| Internet-Draft | PREOF IOAM for DetNet Service Sub-layer | October 2024 |
| Qian, et al. | Expires 17 April 2025 | [Page] |
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.¶
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 17 April 2025.¶
Copyright (c) 2024 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 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.¶
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.¶
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 [RFC9551]. 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.¶
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.¶
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.¶
The proposed PREOF IOAM TRACE is a method of active OAM for DetNet.¶
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.¶
+------------E1-------------+
| P1 | P5 |
| | |
+----+ | | | +----+
|Head|----R1 +----+P4 E2----O1---+Tail|
+----+ | | | P6 +----+
| | |
| P2 | P3 |
+-------R2---------- -------+
<---------------DetNet OAM domain--------------->
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.¶
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.¶
OAM header within the PREOF-TRACE packet carries fields for packet identification, trace type description and necessary auxiliary information such as the serial number.¶
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 [RFC9546].¶
The PREOF-TRACE flag uses one bit to identify the OAM packet as a PREOF-TRACE packet.¶
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.¶
The Node ID field takes an unique value to identify the DetNet node that originates the packet.¶
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.¶
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
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.¶
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.¶
The PREOF-RESPONCE packet encapsualtion should carry several features listed below:¶
1. The flow identification of the the PREOF-TRACE packet.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
TBA.¶
TBA.¶