DetNet Shaofu. Peng Internet-Draft ZTE Intended status: Standards Track Peng. Liu Expires: 5 January 2027 China Mobile Kashinath. Basu Oxford Brookes University 4 July 2026 Mechanism to Control Jitter Caused by Ingress Shaping draft-peng-detnet-policing-jitter-control-03 Abstract This document presents a noble mechanism to eliminate jitter caused by shaping delay on the network entrance node. It needs to be used in combination with a queueing mechanism that provides low jitter for the DetNet path, and ultimately provides a low jitter guarantee for the DetNet flow. 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 5 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Peng, et al. Expires 5 January 2027 [Page 1] Internet-Draft shaping Jitter Control July 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the Solution . . . . . . . . . . . . . . . . . . 3 4. Set Shaping Delay Budget . . . . . . . . . . . . . . . . . . 5 5. Multi-domain Considerations . . . . . . . . . . . . . . . . . 5 5.1. Separate Shaping for Each Domain . . . . . . . . . . . . 5 5.2. Single Shaping for All Domains . . . . . . . . . . . . . 6 6. Encoding Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Policing (as defined in[RFC2216]) is the set of actions triggered when a flow's actual data traffic characteristics exceed the expected values given in the flow's traffic specification. Services which require policing functions to operate correctly must specify both the action to be taken when such discrepancies occur and the locations in the network where discrepancies are to be detected. Examples of such actions might include relegating the packet to best effort service, dropping packets, reshaping the traffic, or marking non-conforming traffic in some fashion. Shaping (as defined in[RFC2475]) is the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile. DetNet [RFC8655] flows are assumed to be rate limited and DetNet is designed to provide sufficient allocated resources. Rate limiting and shaping functions at the ingress of the DetNet domain must be applied. This is needed for meeting the requirements of DetNet flows as well as for protecting non-DetNet traffic from potentially misbehaving DetNet traffic sources. Peng, et al. Expires 5 January 2027 [Page 2] Internet-Draft shaping Jitter Control July 2026 [RFC9016] defines the traffic specification of the DetNet flow, including Interval, MinPayloadSize, MaxPayloadSize, MinPacketsPerInterval, and MaxPacketsPerInterval. Flows exceeding the traffic specification (i.e., having more traffic than defined by the maximum attributes) must be shaped at the network entrance. Assuming that there is enough buffer space to store nonconforming packets, then that is important for application flows that expect zero packet loss. A conforming packet may experience zero shaping delay, while a nonconforming packet may experience non-zero shaping delay. After shaping at the network entrance, each packet of the application flow will be guaranteed the path delay and jitter bound by the applied queueing mechanisms in the DetNet domain. Generally, the applied queueing mechanism is only responsible for the delay performance of the DetNet path, but not the runtime shaping delay at the network entrance. This document describes a mechanism to eliminate jitter caused by the ingress shaping delay. It needs to be used in combination with a queueing mechanism that provides low jitter for the DetNet path, and ultimately provides a low jitter guarantee for the application flow. 2. 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. 3. Overview of the Solution The end-to-end delay experienced by the application flow can be considered to consist of two parts: ingress shaping delay, and DetNet path delay. According to flow's end-to-end delay requirement and shaping delay budget, a DetNet path delay requirement (i.e., end-to- end delay requirement minus shaping delay budget) can be calculated. An appropriate shaping delay budget can be configured for the application flow according to its TSpec and actual possible arrival pattern, and generally be the maximum shaping delay that may be possibly experienced at the network entrance. The shaping delay budget is consumed by the ingress and egress of the DetNet path. shaping delay budget = ingress shaping delay + egress damping delay Peng, et al. Expires 5 January 2027 [Page 3] Internet-Draft shaping Jitter Control July 2026 The ingress shaping delay is the runtime shaping delay experienced at the network entrance. The egress damping delay is obtained by subtracting the ingress shaping delay from the shaping delay budget. Figure 1 shows that the relationship between these delay components. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (~ ~) (~ ~) +------+ +-------+ DetNet Path +--------+ +------+ |AppSrc|---|Headend|---------------------------|Endpoint|---|AppDst| +------+ +-------+ +--------+ +------+ (~ ~) (~ DetNet Domain ~) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |<---------- E2E Delay Reuirement ---------->| | | | |<--------- Path Delay ----------->| | |<-->| |<-->| ingress egress shaping damping delay delay Figure 1: Relationship Between Delay Elements When the headend of the DetNet path receives the packet from the application source, it may carry the egress damping delay value in the encoded packet sent to the endpoint, and the egress damping delay will be used as the holding time imposed on the endpoint before the packet is delivered to the application destination. The endpoint can also distribute this value to downstream device for damping. Note that some queueing mechanisms, such as [I-D.ietf-detnet-deadline-based-forwarding] and [I-D.ietf-detnet-packet-timeslot-mechanism], also provide the latency deviation (E) information of the DetNet path. Depending on the implementation, the endpoint can use different buffers to firstly implement jitter control based on path latency deviation (E) and secondly jitter control based on egress damping delay, or use the same buffer to uniformly implement jitter control based on the sum of path latency deviation (E) and egress damping delay. However, it must use separate fields in the packet to carry these two values. Peng, et al. Expires 5 January 2027 [Page 4] Internet-Draft shaping Jitter Control July 2026 Therefore, a flow with possible nonconforming packets will be regulated and changed to be conforming at the network entrance, then get the DetNet service within the network, and finally reverted to the nonconforming pattern at the network exit, and then delivered to the application destination. 4. Set Shaping Delay Budget The shaping delay budget can be configured for the application flow according to its TSpec and actual possible arrival pattern. For example, an applicaiton flow has service burst interval (SBI) 100 us, and three packets P1, P2, P3 per SBI. Assuming the maximum packet size is 1000 bits. In the ideal case, a conforming pattern of this application flow is that the three packets arrive evenly at the network entrance, i.e., with packet interval 33 us. However, an extremely case of nonconforming pattern may be that P1, P2, P3 arrived back-to-back. After leaky bucket based regulation, P1, P2 and P3 will get different shaping delays, of which P3 has the largest shaping delay, which may be 2/3 of SBI and can be used as the shaping delay budget. There may be other ways to set the shaping delay budget, such as sampling the most likely arrival pattern of flow to set a smaller shaping delay budget. The network entrance node should maintain the shaping delay budget for each application flow, and when it receives a packet from the application source, it identifies the flow and applies the corresponding shaping delay budget. If the shaping delay budget is M, and the ingress shaping delay of the packet is S, then the egress damping delay for that packet equals to M - S. 5. Multi-domain Considerations In the case of multi-domain, all domains may apply the same or different queueing machanisms. For each transit domain and egress domain, the input traffic should be conforming and then get the DetNet services. The output traffic from the upstream domain must be conforming, that can be achieved based on path latency deviation (E). There are two options to implement shaping jitter control. 5.1. Separate Shaping for Each Domain This option is to implement shaping jitter control at the entrance and exit of each domain independently. It is only applicable to scenarios where transit domains maintain flow states. Peng, et al. Expires 5 January 2027 [Page 5] Internet-Draft shaping Jitter Control July 2026 At each domain entrance, it maintain the shaping delay budget for the application flow, regulate the nonconforming arrived packets, and calculate the egress damping delay for each packet. Then, at each domain exit, packets are held based on the egress damping delay. In this option, each domain contribute a separate shaping delay budget to the end-to-end delay. When the packet leaves the upstream domain, the scheduling metadata related to the queueing mechanism of the upstream domain and the egress damping delay information are removed, and the application header is exposed. The current domain entrance will re-encapsulate the scheduling metadata related to the queueing mechanism of the current domain and the endpoint damping delay information. The limitation of this option is the states per flow maintained at each domain entrance. 5.2. Single Shaping for All Domains This option is to implement shaping jitter control only at the ingress domain entrance and the egress domain exit. It is applicable to scenarios where transit domains do not maintain flow states. At the ingress domain entrance, it maintain the shaping delay budget for the application flow, regulate the nonconforming arrived packets, and calculate the egress damping delay for each packet. Then, at the egress domain exit, packets are held based on the egress damping delay. In this option, only a single shaping delay budget is contributed to the end-to-end delay. When the packet leaves the upstream domain, the scheduling metadata related to the queueing mechanism of the upstream domain is removed, but the egress damping delay information remains unchanged. The current domain entrance will re-encapsulate the scheduling metadata related to the queueing mechanism of the current domain. However, if all domains use the same queueing mechanism, they may optionally share a single metadata to avoid removing and re-encapsulating. This option has less cost than the first option, i.e., no states per flow maintained on each domain entrance. 6. Encoding Considerations A new IPv6 option for DOH Options header ([RFC8200]) to carry egress damping delay is defined in [I-D.peng-6man-delay-options]. A new ancillary data for MPLS MNA header ([I-D.ietf-mpls-mna-hdr]) to carry endpoint damping delay is for further definition. Peng, et al. Expires 5 January 2027 [Page 6] Internet-Draft shaping Jitter Control July 2026 7. IANA Considerations This document need not require IANA allocations. 8. Security Considerations TBD. 9. Acknowledgements TBD. 10. References 10.1. Normative References [I-D.ietf-detnet-deadline-based-forwarding] Peng, S., Du, Z., Basu, K., cheng, C., Yang, D., and C. Liu, "Deadline Based Deterministic Forwarding", Work in Progress, Internet-Draft, draft-ietf-detnet-deadline- based-forwarding-01, 26 June 2026, . [I-D.ietf-detnet-packet-timeslot-mechanism] Peng, S., Liu, P., Basu, K., Liu, A., Yang, D., Peng, G., and J. Zhao, "Timeslot Queueing and Forwarding Mechanism", Work in Progress, Internet-Draft, draft-ietf-detnet- packet-timeslot-mechanism-01, 27 June 2026, . [I-D.ietf-mpls-mna-hdr] Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K. Kompella, "MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data", Work in Progress, Internet-Draft, draft-ietf-mpls- mna-hdr-21, 24 February 2026, . [I-D.peng-6man-delay-options] Peng, S., "Delay Options", Work in Progress, Internet- Draft, draft-peng-6man-delay-options-01, 26 January 2026, . Peng, et al. Expires 5 January 2027 [Page 7] Internet-Draft shaping Jitter Control July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, DOI 10.17487/RFC2216, September 1997, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, "Flow and Service Information Model for Deterministic Networking (DetNet)", RFC 9016, DOI 10.17487/RFC9016, March 2021, . Authors' Addresses Shaofu Peng ZTE China Email: peng.shaofu@zte.com.cn Peng Liu China Mobile China Email: liupengyjy@chinamobile.com Peng, et al. Expires 5 January 2027 [Page 8] Internet-Draft shaping Jitter Control July 2026 Kashinath Basu Oxford Brookes University United Kingdom Email: kbasu@brookes.ac.uk Peng, et al. Expires 5 January 2027 [Page 9]