Network interconnecting method and apparatus, and communication system

Abstract

A network interconnecting method and apparatus, and a communication system, which belong to the technical field of communications. In the present application, a first tunnel identifier identifies a first tunnel from a first communication apparatus to a second communication apparatus, wherein the head node of the first tunnel is the first communication apparatus, and the tail node of the first tunnel is the second communication apparatus; the first communication apparatus may send the first tunnel identifier to a third communication apparatus; and the third communication apparatus may receive the first tunnel identifier and establish, on the basis of the first tunnel identifier, an end-to-end tunnel from the third communication apparatus to the second communication apparatus, wherein the end-to-end tunnel comprises the first tunnel and a second tunnel, the head node of the second tunnel is the third communication apparatus, and the tail node of the second tunnel is the first communication apparatus. Thus, in the present application, a third communication apparatus establishes an end-to-end tunnel from the third communication apparatus to a second communication apparatus.

Description

A network interconnection method and device, and a communication system

[0001] This application claims priority to Chinese patent application filed on February 8, 2024, with application number 202410178124.2, entitled “A method, device and communication system for network interconnection”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a network interconnection method and device, and a communication system. Background Art

[0003] In the field of communications, a network managed by an administrator can be called a management domain. Networks managed by different administrators are different management domains, and different management domains can be interconnected for communication.

[0004] Currently, in scenarios where different management domains are interconnected, network nodes in one management domain cannot obtain the network topology in other management domains across management domains. This results in network nodes in one management domain being unable to plan end-to-end tunnels to network nodes in another management domain. Summary of the Invention

[0005] The present application provides a network interconnection method and device, and a communication system. The technical solution of the present application is as follows.

[0006] In a first aspect, a method for network interconnection is provided, the method comprising: receiving a first tunnel identifier, the first tunnel identifier identifying a first tunnel from a first communication device to a second communication device, the head node of the first tunnel being the first communication device, and the tail node of the first tunnel being the second communication device; establishing an end-to-end tunnel from a third communication device to the second communication device according to the first tunnel identifier, the end-to-end tunnel comprising the first tunnel and the second tunnel, the head node of the second tunnel being the third communication device, and the tail node of the second tunnel being the first communication device.

[0007] Among them, the method provided by the first aspect and the method provided by the optional implementation scheme of the first aspect can be executed by a third communication device.

[0008] The technical solution provided by this application realizes the establishment of an end-to-end tunnel from the third communication device to the second communication device because the third communication device can receive the first tunnel identifier and establish an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier.

[0009] Optionally, the third communication device receives the first tunnel identifier sent by the first communication device. The first communication device may send the first tunnel identifier directly to the third communication device, or may send the first tunnel identifier to the third communication device through a controller.

[0010] In the technical solution provided by the present application, since the first communication device can notify the third communication device of the first tunnel identifier, the first communication device can provide the first tunnel from the first communication device to the second communication device to the third communication device.

[0011] Optionally, establishing an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier includes: determining, based on the first tunnel identifier and performance information of the first tunnel, to establish an end-to-end tunnel from the third communication device to the second communication device. For example, determining the first tunnel based on performance information of the first tunnel and performance information of the third tunnel, and then establishing the end-to-end tunnel based on the first tunnel identifier.

[0012] The technical solution provided in the present application is that the third communication device determines to establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel according to the first tunnel identifier and the performance information of the first tunnel, and then the third communication device establishes an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel, thereby ensuring the performance of the end-to-end tunnel established by the third communication device.

[0013] Optionally, the method further includes: receiving performance information of the first tunnel.

[0014] The technical solution provided by this application allows the third communication device to receive the performance information of the first tunnel, which can facilitate the third communication device to determine the establishment of an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel according to the first tunnel identifier and the performance information of the first tunnel.

[0015] Optionally, the third communication device receives the performance information of the first tunnel sent by the first communication device. The first communication device may send the performance information of the first tunnel directly to the third communication device, or may send the performance information of the first tunnel to the third communication device through the controller.

[0016] Optionally, the performance information of the first tunnel includes at least one of available bandwidth, delay, jitter or packet loss rate.

[0017] Optionally, establishing an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier includes: establishing the end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier and a second tunnel identifier, where the second tunnel identifier identifies the second tunnel. For example, the third communication device establishes a tunnel forwarding entry based on the first tunnel identifier and the second tunnel identifier to establish the end-to-end tunnel.

[0018] Optionally, the method further includes: receiving a second tunnel identifier.

[0019] The technical solution provided by the present application enables the third communication device to receive the second tunnel identifier, so that the third communication device can establish an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier and the second tunnel identifier.

[0020] Optionally, the third communication device receives the second tunnel identifier sent by the controller.

[0021] Optionally, receiving the first tunnel identifier includes: receiving multiple tunnel identifiers, the multiple tunnel identifiers including the first tunnel identifier and the third tunnel identifier, the third tunnel identifier identifying the third tunnel from the first communication device to the second communication device, the head node of the third tunnel being the first communication device, and the tail node of the third tunnel being the second communication device. After the third communication device receives the multiple tunnel identifiers, the third communication device can determine the first tunnel among the first tunnel and the third tunnel. For example, the third communication device determines the first tunnel based on the performance information of the first tunnel and the performance information of the third tunnel, and then establishes an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier identifying the first tunnel. For example, the multiple tunnel identifiers identify multiple tunnels from the first communication device to the second communication device, the head nodes of the multiple tunnels are all the first communication device, the tail nodes of the multiple tunnels are all the second communication device, and the third communication device determines the first tunnel based on the performance information of the multiple tunnels.

[0022] The technical solution provided by the present application is that a third communication device receives multiple tunnel identifiers, and the third communication device screens the tunnels identified by the multiple tunnel identifiers to determine the first tunnel, thereby implementing the screening of multiple tunnels from the first communication device to the second communication device by the third communication device.

[0023] Optionally, the method further includes: receiving a virtual private network (VPN) route, the next hop address of the VPN route being the address of the second communication device; and iterating the VPN route to the end-to-end tunnel according to the next hop address of the VPN route.

[0024] The technical solution provided by the present application is that since the next-hop address of the VPN route is the address of the second communication device, and the address of the tail node of the end-to-end tunnel is the address of the second communication device, that is, the next-hop address of the VPN route matches the address of the tail node of the end-to-end tunnel, the third communication device can iterate the VPN route to the end-to-end tunnel according to the next-hop address of the VPN route.

[0025] Optionally, receiving the first tunnel identifier includes: receiving a first route, the first route including the first tunnel identifier, an identifier of a head node of the first tunnel, and an identifier of an end node of the first tunnel. The first route may also include performance information of the first tunnel, a second tunnel identifier, and the like.

[0026] That is, the first communication device or the controller sends the first tunnel identifier to the third communication device by publishing the route.

[0027] Optionally, the first routing includes any one of the following: software-defined networking in a wide area network (SD-WAN) routing; border gateway protocol link-state (BGP-LS) routing; border gateway protocol (BGP) label routing; border gateway protocol flow specification (BGP FS) routing; border gateway protocol routing policy distribution (BGP-RPD) routing; overlay management protocol (OMP) routing; path computation element communication protocol (PCEP) routing.

[0028] The technical solution provided in the present application is that the first communication device or controller sends a first tunnel identifier to the third communication device by publishing any one of SD-WAN routing, BGP-LS routing, BGP label routing, BGP FS routing, BGP-RPD routing, OMP routing, and PCEP routing. Therefore, the technical solution provided in the present application is applicable to a wide range of protocols and scenarios.

[0029] Optionally, the first route is a BGP FS route, an OMP route, or a PCEP route, and the first route includes a flow control policy, where the flow control policy includes a first tunnel identifier. For example, the flow control policy includes multiple tunnel identifiers, where the multiple tunnel identifiers include the first tunnel identifier.

[0030] Alternatively, the first route is a BGP-RPD route, an OMP route, or a PCEP route, and the first route includes a routing control policy, the routing control policy includes a first tunnel identifier, for example, the routing control policy includes multiple tunnel identifiers, and the multiple tunnel identifiers include the first tunnel identifier;

[0031] Alternatively, the first route is an SD-WAN route or a BGP-LS route, the first route includes a multi-protocol reachable network layer reachability information (MP_REACH_NLRI) attribute, the MP_REACH_NLRI attribute includes the first tunnel identifier, for example, the MP_REACH_NLRI attribute includes multiple tunnel identifiers, the multiple tunnel identifiers include the first tunnel identifier;

[0032] Alternatively, the first route is a BGP label route, the first route includes an MP_REACH_NLRI attribute or a border gateway protocol prefix segment identifier (BGP prefix-SID) attribute, the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier, for example, the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes multiple tunnel identifiers, and the multiple tunnel identifiers include the first tunnel identifier.

[0033] Optionally, the BGP label routing includes any one of BGP labeled-unicast (LU) routing, BGP classful transport planes (CT) routing, and BGP color-aware routing (CAR).

[0034] Optionally, the first route is a BGP LU route or a BGP CT route, the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier; or, the first route is a BGP CAR route, the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes a first tunnel identifier.

[0035] Optionally, the first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

[0036] The technical solution provided by this application is that since the first tunnel belongs to the first management domain and the second tunnel belongs to the second management domain, the third communication device in the second management domain can establish an end-to-end tunnel across management domains from the third communication device to the second communication device in the first management domain.

[0037] Optionally, the first tunnel includes any one of the following: segment routing multiprotocol label switching (SR-MPLS) tunnel; segment routing internet protocol version 6 (SRv6) traffic engineering (TE) tunnel; generic routing encapsulation (GRE) tunnel; multiprotocol label switching (MPLS) label distribution protocol (LDP) label switching path (LSP) tunnel; BGP LSP tunnel; resource reservation protocol traffic engineering (RSVP-TE) LSP tunnel.

[0038] Optionally, the second tunnel includes an SD-WAN tunnel.

[0039] Optionally, the method further includes: sending a first message to the second communication device through the end-to-end tunnel, where the first message includes a first tunnel identifier.

[0040] The technical solution provided by the present application can realize end-to-end communication between the third communication device and the second communication device because the third communication device sends the first message to the second communication device through the end-to-end tunnel from the third communication device to the second communication device.

[0041] In a second aspect, a network interconnection method is provided, the method comprising: obtaining a first tunnel identifier, the first tunnel identifier identifying a first tunnel from a first communication device to a second communication device, the first tunnel having a head node being the first communication device and a tail node being the second communication device; and sending the first tunnel identifier to a third communication device. Thus, the third communication device can establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier, the end-to-end tunnel comprising the first tunnel and a second tunnel, the second tunnel having a head node being the third communication device and a tail node being the first communication device.

[0042] The method provided in the second aspect and the method provided in the optional implementation of the second aspect can be executed by the first communication device or the controller. For ease of description, the first communication device and the controller are collectively referred to as the target communication device in the introduction of the second aspect.

[0043] The technical solution provided by the present application is that, since the target communication device sends the first tunnel identifier to the third communication device, the target communication device (for example, the first communication device) realizes providing the first tunnel from the first communication device to the second communication device to the third communication device, so that the third communication device learns of the first tunnel, and then the third communication device establishes an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier.

[0044] Optionally, the method further includes: sending performance information of the first tunnel to a third communication device.

[0045] The technical solution provided in the present application is that the target communication device sends the performance information of the first tunnel to the third communication device, which can facilitate the third communication device to determine the establishment of an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel according to the first tunnel identifier and the performance information of the first tunnel, thereby ensuring the performance of the end-to-end tunnel established by the third communication device.

[0046] Optionally, the performance information of the first tunnel includes at least one of available bandwidth, delay, jitter or packet loss rate.

[0047] Optionally, the method further includes: sending a second tunnel identifier to a third communication device, where the second tunnel identifier identifies the second tunnel.

[0048] The technical solution provided by the present application is that the target communication device sends the second tunnel identifier to the third communication device, which can facilitate the third communication device to establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier and the second tunnel identifier.

[0049] Optionally, obtaining the first tunnel identifier includes: obtaining multiple tunnel identifiers, the multiple tunnel identifiers including a first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifying a third tunnel from the first communication device to the second communication device, the head node of the third tunnel being the first communication device, and the tail node of the third tunnel being the second communication device; determining the first tunnel based on performance information of the first tunnel and performance information of the third tunnel; and obtaining the first tunnel identifier identifying the first tunnel. For example, the multiple tunnel identifiers identify multiple tunnels from the first communication device to the second communication device, the head nodes of the multiple tunnels are all the first communication device, the tail nodes of the multiple tunnels are all the second communication device, the target communication device determines the first tunnel based on the performance information of the multiple tunnels, and then the target communication device obtains the first tunnel identifier identifying the first tunnel.

[0050] The technical solution provided by this application is that the target communication device screens the tunnels identified by multiple tunnel identifiers to determine the first tunnel, thereby implementing the screening of multiple tunnels from the first communication device to the second communication device by the target communication device (the first communication device or the controller).

[0051] Optionally, obtaining the first tunnel identifier includes: obtaining multiple tunnel identifiers, the multiple tunnel identifiers including the first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifying a third tunnel from the first communication device to the second communication device, the head node of the third tunnel being the first communication device, and the tail node of the third tunnel being the second communication device; correspondingly, sending the first tunnel identifier to the third communication device includes: sending the multiple tunnel identifiers to the third communication device. For example, the multiple tunnel identifiers identify multiple tunnels from the first communication device to the second communication device, the head nodes of the multiple tunnels are all the first communication device, and the tail nodes of the multiple tunnels are all the second communication device.

[0052] The technical solution provided by this application is that the target communication device sends multiple tunnel identifiers to the third communication device, and the third communication device screens the tunnels identified by the multiple tunnel identifiers, thereby implementing the screening of multiple tunnels from the first communication device to the second communication device by the third communication device.

[0053] Optionally, sending the first tunnel identifier to the third communication device includes: sending a first route to the third communication device, where the first route includes the first tunnel identifier, an identifier of the head node of the first tunnel, and an identifier of the tail node of the first tunnel. The first route may also include performance information of the first tunnel, the second tunnel identifier, etc. In other words, the target communication device sends the first tunnel identifier, the performance information of the first tunnel, the second tunnel identifier, etc. to the third communication device by publishing the first route.

[0054] Optionally, the first route includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP-RPD routing; OMP routing; PCEP routing.

[0055] The technical solution provided in this application is that the target communication device sends a first tunnel identifier to the third communication device by publishing any one of SD-WAN routing, BGP-LS routing, BGP label routing, BGP FS routing, BGP-RPD routing, OMP routing, and PCEP routing. Therefore, the technical solution provided in this application is applicable to a wide range of protocols and scenarios.

[0056] Optionally, the first route is a BGP FS route, an OMP route, or a PCEP route, and the first route includes a flow control policy, where the flow control policy includes a first tunnel identifier. For example, the flow control policy includes multiple tunnel identifiers, where the multiple tunnel identifiers include the first tunnel identifier.

[0057] Alternatively, the first route is a BGP-RPD route, an OMP route, or a PCEP route, and the first route includes a routing control policy, the routing control policy includes a first tunnel identifier, for example, the routing control policy includes multiple tunnel identifiers, and the multiple tunnel identifiers include the first tunnel identifier;

[0058] Alternatively, the first route is an SD-WAN route or a BGP-LS route, the first route includes a multi-protocol reachable network layer reachability information (MP_REACH_NLRI) attribute, the MP_REACH_NLRI attribute includes the first tunnel identifier, for example, the MP_REACH_NLRI attribute includes multiple tunnel identifiers, the multiple tunnel identifiers include the first tunnel identifier;

[0059] Alternatively, the first route is a BGP label route, the first route includes an MP_REACH_NLRI attribute or a border gateway protocol prefix segment identifier (BGP prefix-SID) attribute, the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier, for example, the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes multiple tunnel identifiers, and the multiple tunnel identifiers include the first tunnel identifier.

[0060] Optionally, the BGP labeled route includes any one of a BGP LU route, a BGP CT route, and a BGP CAR route.

[0061] Optionally, the first route is a BGP LU route or a BGP CT route, the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier; or, the first route is a BGP CAR route, the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes a first tunnel identifier.

[0062] Optionally, the method further includes: receiving a VPN route, the next hop address of the VPN route being the address of the second communication device; and sending the VPN route to a third communication device. The target communication device does not modify the next hop address of the VPN route during the process of sending the VPN route to the third communication device, that is, maintains the next hop address of the VPN route as the address of the second communication device. This facilitates the third communication device to iterate the VPN route to the end-to-end tunnel based on the next hop address of the VPN route after receiving the VPN route.

[0063] Optionally, the first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

[0064] The technical solution provided by this application is that since the first tunnel belongs to the first management domain and the second tunnel belongs to the second management domain, the third communication device in the second management domain can establish an end-to-end tunnel across management domains from the third communication device to the second communication device in the first management domain.

[0065] Optionally, the first tunnel includes any one of the following: SR-MPLS tunnel; SRv6TE tunnel; GRE tunnel; MPLS LDP LSP tunnel; BGP LSP tunnel; RSVP-TE LSP tunnel.

[0066] Optionally, the second tunnel includes an SD-WAN tunnel.

[0067] Optionally, the method is performed by a first communication device, that is, the target communication device is the first communication device, and the method further includes: receiving a first message, the first message including a first tunnel identifier; and forwarding the first message to a second communication device based on the first tunnel identifier. For example, the first communication device determines a first tunnel based on the first tunnel identifier in the first message, and then forwards the first message to the second communication device via the first tunnel.

[0068] In a third aspect, a communication device is provided, comprising at least one functional module configured to execute the method provided in the first aspect or any optional embodiment of the first aspect. The at least one functional module may be implemented based on software, hardware, or a combination of software and hardware, and the at least one functional module may be arbitrarily combined or divided based on the specific implementation.

[0069] Optionally, the communication device is a third communication device, and the at least one functional module includes a receiving module and a processing module.

[0070] The receiving module is configured to receive a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from a first communication device to a second communication device, where a head node of the first tunnel is the first communication device and a tail node of the first tunnel is the second communication device;

[0071] The processing module is used to establish an end-to-end tunnel from a third communication device to a second communication device according to a first tunnel identifier. The end-to-end tunnel includes a first tunnel and a second tunnel. The head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

[0072] Optionally, the receiving module is configured to receive a first tunnel identifier sent by the first communication device. The first communication device may send the first tunnel identifier directly to the third communication device, or may send the first tunnel identifier to the third communication device via the controller.

[0073] Optionally, the processing module is configured to determine, based on the first tunnel identifier and performance information of the first tunnel, to establish an end-to-end tunnel from the third communication device to the second communication device.

[0074] Optionally, the receiving module is further used to receive performance information of the first tunnel.

[0075] Optionally, the receiving module is configured to receive the performance information of the first tunnel sent by the first communication device. The first communication device may send the performance information of the first tunnel directly to the third communication device, or send the performance information of the first tunnel to the third communication device through the controller.

[0076] Optionally, the performance information of the first tunnel includes at least one of available bandwidth, delay, jitter or packet loss rate.

[0077] Optionally, the processing module is configured to establish an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier and the second tunnel identifier, where the second tunnel identifier identifies the second tunnel.

[0078] Optionally, the receiving module is further configured to receive a second tunnel identifier.

[0079] Optionally, the receiving module is used to receive a second tunnel identifier sent by the controller.

[0080] Optionally, the receiving module is used to receive multiple tunnel identifiers, the multiple tunnel identifiers including a first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device.

[0081] Optionally, the receiving module is further configured to receive a VPN route, wherein the next hop address of the VPN route is the address of the second communication device;

[0082] The processing module is further configured to iterate the VPN route to the end-to-end tunnel according to the next hop address of the VPN route.

[0083] Optionally, the receiving module is configured to receive a first route, the first route including a first tunnel identifier, an identifier of a head node of the first tunnel, and an identifier of an end node of the first tunnel. The first route may also include performance information of the first tunnel, a second tunnel identifier, and the like.

[0084] Optionally, the first route includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP-RPD routing; OMP routing; PCEP routing.

[0085] Optionally, the first route is a BGP FS route, an OMP route or a PCEP route, and the first route includes a traffic control policy, which includes a first tunnel identifier; or, the first route is a BGP-RPD route, an OMP route or a PCEP route, and the first route includes a routing control policy, which includes a first tunnel identifier; or, the first route is an SD-WAN route or a BGP-LS route, and the first route includes an MP_REACH_NLRI attribute, which includes a first tunnel identifier; or, the first route is a BGP label route, and the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier.

[0086] Optionally, the BGP labeled route includes any one of a BGP LU route, a BGP CT route, and a BGP CAR route.

[0087] Optionally, the first route is a BGP LU route or a BGP CT route, the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier; or, the first route is a BGP CAR route, the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes a first tunnel identifier.

[0088] Optionally, the first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

[0089] Optionally, the first tunnel includes any one of the following: SR-MPLS tunnel; SRv6TE tunnel; GRE tunnel; MPLS LDP LSP tunnel; BGP LSP tunnel; RSVP-TELSP tunnel.

[0090] Optionally, the second tunnel includes an SD-WAN tunnel.

[0091] Optionally, the at least one functional module further includes: a sending module, configured to send a first message to the second communication device through the end-to-end tunnel, where the first message includes a first tunnel identifier.

[0092] In a fourth aspect, a communication device is provided, comprising at least one functional module configured to execute the method provided in the second aspect or any optional embodiment of the second aspect. The at least one functional module may be implemented based on software, hardware, or a combination of software and hardware, and the at least one functional module may be arbitrarily combined or divided based on the specific implementation.

[0093] Optionally, the communication device is a first communication device or a controller. For ease of description, the first communication device and the controller are collectively referred to as a target communication device. The at least one functional module includes a processing module and a sending module.

[0094] The processing module is configured to obtain a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from a first communication device to a second communication device, where the head node of the first tunnel is the first communication device and the tail node of the first tunnel is the second communication device;

[0095] The sending module is used to send a first tunnel identifier to a third communication device, so that the third communication device establishes an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier. The end-to-end tunnel includes a first tunnel and a second tunnel, the head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

[0096] Optionally, the sending module is further used to send performance information of the first tunnel to the third communication device.

[0097] Optionally, the performance information of the first tunnel includes at least one of available bandwidth, delay, jitter or packet loss rate.

[0098] Optionally, the sending module is further configured to send a second tunnel identifier to the third communication device, where the second tunnel identifier identifies the second tunnel.

[0099] Optionally, the processing module is used to: obtain multiple tunnel identifiers, the multiple tunnel identifiers including a first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device; determine the first tunnel based on the performance information of the first tunnel and the performance information of the third tunnel; obtain the first tunnel identifier that identifies the first tunnel.

[0100] Optionally, the processing module is used to obtain multiple tunnel identifiers, the multiple tunnel identifiers including a first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device; correspondingly, the sending module is used to send the multiple tunnel identifiers to the third communication device.

[0101] Optionally, the sending module is configured to send a first route to a third communication device, the first route including a first tunnel identifier, an identifier of a head node of the first tunnel, and an identifier of an end node of the first tunnel. The first route may also include performance information of the first tunnel, a second tunnel identifier, and the like.

[0102] Optionally, the first route includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP-RPD routing; OMP routing; PCEP routing.

[0103] Optionally, the first route is a BGP FS route, an OMP route or a PCEP route, and the first route includes a traffic control policy, which includes a first tunnel identifier; or, the first route is a BGP-RPD route, an OMP route or a PCEP route, and the first route includes a routing control policy, which includes a first tunnel identifier; or, the first route is an SD-WAN route or a BGP-LS route, and the first route includes an MP_REACH_NLRI attribute, which includes a first tunnel identifier; or, the first route is a BGP label route, and the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier.

[0104] Optionally, the BGP labeled route includes any one of a BGP LU route, a BGP CT route, and a BGP CAR route.

[0105] Optionally, the first route is a BGP LU route or a BGP CT route, the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier; or, the first route is a BGP CAR route, the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes a first tunnel identifier.

[0106] Optionally, the at least one functional module further includes a receiving module for receiving a VPN route, wherein the next hop address of the VPN route is the address of the second communication device; and the sending module is further used to send the VPN route to the third communication device.

[0107] Optionally, the first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

[0108] Optionally, the first tunnel includes any one of the following: SR-MPLS tunnel; SRv6TE tunnel; GRE tunnel; MPLS LDP LSP tunnel; BGP LSP tunnel; RSVP-TE LSP tunnel.

[0109] Optionally, the second tunnel includes an SD-WAN tunnel.

[0110] Optionally, the target communication device is a first communication device, and the at least one functional module further includes a receiving module for receiving a first message, where the first message includes a first tunnel identifier; the sending module is further used to forward the first message to the second communication device according to the first tunnel identifier.

[0111] In a fifth aspect, a communication device is provided, comprising a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory to implement the method provided in the first aspect or any optional manner of the first aspect, or to implement the method provided in the second aspect or any optional manner of the second aspect.

[0112] In the sixth aspect, a communication device is provided, including a main control board and an interface board, wherein the main control board and the interface board are used to implement the method provided by the above-mentioned first aspect or any optional method of the first aspect, or to implement the method provided by the above-mentioned second aspect or any optional method of the second aspect.

[0113] In a seventh aspect, a communication system is provided, comprising a plurality of communication devices; at least one of the plurality of communication devices is used to execute the method provided in the first aspect or any optional manner of the first aspect, or at least one of the plurality of communication devices is used to execute the method provided in the second aspect or any optional manner of the second aspect. At least one of the plurality of communication devices is a communication device provided in the third aspect or any optional manner of the third aspect, or at least one of the plurality of communication devices is a communication device provided in the fourth aspect or any optional manner of the fourth aspect, or at least one of the plurality of communication devices is a communication device provided in the fifth aspect or the sixth aspect.

[0114] Optionally, the multiple communication devices include a first communication device, a second communication device, a third communication device, and a controller, the third communication device being used to execute the method provided in the first aspect or any optional manner of the first aspect, and the first communication device or the controller being used to execute the method provided in the second aspect or any optional manner of the second aspect. The third communication device is the communication device provided in the third aspect or any optional manner of the third aspect, or the communication device provided in the fifth aspect or the sixth aspect, and the first communication device or the controller is the communication device provided in the fourth aspect or any optional manner of the fourth aspect, or the communication device provided in the fifth aspect or the sixth aspect.

[0115] In an eighth aspect, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the method provided in the first aspect or any optional manner of the first aspect is implemented, or the method provided in the second aspect or any optional manner of the second aspect is implemented.

[0116] In the ninth aspect, a computer program product is provided, which includes a program or code, and when the program or code is executed, it implements the method provided by the first aspect or any optional method of the first aspect, or implements the method provided by the second aspect or any optional method of the second aspect.

[0117] The communication device described in the first to ninth aspects above may be a network node, such as a router or a switch, or a communication entity in a network node, such as a chip, an interface board, a line card, or a software-based communication device. This application does not limit the form of the communication device. For example, the communication device is a chip, which includes a programmable logic circuit and / or program instructions, and when the chip is running, it implements the method provided in the first aspect or any optional manner of the first aspect, or implements the method provided in the second aspect or any optional manner of the second aspect.

[0118] The technical effects of the third to ninth aspects mentioned above can refer to the technical effects of the first to second aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0119] FIG1 is a schematic diagram of an MP_REACH_NLRI attribute provided by the multi-protocol extensions for border gateway protocol (MP-BGP);

[0120] FIG2 is a schematic diagram of a multi-protocol unreachable network layer reachability information (MP_UNREACH_NLRI) attribute provided by MP-BGP;

[0121] FIG3 is a schematic diagram of a network layer reachability information (NLRI) field provided by BGPSD-WAN;

[0122] FIG4 is a schematic diagram of another NLRI field provided by BGPSD-WAN;

[0123] FIG5 is a schematic diagram of a link-state NLRI (LS-NLRI) field;

[0124] FIG6 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0125] FIG7 is a schematic diagram of another application scenario provided by an embodiment of the present application;

[0126] FIG8 is a flow chart of a network interconnection method provided in an embodiment of the present application;

[0127] FIG9 is a schematic diagram of a matching type-length-value (TLV) field in OMP routing or PCEP routing provided in an embodiment of the present application;

[0128] FIG10 is a schematic diagram of an action TLV field in OMP routing or PCEP routing provided in an embodiment of the present application;

[0129] FIG11 is a schematic diagram of an SD-WAN NLRI field provided in an embodiment of the present application;

[0130] FIG12 is a schematic diagram of a BGP LU NLRI field provided in an embodiment of the present application;

[0131] FIG13 is a schematic diagram of a BGP CT NLRI field provided in an embodiment of the present application;

[0132] FIG14 is a schematic diagram of a BGP CAR NLRI field provided in an embodiment of the present application;

[0133] FIG15 is a schematic diagram of another BGP CAR NLRI field provided in an embodiment of the present application;

[0134] FIG16 is a schematic diagram of a BGP prefix-SID attribute provided in an embodiment of the present application;

[0135] FIG17 is a schematic diagram of a BGP tunnel performance attribute provided in an embodiment of the present application;

[0136] FIG18 is a schematic diagram of a metric sub-TLV field provided in an embodiment of the present application;

[0137] FIG19 is a schematic diagram of a color extended community attribute provided in an embodiment of the present application;

[0138] FIG20 is a schematic diagram of a "transmission class" routing target extended community attribute provided in an embodiment of the present application;

[0139] FIG21 is a flowchart of another network interconnection method provided in an embodiment of the present application;

[0140] FIG22 is a flowchart of another network interconnection method provided in an embodiment of the present application;

[0141] FIG23 is a schematic diagram of a network interconnection method provided in an embodiment of the present application;

[0142] FIG24 is a schematic diagram of another network interconnection method provided in an embodiment of the present application;

[0143] FIG25 is a schematic diagram of another network interconnection method provided in an embodiment of the present application;

[0144] FIG26 is a schematic diagram of another network interconnection method provided in an embodiment of the present application;

[0145] FIG27 is a schematic diagram of a communication device provided in an embodiment of the present application;

[0146] FIG28 is a schematic diagram of another communication device provided in an embodiment of the present application;

[0147] Figure 29 is a schematic diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0148] The embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

[0149] The technical solutions of the embodiments of the present application involve the Border Gateway Protocol (BGP), BGP software-defined networking in a wide area network (SD-WAN), BGP flow specification (FS) and BGP link state (BGP-LS). To facilitate understanding of the technical solutions of the embodiments of the present application, before introducing the technical solutions of the embodiments of the present application, BGP, SD-WAN standards, BGP FS and BGP-LS are first introduced.

[0150] 1.BGP

[0151] BGP is a dynamic routing protocol used between autonomous systems (ASs). It uses address families to distinguish between different network layer protocols. As the standard for external routing on the internet, BGP is widely used among internet service providers (ISPs).

[0152] The three early BGP versions were BGP-1 (Request for Comments (RFC) 1105), BGP-2 (RFC 1163), and BGP-3 (RFC 1267). These versions were primarily used to exchange reachable routing information between ASes, establish inter-AS propagation paths, prevent routing loops, and apply routing policies at the AS level. The currently used BGP version is BGP-4 (RFC 4271).

[0153] Traditional BGP-4 can only manage unicast routing information for Internet Protocol version 4 (IPv4), limiting its use with other network layer protocols such as Internet Protocol version 6 (IPv6) routing information and multicast routing information. The Internet Engineering Task Force (IETF) extended BGP-4 to create the Multi-Protocol Extensions for Border Gateway Protocol (MP-BGP). MP-BGP supports multiple network layer protocols, addressing the limitations of traditional BGP-4. The current MP-BGP standard is RFC4760.

[0154] MP-BGP defines two BGP path attributes: the MP_REACH_NLRI attribute and the MP_UNREACH_NLRI attribute. The MP_REACH_NLRI attribute is a multiprotocol reachable network layer reachability information (NLRI) attribute, used to advertise reachable routes and next-hop information. The MP_UNREACH_NLRI attribute is a multiprotocol unreachable NLRI attribute, used to remove unreachable routes. These two BGP path attributes make BGP widely used for control signaling in various services.

[0155] The MP_REACH_NLRI attribute consists of one or more triplets: <address family information field, next hop information field, NLRI field>. Figure 1 is a schematic diagram of the MP_REACH_NLRI attribute provided by the MP-BGP standard. As shown in Figure 1, the MP_REACH_NLRI attribute includes the address family information field, the next hop information field, the NLRI field, and a reserved field located between the next hop information field and the NLRI field.

[0156] As shown in Figure 1, the address family information domain includes an address family identifier (AFI) field and a subsequent address family identifier (SAFI) field. The length of the AFI field is 2 bytes (octets), and the length of the SAFI field is 1 byte. The AFI field is used to identify the network layer protocol, and the SAFI field is used to identify the type of the sub-address family. Specifically, the AFI field is used to carry the AFI, which is used to identify the network layer protocol; the SAFI field is used to carry the SAFI, which is used to identify the type of the sub-address family. The value of the AFI field corresponds to the address family value defined in the "Address Family Number" in RFC1700. For example, when the value of the AFI field is 1, the AFI field is used to identify the IPv4 protocol; when the value of the AFI field is 2, the AFI field is used to identify the IPv6 protocol. When the value of the SAFI field is 1, the SAFI field is used to identify that the type of the sub-address family is unicast; when the value of the SAFI field is 2, the SAFI field is used to identify that the type of the sub-address family is multicast; when the value of the SAFI field is 4, the SAFI field is used to identify that the type of the sub-address family is BGP; when the value of the SAFI field is 74, the SAFI field is used to identify that the type of the sub-address family is SD-WAN; when the value of the SAFI field is 128, the SAFI field is used to identify that the type of the sub-address family is a virtual private network (VPN). MP-BGP can identify the type of content carried by the NLRI domain by combining the values ​​of the AFI field and the SAFI field. For example, when the value of the AFI field is 1 and the value of the SAFI field is 1, it indicates that the NLRI domain carries IPv4 unicast address family information. When the value of the AFI field is 1 and the value of the SAFI field is 128, it indicates that the NLRI domain carries virtual private network version 4 (VPN version 4, VPNv4) address family information. If the value of the AFI field is 1 and the value of the SAFI field is 4, it indicates that the NLRI field carries the IPv4 BGP address family information. If the value of the AFI field is 1 and the value of the SAFI field is 74, it indicates that the NLRI field carries the IPv4 SD-WAN address family information. If the value of the AFI field is 2 and the value of the SAFI field is 74, it indicates that the NLRI field carries the IPv6 SD-WAN address family information.

[0157] As shown in Figure 1, the next hop information field includes a next hop network address length field and a next hop network address field. The length of the next hop network address length field is 1 byte, and the length of the next hop network address field is variable. The next hop network address length field is used to indicate the length of the next hop network address field, and the next hop network address field is used to carry the next hop network address. The next hop network address refers to the network address of the next device on the path to the destination system. In some manuscripts or technical documents, the next hop network address is also described as the next hop address.

[0158] As shown in Figure 1, the NLRI field has a variable length. The NLRI field includes a reachable route list and one or more NLRI fields. Each NLRI field consists of <length, NLRI value>. The NLRI value is determined by the combination of the values ​​of the AFI field and the SAFI field.

[0159] Figure 2 is a schematic diagram of an MP_UNREACH_NLRI attribute provided by the MP-BGP standard. As shown in Figure 2, the MP_UNREACH_NLRI attribute includes an address family information field and an NLRI field. The address family information field includes an AFI field and a SAFI field. The meanings of the AFI field and the SAFI field in the MP_UNREACH_NLRI attribute are the same as those of the MP_REACH_NLRI attribute and are not described here. In the MP_UNREACH_NLRI attribute, the NLRI field includes an unreachable route list. The NLRI field includes one or more NLRI fields. Each NLRI field consists of <length, NLRI value>. The NLRI value is determined based on the combination of the value of the AFI field and the value of the SAFI field. A BGP speaker can revoke an unreachable route by carrying the same NLRI as that in the previously published MP_REACH_NLRI attribute in the MP_UNREACH_NLRI attribute. A BGP speaker is a network node (such as a router) that sends a BGP message.

[0160] 2.BGPSD-WAN

[0161] Please refer to the following link for the BGPSD-WAN standard currently being defined:

[0162] https: / / www.ietf.org / archive / id / draft-ietf-idr-sdwan-edge-discovery-12.txt.

[0163] The format of the MP_REACH_NLRI attribute used in the BGPSD-WAN standard is shown in Figure 1.

[0164] The definitions of the AFI and SAFI field values ​​in the BGPSD-WAN standard are shown in Table 1 below.

[0165] Table 1

[0166] As shown in Table 1, in the BGPSD-WAN standard, the AFI field can take values ​​of 1 and 2, and the SAFI field can take a value of 74. When the AFI field value is 1 and the SAFI field value is 74, it indicates that the NLRI field carries IPv4 SD-WAN address family information. When the AFI field value is 2 and the SAFI field value is 74, it indicates that the NLRI field carries IPv6 SD-WAN address family information.

[0167] Figure 3 is a schematic diagram of the NLRI field defined in the BGPSD-WAN standard. The NLRI field includes a route type subfield, a length subfield, and a type-specific value subfield. The length of the route type subfield and the length subfield are both 2 bytes, and the length of the type-specific value subfield is variable. The route type subfield identifies the route type, the length subfield identifies the length of the type-specific value subfield, and the type-specific value subfield carries the value of the route type.

[0168] In the BGPSD-WAN standard, the value of the route type subfield in the NLRI field can be 1. Figure 4 is a schematic diagram of the NLRI field defined by the BGPSD-WAN standard when the route type is 1 (that is, the value of the route type subfield is 1). As shown in Figure 4, when the route type is 1, the type-specific value subfield includes a local port identifier (port-local-ID) subfield, an SD-WAN color (SD-WAN-color) subfield, and an SD-WAN node identifier (SD-WAN-node-ID) subfield. The length of the port-local-ID subfield and the length of the SD-WAN-color subfield are 4 bytes respectively, and the length of the SD-WAN-node-ID subfield is 4 bytes or 16 bytes. The port-local-ID subfield is used to carry the identification of the local WAN port. The SD-WAN-color subfield is used to carry the SD-WAN-color, which can be used to identify a site. The SD-WAN-node-ID subfield is used to carry the identification of the SD-WAN node. It should be noted that when the routing type is 1, this routing is also called SD-WAN transport network port (TNP) routing.

[0169] 3. BGP FS

[0170] BGP FS transmits traffic control policies to BGP FS peers by transmitting BGP FS routes, thereby controlling attack traffic.

[0171] BGP FS includes two basic concepts: BGP FS routes and BGP FS peer relationships.

[0172] BGP FS routing: A type of routing defined in RFC8955. BGP FS defines an NLRI and extended community attribute. These NLRI and extended community attributes can carry traffic matching rules and actions to be performed after traffic matching (i.e., traffic processing behaviors) to control attack traffic.

[0173] A BGP FS peer relationship is established between the device that creates a BGP FS route and another device (such as a network ingress device). After the device that creates the BGP FS route and the other device establish a BGP FS peer relationship, the two become BGP FS peers. The other device can be called a BGP FS peer of the device that creates the BGP FS route. The device that creates the BGP FS route can pass the BGP FS route to the BGP FS peer. After receiving the BGP FS route, the BGP FS peer converts the BGP FS route into a forwarding-plane traffic control policy to control attack traffic.

[0174] BGP FS uses the MP_REACH_NLRI attribute and the MP_UNREACH_NLRI attribute defined in MP-BGP to carry NLRI. That is, the NLRI defined by BGP FS can be included in the MP_REACH_NLRI attribute and the MP_UNREACH_NLRI attribute defined in MP-BGP.

[0175] The values ​​of the AFI field and SAFI field corresponding to different types of BGP FS flow rules are shown in Table 2 below.

[0176] Table 2

[0177] As shown in Table 2, in BGP FS, the values ​​of the AFI field include 1 and 2, and the values ​​of the SAFI field include 133 and 134. When the value of the AFI field is 1 and the value of the SAFI field is 133, it indicates that the NLRI domain carries IPv4 flow rules. When the value of the AFI field is 1 and the value of the SAFI field is 134, it indicates that the NLRI domain carries VPNv4 flow rules. When the value of the AFI field is 2 and the value of the SAFI field is 133, it indicates that the NLRI domain carries IPv6 flow rules. When the value of the AFI field is 2 and the value of the SAFI field is 134, it indicates that the NLRI domain carries VPNv6 flow rules.

[0178] RFC8955 defines 12 traffic matching rules: destination prefix, source prefix, IP protocol, port, destination port, source port, Internet Control Message Protocol (ICMP) type, ICMP code, Transmission Control Protocol (TCP) flags, Differentiated Services Code Point (DSCP), and fragment type. These 12 traffic matching rules are encapsulated and transmitted in the NLRI of BGP FS routes. The destination prefix is ​​also called the destination address, and the source prefix is ​​also called the source address. "Port" here refers to the port number, "destination port" refers to the destination port number, and "source port" refers to the source port number.

[0179] RFC8955 defines four traffic handling behaviors: dropping traffic, limiting traffic rate, modifying the packet's DSCP value, and redirecting to a VPN. These four traffic handling behaviors are encapsulated and transmitted in the extended community attribute of BGP FS routes.

[0180] 4. BGP-LS

[0181] For more information about the BGP-LS standard, please refer to https: / / datatracker.ietf.org / doc / draft-ietf-idr-rfc7752bis / .

[0182] BGP-LS is a protocol used to collect network topology information. BGP-LS makes topology collection simpler and more efficient.

[0183] BGP-LS routes can be used to carry six types of routing information: node information, link information, IPv4 routing prefix information, IPv6 routing prefix information, segment routing internet protocol version 6 (SRv6) segment identifier (SID) routing information, and traffic engineering (TE) policy routing information.

[0184] Building on traditional BGP, BGP-LS introduces a link-state NLRI (LS-NLRI) field to carry the six types of routing information described above. BGP-LS uses the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as containers for the LS-NLRI field. That is, the LS-NLRI can be included in either the MP_REACH_NLRI or MP_UNREACH_NLRI attributes.

[0185] For example, Figure 5 is a schematic diagram of the LS-NLRI field. The LS-NLRI field includes an NLRI type subfield, an NLRI length subfield, and a link-state NLRI subfield. The length of the NLRI type subfield and the length of the NLRI length subfield are each 2 bytes, and the length of the link-state NLRI subfield is variable. The NLRI type subfield is used to identify the NLRI type, the NLRI length subfield is used to identify the length of the link-state NLRI subfield, and the link-state NLRI subfield is used to carry the value of the NLRI type. The SAFI value of the BGP-LS address family is 71. BGP-LS mainly defines the six types of LS-NLRI shown in Table 3 below.

[0186] Table 3

[0187] The above is only a brief introduction to BGP, SD-WAN, BGP FS, and BGP-LS. For detailed information about BGP, SD-WAN, BGP FS, and BGP-LS, please refer to the relevant standard documents. This article will not go into details.

[0188] The technical solutions of the embodiments of the present application are introduced below, and the application scenarios of the embodiments of the present application are first introduced.

[0189] The application scenario of the embodiment of the present application includes at least two management domains, and the at least two management domains are interconnected. The at least two management domains are networks managed by at least two managers, and the managers of the at least two management domains are different. For example, the at least two management domains include network 1 managed by manager 1 (for example, network 1 is referred to as management domain 1), network 2 managed by manager 2 (for example, network 2 is referred to as management domain 2), network 3 managed by manager 3 (for example, network 3 is referred to as management domain 3), etc. Manager 1, manager 2, and manager 3 are different, and management domain 1, management domain 2, and management domain 3 are different. In a specific embodiment, manager 1, manager 2, and manager 3 include operators, enterprises, departments within enterprises, etc., and management domain 1, management domain 2, and management domain 3 include operator networks, enterprise networks, networks of different departments within enterprises, etc.

[0190] In an optional embodiment, a management domain is an AS domain, or a management domain includes multiple AS domains, or a management domain is a part of an AS domain, which is not limited in the embodiments of the present application.

[0191] The technical solution of the embodiments of the present application relates to the establishment of an end-to-end tunnel across management domains in a scenario where at least two management domains are interconnected. Specifically, it relates to the establishment of an end-to-end tunnel from a network node (e.g., an ingress node) in a certain management domain to another network node (e.g., an egress node) in another management domain. For example, the at least two management domains include a branch network and a backbone network, and the technical solution of the embodiments of the present application relates to the establishment of an end-to-end tunnel from the ingress node of the branch network to the egress node of the backbone network.

[0192] In the embodiment of the present application, the backbone network includes a self-built backbone network, a managed service provider (MSP) backbone network, etc., and the branch network includes an SD-WAN branch network, a traditional branch network, etc., which is not limited in the embodiment of the present application.

[0193] In an embodiment of the present application, each of the at least two management domains includes multiple network nodes. A network node can be a physical node or a logical node. A physical node can be a network device such as a switch or router, or a communication entity such as a chip, interface board, or line card within a network device. For example, network devices include access routers (ARs) and network elements (NEs). A logical node can be a functional module within a network device. For example, a logical node is a virtual switch or virtual router created within a network device. Virtual switches or virtual routers can be created within a network device based on virtualization technologies such as virtual machines (VMs) and containers. A management domain includes network nodes located at the edge of the management domain, which are also referred to as edge nodes. The edge nodes of a management domain include ingress nodes and egress nodes. An ingress node is used for traffic entering the management domain, while an egress node is used for traffic leaving the management domain. The at least two management domains can include the same edge node, meaning that a network node can simultaneously serve as an edge node for at least two management domains. For example, a network node can be an ingress node for one management domain and an egress node for another management domain. For example, the edge nodes of the backbone network include provider edge (PE) nodes, and the edge nodes of the branch network include customer edge (CE) nodes, customer premises equipment (CPE), etc. For example, the edge nodes of a traditional branch network include CE nodes, and the edge nodes of an SD-WAN branch network include CPE. Both CE nodes and CPE are used for user devices to access the network. User devices include but are not limited to industrial equipment, user terminals, home gateways, base stations, hosts, servers, virtual machines (VM) created in servers, etc. The host can be a smartphone, tablet computer, desktop computer, Internet of Things (IoT) device, etc.

[0194] In optional embodiments, the application scenarios of the embodiments of the present application also include a controller and / or a route reflector (RR) to perform route reflection between network nodes. The controller is also used for service control, etc., which is not limited in the embodiments of the present application. The controller can be a functional module deployed in a server, a single server, a server cluster consisting of multiple servers, or a cloud computing service center. In some embodiments, the controller is also referred to as a control node, manager, network manager, network controller, etc.

[0195] Please refer to Figure 6, which shows a schematic diagram of an application scenario provided by an embodiment of the present application. Figure 6 takes the interconnection of two management domains as an example. As shown in Figure 6. The first management domain includes network nodes 1 to 6. The second management domain includes network nodes 1 to 2 and network node 7. Network nodes 1 to 2 and network nodes 5 to 6 are edge nodes of the first management domain. Network nodes 1 to 2 and network node 7 are edge nodes of the second management domain. The first management domain and the second management domain are interconnected through network nodes 1 to 2. For example, network node 7 is the entry node of the second management domain, network nodes 1 to 2 are the exit nodes of the second management domain and are the entry nodes of the first management domain, and network nodes 5 to 6 are the exit nodes of the first management domain.

[0196] In an optional embodiment, the first management domain is a backbone network, the second management domain is a branch network, and network nodes 1 to 2 serve as both PE nodes of the first management domain and CE nodes of the second management domain. The network nodes in the backbone network that connect to the branch network are generally called gateway (GW) nodes. Therefore, the network nodes 1 to 2 in the application scenario shown in Figure 6 are all GW nodes. In a specific embodiment, the first management domain is a self-built backbone network or an MSP backbone network, and the second management domain is an SD-WAN branch network or a traditional branch network. This embodiment of the present application does not limit this.

[0197] In an optional embodiment, as shown in Figure 6, the application scenario also includes a controller 10, which is connected to network nodes 1 to 7 respectively (for the sake of simplicity, Figure 6 only shows the connection lines between the controller 10 and network node 1 and network node 7). The controller 10 can perform route reflection between network nodes 1 to 7, and the controller 10 can also control network nodes 1 to 7 to perform service forwarding, etc.

[0198] FIG6 illustrates the interconnection of two management domains as an example. The embodiment of the present application is also applicable to scenarios in which three or more management domains are interconnected.

[0199] Please refer to Figure 7, which shows a schematic diagram of another application scenario provided by an embodiment of the present application. Figure 7 uses the interconnection of three management domains as an example. As shown in Figure 7, the first management domain includes network nodes 1-6. The second management domain includes network nodes 1-2 and network node 7. The third management domain includes network nodes 5-6 and network node 8. Network nodes 1-2 and network nodes 5-6 are edge nodes of the first management domain. Network nodes 1-2 and network node 7 are edge nodes of the second management domain. Network nodes 5-6 and network node 8 are edge nodes of the third management domain. The first and second management domains are interconnected through network nodes 1-2. The second and third management domains are interconnected through network nodes 5-6. For example, network node 7 is the entry node of the second management domain, network nodes 1-2 are the egress nodes of the second management domain and the entry nodes of the first management domain, network nodes 5-6 are the egress nodes of the first management domain and the entry nodes of the third management domain, and network node 8 is the egress node of the third management domain.

[0200] In an optional embodiment, as shown in Figure 7, the first management domain is a backbone network, the second and third management domains are branch networks, network nodes 1-2 serve as both PE nodes for the first management domain and CE nodes for the second management domain, and network nodes 5-6 serve as both PE nodes for the first management domain and CE nodes for the third management domain. Both network nodes 1-2 and 5-6 can be gateway nodes. In a specific embodiment, the first management domain is a self-built backbone network or an MSP backbone network, the second management domain is an SD-WAN branch network, and the third management domain is a traditional branch network.

[0201] In an optional embodiment, as shown in Figure 7, the application scenario also includes a controller 10, which is connected to network nodes 1 to 8 respectively (for the sake of simplicity, Figure 6 only shows the connection lines between the controller 10 and network node 1 and network node 7). The controller 10 can perform route reflection between network nodes 1 to 8, and the controller 10 can also control network nodes 1 to 7 to perform service forwarding, etc.

[0202] As shown in Figures 6 and 7, the second network domain includes tunnel 01 from network node 7 to network node 1. The head node of tunnel 01 is network node 7, and the tail node of tunnel 01 is network node 1. The first administrative domain includes multiple tunnels 11-13 from network node 1 to network node 6. The head nodes of tunnels 11-13 are all network node 1, and the tail nodes of tunnels 11-13 are all network node 6. Currently, network node 7 in the second administrative domain cannot understand the network topology within the first administrative domain. As a result, network node 7 cannot understand tunnels 11-13 from network node 1 to network node 6, and therefore cannot establish an end-to-end tunnel from network node 7 to network node 6 that passes through network node 1. In an embodiment of the present application, network node 1 can notify network node 7 of at least one tunnel between network node 1 and network node 6, so that network node 7 can learn about the at least one tunnel from network node 1 to network node 6, and thus network node 7 can establish an end-to-end tunnel from network node 7 to network node 6 based on tunnel 01 from network node 7 to network node 1 and the at least one tunnel from network node 1 to network node 6.

[0203] In a specific embodiment, network node 1 sends a tunnel identifier of at least one tunnel from network node 1 to network node 6 to network node 7 via a route, and network node 7 learns the at least one tunnel from network node 1 to network node 6 based on the route. Network node 1 may send the route directly to network node 7 or send the route to network node 7 via controller 10, which is not limited in this embodiment of the present application.

[0204] In a specific embodiment, in the application scenarios shown in Figures 6 and 7, the second management domain is an SD-WAN branch network, and tunnel 01 is an SD-WAN tunnel. Tunnels 11 to 13 include at least one of the following: a segment routing multiprotocol label switching (SR-MPLS) tunnel, an SRv6TE tunnel, a generic routing encapsulation (GRE) tunnel, an MPLS label distribution protocol (LDP) label switching path (LSP) tunnel, a BGP LSP tunnel, or a resource reservation protocol traffic engineering (RSVP-TE) LSP tunnel.

[0205] In an optional embodiment, at least one of the second management domain and the third management domain is an ADVPN network or an Ethernet virtual private network (EVPN) network. For example, the second management domain is an ADVPN network, and the third management domain is an EVPN network.

[0206] The application scenarios shown in Figures 6 and 7 are for illustrative purposes only and are not intended to limit the technical solutions of the embodiments of the present application. In actual implementation, the number of management domains, the type of management domains, the number of network nodes in the management domains, the number of controllers, the connection relationships between network nodes, and the connection relationships between network nodes and controllers included in the application scenario can be configured as needed, and the embodiments of the present application do not limit this.

[0207] The above is an introduction to the application scenarios of this application. The following introduces the method embodiments of the embodiments of this application.

[0208] The communication device described below can be a network node, such as a router or switch, or a communication entity within a network node, such as a chip, interface board, line card, or software-based communication device. The embodiments of this application do not limit the form of the communication device. For example, the following method embodiment is applied to the application scenario shown in Figures 6 or 7 , where the first communication device is an entry node for the first management domain and an egress node for the second management domain, the second communication device is an egress node for the first management domain, and the third communication device is an entry node for the second management domain. When the following method embodiment is applied to the application scenario shown in Figure 7 , the second communication device is also an entry node for the third management domain, and the fourth communication device is an egress node for the third management domain. The target communication device described in the following method embodiment can be the first communication device or the control device. In specific embodiments, referring to Figures 6 and 7 , the first communication device is network node 1 or a communication entity within network node 1, the second communication device is network node 6 or a communication entity within network node 6, the third communication device is network node 7 or a communication entity within network node 7, the fourth communication device is network node 8 or a communication entity within network node 8, and the control device is controller 10 or a communication entity within controller 10.

[0209] Please refer to Figure 8, which shows a flow chart of a network interconnection method provided by an embodiment of the present application. As shown in Figure 8, the method includes the following steps S801 to S804.

[0210] S801. The target communication device obtains a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from the first communication device to the second communication device. The head node of the first tunnel is the first communication device, and the tail node of the first tunnel is the second communication device.

[0211] The first tunnel belongs to the first management domain, and the first management domain and the second management domain are interconnected through the first communication device.

[0212] In an optional embodiment, the first tunnel identifier includes a segment identifier. For example, the first tunnel identifier is an MPLS label or an SRv6 SID. In some embodiments, a tunnel is also referred to as a path, and the tunnel identifier is also referred to as a path SID or a tunnel SID. The first tunnel can be, for example, any of an SR-MPLS tunnel, an SRv6 TE tunnel, a GRE tunnel, an MPLS LDP LSP tunnel, a BGP LSP tunnel, and an RSVP-TE LSP tunnel.

[0213] In an embodiment of the present application, the first tunnel identifier can identify a tunnel from the first communication device to the second communication device, or it can identify multiple tunnels from the first communication device to the second communication device (that is, the first tunnel identifier identifies a group of tunnels, and the group of tunnels has the same tunnel identifier). In one embodiment, the first tunnel identifier identifies a tunnel from the first communication device to the second communication device, the head node of the tunnel is the first communication device, the tail node of the tunnel is the second communication device, and the tunnel is the first tunnel. In another embodiment, the first tunnel identifier identifies multiple tunnels from the first communication device to the second communication device, the head nodes of the multiple tunnels are all the first communication device, the tail nodes of the multiple tunnels are all the second communication device, and the multiple tunnels are all the first tunnels. The embodiment of the present application does not limit the number of tunnels identified by the first tunnel identifier.

[0214] In an optional embodiment, the target communication device obtains multiple tunnel identifiers, including a first tunnel identifier and a third tunnel identifier. The first tunnel identifier identifies a first tunnel from the first communication device to the second communication device, and the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device. The head node of the first tunnel and the head node of the third tunnel are both the first communication device, and the tail node of the first tunnel and the tail node of the third tunnel are both the second communication device. The target communication device determines the first tunnel based on the performance information of the first tunnel and the performance information of the third tunnel, and then the target communication device obtains the first tunnel identifier that identifies the first tunnel. In a specific embodiment, the performance information of the tunnel is used to characterize the performance of the tunnel; the target communication device determines the performance of the first tunnel based on the performance information of the first tunnel; the target communication device determines the performance of the third tunnel based on the performance information of the third tunnel; and the target communication device determines the first tunnel based on the performance of the first tunnel and the performance of the third tunnel.

[0215] In a specific embodiment, the tunnel performance includes at least one of available bandwidth, delay, jitter, or packet loss rate. In one example, the tunnel performance includes available bandwidth, and the target communication device determines that the available bandwidth of the first tunnel is greater than the available bandwidth of the third tunnel. The target communication device determines the first tunnel based on the available bandwidth of the first tunnel being greater than the available bandwidth of the third tunnel. In another example, the tunnel performance includes delay, and the target communication device determines that the delay of the first tunnel is less than the delay of the third tunnel. The target communication device determines the first tunnel based on the delay of the first tunnel being less than the delay of the third tunnel. In yet another example, the tunnel performance includes jitter, and the target communication device determines that the jitter of the first tunnel is less than the jitter of the third tunnel. The target communication device determines the first tunnel based on the jitter of the first tunnel being less than the jitter of the third tunnel. In yet another example, the tunnel performance includes packet loss rate, and the target communication device determines that the packet loss rate of the first tunnel is less than the packet loss rate of the third tunnel. The target communication device determines the first tunnel based on the packet loss rate of the first tunnel being less than the packet loss rate of the third tunnel.

[0216] In a specific embodiment, the target communication device determines the first tunnel based on the performance of the first tunnel, the performance of the third tunnel, and a tunnel screening policy. The tunnel screening policy includes the prioritization of multiple performance metrics. For example, tunnel performance includes bandwidth, latency, jitter, and packet loss rate. The tunnel screening policy prioritizes these four performance metrics in descending order: available bandwidth, latency, jitter, and packet loss rate. In a specific embodiment, the tunnel screening policy prioritizes tunnels based on available bandwidth, then latency if available bandwidths are equal, then jitter if latency is equal, and finally packet loss rate if jitter is equal. Based on this tunnel screening policy, the target communication device first determines whether the available bandwidth of the first tunnel is equal to the available bandwidth of the third tunnel. If the available bandwidth of the first tunnel is unequal to the available bandwidth of the third tunnel, the target communication device determines the first tunnel based on the available bandwidths of the first and third tunnels. If the available bandwidths of the first and third tunnels are equal, the target communication device determines whether the latency of the first tunnel is equal to the latency of the third tunnel. When the delay of the first tunnel is not equal to the delay of the third tunnel, the target communication device determines the first tunnel based on the delay of the first tunnel and the delay of the third tunnel; when the delay of the first tunnel is equal to the delay of the third tunnel, the target communication device determines whether the jitter of the first tunnel is equal to the jitter of the third tunnel. When the jitter of the first tunnel is not equal to the jitter of the third tunnel, the target communication device determines the first tunnel based on the jitter of the first tunnel and the jitter of the third tunnel; when the jitter of the first tunnel is equal to the jitter of the third tunnel, the target communication device determines whether the packet loss rate of the first tunnel is equal to the packet loss rate of the third tunnel. When the packet loss rate of the first tunnel is not equal to the packet loss rate of the third tunnel, the target communication device determines the first tunnel based on the packet loss rate of the first tunnel and the packet loss rate of the third tunnel. It should be noted that the tunnel screening strategy described in this paragraph is only an example. The tunnel screening strategy can also be other strategies, and the priorities of the multiple performances indicated by the tunnel screening strategy can also be other priorities. The embodiments of the present application do not limit this tunnel screening strategy.

[0217] In an optional embodiment, the multiple tunnel identifiers obtained by the target communication device identify multiple tunnels from the first communication device to the second communication device (e.g., tunnels 11-13 shown in Figures 6 and 7). For example, the multiple tunnel identifiers correspond one-to-one to the multiple tunnels, with each tunnel identifier identifying one tunnel from the multiple tunnels. The head nodes of the multiple tunnels are all the first communication device, and the tail nodes of the multiple tunnels are all the second communication device. The target communication device determines the performance of the multiple tunnels based on the performance information of the multiple tunnels, and determines the first tunnel from the multiple tunnels based on the performance of the multiple tunnels. In one embodiment, the tunnel performance includes available bandwidth. The target communication device determines the tunnel with available bandwidth greater than a bandwidth threshold among the multiple tunnels as the first tunnel, and / or the target communication device determines the tunnel with the largest available bandwidth among the multiple tunnels as the first tunnel. In another embodiment, the tunnel performance includes latency. The target communication device determines the tunnel with latency less than a latency threshold among the multiple tunnels as the first tunnel, and / or the target communication device determines the tunnel with the smallest latency among the multiple tunnels as the first tunnel. In another embodiment, the performance of the tunnel includes jitter, and the target communication device determines the tunnel with jitter less than the jitter threshold among the multiple tunnels as the first tunnel, and / or the target communication device determines the tunnel with the smallest jitter among the multiple tunnels as the first tunnel. In another embodiment, the performance of the tunnel includes packet loss rate, and the target communication device determines the tunnel with packet loss rate less than the packet loss rate threshold among the multiple tunnels as the first tunnel, and / or the target communication device determines the tunnel with the smallest packet loss rate among the multiple tunnels as the first tunnel. It should be noted that the four embodiments described in this paragraph can be implemented separately or in combination. That is, in the process of determining the first tunnel among the multiple tunnels, the target communication device can consider only one performance of the tunnel or multiple performances. In addition, the target communication device can determine the first tunnel among the multiple tunnels based on the performance of the multiple tunnels and the tunnel screening strategy. The specific implementation process can refer to the above description, and the embodiments of the present application will not be repeated here.

[0218] It should be noted that, in some embodiments, tunnel performance information is also referred to as tunnel transmission performance information, tunnel service level agreement (SLA) information, tunnel metric information, tunnel quality information, etc. Correspondingly, tunnel performance is also referred to as tunnel transmission performance, tunnel SLA performance, tunnel metric, tunnel quality, etc. This embodiment of the present application does not limit this.

[0219] In an embodiment of the present application, the target communication device may be a first communication device or a control device. When the target communication device is a control device, the first communication device is connected to the target communication device (i.e., the control device). Depending on the target communication device, the implementation method for the target communication device to obtain the tunnel identifier that identifies the tunnel from the first communication device to the second communication device may be different, and the implementation method for the target communication device to obtain the performance information of the tunnel from the first communication device to the second communication device may be different. The following is an introduction into two cases.

[0220] The first case: the target communication device is the first communication device, the target communication device generates a tunnel identifier identifying a tunnel from the first communication device to the second communication device, and the target communication device detects the tunnel from the first communication device to the second communication device to obtain performance information of the tunnel.

[0221] In a specific embodiment, the target communication device receives VPN route A published by the second communication device, and the next hop address of VPN route A is the address of the second communication device. The target communication device determines at least one tunnel from the first communication device (i.e., the target communication device) to the second communication device based on the next hop address of VPN route A, the head node of the at least one tunnel is the first communication device, the tail node of the at least one tunnel is the second communication device, and the at least one tunnel includes the first tunnel. The target communication device generates a tunnel identifier that identifies the at least one tunnel, and the tunnel identifier of the at least one tunnel includes the first tunnel identifier. For example, the next hop address of VPN route A is the address of the loopback port of the second communication device, which is not limited in this embodiment of the present application.

[0222] The at least one tunnel from the first communication device to the second communication device may be pre-created or created after the target communication device receives VPN route A. In one embodiment, the at least one tunnel is pre-created by the target communication device. After the target communication device receives VPN route A, the target communication device determines the at least one pre-created tunnel based on the next hop address of VPN route A and generates a tunnel identifier for the at least one tunnel. In another embodiment, the at least one tunnel is created after the target communication device receives VPN route A. After the target communication device receives VPN route A, the target communication device creates the at least one tunnel from the first communication device to the second communication device based on the next hop address of VPN route A and generates a tunnel identifier for the at least one tunnel.

[0223] In a specific embodiment, VPN route A may be sent by the second communication device to the target communication device (i.e., the first communication device) through a session connection between the second communication device and the target communication device, or may be sent by the second communication device to the target communication device through a control device or a RR. The session connection between the target communication devices may be a BGP session connection or other session connection, which is not limited in this embodiment of the present application.

[0224] In a specific embodiment, VPN route A is published by a second communication device based on a VPN address family. The second communication device publishes (or announces) VPN route A using a BGP update message. VPN route A also includes a VPN SID, which is a service SID assigned by the second communication device. In an optional embodiment, VPN route A is a VPNv4 route published based on the VPNv4 address family, a VPNv6 route published based on the VPNv6 address family, or an EVPN route published based on the EVPN address family, which is not limited in this embodiment of the present application.

[0225] In an optional embodiment, the target communication device (i.e., the first communication device) continues to send VPN route A after receiving VPN route A published by the second communication device. For example, the target communication device sends VPN route A to the BGP peer of the target communication device. In one embodiment, the target communication device (i.e., the first communication device) establishes a BGP peer relationship with the control device, and the target communication device sends VPN route A to the control device. In another embodiment, the target communication device (i.e., the first communication device) establishes a BGP peer relationship with a third communication device in the second management domain, and the target communication device sends VPN route A to the third communication device. The target communication device can also send VPN route A to other BGP peers. In the embodiment of the present application, the target communication device does not modify the next hop address of VPN route A during the process of sending VPN route A (i.e., maintains the next hop address of VPN route A as the address of the second communication device), but may modify other information of VPN route A. These modifications belong to the standard operation of VPN route publication and do not affect the technical solution of the embodiment of the present application.

[0226] In the second scenario, the target communication device is a control device and is connected to a first communication device. The target communication device receives, from the first communication device, at least one tunnel identifier and performance information of at least one tunnel from the first communication device to the second communication device. The head node of the at least one tunnel is the first communication device, the tail node of the at least one tunnel is the second communication device, the at least one tunnel includes the first tunnel, and the tunnel identifier of the at least one tunnel includes the first tunnel identifier.

[0227] In an optional embodiment, the target communication device receives a route X1 sent by the first communication device, where the route X1 includes the at least one tunnel identifier of the at least one tunnel from the first communication device to the second communication device and the performance information of the at least one tunnel. The target communication device obtains the at least one tunnel identifier and the performance information of the at least one tunnel from the route X1.

[0228] In an optional embodiment, the route X1 may further include an identifier of a head node of the at least one tunnel (i.e., the first communication device) and an identifier of an end node of the at least one tunnel (i.e., the second communication device). The identifier of the head node of the at least one tunnel may be an address of the head node of the at least one tunnel, and the identifier of the end node of the at least one tunnel may be an address of the end node of the at least one tunnel.

[0229] In an optional embodiment, routing X1 includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP routing policy distribution (BGP-RPD) routing; overlay management protocol (OMP) routing; path computation element communication protocol (PCEP) routing. BGP label routing includes any one of the following: BGP unicast label (LU) routing; BGP classful transport planes (CT) routing; BGP color-aware routing (CAR). Among them, BGP CT routing is also called BGP intent transport plane routing, and BGP CAR is also called BGP intent-aware routing.

[0230] The implementation of the tunnel identifier carried by the route X1 varies depending on the route X1, which is described in four embodiments below.

[0231] In a first embodiment, route X1 is a BGP FS route, an OMP route, or a PCEP route. Route X1 includes a traffic control policy, wherein the traffic control policy includes a tunnel identifier of at least one tunnel from a first communication device to a second communication device. For example, the traffic control policy includes multiple traffic matching rules, each traffic matching rule includes flow feature information and a tunnel identifier, wherein the tunnel identifier identifies the tunnel from the first communication device to the second communication device. The flow feature information includes at least one of a destination address, a source address, an IP protocol number, a port number, a destination port number, a source port number, an ICMP type, an ICMP code, a TCP flag, a DSCP, or a fragmentation type.

[0232] In one example, route X1 is a BGP FS route, and route X1 includes an MP_REACH_NLRI attribute, which includes at least one tunnel identifier of at least one tunnel from the first communication device to the second communication device. In a specific example, the format of the MP_REACH_NLRI attribute is shown in Figure 1, and the NLRI field of the MP_REACH_NLRI attribute includes the at least one tunnel identifier. For example, the NLRI field of the MP_REACH_NLRI attribute includes at least one NLRI field corresponding to the at least one tunnel identifier, and the at least one tunnel identifier is carried in the at least one NLRI field in a one-to-one correspondence. In this example, the value of the AFI field of the MP_REACH_NLRI attribute is 1 or 2, and the value of the SAFI field of the MP_REACH_NLRI attribute is 133 or 134.

[0233] In another example, route X1 is an OMP route or a PCEP route, and route X1 includes a matching type-length-value (TLV) field and an action TLV field. The matching TLV field can be used to carry the destination VPN prefix. The action TLV field includes a tunnel identifier of the tunnel from the first communication device to the second communication device. Among them, one action TLV field can carry one or more tunnel identifiers. When one action TLV field carries one tunnel identifier, route X1 can carry multiple tunnel identifiers through multiple action TLV fields. In a specific example, the format of the matching TLV field is shown in Figure 9, and the format of the action TLV field is shown in Figure 10.

[0234] Referring to Figure 9, the match TLV field includes a type subfield, a length subfield, and a match condition subfield. The match condition subfield is used to carry the destination VPN prefix. The type subfield is used to identify the type of the match condition subfield (specifically, the value of the match condition subfield). In this example, the type subfield is used to identify that the type of the match condition subfield is an address prefix (e.g., an IP address prefix). The length subfield is used to identify the length of the match condition subfield. For example, the length of the type subfield is 1 byte, the length of the length subfield is 2 bytes, and the length of the match condition subfield is variable.

[0235] Referring to Figure 10, the action TLV field includes a type subfield, a length subfield, and an action parameter subfield. The action parameter subfield is used to carry a tunnel identifier. The type subfield is used to identify the type of the action parameter subfield (specifically, the value of the action parameter subfield). In this example, the type subfield is used to identify that the type of the action parameter subfield is a tunnel identifier. The length subfield is used to identify the length of the action parameter subfield. For example, the length of the type subfield is 1 byte, the length of the length subfield is 2 bytes, and the length of the action parameter subfield is variable. In an optional embodiment, the action TLV field shown in Figure 10 is used to carry a tunnel identifier, and route X1 may include multiple action TLV fields as shown in Figure 10 to carry multiple tunnel identifiers.

[0236] Second embodiment: Route X1 is BGP-RPD routing, OMP routing or PCEP routing, and route X1 includes a routing control policy, which includes a tunnel identifier of at least one tunnel from the first communication device to the second communication device.

[0237] For example, route X1 includes a match TLV field and an action TLV field. The match TLV field can be used to carry the destination VPN prefix, and the action TLV field includes the tunnel identifier of the tunnel from the first communication device to the second communication device. Among them, one action TLV field can carry one or more tunnel identifiers. When one action TLV field carries one tunnel identifier, route X1 can carry multiple tunnel identifiers through multiple action TLV fields. In a specific example, the format of the match TLV field is shown in Figure 9, and the format of the action TLV field is shown in Figure 10. The action TLV field shown in Figure 10 is used to carry a tunnel identifier, and route X1 may include multiple action TLV fields as shown in Figure 10 to carry multiple tunnel identifiers.

[0238] A third embodiment: Route X1 is an SD-WAN route or a BGP-LS route, and route X1 includes an MP_REACH_NLRI attribute, where the MP_REACH_NLRI attribute includes at least one tunnel identifier of at least one tunnel from the first communication device to the second communication device.

[0239] In a specific embodiment, the format of the MP_REACH_NLRI attribute is shown in Figure 1, and the NLRI field of the MP_REACH_NLRI attribute includes the at least one tunnel identifier. For example, the NLRI field includes an NLRI field, and the NLRI field includes the at least one tunnel identifier.

[0240] In one example, route X1 is an SD-WAN route, and the NLRI field of the MP_REACH_NLRI attribute of route X1 includes the NLRI field shown in Figure 11. The NLRI field can be referred to as the SD-WAN NLRI field (the NLRI field in the MP_REACH_NLRI attribute of the SD-WAN route). Referring to Figure 11, the SD-WAN NLRI field includes a route type subfield, a length subfield, a local endpoint (local-end-point) subfield, a remote endpoint (remote-end-point) subfield, and n tunnel identifier subfields, where n is a positive integer. The local endpoint subfield, the remote endpoint subfield, and the n tunnel identifier subfields constitute the type specific value subfield of the SD-WAN NLRI field. The route type subfield is used to carry the route type, and the value of the route type field is to be defined (TBD). The length subfield is used to identify the length of the type specific value subfield. The local endpoint subfield is used to carry the address of the local endpoint (in this embodiment, the head node of the tunnel from the first communication device to the second communication device, that is, the first communication device). The Remote Endpoint subfield is used to carry the address of the remote endpoint (in this embodiment, the tail node of the tunnel from the first communication device to the second communication device, i.e., the second communication device). The n Tunnel Identifier fields are used to carry the n tunnel identifiers of the n tunnels from the first communication device to the second communication device. For example, the length of the Routing Type subfield and the length subfield are 2 bytes, respectively. The length of the Local Endpoint subfield is 4 bytes or 16 bytes, the length of the Remote Endpoint subfield is 4 bytes or 16 bytes, and the length of the Tunnel Identifier subfield is 3 bytes or 16 bytes.

[0241] In another example, route X1 is a BGP-LS route. The NLRI field of the MP_REACH_NLRI attribute of route X1 includes the NLRI field shown in FIG5 . This NLRI field can be referred to as a BGP-LS NLRI field (the NLRI field in the MP_REACH_NLRI attribute of the BGP-LS route). This NLRI field includes at least one tunnel identifier of at least one tunnel from the first communication device to the second communication device. As shown in FIG5 , the NLRI field includes a link-state NLRI subfield. This link-state NLRI subfield is used to carry a tunnel identifier. A link-state NLRI subfield can carry one or more tunnel identifiers. When a link-state NLRI subfield carries one tunnel identifier, the BGP-LS NLRI field can carry multiple tunnel identifiers via multiple link-state NLRI subfields.

[0242] Fourth embodiment: Route X1 is a BGP label route, and route X1 includes an MP_REACH_NLRI attribute or a BGP prefix segment identifier (prefix-SID) attribute. The MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes at least one tunnel identifier of at least one tunnel from the first communication device to the second communication device. As can be seen from the foregoing description, route X1 can be any one of a BGP LU route, a BGP CT route, and a BGP CAR route. The following uses the BGP LU route, the BGP CT route, and the BGP CAR route as examples for explanation.

[0243] In one embodiment, route X1 is a BGP LU route, a BGP CT route, or a BGP CAR route, and route X1 includes an MP_REACH_NLRI attribute, where the MP_REACH_NLRI attribute includes at least one tunnel identifier of at least one tunnel from the first communication device to the second communication device. In a specific example, the format of the MP_REACH_NLRI attribute is shown in FIG1 . The NLRI field of the MP_REACH_NLRI attribute includes an NLRI field, where the NLRI field includes a label subfield, where the label subfield includes a tunnel identifier of the tunnel from the first communication device to the second communication device.

[0244] In a specific example, the NLRI field in the NLRI domain of the MP_REACH_NLRI attribute of a BGP LU route can be referred to as a BGP LU NLRI field. When route X1 is a BGP LU route, the NLRI field of the MP_REACH_NLRI attribute of route X1 includes the BGP LU NLRI field shown in FIG12 . Referring to FIG12 , the BGP LU NLRI field includes a length subfield, a prefix subfield, n label subfields, n reserved subfields, and n S bits (bottom of stack mark bits), where n is a positive integer. The length subfield is used to identify the total length of the subfields in the BGP LU NLRI field excluding the length subfield. The prefix subfield is used to carry the address of the tail node of the tunnel from the first communication device to the second communication device. The n label subfields are used to carry n tunnel identifiers of the n tunnels from the first communication device to the second communication device. The n S bits correspond one-to-one to the n label subfields, and each S bit is used to identify whether the corresponding label subfield is the bottom-of-stack label subfield (i.e., whether the corresponding label subfield is the last label subfield). For example, among the n label subfields, the S bit corresponding to the first n-1 label subfields has a value of 0, and the S bit corresponding to the nth label subfield has a value of 1, indicating that none of the first n-1 label subfields is the bottom-of-stack label subfield, and the nth label subfield is the bottom-of-stack label subfield. For example, the length subfield has a length of 1 byte; the length of the label subfield has a length of 20 bits; the length of the reserved subfield has a length of 3 bits; the S bit has a length of 1 bit; the length of the prefix subfield is typically 32 bytes or 128 bytes; the length of the prefix subfield is equal to the length indicated by the length subfield minus the difference between the lengths of the n label subfields, the lengths of the n reserved subfields, and the lengths of the n S bits. It should be noted that the BGP LU NLRI field shown in Figure 12 is applicable to tunnel identifiers in label form. In the case where the tunnel identifier is an MPLS label, the BGP LU NLRI field shown in FIG. 12 may be used to carry the tunnel identifier of the tunnel from the first communication device to the second communication device.

[0245] In a specific example, the NLRI field in the NLRI domain of the MP_REACH_NLRI attribute of a BGP CT route can be referred to as the BGP CT NLRI field. If route X1 is a BGP CT route, the NLRI field of the MP_REACH_NLRI attribute of route X1 includes the BGP CT NLRI field shown in FIG13 . Referring to FIG13 , the format of the BGP CT NLRI field is substantially the same as the format of the BGP LU NLRI field shown in FIG12 , except that the BGP CT NLRI field also includes a route distinguisher (RD) subfield. In the BGP CT NLRI field, the RD subfield is used to carry a route identifier, and the prefix subfield is used to carry an address. The RD subfield and the prefix subfield, combined, indicate the egress node of the tunnel from the first communication device to the second communication device. The RD subfield is 8 bytes long. For a description of the meaning of the other fields in the BGP CT NLRI field, please refer to the explanation of the BGP LU NLRI field shown in FIG12 , and will not be repeated here. It should be noted that the BGP CT field shown in Figure 13 is applicable to tunnel identifiers in the form of labels. When the tunnel identifier is an MPLS label, the BGP CT field shown in Figure 13 can be used to carry the tunnel identifier of the tunnel from the first communication device to the second communication device.

[0246] In a specific example, the NLRI field in the NLRI domain of the MP_REACH_NLRI attribute of the BGP CAR route can be called the BGP CAR NLRI field. When route X1 is a BGP CAR route, the NLRI field of the MP_REACH_NLRI attribute of route X1 includes the BGP CAR NLRI field shown in Figure 14 and / or the BGP CAR NLRI field shown in Figure 15.

[0247] Referring to Figure 14, the BGP CAR NLRI field includes an NLRI length subfield, a key length subfield, an NLRI type subfield, a prefix length subfield, an IP prefix subfield, a color subfield, and n label TLV fields, where n is a positive integer. The label TLV field includes an R bit (reserved bit), a T bit (transfer indicator bit), a type subfield, a length subfield, a label subfield, a reserved subfield, and an S bit (bottom of stack marker bit). The NLRI length subfield is used to identify the total length of the subfields in the BGP CAR NLRI field excluding the NLRI length subfield. The key length subfield is used to identify key fields in the BGP CAR NLRI field (for example, including the IP prefix subfield). The NLRI type subfield is used to identify the NLRI type. In this application, the value of the NLRI type subfield can be 1. The prefix length subfield is used to identify the length of the IP prefix subfield. The IP prefix subfield is used to carry the IP prefix. In the present application, the IP prefix subfield can carry the address of the tail node of the tunnel from the first communication device to the second communication device. The color subfield can be used to carry the second tunnel identifier described later in this application. In the label TLV field: the T bit is used to identify whether the label TLV field is transferable; when the value of the T bit is 1, it indicates that the label TLV field is transferable; when the value of the T bit is 0, it indicates that the label TLV field is not transferable; the type subfield is used to identify the type of the value field of the label TLV field (for example, the label subfield, the reserved subfield and the S bit constitute the value field); the length subfield is used to identify the length of the value field of the label TLV field; the label subfield is used to carry the tunnel identifier of the tunnel from the first communication device to the second communication device, and the S bit is used to identify whether the label subfield is the bottom label subfield (or to identify whether the label TLV field is the bottom label TLV field). For example, among the n label TLV fields, the S bit in the first n-1 label TLV fields has a value of 0, and the S bit in the nth label TLV field has a value of 1, indicating that none of the first n-1 label TLV fields are bottom-of-stack label TLV fields, and the nth label TLV field is a bottom-of-stack label TLV field. For example, the length of the NLRI length subfield, the length of the key length subfield, the length of the NLRI type subfield, and the length of the prefix length subfield are all 1 byte, the length of the R bit and the length of the T bit are both 1 bit, the length of the type subfield in the label TLV field is 6 bits, the length subfield in the label TLV field is 1 byte, the length of the label subfield in the label TLV field is 20 bits, the length of the reserved subfield is 3 bits, and the S bit is 1 bit. It should be noted that the BGP CAR NLRI field shown in Figure 14 is applicable to tunnel identifiers in label form.When the tunnel identifier is an MPLS label, the BGP CAR NLRI field shown in Figure 14 can be used to carry n tunnel identifiers of n tunnels from the first communication device to the second communication device, and the n tunnel identifiers are carried one-to-one in the label subfields in the n label TLV fields.

[0248] As shown in Figure 15 , the BGP CAR NLRI field includes the NLRI Length subfield, Key Length subfield, NLRI Type subfield, Prefix Length subfield, IP Prefix subfield, Color subfield, and n SRv6 SID TLV fields, where n is a positive integer. For a description of the meaning of the NLRI Length subfield, Key Length subfield, NLRI Type subfield, Prefix Length subfield, IP Prefix subfield, and Color subfield, please refer to the explanation of the BGP CAR NLRI field shown in Figure 14 ; these are not detailed here. This section focuses on the SRv6 SID TLV field. As shown in Figure 15 , the SRv6 SID TLV field includes an R bit (reserved bit), a T bit (transfer indicator bit), a Type subfield, a Length subfield, and an SRv6 SID Information subfield. The T bit indicates whether the SRv6 SID TLV field is transferable. The Type subfield identifies the type of the Value field (e.g., the SRv6 SID Information subfield) of the SRv6 SID TLV field. The Length subfield identifies the length of the SRv6 SID TLV field. The SRv6SID TLV field is used to carry a tunnel identifier of a tunnel from the first communication device to the second communication device. It should be noted that the BGP CAR NLRI field shown in Figure 15 is applicable to a tunnel identifier in the form of an SRv6SID. In the case where the tunnel identifier is an SRv6SID, the BGP CAR NLRI field shown in Figure 15 can be used to carry n tunnel identifiers of n tunnels from the first communication device to the second communication device, and the n tunnel identifiers are carried in a one-to-one correspondence in the SRv6SID information subfield in the n SRv6SID TLV fields.

[0249] In another embodiment, route X1 is a BGP LU route, a BGP CT route, or a BGP CAR route, and route X1 includes a BGP prefix-SID attribute, where the BGP prefix-SID attribute includes at least one tunnel identifier of at least one tunnel from the first communication device to the second communication device. In a specific example, the BGP prefix-SID attribute includes an SRv6 service TLV field, where the SRv6 service TLV field includes an SRv6 SID message sub-TLV field, where the SRv6 SID message sub-TLV field is used to carry the tunnel identifier.

[0250] In a specific example, the format of the BGP prefix-SID attribute is shown in Figure 16. The BGP prefix-SID attribute includes an attribute tag (Attr.flags) field, an attribute type (Attr.type) field, a length field, and at least one TLV field. The attribute tag field is used to carry the attribute tag of the BGP prefix-SID attribute, the attribute type field is used to carry the attribute type of the BGP prefix-SID attribute, and the length field is used to identify the total length of the field after the length field in the BGP prefix-SID attribute. The at least one TLV field includes an SRv6 service TLV field. The SRv6 service TLV field includes a TLV type (TLV type) subfield, a TLV length (TLV length) subfield, a reserved field, and multiple SRv6 service sub-TLV (SRv6service sub-TLV) fields. The TLV type subfield is used to identify the type of the SRv6 service TLV field, and the TLV length subfield is used to identify the length of the SRv6 service TLV field. The multiple SRv6 service sub-TLVs include n SRv6SID message sub-TLV fields. The SRv6 SID message sub-TLV field includes: an SRv6 service sub-TLV type field, an SRv6 service sub-TLV length field, a reserved field, an SRv6 SID field (also known as an SRv6 SID value field), an SRv6 service SID tag field, an SRv6 endpoint behavior field, and at least one SRv6 service data sub-sub-TLV field. The SRv6 service sub-TLV type field is used to identify the type of the SRv6 SID message sub-TLV field, the SRv6 service sub-TLV length field is used to identify the length of the SRv6 SID message sub-TLV field, the SRv6 SID field is used to carry the tunnel identifier of the tunnel from the first communication device to the second communication device, the SRv6 service SID tag is used to carry the SRv6 service SID tag, the SRv6 endpoint behavior field is used to carry the SRv6 endpoint behavior, and the SRv6 endpoint behavior field is used to carry the SRv6 endpoint behavior. It should be noted that the BGP CAR NLRI field shown in Figure 16 is applicable to tunnel identifiers in the form of SRv6SID. When the tunnel identifier is an SRv6SID, the BGP prefix-SID attribute shown in Figure 16 can be used to carry the n tunnel identifiers of the n tunnels from the first communication device to the second communication device. The n tunnel identifiers are carried in a one-to-one correspondence in the n SRv6SID message sub-TLV fields.

[0251] The preceding describes how to implement X1 bearer tunnel identification. The following describes how to implement performance information for X1 bearer tunnels. This information applies to SD-WAN routing, BGP-LS routing, BGP label routing, BGP FS routing, BGP-RPD routing, OMP routing, and PCEP routing. It also applies to BGP LU routing, BGP CT routing, and BGP CAR.

[0252] In an optional embodiment, route X1 includes a BGP tunnel performance attribute, which is a community attribute based on a BGP extension. The BGP tunnel performance attribute includes performance information of at least one tunnel from the first communication device to the second communication device. In a specific embodiment, the BGP tunnel performance attribute includes at least one TLV field, each of which corresponds one-to-one to the at least one tunnel, and each of the at least one TLV field is used to carry performance information of the corresponding tunnel. For example, the format of the BGP tunnel performance attribute is shown in FIG17 . Referring to FIG17 , the BGP tunnel performance attribute includes an attribute flag (Attr.flags) field, an attribute type (Attr.type) field, and n TLV fields, where n is a positive integer. The attribute flag field is used to carry the attribute flag of the BGP tunnel performance attribute, the attribute type field is used to carry the attribute type of the BGP tunnel performance attribute, and the length field is used to identify the total length of the fields following the length field in the BGP tunnel performance attribute. The n TLV fields are used to carry performance information of the n tunnels from the first communication device to the second communication device. Specifically, each of the n TLV fields includes a type subfield, a length subfield, a tunnel identifier subfield, and at least one metric sub-TLV field. In each of the n TLV fields: the type subfield is used to identify the type of the TLV field, the length subfield is used to identify the length of the TLV field, the tunnel identifier subfield is used to carry the tunnel identifier of a tunnel from the first communication device to the second communication device, and the at least one metric sub-TLV field is used to carry performance information of the tunnel. In a specific embodiment, the format of the metric sub-TLV field is shown in Figure 18. The metric sub-TLV field includes a type subfield, a length subfield, and a value subfield. The type subfield is used to identify the type of information carried by the value subfield, the length subfield is used to identify the length of the value subfield, and the value subfield is used to carry performance information of the tunnel. For example, the performance information of the tunnel includes at least one of available bandwidth, delay, jitter or packet loss rate. The formats of the metric sub-TLV fields used to carry different types of performance information are shown in Figure 18. The difference is that the value of the type subfield of the metric sub-TLV field is different, and the information carried by the value subfield of the metric sub-TLV field is different.

[0253] It should be noted that the BGP tunnel performance attributes shown in Figure 18 can carry the tunnel identifier. Therefore, in one possible case, there is no need to use the MP_REACH_NLRI attribute or the BGP prefix-SID attribute to carry the tunnel identifier. The BGP tunnel performance attributes shown in Figure 18 can be used to carry the tunnel identifier and the tunnel performance information. In addition, Figure 18 is only an example of the BGP tunnel performance attributes, and the format of the BGP tunnel performance attributes can also be other formats. In one example, the correspondence between the fields in the BGP tunnel performance attributes and the tunnel identifier in the route X1 can be set, and the performance information of the tunnel identified by the tunnel identifier carried by the route X1 (for example, the tunnel identifier carried by the MP_REACH_NLRI attribute or the BGP prefix-SID attribute) is carried in the field corresponding to the tunnel identifier in the BGP tunnel performance attributes. In this way, there is no need to set the tunnel identifier field in the BGP tunnel performance attributes. In another example, an index can be set for the tunnel identifier, and an index field can be set in the BGP tunnel performance attribute to carry the index of the tunnel identifier. The performance information carried by the BGP tunnel performance attribute is associated with the tunnel identifier carried by route X1 through the index, so there is no need to set the tunnel identifier field in the BGP tunnel performance attribute.

[0254] The above embodiments are described as follows: when the target communication device is the first communication device, the target communication device generates a tunnel identifier for the tunnel from the first communication device to the second communication device, and the target communication device obtains the performance information of the tunnel from the first communication device to the second communication device through tunnel detection; and when the target communication device is the control device, the target communication device receives the tunnel identifier for the tunnel from the first communication device to the second communication device and the performance information of the tunnel from the first communication device to the second communication device sent by the first communication device. In some embodiments, the tunnel identifier for the tunnel from the first communication device to the second communication device can be generated by the control device, and / or the performance information of the tunnel from the first communication device to the second communication device can be detected by the control device. The control device can send the generated tunnel identifier and the performance information of the tunnel from the first communication device to the second communication device obtained through detection to the first communication device. The embodiments of the present application are not limited to this.

[0255] In an optional embodiment, the target communication device may further obtain a second tunnel identifier, where the second tunnel identifier identifies a second tunnel from the third communication device to the first communication device, the head node of the second tunnel being the third communication device, and the tail node of the second tunnel being the first communication device. For example, when the target communication device is a control device, or when the target communication device is the first communication device and the target communication device integrates the functionality of a controller, the target communication device obtains the second tunnel identifier. In a specific embodiment, the second tunnel comprises an SD-WAN tunnel. The first tunnel described in the above embodiment belongs to the first management domain, and the second tunnel belongs to the second management domain. The second management domain may be an SD-WAN network domain.

[0256] In a specific embodiment, the second management domain includes multiple tunnels from a third communication device to a first communication device, the head nodes of the multiple tunnels are all the third communication device, the tail nodes of the multiple tunnels are all the first communication device, the target communication device determines the second tunnel in the multiple tunnels, and the target communication device obtains (e.g., generates) a second tunnel identifier that identifies the second tunnel. In one embodiment, the target communication device determines the second tunnel from the multiple tunnels based on performance information of the multiple tunnels, or the target communication device randomly determines the second tunnel from the multiple tunnels. The implementation method of the target communication device determining the second tunnel based on the performance information of the multiple tunnels can refer to the implementation method of the target communication device determining the first tunnel based on the performance information of the multiple tunnels from the first communication device to the second communication device, which will not be repeated here.

[0257] S802. The target communication device sends a first tunnel identifier to the third communication device.

[0258] In a specific embodiment, the target communication device generates a first route based on the first tunnel identifier, and sends the first route to the third communication device. The first route includes the first tunnel identifier, the identifier of the head node of the first tunnel, and the identifier of the tail node of the first tunnel.

[0259] In an optional embodiment, in S801, the target communication device obtains multiple tunnel identifiers that identify multiple tunnels from the first communication device to the second communication device, and the target communication device does not screen the multiple tunnels, that is, the target communication device does not determine the first tunnel in the multiple tunnels. In S802, the target communication device sends the multiple tunnel identifiers to the third communication device. The multiple tunnel identifiers include the first tunnel identifier and the third tunnel identifier, the head node of the first tunnel and the head node of the third tunnel are both the first communication device, and the tail node of the first tunnel and the tail node of the third tunnel are the second communication device. In a specific embodiment, the head nodes of the multiple tunnels are all the first communication device, and the tail nodes of the multiple tunnels are all the second communication device. The target communication device generates a first route based on the multiple tunnel identifiers, and the first route includes the multiple tunnel identifiers, the identifiers (e.g., addresses) of the head nodes of the multiple tunnels, and the identifiers (e.g., addresses) of the tail nodes of the multiple tunnels.

[0260] In an optional embodiment, the first route includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP-RPD routing; OMP routing; PCEP routing. BGP label routing includes any one of the following: BGP LU routing; BGP CT routing; BGP CAR. In one embodiment, the first route is a BGP FS routing, an OMP routing, or a PCEP routing, and the first route includes a traffic control policy, which includes a first tunnel identifier. For example, the traffic control policy includes multiple tunnel identifiers of multiple tunnels from the first communication device to the second communication device, the multiple tunnels include the first tunnel, and the multiple tunnel identifiers include the first tunnel identifier. In another embodiment, the first route is a BGP-RPD routing, an OMP routing, or a PCEP routing, and the first route includes a routing control policy, which includes the first tunnel identifier. For example, the routing control policy includes multiple tunnel identifiers of multiple tunnels from the first communication device to the second communication device, the multiple tunnels include the first tunnel, and the multiple tunnel identifiers include the first tunnel identifier. In another embodiment, the first route is an SD-WAN route or a BGP-LS route, and the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes a first tunnel identifier. For example, the MP_REACH_NLRI attribute includes multiple tunnel identifiers of multiple tunnels from the first communication device to the second communication device, the multiple tunnels include the first tunnel, and the multiple tunnel identifiers include the first tunnel identifier. In another embodiment, the first route is a BGP label route, and the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes the first tunnel identifier. For example, the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes multiple tunnel identifiers of multiple tunnels from the first communication device to the second communication device, the multiple tunnels include the first tunnel, and the multiple tunnel identifiers include the first tunnel identifier. The implementation method of the first route carrying the tunnel identifier can refer to the implementation method of the route X1 carrying the tunnel identifier in S801, which will not be repeated here. It should be noted that the first route also includes an identifier (e.g., an address) of the head node of the first tunnel and an identifier (e.g., an address) of the tail node of the first tunnel. The implementation method of the first route carrying the identifier of the head node of the first tunnel and the identifier of the tail node of the first tunnel can refer to the implementation method of the route X1 carrying the identifier of the head node of the first tunnel and the identifier of the tail node of the first tunnel in S801.

[0261] In an optional embodiment, the target communication device further transmits performance information of the first tunnel to the third communication device. For example, the target communication device transmits performance information of multiple tunnels from the first communication device to the second communication device to the third communication device. In a specific embodiment, the first route includes BGP tunnel performance attributes, which include performance information of multiple tunnels from the first communication device to the second communication device. The format of the BGP tunnel performance attributes can be found in Figure 17 and its related description, and is not further described in this embodiment of the present application.

[0262] In an optional embodiment, the target communication device further sends a second tunnel identifier to the third communication device. The second tunnel identifier identifies a second tunnel from the third communication device to the first communication device, where the head node of the second tunnel is the third communication device and the tail node of the second tunnel is the first communication device. For example, when the target communication device is a control device, or when the target communication device is the first communication device and integrates controller functionality, the target communication device sends the second tunnel identifier to the third communication device. In a specific embodiment, the first route generated by the target communication device also includes the second tunnel identifier, and the target communication device sends the second tunnel identifier to the third communication device via the first route. In one example, the first route includes a color extended community attribute, the color extended community attribute includes a color field, and the color field includes the second tunnel identifier. That is, the color value of the color field is the second tunnel identifier. In another example, the first route includes a "transport class" route target extended community attribute, the "transport class" route target extended community attribute includes a transport class ID field, and the transport class ID field includes the second tunnel identifier. That is, the value of the transport class ID field is the second tunnel identifier. In a specific example, the color extended community attribute is shown in Figure 19, which includes a type field, a subtype field, a tag field, and a color field. The "transport class" route target extended community attribute is shown in Figure 20, which includes a type field, a subtype field, a reserved field, and a transport class identifier field.

[0263] S803. The third communication device receives the first tunnel identifier.

[0264] In a specific embodiment, the third communication device receives a first route sent by a target communication device, the first route including a first tunnel identifier, an identifier of a head node of the first tunnel, and an identifier of an end node of the first tunnel, wherein the target communication device is the first communication device or the control device.

[0265] In an optional embodiment, the third communication device receives multiple tunnel identifiers, and the multiple tunnel identifiers include a first tunnel identifier and a third tunnel identifier. The first tunnel identifier identifies a first tunnel from the first communication device to the second communication device, and the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device. The head node of the first tunnel and the head node of the third tunnel are both the first communication device, and the tail node of the first tunnel and the tail node of the third tunnel are both the second communication device. In a specific embodiment, the multiple tunnel identifiers identify multiple tunnels from the first communication device to the second communication device. For example, the multiple tunnel identifiers correspond one-to-one to the multiple tunnels, and each tunnel identifier identifies one tunnel among the multiple tunnels. The head nodes of the multiple tunnels are all the first communication device, and the tail nodes of the multiple tunnels are all the second communication device. In a specific embodiment, the third communication device receives a first route sent by the target communication device, and the first route includes the multiple tunnel identifiers.

[0266] In an optional embodiment, the third communication device further receives performance information of the first tunnel sent by the target communication device. For example, the third communication device receives performance information of multiple tunnels from the first communication device to the second communication device, the multiple tunnels including the first tunnel and the third tunnel, sent by the target communication device. In a specific embodiment, the third communication device receives a first route sent by the target communication device, the first route including the performance information of the multiple tunnels from the first communication device to the second communication device.

[0267] In an optional embodiment, the third communication device further receives a second tunnel identifier sent by the target communication device, where the second tunnel identifier identifies a second tunnel from the third communication device to the first communication device, where the head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device. In a specific embodiment, the third communication device receives a first route sent by the target communication device, where the first route includes the second tunnel identifier.

[0268] S804. The third communication device establishes an end-to-end tunnel Y from the third communication device to the second communication device according to the first tunnel identifier. The end-to-end tunnel Y includes the first tunnel and the second tunnel. The head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

[0269] In an optional embodiment, the third communication device determines, based on the first tunnel identifier and the performance information of the first tunnel, to establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel, and then the third communication device establishes an end-to-end tunnel Y based on the first tunnel identifier. In a specific embodiment, the third communication device determines, based on the first tunnel identifier, the performance information of the first tunnel, and the performance information of the third tunnel, to establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel. For example, the third communication device determines the first tunnel based on the performance information of the first tunnel and the performance information of the third tunnel (or filters out the first tunnel from the first tunnel and the third tunnel), and the third communication device establishes the end-to-end tunnel Y based on the first tunnel identifier. In a specific embodiment, the third communication device determines the first tunnel from the multiple tunnels from the first communication device to the second communication device based on the performance information of the multiple tunnels, and then establishes the end-to-end tunnel Y based on the first tunnel identifier that identifies the first tunnel. The implementation method of the third communication device determining the first tunnel based on the performance information of the first tunnel and the performance information of the third tunnel, and the implementation method of the third communication device determining the first tunnel based on the performance information of the multiple tunnels, can both be referred to the relevant description in S801 and are not repeated here.

[0270] In a specific embodiment, a third communication device establishes an end-to-end tunnel Y from the third communication device to the second communication device based on a first tunnel identifier and a second tunnel identifier. The second tunnel identifier identifies a second tunnel from the third communication device to the second communication device. For example, the third communication device establishes tunnel forwarding entry 1 based on the first tunnel identifier and the second tunnel identifier to establish end-to-end tunnel Y. Tunnel forwarding entry 1 includes information about end-to-end tunnel Y, which includes the first tunnel identifier and the second tunnel identifier. In the information about end-to-end tunnel Y, the first tunnel identifier is arranged after the second tunnel identifier, such that the first tunnel identified by the first tunnel identifier is arranged after the second tunnel identified by the second tunnel identifier. For example, the second tunnel is from the third communication device to the first communication device, the first tunnel is from the first communication device to the second communication device, and the end-to-end tunnel Y is from the third communication device to the first communication device to the second communication device. The information about end-to-end tunnel Y is the second tunnel identifier -> the first tunnel identifier. In an optional embodiment, the information about end-to-end tunnel Y is the next hop information of tunnel forwarding entry 1.

[0271] In a specific embodiment, the third communication device determines that the tail node of the second tunnel is the first communication device, and the third communication device determines that the head node of the first tunnel (the first route includes the identifier of the head node of the first tunnel) is the first communication device based on the first route. The third communication device determines to establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier and the second tunnel identifier based on the fact that the tail node of the second tunnel is the first communication device and the head node of the first tunnel is the first communication device. In addition, the third communication device determines to arrange the first tunnel identifier after the second tunnel identifier to arrange the first tunnel after the second tunnel to establish an end-to-end tunnel Y from the third communication device to the second communication device.

[0272] In an optional embodiment, the target communication device sends a first tunnel identifier and a second tunnel identifier to a third communication device via a first route. The third communication device obtains the first tunnel identifier and the second tunnel identifier from the first route, and then establishes an end-to-end tunnel Y from the third communication device to the second communication device based on the first tunnel identifier and the second tunnel identifier. In a specific embodiment, the third communication device obtains from the first route the second tunnel identifier of the second tunnel from the third communication device to the first communication device, multiple tunnel identifiers of multiple tunnels from the first communication device to the second communication device, and performance information of the multiple tunnels. The third communication device determines a first tunnel from the multiple tunnels based on the performance information of the multiple tunnels, and then establishes the end-to-end tunnel Y based on the second tunnel identifier and the first tunnel identifier identifying the first tunnel.

[0273] In summary, the technical solution provided by the embodiment of the present application is that, since the first communication device notifies the third communication device of the first tunnel identifier that identifies the first tunnel from the first communication device to the second communication device, the first communication device implements the function of providing the tunnel from the first communication device to the second communication device to the third communication device. Since the third communication device establishes an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier notified by the first communication device, the third communication device implements the establishment of an end-to-end tunnel from the third communication device to the second communication device. For example, the first communication device, the second communication device, and the first tunnel all belong to the first management domain, and the third communication device belongs to the second management domain. Thus, the embodiment of the present application implements the establishment of an end-to-end tunnel from a communication device in the second management domain to a communication device in the first management domain.

[0274] After the third communication device establishes an end-to-end tunnel Y from the third communication device to the second communication device, the third communication device can iterate the VPN route published by the second communication device to the end-to-end tunnel Y. In an optional embodiment, please refer to Figure 21, which shows a flowchart of another network interconnection method provided by an embodiment of the present application. Based on Figure 8, the method shown in Figure 21 also includes the following steps S805 to S806.

[0275] S805. The third communication device receives VPN route B, where the next hop address of VPN route B is the address of the second communication device.

[0276] VPN route B is a VPN route published by the second communication device, and includes a VPN SID assigned by the second communication device. VPN route B is published by the second communication device based on a VPN address family. For example, VPN route B is a VPNv4 route published by the second communication device based on a VPNv4 address family, a VPNv6 route published based on a VPNv6 address family, or an EVPN route published based on an EVPN address family. VPN route B can be the same VPN route as VPN route A described in the preceding embodiment. VPN route B can be forwarded by other communication devices to a third communication device, and these other communication devices do not modify the next hop address of VPN route B during the forwarding process.

[0277] The second communication device publishes VPN route B based on the learned private network route. In a specific embodiment, the second communication device receives the private network route published by the fourth communication device through the first interface; the second communication device assigns a VPN SID to the private network route; the second communication device binds the VPN SID to the first interface of the second communication device; the second communication device generates VPN route B based on the private network route; and the second communication device publishes VPN route B. For example, the fourth communication device belongs to the third management domain, and the first and third management domains are interconnected through the second communication device. For example, the second communication device is the ingress node of the first management domain, and the fourth communication device is the egress node of the third management domain.

[0278] S806. The third communication device iterates VPN route B to end-to-end tunnel Y according to the next hop address of VPN route B.

[0279] In a specific embodiment, the third communication device searches for a tunnel whose head node is the third communication device and whose tail node address matches the next-hop address of VPN route B. The third communication device can find end-to-end tunnel Y. The third communication device finding end-to-end tunnel Y means that the third communication device has found tunnel forwarding entry 1 established in S804. The third communication device records the VPN SID of VPN route B in tunnel forwarding entry 1 (for example, refer to this VPN SID as VPN SID1). In a specific embodiment, VPN SID1 is the destination address of tunnel forwarding entry 1, that is, it is a matching entry of tunnel forwarding entry 1. Tunnel forwarding entry 1 is shown in Table 4 below.

[0280] Table 4

[0281] The tunnel forwarding entry 1 shown in Table 4 is used for messages from the third communication device to the second communication device through the end-to-end tunnel Y.

[0282] After the third communication device establishes an end-to-end tunnel Y from the third communication device to the second communication device, the third communication device can send a message to the second communication device through the end-to-end tunnel Y. In an optional embodiment, please refer to Figure 22, which shows a flowchart of another network interconnection method provided by an embodiment of the present application. Based on the method shown in Figure 21, the method shown in Figure 22 also includes the following steps S807 to S809.

[0283] S807. The third communication device sends a first message to the second communication device through the end-to-end tunnel Y, where the first message includes a first tunnel identifier.

[0284] In an optional embodiment, the third communication device obtains information of the end-to-end tunnel Y; the third communication device generates a first message based on the information of the end-to-end tunnel Y, the destination address of the first message is the address of the second communication device, and the first message includes a first tunnel identifier; the third communication device sends the first message to the first communication device through the second tunnel included in the end-to-end tunnel Y based on the destination address of the first message.

[0285] In a specific embodiment, a third communication device receives an original message. The third communication device searches its forwarding table based on the destination address of the original message and determines that the destination address of the original message matches the destination address of tunnel forwarding entry 1 (e.g., VPN SID1). The third communication device then determines information about end-to-end tunnel Y based on tunnel forwarding entry 1. The third communication device performs tunnel encapsulation on the original message based on the information about end-to-end tunnel Y to obtain a first message. In a specific embodiment, the third communication device determines, based on the information about end-to-end tunnel Y, that end-to-end tunnel Y includes a second tunnel from the third communication device to the first communication device and a first tunnel from the first communication device to the second communication device. The third communication device encapsulates a first tunnel identifier identifying the first tunnel in the original message, and performs second tunnel encapsulation on the original message based on the second tunnel identifier identifying the second tunnel to obtain a first message. The first message includes encapsulation information for the first tunnel identifier and the second tunnel. In the first message, the tunnel information for the second tunnel is located outside the first tunnel identifier. For example, the third communication device sequentially encapsulates the first tunnel identifier and the tunnel information for the second tunnel in the original message to obtain the first message.

[0286] In a specific embodiment, the third communication device performs tunnel encapsulation on the original message according to tunnel forwarding entry 1 to obtain a first message. The first message includes VPN SID1, a first tunnel identifier, and encapsulation information for the second tunnel. In the first message, the first tunnel identifier is located outside VPN SID1, and the tunnel information for the second tunnel is located outside the first tunnel identifier. That is, VPN SID1, the first tunnel identifier, and the tunnel information for the second tunnel are sequentially arranged from the inside out. For example, the third communication device sequentially encapsulates VPN SID1, the first tunnel identifier, and the tunnel information for the second tunnel in the original message to obtain the first message.

[0287] In an optional embodiment, the second tunnel is an SD-WAN tunnel, and the encapsulation information of the second tunnel is SD-WAN tunnel information.

[0288] In an optional embodiment, the original message comes from a user device (eg, a host) accessing the second management domain.

[0289] S808. The first communication device receives the first message.

[0290] The first communication device is an intermediate node of the end-to-end tunnel Y, and the first communication device can receive a first message sent by the third communication device to the second communication device through the end-to-end tunnel Y.

[0291] In a specific embodiment, the first communication device receives a first message sent by the third communication device through the second tunnel included in the end-to-end tunnel Y.

[0292] S809. The first communication device forwards the first message to the second communication device according to the first tunnel identifier in the first message.

[0293] The first message received by the first communication device includes tunnel information and a first tunnel identifier of the second tunnel, and may also include VPN SID1. The first communication device decapsulates the tunnel information of the second tunnel in the first message to determine the first tunnel identifier in the first message. The first communication device determines the first tunnel based on the first tunnel identifier, and the first communication device forwards the first message to the second communication device through the first tunnel.

[0294] In an optional embodiment, the first message includes VPN SID1. After the second communication device receives the first message, the second communication device decapsulates the first tunnel identifier in the first message to determine VPN SID1 in the first message, and the second communication device forwards the first message based on VPN SID1. In a specific embodiment, VPN SID1 is bound to a first interface of the second communication device, the second communication device determines the first interface of the second communication device based on VPN SID1, and the second communication device forwards the first message to the fourth communication device via the first interface.

[0295] It should be noted that after the first communication device decapsulates the tunnel information of the second tunnel in the first message, the tunnel information of the second tunnel in the first message is stripped off. Therefore, the first message decapsulated by the first communication device does not include the tunnel information of the second tunnel. The first communication device forwards the first message to the second communication device according to the first tunnel identifier in the first message, which means: the first communication device forwards the decapsulated first message to the second communication device according to the first tunnel identifier in the decapsulated first message. After the second communication device decapsulates the first tunnel identifier in the first message, the first tunnel identifier in the first message is stripped off. Therefore, the first message decapsulated by the second communication device does not include the first tunnel identifier. The second communication device forwards the first message according to the VPN SID1 in the first message, which means: the second communication device forwards the decapsulated first message according to the VPN SID1 in the decapsulated first message. For the sake of simplicity of description, the embodiments of the present application are collectively referred to as the first message.

[0296] To sum up, the technical solution provided by the embodiment of the present application is that, since the third communication device can establish an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier notified by the first communication device, and send a message to the second communication device through the end-to-end tunnel, end-to-end communication from the third communication device to the second communication device can be realized.

[0297] In order to facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the embodiments of the present application are introduced below with four examples in conjunction with the accompanying drawings.

[0298] First example: Please refer to Figure 23, which shows a schematic diagram of a network interconnection method provided in an embodiment of the present application.

[0299] Network node 6 receives route Z published by network node 8 through interface 1. Network node 6 assigns VPN SID 1 to route Z and binds VPN SID 1 to interface 1 of network node 6. Network node 6 generates VPN route 1 (not shown in FIG. 23 ) and publishes VPN route 1. VPN route 1 includes VPN SID 1, and the next hop address of VPN route 1 is the address of network node 6.

[0300] After receiving VPN route 1, network node 1 determines tunnels 11-13 from network node 1 to network node 6 based on the next-hop address of VPN route 1. The head nodes of tunnels 11-13 are all network node 1, and the tail nodes of tunnels 11-13 are all network node 6. Network node 1 generates tunnel identifiers for tunnels 11-13. For example, network node 1 generates tunnel identifier 11 for tunnel 11, tunnel identifier 12 for tunnel 12, and tunnel identifier 13 for tunnel 13.

[0301] Network node 1 generates SD-WAN route 1, which includes tunnel identifiers 11 to 13 (SD-WAN route 1 may also include performance information of tunnels 11 to 13), identifiers of the head nodes of tunnels 11 to 13, and identifiers of the tail nodes of tunnels 11 to 13. For example, the local endpoint address of SD-WAN route 1 is the address of network node 1 (the identifier of the head node of tunnels 11 to 13), and the remote endpoint address of SD-WAN route 1 is the address of network node 6 (the identifier of the tail node of tunnels 11 to 13). Network node 1 sends SD-WAN route 1 to controller 10.

[0302] After the controller 10 receives SD-WAN route 1, the controller 10 obtains the tunnel identifiers 11 to 13 in SD-WAN route 1, and the controller 10 determines tunnel 11 among tunnels 11 to 13 as the first tunnel. The controller 10 generates SD-WAN route 2, which includes tunnel identifier 11, the identifier of the head node of tunnel 11, and the identifier of the tail node of tunnel 11. For example, the local endpoint address of SD-WAN route 2 is the address of network node 1 (the identifier of the head node of tunnel 11), and the remote endpoint address is the address of network node 6 (the identifier of the tail node of tunnels 11 to 13). The controller 10 sends SD-WAN route 2 to network node 7.

[0303] After network node 7 receives SD-WAN route 2, network node 7 obtains tunnel identifier 11 in SD-WAN route 2. Network node 7 determines tunnel 01 from network node 7 to network node 1. Network node 7 establishes an end-to-end tunnel from network node 7 to network node 6 based on tunnel identifier 11 and tunnel identifier 01 of tunnel 01 (for ease of description, this end-to-end tunnel is referred to as end-to-end tunnel 011). In a specific embodiment, network node 7 establishes tunnel forwarding entry 1 based on tunnel identifier 11 and tunnel identifier 01 to establish end-to-end tunnel 011. The next hop information of tunnel forwarding entry 1 is the information of end-to-end tunnel 011: tunnel identifier 01 -> tunnel identifier 11.

[0304] After receiving VPN route 1, network node 7 finds end-to-end tunnel 011 based on the next-hop address of VPN route 1. Network node 7 iterates VPN route 1 to end-to-end tunnel 011 and records VPN SID 1 in VPN route 1 in tunnel forwarding entry 1. The destination address of tunnel forwarding entry 1 is VPN SID 1.

[0305] After network node 7 receives a message whose destination address matches VPN SID1 in tunnel forwarding entry 1, it determines end-to-end tunnel 011 based on the next hop information in tunnel forwarding entry 1. Network node 7 encapsulates the message with tunnel information for end-to-end tunnel 011. Network node 7 forwards the message to network node 1 based on the tunnel information for tunnel 01 in the tunnel information for end-to-end tunnel 011. After receiving the message, network node 1 decapsulates the tunnel information for tunnel 01 in the message and, based on tunnel identifier 11 in the message, forwards the message to network node 6 through tunnel 11. After receiving the message, network node 6 decapsulates tunnel identifier 11 in the message and, based on VPN SID1 in the message, determines interface 1 of network node 6. It then forwards the message to network node 8 through interface 1.

[0306] Second example: Please refer to Figure 24, which shows a schematic diagram of another network interconnection method provided in an embodiment of the present application.

[0307] The process of the method shown in Figure 24 is basically the same as the process of the method shown in Figure 23, with the difference that: in the method shown in Figure 24, network node 1 sends tunnel identifiers 11 to 13 to controller 10 through BGP-LS routing. After controller 10 filters out tunnel 11 from tunnels 11 to 13, controller 10 sends tunnel identifier 11 to network node 1 through BGP label routing.

[0308] The BGP labeled route may be a BGP LU route, a BGP CT route, or a BGP CAR route.

[0309] Third example: Please refer to Figure 25, which shows a schematic diagram of another network interconnection method provided in an embodiment of the present application.

[0310] The process of the method shown in Figure 25 is basically the same as the process of the method shown in Figure 23, with the difference that: in the method shown in Figure 25, network node 1 sends tunnel identifiers 11 to 13 to controller 10 through BGP-LS routing. After controller 10 filters out tunnel 11 from tunnels 11 to 13, controller 10 sends tunnel identifier 11 to network node 1 through BGP-RPD routing, OMP routing or PCEP routing.

[0311] Fourth example: Please refer to Figure 26, which shows a schematic diagram of another network interconnection method provided in an embodiment of the present application.

[0312] The process of the method shown in Figure 26 is basically the same as the process of the method shown in Figure 23, with the difference that: in the method shown in Figure 26, network node 1 sends tunnel identifiers 11 to 13 to controller 10 through BGP-LS routing. After controller 10 filters out tunnel 11 from tunnels 11 to 13, controller 10 sends tunnel identifier 11 to network node 1 through BGP FS routing, OMP routing or PCEP routing.

[0313] It should be noted that the above four examples are explained by taking the example of the controller 10 determining the first tunnel (i.e., tunnel 11) among tunnels 11 to 13. In some embodiments, the network node 1 determines the first tunnel among tunnels 11 to 13, and the SD-WAN route or BGP-LS route sent by the network node 1 to the controller 10 includes the tunnel identifier of the first tunnel (e.g., tunnel 11), without including the tunnel identifiers of tunnels 12 to 13. In other embodiments, the network node 7 determines the first tunnel among tunnels 11 to 13, and the SD-WAN route or BGP-LS route sent by the network node 1 to the controller 10 includes the tunnel identifiers of tunnels 11 to 13, and the SD-WAN route, BGP label route, BGP FS route, BGP-RPD route, OMP route, or PCEP route sent by the controller 10 to the network node 7 includes the tunnel identifiers of tunnels 11 to 13.

[0314] In addition, the route used in the above embodiment to transmit the tunnel identifier between network node 1 and network node 7 is only an example of the embodiment of the present application. Other routes can also be used to transmit the tunnel identifier between network node 1 and network node 7, and the embodiment of the present application does not limit this.

[0315] In addition, S801 to S809 in the above method embodiment are only used as step numbers of the method embodiment of the present application, and are not used to limit the execution order of the steps. The order of the steps in the method embodiment of the present application can be adjusted appropriately, and the steps can also be increased or decreased according to the situation. For example, step S805 can be located before step S801. Any person skilled in the art who can easily think of a method of variation within the technical scope disclosed in this application should be included in the scope of protection of this application, so it will not be described in detail.

[0316] It should be noted that in the embodiments of the present application, a "tunnel from a first communication device to a second communication device" means that the tunnel's head node is the first communication device, and the tunnel's tail node is the second communication device. A "tunnel from a third communication device to a second communication device" means that the tunnel's head node is the third communication device, and the tunnel's tail node is the second communication device. Unless otherwise specified, other similar descriptions have the same meaning.

[0317] The above is an introduction to the method embodiments of the present application. The following describes the device embodiments of the present application, which are used to perform the method of the present application. For details not disclosed in the device embodiments, please refer to the method embodiments.

[0318] An embodiment of the present application provides a communication device, which includes at least one functional module, and the at least one functional module is used to execute all or part of the steps of the network interconnection method provided by the above-mentioned method embodiments (for example, the method embodiments shown in Figures 8, 21, and 22).

[0319] Please refer to Figure 27, which shows a schematic diagram of a communication device 2700 provided in an embodiment of the present application. Communication device 2700 can be the third communication device, the first communication device, or a control device (e.g., a controller) described in the above method embodiment. In communication device 2700, the at least one functional module includes a receiving module 2710, a processing module 2720, and a sending module 2730.

[0320] In one embodiment, the communication device 2700 is the third communication device described in the above method embodiment.

[0321] A receiving module 2710 is configured to receive a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from a first communication device to a second communication device, where the head node of the first tunnel is the first communication device and the tail node of the first tunnel is the second communication device;

[0322] Processing module 2720 is used to establish an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier. The end-to-end tunnel includes a first tunnel and a second tunnel. The head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

[0323] In a specific implementation, the processing module 2720 is configured to determine, based on the first tunnel identifier and the performance information of the first tunnel, to establish an end-to-end tunnel from the third communication device to the second communication device.

[0324] In a specific implementation, the receiving module 2710 is further configured to receive performance information of the first tunnel.

[0325] In a specific implementation, the performance information of the first tunnel includes at least one of available bandwidth, delay, jitter, or packet loss rate.

[0326] In a specific implementation, the processing module 2720 is configured to establish an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier and the second tunnel identifier, where the second tunnel identifier identifies the second tunnel.

[0327] In a specific implementation, the receiving module 2710 is further configured to receive a second tunnel identifier.

[0328] In a specific implementation, the receiving module 2710 is configured to receive a second tunnel identifier sent by the controller.

[0329] In a specific implementation, the receiving module 2710 is used to receive multiple tunnel identifiers, which include a first tunnel identifier and a third tunnel identifier, where the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device.

[0330] In a specific implementation, the receiving module 2710 is further configured to receive a VPN route whose next hop address is the address of the second communication device; the processing module 2720 is further configured to iterate the VPN route to the end-to-end tunnel according to the next hop address of the VPN route.

[0331] In a specific embodiment, the receiving module 2710 is configured to receive a first route, which includes a first tunnel identifier, an identifier of a head node of the first tunnel, and an identifier of an end node of the first tunnel. The first route may also include performance information of the first tunnel, a second tunnel identifier, and the like.

[0332] In a specific implementation manner, the first route includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP-RPD routing; OMP routing; PCEP routing.

[0333] In a specific implementation manner, the first route is a BGP FS route, an OMP route, or a PCEP route, and the first route includes a traffic control policy, which includes a first tunnel identifier; or, the first route is a BGP-RPD route, an OMP route, or a PCEP route, and the first route includes a routing control policy, which includes a first tunnel identifier; or, the first route is an SD-WAN route or a BGP-LS route, and the first route includes an MP_REACH_NLRI attribute, which includes a first tunnel identifier; or, the first route is a BGP label route, and the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier.

[0334] In a specific implementation manner, BGP label routing includes any one of BGP LU routing, BGP CT routing, and BGP CAR.

[0335] In a specific implementation, the first route is a BGP LU route or a BGP CT route, the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier; or, the first route is a BGP CAR route, the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes the first tunnel identifier.

[0336] In a specific implementation, the first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

[0337] In a specific implementation manner, the first tunnel includes any one of the following: an SR-MPLS tunnel; an SRv6TE tunnel; a GRE tunnel; an MPLS LDP LSP tunnel; a BGP LSP tunnel; or an RSVP-TELSP tunnel.

[0338] In a specific embodiment, the second tunnel includes an SD-WAN tunnel.

[0339] In a specific implementation, the sending module 2730 is configured to send a first message to the second communication device through the end-to-end tunnel, where the first message includes a first tunnel identifier.

[0340] In another embodiment: the communication device 2700 is the first communication device or control device (eg, a controller) described in the above method embodiment.

[0341] A processing module 2720 is configured to obtain a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from the first communication device to the second communication device, where the head node of the first tunnel is the first communication device and the tail node of the first tunnel is the second communication device;

[0342] The sending module 2730 is configured to send the first tunnel identifier to the third communication device.

[0343] In a specific implementation, the sending module 2730 is further configured to send the performance information of the first tunnel to the third communication device.

[0344] In a specific implementation, the performance information of the first tunnel includes at least one of available bandwidth, delay, jitter, or packet loss rate.

[0345] In a specific implementation, the sending module 2730 is further configured to send a second tunnel identifier to the third communication device, where the second tunnel identifier identifies a second tunnel from the third communication device to the first communication device, the head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

[0346] In a specific implementation, the processing module 2720 is used to: obtain multiple tunnel identifiers, the multiple tunnel identifiers including a first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device; determine the first tunnel based on the performance information of the first tunnel and the performance information of the third tunnel; obtain the first tunnel identifier that identifies the first tunnel.

[0347] In a specific implementation, the processing module 2720 is used to obtain multiple tunnel identifiers, which include a first tunnel identifier and a third tunnel identifier, where the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device; the sending module 2730 is used to send the multiple tunnel identifiers to the third communication device.

[0348] In a specific embodiment, the sending module 2730 is configured to send a first route to the third communication device, the first route including the first tunnel identifier, the identifier of the first tunnel's head node, and the identifier of the first tunnel's tail node. The first route may also include performance information of the first tunnel, the second tunnel identifier, and the like.

[0349] In a specific implementation manner, the first route includes any one of the following: SD-WAN routing; BGP-LS routing; BGP label routing; BGP FS routing; BGP-RPD routing; OMP routing; PCEP routing.

[0350] In a specific implementation manner, the first route is a BGP FS route, an OMP route, or a PCEP route, and the first route includes a traffic control policy, which includes a first tunnel identifier; or, the first route is a BGP-RPD route, an OMP route, or a PCEP route, and the first route includes a routing control policy, which includes a first tunnel identifier; or, the first route is an SD-WAN route or a BGP-LS route, and the first route includes an MP_REACH_NLRI attribute, which includes a first tunnel identifier; or, the first route is a BGP label route, and the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier.

[0351] In a specific implementation manner, BGP label routing includes any one of BGP LU routing, BGP CT routing, and BGP CAR.

[0352] In a specific implementation, the first route is a BGP LU route or a BGP CT route, the first route includes an MP_REACH_NLRI attribute or a BGP prefix-SID attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes a first tunnel identifier; or, the first route is a BGP CAR route, the first route includes an MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes the first tunnel identifier.

[0353] In a specific implementation, the receiving module 2710 is configured to receive a VPN route, the next hop address of which is the address of the second communication device; and the sending module 2730 is further configured to send the VPN route to the third communication device.

[0354] In a specific implementation, the first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

[0355] In a specific implementation manner, the first tunnel includes any one of the following: an SR-MPLS tunnel; an SRv6TE tunnel; a GRE tunnel; an MPLS LDP LSP tunnel; a BGP LSP tunnel; or an RSVP-TE LSP tunnel.

[0356] In a specific embodiment, the second tunnel includes an SD-WAN tunnel.

[0357] In a specific implementation, the communication device 2700 is a first communication device, the receiving module 2710 is further configured to receive a first message including a first tunnel identifier; and the sending module 2730 is further configured to forward the first message to a second communication device according to the first tunnel identifier.

[0358] The functional implementation of the above-mentioned receiving module 2710 can refer to steps S803, S805, and S808 in Figure 8, Figure 21 or Figure 22, the functional implementation of the above-mentioned processing module 2720 can refer to steps S801, S804, and S806 shown in Figure 8, Figure 21 or Figure 22, and the functional implementation of the above-mentioned sending module 2730 can refer to steps S802, S807, and S809 in Figure 8, Figure 21 or Figure 22, which will not be described in detail here.

[0359] The communication device provided in the embodiments of the present application can also be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The method provided in the above method embodiment can also be implemented using software. When the method provided in the above method embodiment is implemented using software, each functional module in the communication device can be a software module.

[0360] An embodiment of the present application provides a communication device, comprising a memory and a processor. The memory is used to store a computer program. The processor is used to execute the computer program stored in the memory to implement the network interconnection method provided by the method embodiment shown in Figure 8, Figure 21, or Figure 22. The communication device can be the third communication device, the first communication device, or a control device (e.g., a controller) described in the above method embodiment.

[0361] As an example, please refer to Figure 28, which shows a schematic diagram of a communication device 2800 provided in an embodiment of the present application. The communication device 2800 is a network node or a functional component in a network node, and the network node can be a switch or a router, etc. The communication device 2800 can implement the method embodiments shown in Figure 8, Figure 21 or Figure 22. As shown in Figure 28, the communication device 2800 includes a main control board 2810, an interface board 2830 and an interface board 2840. In the case where the communication device 2800 includes multiple interface boards (interface boards are also called line cards or service boards), the communication device 2800 also includes a switching network board (not shown in Figure 28), which is used to complete data exchange between the interface boards.

[0362] The main control board 2810 performs functions such as system management, device maintenance, and protocol processing. The interface boards 2830 and 2840 provide various service interfaces and implement service forwarding. These service interfaces include POS interfaces, Gigabit Ethernet (GE) interfaces, and Asynchronous Transfer Mode (ATM) interfaces. The main control board 2810 primarily houses three functional units: a system management and control unit, a system clock unit, and a system maintenance unit. The main control board 2810, interface boards 2830, and interface boards 2840 are interconnected via a system bus and the system backplane. The interface board 2830 includes one or more processors 2831. Processors 2831 control and manage the interface board 2830 and communicate with the central processing unit 2812 on the main control board 2810. The memory 2832 on the interface board 2830 stores forwarding table entries. The interface board 2830 also includes one or more network interfaces 2833 for transmitting and receiving. The main control board 2810 also includes a memory 2814, which is used to store system management information, protocols, etc., which is not limited in the embodiments of the present application. As shown in Figure 28, this embodiment includes multiple interface boards and adopts a distributed forwarding mechanism. Under this mechanism, the operations on the interface board 2840 are basically similar to those on the interface board 2830. For example, the interface board 2840 includes one or more network interfaces 2843 for implementing transmission and reception, the interface board 2840 includes a memory 2842 for storing forwarding table entries, and the interface board 2840 includes a processor 2841 for controlling and managing the interface board 2840 and communicating with the central processing unit 2812 on the main control board 2810.

[0363] The processor 2831 in interface board 2830 and / or the processor 2841 in interface board 2840 can be dedicated hardware or chips, such as a network processor or an application-specific integrated circuit, to implement the aforementioned functions. This implementation is commonly referred to as using dedicated hardware or chips for forwarding plane processing. In other embodiments, the processor 2831 in interface board 2830 and / or the processor 2841 in interface board 2840 can also be a general-purpose processor, such as a general-purpose central processing unit (CPU).

[0364] There may be one or more main control boards, which may include a primary main control board and a backup main control board. There may be one or more interface boards. The stronger the data processing capability of the communication device, the more interface boards are provided. In the case of multiple interface boards, these multiple interface boards can communicate with each other through one or more switching network boards. When there are multiple boards, they can jointly achieve load sharing and redundant backup. In a centralized forwarding architecture, the communication device may not require a switching network board, and the interface board is responsible for processing the service data of the entire system. In a distributed forwarding architecture, the communication device includes multiple interface boards, and data exchange between the multiple interface boards can be achieved through the switching network board, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a communication device with a distributed architecture are greater than those of a communication device with a centralized architecture. The specific architecture to be adopted depends on the network deployment scenario and is not limited here.

[0365] In a specific embodiment, the memory 2832 and / or the memory 2842 is 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, or 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 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 to these. The memory 2832 can exist independently and be connected to the processor 2831 via a communication bus, or it can be integrated with the processor 2831. The memory 2842 can exist independently and be connected to the processor 2841 via a communication bus, or it can be integrated with the processor 2841.

[0366] The memory 2832 is used to store program code and is controlled by the processor 2831 to execute some or all of the steps of the network interconnection method provided in the above embodiment. The processor 2831 is used to execute the program code stored in the memory 2832. The program code may include one or more software modules. These one or more software modules may be at least one functional module provided in the embodiment shown in Figure 27 above. The memory 2842 may also be used to store program code and is controlled by the processor 2841 to execute some or all of the steps of the network interconnection method provided in the above embodiment. Similarly, the memory 2814 may also be used to store program code and is controlled by the central processing unit 2812 to execute some or all of the steps of the network interconnection method provided in the above embodiment.

[0367] In a specific implementation, the network interface 2833 and the network interface 2843 are transceiver-type devices used for the communication device 2800 to communicate with other devices or networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), SD-WAN branch networks, backbone networks, etc.

[0368] As another example, please refer to Figure 29, which shows a schematic diagram of a communication device 2900 provided in an embodiment of the present application. Communication device 2900 can be a network node or a functional component within a network node, or a controller or a functional component within a controller. The network node can be a switch or router, etc. Communication device 2900 can implement the method embodiments shown in Figures 8, 21, or 22.

[0369] As shown in Figure 29, the communication device 2900 includes a processor 2902, a memory 2904, a communication interface 2906, and a bus 2908. The processor 2902, the memory 2904, and the communication interface 2906 are communicatively connected via the bus 2908. The connection method between the processor 2902, the memory 2904, and the communication interface 2906 shown in Figure 29 is merely exemplary. During implementation, the processor 2902, the memory 2904, and the communication interface 2906 may also be connected using a connection method other than the bus 2908, and this embodiment of the present application is not limited thereto.

[0370] In a specific embodiment, the memory 2904 is used to store a computer program 29042, which may include instructions and data. The memory 2904 may be various types of storage media, such as RAM, ROM, non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, and registers.

[0371] In a specific embodiment, the processor 2902 can be a general-purpose processor or a special-purpose processor. A general-purpose processor is a processor that performs specific steps and / or operations by reading and executing a computer program (e.g., computer program 29042) stored in a memory (e.g., memory 2904). The general-purpose processor may use data stored in the memory (e.g., memory 2904) during the execution of the above steps and / or operations. The stored computer program can be executed to implement the relevant functions of the aforementioned processing module 2720. The general-purpose processor can be a CPU. A special-purpose processor is a processor specially designed to perform specific steps and / or operations. The special-purpose processor can be a digital signal processor (DSP), ASIC, or FPGA, etc. The processor 2902 can also be a combination of multiple processors, such as a multi-core processor. The processor 2902 includes at least one circuit to perform all or part of the steps of the above-mentioned method embodiment.

[0372] The communication interface 2906 includes input / output (I / O) interfaces, physical interfaces, and logical interfaces, etc., which are used to interconnect devices within the communication device 2900, as well as interfaces for interconnecting the communication device 2900 with other devices (e.g., network devices, controllers). The physical interface can be a GE interface, which is used to interconnect the communication device 2900 with other devices. The logical interface is an interface within the communication device 2900, which is used to interconnect devices within the communication device 2900. The communication interface 2906 can be used for the communication device 2900 to communicate with other devices. The communication interface 2906 can implement the related functions of the aforementioned receiving module 2710 and sending module 2730. The communication interface 2906 can also include a transceiver for transceiver, which can also implement the related functions of the aforementioned receiving module 2710 and sending module 2730.

[0373] Bus 2908 is any type of communication bus used to interconnect processor 2902, memory 2904, and communication interface 2906. For example, bus 2908 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Bus 2908 can be classified as an address bus, a data bus, a control bus, etc. For ease of illustration, FIG29 shows only one thick line, but this does not indicate that there is only one bus or only one type of bus.

[0374] The above-mentioned components in the communication device 2900 can be respectively provided on independent chips, or at least partially or entirely provided on the same chip. Whether each component is provided independently on different chips or integrated on one or more chips often depends on the needs of the product design. The embodiments of the present application do not limit the specific implementation of the above-mentioned components.

[0375] The communication device 2900 shown in FIG29 is merely exemplary. During implementation, the communication device 2900 may further include other components, which are not listed here. The communication device 2900 shown in FIG29 implements network interconnection between different management domains by executing all or part of the steps of the network interconnection method provided in the above embodiment.

[0376] Based on the same inventive concept, an embodiment of the present application provides a communication system, which includes multiple communication devices, at least one of which is used to perform the method embodiment shown in Figure 8, Figure 21, or Figure 22, and the multiple communication devices include a communication device shown in any one of Figures 27 to 29. In a specific embodiment, the multiple communication devices include a first communication device, a second communication device, a third communication device, and a control device; the third communication device is used to perform steps S803 to S807 in the method embodiment shown in Figure 8, Figure 21, or Figure 22; the first communication device or the control device is used to perform steps S801 to S802 in the method embodiment shown in Figure 8, Figure 21, or Figure 22; and the first communication device is also used to perform steps S808 to S809 in the method embodiment shown in Figure 22.

[0377] In a specific embodiment, the communication system is shown in FIG6 or FIG7. The first communication device is the network node 1 or a communication entity in the network node 1, the second communication device is the network node 6 or a communication entity in the network node 6, the third communication device is the network node 7 or a communication entity in the network node 7, and the control device is the controller 10 or a communication entity in the controller 10.

[0378] The communication entity includes a chip, an interface board, a line card, or a software-based communication device, etc. For example, the communication device includes a chip, which includes a programmable logic circuit and / or program instructions, and when the chip is running, it implements all or part of the steps of the method provided in the above method embodiment.

[0379] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed (for example, executed by a communication device, one or more processors, etc.), it implements all or part of the steps of the method provided in the above method embodiment.

[0380] Based on the same inventive concept, an embodiment of the present application provides a computer program product, which includes a program or code. When the program or code is executed (for example, executed by a communication device, one or more processors, etc.), it implements all or part of the steps of the method provided in the above method embodiment.

[0381] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product, which includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium, or a semiconductor medium (e.g., a solid-state hard disk).

[0382] It should be understood that the term "at least one" in this application refers to one or more, and "a plurality of" refers to two or more. In this application, unless otherwise specified, the symbol " / " generally means or, for example, A / B can mean A or B. The term "and / or" in this application is merely a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, for the sake of clarity of description, this application uses words such as "first", "second", and "third" to distinguish between identical or similar items with basically the same functions and effects. Those skilled in the art will understand that words such as "first", "second", and "third" do not limit the quantity and execution order.

[0383] Different types of embodiments, such as method embodiments and device embodiments, provided in the embodiments of the present application can refer to each other. The order of operations of the method embodiments can be appropriately adjusted, and the operations can be increased or decreased in response to the situation. Any technician familiar with this technical field can easily think of different methods within the technical scope disclosed in this application, and they should all be covered within the scope of protection of this application, so they will not be repeated here.

[0384] In the corresponding embodiments provided in the present application, it should be understood that the disclosed devices and the like can be implemented through other structural methods. For example, the device embodiments described above are merely illustrative. For example, the division of modules is merely a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. On the other hand, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical or other forms. The modules described as separate components may or may not be physically separated, and the components described as modules may or may not be physical modules, and may be located in one place or distributed on multiple network nodes. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0385] The above description is merely an exemplary 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 replacements within the technical scope disclosed in this application, and these modifications or replacements should be included within 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.

Claims

1. A network interconnection method, characterized in that: The method comprises: receiving a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from a first communication device to a second communication device, where a head node of the first tunnel is the first communication device and a tail node of the first tunnel is the second communication device; An end-to-end tunnel is established from the third communication device to the second communication device according to the first tunnel identifier, wherein the end-to-end tunnel includes the first tunnel and the second tunnel, the head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

2. The method according to claim 1, characterized in that The establishing, according to the first tunnel identifier, an end-to-end tunnel from the third communication device to the second communication device includes: Determine, according to the first tunnel identifier and the performance information of the first tunnel, that the end-to-end tunnel be established based on the first tunnel.

3. The method according to claim 2, characterized in that The method further comprises: Receive performance information of the first tunnel.

4. The method according to any one of claims 1 to 3, characterized in that The establishing an end-to-end tunnel from the third communication device to the second communication device according to the first tunnel identifier includes: The end-to-end tunnel is established according to the first tunnel identifier and the second tunnel identifier, where the second tunnel identifier identifies the second tunnel.

5. The method according to claim 4, characterized in that The method further comprises: Receive the second tunnel identifier.

6. The method according to any one of claims 1 to 5, characterized in that The receiving the first tunnel identifier includes: Receive multiple tunnel identifiers, where the multiple tunnel identifiers include the first tunnel identifier and a third tunnel identifier, where the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, where the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: receiving a virtual private network (VPN) route, wherein the next hop address of the VPN route is the address of the second communication device; The VPN route is iterated to the end-to-end tunnel according to the next hop address of the VPN route.

8. The method according to any one of claims 1 to 7, characterized in that The receiving the first tunnel identifier includes: receiving a first route, where the first route includes the first tunnel identifier, an identifier of a head node of the first tunnel, and an identifier of an end node of the first tunnel.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: A first message is sent to the second communication device through the end-to-end tunnel, where the first message includes the first tunnel identifier.

10. The method according to any one of claims 1 to 9, characterized in that The method is performed by the third communication device.

11. A network interconnection method, characterized in that: The method comprises: Obtain a first tunnel identifier, where the first tunnel identifier identifies a first tunnel from a first communication device to a second communication device, where a head node of the first tunnel is the first communication device and a tail node of the first tunnel is the second communication device; The first tunnel identifier is sent to a third communication device so that the third communication device establishes an end-to-end tunnel from the third communication device to the second communication device based on the first tunnel identifier, wherein the end-to-end tunnel includes the first tunnel and the second tunnel, the head node of the second tunnel is the third communication device, and the tail node of the second tunnel is the first communication device.

12. The method according to claim 11, characterized in that The method further comprises: The performance information of the first tunnel is sent to the third communication device.

13. The method according to claim 11 or 12, characterized in that The method further comprises: A second tunnel identifier is sent to the third communication device, where the second tunnel identifier identifies the second tunnel.

14. The method according to any one of claims 11 to 13, characterized in that The obtaining of the first tunnel identifier includes: Acquire multiple tunnel identifiers, where the multiple tunnel identifiers include the first tunnel identifier and a third tunnel identifier, where the third tunnel identifier identifies a third tunnel from the first communication device to the second communication device, where the head node of the third tunnel is the first communication device, and the tail node of the third tunnel is the second communication device; determining the first tunnel according to the performance information of the first tunnel and the performance information of the third tunnel; Obtain the first tunnel identifier that identifies the first tunnel.

15. The method according to any one of claims 11 to 13, characterized in that The acquiring the first tunnel identifier includes: acquiring multiple tunnel identifiers, the multiple tunnel identifiers including the first tunnel identifier and a third tunnel identifier, the third tunnel identifier identifying a third tunnel from the first communication device to the second communication device, the head node of the third tunnel being the first communication device, and the tail node of the third tunnel being the second communication device; The sending the first tunnel identifier to the third communication device includes: sending the multiple tunnel identifiers to the third communication device.

16. The method according to any one of claims 11 to 15, characterized in that The sending the first tunnel identifier to the third communication device includes: A first route is sent to the third communication device, where the first route includes the first tunnel identifier, the identifier of the head node of the first tunnel, and the identifier of the tail node of the first tunnel.

17. The method according to any one of claims 11 to 16, characterized in that The method is performed by the first communication device, and the method further includes: receiving a first message, where the first message includes the first tunnel identifier; Forward the first message to the second communication device according to the first tunnel identifier.

18. The method according to any one of claims 11 to 16, characterized in that The method is executed by a controller or the first communication device.

19. The method according to any one of claims 2, 3, 12 and 14, characterized in that: The performance information includes at least one of available bandwidth, delay, jitter or packet loss rate.

20. The method according to claim 8 or 16, characterized in that The first route includes any one of the following: Software-defined wide area network (SD-WAN) routing; Border Gateway Protocol Link State BGP-LS routing; Border Gateway Protocol BGP label routing; Border Gateway Protocol Flow Specification BGP FS routing; Border Gateway Protocol routing policy distribution BGP-RPD routes; Overlay Management Protocol OMP routing; Path Computation Protocol (PCEP) routing.

21. The method according to any one of claims 8, 16 and 20, characterized in that: The first route is a BGP FS route, an OMP route, or a PCEP route, the first route includes a traffic control policy, and the traffic control policy includes the first tunnel identifier; or, The first route is a BGP-RPD route, an OMP route, or a PCEP route, the first route includes a route control policy, and the route control policy includes the first tunnel identifier; or The first route is an SD-WAN route or a BGP-LS route, the first route includes a multi-protocol reachable network layer reachability information MP_REACH_NLRI attribute, and the MP_REACH_NLRI attribute includes the first tunnel identifier; or, The first route is a BGP label route, and the first route includes an MP_REACH_NLRI attribute or a Border Gateway Protocol Prefix Segment Identifier (BGP prefix-SID) attribute, and the MP_REACH_NLRI attribute or the BGP prefix-SID attribute includes the first tunnel identifier.

22. The method according to any one of claims 1 to 21, characterized in that The second tunnel includes a software-defined wide area network SD-WAN tunnel.

23. The method according to any one of claims 1 to 22, characterized in that The first tunnel belongs to a first management domain, and the second tunnel belongs to a second management domain.

24. The method according to any one of claims 1 to 23, characterized in that The first tunnel includes any one of the following: Segment Routing Multi-Protocol Label Switching (SR-MPLS) tunnels; Segment Routing Internet Protocol Version 6 (SRv6) Traffic Engineering (TE) tunnels; Generic Routing Encapsulation (GRE) tunnel; Multi-protocol Label Switching (MPLS) Label Distribution Protocol (LDP) Label Switched Path (LSP) tunnel; Border Gateway Protocol BGP Label Switched Path LSP tunnel; Resource Reservation Protocol Traffic Engineering RSVP-TE Label Switched Path LSP tunnel.

25. A communication device, characterized in that: The communication device includes at least one functional module; The at least one functional module is configured to execute the method according to any one of claims 1 to 24.

26. A communication device, characterized in that: including memory and processor; The memory is used to store computer programs; The processor is configured to execute the computer program stored in the memory to implement the method according to any one of claims 1 to 24.

27. A communication system, characterized in that: including a plurality of communication devices; At least one communication device among the plurality of communication devices is configured to perform the method according to any one of claims 1 to 24.

28. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 24 is implemented.

29. A computer program product, characterized in that The method comprises a program or code, which implements the method according to any one of claims 1 to 24 when executed by a processor.

Images