Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: DETNET

RFC 8578

Deterministic Networking Use Cases

Pages: 97
Informational
Part 1 of 8 – Pages 1 to 13
None   None   Next

Top   ToC   Page 1
Internet Engineering Task Force (IETF)                  E. Grossman, Ed.
Request for Comments: 8578                                         DOLBY
Category: Informational                                         May 2019
ISSN: 2070-1721


                   Deterministic Networking Use Cases

Abstract

   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.
Top   ToC   Page 2
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
Top   ToC   Page 3
           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
Top   ToC   Page 4
   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
Top   ToC   Page 5
           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
Top   ToC   Page 6
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)
Top   ToC   Page 7
   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)
Top   ToC   Page 8
   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.
Top   ToC   Page 9
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).
Top   ToC   Page 10
   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.
Top   ToC   Page 11
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
Top   ToC   Page 12
   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].
Top   ToC   Page 13
   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 Section