Internet DRAFT - draft-qian-detnet-preof-ioam
draft-qian-detnet-preof-ioam
DETNET X. Qian
Internet-Draft Q. Xiong
Intended status: Standards Track F. Zhou
Expires: 25 March 2024 ZTE Corporation
22 September 2023
PREOF IOAM Method for Deterministic Network Service Sub-layer
draft-qian-detnet-preof-ioam-00
Abstract
This document proposes an active IOAM method to PREOF monitor and
troubleshoot for Deterministic Networking (DetNet) in its service
sub-layer. The method uses a special PREOF-TRACE message to collect
multiple types of information from the target flow's PREOF entities
and to record them in the packet, and uses a PREOF-RESPONCE message
to feed them back to the head node. It assists the DetNet to monitor
and maintain the PREOF for the traffic 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 25 March 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Qian, et al. Expires 25 March 2024 [Page 1]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. PREOF-TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. OAM Header . . . . . . . . . . . . . . . . . . . . . 6
5.1.1.1. OAM Distinguishing Nibble . . . . . . . . . . . . 7
5.1.1.2. PREOF-TRACE Flag . . . . . . . . . . . . . . . . 7
5.1.1.3. Serial Number . . . . . . . . . . . . . . . . . . 7
5.1.1.4. Node ID . . . . . . . . . . . . . . . . . . . . . 7
5.1.1.5. TRACE Type . . . . . . . . . . . . . . . . . . . 7
5.1.2. Data Field . . . . . . . . . . . . . . . . . . . . . 9
6. PREOF-RESPONCE . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 9
7. PREOF IOAM TRACE Procedures . . . . . . . . . . . . . . . . . 10
7.1. OAM Head Node . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Intermediate Node . . . . . . . . . . . . . . . . . . . . 10
7.3. OAM Tail Node . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Deterministic Networking (DetNet) provides the ability to carry
traffic flows with extremely low packet loss rates, assured latency,
limited jitter, and limited out-of-order delivery. The DetNet-
related data plane is decomposed into a forwarding sub-layer and a
service sub-layer, which is described in [RFC8655] [RFC8938]. The
forwarding sub-layer leverages traffic engineering mechanisms and
provides congestion protection. The service sub-layer provides
DetNet service protection and reordering.
Qian, et al. Expires 25 March 2024 [Page 2]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
The DetNet service sub-layer includes the Packet Replication Function
(PRF), Packet Elimination Function (PEF), and Packet Ordering
Function (POF) entities. These functions can be enabled in a DetNet
edge node, relay node, or end system. The collective name for
PRF/PEF/POF is PREOF as per [RFC8655].
OAM is expected to support monitoring and troubleshooting PREOF
within the domain [I-D.ietf-detnet-oam-framework]. An on-demand OAM
method for particular PREOF node is described in
[I-D.varga-detnet-service-sub-layer-oam]. That method is referred to
as "DetNet PING", which is an in-band OAM approach, i.e., the OAM
packets follow precisely the same path as the data packets of the
corresponding DetNet flow(s). The OAM packets provide DetNet service
sub-layer specific information such as: 1) Identity of a DetNet
service sub-layer node. 2) Discover Ingress/Egress flow-specific
configuration of a DetNet service sub-layer node. 3) Detect the
status of the flow-specific service sub-layer function.
This document proposes another method for detecting and
troubleshooting PREOF entities for the targeted DetNet traffic flow
(which is briefly called traget flow in following content) in DetNet
service sub-layer. This method designs PREOF-TRACE and PREOF-
RESPONCE messages. The PREOF-TRACE message sent by the OAM head node
is transplanted from the target flow. So its behavior in forwarding
sublayer is equal to that of the traffic flow. Relay nodes those
have DetNet service sub-layer in the forwarding path recognize PREOF-
TRACE message, and append records into PREOF-TRACE message only when
they run PRF/PEF/POF entities for that flow. The recorded content
includes the identity, attributes, status of the functional entity
and other information about interface, time, queue, etc. When the
PEF node eliminates redundant replicas, or when the PREOF-TRACE
message reaches its destination, a PREOF-RESPONCE message containing
all information collected along the way of the PREOF-TRACE message
will be generated and sent back to the OAM head node. The PREOF-
RESPONCE message is also generated by PEF nodes and carrys the
current replica count value.
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.
Qian, et al. Expires 25 March 2024 [Page 3]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
3. Terminology
* IOAM: In situ Operations, Administration and Maintenance.
* PRF: Packet Replication Function. It divides a DetNet flow into
multiple DetNet member flows by replicating packets and sending
them out with different egress interfaces.
* PEF: Packet Elimination Function. It eliminates duplicated
packets of a DetNet flow based on the sequencing information and a
history of received packets. The output of the PEF is always a
single packet.RIB: Routing Information Base.
* POF: Packet Ordering Function. It uses the sequencing information
to reorder a DetNet flow's packets that are received out of order.
* PREOF: A collective name for Packet Replication, Elimination, and
Ordering Functions.
* PREOF-TRACE: A message used to collect information on all PREOF
entities along its way to the destination.
* PREOF-RESPONCE: A message used to postback collected information
about PREOF entities to the head node.
* PREOF IOAM TRACE: an active IOAM method for DetNet PREOF that
appends collected information in the PREOF-TRACE packet and
postbacks in the PREOF-RESPONCE packet.
4. Overview
The proposed PREOF IOAM TRACE is a method of active OAM for DetNet.
Qian, et al. Expires 25 March 2024 [Page 4]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
For the target flow, the PREOF IOAM TRACE uses the message
transmission method by sending a "PREOF-TRACE" message and accepting
its "PREOF-RESPONCE" message to monitor and troubleshoot PREOF
ability. At the beginning, a "PREOF-TRACE" message is sent from the
head node. The outer part of PREOF-TRACE carries the same IP header
(for IP data plane) or MPLS label (for MPLS data plane) as the
service message. The inner part of PREOF-TRACE carries a header
containing fields such as "PREOF-TRACE Flag", dedicated "Serial
Number", "TRACE Type" as well as "Data Field" used to record running
information of all encountered PREOF functional entities along the
way. PREOF-TRACE follows exactly the same forwarding way and the
same replication, elimination and ordering behaviors as the DetNet
flow. Accordingly, information about location, attributes, status
and other items concerned by networks' operator for PREOF entity in
the forwarding path will be recorded into the data field as a list,
in accordance with the specification carried by TRACE type.
When the PEF node eliminates redundant "PREOF-TRACE" copies, or when
the tail node receives the "PREOF-TRACE" message, a "PREOF-RESPONCE"
message will be returned, which carries the flow identification, node
identification, sequence number of the message and all records in
data field of the "PREOF-TRACE" message.
Figure 1 shows an instance of PREOF IOAM TRACE. There are two PRF
entities (R1, R2), two PEF entites(E1, E2) and one POF entity(O1)
applied for the target flow in the DetNet OAM domain. P1, P2 to P6
are forwarding paths between two PREOF entities..
For this instance, Every PREOF-TRACE packet from the head node is
replicated by R1 into two packets: pkt1(along P1) and pkt2(along P2).
The pkt2 is replicated by R2 into two packets: pkt2(along P2,P3) and
pkt3(along P2,P4). For E1 that receives pkt1 and pkt3, it is
supposed that pkt1 is accept and forwarded ahead while pkt3 is
discarded. For E2 that receives pkt1(along P1,P5) and pkt2(along
P2,P3), it is supposed that pkt2 is accept and forwarded ahead while
pkt1 is discarded. At O1, PREOF-TRACE packets are reorderd by their
serial numbers.
At the moment when E1 decides to discard pkt3, E1 generates a PREOF-
RESPONCE packet containing historic records(about R1,R2) carried in
pkt3 and current record of E1, then sends it back to the head node.
When the tail node receives pkt2, it generates a PREOF-RESPONCE
packet containing all historic records(about R1,R2,E2,O1) carried in
pkt2 and sents it back to the head node.
Qian, et al. Expires 25 March 2024 [Page 5]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
+------------E1-------------+
| P1 | P5 |
| | |
+----+ | | | +----+
|Head|----R1 +----+P4 E2----O1---+Tail|
+----+ | | | P6 +----+
| | |
| P2 | P3 |
+-------R2---------- -------+
<---------------DetNet OAM domain--------------->
Figure 1: an instance of PREOF IOAM TRACE
5. PREOF-TRACE
The PREOF-TRACE message collects items including the location,
attributes, status, configuration and other information of the
entities that provide PRF, PEF, or POF for the target flow when it
passes through the OAM domain. Besides, some information in the
forwarding sub-layer can also be collected.
5.1. Encapsulation
Since PRF, PEF, and POF entities are deployed for the target flow,
the OAM packets should be associated with the target flow. So for
PREOF-TRACE's encapsulation, it is necessary to carry a flow
identifier which is consistent with the targeted DetNet traffic flow.
That means, PREOF-TRACE should carry the same S-label in the DetNet
encapsulation as described in [RFC8938] for MPLS data plane. While
for IP data plane, PREOF-TRACE should carry the six tuples in the
DetNet encapsulation (in cases where port information cannot be
obtained, triples or binaries can also be used, as described in
[RFC8938] [RFC8939]). Furthermore, in order to ensure that PREOF-
TRACE packets and associated DetNet traffic packets are treated
equally by all DetNet network nodes and follow the same path in the
forwarding sub-layer, the outer encapsulation of PREOF-TRACE packets
should be the same as that of DetNet traffic packets.
The PREOF-TRACE packet should encapsulates an OAM header and data
field.
5.1.1. OAM Header
OAM header within the PREOF-TRACE packet carries fields for packet
identification, trace type description and necessary auxiliary
information such as the serial number.
Qian, et al. Expires 25 March 2024 [Page 6]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
5.1.1.1. OAM Distinguishing Nibble
The OAM Distinguishing nibble is used to distinguish an OAM packet
from a DetNet traffic packet in MPLS data plane. These four bits are
0001 for PREOF-TRACE packet, which is consistent to the section 4.1
of [I-D.ietf-detnet-mpls-oam].
5.1.1.2. PREOF-TRACE Flag
The PREOF-TRACE flag uses one bit to identify the OAM packet as a
PREOF-TRACE packet.
5.1.1.3. Serial Number
The Serial Number field carrys a dedicated serial number referenced
for PREOF. It's a number represented by a set of consecutive bits,
and the sequence code in the next PREOF-TRACE packet is added by 1 to
that in the previous message.
5.1.1.4. Node ID
The Node ID field takes an unique value to identify the DetNet node
that originates the packet.
5.1.1.5. TRACE Type
The TRACE Type field specifies which data types are used the data
field. The structure of this field is bit-map, and each bit within
the map has a particular regulation, just as follows:
ID-bit: When set, indicates the PREOF entity to record its identity.
FT-Bit: When set, indicates the PREOF entity to record its function
type (RPF, PEF or POF).
RT-bit: When set, indicates the PREOF entity to record its location
(eg. the identity of the router).
Time-bit: When set, indicates the PREOF entity to record a timestamp
on the moment of PEF/PEF/POF process ending.
RN-bit: When set, indicates the PRF entity to record the number of
replication.
SN-bit: When set, indicates the PEF entity to record the current
value of the counter for the packet with the same serial number.
Qian, et al. Expires 25 March 2024 [Page 7]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
QL-bit: When set, indicates the PRF entity to record the current
length of the reordering queue.
TRACE Type may also define some bits to collect information from the
forwarding sub-layer, so as to help the DetNet flow to detect
characteristics or performances of its member flows, for example, to
detect delay differences among different member flows between PRF and
PEF nodes.
IIFI-bit: When set, indicates the PREOF entity to record the ingress
interface information.
EIFI-bit: When set, indicates the PREOF entity to record the egress
interface information.
IIFT-bit: When set, indicates the PREOF entity to record the time
when the packet reaches the ingress interface.
EIFT-bit: When set, indicates the PREOF entity to record the time
when the packet leaves the egress interface.
EIFS-bit: When set, indicates the PREOF entity to record the timeslot
or cycle id on the egress interface.
EIFQ-bit: When set, indicates the PREOF entity to record the queue
information on the egress interface.
More bits can be regulated in the TRACE type in the future.
Figure 2 shows an instance of TRACE Type bit-map structure.
bit0 1 2 3 4 5 6 7 8 9 10 11 12
+---+---+---+---+---+---+---+---+---+---+---+---+---+........+
| | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+........+
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | | | \ /
ID | | | RN| | | | EIFI | | EIFS | reserved
FT | | SN | | | | EIFQ bits
RT | QL | IIFT |
Time IIFI EIFT
Figure 2: an instance of TRACE Type bit-map structure
Qian, et al. Expires 25 March 2024 [Page 8]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
5.1.2. Data Field
Data field is the most important field for this OAM packet. It
consists of a series of record lists. Each record list is written by
the PREOF entity through which the PREOF-TRACE flows. The recorded
items are: identification of the node; Identification, attributes,
and status information of PRF/PEF/POF entities; Interface parameters,
time parameters, queue parameters and other useful information for
OAM. Suggestions for information collection are as follows:
1. If PRF entity is provided for the flow at the relay node, PRF
entity should record the node ID, entity ID, entity attributes (PRF),
and necessary information indicated by the trace type field into the
data field of the PREOF-TRACE packet.
2. If PEF entity is provided for the flow at the relay node, PEF
entity should record the node ID, entity ID, entity attributes (PEF),
and necessary information indicated by the trace type field into the
data field of the PREOF-TRACE packet.
3. If POF entity is provided for the flow at the relay node, POF
entity should record the node ID, entity ID, entity attributes (POF),
and necessary information indicated by the trace type field into the
data field of the PREOF-TRACE packet.
6. PREOF-RESPONCE
The PREOF-RESPONCE message transmits all information of PREOF
entities along the way collectted by the PREOF-TRACE message to the
OAM head node.
The PREOF-RESPONCE packet should be generated for two circumstances
below:
1. When the OAM tail node (it should be a relay node or an end
system which owns DetNet service-sublayer) receives a PREOF-RESPONCE
packet.
2. When a PEF node receives an redundant replica of PEROF-TRACE
packet.
6.1. Encapsulation
The PREOF-RESPONCE packet encapsualtion should carry several features
listed below:
1. The flow identification of the the PREOF-TRACE packet.
Qian, et al. Expires 25 March 2024 [Page 9]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
2. The serial number of the PREOF-TRACE packet.
3. The node ID of the PREOF-TRACE packet.
4. The trace type field of the PREOF-TRACE packet.
5. Whole information recorded in the data field of the PREOF-TRACE
packet. Direct copy is suitable while appropriate compression is
also considerable, which is out of this document.
6. A bit of PREOF-RESPONCE flag is added in the packet.
7. When a PEF node generates the PREOF-RESPONCE packet, it should
set SN-bit of the trace type field and record the counter value for
the replica.
7. PREOF IOAM TRACE Procedures
The head node of PREOF IOAM TRACE is an end system or an relay node
within the DetNet domain, and an IOAM encapsulating node in the OAM
domain. The tail node of PREOF IOAM TRACE is an end system or an
relay node within the DetNet domain, and an IOAM decapsulating node
in the OAM domain. Once It is confirmed that the tail node has no
less than one reachable route to the head node, DetNet can perform
PREOF IOAM TRACE with following procedures:
7.1. OAM Head Node
1. The head node generates PREOF-TRACE packets for trageted DetNet
service flow and sends PREOF-TRACE packets to the tail node within
the OAM domain. A serial number is allocated in each packet.
2. For every PREOF-TRACE packet, the head node waits for its PREOF-
RESPONCE packet carrying the same serial number.
3. The head node receives PREOF-RESPONCE packets and extracts out
information about all PREOF entities.
There is a state machine for the head node to wait and receive PREOF-
RESPONCE packets which are normally more than one when PEF entity
exists.
7.2. Intermediate Node
The procedures for intermediate node depend on following cases:
Case 1: the intermediate node is a DetNet transit node which only
works on forwarding sub-layer.
Qian, et al. Expires 25 March 2024 [Page 10]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
For case 1, the intermediate node directly forwards the packet to the
next hop without processing its inner OAM part.
Case 2: the intermediate node is a DetNet relay node which works on
service sub-layer, but it is not a PREOF entity for the trageted
DetNet service flow.
For case 2, the intermediate node directly forwards the packet to the
next hop without processing its inner OAM part.
Case 3: the intermediate node is a DetNet relay node which runs PRF
for the trageted DetNet service flow.
For case 3, the intermediate node performs the following steps:
1. It copys the PREOF-Trace packet, including the OAM serial number,
and adds a PRF record into the data field of each copied message
according to the trace type field.
2. It sends replicas through multiple egress interfaces to multiple
next hops, complying with the rules pre-defined in the PRF entity.
Case 4: the intermediate node is a DetNet relay node which runs PEF
for the trageted DetNet service flow..
For case 4, the intermediate node performs the following steps:
1. It counts the number of received replicas locally based on the
serial number of PREOF-TRACE packet.
2. If the count value is 1, it adds a PEF record in the data area of
the PREOF-TRACE message according to the trace type field, and
continues forwarding the PREOF-TRACE packet.
3. If the count value is equal to or bigger than 2, it generates a
PREOF-RESPONCE packet containing all historical trace records, one
current PEF record, as well as the count value in step 1.
4. It sends the PREOF-RESPONCE packet to the OAM head node, while
the PREOF-TRACE replica is discarded.
Case 5: the intermediate node is a DetNet relay node which runs POF
for the trageted DetNet service flow.
For case 5, the intermediate node performs the following steps:
1. It adds a POF record to the data field of the PREOF-TRACE packet
according to the trace type field.
Qian, et al. Expires 25 March 2024 [Page 11]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
2. PREOF-TRACE packets out of order are reordered in the queue by
their serial numbers.
3. PREOF-TRACE packets are sent to the next hop in order.
7.3. OAM Tail Node
When the tail node receives PREOF-TRACE, it generates a PREOF-
RESPONCE packet whose content is described in section 5, and sends it
back to the OAM head node.
8. Security Considerations
TBA.
9. IANA Considerations
TBA.
10. References
10.1. Normative References
[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>.
10.2. Informative References
[I-D.ietf-detnet-mpls-oam]
Mirsky, G., Chen, M., and B. Varga, "Operations,
Administration and Maintenance (OAM) for Deterministic
Networks (DetNet) with MPLS Data Plane", Work in Progress,
Internet-Draft, draft-ietf-detnet-mpls-oam-13, 6 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
detnet-mpls-oam-13>.
Qian, et al. Expires 25 March 2024 [Page 12]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
[I-D.ietf-detnet-oam-framework]
Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos,
C. J., Varga, B., and J. Farkas, "Framework of Operations,
Administration and Maintenance (OAM) for Deterministic
Networking (DetNet)", Work in Progress, Internet-Draft,
draft-ietf-detnet-oam-framework-08, 1 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
oam-framework-08>.
[I-D.varga-detnet-service-sub-layer-oam]
Varga, B., Farkas, J., and G. Mirsky, "Deterministic
Networking (DetNet): OAM Functions for The Service Sub-
Layer", Work in Progress, Internet-Draft, draft-varga-
detnet-service-sub-layer-oam-03, 25 July 2022,
<https://datatracker.ietf.org/doc/html/draft-varga-detnet-
service-sub-layer-oam-03>.
[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>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>.
Authors' Addresses
Xiaocong Qian
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: qian.xiaocong@zte.com.cn
Quan Xiong
ZTE Corporation
No.6 Huashi Park Rd
Wuhan
Hubei, 430223
China
Email: xiong.quan@zte.com.cn
Qian, et al. Expires 25 March 2024 [Page 13]
Internet-Draft PREOF IOAM for DetNet Service Sub-layer September 2023
Fenlin Zhou
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: zhou.fenlin@zte.com.cn
Qian, et al. Expires 25 March 2024 [Page 14]
