idnits 2.17.1 draft-liu-detnet-dynamic-latency-guarantee-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 10, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.finn-detnet-bounded-latency' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-detnet-architecture' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qav' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qbu' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qch' is defined on line 378, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-finn-detnet-bounded-latency-02 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-11 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Deterministic Networking Working Group P. Liu 3 Internet-Draft L. Geng 4 Intended status: Informational China Mobile 5 Expires: September 11, 2019 March 10, 2019 7 Dynamic Latency Guarantee 8 draft-liu-detnet-dynamic-latency-guarantee-00 10 Abstract 12 Aiming at the deterministic demand for network latency in future 13 vertical industry applications, this document analyzes the existing 14 latency control methods for data transmission, points out the 15 possible shortcomings, and proposes some directions for optimizing 16 the latency control method. . 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 11, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Core Technology of Bounded Latency . . . . . . . . . . . . . 3 60 2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for 61 Time-Sensitive Streams . . . . . . . . . . . . . . . . . 3 62 2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic . . . . 3 63 2.3. IEEE 802.1Qbu Frame Preemption . . . . . . . . . . . . . 3 64 3. Problems and Requirments . . . . . . . . . . . . . . . . . . 4 65 3.1. Problems . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Requirments . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Dynamic Latency Guarantee . . . . . . . . . . . . . . . . 6 69 4.2. Feedback System . . . . . . . . . . . . . . . . . . . . . 7 70 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 With the vigorous development of 5G and industrial Internet, network 81 technology has become more and more important to support new types of 82 services, such as AR/VR, V2X, industrial motion control, etc., which 83 have stringent requirements for latency and stability. In order to 84 meet the requirements of the above applications, new network 85 technologies such as time-sensitive network TSN, deterministic 86 network DETNET, etc., have proposed corresponding technical means to 87 provide network bearers with deterministic latency and packet loss 88 rate and guarantee the user's business experience. 90 TSN includes a set of standards developed by the IEEE 802.1 Working 91 Group's. The TSN task group inherited from the previous Audio/Video 92 Bridging working group and has expanded its applications to in- 93 vehicle, industrial, and mobile networks. Deterministic network 94 (DETNET) is based on the mechanism of TSN. The difference is that 95 TSN is applied to the data link layer and below. DETNET is committed 96 to applying the method to the IP layer to provide more reliable and 97 stable network transmission. 99 This document will present some problems when applying TSN in DETNET, 100 and try to propose reference methods to solve the corresponding 101 problems. 103 2. Core Technology of Bounded Latency 105 Based on time synchronization, TSN has a range of bounded latency 106 technologies. 108 2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for Time- 109 Sensitive Streams 111 IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive 112 Streams inherited from the AVB, including priority mapping algorithms 113 and Credit-based Traffic Shaping algorithms. The priority mapping 114 algorithms is to mapping the priority to 'traffic class', which 115 represents whether the stream is time sensitive or not. Credit-based 116 Traffic Shaping algorithms provide the method to allocate bandwidth 117 of different streams. 119 2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic 121 In IEEE 802.1Qbv, the gate control list is created according to the 122 actual stream and timescale. It contains the transmission sequence 123 of all streams, and controls whether the data stream of each priority 124 is sent at the current time or not. All streams will be transmitted 125 strictly according to the current list. More Than This, IEEE 126 802.1Qbv also defines the guard band mechanism and spares part of the 127 time to guarantee the transmission of high priority data frames at 128 the beginning of the next time slice. 130 2.3. IEEE 802.1Qbu Frame Preemption 132 In the preemption mechanism, high-priority frames can interrupt the 133 transmission of low-priority data frames unless low-priority data 134 frames can no longer be fragmented. This standard fully guarantees 135 the transmission delay of the highest priority data frame, and also 136 reduces the guard band in IEEE 802.1Qbv to 127 bytes. The frame 137 preemption mechanism changes the transmission rules of the ethernet 138 frame and is used in conjunction with the IEEE 802.3Qbr . 140 In addition to these, there are also other standards to guarantee the 141 sequence of receiving data streams, which are fine-grained traffic 142 scheduling technology and the key technologies of TSN in bounded 143 latency. 145 3. Problems and Requirments 147 DETNET refers to the bounded latency mechanism of TSN, so it needs to 148 pay attention to some problems in the bounded latency mechanism. 149 There are several standards refers to bounded latency. Users can 150 decide whether to use a specific standard or not, which depends on 151 the requirments of network and business. Some TSN testbeds have been 152 established these years whose basic concept is realizing 802.1Qbv to 153 ensure the deterministic transmission of time sensitive stream. 154 Though it realized ignoring the interfere of background stream, the 155 testbed was too simple. In fact, networking is complicated. There 156 will be more than two kind of streams being transmitted. So it is 157 not that easily to apply those mechanisms on real networks. 159 3.1. Problems 161 Because of the complicated of real networks, there may be some 162 situations that the preemptable data frame transmission delay is too 163 large or cannot be transmitted. Thoes might occur when both 164 Enhancements for Scheduled Traffic and Frame Preemption are enabled. 166 Except for the highest priority, the others may be preempted by the 167 time slice to wait for transmission. In the actual scenario, the 168 preemptable data frame is not necessarily a completely non-time 169 sensitive frame, so it also need to guarantee the transmission of 170 some preemptable frame. However, Under the current mechanism, there 171 may be multiple preemption to cause a very large transmission delay 172 or no transmission of preemptable frame, depending on the size of the 173 express frame and the period of the timescale. In an actual 174 scenario, a data frame with a Secondary high priority may also be a 175 time-sensitive. If it cannot be transmitted or the transmission 176 delay is large, the service cannot be operated. 178 For example, there are currently two queues are transmited following 179 the gate control list which assuming is the following table. In the 180 table, T00, T01, T02... represent the order of each time slice and 181 switching. The "01" and "10" in the right represent whether the two 182 queue can be transmitted in the current period. Assuming that 0 183 indicates that the gate is closed and the corresponding queue cannot 184 be transmitted. while 1 indicates the gate is open and corresponding 185 queue can be transferred. Then the following two cases may occur: 187 +-----------------------+ 188 | Gate Control List | 189 +-----------------------+ 190 | T00 | 01 | 191 +-----------------------+ 192 | T01 | 10 | 193 +-----------------------+ 194 | T02 | 01 | 195 +-----------------------+ 196 | T03 | 10 | 197 +-----------------------+ 198 | T.. | .. | 199 +-----------------------+ 201 Gate Control List 203 Case 1, The preemptable frame is interrupted many times before the 204 transmission is completed, which causes a high transmission delay of 205 the preemptable frame. 207 Case 2, the preemptable frame cannot be transmitted after once being 208 interrupted. 210 +-------------+---------+-------------+---------+---+-------------+ 211 | Part 1 of | Express | Part 2 of | Express | | Part n of | 212 | Preemptable | | Preemptable | |...| Preemptable | 213 | Frame | Frame A | Frame | Frame B | | Frame | 214 +-------------+---------+-------------+---------+---+-------------+ 216 Case 1 of Preemption 218 +-------------+---------+---------+----------+-----+----------+ 219 | Part 1 of | Express | Express | Express | | Express | 220 | Preemptable | | | | ... | | 221 | Frame | Frame A | Frame B | Frame C | | Frame N | 222 +-------------+---------+---------+----------+-----+----------+ 224 Case 2 of Preemption 226 3.2. Requirments 228 Deterministic network includes deterministic latency and 229 deterministic packet loss. We need to think how to apply the bounded 230 latency mechanism effectively. 232 Before using the bounded latency mechanism, network manager needs to 233 know enough about the network and applications. For example, which 234 kind of stream is time sensitive? How about the frame's transceiver 235 frequency of thoes stream? How much bandwidth does it need? ... When 236 you have a clear understanding of the real-time state of the network, 237 you can configure a delay-limited algorithm for the network. 239 However, the transmission state of the network is not invariable. 240 Some transfer table might make corresponding adjustments according to 241 the current network situation. So the parameters that have been 242 configured before should also be changed. More than this, the 243 bounded latency mechanism also need a feedback system to receive 244 current network status and adjust/reconfigure the network. 246 4. Solutions 248 The implementation of the mechanism to guarantee latency requires 249 sophisticated calculation, including timescale and gate control tist 250 . When the stream in the network becomes diverse, it will consume a 251 lot of computing resources to schedule each stream. Therefore, a 252 single transmission rule may not be able to meet the problem of 253 multiple streams' transmission. Worst of all, the gate control list 254 is not properly calculated, the network may not transmit or failure. 256 4.1. Dynamic Latency Guarantee 258 Dynamic latency guarantee is a way of thinking based on the latency 259 guarantee of the whole network. that is, to dynamically adjust the 260 priority through the current network condition and the transmission 261 of data stream. 263 In the transmission process, the priority of data is based on the 264 "Traffic Class" in IEEE802.1 Qav. that is, the priority of data 265 frames is converted into traffic class according to the mapping 266 table. If the data frame is preempted once, the corresponding 267 traffic class is increased according to certain functional rules. 269 Functional rules can be defined as needed, for example, by assuming: 271 T = Time of preempted 273 M = Lifting coefficient 275 and F(tm)=Increased traffic class 277 That is to say, with the increase of preemption times, the 278 preemptable frames will gradually increase their priority (the 279 corresponding traffic class). When it is greater than or equal to 280 the Traffic Class of express frames, the preemptable frames could 281 complete the transmission. 283 The lifting factor M can be either a constant or a variable varying 284 with T, depending on the network requirements of specific business 285 application scenarios, which will not been discussed in detail in 286 this document. 288 4.2. Feedback System 290 One of the reasons for this situation is that the prediction or 291 mastery of the transmission of frames in the network is not accurate, 292 so a feedback system is needed to tell the network to centrally 293 configure the system. So it could help to optimize the gate control 294 list to avoid the frequent occurring of this problems. The most 295 basic case is that once there are multiple preemption occured, the 296 switch need to report it to the Centralized Configuration System. It 297 represent that there might be some unjustified configurations need to 298 be reconfiguration. For example, distribute more bandwidth to the 299 corresponding traffic class. 301 It should be noted that all devices in the network share the same 302 gate control list. However, due to the difference in time of the 303 transmission path, it is necessary to keep all devices in the network 304 "asynchronous" to execute the gate control list. For example, when 305 the data frame is received by the device A, it is queued to be 306 transmited first in the currently divided time slice. When the frame 307 is received by the device B, the time t1 has elapsed. So the gate 308 control list of device B needs to perform the time difference of t1 309 with the A device, which can ensure that this frame arrives at every 310 device with a first-transmiting in current time slice. 312 -------------------------------------- 313 | Optimize Configuration | 314 V | 315 +-------------+------------+ | 316 | Centralized |------------------------ 317 | Configuration | 318 | System |------------------------ 319 +-------------+------------+ | 320 | Feedback Data| 321 | of Preemption| 322 ----------------------|------------------------ | 323 | | | | 324 V V V | 325 +---------+ +----------+ +---------+ | 326 | Switch A|-----------| Switch B |-------------| Switch C|-------- 327 +---------+ t1 +----------+ t2 +---------+ 328 Gate Control Gate Control Gate Control 329 List List List 331 Feedback System 333 5. Conclusion 335 This draft described the existing mechanism of bounded latency and 336 point out some problems when using them. It also proposed some 337 reference methods to solve them. In the process of network 338 evolution, there might also be more problems need to be noticed and 339 disscuss. 341 6. Security Considerations 343 TBD. 345 7. IANA Considerations 347 TBD. 349 8. References 351 8.1. Normative References 353 [I-D.finn-detnet-bounded-latency] 354 Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, 355 B., and J. Farkas, "DetNet Bounded Latency", draft-finn- 356 detnet-bounded-latency-02 (work in progress), October 357 2018. 359 [I-D.ietf-detnet-architecture] 360 Finn, N., Thubert, P., Varga, B., and J. Farkas, 361 "Deterministic Networking Architecture", draft-ietf- 362 detnet-architecture-11 (work in progress), February 2019. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 8.2. Informative References 371 [IEEE802.1Qav] 372 IEEE, "Forwarding and Queuing Enhancements for Time- 373 Sensitive Streams (IEEE 802.1Qav)", 2009. 375 [IEEE802.1Qbu] 376 IEEE, "Frame Preemption", 2015. 378 [IEEE802.1Qch] 379 IEEE, "Cyclic Queuing and Forwarding", 2015. 381 [IIEEE802.1Qbv] 382 IEEE, "Enhancements for Scheduled Traffic", 2016. 384 Authors' Addresses 386 Peng Liu 387 China Mobile 388 Beijing 100053 389 China 391 Email: liupengyjy@chinamobile.com 393 Liang Geng 394 China Mobile 395 Beijing 100053 396 China 398 Email: gengliang@chinamobile.com