Network Shaofu. Peng
Internet-Draft Bin. Tan
Intended status: Standards Track ZTE Corporation
Expires: January 9, 2023 Peng. Liu
China Mobile
July 8, 2022
Deadline Based Deterministic Forwarding
draft-peng-detnet-deadline-based-forwarding-02
Abstract
This document describes a deterministic forwarding mechanism based on
deadline. The mechanism enhances strict priority scheduling
algorithm with dynamically adjusting the priority of the queue
according to its deadline attribute.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 January 9, 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Peng, et al. Expires January 9, 2023 [Page 1]
Internet-Draft Deadline Routing July 2022
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Deadline Queue . . . . . . . . . . . . . . . . . . . . . . . 3
3. Get Deadline Information of Packets . . . . . . . . . . . . . 6
3.1. Get Planned Residence Time . . . . . . . . . . . . . . . 6
3.2. Get Existing Cumulative Planned Residence Time . . . . . 7
3.3. Get Existing Accumulated Actual Residence Time . . . . . 7
3.4. Get Existing Accumulated Residence Time Deviation . . . . 8
4. Put Packets into the Deadline Queues . . . . . . . . . . . . 8
5. Traffic Regulation and Shaping . . . . . . . . . . . . . . . 11
6. Compatibility Considerations . . . . . . . . . . . . . . . . 12
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
[RFC8655] describes the architecture of deterministic network and
defines the QoS goals of deterministic forwarding: Minimum and
maximum end-to-end latency from source to destination, timely
delivery, and bounded jitter (packet delay variation); packet loss
ratio under various assumptions as to the operational states of the
nodes and links; an upper bound on out-of-order packet delivery. In
order to achieve these goals, deterministic networks use resource
reservation, explicit routing, service protection and other means.
Resource reservation refers to the occupation of resources by service
traffic, exclusive or shared in a certain proportion, such as
dedicated physical link, link bandwidth, queue resources, etc;
Explicit routing means that the transmission path of traffic flow in
the network needs to be selected in advance to ensure the stability
of the route and does not change with the real-time change of network
topology, and based on this, the upper bound of end-to-end delay and
delay jitter can be accurately calculated; Service protection refers
to sending multiple service flows along multiple disjoint paths at
the same time to reduce the packet loss rate. In general, a
deterministic path is a strictly explicit path calculated by a
centralized controller, and resources are reserved on the nodes along
the path to meet the SLA requirements of deterministic services.
Peng, et al. Expires January 9, 2023 [Page 2]
Internet-Draft Deadline Routing July 2022
[I-D.stein-srtsn] describes that the controller calculates the local
deadline time of each node for the traffic to be transmitted in
advance, which is a absolute system time, forms a stack of these
local deadline time, and then carries them in the forwarded data
packets. Each node forwards the packets according to its own local
deadline. [I-D.stein-srtsn] suggests that FIFO queue can not be used
to realize this function, because the packets stored in the queue are
always first in first out, so a special data structure is recommoned.
The packets in this data structure will be automatically sorted with
the order from emergency to non emergency according to the deadline
of the packets. However, it may be difficult to implement this
structure in hardware, and especially for a large network it may be
challenge to synchronize time.
Considering that the link transmission delay is generally a fixed
value, and we focus on the residence time of the packets inside the
node, an alternate approach is to make the deadline eliminate the
interference of link delay and avoids relying on time synchronization
between nodes.
This document desrbies an alternate packets scheduling scheme that is
used for wide area network. It suggests to only use a single
deadline time to control the packets scheduling of all nodes along
the path. The single deadline time is an offset time, which is based
on the time when the packet enters the node and represents the
maximum time allowed for the packet to stay inside the node.
However, if each node has obvious differences in the capability of
packets forwarding and scheduling, more offset-time may be needed.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Deadline Queue
For nodes in the network, some queues with deadline time (also termed
as TTL) are introduced and maintained for each outgoing port. These
queues are called deadline queue and participate in priority based
scheduling. Deadline queue has the following characteristics:
o The TTL of each deadline queue will decrease with the passage of
time. When it decreases to 0, the scheduling priority of the
queue will be set to the highest, and the scheduling opportunity
will be obtained immediately (note that there may be interference
Peng, et al. Expires January 9, 2023 [Page 3]
Internet-Draft Deadline Routing July 2022
delay caused by a large packet being sent by a low priority
queue). It will prohibit receiving new packets, in which the
buffered packets will be sent to the outgoing port immediately,
and the maximum duration allowed to send packets is the preset
authorization time, e.g, 10us, 20us, etc. In principle, all
packets buffered in the queue shall be sent within this
authorization time. If the queue is sent to empty and the
authorization time is still free, other queues with lower priority
can be scheduled during this authorization time.
o The scheduling engine can initiate a cycle timer to decrement the
TTL of all deadline queues, that is, whenever the timer expires,
the deadline values of all queues will be subtracted from the
timer interval. Note that the time interval of the timer must be
less than or equal to the authorization time.
o For a deadline queue whose TTL has been reduced to 0, after a new
round of authorization time, the TTL will return to the maximum
initial value, allow receiving new packets, and continue to enter
the next round of operation that decreases with the passage of
time.
o For a deadline queue whose TTL is not reduced to 0, it can receive
packets. In detailed, when a node receives a packet to be
forwarded from a specific outgoing port, it first obtains the
expected deadline of the packet, and then put the packet to the
deadline queue with the relevant TTL value of the outgoing port
for transmission.
o For a deadline queue whose TTL is not reduced to 0, its scheduling
priority cannot be set to the highest value. The smaller the TTL,
the higher the priority. A transmission mode can be further
configured for a deadline queue to control its transmission
behavior. There are two modes:
* The first mode is to allow participation in priority based
scheduling, also termed as in-time mode;
* The second mode, not allowed, also termed as on-time mode.
That is, a queue with on-time mode is allowed to participate in
priority based scheduling only when its TTL becomes 0.
In-time mode is applicable to low delay services, and on-time mode
is applicable to low delay jitter services. Only one mode can be
configured for a deadline queue. One implementation can support
one set of queues in a single mode, or two sets of queues support
two modes.
Peng, et al. Expires January 9, 2023 [Page 4]
Internet-Draft Deadline Routing July 2022
o At the beginning, all deadline queues have different TTL values,
i.e., staggered from each other, so that the TTL of only one
deadline queue will decrease to 0 at any time.
The above authorization time, timer interval and maximum initial TTL
value shall be specified according to the actual capacity of the
node. In fact, each node in the network can independently use
different authorization time for different outgoing ports. The
general principle is that if an outgoing port has a large bandwidth
(such as 100G bps), the authorization time can be small (such as
1us), because the link with large bandwidth can send the required
bits amount even within a small duration; If an outgoing port has a
small bandwidth (e.g. 1G bps), the authorization time should be
larger (e.g. 10us), because the link with small bandwidth needs to
send the required bit amount within a larger duration. In the FE
(Fast Ethernet, 100M bps) scenario, that however may not be the
typical scenario this document focuses on, the transmission time of a
single packet may take several microseconds, then attention must be
paid to ensure that authorization time is larger than the
transmission time of a single packet, especially the authorization
time should include the interferrence delay caused by a single low
priority packet with maximum size.
A specific example of the deadline queue is depicted in Figure 1.
+------------------------------+ +------------------------------+
| Deadline Queue Group: | | Deadline Queue Group: |
| queue-1(TTL=60us) ###### | | queue-1(TTL=50us) ###### |
| queue-2(TTL=50us) ###### | | queue-2(TTL=40us) ###### |
| queue-3(TTL=40us) ###### | | queue-3(TTL=30us) ###### |
| queue-4(TTL=30us) ###### | | queue-4(TTL=20us) ###### |
| queue-5(TTL=20us) ###### | | queue-5(TTL=10us) ###### |
| queue-6(TTL=10us) ###### | | queue-6(TTL=0us) ###### |
| queue-7(TTL=0us) ###### | | queue-7(TTL=60us) ###### |
+------------------------------+ +------------------------------+
+------------------------------+ +------------------------------+
| Non-deadline Queue Group: | | Non-deadline Queue Group: |
| queue-8 ############ | | queue-8 ############ |
| queue-9 ############ | | queue-9 ############ |
| queue-10 ############ | | queue-10 ############ |
| ... ... | | ... ... |
+------------------------------+ +------------------------------+
-o----------------------------------o-------------------------------->
T0 T0+10us time
Figure 1: Example of Deadline Queue for outgoing Port
Peng, et al. Expires January 9, 2023 [Page 5]
Internet-Draft Deadline Routing July 2022
In this example, the authorization time for deadline queue group is
configured to 10us. Queue-1 ~ queue-7 are deadline queues, and other
queues are traditional non-deadline queues. Each deadline queue has
its TTL attribute. The maximum initial TTL is 60us. At the initial
time (T0), the TTL of all deadline queues are staggered from each
other. For example, the TTL of queue-1 is 60us, the TTL of queue-2
is 50uS, the TTL of queue-3 is 40us, and so on. At this time, only
the TTL of queue-7 is 0, which has the highest scheduling priority.
Suppose the scheduling engine initiates a cycle timer with a time
interval of 10us. After each timer timeout, the timer interval will
be subtracted from the TTL of all deadline queues. As shown in the
figure, at T0 + 10us, the timer timeout, the TTL of queue-1 becomes
50uS, the TTL of queue-2 becomes 40us, the TTL of queue-3 becomes
30us, etc. At this time, the TTL of queue-7 returns to the maximum
initial TTL of 60us and is no longer set to the highest scheduling
priority; The TTL of queue-6 becomes 0, which has the highest
scheduling priority.
When the TTL of a deadline queue becomes 0, it has a time limit of
10us (i.e., authorization time) to send packets in the queue. During
this period, it will be prohibited to receive new packets (in fact,
there can be no new packets with a deadline of 0). After the 10us
time elapses, the TTL of another deadline queue will change to 0.
If the deadline queue with the highest priority is still free after
sending packets within the authorized time, the scheduling engine
will visit other queues with the second highest priority during the
rest of the authorized time.
Note that for each deadline queue with specific TTL, if both in-time
and on-time policies are supported, it may include two sub-queues,
one used to buffer in-time packets and the other used to buffer on-
time packets.
3. Get Deadline Information of Packets
3.1. Get Planned Residence Time
The planned residence time of the packet is an offset time, which is
based on the time when the packet enters the node and represents the
maximum time allowed for the packet to stay inside the node. There
are many ways to obtain the planned residence time of the packet.
o Carried in the packet. The ingress PE node, when encapsulating
the deterministic service flow, can explicitly insert the planned
residence time into the packet according to SLA. The intermediate
node, after receiving the packet, can directly obtain the planned
Peng, et al. Expires January 9, 2023 [Page 6]
Internet-Draft Deadline Routing July 2022
residence time from the packet. Generally, only a single planned
residence time needs to be carried in the packet, which is
applicable to all nodes along the path; Or insert a stack composed
of multiple deadlines, one for each node.
[I-D.peng-6man-deadline-option] defined a method to carry the
planned residence time in the IPv6 packets .
o Included in the FIB entry. Each node in the network can maintain
the deterministic FIB entry. After the packet hits the
deterministic FIB entry, the planned residence time is obtained
from the forwarding information contained in the FIB entry.
o Included in the policy entry. Configure local policies on each
node in the network, and then set the corresponding planned
residence time according to the matched specific characteristics
of the packet, such as 5-tuple.
For a deterministic delay path based on deadline queue scheduling,
the path it passes through has deterministic end-to-end delay
requirements. It includes two parts, one is the cumulative node
delay and the other is the cumulative link transmission delay. The
end-to-end delay requirement is subtracted from the cumulative link
transmission delay to obtain the cumulative node delay. A simple
method is that the accumulated node delay is shared equally by each
intermediate node along the path to obtain the planning deadline of
each node.
3.2. Get Existing Cumulative Planned Residence Time
The existing cumulative planned residence time of the packet refers
to the sum of the planned residence time of all upstream nodes before
the packet is transmitted to this node. This information needs to be
carried in the packet. Every time the packet passes through a node,
the node accumulates its corresponding planned residence time to the
existing cumulative planned residence time field in the packet.
[I-D.peng-6man-deadline-option] defined a method to carry existing
cumulative planned residence time in the IPv6 packets.
The setting of "existing cumulative planned residence time" in the
packet needs to be friendly to the chip for reading and writing. For
example, it should be designed as a fixed position in the packet.
The chip may support flexible configuration for that position.
3.3. Get Existing Accumulated Actual Residence Time
The existing cumulative actual residence time of the packet, refers
to the sum of the actual residence time of all upstream nodes before
the packet is transmitted to this node. This information needs to be
Peng, et al. Expires January 9, 2023 [Page 7]
Internet-Draft Deadline Routing July 2022
carried in the packet. Every time the packet passes through a node,
the node accumulates its corresponding actual residence time to the
existing cumulative actual residence time field in the packet.
[I-D.peng-6man-deadline-option] defined a method to carry existing
cumulative actual residence time in the IPv6 packets.
The setting of "existing cumulative actual residence time" in the
packet needs to be friendly to the chip for reading and writing. For
example, it should be designed as a fixed position in the packet.
The chip may support flexible configuration for that position.
Although other methods can also be, for example, carrying the
absolute system time of receiving and sending in the packet to
compute the actual residence time indirectly, that has a low
encapsulation efficiency and require strict time synchronization
between nodes.
A possible method to get the actual residence time in the node is
that, the receiving and sending time of the packet can be recorded in
the auxiliary data structure (note that is not packet itself) of the
packet, and the actual residence time of the packet in the node can
be calculated according to these two times.
3.4. Get Existing Accumulated Residence Time Deviation
The existing accumulated residence time deviation equals existing
cumulative planned residence time minus existing cumulative actual
residence time. This value can be positive or negative.
If the existing cumulative planned residence time and the existing
cumulative actual residence time are carried in the packet, it is not
necessary to carry the existing accumulated residence time deviation.
Otherwise, it is necessary. The advantage of the former is that it
can be applied to more scenarios.
4. Put Packets into the Deadline Queues
[I-D.ietf-detnet-bounded-latency] presents a latency model for DetNet
nodes. There are six delays that a packet can experience from hop to
hop. The processing delay (4), the regulator delay (5), the queuing
subsystem delay (6), and the output delay (1) together contribute to
the residence time in the node.
In this document, the residence delay in the node is simplified into
two parts: the first part is to lookup the forwarding table when the
packet is received from the incoming port (or generated by the
control plane) and deliver the packet to the line card where the
outgoing port is located; the second part is to store the packet in
Peng, et al. Expires January 9, 2023 [Page 8]
Internet-Draft Deadline Routing July 2022
the queue of the outgoing port for transmission. These two parts
contribute to the actual residence time of the packet in the node.
The former can be called forwarding delay and the latter can be
called queuing delay. The forwarding delay is related to the chip
implementation and is generally constant; The queuing delay is
unstable.
When a node receives a packet from an upstream node, it can first get
the existing accumulated residence time deviation, and then add it to
the planned residence time of the packet at this node to obtain the
deadline adjustment value, and then on the basis of the deadline
adjustment value, deducting the forwarding delay of the packet in the
node, the allowable queuing delay value is obtained, and then the
packet will be put to the deadline queue with TTL as the above
allowable queuing delay value for sending. If the calculated
allowable queuing delay is not exactly equal to the TTL of any queue,
the packet selects the queue with the closest TTL to enter.
Under normal circumstances, if each hop strictly controls the
scheduling of the packet according to its planned residence time, the
actual residence time of the packet will be very close to the planned
residence time, and the absolute value of the existing accumulated
residence time deviation will be very small.
More generally, assume that the local node in a deterministic path is
i, all upstream nodes are from 1 to i-1, and downstream nodes are i +
1, the planned residence time is D, the actual residence time is R,
the deadline adjustment value is M, the forwarding delay inside the
node is F, the existing accumulated residence time deviation is E,
and the allowable queuing delay is Q, then the allowable queuing
delay (Q) of the packet on this node i is calculated as follows:
E(i-1) = D(1) + D(2) + ... + D(i-1) - R(1) - R(2) - ... - R(i-1)
M(i) = D(i) + E(i-1)
Q(i) = M(i) - F(i)
Consider some extreme cases. For example, many upstream nodes adopt
the in-time mode to send packets quickly. Packets almostly need not
queue in these nodes, but only depend on the forwarding delay. Then
the existing accumulated residence time deviation (E) may be a very
large positive value, resulting in a large allowable queuing delay
(Q). If this value exceeds the maximum initial TTL of the deadline
queue maintained by the node, the allowable queuing delay (Q) should
be modified to the maximum initial TTL.
Peng, et al. Expires January 9, 2023 [Page 9]
Internet-Draft Deadline Routing July 2022
For another example, if some upstream nodes are abnormal and have a
very large actual residence time (R), the existing accumulated
residence time deviation (E) may be a negative number, resulting in
the allowable queuing delay (Q) may be less than or equal to 0, the
allowable queuing delay (Q) should be modified to a minimum TTL other
than 0.
Figure 2 depicts an example of packets buffered to the deadline
queue.
packet-2 packet-1 +------------------------------+
+--------+ +--------+ | Deadline Queue Group: |
| D=20us | | D=30us | | queue-1(TTL=60us) ###### |
| E=10us | | E=-10us| +--+ | queue-2(TTL=50us) ###### |
+--------+ +--------+ |\/| | queue-3(TTL=40us) ###### |
------incoming port-1------> |/\| | queue-4(TTL=30us) ###### |
|\/| | queue-5(TTL=20us) ###### |
packet-4 packet-3 |/\| | queue-6(TTL=10us) ###### |
+--------+ +--------+ |\/| | queue-7(TTL=0us) ###### |
| | | D=30us | |/\| +------------------------------+
+--------+ | E=-30us| |\/|
+--------+ |/\|
------incoming port-2------> |\/| +------------------------------+
|/\| | Non-deadline Queue Group: |
packet-6 packet-5 |\/| | queue-8 ############ |
+--------+ +--------+ |/\| | queue-9 ############ |
| | | D=40us | |\/| | queue-10 ############ |
+--------+ | E=40us | |/\| | ... ... |
+--------+ +--+ +------------------------------+
------incoming port-3------> ---------outgoing port---------->
-o----------------------------------o-------------------------------->
receiving-time base +F time
Figure 2: Time Sensitive Packets Buffered to Deadline Queue
As shown in Figure 2, the node successively receives six packets from
three incoming ports, among which packet 1, 2, 3 and 5 have
corresponding deadline information, while packet 4 and 6 are
traditional packets. These packets need to be forwarded to the same
outgoing port according to the forwarding table entries. It is
assumed that they arrive at the line card where the outgoing port is
located at almost the same time after the forwarding delay in the
node (F = 10us). At this time, the queue status of the outgoing port
is shown in the figure. Then:
Peng, et al. Expires January 9, 2023 [Page 10]
Internet-Draft Deadline Routing July 2022
o The allowable queuing delay (Q) of packet 1 in the node is 30 - 10
-10 = 10us, and it will be put into the deadline queue-6 (its TTL
is 10us).
o The allowable queuing delay (Q) of packet 2 in the node is 20 + 10
-10 = 20us, and it will be put into the deadline queue-5 (its TTL
is 20us).
o The allowable queuing delay (Q) of packet 3 in the node is 30 - 30
-10 = -10us, and it will be modified to the minimum positive value
10 us then put into the deadline queue-6 (its TTL is 10us).
o The allowable queuing delay (Q) of packet 5 in the node is 40 + 40
-10 = 70us, and it will be modified to the maximum positive value
60 us then put into the deadline queue-1 (its TTL is 60us).
o Packets 4 and 6 will be put into the non-deadline queue in the
traditional way.
5. Traffic Regulation and Shaping
On the ingress PE node, traffic regulation is performed on UNI port,
so that the service traffic does not exceed its reserved bandwidth.
Suppose there are N sources, and the packets they send carry the same
deadline. These packets may arrive at an intermediate node at the
same time and put into the same deadline queue. If the reserved
bandwidth of deadline queue at N sources is M0, and the reserved
bandwidth of deadline queue at intermediate nodes is Mx, then it
needs to meet: N * M0 < = Mx. This means that a larger bandwidth is
required on the intermediate node to send more bits in the same time
duration, i.e., larger buffer size. Especially, packets with
different deadlines sent by a single ingress PE node at different
instant of time (e.g, for on-time mode the packet sent early has a
larger planned residence time than the packet sent late, or for in-
time mode the packet sent early face more interference delay than the
packet sent late.), may be put into the same deadline queue by an
intermediate node.
On the ingress PE node, traffic shaping is performed on NNI port.
Multiple continuous packets of the specific service flow are stored
in the deadline queue with corresponding remaining time according to
the planned residence time of the service flow. Note that these
packets are not stored in the same queue over time. The amount of
bits that can be stored in one queue is equal to the reserved
bandwidth * authorization time, however, at least one whole packet
shall be loaded. For example, if the allowable queuing delay is
20us, then within the current authorization time, the first sequence
of the packets will be put into the current deadline queue with TTL =
Peng, et al. Expires January 9, 2023 [Page 11]
Internet-Draft Deadline Routing July 2022
20us until the reserved bandwidth limit is reached; Then, within the
next authorization time, the next sequence of packets will be put
into the current TTL = 20us queue until the reserved bandwidth limit
is reached; and so on, until the total service bits are loaded.
Figure 3 depicts an example of deadline based traffic shaping on the
ingress PE node. It is assumed that the packets loaded in each
authorization time do not exceed the reserved bandwidth of the
service.
1st packet
|
v
+-+ +-+ +----+ +-+ +--+ +------+
|1| |2| | 3 | |4| |5 | | 6 | <= packet sequence
+-+ +-+ +----+ +-+ +--+ +------+
| | | | | |
~+F ~+F ~+F ~+F ~+F ~+F
| | | | | |
UNI v v v v v v
ingress PE -+--------+--------+--------+--------+--------+--------+---->
NNI | Auth | Auth | Auth | Auth | Auth | Auth | time
| time | time | time | time | time | time |
v v v v
1,2 in 3 in 4,5 in 6 in
Buffer-A Buffer-B Buffer-C Buffer-D
(TTL=Q) (TTL=Q) (TTL=Q) (TTL=Q)
| | | |
~+Q ~+Q ~+Q ~+Q
| | | |
sending v v v v
+-+ +-+ +----+ +-+ +--+ +------+
|1| |2| | 3 | |4| |5 | | 6 |
+-+ +-+ +----+ +-+ +--+ +------+
Figure 3: Deadline Based Traffic Shaping
6. Compatibility Considerations
For a particular path, if only some nodes in the path upgrade support
the deadline mechanism defined in this document, the end-to-end
deterministic delay/jitter target will only be partially achieved.
Those legacy devices may adopt the existing priority based scheduling
mechanism, and ignore the possible deadline information in the
packet, thus the delay intra node produced by them cannot be
perceived by the adjacent upgraded node. The more upgraded nodes
included in the path, the closer to the delay/jitter target.
Peng, et al. Expires January 9, 2023 [Page 12]
Internet-Draft Deadline Routing July 2022
Although, the legacy devices may not support the dataplane mechanism
described in this document, but they can be freely programmed (such
as P4 language) to measure and insert the deadline information into
packets, in this case the achievement of delay/jitter target will be
more perfect.
Only a few key nodes are upgraded to support deadline mechanism,
which is low-cost, but can meet a service with relatively loose time
requirements. Figure 4 shows an example of upgrading only several
network edge nodes. In the figure, only R1, R2, R3 and R4 are
upgraded to support deadline mechanism. A deterministic path across
domain 1, 2, and 3 is established, which contains nodes R1, R2, R3,
and R4, as well as explicit nodes in each domain. Domain 1, 2 and 3
use the traditional strict priority based forwarding mechanism. The
encoding of the packet sent by R1 includes the planned residence time
and the accumulated residence time deviation. Especially, IP DSCP or
Traffic Class are also set to appropriate values. The basic
principle of setting is that the less the planned residence time, the
higher the priority. However, in order to avoid the interference of
non deterministic flow to deterministic flow, the priority of
deterministic flow should be set as high as possible.
The delay analysis based on strict priority in each domain can be
found in [SP-LATENCY], which gives the formula to evaluate the worst-
case delay of each hop during the resource reservation procedure.
The worst-case delay depends on the number of hops and the burst size
of interference flows that may be faced on each hop. The delay
analysis of in-time mode of deadline mechanism is similar to SP
mechanism, except that in-time mode has different predefined upper
latency bound (i.e., the planned residence time) and can further
distinguish between emergency and non emergency according to deadline
information other than traffic class. For example, a typical
configuration is that if the burst interval is 250us and the planned
residence time is 20us, each node within 12 hops will only face a
single burst. In-time mode can even be pessimistic that its worst
delay is the same as on-time mode, that is, the number of hops
multiplied by the planned residence time. In later versions, we will
further analyze how to ensure that the average actual residence time
per hop does not exceed the planned residence time.
When the boundary node (e.g, R2) receives the deterministic traffic,
it will decide whether to speed up or hold according to the
cumulative residence time deviation information carried in the
packet. In-time traffic is always sent as soon as possible,
especially when the residence time deviation of the packet is
negative. On time traffic always controls the sending time so that
the average planned residence time is followed, especially when the
residence time deviation of the packet is positive. For a specific
Peng, et al. Expires January 9, 2023 [Page 13]
Internet-Draft Deadline Routing July 2022
deterministic flow, if it experiences too much latency in the SP
domain (due to unreasonable setting of traffic class and the
inability to distinguish between deterministic and non deterministic
flows), even if the boundary node accelerates the transmission, it
may not be able to achieve the target of low E2E latency. If the
traffic experiences less latency within the SP domain, on-time mode
will work to achieve the end-to-end jitter target.
_____ ___ _____ ___ _____ ___
/ \/ \___ / \/ \___ / \/ \___
/ \ / \ / \
+--+ +--+ +--+ +--+
|R1| Strict Priority |R2| Strict Priority |R3| Strict Priority |R4|
+--+ domian 1 +--+ domian 2 +--+ domian 3 +--+
\____ __/ \____ __/ \____ __/
\_______/ \_______/ \_______/
Figure 4: Example of partial upgrade
7. Benefits
The mechanism described in this document has the following benefits:
o Time synchronization is not required between network nodes. Each
node can flexibly set the authorization time length of the
deadline queue according to its own outgoing port bandwidth.
o Packet multiplexing based, it is an enhancement of PQ scheduling
algorithm, friendly to the upgrade of packet switching network.
All nodes in the network can independently use cycle timers with
different timeout intervals to traverse the deadline queues.
o The packet can control its expected residence time in the node. A
single set of deadline queues supports multiple levels of
residence time.
o For in-time mode, the end-to-end delay is H*(F~D), jitter is H*Q;
For on-time mode, the end-to-end delay is H*D, jitter is a just
single authorization time.
8. IANA Considerations
There is no IANA requestion for this document.
Peng, et al. Expires January 9, 2023 [Page 14]
Internet-Draft Deadline Routing July 2022
9. Security Considerations
TBD
10. Acknowledgements
TBD
11. References
11.1. Normative References
[I-D.ietf-detnet-bounded-latency]
Finn, N., Boudec, J. L., Mohammadpour, E., Zhang, J., and
B. Varga, "DetNet Bounded Latency", draft-ietf-detnet-
bounded-latency-10 (work in progress), April 2022.
[I-D.peng-6man-deadline-option]
Peng, S. and B. Tan, "Deadline Option", draft-peng-6man-
deadline-option-00 (work in progress), January 2022.
[I-D.stein-srtsn]
Stein, Y. (., "Segment Routed Time Sensitive Networking",
draft-stein-srtsn-01 (work in progress), August 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
11.2. Informative References
[SP-LATENCY]
"Guaranteed Latency with SP", 2020,
<https://www.ieee802.org/1/files/public/docs2020/dd-
grigorjew-strict-priority-latency-0320-v02.pdf>.
Peng, et al. Expires January 9, 2023 [Page 15]
Internet-Draft Deadline Routing July 2022
Authors' Addresses
Shaofu Peng
ZTE Corporation
China
Email: peng.shaofu@zte.com.cn
Bin Tan
ZTE Corporation
China
Email: tan.bin@zte.com.cn
Peng Liu
China Mobile
China
Email: liupengyjy@chinamobile.com
Peng, et al. Expires January 9, 2023 [Page 16]