System and method for serial scheduling of services
By introducing service-aware gateways and proxy nodes in multi-cluster microservice scenarios, and utilizing the Binding SID and Service SID of SRv6 Policy, dynamic scheduling and consistent forwarding across multiple service endpoints are achieved. This solves the problems of static service endpoint selection and low resource utilization in existing technologies, and improves service level and resource utilization.
Patent Information
- Application Number
- PCT/CN2025/086301
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-08-26
- Filing Date
- 2025-03-31
- Publication Date
- 2026-03-05
AI Technical Summary
In multi-cluster microservice scenarios, existing technologies cannot effectively achieve dynamic service endpoint selection and scheduling, leading to service level degradation and reduced utilization of computing network resources. Furthermore, the lack of an overall logical understanding of the service chain makes it impossible to ensure consistency.
By introducing service-aware gateways and service proxy nodes, service chain identifiers and service identifiers are encapsulated in the packets. Using the Binding SID and Service SID of SRv6 Policy, end-to-end forwarding across multiple service endpoints is achieved, service paths are dynamically adjusted, and forwarding paths are recorded and updated in the service-aware gateway.
It enables dynamic scheduling and consistent forwarding across multiple service endpoints, improving service levels and resource utilization, and ensuring the integrity and reliability of the service chain.
Smart Images

Figure CN2025086301_05032026_PF_FP_ABST
Abstract
Description
Serial scheduling system and method for services
[0001] Cross-reference to related applications
[0002] This disclosure is based on and claims priority to Chinese patent application CN202411180028.8, filed on August 26, 2024, entitled “Serial Scheduling System and Method for Services”, the entire contents of which are incorporated herein by reference. Technical Field
[0003] This disclosure relates to the field of network communication technology, and in particular to a serial scheduling system and method for services. Background Technology
[0004] 5G is driving edge computing to become a hot topic, accelerating the deployment of MEC (Multi-access Edge Computing). For emerging businesses such as the Industrial Internet, network-side edge computing, and even field-level edge computing, will provide users with flexible, proximity-based access and an exceptional user experience. Therefore, computing power is shifting from centralized to decentralized, with distributed resources, computing power, and distributed services becoming the trend. On the other hand, with the development of container technology and microservice architecture, applications are being deconstructed into functions and services, and the network is shifting from host-oriented addressing to service- and computing power-oriented addressing.
[0005] In some situations, Kubernetes breaks down the boundaries of underlying server and network computing resources, bringing unlimited possibilities for flexible deployment, rapid recovery, elastic scaling, and maximizing resource efficiency. However, with the rapid development of microservices, businesses have more granular requirements for different versions and traffic control of the same Service, ideally achieving Pod-level traffic control, observability, and so on.
[0006] With the emergence of service meshes, Istio, for example, leverages the Kubernetes Pod concept to automatically inject `istio-proxy` and `initial` containers into each injected Pod upon deployment, based on user configuration. The `initial` container modifies the iptables rules of the Pod's individual network namespace, directing traffic requiring proxying to the ports listened to by `istio-proxy`. `istio-proxy` listens on both inbound and outbound ports, implementing proxying and intervention for inbound and outbound traffic according to the mesh configuration. Pods injected with the same Istio are considered to be within the same service mesh; their calls are no longer at the service level and will hit the relevant Istio cluster configuration endpoint. This enables Pod-level traffic management, observability, and security configurations.
[0007] Applications address services by name (e.g., hostnames resolved via DNS) to avoid the vulnerability of addressing services by IP address (which is initially unknown, can change at any time, is difficult to remember, and may be adjusted between IPv4 and IPv6 depending on the environment). Therefore, Istio's network configuration uses a name-centric model, where:
[0008] Gateway public name;
[0009] VirtualService configuration and route name;
[0010] The DestinationRule describes how to communicate with the workload behind the name;
[0011] ServiceEntry allows the creation of new names.
[0012] When cross-cluster communication is required, taking a multi-control plane deployment mode as an example, each Kubernetes cluster contains an independent Istio control plane. Istio does not actively enable service access between clusters; users need to actively register service entries for inter-cluster communication. This includes configuring DNS and gateways, registering ServiceEntries, etc. To support service name resolution and verifiable identities, all namespaces, services, and service accounts need to be defined identically in each cluster. Multi-cluster deployment combines multiple clusters into a single logical unit, and the control plane has a logical view of all services across all clusters.
[0013] In a multi-control-plane mesh topology, each cluster has an equal identity; for any given cluster, any other cluster is a remote cluster. The built-in DNS service within the Kubernetes cluster (KubeDNS or CoreDNS) is responsible for resolving service domain names. To distinguish whether a request is destined for a service in the local cluster or a remote cluster, Istio uses `global` to point to the remote cluster service. Taking accessing a service in cluster 2 from cluster 1 as an example, a `ServiceEntry` needs to be configured in cluster 1. The `addresses` field sets the VIP of the destination service, and the `endpoints` field for that service should contain the ingress gateway address of cluster 2 (`CLUSTER2_GW_ADDR`).
[0014] The semantics of Istio are: route traffic from cluster 1 to addresses to the ingress gateway of cluster 2. The VIP configured above will not be used as the actual destination address at the inter-cluster IP layer. When a client in cluster 1 initiates access to this IP, the traffic will be intercepted by the corresponding sidecar, which will then translate the destination IP to the ingress gateway address of cluster 2.
[0015] With the widespread adoption of cloud-native applications, applications are no longer typically monolithic services. Instead, they are decomposed into a series of cloud-native services deployed within a Kubernetes cluster. These services maintain call chains and collectively provide services to the outside world. Correspondingly, technologies such as swimlanes have emerged. In, for example, strict mode, each swimlane contains all services along the call chain.
[0016] Each time a swimlane is created, a corresponding DestinationRule is automatically generated for that swimlane. After the swimlane is created, a VirtualService corresponding to the swimlane rule is generated for each service in the swimlane group. These network APIs can be directed to a specific swimlane by matching some predefined tags. Summary of the Invention
[0017] Currently, computing power networks, a new technological form and operating model, have emerged. Increasingly complex and diverse applications and services will lead to scenarios involving the dynamic deployment of heterogeneous, widespread, and large-scale service (or microservice) instances. This also presents new requirements for the construction, management, and operation of computing power network infrastructure. These are mainly reflected in:
[0018] (1) East-west traffic for service interconnection and scheduling across resource pools, management domains, and infrastructures is increasing. Access to remote services by local services requires prior management and registration of remote services on the local end. Therefore, the large-scale, dynamic, and potentially on-demand service deployment methods pose significant new challenges to the local end's remote or global service management capabilities. Remote services may be dynamically launched and released, making static CRUD operations and management of locally registered services (such as modifying API configuration files in Istio) a huge burden.
[0019] (2) Applications and services are becoming increasingly complex and diverse, often concealing the collaborative and chained scheduling relationships of multiple sub-services corresponding to microservices. Service interconnection means that business traffic will pass through multiple service endpoints over the network. However, the service endpoints and the network connecting them cannot effectively understand the overall service logic they carry, i.e., the service chain. This is because, unlike traditional network service function chains (SFCs), where packets do not terminate between service endpoints (such as NSH-based or SRv6-based SFCs), in application-layer microservice chain scenarios, whenever a service endpoint requests the next service, it always terminates the incoming packet and sends a completely new packet. The preceding and following packets have no direct relationship; information such as the IP address and SRH of the incoming packet cannot be directly inherited. Therefore, ensuring consistent service capabilities is a characteristic that existing mechanisms cannot satisfy.
[0020] (3) The selection and scheduling of remote service endpoints by the service endpoint is often static or based on static deployment strategies, such as round-robin or weighted round-robin. This means that the service endpoint cannot dynamically select the next endpoint based on the remote resource situation and service capabilities, as well as the network conditions connecting to the remote service. Consequently, this may lead to a deterioration in service levels and a decrease in the utilization of computing network resources.
[0021] In the solutions mentioned in the background technology section, in wide-area multi-cluster scenarios, services are still managed through configuration and static policies. They are unaware of the wide-area network capabilities connecting the clusters and cannot achieve dynamic scheduling and load balancing. In addition, for each independent service endpoint, the routing of remote services is still isolated, that is, the perspective of a microservice may exist in one or more microservice chain call relationships is missing.
[0022] To address the aforementioned issues, this disclosure provides a serial scheduling scheme for services and proposes a method for inheriting a consistent scheduling strategy after the service endpoint terminates the message.
[0023] According to one embodiment of this disclosure, a service serial scheduling system is provided. The system includes: a service-aware gateway configured to receive a first service traffic packet, the first service traffic packet including a service chain identifier, a service identifier, and a service routing forwarding SID; recording forwarding paths and remaining forwarding items in a service traffic forwarding cache table according to the forwarding semantics of the service routing forwarding SID; and searching for the next-hop edge cloud gateway and outgoing interface in a local service routing table according to the service chain identifier, and delivering the first service traffic packet to the edge cloud for service execution; a service proxy node configured to intercept the first service traffic packet, record the service chain identifier and the service identifier, and send the first service traffic packet; and a service endpoint corresponding to the service proxy node configured to extract the service chain identifier and service identifier from the first service traffic packet, process the payload of the first service traffic packet, and combine the extracted service chain identifier and service identifier to form and send a second service traffic packet; the service proxy node configured to receive the second service traffic packet, and, if the recorded service chain identifier and service identifier are consistent with the service chain identifier and service identifier carried in the second service traffic packet, according to a preset service logic... The system updates the service identifier to the next service identifier, so that the service instance corresponding to the next service identifier is configured in the edge cloud as the service routing cache inherited forwarding SID of the service-aware gateway, and sends the second service traffic to the service-aware gateway. The service-aware gateway is configured to receive the second service traffic packet, and according to the forwarding semantics of the service routing cache inherited forwarding SID, look up the forwarding path and forwarding remainder in the service traffic forwarding cache table through the service chain identifier, insert the forwarding path into the header of the second service traffic packet, update the forwarding remainder, determine the header of the second service traffic packet according to the forwarding path and the updated forwarding remainder, and send the second service traffic packet. The service-aware gateway is also configured to receive a third service traffic packet, the third service traffic packet including a service chain identifier, a service identifier, and a service routing initial forwarding SID; according to the forwarding semantics of the service routing initial forwarding SID, look up the service chain forwarding table through the service chain identifier and the service identifier to determine the corresponding forwarding path; determine the header of the third service traffic packet according to the forwarding path, and send the third service traffic packet.
[0024] According to another embodiment of this disclosure, a serial scheduling method for services is provided, applied to a service-aware gateway, comprising: receiving a first service traffic packet, the first service traffic packet including a service chain identifier, a service identifier, and a service routing forwarding SID; searching for the service chain identifier and the forwarding path corresponding to the service identifier in a service chain forwarding table according to the forwarding semantics of the service routing forwarding SID; recording the forwarding path and the remaining forwarding entries in a service traffic forwarding cache table; and searching for the next-hop edge cloud gateway and the outgoing interface in a local service routing table according to the service chain identifier, and delivering the first service traffic packet to the edge cloud for service execution.
[0025] According to another embodiment of this disclosure, a serial scheduling method for services is provided, applied to a service proxy node, comprising: intercepting a first service traffic packet from a service-aware gateway, the first service traffic packet including a service chain identifier and a service identifier; recording the service chain identifier and the service identifier, and sending the first service traffic packet to a corresponding service endpoint; receiving a second service traffic packet from the service endpoint; if the recorded service chain identifier and service identifier are consistent with the service chain identifier and service identifier carried in the second service traffic packet, updating the service identifier to a next service identifier according to a preset service logic, such that the service instance corresponding to the next service identifier is configured in the edge cloud as the service routing cache inheritance forwarding SID of the service-aware gateway, and sending the second service traffic to the service-aware gateway.
[0026] According to yet another embodiment of the present disclosure, a wireless communication device is provided, including a memory storing one or more programs and a processor electrically coupled to the memory and configured to execute one or more programs to perform any methods or steps of the present disclosure or combinations thereof.
[0027] According to yet another embodiment of the present disclosure, a non-transitory computer-readable storage medium is provided that stores one or more programs configured to, when executed by a processor, cause any methods or steps or combinations thereof in the present disclosure to be performed.
[0028] The above and other aspects and their implementations are described in more detail in the accompanying drawings, description and claims. Attached Figure Description
[0029] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without exceeding the scope of protection claimed by this disclosure.
[0030] Figure 1 is a schematic diagram of a serial scheduling system for services according to an embodiment of the present disclosure.
[0031] Figure 2 is a schematic diagram of the composition of the header in a service traffic message according to an embodiment of the present disclosure.
[0032] Figure 3 is a schematic diagram illustrating path protection in the event of failure or degradation of the expanded list obtained by expanding the BSID of the next-hop service-aware gateway according to an embodiment of the present disclosure.
[0033] Figure 4 is a schematic diagram illustrating instance protection when the service-aware gateway or the corresponding service instance is unavailable according to an embodiment of this disclosure.
[0034] Figure 5 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to the first embodiment of this disclosure.
[0035] Figure 6 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a second embodiment of the present disclosure.
[0036] Figure 7 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a third embodiment of the present disclosure.
[0037] Figure 8 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a fourth embodiment of the present disclosure.
[0038] Figure 9 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a fifth embodiment of the present disclosure.
[0039] Figure 10 is a flowchart of a service serial scheduling method implemented by a service proxy node according to an embodiment of the present disclosure.
[0040] Figure 11 is a structural diagram of an electronic device provided in this disclosure. Detailed Implementation
[0041] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.
[0042] Throughout the specification and claims, terms may have subtle meanings implied or implied in the context, rather than explicitly stated meanings. Similarly, the phrases “in one embodiment” or “in some embodiments” as used herein do not necessarily refer to the same embodiment, and the phrases “in another embodiment” or “in other embodiments” as used herein do not necessarily refer to different embodiments. The phrases “in one implementation” or “in some implementations” as used herein do not necessarily refer to the same implementation, and the phrases “in another implementation” or “in other implementations” as used herein do not necessarily refer to different implementations. For example, the claimed subject matter includes all or part of a combination of exemplary embodiments or implementations.
[0043] Generally, terms can be understood at least in part from their use in context. For example, terms used herein, such as “and,” “or,” and “and / or,” can include a variety of meanings, which can depend at least in part on the context in which they are used. Typically, “or,” when used in an associative list, such as A, B, or C, means A, B, and C, here used for inclusion, and A, B, or C, here used only for exclusion. Furthermore, the terms “one or more” or “at least one,” as used herein, depend at least in part on the context and can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, and characteristics in a plural sense. Similarly, terms such as “a,” “an,” or “described,” depend at least in part on the context and can be understood to convey either singular or plural usage. Moreover, also depending at least in part on the context, the terms “based on” or “determined by” can be understood not necessarily to indicate a set of exclusive factors; rather, they may allow for the presence of other factors that are not necessarily explicitly described.
[0044] Figure 1 is a schematic diagram of a serial scheduling system for services according to an embodiment of the present disclosure. As shown in Figure 1, the system includes a service gateway (App GW), service-aware gateway I, service-aware gateway X, service-aware gateway Y, service-aware gateway Z, service endpoints (App pods) A, B, and C corresponding to service-aware gateways X, Y, and Z, and service proxy nodes (or sidecars) corresponding to service endpoints A, B, and C, respectively.
[0045] In the embodiment shown in Figure 1, an App service can be composed of services A, B, and C, which are processed and provided sequentially to jointly provide an overall service. Those skilled in the art will understand that, according to actual needs, an App service can be divided into multiple different services (or microservices), processed and provided sequentially to jointly provide an overall service. This disclosure does not limit how an App service is divided or the number of services. For example, a deep learning service can be deconstructed into multiple microservices, including: a data preprocessing service, responsible for data preprocessing, including but not limited to data cleaning, feature engineering, and data augmentation; a model training service, responsible for model training, including model selection, hyperparameter adjustment, and model training; a model prediction service, responsible for model prediction, receiving input data and predicting results through the model; a model evaluation service, responsible for model evaluation, including calculating model performance metrics and visualizing model effects; a model update service, responsible for updating the model; and a model storage service, responsible for model storage, including model saving and version management.
[0046] According to the embodiment shown in Figure 1, when a user initiates a service request, the local service gateway information (App GW) is obtained through methods such as DNS. The user service request arrives at the service gateway and is processed by the service gateway. The service gateway identifies the user service request and determines that it belongs to one of the services registered within the service operation and management domain contract. Within the service operation and management domain, it completes the final delivery through the coordination and scheduling of a group of services (or microservices). A service chain corresponding to the service is formed in the service operation and management domain, and this service chain has a corresponding service chain identifier. The service gateway finds the service chain identifier of the service and encapsulates the service chain identifier SFC-ID and the first service identifier under the service chain (e.g., S-ID A) in the application layer header and network layer header of the service traffic packet (hereinafter referred to as "packet"). The destination address of the packet can be filled in as the SRv6 SID (Service Init SID I) defined on the nearest access service-aware gateway I.
[0047] As shown in Figure 2(1), the lower box corresponds to the application layer header, and the upper box corresponds to the network layer header. The service chain identifier SFC-ID and the first service identifier (S-ID A) under the service chain are encapsulated in the application layer header and network layer header of the message. The destination address of the network layer header of the message is filled with the service route initial forwarding SID (Service Init SID I).
[0048] Service-aware gateway I receives a packet and identifies the service chain identifier and service identifier in the network layer packet header based on the forwarding semantics of Service Init SID I. The Service Init SID is defined on the initial gateway or the service-aware gateway of the first service in the service chain. The forwarding semantics involve looking up the service chain identifier and service identifier encapsulated in the packet header, using them as an index to look up the service chain forwarding table (as shown in Table 1), and inserting a forwarding path matched in the forwarding table into the current packet header using an Insert method, such as in the IPv6 packet header.
[0049] Table 1
[0050] In this way, by using the service chain identifier and service identifier as keys, a lookup is performed on a service chain forwarding table issued by a centralized orchestrator. A forwarding path consisting of (BSID X, Service SID X, BSID Y, Service SID Y, BSID Z, Service SID Z, END SID) that matches the service chain provides transmission guarantees across multiple service endpoints. The corresponding forwarding path is then encapsulated in the packet header using a method such as Insert, for example, in an IPv6 extension header. The packet header is determined based on the forwarding path. The service chain forwarding table reflects the mapping relationship between the service chain identifier, service identifier, and forwarding path. According to one embodiment, the service chain identifier encoding method includes time / process sequence + service chain type. For the service chain forwarding table, flow information such as time / process sequence may not be used as a key.
[0051] According to some embodiments, as shown in Figure 2(2), the lower box corresponds to the application layer packet header, the middle box corresponds to the network layer inner packet header (hereinafter referred to as the inner packet header), and the upper box corresponds to the network layer outer packet header (hereinafter referred to as the outer packet header). The forwarding path is encapsulated in the inner packet header. At the same time, the outer packet header of the packet is determined according to the network path information of the service-aware gateway corresponding to the first item in the forwarding path.
[0052] The end-to-end application forwarding path orchestrated by the control plane (corresponding to the BSID and Service SID in the embodiment shown in Figure 2) identifies the specific instance of each service in the application service chain and also identifies the network path connecting the gateway of this service instance. The network path can be represented by a Binding SID of an SRv6 Policy (TE: Traffic Engineering). Other methods include directly using the SID of the service instance's service-aware gateway (by default) to represent the BE path (Best Effort) to that gateway, or configuring static routes for the SID of the service instance's service-aware gateway to redirect traffic to other types of tunnels (GRE tunnels, etc.), etc. For ease of explanation, this document describes the network path using the "Binding SID of an SRv6 Policy." Other methods that those skilled in the art can understand based on the network path implementation methods given in this disclosure are all within the scope of this disclosure.
[0053] According to a specific embodiment, when the network path information of the first service-aware gateway is the BSID (Binding Segment identifier) of the first service-aware gateway, the BSID of the first service-aware gateway is expanded according to a preset definition to obtain an expanded list. Then, the expanded list is encapsulated in the outer header of the packet, and the destination address of the outer header is set as the first item of the expanded list. According to a specific embodiment, as shown in Figure 2(2), BSID X is defined in the service-aware gateway I, representing a Segment List of an SRv6 Policy (Segment Routing over IPv6 Policy) for the service-aware gateway X corresponding to the next hop service of the service-aware gateway I. The corresponding Segment List is expanded (BSID X LIST), and an outer IPv6 packet header is added by means such as Encaps. The Segment List is encapsulated in the SRH (Segment Routing Header) of the outer IPv6 packet header, and the destination address of the outer IPv6 packet is filled in the first Segment. Service-aware gateway I forwards the packet segment by segment to the next service-aware gateway X according to the Segment List of the outer packet. Finally, the Service Routing Forwarding SID (Service SID X) immediately following the network path information (BSID X) of the first item in the forwarding path corresponding to the service-aware gateway is set as the destination address of the inner packet header. According to one embodiment, in Figure 2, the small box (without background color) represents the extended header portion of the packet header.
[0054] As shown in Figure 1, the packet ends at Service Aware Gateway X. The Segment List corresponding to BSID X has been completely traversed. After removing the outer packet header, Service Aware Gateway X performs forwarding semantics based on the next Service SID X in the inner packet header BSID X. Here, Service SID (Service Routing Forwarding SID) is defined on each Service Aware Gateway. The forwarding semantics are to look up the service chain identifier and service identifier encapsulated in the packet header in the service chain forwarding table (as shown in Table 1), use these two identifiers as keys, and use the forwarding path where the Service SID is located as the value to record it in the current device's service traffic forwarding cache table (as shown in Table 2). If it already exists in the cache table, the corresponding table entry can be updated, and the forwarding path can be decapsulated and retrieved. Then, the device's local service routing table (as shown in Table 3) is looked up using the service chain identifier as the index, and the outgoing interface forwarding with destination address replacement is performed according to the matched forwarding table entry.
[0055] In this way, based on the forwarding semantics of Service SID X, information such as SRH (including forwarding path) and SL (Segment LEFT) is retrieved and cached, and the local service routing table (as shown in Table 3) is used to look up the forwarding based on the service chain identifier in the packet. The service-aware gateway then records the forwarding path and forwarding remainder in the service traffic forwarding cache table (as shown in Table 2), and looks up the next-hop edge cloud gateway (such as the gateway address of the local resource pool) and the outgoing interface in the local service routing table. It then changes the next-hop edge cloud gateway to the new destination address and forwards the packet to it, thus delivering the service to the edge cloud using a Native IP packet.
[0056] Table 2
[0057] Table 3
[0058] Next, the message enters the edge cloud. Before reaching the application service endpoint, it is first intercepted by the service proxy node of the application service endpoint. The service proxy node records the service chain identifier and service identifier carried in the message and then sends the message to the application service endpoint. The application service endpoint first extracts the service chain identifier and service identifier from the application layer message header and processes the payload content. After processing, it attaches the previously extracted service chain identifier and service identifier back to the newly sent message. The sent message is intercepted by the service proxy node again. The service proxy node matches the message with the cached service chain identifier and service identifier. That is, the recorded service chain identifier and service identifier are consistent with the service chain identifier and service identifier carried in the message. According to the preset service logic, the service identifier is updated to the next service identifier, as shown in Figure 2(3). The next service is changed to service B (S-ID B). Service B is configured as the service route cache inherited forwarding SID (Service Inherit SID X) of the service-aware gateway at the endpoint of the edge cloud. Therefore, the message is sent to the service-aware gateway X.
[0059] For Service Inherit SID, it is defined on the service-aware gateway of each service. The forwarding semantics involve looking up the service chain identifier encapsulated in the packet header, using it as an index to search the service traffic forwarding cache table. Based on the forwarding path and remaining entries in the routing cache table, the forwarding path is re-inserted into the packet header using an INSERT-like method, and the remaining entries are updated accordingly. Additionally, if the service traffic forwarding cache table cannot be found, the service chain forwarding table can be queried.
[0060] According to one embodiment, in a service mesh deployment scenario such as Istio, the Service Inherit SID, as an IPv6 address, needs to be configured in the ServiceEntry network API within the cluster connected to the service-aware gateway. This allows the sidecar / proxy to intercept packets and modify the destination address to the Service Inherit SID, enabling the service-aware gateway to perform forwarding actions based on the forwarding semantics of the SID.
[0061] Service-aware gateway X, based on the forwarding semantics of Inherit SID X, identifies the service chain identifier in the packet header. Using the service chain identifier as the key, it finds the cached forwarding path (BSID X, Service SID X, BSID Y, Service SID Y, BSID Z, Service SID Z, END SID) and the current forwarding remainder value. It then re-inserts the forwarding path into the packet using an Insert method. Based on the change in the forwarding remainder count, it points to BSID Y, as shown in Figure 2(4). BSID Y is also predefined in this service-aware gateway X, representing a list of SRv6 policies (Segment List) that service-aware gateway X uses to access the next-hop service corresponding to service-aware gateway Y. Therefore, it expands the corresponding Segment List, adds an outer packet header using an Encaps method, and encapsulates the Segment List in the SRH of the outer packet header. The destination address of the outer packet header is filled with the first Segment. Finally, the Service Routing Forwarding SID (Service SID Y) immediately following the Network Path Information (BSID Y) in the forwarding path is set to the destination address of the inner header of the packet.
[0062] Finally, the above process is repeated until service C after service-aware gateway Z completes its service and sends the final processed data packet back to service gateway App GW. That is, service-aware gateway Z inserts a forwarding path (BSID X, Service SID X, BSID Y, Service SID Y, BSID Z, Service SID Z, END SID) for the packet based on Inherit SID Z. Based on the count change of the remaining forwarding items, it points to the final END SID. The END SID can be defined as the SID of service-aware gateway I of App GW (such as END.DT, END.DX). Finally, the packet is sent back to service gateway App GW and returned to the user.
[0063] In terms of message data plane processing and transmission, wide-area cross-cluster microservice interconnection and scheduling can inherit and utilize the SRv6 data plane encapsulation method in the traditional wide area network scope, and it is also possible to utilize the SRv6 over UDP encapsulation method in some areas such as edge cloud and cluster.
[0064] According to some embodiments, as shown in Figure 3, when the service-aware gateway X detects that the network path corresponding to the BSID is disabled or degraded, but the service-aware gateway Y and the corresponding service instance are still available, the original BSID Y can be directly replaced with the backup BSID Y corresponding to the backup SRv6 Policy in the service link forwarding table and the service traffic forwarding cache table. At this time, although the service traffic is diverted to a different SRv6 Policy, since the service-aware gateway Y has not changed, the Service SID Y does not need to be replaced.
[0065] Furthermore, in scenarios where the service-aware gateway or its corresponding service instance is unavailable, a backup (or proxy) SID can be generated based on the BSID and / or Service SID encoded in the forwarding path of the service chain forwarding table entry. As shown in Figure 4, when the service-aware gateway Y or its corresponding service instance is unavailable, neither BSID Y nor Service SID Y has routing significance. Moreover, the unavailability of the service-aware gateway Y or its corresponding service instance may cause the entire original service chain to become unavailable. Therefore, in this case, as shown in Table 4, the service-aware gateway Y uses the backup path of the service chain forwarding table entry corresponding to the service chain identifier as the primary path and deletes the associated information in the service traffic forwarding cache table, causing the corresponding traffic to query the service chain forwarding table for forwarding.
[0066] Table 4
[0067] Based on the above system, according to one aspect of this disclosure, a service serial scheduling method is provided. Figure 5 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a first embodiment of this disclosure. As shown in Figure 5, the method includes:
[0068] Step S501: Receive a first service traffic packet, the first service traffic packet including a service chain identifier, a service identifier, and a service routing forwarding SID;
[0069] Step S502: Based on the forwarding semantics of the service routing forwarding SID, look up the service chain identifier and the forwarding path corresponding to the service identifier in the service chain forwarding table;
[0070] Step S503: Record the forwarding path and remaining forwarding entries in the service traffic forwarding cache table; and
[0071] Step S504: Based on the service chain identifier, look up the next-hop edge cloud gateway and outgoing interface in the local service routing table, and deliver the first service traffic packet to the edge cloud to perform the service.
[0072] Figure 6 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a second embodiment of the present disclosure. Compared with Figure 5, steps S601 to S604 of Figure 6 are the same as steps S501 to S504 of Figure 5, except that the method shown in Figure 6 further includes:
[0073] Step S605: Receive a second service traffic packet from the edge cloud, the second service traffic packet including a service chain identifier, a service identifier, and a service routing cache inherited forwarding SID;
[0074] Step S606: Based on the forwarding semantics of the service routing cache inherited forwarding SID, the forwarding path and remaining forwarding entries are searched in the service traffic forwarding cache table using the service chain identifier;
[0075] Step S607: Insert the forwarding path into the header of the second service traffic packet and update the forwarding remainder;
[0076] Step S608: Determine the header of the second service traffic packet based on the forwarding path and the updated forwarding remnant; and
[0077] Step S609: Send the second service traffic message.
[0078] According to some embodiments, step S608 may specifically include:
[0079] Based on the updated forwarding remainder and the forwarding path, obtain the network path information to the next-hop service-aware gateway;
[0080] The outer header of the second service traffic packet is determined based on the network path information of the next-hop service-aware gateway; and
[0081] Set the service routing forwarding SID immediately following the network path information of the next-hop service-aware gateway in the forwarding path to the destination address of the inner header of the second service traffic packet.
[0082] According to some embodiments, when the network path information of the next-hop service-aware gateway includes the BSID of the next-hop service-aware gateway, determining the outer header of the second service traffic packet based on the network path information of the next-hop service-aware gateway may specifically include:
[0083] According to the preset definition, the BSID of the next-hop service-aware gateway is expanded to obtain the expanded list;
[0084] The expanded list is encapsulated in the outer header of the second service traffic packet, and the destination address of the outer header is set as the first item in the expanded list.
[0085] Figure 7 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a third embodiment of the present disclosure. Compared with Figure 5, steps S701 to S704 of Figure 7 are the same as steps S501 to S504 of Figure 5, except that the method shown in Figure 7 further includes:
[0086] Step S705: Receive a third service traffic packet, wherein the third service traffic packet includes a service chain identifier, a service identifier, and a service route initial forwarding SID;
[0087] Step S706: Based on the forwarding semantics of the initial forwarding SID of the service route, the service chain forwarding table is looked up using the service chain identifier and the service identifier to determine the corresponding forwarding path;
[0088] Step S707: Determine the header of the third service traffic packet based on the forwarding path; and
[0089] Step S708: Send the third service traffic message.
[0090] According to some embodiments, step S707 may specifically include:
[0091] The forwarding path is encapsulated in the inner header of the third service traffic packet;
[0092] The outer header of the third service traffic packet is determined based on the network path information of the service-aware gateway corresponding to the first item in the forwarding path; and
[0093] Set the service routing forwarding SID immediately following the network path information of the service-aware gateway corresponding to the first item in the forwarding path to the destination address of the inner header of the third service traffic packet.
[0094] Figure 8 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a fourth embodiment of the present disclosure. Compared with Figure 5, steps S801 to S804 of Figure 8 are the same as steps S501 to S504 of Figure 5, except that the method shown in Figure 8 further includes:
[0095] Step S805: If the network path corresponding to the next-hop service-aware gateway in the forwarding path is disabled or degraded, the network path is replaced with a backup network path in the service link forwarding table and the service traffic forwarding cache table, so as to forward service traffic to the next-hop service-aware gateway through the backup network path.
[0096] Figure 9 is a flowchart of a service serial scheduling method implemented by a service-aware gateway according to a fifth embodiment of the present disclosure. Compared with Figure 5, steps S901 to S904 of Figure 9 are the same as steps S501 to S504 of Figure 5, except that the method shown in Figure 9 further includes:
[0097] Step S905: If the current service-aware gateway and / or the corresponding service instance are unavailable, the preset backup forwarding path in the service chain forwarding table corresponding to the service chain identifier is used as the primary forwarding path, and the associated information in the service traffic forwarding cache table is deleted, so that the service chain forwarding table is queried to forward service traffic.
[0098] Based on the above system, according to another aspect of this disclosure, a service serial scheduling method is provided. Figure 10 is a flowchart of a service serial scheduling method implemented by a service proxy node according to an embodiment of this disclosure. As shown in Figure 10, the method includes:
[0099] Step S1001: Intercept a first service traffic packet from the service-aware gateway. The first service traffic packet includes a service chain identifier and a service identifier.
[0100] Step S1002: Record the service chain identifier and the service identifier, and send the first service traffic packet to the corresponding service endpoint;
[0101] Step S1003: Receive a second service traffic packet from the service endpoint;
[0102] Step S1004: If the recorded service chain identifier and service identifier are consistent with the service chain identifier and service identifier carried in the second service traffic packet, the service identifier is updated to the next service identifier according to the preset service logic, so that the service instance corresponding to the next service identifier is configured as the service routing cache inheritance forwarding SID of the service-aware gateway in the edge cloud, and the second service traffic is sent to the service-aware gateway.
[0103] Based on the serial scheduling system and method for services provided in this disclosure, an end-to-end forwarding method across multiple service endpoints is proposed by defining new forwarding actions, routing and forwarding table entries. This method enables service interconnection across multiple service endpoints and full-lifecycle service assurance, and implements a scheduling strategy that ensures consistency after the service endpoint terminates the message.
[0104] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0105] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this disclosure is not limited to the described order of actions, because according to this disclosure, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this disclosure.
[0106] In the several embodiments provided in this disclosure, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical connections or other forms.
[0107] Referring to Figure 11, Figure 11 provides a wireless communication device including a processor and a memory. The memory stores computer instructions or one or more programs, which, when executed by the processor, cause the processor to execute the computer instructions to implement the methods and refinements shown in Figures 5 to 10.
[0108] It should be understood that the above-described device embodiments are merely illustrative, and the device disclosed in this invention can be implemented in other ways. For example, the division of units / modules described in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, integrated into another system, or some features may be ignored or not executed.
[0109] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of the present invention can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.
[0110] If the integrated unit / module is implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor or chip can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the on-chip cache, off-chip memory, and storage can be any suitable magnetic or magneto-optical storage medium, such as resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), etc.
[0111] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer electronic device (which may be a personal computer, server, or network electronic device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0112] This disclosure also provides a non-transitory computer-readable storage medium storing one or more computer programs that, when executed by a plurality of processors, cause the processors to perform the methods and refinements shown in Figures 5 to 10.
[0113] References to features, advantages, or similar language in this specification do not imply that all features and advantages achievable with this solution should be included or included in any single implementation thereof. Rather, references to features and advantages are understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this solution. Therefore, discussions of features, advantages, and similar language throughout this specification may, but do not necessarily, refer to the same embodiments.
[0114] Furthermore, the features, advantages, and characteristics described herein can be combined in any suitable manner in one or more embodiments. Based on the description herein, those skilled in the art will recognize that this solution can be implemented without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages can be appreciated in specific embodiments not presented in all embodiments of this solution.
[0115] The embodiments of this disclosure have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this disclosure. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of this disclosure, and on the specific implementation methods and application scope of this disclosure, are all within the scope of protection of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.
Claims
A serial scheduling system for services, comprising: The service-aware gateway is configured to receive a first service traffic packet, which includes a service chain identifier, a service identifier, and a service routing forwarding SID. Based on the forwarding semantics of the service routing forwarding SID, the gateway records the forwarding path and the remaining forwarding items in the service traffic forwarding cache table. Based on the service chain identifier, the gateway looks up the next-hop edge cloud gateway and the outgoing interface in the local service routing table and delivers the first service traffic packet to the edge cloud for service execution. The service proxy node is configured to intercept the first service traffic packet, record the service chain identifier and the service identifier, and send the first service traffic packet. The service endpoint, corresponding to the service proxy node, is configured to extract the service chain identifier and service identifier from the first service traffic packet, process the payload of the first service traffic packet, and combine the extracted service chain identifier and service identifier to form and send the second service traffic packet. The service proxy node is configured to receive the second service traffic packet. If the recorded service chain identifier and service identifier are consistent with the service chain identifier and service identifier carried in the second service traffic packet, the service identifier is updated to the next service identifier according to the preset service logic. This causes the service instance corresponding to the next service identifier to be configured as the service routing cache inheriting forwarding SID of the service-aware gateway in the edge cloud, and the second service traffic is sent to the service-aware gateway. The service-aware gateway is configured to receive the second service traffic packet, inherit the forwarding semantics of the forwarding SID from the service routing cache, look up the forwarding path and forwarding remainder in the service traffic forwarding cache table through the service chain identifier, insert the forwarding path into the packet header of the second service traffic packet, update the forwarding remainder, determine the packet header of the second service traffic packet based on the forwarding path and the updated forwarding remainder, and send the second service traffic packet. The service-aware gateway is also configured to receive third service traffic packets, the third service traffic packets including service chain identifier, service identifier, and service route initial forwarding SID; Based on the forwarding semantics of the initial forwarding SID of the service route, the service chain forwarding table is looked up using the service chain identifier and the service identifier to determine the corresponding forwarding path; The header of the third service traffic packet is determined according to the forwarding path, and the third service traffic packet is sent. The system as described in claim 1, wherein, The service-aware gateway is configured as follows: Based on the updated forwarding remainder and the forwarding path, obtain the network path information to the next-hop service-aware gateway; The outer header of the second service traffic packet is determined based on the network path information of the next-hop service-aware gateway. as well as Set the service routing forwarding SID immediately following the network path information of the next-hop service-aware gateway in the forwarding path to the destination address of the inner header of the second service traffic packet. The system as described in claim 2, wherein, The network path information of the next-hop service-aware gateway includes the BSID of the next-hop service-aware gateway, and the service-aware gateway is configured as follows: According to the preset definition, the BSID of the next-hop service-aware gateway is expanded to obtain the expanded list; The expanded list is encapsulated in the outer header of the second service traffic packet, and the destination address of the outer header is set as the first item in the expanded list. The system as described in claim 1, wherein, The service-aware gateway is configured as follows: The forwarding path is encapsulated in the inner header of the third service traffic packet; The outer header of the third service traffic packet is determined based on the network path information of the service-aware gateway corresponding to the first item in the forwarding path. as well as Set the service routing forwarding SID immediately following the network path information of the service-aware gateway corresponding to the first item in the forwarding path to the destination address of the inner header of the third service traffic packet. The system as described in any one of claims 1 to 4, wherein, The service-aware gateway is also configured to: In the event that the network path corresponding to the next-hop service-aware gateway in the forwarding path is disabled or degraded, the network path is replaced with a backup network path in the service link forwarding table and the service traffic forwarding cache table, so that the service traffic is forwarded to the next-hop service-aware gateway through the backup network path. The system as described in any one of claims 1 to 4, wherein, The service-aware gateway is also configured to: If the current service-aware gateway and / or the corresponding service instance are unavailable, the preset backup forwarding path in the service chain forwarding table corresponding to the service chain identifier is used as the primary forwarding path, and the associated information in the service traffic forwarding cache table is deleted, so that the service traffic can be forwarded by querying the service chain forwarding table. A serial scheduling method for services, applied to a service-aware gateway, includes: Receive a first service traffic packet, the first service traffic packet including a service chain identifier, a service identifier, and a service routing forwarding SID; Based on the forwarding semantics of the service routing forwarding SID, look up the service chain identifier and the forwarding path corresponding to the service identifier in the service chain forwarding table; Record the forwarding path and the remaining forwarding items in the service traffic forwarding cache table; as well as Based on the service chain identifier, the next-hop edge cloud gateway and outgoing interface are found in the local service routing table, and the first service traffic packet is delivered to the edge cloud to perform the service. A serial scheduling method for services, applied to service broker nodes, includes: Intercept the first service traffic packet from the service-aware gateway, the first service traffic packet including the service chain identifier and the service identifier; Record the service chain identifier and the service identifier, and send the first service traffic packet to the corresponding service endpoint; Receive a second service traffic packet from the service endpoint; If the recorded service chain identifier and service identifier are consistent with the service chain identifier and service identifier carried in the second service traffic packet, the service identifier is updated to the next service identifier according to the preset service logic, so that the service instance corresponding to the next service identifier is configured as the service routing cache inheritance forwarding SID of the service-aware gateway in the edge cloud, and the second service traffic is sent to the service-aware gateway. A wireless communication device includes a memory storing one or more programs and one or more processors, the one or more processors being electrically coupled to the memory and configured to execute the one or more programs to perform the method as claimed in claim 7 or 8. A non-transitory computer-readable storage medium storing one or more programs configured to cause the method of claim 7 or 8 to be performed when executed by a processor.
Citation Information
Patent Citations
Routing and cloud resource registration method and device, storage medium and electronic device
CN115733786A
Network security convergence gateway system based on service function chain
CN117792693A
Load balancing system for fast computing power expansion
CN118200323A
Service-aware network user drainage and traffic engineering implementation method and device
CN118264717A
Methods and arrangements for service function chaining and packet steering
WO2024006426A1