Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method comprising: retrieving, for a cloud computing service, a request graph specifying request nodes identifying respective requested cloud computing service operations, and at least one request edge specifying a requested path requirements connecting the request nodes; identifying a placement pivot from among feasible cloud elements identified in a physical graph representing a data network having a physical topology, each feasible cloud element an available solution for one of the request nodes, the placement pivot having a maximum depth in the physical topology relative to the feasible cloud elements; ordering the feasible cloud elements, within candidate sets of feasible cloud elements identified as available solutions for the at least one request edge, according to increasing distance from the placement pivot to form an ordered list of candidate sets of feasible cloud elements; and determining an optimum candidate set, from at least a portion of the ordered list, based on the optimum candidate set having an optimized fitness function in the physical graph from among the other candidate sets in the ordered list.
A method for cloud resource placement involves these steps: First, a request graph is retrieved. This graph specifies requested cloud services (compute, storage, networking) as request nodes and their path requirements as request edges. Second, a placement pivot is identified from available cloud elements. This pivot is a cloud element with the maximum depth in the physical network topology relative to other feasible cloud elements. Each feasible cloud element is an available solution for one of the requested cloud services. Third, the feasible cloud elements are ordered within candidate sets based on increasing distance from the placement pivot. Fourth, an optimal candidate set is determined based on having an optimized fitness function in the physical graph.
2. The method of claim 1 , wherein the identifying further includes identifying the placement pivot as having a maximum available link bandwidth relative to other feasible cloud elements having the same maximum depth.
The method described above (retrieving a request graph, identifying a placement pivot, ordering the feasible cloud elements and determining an optimal candidate set), identifies the placement pivot based not only on maximum depth in the physical topology relative to other feasible cloud elements, but also on having the maximum available link bandwidth compared to other feasible cloud elements with the same maximum depth. Therefore, if multiple feasible cloud elements are at the same maximum depth, the one with the highest available bandwidth is chosen as the placement pivot.
3. The method of claim 1 , wherein the request graph includes customer request nodes specifying respective customer-requested cloud computing service operations, and at least one service provider-based request node representing a service provider policy implemented in the physical graph, and at least one request edge connecting the request nodes.
The method described above (retrieving a request graph, identifying a placement pivot, ordering the feasible cloud elements and determining an optimal candidate set) uses a request graph that includes customer request nodes specifying customer requested cloud computing service operations, at least one service provider-based request node representing a service provider policy implemented in the physical graph, and at least one request edge connecting the request nodes. So the request graph incorporates both customer needs and service provider policies.
4. The method of claim 1 , wherein each feasible cloud element is determined as an available solution for the corresponding one request node based on the request node specifying service requirements on at least one prescribed attribute type.
The method described above (retrieving a request graph, identifying a placement pivot, ordering the feasible cloud elements and determining an optimal candidate set) determines that each feasible cloud element is an available solution for its corresponding request node based on the request node specifying service requirements related to at least one prescribed attribute type. This means the available cloud element must meet the requirements specified by the requesting node to be considered a feasible solution.
5. The method of claim 4 , wherein the prescribed attribute type includes at least one of processor type, virtual data center service type, or network service type.
In the method described above where each feasible cloud element is determined as an available solution for its corresponding request node based on service requirements related to at least one prescribed attribute type, the prescribed attribute type includes at least one of processor type, virtual data center service type, or network service type. Therefore, the service requirements can specify particular processor types, virtual data center service types or network service types to be considered a feasible solution.
6. The method of claim 1 , wherein the physical graph represents a service provider deployment of the data network according to service provider-based constraints and policies.
In the method described above (retrieving a request graph, identifying a placement pivot, ordering the feasible cloud elements and determining an optimal candidate set), the physical graph that represents a data network having a physical topology represents a service provider deployment of the data network according to service provider-based constraints and policies. In other words, the physical graph reflects the actual network infrastructure as deployed and managed by the service provider, incorporating their specific constraints and policies.
7. The method of claim 6 , further comprising determining the candidate sets of feasible cloud elements for the at least one request edge based on: identifying, among the feasible cloud elements relative to the physical graph, sets of possible solutions for feasible cloud elements based on identifying respective paths in the physical graph connecting the associated feasible cloud elements; filtering the sets of possible solutions based on the service provider-based constraints and policies.
The method described above (retrieving a request graph, identifying a placement pivot, ordering the feasible cloud elements and determining an optimal candidate set), determines candidate sets of feasible cloud elements for each request edge by: identifying possible solutions for feasible cloud elements based on identifying paths in the physical graph connecting the associated feasible cloud elements and filtering those sets of possible solutions based on service provider constraints and policies. This involves finding possible paths between feasible cloud elements and then eliminating paths that violate service provider rules.
8. The method of claim 7 , wherein: the service provider-based constraints and policies include at least one of a bandwidth constraint limiting bandwidth consumption on at least one of the feasible cloud elements, or an overlay constraint limiting traversal of network traffic from one of the request nodes to a second of the request nodes; the optimum candidate set heuristically determined to provide a sequence of physical network nodes implementing the request graph in the physical topology and that minimizes consumption of bandwidth in the physical topology.
In the method described above where candidate sets of feasible cloud elements are determined for each request edge based on service provider constraints and policies, the service provider constraints and policies include at least one of a bandwidth constraint (limiting bandwidth consumption on feasible cloud elements) or an overlay constraint (limiting traversal of network traffic from one request node to another). The optimum candidate set is heuristically determined to provide a sequence of physical network nodes implementing the request graph in the physical topology that minimizes consumption of bandwidth in the physical topology.
9. The method of claim 1 , wherein the requested cloud computing service operations include at least one of compute, storage, or networking services.
In the method described above (retrieving a request graph, identifying a placement pivot, ordering the feasible cloud elements and determining an optimal candidate set), the requested cloud computing service operations include at least one of compute, storage, or networking services. This means that the request nodes within the request graph can represent requests for compute resources, storage capacity, network connectivity or a combination of these.
10. An apparatus comprising: a memory circuit configured for storing a request graph for a cloud computing service, the request graph specifying request nodes identifying respective requested cloud computing service operations, and at least one request edge specifying a requested path requirements connecting the request nodes; and a processor circuit configured for: identifying a placement pivot from among feasible cloud elements identified in a physical graph representing a data network having a physical topology, each feasible cloud element an available solution for one of the request nodes, the placement pivot having a maximum depth in the physical topology relative to the feasible cloud elements, ordering the feasible cloud elements, within candidate sets of feasible cloud elements identified as available solutions for the at least one request edge, according to increasing distance from the placement pivot to form an ordered list of candidate sets of feasible cloud elements, and determining an optimum candidate set, from at least a portion of the ordered list, based on the optimum candidate set having an optimized fitness function in the physical graph from among the other candidate sets in the ordered list.
An apparatus for cloud resource placement includes a memory circuit and a processor circuit. The memory stores a request graph for a cloud computing service, specifying requested services (compute, storage, networking) as request nodes and path requirements as request edges. The processor identifies a placement pivot from available cloud elements, prioritizing those with maximum depth in the physical network topology. The processor then orders feasible cloud elements within candidate sets based on increasing distance from the placement pivot and selects an optimal candidate set based on an optimized fitness function in the physical graph.
11. The apparatus of claim 10 , wherein the processor circuit is configured for identifying the placement pivot as having a maximum available link bandwidth relative to other feasible cloud elements having the same maximum depth.
The apparatus described above (memory storing the request graph and a processor configured to identify a placement pivot and order feasible cloud elements), configures the processor to identify the placement pivot based not only on maximum depth in the physical topology relative to other feasible cloud elements, but also on having the maximum available link bandwidth compared to other feasible cloud elements with the same maximum depth. Therefore, if multiple feasible cloud elements are at the same maximum depth, the one with the highest available bandwidth is chosen as the placement pivot.
12. The apparatus of claim 10 , wherein the request graph includes customer request nodes specifying respective customer-requested cloud computing service operations, and at least one service provider-based request node representing a service provider policy implemented in the physical graph, and at least one request edge connecting the request nodes.
The apparatus described above (memory storing the request graph and a processor configured to identify a placement pivot and order feasible cloud elements), uses a request graph that includes customer request nodes specifying customer requested cloud computing service operations, at least one service provider-based request node representing a service provider policy implemented in the physical graph, and at least one request edge connecting the request nodes. So the request graph incorporates both customer needs and service provider policies.
13. The apparatus of claim 10 , wherein each feasible cloud element is determined as an available solution for the corresponding one request node based on the request node specifying service requirements on at least one prescribed attribute type.
The apparatus described above (memory storing the request graph and a processor configured to identify a placement pivot and order feasible cloud elements), determines that each feasible cloud element is an available solution for its corresponding request node based on the request node specifying service requirements related to at least one prescribed attribute type. This means the available cloud element must meet the requirements specified by the requesting node to be considered a feasible solution.
14. The apparatus of claim 13 , wherein the prescribed attribute type includes at least one of processor type, virtual data center service type, or network service type.
In the apparatus described above where each feasible cloud element is determined as an available solution for its corresponding request node based on service requirements related to at least one prescribed attribute type, the prescribed attribute type includes at least one of processor type, virtual data center service type, or network service type. Therefore, the service requirements can specify particular processor types, virtual data center service types or network service types to be considered a feasible solution.
15. The apparatus of claim 10 , wherein the physical graph represents a service provider deployment of the data network according to service provider-based constraints and policies.
In the apparatus described above (memory storing the request graph and a processor configured to identify a placement pivot and order feasible cloud elements), the physical graph that represents a data network having a physical topology represents a service provider deployment of the data network according to service provider-based constraints and policies. In other words, the physical graph reflects the actual network infrastructure as deployed and managed by the service provider, incorporating their specific constraints and policies.
16. The apparatus of claim 15 , wherein the processor circuit is configured for determining the candidate sets of feasible cloud elements for the at least one request edge based on: identifying, among the feasible cloud elements relative to the physical graph, candidate sets of possible solutions for feasible cloud elements based on identifying respective paths in the physical graph connecting the associated feasible cloud elements; filtering the candidate sets of possible solutions based on the service provider-based constraints and policies.
The apparatus described above (memory storing the request graph and a processor configured to identify a placement pivot and order feasible cloud elements), is configured to determine candidate sets of feasible cloud elements for each request edge by: identifying possible solutions for feasible cloud elements based on identifying paths in the physical graph connecting the associated feasible cloud elements and filtering those sets of possible solutions based on service provider constraints and policies. This involves finding possible paths between feasible cloud elements and then eliminating paths that violate service provider rules.
17. The apparatus of claim 16 , wherein: the service provider-based constraints and policies include at least one of a bandwidth constraint limiting bandwidth consumption on at least one of the feasible cloud elements, or an overlay constraint limiting traversal of network traffic from one of the request nodes to a second of the request nodes; the optimum candidate set heuristically determined to provide a sequence of physical network nodes implementing the request graph in the physical topology and that minimizes consumption of bandwidth in the physical topology.
In the apparatus described above where candidate sets of feasible cloud elements are determined for each request edge based on service provider constraints and policies, the service provider constraints and policies include at least one of a bandwidth constraint (limiting bandwidth consumption on feasible cloud elements) or an overlay constraint (limiting traversal of network traffic from one request node to another). The optimum candidate set is heuristically determined to provide a sequence of physical network nodes implementing the request graph in the physical topology that minimizes consumption of bandwidth in the physical topology.
18. The apparatus of claim 10 , wherein the requested cloud computing service operations include at least one of compute, storage, or networking services.
In the apparatus described above (memory storing the request graph and a processor configured to identify a placement pivot and order feasible cloud elements), the requested cloud computing service operations include at least one of compute, storage, or networking services. This means that the request nodes within the request graph can represent requests for compute resources, storage capacity, network connectivity or a combination of these.
19. Logic encoded in one or more non-transitory tangible media for execution and when executed operable for: retrieving, for a cloud computing service, a request graph specifying request nodes identifying respective requested cloud computing service operations, and at least one request edge specifying a requested path requirements connecting the request nodes; identifying a placement pivot from among feasible cloud elements identified in a physical graph representing a data network having a physical topology, each feasible cloud element an available solution for one of the request nodes, the placement pivot having a maximum depth in the physical topology relative to the feasible cloud elements; ordering the feasible cloud elements, within candidate sets of feasible cloud elements identified as available solutions for the at least one request edge, according to increasing distance from the placement pivot to form an ordered list of candidate sets of feasible cloud elements; and determining an optimum candidate set, from at least a portion of the ordered list, based on the optimum candidate set having an optimized fitness function in the physical graph from among the other candidate sets in the ordered list.
Logic encoded in non-transitory media (e.g., software) performs cloud resource placement by: retrieving a request graph specifying requested cloud services (compute, storage, networking) as request nodes and their path requirements as request edges; identifying a placement pivot from available cloud elements, prioritizing those with maximum depth in the physical network topology; ordering feasible cloud elements within candidate sets based on increasing distance from the placement pivot; and selecting an optimal candidate set based on an optimized fitness function in the physical graph.
20. The logic of claim 19 , wherein the identifying further includes identifying the placement pivot as having a maximum available link bandwidth relative to other feasible cloud elements having the same maximum depth.
The logic described above (retrieving a request graph, identifying a placement pivot, ordering feasible cloud elements, and selecting an optimal candidate set), identifies the placement pivot based not only on maximum depth in the physical topology relative to other feasible cloud elements, but also on having the maximum available link bandwidth compared to other feasible cloud elements with the same maximum depth. Therefore, if multiple feasible cloud elements are at the same maximum depth, the one with the highest available bandwidth is chosen as the placement pivot.
Unknown
October 7, 2014
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.