Internet DRAFT - draft-sx-mpls-detnet-bounded-latency
draft-sx-mpls-detnet-bounded-latency
MPLS Working Group X. Song
Internet-Draft Q. Xiong
Intended status: Standards Track ZTE Corp.
Expires: 18 April 2024 R. Gandhi
Cisco Systems, Inc.
16 October 2023
MPLS Encapsulation for Deterministic Latency Network Action
draft-sx-mpls-detnet-bounded-latency-01
Abstract
This document specifies formats and principles for the MPLS header
which contains the Deterministic Latency Network Action (DLNA)
option, designed for use over a DetNet network with MPLS data plane.
It enables guaranteed latency support and makes scheduling decisions
for time-sensitive service running on DetNet nodes that operate
within a constrained network domain.
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 18 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Song, et al. Expires 18 April 2024 [Page 1]
Internet-Draft MPLS Encapsulation for DLNA October 2023
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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. DetNet DLNA Option . . . . . . . . . . . . . . . . . . . . . 4
3.1. Queuing delay . . . . . . . . . . . . . . . . . . . . . . 4
3.2. DLNA Option . . . . . . . . . . . . . . . . . . . . . . . 5
4. MPLS Extension for DLNA . . . . . . . . . . . . . . . . . . . 5
4.1. DetNet MPLS Header for DLNA . . . . . . . . . . . . . . . 5
4.2. MPLS In-Stack DLNA Network Action . . . . . . . . . . . . 6
4.3. MPLS Post-Stack DLNA Network Action . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
As specified in [RFC8655] and [RFC8938], Deterministic Networking
(DetNet) operates at the IP layer and delivers service with low data
loss rates and bounded latency guarantee within a network domain.
As defined in [RFC8964], the DetNet MPLS data plane provides a
foundation of building blocks to enable PREOF (Packet Replication,
Elimination and Ordering Functions (PREOF)) functions to DetNet
service and forwarding sub-layer. The DetNet service sub-layer
includes a DetNet Control Word (d-CW), service label (S-Label), an
aggregation label (A-Label) in special case of S-Label used for
aggregation. The DetNet forwarding sub-layer supports one or more
forwarding labels (F-Labels) used to forward a DetNet flow over MPLS
domains. The DetNet forwarding sub-layer provides corresponding
forwarding assurance with IETF existing functions using resource
allocations and explicit routes. But these functions may not be
enough to provide the deterministic latency (including bounded
Song, et al. Expires 18 April 2024 [Page 2]
Internet-Draft MPLS Encapsulation for DLNA October 2023
latency, low packet loss and in-order delivery) assurance. Because
latency variation in one DetNet system results in the need for extra
buffer space in the next-hop DetNet system(s), which in turn
increases the worst-case per-hop latency. So standard queuing and
scheduling algorithms are required to compute and reserve the
sufficient buffer space for DetNet nodes along the path of DetNet
flows.
To support time-sensitive service with ultra-low loss rates and
deterministic latency, it is required to apply feasible scheduling
mechanisms to specific applications for deterministic networking. As
described in [RFC9320], the end-to-end bounded latency is considered
as the sum of non-queuing and queuing delay bounds along with the
queuing mechanisms. The value for non-queuing delay bounds (which
consist of packet output delay, link delay, frame preemption delay
and processing delay) is relative with the physical capability of on-
used networks and can be considered to be stable. The unstable
latency delay bounds are mainly from queuing delay and regulation
delay. The regulation delay is mainly from regulation policy. To
simplify the question this draft assumes there is no regulation
policy. So the question is left to address the selection for queuing
mechanisms and queuing delay information encapsulation in data plane.
The queuing mechanisms, as mentioned in [RFC9320] and [RFC8655],
which include Time Aware Shaping IEEE802.1Qbv, Asynchronous Traffic
Shaping IEEE802.1Qcr, cyclic-scheduling queuing mechanism proposed in
IEEE802.1Qch. There are also discussions on new queuing or
scheduling mechanisms such as [I-D.peng-6man-deadline-option] and
[I-D.dang-queuing-with-multiple-cyclic-buffers]. In terms of delay
guarantee for different applications, to select the right scheduling/
queuing mechanism applied to a specific application is required.
Based on the existing DetNet MPLS encapsulations and mechanisms
[RFC8964], the draft defines the encoding format for Deterministic
Latency Network Action (DLNA) option in MPLS data plane.
MPLS Network Actions (MNA) are used to indicate actions for LSPs and/
or MPLS packets and to transfer data needed for these actions.
[I-D.ietf-mpls-mna-hdr] defines the MNA solution for carrying Network
Actions with In-Stack Data and associated Ancillary Data (AD) (i.e.,
in the MPLS label stack). [I-D.jags-mpls-ps-mna-hdr] defines the MNA
solution for carrying Network Actions with Post-Stack Data and
associated Ancillary Data (i.e., below the bottom of the MPLS label
stack). This draft describes MNA solutions for DLNA in DetNet.
2. Conventions
Song, et al. Expires 18 April 2024 [Page 3]
Internet-Draft MPLS Encapsulation for DLNA October 2023
2.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.2. Terminology
Refer to [RFC8655], [RFC8964], [I-D.ietf-mpls-mna-hdr] and [RFC9320]
for the key terms used in this document.
Deterministic Latency (DL):the bound of network latency and delay
variation between two DetNet endpoints. It may includes parameters
such as bounded latency, bounded delay variation, etc.
Deterministic Latency Network Action (DLNA): used to indicate
deterministic latency network action for MPLS data plane.
3. DetNet DLNA Option
3.1. Queuing delay
[RFC8655] provides the architecture for deterministic networking
(DetNet) which enables the service delivery of DetNet flows with
extremely low packet loss rates and deterministic latency. The
forwarding sub-layer provides corresponding forwarding assurance but
can not provide the deterministic latency (including bounded latency,
low packet loss and in-order delivery). As described at [RFC9320],
the end-to-end bounded latency for one DetNet flow is the sum of
delay bound of non-queuing and queuing processing latency. The delay
bound for non-queuing processing may include output delay, link
delay, frame preemption delay, and processing delay, the delay bound
for queuing processing may include regulator delay, queuing delay.
It is assumed that the delay of non-queuing processing is fixed or be
ignorable, the delay of queuing processing is variable. To realize
the guarantee of bounded latency service it is important to select
right queuing methodology applied to specific applications and carry
necessary queuing delay information for computation of end-to-end
latency.
Song, et al. Expires 18 April 2024 [Page 4]
Internet-Draft MPLS Encapsulation for DLNA October 2023
3.2. DLNA Option
The DetNet data plane encapsulation in transport network with MPLS
data plane is specified in [RFC8964].
[I-D.xiong-detnet-data-fields-edp] has proposed a commom DetNet data
fields for enhanced DetNet data plane and defined a DLNA option to
carry queuing-based metadata.This document provides additional
encapsulation for the DLNA in MPLS data plane.
The DetNet routers in data plane perform MPLS forwarding functions to
choose a feasible way with sufficient network resources for the
incoming packets, and makes right selection on the queuing or
scheduling mechanisms applied for specific DetNet flows to satisfy
strict QoS criteria in the forwarding output port. The information
for the queuing or scheduling mechanisms are carried in DetNet DLNA
header. Refer to [I-D.stein-srtsn], considering the time latency
information are processed per hop so the time latency informations
(such as deadline time, cycle identify, etc.) of each DetNet node for
DetNet flows are expected to be carried as a set of lists of LSEs in
MPLS data plane.
4. MPLS Extension for DLNA
4.1. DetNet MPLS Header for DLNA
The DetNet MPLS header follows [RFC8964]. To support deterministic
bounded latency service this draft introduces 2 options to carry
DetNet DLNA data using MPLS MNA solutions. As shown in figure 1, the
MNA label is inserted to indicate the recognition of MPLS Network
Actions, the DetNet DLNA can be carried in or after MPLS Label Stack.
Option 1, the DetNet IS-DLNA are inserted to MPLS In-Stack
Option 2, the DetNet PS-DLNA are located to MPLS Post-Stack
The format for MPLS DetNet IS-DLNA follows MNA (MPLS Network Action)
encapsulation specified in [I-D.ietf-mpls-mna-hdr] and
[I-D.ietf-mpls-mna-fwk], which is comprised of a set of Label Stack
Entries (LSEs) that carry the DetNet DLNA Network Action Indicator
and Ancillary Data to perform DLNA actions for MPLS packets. The
format for MPLS DetNet PS-DLNA refers to [I-D.jags-mpls-ps-mna-hdr].
The detailed DetNet IS-DLNA and PS-DLNA encapsulation refers to the
following section in the draft.
Song, et al. Expires 18 April 2024 [Page 5]
Internet-Draft MPLS Encapsulation for DLNA October 2023
+---------------------------+
| DetNet App-Flow |
| Payload Packet |
+---------------------------+--\
| DetNet PS-DLNA (OPT 2) | \
+---------------------------+ |
| DetNet Control Word | |
+---------------------------+ |
| S-Label | | DetNet
+---------------------------+ | Data Plane
| DetNet IS-DLNA (OPT 1) | | MPLS Encapsulation
+---------------------------+ |
| MNA Label | |
+---------------------------+ |
| F-Label(s) | /
+---------------------------+--/
| Data-Link |
+---------------------------+
| Physical |
+---------------------------+
Figure 1: DetNet MPLS Header
4.2. MPLS In-Stack DLNA Network Action
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA Label = bSPL (TBA) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: bSP-Label Format
MNA Label:
A new bSPL value is to be assigned by IANA. It is used to indicate
the presence of the MPLS Network Action Sub-Stack (NASS). The
assignment for this field value refers to [I-D.ietf-mpls-mna-hdr].
The MPLS In-Stack Data encoding format for DLNA option is shown in
the figure 3. The format provides DLNA Indicator to describe the set
of the DLNA network action. Its detailed information is carried in
the following Ancillary Data for the present DLNA network action.
Song, et al. Expires 18 April 2024 [Page 6]
Internet-Draft MPLS Encapsulation for DLNA October 2023
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IS-DLNA=TBA1 | Flag |S| Data | NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| AD LSE1 |S| AD LSE1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| AD LSE2 |S| AD LSE2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... ... ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| AD LSEn |S| AD LSEn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS In-Stack Format for DLNA
IS-DLNA (7 bits): This is the first 7-bit value in the Label Field.
The value is used to indicate DLNA network action with In-Stack Data
and to be assigned by IANA as value TBA1.
Flag (16 bits): identifies the type of queuing mechanisms used in the
network. The queuing type format is defined in section 4.2 of
[I-D.xiong-detnet-data-fields-edp].
S (1 bit) : The Bottom of Stack [RFC3032].
Data (4 bits) : Reserved bits for future use.
NAL (4 bits): The DLNA action length. It indicates the number of AD
LSEs in the sub-stack.
The first bit in the Label field of the following AD LSEs MUST be set
to "1". As specified in [I-D.ietf-mpls-mna-hdr] this is to prevent
aliasing the label field with other bSPLs on the legacy routers.
Ancillary Data:
The 19-bit Label field and 4-bit TC field and 8-bit TTL field (except
S bit) in the additional LSEs are used to carry the Ancillary Data
for specific DLNA latency information.
The Ancillary Data LSE1 is expected to carry the latency information
DLNA option data defined in section 4.2.2 of
[I-D.xiong-detnet-data-fields-edp] of the edge DetNet node. Depend
on specific queuing mechanisms used in the network the DLNA field
length for the latency information for one DetNet node is variable.
The specific queuing (including cycle, deadline, etc.) data
encapsulation are described in [I-D.xiong-detnet-data-fields-edp].
Song, et al. Expires 18 April 2024 [Page 7]
Internet-Draft MPLS Encapsulation for DLNA October 2023
The first AD LSE is expected to carry the latency information for
edge DetNet node. When the length of latency information is more
than 32bits less than 64bits, both AD LSE1 and LSE2 are expected to
carry the latency information for edge DetNet node. In this case,
the DLNA option data of next hop is carried in AD LSE3 and LSE4.
Along the path of DetNet flows the AD LSE(n-1) and LSEn carry the
DLNA option data for the peer edge DetNet node. With the DetNet
flows are being forwarded in its output ports the corresponding node
latency information carried in DLNA options are processed hop by hop.
4.3. MPLS Post-Stack DLNA Network Action
There are some limitaions to use MPLS In-Stack Data for DLNA. For
example, the total length for In-Stack Data LSEs seems small (no more
than 16LSEs), but on the other hand the latency information of each
nodes (nodes number may be more than 16 in DetNet) along the path of
DetNet flows needs be carried in the MPLS sub-stack. Besides, HBH
scenario brings high packet overload and low encapsulation
efficiency. This document does not exclude MNA Post-Stack solution
for carrying DLNA.
The MPLS Post-Stack format for DLNA Network Action refers to
[I-D.ietf-mpls-mna-hdr] and [I-D.jags-mpls-ps-mna-hdr] and shown in
figure 4.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label=MNA bSPL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA Opcode | Ancillary Data (AD) |1|IHS|S| Res |U| NASL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|0 0 0 0| Sequence Number |d-CW
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|N N N N|Version| PS-MNA-LEN | TYPE = POST-STACK-MNA | TH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|<-+
|PS-DLNA=TBA2 | DLNA Ancillary Data |R|R| PS-DLNA-LEN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | D
| | L
~ DLNA Option and Ancillary Data ~ A
| | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Song, et al. Expires 18 April 2024 [Page 8]
Internet-Draft MPLS Encapsulation for DLNA October 2023
Figure 4: MPLS Post-Stack Format for DLNA
As specified at [I-D.ietf-mpls-mna-hdr], The header for In-Stack
Network Action encodes:
P (1 Bit) : This document sets the value to 1 to identify the
presence of Post-Stack Network Action.
IHS (2 Bit) : Indicates the combined scope of the In-Stack and the
Post-Stack Network Actions.
U (1 Bit) : Indicates the combined Unknown Action Handling of the In-
Stack and the Post-Stack Network Actions.
As specified at [I-D.jags-mpls-ps-mna-hdr], The header for Post-Stack
Network Action encodes:
Sequence Number: The format of DetNet Control Word (d-CW) refers to
[RFC8964].
NNNN (4 bits): This first nibble identifies the start of the Post-
Stack Network Actions. A new value can be assigned by IANA. Generic
Associated Channel (0001b) can be used instead. The assignment for
this field value is out of the scope of this draft.
Version (4 bits): This is Post-Stack MNA version.
PS-MNA-LEN (8 bits): Post-Stack MNA Total Length in words. This
excludes the Post-Stack Top header.
TYPE (16 bits): Type is set to POST-STACK-MNA. In case of DetNet
MPLS, this is DLNA Type.
PS-DLNA (7 bits): Post-Stack Network Action Opcode. The value is
used to indicate DLNA network action with Post-Stack Data and to be
assigned by IANA as value TBA2.
DLNA Ancillary Data (16 bits): Post-Stack Ancillary Data associated
with the DLNA.
R (2 bits): Reserved bits.
PS-DLNA-LEN (7 bits): Post-Stack DLNA Network Action Length. The
number of LSEs of the following Ancillary Data.
The MPLS DLNA Network Action encapsulation with Post-Stack Data
refers to the latest MPLS WG discussions and follows the encoding
principles of the MNA Post-Stack Data speicified at MPLS WG.
Song, et al. Expires 18 April 2024 [Page 9]
Internet-Draft MPLS Encapsulation for DLNA October 2023
5. IANA Considerations
This document requests two new IANA-managed code-points for DetNet
application processing. IANA maintains the "In-Stack MNA Opcode"
registry when created from IANA request in [I-D.ietf-mpls-mna-hdr].
IANA is requested to allocate a value for In-Stack Network Action
Opcode for DLNA application from this registry:
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| TBA1 | IS-DLNA | this document |
+-------+-------------+---------------+
Table 1: In-Stack DLNA Network
Action Opcode
IANA maintains the "Post-Stack MNA Opcode" registry when created from
IANA request in [I-D.jags-mpls-ps-mna-hdr]. IANA is requested to
allocate a value for Post-Stack Network Action Opcode for DLNA
application from this registry:
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| TBA2 | PS-DLNA | this document |
+-------+-------------+---------------+
Table 2: Post-Stack DLNA Network
Action Opcode
6. Security Considerations
Security considerations for DetNet are covered in the DetNet
Architecture RFC8655 and DetNet Security Considerations [RFC9055].
MPLS security considerations are covered in [RFC8964], [RFC3031],
[RFC3032]. These security considerations also apply to this
document. The MNA security considerations speicified at
[I-D.ietf-mpls-mna-hdr] and [I-D.jags-mpls-ps-mna-hdr] are also
applicable to the procedures defined in this document.
7. Acknowledgements
The authors would like to acknowledge Shaofu Peng for his thorough
review and very helpful comments.
8. References
Song, et al. Expires 18 April 2024 [Page 10]
Internet-Draft MPLS Encapsulation for DLNA October 2023
8.1. Normative References
[I-D.ietf-mpls-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.
Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",
Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-
03, 6 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-hdr-03>.
[I-D.jags-mpls-ps-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Li, T., and J.
Dong, "Post-Stack MPLS Network Action (MNA) Solution",
Work in Progress, Internet-Draft, draft-jags-mpls-ps-mna-
hdr-00, 10 March 2023,
<https://datatracker.ietf.org/doc/html/draft-jags-mpls-ps-
mna-hdr-00>.
[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>.
[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
S., and J. Korhonen, "Deterministic Networking (DetNet)
Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
2021, <https://www.rfc-editor.org/info/rfc8964>.
8.2. Informative References
[I-D.dang-queuing-with-multiple-cyclic-buffers]
Liu, B. and J. Dang, "A Queuing Mechanism with Multiple
Cyclic Buffers", Work in Progress, Internet-Draft, draft-
dang-queuing-with-multiple-cyclic-buffers-00, 22 February
2021, <https://datatracker.ietf.org/doc/html/draft-dang-
queuing-with-multiple-cyclic-buffers-00>.
[I-D.ietf-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions Framework", Work in Progress, Internet-
Draft, draft-ietf-mpls-mna-fwk-04, 5 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-04>.
Song, et al. Expires 18 April 2024 [Page 11]
Internet-Draft MPLS Encapsulation for DLNA October 2023
[I-D.peng-6man-deadline-option]
Peng, S., Tan, B., and P. Liu, "Deadline Option", Work in
Progress, Internet-Draft, draft-peng-6man-deadline-option-
01, 11 July 2022, <https://datatracker.ietf.org/doc/html/
draft-peng-6man-deadline-option-01>.
[I-D.stein-srtsn]
Stein, Y. J., "Segment Routed Time Sensitive Networking",
Work in Progress, Internet-Draft, draft-stein-srtsn-01, 29
August 2021, <https://datatracker.ietf.org/doc/html/draft-
stein-srtsn-01>.
[I-D.xiong-detnet-data-fields-edp]
Xiong, Q., Liu, A., Gandhi, R., and D. Yang, "Data Fields
for DetNet Enhanced Data Plane", Work in Progress,
Internet-Draft, draft-xiong-detnet-data-fields-edp-01, 10
July 2023, <https://datatracker.ietf.org/doc/html/draft-
xiong-detnet-data-fields-edp-01>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[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>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>.
[RFC9320] Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J.,
and B. Varga, "Deterministic Networking (DetNet) Bounded
Latency", RFC 9320, DOI 10.17487/RFC9320, November 2022,
<https://www.rfc-editor.org/info/rfc9320>.
Song, et al. Expires 18 April 2024 [Page 12]
Internet-Draft MPLS Encapsulation for DLNA October 2023
Authors' Addresses
Xueyan Song
ZTE Corp.
China
Email: song.xueyan2@zte.com.cn
Quan Xiong
ZTE Corp.
China
Email: xiong.quan@zte.com.cn
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Song, et al. Expires 18 April 2024 [Page 13]
