--- 1/draft-ietf-detnet-use-cases-14.txt 2018-04-02 21:13:11.313231714 -0700
+++ 2/draft-ietf-detnet-use-cases-15.txt 2018-04-02 21:13:11.489235897 -0700
@@ -1,18 +1,18 @@
Internet Engineering Task Force E. Grossman, Ed.
Internet-Draft DOLBY
-Intended status: Informational February 23, 2018
-Expires: August 27, 2018
+Intended status: Informational April 2, 2018
+Expires: October 4, 2018
Deterministic Networking Use Cases
- draft-ietf-detnet-use-cases-14
+ draft-ietf-detnet-use-cases-15
Abstract
This draft documents requirements in several diverse industries to
establish multi-hop paths for characterized flows with deterministic
properties. In this context deterministic implies that streams can
be established which provide guaranteed bandwidth and latency which
can be established from either a Layer 2 or Layer 3 (IP) interface,
and which can co-exist on an IP network with best-effort traffic.
@@ -35,21 +35,21 @@
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on August 27, 2018.
+ This Internet-Draft will expire on October 4, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
@@ -137,98 +137,100 @@
6.1.1. Network Architecture . . . . . . . . . . . . . . . . 49
6.1.2. Delay Constraints . . . . . . . . . . . . . . . . . . 50
6.1.3. Time Synchronization Constraints . . . . . . . . . . 52
6.1.4. Transport Loss Constraints . . . . . . . . . . . . . 54
6.1.5. Security Considerations . . . . . . . . . . . . . . . 54
6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 55
6.2.1. Fronthaul . . . . . . . . . . . . . . . . . . . . . . 55
6.2.2. Midhaul and Backhaul . . . . . . . . . . . . . . . . 55
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 56
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 58
- 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 58
- 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 58
- 7.2. Industrial M2M Communication Today . . . . . . . . . . . 59
+ 7. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 59
+ 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 59
+ 7.2. Industrial M2M Communication Today . . . . . . . . . . . 60
7.2.1. Transport Parameters . . . . . . . . . . . . . . . . 60
7.2.2. Stream Creation and Destruction . . . . . . . . . . . 61
7.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 61
- 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 61
+ 7.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 62
8. Mining Industry . . . . . . . . . . . . . . . . . . . . . . . 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.4. Mining Industry Asks . . . . . . . . . . . . . . . . . . 64
9. Private Blockchain . . . . . . . . . . . . . . . . . . . . . 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.3. Security Considerations . . . . . . . . . . . . . . . 65
- 9.2. Private Blockchain Today . . . . . . . . . . . . . . . . 65
+ 9.1.3. Security Considerations . . . . . . . . . . . . . . . 66
+ 9.2. Private Blockchain Today . . . . . . . . . . . . . . . . 66
9.3. Private Blockchain Future . . . . . . . . . . . . . . . . 66
9.4. Private Blockchain Asks . . . . . . . . . . . . . . . . . 66
- 10. Network Slicing . . . . . . . . . . . . . . . . . . . . . . . 66
- 10.1. Use Case Description . . . . . . . . . . . . . . . . . . 66
- 10.2. Network Slicing Use Cases . . . . . . . . . . . . . . . 67
- 10.2.1. Enhanced Mobile Broadband (eMBB) . . . . . . . . . . 67
- 10.2.2. Ultra-Reliable and Low Latency Communications
- (URLLC) . . . . . . . . . . . . . . . . . . . . . . 67
- 10.2.3. massive Machine Type Communications (mMTC) . . . . . 67
- 10.3. Using DetNet in Network Slicing . . . . . . . . . . . . 67
- 10.4. Network Slicing Today and Future . . . . . . . . . . . . 68
- 10.5. Network Slicing Asks . . . . . . . . . . . . . . . . . . 68
- 11. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 68
- 11.1. Unified, standards-based network . . . . . . . . . . . . 68
- 11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 68
- 11.1.2. Centrally Administered . . . . . . . . . . . . . . . 68
- 11.1.3. Standardized Data Flow Information Models . . . . . 69
- 11.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . 69
- 11.1.5. Guaranteed End-to-End Delivery . . . . . . . . . . . 69
- 11.1.6. Replacement for Multiple Proprietary Deterministic
- Networks . . . . . . . . . . . . . . . . . . . . . . 69
- 11.1.7. Mix of Deterministic and Best-Effort Traffic . . . . 69
- 11.1.8. Unused Reserved BW to be Available to Best Effort
- Traffic . . . . . . . . . . . . . . . . . . . . . . 69
- 11.1.9. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 70
- 11.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . 70
- 11.3. Scalable Timing Parameters and Accuracy . . . . . . . . 70
- 11.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . 70
- 11.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . 70
- 11.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . 71
- 11.4. High Reliability and Availability . . . . . . . . . . . 71
- 11.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 71
- 11.6. Deterministic Flows . . . . . . . . . . . . . . . . . . 71
- 12. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 71
- 12.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 72
- 12.2. Internet-based Applications . . . . . . . . . . . . . . 72
- 12.2.1. Use Case Description . . . . . . . . . . . . . . . . 72
- 12.2.1.1. Media Content Delivery . . . . . . . . . . . . . 73
- 12.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . 73
- 12.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . 73
- 12.2.2. Internet-Based Applications Today . . . . . . . . . 73
- 12.2.3. Internet-Based Applications Future . . . . . . . . . 73
- 12.2.4. Internet-Based Applications Asks . . . . . . . . . . 73
- 12.3. Pro Audio and Video - Digital Rights Management (DRM) . 74
- 12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 74
- 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 75
- 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
- 14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 76
- 14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 77
- 14.3. Building Automation Systems . . . . . . . . . . . . . . 77
- 14.4. Wireless for Industrial . . . . . . . . . . . . . . . . 77
- 14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 77
- 14.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 77
- 14.7. Internet Applications and CoMP . . . . . . . . . . . . . 78
- 14.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 78
- 14.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 78
- 14.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 78
- 14.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 78
- 15. Informative References . . . . . . . . . . . . . . . . . . . 78
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 88
+ 10. Network Slicing . . . . . . . . . . . . . . . . . . . . . . . 67
+ 10.1. Use Case Description . . . . . . . . . . . . . . . . . . 67
+ 10.2. DetNet Applied to Network Slicing . . . . . . . . . . . 67
+ 10.2.1. Resource Isolation Across Slices . . . . . . . . . . 67
+ 10.2.2. Deterministic Services Within Slices . . . . . . . . 67
+ 10.3. A Network Slicing Use Case Example - 5G Bearer Network . 68
+ 10.4. Non-5G Applications of Network Slicing . . . . . . . . . 68
+ 10.5. Limitations of DetNet in Network Slicing . . . . . . . . 69
+ 10.6. Network Slicing Today and Future . . . . . . . . . . . . 69
+ 10.7. Network Slicing Asks . . . . . . . . . . . . . . . . . . 69
+ 11. Use Case Common Themes . . . . . . . . . . . . . . . . . . . 69
+ 11.1. Unified, standards-based network . . . . . . . . . . . . 69
+ 11.1.1. Extensions to Ethernet . . . . . . . . . . . . . . . 69
+ 11.1.2. Centrally Administered . . . . . . . . . . . . . . . 69
+ 11.1.3. Standardized Data Flow Information Models . . . . . 70
+ 11.1.4. L2 and L3 Integration . . . . . . . . . . . . . . . 70
+ 11.1.5. Consideration for IPv4 . . . . . . . . . . . . . . . 70
+ 11.1.6. Guaranteed End-to-End Delivery . . . . . . . . . . . 70
+ 11.1.7. Replacement for Multiple Proprietary Deterministic
+ Networks . . . . . . . . . . . . . . . . . . . . . . 70
+ 11.1.8. Mix of Deterministic and Best-Effort Traffic . . . . 71
+ 11.1.9. Unused Reserved BW to be Available to Best Effort
+ Traffic . . . . . . . . . . . . . . . . . . . . . . 71
+ 11.1.10. Lower Cost, Multi-Vendor Solutions . . . . . . . . . 71
+
+ 11.2. Scalable Size . . . . . . . . . . . . . . . . . . . . . 71
+ 11.3. Scalable Timing Parameters and Accuracy . . . . . . . . 71
+ 11.3.1. Bounded Latency . . . . . . . . . . . . . . . . . . 71
+ 11.3.2. Low Latency . . . . . . . . . . . . . . . . . . . . 72
+ 11.3.3. Symmetrical Path Delays . . . . . . . . . . . . . . 72
+ 11.4. High Reliability and Availability . . . . . . . . . . . 72
+ 11.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 72
+ 11.6. Deterministic Flows . . . . . . . . . . . . . . . . . . 73
+ 12. Use Cases Explicitly Out of Scope for DetNet . . . . . . . . 73
+ 12.1. DetNet Scope Limitations . . . . . . . . . . . . . . . . 73
+ 12.2. Internet-based Applications . . . . . . . . . . . . . . 74
+ 12.2.1. Use Case Description . . . . . . . . . . . . . . . . 74
+ 12.2.1.1. Media Content Delivery . . . . . . . . . . . . . 74
+ 12.2.1.2. Online Gaming . . . . . . . . . . . . . . . . . 74
+ 12.2.1.3. Virtual Reality . . . . . . . . . . . . . . . . 74
+ 12.2.2. Internet-Based Applications Today . . . . . . . . . 74
+ 12.2.3. Internet-Based Applications Future . . . . . . . . . 74
+ 12.2.4. Internet-Based Applications Asks . . . . . . . . . . 75
+ 12.3. Pro Audio and Video - Digital Rights Management (DRM) . 75
+ 12.4. Pro Audio and Video - Link Aggregation . . . . . . . . . 75
+ 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76
+ 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
+ 14.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 77
+ 14.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 78
+ 14.3. Building Automation Systems . . . . . . . . . . . . . . 78
+ 14.4. Wireless for Industrial . . . . . . . . . . . . . . . . 78
+ 14.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 78
+ 14.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 79
+ 14.7. Internet Applications and CoMP . . . . . . . . . . . . . 79
+ 14.8. Electrical Utilities . . . . . . . . . . . . . . . . . . 79
+ 14.9. Network Slicing . . . . . . . . . . . . . . . . . . . . 79
+ 14.10. Mining . . . . . . . . . . . . . . . . . . . . . . . . . 79
+ 14.11. Private Blockchain . . . . . . . . . . . . . . . . . . . 79
+ 15. Informative References . . . . . . . . . . . . . . . . . . . 79
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction
This draft presents use cases from diverse industries which have in
common a need for deterministic streams, but which also differ
notably in their network topologies and specific desired behavior.
Together, they provide broad industry context for DetNet and a
yardstick against which proposed DetNet designs can be measured (to
what extent does a proposed design satisfy these various use cases?)
@@ -2270,21 +2273,21 @@
transmission operations by properly assigning the network resources,
thus leaving more of the transport time budget available for link
propagation, and thus enabling longer link lengths. However, link
length is usually a given parameter and is not a controllable network
parameter, since RRH and BBU sights are usually located in
predetermined locations. However, the number of antennas in an RRH
sight might increase for example by adding more antennas, increasing
the MIMO capability of the network or support of massive MIMO. This
means increasing the number of the fronthaul flows sharing the same
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
the packet loss rate.
Another way in which DetNet technology can aid Fronthaul networks is
by providing effective isolation from best-effort (and other classes
of) traffic, which can arise as a result of network slicing in 5G
networks where Fronthaul traffic generated in different network
slices might have differing performance requirements. DetNet
technology can also dynamically control the bandwidth assignment,
scheduling and packet forwarding decisions and the buffer
@@ -2482,23 +2485,23 @@
for legacy transport support) have become popular tools to build and
manage new all-IP Radio Access Networks (RANs)
[I-D.kh-spring-ip-ran-use-case]. Although various timing and
synchronization optimizations have already been proposed and
implemented including 1588 PTP enhancements
[I-D.ietf-tictoc-1588overmpls] and [I-D.ietf-mpls-residence-time],
these solution are not necessarily sufficient for the forthcoming RAN
architectures nor do they guarantee the more stringent time-
synchronization requirements such as [CPRI].
- There are also existing solutions for TDM over IP such as [RFC5087]
- and [RFC4553], as well as TDM over Ethernet transports such as
- [RFC5086].
+ There are also existing solutions for TDM over IP such as [RFC4553],
+ [RFC5086], and [RFC5087], as well as TDM over Ethernet transports
+ such as [MEF8].
6.3. Cellular Radio Networks Future
Future Cellular Radio Networks will be based on a mix of different
xHaul networks (xHaul = front-, mid- and backhaul), and future
transport networks should be able to support all of them
simultaneously. It is already envisioned today that:
o Not all "cellular radio network" traffic will be IP, for example
some will remain at Layer 2 (e.g. Ethernet based). DetNet
@@ -2520,21 +2523,21 @@
networking equipment that can make use of underlying deterministic
link-layer services
o Unified and standards-based network management systems and
protocols in all parts of the network (including Fronthaul)
New radio access network deployment models and architectures may
require time- sensitive networking 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 [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
Fronthaul networks the timing and synchronization requirements can be
extreme for packet based technologies, for example, on the order of
sub +-20 ns packet delay variation (PDV) and frequency accuracy of
+0.002 PPM [Fronthaul].
The actual transport protocols and/or solutions to establish required
transport "circuits" (pinned-down paths) for Fronthaul traffic are
still undefined. Those are likely to include (but are not limited
to) solutions directly over Ethernet, over IP, and using MPLS/
@@ -2549,23 +2552,41 @@
done for Ethernet [TSNTG], which specifies the use of IEEE 1588 time
precision protocol (PTP) [IEEE1588] in the context of IEEE 802.1D and
IEEE 802.1Q. [IEEE8021AS] specifies a Layer 2 time synchronizing
service, and other specifications such as IEEE 1722 [IEEE1722]
specify Ethernet-based Layer-2 transport for time-sensitive streams.
New promising work seeks to enable the transport of time-sensitive
fronthaul streams in Ethernet bridged networks [IEEE8021CM].
Analogous to IEEE 1722 there is an ongoing standardization effort to
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
Ethernet appears to be the unifying technology for the transport,
there is still a disconnect providing Layer 3 services. The protocol
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
on top of the lowest layer (optical) transport there is the first
layer of Ethernet followed one or more layers of MPLS, PseudoWires
and/or other tunneling protocols finally carrying the Ethernet layer
visible to the user plane IP traffic.
@@ -2989,106 +3010,132 @@
o Coexistence in a single network of blockchain and IT traffic.
o 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
+ Network Slicing divides one physical network infrastructure into
multiple logical networks. Each slice, corresponding to a logical
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.
Future services will demand network performance with a wide variety
of characteristics such as high data rate, low latency, low loss
rate, security and many other parameters. Ideally every service
would have its own physical network satisfying its particular
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
network. This method can optimize the performance for the service at
lower cost, and the flexibility of setting up and release the slices
also allows the user to allocate the network resources dynamically.
- Unlike other DetNet use cases, Network slicing is not a specific
- application with specific deterministic requirements; it is proposed
- as a new requirement for the future network, which is still in
- discussion, and DetNet is a candidate solution for it.
+ Unlike the other use cases presented here, Network Slicing is not a
+ specific application that depends on specific deterministic
+ properties; rather it is introduced as an area of networking to which
+ 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
- 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.
+10.2.1. Resource Isolation Across Slices
- A 5G bearer network is a typical use case of network slicing,
- including 3 service scenarios: enhanced Mobile Broadband (eMBB),
- Ultra-Reliable and Low Latency Communications (URLLC), and massive
- Machine Type Communications (mMTC). Each of these are described
- below.
+ One of the requirements discussed for Network Slicing is the "hard"
+ separation of various users' deterministic performance. That is, 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, 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
- high definition (HD) videos, virtual reality (VR), augmented reality
- (AR), and fixed mobile convergence (FMC).
+ Slices may need to provide services with DetNet-type performance
+ guarantees, however we note 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, 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
- vehicles, remote surgery, or drone control.
+ Network Slicing is a core feature of 5G defined in 3GPP, which is
+ 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
- density, such as those typical for smart city and smart agriculture
- use cases.
+ o URLLC (Ultra-Reliable and Low Latency Communications) focuses on
+ latency-sensitive services, such as self-driving vehicles, remote
+ 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"
- separation of various users' deterministic performance. That is, 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 users. Typical
- techniques used today, which share a physical network among users, do
- not offer this kind of insulation. 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.
+ A 5G bearer network could use DetNet to provide hard resource
+ isolation across slices and within the slice. For example consider
+ Slice-A and Slice-B, with DetNet used to transit services URLLC-A and
+ URLLC-B over them. Without DetNet, URLLC-A and URLLC-B would compete
+ for bandwidth resource, and latency and reliability would not be
+ guaranteed. With DetNet, URLLC-A and URLLC-B have separate bandwidth
+ reservation and there is no resource conflict between them, as though
+ they were in different logical networks.
- Thus DetNet is a powerful tool when latency and reliability are
- 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. Non-5G Applications of Network Slicing
-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
- 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. Limitations of DetNet in Network Slicing
-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 Service Quality Customization and Guarantee
o Security
11. Use Case Common Themes
This section summarizes the expected properties of a DetNet network,
@@ -3123,50 +3170,62 @@
11.1.4. L2 and L3 Integration
A DetNet network is intended to integrate between Layer 2 (bridged)
network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g.
using IP-based protocols). One example of this is "making AVB/TSN-
type deterministic performance available from Layer 3 applications,
e.g. using RTP". Another example is "connecting two AVB/TSN LANs
("islands") together through a standard router".
-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
network due to congestion. (Packets may however be dropped for
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-
based networks currently available; DetNet is intended to provide an
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
operational (OT) traffic and information (IT) traffic on the same
("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
bandwidth is not used at any point in time, that bandwidth is made
available on the network for best-effort traffic. If the owner of
the reserved stream then starts transmitting again, the bandwidth is
no longer available for best-effort traffic, on a moment-to-moment
basis. Note that such "temporarily available" bandwidth is not
available for time-sensitive traffic, which must have its own
reservation.
-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
in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each
device manufactured, promoting cost reduction and cost competition
among vendors. The intent is that DetNet networks should be able to
be created at lower cost and with greater diversity of available
devices than existing proprietary networks.
11.2. Scalable Size
@@ -3414,34 +3473,34 @@
phone +1 514 840 3000, email raymond.jean@hydro.qc.ca
Jouni Korhonen (Broadcom Corporation)
3151 Zanker Road, San Jose, 95134, CA, USA
email jouni.nospam@gmail.com
Yu Kaneko (Toshiba)
1 Komukai-Toshiba-cho, Saiwai-ku, Kasasaki-shi, Kanagawa, Japan
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
email sdas@appcomsci.com
Yiyong Zha (Huawei Technologies)
email
Balazs Varga (Ericsson)
Konyves Kalman krt. 11/B, Budapest, Hungary, 1097
email balazs.a.varga@ericsson.com
-
Janos Farkas (Ericsson)
Konyves Kalman krt. 11/B, Budapest, Hungary, 1097
email janos.farkas@ericsson.com
+
Franz-Josef Goetz (Siemens)
Gleiwitzerstr. 555, Nurnberg, Germany, 90475
email franz-josef.goetz@siemens.com
Juergen Schmitt (Siemens)
Gleiwitzerstr. 555, Nurnberg, Germany, 90475
email juergen.jues.schmitt@siemens.com
Xavier Vilajosana (Worldsensing)
483 Arago, Barcelona, Catalonia, 08013, Spain
@@ -3599,20 +3659,24 @@
[DCI] Digital Cinema Initiatives, LLC, "DCI Specification,
Version 1.2", 2012, .
[DICE] IETF, "DTLS In Constrained Environments",
.
[EA12] Evans, P. and M. Annunziata, "Industrial Internet: Pushing
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, .
+
[ESPN_DC2]
Daley, D., "ESPN's DC2 Scales AVB Large", 2014,
.
[flnet] Japan Electrical Manufacturers Association, "JEMA 1479 -
English Edition", September 2012.
[Fronthaul]
Chen, D. and T. Mustala, "Ethernet Fronthaul
@@ -3644,23 +3708,23 @@
of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), November 2017.
[I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
in progress), March 2015.
[I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
- "Terminology in IPv6 over the TSCH mode of IEEE
- 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
- progress), June 2017.
+ "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
+ draft-ietf-6tisch-terminology-10 (work in progress), March
+ 2018.
[I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002.
[I-D.ietf-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-ietf-mpls-residence-time-15 (work in
@@ -3730,23 +3794,25 @@
Electric Power Substation Automation", IEEE Standard
1646-2004 , Apr 2004.
[IEEE1722]
IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport
Protocol for Time Sensitive Applications in a Bridged
Local Area Network", IEEE Std 1722-2011, 2011,
.
- [IEEE19043]
- IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3,
- 2015, .
+ [IEEE19143]
+ IEEE Standards Association, "P1914.3/D3.1 Draft Standard
+ for Radio over Ethernet Encapsulations and Mappings",
+ IEEE 1914.3, 2018,
+ .
[IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networks Task Group", March 2013,
.
[IEEE802154]
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
@@ -3804,25 +3870,32 @@
[lontalk] ECHELON, "LonTalk(R) Protocol Specification Version 3.0",
1994.
[LTE-Latency]
Johnston, S., "LTE Latency: How does it compare to other
technologies", March 2014,
.
- [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,
.
+ [MEF8] MEF, "Implementation Agreement for the Emulation of PDH
+ Circuits over Metro Ethernet Networks", MEF 8, October
+ 2004,
+ .
+
[METIS] METIS, "Scenarios, requirements and KPIs for 5G mobile and
wireless system", ICT-317669-METIS/D1.1 ICT-
317669-METIS/D1.1, April 2013, .
[modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL
SPECIFICATION V1.1b", December 2006.
[MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol
Specification", Apr 2012.
@@ -3974,20 +4047,27 @@
.
[SyncE] ITU-T, "G.8261 : Timing and synchronization aspects in
packet networks", Recommendation G.8261, August 2013,
.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling",
.
+ [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,
+ .
+
[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[TS25104] 3GPP, "Base Station (BS) radio transmission and reception
(FDD)", 3GPP TS 25.104 3.14.0, March 2007.
[TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Base Station (BS) radio transmission and
reception", 3GPP TS 36.104 10.11.0, July 2013.