A cross-domain QoS routing method and device, a general controller and a storage medium

Abstract

The application discloses a cross-domain QoS routing method and device, a general controller and a storage medium. The method comprises the following steps: after receiving a service request sent by a domain controller, a plurality of candidate paths are determined based on a global virtual topology, the global virtual topology being generated based on an abstract result of abstracting an original domain topology by each domain controller; an index decomposition is performed based on the plurality of candidate paths to obtain a decomposition result, and the decomposition result is issued to a plurality of corresponding domain controllers as a decomposition requirement, so that the plurality of domain controllers determine corresponding target intra-domain paths based on the decomposition requirement; and target QoS routing is determined according to the target intra-domain paths. The method can realize efficient end-to-end QoS performance guarantee while using a small amount of intra-domain information by performing index decomposition on the plurality of candidate paths and performing intra-domain path planning according to the decomposition requirement by each domain controller.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a cross-domain QoS routing method, apparatus, central controller, and storage medium. Background Technology

[0002] With the continuous development of information technology, the Internet has gradually expanded from the consumer field to the fields of social production and the real economy, resulting in many new business scenarios, such as remote surgery, video conferencing, and holographic communication, which have put forward stringent requirements on end-to-end QoS indicators such as bandwidth and latency.

[0003] The current internet consists of numerous independent autonomous domains (AVMs), each managed by different operators or institutions. End-to-end transmission of business data may traverse multiple AVMs. However, the independent management of each domain, coupled with factors such as privacy protection and market competition, makes intra-domain information exchange difficult, which severely limits the guarantee of cross-domain QoS performance. Therefore, there is an urgent need to seek efficient cross-domain QoS routing technologies to safeguard the construction of production-ready internet. Summary of the Invention

[0004] This invention provides a cross-domain QoS routing method, apparatus, central controller, and storage medium to solve the problem that existing technologies cannot achieve efficient cross-domain QoS routing using limited intra-domain information.

[0005] According to one aspect of the present invention, a cross-domain QoS routing method is provided, comprising:

[0006] After receiving a service request from a domain controller, multiple candidate paths are determined based on a global virtual topology, which is generated based on the abstraction results obtained by each domain controller from the abstraction of the original domain topology.

[0007] Based on the multiple candidate paths, the index is decomposed to obtain the decomposition result, and the decomposition result is sent to the corresponding multiple domain controllers as the decomposition requirement, so that the multiple domain controllers can determine the corresponding target domain path based on the decomposition requirement.

[0008] Determine the target QoS route based on the path within the target domain.

[0009] According to another aspect of the present invention, a cross-domain QoS routing apparatus is provided, comprising:

[0010] The candidate path determination module is used to determine multiple candidate paths based on the global virtual topology after receiving a service request sent by the domain controller. The global virtual topology is generated based on the abstraction result obtained by each domain controller abstracting the original domain topology.

[0011] The decomposition module is used to decompose the indicators based on the multiple candidate paths to obtain the decomposition results, and to send the decomposition results as decomposition requirements to the corresponding multiple domain controllers so that the multiple domain controllers can determine the corresponding target domain paths based on the decomposition requirements.

[0012] The target QoS route determination module is used to determine the target QoS route based on the path within the target domain.

[0013] According to another aspect of the present invention, a master controller is provided, the master controller comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the cross-domain QoS routing method according to any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the cross-domain QoS routing method according to any embodiment of the present invention.

[0018] The technical solution of this invention, upon receiving a service request from a domain controller, determines multiple candidate paths based on a global virtual topology. This global virtual topology is generated based on the abstraction results obtained by each domain controller from the original intra-domain topology. The multiple candidate paths are then decomposed into metrics to obtain decomposition results, which are then distributed as decomposition requirements to the corresponding domain controllers. These domain controllers then determine the corresponding target intra-domain path based on the decomposition requirements. Finally, a target QoS route is determined based on the target intra-domain path. This solution achieves the beneficial effect of obtaining ideal end-to-end QoS performance while using a small amount of intra-domain information.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating a cross-domain QoS routing method provided in Embodiment 1 of the present invention;

[0022] Figure 2 This is a schematic diagram of a packet network scenario;

[0023] Figure 3 This is a schematic diagram of the global virtual topology in a cross-domain QoS routing method provided in Embodiment 1 of the present invention;

[0024] Figure 4 This is a schematic diagram of the topology abstraction process in a cross-domain QoS routing method provided in an embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of delay decomposition in a cross-domain QoS routing method provided in an embodiment of the present invention;

[0026] Figure 6 This is a schematic diagram of jitter decomposition in a cross-domain QoS routing method provided in an embodiment of the present invention;

[0027] Figure 7 This is a schematic diagram of packet loss decomposition in a cross-domain QoS routing method provided in an embodiment of the present invention;

[0028] Figure 8 This is a flowchart of a cross-domain QoS routing method provided in Embodiment 2 of the present invention;

[0029] Figure 9 This is a schematic diagram of the structure of a cross-domain QoS routing device provided in Embodiment 3 of the present invention;

[0030] Figure 10 This is a schematic diagram of the overall controller structure of the cross-domain QoS routing method according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention. It should be understood that the various steps described in the method embodiments of the present invention can be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0032] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] It should be noted that the terms "a" and "a plurality of" used in this invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0035] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0036] Existing technologies include protocol-based cross-domain routing, centralized control-based cross-domain routing, and hierarchical routing.

[0037] Cross-domain routing based on protocols propagates routing and reachability information between domains through inter-domain routing protocols, thereby completing end-to-end path planning. A typical protocol is the Border Gateway Protocol (BGP). However, BGP does not transmit real-time link state (bandwidth, latency, etc.) and does not provide multiple alternative route options, thus failing to guarantee cross-domain QoS performance. Furthermore, after topology changes, the decentralized nature of BGP leads to slow route convergence, which in turn affects service routing quality (especially for time-sensitive applications). To address these issues, the BGP protocol has been continuously improved, for example, by adding path state information to signaling or keep-alive messages.

[0038] However, cross-domain routing based on BGP still faces the following problems: (1) It is difficult to avoid the distributed nature of BGP, resulting in slow route convergence; (2) Each domain cannot control the routing of other domains, so the path of external domains will change, resulting in the inability to guarantee end-to-end QoS; (3) Continuous announcement of status information will lead to excessive communication, while reducing the communication frequency will make it difficult for emergency services to obtain ideal QoS performance.

[0039] In the cross-domain routing based on centralized control, each autonomous domain has an independent controller. Each domain controller periodically exchanges intra-domain status information to construct a global network view and realize global route planning. At the same time, the route decision is handled by the local controller, thereby reducing the control plane response time.

[0040] However, the cross-domain routing scheme based on centralized control still has the following drawbacks: (1) Each domain controller builds a global view by sharing information between domains. After the topology changes, there is also the problem of slow route convergence or even inconsistency in the global topology of each domain; (2) The privacy of information in each domain will greatly limit the construction of the global view, thus affecting the cross-domain QoS performance; (3) Frequent sharing of information within a domain requires the consumption of network transmission resources.

[0041] The hierarchical routing scheme includes: routers providing their own links and corresponding QoS status to the domain controller, so the domain controller has complete information about the domain network and can then abstract its topology and resource status.

[0042] However, hierarchical routing schemes still have the following drawbacks: (1) The accuracy of their abstract characterization of intra-domain topology and QoS information will directly affect QoS performance and service carrying capacity. For example, in the abstraction process, using "shortest path" or "multiple paths" to describe the routing relationship between two nodes cannot fully describe all the routing possibilities between them. However, if the characterization is detailed, it will lead to excessive information reporting and consume additional transmission resources; (2) The accuracy and timeliness of the link QoS information in each domain virtual topology will affect end-to-end QoS performance.

[0043] To address the aforementioned shortcomings, this invention provides a cross-domain QoS routing method.

[0044] Example 1

[0045] Figure 1 This is a flowchart illustrating a cross-domain QoS routing method provided in Embodiment 1 of the present invention. This method is applicable to cross-domain transmission of service data in packet network scenarios and can be executed by the central controller.

[0046] Figure 2 This is a schematic diagram of a packet network scenario, such as... Figure 2 The network shown consists of multiple autonomous systems, each containing nodes and links. Nodes can include switches and routers. Figure 2 This includes domains A, B, and C. Each domain has its corresponding domain controller, and the master controller can control all domains. For example... Figure 1 As shown, the cross-domain QoS routing method provided in Embodiment 1 of the present invention includes the following steps:

[0047] S110. After receiving a service request sent by a domain controller, multiple candidate paths are determined based on the global virtual topology, which is generated based on the abstraction results obtained by each domain controller from the abstraction of the original domain topology.

[0048] A business request can be understood as a request to transfer business data from the source node to the host node. A business request can carry source node information and destination node information. Business requirements are also sent along with the business request, and these requirements may include latency requirements, jitter requirements, packet loss rate requirements, and bandwidth requirements.

[0049] In this embodiment, the service request first reaches the domain controller. If the domain controller sends the service request and service requirements to the central controller, the central controller can perform coarse planning to select candidate paths. If the domain controller does not send the service request to the central controller, the domain controller can plan the routing path. In this embodiment, the central controller can roughly plan several candidate paths based on the source node information, destination node information, and received service requirements carried in the service request, and based on the global virtual topology. The coarse planning process is not specifically limited here.

[0050] In this embodiment, each domain controller corresponds to an original intra-domain topology. Each domain controller collects all link and resource information within the domain to construct a complete intra-domain topology, i.e., the original intra-domain topology, and abstracts it to obtain an abstract result.

[0051] The abstract result can be the result obtained after abstraction. The abstract result can include the virtual topology within the domain, the average delay and average hop count between boundary nodes, and the propagation delay of the topology between domains.

[0052] In this embodiment, each domain controller can abstract the original intra-domain topology using an autonomous system topology abstraction method based on boundary nodes, average latency, and average hop count. Abstracting the original intra-domain topology hides intra-domain and inter-domain topology information, thus protecting privacy.

[0053] In this embodiment, the central controller can collect the abstract results reported by the domain controllers of each domain, and then construct a global virtual topology based on the abstract results.

[0054] Figure 3 This is a schematic diagram of the global virtual topology in a cross-domain QoS routing method provided in Embodiment 1 of the present invention, as shown below. Figure 3 As shown, the global virtual topology can be composed of multiple intra-domain virtual topologies, including the average latency and average hop count of the link between any two boundary nodes in each intra-domain virtual topology, as well as the propagation latency between any two intra-domain virtual topologies.

[0055] S120. Based on the multiple candidate paths, the index is decomposed to obtain the decomposition result, and the decomposition result is sent as a decomposition requirement to the corresponding multiple domain controllers so that the multiple domain controllers can determine the corresponding target domain path based on the decomposition requirement.

[0056] In this embodiment, the main controller can decompose multiple candidate paths together to obtain the decomposition result of each candidate path. The decomposition result of each candidate path is then sent as a decomposition requirement to the domain controller corresponding to each candidate path. Each corresponding domain controller can plan a path within the domain according to the corresponding decomposition requirement. If all domain controllers corresponding to the candidate path can plan a path within the domain that meets the decomposition requirement, then the planned path within the domain can be used as the target path within the domain. There is no limit to the number of target paths within the domain.

[0057] In this embodiment, the main controller can first decompose a candidate path into indicators to obtain the decomposition result of the candidate path, and send the decomposition result as a decomposition requirement to the domain controller corresponding to the candidate path. If there is a domain controller in the corresponding domain controller that cannot plan an intra-domain path that meets the decomposition requirement, the main controller can decompose the next candidate path into indicators until all domain controllers corresponding to a certain candidate path can plan an intra-domain path that meets the decomposition requirement.

[0058] The domain controllers corresponding to candidate paths can be understood as follows: if a candidate path spans multiple domains, the controllers of multiple domains can be used as the domain controllers corresponding to the candidate path, that is, there can be multiple corresponding domain controllers.

[0059] The decomposition of metrics can be determined based on business requirements. If the business requirements include bandwidth, latency, jitter, and packet loss rate, since bandwidth does not need to be decomposed, the decomposition of metrics can include latency decomposition, jitter decomposition, and packet loss rate decomposition. Correspondingly, the decomposition results can include latency budget, jitter budget, packet loss rate budget, and bandwidth capacity of candidate paths.

[0060] In this embodiment, the central controller decomposes the end-to-end service metrics by domain, enabling each domain controller to independently plan within its domain based on the decomposition results and requirements. This allows for the achievement of ideal end-to-end QoS performance while using only a small amount of domain information.

[0061] S130. Determine the target QoS route based on the path within the target domain.

[0062] In this embodiment, the central controller can concatenate multiple paths within the target domain to obtain a single QoS route as the target QoS route.

[0063] In one embodiment, the central controller concatenates multiple paths within the target domain to obtain a QoS route from the source node to the destination node.

[0064] Furthermore, after S140, the method further includes: the corresponding multiple domain controllers binding the routes of the corresponding domains with service labels, so that after the service data enters the network, the data is forwarded according to the routes corresponding to the service labels;

[0065] The service tag is assigned to a service by the central controller after receiving a service request from the domain controller. The service tag is used to identify service data and can be carried in the service packet header.

[0066] The first embodiment of this invention provides a cross-domain QoS routing method. First, after receiving a service request from a domain controller, multiple candidate paths are determined based on a global virtual topology. This global virtual topology is generated based on the abstraction results obtained by each domain controller abstracting the original intra-domain topology. Then, based on the multiple candidate paths, index decomposition is performed to obtain decomposition results. These decomposition results are then sent as decomposition requirements to the corresponding multiple domain controllers, enabling them to determine the corresponding target intra-domain path based on the decomposition requirements. Finally, a target QoS route is determined based on the target intra-domain path.

[0067] The above method has the following advantages: 1. Compared with "protocol-based cross-domain routing", it has centralized routing characteristics, which can effectively overcome the problem of slow route convergence; the routes of each domain are controllable, which strengthens the end-to-end QoS performance guarantee; there is no need to continuously synchronize the information of each domain, only the virtual topology needs to be reported once when initially joining the network or when the topology changes; 2. Compared with "cross-domain routing based on centralized control", this scheme can obtain ideal end-to-end QoS performance while using very little intra-domain information, and there is no need to continuously synchronize the information of each domain, thus reducing the consumption of transmission resources; 3. Compared with traditional "hierarchical routing", it introduces the intra-domain description method of "average latency and hop count", combined with the independent planning characteristics of each domain, which improves the possibility of intra-domain route selection; it does not rely on path state information, thus avoiding QoS performance degradation caused by "inaccurate" information.

[0068] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0069] In one embodiment, the abstraction result includes the intra-domain virtual topology, average latency, average hop count, and propagation latency; correspondingly, the abstraction result is obtained by abstracting the original intra-domain topology based on each domain controller, including:

[0070] For each domain controller, the original domain topology is abstracted into a virtual domain topology composed of boundary nodes, and the boundary nodes are fully connected to the outside world.

[0071] Average latency and average hop count are obtained by performing domain abstraction through the domain controller;

[0072] Propagation latency is obtained by performing inter-domain abstraction through the domain controller.

[0073] Each control domain abstracts its corresponding original domain topology into a virtual topology composed of boundary nodes. The boundary nodes are fully connected to the outside world, that is, they are connected through virtual links. Figure 4 This is a schematic diagram of the topology abstraction process in a cross-domain QoS routing method provided in an embodiment of the present invention, as shown below. Figure 4 The original domain topology is abstracted to obtain a virtual topology composed of boundary node 1, boundary node 2 and boundary node 3. Boundary node 1, boundary node 2 and boundary node 3 are connected to other domains externally, presenting a fully connected state.

[0074] In this context, multiple intra-domain paths can exist between any two boundary nodes, allowing them to communicate with each other. These intra-domain paths are ultimately abstracted into a virtual link, with different intra-domain paths containing varying numbers of hops. Each hop can be understood as traversing a physical link. Average latency can be understood as the average latency of all intra-domain paths between any two boundary nodes, while path latency can be understood as the transmission latency of data along the path. Average hop count can be understood as the average number of hops experienced between any two boundary nodes.

[0075] In this system, any two boundary points of different domains are connected by a direct link, and the propagation delay can be the transmission delay of the direct link.

[0076] Specifically, the intra-domain abstraction includes: obtaining all intra-domain paths that have undergone at least one hop between any two boundary nodes and the latency of each intra-domain path through the domain controller; calculating the average latency and average number of hops of all intra-domain paths; and abstracting the original topology into the intra-domain virtual topology composed of boundary nodes, with the boundary nodes interconnected by virtual links and presenting a fully connected state to the outside world.

[0077] This involves enumerating all intra-domain paths and their delays between any two boundary nodes (i,j) that traverse n hops, using a set... Represents (n∈[1,N-1], where N is the total number of nodes in the domain), only inherent delays are counted, such as node lookup processing delays and link transmission delays. Queuing delays are not considered here. L n The number of elements in the middle does not exceed Calculate the average delay of all intra-domain paths. and average number of jumps

[0078] For example, suppose there are four intra-domain paths between the source and destination nodes: L 1hop ={1ms}, L 2hops ={2ms, 2ms}, L 3hops ={3ms}, then the average latency Average number of jumps

[0079]

[0080] Specifically, the inter-domain abstraction includes: connecting the boundary nodes of different domains through direct links via domain controllers, and using the direct link delay as the propagation delay.

[0081] In this case, if we consider direct physical links between domains, the inter-domain topology is represented as a direct link between boundary nodes of different domains, and the transmission delay of the link is used as the propagation delay between two boundary nodes.

[0082] In one embodiment, before receiving a service request from a domain controller, the method further includes: determining, through the domain controller, whether to report the service request to the central controller;

[0083] Specifically, after the domain controller receives a service request, it determines whether the destination node is in the domain based on the destination node information carried in the service request; if not, the domain controller reports the service request.

[0084] like Figure 2 As shown, the domain controller can determine the domain to which the source node belongs, i.e., domain A, based on the source node information, and determine the domain to which the destination node belongs, i.e., domain C, based on the destination node information. Since the source node and the destination node do not belong to the same domain, the master controller is needed to plan the routing path. Therefore, domain controller A can send the service request to the master controller.

[0085] In one embodiment, the step of planning based on the global virtual topology to determine multiple candidate paths includes: using all average latency and all propagation latency in the global virtual topology as weights, and using a preset algorithm to calculate multiple cross-domain paths connecting the source node and the destination node as candidate paths.

[0086] The path latency of each candidate path shall not exceed the latency requirement in the business requirements, and the source node and destination node shall be determined based on the source node information and destination node information carried in the business request.

[0087] In this embodiment, using the average latency of links in each domain virtual topology within the global virtual topology and the propagation latency of directly connected links included in the global virtual topology as weights, the K-shortest path algorithm can be used to select K cross-domain paths connecting the source host node, and the path latency of each candidate path does not exceed the latency requirement in the service requirements.

[0088] In one embodiment, decomposing the indicators based on the multiple candidate paths includes: arranging the multiple candidate paths according to the path delay of each candidate path; starting from the candidate path with the shortest path delay, decomposing the indicators of each of the multiple candidate paths one by one according to the arrangement order.

[0089] When arranging multiple candidate paths, they can be sorted in ascending order based on their corresponding time delay, or in descending order based on their corresponding time delay; no specific restrictions apply here.

[0090] Specifically, a candidate path is decomposed into indicators, and the decomposition requirements are sent to multiple domain controllers corresponding to the candidate path. If one of the multiple domain controllers cannot determine the target intra-domain path according to the decomposition requirements, the indicator decomposition continues for the next candidate path until all domain controllers corresponding to a candidate path can determine the corresponding target intra-domain path according to the decomposition requirements.

[0091] The target domain path can be a domain path that meets the decomposition requirements. If the corresponding domain controller cannot determine the target domain path based on the decomposition requirements, it can be understood as if the corresponding domain controller cannot plan a domain path that meets the decomposition requirements.

[0092] Preferably, the central controller can select the next candidate path based on the load of each domain, avoiding the problem of excessive computation caused by selecting all candidate paths in sequence, and can accelerate the solution of feasible candidate paths.

[0093] Each domain controller can report its domain's load status to the central controller, so that when selecting the next candidate path, the central controller can select a candidate path that passes through an idle domain based on the load status of each domain, thereby avoiding the selection of every candidate path.

[0094] It should be noted that the index decomposition includes one or more of latency decomposition, jitter decomposition, and packet loss decomposition; the decomposition results include one or more of latency budget, jitter budget, packet loss rate budget, and bandwidth capacity of candidate paths.

[0095] Furthermore, the index decomposition includes time delay decomposition, and the decomposition result includes time delay budget;

[0096] For a candidate path that passes through multiple domains, the latency of the candidate path is decomposed to obtain the latency budget for each domain. The candidate path consists of target virtual links within multiple domains and target direct links between domains. The latency budget for each domain is calculated using a first formula based on the average hop count of the target virtual links within each domain, the average latency of the target virtual links within each domain, the propagation latency of the target direct links between domains, and the latency requirements included in the service requirements.

[0097] The target virtual link can be a virtual link that the candidate path passes through within the domain, and the target direct link can be a direct link that the candidate path passes through between domains.

[0098] Furthermore, a candidate path passes through M domains, and the i-th domain contains i... k There are boundary nodes, and the boundary node pair (i) s i dThe path between () is the target virtual link within the i-th domain; correspondingly, the first formula is as follows:

[0099]

[0100] in, L represents the latency requirement, L j,j+1 L represents the propagation delay of the direct link between the j-th domain and the (j+1)-th domain. i L represents the latency budget for the i-th domain. j This represents the delay budget for the j-th domain. This represents the average latency of the target virtual link within the j-th domain. This represents the average latency of the target virtual link within the i-th domain. This represents the average hop count of the target virtual link within the i-th domain. This represents the average number of hops for the target virtual link within the j-th domain.

[0101] Figure 5 This is a schematic diagram of delay decomposition in a cross-domain QoS routing method provided in an embodiment of the present invention, as shown below. Figure 5 As shown, candidate path k passes through M autonomous systems, and m exists within the m-th autonomous system. k There are boundary nodes, and node pairs (m s ,m d The average latency and hop count are respectively and

[0102] Latency is an additive metric, meaning the total end-to-end latency equals the sum of the intra-domain and inter-domain latency: L = L 1 +L 1,2 +L 2 +……+L M Since the propagation delay between domains is known, the undetermined part in the above formula represents the intra-domain delay, specifically the queuing delay of nodes within the domain. Therefore, the queuing delay budget can be expressed as the end-to-end delay minus the propagation delay of the target direct link and the average delay of the target virtual link within the domain: The uncertainty of intra-domain latency mainly stems from queuing within nodes, and generally, the more hops there are, the longer the queuing latency will be. Therefore, if we assume that the intra-domain latency budget is proportional to the number of hops, then the latency budget for domain i is: in The "+1" indicates that the latency budget for each domain is included in the entry node of that domain. The latency budget for each domain can be obtained by decomposing the above formula.

[0103] For example, suppose the candidate path spans 3 domains, and the average number of hops in each domain is as follows: The average inherent delay of each domain are as follows: Inter-domain link latency is L 1,2 =2ms, L 2,3 =3ms; the end-to-end latency requirement for the business is 50ms; therefore, the latency budgets for each domain are as follows:

[0104] Furthermore, the index decomposition includes jitter decomposition, and the decomposition result includes jitter budget; for a candidate path, if the candidate path passes through multiple domains, then the jitter decomposition of the candidate path is performed to obtain the jitter budget, and the candidate path includes target virtual links in multiple domains.

[0105] Specifically, the jitter budget for each domain is calculated using the average number of hops of the target virtual links within each domain and the jitter requirements included in the business needs, through the second formula.

[0106] Furthermore, a candidate path passes through M domains, and the i-th domain contains i... k There are boundary nodes, and the boundary node pair (i) s i d The virtual link between ) is the target virtual link within the i-th domain; correspondingly, the second formula is as follows:

[0107]

[0108] Where J represents the jitter requirement, J i This represents the jitter budget for the i-th domain. This represents the average hop count of the target virtual link within the j-th domain. This represents the average number of hops for the target virtual link within the i-th domain.

[0109] Figure 6 This is a schematic diagram of jitter decomposition in a cross-domain QoS routing method provided in an embodiment of the present invention, as shown below. Figure 6 As shown, jitter is an additive metric, meaning the end-to-end jitter equals the sum of the jitter across all domains. Unlike latency, jitter only occurs within a node; there is no jitter on the physical link. Jitter characterizes the range of variation in node queuing latency, and generally, the higher the number of hops, the greater the range of latency variation. Therefore, if we let the intra-domain jitter budget be proportional to the number of hops, then the jitter budget for domain i is:

[0110] For example, suppose the candidate path spans 3 domains, and the average number of hops in each domain is as follows: If the end-to-end jitter requirement for the business is 6ms, then the jitter budget for each domain is as follows:

[0111]

[0112] Furthermore, the index decomposition includes packet loss decomposition, and the decomposition result includes packet loss rate budget; for a candidate path, if the candidate path passes through multiple domains, then the packet loss decomposition of the candidate path is performed to obtain the packet loss rate budget of each domain, and the candidate path includes target virtual links in multiple domains.

[0113] Specifically, a third formula is constructed based on the average number of hops of the target virtual links within each domain. The packet loss rate budget for a domain is obtained by solving the third formula. The packet loss rate budget for the first domain is then used to solve the packet loss rate budget for the other domains using a fourth formula.

[0114] Furthermore, a candidate path passes through M domains, and the i-th domain contains i... k There are boundary nodes, and the boundary node pair (i) s i d The virtual link between ) is the target virtual link within the i-th domain; correspondingly, the third formula is constructed based on the average hop count of the target virtual links within each domain as follows:

[0115]

[0116] in, This represents the average hop count of the target virtual link within the i-th domain. D represents the average hop count of the target virtual link within the j-th domain. i Let represent the packet loss rate budget for the i-th domain, and D represent the packet loss rate requirement.

[0117] The fourth formula is as follows:

[0118]

[0119] Among them, D j This represents the packet loss rate estimate for the j-th domain.

[0120] Figure 7 This is a schematic diagram of packet loss decomposition in a cross-domain QoS routing method provided in an embodiment of the present invention, as shown below. Figure 7 As shown, packet loss is a multiplicative metric, meaning the end-to-end packet loss rate equals "1" minus the product of no packet loss in each domain: D = 1 - (1 - D) 1 (1-D) 2 )……(1-D M Assuming good link transmission quality, the probability of packet loss due to transmission errors is extremely low; therefore, packet loss mainly originates from node queues. If we assume that the packet loss rate of each domain is proportional to the number of hops, then... achievable The above formula is about D i It can be seen that when D iWhen the degree is higher than 5 (meaning the number of domains is not less than 5), there is no general formula for finding the root of the equation. Here, Newton's tangent method can be used iteratively to find an approximate root. The iterative steps are as follows:

[0121]

[0122] Where |y| represents the absolute value of y, and ε is a number approaching 0 (which can be set according to the solution precision, such as 10). -5 10 -7 (etc.), "y<0" requires that the function value f(x) corresponding to the obtained solution x is greater than 0, thus constraining the end-to-end packet loss rate to not exceed the packet loss rate requirement D. D is obtained through the above steps. i Then the packet loss rate estimate for other domains j is:

[0123] Furthermore, the decomposition results include the bandwidth capacity of the candidate paths, which is characterized by the minimum bandwidth of all links on the candidate paths, and the minimum bandwidth is greater than or equal to the bandwidth requirement in the service requirements.

[0124] In this context, bandwidth does not require decomposition; bandwidth is a "concave" metric, meaning that the bandwidth capacity of a path is characterized by the minimum bandwidth of all links on it. Link (i,j) belongs to path p. Therefore, in order to meet the end-to-end bandwidth requirement B, which is the bandwidth requirement included in the service requirements, the available bandwidth capacity of each domain link must not be less than B.

[0125] In one embodiment, the corresponding domain controller determines the corresponding intra-domain path based on the decomposition result, including:

[0126] For a given domain controller, the domain controller uses a QoS routing algorithm to plan an intra-domain path that meets the decomposition requirements as the target intra-domain path. The decomposition requirements include one or more of the following: latency budget, jitter budget, packet loss rate budget, and bandwidth capacity.

[0127] The QoS routing algorithm can be any intra-domain QoS routing algorithm, and there are no restrictions on the specific content of the QoS routing algorithm here.

[0128] In this embodiment, each domain controller can use a QoS routing algorithm to plan an intra-domain path that meets the latency budget, jitter budget, packet loss rate budget, and bandwidth capacity requirements as the target intra-domain path. It should be noted that different domain controllers plan target intra-domain paths that meet different decomposition requirements.

[0129] Example 2

[0130] Based on the technical solutions of the above embodiments, this invention provides several specific implementation methods.

[0131] As one specific implementation method of this embodiment. Figure 8 This is a flowchart of a cross-domain QoS routing method provided in Embodiment 2 of the present invention, as shown below. Figure 8 As shown, it includes the following steps:

[0132] Step 1: Each domain controller abstracts the topology and calculates the abstract results, including average latency and average hop count, and reports them to the central controller; the central controller collects the virtual topologies of each domain and generates a global virtual topology.

[0133] Step 2.1: The domain controller determines whether the destination node of the service is in this domain. If so, the domain controller plans the routing path; if not, the domain controller reports the service request to the central controller. The central controller performs coarse planning based on the virtual topology and selects K candidate paths.

[0134] Step 2.2: Decompose the k-th candidate path into metrics such as latency, packet loss, and jitter.

[0135] Step 3: The central controller distributes the decomposition results to each domain controller; each domain controller performs intra-domain planning according to the decomposition requirements.

[0136] The decomposition result received by domain i is (B,L) i J i D i Based on this, domain i uses the intra-domain QoS routing algorithm to plan an intra-domain path that meets the requirements.

[0137] Step 4: Determine whether the route planning for each domain is successful. If the planning fails, repeat steps 2.1 and 3 until each domain can plan its own route.

[0138] Step 5: Concatenate the paths from each domain to obtain the end-to-end QoS path, and bind it to the service tag.

[0139] In this process, the paths from each domain are concatenated to form an end-to-end QoS route, and each domain binds its routing result to a service label. When service data enters the network, the service label is identified and forwarded according to the corresponding route.

[0140] As another specific implementation of this method, firstly, the topology and resource status within the domain are abstracted and reported to the central controller to construct a global virtual topology view. Secondly, when a service request arrives and is reported to the central controller, the central controller assigns a global label to the service. This global label is used to identify the service and is carried in the service packet header. Subsequently, based on the link latency in the global virtual topology view, K candidate paths from the source domain to the destination domain are selected. Based on the cross-domain nature of the candidate paths, the service metrics are decomposed domain by domain. Then, the decomposed service metrics are transmitted to each domain controller, and QoS paths that meet the decomposition requirements are planned within the domain accordingly. The specific steps are described below:

[0141] Step 1: Domain Topology Abstraction. First, to hide the domain topology information, the original topology is abstracted into a virtual topology composed of boundary nodes, with the boundary nodes presenting a fully connected state to the outside world. (1) Domain Abstraction: Enumerate all paths and their delays between any two boundary nodes (i,j) that take n hops, and use the set Represents (n∈[1,N-1], where N is the total number of nodes in the domain), where only inherent delays are counted (node ​​lookup and other processing delays, and link transmission delays; queuing delays are not considered for now), L n The number of elements in the middle does not exceed Then, the average delay of all paths is calculated. and average number of jumps (2) Inter-domain: Considering that inter-domains are directly connected by physical links, the inter-domain topology is represented as the direct link between boundary nodes of different domains, and the link delay is its propagation delay. Finally, the virtual topology within the domain, the average delay and average hop count between boundary nodes, and the inter-domain topology delay are reported to the central controller.

[0142] Step 2: When a service request (bandwidth B, latency L, jitter J, packet loss rate D) arrives, if the domain controller finds that the destination is not in its domain, it will report the request to the central controller. The central controller assigns a global label to the service and then performs the following operations: First, using the average latency of the links in the virtual topology (including the average latency between boundary nodes and the inter-domain propagation latency) as the weight, the K-shortest path algorithm is used to select K cross-domain paths connecting the source and destination nodes, and the latency of each path does not exceed the service latency requirement L. Second, the K paths are sorted in ascending order of path latency value, and then the candidate paths are decomposed into indicators one by one. The decomposition results are sent to each domain controller, and each domain controller performs precise intra-domain path planning to find intra-domain QoS paths that meet the decomposition requirements.

[0143] Step 3: The central controller sends the index decomposition results to each domain controller. The decomposition result received by domain i is (B,Li,Ji,Di). Based on this, domain i uses the QoS routing algorithm to plan an intra-domain path that meets the requirements.

[0144] Step 4: If domain i cannot be programmed to satisfy (B,L) i J i D i If the required path is found, feedback is sent to the central controller, which selects the next candidate path k+1. Steps 2 and 3 are repeated until each domain can plan its own route, which supports policy rollback.

[0145] Step 5: The paths from each domain are concatenated to obtain an end-to-end QoS route. Each domain binds its routing result to the service label. When service data enters the network, the service label is identified and forwarded according to the corresponding route.

[0146] The second embodiment of this invention provides a cross-domain QoS routing method that can hide intra-domain information through intra-domain topology abstraction, which is beneficial to privacy protection. By using cross-domain coarse planning based on average latency and fine planning for each domain based on index decomposition, as well as end-to-end latency, jitter, and packet loss decomposition methods based on average hop count, each domain can perform independent intra-domain planning according to the decomposed indexes, which can achieve ideal end-to-end QoS performance while using a small amount of intra-domain information.

[0147] Example 3

[0148] Figure 9 This is a schematic diagram of a cross-domain QoS routing device provided in Embodiment 3 of the present invention. The device is applicable to cross-domain transmission of service data in packet network scenarios. The device can be implemented by software and / or hardware and is generally integrated on the main controller.

[0149] like Figure 9 As shown, the device includes: a candidate path determination module 110, a decomposition module 120, and a target QoS route determination module 130.

[0150] The candidate path determination module 110 is used to determine multiple candidate paths based on the global virtual topology after receiving a service request sent by the domain controller. The global virtual topology is generated based on the abstraction result obtained by each domain controller abstracting the original domain topology.

[0151] The decomposition module 120 is used to perform index decomposition based on the multiple candidate paths to obtain decomposition results, and to send the decomposition results as decomposition requirements to the corresponding multiple domain controllers so that the multiple domain controllers can determine the corresponding target domain path based on the decomposition requirements.

[0152] The target QoS route determination module 130 is used to determine the target QoS route based on the path within the target domain.

[0153] This invention provides a cross-domain QoS routing device that can achieve efficient end-to-end QoS performance assurance while using a small amount of intra-domain information.

[0154] The aforementioned cross-domain QoS routing device can execute the cross-domain QoS routing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0155] Example 4

[0156] Figure 10 A schematic diagram of a central controller 10, which can be used to implement embodiments of the present invention, is shown. The central controller is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The central controller can also represent various forms of mobile devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0157] like Figure 10 As shown, the main controller 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the main controller 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0158] Multiple components in the main controller 10 are connected to the I / O interface 15, including: input units 16, such as a keyboard, mouse, etc.; output units 17, such as various types of displays, speakers, etc.; storage units 18, such as disks, optical disks, etc.; and communication units 19, such as network interface cards, modems, wireless transceivers, etc. The communication unit 19 allows the main controller 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0159] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as cross-domain QoS routing methods.

[0160] In some embodiments, the cross-domain QoS routing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the main controller 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the cross-domain QoS routing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the cross-domain QoS routing method by any other suitable means (e.g., by means of firmware).

[0161] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0162] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0163] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0164] To provide user interaction, the systems and techniques described herein can be implemented on a central controller having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the central controller. Other types of devices can also be used to provide user interaction; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0165] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0166] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0167] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0168] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A cross-domain QoS routing method, characterized by, The method comprises: After receiving the service request sent by the domain controller, a plurality of candidate paths are determined based on a global virtual topology, the global virtual topology being generated based on abstracted results obtained by performing original intra-domain topology abstraction, intra-domain abstraction and inter-domain abstraction on each domain controller; The plurality of candidate paths are arranged according to path latency of each candidate path, starting from the candidate path with the shortest path latency, a candidate path is subjected to index decomposition to obtain a decomposition result, and the decomposition result is sent to a plurality of domain controllers corresponding to the candidate path as a decomposition requirement, if there is a domain controller in the plurality of domain controllers that cannot determine a target intra-domain path according to the decomposition requirement, the next candidate path is subjected to index decomposition, until all domain controllers corresponding to a candidate path can determine the corresponding target intra-domain path according to the decomposition requirement; A target QoS route is determined according to the target intra-domain path.

2. The method of claim 1, wherein, The abstracted results comprise an intra-domain virtual topology, average latency, average hop count and propagation latency, and correspondingly, the abstracted results obtained by performing abstraction on the original intra-domain topology by each domain controller comprise: For each domain controller, the original intra-domain topology is abstracted by the domain controller into an intra-domain virtual topology composed of boundary nodes, and the boundary nodes are in a full connection state with each other; The average latency and the average hop count are obtained by performing intra-domain abstraction by the domain controller; The propagation latency is obtained by performing inter-domain abstraction by the domain controller.

3. The method of claim 2, wherein: The intra-domain abstraction comprises: obtaining, by the domain controller, all intra-domain paths experienced by any two boundary nodes through at least one hop and the latency of each intra-domain path, and calculating the average latency and the average hop count of all intra-domain paths; and abstracting the original topology into the intra-domain virtual topology composed of the boundary nodes, the boundary nodes being interconnected by virtual links and being in a full connection state with each other; The inter-domain abstraction comprises: connecting the boundary nodes of different domains through a direct link by the domain controller, and taking the latency of the direct link as the propagation latency.

4. The method of claim 1, wherein, Before receiving the service request sent by the domain controller, the method further comprises: Determining, by the domain controller, whether to report the service request to a total controller: Wherein, after receiving the service request by the domain controller, determining, by the domain controller, whether the sink node is in the domain according to sink node information carried by the service request; if not, reporting the service request to the total controller by the domain controller.

5. The method of claim 2, wherein, The determination of the plurality of candidate paths based on the global virtual topology comprises: Taking all average latencies and all propagation latencies in the global virtual topology as weights, and using a preset algorithm to calculate a plurality of cross-domain paths connecting the source node and the sink node as candidate paths; Wherein, the path latency of each candidate path does not exceed the latency requirement in the service requirement, and the source node and the sink node are determined according to the source node information and the sink node information carried in the service request.

6. The method of claim 3, wherein, The index decomposition comprises latency decomposition, and the decomposition result comprises latency budget. For a candidate path passing through multiple domains, a delay budget of each domain is obtained by delay decomposition of the candidate path, the candidate path being composed of target virtual links in the multiple domains and target direct links between the domains; The delay budget of each domain is calculated by a first formula based on the average hop count of the target virtual links in each domain, the average delay of the target virtual links in each domain, the propagation delay of the target direct links between the domains, and the delay requirement included in the service requirement.

7. The method of claim 6, wherein, A candidate path passes through M domains, and there are k boundary nodes i in the ith domain k , the path between the boundary node pair (i s , i d ) is the target virtual link in the ith domain, 1<s<k, 1<d<k; accordingly, the first formula is as follows: wherein, L denotes latency requirement, L j,j+1 denotes the propagation latency of the target direct link between the jth domain and the (j+1)th domain, L i denotes the latency budget of the ith domain, L j denotes the latency budget of the jth domain, denotes the average latency of the target virtual link within the jth domain, denotes the average latency of the target virtual link within the ith domain, denotes the average hop count of the target virtual link within the ith domain, denotes the average hop count of the target virtual link within the jth domain.

8. The method of claim 3, wherein, The index decomposition includes jitter decomposition, and the decomposition result includes a jitter budget; For a candidate path passing through multiple domains, a jitter budget is obtained by jitter decomposition of the candidate path, the candidate path including target virtual links in the multiple domains; The jitter budget of each domain is calculated by a second formula based on the average hop count of the target virtual links in each domain and the jitter requirement included in the service requirement.

9. The method of claim 8, wherein, A candidate path passes through M domains, and there are k boundary nodes i in the ith domain k , the virtual link between the boundary node pair (i s ,i d ) is the target virtual link in the ith domain, 1 k , the virtual link between the boundary node pair (i s ,i d ) is the target virtual link in the ith domain, 1 k , the virtual link between the boundary node pair (i s ,i d ) is the target virtual link in the ith domain, 1 wherein J represents a jitter requirement, J i represents a jitter budget of the i-th domain, represents an average hop count of the target virtual link within the j-th domain, represents an average hop count of the target virtual link within the i-th domain.

10. The method of claim 3, wherein, The index decomposition includes packet loss decomposition, and the decomposition result includes a packet loss rate budget; For a candidate path passing through multiple domains, a packet loss rate budget of each domain is obtained by packet loss decomposition of the candidate path, the candidate path including target virtual links in the multiple domains; A third formula is constructed based on the average hop count of the target virtual links in each domain, and a packet loss rate budget of one domain is obtained by solving the third formula, and packet loss rate budgets of other domains are obtained by solving a fourth formula based on the packet loss rate budget of the one domain.

11. The method of claim 10, wherein, A candidate path passes through M domains, and there are k boundary nodes i in the ith domain k The virtual link between the boundary node pair (i s , i d ) is the target virtual link in the ith domain, 1 < s < k, 1 < d < k; accordingly, the third formula based on the average number of hops of the target virtual link in each domain is constructed as follows: wherein, denotes the average hop count of the i-th inter-domain target virtual link, denotes the average hop count of the j-th inter-domain target virtual link, D i denotes the packet loss rate budget of the i-th domain, D denotes the packet loss rate requirement; The fourth formula is as follows: where D j denotes the packet loss budget of the jth domain.

12. The method of claim 1, wherein, The decomposition result includes a bandwidth capacity of the candidate path, the bandwidth capacity being represented by a minimum bandwidth of all links on the candidate path, the minimum bandwidth being greater than or equal to a bandwidth requirement in the service requirement.

13. A cross-domain QoS routing apparatus, characterized by, The apparatus includes: A candidate path determination module configured to determine multiple candidate paths based on a global virtual topology after receiving a service request sent by a domain controller, the global virtual topology being generated based on an abstract result obtained by performing original intra-domain topology abstraction, intra-domain abstraction, and inter-domain abstraction on each domain controller; A decomposition module configured to arrange the multiple candidate paths according to path delays of each candidate path, to perform index decomposition on a candidate path to obtain a decomposition result from a candidate path with the shortest path delay, and to send the decomposition result as a decomposition requirement to multiple domain controllers corresponding to the candidate path, and to continue to perform index decomposition on a next candidate path if a domain controller in the multiple domain controllers cannot determine a target intra-domain path according to the decomposition requirement, until all domain controllers corresponding to a candidate path can determine corresponding target intra-domain paths according to the decomposition requirement; A target QoS route determination module configured to determine a target QoS route based on the target intra-domain paths.

14. A master controller, comprising: The total controller includes: At least one processor; and A memory connected in communication with the at least one processor; wherein The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the cross-domain QoS routing method in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling the processor to implement the cross-domain QoS routing method in any one of claims 1-12 when executed.

Images