draft-ietf-detnet-use-cases-14.txt   draft-ietf-detnet-use-cases-15.txt 
Internet Engineering Task Force E. Grossman, Ed. Internet Engineering Task Force E. Grossman, Ed.
Internet-Draft DOLBY Internet-Draft DOLBY
Intended status: Informational February 23, 2018 Intended status: Informational April 2, 2018
Expires: August 27, 2018 Expires: October 4, 2018
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-14 draft-ietf-detnet-use-cases-15
Abstract Abstract
This draft documents requirements in several diverse industries to This draft documents requirements in several diverse industries to
establish multi-hop paths for characterized flows with deterministic establish multi-hop paths for characterized flows with deterministic
properties. In this context deterministic implies that streams can properties. In this context deterministic implies that streams can
be established which provide guaranteed bandwidth and latency which be established which provide guaranteed bandwidth and latency which
can be established from either a Layer 2 or Layer 3 (IP) interface, can be established from either a Layer 2 or Layer 3 (IP) interface,
and which can co-exist on an IP network with best-effort traffic. and which can co-exist on an IP network with best-effort traffic.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2018. This Internet-Draft will expire on October 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 8 skipping to change at page 4, line 8
6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49
6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50 6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50
6.1.3. Time Synchronization Constraints . . . . . . . . . . 52 6.1.3. Time Synchronization Constraints . . . . . . . . . . 52
6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 54 6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 54
6.1.5. Security Considerations . . . . . . . . . . . . . . . 54 6.1.5. Security Considerations . . . . . . . . . . . . . . . 54
6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 55 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 55
6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 55 6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 55
6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 55 6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 55
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 56 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 56
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 58 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 58
7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 58 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 59
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 58 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 59
7.2. Industrial M2M Communication Today . . . . . . . . . . . 59 7.2. Industrial M2M Communication Today . . . . . . . . . . . 60
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 60 7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 60
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 61 7.2.2. Stream Creation and Destruction . . . . . . . . . . . 61
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 61 7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 61
7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 61 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 62
8. Mining Industry . . . . . . . . . . . . . . . . . . . . . . . 62 8. Mining Industry . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Use Case Description . . . . . . . . . . . . . . . . . . 62 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 62
8.2. Mining Industry Today . . . . . . . . . . . . . . . . . . 62 8.2. Mining Industry Today . . . . . . . . . . . . . . . . . . 63
8.3. Mining Industry Future . . . . . . . . . . . . . . . . . 63 8.3. Mining Industry Future . . . . . . . . . . . . . . . . . 63
8.4. Mining Industry Asks . . . . . . . . . . . . . . . . . . 64 8.4. Mining Industry Asks . . . . . . . . . . . . . . . . . . 64
9. Private Blockchain . . . . . . . . . . . . . . . . . . . . . 64 9. Private Blockchain . . . . . . . . . . . . . . . . . . . . . 64
9.1. Use Case Description . . . . . . . . . . . . . . . . . . 64 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 64
9.1.1. Blockchain Operation . . . . . . . . . . . . . . . . 64 9.1.1. Blockchain Operation . . . . . . . . . . . . . . . . 65
9.1.2. Blockchain Network Architecture . . . . . . . . . . . 65 9.1.2. Blockchain Network Architecture . . . . . . . . . . . 65
9.1.3. Security Considerations . . . . . . . . . . . . . . . 65 9.1.3. Security Considerations . . . . . . . . . . . . . . . 66
9.2. Private Blockchain Today . . . . . . . . . . . . . . . . 65 9.2. Private Blockchain Today . . . . . . . . . . . . . . . . 66
9.3. Private Blockchain Future . . . . . . . . . . . . . . . . 66 9.3. Private Blockchain Future . . . . . . . . . . . . . . . . 66
9.4. Private Blockchain Asks . . . . . . . . . . . . . . . . . 66 9.4. Private Blockchain Asks . . . . . . . . . . . . . . . . . 66
10. Network Slicing . . . . . . . . . . . . . . . . . . . . . . . 66 10. Network Slicing . . . . . . . . . . . . . . . . . . . . . . . 67
10.1. Use Case Description . . . . . . . . . . . . . . . . . . 66 10.1. Use Case Description . . . . . . . . . . . . . . . . . . 67
10.2. Network Slicing Use Cases . . . . . . . . . . . . . . . 67 10.2. DetNet Applied to Network Slicing . . . . . . . . . . . 67
10.2.1. Enhanced Mobile Broadband (eMBB) . . . . . . . . . . 67 10.2.1. Resource Isolation Across Slices . . . . . . . . . . 67
10.2.2. Ultra-Reliable and Low Latency Communications 10.2.2. Deterministic Services Within Slices . . . . . . . . 67
(URLLC) . . . . . . . . . . . . . . . . . . . . . . 67 10.3. A Network Slicing Use Case Example - 5G Bearer Network . 68
10.2.3. massive Machine Type Communications (mMTC) . . . . . 67 10.4. Non-5G Applications of Network Slicing . . . . . . . . . 68
10.3. Using DetNet in Network Slicing . . . . . . . . . . . . 67 10.5. Limitations of DetNet in Network Slicing . . . . . . . . 69
10.4. Network Slicing Today and Future . . . . . . . . . . . . 68 10.6. Network Slicing Today and Future . . . . . . . . . . . . 69
10.5. Network Slicing Asks . . . . . . . . . . . . . . . . . . 68 10.7. Network Slicing Asks . . . . . . . . . . . . . . . . . . 69
11. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 68 11. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 69
11.1. Unified, standards-based network . . . . . . . . . . . . 68 11.1. Unified, standards-based network . . . . . . . . . . . . 69
11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 68 11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 69
11.1.2. Centrally Administered . . . . . . . . . . . . . . . 68 11.1.2. Centrally Administered . . . . . . . . . . . . . . . 69
11.1.3. Standardized Data Flow Information Models . . . . . 69 11.1.3. Standardized Data Flow Information Models . . . . . 70
11.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . 69 11.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . 70
11.1.5. Guaranteed End-to-End Delivery . . . . . . . . . . . 69 11.1.5. Consideration for IPv4 . . . . . . . . . . . . . . . 70
11.1.6. Replacement for Multiple Proprietary Deterministic 11.1.6. Guaranteed End-to-End Delivery . . . . . . . . . . . 70
Networks . . . . . . . . . . . . . . . . . . . . . . 69 11.1.7. Replacement for Multiple Proprietary Deterministic
11.1.7. Mix of Deterministic and Best-Effort Traffic . . . . 69 Networks . . . . . . . . . . . . . . . . . . . . . . 70
11.1.8. Unused Reserved BW to be Available to Best Effort 11.1.8. Mix of Deterministic and Best-Effort Traffic . . . . 71
Traffic . . . . . . . . . . . . . . . . . . . . . . 69 11.1.9. Unused Reserved BW to be Available to Best Effort
11.1.9. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 70 Traffic . . . . . . . . . . . . . . . . . . . . . . 71
11.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . 70 11.1.10. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 71
11.3. Scalable Timing Parameters and Accuracy . . . . . . . . 70
11.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . 70 11.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . 71
11.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . 70 11.3. Scalable Timing Parameters and Accuracy . . . . . . . . 71
11.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . 71 11.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . 71
11.4. High Reliability and Availability . . . . . . . . . . . 71 11.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . 72
11.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 71 11.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . 72
11.6. Deterministic Flows . . . . . . . . . . . . . . . . . . 71 11.4. High Reliability and Availability . . . . . . . . . . . 72
12. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 71 11.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 72
12.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 72 11.6. Deterministic Flows . . . . . . . . . . . . . . . . . . 73
12.2. Internet-based Applications . . . . . . . . . . . . . . 72 12. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 73
12.2.1. Use Case Description . . . . . . . . . . . . . . . . 72 12.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 73
12.2.1.1. Media Content Delivery . . . . . . . . . . . . . 73 12.2. Internet-based Applications . . . . . . . . . . . . . . 74
12.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . 73 12.2.1. Use Case Description . . . . . . . . . . . . . . . . 74
12.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . 73 12.2.1.1. Media Content Delivery . . . . . . . . . . . . . 74
12.2.2. Internet-Based Applications Today . . . . . . . . . 73 12.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . 74
12.2.3. Internet-Based Applications Future . . . . . . . . . 73 12.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . 74
12.2.4. Internet-Based Applications Asks . . . . . . . . . . 73 12.2.2. Internet-Based Applications Today . . . . . . . . . 74
12.3. Pro Audio and Video - Digital Rights Management (DRM) . 74 12.2.3. Internet-Based Applications Future . . . . . . . . . 74
12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 74 12.2.4. Internet-Based Applications Asks . . . . . . . . . . 75
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 75 12.3. Pro Audio and Video - Digital Rights Management (DRM) . 75
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 75
14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 76 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76
14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 77 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
14.3. Building Automation Systems . . . . . . . . . . . . . . 77 14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 77
14.4. Wireless for Industrial . . . . . . . . . . . . . . . . 77 14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 78
14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 77 14.3. Building Automation Systems . . . . . . . . . . . . . . 78
14.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 77 14.4. Wireless for Industrial . . . . . . . . . . . . . . . . 78
14.7. Internet Applications and CoMP . . . . . . . . . . . . . 78 14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 78
14.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 78 14.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 79
14.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 78 14.7. Internet Applications and CoMP . . . . . . . . . . . . . 79
14.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 78 14.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 79
14.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 78 14.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 79
15. Informative References . . . . . . . . . . . . . . . . . . . 78 14.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 88 14.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 79
15. Informative References . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
This draft presents use cases from diverse industries which have in This draft presents use cases from diverse industries which have in
common a need for deterministic streams, but which also differ common a need for deterministic streams, but which also differ
notably in their network topologies and specific desired behavior. notably in their network topologies and specific desired behavior.
Together, they provide broad industry context for DetNet and a Together, they provide broad industry context for DetNet and a
yardstick against which proposed DetNet designs can be measured (to yardstick against which proposed DetNet designs can be measured (to
what extent does a proposed design satisfy these various use cases?) what extent does a proposed design satisfy these various use cases?)
skipping to change at page 51, line 27 skipping to change at page 51, line 27
transmission operations by properly assigning the network resources, transmission operations by properly assigning the network resources,
thus leaving more of the transport time budget available for link thus leaving more of the transport time budget available for link
propagation, and thus enabling longer link lengths. However, link propagation, and thus enabling longer link lengths. However, link
length is usually a given parameter and is not a controllable network length is usually a given parameter and is not a controllable network
parameter, since RRH and BBU sights are usually located in parameter, since RRH and BBU sights are usually located in
predetermined locations. However, the number of antennas in an RRH predetermined locations. However, the number of antennas in an RRH
sight might increase for example by adding more antennas, increasing sight might increase for example by adding more antennas, increasing
the MIMO capability of the network or support of massive MIMO. This the MIMO capability of the network or support of massive MIMO. This
means increasing the number of the fronthaul flows sharing the same means increasing the number of the fronthaul flows sharing the same
fronthaul link. DetNet can now control the bandwidth assignment of fronthaul link. DetNet can now control the bandwidth assignment of
the fronthaul link and the scheduling pf fronthaul packets over this the fronthaul link and the scheduling of fronthaul packets over this
link and provide adequate buffer provisioning for each flow to reduce link and provide adequate buffer provisioning for each flow to reduce
the packet loss rate. the packet loss rate.
Another way in which DetNet technology can aid Fronthaul networks is Another way in which DetNet technology can aid Fronthaul networks is
by providing effective isolation from best-effort (and other classes by providing effective isolation from best-effort (and other classes
of) traffic, which can arise as a result of network slicing in 5G of) traffic, which can arise as a result of network slicing in 5G
networks where Fronthaul traffic generated in different network networks where Fronthaul traffic generated in different network
slices might have differing performance requirements. DetNet slices might have differing performance requirements. DetNet
technology can also dynamically control the bandwidth assignment, technology can also dynamically control the bandwidth assignment,
scheduling and packet forwarding decisions and the buffer scheduling and packet forwarding decisions and the buffer
skipping to change at page 56, line 5 skipping to change at page 56, line 5
for legacy transport support) have become popular tools to build and for legacy transport support) have become popular tools to build and
manage new all-IP Radio Access Networks (RANs) manage new all-IP Radio Access Networks (RANs)
[I-D.kh-spring-ip-ran-use-case]. Although various timing and [I-D.kh-spring-ip-ran-use-case]. Although various timing and
synchronization optimizations have already been proposed and synchronization optimizations have already been proposed and
implemented including 1588 PTP enhancements implemented including 1588 PTP enhancements
[I-D.ietf-tictoc-1588overmpls] and [I-D.ietf-mpls-residence-time], [I-D.ietf-tictoc-1588overmpls] and [I-D.ietf-mpls-residence-time],
these solution are not necessarily sufficient for the forthcoming RAN these solution are not necessarily sufficient for the forthcoming RAN
architectures nor do they guarantee the more stringent time- architectures nor do they guarantee the more stringent time-
synchronization requirements such as [CPRI]. synchronization requirements such as [CPRI].
There are also existing solutions for TDM over IP such as [RFC5087] There are also existing solutions for TDM over IP such as [RFC4553],
and [RFC4553], as well as TDM over Ethernet transports such as [RFC5086], and [RFC5087], as well as TDM over Ethernet transports
[RFC5086]. such as [MEF8].
6.3. Cellular Radio Networks Future 6.3. Cellular Radio Networks Future
Future Cellular Radio Networks will be based on a mix of different Future Cellular Radio Networks will be based on a mix of different
xHaul networks (xHaul = front-, mid- and backhaul), and future xHaul networks (xHaul = front-, mid- and backhaul), and future
transport networks should be able to support all of them transport networks should be able to support all of them
simultaneously. It is already envisioned today that: simultaneously. It is already envisioned today that:
o Not all "cellular radio network" traffic will be IP, for example o Not all "cellular radio network" traffic will be IP, for example
some will remain at Layer 2 (e.g. Ethernet based). DetNet some will remain at Layer 2 (e.g. Ethernet based). DetNet
skipping to change at page 56, line 43 skipping to change at page 56, line 43
networking equipment that can make use of underlying deterministic networking equipment that can make use of underlying deterministic
link-layer services link-layer services
o Unified and standards-based network management systems and o Unified and standards-based network management systems and
protocols in all parts of the network (including Fronthaul) protocols in all parts of the network (including Fronthaul)
New radio access network deployment models and architectures may New radio access network deployment models and architectures may
require time- sensitive networking services with strict requirements require time- sensitive networking services with strict requirements
on other parts of the network that previously were not considered to on other parts of the network that previously were not considered to
be packetized at all. Time and synchronization support are already be packetized at all. Time and synchronization support are already
topical for Backhaul and Midhaul packet networks [MEF] and are topical for Backhaul and Midhaul packet networks [MEF22.1.1] and are
becoming a real issue for Fronthaul networks also. Specifically in becoming a real issue for Fronthaul networks also. Specifically in
Fronthaul networks the timing and synchronization requirements can be Fronthaul networks the timing and synchronization requirements can be
extreme for packet based technologies, for example, on the order of extreme for packet based technologies, for example, on the order of
sub +-20 ns packet delay variation (PDV) and frequency accuracy of sub +-20 ns packet delay variation (PDV) and frequency accuracy of
+0.002 PPM [Fronthaul]. +0.002 PPM [Fronthaul].
The actual transport protocols and/or solutions to establish required The actual transport protocols and/or solutions to establish required
transport "circuits" (pinned-down paths) for Fronthaul traffic are transport "circuits" (pinned-down paths) for Fronthaul traffic are
still undefined. Those are likely to include (but are not limited still undefined. Those are likely to include (but are not limited
to) solutions directly over Ethernet, over IP, and using MPLS/ to) solutions directly over Ethernet, over IP, and using MPLS/
skipping to change at page 57, line 23 skipping to change at page 57, line 23
done for Ethernet [TSNTG], which specifies the use of IEEE 1588 time done for Ethernet [TSNTG], which specifies the use of IEEE 1588 time
precision protocol (PTP) [IEEE1588] in the context of IEEE 802.1D and precision protocol (PTP) [IEEE1588] in the context of IEEE 802.1D and
IEEE 802.1Q. [IEEE8021AS] specifies a Layer 2 time synchronizing IEEE 802.1Q. [IEEE8021AS] specifies a Layer 2 time synchronizing
service, and other specifications such as IEEE 1722 [IEEE1722] service, and other specifications such as IEEE 1722 [IEEE1722]
specify Ethernet-based Layer-2 transport for time-sensitive streams. specify Ethernet-based Layer-2 transport for time-sensitive streams.
New promising work seeks to enable the transport of time-sensitive New promising work seeks to enable the transport of time-sensitive
fronthaul streams in Ethernet bridged networks [IEEE8021CM]. fronthaul streams in Ethernet bridged networks [IEEE8021CM].
Analogous to IEEE 1722 there is an ongoing standardization effort to Analogous to IEEE 1722 there is an ongoing standardization effort to
define the Layer-2 transport encapsulation format for transporting define the Layer-2 transport encapsulation format for transporting
radio over Ethernet (RoE) in the IEEE 1904.3 Task Force [IEEE19043]. radio over Ethernet (RoE) in the IEEE 1904.3 Task Force [IEEE19143].
All-IP RANs and xHhaul networks would benefit from time As mentioned in Section 6.1.2, 5G communications will provide one of
the most challenging cases for delay sensitive networking. In order
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 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), with each
intermediate split having its own data rate and delay requirements.
Packetized versions of different splits have recently been proposed
including 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. Although synchronization and time-sensitive transport services. Although
Ethernet appears to be the unifying technology for the transport, Ethernet appears to be the unifying technology for the transport,
there is still a disconnect providing Layer 3 services. The protocol there is still a disconnect providing Layer 3 services. The protocol
stack typically has a number of layers below the Ethernet Layer 2 stack typically has a number of layers below the Ethernet Layer 2
that shows up to the Layer 3 IP transport. It is not uncommon that that shows up to the Layer 3 IP transport. It is not uncommon that
on top of the lowest layer (optical) transport there is the first on top of the lowest layer (optical) transport there is the first
layer of Ethernet followed one or more layers of MPLS, PseudoWires layer of Ethernet followed one or more layers of MPLS, PseudoWires
and/or other tunneling protocols finally carrying the Ethernet layer and/or other tunneling protocols finally carrying the Ethernet layer
visible to the user plane IP traffic. visible to the user plane IP traffic.
skipping to change at page 66, line 37 skipping to change at page 67, line 9
o Coexistence in a single network of blockchain and IT traffic. o Coexistence in a single network of blockchain and IT traffic.
o Ability to scale the network by distributing the centralized o Ability to scale the network by distributing the centralized
control of the network across multiple control entities. control of the network across multiple control entities.
10. Network Slicing 10. Network Slicing
10.1. Use Case Description 10.1. Use Case Description
Network slicing divides one physical network infrastructure into Network Slicing divides one physical network infrastructure into
multiple logical networks. Each slice, corresponding to a logical multiple logical networks. Each slice, corresponding to a logical
network, uses resources and network functions independently from each network, uses resources and network functions independently from each
other. Network slicing provides flexibility of resource allocation other. Network Slicing provides flexibility of resource allocation
and service quality customization. and service quality customization.
Future services will demand network performance with a wide variety Future services will demand network performance with a wide variety
of characteristics such as high data rate, low latency, low loss of characteristics such as high data rate, low latency, low loss
rate, security and many other parameters. Ideally every service rate, security and many other parameters. Ideally every service
would have its own physical network satisfying its particular would have its own physical network satisfying its particular
performance requirements, however that would be prohibitively performance requirements, however that would be prohibitively
expensive. Network slicing can provide a customized slice for a expensive. Network Slicing can provide a customized slice for a
single service, and multiple slices can share the same physical single service, and multiple slices can share the same physical
network. This method can optimize the performance for the service at network. This method can optimize the performance for the service at
lower cost, and the flexibility of setting up and release the slices lower cost, and the flexibility of setting up and release the slices
also allows the user to allocate the network resources dynamically. also allows the user to allocate the network resources dynamically.
Unlike other DetNet use cases, Network slicing is not a specific Unlike the other use cases presented here, Network Slicing is not a
application with specific deterministic requirements; it is proposed specific application that depends on specific deterministic
as a new requirement for the future network, which is still in properties; rather it is introduced as an area of networking to which
discussion, and DetNet is a candidate solution for it. DetNet might be applicable.
10.2. Network Slicing Use Cases 10.2. DetNet Applied to Network Slicing
Network Slicing is a core feature of 5G defined in 3GPP, which is 10.2.1. Resource Isolation Across Slices
currently under development. A Network Slice in mobile network is a
complete logical network including Radio Access Network (RAN) and
Core Network (CN). It provides telecommunication services and
network capabilities, which may vary (or not) from slice to slice.
A 5G bearer network is a typical use case of network slicing, One of the requirements discussed for Network Slicing is the "hard"
including 3 service scenarios: enhanced Mobile Broadband (eMBB), separation of various users' deterministic performance. That is, it
Ultra-Reliable and Low Latency Communications (URLLC), and massive should be impossible for activity, lack of activity, or changes in
Machine Type Communications (mMTC). Each of these are described activity of one or more users to have any appreciable effect on the
below. deterministic performance parameters of any other slices. Typical
techniques used today, which share a physical network among users, do
not offer this level of isolation. DetNet can supply point-to-point
or point-to-multipoint paths that offer bandwidth and latency
guarantees to a user that cannot be affected by other users' data
traffic. Thus DetNet is a powerful tool when latency and reliability
are required in Network Slicing.
10.2.1. Enhanced Mobile Broadband (eMBB) 10.2.2. Deterministic Services Within Slices
eMBB focuses on services characterized by high data rates, such as Slices may need to provide services with DetNet-type performance
high definition (HD) videos, virtual reality (VR), augmented reality guarantees, however we note that a system can be implemented to
(AR), and fixed mobile convergence (FMC). provide such services in more than one way. For example the slice
itself might be implemented using DetNet, and thus 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 thus can enjoy similar
service guarantees.
10.2.2. Ultra-Reliable and Low Latency Communications (URLLC) 10.3. A Network Slicing Use Case Example - 5G Bearer Network
URLLC focuses on latency-sensitive services, such as self-driving Network Slicing is a core feature of 5G defined in 3GPP, which is
vehicles, remote surgery, or drone control. currently under development. A network slice in a mobile network is
a complete logical network including Radio Access Network (RAN) and
Core Network (CN). It provides telecommunication services and
network capabilities, which may vary from slice to slice. A 5G
bearer network is a typical use case of Network Slicing; for example
consider three 5G service scenarios: eMMB, URLLC, and mMTC.
10.2.3. massive Machine Type Communications (mMTC) o eMBB (Enhanced Mobile Broadband) focuses on services characterized
by high data rates, such as high definition videos, virtual
reality, augmented reality, and fixed mobile convergence.
mMTC focuses on services that have high requirements for connection o URLLC (Ultra-Reliable and Low Latency Communications) focuses on
density, such as those typical for smart city and smart agriculture latency-sensitive services, such as self-driving vehicles, remote
use cases. surgery, or drone control.
10.3. Using DetNet in Network Slicing o mMTC (massive Machine Type Communications) focuses on services
that have high requirements for connection density, such as those
typical for smart city and smart agriculture use cases.
One of the requirements discussed for network slicing is the "hard" A 5G bearer network could use DetNet to provide hard resource
separation of various users' deterministic performance. That is, it isolation across slices and within the slice. For example consider
should be impossible for activity, lack of activity, or changes in Slice-A and Slice-B, with DetNet used to transit services URLLC-A and
activity of one or more users to have any appreciable effect on the URLLC-B over them. Without DetNet, URLLC-A and URLLC-B would compete
deterministic performance parameters of any other users. Typical for bandwidth resource, and latency and reliability would not be
techniques used today, which share a physical network among users, do guaranteed. With DetNet, URLLC-A and URLLC-B have separate bandwidth
not offer this kind of insulation. DetNet can supply point-to-point reservation and there is no resource conflict between them, as though
or point-to-multipoint paths that offer bandwidth and latency they were in different logical networks.
guarantees to a user that cannot be affected by other users' data
traffic.
Thus DetNet is a powerful tool when latency and reliability are 10.4. Non-5G Applications of Network Slicing
required in Network Slicing. However, DetNet cannot cover every
Network Slicing use case, and there are some other problems to be
solved. Firstly, DetNet is a point-to-point or point-to-multipoint
technology while Network Slicing needs multi-point to multi-point
guarantee. Second, the number of flows that can be carried by DetNet
is limited by DetNet scalability. Flow aggregation and queuing
management modification may help to fix the problem. More work and
discussions are needed in these topics.
10.4. Network Slicing Today and Future Although operation of services not related to 5G is not part of the
5G Network Slicing definition and scope, Network Slicing is likely to
become a preferred approach to providing various services across a
shared physical infrastructure. Examples include providing
electrical utilities services and pro audio services via slices. Use
cases like these could become more common once the work for the 5G
core network evolves to include wired as well as wireless access.
Network slicing can satisfy the requirements of a lot of future 10.5. Limitations of DetNet in Network Slicing
deployment scenario, but it is still a collection of ideas and
analysis, without a specific technical solution. A lot of
technologies, such as Flex-E, Segment Routing, and DetNet have
potential to be used in Network Slicing. For more details please see
IETF99 Network Slicing BOF session agenda and materials.
10.5. Network Slicing Asks DetNet cannot cover every Network Slicing use case. One issue is
that DetNet is a point-to-point or point-to-multipoint technology,
however Network Slicing ultimately needs multi-point to multi-point
guarantees. Another issue is that the number of flows that can be
carried by DetNet is limited by DetNet scalability; flow aggregation
and queuing management modification may help address this.
Additional work and discussion are needed to address these topics.
10.6. Network Slicing Today and Future
Network Slicing has the promise to satisfy many requirements of
future network deployment scenarios, but it is still a collection of
ideas and analysis, without a specific technical solution. DetNet is
one of various technologies that have potential to be used in Network
Slicing, along with for example Flex-E and Segment Routing. For more
information please see the IETF99 Network Slicing BOF session agenda
and materials.
10.7. Network Slicing Asks
o Isolation from other flows through Queuing Management o Isolation from other flows through Queuing Management
o Service Quality Customization and Guarantee o Service Quality Customization and Guarantee
o Security o Security
11. Use Case Common Themes 11. Use Case Common Themes
This section summarizes the expected properties of a DetNet network, This section summarizes the expected properties of a DetNet network,
skipping to change at page 69, line 24 skipping to change at page 70, line 25
11.1.4. L2 and L3 Integration 11.1.4. L2 and L3 Integration
A DetNet network is intended to integrate between Layer 2 (bridged) A DetNet network is intended to integrate between Layer 2 (bridged)
network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g. network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g.
using IP-based protocols). One example of this is "making AVB/TSN- using IP-based protocols). One example of this is "making AVB/TSN-
type deterministic performance available from Layer 3 applications, type deterministic performance available from Layer 3 applications,
e.g. using RTP". Another example is "connecting two AVB/TSN LANs e.g. using RTP". Another example is "connecting two AVB/TSN LANs
("islands") together through a standard router". ("islands") together through a standard router".
11.1.5. Guaranteed End-to-End Delivery 11.1.5. Consideration for IPv4
This Use Cases draft explicitly does not specify any particular
implementation or protocol, however it has been observed that various
of the use cases described (and their associated industries) are
explicitly based on IPv4 (as opposed to IPv6) and it is not
considered practical to expect them to migrate to IPv6 in order to
use DetNet. Thus 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) are expected to be available.
11.1.6. Guaranteed End-to-End Delivery
Packets sent over DetNet are guaranteed not to be dropped by the Packets sent over DetNet are guaranteed not to be dropped by the
network due to congestion. (Packets may however be dropped for network due to congestion. (Packets may however be dropped for
intended reasons, e.g. per security measures). intended reasons, e.g. per security measures).
11.1.6. Replacement for Multiple Proprietary Deterministic Networks 11.1.7. Replacement for Multiple Proprietary Deterministic Networks
There are many proprietary non-interoperable deterministic Ethernet- There are many proprietary non-interoperable deterministic Ethernet-
based networks currently available; DetNet is intended to provide an based networks currently available; DetNet is intended to provide an
open-standards-based alternative to such networks. open-standards-based alternative to such networks.
11.1.7. Mix of Deterministic and Best-Effort Traffic 11.1.8. Mix of Deterministic and Best-Effort Traffic
DetNet is intended to support coexistance of time-sensitive DetNet is intended to support coexistance of time-sensitive
operational (OT) traffic and information (IT) traffic on the same operational (OT) traffic and information (IT) traffic on the same
("unified") network. ("unified") network.
11.1.8. Unused Reserved BW to be Available to Best Effort Traffic 11.1.9. Unused Reserved BW to be Available to Best Effort Traffic
If bandwidth reservations are made for a stream but the associated If bandwidth reservations are made for a stream but the associated
bandwidth is not used at any point in time, that bandwidth is made 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 available on the network for best-effort traffic. If the owner of
the reserved stream then starts transmitting again, the bandwidth is the reserved stream then starts transmitting again, the bandwidth is
no longer available for best-effort traffic, on a moment-to-moment no longer available for best-effort traffic, on a moment-to-moment
basis. Note that such "temporarily available" bandwidth is not basis. Note that such "temporarily available" bandwidth is not
available for time-sensitive traffic, which must have its own available for time-sensitive traffic, which must have its own
reservation. reservation.
11.1.9. Lower Cost, Multi-Vendor Solutions 11.1.10. Lower Cost, Multi-Vendor Solutions
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each promoting device diversity and potentially higher numbers of each
device manufactured, promoting cost reduction and cost competition device manufactured, promoting cost reduction and cost competition
among vendors. The intent is that DetNet networks should be able to among vendors. The intent is that DetNet networks should be able to
be created at lower cost and with greater diversity of available be created at lower cost and with greater diversity of available
devices than existing proprietary networks. devices than existing proprietary networks.
11.2. Scalable Size 11.2. Scalable Size
skipping to change at page 75, line 38 skipping to change at page 76, line 42
phone +1 514 840 3000, email raymond.jean@hydro.qc.ca phone +1 514 840 3000, email raymond.jean@hydro.qc.ca
Jouni Korhonen (Broadcom Corporation) Jouni Korhonen (Broadcom Corporation)
3151 Zanker Road, San Jose, 95134, CA, USA 3151 Zanker Road, San Jose, 95134, CA, USA
email jouni.nospam@gmail.com email jouni.nospam@gmail.com
Yu Kaneko (Toshiba) Yu Kaneko (Toshiba)
1 Komukai-Toshiba-cho, Saiwai-ku, Kasasaki-shi, Kanagawa, Japan 1 Komukai-Toshiba-cho, Saiwai-ku, Kasasaki-shi, Kanagawa, Japan
email yu1.kaneko@toshiba.co.jp email yu1.kaneko@toshiba.co.jp
Subir Das (Applied Communication Sciences) Subir Das (Vencore Labs)
150 Mount Airy Road, Basking Ridge, New Jersey, 07920, USA 150 Mount Airy Road, Basking Ridge, New Jersey, 07920, USA
email sdas@appcomsci.com email sdas@appcomsci.com
Yiyong Zha (Huawei Technologies) Yiyong Zha (Huawei Technologies)
email email
Balazs Varga (Ericsson) Balazs Varga (Ericsson)
Konyves Kalman krt. 11/B, Budapest, Hungary, 1097 Konyves Kalman krt. 11/B, Budapest, Hungary, 1097
email balazs.a.varga@ericsson.com email balazs.a.varga@ericsson.com
Janos Farkas (Ericsson) Janos Farkas (Ericsson)
Konyves Kalman krt. 11/B, Budapest, Hungary, 1097 Konyves Kalman krt. 11/B, Budapest, Hungary, 1097
email janos.farkas@ericsson.com email janos.farkas@ericsson.com
Franz-Josef Goetz (Siemens) Franz-Josef Goetz (Siemens)
Gleiwitzerstr. 555, Nurnberg, Germany, 90475 Gleiwitzerstr. 555, Nurnberg, Germany, 90475
email franz-josef.goetz@siemens.com email franz-josef.goetz@siemens.com
Juergen Schmitt (Siemens) Juergen Schmitt (Siemens)
Gleiwitzerstr. 555, Nurnberg, Germany, 90475 Gleiwitzerstr. 555, Nurnberg, Germany, 90475
email juergen.jues.schmitt@siemens.com email juergen.jues.schmitt@siemens.com
Xavier Vilajosana (Worldsensing) Xavier Vilajosana (Worldsensing)
483 Arago, Barcelona, Catalonia, 08013, Spain 483 Arago, Barcelona, Catalonia, 08013, Spain
skipping to change at page 79, line 36 skipping to change at page 80, line 39
[DCI] Digital Cinema Initiatives, LLC, "DCI Specification, [DCI] Digital Cinema Initiatives, LLC, "DCI Specification,
Version 1.2", 2012, <http://www.dcimovies.com/>. Version 1.2", 2012, <http://www.dcimovies.com/>.
[DICE] IETF, "DTLS In Constrained Environments", [DICE] IETF, "DTLS In Constrained Environments",
<https://datatracker.ietf.org/doc/charter-ietf-dice/>. <https://datatracker.ietf.org/doc/charter-ietf-dice/>.
[EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing [EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing
the Boundaries of Minds and Machines", November 2012. the Boundaries of Minds and Machines", November 2012.
[eCPRI] IEEE Standards Association, "Common Public Radio
Interface, "Common Public Radio Interface: eCPRI Interface
Specification V1.0", 2017, <http://www.cpri.info/>.
[ESPN_DC2] [ESPN_DC2]
Daley, D., "ESPN's DC2 Scales AVB Large", 2014, Daley, D., "ESPN's DC2 Scales AVB Large", 2014,
<http://sportsvideo.org/main/blog/2014/06/ <http://sportsvideo.org/main/blog/2014/06/
espns-dc2-scales-avb-large>. espns-dc2-scales-avb-large>.
[flnet] Japan Electrical Manufacturers Association, "JEMA 1479 - [flnet] Japan Electrical Manufacturers Association, "JEMA 1479 -
English Edition", September 2012. English Edition", September 2012.
[Fronthaul] [Fronthaul]
Chen, D. and T. Mustala, "Ethernet Fronthaul Chen, D. and T. Mustala, "Ethernet Fronthaul
skipping to change at page 80, line 32 skipping to change at page 81, line 42
of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), November 2017. in progress), November 2017.
[I-D.ietf-6tisch-coap] [I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-03 (work Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
in progress), March 2015. in progress), March 2015.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
802.15.4e", draft-ietf-6tisch-terminology-09 (work in draft-ietf-6tisch-terminology-10 (work in progress), March
progress), June 2017. 2018.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.ietf-mpls-residence-time] [I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Vainshtein, "Residence Time Measurement in MPLS and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-15 (work in network", draft-ietf-mpls-residence-time-15 (work in
skipping to change at page 82, line 24 skipping to change at page 83, line 35
Electric Power Substation Automation", IEEE Standard Electric Power Substation Automation", IEEE Standard
1646-2004 , Apr 2004. 1646-2004 , Apr 2004.
[IEEE1722] [IEEE1722]
IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport
Protocol for Time Sensitive Applications in a Bridged Protocol for Time Sensitive Applications in a Bridged
Local Area Network", IEEE Std 1722-2011, 2011, Local Area Network", IEEE Std 1722-2011, 2011,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/1722-2011.html>. standard/1722-2011.html>.
[IEEE19043] [IEEE19143]
IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3, IEEE Standards Association, "P1914.3/D3.1 Draft Standard
2015, <http://www.ieee1904.org/3/tf3_home.shtml>. for Radio over Ethernet Encapsulations and Mappings",
IEEE 1914.3, 2018,
<https://standards.ieee.org/develop/project/1914.3.html>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networks Task Group", March 2013, Networks Task Group", March 2013,
<http://www.ieee802.org/1/pages/avbridges.html>. <http://www.ieee802.org/1/pages/avbridges.html>.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
skipping to change at page 84, line 5 skipping to change at page 85, line 16
[lontalk] ECHELON, "LonTalk(R) Protocol Specification Version 3.0", [lontalk] ECHELON, "LonTalk(R) Protocol Specification Version 3.0",
1994. 1994.
[LTE-Latency] [LTE-Latency]
Johnston, S., "LTE Latency: How does it compare to other Johnston, S., "LTE Latency: How does it compare to other
technologies", March 2014, technologies", March 2014,
<http://opensignal.com/blog/2014/03/10/ <http://opensignal.com/blog/2014/03/10/
lte-latency-how-does-it-compare-to-other-technologies>. lte-latency-how-does-it-compare-to-other-technologies>.
[MEF] MEF, "Mobile Backhaul Phase 2 Amendment 1 -- Small Cells", [MEF22.1.1]
MEF, "Mobile Backhaul Phase 2 Amendment 1 -- Small Cells",
MEF 22.1.1, July 2014, MEF 22.1.1, July 2014,
<http://www.mef.net/Assets/Technical_Specifications/PDF/ <http://www.mef.net/Assets/Technical_Specifications/PDF/
MEF_22.1.1.pdf>. MEF_22.1.1.pdf>.
[MEF8] MEF, "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 [METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and
wireless system", ICT-317669-METIS/D1.1 ICT- wireless system", ICT-317669-METIS/D1.1 ICT-
317669-METIS/D1.1, April 2013, <https://www.metis2020.com/ 317669-METIS/D1.1, April 2013, <https://www.metis2020.com/
wp-content/uploads/deliverables/METIS_D1.1_v1.pdf>. wp-content/uploads/deliverables/METIS_D1.1_v1.pdf>.
[modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL [modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL
SPECIFICATION V1.1b", December 2006. SPECIFICATION V1.1b", December 2006.
[MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol [MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol
Specification", Apr 2012. Specification", Apr 2012.
skipping to change at page 87, line 39 skipping to change at page 89, line 5
<http://www.ieee802.org/1/files/public/docs2047/ <http://www.ieee802.org/1/files/public/docs2047/
avb-mace-ip-networked-studio-infrastructure-0107.pdf>. avb-mace-ip-networked-studio-infrastructure-0107.pdf>.
[SyncE] ITU-T, "G.8261 : Timing and synchronization aspects in [SyncE] ITU-T, "G.8261 : Timing and synchronization aspects in
packet networks", Recommendation G.8261, August 2013, packet networks", Recommendation G.8261, August 2013,
<http://www.itu.int/rec/T-REC-G.8261>. <http://www.itu.int/rec/T-REC-G.8261>.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling", [TEAS] IETF, "Traffic Engineering Architecture and Signaling",
<https://datatracker.ietf.org/doc/charter-ietf-teas/>. <https://datatracker.ietf.org/doc/charter-ietf-teas/>.
[TR38801] IEEE Standards Association, "3GPP TR 38.801, Technical
Specification Group Radio Access Network; Study on new
radio access technology: Radio access architecture and
interfaces (Release 14)", 2017,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3056>.
[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements [TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[TS25104] 3GPP, "Base Station (BS) radio transmission and reception [TS25104] 3GPP, "Base Station (BS) radio transmission and reception
(FDD)", 3GPP TS 25.104 3.14.0, March 2007. (FDD)", 3GPP TS 25.104 3.14.0, March 2007.
[TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access [TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Base Station (BS) radio transmission and (E-UTRA); Base Station (BS) radio transmission and
reception", 3GPP TS 36.104 10.11.0, July 2013. reception", 3GPP TS 36.104 10.11.0, July 2013.
 End of changes. 47 change blocks. 
148 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/