--- 1/draft-ietf-detnet-use-cases-11.txt 2017-04-03 22:13:09.747623351 -0700 +++ 2/draft-ietf-detnet-use-cases-12.txt 2017-04-03 22:13:09.903627024 -0700 @@ -1,15 +1,15 @@ Internet Engineering Task Force E. Grossman, Ed. Internet-Draft DOLBY Intended status: Informational C. Gunther -Expires: April 6, 2017 HARMAN +Expires: October 5, 2017 HARMAN P. Thubert P. Wetterwald CISCO J. Raymond HYDRO-QUEBEC J. Korhonen BROADCOM Y. Kaneko Toshiba S. Das @@ -23,24 +23,24 @@ J. Schmitt Siemens X. Vilajosana Worldsensing T. Mahmoodi King's College London S. Spirou Intracom Telecom P. Vizarreta Technical University of Munich, TUM - October 3, 2016 + April 3, 2017 Deterministic Networking Use Cases - draft-ietf-detnet-use-cases-11 + draft-ietf-detnet-use-cases-12 Abstract This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. @@ -63,45 +63,45 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 6, 2017. + This Internet-Draft will expire on October 5, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Pro Audio and Video . . . . . . . . . . . . . . . . . . . . . 6 2.1. Use Case Description . . . . . . . . . . . . . . . . . . 6 - 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 6 + 2.1.1. Uninterrupted Stream Playback . . . . . . . . . . . . 7 2.1.2. Synchronized Stream Playback . . . . . . . . . . . . 7 - 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 7 + 2.1.3. Sound Reinforcement . . . . . . . . . . . . . . . . . 8 2.1.4. Deterministic Time to Establish Streaming . . . . . . 8 2.1.5. Secure Transmission . . . . . . . . . . . . . . . . . 8 2.1.5.1. Safety . . . . . . . . . . . . . . . . . . . . . 8 2.2. Pro Audio Today . . . . . . . . . . . . . . . . . . . . . 9 2.3. Pro Audio Future . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 9 2.3.2. High Reliability Stream Paths . . . . . . . . . . . . 9 2.3.3. Integration of Reserved Streams into IT Networks . . 9 2.3.4. Use of Unused Reservations by Best-Effort Traffic . . 10 2.3.5. Traffic Segregation . . . . . . . . . . . . . . . . . 10 @@ -172,44 +172,65 @@ 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 54 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 55 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 57 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 57 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 57 7.2. Industrial M2M Communication Today . . . . . . . . . . . 58 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 60 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 60 - 8. Use Case Common Elements . . . . . . . . . . . . . . . . . . 60 - 9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 61 - 9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 62 - 9.2. Internet-based Applications . . . . . . . . . . . . . . . 62 - 9.2.1. Use Case Description . . . . . . . . . . . . . . . . 62 - 9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 63 - 9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 63 - 9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 63 - 9.2.2. Internet-Based Applications Today . . . . . . . . . . 63 - 9.2.3. Internet-Based Applications Future . . . . . . . . . 63 - 9.2.4. Internet-Based Applications Asks . . . . . . . . . . 63 - 9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 64 - 9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 64 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 - 10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 65 - 10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 65 - 10.3. Building Automation Systems . . . . . . . . . . . . . . 65 - 10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 65 - 10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 66 - 10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 66 - 10.7. Internet Applications and CoMP . . . . . . . . . . . . . 66 - 10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 66 - 11. Informative References . . . . . . . . . . . . . . . . . . . 66 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 + 8. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 60 + 8.1. Unified, standards-based network . . . . . . . . . . . . 61 + 8.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 61 + 8.1.2. Centrally Administered . . . . . . . . . . . . . . . 61 + 8.1.3. Standardized Data Flow Information Models . . . . . . 61 + 8.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . . 61 + 8.1.5. Guaranteed End-to-End Delivery . . . . . . . . . . . 61 + 8.1.6. Replacement for Multiple Proprietary Deterministic + Networks . . . . . . . . . . . . . . . . . . . . . . 61 + 8.1.7. Mix of Deterministic and Best-Effort Traffic . . . . 62 + 8.1.8. Unused Reserved BW to be Available to Best Effort + Traffic . . . . . . . . . . . . . . . . . . . . . . . 62 + + 8.1.9. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 62 + 8.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . . 62 + 8.3. Scalable Timing Parameters and Accuracy . . . . . . . . . 62 + 8.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . . 62 + 8.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . . 63 + 8.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . . 63 + 8.4. High Reliability and Availability . . . . . . . . . . . . 63 + 8.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 63 + 8.6. Deterministic Flows . . . . . . . . . . . . . . . . . . . 64 + 9. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 64 + 9.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 64 + 9.2. Internet-based Applications . . . . . . . . . . . . . . . 65 + 9.2.1. Use Case Description . . . . . . . . . . . . . . . . 65 + 9.2.1.1. Media Content Delivery . . . . . . . . . . . . . 65 + 9.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . . 65 + 9.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . . 65 + 9.2.2. Internet-Based Applications Today . . . . . . . . . . 65 + 9.2.3. Internet-Based Applications Future . . . . . . . . . 65 + 9.2.4. Internet-Based Applications Asks . . . . . . . . . . 66 + 9.3. Pro Audio and Video - Digital Rights Management (DRM) . . 66 + 9.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 66 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 + 10.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 67 + 10.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 67 + 10.3. Building Automation Systems . . . . . . . . . . . . . . 67 + 10.4. Wireless for Industrial . . . . . . . . . . . . . . . . 67 + 10.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 68 + 10.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 68 + 10.7. Internet Applications and CoMP . . . . . . . . . . . . . 68 + 10.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 68 + 11. Informative References . . . . . . . . . . . . . . . . . . . 68 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 1. Introduction This draft presents use cases from diverse industries which have in common a need for deterministic streams, but which also differ notably in their network topologies and specific desired behavior. Together, they provide broad industry context for DetNet and a yardstick against which proposed DetNet designs can be measured (to what extent does a proposed design satisfy these various use cases?) @@ -337,43 +358,25 @@ remote broadcast. In such cases the latencies of the broadcast stream and the local performer must be adjusted to match each other, with a worst case of one video frame (33ms for NTSC video). In cases where audio phase is a consideration, for example beam- forming using multiple speakers, latency requirements can be in the 10 microsecond range (1 audio sample at 96kHz). 2.1.4. Deterministic Time to Establish Streaming - Note: It is still under WG discussion whether this topic (stream - startup time) is within scope of DetNet. - - Some audio systems installed in public environments (airports, - hospitals) have unique requirements with regards to health, safety - and fire concerns. One such requirement is a maximum of 3 seconds - for a system to respond to an emergency detection and begin sending - appropriate warning signals and alarms without human intervention. - For this requirement to be met, the system must support a bounded and - acceptable time from a notification signal to specific stream - establishment. For further details see [ISO7240-16]. - - Similar requirements apply when the system is restarted after a power - cycle, cable re-connection, or system reconfiguration. - - In many cases such re-establishment of streaming state must be - achieved by the peer devices themselves, i.e. without a central - controller (since such a controller may only be present during - initial network configuration). - - Video systems introduce related requirements, for example when - transitioning from one camera feed (video stream) to another (see - [STUDIO_IP] and [ESPN_DC2]). + Note: The WG has decided that guidelines for deterministic time to + establish stream startup is not within scope of DetNet. If bounded + timing of establishing or re-establish streams is required in a given + use case, it is up to the application/system to achieve this. (The + supporting text from this section has been removed as of draft 12). 2.1.5. Secure Transmission 2.1.5.1. Safety Professional audio systems can include amplifiers that are capable of generating hundreds or thousands of watts of audio power which if used incorrectly can cause hearing damage to those in the vicinity. Apart from the usual care required by the systems operators to prevent such incidents, the network traffic that controls these @@ -2334,22 +2337,22 @@ meet with point-to-point connected networks, and more difficult when the network includes multiple hops. It is expected that networks must include buffering at the ends of the connections as imposed by the jitter requirements, since trying to meet the jitter requirements in every intermediate node is likely to be too costly. However, every measure to reduce jitter and delay on the path makes it easier to meet the end-to-end requirements. In order to meet the timing requirements both senders and receivers must remain time synchronized, demanding very accurate clock - distribution, for example support for IEEE 1588 transparent clocks in - every intermediate node. + distribution, for example support for IEEE 1588 transparent clocks or + boundary clocks in every intermediate node. In cellular networks from the LTE radio era onward, phase synchronization is needed in addition to frequency synchronization ([TS36300], [TS23401]). 6.1.4. Transport Loss Constraints Fronthaul and Midhaul networks assume almost error-free transport. Errors can result in a reset of the radio interfaces, which can cause reduced throughput or broken radio connectivity for mobile customers. @@ -2691,63 +2694,176 @@ o High availability (presumably through redundancy) (99.999 %) o Low message delivery time (100us - 50ms) o Low packet loss (burstless, 0.1-1 %) o Security (e.g. prevent critical flows from being leaked between physically separated networks) -8. Use Case Common Elements +8. Use Case Common Themes - Looking at the use cases collectively, the following common desires - for the DetNet-based networks of the future emerge: + This section summarizes the expected properties of a DetNet network, + based on the use cases as described in this draft. - o Open standards-based network (replace various proprietary - networks, reduce cost, create multi-vendor market) +8.1. Unified, standards-based network - o Centrally administered (though such administration may be - distributed for scale and resiliency) +8.1.1. Extensions to Ethernet - o Integrates L2 (bridged) and L3 (routed) environments (independent - of the Link layer, e.g. can be used with Ethernet, 6TiSCH, etc.) + A DetNet network is not "a new kind of network" - it based on + extensions to existing Ethernet standards, including elements of IEEE + 802.1 AVB/TSN and related standards. Presumably it will be possible + to run DetNet over other underlying transports besides Ethernet, but + Ethernet is explicitly supported. - o Carries both deterministic and best-effort traffic (guaranteed - end-to-end delivery of deterministic flows, deterministic flows - isolated from each other and from best-effort traffic congestion, - unused deterministic BW available to best-effort traffic) +8.1.2. Centrally Administered - o Ability to add or remove systems from the network with minimal, - bounded service interruption (applications include replacement of - failed devices as well as plug and play) + In general a DetNet network is not expected to be "plug and play" - + it is expected that there is some centralized network configuration + and control system. Such a system may be in a single central + location, or it maybe distributed across multiple control entities + that function together as a unified control system for the network. + However, the ability to "hot swap" components (e.g. due to + malfunction) is similar enough to "plug and play" that this kind of + behavior may be expected in DetNet networks, depending on the + implementation. - o Uses standardized data flow information models capable of - expressing deterministic properties (models express device - capabilities, flow properties. Protocols for pushing models from - controller to devices, devices to controller) +8.1.3. Standardized Data Flow Information Models - o Scalable size (long distances (many km) and short distances - (within a single machine), many hops (radio repeaters, microwave - links, fiber links...) and short hops (single machine)) + Data Flow Information Models to be used with DetNet networks are to + be specified by DetNet. - o Scalable timing parameters and accuracy (bounded latency, - guaranteed worst case maximum, minimum. Low latency, e.g. control - loops may be less than 1ms, but larger for wide area networks) +8.1.4. L2 and L3 Integration - o High availability (99.9999 percent up time requested, but may be - up to twelve 9s) + A DetNet network is intended to integrate between Layer 2 (bridged) + network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g. + using IP-based protocols). One example of this is "making AVB/TSN- + type deterministic performance available from Layer 3 applications, + e.g. using RTP". Another example is "connecting two AVB/TSN LANs + ("islands") together through a standard router". - o Reliability, redundancy (lives at stake) +8.1.5. Guaranteed End-to-End Delivery - o Security (from failures, attackers, misbehaving devices - - sensitive to both packet content and arrival time) + Packets sent over DetNet are guaranteed not to be dropped by the + network due to congestion. (Packets may however be dropped for + intended reasons, e.g. per security measures). + +8.1.6. Replacement for Multiple Proprietary Deterministic Networks + + There are many proprietary non-interoperable deterministic Ethernet- + based networks currently available; DetNet is intended to provide an + open-standards-based alternative to such networks. + +8.1.7. Mix of Deterministic and Best-Effort Traffic + + DetNet is intended to support coexistance of time-sensitive + operational (OT) traffic and information (IT) traffic on the same + ("unified") network. + +8.1.8. Unused Reserved BW to be Available to Best Effort Traffic + + If bandwidth reservations are made for a stream but the associated + bandwidth is not used at any point in time, that bandwidth is made + available on the network for best-effort traffic. If the owner of + the reserved stream then starts transmitting again, the bandwidth is + no longer available for best-effort traffic, on a moment-to-moment + basis. Note that such "temporarily available" bandwidth is not + available for time-sensitive traffic, which must have its own + reservation. + +8.1.9. Lower Cost, Multi-Vendor Solutions + + The DetNet network specifications are intended to enable an ecosystem + in which multiple vendors can create interoperable products, thus + promoting device diversity and potentially higher numbers of each + device manufactured, promoting cost reduction and cost competition + among vendors. The intent is that DetNet networks should be able to + be created at lower cost and with greater diversity of available + devices than existing proprietary networks. + +8.2. Scalable Size + + DetNet networks range in size from very small, e.g. inside a single + industrial machine, to very large, for example a Utility Grid network + spanning a whole country, and involving many "hops" over various + kinds of links for example radio repeaters, microwave linkes, fiber + optic links, etc.. However recall that the scope of DetNet is + confined to networks that are centrally administered, and explicitly + excludes unbounded decentralized networks such as the Internet. + +8.3. Scalable Timing Parameters and Accuracy + +8.3.1. Bounded Latency + + The DetNet Data Flow Information Model is expected to provide means + to configure the network that include parameters for querying network + path latency, requesting bounded latency for a given stream, + requesting worst case maximum and/or minimum latency for a given path + or stream, and so on. It is an expected case that the network may + not be able to provide a given requested service level, and if so the + network control system should reply that the requested services is + not available (as opposed to accepting the parameter but then not + delivering the desired behavior). + +8.3.2. Low Latency + + Applications may require "extremely low latency" however depending on + the application these may mean very different latency values; for + example "low latency" across a Utility grid network is on a different + time scale than "low latency" in a motor control loop in a small + machine. The intent is that the mechanisms for specifying desired + latency include wide ranges, and that architecturally there is + nothing to prevent arbirtrarily low latencies from being implemented + in a given network. + +8.3.3. Symmetrical Path Delays + + Some applications would like to specify that the transit delay time + values be equal for both the transmit and return paths. + +8.4. High Reliability and Availability + + Reliablity is of critical importance to many DetNet applications, in + which consequences of failure can be extraordinarily high in terms of + cost and even human life. DetNet based systems are expected to be + implemented with essentially arbitrarily high availability (for + example 99.9999% up time, or even 12 nines). The intent is that the + DetNet designs should not make any assumptions about the level of + reliability and availability that may be required of a given system, + and should define parameters for communicating these kinds of metrics + within the network. + + A strategy used by DetNet for providing such extraordinarily high + levels of reliability is to provide redundant paths that can be + seamlessly switched between, while maintaining the required + performance of that system. + +8.5. Security + + Security is of critical importance to many DetNet applications. A + DetNet network must be able to be made secure against devices + failures, attackers, misbehaving devices, and so on. In a DetNet + network the data traffic is expected to be be time-sensitive, thus in + addition to arriving with the data content as intended, the data must + also arrive at the expected time. This may present "new" security + challenges to implementers, and must be addressed accordingly. There + are other security implications, including (but not limited to) the + change in attack surface presented by packet replication and + elimination. + +8.6. Deterministic Flows + + Reserved bandwidth data flows must be isolated from each other and + from best-effort traffic, so that even if the network is saturated + with best-effort (and/or reserved bandwidth) traffic, the configured + flows are not adversely affected. 9. Use Cases Explicitly Out of Scope for DetNet This section contains use case text that has been determined to be outside of the scope of the present DetNet work. 9.1. DetNet Scope Limitations The scope of DetNet is deliberately limited to specific use cases that are consistent with the WG charter, subject to the @@ -3033,44 +3149,44 @@ Statement", draft-finn-detnet-problem-statement-05 (work in progress), March 2016. [I-D.ietf-6tisch-6top-interface] Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer (6top) Interface", draft-ietf-6tisch-6top-interface-04 (work in progress), July 2015. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work - in progress), June 2016. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work + in progress), January 2017. [I-D.ietf-6tisch-coap] Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", draft-ietf-6tisch-coap-03 (work in progress), March 2015. [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE - 802.15.4e", draft-ietf-6tisch-terminology-07 (work in - progress), March 2016. + 802.15.4e", draft-ietf-6tisch-terminology-08 (work in + progress), December 2016. [I-D.ietf-ipv6-multilink-subnets] Thaler, D. and C. Huitema, "Multi-link Subnet Support in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in progress), July 2002. [I-D.ietf-mpls-residence-time] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., and S. Vainshtein, "Residence Time Measurement in MPLS - network", draft-ietf-mpls-residence-time-11 (work in - progress), July 2016. + network", draft-ietf-mpls-residence-time-15 (work in + progress), March 2017. [I-D.ietf-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", draft-ietf-roll- rpl-industrial-applicability-02 (work in progress), October 2013. [I-D.ietf-tictoc-1588overmpls] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS