idnits 2.17.1 draft-finn-detnet-problem-statement-05.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 (March 17, 2016) is 2956 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: 'CCAMP' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'EIP' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'HART' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'I-D.finn-detnet-architecture' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-rpl-industrial-applicability' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-deterministic-forwarding' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'I-D.zhao-pce-pcep-extension-for-pce-controller' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1AS-2011' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1BA-2011' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q-2011' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qat-2010' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qav' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'IEEE802154' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'IEEE802154e' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'MPLS' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'PCE' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'RFC2547' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC3985' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC4664' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC5127' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC5151' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC5329' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'RFC7426' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'TEAS' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'TiSCH' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'WirelessHART' is defined on line 654, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-finn-detnet-architecture-03 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-09 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-02 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-03 -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 0 errors (**), 0 flaws (~~), 45 warnings (==), 3 comments (--). 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: September 18, 2016 March 17, 2016 7 Deterministic Networking Problem Statement 8 draft-finn-detnet-problem-statement-05 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 September 18, 2016. 33 Copyright Notice 35 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. On Deterministic Networking . . . . . . . . . . . . . . . . . 4 53 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Supported topologies . . . . . . . . . . . . . . . . . . 6 55 4.2. Flow Characterization . . . . . . . . . . . . . . . . . . 6 56 4.3. Centralized Path Computation and Installation . . . . . . 6 57 4.4. Distributed Path Setup . . . . . . . . . . . . . . . . . 7 58 4.5. Duplicated data format . . . . . . . . . . . . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 8.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 67 1. Introduction 69 The Deterministic Networking Use Cases 70 [I-D.grossman-detnet-use-cases] document illustrates that beyond the 71 classical case of industrial automation and control systems (IACS), 72 there are in fact multiple industries with strong and yet relatively 73 similar needs for deterministic network services with latency 74 guarantees and ultra-low packet loss. 76 The generalization of the needs for more deterministic networks have 77 led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive 78 Networking (TSN) [IEEE802.1TSNTG] Task Group (TG), with a much- 79 expanded constituency from the industrial and vehicular markets. 81 Along with this expansion, the networks in consideration are becoming 82 larger and structured, requiring deterministic forwarding beyond the 83 LAN boundaries. For instance, IACS segregates the network along the 84 broad lines of the Purdue Enterprise Reference Architecture (PERA) 85 [ISA95], typically using deterministic local area networks for level 86 2 control systems, whereas public infrastructures such as Electricity 87 Automation require deterministic properties over the Wide Area. The 88 realization is now coming that the convergence of IT and Operational 89 Technology (OT) networks requires Layer-3, as well as Layer-2, 90 capabilities. 92 While the initial user base has focused almost entirely on Ethernet 93 physical media and Ethernet-based bridging protocol (from several 94 Standards Development Organizations), the need for Layer-3 expressed 95 above, must not be confined to Ethernet and Ethernet-like media, and 96 while such media must be encompassed by any useful DetNet 97 architecture, cooperation between IETF and other SDOs must not be 98 limited to IEEE or IEEE 802. Furthermore, while the work completed 99 and ongoing in other SDOs, and in IEEE 802 in particular, provide an 100 obvious starting point for a DetNet architecture, we must not assume 101 that these other SDOs' work confines the space in which the DetNet 102 architecture progresses. 104 The properties of deterministic networks will have specific 105 requirements for the use of routed networks to support these 106 applications and a new model must be proposed to integrate 107 determinism in IT technology. The proposed model should enable a 108 fully scheduled operation orchestrated by a central controller, and 109 may support a more distributed operation with probably lesser 110 capabilities. In any fashion, the model should not compromise the 111 ability of a network to keep carrying the sorts of traffic that is 112 already carried today in conjunction with new, more deterministic 113 flows. 115 Once the abstract model is agreed upon, the IETF will need to specify 116 the signaling elements to be used to establish a path and the tagging 117 elements to be used identify the flows that are to be forwarded along 118 that path. The IETF will also need to specify the necessary 119 protocols, or protocol additions, based on relevant IETF 120 technologies, to implement the selected model. 122 As a result of this work, it will be possible to establish a multi- 123 hop path over the IP network, for a particular flow with given timing 124 and precise throughput requirements, and carry this particular flow 125 along the multi-hop path with such characteristics as low latency and 126 ultra-low jitter, duplication and elimination of packets over non- 127 congruent paths for a higher delivery ratio, and/or zero congestion 128 loss, regardless of the amount of other flows in the network. 130 Depending on the network capabilities and on the current state, 131 requests to establish a path by an end-node or a network management 132 entity may be granted or rejected, an existing path may be moved or 133 removed, and DetNet flows exceeding their contract may face packet 134 declassification and drop. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. On Deterministic Networking 144 The Internet is not the only digital network that has grown 145 dramatically over the last 30-40 years. Video and audio 146 entertainment, and control systems for machinery, manufacturing 147 processes, and vehicles are also ubiquitous, and are now based almost 148 entirely on digital technologies. Over the past 10 years, engineers 149 in these fields have come to realize that significant advantages in 150 both cost and in the ability to accelerate growth can be obtained by 151 basing all of these disparate digital technologies on packet 152 networks. 154 The goals of Deterministic Networking are to enable the migration of 155 applications that use special-purpose fieldbus technologies (HDMI, 156 CANbus, ProfiBus, etc... even RS-232!) to packet technologies in 157 general, and the Internet Protocol in particular, and to support both 158 these new applications, and existing packet network applications, 159 over the same physical network. 161 Considerable experience ([ODVA],[AVnu], [Profinet],[IEC62439], 162 etc...) has shown that these applications need a some or all of a 163 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 critical 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 1.0e-9 to 1.0e-12, or 179 better, on Ethernet, and in the order of 1.0e-5 in Wireless 180 Sensor mesh 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; 201 5. One or more methods to reserve resources in bridges and routers 202 to carry these flows. 204 Time synchronization techniques need not be addressed by an IETF 205 Working Group; there are a number of standards available for this 206 purpose, including IEEE 1588, IEEE 802.1AS, and more. 208 The multicast, latency, loss ratio, and non-throttling needs are made 209 necessary by the algorithms employed by the applications. They are 210 not simply the transliteration of fieldbus needs to a packet-based 211 fieldbus simulation, but reflect fundamental mathematics of the 212 control of a physical system. 214 With classical forwarding latency- and loss-sensitive packets across 215 a network, interactions among different critical flows introduce 216 fundamental uncertainties in delivery schedules. The details of the 217 queuing, shaping, and scheduling algorithms employed by each bridge 218 or router to control the output sequence on a given port affect the 219 detailed makeup of the output stream, e.g. how finely a given flow's 220 packets are mixed among those of other flows. 222 This, in turn, has a strong effect on the buffer requirements, and 223 hence the latency guarantees deliverable, by the next bridge or 224 router along the path. For this reason, the IEEE 802.1 Time- 225 Sensitive Networking Task Group has defined a new set of queuing, 226 shaping, and scheduling algorithms that enable each bridge or router 227 to compute the exact number of buffers to be allocated for each flow 228 or class of flows. 230 Robustness is a common need for networking protocols, but plays a 231 more important part in real-time control networks, where expensive 232 equipment, and even lives, can be lost due to misbehaving equipment. 234 Reserving resources before packet transmission is the one fundamental 235 shift in the behavior of network applications that is impossible to 236 avoid. In the first place, a network cannot deliver finite latency 237 and practically zero packet loss to an arbitrarily high offered load. 238 Secondly, achieving practically zero packet loss for un-throttled 239 (though bandwidth limited) flows means that bridges and routers have 240 to dedicate buffer resources to specific flows or to classes of 241 flows. The requirements of each reservation have to be translated 242 into the parameters that control each host's, bridge's, and router's 243 queuing, shaping, and scheduling functions and delivered to the 244 hosts, bridges, and routers. 246 4. Problem Statement 248 4.1. Supported topologies 250 In some use cases, the end point which run the application is 251 involved in the deterministic networking operation, for instance by 252 controlling certain aspects of its throughput such as rate or precise 253 time of emission. In that case, the deterministic path is end-to-end 254 from application host to application host. 256 On the other end, the deterministic portion of a path may be a tunnel 257 between and ingress and an egress router. In any case, routers and 258 switches in between should not need to be aware whether the path is 259 end-to-end of a tunnel. 261 While it is clear that DetNet does not aim at setting up 262 deterministic paths over the global Internet, there is still a lack 263 of clarity on the limits of a domain where a deterministic path can 264 be set up. These limits may depend in the technology that is used to 265 seu th epath up, whether it is centralized or distributed. 267 4.2. Flow Characterization 269 Deterministic forwarding can only apply on flows with well-defined 270 characteristics such as periodicity and burstiness. Before a path 271 can be established to serve them, the expression of those 272 characteristics, and how the network can serve them, for instance in 273 shaping and forwarding operations, must be specified. 275 4.3. Centralized Path Computation and Installation 277 A centralized routing model, such as provided with a PCE, enables 278 global and per-flow optimizations. The model is attractive but a 279 number of issues are left to be solved. In particular: 281 o whether and how the path computation can be installed by 1) an end 282 device or 2) a Network Management entity, 284 o and how the path is set up, either by installing state at each hop 285 with a direct interaction between the forwarding device and the 286 PCE, or along a path by injecting a source-routed request at one 287 end of the path following classical Traffic Engineering (TE) 288 models. 290 To enable a centralized model, DetNet should produce the complete SDN 291 architecture with describes at a high level the interaction and data 292 models to: 294 o report the topology and device capabilities to the central 295 controller; 297 o establish a direct interface between the centralized PCE to each 298 device under its control in order to enable a vertical signaling 300 o request a path setup for a new flow with particular 301 characteristics over the service interface and control it through 302 its life cycle; 304 o support for life cycle management for a path 305 (instantiate/modify/update/delete) 307 o support for adaptability to cope with various events such as loss 308 of a link, etc... 310 o expose the status of the path to the end devices (UNI interface) 312 o provide additional reliability through redundancy, in particular 313 with packet replication and elimination; 315 o indicate the flows and packet sequences in-band with the flows; 317 4.4. Distributed Path Setup 319 Whether a distributed alternative without a PCE can be valuable could 320 be studied as well. Such an alternative could for instance inherit 321 from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows. 322 But the focus of the work should be to deliver the centralized 323 approach first. 325 To enable a RSVP-TE like functionality, the following steps would 326 take place: 328 1. Neighbors and their capabilities are discovered and exposed to 329 compute a path that fits the DetNet constraints, typically of 330 latency, time precision and resource availability. 332 2. A constrained path is calculated with an improved version of CSPF 333 that is aware of DetNet. 335 3. The path is installed using RSVP-TE, associated with flow 336 identification, per-hop behavior such as replication and 337 elimination, blocked resources, and flow timing information. 339 4. Traffic flows are transported through the MPLS-TE tunnel, using 340 the reserved resources for this flow at each hop. 342 4.5. Duplicated data format 344 In some cases the duplication and elimination of packets over non- 345 congruent paths is required to achieve a sufficiently high delivery 346 ratio to meet application needs. In these cases, a small number of 347 packet formats and supporting protocols are required (preferably, 348 just one) to serialize the packets of a DetNet stream at one point in 349 the network, replicate them at one or more points in the network, and 350 discard duplicates at one or more other points in the network, 351 including perhaps the destination host. Using an existing solution 352 would be preferable to inventing a new one. 354 5. Security Considerations 356 Security in the context of Deterministic Networking has an added 357 dimension; the time of delivery of a packet can be just as important 358 as the contents of the packet, itself. A man-in-the-middle attack, 359 for example, can impose, and then systematically adjust, additional 360 delays into a link, and thus disrupt or subvert a real-time 361 application without having to crack any encryption methods employed. 362 See [RFC7384] for an exploration of this issue in a related context. 364 Typical control networks today rely on complete physical isolation to 365 prevent rogue access to network resources. DetNet enables the 366 virtualization of those networks over a converged IT/OT 367 infrastructure. Doing so, DetNet introduces an additional risk that 368 flows interact and interfere with one another as they share physical 369 resources such as Ethernet trunks and radio spectrum. The 370 requirement is that there is no possible data leak from and into a 371 deterministic flow, and in a more general fashion there is no 372 possible influence whatsoever from the outside on a deterministic 373 flow. The expectation is that physical resources are effectively 374 associated with a given flow at a given point of time. In that 375 model, Time Sharing of physical resources becomes transparent to the 376 individual flows which have no clue whether the resources are used by 377 other flows at other times. 379 Security must cover: 381 o the protection of the signaling protocol 383 o the authentication and authorization of the controlling nodes 385 o the identification and shaping of the flows 387 o the isolation of flows from leakage and other influences from any 388 activity sharing physical resources. 390 6. IANA Considerations 392 This document does not require an action from IANA. 394 7. Acknowledgments 396 The authors wish to thank Lou Berger, Jouni Korhonen, Erik Nordmark, 397 George Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas 398 Watteyne, Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried 399 Steiner, Marcel Kiessling, Karl Weber, Ethan Grossman, Patrick 400 Wetterwald, Subha Dhesikan, Rudy Klecka and Pat Thaler for their 401 various contribution to this work. 403 8. References 405 8.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 8.2. Informative References 414 [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and 415 certifies devices for interoperability, providing a simple 416 and reliable networking solution for AV network 417 implementation based on the IEEE Audio Video Bridging 418 (AVB) and Time-Sensitive Networking (TSN) standards.". 420 [CCAMP] IETF, "Common Control and Measurement Plane", 421 . 423 [EIP] http://www.odva.org/, "EtherNet/IP provides users with the 424 network tools to deploy standard Ethernet technology (IEEE 425 802.3 combined with the TCP/IP Suite) for industrial 426 automation applications while enabling Internet and 427 enterprise connectivity data anytime, anywhere.", 428 . 432 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 433 a group of specifications for industrial process and 434 control devices administered by the HART Foundation". 436 [I-D.finn-detnet-architecture] 437 Finn, N., Thubert, P., and M. Teener, "Deterministic 438 Networking Architecture", draft-finn-detnet- 439 architecture-03 (work in progress), March 2016. 441 [I-D.grossman-detnet-use-cases] 442 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 443 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. 444 Zha, "Deterministic Networking Use Cases", draft-grossman- 445 detnet-use-cases-01 (work in progress), November 2015. 447 [I-D.ietf-6tisch-architecture] 448 Thubert, P., "An Architecture for IPv6 over the TSCH mode 449 of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work 450 in progress), November 2015. 452 [I-D.ietf-roll-rpl-industrial-applicability] 453 Phinney, T., Thubert, P., and R. Assimiti, "RPL 454 applicability in industrial networks", draft-ietf-roll- 455 rpl-industrial-applicability-02 (work in progress), 456 October 2013. 458 [I-D.ietf-teas-yang-te-topo] 459 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 460 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 461 teas-yang-te-topo-02 (work in progress), October 2015. 463 [I-D.svshah-tsvwg-deterministic-forwarding] 464 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 465 draft-svshah-tsvwg-deterministic-forwarding-04 (work in 466 progress), August 2015. 468 [I-D.zhao-pce-pcep-extension-for-pce-controller] 469 Zhao, Q., Li, Z., Dhody, D., and C. Zhou, "PCEP Procedures 470 and Protocol Extensions for Using PCE as a Central 471 Controller (PCECC) of LSPs", draft-zhao-pce-pcep- 472 extension-for-pce-controller-03 (work in progress), March 473 2016. 475 [IEC62439] 476 IEC, "Industrial communication networks - High 477 availability automation networks - Part 3: Parallel 478 Redundancy Protocol (PRP) and High-availability Seamless 479 Redundancy (HSR) - IEC62439-3", 2012, 480 . 482 [IEEE802.1AS-2011] 483 IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)", 484 2011, . 487 [IEEE802.1BA-2011] 488 IEEE, "AVB Systems (IEEE 802.1BA-2011)", 2011, 489 . 492 [IEEE802.1Q-2011] 493 IEEE, "MAC Bridges and VLANs (IEEE 802.1Q-2011", 2011, 494 . 497 [IEEE802.1Qat-2010] 498 IEEE, "Stream Reservation Protocol (IEEE 802.1Qat-2010)", 499 2010, . 502 [IEEE802.1Qav] 503 IEEE, "Forwarding and Queuing (IEEE 802.1Qav-2009)", 2009, 504 . 507 [IEEE802.1TSNTG] 508 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 509 Networks Task Group", 2013, 510 . 512 [IEEE802154] 513 IEEE standard for Information Technology, "IEEE std. 514 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 515 and Physical Layer (PHY) Specifications for Low-Rate 516 Wireless Personal Area Networks". 518 [IEEE802154e] 519 IEEE standard for Information Technology, "IEEE std. 520 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 521 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 522 2012. 524 [ISA100.11a] 525 ISA/IEC, "ISA100.11a, Wireless Systems for Automation, 526 also IEC 62734", 2011, < http://www.isa100wci.org/en- 527 US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- 528 WEB-ETSI.aspx>. 530 [ISA95] ANSI/ISA, "Enterprise-Control System Integration Part 1: 531 Models and Terminology", 2000, . 534 [MPLS] IETF, "Multiprotocol Label Switching", 535 . 537 [ODVA] http://www.odva.org/, "The organization that supports 538 network technologies built on the Common Industrial 539 Protocol (CIP) including EtherNet/IP.". 541 [PCE] IETF, "Path Computation Element", 542 . 544 [Profinet] 545 http://us.profinet.com/technology/profinet/, "PROFINET is 546 a standard for industrial networking in automation.", 547 . 549 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 550 DOI 10.17487/RFC2547, March 1999, 551 . 553 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 554 McManus, "Requirements for Traffic Engineering Over MPLS", 555 RFC 2702, DOI 10.17487/RFC2702, September 1999, 556 . 558 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 559 Label Switching Architecture", RFC 3031, 560 DOI 10.17487/RFC3031, January 2001, 561 . 563 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 564 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 565 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 566 . 568 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 569 Xiao, "Overview and Principles of Internet Traffic 570 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 571 . 573 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 574 (TE) Extensions to OSPF Version 2", RFC 3630, 575 DOI 10.17487/RFC3630, September 2003, 576 . 578 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 579 Switching (GMPLS) Architecture", RFC 3945, 580 DOI 10.17487/RFC3945, October 2004, 581 . 583 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 584 Edge-to-Edge (PWE3) Architecture", RFC 3985, 585 DOI 10.17487/RFC3985, March 2005, 586 . 588 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 589 Support of Generalized Multi-Protocol Label Switching 590 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 591 . 593 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 594 Element (PCE)-Based Architecture", RFC 4655, 595 DOI 10.17487/RFC4655, August 2006, 596 . 598 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 599 2 Virtual Private Networks (L2VPNs)", RFC 4664, 600 DOI 10.17487/RFC4664, September 2006, 601 . 603 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 604 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 605 February 2008, . 607 [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter- 608 Domain MPLS and GMPLS Traffic Engineering -- Resource 609 Reservation Protocol-Traffic Engineering (RSVP-TE) 610 Extensions", RFC 5151, DOI 10.17487/RFC5151, February 611 2008, . 613 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 614 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 615 2008, . 617 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 618 "Traffic Engineering Extensions to OSPF Version 3", 619 RFC 5329, DOI 10.17487/RFC5329, September 2008, 620 . 622 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 623 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 624 DOI 10.17487/RFC5440, March 2009, 625 . 627 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 628 Phinney, "Industrial Routing Requirements in Low-Power and 629 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 630 2009, . 632 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 633 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 634 October 2014, . 636 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 637 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 638 Defined Networking (SDN): Layers and Architecture 639 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 640 2015, . 642 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 643 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 644 Internet of Things (IoT): Problem Statement", RFC 7554, 645 DOI 10.17487/RFC7554, May 2015, 646 . 648 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 649 . 651 [TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4", 652 . 654 [WirelessHART] 655 www.hartcomm.org, "Industrial Communication Networks - 656 Wireless Communication Network and Communication Profiles 657 - WirelessHART - IEC 62591", 2010. 659 Authors' Addresses 661 Norm Finn 662 Cisco Systems 663 510 McCarthy Blvd 664 SJ-24 665 Milpitas, California 95035 666 USA 668 Phone: +1 408 526 4495 669 Email: nfinn@cisco.com 671 Pascal Thubert 672 Cisco Systems 673 Village d'Entreprises Green Side 674 400, Avenue de Roumanille 675 Batiment T3 676 Biot - Sophia Antipolis 06410 677 FRANCE 679 Phone: +33 4 97 23 26 34 680 Email: pthubert@cisco.com