idnits 2.17.1 draft-geng-detnet-requirements-bounded-latency-02.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 (June 3, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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 China Mobile 4 Intended status: Informational P. Willis 5 Expires: December 5, 2019 BT 6 S. Homma 7 NTT 8 L. Qiang 9 Huawei 10 June 3, 2019 12 Requirements of Layer 3 Deterministic Latency Service 13 draft-geng-detnet-requirements-bounded-latency-02 15 Abstract 17 This document specifies some technical, operational and management 18 requirements of deploying deterministic latency service on layer 3 19 networks from the perspective of the service provider. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 5, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 58 2. Technical Requirements . . . . . . . . . . . . . . . . . . . 3 59 2.1. Requirement 1: Must support the dynamic creation, 60 modification and deletion of deterministic services . . . 3 61 2.2. Requirement 2: Should tolerate a certain degree of time 62 variance . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2.1. Sub-requirement 2.1: Should support asynchronous 64 clocks across domains . . . . . . . . . . . . . . . . 4 65 2.2.2. Sub-requirement 2.2: Should tolerate clock jitter & 66 wander within a clock synchronous domain . . . . . . 4 67 2.3. Requirement 3: Must support Inter-Continental propagation 68 delay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Operational and Management Requirements . . . . . . . . . . . 6 70 3.1. Requirement 4: Should have self-monitoring capability . . 6 71 3.2. Requirement 5: Should be robust against denial of service 72 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. Requirement 6: Must tolerate failures of links or nodes 74 and topology changes . . . . . . . . . . . . . . . . . . 7 75 3.4. Requirement 7: Must be scalable . . . . . . . . . . . . . 7 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 DetNet is chartered to provide bounds on latency, jitter (delay 85 variation) and packet loss [draft-ietf-detnet-problem-statement]. 86 Where latency and jitter are two closely related performance 87 characteristics, this document refers to bounded latency and bounded 88 jitter collectively as deterministic latency. 90 This document does not intend to define any specific mechanism, but 91 specifies some technical, operational and management requirements 92 that must be considered when deploying deterministic latency service 93 at layer 3. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119][RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 1.2. Terminology & Abbreviations 105 This document uses the terminology defined in 106 [draft-ietf-detnet-architecture]. 108 TSN: Time Sensitive Network 110 2. Technical Requirements 112 2.1. Requirement 1: Must support the dynamic creation, modification and 113 deletion of deterministic services 115 There are at least two modes to provide deterministic service over an 116 operator's network: 1) deterministic VPN; 2) point-to-point 117 deterministic tunnel. No matter in which mode, the layer 3 118 deterministic latency mechanisms must be able to support the dynamic 119 creation, modification and deletion of deterministic services without 120 affecting any deterministic services that are already running in the 121 network. 123 In a local area network such as a factory, the information about when 124 a deterministic service will start, how long the service will last, 125 can be known in advance, or can even be planned. Based on this 126 information, the local area network can adopt a global programming 127 mechanism to calculate the accurate processing behaviors for each 128 device, and achieve a global optimal performance. However, such 129 global programming mechanisms are unsuitable for service providers' 130 networks. Many deterministic applications are expected to running on 131 a service provider's network simultaneously. Different deterministic 132 applications may have different lifecycles and SLA requirements, 133 hence the network state changes dynamically. If a mechanism relies 134 on a stable network state for global computing, any change in network 135 state (e.g., new application starts, or an application finishes, or 136 SLA requirement changes) will lead to re-computing, even worse if all 137 devices need to stop work and install the recomputed results, then 138 this mechanism is hard to be deployed on service provider's network. 140 2.2. Requirement 2: Should tolerate a certain degree of time variance 142 2.2.1. Sub-requirement 2.1: Should support asynchronous clocks across 143 domains 145 One of DetNet's objectives is to stitch TSN islands together. All 146 devices inside a TSN domain are time-synchronized, and most of TSN 147 technologies rely on precise time synchronization. However, 148 different TSN islands may have different clocks which are not 149 synchronized as shown in Figure 1, where the time difference of two 150 TSN domain is D. DetNet needs to connect these two TSN domains 151 together and provide end-to-end deterministic latency service. The 152 mechanism adopted by DetNet should be able to support the interaction 153 across time domains by using a fine controlled buffer (the time 154 difference 'D' may be us-level) to absorb the time difference, or 155 relying on the mechanism itself to implement cross domain time 156 mapping. 158 +--------------+ +--------------+ 159 | | DetNet Connection | | 160 | TSN Domain I +-----------------------------+ TSN Domain II| 161 | | | | 162 +--------------+ +--------------+ 164 | | | | | 165 Clock of TSN +--------+--------+--------+--------+ 166 Domain I = 167 = 168 = | | | | | 169 Clock of TSN = +--------+--------+--------+--------+ 170 Domain II = = 171 =<==D==>= 172 = = 174 Figure 1: TSN islands interconnecting 176 2.2.2. Sub-requirement 2.2: Should tolerate clock jitter & wander 177 within a clock synchronous domain 179 DetNet domain itself can be time synchronous or asynchronous, 180 depending on the technology selection of different operators. Even 181 within a time synchronous domain, the synchronized clocks may also 182 experience jitter & wander, the mechanisms adopted by DetNet should 183 be able to tolerate a certain degree of clock jitter & wander. 185 2.3. Requirement 3: Must support Inter-Continental propagation delay 187 In contrast to Layer 2 TSN that is deployed on a LAN [IEEE-TSN], 188 DetNet is expected to be deployed in a larger scale carrier networks 189 that have long link propagation delay which means that DetNet must 190 work on network links that have inter-continental propagation delays. 191 Long link propagation delay can cause some troubles to cyclic 192 forwarding type mechanisms. In order to guarantee deterministic 193 latency, cyclic forwarding type mechanisms usually require a packet 194 be sent out (or received) at a particular cycle, rather than be sent 195 out (or received) randomly. There is a mapping between the sending 196 cycle of upstream node and the receiving cycle of downstream node. 197 In a local area network that with short link propagation delay, the 198 cycle mapping relationship could be very simple. 200 As an example shown in Figure 2, where the length of a cycle is 10 201 us, and the sending cycle of upstream node X and the receiving cycle 202 of downstream node Y correspond to the same period of time (e.g., 203 0~10 us). Packets sent from X at sending cycle will arrive at 204 downstream node Y at receiving cycle, and the link propagation delay 205 between X and Y is smaller than the length of a cycle (i.e., 10 us). 207 Suppose a large scale network wants to keep using this simple cycle 208 mapping relationship, however the link distance between two nodes is 209 longer. Moreover, a downstream node may have many upstream nodes 210 each with different link propagation delays (e.g., 9 us, 10 us, 11 211 us, 15 us, 20 us). In order to absorb the longest link propagation 212 delay, then the length of cycle must be set to at least 20 us. 213 However since packet's arrival time varies within the receiving 214 cycle, larger cycle length means larger delay variance. 216 Upstream Node X |sending cycle | | 217 +--"------------+------------+ 218 = "\ = = 219 = " \ = = 220 = " \ = = 221 = " \ = = 222 = " V = = 223 Downstream Node Y |receiving cycle| | 224 +--"----"-------+----\-------+ 225 = " " = \ = 226 = " " = V resent out 227 = " " = = 228 Time Line -=--"----"-------=------------=-----> 229 (in us) 0 Link 10 20 230 Propagation 231 Delay 233 Figure 2: An example of limited link 235 3. Operational and Management Requirements 237 [Authors note: more explanations for each requirement need to be 238 added in later versions.] 240 3.1. Requirement 4: Should have self-monitoring capability 242 Both network operators and end-users need to be able to measure if 243 the deterministic latency service is working correctly and meeting 244 its SLA. Once the monitored results exceed the expected bounds, 245 network operators and end-users should be notified, and some service 246 protection mechanisms should also be triggered accordingly. In 247 addition, network operators can input the collected results into a 248 reporting system and produce the latency (and jitter) distribution 249 over a period of time, which would be helpful for operators in 250 understanding their networks performance. 252 However, such fine-granularity monitoring is costly. Hence although 253 the self-monitoring is an important capability to both operators and 254 customers, it is not recommended as a mandatory requirement until the 255 use cases are clear. 257 3.2. Requirement 5: Should be robust against denial of service attacks 259 To protect the services requiring deterministic latency, the 260 mechanisms implemented by DetNet should be robust to denial of 261 service attacks. This includes robustness against attacks on the 262 mechanisms to generate clock synchronization. 263 [draft-ietf-detnet-architecture] has discussed using the traffic 264 admission control at the ingress or through the fault mitigation 265 methods, to prevent (or mitigate) the excess traffic caused by 266 malicious or malfunction devices. DetNet also considers using 267 authentication and authorization to mitigate man-in-the middle 268 attacks 270 3.3. Requirement 6: Must tolerate failures of links or nodes and 271 topology changes 273 A step change in latency due to a single network topology change is 274 inevitable. However if the topology keeps changing many times, then 275 DetNet may not deliver on its SLA. The topology changes alone may 276 not be sufficient on a traditional IP network to raise any alarms, 277 but the mechanism's self-monitoring should detect this, and keep 278 working in flapping network topologies. 280 3.4. Requirement 7: Must be scalable 282 Further to the requirement to work on inter-continental links, the 283 deterministic latency forwarding mechanisms must scale to networks of 284 significant size. The number of DetNet devices and flows in a 285 network will be very dependent on the use case. A simple use case to 286 understand is ultra-low-latency (public) 5G transport networks, which 287 would require DetNet extend to every 5G base station. For some 288 network operators, their network may need to connect to ~100 K base 289 stations (serving multiple MNOs'), and this number will only increase 290 with 5G. If each ultra-low-latency slice or MNO is treated as a 291 separate deterministic latency traffic flow (or tunnel), then even if 292 each base station has a limited number of ultra-low latency slices or 293 MNOs (e.g. ~10), there will still be a lot of, ~1M, deterministic 294 latency traffic flows on one network simultaneously. 296 [Authors note: Req. 1 and Req. 3 also have some discussions relevant 297 to scalability. Need more comments and suggestions to help 298 reorganize the contents.] 300 4. IANA Considerations 302 This document makes no request of IANA. 304 5. Security Considerations 306 This document will not introduce new security problems. 308 6. Acknowledgements 310 The Authors would like to thank David Black, Stewart Bryant for their 311 review, suggestion and comments to this document. 313 7. Normative References 315 [draft-ietf-detnet-architecture] 316 "DetNet Architecture", . 319 [draft-ietf-detnet-problem-statement] 320 "DetNet Problem Statement", 321 . 324 [IEEE-TSN] 325 "IEEE TSN Task Group", 326 . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 335 May 2017, . 337 Authors' Addresses 339 Liang Geng 340 China Mobile 341 Beijing 342 China 344 Email: gengliang@chinamobile.com 346 Peter Willis 347 BT 348 BT Adastral Park 349 Ipswich IP5 3RE 350 UK 352 Email: peter.j.willis@bt.com 353 Shunsuke Homma 354 NTT 355 Tokyo 356 Japan 358 Email: shunsuke.homma.fp@hco.ntt.co.jp 360 Li Qiang 361 Huawei 362 Huawei Campus, No. 156 Beiqing Rd. 363 Beijing 100095 364 China 366 Email: qiangli3@huawei.com