idnits 2.17.1 draft-ietf-detnet-problem-statement-09.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 date (December 18, 2018) is 1954 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-09 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-03 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-19 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet N. Finn 3 Internet-Draft Huawei Technologies Co. Ltd 4 Intended status: Informational P. Thubert 5 Expires: June 21, 2019 Cisco 6 December 18, 2018 8 Deterministic Networking Problem Statement 9 draft-ietf-detnet-problem-statement-09 11 Abstract 13 This paper documents the needs in various industries to establish 14 multi-hop paths for characterized flows with deterministic 15 properties. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 21, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. On Deterministic Networking . . . . . . . . . . . . . . . . . 3 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1. Supported topologies . . . . . . . . . . . . . . . . . . 6 55 3.2. Flow Characterization . . . . . . . . . . . . . . . . . . 6 56 3.3. Centralized Path Computation and Installation . . . . . . 6 57 3.4. Distributed Path Setup . . . . . . . . . . . . . . . . . 7 58 3.5. Duplicated data format . . . . . . . . . . . . . . . . . 8 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Informative References . . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 65 1. Introduction 67 The Deterministic Networking Use Cases [I-D.ietf-detnet-use-cases] 68 document illustrates that beyond the classical case of industrial 69 automation and control systems (IACS), there are in fact multiple 70 industries with strong and yet relatively similar needs for 71 deterministic network services with latency guarantees and ultra-low 72 packet loss. 74 The generalization of the needs for more deterministic networks have 75 led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive 76 Networking (TSN) [IEEE802.1TSNTG] Task Group (TG), with a much- 77 expanded constituency from the industrial and vehicular markets. 79 Along with this expansion, the networks in consideration are becoming 80 larger and structured, requiring deterministic forwarding beyond the 81 LAN boundaries. For instance, IACS segregates the network along the 82 broad lines of the Purdue Enterprise Reference Architecture (PERA) 83 [ISA95], typically using deterministic local area networks for level 84 2 control systems, whereas public infrastructures such as Electricity 85 Automation require deterministic properties over the Wide Area. The 86 realization is now coming that the convergence of IT and Operational 87 Technology (OT) networks requires Layer-3, as well as Layer-2, 88 capabilities. 90 While the initial user base has focused almost entirely on Ethernet 91 physical media and Ethernet-based bridging protocol from several 92 Standards Development Organizations, the need for Layer-3 expressed 93 above, must not be confined to Ethernet and Ethernet-like media. 94 While such media must be encompassed by any useful Deterministic 95 Networking (DetNet) Architecture, cooperation between IETF and other 96 SDOs must not be limited to IEEE or IEEE 802. Furthermore, while the 97 work completed and ongoing in other SDOs, and in IEEE 802 in 98 particular, provide an obvious starting point for a DetNet 99 architecture, we must not assume that these other SDOs' work confines 100 the space in which the DetNet architecture progresses. 102 The properties of deterministic networks will have specific 103 requirements for the use of routed networks to support these 104 applications and a new model must be proposed to integrate 105 determinism in IT technology. The proposed model should enable a 106 fully scheduled operation orchestrated by a central controller, and 107 may support a more distributed operation with probably lesser 108 capabilities. In any fashion, the model should not compromise the 109 ability of a network to keep carrying the sorts of traffic that is 110 already carried today in conjunction with new, more deterministic 111 flows. Forward note: The DetNet Architecture 112 [I-D.ietf-detnet-architecture] is the document produced by the DetNet 113 WG to describe that model. 115 At the time of this writing, the expectation is that once the 116 abstract model is agreed upon, the IETF will specify the signaling 117 elements to be used to establish a path and the tagging elements to 118 be used identify the flows that are to be forwarded along that path. 119 The expectation is also that IETF will specify the necessary 120 protocols, or protocol additions, based on relevant IETF 121 technologies, to implement the selected model. 123 A desirable outcome of the work is the capability to establish a 124 multi-hop path over the IP or MPLS network, for a particular flow 125 with given timing and precise throughput requirements, and carry this 126 particular flow along the multi-hop path with such characteristics as 127 low latency and ultra-low jitter, reordering and/or replication and 128 elimination of packets over non-congruent paths for a higher delivery 129 ratio, and/or zero congestion loss, regardless of the amount of other 130 flows in the network. 132 Depending on the network capabilities and on the current state, 133 requests to establish a path by an end-node or a network management 134 entity may be granted or rejected, an existing path may be moved or 135 removed, and DetNet flows exceeding their contract may face packet 136 declassification and drop. 138 2. On Deterministic Networking 140 The Internet is not the only digital network that has grown 141 dramatically over the last 30-40 years. Video and audio 142 entertainment, and control systems for machinery, manufacturing 143 processes, and vehicles are also ubiquitous, and are now based almost 144 entirely on digital technologies. Over the past 10 years, engineers 145 in these fields have come to realize that significant advantages in 146 both cost and in the ability to accelerate growth can be obtained by 147 basing all of these disparate digital technologies on packet 148 networks. 150 The goals of Deterministic Networking are to enable the migration of 151 applications with critical timing and reliability issues that 152 currently use special-purpose fieldbus technologies (HDMI, CANbus, 153 ProfiBus, etc... even RS-232!) to packet technologies in general, and 154 the Internet Protocol in particular, and to support both these new 155 applications, and existing packet network applications, over the same 156 physical network. In other words, a Deterministic Network is 157 backwards compatible with (capable of transporting) statistically 158 multiplexed traffic while preserving the properties of the accepted 159 deterministic flows. 161 The Deterministic Networking Use Cases [I-D.ietf-detnet-use-cases] 162 document indicates that applications in multiple fields need some or 163 all of a suite of features that includes: 165 1. Time synchronization of all host and network nodes (routers and/ 166 or bridges), accurate to something between 10 nanoseconds and 10 167 microseconds, depending on the application. 169 2. Support for Deterministic packet flows that: 171 * Can be unicast or multicast; 173 * Need absolute guarantees of minimum and maximum latency end- 174 to-end across the network; sometimes a tight jitter is 175 required as well; 177 * Need a packet loss ratio beyond the classical range for a 178 particular medium, in the range of 10^-9 to 10^-12, or better, 179 on Ethernet, and in the order of 10^-5 in Wireless Sensor Mesh 180 Networks; 182 * Can, in total, absorb more than half of the network's 183 available bandwidth (that is, massive over-provisioning is 184 ruled out as a solution); 186 * Cannot suffer throttling, congestion feedback, or any other 187 network-imposed transmission delay, although the flows can be 188 meaningfully characterized either by a fixed, repeating 189 transmission schedule, or by a maximum bandwidth and packet 190 size; 192 3. Multiple methods to schedule, shape, limit, and otherwise control 193 the transmission of critical packets at each hop through the 194 network data plane; 196 4. Robust defenses against misbehaving hosts, routers, or bridges, 197 both in the data and control planes, with guarantees that a 198 critical flow within its guaranteed resources cannot be affected 199 by other flows whatever the pressures on the network - more on 200 the specific threats against DetNet in the DetNet Security 201 Considerations [I-D.ietf-detnet-security] document; 203 5. One or more methods to reserve resources in bridges and routers 204 to carry these flows. 206 Time synchronization techniques need not be addressed by an IETF 207 Working Group; there are a number of standards available for this 208 purpose, including IEEE 1588, IEEE 802.1AS, and more. 210 The multicast, latency, loss ratio, and non-throttling needs are made 211 necessary by the algorithms employed by the applications. They are 212 not simply the transliteration of fieldbus needs to a packet-based 213 fieldbus simulation, but reflect fundamental mathematics of the 214 control of a physical system. 216 With classical forwarding latency- and loss-sensitive packets across 217 a network, interactions among different critical flows introduce 218 fundamental uncertainties in delivery schedules. The details of the 219 queuing, shaping, and scheduling algorithms employed by each bridge 220 or router to control the output sequence on a given port affect the 221 detailed makeup of the output stream, e.g. how finely a given flow's 222 packets are mixed among those of other flows. 224 This, in turn, has a strong effect on the buffer requirements, and 225 hence the latency guarantees deliverable, by the next bridge or 226 router along the path. For this reason, the IEEE 802.1 Time- 227 Sensitive Networking Task Group has defined a new set of queuing, 228 shaping, and scheduling algorithms that enable each bridge or router 229 to compute the exact number of buffers to be allocated for each flow 230 or class of flows. 232 Robustness is a common need for networking protocols, but plays a 233 more important part in real-time control networks, where expensive 234 equipment, and even lives, can be lost due to misbehaving equipment. 236 Reserving resources before packet transmission is the one fundamental 237 shift in the behavior of network applications that is impossible to 238 avoid. In the first place, a network cannot deliver finite latency 239 and practically zero packet loss to an arbitrarily high offered load. 241 Secondly, achieving practically zero packet loss for un-throttled 242 (though bandwidth limited) flows means that bridges and routers have 243 to dedicate buffer resources to specific flows or to classes of 244 flows. The requirements of each reservation have to be translated 245 into the parameters that control each host's, bridge's, and router's 246 queuing, shaping, and scheduling functions and delivered to the 247 hosts, bridges, and routers. 249 3. Problem Statement 251 3.1. Supported topologies 253 In some use cases, the end point which run the application is 254 involved in the deterministic networking operation, for instance by 255 controlling certain aspects of its throughput such as rate or precise 256 time of emission. In that case, the deterministic path is end-to-end 257 from application host to application host. 259 On the other end, the deterministic portion of a path may be a tunnel 260 between an ingress and an egress router. In any case, routers and 261 switches in between should not need to be aware whether the path is 262 end-to-end or a tunnel. 264 While it is clear that DetNet does not aim at setting up 265 deterministic paths over the global Internet, there is still a lack 266 of clarity on the limits of a domain where a deterministic path can 267 be set up. These limits may depend in the technology that is used to 268 set the path up, whether it is centralized or distributed. 270 3.2. Flow Characterization 272 Deterministic forwarding can only apply on flows with well-defined 273 characteristics such as periodicity and burstiness. Before a path 274 can be established to serve them, the expression of those 275 characteristics, and how the network can serve them, for instance in 276 shaping and forwarding operations, must be specified. 278 3.3. Centralized Path Computation and Installation 280 A centralized routing model, such as provided with a Path Computation 281 Element (PCE) (see [RFC4655]), enables global and per-flow 282 optimizations. The model is attractive but a number of issues are 283 left to be solved. In particular: 285 o whether and how the path computation can be installed by 1) an end 286 device or 2) a Network Management entity, 288 o and how the path is set up, either by installing state at each hop 289 with a direct interaction between the forwarding device and the 290 PCE, or along a path by injecting a source-routed request at one 291 end of the path following classical Traffic Engineering (TE) 292 models. 294 To enable a centralized model, DetNet should produce a description of 295 the high level interaction and data models to: 297 o report the topology and device capabilities to the central 298 controller; 300 o establish a direct interface between the centralized PCE to each 301 device under its control in order to enable a vertical signaling 303 o request a path setup for a new flow with particular 304 characteristics over the service interface and control it through 305 its life cycle; 307 o support for life cycle management for a path 308 (instantiate/modify/update/delete) 310 o support for adaptability to cope with various events such as loss 311 of a link, etc... 313 o expose the status of the path to the end devices (UNI interface) 315 o provide additional reliability through redundancy, in particular 316 with packet Packet Replication, Elimination and Ordering Functions 317 (PREOF) where the former may generate an out-of-order delivery 318 that may need to be corrected corrected by the latter; 320 o indicate the flows and packet sequences in-band with the flows, 321 this is needed for flows that require PREOF in order to isolate 322 duplicates and reorder in the end; 324 3.4. Distributed Path Setup 326 Whether a distributed alternative without a PCE can be valuable could 327 be studied as well. Such an alternative could for instance inherit 328 from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows. 329 But the focus of the work should be to deliver the centralized 330 approach first. 332 To enable a RSVP-TE like functionality, the following steps would 333 take place: 335 1. Neighbors and their capabilities are discovered and exposed to 336 compute a path that fits the DetNet constraints, typically of 337 latency, time precision and resource availability. 339 2. A constrained path is calculated with an improved version of 340 Constrained Shortest Path First (CSPF) that is aware of DetNet. 342 3. The path may be installed using a control protocol such as RSVP- 343 TE, associated with flow identification, per-hop behavior such as 344 Packet Replication and Elimination, and blocked resources. In 345 that case, traffic flows can be transported through an MPLS-TE 346 tunnel, using the reserved resources for this flow at each hop. 348 3.5. Duplicated data format 350 In some cases the duplication and elimination of packets over non- 351 congruent paths is required to achieve a sufficiently high delivery 352 ratio to meet application needs. In these cases, a small number of 353 packet formats and supporting protocols are required (preferably, 354 just one) to serialize the packets of a DetNet stream at one point in 355 the network, replicate them at one or more points in the network, and 356 discard duplicates at one or more other points in the network, 357 including perhaps the destination host. Using an existing solution 358 would be preferable to inventing a new one. 360 4. Security Considerations 362 Security in the context of Deterministic Networking has an added 363 dimension; the time of delivery of a packet can be just as important 364 as the contents of the packet, itself. A man-in-the-middle attack, 365 for example, can impose, and then systematically adjust, additional 366 delays into a link, and thus disrupt or subvert a real-time 367 application without having to crack any encryption methods employed. 368 See [RFC7384] for an exploration of this issue in a related context. 370 Typical control networks today rely on complete physical isolation to 371 prevent rogue access to network resources. DetNet enables the 372 virtualization of those networks over a converged IT/OT 373 infrastructure. Doing so, DetNet introduces an additional risk that 374 flows interact and interfere with one another as they share physical 375 resources such as Ethernet trunks and radio spectrum. The 376 requirement is that there is no possible data leak from and into a 377 deterministic flow, and in a more general fashion there is no 378 possible influence whatsoever from the outside on a deterministic 379 flow. The expectation is that physical resources are effectively 380 associated with a given flow at a given point of time. In that 381 model, Time Sharing of physical resources becomes transparent to the 382 individual flows which have no clue whether the resources are used by 383 other flows at other times. 385 The overall security of a deterministic system must cover: 387 o the protection of the signaling protocol 389 o the authentication and authorization of the controlling nodes 390 including plug-and-play participating end systems. 392 o the identification and shaping of the flows 394 o the isolation of flows from leakage and other influences from any 395 activity sharing physical resources. 397 The specific threats against DetNet are further discussed in the 398 DetNet Security Considerations [I-D.ietf-detnet-security] document. 400 5. IANA Considerations 402 This document does not require an action from IANA. 404 6. Acknowledgments 406 The authors wish to thank Lou Berger, Pat Thaler, Jouni Korhonen, 407 Janos Farkas, Stewart Bryant, Andrew Malis, Ethan Grossman, Patrick 408 Wetterwald, Subha Dhesikan, Matthew Miller, Erik Nordmark, George 409 Swallow, Rodney Cummings, Ines Robles, Shwetha Bhandari, Rudy Klecka, 410 Anca Zamfir, David Black, Thomas Watteyne, Shitanshu Shah, Kiran 411 Makhijani, Craig Gunther, Warren Kumari, Wilfried Steiner, Marcel 412 Kiessling, Karl Weber, Alissa Cooper, and Benjamin Kaduk for their 413 various contributions to this work. 415 7. Informative References 417 [I-D.ietf-detnet-architecture] 418 Finn, N., Thubert, P., Varga, B., and J. Farkas, 419 "Deterministic Networking Architecture", draft-ietf- 420 detnet-architecture-09 (work in progress), October 2018. 422 [I-D.ietf-detnet-security] 423 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 424 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 425 Networking (DetNet) Security Considerations", draft-ietf- 426 detnet-security-03 (work in progress), October 2018. 428 [I-D.ietf-detnet-use-cases] 429 Grossman, E., "Deterministic Networking Use Cases", draft- 430 ietf-detnet-use-cases-19 (work in progress), October 2018. 432 [IEEE802.1TSNTG] 433 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 434 Networks Task Group", 2013, 435 . 437 [ISA95] ANSI/ISA, "Enterprise-Control System Integration Part 1: 438 Models and Terminology", 2000, 439 . 441 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 442 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 443 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 444 . 446 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 447 Element (PCE)-Based Architecture", RFC 4655, 448 DOI 10.17487/RFC4655, August 2006, 449 . 451 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 452 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 453 October 2014, . 455 Authors' Addresses 457 Norman Finn 458 Huawei Technologies Co. Ltd 459 3755 Avocado Blvd. 460 PMB 436 461 La Mesa, California 91941 462 US 464 Phone: +1 925 980 6430 465 Email: norman.finn@mail01.huawei.com 466 Pascal Thubert 467 Cisco Systems 468 Village d'Entreprises Green Side 469 400, Avenue de Roumanille 470 Batiment T3 471 Biot - Sophia Antipolis 06410 472 FRANCE 474 Phone: +33 497 232 634 475 Email: pthubert@cisco.com