CN115242892A

CN115242892A - Flow identification obtaining method, device, equipment and medium

Info

Publication number: CN115242892A
Application number: CN202210770679.7A
Authority: CN
Inventors: 覃耿; 杜伟; 饶小兵
Original assignee: New H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2022-06-30
Filing date: 2022-06-30
Publication date: 2022-10-25
Anticipated expiration: 2042-06-30
Also published as: CN115242892B

Abstract

The embodiment of the application provides a method, a device, equipment and a medium for acquiring a flow identifier, which relate to the technical field of communication, wherein the method is applied to a CPU (central processing unit) of IOAM (input/output access memory) equipment and comprises the following steps: receiving a head message obtained based on a random flow detection identification table item; selecting a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to the FLOW characteristic information of the first message; generating a FLOW ID of a service FLOW to which the header message belongs based on the equipment ID and the selected sub-FLOW ID; and sending an ACL table item to a hardware chip, wherein a matching domain of the ACL table item is FLOW characteristic information, and an action item is an IOAM header which comprises a FLOW ID and is added in the message. Stream-following detection can be performed on streams with shorter lifetime.

Description

Flow identification obtaining method, device, equipment and medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a device, and a medium for acquiring a flow identifier.

Background

The detection technology with flow is a detection technology for detecting the real service flow of the network to obtain the network performance index. An In-band Operation Administration and Maintenance (IOAM) device In a network can identify a stream by a FLOW ID (stream identifier), after receiving an original service packet that needs to be detected with the stream, the IOAM device can insert an IOAM header into the original packet, where the IOAM header carries the FLOW ID, and a network device In a forwarding path can report detection data to an analyzer by the FLOW ID.

The method for obtaining the FLOW ID by the IOAM device at present is as follows: the controller issues a quadruplet rule to the IOAM device, where the quadruplet may include a source IP address, a source Media Access Control (MAC) address, a destination IP address, and a destination MAC address of a stream that needs to be detected along with the stream. Then, when the forwarding layer of the IOAM device receives the packet matching the quadruplet, the packet matching the quadruplet may be reported to a Central Processing Unit (CPU) based on the quadruplet rule, the CPU extracts a quintuple of the packet and sends the quintuple to the controller, and the quintuple increases a port number compared to the quadruplet.

Then, the controller generates a FLOW ID for the received quintuple in the FLOW ID pool, and issues a mapping rule of the quintuple and the FLOW ID to a CPU of the IOAM device, and the CPU issues the mapping rule to a forwarding layer. When receiving the packet matching the five-tuple in the mapping rule, the subsequent forwarding layer may obtain the FLOW ID matching the five-tuple, and encapsulate the IOAM header including the FLOW ID for the packet.

In the process of obtaining the FLOW ID by the IOAM device, the processes of reporting the quintuple to the controller, generating the FLOW ID by the controller, and issuing the mapping rule by the controller by the IOAM device all require time, so that the speed of obtaining the FLOW ID by the IOAM device is slow. However, the lifetime of some FLOWs that need to be detected with the FLOW is very short, and the lifetime may be less than the total time consumed by the above process, after the controller generates FLOW IDs for these FLOWs and issues mapping rules to the IOAM device, these FLOWs may have died, and the IOAM device cannot match messages of these FLOWs through the mapping rules, so that the FLOW with the short lifetime cannot be detected with the FLOW.

Disclosure of Invention

An object of the embodiments of the present application is to provide a method, an apparatus, a device, and a medium for acquiring a stream identifier, so as to solve the problem that a stream with a short lifetime cannot be detected along with the stream. The specific technical scheme is as follows:

in a first aspect, an embodiment of the present application provides a flow identifier obtaining method, where the method is applied to a CPU of an IOAM device, and the method includes:

receiving a head message acquired based on a random flow detection identification table entry;

selecting a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to the FLOW characteristic information of the first message;

generating a FLOW ID of a traffic FLOW to which the header message belongs based on the device ID and the selected sub-FLOW ID;

and issuing an ACL table item to a hardware chip, wherein a matching domain of the ACL table item is the FLOW characteristic information, and an action item is an IOAM (input/output access am) head which comprises the FLOW ID and is added into a message.

In a second aspect, an embodiment of the present application provides a flow identifier obtaining apparatus, where the apparatus is applied to a CPU of an IOAM device, and the apparatus includes:

the receiving module is used for receiving a head message acquired based on the flow detection identification table item;

a selecting module, configured to select a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to the FLOW characteristic information of the first packet;

a generating module, configured to generate a FLOW ID of a service FLOW to which the header message belongs based on the device ID and the selected sub-FLOW ID;

and the issuing module is used for issuing an ACL table item to a hardware chip, wherein the matching domain of the ACL table item is the FLOW characteristic information, and the action item is the addition of an IOAM header comprising the FLOW ID in a message.

By adopting the technical scheme, after receiving a head message acquired based on the FLOW-following detection identification table item, a CPU of the IOAM equipment can select a FLOW ID in an idle state from a FLOW ID pool according to the FLOW characteristic information of the head message, further generate the FLOW ID based on the equipment ID and the FLOW ID, and issue an ACL table item to a hardware chip, wherein the matching field of the ACL table item is the FLOW characteristic information, and the action item is the addition of an IOAM head including the FLOW ID in the message. Therefore, in the above process, the IOAM device does not need to request the controller to acquire the FLOW ID, but can generate the ACL entry in its own CPU, and the generation speed is high. Compared with the prior art, the time for sending the quintuple information to the controller and issuing the FLOW ID by the controller is saved, the time for generating the FLOW ID by the IOAM device is shorter than the time for generating the FLOW ID by the controller for a plurality of IOAM devices, and the time consumption is reduced to a great extent. Further, the problem that the FLOW detection with short memory time cannot be carried out due to the fact that the time consumption for obtaining the FLOW ID is too long can be avoided.

Of course, not all advantages described above need to be achieved at the same time in the practice of any one product or method of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and it is also obvious for a person skilled in the art to obtain other embodiments according to the drawings.

Fig. 1 is a schematic structural diagram of an ad hoc network provided in an embodiment of the present application;

fig. 2 is an exemplary schematic diagram of three service packets to which an IOAM header is added according to an embodiment of the present application;

fig. 3 is an IPv4 packet format according to an embodiment of the present application;

fig. 4a is a schematic diagram of issuing a FLOW ID according to an embodiment of the present application;

fig. 4b is a schematic diagram illustrating a process of obtaining FLOW ID by an IOAM device according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a flow identifier obtaining method according to an embodiment of the present application;

fig. 6 is a schematic diagram of a sub-FLOW ID state machine according to an embodiment of the present application;

fig. 7a is a relational diagram of a seed FLOW ID linked list and a quintuple linked list according to an embodiment of the present application;

fig. 7b is a relational diagram of another seed FLOW ID linked list and a quintuple linked list provided in the embodiment of the present application;

fig. 8 is a schematic diagram of specifications of an issuing device ID and a sub FLOW ID according to an embodiment of the present application;

fig. 9 is a schematic diagram illustrating a process of obtaining FLOW ID by an IOAM device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a flow identifier obtaining apparatus according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application are within the scope of protection of the present application.

For ease of understanding, the related concepts related to the embodiments of the present application will be first described.

The flow-following detection technology in the embodiment of the application is an IOAM-based flow-following detection technology, that is, an IOAM head is carried in a service packet transmitted in a flow-following detection networking, after each device in the flow-following detection networking recognizes the IOAM head included in the service packet, statistical data can be reported to an analyzer based on the IOAM head, the analyzer can obtain information such as device delay, link packet loss, device packet loss and the like by analyzing the statistical data, and can also draw a path of the flow passing through the device.

As shown in fig. 1, fig. 1 is a schematic structural diagram of a flow-following detection networking, where a controller may issue Configuration information of flow-following detection to each IOAM node through a Network Configuration protocol, an IOAM node serving as a path head node may add an IOAM head to a received service packet according to the Configuration information of flow-following detection, and then each IOAM node on a forwarding path of the service packet performs flow-following detection on the service packet according to the IOAM head included in the service packet, and sends statistical data to an analyzer through Telemetry. The telemetering is a new generation of network monitoring technology for remotely acquiring data from equipment at high speed.

As shown in fig. 2, fig. 2 is an exemplary diagram of three traffic packets to which an IOAM header is added, and the IOAM header may be encapsulated after an IP header of an original traffic packet.

The 1 st packet in fig. 2 includes: MAC layer, IP layer, IOAM Header and Payload;

the 2 nd packet in fig. 2 includes: MAC layer, IP layer, IOAM Header, TCP/UDP (protocol layer), and Payload.

The 3 rd packet in fig. 2 includes: outer MAC layer, outer IP layer, IOAM Header, out UDP, VXLAN and Payload.

In each message shown in fig. 2, a FLOW ID having a mapping relationship with a five-tuple exists in an IOAM header to identify a specific FLOW, and taking an IPv4 message as an example, as shown in fig. 3, the IPv4 message includes an IPv4 header, an IOAM header, and a Transmission Control Protocol (TCP) \ User Datagram Protocol (UDP) \ Payload.

Wherein, IPv4 includes in the head:

version (Version, ver.) takes 4 bits, representing the IP Version.

Header Length (HL), which takes 4 bits, indicates the Length of the entire Header.

Differentiated Services Code Point (DSCP) occupies 6 bits, which is a Qos priority descriptor.

Total Length (Total Length) takes 16 bits, and represents the Length of the whole message.

And the Identification (Identification) occupies 16 bits and is used for indicating the Identification of the data packet.

The Flag (Flag) occupies 8 bits and is Flag information.

The slice Offset (Fragmet Offset) occupies 13 bits and indicates the position of the IP slice.

Time To Live (TTL), which occupies 8 bits, represents the Time To Live of the packet.

Protocol (Protocol), which takes 8 bits and identifies the upper layer Protocol.

Checksum (Checksum), which takes 16 bits to check the header.

Source address (Source IP), takes 32 bits.

The Destination address (Destination IP) occupies 32 bits.

The IOAM header includes:

a FLOW identification (FLOW ID) that identifies a detection FLOW.

And the ad other function bit.

As shown in fig. 4a, in the related art, a controller maintains a FLOW ID pool, IOAM devices (for example, device 1 and device 2 in fig. 4 a) may apply for the FLOW ID to the controller, and then the controller may generate FLOW IDs for device 1 and device 2 from the FLOW ID pool and issue the FLOW IDs to device 1 and device 2, respectively.

The process of obtaining the FLOW ID by each IOAM device is specifically shown in fig. 4b, taking the IOAM device as a router as an example, where the router includes a device CPU platform and a device driver, the controller issues a four-tuple rule of a stream to be detected to the device CPU platform of the IOAM device, and the device CPU platform issues the four-tuple rule to the device driver.

After the device driver receives the original message, if it is determined that the original message matches a four-tuple rule in an Access Control List (ACL), the original message is sent to a device CPU platform, and the device CPU platform obtains a five-tuple of the message by analyzing the original message, and then sends the five-tuple to a controller.

After receiving the quintuple, the controller generates a FLOW ID for the quintuple in a FLOW ID specification pool with a specified size, establishes a mapping relation between the quintuple and the FLOW ID, and issues the mapping relation to an ACL in a device driver of the IOAM device.

After the subsequent device driver matches the original message conforming to the quintuple through the ACL, an IOAM header may be inserted into the matched original message, where the IOAM header includes a FLOW ID having a mapping relationship with the quintuple.

The device driver may count in the incoming direction of the original service packet, for example, record a timestamp of receiving the service packet, count the number of received packets belonging to the FLOW ID, and so on. After parsing the IOAM header in the egress direction, a statistical count may be made based on the IOAM header. The device driver may periodically report the flow statistical information obtained by performing statistical counting in the ingress direction and the egress direction to the analyzer.

However, in the above process, the device CPU platform sends five tuples to the controller through telemetric technology and the like, the sending process requires time consumption (time consumption X), multiple IOAM devices in the whole network all require the controller to calculate and generate FLOW ID (time consumption Y), the controller issues a mapping relationship to the IOAM device (time consumption Z), and X + Y + Z = obtains total time consumption T of FLOW ID. However, there are many short connections in the network, the lifetime of the FLOWs is very short, and the lifetime may be shorter than the total consumed time T, after the device driver of the IOAM device obtains the FLOW ID, the FLOWs may die, and the device driver of the IOAM device cannot match the messages of the FLOWs through the quintuple in the mapping rule, so that the FLOWs with short lifetime cannot be detected along with the FLOWs.

In order to solve the above problem, an embodiment of the present application provides a flow identifier obtaining method, where the method is applied to a CPU of an IOAM device, and as shown in fig. 5, the method includes:

s501, receiving a head message obtained based on the flow detection identification table entry.

In the embodiment of the application, after the hardware chip of the IOAM device receives the message, the received message can be matched with the flow detection identification table entry, and if the received message is successfully matched with the flow detection identification table entry, the first message is reported to the CPU. As an example, if the IOAM device is a switch, the hardware chip may be an Application Specific Integrated Circuit (ASIC) chip.

The flow following detection identification table entry may be a four-tuple rule issued by the controller to the IOAM device in advance, the four-tuple rule may specifically be an ACL rule, a matching field of the four-tuple rule is a four-tuple of a service flow that needs flow following detection, the action entry is to report a first message to the CPU, and the four-tuple may include a source IP address, a source MAC address, a destination IP address, and a destination MAC address.

S502, selecting a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to the FLOW characteristic information of the first message.

The CPU can analyze the first message to obtain the stream characteristic information of the first message.

The stream feature information is a set of feature information for identifying a stream. The flow characteristic information may be a quintuple of the packet.

The quintuple of the message is obtained by adding a protocol number or a source port number or a destination port number on the basis of the quadruplet.

Or the quintuple of the packet may also be a source IP address, a source port number, a protocol number, a destination IP address, and a destination port number, where the source IP address and the destination IP address included in the quintuple are the same as the source IP address and the destination IP address included in the above quadruplet.

In addition, the flow characteristic information may also be a set of other characteristic information for identifying a flow, and is not limited to a quintuple, for example, the flow characteristic information may include: source IP address, source port number, protocol number, destination IP address, destination port number, source MAC address, and destination MAC address, to name but a few.

In the following embodiments, explanation is given by taking flow characteristic information as a quintuple of a packet as an example.

The sub-FLOW ID pool is a specification pool that the controller configures for the IOAM device in advance, and a method of selecting the sub-FLOW ID will be described in detail in the following embodiments.

And S503, generating the FLOW ID of the service FLOW to which the header message belongs based on the device ID and the selected sub-FLOW ID.

The device ID is configured for the IOAM device in advance by the controller, and the CPU may splice the device ID and the selected subflow ID to obtain the FLOW ID of the service FLOW to which the header message belongs.

It should be noted that, in the FLOW ID, the bits occupied by the device ID and the sub-FLOW ID may be set based on actual requirements, which is not limited in the embodiment of the present application.

And S504, issuing ACL list items to the hardware chip.

The matching domain of the ACL table entry is FLOW characteristic information, and the action entry is an IOAM header which is added into the message and comprises the FLOW ID.

By adopting the FLOW identifier obtaining method provided by the embodiment of the application, after receiving a first message obtained based on a FLOW-following detection identification table item, a CPU of an IOAM device may select a subflow ID in an idle state from a subflow ID pool according to FLOW characteristic information of the first message, and further may generate a FLOW ID based on the device ID and the subflow ID, and issue an ACL table item to a hardware chip, where a matching field of the ACL table item is the FLOW characteristic information, and an action item is an IOAM header including the FLOW ID added to the message. Therefore, in the above process, the IOAM device does not need to request the controller to acquire the FLOW ID, but can generate the ACL entry in its own CPU, and the generation speed is high. Compared with the prior art, the time for sending the quintuple information to the controller and issuing the FLOW ID by the controller is saved, the time for generating the FLOW ID by the IOAM device is shorter than the time for generating the FLOW ID by the controller for a plurality of IOAM devices, and the time consumption is reduced to a great extent. Further, the problem that the FLOW detection with short memory time cannot be carried out due to the fact that the time consumption for obtaining the FLOW ID is too long can be avoided.

In addition, if the FLOW IDs of the whole network are generated by the controller in a unified manner, when there are many FLOWs to be detected with the FLOW in the network and the FLOW changes rapidly, the FLOW IDs in the specification pool may be exhausted, and then a situation that a certain FLOW ID is repeatedly released and occupied may occur, so that different devices repeatedly use the same FLOW ID due to oscillation, and refresh confusion of FLOW detection data counted by the devices is caused. For example, the FLOW ID added to the IOAM header of the packet 1 by the head node 1 is 100, before the packet 1 is transmitted to the tail node, the head node 1 may release the FLOW ID 100, and the controller allocates the FLOW ID 100 to another FLOW received by the head node 2, so that the head node 2 may add the FLOW ID 100 to the IOAM header of the packet 2, and then the intermediate node may receive the packet 1 and the packet 2 in a short time interval, and refresh the statistical information corresponding to the FLOW ID 100 based on the packet 1 and the packet 2, respectively, and actually, the packet 1 and the packet 2 do not belong to the same FLOW, which causes the intermediate node to transmit an error in the FLOW detection data counted for each FLOW.

Because the FLOW ID in the embodiment of the present application is generated based on the device ID and the sub-FLOW ID, even though the sub-FLOW IDs generated by different devices may be the same, the FLOW IDs generated by different devices are not the same because the device IDs of different devices are different, which can avoid that different devices select the same FLOW ID for different streams, and avoid the problem of chaotic refresh of detection data with streams of device statistics.

It can be understood that the matching field of the ACL entry issued by the CPU to the hardware chip includes FLOW characteristic information, the action item is to add an IOAM header including a FLOW ID to the message, and after the hardware chip receives the message, if the message matches the FLOW characteristic information of the ACL entry, the hardware chip encapsulates the IOAM header including the FLOW ID for the message, and then the device on the forwarding path can perform FLOW following detection based on the IOAM header and record FLOW following detection data based on the FLOW ID.

In this embodiment of the application, before executing the process shown in fig. 5, the CPU of the IOAM device needs to generate a subflow ID pool, and the IOAM device may receive the device ID and the subflow ID specification sent by the controller. The CPU then stores the device ID and generates a sub-FLOW ID pool based on the sub-FLOW ID specification.

Where the sub-FLOW ID specification is used to represent the range of sub-FLOW ID pools allocated for IOAM devices. For example, if the subwow ID specification is 10, the range of the subwow ID pool generated by the CPU includes 1 to 10.

A process of selecting a sub-FLOW ID in an idle state from the sub-FLOW ID pool by the CPU according to the FLOW characteristic information of the first message will be described in detail below.

As shown in fig. 6, the CPU may maintain a sub-FLOW ID state machine, each sub-FLOW ID comprising three states, respectively a mapped state (which may be referred to as E1), a to-be-released state (which may be referred to as E2), and an idle state (which may be referred to as E3).

Wherein, E1: the mapping state refers to a mapping state of a quintuple and a sub FLOW ID, that is, if the sub FLOW ID is already allocated to a service FLOW, the sub FLOW ID is in a mapping state, and specifically, a software mapping relationship between the sub FLOW ID and the quintuple can be maintained by a state machine.

E2: the to-be-released state refers to a state of the sub-FLOW ID being switched to the to-be-released state after the FLOW corresponding to the sub-FLOW ID in the mapping state dies. That is, after the allocated sub FLOW ID is not used, there is a cooling period in which it is in a state to be released, and after the cooling period is finished, it is restored to an idle state.

E3: idle state, indicating that the sub FLOW ID may be selected.

Referring to fig. 6, the cpu may select a sub-FLOW ID in an idle state from the sub-FLOW ID pool according to the FLOW characteristic information of the first message.

In one embodiment, the CPU may randomly select a sub-FLOW ID in an idle state for the FLOW characteristic information from the sub-FLOW ID pool.

In an embodiment, the CPU may select the sub-FLOW ID in the idle state for the FLOW feature information according to a certain sequence, where the specific selection process is as follows:

starting from the specification of the sub-FLOW ID in the sub-FLOW ID pool, the sub-FLOW IDs in the idle state are searched in the order of the sub-FLOW IDs from small to large. If the FLOW ID in the idle state is not found at the end of the FLOW ID pool, the FLOW ID in the idle state is found from the beginning of the FLOW ID pool in the order from small to large. The found first FLOW ID in the idle state is selected.

The designated location is the location of the last selected sub-FLOW ID in the sub-FLOW ID pool.

As shown in fig. 7a, fig. 7a shows a software mapping relationship between each sub FLOW ID in the sub FLOW ID pool maintained by the state machine and the five-tuple, and optionally, the sub FLOW ID pool may be maintained in the form of a sub FLOW ID linked list, or the five-tuple of the selected sub FLOW ID may be maintained in the form of a five-tuple linked list.

The controller may select from the FLOW ID1 in selecting the FLOW ID for the quintuple, in fig. 7a, the FLOW ID1 has been assigned to the quintuple a, so the state of the FLOW ID1 is the mapped state (E1);

sub FLOW ID2 was once allocated to quintuple B, but the FLOW to which quintuple B belongs has not existed, sub FLOW ID2 is in a state to be released (E2);

the sub FLOW ID3 has been allocated to the quintuple C, so the state of the sub FLOW ID3 is the mapping state (E1);

the FLOW ID states following the sub FLOW ID3 are all idle states.

Referring to fig. 7a, if the specified location is the location of the sub-FLOW ID3, the CPU may search for the sub-FLOW ID in the idle state after the sub-FLOW ID3, and may search for the sub-FLOW ID4 to select the sub-FLOW ID4 for the FLOW characteristic information.

It is to be understood that, assuming that the FLOW characteristic information is quintuple D, after the FLOW ID4 is selected for quintuple B, the status of FLOW ID4 is updated to the mapping status (E1), i.e., the software mapping relationship between FLOW ID4 and quintuple D can be maintained by the state machine.

Subsequently, if the duration that the FLOW ID2 is in the to-be-released state exceeds the preset duration, i.e., the cooling period ends, the sub-FLOW ID2 is updated to the idle state (E3), and then fig. 7a changes to fig. 7b.

If the CPU of the IOAM device receives the message in another FLOW reported by the hardware chip again at this time, and obtains the FLOW characteristic information of the message, it may start to search for the sub-FLOW ID in the idle state from the sub-FLOW ID4, and since the sub-FLOW ID4 is already at the end of the sub-FLOW ID pool, it may start to search from the start of the sub-FLOW ID pool again, and then it may search for the sub-FLOW ID2 in the idle state, select the sub-FLOW ID2 for the FLOW characteristic information, and update the sub-FLOW ID2 to the mapping state.

In an embodiment of the application, if a subflow ID needs to be selected for the FLOW characteristics information, but there are no idle subflow IDs in the subflow ID pool, an over-specification alert may be issued to prompt the administrator to temporarily stop having selectable subflow IDs.

By adopting the method, the controller can search the sub-FLOW IDs in the idle state from the position of the sub-FLOW ID selected last time according to the sequence of the sub-FLOW IDs from small to large, and then the controller can search the tail of the sub-FLOW ID pool and perform overturning search, so that the situation that the same sub-FLOW ID is allocated to two different service FLOWs in a short time can be avoided, and the situation that the same sub-FLOW ID is repeatedly used by different service FLOWs in the same equipment in an oscillating manner is avoided.

As can be seen from the above embodiments, the status of the sub FLOW ID changes after the sub FLOW ID is selected according to the FLOW characteristic information.

Specifically, after the found first sub-FLOW ID in the idle state is selected, the selected sub-FLOW ID may be updated to the mapping state, and the state machine maintains the software mapping relationship between the selected sub-FLOW ID and the FLOW characteristic information.

If the aging time of the FLOW characteristic information is reached, the hardware chip still does not receive the message matched with the FLOW characteristic information, or the identification table entry is deleted along with the FLOW detection, updating the sub-FLOW ID selected according to the FLOW characteristic information into a state to be released; and after a preset time length, updating the sub-FLOW ID selected according to the FLOW characteristic information to an idle state.

If the aging time of the FLOW characteristic information is reached, the hardware chip still does not receive the message matched with the FLOW characteristic information, which indicates that the FLOW identified by the FLOW characteristic information does not exist, so that the sub FLOW ID selected according to the FLOW characteristic information can be updated to a state to be released. Since the sub FLOW ID of the to-be-released state is not selected, it is possible to avoid a case where the sub FLOW ID is used by being oscillated by different traffic in a short time.

If the FLOW following detection identification table entry is deleted, it indicates that the FLOW identified by the FLOW characteristic information does not need to be subjected to FLOW following detection, but a message before the service FLOW may still be transmitted along a forwarding path in the network, so that the sub-FLOW ID selected according to the FLOW characteristic information can be updated to a state to be released, the sub-FLOW ID can be prevented from being selected to other service FLOWs in a short time, the sub-FLOW ID can be prevented from being used by being oscillated by different service FLOWs in a short time, and the accuracy of a FLOW following detection result is prevented from being influenced by the refresh confusion of FLOW following detection data counted by the device.

In this embodiment of the present application, if the CPU of the IOAM device receives a delete instruction for the device ID issued by the controller, the device ID, the FLOW-following detection identification entry, the sub-FLOW ID pool, and the ACL entry are deleted. If the controller receives a delete instruction for the device ID, it indicates that the IOAM device does not need to perform stream following detection, or the IOAM device is not currently managed by the controller, the CPU of the IOAM may release the device ID and the selected sub FLOW ID, and the controller may further allocate the device ID to other IOAM devices, and may not cause different IOAM devices to use the same FLOW ID.

In addition, if the CPU of the IOAM device receives the updated device ID issued by the controller, the CPU updates the device ID stored in the CPU to the updated device ID, and then generates the FLOW ID using the updated device ID.

A method for a controller to pre-configure a device ID and sub FLOW ID pool for an IOAM device is described as follows, the method being applied to the controller, and the method including:

and configuring a device ID pool and a sub-FLOW ID pool for a CPU of the IOAM device, so that after the CPU receives a head message acquired based on the FLOW detection identification table item, selecting a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to FLOW characteristic information of the head message, generating a FLOW ID of a service FLOW to which the head message belongs based on the device ID and the selected sub-FLOW ID, and sending the FLOW ID to an ACL (access control list) table item of a hardware chip. The matching field of the ACL table entry is FLOW characteristic information, and the action item is an IOAM header which is added into the message and comprises the FLOW ID.

The controller configures a device ID pool and a sub FLOW ID pool for a CPU of the IOAM device, and may specifically be implemented as: issuing the device ID and the sub-FLOW ID specification to a CPU of the IOAM device such that the CPU stores the device ID and generates a sub-FLOW ID pool based on the FLOW ID specification, the sub-FLOW ID specification being for representing a range of sub-FLOW IDs allocated for the IOAM device.

The device ID and the sub-FLOW ID specification assigned to each device managed by the controller may be maintained in the controller, and the device ID and the sub-FLOW ID specification of each device may be manually configured in the controller or may be automatically assigned by the controller.

The controller may issue the device ID and sub-FLOW ID specifications to the device through NETCONF, as shown in fig. 8, and assuming that the controller currently manages the

devices

1 and 2, the device ID and sub-FLOW ID specifications may be assigned to the devices from its own device ID pool and FLOW ID specification pool. The device ID and the sub FLOW ID specification are issued to the device 1 and the device 2, respectively, for example, the device ID issued to the device 1 is X, and the sub FLOW ID specification is 30. The device ID issued for the device 1 is Y, and the sub FLOW ID specification is 20.

Since the device IDs allocated to different devices are different, FLOW IDs generated by different devices based on the device IDs will not be the same, so that different devices can be prevented from using the same FLOW ID.

In another embodiment of the present application, after the controller configures the device ID and the sub FLOW ID pool for the CPU of the IOAM device, the method further comprises:

when the communication with the IOAM device is disconnected and the communication is resumed again, the device ID stored by the CPU of the IOAM device is acquired. And if the device ID maintained by the controller for the IOAM device is inconsistent with the device ID acquired from the IOAM device, issuing the device ID maintained for the IOAM device to the CPU of the IOAM device, so that the CPU of the IOAM device updates the device ID to the device ID received this time.

In this embodiment of the application, if the controller is disconnected from the IOAM device, that is, the communication with the IOAM device is temporarily disconnected, the IOAM device may maintain the assigned device ID by itself. Because the device ID allocated to the IOAM device may be modified by an administrator by mistake during the period when the controller is disconnected from the IOAM device, after the communication between the controller and the IOAM device is restored again, the controller may perform an alignment operation on the device ID maintained by itself for the IOAM device and the device ID currently used by the IOAM device, and if the device IDs maintained by the controller and the IOAM device are different, the device ID maintained by the controller is taken as the standard to prevent the controller from allocating the same device ID to other IOAM devices, so as to prevent different IOAM devices from using the same FLOW ID.

The following describes a flow identifier obtaining method provided in this embodiment with reference to a specific example, where the IOAM device in this embodiment may be a router, a switch, a virtual switch, or a firewall, and the IOAM device is taken as a router, a flow-following detection identification table entry is a quadruple rule, and flow characteristic information is a quintuple, and the switch includes a device CPU platform and a device driver, and the device driver may implement the method steps executed by a hardware chip in the above embodiment. As shown in fig. 9, the method includes:

step 1, after acquiring a quadruplet of a service flow which needs to be detected along with the flow, a controller issues a quadruplet rule to an equipment CPU platform of the IOAM equipment, and the equipment CPU platform issues the quadruplet rule to an equipment driver.

And 2, the equipment driver receives the first message matched with the four-tuple rule and reports the first message to the CPU platform of the equipment.

And 3, extracting the quintuple of the first message by the CPU platform of the equipment, generating the FLOW ID for the quintuple, and issuing the FLOW ID to the equipment driver.

Wherein the FLOW ID consists of a device ID and a sub-FLOW ID.

And 4, the device driver receives the message matched with the quintuple and inserts an IOAM header carrying the FLOW ID into the message.

The subsequent device driver can count in the incoming direction according to the detection method along with the flow, can analyze the header of the message in the outgoing direction, counts in the statistics mode, and sends the message carrying the IOAM header to other devices.

Based on the same inventive concept, an embodiment of the present application further provides a flow identifier obtaining apparatus, which is applied to a CPU of an IOAM device, and as shown in fig. 10, the apparatus includes:

a receiving module 1001, configured to receive a header message obtained based on an identification table entry detected along with a flow;

a selecting module 1002, configured to select a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to FLOW characteristic information of a first packet;

a generating module 1003, configured to generate a FLOW ID of a service FLOW to which the header message belongs based on the device ID and the selected sub-FLOW ID;

the issuing module 1004 is configured to issue an ACL entry to the hardware chip, where a matching field of the ACL entry is FLOW characteristic information, and an action entry is an IOAM header including a FLOW ID added to the message.

Optionally, the selecting module 1002 is specifically configured to:

starting from the step of designating the sub-FLOW ID in the sub-FLOW ID pool, searching the sub-FLOW ID in an idle state according to the sequence from small to large of the sub-FLOW ID, and designating the sub-FLOW ID as the position of the sub-FLOW ID which is selected last time in the sub-FLOW ID pool;

if the sub-FLOW ID in the idle state is not found at the end of the sub-FLOW ID pool, the sub-FLOW ID in the idle state is found from the beginning of the sub-FLOW ID pool according to the sequence of the sub-FLOW IDs from small to large;

the found first FLOW ID in the idle state is selected.

Optionally, the apparatus further comprises a first updating module:

a first update module to:

updating the selected sub-FLOW ID into a mapping state, and maintaining a software mapping relation between the selected sub-FLOW ID and the FLOW characteristic information through a state machine;

if the aging time of the FLOW characteristic information is reached, the hardware chip still does not receive the message matched with the FLOW characteristic information, or the identification table entry is deleted along with the FLOW detection, updating the sub-FLOW ID selected according to the FLOW characteristic information into a state to be released;

after a preset time period, the sub FLOW ID selected according to the FLOW characteristic information is updated to an idle state.

Optionally, the apparatus further comprises:

and a deleting module, configured to delete the device ID, the FLOW-following detection table entry, the sub-FLOW ID pool, and the ACL table entry if the receiving module 1001 receives a delete instruction for the device ID issued by the controller.

Optionally, the apparatus further comprises:

a second updating module, configured to update the device ID stored in the receiving module 1001 to the updated device ID if the receiving module receives the updated device ID sent by the controller.

The embodiment of the present application further provides an electronic device, as shown in fig. 11, including a processor 1101, a communication interface 1102, a memory 1103 and a communication bus 1104, where the processor 1101, the communication interface 1102 and the memory 1103 complete communication with each other through the communication bus 1104,

a memory 1103 for storing a computer program;

the processor 1101 is configured to implement the steps of any of the stream identification methods in the embodiments described above when executing the program stored in the memory 1103.

The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this is not intended to represent only one bus or type of bus.

The communication interface is used for communication between the electronic equipment and other equipment.

The Memory may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Alternatively, the memory may be at least one memory device located remotely from the processor.

The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

In still another embodiment provided by the present application, there is further provided a computer-readable storage medium having a computer program stored therein, where the computer program is executed by a processor to implement the steps of any of the above-mentioned flow identification acquisition methods.

In yet another embodiment provided by the present application, there is also provided a computer program product containing instructions that, when executed on a computer, cause the computer to execute any of the flow identification acquisition methods in the above embodiments.

In the above embodiments, all or part of the implementation may be realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The procedures or functions described in accordance with the embodiments of the application are all or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

It should be noted that, in this document, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising one of 8230; \8230;" 8230; "does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points.

The above description is only for the preferred embodiment of the present application and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A method for acquiring a stream identifier, the method being applied to a CPU of an IOAM device, the method comprising:

receiving a head message obtained based on a random flow detection identification table item;

2. The method of claim 1, wherein the selecting a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to the FLOW characteristic information of the first packet comprises:

starting from the specified sub-FLOW ID in the sub-FLOW ID pool, searching the sub-FLOW IDs in an idle state according to the descending order of the sub-FLOW IDs, wherein the specified sub-FLOW ID is the position of the sub-FLOW ID which is selected last time in the sub-FLOW ID pool;

if the FLOW ID in the idle state is not found at the end of the FLOW ID pool, searching the FLOW ID in the idle state from the beginning of the FLOW ID pool according to the sequence of the FLOW IDs from small to large;

the found first FLOW ID in the idle state is selected.

3. The method of claim 2, wherein after selecting the found first sub FLOW ID in idle state, the method further comprises:

if the aging time of the FLOW characteristic information is reached, the hardware chip still does not receive the message matched with the FLOW characteristic information, or the FLOW detection-associated identification table entry is deleted, updating the sub-FLOW ID selected according to the FLOW characteristic information into a to-be-released state;

updating the sub-FLOW ID selected according to the FLOW characteristic information to an idle state after a preset time period.

4. The method according to any one of claims 1-3, further comprising:

and if a deletion instruction of the equipment ID issued by a controller is received, deleting the equipment ID, the FLOW detection table entry, the sub-FLOW ID pool and the ACL table entry.

5. The method according to any one of claims 1-3, further comprising:

and if the updated equipment ID issued by the controller is received, updating the equipment ID stored by the controller into the updated equipment ID.

6. A flow identification acquisition apparatus applied to a CPU of an IOAM device, the apparatus comprising:

a selection module, configured to select a sub-FLOW ID in an idle state from a preset sub-FLOW ID pool according to the FLOW characteristic information of the first packet;

a generating module, configured to generate a FLOW ID of a traffic FLOW to which the header message belongs based on the device ID and the selected sub-FLOW ID;

7. The apparatus according to claim 6, wherein the selection module is specifically configured to:

starting from the sub-FLOW ID pool, designating the sub-FLOW ID, and searching the sub-FLOW ID in an idle state according to the sequence of the sub-FLOW IDs from small to large, wherein the designated sub-FLOW ID is the position of the sub-FLOW ID which is selected last time in the sub-FLOW ID pool;

if the sub-FLOW ID in the idle state is not found at the end of the sub-FLOW ID pool, searching the sub-FLOW ID in the idle state from the beginning of the sub-FLOW ID pool according to the sequence of the sub-FLOW IDs from small to large;

the found first FLOW ID in the idle state is selected.

8. The apparatus of claim 7, further comprising:

a first updating module, configured to update the selected sub-FLOW ID to a mapping state, and maintain a software mapping relationship between the selected sub-FLOW ID and the FLOW characteristic information through a state machine; if the aging time of the FLOW characteristic information is up, the hardware chip still does not receive the message matched with the FLOW characteristic information, or the FLOW-following detection identification table entry is deleted, updating the sub-FLOW ID selected according to the FLOW characteristic information into a state to be released; and after a preset time length, updating the sub-FLOW ID selected according to the FLOW characteristic information to an idle state.

9. The apparatus of any one of claims 6-8, further comprising:

and the deleting module is used for deleting the equipment ID, the FLOW detection table entry, the sub-FLOW ID pool and the ACL table entry if the receiving module receives a deleting instruction of the equipment ID issued by a controller.

10. The apparatus according to any one of claims 6-8, further comprising:

and the second updating module is used for updating the self-stored equipment ID into the updated equipment ID if the receiving module receives the updated equipment ID issued by the controller.

11. An electronic device is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor and the communication interface are used for realizing mutual communication by the memory through the communication bus;

a memory for storing a computer program;

a processor for implementing the method steps of any one of claims 1 to 5 when executing a program stored in the memory.

12. A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, which computer program, when being executed by a processor, carries out the method steps of any one of the claims 1-5.