An IOAM-based adaptive efficient network node telemetry system and method

Abstract

The application discloses an IOAM-based adaptive efficient network node telemetry system and method, belongs to the technical field of digital information transmission, and comprises a local control plane and a data plane. The local control plane comprises an event analysis module, a configuration management module, an adaptive decision engine module, a policy library module and a reporting management module, and interacts with the data plane through a high-speed internal communication channel. The data plane comprises an interface transmission component, a forwarding rule database, a message forwarding component, an abnormality sensing module and an IOAM processing component, and interacts with the local control plane through the high-speed internal communication channel. The application can adaptively adjust the telemetry strategy according to the real-time state of the network by constructing an efficient and adaptive closed-loop cooperative mechanism of the data plane and the local control plane in the network node, realizes dynamic on-demand allocation of monitoring resources and instant switching of a baseline mode or a high-precision mode, and has the technical effects of high response efficiency, optimized resource utilization and strong node self-intelligence.

Description

Technical Field

[0001] This invention belongs to the field of digital information transmission technology, and particularly relates to a real-time network performance monitoring and fault diagnosis technology, especially an adaptive and efficient network node telemetry system and method based on IOAM. Background Technology

[0002] With the rapid development of technologies such as cloud computing, big data, and artificial intelligence, the scale and complexity of modern networks have increased dramatically, placing higher demands on real-time monitoring and fault diagnosis of network performance. To achieve refined network management, In-band Operation, Management, and Maintenance (IOAM) technology has emerged. IOAM provides unprecedented, hop-by-hop high-precision network status visibility by directly embedding telemetry commands and data into service messages. However, existing IOAM implementations are often based on a centralized control architecture and adopt a static configuration mode. When faced with instantaneous dynamic changes in network status, they generally suffer from core problems such as slow response, low resource utilization, and mismatch between monitoring strategies and real-time network status, severely limiting their application effectiveness in actual production environments.

[0003] Most mainstream IOAM implementations are based on a "centralized control" architecture, where a remote network controller (such as an SDN controller or management platform) is responsible for the formulation, distribution, collection, and analysis of the entire network's monitoring strategies, while network nodes passively execute static configurations.

[0004] Patent application CN112910773A discloses a scheme entitled "A Path Detection Method and Apparatus." This scheme involves a control node issuing IOAM configuration information to a head node or tail node according to the path detection mode, instructing the node to perform IOAM processing and encapsulation on the packets. The head node then inserts an IOAM header into the packet to collect detection data. However, since the IOAM strategy of this scheme relies entirely on the centralized generation and issuance by the network controller, if the node itself does not support this mode, the transmission and execution of its control commands may fail. This results in a technical problem where, when the network device's data plane has detected an anomaly, it cannot make rapid local decisions to adjust the monitoring granularity, leading to path detection failure or monitoring behavior lagging behind the real-time network status.

[0005] The paper "CLINT: Controller-Assisted Lightweight In-Band Network Telemetry" discloses a controller-assisted lightweight in-band network telemetry scheme. This scheme is a typical centralized control implementation, emphasizing the core role of the controller in telemetry configuration and node management. The fundamental drawback of this architecture lies in its long control loop and high latency. The millisecond-level or even second-level communication signaling between the controller and network nodes causes the controller to be unable to match the microsecond-level state changes within the network nodes. When network anomalies occur, the network controller cannot instantly detect and issue high-precision monitoring strategies, resulting in missed critical diagnostic data; after the anomaly ends, nodes may still be executing high-overhead strategies, leading to resource waste.

[0006] Current mainstream centralized control IOAM technology solutions, through a "remote static configuration, local passive execution" model, theoretically provide high-precision network telemetry capabilities, but in practical applications, they have exposed fundamental architectural flaws. Their design philosophy cannot adapt to the highly dynamic characteristics of modern networks, resulting in low response efficiency, low resource utilization, and missing node capabilities. Specifically, these can be summarized in the following three points:

[0007] First, the response efficiency is low: the contradiction between control latency and data dynamics leads to a serious lag in monitoring strategies.

[0008] The core drawback of existing technologies is that their "slow" control loops cannot match the "fast" changes in network status, resulting in monitoring strategies lagging far behind the real-time network status.

[0009] Second, low resource utilization: the rigid monitoring strategy leads to a sharp conflict between forwarding performance and monitoring accuracy.

[0010] Due to a lack of rapid adaptive capabilities, network administrators are forced to make static, either-or trade-offs between network forwarding performance and monitoring accuracy, resulting in serious resource allocation efficiency problems. Fixed monitoring strategies make it difficult to balance network forwarding performance and monitoring accuracy, failing to allocate monitoring resources precisely and on demand, focusing only on the moment an anomaly occurs and specific traffic flows, leading to resource waste.

[0011] Third, lack of node capabilities: The lack of internal coordination mechanisms prevents nodes from responding quickly and autonomously.

[0012] The root cause of the above problems lies in the design flaws of the network nodes themselves. The lack of a high-speed communication and closed-loop control mechanism specifically designed for telemetry between the data plane (ASIC / FPGA) and the local control plane (CPU) inside the network node prevents the node from using its own sensing and computing resources to make a rapid and autonomous adaptive response to local network anomalies. Summary of the Invention

[0013] To overcome the shortcomings of the prior art, the present invention aims to provide an adaptive and efficient network node telemetry system and method based on IOAM. By constructing an efficient and adaptive closed-loop collaborative mechanism between the data plane and the local control plane within the network node, the telemetry strategy can be adaptively adjusted according to the real-time network status, realizing dynamic on-demand allocation of monitoring resources and instant switching between baseline mode and high-precision mode. It has the technical effects of high response efficiency, optimized resource utilization, strong node autonomy and intelligence, and effective balance between forwarding performance and monitoring accuracy.

[0014] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0015] An adaptive and efficient network node telemetry system based on IOAM includes a local control plane and a data plane, wherein:

[0016] The local control plane includes an event analysis module, a configuration management module, an adaptive decision engine module, a policy library module, and a reporting management module, which interact with the data plane through a high-speed internal communication channel. The event analysis module provides input triggers, the adaptive decision engine module integrates decisions and outputs instructions to the configuration management module and the reporting management module. The configuration management module maintains telemetry parameter thresholds and constructs policy configuration control frames. The reporting management module aggregates event data to generate refined logs. For high-level anomalies, the refined logs are reported to the network controller and simultaneously recorded locally; for non-high-level anomalies, the refined logs are only recorded locally. The policy library module interacts bidirectionally with the adaptive decision engine module for storing, querying, and updating multi-level telemetry policies.

[0017] The data plane includes an interface transmission component, a forwarding rule database, a message forwarding component, an anomaly detection module, and an IOAM processing component. It interacts with the local control plane through a high-speed internal communication channel. The interface transmission component processes data frames for external transmission and reception. The message forwarding component performs protocol processing on the received data frames according to the forwarding rule entries stored in the forwarding rule database. The IOAM processing component constructs IOAM upload messages. The anomaly detection module monitors and reports anomalies.

[0018] The event analysis module is used to perform preliminary analysis and classification of abnormal signals reported by the data plane. It takes abnormal event reporting frames from the high-speed internal communication channel as input and outputs the classified refined event metadata signal to the adaptive decision engine module. If the event level is high, it outputs the preliminary reporting identification signal to the reporting management module in parallel. If the event level is low or medium, it only outputs to the adaptive decision engine module.

[0019] The configuration management module is used to maintain telemetry parameter thresholds and construct policy configuration control frames. It inputs decision command signals from the adaptive decision engine module and optional network controller feedback signals, constructs policy configuration control frames based on the decision command signals, and outputs the constructed policy configuration control frame signals to the data plane.

[0020] The adaptive decision engine module receives the refined event metadata signal from the event analysis module and the query result signal from the strategy library module. It integrates the input signals to execute the adaptive algorithm and generate decision instructions. It outputs the decision instruction signal to the configuration management module, the refined reporting signal to the reporting management module, and the update request signal to the strategy library module.

[0021] The strategy library module receives query request signals and update request signals from the adaptive decision engine module, and is used to store and manage multi-level telemetry strategies and support dynamic updates, and outputs the matched query result signal to the adaptive decision engine module.

[0022] The reporting management module receives the refined reporting signal output by the adaptive decision engine module and the preliminary reporting identifier signal from the event analysis module, and uses them to aggregate event data to generate refined logs. The reporting management module performs hierarchical processing based on the anomaly level: for high-level anomalies, the refined logs are reported to the network controller and simultaneously recorded locally; for non-high-level anomalies, the refined logs are only recorded locally.

[0023] The interface transmission component is used to process the reception, splitting, and assembly of data frames, providing data transmission and flow control. For each service physical interface, the interface transmission component is configured with a pair of input processing modules and an output processing module. For the sampling physical interface that outputs IOAM uplink messages, an IOAM output module is configured, wherein:

[0024] Each of the input processing modules is used to receive the business data packets of the corresponding business physical interface and perform preliminary parsing, extract information to assemble metadata, transmit it synchronously with the business data packets, and output the business data packets carrying metadata to the packet forwarding component.

[0025] Each of the output processing modules is used to deliver the service data packets that have undergone routing and forwarding processing by the packet forwarding component to the corresponding service physical interface;

[0026] The IOAM output module is used to deliver the IOAM uplink message constructed by the IOAM processing component to the sampling physical interface;

[0027] The packet forwarding component is used to parse, match, and forward received service data packets carrying metadata based on forwarding policies stored in the forwarding rule database. It accesses ACL policy rules, performs IOAM node processing and raw packet processing, and collects sampling information. The packet forwarding component includes a polling scheduling module, an ACL policy matching module, a flow classification module, a route forwarding lookup module, a packet processing module, and a queue management module.

[0028] The polling scheduling module connects multiple input processing modules in the interface transmission component. It is used to receive the business data packets carrying metadata output by each input processing module, and to perform polling scheduling to aggregate multiple inputs into one business data packet carrying metadata, which is then output to the ACL policy matching module.

[0029] The ACL policy matching module is used to process a service data packet carrying metadata from the polling scheduling module. It uses the packet's five-tuple information as a lookup index signal to query the Access Control List (ACL) entry in the forwarding rule database to obtain IOAM processing actions and IOAM configuration information. Based on the IOAM node determination method, it determines the current node type and obtains the IOAM uploading mode signal. If the current node type is an IOAM encapsulation node, it obtains the IOAM uploading mode signal based on the IOAM configuration information. If the current node type is an IOAM transmission node or an IOAM decapsulation node, it obtains the IOAM uploading mode signal based on the IOAM header carried in the service data packet. Furthermore, it constructs an IOAM trigger signal based on the IOAM uploading mode signal and the current node type signal, and writes it into the metadata along with the sampling template signal from the IOAM node type and IOAM configuration information. Simultaneously, it outputs the IOAM trigger signal, IOAM uploading mode signal, IOAM node type signal, and IOAM configuration information as IOAM metadata to the IOAM processing component. Otherwise, it does not update the metadata. Finally, it outputs the service data packet and metadata to the flow classification module.

[0030] IOAM upload modes include hop-by-hop tracking (Trace) mode, end-to-end E2E mode, or direct DEX export mode. The specific method for constructing the IOAM trigger signal is as follows:

[0031] (1) If the IOAM uploading mode is end-to-end E2E, and the current node type is IOAM encapsulation node or IOAM decapsulation node, then construct the IOAM trigger signal;

[0032] (2) If the current IOAM uploading mode is hop-by-hop tracing and the current node type is IOAM decapsulation node, then construct the IOAM trigger signal;

[0033] (3) If the IOAM upload mode is direct export of DEX, and the current node type is IOAM encapsulation node, IOAM transmission node or IOAM decapsulation node, then construct the IOAM trigger signal.

[0034] Otherwise, the IOAM trigger signal will not be constructed;

[0035] The flow classification module is used to parse the protocol field in the packet header to accurately classify the packet, extract the protocol field and write it into metadata; it takes the service data packet and metadata from the ACL policy matching module as input, and outputs the updated metadata and service data packet to the route forwarding lookup module; if the IOAM trigger signal from the ACL policy matching module is valid, the original service data packet is written to the mirror data cache, otherwise it is not written to the cache.

[0036] The routing forwarding lookup module is used to output a table lookup index signal for the metadata and service data packets updated from the flow classification module, query the routing forwarding FIB table entries and the neighbor discovery protocol NDP table entries in the forwarding rule database, write the obtained table entry information signal into the metadata signal, and output the service data packets and the metadata signal containing complete forwarding information to the packet processing module.

[0037] The packet processing module is used to perform link layer and network layer header processing on the service data packets based on the service data packets output by the routing and forwarding lookup module and the metadata signal containing complete forwarding information. Based on the IOAM node type signal and IOAM uploading mode signal obtained by the ACL policy matching module, it determines whether to perform IOAM header or IOAM metadata processing on the service data packets. The specific determination method is as follows:

[0038] (1) If the current IOAM uploading mode is end-to-end E2E or direct export DEX, then further judgment is made based on the IOAM node type; if it is determined to be an IOAM encapsulation node, then the IOAM header is inserted based on the header processing; if it is determined to be an IOAM decapsulation node, then the IOAM header is removed based on the header processing, the flow tag field in the business data packet header is cleared, and the processed business data packet is sent to the queue management module;

[0039] (2) If the current IOAM uploading mode is hop-by-hop tracing, then further judgment is made based on the IOAM node type; if it is determined to be an IOAM encapsulation node, then the IOAM header and IOAM metadata are inserted on the basis of header processing; if it is determined to be an IOAM transmission node, then the IOAM metadata is inserted on the basis of header processing; if it is determined to be an IOAM decapsulation node, then the IOAM header and IOAM metadata are removed on the basis of header processing, and the flow tag field in the business data packet header is cleared.

[0040] Meanwhile, if the mode signal and sampling rate signal in the IOAM configuration information obtained during the ACL policy matching phase are valid, the fields in the IOAM header will be updated; otherwise, the payload structure of the service data packet will remain unchanged, and the processed service data packet will be directly output to the queue management module.

[0041] The queue management module is used to perform enqueueing, priority scheduling, and dequeueing operations on the final message output from the packet processing module or the IOAM uplink message output by the IOAM processing component in the specified port output mode. At the same time, the queue management module obtains telemetry parameter information based on the IOAM sampling template information carried in the metadata and writes it into the IOAM sampling information cache. Finally, it outputs the service data packet that has completed the routing and forwarding processing to the output processing module of the interface transmission component.

[0042] The forwarding rule database is used to store and manage the lookup table module, which includes Access Control List (ACL) entries, Routing Forwarding (FIB) entries, and Neighbor Discovery Protocol (NDP) entries.

[0043] The forwarding rule database locally configures and stores policy configuration control frames output from the configuration management module of the local control plane; it indexes Access Control List (ACL) entries and performs policy matching based on the lookup index signal output from the ACL policy matching module of the packet forwarding component, and outputs the matched entry information signal back to the ACL policy matching module; it indexes the route forwarding FIB entry storage based on the lookup index signal output from the route forwarding lookup module of the packet forwarding component, performs entry matching, and outputs the matched entry information signal back to the route forwarding lookup module; it also indexes the Neighbor Discovery Protocol (NDP) entries and performs entry matching based on the lookup index signal output from the route forwarding lookup module of the packet forwarding component, and outputs the matched entry information signal back to the route forwarding lookup module.

[0044] The anomaly detection module is used to monitor the data flow status of the data plane in real time, obtain telemetry parameters by reading the statistical register of the queue management module, determine the type of abnormal event based on the telemetry parameter threshold, and output the abnormal event reporting frame to the event analysis module of the local control plane; wherein, the telemetry parameters include forwarding delay, packet loss and queue congestion status information obtained by monitoring the queue management module;

[0045] The IOAM processing component is used to trigger the construction of IOAM uploading messages. Internally, it includes a policy matching module, an IOAM encapsulation information acquisition module, an IOAM uploading message construction module, and an outbound path decision module; wherein:

[0046] The policy matching module is used to process the IOAM trigger signal, IOAM upload mode, IOAM node type signal, and IOAM configuration information output by the ACL policy matching module. If the IOAM trigger signal is valid, the IOAM upload message is constructed, the IOAM configuration information is parsed, the IOAM upload mode, sampling template signal, IOAM sampling rate, and specified output port information are obtained, metadata is written, and output to the IOAM encapsulation information acquisition module; otherwise, the IOAM upload message is not constructed.

[0047] The IOAM encapsulation information acquisition module is used to read the image data cache, IOAM sampling information cache, and metadata information output by the policy matching module. Based on the IOAM node type signal and IOAM upload mode signal, it acquires and constructs the necessary information for the IOAM upload message. The construction information includes the message header, UDP header, IOAM header, and IOAM metadata information. The method for acquiring the construction information is as follows:

[0048] (1) Message header: The message header is obtained by reading the mirror data cache; (2) UDP header: If the current IOAM node type is an IOAM encapsulation node, the UDP header is provided by the local control plane; otherwise, it is obtained by reading the mirror data cache; (3) IOAM header: If the current IOAM node type is an IOAM encapsulation node, the IOAM header is provided by the IOAM configuration information output by the ACL policy matching module; otherwise, it is obtained by reading the mirror data cache; (4) IOAM metadata: If the current IOAM upload mode is end-to-end E2E or direct export DEX, the IOAM metadata only contains the current node information and is obtained by reading the telemetry parameter information stored step by step in the IOAM sampling information cache; If the current IOAM upload mode is hop-by-hop tracing, the IOAM metadata contains the current node information and the upstream node information in the IOAM network measurement path. The current node information is obtained by reading the telemetry parameter information stored step by step in the IOAM sampling information cache, and the upstream node information is obtained by reading the mirror data cache;

[0049] Finally, the IOAM encapsulation information acquisition module outputs the construction information to the IOAM uploading message construction module in a timely manner.

[0050] The IOAM uplink message construction module is used to integrate the construction information provided by the IOAM encapsulation information acquisition module, encapsulate it into an IOAM uplink message, and output it to the exit path decision module.

[0051] The exit path decision module is used to specify a forwarding strategy for the IOAM uplink message constructed by the IOAM uplink message construction module. Based on whether the specified output port signal from the IOAM configuration information is valid, it selects either a specified output port or a fixed output port output mode. If the specified output port signal is valid, the IOAM uplink message is output to the queue management module in the message forwarding component; otherwise, the IOAM uplink message is directly output to the IOAM output module in the interface transmission component. The specified output port strategy is dynamically learned and configured by the local control plane, and the local control plane configures the dynamically calculated specified output port of the IOAM uplink message into the access control list (ACL) entry in the forwarding rule database.

[0052] The abnormal event reporting frame includes the abnormal event type, trigger timestamp, five-tuple information, flow tag associated with the service data packet, and telemetry parameters obtained by the abnormality perception module when the data plane abnormal event is triggered.

[0053] The policy configuration control frame includes 5-tuple information, updated stream label, updated sampling mode, and sampling rate N information.

[0054] The adaptive algorithm of the adaptive decision engine module is a multi-level adaptive monitoring state machine, specifically including:

[0055] State 0, i.e. baseline monitoring state: the system default state, executing end-to-end E2E mode with low sampling rate, only collecting basic path information;

[0056] State 1, i.e. suspected confirmation or medium-precision monitoring state: entered when a transient anomaly or low-level event is detected, and medium sampling rate or lightweight direct export DEX mode is executed;

[0057] State 2, i.e., fault location or high-precision monitoring state: Entered when the abnormality is confirmed to be continuous in State 1 or a high-severity event is detected, and full-volume hop-by-hop tracing Trace mode or high-frequency direct export DEX mode is executed to collect complete metadata;

[0058] Meanwhile, an event timer mechanism is introduced. If the event timer does not detect any new abnormal events within the preset time window, it is determined that the network state is stable, triggering the policy rollback logic to fall back the monitoring state from state 2 to state 1, or directly reset it back to state 0.

[0059] The IOAM node determination method is specifically divided into two stages: a preliminary flow tag matching stage and a final IOAM node type determination stage; wherein:

[0060] In the initial flow label matching stage: the ACL policy matching module extracts the flow label field from the IPv6 basic header of the service data packet for judgment. If the flow label value is within the preset range, the node type is initially determined to be an IOAM transmission node or an IOAM decapsulation node; if the flow label value is not within the preset range, the node type is an IOAM encapsulation node or a non-IOAM node, and the judgment needs to be combined with the IOAM processing action.

[0061] The final determination stage of the IOAM node type: combining the results of the initial matching stage between IOAM processing actions and flow tags, the node type is determined to be either an IOAM encapsulated node or a non-IOAM node; the matching method is as follows:

[0062] (1) If the IOAM processing action is encapsulation, then the current node is the encapsulation node and the IOAM encapsulation operation needs to be performed;

[0063] (2) If the stream label matches and the IOAM processing action is decapsulation, then the current node is the decapsulation node and the IOAM decapsulation operation needs to be performed;

[0064] (3) If the stream tag matches and the IOAM processing action is not encapsulation or decapsulation, then the IOAM transport node operation is executed;

[0065] (4) Otherwise, it is determined to be a non-IOAM node and no IOAM-related operations are performed.

[0066] The specific implementation methods of the Control List (ACL) entries, Routing Forwarding (FIB) entries, and Neighbor Discovery Protocol (NDP) entries include:

[0067] The FIB (Forwarding Instructions for International) table entries are used for matching packet forwarding policies. Using the destination IP address as the lookup index signal, they retrieve the entry information signal, which includes the next-hop IP address and the outgoing port number. This retrieved entry information signal is then input into the routing lookup module. The NDP (Neighbor Discovery Protocol) table entries are used to obtain the link-layer MAC address of neighboring devices. Using the next-hop IP address as the lookup index signal, they retrieve the entry information signal, which includes the link-layer MAC address of the next-hop node. This retrieved entry information signal is then input into the routing lookup module. The ACL (Access Control List) table entries use the five-tuple information output by the ACL policy matching module as the lookup index signal to obtain the IOAM (Important Query Management) policy. The five-tuple... The group information includes: source IP address, destination IP address, transport layer source port, transport layer destination port, and transport layer protocol number; the IOAM monitoring policy includes IOAM processing actions and IOAM configuration information. The IOAM processing actions include determining whether the node performs IOAM encapsulation or decapsulation operations. The IOAM configuration information includes the IOAM domain namespace number, flow label, IOAM upload mode, sampling information template, sampling rate N, and specified output port. The IOAM upload mode includes hop-by-hop tracing mode, end-to-end E2E mode, or direct export DEX mode; the access control list (ACL) entry information is output to the ACL policy matching module of the IOAM processing component.

[0068] The positions of the ACL policy matching module and the flow classification module in the packet forwarding component can be interchanged; wherein:

[0069] The flow classification module is used to parse the protocol field in the packet header to accurately classify the packet. It takes a service data packet carrying metadata from the output of the polling scheduling module as input, parses the protocol field in the packet header, adds the parsed packet five-tuple information to the metadata, outputs it along with the original packet, and outputs the updated metadata and service data packet to the ACL policy matching module.

[0070] The ACL policy matching module is used to query the ACL entries in the forwarding rule database based on the updated metadata and service data packets output from the flow classification module, using the packet's five-tuple information as a lookup index signal, to obtain IOAM processing actions and IOAM configuration information; determine the current node type according to the IOAM node determination method; and obtain the IOAM uploading mode signal based on the current node type; if the current node type is an IOAM encapsulation node, then obtain the IOAM uploading mode signal based on the IOAM configuration information; if the current node type is an IOAM transmission node or an IOAM decapsulation node, then obtain the IOAM header carried in the service data packet. The IOAM uplink mode signal is then sent; furthermore, an IOAM trigger signal is constructed based on the IOAM uplink mode signal and the current node type signal, and written into the metadata along with the sampling template signal in the IOAM node type and IOAM configuration information. At the same time, the IOAM trigger signal, IOAM uplink mode signal, IOAM node type signal, and IOAM configuration information are output to the IOAM processing component as IOAM metadata; otherwise, the metadata is not updated. Finally, the updated metadata from the ACL policy matching module and the service data packet are output to the route forwarding lookup module. Meanwhile, if the IOAM trigger signal is valid, the original service data packet is written to the mirror data cache; otherwise, it is not written to the cache.

[0071] This invention also provides an adaptive and efficient network node telemetry method based on IOAM, comprising the following steps:

[0072] Step 1: The network node is initialized and the baseline monitoring strategy is loaded. The baseline monitoring strategy is uniquely indexed by the five-tuple information in the service data packet. The specific strategy is: to execute the end-to-end E2E upload mode, construct the IOAM upload message with a low sampling rate, and at the same time, the node telemetry parameter information in the IOAM upload message only contains the basic telemetry fields.

[0073] Step 2: The data plane processes service packets in real time, performing baseline monitoring while maintaining line-rate forwarding. The specific implementation process is as follows: The interface transmission component receives multiple service data packets from external service physical interfaces and outputs them to the packet forwarding component; the polling scheduling module aggregates multiple inputs into a single service data packet carrying metadata and outputs it to the ACL policy matching module; the ACL policy matching module obtains the IOAM processing action and IOAM configuration information based on the packet's five-tuple information, where the IOAM configuration information includes the baseline monitoring policy; the flow classification module parses the protocol field in the packet header and updates the metadata. If the IOAM trigger signal from the ACL policy matching module is valid, the original service data packet is written to the mirror data cache; the original data packet enters the routing forwarding lookup module after obtaining the next-hop IP address, outgoing port number, and link-layer MAC address. The packet processing module, while processing packet data, performs IOAM header or IOAM metadata processing based on IOAM node type and IOAM uploading mode signals. Subsequently, the queue management module performs packet enqueueing and dequeueing scheduling. During the dequeueing phase, the queue management module collects packet queuing delay and buffer occupancy information according to the baseline monitoring strategy and writes it to the IOAM sampling information buffer. Simultaneously, it outputs the service data packets that have completed routing and forwarding processing to the output processing module of the interface transmission component. Meanwhile, the IOAM processing component reads the aforementioned IOAM sampling information buffer information, triggers the construction of IOAM uploading packets under the baseline monitoring strategy based on IOAM metadata and IOAM configuration information, and outputs them to the physical interface in the interface transmission component according to the port output mode, ultimately completing the forwarding of the IOAM uploading packets.

[0074] Step 3: The anomaly detection module monitors the data flow status of the data plane in real time and determines the event type based on telemetry parameter thresholds, namely latency, packet loss, and queue congestion status.

[0075] Determine whether the telemetry parameter values ​​exceed the preset threshold range;

[0076] If no abnormalities are found, return to step 2 and maintain the baseline monitoring status to ensure network performance.

[0077] If an anomaly is detected, the data plane captures the anomaly event data, constructs an anomaly event reporting frame, and inputs the anomaly event reporting frame to the event analysis module through a high-speed internal communication channel. The event analysis module performs preliminary analysis and classification processing on it, and outputs the refined event metadata signal after classification to the adaptive decision engine module. If the event level is high, the preliminary reporting identification signal is output to the reporting management module in parallel.

[0078] Step 4: After receiving the refined event metadata signal, the adaptive decision engine module of the local control plane analyzes it, executes the adaptive algorithm according to the abnormal event type and level, and generates decision instructions.

[0079] Step 5: The adaptive decision engine outputs decision instruction signals to the configuration management module, refinement reporting signals to the reporting management module, and update request signals to the policy library module;

[0080] Step 6: The configuration management module converts the decision command signal into a policy configuration control frame that can be executed in the data plane, and sends it to the data plane via the high-speed internal communication channel;

[0081] Step 7: The Access Control List (ACL) entries in the data plane receive policy configuration control frames and update the sampling policy based on the five-tuple information. Subsequently, the ACL policy matching module locates abnormal data flows based on the packet five-tuple information and guides subsequent modules to execute the updated high-precision monitoring policy. Specifically, the queue management module collects full network status information according to the high-precision sampling template, including packet enqueue and dequeue times, real-time queue depth, queue occupancy rate, and packet loss statistics, and writes the above information into the IOAM sampling information cache. The IOAM processing component, according to the high-precision monitoring policy, i.e., adopting hop-by-hop tracing or direct DEX export mode and executing high sampling rate, reads the cache and constructs an IOAM upload packet containing complete telemetry field information. At the same time, the data plane continues to maintain baseline monitoring mode for non-abnormal traffic.

[0082] Step 8: During high-precision monitoring, the data plane continuously determines whether the abnormal state has disappeared. For the same set of telemetry parameters in Step 3, it determines whether the telemetry parameter values ​​have fallen back to the preset recovery threshold range. If the abnormal state is determined to persist, Step 7 is executed repeatedly to continue high-precision sampling and capture complete data. If the abnormal state is determined to have disappeared, the adaptive decision engine module evaluates the current state and generates a strategy fallback instruction to restore the baseline mode. The configuration management module converts the strategy fallback instruction signal into a strategy configuration control frame that can be executed by the data plane and sends it to the data plane through the high-speed internal communication channel.

[0083] Step 9: The Access Control List (ACL) entries in the data plane receive the policy configuration control frame and update the sampling policy based on the five-tuple information. The ACL policy matching module matches the updated low-precision monitoring policy based on the packet five-tuple information and returns to Step 2 to realize automatic resource optimization and closed-loop control.

[0084] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0085] This invention fundamentally solves the problems of lagging monitoring strategies, high resource overhead, and lack of node intelligence in traditional centralized IOAM schemes by constructing an efficient and adaptive closed-loop collaborative mechanism between the data plane and the local control plane within network nodes, and combining it with efficient forwarding and adaptive decision-making algorithms. This brings the following significant benefits:

[0086] First, it completely solves the problem of mismatch between monitoring strategies and network status, upgrading the traditional "passive and lagging" monitoring to "microsecond-level adaptive" monitoring, which significantly improves the timeliness and accuracy of fault diagnosis.

[0087] Technical Solution Support: This invention constructs a high-speed, low-latency closed-loop control mechanism within network nodes, based on data plane awareness, efficient execution, and adaptive decision-making in the local control plane. Specifically, the anomaly awareness module in the data plane can monitor the data flow status at the microsecond or even nanosecond level (such as forwarding latency, packet loss, and queue congestion information of service data packets) in parallel and in real time. Once an indicator is detected to exceed a preset threshold, it immediately captures the abnormal flow characteristics and reports them directly through a high-speed internal communication channel (such as PCIe / DMA mechanism). After receiving the signal, the adaptive decision-making engine module in the local control plane quickly executes the adaptive algorithm to generate decision instructions and directly updates the access control list (ACL) entries and sampling policies in the data plane forwarding rule database through the configuration management module, without waiting for instructions from the network controller.

[0088] Beneficial Effects Analysis: This mechanism frees monitoring strategy adjustments from reliance on remote, slow controllers, shortening the slow loops of traditional solutions (milliseconds or even seconds) to fast loops within nodes (microseconds). Its significant effect lies in the fact that when transient anomalies such as microbursts occur in the network, this invention can complete the entire process of "perception-decision-policy update-high-precision capture" within the extremely short lifespan of the anomaly, accurately capturing key on-site data (such as forwarding latency, packet loss, and queue congestion status information at the time of the fault) that would inevitably be missed by traditional solutions due to signaling interaction delays. This makes fault location no longer dependent on post-event speculation or low-precision statistical data, but based on complete data from the scene, thereby effectively improving the timeliness of fault diagnosis.

[0089] Second, it fundamentally resolves the contradiction between monitoring accuracy and forwarding performance, enabling on-demand allocation, dynamic balancing, and efficient utilization of network monitoring resources.

[0090] Technical Support: This invention employs an on-demand, tiered monitoring strategy triggered by abnormal events and a non-loopback direct output mechanism. On one hand, the system supports dynamic switching between baseline monitoring (end-to-end E2E mode / low sampling rate) and high-precision monitoring (hop-by-hop tracing / direct DEX export mode / high sampling rate): When the network is stable, the adaptive decision engine automatically executes fallback decisions, and the ACL policy matching module executes the low-overhead baseline monitoring mode, consuming almost no forwarding resources. High-precision monitoring is only initiated for specific abnormal flows at the moment the abnormal event is triggered by the anomaly perception module. This achieves on-demand allocation and dynamic balancing of network resources. On the other hand, the output of IOAM uploading messages uses a non-loopback mechanism, significantly reducing system latency and resource consumption, and achieving efficient utilization of network resources.

[0091] Beneficial Effects Analysis: This mechanism breaks down the contradiction between monitoring accuracy and forwarding performance in existing technologies. Through dynamic adjustment, the system's forwarding performance is guaranteed for the vast majority of normal uptime, avoiding performance degradation caused by excessive telemetry; at the same time, it ensures monitoring accuracy and data integrity when anomalies occur, achieving on-demand allocation and dynamic balance of system resources. Furthermore, the non-loopback direct output mechanism avoids IOAM-uploaded packets re-entering the packet forwarding component for secondary routing table lookups and queue scheduling, significantly reducing internal chip bandwidth usage and processing latency. While ensuring high real-time performance, it minimizes system resource consumption, achieving efficient utilization of system resources.

[0092] Third, it endows network nodes with local intelligence, making up for the architectural defects of traditional network nodes lacking internal capabilities, and improving the scalability and robustness of the entire telemetry system.

[0093] Technical Solution Support: This invention constructs an efficient internal collaboration mechanism. The data plane is responsible for real-time monitoring of abnormal states and providing abnormal event reporting capabilities, while the control plane is responsible for adaptive telemetry decision-making, event analysis, policy matching, configuration management, and refined reporting, providing rapid response capabilities to abnormal events. The tight coupling between the control plane and the data plane overcomes the fundamental defects of traditional network node architectures and activates the node's own computational and decision-making potential. The node is no longer merely a passive "sensor" executing remote commands, but becomes an intelligent agent capable of autonomously processing local events in a closed loop.

[0094] Beneficial Effects Analysis: This distributed intelligent architecture upgrades network nodes from traditional network devices that passively execute instructions to intelligent agents with autonomous perception and decision-making capabilities. First, numerous instantaneous network state changes are processed locally on-node in a closed-loop manner, and the refined log reporting mechanism significantly reduces the backhaul of redundant data, saving valuable network bandwidth and storage resources. Second, it significantly reduces the computational and decision-making burden on the network controller; only data deemed valuable for analysis by the local controller is sent to it, solving the performance bottleneck problem of the controller in large-scale networks and improving the system's scalability. Finally, even in extreme cases where the connection between the node and the network controller is interrupted, the node can still maintain effective monitoring and response to anomalies through local intelligence, ensuring the high robustness and availability of the telemetry system.

[0095] In summary, this invention effectively overcomes the inherent limitations of traditional centralized IOAM technology in terms of response lag, performance-accuracy contradictions, and limited system scalability by constructing a data plane and local control plane collaboration within network nodes, triggering an anomaly perception module and driving an adaptive decision engine. It combines an anomaly-triggered on-demand high-precision monitoring strategy with a non-loopback direct output mechanism for IOAM uploading messages, and introduces a distributed intelligent architecture with event analysis and refined reporting capabilities. It has the advantages of significantly improved fault diagnosis efficiency, maximized network resource utilization, and greatly enhanced system scalability and robustness. Attached Figure Description

[0096] Figure 1 This is a diagram of the adaptive and efficient network node system architecture of the present invention.

[0097] Figure 2 This is a flowchart of the adaptive flow detection method of the present invention.

[0098] Figure 3 This is an example diagram of an adaptive and efficient flow detection scenario and message transmission based on the present invention.

[0099] Figure 4 This is a schematic diagram of the IOAM flow detection hop-by-hop tracking Trace mode.

[0100] Figure 5 This is a schematic diagram of the end-to-end E2E mode of IOAM flow detection.

[0101] Figure 6 This is a schematic diagram of IOAM flow detection directly exporting DEX mode. Detailed Implementation

[0102] The technical solution adopted by the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0103] To address the core shortcomings of existing technologies in terms of response efficiency, resource utilization, and node capabilities, this invention aims to provide a highly efficient and adaptive in-band network telemetry (IOAM) implementation scheme. This invention primarily focuses on implementing adaptive telemetry optimization within network nodes (such as routers and switches), resolving the issues of response lag, resource conflicts, and insufficient local coordination in existing IOAM schemes. The core of the technical solution is to dynamically adjust the monitoring strategy through hardware-level anomaly triggering and local closed-loop control, ensuring high-precision data capture during anomalies and low-overhead operation during normal conditions, while maintaining compatibility with existing IOAM standards, such as the data encapsulation format of RFC 9197.

[0104] This invention discloses an adaptive and efficient network node telemetry system based on IOAM. This system can be applied to general network nodes (routers / switches). For ease of description, the following will use a router network node as an example. This system has an externally open physical interface, providing basic transmission capabilities for Ethernet data service packets, and supports interaction with interconnected network nodes and network management controllers. The network node supports Ethernet service / control data forwarding and processing capabilities based on the IEEE 802.3 standard to carry Internet Protocol version 6 (IPv6) and higher-level protocols such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). To enhance the intelligence and autonomy of IOAM (In Situ Operations, Administration, and Maintenance) flow detection operation and maintenance, this system, based on In Situ Operations, Administration, and Maintenance (IOAM) technology, performs adaptive decision-making, event analysis, policy matching, configuration management, and reporting management functions in the local control plane. It innovatively achieves a local autonomous closed loop, dynamically switching IOAM sampling modes, such as baseline end-to-end E2E / low sampling rate mode and high-precision hop-by-hop tracing / direct DEX export / high sampling rate mode. The configuration management module performs real-time configuration of the data plane. The system completes the entire IOAM process in the data plane, covering flow identification and monitoring, node type determination, flow information collection, packet encapsulation, and forwarding path decision-making. It also features adaptive network monitoring information export capabilities, meeting the needs of real-time network status monitoring based on IOAM, and supports full-link processing capabilities for IOAM encapsulation / forwarding / decapsulation. This invention focuses on network node design and implementation, ensuring high-performance forwarding of data services while providing efficient adaptive flow detection capabilities. It innovatively reduces reporting load and achieves microsecond-level response, avoiding the resource waste of traditional static telemetry. Simultaneously, the data plane supports efficient routing and forwarding of service packets, achieving line-speed processing through hardware acceleration (such as FPGA / P4 programmable chips) to avoid software intervention overhead. For IOAM uploading packets, the system supports two modes: forwarding to a specified output port and direct output to a fixed output port. The common advantage of these two modes is that neither requires the packet to loop back to the routing and forwarding lookup module for a secondary table lookup, thus significantly reducing processing latency and resource consumption.Based on this, the two modes are suitable for different business scenarios: the specified output port forwarding mode is more adaptable to dynamic and time-varying network scenarios (such as satellite networks). The local control plane dynamically calculates routes and updates the forwarding rule database, while the data plane sends packets to the queue management module for priority scheduling, ensuring link reachability and quality of service under highly dynamic topology changes. The fixed output port direct output mode further skips the queue scheduling logic and sends packets directly via the IOAM output module, thus meeting high real-time telemetry requirements with the lowest absolute latency. The local control plane consists of an adaptive decision engine module, an event analysis module, a policy library module, a configuration management module, and a reporting management module. The data plane consists of an interface transmission component, a forwarding rule database, a packet forwarding component, and an IOAM processing component. The two planes interact through a high-speed internal communication channel (such as PCIe / DMA mechanisms) to achieve abnormal signal reporting, policy configuration control frame distribution, and microsecond-level closed-loop response. The system architecture diagram of the IOAM-based adaptive high-efficiency network node is shown below. Figure 1 As shown.

[0105] like Figure 1 As shown, this invention provides an adaptive and efficient network node telemetry system based on IOAM. The overall architecture includes a local control plane and a data plane. The data plane is responsible for full-speed packet forwarding and hardware-level anomaly detection, while the local control plane is responsible for adaptive policy decision-making and deployment. The core closed-loop mechanism of this invention is that anomalies (such as sudden increases in queue depth) are detected in real time by the data plane, reported to the local control plane via a high-speed internal communication channel, and the local control plane quickly makes decisions and deploys policies to achieve dynamic switching of monitoring modes.

[0106] An adaptive and efficient network node telemetry system based on IOAM includes a local control plane and a data plane, wherein:

[0107] The local control plane is responsible for adaptive telemetry decision-making, event analysis, policy matching, configuration management, and refined reporting, achieving microsecond-level local closed-loop response. The local control plane includes an event analysis module, a configuration management module, an adaptive decision engine module, a policy library module, and a reporting management module. It interacts with the data plane through a high-speed internal communication channel and, with the adaptive decision engine module at its core, forms a closed-loop mechanism for event perception, decision generation, policy execution, and reporting optimization. Specifically, the event analysis module provides input triggers, the adaptive decision engine module integrates decisions and outputs instructions to the configuration management module and the reporting management module. The configuration management module maintains telemetry parameter thresholds and constructs policy configuration control frames. The reporting management module aggregates event data to generate refined logs. For high-level anomalies, the refined logs are reported to the network controller and simultaneously recorded locally; for non-high-level anomalies, the refined logs are only recorded locally. The policy library module interacts bidirectionally with the adaptive decision engine module for storing, querying, and updating multi-level telemetry policies.

[0108] The event analysis module is used to perform preliminary analysis and classification of abnormal signals reported from the data plane. The abnormal signals are abnormal event reporting frames from the high-speed internal communication channel. Each abnormal event reporting frame includes the abnormal event type, trigger timestamp, five-tuple information, flow label associated with the service data packet, and telemetry parameters acquired by the abnormality perception module when the abnormal event is triggered. The abnormal event type includes queue congestion, latency exceeding a threshold, and packet loss rate exceeding a threshold. The trigger timestamp is the current time when the abnormal event is triggered. The five-tuple information includes: source IP address, destination IP address, transport layer source port, transport layer destination port, and transport layer protocol number. The flow label is the flow label associated with the service data packet when the abnormal event is triggered. The event analysis module extracts event features from abnormal event reporting frames, executes a classification algorithm, filters noise signals, and outputs refined event metadata, including abnormal event type, event level, 5-tuple information, flow label, and event timestamp. If the event level is high, such as in cases of persistent congestion or high packet loss, the event analysis module generates a preliminary reporting identifier signal in parallel to notify the reporting management module. If the event level is low or medium, the signal is only output to the adaptive decision engine module and not to the reporting management module.

[0109] The configuration management module is used to maintain telemetry parameter thresholds and construct policy configuration control frames. It serves as an input reference for decision results and a module for issuing and executing decisions, and has a bidirectional dependency with the event analysis module and the adaptive decision engine. Input signals include decision command signals from the adaptive decision engine module, such as mode switching signals (e.g., switching from end-to-end E2E to hop-by-hop trace / direct export DEX) or sampling rate update signals, and optional network controller feedback signals, such as parameter update frames (containing threshold adjustment data). Based on the decision command signals, policy configuration control frames are constructed. These frames include 5-tuple information, updated flow labels, updated sampling modes (i.e., hop-by-hop trace mode, end-to-end E2E mode, or direct export DEX mode), and sampling rate N information; they are then sent to the data plane via a high-speed internal communication channel.

[0110] The adaptive decision engine module integrates the refined event metadata output by the event analysis module and the query result signals from the policy library module, executes adaptive algorithms (e.g., judging abnormal escalation or normal fallback based on event level and timer), analyzes and generates decision instructions, outputs decision instruction signals to the configuration management module, outputs refined reporting signals to the reporting management module, and updates request signals to the policy library module. The adaptive decision engine module integrates an event timer, performing low-overhead baseline decision-making when a network node is initialized; high-precision decision-making when the event level increases; and fallback decision-making when the event level decreases, employing a low-overhead sampling strategy to ensure closed-loop stability.

[0111] The adaptive algorithm of the adaptive decision engine module is designed as a multi-level adaptive monitoring state machine, which breaks through the traditional binary switching (i.e., only baseline and high precision, an either / or) limitation, to achieve the optimal balance between monitoring overhead and fault location accuracy; the multi-level adaptive monitoring state machine specifically includes:

[0112] State 0, i.e. baseline monitoring state: the system default state, executing end-to-end E2E mode and low sampling rate (e.g., N=100), only collecting basic path information, maintaining extremely low system overhead;

[0113] State 1, i.e. suspected confirmation or medium-precision monitoring state: enters when a transient anomaly or low-level event is detected, and performs medium sampling rate (e.g., N=10) or lightweight direct export DEX mode to prevent system hypersensitive triggering;

[0114] State 2, i.e. fault location or high-precision monitoring state: Entered when the abnormality is confirmed to be continuous in State 1 or a high-severity event is detected. Full-volume hop-by-hop tracing Trace mode or high-frequency direct export DEX mode (e.g., N=1) is executed to collect complete metadata to achieve microsecond-level fault location.

[0115] The policy switching logic follows the principle of "rapid escalation and smooth fallback": based on the frequency or severity level of events reported by the data plane, the policy can be escalated from state 0 to state 2 step by step or skipping levels. At the same time, the system introduces an event timer mechanism. If the event timer does not detect any new abnormal events within a preset time window (e.g., T=500ms), the network state is determined to be stable, triggering the policy fallback logic to fall back the monitoring state from state 2 to state 1, or directly reset back to state 0, thereby realizing dynamic resource release and closed-loop self-healing.

[0116] The strategy library module stores and manages multi-level telemetry strategies, serving as an auxiliary storage module for the adaptive decision engine module and exhibiting a bidirectional dependency with it. Input signals include query request signals and update request signals from the adaptive decision engine module. The strategy library module maintains a strategy table and employs an efficient hash index algorithm to quickly respond to queries. The output signal is the matched query result signal, delivered to the adaptive decision engine module. The strategy library module supports dynamic updates, ensuring strategy consistency and adaptive flexibility.

[0117] The reporting management module aggregates the refined reporting signals output by the adaptive decision engine module and the preliminary reporting identification signals output by the event analysis module to generate a refined log. The refined log includes the exception type, exception level, timestamp, five-tuple, and updated policy. The reporting management module performs hierarchical processing based on the exception level: for high-level exceptions, the refined log is reported to the network controller and simultaneously recorded locally; for non-high-level exceptions, the refined log is only recorded locally.

[0118] The data plane of this invention is responsible for supporting the forwarding and processing capabilities of Ethernet service data packets based on the IEEE 802.3 standard. During the forwarding process, it senses and monitors the real-time status of the data stream, and reports to the local control plane after detecting an anomaly, thereby realizing real-time detection and triggering of anomalies.

[0119] The data plane includes an interface transmission component, a forwarding rule database, a message forwarding component, an anomaly detection module, and an IOAM processing component. It interacts with the local control plane through a high-speed internal communication channel. The interface transmission component processes data frames for external transmission and reception. The message forwarding component performs protocol processing on the received data frames according to the forwarding rule entries stored in the forwarding rule database. The IOAM processing component constructs IOAM upload messages. The anomaly detection module efficiently monitors and reports abnormal states.

[0120] The interface transmission component is used to process the reception, splitting, and assembly of data frames, providing reliable data transmission and flow control capabilities. For different types of physical interfaces, the interface transmission component adopts a differentiated module configuration scheme: for multiple service physical interfaces in the system, a pair of input processing modules and output processing modules are instantiated under each interface, which are responsible for the reception and transmission processing of the interface respectively; for the physical interface for IOAM uploading message output in the telemetry system of this invention, only the IOAM output module is instantiated under this interface, and the above-mentioned input processing module and output processing module are not included.

[0121] The input processing module receives data from the corresponding service physical interface and performs protocol adaptation, format conversion, and preliminary processing of service data packets. It performs preliminary parsing of the received service data packets, extracts information to assemble metadata, and transmits it synchronously with the service data packets. The input signal is in the Advanced Extensible Interface 4-Stream (AXI4-Stream) interface format defined by the Advanced Microcontroller Bus Architecture (AMBA) specification. After clock domain synchronization, each input processing module outputs service data packets carrying metadata to the packet forwarding component in parallel.

[0122] The output processing module is used to deliver the service data packets that have completed the routing and forwarding processing of the packet forwarding component to the corresponding service physical interface and output them. The input signal is the internal interface format of the data plane, which supports the AXI4-Stream protocol or user-defined data frame protocol. The output signal is the data packet format corresponding to the service physical interface. The output processing module receives the output from the packet forwarding component and the service data packets distributed by the interface transmission component. That is, the interface transmission component performs decoupling chip selection according to the destination port number, distributes the packets to the output processing module corresponding to the service physical interface, and performs protocol adaptation and format conversion according to the physical interface specification to ensure that the service data packets can be correctly sent to the physical link.

[0123] The IOAM output module is used to deliver the IOAM uplink message constructed by the IOAM processing component to the sampling physical interface and output it. The input signal is the data plane internal interface format, which supports the AXI4-Stream protocol or user-defined data frame protocol. The output signal is the data packet format corresponding to the sampling physical interface. Protocol adaptation and format conversion are performed according to the physical interface specification to ensure that the IOAM uplink message can be correctly sent to the physical link.

[0124] The packet forwarding component is a core functional module of the data plane. It is primarily used to parse, match, and forward received service data packets carrying metadata based on forwarding policies stored in the forwarding rule database. It accesses ACL policy rules, performs IOAM node processing and raw packet processing, and collects sampling information. The packet forwarding component includes a polling scheduling module, an ACL policy matching module, a flow classification module, a route forwarding lookup module, a packet processing module, and a queue management module.

[0125] The polling scheduling module, as the entry scheduling unit of the packet forwarding component, receives service data packets carrying metadata that are output in parallel by multiple input processing modules in the interface transmission component. It adopts a fair round-robin scheduling strategy to sequentially poll and select the input processing module interface with the currently existing data packet, and time-division multiplexes the multiple parallel data into one service data packet carrying metadata, and outputs it to the ACL policy matching module.

[0126] The ACL policy matching module is used to process a service data packet carrying metadata output from the polling scheduling module. Using the packet's five-tuple information as a lookup index signal, it queries the Access Control List (ACL) entries in the forwarding rule database to obtain IOAM processing actions and IOAM configuration information. Combining the IOAM processing actions and the flow label field in the service data packet, it executes the IOAM node determination method to determine the current node type and obtains the IOAM uploading mode signal based on the current node type. If the current node type is an IOAM encapsulation node, it obtains the IOAM uploading mode signal based on the IOAM configuration information; if the current node type is an IOAM transport node or an IOAM decapsulation node, it obtains the IOA based on the IOAM header carried in the service data packet. The M-mode signal is sent up; and further, an IOAM trigger signal is constructed based on the IOAM up-mode signal and the current node type signal, and written into the metadata along with the sampling template signal in the IOAM node type and IOAM configuration information. At the same time, the IOAM trigger signal, IOAM up-mode signal, IOAM node type signal and IOAM configuration information are output to the IOAM processing component as IOAM metadata; otherwise, the metadata is not updated, and finally the service data packet and metadata are output to the flow classification module; the ACL policy matching module extracts the five-tuple information from the service data packet carrying metadata output from the polling scheduling module, indexes the access control list ACL entries in the forwarding rule database, performs policy query, and outputs the query result to the IOAM processing component.

[0127] The IOAM node determination method is specifically divided into two stages: the initial flow tag matching stage and the final IOAM node type determination stage.

[0128] 1. Preliminary Flow Label Matching Stage: The ACL policy matching module extracts the flow label field from the IPv6 basic header of the service data packet for judgment. If the flow label value is within the preset range, the node type is initially determined to be an IOAM transport node or an IOAM decapsulation node. If the flow label value is not within the preset range, the node type is an IOAM encapsulation node or a non-IOAM node, and the judgment needs to be combined with the IOAM processing action.

[0129] II. Final Determination of IOAM Node Type: Based on the results of the initial matching phase between IOAM processing actions and flow tags, the node type is determined to be either an IOAM encapsulated node or a non-IOAM node; the matching method is as follows:

[0130] (1) If the IOAM processing action is encapsulation, then the current node is the encapsulation node and the IOAM encapsulation operation needs to be performed;

[0131] (2) If the stream label matches and the IOAM processing action is decapsulation, then the current node is the decapsulation node and the IOAM decapsulation operation needs to be performed;

[0132] (3) If the stream tag matches and the IOAM processing action is not encapsulation or decapsulation, then the IOAM transport node operation is executed;

[0133] (4) Otherwise, it is determined to be a non-IOAM node and no IOAM-related operations are performed.

[0134] IOAM upload modes include hop-by-hop tracking (Trace) mode, end-to-end E2E mode, or direct DEX export mode. The specific method for constructing the IOAM trigger signal is as follows:

[0135] (1) If the IOAM uploading mode is end-to-end E2E, and the current node type is IOAM encapsulation node or IOAM decapsulation node, then construct the IOAM trigger signal;

[0136] (2) If the current IOAM uploading mode is hop-by-hop tracing and the current node type is IOAM decapsulation node, then construct the IOAM trigger signal;

[0137] (3) If the IOAM upload mode is direct export of DEX, and the current node type is IOAM encapsulation node, IOAM transmission node or IOAM decapsulation node, then construct the IOAM trigger signal.

[0138] Otherwise, the IOAM trigger signal will not be constructed;

[0139] The flow classification module is key to the data plane's implementation of L2, L3, and L4 standard protocol processing. It receives service data packets and metadata from the ACL policy matching module, extracts protocol fields and writes them into the metadata, and outputs the updated metadata and service data packets to the routing forwarding lookup module. If the IOAM trigger signal in the ACL policy matching module is valid, the original service data packets are written to the mirror data cache for the IOAM processing component to read and construct IOAM uploaded packets; otherwise, they do not need to be written to the cache.

[0140] The routing and forwarding lookup module ensures the correct forwarding and addressing of service data packets. It performs a two-stage lookup operation on the updated metadata from the flow classification module and the service data packets. First, it uses the destination IP address in the metadata as the lookup index signal to query the routing and forwarding FIB table entry in the forwarding rule database, obtaining the table entry information signal containing the next-hop IP address and outgoing port number. Then, based on the obtained next-hop IP address as the lookup index signal, it continues to query the Neighbor Discovery Protocol (NDP) table entry in the forwarding rule database, obtaining the table entry information signal containing the link-layer MAC address of the next-hop node. Finally, it adds the complete forwarding information obtained from the query to the metadata and outputs it synchronously to the packet processing module along with the service data packets, performing packet encapsulation and header update.

[0141] The packet processing module is used to perform conventional link layer and network layer header processing on all service data packets, such as MAC address update, IP time-to-live (TTL) decrement and header checksum update, based on the service data packets output by the routing and forwarding lookup module, metadata signals containing complete forwarding information, and IOAM node type signals obtained by the ACL policy matching module, regardless of whether the IOAM policy is hit.

[0142] Based on the IOAM node type signal and IOAM upload mode signal obtained by the ACL policy matching module, it is determined whether differentiated IOAM header or IOAM metadata processing operations need to be performed on the service data packets. The specific determination method is as follows:

[0143] (1) If the current IOAM uploading mode is end-to-end E2E or direct export DEX, then further judgment is made based on the IOAM node type; if it is determined to be an IOAM encapsulation node, then the IOAM header is inserted based on the header processing, and the specific insertion position is between the original data packet UDP header and the payload; if it is determined to be an IOAM decapsulation node, then the IOAM header is removed based on the header processing, and the specific removal position is between the original data packet UDP header and the payload, while clearing the flow tag field in the business data packet header;

[0144] (2) If the current IOAM uploading mode is hop-by-hop tracing, then further judgment is made based on the IOAM node type; if it is determined to be an IOAM encapsulation node, then the IOAM header and IOAM metadata are inserted on the basis of header processing; if it is determined to be an IOAM transmission node, then the IOAM metadata is inserted on the basis of header processing; if it is determined to be an IOAM decapsulation node, then the IOAM header and IOAM metadata are removed on the basis of header processing, and the flow tag field in the business data packet header is cleared at the same time.

[0145] Meanwhile, if the uploading mode signal and sampling rate signal in the IOAM configuration information obtained during the ACL policy matching phase are valid, the fields in the IOAM header also need to be updated; otherwise, the payload structure of the service data packet remains unchanged; finally, after the packet processing module completes all the above processing, it sends the final packet to be forwarded to the queue management module.

[0146] The queue management module is used to perform enqueueing, priority scheduling, and dequeueing operations on the final message output from the packet processing module or the IOAM uploading message output by the IOAM processing component in the specified port output mode. Regarding the support for flow-based detection information collection, the queue management module identifies service data packets that carry IOAM trigger signals in the metadata. During the message dequeueing stage, it acquires and calculates the message enqueueing time, message dequeueing time, message forwarding delay, message buffer occupancy, and packet loss count information due to congestion. Based on the IOAM sampling template information carried in the metadata, it filters out one or more telemetry parameter information from the above information and writes it into the IOAM sampling information cache for the IOAM processing component to read for IOAM metadata assembly. The message forwarding delay is the difference between the message dequeueing time and the message enqueueing time. Simultaneously, the queue management module outputs the service data packets that have completed scheduling and dequeueing operations to the output processing module in the interface transmission component, which then performs subsequent physical interface transmission processing.

[0147] The forwarding rule database is used to store and manage the lookup table module, which includes Access Control List (ACL) entries, Routing Forwarding (FIB) entries, and Neighbor Discovery Protocol (NDP) entries.

[0148] The lookup table module, as the core functional module of the forwarding rule database, provides routing table entry configuration and matching interfaces, and supports hardware offloading of Access Control List (ACL) entries, Forwarding Information Base (FIB) entries, and Neighbor Discovery Protocol (NDP) entries. Each table is used for different service data forwarding and IOAM node processing action determination. It takes the lookup index signal output by the corresponding module in the packet forwarding processing component as input, and outputs the matched entry information if the lookup is successful. Specifically: the Forwarding Information Base (FIB) entry is used for packet forwarding policy matching, using the destination IP address as the lookup index signal to obtain the entry information signal containing the next-hop IP address and outgoing port number; the Neighbor Discovery Protocol (NDP) entry is used to obtain the link-layer MAC address of neighboring devices, using the next-hop IP address as the lookup index signal to obtain the entry information signal containing the link-layer MAC address of the next-hop node; the Access Control List (ACL) entry uses the five-tuple information output by the ACL policy matching module as the lookup index signal. The system retrieves the IOAM monitoring policy, enabling flexible and on-demand configuration of the IOAM monitoring policy. The five-tuple information includes: source IP address, destination IP address, transport layer source port, transport layer destination port, and transport layer protocol number. The IOAM monitoring policy includes IOAM processing actions and IOAM configuration information. IOAM processing actions include determining whether the node performs IOAM encapsulation or decapsulation operations. IOAM configuration information includes the IOAM domain namespace number, flow label, IOAM upload mode, sampling information template, sampling rate N, and specified output port. IOAM upload modes include hop-by-hop tracing, end-to-end E2E, or direct DEX export. Access Control List (ACL) entry information is output to the ACL policy matching module of the IOAM processing component.

[0149] The anomaly detection module is used to monitor the status of the data flow in the data plane in real time, including forwarding latency, packet loss, and queue congestion information. It identifies abnormal events based on telemetry parameter thresholds and outputs an abnormal event reporting frame to the event analysis module in the local control plane via a high-speed internal communication channel, triggering adaptive decision-making in the local control plane. Telemetry parameters include metadata signals transmitted in the packet forwarding component and collected forwarding latency, packet loss, and queue congestion information. In practical scenarios, Explicit Congestion Notification (ECN) flags can also be used as trigger indicators.

[0150] The IOAM processing component is used to trigger the construction of IOAM uploading messages. Internally, it includes a policy matching module, an IOAM encapsulation information acquisition module, an IOAM uploading message construction module, and an outbound path decision module; wherein:

[0151] The policy matching module is used to process the IOAM trigger signal, IOAM upload mode, IOAM node type signal, and IOAM configuration information output by the ACL policy matching module. If the IOAM trigger signal is valid, the IOAM upload message is constructed, the IOAM configuration information is parsed, the IOAM upload mode, sampling template signal, IOAM sampling rate, and specified output port information are obtained, metadata is written, and output to the IOAM encapsulation information acquisition module; otherwise, the IOAM upload message is not constructed.

[0152] The IOAM encapsulation information acquisition module is used to read the image data cache, IOAM sampling information cache, and metadata information output by the policy matching module. Based on the IOAM node type signal and IOAM upload mode signal, it acquires and constructs the necessary information for the IOAM upload message. The construction information includes the message header, UDP header, IOAM header, and IOAM metadata information. The method for acquiring the construction information is as follows:

[0153] (1) Message header: The message header is obtained by reading the mirror data cache; (2) UDP header: If the current IOAM node type is an IOAM encapsulation node, the UDP header is provided by the local control plane; otherwise, it is obtained by reading the mirror data cache; (3) IOAM header: If the current IOAM node type is an IOAM encapsulation node, the IOAM header is provided by the IOAM configuration information output by the ACL policy matching module; otherwise, it is obtained by reading the mirror data cache; (4) IOAM metadata: If the current IOAM upload mode is end-to-end E2E or direct export DEX, the IOAM metadata only contains the current node information and is obtained by reading the telemetry parameter information stored step by step in the IOAM sampling information cache; If the current IOAM upload mode is hop-by-hop tracing, the IOAM metadata contains the current node information and the upstream node information in the IOAM network measurement path. The current node information is obtained by reading the telemetry parameter information stored step by step in the IOAM sampling information cache, and the upstream node information is obtained by reading the mirror data cache;

[0154] Finally, the IOAM encapsulation information acquisition module outputs the construction information to the IOAM uploading message construction module in a timely manner.

[0155] The IOAM uploading message construction module integrates and encapsulates the construction information provided by the IOAM encapsulation information acquisition module into an IOAM uploading message conforming to the format defined by the RFC9326 standard, calculates and updates the checksum field in the IOAM metadata, and outputs the constructed IOAM uploading message to the outgoing path decision module.

[0156] The egress path decision module is used to specify forwarding strategies for the constructed IOAM uplink messages. It has two modes: specified output port and fixed output port. The egress path decision module receives IOAM uplink message data and the specified output port signal from the IOAM configuration information. If the specified output port signal is valid, the egress path decision module generates scheduling information according to the configured specified output port signal and outputs it to the queue management module in the message forwarding component along with the IOAM uplink message. Otherwise, the fixed output port forwarding strategy is adopted, and the IOAM uplink message is output to the IOAM output module in the interface transmission component. The specified output port strategy is dynamically learned and configured by the local control plane. The local control plane configures the specified output port of the dynamically calculated IOAM uplink message into the access control list (ACL) entry in the forwarding rule database, which is more suitable for highly dynamic topology scenarios. This system uses the fixed output port output strategy by default. Through a non-loopback method, there is no need to re-enter the message forwarding component to apply for and release queues, which further reduces the system latency and resource consumption.

[0157] The positions of the ACL policy matching module and the flow classification module in the packet forwarding component can be interchanged; wherein:

[0158] The flow classification module is used to parse the protocol field in the packet header to accurately classify the packet. It takes a service data packet carrying metadata from the output of the polling scheduling module as input, parses the protocol field in the packet header, adds the parsed packet five-tuple information to the metadata, outputs it along with the original packet, and outputs the updated metadata and service data packet to the ACL policy matching module.

[0159] The ACL policy matching module is used to query the ACL entries in the forwarding rule database based on the updated metadata and service data packets output from the flow classification module, using the packet's five-tuple information as a lookup index signal, to obtain IOAM processing actions and IOAM configuration information; determine the current node type according to the IOAM node determination method; and obtain the IOAM uploading mode signal based on the current node type; if the current node type is an IOAM encapsulation node, then obtain the IOAM uploading mode signal based on the IOAM configuration information; if the current node type is an IOAM transmission node or an IOAM decapsulation node, then obtain the IOA based on the IOAM header carried in the service data packet. The M-mode signal is sent up; and further, an IOAM trigger signal is constructed based on the IOAM up-mode signal and the current node type signal. This signal, along with the sampling template signal in the IOAM node type and IOAM configuration information, is written into the metadata. Simultaneously, the IOAM trigger signal, IOAM up-mode signal, IOAM node type signal, and IOAM configuration information are output to the IOAM processing component as IOAM metadata. Otherwise, the metadata is not updated. Finally, the updated metadata from the ACL policy matching module and the service data packet are output to the route forwarding lookup module. If the IOAM trigger signal is valid, the original service data packet is written to the mirror data cache; otherwise, it is not necessary to write it to the cache.

[0160] The local control plane and data plane interact via a high-speed internal communication channel, which can be physically implemented as a PCIe interface between the CPU and the FPGA. Specifically, the message forwarding component transmits abnormal event reporting frames to the local control plane for processing via the high-speed internal communication channel. The local control plane is responsible for making adaptive decisions and offloading the decision results to the data plane via a policy configuration control frame.

[0161] The high-speed internal communication channel can employ schemes based on direct memory access (DMA), in-band signaling, shared memory, or hardware message queues; among which:

[0162] Option 1: Direct Memory Access (DMA) based solution.

[0163] The data plane can encapsulate abnormal event information (such as stream labels, event types, and timestamps) into a structured data block, and write it directly to the reserved physical memory area of ​​the local control plane through direct memory access (DMA). The agent program of the local control plane can detect the arrival of new data through interrupts or polling, and realize information transmission at the microsecond level.

[0164] Option 2: A solution based on In-band Signaling.

[0165] The data plane can encapsulate abnormal event information into a special internal notification message with a specific MAC / IP address and send it to the local control plane from a dedicated internal port. The agent program of the local control plane receives the event notification by listening to this virtual or physical port. This approach can reuse existing message processing paths with minimal hardware modifications.

[0166] Option 3: A solution based on shared memory or hardware message queues.

[0167] At the hardware design level, a shared memory region can be implemented between the data plane and the local control plane, or a hardware-managed FIFO (First-In, First-Out) message queue can be implemented. The data plane, acting as a producer, pushes events into the queue, and the local control plane, acting as a consumer, retrieves them, achieving an efficient producer-consumer communication model.

[0168] This invention also provides an adaptive and efficient network node telemetry method based on IOAM, comprising the following steps:

[0169] Step 1: The network node is initialized and a low-overhead baseline monitoring policy is loaded. This baseline monitoring policy is uniquely indexed by the five-tuple information in the service data packet. The specific policy is: to execute the end-to-end E2E upload mode, construct the IOAM upload packet with a low sampling rate, and at the same time, the node telemetry parameter information in the IOAM upload packet only includes basic telemetry fields such as node ID and timestamp, so as to minimize the impact on forwarding performance.

[0170] Step 2: The data plane processes service packets in real time, performing baseline monitoring while maintaining line-rate forwarding. The specific implementation process is as follows: The interface transmission component receives multiple service data packets from external service physical interfaces and outputs them to the packet forwarding component; the polling scheduling module aggregates multiple inputs into a single service data packet carrying metadata and outputs it to the ACL policy matching module; the ACL policy matching module obtains the IOAM processing action and IOAM configuration information based on the packet's five-tuple information. The IOAM configuration information includes a low-overhead baseline monitoring policy (executing end-to-end E2E upload mode, constructing IOAM upload packets with a low sampling rate, and the node telemetry parameter information in the IOAM upload packets only includes basic telemetry fields such as node ID and timestamp); the flow classification module parses the protocol fields in the packet header and updates the metadata. If the IOAM trigger signal from the ACL policy matching module is valid, the original service data packet is written to the mirrored data cache; the original data packet is routed... After the forwarding lookup module obtains the next-hop IP address, outgoing port number, and link-layer MAC address, it enters the packet processing module. While processing packet data, the packet processing module performs IOAM header or IOAM metadata processing based on the IOAM node type signal and IOAM uploading mode signal. Subsequently, the queue management module performs packet enqueueing and dequeueing scheduling. During the packet dequeueing phase, the queue management module collects packet queuing delay and buffer usage information according to the baseline monitoring strategy and writes it to the IOAM sampling information buffer. Simultaneously, it outputs the service data packets that have completed routing and forwarding processing to the output processing module of the interface transmission component. Meanwhile, the IOAM processing component reads the aforementioned IOAM sampling information buffer information, triggers the construction of IOAM uploading packets under the baseline monitoring strategy based on IOAM metadata and IOAM configuration information, and outputs them to the physical interface in the interface transmission component according to the port output mode, ultimately completing the forwarding of the IOAM uploading packets.

[0171] Step 3: The anomaly detection module monitors the data flow status of the data plane in real time and determines the event type based on telemetry parameter thresholds, namely latency, packet loss, and queue congestion status.

[0172] Determine whether the telemetry parameter values ​​exceed the preset threshold range, i.e., latency exceeds the preset value (reflecting latency issues), packet loss statistics exceed the preset threshold (reflecting packet loss issues), and queue depth exceeds the preset threshold (indicating congestion risk);

[0173] If no abnormalities are found, return to step 2 and maintain the baseline monitoring status to ensure network performance.

[0174] If an anomaly is detected, the data plane captures the anomaly event data, such as extracting the anomaly event type, trigger timestamp, 5-tuple information, associated flow label, and data plane trigger status such as queue occupancy, forwarding latency, and packet loss count, and constructs anomaly event reporting frames to provide local control plane analysis and decision-making basis.

[0175] The abnormal event reporting frame is input to the event analysis module through a high-speed internal communication channel (such as DMA direct memory access mechanism). The event analysis module performs preliminary analysis and classification processing, and outputs the refined event metadata signal after classification to the adaptive decision engine module. If the event level is high, the preliminary reporting identification signal is output to the reporting management module in parallel.

[0176] Step 4: After receiving the refined event metadata signal, the adaptive decision engine module of the local control plane performs rapid analysis. For example, it executes an adaptive algorithm and generates decision instructions based on the type and level of the abnormal event, such as switching to hop-by-hop tracing Trace mode or directly exporting DEX mode and adding complete telemetry fields, including ingress timestamp, egress timestamp, transmission delay, queue depth, and queue occupancy rate.

[0177] Step 5: The adaptive decision engine outputs decision instruction signals to the configuration management module, refinement reporting signals to the reporting management module, and update request signals to the policy library module;

[0178] Step 6: The configuration management module converts the decision command signal into a data plane executable policy configuration control frame (containing a 5-tuple, stream label, high-precision sampling mode hop-by-hop tracing Trace / direct export DEX, and high sampling rate N), and sends it to the data plane via a high-speed internal communication channel.

[0179] Step 7: The Access Control List (ACL) entries in the data plane receive policy configuration control frames and update the sampling policy based on the five-tuple information. Subsequently, the ACL policy matching module locates abnormal data flows based on the packet five-tuple information and guides subsequent modules to execute the updated high-precision monitoring policy. Specifically, the queue management module collects full network status information according to the high-precision sampling template, including packet enqueue and dequeue times, real-time queue depth, queue occupancy rate, and packet loss statistics, and writes the above information into the IOAM sampling information cache. The IOAM processing component, according to the high-precision monitoring policy, i.e., adopting hop-by-hop tracing or direct DEX export mode and executing high sampling rate, reads the cache and constructs an IOAM upload packet containing complete telemetry field information to achieve hop-by-hop fine-grained monitoring of abnormal flows. At the same time, the data plane continues to maintain the baseline monitoring mode for non-abnormal traffic to avoid overall forwarding performance degradation.

[0180] Step 8: During high-precision monitoring, the data plane continuously determines whether the abnormal state has disappeared. For the same set of telemetry parameters (latency, packet loss, and queue congestion status) from Step 3, it determines whether the telemetry parameter values ​​have fallen back to the preset recovery threshold range, i.e., the latency is continuously lower than the preset threshold, the packet loss statistics are continuously lower than the preset threshold, and the queue depth is continuously lower than the preset threshold. If the abnormal state is determined to persist, Step 7 is executed repeatedly to continue high-precision sampling and capture complete data. If the abnormal state is determined to have disappeared, the adaptive decision engine module evaluates the current state and generates a policy fallback instruction to restore the baseline mode. The configuration management module converts the policy fallback instruction signal into a policy configuration control frame executable by the data plane (including a 5-tuple, stream label, low-precision sampling end-to-end E2E mode, and low sampling rate N), and sends it to the data plane via the high-speed internal communication channel.

[0181] Step 9: The Access Control List (ACL) entries in the data plane receive the policy configuration control frame and update the sampling policy based on the five-tuple information. The ACL policy matching module matches the updated low-precision monitoring policy based on the packet five-tuple information and returns to Step 2 to realize automatic resource optimization and closed-loop control.

[0182] This invention fully embodies the innovative concepts of "hardware triggering, microsecond response, dynamic escalation / deceleration, and automatic fallback." This mechanism, based on local anomaly perception (such as queue depth threshold), ensures a response latency far lower than the millisecond-level control loop of traditional solutions. It achieves accurate capture of instantaneous network events, a significant improvement in fault diagnosis efficiency, and optimized utilization of overall network resources (e.g., maintaining low overhead for 99% of normal time and activating high precision only for 1% of abnormal time).

[0183] One embodiment of this invention provides an adaptive and efficient network node telemetry method based on IOAM. The core of this method lies in real-time monitoring of the data flow status of the data plane through a built-in anomaly detection module, including forwarding latency, packet loss, and queue congestion information. Anomalies are identified based on telemetry parameter thresholds and reported to the local control plane to trigger a closed-loop response in the local telemetry system, achieving microsecond-level dynamic adjustment of the monitoring strategy. This contrasts sharply with the static and low-frequency configuration of traditional centralized solutions, ensuring accurate capture of transient network events while optimizing resource utilization. The specific implementation process of this method in the direct-export DEX sampling mode is as follows... Figure 3 As shown.

[0184] like Figure 3 The diagram shows an adaptive application scenario in a typical network topology under the direct export DEX mode, where network device nodes directly send IOAM uplink messages to the network controller without increasing the length of service messages.

[0185] Example

[0186] This system supports three IOAM upload modes: hop-by-hop tracing (Trace) mode and end-to-end (E2E) mode conforming to IETF RFC 9197, and direct export (DEX) mode conforming to IETF RFC 9326. The schematic diagrams of the IOAM network system under these three modes are shown below. Figure 4 , Figure 5 and Figure 6 As shown. The uploading mode and sampling rate are dynamically adjusted according to the policy configuration control frames issued by the local control plane. For ease of description, the Direct-export (DEX) mode of IOAM flow detection is explained; other modes are similar. In the Direct-export DEX mode, each node in the IOAM domain sends an IOAM uploading message with node telemetry parameter information to the network controller. For input service data packets, if the ACL policy matches, a copy of the original service data packet information is made, and the IOAM processing component completes the encapsulation of the uploading message. The IOAM processing component uses the format "ETH+IP+UDP header+IOAM header+IOAM metadata" to construct and encapsulate the telemetry parameter information, realizing multi-protocol layer encapsulation of the IOAM uploading message. The constructed IOAM uploading message... According to the forwarding strategy, the message is output in two modes: designated output port or fixed output port, and finally sent to the network controller. When the local control plane adopts the baseline low-overhead sampling strategy, the data plane of this system executes the end-to-end E2E mode and low sampling rate. When abnormalities occur in packet forwarding, in order to facilitate real-time, fast and high-precision fault location, the local control plane makes decisions based on the abnormal event reporting frames sent by the data plane, switching to a higher precision sampling rate and switching the IOAM message sending mode according to the abnormal event, guiding the data plane to execute a higher precision sampling strategy, thereby facilitating fault analysis and location.

[0187] like Figure 2 As shown, this embodiment describes the specific processing flow of adaptive telemetry performed by a network node using the system of this invention in an IPv6 unicast service forwarding scenario. This flow achieves dynamic switching between low-overhead baseline monitoring strategies and high-precision monitoring strategies through the collaboration of the anomaly detection module, the adaptive decision engine module of the local control plane, and the data plane. Specifically, it includes the following steps:

[0188] Step 1: The network node is initialized and a low-overhead baseline monitoring strategy is loaded (e.g., configured as end-to-end E2E mode, sampling rate N=100, only adding basic IOAM fields such as node ID and timestamp information); service packets are input from the external service physical interface, and the input processing module in the interface transmission component performs frame verification and data format matching, extracts information, assembles it into metadata and distributes it along the path, and outputs data packet signals carrying metadata information;

[0189] Step 2: The polling scheduling module in the packet forwarding component receives data packets carrying metadata from multiple input processing modules in the interface transmission component. It uses a polling algorithm to select packets sequentially and outputs a single integrated service data packet and metadata to the ACL policy matching module. During this process, the anomaly detection module continuously monitors the data flow status of the local data plane in parallel. If an anomaly is detected—specifically, if the statistical data received from the queue management module exceeds a threshold (e.g., historical packet forwarding latency > 1ms, packet loss rate > 10%, or queue depth > 90%)—the module immediately captures the five-tuple of the anomaly flow, the event type, timestamp, and trigger indicator (such as the current queue depth value). It then outputs the anomaly event reporting frame to the local control plane through a high-speed internal communication channel (e.g., based on direct memory access (DMA)) to ensure microsecond-level fault detection. The anomaly event reporting frame is shown in Table 1.

[0190] Step 3: The event analysis module of the local control plane receives the abnormal signals reported by the anomaly perception module, performs classification and evaluation (distinguishing between instantaneous jitter and continuous anomalies, and assigning a priority of low / medium / high), and queries the threshold parameters from the configuration management module. Subsequently, the adaptive decision engine module integrates the refined event metadata, threshold response, and matching results from the policy library module, executes the adaptive algorithm to generate decision instructions (e.g., switching to hop-by-hop tracing or directly exporting DEX mode, and adjusting the sampling rate to N=1, i.e., full sampling). The configuration management module constructs policy configuration control frames based on the decision instructions, as shown in Table 2. These frames are then sent to the data plane via the high-speed channel to update the ACL entries and sampling policies in the forwarding rule database. If the event level is determined to be high, the reporting management module generates refined logs in parallel and reports them to the network controller.

[0191] Step 4: After the data plane is updated, the ACL policy matching module matches the updated Access Control List (ACL) entries based on the packet's five-tuple; it then confirms the current node type and the updated IOAM upload mode (hop-by-hop tracing, end-to-end E2E, or direct DEX export) and sampling rate N according to the rules (the IOAM upload mode and sampling rate N are obtained as follows: for encapsulation nodes, they are taken from the local control plane configuration; for transmission or decapsulation nodes, they are taken from the IOAM header in the service data packet. If a node in the IOAM network measurement path updates its sampling policy, the packet processing module will update the IOAM upload mode and sampling rate N fields in the IOAM header. Downstream nodes can obtain the updated sampling policy by parsing the IOAM header in the service data packet). Finally, an IOAM trigger signal is constructed, and the configuration and control information required for triggering and constructing the IOAM upload packet is written to the IOAM processing component. The original service data packet and telemetry parameter information are written to the cache, ready for high-precision monitoring.

[0192] Step 5: The flow classification module completes the protocol parsing operation. Based on the forwarding behavior information and packet header field information, it classifies and identifies the service data packets and metadata from the ACL policy matching module. The flow classification module categorizes different types of packets by parsing the protocol packets and outputs the updated metadata and service data packets to the route forwarding lookup module. If the IOAM trigger signal in the metadata is valid, the flow classification module writes the original service data packets into the mirror data cache; otherwise, it does not perform the writing.

[0193] Step 6: The routing and forwarding lookup module completes the table lookup operation, obtains the updated metadata and service data packets output by the flow classification module; accesses the routing and forwarding FIB table entries and the neighbor discovery protocol NDP table entries in the forwarding rule database, and writes the complete forwarding information obtained from the query into the metadata signal. Then, the service data packets and the metadata signal containing the complete forwarding information are output to the packet processing module.

[0194] Step 7: The packet processing module completes the routine link layer and network layer header processing. Simultaneously, based on the IOAM node type signal and IOAM upload mode signal obtained by the ACL policy matching module, it completes the processing of the IOAM header or IOAM metadata. Specifically: if determined to be an encapsulation node (regardless of whether it is currently in hop-by-hop tracing, end-to-end E2E, or direct export DEX mode), IOAM header data is encapsulated between the UDP header and the packet payload. This IOAM header data includes the IOAM-Trace-Type field (as a sampling template, using a bitmask to indicate the specific data types to be collected, such as latency and queue congestion) and the Flags field (used to indicate control status information). If determined to be a decapsulation node, the IOAM header data and flow tag field of the input packet are cleared. If determined to be a transport node or a non-IOAM node, the payload of the original packet is not processed. Inserting the IOAM header in direct export DEX mode here is to facilitate subsequent node identification and to carry local telemetry metadata according to the sampling template information in the IOAM header.

[0195] Step 8: Based on the packet's priority and destination port, the data packet enters the queue management module, where enqueue buffering, priority scheduling, and dequeue operations are performed. During this stage, for packets that hit IOAM node type signals, the system collects the necessary sampling information for IOAM metadata in real time based on an adaptive sampling rate N (which may be high-precision N=1). Specifically, when a packet is dequeued, the queue management module calculates the difference between the dequeue timestamp and the enqueue timestamp to obtain the packet forwarding delay, and feeds this delay data and congestion indicators (such as queue depth) back to the anomaly detection module in Step 2 in real time, providing it along with the data and writing it into the IOAM sampling information cache. Simultaneously, the anomaly detection module continuously determines whether the anomaly has disappeared (e.g., detecting that the queue depth has fallen below a safe threshold). If it has disappeared, it reports to the local control plane to generate a "policy fallback instruction," issuing a baseline recovery policy (e.g., resetting the sampling rate N=100), completing the closed-loop optimization.

[0196] Step 9: The policy matching module in the IOAM processing component performs a two-stage IOAM function matching. If the IOAM uploading processing action is matched, the IOAM encapsulation information acquisition module is notified to read the protocol field data required to construct the uploading message.

[0197] Step 10: The IOAM encapsulation information acquisition module reads the necessary information and encapsulates the IOAM metadata collected from the cache with the IOAM header, UDP header and message header into a standard IOAM uploading message (UDP message); at the same time, the control plane reporting management module generates a refined log (such as exception type, five-tuple), which can be optionally reported to the network controller.

[0198] Step 11: The egress path decision module specifies a forwarding strategy for the constructed IOAM uplink message. Based on the IOAM configuration information, it selects either a specified output port or a fixed output port and outputs the message. If the specified output port signal is valid, the module generates scheduling information and outputs the IOAM uplink message to the queue management module (i.e., it enters the regular forwarding queue and reuses the service message path). Otherwise (the default), the fixed output port strategy is adopted, directly outputting the IOAM uplink message to the IOAM output module in the interface transmission component. This method uses a non-loopback mechanism, eliminating the need to return to step 6 for route lookup, thus significantly reducing system latency and resource consumption.

[0199] Step 12: The data packet is finally delivered to the external service physical interface for transmission. For packets scheduled by the queue management module (service packets or IOAM packets for a specified port), the output processing module completes the transmission processing; for directly output IOAM upload packets, the IOAM output module completes the transmission processing. Both perform chip selection and data frame format conversion operations, sending the IP packet to the physical link to achieve microsecond-level closed-loop response and resource optimization.

[0200] The abnormal event reporting frame contains the abnormal event type, trigger timestamp, five-tuple information, associated flow label, and data plane abnormal event telemetry parameters. When the abnormal event is triggered, the abnormal perception module obtains the telemetry parameters, which include the currently obtained forwarding delay, packet loss status, and queue congestion status information. The format of the abnormal event reporting frame is shown in Table 1.

[0201] Table 1. Frame format for reporting abnormal events

[0202] Serial Number Fields byte count Field Description 1 Synchronization Head 4 0xF1F2C1C2 2 Frame length 2 From frame length to the end 3 type 1 0xF1 4 operate 1 0x01: Query; 0x02: Configuration; 5 Pure Lotus N Five-tuple + Abnormal event type (1B) + Trigger timestamp (4B) + Associated stream tag (20bit) + Queue occupancy (2B) + Forwarding latency (2B) + Packet loss count (2B) 6 CRC 2 Frame length to payload verification

[0203] The policy configuration control frame is used to configure Access Control List (ACL) entries. It uses a 5-tuple as the lookup index signal, which includes: source IP address, destination IP address, transport layer source port, transport layer destination port, and transport layer protocol number. The obtained entry information signals are IOAM processing actions and IOAM configuration information. The IOAM processing actions include determining whether the node performs IOAM encapsulation or decapsulation operations. The IOAM configuration information includes the IOAM domain namespace number, flow label, IOAM uploading message reporting mode, sampling information template, sampling rate N, and specified output port. The IOAM uploading message reporting mode includes hop-by-hop tracing, end-to-end E2E, or direct DEX export. The network monitoring policy is adjusted promptly through adaptive updates to the IOAM uploading mode and sampling rate. The policy configuration control frame format is shown in Table 2.

[0204] Table 2 Policy Configuration Control Frame Format

[0205] Serial Number Fields byte count Field Description 1 Synchronization Head 4 0xF1F2C1C2 2 Frame length 2 From frame length to the end 3 type 1 0x03 4 operate 1 0x01: Query; 0x02: Configuration; 5 Pure Lotus N Five-tuple + IOAM processing action (1B) + IOAM domain namespace number (7b) + stream label (20b) + IOAM upload mode (2b) + sampling template (3b) + sampling rate N (2B), specified output port (1B) 6 CRC 2 Frame length to payload verification

Claims

1. An adaptive and efficient network node telemetry method based on IOAM, characterized in that, Includes the following steps: Step 1: The network node is initialized and the baseline monitoring strategy is loaded. The baseline monitoring strategy is uniquely indexed by the five-tuple information in the service data packet. The specific strategy is: to execute the end-to-end E2E upload mode, construct the IOAM upload message with a low sampling rate, and at the same time, the node telemetry parameter information in the IOAM upload message only contains the basic telemetry fields. Step 2: The data plane processes business packets in real time. While maintaining line-speed forwarding, baseline monitoring is performed. The specific implementation process is as follows: the interface transmission component receives multiple business data packets from external business physical interfaces and outputs them to the packet forwarding component; the polling scheduling module aggregates multiple inputs into one business data packet carrying metadata and outputs it to the ACL policy matching module. The ACL policy matching module obtains IOAM processing actions and IOAM configuration information based on the packet five-tuple information, where the IOAM configuration information includes the baseline monitoring policy; The flow classification module parses the protocol field in the packet header and updates the metadata. If the IOAM trigger signal from the ACL policy matching module is valid, the original business data packet is written to the mirror data cache. After the routing and forwarding lookup module obtains the next-hop IP address, outgoing port number, and link-layer MAC address, the raw data packet enters the packet processing module. While completing message packet processing, the packet processing module performs IOAM header or IOAM metadata processing operations based on the IOAM node type signal and IOAM upload mode signal. Subsequently, the queue management module performs enqueueing and dequeueing scheduling of packets; during the packet dequeueing stage, the queue management module collects packet queuing delay and cache occupancy information according to the baseline monitoring strategy and writes it into the IOAM sampling information cache, while outputting the service data packets that have completed routing and forwarding processing to the output processing module of the interface transmission component. At the same time, the IOAM processing component reads the above-mentioned IOAM sampling information cache information, triggers the construction of IOAM uplink messages under the baseline monitoring strategy according to the IOAM metadata and IOAM configuration information, and outputs them to the physical interface in the interface transmission component according to the port output mode, and finally completes the forwarding of IOAM uplink messages. Step 3: The anomaly detection module monitors the data flow status of the data plane in real time and determines the event type based on telemetry parameter thresholds, namely latency, packet loss, and queue congestion status. Determine whether the telemetry parameter values ​​exceed the preset threshold range; If no abnormalities are found, return to step 2 and maintain the baseline monitoring status to ensure network performance. If an anomaly is detected, the data plane captures the anomaly event data, constructs an anomaly event reporting frame, and inputs the anomaly event reporting frame to the event analysis module through a high-speed internal communication channel. The event analysis module performs preliminary analysis and classification processing on it, and outputs the refined event metadata signal after classification to the adaptive decision engine module. If the event level is high, the preliminary reporting identification signal is output to the reporting management module in parallel. Step 4: After receiving the refined event metadata signal, the adaptive decision engine module of the local control plane analyzes it, executes the adaptive algorithm according to the abnormal event type and level, and generates decision instructions. Step 5: The adaptive decision engine outputs decision instruction signals to the configuration management module, refinement reporting signals to the reporting management module, and update request signals to the policy library module; Step 6: The configuration management module converts the decision command signal into a policy configuration control frame that can be executed in the data plane, and sends it to the data plane via the high-speed internal communication channel; Step 7: The Access Control List (ACL) entries in the data plane receive policy configuration control frames and update the sampling policy based on the five-tuple information. Subsequently, the ACL policy matching module locates abnormal data flows based on the packet five-tuple information and guides subsequent modules to execute the updated high-precision monitoring policy. Specifically, the queue management module collects full network status information according to the high-precision sampling template, including packet enqueue and dequeue times, real-time queue depth, queue occupancy rate, and packet loss statistics, and writes the above information into the IOAM sampling information cache. The IOAM processing component, according to the high-precision monitoring policy, i.e., adopting hop-by-hop tracing or direct DEX export mode and executing high sampling rate, reads the cache and constructs an IOAM upload packet containing complete telemetry field information. At the same time, the data plane continues to maintain baseline monitoring mode for non-abnormal traffic. Step 8: During high-precision monitoring, the data plane continuously determines whether the abnormal state has disappeared. For the same set of telemetry parameters in Step 3, it determines whether the telemetry parameter values ​​have fallen back to the preset recovery threshold range. If the abnormal state is determined to persist, Step 7 is executed repeatedly to continue high-precision sampling and capture complete data. If the abnormal state is determined to have disappeared, the adaptive decision engine module evaluates the current state and generates a policy fallback instruction to restore the baseline mode. The configuration management module converts the policy fallback instruction signal into a policy configuration control frame that can be executed in the data plane and sends it to the data plane through the high-speed internal communication channel. Step 9: The Access Control List (ACL) entries in the data plane receive the policy configuration control frame and update the sampling policy based on the five-tuple information. The ACL policy matching module matches the updated low-precision monitoring policy based on the packet five-tuple information and returns to Step 2 to realize automatic resource optimization and closed-loop control.

2. An adaptive and efficient network node telemetry system based on IOAM, characterized in that, Includes the local control plane and the data plane, wherein: The local control plane includes an event analysis module, a configuration management module, an adaptive decision engine module, a policy library module, and a reporting management module, which interact with the data plane through a high-speed internal communication channel. The event analysis module provides input triggers, the adaptive decision engine module integrates decisions and outputs instructions to the configuration management module and the reporting management module. The configuration management module maintains telemetry parameter thresholds and constructs policy configuration control frames. The reporting management module aggregates event data to generate refined logs. For high-level anomalies, the refined logs are reported to the network controller and simultaneously recorded locally; for non-high-level anomalies, the refined logs are only recorded locally. The policy library module interacts bidirectionally with the adaptive decision engine module for storing, querying, and updating multi-level telemetry policies. The data plane includes an interface transmission component, a forwarding rule database, a message forwarding component, an anomaly detection module, and an IOAM processing component. It interacts with the local control plane through a high-speed internal communication channel. The interface transmission component processes data frames for external transmission and reception. The message forwarding component performs protocol processing on the received data frames according to the forwarding rule entries stored in the forwarding rule database. The IOAM processing component constructs IOAM upload messages. The anomaly detection module monitors and reports anomalies.

3. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 2, characterized in that, The event analysis module is used to perform preliminary analysis and classification of abnormal signals reported by the data plane. It takes abnormal event reporting frames from the high-speed internal communication channel as input and outputs the classified refined event metadata signal to the adaptive decision engine module. If the event level is high, it outputs the preliminary reporting identification signal to the reporting management module in parallel. If the event level is low or medium, it only outputs to the adaptive decision engine module. The configuration management module is used to maintain telemetry parameter thresholds and construct policy configuration control frames. It inputs decision command signals from the adaptive decision engine module and optional network controller feedback signals, constructs policy configuration control frames based on the decision command signals, and outputs the constructed policy configuration control frame signals to the data plane. The adaptive decision engine module receives the refined event metadata signal from the event analysis module and the query result signal from the strategy library module. It integrates the input signals to execute the adaptive algorithm and generate decision instructions. It outputs the decision instruction signal to the configuration management module, the refined reporting signal to the reporting management module, and the update request signal to the strategy library module. The strategy library module receives query request signals and update request signals from the adaptive decision engine module, and is used to store and manage multi-level telemetry strategies and support dynamic updates, and outputs the matched query result signal to the adaptive decision engine module. The reporting management module receives the refined reporting signal output by the adaptive decision engine module and the preliminary reporting identifier signal from the event analysis module, and uses them to aggregate event data to generate refined logs. The reporting management module performs hierarchical processing based on the anomaly level: for high-level anomalies, the refined logs are reported to the network controller and simultaneously recorded locally; for non-high-level anomalies, the refined logs are only recorded locally.

4. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 2, characterized in that, The interface transmission component is used to process the reception, splitting, and assembly of data frames, providing data transmission and flow control. For each service physical interface, the interface transmission component is configured with a pair of input processing modules and an output processing module. For the sampling physical interface that outputs IOAM uplink messages, an IOAM output module is configured, wherein: Each of the input processing modules is used to receive the business data packets of the corresponding business physical interface and perform preliminary parsing, extract information to assemble metadata, transmit it synchronously with the business data packets, and output the business data packets carrying metadata to the packet forwarding component. Each of the output processing modules is used to deliver the service data packets that have undergone routing and forwarding processing by the packet forwarding component to the corresponding service physical interface; The IOAM output module is used to deliver the IOAM uplink message constructed by the IOAM processing component to the sampling physical interface; The packet forwarding component is used to parse, match, and forward received service data packets carrying metadata based on forwarding policies stored in the forwarding rule database. It accesses ACL policy rules, performs IOAM node processing and raw packet processing, and collects sampling information. The packet forwarding component includes a polling scheduling module, an ACL policy matching module, a flow classification module, a route forwarding lookup module, a packet processing module, and a queue management module. The polling scheduling module connects multiple input processing modules in the interface transmission component. It is used to receive the business data packets carrying metadata output by each input processing module, and to perform polling scheduling to aggregate multiple inputs into one business data packet carrying metadata, which is then output to the ACL policy matching module. The ACL policy matching module is used to process a service data packet carrying metadata from the polling scheduling module. It uses the packet's five-tuple information as a lookup index signal to query the Access Control List (ACL) entry in the forwarding rule database to obtain IOAM processing actions and IOAM configuration information. Based on the IOAM node determination method, it determines the current node type and obtains the IOAM uploading mode signal. If the current node type is an IOAM encapsulation node, it obtains the IOAM uploading mode signal based on the IOAM configuration information. If the current node type is an IOAM transmission node or an IOAM decapsulation node, it obtains the IOAM uploading mode signal based on the IOAM header carried in the service data packet. Furthermore, it constructs an IOAM trigger signal based on the IOAM uploading mode signal and the current node type signal, and writes it into the metadata along with the sampling template signal from the IOAM node type and IOAM configuration information. Simultaneously, it outputs the IOAM trigger signal, IOAM uploading mode signal, IOAM node type signal, and IOAM configuration information as IOAM metadata to the IOAM processing component. Otherwise, it does not update the metadata. Finally, it outputs the service data packet and metadata to the flow classification module. IOAM upload modes include hop-by-hop tracking (Trace) mode, end-to-end E2E mode, or direct DEX export mode. The specific method for constructing the IOAM trigger signal is as follows: (1) If the IOAM uploading mode is end-to-end E2E, and the current node type is IOAM encapsulation node or IOAM decapsulation node, then construct the IOAM trigger signal; (2) If the current IOAM uploading mode is hop-by-hop tracing and the current node type is IOAM decapsulation node, then construct the IOAM trigger signal; (3) If the IOAM upload mode is direct export of DEX, and the current node type is IOAM encapsulation node, IOAM transmission node or IOAM decapsulation node, then construct the IOAM trigger signal. Otherwise, the IOAM trigger signal will not be constructed; The flow classification module is used to parse the protocol field in the packet header to accurately classify the packet, extract the protocol field and write it into metadata; it takes the service data packet and metadata from the ACL policy matching module as input, and outputs the updated metadata and service data packet to the route forwarding lookup module; if the IOAM trigger signal from the ACL policy matching module is valid, the original service data packet is written to the mirror data cache, otherwise it is not written to the cache. The routing forwarding lookup module is used to output a table lookup index signal for the metadata and service data packets updated from the flow classification module, query the routing forwarding FIB table entries and the neighbor discovery protocol NDP table entries in the forwarding rule database, write the obtained table entry information signal into the metadata signal, and output the service data packets and the metadata signal containing complete forwarding information to the packet processing module. The packet processing module is used to perform link layer and network layer header processing on the service data packets based on the service data packets output by the routing and forwarding lookup module and the metadata signal containing complete forwarding information. Based on the IOAM node type signal and IOAM uploading mode signal obtained by the ACL policy matching module, it determines whether to perform IOAM header or IOAM metadata processing on the service data packets. The specific determination method is as follows: (1) If the current IOAM uploading mode is end-to-end E2E or direct export DEX, then further judgment is made based on the IOAM node type; if it is determined to be an IOAM encapsulation node, then the IOAM header is inserted based on the header processing; if it is determined to be an IOAM decapsulation node, then the IOAM header is removed based on the header processing, the flow tag field in the business data packet header is cleared, and the processed business data packet is sent to the queue management module; (2) If the current IOAM uploading mode is hop-by-hop tracing, then further judgment is made based on the IOAM node type; if it is determined to be an IOAM encapsulation node, then the IOAM header and IOAM metadata are inserted on the basis of header processing; if it is determined to be an IOAM transmission node, then the IOAM metadata is inserted on the basis of header processing; if it is determined to be an IOAM decapsulation node, then the IOAM header and IOAM metadata are removed on the basis of header processing, and the flow tag field in the business data packet header is cleared. Meanwhile, if the mode signal and sampling rate signal in the IOAM configuration information obtained during the ACL policy matching phase are valid, the fields in the IOAM header will be updated; otherwise, the payload structure of the service data packet will remain unchanged, and the processed service data packet will be directly output to the queue management module. The queue management module is used to perform enqueueing, priority scheduling, and dequeueing operations on the final message output from the packet processing module or the IOAM uplink message output by the IOAM processing component in the specified port output mode. At the same time, the queue management module obtains telemetry parameter information based on the IOAM sampling template information carried in the metadata and writes it into the IOAM sampling information cache. Finally, it outputs the service data packet that has completed the routing and forwarding processing to the output processing module of the interface transmission component. The forwarding rule database is used to store and manage the lookup table module, which includes Access Control List (ACL) entries, Routing Forwarding (FIB) entries, and Neighbor Discovery Protocol (NDP) entries. The forwarding rule database locally configures and stores policy configuration control frames output from the configuration management module of the local control plane; it indexes Access Control List (ACL) entries and performs policy matching based on the lookup index signal output from the ACL policy matching module of the packet forwarding component, and outputs the matched entry information signal back to the ACL policy matching module; it indexes the route forwarding FIB entry storage based on the lookup index signal output from the route forwarding lookup module of the packet forwarding component, performs entry matching, and outputs the matched entry information signal back to the route forwarding lookup module; it also indexes the Neighbor Discovery Protocol (NDP) entries and performs entry matching based on the lookup index signal output from the route forwarding lookup module of the packet forwarding component, and outputs the matched entry information signal back to the route forwarding lookup module. The anomaly detection module is used to monitor the data flow status of the data plane in real time, obtain telemetry parameters by reading the statistical register of the queue management module, determine the type of abnormal event based on the telemetry parameter threshold, and output the abnormal event reporting frame to the event analysis module of the local control plane; wherein, the telemetry parameters include forwarding delay, packet loss and queue congestion status information obtained by monitoring the queue management module; The IOAM processing component is used to trigger the construction of IOAM uploading messages. Internally, it includes a policy matching module, an IOAM encapsulation information acquisition module, an IOAM uploading message construction module, and an outbound path decision module; wherein: The policy matching module is used to process the IOAM trigger signal, IOAM upload mode, IOAM node type signal, and IOAM configuration information output by the ACL policy matching module. If the IOAM trigger signal is valid, the IOAM upload message is constructed, the IOAM configuration information is parsed, the IOAM upload mode, sampling template signal, IOAM sampling rate, and specified output port information are obtained, metadata is written, and output to the IOAM encapsulation information acquisition module; otherwise, the IOAM upload message is not constructed. The IOAM encapsulation information acquisition module is used to read the image data cache, IOAM sampling information cache, and metadata information output by the policy matching module. Based on the IOAM node type signal and IOAM upload mode signal, it acquires and constructs the necessary information for the IOAM upload message. The construction information includes the message header, UDP header, IOAM header, and IOAM metadata information. The method for acquiring the construction information is as follows: (1) Message header: The message header is obtained by reading the mirror data cache; (2) UDP header: If the current IOAM node type is an IOAM encapsulation node, the UDP header is provided by the local control plane; otherwise, it is obtained by reading the mirror data cache; (3) IOAM header: If the current IOAM node type is an IOAM encapsulation node, the IOAM header is provided by the IOAM configuration information output by the ACL policy matching module; otherwise, it is obtained by reading the mirror data cache; (4) IOAM metadata: If the current IOAM upload mode is end-to-end E2E or direct export DEX, the IOAM metadata only contains the current node information and is obtained by reading the telemetry parameter information stored step by step in the IOAM sampling information cache; If the current IOAM upload mode is hop-by-hop tracing, the IOAM metadata contains the current node information and the upstream node information in the IOAM network measurement path. The current node information is obtained by reading the telemetry parameter information stored step by step in the IOAM sampling information cache, and the upstream node information is obtained by reading the mirror data cache; Finally, the IOAM encapsulation information acquisition module outputs the construction information to the IOAM uploading message construction module in a timely manner. The IOAM uplink message construction module is used to integrate the construction information provided by the IOAM encapsulation information acquisition module, encapsulate it into an IOAM uplink message, and output it to the exit path decision module. The exit path decision module is used to specify a forwarding strategy for the IOAM uplink message constructed by the IOAM uplink message construction module. Based on whether the specified output port signal from the IOAM configuration information is valid, it selects either a specified output port or a fixed output port output mode. If the specified output port signal is valid, the IOAM uplink message is output to the queue management module in the message forwarding component; otherwise, the IOAM uplink message is directly output to the IOAM output module in the interface transmission component. The specified output port strategy is dynamically learned and configured by the local control plane, and the local control plane configures the dynamically calculated specified output port of the IOAM uplink message into the access control list (ACL) entry in the forwarding rule database.

5. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 3, characterized in that, The abnormal event reporting frame includes the abnormal event type, trigger timestamp, five-tuple information, flow tag associated with the service data packet, and telemetry parameters obtained by the abnormality perception module when the data plane abnormal event is triggered.

6. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 3, characterized in that, The policy configuration control frame includes 5-tuple information, updated stream label, updated sampling mode, and sampling rate N information.

7. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 3, characterized in that, The adaptive algorithm of the adaptive decision engine module is a multi-level adaptive monitoring state machine, specifically including: State 0, i.e. baseline monitoring state: the system default state, executing end-to-end E2E mode with low sampling rate, only collecting basic path information; State 1, i.e. suspected confirmation or medium-precision monitoring state: entered when a transient anomaly or low-level event is detected, and medium sampling rate or lightweight direct export DEX mode is executed; State 2, i.e., fault location or high-precision monitoring state: Entered when the abnormality is confirmed to be continuous in State 1 or a high-severity event is detected, and full-volume hop-by-hop tracing Trace mode or high-frequency direct export DEX mode is executed to collect complete metadata; Meanwhile, an event timer mechanism is introduced. If the event timer does not detect any new abnormal events within the preset time window, it is determined that the network state is stable, triggering the policy rollback logic to fall back the monitoring state from state 2 to state 1, or directly reset it back to state 0.

8. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 4, characterized in that, The IOAM node determination method is specifically divided into two stages: a preliminary flow tag matching stage and a final IOAM node type determination stage; wherein: In the initial flow label matching stage: the ACL policy matching module extracts the flow label field from the IPv6 basic header of the service data packet for judgment. If the flow label value is within the preset range, the node type is initially determined to be an IOAM transmission node or an IOAM decapsulation node; if the flow label value is not within the preset range, the node type is an IOAM encapsulation node or a non-IOAM node, and the judgment needs to be combined with the IOAM processing action. The final determination stage of the IOAM node type: combining the results of the initial matching stage between IOAM processing actions and flow tags, the node type is determined to be either an IOAM encapsulated node or a non-IOAM node; the matching method is as follows: (1) If the IOAM processing action is encapsulation, then the current node is the encapsulation node and the IOAM encapsulation operation needs to be performed; (2) If the stream label matches and the IOAM processing action is decapsulation, then the current node is the decapsulation node and the IOAM decapsulation operation needs to be performed; (3) If the stream tag matches and the IOAM processing action is not encapsulation or decapsulation, then the IOAM transport node operation is executed; (4) Otherwise, it is determined to be a non-IOAM node and no IOAM-related operations are performed.

9. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 4, characterized in that, The specific implementation methods of the Control List (ACL) entries, Routing Forwarding (FIB) entries, and Neighbor Discovery Protocol (NDP) entries include: The FIB (Forwarding Instructions for International) table entries are used for matching packet forwarding policies. Using the destination IP address as the lookup index signal, they retrieve the entry information signal, which includes the next-hop IP address and the outgoing port number. This retrieved entry information signal is then input into the routing lookup module. The NDP (Neighbor Discovery Protocol) table entries are used to obtain the link-layer MAC address of neighboring devices. Using the next-hop IP address as the lookup index signal, they retrieve the entry information signal, which includes the link-layer MAC address of the next-hop node. This retrieved entry information signal is then input into the routing lookup module. The ACL (Access Control List) table entries use the five-tuple information output by the ACL policy matching module as the lookup index signal to obtain the IOAM (Important Query Management) policy. The five-tuple... The group information includes: source IP address, destination IP address, transport layer source port, transport layer destination port, and transport layer protocol number; the IOAM monitoring policy includes IOAM processing actions and IOAM configuration information. The IOAM processing actions include determining whether the node performs IOAM encapsulation or decapsulation operations. The IOAM configuration information includes the IOAM domain namespace number, flow label, IOAM upload mode, sampling information template, sampling rate N, and specified output port. The IOAM upload mode includes hop-by-hop tracing mode, end-to-end E2E mode, or direct export DEX mode; the access control list (ACL) entry information is output to the ACL policy matching module of the IOAM processing component.

10. The adaptive high-efficiency network node telemetry system based on IOAM according to claim 4, characterized in that, The positions of the ACL policy matching module and the flow classification module in the packet forwarding component can be interchanged; wherein: The flow classification module is used to parse the protocol field in the packet header to accurately classify the packet. It takes a service data packet carrying metadata from the output of the polling scheduling module as input, parses the protocol field in the packet header, adds the parsed packet five-tuple information to the metadata, outputs it along with the original packet, and outputs the updated metadata and service data packet to the ACL policy matching module. The ACL policy matching module is used to query the ACL entries in the forwarding rule database based on the updated metadata and service data packets output from the flow classification module, using the packet's five-tuple information as a lookup index signal, to obtain IOAM processing actions and IOAM configuration information; determine the current node type according to the IOAM node determination method; and obtain the IOAM uploading mode signal based on the current node type; if the current node type is an IOAM encapsulation node, then obtain the IOAM uploading mode signal based on the IOAM configuration information; if the current node type is an IOAM transmission node or an IOAM decapsulation node, then obtain the IOAM header carried in the service data packet. The IOAM uplink mode signal is then sent; furthermore, an IOAM trigger signal is constructed based on the IOAM uplink mode signal and the current node type signal, and written into the metadata along with the sampling template signal in the IOAM node type and IOAM configuration information. At the same time, the IOAM trigger signal, IOAM uplink mode signal, IOAM node type signal, and IOAM configuration information are output to the IOAM processing component as IOAM metadata; otherwise, the metadata is not updated. Finally, the updated metadata from the ACL policy matching module and the service data packet are output to the route forwarding lookup module. Meanwhile, if the IOAM trigger signal is valid, the original service data packet is written to the mirror data cache; otherwise, it is not written to the cache.

Images