idnits 2.17.1 draft-finn-detnet-problem-statement-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 8, 2015) is 3238 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 470, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1AS-2011' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q-2011' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qat-2010' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qav' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'IEEE802154e' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 565, 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 10, 2015 June 8, 2015 7 Deterministic Networking Problem Statement 8 draft-finn-detnet-problem-statement-02 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 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. On Deterministic Networking . . . . . . . . . . . . . . . . . 4 53 4. Related IETF work . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Deterministic PHB . . . . . . . . . . . . . . . . . . . . 6 55 4.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Related work in other standards organizations . . . . . . . . 7 57 5.1. Bridged solutions . . . . . . . . . . . . . . . . . . . . 7 58 5.2. Queuing and shaping . . . . . . . . . . . . . . . . . . . 8 59 6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 60 6.1. DetNet architecture . . . . . . . . . . . . . . . . . . . 8 61 6.2. Flow Characterization . . . . . . . . . . . . . . . . . . 8 62 6.3. Centralized Path Computation and Installation . . . . . . 8 63 6.4. Distributed Path Setup . . . . . . . . . . . . . . . . . 9 64 6.5. Duplicated data format . . . . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Operational Technology (OT) refers to industrial networks that are 76 typically used for monitoring systems and supporting control loops, 77 as well as movement detection systems for use in process control 78 (i.e., process manufacturing) and factory automation (i.e., discrete 79 manufacturing). Due to its different goals, OT has evolved in 80 parallel but in a manner that is radically different from IT/ICT, 81 focusing on highly secure, reliable and deterministic networks, with 82 limited scalability over a bounded area. 84 The convergence of IT and OT technologies, also called the Industrial 85 Internet, represents a major evolution for both sides. The work has 86 already started; in particular, the industrial automation space has 87 been developing a number of Ethernet-based replacements for existing 88 digital control systems, often not packet-based (fieldbus 89 technologies). 91 These replacements are meant to provide similar behavior as the 92 incumbent protocols, and their common focus is to transport a fully 93 characterized flow over a well-controlled environment (i.e., a 94 factory floor), with a bounded latency, extraordinarily low frame 95 loss, and a very narrow jitter. Examples of such protocols include 96 PROFINET, ODVA Ethernet/IP, and EtherCAT. 98 In parallel, the need for determinism in professional and home audio/ 99 video markets drove the formation of the Audio/Video Bridging (AVB) 100 standards effort of IEEE 802.1. With the explosion of demand for 101 connectivity and multimedia in transportation in general, the 102 Ethernet AVB technology has become one of the hottest topics, in 103 particular in the automotive connectivity. It is finding application 104 in all elements of the vehicle from head units, to rear seat 105 entertainment modules, to amplifiers and camera modules. While aimed 106 at less critical applications than some industrial networks, AVB 107 networks share the requirement for extremely low packet loss rates 108 and guaranteed finite latency and jitter. 110 Other instances of in-vehicle deterministic networks have arisen as 111 well for control networks in cars, trains and buses, as well as 112 avionics, with, for instance, the mission-critical "Avionics Full- 113 Duplex Switched Ethernet" (AFDX) that was designed as part of the 114 ARINC 664 standards. Existing automotive control networks such as 115 the LIN, CAN and FlexRay standards were not designed to cover these 116 increasing demands in terms of bandwidth and scalability that we see 117 with various kinds of Driver Assistance Systems (DAS) and new 118 multiplexing technologies based on Ethernet are now getting traction. 120 Examples of industries where strong needs for deterministic networks 121 are now emerging include radio access networks 122 [I-D.korhonen-detnet-telreq], the smartgrid 123 [I-D.wetterwald-detnet-utilities-reqs], and ProAudio networks 124 [I-D.gunther-detnet-proaudio-req]. 126 The generalization of the needs for more deterministic networks have 127 led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive 128 Networking (TSN) Task Group (TG) [IEEE802.1TSNTG], with a much- 129 expanded constituency from the industrial and vehicular markets. 130 Along with this expansion, the networks in consideration are becoming 131 larger and structured, requiring deterministic forwarding beyond the 132 LAN boundaries. For instance, Industrial Automation segregates the 133 network along the broad lines of the Purdue Enterprise Reference 134 Architecture (PERA), using different technologies at each level, and 135 public infrastructures such as Electricity Automation require 136 deterministic properties over the Wide Area. The realization is now 137 coming that the convergence of IT and OT networks requires Layer-3, 138 as well as Layer-2, capabilities. 140 In order to serve this extended requirement, the IETF and the IEEE 141 must collaborate and define an abstract model that can be applicable 142 both at Layer-2 and Layer-3, and along segments of different 143 technologies. With this new work, a path may span, for instance, 144 across a (limited) number of 802.1 bridges and then a (limited) 145 number of IP routers. In that example, the IEEE802.1 bridges may be 146 operating at Layer-2 over Ethernet whereas the IP routers may be 147 6TiSCH [TiSCH] nodes operating at Layer-2 and/or Layer-3 over the 148 IEEE802.15.4 MAC. 150 The proposed model should enable a fully scheduled operation 151 orchestrated by a central controller, as well as a more distributed 152 operation with probably lesser capabilities. In any fashion, the 153 model should not compromise the ability of a network to keep carrying 154 the sorts of traffic that is already carried today in conjunction 155 with new, more deterministic flows. 157 Once the abstract model is agreed upon, the IETF will need to specify 158 the signaling elements to be used to establish a path and the tagging 159 elements to be used identify the flows that are to be forwarded along 160 that path. The IETF will also need to specify the necessary 161 protocols, or protocol additions, based on relevant IETF technologies 162 such as PCE [PCE], TEAS [TEAS], CCAMP [CCAMP] and MPLS [MPLS], to 163 implement the selected model. As a result of this work, it will be 164 possible to establish a multi-hop path over the IP network, for a 165 particular flow with precise timing and throughput requirements, and 166 carry this particular flow along the multi-hop path with such 167 characteristics as low latency and ultra-low jitter, duplication and 168 elimination of packets over non-congruent paths for a higher delivery 169 ratio, and/or zero congestion loss. Depending on the network 170 capabilities and on the current state, requests to establish a path 171 by an end-node or a network management entity may be granted or 172 rejected, and an existing path may be moved or removed. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 3. On Deterministic Networking 182 The Internet is not the only digital network that has grown 183 dramatically over the last 30-40 years. Video and audio 184 entertainment, and control systems for machinery, manufacturing 185 processes, and vehicles are also ubiquitous, and are now based almost 186 entirely on digital technologies. Over the past 10 years, engineers 187 in these fields have come to realize that significant advantages in 188 both cost and in the ability to accelerate growth can be obtained by 189 basing all of these disparate digital technologies on packet 190 networks. 192 The goals of Deterministic Networking are to enable the migration of 193 applications that use special-purpose fieldbus technologies (HDMI, 194 CANbus, ProfiBus, etc... even RS-232!) to packet technologies in 195 general, and the Internet Protocol in particular, and to support both 196 these new applications, and existing packet network applications, 197 over the same physical network. 199 Considerable experience ([ODVA],[AVnu], [Profinet],[HSR-PRP], etc...) 200 has shown that these applications need a some or all of a suite of 201 features that includes: 203 1. Time synchronization of all host and network nodes (routers and/ 204 or bridges), accurate to something between 10 nanoseconds and 10 205 microseconds, depending on the application. 207 2. Support for critical packet flows that: 209 * Can be unicast or multicast; 211 * Need absolute guarantees of minimum and maximum latency end- 212 to-end across the network; 214 * Need a packet loss ratio in the range of 1.0e-9 to 1.0e-12, or 215 better; 217 * Can, in total, absorb more than half of the network's 218 available bandwidth (that is, over-provisioning is ruled out 219 as a solution); 221 * Cannot suffer throttling, congestion feedback, or any other 222 network-imposed transmission delay, although the flows can be 223 meaningfully characterized either by a fixed, repeating 224 transmission schedule, or by a maximum bandwidth and packet 225 size. 227 3. Multiple methods to schedule, shape, limit, and otherwise control 228 the transmission of critical packets at each hop through the 229 network data plane. 231 4. Robust defenses against misbehaving hosts, routers, or bridges, 232 both in the data and control planes. 234 5. One or more methods to reserve resources in bridges and routers 235 to carry these flows. 237 Time synchronization techniques need not be addressed by an IETF 238 Working Group; there are a number of standards available for this 239 purpose, including IEEE 1588, IEEE 802.1AS, and more. 241 The multicast, latency, loss ratio, and non-throttling needs are made 242 necessary by the algorithms employed by the applications. They are 243 not simply the transliteration of fieldbus needs to a packet-based 244 fieldbus simulation, but reflect fundamental mathematics of the 245 control of a physical system. 247 When forwarding latency- and loss-sensitive packets across a network, 248 interactions among different critical flows introduce fundamental 249 uncertainties in delivery schedules. The details of the queuing, 250 shaping, and scheduling algorithms employed by each bridge or router 251 to control the output sequence on a given port affect the detailed 252 makeup of the output stream, e.g. how finely a given flow's packets 253 are mixed among those of other flows. 255 This, in turn, has a strong effect on the buffer requirements, and 256 hence the latency guarantees deliverable, by the next bridge or 257 router along the path. For this reason, the IEEE 802.1 Time- 258 Sensitive Networking Task Group has defined a set of queuing, 259 shaping, and scheduling algorithms (see Section 5.2) that enable each 260 bridge or router to compute the exact number of buffers to be 261 allocated for each flow or class of flows. The present authors 262 assume that these techniques will be used by the DetNet Working 263 Group. 265 Robustness is a common need for networking protocols, but plays a 266 more important part in real-time control networks, where expensive 267 equipment, and even lives, can be lost due to misbehaving equipment. 269 Reserving resources before packet transmission is the one fundamental 270 shift in the behavior of network applications that is impossible to 271 avoid. In the first place, a network cannot deliver finite latency 272 and practically zero packet loss to an arbitrarily high offered load. 273 Secondly, achieving practically zero packet loss for unthrottled 274 (though bandwidth limited) flows means that bridges and routers have 275 to dedicate buffer resources to specific flows or to classes of 276 flows. The requirements of each reservation have to be translated 277 into the parameters that control each host's, bridge's, and router's 278 queuing, shaping, and scheduling functions and delivered to the 279 hosts, bridges, and routers. 281 4. Related IETF work 283 4.1. Deterministic PHB 285 [I-D.svshah-tsvwg-deterministic-forwarding] defines a Differentiated 286 Services Per-Hop-Behavior (PHB) Group called Deterministic Forwarding 287 (DF). The document describes the purpose and semantics of this PHB. 288 It also describes creation and forwarding treatment of the service 289 class. The document also describes how the code-point can be mapped 290 into one of the aggregated Diffserv service classes [RFC5127]. 292 4.2. 6TiSCH 294 Industrial process control already leverages deterministic wireless 295 Low power and Lossy Networks (LLNs) to interconnect critical 296 resource-constrained devices and form wireless mesh networks, with 297 standards such as [ISA100.11a] and [WirelessHART]. 299 These standards rely on variations of the [IEEE802154] timeSlotted 300 Channel Hopping (TSCH) [RFC7554] Medium Access Control (MAC), and a 301 form of centralized Path Computation Element (PCE), to deliver 302 deterministic capabilities. 304 The TSCH MAC benefits include high reliability against interference, 305 low power consumption on characterized flows, and Traffic Engineering 306 capabilities. Typical applications are open and closed control 307 loops, as well as supervisory control flows and management. 309 The 6TiSCH Working Group focuses only on the TSCH mode of the 310 IEEE802.15.4e standard. The WG currently defines a framework for 311 managing the TSCH schedule. Future work will standardize 312 deterministic operations over so-called tracks as described in 313 [I-D.ietf-6tisch-architecture]. Tracks are an instance of a 314 deterministic path, and the DetNet work is a prerequisite to specify 315 track operations and serve process control applications. The 316 dependencies that 6TiSCH has on PCE and DetNet work are further 317 discussed in [I-D.thubert-6tisch-4detnet]. 319 [RFC5673] and [I-D.ietf-roll-rpl-industrial-applicability] section 320 2.1.3 and next discuss application-layer paradigms, such as Source- 321 sink (SS) that is a Multipeer to Multipeer (MP2MP) model that is 322 primarily used for alarms and alerts, Publish-subscribe (PS, or pub/ 323 sub) that is typically used for sensor data, as well as Peer-to-peer 324 (P2P) and Peer-to-multipeer (P2MP) communications. Additional 325 considerations on Duocast and its N-cast generalization are also 326 provided for improved reliability. 328 5. Related work in other standards organizations 330 5.1. Bridged solutions 332 Completed and ongoing work in other standards bodies have, to date, 333 produced viable solutions, suitable for carrying IP traffic for a 334 subset of the applications of interest to DetNet, but only over 335 bridged networks, not through routers. Among these are: 337 o IEEE 802 Audio-Video Bridging [IEEE802.1BA-2011]. 339 o IEEE 802 Time-Sensitive Networking (TSN) Task Group (TG) 340 [IEEE802.1TSNTG] 342 o ISO/IEC HSR and PRP [HSR-PRP]. 344 5.2. Queuing and shaping 346 A number of standards are completed or in progress in the IEEE 802.1 347 (bridging) and IEEE 802.3 (Ethernet) Working Groups related to the 348 queuing and transmission of Ethernet frames. Most of these standards 349 could be applied to non-Ethernet or non-802 media with equal 350 facility, and so will likely be of use to DetNet. See the DetNet 351 architecture draft [I-D.finn-detnet-architecture] for a detailed 352 list. 354 6. Problem Statement 356 6.1. DetNet architecture 358 An architecture that defines the space in which the various parts of 359 the DetNet solution operate is required. A start has been made with 360 [I-D.finn-detnet-architecture]. 362 6.2. Flow Characterization 364 Deterministic forwarding can only apply on flows with well-defined 365 characteristics such as periodicity and burstiness. Before a path 366 can be established to serve them, the expression of those 367 characteristics, and how the network can serve them, for instance in 368 shaping and forwarding operations, must be specified. 370 6.3. Centralized Path Computation and Installation 372 A centralized routing model, such as provided with a PCE, enables 373 global and per-flow optimizations. The model is attractive but a 374 number of issues are left to be solved. In particular: 376 o whether and how the path computation can be installed by 1) an end 377 device or 2) a Network Management entity, 379 o and how the path is set up, either by installing state at each hop 380 with a direct interaction between the forwarding device and the 381 PCE, or along a path by injecting a source-routed request at one 382 end of the path. 384 6.4. Distributed Path Setup 386 Whether a distributed alternative without a PCE can be valuable 387 should be studied as well. Such an alternative could for instance 388 inherit from the Resource ReSerVation Protocol [RFC5127] (RSVP) 389 flows. 391 6.5. Duplicated data format 393 In some cases the duplication and elimination of packets over non- 394 congruent paths is required to achieve a sufficiently high delivery 395 ratio to meet application needs. In these cases, a small number of 396 packet formats and supporting protocols are required (preferably, 397 just one) to serialize the packets of a DetNet stream at one point in 398 the network, replicate them at one or more points in the network, and 399 discard duplicates at one or more other points in the network, 400 including perhaps the destination host. Using an existing solution 401 would be preferable to inventing a new one. 403 7. Security Considerations 405 Security in the context of Deterministic Networking has an added 406 dimension; the time of delivery of a packet can be just as important 407 as the contents of the packet, itself. A man-in-the-middle attack, 408 for example, can impose, and then systematically adjust, additional 409 delays into a link, and thus disrupt or subvert a real-time 410 application without having to crack any encryption methods employed. 411 See [RFC7384] for an exploration of this issue in a related context. 413 Security must cover: 415 o the protection of the signaling protocol 417 o the authentication and authorization of the controlling nodes 419 o the identification and shaping of the flows 421 8. IANA Considerations 423 This document does not require an action from IANA. 425 9. Acknowledgements 427 The authors wish to thank Jouni Korhonen, Erik Nordmark, George 428 Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne, 429 Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried Steiner, 430 Marcel Kiessling, Karl Weber, Ethan Grossman and Pat Thaler, for 431 their various contribution with this work. 433 10. References 435 10.1. Normative References 437 [I-D.gunther-detnet-proaudio-req] 438 Gunther, C. and E. Grossman, "Deterministic Networking 439 Professional Audio Requirements", draft-gunther-detnet- 440 proaudio-req-01 (work in progress), March 2015. 442 [I-D.korhonen-detnet-telreq] 443 Korhonen, J., "Deterministic networking for radio access 444 networks", draft-korhonen-detnet-telreq-00 (work in 445 progress), May 2015. 447 [I-D.thubert-6tisch-4detnet] 448 Thubert, P., "6TiSCH requirements for DetNet", draft- 449 thubert-6tisch-4detnet-00 (work in progress), June 2015. 451 [I-D.wetterwald-detnet-utilities-reqs] 452 Wetterwald, P. and J. Raymond, "Deterministic Networking 453 Uitilities requirements", draft-wetterwald-detnet- 454 utilities-reqs-01 (work in progress), October 2014. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 10.2. Informative References 461 [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and 462 certifies devices for interoperability, providing a simple 463 and reliable networking solution for AV network 464 implementation based on the IEEE Audio Video Bridging 465 (AVB) and Time-Sensitive Networking (TSN) standards.". 467 [CCAMP] IETF, "Common Control and Measurement Plane", 468 . 470 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 471 a group of specifications for industrial process and 472 control devices administered by the HART Foundation". 474 [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a 475 further development of the PRP approach, although HSR 476 functions primarily as a protocol for creating media 477 redundancy while PRP, as described in the previous 478 section, creates network redundancy. PRP and HSR are both 479 described in the IEC 62439 3 standard.". 481 [I-D.finn-detnet-architecture] 482 Finn, N., Thubert, P., and M. Teener, "Deterministic 483 Networking Architecture", draft-finn-detnet- 484 architecture-01 (work in progress), March 2015. 486 [I-D.ietf-6tisch-architecture] 487 Thubert, P., "An Architecture for IPv6 over the TSCH mode 488 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 489 in progress), May 2015. 491 [I-D.ietf-roll-rpl-industrial-applicability] 492 Phinney, T., Thubert, P., and R. Assimiti, "RPL 493 applicability in industrial networks", draft-ietf-roll- 494 rpl-industrial-applicability-02 (work in progress), 495 October 2013. 497 [I-D.svshah-tsvwg-deterministic-forwarding] 498 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 499 draft-svshah-tsvwg-deterministic-forwarding-03 (work in 500 progress), March 2015. 502 [IEEE802.1AS-2011] 503 IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 504 2011, . 507 [IEEE802.1BA-2011] 508 IEEE, "AVB Systems (IEEE 802.1BA-2011)", 2011, 509 . 512 [IEEE802.1Q-2011] 513 IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, 514 . 517 [IEEE802.1Qat-2010] 518 IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 519 2010, . 522 [IEEE802.1Qav] 523 IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, 524 . 527 [IEEE802.1TSNTG] 528 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 529 Networks Task Group", 2013, 530 . 532 [IEEE802154] 533 IEEE standard for Information Technology, "IEEE std. 534 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 535 and Physical Layer (PHY) Specifications for Low-Rate 536 Wireless Personal Area Networks". 538 [IEEE802154e] 539 IEEE standard for Information Technology, "IEEE std. 540 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 541 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 542 2012. 544 [ISA100.11a] 545 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 546 also IEC 62734", 2011, < http://www.isa100wci.org/en- 547 US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- 548 WEB-ETSI.aspx>. 550 [MPLS] IETF, "Multiprotocol Label Switching", 551 . 553 [ODVA] http://www.odva.org/, "The organization that supports 554 network technologies built on the Common Industrial 555 Protocol (CIP) including EtherNet/IP.". 557 [PCE] IETF, "Path Computation Element", 558 . 560 [Profinet] 561 http://us.profinet.com/technology/profinet/, "PROFINET is 562 a standard for industrial networking in automation.", 563 . 565 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 566 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 567 Functional Specification", RFC 2205, September 1997. 569 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 570 Diffserv Service Classes", RFC 5127, February 2008. 572 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 573 "Industrial Routing Requirements in Low-Power and Lossy 574 Networks", RFC 5673, October 2009. 576 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 577 Packet Switched Networks", RFC 7384, October 2014. 579 [RFC7554] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE 580 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 581 Internet of Things (IoT): Problem Statement", RFC 7554, 582 May 2015. 584 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 585 . 587 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 588 . 590 [WirelessHART] 591 www.hartcomm.org, "Industrial Communication Networks - 592 Wireless Communication Network and Communication Profiles 593 - WirelessHART - IEC 62591", 2010. 595 Authors' Addresses 597 Norm Finn 598 Cisco Systems 599 510 McCarthy Blvd 600 SJ-24 601 Milpitas, California 95035 602 USA 604 Phone: +1 408 526 4495 605 Email: nfinn@cisco.com 607 Pascal Thubert 608 Cisco Systems 609 Village d'Entreprises Green Side 610 400, Avenue de Roumanille 611 Batiment T3 612 Biot - Sophia Antipolis 06410 613 FRANCE 615 Phone: +33 4 97 23 26 34 616 Email: pthubert@cisco.com