Topologieinformationsveröffentlichungsverfahren, netzwerktopologiesammelverfahren und vorrichtung

Abstract

The present application relates to the technical field of networks. Provided are a topology information publishing method, a network topology collecting method, and a device. According to the present application, during topology delivery, intra-domain topology and inter-domain topology each carry a node identifier, and the same node identifier is carried in intra-domain topology and inter-domain topology, thereby facilitating a controller device using the same node identifier to automatically associate intra-domain topology information with inter-domain topology, reducing the complexity of network configuration, and improving the topology collecting efficiency of the controller device.

Description

Topology information publishing method, network topology collection method and device

[0001] This application claims priority to the Chinese patent application with application number 202011217967.7 filed on November 4, 2020, and invention name “Method for publishing topology information, network topology collection method and device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of network technology, and in particular to a method for publishing topology information, a method for collecting network topology, and a device. Background Art

[0003] When collecting topology, the controller device needs to use network information to obtain end-to-end topology or path information. In related technologies, a large number of complex configuration operations need to be performed manually on the controller device. The controller device obtains the above end-to-end topology information based on the configuration operations, which is complex to configure.

[0004] Summary of the Invention

[0005] The present invention provides a method for publishing topology information, a method for collecting network topology, and a device, which can improve the efficiency of topology collection by a controller device. The technical solution is as follows:

[0006] In a first aspect, a method for publishing topology information is provided, in which a first network device obtains a node identifier; the first network device publishes intra-domain topology information and inter-domain topology information to a controller device based on the node identifier, wherein the intra-domain topology information and the inter-domain topology information both include the node identifier, the intra-domain topology information is used to indicate the topology within the first domain, and the inter-domain topology information is used to indicate the topology between the first domain and the second domain, and the first domain is the domain to which the first network device belongs.

[0007] In the method provided above, the network device carries node identifiers in both the intra-domain topology and the inter-domain topology when uploading the topology, and the intra-domain topology and the inter-domain topology carry the same node identifier, which helps the controller device to automatically associate the intra-domain topology information with the inter-domain topology using the same node identifier, reducing the complexity of the network configuration and thus improving the efficiency of the controller device in collecting topology.

[0008] In one possible implementation, the first network device publishes intra-domain topology information and inter-domain topology information to the controller device based on the node identifier, including: the first network device sends a first border gateway protocol link-state (BGP LS) message to the controller device, and the first BGP LS message includes at least one of the intra-domain topology information or the inter-domain topology information.

[0009] In the implementation provided above, by extending the BGP LS protocol message, BGP LS is used to upload the topology containing node identifiers. When applied in a scenario based on BGP LS topology collection, the uploaded topology and the collected topology can be implemented using the same protocol, thereby reducing the types of protocols that the device needs to support and reducing implementation complexity.

[0010] In one possible implementation, the first BGP LS message includes a BGP-LS node route, and the BGP-LS node route includes the node identifier; or, the first BGP LS message includes a BGP LS route of a target route type, and the BGP LS route of the target route type includes device global information, and the device global information includes the node identifier; or, the first BGP LS message includes a BGP-LS link route, and the BGP-LS link route includes the node identifier; or, the first BGP LS message includes an Internet Protocol version 6 segment routing (segment routing internet protocol version 6, SRv6) segment identifier (segment ID, SID) route, and the SRv6 SID route includes the node identifier.

[0011] The above implementations address more application scenarios by using BGP-LS node routes, BGP-LS link routes, or SRv6 SID routes to carry node identifiers, or by adding a new BGP LS route that carries node identifiers for sending global device information.

[0012] In a possible implementation, the routing attribute field in the first BGP LS message includes a node identifier type length value (TLV), the value of the node identifier TLV includes the node identifier, and the type of the node identifier TLV is used to identify that the node identifier TLV carries the node identifier.

[0013] In the implementation provided above, a new TLV is added to carry the node identifier, so that the controller device can directly obtain the node identifier from the newly added TLV, thereby reducing network configuration.

[0014] In a possible implementation manner, the routing attribute field is a node attribute field or a link attribute field.

[0015] In a possible implementation, the node identifier is used to identify the first network device; or, the node identifier is used to identify a second network device, the second network device belongs to the first domain, and the second network device is a boundary routing device between the first domain and the second domain.

[0016] In one possible implementation, when the node identifier is used to identify the second network device, before the first network device publishes intra-domain topology information and inter-domain topology information to the controller device based on the node identifier, the method also includes: the first network device receives the node identifier sent by the second network device.

[0017] In a possible implementation, the first network device receives the node identifier sent by the second network device, including: the first network device receives an internal gateway protocol (IGP) message sent by the second network device, the IGP message including the node identifier; or, the first network device receives a second BGP-LS message sent by the second network device, the second BGP-LS message including the node identifier.

[0018] In one possible implementation, before the first network device publishes intra-domain topology information and inter-domain topology information to the controller device based on the node identifier, the method also includes: the first network device receives a third BGP-LS message sent by the second network device, and the third BGP-LS message includes the inter-domain topology information.

[0019] In one possible implementation, the node identifier includes one or more of the following: a BGP node identifier, an IGP node identifier, a traffic engineering (TE) node identifier, a system ID, an Internet Protocol version 4 (IPv4) local node identifier, and an Internet Protocol version 6 (IPv6) local node identifier.

[0020] In a second aspect, a network topology collection method is provided, in which a controller device receives intra-domain topology information and inter-domain topology information, wherein the intra-domain topology information and the inter-domain topology information both include a node identifier, wherein the node identifier is used to identify the network device, the intra-domain topology information is used to indicate the topology within a first domain, and the inter-domain topology information is used to indicate the topology between the first domain and a second domain, wherein the first domain is the domain to which the network device belongs; the controller device establishes an association relationship between the intra-domain topology information and the inter-domain topology information based on the node identifier.

[0021] In the method provided above, when the controller device collects the topology, it uses the same node identifier to associate the intra-domain topology information with the inter-domain topology, avoiding the huge workload brought by manually configuring consistent node identifiers, thereby reducing the complexity of network configuration, thereby improving the efficiency of the controller device in collecting topology and facilitating the controller device to calculate the end-to-end forwarding path based on the associated topology.

[0022] In one possible implementation, the node identifier is used to identify a first network device, and the controller device receives intra-domain topology information and inter-domain topology information, including: the controller device receives the intra-domain topology information and the inter-domain topology information sent by the first network device; or, the controller device receives the intra-domain topology information and the inter-domain topology information sent by a second network device, and the second network device and the first network device both belong to the first domain; or, the controller device receives the intra-domain topology information sent by the first network device, and the controller device receives the inter-domain topology information sent by the second network device; or, the controller device receives the inter-domain topology information sent by the first network device, and the controller device receives the intra-domain topology information sent by the second network device.

[0023] In a third aspect, a method for publishing a node identifier is provided, in which a second network device publishes a node identifier to a first network device, wherein the node identifier is used to identify the second network device, and the node identifier is used to associate intra-domain topology information with inter-domain topology information, the intra-domain topology information is used to indicate the topology within the first domain, and the inter-domain topology information is used to indicate the topology between the first domain and the second domain, the first domain is the second network device and the domain to which the first network device belongs, and the second network device is a boundary routing device between the first domain and the second domain.

[0024] In the method provided above, the border routing device notifies the network devices in the same domain of its own node identifier, so that the network devices can carry the node identifier of the border routing device in the intra-domain topology and inter-domain topology respectively and send them to the controller device. Therefore, the controller device can use the same node identifier to automatically associate the intra-domain topology information with the inter-domain topology, avoiding the huge workload brought by manually configuring consistent node identifiers, reducing the complexity of network configuration, and thus improving the efficiency of the controller device in collecting topology.

[0025] In one possible implementation, the second network device publishes a node identifier to the first network device, including: the second network device floods an IGP message within the first domain, the IGP message including the node identifier; or the second network device sends a BGP-LS message to the first network device, the BGP-LS message including the node identifier.

[0026] In a possible implementation, the node identifier includes one or more of the following: a BGP node identifier, an IGP node identifier, a TE node identifier, a system ID, an IPv4 local node identifier, and an IPv6 local node identifier.

[0027] In a fourth aspect, a network device is provided, which has the function of implementing the first aspect or any optional manner of the first aspect. The network device includes at least one unit, and the at least one unit is used to implement the method provided by the first aspect or any optional manner of the first aspect.

[0028] In some embodiments, the units in the network device provided in the fourth aspect are implemented by software, and the units in the network device are program modules. In other embodiments, the units in the network device provided in the fourth aspect are implemented by hardware or firmware. The specific details of the network device provided in the fourth aspect can be found in the first aspect or any optional embodiment of the first aspect, and will not be repeated here.

[0029] In a fifth aspect, a controller device is provided, wherein the controller device has the function of implementing the second aspect or any optional manner of the second aspect. The controller device includes at least one unit, and the at least one unit is used to implement the method provided by the second aspect or any optional manner of the second aspect.

[0030] In some embodiments, the units in the controller device provided in the fifth aspect are implemented via software, and the units in the controller device are program modules. In other embodiments, the units in the controller device provided in the fifth aspect are implemented via hardware or firmware. Specific details of the controller device provided in the fifth aspect can be found in the second aspect or any of the optional embodiments of the second aspect, and are not further described here.

[0031] In a sixth aspect, a network device is provided, which has the function of implementing the third aspect or any optional method of the third aspect. The network device includes at least one unit, and the at least one unit is used to implement the method provided by the third aspect or any optional method of the third aspect.

[0032] In some embodiments, the units in the network device provided in the sixth aspect are implemented by software, and the units in the network device are program modules. In other embodiments, the units in the network device provided in the sixth aspect are implemented by hardware or firmware. The specific details of the network device provided in the sixth aspect can be found in the third aspect or any optional embodiment of the third aspect, and will not be repeated here.

[0033] In a seventh aspect, a network device is provided, comprising a processor and a communication interface. The processor is configured to execute instructions so that the network device performs the method provided in the first aspect or any optional embodiment of the first aspect, and the communication interface is configured to receive or send messages. Specific details of the network device provided in the seventh aspect can be found in the first aspect or any optional embodiment of the first aspect, and are not further described here.

[0034] In an eighth aspect, a controller device is provided, comprising a processor and a communication interface. The processor is configured to execute instructions so that the controller device performs the method provided in the second aspect or any optional embodiment of the second aspect, and the communication interface is configured to receive or send messages. Specific details of the controller device provided in the eighth aspect can be found in the second aspect or any optional embodiment of the second aspect, and are not further described here.

[0035] In a ninth aspect, a network device is provided, comprising a processor and a communication interface. The processor is configured to execute instructions so that the network device performs the method provided in the third aspect or any optional embodiment of the third aspect, and the communication interface is configured to receive or send messages. Specific details of the network device provided in the ninth aspect can be found in the third aspect or any optional embodiment of the third aspect, and are not further described here.

[0036] In a tenth aspect, a network device is provided, comprising: a main control board and an interface board. Furthermore, the network device may also include a switching network board. The network device is configured to perform the method of the first aspect or any possible implementation of the first aspect. Specifically, the network device includes a unit configured to perform the method of the first aspect or any possible implementation of the first aspect.

[0037] In an eleventh aspect, a controller device is provided, comprising: a main control board and an interface board. Furthermore, the controller device may also include a switching network board. The controller device is configured to execute the method of the second aspect or any possible implementation of the second aspect. Specifically, the controller device includes a unit configured to execute the method of the second aspect or any possible implementation of the second aspect.

[0038] In a twelfth aspect, a network device is provided, comprising: a main control board and an interface board. Furthermore, the network device may also include a switching network board. The network device is configured to perform the method of the third aspect or any possible implementation of the third aspect. Specifically, the network device includes a unit configured to perform the method of the third aspect or any possible implementation of the third aspect.

[0039] In the thirteenth aspect, a computer-readable storage medium is provided, in which at least one instruction is stored. The instruction is read by a processor to enable a network device to execute the method provided in the first aspect or any optional manner of the first aspect.

[0040] In a fourteenth aspect, a computer-readable storage medium is provided, in which at least one instruction is stored. The instruction is read by a processor to enable a controller device to execute the method provided in the second aspect or any optional manner of the second aspect.

[0041] In the fifteenth aspect, a computer-readable storage medium is provided, in which at least one instruction is stored. The instruction is read by a processor to enable a network device to execute the method provided in the third aspect or any optional method of the third aspect.

[0042] In a sixteenth aspect, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a network device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the network device to perform the method provided in the first aspect or any optional embodiment of the first aspect.

[0043] In a seventeenth aspect, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a controller device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the controller device to perform the method provided in the second aspect or any optional embodiment of the second aspect.

[0044] In an eighteenth aspect, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a network device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the network device to perform the method provided in the third aspect or any optional embodiment of the third aspect.

[0045] In the nineteenth aspect, a chip is provided. When the chip runs on a network device, the network device executes the method provided in the first aspect or any optional method of the first aspect.

[0046] In the twentieth aspect, a chip is provided, which, when running on a controller device, enables the controller device to execute the method provided in the second aspect or any optional manner of the second aspect.

[0047] In the twenty-first aspect, a chip is provided. When the chip runs on a network device, the network device executes the method provided in the third aspect or any optional method of the third aspect.

[0048] In aspect 22, a network system is provided, which includes the network device described in aspect 4, aspect 7 or aspect 10 above, and the network system also includes the controller device described in aspect 5, aspect 8 or aspect 11 above, and the network system also includes the network device described in aspect 6, aspect 9 or aspect 12 above. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] FIG1 is a schematic diagram of the architecture of a network system 10 provided in an embodiment of the present application;

[0050] FIG2 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0051] FIG3 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0052] FIG4 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0053] FIG5 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0054] FIG6 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0055] 7 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0056] FIG8 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0057] FIG9 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0058] FIG10 is a flowchart of a method for publishing topology information provided in an embodiment of the present application;

[0059] FIG11 is a schematic structural diagram of a network device 700 provided in an embodiment of the present application;

[0060] FIG12 is a schematic structural diagram of a controller device 800 provided in an embodiment of the present application;

[0061] FIG13 is a schematic structural diagram of a network device 900 provided in an embodiment of the present application;

[0062] FIG14 is a schematic structural diagram of a device 1000 provided in an embodiment of the present application;

[0063] FIG15 is a schematic structural diagram of a device 1100 provided in an embodiment of the present application;

[0064] FIG16 is a schematic structural diagram of a network system 1200 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0066] In this application, the terms "first", "second", etc. are used to distinguish between identical or similar items with substantially the same effects and functions. It should be understood that there is no logical or temporal dependency between "first", "second", and "third", nor is there any limitation on quantity or order of execution. It should also be understood that although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the scope of the various examples, a first BGP-LS message may be referred to as a second BGP-LS message, and similarly, a second BGP-LS message may be referred to as a first BGP-LS message. Both the first BGP-LS message and the second BGP-LS message may be BGP-LS messages, and in some cases, may be separate and different BGP-LS messages.

[0067] The following first explains some terms and features involved in the embodiments of this application.

[0068] (1) Node identity (ID)

[0069] A node identifier is used to identify a network device in a domain. Node identifiers include many specific types. In one example, a node identifier includes one or more of the following: a border gateway protocol router identifier (BGP router-ID), an interior gateway protocol router identifier (IGP router-ID), a traffic engineering router identifier (TE router-ID), a system ID (system-ID), an IPv4 local node identifier (IPv4 router-ID of local node), and an IPv6 local node identifier (IPv6 router-ID of local node).

[0070] (2) BGP router-ID

[0071] The BGP router-ID serves as a unique identifier for the Border Gateway Protocol (BGP) process on a router to interact with BGP processes on other routers. The BGP router-ID is unique within an autonomous system (AS). In one example, the BGP router-ID is represented by an IPv4 address. For example, the BGP router-ID is the Internet Protocol (IP) address of the loopback port or the IP address of a physical port on a network device.

[0072] (3) System ID

[0073] The system ID is used to uniquely identify a device (such as a host or router) within an area. The length of the system ID is, for example, 48 bits (6 bytes).

[0074] (4)TE router-ID

[0075] The TE node identifier is a node ID. The TE router ID is an IP address. For the definition of the TE router ID, see Section 4.3 of the Request for Comments (RFC) in RFC5305.

[0076] (5)IGP

[0077] An IGP is a routing protocol that runs within an AS. Examples of IGP protocols include Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS).

[0078] (6)BGP

[0079] BGP is a dynamic routing protocol used between ASes. It primarily exchanges reachable routing information between ASes, establishes inter-AS propagation paths, prevents routing loops, and applies routing policies at the AS level.

[0080] (7) Topology (topo) information

[0081] Topology information refers to information containing the network topology. Topology information includes, but is not limited to, node information and link information. Node information is information about the devices (nodes) contained in the network. Link information is information about the links between the devices in the network. In one example, the node information in the topology information includes at least one local node descriptor and at least one remote node descriptor. In one example, the topology information includes a protocol ID (protocol-ID). The protocol ID indicates the communication protocol based on which the topology information is collected. In one example, the topology information includes an AS number (AS-number), which is used to identify the AS corresponding to the topology information. The topology information in this embodiment is divided into intra-domain topology information and inter-domain topology information.

[0082] (8) Domain topology information

[0083] Intra-domain topology information indicates the topological relationship within a domain (such as an IGP domain). Intra-domain topology information can be collected through the IS-IS protocol, the OSPF protocol, or other IGP protocols. The protocol ID in the intra-domain topology information is, for example, the ID of the IS-IS protocol, the ID of the OSPF protocol, or the ID of another IGP protocol. In one example, the AS number in the local node description information in the intra-domain topology information is the same as the AS number in the remote node description information. For details on how to collect and report intra-domain topology information, please refer to the RFC7752 protocol.

[0084] (9) Inter-domain topology information

[0085] Interdomain topology information indicates the topological relationships between different domains. Interdomain topology information can be collected using the BGP protocol. The protocol ID in the interdomain topology information is, for example, the BGP protocol ID. In one example, the AS number in the local node description in the interdomain topology information differs from the AS number in the remote node description. For details on how to collect and report interdomain topology information, see the draft-ietf-idr-bgpls-segment-routing-epe protocol.

[0086] (10) Relationship between intra-domain topology information and inter-domain topology information

[0087] Intra-domain topology information includes at least one node identifier. Inter-domain topology information also includes at least one node identifier. Furthermore, the intra-domain topology information and the inter-domain topology information include at least one identical node identifier. Because the intra-domain topology information and the inter-domain topology information contain the same node identifier, the controller device can use the node identifier to automatically associate the intra-domain topology information with the inter-domain topology information, thereby merging the intra-domain and inter-domain topologies. In combination with the various types of node identifiers described above, the relationship between intra-domain topology information and inter-domain topology information applies to various scenarios. The following describes a scenario involving network device A in a network.

[0088] In one example, the intra-domain topology information uses the BGP router-ID of network device A as the node identifier of network device A, and the inter-domain topology information also uses the BGP router-ID of network device A as the node identifier of network device A. Because the intra-domain topology information and the inter-domain topology information include the same BGP router-ID, the controller can automatically associate the intra-domain topology information with the inter-domain topology information using the BGP router-ID.

[0089] In another example, the intra-domain topology information uses the IGP router-ID of network device A as the node identifier of network device A, and the inter-domain topology information also uses the IGP router-ID of network device A as the node identifier of network device A. Because the intra-domain topology information and the inter-domain topology information include the same IGP router-ID, the controller can automatically associate the intra-domain topology information with the inter-domain topology information using the IGP router-ID.

[0090] In another example, the intra-domain topology information uses the system ID of network device A as the node identifier of network device A, and the inter-domain topology information also uses the system ID of network device A as the node identifier of network device A. Because the intra-domain topology information and the inter-domain topology information include the same system ID, the controller can automatically associate the intra-domain topology information with the inter-domain topology information using the system ID.

[0091] (11)BGP LS

[0092] BGP-LS is a method for collecting network topology information. It summarizes topology information collected by IGP protocols and sends it to the upper-layer controller, making topology collection simpler and more efficient.

[0093] (12) BGP routing

[0094] A BGP route consists of two parts: a route prefix and a route attribute. Each BGP route contains a route attribute. A route attribute contains one or more sub-attributes.

[0095] (13) BGP routing attributes

[0096] BGP route attributes are a set of parameters carried in BGP routing information. They further describe routes, expressing the characteristics of each route. This allows receivers to filter and select routes based on their attributes. Route attributes are a key feature that distinguishes BGP from other protocols. BGP performs tasks such as route selection and loop avoidance by comparing route attributes.

[0097] (14) BGP optional non-transitive routing attributes

[0098] The optional non-transitive route attribute is a type of BGP route attribute. If a BGP router does not support this attribute, it is ignored and not advertised to other peers.

[0099] (15) BGP LS routing

[0100] BGP LS routes are a medium for carrying network topology information. BGP-LS routes include six types: nodes, links, route prefixes, IPv6 route prefixes, SRv6 SID routes, and TE policy routes. These routes work together to transmit topology information.

[0101] (16) BGP LS node routing (node ​​routing)

[0102] BGP LS node routing is used to record node information in the topology.

[0103] (17) BGP LS network layer reachability information (NLRI)

[0104] Based on BGP, BGP-LS introduces a series of new NLRIs to carry information about links, nodes, and IPv4 / IPv6 prefixes. These new NLRIs are called link-state NLRIs. Link-state NLRIs are typically carried in attributes of BGP-LS update messages.

[0105] BGP-LS primarily defines the following types of link-state NLRI: node NLRI, link NLRI, IPv4 topology prefix NLRI, and IPv6 topology prefix NLRI. BGP-LS also defines corresponding attributes for these NLRIs, which carry parameters and attributes related to links, nodes, and IPv4 / IPv6 prefixes. BGP-LS attributes are carried in BGP-LS messages in the form of TLVs along with the corresponding NLRI. These attributes are all BGP optional non-transitive attributes, primarily including node attributes, link attributes, and prefix attributes.

[0106] (18) Node NLRI

[0107] The node NLRI is a local node descriptor, which contains a series of node descriptors (structured as sub-TLVs).

[0108] (19) BGP LS attributes

[0109] BGP-LS attributes are carried in BGP-LS messages in the form of TLVs and corresponding NLRIs. BGP-LS attributes are optional, non-transitive attributes of BGP and mainly include node attributes, link attributes, and prefix attributes.

[0110] When IP networks forward traffic, once the traffic reaches a network device, the next hop is determined by querying the IP routing table on that device. Users cannot clearly know the specific path of traffic at the head node. Therefore, when planning their networks, users typically need to add configurations to each network device to direct traffic. Traffic engineering techniques such as segment routing (SR) have been introduced, enabling users to directly customize the entire forwarding path for traffic. This capability requires access to network topology information.

[0111] Topology information can be divided into intra-domain topology and inter-domain topology. After collecting topology information, the controller device calculates end-to-end traffic forwarding paths based on this information, such as the SR policy, to guide traffic forwarding along the specified path. Therefore, the controller device must be able to correctly stitch together the collected intra-domain and inter-domain topologies.

[0112] Currently, when network devices report intra-domain topology information (IGP topology information) via BGP-LS, they use the IPv4 local node identifier as the node identifier. When network devices report inter-domain topology information (BGP topology information) via BGP-LS, they use the BGP router-ID as the node identifier. Because the meanings of these two node identifiers are inconsistent and there is no unified field in BGP-LS messages as a correlation field, controller devices cannot directly use the BGP router-ID and IPv4 local node identifier to splice the intra-domain and inter-domain topologies.

[0113] In one solution provided by the related art, the controller device reads the configuration or queries the forwarding device information through the network configuration (NETCONF) protocol / yang (a data modeling language) interface, and then generates a mapping relationship between the IGP information and the BGP information. However, this method faces many defects. First, it relies on the configuration of the BGP router-ID rather than automatic selection. Second, there are performance issues with NETCONF / yang acquisition, and when the number of devices is large, there is a performance bottleneck. Third, the controller device needs to query the device information regularly because there is no active notification method when the device information changes.

[0114] In another solution provided by the related art, specifically, the BGP router-ID and the IPv4 local node identifier (IPv4 router-ID, TLV 1028) in the routing attributes in the intra-domain topology information are configured to be consistent. Since the BGP information is configured to be the same as the IGP information, the splicing of the inter-domain topology and the intra-domain topology is achieved. However, this method also faces many defects. First, it relies on the configuration of the BGP router-ID rather than automatic selection. Second, when deploying devices, the BGP router-ID and IPv4 local node identifier of each device must be planned in advance. Automatic deployment cannot be achieved and there are great limitations.

[0115] In summary, there is currently no method that can dynamically obtain the association between BGP information (BGP router-ID) and IPv4 local node identifiers, and it is impossible to automatically splice the BGP inter-domain topology and the IGP intra-domain topology.

[0116] In some embodiments of the present application, by expanding the BGP-LS reporting content information, the controller device can dynamically obtain the node identifier of the network device. In this way, when the controller device calculates the end-to-end forwarding path, it can use the node identifier to automatically splice the BGP inter-domain topology and the IGP intra-domain topology. By automatically splicing the BGP inter-domain topology and the IGP intra-domain topology, benefits can be obtained in many application scenarios. For example, when a user deploys an SR (v6) policy for traffic optimization, the controller device uses the spliced ​​network topology to facilitate the calculation of the SR) policy path. For another example, the controller device can display the end-to-end topology to the user.

[0117] The following describes the system operating environment provided by the embodiments of the present application.

[0118] Figure 1 is a schematic diagram of the architecture of a network system 10 provided in an embodiment of the present application. Network system 10 is an example of a networking architecture including a controller device and network devices. Network system 10 supports the controller device in collecting intra-domain topology and inter-domain topology.

[0119] Specifically, the network system 10 includes a plurality of network devices and a controller device 11 .

[0120] The network device is used to collect topology information and upload it to the controller device 11. For example, the network device is a switch or router. The network device includes at least one protocol module, such as an IGP protocol module and a BGP-LS protocol module. The IGP protocol module supports communication between network devices based on the IGP protocol, and the BGP-LS protocol module supports communication between network devices based on the BGP-LS protocol.

[0121] Network devices are categorized into three types: autonomous system boundary routers (ASBRs), provider edge (PE) devices, and customer edge (CE) devices. ASBRs include ASBR1, ASBR2, ASBR3, and ASBR4. ASBR1, ASBR2, ASBR3, and ASBR4 are the border routers between AS1 and AS2. PEs include PE1, PE2, PE3, and PE4. CEs include CE1 and CE2. PE1 and PE2 are connected to CE1. PE3 and PE4 are connected to CE2.

[0122] PE3, PE4, ASBR3, and ASBR4 belong to AS1. There is an intra-AS1 topology between PE3, PE4, ASBR3, and ASBR4. PE1, PE2, ASBR1, and ASBR2 belong to AS2. There is an intra-AS2 topology between PE1, PE2, ASBR1, and ASBR2. There is also an inter-AS1 and AS2 topology between ASBR3, ASBR4, ASBR1, and ASBR2.

[0123] The relationship between different devices in the network system 10 is described in detail below.

[0124] PE3, PE4, ASBR3, and ASBR4 are interconnected using the IGP protocol. IGP neighbor relationships are established between PE3, PE4, ASBR3, and ASBR4. PE3, PE4, ASBR3, and ASBR4 can exchange routing information based on this IGP neighbor relationship. This routing information indicates the intra-AS1 topology.

[0125] PE1, PE2, ASBR1, and ASBR2 are interconnected using the IGP protocol. IGP neighbor relationships are established between PE1, PE2, ASBR1, and ASBR2. PE1, PE2, ASBR1, and ASBR2 can exchange routing information based on the IGP neighbor relationship. This routing information indicates the topology within AS2.

[0126] In one example, ASBR3 and ASBR1 each establish a BGP-LS neighbor relationship with a controller device. Based on the BGP-LS neighbor relationship, ASBR3 or ASBR1 can send BGP-LS messages (such as BGP-LS update messages) to the controller device. The BGP-LS messages sent by ASBR3 carry the intra-domain topology of AS1 and the inter-domain topology between AS1 and AS2. By sending BGP-LS messages to the controller device, ASBR3 reports the intra-domain topology of AS1 and the inter-domain topology between AS1 and AS2 to the controller device. The BGP-LS messages sent by ASBR1 carry the intra-domain topology of AS2 and the inter-domain topology between AS2 and AS1. By sending BGP-LS messages to the controller device, ASBR1 reports the intra-domain topology of AS2 and the inter-domain topology between AS2 and AS1 to the controller device.

[0127] In another example, PE3 and PE1 each establish a BGP-LS neighbor relationship with a controller device. PE3 or PE1 can report BGP-LS messages (such as BGP-LS update messages) to the controller device based on the BGP-LS neighbor relationship. The BGP-LS message sent by PE3 carries the intra-domain topology of AS1 and the inter-domain topology between AS1 and AS2. PE3 reports the intra-domain topology of AS1 and the inter-domain topology between AS1 and AS2 to the controller device by sending BGP-LS messages to the controller device. The BGP-LS message sent by PE1 carries the intra-domain topology of AS2 and the inter-domain topology between AS2 and AS1. PE1 reports the intra-domain topology of AS2 and the inter-domain topology between AS2 and AS1 to the controller device by sending BGP-LS messages to the controller device.

[0128] PE3 and the controller establish a BGP SR policy neighbor relationship (such as a BGP SRv6 policy neighbor relationship).

[0129] The controller device 11 is configured to receive topology information from network devices and perform path planning and calculation based on the topology information. The controller device 11 may be, for example, a host, server, switch, or router. The path calculated by the controller device 11 includes at least one of an intra-domain path and an inter-domain path. An intra-domain path may be, for example, a path within AS1 or a path within AS2. For example, an intra-domain path may be an IGP path between PE3 and ASBR3. An inter-domain path may be, for example, a path between AS1 and AS2. For example, an inter-domain path may be an EPE path between ASBR3 and ASBR2.

[0130] In an example, the controller device 11 establishes a BGP-LS neighbor relationship with the ASBR devices (such as ASBR3 and ASBR1), thereby collecting topology information sent by the ASBR devices (such as ASBR3 and ASBR1) based on the BGP-LS neighbor relationship.

[0131] In another example, the controller device 11 establishes a BGP-LS neighbor relationship with PE devices (such as PE3 and PE1), thereby collecting topology information sent by the PE devices (such as PE3 and PE1) based on the BGP-LS neighbor relationship.

[0132] In the network system 10 shown in FIG1 , when the controller device 11 collects topology information through BGP-LS neighbors, it collects not only intra-domain topology (such as the intra-domain topology of AS1 or AS2) but also inter-domain topology (such as the inter-domain topology between AS1 and AS2). In this scenario, by implementing the technical solutions provided in the embodiments of the present application, the controller device 11 can associate the intra-domain topology with the inter-domain topology.

[0133] The above is an example of the system operating environment. The following is an introduction to the method flow provided in the embodiment of the present application.

[0134] FIG2 is a flow chart of a method 200 for publishing topology information provided in an embodiment of the present application. The method 200 is described by taking the first network device as an example in which the device sending the topology information is a first network device. The interacting subjects of the method 200 include the first network device and a controller device.

[0135] The first network device is, for example, a switch, a router, etc. The first network device is, for example, an ASBR device, a PE device, a route reflector (RR) device, etc. The controller device is, for example, a host, a server, or a personal computer.

[0136] For simplicity, the domain to which the first network device belongs is often referred to as the first domain, and domains other than the domain to which the first network device belongs are referred to as the second domain. For example, the first network device is PE3 or ASBR3 in the system operating environment shown in Figure 1, the first domain is AS1, and the second domain is AS2.

[0137] Optionally, when the first network device is not an ASBR, the interaction subject of method 200 further includes a second network device, where the second network device and the first network device belong to the same domain, and the second network device is a border routing device in the domain to which the first network device belongs. For example, the first network device is PE3 in the system operating environment shown in FIG1 , and the second network device is ASBR3.

[0138] Illustratively, the method 200 includes the following S210 to S240 .

[0139] S210: The first network device obtains a node identifier.

[0140] The relationship between the node identifier obtained by the first network device (the node identifier included in the topology information) and the first network device (the device that sends the topology information) can occur in various situations. The following two situations are used as examples to illustrate this. Situation 1 supports the scenario where the first network device is an ASBR. Situation 2 supports the scenario where the first network device is not an ASBR. For example, when a controller establishes a BGP-LS neighbor relationship with an ASBR, Situation 1 is triggered; when a controller establishes a BGP-LS neighbor relationship with a non-ASBR, Situation 2 is triggered.

[0141] Case 1: The node ID is the node ID of the device that sends topology information.

[0142] In the following scenario, the network device places its node identifier in the topology information and sends it to the controller device. The node identifier in the topology information is used to identify the device sending the topology information. In the scenario where the first network device sends the topology information, step S210 may involve, for example, the first network device obtaining the node identifier of the first network device, which is used to identify the first network device.

[0143] Case 2: The node identifiers included in the topology information are node identifiers of other devices that belong to the same domain as the device that sends the topology information.

[0144] In scenario 2, the network device includes the node identifiers of other devices in its own domain in the topology information and sends it to the controller device. In one example, the network device obtains the node identifier of a border routing device in the domain, includes the node identifier of the border routing device in the topology information, and sends it to the controller device. In the scenario where the first network device sends the topology information, step S210, for example, involves the first network device obtaining the node identifier of a second network device, which is used to identify the second network device. The second network device belongs to the first domain and is a border routing device between the first and second domains.

[0145] In combination with the situation 1 described above, the node identifier in S210 includes one or more of the following: the BGP node identifier of the first network device, the TE node identifier of the first network device, the system ID of the first network device, the IPv4 local node identifier of the first network device, and the IPv6 local node identifier of the first network device.

[0146] In combination with the second situation described above, the node identifier in S210 includes one or more of the following: the BGP node identifier of the second network device, the TE node identifier of the second network device, the system ID of the second network device, the IPv4 local node identifier of the second network device, and the IPv6 local node identifier of the second network device.

[0147] S220: The first network device publishes intra-domain topology information and inter-domain topology information to the controller device according to the node identifier.

[0148] In the scenario where the first network device belongs to the first domain, the intra-domain topology information published by the first network device is used to indicate the topology within the first domain. The inter-domain topology information published by the first network device is used to indicate the topology between the first domain and the second domain. In the first scenario described above, both the intra-domain topology information and the inter-domain topology information include the node identifier of the first network device. In the second scenario described above, both the intra-domain topology information and the inter-domain topology information include the node identifier of the second network device.

[0149] In one example, a first network device uploads topology information based on the BGP LS protocol. Specifically, the first network device generates a first BGP LS message; the first network device sends the first BGP LS message to a controller device. The first BGP LS message includes topology information, and the topology information in the first BGP LS message includes the node identifier described above. In one example, the first BGP LS message is a BGP-LS update message. In one example, the first network device converts the topology information into a BGP-LS route, thereby generating the first BGP LS message.

[0150] The first BGP LS message includes at least one of intra-domain topology information and inter-domain topology information. In other words, the content of the first BGP LS message can include intra-domain topology information, inter-domain topology information, or both. The following describes, using Cases a and b, possible scenarios involving topology information in the first BGP LS message.

[0151] Case a: The first network device encapsulates the intra-domain topology information and the inter-domain topology information into different BGP LS messages respectively.

[0152] Specifically, the first network device sends the intra-domain topology information and the inter-domain topology information to the controller device via multiple BGP LS messages. When this method is adopted, the first BGP LS message includes the following case a-1 and case a-2.

[0153] Case a-1: The first BGP LS message includes intra-domain topology information but does not include inter-domain topology information.

[0154] Specifically, the first network device generates a first BGP LS message based on intra-domain topology information including a node identifier. Furthermore, the first network device generates a fourth BGP LS message based on inter-domain topology information including the node identifier. The first BGP LS message includes intra-domain topology information, and the fourth BGP LS message includes inter-domain topology information. The intra-domain topology information in the first BGP LS message and the inter-domain topology information in the fourth BGP LS message include the same node identifier.

[0155] Case a-2: The first BGP LS message includes inter-domain topology information but does not include intra-domain topology information.

[0156] Specifically, the first network device generates a first BGP LS message based on inter-domain topology information including a node identifier. Furthermore, the first network device generates a fourth BGP LS message based on intra-domain topology information including the node identifier. The first BGP LS message includes inter-domain topology information, and the fourth BGP LS message includes intra-domain topology information. The inter-domain topology information in the first BGP LS message and the intra-domain topology information in the fourth BGP LS message include the same node identifier.

[0157] This embodiment does not limit the sequence for sending the intra-domain topology information and the inter-domain topology information in the scenario a described above. In one example, the first network device first sends the intra-domain topology information and then sends the inter-domain topology information. Specifically, the first network device first sends a BGP LS message containing the intra-domain topology information to the controller device, and then sends a BGP LS message containing the inter-domain topology information to the controller device. In another example, the first network device first sends the inter-domain topology information and then sends the intra-domain topology information. Specifically, the first network device first sends a BGP LS message containing the inter-domain topology information to the controller device, and then sends a BGP LS message containing the intra-domain topology information to the controller device.

[0158] Case b: The first network device encapsulates the intra-domain topology information and the inter-domain topology information into the same BGP LS message.

[0159] Specifically, the first network device generates a first BGP LS message based on the intra-domain topology information and the inter-domain topology information that include the same node identifier. The first BGP LS message includes the intra-domain topology information and the inter-domain topology information. For example, if the intra-domain topology information and the inter-domain topology information correspond to the same routing attribute, and the intra-domain topology information and the inter-domain topology information correspond to different routing prefixes, the first network device packages the intra-domain topology information and the inter-domain topology information into the same BGP-LS update message (the first BGP LS message).

[0160] As mentioned in (15) of the terminology introduction section above, BGP LS involves many different route types. The first network device may use various BGP LS routes that carry node identifiers. The following uses route types 1 through 4 as examples to illustrate the types of routes that carry node identifiers.

[0161] Route type 1: Routes that carry node identifiers are BGP-LS node routes.

[0162] The first network device encapsulates the node identifier into a BGP-LS node route, thereby generating a first BGP LS message. The first BGP LS message includes the BGP-LS node route, and the BGP-LS node route includes the node identifier.

[0163] Route type 2, the route type that carries a node identifier, is a newly added BGP-LS route type.

[0164] This embodiment adds a new BGP-LS route type, which is used to report global device information.

[0165] The device global information includes one or more node identifiers. For example, the device global information includes at least two of a BGP node identifier, a TE node identifier, a system ID, an IPv4 local node identifier, and an IPv6 local node identifier. Optionally, the device global information also includes other device information besides the node identifier.

[0166] For the convenience of description, this newly added BGP-LS route type is referred to as the target route type below. The target route type refers to a type of BGP LS route that carries device-global information. The first network device encapsulates the node identifier into the target BGP-LS route, thereby generating a first BGP LS message. The first BGP LS message includes a target BGP-LS route, and the BGP LS route of the target route type includes a route prefix and route attributes. The route attributes in the BGP LS route of the target route type include device-global information. The overall message format of the target BGP-LS route can be referred to the relevant introduction in Table 4 below.

[0167] For example, the target route type is called a physical node route. The physical node route includes a physical node NLRI field and a physical node attribute field. The physical node NLRI field is used to carry the route prefix. The physical node NLRI field includes an NLRI type value. The NLRI type value in the physical node NLRI field is different from the NLRI type value in the existing BGP-LS routes (BGP-LS node routes, BGP-LS link routes, etc.). The NLRI type value in the physical node NLRI field is used to identify that the type of BGP LS route is a physical node route. The physical node attribute field is used to carry route attributes. The physical node attribute field includes device global information.

[0168] A new BGP-LS route type, used to report global device information, can be used to perform topology association using the node identifiers carried in this new BGP-LS route type in various scenarios, including reporting topology in pure IPv6 networks, reporting topology in BGP SR networks, reporting static routing link information, and reporting direct link information. This facilitates data connectivity between data sources. For example, when reporting BGP SR topology via BGP-LS, the new route type can carry the BGP router-ID. When reporting static routing link information via BGP-LS, the new route type can carry the system-ID. Because the new route type reports the BGP router-ID and system-ID to the controller, the controller can use the BGP router-ID and system-ID to associate BGP SR network topology information with static routing link information.

[0169] Route type 3: The route type that carries a node identifier is a BGP-LS link route.

[0170] For example, the first network device encapsulates the node identifier into a BGP-LS link route, thereby generating a first BGP LS message. The first BGP LS message includes the BGP-LS link route, and the BGP-LS link route includes the node identifier.

[0171] Route type 4: Routes that carry node identifiers are BGP-LS SRv6 SID routes.

[0172] For example, the first network device encapsulates the node identifier into a BGP-LS SRv6 SID route, thereby generating a first BGP LS message. The first BGP LS message includes the BGP-LS SRv6 SID route, and the BGP-LS SRv6 SID route includes the node identifier.

[0173] The methods described in route type three and route type four help support peer egress traffic engineering (EPE) scenarios. Specifically, in the EPE scenario, the first network device needs to notify the controller device of peer-node information and peer-adjacency (peer-adj) information. When the first network device notifies the peer-node information, it can carry the node identifier in the BGP-LS link route or the BGP-LS SRv6 SID route. When the first network device notifies the peer-adj information, it can carry the node identifier in the BGP-LS link route.

[0174] The above describes several possible BGP LS route types that carry node identifiers, using route types 1 through 4. There are various ways to carry node identifiers in the BGP LS routes described above. In one example, the node identifier is carried via a TLV in the route attribute field. Specifically, the route attribute field in the first BGP LS message includes a node identifier TLV.

[0175] A Node Identification TLV refers to a TLV that carries any of the node identifiers described above. A Node Identification TLV includes a Type field, a Length field, and a Value field. The Type field in a Node Identification TLV includes the type of the Node Identification TLV. The Type field of the Node Identification TLV is used to identify that the Node Identification TLV carries a node identifier. The Length field in a Node Identification TLV includes the length of the node identifier. The Value field in a Node Identification TLV includes the node identifier. In one example, the Node Identification TLV is a sub-TLV. A sub-TLV is another TLV included within a TLV.

[0176] This embodiment does not limit the routing attribute field in which the node identifier TLV is carried. In one example, the node identifier TLV is carried in the node attribute field of the first BGP LS message. In another example, the node identifier TLV is carried in the link attribute field of the first BGP LS message.

[0177] There are multiple ways to implement the node identifier TLV. The following uses implementation method I and implementation method II as examples to illustrate.

[0178] Implementation method I: Add a new type of TLV as the node identification TLV.

[0179] Specifically, a TLV for carrying a node identifier is added to the routing attributes of BGP LS.

[0180] For example, if the node identifier is a BGP router-ID, a new type of TLV is added to the BGP LS routing attributes to carry the BGP router-ID. Specifically, the node identifier TLV is a BGP Node Identifier TLV. The type of the BGP Node Identifier TLV is used to identify the TLV carrying the BGP router-ID. The value of the BGP Node Identifier TLV includes the BGP router-ID. For example, the format of the BGP Node Identifier TLV is shown in Table 1 below.

[0181] Table 1

[0182]

[0183] In Table 1, the sub-TLV type field indicates the type field of the BGP Node Identifier TLV. The value of the sub-TLV type field indicates that the TLV is a TLV that carries the BGP router ID. The length field in Table 1 indicates the length field of the BGP Node Identifier TLV. Table 1 uses a length field value of 4 as an example.

[0184] The BGP node identifier TLV and the various routing types described above can be combined in any manner. The following describes some of these combinations.

[0185] In conjunction with route type 1 described above, a BGP-LS node route is used to carry a BGP node identifier TLV. The first BGP LS message includes a BGP-LS node route, which includes a BGP node identifier TLV. For example, the route attribute field in the BGP-LS node route includes a BGP node identifier TLV. When using this method, the BGP node identifier can be understood as a sub-attribute of the route attributes in the BGP-LS node route.

[0186] In conjunction with the second route type described above, the newly added BGP-LS route type carries a BGP node identifier TLV. Specifically, the first BGP LS message includes a BGP LS route (physical node route) of the target route type, and the BGP LS route of the target route type includes a BGP node identifier TLV. For example, the route attribute field in the target route type includes a BGP node identifier TLV. When this method is used, the BGP node identifier can be understood as a sub-attribute of the route attributes in the newly added BGP-LS route type.

[0187] In conjunction with route type three described above, a BGP-LS link route is used to carry a BGP Node Identifier TLV. The first BGP LS message includes a BGP-LS link route, which includes a BGP Node Identifier TLV. For example, the route attribute field in the BGP-LS link route includes a BGP Node Identifier TLV. When this method is used, the BGP Node Identifier can be understood as a sub-attribute of the route attributes in the BGP-LS link route.

[0188] In conjunction with route type 4 described above, a BGP-LS SRv6 SID route is used to carry a BGP Node Identifier TLV. The first BGP LS message includes a BGP-LS SRv6 SID route, which includes a BGP Node Identifier TLV. For example, the route attribute field in the BGP-LS SRv6 SID route includes a BGP Node Identifier TLV. When this method is used, the BGP Node Identifier can be understood as a sub-attribute of the route attributes in the BGP-LS SRv6 SID route.

[0189] The preceding example uses the BGP Node Identifier TLV to illustrate how to add a TLV to BGP LS route attributes to carry node identifiers. Depending on the type of node identifier, the BGP Node Identifier TLV can be replaced with another type of node identifier TLV, such as the System ID TLV or the TE Node Identifier TLV. The following uses the System ID TLV as an example for detailed explanation.

[0190] For example, when the node identifier is a system ID, a new type of TLV is added to the BGP LS route attributes to carry the system ID. Specifically, the node identifier TLV is a system ID TLV. The type of the system ID TLV is used to identify the TLV carrying the system ID. The value of the system ID TLV includes the system ID. For example, the format of the system ID TLV is shown in Table 2 below.

[0191] Table 2

[0192]

[0193] In Table 2, "sub TLV type" indicates the type field of the System ID TLV. The value of the "sub TLV type" field indicates that the TLV is a TLV that carries the System ID. "length" in Table 2 indicates the length field of the System ID TLV. Table 2 uses a length field value of 4 or 16 as an example.

[0194] The System ID TLV and the various routing types described above can be combined in any manner. The following describes some of these combinations.

[0195] In conjunction with route type 1 described above, a BGP-LS node route is used to carry a system ID TLV. The first BGP LS message includes a BGP-LS node route, which includes a system ID TLV. For example, the route attribute field in the BGP-LS node route includes a system ID TLV. When using this method, the system-ID can be understood as a sub-attribute of the route attributes in the BGP-LS node route.

[0196] In combination with the route type 2 described above, the newly added BGP-LS route type carries a system ID TLV. Specifically, the first BGP LS message includes a BGP LS route (physical node route) of the target route type, and the BGP LS route of the target route type includes a system ID TLV. For example, the route attribute field in the target route type includes a system ID TLV. When this method is used, system-ID can be understood as a sub-attribute of the route attributes in the newly added type of BGP-LS route.

[0197] In conjunction with route type 3 described above, a BGP-LS link route carries a system ID TLV. The first BGP LS message includes a BGP-LS link route, which includes a system ID TLV. For example, the route attribute field in the BGP-LS link route includes a system ID TLV. When using this approach, system-ID can be understood as a sub-attribute of the route attributes in the BGP-LS link route. The format of the BGP-LS link route is described in Table 5 below.

[0198] In combination with the route type 4 described above, a BGP-LS SRv6 SID route is used to carry a system ID TLV. The first BGP LS message includes a BGP-LS SRv6 SID route, and the BGP-LS SRv6 SID route includes a system ID TLV. For example, the route attribute field in the BGP-LS SRv6 SID route includes a system ID TLV. When this method is used, system-ID can be understood as a sub-attribute of the route attribute in the BGP-LS SRv6 SID route.

[0199] Implementation method II: Use the defined type of TLV as the node identifier TLV.

[0200] For example, when the node identifier is an IPv4 router-ID of local node, the node identifier TLV is an IPv4 router-ID of local node TLV. The type field in the IPv4 router-ID TLV includes 1028, that is, the type value is 1028. The value field in the IPv4 router-ID TLV includes the IPv4 local node identifier.

[0201] For example, when the node identifier is an IPv6 router-ID of local node, the node identifier TLV is an IPv6 router-ID of local node TLV. The type field in the router-ID TLV includes 1029, that is, the type value is 1029. The value field in the router-ID TLV includes the IPv6 local node identifier.

[0202] For detailed explanations of the two TLVs, the router IPv4 identifier TLV and the IPv4 router-ID of local node TLV, refer to RFC7752 and are not detailed here.

[0203] Possible implementations of the Node Identifier TLV have been described above through Implementation Methods I and II. This embodiment does not limit the number of Node Identifier TLVs in a BGP LS message. For example, a first BGP LS message includes one or more Node Identifier TLVs. In one example, the first BGP LS message includes multiple Node Identifier TLVs, each carrying a type of node identifier. For example, the first BGP LS message includes a BGP Node Identifier TLV and a System ID TLV. In this way, multiple node identifiers of the same device can be reported to the controller device via a single BGP LS message.

[0204] S230: The controller device receives intra-domain topology information and inter-domain topology information from the first network device.

[0205] The controller device receives a first BGP LS message from the first network device and obtains at least one of intra-domain topology information or inter-domain topology information from the first BGP LS message.

[0206] Specifically, in the aforementioned scenario a, the controller device receives not only the first BGP LS message but also the fourth BGP LS message. In scenario a-1, the controller device obtains intra-domain topology information from the first BGP LS message and inter-domain topology information from the fourth BGP LS message. In scenario a-2, the controller device obtains inter-domain topology information from the first BGP LS message and intra-domain topology information from the fourth BGP LS message. In the aforementioned scenario b, the controller device receives the first BGP LS message and obtains both intra-domain and inter-domain topology information from the first BGP LS message.

[0207] S240: The controller device establishes an association relationship between the intra-domain topology information and the inter-domain topology information according to the node identifier.

[0208] Since the intra-domain topology information and the inter-domain topology information include the same node identifier, the controller device can use the node identifier as an association field between the intra-domain topology information and the inter-domain topology information to splice the intra-domain topology information with the inter-domain topology information.

[0209] For example, if the node identifier is a BGP router ID, the controller device collects intra-domain topology information through BGP-LS, which includes the BGP router ID. The controller device also collects inter-domain link information through BGP-LS, which also includes the BGP router ID. The controller device can use the BGP router ID to correlate the intra-domain topology with the inter-domain topology.

[0210] For example, if the node identifier is an IPv4 local node identifier, the inter-domain topology information collected by the controller via BGP-LS includes the IPv4 local node identifier. The intra-domain link information collected by the controller via BGP-LS also includes the IPv4 local node identifier. The controller can use the IPv4 local node identifier to correlate the intra-domain topology with the inter-domain topology.

[0211] For example, if the node identifier is a system ID, the inter-domain topology information collected by the controller through BGP-LS includes the system ID. The intra-domain link information collected by the controller through BGP-LS also includes the system ID. The controller can use the system ID to correlate the intra-domain and inter-domain topologies.

[0212] In combination with the routing type 2 introduced above, the controller device obtains the device global information from the first BGP LS message. The controller device generates a mapping relationship table based on the device global information. The mapping relationship table contains the correspondence between different types of node identifiers of the same device (such as the first network device or the second network device). For example, the mapping relationship table is shown in Table 3 below. When the controller device collects inter-domain link information and intra-domain link information through BGP-LS, it can realize link splicing according to the mapping relationship table through the BGP router-ID in the inter-domain link and the TE router-ID carried in the IPv4 router-ID of local node field of the intra-domain IGP.

[0213] Table 3

[0214] BGP router-IDTE router-IDsystem-ID

[0215] The method provided in this embodiment is that, since the network device carries the same node identifier in the intra-domain topology information and the inter-domain topology information when uploading the topology, the controller device can automatically associate the intra-domain topology information with the inter-domain topology information using the received node identifier, thereby reducing the complexity of the network configuration and improving the efficiency of the controller device in collecting the topology.

[0216] Furthermore, it helps the controller device automatically realize the normal splicing of intra-domain links and inter-domain links, making it easier for the controller device to calculate end-to-end topology or path information.

[0217] Furthermore, the controller device does not need to obtain the mapping relationship between the IPv4 local node identifier and the BGP node identifier through a configuration reading method such as NETCONF / yang, thereby reducing configuration operations.

[0218] Furthermore, when the controller device collects topology information, the network device does not need to enforce consistency between the IPv4 local node identifier and the BGP node identifier, thereby improving flexibility.

[0219] In the above method 200, how the first network device obtains the node identifier includes multiple specific implementations, which are illustrated below by using implementation (1) and implementation (2). Implementation (1) supports the case where the first network device is an ASBR device. Implementation (2) supports the case where the first network device is not an ASBR device, but the second network device is an ASBR device.

[0220] Implementation method (1): The first network device obtains a locally stored node identifier.

[0221] Specifically, the first network device obtains the node identifier through one or more protocol modules of the first network device. For example, the BGP protocol module in the first network device collects the BGP node identifier, system ID, and TE node identifier of the first network device.

[0222] In one example, a first network device includes protocol modules corresponding to multiple protocol types, and the different protocol modules within the first network device interact to obtain a node identifier. For example, a BGP-LS protocol module in the first network device collects an IPv4 local node identifier or an IPv6 local node identifier from an IGP protocol module. In another example, an IGP protocol module in the first network device collects a BGP node identifier from a BGP protocol module.

[0223] Implementation method (2): The first network device interacts with the second network device to obtain a node identifier.

[0224] The second network device sends its own node identifier to the first network device, allowing the first network device to obtain the node identifier of the second network device. Specifically, the second network device issues the node identifier to the first network device, and the first network device receives the node identifier sent by the second network device. The node identifier is used to identify the second network device.

[0225] There are multiple specific implementations for how the second network device publishes the node identifier, which are described below using implementation (2-1) and implementation (2-2) as examples.

[0226] Implementation method (2-1): The second network device publishes a node identifier based on the IGP protocol.

[0227] Specifically, the second network device generates an IGP message, the IGP message including the node identifier of the second network device. The second network device floods the IGP message within the first domain (IGP domain). The first network device receives the IGP message sent by the second network device. The first network device obtains the node identifier of the second network device from the IGP message.

[0228] For example, when the node identifier is a BGP node identifier, the specific process of method A includes: the IGP protocol module in the second network device collects the BGP router-ID from the BGP protocol module of the second network device. When the IGP protocol module in the second network device floods the LSDB, the IGP protocol module in the second network device carries the collected BGP router-ID in an IGP message and floods the IGP message to the surrounding neighbor (the first network device). When the first network device receives the IGP message, it obtains the BGP router-ID from the IGP message and stores the BGP router-ID in the LSDB.

[0229] The second network device floods IGP messages carrying the BGP router-ID, enabling every device in the IGP domain (such as the first network device) to obtain the second network device's BGP router-ID through the IGP message. Consequently, when the controller device establishes a BGP-LS neighbor relationship with the first network device but not with the second network device, since the first network device has the second network device's BGP router-ID, the first network device is responsible for sending the second network device's BGP router-ID to the controller device via a BGP-LS message. This ensures that the controller device obtains the second network device's BGP router-ID, helping to overcome the limitations imposed by the networking architecture.

[0230] There are many ways to carry a node identifier in an IGP message. In one example, a new TLV is added to the IGP message to carry the node identifier. Specifically, the IGP message sent by the second network device includes a node identifier TLV. The node identifier TLV is, for example, carried in a link-state advertisement (LSA) message in the IGP protocol. For example, when the node identifier is a BGP node identifier, the IGP message includes a BGP node identifier TLV. The format of the BGP node identifier TLV can refer to the relevant introduction in Table 1 above. By carrying the BGP node identifier TLV in the IGP message, the BGP node identifier can be used as an attribute of the IGP flooding and flooded within the domain through the IGP.

[0231] Implementation method (2-2): The second network device announces the node identifier based on the BGP-LS protocol.

[0232] Specifically, the second network device generates a second BGP LS message and sends the second BGP LS message to the first network device through the BGP-LS neighbor relationship between the second network device and the first network device.

[0233] The second BGP LS message includes the node identifier of the second network device.

[0234] The second BGP LS message can be arbitrarily combined with the features related to the four routing types described above. For example, in combination with the above-mentioned routing type one, the second BGP LS message includes a BGP-LS node route, and the BGP-LS node route includes the node identifier of the second network device. In combination with the above-mentioned routing type two, the second BGP LS message includes a BGP LS route of the target routing type, and the BGP LS route of the target routing type includes device-global information, and the device-global information includes the node identifier of the second network device. In combination with the above-mentioned routing type three, the second BGP LS message includes a BGP-LS link route, and the BGP-LS link route includes the node identifier of the second network device. In combination with the above-mentioned routing type four, the second BGP LS message includes an SRv6 SID route, and the SRv6 SID route includes the node identifier of the second network device.

[0235] The second BGP LS message can be combined with any of the features related to the Node Identifier TLV described above. For example, the routing attribute field in the second BGP LS message includes a Node Identifier TLV. Node Identifier TLVs include, but are not limited to, at least one of a BGP Node Identifier TLV, a System ID TLV, a Router IPv4 Identifier TLV, and a Router IPv6 Identifier TLV.

[0236] The manner in which the second BGP LS message carries the node identifier is similar to the manner in which the first BGP LS message carries the node identifier. For implementation details, please refer to the above introduction to the first BGP LS message.

[0237] In the above method 200, how the first network device obtains inter-domain topology information includes multiple specific implementations. For example, when the first network device is an ASBR device, the first network device collects the inter-domain topology information. In another example, when the first network device is not an ASBR device and the second network device is an ASBR device, the first network device receives the inter-domain topology information sent by the second network device. Specifically, the second network device generates a third BGP-LS message, and the third BGP-LS message includes the inter-domain topology information. The second network device sends the third BGP-LS message to the first network device. The first network device receives the third BGP-LS message sent by the second network device. The first network device obtains the inter-domain topology information from the third BGP-LS message. The third BGP-LS message is, for example, a BGP-LS update message.

[0238] The above method 200 is described by taking the example that the same device (first network device) is responsible for sending the intra-domain topology information and the inter-domain topology information. In another example, different devices are responsible for sending the intra-domain topology information and the inter-domain topology information, which is described in detail below.

[0239] For example, a first network device sends intra-domain topology information to a controller device; a second network device sends inter-domain topology information to the controller device. The controller device receives the intra-domain topology information from the first network device, and the controller device receives the inter-domain topology information sent by the second network device. The intra-domain topology information sent by the first network device and the inter-domain topology information sent by the second network device include the same node identifier.

[0240] In another example, a first network device sends inter-domain topology information to a controller device; a second network device sends intra-domain topology information to the controller device. The controller device receives the inter-domain topology information from the first network device, and the controller device receives the intra-domain topology information from the second network device. The inter-domain topology information sent by the first network device and the intra-domain topology information sent by the second network device include the same node identifier.

[0241] The manner in which the second network device sends the topology information is similar to the manner in which the first network device sends the topology information. For technical details, please refer to the description of sending the topology information on the first network device.

[0242] The above method 200 is described using the example of sending topology information based on the BGP LS protocol. In another example, topology information is sent using a method other than the BGP LS protocol. For example, the path computation element communication protocol (PCEP) is used to send topology information. Specifically, the network device collects topology information, generates a PCEP message based on the topology information, and sends the PCEP message to the controller device. The PCEP message carries a node identifier. For another example, the network device publishes intra-domain topology information and inter-domain topology information to the controller device based on the NETCONF protocol.

[0243] The following describes in detail the message format containing the newly added BGP-LS route type (target route type).

[0244] Refer to Table 4, which illustrates the BGP LS message format. The BGP LS message shown in Table 4 contains a BGP LS route of the target route type. The IPv4 router-ID, IPv6 router-ID, and system-ID in Table 4 illustrate global device information.

[0245] Table 4

[0246]

[0247]

[0248] The numbers 0-4, 5-8, etc. in the first row of Table 4 represent bits. For example, the protocol ID field is located from bit 0 to bit 8. The meaning of each field in Table 4 is described in detail below.

[0249] (1) Physical node NLRI (physical node network layer reachability information)

[0250] Physical node NLRI is a type of node NLRI. Physical node NLRI includes NLRI type field, NLRI length field, protocol ID field, identifier field, and local node descriptor field.

[0251] The value of the (1-1) NLRI Type field is used to indicate that the type of the NLRI is a physical node NLRI. For example, a value of 1 in the NLRI Type field indicates that the NLRI is a physical node NLRI.

[0252] (1-2) The value of the NLRI length field indicates the length of the physical node NLRI. The value of the NLRI length field is variable (var).

[0253] The value of the (1-3) Protocol ID field indicates the protocol number of the source of the topology information, such as IS-IS, OSPF, or BGP. The Protocol ID field is 1 byte long.

[0254] (1-4) The identifier field is used to identify different protocol instances. The length of the identifier field is 4 bytes.

[0255] (1-5) The local node description information includes a type field, a length field, an autonomous system sub-TLV (AS sub-TLV), and a BGP-LS identifier sub-TLV.

[0256] The value of the type field in the local node description information indicates that the information type is local node description information. The value of the type field in the local node description information is, for example, 256. The value of the length field in the local node description information indicates the length of the local node description information. The value of the length field in the local node description information is a variable (var).

[0257] The AS sub-TLV includes a sub-TLV type field, a length field, and an AS field. The value of the sub-TLV type field in the AS sub-TLV identifies the sub-TLV as an AS sub-TLV. For example, a value of 512 in the sub-TLV type field indicates that the sub-TLV is an AS sub-TLV. The value of the length field indicates the length of the value portion of the AS sub-TLV. For example, the value of the length field is 4. The AS field is part of the value portion of the AS sub-TLV. The value of the AS field identifies the AS to which the network device belongs. Specifically, the value of the AS field is a 32-bit AS number.

[0258] The BGP-LS Identifier sub-TLV includes a sub-TLV type field, a length field, and a BGP-LS identifier (BGP-LS ID) field. The value of the sub-TLV type field in the BGP-LS Identifier sub-TLV is used to identify that the type of the sub-TLV is the BGP-LS Identifier sub-TLV. For example, the value of the sub-TLV type field in the BGP-LS Identifier sub-TLV is 513, indicating that it is a BGP-LS Identifier sub-TLV. The value of the length field is used to indicate the length of the value part in the BGP-LS Identifier sub-TLV. The value of the length field is, for example, 4. The BGP-LS Identifier field belongs to the value part of the BGP-LS Identifier sub-TLV. The value of the BGP-LS Identifier field is the BGP-LS identifier to which the network device belongs. For example, the value of the BGP-LS Identifier field is a 32-bit ID.

[0259] (2) Physical node attribute

[0260] The physical node attributes include an attribute flag field, an attribute type field, an attribute length field, a router IPv4 identifier TLV, a router IPv6 identifier TLV, and a system ID TLV.

[0261] The Router IPv4 Identification TLV includes a sub-TLV type field, a length field, and a router IPv4 identification field. The value of the sub-TLV type field is used to identify the sub-TLV type as a Router IPv4 Identification TLV. For example, a value of 1028 in the sub-TLV type field indicates that it is a Router IPv4 Identification TLV. The value of the length field indicates the length of the value portion of the Router IPv4 Identification TLV. For example, the value of the length field is 4. The Router IPv4 Identification field belongs to the value portion of the Router IPv4 Identification TLV. The value of the Router IPv4 Identification field is the Router IPv4 Identification of the local node.

[0262] The Router IPv6 Identification TLV includes a sub-TLV type field, a length field, and a router IPv6 identifier (IPv6 router-ID) field. The value of the sub-TLV type field is used to identify the sub-TLV type as a Router IPv6 Identification TLV. For example, a value of 1029 in the sub-TLV type field in the Router IPv6 Identification TLV indicates that it is a Router IPv6 Identification TLV. The value of the length field indicates the length of the value portion of the Router IPv6 Identification TLV. The value of the length field is, for example, 16. The Router IPv6 Identification field belongs to the value portion of the Router IPv6 Identification TLV. The value of the Router IPv6 Identification field is the Router IPv6 Identification of the local node.

[0263] The System ID TLV includes a sub-TLV type field, a length field, and a system identifier (IPv6 router-ID) field. The value of the sub-TLV type field identifies the sub-TLV as a System ID TLV. The value of the length field indicates the length of the value portion of the System ID TLV. For example, the value of the length field is 4. The System ID field is part of the value portion of the System ID TLV. The value of the System ID field is the system identifier of the local node.

[0264] The following describes the format of a BGP-LS message containing a node identifier TLV.

[0265] Refer to Table 5, which illustrates the BGP LS message format. The BGP LS message shown in Table 5 includes a BGP-LS link route. The BGP-LS link route includes the link attribute field. The link attribute field includes the attribute flag field, attribute type field, attribute length field, router IPv4 identifier TLV, router IPv6 identifier TLV, administrative group TLV, maximum link bandwidth TLV, TE default metric TLV, shared risk link group TLV, and system ID TLV.

[0266] Table 5

[0267]

[0268] The Router IPv4 Identifier TLV, Router IPv6 Identifier TLV, and System ID TLV are examples of Node Identifier TLVs. They carry the IPv4 router ID, IPv6 router ID, and system ID, respectively. TLVs other than the Node Identifier TLV in Table 5 carry link information. For features in Table 5 that are identical to those in Table 4, refer to the description of Table 4 above and are not further elaborated here.

[0269] The method 200 is described below with reference to four examples. PE3 and ASBR3 in the following four examples illustrate the first network device in the method 200 , and the node identifier of ASBR3 in the following four examples illustrates the node identifier in the method 200 .

[0270] Example 1: Use BGP router-ID as the association field between intra-domain links and inter-domain links.

[0271] Example 1 uses the interaction between PE3, ASBR3, and the controller device in Figure 1 as an example. Please refer to Figures 3 and 4, which are both specific flow charts of Example 1. The difference between the flows shown in Figures 3 and 4 is that the flow shown in Figure 3 applies to a network architecture where the controller device and PE3 are BGP LS neighbors, while the flow shown in Figure 4 applies to a network architecture where the controller device and ASBR3 are BGP-LS neighbors. Example 1 specifically includes the following steps: S31 to S34.

[0272] Step S31: The IGP protocol module in ASBR3 collects the BGP router-ID of ASBR3 from the BGP protocol module in ASBR3.

[0273] Step S32: When the IGP protocol module in ASBR3 floods the LSDB to its neighbor (PE3), it floods the collected BGP router ID of ASBR3 to the neighbor (PE3). The BGP router ID can be transmitted using IGP messages such as LSAs. After receiving the BGP router ID of ASBR3, PE3 stores it in the LSDB. A new TLV is added to the IGP message during IGP flooding to carry the BGP router ID of ASBR3. The format of the new TLV is shown in Table 1.

[0274] Step S33: As shown in FIG3 , the BGP-LS protocol module in PE3 collects topology information from the IGP protocol module in PE3. The IGP protocol module in PE3 reports the BGP router ID of ASBR3 as node information to the BGP-LS protocol module in PE3. Alternatively, as shown in FIG4 , the BGP-LS protocol module in ASBR3 collects topology information from the IGP protocol module in ASBR3. The IGP protocol module in ASBR3 reports the BGP router ID of ASBR3 as node information to the BGP-LS protocol module in ASBR3.

[0275] Step S34: As shown in FIG3 , after the BGP-LS protocol module in PE3 collects the IGP topology information (intra-domain topology information), PE3 encapsulates the IGP topology information into a BGP-LS update message and distributes it to the controller device via the BGP-LS neighbor. The BGP-LS node routing attribute carries the BGP router-ID, for example, by adding the TLV shown in Table 1 above.

[0276] Alternatively, as shown in Figure 4, after the BGP-LS protocol module in ASBR3 collects IGP topology information, ASBR3 encapsulates the IGP topology information into a BGP-LS update message, which ASBR3 then publishes to the controller device via its BGP-LS neighbor. The route attributes in the BGP-LS node route carry the BGP router-ID, for example, by adding the TLV shown in Table 1 above.

[0277] In Example 1 above, the controller device collects IGP topology information (intra-domain topology information) through BGP-LS, which includes ASBR3's BGP router-ID. The controller device also collects inter-domain link information through BGP-LS, which also includes ASBR3's BGP router-ID. The controller device uses ASBR3's BGP router-ID to correlate the intra-domain and inter-domain topologies.

[0278] Example 2: Reporting global device information for inter-domain and intra-domain link splicing.

[0279] Example 2 uses the interaction between PE3, ASBR3, and the controller device in Figure 1 as an example. Please refer to Figures 5 and 6, which are both specific flow charts of Example 2. The difference between the flows shown in Figures 5 and 6 is that the flow shown in Figure 5 applies to a network architecture where the controller device and PE3 are BGP LS neighbors, while the flow shown in Figure 6 applies to a network architecture where the controller device and ASBR3 are BGP-LS neighbors. Example 2 specifically includes the following steps S41 through S43.

[0280] Step S41: The BGP-LS protocol module in ASBR3 collects the global device information of ASBR3. The global device information includes, for example, BGP router-ID, TE router-ID, system-ID, and the like.

[0281] Step S42: The BGP-LS protocol module in ASBR3 encapsulates the collected global device information of ASBR3 into a BGP-LS update message (new route type), and publishes it to the neighbor (PE3).

[0282] Step S43: As shown in FIG5 , the BGP-LS protocol module in PE3 encapsulates the collected global device information of ASBR3 into a BGP-LS update message (with a newly added route type), and publishes it to the controller device. Alternatively, as shown in FIG6 , the BGP-LS protocol module in ASBR3 encapsulates the collected global device information of ASBR3 into a BGP-LS update message (with a newly added route type), and publishes it to the controller device. After collecting the global device information of ASBR3 via BGP-LS, the controller device generates a mapping table between the global device information (as shown in Table 3 above).

[0283] In Example 2 above, when the controller device collects inter-domain link and intra-domain link information through BGP-LS, it can implement link splicing based on the mapping table using the BGP router-ID of ASBR3 in the inter-domain link and the TE router-ID of ASBR3 carried in the IPv4 router-ID of local node field of the intra-domain IGP.

[0284] Example 3: Using the IPv4 Router-ID of Local Node or the IPv6 Router-ID of Local Node as the association field between the intra-domain link and the inter-domain link.

[0285] Example 3 uses the interaction between PE3, ASBR3, and the controller device in Figure 1 as an example. Please refer to Figures 7 and 8, which are both detailed flowcharts of Example 3. The difference between the flowcharts shown in Figures 7 and 8 is that the flowchart in Figure 7 applies to a network architecture where the controller device and PE3 are BGP LS neighbors, while the flowchart in Figure 8 applies to a network architecture where the controller device and ASBR3 are BGP-LS neighbors. Example 3 specifically includes the following steps: S51 to S54.

[0286] Step S51: The BGP-LS protocol module in ASBR3 collects the IPv4 local node identifier or IPv6 local node identifier of ASBR3 from the IGP protocol module.

[0287] Step S52: The BGP-LS protocol module in ASBR3 encapsulates the collected IPv4 local node identifier or IPv6 local node identifier in ASBR3 into the EPE BGP-LS update message attributes and generates EPE routing information. The IPv4 local node identifier is carried in the IPv4 router-ID of local node (type 1028), and the IPv6 local node identifier is carried in the IPv6 router-ID of local node (type 1029).

[0288] Step S53: As shown in FIG7 , the BGP-LS protocol module in ASBR3 publishes the BGP-LS EPE route to PE3. The BGP-LS EPE route includes the IPv4 local node identifier or the IPv6 local node identifier in ASBR3.

[0289] Step S54: As shown in FIG7 , the BGP-LS protocol module in PE3 advertises the BGP-LS EPE route containing the IPv4 local node identifier or the IPv6 local node identifier of ASBR3 to the controller device. Alternatively, as shown in FIG8 , the BGP-LS protocol module in ASBR3 advertises the BGP-LS EPE route containing the IPv4 local node identifier or the IPv6 local node identifier of ASBR3 to the controller device.

[0290] In Example 3 above, the controller device collects inter-domain topology information through BGP-LS, which includes the IPv4 local node identifier or IPv6 local node identifier of ASBR3. Specifically, the IPv4 router-ID of local node (type 1028) in the BGP-LS message carries the IPv4 local node identifier of ASBR3; or, the IPv6 router-ID of local node (type 1029) in the BGP-LS message carries the IPv6 local node identifier of ASBR3. In addition, the controller device collects intra-domain link information through BGP-LS, which also includes the IPv4 local node identifier or IPv6 local node identifier of ASBR3. The controller device can associate the intra-domain topology with the inter-domain topology through the IPv4 local node identifier or IPv6 local node identifier of ASBR3.

[0291] Example 4: Use the device ID as the association field between the intra-domain link and the inter-domain link.

[0292] Example 4 uses the interaction between PE3, ASBR3, and the controller device in Figure 1 as an example. Please refer to Figures 9 and 10, which are both specific flow charts of Example 4. The difference between the flows shown in Figures 9 and 10 is that the flow shown in Figure 9 applies to a network architecture where the controller device and PE3 are BGP LS neighbors, while the flow shown in Figure 10 applies to a network architecture where the controller device and ASBR3 are BGP-LS neighbors. Example 4 specifically includes the following steps S61 to S67.

[0293] Step S61: The BGP protocol module on ASBR3 collects the system-ID of ASBR3.

[0294] Step S62: As shown in FIG9 , when the BGP protocol module on ASBR3 generates a BGP-LS EPE route, it adds the system-ID of ASBR3 as a new attribute in the route attributes and publishes it to the peripheral device PE3. The system-ID is carried in the TLV shown in Table 2, for example.

[0295] Step S63: As shown in FIG9 , PE3 advertises the EPE routing information including ASBR3's system ID to the controller device via a BGP-LS neighbor. Alternatively, as shown in FIG10 , ASBR3 advertises the EPE routing information including ASBR3's system ID to the controller device via a BGP-LS neighbor.

[0296] Step S64: The IGP protocol module on ASBR3 collects the system-ID of ASBR3.

[0297] Step S65: The BGP-LS protocol module on ASBR3 collects topology information from the IGP protocol module on ASBR3. The IGP protocol module on ASBR3 reports the system-ID as a new topology attribute to the BGP-LS protocol module on ASBR3. The BGP-LS protocol module encapsulates the topology information (including the newly added system-ID) into a BGP-LS update message. The system-ID is carried, for example, using the TLVs shown in Table 2.

[0298] Step S66: ASBR3 publishes the BGP-LS update message (intra-domain topology information) generated by BGP-LS to PE3 through the BGP-LS neighbor.

[0299] Step S67: As shown in FIG9 , PE3 publishes the BGP-LS update message (domain topology information) generated by BGP-LS to the controller device through the BGP-LS neighbor. Alternatively, as shown in FIG10 , ASBR3 publishes the BGP-LS update message (domain topology information) generated by BGP-LS to the controller device through the BGP-LS neighbor.

[0300] In Example 4 above, the inter-domain topology information collected by the controller via BGP-LS includes ASBR3's system ID. The intra-domain link information collected by the controller via BGP-LS also includes ASBR3's system ID. The controller uses ASBR3's system ID to correlate the intra-domain and inter-domain topologies.

[0301] The method embodiment of the embodiment of the present application is introduced above. The network device and controller device of the embodiment of the present application are introduced below.

[0302] FIG11 shows a possible structural diagram of the first network device involved in the above embodiment. The network device 700 shown in FIG11 implements the functions of the first network device in method 200, ASBR3 in Examples 1 to 4, or PE3 in Examples 1 to 4, for example.

[0303] Referring to FIG. 11 , network device 700 includes an acquisition unit 701 and a publishing unit 702. Each unit in network device 700 is implemented in whole or in part via software, hardware, firmware, or any combination thereof. Each unit in network device 700 is configured to perform the corresponding functions of the first network device, PE3, or ASBR3 described above. For example, acquisition unit 701 is configured to support network device 700 in executing S210. Publishing unit 702 is configured to support network device 700 in executing S220. For another example, acquisition unit 701 is configured to support network device 700 in executing S33. Publishing unit 702 is configured to support network device 700 in executing S34. For another example, acquisition unit 701 is configured to support network device 700 in executing S41. Publishing unit 702 is configured to support network device 700 in executing S43. For another example, acquisition unit 701 is configured to support network device 700 in executing S51 to S52. Publishing unit 702 is configured to support network device 700 in executing S54. For another example, the acquiring unit 701 is used to support the network device 700 in executing S61, S63, S64, and S66, and the issuing unit 702 is used to support the network device 700 in executing S63 and S67.

[0304] In some embodiments, the network device 700 further includes a processing unit, which is configured to support the network device 700 in executing steps related to generating BGP-LS messages in method 200 and examples 1 to 4.

[0305] In some embodiments, the network device 700 further includes a receiving unit, which is used to support the network device 700 in executing steps related to receiving node identifiers, IGP messages, and BGP-LS messages in method 200 and examples 1 to 4.

[0306] For the specific execution process of the network device 700, please refer to the detailed description of the corresponding steps in method 200 and examples 1 to 4, which will not be repeated here.

[0307] The division of units in the embodiment of the present application is schematic and is merely a logical function division. In actual implementation, other division methods may be optional.

[0308] In some embodiments, the various units in the network device 700 are integrated into a single unit. For example, the various units in the network device 700 are integrated into the same chip. The chip includes a processing circuit and an input interface and an output interface that are internally connected and communicated with the processing circuit. The acquisition unit 701 is implemented by the processing circuit in the chip. The receiving unit in the network device 700 is implemented by the input interface in the chip. The publishing unit 702 is implemented by the output interface in the chip. For example, the chip is implemented by one or more field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits that can perform the various functions described throughout this application.

[0309] In other embodiments, each unit of network device 700 exists physically separately. In other embodiments, some units of network device 700 exist physically separately, while other units are integrated into a single unit. For example, in some embodiments, acquisition unit 701 and publishing unit 702 are the same unit. In other embodiments, acquisition unit 701 and publishing unit 702 are different units. In some embodiments, the integration of different units is implemented in hardware, i.e., the different units correspond to the same hardware. In another example, the integration of different units is implemented in software.

[0310] When implemented in hardware in network device 700, the acquisition unit 701 and processing unit in network device 700 are implemented, for example, by the central processing unit 1011 on the main control board 1010 in device 1000, or by the processor 1101 in device 1100. The publishing unit 702 and receiving unit in network device 700 are implemented, for example, by the interface board 1030 in device 1000, or by the communication interface 1104 in device 1100.

[0311] When implemented by software in the network device 700, each unit in the network device 700 is, for example, software generated by the central processing unit 1011 on the main control board 1010 in the device 1000 reading the program code stored in the memory 1012 on the main control board 1010, or software generated by the processor 1101 in the device 1100 reading the program code stored in the memory 1103.

[0312] For example, the network device 700 is a virtualized device. Virtualized devices include but are not limited to at least one of virtual machines, containers, and Pods. In some embodiments, the network device 700 is deployed on a hardware device (such as a physical server) in the form of a virtual machine. For example, the network device 700 is implemented based on a general physical server in combination with network function virtualization (NFV) technology. When implemented in the form of a virtual machine, the network device 700 is, for example, a virtual host, a virtual router, or a virtual switch. Those skilled in the art can virtualize the network device 700 on a general physical server in combination with NFV technology by reading this application. In other embodiments, the network device 700 is deployed on a hardware device in the form of a container (such as a docker container). For example, the process of the network device 700 executing the above-mentioned method embodiment is encapsulated in an image file, and the hardware device creates the network device 700 by running the image file. In other embodiments, the network device 700 is deployed on a hardware device in the form of a Pod. The Pod includes multiple containers, each of which is used to implement one or more units in the network device 700.

[0313] FIG12 shows a possible schematic diagram of the structure of the controller device involved in the above embodiment. The controller device 800 shown in FIG12 implements the functions of the controller devices in method 200 and examples 1 to 4, for example.

[0314] Referring to FIG. 12 , controller device 800 includes a receiving unit 801 and a topology association unit 802. Each unit in controller device 800 is implemented in whole or in part via software, hardware, firmware, or any combination thereof. Each unit in controller device 800 is configured to perform the corresponding functions of the controller device in method 200 and examples 1 through 4 described above. For example, receiving unit 801 is configured to support controller device 800 in executing the step of receiving a BGP-LS update message in S230 and examples 1 through 4. Topology association unit 802 is configured to support controller device 800 in executing the steps of associating intra-domain topology with inter-domain topology in S240 and examples 1 through 4. For the specific execution process of controller device 800, please refer to the detailed description of the corresponding steps in method 200 and examples 1 through 4, and will not be repeated here.

[0315] The division of units in the embodiment of the present application is schematic and is merely a logical function division. In actual implementation, other division methods may be optional.

[0316] In some embodiments, the various units in controller device 800 are integrated into a single unit. For example, the various units in controller device 800 are integrated into a single chip. The chip includes processing circuitry and input and output interfaces that communicate with the processing circuitry. Topology association unit 802 is implemented via the processing circuitry within the chip. Receiving unit 801 is implemented via the input interfaces within the chip. For example, the chip is implemented via one or more FPGAs, PLDs, controllers, state machines, gate logic, discrete hardware components, any other suitable circuitry, or any combination of circuits capable of performing the various functions described throughout this application.

[0317] In other embodiments, the various units of the controller device 800 exist physically separately. In other embodiments, some units of the controller device 800 exist physically separately, while other units are integrated into a single unit. For example, in some embodiments, the receiving unit 801 and the topology association unit 802 are the same unit. In other embodiments, the receiving unit 801 and the topology association unit 802 are different units. In some embodiments, the integration of the different units is implemented in hardware, i.e., the different units correspond to the same hardware. In another example, the integration of the different units is implemented in software.

[0318] When implemented in hardware in the controller device 800, the topology association unit 802 in the controller device 800 is implemented, for example, by the central processing unit 1011 on the main control board 1010 in the device 1000, or by the processor 1101 in the device 1100. The receiving unit 801 and the sending unit in the controller device 800 are implemented, for example, by the interface board 1030 in the device 1000, or by the communication interface 1104 in the device 1100.

[0319] When controller device 800 is implemented via software, each unit in controller device 800 may be, for example, software generated by the central processing unit 1011 on the main control board 1010 of device 1000 reading program code stored in the memory 1012 of the main control board 1010, or software generated by the processor 1101 in device 1100 reading program code stored in the memory 1103. For example, controller device 800 is a virtualized device. Virtualized devices include, but are not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, controller device 800 is deployed on a hardware device (e.g., a physical server) in the form of a virtual machine. For example, controller device 800 is implemented based on a general-purpose physical server in conjunction with NFV technology. When implemented as a virtual machine, controller device 800 may be, for example, a virtual host, a virtual router, or a virtual switch. Those skilled in the art, after reading this application, can virtualize controller device 800 on a general-purpose physical server in conjunction with NFV technology. In other embodiments, controller device 800 is deployed on a hardware device in the form of a container (e.g., a Docker container). For example, the process for executing the above-described method embodiment by the controller device 800 is encapsulated in an image file, and the hardware device creates the controller device 800 by running the image file. In other embodiments, the controller device 800 is deployed on the hardware device in the form of a pod. The pod includes multiple containers, each of which is used to implement one or more units in the controller device 800.

[0320] FIG13 shows a possible schematic diagram of the structure of the second network device involved in the above embodiment. Network device 900 shown in FIG13 implements the functions of the second network device in method 200 and Examples 1 to 4, or implements the functions of ASBR3 in Examples 1 to 4.

[0321] Referring to FIG. 13 , network device 900 includes a publishing unit 901. Publishing unit 901 is implemented in whole or in part via software, hardware, firmware, or any combination thereof. Publishing unit 901 is configured to support network device 900 in publishing node identifiers. For example, publishing unit 901 is configured to execute the step of sending the node identifier in method 200, S32 in Example 1, S42 in Example 2, S53 in Example 3, and S62 in Example 4.

[0322] In some embodiments, the network device 900 further includes a processing unit, which is configured to support the network device 900 in executing steps related to generating an IGP message or a BGP-LS message in method 200 and examples 1 to 4.

[0323] When implemented in hardware in network device 900, publishing unit 901 in network device 900 is implemented, for example, by interface board 1030 in device 1000, or by communication interface 1104 in device 1100. Processing unit in network device 900 is implemented, for example, by central processing unit 1011 on main control board 1010 in device 1000, or by processor 1101 in device 1100.

[0324] When network device 900 is implemented via software, each unit in network device 900 may be, for example, software generated by the central processing unit 1011 on the main control board 1010 of device 1000 reading program code stored in the memory 1012 of the main control board 1010, or software generated by the processor 1101 in device 1100 reading program code stored in the memory 1103. For example, network device 900 is a virtualized device. Virtualized devices include, but are not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, network device 900 is deployed on a hardware device (such as a physical server) in the form of a virtual machine. For example, network device 900 is implemented based on a general-purpose physical server in conjunction with NFV technology. When implemented as a virtual machine, network device 900 may be, for example, a virtual host, a virtual router, or a virtual switch. Those skilled in the art, after reading this application, can virtualize network device 900 on a general-purpose physical server in conjunction with NFV technology. In other embodiments, network device 900 is deployed on a hardware device in the form of a container (such as a Docker container). For example, the process of executing the above-described method embodiment by network device 900 is encapsulated in an image file, and a hardware device creates network device 900 by running the image file. In other embodiments, network device 900 is deployed on a hardware device in the form of a Pod. The Pod includes multiple containers, each of which is used to implement one or more units in network device 900.

[0325] The above describes how to implement the first network device, the second network device, or the controller device in method 200, and the ASBR3, PE3, or the controller device in Examples 1 through 4, from a logical functional perspective, using network device 700, controller device 800, and network device 900. The following describes how to implement the first network device, the second network device, and the controller device from a hardware perspective, using devices 1000 and 1100. Device 1000 shown in FIG. 10 and device 1100 shown in FIG. 11 illustrate the hardware structures of the first network device, the second network device, or the controller device in method 200, and the ASBR3, PE3, or the controller device in Examples 1 through 4.

[0326] Device 1000 or device 1100 corresponds to the first network device, the second network device or the controller device in the above-mentioned method 200, or the ASBR3, PE3 or the controller device in Examples 1 to 4. The hardware, modules and other operations and / or functions in device 1000 or device 1100 are respectively for implementing the various steps and methods implemented by the first network device, the second network device or the controller device in method 200, or the ASBR3, PE3 or the controller device in Examples 1 to 4. Regarding the detailed process of how device 1000 or device 1100 publishes topology information or how to associate the intra-domain topology with the inter-domain topology, the specific details can be found in the above-mentioned method 200, Examples 1 to 4. For the sake of brevity, they are not repeated here. Among them, each step of method 200, Examples 1 to 4 is completed by the hardware integrated logic circuit or software instructions in the processor of device 1000 or device 1100. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor. The software module is located, for example, in a storage medium well-known in the art, such as a random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or register. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not given here.

[0327] Refer to Figure 14, which shows a structural diagram of a device 1000 provided by an exemplary embodiment of the present application. Device 1000 is configured as, for example, the first network device, the second network device, or the controller device in method 200, or the ASBR3, PE3, or the controller device in Examples 1 to 4.

[0328] The main control board (MCB), also known as the main processing unit (MPU) or route processor card, is used to control and manage various components in device 1000, including routing calculations, device management, device maintenance, and protocol processing. MCB 1010 includes a central processing unit (CPU) 1011 and memory 1012.

[0329] Interface board 1030 is also known as a line processing unit (LPU), line card, or service board. It provides various service interfaces and implements data packet forwarding. Service interfaces include, but are not limited to, Ethernet interfaces and POS (Packet over SONET / SDH) interfaces. Ethernet interfaces, for example, are Flexible Ethernet Clients (FlexE Clients). Interface board 1030 includes a central processing unit (CPU) 1031, a network processor (NPU) 1032, a forwarding table memory 1034, and a physical interface card (PIC) 1033.

[0330] The central processing unit 1031 on the interface board 1030 is used to control and manage the interface board 1030 and communicate with the central processing unit 1011 on the main control board 1010 .

[0331] The network processor 1032 is used to implement message forwarding processing. The network processor 1032 is, for example, a forwarding chip. Specifically, the network processor 1032 is used to forward received messages based on the forwarding table stored in the forwarding table memory 1034. If the destination address of the message is the address of device 1000, the message is sent to the CPU (such as the central processing unit 1011) for processing; if the destination address of the message is not the address of device 1000, the next hop and outgoing interface corresponding to the destination address are found in the forwarding table based on the destination address, and the message is forwarded to the outgoing interface corresponding to the destination address. The processing of uplink messages includes: processing of the message input interface, forwarding table search; processing of downlink messages: forwarding table search, etc.

[0332] Physical interface card 1033 implements the physical layer interconnection function. Raw traffic enters interface board 1030 through this card, and processed packets are sent out from this physical interface card 1033. Physical interface card 1033, also known as a daughter card, can be installed on interface board 1030. It is responsible for converting optical and electrical signals into packets, performing a validity check on these packets, and forwarding them to network processor 1032 for processing. In some embodiments, a central processing unit can also perform the functions of network processor 1032, such as implementing software forwarding based on a general-purpose CPU, thus eliminating the need for network processor 1032 in physical interface card 1033.

[0333] Optionally, the device 1000 includes multiple interface boards. For example, the device 1000 further includes an interface board 1040 . The interface board 1040 includes a central processing unit 1041 , a network processor 1042 , a forwarding table entry memory 1044 , and a physical interface card 1043 .

[0334] Optionally, device 1000 further includes a switching fabric board 1020. Switching fabric board 1020 is also referred to as a switch fabric unit (SFU). If the network device has multiple interface boards 1030, switching fabric board 1020 is used to exchange data between the interface boards. For example, interface board 1030 and interface board 1040 communicate via switching fabric board 1020.

[0335] The main control board 1010 and the interface board 1030 are coupled. For example, the main control board 1010, the interface board 1030, the interface board 1040, and the switching network board 1020 are connected to the system backplane via a system bus to achieve intercommunication. In one possible implementation, an inter-process communication (IPC) channel is established between the main control board 1010 and the interface board 1030, and communication between the main control board 1010 and the interface board 1030 is performed via the IPC channel.

[0336] Logically, device 1000 includes a control plane and a forwarding plane. The control plane includes a main control board 1010 and a central processing unit 1031. The forwarding plane includes various components that perform forwarding, such as a forwarding table entry memory 1034, a physical interface card 1033, and a network processor 1032. The control plane performs routing functions, generates forwarding tables, processes signaling and protocol messages, and configures and maintains device status. The control plane sends the generated forwarding tables to the forwarding plane. On the forwarding plane, the network processor 1032 forwards messages received by the physical interface card 1033 based on the forwarding tables sent by the control plane. The forwarding tables sent by the control plane are stored, for example, in the forwarding table entry memory 1034. In some embodiments, the control plane and forwarding plane are completely separate and not located on the same device.

[0337] It should be understood that the operations on the interface board 1040 in the embodiment of the present application are consistent with the operations on the interface board 1030. For the sake of brevity, detailed description is omitted. It should be understood that the device 1000 of this embodiment may correspond to the first network device, controller device, or second network device in each of the above-mentioned method embodiments. The main control board 1010, interface board 1030, and / or 1040 in the device 1000, for example, implement the functions and / or various steps of the first network device, controller device, or second network device in each of the above-mentioned method embodiments. For the sake of brevity, detailed description is omitted here.

[0338] It's worth noting that there may be one or more main control boards, including, for example, a primary and backup main control board. There may be one or more interface boards. The higher the network device's data processing capabilities, the more interface boards it provides. Interface boards can also have one or more physical interface cards. There may be no switching fabric boards, one or more switching fabric boards, and multiple switching fabric boards can collectively implement load balancing and redundant backup. In a centralized forwarding architecture, network devices may not require switching fabric boards; the interface boards handle the entire system's service data processing. In a distributed forwarding architecture, network devices may have at least one switching fabric board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, network devices with distributed architectures have greater data access and processing capabilities than those with centralized architectures. Alternatively, a network device can consist of a single card, without a switching fabric board (SFB), integrating the functions of the interface board and the main control board. In this case, the central processing unit (CPU) on the interface board and the CPU on the main control board can be combined into a single CPU on this card, performing the combined functions of the two. This type of device has lower data exchange and processing capabilities (for example, low-end network devices such as switches or routers). The specific architecture used depends on the specific network deployment scenario and is not specified here.

[0339] Referring to FIG. 15 , FIG. 15 shows a schematic diagram of the structure of a device 1100 provided in an exemplary embodiment of the present application. Device 1100 may be configured as, for example, the first network device, the second network device, or the controller device in method 200, or as the ASBR3, PE3, or the controller device in Examples 1 through 4. Device 1100 may be a host, a server, or a personal computer. Device 1100 may be implemented using a general bus architecture.

[0340] The device 1100 includes at least one processor 1101 , a communication bus 1102 , a memory 1103 , and at least one communication interface 1104 .

[0341] The processor 1101 is, for example, a general-purpose central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the solution of the present application. For example, the processor 1101 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0342] Communication bus 1102 is used to transmit information between the above components. Communication bus 1102 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 15, but this does not mean that there is only one bus or one type of bus.

[0343] The memory 1103 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1103 is, for example, independent and connected to the processor 1101 via the communication bus 1102. The memory 1103 can also be integrated with the processor 1101.

[0344] The communication interface 1104 uses any transceiver or other device for communicating with other devices or communication networks. The communication interface 1104 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0345] In a specific implementation, as an embodiment, the processor 1101 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 15 .

[0346] In a specific implementation, as an example, device 1100 may include multiple processors, such as processor 1101 and processor 1105 shown in FIG15 . Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0347] In a specific implementation, as an embodiment, the device 1100 may further include an output device and an input device. The output device communicates with the processor 1101 and can display information in a variety of ways. For example, the output device can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device communicates with the processor 1101 and can receive user input in a variety of ways. For example, the input device can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0348] In some embodiments, the memory 1103 is used to store program code 1110 for executing the solution of the present application, and the processor 1101 can execute the program code 1110 stored in the memory 1103. That is, the device 1100 can implement method 200 and the methods provided in Examples 1 to 4 through the processor 1101 and the program code 1110 in the memory 1103.

[0349] The device 1100 in the embodiment of the present application may correspond to the first network device, the second network device, or the controller device in each of the above-mentioned methods 200, or the ASBR3, PE3, or the controller device in Examples 1 to 4. Furthermore, the processor 1101, the communication interface 1104, and the like in the device 1100 may implement the functions and / or various steps and methods implemented by the first network device, the second network device, or the controller device, or the ASBR3, PE3, or the controller device in Examples 1 to 4 in the above-mentioned method 200. For the sake of brevity, these details are not repeated here.

[0350] 16 , an embodiment of the present application provides a network system 1200 , which includes: a first network device 1201 , a controller device 1202 , and a second network device 1203 .

[0351] In some embodiments, the first network device 1201 is the network device 700 shown in FIG. 11 , the controller device 1202 is the controller device 800 shown in FIG. 16 , and the second network device 1203 is the network device 900 shown in FIG. 13 .

[0352] In some embodiments, at least one of the first network device 1201 , the controller device 1202 , or the second network device 1203 is the device 1000 shown in FIG. 14 or the device 1100 shown in FIG. 15 .

[0353] In some embodiments, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a network device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the network device to perform the method performed by the first network device in the above method embodiment.

[0354] In some embodiments, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a controller device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the controller device to perform the method performed by the controller device in the above-described method embodiment.

[0355] In some embodiments, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a network device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the network device to perform the method performed by the second network device in the above method embodiment.

[0356] In some embodiments, a chip is provided. When the chip runs on a network device, the network device executes the method executed by the first network device in the above method embodiment.

[0357] In some embodiments, a chip is provided. When the chip runs on a controller device, the controller device executes the method executed by the controller device in the above method embodiment.

[0358] In some embodiments, a chip is provided. When the chip runs on a network device, the network device executes the method executed by the second network device in the above method embodiment.

[0359] Those skilled in the art will appreciate that the various method steps and units described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the steps and components of each embodiment have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0360] Those skilled in the art will clearly understand that, for the sake of convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0361] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the unit is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be electrical, mechanical or other forms of connection.

[0362] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0363] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0364] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0365] In this application, the terms "first" and "second" are used to distinguish between identical or similar items with substantially the same effects and functions. It should be understood that there is no logical or temporal dependency between "first" and "second", nor is there a limit on quantity and execution order. It should also be understood that although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the various examples, a first network device may be referred to as a second network device, and similarly, a second network device may be referred to as a first network device. The first network device and the second network device may both be network devices, and in some cases, may be separate and different network devices.

[0366] The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more.

[0367] The term "if" may be interpreted to mean "when" or "upon" or "in response to determining" or "in response to detecting." Similarly, the phrase "if it is determined that..." or "if [stated condition or event] is detected" may be interpreted to mean "upon determining that..." or "in response to determining that..." or "upon detecting [stated condition or event]" or "in response to detecting [stated condition or event]," depending on the context.

[0368] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and such modifications or substitutions should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0369] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0370] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired or wireless method. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, or a magnetic tape), an optical medium (e.g., a digital video disc (DVD), or a semiconductor medium (e.g., a solid-state drive), etc.

[0371] Those skilled in the art will understand that all or part of the steps of implementing the above embodiments may be accomplished by hardware, or may be accomplished by a program instructing the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0372] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for publishing topology information, It is characterized in that The method comprises: The first network device obtains a node identifier; The first network device publishes intra-domain topology information and inter-domain topology information to the controller device based on the node identifier, the intra-domain topology information and the inter-domain topology information both include the node identifier, the intra-domain topology information is used to indicate the topology within the first domain, and the inter-domain topology information is used to indicate the topology between the first domain and the second domain, and the first domain is the domain to which the first network device belongs.

2. The method according to claim 1, It is characterized in that The first network device publishes intra-domain topology information and inter-domain topology information to the controller device according to the node identifier, including: The first network device sends a first Border Gateway Protocol Link State BGP LS message to the controller device, where the first BGP LS message includes at least one of the intra-domain topology information or the inter-domain topology information.

3. The method according to claim 2, It is characterized in that The first BGP LS message includes a BGP-LS node route, and the BGP-LS node route includes the node identifier; or, The first BGP LS message includes a BGP LS route of a target route type, the BGP LS route of the target route type includes device global information, and the device global information includes the node identifier; or, The first BGP LS message includes a BGP-LS link route, and the BGP-LS link route includes the node identifier; or, The first BGP LS message includes an Internet Protocol version 6 segment routing segment identifier SRv6 SID route, and the SRv6 SID route includes the node identifier.

4. The method according to claim 2 or 3, It is characterized in that The routing attribute field in the first BGP LS message includes a node identifier type length value TLV, the value of the node identifier TLV includes the node identifier, and the type of the node identifier TLV is used to identify that the node identifier TLV carries a node identifier.

5. The method according to claim 4, It is characterized in that The routing attribute field is a node attribute field or a link attribute field.

6. The method according to any one of claims 1 to 5, It is characterized in that The node identifier is used to identify the first network device; or, The node identifier is used to identify a second network device, the second network device belongs to the first domain, and the second network device is a boundary routing device between the first domain and the second domain.

7. The method according to claim 6, It is characterized in that In the case where the node identifier is used to identify the second network device, before the first network device publishes the intra-domain topology information and the inter-domain topology information to the controller device according to the node identifier, the method further includes: The first network device receives the node identifier sent by the second network device.

8. The method according to claim 7, It is characterized in that The first network device receiving the node identifier sent by the second network device includes: The first network device receives an internal gateway protocol IGP message sent by the second network device, where the IGP message includes the node identifier; or, The first network device receives a second BGP-LS message sent by the second network device, where the second BGP-LS message includes the node identifier.

9. The method according to claim 7 or 8, It is characterized in that Before the first network device publishes the intra-domain topology information and the inter-domain topology information to the controller device according to the node identifier, the method further includes: The first network device receives a third BGP-LS message sent by the second network device, where the third BGP-LS message includes the inter-domain topology information.

10. The method according to any one of claims 1 to 9, It is characterized in that The node identifier includes one or more of the following: BGP node identifier, IGP node identifier, Traffic Engineering TE node identifier, system ID, Internet Protocol version 4 IPv4 local node identifier, Internet Protocol version 6 IPv6 local node identifier.

11. A network topology collection method, It is characterized in that The method comprises: The controller device receives intra-domain topology information and inter-domain topology information, wherein the intra-domain topology information and the inter-domain topology information both include a node identifier, the node identifier is used to identify a network device, the intra-domain topology information is used to indicate a topology within a first domain, and the inter-domain topology information is used to indicate a topology between the first domain and a second domain, wherein the first domain is a domain to which the network device belongs; The controller device establishes an association relationship between the intra-domain topology information and the inter-domain topology information according to the node identifier.

12. The method according to claim 11, It is characterized in that The node identifier is used to identify the first network device, and the controller device receives intra-domain topology information and inter-domain topology information, including: The controller device receives the intra-domain topology information and the inter-domain topology information sent by the first network device; or, The controller device receives the intra-domain topology information and the inter-domain topology information sent by a second network device, where both the second network device and the first network device belong to the first domain; or, The controller device receives the intra-domain topology information sent by the first network device, and the controller device receives the inter-domain topology information sent by the second network device; or, The controller device receives the inter-domain topology information sent by the first network device, and the controller device receives the intra-domain topology information sent by the second network device.

13. A method for publishing a node identifier, It is characterized in that The method comprises: The second network device publishes a node identifier to the first network device, where the node identifier is used to identify the second network device, and the node identifier is used to associate intra-domain topology information with inter-domain topology information, where the intra-domain topology information is used to indicate the topology within the first domain, and the inter-domain topology information is used to indicate the topology between the first domain and the second domain, where the first domain is the second network device and the domain to which the first network device belongs, and where the second network device is a boundary routing device between the first domain and the second domain.

14. The method according to claim 13, It is characterized in that The second network device issues a node identifier to the first network device, including: The second network device floods an interior gateway protocol IGP message in the first domain, where the IGP message includes the node identifier; or, The second network device sends a Border Gateway Protocol Link State BGP-LS message to the first network device, where the BGP-LS message includes the node identifier.

15. The method according to claim 13 or 14, It is characterized in that The node identifier includes one or more of the following: BGP node identifier, IGP node identifier, Traffic Engineering TE node identifier, system ID, Internet Protocol version 4 IPv4 local node identifier, Internet Protocol version 6 IPv6 local node identifier.

16. A network device, It is characterized in that The network device is a first network device, and the network device includes: An acquisition unit, used for acquiring a node identifier; A publishing unit is used to publish intra-domain topology information and inter-domain topology information to a controller device according to the node identifier, wherein the intra-domain topology information and the inter-domain topology information both include the node identifier, the intra-domain topology information is used to indicate the topology within a first domain, and the inter-domain topology information is used to indicate the topology between the first domain and a second domain, and the first domain is the domain to which the first network device belongs.

17. The network device according to claim 16, It is characterized in that The publishing unit is used to send a first Border Gateway Protocol Link State BGP LS message to the controller device, where the first BGP LS message includes at least one of the intra-domain topology information or the inter-domain topology information.

18. The network device according to claim 16 or 17, It is characterized in that The node identifier is used to identify the second network device. The network device further includes: a receiving unit, configured to receive the node identifier sent by the second network device.

19. The network device according to claim 18, It is characterized in that The receiving unit is used to receive an internal gateway protocol IGP message sent by the second network device, wherein the IGP message includes the node identifier; or receive a second BGP-LS message sent by the second network device, wherein the second BGP-LS message includes the node identifier.

20. A controller device, It is characterized in that The controller device comprises: A receiving unit, configured to receive intra-domain topology information and inter-domain topology information, wherein the intra-domain topology information and the inter-domain topology information both include a node identifier, the node identifier is used to identify a network device, the intra-domain topology information is used to indicate a topology within a first domain, and the inter-domain topology information is used to indicate a topology between the first domain and a second domain, the first domain being the domain to which the network device belongs; A topology association unit is used to establish an association relationship between the intra-domain topology information and the inter-domain topology information according to the node identifier.

21. The controller device according to claim 20, It is characterized in that The node identifier is used to identify the first network device, and the receiving unit is used to receive the intra-domain topology information and the inter-domain topology information sent by the first network device; or, receive the intra-domain topology information and the inter-domain topology information sent by the second network device, and the second network device and the first network device both belong to the first domain; or, receive the intra-domain topology information sent by the first network device and receive the inter-domain topology information sent by the second network device; or, receive the inter-domain topology information sent by the first network device and receive the intra-domain topology information sent by the second network device.

22. A network device, It is characterized in that The network device is a second network device, and the network device includes: A publishing unit, used for publishing a node identifier to a first network device, wherein the node identifier is used to identify the second network device, and the node identifier is used to associate intra-domain topology information with inter-domain topology information, wherein the intra-domain topology information is used to indicate the topology within the first domain, and the inter-domain topology information is used to indicate the topology between the first domain and the second domain, wherein the first domain is the second network device and the domain to which the first network device belongs, and the second network device is a boundary routing device between the first domain and the second domain.

23. The network device according to claim 22, It is characterized in that The publishing unit is used to flood an Interior Gateway Protocol IGP message in the first domain, wherein the IGP message includes the node identifier; or to send a Border Gateway Protocol Link State BGP-LS message to the first network device, wherein the BGP-LS message includes the node identifier.

24. A network system, It is characterized in that The network system comprises the network device according to any one of claims 16 to 19, the controller device according to any one of claims 20 to 21, and the network device according to any one of claims 22 to 23.