A Spatial Network Flow Detection Method

Abstract

The present invention discloses a method for in-flow detection in a spatial network, belonging to the field of communication technologies. The method first receives packets and extracts the Flow Label field in the IPv6 protocol header; then performs node type judgment and sampled packet identification; and then conducts in-flow detection processes for encapsulation nodes, transmission nodes, and decapsulation nodes according to the node types. In the method of the present invention, the compression of in-flow detection data separately compresses the in-band operation, administration, and maintenance option headers and metadata to obtain in-flow detection option headers and metadata, which saves more memory resources; the present invention judges the node types and identifies sampled packets through the Flow Label field in the IPv6 protocol header, which is accurate, efficient, and resource-saving; in addition, a sampling template method is adopted to indicate each node to collect in-flow detection metadata; the in-flow detection option header is added between the UDP / TCP protocol header and the payload of the original packet for transmission to avoid affecting the original packet protocol header.

Description

Technical Field

[0001] The present invention belongs to the field of communication technologies, and particularly relates to a method for in-flow detection in a spatial network. Background Art

[0002] Network telemetry is the basis for network management applications, such as network health monitoring, debugging, fault location, congestion control, load balancing, etc., and provides valuable basic data for tasks such as rapid network fault location, reasonable network capacity planning, and effective network security protection during network management and operation and maintenance.

[0003] For traditional network measurement schemes, according to the measurement methods, they can be roughly divided into active measurement and passive measurement. Active measurement includes ping, traceroute; passive measurement includes technologies such as sFlow and NetFlow. Traditional network measurement schemes are relatively mature in implementation, but there are problems such as coarse granularity, poor real-time performance, and inconsistency with the actual path of service packets. In modern large-scale and complex networks, these disadvantages are becoming increasingly prominent, which has promoted the emergence of new in-band network telemetry technologies. The new scheme emphasizes real-time performance, programmability, and fine granularity, and is an important supplement and optimization direction for traditional schemes.

[0004] In-band measurement completes the collection of network status data by inserting metadata (Metadata, abbreviated as MD) into the original packets by network nodes. Compared with traditional network measurement schemes, in-band measurement can achieve more fine-grained measurement of network topology, network performance, and network traffic. One implementation method is in-situ operation, administration, and maintenance (In-Situ Operation, Administration, and Maintenance, abbreviated as IOAM), which directly carries network status information such as delay and packet loss in the original packet, so as to achieve real-time measurement that is completely consistent with the network path passed by the packet.

[0005] Currently, in-band measurement techniques are mainly applied to terrestrial networks. Compared with terrestrial networks, space networks have a series of unique characteristics and challenges. First, the dynamic topology of space networks is one of their features. The relative movement between satellites and ground stations causes the network topology to change continuously. Second, satellite-ground link switching is frequent. When a satellite orbits, it will periodically establish or disconnect connections with different ground stations. This frequent switching significantly increases the complexity of network management. In addition, resources in satellite networks are limited. Bandwidth, computing power, storage space, and energy supply are all strictly restricted, which makes the efficient utilization of system resources one of the core issues of the technology. However, in existing in-band measurement methods, the lengths of the collected option headers and metadata are relatively long, and the identification of the traffic to be collected is relatively complex, increasing the data load of the network and the overhead of system resources. This phenomenon is exacerbated especially in high-traffic or high-load situations. Therefore, in the resource-constrained space network environment, existing in-band measurement methods are subject to certain limitations. For the above reasons, there is an urgent need for a flow detection method that is both resource-saving and simple and efficient in space networks. Summary of the Invention

[0006] Object of the Invention: The present invention discloses a space network in-situ flow telemetry (iSFT) method, which optimizes and improves the existing IOAM in-band measurement technology, can better adapt to the space network environment, makes the resources occupied by network measurement less, the measurement more efficient, and the deployment simpler.

[0007] The implementation process of this method is as follows:

[0008] S1. Receive a packet and extract the Flow Label field in the IPv6 protocol header;

[0009] S2. Node type judgment and sampled packet identification:

[0010] S2.1. First, perform node type judgment. If the Flow Label is not within the agreed range, the current node is an encapsulation node, and go to S2.2; otherwise, it is a transmission node or a decapsulation node, and go to 2.3;

[0011] S2.2. The encapsulation node further identifies the sampled packet through whether the flow classification engine hits the sampled flow rule: If it does not hit, it means that in-situ flow detection is not required, and the original packet is directly forwarded; if it hits, go to the S3 encapsulation node in-situ flow detection process;

[0012] S2.3. Both the transmission node and the decapsulation node need to perform in-situ flow detection processing, and enter the S4 transmission node in-situ flow detection process or the S5 decapsulation node in-situ flow detection process according to the specific node type;

[0013] S3. Flow detection process for encapsulation nodes:

[0014] S3.1. Obtain the flow identifier and sampling template of the packet.

[0015] S3.2. Generate a flow detection option header based on the result of data compression, and encapsulate the flow identifier and sampling template into the flow detection option header.

[0016] S3.3. Add the generated flow detection option header to the original packet.

[0017] S3.4. Map the flow identifier to the Flow Label field in the original packet's IPv6 protocol header, and agree that the range of this field indicates whether subsequent nodes perform flow detection.

[0018] S3.5. Perform metadata collection, and collect the flow detection metadata obtained by data compression based on the sampling template.

[0019] S3.6. Encapsulate the collected flow detection metadata and the generated flow detection option header into a UDP packet and send it to the collector.

[0020] S3.7. Forward the original packet carrying the flow detection option header to the next node and end the processing.

[0021] S4. Flow detection process for transmission nodes:

[0022] S4.1. Parse the flow detection option header to obtain the flow identifier and sampling template.

[0023] S4.2. Perform metadata collection, and collect the flow detection metadata obtained by data compression.

[0024] S4.3. Encapsulate the collected flow detection metadata and the flow detection option header into a UDP packet and send it to the collector.

[0025] S4.4. Forward the original packet carrying the flow detection option header to the next node and end the processing.

[0026] S5. Flow detection process for decapsulation nodes:

[0027] S5.1. Parse the flow detection option header to obtain the flow identifier and sampling template.

[0028] S5.2. Perform metadata collection, and collect the flow detection metadata obtained by data compression.

[0029] S5.3. Encapsulate the collected flow detection metadata and the flow detection option header into a UDP packet and send it to the collector.

[0030] S5.4. After processing, remove the in-flow detection option header from the original message;

[0031] S5.5. Forward the original message after removing the additional information to the next node to end the processing;

[0032] In the present invention, the data compression separately compresses the in-band operation, administration, and maintenance option header and the metadata to obtain the in-flow detection option header and the in-flow detection metadata, saving overhead while ensuring the detection performance;

[0033] The sampled message identification determines the node type and identifies the sampled message at each node through the Flow Label field in the IPv6 protocol header, simplifying the identification process of the in-flow detection message for the transmission node and the decapsulation node;

[0034] The metadata collection indicates to each node to collect the in-flow detection metadata based on the sampling template method, achieving simplicity and efficiency;

[0035] The in-flow detection option header addition adds the in-flow detection option header between the UDP / TCP protocol header and the payload of the original message to avoid affecting the original message protocol header.

[0036] Further, the data compression means that according to the RFC standard and combined with the characteristics of the satellite network, each data field defined in the standard is compressed separately: compress the IOAM option header from 16 bytes to 8 bytes to obtain the in-flow detection option header; compress the IOAM metadata, the original length of the field is 36 bytes, compressed to 20 or 24 bytes to obtain the in-flow detection metadata, enhancing the detection function while saving system resources.

[0037] Further, for the sampled message identification, the node type is determined and the sampled message is identified through the Flow Label field in the IPv6 protocol header. The 20-bit Flow Label field is used to determine whether the message needs to be subject to in-flow detection: First, at the encapsulation node, configure the flow to be sampled and the flow identifier (Flow ID) adopted by the flow. The Flow ID is mapped to the Flow Label field in the IPv6 header before forwarding the message. The flow is represented by an n-tuple, where n can be the 5-tuple of TCP / IP or one of the 1-tuple, 2-tuple, 3-tuple, 4-tuple, depending on the granularity of the sampling object; Second, the node can distinguish whether it is an encapsulation node by judging whether the value of the Flow Label is within the agreed range; at the transmission node and the decapsulation node, further judge whether the incoming message needs to be subject to in-flow detection through the Flow Label.

[0038] Further, the metadata collection refers to the in-flow detection metadata indicated by the 3-bit sampling template Template method, that is, 3 bits are reserved in the in-flow detection option header to store the sampling template. The metadata measured by the in-flow detection method proposed in the present invention can be divided into three categories: delay, packet loss, and congestion. Therefore, the template is divided into 8 types, namely 000: [node information], 001: [delay], 010: [packet loss], 100: [congestion], 011: [delay packet loss], 101: [delay congestion], 110: [packet loss congestion], 111: [delay packet loss congestion]. After receiving the packet, the encapsulation node performs sampling flow identification and matching. If the sampling flow rule is hit, in-flow detection needs to be performed, the sampling template Template of the flow is obtained, stored in the in-flow detection option header, and added to the original packet, and reaches the next node along with the original packet. The transmission node and the decapsulation node determine which in-flow detection metadata needs to be collected at this node according to the sampling template field in the in-flow detection option header.

[0039] Beneficial effects

[0040] 1. The present invention provides a data compression method for in-flow detection, which compresses the IOAM option header and IOAM MD respectively to obtain the in-flow detection option header and metadata; compresses the IOAM option header from the existing 16 bytes to 8 bytes, saving 8 bytes of space, and the compression rate is 50%; performs lightweight reconstruction on the standard-defined IOAM MD. The total length of the original data is 36 bytes, and only 20 or 24 bytes are required after compression, covering the core detection indicators of space network delay, congestion, and packet loss while reducing the overhead by 33%.

[0041] 2. The in-flow detection metadata collection of the present invention is based on the 3-bit sampling template Template method, which has less resource overhead, is easier to implement, and is more efficient compared with the 24-bit setting method defined by RFC9326.

[0042] 3. The sampling packet identification of the present invention judges the node type and identifies the sampling packet through the Flow Label field of the IPv6 protocol header, simplifies the identification process of the in-flow detection packet by the transmission node and the decapsulation node; saves resources and is simple to deploy.

[0043] 4. The addition of the in-flow detection option header of the present invention is to add the in-flow detection option header between the UDP / TCP protocol header and the payload, avoiding the impact on the original packet protocol header; and is simpler and more efficient compared with the existing method of adding the IOAM option header and IOAM MD to the IPv6 Hop-by-Hop Options extension header.

[0044] 5. The in-situ detection method proposed by the present invention improves and optimizes the existing IOAM measurement method according to the characteristics of the space network, provides effective technical support for comprehensively monitoring the space network status, and fills the gap in the field of real-time measurement of the space network. Description of the Drawings

[0045] Figure 1 It is the overall flowchart of the in-situ detection method for the space network;

[0046] Figure 2 It is the IOAM option header format defined by RFC9326;

[0047] Figure 3 It is the compressed in-situ detection option header format;

[0048] Figure 4 It is the IOAM MD format defined by RFC9197;

[0049] Figure 5 It is the compressed in-situ detection metadata format;

[0050] Figure 6 It is the process of encapsulating node message processing;

[0051] Figure 7 It is the process of transmitting node message processing;

[0052] Figure 8 It is the process of decapsulating node message processing;

[0053] Figure 9 It is the schematic diagram of the in-situ detection option header insertion position;

[0054] Figure 10 It is the in-situ detection message encapsulation format in Direct-export mode. Detailed Implementation Manner

[0055] The present invention will be further described below in conjunction with the drawings and specific application scenarios.

[0056] The present invention provides an in-situ space flow telemetry (iSFT) method for the space network. The overall processing flow is as shown in the appendix Figure 1 and mainly includes the following implementation processes:

[0057] S1. Receive the message and extract the Flow Label field in the IPv6 protocol header;

[0058] S2. Node type judgment and sampling message recognition:

[0059] S2.1. First, perform node type judgment. If the Flow Label is not within the agreed range, the current node is an encapsulation node, and proceed to S2.2; otherwise, it is a transmission node or a decapsulation node, and proceed to 2.3. The agreed range of the Flow Label refers to a value range of the Flow Label, which is used to indicate the packets that need to perform in-flow detection. For example, packets with the Flow Label value in the range of [1000, 1000 + 10000] perform in-flow detection.

[0060] S2.2. The encapsulation node further identifies the sampled packets by whether the flow classification engine hits the sampled flow rule: If not hit, it means that in-flow detection is not required, and the original packet is directly forwarded; if hit, proceed to the S3 encapsulation node in-flow detection process.

[0061] S2.3. Both the transmission node and the decapsulation node need to perform in-flow detection processing, and enter the S4 transmission node in-flow detection process or the S5 decapsulation node in-flow detection process according to the specific node type.

[0062] S3. Encapsulation node in-flow detection process:

[0063] S3.1. Obtain the flow identifier and sampling template of the packet.

[0064] S3.2. Generate an in-flow detection option header according to the result of data compression, and encapsulate the flow identifier and sampling template into the in-flow detection option header.

[0065] S3.3. Add the in-flow detection option header, and add the generated in-flow detection option header to the original packet.

[0066] S3.4. Map the flow identifier to the Flow Label field of the original packet's IPv6 protocol header, and agree that the range of this field indicates whether the subsequent node performs in-flow detection; in this embodiment, the range of the Flow Label field is illustrated by taking [1000, 1000 + 10000] as an example.

[0067] S3.5. Perform metadata collection, and collect the in-flow detection metadata obtained by data compression based on the sampling template.

[0068] S3.6. Encapsulate the collected in-flow detection metadata and the generated in-flow detection option header into a UDP packet and send it to the collector.

[0069] S3.7. Forward the original packet carrying the in-flow detection option header to the next node, and end the processing.

[0070] S4. Transmission node in-flow detection process:

[0071] S4.1. Parse the in-flow detection option header to obtain the flow identifier and the sampling template;

[0072] S4.2. Perform metadata collection to collect the in-flow detection metadata obtained through data compression;

[0073] S4.3. Package the collected in-flow detection metadata together with the in-flow detection option header into a UDP packet and send it to the collector;

[0074] S4.4. Forward the original packet carrying the in-flow detection option header to the next node to end the processing;

[0075] S5. In-flow detection process for the decapsulation node:

[0076] S5.1. Parse the in-flow detection option header to obtain the flow identifier and the sampling template;

[0077] S5.2. Perform metadata collection to collect the in-flow detection metadata obtained through data compression;

[0078] S5.3. Package the collected in-flow detection metadata together with the in-flow detection option header into a UDP packet and send it to the collector;

[0079] S5.4. After processing, remove the in-flow detection option header from the original packet carrying the in-flow detection option header;

[0080] S5.5. Forward the original packet after removing the additional information to the next node to end the processing;

[0081] Different from the prior art, in this embodiment, the data compression separately compresses the in-band operation, administration, and maintenance option header and the metadata to obtain the in-flow detection option header and the in-flow detection metadata, saving overhead while ensuring the detection performance;

[0082] The sampling packet identification determines the node type and identifies the sampling packet at each node through the Flow Label field of the IPv6 protocol header, simplifying the identification process of the in-flow detection packets for the transmission node and the decapsulation node;

[0083] The metadata collection indicates to each node to collect the in-flow detection metadata based on the sampling template method, achieving simplicity and high efficiency;

[0084] The addition of the in-flow detection option header adds the in-flow detection option header between the UDP / TCP protocol header and the payload of the original packet to avoid affecting the original packet protocol header.

[0085] Further, the specific implementation process of the data compression is as follows: The present invention performs compression based on the RFC standard of IOAM, improving the formats of the in-flow detection option header and the metadata.

[0086] (1) RFC 9326 defines the standard format of each field in the IOAM option header, and the specific definition is as follows Figure 2 shown. On the premise of ensuring the measurement function, the present invention compresses the data fields in the standard format of the IOAM option header. The improved fields of the in-flow detection option header are listed in Table 1:

[0087] Table 1 In-flow Detection Option Header Fields (8 bytes)

[0088] Field Length Description Namespace (Namespace-ID) 7 bits Identifies the namespace for in-flow detection In-flow Detection Option Type (iSFT-Option-Type, abbreviated as O) 2 bits Indicates the in-flow detection type, including incremental tracking, end-to-end tracking, and direct forwarding Sampling Template (Template, abbreviated as T) 3 bits Sampling template for in-flow detection Flow ID 20 bits Used to identify the flow, set at the encapsulation node Sequence Number 32 bits Message sequence number, used in combination with Flow ID to detect packet loss and out-of-order

[0089] The compressed format of the in-flow detection option header is as follows Figure 3 shown. Compared with the standard format of the IOAM option header in RFC9326, the changed items are listed in Table 2. Among them, the Template field is abbreviated as T, which identifies 8 sampling templates for in-flow detection, namely 000: [Node Information], 001: [Delay], 010: [Packet Loss], 100: [Congestion], 011: [Delay Packet Loss], 101: [Delay Congestion], 110: [Packet Loss Congestion], 111: [Delay Packet Loss Congestion]; the iSFT-Option-Type field is abbreviated as O, which identifies the in-flow detection types, namely 01: Trace, 10: Edge-to-Edge, 11: Direct-export.

[0090] Table 2 Compression Situation and Reason Explanation of the In-flow Detection Option Header of the Present Invention Compared with the Standard Format of the IOAM Option Header

[0091] Field RFC9326 The present invention Description Namespace (Namespace-ID) 16 bits 7 bits The namespace is used to define the boundary of network in-flow detection within a certain period. Compared with terrestrial networks, satellite networks are small in scale due to the constraints of the constellation configuration Flags 8 bits iSFT-Option-Type (O) 2 bits Corresponds to the IOAM-Option-Type in RFC 9486, identifying the in-flow detection type Extension-Flags 8 bits Delete Simplify IOAM Trace Type (IOAM-Trace-Type) 24 bits Template - 3 bits Defines 8 sampling templates (such as delay + packet loss, congestion + delay, etc.), avoiding complex combinations of 24 bits Flow ID 32 bits 20 bits Directly mapped to the Flow Label field in the IPv6 protocol header SequenceNumber 32 bits 32 bits Used to detect packet loss and out-of-order

[0092] The present invention deeply compresses the IOAM option header and collaboratively optimizes the protocol. The standard format of the IOAM option header is 16 bytes, and the length of the obtained in-flow detection option header is 8 bytes. The compression rate is 50%, saving 8 bytes of space.

[0093] (2) RFC 9197 defines the standard format of each field in the IOAM MD. The IOAM MD is different under different acquisition modes. One of the formats is as follows Figure 4 shown. The standard format of the IOAM MD of the present invention is described by taking the most typical IOAM Trace-Type as an example.

[0094] On the premise of ensuring the measurement accuracy and richness, the standard format of the IOAM MD is compressed, and the obtained in-flow detection MD fields are listed in Table 3:

[0095] Table 3 In-flow Detection Metadata Fields (20 / 24 bytes)

[0096] Field Length Description Node ID 16 bits The node ID uniquely identifies a node in the in-flow detection namespace and the associated in-flow detection domain. The spacecraft ID defined by CCSDS is 12 bits Ingress Port ID (abbreviated as in) 3 bits Records the ingress interface of the received message Egress Port ID (abbreviated as eg) 3 bits Records the egress interface of the received message Reserved 10 bits Extended reservation In TimeStamp 32 bits In-device timestamp Out TimeStamp 32 bits Out-device timestamp Transit Delay 32 bits Transit delay (optional) Queue Depth 16 bits Queue depth Buffer occupancy 16 bits Indicates the occupancy status of the common buffer pool used by the current set of queues ChecksumComplement 32 bits Checksum of the incremental part of the message after adding the on-the-fly detection message option header

[0097] The compressed in-flow detection MD format is as shown in the appendix Figure 5 As shown, compared with the IOAM MD described in RFC9197, the changed items are listed in Table 4:

[0098] Table 4 Compression situation and reason explanation of the in-flow detection MD of the present invention compared with the IOAM MD standard format

[0099] Field RFC9197 The present invention Description Hop Lim 8 bits Delete Limit the total hop count of sampling nodes by dividing the size of the namespace monitoring domain Node ID 24 bits 16 bits 16 bits support 65,536 nodes, which can meet the requirements of ultra-large-scale constellations Ingress Port ID 16 bits 3 bits The number of satellite interfaces is limited Egress Port ID 16 bits 3 bits Same as above Reserved None 10 bits Extended reservation In TimeStamp 32 bits 32 bits Retain nanosecond-level accuracy to meet the requirements of high-precision satellite delay measurement Out TimeStamp None 32 bits New field, jointly calculate the node processing and queuing delay with In Timestamp Transit Delay 32 bits 32 bits Indication of node queuing delay namespace-specific data 32 bits Delete Put special extension requirements in the Reserved field Queue Depth 32 bits 16 bits The on-board queue capacity is small (such as in MB), and 16 bits represent 0 - 65,535 messages or percentages Buffer occupancy 32 bits 16 bits The on-board queue capacity is small (such as in MB), and 16 bits represent the occupancy or percentage of the queue cache ChecksumComplement 32 bits 32 bits The bit error rate of the satellite link is high, providing strong error detection capabilities

[0100] Among them, the time stamp is divided into the ingress interface time stamp and the egress interface time stamp. Based on In TimeStamp, OutTimeStamp, and Transit Delay, the processing delay of the packet at the node can be calculated.

[0101] The present invention compresses the IOAM MD data of RFC9197, compressing the original 36 bytes to 20 or 24 bytes, reducing the overhead by 33%, and still completely covering core indicators such as spatial network delay, congestion, and packet loss.

[0102] Furthermore, the specific implementation process of sampling packet identification is as follows: The node type and sampling packets are identified by the flow label FlowLabel in the IPv6 protocol header.

[0103] According to the 20-bit Flow Label field, determine the type of the node where the packet is located and identify the sampling packet. As shown in the appendix Figure 6 As shown, for the received packet, first judge the Flow Label field in the IPv6 protocol header. If it is not within the agreed range, it is an encapsulation node; otherwise, it is a transmission node or a decapsulation node, and enter the corresponding in-flow detection process. At the encapsulation node, further identify and match the sampling flow through the flow classification engine. The packet that hits the sampling flow rule is a sampling packet and needs to be subject to in-flow detection, and enter the in-flow detection process of the encapsulation node. First, obtain the flow identifier Flow ID of the flow, generate an in-flow detection option header, encapsulate the Flow ID into the in-flow detection option header, then add the in-flow detection option header to the original packet, and further map the Flow ID to the Flow Label field in the original IPv6 protocol header, and indicate whether the subsequent transmission node and decapsulation node need to perform in-flow detection by agreeing on the range of the Flow Label. Forward the original packet carrying the in-flow detection option header to the next node.

[0104] As shown in the appendix Figure 7As shown in the figure, the transmission node first obtains the Flow Label field of the original packet carrying the in-flow detection option header, determines whether in-flow detection needs to be performed on this packet according to the Flow Label field. If its value is within the agreed range, in-flow detection is required. Obtain the sampling template Template from the in-flow detection option header, collect in-flow detection metadata according to Template, and encapsulate the in-flow detection metadata combined with the in-flow detection option header into a UDP packet and send it to the collector. The original packet carrying the in-flow detection option header is sent to the next node after forwarding processing.

[0105] As shown in the appendix Figure 8 As shown in the figure, the decapsulation node also makes a judgment according to the Flow Label field in the IPv6 protocol header of the packet. The difference is that at this node, the in-flow detection option header in the original packet carrying the in-flow detection option header needs to be removed to avoid interfering with the data analysis of the destination address.

[0106] Furthermore, the specific implementation process of metadata collection is as follows: Use the sampling template Template to instruct each node to collect in-flow detection metadata.

[0107] The metadata measured by the in-flow detection method proposed by the present invention can be divided into three categories: delay, packet loss, and congestion. Therefore, the template Template is divided into 8 types and requires 3 bits, which are 000: [node information], 001: [delay], 010: [packet loss], 100: [congestion], 011: [delay packet loss], 101: [delay congestion], 110: [packet loss congestion], 111: [delay packet loss congestion].

[0108] The specific matching process and implementation method are as shown in the appendix Figure 6 As shown in the figure, the node first judges the FlowLabel field of the IPv6 protocol header. If it is not within the agreed range, it is an encapsulation node; otherwise, it is a transmission node or a decapsulation node, and enters the corresponding in-flow detection process. At the encapsulation node, further sample flow identification and matching are performed through the flow classification engine. The packet that hits the sample flow rule is a sample packet and needs to perform in-flow detection and enter the in-flow detection process. First, obtain the flow identifier Flow ID and sampling template Template of this flow, collect the in-flow detection MD according to the sampling template, and generate an in-flow detection option header at the same time. Package the sampling template into the in-flow detection option header. Further, add the in-flow detection option header to the original packet. Encapsulate the collected in-flow detection metadata combined with the generated in-flow detection option header into a UDP packet and send it to the collector. The original packet carrying the in-flow detection option header is transmitted to the subsequent transmission node and decapsulation node, as shown in the appendix Figure 6 and Figure 7As shown, the transmission node and the decapsulation node determine the per-flow detection metadata to be collected at this node according to the Template field therein. Specifically, the per-flow detection metadata collected according to the Template field is as follows:

[0109] 000: Collect node information (node ID, Queue Depth, Buffer occupancy).

[0110] 001: Collect delay-related data (In TimeStamp, Out TimeStamp, Transit Delay).

[0111] 010: Collect packet loss-related data (Sequence Number).

[0112] 100: Collect congestion-related data (Queue Depth, Buffer occupancy).

[0113] 011: Collect delay and packet loss-related data (In TimeStamp, Out TimeStamp, Transit Delay, Sequence Number).

[0114] 101: Collect delay and congestion-related data (In TimeStamp, Out TimeStamp, Transit Delay, Queue Depth, Buffer occupancy).

[0115] 110: Collect packet loss and congestion-related data (Sequence Number, Queue Depth, Buffer occupancy).

[0116] 111: Collect delay, packet loss and congestion-related data (In TimeStamp, Out TimeStamp, Transit Delay, Sequence Number, Queue Depth, Buffer occupancy).

[0117] In the IOAM MD of RFC9197, the metadata to be collected is determined by each bit in the 24-bit IOAM-Trace-Type field. Each bit represents a different IOAM metadata item, such as hop limit, node ID, timestamp, queue depth, etc. According to the value of each bit, it is determined whether to collect a specific metadata item. For example, if bit0 is 1, the node ID is collected; if it is 0, it is not collected. If bit1 is 1, the ingress and egress interfaces are collected; if it is 0, they are not collected. This judgment is made in turn, and finally the required IOAM metadata is obtained. Its advantages lie in high flexibility and accuracy, and it can accurately select the collection fields according to requirements. However, due to multiple conditional judgments, bit operations, and dynamic memory allocation, it may lead to high resource consumption, performance degradation, and insufficient concurrent processing capabilities. Moreover, most MD combinations lack practical significance, and the types of commonly used MD are actually determined. In a network environment with high load, large traffic, and limited resources, these problems may significantly affect the stability and response time of the system, thus reducing the overall performance.

[0118] Furthermore, the specific implementation process of adding the per-flow detection option header is as follows: The per-flow detection option header is added between the UDP / TCP protocol header and the payload of the original packet.

[0119] The transmission of existing IOAM data depends on the option field within the IPv6 Hop-by-Hop Extension Header. The IOAM data is encapsulated in the IPv6 Hop-by-Hop Options Header, as shown in the appendix. Figure 9 During the transmission of the packet, each network node executes the corresponding IOAM MD collection task according to the instructions in the IOAM option header, and then appends the IOAM option header to the end of the hop-by-hop option header sequence.

[0120] However, as known from RFC 9673: IPv6 Hop-by-Hop Options Processing Procedures, the early IPv6 specification forced all nodes to process hop-by-hop options. However, modern high-speed routers often discard or degrade the processing of such packets due to performance bottlenecks. In addition, large extended headers may reduce the router's ability to find subsequent header fields and increase the probability of packet loss. RFC 9673 solves the performance bottleneck and functional failure problems caused by the forced processing of the original specification (RFC 2460) by allowing routers to configure the processing of IPv6 hop-by-hop option headers on demand, improving the practicality of this option in modern networks. However, it still faces challenges such as compatibility conflicts with old devices, potential local security risks exposed by selective processing, vendor implementation differences caused by insufficient standardization, and increased parsing pressure on the host side (especially resource-constrained devices).

[0121] The present invention adds the in-flow detection option header between the UDP / TCP protocol header and the payload, rather than relying on the IPv6 hop-by-hop option header, as shown in the appendix. Figure 9 This can avoid the need to parse and process the IPv6 hop-by-hop option header at each intermediate node, thereby reducing the additional processing overhead of the router; at the same time, it avoids the problem that the IPv6 hop-by-hop option header is discarded or degraded due to complex processing on high-speed routers. In addition, placing the in-flow detection data between the transport layer and the application layer enables terminal devices to directly access and parse this data, facilitating subsequent function expansion and customization, without being restricted by the IPv6 extension header format.

[0122] In order to make the objectives, technical solutions and advantages of the present invention more clear and understandable, the following describes the embodiments of the present invention in detail with reference to the accompanying drawings: These embodiments are implemented on the premise of the technical solution of the present invention, and detailed implementation manners and specific operation processes are given. The specific examples described herein are only used to explain the present invention, but the protection scope of the present invention is not limited to the following embodiments.

[0123] According to the different types of in-flow detection data collection, it can be divided into three data collection modes: Direct-export direct upload mode, Trace incremental mode, and Edge-to-Edge end-to-end mode. Next, the specific application process of the present invention will be described in combination with specific modes:

[0124] A typical in-flow detection scenario and packet encapsulation structure of a satellite network are as Figure 10As shown in the figure. This scenario realizes the transmission of UDP packets based on the Direct-export direct upload mode. The TCP / IP protocol stack of Ethernet (abbreviated as ETH) is used for the description. The Ethernet frame header in its packet encapsulation is marked as "ETH header". The source host sends the original packet encapsulated by Ethernet to the low-earth orbit satellite network and enters the data acquisition module. The node first determines the node type according to the value of the Flow Label field. If it meets the agreed value range, it is a transmission node or a decapsulation node; otherwise, it is an encapsulation node. At the encapsulation node, the flow classification function is further realized through the flow classification engine. The sampled flow is identified and matched using the n-tuple of the packet. After hitting the sampled flow rule, it enters the in-flow detection process of the encapsulation node. First, obtain the sampling template Template and the flow identifier Flow ID, and map the Flow ID to the Flow Label field of the original packet IPv6 protocol header. Then, collect the compressed in-flow detection MD according to Template and generate the in-flow detection option header. The format of the in-flow detection option header is as described in the data compression section, including fields such as Flow ID and Template. Among them, the flow classification engine can be implemented using an Access Control List (ACL). Then, add the in-flow detection option header between the UDP / TCP protocol header and the payload of the original packet, and forward the original packet carrying the in-flow detection option header. At the same time, encapsulate the in-flow detection MD combined with the in-flow detection option header into a UDP packet and send it to the collector. The original packet carrying the in-flow detection option header is transmitted to the subsequent transmission node and decapsulation node. Similarly, the sampled packet is identified according to the Flow Label field in its IPv6 protocol header. If its value is within the agreed range, it is a sampled packet and needs to be processed for in-flow detection. Obtain the Template from the in-flow detection option header, and determine the in-flow detection MD that this node needs to collect according to the Template field. After the collection is completed, it is encapsulated into a UDP packet and sent. For the decapsulation node, it is also necessary to remove the in-flow detection option header in the original packet carrying the in-flow detection option header and forward it to the destination host. In the above process of encapsulating the in-flow detection MD into a UDP packet and sending it to the collector, the UDP packet sent by the node reaches the ground station through the relay satellite, and then reaches the collector of the data analysis module for data collection and storage.

[0125] The basic principle of the Trace incremental mode is the same as that of the Direct-export mode. The difference is that in the Trace incremental mode, there is no need to upload at the encapsulation node and the transmission node. Instead, after adding the collected in-flow detection MD to the in-flow detection option header, finally, at the decapsulation node, the in-flow detection option header and all the collected in-flow detection MD are encapsulated into a UDP packet and sent to the collector, and the in-flow detection data in the original packet carrying the in-flow detection data is removed.

[0126] The basic principle of the Edge-to-Edge (E2E) mode is also the same as that of the Trace incremental mode. The difference is that in the E2E mode, data does not need to be collected at the transmission nodes, and only the on-flow detection MD of the encapsulation node and the decapsulation node needs to be collected.

Claims

1. A spatial network flow detection method, the implementation process of the method is as follows: S1, receive the message and extract the Flow Label field in the IPv6 protocol header; S2. Node type determination and sampled message identification: S2.

1. First, determine the node type. If the Flow Label is not within the agreed range, the current node is an encapsulation node and proceeds to S2.

2. Otherwise, it is a transmission node or a decapsulation node and proceeds to 2.

3. S2.2, the encapsulation node further identifies the sampled message by checking whether the flow classification engine hits the sampling flow rule: if it does not hit, it means that there is no need to perform flow detection and the original message is forwarded directly; If it hits, it will enter the S3 encapsulation node flow detection process; S2.3, both the transmission node and the decapsulation node need to perform on-line detection processing, and enter the S4 transmission node on-line detection process or the S5 decapsulation node on-line detection process according to the specific node type; S3, packaging node flow detection process: S3.

1. Obtain the flow identifier and sampling template of the message; S3.

2. Generate a flow detection option header according to the result of data compression, and encapsulate the flow identifier and sampling template into the flow detection option header; S3.3, adding a flow detection option header, adding the generated flow detection option header to the original message; S3.4, mapping the flow identifier to the Flow Label field of the IPv6 protocol header of the original message, and agreeing on the range of the field to indicate whether the subsequent node performs flow detection; S3.5, performing metadata collection, collecting the in-stream detection metadata obtained through data compression based on the sampling template; S3.6, encapsulating the collected in-flow detection metadata and the generated in-flow detection option header into a UDP message and sending it to the collector; S3.7, forward the original message carrying the flow detection option header to the next node, and end the processing; S4, Transmission node flow detection process: S4.

1. Parse the flow detection option header to obtain the flow identifier and sampling template; S4.2, collecting metadata, collecting the in-stream detection metadata obtained through data compression; S4.3, encapsulating the collected flow detection metadata with the flow detection option header into a UDP message and sending it to the collector; S4.4, forward the original message carrying the flow detection option header to the next node, and end the processing; S5, decapsulation node flow detection process: S5.

1. Parse the flow detection option header to obtain the flow identifier and sampling template. S5.2, collecting metadata, collecting the in-stream detection metadata obtained through data compression; S5.3, encapsulating the collected flow detection metadata with the flow detection option header into a UDP message and sending it to the collector; S5.4, after processing, remove the flow detection option header in the original message; S5.5, forward the original message after removing the additional information to the next node, and end the processing; The data compression is characterized in that the data compression is to compress the in-band operation management and maintenance option header and metadata respectively to obtain the in-stream detection option header and the in-stream detection metadata; The sampled message identification is to determine the node type and identify the sampled message at each node through the flow label Flow Label field of the IPv6 protocol header; The metadata collection is to instruct each node to collect the flow detection metadata based on the sampling template mode, and a 3-bit position is reserved in the flow detection option header to store the sampling template. Each node determines the flow detection metadata to be collected according to the sampling template; The adding of the flow detection option header is to add the flow detection option header between the UDP / TCP protocol header and the payload of the original message.

2. A spatial network flow detection method according to claim 1, characterized in that: The data compression refers to compressing each data field defined in the RFC standard according to the RFC standard and in combination with the characteristics of the satellite network; compressing the in-band operation management and maintenance option header from 16 bytes to 8 bytes to obtain the flow detection option header; The in-band operation management and maintenance metadata is compressed. The original length of the field is 36 bytes, which is compressed to 20 or 24 bytes to obtain the in-stream detection metadata.

3. A spatial network flow detection method according to claim 1, characterized in that: The sampled message identification refers to identifying the sampled message through the 20-bit flow label Flow Label field in the IPv6 protocol header to determine whether the message needs to be detected along with the flow; specifically, for the message received by the node, the Flow Label in the IPv6 protocol header is first judged. If its value is not within the agreed range, it is an encapsulation node and enters the flow classification engine for further sampled flow identification and matching; otherwise, it is a sampled message of a transmission node or a decapsulation node and enters the corresponding along-flow detection processing flow.

4. A spatial network flow detection method according to claim 1, characterized in that: The metadata collection reserves 3 bits in the flow detection option header to store the sampling template. The measured data is divided into three categories: delay, packet loss and congestion. The sampling templates are divided into 8 types, occupying 3 bits, including: 000: [node information]; 001: [Delay]; 010: [Packet loss]; 100: [Congestion]; 011: [Delay and packet loss]; 101: [Delay congestion]; 110: [Packet loss congestion]; 111: [Delay, packet loss, congestion].

Images