RFC 8578
Deterministic Networking Use Cases
Part 1 of 22 🎀
Deterministic Networking Use Cases 🦋
Okay bestie, this is RFC 8578 from the IETF (Internet Engineering Task Force) 💖. It's a Request for Comments, so this is the doc where the IETF writes stuff down for everyone. The editor is E. Grossman, Ed. from DOLBY, the category is Informational 📚, and it's dated May 2019. The ISSN is 2070-1721. The title block doesn't list anything this document obsoletes or updates, so there's no drama there 💅.
Abstract ✨
Okay so this doc is all about use cases from different industries that all need "deterministic flows" 🧚. "Deterministic" here means these flows get guaranteed bandwidth, bounded latency, and other stuff that matters when you're moving time-sensitive data. The use cases have pretty different network topologies and wildly different behavior, so together they give the whole industry context for Deterministic Networking (DetNet) 🌈. For each use case, the doc will name the use case, point out representative solutions people use today, and describe the improvements DetNet can enable. It's giving organized and thorough 💜.
Status of This Memo 🌸
Real talk: this document is not an Internet Standards Track specification. It's published for informational purposes only 📖.
This document is a product of the Internet Engineering Task Force (IETF) 🎀. It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for the full picture 🫶.
Want the latest status, any errata, or a place to send feedback? Head to 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) as they're in effect on the date of publication. Please review these documents carefully, because 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 they're provided without warranty as described in the Simplified BSD License 🍓.
Table of Contents 💖
okay bestie, this is the whole map of the doc, so you can see exactly where every section lives 🗺️ the page numbers are kept as-is, so you can skip around like a pro ✨
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 ..................................................97the whole thing is 97 pages of deterministic networking goodness, and the next parts will walk through it section by section 🌈💅
1. Introduction ✨
okay bestie, let's start with the big picture 🦋 This memo documents use cases for lots of different industries that need deterministic flows over multi-hop paths. Deterministic Networking (DetNet) flows can be set up from either a Layer 2 or a Layer 3 (IP) interface, and they can share an IP network with best-effort traffic. DetNet also gives you highly reliable flows by providing for redundant paths 💖
The DetNet use cases explicitly do not suggest any specific design for DetNet architecture or protocols. Those are topics for other DetNet documents 🙈
Here's the tea 🍵 The DetNet use cases, as originally submitted, were explicitly not considered by the DetNet Working Group (WG) to be concrete requirements. The DetNet WG and Design Team looked at these use cases and figured out which parts could feasibly be implemented within the DetNet charter. As a result, some of the originally submitted use cases (or parts of them) were moved to Appendix A ("Use Cases Explicitly Out of Scope for DetNet") of this document 💅
This document gives context on DetNet design decisions. It also has a long-lived purpose: it helps people who are learning DetNet (or are brand new to it) understand what kinds of applications DetNet can support ✨ It also lets WG contributors who are users make sure their concerns are addressed by the WG. For them, this document (1) covers their contributions and (2) provides a long-term reference for the problems they expect the technology to solve, both in the short-term deliverables and as the technology evolves in the future 🌸
This document has served as a "yardstick" for measuring proposed DetNet designs, 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:
- professional audio and video (Section 2)
- electrical utilities (Section 3)
- building automation systems (BASs) (Section 4)
- wireless for industrial applications (Section 5)
- cellular radio (Section 6)
- industrial machine to machine (M2M) (Section 7)
- mining (Section 8)
- private blockchain (Section 9)
- network slicing (Section 10)
For each use case, the following questions get answered:
- What is the use case?
- How is it addressed today?
- How should it be addressed in the future?
- What should the IETF deliver to enable this use case?
The level of detail in each use case is meant to be enough to express the relevant elements of the use case, and no more than that 🎀
DetNet does not directly address clock distribution or time synchronization. Those are considered part of the overall design and implementation of a time-sensitive network, and they use 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:
- Music and film content creation
- Broadcast
- Cinema
- Live sound
- Public address, media, and emergency systems at large venues (e.g., airports, stadiums, churches, theme parks)
These industries have already moved audio and video signals from analog to digital 🎶 However, the digital interconnect systems are still mostly point to point, with a single signal or a small number of signals per link, connected with purpose-built hardware.
These industries are now moving to packet-based infrastructures to cut costs, 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. Honestly, this is a fundamental limitation of the use cases described here 😭 Deterministic flows can be created within standards-based Layer 2 LANs (e.g., using IEEE 802.1 TSN ("TSN" stands for "Time-Sensitive Networking")). But these flows are not routable via IP, so they aren't 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. Still, solutions with a 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 nothing like common file transfer. Uninterrupted stream playback in the presence of network errors cannot be achieved by retrying the transmission, because by the time the missing or corrupt packet has been identified, it is too late to retry 😱 Buffering can add enough delay to allow time for one or more retries. However, this isn't an effective solution for applications where large delays (latencies) aren't 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 ✨ Using redundant paths can further mitigate transmission errors and 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
In this context, latency is the time between when a signal is initially sent over a stream and when it is received ⏱️ A very common ProAV example 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 going to stay 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 keep 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 take different paths through the network (and thus potentially have different latencies) measures the latency of each path. It then 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 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
Think about the latency (delay) between the moment a person speaks into a microphone and the moment their voice comes out of 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 talk while hearing a delayed echo of your own voice, you know exactly what I mean 😭)
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 those 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 can generate hundreds or thousands of watts of audio power. If used incorrectly, these amplifiers can cause hearing damage to people nearby 😬 Apart from the usual care that system operators take to prevent these 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 need careful configuration to operate, and they often require the system to be over-provisioned 🙄 Also, it is implied that all devices on the network voluntarily play by the rules of that network. To help these industries successfully move to an interoperable, multi-vendor, packet-based infrastructure, we need 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 let IP connect multiple Layer 2 LANs 🧩
As an example, ESPN built a state-of-the-art 194,000 sq. ft., $125-million broadcast studio called "Digital Center 2" (DC2). The DC2 network can handle 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]) 🤯
When designing DC2, they replaced as much point-to-point technology as they could with packet-based technology. They built seven individual studios using Layer 2 LANs (using IEEE 802.1 TSN) that worked perfectly for routing audio within the LANs. However, to interconnect these Layer 2 LAN islands, 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 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, so 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 go down by using off-the-shelf, commodity network hardware 🛒 Economies of scale can also be realized by combining media infrastructure with IT infrastructure 💅 In keeping with these goals, stream-reservation technology should be compatible with existing protocols, and it 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 ✨
okay so 🫶 if stream bandwidth is reserved but nobody's actually using it (or it's only kinda used), that bandwidth must be available to best-effort (i.e., non-time-sensitive) traffic 💅. Picture a single stream that's "nailed up" (reserved) for some media that needs to play at specific times of day, so it always arrives on time 🎀. In between those times, the whole network is free for best-effort stuff like file transfers. Everyone wins!
This also handles a worry that IT network admins have when they're thinking about 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." 😭 Valid concern, but the unused-reservation thing makes it a non-issue, periodt 💜.
2.3.5. Traffic Segregation 🦋
Sink devices can be low-cost gadgets with limited processing power 🧚. To keep their CPUs from getting overwhelmed, it's important to limit how much traffic these devices have to process.
Let's use individual seat speakers in a cinema as an example 🍿. These speakers are typically required to be cost reduced, because a single theater can have hundreds of seats. Discovery protocols alone in a 1,000-seat theater can generate enough broadcast traffic to overwhelm a low-powered CPU 💀. So an installation like this will benefit hugely from some kind 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, though 🙈.
There are a bunch of techniques that can support this feature. Here are some examples (but not all of them) 🌸.
2.3.5.1. Packet-Forwarding Rules, VLANs, and Subnets 💖
Packet-forwarding rules can help keep some extra streaming traffic from reaching potentially low-powered sink devices ✨. However, there may be other types of broadcast traffic that should be eliminated some other way, like with 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 🍓.
Layer 2 bridges forward Media Access Control (MAC) addresses by design, so it's important that a multicast MAC address only be associated with one stream 👑. That way, reservations can't forward packets from one stream down a path with no interested sinks just because some other stream on that same path shares the same multicast MAC address. Main character energy for each stream, no sharing the spotlight 🔥.
Here's the tricky part: each multicast MAC address can represent 32 different IPv4 multicast addresses 😵. So 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. IPv6 could help with this because of its way bigger address range, but since IPv4 installations are still super prevalent, solutions that work for IPv4 would be practical in way more use cases 💅.
2.3.6. Latency Optimization by a Central Controller 🧚♀️
A central network controller might also do optimizations based on the individual path delays 🦋. For example, sinks that are closer to the source can tell the controller that they can accept greater latency, since they'll be buffering packets to match presentation times of sinks that are farther away. The controller might then move a stream reservation from a short path to a longer path so it can free up bandwidth for other critical streams on that short path. Smart, right? 🧠 See slides 3-5 of [SRP_LATENCY].
It gets even better when sinks have different 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 drop in a system with guaranteed reservations and a small bounded latency, since sink devices need less buffering (i.e., memory) 🤑. Say a theme park wants to broadcast a live event across the globe via a Layer 3 protocol 🎢. The size of the buffers needed is set by the worst-case latency and jitter values of the worst-case segment of the end-to-end network path. On today's open Internet, the latency is usually unacceptable for audio and video streaming without many seconds of buffering 😩.
So in situations like this, one gateway device on the local network that receives the feed from the remote site does the expensive buffering needed to mask the latency and jitter issues from long-distance delivery 🫶. Sink devices at the local location don't need any extra buffering, so they don't add any extra costs beyond what they'd need for local content anyway. They're getting packets identical to the ones the source sent and they have no idea there was any latency or jitter drama along the way 🥹✨.
2.4. Pro Audio Requests to the IETF 📣
- Layer 3 routing on top of Audio Video Bridging (AVB) (and/or other high-QoS (Quality of Service) networks) 🌟
- Content delivery with bounded, lowest possible latency 🎯
- IntServ and DiffServ integration with AVB (where practical) 🧩
- Single network for A/V and IT traffic 🎧
- Standards-based, interoperable, multi-vendor solutions 🤝
- IT-department-friendly networks 💼
- Enterprise-wide networks (e.g., the size of San Francisco but not the whole Internet (yet...)) 🌉😏
3. Electrical Utilities ⚡
3.1. Use Case Description 💡
Lots of systems that an electrical utility deploys today rely on high availability and deterministic behavior from the underlying networks 🔌. This section covers use cases for transmission, generation, and distribution, including the key timing and reliability metrics. It also talks about security issues and industry trends that affect how next-generation utility networks get built 🛠️.
3.1.1. Transmission Use Cases 🗼
3.1.1.1. Protection 🛡️
"Protection" means more than just protecting human operators. It's also about protecting the electrical equipment and keeping the grid's stability and frequency steady 🫡. If a fault happens in the transmission or distribution of electricity, it can seriously damage human operators, electrical equipment, and the grid itself, and that can lead to blackouts 😱.
Communication links work together with protection relays to selectively isolate faults on high-voltage lines, transformers, reactors, and other important electrical equipment ⚡💜. The teleprotection system's whole job is to selectively disconnect a faulty part by sending command signals in the shortest possible time. Speed is everything here, bestie 🏃♀️💨.
3.1.1.1.1. Key Criteria 📊
The key criteria for measuring teleprotection performance are command transmission time, dependability, and security 🎀. The International Electrotechnical Commission (IEC) Standard 60834 [IEC-60834] defines these criteria as follows:
- Transmission time (speed): The time between the moment when a state change occurs at the transmitter input and the moment of the corresponding change at the receiver output, including propagation delay. The overall operating time for a teleprotection system is the sum of (1) the time required to initiate the command at the transmitting end, (2) the propagation delay over the network (including equipment), and (3) the time required to make the necessary selections and decisions at the receiving end, including any additional delay due to a noisy environment. ⏱️
- Dependability: The ability to issue and receive valid commands in the presence of interference and/or noise, by minimizing the Probability of Missing Commands (PMC). Dependability targets are typically set for a specific Bit Error Rate (BER) level. 🫶
- Security: The ability to prevent false tripping due to a noisy environment, by minimizing the Probability of Unwanted Commands (PUC). Security targets are also set for a specific BER level. 🔒
Other parts of the teleprotection system that affect its performance include:
- Network bandwidth 📶
- Failure recovery capacity (aka resiliency) 🦾
3.1.1.1.2. Fault Detection and Clearance Timing ⏳
Most power-line equipment can tolerate short circuits or faults for up to about five power cycles before it gets irreversibly damaged or messes with other segments in the network 😬. That works out to a total fault clearance time of 100 ms. As a safety precaution, though, the actual operation time of protection systems is limited to 70-80% of that period. That includes fault recognition time, command transmission time, and line breaker switching time 🧯.
Some system components, like large electromechanical switches, take a really long time to operate and eat up most of the total clearance time. That leaves only a 10 ms window for the telecommunications part of the protection scheme, no matter how far away things are 🥲. Since this is so sensitive, new networks have even stricter requirements. IEC Standard 61850-5:2013 [IEC-61850-5:2013] limits the transfer time for protection messages to 1/4-1/2 cycle or 4-8 ms (for 60 Hz lines) for the most critical messages 🚨✨.
3.1.1.1.3. Symmetric Channel Delay 🔁
Teleprotection channels that are differential must be synchronous. That means any delays on the transmit and receive paths must match each other 🪞. Ideally, teleprotection systems support zero asymmetric delay, but typical legacy relays can tolerate delay discrepancies of up to 750 us 🙃.
Here are some tools that can help lower delay variation below this threshold 🧰:
- For legacy systems using Time-Division Multiplexing (TDM), jitter buffers at the multiplexers on each end of the line can offset delay variation by queuing sent and received packets. The length of the queues has to balance the need to regulate the rate of transmission with the need to limit overall delay, since larger buffers mean more latency 📦.
- For jitter-prone IP networks, traffic management tools can make sure the teleprotection signals get the highest transmission priority to minimize jitter 🏆.
- Standard packet-based synchronization technologies, like the IEEE 1588-2008 Precision Time Protocol (PTP) [IEEE-1588] and synchronous Ethernet (syncE) [syncE], can help keep networks stable by maintaining a highly accurate clock source on the various network devices ⏰💖.
3.1.1.1.4. Teleprotection Network Requirements
Okay so this table is the teleprotection checklist, bestie 💅 Table 1 pulls its main network metrics from IEC Standard 61850-5:2013 [IEC-61850-5:2013], so these numbers come from the power-grid side of things 🔌✨
+---------------------------------+---------------------------------+
| Teleprotection Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 4-10 ms |
| | |
| Asymmetric delay required | Yes |
| | |
| Maximum jitter | Less than 250 us (750 us for |
| | legacy IEDs) |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% to 1% |
+---------------------------------+---------------------------------+Table 1: Teleprotection Network Requirements 🎀
The vibe here is super strict 😭 One-way delay is 4-10 ms, asymmetric delay is required, jitter is less than 250 us (750 us for legacy IEDs), and availability is 99.9999%. Recovery on node failure is less than 50 ms and hitless, precise timing is required, performance management is mandatory, redundancy is yes, and packet loss sits between 0.1% and 1% 🦋
3.1.1.1.5. Inter-trip Protection Scheme
Okay, inter-tripping is when a circuit breaker gets tripped by a signal so that a circuit or piece of apparatus gets fully isolated, and it happens together with other circuit breakers tripping too 🌸⚡
+---------------------------------+---------------------------------+
| Inter-trip Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+Table 2: Inter-trip Protection Network Requirements 💖
Inter-trip is a bit of a chill one 🧚 One-way maximum delay is 5 ms, asymmetric delay is No, jitter is not critical, and bandwidth is 64 kbps. Availability is still 99.9999%, precise timing is still required, recovery is still less than 50 ms and hitless, and packet loss is 0.1% ✨
3.1.1.1.6. Current Differential Protection Scheme
Current differential protection is commonly used for line protection, and it's typically used to protect parallel circuits 🔥 At both ends of the lines, the differential relays measure the current, and both relays trip the circuit breaker if the current going into the line doesn't equal the current going out of the line 😭
This scheme needs some kind of communication between the relays at both ends so they can compare their measured current values 🫶 Line differential schemes assume the telecommunications delay between both relays is very low, often as low as 5 ms. Those systems are often not time-synchronized, so they also assume the delay over symmetric telecommunications paths is constant. That lets them compare current measurements taken at exactly the same time 👑
+---------------------------------+---------------------------------+
| Current Differential Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | Yes |
| | |
| Maximum jitter | Less than 250 us (750 us for |
| | legacy IEDs) |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+Table 3: Current Differential Protection Metrics 🌈
3.1.1.1.7. Distance Protection Scheme
The distance (impedance relay) protection scheme is based on voltage and current measurements 💜 Its network metrics are similar to current differential protection, but not identical 🦋
+---------------------------------+---------------------------------+
| Distance Protection Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+Table 4: Distance Protection Requirements 🎀
3.1.1.1.8. Inter-substation Protection Signaling 🦋
okay so this use case is about two substations talking to each other about protection and tripping, and it's giving high-stakes teamwork 😭 The exchange happens between Intelligent Electronic Devices (IEDs) in each substation, using sampled values and/or GOOSE (Generic Object Oriented Substation Events) messages, and the two IEDs are in master-slave mode 👑
Here's the flow, bestie. The Current Transformer or Voltage Transformer (CT/VT) in one substation sends the sampled analog voltage or current value to the Merging Unit (MU) over hard wire. The MU then sends the time-synchronized sampled values (as specified by IEC 61850-9-2:2011 [IEC-61850-9-2:2011]) to the slave IED. The slave IED forwards that info to the master IED in the other substation. The master IED makes the call (for example, based on sampled value differentials) and sends a trip command to the originating IED. Once the slave IED/relay gets the GOOSE message containing the command to trip the breaker, it opens the breaker 💅 Then it sends a confirmation message back to the master. And honestly, all the data exchanges between IEDs go through sampled values and/or GOOSE messages, so that's the whole vibe 🫶
Now the requirements. Check out the table below, it's literally the numbers that make or break this:
+---------------------------------+---------------------------------+
| Inter-substation Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
+---------------------------------+---------------------------------+
Table 5: Inter-substation Protection RequirementsOkay, so the one-way maximum delay is 5 ms, asymmetric delay is not required, and jitter is not critical. Topology can be point to point or point to multipoint, the bandwidth is 64 kbps, and availability is 99.9999% 🔥 Precise timing is required, recovery on node failure is less than 50 ms and hitless, performance management is mandatory, redundancy is yes, and packet loss is 1% 💀
3.1.1.2. Intra-substation Process Bus Communications 🌈
ngl this one is about what happens inside a single substation. The CT/VT sends the analog voltage or current values to the MU over hard wire. The MU converts those analog values into digital format (typically time-synchronized sampled values as specified by IEC 61850-9-2:2011 [IEC-61850-9-2:2011]) and sends them to the IEDs in the substation. The Global Positioning System (GPS) Master Clock can send 1PPS or IRIG-B format to the MU through a serial port, or use IEEE 1588 protocol via a network.
Quick timing lesson, because it's lowkey iconic 🧚 1PPS (One Pulse Per Second) is an electrical signal with a width of less than 1 second and a sharply rising or abruptly falling edge that repeats accurately once per second. 1PPS signals come out of radio beacons, frequency standards, other precision oscillators, and some GPS receivers. IRIG (Inter-Range Instrumentation Group) time codes are standard formats for transferring timing info, and atomic frequency standards and GPS receivers built for precision timing often have an IRIG output.
Process bus communication using IEC 61850-9-2:2011 [IEC-61850-9-2:2011] simplifies connectivity inside the substation, gets rid of the need for multiple serial connections, and removes the slow serial-bus architectures that are usually used. It also brings increased flexibility and speed through multicast messaging between multiple devices. Main character energy 🎀
Here's the table for this one:
+---------------------------------+---------------------------------+
| Intra-substation Protection | Attribute |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 5 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes or No |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 6: Intra-substation Protection RequirementsCompare that to the inter-substation table and you'll see the differences: redundancy can be Yes or No here, and packet loss is way tighter at 0.1% 🙈
3.1.1.3. Wide-Area Monitoring and Control Systems 💜
okay this is the big-picture one, and it's so important 😭 Applying synchrophasor measurement data from Phasor Measurement Units (PMUs) to wide-area monitoring and control systems promises to unlock important new capabilities for improving system stability. Access to PMU data gives more-timely situational awareness over larger parts of the grid than was ever possible with normal SCADA (Supervisory Control and Data Acquisition) data. Handling the volume and real-time nature of synchrophasor data is a whole challenge for existing application architectures. The Wide-Area Management System (WAMS) lets operators see and understand the condition of the bulk power system in real time, so that protective, preventative, or corrective action can be taken.
Because the sampling rate is super high and the samples need strict time synchronization, the WAMS has stringent telecommunications requirements in an IP network, as captured in Table 7 👑
+---------------------------------+---------------------------------+
| WAMS Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 50 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point, point to |
| | multipoint, multipoint to |
| | multipoint |
| | |
| Bandwidth | 100 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Less than 50 ms - hitless |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
| | |
| Consecutive packet loss | At least one packet per |
| | application cycle must be |
| | received. |
+---------------------------------+---------------------------------+
Table 7: WAMS Special Communication RequirementsThe headline numbers: one-way maximum delay is 50 ms, bandwidth is 100 kbps, and the topology can be point to point, point to multipoint, or multipoint to multipoint 🦋 Consecutive packet loss has a special rule too: at least one packet per application cycle must be received 🫶
3.1.1.4. WAN Engineering Guidelines Requirement Classification ✨
okay so the IEC put out a technical report (TR) with guidelines on how to define and deploy Wide-Area Networks (WANs) that connect electric substations, generation plants, and SCADA operation centers 🔌. IEC TR 61850-90-12:2015 [IEC-61850-90-12:2015] lays out four classes of WAN communication requirements, all summarized in Table 8 💅:
+----------------+-----------+----------+----------+----------------+
| WAN | Class WA | Class WB | Class WC | Class WD |
| Requirement | | | | |
+----------------+-----------+----------+----------+----------------+
| Application | EHV | HV (High | MV | General- |
| field | (Extra- | Voltage) | (Medium | purpose |
| | High | | Voltage) | |
| | Voltage) | | | |
| | | | | |
| Latency | 5 ms | 10 ms | 100 ms | >100 ms |
| | | | | |
| Jitter | 10 us | 100 us | 1 ms | 10 ms |
| | | | | |
| Latency | 100 us | 1 ms | 10 ms | 100 ms |
| asymmetry | | | | |
| | | | | |
| Time accuracy | 1 us | 10 us | 100 us | 10 to 100 ms |
| | | | | |
| BER | 10^-7 to | 10^-5 to | 10^-3 | |
| | 10^-6 | 10^-4 | | |
| | | | | |
| Unavailability | 10^-7 to | 10^-5 to | 10^-3 | |
| | 10^-6 | 10^-4 | | |
| | | | | |
| Recovery delay | Zero | 50 ms | 5 s | 50 s |
| | | | | |
| Cybersecurity | Extremely | High | Medium | Medium |
| | high | | | |
+----------------+-----------+----------+----------+----------------+
Table 8: Communication Requirements (Courtesy of
IEC TR 61850-90-12:2015)3.1.2. Generation Use Case ⚡
bestie, energy generation systems are seriously complicated infrastructures 😭 they have to control both the power being generated AND the infrastructure doing the generating 🔥.
3.1.2.1. Control of the Generated Power 💖
the electrical power generation frequency must be maintained within a very narrow band 🎀. when the frequency drifts outside the acceptable range, that gets detected, and the required signals get sent to the power plants so they can regulate it 🫶.
Automatic Generation Control (AGC) is a system for adjusting the power output of generators at different power plants, in response to changes in the load 🌸.
+---------------------------------+---------------------------------+
| FCAG (Frequency Control | Attribute |
| Automatic Generation) | |
| Requirement | |
+---------------------------------+---------------------------------+
| One-way maximum delay | 500 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | Not critical |
| | |
| Topology | Point to point |
| | |
| Bandwidth | 20 kbps |
| | |
| Availability | 99.999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | N/A |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 1% |
+---------------------------------+---------------------------------+
Table 9: FCAG Communication Requirements3.1.2.2. Control of the Generation Infrastructure 🌬️
the control of the generation infrastructure is a mashup of requirements from industrial automation systems and energy generation systems 🧚. this section focuses on the use case for controlling the generation infrastructure of a wind turbine 🦋.
Figure 1 shows the subsystems that operate a wind turbine 👑:
|
|
| +-----------------+
| | +----+ |
| | |WTRM| WGEN |
WROT x==|===| | |
| | +----+ WCNV|
| |WNAC |
| +---+---WYAW---+--+
| | |
| | | +----+
|WTRF | |WMET|
| | | |
Wind Turbine | +--+-+
Controller | |
WTUR | | |
WREP | | |
WSLG | | |
WALG | WTOW | |
Figure 1: Wind Turbine Control NetworkThe subsystems shown in Figure 1 include the following:
- WROT (rotor control)
- WNAC (nacelle control) (nacelle: housing containing the generator)
- WTRM (transmission control)
- WGEN (generator)
- WYAW (yaw controller) (of the tower head)
- WCNV (in-turbine power converter)
- WTRF (wind turbine transformer information)
- WMET (external meteorological station providing real-time information to the tower's controllers)
- WTUR (wind turbine general information)
- WREP (wind turbine report information)
- WSLG (wind turbine state log information)
- WALG (wind turbine analog log information)
- WTOW (wind turbine tower information)
Traffic characteristics that matter for network planning and dimensioning in a wind turbine scenario are listed below 📊. the values in this section are based mainly on the relevant references [Ahm14] and [Spe09] ✨. each logical node (Figure 1) is a part of the metering network and produces analog measurements and status information that must comply with their respective data-rate constraints 💜.
+-----------+--------+----------+-----------+-----------+-----------+
| Subsystem | Sensor | Analog | Data Rate | Status | Data Rate |
| | Count | Sample | (bytes/s) | Sample | (bytes/s) |
| | | Count | | Count | |
+-----------+--------+----------+-----------+-----------+-----------+
| WROT | 14 | 9 | 642 | 5 | 10 |
| | | | | | |
| WTRM | 18 | 10 | 2828 | 8 | 16 |
| | | | | | |
| WGEN | 14 | 12 | 73764 | 2 | 4 |
| | | | | | |
| WCNV | 14 | 12 | 74060 | 2 | 4 |
| | | | | | |
| WTRF | 12 | 5 | 73740 | 2 | 4 |
| | | | | | |
| WNAC | 12 | 9 | 112 | 3 | 6 |
| | | | | | |
| WYAW | 7 | 8 | 220 | 4 | 8 |
| | | | | | |
| WTOW | 4 | 1 | 8 | 3 | 6 |
| | | | | | |
| WMET | 7 | 7 | 228 | - | - |
+-----------+--------+----------+-----------+-----------+-----------+
Table 10: Wind Turbine Data-Rate ConstraintsQoS constraints for different services are presented in Table 11 🎯. these constraints are defined by IEEE Standard 1646 [IEEE-1646] and IEC Standard 61400 Part 25 [IEC-61400-25] 🌈.
+---------------------+---------+-------------+---------------------+
| Service | Latency | Reliability | Packet Loss Rate |
+---------------------+---------+-------------+---------------------+
| Analog measurement | 16 ms | 99.99% | <10^-6 |
| | | | |
| Status information | 16 ms | 99.99% | <10^-6 |
| | | | |
| Protection traffic | 4 ms | 100.00% | <10^-9 |
| | | | |
| Reporting and | 1 s | 99.99% | <10^-6 |
| logging | | | |
| | | | |
| Video surveillance | 1 s | 99.00% | No specific |
| | | | requirement |
| | | | |
| Internet connection | 60 min | 99.00% | No specific |
| | | | requirement |
| | | | |
| Control traffic | 16 ms | 100.00% | <10^-9 |
| | | | |
| Data polling | 16 ms | 99.99% | <10^-6 |
+---------------------+---------+-------------+---------------------+
Table 11: Wind Turbine Reliability and Latency Constraints3.1.2.2.1. Intra-domain Network Considerations ✨
Okay bestie, a wind turbine is basically a huge pile of subsystems, and a lot of them, sensors and actuators included, need to react right now 🌬️💅. The reliability and latency constraints for each of these subsystems are shown in Table 11. Everything is wired into an intra-domain network that monitors and controls the turbine and hooks it up to the SCADA subsystems 🔌. The parts talk to each other over fiber optics, industrial buses, industrial Ethernet, EtherCAT [EtherCAT], or some mix of those. Industrial signaling and control protocols like Modbus [MODBUS], PROFIBUS [PROFIBUS], PROFINET [PROFINET], and EtherCAT run directly on top of the Layer 2 transport, or get wrapped up inside TCP/IP 🎀.
The data from the sensors and condition-monitoring systems gets multiplexed onto fiber cables and sent down to the base of the tower and off to remote control centers 🧚. The turbine controller keeps watch on the condition of the turbine nonstop and collects statistics on how it's running 👀. It also manages a big crowd of switches, hydraulic pumps, valves, and motors inside the turbine. Such a busy queen 👑.
There's usually a controller at the bottom of the tower and another one in the nacelle 🌸. Those two usually chat over fiber optics instead of copper links, because fiber is the upgrade we deserve ✨. Sometimes there's a third controller in the hub of the rotor, and its whole job is managing the pitch of the blades 🦋. That unit usually talks to the nacelle unit using serial communications.
3.1.2.2.2. Inter-domain Network Considerations ✨
A remote control center that belongs to a grid operator is giving full control-room main character energy 💅. It regulates the power output, enables remote actuation, and keeps an eye on the health of one or more wind parks at the same time 🌈. It reaches the local control center in a wind park over the Internet (Figure 2), and there are firewalls guarding both ends 🧱.
The Autonomous System (AS) path between the local control center and the wind park usually runs through several ISPs at different tiers 🛰️. For example, a remote control center in Denmark can regulate a wind park in Greece over the normal public AS path between the two places. Iconic, honestly 🇩🇰➡️🇬🇷.
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX X XXXXX | |
+---+ XXX | Remote Control |
XXX Internet +----+ Center |
+----+X XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
Figure 2: Wind Turbine Control via InternetThe remote control center is part of the SCADA system 🖥️. It sets the desired power output for the wind park, then reads back the result once the new power output level has been set 📖. Traffic between the remote control center and the wind park usually includes protocols like IEC 60870-5-104 [IEC-60870-5-104], OPC XML-Data Access (XML-DA) [OPCXML], Modbus [MODBUS], and SNMP [RFC3411]. As of this writing, traffic flows between the remote control center and the wind park are best effort 🌤️. QoS requirements aren't strict, so no Service Level Agreements (SLAs) or service-provisioning mechanisms (e.g., VPNs) are used. When something like equipment failure happens, tolerance for alarm delay is on the order of minutes, because redundant systems are already in place 🛟. Chill, it's fine 🫶.
Future use cases will need bounded latency, bounded jitter, and extraordinarily low packet loss for inter-domain traffic flows 😭🔥. The reason is the softwarization and virtualization of core wind-park equipment, like switches, firewalls, and SCADA server components. These changes open the door for service providers to install new services and manage them remotely, which is a whole new era 🚀. For example, to enable failover of a local SCADA server, a SCADA server at another wind-park site (under the administrative control of the same operator) could be used temporarily (Figure 3). In that case, local traffic would be forwarded to the remote SCADA server, and the existing intra-domain QoS and timing parameters would have to be met for inter-domain traffic flows. Big demands, big energy 💜.
+--------------+
| |
| |
| Wind Park #1 +----+
| | | XXXXXX
| | | X XXXXXXXX +----------------+
+--------------+ | XXXX XXXXX | |
+---+ Operator- XXX | Remote Control |
XXX Administered +----+ Center |
+----+X WAN XXX | |
+--------------+ | XXXXXXX XX | |
| | | XX XXXXXXX +----------------+
| | | XXXXX
| Wind Park #2 +----+
| |
| |
+--------------+
Figure 3: Wind Turbine Control via Operator-Administered WAN3.1.3. Distribution Use Case ⚡
3.1.3.1. Fault Location, Isolation, and Service Restoration (FLISR) 🛠️
"Fault Location, Isolation, and Service Restoration (FLISR)" is the ability to automatically locate the fault, isolate the fault, and restore service in the distribution network 🙌. This will likely be the first widespread application of distributed intelligence in the grid, so it's a big deal 🌟.
The static power-switch status (open/closed) in the network decides how power flows to the secondary substations 🔀. Reconfiguring the network after a fault is usually done manually on site, to energize or de-energize alternate paths. Automating the operation of substation switchgear means power flow can be changed automatically under fault conditions. No more waiting around, periodt 💖.
FLISR can be managed centrally from a Distribution Management System (DMS), or it can be run locally through distributed control via intelligent switches and fault sensors 🧠.
+---------------------------------+---------------------------------+
| FLISR Requirement | Attribute |
+---------------------------------+---------------------------------+
| One-way maximum delay | 80 ms |
| | |
| Asymmetric delay required | No |
| | |
| Maximum jitter | 40 ms |
| | |
| Topology | Point to point, point to |
| | multipoint, multipoint to |
| | multipoint |
| | |
| Bandwidth | 64 kbps |
| | |
| Availability | 99.9999% |
| | |
| Precise timing required | Yes |
| | |
| Recovery time on node failure | Depends on customer impact |
| | |
| Performance management | Yes; mandatory |
| | |
| Redundancy | Yes |
| | |
| Packet loss | 0.1% |
+---------------------------------+---------------------------------+
Table 12: FLISR Communication Requirements3.2. Electrical Utilities Today 🔌
Many utilities still rely on complex environments made of multiple application-specific proprietary networks, including TDM networks 🥲. In this kind of environment, OT and IT applications never share the same network, and information stays siloed between operational areas 🧱.
Specific calibration of the full chain is required, and that is costly 💸. This kind of environment keeps utility operations from getting operational efficiency benefits, visibility, and functional integration of operational information across grid applications and data networks. Not it 🙈. In addition, there are many security-related issues, as discussed in the following section 🔐.
3.2.1. Current Security Practices and Their Limitations ✨
okay so grid-monitoring and control devices are already getting targeted by cyber attacks 😭, and the legacy telecom protocols have a bunch of built-in network weak spots 💀. Take DNP3 [IEEE-1815], Modbus, PROFIBUS/PROFINET, and friends. They're all built on the same "request and respond" vibe. A master device, like an HMI (Human-Machine Interface) system, sends commands to subordinate slave devices to either read inputs or write to outputs 🔌. The problem is that a lot of these protocols don't have authentication, encryption, or other basic security stuff. So an attacker can totally use that request-and-respond system like a command-and-control tool 🙈. Here's the list of security concerns that show up in most industrial-control protocols (utility telecom protocols included) 💅:
- Network or transport errors (e.g., malformed packets or excessive latency) can cause protocol failure.
- Protocol commands may be available that are capable of forcing slave devices into inoperable states, including powering devices off, forcing them into a listen-only state, or disabling alarming.
- Protocol commands may be available that are capable of interrupting processes (e.g., restarting communications).
- Protocol commands may be available that are capable of clearing, erasing, or resetting diagnostic information such as counters and diagnostic registers.
- Protocol commands may be available that are capable of requesting sensitive information about the controllers, their configurations, or other need-to-know information.
- Most protocols are application-layer protocols transported over TCP; it is therefore easy to transport commands over non-standard ports or inject commands into authorized traffic flows.
- Protocol commands may be available that are capable of broadcasting messages to many devices at once (i.e., a potential DoS).
- Protocol commands may be available that will query the device network to obtain defined points and their values (i.e., perform a configuration scan).
- Protocol commands may be available that will list all available function codes (i.e., perform a function scan).
These inherent vulnerabilities, plus more and more IT and OT networks getting connected together, make network-based attacks very feasible 😬. An attacker who injects malicious protocol commands could take over the target process 🚨. Messing with legit protocol traffic can also change the info about a process and throw off the real controls on that process. And a man-in-the-middle attack could lead to (1) improper control over a process and (2) misrepresentation of the data that gets sent back to operator consoles. Scary stuff, bestie 🥺.
3.3. Electrical Utilities in the Future 🔮
the business and tech trends sweeping the utility industry are about to totally transform the utility business from how it's been for decades 🌈. At the heart of a lot of these changes is a push to modernize the electrical grid with an integrated telecom infrastructure. But interoperability concerns, legacy networks, disparate tools, and strict security requirements all make the grid's glow-up more complicated 😩. With the range and variety of requirements the next-gen telecom infrastructure has to handle, utilities need a holistic architectural approach that connects the electrical grid with digital telecom across the entire power delivery chain 💖.
The key to modernizing grid telecom is a common, adaptable, multi-service network infrastructure for the whole utility organization ✨. That kind of network is the platform for what utilities can do today, while also making room for the network to grow to support new applications and services 🌸.
To cover this diverse set of requirements now and later, the next-gen utility telecom network will be based on an open-standards-based IP architecture 🦋. An end-to-end IP architecture leans on nearly three decades of IP technology development, which helps with interoperability and device management across different networks and devices. It's already been proven in many mission-critical and highly secure networks, so it's giving reliable 👑.
IPv6 is seen as a future telecom technology for the smart grid 🧚. The IEC and different national committees gave a specific ad hoc group (AHG8) the job of defining the strategy for migrating to IPv6 for all the IEC Technical Committee 57 (TC 57) power automation standards. The AHG8 has finished its work on the migration strategy, and IEC TR 62357-200:2015 [IEC-62357-200:2015] has been issued 📚.
Cloud-based SCADA systems will control and monitor the critical and non-critical subsystems of generation systems, like wind parks 🌬️.
3.3.1. Migration to Packet-Switched Networks 📦
all over the world, utilities are planning for a future full of smart-grid applications that need advanced telecom systems 🌍. A lot of these applications use packet connectivity to send info and control signals across the utility's WAN, which is made possible by technologies like Multiprotocol Label Switching (MPLS) 💫. The data moving across the utility WAN includes:
- Grid monitoring, control, and protection data
- Non-control grid data (e.g., asset data for condition monitoring)
- Data (e.g., voice and video) related to physical safety and security
- Remote worker access to corporate applications (voice, maps, schematics, etc.)
- Field area network Backhaul for smart metering
- Distribution-grid management
- Enterprise traffic (email, collaboration tools, business applications)
WANs carry this wild mix of traffic to and from substations, the transmission and distribution grid, and generation sites; between control centers; and between work locations and data centers 🗺️. To keep up with how fast the app list is growing, lots of utilities are moving from TDM-based and frame relay setups over to packet systems 🚀. Packet-based networks offer more functionality and higher service levels for applications, and they still deliver reliability and deterministic (real-time) traffic support 💜.
3.3.2. Telecommunications Trends 🌷
these general telecom topics are on top of the use cases we've already covered 💅. They include both current and future telecom-related topics that should be factored into the network architecture and design 🎀.
3.3.2.1. General Telecommunications Requirements 📋
- IP connectivity everywhere
- Monitoring services everywhere, and from different remote centers
- Moving services to a virtual data center
- Unified access to applications/information from the corporate network
- Unified services
- Unified communications solutions
- Mix of fiber and microwave technologies - obsolescence of the Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) or TDM
- Standardizing grid telecommunications protocols to open standards, to ensure interoperability
- Reliable telecommunications for transmission and distribution substations
- IEEE 1588 time-synchronization client/server capabilities
- Integration of multicast design
- Mapping of QoS requirements
- Enabling future network expansion
- Substation network resilience
- Fast convergence design
- Scalable headend design
- Defining SLAs and enabling SLA monitoring
- Integration of 3G/4G technologies and future technologies
- Ethernet connectivity for station bus architecture
- Ethernet connectivity for process bus architecture
- Protection, teleprotection, and PMUs on IP
3.3.2.2. Specific Network Topologies of Smart-Grid Applications 🕸️
utilities often run very large private telecom networks that can cover an entire territory or country 🏔️. Until now, the main jobs of these networks have been to (1) support transmission network monitoring, control, and automation, (2) support remote control of generation sites, and (3) provide FCAPS (Fault, Configuration, Accounting, Performance, and Security) services from centralized network operation centers 🖥️.
Going forward, one network will support the operation and maintenance of electrical networks (generation, transmission, and distribution), voice and data services for tens of thousands of employees and for exchanges with neighboring interconnections, and administrative services 🤝. To meet those requirements, a utility may deploy several physical networks that use different technologies across the country, for instance, an optical network and a microwave network 📡. Each protection and automation system between two points has two telecom circuits, one on each network. Path diversity between two substations is key 🔑. No matter what the event is (hurricane, ice storm, etc.), one path needs to stay available so the system can keep running 🌪️.
In the optical network, signals travel over more than tens of thousands of circuits using fiber optic links, microwave links, and telephone cables ⚡. This network is basically the nervous system of the utility's power transmission operations 🧠. The optical network is tens of thousands of kilometers of cable laid along the power lines, with individual runs as long as 280 km 🌟.
3.3.2.3. Precision Time Protocol ✨
okay so some utilities don't use GPS clocks in their generation substations 🛰️ because some generation plants are 30 to 50 meters deep underground, and the GPS signal can be weak and unreliable there 😭 instead they use atomic clocks 🧪 and sync the clocks with each other. rubidium clocks give clock and 1 ms timestamps for IRIG-B 🕰️💖
some companies are planning to switch to PTP [IEEE-1588] 🦋 and send the sync signal over the IP/MPLS network. PTP gives you a way to sync the clocks of participating nodes to a super high degree of accuracy and precision 🎀
PTP runs on these assumptions:
- The network eliminates cyclic forwarding of PTP messages within each communication path (e.g., by using a spanning tree protocol).
- PTP is tolerant of an occasional missed message, duplicated message, or message that arrived out of order. However, PTP assumes that such impairments are relatively rare. 🌸
- As designed, PTP expects a multicast communication model; however, PTP also supports a unicast communication model as long as the behavior of the protocol is preserved. 🧚
- Like all message-based time transfer protocols, PTP time accuracy is degraded by delay asymmetry in the paths taken by event messages. PTP cannot detect asymmetry, but if such delays are known a priori, time values can be adjusted to correct for asymmetry. 💅
the use of PTP for power automation is defined in IEC/IEEE 61850-9-3:2016 [IEC-IEEE-61850-9-3:2016] 📜 it's based on Annex B of IEC 62439-3:2016 [IEC-62439-3:2016], which supports redundant attachment of clocks to Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR) networks. that's giving redundancy realness 🔥
3.3.3. Security Trends in Utility Networks
okay the vibe here is serious but i'm still obsessed 🥹 advanced telecom networks can totally help the energy industry by playing a critical role in keeping reliability, performance, and manageability super high 👑 but they also bring the need for an integrated security infrastructure 🔐 a lot of the tech being deployed for smart-grid projects, like smart meters and sensors, can make the grid more vulnerable to attack 💀 the top security concerns for utilities moving to an intelligent smart-grid telecom platform center on these trends:
- Integration of distributed energy resources
- Proliferation of digital devices to enable management, automation, protection, and control
- Regulatory mandates to comply with standards for critical infrastructure protection
- Migration to new systems for outage management, distribution automation, condition-based maintenance, load forecasting, and smart metering
- Demand for new levels of customer service and energy management
this whole development of diverse networks to support microgrids, open-access energy competition, and network-controlled devices is pushing the need for a converged security infrastructure 🌈 for everyone in the smart grid, including utilities, energy service providers, big commercial and industrial customers, and residential customers. securing the assets of electric power delivery systems (from the control center to the substation, to the feeders and down to customer meters) needs an end-to-end security infrastructure that protects the myriad of telecom assets used to operate, monitor, and control power flow and measurement 🫶
"cybersecurity" refers to all the security issues in automation and telecom that affect any functions related to operating electric power systems. specifically, it involves these concepts:
- Integrity: data cannot be altered undetectably
- Authenticity (data origin authentication): the telecommunications parties involved must be validated as genuine
- Authorization: only requests and commands from authorized users can be accepted by the system
- Confidentiality: data must not be accessible to any unauthenticated users
when designing and deploying new smart-grid devices and telecom systems, it is imperative to understand the various impacts of these new components under a variety of attack situations on the power grid. a cyber attack on the grid telecom network can be catastrophic 😭🚨 which is why smart-grid security isn't just an ad hoc feature or product. it's a complete framework that integrates both physical and cybersecurity requirements and covers the entire smart-grid network, from generation to distribution. security has therefore become one of the main foundations of the utility telecom network architecture, and it must be considered at every layer with a defense-in-depth approach 🛡️✨
migrating to IP-based protocols is key to handling these challenges, for two reasons:
- IP enables a rich set of features and capabilities to enhance the security posture.
- IP is based on open standards; this allows interoperability between different vendors and products, driving down the costs associated with implementing security solutions in OT networks. 🍓
securing OT telecom over packet-switched IP networks follows the same principles that are foundational for securing the IT infrastructure. that means consideration must be given to (1) enforcing electronic access control for both person-to-machine and machine-to-machine communications and (2) providing the appropriate levels of data privacy, device and platform integrity, and threat detection and mitigation 💜
3.4. Electrical Utilities Requests to the IETF
here's what electrical utilities are asking the IETF for 🙏✨
- Mixed Layer 2 and Layer 3 topologies
- Deterministic behavior
- Bounded latency and jitter
- Tight feedback intervals
- High availability, low recovery time
- Redundancy, low packet loss
- Precise timing
- Centralized computing of deterministic paths
- Distributed configuration (may also be useful)
4. Building Automation Systems (BASs) 🏢
4.1. Use Case Description
okay so a BAS manages equipment and sensors in a building to improve residents' comfort, cut energy consumption, and respond to failures and emergencies 🏠💅 for example, the BAS measures a room's temperature with sensors and then controls the HVAC (heating, ventilating, and air conditioning) to keep a set temperature while using as little energy as possible 🌡️
a BAS mainly does these things:
- Periodically measures states of devices -- for example, humidity and illuminance of rooms, open/close state of doors, fan speed.
- Stores the measured data.
- Provides the measured data to BAS operators.
- Generates alarms for abnormal state of devices.
- Controls devices (e.g., turns room lights off at 10:00 PM).
4.2. BASs Today
4.2.1. BAS Architecture
here's what a typical present-day BAS architecture looks like, shown in Figure 4 🎀
+----------------------------+
| |
| BMS HMI |
| | | |
| +----------------------+ |
| | Management Network | |
| +----------------------+ |
| | | |
| LC LC |
| | | |
| +----------------------+ |
| | Field Network | |
| +----------------------+ |
| | | | | |
| Dev Dev Dev Dev |
| |
+----------------------------+
BMS: Building Management Server
HMI: Human-Machine Interface
LC: Local Controller
Figure 4: BAS Architecturethere are typically two layers of network in a BAS. the upper layer is called the management network, and the lower layer is called the field network. management networks use an IP-based communication protocol, while field networks mainly use non-IP-based communication protocols ("field protocols"). field networks have specific timing requirements, whereas management networks can be best effort. 🕰️
an HMI is typically a desktop PC that operators use to monitor and display device states, send device control commands to Local Controllers (LCs), and configure building schedules (for example, "turn off all room lights in the building at 10:00 PM") 💻✨
a building management server (BMS) does the following:
- Collects and stores device states from LCs at regular intervals.
- Sends control values to LCs according to a building schedule.
- Sends an alarm signal to operators if it detects abnormal device states. 🚨
the BMS and HMI talk to LCs via IP-based "management protocols" (see standards [BACnet-IP] and [KNX]) 🫶
an LC is typically a Programmable Logic Controller (PLC) connected to several tens or hundreds of devices using "field protocols". an LC does these kinds of operations:
- Measures device states and provides the information to a BMS or HMI.
- Sends control values to devices, unilaterally or as part of a feedback control loop. 🔁
at the time of this writing, lots of field protocols are in use. some are standards-based, and others are proprietary (see standards [LonTalk], [MODBUS], [PROFIBUS], and [FL-net]) 🌀 the result is that BASs have multiple MAC/PHY modules and interfaces. this makes BASs more expensive and slower to develop, and it can result in "vendor lock-in" with multiple types of management applications 😩💀
4.2.2. BAS Deployment Model ✨
okay so here's an example BAS for medium or large buildings 🏢 (see Figure 5). The layout spans multiple floors and has a monitoring room where the BAS management entities live. Every floor gets one or more LCs, depending on how many devices are plugged into the field network 🔌
+--------------------------------------------------+
| Floor 3 |
| +----LC~~~~+~~~~~+~~~~~+ |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 2 |
| +----LC~~~~+~~~~~+~~~~~+ Field Network |
| | | | | |
| | Dev Dev Dev |
| | |
|--- | ------------------------------------------|
| | Floor 1 |
| +----LC~~~~+~~~~~+~~~~~+ +-----------------|
| | | | | | Monitoring Room |
| | Dev Dev Dev | |
| | | BMS HMI |
| | Management Network | | | |
| +--------------------------------+-----+ |
| | |
+--------------------------------------------------+
Figure 5: BAS Deployment Model for Medium/Large Buildingseach LC connects to the monitoring room through the management network, and the management functions are handled inside the building 🏠. In most cases, Fast Ethernet (e.g., 100BASE-T) is used for the management network 🖥️. Since that network isn't a real-time one, plain Ethernet without QoS is sufficient for today's deployments 💖
Lots of physical interfaces in field networks have specific timing requirements, like RS232C and RS485 👀. So if a field network gets swapped out for an Ethernet or wireless network, those new networks must support time-critical deterministic flows. no shortcuts, bestie 😤
Figure 6 shows another deployment model, where the management system is hosted remotely ☁️. This one is getting super popular for small offices and residential buildings, where a standalone monitoring system just isn't cost effective 🏡
+---------------+
| Remote Center |
| |
| BMS HMI |
+------------------------------------+ | | | |
| Floor 2 | | +---+---+ |
| +----LC~~~~+~~~~~+ Field Network| | | |
| | | | | | Router |
| | Dev Dev | +-------|-------+
| | | |
|--- | ------------------------------| |
| | Floor 1 | |
| +----LC~~~~+~~~~~+ | |
| | | | | |
| | Dev Dev | |
| | | |
| | Management Network | WAN |
| +------------------------Router-------------+
| |
+------------------------------------+
Figure 6: Deployment Model for Small Buildingssome interoperability is possible in today's management networks 🤝, but it isn't possible in today's field networks because of their non-IP-based design 🙃
4.2.3. Use Cases for Field Networks 📊
Here are the use cases for environmental monitoring, fire detection, and feedback control, plus what each one means for field network performance 🧠
4.2.3.1. Environmental Monitoring 🌡️
The BMS polls each LC at a maximum measurement interval of 100 ms (for example, to draw a historical chart of 1-second granularity with a 10x sampling interval), and then performs the operations the operator specified 🎀. Each LC needs to measure each of its several hundred sensors once per measurement interval. Latency isn't critical here, as long as all sensor value measurements finish within the measurement interval 😌. Availability is expected to be 99.999%.
4.2.3.2. Fire Detection 🔥
okay this one is serious 😳. When a fire is detected, the BMS must stop the HVAC, close the fire shutters, turn on the fire sprinklers, send an alarm, etc. There are typically tens of fire sensors per LC that the BMS needs to manage. In this scenario, the measurement interval is 10-50 ms, the communication delay is 10 ms, and the availability must be 99.9999%.
4.2.3.3. Feedback Control 🎛️
BASs use feedback control in lots of ways, and the most time-critical one is controlling DC motors ⚡. Those need a short feedback interval (1-5 ms) with low communication delay (10 ms) and jitter (1 ms). The feedback interval depends on the device's characteristics and on the requirements for the control values. There are typically tens of feedback sensors per LC.
Communication delay is expected to be less than 10 ms and jitter less than 1 ms, while availability must be 99.9999% 💅.
4.2.4. BAS Security Considerations 🔐
okay this part is giving main character drama, so pay attention 😭 When BAS field networks were developed, it was assumed they'd always be physically isolated from external networks, so security wasn't a concern. In today's world, many BASs are managed remotely and are connected to shared IP networks, so security is a definite concern 🚨. Note, however, that security features aren't currently available in the majority of BAS field network deployments 💀.
The management network is IP-based, so it has the protocols available to enable network security. But in practice, many BASs don't implement even those available security features, like device authentication or encryption for data in transit 🙈.
4.3. BASs in the Future 🔮
In the future, lower energy consumption and more fine-grained environmental monitoring will show up 🌱. These will need more sensors and devices, which means larger and more complex building networks 🏗️.
Building networks will be connected to, or converged with, other networks (enterprise networks, home networks, and the Internet) 🌐.
That's why better facilities for network management, control, reliability, and security are critical, so residents and operators get more convenience and comfort 🛋️. For example, being able to monitor and control building devices over the Internet would let someone control room lights or HVAC from a resident's desktop PC or phone app 📱✨.
4.4. BAS Requests to the IETF 🙋♀️
The community would love to see an interoperable protocol specification that can meet the timing, security, availability, and QoS constraints described above 🎯. The goal is that the resulting converged network can replace the disparate field networks. Ideally, this connectivity could extend to the open Internet 🌍.
This would imply an architecture that can guarantee:
- Low communication delays (from <10 ms to 100 ms in a network of several hundred devices)
- Low jitter (<1 ms)
- Tight feedback intervals (1-10 ms)
- High network availability (up to 99.9999%)
- Availability of network data in disaster scenarios
- Authentication between management devices and field devices (both local and remote)
- Integrity and data origin authentication of communication data between management devices and field devices
- Confidentiality of data when communicated to a remote device
5. Wireless for Industrial Applications 💅
5.1. Use Case Description 📡
Wireless networks are useful for industrial applications, for example (1) when portable, fast-moving, or rotating objects are involved, and (2) for the resource-constrained devices found in the Internet of Things (IoT) 🧸.
These network-connected sensors, actuators, control loops, etc. typically need the underlying network to support real-time QoS, plus specific network properties like reliability, redundancy, and security 🔒.
These networks may also contain very large numbers of devices, for example in factories, "big data" acquisition, and the IoT. With that many devices installed and the potential pervasiveness of the IoT, this is a huge and very cost-sensitive market, so small cost reductions can save large amounts of money 💰🤑.
5.1.1. Network Convergence Using 6TiSCH 🦋
Some wireless network technologies support real-time QoS and are useful for these kinds of networks, but others don't 🙅♀️.
This use case focuses on one specific wireless network technology that provides the required deterministic QoS: "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH, where "TSCH" stands for "Time-Slotted Channel Hopping"; see [Arch-for-6TiSCH], [IEEE-802154], and [RFC7554]) 🧚.
There are other deterministic wireless buses and networks available today. However, they're incompatible with each other and with IP traffic (for example, see [ISA100] and [WirelessHART]) 😤.
So the main goal of this use case is to apply 6TiSCH as a converged IP-based and standards-based wireless network for industrial applications. In other words, it replaces multiple proprietary and/or incompatible wireless networking and wireless network management standards 👑✨.
5.1.2. Common Protocol Development for 6TiSCH 🦋
okay so there are a bunch of protocols 6TiSCH needs that are still being cooked 🍳, not finished yet! Another goal of this use case is to show how those "missing" protocols share goals with DetNet 💜. So some of the protocol tech being built for DetNet might also be useful for 6TiSCH ✨. it's giving teamwork.
These protocol goals are listed here, along with how they connect to DetNet. The final protocols probably won't be identical, but they'll share design principles that make it efficient to enable both DetNet and 6TiSCH 💅.
One big commonality: even though they run on different time scales, in both TSN [IEEE-8021TSNTG] and TSCH, a packet hopping from node to node follows a precise schedule 🚆. It's like a train that leaves each station at exact times along its route 🚂. This kind of operation reduces collisions, saves energy, and lets you engineer the network for deterministic properties 🔥.
Another commonality is remote monitoring and scheduling management of a TSCH network by a Path Computation Element (PCE) and Network Management Entity (NME) 🧚. The PCE and NME manage timeslots and device resources in a way that minimizes the interaction with, and the load placed on, resource-constrained devices 🫶. For example, a tiny IoT device may have just enough buffers to store one or a few IPv6 packets 🥺. It has limited bandwidth between peers, so it can only keep a small amount of peer information, and it can't store many packets waiting to be forwarded 💀. So it's advantageous for the IoT device to only carry out the specific behavior assigned to it by the PCE and NME, instead of maintaining its own IP stack (for example) 🌸.
It's possible there will be some peer-to-peer communication too. For example, the PCE may communicate only indirectly with some devices in order to enable hierarchical configuration of the system 👑.
6TiSCH depends on [PCE] and [DetNet-Arch] 💖.
6TiSCH also depends on the fact that DetNet will maintain consistency with [IEEE-8021TSNTG] 🎀.
5.2. Wireless Industrial Today
Today, industrial wireless technology ("wireless industrial") is accomplished using multiple deterministic wireless networks that are incompatible with each other and with IP traffic 😭.
6TiSCH is not yet fully specified, so it cannot be used in today's applications 🙈.
5.3. Wireless Industrial in the Future
5.3.1. Unified Wireless Networks and Management
this is the glow-up 🌈. DetNet and 6TiSCH together can enable converged transport of deterministic and best-effort traffic flows between real-time industrial devices and WANs via IP routing ✨. A high-level view of this type of basic network is shown in Figure 7 🦋.
---+-------- ............ ------------
| External Network |
| +-----+
+-----+ | NME |
| | LLN Border | |
| | Router +-----+
+-----+
o o o
o o o o
o o LLN o o o
o o o o
o
LLN: Low-Power and Lossy Network
Figure 7: Basic 6TiSCH NetworkFigure 8 shows a backbone router federating multiple synchronized 6TiSCH subnets into a single subnet connected to the external network 👑.
---+-------- ............ ------------
| External Network |
| +-----+
| +-----+ | NME |
+-----+ | +-----+ | |
| | Router | | PCE | +-----+
| | +--| |
+-----+ +-----+
| |
| Subnet Backbone |
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
o | | Router | | Router | | Router
+-----+ +-----+ +-----+
o o o o o
o o o o o o o o o o o
o o o LLN o o o o
o o o o o o o o o o o o
Figure 8: Extended 6TiSCH NetworkThe backbone router must ensure end-to-end deterministic behavior between the LLN and the backbone. This should be accomplished in conformance with the work done in [DetNet-Arch] with respect to Layer 3 aspects of deterministic networks that span multiple Layer 2 domains 🧩.
The PCE must compute a deterministic path end to end across the TSCH network and IEEE 802.1 TSN Ethernet backbone, and DetNet protocols are expected to enable end-to-end deterministic forwarding 🛤️✨.
5.3.1.1. PCE and 6TiSCH ARQ Retries
6TiSCH uses the Automatic Repeat reQuest (ARQ) mechanism [IEEE-802154] to provide higher reliability of packet delivery 💪. ARQ is related to Packet Replication and Elimination (PRE) because there are two independent paths for packets to arrive at the destination 👯. If an expected packet does not arrive on one path, then it checks for the packet on the second path 🔍.
Although to date this mechanism is only used by wireless networks, this technique might be appropriate for DetNet, and aspects of the enabling protocol could therefore be co-developed 🤝.
For example, in Figure 9, a track is laid out from a field device in a 6TiSCH network to an IoT gateway that is located on an IEEE 802.1 TSN backbone 🗺️.
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track Branch | |
+-------+ +--------+ Subnet Backbone
| |
+--|--+ +--|--+
| | | Backbone | | | Backbone
o | | | Router | | | Router
+--/--+ +--|--+
o / o o---o----/ o
o o---o--/ o o o o o
o \ / o o LLN o
o v <---- Replication
o
Figure 9: 6TiSCH Network with PREIn ARQ, the replication function in the field device sends a copy of each packet over two different branches, and the PCE schedules each hop of both branches so that the two copies arrive in due time at the gateway 🎯. In the case of a loss on one branch, one hopes that the other copy of the packet will still arrive within the allocated time 🤞. If two copies make it to the IoT gateway, the elimination function in the gateway ignores the extra packet and presents only one copy to upper layers ✂️.
At each 6TiSCH hop along the track, the PCE may schedule more than one timeslot for a packet, so as to support Layer 2 retries (ARQ) ⏰.
At the time of this writing, a deployment's TSCH track does not necessarily support PRE but is systematically multipath. This means that a track is scheduled so as to ensure that each hop has at least two forwarding solutions. The forwarding decision will be to try the preferred solution and use the other solution in the case of Layer 2 transmission failure as detected by ARQ 🛟.
5.3.2. Schedule Management by a PCE
A common feature of 6TiSCH and DetNet is actions taken by a PCE when configuring paths through the network 🧠. Specifically, what is needed is a protocol and data model that the PCE will use to get/set the relevant configuration from/to the devices, as well as perform operations on the devices 📋. Specifically, both DetNet and 6TiSCH need to develop a protocol (and associated data model) that the PCE can use to (1) get/set the relevant configuration from/to the devices and (2) perform operations on the devices 🔁. These could be initially developed by DetNet, with consideration for their reuse by 6TiSCH 💜. The remainder of this section provides a bit more context from the 6TiSCH side 🦋.
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests
Okay so bestie, the 6TiSCH device does NOT get to request bandwidth between itself and another device 🙅♀️. Nope! Instead, an operation control system (you poke it through a human interface 🧑💻) spells out the traffic requirements and the end nodes, in terms of latency and reliability ⏱️. Then the PCE must compute a path between those end nodes 🛤️ and provision the network with per-flow state. That state covers the per-hop operation for a given packet, the matching timeslots, and the flow identification that lets a node recognize that a certain packet belongs to a certain path, plus more ✨.
For a static setup that does its job for a long time, a node is expected to get provisioned in one shot with a full schedule 📅. That's a schedule that defines the node's behavior for all the data flows going through it. 6TiSCH expects the schedule to be programmed over the Constrained Application Protocol (CoAP), as discussed in [CoAP-6TiSCH] 💜.
6TiSCH expects the PCE commands to get mapped back and forth into CoAP by a gateway function at the edge of the 6TiSCH network 🌉. For example, a mapping entity on the backbone could take a non-CoAP protocol like the Path Computation Element Communication Protocol (PCEP) and turn it into the RESTful interfaces that the 6TiSCH devices support. This architecture will be refined to comply with DetNet [DetNet-Arch] once the work gets formalized 🧚. More info about 6TiSCH lives in [Interface-6TiSCH-6top] and [RFC6550] ("RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks") 📚.
Now, a protocol might be used to update the state in the devices during runtime 🔄. Picture this: a path through the network stops performing as expected. But in 6TiSCH, that flow wasn't designed, and no protocol was selected for it 🙈. So DetNet should define the appropriate end-to-end protocols for that case. The vibe here is that these state updates happen once the system is configured and running, so they aren't limited to the initial communication of the system's configuration 🔥.
A "slotFrame" is the base object that a PCE would manipulate to program a schedule into an LLN node [Arch-for-6TiSCH] 🎀.
The PCE should read energy data from devices and compute paths that implement policies on how energy in devices gets consumed 🔋. For instance, it can make sure the spent energy doesn't exceed the available energy over a period of time 💅. Note that this implies an extensible protocol for sending device information to the PCE, and for letting the PCE act on it, will be part of the DetNet architecture ✨. For subnets with specific protocols (like CoAP), a gateway may be required 🌸.
6TiSCH devices can discover their neighbors over the radio using a mechanism like beacons 📡. Even though the neighbor information is available in the 6TiSCH interface data model, 6TiSCH doesn't describe a protocol for proactively pushing that neighbor info to a PCE 🙃. DetNet should define such a protocol. One possible design alternative is that it could operate over CoAP. Another option is that it could be converted to and from CoAP by a gateway 🦋. Such a protocol could carry multiple metrics, like the ones used for RPL operations [RFC6551] 📊.
5.3.2.2. 6TiSCH IP Interface
Protocol translation between the TSCH MAC layer and IP happens via the "6top" sublayer [Sublayer-6TiSCH-6top] 🔁. The 6top data model and management interfaces are further discussed in [Interface-6TiSCH-6top] and [CoAP-6TiSCH] 🫶.
An IP packet that gets sent along a 6TiSCH path uses a differentiated services Per-Hop Behavior Group (PHB) called "deterministic forwarding", as described in [Det-Fwd-PHB] 🚀.
5.3.3. 6TiSCH Security Considerations
Okay, security time, and it's serious 😭. On top of the classical requirements for protecting control signaling, you have to remember that 6TiSCH networks run on limited resources. Those resources can get depleted fast in a DoS attack on the system 💀. For instance, an attacker could place a rogue device in the network, or get management control and set up unexpected extra paths 🚨.
5.4. Wireless Industrial Requests to the IETF
6TiSCH depends on DetNet to define:
- Configuration (state) and operations for deterministic paths 🛤️
- End-to-end protocols for deterministic forwarding (tagging, IP) 🏷️
- A protocol for PRE 🎯
6. Cellular Radio 📶
6.1. Use Case Description
This use case is all about deterministic networking in the context of cellular telecom transport networks 🗼. The important elements here are time synchronization, clock distribution, and ways to establish time-sensitive streams for both Layer 2 and Layer 3 user-plane traffic 🌈.
6.1.1. Network Architecture
Here's the 3GPP-defined cellular network architecture that was typical when this was written 🧁. It has "Fronthaul", "Midhaul", and "Backhaul" network segments. The "Fronthaul" connects base stations (Baseband Units (BBUs)) to the Remote Radio Heads (RRHs), also called "antennas" 📡. The "Midhaul" interconnects base stations (or small-cell sites) 🏘️. The "Backhaul" is the network or links that connect the radio base station sites to the network controller/gateway sites, which is the core of the 3GPP cellular network 🏰.
Y (RRHs (antennas))
\
Y__ \.--. .--. +------+
\_( `. +---+ _( `. | 3GPP |
Y------( Front- )----|eNB|----( Back- )------| core |
( ` .haul ) +---+ ( ` .haul) ) | netw |
/`--(___.-' \ `--(___.-' +------+
Y_/ / \.--. \
Y_/ _(Mid-`. \
( haul ) \
( ` . ) ) \
`--(___.-'\_____+---+ (small-cell sites)
\ |SCe|__Y
+---+ +---+
Y__|eNB|__Y
+---+
Y_/ \_Y ("local" radios)
Figure 10: Generic 3GPP-Based Cellular Network ArchitectureIn Figure 10, "eNB" ("E-UTRAN Node B") is the hardware that connects to the mobile phone network and lets it talk to mobile handsets [TS36300] 📱. ("E-UTRAN" stands for "Evolved Universal Terrestrial Radio Access Network" 🌟.)
6.1.2. Delay Constraints ✨
okay so bestie, this part is all about the clock 🕰️💅 the Fronthaul gets whatever time is left over after the baseband processing has finished with a radio frame, and that leftover is tiny, no cap. 🥺
For example, in Long Term Evolution (LTE) radio, 3 ms is allocated for processing one radio frame, but baseband processing eats most of it, so only a small slice is left for the Fronthaul network 💀 Out of those 3 ms, the most the Fronthaul network gets for one-way delay is 250 us, but the existing specification [NGMN-Fronth] only allows a maximum delay of 100 us 😭 That number is the thing that decides how far the RRHs can sit from the base stations. 100 us is roughly 20 km of optical fiber-based transport, so it's giving distance limits 🦋 How the budget gets split between processing and transport is still a super hot topic in the mobile industry right now 🔥
For packet-based transport, the time allowed between the RRH and the BBU gets eaten up by node processing, buffering, and the delay that comes from distance 🌸 An example of that allocated transport time is 100 us (from the Common Public Radio Interface [CPRI]) 🎀
The baseband processing time and the available "delay budget" for the Fronthaul will probably change in the forthcoming "5G" because of reduced radio round-trip times and other architecture and service requirements [NGMN] 🌈 Things are about to shift, bestie 👑
The transport time budget, as we just saw, limits how far RRHs can be from base stations (aka the link length) 📏 The analysis above assumed the whole transport budget goes to link propagation delay 🙈 But the transport budget actually breaks into three parts: scheduling/queuing delay, transmission delay, and link propagation delay ✨ With today's Fronthaul tech, the queuing, scheduling, and transmission parts might end up being the main players in total transport time, not the propagation delay 💜 This is especially true when the Fronthaul link is pretty short and shared by a bunch of Fronthaul flows, like in indoor and small-cell networks, massive Multiple Input Multiple Output (MIMO) antenna networks, and split Fronthaul architectures 🧚
DetNet technology can level up Fronthaul networks by controlling and cutting down the time spent on queuing, scheduling, and transmission, through properly assigning network resources 💖 That means (1) more of the transport budget is left for link propagation and (2) longer link lengths become possible 🫶 Link length is usually a predetermined parameter though, and not something the network can control, since RRH and BBU sites are usually in predetermined spots 🙃 However, the number of antennas at an RRH site might grow, like by adding more antennas, boosting MIMO capability, or adding support for massive MIMO 📡 That means more Fronthaul flows sharing the same Fronthaul link 😤 DetNet can now control the bandwidth assignment of the Fronthaul link and the scheduling of Fronthaul packets over that link, and it can give each flow adequate buffer provisioning to reduce the packet loss rate 🛡️✨
Another way DetNet helps Fronthaul networks is by providing effective isolation between flows, like between flows coming from different slices within a network-sliced 5G network 🍓 Heads up though, this isolation only applies to DetNet flows that have resources preallocated, so it does NOT cover best-effort flows within a DetNet 🚨 DetNet can also dynamically control the bandwidth assignment, scheduling, and packet-forwarding decisions, plus the buffer provisioning of Fronthaul flows, to guarantee end-to-end delay of Fronthaul packets and minimize packet loss rate 👑💅
[METIS] documents the fundamental challenges and overall technical goals of future 5G mobile and wireless systems, and that's the starting point 🚀 These future systems should support much higher data volumes and rates, and significantly lower end-to-end latency, for 100x more connected devices (at cost and energy-consumption levels similar to today's systems) 🌟 literally a whole vibe shift 😭
For Midhaul connections, delay constraints are driven by inter-site radio functions like Coordinated Multi-Point (CoMP) processing (see [CoMP]) 🫧 CoMP is a framework where multiple geographically distributed antenna nodes cooperate to improve performance for the users served in the common cooperation area 🤝 The design principle of CoMP is to extend single-cell-to-multi-UE (User Equipment) transmission into multi-cell-to-multi-UE transmission, via cooperation among base stations 🦋
CoMP has delay-sensitive performance parameters: "Midhaul latency" and "CSI (Channel State Information) reporting and accuracy" 🎀 The essential feature of CoMP is signaling between eNBs, so Midhaul latency is the dominating limit on CoMP performance 😩 Generally, CoMP can benefit from coordinated scheduling (either distributed or centralized) of different cells if the signaling delay between eNBs is within 1-10 ms ⭐ This delay requirement is both rigid and absolute, because any uncertainty in delay will degrade performance significantly 💀
Inter-site CoMP is one of the key requirements for 5G and is also a goal for 4.5G network architectures 🌈✨
6.1.3. Time-Synchronization Constraints ⏰
Fronthaul time-synchronization requirements come from [TS25104], [TS36104], [TS36211], and [TS36133] 📚 For 3GPP LTE-based networks, they boil down to this 💅
Delay accuracy:
+-8 ns (i.e., +-1/32 Tc, where Tc is the Universal Mobile
Telecommunications System (UMTS) Chip time of 1/3.84 MHz),
resulting in a round-trip accuracy of +-16 ns.The value is this tight so it can meet the 3GPP Timing Alignment Error (TAE) measurement requirements 🎯 Performance guarantees at low-nanosecond values like these are considered to be below the DetNet layer 🙈 It's assumed the underlying implementation (like the hardware) will provide enough support (like buffering) to hit this level of accuracy 🧠 These values stay in the use case just to give a sense of the overall application ✨
TAE: TAE is a real problem for Fronthaul networks and must be minimized 😭 If the transport network can't guarantee TAE levels that are low enough, then extra buffering has to be added at the network edges to buffer out the jitter 🫠 Buffering isn't great though, because it shrinks the total available delay budget 💔
Packet Delay Variation (PDV) requirements can be derived from TAE measurements for packet-based Fronthaul networks 📊
- For MIMO or TX diversity transmissions, at each carrier frequency, TAE measurements shall not exceed 65 ns (i.e., 1/4 Tc) 🌸
- For intra-band contiguous carrier aggregation, with or without MIMO or TX diversity, TAE measurements shall not exceed 130 ns (i.e., 1/2 Tc) 🎀
- For intra-band non-contiguous carrier aggregation, with or without MIMO or TX diversity, TAE measurements shall not exceed 260 ns (i.e., 1 Tc) 🦋
- For inter-band carrier aggregation, with or without MIMO or TX diversity, TAE measurements shall not exceed 260 ns 🧚
Transport link contribution to radio frequency errors: +-2 PPB. This value is considered "available" for the Fronthaul link out of the total 50 PPB budget reserved for the radio interface 💖 The transport link contributes to radio frequency errors for this reason: at the time of writing, Fronthaul communication is direct communication from the radio unit to the RRH 📡 The RRH is basically a passive device (like, no buffering) 🫥 The transport drives the antenna directly by feeding it samples, so everything the transport adds gets introduced to the radio "as is" 😱 If the transport causes any extra frequency errors, they'll show up on the radio immediately too 💀 Performance guarantees at low-nanosecond values like these are considered to be below the DetNet layer, and it's assumed the underlying implementation (like the hardware) will provide enough support to enable this level of performance 🤞 These values stay in the use case to give an indication of the overall application 🫶
The time-synchronization requirements above are hard to meet with point-to-point connected networks, and even harder when the network includes multiple hops 😩 It's expected that networks must include buffering at the ends of connections, as imposed by the jitter requirements, since trying to meet jitter requirements in every intermediate node would probably be too costly 💸 Still, every measure that reduces jitter and delay on the path makes the end-to-end requirements easier to meet 🌈
To meet the timing requirements, both senders and receivers must stay time synchronized, which demands very accurate clock distribution 🕰️ For example, that means 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] 🌸 Time constraints also matter because of their impact on packet loss ⏳ If a packet is delivered too late, the host may drop it 😭
6.1.4. Transport-Loss Constraints 📉
Fronthaul and Midhaul networks assume transport is almost error free 🥹 Errors can cause a reset of the radio interfaces, which can lead to reduced throughput or broken radio connectivity for mobile customers 💔
For packetized Fronthaul and Midhaul connections, packet loss may be caused by BER, congestion, or network failure scenarios 🫠 Different Fronthaul "functional splits" are being considered by 3GPP, and they require strict Frame Loss Ratio (FLR) guarantees 🎯 As one example (referring to the legacy CPRI split, which is option 8 in 3GPP), lower-layer splits may imply an FLR of less than 10^-7 for data traffic and less than 10^-6 for control and management traffic 📊
Many of the tools for eliminating packet loss in Fronthaul and Midhaul networks have serious challenges 😩 For example, retransmitting lost packets or using FEC to circumvent bit errors (or both) is practically impossible, due to the additional delay incurred 🙅 Using redundant streams for better delivery guarantees is also practically impossible in many cases, due to the high bandwidth requirements of Fronthaul and Midhaul networks 💀 Protection switching is also a candidate, but at the time of writing, available technologies for the path switch are too slow to avoid a reset of mobile interfaces 🫤
It's assumed that Fronthaul links are symmetric 🪞 All Fronthaul streams (i.e., those carrying radio data) have equal priority and cannot delay or preempt each other 🤝
All of this means it's up to the network to guarantee that each time-sensitive flow meets its schedule ⏰👑 bestie, that's the whole vibe 💖
6.1.5. Cellular Radio Network Security Considerations
okay bestie, security time 🔐 Reserving networking resources for time-sensitive streams means holding onto them for long periods, so those reservation requests need to be authenticated. Otherwise a hostile node could make malicious reservations, or someone could cause trouble just by misconfiguring things 🙈 This gets even more important when the reservation requests span administrative domains. The reservation info itself should also be digitally signed, so a legit node can't accidentally push a stale or hostile config into another networking node 💀
Note: This is considered important for the security policy of the network but does not affect the core DetNet architecture and design.
6.2. Cellular Radio Networks Today
6.2.1. Fronthaul
okay so today's Fronthaul networks typically look like this 🧚
- Dedicated point-to-point fiber connection (common)
- Proprietary protocols and framings
- Custom equipment and no real networking
At the time of this writing, solutions for Fronthaul are direct optical cables or Wavelength-Division Multiplexing (WDM) connections ✨
6.2.2. Midhaul and Backhaul
Today's Midhaul and Backhaul networks typically look like this 🌸
- Mostly normal IP networks, MPLS-TP, etc.
- Clock distribution and synchronization using IEEE 1588 and syncE
Telecom networks in the Midhaul and Backhaul are already heading toward transport networks where precise time-synchronization support is one of the basic building blocks 👑 To meet bandwidth and cost requirements, most transport networks have already moved to all-IP packet-based networks. The catch is that highly accurate clock distribution has become a real challenge 😭
In the past, Midhaul and Backhaul connections were typically based on TDM and provided frequency-synchronization capabilities as part of the transport media. More recently, other technologies such as GPS or syncE [syncE] have been used 🦋
Ethernet, IP/MPLS [RFC3031], and pseudowires (as described in [RFC3985] ("Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture") for legacy transport support)) have become popular tools for building and managing new all-IP Radio Access Networks (RANs) [SR-IP-RAN-Use-Case]. Various timing and synchronization optimizations have already been proposed and implemented, including PTP enhancements [IEEE-1588] (see also [Timing-over-MPLS] and [RFC8169]). Still, these solutions are not necessarily sufficient for the forthcoming RAN architectures, nor do they guarantee the more stringent time-synchronization requirements such as [CPRI] 🥺
Existing solutions for TDM over IP include those discussed in [RFC4553], [RFC5086], and [RFC5087]. [MEF8] addresses TDM over Ethernet transports 💜
6.3. Cellular Radio Networks in the Future
Future cellular radio networks will be based on a mix of different xHaul networks (xHaul = Fronthaul, Midhaul, and Backhaul), and future transport networks should be able to support all of them simultaneously. It is already envisioned today that:
- Not all "cellular radio network" traffic will be IP; for example, some will remain at Layer 2 (e.g., Ethernet based). DetNet solutions must address all traffic types (Layer 2 and Layer 3) with the same tools and allow their transport simultaneously.
- All types of xHaul networks will need some types of DetNet solutions. For example, with the advent of 5G, some Backhaul traffic will also have DetNet requirements (for example, traffic belonging to time-critical 5G applications).
- Different functional splits between the base stations and the on-site units could coexist on the same Fronthaul and Backhaul network.
Future cellular radio networks should contain the following 🌈
- Unified standards-based transport protocols and standard networking equipment that can make use of underlying deterministic link-layer services
- Unified and standards-based network management systems and protocols in all parts of the network (including Fronthaul)
New RAN deployment models and architectures may require TSN services with strict requirements on other parts of the network that previously were not considered to be packetized at all 🤯 Time and synchronization support are already topical for Backhaul and Midhaul packet networks [MEF22.1.1], and they are also becoming a real issue for Fronthaul networks. In Fronthaul networks specifically, the timing and synchronization requirements can be extreme for packet-based technologies. For example, we're talking on the order of a PDV of +-20 ns or less and frequency accuracy of +-0.002 PPM [Fronthaul] 😳
The actual transport protocols and/or solutions for establishing required transport "circuits" (pinned-down paths) for Fronthaul traffic are still undefined. Those protocols are likely to include (but are not limited to) solutions directly over Ethernet, over IP, and using MPLS/pseudowire transport 🎀
Interesting and important work for TSN has been done for Ethernet [IEEE-8021TSNTG]. This work specifies the use of PTP [IEEE-1588] in the context of IEEE 802.1D and IEEE 802.1Q. [IEEE-8021AS] specifies a Layer 2 time-synchronizing service, and other specifications such as IEEE 1722 [IEEE-1722] specify Ethernet-based Layer 2 transport for time-sensitive streams ⭐
However, even these Ethernet TSN features may not be sufficient for Fronthaul traffic. Therefore, having specific profiles that take Fronthaul requirements into account is desirable [IEEE-8021CM] 🙃
New promising work seeks to enable the transport of time-sensitive Fronthaul streams in Ethernet bridged networks [IEEE-8021CM]. Analogous to IEEE 1722, standardization efforts in the IEEE 1914.3 Task Force [IEEE-19143] to define the Layer 2 transport encapsulation format for transporting Radio over Ethernet (RoE) are ongoing 🍓
As mentioned in Section 6.1.2, 5G communications will provide one of the most challenging cases for delay-sensitive networking. To meet the challenges of ultra-low latency and ultra-high throughput, 3GPP has studied various functional splits for 5G, i.e., physical decomposition of the 5G "gNodeB" base station and deployment of its functional blocks in different locations [TR38801] 🚀
These splits are numbered from split option 1 (dual connectivity, a split in which the radio resource control is centralized and other radio stack layers are in distributed units) to split option 8 (a PHY-RF split in which RF functionality is in a distributed unit and the rest of the radio stack is in the centralized unit). Each intermediate split has its own data-rate and delay requirements. Packetized versions of different splits have been proposed, including enhanced CPRI (eCPRI) [eCPRI] and RoE (as previously noted). Both provide Ethernet encapsulations, and eCPRI is also capable of IP encapsulation 💅
All-IP RANs and xHaul networks would benefit from time synchronization and time-sensitive transport services. Ethernet appears to be the unifying technology for the transport, but there is still a disconnect when it comes to providing Layer 3 services 🫠 The protocol stack typically has a number of layers below Ethernet Layer 2 that might be "visible" to Layer 3. In a fairly common scenario, on top of the lowest-layer (optical) transport sits the first (lowest) Ethernet layer, then one or more layers of MPLS, pseudowires, and/or other tunneling protocols, and finally one or more Ethernet layers that are visible to Layer 3.
Although there exist technologies for establishing circuits through the routed and switched networks (especially in the MPLS/PWE space), there is still no way to signal the time-synchronization and time-sensitive stream requirements/reservations for Layer 3 flows in a way that addresses the entire transport stack, including the Ethernet layers that need to be configured 😤
Furthermore, not all "user-plane" traffic will be IP. Therefore, the solution in question also must address the use cases where the user-plane traffic is on a different layer (for example, Ethernet frames) 🦋
6.4. Cellular Radio Networks Requests to the IETF
Here's what we want from a standard for data-plane transport specifications 👑
- Unified among all xHauls (meaning that different flows with diverse DetNet requirements can coexist in the same network and traverse the same nodes without interfering with each other)
- Deployed in a highly deterministic network environment
- Capable of supporting multiple functional splits simultaneously, including existing Backhaul and CPRI Fronthaul, and (potentially) new modes as defined, for example, in 3GPP. These goals can be supported by the existing DetNet use case "common themes" (Section 11). Of special note are Sections 11.1.8 ("Mix of Deterministic and Best-Effort Traffic"), 11.3.1 ("Bounded Latency"), 11.3.2 ("Low Latency"), 11.3.4 ("Symmetrical Path Delays"), and 11.6 ("Deterministic Flows") 💖
- Capable of supporting network slicing and multi-tenancy. These goals can be supported by the same DetNet themes noted above 🍰
- Capable of transporting both in-band and out-of-band control traffic (e.g., Operations, Administration, and Maintenance (OAM) information)
- Deployable over multiple data-link technologies (e.g., IEEE 802.3, mmWave)
And here's what we want from a standard for data-flow information models 🧠
- Aware of the time sensitivity and constraints of the target networking environment
- Aware of underlying deterministic networking services (e.g., on the Ethernet layer)
7. Industrial Machine to Machine (M2M) 🏭
7.1. Use Case Description ✨
okay so bestie, "industrial automation" is basically the umbrella term for automating manufacturing, quality control, and material processing 🏭💖 this M2M use case is all about machine units on a plant floor that periodically swap data with upstream or downstream machine modules and/or a supervisory controller inside a LAN 🎀
PLCs are the "actors" in M2M communications 💅 PLC-to-PLC chats, and PLC-to-supervisory-PLC (S-PLC) chats, happen over critical control/data streams (see Figure 11 🦋)
S (Sensor)
\ +-----+
PLC__ \.--. .--. ---| MES |
\_( `. _( `./ +-----+
A------( Local )-------------( L2 )
( Net ) ( Net ) +-------+
/`--(___.-' `--(___.-' ----| S-PLC |
S_/ / PLC .--. / +-------+
A_/ \_( `.
(Actuator) ( Local )
( Net )
/`--(___.-'\
/ \ A
S A
Figure 11: Current Generic Industrial M2M Network Architecturethis use case is only about the PLC stuff 🤖 Manufacturing Execution Systems (MESs) are NOT addressed here, so don't come for them, sis 🙅♀️
this use case covers ONLY the critical control/data streams 🔥 the non-critical traffic (state, configuration, setup, database stuff between industrial automation apps) is already handled fine by prioritization techniques that existed when this was written 🌸 that traffic can eat up to 80% of the total bandwidth required 💀 there's also a subset of non-time-critical traffic that still has to be reliable even though it isn't time sensitive 🫶
so, highkey, the main thing deterministic networking is needed for is end-to-end delivery of M2M messages within specific timing constraints, like in closed-loop automation control 🌈 right now that level of determinism comes from proprietary networking tech 😤 plus, standard networking tech connects the local network to remote industrial automation sites over an enterprise or metro network that also carries other traffic types 🚀 which means flows that should get deterministic guarantees have to stay sustained no matter how many other flows are on those networks 👑
7.2. Industrial M2M Communications Today 🌸
right now, proprietary networks are the ones meeting the needed timing and availability for M2M networks 💖
the network topologies industrial automation uses today look a lot like telecom networks: daisy chain, ring, hub-and-spoke, and "comb" (which is a subset of daisy chain) 🧚
PLC-related control/data streams get transmitted periodically, and they carry either a preconfigured payload or a payload configured during runtime 🍓
some industrial apps need time synchronization at the end nodes ⏰ for these time-coordinated PLCs, accuracy of 1 us is REQUIRED ✨ and even "non-time-coordinated" PLCs might need time sync, e.g., for timestamping sensor data 🦋
industrial-network scenarios need advanced security solutions 🔐 at the time of writing, lots of industrial production networks are physically separated, and filtering policies that are usually enforced in firewalls are used to stop critical flows from leaking outside a domain 🛡️
7.2.1. Transport Parameters 📊
the cycle time defines how often messages happen between industrial actors ⏱️ it's application dependent and sits in the range of 1-100 ms for critical control/data streams 💜
because industrial apps assume deterministic transport will be used for critical control-data-stream parameters (instead of having to define latency and delay-variation parameters), it is sufficient to fulfill requirements about the upper bound of latency (maximum latency) 🎯 the underlying networking infrastructure MUST ensure a maximum end-to-end message delivery time in the range of 100 us to 50 ms, depending on the control-loop application 🔥
the bandwidth requirements of control/data streams are usually calculated straight from the bytes-per-cycle parameter of the control loop 🧮 for PLC-to-PLC communication, you can expect 2-32 streams with packet sizes in the range of 100-700 bytes 📦 for S-PLC-to-PLC communication the number of streams is higher, up to 256 streams 😳 usually no more than 20% of available bandwidth is used for critical control/data streams 🙌 and in today's networks, 1 Gbps links are commonly used 💨
most PLC control loops are pretty tolerant of packet loss 🥰 BUT critical control/data streams accept a loss of no more than one packet per consecutive communication cycle (so if a packet gets lost in cycle "n", then the next cycle "n+1" MUST be lossless) 😭 after the loss of two or more consecutive packets, the application may consider the network to be "down" 🚨
as network downtime can impact the whole production system, the required network availability is rather high (99.999%) 👑
based on the above parameters, some form of redundancy will be REQUIRED for M2M communications 🫶 however, any individual solution depends on several parameters, including cycle time and delivery time 🧩
7.2.2. Stream Creation and Destruction 🎀
in an industrial environment, critical control/data streams get created pretty rarely, on the order of ~10 times per day/week/month 📅 most of them get created at machine startup, but flexibility is also needed during runtime, like when adding or removing a machine 🔧 as production systems get more flexible going forward, the rate at which streams are created, changed, and destroyed is going to increase a lot 📈
7.3. Industrial M2M in the Future 🔮
we foresee a converged IP-standards-based network with deterministic properties that can satisfy the timing, security, and reliability constraints described above ✨ today's proprietary networks could then be interfaced to such a network via gateways 🌉 or, for new installations, devices could connect directly to the converged network 💻
for this use case, time-synchronization accuracy on the order of 1 us is expected ⏰
7.4. Industrial M2M Requests to the IETF 💌
- Converged IP-based network 🌐
- Deterministic behavior (bounded latency and jitter) 💫
- High availability (presumably through redundancy) (99.999%) 👑
- Low message delivery time (100 us to 50 ms) ⚡
- Low packet loss (with a bounded number of consecutive lost packets) 🍭
- Security (e.g., preventing critical flows from being leaked between physically separated networks) 🔒
8. Mining Industry ⛏️💎
8.1. Use Case Description 🌈
the mining industry leans HEAVILY on networks to monitor and control their systems 🖥️ this covers open-pit and underground extraction, plus transport and refining processes 🚚 to cut risks and boost operational efficiency, mining operators have been moved (as much as possible) away from the extraction site and into remote control and monitoring sites 🏠✨
in open-pit mining, autonomous trucks haul raw materials from the open pit to the refining factory, where the final product (e.g., copper) is obtained 🥇 even though the operation is autonomous, the tracks are remotely monitored from a central facility 👀
in pit mines, monitoring the tailings or mine dumps is critical to minimize environmental pollution 🌍 in the past this was done by manual inspection of preinstalled dataloggers 🚶♀️ cabling usually isn't used in these scenarios because it's expensive and complicated to deploy 💸 at the time of writing, wireless technologies are being used to monitor these cases permanently 📡 slopes get monitored too, so possible mine collapses can be anticipated 🏔️ because the terrain is unstable, cable maintenance is costly and complex, so wireless tech is used instead 🙃
in underground monitoring, autonomous vehicles with extraction tools travel independently through the tunnels, but their operational tasks (like excavation, stone-breaking, and transport) are controlled remotely from a central facility 🚜 this generates upstream video and feedback traffic plus downstream actuator-control traffic 📹🎮
8.2. Mining Industry Today ⚒️
at the time of writing, the mining industry uses a packet-switched architecture supported by high-speed Ethernet 🌟 BUT to comply with requirements about delay and packet loss, the network bandwidth is overestimated 🫠 which results in very low efficiency in terms of resource usage 📉
QoS is implemented at the routers to separate video, management, monitoring, and process-control traffic for each stream 🚦
since mobility is involved, the connections between the backbone and the mobile devices (e.g., trucks, trains, and excavators) are implemented with a wireless link 📶 these links are based on IEEE 802.11 [IEEE-80211] for open-pit mining and "leaky feeder" communications for underground mining 🐍 (a "leaky feeder" system is a coaxial cable run along tunnels that emits and receives radio waves, acting like an extended antenna 📡 it's "leaky" because it has gaps or slots in its outer conductor so the radio signal can leak into or out of the cable along its entire length 💫)
lately, in pit mines, LPWAN (Low-Power WAN) technologies have been extended 🔋 tailings, slopes, and mine dumps are monitored by battery-powered dataloggers that use robust long-range radio technologies 🛰️ reliability is usually ensured through retransmissions at Layer 2 🔁 gateways or concentrators act as bridges, forwarding the data to the backbone Ethernet network 🌉 deterministic requirements are biased towards reliability rather than latency, since events are triggered slowly or can be anticipated in advance 🐢
at the mineral-processing stage, conveyor belts and refining processes are controlled by a SCADA system that provides an in-factory delay-constrained networking environment 🏭⏱️
at the time of writing, voice communications are served by a redundant trunking infrastructure that's independent from data networks 📞💕
8.3. Mining Industry in the Future
okay so mining is getting a whole glow-up 🚜✨ operations are converging on a mix of autonomous operation and teleoperation for transport and extraction machines. that means video, audio, monitoring, and process-control traffic are about to go up dramatically 📈 ideally, every activity at the mine relies on network infrastructure 🫶
wireless for open-pit mining is already a reality with LPWAN technologies 🌄 and it's expected to level up to more advanced LPWAN tech, like ones based on LTE, to boost last-hop reliability, or novel LPWAN flavors with deterministic access 🔥
where DetNet can really help here is the wired networks that make up the "backbone network" of the system 🦴 these networks connect a bunch of wireless Access Points (APs) together. the mobile machines (connected to the network via wireless) switch from one AP to the next as they move around 🚛 a deterministic, reliable, low-latency backbone can make those transitions more reliable 💅
connections that stretch all the way from the base stations to the machinery through a mix of wired and wireless hops would also be super beneficial, like for making digging machines more responsive to remote control 🏗️ but here's the important part, bestie: to guarantee deterministic performance of a DetNet, the end-to-end underlying network must be deterministic 🚨 so for this use case, if a deterministic wireless transport gets integrated with a wire-based DetNet network, it could create the desired wired plus wireless end-to-end deterministic network ✨
8.4. Mining Industry Requests to the IETF
- Improved bandwidth efficiency 📶
- Very low delay, to enable machine teleoperation 🕹️
- Dedicated bandwidth usage for high-resolution video streams 🎥
- Predictable delay, to enable real-time monitoring 👀
- Potential for constructing a unified DetNet network over a combination of wired and deterministic wireless links 🌈
9. Private Blockchain ⛓️
9.1. Use Case Description
okay blockchain started out with Bitcoin as a "public" blockchain on the open Internet 🌐 but it has since spread way beyond that into all kinds of industries, like smart manufacturing, logistics, security, legal rights, and more 💼 in these industries, blockchain runs in designated and carefully managed networks where deterministic networking requirements could be addressed by DetNet 🔐 these setups are called "private" blockchain.
the only real difference between public and private blockchain is who gets to participate in the network, run the consensus protocol, and maintain the shared ledger 🧾
today's networks handle blockchain traffic on a best-effort basis 🤷♀️ but blockchain operation could get a lot more efficient if deterministic networking services were available to minimize latency and packet loss in the network ✨
9.1.1. Blockchain Operation
a "block" is basically a container holding a batch of primary items (like transactions or property records) 📦 the blocks get chained together in a way where the hash of the previous block works as the pointer to the header of the new block 🔗 every block needs a consensus mechanism to get confirmed ✅ when an item shows up at a blockchain node, that node broadcasts it to the rest of the nodes, and they receive it, verify it, and put it in the ongoing block 📡 block confirmation kicks off once the number of items hits the predefined block capacity. at that point, the node broadcasts its proved block to the other nodes, so they can verify it and chain it too 🙌 the result is that block N+1 of each chain transitively vouches for block N and everything before it in that chain 💜
9.1.2. Blockchain Network Architecture
blockchain node communication and coordination happen mainly through frequent point-to-multipoint communication 📢 but persistent point-to-point connections are used to carry both the items and the blocks to the other nodes 🤝 here's an example implementation, so you can picture it 👇
when a node starts up, it first asks a specific entity, such as DNS, for the other nodes' addresses 🔍 then the node creates persistent connections with each of the other nodes 🧵 if a node confirms an item, it sends that item to the other nodes over these persistent connections 💌
as a new block gets completed at a node and is proven by the surrounding nodes, it propagates toward its neighbor nodes 🌊 when node A receives a block, it verifies it and then sends an invite message to its neighbor B 💬 neighbor B checks whether the designated block is available, and responds to A if it isn't 🙅♀️ then A sends the complete block to B 📦 B repeats the same process A used to kick off the next round of block propagation 🔁
the challenge with blockchain network operation isn't overall data rates 📉 the volume from both the block and the item stays between hundreds of bytes and a couple of megabytes per second 🧮 the real challenge is transporting the blocks with minimum latency to maximize the efficiency of the blockchain consensus process ⏱️ different implementations of the consensus process may be affected to different degrees by the latency (and the variation of latency) of the network 📊
9.1.3. Blockchain Security Considerations
okay, bestie, this section is serious 🚨🔐 security is crucial for blockchain applications. at the time of writing, blockchain systems address security issues mainly at the application level, where cryptography and hash-based consensus play a leading role in preventing both double-spending and malicious service attacks 🛡️ however, there is concern that in the proposed use case for a private blockchain network that depends on deterministic properties, the network could be vulnerable to delays and other specific attacks against determinism 😱 these delays and attacks could interrupt service, and that's the part that keeps network people up at night 💀
9.2. Private Blockchain Today
today, private blockchain runs in Layer 2 or Layer 3 VPNs, generally without guaranteed determinism 😬 the industry players are starting to realize that improving determinism in their blockchain networks could improve the performance of their service 📈 but at present, these goals are not being met 🥲
9.3. Private Blockchain in the Future
blockchain system performance can be greatly improved through deterministic networking services 🚀 mainly because low latency would speed up the consensus process ⚡ it would be valuable to be able to design a private blockchain network with the following properties:
- Transport of point-to-multipoint traffic in a coordinated network architecture rather than at the application layer (which typically uses point-to-point connections) 🧩
- Guaranteed transport latency ⏰
- Reduced packet loss (to the point where delay incurred by packet retransmissions would be negligible) 🌸
9.4. Private Blockchain Requests to the IETF
- Layer 2 and Layer 3 multicast of blockchain traffic 📣
- Item and block delivery with bounded, low latency and negligible packet loss 🎯
- Coexistence of blockchain and IT traffic in a single network 🤝
- Ability to scale the network by distributing the centralized control of the network across multiple control entities 🧠
10. Network Slicing 🍰
10.1. Use Case Description
network slicing divides one physical network infrastructure into multiple logical networks 🥞 each slice, which corresponds to a logical network, uses resources and network functions independently from each other 🧁 network slicing gives you flexibility in resource allocation and lets you customize service quality 💅
future services will demand network performance with a wide variety of characteristics, like high data rate, low latency, low loss rate, security, and many other parameters 🌈 ideally, every service would have its own physical network that satisfies its particular performance requirements, but honestly that would be prohibitively expensive 💸 network slicing can provide a customized slice for a single service, and multiple slices can share the same physical network 🙌 this can optimize performance for the service at a lower cost, and the flexibility of setting up and releasing slices also lets users allocate network resources dynamically ⚡
unlike the other use cases presented here, network slicing is not a specific application that depends on specific deterministic properties 🙃 instead, it's introduced as an area of networking where DetNet might be applicable 🦋
10.2. DetNet Applied to Network Slicing
10.2.1. Resource Isolation across Slices
one of the requirements discussed for network slicing is the "hard" separation of various users' deterministic performance 🧱 that means it should be impossible for activity, lack of activity, or changes in activity of one or more users to have any appreciable effect on the deterministic performance parameters of any other slices 🙅♀️ typical techniques used today, which share a physical network among users, don't offer this level of isolation 😤 DetNet can supply point-to-point or point-to-multipoint paths that give a user bandwidth and latency guarantees that can't be affected by other users' data traffic 🛤️ so DetNet is a powerful tool when reliability and low latency are required in network slicing 👑
10.2.2. Deterministic Services within Slices
slices may need to provide services with DetNet-type performance guarantees 🎀 just note, though, that a system can be implemented to provide such services in more than one way 🧩 for example, the slice itself might be implemented using DetNet, so the slice can provide service guarantees and isolation to its users without any particular DetNet awareness on the part of the users' applications 🫧 alternatively, a "non-DetNet-aware" slice may host an application that itself implements DetNet services, and so it can enjoy similar service guarantees 🌟
10.3. A Network Slicing Use Case Example - 5G Bearer Network
Okay so network slicing is a core feature of 5G, as defined in 3GPP 🦋✨ The 5G system architecture is still being worked on at the time of this writing [TS23501], so keep an eye out for updates bestie. A network slice in a mobile network is basically a complete logical network, with RANs and Core Networks (CNs) both included 🌸 It provides telecom services and network capabilities, and those can vary from slice to slice. A 5G bearer network is a super typical use case for slicing. For example, let's look at three 5G service scenarios: eMBB, URLLC, and mMTC 💅
- eMBB (Enhanced Mobile Broadband) is all about services with high data rates, like high-definition video, Virtual Reality (VR), augmented reality, and fixed mobile convergence 🎀
- URLLC (Ultra-Reliable and Low Latency Communications) is all about latency-sensitive services, like self-driving vehicles, remote surgery, or drone control 😭
- mMTC (massive Machine Type Communications) is all about services with high connection-density requirements, like the ones used in smart-city and smart-agriculture scenarios 🌈
Okay now the iconic part 👑 A 5G bearer network could use DetNet to provide hard resource isolation across slices and within a given slice. Picture Slice-A and Slice-B, with DetNet used to transit the services URLLC-A and URLLC-B over them. Without DetNet, URLLC-A and URLLC-B would compete for bandwidth resources, and the latency and reliability requirements would not be guaranteed 💀 With DetNet, URLLC-A and URLLC-B get separate bandwidth reservations, so there is no resource conflict between them. It's giving "as though they were in different physical networks" 🫶
10.4. Non-5G Applications of Network Slicing
Lowkey, the operation of services that aren't related to 5G is not part of the 5G network slicing definition and scope 🧚 But network slicing is likely to become a preferred approach for providing various services across a shared physical infrastructure. Examples include providing services for electrical utilities and pro audio via slices 🔥 Use cases like these could become more common once the work for the 5G CN evolves to include wired as well as wireless access 🌸
10.5. Limitations of DetNet in Network Slicing
Real talk, DetNet cannot cover every network slicing use case 🙈 One issue is that DetNet is a point-to-point or point-to-multipoint technology, but network slicing ultimately needs multipoint-to-multipoint guarantees 😭 Another issue is that the number of flows DetNet can carry is limited by DetNet scalability. Flow aggregation and queuing management modification may help address this issue ✨ Additional work and discussion are needed to address these topics 💜
10.6. Network Slicing Today and in the Future
Network slicing has so much promise for satisfying many requirements of future network deployment scenarios 🦋 But it is still a collection of ideas and analyses without a specific technical solution, ngl. DetNet is one of various technologies that could potentially be used in network slicing, along with, for example, Flex-E and segment routing 🌈 For more info, check out the IETF 99 Network Slicing BoF session agenda and materials as provided in [IETF99-netslicing-BoF] 🎀
10.7. Network Slicing Requests to the IETF
- Isolation from other flows through queuing management 💖
- Service quality customization and guarantees 👑
- Security 🔥
- Use Case Common Themes
Okay bestie, this section summarizes the expected properties of a DetNet network, based on the use cases we just went through 🧚✨
11.1. Unified, Standards-Based Networks
11.1.1. Extensions to Ethernet
A DetNet network is not "a new kind of network" -- it is based on extensions to existing Ethernet standards, including elements of IEEE 802.1 TSN and related standards 🌸 Presumably, it will be possible to run DetNet over other underlying transports besides Ethernet, but Ethernet is explicitly supported 💅
11.1.2. Centrally Administered Networks
In general, a DetNet network is not expected to be "plug and play" 🙈 Instead, some type of centralized network configuration and control system is expected. Such a system may be in a single central location, or it may be 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 🦋
11.1.3. Standardized Data-Flow Information Models
Data-flow information models to be used with DetNet networks are to be specified by DetNet 💜
11.1.4. Layer 2 and Layer 3 Integration
A DetNet network is intended to integrate between Layer 2 (bridged) network(s) (e.g., an AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g., using IP-based protocols) 🎀 One example 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 🌈
11.1.5. IPv4 Considerations
This document explicitly does not specify any particular implementation or protocol. However, it has been observed that various use cases (and their associated industries) described herein are explicitly based on IPv4 (as opposed to IPv6), and it is not considered practical to expect such implementations to migrate to IPv6 in order to use DetNet 😭 So the expectation is that even if not every feature of DetNet is available in an IPv4 context, at least some of the significant benefits (such as guaranteed end-to-end delivery and low latency) will be available ✨
11.1.6. Guaranteed End-to-End Delivery
Packets in a DetNet flow are guaranteed not to be dropped by the network due to congestion 🫶 However, the network may drop packets for intended reasons, e.g., per security measures. Similarly, best-effort traffic on a DetNet is subject to being dropped (as on a non-DetNet IP network). Also note that this guarantee applies to actions taken by DetNet protocol software and does not provide any guarantee against lower-level errors such as media errors or checksum errors 💀
11.1.7. Replacement for Multiple Proprietary Deterministic Networks
There are many proprietary, non-interoperable deterministic Ethernet-based networks available. DetNet is intended to provide an open-standards-based alternative to such networks 👑
11.1.8. Mix of Deterministic and Best-Effort Traffic
DetNet is intended to support the coexistence of time-sensitive operational (OT) traffic and informational (IT) traffic on the same ("unified") network 🦋
11.1.9. Unused Reserved Bandwidth 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. This happens 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 💜
11.1.10. Lower-Cost, Multi-Vendor Solutions
The DetNet network specifications are intended to enable an ecosystem in which multiple vendors can create interoperable products. This promotes device diversity and potentially higher numbers of each device manufactured, which promotes cost reduction and cost competition among vendors 🧚 In other words, vendors should be able to create DetNet networks at lower cost and with greater diversity of available devices than existing proprietary networks 🎀
11.2. Scalable Size
DetNet networks range in size from very small (e.g., inside a single industrial machine) to very large (e.g., a utility-grid network spanning a whole country and involving many "hops" over various kinds of links -- for example, radio repeaters, microwave links, or fiber optic links) 🌈 However, recall that the scope of DetNet is confined to networks that are centrally administered, and thereby explicitly excludes unbounded decentralized networks such as the Internet 🙈
11.2.1. Scalable Number of Flows
The number of flows in a given network application can potentially be large, and can potentially grow faster than the number of nodes and hops. So the network should provide a sufficient (perhaps configurable) maximum number of flows for any given application 💖
11.3. Scalable Timing Parameters and Accuracy
11.3.1. Bounded Latency
DetNet data-flow information models are 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 expected that the network may not be able to provide a given requested service level. If this is indeed the case, the network control system should reply that the requested services are not available, as opposed to accepting the parameter but then not delivering the desired behavior 😭
11.3.2. Low Latency
Various applications may state that they require "extremely low latency." However, depending on the application, "extremely low" may imply very different latency bounds. For example, "low latency" across a utility-grid network is a different order of magnitude of latency values compared to "low latency" in a motor control loop in a small machine 🌸 It is intended that the mechanisms for specifying desired latency include wide ranges, and that architecturally there is nothing to prevent arbitrarily low latencies from being implemented in a given network ✨
11.3.3. Bounded Jitter (Latency Variation)
As with the other latency-related elements noted above, parameters that can determine or request permitted variations in latency should be available 🎀
11.3.4. Symmetrical Path Delays
Some applications would like to specify that the transit delay time values be equal for both the transmit path and the return path 🧚
11.4. High Reliability and Availability
Reliability is of critical importance to many DetNet applications, because the 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% uptime (where 99.9999 means "six nines") or even 12 nines. 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, so that a system can seamlessly switch between the paths while maintaining its required level of performance 💜
11.5. Security ✨
Security is literally of critical importance for so many DetNet applications 🔐. A DetNet network has to be able to stay secure even when devices fail, attackers show up, or devices misbehave 💀. Here's the tea: DetNet traffic is time sensitive, so it's not enough for the data content to arrive as intended. It also has to arrive at the expected time ⏰. That can present "new" security challenges for implementers, and those challenges have to be addressed properly 🫶. There are other security implications too, including (but not limited to) the change in attack surface presented by PRE 🎀.
11.6. Deterministic Flows 🦋
Reserved-bandwidth data flows must be isolated from each other and from best-effort traffic 🔒. That way, even if the network is totally saturated with best-effort (and/or reserved-bandwidth) traffic, the configured flows are not adversely affected 👑. Iconic isolation energy.
12. Security Considerations 🛡️
Okay, this section is so important 😭. This document covers a bunch of representative applications and network scenarios that are expected to make use of DetNet technologies 💅. Each of the potential DetNet use cases will have security considerations from both the use-specific perspective and the DetNet technology perspective. Some use-specific security considerations were already discussed above, but a more comprehensive discussion is captured in [DetNet-Security] ("Deterministic Networking (DetNet) Security Considerations"). Readers are encouraged to review [DetNet-Security] to gain a more complete understanding of DetNet-related security considerations 📚🫶.
13. IANA Considerations 🌸
No drama here, bestie. This document has no IANA actions 🌸.
14. Informative References 📚
Here are all the receipts, kept exactly as they were 💜:
[Ahm14] Ahmed, M. and R. Kim, "Communication Network Architectures
for Smart-Wind Power Farms", Energies 2014, pp. 3900-3921,
DOI 10.3390/en7063900, June 2014.
[Arch-for-6TiSCH]
Thubert, P., Ed., "An Architecture for IPv6 over the TSCH
mode of IEEE 802.15.4", Work in Progress,
draft-ietf-6tisch-architecture-20, March 2019.
[BACnet-IP]
ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP",
January 1999, <http://www.bacnet.org/Addenda/
Add-1995-135a.pdf>.
[BAS-DetNet]
Kaneko, Y. and S. Das, "Building Automation Use Cases and
Requirements for Deterministic Networking", Work in
Progress, draft-bas-usecase-detnet-00, October 2015.
[CoAP-6TiSCH]
Sudhaakar, R., Ed. and P. Zand, "6TiSCH Resource
Management and Interaction using CoAP", Work in Progress,
draft-ietf-6tisch-coap-03, March 2015.
[CoMP] NGMN Alliance, "RAN EVOLUTION PROJECT COMP EVALUATION AND
ENHANCEMENT", VERSION 2.0, NGMN Alliance, March 2015,
<https://www.ngmn.org/fileadmin/user_upload/
NGMN_RANEV_D3_CoMP_Evaluation_and_Enhancement_v2.0.pdf>.
[Content_Protection]
Olsen, D., "1722a Content Protection", April 2012,
<http://grouper.ieee.org/groups/1722/contributions/2012/
avtp_dolsen_1722a_content_protection.pdf>.
[CPRI] CPRI Cooperation, "Common Public Radio Interface (CPRI);
Interface Specification", CPRI Specification V6.1,
July 2014, <http://www.cpri.info/downloads/
CPRI_v_6_1_2014-07-01.pdf>.
[DCI] Digital Cinema Initiatives, LLC, "DCI Specification,
Version 1.3", June 2018, <https://www.dcimovies.com/>.
[Det-Fwd-PHB]
Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
Work in Progress,
draft-svshah-tsvwg-deterministic-forwarding-04,
August 2015.
[DetNet-6TiSCH]
Thubert, P., Ed., "6TiSCH requirements for DetNet", Work
in Progress, draft-thubert-6tisch-4detnet-01, June 2015.
[DetNet-Arch]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", Work in Progress,
draft-ietf-detnet-architecture-13, May 2019.
[DetNet-Audio-Reqs]
Gunther, C., Ed. and E. Grossman, Ed., "Deterministic
Networking Professional Audio Requirements", Work in
Progress, draft-gunther-detnet-proaudio-req-01,
March 2015.
[DetNet-Mobile]
Zha, Y., "Deterministic Networking Use Case in Mobile
Network", Work in Progress, draft-zha-detnet-use-case-00,
July 2015.
[DetNet-RAN]
Korhonen, J., "Deterministic networking for radio
access networks", Work in Progress,
draft-korhonen-detnet-telreq-00, May 2015.
[DetNet-Security]
Mizrahi, T., Grossman, E., Ed., Hacker, A., Das, S.,
Dowdell, J., Austad, H., Stanton, K., and N. Finn,
"Deterministic Networking (DetNet) Security
Considerations", Work in Progress,
draft-ietf-detnet-security-04, March 2019.
[DetNet-Util-Reqs]
Wetterwald, P. and J. Raymond, "Deterministic Networking
Uitilities requirements", Work in Progress,
draft-wetterwald-detnet-utilities-reqs-02, June 2015.
[eCPRI] IEEE Standards Association, "Common Public Radio
Interface: eCPRI Interface Specification V1.2", June 2018,
<http://www.cpri.info/>.
[ESPN_DC2] Daley, D., "ESPN's DC2 Scales AVB Large", SVG News,
June 2014, <https://sportsvideo.org/main/blog/2014/06/
espns-dc2-scales-avb-large>.
[EtherCAT] "EtherCAT Technology Group",
<https://www.ethercat.org/default.htm>.
[FL-net] Japan Electrical Manufacturers Association, "JEMA 1479 -
English Edition", September 2012,
<https://www.jema-net.or.jp/Japanese/standard/opcn/pdf/
JEM_1479e(20120927).pdf>.
[Fronthaul]
Chen, D. and T. Mustala, "Ethernet Fronthaul
Considerations", IEEE 1904.3, February 2015,
<http://www.ieee1904.org/3/meeting_archive/2015/02/
tf3_1502_chen_1.pdf>.
[IEC-60834]
International Electrotechnical Commission, "Teleprotection
equipment of power systems - Performance and testing",
IEC 60834, October 1999.
[IEC-60870-5-104]
International Electrotechnical Commission, "Telecontrol
equipment and systems - Part 5-104: Transmission protocols
- Network access for IEC 60870-5-101 using standard
transport profiles", IEC 60870-5-104, June 2006.
[IEC-61400-25]
International Electrotechnical Commission, "Communications
for monitoring and control of wind power plants",
IEC 61400-25, June 2013.
[IEC-61850-5:2013]
International Electrotechnical Commission, "Communication
networks and systems for power utility automation -
Part 5: Communication requirements for functions and
device models", IEC 61850-5, January 2013.
[IEC-61850-9-2:2011]
International Electrotechnical Commission, "Communication
networks and systems for power utility automation -
Part 9-2: Specific communication service mapping (SCSM) -
Sampled values over ISO/IEC 8802-3", IEC 61850-9-2,
September 2011.
[IEC-61850-90-12:2015]
International Electrotechnical Commission, "Communication
networks and systems for power utility automation -
Part 90-12: Wide area network engineering guidelines",
IEC TR 61850-90-12, July 2015.
[IEC-62357-200:2015]
International Electrotechnical Commission, "Power systems
management and associated information exchange - Part 200:
Guidelines for migration from Internet Protocol version 4
(IPv4) to Internet Protocol version 6 (IPv6)",
IEC 62357-200:2015, July 2015.
[IEC-62439-3:2016]
International Electrotechnical Commission, "Industrial
communication networks - High availability automation
networks - Part 3: Parallel Redundancy Protocol (PRP) and
High-availability Seamless Redundancy (HSR)", March 2016.
[IEC-IEEE-61850-9-3:2016]
International Electrotechnical Commission, "Communication
networks and systems for power utility automation -
Part 9-3: Precision time protocol profile for power
utility automation", IEC 61850-9-3, May 2016.
[IEEE-1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Standard 1588, <https://standards.ieee.org/findstds/
standard/1588-2008.html>.
[IEEE-1646]
IEEE, "IEEE Standard Communication Delivery Time
Performance Requirements for Electric Power Substation
Automation", IEEE Standard 1646,
<https://standards.ieee.org/standard/1646-2004.html>.
[IEEE-1722]
IEEE, "IEEE Standard for a Transport Protocol for
Time-Sensitive Applications in Bridged Local Area
Networks", IEEE Standard 1722,
<https://standards.ieee.org/findstds/
standard/1722-2016.html>.
[IEEE-1815]
IEEE Standards Association, "IEEE Standard for Electric
Power Systems Communications-Distributed Network Protocol
(DNP3)", IEEE Standard 1815, <https://ieeexplore.ieee.org/
servlet/opac?punumber=6327576>.
[IEEE-19143]
IEEE Standards Association, "IEEE Standard for Radio over
Ethernet Encapsulations and Mappings", IEEE 1914.3,
<https://standards.ieee.org/develop/project/1914.3.html>.
[IEEE-80211]
IEEE Standard for Information technology, "IEEE Std.
802.11, Telecommunications and information exchange
between systems--Local and metropolitan area networks--
Specific requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications",
<https://standards.ieee.org/standard/802_11-2016.html>.
[IEEE-802154]
IEEE Standard for Information technology, "IEEE Std.
802.15.4, Part 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low Rate
Wireless Personal Area Networks (WPANs)",
<https://standards.ieee.org/standard/802_15_4-2015.html>.
[IEEE-8021AS]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Timing and Synchronization for Time-Sensitive
Applications in Bridged Local Area Networks",
IEEE 802.1AS,
<http://www.ieee802.org/1/pages/802.1as.html>.
[IEEE-8021CM]
"IEEE Standard for Local and metropolitan area networks -
Time-Sensitive Networking for Fronthaul", IEEE
Standard 802.1CM,
<https://standards.ieee.org/standard/802_1CM-2018.html>.
[IEEE-8021TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networking Task Group",
<http://www.ieee802.org/1/pages/avbridges.html>.
[IETF99-netslicing-BoF]
"Network Slicing (netslicing) BoF", IETF 99, Prague,
July 2017, <https://datatracker.ietf.org/meeting/99/
materials/slides-99-netslicing-chairs-netslicing-bof-04>.Okay, the reading list keeps going, and these are the receipts 📚✨
[Interface-6TiSCH-6top]
Wang, Q., Ed. and X. Vilajosana, "6TiSCH Operation
Sublayer (6top) Interface", Work in Progress,
draft-ietf-6tisch-6top-interface-04, July 2015.
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation",
<https://www.isa.org/isa100/>.
[KNX] KNX Association, "ISO/IEC 14543-3 - KNX", November 2006.
[LonTalk] Echelon Corp., "LonTalk(R) Protocol Specification
Version 3.0", 1994, <http://www.enerlon.com/JobAids/
Lontalk%20Protocol%20Spec.pdf>.
[MailingList-6TiSCH]
IETF, "6TiSCH Mailing List",
<https://mailarchive.ietf.org/arch/browse/6tisch/>.
[MEF22.1.1]
Metro Ethernet Forum, "Mobile Backhaul Phase 2 Amendment 1
-- Small Cells", MEF 22.1.1, July 2014,
<http://www.mef.net/Assets/Technical_Specifications/PDF/
MEF_22.1.1.pdf>.
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the
Emulation of PDH Circuits over Metro Ethernet Networks",
MEF 8, October 2004, <https://www.mef.net/
Assets/Technical_Specifications/PDF/MEF_8.pdf>.
[METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and
wireless system", Document Number ICT-317669-METIS/D1.1,
April 2013, <https://metis2020.com/wp-content/
uploads/deliverables/METIS_D1.1_v1.pdf>.
[MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol
Specification", April 2012,
<http://www.modbus.org/specs.php>.
[NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0,
February 2015, <https://www.ngmn.org/fileadmin/ngmn/
content/downloads/Technical/2015/
NGMN_5G_White_Paper_V1_0.pdf>.
[NGMN-Fronth]
NGMN Alliance, "Fronthaul Requirements for C-RAN",
March 2015, <https://www.ngmn.org/fileadmin/user_upload/
NGMN_RANEV_D1_C-RAN_Fronthaul_Requirements_v1.0.pdf>.
[OPCXML] OPC Foundation, "OPC Data Access (OPC DA) Specification",
<http://www.opcti.com/opc-da-specification.aspx>.
[PCE] IETF, "Path Computation Element",
<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[PROFIBUS] IEC, "PROFIBUS Standard - DP Specification (IEC 61158
Type 3)", <https://www.profibus.com/>.
[PROFINET] "PROFINET Technology",
<https://us.profinet.com/technology/profinet/>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
<https://www.rfc-editor.org/info/rfc4553>.
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
<https://www.rfc-editor.org/info/rfc5086>.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
"Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
DOI 10.17487/RFC5087, December 2007,
<https://www.rfc-editor.org/info/rfc5087>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and A. Vainshtein, "Residence Time Measurement in MPLS
Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
<https://www.rfc-editor.org/info/rfc8169>.
[Spe09] Barbosa, R., Sadre, R., and A. Pras, "A First Look into
SCADA Network Traffic", IP Network Operations and
Management Symposium, DOI 10.1109/NOMS.2012.6211945,
June 2012, <https://ieeexplore.ieee.org/document/6211945>.
[SR-IP-RAN-Use-Case]
Khasnabish, B., Hu, F., and L. Contreras, "Segment
Routing in IP RAN use case", Work in Progress,
draft-kh-spring-ip-ran-use-case-02, November 2014.
[SRP_LATENCY]
Gunther, C., "Specifying SRP Acceptable Latency",
March 2014, <http://www.ieee802.org/1/files/public/
docs2014/cc-cgunther-acceptable-latency-0314-v01.pdf>.
[Sublayer-6TiSCH-6top]
Wang, Q., Ed. and X. Vilajosana, "6TiSCH Operation
Sublayer (6top)", Work in Progress,
draft-wang-6tisch-6top-sublayer-04, November 2015.
[syncE] International Telecommunication Union, "Timing and
synchronization aspects in packet networks", ITU-T
Recommendation G.8261, August 2013,
<https://www.itu.int/rec/T-REC-G.8261>.
[Timing-over-MPLS]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", Work in Progress,
draft-ietf-tictoc-1588overmpls-07, October 2015.
[TR38801] 3GPP, "Study on new radio access technology: Radio access
architecture and interfaces (Release 14)", 3GPP TR 38.801,
April 2017,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3056>.
[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access (Release 16)", 3GPP TS 23.401,
March 2019, <https://portal.3gpp.org/
desktopmodules/ Specifications/
SpecificationDetails.aspx?specificationId=849>.
[TS23501] 3GPP, "System architecture for the 5G System (5GS)
(Release 15)", 3GPP TS 23.501, March 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS25104] 3GPP, "Base Station (BS) radio transmission and reception
(FDD) (Release 16)", 3GPP TS 25.104, January 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1154>.
[TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Base Station (BS) radio transmission and
reception (Release 16)", 3GPP TS 36.104, January 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2412>.
[TS36133] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Requirements for support of radio resource
management (Release 16)", 3GPP TS 36.133, January 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2420>.
[TS36211] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Physical channels and modulation (Release 15)",
3GPP TS 36.211, January 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2425>.
[TS36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2 (Release 15)",
3GPP TS 36.300, January 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2430>.
[WirelessHART]
International Electrotechnical Commission, "Industrial
networks - Wireless communication network and
communication profiles - WirelessHART(TM)",
IEC 62591:2016, March 2016.Appendix A. Use Cases Explicitly Out of Scope for DetNet ✨
This appendix is the "not invited" list 🙅♀️💅. It covers the use cases that have been decided to be outside the scope of the present DetNet work, so if your favourite use case shows up here, it's not getting in this round 🥲.
A.1. DetNet Scope Limitations ✨
okay so the scope of DetNet is deliberately narrow 🎀 It only covers specific use cases that fit the WG charter, and the WG gets to interpret what that means. When the authors gathered the use cases, DetNet's scope wasn't really nailed down yet. Once it got clarified, some use cases turned out to be outside the scope of this DetNet work 💅 The text about those was moved into this appendix so everyone knows DetNet won't support them.
The text was moved here based on the following "exclusion" principles 🦋 Quick note: instead of moving all of it, some text was edited in place to reflect the same principles.
These principles clarify the scope of the present DetNet work 🌸
- The scope of networks addressed by DetNet is limited to networks that can be centrally controlled, i.e., an "enterprise" (aka "corporate") network. This explicitly excludes "the open Internet". 🚫🌐
- Keeping time synchronization across a DetNet network is crucial to how it works 🕰️ But DetNet assumes time is maintained using other means. One example is PTP [IEEE-1588]. A use case may state the accuracy and reliability it expects from the DetNet network as part of a whole system, but it's understood that DetNet itself does not guarantee those timing properties. As of this writing, two open questions remain: (1) whether DetNet protocols will include a way for an application to communicate expectations about such timing properties to the network, and (2) if so, whether those properties would likely have a material effect on network performance as a result. 🤔✨
A.2. Internet-Based Applications
ngl there are so many apps on the open Internet that would love guaranteed delivery and bounded latency 🥺 But like we said above, all of those apps, when run over the open Internet, are out of scope for DetNet 🙈 They could be in scope in constrained environments though, meaning inside a centrally controlled DetNet network. Here are some examples 💜
A.2.1. Use Case Description
A.2.1.1. Media Content Delivery
Media content delivery is still a huge part of the Internet 📺 Yet users often get poor-quality audio and video because of the delay and jitter that's just built into today's Internet 😭
A.2.1.2. Online Gaming
Online gaming is a massive part of the gaming market 🎮 But latency can wreck the end user's experience 💀 For example, "First Person Shooter" (FPS) games are highly delay sensitive. Main character energy, but make it lag 🙃
A.2.1.3. Virtual Reality
VR has tons of commercial applications, including real estate presentations, remote medical procedures, and so on 🥽 Low latency is critical for interacting with the virtual world, because perceptual delays can cause motion sickness. Nobody wants to feel sick in the metaverse, bestie 🤢🫶
A.2.2. Internet-Based Applications Today
Internet service today is, by definition, "best effort", with no guarantees regarding delivery or bandwidth 🥲
A.2.3. Internet-Based Applications in the Future
One should be able to play Internet videos without glitches and play Internet games without lag 🍓✨
For online gaming, the desired maximum allowance for round-trip delay is typically 100 ms 🎯 It may be less for specific types of games, though. For example, for FPS games, the maximum delay should be 50 ms 🔫 Transport delay is the dominant part, with a budget of 5-20 ms.
For VR, a maximum delay of 1-10 ms is needed 🥽 And if doing remote VR, the total network delay budget is 1-5 ms. Tiny budgets, very intense, very iconic 😤
Flow identification can be used for gaming and VR, i.e., it can recognize a critical flow and provide appropriate latency bounds 🧚 Such a vibe!
A.2.4. Internet-Based Applications Requests to the IETF
- Unified control and management protocols that handle time-critical data flows 📋
- An application-aware flow-filtering mechanism that recognizes time-critical flows without doing 5-tuple matching 🔍
- A unified control plane that provides low-latency service on Layer 3 without changing the data plane 💅
- An OAM system and protocols that can help provide service provisioning that is sensitive to end-to-end delays 🌈
A.3. Pro Audio and Video - Digital Rights Management (DRM)
This text was moved to this appendix because this information is considered a link-layer topic for which DetNet is not directly responsible 🙅♀️ Not our department, babe!
Digital Rights Management (DRM) is very important to the audio and video industries 🎬 Whenever protected content is introduced into a network, there are DRM concerns that must be taken into account (see [Content_Protection]). Plenty of DRM stuff is outside the scope of network technology, but there are cases where content owners require a secure link supporting authentication and encryption to carry their audio or video content when it's outside their own secure environment (for example, see [DCI]). Locked down, no cap 🔐
As an example, two such techniques are Digital Transmission Content Protection (DTCP) and High-bandwidth Digital Content Protection (HDCP). HDCP content is not approved for retransmission within any other type of DRM, while DTCP content may be retransmitted under HDCP. So if the source of a stream is outside of the network and it uses HDCP, it is only allowed to be placed on the network with that same type of protection (i.e., HDCP). The rules are the rules, periodt 💀👑
A.4. Pro Audio and Video - Link Aggregation
Note: The term "link aggregation" is used here as defined by the text in the following paragraph, i.e., not following a more common network-industry definition. 📝
For transmitting streams that require more bandwidth than a single link in the target network can support, link aggregation is a technique for combining (aggregating) the bandwidth available on multiple physical links to create a single logical link that provides the required bandwidth 🧩 However, if aggregation is to be used, the network controller (or equivalent) must be able to determine the maximum latency of any path through the aggregate link. Know your paths, bestie 🗺️✨
A.5. Pro Audio and Video - Deterministic Time to Establish Streaming
The DetNet WG decided that guidelines for establishing a deterministic time to establish stream startup are not within the scope of DetNet 🙃 If bounded timing for establishing or re-establishing streams is required in a given use case, it's up to the application/system to achieve it. Not DetNet's job, slay the app side instead 💖
Acknowledgments 🫶
Pro audio (Section 2)
- As also acknowledged in [DetNet-Audio-Reqs], the editor would like to acknowledge the help of the following individuals and the companies they represent 🌸
- Jeff Koftinoff, Meyer Sound
- Jouni Korhonen, Associate Technical Director, Broadcom
- Pascal Thubert, CTAO, Cisco
- Kieran Tyrrell, Sienda New Media Technologies GmbH
Utility telecom (Section 3)
- Information regarding utility telecom was derived from [DetNet-Util-Reqs]. As in that document, the following individuals are acknowledged here 🦋
- Faramarz Maghsoodlou, Ph.D., IoT Connected Industries and Energy Practice, Cisco
- Pascal Thubert, CTAO, Cisco
- The wind power generation use case has been extracted from the study of wind parks conducted within the 5GPPP VirtuWind Project 🌬️ The project is funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 671648 (VirtuWind). 💜
Building automation systems (Section 4)
- Please see [BAS-DetNet]. 🏢
Wireless for industrial applications (Section 5)
- See [DetNet-6TiSCH]. 📡
- [DetNet-6TiSCH] derives from the 6TiSCH architecture, which is the result of multiple interactions -- in particular, during the 6TiSCH (bi)weekly interim call, relayed through the 6TiSCH mailing list at the IETF [MailingList-6TiSCH]. Teamwork makes the dream work ✨
- As also acknowledged in [DetNet-6TiSCH], the editor wishes to thank Kris Pister, Thomas Watteyne, Xavier Vilajosana, Qin Wang, Tom Phinney, Robert Assimiti, Michael Richardson, Zhuo Chen, Malisa Vucinic, Alfredo Grieco, Martin Turon, Dominique Barthel, Elvis Vogli, Guillaume Gaillard, Herman Storey, Maria Rita Palattella, Nicola Accettura, Patrick Wetterwald, Pouria Zand, Raghuram Sudhaakar, and Shitanshu Shah for their participation and various contributions 🙌
Cellular radio (Section 6)
- See [DetNet-RAN]. 📶
Internet applications and CoMP (Section 6)
- As also acknowledged in [DetNet-Mobile], authored by Yiyong Zha, the editor would like to thank the following people for their reviews, suggestions, comments, and proposed text: Jing Huang, Junru Lin, Lehong Niu, and Oliver Huang. 💖
Industrial Machine to Machine (M2M) (Section 7)
- The editor would like to thank Feng Chen and Marcel Kiessling for their comments and suggestions. 🤖
Mining industry (Section 8)
- This text was written by Diego Dujovne, who worked in conjunction with Xavier Vilajosana. ⛏️
Private blockchain (Section 9)
- This text was written by Daniel Huang. ⛓️
Network slicing (Section 10)
- This text was written by Xuesong Geng, who would like to acknowledge Norm Finn and Mach Chen for their useful comments. 🍰
Contributors 🫶
okay so RFC 7322 ("RFC Style Guide") usually caps the author list on the front page at five people, bestie 💅 that's way fewer than the 19 people below, who ALSO put in serious work on this doc 🌸. The editor wants to thank and shout out each of them for writing text, and you can check out the Acknowledgments section too ✨.
Craig Gunther (Harman International)
10653 South River Front Parkway
South Jordan, UT 84095
United States of America
Phone: +1 801 568 7675
Email: craig.gunther@harman.comPascal Thubert (Cisco Systems, Inc.)
Building D, 45 Allee des Ormes - BP1200
Mougins - Sophia Antipolis 06254
France
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.comPatrick Wetterwald (Cisco Systems)
45 Allee des Ormes
Mougins 06250
France
Phone: +33 4 97 23 26 36
Email: pwetterw@cisco.comJean Raymond (Hydro-Quebec)
1500 University
Montreal, Quebec H3A 3S7
Canada
Phone: +1 514 840 3000
Email: raymond.jean@hydro.qc.caJouni Korhonen (Broadcom Corporation)
3151 Zanker Road
San Jose, CA 95134
United States of America
Email: jouni.nospam@gmail.comYu Kaneko (Toshiba)
1 Komukai-Toshiba-cho
Saiwai-ku, Kasasaki-shi, Kanagawa
Japan
Email: yu1.kaneko@toshiba.co.jpSubir Das (Vencore Labs)
150 Mount Airy Road
Basking Ridge, NJ 07920
United States of America
Email: sdas@appcomsci.comBalazs Varga (Ericsson)
Konyves Kalman krt. 11/B
Budapest 1097
Hungary
Email: balazs.a.varga@ericsson.comJanos Farkas (Ericsson)
Konyves Kalman krt. 11/B
Budapest 1097
Hungary
Email: janos.farkas@ericsson.comFranz-Josef Goetz (Siemens)
Gleiwitzerstr. 555
Nurnberg 90475
Germany
Email: franz-josef.goetz@siemens.comJuergen Schmitt (Siemens)
Gleiwitzerstr. 555
Nurnberg 90475
Germany
Email: juergen.jues.schmitt@siemens.comXavier Vilajosana (Worldsensing)
483 Arago
Barcelona, Catalonia 08013
Spain
Email: xvilajosana@worldsensing.comToktam Mahmoodi (King's College London)
Strand, London WC2R 2LS
United Kingdom
Email: toktam.mahmoodi@kcl.ac.ukSpiros Spirou (Intracom Telecom)
19.7 km Markopoulou Ave.
Peania, Attiki 19002
Greece
Email: spiros.spirou@gmail.comPetra Vizarreta (Technical University of Munich)
Maxvorstadt, Arcisstrasse 21
Munich 80333
Germany
Email: petra.stojsavljevic@tum.deDaniel Huang (ZTE Corporation, Inc.)
No. 50 Software Avenue
Nanjing, Jiangsu 210012
China
Email: huang.guangping@zte.com.cnXuesong Geng (Huawei Technologies)
Email: gengxuesong@huawei.comDiego Dujovne (Universidad Diego Portales)
Email: diego.dujovne@mail.udp.clMaik Seewald (Cisco Systems)
Email: maseewal@cisco.comAuthor's Address 🦋
Ethan Grossman (editor) is the one who kept this whole thing together, and here's where you can reach them 💜
Ethan Grossman (editor)
Dolby Laboratories, Inc.
1275 Market Street
San Francisco, CA 94103
United States of America
Phone: +1 415 645 4726
Email: ethan.grossman@dolby.com
URI: http://www.dolby.com📦 where this page comes from
- ietf: rfc8578 2019-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms