In-situ flow telemetry information configuration method and apparatus, and network device and storage medium

Abstract

The embodiments of the present application relate to the technical field of communications. Provided are an in-situ flow telemetry information configuration method and apparatus, and a network device and a storage medium. The method is applied to a tail node, and comprises: receiving a first BGP update message from a head node, wherein the first BGP update message comprises in-situ flow telemetry configuration information; receiving a first service message from the head node by means of a first path, wherein the first service message comprises a first in-situ flow telemetry option, and the first in-situ flow telemetry option comprises first indication information; and if the value of the first indication information is a first value, generating a service flow identification rule on the basis of the configuration information, wherein the service flow identification rule is used for identifying a service flow requiring in-situ flow telemetry, the service flow is transmitted by means of a second path, the second path is a forwarding path from the tail node to the head node, and the first path and the second path pass through the same intermediate node. In this way, the forwarding efficiency of a service message can be improved.

Description

Method and apparatus for configuring in-situ flow information telemetry information, network device and storage medium TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of communication technology, and in particular to a method and apparatus for configuring in-situ flow information telemetry information, a network device and a storage medium. BACKGROUND

[0002] IFIT (in-situ Flow Information Telemetry) is an IOAM (in-situ Operation Administration and Maintenance) detection technology that can directly measure the real packet loss rate and delay of service packets, and has the advantages of convenient deployment, high statistical accuracy, etc.

[0003] Currently, if bidirectional in-situ flow detection is required, an extension field can be added to the service packet sent by the head node, so as to carry the information of reverse in-situ flow detection, such as the five-tuple of the service flow requiring reverse in-situ flow detection, etc.

[0004] However, after inserting this information into the service packet, the service packet becomes larger. Further, the service packet that does not need to be fragmented for sending may need to be fragmented for sending, which increases the number of times of looking up the forwarding table when forwarding the service packet, and reduces the forwarding efficiency. In addition, the bandwidth required to carry the service packet becomes larger, which also reduces the forwarding efficiency.

[0005] SUMMARY

[0006] Therefore, the present application provides a method and apparatus for configuring in-situ flow information telemetry information, a network device and a storage medium to solve the problem of low forwarding efficiency.

[0007] In a first aspect, embodiments of the present application provide a method for configuring in-situ flow information telemetry information, applied to a tail node, comprising:

[0008] receiving a first BGP update packet from a head node, wherein the first BGP update packet comprises configuration information of in-situ flow detection;

[0009] receiving a first service packet from the head node through a first path, wherein the first service packet comprises a first in-situ flow detection option, and the first in-situ flow detection option comprises first indication information;

[0010] If the value of the first indication information is a first value, a service flow identification rule is generated based on the configuration information, the service flow identification rule is used to identify a service flow which needs to be detected, the service flow is transmitted through a second path, the second path is a forwarding path of the tail node to the head node, and the first path and the second path pass through the same intermediate node.

[0011] In a second aspect, an embodiment of the present application provides a method for configuring in-situ OAM information, applied to a head node, and the method comprises the following steps:

[0012] sending a first BGP update message to a tail node, wherein the first BGP update message comprises configuration information of reverse in-situ OAM;

[0013] receiving a first service message;

[0014] sending a second service message to the tail node through a first path, wherein the second service message comprises a first in-situ OAM option, the first in-situ OAM option comprises first indication information, the first indication information is used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule is used to identify a service flow which needs to be detected, the service flow is transmitted through a second path, the second path is a forwarding path of the tail node to the head node, and the first path and the second path pass through the same intermediate node.

[0015] In a third aspect, an embodiment of the present application provides a device for configuring in-situ OAM information, applied to a tail node, and the device comprises the following steps:

[0016] a receiving module, configured to receive a first BGP update message from a head node, wherein the first BGP update message comprises configuration information of in-situ OAM, and receive a first service message from the head node through a first path, wherein the first service message comprises a first in-situ OAM option, and the first in-situ OAM option comprises first indication information;

[0017] a generating module, configured to, if the value of the first indication information is a first value, generate a service flow identification rule based on the configuration information, the service flow identification rule is used to identify a service flow which needs to be detected, the service flow is transmitted through a second path, the second path is a forwarding path of the tail node to the head node, and the first path and the second path pass through the same intermediate node.

[0018] In a fourth aspect, an embodiment of the present application provides a device for configuring in-situ OAM information, applied to a head node, and the device comprises the following steps:

[0019] a sending module, configured to send a first BGP update message to a tail node, wherein the first BGP update message comprises configuration information of reverse in-situ OAM.

[0020] receive a first service packet;

[0021] The sending module is further configured to send a second service packet to the tail node through a first path, the second service packet comprising a first flow detection option, the first flow detection option comprising first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

[0022] In a fifth aspect, an embodiment of the present application provides a network device applied to a tail node, comprising: a processor; a transceiver; and a machine readable storage medium, which stores machine executable instructions executable by the processor; and the machine executable instructions cause the processor to perform the following steps:

[0023] receive a first BGP update packet from a head node, the first BGP update packet comprising configuration information of reverse flow detection;

[0024] receive a first service packet from the head node through a first path, the first service packet comprising a first flow detection option, the first flow detection option comprising first indication information;

[0025] if the first indication information is of a first value, generate a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

[0026] In a sixth aspect, an embodiment of the present application provides a network device applied to a head node, comprising: a processor; a transceiver; and a machine readable storage medium, which stores machine executable instructions executable by the processor; and the machine executable instructions cause the processor to perform the following steps:

[0027] send a first BGP update packet to a tail node, the first BGP update packet comprising configuration information of reverse flow detection;

[0028] receive a first service packet;

[0029] The second service message is sent to the tail node through a first path, the second service message includes a first flow-based detection option, the first flow-based detection option includes first indication information, the first indication information is used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule is used to identify a service flow which needs to be detected based on the flow, the service flow is transmitted through a second path, the second path is a forwarding path of the tail node to the head node, and the first path and the second path pass through the same intermediate node.

[0030] In a seventh aspect, an embodiment of the present application provides a machine readable storage medium, which stores machine executable instructions, when the machine executable instructions are invoked and executed by a processor, the machine executable instructions cause the processor to execute the method in the first aspect.

[0031] In an eighth aspect, an embodiment of the present application provides a computer program product including instructions, when the computer program product is run on a computer, the computer program product causes the computer to execute the method in the first aspect.

[0032] According to the technical solution, the tail node can receive the first BGP update message from the head node, the first BGP update message includes the configuration information of the flow-based detection, then receive the first service message from the head node, the first service message includes the first flow-based detection option, and the first flow-based detection option includes the first indication information. If the value of the first indication information is the first value, it indicates that the head node instructs the tail node to automatically generate the service flow identification rule, and then the tail node generates the service flow identification rule according to the configuration information, the service flow identification rule is used to identify the service flow which needs to be detected based on the flow, the service flow is transmitted through the second path, the second path is the forwarding path of the tail node to the head node, and the second path and the first path pass through the same intermediate node. It can be seen that in the above process, the head node can advertise the configuration information of the flow-based detection to the tail node through the first BGP update message, and then does not need to carry the configuration information of the flow-based detection in each service message of the forward service flow, so that the service message is prevented from becoming large, and the forwarding efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS

[0033] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and serve to explain the principles of the application, and do not limit the application in any way.

[0034] FIG. 1 is an exemplary schematic diagram of a structure of a flow-based detection network according to an embodiment of the present application;

[0035] FIG. 2 is a schematic diagram of a structure of a service message in the related art;

[0036] FIG. 3 is a flowchart of a flow-based detection information configuration method according to an embodiment of the present application;

[0037] FIG. 4 is a schematic diagram of a stream detection option provided by an embodiment of the present application;

[0038] FIG. 5 is a flow diagram of a method for generating a traffic flow identification rule by a tail node provided by an embodiment of the present application;

[0039] FIG. 6 is a structural schematic diagram of a stream detection attribute TLV provided by an embodiment of the present application;

[0040] FIG. 7 is a structural schematic diagram of a first sub-TLV provided by an embodiment of the present application;

[0041] FIG. 8 is a structural schematic diagram of an extended stream detection type identifier in the first sub-TLV provided by an embodiment of the present application;

[0042] FIG. 9 is a structural schematic diagram of a second sub-TLV provided by an embodiment of the present application;

[0043] FIG. 10 is a structural schematic diagram of encapsulation information in the second sub-TLV provided by an embodiment of the present application;

[0044] FIG. 11 is a flow diagram of another method for configuring stream detection information provided by an embodiment of the present application;

[0045] FIG. 12 is an exemplary schematic diagram of an SRv6 network structure provided by an embodiment of the present application;

[0046] FIG. 13 is an interactive flow diagram of a method for configuring stream detection information provided by an embodiment of the present application;

[0047] FIG. 14 is a structural schematic diagram of a device for configuring stream detection information provided by an embodiment of the present application;

[0048] FIG. 15 is a structural schematic diagram of another device for configuring stream detection information provided by an embodiment of the present application;

[0049] FIG. 16 is a structural schematic diagram of a network device provided by an embodiment of the present application;

[0050] FIG. 17 is a structural schematic diagram of another network device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0051] To make the objectives, technical solutions, and advantages of the present application clearer, further detailed descriptions will be given below with reference to the drawings and embodiments. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art belong to the scope of protection of the present application.

[0052] For the convenience of understanding, first, the related concepts involved in the embodiments of the present application are introduced.

[0053] The stream detection technology in the embodiments of the present application is an IOAM-based stream detection technology, that is, the service message transmitted in the stream detection networking carries stream detection data, and each device in the stream detection networking can report the measurement data to the analyzer based on the stream detection data after identifying the stream detection data included in the service message.

[0054] As shown in FIG. 1, FIG. 1 is an exemplary schematic diagram of the structure of a stream detection network provided by the embodiments of the present application, the stream detection networking includes a head node, a plurality of intermediate nodes and a tail node, and two intermediate nodes are exemplarily shown in FIG. 1, which are intermediate node 1 and intermediate node 2, wherein the intermediate node 1 does not support stream detection, and the intermediate node 2 supports stream detection.

[0055] The head node is used to receive a real service flow, and if it is determined that stream detection needs to be performed on the service flow, the measurement data of the service flow is sent to the analyzer, and stream detection data is added in the service flow, and the service flow carrying the stream detection data is forwarded to the intermediate node 1 connected to itself. Since the intermediate node 1 does not support stream detection, the service flow is directly forwarded to the intermediate node 2.

[0056] The intermediate node 2 is used to receive the service flow, and if it identifies that the service flow includes stream detection data and the measurement type indicated by the stream detection data is point-by-point measurement, the measurement data of the service flow is sent to the analyzer based on the stream detection data, and the service flow is forwarded to the tail node. Or, if the measurement type indicated by the stream detection data is end-to-end measurement, the measurement data does not need to be sent to the analyzer, and the service flow can be forwarded to the tail node.

[0057] The tail node is used to receive the service flow, and if it identifies that the service flow includes stream detection data, the measurement data of the service flow is sent to the analyzer based on the stream detection data, and the stream detection data in the service flow is deleted, and then the service flow is forwarded.

[0058] The analyzer is used to receive the measurement data sent by the head node, the intermediate node and the tail node, and to summarize and calculate the received measurement data. The analyzer and the devices supporting stream detection run a clock synchronization protocol, and in FIG. 1, the head node, the intermediate node 2 and the tail node need to be PTP (Precision Time Protocol) time synchronized with the analyzer.

[0059] The advantage of the IFIT technology is easy to deploy, the instances of the measurement parameters included in the IFIT are deployed at the head node, and the IFIT function of the intermediate node and the tail node is started, and the intermediate node and the tail node can complete the measurement and report the measurement data.

[0060] If bidirectional measurement is needed, for example, bidirectional packet loss measurement, bidirectional delay measurement or bidirectional jitter measurement, etc., an instance of reverse flow detection needs to be configured at the tail node. However, as the network becomes more and more complex, the number of devices in the network increases, and for users, they must be familiar with the current network traffic forwarding path, so as to achieve configuration at the head node and the tail node of each forwarding path respectively. The configuration is complex and tedious.

[0061] In order to reduce the configuration workload, the head node can add an extension field in the IFIT packet header of the service packet at present, so as to carry the information of the service flow which needs to be detected in the reverse flow detection, such as the five-tuple of the service flow, etc. As shown in FIG. 2, the service packet includes an ETH (Ethernet) header, an IPv6 (Internet Protocol Version 6) basic header, a Segment Routing Header (SRH) and a payload. The SRH includes an SRH basic header, a Segment List and an IFIT packet header. The IFIT packet header is an optional TLV (Type Length Value) in the SRH.

[0062] The IFIT packet header is a TLV structure, and the IFIT packet header includes a steering label, a basic header and an extension header.

[0063] The steering label includes Type, Length and Rsv (Reserved). The value of Type can be 130.

[0064] The basic header is used to carry the information of the forward flow detection, and specifically includes Flow ID (Flow ID), L, D, R, S / R, NextHeader, Flow ID Ext, E, P, F, R, Len, Rsv and Trace Type.

[0065] Flow ID and Flow ID Ext are the IDs of the service flow which needs to be detected, and are used to uniquely identify a service flow.

[0066] L is a loss measurement dyeing mark.

[0067] D is a delay measurement dyeing mark.

[0068] S / R, if the steering label is the bottom of the stack, the field is S, and the value is 1; if the steering label is not the bottom of the stack, the field is R, and the value is 0.

[0069] E, is a statistical mode, and a value of 0 indicates that a hop-by-hop statistical mode is used, and a value of 1 indicates that an end-to-end statistical mode is used.

[0070] P, is used to prevent a Probe Marker (probe marker) from being mismatched when IPv4 encapsulation is used, and a value of 1 indicates that the mismatch occurs, and in this case, no statistics are needed.

[0071] F, is an identifier of a forward service flow, and a value of 1 indicates the forward service flow.

[0072] Len, is an extension length.

[0073] Trace Type, is a Metadata (metadata) indication bit, and is indicated in the form of a bitmap (bitmap).

[0074] R and Rsv are both reserved fields.

[0075] The extension header is used to carry configuration information of a reverse service flow, and specifically includes Bit0, Bit1, Bit2, and Bit3.

[0076] Bit0, is Rsv or Timestamp, and the Timestamp is used to measure a per-packet delay, and occupies 6 bytes; of which, the first 2 bytes indicate seconds, and the last 4 bytes indicate nanoseconds.

[0077] Bit1, is a control field, and is used to carry control information such as a flow feature and a synchronization period of the reverse service flow. For example, the control information can include a DIP Mask (destination IP address mask), a SIP Mask (source IP address mask), a Proto / Ports (protocol / port), a V, a DSCP (Differentiated Services Code Point), a Tunnel (tunnel), and a Period (synchronization period) of the reverse service flow.

[0078] Proto / Ports, indicates a protocol enablement flag, a source port number enablement flag, and a destination port number enablement flag, a value of the protocol enablement flag is 1, indicating that a reverse service flow that needs to be detected in a flow needs to be determined based on a protocol name; a value of the source port number enablement flag is 1, indicating that the reverse service flow that needs to be detected in the flow needs to be determined based on a source port number; and a value of the destination port number enablement flag is 1, indicating that the reverse service flow that needs to be detected in the flow needs to be determined based on a destination port number.

[0079] V, indicates whether the reverse service flow needs to be detected in a flow, and a value of 1 indicates that the reverse service flow needs to be detected in the flow.

[0080] DSCP, indicating whether DSCP-based determination of reverse traffic flow requiring flow detection is required.

[0081] Tunnel, indicating whether tunnel-level flow detection is required.

[0082] Period, synchronization reporting period, in seconds.

[0083] Bit2, Sequence, used for out-of-order detection, occupying 4 bytes.

[0084] Bit3, Checksum, used for packet modification detection, occupying 4 bytes.

[0085] In FIG. 2, Bit0, Bit1, Bit2 and Bit3 included in the extension header are all information for reverse flow detection, occupying 4 bytes in total. If 4 bytes of extension header are inserted into each traffic message, the load will become larger, the bandwidth required for transmitting traffic flow will become larger, and the forwarding efficiency will be reduced. For example, assuming that the length of a traffic message is 500 bytes, 4 bytes of extension header need to be additionally inserted into the traffic message. For a 10G port, 80M of bandwidth is required to transmit the extension header, which will reduce the forwarding efficiency of the traffic message.

[0086] Moreover, the traffic message originally can not need to be sent in fragments, but after the 4 bytes of extension header are inserted into the traffic message, the traffic message can need to be sent in fragments, further increasing the number of times of checking the forwarding table when sending the message, and also reducing the forwarding efficiency.

[0087] To solve the above problems, an embodiment of the present application provides a flow detection information configuration method. The method is applied to a tail node, as shown in FIG. 3, and the method comprises the following steps:

[0088] S301, receiving a first BGP (Border Gateway Protocol) update message from a head node, wherein the first BGP update message comprises configuration information of flow detection.

[0089] The forwarding path of the head node to the tail node is a first path, the head node is configured with flow detection information of a forward traffic flow and flow detection information of a reverse traffic flow, and the flow detection information specifically can comprise flow characteristics of the flow detection traffic flow and configuration information. In the embodiment of the present application, the forward traffic flow is a traffic flow transmitted from the head node to the tail node, i.e., a traffic flow transmitted through the first path. The reverse traffic flow is a traffic flow transmitted from the tail node to the head node, i.e., a traffic flow transmitted through a second path.

[0090] After the head node is configured with the in-flow detection information of the forward service flow and the in-flow detection information of the reverse service flow, it determines that the bidirectional in-flow detection needs to be performed, and then sends a first BGP update message to the tail node.

[0091] S302, receiving a first service message from the head node through a first path, the first service message including a first in-flow detection option, and the first in-flow detection option including first indication information.

[0092] The head node receives a service message, determines that the service message matches the in-flow detection information of the forward service flow, that is, the service message is a service message that needs to be in-flow detected, inserts a first in-flow detection option in the service message, and obtains a first service message. Then, the first service message is transmitted to the tail node of the first path along the first path between the head node and the tail node.

[0093] The first in-flow detection option includes in-flow detection data of the forward service flow.

[0094] As an example, the first in-flow detection option is shown in FIG. 4, and specifically includes the following fields:

[0095] FlowMonID (flow identification), occupying 20 bits, the flow identification being used to uniquely identify a service flow;

[0096] L, occupying 1 bit, being a loss measurement coloring mark;

[0097] D, occupying 1 bit, being a delay measurement coloring mark;

[0098] HTI (Header Type Indication, header type indication), occupying 8 bits, being used to indicate the type of the carried extension data, the value being 0 indicating a reserved field, the value being 1 to 15 indicating that private extension data is carried, and the value being 16 to 255 indicating that standard extension data is carried. In the embodiment of the application, the value of HTI can be 16;

[0099] NodeMonID (device node identification), occupying 20 bits, being used to uniquely identify a node in the in-flow detection network. The head node can add its own node identification in the field when encapsulating the in-flow detection option for the service message;

[0100] F, occupying 1 bit, being a service flow direction identifier, being used to carry the first indication information, the value being 1 indicating that the reverse service flow needs to be self-learned, that is, the tail node needs to generate an identification rule of the reverse service flow according to the flow characteristics of the forward service flow, and trigger the in-flow detection of the reverse service flow;

[0101] P, occupies 3 bits, is a measurement period. When the value is 000, it indicates that the measurement period is 1 second; when the value is 001, it indicates that the measurement period is 10 seconds; when the value is 010, it indicates that the measurement period is 30 seconds; when the value is 011, it indicates that the measurement period is 60 seconds; when the value is 100, it indicates that the measurement period is 300 seconds; and the remaining possible values are temporarily reserved, and can be set according to actual measurement requirements in the future.

[0102] T, occupies 2 bits, is used to indicate a detection type. When the value is 00, the corresponding detection type is temporarily reserved; when the value is 01, the corresponding detection type is end-to-end detection; when the value is 10, the corresponding detection type is hop-by-hop detection; and when the value is 11, the corresponding detection type is temporarily reserved, and can be set based on actual measurement requirements in the future.

[0103] Ext FM Type (Extension Flow Monitor Type, extension flow detection type), occupies 16 bits, and can be identified in the form of a bitmap.

[0104] R (1 bit), Rsv (6 bits), and Reserved (16 bits) are all reserved fields.

[0105] S303, if the value of the first indication information is a first value, generating a service flow identification rule based on the configuration information.

[0106] The service flow identification rule is used to identify a service flow that needs to be detected with a flow, and the service flow is transmitted through a second path, the second path is a forwarding path from a tail node to a head node, and the first path and the second path pass through the same intermediate node.

[0107] For example, in FIG. 1, the forwarding path composed of the head node, the intermediate node 1, the intermediate node 2, and the tail node is the first path. The forwarding path composed of the tail node, the intermediate node 2, the intermediate node 1, and the head node is the second path, the tail node in FIG. 1 is the head node of the second path, and the head node in FIG. 1 is the tail node of the second path.

[0108] The first indication information is the F field in FIG. 4, and the first value can be 1, that is, when the value of the F field is 1, the tail node needs to perform self-learning of the reverse service flow, and then the tail node can generate a service flow identification rule based on the configuration information of the reverse service flow in the first BGP update message.

[0109] The service flow identification rule is an ACL (Access Control List) rule, specifically including a flow feature of a reverse service flow that needs to be detected with a flow, and can further include a detection type, a statistical period, and other parameters of the detection with the flow.

[0110] With the method, the tail node can receive a first BGP update message from the head node, the first BGP update message including configuration information of the in-situ flow detection, then receive a first service message from the head node, the first service message including a first in-situ flow detection option, and the first in-situ flow detection option including first indication information. If the value of the first indication information is a first value, it indicates that the head node instructs the tail node to generate a service flow identification rule automatically, and then the tail node generates the service flow identification rule according to the configuration information, the service flow identification rule being used to identify a service flow that needs to be detected in situ, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the second path passing through the same intermediate nodes as the first path. It can be seen that in the above process, the head node can announce the configuration information of the in-situ flow detection to the tail node through the first BGP update message, and then does not need to carry the configuration information of the in-situ flow detection in each service message of the forward service flow, so as to avoid the increase of the service message and improve the forwarding efficiency.

[0111] In some embodiments of the present application, the configuration information includes a tunnel-level enabling flag, the tunnel-level enabling flag being used to indicate whether to perform reverse in-situ flow detection based on a tunnel. Accordingly, the generating of the service flow identification rule based on the configuration information in S303 can be implemented as follows:

[0112] If the value of the tunnel-level enabling flag is a first value, a first type of service flow identification rule is generated. The first type of service flow identification rule includes a segment list (SL) identifier, and the path indicated by the segment list identifier is the second path, and the second path constitutes a transmission tunnel.

[0113] The reverse in-situ flow detection based on the tunnel refers to performing the reverse in-situ flow detection on all service flows transmitted through a specific tunnel. For example, in FIG. 1, the transmission tunnel corresponding to the first service message is the transmission tunnel of the head node to the tail node, and accordingly, the transmission tunnel constituted by the second path is the transmission tunnel of the tail node to the head node. Assuming that the intermediate node 2 in FIG. 1 is an endpoint node, and the intermediate node 1 is not an endpoint node, the segment list of the reverse transmission tunnel includes the SID (Segment Identifier) of the tail node, the SID of the intermediate node 2 and the SID of the head node in FIG. 1.

[0114] In the related art, in order to avoid that the service message is too large, the F field can also be added in the flow detection option, so as to instruct the tail node to perform self-learning of the reverse service flow. In this way, the tail node can only generate the service flow identification rule based on the five-tuple of the reverse service flow, and cannot implement the tunnel level detection. In the embodiment of the present application, the configuration information of the flow detection is notified through the first BGP update message, and the configuration information further includes the tunnel level enabling mark, so that the service message is not too large, and the tunnel level flow detection can be flexibly selected.

[0115] In some embodiments of the present application, the first service message includes an original message, and the original message includes a plurality of first flow characteristics; the configuration information further includes enabling information of a plurality of second flow characteristics. It can be understood that the plurality of first flow characteristics are flow characteristics of the forward service flow, and the plurality of second flow characteristics are flow characteristics of the reverse service flow.

[0116] On this basis, the generation of the service flow identification rule based on the configuration information in S303 can be implemented as follows:

[0117] If the value of the tunnel enabling mark is the second value, the value of each second flow characteristic is obtained from the plurality of first flow characteristics according to each second flow characteristic indicated by the enabling information; and the second type of service flow identification rule is generated based on the value of the second flow characteristic.

[0118] That is, the second type of service flow identification rule includes the value of the flow characteristic of the reverse service flow.

[0119] The plurality of first flow characteristics can include the five-tuple of the forward service flow, and can also include other information capable of representing the forward service flow, such as DSCP.

[0120] The enabling information of the plurality of second flow characteristics can include source IP address mask, destination IP address mask, DSCP enabling information, protocol number enabling information, source port enabling information, and destination port enabling information.

[0121] The source IP address mask and the destination IP address in the five-tuple of the forward service flow can be used to obtain the source IP address segment of the reverse service flow which needs to be detected, for example, the source IP address mask is 24, and the destination IP address of the forward service flow is 2.2.2.0, so that the obtained source IP address segment of the reverse service flow is 2.2.2.0 / 24. Correspondingly, the second type of service flow identification rule includes the source IP address segment.

[0122] Similarly, the destination IP address mask and the source IP address in the five-tuple of the forward service flow can be used to obtain the destination IP address segment of the reverse service flow which needs to be detected. Correspondingly, the second type of service flow identification rule includes the destination IP address segment.

[0123] If the DSCP enabling information is enabled, the second type of traffic flow identification rule includes the DSCP of the reverse traffic flow; if the DSCP enabling information is not enabled, the second type of traffic flow identification rule does not include the DSCP of the reverse traffic flow.

[0124] Similarly, if the protocol number enabling information is enabled, the protocol number is obtained from the plurality of first flow characteristics, and the protocol number is taken as the protocol number of the reverse traffic flow. Accordingly, the second type of traffic flow identification rule further includes the protocol number of the reverse traffic flow.

[0125] If the source port enabling information is enabled, the destination port number is obtained from the plurality of first flow characteristics, and the destination port number is taken as the source port number of the reverse traffic flow. Accordingly, the second type of traffic flow identification rule further includes the source port number of the reverse traffic flow.

[0126] If the destination port enabling information is enabled, the source port number is obtained from the plurality of first flow characteristics, and the source port number is taken as the destination port number of the forward traffic flow. Accordingly, the second type of traffic flow identification rule further includes the destination port number of the reverse traffic flow.

[0127] In the embodiments of the present application, after the data plane of the tail node receives the first traffic message (i.e., the first traffic message) carrying the first flow detection option, the first traffic message is uploaded to the control plane, and the traffic flow identification rule is generated by the control plane, and then the traffic flow identification rule is stored in the forwarding plane.

[0128] Further, when the data plane of the tail node receives the second traffic message conforming to the traffic flow identification rule, the second flow detection option is encapsulated for the second traffic message to obtain the third traffic message, and the third traffic message is transmitted to the head node through the second path.

[0129] The second flow detection option has the same structure as the first flow detection option, and the value of the F field in the second flow detection option is 0.

[0130] The method for the tail node to generate the traffic flow identification rule will be described below in combination with specific examples. As shown in FIG. 5, the tail node includes a BGP module, an IFIT module and a driver, wherein the BGP module and the IFIT module are located in the control plane of the tail node, and the driver is located in the data plane of the tail node. The method includes the following steps:

[0131] Step 1, the driver receives the traffic message including the flow detection option.

[0132] After the driver receives the traffic message, the F field in the flow detection option in the traffic message can be checked. If the F field is set (i.e., the value is 1), and the traffic message is the first message of the same traffic flow, step 2 is executed.

[0133] Step 2, drive to send service message to IFIT module, so that IFIT module parses the information of the flow detection option and the five-tuple of the inner message.

[0134] Wherein, the IFIT module can obtain the flow detection related information from the flow detection option of the service message, that is, the information shown in Figure 4. And it can also obtain the original message (also known as inner message) encapsulated in the service message, and obtain the flow characteristics of the forward service flow from the inner message, such as five-tuple and DSCP, and the five-tuple includes source IP address, destination IP address, protocol number, source port number and destination port number.

[0135] Step 3, the IFIT module obtains the configuration information of the flow detection from the BGP module.

[0136] The configuration information of the flow detection is the configuration information synchronized by the head node through the first BGP update message, and the configuration information includes tunnel level enable flag and enable information of each flow characteristic of the reverse service flow.

[0137] The IFIT module can generate the service flow identification rule of the reverse service flow according to the configuration information and the flow characteristics of the forward service flow.

[0138] As an example, if the tunnel level enable flag is not set (i.e. the value is 0), and the flow characteristics of the forward service flow include: SIP (source IP address): 1.1.1.1, DIP (destination IP address): 2.2.2.2, DSCP: 8, PRO (protocol): UDP, SPORT (source port): 100, DPORT (destination port): 200.

[0139] The enable information of each flow characteristic of the reverse service flow in the configuration information is: SIPMASK (source IP address mask): 24, DIPMASK (destination IP address mask): 24, DSCP: 0, PRO (protocol): 1, SPORT (source port): 0, DPORT (destination port): 0. Wherein, "1" in the enable information represents enable, and "0" represents not enable.

[0140] Further, the service flow identification rule of the reverse service flow generated by the IFIT module includes: SIP: 2.2.2.0 / 24, DIP: 1.1.1.0 / 32, PRO: UDP. The service flow identification rule is used to indicate that if the tail node acts as the head node, the source IP address of the received service message belongs to 2.2.2.0 / 24 network segment, the destination IP address belongs to 1.1.1.0 / 32, and the protocol is UDP, then the service message needs to be flow detected.

[0141] Step 4, the IFIT module issues the service flow identification rule of the reverse service flow to the driver.

[0142] By using the method, the traffic flow identification rule of the reverse traffic flow is generated by the control plane and then is sent to the data plane, which can reduce the influence on the data plane and further reduce the load of the data plane, thereby reducing the load of the tail node and improving the forwarding efficiency of the service message. Moreover, the tail node can dynamically generate the traffic flow identification rule of the reverse traffic flow automatically without manual configuration, which can reduce the workload of configuration and maintenance.

[0143] The first BGP update message in the embodiments of the present application is described in detail below.

[0144] At both ends of the SRv6 tunnel, i.e. between the head node and the tail node, the route information can be synchronized through the BGP protocol, and the embodiments of the present application can synchronize the configuration information of the reverse in-situ flow detection through the first BGP update message.

[0145] The first BGP update message includes an SR Policy Subsequenct Address Family Indentifier (SAFI) Network Layer Reachability Information (NLRI) field.

[0146] The SR Policy SAFI NLRI field includes a Tunnel Encaps Attribute, and the Tunnel Type of the Tunnel Encaps Attribute is SR Policy Type (value 15). In the embodiments of the present application, a sub-TLV, i.e. an in-situ flow detection attribute TLV (IFIT Attributes TLV), can be added in the Tunnel Encaps Attribute, so as to carry the configuration information of the reverse in-situ flow detection by using the in-situ flow detection attribute TLV.

[0147] The position of the IFIT Attributes in the SR Policy SAFI NLRI field is as follows:

[0148] SR Policy SAFI NLRI: <Distinguisher, policy-Color, Endpoint>

[0149] Attributes:

[0150] Tunnel Encaps Attribute (23)

[0151] Tunnel Type: SR Policy Type (15)

[0152] Binding SID (binding SID)

[0153] SRv6 Binding SID (SRv6 binding SID)

[0154] Prefence (priority)

[0155] Priority (priority)

[0156] Policy Name (policy name)

[0157] Policy Candidate Path Name (policy candidate path name)

[0158] Explicit NULL Lable Policy (explicit NULL label policy)

[0159] IFIT Attributes

[0160] Segment List (segment list)

[0161] Weight (weight)

[0162] …

[0163] …

[0164] The structure of the in-situ flow detection attribute TLV is shown in FIG. 6, including the following fields:

[0165] Type (type): occupies 8 bits, indicating the type of encapsulated attribute.

[0166] Length (length): occupies 8 bits, indicating the length of the subsequent sub-TLV, not including the length of Type and Length.

[0167] The sub-TLV (sub-TLVs) is used to carry the configuration information of reverse in-situ flow detection, including at least one sub-TLV.

[0168] The at least one sub-TLV includes a first sub-TLV, and the structure of the first sub-TLV is shown in FIG. 7, including the following fields:

[0169] Type (type): occupies 8 bits, indicating the type of the first sub-TLV, for example, the value of the Type field can be 2;

[0170] Length (length): occupies 8 bits, indicating the length of the Value field;

[0171] The fields after Length all belong to the value field.

[0172] The value field includes:

[0173] Flow Mon ID: occupying 20 bits, unique in the device, used for uniquely identifying a service flow;

[0174] Node Mon ID: occupying 20 bits, used for uniquely identifying a device in the flow detection network;

[0175] Ext FM Flag: occupying 20 bits;

[0176] The enabling information of the plurality of second flow features;

[0177] Tunnel level enabling flag.

[0178] The plurality of second flow features include: destination IP address, source IP address, DSCP, protocol name, destination port and source port.

[0179] Correspondingly, the enabling information of the plurality of second flow features includes:

[0180] DIP Mask: occupying 8 bits, used for indicating whether each bit of the destination IP address is enabled;

[0181] SIP Mask: occupying 8 bits, used for indicating whether each bit of the source IP address is enabled;

[0182] D Flag: occupying 1 bit, used for indicating whether the DSCP is enabled. When the value is 1, it indicates that the DSCP is enabled; when the value is 0, it indicates that the DSCP is not enabled;

[0183] L4 flag: occupying 3 bits, wherein the first bit indicates whether the protocol name in the plurality of second flow features is enabled, the second bit indicates whether the destination port in the plurality of second flow features is enabled, and the third bit indicates whether the source port in the plurality of second flow features is enabled;

[0184] Tunnel level enabling flag (T Flag): occupying 1 bit, when the value is 1, it indicates that tunnel level flow detection is needed, in which case the destination IP address mask, the source IP address mask, the D flag and the L4 flag are all invalid; when the value is 0, it indicates that tunnel level flow detection is not needed.

[0185] The remaining fields included in the value are all reserved fields (Reserved).

[0186] The structure of the extended flow detection type identifier (Ext FM Flag) is shown in FIG. 8, including an F flag and a reserved field.

[0187] The F flag (F-flag) occupies 1 bit, and is used to indicate the enabling information of identifying multiple second flow characteristics, i.e., whether the destination IP address mask, the source IP address mask, the D flag and the L4 flag are effective.

[0188] Optionally, the at least one sub-TLV further includes a second sub-TLV, which can also be referred to as an IFIT capability sub-TLV (IFIT Capability sub-TLV). The second sub-TLV is used to notify the tail node of the capabilities of the head node, so that the tail node reasonably uses these capabilities to identify the service packets subsequently sent by the head node, and can enable the tail node to encapsulate the service packets of the reverse service flow into a format that can be identified by the head node.

[0189] As shown in FIG. 9, the second sub-TLV includes a Type field and a Length field, each occupying 8 bits. For example, the value of the Type field can be 1. The second sub-TLV further includes a value field.

[0190] The value field includes:

[0191] The first flag (M-Flag) occupies 1 bit, and is used to indicate whether the head node supports the flow detection of alternate coloring, and the value of 1 indicates support, and the value of 0 indicates no support;

[0192] The second flag (E-Flag) occupies 1 bit, and is used to indicate whether the head node supports the flow detection of enhanced alternate coloring, and the value of 1 indicates support, and the value of 0 indicates no support;

[0193] The third flag (F-Flag) occupies 1 bit, and is used to indicate whether the head node supports dynamically establishing a service flow identification rule, and the value of 1 indicates support, and the value of 0 indicates no support;

[0194] The reserved field (Reserved) occupies 21 bits;

[0195] The encapsulation information (Encap) occupies 8 bits, and indicates the encapsulation position of the flow detection option supported by the head node.

[0196] The structure of the encapsulation information (Encap) is shown in FIG. 10, including the following fields:

[0197] H flag (H-Flag): occupying 1 bit, used to indicate whether the head node supports encapsulating the stream detection option (Option TLV) in the hop-by-hop header, and the value of 1 indicates support and the value of 0 indicates no support;

[0198] D flag (D-Flag): occupying 1 bit, used to indicate whether the head node supports encapsulating the stream detection option in the destination header, and the value of 1 indicates support and the value of 0 indicates no support;

[0199] S flag (S-Flag): occupying 1 bit, used to indicate whether the head node supports encapsulating the stream detection option in the SRH, and the value of 1 indicates support and the value of 0 indicates no support.

[0200] Further, the tail node can determine the encapsulation position of the stream detection option of the service message sent by the head node based on the values of the H flag, the D flag and the S flag.

[0201] And the encapsulation information includes a reserved field (Reserved).

[0202] By carrying the second TLV in the first BGP update message, the tail node can be informed of the encapsulation position of the stream detection option by the subsequent head node and the coloring mode of the support of the stream detection, and the workload of manual configuration and maintenance can be reduced.

[0203] In some embodiments of the present application, after the tail node generates the service flow identification rule based on the configuration information, if the tail node receives a second BGP update message from the head node, and the second BGP update message does not include the configuration information, the tail node deletes the service flow identification rule; or, if the tail node does not receive a message including multiple first flow characteristics for a preset time period, the tail node deletes the service flow identification rule.

[0204] The format of the second BGP update message is the same as that of the first BGP update message, but in the second BGP update message, the contents of the fields included in the first sub-TLV and the second sub-TLV are all empty.

[0205] After the tail node receives the second BGP update message, if it identifies that the contents of the fields included in the first sub-TLV and the second sub-TLV in the second BGP update message are all empty, it can be determined that there is no need to continue the stream detection based on the service flow identification rule, and the service flow identification rule can be deleted.

[0206] Or, if the tail node does not receive a forward service flow matching the reverse service flow for a preset time period, it can be determined that there is no need to perform bidirectional detection on the transmission tunnel between the head node and the tail node, and the service flow identification rule can be deleted.

[0207] When any one of the above conditions is met, the head node can automatically delete the service flow identification rule, without manual configuration of deletion, thereby reducing the workload of manual configuration and achieving more convenience.

[0208] Corresponding to the method embodiment, the embodiment of the application further provides a flow detection information configuration method, applied to a head node, as shown in FIG. 11, the method comprises:

[0209] S1101, sending a first BGP update message to a tail node, the first BGP update message comprising flow detection configuration information.

[0210] After the head node is configured with the flow detection information of the forward service flow and the flow detection information of the reverse service flow, it can be determined that bidirectional flow detection is needed, and then the first BGP update message is sent to the tail node.

[0211] The specific structure of the first BGP update message can refer to the related description in the above embodiment, which will not be repeated here.

[0212] S1102, receiving a first service message.

[0213] The first service message is a normal service message. After the head node receives the first service message, if it is determined that the first service message matches the flow detection information of the forward service flow, that is, the first service message is a service message that needs to be subjected to flow detection, a first flow detection option can be inserted into the first service message, thereby obtaining a second service message.

[0214] S1103, sending the second service message to the tail node through a first path, the second service message comprising a first flow detection option, the first flow detection option comprising first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information.

[0215] The service flow identification rule is used to identify a service flow that needs to be subjected to flow detection, and the service flow is transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

[0216] The structure of the first flow detection option can refer to the related description in the above embodiment, which will not be repeated here.

[0217] With the method, the head node can send a first BGP update message including the configuration information of the in-situ flow detection to the tail node, and then the head node sends a second service message to the tail node through the first path after receiving the first service message, the second service message including the first service message and a first in-situ flow detection option, and the first in-situ flow detection option including first indication information. The first indication information is used to indicate whether the tail node generates a service flow identification rule based on the configuration information, and the service flow identification rule is used to identify a service flow that needs to be subjected to in-situ flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the second path passing through the same intermediate nodes as the first path. It can be seen that in the above process, the head node can announce the configuration information of the in-situ flow detection to the tail node through the first BGP update message, and thus does not need to carry the configuration information of the in-situ flow detection in each service message of the forward service flow, which can avoid the service message from becoming large and improve the forwarding efficiency.

[0218] The in-situ flow detection information configuration method provided by the embodiments of the present application is introduced below in combination with specific examples. Taking SRv6 (Segment Routing IPv6, Segment Routing IPv6) networking as an example, as shown in FIG. 12, the PE (Provider Edge, Provider Edge device) 1 and the P (Provider, Provider device) have an SRv6 tunnel therebetween, and the P and the PE2 also have an SRv6 tunnel therebetween, the PE1 and the PE2 have established an M-BGP peer, and the PE1 and the PE2 have connected the Overlay network. The PE1 is a head node, the PE2 is a tail node, and the P is an intermediate node. The PE1 and the PE2 can mutually announce routing information through BGP update messages.

[0219] After the PE1 receives user traffic, if it is determined that the user traffic matches the in-situ flow detection information of the forward service flow, the PE1 encapsulates a first in-situ flow detection option for the message of the user traffic to obtain colored traffic. Then the PE1 transmits the colored traffic to the P, and the P transmits the colored traffic to the PE2. After the PE2 receives the colored traffic, the PE2 restores the colored traffic to user traffic and then continues to transmit the user traffic to a destination device of the user traffic.

[0220] In this process, the PE1, the P and the PE2 all need to report measurement data of the in-situ flow detection to an analyzer according to the colored traffic.

[0221] Under the networking structure of FIG. 12, the interaction process of the PE1 and the PE2 is shown in FIG. 13, and specifically includes the following steps.

[0222] S1301, a user configures in-situ flow detection for the PE1.

[0223] The information configured for the PE1 includes in-situ flow detection information of a forward service flow and in-situ flow detection information of a reverse service flow.

[0224] S1302, PE1 sends a first BGP update message to PE2.

[0225] The first BGP update message includes the configuration information of the flow detection.

[0226] S1303, PE1 receives the user traffic.

[0227] S1304, PE1 transmits the application traffic carrying the flow detection option to PE2.

[0228] If PE1 determines that the received user traffic matches the flow detection information of the forward traffic, PE1 encapsulates the flow detection option for the user traffic. The flow detection option is the same as the first flow detection option in the above embodiments, and will not be described herein.

[0229] It should be noted that PE1 forwards the application traffic carrying the flow detection option to P, and then P forwards the application traffic to PE2.

[0230] S1305, PE2 generates a reverse traffic identification rule according to the first packet information and the configuration information.

[0231] The first packet information is the first packet of the application traffic carrying the flow detection option.

[0232] The method of generating the traffic identification rule can refer to the related description in the above embodiments, and will not be described herein.

[0233] S1306, PE2 receives the reverse traffic.

[0234] S1307, PE2 sends the reverse application traffic carrying the flow detection option to PE1.

[0235] If PE2 determines that the reverse traffic matches the traffic identification rule of the reverse traffic, PE2 encapsulates the flow detection option (second flow detection option) for the reverse traffic, and then forwards the reverse traffic to PE1 via P.

[0236] S1308, if the traffic identification rule is aged or PE2 receives a second BGP update message, the traffic identification rule is deleted.

[0237] If no traffic packet of the forward traffic is received for a predetermined time period, it can be determined that the traffic identification rule of the reverse traffic is aged, and the traffic identification rule is deleted.

[0238] Alternatively, if PE1 can instruct the tail node to delete the service flow identification rule, i.e., send a second BGP update message to PE2, after receiving the second BGP update message, if PE2 determines that the second BGP update message does not include configuration information, PE2 deletes the service flow identification rule.

[0239] By using the method, PE1 can notify PE2 of the configuration information through the first BGP update message, avoid large service messages, and improve service message forwarding efficiency. PE2 can automatically generate the service flow identification rule without manual configuration, and reduce the workload of manual configuration. When the service flow identification rule needs to be deleted, manual configuration is not required, and the workload of manual configuration can be further reduced.

[0240] Corresponding to the method embodiments, the embodiments of the present application also provide a device for configuring in-situ flow information, applied to a tail node, as shown in FIG. 14, the device includes:

[0241] The receiving module 1401 is configured to receive a first BGP update message from a head node, the first BGP update message including configuration information for in-situ flow detection; and receive a first service message from the head node through a first path, the first service message including a first in-situ flow detection option, the first in-situ flow detection option including first indication information;

[0242] The generating module 1402 is configured to, if the value of the first indication information is a first value, generate a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow that needs to be subjected to in-situ flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

[0243] Optionally, the configuration information includes a tunnel-level enabling flag.

[0244] The generating module 1402 is specifically configured to, if the value of the tunnel-level enabling flag is the first value, generate a first type of service flow identification rule, the first type of service flow identification rule including a segment list identifier, the path indicated by the segment list identifier being the second path, and the second path constituting a transmission tunnel.

[0245] Optionally, the first service message includes an original message, the original message including a plurality of first flow characteristics; and the configuration information further includes enabling information of a plurality of second flow characteristics.

[0246] The generating module 1402 is specifically configured to:

[0247] If the value of the tunnel enabling flag is a second value, the value of each second flow characteristic is obtained from the plurality of first flow characteristics according to each second flow characteristic that is enabled as indicated by the enabling information.

[0248] Generate a second type of service flow identification rule based on the value of the second flow feature.

[0249] Optionally, the first BGP update message includes an SR Policy SAFI NLRI field, and the SR Policy SAFI NLRI field includes a tunnel encapsulation attribute, and the tunnel encapsulation attribute includes a flow detection attribute TLV.

[0250] The flow detection attribute TLV includes at least one sub-TLV, and the at least one sub-TLV is used to carry configuration information.

[0251] Optionally, the at least one sub-TLV includes a first sub-TLV, and a value field of the first sub-TLV includes a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of a plurality of second flow features, and a tunnel level enabling flag; the plurality of second flow features include a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; the enabling information of the plurality of second flow features includes a destination IP address mask, a source IP address mask, a D flag, and an L4 flag.

[0252] The extended flow detection type identifier includes an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow features is identified.

[0253] The destination IP address mask is used to indicate whether each bit included in the destination IP address is enabled.

[0254] The source IP address mask is used to indicate whether each bit included in the source IP address is enabled.

[0255] The D flag is used to indicate whether the DSCP is enabled.

[0256] The L4 flag includes three bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

[0257] Optionally, the at least one sub-TLV further includes a second sub-TLV, and a value field of the second sub-TLV includes a first flag, a second flag, a third flag, and encapsulation information.

[0258] The first flag is used to indicate whether the head node supports the alternate coloring of the flow detection, the second flag is used to indicate whether the head node supports the enhanced alternate coloring of the flow detection, and the third flag is used to indicate whether the head node supports the dynamic establishment of the service flow identification rule.

[0259] The encapsulation information includes H flag, D flag and S flag, the H flag is used to indicate whether the head node supports encapsulating the stream detection option in the hop-by-hop head, the D flag is used to indicate whether the head node supports encapsulating the stream detection option in the destination head, and the S flag is used to indicate whether the head node supports encapsulating the stream detection option in the SRH.

[0260] Optionally, the apparatus further includes:

[0261] The storage module is configured to store the service flow identification rule in the forwarding plane.

[0262] The encapsulation module is configured to encapsulate a second stream detection option for the second service packet to obtain a third service packet when the second service packet conforming to the service flow identification rule is received.

[0263] The transmission module is configured to transmit the third service packet to the head node through the second path.

[0264] Optionally, the apparatus further includes:

[0265] The deletion module is configured to delete the service flow identification rule if the second BGP update packet from the head node is received and the second BGP update packet does not include the configuration information, or delete the service flow identification rule if the packet including the plurality of first flow characteristics is not received for a preset time length.

[0266] Corresponding to the method embodiments, the embodiments of the present application further provide a stream detection information configuration apparatus, the apparatus is applied to a head node, as shown in Fig. 15, the apparatus includes:

[0267] The sending module 1501 is configured to send a first BGP update packet to a tail node, the first BGP update packet including configuration information of reverse stream detection.

[0268] The receiving module 1502 is configured to receive a first service packet.

[0269] The sending module 1501 is further configured to send a second service packet to the tail node through a first path, the second service packet including a first stream detection option, the first stream detection option including first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring stream detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

[0270] Optionally, the first BGP update message comprises an SR Policy SAFI NLRI field, and the SR Policy SAFI NLRI field comprises a tunnel encapsulation attribute, and the tunnel encapsulation attribute comprises a flow detection attribute TLV;

[0271] The flow detection attribute TLV comprises at least one sub-TLV, and the at least one sub-TLV is used to carry configuration information.

[0272] Optionally, the at least one sub-TLV comprises a first sub-TLV, and a value field of the first sub-TLV comprises a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of a plurality of second flow characteristics, and a tunnel level enabling mark; the plurality of second flow characteristics comprise a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; and the enabling information of the plurality of second flow characteristics comprises a destination IP address mask, a source IP address mask, a D mark, and an L4 mark.

[0273] The extended flow detection type identifier comprises an F mark, and the F mark is used to indicate whether the enabling information of the plurality of second flow characteristics is identified.

[0274] The destination IP address mask is used to indicate whether each bit of the destination IP address is enabled.

[0275] The source IP address mask is used to indicate whether each bit of the source IP address is enabled.

[0276] The D mark is used to indicate whether the DSCP is enabled.

[0277] The L4 mark comprises three bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

[0278] Optionally, the at least one sub-TLV further comprises a second sub-TLV, and a value field of the second sub-TLV comprises a first mark, a second mark, a third mark, and encapsulation information.

[0279] The first mark is used to indicate whether the head node supports alternate coloring of the flow detection, the second mark is used to indicate whether the head node supports enhanced alternate coloring of the flow detection, and the third mark is used to indicate whether the head node supports dynamic establishment of a service flow identification rule.

[0280] The encapsulation information comprises an H mark, a D mark, and an S mark, the H mark is used to indicate whether the head node supports encapsulating the flow detection option in a hop-by-hop header, the D mark is used to indicate whether the head node supports encapsulating the flow detection option in a destination header, and the S mark is used to indicate whether the head node supports encapsulating the flow detection option in an SRH.

[0281] Optionally, the sending module 1501 is further configured to send a second BGP update message to the tail node, the second BGP update message not including the configuration information, so as to instruct the tail node to delete the service flow identification rule.

[0282] Corresponding to the method embodiments, the embodiments of the present application further provide a network device applied to a tail node, as shown in FIG. 16, the network device comprises: a processor 1601; a transceiver 1604; a machine readable storage medium 1602, which stores machine executable instructions capable of being executed by the processor 1601; and the machine executable instructions cause the processor 1601 to perform the following steps: receiving a first BGP update message from a head node, the first BGP update message including configuration information of reverse flow detection;

[0283] Through the first path, receiving a first service message from the head node, the first service message including a first flow detection option, the first flow detection option including first indication information;

[0284] If the value of the first indication information is a first value, generating a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, the first path and the second path passing through the same intermediate node.

[0285] Optionally, the configuration information includes a tunnel level enabling mark.

[0286] The machine executable instructions further cause the processor 1601 to perform the following steps: if the value of the tunnel level enabling mark is the first value, generating a first type of service flow identification rule, the first type of service flow identification rule including a segment list identifier, the segment list identifier indicating the second path, the second path constituting a transmission tunnel.

[0287] Optionally, the first service message includes an original message, the original message including a plurality of first flow characteristics; and the configuration information further includes enabling information of a plurality of second flow characteristics.

[0288] The machine executable instructions further cause the processor 1601 to perform the following steps:

[0289] If the value of the tunnel enabling mark is a second value, obtaining the value of each second flow characteristic from the plurality of first flow characteristics according to each second flow characteristic enabled as indicated by the enabling information.

[0290] Generating a second type of service flow identification rule based on the value of the second flow characteristic.

[0291] Optionally, the first BGP update message comprises an SR Policy SAFI NLRI field, and the SR Policy SAFI NLRI field comprises a tunnel encapsulation attribute, and the tunnel encapsulation attribute comprises a flow detection attribute TLV;

[0292] The flow detection attribute TLV comprises at least one sub-TLV, and the at least one sub-TLV is used to carry configuration information.

[0293] Optionally, the at least one sub-TLV comprises a first sub-TLV, and a value field of the first sub-TLV comprises a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of a plurality of second flow characteristics, and a tunnel level enabling mark; the plurality of second flow characteristics comprise a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; and the enabling information of the plurality of second flow characteristics comprises a destination IP address mask, a source IP address mask, a D mark, and an L4 mark.

[0294] The extended flow detection type identifier comprises an F mark, and the F mark is used to indicate whether the enabling information of the plurality of second flow characteristics is identified.

[0295] The destination IP address mask is used to indicate whether each bit of the destination IP address is enabled.

[0296] The source IP address mask is used to indicate whether each bit of the source IP address is enabled.

[0297] The D mark is used to indicate whether the DSCP is enabled.

[0298] The L4 mark comprises three bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

[0299] Optionally, the at least one sub-TLV further comprises a second sub-TLV, and a value field of the second sub-TLV comprises a first mark, a second mark, a third mark, and encapsulation information.

[0300] The first mark is used to indicate whether the head node supports alternate coloring of the flow detection, the second mark is used to indicate whether the head node supports enhanced alternate coloring of the flow detection, and the third mark is used to indicate whether the head node supports dynamic establishment of a service flow identification rule.

[0301] The encapsulation information comprises an H mark, a D mark, and an S mark, the H mark is used to indicate whether the head node supports encapsulating the flow detection option in a hop-by-hop header, the D mark is used to indicate whether the head node supports encapsulating the flow detection option in a destination header, and the S mark is used to indicate whether the head node supports encapsulating the flow detection option in an SRH.

[0302] Optionally, the machine-executable instructions further cause the processor 1601 to perform the following steps:

[0303] storing the service flow identification rule in a forwarding plane;

[0304] when a second service packet conforming to the service flow identification rule is received, encapsulating a second flow detection option for the second service packet to obtain a third service packet;

[0305] transmitting the third service packet to the head node through the second path.

[0306] Optionally, the machine-executable instructions further cause the processor 1601 to perform the following steps:

[0307] if a second BGP update packet from the head node is received, and the second BGP update packet does not include the configuration information, deleting the service flow identification rule; or,

[0308] if the forward service flow is not received for a preset time period, deleting the service flow identification rule.

[0309] As shown in FIG. 16, the network device can further include a communication bus 1603. The processor 1601, the machine-readable storage medium 1602, and the transceiver 1604 can communicate with each other through the communication bus 1603. The communication bus 1603 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 1603 can be divided into an address bus, a data bus, a control bus, etc.

[0310] The transceiver 1604 can be a wireless communication module. The transceiver 1604 communicates data with other devices under the control of the processor 1601.

[0311] The machine-readable storage medium 1602 can include a Random Access Memory (RAM) and can also include a Non-Volatile Memory (NVM), such as at least one disk memory. In addition, the machine-readable storage medium 1602 can also be at least one storage device located away from the aforementioned processor.

[0312] The processor 1601 can be a general processor, including a central processing unit (CPU), a network processor (NP), etc.; can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0313] Corresponding to the above method embodiments, the embodiments of the present application also provide a network device applied to a head node, the network device comprising: a processor 1701; a transceiver 1704; a machine readable storage medium 1702, the machine readable storage medium 1702 storing machine executable instructions capable of being executed by the processor 1701; the machine executable instructions causing the processor 1701 to perform the following steps: sending a first BGP update message to a tail node, the first BGP update message comprising configuration information of reverse flow detection;

[0314] receiving a first service message;

[0315] sending a second service message to the tail node through a first path, the second service message comprising a first flow detection option, the first flow detection option comprising first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring flow detection, the service flow being transmitted through a second path, the second path being a forwarding path from the tail node to the head node, the first path and the second path comprising the same intermediate nodes.

[0316] Optionally, the first BGP update message comprises an SR Policy SAFI NLRI field, the SR Policy SAFI NLRI field comprising a tunnel encapsulation attribute, the tunnel encapsulation attribute comprising a flow detection attribute TLV.

[0317] The flow detection attribute TLV comprises at least one sub-TLV, the at least one sub-TLV being used to carry the configuration information.

[0318] Optionally, the at least one sub-TLV includes a first sub-TLV, and a value field of the first sub-TLV includes a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of a plurality of second flow characteristics, and a tunnel level enabling flag; the plurality of second flow characteristics include a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; the enabling information of the plurality of second flow characteristics includes a destination IP address mask, a source IP address mask, a D flag, and an L4 flag; the extended flow detection type identifier includes an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow characteristics is identified; the destination IP address mask is used to indicate whether each bit included in the destination IP address is enabled; the source IP address mask is used to indicate whether each bit included in the source IP address is enabled; the D flag is used to indicate whether the DSCP is enabled; and the L4 flag includes three bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

[0319] Optionally, the at least one sub-TLV further includes a second sub-TLV, and a value field of the second sub-TLV includes a first flag, a second flag, a third flag, and encapsulation information; the first flag is used to indicate whether the head node supports the alternate coloring-based in-situ flow detection, the second flag is used to indicate whether the head node supports the enhanced alternate coloring-based in-situ flow detection, and the third flag is used to indicate whether the head node supports the dynamic establishment of the service flow identification rule; and the encapsulation information includes an H flag, a D flag, and an S flag, the H flag is used to indicate whether the head node supports the encapsulation of the in-situ flow detection option in the per-hop header, the D flag is used to indicate whether the head node supports the encapsulation of the in-situ flow detection option in the destination header, and the S flag is used to indicate whether the head node supports the encapsulation of the in-situ flow detection option in the SRH.

[0320] Optionally, the machine executable instructions further cause the processor 1701 to perform the following steps:

[0321] sending, to the tail node, a second BGP update message, the second BGP update message not including the configuration information, to instruct the tail node to delete the service flow identification rule.

[0322] As shown in FIG. 17, the network device can further include a communication bus 1703. The processor 1701, the machine readable storage medium 1702, and the transceiver 1704 can communicate with each other through the communication bus 1703, and the communication bus 1703 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 1703 can be divided into an address bus, a data bus, a control bus, etc.

[0323] The transceiver 1704 can be a wireless communication module, which is controlled by the processor 1701 to interact with other devices.

[0324] The machine readable storage medium 1702 can include a random access memory (RAM) and can also include a non-volatile memory (NVM), such as at least one disk storage. In addition, the machine readable storage medium 1702 can also be at least one storage device located remotely from the aforementioned processor.

[0325] The processor 1701 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., and can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic component, a discrete hardware component.

[0326] Based on the same inventive concept, according to the method provided by the embodiments of the present application, the embodiments of the present application further provide a machine readable storage medium, which stores machine executable instructions executable by a processor. The processor is prompted by the machine executable instructions to implement the steps of any of the stream detection information configuration methods.

[0327] In yet another embodiment provided by the present application, a computer program product containing instructions is also provided, which, when running on a computer, causes the computer to perform the steps of any of the stream detection information configuration methods in the above embodiments.

[0328] It is to be noted that, as used in this specification and the appended claims, the singular forms "a," "an" and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component" can include a combination of two or more components, and the term "an element" can include comparable reference to a plurality of elements. Also, as used in this specification and the appended claims, the term "or" as used in the context of "A / B" or "A / B / C" means any of the possibilities; for example, the term "or" means "any of A, B, or C; or any of A, B, or C." Further, the term "comprising" as used in this specification and the appended claims, whether in the description of the application or the claims themselves, is used in the sense of "including" and means "including but not limited to." Further, the term "consisting essentially of" as used in this specification and the appended claims, whether in the description of the application or the claims themselves, means "including at least the members identified, but excluding others not specifically identified." Further, the term "consisting of" as used in this specification and the appended claims, whether in the description of the application or the claims themselves, means "including and limited to."

[0329] The foregoing is considered as illustrative only of the principles of the application. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the application to the exact construction and practice described. Accordingly, all such variations are intended to be included within the scope of the present application as defined in the following claims.

Claims

1. A method of configuring in-stream detection information, characterized by, The method applied to a tail node comprises: receiving a first BGP update message from a head node, the first BGP update message comprising configuration information of in-situ flow detection; receiving a first service message from the head node through a first path, the first service message comprising a first in-situ flow detection option, the first in-situ flow detection option comprising first indication information; if the value of the first indication information is a first value, generating a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring in-situ flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, the first path and the second path passing through the same intermediate node.

2. The method of claim 1, wherein, The configuration information comprises a tunnel-level enabling flag; The generating of the service flow identification rule based on the configuration information comprises: if the value of the tunnel-level enabling flag is the first value, generating a first type of service flow identification rule, the first type of service flow identification rule comprising a segment list identifier, the path indicated by the segment list identifier being the second path, the second path constituting a transmission tunnel.

3. The method of claim 2, wherein, The first service message comprises an original message, the original message comprising a plurality of first flow characteristics; The configuration information further comprises enabling information of a plurality of second flow characteristics; The generating of the service flow identification rule based on the configuration information comprises: if the value of the tunnel enabling flag is a second value, acquiring the value of each second flow characteristic from the plurality of first flow characteristics according to each enabled second flow characteristic indicated by the enabling information; generating a second type of service flow identification rule based on the value of the second flow characteristic.

4. The method according to any one of claims 1 to 3, characterized in that, The first BGP update message comprises an SR Policy SAFI NLRI field, the SR Policy SAFI NLRI field comprising a tunnel encapsulation attribute, the tunnel encapsulation attribute comprising an in-situ flow detection attribute TLV; The in-situ flow detection attribute TLV comprises at least one sub-TLV, the at least one sub-TLV being used to carry the configuration information.

5. The method of claim 4, wherein, The at least one sub-TLV comprises a first sub-TLV, a value field of the first sub-TLV comprising a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of the plurality of second flow characteristics, and a tunnel-level enabling flag; the plurality of second flow characteristics comprising a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; the enabling information of the plurality of second flow characteristics comprising a destination IP address mask, a source IP address mask, a D flag, and an L4 flag; The extended flow detection type identifier comprises an F flag, the F flag being used to indicate whether to identify the enabling information of the plurality of second flow characteristics; The destination IP address mask is used to indicate whether each bit of the destination IP address is enabled; The source IP address mask is used to indicate whether each bit of the source IP address is enabled; The D flag is used to indicate whether the DSCP is enabled; The L4 label includes 3 bits, the first bit is used to indicate whether the protocol name is enabled, the second bit is used to indicate whether the destination port is enabled, and the third bit is used to indicate whether the source port is enabled.

6. The method of claim 5, wherein, The at least one sub-TLV further includes a second sub-TLV, a value field of the second sub-TLV includes a first label, a second label, a third label and encapsulation information; The first label is used to indicate whether the head node supports in-situ OAM, the second label is used to indicate whether the head node supports enhanced in-situ OAM, and the third label is used to indicate whether the head node supports dynamically establishing the service flow Identification rule; The encapsulation information includes H label, D label and S label, the H label is used to indicate whether the head node supports encapsulating in-situ OAM option in hop-by-hop header, the D label is used to indicate whether the head node supports encapsulating in-situ OAM option in destination header, and the S label is used to indicate whether the head node supports encapsulating in-situ OAM option in SRH.

7. The method of claim 1, wherein, After the service flow identification rule is generated based on the configuration information, the method further includes: storing the service flow identification rule in a forwarding plane; when a second service packet meeting the service flow identification rule is received, encapsulating a second in-situ OAM option for the second service packet to obtain a third service packet; transmitting the third service packet to the head node through the second path.

8. The method of claim 3, wherein, After the service flow identification rule is generated based on the configuration information, the method further includes: if a second BGP update packet from the head node is received and the second BGP update packet does not include the configuration information, deleting the service flow identification rule; or if no packet including the plurality of first flow characteristics is received for a preset time period, deleting the service flow identification rule.

9. A method for configuring flow-following detection information, characterized in that, Applied to a head node, the method includes: sending a first BGP update packet to a tail node, the first BGP update packet including configuration information of in-situ OAM; receiving a first service packet; sending a second service packet to the tail node through a first path, the second service packet including a first in-situ OAM option, the first in-situ OAM option including first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring in-situ OAM, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

10. The method of claim 9, wherein, The first BGP update packet includes an SR Policy SAFI NLRI field, and the SR Policy SAFI NLRI field includes a tunnel encapsulation attribute, and the tunnel encapsulation attribute includes an in-situ OAM attribute TLV; The in-situ OAM attribute TLV includes at least one sub-TLV, and the at least one sub-TLV is used to carry the configuration information.

11. The method of claim 10, wherein, The at least one sub-TLV includes a first sub-TLV, and a value field of the first sub-TLV includes a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of a plurality of second flow characteristics, and a tunnel level enabling flag; the plurality of second flow characteristics include a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; the enabling information of the plurality of second flow characteristics includes a destination IP address mask, a source IP address mask, a D flag, and an L4 flag; The extended flow detection type identifier includes an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow characteristics is identified; The destination IP address mask is used to indicate whether each bit included in the destination IP address is enabled; The source IP address mask is used to indicate whether each bit included in the source IP address is enabled; The D flag is used to indicate whether the DSCP is enabled; The L4 flag includes three bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

12. The method of claim 11, wherein, The at least one sub-TLV further includes a second sub-TLV, and a value field of the second sub-TLV includes a first flag, a second flag, a third flag, and encapsulation information; The first flag is used to indicate whether the head node supports in-situ flow detection of alternate coloring, the second flag is used to indicate whether the head node supports in-situ flow detection of enhanced alternate coloring, and the third flag is used to indicate whether the head node supports dynamically establishing the service flow identification rule; The encapsulation information includes an H flag, a D flag, and an S flag, the H flag is used to indicate whether the head node supports encapsulating the in-situ flow detection option in a hop-by-hop header, the D flag is used to indicate whether the head node supports encapsulating the in-situ flow detection option in a destination header, and the S flag is used to indicate whether the head node supports encapsulating the in-situ flow detection option in an SRH.

13. The method according to any one of claims 9-12, characterized in that, After the second service message is sent to the tail node through the first path, the method further includes: sending a second BGP update message to the tail node, the second BGP update message does not include the configuration information, and the second BGP update message is used to instruct the tail node to delete the service flow identification rule.

14. An in-stream detection information configuration apparatus characterized by comprising: The device is applied to a tail node and includes: a receiving module configured to receive a first BGP update message from a head node, the first BGP update message including configuration information of in-situ flow detection, and receive a first service message from the head node through a first path, the first service message including a first in-situ flow detection option, and the first in-situ flow detection option including first indication information; a generating module configured to, if a value of the first indication information is a first value, generate a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow that needs to be subjected to in-situ flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

15. The apparatus of claim 14, wherein, The configuration information includes a tunnel level enabling flag. The generating module is specifically configured to: if the value of the tunnel level enabling flag is a first value, generate a first type of service flow identification rule, the first type of service flow identification rule comprising a segment list identifier, the path indicated by the segment list identifier being the second path, and the second path constituting a transmission tunnel.

16. The apparatus of claim 15, wherein, The first service packet comprises an original packet, and the original packet comprises a plurality of first flow characteristics; the configuration information further comprises enabling information of a plurality of second flow characteristics; The generating module is specifically configured to: if the value of the tunnel enabling flag is a second value, according to each second flow characteristic indicated by the enabling information, obtain the value of each second flow characteristic from the plurality of first flow characteristics; and generate a second type of service flow identification rule based on the value of the second flow characteristic.

17. The apparatus of any of claims 14-16, wherein, The first BGP update packet comprises an SR Policy SAFI NLRI field, the SR Policy SAFI NLRI field comprising a tunnel encapsulation attribute, and the tunnel encapsulation attribute comprising a flow detection attribute TLV; The flow detection attribute TLV comprises at least one sub-TLV, and the at least one sub-TLV is used to carry the configuration information.

18. The apparatus of claim 17, wherein, The at least one sub-TLV comprises a first sub-TLV, a value field of the first sub-TLV comprising a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of the plurality of second flow characteristics, and a tunnel level enabling flag; the plurality of second flow characteristics comprising a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; and the enabling information of the plurality of second flow characteristics comprising a destination IP address mask, a source IP address mask, a D flag, and an L4 flag. The extended flow detection type identifier comprises an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow characteristics is identified. The destination IP address mask is used to indicate whether each bit of the destination IP address is enabled. The source IP address mask is used to indicate whether each bit of the source IP address is enabled. The D flag is used to indicate whether the DSCP is enabled. The L4 flag comprises three bits, a first bit being used to indicate whether the protocol name is enabled, a second bit being used to indicate whether the destination port is enabled, and a third bit being used to indicate whether the source port is enabled.

19. The apparatus of claim 18, wherein, The at least one sub-TLV further comprises a second sub-TLV, and a value field of the second sub-TLV comprising a first flag, a second flag, a third flag, and encapsulation information. The first flag is used to indicate whether the head node supports alternate coloring based flow detection, the second flag is used to indicate whether the head node supports enhanced alternate coloring based flow detection, and the third flag is used to indicate whether the head node supports dynamically establishing the service flow identification rule. The encapsulation information includes an H flag, a D flag and an S flag, the H flag is used to indicate whether the head node supports encapsulating a stream detection option in a hop-by-hop head, the D flag is used to indicate whether the head node supports encapsulating a stream detection option in a destination head, and the S flag is used to indicate whether the head node supports encapsulating a stream detection option in an SRH.

20. The apparatus of claim 14, wherein, The device further includes: a storage module, configured to store the service flow identification rule in a forwarding plane; an encapsulation module, configured to encapsulate a second stream detection option for a second service packet when the second service packet meets the service flow identification rule, to obtain a third service packet; a transmission module, configured to transmit the third service packet to the head node through the second path.

21. The apparatus of claim 16, wherein, The device further includes: a deletion module, configured to delete the service flow identification rule if a second BGP update packet from the head node is received and the second BGP update packet does not include the configuration information, or delete the service flow identification rule if a packet including the plurality of first flow characteristics is not received for a preset time length.

22. An in-stream detection information configuration apparatus characterized by comprising: Applied to a head node, the device includes: a sending module, configured to send a first BGP update packet to a tail node, the first BGP update packet including configuration information of reverse stream detection; a receiving module, configured to receive a first service packet; The sending module is further configured to send a second service packet to the tail node through a first path, the second service packet including a first stream detection option, the first stream detection option including first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring stream detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, and the first path and the second path passing through the same intermediate node.

23. The apparatus of claim 22, wherein, The first BGP update packet includes an SR Policy SAFI NLRI field, the SR Policy SAFI NLRI field including a tunnel encapsulation attribute, and the tunnel encapsulation attribute including a stream detection attribute TLV; The stream detection attribute TLV includes at least one sub-TLV, and the at least one sub-TLV is used to carry the configuration information.

24. The apparatus of claim 23, wherein, The at least one sub-TLV includes a first sub-TLV, a value field of the first sub-TLV including service flow identification, device node identification, extended stream detection type identification, enabling information of a plurality of second flow characteristics and a tunnel level enabling flag; the plurality of second flow characteristics including a destination IP address, a source IP address, a DSCP, a protocol name, a destination port and a source port; and the enabling information of the plurality of second flow characteristics including a destination IP address mask, a source IP address mask, a D flag and an L4 flag; The extended stream detection type identification includes an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow characteristics is identified. The extended stream detection type identification includes an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow characteristics is identified. The destination IP address mask is used to indicate whether each bit of the destination IP address is enabled or not; The source IP address mask is used to indicate whether each bit of the source IP address is enabled or not; The D flag is used to indicate whether the DSCP is enabled or not; The L4 flag includes three bits, the first bit is used to indicate whether the protocol name is enabled or not, the second bit is used to indicate whether the destination port is enabled or not, and the third bit is used to indicate whether the source port is enabled or not.

25. The apparatus of claim 24, wherein, The at least one sub-TLV further includes a second sub-TLV, and a value field of the second sub-TLV includes a first flag, a second flag, a third flag and encapsulation information; The first flag is used to indicate whether the head node supports in-situ flow detection of alternate coloring, the second flag is used to indicate whether the head node supports in-situ flow detection of enhanced alternate coloring, and the third flag is used to indicate whether the head node supports dynamically establishing the traffic flow identification rule; The encapsulation information includes an H flag, a D flag and an S flag, the H flag is used to indicate whether the head node supports encapsulating the in-situ flow detection option in the hop-by-hop header, the D flag is used to indicate whether the head node supports encapsulating the in-situ flow detection option in the destination header, and the S flag is used to indicate whether the head node supports encapsulating the in-situ flow detection option in the SRH.

26. The apparatus of any one of claims 22-25, wherein, The sending module is further configured to send a second BGP update message to the tail node, the second BGP update message does not include the configuration information, and is used to instruct the tail node to delete the traffic flow identification rule.

27. A network device, comprising: The network device applied to a tail node includes: a processor; a transceiver; a machine readable storage medium, the machine readable storage medium stores machine executable instructions which can be executed by the processor; the machine executable instructions cause the processor to execute the following steps: receiving a first BGP update message from a head node, the first BGP update message includes configuration information of reverse in-situ flow detection; receiving a first service message from the head node through a first path, the first service message includes a first in-situ flow detection option, and the first in-situ flow detection option includes first indication information; if the value of the first indication information is a first value, generating a traffic flow identification rule based on the configuration information, the traffic flow identification rule is used to identify a service flow which needs to be subjected to in-situ flow detection, the service flow is transmitted through a second path, the second path is a forwarding path of the tail node to the head node, and the first path and the second path pass through the same intermediate node.

28. The network device of claim 27, wherein, The configuration information includes a tunnel level enabling flag, and the tunnel level enabling flag is used to indicate whether to perform reverse in-situ flow detection based on a tunnel; The machine executable instructions further cause the processor to execute the following steps: if the value of the tunnel level enabling flag is the first value, generating a first type of traffic flow identification rule, and the first type of traffic flow identification rule includes a segment list identifier, the path indicated by the segment list identifier is the second path, and the second path constitutes a transmission tunnel.

29. The network device of claim 28, wherein, The first service packet includes an original packet, and the original packet includes a plurality of first flow characteristics; and the configuration information further includes enabling information of a plurality of second flow characteristics; The machine executable instructions further cause the processor to perform the following steps: If the value of the tunnel enabling flag is the second value, then according to each second flow characteristic indicated by the enabling information, the value of each second flow characteristic is obtained from the plurality of first flow characteristics; Based on the value of the second flow characteristic, a second type of service flow recognition rule is generated.

30. The network device of any of claims 27-29, wherein, The first BGP update packet includes an SR Policy SAFI NLRI field, and the SR Policy SAFI NLRI field includes a tunnel encapsulation attribute, and the tunnel encapsulation attribute includes a stream detection attribute TLV; The stream detection attribute TLV includes at least one sub-TLV, and the at least one sub-TLV is used to carry the configuration information.

31. The network device of claim 30, wherein, The at least one sub-TLV includes a first sub-TLV, and a value field of the first sub-TLV includes a service flow identifier, a device node identifier, an extended flow detection type identifier, enabling information of the plurality of second flow characteristics, and a tunnel level enabling flag; the plurality of second flow characteristics include a destination IP address, a source IP address, a DSCP, a protocol name, a destination port, and a source port; and the enabling information of the plurality of second flow characteristics includes a destination IP address mask, a source IP address mask, a D flag, and an L4 flag. The extended flow detection type identifier includes an F flag, and the F flag is used to indicate whether the enabling information of the plurality of second flow characteristics is recognized; The destination IP address mask is used to indicate whether each bit included in the destination IP address is enabled; The source IP address mask is used to indicate whether each bit included in the source IP address is enabled; The D flag is used to indicate whether the DSCP is enabled; The L4 flag includes three bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

32. The network device of claim 31, wherein, The at least one sub-TLV further includes a second sub-TLV, and a value field of the second sub-TLV includes a first flag, a second flag, a third flag, and encapsulation information; The first flag is used to indicate whether the head node supports alternate coloring stream detection, the second flag is used to indicate whether the head node supports enhanced alternate coloring stream detection, and the third flag is used to indicate whether the head node supports dynamically establishing the service flow recognition rule; The encapsulation information includes an H flag, a D flag, and an S flag, the H flag is used to indicate whether the head node supports encapsulating the stream detection option in the hop-by-hop head, the D flag is used to indicate whether the head node supports encapsulating the stream detection option in the destination head, and the S flag is used to indicate whether the head node supports encapsulating the stream detection option in the SRH.

33. The network device of claim 27, wherein, The machine executable instructions further cause the processor to perform the following steps: The service flow recognition rule is stored in a forwarding plane. when a second service packet conforming to the service flow identification rule is received, a second flow detection option is encapsulated for the second service packet, to obtain a third service packet; transmit the third service packet to the head node through the second path.

34. The network device of claim 29, wherein, The machine executable instructions further cause the processor to perform the following steps: if a second BGP update packet from the head node is received, and the second BGP update packet does not include the configuration information, then delete the service flow identification rule; or if no packet including the plurality of first flow characteristics is received for a preset time period, then delete the service flow identification rule. The network device applied to a head node comprises:

35. A network device, comprising: a processor; a transceiver; a machine readable storage medium storing machine executable instructions executable by the processor; the machine executable instructions cause the processor to perform the following steps: send a first BGP update packet to a tail node, the first BGP update packet including configuration information of reverse flow detection; receive a first service packet; send a second service packet to the tail node through a first path, the second service packet including a first flow detection option, the first flow detection option including first indication information, the first indication information being used to indicate whether the tail node generates a service flow identification rule based on the configuration information, the service flow identification rule being used to identify a service flow requiring flow detection, the service flow being transmitted through a second path, the second path being a forwarding path of the tail node to the head node, the first path and the second path passing through the same intermediate node. The first BGP update packet includes an SR Policy SAFI NLRI field, the SR Policy SAFI NLRI field including a tunnel encapsulation attribute, the tunnel encapsulation attribute including a flow detection attribute TLV; 36. The network device of claim 35, wherein, The flow detection attribute TLV includes at least one sub-TLV, the at least one sub-TLV being used to carry the configuration information. The at least one sub-TLV includes a first sub-TLV, a value field of the first sub-TLV including service flow identification, device node identification, extended flow detection type identification, enabling information of a plurality of second flow characteristics, and tunnel level enabling mark; the plurality of second flow characteristics including destination IP address, source IP address, DSCP, protocol name, destination port, and source port; the enabling information of the plurality of second flow characteristics including destination IP address mask, source IP address mask, D mark, and L4 mark; 37. The network device of claim 36, wherein, The extended flow detection type identification includes F mark, the F mark being used to indicate whether the enabling information of the plurality of second flow characteristics is identified; The destination IP address mask is used to indicate whether each bit included in the destination IP address is enabled; The source IP address mask is used to indicate whether each bit included in the source IP address is enabled; The D mark is used to indicate whether the DSCP is enabled; The D mark is used to indicate whether the DSCP is enabled; The L4 label includes 3 bits, a first bit is used to indicate whether the protocol name is enabled, a second bit is used to indicate whether the destination port is enabled, and a third bit is used to indicate whether the source port is enabled.

38. The network device of claim 37, wherein, The at least one sub-TLV further includes a second sub-TLV, a value field of the second sub-TLV includes a first label, a second label, a third label and encapsulation information; The first label is used to indicate whether the head node supports in-situ OAM, the second label is used to indicate whether the head node supports enhanced in-situ OAM, and the third label is used to indicate whether the head node supports dynamically establishing the traffic flow identification rule; The encapsulation information includes an H label, a D label and an S label, the H label is used to indicate whether the head node supports encapsulating the in-situ OAM option in a hop-by-hop header, the D label is used to indicate whether the head node supports encapsulating the in-situ OAM option in a destination header, and the S label is used to indicate whether the head node supports encapsulating the in-situ OAM option in an SRH.

39. The network device of any of claims 35-38, wherein, The machine executable instructions further cause the processor to perform the following steps: sending a second BGP update message to the tail node, the second BGP update message does not include the configuration information, and the second BGP update message is used to instruct the tail node to delete the traffic flow identification rule.

40. A machine-readable storage medium, characterized in that, The machine executable instructions stored in the computer readable medium, when being called and executed by the processor, cause the processor to implement the method of any one of claims 1-13.

41. A computer program product, characterised in that, The computer program product causes the processor to implement the method of any one of claims 1-13.

Images