GB/T 44887.11-2024IPv6 evolution technical requirements-Part 11: IPv6 in-situ flow information telemetry (English PDF)

1 Scope

This document specifies the technical requirements for IPv6 in-situ flow information telemetry, and describes the architecture of in-situ flow information telemetry, its key technologies, and the data encapsulation formats and methods.

This document applies to the measurement of data-plane in-situ flow information in multi-service bearer scenarios, and is used for the development, testing and deployment of the in-situ flow information telemetry function of IP network devices.

2 Normative references

The contents of the following documents constitute indispensable provisions of this document through normative reference in the text. For dated references, only the version corresponding to that date applies to this document; for undated references, the latest version (including all amendments) applies to this document.

IETF RFC 8200 Internet protocol, version 6 (IPv6) specification; IETF RFC 9341 Alternate-marking method.

3 Terms and definitions

The following terms and definitions apply to this document.

3.1 in-situ flow information telemetry: a telemetry technique that marks the characteristics of real service traffic in the network so that network performance indicators are measured directly.

3.2 postcard-based telemetry: an in-band flow quality measurement method that, along the packet forwarding path, collects data hop by hop and reports it hop by hop.

3.3 passport mode telemetry: an in-band flow quality measurement method that, along the packet forwarding path, collects data hop by hop and reports it at the tail node. Note: in passport mode telemetry, the flow quality information collected hop by hop is encapsulated in the data packet and forwarded with the flow.

3.4 alternate marking (colouring): a quality detection technique that marks service packets directly in order to measure indicators such as packet loss and delay.

3.5 in-situ operations, administration and maintenance: an OAM implementation method that carries network operation and measurement information within service packets and forwards it along the service path.

4 Abbreviations

The following abbreviations apply to this document. ACL: access control list. BGP: border gateway protocol. DNP: dynamic network probe. DoH: destination option header. DSCP: differentiated services code point. FIEH: flow instruction extension header. IFIT: in-situ flow information telemetry. IGP: interior gateway protocol. IOAM: in-situ OAM. IPFIX: IP flow information export. OAM: operations, administration and maintenance. PBT: postcard-based telemetry. PMT: passport mode telemetry. SRH: segment routing header. SRv6: segment routing over IPv6. VxLAN: virtual extensible local area network.

5 Architecture of in-situ flow information telemetry

In-situ flow information telemetry (IFIT) provides an architecture and a method for network performance measurement that achieve automated quality measurement of high-performance flow information. Its architecture is shown in Figure 1 and mainly comprises the IFIT application and management system, the IFIT controller, and the forwarding devices inside the IFIT domain.

IFIT application and management system: responsible for the input of the measurement intent and the presentation of the measurement results. On one side it receives the network quality measurement intent coming from service applications and from operation and maintenance systems, and converts it into a network configuration policy that is delivered to the IFIT controller; the IFIT network configuration policy includes the flow objects to be measured, the performance indicators to be collected and the way the test data is to be reported. On the other side it receives the IFIT quality measurement data and the analysis results reported by the collection and analysis function module of the IFIT controller, and presents them visually.

IFIT controller: it contains two functional components, the network configuration function module and the collection and analysis function module. The network configuration function module supports gRPC and UDP protocol interfaces, receives the network configuration policy delivered by the IFIT application and management system, and converts it into device configuration commands for monitoring and quality measurement that are delivered to the network forwarding devices. The collection and analysis function module receives and stores the telemetry quality measurement data reported by the network devices and performs computation and analysis of the measurement data, such as forwarding delay and packet loss analysis and fault location; at the same time it reports the relevant measurement data and analysis results to the IFIT application and management system. The collection and analysis function module supports the JSON encoding format, supports a structured way of describing data, and supports standardized data encoding and convenient format conversion.

Forwarding devices inside the IFIT domain: network devices that support the IFIT function. During flow quality measurement they are divided, according to their IFIT role, into IFIT head node, IFIT transit node and IFIT tail node. The IFIT head node encapsulates the IFIT instruction header into the data packets of the designated flow object. The IFIT transit node collects measurement data according to the IFIT instruction and reports it to the IFIT controller as required. The IFIT tail node extracts the quality measurement data carried in the data packet and reports it to the IFIT controller, and at the same time removes the IFIT instruction header from the data packet before forwarding it.

Forwarding devices inside the IFIT domain shall support: the IFIT function, that is the encapsulation and decapsulation of the IFIT packet header and the addition and reading of the IFIT collected information; the flow identification function, identifying the traffic to be monitored or measured by means of ACLs or of algorithms such as Count-Min Sketch; the gRPC protocol, the JSON encoding format and the YANG modelling language, so that the collected flow information is reported quickly; the IPFIX protocol, for standardized export of IP flow information; pre-processing of the IFIT collected data, such as removal of redundant data, buffered batch processing and subscription to abnormal events; the dynamic network probe (DNP) technique, which achieves on-demand information probing through flexible configuration of the measurement data; the postcard mode and passport mode ways of reporting IFIT data; the unified mode and pipe mode ways of processing IFIT data.

In the implementation of IFIT, the IFIT controller configures the forwarding nodes and collects and analyses the quality measurement data, so that the forwarding quality information of the network flows is monitored in real time; the IFIT application and management system dynamically adjusts, on the basis of the measurement results, the flow quality measurement indicators and parameters that are monitored or measured, so that the quality measurement information is adjusted and optimized according to the real-time operating state of the network and network operation becomes finer grained.

The IFIT architecture supports several techniques for collecting in-situ flow information and for exporting data, so as to suit the measurement needs of different networks and applications. For the collection of performance test data, IFIT can be implemented in postcard-based telemetry (PBT) mode or in passport mode telemetry (PMT); for delimiting packet loss of an application, the PBT mode is required. In addition, IFIT can further integrate several data-plane monitoring and measurement techniques, providing network operation and maintenance with a complete method for automated quality measurement of data-plane flow information.

6.1 General

The key IFIT technologies mainly include intelligent flow selection, intelligent data reporting, dynamic network probing, and encapsulation and tunnelling. Intelligent flow selection achieves quality measurement of a specific flow for a specific service need; intelligent data reporting improves the transmission efficiency of the collected information on the basis of redundancy removal and efficient compression; dynamic network probing allows the measurement information to be customized flexibly and probes to be deployed on demand, either programmable hardware probes or hardware plus programmable software probes, improving the efficiency of network quality measurement; the use of different encapsulation and tunnelling techniques achieves end-to-end performance measurement in cross-domain network scenarios.

The IFIT application and management system needs to designate the corresponding measurement technique on the basis of the measurement needs of the application or of the operation and maintenance, and to deliver the relevant policy to the IFIT head node through the IFIT controller. On the basis of the configuration instruction the IFIT head node selects the target flow to be monitored or measured and the set of measurement information, and determines the corresponding header encapsulation format and tunnel mode according to the type of bearer layer. The IFIT forwarding devices collect the relevant measurement data according to the configuration instruction and determine the reporting mode of the measurement data, so that in-situ flow quality measurement is achieved.

In addition, on the basis of the real-time operating state of the network and of the services, the IFIT application and management system shall, without affecting the normal operation of the network, dynamically designate the loading or unloading of the DNP, adjust the measurement technique used, the flow selection policy and the reporting mode of the measurement data, and deliver the relevant network configuration policy to the IFIT controller. The IFIT controller enables the IFIT function of the forwarding devices by means of the command line, NETCONF or control protocol extensions such as BGP and IGP extensions, so that flow selection, DNP probing and policy information reporting are achieved, and it is able to report the information collected by the IFIT network nodes to the IFIT application and management system through techniques such as IPFIX over UDP or gRPC.

6.2 Technical requirements for intelligent flow selection

Intelligent flow selection is the key technique for the quality measurement of a specific service, and shall meet the following technical requirements.

The data forwarding plane supports the use of ACLs as the main method for identifying and selecting flows; for different service flows it supports the setting of different sampling rates and of different packet measurement indicators, and it supports enabling the IFIT measurement function on specific forwarding nodes.

It supports the full or partial acceptance or rejection, at any node, of data collection on the packets of a service flow, so that intelligent flow selection and monitoring data selection policies at service application level are achieved.

It supports the real-time dynamic adjustment of the flow selection and collection policy on the basis of the network load, the forwarding processing capability, the focus of the measurement and other criteria, so as to keep network performance and measurement needs in balance.

It supports the use of packet sampling on a designated flow, so as to lower the measurement overhead and avoid the overload of the network bearer capacity that applying IFIT to all packets of the designated flow could cause.

The IFIT controller is able to collect the indicators that measure network congestion, such as packet buffer size, delay and packet loss, and on the basis of this information and of the measurement requirements it supports the real-time dynamic adjustment of the sampling frequency of the IFIT measurement packets, so as to avoid network congestion.

6.3 Technical requirements for intelligent data reporting

As regards intelligent data reporting, the reporting of IFIT measurement data shall follow the technical requirements below.

Both the PMT and the PBT reporting modes are supported. In PMT mode every node on the service path encapsulates the telemetry quality measurement data inside the user data packet, until the IFIT tail node decapsulates it and reports the collected information to the IFIT controller. In PBT mode every node on the service path encapsulates the telemetry quality measurement data it has collected locally into an independent collection packet, which is reported directly to the IFIT controller.

The IFIT controller supports measuring and reporting the quality information of a service flow in real time with per-packet granularity, and supports using the available computing capacity of the network devices to remove redundancy from and compress the reported data, so as to reduce the transmission bandwidth of the reported data and lower the processing burden of the IFIT controller.

The use of binary-based data transmission encoding is supported, which greatly reduces the volume of transmitted data.

For the collection of information data whose real-time requirements are not high, the use of common techniques for removing repeated and redundant data and for compression is supported, so that data can be accumulated in a buffer in batches and then packed and reported.

The monitoring of abnormal network events by means of IFIT is supported. When a network device detects an anomaly, the description of the abnormal event by means of a policy and its reporting to the IFIT controller are supported, so that an abnormal event triggers the reporting of monitoring data.

The use of the common IP flow information export (IPFIX) technique for reporting the collected data is supported.

6.4 Technical requirements for dynamic network probing

In order to introduce sufficient flexibility and extensibility, IFIT shall use the dynamic network probe (DNP) technique and shall follow the technical requirements below: it supports enabling probes in different network planes for customized data collection; it supports loading into the data plane by incremental programming or configuration, for data generation, processing and aggregation.

Through on-demand probing IFIT not only optimizes data export but also customizes the probed information according to service needs.

6.5.1 Tunnelling techniques

IFIT shall support the unified mode and the pipe mode tunnelling techniques.

The IFIT unified mode is shown in Figure 2: the tunnel ingress node shall support copying the IFIT instruction header of the original data packet, for example an IPv6 packet, into the outer tunnel header, for example an SRv6 SRH option TLV, so that the IFIT instruction receives consistent treatment at the nodes inside the tunnel and at the nodes outside it and hop-by-hop quality measurement is achieved.

The IFIT pipe mode is shown in Figure 3: the tunnel ingress node shall process the IFIT instruction and perform the corresponding data collection. After the packet has entered the tunnel the IFIT instruction shall remain in the original packet and shall not be copied into the tunnel header, so that the IFIT information is transported transparently through the tunnel. After stripping the tunnel header the tunnel egress node shall continue to process the IFIT instruction. In the IFIT pipe mode the whole tunnel shall be treated as a single node.

6.5.2 Encapsulation and packet processing

In unified mode, three scenarios are distinguished according to where the IFIT domain begins and ends, and the encapsulation and packet processing in each scenario follow the relevant technical requirements.

Scenario 1: the IFIT domain begins and ends outside the tunnel, that is the tunnel lies entirely between the IFIT head node and the IFIT tail node; this is further divided according to whether the tunnel ingress node coincides with the IFIT head node and whether the tunnel egress node coincides with the IFIT tail node. Where the IFIT head node lies outside the tunnel, the IFIT header shall be encapsulated in the original data packet and processed. Where the IFIT head node is the tunnel ingress node, the IFIT header shall be encapsulated in the original data packet and processed, and at the tunnel ingress node the IFIT header of the original packet shall be copied and encapsulated in the outer tunnel encapsulation. Where the IFIT tail node lies outside the tunnel, the IFIT header shall be decapsulated and removed from the original data packet. Where the IFIT tail node is the tunnel egress node, the IFIT header in the tunnel header shall be processed in the normal way; after the tunnel header has been deleted and the original data packet restored, the IFIT header shall be copied and shall overwrite the IFIT header of the original data packet, and once IFIT processing has ended the IFIT header shall be removed from the original data packet.

Scenario 2: the IFIT domain begins and ends inside the tunnel. The IFIT header shall be encapsulated in the outer tunnel encapsulation and processed normally.

Scenario 3: the IFIT domain begins and ends at arbitrary nodes, that is the IFIT domain is configured to begin and end at any node. Where the IFIT head node lies outside the tunnel, the IFIT header shall be encapsulated in the original data packet. Where the IFIT head node is the tunnel ingress node, the IFIT header shall be encapsulated in the original packet and processed, after which the IFIT header of the original data packet shall be copied and encapsulated in the outer tunnel encapsulation while the IFIT header is removed from the original data packet. Where the IFIT head node lies inside the tunnel, the IFIT header shall be encapsulated in the outer tunnel encapsulation and processed. Where the IFIT head node is the tunnel egress node, the IFIT header shall be encapsulated in the outer tunnel encapsulation and processed, and when the tunnel header is removed the IFIT header shall be copied from the outer tunnel encapsulation and encapsulated in the original data packet. Where the IFIT tail node lies outside the tunnel, the IFIT header shall be decapsulated and removed from the original data packet. Where the IFIT tail node is the tunnel ingress node, the IFIT header shall be decapsulated and removed from the original data packet. Where the IFIT tail node lies inside the tunnel, the IFIT header shall be decapsulated and removed from the outer tunnel encapsulation. Where the IFIT tail node is the tunnel egress node, the IFIT header shall be decapsulated and removed from the outer tunnel encapsulation. Where the tunnel ingress node lies inside the IFIT domain, the IFIT header shall be decapsulated from the original data packet and re-encapsulated in the outer tunnel encapsulation. Where the tunnel egress node lies inside the IFIT domain, the IFIT header shall be decapsulated from the outer tunnel encapsulation and re-encapsulated in the original data packet.

In pipe mode the scenarios are as follows, and the encapsulation and packet processing in each scenario follow the technical requirements below. Scenario 1: the IFIT domain begins and ends outside the tunnel, including the cases in which the tunnel ingress node coincides with the IFIT head node and the tunnel egress node coincides with the IFIT tail node. In this scenario the IFIT header shall be encapsulated only in the original packet header and shall not be copied into the tunnel header. Inside the tunnel the IFIT header shall be invisible to the underlay network and shall not be processed. At the tunnel ingress node the IFIT header shall be processed before the tunnel header is encapsulated. At the tunnel egress node the IFIT header shall be processed after the tunnel header has been removed. The whole tunnel shall appear to the IFIT header as a single hop. Scenario 2: the IFIT domain begins and ends inside the tunnel; the IFIT header shall be encapsulated in the outer tunnel header and processed normally.

7.1 Alternate-marking (colouring) data field format

Following the network performance measurement method of alternate marking defined in IETF RFC 9341, switching the value (the colour) of the marking bit synchronizes the measurement data of different points of the network and thus divides the data flow into blocks. By counting the number of data packets of each traffic block and comparing the packet counts of different nodes, the packet loss ratio is measured accurately. In the same way, the alternation of the value (the colour) of the marking bit can serve as a time reference for calculating delay and jitter.

As shown in Figure 4, the alternate-marking data field contains a flow instruction header (FIH) and a flow instruction extension header (FIEH) that carry the basic information used for in-situ flow information telemetry, including the flow ID, the colouring indication bit, the type indication, the hop-by-hop detection, the flow direction, and the extension length and type.

The meaning of each field is as follows. Flow ID and Flow ID Ext: bit 0 to bit 19 and bit 32 to bit 51, used to identify a service flow uniquely; the flow identifier needs to be unique across the whole network within the detection domain. Where the device allocates the flow identifier, the Flow ID Ext field is pre-allocated and a unique value is assigned to each device, while the Flow ID is generated automatically by the device, which assigns an ID to each flow within the device and guarantees that it is locally unique, so that the flow identifier is unique across the whole network.

L: colouring mark for packet loss measurement. D: colouring mark for delay measurement, where 1 means that delay is to be measured and 0 means that it is not. R: reserved bit, kept for future use. Next Header: indicates the extension data type, that is whether an extension header is carried, with the value 0x00 meaning that no FIEH is carried, the value 0x09 meaning that an FIEH is carried, and the other values reserved.

E: hop-by-hop or end-to-end mode, where E equal to 1 means end-to-end mode. Fra: fragmentation mark, where Fra equal to 1 means that the subsequent fragments are not counted. F: forward flow flag, where F equal to 1 means a forward flow. Len: the length of the content excluding the first 4 bytes, expressed in units of 4 bytes.

Trace Type: metadata indication bits, a 16-bit bitmap supporting at most sixteen types of extension, such as timestamp, sequence and checksum, shown in Figure 5. Bit 0 set to 1 means that the timestamp is valid; bit 1 is a control field, used to carry in-situ control information such as reverse flow set-up and synchronization period; bit 2 set to 1 means that the sequence is valid; bit 3 set to 1 means that the checksum is valid; the other bits are reserved.

Timestamp: the timestamp, 6 bytes long, used to measure per-packet delay; the first 2 bytes give the part expressed in seconds and the last 4 bytes the part expressed in nanoseconds. DIP mask and SIP mask: the mask length of the destination IP address and of the source IP address.

P: set to 1 means valid, that is a reverse-flow ACL matching rule needs to be created for the flows matched by protocol number. SP: set to 1 means valid, that is a reverse-flow ACL matching rule needs to be created for the flows matched by transport layer source port number. DP: set to 1 means valid, that is a reverse-flow ACL matching rule needs to be created for the flows matched by transport layer destination port number.

V: indicates whether reverse flow monitoring needs to be established; V equal to 1 means that a reverse flow needs to be established. On a node where the automatic establishment of reverse flow monitoring has been enabled, when V equal to 1 is detected in a packet the node shall establish the reverse flow on its own initiative on the basis of the matching information of the forward flow, and shall allocate the reverse flow ID automatically.

DSCP: indicates whether the DSCP value matters when the reverse flow is created, DSCP equal to 1 meaning that it matters. T: for detection between PE and PE, T equal to 1 means that the detection points cover only the path from network-side interface to network-side interface, while T equal to 0 means that the detection points cover the path from user-side interface to user-side interface. Period: the synchronous reporting period, expressed in seconds. Sequence: 4 bytes long, used for out-of-order measurement. Checksum: the checksum, 4 bytes long, used to detect bit errors in the packet payload.

7.2.1 General

In-situ operations, administration and maintenance (IOAM) is a hybrid OAM technique: while a packet travels along a path between two points of the network, IOAM records operation and telemetry information in the packet. In order to suit different IOAM scenarios the IOAM data fields are classified in different ways, corresponding to different IOAM option types. Five IOAM option types are defined at present.

Pre-allocated trace option type: used to collect data hop by hop, with space for the node data reserved in advance in the option format. Incremental trace option type: used to collect data hop by hop, with no space reserved in advance in the option format, the packet header growing hop by hop. Proof-of-transit option type: used to verify that the path the packet has taken is consistent with the planned path. End-to-end option type: used to carry the information of the head node to the tail node. Direct exporting option type: used to collect data hop by hop, based on the postcard mode, reporting the data hop by hop without modifying the packet header.

7.2.2 Pre-allocated and incremental trace option types

The IOAM pre-allocated trace option and the IOAM incremental trace option have similar formats. Except where stated otherwise below, the internal format and the fields of these two trace options are entirely identical. Both trace options contain a fixed-size trace option header and a variable-length data space, called the node data list, in which the collected data is stored. Apart from the flags field and the remaining length field, an IOAM transit node shall not modify any field of the fixed-length trace option header. The pre-allocated and incremental trace option headers are shown in Figure 6, and the IOAM trace option data fields, which shall be aligned on 4 bytes, are shown in Figure 7.

Namespace-ID: the identifier of the IOAM namespace, 16 bits long. The value 0x0000 of the namespace identifier is defined as the default value. For any other namespace identifier that does not match one of the namespace identifiers configured on the node, the node shall not modify the content of the IOAM data fields.

NodeLen: a 5-bit unsigned number. This field indicates the length of the data added by each node, in units of 4 bytes, not including the length of the opaque state snapshot field, with the following requirements. If bit 22 of the IOAM trace type is not set, the node length indicates the actual length of the data added by each node. If bit 22 of the IOAM trace type is set, the actual length added by a node is the node length plus the length of the opaque state snapshot field, this length being expressed in units of 4 bytes. An IOAM encapsulating node shall set the node length field. A node that receives an IOAM pre-allocated or incremental trace option may rely on the value of the node length field, or may ignore the node length field and compute the node length from the bits of the IOAM trace type.

Flags: a 4-bit field. This document allocates one flag bit: bit 0 means overflow (the most significant bit). If there are not enough bytes to record the node data, the network element sets this bit to 1 and does not add any field to the IOAM trace option header. This allows transit nodes to skip any further processing of the option.

RemainingLen: a 7-bit unsigned number. This field defines the data space still available for recording node data before the node data list is considered to have overflowed, in units of 4 bytes. Assuming that the sender knows the minimum path MTU, the sender can set the initial value of the remaining length according to the number of bytes of node data that are allowed before the MTU is exceeded. A subsequent node is then able to make a simple comparison between the remaining length and the node length, together with the length of the opaque state snapshot if needed, in order to decide whether it can add data. When node data is added, the node shall reduce the value of the remaining length by the amount of data added. In the pre-allocated trace option the remaining length field is used to obtain the offset of the data space in which the node data entry is recorded: specifically, the node data entry is recorded starting from the remaining length minus the node length minus the size of the opaque snapshot, in units of 4 bytes. If the remaining length in a pre-allocated trace option exceeds the option length indicated by the preceding packet header, the node is not allowed to add any field.

IOAM-Trace-Type: a 24-bit identifier that specifies which data types are used in the node data list. The value of the IOAM trace type is a bitmap. The order in which the data fields are filled into each node data entry follows the bit order of the IOAM trace type field below. Bit 0 (the most significant bit), when set, means that the node data contains the hop limit and the node identifier in short format. Bit 1, when set, means that the node data contains the ingress interface identifier and the egress interface identifier in short format. Bit 2, when set, means that the node data contains a timestamp expressed in seconds. Bit 3, when set, means that the node data contains a timestamp expressed in subseconds. Bit 4, when set, means that the node data contains transit delay information. Bit 5, when set, means that the node data contains IOAM namespace-specific data in short format. Bit 6, when set, means that the node data contains queue depth information. Bit 7, when set, means that a checksum complement is present in the node data. Bit 8, when set, means that the node data contains the hop limit and the node identifier in wide format. Bit 9, when set, means that the node data contains the ingress interface identifier and the egress interface identifier in wide format. Bit 10, when set, means that the node data contains IOAM namespace-specific data in wide format. Bit 11, when set, means that the node data contains buffer occupancy information. Bits 12 to 21 are undefined; an IOAM encapsulating node shall set all these bits to 0. If an IOAM transit node receives a packet in which one or more of these bits is set to 1, the node shall perform one of the following two actions: after the node data fields corresponding to the IOAM trace type bits defined above, add the corresponding node data using the reserved value 0xFFFFFFFF, so that all the node data filled in by that node equals the value of the node length field in units of 4 bytes; or add no node data field at all to the packet, not even the node data fields corresponding to the IOAM trace type bits defined above. Bit 22, when set, means that a variable-length opaque state snapshot field is present. Bit 23 is a reserved bit, which shall be set to 0 on transmission and ignored on reception.

Reserved: 8 bits, which shall be set to 0.

Node data list [n]: a variable-length field with the format shown in Figure 7. It is a list of node data elements, the content of each element being determined by the IOAM trace type; within each node data element the order in which the data fields are placed follows the bit order of the IOAM trace type field. Each node shall add its own node data element in front of the node data elements it has received, so that the node data list it sends out has its own data element as the first element in the list and the last node data element in the list is the data of the first IOAM-capable node on the path. Filling the node data list in this way ensures that the order of the node data list is the same for the incremental and for the pre-allocated trace options. In the pre-allocated trace option the pointer contained in the remaining length field points to the offset of the node data currently being written.

7.2.3 IOAM end-to-end option type

The IOAM end-to-end option type is used to carry the data added by the IOAM encapsulating node, which will be interpreted by the IOAM decapsulating node. An IOAM transit node may process this data but shall not modify it. The IOAM end-to-end option type contains a fixed-length IOAM end-to-end option type header, shown in Figure 8, and the IOAM end-to-end option type data fields, which shall be aligned on 4 bytes and are shown in Figure 9.

Namespace-ID: the 16-bit IOAM namespace identifier. The default value of the namespace identifier is 0x0000, and this default value shall be known to all nodes that implement IOAM. If a value is received that does not match any of the namespace identifiers configured on the node, the node is not allowed to modify the content of the IOAM data fields.

IOAM-E2E-Type: a 16-bit identifier indicating which data types are contained in the end-to-end option data. The value of the IOAM end-to-end type is a bitmap. The order in which the entries of the end-to-end option data field are filled follows the bit order of the IOAM end-to-end type field, as follows. Bit 0, when set, means that a 64-bit sequence number has been added to the packets of a specific flow, used to detect packet loss, packet reordering or packet duplication within a group of packets; the specific flow is classified by the IOAM encapsulating node, for example by the five-tuple of the packet; when this bit is set, bit 1 must be zero. Bit 1, when set, means that a 32-bit sequence number has been added to the packets of a specific flow, used to detect packet loss, packet reordering or packet duplication within a group of packets; the specific flow is classified by the IOAM encapsulating node; when this bit is set, bit 0 must be zero. Bit 2, when set, means the part expressed in seconds of a timestamp that indicates the time at which the packet entered the IOAM domain. Bit 3, when set, means the subsecond part of a timestamp that indicates the time at which the packet entered the IOAM domain. Bits 4 to 15 are undefined; an IOAM encapsulating node shall set these bits to 0 on transmission and ignore them on reception.

E2E Option data field: a variable-length field. The specific data types are determined by the IOAM end-to-end type field.

7.2.4 IOAM proof-of-transit option type

The IOAM proof-of-transit option type is used to support the verification of a path or of a service function chain. Path verification uses the method of nested hashing or nested encryption of the IOAM data, or the mechanism of Shamir secret sharing. The proof-of-transit option of IOAM POT type 0 is shown in Figure 10.

Namespace-ID: the 16-bit IOAM namespace identifier. The default value of the namespace identifier is 0x0000, and this default value shall be known to all nodes that implement IOAM. If a value is received that does not match any of the namespace identifiers configured on the node, the node is not allowed to modify the content of the IOAM data fields.

IOAM POT Type: an 8-bit identifier of the specific POT type, which indicates the POT data contained in the option. This subclause defines the POT data for the case in which the IOAM POT type is set to 0.

R: 8 bits of IOAM POT flags, reserved for future use, which shall be set to 0 on transmission and ignored on reception. PktID and PktID (contd): a 64-bit per-packet random number. Cumulative and Cumulative (contd): a 64-bit cumulative number, which is updated at a given node by processing the PktID field of each packet together with the configured parameters.

7.2.5 IOAM direct exporting option type

The basic function of the IOAM direct exporting option is the same as that of the trace option types, namely to trace hop by hop and collect the information of the nodes the packet has passed through, but the collected information is neither inserted into nor carried by the packet: it is reported directly by the monitored node to the collecting node, which may be a controller, a network management system or a network node. The specific format is shown in Figure 11.

Namespace-ID: the identifier of the IOAM namespace, 16 bits long, defined in the same way as for the IOAM trace option types. Flag: 8 bits long, not yet defined. Extension-Flag: 8 bits long, used to indicate whether the optional part is present, bit 0 meaning that a flow ID is carried, bit 1 meaning that a sequence number is carried, and the other bits reserved. IOAM-Trace-Type: 24 bits long, consistent with the definition of the IOAM trace type field in the IOAM trace option types. Reserved: 8 bits long.

8.1 Alternate-marking (colouring) encapsulation methods

IPv6 encapsulation method for alternate marking: the alternate-marking data field can be carried in the IPv6 destination option header (DoH). It is inserted at the ingress node of the detection domain and deleted at the egress node. Each detection node along the way, if it supports alternate-marking measurement, shall further parse and process the alternate-marking fields inside the DoH.

SRv6 encapsulation method for alternate marking: the alternate-marking data field can be carried in the SRH in the form of a TLV. It is inserted at the ingress node of the detection domain and deleted at the egress node. Each detection node along the way, if it supports alternate-marking measurement, shall further parse and process the alternate-marking fields inside the SRH.

VxLAN encapsulation method for alternate marking: the reserved field in the last byte of the VxLAN packet header (Reserved equal to ALT-MK) serves as the indication of whether the alternate-marking data field follows the VxLAN packet header, as shown in Figure 12. When the value of the Reserved field matches the defined ALT-MK value, the alternate-marking data field follows immediately after the VxLAN header.

VxLAN-GPE encapsulation method for alternate marking: the reserved field in the last byte of the VxLAN-GPE packet header (Reserved equal to ALT-MK) serves as the indication of whether the alternate-marking data field follows the VxLAN packet header, as shown in Figure 13. When the value of the Reserved field matches the defined ALT-MK value, the alternate-marking data field follows immediately after the VxLAN-GPE packet header.

8.2 IOAM encapsulation method

The IOAM data fields shall be encapsulated in the option data field of an IPv6 extension header, either the hop-by-hop options header or the destination options header. Several options of the same option type may appear at the same time in the hop-by-hop options header or in the destination options header, and the content of the several options may differ.

IOAM shall be enabled explicitly on a per-interface basis at every node of the IOAM domain. For a node that supports the IOAM capability, unless one of its specific interfaces has been explicitly enabled, that is explicitly configured, for the IOAM function, the node shall discard packets that contain an extension header carrying IOAM data fields. An IPv6 packet carrying IOAM data may contain other extension headers, and its format shall comply with IETF RFC 8200.

The format of the IPv6 hop-by-hop and destination options used to carry the IOAM data fields is shown in Figure 14. Option Type: an 8-bit identifier of the option type; the option type value of the pre-allocated trace option, of the incremental trace option and of the proof-of-transit option is 0x31, and the option type value of the end-to-end option and of the direct exporting option is 0x11. Opt Data Len: an 8-bit unsigned integer that gives the length of the reserved field and of the option data field, in bytes. Reserved: an 8-bit field, which shall be set to 0 on transmission and ignored on reception. IOAM Type: an 8-bit field, defined in the part on IOAM data content. Option Data: a variable-length field containing the data specific to the option type.

All IPv6 option fields carrying IOAM shall be aligned on a multiple of 4 bytes. At the same time, since the maximum length of an IPv6 option is 255 bytes, the total length of all IOAM option fields shall likewise not exceed 255 bytes.