idnits 2.17.1 draft-finn-detnet-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 : ---------------------------------------------------------------------------- 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 (October 23, 2014) is 3474 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) == Unused Reference: 'HART' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1AS-2011' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1BA-2011' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q-2011' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qat-2010' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qav' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1TSNTG' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'IEEE802154' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 481, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-03 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-02 == Outdated reference: A later version (-04) exists of draft-svshah-tsvwg-deterministic-forwarding-02 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 detnet N. Finn 3 Internet-Draft P. Thubert 4 Intended status: Standards Track Cisco 5 Expires: April 26, 2015 October 23, 2014 7 Deterministic Networking Problem Statement 8 draft-finn-detnet-problem-statement-01 10 Abstract 12 This paper documents the needs in various industries to establish 13 multi-hop paths for characterized flows with deterministic properties 14 . 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 26, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. On Deterministic Networking . . . . . . . . . . . . . . . . . 4 53 4. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 6 55 4.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1. Flow Characterization . . . . . . . . . . . . . . . . . . 7 58 5.2. Centralized Path Computation and Installation . . . . . . 7 59 5.3. Distributed Path Setup . . . . . . . . . . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 Operational Technology (OT) refers to industrial networks that are 71 typically used for monitoring systems and supporting control loops, 72 as well as movement detection systems for use in process control 73 (i.e., process manufacturing) and factory automation (i.e., discrete 74 manufacturing). Due to its different goals, OT has evolved in 75 parallel but in a manner that is radically different from IT/ICT, 76 focusing on highly secure, reliable and deterministic networks, with 77 limited scalability over a bounded area. 79 The convergence of IT and OT technologies, also called the Industrial 80 Internet, represents a major evolution for both sides. The work has 81 already started; in particular, the industrial automation space has 82 been developing a number of Ethernet-based replacements for existing 83 digital control systems, often not packet-based (fieldbus 84 technologies). 86 These replacements are meant to provide similar behavior as the 87 incumbent protocols, and their common focus is to transport a fully 88 characterized flow over a well-controlled environment (i.e., a 89 factory floor), with a bounded latency, extraordinarily low frame 90 loss, and a very narrow jitter. Examples of such protocols include 91 PROFINET, ODVA Ethernet/IP, and EtherCAT. 93 In parallel, the need for determinism in professional and home audio/ 94 video markets drove the formation of the Audio/Video Bridging (AVB) 95 standards effort of IEEE 802.1. With the explosion of demand for 96 connectivity and multimedia in transportation in general, the 97 Ethernet AVB technology has become one of the hottest topics, in 98 particular in the automotive connectivity. It is finding application 99 in all elements of the vehicle from head units, to rear seat 100 entertainment modules, to amplifiers and camera modules. While aimed 101 at less critical applications than some industrial networks, AVB 102 networks share the requirement for extremely low packet loss rates 103 and guaranteed finite latency and jitter. 105 Other instances of in-vehicle deterministic networks have arisen as 106 well for control networks in cars, trains and buses, as well as 107 avionics, with, for instance, the mission-critical "Avionics Full- 108 Duplex Switched Ethernet" (AFDX) that was designed as part of the 109 ARINC 664 standards. Existing automotive control networks such as 110 the LIN, CAN and FlexRay standards were not designed to cover these 111 increasing demands in terms of bandwidth and scalability that we see 112 with various kinds of Driver Assistance Systems (DAS) and new 113 multiplexing technologies based on Ethernet are now getting traction. 115 The generalization of the needs for more deterministic networks have 116 led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive 117 Networking (TSN) Task Group (TG), with a much-expanded constituency 118 from the industrial and vehicular markets. Along with this 119 expansion, the networks in consideration are becoming larger and 120 structured, requiring deterministic forwarding beyond the LAN 121 boundaries. For instance, Industrial Automation segregates the 122 network along the broad lines of the Purdue Enterprise Reference 123 Architecture (PERA), using different technologies at each level, and 124 public infrastructures such as Electricity Automation require 125 deterministic properties over the Wide Area. The realization is now 126 coming that the convergence of IT and OT networks requires Layer-3, 127 as well as Layer-2, capabilities. 129 In order to serve this extended requirement, the IETF and the IEEE 130 must collaborate and define an abstract model that can be applicable 131 both at Layer-2 and Layer-3, and along segments of different 132 technologies. With this new work, a path may span, for instance, 133 across a (limited) number of 802.1 bridges and then a (limited) 134 number of IP routers. In that example, the IEEE802.1 bridges may be 135 operating at Layer-2 over Ethernet whereas the IP routers may be 136 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the 137 IEEE802.15.4e MAC. 139 The proposed model should enable a fully scheduled operation 140 orchestrated by a central controller, as well as a more distributed 141 operation with probably lesser capabilities. In any fashion, the 142 model should not compromise the ability of a network to keep carrying 143 the sorts of traffic that is already carried today. 145 Once the abstract model is agreed upon, the IETF will need to specify 146 the signaling elements to be used to establish a path and the tagging 147 elements to be used identify the flows that are to be forwarded along 148 that path. The IETF will also need to specify the necessary 149 protocols, or protocol additions, based on relevant IETF technologies 150 such as PCE, MPLS and 6TiSCH, to implement the selected model. As a 151 result of this work, it will be possible to establish a multi-hop 152 path over the IP network, for a particular flow with precise timing 153 and throughput requirements, and carry this particular flow along the 154 multi-hop path with such characteristics as low latency and ultra-low 155 jitter, duplication and elimination of packets over non-congruent 156 paths for a higher delivery ratio, and/or zero congestion loss. 157 Depending on the network capabilities and on the current state, 158 requests to establish a path by an end-node or a network management 159 entity may be granted or rejected, and an existing path may be moved 160 or removed. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 3. On Deterministic Networking 170 The Internet is not the only digital network that has grown 171 dramatically over the last 30-40 years. Video and audio 172 entertainment, and control systems for machinery, manufacturing 173 processes, and vehicles are also ubiquitous, and are now based almost 174 entirely on digital technologies. Over the past 10 years, engineers 175 in these fields have come to realize that significant advantages in 176 both cost and in the ability to accelerate growth can be obtained by 177 basing all of these disparate digital technologies on packet 178 networks. 180 The goals of Deterministic Networking are to enable the migration of 181 applications that use special-purpose fieldbus technologies (HDMI, 182 CANbus, ProfiBus, etc...even RS-232!) to packet technologies in 183 general, and the Internet Protocol in particular, and to support both 184 these new applications, and existing packet network applications, 185 over the same physical network. 187 Considerable experience ( [ODVA],[AVnu], [Profinet],[HSR-PRP], 188 etc...) has shown that these applications need a some or all of a 189 suite of features that includes: 191 1. Time synchronization of all host and network nodes (routers and/ 192 or bridges), accurate to something between 10 nanoseconds and 10 193 microseconds, depending on the application. 195 2. Support for critical packet flows that: 197 * Can be unicast or multicast; 199 * Need absolute guarantees of minimum and maximum latency end- 200 to-end across the network; 202 * Need a packet loss ratio in the range of 1.0e-9 to 1.0e-12, or 203 better; 205 * Can, in total, absorb more than half of the network's 206 available bandwidth (that is, over-provisioning is ruled out 207 as a solution); 209 * Cannot suffer throttling, congestion feedback, or any other 210 network-imposed transmission delay, although the flows can be 211 meaningfully characterized either by a fixed, repeating 212 transmission schedule, or by a maximum bandwidth and packet 213 size. 215 3. Multiple methods to schedule, shape, limit, and otherwise control 216 the transmission of critical packets at each hop through the 217 network data plane. 219 4. Robust defenses against misbehaving hosts, routers, or bridges, 220 both in the data and control planes. 222 5. One or more methods to reserve resources in bridges and routers 223 to carry these flows. 225 Time synchronization techniques need not be addressed by an IETF 226 Working Group; there are a number of standards available for this 227 purpose, including IEEE 1588, IEEE 802.1AS, and more. 229 The multicast, latency, loss ratio, and non-throttling needs are made 230 necessary by the algorithms employed by the applications. They are 231 not simply the transliteration of fieldbus needs to a packet-based 232 fieldbus simulation, but reflect fundamental mathematics of the 233 control of a physical system. 235 When forwarding latency- and loss-sensitive packets across a network, 236 interactions among different critical flows introduce fundamental 237 uncertainties in delivery schedules. The details of the queuing, 238 shaping, and scheduling algorithms employed by each bridge or router 239 to control the output sequence on a given port affect the detailed 240 makeup of the output stream, e.g. how finely a given flow's packets 241 are mixed among those of other flows. 243 This, in turn, has a strong effect on the buffer requirements, and 244 hence the latency guarantees deliverable, by the next bridge or 245 router along the path. For this reason, the IEEE 802.1 Time- 246 Sensitive Networking Task Group has defined a set of queuing, 247 shaping, and scheduling algorithms (:::reference to section, below 248 :::) that enable each bridge or router to compute the exact number of 249 buffers to be allocated for each flow or class of flows. The present 250 authors assume that these techniques will be used by the DetNet 251 Working Group. 253 Robustness is a common need for networking protocols, but plays a 254 more important part in real-time control networks, where expensive 255 equipment, and even lives, can be lost due to misbehaving equipment. 257 Reserving resources before packet transmission is the one fundamental 258 shift in the behavior of network applications that is impossible to 259 avoid. In the first place, a network cannot deliver finite latency 260 and practically zero packet loss to an arbitrarily high offered load. 261 Secondly, achieving practically zero packet loss for unthrottled 262 (though bandwidth limited) flows means that bridges and routers have 263 to dedicate buffer resources to specific flows or to classes of 264 flows. The requirements of each reservation have to be translated 265 into the parameters that control each host's, bridge's, and router's 266 queuing, shaping, and scheduling functions and delivered to the 267 hosts, bridges, and routers. 269 4. Related IETF work 271 4.1. Deterministic PHB 273 [I-D.svshah-tsvwg-deterministic-forwarding] defines a Differentiated 274 Services Per-Hop-Behavior (PHB) Group called Deterministic Forwarding 275 (DF). The document describes the purpose and semantics of this PHB. 276 It also describes creation and forwarding treatment of the service 277 class. The document also describes how the code-point can be mapped 278 into one of the aggregated Diffserv service classes [RFC5127]. 280 4.2. 6TiSCH 282 Industrial process control already leverages deterministic wireless 283 Low power and Lossy Networks (LLNs) to interconnect critical 284 resource-constrained devices and form wireless mesh networks, with 285 standards such as [ISA100.11a] and [WirelessHART]. 287 These standards rely on variations of the [IEEE802154e] timeSlotted 288 Channel Hopping (TSCH) [I-D.ietf-6tisch-tsch] Medium Access Control 289 (MAC), and a form of centralized Path Computation Element (PCE), to 290 deliver deterministic capabilities. 292 The TSCH MAC benefits include high reliability against interference, 293 low power consumption on characterized flows, and Traffic Engineering 294 capabilities. Typical applications are open and closed control 295 loops, as well as supervisory control flows and management. 297 The 6TiSCH Working Group focuses only on the TSCH mode of the 298 IEEE802.15.4e standard. The WG currently defines a framework for 299 managing the TSCH schedule. Future work will standardize 300 deterministic operations over so-called tracks as described in 301 [I-D.ietf-6tisch-architecture]. Tracks are an instance of a 302 deterministic path, and the detnet work is a prerequisite to specify 303 track operations and serve process control applications. 305 [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section 306 2.1.3. and next discusses application-layer paradigms, such as 307 Source-sink (SS) that is a Multipeer to Multipeer (MP2MP) model that 308 is primarily used for alarms and alerts, Publish-subscribe (PS, or 309 pub/sub) that is typically used for sensor data, as well as Peer-to- 310 peer (P2P) and Peer-to-multipeer (P2MP) communications. Additional 311 considerations on Duocast and its N-cast generalization are also 312 provided for improved reliability. 314 5. Problem Statement 316 5.1. Flow Characterization 318 Deterministic forwarding can only apply on flows with well-defined 319 characteristics such as periodicity and burstiness. Before a path 320 can be established to serve them, the expression of those 321 characteristics, and how the network can serve them, for instance in 322 shaping and forwarding operations, must be specified. 324 5.2. Centralized Path Computation and Installation 326 A centralized routing model, such as provided with a PCE, enables 327 global and per-flow optimizations. The model is attractive but a 328 number of issues are left to be solved. In particular: 330 o whether and how the path computation can be installed by 1) an end 331 device or 2) a Network Management entity, 333 o and how the path is set up, either by installing state at each hop 334 with a direct interaction between the forwarding device and the 335 PCE, or along a path by injecting a source-routed request at one 336 end of the path. 338 5.3. Distributed Path Setup 340 Whether a distributed alternative without a PCE can be valuable 341 should be studied as well. Such an alternative could for instance 342 inherit from the Resource ReSerVation Protocol [RFC5127] (RSVP) 343 flows. 345 6. Security Considerations 347 Security in the context of Deterministic Networking has an added 348 dimension; the time of delivery of a packet can be just as important 349 as the contents of the packet, itself. A man-in-the-middle attack, 350 for example, can impose, and then systematically adjust, additional 351 delays into a link, and thus disrupt or subvert a real-time 352 application without having to crack any encryption methods employed. 353 See [RFC7384] for an exploration of this issue in a related context. 355 Security must cover: 357 o the protection of the signaling protocol 359 o the authentication and authorisation of the controlling nodes 361 o the identification and shaping of the flows 363 7. IANA Considerations 365 This document does not require an action from IANA. 367 8. Acknowledgements 369 The authors wish to thank Jouni Korhonen, Erik Nordmark, George 370 Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne, 371 Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried Steiner, 372 Marcel Kiessling, Karl Weber, Ethan Grossman and Pat Thaler, for 373 their various contribution with this work. 375 9. References 377 9.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 9.2. Informative References 384 [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and 385 certifies devices for interoperability, providing a simple 386 and reliable networking solution for AV network 387 implementation based on the Audio Video Bridging (AVB) 388 standards.", . 390 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 391 a group of specifications for industrial process and 392 control devices administered by the HART Foundation", . 394 [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a 395 further development of the PRP approach, although HSR 396 functions primarily as a protocol for creating media 397 redundancy while PRP, as described in the previous 398 section, creates network redundancy. PRP and HSR are both 399 described in the IEC 62439 3 standard.", . 401 [I-D.ietf-6tisch-architecture] 402 Thubert, P., Watteyne, T., and R. Assimiti, "An 403 Architecture for IPv6 over the TSCH mode of IEEE 404 802.15.4e", draft-ietf-6tisch-architecture-03 (work in 405 progress), July 2014. 407 [I-D.ietf-6tisch-tsch] 408 Watteyne, T., Palattella, M., and L. Grieco, "Using 409 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 410 Statement and Goals", draft-ietf-6tisch-tsch-02 (work in 411 progress), October 2014. 413 [I-D.ietf-roll-rpl-industrial-applicability] 414 Phinney, T., Thubert, P., and R. Assimiti, "RPL 415 applicability in industrial networks", draft-ietf-roll- 416 rpl-industrial-applicability-02 (work in progress), 417 October 2013. 419 [I-D.svshah-tsvwg-deterministic-forwarding] 420 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 421 draft-svshah-tsvwg-deterministic-forwarding-02 (work in 422 progress), September 2014. 424 [IEEE802.1AS-2011] 425 IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 426 2011, . 429 [IEEE802.1BA-2011] 430 IEEE, "AVB Systems (IEEE 802.1BA-2011)", 2011, 431 . 434 [IEEE802.1Q-2011] 435 IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, 436 . 439 [IEEE802.1Qat-2010] 440 IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 441 2010, . 444 [IEEE802.1Qav] 445 IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, 446 . 449 [IEEE802.1TSNTG] 450 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 451 Networks Task Group", 2013, 452 . 454 [IEEE802154] 455 IEEE standard for Information Technology, "IEEE std. 456 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 457 and Physical Layer (PHY) Specifications for Low-Rate 458 Wireless Personal Area Networks", June 2011. 460 [IEEE802154e] 461 IEEE standard for Information Technology, "IEEE std. 462 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 463 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 464 2012. 466 [ISA100.11a] 467 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 468 also IEC 62734", 2011, < http://www.isa100wci.org/en- 469 US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- 470 WEB-ETSI.aspx>. 472 [ODVA] http://www.odva.org/, "The organization that supports 473 network technologies built on the Common Industrial 474 Protocol (CIP) including EtherNet/IP.", . 476 [Profinet] 477 http://us.profinet.com/technology/profinet/, "PROFINET is 478 a standard for industrial networking in automation.", 479 . 481 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 482 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 483 Functional Specification", RFC 2205, September 1997. 485 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 486 Diffserv Service Classes", RFC 5127, February 2008. 488 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 489 "Industrial Routing Requirements in Low-Power and Lossy 490 Networks", RFC 5673, October 2009. 492 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 493 Packet Switched Networks", RFC 7384, October 2014. 495 [WirelessHART] 496 www.hartcomm.org, "Industrial Communication Networks - 497 Wireless Communication Network and Communication Profiles 498 - WirelessHART - IEC 62591", 2010. 500 Authors' Addresses 502 Norm Finn 503 Cisco Systems 504 510 McCarthy Blvd 505 SJ-24 506 Milpitas, California 95035 507 USA 509 Phone: +1 925 980 6430 510 Email: nfinn@cisco.com 512 Pascal Thubert 513 Cisco Systems 514 Village d'Entreprises Green Side 515 400, Avenue de Roumanille 516 Batiment T3 517 Biot - Sophia Antipolis 06410 518 FRANCE 520 Phone: +33 4 97 23 26 34 521 Email: pthubert@cisco.com