< draft-liu-detnet-dynamic-latency-guarantee-00.txt   draft-liu-detnet-dynamic-latency-guarantee-01.txt >
Deterministic Networking Working Group P. Liu Deterministic Networking Working Group P. Liu
Internet-Draft L. Geng Internet-Draft L. Geng
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: September 11, 2019 March 10, 2019 Expires: January 9, 2020 July 08, 2019
Dynamic Latency Guarantee Dynamic Latency Guarantee
draft-liu-detnet-dynamic-latency-guarantee-00 draft-liu-detnet-dynamic-latency-guarantee-01
Abstract Abstract
Aiming at the deterministic demand for network latency in future Aiming at the deterministic demand for network latency in future
vertical industry applications, this document analyzes the existing vertical industry applications, this document analyzes the existing
latency control methods for data transmission, points out the latency control methods for data transmission, points out the
possible shortcomings, and proposes some directions for optimizing possible shortcomings, and proposes some directions for optimizing
the latency control method. . the latency control method. .
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 11, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Core Technology of Bounded Latency . . . . . . . . . . . . . 3 2. Technologies of Latency Control . . . . . . . . . . . . . . . 2
2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for 2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for
Time-Sensitive Streams . . . . . . . . . . . . . . . . . 3 Time-Sensitive Streams . . . . . . . . . . . . . . . . . 3
2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic . . . . 3 2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic . . . . 3
2.3. IEEE 802.1Qbu Frame Preemption . . . . . . . . . . . . . 3 2.3. IEEE 802.1Qbu Frame Preemption . . . . . . . . . . . . . 3
3. Problems and Requirments . . . . . . . . . . . . . . . . . . 4 3. Problems and Requirments . . . . . . . . . . . . . . . . . . 3
3.1. Problems . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Problems in Bounded Latency . . . . . . . . . . . . . . . 4
3.2. Requirments . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Requirments of Deterministic latency . . . . . . . . . . 4
4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Dynamic Latency Guarantee . . . . . . . . . . . . . . . . 6 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Feedback System . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
With the vigorous development of 5G and industrial Internet, network New types of services such as AR/VR, V2X, industrial motion control,
technology has become more and more important to support new types of etc. have stringent requirements for latency and stability. In order
services, such as AR/VR, V2X, industrial motion control, etc., which to meet those requirements, some network technologies such as time-
have stringent requirements for latency and stability. In order to sensitive network, deterministic network, etc., have proposed
meet the requirements of the above applications, new network corresponding technical means to provide network bearers with
technologies such as time-sensitive network TSN, deterministic deterministic latency and packet loss rate to guarantee the service
network DETNET, etc., have proposed corresponding technical means to experience. TSN includes a set of standards developed by the IEEE
provide network bearers with deterministic latency and packet loss 802.1 Working Group's. Deterministic network (DETNET) is based on
rate and guarantee the user's business experience. the mechanism of TSN and committed to applying the method to the IP
layer to provide more reliable and stable network transmission. This
TSN includes a set of standards developed by the IEEE 802.1 Working document will present some problems when applying TSN in DETNET, and
Group's. The TSN task group inherited from the previous Audio/Video try to propose reference methods to solve the corresponding problems.
Bridging working group and has expanded its applications to in-
vehicle, industrial, and mobile networks. Deterministic network
(DETNET) is based on the mechanism of TSN. The difference is that
TSN is applied to the data link layer and below. DETNET is committed
to applying the method to the IP layer to provide more reliable and
stable network transmission.
This document will present some problems when applying TSN in DETNET,
and try to propose reference methods to solve the corresponding
problems.
2. Core Technology of Bounded Latency 2. Technologies of Latency Control
Based on time synchronization, TSN has a range of bounded latency Based on time synchronization, TSN has a range of bounded latency
technologies. technologies.
2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for Time- 2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-
Sensitive Streams Sensitive Streams
IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive IEEE 802.1Qav inherited from the AVB, including priority mapping
Streams inherited from the AVB, including priority mapping algorithms algorithms and Credit-based Traffic Shaping algorithms. The priority
and Credit-based Traffic Shaping algorithms. The priority mapping mapping algorithms is to mapping the priority to 'traffic class',
algorithms is to mapping the priority to 'traffic class', which which represents whether the stream is time sensitive or not.
represents whether the stream is time sensitive or not. Credit-based Credit-based Traffic Shaping algorithms provide the method to
Traffic Shaping algorithms provide the method to allocate bandwidth allocate bandwidth of different streams.
of different streams.
2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic 2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic
In IEEE 802.1Qbv, the gate control list is created according to the In IEEE 802.1Qbv, the gate control list is created according to the
actual stream and timescale. It contains the transmission sequence actual stream and timescale. It contains the transmission sequence
of all streams, and controls whether the data stream of each priority of all streams, and controls whether the data stream of each priority
is sent at the current time or not. All streams will be transmitted is sent at the current time or not. All streams will be transmitted
strictly according to the current list. More Than This, IEEE strictly according to the current list. More Than This, IEEE
802.1Qbv also defines the guard band mechanism and spares part of the 802.1Qbv also defines the guard band mechanism and spares part of the
time to guarantee the transmission of high priority data frames at time to guarantee the transmission of high priority data frames at
skipping to change at page 4, line 19 skipping to change at page 4, line 7
There are several standards refers to bounded latency. Users can There are several standards refers to bounded latency. Users can
decide whether to use a specific standard or not, which depends on decide whether to use a specific standard or not, which depends on
the requirments of network and business. Some TSN testbeds have been the requirments of network and business. Some TSN testbeds have been
established these years whose basic concept is realizing 802.1Qbv to established these years whose basic concept is realizing 802.1Qbv to
ensure the deterministic transmission of time sensitive stream. ensure the deterministic transmission of time sensitive stream.
Though it realized ignoring the interfere of background stream, the Though it realized ignoring the interfere of background stream, the
testbed was too simple. In fact, networking is complicated. There testbed was too simple. In fact, networking is complicated. There
will be more than two kind of streams being transmitted. So it is will be more than two kind of streams being transmitted. So it is
not that easily to apply those mechanisms on real networks. not that easily to apply those mechanisms on real networks.
3.1. Problems 3.1. Problems in Bounded Latency
Because of the complicated of real networks, there may be some Because of the complicated of real networks, there may be some
situations that the preemptable data frame transmission delay is too situations that the preemptable data frame transmission delay is too
large or cannot be transmitted. Thoes might occur when both large or cannot be transmitted. Thoes might occur when both
Enhancements for Scheduled Traffic and Frame Preemption are enabled. Enhancements for Scheduled Traffic and Frame Preemption are enabled.
Except for the highest priority, the others may be preempted by the Except for the highest priority, the others may be preempted by the
time slice to wait for transmission. In the actual scenario, the time slice to wait for transmission. In the actual scenario, the
preemptable data frame is not necessarily a completely non-time preemptable data frame is not necessarily a completely non-time
sensitive frame, so it also need to guarantee the transmission of sensitive frame, so it also need to guarantee the transmission of
some preemptable frame. However, Under the current mechanism, there some preemptable frame. However, Under the current mechanism, there
may be multiple preemption to cause a very large transmission delay may be multiple preemption to cause a very large transmission delay
or no transmission of preemptable frame, depending on the size of the or no transmission of preemptable frame, depending on the size of the
express frame and the period of the timescale. In an actual express frame and the period of the timescale. In an actual
scenario, a data frame with a Secondary high priority may also be a scenario, a data frame with a Secondary high priority may also be a
time-sensitive. If it cannot be transmitted or the transmission time-sensitive. If it cannot be transmitted or the transmission
delay is large, the service cannot be operated. delay is large, the service cannot be operated.
For example, there are currently two queues are transmited following 3.2. Requirments of Deterministic latency
the gate control list which assuming is the following table. In the
table, T00, T01, T02... represent the order of each time slice and
switching. The "01" and "10" in the right represent whether the two
queue can be transmitted in the current period. Assuming that 0
indicates that the gate is closed and the corresponding queue cannot
be transmitted. while 1 indicates the gate is open and corresponding
queue can be transferred. Then the following two cases may occur:
+-----------------------+
| Gate Control List |
+-----------------------+
| T00 | 01 |
+-----------------------+
| T01 | 10 |
+-----------------------+
| T02 | 01 |
+-----------------------+
| T03 | 10 |
+-----------------------+
| T.. | .. |
+-----------------------+
Gate Control List
Case 1, The preemptable frame is interrupted many times before the
transmission is completed, which causes a high transmission delay of
the preemptable frame.
Case 2, the preemptable frame cannot be transmitted after once being
interrupted.
+-------------+---------+-------------+---------+---+-------------+
| Part 1 of | Express | Part 2 of | Express | | Part n of |
| Preemptable | | Preemptable | |...| Preemptable |
| Frame | Frame A | Frame | Frame B | | Frame |
+-------------+---------+-------------+---------+---+-------------+
Case 1 of Preemption
+-------------+---------+---------+----------+-----+----------+
| Part 1 of | Express | Express | Express | | Express |
| Preemptable | | | | ... | |
| Frame | Frame A | Frame B | Frame C | | Frame N |
+-------------+---------+---------+----------+-----+----------+
Case 2 of Preemption
3.2. Requirments
Deterministic network includes deterministic latency and Deterministic network includes deterministic latency and
deterministic packet loss. We need to think how to apply the bounded deterministic packet loss. We need to think how to apply the bounded
latency mechanism effectively. latency mechanism effectively. Before using the bounded latency
mechanism, network manager needs to know enough about the network and
Before using the bounded latency mechanism, network manager needs to applications. For example, which kind of stream is time sensitive?
know enough about the network and applications. For example, which How about the frame's transceiver frequency of thoes stream? How
kind of stream is time sensitive? How about the frame's transceiver much bandwidth does it need? ... When you have a clear understanding
frequency of thoes stream? How much bandwidth does it need? ... When of the real-time state of the network, you can configure a delay-
you have a clear understanding of the real-time state of the network, limited algorithm for the network.
you can configure a delay-limited algorithm for the network.
However, the transmission state of the network is not invariable. However, the transmission state of the network is not invariable.
Some transfer table might make corresponding adjustments according to Some transfer table might make corresponding adjustments according to
the current network situation. So the parameters that have been the current network situation. So the parameters that have been
configured before should also be changed. More than this, the configured before should also be changed. More than this, the
bounded latency mechanism also need a feedback system to receive bounded latency mechanism also need a feedback system to receive
current network status and adjust/reconfigure the network. current network status and adjust/reconfigure the network.
4. Solutions 4. Solutions
The implementation of the mechanism to guarantee latency requires The implementation of the mechanism to guarantee latency requires
sophisticated calculation, including timescale and gate control tist sophisticated calculation, including timescale and gate control tist
. When the stream in the network becomes diverse, it will consume a . When the stream in the network becomes diverse, it will consume a
lot of computing resources to schedule each stream. Therefore, a lot of computing resources to schedule each stream. Therefore, a
single transmission rule may not be able to meet the problem of single transmission rule may not be able to meet the problem of
multiple streams' transmission. Worst of all, the gate control list multiple streams' transmission. Worst of all, the gate control list
is not properly calculated, the network may not transmit or failure. is not properly calculated, the network may not transmit or failure.
4.1. Dynamic Latency Guarantee
Dynamic latency guarantee is a way of thinking based on the latency Dynamic latency guarantee is a way of thinking based on the latency
guarantee of the whole network. that is, to dynamically adjust the guarantee of the whole network. that is, to dynamically adjust the
priority through the current network condition and the transmission priority through the current network condition and the transmission
of data stream. of data stream, and a feedback system is needed to optimize the
system. One of the reasons for this situation is that the prediction
In the transmission process, the priority of data is based on the or mastery of the transmission of frames in the network is not
"Traffic Class" in IEEE802.1 Qav. that is, the priority of data accurate, so a feedback system is needed to tell the network to
frames is converted into traffic class according to the mapping centrally configure the system. So it could help to optimize the
table. If the data frame is preempted once, the corresponding gate control list to avoid the frequent occurring of this problems.
traffic class is increased according to certain functional rules. The most basic case is that once there are multiple preemption
occured, the switch need to report it to the Centralized
Functional rules can be defined as needed, for example, by assuming: Configuration System. It represent that there might be some
unjustified configurations need to be reconfiguration. For example,
T = Time of preempted distribute more bandwidth to the corresponding traffic class.
M = Lifting coefficient
and F(tm)=Increased traffic class
That is to say, with the increase of preemption times, the
preemptable frames will gradually increase their priority (the
corresponding traffic class). When it is greater than or equal to
the Traffic Class of express frames, the preemptable frames could
complete the transmission.
The lifting factor M can be either a constant or a variable varying
with T, depending on the network requirements of specific business
application scenarios, which will not been discussed in detail in
this document.
4.2. Feedback System
One of the reasons for this situation is that the prediction or
mastery of the transmission of frames in the network is not accurate,
so a feedback system is needed to tell the network to centrally
configure the system. So it could help to optimize the gate control
list to avoid the frequent occurring of this problems. The most
basic case is that once there are multiple preemption occured, the
switch need to report it to the Centralized Configuration System. It
represent that there might be some unjustified configurations need to
be reconfiguration. For example, distribute more bandwidth to the
corresponding traffic class.
It should be noted that all devices in the network share the same It should be noted that all devices in the network share the same
gate control list. However, due to the difference in time of the gate control list. However, due to the difference in time of the
transmission path, it is necessary to keep all devices in the network transmission path, it is necessary to keep all devices in the network
"asynchronous" to execute the gate control list. For example, when "asynchronous" to execute the gate control list. For example, when
the data frame is received by the device A, it is queued to be the data frame is received by the device A, it is queued to be
transmited first in the currently divided time slice. When the frame transmited first in the currently divided time slice. When the frame
is received by the device B, the time t1 has elapsed. So the gate is received by the device B, the time t1 has elapsed. So the gate
control list of device B needs to perform the time difference of t1 control list of device B needs to perform the time difference of t1
with the A device, which can ensure that this frame arrives at every with the A device, which can ensure that this frame arrives at every
skipping to change at page 8, line 32 skipping to change at page 6, line 32
List List List List List List
Feedback System Feedback System
5. Conclusion 5. Conclusion
This draft described the existing mechanism of bounded latency and This draft described the existing mechanism of bounded latency and
point out some problems when using them. It also proposed some point out some problems when using them. It also proposed some
reference methods to solve them. In the process of network reference methods to solve them. In the process of network
evolution, there might also be more problems need to be noticed and evolution, there might also be more problems need to be noticed and
disscuss. disscuss. For example, it also needs to consider whether the bounded
latency mechanism of layer 2 can guarantee the deterministic
processing of whole stack. There may be that deterministic
forwarding mechanism is used in Layer 2, but due to the TCP/IP or
other protocol in higher layer, data packets can not be processed in
deterministic order in the queue, which leads to the uncertainty of
latency.
6. Security Considerations 6. Security Considerations
TBD. TBD.
7. IANA Considerations 7. IANA Considerations
TBD. TBD.
8. References 8. References
skipping to change at page 8, line 43 skipping to change at page 7, line 4
6. Security Considerations 6. Security Considerations
TBD. TBD.
7. IANA Considerations 7. IANA Considerations
TBD. TBD.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.finn-detnet-bounded-latency] [I-D.finn-detnet-bounded-latency]
Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga,
B., and J. Farkas, "DetNet Bounded Latency", draft-finn- B., and J. Farkas, "DetNet Bounded Latency", draft-finn-
detnet-bounded-latency-02 (work in progress), October detnet-bounded-latency-04 (work in progress), June 2019.
2018.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-11 (work in progress), February 2019. detnet-architecture-13 (work in progress), May 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[IEEE802.1Qav] [IEEE802.1Qav]
IEEE, "Forwarding and Queuing Enhancements for Time- IEEE, "Forwarding and Queuing Enhancements for Time-
 End of changes. 17 change blocks. 
151 lines changed or deleted 63 lines changed or added

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