Information notification method and apparatus

Abstract

Embodiments of the present application disclose an information notification method. The method can be applied to a first communication apparatus serving as a first station edge. The first communication apparatus can receive a first routing notified by a second communication apparatus, and on the basis of the first routing, acquire a first binding relationship between a second station edge and a first backbone network egress device. The first routing comprises the first backbone network egress device in a backbone network accessing the backbone network, and the first station edge accessing the backbone network by means of a first backbone network ingress device. Hence, by using the solution of the embodiments of the present application, the first station edge can acquire the first binding relationship, so as to subsequently orchestrate an end-to-end path from the first station edge to the second station edge on the basis of the first binding relationship, so that the end-to-end path obtained by means of orchestration better satisfies service requirements, thereby correspondingly improving the quality of service provided by service traffic transmitted by means of the end-to-end path.

Description

Information notification method and device

[0001] This application claims priority from the following patent applications, the entire contents of which are incorporated herein by reference.

[0002] 1. A Chinese patent application, application number 202310726065.3, entitled “Information Notification Method and Device,” was submitted to the State Intellectual Property Office on June 16, 2023;

[0003] 2. A Chinese patent application with application number 202310725238.X, titled “A Message Forwarding Method and Device,” was submitted to the China Patent Office on June 16, 2023;

[0004] 3. A Chinese patent application, application number 202310801479.8, entitled “Information Notification Method and Device,” submitted to the State Intellectual Property Office on June 30, 2023;

[0005] 4. The Chinese patent application submitted to the State Intellectual Property Office on June 30, 2023, with application number 202310802325.0 and invention name “A method and device for forwarding traffic”. Technical Field

[0006] The present application relates to the field of communications, and in particular to an information notification method and device. Background Art

[0007] With the development of communication technology, in some scenarios, business traffic needs to be transmitted across multiple network domains. For example, in scenarios such as enterprise multi-cloud integration, enterprise branch interconnection, and user access to related services, business traffic needs to be transmitted across edge access networks and backbone networks.

[0008] Currently, when business traffic needs to be transmitted across multiple network domains, the quality of service provided by the network for business traffic cannot meet business requirements. Therefore, a solution is urgently needed to solve the above problem.

[0009] Summary of the Invention

[0010] The embodiments of the present application provide an information notification method and apparatus, which can improve the quality of service provided to business traffic in scenarios where business traffic needs to be transmitted across multiple network domains.

[0011] In the first aspect, an embodiment of the present application provides an information notification method, which can be applied to a first communication device as a first site edge. The first communication device can receive a first route announced by a second communication device, wherein the first route includes a first backbone network egress device in a backbone network accessing the backbone network, and the first site edge accessing the backbone network through a first backbone network ingress device. After the first site edge receives the first route, it can obtain a first binding relationship between the second site edge and the first backbone network egress device based on the first route. The first site edge can use the first binding relationship to orchestrate an end-to-end path from the first site edge to the second site edge. It can be seen that, using the solution of the embodiment of the present application, the first site edge can obtain the first binding relationship between the second site edge and the first backbone network egress device of the second site edge accessing the backbone network, so as to subsequently orchestrate the end-to-end path from the first site edge to the second site edge based on the first binding relationship, thereby making the orchestrated end-to-end path more in line with business requirements, and accordingly, it can improve the quality of service provided by the business traffic transmitted through the end-to-end path.

[0012] In one possible implementation, after the first site edge obtains the first binding relationship, it can determine a first end-to-end path from the first site edge to the second site edge based on the first binding relationship, and the determined first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device. Thus, it can be seen that, using this solution, when arranging the end-to-end path, the first site edge can combine the information of the backbone network egress device bound to the opposite site edge (the second site edge), so that the arranged end-to-end path is more in line with business needs, and accordingly, it can improve the service quality provided by the business traffic transmitted through the end-to-end path.

[0013] In one possible implementation, the first information may include a first segment identifier (SID) assigned by the first backbone network egress device to the adjacency relationship between the first backbone network egress device and the second site edge, so that in the subsequent traffic forwarding stage, the message can be encapsulated based on the first SID, thereby performing traffic forwarding based on the first SID.

[0014] In a possible implementation, the first information may include the second SID of the first backbone network egress device, so that in a subsequent traffic forwarding phase, the message can be encapsulated based on the second SID, thereby performing traffic forwarding based on the second SID.

[0015] In one possible implementation, the first information may include the routing priority of the first backbone network egress device, so that the first site edge can arrange the end-to-end path from the first site edge to the second site edge in combination with the routing priority, or, the first site edge can determine the end-to-end path for transmitting business traffic from the end-to-end path from the first site edge to the second site edge in combination with the routing priority.

[0016] In one possible implementation, the first information may include the load sharing weight of the first backbone network exit device, so that the first site edge can determine the end-to-end path for transmitting business traffic from the end-to-end path from the first site edge to the second site edge in combination with the load sharing weight.

[0017] In one possible implementation, if the first site edge supports forwarding using Segment Routing Internet Protocol Version 6 (SRv6) technology, the first SID can be an SRv6 endpoint segment identifier (SRv6 END.X SID) with a cross-connection to a Layer 3 adjacency array, and the second SID can be an SRv6 endpoint segment identifier (SRv6 END.SID).

[0018] In a possible implementation, if the first site edge supports forwarding using Multi-Protocol Label Switching (MPLS) technology, the first SID may be an adjacency SID (adj-SID), and the second SID may be a node SID (node ​​SID).

[0019] In one possible implementation, the second communication device may be a second site edge. In this case, the first route may be a software-defined wide area network (SD-WAN) gateway information announcement route. The SD-WAN gateway information announcement route may be a route announced based on an SD-WAN address family or an SD-WAN sub-address family. In one example, the SD-WAN gateway information announcement route includes at least one type-length value (TLV), and the at least one TLV carries the first information.

[0020] In one possible implementation, the at least one TLV included in the SD-WAN gateway information announcement route may include a first TLV, and the first TLV is used to carry the first information. In a specific example, when the first information includes the first SID and / or the second SID, the value field of the first TLV is used to carry the first SID and / or the second SID in the first information. When the first information also includes the aforementioned routing priority, the first TLV may also include a priority sub-TLV for carrying the routing priority. When the first information also includes the aforementioned load sharing weight, the first TLV also includes a weight sub-TLV for carrying the load sharing weight.

[0021] In one possible implementation, the second communication device is the second site edge, and the first route is a virtual private network (VPN) route. In this case, the second site edge can notify the first site edge of the first information via the VPN route, thereby simultaneously notifying the VPN route and the first information.

[0022] In a possible implementation, the first information may be carried by a BGP path attribute in a VPN route. In a specific example, the first information may be carried by a first metadata path attribute in the VPN route.

[0023] In one possible implementation, the first route may also include service intent information. The service intent is used to indicate service intent (or service demand). The second communication device notifies the first site edge of the service intent information via the first route, enabling the communication device forwarding service traffic to forward the traffic in conjunction with the service intent information during the traffic forwarding phase, thereby satisfying the service intent.

[0024] In one possible implementation, the service intent information may include one or more information that can indicate the service intent. In one example, the service intent information may include quality of service parameters, including but not limited to one or more parameters such as latency, packet loss, jitter, bandwidth utilization, and bit error rate. In another example, the service intent parameters may include gateway constraint information that must be satisfied by the end-to-end path from the first site edge to the second site edge, including but not limited to gateways that need to be passed through and / or gateways that need to be detoured.

[0025] In one possible implementation, the business intent information can be carried by a BGP path attribute in the first route. In a specific example, the business intent information can be carried by a second Metadata Path Attribute in the first route. When the first route is a VPN route, the second Metadata Path Attribute and the aforementioned first Metadata Path Attribute can be the same Metadata Path Attribute. In this case, the first information and the business intent information can be carried using one Metadata Path Attribute. Of course, the second Metadata Path Attribute and the aforementioned first Metadata Path Attribute can also be different Metadata Path Attributes.

[0026] In one possible implementation, the second communication device is a first backbone network egress device. In this case, the first backbone network egress device may advertise the first route to the first site edge via the first backbone network ingress device. Accordingly, the first site edge may receive the first route advertised by the first backbone network egress device via the first backbone network ingress device.

[0027] In one possible implementation, the first route announced by the first backbone network egress device to the first site edge may be a route automatically discovered by the first SD-WAN gateway. The first SD-WAN gateway automatically discovered route may be a route announced based on an SD-WAN address family or an SD-WAN sub-address family.

[0028] In one possible implementation, when the second site edge is multi-homed to the first backbone network exit device and the second backbone network exit device, the first site edge can also receive a second route announced by a third communication device, where the second route includes second information of the second backbone network exit device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network exit device; after the first site edge receives the second route, it can obtain a second binding relationship between the second site edge and the second backbone network exit device according to the second route, so as to subsequently determine a second end-to-end path from the first site edge to the second site edge based on the second binding relationship.

[0029] In one possible implementation, the first site edge may also determine the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device, respectively, so as to subsequently determine the forwarding path of the service traffic based on the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device, respectively. As an example, the first site edge may determine the routing priority of the first backbone network egress device based on its own configured routing policy or in combination with the load condition of the first backbone network egress device. As another example, the first site edge may determine the routing priority of the second backbone network egress device based on its own configured routing policy or in combination with the load condition of the second backbone network egress device.

[0030] In one possible implementation, the first site edge may also determine the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device, respectively, so as to subsequently determine the forwarding path of the service traffic based on the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device, respectively. As an example, the first site edge may determine the load sharing weight of the first backbone network egress device, for example, based on its own configured load sharing strategy or in combination with the load condition of the first backbone network egress device. As another example, the first site edge may determine the load sharing weight of the second backbone network egress device, for example, based on its own configured load sharing strategy or in combination with the load condition of the second backbone network egress device.

[0031] In one possible implementation, after the first site edge obtains the second binding relationship, it can determine the first end-to-end path from the first site edge to the second site edge based on the second binding relationship, and the determined second end-to-end path passes through the first backbone network entry device and the second backbone network exit device. It can be seen that, using this solution, when arranging the end-to-end path, the first site edge can combine the information of the backbone network exit device bound to the opposite site edge (the second site edge), so that the arranged end-to-end path is more in line with business needs, and accordingly, it can improve the service quality provided by the business traffic transmitted through the end-to-end path.

[0032] In one possible implementation, the first site edge may also receive a third route sent by the first backbone network access device. The third route is used to notify the first backbone network access device of third information. After receiving the third route, the first site edge can obtain a third binding relationship between the first site edge and the first backbone network access device based on the third route. Thus, using this solution, the first site edge can determine its corresponding gateway based on the received third route, eliminating the need to manually configure the corresponding gateway on the first site edge.

[0033] In one possible implementation, the third route is a route automatically discovered by the second SD-WAN gateway. In this case, the first site edge can automatically discover the route through the second SD-WAN gateway to determine the third information of the gateway for accessing the backbone network (i.e., the first backbone network entry device). The route automatically discovered by the second SD-WAN gateway can be a route advertised based on the SD-WAN address family or SD-WAN sub-address family.

[0034] In one possible implementation, the third route is a Border Gateway Protocol Link State (BGP LS) route. In this case, the first site edge can determine the third information of its gateway for accessing the backbone network (i.e., the first backbone network entry device) through BGP LS routing. The BGP LS route can be a route based on a BGP LS address family advertisement.

[0035] In one possible implementation, the third information may include a third SID assigned by the first backbone network entry device to the adjacency relationship between the first backbone network entry device and the first site edge, so that in the subsequent traffic forwarding stage, the message is encapsulated based on the third SID, thereby using the third SID for traffic forwarding.

[0036] In a possible implementation, the third information may include the fourth SID of the first backbone network ingress device, so that in a subsequent traffic forwarding stage, the message is encapsulated based on the third SID, thereby using the third SID for traffic forwarding.

[0037] In a possible implementation, if the first site edge supports forwarding using the SRv6 technology, the third SID may be an SRv6END.X SID, and the fourth SID may be an SRv6END.SID.

[0038] In a possible implementation, if the first site edge supports forwarding using the MPLS technology, the third SID may be an adj-SID, and the fourth SID may be a node SID.

[0039] In a possible implementation, the third route also includes intermediate gateway information, and the intermediate gateway information indicates at least one intermediate gateway between the backbone network entry device in the backbone network and the exit device in the backbone network, so that the first site edge can perform path orchestration based on the intermediate gateway. In one example, the first site edge can determine the gateway constraints that the end-to-end path needs to follow based on business requirements and the intermediate gateway. The gateway constraints mentioned here include gateways that need to be passed through and / or gateways that need to be bypassed. In a specific example, when the first site edge performs path orchestration based on business requirements, it can determine the gateways that the end-to-end path needs to pass through and / or the gateways that need to be bypassed from the intermediate gateways, so that the determined end-to-end path meets business requirements.

[0040] In one possible implementation, the first site edge can also receive a first service message. After receiving the first service message, the first site edge can encapsulate the path information of the first end-to-end path in the outer layer of the first service message to obtain a second service message. The ingress endpoint of the first end-to-end path is the first site edge, and the egress endpoint of the first end-to-end path is the second site edge. The path information of the first end-to-end path includes: fourth information identifying a first backbone network ingress device in the backbone network, and fifth information identifying a first backbone network egress device in the backbone network. The first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device. After receiving the second service message, the first site edge can forward the second service message through the first end-to-end path. Thus, using this solution, the site edge can orchestrate the first end-to-end path across the backbone network, eliminating the need for devices in the backbone network to determine the transmission path based on service configuration. This eliminates the need for the backbone network to be aware of the service, thereby improving the forwarding efficiency of service traffic. Moreover, since the backbone network does not need to be aware of the service, there is no need to perform service-related configuration on the equipment in the backbone network, thereby improving the efficiency of service activation and, accordingly, the scalability of the backbone network.

[0041] In one possible implementation, the first end-to-end path may be pre-arranged by the first site edge. In a specific example, the first site edge may arrange the first end-to-end path before receiving the first service message. In a specific example, the first service message is used to carry a virtual private network (VPN) service. For this purpose, the first site edge may, based on the VPN service, combine the first backbone network entry device and the first backbone network exit device as needed to arrange the first end-to-end path from the first site edge to the second site edge. As an example, the first site edge may arrange an end-to-end path for the VPN route after receiving the VPN route including the destination prefix announced by the second site edge. In a specific example, the first site edge may arrange the first end-to-end path for the VPN route based on the binding relationship between the first site edge and the first backbone network entry device, and the binding relationship between the second site edge and the first backbone network exit device.

[0042] In one possible implementation, the second business message may also include business intent information. In this way, after the first site edge sends the second business message, the forwarding device that receives the second business message can select a corresponding path for forwarding based on the business intent information when further forwarding the second business message, so that the business intent is met and, accordingly, the service quality provided to the business is improved.

[0043] In one possible implementation, the second service message may include a metadata field, and the service intent information is carried in the metadata field. A forwarding device that receives the second service message may parse the metadata field to obtain the service intent information, so as to further select a corresponding path for forwarding based on the service intent information, thereby satisfying the service intent and, accordingly, improving the quality of service provided to the service.

[0044] In one possible implementation, the first site edge may first determine the path information of the first end-to-end path before encapsulating the first service message using the path information of the first end-to-end path. In a specific example, the first site edge may determine, based on the destination address of the first service message, that the next hop for forwarding the first service message is the second site edge, and further, iterate a first segment routing policy (SR policy) based on the Internet Protocol (IP) address of the second site edge to obtain the path information of the first end-to-end path.

[0045] In one possible implementation, the first SR policy may be an Internet Protocol Version 6 Segment Routing (SRv6) policy. In this case, the first end-to-end path may be an SRv6 tunnel. Accordingly, the second service packet includes an IPv6 header and a segment routing header (SRH). The fourth and fifth information may be carried by the SRH. Furthermore, the destination address of the IPv6 header points to the first backbone network ingress device, so that the first site edge forwards the second service packet to the first backbone network ingress device based on the destination address of the IPv6 header.

[0046] In one possible implementation, when the first SR policy is an SRv6 policy, the fourth information may be the first end segment identifier (END.SID) 1 of the first backbone network ingress device, and the fifth information may be the second end segment identifier END.SID2 of the first backbone network egress device. In addition, the SRH also includes the IPv6 address of the second site edge. In this case, the SRH may indicate the path from the first backbone network ingress device to the second site edge.

[0047] In one possible implementation, when the first SR policy is an SRv6 policy, the fourth information is the END.SID1 of the first backbone network ingress device, and the fifth information is the endpoint segment identifier (END.X SID) assigned by the first backbone network egress device for the adjacency between the first backbone network egress device and the second site edge, with a cross-connection to the Layer 3 adjacency array. In this case, the SRH may also indicate the path from the first backbone network ingress device to the second site edge.

[0048] In one possible implementation, the END.SID1 can be used to indicate a new message forwarding operation. In this case, the first backbone network ingress device can determine how to forward the second service message based on the END.SID1 without combining VPN information to determine how to forward the second service message.

[0049] In a specific example, the operation associated with END.SID1 may be: matching the overlying SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of END.SID1 in the SRH. In another specific example, when the second service message includes service intent information, the operation associated with END.SID1 may be: matching the overlying SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of END.SID1 in the SRH and the service intent information.

[0050] In one possible implementation, the aforementioned first SR policy may be an MPLS segment routing traffic engineering (SR-TE) policy. For this case, the first end-to-end path is an MPLS SR-TE policy. Accordingly, the second service message includes an MPLS label stack, and the aforementioned fourth information and fifth information are carried by the MPLS label stack. For this case, the fourth information is the first node SID of the first backbone network ingress device, and the fifth information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier (adj-SID) assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0051] In one possible implementation, the first node SID can be used to indicate a new message forwarding operation. In this case, the first backbone network ingress device can determine how to forward the second service message based on the first node SID without combining VPN information to determine how to forward the second service message.

[0052] In a specific example, the operation of associating the first node SID may be: matching the upper layer (overly) SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the MPLS label stack. In another specific example, when the second service message includes service intent information, the operation of associating the first node SID may be: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the MPLS label stack and the service intent information.

[0053] In one possible implementation, the first end-to-end path is a tunnel encapsulated based on the Generic Network Virtualization Encapsulation (GENEVE) protocol. In this case, the first site edge can use GENEVE encapsulation when encapsulating the path information of the first end-to-end path in the outer layer of the first service message. In other words, the second service message uses GENEVE encapsulation. When the first end-to-end path is an SRv6 tunnel, the second service message can use SRv6 in GENEVE encapsulation. When the first end-to-end path is an MPLS SR-TE policy, the second service message can use MPLS in GENEVE encapsulation.

[0054] In one possible implementation, the first end-to-end path is a tunnel encapsulated based on the generic routing encapsulation (GRE) protocol. In this case, when the first site edge encapsulates the path information of the first end-to-end path in the outer layer of the first service message, GRE encapsulation can be used. In other words, the second service message is encapsulated using GRE. When the first end-to-end path is an SRv6 tunnel, the second service message can be encapsulated using SRv6 over GRE. When the first end-to-end path is an MPLS SR-TE policy, the second service message can be encapsulated using MPLS over GRE.

[0055] In one possible implementation, if the second service message is encapsulated using SRv6 over GRE, the second service message includes: an outer IP header, a User Datagram Protocol (UDP) header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation, and a payload, wherein the payload includes the first service message, and the inner GRE encapsulation includes a VPN identifier (VNI) of the VPN service carried by the first service message. The VPN identifier is carried in the inner GRE encapsulation. When the second service message is transmitted in the backbone network, the devices in the backbone network do not parse the VPN identifier, that is, the backbone network is not aware of the VPN.

[0056] In one possible implementation, the first site edge can also receive a third service message and encapsulate path information of a third end-to-end path in the outer layer of the third service message to obtain a fourth service message; wherein the path information of the third end-to-end path includes sixth information identifying a second backbone network ingress device in the backbone network and seventh information identifying a second backbone network egress device in the backbone network, the ingress endpoint of the third end-to-end path is the first site edge, the egress endpoint of the third end-to-end path is the second site edge, the third end-to-end path passes through the second backbone network ingress device and the second backbone network egress device, the first site edge is multi-homed to the first backbone network ingress device and the second backbone network ingress device, and the second site edge is multi-homed to the first backbone network egress device and the second backbone network egress device; the first site edge sends the fourth service message via the third end-to-end path. Thus, using this solution, the site edge can orchestrate a third end-to-end path across the backbone network, without the need for devices in the backbone network to determine the transmission path based on service configuration, thereby eliminating the need for the backbone network to perceive the service, thereby improving the forwarding efficiency of service traffic. Moreover, since the backbone network does not need to be aware of the service, there is no need to perform service-related configuration on the equipment in the backbone network, thereby improving the efficiency of service activation and, accordingly, the scalability of the backbone network.

[0057] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network (SD-WAN) tunnel or the Internet.

[0058] In the second aspect, an embodiment of the present application provides an information notification method that can be applied to a second communication device. The second communication device can obtain a first route, wherein the first route includes first information of a first backbone network exit device in a backbone network and an identifier of a second site edge, and the second site edge accesses the backbone network through the first backbone network exit device. After the second communication device obtains the first route, it can notify the first route to the first site edge, wherein the first site edge accesses the backbone network through the first backbone network entry device. After notifying the first route to the first site edge, the first site edge can obtain a first binding relationship between the second site edge and the first backbone network exit device through which the second site edge accesses the backbone network, so as to subsequently orchestrate an end-to-end path from the first site edge to the second site edge based on the first binding relationship, thereby making the orchestrated end-to-end path more in line with business requirements, and accordingly, being able to improve the quality of service provided by the business traffic transmitted through the end-to-end path.

[0059] In one possible implementation, the first information includes one or more of the following: a first segment identifier SID assigned by the first backbone network egress device to the adjacency relationship between the first backbone network egress device and the second site edge; a second SID of the first backbone network egress device; a routing priority of the first backbone network egress device; and a load sharing weight of the first backbone network egress device.

[0060] In one possible implementation, the first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.X SID that is cross-connected to a Layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.SID; or, the first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

[0061] In one possible implementation, the second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

[0062] In one possible implementation, the SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, and the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

[0063] In a possible implementation, the second communication device is the second site edge, and the first route includes a virtual private network VPN route.

[0064] In a possible implementation, the VPN route includes a first metadata path attribute, and the first metadata path attribute carries the first information.

[0065] In a possible implementation manner, the first route further includes: service intent information.

[0066] In one possible implementation, the service intent information includes one or more of the following: a gateway through which the service traffic needs to pass, a gateway that the service traffic needs to bypass, and quality of service parameters that need to be met when transmitting the service traffic.

[0067] In a possible implementation, the first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the service intent information.

[0068] In a possible implementation, the second communication device is the first backbone network egress device, and the notifying the first route to the first site edge includes: notifying the first route to the first site edge through the first backbone network ingress device.

[0069] In one possible implementation, the first route includes: the first SD-WAN gateway automatically discovers the route.

[0070] In one possible implementation, the method further includes: notifying the first site edge of a second route, the second route including second information of a second backbone network exit device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network exit device.

[0071] In one possible implementation, the second site edge can also receive a third route sent by the first backbone network egress device, where the third route is used to notify the first backbone network egress device of third information. After receiving the third route, the second site edge can obtain the first binding relationship between the second site edge and the first backbone network egress device based on the third route. Thus, using this solution, the second site edge can determine its corresponding gateway based on the received third route, eliminating the need to manually configure its corresponding gateway on the first site edge.

[0072] In a possible implementation, the third information includes: a third SID allocated by the first backbone network egress device for the adjacency relationship between the first backbone network egress device and the second site edge, and / or a fourth SID of the first backbone network egress device.

[0073] In one possible implementation, if the second site edge is multi-homed to the first backbone network exit device and the second backbone network exit device, the second site edge can also receive a fourth route sent by the second backbone network exit device, and the fourth route is used to notify the fourth information of the second backbone network exit device; according to the fourth route, the second binding relationship between the second site edge and the second backbone network exit device is obtained.

[0074] In one possible implementation, the second site edge can also determine the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or determine the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

[0075] In one possible implementation, the third route is a route automatically discovered by the second SD-WAN gateway.

[0076] In a possible implementation, the third route is a BGP link state LS route, and the BGP LS route includes a second TLV, where the second TLV indicates that the third route is used to notify third information of the first backbone network egress device.

[0077] In one possible implementation, the second TLV is a role-advertising TLV, which indicates that the role of the first backbone network egress device is a gateway. The second site edge can parse the role TLV to determine that the device advertising the third route is its own gateway, thereby obtaining a first binding relationship between the second site edge and the first backbone network egress device.

[0078] In a possible implementation, the third route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device in the backbone network and the first backbone network egress device.

[0079] In a possible implementation, the third route includes a third Metadata Path Attribute, and the third Metadata Path Attribute carries the intermediate gateway information.

[0080] In one possible implementation, after receiving the intermediate gateway information, the second-site edge may determine, based on the intermediate gateway information, gateway constraint information in the service intent information, where the gateway constraint information indicates gateway constraint conditions that must be followed to determine a path to the second-site edge. As an example, after determining the gateway constraint information, the second-site edge may notify the first-site edge of the gateway constraint information so that, during the forwarding phase, the service traffic transmitted from the first-site edge to the second-site edge can be forwarded by a forwarding device in conjunction with the gateway constraint information.

[0081] In a possible implementation, the gateway constraint condition includes: a gateway that needs to be passed through, and / or a gateway that needs to be detoured.

[0082] In a third aspect, an embodiment of the present application provides an information notification method, which can be applied to a first backbone network entry device in a backbone network, wherein the first backbone network entry device can receive a first route announced by a first backbone network exit device in the backbone network, and notify the first route to a first site edge. The first route includes information about the first backbone network exit device and an identifier of a second site edge, the second site edge accesses the backbone network through the first backbone network exit device, and the first site edge accesses the backbone network through the first backbone network entry device. After notifying the first route to the first site edge, the first site edge can obtain a first binding relationship between the second site edge and the first backbone network exit device through which the second site edge accesses the backbone network, so as to subsequently orchestrate an end-to-end path from the first site edge to the second site edge based on the first binding relationship, thereby making the orchestrated end-to-end path more in line with business requirements, and accordingly, being able to improve the quality of service provided by the business traffic transmitted through the end-to-end path.

[0083] In one possible implementation, the first backbone network device may also receive a second service packet from a first site edge. The payload of the second service packet includes the first service packet. The outer layer of the first service packet encapsulates path information of an end-to-end path between the first site edge and the second site edge. The path information of the end-to-end path includes: first information identifying the first backbone network ingress device and second information identifying the first backbone network egress device in the backbone network. The ingress endpoint of the end-to-end path is the first site edge, and the egress endpoint of the end-to-end path is the second site edge. The end-to-end path passes through the first backbone network ingress device and the first backbone network egress device. The first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device. After receiving the second service packet, the first backbone network ingress device may process the second service packet based on the first information to obtain a third service packet, and send the third service packet to the first backbone network egress device to forward the service traffic. As can be seen, using this solution, the first end-to-end path for transmitting the service is determined by the first site edge, and the second service message received by the first backbone network entry device includes path information for the first end-to-end path. The first backbone network entry device does not need to determine the transmission path based on the service configuration, eliminating the need for the backbone network to be aware of the service, thereby improving the forwarding efficiency of service traffic. Furthermore, since the backbone network does not need to be aware of the service, there is no need to perform service-related configuration on the backbone network devices, thereby improving the efficiency of service provisioning and, accordingly, the scalability of the backbone network.

[0084] In a possible implementation, the second service message further includes service intent information.

[0085] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0086] In one possible implementation, the end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

[0087] In a possible implementation, the first information is the first endpoint segment identifier END.SID1 allocated by the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 allocated by the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

[0088] In a possible implementation, the first information is a first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the second information is an endpoint segment identifier END.X SID allocated by the first backbone network device egress device for an adjacency relationship between the first backbone network device egress device and the second site edge, with a cross-connection to a Layer 3 adjacency relationship array.

[0089] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH.

[0090] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the END.SID1 in the SRH and the service intent information.

[0091] In one possible implementation, when the first information is END.SID1, the first backbone network ingress device 1 processes the second service message according to the first information. In a specific implementation, the first overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device can be matched according to the next-hop SID of END.SID1 in the SRH, and the second service message can be encapsulated using the first overly SRv6 policy to obtain the third service message. Specifically, the first backbone network ingress device can insert a new SRH based on the second service message, and the new SRH carries the path information of the first overly SRv6 policy.

[0092] In one possible implementation, when the first information is END.SID1, if the second service message includes service intent information, the first backbone network entry device 1 processes the second service message according to the first information. In a specific implementation, the second overly SRv6 policy between the first backbone network entry device and the first backbone network exit device can be matched according to the next-hop SID of the END.SID1 in the SRH and the service intent information, and the second service message is encapsulated using the second overly SRv6 Policy to obtain the third service message. Specifically, the first backbone network entry device can insert a new SRH based on the second service message, and the new SRH carries the path information of the second overly SRv6 policy. In addition, the first backbone network entry device can also strip the service intent information from the second service message to obtain the third service message.

[0093] In one possible implementation, the end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0094] In a possible implementation, the operation of associating the first node SID includes: matching an upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the label stack.

[0095] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy from the first backbone network ingress device to the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0096] In one possible implementation, when the first information is the first node SID, the first backbone network ingress device 1 processes the second service message according to the first information. In a specific implementation, the first overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device can be matched according to the next-hop SID of the first node SID in the MPLS label stack. The first overly SR-MPLS TE policy is further used to encapsulate the second service message to obtain the third service message. For example, the first backbone network ingress device can replace SID1 and SID2 in the MPLS label stack with the first overly SR-MPLS TE policy to obtain the third service message.

[0097] In one possible implementation, when the first information is the first node SID, if the second service message includes service intent information, the first backbone network ingress device 1 processes the second service message according to the first information. In a specific implementation, the second overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device can be matched based on the next-hop SID of the first node SID in the MPLS label stack and the service intent information, and the second service message is encapsulated using the second overly SR-MPLS TE policy to obtain the third service message. For example, the first backbone network ingress device can replace SID1 and SID2 in the MPLS label stack with the second overly SR-MPLS TE policy to obtain the third service message.

[0098] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0099] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0100] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0101] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0102] In a fourth aspect, an embodiment of the present application provides a route announcement method, which is applied to a site edge, and the method includes: receiving a first route sent by a first backbone network edge device, the first route being used to announce first information of the first backbone network edge device, and the site edge accessing the backbone network through the first backbone network edge device; obtaining a first binding relationship between the site edge and the first backbone network edge device according to the first route. It can be seen that, by using this solution, the site edge can determine its own corresponding gateway through the received first route, without the need to manually configure its corresponding gateway on the site edge. The first backbone network edge device mentioned here can be a first backbone network egress device or a first backbone network ingress device.

[0103] In a possible implementation, the first information includes: a first SID allocated by the first backbone network edge device for an adjacency relationship between the first backbone network edge device and the site edge, and / or a second SID of the first backbone network edge device.

[0104] In one possible implementation, the method further includes: receiving a second route sent by a second backbone network edge device, where the second route is used to notify the second information of the second backbone network edge device, and the site edge accesses the backbone network through the second backbone network edge device; and obtaining a second binding relationship between the site edge and the second backbone network edge device according to the second route.

[0105] In one possible implementation, the method further includes: determining the routing priorities corresponding to the first backbone network edge device and the second backbone network edge device respectively; and / or determining the load sharing weights corresponding to the first backbone network edge device and the second backbone network edge device respectively.

[0106] In one possible implementation, the first route is an SD-WAN gateway automatic discovery route.

[0107] In a possible implementation, the first route is a BGP link state LS route, and the BGP LS route includes a TLV, where the TLV indicates that the first route is used to notify the first information of the first backbone network edge device.

[0108] In a possible implementation manner, the TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the backbone network edge device is a gateway.

[0109] In a possible implementation, the first route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device and a backbone network egress device in the backbone network.

[0110] In a possible implementation manner, the first route includes a Metadata Path Attribute, and the Metadata Path Attribute carries the intermediate gateway information.

[0111] In a possible implementation, the method further includes: determining gateway constraint information in the service intent information based on the intermediate gateway information, where the gateway constraint information indicates gateway constraint conditions that need to be followed to determine a path to reach the site edge.

[0112] In a possible implementation, the gateway constraint condition includes: a gateway that needs to be passed through, and / or a gateway that needs to be detoured.

[0113] In a fifth aspect, an embodiment of the present application provides a route announcement method, which is applied to a backbone network edge device. The backbone network edge device mentioned here can be a backbone network egress device or a backbone network ingress device. The method includes: obtaining a route, the route is used to announce the information of the backbone network edge device; sending the route to the site edge, and the site edge accesses the backbone network through the backbone network edge device. It can be seen that, using this solution, the backbone network edge device can announce its own information to the site edge through the route, and the site edge can determine its own corresponding gateway through the received route, without the need to manually configure its corresponding gateway on the site edge.

[0114] In a possible implementation, the information includes: a first SID allocated by the backbone network edge device for the adjacency relationship between the backbone network edge device and the site edge, and / or a second SID of the backbone network edge device.

[0115] In one possible implementation, the routing is automatically discovered by the SD-WAN gateway.

[0116] In a possible implementation, the route is a BGP link state LS route, and the BGP LS route includes a TLV, where the TLV indicates that the route is used to notify information of the backbone network edge device.

[0117] In a possible implementation manner, the TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the backbone network edge device is a gateway.

[0118] In a possible implementation, the route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device and a backbone network egress device in the backbone network.

[0119] In a possible implementation, the route includes a Metadata Path Attribute, and the Metadata Path Attribute carries the intermediate gateway information.

[0120] In a sixth aspect, embodiments of the present application provide a communication device, which may include a transceiver unit and / or a processing unit; the transceiver unit is configured to perform receiving and / or transmitting operations; and the processing unit is configured to perform operations other than receiving and / or transmitting operations. The transceiver unit includes a receiving unit and / or a transmitting unit, the receiving unit being configured to perform receiving operations, and the transmitting unit being configured to perform transmitting operations.

[0121] In a specific example: the communication device may include a receiving unit and a processing unit. In this case, the communication device can be used to execute the method described in the first aspect and any one of the first aspects above, or to execute the method described in the fourth aspect and any one of the fourth aspects above.

[0122] When the communication device can be used to perform the method according to the first aspect and any one of the above first aspects:

[0123] A receiving unit is used to receive a first route announced by a second communication device, where the first route includes first information of a first backbone network exit device in the backbone network and an identifier of a second site edge, where the second site edge accesses the backbone network through the first backbone network exit device, and the first site edge accesses the backbone network through a first backbone network entry device; and a processing unit is used to obtain a first binding relationship between the second site edge and the first backbone network exit device based on the first route.

[0124] In a possible implementation, the processing unit is further used to: determine a first end-to-end path from the first site edge to the second site edge based on the first binding relationship, where the first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device.

[0125] In one possible implementation, the first information includes one or more of the following: a first segment identifier SID assigned by the first backbone network egress device to the adjacency relationship between the first backbone network egress device and the second site edge; a second SID of the first backbone network egress device; a routing priority of the first backbone network egress device; and a load sharing weight of the first backbone network egress device.

[0126] In one possible implementation, the first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.X SID that is cross-connected to a Layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.SID; or, the first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

[0127] In one possible implementation, the second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

[0128] In one possible implementation, the SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, and the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

[0129] In a possible implementation, the second communication device is the second site edge, and the first route includes a virtual private network VPN route.

[0130] In a possible implementation, the VPN route includes a first metadata path attribute, and the first metadata path attribute carries the first information.

[0131] In a possible implementation manner, the first route further includes: service intent information.

[0132] In a possible implementation, the service intention information includes one or more of the following: a gateway that the first end-to-end path needs to pass through, a gateway that the first end-to-end path needs to bypass, and a quality of service parameter.

[0133] In a possible implementation, the first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the service intent information.

[0134] In a possible implementation, the second communication device is the first backbone network egress device, and the receiving unit is configured to receive the first route advertised by the first backbone network egress device through the first backbone network ingress device.

[0135] In one possible implementation, the first route includes: the first SD-WAN gateway automatically discovers the route.

[0136] In one possible implementation, the receiving unit is further used to: receive a second route announced by a third communication device, the second route including second information of a second backbone network exit device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network exit device; the processing unit is further used to obtain a second binding relationship between the second site edge and the second backbone network exit device based on the second route.

[0137] In a possible implementation, the processing unit is further used to: determine the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or determine the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

[0138] In one possible implementation, the processing unit is further used to: determine, based on the second binding relationship, a second end-to-end path from the first site edge to the second site edge, where the second end-to-end path passes through the first backbone network ingress device and the second backbone network egress device.

[0139] In one possible implementation, the receiving unit is further used to: receive a third route sent by the first backbone network entry device, where the third route is used to notify the first backbone network entry device of third information; the processing unit is further used to: obtain a third binding relationship between the first site edge and the first backbone network entry device based on the third route.

[0140] In one possible implementation, the third route is a second SD-WAN gateway automatic discovery route or a BGP link state LS route.

[0141] In a possible implementation, the third information includes: a third SID allocated by the first backbone network ingress device for the adjacency relationship between the first backbone network ingress device and the first site edge, and / or a fourth SID of the first backbone network ingress device.

[0142] In a possible implementation, the third route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between the first backbone network ingress device and the egress device in the backbone network.

[0143] In a possible implementation, the apparatus further includes a sending unit. For this case:

[0144] The receiving unit is further used to receive a first service message; the processing unit is further used to encapsulate path information of a first end-to-end path in an outer layer of the first service message to obtain a second service message; wherein the path information of the first end-to-end path includes fourth information identifying a first backbone network ingress device in the backbone network and fifth information identifying a first backbone network egress device in the backbone network, the ingress endpoint of the first end-to-end path is the first site edge, the egress endpoint of the first end-to-end path is the second site edge, the first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; the sending unit is used to send the second service message through the first end-to-end path.

[0145] In one possible implementation, the first service message is used to carry a virtual private network (VPN) service, and the processing unit is further used to: before receiving the first service message, orchestrate the first end-to-end path from the first site edge to the second site edge in combination with the first backbone network ingress device and the first backbone network egress device as needed based on the VPN service.

[0146] In a possible implementation, the second service message further includes service intent information.

[0147] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0148] In one possible implementation, the processing unit is further used to: before encapsulating the path information of the first end-to-end path, determine that the next hop for forwarding the first business message is the second site edge according to the destination address of the first business message, and iterate the first segment routing policy SR Policy according to the Internet Protocol IP address of the second site edge to obtain the path information of the first end-to-end path.

[0149] In one possible implementation, the first end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the fourth information and the fifth information.

[0150] In one possible implementation, the fourth information is the first endpoint segment identifier END.SID1 of the first backbone network entry device, the fifth information is the second endpoint segment identifier END.SID2 of the first backbone network egress device, and the SRH also includes the IPv6 address of the second site edge.

[0151] In a possible implementation, the fourth information is the first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the fifth information is the endpoint segment identifier END.X SID, which is cross-connected to a Layer 3 adjacency array and is allocated by the first backbone network device egress device for the adjacency relationship between the first backbone network device egress device and the second site edge.

[0152] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1.

[0153] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper-layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the END.SID1 and the service intent information.

[0154] In one possible implementation, the first end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the fourth information and the fifth information, the fourth information is the first node SID of the first backbone network ingress device, and the fifth information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0155] In a possible implementation, the operation of associating the first node SID includes matching an upper-layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the first node SID in the label stack.

[0156] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0157] In a possible implementation, the first end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0158] In a possible implementation, the first end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0159] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0160] In one possible implementation, the receiving unit is further used to receive a third service message; the processing unit is further used to encapsulate path information of a third end-to-end path in an outer layer of the third service message to obtain a fourth service message; wherein the path information of the third end-to-end path includes sixth information identifying a second backbone network ingress device in the backbone network and seventh information identifying a second backbone network egress device in the backbone network, the ingress endpoint of the third end-to-end path is the first site edge, the egress endpoint of the third end-to-end path is the second site edge, the third end-to-end path passes through the second backbone network ingress device and the second backbone network egress device, the first site edge is multi-homed to the first backbone network ingress device and the second backbone network ingress device, and the second site edge is multi-homed to the first backbone network egress device and the second backbone network egress device; the sending unit is further used to send the fourth service message through the third end-to-end path.

[0161] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0162] When the communication device can be used to perform the method described in any one of the fourth aspects and the fourth aspect above:

[0163] A receiving unit is used to receive a first route sent by a first backbone network edge device, where the first route is used to notify the first information of the first backbone network edge device, and the site edge accesses the backbone network through the first backbone network edge device; and a processing unit is used to obtain a first binding relationship between the site edge and the first backbone network edge device based on the first route.

[0164] In a possible implementation, the first information includes: a first SID allocated by the first backbone network edge device for an adjacency relationship between the first backbone network edge device and the site edge, and / or a second SID of the first backbone network edge device.

[0165] In one possible implementation, the receiving unit is further used to: receive a second route sent by a second backbone network edge device, where the second route is used to notify the second information of the second backbone network edge device, and the site edge accesses the backbone network through the second backbone network edge device; the processing unit is further used to obtain a second binding relationship between the site edge and the second backbone network edge device based on the second route.

[0166] In a possible implementation, the processing unit is further used to: determine the routing priorities corresponding to the first backbone network edge device and the second backbone network edge device respectively; and / or determine the load sharing weights corresponding to the first backbone network edge device and the second backbone network edge device respectively.

[0167] In one possible implementation, the first route is an SD-WAN gateway automatic discovery route.

[0168] In a possible implementation, the first route is a BGP link state LS route, and the BGP LS route includes a TLV, where the TLV indicates that the first route is used to notify the first information of the first backbone network edge device.

[0169] In a possible implementation manner, the TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the backbone network edge device is a gateway.

[0170] In a possible implementation, the first route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device and a backbone network egress device in the backbone network.

[0171] In a possible implementation, the first route includes a Metadata Path Attribute, and the Metadata Path Attribute carries the intermediate gateway information.

[0172] In a possible implementation, the processing unit is further configured to determine, based on the intermediate gateway information, gateway constraint information in the service intent information, where the gateway constraint information indicates gateway constraint conditions that must be followed to determine a path to the site edge.

[0173] In a possible implementation, the gateway constraint condition includes: a gateway that needs to be passed through, and / or a gateway that needs to be detoured.

[0174] In another specific example: the communication device may include a processing unit and a sending unit. In this case, the communication device can be used to execute the method described in the second aspect and any one of the second aspects above, or to execute the method described in the fifth aspect and any one of the fifth aspects above.

[0175] When the communication device can be used to perform the method according to the second aspect and any one of the second aspects:

[0176] A processing unit is used to obtain a first route, where the first route includes first information of a first backbone network exit device and an identifier of a second site edge in the backbone network, and the second site edge accesses the backbone network through the first backbone network exit device; a sending unit is used to notify the first site edge of the first route, and the first site edge accesses the backbone network through the first backbone network entry device.

[0177] In one possible implementation, the first information includes one or more of the following: a first segment identifier SID assigned by the first backbone network egress device to the adjacency relationship between the first backbone network egress device and the second site edge; a second SID of the first backbone network egress device; a routing priority of the first backbone network egress device; and a load sharing weight of the first backbone network egress device.

[0178] In one possible implementation, the first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.X SID that is cross-connected to a Layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.SID; or, the first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

[0179] In one possible implementation, the second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

[0180] In one possible implementation, the SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, and the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

[0181] In a possible implementation, the second communication device is the second site edge, and the first route includes a virtual private network VPN route.

[0182] In a possible implementation, the VPN route includes a first metadata path attribute, and the first metadata path attribute carries the first information.

[0183] In a possible implementation manner, the first route further includes: service intent information.

[0184] In one possible implementation, the service intent information includes one or more of the following: a gateway through which the service traffic needs to pass, a gateway that the service traffic needs to bypass, and quality of service parameters that need to be met when transmitting the service traffic.

[0185] In a possible implementation, the first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the service intent information.

[0186] In a possible implementation, the second communication device is the first backbone network egress device, and the sending unit is configured to: notify the first route to the first site edge through the first backbone network ingress device.

[0187] In one possible implementation, the first route includes: the first SD-WAN gateway automatically discovers the route.

[0188] In one possible implementation, the sending unit is also used to: announce a second route to the first site edge, where the second route includes second information of a second backbone network exit device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network exit device.

[0189] In one possible implementation, the device also includes: a receiving unit for receiving a third route sent by the first backbone network export device, wherein the third route is used to notify the third information of the first backbone network export device; the processing unit is also used to obtain the first binding relationship between the second site edge and the first backbone network export device based on the third route.

[0190] In a possible implementation, the third information includes: a third SID allocated by the first backbone network egress device for the adjacency relationship between the first backbone network egress device and the second site edge, and / or a fourth SID of the first backbone network egress device.

[0191] In one possible implementation, the receiving unit is further used to: receive a fourth route sent by the second backbone network export device, and the fourth route is used to announce the fourth information of the second backbone network export device; the processing unit is further used to obtain the second binding relationship between the second site edge and the second backbone network export device based on the fourth route.

[0192] In a possible implementation, the processing unit is further used to: determine the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or determine the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

[0193] In one possible implementation, the third route is a route automatically discovered by the second SD-WAN gateway.

[0194] In a possible implementation, the third route is a BGP link state LS route, and the BGP LS route includes a second TLV, where the second TLV indicates that the third route is used to notify third information of the first backbone network egress device.

[0195] In a possible implementation, the second TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the first backbone network egress device is a gateway.

[0196] In a possible implementation, the third route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device in the backbone network and the first backbone network egress device.

[0197] In a possible implementation, the third route includes a third Metadata Path Attribute, and the third Metadata Path Attribute carries the intermediate gateway information.

[0198] In a possible implementation, the processing unit is further configured to determine, based on the intermediate gateway information, gateway constraint information in the service intent information, where the gateway constraint information indicates gateway constraint conditions that must be followed to determine a path to the second site edge.

[0199] In a possible implementation, the gateway constraint condition includes: a gateway that needs to be passed through, and / or a gateway that needs to be detoured.

[0200] When the communication device can be used to perform the method described in any one of the fifth aspects and the fifth aspect above:

[0201] The processing unit is used to obtain a route, which is used to notify the information of the backbone network edge device; the sending unit is used to send the route to the site edge, and the site edge accesses the backbone network through the backbone network edge device.

[0202] In a possible implementation, the information includes: a first SID allocated by the backbone network edge device for the adjacency relationship between the backbone network edge device and the site edge, and / or a second SID of the backbone network edge device.

[0203] In one possible implementation, the routing is automatically discovered by the SD-WAN gateway.

[0204] In a possible implementation, the route is a BGP link state LS route, and the BGP LS route includes a TLV, where the TLV indicates that the route is used to notify information of the backbone network edge device.

[0205] In a possible implementation manner, the TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the backbone network edge device is a gateway.

[0206] In a possible implementation, the route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device and a backbone network egress device in the backbone network.

[0207] In a possible implementation, the route includes a Metadata Path Attribute, and the Metadata Path Attribute carries the intermediate gateway information.

[0208] In another specific example: the communication device may include a receiving unit and a sending unit. In this case, the communication device may be used to execute the method described in the third aspect and any one of the above third aspects.

[0209] A receiving unit is used to receive a first route announced by a first backbone network exit device in the backbone network, where the first route includes information of the first backbone network exit device and an identifier of a second site edge, where the second site edge accesses the backbone network through the first backbone network exit device, and the first site edge accesses the backbone network through the first backbone network entry device; and a sending unit is used to announce the first route to the first site edge.

[0210] In a possible implementation, the communication device further includes a processing unit. For this situation:

[0211] The receiving unit is further configured to receive a second service message from a first site edge, the payload of the second service message including the first service message, the outer layer of the first service message encapsulating path information of an end-to-end path between the first site edge and the second site edge; wherein the path information of the end-to-end path includes: first information identifying the first backbone network ingress device and second information identifying the first backbone network egress device in the backbone network, the ingress endpoint of the end-to-end path is the first site edge, the egress endpoint of the end-to-end path is the second site edge, the end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; the processing unit is configured to process the second service message according to the first information to obtain a third service message; and the sending unit is further configured to send the third service message to the first backbone network egress device.

[0212] In a possible implementation, the second service message further includes service intent information.

[0213] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0214] In one possible implementation, the end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

[0215] In a possible implementation, the first information is the first endpoint segment identifier END.SID1 allocated by the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 allocated by the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

[0216] In a possible implementation, the first information is a first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the second information is an endpoint segment identifier END.X SID allocated by the first backbone network device egress device for an adjacency relationship between the first backbone network device egress device and the second site edge, with a cross-connection to a Layer 3 adjacency relationship array.

[0217] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH.

[0218] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the END.SID1 in the SRH and the service intent information.

[0219] In one possible implementation, the processing unit is configured to: match a first overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH; and encapsulate the second service message using the first overly SRv6 policy to obtain the third service message.

[0220] In one possible implementation, the processing unit is configured to: match a second overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH and the service intent information; and encapsulate the second service message using the second overly SRv6 Policy to obtain the third service message.

[0221] In one possible implementation, the end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0222] In a possible implementation, the operation of associating the first node SID includes: matching an upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the label stack.

[0223] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy from the first backbone network ingress device to the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0224] In one possible implementation, the processing unit is configured to: match a first overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the first node SID in the label stack; and encapsulate the second service packet using the first overly SR-MPLS TE policy to obtain the third service packet.

[0225] In one possible implementation, the processing unit is configured to: match a second overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the first node SID in the label stack and the service intent information; and encapsulate the second service packet using the second overly SR-MPLS TE policy to obtain the third service packet.

[0226] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0227] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0228] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0229] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0230] In a seventh aspect, an embodiment of the present application provides a communication device, characterized by comprising: a processor and a memory;

[0231] The memory is used to store instructions; the processor is used to execute the instructions, so that the communication device performs the method described in the first aspect and any one of the first aspects, or the communication device performs the method described in the second aspect and any one of the second aspects, or the communication device performs the method described in the third aspect and any one of the third aspects, or the communication device performs the method described in the fourth aspect and any one of the fourth aspects, or the communication device performs the method described in the fifth aspect and any one of the fifth aspects.

[0232] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions or a computer program. When the instructions or computer program are executed on a processor, the method described in the first aspect and any one of the first aspects is implemented, or the method described in the second aspect and any one of the second aspects is implemented, or the method described in the third aspect and any one of the third aspects is implemented, or the method described in the fourth aspect and any one of the fourth aspects is implemented, or the method described in the fifth aspect and any one of the fifth aspects is implemented.

[0233] In the ninth aspect, an embodiment of the present application provides a computer program product, including a computer program product, which, when running on a processor, implements the method described in the first aspect and any one of the first aspects, or implements the method described in the second aspect and any one of the second aspects, or implements the method described in the third aspect and any one of the third aspects, or implements the method described in the fourth aspect and any one of the fourth aspects, or implements the method described in the fifth aspect and any one of the fifth aspects.

[0234] In a tenth aspect, an embodiment of the present application provides a communication system, the communication system comprising:

[0235] A first communication device that executes the method described in the first aspect and any one of the first aspects, and a second communication device that executes the method described in the second aspect and any one of the second aspects; or

[0236] A site edge that executes the method described in the fourth aspect and any one of the fourth aspects, and a backbone network edge device that executes the method described in the fifth aspect and any one of the fifth aspects.

[0237] In an eleventh aspect, an embodiment of the present application provides a method for forwarding traffic, which can be applied to a first site edge. The first site edge can receive a first service message. After receiving the first service message, the first site edge can encapsulate path information of a first end-to-end path in the outer layer of the first service message to obtain a second service message. The ingress endpoint of the first end-to-end path is the first site edge, and the egress endpoint of the first end-to-end path is the second site edge. The path information of the first end-to-end path includes: first information identifying a first backbone network ingress device in the backbone network, and second information identifying a first backbone network egress device in the backbone network. The first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device. After receiving the second service message, the first site edge can forward the second service message through the first end-to-end path. Thus, using this solution, the site edge can orchestrate a first end-to-end path across the backbone network, eliminating the need for devices in the backbone network to determine the transmission path based on service configuration. This eliminates the need for the backbone network to be aware of the service, thereby improving the forwarding efficiency of service traffic. Moreover, since the backbone network does not need to be aware of the service, there is no need to perform service-related configuration on the equipment in the backbone network, thereby improving the efficiency of service activation and, accordingly, the scalability of the backbone network.

[0238] In one possible implementation, the first end-to-end path may be pre-arranged by the first site edge. In a specific example, the first site edge may arrange the first end-to-end path before receiving the first service message. In a specific example, the first service message is used to carry a virtual private network (VPN) service. For this purpose, the first site edge may, based on the VPN service, combine the first backbone network entry device and the first backbone network exit device as needed to arrange the first end-to-end path from the first site edge to the second site edge. As an example, the first site edge may arrange an end-to-end path for the VPN route after receiving the VPN route including the destination prefix announced by the second site edge. In a specific example, the first site edge may arrange the first end-to-end path for the VPN route based on the binding relationship between the first site edge and the first backbone network entry device, and the binding relationship between the second site edge and the first backbone network exit device.

[0239] In one possible implementation, the second business message may also include business intent information. In this way, after the first site edge sends the second business message, the forwarding device that receives the second business message can select a corresponding path for forwarding based on the business intent information when further forwarding the second business message, so that the business intent is met and, accordingly, the service quality provided to the business is improved.

[0240] In one possible implementation, the second service message may include a metadata field, and the service intent information is carried in the metadata field. A forwarding device that receives the second service message may parse the metadata field to obtain the service intent information, so as to further select a corresponding path for forwarding based on the service intent information, thereby satisfying the service intent and, accordingly, improving the quality of service provided to the service.

[0241] In one possible implementation, the first site edge may first determine the path information of the first end-to-end path before encapsulating the first service message using the path information of the first end-to-end path. In a specific example, the first site edge may determine, based on the destination address of the first service message, that the next hop for forwarding the first service message is the second site edge, and further, iterate a first segment routing policy (SR policy) based on the Internet Protocol (IP) address of the second site edge to obtain the path information of the first end-to-end path.

[0242] In one possible implementation, the first SR policy may be an Internet Protocol Version 6 Segment Routing (SRv6) policy. In this case, the first end-to-end path may be an SRv6 tunnel. Accordingly, the second service packet includes an IPv6 header and a segment routing header (SRH), and the first and second information may be carried by the SRH. Furthermore, the destination address of the IPv6 header points to the first backbone network ingress device, so that the first site edge forwards the second service packet to the first backbone network ingress device based on the destination address of the IPv6 header.

[0243] In one possible implementation, when the first SR policy is an SRv6 policy, the first information may be the first endpoint segment identifier (END.SID) 1 of the first backbone network ingress device, and the second information may be the second endpoint segment identifier END.SID2 of the first backbone network egress device. In addition, the SRH also includes the IPv6 address of the second site edge. In this case, the SRH may indicate the path from the first backbone network ingress device to the second site edge.

[0244] In one possible implementation, when the first SR policy is an SRv6 policy, the first information is the END.SID1 of the first backbone network ingress device, and the second information is the endpoint segment identifier (END.X SID) assigned by the first backbone network egress device for the adjacency between the first backbone network egress device and the second site edge, with a cross-connection to a Layer 3 adjacency array. In this case, the SRH may also indicate a path from the first backbone network ingress device to the second site edge.

[0245] In one possible implementation, the END.SID1 can be used to indicate a new message forwarding operation. In this case, the first backbone network ingress device can determine how to forward the second service message based on the END.SID1 without combining VPN information to determine how to forward the second service message.

[0246] In a specific example, the operation associated with END.SID1 may be: matching the overlying SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of END.SID1 in the SRH. In another specific example, when the second service message includes service intent information, the operation associated with END.SID1 may be: matching the overlying SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of END.SID1 in the SRH and the service intent information.

[0247] In one possible implementation, the aforementioned first SR policy may be an MPLS segment routing traffic engineering (SR-TE) policy. For this case, the first end-to-end path is an MPLS SR-TE policy. Accordingly, the second service message includes an MPLS label stack, and the aforementioned first information and second information are carried by the MPLS label stack. For this case, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier (adj-SID) assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0248] In one possible implementation, the first node SID can be used to indicate a new message forwarding operation. In this case, the first backbone network ingress device can determine how to forward the second service message based on the first node SID without combining VPN information to determine how to forward the second service message.

[0249] In a specific example, the operation of associating the first node SID may be: matching the upper layer (overly) SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the MPLS label stack. In another specific example, when the second service message includes service intent information, the operation of associating the first node SID may be: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the MPLS label stack and the service intent information.

[0250] In one possible implementation, the first end-to-end path is a tunnel encapsulated based on the Generic Network Virtualization Encapsulation (GENEVE) protocol. In this case, the first site edge can use GENEVE encapsulation when encapsulating the path information of the first end-to-end path in the outer layer of the first service message. In other words, the second service message uses GENEVE encapsulation. When the first end-to-end path is an SRv6 tunnel, the second service message can use SRv6 in GENEVE encapsulation. When the first end-to-end path is an MPLS SR-TE policy, the second service message can use MPLS in GENEVE encapsulation.

[0251] In one possible implementation, the first end-to-end path is a tunnel encapsulated based on the generic routing encapsulation (GRE) protocol. In this case, when the first site edge encapsulates the path information of the first end-to-end path in the outer layer of the first service message, GRE encapsulation can be used. In other words, the second service message is encapsulated using GRE. When the first end-to-end path is an SRv6 tunnel, the second service message can be encapsulated using SRv6 over GRE. When the first end-to-end path is an MPLS SR-TE policy, the second service message can be encapsulated using MPLS over GRE.

[0252] In one possible implementation, if the second service message is encapsulated using SRv6 over GRE, the second service message includes: an outer IP header, a User Datagram Protocol (UDP) header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation, and a payload, wherein the payload includes the first service message, and the inner GRE encapsulation includes a VPN identifier (VNI) of the VPN service carried by the first service message. The VPN identifier is carried in the inner GRE encapsulation. When the second service message is transmitted in the backbone network, the devices in the backbone network do not parse the VPN identifier, that is, the backbone network is not aware of the VPN.

[0253] In one possible implementation, the first site edge can also receive a third service message and encapsulate path information of a second end-to-end path within the outer layer of the third service message to obtain a fourth service message. The path information of the second end-to-end path includes third information identifying a second backbone network ingress device in the backbone network and fourth information identifying a second backbone network egress device in the backbone network. The ingress endpoint of the second end-to-end path is the first site edge, the egress endpoint of the second end-to-end path is the second site edge, the second end-to-end path passes through the second backbone network ingress device and the second backbone network egress device, the first site edge is multi-homed to the first backbone network ingress device and the second backbone network ingress device, and the second site edge is multi-homed to the first backbone network egress device and the second backbone network egress device. The first site edge sends the fourth service message via the second end-to-end path. Thus, using this solution, the site edge can orchestrate a second end-to-end path across the backbone network, eliminating the need for backbone network devices to determine a transmission path based on service configuration. This eliminates the need for the backbone network to be aware of the service, thereby improving service traffic forwarding efficiency. Moreover, since the backbone network does not need to be aware of the service, there is no need to perform service-related configuration on the equipment in the backbone network, thereby improving the efficiency of service activation and, accordingly, the scalability of the backbone network.

[0254] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network (SD-WAN) tunnel or the Internet.

[0255] In the twelfth aspect, an embodiment of the present application provides a method for forwarding traffic, which can be applied to a first backbone network entry device in a backbone network. The first backbone network device can receive a second service message from a first site edge, and the payload of the second service message includes the first service message. The outer layer of the first service message encapsulates the path information of the end-to-end path between the first site edge and the second site edge; wherein the path information of the end-to-end path includes: first information identifying the first backbone network entry device, and second information identifying the first backbone network exit device in the backbone network, the entry point of the end-to-end path is the first site edge, the exit point of the end-to-end path is the second site edge, the end-to-end path passes through the first backbone network entry device and the first backbone network exit device, the first site edge accesses the backbone network through the first backbone network entry device, and the second site edge accesses the backbone network through the first backbone network exit device. After the first backbone network entry device receives the second service message, it can process the second service message according to the first information to obtain a third service message, and send the third service message to the first backbone network exit device to forward the service traffic. It can be seen that, using this solution, the first end-to-end path for transmitting the service is determined by the first site edge, and the second service message received by the first backbone network entry device includes the path information of the first end-to-end path. The first backbone network entry device does not need to determine the transmission path based on the service configuration, so that the backbone network does not need to perceive the service, thereby improving the forwarding efficiency of the service traffic. Moreover, since the backbone network does not need to perceive the service, there is no need to perform service-related configuration on the equipment in the backbone network, thereby improving the efficiency of service activation and, correspondingly, improving the scalability of the backbone network.

[0256] In a possible implementation, the second service message further includes service intent information.

[0257] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0258] In one possible implementation, the end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

[0259] In a possible implementation, the first information is the first endpoint segment identifier END.SID1 allocated by the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 allocated by the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

[0260] In a possible implementation, the first information is a first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the second information is an endpoint segment identifier END.X SID allocated by the first backbone network device egress device for an adjacency relationship between the first backbone network device egress device and the second site edge, with a cross-connection to a Layer 3 adjacency relationship array.

[0261] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH.

[0262] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the END.SID1 in the SRH and the service intent information.

[0263] In one possible implementation, when the first information is END.SID1, the first backbone network ingress device 1 processes the second service message according to the first information. In a specific implementation, the first overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device can be matched according to the next-hop SID of END.SID1 in the SRH, and the second service message can be encapsulated using the first overly SRv6 policy to obtain the third service message. Specifically, the first backbone network ingress device can insert a new SRH based on the second service message, and the new SRH carries the path information of the first overly SRv6 policy.

[0264] In one possible implementation, when the first information is END.SID1, if the second service message includes service intent information, the first backbone network entry device 1 processes the second service message according to the first information. In a specific implementation, the second overly SRv6 policy between the first backbone network entry device and the first backbone network exit device can be matched according to the next-hop SID of the END.SID1 in the SRH and the service intent information, and the second service message is encapsulated using the second overly SRv6 Policy to obtain the third service message. Specifically, the first backbone network entry device can insert a new SRH based on the second service message, and the new SRH carries the path information of the second overly SRv6 policy. In addition, the first backbone network entry device can also strip the service intent information from the second service message to obtain the third service message.

[0265] In one possible implementation, the end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0266] In a possible implementation, the operation of associating the first node SID includes: matching an upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the label stack.

[0267] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy from the first backbone network ingress device to the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0268] In one possible implementation, when the first information is the first node SID, the first backbone network ingress device 1 processes the second service message according to the first information. In a specific implementation, the first overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device can be matched according to the next-hop SID of the first node SID in the MPLS label stack. The first overly SR-MPLS TE policy is further used to encapsulate the second service message to obtain the third service message. For example, the first backbone network ingress device can replace SID1 and SID2 in the MPLS label stack with the first overly SR-MPLS TE policy to obtain the third service message.

[0269] In one possible implementation, when the first information is the first node SID, if the second service message includes service intent information, the first backbone network ingress device 1 processes the second service message according to the first information. In a specific implementation, the second overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device can be matched based on the next-hop SID of the first node SID in the MPLS label stack and the service intent information, and the second service message is encapsulated using the second overly SR-MPLS TE policy to obtain the third service message. For example, the first backbone network ingress device can replace SID1 and SID2 in the MPLS label stack with the second overly SR-MPLS TE policy to obtain the third service message.

[0270] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0271] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0272] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0273] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0274] In the thirteenth aspect, an embodiment of the present application provides a device for forwarding traffic, which may include a transceiver unit and a processing unit; the transceiver unit is used to perform the receiving and / or sending operations performed by the first site edge as described in the eleventh aspect above; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the first site edge as described in the eleventh aspect above.

[0275] In a specific example, the device includes: a receiving unit, a processing unit, and a sending unit. The receiving unit is used to receive a first service message; the processing unit is used to encapsulate the path information of the first end-to-end path in the outer layer of the first service message to obtain a second service message; wherein the path information of the first end-to-end path includes first information identifying a first backbone network ingress device in the backbone network and second information identifying a first backbone network egress device in the backbone network, the ingress endpoint of the first end-to-end path is the first site edge, the egress endpoint of the first end-to-end path is the second site edge, the first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; the sending unit is used to send the second service message through the first end-to-end path.

[0276] In one possible implementation, the first service message is used to carry a virtual private network (VPN) service, and the processing unit is further used to: before receiving the first service message, orchestrate the first end-to-end path from the first site edge to the second site edge in combination with the first backbone network ingress device and the first backbone network egress device as needed based on the VPN service.

[0277] In a possible implementation, the second service message further includes service intent information.

[0278] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0279] In one possible implementation, the processing unit is further used to: before encapsulating the path information of the first end-to-end path, determine that the next hop for forwarding the first business message is the second site edge according to the destination address of the first business message, and iterate the first segment routing policy SR Policy according to the Internet Protocol IP address of the second site edge to obtain the path information of the first end-to-end path.

[0280] In one possible implementation, the first end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header (SRH), the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

[0281] In a possible implementation, the first information is the first endpoint segment identifier END.SID1 of the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 of the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

[0282] In a possible implementation, the first information is a first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the second information is an endpoint segment identifier END.X SID allocated by the first backbone network device egress device for an adjacency relationship between the first backbone network device egress device and the second site edge, with a cross-connection to a Layer 3 adjacency relationship array.

[0283] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6Policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1.

[0284] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper-layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the END.SID1 and the service intent information.

[0285] In one possible implementation, the first end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0286] In a possible implementation, the operation of associating the first node SID includes matching an upper-layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the first node SID in the label stack.

[0287] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0288] In a possible implementation, the first end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0289] In a possible implementation, the first end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0290] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0291] In one possible implementation, the receiving unit is further used to receive a third service message; the processing unit is further used to encapsulate path information of the second end-to-end path in the outer layer of the third service message to obtain a fourth service message; wherein the path information of the second end-to-end path includes third information identifying a second backbone network ingress device in the backbone network and fourth information identifying a second backbone network egress device in the backbone network, the ingress endpoint of the second end-to-end path is the first site edge, the egress endpoint of the second end-to-end path is the second site edge, the second end-to-end path passes through the second backbone network ingress device and the second backbone network egress device, the first site edge is multi-homed to access the first backbone network ingress device and the second backbone network ingress device, and the second site edge is multi-homed to access the first backbone network egress device and the second backbone network egress device; the sending unit is further used to send the fourth service message via the second end-to-end path.

[0292] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0293] In the fourteenth aspect, an embodiment of the present application provides a device for forwarding traffic, which may include a transceiver unit and a processing unit; the transceiver unit is used to perform the receiving and / or sending operations performed by the first backbone network ingress device as described in the twelfth aspect above; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the first backbone network ingress device as described in the twelfth aspect above.

[0294] In a specific example, the apparatus includes: a receiving unit, a processing unit, and a sending unit. The receiving unit is configured to receive a second service message from a first site edge, wherein the payload of the second service message includes the first service message, and the outer layer of the first service message encapsulates path information of an end-to-end path between the first site edge and the second site edge; wherein the path information of the end-to-end path includes: first information identifying the first backbone network ingress device and second information identifying the first backbone network egress device in the backbone network, the ingress endpoint of the end-to-end path is the first site edge, the egress endpoint of the end-to-end path is the second site edge, the end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; the processing unit is configured to process the second service message based on the first information to obtain a third service message; and the sending unit is configured to send the third service message to the first backbone network egress device.

[0295] In a possible implementation, the second service message further includes service intent information.

[0296] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0297] In one possible implementation, the end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

[0298] In a possible implementation, the first information is the first endpoint segment identifier END.SID1 allocated by the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 allocated by the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

[0299] In a possible implementation, the first information is a first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the second information is an endpoint segment identifier END.X SID allocated by the first backbone network device egress device for an adjacency relationship between the first backbone network device egress device and the second site edge, with a cross-connection to a Layer 3 adjacency relationship array.

[0300] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH.

[0301] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the END.SID1 in the SRH and the service intent information.

[0302] In one possible implementation, the processing unit is configured to: match a first overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1 in the SRH; and encapsulate the second service message using the first overly SRv6 policy to obtain the third service message.

[0303] In one possible implementation, the processing unit is configured to: match a second overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the END.SID1 in the SRH and the service intent information; and encapsulate the second service message using the second overly SRv6 Policy to obtain the third service message.

[0304] In one possible implementation, the end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0305] In a possible implementation, the operation of associating the first node SID includes: matching an upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the label stack.

[0306] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0307] In one possible implementation, the processing unit is configured to: match a first overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the first node SID in the label stack; and encapsulate the second service packet using the first overly SR-MPLS TE policy to obtain the third service packet.

[0308] In one possible implementation, the processing unit is configured to: match a second overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the first node SID in the label stack and the service intent information; and encapsulate the second service packet using the second overly SR-MPLS TE policy to obtain the third service packet.

[0309] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0310] In a possible implementation, the end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0311] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0312] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0313] In a fifteenth aspect, an embodiment of the present application provides a communication device, characterized in that it includes: a processor and a memory;

[0314] The memory is used to store instructions; the processor is used to execute the instructions, so that the communication device executes the method described in the above eleventh aspect and any one of the eleventh aspects, or causes the communication device to execute the method described in the above twelfth aspect and any one of the twelfth aspects.

[0315] In the sixteenth aspect, an embodiment of the present application provides a computer-readable storage medium, including instructions or computer programs. When the instructions or computer programs are run on a processor, they implement the method described in the above eleventh aspect and any one of the eleventh aspects, or implement the method described in the above twelfth aspect and any one of the twelfth aspects.

[0316] In the seventeenth aspect, an embodiment of the present application provides a computer program product, including a computer program product, which, when running on a processor, implements the method described in the above eleventh aspect and any one of the eleventh aspects, or implements the method described in the above twelfth aspect and any one of the twelfth aspects.

[0317] In the eighteenth aspect, an embodiment of the present application provides a communication system, which includes a first site edge that executes the method described in the above eleventh aspect and any one of the eleventh aspects, and a first backbone network entry device that executes the method described in the above twelfth aspect and any one of the twelfth aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0318] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0319] FIG1a is a schematic diagram of an exemplary application scenario provided by an embodiment of the present application;

[0320] FIG1b is a schematic diagram of another exemplary application scenario provided by an embodiment of the present application;

[0321] FIG1c is a schematic diagram of another exemplary application scenario provided by an embodiment of the present application;

[0322] FIG2a is a schematic diagram of the structure of an MP_REACH_NLRI provided in an embodiment of the present application;

[0323] FIG2 b shows a schematic diagram of the structure of a link state NLRI;

[0324] FIG3 is a signaling interaction diagram of an information notification method provided in an embodiment of the present application;

[0325] FIG4a is a schematic diagram of the structure of an MP_REACH_NLRI provided in an embodiment of the present application;

[0326] FIG4 b is a schematic diagram of the structure of a routing priority sub-TLV provided in an embodiment of the present application;

[0327] FIG4c is a schematic diagram of the structure of a weight sub-TLV provided in an embodiment of the present application;

[0328] FIG4 d is a schematic diagram of the structure of a sub-TLV provided in an embodiment of the present application;

[0329] FIG4e is a schematic diagram of the structure of another seed TLV provided in an embodiment of the present application;

[0330] FIG4f is a schematic diagram of the structure of another sub-TLV provided in an embodiment of the present application;

[0331] FIG5 is a signaling interaction diagram of an information notification method provided in an embodiment of the present application;

[0332] FIG6 is a schematic diagram of the structure of a sub-TLV1 included in a Metadata Path Attribute2 provided in an embodiment of the present application;

[0333] FIG7 is a signaling interaction diagram of an information notification method provided in an embodiment of the present application;

[0334] FIG8 is a schematic diagram of the structure of another MP_REACH_NLRI provided in an embodiment of the present application;

[0335] FIG9 is a signaling interaction diagram of a route advertisement method provided in an embodiment of the present application;

[0336] FIG10 is a schematic diagram of the structure of an intermediate gateway sub-TLV provided in an embodiment of the present application;

[0337] FIG11 is a signaling interaction diagram of another route advertisement method provided in an embodiment of the present application;

[0338] FIG12a is a schematic diagram of the structure of a role announcement TLV provided in an embodiment of the present application;

[0339] FIG12b is a schematic diagram of the structure of an adjacency SID TLV provided in an embodiment of the present application;

[0340] FIG12c is a schematic diagram of the structure of a node SID TLV provided in an embodiment of the present application;

[0341] FIG13 is a signaling interaction diagram of a method for forwarding traffic provided in an embodiment of the present application;

[0342] FIG14a is a schematic diagram of the structure of an SRv6 over GRE encapsulation provided in an embodiment of the present application;

[0343] FIG14b is a schematic diagram of the structure of an MPLS over GRE encapsulation provided in an embodiment of the present application;

[0344] FIG14c is a schematic diagram of the structure of an SRv6 in GENEVE package provided in an embodiment of the present application;

[0345] FIG14 d is a schematic diagram of the structure of an SRv6 over GENEVE package provided in an embodiment of the present application;

[0346] FIG14e is a schematic diagram of the structure of an MPLS in GENEVE encapsulation provided in an embodiment of the present application;

[0347] FIG15a is a schematic diagram of a scenario of a traffic forwarding method provided in an embodiment of the present application;

[0348] FIG15b is a schematic diagram of a scenario of another traffic forwarding method provided in an embodiment of the present application;

[0349] FIG15c is a schematic diagram of a scenario of another traffic forwarding method provided in an embodiment of the present application;

[0350] FIG15d is a schematic diagram of a scenario of a traffic forwarding method provided in an embodiment of the present application;

[0351] FIG15e is a schematic diagram of another scenario of a traffic forwarding method provided in an embodiment of the present application;

[0352] FIG16 is a flow chart of an information notification method according to an embodiment of the present application;

[0353] FIG17 is a flow chart of another information notification method provided in an embodiment of the present application;

[0354] FIG18 is a flow chart of an information notification method according to an embodiment of the present application;

[0355] FIG19 is a flow chart of another information notification method provided in an embodiment of the present application;

[0356] FIG20 is a flow chart of another information notification method provided in an embodiment of the present application;

[0357] FIG21 is a flow chart of a method for forwarding traffic provided in an embodiment of the present application;

[0358] FIG22 is a flow chart of another method for forwarding traffic provided in an embodiment of the present application;

[0359] FIG23a is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0360] FIG23b is a schematic structural diagram of another communication device provided in an embodiment of the present application;

[0361] FIG23c is a schematic structural diagram of another communication device provided in an embodiment of the present application;

[0362] FIG23d is a schematic structural diagram of another communication device provided in an embodiment of the present application;

[0363] FIG24 is a schematic structural diagram of another communication device provided in an embodiment of the present application;

[0364] FIG25 is a schematic structural diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0365] The embodiments of the present application provide an information notification method and apparatus, which can improve the quality of service provided to business traffic in scenarios where business traffic needs to be transmitted across multiple network domains.

[0366] For ease of understanding, the possible application scenarios of the embodiments of the present application are first introduced.

[0367] Currently, in wide area networks, SD-WAN technology is commonly used to achieve end-to-end rapid delivery and flexible scheduling. Based on different layers (underlay) of the Internet, dedicated line networks, etc., SD-WAN tunnels are established to build an upper layer (overlay) network based on SD-WAN, decoupling WAN services from the lower layer networks and improving end-to-end delivery capabilities.

[0368] After deploying SD-WAN, the SD-WAN overlay network within the WAN builds on the existing underlay network to establish SD-WAN tunnels between points of presence (POPs) and between customer-premises equipment (CPE) and edge points of presence (EPOPs). Service traffic tunnels through intermediate devices, making them unaware of the service. At the overlay network level, each CPE or POP represents a hop in the service routing. Service traffic is forwarded end-to-end within the POP network, either hop-by-hop or using tunnels or labels.

[0369] Refer to Figure 1a, which is a schematic diagram of an exemplary application scenario provided by an embodiment of the present application. As shown in Figure 1a, service traffic needs to be transmitted across the edge access area 100, the backbone network 200, and the edge access area 300. Among them:

[0370] The edge access network 100 includes: site edge1, site edge3, and site edge4.

[0371] Backbone network 200 includes at least one network device. For example, when backbone network 200 is a Point of Presence (POP) backbone network, backbone network 200 includes at least one Point of Presence (POP). A POP connected to a site edge in the POP backbone network is called an EPOP, and a POP not connected to a site edge is called a backbone point of presence (BPOP). In one example, a site edge can be a Customer Presence Equipment (CPE).

[0372] The edge access network 300 includes a site edge2 and a site edge5.

[0373] Site edges in edge access networks 100 and 300 can access the backbone network through the EPOP in the backbone network. The EPOP in the backbone network used by a site edge to access the backbone network can be considered the gateway corresponding to the site edge. For example, as shown in Figure 1a, site edge1 is dual-homed to gateway (GW) 1 and gateway 3. Site edge1 can access backbone network 200 through gateways 1 and 3. For another example, site edge2 is dual-homed to gateways 2 and 4. Site edge2 can access backbone network 200 through gateways 2 and 4.

[0374] The site edge can access its corresponding gateway through the SD-WAN tunnel or the internet.

[0375] In an embodiment of the present application, the backbone network can be a hybrid network including at least one network domain, and the at least one network domain includes but is not limited to: a self-built backbone network and / or a managed service provider (MSP) backbone network, wherein the MSP backbone network can include a single operator network, a hybrid operator network, or a self-built dedicated line network, which is not specifically limited in the embodiment of the present application. For understanding, reference can be made to Figures 1b and 1c, which are schematic diagrams of two other exemplary application scenarios provided in the embodiments of the present application.

[0376] As shown in Figure 1b, backbone network 400 includes: Internet Service Provider (ISP) Network 1 (ISP1), ISP2, ISP3, and a self-built dedicated line network. The connection between network devices in the network architecture shown in Figure 1b is not described in detail here. The scenario shown in Figure 1c differs from Figure 1b in that backbone network 500 shown in Figure 1c does not include a self-built dedicated line network.

[0377] Currently, when service traffic needs to be transmitted across multiple network domains, the network's quality of service (QoS) for that traffic cannot meet requirements. One specific reason for this is that when orchestrating forwarding paths for services, the site edge cannot flexibly select the backbone point of presence (POP) used by the remote site edge to access the backbone network, nor can it select the egress link from that backbone POP to the remote site edge. This is illustrated using the scenario shown in Figure 1b as an example:

[0378] Currently, the service quality obtained by the business traffic sent from site edge1 to site edge2 during transmission in the network cannot meet the requirements. This is because when Edge1 arranges the transmission path for the business traffic, it cannot flexibly choose whether to transmit the business traffic to site edge2 via POP4 connected to site edge2, or to transmit the business traffic to site edge2 via POP9 connected to site edge2.

[0379] When the site edge arranges the forwarding path for the service, it cannot flexibly select the backbone network POP used by the remote site edge to access the backbone network because the site edge does not know the backbone network POP information used by the remote site edge to access the backbone network.

[0380] In view of this, an embodiment of the present application provides an information notification method and device, which enables the site edge to obtain the binding relationship between the remote site edge and the backbone network POP used by the remote site edge to access the backbone network, so that when the site edge arranges the forwarding path for the service, it can flexibly select the backbone network POP used by the remote site edge to access the backbone network, thereby improving the service quality provided to the service.

[0381] Next, the information notification method provided in the embodiment of the present application is introduced with reference to the accompanying drawings.

[0382] Before introducing the information notification method provided in the embodiment of the present application, the routing notification method between network devices is first introduced.

[0383] In one example, two communication devices can communicate routes using Multi-Protocol Extensions for BGP (MP-BGP). For example, in Figure 1a, edge2 announces a route to edge1. Edge2 sends BGP message 1 to edge1. This BGP message includes an MP_REACH_NLRI, which carries the routing information advertised by edge2 to edge1.

[0384] In one example, the structure of the MP_REACH_NLRI is shown in Figure 2a, which is a schematic diagram of the structure of an MP_REACH_NLRI provided in an embodiment of the present application. As shown in Figure 2a, the MP_REACH_NLRI includes an address family identifier (AFI), a subsequent address family identifier (SAFI), a next hop information length field, a next hop information field, and a network reachability information field.

[0385] As an example, the AFI field can identify the network layer protocol. For example, the value of the AFI field is 1 to identify IPv4, and the value of the AFI field is 2 to identify IPv6. The value of the AFI field can refer to the relevant description of the address family number in the request for comments (RFC) 1700, which is not described in detail here. The SAFI field identifies the type of the sub-address family. For example, the value of the SAFI field is 1 to identify unicast, the value of the SAFI field is 2 to identify multicast, the value of the SAFI field is 74 to identify SD-WAN, and the value of the SAFI field is 128 to identify a virtual private network (VPN).

[0386] In one example, the aforementioned next-hop network address may refer to the network address of the next device on the path to the destination device.

[0387] In one example, the NLRI field may include one or more NLRIs, each NLRI includes a length field and an NLRI value field, and the specific content of the NLRI value may be determined based on a combination of the AFI field and the SAFI field. For example:

[0388] When the AFI value is 1 and the SAFI value is 1, the NLRI information field of MP_REACH_NLRI carries the Internet Protocol Version 4 (IPv4) unicast route;

[0389] When the AFI value is 1 and the SAFI value is 128, the VPNv4 routes carried in the NLRI information field of the MP_REACH_NLRI;

[0390] When the AFI value is 1 and the SAFI value is 4, the BGP labeled route carried in the NLRI information field of MP_REACH_NLRI;

[0391] When the AFI value is 1 and the SAFI value is 74, the NLRI information field of MP_REACH_NLRI carries the IPv4 SD-WAN address family information;

[0392] When the AFI value is 2 and the SAFI value is 74, the NLRI information field of MP_REACH_NLRI carries the IPv6 SD-WAN address family information.

[0393] The NLRI information field includes a route type field, a length field, and a type specific value field. The route type field is used to indicate the route type, the length field is the length of the type specific value field, and the type specific value field is used to carry a value related to the type corresponding to the route type field.

[0394] In one example, when the NLRI information field of the MP_REACH_NLRI carries IPv4 SD-WAN address family information or IPv6 SD-WAN address family information, if the value of the type field is 1, the NLRI information field can be used to carry SD-WAN transport network port (transport network port, TNP) routing information. The information about TNP routing is not described in detail here.

[0395] In one example, the route type field in the NLRI information field may also be an NLRI type field. In a specific example, if the NLRI information field is used to carry one type of routing information, the NLRI information field may include the NLRI type field; if the NLRI information field is used to carry multiple types of routing information, the NLRI information field may include the route type field.

[0396] In another example, routing announcements can be made between two communication devices via the multi-protocol extension BGP-LS. Based on the original BGP, BGP-LS introduces a series of new NLRs to carry information related to links, nodes, and IPv4 prefixes or IPv6 prefixes. This new NLRI is called link-state NLRI. In one example, BGP-LS uses the MP_REACH_NLRI attribute as a container for the link-state NLRI, that is, the link-state NLRI is carried in the BGP Update message as an MP_REACH_NLRI attribute. Referring to Figure 2b, Figure 2b shows a schematic diagram of the structure of a link-state NLRI. As shown in Figure 2b, the link-state NLRI includes an NLRI type field, a total NLRI length field, and a link-state NLRI field. Among them:

[0397] The NLRI type field is used to indicate the NLRI type;

[0398] The total NLRI length field indicates the length of the entire NLRI;

[0399] The link-state NLRI field carries specific information. The content of the link-state NLRI field is determined by the value of the NLRI type field. For details about the content of the link-state NLRI field, refer to Table 1 below.

[0400] Table 1

[0401] Next, the information notification method provided in the embodiment of the present application is introduced with reference to the accompanying drawings.

[0402] See Figure 3, which is a signaling interaction diagram of an information notification method provided in an embodiment of the present application.

[0403] The information notification method 100 shown in Figure 3 can be applied to the application scenario shown in Figure 1a or Figure 1b. When the method 100 is applied to the application scenario shown in Figure 1a, the backbone network egress device 1 in the method 100 can correspond to GW2 shown in Figure 1a, and the backbone network egress device 2 in the method 100 can correspond to GW4 shown in Figure 1a. When the method 100 is applied to the application scenario shown in Figure 1b, the backbone network egress device 1 in the method 100 can correspond to POP4 shown in Figure 1b, and the backbone network egress device 2 in the method 100 can correspond to POP9 shown in Figure 1b. The method 100 may, for example, include the following S101-S104.

[0404] S101: Site edge2 obtains route 1, which is the SD-WAN gateway information announcement route. Route 1 includes the identifier of site edge2 and information 1 of backbone network export device 1. Site edge2 accesses the backbone network through backbone network export device 1.

[0405] In the embodiment of the present application, the site edge2 can generate the route 1 based on the identifier of the site edge2 and the information 1 of the backbone network egress device 1.

[0406] In the embodiment of the present application, the identifier of the site edge2 may be the IP address of the site edge2.

[0407] In the embodiment of the present application, the information 1 of the backbone network egress device 1 at least includes an identifier of the backbone network egress device 1 , and the identifier of the backbone network egress device 1 may be an IP address of the backbone network egress device 1 .

[0408] In one example, the information 1 may also include SID1 assigned by the backbone network egress device 1 to the adjacency relationship between the backbone network egress device 1 and the site edge2, so that in the subsequent traffic forwarding phase, the message can be encapsulated based on SID1, thereby performing traffic forwarding based on SID1. The SID1 can be an SRv6 END.X SID or an adj-SID. For example, in a network scenario using SRv6 technology forwarding, the SID1 can be an SRv6 END.X SID, and in a network scenario using MPLS technology forwarding, the SID1 can be an adj-SID.

[0409] In another example, the information 1 may also include the SID 2 of the backbone network egress device 1, so that during the subsequent traffic forwarding phase, the message can be encapsulated based on SID 2, thereby forwarding traffic based on SID 2. This SID 2 can be the SRv6 END.SID or the node SID. For example, in a network scenario using SRv6 forwarding technology, the SID 2 can be the SRv6 END.SID, and in a network scenario using MPLS forwarding technology, the SID 2 can be the node SID.

[0410] In another example, the information 1 may also include the routing priority of the backbone network egress device 1, so that the communication device (eg, edge1) receiving the route 1 arranges an end-to-end path from edge1 to edge2 in combination with the routing priority.

[0411] In another example, the information 1 may also include the load sharing weight of the backbone network egress device 1, so that the communication device (eg, edge1) receiving route 1 determines the end-to-end path for forwarding service traffic in combination with the load sharing weight.

[0412] The route 1 may be carried by the BGP message 1. Specifically, the route 1 may be carried by the MP_REACH_NLRI in the BGP message 1. Regarding the MP_REACH_NLRI carrying the route 1, the following is an example in which the route 1 includes the identifier of the site edge2, the identifier of the backbone network egress device 1, SID1, and SID2.

[0413] Refer to Figure 4a, which is a schematic diagram of the structure of an MP_REACH_NLRI provided in an embodiment of the present application. As shown in Figure 4a, the MP_REACH_NLRI includes: a route type field, a length field, a CPE endpoint address (CPE-End-Point) field, a destination gateway endpoint address (Destination-GW-End-Point) field, a connection SID field, and a destination gateway SID (Destination-GW-SID) field. Among them:

[0414] Route type: Route type. The value of the route type field indicates that route 1 is the SD-WAN gateway information announcement route. In an example, the value of route type can be 3.

[0415] length: The value of the length field indicates the total length of each field following the length field.

[0416] CPE-End-Point: carries the CPE endpoint address, for example, the IP address of site edge2.

[0417] Destination-GW-End-Point: carries the destination gateway endpoint address, for example, the IP address of backbone network egress device 1.

[0418] connection SID: used to carry the aforementioned SID1.

[0419] Destination-GW-SID: used to carry the aforementioned SID2.

[0420] In one example, if the information 1 also includes the routing priority of the aforementioned backbone network export device 1, then as an example, the aforementioned MP_REACH_NLRI may also include a routing priority field, and the routing priority field is used to carry the routing priority of the backbone network export device 1. As another example, the BGP message 1 may carry a BGP path attribute 1, and a routing priority sub-TLV is added to the BGP path attribute 1 to carry the routing priority. As shown in Figure 4b, Figure 4b is a structural diagram of a routing priority sub-TLV provided in an embodiment of the present application. The routing priority sub-TLV shown in Figure 4b may include a type, length, and a gateway priority (priority of the GW) field, and the gateway priority field is used to carry the routing priority of the aforementioned backbone network export device 1.

[0421] In another example, the information 1 also includes the load sharing weight of the aforementioned backbone network export device 1. As an example, the aforementioned MP_REACH_NLRI may also include a weight field, which is used to carry the load sharing weight of the backbone network export device 1. As another example, the BGP message 1 may carry a BGP path attribute 1, and a weight sub-TLV is added to the BGP path attribute 1 to carry the load sharing weight. As shown in Figure 4c, Figure 4c is a structural diagram of a weight sub-TLV provided in an embodiment of the present application. The weight sub-TLV shown in Figure 4c may include a type, length, and a gateway load sharing weight (weight of the GW) field, and the gateway load sharing weight field is used to carry the load sharing weight of the aforementioned backbone network export device 1.

[0422] S102: Site edge2 announces the route 1 to site edge1.

[0423] S103: Site edge1 receives route 1 advertised by site edge2.

[0424] S104: Site edge1 obtains binding relationship 1 between site edge2 and backbone network egress device 1 according to route 1.

[0425] After obtaining route 1, site edge2 can advertise route 1 to site edge1. Correspondingly, site edge1 can receive route 1 advertised by site edge2. After receiving route 1 advertised by site edge2, site edge1 can parse route 1 to obtain binding relationship 1 between site edge2 and backbone network egress device 1. After obtaining binding relationship 1, site edge1 can store it so that the end-to-end path from site edge1 to site edge2 can be determined based on it.

[0426] In an example, the binding relationship 1 may include the identifier of the site edge2 and the information 1 of the backbone network egress device 1. As an example, the binding relationship 1 may be as shown in the following Table 2:

[0427] Table 2

[0428] In one example, if the aforementioned route 1 does not include the routing priority of backbone network egress device 1, site edge 1 can determine the routing priority of backbone network egress device 1. For example, site edge 1 can determine the routing priority of backbone network egress device 1 based on its own configured routing policy or in combination with the load of backbone network egress device 1.

[0429] In another example, if the aforementioned route 1 does not include the load sharing weight of backbone network egress device 1, the site edge 1 can determine the load sharing weight of backbone network egress device 1. For example, the site edge 1 can determine the load sharing weight of backbone network egress device 1 based on its own configured load sharing policy or in combination with the load status of backbone network egress device 1.

[0430] In one example, route 1 may also include service intent information, which indicates service intent. Site edge 2 notifies site edge 1 of the service intent information via route 1. This allows the communication device forwarding service traffic to forward the traffic based on the service intent information during the traffic forwarding phase, thereby satisfying the service intent.

[0431] The service intent information in the embodiments of the present application may include one or more information indicating the service intent. In one example, the service intent information may include quality of service parameters, including but not limited to one or more parameters such as latency, packet loss, jitter, bandwidth utilization, and bit error rate. In another example, the service intent parameters may include gateway constraint information that must be satisfied by the end-to-end path from site edge1 to site edge2, including but not limited to gateways that must be passed through and / or gateways that must be bypassed.

[0432] In the embodiment of the present application, the route 1 may include a BGP path attribute 1, and the BGP path attribute 1 is used to carry the service intent information. It is noted here that the BGP path attribute 1 may be a Metadata Path Attribute 1.

[0433] In an example, if the service intention information includes the aforementioned gateway that needs to be passed through, the Metadata Path Attribute1 may include a sub-TLV1, and the sub-TLV1 is used to carry the gateway that needs to be passed through.

[0434] Refer to Figure 4d for further understanding. Figure 4d is a schematic diagram of the structure of a sub-TLV1 included in a Metadata Path Attribute1 provided in an embodiment of the present application. As shown in Figure 4d, the sub-TLV1 includes an include-GW sub-type field, a length field, and a gateway information field. Among them:

[0435] The inclusion of the Gateway Subtype field indicates that this sub-TLV is used to carry information about the gateway that needs to be passed through;

[0436] The length field is used to indicate the length of the gateway information field.

[0437] The gateway information field may carry gateway information. In one example, the gateway information includes a gateway address. In another example, the gateway information may also include a gateway SID. The gateway SID mentioned here may be an SRv6 END.SID or a node SID.

[0438] In another example, if the service intention information includes the aforementioned gateway that needs to be detoured, then the Metadata Path Attribute1 may include a sub-TLV2, and the sub-TLV2 is used to carry the gateway that needs to be detoured.

[0439] For further understanding, please refer to Figure 4e, which is a schematic diagram of the structure of a sub-TLV2 included in a Metadata Path Attribute1 provided in an embodiment of the present application. As shown in Figure 4e, the sub-TLV2 includes a bypass gateway sub-type field (exclude-GW sub-type), a length field, and a gateway information field. Among them:

[0440] The Detour Gateway Subtype field indicates that this sub-TLV is used to carry information about the gateway that needs to be detoured;

[0441] The length field is used to indicate the length of the gateway information field.

[0442] The gateway information field may carry gateway information. For gateway information, please refer to the relevant description of FIG. 4 d above, which will not be repeated here.

[0443] In another example, if the service intent information includes the aforementioned quality of service parameter, the Metadata Path Attribute1 may include a sub-TLV3, and the sub-TLV3 is used to carry the quality of service parameter.

[0444] For further understanding, please refer to Figure 4f, which is a schematic diagram of the structure of a sub-TLV3 included in a Metadata Path Attribute1 provided in an embodiment of the present application. As shown in Figure 4f, the sub-TLV3 includes a Quality of Service Parameter Subtype (QoS sub-type) field, a length field, and a Quality of Service Parameter field. Among them:

[0445] The Quality of Service Parameter Subtype field indicates that this sub-TLV is used to carry quality of service parameters;

[0446] The length field is used to indicate the length of the quality of service parameter field.

[0447] The quality of service parameter field may carry specific quality of service parameters, such as one or more parameters such as delay, packet loss, and bit error rate.

[0448] In an embodiment of the present application, when site edge2 is multi-homed to backbone network export device 1 and backbone network export device 2 in the backbone network, the site edge2 can correspond to multiple gateways. That is, in addition to backbone network export device 1 being the gateway of site edge2, backbone network export device 2 is also the gateway of site edge2. In this case, the site edge2 can also obtain route 2 and pass the route 2 to site edge1. The route 2 is the SD-WAN gateway information announcement route, and the route 2 includes the identifier of site edge2 and information 2 of backbone network export device 2. The site edge2 accesses the backbone network through the backbone network export device 2. Accordingly, site edge1 can receive route 2 announced by site edge2, and based on route 2, obtain the binding relationship 2 between site edge2 and backbone network export device 2.

[0449] Regarding the specific implementation of site edge2 notifying route 2 to site edge1 and site edge1 obtaining binding relationship 2, the implementation principle is the same as method 100. Therefore, the relevant implementation can refer to the description of method 100 in the previous text and is not described in detail here.

[0450] In an example, after site edge1 receives route 2, its locally stored binding relationship may be as shown in Table 3 below.

[0451] Table 3

[0452] See Figure 5, which is a signaling interaction diagram of an information notification method provided in an embodiment of the present application.

[0453] The information notification method 200 shown in Figure 5 can be applied to the application scenario shown in Figure 1a or Figure 1b. When the method 200 is applied to the application scenario shown in Figure 1a, the backbone network egress device 1 in the method 200 can correspond to GW2 in Figure 1a, and the backbone network egress device 2 in the method 200 can correspond to GW4 in Figure 1a. When the method 200 is applied to the application scenario shown in Figure 1b, the backbone network egress device 1 in the method 200 can correspond to POP4 in Figure 1b, and the backbone network egress device 2 in the method 200 can correspond to POP9 in Figure 1b.

[0454] The method 200 may include, for example, the following S201 - S204 .

[0455] S201: Site edge2 obtains route 1', which is a VPN route. Route 1' includes an identifier of site edge2 and information 1 of a backbone network egress device 1. Site edge2 accesses the backbone network through the backbone network egress device 1.

[0456] In an embodiment of the present application, the site edge2 can generate the route 1' based on the identifier of the site edge2 and the information 1 of the backbone network egress device 1. In one example, the VPN route can include a destination prefix. For example, in the scenario shown in FIG1b , the destination prefix can be the network prefix corresponding to the corporate headquarters.

[0457] Regarding the identifier of the site edge2 and the information 1 of the backbone network egress device 1, reference may be made to the relevant description in the method 100 and will not be repeated here.

[0458] In one example, the VPN route may include BGP path attribute 2, which is used to carry the identifier and information 1 of the aforementioned site edge2. In a specific example, the BGP path attribute 2 may be Metadata Path Attribute 2. The Metadata Path Attribute 2 may include sub-TLV 1, which is used to carry the identifier and information 1 of the aforementioned site edge2.

[0459] This can be understood in conjunction with Figure 6, which is a schematic diagram of the structure of a sub-TLV1 included in a Metadata Path Attribute2 provided in an embodiment of the present application. As shown in Figure 6, the sub-TLV1 includes: a Destination GW Sub-Type field, a length field, a priority field, a weight field, a CPE-End-Point field, a Destination-GW-End-Point field, a connection SID field, and a Destination-GW-SID field. Among them:

[0460] Destination GW Sub-Type: Destination gateway sub-type field, indicating that this sub-TLV carries information about the destination gateway;

[0461] length: The value of the length field indicates the total length of each field following the length field.

[0462] priority: Priority field, carrying the routing priority of backbone network egress device 1. In an example, the smaller the value of the priority field, the higher the priority.

[0463] weight: Load sharing weight field, which carries the load sharing weight of backbone network egress device 1.

[0464] CPE-End-Point: carries the CPE endpoint address, for example, the IP address of site edge2.

[0465] Destination-GW-End-Point: carries the destination gateway endpoint address, for example, the IP address of backbone network egress device 1.

[0466] connection SID: used to carry the aforementioned SID1.

[0467] Destination-GW-SID: used to carry the aforementioned SID2.

[0468] S202: The site edge2 notifies the route 1' to the site edge1.

[0469] S203: Site edge1 receives route 1' advertised by site edge2.

[0470] S204: Site edge1 obtains binding relationship 1 between site edge2 and backbone network egress device 1 according to route 1'.

[0471] After site edge2 obtains route 1', it can announce route 1' to site edge1. Correspondingly, site edge1 can receive route 1' announced by site edge2. After site edge1 receives route 1' announced by site edge2, it can parse route 1' to obtain binding relationship 1 between site edge2 and backbone network egress device 1. After site edge1 obtains binding relationship 1, it can store the binding relationship 1 so as to facilitate the subsequent determination of the end-to-end path from site edge1 to site edge2 based on the binding relationship 1. Regarding the binding relationship 1, you can refer to Table 2 in method 100 for understanding, and will not repeat it here.

[0472] In one example, if the aforementioned route 1' does not include the routing priority of backbone network egress device 1, the site edge1 can determine the routing priority of backbone network egress device 1. For example, the site edge1 can determine the routing priority of backbone network egress device 1 based on its own configured routing policy or in combination with the load of backbone network egress device 1.

[0473] In another example, if the aforementioned route 1' does not include the load sharing weight of backbone network egress device 1, then the site edge1 can determine the load sharing weight of backbone network egress device 1. For example, the site edge1 can determine the load sharing weight of backbone network egress device 1 based on its own configured load sharing policy or in combination with the load condition of backbone network egress device 1.

[0474] In one example, route 1' may also include service intent information, which indicates service intent. Site edge 2 notifies site edge 1 of the service intent information via route 1. This allows the communication device forwarding service traffic to incorporate the service intent information during the traffic forwarding phase, thereby satisfying the service intent. For details on the specific content of the service intent information, please refer to the previous description of method 100 and will not be repeated here.

[0475] In an embodiment of the present application, the service intent information may be carried by the BGP path attributes included in route 1'. In one example, the service intent information and the aforementioned information 1 may be carried by the same BGP path attributes, or by different BGP path attributes, which is not specifically limited in this embodiment of the present application.

[0476] In a specific example, both the business intent information and the aforementioned information 1 can be carried by Metadata Path Attribute 2. In this case, one Metadata Path Attribute can carry both the information 1 and the business intent information.

[0477] Regarding the specific implementation of the Metadata Path Attribute2 carrying the service intent information, reference may be made to the description of the Metadata Path Attribute1 carrying the service intent information in method 100 , which will not be repeated here.

[0478] In an embodiment of the present application, when site edge2 is multi-homed to backbone network egress device 1 and backbone network egress device 2 in the backbone network, the site edge2 may correspond to multiple gateways. That is, in addition to backbone network egress device 1 being the gateway of site edge2, backbone network egress device 2 is also the gateway of site edge2. In this case, the aforementioned VPN route may carry multiple sub-TLV1s, where one sub-TLV1 is used to carry information about one gateway. In this case, the site edge1 may parse the multiple sub-TLV1s to obtain information about multiple gateways bound to site edge2. In this case, after site edge1 receives the VPN route, its locally stored binding relationship may refer to Table 3 in method 100, and will not be repeated here.

[0479] See Figure 7, which is a signaling interaction diagram of an information notification method provided in an embodiment of the present application.

[0480] The information notification method 300 shown in FIG. 7 may be applied to the application scenario shown in FIG. 1 a or FIG. 1 b .

[0481] When the method 300 is applied to the application scenario shown in Figure 1a, the backbone network egress device 1 in the method 300 can correspond to GW2 shown in Figure 1a, the backbone network egress device 2 in the method 300 can correspond to GW4 shown in Figure 1a, and the backbone network ingress device 1 in the method 300 can correspond to GW1 or GW3 shown in Figure 1a.

[0482] When the method 300 is applied to the application scenario shown in Figure 1b, the backbone network export device 1 in the method 300 can correspond to POP4 shown in Figure 1b, the backbone network export device 2 in the method 300 can correspond to POP9 shown in Figure 1b, and the backbone network import device 1 in the method 300 can correspond to POP1 shown in Figure 1b.

[0483] The method 300 may include, for example, the following S301 - S304 .

[0484] S301: Backbone network export device 1 obtains route 1", wherein route 1" is a route automatically discovered by the SD-WAN gateway, and route 1" includes the identifier of site edge2 and information 1 of backbone network export device 1. Site edge2 accesses the backbone network through backbone network export device 1.

[0485] In the embodiment of the present application, the backbone network egress device 1 may generate the route 1 based on the identifier of the site edge2 and the information 1 of the backbone network egress device 1.

[0486] Regarding the identifier of the site edge2 and the information 1 of the backbone network egress device 1, reference may be made to the relevant description in the method 100 and will not be repeated here.

[0487] The route 1" can be carried by BGP message 2. Specifically, the route 1" can be carried by MP_REACH_NLRI in BGP message 2. Regarding the MP_REACH_NLRI carrying the route 1", the following is an example of route 1" including the identifier of the above-mentioned site edge2, the identifier of the backbone network egress device 1, SID1, and SID2.

[0488] See Figure 8, which is a schematic diagram of the structure of another MP_REACH_NLRI provided in an embodiment of the present application. As shown in Figure 8, the MP_REACH_NLRI includes: a route type field, a length field, a local-end-point field, a remote-end-point field, a connection SID field, and a local SID field. Among them:

[0489] Route Type: Route type. The value of the Route Type field indicates that "Route 1" is the route automatically discovered by the SD-WAN gateway. In one example, the value of Route Type can be 2.

[0490] length: The value of the length field indicates the total length of each field following the length field.

[0491] The local-end-point field carries the local address, which in this application carries the IP address of backbone network egress device 1;

[0492] remote-end-point: carries the CPE endpoint address, for example, the IP address of site edge2.

[0493] connection SID: used to carry the aforementioned SID1.

[0494] Local SID field: used to carry the local SID, and in this application carries the aforementioned SID2.

[0495] In one example, before executing S301, the backbone network egress device 1 and site edge 1 can advertise TNP routes to each other, and then an SD-WAN tunnel is established between site edge 2 and backbone network egress device 1. After the SD-WAN tunnel is created, backbone network egress device 1, acting as a GW, assigns a connection SID (i.e., SID1) to the tunnel, so that route 1 including SID1 can be obtained subsequently.

[0496] In one example, the backbone network egress device 1 can locally configure its own role as a gateway. Backbone network device 1 detects that its own role is a gateway, so after the SD-WAN tunnel is created, backbone network egress device 1, as a GW, allocates a connection SID for the tunnel.

[0497] S302: Backbone network egress device 1 announces route 1 to site edge1 through backbone network ingress device 1. Site edge1 accesses the backbone network through backbone network ingress device 1.

[0498] In an embodiment of the present application, a BGP neighbor relationship can be established between the backbone network egress device 1 and the backbone network ingress device 1, and the backbone network egress device 1 can announce the route 1" to the backbone network ingress device 1. After the backbone network ingress device 1 receives the route 1", it can further announce the route 1" to the site edge1.

[0499] S303: Site edge1 receives route 1 advertised by backbone network egress device 1.

[0500] S304: Site edge1 obtains binding relationship 1 between site edge2 and backbone network egress device 1 according to route 1.

[0501] After receiving route 1", site edge1 can parse route 1 to obtain binding relationship 1 between site edge2 and backbone network egress device 1. After obtaining binding relationship 1, site edge1 can store binding relationship 1 so as to facilitate subsequent determination of the end-to-end path from site edge1 to site edge2 based on binding relationship 1. Regarding the binding relationship 1, please refer to Table 2 in method 100 for understanding, and will not be repeated here.

[0502] In an example, after receiving the route 1", the site edge1 can determine the routing priority of the backbone network egress device 1. For example, the site edge1 can determine the routing priority of the backbone network egress device 1 based on its own configured routing policy or in combination with the load condition of the backbone network egress device 1.

[0503] In another example, after receiving the route 1", the site edge1 can determine the load sharing weight of the backbone network egress device 1. For example, the site edge1 can determine the load sharing weight of the backbone network egress device 1 based on its own configured load sharing strategy or in combination with the load condition of the backbone network egress device 1.

[0504] In this embodiment of the present application, when site edge2 is multi-homed to backbone network egress device 1 and backbone network egress device 2 in the backbone network, site edge2 may correspond to multiple gateways. That is, in addition to backbone network egress device 1 being the gateway for site edge2, backbone network egress device 2 is also the gateway for site edge2. In this case, backbone network egress device 2 may also notify site edge1 of the SD-WAN gateway automatic route discovery through backbone network ingress device 1, thereby enabling site edge1 to obtain binding relationship 2 between site edge2 and backbone network egress device 2. Regarding the specific implementation of "backbone network egress device 2 notifies site edge1 of the SD-WAN gateway automatic discovery route through backbone network ingress device 1", its implementation principle is the same as the principle of "backbone network egress device 1 notifies site edge1 of the SD-WAN gateway automatic discovery route through backbone network ingress device 1". Therefore, regarding the specific implementation of "backbone network egress device 2 notifies site edge1 of the SD-WAN gateway automatic discovery route through backbone network ingress device 1", please refer to the description of method 300 above, and the description will not be repeated here. In this case, after site edge1 receives the SD-WAN Ethernet automatic discovery route notified by backbone network egress device 2, the locally stored binding relationship can refer to Table 3 in method 100, and the description will not be repeated here.

[0505] In traditional technology, the binding relationship between a site edge and its corresponding gateway can be manually configured. For example, in the scenario shown in FIG1a: the gateways on site edge1 can be configured as GW1 and GW3, and the gateways on site edge2 can be configured as GW2 and GW4 by manual configuration. For another example, in the scenario shown in FIG1b: the gateways on site edge1 can be configured as POP1, and the gateways on site edge2 can be configured as POP4 and POP9 by manual configuration. The manual configuration method is inefficient. In view of this, the embodiments of the present application also provide corresponding routing announcement methods 400 and 500, which enable the site edge to determine its corresponding gateway through the received route, without the need to manually configure the corresponding gateway on the site edge.

[0506] Referring to Figure 9, which is a signaling interaction diagram of a route advertisement method provided in an embodiment of the present application, the method 400 shown in Figure 9 can be applied to the application scenario shown in Figure 1a or the application scenario shown in Figure 1b.

[0507] When the method 400 is applied to the application scenario shown in FIG1a :

[0508] In an example, the site edge in the method 400 may be the site edge1 shown in FIG. 1 a , and correspondingly, the gateway in the method 400 may be GW1 or GW3 shown in FIG. 1 a .

[0509] In another example, the site edge in the method 400 may be the site edge2 shown in FIG. 1 a , and correspondingly, the gateway in the method 400 may be GW2 or GW4 shown in FIG. 1 a .

[0510] When the method 400 is applied to the application scenario shown in FIG1b :

[0511] In an example, the site edge in the method 400 may be the site edge1 shown in FIG. 1 b , and correspondingly, the gateway in the method 400 may be the POP1 shown in FIG. 1 b .

[0512] In another example, the site edge in the method 400 may be the site edge2 shown in FIG. 1 b , and correspondingly, the gateway in the method 400 may be POP4 or POP9 shown in FIG. 1 b .

[0513] The method 400 shown in FIG. 9 may include the following S401 - S404 .

[0514] S401: The gateway obtains route 3, where route 3 is the route automatically discovered by the SD-WAN gateway and includes gateway information 3.

[0515] In the embodiment of the present application, the gateway may generate the route 3 based on its own information 3.

[0516] In one example, before executing S401, the gateway and the site edge can advertise TNP routes to each other, and then establish an SD-WAN tunnel between the site edge and the gateway. After the SD-WAN tunnel is created, the gateway assigns a connection SID (i.e., SID3) to the tunnel to facilitate subsequent acquisition of route 3 including SID3.

[0517] In one example, the gateway can locally configure its own role as a gateway. The gateway detects its own role as a gateway, and therefore, after the SD-WAN tunnel is created, the gateway assigns a connection SID to the tunnel. In one example, the information 3 can include the IP address of the gateway and the IP address of the site edge.

[0518] In one example, the information 3 may include SID3 assigned by the gateway to the adjacency relationship between the gateway and the site edge, so that in the subsequent traffic forwarding phase, the message can be encapsulated based on SID3, thereby performing traffic forwarding based on SID3. The SID3 can be an SRv6 END.X SID or an adj-SID. For example, in a network scenario using SRv6 technology forwarding, the SID3 can be an SRv6 END.X SID, and in a network scenario using MPLS technology forwarding, the SID3 can be an adj-SID.

[0519] In another example, the information 3 may include the gateway's SID 4, so that during the subsequent traffic forwarding phase, the message can be encapsulated based on SID 4, thereby forwarding traffic based on SID 4. SID 4 can be either the SRv6 END.SID or the node SID. For example, in a network scenario using SRv6 forwarding, SID 4 can be the SRv6 END.SID; in a network scenario using MPLS forwarding, SID 4 can be the node SID.

[0520] The route 3 may be carried by BGP message 3. Specifically, the route 3 may be carried by MP_REACH_NLRI in BGP message 3. Regarding the MP_REACH_NLRI carrying the route 3, a possible structure thereof may be referred to FIG8 , which will not be repeated here.

[0521] S402: The gateway notifies the route 3 to the site edge, and the site edge accesses the backbone network through the gateway.

[0522] S403: The site edge receives route 3 advertised by the gateway.

[0523] S404: The site edge obtains the binding relationship 3 between the site edge and the gateway according to the route 3.

[0524] After obtaining route 3, the gateway can advertise route 3 to the site edge. Correspondingly, the site edge can receive route 3 advertised by the gateway. After receiving route 3, the site edge can parse route 3 to obtain binding relationship 3 between the site edge and the gateway, so that the end-to-end path can be determined based on this binding relationship 3.

[0525] In one example, after receiving the route 3, the site edge may also determine the routing priority of the gateway. For example, the site edge may determine the routing priority of the gateway based on its own configured routing policy or in combination with the load of the gateway.

[0526] In another example, after receiving route 3, the site edge may also determine the load sharing weight of the gateway. For example, the site edge may determine the load sharing weight of the gateway based on its own configured load sharing policy or in combination with the load condition of the gateway.

[0527] In one example, the route 3 may also include intermediate gateway information, which indicates at least one intermediate gateway between the backbone network entry device and the backbone network exit device in the backbone network, so that the site edge can perform path orchestration based on the intermediate gateway. In one example, the site edge can determine the gateway constraints that the end-to-end path needs to follow based on business requirements and the intermediate gateway. The gateway constraints mentioned here include gateways that need to be passed through and / or gateways that need to be bypassed. In a specific example, when the site edge performs path orchestration based on business requirements, it can determine the gateways that the end-to-end path needs to pass through and / or the gateways that need to be bypassed from the intermediate gateways, so that the determined end-to-end path meets business requirements.

[0528] In one example, the intermediate gateway information can be carried by a BGP path attribute. In a specific example, the intermediate gateway information can be carried by Metadata Path Attribute 3. For example, the Metadata Path Attribute 3 can include at least one intermediate gateway sub-TLV, which is used to carry information about the intermediate gateway. One intermediate gateway sub-TLV is used to carry information about one intermediate gateway.

[0529] In an embodiment of the present application, for a particular intermediate gateway, the information of the intermediate gateway includes at least the endpoint address (e.g., IP address) of the intermediate gateway. Optionally, the information of the intermediate gateway may also include the SID of the intermediate gateway. The SID of the intermediate gateway may be an SRv6 END.SID or a node SID.

[0530] Regarding the intermediate gateway sub-TLV, it can be understood in conjunction with Figure 10, which is a schematic diagram of the structure of an intermediate gateway sub-TLV provided in an embodiment of the present application. As shown in Figure 10, the intermediate gateway sub-TLV includes: an intermediate gateway sub-type field (transit-GW sub-type), a length field, an intermediate gateway endpoint address (transit-GW-end-point) field, and an intermediate gateway SID (transit-GW-SID) field. Among them:

[0531] transit-GW sub-type field: Indicates that this sub-TLV carries the gateway information of an intermediate gateway.

[0532] Length field: indicates the total length of each field following the length field.

[0533] transit-GW-end-point field: indicates the endpoint address of the intermediate gateway.

[0534] transit-GW-SID field: indicates the SID corresponding to the intermediate gateway.

[0535] In some examples, for a certain site edge, it may correspond to multiple gateways. In this case, each gateway may send an SD-WAN gateway automatic discovery route to the site edge so that the site edge obtains the binding relationship between itself and the gateway. For example, in the scenario shown in Figure 1a, site edge1 is multi-homed to GW1 and GW3, then GW1 may send an SD-WAN gateway automatic discovery route carrying GW1's information to site edge1, and GW3 may send an SD-WAN gateway automatic discovery route carrying GW3's information to site edge1. For another example, in the scenario described in Figure 1b, site edge2 is dual-homed to POP4 and POP9. Then POP4 may send an SD-WAN gateway automatic discovery route carrying POP4's information to site edge2, and POP9 may send an SD-WAN gateway automatic discovery route carrying POP9's information to site edge2.

[0536] Taking the site edge1 shown in Figure 1a as an example, after GW1 and GW3 both send SD-WAN gateway automatic discovery routes to the site edge1, the site edge1 can obtain the binding relationship shown in Table 4 below.

[0537] Table 4

[0538] Referring to Figure 11, which is a signaling interaction diagram of another route advertisement method provided by an embodiment of the present application, the method 500 shown in Figure 11 can be applied to the application scenario shown in Figure 1a or the application scenario shown in Figure 1b.

[0539] Regarding the site edge and gateway in method 500, reference may be made to the description of the site edge and gateway in method 400, which will not be repeated here.

[0540] The method 500 shown in FIG11 may include the following S501 - S504 .

[0541] S501: The gateway obtains route 3', where route 3' is a BGP LS route and includes gateway information 3.

[0542] In the embodiment of the present application, the gateway may generate the route 3' based on its own information 3.

[0543] In one example, before executing S501, a GRE tunnel can be established between the gateway and the site edge, and then a BGP session is established between the site edge and the gateway using the GRE tunnel address, and the BGP LS address family is enabled between the site edge and the gateway. In addition, the gateway enables the BGP egress peer engineering (EPE) function. In this case, the gateway can allocate SID3 for the adjacency relationship (BGP session) between the gateway and the site. The SID3 can be an SRv6 END.X SID or an adj-SID.

[0544] Regarding BGP EPE, it is important to note that BGP EPE can allocate BGP peer SIDs for inter-domain paths. Peer SIDs can be directly passed to the network controller via BGP-LS extensions. For forwarding devices that do not have a BGP-LS neighbor relationship with the controller, peer SID information can first be passed to the BGP neighbor via BGP-LS, and then the BGP neighbor can pass it to the network controller via BGP-LS. BGP EPE can allocate peer-node SIDs and peer-adj SIDs for peers. Among them:

[0545] A peer-node SID identifies a peer node. Each BGP session is assigned a peer-node SID. For an External Border Gateway Protocol (EBGP) neighbor established over a loopback interface, which may have multiple corresponding physical links, the peer-node SID for that neighbor will correspond to multiple outbound interfaces.

[0546] The peer-adj SID indicates an adjacency to a peer. For EBGP adjacencies established over loopback interfaces, which may have multiple corresponding physical links, each adjacency is assigned a peer-adj SID. The packets are forwarded over the specified link (corresponding to the specified outbound interface).

[0547] In one example, the route 3' may include a TLV1, which indicates that the route 3' is used to advertise gateway information. In a specific example, the TLV1 may be a role announcement TLV, which indicates that the role of the device publishing the route 3' is a gateway. In another specific example, the TLV1 may be a gateway information indication TLV, whose type field indicates that the device publishing the route 3' is a gateway.

[0548] The role announcement TLV can be understood in conjunction with Figure 12a, which is a schematic diagram of the structure of a role announcement TLV provided in an embodiment of the present application. As shown in Figure 12a, the role announcement TLV includes: a type field, a length field, and a device role field. Among them:

[0549] The Type field indicates that the TLV is a role announcement TLV.

[0550] The length field indicates the length of the device role field.

[0551] The device role field carries the device role. For example, when the value of the device role field is 1, it indicates that the device role is gateway.

[0552] As described above for SID3, in one example, the information 3 may include SID3 and / or SID4. In this case, the route 3' may include TLV2 and TLV3, where TLV2 is used to carry SID3 and TLV3 is used to carry SID4.

[0553] In one example, the TLV2 may be an adjacency SID TLV. The structure of the adjacency SID TLV may be understood in conjunction with FIG12B, which is a schematic diagram of the structure of an adjacency SID TLV provided in an embodiment of the present application. As shown in FIG12B, the adjacency SID TLV includes: a type field, a length field, and an adjacency SID field. Among them:

[0554] The Type field indicates that the TLV is an adjacency SID TLV.

[0555] The length field indicates the length of the adjacency SID field.

[0556] The adjacency SID field carries the SID assigned by the gateway to the adjacency relationship between the gateway and the site edge. In an embodiment of the present application, the adjacency SID field can be used to carry the aforementioned SID3.

[0557] In yet another example, when SID3 is an SRv6 End.X SID, the TLV2 may be an SRv6 End.X SID TLV.

[0558] In one example, the TLV3 may be a node SID TLV. The structure of the node SID TLV can be understood in conjunction with FIG12c, which is a schematic diagram of the structure of a node SID TLV provided in an embodiment of the present application. As shown in FIG12c, the node SID TLV includes: a type field, a length field, and a node SID field. Among them:

[0559] The type field indicates that the TLV is a node SID TLV.

[0560] The length field indicates the length of the node SID field.

[0561] The node SID field carries the gateway SID. In an embodiment of the present application, the node SID field can be used to carry the aforementioned SID4.

[0562] S502: The gateway notifies the route 3' to the site edge, and the site edge accesses the backbone network through the gateway.

[0563] S503: The site edge receives the route 3' advertised by the gateway.

[0564] S504: The site edge obtains the binding relationship 3 between the site edge and the gateway according to the route 3'.

[0565] After obtaining route 3', the gateway can advertise route 3' to the site edge. In return, the site edge can receive route 3' advertised by the gateway. After receiving route 3', the site edge can parse route 3' to obtain binding relationship 3 between the site edge and the gateway, so that the end-to-end path can be determined based on binding relationship 3.

[0566] In one example, after receiving the route 3', the site edge may also determine the routing priority of the gateway. For example, the site edge may determine the routing priority of the gateway based on its own configured routing policy or in combination with the load of the gateway.

[0567] In another example, after receiving the route 3', the site edge may also determine the load sharing weight of the gateway. For example, the site edge may determine the load sharing weight of the gateway based on its own configured load sharing policy or in combination with the load condition of the gateway.

[0568] In one example, the route 3' may also include intermediate gateway information, and the intermediate gateway information indicates at least one intermediate gateway between the backbone network ingress device and the backbone network egress device in the backbone network, so that the site edge can perform path orchestration based on the intermediate gateway. In one example, the site edge can determine the gateway constraints that the end-to-end path needs to follow based on business requirements and the intermediate gateway. The gateway constraints mentioned here include gateways that need to be passed through and / or gateways that need to be bypassed. In a specific example, when the site edge performs path orchestration based on business requirements, it can determine the gateways that the end-to-end path needs to pass through and / or the gateways that need to be bypassed from the intermediate gateways, so that the determined end-to-end path meets business requirements.

[0569] In one example, the intermediate gateway information may be carried by a BGP path attribute. In a specific example, the intermediate gateway information may be carried by Metadata Path Attribute 4. For example, Metadata Path Attribute 4 may include at least one intermediate gateway sub-TLV, which is used to carry information about the intermediate gateway. One intermediate gateway sub-TLV is used to carry information about one intermediate gateway.

[0570] In an embodiment of the present application, for a particular intermediate gateway, the information of the intermediate gateway includes at least the endpoint address (e.g., IP address) of the intermediate gateway. Optionally, the information of the intermediate gateway may also include the SID of the intermediate gateway. The SID of the intermediate gateway may be an SRv6 END.SID or a node SID.

[0571] Regarding the intermediate gateway sub-TLV, please refer to the description of Figure 10 above, and no repetition will be given here.

[0572] In some examples, for a certain site edge, it may correspond to multiple gateways. In this case, each gateway may send a BGP LS route to the site edge so that the site edge obtains a binding relationship between itself and the gateway. For example, in the scenario shown in Figure 1a, site edge1 is multi-homed to GW1 and GW3, then GW1 may send a BGP LS route carrying GW1's information to site edge1, and GW3 may send a BGP LS route carrying GW3's information to site edge1. For another example, in the scenario described in Figure 1b, site edge2 is dual-homed to POP4 and POP9. Then POP4 may send a BGP LS route carrying POP4's information to site edge2, and POP9 may send a BGP LS route carrying POP9's information to site edge2.

[0573] Taking the site edge1 shown in FIG1a as an example, after GW1 and GW3 both send BGP LS routes to the site edge1, the site edge1 can obtain the binding relationship shown in Table 4 above.

[0574] Using method 500, the gateway and site edge do not need to enable the SD-WAN address family, but only need to enable the BGP-LS address family.

[0575] After executing one of the above methods 100-300 and one of the above methods 400-500, site edge1 can orchestrate an end-to-end path based on the locally stored binding relationship between the site edge and the gateway.

[0576] Next, the specific implementation method of orchestrating an end-to-end path at site edge1 is introduced with reference to a specific example.

[0577] Taking the scenario shown in Figure 1b as an example, the binding relationship between the site edge and the gateway stored locally at site edge1 can be shown in Table 5 below:

[0578] Table 5

[0579] In Table 5:

[0580] "*-IP" indicates the IP address of "*". For example, edge2-IP indicates the IP address of site edge2.

[0581] "ab-SID" indicates the SID of the adjacency relationship between a and b. For example, "edge2-POP4-SID" indicates the SID of the adjacency relationship between edge2 and POP4.

[0582] "*-SID" indicates the SID of "*". For example, POP4-SID indicates the SID of POP4.

[0583] "*-priority" indicates the routing priority of "*". For example, POP4-priority indicates the routing priority of POP4.

[0584] *-weight indicates the load sharing weight of *. For example, POP4-weight indicates the load sharing weight of POP4.

[0585] In an example, after receiving the service route (eg, VPN route) published by the site edge1, the site edge2 can orchestrate an end-to-end path for the service route.

[0586] In a specific example, the site edge2 can determine the end-to-end path 1 from the site edge1 to edge2 based on the binding relationship shown in the first row and the binding relationship shown in the third row of Table 5. The end-to-end path 1 includes POP1 and POP4, that is, the end-to-end path 1 can be: edge1-POP1-POP4-edge2.

[0587] In another specific example, the site edge2 can determine the end-to-end path 2 from the site edge1 to edge2 based on the binding relationship shown in the second row and the binding relationship shown in the third row of Table 5. The end-to-end path 2 includes POP1 and POP9, that is, the end-to-end path 2 can be: edge1-POP1-POP9-edge2.

[0588] In one example, after site edge1 orchestrates the aforementioned end-to-end path 1 and end-to-end path 2, it can select one of these two end-to-end paths as the path for actually forwarding service traffic. For example, based on the routing priorities of POP4 and POP9, site edge1 can determine the end-to-end path corresponding to the POP with the higher routing priority as the path for actually forwarding service traffic. For example, if POP4's routing priority is higher than POP9's routing priority, end-to-end path 1 can be determined as the path for actually forwarding service traffic.

[0589] In another example, after site edge1 orchestrates the aforementioned end-to-end path 1 and end-to-end path 2, it can set these two end-to-end paths as primary and backup paths. For example, based on the routing priorities of POP4 and POP9, site edge1 can determine the end-to-end path corresponding to the POP with the higher routing priority as the primary path, and the end-to-end path corresponding to the POP with the lower routing priority as the backup path. For example, if POP4 has a higher routing priority than POP9, end-to-end path 1 can be determined as the primary path, and end-to-end path 2 can be determined as the backup path.

[0590] In another example, after site edge 1 orchestrates the aforementioned end-to-end path 1 and end-to-end path 2, it can set these two end-to-end paths as load sharing paths. E2E path 1 and end-to-end path 2 can be set as equal-cost load sharing paths or unequal-cost load sharing paths, which is not specifically limited in this embodiment of the present application.

[0591] As an example, the load sharing weight of end-to-end path 1 can be determined based on the load sharing weight of POP4, and the load sharing weight of end-to-end path 2 can be determined based on the load sharing weight of POP9. For example, the load sharing weight of end-to-end path 1 can be equal to the load sharing weight of POP4, and the load sharing weight of end-to-end path 2 can be equal to the load sharing weight of POP9. In this case, when the load sharing weight of POP4 is equal to the load sharing weight of POP9, end-to-end path 1 and end-to-end path 2 can achieve equal load sharing. When the load sharing weight of POP4 is not equal to the load sharing weight of POP9, end-to-end path 1 and end-to-end path 2 can achieve unequal load sharing.

[0592] As another example, the load sharing weights of end-to-end path 1 and end-to-end path 2 can also be set by edge1, independent of the load sharing weights of POP4 and POP9, which is not specifically limited in the embodiment of the present application.

[0593] Similarly, in the scenario shown in Figure 1a, site edge1 can orchestrate four end-to-end paths based on the locally stored binding relationship between site edges and gateways. They are:

[0594] End-to-end path: Site edge1-GW1-GW2-edge2.

[0595] End-to-end path: Site edge1-GW1-GW4-edge2.

[0596] End-to-end path: Site edge1-GW3-GW2-edge2.

[0597] End-to-end path: Site edge1-GW3-GW4-edge2.

[0598] Regarding the specific implementation method of orchestrating four end-to-end paths based on the locally stored binding relationship between the site edge and the gateway in Figure 1a, the principle can be referred to the description of the end-to-end path 1 and end-to-end path 2 orchestrated by site edge 1 above, and will not be repeated here.

[0599] Currently, when service traffic needs to be transmitted across a backbone network, service-related configuration, such as VPN configuration, must be performed within the backbone network. This inefficiency leads to low service provisioning efficiency. Especially when the backbone network includes multiple heterogeneous network domains, service VPN instances must be planned at the boundary interconnection points between the intermediate heterogeneous networks to perform service re-addressing, forwarding, and isolation. Furthermore, the backbone network's need to be service-aware also impacts its scalability.

[0600] Accordingly, during the traffic forwarding phase, network devices in the backbone network also need to integrate VPN configurations to forward traffic, resulting in low traffic forwarding efficiency. For example, in the scenario shown in Figure 1b, when traffic arrives at POP1, POP1 needs to integrate the VPN instance to determine the traffic forwarding path and forward it. When the traffic is forwarded to POP2, POP3, and POP4, POP2, POP3, and POP4 also need to integrate the VPN configuration to further determine the traffic forwarding path and forward it.

[0601] In order to solve the above problems, an embodiment of the present application provides a method for forwarding traffic. Next, the traffic forwarding method is introduced in conjunction with the accompanying drawings.

[0602] See Figure 13, which is a signaling interaction diagram of a method for forwarding traffic provided in an embodiment of the present application. The method 600 shown in Figure 13 can be applied to the application scenario shown in Figure 1a, the application scenario shown in Figure 1b, and the application scenario shown in Figure 1c.

[0603] When the method 600 is applied to the application scenario shown in Figure 1a: the site edge1 in the method 600 can correspond to the site edge1 shown in Figure 1a; the site edge2 in the method 600 can correspond to the site edge2 shown in Figure 1a; the backbone network entry device 1 in the method 600 can correspond to the GW1 shown in Figure 1a; the backbone network exit device 1 in the method 600 can correspond to the GW2 or GW4 shown in Figure 1a.

[0604] When the method 600 is applied to the application scenario shown in Figure 1b: the site edge1 in the method 600 can correspond to the site edge1 shown in Figure 1b; the site edge2 in the method 600 can correspond to the site edge2 shown in Figure 1b; the backbone network entry device 1 in the method 600 can correspond to the POP1 shown in Figure 1a; the backbone network exit device 1 in the method 600 can correspond to the POP4 or POP9 shown in Figure 1b.

[0605] When the method 600 is applied to the application scenario shown in Figure 1c: the site edge1 in the method 600 can correspond to the site edge1 shown in Figure 1c; the site edge2 in the method 600 can correspond to the site edge2 shown in Figure 1c; the backbone network entry device 1 in the method 600 can correspond to POP1 shown in Figure 1c; the backbone network exit device 1 in the method 600 can correspond to POP4 or POP9 shown in Figure 1c.

[0606] The method 600 may, for example, include the following S601 - S606 .

[0607] S601: Site edge1 receives service packet 1.

[0608] In one example, the site edge may receive a service message 1 from a user device, which may be a terminal device or a server, and is not specifically limited in this embodiment of the application. In one example, the service message 1 may include a source address, a destination address, and a payload.

[0609] S602: Site edge1 encapsulates the path information of end-to-end path 1 in the outer layer of service message 1 to obtain service message 2. The input endpoint of end-to-end path 1 is site edge1, and the output endpoint of end-to-end path 1 is site edge2. End-to-end path 1 includes backbone network ingress device 1 and backbone network egress device 1. Site edge1 accesses the backbone network through backbone network ingress device 1, and site edge2 accesses the backbone network through backbone network egress device 1. The path information of end-to-end path 1 includes: information 1 identifying backbone network ingress device 1, and information 2 identifying backbone network egress device 1.

[0610] In an embodiment of the present application, site edge 1 accesses the backbone network through backbone network ingress device 1, and site edge 2 accesses the backbone network through backbone network egress device 1. In one example, site edge 1 can access backbone network ingress device 1 via the internet. In another example, site edge 1 can access backbone network ingress device 1 via an SD-WAN tunnel. Similarly, in one example, site edge 2 can access backbone network egress device 1 via the internet. In another example, site edge 2 can access backbone network egress device 1 via an SD-WAN tunnel.

[0611] In one example, after receiving service message 1, site edge1 may encapsulate path information of end-to-end path 1 in the outer layer of service message 1 to obtain service message 2. After the outer layer of service message 1 encapsulates the path information, service message 1 belongs to the payload of service message 2.

[0612] In another example, when encapsulating service message 1, in addition to encapsulating the aforementioned path information within the outer layer of service message 1, service intent information can also be encapsulated within the outer layer of service message 1 to obtain service message 2, which includes both the path information and service intent information. In this way, after forwarding service message 2, the forwarding device that receives service message 2 can select a corresponding path for forwarding based on the service intent information when further forwarding service message 2, thereby satisfying the service intent and, accordingly, improving the quality of service provided to the service.

[0613] The service intent information in the embodiments of the present application may include one or more information indicating the service intent. In one example, the service intent information may include quality of service parameters, including but not limited to one or more parameters such as latency, packet loss, jitter, bandwidth utilization, and bit error rate. In another example, the service intent parameters may include gateway constraint information that must be satisfied by the end-to-end path from site edge1 to site edge2, including but not limited to gateways that must be passed through and / or gateways that must be bypassed.

[0614] In one specific example, a metadata field can be encapsulated in the outer layer of service message 1, and the metadata field is used to carry the service intent information. The metadata field can be carried, for example, via an extension header. In another specific example, the service intent information can be carried using available fields in the outer layer of service message 2.

[0615] In one example, before encapsulating the aforementioned path information in the outer layer of the service message 1, the site edge 1 can determine the path information of the end-to-end path 1 for transmitting the service message 1 based on the service message 1. As an example, the site edge can determine the path information of the end-to-end path 1 based on the destination address of the service message 1.

[0616] In a specific example, the site edge1 may pre-store a mapping relationship between the destination address of the service message 1 and the aforementioned path information. The site edge1 may match the mapping relationship according to the destination address of the service message 1 to obtain the path information.

[0617] In another specific example, the site edge1 can determine the next hop for forwarding the service message according to the destination address of the service message 1. Specifically, the site edge1 can query the service table entry according to the destination address of the service message 1 and determine that the next hop for forwarding the service message 1 is the site edge2. Furthermore, the IP address of the site edge2 is used to iterate SR policy1 to obtain the path information of the end-to-end path. In one example, the IP address of the site edge2 can be used to match the destination addresses of multiple SR policies. When the IP address of the site edge2 successfully matches the destination address of the SR policy1, it is determined that the IP address of the site edge2 is iterated to SR policy1. Accordingly, the path information indicated by the SR policy1 can be determined as the path information of the end-to-end path 1.

[0618] In one example, the SR policy 1 may be an SRv6 policy. In this case, the end-to-end path 1 may be an SRv6 tunnel.

[0619] In another example, the SR policy 1 may be an MPLS SR policy. In this case, the end-to-end path 1 may be an SR-MPLS TE policy.

[0620] In one example, the end-to-end path 1 may be pre-orchestrated by site edge1. In this case, the site edge1 may further orchestrate the end-to-end path 1 before receiving the service message 1. In a specific example, the service message 1 is used to carry VPN services. The site edge1 may, based on the VPN services, orchestrate the end-to-end path 1 between site edge1 and site edge2 in combination with the aforementioned backbone network entry device 1 and backbone network exit device 1 as needed. As an example, the site edge1 may orchestrate the end-to-end path for the VPN route after receiving the VPN route including the destination prefix announced by site edge2. In a specific example, the site edge1 may orchestrate the end-to-end path 1 for the VPN route based on the binding relationship 1 between site edge1 and backbone network entry device 1, and the binding relationship 2 between site edge2 and backbone network exit device 1. When method 600 is applied to the application scenario shown in FIG. 1 b or FIG. 1 c, the destination prefix may, for example, be the network prefix corresponding to the corporate headquarters.

[0621] In one example, if the end-to-end path is an SRv6 tunnel, service packet 2 may include an IPv6 header and an SRH. The aforementioned information 1 and information 2 may be carried in the SRH. Furthermore, the destination address of the IPv6 header points to backbone network ingress device 1, so that site edge 1 forwards service packet 2 to backbone network ingress device 1 based on the destination address of the IPv6 header. In one example, the destination address of the IPv6 header may be END.SID1 of the backbone network ingress device.

[0622] In one example, when the end-to-end path is an SRv6 tunnel, the aforementioned information 1 may be END.SID1 of the backbone network ingress device, and the aforementioned information 2 may be END.SID2 of backbone network egress device 1. In this case, information 1 also includes the IPv6 address of site edge2. Accordingly, the aforementioned SRH may also include the IPv6 address of site edge2. In this case, the SRH may indicate the path from backbone network ingress device 1 to site edge2.

[0623] In another example, when the end-to-end path is an SRv6 tunnel, the aforementioned information 1 may be END.SID1 of the backbone network ingress device, and the aforementioned information 2 may be END.XSID assigned by backbone network egress device 1 for the adjacency relationship between backbone network egress device 1 and site edge 2. In this case, the SRH may also indicate the path from backbone network ingress device 1 to site edge 2.

[0624] In one example, END.SID1 can be used to indicate a new packet forwarding operation. In this case, backbone network ingress device 1 can determine how to forward service packet 2 based on END.SID1, without having to use VPN information to determine how to forward service packet 2. In a specific example, the operation associated with END.SID1 includes matching the overly SRv6 policy from backbone network ingress device 1 to backbone network egress device 1 based on the next-hop SID of END.SID1. As described above regarding path information, in one example, the next-hop SID of END.SID1 can be END.SID2. In this case, the operation associated with END.SID1 includes matching the overly SRv6 policy from backbone network ingress device 1 to backbone network egress device 1 based on END.SID2. In another example, the next-hop SID of END.SID1 can be END.X SID. In this case, the operation associated with END.SID1 includes matching the overly SRv6 policy from backbone network ingress device 1 to backbone network egress device 1 based on END.X SID.

[0625] In another specific example, if the service message 2 includes service intent information, the operation associated with END.SID1 includes: matching the overly SRv6 policy from backbone network ingress device 1 to backbone network egress device 1 based on the next-hop SID of END.SID1 and the service intent information. In this case, when forwarding service message 2, the backbone network ingress device 1 can also determine the corresponding overly SRv6 policy in combination with the service intent information, so that the determined overly SRv6 policy satisfies the service intent as much as possible, thereby improving the service quality provided to the service as much as possible. When the next-hop SID of END.SID1 is END.SID2, the operation associated with END.SID1 includes: matching the overly SRv6 policy from backbone network ingress device 1 to backbone network egress device 1 based on END.SID2 and the service intent information. When the next hop SID of the END.SID1 is the END.X SID, the operation associated with the END.SID1 includes: matching an overly SRv6 policy from the backbone network ingress device 1 to the backbone network egress device 1 according to the END.X SID and the service intent information.

[0626] In one example, when the end-to-end path is an SR-MPLS TE policy, the service message 2 may include an MPLS label stack, and the aforementioned information 1 and information 2 may be carried in the MPLS label stack. In this scenario, the information 1 may be the node SID1 of the backbone network ingress device, and the information 2 may be the node SID2 of the backbone network egress device 1. For this case, the path information also includes the adj-SID assigned by the backbone network egress device 1 for the adjacency relationship between the backbone network egress device 1 and the site edge2, and accordingly, the MPLS label stack also includes the adj-SID. For this case, the node SID1, node SID2, and adj-SID in the MPLS label stack may indicate the path from the backbone network ingress device 1 to the site edge2.

[0627] In one example, the node SID1 can be used to indicate a new message forwarding operation. In this case, the backbone network ingress device 1 can determine how to forward the service message 2 based on the node SID1, without combining VPN information to determine how to forward the service message 2. In a specific example, the operation associated with the node SID1 includes: matching the overly SR-MPLS TE policy from the backbone network ingress device 1 to the backbone network egress device 1 according to the next-hop SID of the node SID1. As can be seen from the previous description of the path information, the next-hop SID of the node SID1 can be node SID2. In this case, the operation associated with the node SID1 includes: matching the overly SR-MPLS TE policy from the backbone network ingress device 1 to the backbone network egress device 1 according to the node SID2.

[0628] In another specific example, if the service message 2 includes service intent information, the operation associated with the node SID1 includes: matching the overly SR-MPLS TE policy from the backbone network ingress device 1 to the backbone network egress device 1 according to the next-hop SID of the node SID1 and the service intent information. In this case, when forwarding the service message 2, the backbone network ingress device 1 can also determine the corresponding overly SR-MPLS TE policy in combination with the service intent information, so that the determined overly SR-MPLS TE policy meets the service intent as much as possible, thereby improving the service quality provided to the service as much as possible. When the next-hop SID of the node SID1 is node SID2, the operation associated with the node SID1 includes: matching the overly SR-MPLS TE policy from the backbone network ingress device 1 to the backbone network egress device 1 according to the node SID2 and the service intent information.

[0629] In an example, the end-to-end path 1 may be a tunnel based on GRE protocol encapsulation. In this case, the service message may be encapsulated using GRE.

[0630] In a specific example, if the end-to-end path 1 is an SRv6 tunnel, the service message 2 can be encapsulated using SRv6 over GRE. For this case, the encapsulation format of the service message 2 can be understood with reference to Figure 14a, which is a structural diagram of an SRv6 over GRE encapsulation provided in an embodiment of the present application. As shown in Figure 14a, the service message 2 includes: an outer IP header, a UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, wherein the payload includes the aforementioned service message 1; the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the service message 1. The VPN identifier is carried in the inner GRE encapsulation. When the service message 2 is transmitted in the backbone network, the equipment in the backbone network does not parse the VPN identifier (VPN identifier, VNI), that is, the backbone network does not perceive the VPN. In an example, a metadata field may also be included between the SRH and the inner GRE encapsulation. In another example, the service message 2 may further include a security check field, such as an Encapsulating Security Protocol (ESP) field, which is not described in detail here.

[0631] In another specific example, if the end-to-end path 1 is an SR-MPLS TE policy, the service message 2 can be encapsulated using MPLS over GRE. In this case, the encapsulation format of the service message 2 can be understood with reference to Figure 14b, which is a structural diagram of an MPLS over GRE encapsulation provided in an embodiment of the present application. As shown in Figure 14b, the service message 2 includes: an outer IP header, a UDP header, an outer GRE encapsulation, an MPLS label stack, an inner GRE encapsulation, and a payload, wherein the payload includes the aforementioned service message 1; the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the service message 1. The VPN identifier is carried in the inner GRE encapsulation. When the service message 2 is transmitted in the backbone network, the equipment in the backbone network does not parse the VPN identifier, that is, the backbone network does not perceive the VPN. In one example, a metadata field may be included between the MPLS label stack and the inner GRE encapsulation. In another example, the service message 2 may also include a security check field, such as an ESP field, which is not described in detail here.

[0632] In another example, the end-to-end path 1 may be a tunnel based on GENEVE protocol encapsulation. In this case, the service message may be encapsulated using GENEVE.

[0633] In a specific example, if the end-to-end path 1 is an SRv6 tunnel, the service message 2 can be encapsulated using SRv6 in GENEVE. In this case, the encapsulation format of the service message 2 can be understood with reference to Figure 14c, which is a schematic diagram of the structure of an SRv6 in GENEVE encapsulation provided in an embodiment of the present application. As shown in Figure 14c, the service message 2 includes: an outer IP header, a UDP header, a GENEVE encapsulation, an SRH, and a payload, wherein the payload includes the aforementioned service message 1; the GENEVE encapsulation includes a VPN identifier for the VPN service carried by the service message 1. In one example, a metadata field may also be included between the SRH and the payload. In another example, the service message 2 may also include a security check field, such as an ESP field, which is not described in detail here. Of course, the service message 2 may also be encapsulated using SRv6 over GENEVE. The difference between SRv6 over GENEVE encapsulation and SRv6 in GENEVE encapsulation is that the service message 2 encapsulated using SRv6 over GENEVE also includes an IPv6 header. For further information, see Figure 14d, which shows a schematic diagram of the structure of an SRv6 over GENEVE encapsulation according to an embodiment of the present application. Compared to the SRv6 in GENEVE encapsulation shown in Figure 14c, the encapsulation structure shown in Figure 14d also includes an IPv6 header between the GENEVE encapsulation and the SRH. While SRv6 over GENEVE encapsulation has a higher encapsulation overhead than SRv6 in GENEVE encapsulation, SRv6 over GENEVE encapsulation complies with the standard SRv6 encapsulation format.

[0634] In another specific example, if the end-to-end path 1 is an SR-MPLS TE policy, the service message 2 can be encapsulated using MPLS in GENEVE. For this case, the encapsulation format of the service message 2 can be understood with reference to Figure 14e, which is a structural diagram of an MPLS in GENEVE encapsulation provided in an embodiment of the present application. As shown in Figure 14e, the service message 2 includes: an outer IP header, a UDP header, a GENEVE encapsulation, an MPLS label stack and a payload, wherein the payload includes the aforementioned service message 1; the GENEVE encapsulation includes the VPN identifier of the VPN service carried by the service message 1. In one example, a metadata field may also be included between the MPLS label stack and the payload. In another example, the service message 2 may also include a security check field, such as an ESP field, which is not described in detail here.

[0635] S603: Site edge1 sends service packet 2 through end-to-end path 1.

[0636] S604: Backbone network ingress device 1 receives service packet 2 from site edge1.

[0637] S605: Backbone network ingress device 1 processes service message 2 according to information 1 to obtain service message 3.

[0638] After receiving service packet 2, site edge 1 can forward service packet 2. In one example, the source address of the outer IP header of service packet 2 is the IP address of site edge 1, and the destination address is the IP address of backbone network ingress device 1. Site edge 1 forwards service packet 2 to backbone network ingress device 1 based on the destination address in the outer IP header.

[0639] Backbone network ingress device 1 may receive service message 2 from site edge 1 , further parse service message 2 , and process service message 2 using information 1 in message 2 to obtain service message 3 .

[0640] As mentioned above, in one example, the information 1 may be END.SID1. In this case:

[0641] In one example, the backbone network ingress device 1 can match the overly SRv6 policy between the backbone network ingress device 1 and the backbone network egress device 1 based on the next-hop SID of END.SID1 in the SRH of service packet 2. In one example, the backbone network ingress device 1 can use the next-hop SID of END.SID1 to match the destination address of the overly SRv6 policy. When the destination address of overly SRv6 policy1 successfully matches the next-hop SID, it is determined that the match of overly SRv6 policy1 is successful. In a specific example, the backbone network ingress device 1 can use END.SID2 to match the overly SRv6 policy1. In another specific example, the backbone network ingress device 1 can use the aforementioned END.X SID to match the overly SRv6 policy1. After backbone network ingress device 1 matches and obtains overly SRv6 policy 1, it can re-encapsulate service message 2 using overly SRv6 policy 1. For example, backbone network ingress device 1 can insert a new SRH into service message 2 to carry overly SRv6 policy 1, thereby obtaining service message 3. In one example, the SRH carrying overly SRv6 policy 1 can be located outside the SRH carrying information 1 and information 2.

[0642] In another example, if service packet 2 includes service intent information, backbone network ingress device 1 can match the overly SRv6 policy between backbone network ingress device 1 and backbone network egress device 1 based on the next-hop SID of END.SID1 in the SRH of service packet 2 and the service intent information. In one example, backbone network ingress device 1 can use the next-hop SID of END.SID1 to match the destination address of the overly SRv6 policy to obtain at least one overly SRv6 policy that matches the next-hop SID of END.SID1, and then determine, from the at least one overly SRv6 policy, an overly SRv6 policy2 that satisfies the service intent information. In a specific example, backbone network ingress device 1 can use END.SID2 and the service intent information to match overly SRv6 policy2. In another specific example, backbone network ingress device 1 can use the aforementioned END.X SID and the service intent information to match overly SRv6 policy2. After backbone network ingress device 1 matches and obtains overly SRv6 policy 2, it can re-encapsulate service packet 2 using overly SRv6 policy 2 to obtain service packet 3. For example, backbone network ingress device 1 can insert a new SRH into service packet 2 to carry overly SRv6 policy 2, thereby obtaining service packet 3. In one example, the SRH carrying overly SRv6 policy 2 can be located outside the SRH carrying information 1 and information 2.

[0643] As mentioned above, in one example, the information 1 may be the node SID1. In this case:

[0644] In one example, the backbone network ingress device 1 can match the overly SR-MPLS TE policy between the backbone network ingress device 1 and the backbone network egress device 1 based on the next-hop SID of node SID1 in the MPLS label stack of service packet 2. In one example, the backbone network ingress device 1 can use the next-hop SID of node SID1 to match the destination address of the overly SR-MPLS TE policy. When the destination address of overly SR-MPLS TEpolicy1 successfully matches the next-hop SID, it is determined that the matching of overly SR-MPLS TEpolicy1 is successful. In a specific example, the backbone network ingress device 1 can use node SID2 to match the overly SR-MPLS TE policy1. After backbone network ingress device 1 matches and obtains overly SR-MPLS TE policy 1, it can use the overly SR-MPLS TE policy 1 to re-encapsulate service message 2. For example, backbone network ingress device 1 can replace node SID 1 and node SID 2 in the MPLS label stack in service message 2 with the overly SR-MPLS TE policy 1 to obtain service message 3.

[0645] In another example, if service packet 2 includes service intent information, the backbone network ingress device 1 can match the overly SR-MPLS TE policy between the backbone network ingress device 1 and the backbone network egress device 1 based on the next-hop SID of node SID1 in the MPLS label stack of service packet 2 and the service intent information. In one example, the backbone network ingress device 1 can use the next-hop SID of node SID1 to match the destination address of the overly SR-MPLS TE policy to obtain at least one overly SR-MPLS TE policy that matches the next-hop SID of node SID1, and then determine the overly SR-MPLS TE policy 2 that meets the service intent information from the at least one overly SR-MPLS TE policy. After backbone network ingress device 1 matches and obtains overly SR-MPLS TE policy 2, it can use the overly SR-MPLS TE policy 2 to re-encapsulate service packet 2 to obtain service packet 3. For example, the backbone network ingress device 1 may replace the node SID 1 and the node SID 2 in the MPLS label stack in the service packet 2 with the overly SR-MPLS TE policy 2 to obtain the service packet 3 .

[0646] S606: Backbone network ingress device 1 sends service message 3 to backbone network egress device 1.

[0647] After receiving service packet 3, backbone network ingress device 1 can send service packet 3 to backbone network egress device 1. In one example, backbone network ingress device 1 can send service packet 3 to backbone network egress device 1 based on the aforementioned overly SRv6 policy 1 or overly SRv6 policy 2. In another example, backbone network ingress device 1 can send service packet 3 to backbone network egress device 1 based on the aforementioned overly SR-MPLS TE policy 1 or overly SR-MPLS TE policy 2.

[0648] As can be seen from the above description, using the method 600 provided in the embodiment of the present application, site edge 1 can orchestrate an end-to-end path 1 across the backbone network, eliminating the need for backbone network devices to determine the transmission path based on VPN configuration. This eliminates the need for the backbone network to be aware of the service, thereby improving the forwarding efficiency of service traffic. Furthermore, since the backbone network does not need to be aware of the service, there is no need to perform service-related configuration on the backbone network devices, thereby improving the efficiency of service provisioning and, correspondingly, improving the scalability of the backbone network.

[0649] In one example, site edge1 can be dual-homed to backbone network entry device 1 and backbone network entry device 2. In other words, in addition to accessing the backbone network through backbone network entry device 1, site edge1 can also access the backbone network through backbone network entry device 2. Site edge2 can be dual-homed to backbone network exit device 1 and backbone network exit device 2. In other words, in addition to accessing the backbone network through backbone network exit device 1, site edge2 can also access the backbone network through backbone network exit device 2. For this case, the site edge1 can also arrange an end-to-end path 2 from site edge1 to site edge2, and the end-to-end path 2 includes the ingress endpoint of site edge1 and the egress endpoint of site edge2, and the end-to-end path 2 includes the backbone network ingress device 2 and backbone network exit device 2. For this case:

[0650] Site edge 1 may also receive service message 4, encapsulate path information of end-to-end path 2 in the outer layer of service message 4 to obtain service message 5, and send service message 5 through end-to-end path 2. The path information of end-to-end path 2 includes information 3 identifying backbone network ingress device 2 and information 4 identifying backbone network egress device 2.

[0651] For the path information of end-to-end path 2, please refer to the previous description of the path information of end-to-end path 1. For the specific implementation of site edge1 "encapsulating the path information of end-to-end path 2 in the outer layer of business message 4 to obtain business message 5", please refer to the specific description of S602 in method 600, which will not be repeated here.

[0652] After site edge 1 sends service packet 5 via end-to-end path 2, backbone network ingress device 2 may receive service packet 5 from site edge 1, further process service packet 5 based on information 3 to obtain service packet 6, and further forward service packet 6. Regarding the processing of service packet 5 by backbone network ingress device 2, reference may be made to the processing of service packet 2 by site edge 1 in method 600, and will not be repeated here.

[0653] The above introduces the method for forwarding traffic provided in the embodiment of the present application. Next, in combination with the application scenarios shown in Figures 1b and 1c, taking the end-to-end path between site edge1 and site edge2 as an end-to-end tunnel using GRE encapsulation as an example, the method for forwarding traffic provided in the embodiment of the present application is illustrated.

[0654] First, the solution of the embodiment of the present application is introduced in conjunction with the application scenario shown in Figure 1b.

[0655] See Figure 15a, which is a schematic diagram of a scenario of a traffic forwarding method provided by an embodiment of the present application. Figure 15a shows the encapsulation format of the service traffic transmitted in the network when the solution provided by an embodiment of the present application is applied to the scenario shown in Figure 1b. In the scenario shown in Figure 15a, the end-to-end path between site edge1 and site edge2 is an SRv6 tunnel. The specific process of traffic forwarding is as follows:

[0656] At site edge1, a service packet from an enterprise user accessing headquarters arrives at branch site edge1. The source address of the service packet is the enterprise user's IP address (client-ip), and the destination address is the headquarters' IP address (server-ip). Site edge1 queries the server-ip route and determines that the next hop is site edge2's IP address, system-ip2. Based on the SRv6 policy for system-ip2 (the path list is: END.SID1, END.SID2, system-ip2), site edge1 encapsulates the service packet with an IPv6 header and SRH, along with service intent information. It then continues forwarding the packet based on the SRv6 forwarding next hop, END.SID1. END.SID1 iterates over the SDWAN tunnel, encapsulating SDWAN tunnel link information (source address (SA) = tnp1, destination address (DA) = tnp2), and sends the packet to POP1. Where: tnp1 is the IP address of the port used by site edge1 to communicate with POP1, and tnp2 is the IP address of the port used by POP1 to communicate with site edge1.

[0657] POP1 decapsulates the outer SDWAN tunnel of the received packet and searches the local SID table for the IPv6 DA (END.SID1). The associated operation for END.SID1 is to match the SR policy based on the next-hop SID and service intent information. If a match is found based on the tunnel matching policy, a new SRH (containing the SR list: END.SID3 and END.SID2) is inserted into the packet. The IPv6 header DA is replaced with END.SID3, and the route is searched and forwarded. END.SID3 iterates over the SDWAN tunnel and, based on the SDWAN tunnel link information (SA = tnp3, DA = tnp4) encapsulated in the packet, sends it to POP2. If no SR policy is matched, the IPv6 DA (END.SID2) is searched and forwarded to POP4. Tnp3 is the IP address of the port used by POP1 to communicate with POP2, and tnp2 is the IP address of the port used by POP2 to communicate with POP1.

[0658] POP2: Decapsulates the outer SDWAN tunnel of the received message, searches for the IPv6 DA (END.SID3) to match the local SID table entry, replaces the IPv6 header DA with END.SID2, continues to search for routing and forwarding, iterates over the SDWAN tunnel with END.SID2, encapsulates the SDWAN tunnel link information (SA = tnp5, DA = tnp6), and sends the message to POP3. tnp5 is the IP address of the port used by POP2 to communicate with POP3, and tnp6 is the IP address of the port used by POP3 to communicate with POP2.

[0659] POP3: Decapsulates the outer SDWAN tunnel for the received message, continues to query the route and forward according to the IPv6 DA (END.SID2), and forwards POP4 through the local direct connection interface based on the END.X SID route output interface.

[0660] POP4: For the received message, it searches the IPv6 DA (END.SID2) for a match in the local SID table. If the SL is 0, it removes the SRH encapsulation and replaces the IPv6 header DA with system-ip2. It then continues to search for routing information and forwards the message. System-ip2 iterates over the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp7, DA = tnp8), and sends the message to site edge2. Tnp7 is the IP address of the port used by POP4 to communicate with site edge2, and tnp8 is the IP address of the port used by site edge2 to communicate with POP4.

[0661] Site edge2: Decapsulates the outer SDWAN tunnel, finds the local route for system-ip2, removes the IPv6 encapsulation, processes ESP, searches for the route for server-ip based on the VPN identifier in the GRE private network, and forwards the route to the destination.

[0662] See Figure 15b, which is a schematic diagram of another scenario of a traffic forwarding method provided by an embodiment of the present application. Figure 15b shows the encapsulation format of the service traffic transmitted in the network when the solution provided by an embodiment of the present application is applied to the scenario shown in Figure 1b. In the scenario shown in Figure 15b, the end-to-end path between site edge1 and site edge2 is an SRv6 tunnel. The specific process of traffic forwarding is as follows:

[0663] At site edge1, a service packet from an enterprise user accessing headquarters arrives at branch site edge1. The source address of the service packet is the enterprise user's IP address (client-ip), and the destination address is the headquarters' IP address (server-ip). Site edge1 queries the server-ip route and determines the next hop is site edge2's IP address, system-ip2. It then iterates the SRv6 policy based on system-ip2 (the path list is: END.SID1, END.X SID). Site edge1 encapsulates the service packet with an IPv6 header and SRH, along with service intent information. It then continues to query the route for the SRv6 forwarding next hop, END.SID1. END.SID1 iterates over the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp1, DA = tnp2), and sends the packet to POP1.

[0664] POP1 decapsulates the outer SDWAN tunnel of the received packet and queries the IPv6 DA (END.SID1) to match the local SID table entry. The operation associated with END.SID1 is to take the next-hop SID and service intent information to match the SR policy. If a match is successful according to the tunnel matching policy, a new SRH (containing the SR list: END.SID3, END.X SID) is inserted into the packet. The IPv6 header DA is replaced with END.SID3 and the route is searched and forwarded. END.SID3 iterates the SDWAN tunnel and sends the SDWAN tunnel link information (SA = tnp3, DA = tnp4) encapsulated in the packet to POP2. If no SR policy path is matched, the IPv6 DA (END.X SID) is searched and forwarded to POP4.

[0665] POP2: Decapsulates the outer SDWAN tunnel of the received message, queries the IPv6 DA (END.SID3) to match the local SID table entry, changes the IPv6 header DA to END.X SID, continues to check the route and forward, iterates the END.X SID route to the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA=tnp5, DA=tnp6), and sends the message to POP3.

[0666] POP3: Decapsulates the outer SDWAN tunnel of the received message, continues to query the route and forward according to the IPv6 DA (END.X SID), and directly forwards POP4 through the local direct connection interface based on the END.X SID route output interface.

[0667] POP4: For the received message, the IPv6 DA (END.X SID) is queried to match the local SID table entry. At the same time, SL is 0, the SRH encapsulation is removed, and the IPv6 header encapsulation is removed. The SDWAN tunnel is iterated according to system-ip2, and the SDWAN tunnel link information (SA = tnp7, DA = tnp8) is encapsulated. The message is sent to site edge2.

[0668] Site edge2: Decapsulates the outer SDWAN tunnel of the received message, queries system-ip2 for the local route, removes the IPv6 encapsulation, processes ESP, searches for the server-ip route based on the VPN identifier in the GRE private network, and forwards the route to the destination.

[0669] See Figure 15c, which is a schematic diagram of another scenario of a traffic forwarding method provided by an embodiment of the present application. Figure 15c shows the encapsulation format of the service traffic transmitted in the network when the solution provided by an embodiment of the present application is applied to the scenario shown in Figure 1b. In the scenario shown in Figure 15c, the end-to-end path between site edge1 and site edge2 is an SR-MPLS TE policy. The specific process of traffic forwarding is as follows:

[0670] At site edge1, a service packet from an enterprise user accessing headquarters arrives at branch site edge1. The source address of the service packet is the enterprise user's IP address (client-ip), and the destination address is the headquarters' IP address (server-ip). Site edge1 queries the route for server-ip and determines the next hop is system-ip2, the IP address of site edge2. Based on system-ip2, it iterates the SR-MPLS TE policy (path list: NODE.SID1, NODE.SID5, Adjacency SID), and encapsulates the MPLS label stack. Based on the label forwarding next hop, NODE.SID1, it iterates the route forwarding. NODE.SID1 iterates the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp1, DA = tnp2), and sends the packet to POP1.

[0671] POP1: Decapsulates the outer SDWAN tunnel of the received message and queries the local SID table entry for NODE.SID1. The operation associated with NODE.SID1 is to match the SR-MPLS TE policy based on the next-hop SID of NODE.SID1 in the MPLS label stack as the egress node information of the intermediate POP backbone network SR-MPLS label stack path. If the tunnel matching policy successfully matches, the local NODE.SID1 and next-hop label NODE.SID5 in the message are replaced with the label stack corresponding to the intermediate POP backbone network SRMPLS policy (backbone network SR-MPLS TE policy path: NODE.SID3, NODE.SID4, NODE.SID5). The message is then forwarded based on the top label NODE.SID3 in the stack. NODE.SID3 iterates over the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp3, DA = tnp4), and sends the message to POP2. If POP1 does not match the POP backbone network SR-MPLS TE policy, the packet is directly forwarded to POP4 based on the next-hop label NODE.SID5 in the packet.

[0672] POP2: Decapsulates the outer SDWAN tunnel of the received message, queries the label NODE.SID3 to match the local SID table entry, pops up the current NODE.SID3 label, and uses the next hop label NODE.SID4 to continue the table lookup and forwarding. NODE.SID4 routes the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA=tnp5, DA=tnp6), and sends the message to POP3.

[0673] POP3: Decapsulates the outer SDWAN tunnel of the received message, pops out the current NODE.SID4 label, continues to look up the table and forwards it using the next hop label NODE.SID5, and forwards POP4 through the local direct connection interface.

[0674] POP4: Decapsulates the outer SDWAN tunnel of the received message. The NODE.SID5 label matches the local SID table entry, pops up the current NODE.SID5 label, and continues to look up the table for forwarding using the next-hop label Adjacency SID. According to the Adjacency SID, the next hop is the incoming SDWAN tunnel. The current Adjacency SID label is popped up, and the SDWAN tunnel link information (SA=tnp7, DA=tnp8) is encapsulated. The message is sent to site edge2.

[0675] Site edge2: Decapsulates the outer SDWAN tunnel, processes ESP, searches for the server-ip route in the private network identified by the VPN in GRE, queries the destination system-ip2 route, and forwards the packet to the destination.

[0676] See Figure 15d, which is a schematic diagram of a scenario of a traffic forwarding method provided by an embodiment of the present application. Figure 15d shows the encapsulation format of the service traffic transmitted in the network when the solution provided by an embodiment of the present application is applied to the scenario shown in Figure 1c. In the scenario shown in Figure 15d, the end-to-end path between site edge1 and site edge2 is an SRv6 tunnel. The specific process of traffic forwarding is as follows:

[0677] At site edge1, a service packet from an enterprise user accessing headquarters arrives at branch site edge1. The source address of the service packet is the enterprise user's IP address (client-ip), and the destination address is the headquarters' IP address (server-ip). Site edge1 queries the server-ip route and determines that the next hop is site edge2's IP address, system-ip2. Based on the SRv6 policy for system-ip2 (the path list is: END.SID1, END.SID2, system-ip2), site edge1 encapsulates the service packet with an IPv6 header and SRH, along with service intent information. It then continues forwarding the packet based on the SRv6 forwarding next hop, END.SID1. END.SID1 iterates over the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp1, DA = tnp2), and sends the packet to POP1.

[0678] POP1: Decapsulates the outer SDWAN tunnel of the received message and queries the IPv6 DA (END.SID1) to match the local SID table entry. The operation associated with END.SID1 is to match the SR policy based on the next-hop SID + service intent information. If the tunnel matching policy matches successfully, a new SRH (containing the SR list: END.SID3, END.SID2) is inserted into the message. The IPv6 header DA is replaced with END.SID3 to continue searching for routing and forwarding. END.SID3 iterates the SDWAN tunnel and sends the SDWAN tunnel link information (SA = tnp3, DA = tnp4) encapsulated in the message to POP2. If no SR policy is matched, the IPv6 DA (END.SID2) is searched for routing and forwarded to POP4.

[0679] POP2: Decapsulates the outer SDWAN tunnel of the received message, searches for the IPv6 DA (END.SID3) to match the local SID table entry, replaces the IPv6 header DA with END.SID2, continues to search for routing and forwarding, iterates over the SDWAN tunnel with END.SID2, encapsulates the SDWAN tunnel link information (SA = tnp5, DA = tnp9), and sends the message to POP4. tnp5 is the IP address of the port used by POP2 to communicate with POP4, and tnp9 is the IP address of the port used by POP4 to communicate with POP2.

[0680] POP4: Query the IPv6 DA (END.SID2) for the received message to match the local SID table entry. At the same time, SL is 0, remove the SRH encapsulation, change the IPv6 header DA to system-ip2, continue to check the route and forward, system-ip2 iterates the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA=tnp7, DA=tnp8), and sends the message to site edge2.

[0681] Site edge2: Decapsulates the outer SDWAN tunnel, finds the local route for system-ip2, removes the IPv6 encapsulation, processes ESP, searches for the route to server-ip in the private network based on the VNI identifier in GRE, and forwards the route to the destination.

[0682] See Figure 15e, which is a schematic diagram of another scenario of a traffic forwarding method provided by an embodiment of the present application. Figure 15e shows the encapsulation format of the service traffic transmitted in the network when the solution provided by an embodiment of the present application is applied to the scenario shown in Figure 1c. In the scenario shown in Figure 15e, the end-to-end path between site edge1 and site edge2 is an SR-MPLS TE policy. The specific process of traffic forwarding is as follows:

[0683] At site edge1, a service packet from an enterprise user accessing headquarters arrives at branch site edge1. The source address of the service packet is the enterprise user's IP address (client-ip), and the destination address is the headquarters' IP address (server-ip). Site edge1 queries the route for server-ip and determines the next hop is system-ip2, the IP address of site edge2. Based on system-ip2, it iterates the SR-MPLS TE policy (path list: NODE.SID1, NODE.SID5, Adjacency SID), and encapsulates the MPLS label stack. Based on the label forwarding next hop, NODE.SID1, it iterates the route forwarding. NODE.SID1 iterates the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp1, DA = tnp2), and sends the packet to POP1.

[0684] POP1: Decapsulates the outer SDWAN tunnel of the received message and queries the local SID table entry for NODE.SID1. The operation associated with NODE.SID1 is to match the SR-MPLS TE policy based on the next-hop SID of NODE.SID1 in the MPLS label stack as the egress node information of the intermediate POP backbone network SR-MPLS label stack path. If the tunnel matching policy successfully matches, the local NODE.SID1 and next-hop label NODE.SID5 in the message are replaced with the label stack corresponding to the intermediate POP backbone network SRMPLS policy (backbone network SR-MPLS TE policy path: NODE.SID3, NODE.SID5). The message is then forwarded based on the top label NODE.SID3 in the stack. NODE.SID3 iterates over the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA = tnp3, DA = tnp4), and sends the message to POP2. If POP1 does not match the POP backbone network SR-MPLS TE policy, the packet is directly forwarded to POP4 based on the next-hop label NODE.SID5 in the packet.

[0685] POP2: Decapsulates the outer SDWAN tunnel of the received message, queries the label NODE.SID3 to match the local SID table entry, pops up the current NODE.SID3 label, and uses the next hop label NODE.SID5 to continue the table lookup and forwarding. The NODE.SID5 route iterates the SDWAN tunnel, encapsulates the SDWAN tunnel link information (SA=tnp5, DA=tnp9), and sends the message to POP4.

[0686] POP4: Decapsulates the outer SDWAN tunnel of the received message. The NODE.SID5 label matches the local SID table entry, pops up the current NODE.SID5 label, and continues to look up the table for forwarding using the next-hop label Adjacency SID. According to the Adjacency SID, the next hop is the incoming SDWAN tunnel. The current Adjacency SID label is popped up, and the SDWAN tunnel link information (SA=tnp7, DA=tnp8) is encapsulated. The message is sent to site edge2.

[0687] Site edge2: Decapsulates the outer SDWAN tunnel, processes ESP, searches for the server-ip route in the private network identified by the VPN in GRE, queries the destination system-ip2 route, and forwards the packet to the destination.

[0688] Referring to Figure 16, which is a flow chart of an information notification method provided in an embodiment of the present application, the information notification method 700 shown in Figure 16 can be applied to the above method 100, method 200, method 300, method 400, method 500, or method 600.

[0689] The information notification method 700 shown in FIG16 may be applied to a first communication device serving as a first site edge.

[0690] In the embodiment of the present application, the method 700 may include the following S701-S702.

[0691] S701: Receive a first route announced by a second communication device, where the first route includes first information of a first backbone network exit device and an identifier of a second site edge in the backbone network, where the second site edge accesses the backbone network through the first backbone network exit device, and the first site edge accesses the backbone network through a first backbone network entry device.

[0692] S702: Acquire a first binding relationship between the second site edge and the first backbone network egress device according to the first route.

[0693] When the method 700 is applied to the method 100:

[0694] The first site edge in method 700 can correspond to site edge1 in method 100; the second communication device in method 700 can correspond to site edge2 in method 100; the first route in method 700 can correspond to route 1 in method 100; the first backbone network exit device in method 700 can correspond to backbone network exit device 1 in method 100; the first information in method 700 can correspond to information 1 in method 100; the first binding relationship in method 700 can correspond to binding relationship 1 in method 100.

[0695] When the method 700 is applied to the method 200:

[0696] The first site edge in method 700 can correspond to site edge1 in method 200; the second communication device in method 700 can correspond to site edge2 in method 200; the first route in method 700 can correspond to route 1' in method 100; the first backbone network exit device in method 700 can correspond to backbone network exit device 1 in method 200; the first information in method 700 can correspond to information 1 in method 200; the first binding relationship in method 700 can correspond to binding relationship 1 in method 200.

[0697] When the method 700 is applied to the method 300:

[0698] The first site edge in method 700 can correspond to site edge1 in method 300; the second communication device in method 700 can correspond to backbone network exit device 1 in method 300; the first route in method 700 can correspond to route 1" in method 300; the first backbone network exit device in method 700 can correspond to backbone network exit device 1 in method 300; the first information in method 700 can correspond to information 1 in method 300; the first binding relationship in method 700 can correspond to binding relationship 1 in method 300.

[0699] In a possible implementation, the method further includes: determining a first end-to-end path from the first site edge to the second site edge based on the first binding relationship, the first end-to-end path passing through the first backbone network ingress device and the first backbone network egress device.

[0700] The first end-to-end path mentioned in method 700 may be, for example, the end-to-end path 1 or the end-to-end path 2 mentioned in the above method embodiments.

[0701] In one possible implementation, the first information includes one or more of the following: a first segment identifier SID assigned by the first backbone network egress device to the adjacency relationship between the first backbone network egress device and the second site edge; a second SID of the first backbone network egress device; a routing priority of the first backbone network egress device; and a load sharing weight of the first backbone network egress device.

[0702] When the method 700 is applied to the method 100 , the first SID in the method 700 may be SID1 in the method 100 ; the second SID in the method 700 may be SID2 in the method 100 .

[0703] When the method 700 is applied to the method 200 , the first SID in the method 700 may be SID1 in the method 200 ; the second SID in the method 700 may be SID2 in the method 200 .

[0704] When the method 700 is applied to the method 300 , the first SID in the method 700 may be the SID1 in the method 300 ; the second SID in the method 700 may be the SID2 in the method 300 .

[0705] In one possible implementation, the first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.X SID that is cross-connected to a Layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.SID; or, the first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

[0706] In one possible implementation, when the method 700 is applied to the above method 100, the second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, and the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

[0707] In one possible implementation, the SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, and the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

[0708] The first TLV mentioned in method 700 may be the MP_REACH_NLRI shown in FIG. 4 a mentioned in method 100 .

[0709] In a possible implementation, when the method 700 is applied to the above method 200, the second communication device is the second site edge, and the first route includes a virtual private network VPN route.

[0710] In a possible implementation, the VPN route includes a first metadata path attribute, and the first metadata path attribute carries the first information.

[0711] The first Metadata Path Attribute in method 700 may correspond to Metadata Path Attribute2 in method 100 .

[0712] In a possible implementation manner, the first route further includes: service intent information.

[0713] In a possible implementation, the service intention information includes one or more of the following: a gateway that the first end-to-end path needs to pass through, a gateway that the first end-to-end path needs to bypass, and a quality of service parameter.

[0714] In a possible implementation, the first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the service intent information.

[0715] When the method 700 is applied to the above method 100 , the second Metadata Path Attribute in the method 700 may correspond to the Metadata Path Attribute 1 in the method 100 .

[0716] When the method 700 is applied to the above method 200 , the second Metadata Path Attribute in the method 700 may correspond to the Metadata Path Attribute2 in the method 200 .

[0717] In one possible implementation, when the method 700 is applied to the above method 200, the second communication device is the first backbone network egress device, and the receiving of the first route announced by the second communication device includes: receiving the first route announced by the first backbone network egress device through the first backbone network ingress device.

[0718] The first backbone network ingress device in method 700 may correspond to backbone network ingress device 1 in method 300 .

[0719] In one possible implementation, the first route includes: the first SD-WAN gateway automatically discovers the route.

[0720] In one possible implementation, the method also includes: receiving a second route announced by a third communication device, the second route including second information of a second backbone network exit device in the backbone network and an identifier of the second site edge, the second site edge accessing the backbone network through the second backbone network exit device; according to the second route, obtaining a second binding relationship between the second site edge and the second backbone network exit device.

[0721] When the method 700 is applied to the above method 100:

[0722] The third communication device in method 700 can correspond to the site edge2 in method 100; the second route in method 700 can correspond to route 2 in method 100; the second backbone network exit device in method 700 can correspond to backbone network exit device 2 in method 100; the second information in method 700 can correspond to information 2 in method 100; the second binding relationship in method 700 can correspond to binding relationship 2 in method 100.

[0723] When the method 700 is applied to the above method 200:

[0724] The third communication device in method 700 can correspond to the site edge2 in method 200; the second route in method 700 can correspond to route 1' in method 200; the second backbone network exit device in method 700 can correspond to the backbone network exit device 2 in method 200; the second information in method 700 can correspond to the information 2 in method 200; the second binding relationship in method 700 can correspond to the binding relationship 2 in method 200.

[0725] In one possible implementation, the method further includes: determining the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or determining the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

[0726] In a possible implementation, the method further includes: determining, based on the second binding relationship, a second end-to-end path from the first site edge to the second site edge, where the second end-to-end path passes through the first backbone network ingress device and the second backbone network egress device.

[0727] The second end-to-end path in method 700 may be another end-to-end path different from the first end-to-end path, extending from the edge of the first site to the edge of the second site. The second end-to-end path mentioned in method 700 may be, for example, end-to-end path 1 or end-to-end path 2 mentioned in the above method embodiments.

[0728] In one possible implementation, the method 700 can also be applied to the above method 400 or 500. In this case, the method also includes: receiving a third route sent by the first backbone network entry device, the third route being used to notify the third information of the first backbone network entry device; and obtaining a third binding relationship between the first site edge and the first backbone network entry device according to the third route.

[0729] When the method 700 is applied to the above method 400:

[0730] The first site edge in method 700 may correspond to the site edge in method 400; the first backbone network access device in method 700 may correspond to the gateway in method 400; the third route in method 700 may correspond to route 3 in method 400; the third information in method 700 may correspond to information 3 in method 400. The third binding relationship in method 700 may correspond to binding relationship 3 in method 400.

[0731] When the method 700 is applied to the above method 500:

[0732] The first site edge in method 700 may correspond to the site edge in method 500; the first backbone network access device in method 700 may correspond to the gateway in method 500; the third route in method 700 may correspond to route 3' in method 500; the third information in method 700 may correspond to information 3 in method 500. The third binding relationship in method 700 may correspond to binding relationship 3 in method 500.

[0733] In one possible implementation, when the method 700 is applied to the above method 400, the third route is a route automatically discovered by the second SD-WAN gateway.

[0734] In a possible implementation, when the method 700 is applied to the above method 500, the third route is a BGP link state LS route.

[0735] In a possible implementation, the third information includes: a third SID allocated by the first backbone network ingress device for the adjacency relationship between the first backbone network ingress device and the first site edge, and / or a fourth SID of the first backbone network ingress device.

[0736] When the method 700 is applied to the above method 400 , the third SID in the method 700 may correspond to SID3 in the method 400 , and the fourth SID in the method 700 may correspond to SID4 in the method 400 .

[0737] When the method 700 is applied to the above method 500 , the third SID in the method 700 may correspond to SID3 in the method 500 , and the fourth SID in the method 700 may correspond to SID4 in the method 500 .

[0738] In a possible implementation, the third route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between the first backbone network ingress device and the egress device in the backbone network.

[0739] The method 700 can also be applied to the above method 600. Specifically, the method further includes:

[0740] A first site edge receives a first service message, and the first site edge encapsulates path information of a first end-to-end path in an outer layer of the first service message to obtain a second service message; wherein the path information of the first end-to-end path includes fourth information identifying a first backbone network ingress device in the backbone network and fifth information identifying a first backbone network egress device in the backbone network, the ingress endpoint of the first end-to-end path is the first site edge, the egress endpoint of the first end-to-end path is the second site edge, the first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device. The first site edge sends the second service message via the first end-to-end path.

[0741] The first site edge in method 700 can correspond to site edge1 in method 600; the first business message in method 700 can correspond to business message 1 in method 600; the second business message in method 700 can correspond to business message 2 in method 600; the first end-to-end path in method 700 can correspond to end-to-end path 1 in method 600; the fourth information in method 700 can correspond to information 1 in method 600; the fifth information in method 700 can correspond to information 2 in method 600; the first backbone network ingress device in method 700 can correspond to backbone network ingress device 1 in method 600; the first backbone network egress device in method 700 can correspond to backbone network egress device 1 in method 600; the second site edge in method 700 can correspond to site edge2 in method 600.

[0742] In one possible implementation, the first service message is used to carry a virtual private network (VPN) service. Before receiving the first service message, the method further includes: the first site edge, based on the VPN service, combines the first backbone network entry device and the first backbone network exit device as needed to orchestrate the first end-to-end path from the first site edge to the second site edge.

[0743] In a possible implementation, the second service message further includes service intent information.

[0744] In a possible implementation, the service intention information is carried in a metadata field of the second service message.

[0745] In one possible implementation, before encapsulating the path information of the first end-to-end path, the method also includes: the first site edge determines, based on the destination address of the first service message, that the next hop for forwarding the first service message is the second site edge, and iterates the first segment routing policy SR policy based on the Internet Protocol IP address of the second site edge to obtain the path information of the first end-to-end path.

[0746] The first SR policy in method 700 may correspond to SR policy 1 in method 600 .

[0747] In one possible implementation, the first end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the fourth information and the fifth information.

[0748] In one possible implementation, the fourth information is the first endpoint segment identifier END.SID1 of the first backbone network entry device, the fifth information is the second endpoint segment identifier END.SID2 of the first backbone network egress device, and the SRH also includes the IPv6 address of the second site edge.

[0749] In a possible implementation, the fourth information is the first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the fifth information is the endpoint segment identifier END.X SID, which is cross-connected to a Layer 3 adjacency array and is allocated by the first backbone network device egress device for the adjacency relationship between the first backbone network device egress device and the second site edge.

[0750] In a possible implementation, the operation of associating the first endpoint segment identifier END.SID1 includes: matching an upper-layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the END.SID1.

[0751] In one possible implementation, when the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper-layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device based on the next-hop SID of the END.SID1 and the service intent information.

[0752] In one possible implementation, the first end-to-end path is an SR-MPLS TE policy, the second service packet includes an MPLS label stack, the MPLS label stack includes the fourth information and the fifth information, the fourth information is the first node SID of the first backbone network ingress device, and the fifth information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID assigned by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

[0753] In a possible implementation, the operation of associating the first node SID includes matching an upper-layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next-hop SID of the first node SID in the label stack.

[0754] In one possible implementation, when the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device based on the next hop SID of the first node SID in the label stack and the service intent information.

[0755] In a possible implementation, the first end-to-end path is a tunnel encapsulated based on the General Network Virtualization Encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

[0756] In a possible implementation, the first end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

[0757] In one possible implementation, the second service message includes: an outer IP header, a User Datagram Protocol UDP header, an outer GRE encapsulation, an IPv6 header, an SRH, an inner GRE encapsulation and a payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

[0758] In a possible implementation, the method further includes:

[0759] The first site edge receives the third service message;

[0760] The first site edge encapsulates path information of the third end-to-end path in the outer layer of the third service message to obtain a fourth service message; wherein the path information of the third end-to-end path includes sixth information identifying a second backbone network ingress device in the backbone network and seventh information identifying a second backbone network egress device in the backbone network, the ingress endpoint of the third end-to-end path is the first site edge, the egress endpoint of the third end-to-end path is the second site edge, the third end-to-end path passes through the second backbone network ingress device and the second backbone network egress device, the first site edge multi-homed access to the first backbone network ingress device and the second backbone network ingress device, and the second site edge multi-homed access to the first backbone network egress device and the second backbone network egress device;

[0761] The first site edge sends the fourth service message through the third end-to-end path.

[0762] The third business message in method 700 can correspond to business message 4 in method 600; the fourth business message in method 700 can correspond to business message 5 in method 600; the third end-to-end path in method 700 can correspond to end-to-end path 2 in method 600; the third information in method 700 can correspond to information 3 in method 600; the fourth information in method 700 can correspond to information 4 in method 600; the second backbone network ingress device in method 700 can correspond to backbone network ingress device 2 in method 600; the second backbone network egress device in method 700 can correspond to backbone network egress device 2 in method 600.

[0763] In one possible implementation, the first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

[0764] Referring to Figure 17, which is a flowchart of another information notification method provided in an embodiment of the present application, the information notification method 800 shown in Figure 17 can be applied to the above method 100, method 200, method 300, method 400, or method 500.

[0765] The information notification method 800 shown in FIG. 17 may be applied to the second communication device.

[0766] In the embodiment of the present application, the method 800 may include the following S701-S702.

[0767] S801: Obtain a first route, where the first route includes first information of a first backbone network egress device and an identifier of a second site edge in a backbone network. The second site edge accesses the backbone network through the first backbone network egress device.

[0768] S802: Notify the first route to a first site edge, where the first site edge accesses the backbone network through a first backbone network ingress device.

[0769] When the method 800 is applied to the method 100:

[0770] The first site edge in method 800 can correspond to site edge1 in method 100; the second site edge in method 800 can correspond to site edge2 in method 100; the first route in method 800 can correspond to route 1 in method 100; the first backbone network exit device in method 800 can correspond to backbone network exit device 1 in method 100; the first information in method 800 can correspond to information 1 in method 100.

[0771] When the method 800 is applied to the method 200:

[0772] The first site edge in method 800 can correspond to site edge1 in method 200; the second site edge in method 800 can correspond to site edge2 in method 200; the first route in method 800 can correspond to route 1' in method 100; the first backbone network exit device in method 800 can correspond to backbone network exit device 1 in method 200; the first information in method 800 can correspond to information 1 in method 200.

[0773] When the method 800 is applied to the method 300:

[0774] The first site edge in method 800 may correspond to site edge1 in method 300; the first route in method 800 may correspond to route 1" in method 300; the first backbone network egress device in method 800 may correspond to backbone network egress device 1 in method 300; the first information in method 800 may correspond to information 1 in method 300.

[0775] In one possible implementation, the first information includes one or more of the following: a first segment identifier SID assigned by the first backbone network egress device to the adjacency relationship between the first backbone network egress device and the second site edge; a second SID of the first backbone network egress device; a routing priority of the first backbone network egress device; and a load sharing weight of the first backbone network egress device.

[0776] When the method 800 is applied to the method 100 , the first SID in the method 800 may be SID1 in the method 100 ; the second SID in the method 800 may be SID2 in the method 100 .

[0777] When the method 800 is applied to the method 200 , the first SID in the method 800 may be SID1 in the method 200 ; the second SID in the method 800 may be SID2 in the method 200 .

[0778] When the method 800 is applied to the method 300 , the first SID in the method 800 may be SID1 in the method 300 ; the second SID in the method 800 may be SID2 in the method 300 .

[0779] In one possible implementation, the first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.X SID that is cross-connected to a Layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.SID; or, the first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

[0780] In one possible implementation, when the method 800 is applied to the above method 100, the second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, and the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

[0781] In one possible implementation, the SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, and the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

[0782] The first TLV mentioned in method 700 may be the MP_REACH_NLRI shown in FIG. 4 a mentioned in method 100 .

[0783] In a possible implementation, when the method 800 is applied to the above method 200, the second communication device is the second site edge, and the first route includes a virtual private network VPN route.

[0784] In a possible implementation, the VPN route includes a first metadata path attribute, and the first metadata path attribute carries the first information.

[0785] The first Metadata Path Attribute in method 800 may correspond to Metadata Path Attribute2 in method 100 .

[0786] In a possible implementation manner, the first route further includes: service intent information.

[0787] In one possible implementation, the service intent information includes one or more of the following: a gateway through which the service traffic needs to pass, a gateway that the service traffic needs to bypass, and quality of service parameters that need to be met when transmitting the service traffic.

[0788] In a possible implementation, the first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the service intent information.

[0789] When the method 800 is applied to the above method 100 , the second Metadata Path Attribute in the method 800 may correspond to the Metadata Path Attribute 1 in the method 100 .

[0790] When the method 800 is applied to the above method 200, the second Metadata Path Attribute in the method 800 may correspond to the Metadata Path Attribute2 in the method 200. In one possible implementation, when the method 800 is applied to the above method 200, the second communication device is the first backbone network egress device, and the notifying the first site edge of the first route includes: notifying the first route to the first site edge through the first backbone network ingress device.

[0791] The first backbone network ingress device in method 700 may correspond to backbone network ingress device 1 in method 300 .

[0792] In one possible implementation, the first route includes: the first SD-WAN gateway automatically discovers the route.

[0793] In one possible implementation, when the method 800 is applied to the above method 100 or 200, the method also includes: notifying the first site edge of a second route, the second route including second information of a second backbone network exit device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network exit device.

[0794] When the method 800 is applied to the above method 100:

[0795] The second route in method 800 can correspond to route 2 in method 100; the second backbone network exit device in method 800 can correspond to backbone network exit device 2 in method 100; the second information in method 800 can correspond to information 2 in method 100; the second binding relationship in method 800 can correspond to binding relationship 2 in method 100.

[0796] When the method 800 is applied to the above method 200:

[0797] The second route in method 800 may correspond to route 1' in method 200; the second backbone network exit device in method 800 may correspond to backbone network exit device 2 in method 200; the second information in method 800 may correspond to information 2 in method 200; the second binding relationship in method 800 may correspond to binding relationship 2 in method 200.

[0798] In one possible implementation, when the second communication device is a second site edge, the method 800 can also be applied to the above method 400 or 500. In this case, the method also includes: receiving a third route sent by the first backbone network export device, and the third route is used to notify the third information of the first backbone network export device; according to the third route, obtaining the first binding relationship between the second site edge and the first backbone network export device.

[0799] When the method 800 is applied to the above method 400:

[0800] The second site edge in method 800 may correspond to the site edge in method 400; the first backbone network egress device in method 800 may correspond to the gateway in method 400; the third route in method 800 may correspond to route 3 in method 400; the third information in method 800 may correspond to information 3 in method 400. The third binding relationship in method 800 may correspond to binding relationship 3 in method 400.

[0801] When the method 800 is applied to the above method 500:

[0802] The second site edge in method 800 may correspond to the site edge in method 500; the first backbone network egress device in method 800 may correspond to the gateway in method 500; the third route in method 800 may correspond to route 3' in method 500; the third information in method 800 may correspond to information 3 in method 500. The third binding relationship in method 800 may correspond to binding relationship 3 in method 500.

[0803] In a possible implementation, the third information includes: a third SID allocated by the first backbone network egress device for the adjacency relationship between the first backbone network egress device and the second site edge, and / or a fourth SID of the first backbone network egress device.

[0804] When the method 800 is applied to the above method 400 , the third SID in the method 800 may correspond to SID3 in the method 400 , and the fourth SID in the method 800 may correspond to SID4 in the method 400 .

[0805] When the method 800 is applied to the above method 500 , the third SID in the method 800 may correspond to SID3 in the method 500 , and the fourth SID in the method 800 may correspond to SID4 in the method 500 .

[0806] In one possible implementation, when the method 800 can also be applied to the above method 400 or 500, the method also includes: receiving a fourth route sent by the second backbone network export device, the fourth route being used to announce the fourth information of the second backbone network export device; and obtaining the second binding relationship between the second site edge and the second backbone network export device according to the fourth route.

[0807] In one possible implementation, the method further includes: determining the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or determining the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

[0808] In one possible implementation, when the method 800 is applied to the above method 400, the third route is a route automatically discovered by the second SD-WAN gateway.

[0809] In a possible implementation, when the method 800 is applied to the above method 500, the third route is a BGP link state LS route, and the BGP LS route includes a second TLV, and the second TLV indicates that the third route is used to announce third information of the first backbone network egress device.

[0810] The second TLV in method 800 may correspond to TLV1 in method 500 .

[0811] In a possible implementation, the second TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the first backbone network egress device is a gateway.

[0812] In a possible implementation, the third route further includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device in the backbone network and the first backbone network egress device.

[0813] In a possible implementation, the third route includes a third Metadata Path Attribute, and the third Metadata Path Attribute carries the intermediate gateway information.

[0814] When the method 800 is applied to the above method 400 , the third Metadata Path Attribute in the method 800 may correspond to Metadata Path Attribute3 in the method 400 .

[0815] When the method 800 is applied to the above method 500 , the third Metadata Path Attribute in the method 800 may correspond to Metadata Path Attribute 4 in the method 500 .

[0816] In a possible implementation, the method further includes: determining gateway constraint information in the service intent information based on the intermediate gateway information, where the gateway constraint information indicates gateway constraint conditions that need to be followed to determine a path to the second site edge.

[0817] In a possible implementation, the gateway constraint condition includes: a gateway that needs to be passed through, and / or a gateway that needs to be detoured.

[0818] Referring to Figure 18, which is a flowchart of another information notification method provided in an embodiment of the present application, the information notification method 900 shown in Figure 18 can be applied t...

Claims

1. An information notification method, It is characterized in that Applied to a first communication device as a first site edge, the method includes: Receive a first route announced by a second communication device, wherein the first route includes first information of a first backbone network egress device in the backbone network and an identifier of a second site edge, wherein the second site edge accesses the backbone network through the first backbone network egress device, and the first site edge accesses the backbone network through a first backbone network ingress device; According to the first route, a first binding relationship between the second site edge and the first backbone network egress device is obtained.

2. The method according to claim 1, It is characterized in that The method further comprises: According to the first binding relationship, a first end-to-end path from the first site edge to the second site edge is determined, where the first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device.

3. The method according to claim 2, It is characterized in that The first information includes one or more of the following: The first backbone network egress device is allocated a first segment identifier SID for an adjacency relationship between the first backbone network egress device and the second site edge; A second SID of the first backbone network egress device; The routing priority of the first backbone network egress device; The load sharing weight of the first backbone network egress device.

4. The method according to claim 3, It is characterized in that The first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.X SID having a cross-connection to a layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.SID; or, The first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

5. The method according to claim 3 or 4, It is characterized in that The second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, and the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

6. The method according to claim 5, It is characterized in that The SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

7. The method according to any one of claims 2 to 4, It is characterized in that The second communication device is the second site edge, and the first route includes a virtual private network VPN route.

8. The method according to claim 7, It is characterized in that The VPN route includes a first metadata path attribute Metadata Path Attribute, and the first Metadata Path Attribute carries the first information.

9. The method according to any one of claims 2 to 8, It is characterized in that The first route also includes: business intention information.

10. The method according to claim 9, It is characterized in that The business intention information includes one or more of the following: The gateways that the first end-to-end path needs to pass through, the gateways that the first end-to-end path needs to bypass, and quality of service parameters.

11. The method according to claim 9 or 10, It is characterized in that The first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the business intent information.

12. The method according to any one of claims 1 to 4, It is characterized in that The second communication device is the first backbone network egress device, and the receiving the first route announced by the second communication device includes: The first route announced by the first backbone network egress device is received through the first backbone network ingress device.

13. The method according to claim 12, It is characterized in that The first route includes: the first SD-WAN gateway automatically discovers the route.

14. The method according to any one of claims 1 to 13, It is characterized in that The method further comprises: receiving a second route announced by a third communication device, wherein the second route includes second information of a second backbone network egress device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network egress device; According to the second route, a second binding relationship between the second site edge and the second backbone network egress device is obtained.

15. The method according to claim 14, It is characterized in that The method further comprises: Determine the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or, Determine the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

16. The method according to claim 14 or 15, It is characterized in that The method further comprises: A second end-to-end path from the first site edge to the second site edge is determined according to the second binding relationship. The second end-to-end path passes through the first backbone network ingress device and the second backbone network egress device.

17. The method according to any one of claims 1 to 16, It is characterized in that The method further comprises: receiving a third route sent by the first backbone network ingress device, where the third route is used to notify the first backbone network ingress device of third information; According to the third route, a third binding relationship between the first site edge and the first backbone network ingress device is obtained.

18. The method according to claim 17, It is characterized in that The third route is the second SD-WAN gateway automatic discovery route or the BGP link state LS route.

19. The method according to claim 17, It is characterized in that The third information includes: The first backbone network entry device is a third SID allocated by the first backbone network entry device for the adjacency relationship between the first backbone network entry device and the first site edge, and / or a fourth SID of the first backbone network entry device.

20. The method according to claim 18 or 19, It is characterized in that The third route also includes intermediate gateway information, where the intermediate gateway information indicates at least one intermediate gateway between the first backbone network ingress device and the egress device in the backbone network.

21. The method according to any one of claims 2 to 11, It is characterized in that The method comprises: Receiving a first service message; Encapsulating the path information of the first end-to-end path in the outer layer of the first service message to obtain a second service message; wherein the path information of the first end-to-end path includes fourth information identifying a first backbone network ingress device in the backbone network and fifth information identifying a first backbone network egress device in the backbone network, the ingress endpoint of the first end-to-end path is the first site edge, and the egress endpoint of the first end-to-end path is the second site edge; The second service message is sent through the first end-to-end path.

22. The method according to claim 11, It is characterized in that The first service message is used to carry a virtual private network VPN service. Before receiving the first service message, the method further includes: The first site edge, according to the VPN service, combines the first backbone network ingress device and the first backbone network egress device as needed to orchestrate the first end-to-end path from the first site edge to the second site edge.

23. The method according to claim 21 or 22, It is characterized in that The second service message also includes service intention information.

24. The method according to claim 23, It is characterized in that The service intention information is carried in the metadata field of the second service message.

25. The method according to any one of claims 21 to 24, It is characterized in that Before encapsulating the path information of the first end-to-end path, the method further includes: The first site edge determines that the next hop for forwarding the first service message is the second site edge according to the destination address of the first service message, and iterates the first segment routing policy SR Policy according to the Internet Protocol IP address of the second site edge to obtain the path information of the first end-to-end path.

26. The method according to any one of claims 21 to 25, It is characterized in that The first end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the fourth information and the fifth information.

27. The method according to claim 26, It is characterized in that The fourth information is the first endpoint segment identifier END.SID1 of the first backbone network ingress device, the fifth information is the second endpoint segment identifier END.SID2 of the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

28. The method according to claim 26, It is characterized in that The fourth information is the first endpoint segment identifier END.SID1 of the first backbone network entry device, and the fifth information is the endpoint segment identifier END.X SID with a cross connection to the Layer 3 adjacency relationship array allocated by the first backbone network device egress device for the adjacency relationship between the first backbone network device egress device and the second site edge.

29. The method according to claim 27 or 28, It is characterized in that The operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1.

30. The method according to claim 27 or 28, It is characterized in that When the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 Policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1 and the service intent information.

31. The method according to any one of claims 21 to 25, It is characterized in that The first end-to-end path is a segment routing multi-protocol label switching traffic engineering strategy SR-MPLS TE policy, the second service message includes an MPLS label stack, the MPLS label stack includes the fourth information and the fifth information, the fourth information is the first node SID of the first backbone network ingress device, and the fifth information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID allocated by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

32. The method according to claim 31, It is characterized in that The operation of associating the first node SID includes: An overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched according to the next hop SID of the first node SID in the label stack.

33. The method according to claim 31, It is characterized in that When the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the label stack and the service intent information.

34. The method according to any one of claims 26 to 30, It is characterized in that The first end-to-end path is a tunnel encapsulated based on the general network virtualization encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

35. The method according to any one of claims 36 to 30, It is characterized in that The first end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

36. The method according to claim 35, It is characterized in that The second service message includes: Outer IP header, User Datagram Protocol UDP header, outer GRE encapsulation, IPv6 header, SRH, inner GRE encapsulation and payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

37. The method according to any one of claims 21 to 36, It is characterized in that The method further comprises: Receiving a third service message; The path information of the third end-to-end path is encapsulated in the outer layer of the third service message to obtain the fourth service message; wherein the path information of the third end-to-end path includes sixth information identifying a second backbone network entry device in the backbone network and seventh information identifying a second backbone network exit device in the backbone network, the entry point of the third end-to-end path is the first site edge, the exit point of the third end-to-end path is the second site edge, the third end-to-end path passes through the second backbone network entry device and the second backbone network exit device, the first site edge is multi-homed to access the first backbone network entry device and the second backbone network entry device, and the second site edge is multi-homed to access the first backbone network exit device and the second backbone network exit device; The first site edge sends the fourth service message through the third end-to-end path.

38. The method according to any one of claims 21 to 37, It is characterized in that The first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

39. A method for notifying information, It is characterized in that Applied to a second communication device, the method comprises: Acquire a first route, where the first route includes first information of a first backbone network egress device in the backbone network and an identifier of a second site edge, where the second site edge accesses the backbone network through the first backbone network egress device; The first route is notified to a first site edge, and the first site edge accesses the backbone network through a first backbone network ingress device.

40. The method according to claim 39, It is characterized in that The first information includes one or more of the following: The first backbone network egress device is allocated a first segment identifier SID for an adjacency relationship between the first backbone network egress device and the second site edge; A second SID of the first backbone network egress device; The routing priority of the first backbone network egress device; The load sharing weight of the first backbone network egress device.

41. The method according to claim 40, It is characterized in that The first SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6END.X SID having a cross-connection to a layer 3 adjacency array, and the second SID is an Internet Protocol version 6 segment routing endpoint segment identifier SRv6 END.SID; or, The first SID is an adjacency segment identifier adj-SID, and the second SID is a node SID.

42. The method according to claim 40 or 41, It is characterized in that The second communication device is the second site edge, and the first route includes: a software-defined wide area network SD-WAN gateway information announcement route, and the SD-WAN gateway information announcement route includes at least one type-length value TLV, and the at least one TLV carries the first information.

43. The method according to claim 42, It is characterized in that The SD-WAN gateway information announcement route includes a first TLV, the value field of the first TLV is used to carry the first SID and / or second SID in the first information, the first TLV also includes a priority sub-TLV and / or a weight sub-TLV, the priority sub-TLV is used to carry the routing priority in the first information, and the weight sub-TLV is used to carry the load sharing weight in the first information.

44. The method according to claim 40 or 41, It is characterized in that The second communication device is the second site edge, and the first route includes a virtual private network VPN route.

45. The method according to claim 44, It is characterized in that The VPN route includes a first metadata path attribute Metadata Path Attribute, and the first Metadata Path Attribute carries the first information.

46. ​​The method according to any one of claims 39 to 45, It is characterized in that The first route also includes: business intention information.

47. The method according to claim 46, It is characterized in that The business intention information includes one or more of the following: The gateways that the business traffic needs to pass through, the gateways that the business traffic needs to bypass when transmitting, and the quality of service parameters that need to be met when transmitting the business traffic.

48. The method according to claim 46 or 47, It is characterized in that The first route includes a second Metadata Path Attribute, and the second Metadata Path Attribute includes the business intent information.

49. The method according to any one of claims 39 to 41, It is characterized in that The second communication device is the first backbone network egress device, and the notifying the first route to the first site edge includes: The first route is announced to the first site edge through the first backbone network ingress device.

50. The method according to claim 49, It is characterized in that The first route includes: the first SD-WAN gateway automatically discovers the route.

51. The method according to any one of claims 42 to 45, It is characterized in that The method further comprises: A second route is notified to the first site edge, where the second route includes second information of a second backbone network egress device in the backbone network and an identifier of the second site edge, and the second site edge accesses the backbone network through the second backbone network egress device.

52. The method according to any one of claims 42 to 45, It is characterized in that The method further comprises: receiving a third route sent by the first backbone network egress device, where the third route is used to notify the first backbone network egress device of third information; According to the third route, a first binding relationship between the second site edge and the first backbone network egress device is obtained.

53. The method according to claim 52, It is characterized in that The third information includes: a third SID allocated by the first backbone network egress device for the adjacency relationship between the first backbone network egress device and the second site edge, and / or a fourth SID of the first backbone network egress device.

54. The method according to claim 52 or 53, It is characterized in that The method further comprises: receiving a fourth route sent by a second backbone network egress device, wherein the fourth route is used to notify fourth information of the second backbone network egress device; According to the fourth route, a second binding relationship between the second site edge and the second backbone network egress device is obtained.

55. The method according to claim 54, It is characterized in that The method further comprises: Determine the routing priorities corresponding to the first backbone network egress device and the second backbone network egress device respectively; and / or, Determine the load sharing weights corresponding to the first backbone network egress device and the second backbone network egress device respectively.

56. The method according to any one of claims 52 to 55, It is characterized in that The third route is the route automatically discovered by the second SD-WAN gateway.

57. The method according to any one of claims 52 to 55, It is characterized in that The third route is a BGP link state LS route, and the BGP LS route includes a second TLV, and the second TLV indicates that the third route is used to notify third information of the first backbone network egress device.

58. The method according to claim 57, It is characterized in that The second TLV is a role announcement TLV, and the role announcement TLV indicates that the role of the first backbone network egress device is a gateway.

59. The method according to any one of claims 52 to 58, It is characterized in that The third route also includes intermediate gateway information, and the intermediate gateway information indicates at least one intermediate gateway between a backbone network ingress device in the backbone network and the first backbone network egress device.

60. The method according to claim 59, It is characterized in that The third route includes a third Metadata Path Attribute, and the third Metadata Path Attribute carries the intermediate gateway information.

61. The method according to claim 59 or 60, It is characterized in that The method further comprises: According to the intermediate gateway information, gateway constraint information in the service intention information is determined, where the gateway constraint information indicates a gateway constraint condition that needs to be followed in determining a path to reach the second site edge.

62. The method according to claim 61, It is characterized in that The gateway constraints include: Gateways that need to be passed through and / or gateways that need to be detoured.

63. A method for notifying information, It is characterized in that Applied to a first backbone network entry device in a backbone network, the method comprises: receiving a first route announced by a first backbone network egress device in the backbone network, wherein the first route includes information of the first backbone network egress device and an identifier of a second site edge, the second site edge accesses the backbone network through the first backbone network egress device, and the first site edge accesses the backbone network through the first backbone network ingress device; The first route is advertised to the first site edge.

64. The method according to claim 63, It is characterized in that The method further comprises: Receive a second service message from a first site edge edge, the payload of the second service message includes the first service message, the outer layer of the first service message encapsulates path information of an end-to-end path between the first site edge and the second site edge; wherein the path information of the end-to-end path includes: first information identifying the first backbone network ingress device and second information identifying the first backbone network egress device in the backbone network, the ingress endpoint of the end-to-end path is the first site edge, the egress endpoint of the end-to-end path is the second site edge, the end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; Processing the second service message according to the first information to obtain a third service message; The first backbone network ingress device sends the third service message to the first backbone network egress device.

65. The method according to claim 64, It is characterized in that The second service message also includes service intention information.

66. The method according to claim 65, It is characterized in that The service intention information is carried in the metadata field of the second service message.

67. The method according to any one of claims 64 to 66, It is characterized in that The end-to-end path is an SRv6 tunnel, the second service message includes an IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

68. The method according to claim 67, It is characterized in that The first information is the first endpoint segment identifier END.SID1 allocated by the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 allocated by the first backbone network egress device, and the SRH also includes the IPv6 address of the second site edge.

69. The method according to claim 67, It is characterized in that The first information is the first endpoint segment identifier END.SID1 of the first backbone network entry device, and the second information is the endpoint segment identifier END.XSID with a cross-connection to the Layer 3 adjacency relationship array allocated by the first backbone network device egress device for the adjacency relationship between the first backbone network device egress device and the second site edge.

70. The method according to claim 68 or 69, It is characterized in that The operation of associating the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1 in the SRH.

71. The method according to claim 68 or 69, It is characterized in that When the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy from the first backbone network ingress device to the first backbone network egress device according to the next hop SID of the END.SID1 in the SRH and the service intent information.

72. The method according to claim 70, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: Matching a first overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of END.SID1 in the SRH; The second service message is encapsulated by using the first overly SRv6 policy to obtain the third service message.

73. The method according to claim 71, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: Matching a second overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1 in the SRH and the service intent information; The second service message is encapsulated by using the second overly SRv6 Policy to obtain the third service message.

74. The method according to any one of claims 64 to 66, It is characterized in that The end-to-end path is a segment routing multi-protocol label switching traffic engineering strategy SR-MPLS TE policy, the second service message includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID allocated by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

75. The method according to claim 74, It is characterized in that The operation of associating the first node SID includes: An upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched according to the next hop SID of the first node SID in the label stack.

76. The method according to claim 74, It is characterized in that When the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy from the first backbone network ingress device to the first backbone network egress device according to the next hop SID of the first node SID in the label stack and the service intent information.

77. The method according to claim 75, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: According to the next hop SID of the first node SID in the label stack, a first overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched; The second service message is encapsulated by using the first overly SR-MPLS TE policy to obtain the third service message.

78. The method according to claim 76, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: According to the next hop SID of the first node SID in the label stack and the service intent information, a second overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched; The second service message is encapsulated by using the second overly SR-MPLS TE policy to obtain the third service message.

79. The method according to any one of claims 67 to 73, It is characterized in that The end-to-end path is a tunnel encapsulated based on the general network virtualization encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

80. The method according to any one of claims 67 to 73, It is characterized in that The end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

81. The method according to claim 80, It is characterized in that The second service message includes: Outer IP header, User Datagram Protocol UDP header, outer GRE encapsulation, IPv6 header, SRH, inner GRE encapsulation and payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

82. The method according to any one of claims 64 to 81, It is characterized in that The first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

83. A communication device, It is characterized in that The device comprises: Transceiver unit and processing unit; The transceiver unit is used to perform the receiving and / or sending operations performed by the first communication device as described in any one of claims 1-38; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the first communication device as described in any one of claims 1-38; or, The transceiver unit is used to perform the receiving and / or sending operations performed by the second communication device as described in any one of claims 39-62; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the second communication device as described in any one of claims 39-62; or, The transceiver unit is used to perform the receiving and / or sending operations performed by the first backbone network access device as described in any one of claims 63-82; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the first backbone network access device as described in any one of claims 63-82.

84. A communication device, It is characterized in that include: Processor and memory; The memory is used to store instructions; The processor is used to execute the instructions so that the communication device executes the method described in any one of claims 1-82.

85. A communication system, It is characterized in that The system comprises: A first communication device for executing the method described in any one of claims 1 to 38 above, and a second communication device for executing the method described in any one of claims 39 to 62 above; or, A first communication device for executing the method described in any one of claims 1 to 38, and a first backbone network access device for executing the method described in any one of claims 63 to 82.

86. A computer readable storage medium, It is characterized in that The method comprises instructions or computer programs, which, when executed on a processor, implement the method described in any one of claims 1 to 82. 87.A method for forwarding traffic, It is characterized in that The method comprises: The first site edge receives the first service message; The first site edge encapsulates the path information of the first end-to-end path in the outer layer of the first service message to obtain the second service message; wherein the path information of the first end-to-end path includes first information identifying a first backbone network ingress device in the backbone network and second information identifying a first backbone network egress device in the backbone network, the ingress endpoint of the first end-to-end path is the first site edge, the egress endpoint of the first end-to-end path is the second site edge, the first end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; The first site edge sends the second service message through the first end-to-end path.

88. The method according to claim 87, It is characterized in that The first service message is used to carry a virtual private network VPN service. Before receiving the first service message, the method further includes: The first site edge, according to the VPN service, combines the first backbone network ingress device and the first backbone network egress device as needed to orchestrate the first end-to-end path from the first site edge to the second site edge.

89. The method according to claim 87 or 88, It is characterized in that The second service message also includes service intention information.

90. The method according to claim 89, It is characterized in that The service intention information is carried in the metadata field of the second service message.

91. The method according to any one of claims 87 to 90, It is characterized in that Before encapsulating the path information of the first end-to-end path, the method further includes: The first site edge determines that the next hop for forwarding the first service message is the second site edge according to the destination address of the first service message, and iterates the first segment routing policy SR Policy according to the Internet Protocol IP address of the second site edge to obtain the path information of the first end-to-end path.

92. The method according to any one of claims 87 to 91, It is characterized in that The first end-to-end path is an SRv6 tunnel, the second service message includes an Internet Protocol version 6 IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

93. The method according to claim 92, It is characterized in that The first information is the first endpoint segment identifier END.SID1 of the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 of the first backbone network egress device, and the SRH further includes the IPv6 address of the second site edge.

94. The method according to claim 92, It is characterized in that The first information is the first endpoint segment identifier END.SID1 of the first backbone network entry device, and the second information is the endpoint segment identifier END.XSID with a cross-connection to the Layer 3 adjacency relationship array allocated by the first backbone network device egress device for the adjacency relationship between the first backbone network device egress device and the second site edge.

95. The method according to claim 93 or 94, It is characterized in that The operation associated with the first endpoint segment identifier END.SID1 includes: matching an upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1.

96. The method according to claim 93 or 94, It is characterized in that When the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1 and the service intent information.

97. The method according to any one of claims 87 to 91, It is characterized in that The first end-to-end path is a segment routing multi-protocol label switching traffic engineering strategy SR-MPLS TE policy, the second service message includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID allocated by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

98. The method according to claim 97, It is characterized in that The operation of associating the first node SID includes: An overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched according to the next hop SID of the first node SID in the label stack.

99. The method according to claim 97, It is characterized in that When the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the first node SID in the label stack and the service intent information.

100. The method according to any one of claims 92 to 96, It is characterized in that The first end-to-end path is a tunnel encapsulated based on the general network virtualization encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

101. The method according to any one of claims 92 to 96, It is characterized in that The first end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

102. The method according to claim 101, It is characterized in that The second service message includes: Outer IP header, User Datagram Protocol UDP header, outer GRE encapsulation, IPv6 header, SRH, inner GRE encapsulation and payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

103. The method according to any one of claims 87 to 102, It is characterized in that The method further comprises: The first site edge receives the third service message; The first site edge encapsulates the path information of the second end-to-end path in the outer layer of the third service message to obtain a fourth service message; wherein the path information of the second end-to-end path includes third information identifying a second backbone network ingress device in the backbone network and fourth information identifying a second backbone network egress device in the backbone network, the ingress endpoint of the second end-to-end path is the first site edge, the egress endpoint of the second end-to-end path is the second site edge, the second end-to-end path passes through the second backbone network ingress device and the second backbone network egress device, the first site edge multi-homes access the first backbone network ingress device and the second backbone network ingress device, and the second site edge multi-homes access the first backbone network egress device and the second backbone network egress device; The first site edge sends the fourth service message through the second end-to-end path.

104. The method according to any one of claims 87 to 103, It is characterized in that The first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet. 105.A method for forwarding traffic, It is characterized in that The method comprises: A first backbone network ingress device in a backbone network receives a second service message from a first site edge edge, the payload of the second service message includes the first service message, and the outer layer of the first service message encapsulates path information of an end-to-end path between the first site edge and the second site edge; wherein the path information of the end-to-end path includes: first information identifying the first backbone network ingress device and second information identifying the first backbone network egress device in the backbone network, the ingress endpoint of the end-to-end path is the first site edge, the egress endpoint of the end-to-end path is the second site edge, the end-to-end path passes through the first backbone network ingress device and the first backbone network egress device, the first site edge accesses the backbone network through the first backbone network ingress device, and the second site edge accesses the backbone network through the first backbone network egress device; The first backbone network ingress device processes the second service message according to the first information to obtain a third service message; The first backbone network ingress device sends the third service message to the first backbone network egress device.

106. The method according to claim 105, It is characterized in that The second service message also includes service intention information.

107. The method according to claim 106, It is characterized in that The service intention information is carried in the metadata field of the second service message.

108. The method according to any one of claims 105-107, It is characterized in that The end-to-end path is an SRv6 tunnel, the second service message includes an Internet Protocol version 6 IPv6 header and a segment routing header SRH, the destination address of the IPv6 header points to the first backbone network ingress device, and the SRH includes the first information and the second information.

109. The method according to claim 108, It is characterized in that The first information is the first endpoint segment identifier END.SID1 allocated by the first backbone network ingress device, the second information is the second endpoint segment identifier END.SID2 allocated by the first backbone network egress device, and the SRH also includes the IPv6 address of the second site edge.

110. The method according to claim 108, It is characterized in that The first information is the first endpoint segment identifier END.SID1 of the first backbone network ingress device, and the second information is the endpoint segment identifier END.X SID with a cross connection to a layer 3 adjacency relationship array allocated by the first backbone network device egress device for the adjacency relationship between the first backbone network device egress device and the second site edge.

111. The method according to claim 109 or 110, It is characterized in that The operation of associating the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1 in the SRH.

112. The method according to claim 109 or 110, It is characterized in that When the second service message includes service intent information, the operation associated with the first endpoint segment identifier END.SID1 includes: matching the upper layer overly SRv6 policy from the first backbone network ingress device to the first backbone network egress device according to the next hop SID of the END.SID1 in the SRH and the service intent information.

113. The method according to claim 111, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: Matching a first overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of END.SID1 in the SRH; The second service message is encapsulated by using the first overly SRv6 policy to obtain the third service message.

114. The method according to claim 111, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: Matching a second overly SRv6 policy between the first backbone network ingress device and the first backbone network egress device according to the next hop SID of the END.SID1 in the SRH and the service intent information; The second service message is encapsulated by using the second overly SRv6 Policy to obtain the third service message.

115. The method according to any one of claims 105-107, It is characterized in that The end-to-end path is a segment routing multi-protocol label switching traffic engineering strategy SR-MPLS TE policy, the second service message includes an MPLS label stack, the MPLS label stack includes the first information and the second information, the first information is the first node SID of the first backbone network ingress device, and the second information includes: the second node SID of the first backbone network egress device, and the adjacency segment identifier adj-SID allocated by the first backbone network device egress device to the adjacency relationship between the first backbone network device egress device and the second site edge.

116. The method according to claim 115, It is characterized in that The operation of associating the first node SID includes: An upper layer overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched according to the next hop SID of the first node SID in the label stack.

117. The method according to claim 115, It is characterized in that When the second service message includes service intent information, the operation of associating the first node SID includes: matching the upper layer overly SR-MPLS TE policy from the first backbone network ingress device to the first backbone network egress device according to the next hop SID of the first node SID in the label stack and the service intent information.

118. The method according to claim 116, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: According to the next hop SID of the first node SID in the label stack, a first overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched; The second service message is encapsulated by using the first overly SR-MPLS TE policy to obtain the third service message.

119. The method according to claim 117, It is characterized in that The processing, according to the first information, of the second service message to obtain a third service message includes: According to the next hop SID of the first node SID in the label stack and the service intent information, a second overly SR-MPLS TE policy between the first backbone network ingress device and the first backbone network egress device is matched; The second service message is encapsulated by using the second overly SR-MPLS TE policy to obtain the third service message.

120. The method according to any one of claims 108 to 114, It is characterized in that The end-to-end path is a tunnel encapsulated based on the general network virtualization encapsulation GENEVE protocol, and the second service message is encapsulated using SRv6 in GENEVE.

121. The method according to any one of claims 108 to 114, It is characterized in that The end-to-end path is a tunnel encapsulated based on the Generic Routing Encapsulation (GRE) protocol, and the second service message includes SRv6 over GRE encapsulation.

122. The method according to claim 121, It is characterized in that The second service message includes: Outer IP header, User Datagram Protocol UDP header, outer GRE encapsulation, IPv6 header, SRH, inner GRE encapsulation and payload, the payload includes the first service message, and the inner GRE encapsulation includes the VPN identifier of the VPN service carried by the first service message.

123. The method according to any one of claims 105-123, It is characterized in that The first site edge accesses the first backbone network entry device through a software-defined wide area network SD-WAN tunnel or the Internet.

124. A communication device, It is characterized in that The device comprises: Transceiver unit and processing unit; The transceiver unit is used to perform the receiving and / or sending operations performed by the first site edge as described in any one of claims 87-104; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the first site edge as described in any one of claims 87-104; or, The transceiver unit is used to perform the receiving and / or sending operations performed by the first backbone network access device as described in any one of claims 105-123; the processing unit is used to perform operations other than the receiving and / or sending operations performed by the first backbone network access device as described in any one of claims 105-123.

125. A communication device, It is characterized in that include: Processor and memory; The memory is used to store instructions; The processor is used to execute the instructions so that the communication device executes the method described in any one of claims 87-123.

126. A communication system, It is characterized in that The system comprises: A first site edge that executes the method described in any one of claims 87-104, and a first backbone network entry device that executes the method described in any one of claims 105-123.

127. A computer-readable storage medium, It is characterized in that The method comprises instructions or computer programs, which, when executed on a processor, implement the method described in any one of claims 87 to 123.

128. A computer program product, It is characterized in that It comprises a computer program which, when running on a processor, executes the method described in any one of claims 1 to 82 or any one of claims 87 to 123.

Images