阅读说明：本技术 随流信息遥测能力的确认方法和设备 (Method and device for confirming telemetry capability of stream information ) 是由 季叶一 辛方 李瑞瑕 徐峰 于 2019-10-15 设计创作，主要内容包括：一种随流信息测量iFIT能力的确认方法和设备,所述方法包括：第一网络设备向第二网络设备或网络管理设备发送请求报文,所述请求报文用于请求确认所述第二网络设备是否具备iFIT能力；所述第一网络设备接收所述第二网络设备或所述网络管理设备发送的确认报文,所述确认报文包括确认是否具有iFIT能力的确认信息。所述方法能够保证只在所述第二网络设备具备iFIT能力时,向所述第二网络设备发送包括iFIT信息的数据报文,从而解决因网络设备不具备iFIT能力而导致的丢包问题。(A method and apparatus for acknowledgement of measuring ift capabilities with flow information, the method comprising: the method comprises the steps that a first network device sends a request message to a second network device or a network management device, wherein the request message is used for requesting to confirm whether the second network device has the iFIT capability or not; and the first network equipment receives a confirmation message sent by the second network equipment or the network management equipment, wherein the confirmation message comprises confirmation information for confirming whether the iFIT capability exists. The method can ensure that the data message including the iFIT information is sent to the second network equipment only when the second network equipment has the iFIT capability, so that the problem of packet loss caused by the fact that the network equipment does not have the iFIT capability is solved.)

1. A method for confirming the ability to telemeter ift with flow information, the method comprising:

and the first network equipment receives a confirmation message, wherein the confirmation message comprises confirmation information of whether the second network equipment has the iFIT capability.

2. The method of claim 1, further comprising:

the first network equipment sends a request message, wherein the request message is used for requesting and confirming whether the second network equipment has the iFIT capability;

the receiving, by the first network device, the acknowledgment packet includes: and the first network equipment receives the confirmation message responding to the request message.

3. The method of claim 2, wherein sending the request message by the first network device comprises: the first network equipment sends the request message to the second network equipment; the receiving, by the first network device, the acknowledgement packet for responding to the request packet includes: and the first network equipment receives the confirmation message from the second network equipment.

4. The method according to claim 2 or 3, wherein the request message is an Internet Control Message Protocol (ICMP) message, the request message includes request information for requesting confirmation of the iFIT capability of the second network device, the request information is carried in a type and a code field of the request message, the confirmation message is an ICMP message, and the confirmation information in the confirmation message is carried in a type and a code field of the confirmation message.

5. The method of claim 2, wherein sending the request message by the first network device comprises: the first network equipment sends the request message to network management equipment; the receiving, by the first network device, the acknowledgement packet for responding to the request packet includes: and the first network equipment receives the confirmation message from the network management equipment.

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

and responding to the fact that the second network equipment has the iFIT capability, and the first network equipment sends the data message comprising the iFIT information to the second network equipment.

7. The method according to any one of claims 1-6, further comprising:

and in response to that the second network device has an iFIT capability and that the proportion of the network device having the iFIT capability on the path from the first network device to the second network device is greater than a preset value, the first network device sends a data packet including the iFIT information to the second network device.

8. A method of confirming ability to telemeter ift with flow information, the method comprising:

the method comprises the steps that a second network device receives a request message of a first network device, wherein the request message is used for requesting to confirm the iFIT capability of the second network device;

and the second network equipment sends a confirmation message, wherein the confirmation message comprises confirmation information of whether the second network equipment has the iFIT capability.

9. A method for confirming the ability to telemeter ift with flow information, the method comprising:

the network management equipment generates a confirmation message, wherein the confirmation message comprises confirmation information of whether the second network equipment has the iFIT capability;

and the network management equipment sends the confirmation message to the first network equipment.

10. The method of claim 9, wherein the method comprises:

the network management equipment receives a request message of the first network equipment, wherein the request message is used for requesting to confirm the iFIT capability of the second network equipment;

the network management device sending the confirmation message to a first network device includes: and the network management equipment sends the confirmation message responding to the request message to the first network equipment.

11. A first network device, wherein the first network device comprises:

and the receiving unit is used for receiving a confirmation message, wherein the confirmation message comprises confirmation information of whether the second network equipment has the iFIT capability.

12. The first network device of claim 11, wherein the first network device further comprises:

a sending unit, configured to send a request packet, where the request packet is used to request to confirm whether the second network device has an ift capability;

the receiving unit receives the confirmation message, including: and receiving the confirmation message responding to the request message.

13. The first network device of claim 11 or 12, wherein the first network device further comprises:

and a response unit, configured to send, in response to that the second network device has an ift capability, a data packet including the ift information to the second network device.

14. A second network device, the second network device comprising:

a receiving unit, configured to receive a request packet of a first network device, where the request packet is used to request to confirm an ift capability of a second network device;

a sending unit, configured to send a confirmation message, where the confirmation message includes confirmation information of whether the second network device has an ift capability.

15. A network management device, characterized in that the network management device comprises:

a generating unit, configured to generate a confirmation message, where the confirmation message includes confirmation information of whether the second network device has the ift capability;

and the sending unit is used for sending the confirmation message to the first network equipment.

16. The network management device according to claim 15, wherein the network management device further comprises:

a receiving unit, configured to receive a request packet of the first network device, where the request packet is used to request to confirm an ift capability of the second network device;

the sending unit sends the acknowledgement packet to the first network device, including: and sending the confirmation message of the request message to the first network equipment.

17. A network device, characterized in that the device comprises a processor and a memory, the memory being adapted to store a computer program, the processor being adapted to call the computer program stored in the memory to perform the method according to any of claims 1-10.

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method and an apparatus for confirming an ift capability of a network device in an in-situ Flow Information Telemetry (ift) service scenario.

Background

By carrying out feature marking on actual service flow and based on the field of the feature marking, the iFIT technology can provide end-to-end and hop-by-hop telemetering capacity of the actual service flow and sense network performance indexes in real time. The iFIT technology is 'telemetering with stream information' submitted to Internet Engineering Task Force (IETF)The Framework (In-situ Flow Information Framework) personal draft, the Internet link of the draft can be seen Inhttps://tools.ietf.org/html/draft-song-opsawg- ifit-framework-00. The network based on the ift technology includes three types of network nodes, specifically, a head node (english: head node), a tail node (english: end node), and a hop-by-hop path node (english: path node). To simplify configuration and ease deployment, the ift-enabled static instance is currently configured only at the head node, i.e., the head node is guaranteed to be ift-capable, but the tail node is not guaranteed to support the ift. Thus, for the tail node with the iFIT capability, the iFIT header encapsulated by the head node can be automatically identified and stripped after the data message is received. However, if the tail node does not have the ift capability, the tail node cannot strip the ift header, thereby causing the data packet to be regarded as a false packet and discarded because the data packet cannot be identified. The situation that the tail node does not have the ift capability often occurs in the scenario of the butt joint of the new and old devices or the device butt joint between different manufacturers.

Disclosure of Invention

The application provides a method and equipment for confirming the iFIT capability of network equipment, which are used for solving the problem of packet loss caused by the fact that the network equipment does not have the iFIT capability and improving the robustness of network operation.

In a first aspect, the present application provides a method for confirming an ift capability, where the method includes that a first network device receives a confirmation packet, and the confirmation packet includes confirmation information of whether a second network device has the ift capability.

The first network device such as the head node receives a confirmation message for confirming whether the second network device such as the path node or the tail node has the iFIT capability or not, so that the first network device can send a data message including the iFIT information to the second network device when confirming that the second network device has the iFIT capability, and the problem of packet loss caused by the fact that the network device cannot strip the iFIT information because the network device does not have the iFIT capability is solved.

In an optional design, the method includes sending, by a first network device, a request packet, where the request packet is used to request to confirm whether a second network device has an ift capability; the first network device receiving the confirmation message includes the first network device receiving the confirmation message in response to the request message.

In an optional design, the sending of the request packet by the first network device includes sending, by the first network device, the request packet to the second network device; the receiving, by the first network device, the acknowledgement packet for responding to the request packet includes: and the first network equipment receives the confirmation message from the second network equipment.

In an optional design, the request message is an internet control message protocol ICMP message, where the request message includes request information for requesting confirmation of an ift capability of the second network device, the request information is carried in a type and a code field of the request message, the confirmation message is an ICMP message, and the confirmation information in the confirmation message is carried in a type and a code field of the confirmation message.

By expanding ICMP message, ICMP message mechanism can be flexibly applied, iFIT capability of network equipment can be rapidly confirmed, and robustness and efficiency of network operation are improved.

In an optional design, the sending, by the first network device, the request packet includes sending, by the first network device, the request packet to a network management device; the receiving, by the first network device, the acknowledgement packet for responding to the request packet includes: and the first network equipment receives the confirmation message from the network management equipment.

By utilizing the management and control capability of the network management equipment on the network equipment, whether the network equipment has the iFIT capability or not can be flexibly acquired and confirmed, and the robustness and efficiency of network operation are improved.

In an optional design, in response to the second network device having an ift capability, the first network device sends a data packet including ift information to the second network device.

In an optional design, in response to that the second network device has an ift capability and that the proportion of the network device having the ift capability on the path from the first network device to the second network device is greater than a preset value, the first network device sends a data packet including the ift information to the second network device.

Before sending a data message including iFIT information, a first network device firstly counts and confirms the occupation ratio of nodes with iFIT capability supported on a data message transmission path, and sends the data message when the occupation ratio is larger than a preset value, so that the necessity evaluation of iFIT telemetering is realized, and the accuracy of the iFIT telemetering result is ensured to a certain extent.

In a second aspect, the present application provides a method for confirming an ift capability, where the method includes that a second network device receives a request packet of a first network device, where the request packet is used to request to confirm the ift capability of the second network device; and the second network equipment sends a confirmation message, wherein the confirmation message comprises confirmation information of whether the second network equipment has the iFIT capability.

The first network device receives a confirmation message from a second network device such as a path node or a tail node, and can send a data message including the iFIT information to the second network device when the second network device is confirmed to have the iFIT capability, so that the problem of packet loss caused by the fact that the iFIT information cannot be stripped because the network device does not have the iFIT capability is avoided.

In one possible design, the request message is an internet control message protocol ICMP message, where the request message includes request information for requesting confirmation of an ift capability of the second network device, the request information is carried in a type and a code field of the request message, the confirmation message is an ICMP message, and the confirmation information in the confirmation message is carried in a type and a code field of the confirmation message.

In a third aspect, the present application provides a method for confirming an ift capability, where the method includes that a network management device generates a confirmation message, where the confirmation message includes confirmation information of whether a second network device has the ift capability; and the network management equipment sends the confirmation message to the first network equipment.

The network management device can actively send the collected iFIT capability of the network node in the iFIT network to the first network device, and the first network device is not required to send a request message first, so that the communication flow is simplified and the communication efficiency is improved while packet loss is avoided.

In one possible design, the method includes the network management device receiving a request packet of the first network device, where the request packet is used to request to confirm an ift capability of a second network device; and the network management equipment sends the confirmation message to first network equipment, wherein the network management equipment sends the confirmation message of the request message to the first network equipment.

In a possible design, the acknowledgement packet further includes a device identifier of the second network device, where the device identifier is used to identify a corresponding relationship between the acknowledgement information and the second network device.

The network management device can notify the first network device of the second network device to which the acknowledgement information in the acknowledgement message belongs by carrying the device identifier in the acknowledgement message, so that the first network device can obtain the ift capability of each network device on the data message transmission path.

In a fourth aspect, the present application provides a first network device, where the device includes a receiving unit, configured to receive a confirmation packet, where the confirmation packet includes confirmation information of whether a second network device has an ift capability.

In a possible design, the first network device further includes a sending unit, configured to send a request packet, where the request packet is used to request to confirm whether the second network device has an ift capability; the receiving unit receives the confirmation message, including receiving the confirmation message of the request message.

In a possible design, the sending unit sending the request message includes the first network device sending the request message to the second network device; the receiving unit receiving the acknowledgement message to the request message includes the first network device receiving the acknowledgement message from the second network device.

In one possible design, the request message is an internet control message protocol ICMP message, where the request message includes request information for requesting confirmation of an ift capability of the second network device, the request information is carried in a type and a code field of the request message, the confirmation message is an ICMP message, and the confirmation information in the confirmation message is carried in a type and a code field of the confirmation message.

In a possible design, the sending unit sending the request message includes the first network device sending the request message to a network management device; the receiving unit receiving the confirmation message of the request message includes the first network device receiving the confirmation message from the network management device.

In a possible design, the first network device further includes a response unit, configured to send, in response to that the second network device has an ift capability, a data packet including ift information to the second network device.

In a possible design, the response unit further includes that, in response to that the second network device has an ift capability, and that a proportion of network devices having the ift capability on a path from the first network device to the second network device is greater than a preset value, the first network device sends a data packet including the ift information to the second network device.

In a fifth aspect, the present application provides a second network device, where the second network device includes a receiving unit, configured to receive a request packet of a first network device, where the request packet is used to request to confirm an ift capability of the second network device; a sending unit, configured to send a confirmation message, where the confirmation message includes confirmation information of whether the second network device has an ift capability.

In one possible design, the request message is an internet control message protocol ICMP message, where the request message includes request information for requesting confirmation of an ift capability of the second network device, the request information is carried in a type and a code field of the request message, the confirmation message is an ICMP message, and the confirmation information in the confirmation message is carried in a type and a code field of the confirmation message.

In a sixth aspect, the present application provides a network management device, where the network management device includes a generating unit, configured to generate a confirmation message, where the confirmation message includes confirmation information of whether a second network device has an ift capability; and the sending unit is used for sending the confirmation message to the first network equipment.

In a possible design, the network management device further includes a receiving unit, configured to receive a request packet of the first network device, where the request packet is used to request to confirm an ift capability of the second network device; the sending unit sends the confirmation message to the first network device, including sending the confirmation message for the request message to the first network device.

In a possible design, the acknowledgement packet further includes a device identifier of the second network device, where the device identifier is used to identify a corresponding relationship between the acknowledgement information and the second network device.

In a seventh aspect, an embodiment of the present application provides a network device, where the device includes a processor and a memory, where the memory is used to store a computer program, and the processor is used to call the computer program stored in the memory to execute the corresponding method described in the foregoing first aspect, second aspect, or third aspect.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below.

Fig. 1 is a schematic diagram of an ift network structure provided in an embodiment of the present application;

fig. 2 is a schematic diagram of an ICMP message structure provided in the embodiment of the present application;

fig. 3 is a schematic flowchart of an ift capability confirmation method according to an embodiment of the present application;

fig. 4 is a schematic flowchart of an ift capability confirmation method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of an ift capability confirmation method according to an embodiment of the present application;

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

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings. The network architecture and the service scenario described in the embodiment of the present application are for more clearly illustrating the technical solution of the embodiment of the present application, and do not form a limitation on the technical solution provided in the embodiment of the present application, and as a person of ordinary skill in the art knows that along with the evolution of the network architecture and the appearance of a new service scenario, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

The ift technology for measuring information along with flow may perform a feature marking on a data packet flowing through a network node by using a special ift header, where the feature marking may also be referred to as dyeing. The iFIT header may be, for example, an extension header of a multiprotocol Label Switching (MPLS) Protocol or the like. Networks that support the ift technology typically include three types of network nodes, which are a head node 202, hop-by-hop path nodes 204, 206, and 208, and a tail node 210, respectively, taking the network structure shown in fig. 1 as an example. For a network node with an ift capability, when the data packet flows through the network node, the network node can measure statistical data such as packet loss and time delay for a feature field of the data packet based on corresponding field information in an ift header, and send the statistical data obtained by measurement to the network management device 212, so that the network management device 212 further calculates the network time delay, the packet loss condition, the restoration path, and the like.

When the iFIT technology is used for carrying out end-to-end remote measurement on data messages in a network, a head node firstly determines whether the data messages comprising the data flow are in the data flow needing remote measurement. For example, the characteristics of the data stream that require telemetry may be added in an Access Control List (ACL). And if the data message hits the item in the ACL and the item indicates that the iFIT telemetry needs to be carried out, executing corresponding operation on the data message. Still taking fig. 1 as an example, when a data packet hits the ACL, the head node 202 encapsulates the ift information for the data packet, and then sends the data packet encapsulated with the ift information. The data packet flows through each path node 204, 206, and 208 in turn, and reaches tail node 210. When the data packet is sent to tail node 210, tail node 210 may strip the ift information of the data packet to forward the original data packet. However, in an actual application scenario, tail node 210 may not have an ift capability, and thus cannot smoothly strip ift information, which results in the data packet being discarded due to being unrecognizable.

In order to solve the above possible technical problem, an embodiment of the present application provides a method 300 for confirming an ift capability of a network node. By executing the method 300, the head node can determine whether the tail node has the ift capability before performing ift information encapsulation, and when the tail node does not have the ift capability, the head node does not encapsulate the ift header, and at this time, although ift telemetry cannot be smoothly performed, packet loss of the tail node is not caused.

S305 a first network device sends a request packet to a second network device, where the request packet includes request information for requesting to confirm whether the second network device has an ift capability.

The format of the request Message will be described below by taking an implementation based on Internet Control Message Protocol (ICMP) as an example. Fig. 2 illustrates a structure of an ICMP message including an ICMP header, where the ICMP header includes Type (english: Type), Code (english: Code), and Checksum (english: Checksum) subfields, where the Type field is used to describe the role and format of the ICMP message, the Code field is used to describe the Type of the ICMP message, the Checksum field is used to ensure the integrity of data reception, and the Type field and the Code field may cooperate to identify the role and Type of the ICMP message.

The first network device serving as a request initiator may send an ICMP ift capability request message to the second network device serving as a request receiver, where the ICMP ift capability request message includes request information for requesting an ift capability, and is used to identify the request message for confirming the ift capability. For example, considering that Type 15 and Code 0 are abandoned as the initially defined information request messages, Type 15 and Code 0 may be redefined as the ICMP ift capability request messages. The Type and Code fields in the request message and their respective specified values, Type 15 and Code 0, are used as the request information. The value of other reserved types in the ICMP message may also be used as the corresponding value of the ift capability request information, and a value of a code used in cooperation with the value is defined to identify that the request message is a message requesting the ift capability. And the first network equipment sends the ICMP iFIT capability request message to the second network equipment.

S310 the second network device receives the request packet sent by the first network device, and sends a corresponding response packet to the first network device based on the request packet, where the response packet includes response information for determining whether the second network device has an ift capability.

Taking an implementation manner based on the ICMP as an example, the second network device receives the ICMP ift capability request message, and confirms that the currently received request message is used for requesting to acquire a local ift capability condition based on a value of ift capability request information carried in the request message. And the second network equipment sends a corresponding ICMP iFIT capability response message to the first network equipment, wherein the response message is used for responding whether the second network equipment has the iFIT capability. The ICMP ift capability response packet includes ift capability response information, where the response information is used to identify the ift capability of the second network device. As a specific implementation manner, considering that Type ═ 16 and Code ═ 0 are abandoned as the initially defined information response messages and Type ═ 16 and Code ═ 1 are the initial reserved values, Type ═ 16, Code ═ 0 or Code ═ 1 can be redefined as the ICMP ift capability response messages, and the Type and Code field in the request message and their respective specified values, Type ═ 16, Code ═ 0 or Code ═ 1, are used as the ift capability response messages, where Code ═ 0 indicates that the second network device has ift capability and Code ═ 1 indicates that the second network device has no ift capability. As another specific implementation manner, values of other reserved types in the ICMP message may also be used as corresponding values of the ift capability response information, and a value of a code used in cooperation with the value is defined, so as to identify that the response message is a message for responding the ift capability.

In general, the second network device needs to support at least the ICMP ift capability request and the response rule, and can return the correct ICMP ift capability response packet. For example, the second network device supports the rule and has an ift capability, and at this time, an ift capability response packet capable of identifying an information value of the ift capability may be returned, where the information value is, for example, Type ═ 16 and Code ═ 0. For another example, in some cases, such as when the second network device is waiting for the ift configuration and deployment, the second network device itself does not currently have the ift capability, but can support and understand the rule, at this time, an ift capability response packet that can identify an information value that it does not have the ift capability may be returned, for example, the information value is Type-16 and Code-1. And the second network equipment sends the generated ICMP iFIT capability response message to the first network equipment. And the first network equipment receives the ICMP iFIT capability response message.

S315 the first network device receives the response packet, and determines whether the second network device has an ift capability based on the response information in the response packet.

After receiving the ICMP ift capability response message, the first network device determines whether the second network device has an ift capability based on the value of the ift capability response information in the response message. For example, in an implementation using a Type and a Code field as the ift capability response information, the first network device confirms that the second network device is ift capable based on a Type of 16 and a Code of 0, or confirms that the second network device is not ift capable based on a Type of 16 and a Code of 1.

In some cases, the second network device may not support the ICMP ift capability request and response rule, for example, the second network device may not successfully return the ICMP ift capability response packet, but discard or do not respond after receiving the ICMP ift capability request packet sent by the first network device, or respond, but the response packet is an error packet, if the second network device does not support the ift deployment at all, or only supports the ift deployment of the old version, but does not know the situations of the newly defined ICMP ift capability request and response rule, etc. Therefore, in some possible embodiments, when the first network device finds that the second network device does not respond or a response packet is an error packet, it determines that the second network device does not have the ift capability.

In some embodiments, the request packet sent by the first network device to the second network device and the response packet returned by the second network device to the first network device may also be implemented based on other Protocol types, for example, a packet of a User Datagram Protocol (UDP) or a Transmission Control Protocol (TCP) Protocol family. The specific setting mode of the ift capability request information for identifying that the request packet is an ift capability request packet and the ift capability response information for identifying that the response packet is an ift capability response packet may be specifically determined according to the definition of a protocol packet.

In one possible implementation, the method 300 further includes:

s320, the first network device confirms that the second network device has the iFIT capability, and sends the data message for encapsulating the iFIT information to the second network device.

And when the first network equipment confirms that the second network equipment has the iFIT capability, the first network equipment sends the data message which needs to be sent and comprises the iFIT information to the second network equipment, and when the second network equipment does not have the iFIT capability, the first network equipment does not send the data message, so that the situation that the data message is discarded because the data message is not identified after the iFIT header is encapsulated is avoided.

In some embodiments, the first network device is a head node in an ift network and the second network device is a tail node in the ift network, such as head node 202 and tail node 210 shown in fig. 1. By executing the method 200, it can be ensured that the data packet which includes the ift information and is sent out at the head node can be received after the ift information is successfully stripped at the tail node, and cannot be discarded at the tail node. In other embodiments, the second network device may also be a path node in the ift network, such as path nodes 204, 206, and 208 shown in fig. 1, so that the query of the path node ift capability is implemented by executing the method 200. In some cases, the query for the capability of the path node ift may be directed to one or more specified path nodes, and at this time, in a manner similar to the query for the capability of the tail node ift, for example, an IP address of a corresponding node may be specified in an outer layer message carrying an ICMP ift capability request message, so as to send the ICMP ift capability request message to a specified path node, and the like. In other cases, the query on the path node ift capability may traverse all path nodes and tail nodes hop by hop, for this purpose, for example, a traceroute command may be multiplexed, where the traceroute command may be used to traverse all path nodes and tail nodes on a data packet transmission path in the existing definition, each path node may return an ICMP response packet based on the traceroute command, and all path nodes and tail nodes that receive the command may return their own ift capability conditions and the like by multiplexing and redefining the command; or, the head node may execute a traceroute command to acquire all path nodes and tail nodes traversed on the data packet transmission path, and then send an ift capability request packet to each of the all path nodes and the tail nodes, respectively, to acquire a response packet of each corresponding node to determine the ift capability condition thereof, and the like.

As can be seen from fig. 1, in an actual ift Network application scenario, each Network node through which a data packet flows may send its Configuration information, ift telemetry information, and the like to the Network management device 212, for example, through a Network Configuration Protocol (NETCONF) based on eXtensible Markup Language (XML). Another embodiment of the present application further provides a method 400 for implementing an ift capability confirmation based on a network management device, where the method 400 collects an ift capability of a network node in an ift network by using the network management device, and provides ift capability information of the corresponding network node to a first network device such as a head node as needed. The method 400 specifically includes the following.

S405, the first network device sends a request message to the network management device, wherein the request message is used for confirming whether the second network device has the iFIT capability, the request message comprises iFIT capability request information, and the iFIT capability request information is used for identifying that the request message is used for confirming the iFIT capability.

The following describes the format of the request message by taking an implementation mode based on the NETCONF protocol as an example. The NETCONF protocol provides a set of mechanisms for managing network equipment, and a user can use the mechanisms to acquire configuration information and state information of managed network equipment through the network management equipment. In this embodiment, the first network device serving as a request initiator may send an ift capability request packet based on a NETCONF protocol to the network management device serving as a request receiver, where the ift capability request packet includes ift capability request information, and is used to identify the request packet to confirm an ift capability. As a specific implementation manner, for example, the first network device may be the head node 202 in fig. 1, and the network management device may be, for example, the network management device 212 in fig. 1. Head node 202 sends a request packet to network management device 212 requesting confirmation of whether tail node 210 is ift capable. The request message includes an iFIT capability request message, which is used to identify that the request message is used to confirm the iFIT capability. The request packet may further include device identification information for identifying a request to confirm the ift capability for the specified second network device. In another possible embodiment, the device identification information allows specifying multiple network devices, i.e., requests to query the ift capabilities of the multiple network devices at the same time. However, for a case where the default second network device is a tail node or other specific node in the ift network, for example, for a case where ift telemetry is performed on a point-to-point unicast data packet, the device identification information may not be included, and the network management device may also directly return default ift capability confirmation information of the corresponding second network device based on the first network device that sends the request.

S410 the network management device receives the request packet sent by the first network device, and sends a response packet to the first network device based on the request packet, where the response packet includes response information for determining whether the second network device has an ift capability.

In a possible embodiment, after receiving the request packet sent by the head node 202, the network management device 212 matches and determines the tail node 210 corresponding to the head node 202 according to information such as the device identifier of the head node 202 and topology structure information of the network. Network management device 212 then queries and confirms whether tail node 210 is iFIT capable. In another possible embodiment, after receiving the request packet, the network management device 212 may also determine, through the device identification information in the request packet, the second network device for which the head node 202 requests to acquire the ift capability. In another possible embodiment, in a case that the device identification information specifies multiple specific network devices, the network management device 212 may also determine, after receiving the request packet, that the head node 202 requests to acquire the ift capabilities of the multiple specific network devices.

The network management device 212 obtains the ift capabilities of the second network device, or the plurality of specific network devices. The manner in which the network management device 212 acquires the corresponding ift capability may be, for example, acquiring based on default configuration information that is sent by each network device in advance, or acquiring based on a Product Adaptation File (PAF), and the like, where the PAF file is generally used to describe characteristics and capabilities supported by the network device.

After determining the ift capability of the corresponding network device, the network management device 212 encapsulates the ift capability condition as ift capability response information into an ift capability response message based on a NETCONF protocol, and sends the ift capability response message to the first network device. And the first network equipment receives the response message sent by the network management equipment.

S415 the first network device receives the response packet sent by the network management device, and determines whether the second network device has an ift capability based on the response information in the response packet.

After receiving the ift capability response packet sent by the network management device, the first network device may determine, based on a value of the ift capability response information in the response packet, whether the second network device or the plurality of specific network devices have the ift capability.

In one possible implementation, the method 400 further includes the following:

s420 the first network device determines that the second network device has an ift capability, and sends a data packet including ift information to the second network device.

In a possible embodiment, when it is determined that the second network device has the ift capability, the first network device sends a data packet including ift information to be sent to the second network device, and when it is determined that the second network device does not have the ift capability, the first network device does not send the data packet, so as to avoid discarding the data packet after carrying the ift information because the data packet is not identified. The second network device may be, for example, tail node 210 shown in fig. 1, or any of path nodes 204, 206, or 208.

As for the method 300 or 400, in other possible implementation manners, the first network device may obtain the ift capabilities of all path nodes and tail nodes on a path from the first network device to the second network device, where the obtaining manner may be that the ift capabilities are directly obtained by sending an ICMP protocol request packet or other type of communication request packet to the path nodes and tail nodes, or that the ift capabilities are indirectly obtained by sending a NETCONF protocol request packet or other type of management control request packet to a network management device. The first network device, such as the head node 202 in fig. 1, may determine a corresponding ift telemetry policy after obtaining the ift capabilities of all the path nodes and the tail nodes. For example, the head node 202 sends the data packet including the ift information to the corresponding tail node only when it is determined that all the path nodes and the tail nodes have the ift capability, so as to ensure that the data packet is not lost in the whole end-to-end transmission process. For another example, when it is determined that the tail node does not have the ift capability, the head node 202 may determine the last path node having the ift capability in the end-to-end transmission process, and notify the network management device 212 to configure the last path node as the network node from which the ift header is stripped, so as to ensure that the data packet can be successfully forwarded on the subsequent network node, and the data packet is not discarded because the ift information is not identified; alternatively, if the ift capability of the network node is acquired from the network management device 212, the network management device 212 may directly determine the last path node with the ift capability on the transmission path, and configure the path node as the node from which the ift information is stripped. For another example, in an actual application scenario, in an end-to-end transmission process of a data packet, some network nodes may not have an ift capability, but may serve as forwarding nodes to transparently transmit an ift telemetry packet carrying the data packet, so that although the data packet may not be discarded because the network nodes do not recognize the ift telemetry packet, if the network node proportion of only the transparently transmitted ift telemetry packet is large, accuracy and necessity of an ift telemetry result may be directly affected, therefore, the head node 202 may first count the percentage of path nodes having the ift capability in all path nodes flowing through the end-to-end transmission process of the data packet, and only when the percentage is greater than a certain threshold, the head node 202 determines to encapsulate an ift header for the data packet and transmit the data packet. The above statistics of the percentage of the path node with the ift capability may also be performed by the network management device 212, and notify, based on a statistical result, whether the header node 202 carries the ift information for the data packet.

In some embodiments, the first network device may also be a path node in an ift network, where the path node may request other path nodes in the network, such as an ift capability of a next-hop path node, and forward the data packet when it is determined that the next-hop path node has the ift capability, so as to ensure that the forwarding does not cause packet loss at the next-hop path node.

The embodiment of the present application further provides another method 500 for confirming an ift capability of a network node. The method 500 actively sends the collected ift capabilities of the network nodes in the ift network to a first network device such as a head node through a network management device, without sending an ift capability request message by the first network device, so as to simplify a communication flow and improve communication efficiency. The method 500 specifically includes the following.

S505 the network management device generates a confirmation message, where the confirmation message includes iFIT capability confirmation information, and the iFIT capability confirmation information is used to confirm whether the second network device has the iFIT capability.

In a possible embodiment, an implementation based on the NETCONF protocol is still used as an example. Unlike the method 400, the first network device does not need to initiate an ift capability request packet to the network management device actively, but the network management device matches and determines the head node 202 corresponding to the tail node 210 according to information such as the device identifier of the tail node 210 and topology structure information of the network after completing networking of two end nodes including the head node 202 and the tail node 210 and ift configuration management. The network management device 212 queries and confirms whether the tail node 210 has the ift capability, and then encapsulates ift capability confirmation information that feeds back the ift capability in a confirmation message based on the NETCONF protocol, and sends the confirmation message to the head node 202. In another possible embodiment, the network management device 212 may also carry a corresponding device identifier in the acknowledgement packet through the device identifier information, so as to confirm which network device's ift capability is fed back by the ift capability confirmation information. In another possible embodiment, the confirmation message may simultaneously feed back the ift capability confirmation information of multiple network devices, and at this time, the confirmation message feeds back the corresponding relationship between each corresponding device identifier and the ift capability confirmation information.

S510 the network management device sends the confirmation packet to the first network device.

S515 the first network device receives a confirmation packet sent by the network management device, and confirms whether the second network device has an ift capability based on the confirmation information of the confirmation packet.

In one possible implementation, the method 500 further includes the following:

s520, the first network device confirms that the second network device has the iFIT capability, and sends the data packet with the encapsulated iFIT header to the second network device.

The embodiment of the present application provides a network device 600, and the network device 600 includes a processor 610, a memory 620, and a network interface 630. The network interface 630 is used for receiving messages from the network and/or sending messages to the network, which the network device 600 needs to send. The network interface 630 may also transmit messages received from the network to the memory 620 and the processor 610, and may also transmit messages processed or generated by the processor 610 to the network. Memory 620 is configured to store a computer program, and processor 610 is configured to execute the computer program stored in memory 620, thereby causing network device 600 to perform the corresponding ift capability confirmation method performed by the first network device in method 300 described above, where network device 600 may be, for example, head node 202 shown in fig. 1; alternatively, the network device 600 is caused to execute a corresponding ift capability reply method executed by the second network device in the method 300 or execute a corresponding ift capability reply method executed by the network management device in the method 400, where the network device 600 may be, for example, the tail node 210 shown in fig. 1, or may be the path node 204, 206, or 208, or may be the network management device 212; alternatively, the network device 600 is caused to perform the corresponding ift capability confirmation method as performed by the network management device in the method 500, where the network device 600 may be, for example, the network management device 212 shown in fig. 1.

Embodiments of the present application further provide a computer-readable storage medium or a computer program product for storing a corresponding computer program, which is respectively used for executing the corresponding methods executed by the first network device, the second network device, or the network management device in the foregoing methods 300, 400, and 500.

It should be understood that, in the embodiment of the present application, the processor may be a Central Processing Unit (CPU), or other possible general-purpose processors, etc.

The memory may be a non-volatile random access memory, which may include, for example, read only memory and/or random access memory, and provides instructions and data to the processor.

In implementation, the steps of the method 300, 400 or 500 may be performed by integrated logic circuits of hardware in the processor 610 or instructions in the form of software, or by a combination of hardware and software modules in the processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium may be located in a memory, and a processor reads information in the memory and performs the steps of the methods 300, 400, or 500 described above in conjunction with its hardware.

It is to be understood that the structural makeup of the network device 600 described above is merely one possible example. In practical applications, network device 600 may each include any number of interfaces, processors, memories, etc.

It should be understood that, in the various embodiments of the present application, the size of the serial number of each process does not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the various illustrative modules and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software or firmware, 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. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. 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, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, optical fiber, twisted pair) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any medium that can be accessed by a computer or a data storage device including one or more integrated media, servers, data centers, and the like. The media may be magnetic media (e.g., floppy disks, hard disks, magnetic tape), optical media (e.g., compact disks), or semiconductor media (e.g., Solid State Disks (SSDs)), among others.

All parts of this specification are described in a progressive manner, and like parts may be referred to one another between various embodiments. In particular, as for the apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and the relevant points can be referred to the description of the method embodiment section.

Finally, it is to be noted that: the above description is only an example of the technical solution of the present application, and is not intended to limit the scope of the present application.