idnits 2.17.1 draft-geng-detnet-requirements-bounded-latency-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 (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 234, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Geng 3 Internet-Draft L. Wang 4 Intended status: Informational China Mobile 5 Expires: January 3, 2019 L. Qiang 6 Huawei Technologies 7 July 2, 2018 9 Technical Requirements of Bounded Latency in Large-scale DetNet 10 Deployment 11 draft-geng-detnet-requirements-bounded-latency-00 13 Abstract 15 This document summarizes the technical requirements of bounded 16 latency of DetNet system in large-scale deployment. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 55 2. End-to-end bounded latency requirements . . . . . . . . . . . 3 56 3. Tolerance of time deviation . . . . . . . . . . . . . . . . . 4 57 4. Massive number of deterministic flows . . . . . . . . . . . . 4 58 5. Stable jitter with long transmission delay . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Deterministic Networking (DetNet) enables the transmission of 68 specific data flows in large scale networks with extremely low data 69 loss rates and bounded latency. [draft-ietf-detnet-problem-statement] 70 outlines the problems that need to be resolved in DetNet, and 71 [draft-ietf-detnet-use-cases] presents the use cases in which DetNet 72 deployment is found beneficial and useful. 74 In DetNet WG, many of the technical requirements and solution have 75 been discussed In order to achieve deterministic networking 76 performance in large-scale network. This mainly include the 77 following aspect. 79 o DetNet Definition and architecture are discussed in 80 [draft-ietf-detnet-architecture] 82 o Encapsulation methods are discussed in[draft-ietf-detnet-dp-sol] 83 with specific mechanisms for identification of DetNet services and 84 approaches for reliable transmission (i.e. Replication of 85 packets). 87 o Security requirements are specially discussed in 88 [draft-ietf-detnet-security]. 90 To some extend, TSN is assumed to be used for Layer 2 underlay for 91 DetNet services to guarantee the bounded latency performance. 92 However, TSN is originally designed for LAN scenario which suffers 93 from scalability problems (i.e. end-to-end time synchronization, 94 sensitive jitter performance subject to transmission latency). 95 Meanwhile, it is also considered challenging to using MPLS/IP 96 encapsulation for DetNet service in which the forwarding plane is 97 purely based on Layer 2 TSN technology. There is yet a document 98 which specifically discusses the requirements of bounded latency with 99 an assumption that DetNet runs as an standalone underlay technology 100 rather than an overlay of TSN. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119. 108 1.2. Terminology & Abbreviations 110 This document uses the terminology defined in 111 [draft-ietf-detnet-architecture]. 113 TSN: Time Sensitive Network 115 2. End-to-end bounded latency requirements 117 As [draft-ietf-detnet-dp-sol] declares, there are two types of 118 scenarios considered in DetNet as shown in Figure 1: (i) inter- 119 connect TSN domains scenario, and (ii) native connectivity between 120 DetNet-aware end systems. 122 +--------------+ +--------------+ 123 | | | | 124 | TSN Domain I +-----------------------------+ TSN Domain II| 125 | | | | 126 +--------------+ +--------------+ 128 (i) Inter-connect TSN Domains 130 +--------------+ +--------------+ 131 |DetNet Device +---------------------------+DetNet Device | 132 +--------------+ +--------------+ 134 (ii) Native Connectivity between DetNet-aware End Systems 136 Figure 1: Two Types of DetNet Scenarios 138 Req 1: Stitching TSN domains with bounded latency. 140 In scenario (i) TSN islands are bridged through DetNet connections, 141 and time synchronization is required inside each TSN domain. Note 142 that different TSN domains may be misaligned in time and it may not 143 be feasible to achieve end-to-end time synchronization in large 144 scale. It is the DetNet domain who has to maintain the bounded 145 latency performance between the separated TSN domains. 147 Req 2: Flexible and fast convergence mechanism as new DetNet flow is 148 created. 150 Considering the features of TSN applications we can speculate that 151 the applications in scenario (i) are usually in a simple manner, 152 which means the number of deterministic flows will not dramatically 153 change with time. At the same time, the traffic patterns are 154 relative regular. While in scenario (ii) there are more bandwidth- 155 greddy applications such as VR communication. They may require 156 establishment or tear-down of the DetNet connections frequently. 157 Mechanisms like IEEE 802.1 Qch, and IEEE 802.1 Qbv which need re- 158 computation whenever new flow are added may be not suitable for this 159 case. In order to deploy DetNet services in scenario (ii). 161 3. Tolerance of time deviation 163 Req 3: Tolerance of a certain level of end-to-end time deviation. 165 Different from the TSN services which are deployed in small-scale 166 local area network, DetNet service targets at large scale 167 implementation. There are a great amount of heterogeneous devices in 168 large scale network. It will be difficult and costly to keep precise 169 synchronization among all devices. It is worthy of have a DetNet 170 system which can keep the bounded latency performance even under an 171 unsynchronized situation.. 173 4. Massive number of deterministic flows 175 Req 4: Fine-grained and scalable resource reservation method. 177 Resource reservation for individual DetNet flows are required in 178 order to maintain per-flow state in the devices along the path. 179 Given a large number of DetNet flows, aggregation of such resource 180 reservation may be necessary at least at the core routers. However, 181 aggregating massive DetNet flows into a tunnel will sacrifice some 182 network resources or accuracy, just like change from DiffServ to 183 IntServ. Certain trade-off needs to be studied carefully to achieve 184 optimal performance. 186 5. Stable jitter with long transmission delay 188 Req 5: Tolerance of transmission latency 190 Large transmission latency is expected in large scale network which 191 may further lead to larger jitter in some mechanisms such as IEEE 192 802.1 Qch. It would be preferred to have a mechanism where the jitter 193 performance does not scale up with the transmission latency. Thus 194 end user can have same bounded latency performance in a P2MP 195 deployment. 197 6. IANA Considerations 199 This document makes no request of IANA. 201 7. Security Considerations 203 This document will not introduce new security problems. 205 8. Acknowledgements 207 TBD. 209 9. Normative References 211 [draft-ietf-detnet-architecture] 212 "DetNet Architecture", . 215 [draft-ietf-detnet-dp-sol] 216 "DetNet Data Plane Encapsulation", 217 . 220 [draft-ietf-detnet-problem-statement] 221 "DetNet Problem Statement", 222 . 225 [draft-ietf-detnet-security] 226 "DetNet Security Considerations", 227 . 230 [draft-ietf-detnet-use-cases] 231 "DetNet Use Cases", . 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 Authors' Addresses 241 Liang Geng 242 China Mobile 243 Beijing 244 China 246 Email: gengliang@chinamobile.com 248 Lei Wang 249 China Mobile 250 Beijing 251 China 253 Email: wangleiyjy@chinamobile.com 255 Li Qiang 256 Huawei Technologies 257 Huawei Campus, No. 156 Beiqing Rd. 258 Beijing 100095 259 China 261 Email: qiangli3@huawei.com