RFC 8578
Deterministic Networking Use Cases
Pages: 97
Informational
Informational
Part 1 of 8 – Pages 1 to 13
Internet Engineering Task Force (IETF) E. Grossman, Ed. Request for Comments: 8578 DOLBY Category: Informational May 2019 ISSN: 2070-1721 Deterministic Networking Use CasesAbstract
This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8578.
Copyright Notice Copyright (c) 2019 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 (https://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 ....................................................6 2. Pro Audio and Video .............................................7 2.1. Use Case Description .......................................7 2.1.1. Uninterrupted Stream Playback .......................8 2.1.2. Synchronized Stream Playback ........................9 2.1.3. Sound Reinforcement .................................9 2.1.4. Secure Transmission ................................10 2.1.4.1. Safety ....................................10 2.2. Pro Audio Today ...........................................10 2.3. Pro Audio in the Future ...................................10 2.3.1. Layer 3 Interconnecting Layer 2 Islands ............10 2.3.2. High-Reliability Stream Paths ......................11 2.3.3. Integration of Reserved Streams into IT Networks ...11 2.3.4. Use of Unused Reservations by Best-Effort Traffic ..11 2.3.5. Traffic Segregation ................................11 2.3.5.1. Packet-Forwarding Rules, VLANs, and Subnets ...............................12 2.3.5.2. Multicast Addressing (IPv4 and IPv6) ......12 2.3.6. Latency Optimization by a Central Controller .......12 2.3.7. Reduced Device Costs due to Reduced Buffer Memory ..13 2.4. Pro Audio Requests to the IETF ............................13 3. Electrical Utilities ...........................................14 3.1. Use Case Description ......................................14 3.1.1. Transmission Use Cases .............................14 3.1.1.1. Protection ................................14 3.1.1.2. Intra-substation Process Bus Communications ............................21 3.1.1.3. Wide-Area Monitoring and Control Systems ..23 3.1.1.4. WAN Engineering Guidelines Requirement Classification ................25
3.1.2. Generation Use Case ................................26
3.1.2.1. Control of the Generated Power ............26
3.1.2.2. Control of the Generation Infrastructure ..27
3.1.3. Distribution Use Case ..............................32
3.1.3.1. Fault Location, Isolation, and
Service Restoration (FLISR) ...............32
3.2. Electrical Utilities Today ................................33
3.2.1. Current Security Practices and Their Limitations ...34
3.3. Electrical Utilities in the Future ........................35
3.3.1. Migration to Packet-Switched Networks ..............36
3.3.2. Telecommunications Trends ..........................37
3.3.2.1. General Telecommunications Requirements ...37
3.3.2.2. Specific Network Topologies of
Smart-Grid Applications ...................38
3.3.2.3. Precision Time Protocol ...................38
3.3.3. Security Trends in Utility Networks ................39
3.4. Electrical Utilities Requests to the IETF .................41
4. Building Automation Systems (BASs) .............................41
4.1. Use Case Description ......................................41
4.2. BASs Today ................................................42
4.2.1. BAS Architecture ...................................42
4.2.2. BAS Deployment Model ...............................44
4.2.3. Use Cases for Field Networks .......................45
4.2.3.1. Environmental Monitoring ..................45
4.2.3.2. Fire Detection ............................46
4.2.3.3. Feedback Control ..........................46
4.2.4. BAS Security Considerations ........................46
4.3. BASs in the Future ........................................46
4.4. BAS Requests to the IETF ..................................47
5. Wireless for Industrial Applications ...........................47
5.1. Use Case Description ......................................47
5.1.1. Network Convergence Using 6TiSCH ...................48
5.1.2. Common Protocol Development for 6TiSCH .............48
5.2. Wireless Industrial Today .................................49
5.3. Wireless Industrial in the Future .........................49
5.3.1. Unified Wireless Networks and Management ...........49
5.3.1.1. PCE and 6TiSCH ARQ Retries ................51
5.3.2. Schedule Management by a PCE .......................52
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests .....52
5.3.2.2. 6TiSCH IP Interface .......................54
5.3.3. 6TiSCH Security Considerations .....................54
5.4. Wireless Industrial Requests to the IETF ..................54
6. Cellular Radio .................................................54 6.1. Use Case Description ......................................54 6.1.1. Network Architecture ...............................54 6.1.2. Delay Constraints ..................................55 6.1.3. Time-Synchronization Constraints ...................57 6.1.4. Transport-Loss Constraints .........................59 6.1.5. Cellular Radio Network Security Considerations .....60 6.2. Cellular Radio Networks Today .............................60 6.2.1. Fronthaul ..........................................60 6.2.2. Midhaul and Backhaul ...............................60 6.3. Cellular Radio Networks in the Future .....................61 6.4. Cellular Radio Networks Requests to the IETF ..............64 7. Industrial Machine to Machine (M2M) ............................64 7.1. Use Case Description ......................................64 7.2. Industrial M2M Communications Today .......................66 7.2.1. Transport Parameters ...............................66 7.2.2. Stream Creation and Destruction ....................67 7.3. Industrial M2M in the Future ..............................67 7.4. Industrial M2M Requests to the IETF .......................67 8. Mining Industry ................................................68 8.1. Use Case Description ......................................68 8.2. Mining Industry Today .....................................68 8.3. Mining Industry in the Future .............................69 8.4. Mining Industry Requests to the IETF ......................70 9. Private Blockchain .............................................70 9.1. Use Case Description ......................................70 9.1.1. Blockchain Operation ...............................71 9.1.2. Blockchain Network Architecture ....................71 9.1.3. Blockchain Security Considerations .................72 9.2. Private Blockchain Today ..................................72 9.3. Private Blockchain in the Future ..........................72 9.4. Private Blockchain Requests to the IETF ...................72 10. Network Slicing ...............................................73 10.1. Use Case Description .....................................73 10.2. DetNet Applied to Network Slicing ........................73 10.2.1. Resource Isolation across Slices ..................73 10.2.2. Deterministic Services within Slices ..............74 10.3. A Network Slicing Use Case Example - 5G Bearer Network ...74 10.4. Non-5G Applications of Network Slicing ...................75 10.5. Limitations of DetNet in Network Slicing .................75 10.6. Network Slicing Today and in the Future ..................75 10.7. Network Slicing Requests to the IETF .....................75 11. Use Case Common Themes ........................................76 11.1. Unified, Standards-Based Networks ........................76 11.1.1. Extensions to Ethernet ............................76 11.1.2. Centrally Administered Networks ...................76 11.1.3. Standardized Data-Flow Information Models .........76
11.1.4. Layer 2 and Layer 3 Integration ...................76
11.1.5. IPv4 Considerations ...............................76
11.1.6. Guaranteed End-to-End Delivery ....................77
11.1.7. Replacement for Multiple Proprietary
Deterministic Networks ............................77
11.1.8. Mix of Deterministic and Best-Effort Traffic ......77
11.1.9. Unused Reserved Bandwidth to Be Available
to Best-Effort Traffic ............................77
11.1.10. Lower-Cost, Multi-Vendor Solutions ...............77
11.2. Scalable Size ............................................78
11.2.1. Scalable Number of Flows ..........................78
11.3. Scalable Timing Parameters and Accuracy ..................78
11.3.1. Bounded Latency ...................................78
11.3.2. Low Latency .......................................78
11.3.3. Bounded Jitter (Latency Variation) ................79
11.3.4. Symmetrical Path Delays ...........................79
11.4. High Reliability and Availability ........................79
11.5. Security .................................................79
11.6. Deterministic Flows ......................................79
12. Security Considerations .......................................80
13. IANA Considerations ...........................................80
14. Informative References ........................................80
Appendix A. Use Cases Explicitly Out of Scope for DetNet ..........90
A.1. DetNet Scope Limitations ...................................90
A.2. Internet-Based Applications ................................90
A.2.1. Use Case Description ...................................91
A.2.1.1. Media Content Delivery .............................91
A.2.1.2. Online Gaming ......................................91
A.2.1.3. Virtual Reality ....................................91
A.2.2. Internet-Based Applications Today ......................91
A.2.3. Internet-Based Applications in the Future ..............91
A.2.4. Internet-Based Applications Requests to the IETF .......92
A.3. Pro Audio and Video - Digital Rights Management (DRM) ......92
A.4. Pro Audio and Video - Link Aggregation .....................92
A.5. Pro Audio and Video - Deterministic Time to Establish
Streaming ..................................................93
Acknowledgments ...................................................93
Contributors ......................................................95
Author's Address ..................................................97
1. Introduction
This memo documents use cases for diverse industries that require deterministic flows over multi-hop paths. Deterministic Networking (DetNet) flows can be established from either a Layer 2 or Layer 3 (IP) interface, and such flows can coexist on an IP network with best-effort traffic. DetNet also provides for highly reliable flows through provision for redundant paths. The DetNet use cases explicitly do not suggest any specific design for DetNet architecture or protocols; these are topics for other DetNet documents. The DetNet use cases, as originally submitted, explicitly were not considered by the DetNet Working Group (WG) to be concrete requirements. The DetNet WG and Design Team considered these use cases, identifying which of their elements could be feasibly implemented within the charter of DetNet; as a result, certain originally submitted use cases (or elements thereof) were moved to Appendix A ("Use Cases Explicitly Out of Scope for DetNet") of this document. This document provides context regarding DetNet design decisions. It also serves a long-lived purpose of helping those learning (or new to) DetNet understand the types of applications that can be supported by DetNet. It also allows those WG contributors who are users to ensure that their concerns are addressed by the WG; for them, this document (1) covers their contributions and (2) provides a long-term reference regarding the problems that they expect will be served by the technology, in terms of the short-term deliverables and also as the technology evolves in the future. This document has served as a "yardstick" against which proposed DetNet designs can be measured, answering the question "To what extent does a proposed design satisfy these various use cases?" The industries covered by the use cases in this document are o professional audio and video (Section 2) o electrical utilities (Section 3) o building automation systems (BASs) (Section 4) o wireless for industrial applications (Section 5) o cellular radio (Section 6)
o industrial machine to machine (M2M) (Section 7) o mining (Section 8) o private blockchain (Section 9) o network slicing (Section 10) For each use case, the following questions are answered: o What is the use case? o How is it addressed today? o How should it be addressed in the future? o What should the IETF deliver to enable this use case? The level of detail in each use case is intended to be sufficient to express the relevant elements of the use case but no more than that. DetNet does not directly address clock distribution or time synchronization; these are considered to be part of the overall design and implementation of a time-sensitive network, using existing (or future) time-specific protocols (such as [IEEE-8021AS] and/or [RFC5905]). Section 11 enumerates the set of common properties implied by these use cases.2. Pro Audio and Video
2.1. Use Case Description
The professional audio and video industry ("ProAV") includes: o Music and film content creation o Broadcast o Cinema o Live sound o Public address, media, and emergency systems at large venues (e.g., airports, stadiums, churches, theme parks)
These industries have already transitioned audio and video signals
from analog to digital. However, the digital interconnect systems
remain primarily point to point, with a single signal or a small
number of signals per link, interconnected with purpose-built
hardware.
These industries are now transitioning to packet-based
infrastructures to reduce cost, increase routing flexibility, and
integrate with existing IT infrastructures.
Today, ProAV applications have no way to establish deterministic
flows from a standards-based Layer 3 (IP) interface; this is a
fundamental limitation of the use cases described here. Today,
deterministic flows can be created within standards-based Layer 2
LANs (e.g., using IEEE 802.1 TSN ("TSN" stands for "Time-Sensitive
Networking")); however, these flows are not routable via IP and thus
are not effective for distribution over wider areas (for example,
broadcast events that span wide geographical areas).
It would be highly desirable if such flows could be routed over the
open Internet; however, solutions of more-limited scope (e.g.,
enterprise networks) would still provide substantial improvements.
The following sections describe specific ProAV use cases.
2.1.1. Uninterrupted Stream Playback
Transmitting audio and video streams for live playback is unlike
common file transfer in that uninterrupted stream playback in the
presence of network errors cannot be achieved by retrying the
transmission; by the time the missing or corrupt packet has been
identified, it is too late to execute a retry operation. Buffering
can be used to provide enough delay to allow time for one or more
retries; however, this is not an effective solution in applications
where large delays (latencies) are not acceptable (as discussed
below).
Streams with guaranteed bandwidth can eliminate congestion on the
network as a cause of transmission errors that would lead to playback
interruption. The use of redundant paths can further mitigate
transmission errors and thereby provide greater stream reliability.
Additional techniques, such as Forward Error Correction (FEC), can
also be used to improve stream reliability.
2.1.2. Synchronized Stream Playback
Latency in this context is the time between when a signal is initially sent over a stream and when it is received. A common example in ProAV is time-synchronizing audio and video when they take separate paths through the playback system. In this case, the latency of both the audio stream and the video stream must be bounded and consistent if the sound is to remain matched to the movement in the video. A common tolerance for audio/video synchronization is one National Television System Committee (NTSC) video frame (about 33 ms); to maintain the audience's perception of correct lip-sync, the latency needs to be consistent within some reasonable tolerance -- for example, 10%. A common architecture for synchronizing multiple streams that have different paths through the network (and thus potentially different latencies) enables measurement of the latency of each path and has the data sinks (for example, speakers) delay (buffer) all packets on all but the slowest path. Each packet of each stream is assigned a presentation time that is based on the longest required delay. This implies that all sinks must maintain a common time reference of sufficient accuracy, which can be achieved by various techniques. This type of architecture is commonly implemented using a central controller that determines path delays and arbitrates buffering delays.2.1.3. Sound Reinforcement
Consider the latency (delay) between the time when a person speaks into a microphone and when their voice emerges from the speaker. If this delay is longer than about 10-15 ms, it is noticeable and can make a sound-reinforcement system unusable (see slide 6 of [SRP_LATENCY]). (If you have ever tried to speak in the presence of a delayed echo of your voice, you might be familiar with this experience.) Note that the 15 ms latency bound includes all parts of the signal path -- not just the network -- so the network latency must be significantly less than 15 ms. In some cases, local performers must perform in synchrony with a 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 (33 ms for NTSC video).
In cases where audio phase is a consideration -- for example, beam-forming using multiple speakers -- latency can be in the 10 us range (one audio sample at 96 kHz).2.1.4. Secure Transmission
2.1.4.1. Safety
Professional audio systems can include amplifiers that are capable of generating hundreds or thousands of watts of audio power. If used incorrectly, such amplifiers 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 devices must be secured (as with any sensitive application traffic).2.2. Pro Audio Today
Some proprietary systems have been created that enable deterministic streams at Layer 3; however, they are "engineered networks" that require careful configuration to operate and often require that the system be over-provisioned. Also, it is implied that all devices on the network voluntarily play by the rules of that network. To enable these industries to successfully transition to an interoperable multi-vendor packet-based infrastructure requires effective open standards. Establishing relevant IETF standards is a crucial factor.2.3. Pro Audio in the Future
2.3.1. Layer 3 Interconnecting Layer 2 Islands
It would be valuable to enable IP to connect multiple Layer 2 LANs. As an example, ESPN constructed a state-of-the-art 194,000 sq. ft., $125-million broadcast studio called "Digital Center 2" (DC2). The DC2 network is capable of handling 46 Tbps of throughput with 60,000 simultaneous signals. Inside the facility are 1,100 miles of fiber feeding four audio control rooms (see [ESPN_DC2]). In designing DC2, they replaced as much point-to-point technology as they could with packet-based technology. They constructed seven individual studios using Layer 2 LANs (using IEEE 802.1 TSN) that were entirely effective at routing audio within the LANs. However, to interconnect these Layer 2 LAN islands together, they ended up using dedicated paths in a custom SDN (Software-Defined Networking) router because there is no standards-based routing solution available.
2.3.2. High-Reliability Stream Paths
On-air and other live media streams are often backed up with redundant links that seamlessly act to deliver the content when the primary link fails for any reason. In point-to-point systems, this redundancy is provided by an additional point-to-point link; the analogous requirement in a packet-based system is to provide an alternate path through the network such that no individual link can bring down the system.2.3.3. Integration of Reserved Streams into IT Networks
A commonly cited goal of moving to a packet-based media infrastructure is that costs can be reduced by using off-the-shelf, commodity-network hardware. In addition, economy of scale can be realized by combining media infrastructure with IT infrastructure. In keeping with these goals, stream-reservation technology should be compatible with existing protocols and should not compromise the use of the network for best-effort (non-time-sensitive) traffic.2.3.4. Use of Unused Reservations by Best-Effort Traffic
In cases where stream bandwidth is reserved but not currently used (or is underutilized), that bandwidth must be available to best-effort (i.e., non-time-sensitive) traffic. For example, a single stream may be "nailed up" (reserved) for specific media content that needs to be presented at different times of the day, ensuring timely delivery of that content, yet in between those times the full bandwidth of the network can be utilized for best-effort tasks such as file transfers. This also addresses a concern of IT network administrators that are considering adding reserved-bandwidth traffic to their networks that "users will reserve large quantities of bandwidth and then never unreserve it even though they are not using it, and soon the network will have no bandwidth left."2.3.5. Traffic Segregation
Sink devices may be low-cost devices with limited processing power. In order to not overwhelm the CPUs in these devices, it is important to limit the amount of traffic that these devices must process. As an example, consider the use of individual seat speakers in a cinema. These speakers are typically required to be cost reduced, since the quantities in a single theater can reach hundreds of seats. Discovery protocols alone in a 1,000-seat theater can generate enough broadcast traffic to overwhelm a low-powered CPU. Thus, an
installation like this will benefit greatly from some type of traffic segregation that can define groups of seats to reduce traffic within each group. All seats in the theater must still be able to communicate with a central controller. There are many techniques that can be used to support this feature, including (but not limited to) the following examples.2.3.5.1. Packet-Forwarding Rules, VLANs, and Subnets
Packet-forwarding rules can be used to eliminate some extraneous streaming traffic from reaching potentially low-powered sink devices; however, there may be other types of broadcast traffic that should be eliminated via other means -- for example, VLANs or IP subnets.2.3.5.2. Multicast Addressing (IPv4 and IPv6)
Multicast addressing is commonly used to keep bandwidth utilization of shared links to a minimum. Because Layer 2 bridges by design forward Media Access Control (MAC) addresses, it is important that a multicast MAC address only be associated with one stream. This will prevent reservations from forwarding packets from one stream down a path that has no interested sinks simply because there is another stream on that same path that shares the same multicast MAC address. In other words, since each multicast MAC address can represent 32 different IPv4 multicast addresses, there must be a process in place to make sure that any given multicast MAC address is only associated with exactly one IPv4 multicast address. Requiring the use of IPv6 addresses could help in this regard, due to the much larger address range of IPv6; however, due to the continued prevalence of IPv4 installations, solutions that are effective for IPv4 installations would be practical in many more use cases.2.3.6. Latency Optimization by a Central Controller
A central network controller might also perform optimizations based on the individual path delays; for example, sinks that are closer to the source can inform the controller that they can accept greater latency, since they will be buffering packets to match presentation times of sinks that are farther away. The controller might then move a stream reservation on a short path to a longer path in order to free up bandwidth for other critical streams on that short path. See slides 3-5 of [SRP_LATENCY].
Additional optimization can be achieved in cases where sinks have differing latency requirements; for example, at a live outdoor concert, the speaker sinks have stricter latency requirements than the recording-hardware sinks. See slide 7 of [SRP_LATENCY].2.3.7. Reduced Device Costs due to Reduced Buffer Memory
Device costs can be reduced in a system with guaranteed reservations with a small bounded latency due to the reduced requirements for buffering (i.e., memory) on sink devices. For example, a theme park might broadcast a live event across the globe via a Layer 3 protocol. In such cases, the size of the buffers required is defined by the worst-case latency and jitter values of the worst-case segment of the end-to-end network path. For example, on today's open Internet, the latency is typically unacceptable for audio and video streaming without many seconds of buffering. In such scenarios, a single gateway device at the local network that receives the feed from the remote site would provide the expensive buffering required to mask the latency and jitter issues associated with long-distance delivery. Sink devices in the local location would have no additional buffering requirements, and thus no additional costs, beyond those required for delivery of local content. The sink device would be receiving packets identical to those sent by the source and would be unaware of any latency or jitter issues along the path.2.4. Pro Audio Requests to the IETF
o Layer 3 routing on top of Audio Video Bridging (AVB) (and/or other high-QoS (Quality of Service) networks) o Content delivery with bounded, lowest possible latency o IntServ and DiffServ integration with AVB (where practical) o Single network for A/V and IT traffic o Standards-based, interoperable, multi-vendor solutions o IT-department-friendly networks o Enterprise-wide networks (e.g., the size of San Francisco but not the whole Internet (yet...))
(next page on part 2)