WO2021098271A1 - 下发oam配置信息的方法及控制节点 - Google Patents

下发oam配置信息的方法及控制节点 Download PDF

Info

Publication number
WO2021098271A1
WO2021098271A1 PCT/CN2020/105085 CN2020105085W WO2021098271A1 WO 2021098271 A1 WO2021098271 A1 WO 2021098271A1 CN 2020105085 W CN2020105085 W CN 2020105085W WO 2021098271 A1 WO2021098271 A1 WO 2021098271A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
path
notification message
nodes
detection
Prior art date
Application number
PCT/CN2020/105085
Other languages
English (en)
French (fr)
Inventor
周天然
徐玲
刘敏
李振斌
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP20889871.8A priority Critical patent/EP4047888B1/en
Publication of WO2021098271A1 publication Critical patent/WO2021098271A1/zh
Priority to US17/746,078 priority patent/US20220278925A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/022—Multivendor or multi-standard integration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/03—Topology update or discovery by updating link state protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/033—Topology update or discovery by updating distance vector protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters

Definitions

  • This application relates to the field of routing technology, and in particular to a method and control node for issuing OAM configuration information.
  • In-site operation administration and maintenance in-site operation administration and maintenance, iOAM technology means that the head node sends data collection instructions to the tail node hop by hop, and each hop node collects detection data according to the data collection instructions.
  • the control node analyzes the detection data collected by each node to realize the path detection between the head node and the tail node.
  • the types of detection data that need to be collected under different path detection modes are different.
  • the type of the detection data may be the interface information for sending and receiving packets.
  • the type of the detection data is the timestamp information of the received and sent messages.
  • the OAM configuration needs to be issued to the node Information, the OAM configuration information is used to indicate some operations that the node needs to perform when performing the path detection mode.
  • the node if the node itself does not support the path detection mode, at this time, after the control node delivers the OAM configuration information to the node, the node will not be able to successfully perform path detection based on the OAM configuration information, which may cause the head node to interact with the path detection mode. Failure of path detection between tail nodes.
  • the present application provides a method and control node for issuing OAM configuration information, which can improve the success rate of path detection.
  • the technical solutions are as follows:
  • a method for issuing OAM configuration information is provided.
  • the control node respectively obtains the notification message sent by at least two of the multiple nodes included in the communication network.
  • the notification message includes indication information used to indicate the path detection mode supported by the sender of the notification message. Therefore, the control node can determine the detection path according to the required path detection mode and the notification messages sent by at least two nodes, and send OAM configuration information to the nodes in the determined detection path, such as the head node and the tail node. .
  • the node in order to avoid that after the control node sends OAM configuration information to a node, the node cannot successfully perform path detection based on the OAM configuration information because the node does not support the path detection mode that needs to be performed currently.
  • the node may send a notification message to the control node in advance.
  • the notification message includes indication information for indicating the path detection mode supported by the sender of the notification message, so that the control node can learn which nodes in the communication network can support the current The path detection mode that needs to be performed.
  • the control node can determine the detection path according to the node that can support the path detection mode currently required.
  • the tail node is a node that can support the path detection mode that needs to be performed, so as to ensure that the head node and the tail node can successfully perform path detection according to the OAM configuration information.
  • control node determines the detection path according to the path detection mode that needs to be performed and the notification message sent by at least two nodes, specifically: determining the detection path according to the node that supports the path detection mode that needs to be performed among the at least two nodes The head node and tail node in.
  • control node only needs to determine the head node and the tail node for path detection, so that the subsequent head node and tail node can implement path detection according to the OAM configuration information.
  • control node may further determine one or more intermediate nodes in the detection path based on the nodes that support the path detection mode that needs to be performed among the at least two nodes. At this time, the control node may also issue OAM configuration information to each of the one or more intermediate nodes.
  • control node after determining the head node and tail node for path detection, can also determine the intermediate node, and also send OAM configuration information to the intermediate node, so that subsequent intermediate nodes can also implement the OAM configuration information according to the OAM configuration information. Path detection.
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the sender of the notification message.
  • the notification message can also carry indication information indicating the type of detection data corresponding to the path detection mode supported by the sender of the notification message.
  • the control node knows that each node can
  • the types of detection data that can be collected by each node in the supported path detection mode can also be obtained, so as to facilitate the determination of which nodes can be used to determine the detection path.
  • the notification message further includes indication information for indicating the type of protocol used when the packet header carrying the data detection instruction is encapsulated in the path detection message.
  • the control node can also determine the type of protocol used when encapsulating the header of the data detection instruction in the message for path detection; for the type of protocol indicated in the notification message and the determined protocol For nodes with the same type, perform the step of determining the head node and the tail node in the detection path according to the nodes that support the path detection mode that needs to be performed among the at least two nodes.
  • the notification message further includes indication information for indicating the type of protocol used when the packet header carrying the data detection instruction is encapsulated in the path detection message.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the control node can directly obtain the notification message according to the type of the notification message for the path detection mode that the notification node can support, which improves the efficiency of issuing OAM configuration information.
  • the notification message is a message for notifying the RI LSA based on the routing information link state.
  • the notification message is a message based on TLV242.
  • the notification message is a message based on the opaque node attribute TLV.
  • the function of the notification message provided in the embodiment of this application can be realized through the existing message, which improves the comparison between the notification message provided in the embodiment of this application and the current situation.
  • protocol compatibility There is protocol compatibility.
  • the above-mentioned OAM configuration information issued to the head node includes a first access control list ACL configuration instruction, and the first ACL configuration instruction includes the identifier of the packet to be encapsulated and the specific content encapsulated in the packet; to the tail node
  • the issued OAM configuration information includes a second ACL configuration instruction, and the second ACL configuration instruction includes an identifier of the packet to be decapsulated.
  • a method for issuing OAM configuration information is provided, which is applied to a first node in a communication network.
  • the communication network includes a control node and multiple nodes, and the first node is one of the multiple nodes.
  • the first node sends a notification message to the control node, the notification message includes indication information for indicating the path detection mode supported by the first node, so that the control node determines the detection path according to the notification message.
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the first node.
  • the notification message further includes indication information for indicating the type of protocol used when the message header carrying the data detection instruction is encapsulated in the path detection message.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is a message for notifying RI and LSA based on the routing information link state.
  • the notification message is a message based on TLV242.
  • the notification message is a message based on the opaque node attribute TLV.
  • a control node is provided, the control node is a control node in a communication network, and the communication network further includes a plurality of nodes, and the control node includes:
  • the acquiring module is configured to respectively acquire the notification message sent by at least two of the multiple nodes, the notification message including indication information used to indicate the path detection mode supported by the sender of the notification message.
  • the determining module is used to determine the detection path according to the required path detection mode and the notification message sent by at least two nodes.
  • the issuing module is used to issue OAM configuration information to the head node and the tail node in the detection path.
  • determine the module specifically used for:
  • the head node and the tail node in the detection path are determined according to the nodes that support the path detection mode that needs to be performed among the at least two nodes.
  • the determining module is also specifically used for:
  • the node delivers OAM configuration information.
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the sender of the notification message;
  • the head node and the tail node in the detection path are determined according to at least two nodes that support the path detection mode that needs to be performed, and the type of detection data indicated by the notification message is consistent with the type of detection data that needs to be collected.
  • the notification message further includes indication information for indicating the type of protocol used when encapsulating the header of the message carrying the data detection instruction in the message for path detection;
  • the step of determining the head node and the tail node in the detection path is performed according to the nodes that support the path detection mode to be performed among the at least two nodes.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is a message for notifying RI and LSA based on the routing information link state.
  • the notification message is a message based on TLV242.
  • the notification message is a message based on the opaque node attribute TLV.
  • the OAM configuration information issued to the head node includes a first access control list ACL configuration instruction, and the first ACL configuration instruction includes the identifier of the message to be encapsulated and the specific content encapsulated in the message;
  • the OAM configuration information delivered to the tail node includes a second ACL configuration instruction, and the second ACL configuration instruction includes an identifier of the packet to be decapsulated.
  • a first node in a communication network includes a control node and multiple nodes, and the first node is one of the multiple nodes.
  • the first node includes:
  • the sending module is configured to send a notification message to the control node, where the notification message includes indication information for indicating the path detection mode supported by the first node, so that the control node determines the detection path according to the notification message.
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the first node.
  • the notification message further includes indication information for indicating the type of protocol used when the message header carrying the data detection instruction is encapsulated in the path detection message.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is a message for notifying RI and LSA based on the routing information link state.
  • the notification message is a message based on TLV242.
  • the notification message is a message based on the opaque node attribute TLV.
  • a control node in a communication network includes a memory and a processor
  • the memory is used to store computer programs
  • the processor is configured to execute a computer program stored in the memory to execute the method of any one of the above-mentioned first aspects.
  • a first node in a communication network includes a control node and a plurality of nodes, the first node is one of the plurality of nodes, and the first node includes a memory and a processor;
  • the memory is used to store computer programs
  • the processor is configured to execute a computer program stored in the memory to execute the method of any one of the above-mentioned second aspects.
  • a chip is provided, the chip is arranged in a control node in a communication network, and the chip includes a processor and an interface circuit;
  • the interface circuit is used to receive instructions and transmit them to the processor
  • the processor is configured to execute the method of any one of the foregoing first aspect.
  • a chip is provided.
  • the chip is set in a first node in a communication network.
  • the communication network includes a control node and multiple nodes.
  • the first node is one of the multiple nodes.
  • the chip includes a processor and an interface. Circuit
  • the interface circuit is used to receive instructions and transmit them to the processor
  • the processor is used to execute the method of any one of the above-mentioned second aspects.
  • a system for issuing OAM configuration information including a control node and multiple nodes;
  • the first node among the multiple nodes is used to send a notification message to the control node, and the notification message includes indication information used to indicate the path detection mode supported by the first node;
  • the control node is configured to receive the notification message sent by the first node, so that the detection path is determined according to the notification message.
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the first node.
  • the notification message further includes indication information for indicating the type of protocol used when the message header carrying the data detection instruction is encapsulated in the path detection message.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is a message for notifying RI and LSA based on the routing information link state.
  • the notification message is a message based on TLV242.
  • the notification message is a message based on the opaque node attribute TLV.
  • FIG. 1 is a schematic diagram of an iOAM tracking mode provided by an embodiment of the present application
  • FIG. 2 is a schematic diagram of an iOAM E2E mode provided by an embodiment of the present application
  • FIG. 3 is a schematic diagram of an iOAM point-by-point upload mode provided by an embodiment of the present application
  • FIG. 4 is a flowchart of a method for issuing OAM configuration information according to an embodiment of the present application
  • FIG. 5 is a schematic diagram of a RILSA format provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of a TLV242 format provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of an opaque node attribute TLV format provided by an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a network device provided by an embodiment of the present application.
  • FIG. 9 is a schematic structural diagram of another network device provided by an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of an interface board in the network device shown in FIG. 9 provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a control node provided by an embodiment of the present application.
  • FIG. 12 is a schematic structural diagram of a first node provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a network device provided by an embodiment of the present application.
  • iOAM technology is a telemetry technology used on the data plane.
  • data collection instructions are carried in business messages, which is different from traditional OAM technology (revised in addition to business messages).
  • OAM technology has many problems such as inaccurate measurement, too little information, and verification difficulties.
  • iOAM technology just solves these problems.
  • IETF ippm Internet Engineering Task Force Internet Protocol Performance Metrics
  • the path detection mode is also called iOAM mode (type) to solve different problems.
  • iOAM mode type
  • trace type trace type
  • E2E endpoint to end
  • iOAM E2E mode packet loss rate and delay
  • postcard Type point-by-point Sending mode
  • Fig. 1 is a schematic diagram of an iOAM tracking mode provided by an embodiment of the present application.
  • the head node is used to encapsulate the iOAM header for the specified message.
  • the iOAM header contains the data collection instruction and the detection data collected by itself (the square filled with diagonal stripes in Figure 1 is used to indicate the specified message.
  • the square is used to indicate the iOAM header).
  • Each intermediate node (only one intermediate node is used as an example in Figure 1 for illustration) is used to collect other detection data hop by hop along the way according to the data collection instruction (the squares filled in the squares in Figure 1 are used to indicate the collected detection data), And record the collected detection data on the iOAM head.
  • the tail node is used to decapsulate the iOAM header, restore the specified message, and continue to transmit the specified message. At the same time, the tail node also needs to upload the detection data collected by each node according to the iOAM header.
  • FIG. 2 is a schematic diagram of the iOAM E2E mode provided by an embodiment of the present application.
  • the head node is used to encapsulate the iOAM header for the specified message.
  • the iOAM header contains the data collection instruction and the detection data collected by itself (the square filled with diagonal stripes in Figure 1 is used to indicate the specified message. The square is used to indicate the iOAM header).
  • the intermediate node does not need to collect the detection data, only the head node and the tail node need to collect the detection data. Therefore, the intermediate node only needs to continue to pass the specified message encapsulated with the iOAM header sent by the head node.
  • the tail node After the tail node collects the detection data according to the data collection instructions, it decapsulates the iOAM header, restores the specified message, and continues to transmit the specified message. At the same time, the tail node also needs to combine the detection data collected by the head node and the collected data according to the iOAM header. The probe data is uploaded.
  • FIG. 3 is a schematic diagram of an iOAM point-by-point upload mode provided by an embodiment of the present application.
  • the head node is used to encapsulate the iOAM header for the specified message.
  • the iOAM header contains the data collection instruction and the detection data collected by itself (the square filled with diagonal stripes in Figure 3 is used to indicate the specified message.
  • the square is used to indicate the iOAM header).
  • Each intermediate node (only one intermediate node is used as an example for illustration in Figure 1) on the one hand is used to decapsulate the iOAM header to upload the detection data collected by the previous hop node, on the other hand it is also used to collect the data Command, collect the detection data along the way hop by hop (the squares filled in the grid in Figure 1 are used to indicate the collected detection data), and record the collected detection data on the iOAM head.
  • the tail node is also used to decapsulate the iOAM header, restore the specified message, and continue to transmit the specified message. At the same time, the tail node also needs to upload the detection data collected by the previous hop node according to the iOAM header.
  • the above three path detection modes are only used for illustration, and when the method for issuing OAM configuration information provided in the embodiment of the present application is applied, it may not be limited to the above three path detection modes.
  • the aforementioned head node may also be called an encap node
  • the intermediate node may also be called a transit node
  • the tail node may also be called a decap node, which is not specifically limited in the embodiment of the present application. .
  • the method for issuing OAM configuration information provided in the embodiments of the present application can be applied to the above-mentioned iOAM technology, and can also be applied to the traditional OAM technology, which is not specifically limited.
  • Fig. 4 is a flowchart of a method for delivering OAM configuration information according to an embodiment of the present application.
  • the method is applied to a control node in a communication network, and the communication network also includes a plurality of nodes.
  • the method includes the following steps:
  • Step 401 The control node separately obtains a notification message sent by at least two of the multiple nodes, where the notification message includes indication information used to indicate the path detection mode supported by the sender of the notification message.
  • each node can send a notification message to the control node in advance, the notification message includes indication information for indicating the path detection mode supported by the sender of the notification message, so that the control node can learn which nodes in the communication network can support The path detection mode currently required.
  • the control node can determine the detection path from the nodes that can support the path detection mode currently required. In this way, after sending OAM configuration information to the head node and tail node in the detection path, It can be ensured that the head node and the tail node can successfully perform path detection according to the OAM configuration information.
  • the notification message may also include indication information for indicating that the type of the notification message is an OAM capability notification message.
  • indication information for indicating that the type of the notification message is an OAM capability notification message.
  • the notification message may also include indication information for indicating the type of detection data corresponding to the path detection mode supported by the sender of the notification message.
  • the indication information used to indicate the type of detection data corresponding to the path detection mode supported by the sender of the notification message may be directly the type of the detection data, and may also be a namespace (namespaceID) identifier.
  • the control node can use the namespace identifier to obtain the pre-stored namespace identifier and In the correspondence between the data types, the type of detection data corresponding to the path detection mode supported by the sender of the notification message is determined.
  • the notification message may not need to include indication information for indicating the type of detection data corresponding to the path detection mode supported by the sender of the notification message.
  • the namespace identifier cannot be used to indicate the type of detection data corresponding to the path detection mode supported by the sender of the notification message, at this time, the namespace identifier cannot be used to determine and notify the message. The type of detection data corresponding to the path detection mode supported by the sender is now.
  • the notification message may also include a protocol used to indicate that the packet header carrying the data detection instruction is encapsulated in the path detection message.
  • the type of the protocol can be the fourth-generation Internet Protocol (Internet Protocol Version 4, IPv4) or the sixth-generation Internet Protocol (Internet Protocol Version 6, IPv6), or it can also be segment routing based on IPv6 (segment routing based on IPv6). , SRv6) protocol.
  • the control node when determining the detection path, the control node also needs to consider whether the type of protocol indicated in the notification message sent by the node and the type of protocol used when the current path detection service message is encapsulated and carries data encapsulation instructions Consistent, the detection path will continue to be determined only when they are consistent.
  • the above-mentioned notification message can directly use the messages that have been defined in the current existing communication protocol, as long as these messages meet the above-mentioned conditions.
  • the notification message is based on routing information Link state advertisement (routing information link-state advertisement, RI LSA) message. That is, one RI LSA in the notification message under the OSPF protocol can be extended, and the obtained message is the notification message provided in the embodiment of this application.
  • OSPF open shortest path first
  • RI LSA routing information Link state advertisement
  • FIG. 5 is a schematic diagram of the format of an RI LSA provided by an embodiment of the present application.
  • the RI LSA includes a 16-bit (bit) type (type) field, a 16-bit length (length) field, a 4-bit protocol (protocol) field, and a 12-bit path detection mode (iOAM type).
  • Field a 16-bit namespace ID (namespaceID) field, and one or more sub-TLVs (sub-TLV).
  • the type field is used to indicate that the type of the RI LSA is an OAM capability announcement message.
  • the length field is used to indicate the length of the RI LSA.
  • the protocol field is used to indicate the type of protocol used when the packet header carrying the data detection instruction is encapsulated in the packet for path detection.
  • the path detection mode field is used to indicate the supported path detection mode.
  • the namespace identifier field is used to indicate the type of detection data supported by the supported path detection mode.
  • One or more sub-TLVs are used to carry other information.
  • the notification message may It is a message based on TLV 242. That is, one TLV 242 in the notification message under the ISIS protocol can be extended, and the obtained message is the notification message provided in the embodiment of this application.
  • ISIS Intermediate System to Intermediate System
  • FIG. 6 is a schematic diagram of the format of a TLV 242 provided by an embodiment of the present application.
  • the TLV 242 includes a 1-byte type (type) field, a 1-byte length (length) field, a 4-bit protocol (protocol) field, and a 12-bit path detection mode (iOAM type) field.
  • iOAM type path detection mode
  • a 16-bit namespace ID (namespaceID) field and one or more sub-TLVs (sub-TLV).
  • the notification message is based on the opaque node attribute TLV ( opaque Node attribute TLV) message. That is, an opaque node attribute TLV in the notification message under the BGP protocol can be extended, and the obtained message is the notification message provided in the embodiment of this application.
  • TLV opaque Node attribute TLV
  • FIG. 7 is a schematic diagram of the format of an opaque node attribute TLV provided by an embodiment of the present application.
  • the opaque node attribute TLV includes a 16-bit type (type) field, a 16-bit length field, a 4-bit protocol field, and a 12-bit path detection mode (iOAM type) field, a 16-bit namespace identifier (namespaceID) field, and one or more sub-TLVs (sub-TLV).
  • type type
  • iOAM type path detection mode
  • namespaceID namespace identifier
  • sub-TLV sub-TLV
  • each field shown in FIG. 7 is the same as the function of each field shown in FIG. 5, and it will not be explained one by one here as well.
  • FIGS. 5 to 7 are only used to illustrate the notification message provided by the embodiment of the present application, and do not constitute a limitation on the notification message provided by the embodiment of the present application.
  • Step 402 The control node determines the detection path according to the required path detection mode and the notification message sent by at least two nodes.
  • the notification message includes indication information for indicating the path detection mode supported by the sender of the notification message. Therefore, in an example, the implementation process of step 401 may be: the control node determines the head node and the tail node in the detection path according to at least two nodes that support the path detection mode that needs to be performed.
  • control node may select the node that supports the path detection mode to be performed from the at least two nodes according to the notification message sent by the at least two nodes; determine the head node and the tail node for path detection according to the selected node , That is, determine the head node and tail node on the detection path.
  • a node through the method of determining the tail node in the related technology (such as using the node at the network exit as the tail node), and then determine whether the node supports the path detection mode that needs to be performed, and if so, the node Determined as the tail node. If the node does not support the path detection mode that needs to be performed, at this time, in an implementation manner, it is also possible to determine the node that is the previous hop of the previously determined node in the data stream, and then determine whether the node can be the tail node.
  • the head node and the tail node from the selected nodes may be determined as the head node, and the node at the exit of the network among the selected nodes may be determined as the tail node.
  • the control node may further determine one or more of the detection paths based on the nodes that support the path detection mode that needs to be performed among the at least two nodes. Intermediate node.
  • the implementation of obtaining the detection path may be: first determine the head node and the tail node from the selected nodes, and then determine multiple intermediate nodes according to the determined head node and tail node, thereby obtaining the detection path.
  • the determined head node and tail node to determine multiple intermediate nodes can also refer to related technologies, which will not be explained in detail here.
  • the control node may also perform the process as needed.
  • Path detection mode determine the type of detection data that needs to be collected; then according to the path detection mode that needs to be supported in at least two nodes, and the type of detection data indicated in the notification message is consistent with the type of detection data that needs to be collected Nodes, determine the head node and tail node in the detection path.
  • control node may continue to select the type of detection data indicated by the notification message and the type of detection data to be collected from the selected nodes Consistent nodes; so as to continue to select nodes, the head node and tail node for path detection are determined according to the selected node.
  • control node determines that a node supports the path detection mode that needs to be performed, it needs to further determine that the type of detection data indicated by the notification message sent by the node is consistent with the type of detection data that needs to be collected At this time, the node is included in the candidate node for determining the detection path.
  • the control node may also first determine that the path detection is performed. The type of protocol used when the packet header carrying the data detection instruction is encapsulated in the packet; then for nodes whose protocol type indicated in the notification packet is the same as the determined protocol type, the implementation is based on the support needs of at least two nodes For the nodes in the path detection mode, determine the steps of the head node and the tail node in the detection path.
  • control node may first select a node whose protocol type indicated in the notification message is consistent with the determined protocol type from at least two nodes; for the selected node, according to the notification message sent by the node, the selected node Select the node that supports the path detection mode that needs to be performed from the nodes to determine the detection path in the above-mentioned manner.
  • the control node needs to select from at least two nodes the type of the protocol indicated in the notification packet is IPv6, and then select the node that supports the need The node in the path detection mode.
  • nodes with the same type of selection protocol and the nodes that select the path detection mode that needs to be supported are in no particular order, and it is only necessary that the final selected node can meet these two conditions.
  • Step 403 The control node delivers OAM configuration information to the head node and the tail node in the detection path.
  • the OAM configuration information sent by the control node to the head node includes a first access control list (access control list, ACL) configuration instruction, and the first ACL configuration instruction includes the identifier of the message to be encapsulated and the encapsulation in the message
  • ACL access control list
  • the OAM configuration information issued to the tail node includes the second ACL configuration instruction
  • the second ACL configuration instruction includes the identifier of the packet to be decapsulated.
  • the identifier of the message to be encapsulated and the identifier of the message to be decapsulated are the same identifier, and the identifier is used to indicate the identifier of the message used for path detection.
  • the identifier can be the destination address of the message.
  • the head node receives the OAM configuration information
  • the service message An iOAM header is encapsulated in the middle, and the iOAM header carries a data collection instruction, and the data collection instruction is determined according to the specific content encapsulated in the message included in the first ACL configuration instruction.
  • the service message encapsulated with the iOAM header is sent to the next hop node.
  • the tail node After the tail node receives the OAM configuration information, if the identifier of the received service message is the same as the identifier of the message to be encapsulated included in the first ACL configuration instruction, it will decapsulate the iOAM header in the service message and change The information carried in the iOAM header is reported.
  • the specific content encapsulated in the message included in the first ACL configuration instruction depends on the path detection mode that needs to be performed.
  • the specific content may include interface light information for sending and receiving messages.
  • the specific content can be information such as the message serial number of the message sent and received or the timestamp of the message sent and received.
  • the above-mentioned OAM configuration information issued to the head node may also include the identifier configured for the head node and/or the detection data collection enable command for the head node
  • the OAM configuration information issued to the tail node may also include
  • the identifier configured for the tail node and/or the detection data collection enable command for the tail node is not specifically limited here, and the specific content can be adjusted according to the current business scenario.
  • control node can also deliver OAM configuration information to intermediate nodes. It should be noted.
  • the embodiment of the present application does not limit the specific content of the OAM configuration information delivered to the intermediate node and the scenario in which the OAM configuration information is delivered to the intermediate node.
  • the OAM configuration issued to the intermediate node may include an identifier configured for the intermediate node, and/or an enable command for collecting and detecting data for the intermediate node, etc.
  • each node can send a notification message to the control node in advance, the notification message includes indication information for indicating the path detection mode supported by the sender of the notification message, so that the control node can learn which nodes in the communication network can support The path detection mode currently required.
  • the control node can determine the detection path from the nodes that can support the path detection mode currently required. In this way, after sending OAM configuration information to the head node and tail node in the detection path, It can be ensured that the head node and the tail node can successfully perform path detection according to the OAM configuration information.
  • FIG. 8 is a schematic structural diagram of a network device provided by an embodiment of the present application.
  • the network device may be any one of multiple nodes included in the communication network in any of the foregoing embodiments.
  • the network device 800 may be a switch, a router, or other network devices that forward packets.
  • the network device 800 includes: a main control board 810, an interface board 830, and an interface board 840.
  • a switching network board (not shown in the figure) may be included, and the switching network board is used to complete data exchange between interface boards (interface boards are also called line cards or service boards).
  • the main control board 810 is used to perform functions such as system management, equipment maintenance, and protocol processing.
  • the interface boards 830 and 840 are used to provide various service interfaces (for example, POS interface, GE interface, ATM interface, etc.), and implement message forwarding.
  • the main control board 810, the interface board 830, and the interface board 840 are connected to the system backplane through a system bus to achieve intercommunication.
  • the interface board 830 includes one or more processors 831.
  • the processor 831 is used for controlling and managing the interface board, communicating with the central processing unit on the main control board, and for forwarding processing of messages.
  • the memory 832 on the interface board 830 is used to store forwarding entries, and the processor 831 performs packet forwarding by searching for the forwarding entries stored in the memory 832.
  • the interface board 830 includes one or more network interfaces 833 for receiving the detection message sent by the previous hop node, and sending the processed detection message to the next hop network node according to the instruction of the processor 831.
  • the specific implementation process will not be repeated here one by one.
  • the one or more network interfaces 833 are also used to send the notification message in step 401 to the control node, so that the control node can issue OAM through steps 401 to 403 in FIG. 4 Configuration information.
  • the processor 831 may be used to determine the notification message in step 401.
  • the notification message may be any of the notification messages shown in FIG. 5 to FIG. 7.
  • the specific functions of the processor 831 will not be repeated here. .
  • this embodiment includes multiple interface boards and adopts a distributed forwarding mechanism. Under this mechanism, the operation on the interface board 840 is basically similar to that of the interface board 830.
  • the processors 831 and/or 841 in the interface board 830 in FIG. 8 may be dedicated hardware or chips, such as a network processor or an application specific integrated circuit (application specific integrated circuit) to implement the above functions.
  • One way to achieve this is to use dedicated hardware or chip processing for the so-called forwarding plane.
  • the processor 831 and/or 841 may also adopt a general-purpose processor, such as a general-purpose CPU, to implement the functions described above.
  • main control boards there may be one or more main control boards, and when there are more than one, it may include a main main control board and a standby main control board.
  • interface boards There may be one or more interface boards. The stronger the data processing capability of the device, the more interface boards provided.
  • the multiple interface boards can communicate through one or more switching network boards, and when there are more than one, the load sharing and redundant backup can be realized together.
  • the device does not need to switch the network board, and the interface board undertakes the processing function of the business data of the entire system.
  • the device includes multiple interface boards, which can realize data exchange between multiple interface boards through the switching network board, and provide large-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of network equipment with a distributed architecture are greater than those with a centralized architecture.
  • the specific architecture used depends on the specific networking deployment scenario, and there is no restriction here.
  • the memory 832 may be a read-only memory (read-only memory, ROM) or other types of static storage devices that can store static information and instructions, a random access memory (random access memory, RAM), or can store Other types of dynamic storage devices for information and instructions can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only Memory, CD-ROM, or Other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or can be used to carry or store desired program codes in the form of instructions or data structures And any other media that can be accessed by the computer, but not limited to this.
  • the memory 832 may exist independently, and is connected to the processor 831 through a communication bus.
  • the memory 832 may also be integrated with the processor 831.
  • the memory 832 is used to store program codes, which are controlled by the processor 831 to execute, so as to execute the path detection method provided in the foregoing embodiments.
  • the processor 831 is configured to execute program codes stored in the memory 832.
  • One or more software modules can be included in the program code.
  • the one or more software modules may be the software modules provided in any of the following embodiments in FIG. 11 or FIG. 12.
  • the network interface 833 may be any device such as a transceiver for communicating with other devices or communication networks, such as Ethernet, radio access network RAN, and wireless local area network (wireless local area network). local area networks, WLAN), etc.
  • a transceiver for communicating with other devices or communication networks, such as Ethernet, radio access network RAN, and wireless local area network (wireless local area network). local area networks, WLAN), etc.
  • FIG. 9 is a schematic structural diagram of another network device provided by an embodiment of the present application.
  • the network device may be the first node among multiple nodes in the communication network provided in any embodiment of the above-mentioned figure.
  • the network device 900 may be a switch, a router, or other network devices that forward packets.
  • the network device 900 includes: a main control board 910, an interface board 930, a switching network board 920, and an interface board 940.
  • the main control board 910 is used to perform functions such as system management, equipment maintenance, and protocol processing.
  • the switching network board 920 is used to complete data exchange between various interface boards (interface boards are also called line cards or service boards).
  • the interface boards 930 and 940 are used to provide various service interfaces (for example, POS interface, GE interface, ATM interface, etc.), and implement data packet forwarding.
  • the control plane is composed of the management and control units of the main control board 910 and the management and control units on the interface boards 930 and 940, and so on.
  • the main control board 910, the interface boards 930 and 940, and the switching network board 920 are connected to the system backplane through the system bus to achieve intercommunication.
  • the central processing unit 931 on the interface board 930 is used to control and manage the interface board and communicate with the central processing unit on the main control board.
  • the forwarding entry memory 934 on the interface board 930 is used to store forwarding entries, and the network processor 932 forwards the message by searching for the forwarding entries stored in the forwarding entry memory 934.
  • the physical interface card 933 of the interface board 930 is used to receive the detection message sent by the previous hop node. The specific implementation process will not be repeated here one by one.
  • the network processor 932 is used to determine the notification message in step 401.
  • the notification message may be any one of the notification messages shown in FIG. 5 to FIG. 7.
  • the specific functions of the network processor 932 will not be repeated here. .
  • the detection message with the detection data added is sent to the next hop node of the first node through the physical interface card 933.
  • the physical interface card 933 is also used to send the notification message in step 401 to the control node, so that the control node can issue OAM configuration information through steps 401 to 403 in FIG. 4 , The specific implementation process will not be repeated here one by one.
  • this embodiment includes multiple interface boards and adopts a distributed forwarding mechanism.
  • the operation on the interface board 940 is basically similar to that of the interface board 930, for the sake of brevity. ,No longer.
  • the functions of the network processors 932 and 942 in FIG. 9 can be replaced by application specific integrated circuits.
  • main control boards there may be one or more main control boards, and when there are more than one, it may include a main main control board and a standby main control board.
  • interface boards There may be one or more interface boards. The stronger the data processing capability of the device, the more interface boards provided.
  • the switching network board may not exist, or there may be one or more. When there are more than one, the load sharing and redundant backup can be realized together. Under the centralized forwarding architecture, the device does not need to switch the network board, and the interface board undertakes the processing function of the business data of the entire system.
  • the device can have at least one switching network board, and data exchange between multiple interface boards is realized through the switching network board, providing large-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of network equipment with a distributed architecture are greater than those with a centralized architecture.
  • the specific architecture used depends on the specific networking deployment scenario, and there is no restriction here.
  • FIG. 10 is a schematic structural diagram of the interface board 1000 in the above-mentioned network device shown in FIG. 9 provided by an embodiment of the present application.
  • the network device where the interface board 1000 is located may be a plurality of communication networks included in any of the above-mentioned embodiments.
  • the interface board 1000 may include a physical interface card (PIC) 1030, a network processor (NP) 1010, and a traffic management module (traffic management) 1020.
  • PIC physical interface card
  • NP network processor
  • traffic management traffic management
  • PIC physical interface card (physical interface card), used to realize the docking function of the physical layer, the original traffic enters the interface board of the network device from this, and the processed message is sent from the PIC card.
  • the network processor NP1010 is used to implement message forwarding processing. Specifically, the processing of upstream messages includes: processing of the inbound interface of the message, acquisition of timestamps, upstream classification, forwarding table lookup, measurement information encapsulation, and message copy processing; downstream message processing: forwarding table lookup, Downstream classification, time stamp acquisition, measurement information encapsulation, outbound interface processing, etc.
  • Traffic Management TM is used to implement QoS, wire-speed forwarding, large-capacity buffering, queue management and other functions.
  • upstream traffic management includes: upstream QoS processing (such as congestion management and queue scheduling, etc.) and slicing processing;
  • downstream traffic management includes: packet processing, multicast replication, and downstream QoS processing (such as congestion management and queue scheduling, etc.) ).
  • the multiple interface boards 1000 can communicate through the switching network 1040.
  • FIG. 10 only shows a schematic processing flow or module inside the NP, and the processing sequence of each module in a specific implementation is not limited to this, and other modules or processing flows can be deployed as needed in practical applications. The comparison of the embodiments of this application is not limited.
  • FIG. 11 is a schematic structural diagram of a control node provided by an embodiment of the present application.
  • the control node is a control node in a communication network, and the communication network further includes multiple nodes. As shown in FIG. 11, the control node 1100 includes:
  • the obtaining module 1101 is configured to obtain notification messages sent by at least two of the multiple nodes, and the notification message includes indication information used to indicate the path detection mode supported by the sender of the notification message. For the specific implementation process, refer to step 401 in the embodiment of FIG. 4.
  • the determining module 1102 is configured to determine the detection path according to the required path detection mode and the notification message sent by at least two nodes. For the specific implementation process, reference may be made to step 402 in the embodiment of FIG. 4.
  • the issuing module 1103 is used to issue OAM configuration information to the head node and the tail node in the detection path. For the specific implementation process, refer to step 403 in the embodiment of FIG. 4.
  • determine the module specifically used for:
  • the head node and the tail node in the detection path are determined according to the nodes that support the path detection mode that needs to be performed among the at least two nodes.
  • the determining module is also specifically used for:
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the sender of the notification message;
  • the head node and the tail node in the detection path are determined according to at least two nodes that support the path detection mode that needs to be performed, and the type of detection data indicated by the notification message is consistent with the type of detection data that needs to be collected.
  • the notification message further includes indication information for indicating the type of protocol used when encapsulating the header of the message carrying the data detection instruction in the message for path detection;
  • the step of determining the head node and the tail node in the detection path is performed according to the nodes that support the path detection mode to be performed among the at least two nodes.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is a message for notifying the RI LSA based on the routing information link state.
  • the notification message is a notification message based on TLV242.
  • the notification message is a notification message based on the opaque node attribute TLV.
  • the OAM configuration information issued to the head node includes a first access control list ACL configuration instruction, and the first ACL configuration instruction includes the identifier of the message to be encapsulated and the specific content encapsulated in the message;
  • the OAM configuration information delivered to the tail node includes a second ACL configuration instruction, and the second ACL configuration instruction includes an identifier of the packet to be decapsulated.
  • each node can send a notification message to the control node in advance, the notification message includes indication information for indicating the path detection mode supported by the sender of the notification message, so that the control node can learn which nodes in the communication network can support The path detection mode currently required.
  • the control node can determine the detection path from the nodes that can support the path detection mode currently required. In this way, after sending OAM configuration information to the head node and tail node in the detection path, It can be ensured that the head node and the tail node can successfully perform path detection according to the OAM configuration information.
  • control node provided in the above embodiment delivers OAM configuration information
  • only the division of the above functional modules is used as an example for illustration.
  • the above function allocation can be completed by different functional modules according to needs. That is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
  • the control node provided in the foregoing embodiment and the method embodiment for issuing OAM configuration information belong to the same concept. For the specific implementation process, please refer to the method embodiment, which will not be repeated here.
  • FIG. 12 is a schematic structural diagram of a first node provided by an embodiment of the present application.
  • the communication network includes a control node and multiple nodes, and the first node is one of the multiple nodes.
  • the first node 1200 includes:
  • the sending module 1201 is configured to send a notification message to the control node, where the notification message includes indication information for indicating the path detection mode supported by the first node, so that the control node determines the detection path according to the notification message.
  • the notification message sent by the first node reference may be made to the detailed description of the notification message in step 401 in the embodiment of FIG. 4.
  • the notification message further includes indication information used to indicate the type of detection data corresponding to the path detection mode supported by the first node.
  • the notification message further includes indication information for indicating the type of protocol used when the message header carrying the data detection instruction is encapsulated in the path detection message.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is an RI LSA message based on the routing information link state notification.
  • the notification message is a message based on TLV242.
  • the notification message is a message based on the opaque node attribute TLV.
  • each node can send a notification message to the control node in advance, the notification message includes indication information for indicating the path detection mode supported by the sender of the notification message, so that the control node can learn which nodes in the communication network can support The path detection mode currently required.
  • the control node can determine the detection path from the nodes that can support the path detection mode currently required. In this way, after sending OAM configuration information to the head node and tail node in the detection path, It can be ensured that the head node and the tail node can successfully perform path detection according to the OAM configuration information.
  • the first node provided in the above embodiment sends a notification message, it only uses the division of the above functional modules for illustration. In actual applications, the above functions can be allocated by different functional modules according to needs. , Divide the internal structure of the device into different functional modules to complete all or part of the functions described above.
  • the first node provided in the foregoing embodiment belongs to the same concept as the method embodiment for issuing OAM configuration information. For the specific implementation process, please refer to the method embodiment, which will not be repeated here.
  • the embodiment of the present application also provides a system for issuing OAM configuration information.
  • the system includes a control node and multiple nodes.
  • the first node among the multiple nodes is used to send a notification message to the control node, and the notification message includes indication information used to indicate the path detection mode supported by the first node; the control node is used to receive Announcement message sent by the first node.
  • the configuration information is delivered through the embodiment shown in FIG. 4 above.
  • the notification message also includes indication information for indicating the type of detection data corresponding to the path detection mode supported by the first node.
  • the notification message further includes indication information for indicating the type of protocol used when the message header carrying the data detection instruction is encapsulated in the path detection message.
  • the announcement message further includes indication information for indicating that the type of the announcement message is an OAM capability announcement message.
  • the notification message is a message for notifying RI and LSA based on the routing information link state.
  • the notification message is a message based on TLV242.
  • the notification message is a Pavillion based on the opaque node attribute TLV.
  • control node delivers the OAM configuration information according to the notification message.
  • FIG. 13 is a schematic structural diagram of a network device provided by an embodiment of the present invention. Any one of the multiple nodes in the embodiment of FIG. 4 may be implemented by the network device 1300 shown in FIG. 13. At this time, the network device 1300 may be a switch, a router, or other network device that forwards packets. In addition, the control node in the embodiment of FIG. 4 can also be implemented by the network device 1300 shown in FIG. 13. At this time, the specific functions of the network device 1300 can refer to the specific implementation of the control node in the embodiment of FIG. 4, in This will not be repeated here. Referring to FIG. 13, the network device includes at least one processor 1301, a communication bus 1302, a memory 1303, and at least one communication interface 1304.
  • the processor 1301 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling program execution of the solution of the present application.
  • the processor 1301 When the network device serves as any one of multiple nodes in the communication network, the processor 1301 is configured to determine the notification message in step 401 in FIG. 4.
  • the processor 1301 When the network device is used as a control node in the communication network, the processor 1301 is configured to implement any method from step 401 to step 403 in FIG. 4. The specific functions will not be repeated here.
  • the communication bus 1302 may include a path for transferring information between the above-mentioned components.
  • the memory 1303 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), or other types that can store information and instructions
  • the dynamic storage device can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only Memory (CD-ROM) or other optical disc storage, optical disc storage (Including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or can be used to carry or store desired program codes in the form of instructions or data structures and can be accessed by a computer Any other media, but not limited to this.
  • the memory 1303 may exist independently, and is connected to the processor 1301 through a communication bus 1302.
  • the memory 1303 may also be integrated with the processor 1301.
  • the memory 1303 is used to store program codes for executing the solutions of the present application, and the processor 1301 controls the execution.
  • the processor 1301 is configured to execute the program code stored in the memory 1303.
  • One or more software modules can be included in the program code.
  • the control node or any one of the multiple nodes in the embodiment of FIG. 4 can determine the data used to develop the application through the processor 1301 and one or more software modules in the program code in the memory 1303.
  • the one or more software modules may be the software modules provided in any embodiment of FIG. 11 or FIG. 12.
  • the communication interface 1304 uses any device such as a transceiver to communicate with other devices or communication networks, such as Ethernet, radio access network RAN, wireless local area networks (WLAN), and so on.
  • the communication interface 1304 is used to send the notification message in step 401 in FIG. 4 to the control node.
  • the communication interface 1304 is used to receive the notification message in step 401 in FIG. 4. The specific functions will not be repeated here.
  • the network device may include multiple processors, such as the processor 1301 and the processor 1305 shown in FIG. 13.
  • processors can be a single-CPU (single-CPU) processor or a multi-core (multi-CPU) processor.
  • the processor here may refer to one or more devices, circuits, and/or processing cores for processing data (for example, computer program instructions).
  • the aforementioned network device may be a general network device or a dedicated network device.
  • the network device may be a desktop computer, a portable computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device.
  • PDA personal digital assistant
  • the embodiments of this application do not limit the type of network equipment.
  • this embodiment may also be based on a virtual first node implemented by a general physical server combined with network function virtualization NFV technology.
  • the virtual first node is a virtual router, and second, third, and N nodes can be virtualized (according to actual needs).
  • the virtual first node may be a virtual machine (English: Virtual Machine, VM) running a program for providing a message sending function, and the virtual machine is deployed on a hardware device (for example, a physical server).
  • a virtual machine refers to a complete computer system with complete hardware system functions that is simulated by software and runs in a completely isolated environment.
  • Those skilled in the art can combine NFV technology to virtualize multiple first nodes with the above-mentioned functions on a general physical server by reading this application. I won't repeat them here.
  • the computer may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software it can be implemented in the form of a computer program product in whole or in part.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • 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.
  • the computer instructions may be transmitted from a website, computer, server, or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media.
  • the usable medium may be a magnetic medium (for example: floppy disk, hard disk, magnetic tape), optical medium (for example: digital versatile disc (DVD)), or semiconductor medium (for example: solid state disk (SSD)) )Wait.
  • the program can be stored in a computer-readable storage medium.
  • the storage medium mentioned can be a read-only memory, a magnetic disk or an optical disk, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种下发OAM配置信息的方法及控制节点，属于路由技术领域。在本申请中，为了避免出现控制节点向某个节点下发OAM配置信息之后，该节点由于不支持当前需要进行的路径探测模式而无法成功根据OAM配置信息进行路径探测，通信网络中的各个节点可以预先向控制节点发送通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息，如此控制节点便可获知到通信网络中哪些节点能够支持当前需要进行的路径探测模式，从而根据能够支持当前需要进行的路径探测模式的节点中确定探测路径，这样向探测路径中的头节点和尾节点发送OAM配置信息之后，便可保证能够成功根据该OAM配置信息进行路径探测。

Description

下发OAM配置信息的方法及控制节点
本申请要求在2019年11月19日提交中华人民共和国知识产权局、申请号为201911135733.5、申请名称为“下发OAM配置信息的方法及控制节点”的中国专利申请的优先权，这篇中国专利申请的全部内容通过引用结合在本申请中。
技术领域
本申请涉及路由技术领域，特别涉及一种下发OAM配置信息的方法及控制节点。
背景技术
随流操作、管理和维护(in-site operation administration and maintenance，iOAM)技术是指头节点将数据收集指令逐跳发送至尾节点，每一跳节点均根据该数据收集指令收集探测数据，网络中的控制节点对各个节点收集的探测数据进行分析，以实现头节点与尾节点之间的路径探测。其中，不同的路径探测模式下需要收集的探测数据的类型不同。比如，当路径探测模式为需要分析出头节点和尾节点之间的路径拓扑时，探测数据的类型可以为收发报文的接口信息。又比如，当路径探测模式为需要分析出头节点和尾节点之间的传输时延时，探测数据的类型为收发报文的时间戳信息。另外，为了实现某个路径探测模式，控制节点在确定出需要进行的路径探测模式之后，对于头节点至尾节点之间的一些节点，比如头节点或尾节点，需要向该节点下发OAM配置信息，该OAM配置信息用于指示该节点在进行该路径探测模式时需要执行的一些操作。
在上述方式中，如果该节点自身不支持该路径探测模式，此时，控制节点向该节点下发OAM配置信息之后，该节点将不能成功根据OAM配置信息进行路径探测，从而可能导致头节点与尾节点之间的路径探测的失败。
发明内容
本申请提供了一种下发OAM配置信息的方法及控制节点，可以提高进行路径探测的成功率。技术方案如下：
第一方面，提供了一种下发OAM配置信息的方法。在该方法中，控制节点分别获取通信网络包括的多个节点中至少两个节点发送的通告报文。其中，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息。因此，控制节点可以根据需要进行的路径探测模式和至少两个节点发送的通告报文，确定探测路径，并向该确定的探测路径中的节点，例如头节点和尾节点，下发OAM配置信息。
在本申请实施例中，为了避免出现控制节点向某个节点下发OAM配置信息之后，该节点由于不支持当前需要进行的路径探测模式而无法成功根据OAM配置信息进行路径探测，通信网络中的节点可以预先向控制节点发送通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息，如此控制节点便可获知到通信网络中哪些节点能够支持当前需要进行的路径探测模式，此时，控制节点便可根据能够支持当前需要进行的路径探测模式的节点确定探测路径，这样向探测路径中的头节点和尾节点发送OAM配置信息 之后，由于头节点和尾节点是能够支持需要进行的路径探测模式的节点，从而保证头节点以及尾节点能够成功根据该OAM配置信息进行路径探测。
可选地，控制节点根据需要进行的路径探测模式和至少两个节点发送的通告报文，确定探测路径，具体为：根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点。
在一种实现方式中，控制节点只需确定进行路径探测的头节点和尾节点即可，以便于后续头节点和尾节点根据OAM配置信息即可实现路径探测。
可选地，在该方法中，控制节点还可以进一步根据至少两个节点中支持需要进行的路径探测模式的节点，继续确定探测路径中的一个或多个中间节点。此时，控制节点还可以向一个或多个中间节点中每个中间节点下发OAM配置信息。
在另一种实现方式中，控制节点在确定进行路径探测的头节点和尾节点之后，还可以确定中间节点，向中间节点也下发OAM配置信息，以便于后续中间节点也根据OAM配置信息实现路径探测。
可选地，该通告报文还包括用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息。这种场景下，根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点，具体为：确定需要收集的探测数据的类型；根据至少两个节点中支持需要进行的路径探测模式，且通告报文所指示的探测数据的类型和需要收集的探测数据的类型一致的节点，确定探测路径中的头节点和尾节点。
为了进一步提高路径探测的成功率，通告报文中还可以携带用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型指示信息，如此，控制节点在获知各个节点能够支持的路径探测之外，还可以获取各个节点在能够支持的路径探测模式下能够收集的探测数据的类型，从而便于确定哪些节点可以用于确定探测路径。
可选地，该通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。在这种场景下，控制节点还可以确定在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型；对于通告报文中指示的协议的类型和确定的协议的类型一致的节点，执行根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点的步骤。
为了进一步提高路径探测的成功率，该通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。此时，在考虑确定探测路径的备选节点时，还需保证备选节点的通告报文中指示的协议的类型和当前进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型一致，从而提高了后续头节点封装报文头的成功率。
可选地，该通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。此时，控制节点直接根据通告报文的类型便可获取该通告报文用于通告节点能够支持的路径探测模式，提高了下发OAM配置信息的效率。
可选地，在至少两个节点中任一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，该通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在至少两个节点中任一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，该通告报文为基于TLV 242的报文。
可选地，在至少两个节点中任一节点采用的通信协议为边界网关协议BGP的情况下，该通告报文为基于不透明节点属性TLV的报文。
在任一节点采用的通信协议为不同通信协议的情况下，均可以通过现有的报文来实现本申请实施例提供的通告报文的功能，提高了本申请实施例提供的通告报文与现有协议的兼容性。
可选地，上述向头节点下发的OAM配置信息包括第一访问控制列表ACL配置指令，第一ACL配置指令包括待封装的报文的标识以及在报文中封装的具体内容；向尾节点下发的OAM配置信息包括第二ACL配置指令，第二ACL配置指令包括待解封装的报文的标识。以便于后续头节点或尾节点根据该OAM配置信息进行路径探测。
第二方面、提供了一种下发OAM配置信息的方法，应用于通信网络中的第一节点，通信网络包括控制节点和多个节点，第一节点为多个节点中的一个。在该方法中：第一节点向控制节点发送通告报文，通告报文包括用于指示第一节点支持的路径探测模式的指示信息，以使得控制节点根据通告报文确定探测路径。
可选地，通告报文还包括用于指示与第一节点所支持的路径探测模式对应的探测数据的类型的指示信息。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在第一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在第一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，通告报文为基于TLV 242的报文。
可选地，在第一节点采用的通信协议为边界网关协议BGP的情况下，通告报文为基于不透明节点属性TLV的报文。
上述第二方面提供的各个技术方案的有益效果均可参考第一方面提供的下发OAM配置信息的技术方案的有益效果，在此不再一一赘述。
第三方面、提供了一种控制节点，该控制节点为通信网络中的控制节点，且该通信网络还包括多个节点，该控制节点包括：
获取模块，用于分别获取多个节点中至少两个节点发送的通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息。
确定模块，用于根据需要进行的路径探测模式和至少两个节点发送的通告报文，确定探测路径。
下发模块，用于向探测路径中的头节点和尾节点下发OAM配置信息。
可选地，确定模块，具体用于：
根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点。
可选地，确定模块，还具体用于：
根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的一个或多个中间节点，此时，下发模块，还用于向所述探测路径中的一个或多个中间节点下发OAM配置信息。
可选地，通告报文还包括用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息；
确定模块，具体用于：
确定需要收集的探测数据的类型；
根据至少两个节点中支持需要进行的路径探测模式，且通告报文所指示的探测数据的类型和需要收集的探测数据的类型一致的节点，确定探测路径中的头节点和尾节点。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息；
确定模块，具体用于：
确定在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型；
对于通告报文中指示的协议的类型和确定的协议的类型一致的节点，执行根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点的步骤。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在至少两个节点中任一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在至少两个节点中任一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，通告报文为基于TLV 242的报文。
可选地，在至少两个节点中任一节点采用的通信协议为边界网关协议BGP的情况下，通告报文为基于不透明节点属性TLV的报文。
可选地，向头节点下发的OAM配置信息包括第一访问控制列表ACL配置指令，第一ACL配置指令包括待封装的报文的标识以及在报文中封装的具体内容；
向尾节点下发的OAM配置信息包括第二ACL配置指令，第二ACL配置指令包括待解封装的报文的标识。
第四方面，提供了一种通信网络中的第一节点，通信网络包括控制节点和多个节点，第一节点为多个节点中的一个。该第一节点包括：
发送模块，用于向控制节点发送通告报文，通告报文包括用于指示第一节点支持的路径探测模式的指示信息，以使得控制节点根据该通告报文确定探测路径。
可选地，通告报文还包括用于指示与第一节点所支持的路径探测模式对应的探测数据的类型的指示信息。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在第一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在第一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，通告报 文为基于TLV 242的报文。
可选地，在第一节点采用的通信协议为边界网关协议BGP的情况下，通告报文为基于不透明节点属性TLV的报文。
第五方面、提供了一种通信网络中的控制节点，该控制节点包括存储器和处理器；
存储器用于存储计算机程序；
处理器用于执行存储器中存储的计算机程序以执行上述第一方面中任一项的方法。
第六方面、提供了一种通信网络中的第一节点，通信网络包括控制节点和多个节点，第一节点为多个节点中的一个，第一节点包括存储器和处理器；
存储器用于存储计算机程序；
处理器用于执行存储器中存储的计算机程序以执行上述第二方面中任一项的方法。
第七方面、提供了一种芯片，芯片设置在通信网络中的控制节点中，该芯片包括处理器和接口电路；
接口电路用于接收指令并传输至处理器；
处理器用于执行上述第一方面中任意一项的方法。
第七方面、提供了一种芯片，芯片设置在通信网络中的第一节点中，通信网络包括控制节点和多个节点，第一节点为多个节点中的一个，该芯片包括处理器和接口电路；
接口电路用于接收指令并传输至处理器；
处理器用于执行上述第二方面中任意一项的方法。
第八方面、提供了一种下发OAM配置信息的系统，该系统包括控制节点和多个节点；
其中，多个节点中第一节点，用于向控制节点发送通告报文，通告报文包括用于指示第一节点支持的路径探测模式的指示信息；
控制节点，用于接收第一节点发送的通告报文，以使得根据该通告报文确定探测路径。
可选地，通告报文还包括用于指示与第一节点所支持的路径探测模式对应的探测数据的类型的指示信息。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在第一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在第一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，通告报文为基于TLV 242的报文。
可选地，在第一节点采用的通信协议为边界网关协议BGP的情况下，通告报文为基于不透明节点属性TLV的报文。
附图说明
图1是本申请实施例提供的一种iOAM追踪模式示意图；
图2是本申请实施例提供的一种iOAM E2E模式示意图；
图3是本申请实施例提供的一种iOAM逐点上送模式示意图；
图4是本申请实施例提供的一种下发OAM配置信息的方法流程图；
图5是本申请实施例提供的一种RILSA格式示意图；
图6是本申请实施例提供的一种TLV242格式示意图；
图7是本申请实施例提供的一种不透明节点属性TLV格式示意图；
图8是本申请实施例提供的一种网络设备的结构示意图；
图9是本申请实施例提供的另一种网络设备的结构示意图；
图10是本申请实施例提供的一种图9所示网络设备中的接口板的结构示意图；
图11是本申请实施例提供的一种控制节点的结构示意图；
图12是本申请实施例提供的一种第一节点的结构示意图；
图13是本申请实施例提供的一种网络设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
应当理解的是，本文提及的“多个”是指两个或两个以上。在本申请的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
在对本申请实施例进行详细解释说明之前，先对本申请实施例涉及的应用场景进行解释说明。
iOAM技术是一种用于数据面的远距离测量(telemetry)技术，在iOAM技术中，是将数据收集指令携带在业务报文中的，与传统的OAM技术(是在业务报文之外重新生成包括数据收集指令的探测报文)相比有很多优势。传统的OAM技术具有测量不准、信息太少、验证困难等诸多问题，iOAM技术正好解决了这些问题，随着网络规模的扩大、和承载业务变得复杂，iOAM技术得到蓬勃发展，成为互联网工程任务组互联网性能指标(the internet engineering task force internet protocol performance metrics，IETF ippm)的热点之一。当前IETF ippm针对不同的应用场景，提出了多种路径探测模式，其中路径探测模式也称为iOAM模式(type)，用来解决不同的问题。比如针对路径跟踪，提出了iOAM追踪模式(trace type)；针对端对端的(endpoint to endpoint，E2E)丢包率和时延，提出了iOAM E2E模式；针对丢包定位，提出了iOAM逐点上送模式(postcard Type)等。
为了后续便于说明，下面列对几种常用的路径探测模式进行解释说明。
图1是本申请实施例提供的一种iOAM追踪模式的示意图。如图1所示，头节点用于为指定报文封装iOAM头，该iOAM头包含数据收集指令和自身收集的探测数据(图1中斜条纹填充的方块用于指示指定报文，点填充的方块用于指示iOAM头)。各个中间节点(图1中仅仅用一个中间节点为例进行说明)用于根据该数据收集指令，逐跳收集沿途他探测数据(图1中方格填充的方块用于指示收集的探测数据)，并将收集的探测数据记录在iOAM头。 尾节点用于解封装iOAM头，还原指定报文，并将指定报文继续传输下去，同时尾节点还需根据iOAM头将各个节点收集的探测数据进行上送。
图2是本申请实施例提供的iOAM E2E模式的示意图。如图2所示，头节点用于为指定报文封装iOAM头，该iOAM头包含数据收集指令和自身收集的探测数据(图1中斜条纹填充的方块用于指示指定报文，点填充的方块用于指示iOAM头)。在iOAM E2E模式中中间节点无需收集探测数据，只需头节点和尾节点收集探测数据即可，因此，中间节点只需将头节点发送的封装有iOAM头的指定报文继续传递下去即可。尾节点在根据数据收集指令收集探测数据之后，解封装iOAM头，还原指定报文，并将指定报文继续传输下去，同时尾节点还需根据iOAM头将头节点收集的探测数据和自身收集的探测数据进行上送。
图3是本申请实施例提供的一种iOAM逐点上送模式的示意图。如图3所示，头节点用于为指定报文封装iOAM头，该iOAM头包含数据收集指令和自身收集的探测数据(图3中斜条纹填充的方块用于指示指定报文，点填充的方块用于指示iOAM头)。各个中间节点(图1中仅仅用一个中间节点为例进行说明)一方面用于解封装iOAM头将上一跳节点收集的探测数据进行上送，另一方面还用于用于根据该数据收集指令，逐跳收集沿途探测数据(图1中方格填充的方块用于指示收集的探测数据)，并将收集的探测数据记录在iOAM头。尾节点也用于解封装iOAM头，还原指定报文，并将指定报文继续传输下去，同时尾节点还需根据iOAM头将上一跳节点收集的探测数据进行上送。
上述三种路径探测模式仅仅用于举例说明，在应用本申请实施例提供的下发OAM配置信息的方法时，可以不限于上述三种路径探测模式。
另外，上述头节点还可以称为封装(encap)节点，中间节点还可以称为传输(transit)节点，尾节点还可以称为解封装(decap)节点，本申请实施例对此不做具体限定。
此外需要说明的是，本申请实施例提供的下发OAM配置信息的方法可以应用在上述iOAM技术中，还可以应用在传统的OAM技术中，对此不做具体限定。
接下来对本申请实施例提供的下发OAM配置信息的方法进行解释说明。
图4是本申请实施例提供的一种下发OAM配置信息的方法流程图。该方法应用于通信网络中的控制节点，该通信网络还包括多个节点。如图4所示，该方法包括如下几个步骤：
步骤401：控制节点分别获取多个节点中至少两个节点发送的通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息。
在本申请实施例中，为了避免出现控制节点向某个节点下发OAM配置信息之后，该节点由于不支持当前需要进行的路径探测模式而无法成功根据OAM配置信息进行路径探测，通信网络中的各个节点可以预先向控制节点发送通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息，如此控制节点便可获知到通信网络中哪些节点能够支持当前需要进行的路径探测模式，此时，控制节点便可从能够支持当前需要进行的路径探测模式的节点中确定探测路径，这样向探测路径中的头节点和尾节点发送OAM配置信息之后，便可保证头节点和尾节点能够成功根据该OAM配置信息进行路径探测。
为了后续便于说明，在此先对本申请实施例提供的通告报文进行解释说明。
在一种示例中，通告报文还可以包括用于指示通告报文的类型为OAM能力通告报文的指示信息，如此，其他节点在接收到某个节点发送的通告报文时，只需根据该通告报文的类型即可获知到该通告报文用于通告该节点所支持的路径探测模式。也即是，本申请实施例定 义了一个新的类型(type)的报文，该报文用于指示图4所示的实施例中涉及的通告报文。
另外，由于不同厂家在同一路径探测模式下收集的探测数据的类型可能稍有不同，或者同一厂家不同批次的设备在同一路径探测模式下收集的探测数据的类型可能稍有不同，因此，在一种示例中，该通告报文还可以包括用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息。其中，用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息可以直接为探测数据的类型，还可以为命名空间(namespaceID)标识。当该用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息为命名空间标识时，控制节点可以根据该命名空间标识，从预先存储的命名空间标识和数据类型之间的对应关系中，确定出与通告报文的发送方所支持的路径探测模式对应的探测数据的类型。
需要说明的是，如果不同厂家同一路径探测模式下收集的探测数据的类型均相同的情况下，或者通信网络中的设备均来自同一厂家，且来自同一厂家的所有设备在同一路径探测模式下收集的探测数据的类型如果均相同的情况下，该通告报文可无需包括用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息。
另外需要说明的是，当命名空间标识不能用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型时，此时，就不能通过命名空间标识来确定与通告报文的发送方所支持的路径探测模式对应的探测数据的类型了。
另外，为了进一步保证各个节点能够成功根据OAM配置信息成功进行路径探测，通告报文还可以包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。该协议的类型可以为第四代互联网协议(internet protocol version4，IPv4)或者为第六代互联网协议(internet protocol version 6，IPv6)，或者还可以为基于IPv6的分段路由(基于IPv6的segment routing，SRv6)协议。此时，控制节点在确定探测路径时还需考虑该节点发送的通告报文中指示的协议的类型和当前进行路径探测的业务报文在封装携带有数据封装指令时所使用的协议的类型是否一致，在一致的情况下才会继续确定探测路径。
另外，为了兼容当前已有的通信协议，上述通告报文可以直接使用当前已有的通信协议中已经定义的报文，只需这些报文满足上述条件即可。
在一种示例中，在发送通告报文的至少两个节点中任一节点采用的通信协议为开放式最短路径优先(open shortest path first，OSPF)协议的情况下，通告报文为基于路由信息链路状态通告(routing information link-state advertisement，RI LSA)的报文。也即是，可以对OSPF协议下的通告报文中的一个RI LSA进行扩展，得到的报文即为本申请实施例提供的通告报文。
图5是本申请实施例提供的一种RI LSA的格式示意图。如图5所示，该RI LSA包括16比特(bit)的类型(type)字段、16比特的长度(length)字段、4比特的协议(protocol)字段、12比特的路径探测模式(iOAM type)字段、16比特的命名空间标识(namespaceID)字段、以及一个或多个子TLV(sub-TLV)。
其中，类型字段用于指示该RI LSA的类型为OAM能力通告报文。长度字段用于指示该RI LSA的长度。协议字段用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型。路径探测模式字段用于指示所支持的路径探测模式。命名空间标识 字段用于指示与所支持的路径探测模式所支持的探测数据的类型。一个或多个子TLV用于携带其他的信息。
在另一种示例中，在发送通告报文的至少两个节点中任一节点采用的通信协议为中间系统到-中间系统(Intermediate system to intermediate system，ISIS)协议的情况下，通告报文可以为基于TLV 242的报文。也即是，可以对ISIS协议下的通告报文中的一个TLV 242进行扩展，得到的报文即为本申请实施例提供的通告报文。
图6是本申请实施例提供的一种TLV 242的格式示意图。如图6所示，该TLV 242包括1字节的类型(type)字段、1字节的长度(length)字段、4比特的协议(protocol)字段、12比特的路径探测模式(iOAM type)字段、16比特的命名空间标识(namespaceID)字段、以及一个或多个子TLV(sub-TLV)。
图6所示的各个字段的功能和图5所示的各个字段的功能相同，在此不再一一解释说明。
在另一种示例中，在发送通告报文的至少两个节点中任一节点采用的通信协议为边界网关协议(border gateway protocol，BGP)的情况下，通告报文为基于不透明节点属性TLV(opaque Node attribute TLV)的报文。也即是，可以对BGP协议下的通告报文中的一个不透明节点属性TLV进行扩展，得到的报文即为本申请实施例提供的通告报文。
图7是本申请实施例提供的一种不透明节点属性TLV的格式示意图。如图7所示，该不透明节点属性TLV包括包括16比特(bit)的类型(type)字段、16比特的长度(length)字段、4比特的协议(protocol)字段、12比特的路径探测模式(iOAM type)字段、16比特的命名空间标识(namespaceID)字段、以及一个或多个子TLV(sub-TLV)。
图7所示的各个字段的功能和图5所示的各个字段的功能相同，在此同样不再一一解释说明。
需要说明的是，图5至图7仅仅用于举例说明本申请实施例提供的通告报文，并不构成对本申请实施例提供的通告报文的限定。
步骤402：控制节点根据需要进行的路径探测模式和至少两个节点发送的通告报文，确定探测路径。
基于步骤401可知，通告报文中包括用于指示通告报文的发送方所支持的路径探测模式的指示信息。因此，在一种示例中，步骤401的实现过程可以为：控制节点根据至少两个节点中支持所述需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点。
具体地，控制节点可以根据至少两个节点发送的通告报文，从至少两个节点中选择支持需要进行的路径探测模式的节点；根据选择的节点确定用于进行路径探测的头节点和尾节点，也即是，确定探测路径上的头节点和尾节点。
或者，也可以先通过相关技术中确定头节点的方式(比如将网络入口处的节点作为头节点)确定出一个节点，然后判断该节点是否支持需要进行的路径探测模式，若是，则将该节点确定为头节点。如果该节点不支持需要进行的路径探测模式，此时，在一种实现方式中，还可以确定数据流中位于之前确定节点的下一跳的节点，然后确定该节点是否能够作为头节点。尾节点的确定方式也可以参考这种实现方式。另外，也可以先通过相关技术中确定尾节点的方式(比如将网络出口处的节点作为尾节点)确定出一个节点，然后判断该节点是否支持需要进行的路径探测模式，若是，则将该节点确定为尾节点。如果该节点不支持需要进行的路径探测模式，此时，在一种实现方式中，还可以确定数据流中位于之前确定节点的上一 跳的节点，然后确定该节点是否能够作为尾节点。
其中，从选择的节点中确定出头节点和尾节点可以参考相关技术中确定头节点和尾节点的实现方式，在此不再详细说明。比如，可以将选择的节点中处于网络入口处的节点确定为头节点，将选择的节点中处于网络出口处的节点确定为尾节点。
此外，在确定出头节点或尾节点之后，如果探测路径上存在中间节点，控制节点还可以进一步根据至少两个节点中支持需要进行的路径探测模式的节点，继续确定探测路径上的一个或多个中间节点。此时，得到探测路径的实现方式可以为：先从选择的节点中确定出头节点和尾节点，然后根据确定出的头节点以及尾节点，确定出多个中间节点，从而得到探测路径。其中，根据确定出的头节点以及尾节点，确定出多个中间节点同样可以参考相关技术，在此不再详细解释说明。
另外，在通告报文还包括用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息的情况下，在步骤401中，控制节点还可以先根据需要进行的路径探测模式，确定需要收集的探测数据的类型；然后根据至少两个节点中支持需要进行的路径探测模式，且通告报文所指示的探测数据的类型和需要收集的探测数据的类型一致的节点，确定探测路径中的头节点和尾节点。具体地，控制节点在从至少两个节点中选择支持需要进行的路径探测模式的节点之后，可以从选择的节点中继续选择通告报文所指示的探测数据的类型和需要收集的探测数据的类型一致的节点；从而对继续选择节点，根据选择的节点确定用于进行路径探测的头节点和尾节点。
也即是，控制节点在确定出某个节点支持需要进行的路径探测模式的情况下，还需进一步确定该节点发送的通告报文所指示的探测数据的类型和需要收集的探测数据的类型一致时，此时才将该节点纳入确定探测路径的备选节点中。
另外，在通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的情况下，控制节点还可以先确定在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型；然后对于通告报文中指示的协议的类型和确定的协议的类型一致的节点，执行根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点的步骤。具体地，控制节点可以先从至少两个节点中选择通告报文中指示的协议的类型和确定的协议的类型一致的节点；对于选择的节点，再根据节点发送的通告报文，从已经选择的节点中选择支持需要进行的路径探测模式的节点，以通过上述方式确定出探测路径。
比如，在需要进行的路径探测的报文采用IPv6封装iOAM头的情况下，控制节点需要先从至少两个节点中选择通告报文中指示的协议的类型为IPv6的节点，然后再选择支持需要进行的路径探测模式的节点。
需要说明的是，上述选择协议的类型一致的节点和选择支持的需要进行的路径探测模式的节点不分先后顺序，只需最终选择节点能够满足这两个条件即可。
步骤403：控制节点向探测路径中的头节点和尾节点下发OAM配置信息。
示例地，控制节点向头节点下发的OAM配置信息包括为第一访问控制列表(access control list，ACL)配置指令，第一ACL配置指令包括待封装的报文的标识以及在报文中封装的具体内容；向尾节点下发的OAM配置信息包括第二ACL配置指令，第二ACL配置指令包括待解封装的报文的标识。
其中，待封装的报文的标识和待解封装的报文的标识为同一标识，该标识用于指示用于进行路径探测的报文的标识。比如，该标识可以为该报文的目的地址等。
示例地，在iOAM技术中，头节点在接收到OAM配置信息之后，如果接收到的业务报文的标识与第一ACL配置指令包括的待封装的报文的标识相同，则在该业务报文中封装上iOAM头，该iOAM头内携带数据收集指令，该数据收集指令是根据第一ACL配置指令中包括的在报文中封装的具体内容确定的。然后将封装有iOAM头的业务报文发送至下一跳节点。
尾节点在接收到OAM配置信息之后，如果接收到的业务报文的标识与第一ACL配置指令包括的待封装的报文的标识相同，则解封装该业务报文中的iOAM头，并将iOAM头中携带的信息进行上报。
另外，第一ACL配置指令包括的在报文中封装的具体内容取决于需要进行的路径探测模式。比如，在路径探测模式为iOAM追踪模式的情况下，该具体内容可以包括收发报文的接口灯信息。在路径探测模式为iOAM E2E模式的情况下，该具体内容可以收发的报文的报文序列号或收发报文的时间戳等信息。
此外，上述向头节点下发的OAM配置信息还可以包括为该头节点配置的标识和/或针对该头节点的收集探测数据使能指令，向尾节点下发的OAM配置信息同样还可以包括为该尾节点配置的标识和/或针对该尾节点的收集探测数据使能指令，在此不做具体限定，具体包括的内容可以根据当前的业务场景进行调整。
此外，控制节点除了向头节点和尾节点下发OAM配置信息之外，还可以向中间节点下发OAM配置信息。需要说明的是。本申请实施例不限定向中间节点下发OAM配置信息的具体内容以及向中间节点下发OAM配置信息的场景。比如，向中间节点下发的OAM配置可以包括为该中间节点配置的标识、和/或针对该中间节点的收集探测数据使能指令等。
在本申请实施例中，为了避免出现控制节点向某个节点下发OAM配置信息之后，该节点由于不支持当前需要进行的路径探测模式而无法成功根据OAM配置信息进行路径探测，通信网络中的各个节点可以预先向控制节点发送通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息，如此控制节点便可获知到通信网络中哪些节点能够支持当前需要进行的路径探测模式，此时，控制节点便可从能够支持当前需要进行的路径探测模式的节点中确定探测路径，这样向探测路径中的头节点和尾节点发送OAM配置信息之后，便可保证头节点和尾节点能够成功根据该OAM配置信息进行路径探测。
接下来对本申请实施例提供的通信网络中的各个节点的结构进行解释说明。
图8是本申请实施例提供的一种网络设备的结构示意图，该网络设备可以为上述任一实施例中通信网络中包括的多个节点中的任一节点。该网络设备800可以为交换机，路由器或者其他转发报文的网路设备。在该实施例中，该网络设备800包括：主控板810、接口板830和接口板840。多个接口板的情况下可以包括交换网板(图中未示出)，该交换网板用于完成各接口板(接口板也称为线卡或业务板)之间的数据交换。
主控板810用于完成系统管理、设备维护、协议处理等功能。接口板830和840用于提供各种业务接口(例如，POS接口、GE接口、ATM接口等)，并实现报文的转发。主控板810上主要有3类功能单元：系统管理控制单元、系统时钟单元和系统维护单元。主控板810、接口板830以及接口板840之间通过系统总线与系统背板相连实现互通。接口板830上包括一个或多个处理器831。处理器831用于对接口板进行控制管理并与主控板上的中央处理器 进行通信，以及用于报文的转发处理。接口板830上的存储器832用于存储转发表项，处理器831通过查找存储器832中存储的转发表项进行报文的转发。
所述接口板830包括一个或多个网络接口833用于接收上一跳节点发送的探测报文，并根据处理器831的指示向下一跳网络节点发送处理后的探测报文。具体实现过程这里不再逐一赘述。此外，在本申请实施例中，这一个或多个网络接口833还用于向控制节点发送步骤401中的通告报文，以使得控制节点能够通过图4中的步骤401至步骤403下发OAM配置信息。所述处理器831可以用于确定步骤401中的通告报文，该通告报文可以为图5至图7中任一所示的通告报文，处理器831的具体功能这里就不再逐一赘述。
可以理解，如图8所示，本实施例中包括多个接口板，采用分布式的转发机制，这种机制下，接口板840上的操作与所述接口板830的操作基本相似，为了简洁，不再赘述。此外，可以理解的是，图8中的接口板830中的处理器831和/或841可以是专用硬件或芯片，如网络处理器或者专用集成电路(application specific integrated circuit)来实现上述功能，这种实现方式即为通常所说的转发面采用专用硬件或芯片处理的方式。采用网络处理器这一专用硬件或芯片的具体实现方式可以参考下面图9所示的实施例。在另外的实施方式中，所述处理器831和/或841也可以采用通用的处理器，如通用的CPU来实现以上描述的功能。
此外，需要说明的是，主控板可能有一块或多块，有多块的时候可以包括主用主控板和备用主控板。接口板可能有一块或多块，该设备的数据处理能力越强，提供的接口板越多。多块接口板的情况下，该多块接口板之间可以通过一块或多块交换网板通信，有多块的时候可以共同实现负荷分担冗余备份。在集中式转发架构下，该设备可以不需要交换网板，接口板承担整个系统的业务数据的处理功能。在分布式转发架构下，该设备包括多块接口板，可以通过交换网板实现多块接口板之间的数据交换，提供大容量的数据交换和处理能力。所以，分布式架构的网络设备的数据接入和处理能力要大于集中式架构的设备。具体采用哪种架构，取决于具体的组网部署场景，此处不做任何限定。
具体的实施例中，存储器832可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其它类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only Memory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘或者其它磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器832可以是独立存在，通过通信总线与处理器831相连接。存储器832也可以和处理器831集成在一起。
其中，存储器832用于存储程序代码，并由处理器831来控制执行，以执行上述实施例所提供的路径探测方法。处理器831用于执行存储器832中存储的程序代码。程序代码中可以包括一个或多个软件模块。这一个或多个软件模块可以为下面图11或图12任一实施例中提供的软件模块。
具体实施例中，所述网络接口833，可以是使用任何收发器一类的装置，用于与其它设备或通信网络通信，如以太网，无线接入网(radio access networkRAN)，无线局域网(wireless local area networks，WLAN)等。
图9是本申请实施例提供的另一种网络设备的结构示意图，该网络设备可以为上述图任一实施例提供的通信网络中的多个节点中的第一节点。该网络设备900可以为交换机，路由器或者其他转发报文的网路设备。在该实施例中，该网络设备900包括：主控板910、接口板930、交换网板920和接口板940。主控板910用于完成系统管理、设备维护、协议处理等功能。交换网板920用于完成各接口板(接口板也称为线卡或业务板)之间的数据交换。接口板930和940用于提供各种业务接口(例如，POS接口、GE接口、ATM接口等)，并实现数据包的转发。控制平面由主控板910的各管控单元及接口板930和940上的管控单元等构成。主控板910上主要有3类功能单元：系统管理控制单元、系统时钟单元和系统维护单元。主控板910、接口板930和940，以及交换网板920之间通过系统总线与系统背板相连实现互通。接口板930上的中央处理器931用于对接口板进行控制管理并与主控板上的中央处理器进行通信。接口板930上的转发表项存储器934用于存储转发表项，网络处理器932通过查找转发表项存储器934中存储的转发表项进行报文的转发。
所述接口板930的物理接口卡933用于接收上一跳节点发送的探测报文。具体实现过程这里不再逐一赘述。
所述网络处理器932用于确定步骤401中的通告报文，该通告报文可以为图5至图7中任一所示的通告报文，网络处理器932的具体功能这里不再逐一赘述。
然后，添加了探测数据的探测报文通过所述物理接口卡933向该第一节点的下一跳节点发送。此外，在本申请实施例中，所述物理接口卡933还用于向控制节点发送步骤401中的通告报文，以使得控制节点能够通过图4中的步骤401至步骤403下发OAM配置信息，具体实现过程这里不再逐一赘述。
可以理解，如图9所示，本实施例中包括多个接口板，采用分布式的转发机制，这种机制下，接口板940上的操作与所述接口板930的操作基本相似，为了简洁，不再赘述。此外，如上所述，图9中的网络处理器932以及942的功能可以用专用集成电路(application specific integrated circuit)替换来实现。
此外，需要说明的是，主控板可能有一块或多块，有多块的时候可以包括主用主控板和备用主控板。接口板可能有一块或多块，该设备的数据处理能力越强，提供的接口板越多。接口板上的物理接口卡也可以有一块或多块。交换网板可能没有，也可能有一块或多块，有多块的时候可以共同实现负荷分担冗余备份。在集中式转发架构下，该设备可以不需要交换网板，接口板承担整个系统的业务数据的处理功能。在分布式转发架构下，该设备可以有至少一块交换网板，通过交换网板实现多块接口板之间的数据交换，提供大容量的数据交换和处理能力。所以，分布式架构的网络设备的数据接入和处理能力要大于集中式架构的设备。具体采用哪种架构，取决于具体的组网部署场景，此处不做任何限定。
图10是本申请实施例提供的一种上述图9所示网络设备中的接口板1000的结构示意图，该接口板1000所在的网络设备可以为上述任一实施例中的通信网络包括的多个节点中的第一节点。该接口板1000可以包括物理接口卡(physical interface card，PIC)1030，网络处理器(network processor,NP)1010,以及流量管理模块(traffic management)1020。
其中，PIC：物理接口卡(physical interface card)，用于实现物理层的对接功能，原始的 流量由此进入网络设备的接口板，以及处理后的报文从该PIC卡发出。
网络处理器NP1010用于实现报文的转发处理。具体而言，上行报文的处理包括：报文入接口的处理，时间戳的获取，上行流分类，转发表查找，测量信息封装，报文复制处理；下行报文的处理：转发表查找，下行流分类，时间戳获取，测量信息封装，出接口处理等等。
流量管理TM，用于实现QoS、线速转发、大容量缓存，队列管理等功能。具体而言，上行流量管理包括：上行Qos处理(如拥塞管理和队列调度等)以及切片处理；下行流量管理包括：组包处理，多播复制，以及下行Qos处理(如拥塞管理和队列调度等)。
可以理解的是，若网络设备有多个接口板1000的情况下，多个接口板1000之间可以通过交换网1040通信。
需要说明的是，图10仅示出了NP内部的示意性处理流程或模块，具体实现中各模块的处理顺序不限于此，而且实际应用中可以根据需要部署其他模块或者处理流程。本申请实施例对比不做限制。
图11是本申请实施例提供的一种控制节点的结构示意图。该控制节点为通信网络中的控制节点，且该通信网络还包括多个节点，如图11所示，该控制节点1100包括：
获取模块1101，用于分别获取多个节点中至少两个节点发送的通告报文，通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息。具体实现过程可以参考图4实施例中的步骤401。
确定模块1102，用于根据需要进行的路径探测模式和至少两个节点发送的通告报文，确定探测路径。具体实现过程可以参考图4实施例中的步骤402。
下发模块1103，用于向探测路径中的头节点和尾节点下发OAM配置信息。具体实现过程可以参考图4实施例中的步骤403。
可选地，确定模块，具体用于：
根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点。
可选地，确定模块，还具体用于：
确定探测路径中的一个或多个中间节点。
可选地，通告报文还包括用于指示与通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息；
确定模块，具体用于：
确定需要收集的探测数据的类型；
根据至少两个节点中支持需要进行的路径探测模式，且通告报文所指示的探测数据的类型和需要收集的探测数据的类型一致的节点，确定探测路径中的头节点和尾节点。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息；
确定模块，具体用于：
确定在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型；
对于通告报文中指示的协议的类型和确定的协议的类型一致的节点，执行根据至少两个节点中支持需要进行的路径探测模式的节点，确定探测路径中的头节点和尾节点的步骤。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在至少两个节点中任一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，该通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在至少两个节点中任一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，该通告报文为基于TLV 242的通告报文。
可选地，在至少两个节点中任一节点采用的通信协议为边界网关协议BGP的情况下，该通告报文为基于不透明节点属性TLV的通告报文。
可选地，向头节点下发的OAM配置信息包括第一访问控制列表ACL配置指令，第一ACL配置指令包括待封装的报文的标识以及在报文中封装的具体内容；
向尾节点下发的OAM配置信息包括第二ACL配置指令，第二ACL配置指令包括待解封装的报文的标识。
在本申请实施例中，为了避免出现控制节点向某个节点下发OAM配置信息之后，该节点由于不支持当前需要进行的路径探测模式而无法成功根据OAM配置信息进行路径探测，通信网络中的各个节点可以预先向控制节点发送通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息，如此控制节点便可获知到通信网络中哪些节点能够支持当前需要进行的路径探测模式，此时，控制节点便可从能够支持当前需要进行的路径探测模式的节点中确定探测路径，这样向探测路径中的头节点和尾节点发送OAM配置信息之后，便可保证头节点和尾节点能够成功根据该OAM配置信息进行路径探测。
需要说明的是：上述实施例提供的控制节点在下发OAM配置信息时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的控制节点与下发OAM配置信息的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
图12是本申请实施例提供的一种第一节点的结构示意图。通信网络包括控制节点和多个节点，第一节点为多个节点中的一个。如图12所示，该第一节点1200包括：
发送模块1201，用于向控制节点发送通告报文，通告报文包括用于指示第一节点支持的路径探测模式的指示信息，以使得所述控制节点根据所述的通告报文确定探测路径。其中，第一节点发送的通告报文的具体实现方式可以参考图4实施例中步骤401中关于通告报文的详细说明。
可选地，通告报文还包括用于指示与第一节点所支持的路径探测模式对应的探测数据的类型的指示信息。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在第一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，该通告报文为基于路由信息链路状态通告的RI LSA报文。
可选地，在第一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，该通告报文为基于TLV 242的报文。
可选地，在第一节点采用的通信协议为边界网关协议BGP的情况下，该通告报文为基于不透明节点属性TLV的报文。
在本申请实施例中，为了避免出现控制节点向某个节点下发OAM配置信息之后，该节点由于不支持当前需要进行的路径探测模式而无法成功根据OAM配置信息进行路径探测，通信网络中的各个节点可以预先向控制节点发送通告报文，该通告报文包括用于指示通告报文的发送方所支持的路径探测模式的指示信息，如此控制节点便可获知到通信网络中哪些节点能够支持当前需要进行的路径探测模式，此时，控制节点便可从能够支持当前需要进行的路径探测模式的节点中确定探测路径，这样向探测路径中的头节点和尾节点发送OAM配置信息之后，便可保证头节点和尾节点能够成功根据该OAM配置信息进行路径探测。
需要说明的是：上述实施例提供的第一节点在发送通告报文时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的第一节点与下发OAM配置信息的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
此外，本申请实施例还提供了一种下发OAM配置信息的系统，该系统包括控制节点和多个节点。其中，多个节点中的多个节点中第一节点，用于向控制节点发送通告报文，通告报文包括用于指示第一节点支持的路径探测模式的指示信息；控制节点，用于接收第一节点发送的通告报文。以通过上述图4所示的实施例下发配置信息。
通告报文还包括用于指示与第一节点所支持的路径探测模式对应的探测数据的类型的指示信息。
可选地，通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。
可选地，通告报文还包括用于指示通告报文的类型为OAM能力通告报文的指示信息。
可选地，在第一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，该通告报文为基于路由信息链路状态通告RI LSA的报文。
可选地，在第一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，该通告报文为基于TLV 242的报文。
可选地，在第一节点采用的通信协议为边界网关协议BGP的情况下，该通告报文为基于不透明节点属性TLV的柏爱文。
关于控制节点如何根据通告报文下发OAM配置信息的过程已在上述实施例中进行了详细说明，在此就不再赘述。
图13是本发明实施例提供的一种网络设备的结构示意图。图4实施例中的多个节点中任一节点均可以通过图13所示的网络设备1300来实现，此时，该网络设备1300可以为交换机，路由器或者其他转发报文的网路设备。另外，图4实施例中的控制节点同样可以通过图13所示的网络设备1300来实现，此时该网络设备1300的具体功能可以参考前述图4实施例中的控制节点的具体实现方式，在此不再赘述。参见图13，该网络设备包括至少一个处理器1301，通信总线1302、存储器1303以及至少一个通信接口1304。
处理器1301可以是一个通用中央处理器(central processing unit，CPU)、特定应用集成电路(application-specific integrated circuit，ASIC)或一个或多个用于控制本申请方案程序执行的集成电路。当该网络设备作为通信网络多个的节点中的任一节点时，处理器1301用于确定图4中的步骤401中的通告报文。当该网络设备作为通信网络中的控制节点时，处理器1301用于实现图4中的步骤401至步骤403中的任一方法。具体功能在此不再赘述。
通信总线1302可包括一通路，在上述组件之间传送信息。
存储器1303可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其它类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only Memory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘或者其它磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器1303可以是独立存在，通过通信总线1302与处理器1301相连接。存储器1303也可以和处理器1301集成在一起。
其中，存储器1303用于存储执行本申请方案的程序代码，并由处理器1301来控制执行。处理器1301用于执行存储器1303中存储的程序代码。程序代码中可以包括一个或多个软件模块。图4实施例中的控制节点或多个节点中任一节点均可以通过处理器1301以及存储器1303中的程序代码中的一个或多个软件模块，来确定用于开发应用的数据。这一个或多个软件模块可以为图11或图12任一实施例中提供的软件模块。
通信接口1304，使用任何收发器一类的装置，用于与其它设备或通信网络通信，如以太网，无线接入网(radio access networkRAN)，无线局域网(wireless local area networks，WLAN)等。当该网络设备作为通信网络多个的节点中的任一节点时，通信接口1304用于向控制节点发送图4中的步骤401中的通告报文。当该网络设备作为通信网络中的控制节点时，通信接口1304用于接收图4中的步骤401中的通告报文。具体功能在此不再赘述。
在具体实现中，作为一种实施例，网络设备可以包括多个处理器，例如图13中所示的处理器1301和处理器1305。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
上述的网络设备可以是一个通用网络设备或者是一个专用网络设备。在具体实现中，网络设备可以是台式机、便携式电脑、网络服务器、掌上电脑(personal digital assistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备或者嵌入式设备。本申请实施例不限定网络设备的类型。
可以理解的是，在图13所示网络设备为上述方法实施例中的任一的第一节点时，本实施例也可以基于通用的物理服务器结合网络功能虚拟化NFV技术实现的虚拟第一节点，所述虚拟第一节点为虚拟路由器，而且可以虚拟出第二，三，N个节点(根据实际需要)。所述虚拟第一节点可以是运行有用于提供发送消息功能的程序的虚拟机(英文：Virtual Machine，VM)，所述虚拟机部署在硬件设备上(例如，物理服务器)。虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。本领域技术人员通过 阅读本申请即可结合NFV技术在通用物理服务器上虚拟出具有上述功能的多个第一节点。此处不再赘述。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如：同轴电缆、光纤、数据用户线(digital subscriber line，DSL))或无线(例如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如：软盘、硬盘、磁带)、光介质(例如：数字通用光盘(digital versatile disc，DVD))、或者半导体介质(例如：固态硬盘(solid state disk，SSD))等。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述为本申请提供的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (22)

  1. 一种下发OAM配置信息的方法，应用于通信网络中的控制节点，所述通信网络还包括多个节点，其特征在于，所述方法包括：
    所述控制节点分别获取所述多个节点中至少两个节点发送的通告报文，所述通告报文包括用于指示所述通告报文的发送方所支持的路径探测模式的指示信息；
    所述控制节点根据需要进行的路径探测模式和所述至少两个节点发送的通告报文，确定探测路径；
    所述控制节点向所述探测路径中的头节点和尾节点下发OAM配置信息。
  2. 如权利要求1所述的方法，其特征在于，所述控制节点根据需要进行的路径探测模式和所述至少两个节点发送的通告报文，确定探测路径，包括：
    根据所述至少两个节点中支持所述需要进行的路径探测模式的节点，确定所述探测路径中的头节点和尾节点。
  3. 如权利要求2所述的方法，其特征在于，所述方法进一步包括：所述控制节点根据所述至少两个节点中支持所述需要进行的路径探测模式的节点，确定所述探测路径中的一个或多个中间节点；以及
    所述控制节点向所述探测路径中的一个或多个中间节点下发OAM配置信息。
  4. 如权利要求2或3所述的方法，其特征在于，所述通告报文还包括用于指示与所述通告报文的发送方所支持的路径探测模式对应的探测数据的类型的指示信息；
    所述根据所述至少两个节点中支持所述需要进行的路径探测模式的节点，确定所述探测路径中的头节点和尾节点，包括：
    确定需要收集的探测数据的类型；
    根据所述至少两个节点中支持所述需要进行的路径探测模式，且通告报文所指示的探测数据的类型和所述需要收集的探测数据的类型一致的节点，确定所述探测路径中的头节点和尾节点。
  5. 如权利要求2-4任一所述的方法，其特征在于，所述通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息；
    所述根据所述至少两个节点中支持所述需要进行的路径探测模式的节点，确定所述探测路径中的头节点和尾节点之前，还包括：
    确定在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型；
    对于通告报文中指示的协议的类型和确定的协议的类型一致的节点，执行所述根据所述至少两个节点中支持所述需要进行的路径探测模式的节点，确定所述探测路径中的头节点和尾节点的步骤。
  6. 如权利要求1-5任一所述的方法，其特征在于，所述通告报文还包括用于指示所述通告报文的类型为OAM能力通告报文的指示信息。
  7. 如权利要求1-6任一所述的方法，其特征在于，在所述至少两个节点中任一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，所述通告报文为基于路由信息链路状态通告RI LSA的报文。
  8. 如权利要求1-6任一所述的方法，其特征在于，在所述至少两个节点中任一节点采用 的通信协议为中间系统到-中间系统ISIS协议的情况下，所述通告报文为基于TLV 242的报文。
  9. 如权利要求1-6任一所述的方法，其特征在于，在所述至少两个节点中任一节点采用的通信协议为边界网关协议BGP的情况下，所述通告报文为基于不透明节点属性TLV的报文。
  10. 如权利要求1-9任一所述的方法，其特征在于，
    向所述头节点下发的OAM配置信息包括第一访问控制列表ACL配置指令，所述第一ACL配置指令包括待封装的报文的标识以及在所述报文中封装的具体内容；
    向所述尾节点下发的OAM配置信息包括第二ACL配置指令，所述第二ACL配置指令包括待解封装的报文的标识。
  11. 一种下发OAM配置信息的方法，应用于通信网络中的第一节点，所述通信网络包括控制节点和多个节点，所述第一节点为所述多个节点中的一个；
    其特征在于，所述方法包括：
    所述第一节点向所述控制节点发送通告报文，所述通告报文包括用于指示所述第一节点支持的路径探测模式的指示信息，以使得所述控制节点根据所述通告报文确定探测路径。
  12. 如权利要求11所述的方法，其特征在于，所述通告报文还包括用于指示与所述第一节点所支持的路径探测模式对应的探测数据的类型的指示信息。
  13. 如权利要求11或12所述的方法，其特征在于，所述通告报文还包括用于指示在进行路径探测的报文中封装携带数据探测指令的报文头时所使用的协议的类型的指示信息。
  14. 如权利要求11-13任一所述的方法，其特征在于，所述通告报文还包括用于指示所述通告报文的类型为OAM能力通告报文的指示信息。
  15. 如权利要求11-14任一所述的方法，其特征在于，在所述第一节点采用的通信协议为开放式最短路径优先OSPF协议的情况下，所述通告报文为基于路由信息链路状态通告RILSA的报文。
  16. 如权利要求11-14任一所述的方法，其特征在于，在所述第一节点采用的通信协议为中间系统到-中间系统ISIS协议的情况下，所述通告报文为基于TLV 242的报文。
  17. 如权利要求11-14任一所述的方法，其特征在于，在所述第一节点采用的通信协议为边界网关协议BGP的情况下，所述通告报文为基于不透明节点属性TLV的报文。
  18. 一种通信网络中的控制节点，其特征在于，所述控制节点包括存储器和处理器；
    所述存储器用于存储计算机程序；
    所述处理器用于执行所述存储器中存储的计算机程序以执行权利要求1-10任一项所述的方法。
  19. 一种通信网络中的第一节点，所述通信网络包括控制节点和多个节点，所述第一节点为所述多个节点中的一个，其特征在于，所述第一节点包括存储器和处理器；
    所述存储器用于存储计算机程序；
    所述处理器用于执行所述存储器中存储的计算机程序以执行权利要求11-17任一项所述的方法。
  20. 一种芯片，所述芯片设置在通信网络中的控制节点中，其特征在于，所述芯片包括处理器和接口电路；
    所述接口电路用于接收指令并传输至所述处理器；
    所述处理器用于执行权利要求1-10任意一项所述的方法。
  21. 一种芯片，所述芯片设置在通信网络中的第一节点中，所述通信网络包括控制节点和多个节点，所述第一节点为所述多个节点中的一个，其特征在于，所述芯片包括处理器和接口电路；
    所述接口电路用于接收指令并传输至所述处理器；
    所述处理器用于执行权利要求11-17任意一项所述的方法。
  22. 一种下发OAM配置信息的系统，所述系统包括控制节点和多个节点；其特征在于，
    所述多个节点中第一节点，用于向所述控制节点发送通告报文，所述通告报文包括用于指示所述第一节点支持的路径探测模式的指示信息；
    所述控制节点，用于接收所述第一节点发送的通告报文，以使得所述控制节点根据所述的通告报文确定探测路径。
PCT/CN2020/105085 2019-11-19 2020-07-28 下发oam配置信息的方法及控制节点 WO2021098271A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20889871.8A EP4047888B1 (en) 2019-11-19 2020-07-28 Method for issuing oam configuration information and control node
US17/746,078 US20220278925A1 (en) 2019-11-19 2022-05-17 Method for Delivering OAM Configuration Information and Control Node

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201911135733.5A CN112910773B (zh) 2019-11-19 2019-11-19 下发oam配置信息的方法及控制节点
CN201911135733.5 2019-11-19

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/746,078 Continuation US20220278925A1 (en) 2019-11-19 2022-05-17 Method for Delivering OAM Configuration Information and Control Node

Publications (1)

Publication Number Publication Date
WO2021098271A1 true WO2021098271A1 (zh) 2021-05-27

Family

ID=75980245

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/105085 WO2021098271A1 (zh) 2019-11-19 2020-07-28 下发oam配置信息的方法及控制节点

Country Status (4)

Country Link
US (1) US20220278925A1 (zh)
EP (1) EP4047888B1 (zh)
CN (1) CN112910773B (zh)
WO (1) WO2021098271A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114257504A (zh) * 2021-12-15 2022-03-29 烽火通信科技股份有限公司 业务场景切换方法及系统

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113873548A (zh) * 2021-09-03 2021-12-31 中盈优创资讯科技有限公司 一种白盒设备一键开局方法及装置
KR20240022456A (ko) * 2021-09-30 2024-02-20 뉴 에이치3씨 테크놀로지스 코., 엘티디. 메시지 처리 방법, 디바이스, 네트워크 기기 및 매체
CN114301813A (zh) * 2021-12-24 2022-04-08 锐捷网络股份有限公司 一种ping检测的时延测量方法及装置
CN115378816B (zh) * 2022-08-02 2024-02-23 深信服科技股份有限公司 网络配置检测方法、装置及存储介质
CN117834342A (zh) * 2022-09-29 2024-04-05 中兴通讯股份有限公司 虚拟化隧道网络的ioam封装的实现方法及装置
CN117728927B (zh) * 2024-02-18 2024-05-10 南京风启科技有限公司 一种基于域标识的变长报文处理时延探测方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101945018A (zh) * 2010-08-30 2011-01-12 北京星网锐捷网络技术有限公司 节点探测方法、装置和网络中心节点
CN108737127A (zh) * 2017-04-13 2018-11-02 中兴通讯股份有限公司 一种信息通告方法及装置
CN108964943A (zh) * 2017-05-18 2018-12-07 中兴通讯股份有限公司 一种实现ioam封装的方法及装置
US20190182124A1 (en) * 2017-12-07 2019-06-13 Cisco Technology, Inc. Optimizing source routing using machine learning

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010020151A1 (zh) * 2008-08-18 2010-02-25 成都市华为赛门铁克科技有限公司 报文处理方法、装置和系统
US9025951B2 (en) * 2010-10-18 2015-05-05 Calix, Inc. Provisioning network devices in Ethernet-based access networks
CN105790988B (zh) * 2014-12-23 2020-01-14 中兴通讯股份有限公司 操作维护管理功能的实现方法及装置
CN106302351B (zh) * 2015-06-03 2019-10-15 华为技术有限公司 收集访问控制列表的方法、装置及系统
US9967184B2 (en) * 2015-07-02 2018-05-08 Telefonaktiebolaget Lm Ericsson (Publ) Using border gateway protocol to expose maximum segment identifier depth to an external application
US9992056B2 (en) * 2015-10-20 2018-06-05 Cisco Technology, Inc. Triggered in-band operations, administration, and maintenance in a network environment
CN109981450B (zh) * 2017-12-28 2021-06-15 中国电信股份有限公司 路径连通维护方法、装置和系统
US10887230B2 (en) * 2018-02-27 2021-01-05 Cisco Technology, Inc. In-situ operations, administration, and management (IOAM) and network event correlation for internet of things (IOT)
US11469995B2 (en) * 2018-06-14 2022-10-11 Nokia Solutions And Networks Oy Flow-specific fast rerouting of source routed packets
CN111327445B (zh) * 2018-12-17 2023-09-12 中兴通讯股份有限公司 报文采样方法及解封装方法、节点、系统及存储介质
CN109861913B (zh) * 2018-12-25 2020-03-20 华为技术有限公司 一种跨内部网关协议的前缀标识通告方法和装置
CN110166320B (zh) * 2019-05-27 2022-06-21 苏州盛科通信股份有限公司 基于OpenFlow交换机的MPLS-TP OAM实现方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101945018A (zh) * 2010-08-30 2011-01-12 北京星网锐捷网络技术有限公司 节点探测方法、装置和网络中心节点
CN108737127A (zh) * 2017-04-13 2018-11-02 中兴通讯股份有限公司 一种信息通告方法及装置
CN108964943A (zh) * 2017-05-18 2018-12-07 中兴通讯股份有限公司 一种实现ioam封装的方法及装置
US20190182124A1 (en) * 2017-12-07 2019-06-13 Cisco Technology, Inc. Optimizing source routing using machine learning

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4047888A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114257504A (zh) * 2021-12-15 2022-03-29 烽火通信科技股份有限公司 业务场景切换方法及系统
CN114257504B (zh) * 2021-12-15 2023-05-23 烽火通信科技股份有限公司 业务场景切换方法及系统

Also Published As

Publication number Publication date
US20220278925A1 (en) 2022-09-01
EP4047888A4 (en) 2022-12-21
CN112910773A (zh) 2021-06-04
EP4047888B1 (en) 2024-10-30
EP4047888A1 (en) 2022-08-24
CN112910773B (zh) 2024-07-05

Similar Documents

Publication Publication Date Title
WO2021098271A1 (zh) 下发oam配置信息的方法及控制节点
WO2021047668A1 (zh) 路径探测方法、装置及计算机存储介质
WO2021135468A1 (zh) 段标识的确定方法和设备
WO2021164258A1 (zh) 生成转发表项的方法、发送报文的方法、网络设备及系统
EP4239973A1 (en) Packet sending method, device, and system
WO2022012489A1 (zh) 一种能力通告方法及相关设备
EP4329248A1 (en) Packet forwarding method and apparatus, network device, and storage medium
WO2021083228A1 (zh) 报文转发方法、装置及计算机存储介质
JP2024504466A (ja) パケット転送方法、パケット処理方法、およびデバイス
WO2020029928A1 (zh) Bgp会话建立、发送接口地址和别名的方法及网络设备
WO2023011047A1 (zh) 一种处理方法及装置
WO2022257854A1 (zh) 一种报文发布方法、转发路径处理方法及装置
WO2021218352A1 (zh) 流量监控方法、相关设备及系统
JP2024524833A (ja) メッセージ処理方法、装置、ネットワークデバイス及び媒体
CN115473765A (zh) 报文传输方法、设备及系统
CN113595915A (zh) 转发报文的方法及相关设备
US20240333824A1 (en) Service Processing Method, Apparatus, and System
JP7273130B2 (ja) 通信方法および装置
WO2022194193A1 (zh) 用于获取路径的方法和装置
WO2024001733A1 (zh) 报文传输方法、装置及系统
WO2022143572A1 (zh) 一种报文处理方法及相关设备
CN115150320A (zh) 报文传输方法、装置及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20889871

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020889871

Country of ref document: EP

Effective date: 20220520

NENP Non-entry into the national phase

Ref country code: DE