idnits 2.17.00 (12 Aug 2021) /tmp/idnits13775/draft-xiong-rtgwg-precise-tn-problem-statement-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 ([I-D.xiong-rtgwg-precise-tn-requirements]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 1, 2020) is 559 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 (-01) exists of draft-xiong-rtgwg-precise-tn-requirements-00 ** Downref: Normative reference to an Informational RFC: RFC 8557 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Q. Xiong 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track P. Liu 5 Expires: May 5, 2021 China Mobile 6 November 1, 2020 8 The Problem Statement for Precise Transport Networking 9 draft-xiong-rtgwg-precise-tn-problem-statement-01 11 Abstract 13 As described in [I-D.xiong-rtgwg-precise-tn-requirements], the 14 deterministic networks not only need to offer the Service Level 15 Agreements (SLA) guarantees such as low latency and jitter, low 16 packet loss and high reliability, but also need to support the 17 precise services such as flexible resource allocation and service 18 isolation so as to the Precise Transport Networking. However, under 19 the existing IP network architecture with statistical multiplexing 20 characteristics, the existing deterministic technologies are facing 21 long-distance transmission, queue scheduling, dynamic flows and per- 22 flow state maintenance and other controversial issues especially in 23 Wide Area Network (WAN) applications. 25 This document analyses the problems in existing deterministic 26 technologies to provide precise services in various industries such 27 as 5G networks. 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 May 5, 2021. 46 Copyright Notice 48 Copyright (c) 2020 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 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions used in this document . . . . . . . . . . . . . . 4 67 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Problem with Traffic Scheduling Mechanisms . . . . . . . 4 71 3.2. Problem with Long-distance Transmission Delay and Jitter 5 72 3.3. Problem with SLA Guarantees of Dynamic Flows . . . . . . 5 73 3.4. Problem with Service Isolation . . . . . . . . . . . . . 6 74 3.5. Problem with Precise Resource Allocation . . . . . . . . 6 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 1.1. Overview 85 5G network is oriented to the internet of everything. In addition to 86 the Enhanced Mobile Broadband (eMBB) and Massive Machine Type 87 Communications(mMTC) services, it also supports the Ultra-reliable 88 Low Latency Communications (uRLLC) services. The uRLLC services 89 cover the industries such as intelligent electrical network, 90 intelligent factory, internet of vehicles, industry automation and 91 other industrial internet scenarios, which is the key demand of 92 digital transformation of vertical domains. These uRLLC services 93 demand SLA guarantees such as low latency and high reliability and 94 other deterministic and precise properties. 96 For the intelligent electrical network, there are deterministic 97 requirements for communication delay, jitter and packet loss rate. 98 For example, in the electrical current difference model, a delay of 99 3~10ms and a jitter variation is no more than 100us are required. 100 The isolation requirement is also important. For example, the 101 automatic operation, control of a process, isochronous data and low 102 priority service need to meet the requirements of hard isolation. In 103 addition to the requirements of delay and jitter, the differential 104 protection (DP) service needs to be isolated from other services. 106 The industrial internet is the key infrastructure that coordinate 107 various units of work over various system components, e.g. people, 108 machines and things in the industrial environment including big data, 109 cloud computing, Internet of Things (IOT), Augment Reality (AR), 110 industrial robots, Artificial Intelligence (AI) and other basic 111 technologies. For example, automation control is one of the basic 112 application and the the core is closed-loop control system. The 113 control process cycle is as low as millisecond level, so the system 114 communication delay needs to reach millisecond level or even lower to 115 ensure the realization of precise control. There are three levels of 116 real-time requirements for industrial interconnection: factory level 117 is about 1s, and process level is 10~100ms, and the highest real-time 118 requirement is motion control, which requires less than 1ms. 120 1.2. Motivation 122 The applications in 5G networks demand much more deterministic and 123 precise properties. But traditional Ethernet, IP and MPLS networks 124 which is based on statistical multiplexing provides best-effort 125 packet service and offers no delivery and SLA guarantee. The 126 deterministic forwarding can only apply to flows with such well- 127 defined characteristics as periodicity and burstiness. 129 Technologies to provide deterministic service has been proposed to 130 provide bounded latency and jitter based on a best-effort packet 131 network. IEEE 802.1 Time-Sensitive Networking (TSN) has been 132 proposed to provide bounded latency and jitter in L2 LAN networks. 133 According to [RFC8655], Deterministic Networking (DetNet) operates at 134 the IP layer and delivers service which provides extremely low data 135 loss rates and bounded latency within a network domain. However, the 136 existing mechanisms are not sufficient for precise performance such 137 as precise latency, jitter variation, packet loss and more other 138 precise and deterministic properties. 140 As described in [xiong-rtgwg-precise-networking-requirements], the 141 deterministic networks not only need to offer the Service Level 142 Agreements (SLA) guarantees such as low latency and jitter, low 143 packet loss and high reliability, but also need to support the 144 precise services such as flexible resource allocation and service 145 isolation so as to the Precise Transport Networking. However, under 146 the existing IP network architecture with statistical multiplexing 147 characteristics, the existing deterministic technologies are facing 148 long-distance transmission, traffic scheduling, dynamic flows, per- 149 flow state maintenance and other controversial issues especially in 150 Wide Area Network (WAN) applications. 152 This document analyses the problems in existing deterministic 153 technologies to provide precise services in various industries such 154 as 5G networks. 156 2. Conventions used in this document 158 2.1. Terminology 160 The terminology is defined as [RFC8655] and [xiong-rtgwg-precise- 161 networking-requirements]. 163 2.2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 3. Problem Statement 173 3.1. Problem with Traffic Scheduling Mechanisms 175 As described in [RFC8655], the primary means by which DetNet achieves 176 its QoS assurances in IP networks is to eliminate the latency and 177 packet loss by the provision of sufficient resource at each node. 178 But only the resource itself is not sufficient, the traffic 179 scheduling mechanisms such as queuing, shaping, and scheduling 180 functions must be applied in L3 networks. 182 The congestion control, queue scheduling and other traffic mechanisms 183 which have been proposed in IEEE 802.1 TSN. But most of them are 184 based on the time synchronization and time cycle, such as 185 IEEE802.1Qbv, IEEE802.1Qch and so on. It will be difficult to 186 achieve precise time synchronization with all network nodes due to 187 deployment and cost reasons. And the shaping and queuing methods 188 which are not based on time synchronization such as IEEE802.1Qav and 189 IEEE802.1Qcr might not be suitable or available for some L3 networks 190 such as WAN application where multiple dynamic traffic flows may be 191 existed. 193 Moreover, the requirements of the all nodes in WAN networks to apply 194 the time synchronization and traffic scheduling mechanisms will also 195 lead to the difficulty of network scalability and deployment. 197 3.2. Problem with Long-distance Transmission Delay and Jitter 199 In WAN application, long-distance transmission will lead to 200 uncertainties, such as increasing transmission delay, jitter and 201 loss. The link delay of transmission is variable and can not be 202 ignored, and it must be considered in the end-to-end deterministic 203 forwarding mechanisms which are based on time synchronous. So the 204 following problems should be considered. 206 Precise measurement of the link delay. 208 The symmetry of bidirectional forwarding of the link delay. 210 Time cycle alignment in flows aggregation scenario. 212 3.3. Problem with SLA Guarantees of Dynamic Flows 214 As described in [RFC8557], deterministic forwarding can only apply to 215 flows with such well-defined characteristics as periodicity and 216 burstiness. As defined in DetNet architecture [RFC8655], the traffic 217 characteristics of an App-flow can be CBR (constant bit rate) or VBR 218 (variable bit rate) of L1, L2 and L3 layers (VBR takes the maximum 219 value when reserving resources). But the current scenarios and 220 technical solutions only consider CBR flow, without considering the 221 coexistence of VBR and CBR, the burst and aperiodicity of flows. The 222 operations such as shaping or scheduling have not been specified. 223 Even TSN mechanisms are based on a constant and forecastable traffic 224 characteristics. 226 It will be more complicated in WAN applications where much more flows 227 coexist and the traffic characteristics is more dynamic. It is 228 required to offer reliable delivery and SLA guarantee for dynamic 229 flows. For example, periodic flow and aperiodic flow (including 230 micro burst flow, etc.), CBR and VBR flow, flow with different 231 periods or phases, etc. When the network needs to forward these 232 deterministic flows at the same time, it must solve the problems of 233 time window selection, queue processing and aggregation of multiple 234 flows. 236 Moreover, the existing solutions do not consider the characteristics 237 analysis of service requirements, including the impact of dynamic 238 characteristics analysis on the network, mainly about how to ensure 239 the certainty in the case of dynamic flows. 241 3.4. Problem with Service Isolation 243 In some scenarios, such as intelligent electrical network, the 244 isolation requirements are very important. For example, the 245 automatic operation or control of a process or isochronous data and 246 low priority service need to meet the requirements of hard isolation. 247 In addition to the requirements of delay and jitter, the differential 248 protection (DP) service needs to be isolated from other services and 249 hard isolated tunnel is required. 251 The resource reservation in DetNet can only ensure the statistical 252 reuse of bandwidth resources, but it can not guarantee the precise 253 isolation and control of instantaneous burst and can not realize the 254 hard isolation of each flow. The existing solutions cannot achieve 255 the requirements of service isolation. 257 3.5. Problem with Precise Resource Allocation 259 As described in [RFC8655], the primary means by which DetNet achieves 260 its QoS assurances is to reduce, or even completely eliminate, packet 261 loss by the provision of sufficient buffer storage at each node. But 262 it can not be achieved by not enough resource which can be allocated 263 due to practical and cost reason. The existing solutions can not 264 achieve the precise resource allocation. 266 4. Security Considerations 268 TBA 270 5. Acknowledgements 272 TBA 274 6. IANA Considerations 276 TBA 278 7. Normative References 280 [I-D.xiong-rtgwg-precise-tn-requirements] 281 Xiong, Q. and P. Liu, "The Requirements for Precise 282 Transport Networking", draft-xiong-rtgwg-precise-tn- 283 requirements-00 (work in progress), April 2020. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 292 May 2017, . 294 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 295 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 296 . 298 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 299 "Deterministic Networking Architecture", RFC 8655, 300 DOI 10.17487/RFC8655, October 2019, 301 . 303 Authors' Addresses 305 Quan Xiong 306 ZTE Corporation 307 No.6 Huashi Park Rd 308 Wuhan, Hubei 430223 309 China 311 Email: xiong.quan@zte.com.cn 313 Peng Liu 314 China Mobile 315 Beijing 100053 316 China 318 Email: liupengyjy@chinamobile.com