Network Shaofu. Peng Internet-Draft Bin. Tan Intended status: Standards Track ZTE Corporation Expires: September 2, 2022 Peng. Liu China Mobile March 1, 2022 Deadline Based Deterministic Forwarding draft-peng-detnet-deadline-based-forwarding-01 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 September 2, 2022. 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 September 2, 2022 [Page 1] Internet-Draft Deadline Routing March 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 Deadline . . . . . . . . . . . . . . . . . . 6 3.2. Get Existing Cumulative Planned Deadline . . . . . . . . 7 3.3. Get Existing Accumulated Actual Dwell Time . . . . . . . 7 3.4. Get Existing Accumulated Deadline Deviation . . . . . . . 8 4. Put Packets into the Deadline Queues . . . . . . . . . . . . 8 5. Traffic Regulation and Shaping . . . . . . . . . . . . . . . 11 6. Compatibility Considerations . . . . . . . . . . . . . . . . 12 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 September 2, 2022 [Page 2] Internet-Draft Deadline Routing March 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 dwell 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. 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 September 2, 2022 [Page 3] Internet-Draft Deadline Routing March 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 authorization time. In principle, all packets buffered in the queue shall be sent within this authorization time. If the queue is sent 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 greater than or equal to the authorization time of the deadline queue. For simplicity, they are same. o For a deadline queue whose TTL has been reduced to 0, after a new round of timer timeout, 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. A local policy may be used to control the transmission of buffered packets. There are two options: the first option, allowing to be involved in scheduling, also termed as in-time policy; the second option, not allowing, also termed as on-time policy. In-time policy is applicable to the service requirements of low delay, and on-time policy is applicable to low delay jitter. When instantiating deadline scheduling algorithm, one implementation can support only one option or both. 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 timer interval for different outgoing ports. The general Peng, et al. Expires September 2, 2022 [Page 4] Internet-Draft Deadline Routing March 2022 principle is that if an outgoing port has a large bandwidth (such as 100G bps), the timer interval (and the authorization time of the deadline queue) can be small (such as 1us), because the link with large bandwidth can send the required bits amount even within a small time interval; If an outgoing port has a small bandwidth (e.g. 1G bps), the timer interval (and the authorization time of the deadline queue) should be larger (e.g. 10us), because the link with small bandwidth needs to send the required bit amount within a larger time interval. 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 In this example, the timer interval 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 Peng, et al. Expires September 2, 2022 [Page 5] Internet-Draft Deadline Routing March 2022 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. For simplicity, set the authorization time of the deadline queue to be consistent with the time interval of the cycle timer, which is also 10us. When the TTL of a deadline queue becomes 0, it has a time limit of 10us 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 cycle timer will timeout again, The TTL of another deadline queue will change to 0. It is also feasible to set the authorization time to be less than the cycle timer interval. 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 Deadline The planned deadline 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 deadline of the packet. o Carried in the packet. The ingress PE node, when encapsulating the deterministic service flow, can explicitly insert the planned deadline into the packet according to SLA. The intermediate node, after receiving the packet, can directly obtain the planned deadline from the packet. Generally, only a single planned deadline 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 planned deadline 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 Peng, et al. Expires September 2, 2022 [Page 6] Internet-Draft Deadline Routing March 2022 deterministic FIB entry, the planned deadline 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 deadline 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 Deadline The existing cumulative planned deadline of the packet refers to the sum of the planned deadline 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 deadline to the existing cumulative planned deadline field in the packet. [I-D.peng-6man-deadline-option] defined a method to carry existing cumulative planned deadline in the IPv6 packets. The setting of "existing cumulative planned deadline" 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 Dwell Time The existing cumulative actual dwell time of the packet, refers to the sum of the actual dwell 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 actual dwell time to the existing cumulative actual dwell time field in the packet. [I-D.peng-6man-deadline-option] defined a method to carry existing cumulative actual dwell time in the IPv6 packets. The setting of "existing cumulative actual dwell time" in the packet needs to be friendly to the chip for reading and writing. For Peng, et al. Expires September 2, 2022 [Page 7] Internet-Draft Deadline Routing March 2022 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 dwell time indirectly, that has a low encapsulation efficiency and require strict time synchronization between nodes. A possible method to get the actual dwell 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 dwell time of the packet in the node can be calculated according to these two times. 3.4. Get Existing Accumulated Deadline Deviation The existing accumulated deadline deviation equals existing cumulative planned deadline minus existing cumulative actual dwell time. This value can be positive or negative. If the existing cumulative planned deadline and the existing cumulative actual dwell time are carried in the packet, it is not necessary to carry the existing accumulated deadline 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 The lifetime of the packet inside the node mainly includes 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 the queue of the outgoing port for transmission. These two parts contribute to the actual dwell 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 deadline deviation, and then add it to the planned deadline 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 Peng, et al. Expires September 2, 2022 [Page 8] Internet-Draft Deadline Routing March 2022 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 deadline, the actual dwell time of the packet will be very close to the planned deadline, and the absolute value of the existing accumulated deadline 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 deadline is D, the actual dwell time is R, the deadline adjustment value is M, the forwarding delay inside the node is F, the existing accumulated deadline 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 policy to send packets quickly. Packets almostly need not queue in these nodes, but only depend on the forwarding delay. Then the existing accumulated deadline 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. For another example, if some upstream nodes are abnormal and have a very large actual dwell time (R), the existing accumulated deadline deviation (E) may be a negative number, resulting in the allowable queuing delay (Q) may be less than or equal to 0, which is smaller than the cycle timer interval of the deadline queue maintained in the node, then the allowable queuing delay (Q) should be modified to the cycle timer interval value. Figure 2 depicts an example of packets buffered to the deadline queue. Peng, et al. Expires September 2, 2022 [Page 9] Internet-Draft Deadline Routing March 2022 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-2------> ---------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: 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). Note Peng, et al. Expires September 2, 2022 [Page 10] Internet-Draft Deadline Routing March 2022 that the minimum positive value is a timer interval that is a local parameter per port based on port's bandwidth. 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). Note that the maximum positive value is an empirical value that can be configured according to the maximum delay requirements of deterministic services. 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 times, may be put into the same deadline queue by an intermediate node and sent within the same authorization time. In order to mitigate this impact, it is not recommended to apply the on-time policy to packets with large deadline value. 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 deadline 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 timer interval, the first sequence of the packets will be put into the current deadline queue with TTL = 20us until the reserved bandwidth limit is reached; Then, within the next timer interval, 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. Peng, et al. Expires September 2, 2022 [Page 11] Internet-Draft Deadline Routing March 2022 Figure 3 depicts an example of deadline based traffic shaping on the ingress PE node. It is assumed that the packets loaded in each timer interval 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 | | | | | | | time |interval|interval|interval|interval|interval|interval| 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. However, 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. Peng, et al. Expires September 2, 2022 [Page 12] Internet-Draft Deadline Routing March 2022 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 dwell time in the node. A single set of deadline queues supports multiple levels of dwell time. o For in-time policy, the end-to-end delay is H*(F~D), jitter is H*Q; For on-time policy, 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. 9. Security Considerations TBD 10. Acknowledgements TBD 11. Normative References [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, . Peng, et al. Expires September 2, 2022 [Page 13] Internet-Draft Deadline Routing March 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 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 September 2, 2022 [Page 14]