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