idnits 2.17.1 draft-finn-detnet-problem-statement-03.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 11, 2015) is 3236 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 593, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1AS-2011' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q-2011' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qat-2010' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qav' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'IEEE802154e' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 688, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-gunther-detnet-proaudio-req (ref. 'I-D.gunther-detnet-proaudio-req') ** Downref: Normative reference to an Informational draft: draft-korhonen-detnet-telreq (ref. 'I-D.korhonen-detnet-telreq') == Outdated reference: A later version (-01) exists of draft-thubert-6tisch-4detnet-00 ** Downref: Normative reference to an Informational draft: draft-thubert-6tisch-4detnet (ref. 'I-D.thubert-6tisch-4detnet') == Outdated reference: A later version (-02) exists of draft-wetterwald-detnet-utilities-reqs-01 ** Downref: Normative reference to an Informational draft: draft-wetterwald-detnet-utilities-reqs (ref. 'I-D.wetterwald-detnet-utilities-reqs') == Outdated reference: A later version (-08) exists of draft-finn-detnet-architecture-01 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-08 == Outdated reference: A later version (-04) exists of draft-svshah-tsvwg-deterministic-forwarding-03 Summary: 4 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: December 13, 2015 June 11, 2015 7 Deterministic Networking Problem Statement 8 draft-finn-detnet-problem-statement-03 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 December 13, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. On Deterministic Networking . . . . . . . . . . . . . . . . . 5 53 4. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 7 54 4.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 7 55 4.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Related work in other standards organizations . . . . . . . . 8 57 5.1. Bridged solutions . . . . . . . . . . . . . . . . . . . . 8 58 5.2. Queuing and shaping . . . . . . . . . . . . . . . . . . . 8 59 6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 60 6.1. DetNet architecture . . . . . . . . . . . . . . . . . . . 9 61 6.2. Flow Characterization . . . . . . . . . . . . . . . . . . 11 62 6.3. Centralized Path Computation and Installation . . . . . . 11 63 6.4. Distributed Path Setup . . . . . . . . . . . . . . . . . 11 64 6.5. Duplicated data format . . . . . . . . . . . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 10.2. Informative References . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 73 1. Introduction 75 Operational Technology (OT) refers to industrial networks that are 76 specifically deployed in order to monitor production systems and 77 support control loops and movement detection operations for process 78 control (i.e., continuous manufacturing) and factory automation 79 (i.e., discrete manufacturing), as well as protection systems used in 80 power distribution automation (the SmartGrid). Due to its different 81 goals, OT has evolved in parallel but in a manner that is radically 82 different from Information Technology/Information and Communications 83 Technology (IT/ICT), focusing on highly secure, reliable and 84 deterministic networks, with limited scalability over a bounded and 85 closed area. 87 In OT environments, deterministic networks are characterized as 88 providing a guaranteed bandwidth with extremely low packet loss 89 rates, bounded latency, and low jitter. 91 The convergence of IT and OT technologies, also called the Industrial 92 Internet, represents a major evolution for both sides. For IT, it 93 means a new level of Quality of Service whereby the transfer of 94 packets is completely controlled and repeatable, different flows are 95 perfectly isolated from one another, and packet loss and system 96 downtimes are reduced drastically; for OT, it means sharing IT 97 resources between deterministic and stochastic flows in order to 98 retrieve vasts amounts of so-far unmeasured data and enable 99 additional optimizations. 101 The work has already started; in particular, the industrial 102 automation space has been developing a number of Ethernet-based 103 replacements for existing digital control systems (DCS), often not 104 packet-based (fieldbus technologies). These replacements are meant 105 to provide similar behavior as the incumbent protocols, and their 106 common focus is to transport a fully characterized flow over a well- 107 controlled environment (i.e., a factory floor), with a bounded 108 latency, extraordinarily low frame loss, and a very narrow jitter. 109 Examples of such protocols include PROFINET, ODVA Ethernet/IP, and 110 EtherCAT. 112 As an example, Industrial Automation segregates the network along the 113 broad lines of the Purdue Enterprise Reference Architecture (PERA), 114 using different technologies at each level, and public 115 infrastructures such as the power distribution grid require 116 deterministic properties over the Wide Area. To fully serve an 117 industrial application between a wireless sensor and a virtualized 118 control system operating from the carpeted floor, a deterministic 119 path may span, for instance, across a (limited) number of 802.1 120 bridges and then a (limited) number of IP routers. In that example, 121 the IEEE802.1 bridges may be operating at Layer-2 over Ethernet 122 whereas the IP routers may be 6TiSCH [TiSCH] nodes operating at 123 Layer-2 and/or Layer-3 over the IEEE802.15.4 MAC. 125 In parallel, the need for determinism in professional and home audio/ 126 video markets drove the formation of the Audio/Video Bridging (AVB) 127 standards efforts in IEEE 802.1. With the demand for connectivity 128 and multimedia in transportation, AVB is being evaluated for 129 application in vehicle head units, rear seat entertainment modules, 130 amplifiers, camera modules, and engine control systems. Automotive 131 AVB networks share the OT requirements for deterministic networks 132 characteristics. 134 Other instances of in-vehicle deterministic networks have arisen as 135 well for control networks in cars, trains and buses, as well as 136 avionics, with, for instance, the mission-critical "Avionics Full- 137 Duplex Switched Ethernet" (AFDX) that was designed as part of the 138 ARINC 664 standards. Existing automotive control networks such as 139 the LIN, CAN and FlexRay standards were not designed to cover the 140 increasing demands in terms of bandwidth and scalability that we see 141 with various kinds of Driver Assistance Systems (DAS); it results 142 that new multiplexing technologies based on Ethernet are now getting 143 traction. 145 Other industries where strong needs for deterministic networks are 146 now emerging include: radio access networks 147 [I-D.korhonen-detnet-telreq], the SmartGrid 148 [I-D.wetterwald-detnet-utilities-reqs], and ProAudio networks 149 [I-D.gunther-detnet-proaudio-req]. 151 This wider application scope for deterministic networks has led to 152 the IEEE802.1 AVB Task Group becoming the Time-Sensitive Networking 153 (TSN) Task Group (TG) [IEEE802.1TSNTG], additionally covering 154 industrial and vehicular applications. 156 The networks in consideration are now extending beyond the LAN 157 boundaries and require secure deterministic forwarding and 158 connectivity over a mixed Layer-2/Layer-3 network. The properties of 159 deterministic networks will have specific requirements for the use of 160 routed networks to support these applications and a new model must be 161 proposed to integrate determinism in IT technology. 163 The proposed model should enable a fully scheduled operation 164 orchestrated by a central controller, and may support a more 165 distributed operation with probably lesser capabilities. In any 166 fashion, the model should not compromise the ability of a network to 167 keep carrying the sorts of traffic that is already carried today in 168 conjunction with new, more deterministic flows. 170 Once the abstract model is agreed upon, the IETF will need to specify 171 the signaling elements to be used to establish a path and the tagging 172 elements to be used identify the flows that are to be forwarded along 173 that path. The IETF will also need to specify the necessary 174 protocols, or protocol additions, based on relevant IETF technologies 175 such as PCE [PCE], TEAS [TEAS], CCAMP [CCAMP] and MPLS [MPLS], to 176 implement the selected model. 178 As a result of this work, it will be possible to establish a multi- 179 hop path over the IP network, for a particular flow with given timing 180 and precise throughput requirements, and carry this particular flow 181 along the multi-hop path with such characteristics as low latency and 182 ultra-low jitter, duplication and elimination of packets over non- 183 congruent paths for a higher delivery ratio, and/or zero congestion 184 loss, regardless of the amount of other flows in the network. 185 Depending on the network capabilities and on the current state, 186 requests to establish a path by an end-node or a network management 187 entity may be granted or rejected, an existing path may be moved or 188 removed, and flows exceeding their contract may face packet 189 declassification and drop. 191 2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 3. On Deterministic Networking 199 The Internet is not the only digital network that has grown 200 dramatically over the last 30-40 years. Video and audio 201 entertainment, and control systems for machinery, manufacturing 202 processes, and vehicles are also ubiquitous, and are now based almost 203 entirely on digital technologies. Over the past 10 years, engineers 204 in these fields have come to realize that significant advantages in 205 both cost and in the ability to accelerate growth can be obtained by 206 basing all of these disparate digital technologies on packet 207 networks. 209 The goals of Deterministic Networking are to enable the migration of 210 applications that use special-purpose fieldbus technologies (HDMI, 211 CANbus, ProfiBus, etc... even RS-232!) to packet technologies in 212 general, and the Internet Protocol in particular, and to support both 213 these new applications, and existing packet network applications, 214 over the same physical network. 216 Considerable experience ([ODVA],[AVnu], [Profinet],[HSR-PRP], etc...) 217 has shown that these applications need a some or all of a suite of 218 features that includes: 220 1. Time synchronization of all host and network nodes (routers and/ 221 or bridges), accurate to something between 10 nanoseconds and 10 222 microseconds, depending on the application. 224 2. Support for critical packet flows that: 226 * Can be unicast or multicast; 228 * Need absolute guarantees of minimum and maximum latency end- 229 to-end across the network; sometimes a tight jitter is 230 required as well; 232 * Need a packet loss ratio beyond the classical range for a 233 particular medium, in the range of 1.0e-9 to 1.0e-12, or 234 better, on Ethernet, and in the order of 1.0e-5 in Wireless 235 Sensor mesh Networks; 237 * Can, in total, absorb more than half of the network's 238 available bandwidth (that is, massive over-provisioning is 239 ruled out as a solution); 241 * Cannot suffer throttling, congestion feedback, or any other 242 network-imposed transmission delay, although the flows can be 243 meaningfully characterized either by a fixed, repeating 244 transmission schedule, or by a maximum bandwidth and packet 245 size; 247 3. Multiple methods to schedule, shape, limit, and otherwise control 248 the transmission of critical packets at each hop through the 249 network data plane; 251 4. Robust defenses against misbehaving hosts, routers, or bridges, 252 both in the data and control planes, with guarantees that a 253 critical flow within its guaranteed resources cannot be affected 254 by other flows whatever the pressures on the network; 256 5. One or more methods to reserve resources in bridges and routers 257 to carry these flows. 259 Time synchronization techniques need not be addressed by an IETF 260 Working Group; there are a number of standards available for this 261 purpose, including IEEE 1588, IEEE 802.1AS, and more. 263 The multicast, latency, loss ratio, and non-throttling needs are made 264 necessary by the algorithms employed by the applications. They are 265 not simply the transliteration of fieldbus needs to a packet-based 266 fieldbus simulation, but reflect fundamental mathematics of the 267 control of a physical system. 269 With classical forwarding latency- and loss-sensitive packets across 270 a network, interactions among different critical flows introduce 271 fundamental uncertainties in delivery schedules. The details of the 272 queuing, shaping, and scheduling algorithms employed by each bridge 273 or router to control the output sequence on a given port affect the 274 detailed makeup of the output stream, e.g. how finely a given flow's 275 packets are mixed among those of other flows. 277 This, in turn, has a strong effect on the buffer requirements, and 278 hence the latency guarantees deliverable, by the next bridge or 279 router along the path. For this reason, the IEEE 802.1 Time- 280 Sensitive Networking Task Group has defined a new set of queuing, 281 shaping, and scheduling algorithms (see Section 5.2) that enable each 282 bridge or router to compute the exact number of buffers to be 283 allocated for each flow or class of flows. The present authors 284 assume that these techniques will be used by the DetNet Working 285 Group. 287 Robustness is a common need for networking protocols, but plays a 288 more important part in real-time control networks, where expensive 289 equipment, and even lives, can be lost due to misbehaving equipment. 291 Reserving resources before packet transmission is the one fundamental 292 shift in the behavior of network applications that is impossible to 293 avoid. In the first place, a network cannot deliver finite latency 294 and practically zero packet loss to an arbitrarily high offered load. 295 Secondly, achieving practically zero packet loss for un-throttled 296 (though bandwidth limited) flows means that bridges and routers have 297 to dedicate buffer resources to specific flows or to classes of 298 flows. The requirements of each reservation have to be translated 299 into the parameters that control each host's, bridge's, and router's 300 queuing, shaping, and scheduling functions and delivered to the 301 hosts, bridges, and routers. 303 4. Related IETF work 305 4.1. Deterministic PHB 307 [I-D.svshah-tsvwg-deterministic-forwarding] defines a Differentiated 308 Services Per-Hop-Behavior (PHB) Group called Deterministic Forwarding 309 (DF). The document describes the purpose and semantics of this PHB. 310 It also describes creation and forwarding treatment of the service 311 class, and how the code-point can be mapped into one of the 312 aggregated Diffserv service classes [RFC5127]. 314 4.2. 6TiSCH 316 Industrial process control already leverages deterministic wireless 317 Low power and Lossy Networks (LLNs) to interconnect critical 318 resource-constrained devices and form wireless mesh networks, with 319 standards such as [ISA100.11a] and [WirelessHART]. 321 These standards rely on variations of the [IEEE802154] timeSlotted 322 Channel Hopping (TSCH) [RFC7554] Medium Access Control (MAC), and a 323 form of centralized Path Computation Element (PCE), to deliver 324 deterministic capabilities. 326 The TSCH MAC benefits include high reliability against interference, 327 low power consumption on characterized flows, and Traffic Engineering 328 capabilities. Typical applications are open and closed control 329 loops, as well as supervisory control flows and management. 331 The 6TiSCH Working Group focuses only on the TSCH mode of the 332 IEEE802.15.4e standard. The WG currently defines a framework for 333 managing the TSCH schedule. Future work will standardize 334 deterministic operations over so-called tracks as described in 335 [I-D.ietf-6tisch-architecture]. Tracks are an instance of a 336 deterministic path, and the DetNet work is a prerequisite to specify 337 track operations and serve process control applications. The 338 dependencies that 6TiSCH has on PCE and DetNet work are further 339 discussed in [I-D.thubert-6tisch-4detnet]. 341 [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section 342 2.1.3 and next discuss application-layer paradigms, such as Source- 343 sink (SS) that is a Multipeer to Multipeer (MP2MP) model that is 344 primarily used for alarms and alerts, Publish-subscribe (PS, or pub/ 345 sub) that is typically used for sensor data, as well as Peer-to-peer 346 (P2P) and Peer-to-multipeer (P2MP) communications. Additional 347 considerations on Duocast and its N-cast generalization are also 348 provided for improved reliability. 350 5. Related work in other standards organizations 352 5.1. Bridged solutions 354 Completed and ongoing work in other standards bodies have, to date, 355 produced viable solutions, suitable for carrying IP traffic for a 356 subset of the applications of interest to DetNet, but only over 357 bridged networks, not through routers. Among these are: 359 o IEEE 802 Audio-Video Bridging [IEEE802.1BA-2011]. 361 o IEEE 802 Time-Sensitive Networking (TSN) Task Group (TG) 362 [IEEE802.1TSNTG] 364 o ISO/IEC HSR and PRP [HSR-PRP]. 366 5.2. Queuing and shaping 368 A number of standards are completed or in progress in the IEEE 802.1 369 (bridging) and IEEE 802.3 (Ethernet) Working Groups related to the 370 queuing and transmission of Ethernet frames. Most of these standards 371 could be applied to non-Ethernet or non-802 media with equal 372 facility, and so will likely be of use to DetNet. See the DetNet 373 architecture draft [I-D.finn-detnet-architecture] for a detailed 374 list. 376 6. Problem Statement 378 6.1. DetNet architecture 380 An architecture that defines the space in which the various parts of 381 the DetNet solution operate is required. A start has been made with 382 [I-D.finn-detnet-architecture]. The main consideration is to build 383 on art that is deployed in existing OT networks. 385 These networks are systematically designed around a central 386 controller that has a God's view on the devices, their capabilities, 387 and their links to neighbors. The controller gets requests to 388 establish flows with certain Traffic Specifications, and programs the 389 necessary resources in the network to support those flows. 391 This design, referred to as Software Defined Networking (SDN), 392 simplifies the computation and the setup of paths, and ensures a 393 better view and an easier control of the network by an operator. To 394 inherit from this art, it has been determined early in DetNet 395 discussions that the work would initially focus on an SDN model as 396 well. 398 DetNet should thus produce the complete SDN architecture with 399 describes at a high level the interaction and data models to: 401 o report the topology and device capabilities to the central 402 controller; 404 o request a path setup for a new flow with particular 405 characteristics over the service interface and control it through 406 its life cycle; 408 o signal the new path to the devices, modify it to cope with various 409 events such as loss of a link, update it and tear it down; 411 o expose the status of the path to the end devices (UNI interface) 413 o provide additional reliability through redundancy, in particular 414 with packet replication and elimination; 416 o indicate the flows and packet sequences in-band with the flows; 418 The related concepts are already laid out at the IETF with [RFC7426], 419 which introduces the following elements: 421 SDN Layers and Architecture Terminology per RFC 7426 423 o--------------------------------o 424 | | 425 | +-------------+ +----------+ | 426 | | Application | | Service | | 427 | +-------------+ +----------+ | 428 | Application Plane | 429 o---------------Y----------------o 430 | 431 *-----------------------------Y---------------------------------* 432 | Network Services Abstraction Layer (NSAL) | 433 *------Y------------------------------------------------Y-------* 434 | | 435 | Service Interface | 436 | | 437 o------Y------------------o o---------------------Y------o 438 | | Control Plane | | Management Plane | | 439 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 440 | | Service | | App | | | | App | | Service | | 441 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 442 | | | | | | | | 443 | *----Y-----------Y----* | | *---Y---------------Y----* | 444 | | Control Abstraction | | | | Management Abstraction | | 445 | | Layer (CAL) | | | | Layer (MAL) | | 446 | *----------Y----------* | | *----------Y-------------* | 447 | | | | | | 448 o------------|------------o o------------|---------------o 449 | | 450 | CP | MP 451 | Southbound | Southbound 452 | Interface | Interface 453 | | 454 *------------Y---------------------------------Y----------------* 455 | Device and resource Abstraction Layer (DAL) | 456 *------------Y---------------------------------Y----------------* 457 | | | | 458 | o-------Y----------o +-----+ o--------Y----------o | 459 | | Forwarding Plane | | App | | Operational Plane | | 460 | o------------------o +-----+ o-------------------o | 461 | Network Device | 462 +---------------------------------------------------------------+ 464 Figure 1 466 6.2. Flow Characterization 468 Deterministic forwarding can only apply on flows with well-defined 469 characteristics such as periodicity and burstiness. Before a path 470 can be established to serve them, the expression of those 471 characteristics, and how the network can serve them, for instance in 472 shaping and forwarding operations, must be specified. 474 6.3. Centralized Path Computation and Installation 476 A centralized routing model, such as provided with a PCE, enables 477 global and per-flow optimizations. The model is attractive but a 478 number of issues are left to be solved. In particular: 480 o whether and how the path computation can be installed by 1) an end 481 device or 2) a Network Management entity, 483 o and how the path is set up, either by installing state at each hop 484 with a direct interaction between the forwarding device and the 485 PCE, or along a path by injecting a source-routed request at one 486 end of the path following classical Traffic Engineering (TE) 487 models. 489 6.4. Distributed Path Setup 491 Whether a distributed alternative without a PCE can be valuable could 492 be studied as well. Such an alternative could for instance inherit 493 from the Resource ReSerVation Protocol [RFC5127] (RSVP) flows. But 494 the focus of the work should be to deliver the centralized approach 495 first. 497 6.5. Duplicated data format 499 In some cases the duplication and elimination of packets over non- 500 congruent paths is required to achieve a sufficiently high delivery 501 ratio to meet application needs. In these cases, a small number of 502 packet formats and supporting protocols are required (preferably, 503 just one) to serialize the packets of a DetNet stream at one point in 504 the network, replicate them at one or more points in the network, and 505 discard duplicates at one or more other points in the network, 506 including perhaps the destination host. Using an existing solution 507 would be preferable to inventing a new one. 509 7. Security Considerations 511 Security in the context of Deterministic Networking has an added 512 dimension; the time of delivery of a packet can be just as important 513 as the contents of the packet, itself. A man-in-the-middle attack, 514 for example, can impose, and then systematically adjust, additional 515 delays into a link, and thus disrupt or subvert a real-time 516 application without having to crack any encryption methods employed. 517 See [RFC7384] for an exploration of this issue in a related context. 519 Typical control networks today rely on complete physical isolation to 520 prevent rogue access to network resources. DetNet enables the 521 virtualization of those networks over a converged IT/OT 522 infrastructure. Doing so, DetNet introduces an additional risk that 523 flows interact and interfere with one another as they share physical 524 resources such as Ethernet trunks and radio spectrum. The 525 requirement is that there is no possible data leak from and into a 526 deterministic flow, and in a more general fashion there is no 527 possible influence whatsoever from the outside on a deterministic 528 flow. The expectation is that physical resources are effectively 529 associated with a given flow at a given point if time. In that 530 model, Time Sharing of physical resources becomes transparent to the 531 individual flows which have no clue whether the resources are used by 532 other flows at other times. 534 Security must cover: 536 o the protection of the signaling protocol 538 o the authentication and authorization of the controlling nodes 540 o the identification and shaping of the flows 542 o the isolation of flows from leakage and other influences from any 543 activity sharing physical resources. 545 8. IANA Considerations 547 This document does not require an action from IANA. 549 9. Acknowledgements 551 The authors wish to thank Jouni Korhonen, Erik Nordmark, George 552 Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne, 553 Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried Steiner, 554 Marcel Kiessling, Karl Weber, Ethan Grossman and Pat Thaler, for 555 their various contribution with this work. 557 10. References 558 10.1. Normative References 560 [I-D.gunther-detnet-proaudio-req] 561 Gunther, C. and E. Grossman, "Deterministic Networking 562 Professional Audio Requirements", draft-gunther-detnet- 563 proaudio-req-01 (work in progress), March 2015. 565 [I-D.korhonen-detnet-telreq] 566 Korhonen, J., "Deterministic networking for radio access 567 networks", draft-korhonen-detnet-telreq-00 (work in 568 progress), May 2015. 570 [I-D.thubert-6tisch-4detnet] 571 Thubert, P., "6TiSCH requirements for DetNet", draft- 572 thubert-6tisch-4detnet-00 (work in progress), June 2015. 574 [I-D.wetterwald-detnet-utilities-reqs] 575 Wetterwald, P. and J. Raymond, "Deterministic Networking 576 Uitilities requirements", draft-wetterwald-detnet- 577 utilities-reqs-01 (work in progress), October 2014. 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 582 10.2. Informative References 584 [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and 585 certifies devices for interoperability, providing a simple 586 and reliable networking solution for AV network 587 implementation based on the IEEE Audio Video Bridging 588 (AVB) and Time-Sensitive Networking (TSN) standards.". 590 [CCAMP] IETF, "Common Control and Measurement Plane", 591 . 593 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 594 a group of specifications for industrial process and 595 control devices administered by the HART Foundation". 597 [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a 598 further development of the PRP approach, although HSR 599 functions primarily as a protocol for creating media 600 redundancy while PRP, as described in the previous 601 section, creates network redundancy. PRP and HSR are both 602 described in the IEC 62439 3 standard.". 604 [I-D.finn-detnet-architecture] 605 Finn, N., Thubert, P., and M. Teener, "Deterministic 606 Networking Architecture", draft-finn-detnet- 607 architecture-01 (work in progress), March 2015. 609 [I-D.ietf-6tisch-architecture] 610 Thubert, P., "An Architecture for IPv6 over the TSCH mode 611 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 612 in progress), May 2015. 614 [I-D.ietf-roll-rpl-industrial-applicability] 615 Phinney, T., Thubert, P., and R. Assimiti, "RPL 616 applicability in industrial networks", draft-ietf-roll- 617 rpl-industrial-applicability-02 (work in progress), 618 October 2013. 620 [I-D.svshah-tsvwg-deterministic-forwarding] 621 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 622 draft-svshah-tsvwg-deterministic-forwarding-03 (work in 623 progress), March 2015. 625 [IEEE802.1AS-2011] 626 IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 627 2011, . 630 [IEEE802.1BA-2011] 631 IEEE, "AVB Systems (IEEE 802.1BA-2011)", 2011, 632 . 635 [IEEE802.1Q-2011] 636 IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, 637 . 640 [IEEE802.1Qat-2010] 641 IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 642 2010, . 645 [IEEE802.1Qav] 646 IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, 647 . 650 [IEEE802.1TSNTG] 651 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 652 Networks Task Group", 2013, 653 . 655 [IEEE802154] 656 IEEE standard for Information Technology, "IEEE std. 657 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 658 and Physical Layer (PHY) Specifications for Low-Rate 659 Wireless Personal Area Networks". 661 [IEEE802154e] 662 IEEE standard for Information Technology, "IEEE std. 663 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 664 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 665 2012. 667 [ISA100.11a] 668 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 669 also IEC 62734", 2011, < http://www.isa100wci.org/en- 670 US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- 671 WEB-ETSI.aspx>. 673 [MPLS] IETF, "Multiprotocol Label Switching", 674 . 676 [ODVA] http://www.odva.org/, "The organization that supports 677 network technologies built on the Common Industrial 678 Protocol (CIP) including EtherNet/IP.". 680 [PCE] IETF, "Path Computation Element", 681 . 683 [Profinet] 684 http://us.profinet.com/technology/profinet/, "PROFINET is 685 a standard for industrial networking in automation.", 686 . 688 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 689 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 690 Functional Specification", RFC 2205, September 1997. 692 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 693 Diffserv Service Classes", RFC 5127, February 2008. 695 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 696 "Industrial Routing Requirements in Low-Power and Lossy 697 Networks", RFC 5673, October 2009. 699 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 700 Packet Switched Networks", RFC 7384, October 2014. 702 [RFC7426] Haleplidis, E., Pentikousis, K., Denazis, S., Hadi Salim, 703 J., Meyer, D., and O. Koufopavlou, "Software-Defined 704 Networking (SDN): Layers and Architecture Terminology", 705 RFC 7426, January 2015. 707 [RFC7554] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE 708 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 709 Internet of Things (IoT): Problem Statement", RFC 7554, 710 May 2015. 712 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 713 . 715 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 716 . 718 [WirelessHART] 719 www.hartcomm.org, "Industrial Communication Networks - 720 Wireless Communication Network and Communication Profiles 721 - WirelessHART - IEC 62591", 2010. 723 Authors' Addresses 725 Norm Finn 726 Cisco Systems 727 510 McCarthy Blvd 728 SJ-24 729 Milpitas, California 95035 730 USA 732 Phone: +1 408 526 4495 733 Email: nfinn@cisco.com 735 Pascal Thubert 736 Cisco Systems 737 Village d'Entreprises Green Side 738 400, Avenue de Roumanille 739 Batiment T3 740 Biot - Sophia Antipolis 06410 741 FRANCE 743 Phone: +33 4 97 23 26 34 744 Email: pthubert@cisco.com