Spatial network stream following detection method

Abstract

The invention discloses a spatial network stream following detection method, and belongs to the technical field of communication. The method comprises the following steps: firstly, receiving a message, and extracting a Flow Label field in an IPv6 protocol header; node type judgment and sampling message identification are carried out; and then, according to the node types, carrying out a stream detection process of packaging nodes, transmission nodes and de-packaging nodes. According to the method disclosed by the invention, the stream detection data is compressed by respectively compressing the in-band operation management and maintenance option header and the metadata to obtain the stream detection option header and the metadata, so that more memory resources are saved; according to the method, the node type is judged and the sampling message is identified through the Flow Label field of the IPv6 protocol header, so that the method is accurate and efficient, and resources are saved; in addition, a sampling template mode is adopted to indicate each node to collect stream detection metadata; and adding the stream detection option header between the UDP / TCP protocol header of the original message and the load for transmission so as to avoid the influence on the protocol header of the original message.

Description

Technical Field

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

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

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

[0004] In-band measurement is the collection of network status data by inserting metadata (MD) into the original message by the network node. Compared with traditional network measurement solutions, 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 (IOAM), which directly carries network status information such as latency and packet loss in the original message, thereby achieving real-time measurement that is completely consistent with the network path the message passes through.

[0005] At present, in-band measurement technology is mainly used in ground networks. Compared with ground networks, space networks have a series of unique characteristics and challenges. First, the dynamic topology of space networks is one of its characteristics. The relative movement between satellites and ground stations causes the network topology to change constantly. Secondly, the satellite-to-ground link switches frequently. When satellites are running in orbit, they periodically establish or disconnect connections with different ground stations. This frequent switching significantly increases the complexity of network management. In addition, the resources in satellite networks are limited, including bandwidth, computing power, storage space, and energy supply, which are strictly restricted. This makes the efficient use of system resources one of the core issues of the technology. However, the existing in-band measurement methods have a long length of option headers and metadata collected, which makes it more complicated to identify the traffic to be collected, increasing the data load and system resource overhead of the network, especially in high traffic or high load conditions. Therefore, in a space network environment with limited resources, the existing in-band measurement methods are subject to certain limitations. In view of the above reasons, space networks are in urgent need of a simple and efficient flow detection method that is both resource-saving and efficient. Summary of the invention

[0006] Purpose of the invention: The present invention discloses an in-Situ Space Flow Telemetry (iSFT) method, which optimizes and improves the existing IOAM in-band measurement technology, can better adapt to the space network environment, make network measurement occupy less resources, make measurement more efficient, and make deployment simpler.

[0007] The implementation process of this 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 no flow detection is required and the original message is forwarded directly; if it hits, it enters 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 described in the present invention 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, thereby ensuring the detection performance while saving the overhead; The sampled message identification is to judge the node type and identify the sampled message at each node through the flow label Flow Label field of the IPv6 protocol header, simplifying the identification processing of the transmission node and the decapsulation node with the flow detection message; The metadata collection is based on the sampling template method to instruct each node to collect the flow detection metadata, which is simple and efficient; 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 to avoid affecting the protocol header of the original message.

[0008] Furthermore, the data compression refers to compressing each data field defined in the standard separately according to the RFC standard and in combination with the characteristics of the satellite network: compressing the IOAM option header from 16 bytes to 8 bytes to obtain the in-stream detection option header; compressing the IOAM metadata, the original length of the field is 36 bytes, compressed to 20 or 24 bytes, to obtain the in-stream detection metadata, which enhances the detection function while saving system resources.

[0009] Furthermore, the sampled message identification determines the node type and identifies the sampled message through the flow label field of the IPv6 protocol header, and uses the 20-bit Flow Label field to determine whether the message needs to be detected along with the flow: first, the flow (flow) to be sampled and the flow identifier (Flow ID) used by the flow are configured at the encapsulation node. The Flow ID is mapped to the Flow Label field of the IPv6 header before forwarding the message. The flow is represented by an n-tuple, and n can be a 5-tuple of TCP / IP, or a 1-tuple, 2-tuple, 3-tuple, or 4-tuple, depending on the granularity of the sampling object; secondly, 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, the Flow Label is further used to judge whether the incoming message needs to be detected along with the flow.

[0010] Furthermore, the metadata collection refers to the metadata of the flow detection collected based on the 3-bit sampling template Template mode, that is, the sampling template is stored in the reserved 3-bit position in the flow detection option header. The metadata measured by the flow detection method proposed in the present invention can be divided into three categories: delay, packet loss and congestion, so 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 message, the encapsulation node performs sampling flow identification and matching. If the sampling flow rule is hit, it is necessary to perform flow detection, obtain the sampling template Template of the flow, store it in the flow detection option header, and add it to the original message, and arrive at the next node with the original message. The transmission node and the decapsulation node determine which in-stream detection metadata the node needs to collect based on the sampling template field in the in-stream detection option header.

[0011] Beneficial Effects

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

[0013] 2. The in-stream detection metadata collection of the present invention is based on a 3-bit sampling template. Compared with the 24-bit setting method defined in RFC9326, it has low resource overhead, is easy to implement, and is more efficient.

[0014] 3. The sampled message identification of the present invention determines the node type and identifies the sampled message through the flow label field of the IPv6 protocol header, simplifies the identification processing of the transmission node and the decapsulation node with the flow detection message; saves resources and is simple to deploy.

[0015] 4. The addition of the flow detection option header of the present invention is to add the flow detection option header between the UDP / TCP protocol header and the payload to avoid affecting the original message protocol header; and compared with the existing method of adding the IOAM option header and IOAM MD to the IPv6 Hop-by-Hop Options extension header, the implementation is simpler and more efficient.

[0016] 5. The flow detection method proposed in the present invention improves and optimizes the existing IOAM measurement method according to the characteristics of the space network, provides effective technical support for comprehensive monitoring of the space network status, and fills the gap in the field of real-time measurement of space networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is the overall flow chart of the spatial network flow detection method; Figure 2 The IOAM option header format defined in RFC9326; Figure 3 This is the compressed in-stream detection option header format; Figure 4 The IOAM MD format defined in RFC9197; Figure 5 This is the compressed in-stream detection metadata format; Figure 6 It is the process of encapsulating node message processing; Figure 7 The process of message processing for transmission nodes; Figure 8 The process of decapsulating node message processing; Fig. 9 A schematic diagram of the position of inserting the option header for the flow detection; Fig.10 This is the encapsulation format of the flow detection message in Direct-export mode. DETAILED DESCRIPTION

[0018] The present invention is further described below in conjunction with the accompanying drawings and specific application scenarios.

[0019] The present invention provides an in-Situ Space Flow Telemetry (iSFT) method. The overall processing flow is as shown in the attached figure. Figure 1 As shown, the implementation process mainly includes the following: 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. The agreed range of Flow Label refers to a range of values ​​for Flow Label, which is used to indicate the packets that need to be detected along the flow. For example, packets with an agreed Flow Label value in [1000, 1000+10000] are subject to along-flow detection.

[0020] 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 no flow detection is required and the original message is forwarded directly; if it hits, it enters 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. Map the flow identifier to the Flow Label field of the IPv6 protocol header of the original message, and agree that the range of this field indicates whether the subsequent node performs flow detection; the range of the Flow Label field in this embodiment is described by taking [1000, 1000+10000] as an example.

[0021] 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 is completed, the flow detection option header in the original message carrying the flow detection option header is removed; S5.5, forward the original message after removing the additional information to the next node, and end the processing; Different from the prior art, the data compression described in this embodiment is to compress the in-band operation management and maintenance option header and metadata separately to obtain the in-stream detection option header and the in-stream detection metadata, thereby ensuring the detection performance while saving the overhead; The sampled message identification is to judge the node type and identify the sampled message at each node through the flow label Flow Label field of the IPv6 protocol header, simplifying the identification processing of the transmission node and the decapsulation node with the flow detection message; The metadata collection is based on the sampling template method to instruct each node to collect the flow detection metadata, which is simple and efficient; 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 to avoid affecting the protocol header of the original message.

[0022] Furthermore, the specific implementation process of data compression is as follows: the present invention performs compression based on the RFC standard of IOAM, and improves the in-stream detection option header and metadata format.

[0023] (1) RFC 9326 defines the standard format of each field in the IOAM option header. The specific definition is as follows: Figure 2 The present invention compresses the data field of the IOAM option header standard format under the premise of ensuring the measurement function, and the improved flow detection option header field is listed in Table 1: Table 1 Stream detection option header field (8 bytes) Fields length illustrate Namespace-ID 7bits Identifies the namespace for the flow detection In-stream detection option type (iSFT-Option-Type, referred to as O) 2bits Indicates the type of in-stream detection, including incremental tracking, end-to-end tracking, and direct upload Sampling template (Template, referred to as T) 3bits Sampling template for in-stream detection Flow ID 20 bits Used to identify the flow, set in the encapsulation node Sequence Number 32bits Message sequence number, used in conjunction with Flow ID to detect packet loss and out-of-order The compressed stream detection option header format is as follows: Figure 3 As shown in the figure, compared with the standard format of the IOAM option header in RFC9326, the changes are listed in Table 2, where the Template field is abbreviated as T, which identifies the eight sampling templates of the 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 flow detection type, namely 01: Trace, 10: Edge-to-Edge, 11: Direct-export.

[0024] Table 2: Comparison of the IOAM option header standard format with the compression of the in-stream detection option header of the present invention and the reasons thereof Fields RFC9326 The present invention illustrate Namespace-ID 16 bits 7bits The namespace is used to define the boundaries of network flow detection within a certain period of time. Compared with terrestrial networks, satellite networks are constrained by the constellation configuration and are smaller in scale. Flags 8bits iSFT-Option-Type(O) 2 bits Corresponding to IOAM-Option-Type in RFC 9486, it identifies the type of in-flow detection Extension-Flags 8bits delete simplify IOAM-Trace-Type 24bits Template -3bits Define 8 sampling templates (such as delay + packet loss, congestion + delay, etc.) to avoid complex combinations of 24 bits Flow ID 32bits 20 bits Directly mapped to the Flow Label field in the IPv6 protocol header Sequence Number 32bits 32bits Used to detect packet loss and out-of-order The present invention performs deep compression and protocol collaborative optimization on the IOAM option header. The standard format IOAM option header is 16 bytes, and the compressed in-flow detection option header is 8 bytes long, with a compression rate of 50%, saving 8 bytes of space.

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

[0026] The IOAM MD standard format is compressed under the premise of ensuring measurement accuracy and richness, and the obtained flow detection MD fields are listed in Table 3: Table 3 Stream detection metadata fields (20 / 24 bytes) Fields length illustrate Node ID 16 bits Node ID, uniquely identifies a node in the flow detection namespace and the associated flow detection domain. The spacecraft ID defined by CCSDS is 12 bits. Ingress Port ID (in for short) 3bits Record the incoming interface of the received message Egress Port ID (eg) 3bits Record the output interface of the received message Reserved 10bits Extended Retention In TimeStamp 32bits Enter device timestamp Out TimeStamp 32bits Output device timestamp Transit Delay 32bits Queuing delay (optional) Queue Depth 16 bits Queue Depth Buffer occupancy 16 bits Indicates the occupancy status of the common buffer pool currently used by a group of queues ChecksumComplement 32bits Add the checksum of the incremental part of the message after the option header of the flow detection message The compressed in-stream detection MD format is as follows Figure 5 As shown in Table 4, compared with the IOAM MD described in RFC9197, the changes are as listed in Table 4: Table 4: Compression of the in-flow detection MD of the present invention compared with the IOAM MD standard format and the explanation of the reasons Fields RFC9197 The present invention illustrate Hop Lim 8bits delete Limit the total number of hops of sampling nodes by dividing the namespace monitoring domain size Node ID 24bits 16 bits 16 bits supports 65536 nodes, which can meet the needs of ultra-large-scale constellations Ingress Port ID 16 bits 3bits Limited number of satellite interfaces Egress Port ID 16 bits 3bits Same as above Reserved none 10 bits Extended Retention In TimeStamp 32bits 32bits Maintain nanosecond accuracy to meet the needs of high-precision satellite delay measurement Out TimeStamp none 32bits New fields are added to calculate node processing and queuing delays together with In Timestamp Transit Delay 32bits 32bits Indication of node queuing delay Namespace-specific data 32bits delete Special extension requirements are placed in the Reserved domain Queue Depth 32bits 16 bits The onboard queue capacity is small (e.g., MB level), and 16 bits represent 0-65535 messages or percentages Buffer occupancy 32bits 16 bits The onboard queue capacity is small (e.g., MB level), and 16 bits represent the queue cache occupancy or percentage. Checksum Complement 32bits 32bits Satellite links have high bit error rates, providing powerful error detection capabilities The timestamp is divided into the inbound timestamp and the outbound timestamp. Based on the In TimeStamp, OutTimeStamp, and Transit Delay, the processing delay of the message at the node can be calculated.

[0027] 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%, while still fully covering the core indicators such as spatial network delay, congestion and packet loss.

[0028] Furthermore, the specific implementation process of the sampled message identification is as follows: judging the node type and identifying the sampled message through the flow label FlowLabel of the IPv6 protocol header.

[0029] The 20-bit Flow Label field is used to determine the type of node where the message is located and identify the sampled message. Figure 6 As shown, for the received message, first determine the Flow Label 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 flow detection process. At the encapsulation node, the flow classification engine is further used to identify and match the sampling flow. The message that hits the sampling flow rule is a sampling message, which needs to be detected along the flow and enters the encapsulation node flow detection process. First, obtain the flow identifier Flow ID of the flow, generate a flow detection option header, encapsulate the Flow ID into the flow detection option header, then add the flow detection option header to the original message, and further map the Flow ID to the Flow Label field in the IPv6 protocol header of the original message. The agreed Flow Label range indicates whether the subsequent transmission node and decapsulation node need to perform flow detection. The original message carrying the flow detection option header is sent to the next node after forwarding processing.

[0030] As attached Figure 7As shown, the transmission node first obtains the Flow Label field of the original message carrying the flow detection option header, determines whether to perform flow detection on the message according to the Flow Label field, and if its value is within the agreed range, then flow detection is required, obtains the sampling template Template from the flow detection option header, collects flow detection metadata according to the Template, and encapsulates the flow detection metadata and the flow detection option header into a UDP message and sends it to the collector. The original message carrying the flow detection option header is forwarded and sent to the next node.

[0031] As attached Figure 8 As shown, the decapsulation node also makes a judgment based on the Flow Label field in the IPv6 protocol header of the message. The difference is that at this node, the flow detection option header in the original message carrying the flow detection option header needs to be removed to avoid interference with the data analysis of the destination address.

[0032] Furthermore, the specific implementation process of metadata collection is as follows: a sampling template Template is used to instruct each node to collect the in-stream detection metadata.

[0033] The metadata measured by the flow detection method proposed in the present invention can be divided into three categories: delay, packet loss and congestion. Therefore, the templates are divided into 8 types, requiring 3 bits, 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].

[0034] The specific matching process and implementation methods are as follows: Figure 6 As shown, the node first determines 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 flow detection process. At the encapsulation node, the flow classification engine is further used to identify and match the sampling flow. The message that hits the sampling flow rule is the sampling message, which needs to be detected along the flow and enters the flow detection process. First, the flow identifier Flow ID and sampling template Template of the flow are obtained, and the flow detection MD is collected according to the sampling template. At the same time, the flow detection option header is generated, and the sampling template is encapsulated into the flow detection option header. Furthermore, the flow detection option header is added to the original message. The collected flow detection metadata is combined with the generated flow detection option header to encapsulate it into a UDP message and send it to the collector. The original message carrying the flow detection option header is transmitted to the subsequent transmission node and decapsulation node, as shown in the attached figure. Figure 6 and Figure 7As shown, the transmission node and the decapsulation node determine the in-stream detection metadata that the node needs to collect based on the Template field. Specifically, the in-stream detection metadata collected based on the Template field is as follows: 000: Collect node information (node ​​ID, Queue Depth, Buffer occupancy).

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

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

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

[0038] 011: Collects latency and packet loss related data (In TimeStamp, Out TimeStamp, Transit Delay, Sequence Number).

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

[0040] 110: Collect packet loss and congestion related data (Sequence Number, Queue Depth, Bufferoccupancy).

[0041] 111: Collect latency, packet loss, and congestion related data (In TimeStamp, Out TimeStamp, TransitDelay, Sequence Number, Queue Depth, Buffer occupancy).

[0042] 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. The value of each bit determines whether to collect a specific metadata item. For example, if bit0 is 1, the node ID is collected, and if it is 0, it is not collected; if bit1 is 1, the input and output interfaces are collected, and if it is 0, it is not collected. The judgment is made in sequence to finally obtain the required IOAM metadata. Its advantages are high flexibility and accuracy, and it can accurately select the collection field according to the needs. 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; and most MD combinations lack practical significance, while the types of commonly used MDs 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, thereby reducing the overall performance.

[0043] Furthermore, the specific implementation process of adding the flow detection option header is as follows: adding the flow detection option header between the UDP / TCP protocol header and the payload of the original message.

[0044] The transmission of existing IOAM data relies on the option field in the IPv6 Hop-by-Hop Extension Header. IOAM data is encapsulated in the IPv6 Hop-by-Hop Options Header, as shown in the attached figure. Fig. 9 During the transmission of the message, each network node performs the corresponding IOAM MD collection task according to the instruction in the IOAM option header, and then appends the IOAM option header to the hop-by-hop option header sequence.

[0045] However, as can be seen from RFC 9673: IPv6 Hop-by-Hop Options Processing Procedures, the early IPv6 specification mandated that all nodes must process hop-by-hop options, but modern high-speed routers often discard or downgrade such messages due to performance bottlenecks. In addition, large extension headers may reduce the ability of routers to find subsequent header fields and increase the probability of packet loss. RFC 9673 solves the performance bottleneck and functional failure caused by the mandatory processing of the original specification (RFC 2460) by allowing routers to process the IPv6 hop-by-hop options header on demand, thereby improving the practicality of this option in modern networks. However, it still faces challenges such as compatibility conflicts with old equipment, local security risks that may be exposed by selective processing, differences in vendor implementations due to insufficient standardization, and increased parsing pressure on the host side (especially resource-constrained devices).

[0046] The present invention adds the flow detection option header between the UDP / TCP protocol header and the payload, rather than relying on the IPv6 jump option header. Fig. 9 As shown. This can avoid the need for the IPv6 hop option header to be parsed and processed at each intermediate node, thereby reducing the additional processing overhead of the router; at the same time, it can avoid the problem of the IPv6 hop-by-hop option header being discarded or downgraded on high-speed routers due to complex processing. In addition, placing the flow detection data between the transport layer and the application layer allows the terminal device to directly access and parse the data, facilitating subsequent function expansion and customization without being restricted by the IPv6 extension header format.

[0047] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the embodiments of the present invention are described in detail below in conjunction with the accompanying drawings: This embodiment is implemented under the premise of the technical solution of the present invention, and a detailed implementation method and a specific operation process are given. The specific examples described here are only used to explain the present invention, but the protection scope of the present invention is not limited to the following embodiments.

[0048] According to the different types of data collection for in-stream detection, 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 is described in combination with specific modes: A typical satellite network flow detection scenario and message encapsulation structure is as follows: Fig.10As shown. This scenario implements UDP message transmission based on the Direct-export direct upload mode, and uses the Ethernet (ETH) TCP / IP protocol stack for this. The Ethernet frame header in the message encapsulation is marked as "ETH header". The source host sends the original message encapsulated in Ethernet to the low-orbit satellite network and enters the data collection 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 implemented through the flow classification engine, and the sampled flow is identified and matched using the n-tuple of the message. After hitting the sampling flow rule, it enters the encapsulation node flow detection process. First, the sampling template Template and flow ID are obtained, and the Flow ID is mapped to the Flow Label field of the original message IPv6 protocol header. Then, the compressed flow detection MD is collected according to the Template and the flow detection option header is generated. The format of the flow detection option header is as described in the data compression part, including fields such as Flow ID and Template. Among them, the flow classification engine can be implemented using an access control list (ACL). Then, the flow detection option header is added between the UDP / TCP protocol header and the payload of the original message, and the original message carrying the flow detection option header is forwarded. At the same time, the flow detection MD is combined with the flow detection option header to encapsulate into a UDP message and sent to the collector. The original message carrying the flow detection option header is transmitted to the subsequent transmission node and the decapsulation node. The sampled message is also identified according to the Flow Label field of the IPv6 protocol header. If its value is within the agreed range, it is a sampled message and needs to be processed by flow detection. The Template is obtained from the flow detection option header, and the flow detection MD that needs to be collected by this node is determined according to the Template field. After the collection is completed, it is encapsulated into a UDP message and sent. For the decapsulation node, the flow detection option header in the original message carrying the flow detection option header needs to be removed and forwarded to the destination host. In the above process of encapsulating the flow detection MD into a UDP message and sending it to the collector, the UDP message sent by the node is forwarded by the relay satellite to the ground station, and then reaches the collector of the data analysis module for data collection and storage.

[0049] The basic principle of trace incremental mode is the same as that of direct-export mode. The difference is that trace incremental mode does not need to be sent to the encapsulation node and transmission node. Instead, the collected flow detection MD is added to the flow detection option header. Finally, at the decapsulation node, the flow detection option header and all collected flow detection MDs are encapsulated into a UDP message and sent to the collector, and the flow detection data in the original message carrying the flow detection data is removed.

[0050] The basic principle of the Edge-to-Edge end-to-end mode (E2E mode) is the same as that of the Trace incremental mode. The difference is that the E2E mode does not need to collect data at the transmission node, but only needs to collect the in-flow detection MD of the encapsulation node and the decapsulation node.

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