idnits 2.17.1 draft-du-ippm-self-contained-alt-mark-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 (October 24, 2021) is 915 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft P. Liu 4 Intended status: Experimental China Mobile 5 Expires: April 27, 2022 October 24, 2021 7 Self-Contained Alternate-Marking Mechanism for Performance Monitoring in 8 High-Quality Network 9 draft-du-ippm-self-contained-alt-mark-00 11 Abstract 13 This document introduces a self-contained method that can involve the 14 client in based on some extensions to the alternate-marking 15 (coloring) technique. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 27, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Traditional Mechanism Description . . . . . . . . . . . . . . 3 59 3. Proposed Mechanism Description . . . . . . . . . . . . . . . 4 60 4. Analysis of the Potential Problems . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The network operators are planning to provide network services with 72 higher quality than the traditional BE (Best Effort) service, such as 73 the DetNet service [RFC8655] and the Network Slicing service. In 74 these practices, it is important to monitor the performance of the 75 service, such as the packet loss, delay, and jitter of the flow with 76 guaranteed quality. 78 In [RFC8321], an alternate-marking method for passive and hybrid 79 performance monitoring is proposed. It marks the packet by using one 80 or more bits in the packet headers, and collects the number of 81 packets in a block sent on one end and the number of packets in the 82 same block received on the other end. Finally, the two values are 83 compared and accordingly, the packet loss of the flow are computed. 85 The alternate-marking method is potential applied to any kind of 86 packet-based traffic, and easy to implement. However, a controller 87 or NMS needs to collect the information from the coloring point and 88 the monitoring point, and correlate the two pieces of information by 89 using the same block ID. It is hard to make it an end-to-end 90 solution because the client is not in the scope. 92 In this document, we propose a method that can involve the client in 93 based on some extensions to the alternate-marking (coloring) 94 technique. In this method, the block information is serialized and 95 encoded in the packets of the block by the client. Then, the 96 monitoring points can recover the information from the received 97 packets, such as the block ID, number of packets in the block, 98 timestamps in the packet, and compute the target measurement values. 100 2. Traditional Mechanism Description 102 As described in [RFC8321], the alternate-marking method is based on 103 the "block", which represents a measurable entity unambiguously 104 recognizable by all network devices along the path. 106 In the alternate-marking (coloring) technique, the coloring point 107 creates packet blocks, colors the packets in the block, and reports 108 information including block ID to the controller or the NMS. The 109 monitoring points recognize the coloring information, record some 110 needed information and report it to the controller or the NMS. 112 ___________________________ 113 | Controller or | 114 | NMS | 115 --------------------------- 116 / \ \ \ 117 / \ \ \ 118 / Information including Block ID \ 119 / \ \ \ 120 / \ \ \ 121 __________ ____________ ____________ ____________ 122 | Coloring | | Monitoring | | Monitoring | | | 123 | point | | point1 | | point2 | | ... | 124 ---------- ------------ ------------ ------------ 125 Coloring Information: 126 000000111111 000000111111 000000111110 ... 128 Traffic Flow 129 ====================================================================> 131 Figure 1: Mechanism in the traditional alternate-marking method 133 For example, if some packets are lost in the network, the packet 134 numbers of the same block will be different between the coloring 135 point and the monitoring point. If we need to compute the delay or 136 jitter of the flow, the coloring point and the monitoring point can 137 also report the timestamps of the packets in the block to the 138 controller or NMS. 140 Traffic coloring can be implemented by setting a specific bit in the 141 packet header and changing the value of that bit periodically. Thus, 142 we only need two colors, and the packets belonging to the same block 143 have the same color, whilst consecutive blocks will have different 144 colors. 146 When the color changes, the previous block terminates and the new one 147 begins. Two mechanisms of switching color are introduced in 148 [RFC8321]. The first one is to switch the color after a fixed number 149 of packets. The second one is to switch according to a fixed timer. 150 For example, the timer may be 5 minutes. 152 3. Proposed Mechanism Description 154 To make the block information self-contained in the block, we need to 155 occupy another specific bit to encode the block information. Thus, 156 the client in the proposed mechanism needs not to report anything to 157 the controller or NMS, and the monitoring points can compute target 158 measurement values themselves and report any problem if needed. 160 For example, we assume the fixed timer mechanism is used, and there 161 are about 300 packets in a block. In the client, each packet carries 162 one bit of the block information. Thus, if all the packets are 163 received orderly, a monitoring point can recover the block 164 information encoded in those 300 packets. 166 ___________________________ 167 | Controller or | 168 | NMS | 169 --------------------------- 170 \ \ \ 171 \ \ \ 172 \ Target Measurement Values\ 173 \ \ \ 174 \ \ \ 175 __________ ____________ ____________ ____________ 176 | Coloring | | Monitoring | | Monitoring | | | 177 | point | | point1 | | point2 | | ... | 178 ---------- ------------ ------------ ------------ 179 Coloring Information: 180 000000111111 000000111111 000000111110 ... 181 Block Information: 182 001101010100 001101010100 001101010100 ... 184 Traffic Flow 185 ====================================================================> 187 Figure 2: Mechanism in the self-contained alternate-marking method 189 The block information can include the block ID (32 bits), CRC 190 (32bits), and some TLVs as described below. 192 o TLV 1 may be the interval of the block (32bits). 194 o TLV 2 may be the packet number of the last block (32bits). 196 o TLV 3 may be the timestamp of the first packet in the block 197 (32bits). 199 The encoding of the block information is done in the client, and the 200 monitoring points need to understand the meaning of the encoding. 202 4. Analysis of the Potential Problems 204 As described in the last section, we assume that all the packets in a 205 block are received in the monitoring point orderly. Normally, it is 206 hard for the IP network with a relatively high packet loss rate. 207 However, the situation may be much better in the DetNet service or 208 the Network Slicing service, for which no or few packets would be 209 lost. Meanwhile, an additional recovery block may also appear after 210 several blocks, in which we will encode recovery information for the 211 past several blocks, instead of the block information. Other fault 212 tolerance mechanisms can also be considered. 214 Another problem is similar to the situation in [RFC8321]. It is 215 whether we can find at least two reserved bits in the packet header 216 to encode the coloring information and the block information. The 217 detailed analysis can be found in that document. 219 5. IANA Considerations 221 TBD. 223 6. Security Considerations 225 TBD. 227 7. Acknowledgements 229 TBD. 231 8. References 232 8.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 240 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 241 "Alternate-Marking Method for Passive and Hybrid 242 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 243 January 2018, . 245 8.2. Informative References 247 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 248 "Deterministic Networking Architecture", RFC 8655, 249 DOI 10.17487/RFC8655, October 2019, 250 . 252 Authors' Addresses 254 Zongpeng Du 255 China Mobile 256 No.32 XuanWuMen West Street 257 Beijing 100053 258 China 260 Email: duzongpeng@foxmail.com 262 Peng Liu 263 China Mobile 264 No.32 XuanWuMen West Street 265 Beijing 100053 266 China 268 Email: liupengyjy@chinamobile.com