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