CN116489238A - Message sending method, equipment and system for determining link state - Google Patents

Message sending method, equipment and system for determining link state Download PDF

Info

Publication number
CN116489238A
CN116489238A CN202210042399.4A CN202210042399A CN116489238A CN 116489238 A CN116489238 A CN 116489238A CN 202210042399 A CN202210042399 A CN 202210042399A CN 116489238 A CN116489238 A CN 116489238A
Authority
CN
China
Prior art keywords
link state
tlv
link
message
unidirectional
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202210042399.4A
Other languages
Chinese (zh)
Inventor
王立伟
徐国其
刘国权
李臣习
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202210042399.4A priority Critical patent/CN116489238A/en
Priority to PCT/CN2022/140666 priority patent/WO2023134416A1/en
Publication of CN116489238A publication Critical patent/CN116489238A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/70Routing based on monitoring results

Abstract

The application discloses a message forwarding method, a method, equipment and a system for determining a link state. Wherein the first identification is used to indicate a first neighbor device of the first device. Based on the first identifier, the device that obtains the link state message can determine a specific link corresponding to the link state indicated by the link state message. The first device sends a link state message to the second device. The second device is a second neighbor device of the first device. The second device can determine that the link state indicated by the link state message is the link state of the link between the third device and the first neighbor device based on the first identifier included in the acquired link state message. The second device can determine a specific link corresponding to the link state, so that a path can be calculated based on the acquired link state, or the link state can be monitored.

Description

Message sending method, equipment and system for determining link state
Technical Field
The present invention relates to the field of communications, and in particular, to a method for sending a message, and a method, device, and system for determining a link state.
Background
In order to calculate paths in a network or to monitor the status of links in a network, it is often necessary to obtain the link status of links between network devices. The network device detects the link state of the link between the network device and the neighbor device by using the link detection method, and sends a link state message carrying the link state to the neighbor device so that the neighbor device can acquire the link state.
However, after receiving the link state message, the neighbor device of the network device cannot determine the link corresponding to the link state included in the link state message. This may result in the neighbor devices of the network device not being able to calculate a path or monitor the link state using the link state included in the link state message.
Disclosure of Invention
The application provides a message sending method, a method, equipment and a system for determining a link state, wherein equipment for acquiring the link state message can determine a link corresponding to the link state based on the link state message, so that path calculation or link state monitoring can be performed based on the link state.
In a first aspect, the present application provides a method for sending a message, where the method for sending a message is applied to a first device. In the message sending method, a first device generates a link state message including a first identifier and a second identifier. The first identification is used to indicate a first neighbor device of the first device. The first neighbor device is an endpoint device of the link that performs link state detection. The second identification is used to indicate the designated router. The designated router is a logic device and is used for constructing a network topology of a network where the first device is located. The first device sends a link state message to a second device, wherein the second device is a second neighbor device of the first device. The link state message includes a first identification indicating a first neighbor device. The second device can determine that one end of the link corresponding to the link state is the first neighbor device according to the first identifier carried by the link state message, and then determine the link corresponding to the link state.
In one possible implementation, the designated router comprises a designated intermediate system DIS defined by intermediate system-to-intermediate system ISIS.
In one possible implementation, the designated router includes an open shortest path first, OSPF, defined designated router DR.
In one possible implementation, the second device is an IGP neighbor of the first device. Correspondingly, the link state message sent by the first device is a link state protocol data unit (LSP) message.
In one possible implementation, the second device is an IGP neighbor of the first device. Correspondingly, the link state message sent by the first device is a link state advertisement LSA message.
In one possible implementation, the second device is a border gateway protocol BGP neighbor of the first device. Correspondingly, the link state message is a border gateway protocol-link state BGP-LS message.
In one possible implementation, the BGP-LS message also includes a third identifier. The third identifier is used for indicating equipment for detecting the link state indicated by the link state message.
In one possible implementation, the first identifier is a System identifier System ID of the first neighbor device, or a Router ID. As an example, when the link state packet is a link state protocol data unit LSP packet, the first identifier is a System ID. As another example, when the link state message is a link state advertisement LSA message, the first identifier is a Router ID. As yet another example, the link state message is a border gateway protocol-link state BGP-LS message and the first identifier is a System ID or Router ID.
In one possible implementation, the link state message includes a type length value TLV, the TLV carrying the first identity.
In one possible implementation, the TLV is one or more of a minimum/maximum one-way link delay Min/Max Unidirectional Link Delay Sub-TLV, one-way link delay Unidirectional Link Delay Sub-TLV, one-way delay variation Unidirectional Delay Variation Sub-TLV, one-way link loss Unidirectional Link Loss Sub-TLV, one-way residual bandwidth Unidirectional Residual Bandwidth Sub-TLV, one-way available bandwidth Unidirectional Available Bandwidth Sub-TLV, one-way real-world bandwidth Unidirectional Utilized Bandwidth Sub-TLV.
In a second aspect, the present application provides a method of determining a link state, the method being applied to a second device. In the method, a second device receives a link state message including a first identification. The first identification is used to indicate a first neighbor device of the first device. The first device is a device for generating and transmitting a link message. The second device is a second neighbor device of the first device. The second device can determine that one end of the link corresponding to the link state is a first neighbor device of the first device according to the first identifier, so that the link state of the link between the third device and the first neighbor device is determined. Thus, based on the first identifier included in the link state message, the second device can determine the link corresponding to the link state.
In one possible implementation, the second device is an interior gateway protocol IGP neighbor device of the first device.
In one possible implementation, the link state message is a link state protocol data unit LSP message, or the link state message is a link state advertisement LSA message.
In one possible implementation, the first neighbor device of the first device is the second device.
In one possible implementation, the second device is a border gateway protocol BGP neighbor device of the first device.
In one possible implementation, the link state message is a border gateway protocol-link state BGP-LS message.
In one possible implementation, the third device is the first device.
In one possible implementation, the third device is a third neighbor device of the first device.
In a possible implementation manner, the link state message further includes a third identifier, where the third identifier corresponds to the first identifier, and the third identifier is used to indicate the third device. The second device can determine that the other end of the link corresponding to the link state is the third device based on the third identifier.
In one possible implementation, the method further includes:
the second device calculates a path based on the link state.
In one possible implementation, the method further includes:
the second device sends link state information to the control device, where the link state information is used to indicate the link state.
In one possible implementation, the first identifier is a System identifier System ID of the neighbor device, or a Router ID. As an example, when the link state packet is a link state protocol data unit LSP packet, the first identifier is a System ID. As another example, when the link state message is a link state advertisement LSA message, the first identifier is a Router ID. As yet another example, the link state message is a border gateway protocol-link state BGP-LS message and the first identifier is a System ID or Router ID.
In one possible implementation, the link state message includes a type length value TLV, which carries the identification.
In one possible implementation, the TLV is one or more of a minimum/maximum one-way link delay Min/Max Unidirectional Link Delay Sub-TLV, one-way link delay Unidirectional Link Delay Sub-TLV, one-way delay variation Unidirectional Delay Variation Sub-TLV, one-way link loss Unidirectional Link Loss Sub-TLV, one-way residual bandwidth Unidirectional Residual Bandwidth Sub-TLV, one-way available bandwidth Unidirectional Available Bandwidth Sub-TLV, one-way real-world bandwidth Unidirectional Utilized Bandwidth Sub-TLV.
In a third aspect, the present application provides an apparatus for sending a message, where the apparatus is applied to a first apparatus, and the apparatus includes:
the processing unit is used for generating a link state message, wherein the link state message comprises a first identifier and a second identifier, the first identifier is used for indicating first neighbor equipment of the first equipment, and the second identifier is used for indicating a designated router;
and the receiving and transmitting unit is used for transmitting the link state message to the second equipment, wherein the second equipment is second neighbor equipment of the first equipment.
In one possible implementation, the designated router comprises a designated intermediate system DIS defined by intermediate system-to-intermediate system ISIS.
In one possible implementation, the designated router includes an open shortest path first, OSPF, defined designated router DR.
In one possible implementation, the link state message is a link state protocol data unit LSP message and the second device is an interior gateway protocol IGP neighbor of the first device.
In one possible implementation, the link state message is a link state advertisement LSA message and the second device is an IGP neighbor of the first device.
In one possible implementation, the link state message is a border gateway protocol-link state BGP-LS message and the second device is a border gateway protocol BGP neighbor of the first device.
In a possible implementation manner, the BGP-LS message further includes a third identifier, where the third identifier is used to indicate a device that detects a link state indicated by the link state message.
In one possible implementation, the first identifier is a System identifier System ID of the first neighbor device, or a Router ID.
In one possible implementation, the link state message includes a type length value TLV, the TLV carrying the first identity.
In one possible implementation, the TLV is one or more of a minimum/maximum one-way link delay Min/Max Unidirectional Link Delay Sub-TLV, one-way link delay Unidirectional Link Delay Sub-TLV, one-way delay variation Unidirectional Delay Variation Sub-TLV, one-way link loss Unidirectional Link Loss Sub-TLV, one-way residual bandwidth Unidirectional Residual Bandwidth Sub-TLV, one-way available bandwidth Unidirectional Available Bandwidth Sub-TLV, one-way real-world bandwidth Unidirectional Utilized Bandwidth Sub-TLV.
In a fourth aspect, the present application provides an apparatus for determining a link state, the apparatus being applied to a second apparatus, the apparatus comprising:
the receiving and transmitting unit is used for receiving a link state message, wherein the link state message comprises a first identifier, the first identifier is used for indicating first neighbor equipment of first equipment, the first equipment is used for generating and transmitting the link state message, and the second equipment is second neighbor equipment of the first equipment;
and the processing unit is used for determining the link state of the link between the third equipment and the first neighbor equipment according to the first identifier, wherein the third equipment is equipment for detecting and obtaining the link state.
In one possible implementation, the second device is an interior gateway protocol IGP neighbor device of the first device.
In one possible implementation, the link state packet is a link state protocol data unit LSP packet.
In one possible implementation, the link state message is a link state advertisement LSA message.
In one possible implementation, the first neighbor device of the first device is the second device.
In one possible implementation, the second device is a border gateway protocol BGP neighbor device of the first device.
In one possible implementation, the link state message is a border gateway protocol-link state BGP-LS message.
In one possible implementation, the third device is the first device.
In one possible implementation, the third device is a third neighbor device of the first device.
In a possible implementation manner, the link state message further includes a third identifier, where the third identifier corresponds to the first identifier, and the third identifier is used to indicate the third device.
In a possible implementation, the processing unit is further configured to calculate a path based on the link state.
In a possible implementation manner, the transceiver unit is further configured to send link state information to a control device, where the link state information is used to indicate the link state.
In one possible implementation, the first identifier is a System identifier System ID of the neighbor device, or a Router ID.
In one possible implementation, the link state message includes a type length value TLV, which carries the identification.
In one possible implementation, the TLV is one or more of a minimum/maximum one-way link delay Min/Max Unidirectional Link Delay Sub-TLV, one-way link delay Unidirectional Link Delay Sub-TLV, one-way delay variation Unidirectional Delay Variation Sub-TLV, one-way link loss Unidirectional Link Loss Sub-TLV, one-way residual bandwidth Unidirectional Residual Bandwidth Sub-TLV, one-way available bandwidth Unidirectional Available Bandwidth Sub-TLV, one-way real-world bandwidth Unidirectional Utilized Bandwidth Sub-TLV.
In a fifth aspect, the present application provides a network system comprising a first device and a second device. The method comprises the steps that a first device is used for generating a link state message, the link state message comprises a first identifier and a second identifier, the first identifier is used for indicating first neighbor devices of the first device, the second identifier is used for indicating a designated router, and the link state message is sent to a second device. The second device is configured to receive a link state packet, determine a link state of a link between a third device and the first neighboring device according to the first identifier, where the third device is a device that detects and obtains the link state, and the second device is a second neighboring device of the first device.
In a sixth aspect, the present application provides a network device comprising a processor chip and a memory, the memory being for storing instructions or program code, the processor chip being for invoking and executing the instructions or program code from the memory to perform the method of messaging as described in the first aspect or to perform the method of determining link status as described in the second aspect.
In a seventh aspect, the present application provides a network system comprising an apparatus for messaging as in the third aspect and an apparatus for determining a link state as in the fourth aspect.
In an eighth aspect, the present application provides a computer readable storage medium comprising instructions, a program or code which, when executed on a computer, causes the computer to perform the messaging method of the first aspect or the method of determining a link state of the second aspect.
In a ninth aspect, the present application provides a chip comprising a memory and a processor. The memory is used to store instructions or program code. The processor is configured to call and execute the instruction or the program code from the memory to perform the method according to the first aspect; alternatively, the processor performs the method of the second aspect.
In one possible design, the chip includes only a processor for reading and executing the instructions or program code stored in the memory, and when the instructions or program code are executed, the processor performs the method of the first aspect; alternatively, the processor performs the method of the second aspect.
Drawings
Fig. 1 is a schematic diagram of a network structure according to an embodiment of the present application;
fig. 2 is a schematic diagram of a topology structure of a network according to an embodiment of the present application;
fig. 3 is an interaction schematic diagram of a network device and a second device provided in an embodiment of the present application;
Fig. 4a is a schematic format diagram of a Min/Max Unidirectional Link Delay Sub-TLV field in an LSP packet provided according to an embodiment of the present application;
fig. 4b is a schematic diagram of a format of a Unidirectional Link Delay Sub-TLV field in an LSP packet provided according to an embodiment of the present application;
fig. 4c is a schematic diagram of a format of a Unidirectional Delay Variation Sub-TLV field in an LSP packet provided according to an embodiment of the present application;
fig. 4d is a schematic diagram of a format of a Unidirectional Link Loss Sub-TLV field in an LSP packet provided according to an embodiment of the present application;
fig. 4e is a schematic diagram of a format of a Unidirectional Residual Bandwidth Sub-TLV field in an LSP packet provided according to an embodiment of the present application;
fig. 4f is a schematic diagram of a format of a Unidirectional Available Bandwidth Sub-TLV field in an LSP packet provided according to an embodiment of the present application;
fig. 4g is a schematic format diagram of Unidirectional Utilized Bandwidth Sub-TLV fields in an LSP packet provided according to an embodiment of the present application;
fig. 5a is a schematic diagram of the format of the Min/Max Unidirectional Link Delay Sub-TLV field in the LSA packet according to an embodiment of the present application;
fig. 5b is a schematic diagram of a format of Unidirectional Link Delay Sub-TLV fields in an LSA packet according to an embodiment of the present application;
fig. 5c is a schematic diagram of a format of Unidirectional Delay Variation Sub-TLV fields in an LSA packet according to an embodiment of the present application;
Fig. 5d is a schematic diagram of a format of Unidirectional Link Loss Sub-TLV fields in an LSA packet according to an embodiment of the present application;
fig. 5e is a schematic diagram of a format of Unidirectional Residual Bandwidth Sub-TLV fields in an LSA packet according to an embodiment of the present application;
fig. 5f is a schematic diagram of a format of Unidirectional Available Bandwidth Sub-TLV fields in an LSA packet according to an embodiment of the present application;
fig. 5g is a schematic diagram of a format of Unidirectional Utilized Bandwidth Sub-TLV fields in an LSA packet according to an embodiment of the present application;
fig. 6a is a schematic diagram of the format of Min/Max Unidirectional Link Delay Sub-TLV fields in BGP-LS messages provided in an embodiment of the present application;
fig. 6b is a schematic diagram of a format of Unidirectional Link Delay Sub-TLV fields in a BGP-LS message according to an embodiment of the present application;
fig. 6c is a schematic diagram of a format of Unidirectional Delay Variation Sub-TLV fields in a BGP-LS message according to an embodiment of the present application;
fig. 6d is a schematic diagram of a format of Unidirectional Link Loss Sub-TLV fields in a BGP-LS message according to an embodiment of the present application;
fig. 6e is a schematic diagram of a format of Unidirectional Residual Bandwidth Sub-TLV fields in a BGP-LS message according to an embodiment of the present application;
Fig. 6f is a schematic diagram of a format of Unidirectional Available Bandwidth Sub-TLV fields in a BGP-LS message according to an embodiment of the present application;
fig. 6g is a schematic diagram of a format of a Unidirectional Utilized Bandwidth Sub-TLV field in a BGP-LS message according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of an apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an apparatus according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of a network system according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of an apparatus according to an embodiment of the present application;
fig. 11 is a schematic structural diagram of an apparatus according to an embodiment of the present application.
Detailed Description
Embodiments of the present application are described below with reference to the accompanying drawings.
Referring to fig. 1, a schematic diagram of a network structure is provided in an embodiment of the present application. The network includes a network device 101, a network device 102, a network device 103, and a controller 104. Network device 101 and network device 102 establish interior gateway protocol (interior gateway protocol, IGP) neighbors, network device 101 establishes IGP neighbors with network device 103, and network device 102 establishes IGP neighbors with network device 103. Network device 101 establishes border gateway protocol (border gateway protocol, BGP) neighbors with controller 104.
The network entity is capable of running an intermediate system to intermediate system (intermediate system to intermediate system, ISIS) protocol or an open shortest path first (open shortest path first, OSPF) protocol. Based on the ISIS protocol or the OSPF protocol, network device 101-network device 103 elect a designated router. The designated router is a virtual device established based on the network device. The designated router is used to establish the topology of the network.
Referring to fig. 2, a schematic diagram of a topology structure of a network according to an embodiment of the present application is shown. The topology includes five devices, network device 101-network device 103, controller 104, and designated router 105. The topology also includes links between network device 101 and controller 104, and links between network device 101-network device 103 and designated router 105, respectively. Based on the designated router, the connection relationship between the network device 101 and the network device 103 can be simplified, and the calculation of the path is facilitated.
The network device 101-103 is able to detect the link state of the link between the device and the IGP neighbor device. Taking network device 101 as an example, network device 101 is in IGP neighbor relation with network device 102, and network device 101 is in IGP neighbor relation with network device 103. The network device 101 is capable of detecting a link state of a link between the network device 101 and the network device 102 and a link state of a link between the network device 101 and the network device 103 using a link detection method. The network device 101 can send a link state message carrying the link state to an IGP neighbor device or a BGP neighbor device. In the link state packet sent by the network device 101, the link state corresponds to a link between the network device 101 and the designated router 105 in the topology, and cannot correspond to a link between the specific network device 101 and the network device 102, or a link between the network device 101 and the network device 103.
After acquiring the link state message, the network device 102 can only determine that the link state indicated by the link state message is the link state of the link between the network device 101 and the neighbor device of the network device 101. Network device 102 cannot determine whether the neighbor device of network device 101 is specifically network device 102 or network device 103. Similarly, after acquiring the link state packet, the network device 103 can only determine that the link state indicated by the link state packet is the link state of the link between the network device 101 and the neighbor device of the network device 101. The network device 103 cannot determine whether the neighbor device of the network device 101 is specifically the network device 102 or the network device 103.
Network device 101 may also collect link state. For example, the network device 101 acquires the link state of the link between the network device 102 and the designated router 105 transmitted by the network device 102. The network device 101 is capable of generating a link state message based on the acquired link state. The network device 101 sends a link state message to the controller 104. The controller 104 can acquire the link state of the link between the network device 102 and the designated router 105 based on the acquired link state message. The controller 104 cannot determine which of the neighbor devices of the network device 102 the acquired link state is the link state of the link between the network device 102 and. The controller 104 cannot utilize the acquired link state for path computation and monitoring of the link state.
It is understood that, based on the topology including the designated router, the controller or the network device can obtain the link state of the link between the network device generating the link state and the designated router, and can only determine the network device of the detected link state included in the link, and cannot determine the specific network device at the other end. The controller or the network device cannot determine the link state of the link between the network devices, so that the obtained link state cannot be used for path calculation and monitoring of the link state.
Based on the above problems, the embodiments of the present application provide a method for forwarding a message and a method for determining a link state. In the method provided by the embodiment of the application, the first device generates a link state message including the first identifier and the second identifier. Wherein the first identification is used to indicate a first neighbor device of the first device. Based on the first identifier, the device that obtains the link state message can determine a specific link corresponding to the link state indicated by the link state message. The first device sends a link state message to the second device. The second device, that is, the second neighbor device of the first device, can determine, based on the first identifier included in the acquired link state message, that the link state indicated by the link state message is the link state of the link between the third device and the first neighbor device. The third device is a device for detecting and obtaining the link state. The third device may be a network device. The second device can determine a specific link corresponding to the link state, can calculate a path based on the acquired link state, or can monitor the link state.
The following describes an application scenario of the message forwarding method and the method for determining the link state provided in the embodiments of the present application.
The message forwarding method and the method for determining the link state provided by the embodiment of the application can be applied to the network shown in fig. 1. It should be noted that, network device 101 and network device 102 are peers to each other, network device 102 and network device 103 are peers to each other, and network device 101 and network device 103 are also peers to each other. Network device 101-network device 103 may be a router, switch, or the like, having forwarding functionality.
Taking the network device 101 and the network device 102 as examples, three exemplary connection manners are provided in the embodiments of the present application. Any one of the following three connection manners may be adopted between the network device 101 and the network device 102.
First kind: network device 101 is directly connected to network device 102 via a physical link. Direct connection through a physical link may also be referred to as direct connection.
Second kind: network device 101 is connected to network device 102 through other physical devices. The physical device is capable of transmitting messages to network device 101 from network device 102 or transmitting messages to network device 102 from network device 101.
Third kind: the network device 101 is connected to the network device 102 via a network. The network may be a two-layer network. Specifically, the network may be a local area network (local area network, LAN) subnet (sub network).
Similarly, the network device 101 and the network device 103, and the network device 102 and the network device 103 can be connected by any one of the above three connection methods.
The following describes a method for forwarding a message and a method for determining a link state provided by the embodiments of the present application.
Referring to fig. 3, the diagram is an interaction schematic diagram of a first device and a second device provided in an embodiment of the present application, including S301-S304.
S301: the first device generates a link state message.
The first device is a network device capable of generating a link state message and transmitting the link state message.
In the embodiment of the present application, as shown in fig. 1, the first device may be any one of the network devices 101 to 103.
The first device can detect a link state of a link between the first device and the first neighbor device, and generate a link state message based on the detected link state. The link state message can be used to notify other neighbor devices of the detected link state.
The first device can also collect a link state detected by the network device, and generate a link state message based on the collected link state. The first device may send a link state message including the acquired link state to the neighbor device. The neighbor device can acquire a link state of a link between network devices included in the network based on the link state message.
The way in which the two first devices generate the link state messages is described below.
Mode one: the first device generates a link state message based on the detected link state.
The first device has a function of detecting a link state. The first device is capable of detecting a link state of a link between the first device and a first neighbor device of the first device.
Wherein the first neighbor device may be an IGP neighbor of the first device. As shown in fig. 1, taking the first device as the network device 101 in the embodiment of the present application as an example, the first neighbor device may be the network device 102 or the network device 103.
As an example, the first device can detect the link state based on a bi-directional active measurement protocol (two way active measurement protocol, twamp).
The link state detected by the first device may include one or more of latency, loss, and bandwidth. For detecting the link delay, the first device can obtain the link delay value or the link delay variation value. For detecting the loss of the link, the first device can obtain a link loss value. For detecting the bandwidth of the link, the first device can obtain one or more of the remaining bandwidth, the available bandwidth, and the actual bandwidth of the link.
The first device can generate a link state message based on the detection result of the link state. The link state message is used for indicating the link state. As an example, the link state message can include parameters indicative of the link state, such as one or more of the above-described link delay value, link delay variation value, link loss value, residual bandwidth, available bandwidth, and actual bandwidth used.
The link state message includes a first identifier and a second identifier.
Wherein the first identification is used to indicate a first neighbor device of the first device. The first neighbor device, i.e., the neighbor device at the other end of the link that the first device detects. The first identification may be a device identification for uniquely identifying the first neighbor device.
The second identification is used to indicate the designated router. The designated router is the router selected by the first device and the neighbor devices of the first device. In particular, the designated router may be determined by the first device and IGP neighbor devices of the first device based on IGP protocol election.
The designated router is a pseudo node. The designated router is a logical device based on network device establishment in the network. The designated router may be, for example, a functional module comprised by the network device. As shown in connection with fig. 2, the designated router may be designated router 105.
The type of link-state message, the type of first identification, and the type of designated router are determined by the type of IGP protocol that the first device and the neighboring devices of the first device are running. In different types of IGP protocols, the type of link state message, the type of first identification, and the type of designated router are different.
As one example, the IGP protocol run by the first device and the neighbor devices of the first device is an ISIS protocol.
The link state message generated by the first device is a link state protocol data unit (link state protocol data unit, LSP) message.
Based on the ISIS protocol, each network device corresponds to a different System (ID). The System ID can identify a network device in the network. Correspondingly, the first identifier included in the LSP packet may be a System ID of a first neighboring device of the network device.
The designated router indicated by the second identifier may be a designated intermediate system (designated intermediate system, DIS) defined by the ISIS protocol.
As another example, the IGP protocol run by the first device and the neighbor devices of the first device is the OSPF protocol.
The link state message generated by the first device is a link state advertisement (link state advertisement, LSA) message.
Based on the OSPF protocol, each network device corresponds to a different Router identification (Router ID). The Router ID can identify a network device in the network. Correspondingly, the first identifier included in the LSA packet may be a Router ID of a first neighbor device of the first device.
The designated router indicated by the second identifier may be a designated router (designated router, DR) defined by the OSPF protocol.
Mode two: the first device generates a link state message based on the acquired link state.
The first device is capable of collecting a link state generated by a network device in the network and generating a link state message based on the collected link state.
It should be noted that the link state acquired by the first device may include one or more of a link state detected by the first device and a link state acquired from another network device.
In connection with fig. 1, the first device in the embodiment of the present application may be a network device 101. The network device 101 acquires a link state message transmitted by the network device 102. The link state message sent by the network device 102 includes a first identification indicating the network device 103.
The network device 101 can generate a link state packet based on the link state indicated by the acquired link state packet sent by the network device 102 and the detected link state of the link between the network device 101 and the network device 102. The first identifier is used for indicating the network equipment at one end of non-link state detection among the network equipment at two ends of the link. For the link state of the link between the network device 102 and the network device 103, the first identification is used to indicate the network device 103. For the link state of the link between network device 101 and network device 102, the first identification is used to indicate network device 102.
In order to distinguish the link states of the different links, the link state message further comprises a third identification. The third identifier corresponds to the first identifier. The third identification is used to indicate the network device that detected the generated link state.
As an example, a third identification may be used to indicate the first device. Based on the first identifier and the third identifier, the device that obtains the link state message can determine that the link state message indicates a link state of a link between the first device and the first neighbor device.
Taking the link state message generated by the network device 101 as an example, the first identifier is used to indicate the network device 102, and the third identifier corresponding to the first identifier is used to indicate the network device 101.
As another example, the third identification may be with a third neighbor device that indicates the first device. Based on the first identifier and the third identifier, the device that obtains the link state message can determine that the link state message indicates a link state of a link between the third neighbor device and the first neighbor device.
Taking the link state message generated by the network device 101 as an example, the first identifier is used to indicate the network device 103, and the third identifier corresponding to the first identifier is used to indicate the network device 102. Wherein the network device 103 is a second neighbor device of the network device 101. Network device 102 is a third neighbor device of network device 101.
In the embodiment of the present application, the link state message generated by the first device may be a border gateway protocol link state (BGP-LS) message.
It should be noted that BGP-LS protocol supports the first device to collect link information based on IGP protocol. The network in which the first device is located can run the ISIS protocol or the OSPF protocol.
As an example, the network in which the first device is located runs an ISIS protocol, and the BGP-LS message includes a first System ID that identifies a first neighbor device of the first device.
Correspondingly, a third identifier included in the BGP-LS message is a System ID of a third neighbor device of the first device or a System ID of the first device.
As another example, the network in which the first device is located runs the OSPF protocol, and the BGP-LS message includes a first Router ID that identifies the first neighbor device of the first device.
Correspondingly, a third identifier included in the BGP-LS message is a Router ID of a third neighbor device of the first device or a Router ID of the first device.
In one possible implementation, the first device generated link state message includes a type length value (type length value, TLV). The TLV carries a first identification indicating a first neighbor device of the first device.
The specific type of the TLV is related to the type of the link state indicated by the link state message and the type of the link state message. As some examples, embodiments of the present application provide specific types of TLVs included in the three link state messages, respectively, see below.
S302: the first device sends a link state message to the second device.
The second device is a second neighbor device of the first device. The second device may be a network device, a controller or a Route Reflector (RR). The RR may be connected to the controller, and configured to forward a link state packet sent by the first device to the controller.
The second device may be a first neighbor device of the first device or may be a device different from the first neighbor device. That is, the second device may be a neighboring device at the other end of the first device detection link, or may be another neighboring device of the first device.
As an example, as shown in connection with fig. 1, a first device may be a network device 101, with a first neighbor device of the first device and a second neighbor device of the first device being the same neighbor device. The first neighbor device and the second neighbor device are network devices 102. Network device 101 detects a link state of a link with network device 102. The network device 101 generates a link state message based on the detected link state, and transmits the generated link state message to the network device 102.
As another example, as shown in connection with fig. 1, a first device may be a network device 101, the first device first neighbor device and the second neighbor device of the first device being different neighbor devices. For example, the first neighbor device is network device 102. The second neighbor device is the network device 103. Network device 101 detects a link state of a link with network device 102. The network device 101 generates a link state message based on the detected link state, and transmits the generated link state message to the network device 103. As another example, the first neighbor device is the network device 102. The second neighbor device is the controller 104. Network device 101 detects a link state of a link with network device 102. The network device 101 generates a link state message based on the detected link state, and transmits the generated link state message to the controller 104.
It should be noted that the second device, that is, the second neighbor device of the first device, may be an IGP neighbor of the first device, or may be a BGP neighbor of the first device. The neighbor type of the second device is related to the type of the link state message.
In one possible implementation, the second device may be an IGP neighbor of the first device. The link state message may be an LSP message or an LSA message.
In another possible implementation, the second device may be a BGP neighbor of the first device. The link state message may be a BGP-LS message.
S303: the second device receives the link state message.
S304: the second device determines a link state of a link between the third device and a first neighbor device of the first device according to the first identification.
The second device can determine, based on the first identifier included in the link state message, that one end of the link corresponding to the link state indicated by the link state message is a first neighbor device indicated by the first identifier.
In one possible implementation, the second device is capable of determining, based on the first device generating and sending the link state message, that the link indicated by the link state message is a link between the first device and the first neighbor device.
Specifically, for example, for a link state packet that is an LSP packet or an LSA packet, a device that generates the link state packet, that is, the third device, is a first device that detects the link state.
The second device can determine the link state of the link between the first device and the first neighbor device indicated by the first identifier based on the link state message being an LSP message or an LSA message and the first identifier included in the link state message.
In another possible implementation, the link state message includes a third identification indicating a third device. The third identifier corresponds to the first identifier. The second device can determine a third device based on the third identification.
The third device may be the first device or a third neighboring device of the first device.
As an example, the first device can collect the link state detected by the first device. Correspondingly, the link state message generated by the first device includes a third identifier, where the third identifier is used to indicate a third device, that is, a network device that generates a link state. The second device can determine, based on the third identifier and the first identifier, that the link state indicated by the link state message is a link state of a link between the third device and the first neighbor device.
For example, as shown in connection with fig. 1, the first device is a network device 101 and the second device is a controller 104. The link state message sent by the network device 101 and acquired by the controller 104 includes a first identifier indicating the network device 102 and a third identifier indicating the network device 101. The controller 104 can determine, based on the third identification, that the third device is the network device 101. The controller 104 can determine the network device 102 based on the first identification. The controller 104 is capable of determining the link state of the link between the network device 101 and the network device 102 based on the link state message.
As another example, the first device can collect link states detected by a third neighbor device of the first device. The third neighbor device is a different network device than both the first neighbor device and the second neighbor device. Correspondingly, the link state message generated by the first device includes a third identifier, where the third identifier is used to indicate a third neighbor device. The second device can determine, based on the third identifier and the first identifier, that the link state indicated by the link state message is a link state of a link between the third neighbor device of the first device and the first neighbor device of the first device.
For example, as shown in connection with fig. 1, the first device is a network device 101, the second device is a controller 104, the first neighbor device of the first device is a network device 103, and the third neighbor device of the first device is a network device 102. The link state message sent by the network device 101, which is acquired by the controller 104, includes a first identifier indicating the network device 103 and a third identifier indicating the network device 102. The controller 104 can determine, based on the third identification, that the third device is the network device 102. The controller 104 can determine, based on the first identification, that the other end of the link is the network device 103. The controller 104 can determine the link state of the link between the network device 102 and the network device 103 based on the link state message.
In one possible implementation, the second device may be a device with path computation functionality. The second device may be, for example, a network device having a path calculation function or a control device having a path calculation function. The second device is able to calculate a path based on the acquired link state.
In another possible implementation, the second device may also be a device connected to the control device. The second device may be, for example, a network device connected to the control device, or may be a control device connected to another control device. The second device may forward link state information indicating the link state to the control device for the control device to monitor the link state with the determined link state or for calculation of the path.
The TLVs carrying the first identifier included in the three link state messages are described below.
In one possible implementation, a TLV included in the link state message may be extended, with the first identification added to the TLV.
First kind: the link state message is an LSP message.
The link state detected by the first device may include one or more of latency, loss, and bandwidth. The TLVs included in the link state messages indicating the different link state types are described below, respectively.
First: the TLV is a minimum/maximum one-way link delay (Min/Max Unidirectional Link Delay) Sub-TLV.
Referring to fig. 4a, the format of the Min/Max Unidirectional Link Delay Sub-TLV field in the LSP message provided in the embodiments of the present application is schematically shown. The Min/Max Unidirectional Link Delay Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, a RESERVED (RESERVED) field, a maximum Delay (Max Delay) field, and a minimum Delay (Min Delay) field.
Wherein the value of the Type field identifies the Type of the Min/Max Unidirectional Link Delay Sub-TLV field. The Length field has a value of the Min/Max Unidirectional Link Delay Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Max Delay field can carry the maximum unidirectional link Delay value. The Min Delay field can carry a minimum unidirectional link Delay value.
Second,: the TLV is a one-way link delay (Unidirectional Link Delay) Sub-TLV.
Referring to fig. 4b, a schematic format diagram of Unidirectional Link Delay Sub-TLV fields in an LSP packet according to an embodiment of the present application is shown. In the figure, the Unidirectional Link Delay Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, a RESERVED (RESERVED) field, and a Delay (Delay) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Link Delay Sub-TLV field. The Length field has a value of the Unidirectional Link Delay Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Delay field carries a unidirectional link Delay value.
Third,: the TLV is a one-way delay variation (Unidirectional Delay Variation) Sub-TLV.
Referring to fig. 4c, a schematic format diagram of Unidirectional Delay Variation Sub-TLV fields in an LSP packet according to an embodiment of the present application is shown. In the figure, the Unidirectional Delay Variation Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, a RESERVED (RESERVED) field, and a Delay Variation (Delay Variation) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Delay Variation Sub-TLV field. The Length field has a value of the Unidirectional Delay Variation Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Delay variance field carries a unidirectional link Delay Variation value.
Fourth,: the TLV is a one-way link loss (Unidirectional Link Loss) Sub-TLV.
Referring to fig. 4d, the format of Unidirectional Link Loss Sub-TLV fields in the LSP message provided in the embodiments of the present application is schematically illustrated. In the figure, the Unidirectional Link Loss Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, a RESERVED (RESERVED) field, and a Link Loss field.
Wherein the value of the Type field identifies the Type of the Unidirectional Link Loss Sub-TLV field. The Length field has a value of the Unidirectional Link Loss Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Link Loss field carries a unidirectional Link Loss value.
Fifth,: the TLV is a one-way bandwidth remaining (Unidirectional Residual Bandwidth) Sub-TLV.
Referring to fig. 4e, the format of Unidirectional Residual Bandwidth Sub-TLV fields in the LSP message provided in the embodiments of the present application is schematically illustrated. In the figure, the Unidirectional Residual Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, and a remaining bandwidth (Residual Bandwidth) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Residual Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Residual Bandwidth Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Residual Bandwidth field carries the remaining bandwidth.
Sixth: the TLV is a one-way available bandwidth (Unidirectional Available Bandwidth) Sub-TLV.
Referring to fig. 4f, the format of Unidirectional Available Bandwidth Sub-TLV fields in an LSP packet according to an embodiment of the present application is shown. In the figure, the Unidirectional Available Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, and an available bandwidth (Available Bandwidth) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Available Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Available Bandwidth Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Available Bandwidth field carries the available bandwidth.
Seventh: the TLV is a one-way real-use bandwidth (Unidirectional Utilized Bandwidth) Sub-TLV.
Referring to fig. 4g, the format of Unidirectional Utilized Bandwidth Sub-TLV fields in an LSP packet according to an embodiment of the present application is shown. In the figure, the Unidirectional Utilized Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, a Neighbor System identification (Neighbor System-ID) field, and an actual usage bandwidth (Utilized Bandwidth) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Utilized Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Utilized Bandwidth Sub-TLV Length. The Neighbor System-ID field can carry a first identification. The Utilized Bandwidth field carries the actual bandwidth used.
Second kind: the link state message is an LSA message.
The LSA message can include the following seven types of TLVs.
First: the TLV is a minimum/maximum one-way link delay (Min/Max Unidirectional Link Delay) Sub-TLV.
Referring to fig. 5a, the format of Min/Max Unidirectional Link Delay Sub-TLV fields in LSA messages provided in embodiments of the present application is schematically illustrated. In the figure, the Min/Max Unidirectional Link Delay Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, a RESERVED (RESERVED) field, a maximum Delay (Max Delay) field, and a minimum Delay (Min Delay) field.
Wherein the value of the Type field identifies the Type of the Min/Max Unidirectional Link Delay Sub-TLV field. The Length field has a value of the Min/Max Unidirectional Link Delay Sub-TLV Length. The Router Identifier field can carry a first identification. The Max Delay field carries the maximum unidirectional link Delay value. The Min Delay field can carry a minimum unidirectional link Delay value.
Second,: the TLV is a one-way link delay (Unidirectional Link Delay) Sub-TLV.
Referring to fig. 5b, a schematic diagram of a format of Unidirectional Link Delay Sub-TLV fields in LSA packets according to an embodiment of the present application is shown. In the figure, the Unidirectional Link Delay Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, a RESERVED (RESERVED) field, and a Delay (Delay) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Link Delay Sub-TLV field. The Length field has a value of the Unidirectional Link Delay Sub-TLV Length. The Router Identifier field can carry a first identification. The Delay field carries a unidirectional link Delay value.
Third,: the TLV is a one-way delay variation (Unidirectional Delay Variation) Sub-TLV.
Referring to fig. 5c, a schematic diagram of a format of Unidirectional Delay Variation Sub-TLV fields in LSA messages according to an embodiment of the present application is shown. In the figure, the Unidirectional Delay Variation Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, a RESERVED (RESERVED) field, and a Delay Variation (Delay Variation) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Delay Variation Sub-TLV field. The Length field has a value of the Unidirectional Delay Variation Sub-TLV Length. The Router Identifier field can carry a first identification. The Delay variance field carries a unidirectional link Delay Variation value.
Fourth,: the TLV is a one-way link loss (Unidirectional Link Loss) Sub-TLV.
Referring to fig. 5d, a schematic diagram of a format of Unidirectional Link Loss Sub-TLV fields in LSA packets according to an embodiment of the present application is shown. In the figure, the Unidirectional Link Loss Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, a RESERVED (RESERVED) field, and a Link Loss field.
Wherein the value of the Type field identifies the Type of the Unidirectional Link Loss Sub-TLV field. The Length field has a value of the Unidirectional Link Loss Sub-TLV Length. The Router Identifier field can carry a first identification. The Link Loss field carries a unidirectional Link Loss value.
Fifth,: the TLV is a one-way bandwidth remaining (Unidirectional Residual Bandwidth) Sub-TLV.
Referring to fig. 5e, a schematic diagram of a format of Unidirectional Residual Bandwidth Sub-TLV fields in LSA packets according to an embodiment of the present application is shown. In the figure, the Unidirectional Residual Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, and a residual bandwidth (Residual Bandwidth) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Residual Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Residual Bandwidth Sub-TLV Length. The Router Identifier field can carry a first identification. The Residual Bandwidth field carries the remaining bandwidth.
Sixth: the TLV is a one-way available bandwidth (Unidirectional Available Bandwidth) Sub-TLV.
Referring to fig. 5f, a schematic diagram of a format of Unidirectional Available Bandwidth Sub-TLV fields in LSA packets according to an embodiment of the present application is shown. In the figure, the Unidirectional Available Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, and an available bandwidth (Available Bandwidth) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Available Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Available Bandwidth Sub-TLV Length. The Router Identifier field can carry a first identification. The Available Bandwidth field carries the available bandwidth.
Seventh: the TLV is a one-way real-use bandwidth (Unidirectional Utilized Bandwidth) Sub-TLV.
Referring to fig. 5g, the format of Unidirectional Utilized Bandwidth Sub-TLV fields in LSA messages provided in an embodiment of the present application is schematically shown. In the figure, the Unidirectional Utilized Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, a router identification (Router Identifier) field, and an actual usage bandwidth (Utilized Bandwidth) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Utilized Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Utilized Bandwidth Sub-TLV Length. The Router Identifier field can carry a first identification. The Utilized Bandwidth field carries the actual bandwidth used.
Third kind: the link state message is a BGP-LS message.
Similar to the TLVs included in the LSP messages described above, BGP-LS messages can include the following seven types of TLVs.
First: the TLV is a minimum/maximum one-way link delay (Min/Max Unidirectional Link Delay) Sub-TLV.
Referring to fig. 6a, the format of Min/Max Unidirectional Link Delay Sub-TLV fields in BGP-LS messages provided in an embodiment of the present application is schematically illustrated. In the figure, the Min/Max Unidirectional Link Delay Sub-TLV field includes a Type (Type) field, a Length (Length) field, a RESERVED (RESERVED) field, a maximum Delay (Max Delay) field, and a minimum Delay (Min Delay) field. The Min/Max Unidirectional Link Delay Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Min/Max Unidirectional Link Delay Sub-TLV field. The Length field has a value of the Min/Max Unidirectional Link Delay Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Max Delay field can carry the maximum unidirectional link Delay value. The Min Delay field can carry a minimum unidirectional link Delay value.
Second,: the TLV is a one-way link delay (Unidirectional Link Delay) Sub-TLV.
Referring to fig. 6b, a schematic diagram of a format of Unidirectional Link Delay Sub-TLV fields in a BGP-LS message according to an embodiment of the present application is shown. In the figure, the Unidirectional Link Delay Sub-TLV field includes a Type (Type) field, a Length (Length) field, a RESERVED (RESERVED) field, and a Delay (Delay) field. The Unidirectional Link Delay Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Link Delay Sub-TLV field. The Length field has a value of the Unidirectional Link Delay Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Delay field carries a unidirectional link Delay value.
Third,: the TLV is a one-way delay variation (Unidirectional Delay Variation) Sub-TLV.
Referring to fig. 6c, a schematic diagram of a format of Unidirectional Delay Variation Sub-TLV fields in a BGP-LS message according to an embodiment of the present application is shown. In the figure, the Unidirectional Delay Variation Sub-TLV field includes a Type (Type) field, a Length (Length) field, a RESERVED (RESERVED) field, and a Delay Variation (Delay Variation) field. The Unidirectional Delay Variation Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Delay Variation Sub-TLV field. The Length field has a value of the Unidirectional Delay Variation Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Delay variance field carries a unidirectional link Delay Variation value.
Fourth,: the TLV is a one-way link loss (Unidirectional Link Loss) Sub-TLV.
Referring to fig. 6d, the format of Unidirectional Link Loss Sub-TLV fields in a BGP-LS message provided in an embodiment of the present application is schematically illustrated. In the figure, the Unidirectional Link Loss Sub-TLV field includes a Type (Type) field, a Length (Length) field, a RESERVED (RESERVED) field, and a Link Loss field. The Unidirectional Link Loss Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Link Loss Sub-TLV field. The Length field has a value of the Unidirectional Link Loss Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Link Loss field carries a unidirectional Link Loss value.
Fifth,: the TLV is a one-way bandwidth remaining (Unidirectional Residual Bandwidth) Sub-TLV.
Referring to fig. 6e, the format of Unidirectional Residual Bandwidth Sub-TLV fields in a BGP-LS message provided in an embodiment of the present application is schematically illustrated. In the figure, the Unidirectional Residual Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, and a remaining bandwidth (Residual Bandwidth) field. The Unidirectional Residual Bandwidth Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Residual Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Residual Bandwidth Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Residual Bandwidth field carries the remaining bandwidth.
Sixth: the TLV is a one-way available bandwidth (Unidirectional Available Bandwidth) Sub-TLV.
Referring to fig. 6f, a schematic diagram of a format of Unidirectional Available Bandwidth Sub-TLV fields in a BGP-LS message according to an embodiment of the present application is shown. In the figure, the Unidirectional Available Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, and an available bandwidth (Available Bandwidth) field. The Unidirectional Available Bandwidth Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Available Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Available Bandwidth Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Available Bandwidth field carries the available bandwidth.
Seventh: the TLV is a one-way real-use bandwidth (Unidirectional Utilized Bandwidth) Sub-TLV.
Referring to fig. 6g, the format of Unidirectional Utilized Bandwidth Sub-TLV fields in a BGP-LS message provided in an embodiment of the present application is schematically illustrated. In the figure, the Unidirectional Utilized Bandwidth Sub-TLV field includes a Type (Type) field, a Length (Length) field, and an actual usage bandwidth (Utilized Bandwidth) field. The Unidirectional Utilized Bandwidth Sub-TLV field also includes an ISIS neighbor System identification (IS-IS Neighbor System-ID) field or an OSPF router identification (OSPF Router Identifier) field.
Wherein the value of the Type field identifies the Type of the Unidirectional Utilized Bandwidth Sub-TLV field. The Length field has a value of the Unidirectional Utilized Bandwidth Sub-TLV Length. The IS-IS Neighbor System-ID field or OSPF Router Identifier field can carry a first identification. The Utilized Bandwidth field carries the actual bandwidth used.
In another possible implementation, a new type of TLV may also be added to carry the first identification.
For example, the newly added TLVs may be one or more of a local area network minimum/maximum one-way link delay (LAN Min/Max Unidirectional Link Delay) Sub-TLV, a local area network one-way link delay (LAN Unidirectional Link Delay) Sub-TLV, a local area network one-way delay change (LAN Unidirectional Delay Variation) Sub-TLV, a local area network one-way link loss (LAN Unidirectional Link Loss) Sub-TLV, a local area network one-way residual bandwidth (LAN Unidirectional Residual Bandwidth) Sub-TLV, a local area network one-way available bandwidth (LAN Unidirectional Available Bandwidth) Sub-TLV, and a local area network one-way real-world bandwidth (LAN Unidirectional Utilized Bandwidth) Sub-TLV.
The specific format of the added TLV included in the different types of link state messages may be referred to the format of the extended TLV, which is not described herein.
Fig. 7 shows a schematic diagram of a possible configuration of the apparatus for sending a message according to the foregoing embodiment, where the apparatus 700 may implement the function of the first apparatus in the example shown in fig. 3. Referring to fig. 7, the apparatus 700 includes: a processing unit 701 and a transceiver unit 702.
These units may perform the corresponding functions of the first device in the method examples described above. A processing unit 701 for supporting the device 700 to execute S301 in fig. 3; a transceiver unit 702 for supporting the device 700 to execute S302 in fig. 3; and/or other processes performed by the first device in the techniques described herein. For example, a processing unit 701, configured to perform various processing operations performed by the first device in the above-described method embodiment; the transceiver unit 702 is configured to perform operations of various processes of the first device in the foregoing method embodiment. For example, a processing unit 701 is configured to generate a link state message; a transceiver unit 702, configured to send a link state packet to the second device. Reference is made to the detailed description of the corresponding steps in the embodiment shown in fig. 3, and details are not repeated here.
Fig. 8 shows a schematic diagram of a possible architecture of the device for determining a link state according to the above embodiment, where the device 800 may implement the functionality of the second device in the example shown in fig. 3. Referring to fig. 8, the apparatus 800 includes: a transceiver unit 801 and a processing unit 802.
These units may perform the corresponding functions of the second device in the method examples described above. A transceiver unit 801 for supporting the device 800 to execute S303 in fig. 3; a processing unit 802 for supporting the device 800 to execute S304 in fig. 3; and/or other processes performed by the second device in the techniques described herein. For example, the transceiver unit 801 is configured to perform various transceiver operations performed by the second device in the foregoing method embodiment; a processing unit 802, configured to perform various processing operations of the second device in the foregoing method embodiment. For example, the transceiver unit 801 is configured to receive a link state message; a processing unit 802 is configured to determine a link state of a link between the third device and a first neighboring device of the first device according to the first identification. Reference is made to the detailed description of the corresponding steps in the embodiment shown in fig. 3, and details are not repeated here.
It should be noted that, in the embodiment of the present application, the division of the units is schematic, which is merely a logic function division, and other division manners may be implemented in actual practice. Each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. For example, in the above embodiment, the acquisition unit and the processing unit may be the same unit or different units. The integrated units may be implemented in hardware or in software functional units.
Referring to fig. 9, an embodiment of the present invention provides a network system 900, where the network system 900 is configured to implement the method for sending a message and the method for determining a link state in the foregoing method embodiments. The network system 900 includes a first device 901 and a second device 902. The first device 901 may implement the functions of the first device in the embodiment shown in fig. 3, and the second device 902 may implement the functions of the second device in the embodiment shown in fig. 3. Reference is made to the detailed description of the corresponding steps in the embodiment shown in fig. 3, and details are not repeated here.
Fig. 10 is a schematic structural diagram of an apparatus 1000 according to an embodiment of the present application. The device 700 in fig. 7 and the device 800 in fig. 8 may be implemented by the device shown in fig. 10. Referring to fig. 10, the device 1000 comprises at least one processor 1001, a communication bus 1002 and at least one network interface 1004, optionally the device 1000 may also comprise a memory 1003.
The processor 1001 may be a general purpose central processing unit (central processing unit, CPU), application-specific integrated circuit (ASIC) or one or more integrated circuits (integrated circuit, IC) for controlling the execution of programs in the present application. The processor may be configured to process the message to implement a method for sending a message or a method for determining a link state provided in an embodiment of the present application.
For example, when the first device in fig. 3 is implemented by the device shown in fig. 10, the processor may be configured to generate a link state packet, and for specific functional implementation, reference may be made to a processing portion corresponding to the first device in an embodiment of a method. For another example, when the second device in fig. 3 is implemented by the device shown in fig. 10, the processor may be configured to determine, according to the first identifier, a link state of a link between the third device and a first neighboring device of the first device, where a specific functional implementation may refer to a processing portion of the method embodiment corresponding to the second device.
A communication bus 1002 is used to transfer information between the processor 1001, network interface 1004, and memory 1003.
The Memory 1003 may be a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, the Memory 1003 may also be a random access Memory (random access Memory, RAM) or other type of dynamic storage device that can store information and instructions, or it may be a read-only optical disk (compact disc read-only Memory, CD-ROM) or other optical disk storage, optical disk storage (including compact disk, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, without limitation. The memory 1003 may be separate and coupled to the processor 1001 by a communication bus 1002. Memory 1003 may also be integrated with processor 1001.
Optionally, the memory 1003 is used for storing program codes or instructions for executing the aspects of the present application, and the execution is controlled by the processor 1001. The processor 1001 is for executing program code or instructions stored in the memory 1003. One or more software modules may be included in the program code. Alternatively, the processor 1001 may store program code or instructions for performing the aspects of the present application, in which case the processor 1001 need not read the program code or instructions into the memory 1003.
The network interface 1004 may be a device such as a transceiver for communicating with other devices or communication networks, which may be ethernet, radio Access Network (RAN) or wireless local area network (wireless local area networks, WLAN), etc. In the embodiment of the present application, the network interface 1004 may be configured to receive a message sent by another node in the segment routing network, and may also send a message to another node in the segment routing network. The network interface 1004 may be an ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, or the like.
In a particular implementation, as one embodiment, device 1000 may include multiple processors, such as processor 1001 and processor 405 shown in FIG. 10. Each of these processors may be a single-core (single-CPU) processor or may be a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).
Fig. 11 is a schematic structural diagram of an apparatus 1100 according to an embodiment of the present application. The first device and the second device in fig. 3 may be implemented by the devices shown in fig. 11. Referring to the schematic device architecture shown in fig. 11, a device 1100 includes a master control board and one or more interface boards. The main control board is in communication connection with the interface board. The main control board, also called a main processing unit (main processing unit, MPU) or routing processing card (route processor card), includes a CPU and a memory, and is responsible for controlling and managing the various components in the device 1100, including routing computation, device management and maintenance functions. The interface board is also called a line processing unit (line processing unit, LPU) or line card (line card) for receiving and transmitting messages. In some embodiments, communication is via a bus between the master control board and the interface board or between the interface board and the interface board. In some embodiments, the interface boards communicate via a switch fabric, in which case the device 1100 also includes a switch fabric communicatively coupled to the master board and the interface boards, the switch fabric configured to forward data between the interface boards, which may also be referred to as a switch fabric unit (switch fabric unit, SFU). The interface board includes a CPU, memory, forwarding engine, and Interface Card (IC), where the interface card may include one or more network interfaces. The network interface may be an Ethernet interface, an FE interface, a GE interface, or the like. The CPU is in communication connection with the memory, the forwarding engine and the interface card respectively. The memory may be used to store a forwarding table. The forwarding engine is used for forwarding the received message based on a forwarding table stored in the memory. The forwarding engine may be a network processor (network processor, NP). The interface card is also called a sub-card, can be installed on the interface board, and is responsible for converting the photoelectric signal into a data frame, and forwarding the data frame to a forwarding engine for processing or an interface board CPU after performing validity check. In some embodiments, the CPU may also perform the functions of a forwarding engine, such as soft forwarding based on a general purpose CPU, so that no forwarding engine is needed in the interface board. In some embodiments, the forwarding engine may be implemented by an ASIC or field programmable gate array (field programmable gate array, FPGA). In some embodiments, the memory storing the forwarding table may also be integrated into the forwarding engine as part of the forwarding engine.
The embodiment of the application also provides a chip system, which comprises: and a processor coupled to the memory, the memory for storing a program or instructions that, when executed by the processor, cause the system-on-a-chip to implement the method performed by the first device or the second device in the embodiment shown in fig. 3.
Alternatively, the processor in the system-on-chip may be one or more. The processor may be implemented in hardware or in software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general purpose processor, implemented by reading software code stored in a memory.
Alternatively, the memory in the system-on-chip may be one or more. The memory may be integral with the processor or separate from the processor, and is not limited in this application. For example, the memory may be a non-transitory processor, such as a ROM, which may be integrated on the same chip as the processor, or may be separately provided on different chips, and the type of memory and the manner of providing the memory and the processor are not specifically limited in this application.
The system-on-chip may be, for example, an FPGA, an ASIC, a system-on-chip (SoC), a CPU, an NP, a digital signal processing circuit (digital signal processor, DSP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chips.
It should be understood that the steps in the above-described method embodiments may be accomplished by integrated logic circuitry in hardware in a processor or instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in a hardware processor or in a combination of hardware and software modules in a processor.
Embodiments of the present application also provide a computer-readable storage medium comprising instructions that, when run on a computer, cause the computer to perform the method of the previous embodiments.
The terms first, second, third, fourth and the like in the description and in the claims of the present application and in the above-described figures, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
In the present application, "at least one" means one or more, and "a plurality" means two or more. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural. "A and/or B" is considered herein to include A alone, B alone, and A+B.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, and the division of the units, for example, is merely a logic module division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be acquired according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each module unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units described above may be implemented either in hardware or in software module units.
The integrated units, if implemented in the form of software module units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or all or part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a first device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
Those skilled in the art will appreciate that in one or more of the examples described above, the functions described in the present invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, these functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.
The above embodiments are further described in detail for the purpose, technical solution and advantageous effects of the present invention, and it should be understood that the above description is only an embodiment of the present invention.
The above embodiments are merely for illustrating the technical solution of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims (54)

1. A method for sending a message, the method comprising:
the method comprises the steps that a first device generates a link state message, wherein the link state message comprises a first identifier and a second identifier, the first identifier is used for indicating a first neighbor device of the first device, and the second identifier is used for indicating a designated router;
the first device sends the link state message to a second device, and the second device is a second neighbor device of the first device.
2. The method of claim 1, wherein the designated router comprises a designated intermediate system DIS defined by intermediate system-to-intermediate system ISIS.
3. The method of claim 1, wherein the designated router comprises an open shortest path first, OSPF, defined designated router, DR.
4. The method according to claim 1 or 2, wherein the link state message is a link state protocol data unit, LSP, message and the second device is an interior gateway protocol, IGP, neighbor of the first device.
5. A method according to claim 1 or 3, wherein the link state message is a link state advertisement LSA message and the second device is an IGP neighbor of the first device.
6. A method according to any of claims 1-3, wherein the link state message is a border gateway protocol-link state BGP-LS message and the second device is a border gateway protocol BGP neighbor of the first device.
7. The method of claim 6, wherein the BGP-LS message further comprises a third identifier, the third identifier being configured to indicate a device that detects a link state indicated by the link state message.
8. The method of claim 1, 6 or 7, wherein the first identification is a System identification System ID or a Router ID of the first neighbor device.
9. The method according to any of claims 1-8, wherein the link state message comprises a type length value, TLV, the TLV carrying the first identity.
10. The method of claim 9, wherein the TLV is one or more of a Min/Max Unidirectional Link Delay Sub-TLV, a Unidirectional Link Delay Sub-TLV, a Unidirectional Delay Variation Sub-TLV, a Unidirectional Link Loss Sub-TLV, a Unidirectional Residual Bandwidth Sub-TLV, a Unidirectional Available Bandwidth Sub-TLV, and a Unidirectional Utilized Bandwidth Sub-TLV.
11. A method of determining link status, the method comprising:
the method comprises the steps that a second device receives a link state message, wherein the link state message comprises a first identifier, the first identifier is used for indicating first neighbor devices of a first device, the first device is used for generating and sending the link state message, and the second device is the second neighbor device of the first device;
and the second device determines the link state of a link between a third device and the first neighbor device according to the first identifier, wherein the third device is a device for detecting and obtaining the link state.
12. The method of claim 11, wherein the second device is an interior gateway protocol IGP neighbor device of the first device.
13. The method according to claim 11 or 12, wherein the link state message is a link state protocol data unit, LSP, message.
14. The method according to claim 11 or 12, wherein the link state message is a link state advertisement LSA message.
15. The method of any of claims 11-14, wherein the second device is a first neighbor device of the first device.
16. The method of claim 11, wherein the second device is a border gateway protocol BGP neighbor device of the first device.
17. The method of claim 16, wherein the link state message is a border gateway protocol-link state BGP-LS message.
18. The method of any of claims 11-17, wherein the third device is the first device.
19. The method of claim 16 or 17, wherein the third device is a third neighbor device of the first device.
20. The method according to claim 18 or 19, wherein the link state message further comprises a third identifier, the third identifier corresponding to the first identifier, the third identifier being used to indicate the third device.
21. The method according to any one of claims 11-20, further comprising:
the second device calculates a path based on the link state.
22. The method according to any one of claims 11-21, further comprising:
the second device sends link state information to the control device, where the link state information is used to indicate the link state.
23. The method according to any of claims 11, 16 and 17, wherein the first identification is a System identification System ID or a Router ID of the neighbor device.
24. The method according to any of claims 11-23, wherein the link state message comprises a type length value, TLV, the TLV carrying the identification.
25. The method of claim 24, wherein the TLV is one or more of a Min/Max Unidirectional Link Delay Sub-TLV, a Unidirectional Link Delay Sub-TLV, a Unidirectional Delay Variation Sub-TLV, a Unidirectional Link Loss Sub-TLV, a Unidirectional Residual Bandwidth Sub-TLV, a Unidirectional Available Bandwidth Sub-TLV, and a Unidirectional Utilized Bandwidth Sub-TLV.
26. An apparatus for sending a message, wherein the apparatus is applied to a first apparatus, the apparatus comprising:
the processing unit is used for generating a link state message, wherein the link state message comprises a first identifier and a second identifier, the first identifier is used for indicating first neighbor equipment of the first equipment, and the second identifier is used for indicating a designated router;
And the receiving and transmitting unit is used for transmitting the link state message to the second equipment, wherein the second equipment is second neighbor equipment of the first equipment.
27. The apparatus of claim 26, wherein the designated router comprises a designated intermediate system DIS defined by intermediate system-to-intermediate system ISIS.
28. The apparatus of claim 26 wherein the designated router comprises an open shortest path first, OSPF, defined designated router DR.
29. The device of claim 26 or 27, wherein the link state message is a link state protocol data unit, LSP, message and the second device is an interior gateway protocol, IGP, neighbor of the first device.
30. The device of claim 26 or 28, wherein the link state message is a link state advertisement LSA message and the second device is an IGP neighbor of the first device.
31. The device of any of claims 26-28, wherein the link state message is a border gateway protocol-link state BGP-LS message and the second device is a border gateway protocol BGP neighbor of the first device.
32. The apparatus of claim 31, wherein the BGP-LS message further comprises a third identifier, the third identifier being configured to indicate the apparatus that detects the link state indicated by the link state message.
33. The device of claim 25, 31 or 32, wherein the first identity is a System identity, system ID, or a Router ID, of the first neighbor device.
34. The apparatus according to any of claims 26-33, wherein the link state message comprises a type length value, TLV, the TLV carrying the first identity.
35. The device of claim 34, wherein the TLV is one or more of a Min/Max Unidirectional Link Delay Sub-TLV, a Unidirectional Link Delay Sub-TLV, a Unidirectional Delay Variation Sub-TLV, a Unidirectional Link Loss Sub-TLV, a Unidirectional Residual Bandwidth Sub-TLV, a Unidirectional Available Bandwidth Sub-TLV, and a Unidirectional Utilized Bandwidth Sub-TLV.
36. An apparatus for determining a link state, the apparatus being applied to a second apparatus, the apparatus comprising:
the receiving and transmitting unit is used for receiving a link state message, wherein the link state message comprises a first identifier, the first identifier is used for indicating first neighbor equipment of first equipment, the first equipment is used for generating and transmitting the link state message, and the second equipment is second neighbor equipment of the first equipment;
and the processing unit is used for determining the link state of the link between the third equipment and the first neighbor equipment according to the first identifier, wherein the third equipment is equipment for detecting and obtaining the link state.
37. The device of claim 36, wherein the second device is an interior gateway protocol IGP neighbor device of the first device.
38. The apparatus according to claim 36 or 37, wherein the link state message is a link state protocol data unit, LSP, message.
39. The apparatus according to claim 36 or 37, wherein the link state message is a link state advertisement LSA message.
40. The device of any of claims 36-39, wherein a first neighbor device of the first device is the second device.
41. The device of claim 36, wherein the second device is a border gateway protocol BGP neighbor device of the first device.
42. The apparatus of claim 41, wherein the link state message is a border gateway protocol-link state BGP-LS message.
43. The device of any one of claims 36-42, wherein the third device is the first device.
44. The device of claim 41 or 42, wherein the third device is a third neighbor device of the first device.
45. The apparatus of claim 43 or 44, wherein the link state message further includes a third identifier, the third identifier corresponding to the first identifier, the third identifier being used to indicate the third apparatus.
46. The apparatus of any one of claims 36-45, wherein the processing unit is further configured to calculate a path based on the link state.
47. The device according to any of the claims 36-46, wherein the transceiver unit is further configured to send link state information to a control device, the link state information being used to indicate the link state.
48. The device of any one of claims 36, 41, and 42, wherein the first identity is a System identity, system ID, or a Router ID, of the neighbor device.
49. The apparatus of any one of claims 36-48, wherein the link state message includes a type length value, TLV, the TLV carrying the identification.
50. The device of claim 49, wherein the TLV is one or more of a minimum/maximum one-way link delay Min/Max Unidirectional Link Delay Sub-TLV, one-way link delay Unidirectional Link Delay Sub-TLV, one-way delay variation Unidirectional Delay Variation Sub-TLV, one-way link loss Unidirectional Link Loss Sub-TLV, one-way residual bandwidth Unidirectional Residual Bandwidth Sub-TLV, one-way available bandwidth Unidirectional Available Bandwidth Sub-TLV, one-way real-use bandwidth Unidirectional Utilized Bandwidth Sub-TLV.
51. A network system, the network system comprising a first device and a second device;
the first device is configured to generate a link state packet, send the link state packet to the second device, where the link state packet includes a first identifier and a second identifier, the first identifier is used to indicate a first neighboring device of the first device, the second identifier is used to indicate a designated router, and the second device is a second neighboring device of the first device;
The second device is configured to receive a link state packet, determine, according to the first identifier, a link state of a link between a third device and the first neighboring device, where the third device is a device that detects and obtains the link state.
52. An apparatus comprising a processor chip and a memory, the memory storing instructions or program code, the processor chip to invoke and execute the instructions or program code from the memory to perform the messaging method of any of claims 1 to 10 or to perform the method of determining a link state of any of claims 11 to 25.
53. A network system comprising a device for messaging according to any of claims 26 to 35 and a device for determining link status according to any of claims 36 to 50.
54. A computer readable storage medium comprising instructions, a program or code which, when executed on a computer, causes the computer to perform the messaging method of any of claims 1 to 10 or to perform the method of determining a link state of any of claims 11 to 25.
CN202210042399.4A 2022-01-14 2022-01-14 Message sending method, equipment and system for determining link state Pending CN116489238A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210042399.4A CN116489238A (en) 2022-01-14 2022-01-14 Message sending method, equipment and system for determining link state
PCT/CN2022/140666 WO2023134416A1 (en) 2022-01-14 2022-12-21 Message sending method, method for determining link state, device and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210042399.4A CN116489238A (en) 2022-01-14 2022-01-14 Message sending method, equipment and system for determining link state

Publications (1)

Publication Number Publication Date
CN116489238A true CN116489238A (en) 2023-07-25

Family

ID=87212481

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210042399.4A Pending CN116489238A (en) 2022-01-14 2022-01-14 Message sending method, equipment and system for determining link state

Country Status (2)

Country Link
CN (1) CN116489238A (en)
WO (1) WO2023134416A1 (en)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101094112A (en) * 2007-07-23 2007-12-26 华为技术有限公司 Method, device and system for testing performance of route protocol of network device
CN102123088B (en) * 2011-02-21 2015-09-23 杭州华三通信技术有限公司 Set up the method and apparatus of traffic engineering tunnel
WO2014113957A1 (en) * 2013-01-24 2014-07-31 华为技术有限公司 Link management method, device and communication system
CN109218178B (en) * 2017-07-05 2021-06-22 华为技术有限公司 Message processing method and network equipment
CN112118180A (en) * 2018-12-29 2020-12-22 华为技术有限公司 Method, device and system for planning path

Also Published As

Publication number Publication date
WO2023134416A1 (en) 2023-07-20

Similar Documents

Publication Publication Date Title
CN111917643B (en) Seamless bidirectional forwarding detection method and device for segmented routing tunnel
JP5813072B2 (en) Method and apparatus for providing full logical connectivity in an MPLS network
US9634924B2 (en) Server-layer shared link risk group analysis to identify potential client-layer network connectivity loss
US8989048B2 (en) Node system ID change in link state protocol network
CN115552861B (en) Method for generating forwarding table item, method for sending message, network equipment and system
US10862735B2 (en) Method and apparatus for implementing operation, administration, and maintenance function
US9712424B2 (en) Method for configuring node devices of a mesh communications network, computer program, information storage means and system
JP6443864B2 (en) Method, apparatus and system for implementing packet loss detection
CN114513429A (en) Transmission method for detection message, and method and equipment for determining reverse path
JPWO2019207758A1 (en) Monitoring device, network system, topology management method, and monitoring program
JP7119174B2 (en) Network topology discovery method, network topology discovery device and network topology discovery system
US8614958B2 (en) Systems and methods of snooping connectivity fault messages to configure maintenance end point for alarm suppression messages
CN116489238A (en) Message sending method, equipment and system for determining link state
CN114401324B (en) Message forwarding method, network equipment and system
US20210297321A1 (en) Sparse link-state flooding
CN111885630A (en) Data transmission method and communication device
CN114301829B (en) Method, equipment and medium for selecting message sending path
CN114124753B (en) Message sending method and device
US8396955B2 (en) Systems and methods for discovery of network topology using service OAM
CN114793208A (en) Information flooding method and equipment
WO2015055103A1 (en) Method and apparatus for obtaining connection information of configuration point
CN115208809A (en) Method and device for determining path
CN114124753A (en) Message sending method and equipment
CN116193463A (en) Data processing method, message sending method and device
CN117478580A (en) Method for sending load information, method and device for sending message

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication