Service route advertisement and determination method, computing power route gateway, and storage medium

Abstract

The present application discloses a service route advertisement and determination method, a computing power route gateway, and a storage medium. The service route advertisement method comprises: acquiring service state data of a service instance connected to a cloud side computing power route gateway; obtaining a target service metric value on the basis of the service state data, wherein the target service metric value represents a service providing capability of the service instance; and by means of a border gateway protocol (BGP), advertising, to an access side computing power route gateway in a computing power network system, target service route data carrying a service identifier and the target service metric value, so that the access side computing power route gateway determines a target cloud side computing power route gateway from cloud side computing power route gateways on the basis of the target service metric value.

Description

Service routing notification and determination method, computing power routing gateway and storage medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application No. 202311450444.0 filed on November 1, 2023, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communication networks, and in particular to a service routing notification and determination method, a computing power routing gateway, and a storage medium. Background Art

[0004] With the development of the times, 5G-driven edge computing has become a hot topic, and a new technical form and operation model of computing power network has emerged. In the current communication network industry, how computing power network perceives, processes and analyzes the status information of large amounts of dynamic, complex and obscure service instances has become an urgent problem to be solved.

[0005] However, the current service routing methods in the industry have poor capabilities in processing and analyzing large amounts of service status data and are unable to dynamically adapt to changes in service status data, resulting in poor network routing service quality.

[0006] Summary of the Invention

[0007] The main purpose of this application is to provide a service routing notification and determination method, a computing power routing gateway and a storage medium.

[0008] The present application provides a service routing announcement method, which is applied to a cloud-side computing power routing gateway in a computing power network system. The service routing announcement method includes the following steps: obtaining service status data of a service instance connected to the cloud-side computing power routing gateway; obtaining a target service metric value based on the service status data, wherein the target service metric value represents the service provision capability of the service instance; and notifying the access-side computing power routing gateway in the computing power network system through the Border Gateway Protocol (BGP) protocol, the target service routing data carrying the service identifier and the target service metric value, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway from the cloud-side computing power routing gateways based on the target service metric value.

[0009] The present application also provides a service routing determination method, which is applied to the access-side computing power routing gateway in the computing power network system. The service routing notification method includes the following steps: receiving target service routing data sent by at least one cloud-side computing power routing gateway in the computing power network system through the Border Gateway Protocol BGP protocol, the target service routing data carrying a service identifier and a target service metric value, the target service metric value is obtained by the cloud-side computing power routing gateway based on the service status data of the service instance connected to the cloud-side computing power routing gateway, and the target service metric value represents the service provision capability of the service instance; based on the target service metric value, determining the target cloud-side computing power routing gateway from the at least one cloud-side computing power routing gateway.

[0010] An embodiment of the present application also proposes a computing power routing gateway, which includes a processor, a memory, a computer program stored on the memory and executable by the processor, and a data bus for realizing connection and communication between the processor and the memory. When the computer program is executed by the processor, the steps of the service routing announcement method or the steps of the service routing determination method described above are implemented.

[0011] An embodiment of the present application also proposes a storage medium for computer-readable storage, wherein the storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the service route announcement method or the steps of the service route determination method as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG1 is a schematic diagram of an application scenario of computing power perception and computing power routing in the service routing notification and determination method of this application;

[0013] FIG2 is a flow chart of a first exemplary embodiment of the service routing advertisement method of the present application;

[0014] FIG3 is a schematic diagram of the decision-making process of the cloud-side computing power routing gateway for computing power routing announcement in the first exemplary embodiment of the service routing announcement method of this application;

[0015] FIG4 is a flow chart of a seventh exemplary embodiment of the method for determining a service route of the present application;

[0016] FIG5 is a logical diagram of the service routing next hop decision made by the access-side computing power routing gateway in the seventh exemplary embodiment of the service routing determination method of the present application;

[0017] FIG6 is a logic diagram of calculating the conversion value of the joint parameter in the ninth exemplary embodiment of the service route determination method of the present application;

[0018] FIG7 is a logical diagram of VPN route publication and VPN route iteration in the twelfth exemplary embodiment of the service route notification and determination method of the present application;

[0019] FIG8 is a logical diagram of service route announcement and service route iteration in the twelfth exemplary embodiment of the service route announcement and determination method of the present application;

[0020] FIG9 is a logical diagram of the converted target service metric value in the twelfth exemplary embodiment of the service route notification and determination method of the present application;

[0021] 10 is a logical diagram of dynamic routing policy mapping based on target service metric values ​​in the twelfth exemplary embodiment of the service routing notification and determination method of the present application;

[0022] FIG11 is a schematic diagram of the uplink and downlink flow of the first packet in the fourteenth exemplary embodiment of the service route notification and determination method of the present application;

[0023] FIG12 is a schematic diagram of the process of uplink continuation of a packet in the fourteenth exemplary embodiment of the service route notification and determination method of the present application;

[0024] FIG13 is a schematic diagram of the functional modules of an embodiment of a computing power routing gateway of the present application.

[0025] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0026] The specific embodiments described herein are merely used to explain the present application and are not intended to limit the present application.

[0027] The main solution of the embodiment of the present application is: obtaining the service status data of the service instance connected to the cloud-side computing power routing gateway; obtaining the target service metric value based on the service status data, and the target service metric value represents the service provision capability of the service instance; notifying the access-side computing power routing gateway in the computing power network system through the Border Gateway Protocol BGP protocol, carrying the target service routing data carrying the service identifier and the target service metric value, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway from the cloud-side computing power routing gateway according to the target service metric value.

[0028] The embodiments of the present application take into account that, in the context of the current industry's demand for networks gradually shifting from host-oriented addressing to service-oriented, computing power-oriented, and resource-oriented addressing, a new technical form and operation model of computing power network has emerged. Providing common Internet services based on integrated computing and network facilities is conducive to accelerating innovation, reducing deployment costs, improving resource utilization, and promoting the development of the social digital economy.

[0029] Unlike traditional networks, computing power networks require service addressing and routing based on a computing-network integration perspective. Accordingly, achieving dynamic state awareness of computing power and service-side information is the premise and foundation for effective service routing. The state information of computing power resources has the following characteristics:

[0030] (1) With the development of technologies such as container technology, microservice architecture, and Serverless architecture, computing power and service instances are showing a trend of heterogeneous development. For a type of service, there are often service instances distributed in multiple regions and in different forms that can provide this type of service. Therefore, in the future scenario of computing power network, the number of service instances is expected to be large.

[0031] (2) Service instance status information, such as real-time CPU utilization, real-time memory usage, and real-time TCP connection count, is often highly dynamic and continuously changing. Therefore, if the dynamic nature of computing power status changes is directly fed back to the network, it will place a huge burden on the network control plane.

[0032] (3) Compared with the status information in traditional networks, the status information of service instances has both homogeneous attributes, such as service instance processing delay and network link transmission delay, and attributes of different dimensions, such as the number of CPU cores and CPU frequency. Therefore, the computing power network needs to have the ability to process and analyze multi-dimensional attributes.

[0033] (4) The attributes of different dimensions in the status information of service instances, such as the number of CPU cores and CPU frequency, do not have semantic interpretation for the network. In addition, the status information of service instances has many dimensions. Reflecting a large amount of multi-dimensional semantic information in the network will greatly increase the difficulty of network interpretation.

[0034] (5) In view of the characteristics of the above-mentioned service status data, how the computing power network perceives, processes and analyzes the status information of large amounts of dynamic, complex and obscure service instances has become an urgent problem to be solved.

[0035] Based on the above analysis, the first issues that need to be addressed in computing power networks are computing power measurement and modeling. Currently, industry researchers have conducted research on computing power measurement and modeling. The goal of computing power measurement in computing power networks is to link and integrate heterogeneous resources, enabling unified and collaborative management of multi-dimensional resources. This, in turn, addresses future differentiated business needs through a unified computing power measurement system and a mapping mechanism for heterogeneous computing resources, achieving the rational allocation and efficient call of computing power resources. Research on computing power measurement and modeling has, to a certain extent, addressed the issues of heterogeneity in computing power service instances and diversification in computing power services, providing a basis for unified service capability characterization.

[0036] Based on the standard measurement and modeling of computing power, the next challenge is to achieve the publication and notification of standardized computing power modeling attributes. In traditional networks, the IGP protocol is a protocol for exchanging routing information between gateways (hosts and routers) within an autonomous network. Routing information can be used by the Internet Protocol (IP) or other network protocols to describe how routing is carried out. Correspondingly, the BGP protocol is used to exchange routing information between different autonomous systems (ASs). Therefore, to introduce service status data into the network to implement service routing without disrupting the traditional network architecture or affecting the implementation of traditional network services, numerous industry studies are considering using IGP or BGP extensions to implement the carrying, publication, and notification of service status data within the network. Related technologies have proposed methods for extending the BGP protocol to carry service status attribute information for network notification and publication, including methods for extending the OSPF (Open Shortest Path First) protocol to carry service status attribute information for network notification and publication. However, for example, suppose there are 100 computing power routing gateway devices deployed in the network, and the cloud resource pool at each computing power routing gateway deploys 100 service instances capable of providing a certain type of service. The status information of the service instances is characterized by six parameters: computing rate, memory capacity, memory bandwidth, storage capacity, storage bandwidth, and load. Therefore, each computing power routing gateway in the network still needs to generate and maintain a table of 10,000 service instance entries and 60,000 parameters in real time. Making decisions based on 60,000 status parameters for the computing power routing gateway is still very complex. Therefore, directly bringing the status information of service instances into the network in the form of a set of metadata still faces the problem of a large number of service instances and the network's lack of ability to interpret service status data.

[0037] In related technologies, a method for converting Service Metrics and a hierarchical computing power perception and computing power routing architecture are proposed for computing power perception and computing power routing. The conversion of Service Metrics converts the multi-dimensional service instance status information into a unique Service Metric value based on the service type, service constraint, and scheduling strategy, which represents the service provision capability and scheduling priority of a service instance. Hierarchical computing power perception and computing power routing means that the cloud-side computing power routing gateway aggregates the service capabilities of each service instance in the resource pool it is connected to and publishes them to the remote access-side computing power routing gateway. The access-side computing power routing gateway first guides the business traffic to a cloud-side computing power routing gateway, i.e., a resource pool, based on the aggregated service capability information of each resource pool. The cloud-side computing power routing gateway then guides the business traffic to a specific service instance. Similarly, for the above example, 100 computing power routing gateway devices are deployed in the network, and the cloud resource pool at each computing power routing gateway deploys 100 service instances that can provide a certain type of service. The status information of the service instance is represented by a unique Service Metric value. At this point, each computing power routing gateway in the network only needs to generate and maintain in real time 100 local service instance entries and 100 global computing power routing gateway entries. Scheduling decisions are standardized based on the current forwarding hierarchy and the 100 service metrics. Therefore, service metric conversion and hierarchical computing power routing address the computing power network's need to perceive, process, and analyze large amounts of dynamic, complex, and obscure service instance status information to make computing power routing decisions.

[0038] In addition, computing power routing and service routing emphasize end-to-end service quality assurance in business scheduling. However, due to the dynamic nature of computing power status information and possible degradation scenarios, the end-to-end requirements of computing power routing and service routing are often dynamically decomposed into network segments.

[0039] For example, service A has a constraint that the end-to-end latency must not exceed 50ms. At a certain moment, service traffic is directed to service instance X. At this time, the processing latency of service instance X is 10ms. Therefore, the network side only needs to provide a transmission capacity of no more than 40ms. After a period of time, due to various possible reasons, the processing latency of service instance X deteriorates to 30ms. However, since service instance X is not actually disabled, the service traffic originally directed to service instance X will still be sent to service instance X for service affinity. However, due to the degradation of service instance X, the network side needs to provide a transmission capacity of no more than 20ms.

[0040] Therefore, unlike traditional business routing, computing power routing and service routing require the network to dynamically and adaptively match the computing power status and provide and guarantee network capabilities.

[0041] Based on this, an embodiment of the present application proposes a solution, which is to obtain the service status data of the service instance connected to the cloud-side computing power routing gateway; obtain the target service metric value based on the service status data, and the target service metric value represents the service provision capability of the service instance; notify the access-side computing power routing gateway in the computing power network system of the target service routing data carrying the service identifier and the target service metric value through the Border Gateway Protocol BGP protocol, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway from the cloud-side computing power routing gateway based on the target service metric value. Based on the solution of the present application, the cloud-side computing power routing gateway converts the service provision capability of the service instance into the target service metric value, and carries the target service metric value in the target service routing data to notify the access-side computing power routing gateway, thereby improving the processing and analysis capabilities of a large amount of service status data, dynamically adapting to changes in service status data, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway based on the service provision capability of the service instance, dynamically adapting to network computing power requirements, and improving network service quality.

[0042] Refer to Figure 1, which is a schematic diagram of the application scenario of computing power perception and computing power routing in this embodiment; as shown in Figure 1, the method proposed in the embodiment of the present application is mainly used in a computing power network system, and the computing power network system at least includes a cloud-side computing power routing gateway and an access-side computing power routing gateway. In addition, the cloud-side computing power routing gateway establishes a connection with the service instance. Through the cloud-side computing power routing gateway, the state perception of the dynamic state information of the computing power and the service side can be realized, and the perception results are carried in the service routing data through data conversion and data aggregation and notified to the access-side computing power routing gateway, effectively reducing and simplifying the service status data published and notified in the network, and reducing the system burden.

[0043] Based on the scenario diagram shown in FIG1 , a first embodiment of the service routing method of the present application is proposed.

[0044] 2, which is a flowchart of a first exemplary embodiment of the service routing announcement method of the present application, is applied to a cloud-side computing power routing gateway in a computing power network system, and includes steps S10 to S30.

[0045] Step S10: Obtain service status data of the service instance connected to the cloud-side computing power routing gateway.

[0046] As shown in Figure 1, a communication connection is established between the cloud-side computing power routing gateway and the service instance. The service instance can publish service status data externally through itself or to the cloud-side computing power routing gateway. The service instance is used to provide certain types of network services, including experience-prioritized services and resource-prioritized services. For example, a cloud-side computing power routing gateway has one service instance. The service status data of this service instance is characterized by parameters, which may include six parameters: computing rate, memory capacity, memory bandwidth, storage capacity, storage bandwidth, and load. These six parameters can be used to determine whether the service instance is suitable for experience-prioritized services or resource-prioritized services.

[0047] Step S20: obtaining a target service metric value according to the service status data, wherein the target service metric value represents the service provision capability of the service instance.

[0048] In this embodiment, the cloud-side computing power routing gateway converts and aggregates the service status data to obtain the target service metric value; alternatively, the cloud-side computing power routing gateway converts or aggregates the service status data to obtain the target service metric value. By monitoring and analyzing service status data, key indicators such as service performance, availability, and throughput can be understood, and the target service metric value can be calculated. These metrics reflect the service quality and performance level of the service instance, help evaluate the reliability and scalability of the service, and provide guidance for optimizing and improving the service.

[0049] Step S30, notifying the target service routing data carrying the service identifier and the target service metric value to the access-side computing power routing gateway in the computing power network system through the Border Gateway Protocol BGP protocol, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway from the cloud-side computing power routing gateway according to the target service metric value.

[0050] In this embodiment, the cloud-side computing power routing gateway extends the BGP protocol to publish target service routing data with a service identifier as a key value and carrying a unique target service metric value. The cloud-side computing power routing gateway uses the BGP protocol's routing announcement mechanism to extend the BGP transmission data content to carry the target service metric value and the service identifier as a key value. The service identifier and target service metric value can be transmitted to different nodes in the computing power network system, allowing network nodes to select the most suitable cloud-side computing power routing gateway based on the target service metric value, thereby achieving more efficient service routing and resource allocation.

[0051] Referring to FIG3 , FIG3 is a schematic diagram of the decision-making process of the cloud-side computing power routing gateway for computing power routing announcement in an embodiment of the present application; As shown in FIG3 , this embodiment takes the service instance IPv4 (Internet Protocol Version 4) address as an example. The service instance address is carried in the NLRI (Network Layer Reachability Information) field in the BGP Update (BGP Update Information) message. In this embodiment, the service status data of the service instance is transmitted with computing power perception using the service instance as the key value, and the cloud-side computing power routing gateway converts the service status data carried in the Path Attribute (path attribute) field in the BGP Update message to calculate the target service metric value, which is used to characterize the ability of a service instance to provide a class of service. And generate local RIB (Routing Information Base) table entries and FIB (Forwarding Information Base) table entries. The RIB table entries are used to implement routing protocols and static routing selection, and the FIB table entries are used to perform routing forwarding packets.

[0052] In one embodiment, as shown in FIG3 , service instances Instance 1 and Instance 2 can provide two types of services: Service 1 and Service 2. Service 1 is an experience-first service, and scheduling of this type of service aims to achieve the lowest end-to-end latency. Service 2 is a resource-first service, and scheduling of this type of service aims to achieve the lowest instance load while satisfying the constraints (end-to-end latency no greater than 50ms, and latency from the cloud-side computing power routing gateway to the service instance segment no greater than 20ms). The status information of Instance 1 and Instance 2 (latency from the cloud-side computing power routing gateway to the service instance segment, instance load) are (15ms, 60%) and (25ms, 30%), respectively. Therefore, for different services, Service 1 and Service 2, the service capabilities of the service instances can be represented by the Service Metric values ​​in FIG3 , where Service Metric is also the target service metric value in this embodiment. Based on the converted Service Metric value, local service RIB and FIB entries are generated at the cloud-side computing power routing gateway.

[0053] In Figure 3, for different types of services (Service 1 is a delay-sensitive service, optimized for minimum end-to-end delay; Service 2 is a resource-based service, optimized for minimum load with delay as a constraint), the Service Metric conversion method is as follows: Service ID 1: Service Metric = f1(delay) = delay Service ID 2:

[0054] In the above formula, Service ID 1 is the service identifier of Service 1, Service ID 2 is the service identifier of Service 2, delay is the delay from the cloud-side routing gateway to the service instance, and load is the instance load corresponding to the service instance.

[0055] The cloud-side computing power routing gateway notifies the access computing power routing gateway of the target service routing data carrying the service identifier and the target service metric value, so that the access-side computing power routing gateway can make a service routing next-hop decision and obtain the target next-hop. The target next-hop is used by the access-side computing power routing gateway to determine the target cloud-side computing power routing gateway, and perform routing iteration based on the target service routing data and the target cloud-side computing power routing gateway to determine the specific routing path from the access-side computing power routing gateway to the target cloud-side computing power routing gateway.

[0056] This embodiment, through the above-mentioned scheme, obtains the service status data of the service instance connected to the cloud-side computing power routing gateway; obtains the target service metric value based on the service status data, and the target service metric value represents the service provision capability of the service instance; and notifies the access-side computing power routing gateway in the computing power network system of the target service routing data carrying the service identifier and the target service metric value through the Border Gateway Protocol (BGP) protocol, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway from the cloud-side computing power routing gateway based on the target service metric value. Based on the scheme of this application, the cloud-side computing power routing gateway converts the service provision capability of the service instance into the target service metric value and carries the target service metric value in the target service routing data to notify the access-side computing power routing gateway, thereby improving the processing and analysis capabilities of large amounts of service status data and dynamically adapting to changes in service status data, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway based on the service provision capability of the service instance, dynamically adapting to network computing power requirements, and improving network service quality.

[0057] Based on the above first embodiment, a second embodiment of the service routing method of this application is proposed. The difference between this embodiment and the first embodiment is that, in this embodiment, the service routing notification method further includes:

[0058] In the case where there is only one service instance, the target service metric value is converted from the service status data of the service instance, and the target service metric value represents the service provision capability of the service instance.

[0059] In one embodiment, when there is only one service instance, this embodiment converts the service status data corresponding to the service instance through the cloud-side computing power routing gateway. The method for obtaining the target service metric value through conversion includes:

[0060] For a service instance that provides a type of computing power service, the metadata set corresponding to its service status data is converted; for example, by recording the metadata set that is sensitive to a type of computing power service as Attr Set (attribute set), for services such as Service ID i (service ID is i), the sensitive metadata set of computing power service instance Instance j (service instance j) is Attr Set (i, j) at a certain moment, and then based on the evaluation method of this type of computing power service, the metadata in the set is converted into a Metric (metric) value, that is, based on the value of the elements in Attr Set (i, j), Metric (i, j) is calculated, which represents the ability of computing power service instance Instance j to provide services such as Service ID i (service identifier of the i-th service) in cooperation with the corresponding network forwarding path.

[0061] This embodiment, through the above-described solution, converts the target service metric value from the service status data of a single service instance when only one service instance exists. The target service metric value represents the service provision capability of the service instance. By converting the service status data corresponding to a single service instance, this embodiment can understand the performance level and service quality of the service instance, thereby better utilizing limited resources and improving resource utilization efficiency. This in turn enhances the ability to process and analyze large amounts of dynamic service status data, thereby improving network service quality.

[0062] Based on the above first embodiment, a third embodiment of the service routing method of this application is proposed. The difference between this embodiment and the first embodiment is that, in this embodiment, the service routing notification method further includes:

[0063] When there are multiple service instances, the target service metric value is obtained by aggregating the service metric values ​​of the multiple service instances, which are converted from the service status data of the service instances. The target service metric value represents the service provision capabilities of the multiple service instances.

[0064] In one implementation, when there are multiple service instances, the multiple service instances have the same type of service provision capabilities. In this embodiment, the target service metric value can be obtained through the following two methods.

[0065] Method A: First, the metadata corresponding to the service status data is converted to obtain the metric values ​​corresponding to all service instances, and then the metric values ​​corresponding to all service instances are aggregated to obtain the target service metric value; in this embodiment, the method A includes step A1 and step A2.

[0066] In step A1, the set of sensitive metadata of a type of computing power service is recorded as Attr Set (attribute set). For services such as Service ID i (service ID is i), the sensitive metadata set of computing power service instance Instance j (service instance j) at a certain moment is Attr Set (i, j). Then, based on the evaluation method of this type of computing power service, the metadata in the set is converted into a Metric (metric) value, that is, based on the element values ​​in Attr Set (i, j), Metric (i, j) is calculated. This value represents the ability of computing power service instance Instance j to provide services such as Service ID i (service identifier of the i-th service) in conjunction with the corresponding network forwarding path.

[0067] In step A2, there are several computing service instances that can provide services in the edge cloud or data center connected to the network device at the edge of the computing network (hereinafter referred to as the "edge device"), such as Instance 1, Instance 2, and so on. Based on the different computing resource status metadata sets Attr Set (i, j) of these computing service instances at a certain moment, the Metric (i, j) values ​​that characterize the ability of these service instances to provide services such as Service ID i can be calculated accordingly. The edge device applies the corresponding Cohesive Function (aggregation function) to these Metric values ​​to obtain Metric i = Cohesive Function (Metric i, j). Metric i characterizes the ability of the resource pool at the edge device to provide services such as Service ID i. The edge device then publishes and announces the aggregated results, i.e., Metric 1, Metric 2, and other target service metrics, to the computing network.

[0068] In this embodiment, the aggregation algorithms used in the process of aggregating the metric values ​​may include algorithms a1 to a5.

[0069] In Algorithm a1, Metric i takes the average of the corresponding metric values ​​of all service instances that provide the service; in Algorithm a2, Metric i takes the weighted average of the corresponding metric values ​​of all service instances that provide the service; in Algorithm a3, Metric i takes the maximum of the corresponding metric values ​​of all service instances that provide the service; in Algorithm a4, Metric i takes the minimum of the corresponding metric values ​​of all service instances that provide the service; in Algorithm a5, Metric i takes the median of the corresponding metric values ​​of all service instances that provide the service.

[0070] This embodiment does not limit the aggregation algorithm applied to the metric value, and the aggregation algorithm can be selected according to the actual situation during actual implementation.

[0071] Method B: First, the metadata corresponding to the service status data of all service instances is aggregated to obtain aggregated metadata, and then the aggregated metadata is converted into a Mertic value to obtain the target service metric value; in this embodiment, the method B includes step B1 and step B2.

[0072] In step B1, the sensitive metadata set for a computing service is recorded as Attr Set. For example, for a service with Service ID i, the sensitive metadata set for computing service instance j at a certain moment is Attr Set (i, j). For multiple computing network services represented by multiple Service IDs, service instance j corresponds to Attr Set (1, j), Attr Set (2, j), ... . The union of these multiple Attr Sets is calculated and recorded as Metadata Set j.

[0073] In step B2, the edge device applies the corresponding aggregation algorithm to the metadata set j to obtain Cohesive Metadata Set = Cohesive Function (Metadata Set j). The edge device then converts the aggregation result, i.e., the Cohesive Metadata Set (metadata aggregation set), into a metric based on the service type.

[0074] In this embodiment, the aggregation algorithms used in the process of aggregating the meta-information set may include algorithms b1 to b6.

[0075] Algorithm b1 takes the average value of the same type of elements in the set as the corresponding element of the meta-information aggregation set; Algorithm b2 takes the weighted average value of the same type of elements in the set as the corresponding element of the meta-information aggregation set; Algorithm b3 takes the maximum value of the same type of elements in the set as the corresponding element of the meta-information aggregation set; Algorithm b4 takes the minimum value of the same type of elements in the set as the corresponding element of the meta-information aggregation set; Algorithm b5 takes the median of the same type of elements in the set as the corresponding element of the meta-information aggregation set; Algorithm b6 applies the preset strategy to select a service instance and directly uses the meta-information set of the service instance as the meta-information aggregation set.

[0076] This embodiment does not limit the aggregation algorithm applied to the metadata set, and the algorithm can be selected according to the actual situation during the actual implementation.

[0077] This embodiment, through the above-mentioned scheme, obtains the target service metric value by aggregating the service metric values ​​of multiple service instances when there are multiple service instances, and the service metric values ​​of the service instances are converted from the service status data of the service instances. The target service metric value represents the service provision capabilities of the multiple service instances. This embodiment, through the conversion and aggregation of the service metric values ​​of multiple service instances, can uniformly measure multiple service instances based on service type, thereby improving the ability to process and analyze large amounts of dynamic service status data and improving network service quality to cope with the computing network's need to perceive, process, and analyze large amounts of dynamic, complex, and obscure service status data corresponding to service instances.

[0078] Based on the above first embodiment, a fourth embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the first embodiment is that, in this embodiment, the service routing notification method further includes the following steps.

[0079] Step S100 : In response to the service status data being updated, obtaining an updated target service metric value according to the updated service status data.

[0080] When the computing power status information of the computing power network changes dynamically, that is, the service status data of the service instance connected to the cloud-side computing power routing gateway changes, based on the service release and notification mechanism, the new business needs to make service routing decisions based on the updated computing network status information and adaptively provide network capability guarantees; on the other hand, the subsequent traffic of the (old) business that has already made service routing decisions cannot be easily switched to the service instance providing the service for affinity considerations. Therefore, the network needs to dynamically match according to the changes in the service status data of the service instance.

[0081] When the service status data is updated, the cloud-side computing power routing gateway obtains the updated service status data of the service instance in real time, and obtains the updated target service metric value based on the updated service status data.

[0082] Step S110: Add the updated target service metric value to the target service routing data to obtain updated target service routing data.

[0083] The cloud-side computing power routing gateway carries the updated target service metric value in the target service routing data, obtains the updated target service routing data, and notifies the access-side computing power routing gateway to complete the dynamic update of the hierarchical perception of the cloud-side computing power routing gateway and the access-side computing power routing gateway of the service instance's service provision capabilities.

[0084] Step S120, notifying the updated target service routing data to the access side computing power routing gateway, so that the access side computing power routing gateway obtains the traffic engineering group TE Group corresponding to the service identifier through routing iteration based on the updated target service routing data; the TE Group is used by the access side computing power routing gateway to update the first mapping relationship to obtain the first target routing policy, and the first mapping relationship is the correspondence between the service identifier and the first routing policy identifier Policy Color value in the TE Group; the first target routing policy is used by the access side computing power routing gateway to determine the path to the target cloud side computing power routing gateway.

[0085] This embodiment takes the SRv6 (Segment Routing IPv6, segment routing based on the IPv6 forwarding plane) scenario as an example. First, the cloud-side computing power routing gateway notifies the updated target service routing data to the access-side computing power routing gateway, so that the access-side computing power routing gateway can re-select the route based on the updated target service metric in the updated target service routing data, and obtain the new target cloud-side computing power routing gateway as the target next hop; secondly, the access-side computing power routing gateway updates the first mapping relationship, that is, the access-side computing power routing gateway updates the mapping relationship between the service identifier in the SRv6 TE Group of the corresponding Group Color (group identifier) ​​to the target next hop and the first Policy Color based on the updated target service metric, so that the new service traffic can adaptively match the first SRv6 Policy (that is, the first target routing policy) of the access-side computing power routing gateway to the target cloud-side computing power routing gateway based on the updated target service metric.

[0086] For subsequent traffic of (old) services for which service routing decisions have already been made, the private network routes are iterated to the same TE Group through the publication of VPN (Virtual Private Network) routes. The remaining processes are consistent with the above steps, allowing (old) service traffic to adaptively match the SRv6 Policy of the access-side computing power routing gateway to the private network route based on dynamic computing power status information (updated Service Metric value).

[0087] This embodiment adopts the above-mentioned scheme, that is, in response to the update of the service status data, an updated target service metric value is obtained according to the updated service status data; the updated target service metric value is carried in the target service routing data to obtain updated target service routing data; the updated target service routing data is notified to the access side computing power routing gateway, so that the access side computing power routing gateway obtains the traffic engineering group TE Group corresponding to the service identifier through routing iteration according to the updated target service routing data; the TE Group is used by the access side computing power routing gateway to update the first mapping relationship to obtain the first target routing policy, and the first mapping relationship is the correspondence between the service identifier and the first routing policy identifier Policy Color value in the TE Group; the first target routing policy is used by the access side computing power routing gateway to determine the path to the target cloud side computing power routing gateway. In this embodiment, in response to the update of the service status data, the cloud-side computing power routing gateway notifies the updated target service metric value to the access-side computing power routing gateway, so as to dynamically select a new target cloud-side computing power routing gateway according to the status changes of the computing power network and determine the specific routing path to the new target cloud-side computing power routing gateway, thereby achieving the business goal of dynamically adapting to the network computing power demand and improving the network service quality.

[0088] Based on the above first embodiment, a fifth embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the first embodiment is that, in this embodiment, the service routing notification method further includes the following steps.

[0089] Step S200, in response to the service status data being updated, obtaining an updated target service metric value based on the updated service status data; when the service status data is updated, the cloud-side computing power routing gateway obtains the updated service status data of the service instance in real time, and obtains an updated target service metric value based on the updated service status data.

[0090] Step S201: Obtain a target extended community attribute Color value according to the updated target service metric value.

[0091] This embodiment takes the SRv6 scenario as an example. The difference between this embodiment and the fourth embodiment is that this embodiment updates the target Color value through the cloud-side computing power routing gateway to obtain the target Color value. The target Color value is used to notify the access-side computing power routing gateway and enable the access-side computing power routing gateway to determine the corresponding routing policy identifier based on the target Color value.

[0092] Step S202: Add the updated target service metric value and the Color value to the target service routing data to obtain updated target service routing data.

[0093] In this embodiment, the cloud-side computing power routing gateway carries the updated target service metric value and the Color value in the target service routing data to notify the access-side computing power routing gateway, obtains the new target cloud-side computing power routing gateway as the new target next hop through routing selection, and obtains the routing path from the access-side computing power routing gateway to the new target next hop through routing iteration.

[0094] Step S203, notifying the updated target service routing data to the access side computing power routing gateway, so that the access side computing power routing gateway determines the second Policy Color value based on the Color value, and updates the second mapping relationship based on the second Policy Color value to obtain the second target routing policy, where the second mapping relationship is the correspondence between the service identifier and the second Policy Color value.

[0095] The second target routing strategy is used by the access-side computing power routing gateway to determine the path to the target cloud-side computing power routing gateway.

[0096] When the computing power status information of the computing power network changes dynamically, the cloud-side computing power routing gateway updates the target service metric value of the service route, and updates the extended community attribute Color carried by the service route based on the changed computing power status information and the end-to-end constraints of the service, and obtains the updated target service routing data, so that the new business traffic can adaptively match the SRv6 Policy of the access-side computing power routing gateway to the cloud-side computing power routing gateway based on the dynamic computing power status information (updated target service metric value), that is, obtain the second target routing strategy.

[0097] For subsequent traffic of (old) services that have already made service routing decisions, the cloud-side computing power routing gateway updates the color in the published VPN routes, so that the (old) service traffic can adaptively match the SRv6 Policy of the access-side computing power routing gateway to the private network route based on the dynamic computing power status information (updated target service metric value).

[0098] This embodiment, through the above scheme, responds to the update of the service status data and obtains an updated target service metric value according to the updated service status data; obtains a target extended community attribute Color value according to the updated target service metric value; carries the updated target service metric value and the Color value in the target service routing data to obtain updated target service routing data; notifies the updated target service routing data to the access-side computing power routing gateway so that the access-side computing power routing gateway can determine a second Policy Color value according to the Color value, and updates the second mapping relationship according to the second Policy Color value to obtain a second target routing policy, wherein the second mapping relationship is a correspondence between the service identifier and the second Policy Color value; the second target routing policy is used by the access-side computing power routing gateway to determine the path to the target cloud-side computing power routing gateway. This embodiment updates the target Color value at the cloud-side routing gateway to directly refresh the target Color value in the service routing data, thereby better performing routing selection and traffic control, thereby improving service latency, bandwidth, and stability. By fine-tuning the network through specific policies, network resources can be better utilized and the efficiency of network resource utilization can be improved.

[0099] Based on the above-mentioned first embodiment, the sixth embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the first embodiment is that this embodiment extends the BGP protocol, and the BGP protocol extension content includes: the BGP protocol includes a pre-extended field, and the pre-extended field includes at least one of the target service routing address, the service routing attribute SMA, and the service attribute field Service Sub-TLV, wherein the target service routing address is used to carry the service identifier and characterize the ability of the BGP peer to support service routing announcements; the SMA is used to carry the target service metric; the Service Sub-TLV is used to associate the service route with the computing power service SID, wherein the SID is used to identify the query behavior of the device forwarding face for the computing power forwarding table item associated with the SID and the forwarding behavior based on the query result.

[0100] To expand the BGP protocol, it is necessary to define a new address family, namely the target service routing address family. The BGP address family consists of AFI (Address Family Identifier) ​​and SAFI (Sub-address Family Identifier). Among the address families currently supported by BGP, AFI=1 represents the IPv4 address family, and AFI=2 represents the IPv6 address family; and the SAFI numbering starts from 1, including unicast, multicast, VPN, etc. In this embodiment, a service routing address family can be defined, AFI=10, SAFI=1. In the computing power network, the computing power routing gateway establishes a BGP peer and can negotiate the computing power routing address family capabilities through the Open message. The format of the BGP Open (message header) message is defined in RFC4271 (standardization document 4271), as shown in Table 1.

[0101] Table 1

[0102] Explanation of each field in Table 1:

[0103] Version: Indicates the version number of the protocol.

[0104] My Autonomous System: The AS domain number of the party sending the BGP message.

[0105] Hold Time: This is used to negotiate the time interval between BGP peers to maintain established connections and send Update (routing update) messages. After receiving an Open message from a peer, the BGP state machine must compare the Hold times of the sent and received Open messages and select the smaller time as the negotiated result.

[0106] BGP Identifier: The routing identifier of the party sending the BGP message.

[0107] Opt Para Len (Optional Parameters Length): Optional parameter length. If this value is 0, there are no optional parameters.

[0108] Optional Parameters and variables: Contains a list of various negotiation capabilities supported by the BGP peer. The BGP multi-protocol extension capability includes the address family information of the BGP peer. The format of the address family information is shown in the table below:

[0109] Table 2

[0110] Explanation of each field in Table 2:

[0111] AFI: Address family identifier, occupies 2 bytes, indicates the address family identification information supported by the capability, and is used together with SAFI to determine the relationship between the network layer protocol and the IP address. The encoding method is the same as that specified in the multi-protocol extension.

[0112] Res: Reserved bit, occupies 1 byte, the sender should set it to zero and ignore it when receiving.

[0113] SAFI: Sub-address family identifier, occupies 1 byte, indicates the sub-address family identifier information supported by the capability. It is used together with AFI to determine the relationship between the network layer protocol and the IP address. The encoding method is the same as that specified in the multi-protocol extension.

[0114] The service routing address family AFI=10 and SAFI=1 should be filled in the option parameter to describe that the BGP peer supports BGP service routing capabilities and can mutually advertise computing power routing information through extended BGP Update messages.

[0115] To extend the BGP protocol, it is also necessary to define SMA, which is used to carry the target service metric value.

[0116] The BGP Update (BGP route update) message is shown in Table 3.

[0117] Table 3

[0118] Explanation of each field in Table 3:

[0119] Withdrawn Routes Length, Withdrawn Routes (variable): Contains a list of routes to be withdrawn. Each element in the list contains a one-byte Length field and a Prefix field.

[0120] Total Path Attribute Length: indicates the length of the Path Attributes section. A value of zero indicates no routes or route attributes are advertised.

[0121] Path Attributes (variable): Contains a list of route attributes to be updated, sorted in ascending order by their type number, and fills in all attributes of the updated route.

[0122] Network Layer Reachability Information (variable): Network layer reachability information (variable).

[0123] To enable BGP's multi-protocol support, RFC4760 extends Path Attributes, adding the Multi-Protocol Reachable NLRI (MP_REACH_NLRI) and Multi-Protocol Unreachable NLRI (MP_UNREACH_NLRI). These attributes contain the AFI and SAFI of the address family. In a computing network, when BGP peers that have negotiated the service routing address family capability communicate with each other in Update messages, the AFI and SAFI of the computing routing address family should be populated in the MP_REACH_NLRI and MP_UNREACH_NLRI fields.

[0124] In order to announce computing power routing related information in BGP Update messages, this proposal expands the Path Attribute in the Update message and newly defines SMA, which can be called service routing attribute.

[0125] RFC4271 defines that the type of Path Attribute occupies 2 bytes and is divided into two fields: Attr.Flags (attribute tag) and Attr.Type Code (attribute type value). This embodiment defines the type format of the service routing attribute as shown in Table 4.

[0126] Table 4

[0127] The O, T, and E bits of the Attr.Flags field in the service route attribute should be set to 1. Unused indicates an unusable byte. O = 1, T = 1 indicates that the attribute is optional and must be passed. This means that devices that do not recognize the attribute will still receive it and forward it to other BGP peers. E = 1 indicates that the attribute's length is extended to 2 bytes. The type value of the service route attribute is defined as 50, i.e., Attr.Type Code = 50. The format of the service route attribute is shown in Table 5.

[0128] Table 5

[0129] To extend the BGP protocol, it is also necessary to define the Service Sub-TLV. The Service Sub-TLV is used to associate the service route with the computing power service SID, where the SID is used to identify the device forwarding face's query behavior for the computing power forwarding table entry associated with the SID and the forwarding behavior based on the query result.

[0130] RFC9252 (standardization document 9252) extends the BGP Prefix-SID attribute (the attribute field used to transmit Prefix-SID information in the BGP protocol) to carry the SRv6 SID. SRv6 SID refers to the Segment Identifier, which is an identifier used to identify the SRv6 path. In the SRv6 architecture, nodes can use SRv6 SID to identify and operate an SRv6 path, thereby achieving flexible path control and service provision. This embodiment defines a new SRv6 Service Sub-TLV, which is the SRv6 computing service TLV, namely the SRv6 Compute Service TLV (SRv6 computing service TLV). Its encoding form in the BGP Prefix-SID attribute is shown in Table 6.

[0131] Table 6

[0132] As shown in Table 6, this embodiment newly defines TLV Type = 8, indicating that the SRv6 Service Sub-TLVs (variable) field carries the SRv6 Compute Service TLV, which includes the defined computing power SID and END.C (termination route field). The encoding format of the SRv6 Compute Service TLV is shown in Table 7.

[0133] The SRv6 SID Value field in Table 7 corresponds to the SID value of the computing power SID. The encoding format of the SRv6 Service Data Sub-Sub-TLV field is shown in Table 8.

[0134] Table 8

[0135] In Table 8, the Locator Block Length, Locator Node Length, Function Length, and Argument Length fields should be filled with the lengths of the Locator Block, Locator Node, Function, and Argument of the computing power SID.

[0136] This embodiment uses the above scheme to pre-extend the BGP protocol, and the BGP protocol extension content includes: the BGP protocol includes pre-extended fields, and the pre-extended fields include at least one of the target service routing address, the service routing attribute SMA, and the service attribute field Service Sub-TLV, wherein the target service routing address is used to carry the service identifier and characterize the ability of the BGP peer to support service routing announcements; the SMA is used to carry the target service metric value; the Service Sub-TLV is used to associate the service route with the computing power service SID, wherein the SID is used to identify the query behavior of the device forwarding face for the computing power forwarding table item associated with the SID and the forwarding behavior based on the query result. The embodiment of the present application extends the original BGP protocol so that the cloud-side computing power routing gateway can, based on the extended BGP protocol, announce the service identifier and the target service metric value to the access-side computing power routing gateway, thereby dynamically adapting to the network computing power demand based on the service identifier and the target service metric value, and improving the network service quality.

[0137] Based on the scenario diagram shown in Figure 1, a seventh embodiment of the service routing method of the present application is proposed. Referring to Figure 4, Figure 4 is a schematic diagram of the specific flow of the seventh exemplary embodiment of the service routing method of the present application. The service routing method is applied to the access-side computing power routing gateway in the computing power network system, and the method includes the following steps.

[0138] Step K10, receiving target service routing data sent by at least one cloud-side computing power routing gateway in the computing power network system through the Border Gateway Protocol BGP protocol, wherein the target service routing data carries a service identifier and a target service metric value, and the target service metric value is obtained by the cloud-side computing power routing gateway based on the service status data of the service instance connected to the cloud-side computing power routing gateway, and the target service metric value represents the service provision capability of the service instance.

[0139] As shown in Figure 1, a communication connection is established between the cloud-side computing power routing gateway and the service instance. The service instance can publish service status data externally through itself or to the cloud-side computing power routing gateway. The service instance is used to provide certain types of network services, including experience-priority services, resource-priority services, etc.

[0140] In this embodiment, the cloud-side computing power routing gateway converts and aggregates the service status data to obtain the target service metric value; or, the cloud-side computing power routing gateway converts or aggregates the service status data to obtain the target service metric value. The process of obtaining the target service metric value can be referred to the third embodiment above and will not be repeated here. The cloud-side computing power routing gateway extends the BGP protocol to publish the target service routing data with the service identifier as the key value and carrying the unique target service metric value.

[0141] Step K20: Determine a target cloud-side computing power routing gateway from the at least one cloud-side computing power routing gateway according to the target service metric value.

[0142] The cloud-side computing power routing gateway notifies the access computing power routing gateway of the target service routing data carrying the service identifier and the target service metric value, so that the access-side computing power routing gateway can make a service routing next-hop decision and obtain the target next-hop. The target next-hop is used by the access-side computing power routing gateway to determine the target cloud-side computing power routing gateway, and perform routing iteration based on the target service routing data and the target cloud-side computing power routing gateway to determine the specific routing path from the access-side computing power routing gateway to the target cloud-side computing power routing gateway.

[0143] This embodiment adopts the above scheme, by receiving the target service routing data sent by at least one cloud-side computing power routing gateway in the computing power network system through the border gateway protocol BGP protocol, the target service routing data carries a service identifier and a target service metric value, the target service metric value is obtained by the cloud-side computing power routing gateway based on the service status data of the service instance connected to the cloud-side computing power routing gateway, and the target service metric value represents the service provision capability of the service instance; according to the target service metric value, the target cloud-side computing power routing gateway is determined from the at least one cloud-side computing power routing gateway. Based on the scheme of this application, the cloud-side computing power routing gateway converts the service provision capability of the service instance into the target service metric value, and carries the target service metric value in the target service routing data to notify the access-side computing power routing gateway, thereby improving the processing and analysis capabilities of a large amount of service status data, dynamically adapting to changes in service status data, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway based on the service provision capability of the service instance, dynamically adapting to network computing power requirements, and improving network service quality.

[0144] Based on the seventh embodiment above, an eighth embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the seventh embodiment is that, in this embodiment, the service routing determination method further includes the following steps.

[0145] Step M1: Determine the cloud-side computing power routing gateway with the highest local priority among the at least one cloud-side computing power routing gateway as the target cloud-side computing power routing gateway.

[0146] Step M2: When the local priority of at least one cloud-side computing power routing gateway satisfies at least one of the same and default, determine the cloud-side computing power routing gateway corresponding to the minimum target service metric value as the target cloud-side computing power routing gateway.

[0147] Step M3, when the target service metric value of at least one cloud-side computing power routing gateway satisfies at least one of the same and default, determine the cloud-side computing power routing gateway corresponding to the smallest extended routing attribute AIGP metric value as the target cloud-side computing power routing gateway.

[0148] This embodiment takes the access-side computing power routing gateway as the execution body and proposes a method for making service routing decisions based on the target service metric value to determine the target cloud-side computing power routing gateway as the target next-hop node of the access-side computing power routing gateway.

[0149] Refer to Figure 5, which is a logical diagram of the access-side computing power routing gateway making a service routing next-hop decision in this embodiment; as shown in Figure 5, the access-side computing power routing gateway makes a service routing next-hop decision based on the service routing data published by the cloud-side computing power routing gateway.

[0150] The BGP protocol uses attributes and related parameters to determine the optimal path. The BGP path decision process is defined in standards such as RFC 4271, RFC 4760, and RFC 7311. A partial summary is as follows (each item is evaluated sequentially until a preferred path is found):

[0151] (1) If the next hop is unreachable, the route is not considered.

[0152] (2) The path with the highest weight takes priority.

[0153] (3) The path with higher local priority takes precedence.

[0154] (4) AIGP (extended attributes) comparison, the smaller value takes precedence.

[0155] (5) Prefer locally originated routes.

[0156] (6) AS-PATH (AS path that routing updates pass through): The shorter path takes priority.

[0157] (7) The route with the lowest ORIGIN attribute value takes precedence.

[0158] (8) The path with the smallest MED (Multi-Exit Discriminator) value takes priority.

[0159] (9) EBGP (Exterior Gateway Border Protocol) paths take precedence over IBGP (Interior Gateway Border Protocol) paths.

[0160] (10) Prioritize the path with the lowest IGP metric to the BGP next hop.

[0161] In this embodiment, based on the newly defined target service metric, a new BGP routing principle can be implemented, namely, the above steps M1 to M3. The above steps M1 to M3 are explained in detail as follows.

[0162] The lowest target service metric value takes precedence; the order of effectiveness of this policy is between the routing principle (3) and the routing principle (4) specified in the BGP protocol, that is, the priority of the target service metric value is between the local priority value and the AIGP value. It is worth noting that this embodiment does not limit the effectiveness priority of the target service metric value. During implementation, the effectiveness priority of the target service metric value can be set according to actual conditions.

[0163] This embodiment uses the above scheme to determine the cloud-side computing power routing gateway with the highest local priority among the at least one cloud-side computing power routing gateway as the target cloud-side computing power routing gateway; when the local priority of the at least one cloud-side computing power routing gateway satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the smallest target service metric value is determined as the target cloud-side computing power routing gateway; when the target service metric value of the at least one cloud-side computing power routing gateway satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the smallest extended routing attribute AIGP metric value is determined as the target cloud-side computing power routing gateway. Based on the original BGP protocol's decision on the best path, this embodiment adds the target service metric value to the original routing principle to make routing decisions based on the target service metric value, and determines the target cloud-side computing power routing gateway from the at least one cloud-side computing power routing gateway, thereby dynamically adapting to network computing power requirements and improving network service quality.

[0164] Based on the seventh embodiment above, a ninth embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the seventh embodiment is that, in this embodiment, the service routing determination method further includes the following steps.

[0165] Step N1: Determine the cloud-side computing power routing gateway with the highest local priority among the at least one cloud-side computing power routing gateway as the target cloud-side computing power routing gateway.

[0166] In step N2, when the local priority of the at least one cloud-side computing power routing gateway satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the smallest joint parameter conversion value is determined as the target cloud-side computing power routing gateway. The joint parameter conversion value is obtained by converting the target service metric value and the BGP attribute metric value.

[0167] Step N3, when the joint parameter conversion value of at least one cloud-side computing power routing gateway satisfies at least one of the same and default, determine the cloud-side computing power routing gateway corresponding to the minimum AIGP as the target cloud-side computing power routing gateway.

[0168] Referring to the explanation of the BGP best path decision in the eighth embodiment above, this embodiment provides another implementation method, that is, another method for determining the target service metric value by the access-side computing power routing gateway, that is, steps N1 to N3 above. The specific explanation of steps N1 to N3 is as follows:

[0169] The lowest combined parameter conversion value takes precedence; the order of effectiveness of this policy is between the routing principle (3) and the routing principle (4) specified in the BGP protocol as described in the eighth embodiment, that is, the priority of the combined parameter conversion value is between the local priority value and the AIGP value. This embodiment does not limit the effectiveness priority of the combined parameter conversion value. During the specific implementation process, the effectiveness priority of the combined parameter conversion value can be set according to actual conditions.

[0170] In this embodiment, the joint parameter conversion value can be obtained by converting the target service metric value and the BGP attribute metric value.

[0171] In this embodiment, the BGP attribute metric value includes at least one of an extended routing attribute AIGP metric value, an interior gateway protocol IGP metric value, a routing path AS-PATH metric value, a routing origin ORIGIN metric value, and a multipath egress discriminator MED metric value.

[0172] For example, the AIGP metric and the IGP metric are selected as BGP attribute metrics to participate in the calculation of the joint parameter conversion value. The IGP metric is the IGP cost (loss) value from the access-side computing power routing gateway to the target next-hop node. The target service metric, the AIGP metric, and the IGP cost are jointly converted to obtain the joint parameter conversion value.

[0173] Referring to Figure 6, Figure 6 is a logical diagram of calculating the joint parameter conversion value in this embodiment; as shown in Figure 6, this embodiment uses Service Metric (that is, the target service metric value) + a × AIGP + b × IGP Cost as an example to perform a joint decision on multiple attributes. Parameters a and b in Figure 6 can be pre-set to 0.5. According to the calculation logic in Figure 6, the joint parameter conversion value corresponding to the cloud-side computing power routing gateway with a target service metric value of 37 is the smallest, so the cloud-side computing power routing gateway with a target service metric value of 37 will be selected as the cloud-side computing power routing gateway in the routing decision.

[0174] Parameter a and parameter b can be set according to actual implementation conditions. This embodiment does not limit the specific values ​​of parameter a and parameter b.

[0175] This embodiment is based on the above solution. The target cloud-side computing power routing gateway is determined to be the cloud-side computing power routing gateway with the highest local priority among the at least one cloud-side computing power routing gateway. When the local priority of the at least one cloud-side computing power routing gateway satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the smallest joint parameter conversion value is determined to be the target cloud-side computing power routing gateway. The joint parameter conversion value is obtained by converting the target service metric and the BGP attribute metric value. When the joint parameter conversion value of the at least one cloud-side computing power routing gateway satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the smallest AIGP is determined to be the target cloud-side computing power routing gateway. This embodiment adds a joint parameter conversion value to the original routing principle on the basis of the original BGP protocol for deciding the best path, so as to make routing decisions through the joint parameter conversion value and determine the target cloud-side computing power routing gateway from the at least one cloud-side computing power routing gateway; wherein, the joint parameter conversion value is associated with the target service metric value. Since the specific calculation process of the joint parameter conversion value is not limited, the use of joint parameter conversion is more flexible and can be widely applied to various scenarios, thereby dynamically adapting to network computing power requirements and improving network service quality.

[0176] Based on the seventh embodiment above, a tenth embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the seventh embodiment is that, in this embodiment, the service routing determination method further includes the following steps.

[0177] Step K100, in response to the target service routing data being updated, obtains the updated target service routing data notified by the cloud-side computing power routing gateway.

[0178] When the computing power status information of the computing power network changes dynamically, that is, the service status data of the service instance connected to the cloud-side computing power routing gateway changes, based on the service release and notification mechanism, the new business needs to make service routing decisions based on the updated computing network status information and adaptively provide network capability guarantees; on the other hand, the subsequent traffic of the (old) business that has already made service routing decisions cannot be easily switched to the service instance providing the service for affinity considerations. Therefore, the network needs to dynamically match according to the changes in the service status data of the service instance.

[0179] When the service status data is updated, the cloud-side computing power routing gateway obtains the updated service status data of the service instance in real time, and obtains the updated target service metric value based on the updated service status data.

[0180] The cloud-side computing power routing gateway carries the updated target service metric value in the target service routing data, obtains the updated target service routing data, and notifies the access-side computing power routing gateway to complete the dynamic update of the hierarchical perception of the cloud-side computing power routing gateway and the access-side computing power routing gateway of the service instance's service provision capabilities.

[0181] Step K110: performing routing iteration according to the updated target service routing data to obtain a traffic engineering group (TE Group) corresponding to the service identifier; updating the first mapping relationship according to the target service metric in the updated target service routing data to obtain a first target routing policy;

[0182] The first mapping relationship is the correspondence between the service identifier and the first routing policy identifier Policy Color value in the TE Group, and the first target routing policy is used to determine the path to reach the target cloud-side computing power routing gateway.

[0183] This embodiment takes the SRv6 (Segment Routing IPv6, segment routing based on the IPv6 forwarding plane) scenario as an example. First, the cloud-side computing power routing gateway notifies the updated target service routing data to the access-side computing power routing gateway, so that the access-side computing power routing gateway can re-select the route based on the updated target service metric in the updated target service routing data, and obtain the new target cloud-side computing power routing gateway as the target next hop; secondly, the access-side computing power routing gateway updates the first mapping relationship, that is, the access-side computing power routing gateway updates the mapping relationship between the service identifier in the SRv6 TE Group of the corresponding Group Color (group identifier) ​​to the target next hop and the first Policy Color based on the updated target service metric, so that the new service traffic can adaptively match the first SRv6 Policy (that is, the first target routing policy) of the access-side computing power routing gateway to the target cloud-side computing power routing gateway based on the updated target service metric.

[0184] For subsequent traffic of (old) services for which service routing decisions have already been made, the private network routes are iterated to the same TE Group through the publication of VPN (Virtual Private Network) routes. The remaining processes are consistent with the above steps, allowing (old) service traffic to adaptively match the SRv6 Policy of the access-side computing power routing gateway to the private network route based on dynamic computing power status information (updated Service Metric value).

[0185] This embodiment uses the above scheme to obtain the updated target service routing data announced by the cloud-side computing power routing gateway in response to the update of the target service routing data; perform routing iteration according to the updated target service routing data to obtain the traffic engineering group TE Group corresponding to the service identifier; update the first mapping relationship according to the target service metric value in the updated target service routing data to obtain the first target routing policy; the first mapping relationship is the correspondence between the service identifier and the first routing policy identifier Policy Color value in the TE Group, and the first target routing policy is used to determine the path to the target cloud-side computing power routing gateway. In this embodiment, in response to the update of the service status data, the cloud-side computing power routing gateway notifies the updated target service metric value to the access-side computing power routing gateway, so as to dynamically select a new target cloud-side computing power routing gateway according to the status change of the computing power network and determine the specific routing path to the new target cloud-side computing power routing gateway, thereby achieving the business goal of dynamically adapting to the network computing power demand and improving the network service quality.

[0186] Based on the seventh embodiment, an eleventh embodiment of the service routing method of the present application is proposed. The difference between this embodiment and the seventh embodiment is that in this embodiment, the service routing determination method further includes the following steps.

[0187] Step K200, in response to the target service routing data update, obtain the updated target service routing data notified by the cloud-side computing power routing gateway.

[0188] When the service status data is updated, the cloud-side computing power routing gateway obtains the updated service status data of the service instance in real time and obtains the updated target service metric value based on the updated service status data. The cloud-side computing power routing gateway adds the target service metric value to the service routing data to obtain the updated target service routing data and notifies the access-side computing power routing gateway. The access-side computing power routing gateway updates the target service metric value based on the received updated target service routing data.

[0189] Step K210: Obtain the target extended community attribute Color value according to the updated target service routing data.

[0190] This embodiment takes the SRv6 scenario as an example. The difference between this embodiment and the above-mentioned tenth embodiment is that this embodiment receives the updated target service routing data through the access-side computing power routing gateway, and obtains the target Color value obtained in response to the update of the target service routing data; the update of the target Color value is implemented by the cloud-side computing power routing gateway, and enables the access-side computing power routing gateway to determine the corresponding routing policy identifier according to the target Color value.

[0191] Step K220: Determine a second Policy Color value according to the target extended community attribute Color value.

[0192] The second mapping relationship is updated according to the second Policy Color value to obtain a second target routing policy, which is used to determine the path to the target cloud-side computing power routing gateway; the second mapping relationship is the correspondence between the service identifier and the second Policy Color value, and the target extended group attribute Color value is obtained by the cloud-side computing power routing gateway according to the updated target service metric value when the target service metric value is updated.

[0193] When the computing power status information of the computing power network changes dynamically, the cloud-side computing power routing gateway updates the target service metric value of the service route, and updates the extended community attribute Color carried by the service route based on the changed computing power status information and the end-to-end constraints of the service, and obtains the updated target service routing data, so that the new business traffic can adaptively match the SRv6 Policy of the access-side computing power routing gateway to the cloud-side computing power routing gateway based on the dynamic computing power status information (updated target service metric value), that is, obtain the second target routing strategy.

[0194] For subsequent traffic of (old) services that have already made service routing decisions, the cloud-side computing power routing gateway updates the color in the published VPN routes, so that the (old) service traffic can adaptively match the SRv6 Policy of the access-side computing power routing gateway to the private network route based on the dynamic computing power status information (updated target service metric value).

[0195] This embodiment, through the above scheme, obtains updated target service routing data announced by the cloud-side computing power routing gateway in response to the target service routing data update; obtains a target extended community attribute Color value based on the updated target service routing data; determines a second Policy Color value based on the target extended community attribute Color value; updates a second mapping relationship based on the second Policy Color value to obtain a second target routing policy, which is used to determine the path to the target cloud-side computing power routing gateway; the second mapping relationship is a correspondence between the service identifier and the second Policy Color value, and the target extended community attribute Color value is obtained by the cloud-side computing power routing gateway based on the updated target service metric value when the target service metric value is updated. This embodiment updates the target Color value at the cloud-side routing gateway to directly refresh the target Color value in the service routing data, thereby enabling better routing selection and traffic control, thereby improving service latency, bandwidth, and stability. Through refined network management through specific policies, network resources can be better utilized and network resource utilization efficiency can be improved.

[0196] As an implementation method, based on the above-mentioned first to fifth embodiments and seventh to tenth embodiments, a twelfth embodiment of the service routing method of the present application is proposed.

[0197] Refer to Figure 7, which is a logical diagram of VPN route publishing and VPN route iteration in this embodiment. As shown in Figure 7, service instances Instance 1 to 4 at the cloud-side computing power routing gateway can provide services such as Service 1. Service 1 is a type of resource-priority service that uses the lowest load as the scheduling and optimization goal and an end-to-end delay of 50ms as the scheduling constraint.

[0198] Explanation of technical terms in this embodiment:

[0199] Service Metric: target service metric; Service ID: service identifier; Egress PE: cloud-side computing power routing gateway; Ingress: access-side computing power routing gateway; Endpoint: next-hop node; Policy: routing policy; Color: identifier.

[0200] As an implementation method, this embodiment is applied to a control plane communication scenario. The service routing method of this embodiment includes:

[0201] First, the cloud-side computing power routing gateway and the access-side computing power routing gateway establish traditional BGP VPN neighbors. The cloud-side computing power routing gateway publishes VPN routes, which include the service instance address, VPN SID, extended community attribute Color, etc.

[0202] Next, based on the next hop and color information advertised in the VPN route, the system iterates to SRv6 TE Group 1, which corresponds to the TE Group Color. As shown in Figure 7, the extended community attribute Color = 100 carried in the VPN route indicates the service route's requirements for network latency. Accordingly, SRv6 TE Group 1 is defined for the route from Ingress PE 1 to Egress PE 1, with Group Color = 100. Three SRv6 Policies, with Colors = 10, 20, and 30, respectively, specify that the TE path from Ingress PE 1 to Egress PE 1 must meet latency constraints of 30 ms, 20 ms, and 10 ms.

[0203] Again, referring to Figure 8, Figure 8 is a logical diagram of service route announcement and service route iteration in this embodiment; as shown in Figure 8, the cloud-side computing power routing gateway converts the service instance status information and generates a local service routing table entry, such as Instance 1 is preferred at the cloud-side computing power routing gateway. Then, the aggregation method is applied to aggregate the local Service Metric value. The access-side computing power routing gateway establishes a BGP service routing neighbor with the cloud-side computing power routing gateway. The cloud-side computing power routing gateway publishes the service route to the remote access-side computing power routing gateway Ingress PE 1, which contains the service identifier (such as Service ID 1), Service Metric attribute, computing power SID (such as END.CL (Egress PE 1)), and extended community attribute Color = 100, which means that the service route has the same latency attribute requirements as the business route.

[0204] Next, refer to Figure 9, which is a logical diagram of the conversion of target service metrics in this embodiment. As shown in Figure 9, assuming resource load is the optimization objective and a latency constraint is imposed, the Service Metric conversion method for Service 1 is shown in Figure 9. For an end-to-end latency constraint of 50ms, the corresponding expected latency for the computing segment is set at 20ms, the tolerated latency is 30ms, and the latency threshold is 40ms. When the computing segment latency does not exceed expectations, the network segment's policy constraints are relatively loose. When the computing segment latency exceeds expectations but is still within the tolerance limit, the network segment is required to provide a higher-quality policy to compensate for the exceeding expectations. When the computing segment latency exceeds the tolerance but still does not exceed the threshold, the network segment is required to provide an extreme-capacity policy. When the computing segment latency exceeds the threshold, it can be considered that the computing segment has severely degraded and is essentially unable to provide end-to-end service that meets the constraints. The corresponding computing power segment latency is reflected in the calculation of the Service Metric value. For example, if the STEP1 and STEP2 values ​​are 100 and 200 respectively (STEP1 and STEP2 values ​​are preset thresholds and can be set according to actual conditions), F(load) = 100 × load. Typically, if Service Metric = 40, it means that the current load is 40% and the computing power segment latency does not exceed expectations. Service Metric = 150 means that the current load is 50% and the computing power segment latency exceeds expectations. Service Metric = 260 means that the current load is 60% and the computing power segment latency exceeds the tolerance.

[0205] Referring to Figure 10, it is a logical diagram of dynamic routing policy mapping based on the target service metric in this embodiment. As shown in Figure 10, when the Service Metric is 40 (less than 100), the Service ID is mapped to SRv6 Policy 1 with Color = 10 (30ms) in SRv6 TE Group 1. When the Service Metric is 150 (less than 200), the Service ID is mapped to SRv6 Policy 2 with Color = 20 (20ms) in SRv6 TE Group 1. When the Service Metric is 260 (less than 300), the Service ID is mapped to SRv6 Policy 3 with Color = 30 (10ms) in SRv6 TE Group 1. In summary, through the dynamic collection and notification of Service Metrics, the computing power network system can provide corresponding dynamic network capability mapping (switching between multiple SRv6 Policies within an SRv6 TE Group) based on the dynamic computing power status (degradation) during service provision.

[0206] Finally, based on the above steps, the access-side computing power routing gateway, Ingress PE 1, selects the optimal next hop for the service route. For example, it selects Egress PE 1 as the next hop, combines the next hop and color information published by the service route, iterates to SRv6 TE Group 1 through Group Color, and determines the color corresponding to the current Service ID based on the current Service Metric value for the selected next hop. For example, if Color = 10, Service ID 1 now corresponds to SRv6 Policy 1, and the outbound interface of the service route is set to the SRv6 Policy 1 tunnel interface. At this point, the access-side computing power routing gateway generates a global service route entry (Service ID 1, Egress PE 1, SRv6 Policy 1).

[0207] This embodiment uses the above-mentioned solution, utilizing the Service Metric attribute and target service metric value in the service routing method, to optimize the scheduling of different service instances. Service routing selects the optimal service path based on the service instance's load and latency constraints, achieving resource priority and minimal load scheduling. By extending the use of the Color attribute and SRv6 TE Group, the system can constrain and optimize network latency. Each SRv6 TE Group represents a routing path with different latency constraints. Based on service requirements, the appropriate routing path is selected to ensure that the end-to-end latency of the service meets the constraints. Based on dynamically collected and advertised Service Metric values, the system dynamically adjusts routing policies. By comparing Service Metrics with preset thresholds, services are mapped to corresponding SRv6 Policies, enabling dynamic routing policy switching. This provides more adaptable network capability mapping based on changes in computing power. The system comprehensively considers the next hop advertised by the service route, the Color attribute, and the current Service Metric value to determine the optimal next hop. Based on current network conditions and service requirements, the system selects the most appropriate next hop and sets the egress of the service route to the corresponding SRv6 Policy interface. This enables more accurate routing decisions, improving network performance and quality of service.

[0208] As another implementation method, the thirteenth embodiment of the service routing method of the present application is proposed based on the above-mentioned first to fourth embodiments, sixth to ninth embodiments, and eleventh embodiment.

[0209] Explanation of technical terms in this embodiment:

[0210] Service Metric: target service metric; Service ID: service identifier; Egress PE: cloud-side computing power routing gateway; Ingress: access-side computing power routing gateway; Endpoint: next-hop node; Policy: routing policy; Color: identifier.

[0211] As another implementation manner, this embodiment is applied to a control plane communication scenario. The service routing method of this embodiment includes:

[0212] First, the cloud-side computing power routing gateway converts the service instance status information and generates a local service routing table entry, such as Instance 1 is preferred at the cloud-side computing power routing gateway. Then, the aggregation method is applied to aggregate the local Service Metric value. The access-side computing power routing gateway establishes a BGP service routing neighbor with the cloud-side computing power routing gateway. The cloud-side computing power routing gateway publishes the service route to the remote access-side computing power routing gateway Ingress PE 1, which contains the service identifier (such as Service ID 1), Service Metric attribute, computing power SID (such as END.CL (Egress PE 1)), extended community attribute Color, etc. The cloud-side computing power routing gateway maintains the mapping relationship between Service ID+Service Metric and Color, such as {Service ID 1, Service Metric≤100}->Color=10, {Service ID 1, 100<Service Metric≤200}-> Color=20,{Service ID 1,200<Service Metric≤300}-> Color=30.

[0213] Secondly, the cloud-side computing power routing gateway and the access-side computing power routing gateway establish a traditional BGP VPN neighbor relationship. The cloud-side computing power routing gateway publishes VPN routes, which include the service instance address, VPN SID, extended community attribute Color, etc. The Color value is the same as above, that is, {Service ID 1, Service Metric ≤ 100}->Color = 10, {Service ID 1, 100<Service Metric≤200}-> Color=20,{Service ID 1,200<Service Metric≤300}-> Color=30.

[0214] Then, for VPN routes, combined with the next hop and color information advertised by the VPN routes, the private network routes are iterated to an SRv6 Policy, such as SRv6Policy 1.

[0215] Finally, for the service route, the access-side computing power routing gateway (Ingress PE 1) selects the optimal next hop among multiple possible next hops. For example, it selects Egress PE 1 as the next hop and, based on the color information carried in the service route, sets the outbound interface of the service route to the SRv6 Policy 1 tunnel interface. At this point, the access-side computing power routing gateway generates a global service route entry (Service ID 1, Egress PE 1, SRv6 Policy 1).

[0216] Compared with the twelfth embodiment, this embodiment is similar in that the Service ID identifies the service, and the Service Metric identifies the service status. The two form a dynamic mapping relationship with Color. By designing dynamic mapping capabilities, the network can adaptively provide service assurance. The prerequisite for end-to-end network assurance is that the Service Metric is qualified and supports the corresponding policy requirements. The difference is that in the twelfth embodiment, the mapping relationship of Service ID + Service Metric -> Color is maintained in the Ingress, and the Color is derived from the Ingress through mapping. The Color of the service route and business route is not refreshed, corresponding to a general TE Group, indicating a general type of network requirement (latency, bandwidth, etc.). In contrast, in this embodiment, the mapping relationship of Service ID + Service Metric -> Color is maintained in the Egress, and the Color is directly specified in the route by the Egress. The Color of the service route and business route is refreshed, corresponding to a specific Policy, indicating specific detailed network requirements (latency ≤ 30ms, latency ≤ 20ms, etc.).

[0217] This embodiment, through the above-mentioned solution and the dynamic mapping between service metric values ​​and colors, enables the network to adaptively provide service assurance. When the service status changes, the system automatically updates the color based on the service metric value, providing more refined service assurance. By combining multiple routing strategies, such as VPN and SRv6, flexible support for diverse service requirements is achieved. VPN routing and SRv6 policies enable specific control over service priority and latency. The access-side computing power routing gateway generates a global service routing table entry, recording information such as the service ID, egress PE, and SRv6 policy. This information helps network administrators better monitor and manage services and ensure reliable service delivery. Through dynamic mapping capabilities and flexible routing policies, the system can more accurately match service requirements with network conditions, thereby improving network efficiency and availability and ensuring service quality. Furthermore, the colors of service routes and business routes are refreshed and can be adjusted in real time based on service status, better adapting to network changes.

[0218] Based on the above-mentioned first to eleventh embodiments, the fourteenth embodiment of the service routing method of the present application is proposed.

[0219] Different from the twelfth and thirteenth embodiments above, this embodiment is applied to a forwarding plane communication scenario. The service routing method provided in this embodiment includes:

[0220] 11, FIG11 is a schematic diagram of the process of uplink and downlink of the first packet in an embodiment of the present application;

[0221] First, as shown in Figure 11, the client sends a message, and the Destination Address field is filled with the Global SID of the access-side computing power routing gateway, such as SID 1. The Destination Address is used to identify the address information of the final destination of the data packet.

[0222] Secondly, the message arrives at PE 1. PE 1 resolves the Service ID carried in the message header based on the local Global computing power SID (SID 1) in the Destination Address field. The Service ID can be placed in a position such as DOH (encrypted DNS) or HBH (Hop-by-Hop Options Header). PE 1 queries the associated Global FIB table and finds that the next hop is SID 4 based on Service ID 1. It then replaces the Destination Address field and encapsulates the outer message header for the original message based on the outgoing interface, including SRH (Segment Routing Header), source address, and destination address (taking the first SID in the Policy's Segment List). The DOH is used to encrypt DNS request and response data and embed them into the HTTPS protocol, and the HBH is used to add additional option information to each router or node during data packet transmission.

[0223] Again, the access-side computing power routing gateway continues to forward the message. Along the way, the message is forwarded along the explicit path according to the Segment List in Policy 1 until it reaches the cloud-side computing power routing gateway.

[0224] Again, the cloud-side computing power routing gateway decapsulates the outer message header to reveal the inner message. Based on the local computing power SID in the Destination Address field, that is, SID 4, it parses the Service ID carried in the message header (which can be placed in positions such as DOH, HBH, etc.), that is, Service ID 1, and queries the associated Local FIB table. Based on Service ID 1, it finds that the next hop is Instance 1 and replaces it with the Destination Address field. It then forwards the message according to the outbound interface and finally reaches Instance 1.

[0225] Then, the service instance sends a downlink message with the client address as the destination address and fills in its own IP address in the source address field, and sends the message to the client (the cloud-side computing power routing gateway can encapsulate the downlink message in the corresponding SRv6 Policy based on the client private network route published by the access-side computing power routing gateway).

[0226] Finally, refer to Figure 12, which is a schematic diagram of the process of uplink continuation of the packet in an embodiment of the present application; as shown in Figure 12, the client sends an uplink message of the continuation packet with the downlink source address of the first packet as the destination address, and the access-side computing power routing gateway iterates to the SRv6 Policy based on the VPN routing, and sends it to the cloud-side computing power routing gateway. The cloud-side computing power routing gateway removes the outer tunnel encapsulation based on the VPN SID at the bottom of the stack, queries the VPN private network routing table entry associated with the VPN SID, and finally forwards the message to the service instance.

[0227] This embodiment uses the above solution to apply the Service ID to forwarding plane communication scenarios. Routing decisions are made based on the target service metric corresponding to the Service ID, resulting in a next-hop node that meets current network requirements. This makes network resource utilization more efficient and optimized, providing different priorities and resource allocations for different services, thereby ensuring service-level agreements (SLAs). This ensures the quality of service for critical services and improves user satisfaction.

[0228] The above embodiments can be reasonably combined and implemented according to actual conditions, and this embodiment will not be described in detail.

[0229] In addition, as shown in Figure 13, an embodiment of the present application also proposes a computing power routing gateway, which includes a processor, a memory, a computer program stored on the memory and executable by the processor, and a data bus for realizing connection and communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the steps of the service routing announcement method in the first to sixth embodiments above or implements the steps of the service routing determination method in the seventh to eleventh embodiments above.

[0230] In this embodiment, the routing device at least includes an output module 110 , a processor 120 , a memory 130 , and a communication module 140 .

[0231] The memory 130 stores an operating system and a service routing notification and determination program, and can store information such as the service status data of the service instance, the target service metric value obtained based on the service status data, and the target service routing data carrying the service identifier and the target service metric value in the memory 130; the output module 110 can be a display screen, etc.; the communication module 140 can include a routing protocol module, etc., and communicate with an external device or server through the communication module 140.

[0232] Among them, when the service route announcement and determination program in the memory 130 is executed by the processor, it can implement the steps of the service route announcement method in the first to sixth embodiments or implement the service route determination method in the seventh to eleventh embodiments.

[0233] Since the service route announcement and determination program adopts all the technical solutions of all the aforementioned embodiments when executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

[0234] In addition, an embodiment of the present application also provides a computer-readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the service route announcement method in the first to sixth embodiments mentioned above or to implement the steps of the service route determination method in the seventh to eleventh embodiments mentioned above.

[0235] Since all the technical solutions of all the aforementioned embodiments are adopted when one or more programs are executed by the processor, at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments are obtained, which will not be described one by one here.

[0236] As used herein, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or system that includes the element.

[0237] The above-mentioned order of the embodiments of the present application is for description only and does not represent the advantages or disadvantages of the embodiments.

[0238] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0239] The above are merely optional embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A service routing notification method, applied to a cloud-side computing power routing gateway in a computing power network system, wherein: The method comprises: Obtain service status data of a service instance connected to the cloud-side computing power routing gateway; Obtaining a target service metric value according to the service status data, wherein the target service metric value represents a service provision capability of the service instance; Through the Border Gateway Protocol BGP protocol, the target service routing data carrying the service identifier and the target service metric value is notified to the access-side computing power routing gateway in the computing power network system, so that the access-side computing power routing gateway can determine the target cloud-side computing power routing gateway from the cloud-side computing power routing gateways according to the target service metric value.

2. The service route advertisement method according to claim 1, wherein: The method further comprises: In the case where there is only one service instance, the target service metric value is converted from the service status data of the service instance, and the target service metric value represents the service provision capability of the service instance.

3. The service route advertisement method according to claim 1, wherein: The method further comprises: When there are multiple service instances, the target service metric value is obtained by aggregating the service metric values ​​of the multiple service instances, which are converted from the service status data of the service instances. The target service metric value represents the service provision capabilities of the multiple service instances.

4. The service route advertisement method according to claim 1, wherein: The method further comprises: In response to the service status data being updated, obtaining an updated target service metric value according to the updated service status data; Carrying the updated target service metric value in the target service routing data to obtain updated target service routing data; Notify the updated target service routing data to the access side computing power routing gateway, so that the access side computing power routing gateway obtains the traffic engineering group TE Group corresponding to the service identifier through routing iteration according to the updated target service routing data; the TE Group is used by the access side computing power routing gateway to update the first mapping relationship to obtain the first target routing policy, where the first mapping relationship is the correspondence between the service identifier and the first routing policy identifier Policy Color value in the TE Group; The first target routing strategy is used by the access-side computing power routing gateway to determine a path to reach the target cloud-side computing power routing gateway.

5. The service route advertisement method according to claim 1, wherein: The method further comprises: In response to the service status data being updated, obtaining an updated target service metric value according to the updated service status data; Obtaining a target extended community attribute Color value according to the updated target service metric value; Carrying the updated target service metric value and the Color value in the target service routing data to obtain updated target service routing data; Notify the updated target service routing data to the access-side computing power routing gateway, so that the access-side computing power routing gateway determines a second Policy Color value according to the Color value, and updates a second mapping relationship according to the second Policy Color value to obtain a second target routing policy, where the second mapping relationship is a correspondence between the service identifier and the second Policy Color value; The second target routing strategy is used by the access-side computing power routing gateway to determine a path to reach the target cloud-side computing power routing gateway.

6. The service route advertisement method according to claim 1, wherein: The BGP protocol includes a pre-extended field, and the pre-extended field includes at least one of a target service routing address, a service routing attribute SMA, and a service attribute field Service Sub-TLV, wherein the target service routing address is used to carry the service identifier and characterize the ability of the BGP peer to support service routing announcements; The SMA is used to carry the target service metric value; The Service Sub-TLV is used to associate the service route with the computing power service SID, wherein the SID is used to identify the query behavior of the device forwarding face on the computing power forwarding table entry associated with the SID and the forwarding behavior based on the query result.

7. A service routing determination method, applied to an access-side computing power routing gateway in a computing power network system, wherein: The method comprises: Receive target service routing data sent by at least one cloud-side computing power routing gateway in the computing power network system through the Border Gateway Protocol (BGP), where the target service routing data carries a service identifier and a target service metric value, where the target service metric value is obtained by the cloud-side computing power routing gateway based on service status data of a service instance connected to the cloud-side computing power routing gateway, and where the target service metric value represents the service provision capability of the service instance; According to the target service metric value, a target cloud-side computing power routing gateway is determined from the at least one cloud-side computing power routing gateway.

8. The service route determination method according to claim 7, wherein: The step of determining a target cloud-side computing power routing gateway from the at least one cloud-side computing power routing gateway according to the target service metric value includes: Determine the cloud-side computing power routing gateway with the highest local priority among the at least one cloud-side computing power routing gateway as the target cloud-side computing power routing gateway; When the local priority of the at least one cloud-side computing power routing gateway satisfies at least one of the same and default, determining the cloud-side computing power routing gateway corresponding to the minimum target service metric value as the target cloud-side computing power routing gateway; When the target service metric value of at least one of the cloud-side computing power routing gateways satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the smallest extended routing attribute AIGP metric value is determined as the target cloud-side computing power routing gateway.

9. The service route determination method according to claim 7, wherein: The step of determining a target cloud-side computing power routing gateway from the at least one cloud-side computing power routing gateway according to the target service metric value includes: Determine the cloud-side computing power routing gateway with the highest local priority among the at least one cloud-side computing power routing gateway as the target cloud-side computing power routing gateway; When the local priority of at least one of the cloud-side computing power routing gateways satisfies at least one of the same and default, determine the cloud-side computing power routing gateway corresponding to the minimum joint parameter conversion value as the target cloud-side computing power routing gateway, wherein the joint parameter conversion value is converted by the target service metric value and the BGP attribute metric value; When the joint parameter conversion value of at least one of the cloud-side computing power routing gateways satisfies at least one of the same and default, the cloud-side computing power routing gateway corresponding to the minimum AIGP is determined as the target cloud-side computing power routing gateway.

10. The service route determination method according to claim 9, wherein: The BGP attribute metric value includes at least one of an extended routing attribute AIGP metric value, an interior gateway protocol IGP metric value, a routing path AS-PATH metric value, a routing origin ORIGIN metric value, and a multipath egress discriminator MED metric value.

11. The service route determination method according to claim 7, wherein: The method further comprises: In response to the target service routing data being updated, obtaining updated target service routing data notified by the cloud-side computing power routing gateway; Perform routing iteration according to the updated target service routing data to obtain a traffic engineering group TE Group corresponding to the service identifier; According to the target service metric value in the updated target service routing data, the first mapping relationship is updated to obtain a first target routing strategy; The first mapping relationship is the correspondence between the service identifier and the first routing policy identifier Policy Color value in the TE Group, and the first target routing policy is used to determine the path to reach the target cloud-side computing power routing gateway.

12. The service route determination method according to claim 7, wherein: The method further comprises: In response to the target service routing data being updated, obtaining updated target service routing data notified by the cloud-side computing power routing gateway; Obtain the target extended community attribute Color value according to the updated target service routing data; Determine a second Policy Color value according to the target extended community attribute Color value; The second mapping relationship is updated according to the second Policy Color value to obtain a second target routing policy, where the second target routing policy is used to determine a path to reach the target cloud-side computing power routing gateway; The second mapping relationship is the correspondence between the service identifier and the second Policy Color value, and the target extended group attribute Color value is obtained by the cloud-side computing power routing gateway according to the updated target service metric value when the target service metric value is updated.

13. A computing power routing gateway, wherein: The computing power routing gateway includes a processor, a memory, a computer program stored in the memory and executable by the processor, and a data bus for realizing connection communication between the processor and the memory, wherein when the computer program is executed by the processor, the service routing announcement method as described in any one of claims 1 to 6 is realized or the service routing determination method as described in any one of claims 7 to 12 is realized.

14. A storage medium for computer-readable storage, wherein: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the service route announcement method as described in any one of claims 1 to 6 or the service route determination method as described in any one of claims 7 to 12.

Images