idnits 2.17.1 draft-wang-ippm-ipv6-flow-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 61 lines 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 1 character 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 date (October 25, 2021) is 913 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 (-17) exists of draft-ietf-6man-ipv6-alt-mark-08 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) -- Obsolete informational reference (is this intentional?): RFC 8889 (Obsoleted by RFC 9342) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Wang 3 Internet-Draft Y. Liu 4 Intended status: Standards Track China Mobile 5 Expires: May 29, 2022 C. Lin 6 New H3C Technologies 7 M. Xiao 8 ZTE Corporation 9 October 25, 2021 11 Flow Measurement in IPv6 Network 12 draft-wang-ippm-ipv6-flow-measurement-00 14 Abstract 16 In-situ Operations, Administration, and Maintenance (OAM) need 17 carrying necessary measurement information in the packet while the 18 packet transverses a path between two points in the network to mark 19 the packet. The Alternate-Marking is a kind of marking method and is 20 presented in RFC 8321, Alternate-Marking Method for Passive and 21 Hybrid Performance Monitoring, and RFC 8889, Multipoint Alternate- 22 Marking Method for Passive and Hybrid Performance Monitoring. This 23 document describes how to deploy in-situ flow performance measurement 24 based on Alternate-Marking method in IPv6 domain. 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 May 29, 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Flow Measurement in IPv6 Network . . . . . . . . . . . . . . 3 64 2.1. Carrying Flow Measurement Data . . . . . . . . . . . . . 3 65 2.2. Flow Measurement Data Definition . . . . . . . . . . . . 4 66 3. Definition of Flow Monitor Option . . . . . . . . . . . . . . 4 67 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4 68 4. Definition of Flow Monitor Option . . . . . . . . . . . . . . 6 69 4.1. Flow Monitoring Identification . . . . . . . . . . . . . 6 70 5. Flow Measurement Operation . . . . . . . . . . . . . . . . . 7 71 5.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7 72 5.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 7 73 5.3. Measurement Type . . . . . . . . . . . . . . . . . . . . 8 74 5.4. Two-way Flow Measurement . . . . . . . . . . . . . . . . 8 75 5.5. Data Collection and Report . . . . . . . . . . . . . . . 9 76 5.6. Function Extension Consideration . . . . . . . . . . . . 9 77 5.6.1. The Use of Ext FM Type Bitmap . . . . . . . . . . . . 10 78 5.6.2. Bitmap Extension . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 8.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The Alternate-Marking method, as described in [RFC8321] and 89 [RFC8889], allows the synchronization of the measurements in 90 different points by dividing the packet flow into batches. So it is 91 possible to get coherent counters and show what is happening in every 92 marking period for each monitored flow. Based on this ability, the 93 method could be used to perform packet loss, delay and jitter 94 measurements on live traffic. 96 This document discusses how to deploy performance measurement based 97 on Alternate-Marking method in IPv6 domain. The measurement 98 operation is described and the applications are proposed in 99 Section 5. 101 A specific data structure is defined to carrying in-situ flow 102 measurement data with traffic flow, and the extensibility is taken 103 into account in designing. The structure is called Flow Monitor 104 Option, and detail is in Section 3. 106 How to encapsulate the Flow Monitor Option in IPv6 traffic flow is 107 discussed in Section 2. A new type of IPv6 Extension Header is 108 proposed, Flow Monitor Option is encapsulated in Hop-by-Hop options 109 Header or Destination Options Header depending on the measurement 110 type. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 1.2. Terminology 122 The definitions of the basic terms are identical to those found in 123 Alternate Marking [RFC8321] and Multipoint Alternate-Marking 124 [RFC8889]. 126 The important new terms that need to be explained are listed below: 128 ACL: access-control list 130 2. Flow Measurement in IPv6 Network 132 2.1. Carrying Flow Measurement Data 134 The flow measurement method described by this document need to add 135 measurement data in the flow used to perform measure. In IPv6, the 136 general way to carry packet's additional information is IPv6 137 Extension Header. Several IPv6 Extension Headers have been defined 138 in [RFC8200]. It is necessary to determine suitable Ipv6 Extension 139 Header to carry measuring data for deploying of performance measure 140 in IPv6. 142 There are two measurement types: End-to-End and Hop-by-Hop. The 143 participating nodes in two types are different. 145 The source node allocates measurement data and encodes it in packet. 146 For End-to-End measurement, just destination node processes the 147 measuring data. According to Section 4.1 of [RFC8200], IPv6 148 Destination Options Header before the upper-layer header is 149 appropriate for End-to-End measurement. 151 For Hop-by-Hop measurement, all nodes on the delivery path are 152 expected to examine and process the measurement data. According to 153 [RFC8200], the measurement data can be carried as an option of Hop- 154 by-Hop Options Header. 156 2.2. Flow Measurement Data Definition 158 As description in Section 2.1, flow measurement data is encoded in 159 IPv6 Destination Options Header and IPv6 Hop-by-Hop Options Header. 160 Flow measurement data structure must be defined following IPv6 161 Option's principle. 163 This document defines Flow Monitor Option for flow measurement. 164 Using Flow Monitor Option to marking packets required by Alternate- 165 Marking, and to carry flow identity and measure parameters. 167 3. Definition of Flow Monitor Option 169 Flow Monitor Option is defined to carry flow measurement data, below 170 is detailed description. 172 3.1. Data Fields Format 174 The following figure shows the data field's format for Flow Monitor 175 Option. This flow monitoring and measurement data structure can be 176 encapsulated in the Hop-by-Hop Options Header and Destination Options 177 Header. 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Option Type | Opt Data Len | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | FlowMonID |L|D| R | HTI | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | NodeMonID |F| P | Rsv | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Ext FM Type | Reserved | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: Flow Monitor Option 193 where: 195 o Option Type: 8-bit identifier of the type of Flow Monitor Option. 196 The encoding format references Section 4.2 of [RFC8200]. The 197 value is to be assigned by IANA. 199 o Opt Data Len: The length of the Option Data Fields of this option 200 in bytes. 202 o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is 203 used to identify one flow in the node. 205 o L: Loss Flag, a marking bit of packet loss measurement. 207 o D: Delay Flag, a marking bit of packet delay measurement. 209 o R: Reserved for future use, now initialized to zero for 210 transmission and ignored on reception. 212 o HTI: Header Type Indication. It indicates the type of the option 213 header, has the following value: 215 * 0: Reserved, indicate that the format of Flow Monitor Option is 216 the same as [I-D.ietf-6man-ipv6-alt-mark]. 218 * 1~15: Private type. 220 * 16~255: Extensible type value. When the value is 16, the 221 format of the option header is as shown in Figure 2. 223 o NodeMonID: 20 bits unsigned integer. It is used to identify a 224 node in the measurement domain, combined with the FlowMonID field 225 to uniquely identify a monitored flow. Detail description sees 226 Section 4.1. 228 o F: The marking bit of two-way flow measurement. If the field is 229 set to 1, the end node generates reverse flow measurement 230 configuration dynamically according to the current flow. 232 o P: 3 bits, measurement period. It has the following values: 234 * 000: 1 second 236 * 001: 10 seconds 238 * 010: 30 seconds 240 * 011: 60 seconds 241 * 100: 300 seconds 243 * Others: Reserved 245 o Ext FM Type: A 16 bits Bitmap for Extended Flow Measurement type. 246 The Bitmap can present 15 different measurement types. From bit 0 247 to 14, each bit presents a specific measurement type. The bit15 248 is reserved for extension Bitmap, 1 indicates carrying the 249 extension Bitmap. The use case about Ext FM Type is described in 250 Section 5.6. 252 4. Definition of Flow Monitor Option 254 When flow measurement is enabled, source node allocates Flow Monitor 255 Option for monitored flows, fills measurement parameters, sets 256 marking bits, and adds an extension header for packet encapsulating 257 the Flow Monitor Option. 259 For Hop-by-Hop measurement, the Flow Monitor Option is encapsulated 260 in the Hop-by-Hop Options Header. 262 For End-to-End measurement, the Flow Monitor Option is encapsulated 263 in the Destination Options Header before the upper-layer header. 265 4.1. Flow Monitoring Identification 267 The Flow Monitoring Identification is required for some general 268 reasons: 270 First, it helps to reduce the per node configuration. Otherwise, 271 each node needs to configure an access-control list (ACL) for each of 272 the monitored flows. Moreover, using a Flow Monitoring 273 Identification allows a flexible granularity for the flow definition. 275 Second, it simplifies the counters handling. Hardware processing of 276 flow tuples (and ACL matching) is challenging and often incurs into 277 performance issues, especially in tunnel interfaces. 279 Third, it eases the data export encapsulation and correlation for the 280 collectors. 282 The NodeMon identifier (NodeMonID) field is filled with the source 283 node's identifier. The NodeMonID as configuration is set on the 284 source node by the central controller. The controller ensures 285 NodeMonID is unique within the measurement domain. 287 The FlowMon identifier (FlowMonID) field is used to uniquely identify 288 a monitored flow within a specified source node. The FlowMonID can 289 be uniformly assigned by the central controller, also can be 290 algorithmically generated by the source node based on the flow 291 information. 293 Using the combination of FlowMonID and NodeMonID, a monitored flow 294 can be uniquely identified within the measurement domain. The 295 FlowMonID field and NodeMonID field are set at the source node. 297 5. Flow Measurement Operation 299 [RFC8321] describes a method to perform packet loss, delay and jitter 300 measurements on live traffic. This section describes how the method 301 can be applied in IPv6 network. 303 5.1. Packet Loss Measurement 305 The L marking bit in the Flow Monitor Option is used to color the 306 flows that need packet loss measurement. By setting the L marking 307 bit to 1 or 0 according to the measurement period filled in P field 308 in the source node, the monitored flows can be split into consecutive 309 blocks. The intermediate and end nodes read the L marking bit and 310 identify the packet blocks. By counting the number of packets in 311 each block and comparing the values measured by different nodes along 312 the path, it is possible to measure packet loss occurred in any 313 single block between any two points. 315 5.2. Packet Delay Measurement 317 The same principle used to measure packet loss also can be applied to 318 one-way delay measurement. Packet delay measurement references 319 Double-Marking Method described in [RFC8321] using the L marking bit 320 and D marking bit in Flow Monitor Option. 322 The L marking bit is used to mark the alternate flow. By marking the 323 L marking bit to 1 or 0, the monitored flows can be split into 324 consecutive blocks. And, within this colored flow identified by the 325 L marking bit, a second marked D marking bit is used to select the 326 packets for measuring delay. The D marking bit creates a new set of 327 marked packets that are fully identified over the network, so that a 328 network node can store the timestamps of these packets; these 329 timestamps can be compared with the timestamps of the same packets on 330 a second node to compute packet delay values for each packet. 332 Likewise to packet delay measurement, the on-path jitter can be 333 measured by measuring multiple blocks. 335 5.3. Measurement Type 337 For different measurement requirements, there are End-to-End 338 measurement type and Hop-by-Hop measurement type. 340 With the End-to-End measurement type, it can measure the forwarding 341 performance between source node and end node when the traffic passes 342 through the measurement domain. The performance of each intermediate 343 node or link is not cared about. Therefore, when using the End-to- 344 End measurement type, only the source node and end node need to 345 collect performance data and report data to controller. 347 With the Hop-by-Hop measurement type, each node along the path which 348 has enabled performance measurement SHOULD collect performance data 349 and report data to the controller when the traffic passes through the 350 measurement domain. 352 Compared to the End-to-End measurement type, the Hop-by-Hop 353 measurement type can more accurately locate the network packet loss 354 and delay in position. 356 The measurement type is determined by the position of Flow Monitor 357 Option in the IPv6 Extension Header. The Flow Monitor Option can be 358 encapsulated in Hop-by-Hop Options Header or Destination Options 359 Header. When it is encapsulated in the Hop-by-Hop Options Header, 360 each node along the path will deal with it. That is Hop-by-Hop 361 measurement. When the Flow Monitor Option is encapsulated in the 362 Destination Options Header, it means End-to-End measurement. 364 5.4. Two-way Flow Measurement 366 As described in [RFC8321] the source node needs to virtually split 367 traffic flows into consecutive blocks according to some methods, such 368 as configuring an access-control list (ACL) for each of the monitored 369 flows. But, if we want to measure bidirectional forwarding 370 performance of monitored flows on the specified path, we need to 371 configure ACLs associated monitored flows on the source node and end 372 node at the same time. This will increase the configuration and 373 maintenance workload. And this work is more complex, such as source 374 IP addresses in the source node configuration need to be transformed 375 as destination IP addresses in the end node, and other 376 characteristics are similar. 378 Therefore, this document provides a two-way flow measurement method. 379 It generates reverse flow measurement configuration dynamically in 380 the end node according to the forward flow. 382 Two-way flow performance measurement is implemented as follows: 384 1. The source node configures ACLs for monitored flows that need 385 bidirectional flow measurement. 387 2. When the source node receives the corresponding monitored flow, 388 it encapsulates Flow Monitor Option into the IPv6 Extension Header, 389 and sets the F field to 1. 391 3. When the end node receives the monitored flow which F field has 392 been set to 1, it analysis the information of positive monitored 393 flow, changes the source and destination information, dynamically 394 generates ACLs with the characteristics of reverse monitored flows, 395 and distributes configuration on end node. 397 4. At the same time, the end node assigns FlowMonID for reverse 398 monitored flows, and reports the new reserve FlowMonID, the NodeMonID 399 of the end node and the reverse flow information to controller. 401 5. When the end node receives the reserve monitored flow, the end 402 node encapsulates Flow Monitor Option into IPv6 Extension Header, 403 sets F field to 0, uses the FlowMonID and NodeMonID of end node, and 404 fills other fields of Flow Monitor option according to the end node's 405 configuration. 407 6. All nodes along the reserve path enabled performance measurement 408 collect performance data, report to controller according Flow Monitor 409 option in the packet header. 411 5.5. Data Collection and Report 413 Each node which participates in performance measurement collects 414 performance data, records packet counts, received timestamps, sent 415 timestamps, FlowMonID, NodeMonID and other related information 416 specified by Flow Measure Type bitmap, and reports to the controller. 417 For the source node, it needs to report characteristic information of 418 monitored flow additionally. 420 The network nodes report to controller by Telemetry technique. The 421 period of report can be the measurement period filled in the P field 422 of Flow Monitor Option, can also be specified in the Telemetry 423 subscription, or is designated by local configuration. This document 424 does not limit the specific method. 426 5.6. Function Extension Consideration 427 5.6.1. The Use of Ext FM Type Bitmap 429 At present, the performance measurement is commonly attention to 430 network packet loss, delay and jitter. However, with the expanding 431 of network applications, other network performance parameters begin 432 to be concerned, such as out-of-order rate. When network failure, 433 controller wants to be able to obtain more abundant information, and 434 in order to locate fault point quickly requires all nodes along the 435 path to report current queue depth, input and output interface name, 436 and so on. 438 By defining bits of Ext FM Type field in the Flow Monitor Option and 439 carrying additional information in the monitored flows, the 440 measurement function can be extended. 442 For example, in order to measure out-of-order rate, bit0 of Ext FM 443 Type is defined as an out-of-order measurement mark. When the source 444 node receives monitored flow, it sets bit0 to indicate to count out- 445 of-order packets. At the same time, it fills in additional 446 information after Ext FM Type bitmap with ordinal Sequence 447 parameters. After extension, the Flow Monitor Option package format 448 is as follows: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | FlowMonID |L|D| R | HTI | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | NodeMonID |F| P | Rsv | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |1| | Bit0 Data(Sequence Num) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 . . 460 . Bit0 Data(Other information) . 461 . . 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 2: Use Bit0 For Out-of-order Measurement 466 Using the same method, the other bits of Ext FM Type field can be 467 extended. Additional information is optional, whether it is carried 468 is decided by the specified extension function. 470 5.6.2. Bitmap Extension 472 The Ext FM Type field has 16 bit, so 16 measurement functions can be 473 extended. For general applications, the bitmap is enough. In order 474 to reduce the effect on forwarding performance, it is also not 475 recommended too much measurement processes at the same time. 477 However, considering functionality to be expanded in the future, 478 bit15 is reserved, used to break the bitmap limit of 16. If bit15 is 479 set to 1, it indicates carrying the extension bitmap. By default, 480 bit15 is zero. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | FlowMonID |L|D| R | HTI | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | NodeMonID |F| P | Rsv | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Ext FM Type(Bitmap) |1| | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 491 . . 492 . Additional Data of FM Bitmap (Optional) . 493 . . 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Extension Bitmap | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 497 . . 498 . Additional Data of Extension Bitmap (Optional) . 499 . . 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 3: Extension Bitmap Format 504 Based on the previous out-of-order measurement example, for example, 505 after the bits of Ext FM Type have been exhausted, use bit2 of 506 Extension Bitmap to expand FM type. Flow Monitor Option package 507 format is as shown below: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | FlowMonID |L|D| R | HTI | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | NodeMonID |F| P | Rsv | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 |1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1| Bit0 Data (Sequence Num) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 . . 519 . Bit0 Data(Other information) . 520 . . 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 |0|0|1|0|0|0|0|0|0|0|0|0|0|0|0|0| | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 524 . . 525 . Extension Bit2 Data (Optional) . 526 . . 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Figure 4: Extension Bit2 Example 531 6. IANA Considerations 533 The Flow Monitor Option Type should be assigned in IANA. 535 7. Security Considerations 537 The potential security threats of Alternate-Marking method have been 538 described in detail in Section 9 of [RFC8321]. The performance 539 measurement method described in this document does not introduce 540 additional new security issues. 542 8. References 544 8.1. Normative References 546 [I-D.ietf-6man-ipv6-alt-mark] 547 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 548 Pang, "IPv6 Application of the Alternate Marking Method", 549 draft-ietf-6man-ipv6-alt-mark-08 (work in progress), 550 January 2022. 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 559 May 2017, . 561 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 562 (IPv6) Specification", STD 86, RFC 8200, 563 DOI 10.17487/RFC8200, July 2017, 564 . 566 8.2. Informative References 568 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 569 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 570 "Alternate-Marking Method for Passive and Hybrid 571 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 572 January 2018, . 574 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 575 "Multipoint Alternate-Marking Method for Passive and 576 Hybrid Performance Monitoring", RFC 8889, 577 DOI 10.17487/RFC8889, August 2020, 578 . 580 Authors' Addresses 582 Haojie Wang 583 China Mobile 585 Email: wanghaojie@chinamobile.com 587 Yisong Liu 588 China Mobile 590 Email: liuyisong@chinamobile.com 592 Changwang Lin 593 New H3C Technologies 595 Email: linchangwang.04414@h3c.com 597 Min Xiao 598 ZTE Corporation 600 Email: xiao.min2@zte.com.cn