Dynamic bandwidth allocation in cloud network switches based on traffic demand forecasts.

Dynamic QoS policy adjustment in cloud network switches addresses fluctuating traffic demands, enhancing traffic handling and QoS by real-time bandwidth allocation, preventing packet delay and jitter loss.

JP7880829B2Active Publication Date: 2026-06-26INTERNATIONAL BUSINESS MACHINE CORPORATION

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
INTERNATIONAL BUSINESS MACHINE CORPORATION
Filing Date
2023-01-05
Publication Date
2026-06-26

Smart Images

  • Figure 0007880829000001
    Figure 0007880829000001
  • Figure 0007880829000002
    Figure 0007880829000002
  • Figure 0007880829000003
    Figure 0007880829000003
Patent Text Reader

Abstract

To provide dynamic bandwidth allocation in cloud network switches in a cloud computing environment.SOLUTION: Quality of service (QoS) policies may be dynamically changed in one or more cloud network switches based on dynamically estimating expected traffic demands for each of multiple traffic classes, where the bandwidth is dynamically allocated among queues based on changing the QoS policies.SELECTED DRAWING: Figure 7
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention generally relates to computing systems, and more specifically, to various embodiments for dynamic bandwidth allocation in cloud network switches within a cloud computing environment based on traffic demand prediction.

Background Art

[0002] A popular type of large-scale computing is cloud computing. Here, resources may interact, be accessed, or a combination thereof may occur via a communication system such as a computer network. Resources may be software-rendered simulations, emulations of computing devices, or both, storage devices, applications, other computer-related devices, or combinations thereof, services operating on one or more computing devices such as servers, or combinations thereof. For example, multiple servers can communicate, share, or both information that can scale up, scale down, or both across servers depending on the amount of processing power, storage space, other computing resources, or combinations thereof required to accomplish the requested task. The term "cloud" implicitly indicates the cloud-shaped appearance of the diagram of the interconnectivity among computing devices, computer networks, other computer-related devices, or combinations thereof that interact in such a configuration.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Various embodiments are provided for dynamic bandwidth allocation in cloud network switches within a cloud computing environment.

Means for Solving the Problems

[0004] One or more Quality of Service (QoS) policies on one or more cloud network switches may be dynamically modified based on the expected traffic demand for each of several traffic classes, which are mapped to queues on the ports of network elements. Bandwidth allocation between queues on a given port in one or more cloud network switches may be dynamically modified by changing the QoS policy.

[0005] In addition to the exemplary embodiments of the method described above, other exemplary system and computer product embodiments are provided, which offer relevant advantages. [Brief explanation of the drawing]

[0006] To facilitate understanding of the advantages of the present invention, a more detailed description of the invention, which is concisely stated above, will be made by reference to specific embodiments shown in the accompanying drawings. Understanding that these drawings only illustrate typical embodiments of the invention and should not be considered as limiting its scope, the invention will be described and explained with additional specifics and details through the use of the accompanying drawings.

[0007] [Figure 1] This is a block diagram illustrating an exemplary computing node according to an embodiment of the present invention.

[0008] [Figure 2] This is an additional block diagram illustrating an exemplary cloud computing environment according to an embodiment of the present invention.

[0009] [Figure 3] This is an additional block diagram illustrating an abstraction model layer according to an embodiment of the present invention.

[0010] [Figure 4]This is an additional block diagram illustrating exemplary functional relationships between various aspects of the present invention.

[0011] [Figure 5] This is a block diagram illustrating the operation of dynamic bandwidth allocation in a cloud network switch within a cloud computing environment based on traffic demand forecasting, according to one embodiment of the present invention.

[0012] [Figure 6] This is a block diagram illustrating the operation of dynamic bandwidth allocation in a cloud network switch within a cloud computing environment based on traffic demand forecasting, according to one embodiment of the present invention.

[0013] [Figure 7] This is an additional flowchart illustrating a method for dynamic bandwidth allocation in a cloud network switch within a cloud computing environment based on traffic demand forecasting, according to one embodiment of the present invention. [Modes for carrying out the invention]

[0014] As a preliminary point, computing systems may include large-scale computing known as “cloud computing,” where resources can interact, be accessed, or both interact with each other via communication systems such as computer networks. Resources may be software-rendered simulations, emulations of computing devices, or both; storage devices, applications, other computer-related devices, or combinations thereof; services, or combinations thereof, running on one or more computing devices such as servers. For example, multiple servers can communicate, share, or both communicate information, which may scale up, down, or both across the servers, depending on the amount of processing power, storage space, other computing resources, or combinations thereof required to accomplish a requested task. The term “cloud” implicitly refers to the cloud-shaped appearance of the diagram of interconnectivity between computing devices, computer networks, other computer-related devices, or combinations thereof interacting in such a configuration.

[0015] Cloud networks generate constant fluctuations in the types of applications running on them, resulting in diverse traffic characteristics over time. These constant changes in traffic demand complicate the process of allocating appropriate bandwidth via the priority plane in network switches to ensure quality of service ("QoS") on the network. For example, a given QoS profile that statically reserves bandwidth for a set of traffic classes may be appropriate and effective at a given time, but may perform poorly if traffic demand changes significantly.

[0016] Accordingly, various embodiments of the present invention provide novel solutions for addressing how to allocate bandwidth between switch queues in a cloud network, regardless of steady-state changes in traffic demand. In some implementations, one or more quality of service (QoS) policies on one or more cloud network switches can be dynamically modified based on the expected traffic demand for each of the multiple traffic classes. Bandwidth on one or more cloud network switches can be dynamically allocated based on the dynamic modification of the QoS policies.

[0017] Since many enterprise networks implementing QoS policies primarily focus on enterprise networks where the amount of change in application traffic demand is relatively small compared to cloud networks, the present invention offers advantages to the current state of the art. Furthermore, it offers further advantages to the current state of the art that rely on static bandwidth allocation between network switch queues, because static allocation is insecure in cloud environments where traffic demand is constantly changing. If traffic allocation for network-sensitive applications is incorrect in the QoS policy, the traffic may encounter packet delay, jitter loss, or a combination thereof, while other lower-priority traffic avoids such degradation due to incorrect bandwidth allocation.

[0018] In other implementations, various differentiated service frameworks may classify traffic types (e.g., traffic classes) and configure network elements (switches, routers) to process marked packets in a differentiated manner via a Differentiated Service Code Point ("DSCP") field in the packet header. For example, packets marked as "high priority" may be forwarded before other packets or some bandwidth are reserved in a switch queue based on traffic importance.

[0019] Such QoS policies can achieve the intended differentiated behavior when the traffic demand of a traffic class is known or well understood. As such, the present invention is applicable to cloud networks where traffic demand can vary significantly over time. In some implementations, the QoS policies configured on a network switch (i.e., queue bandwidth allocation) can be dynamically changed, adjusted, or modified based on the demand expectations for each traffic class.

[0020] In some implementations, the demand expectations can be derived from information regarding the scheduling of virtual entities, typically realized by an overlay software-defined network (SDN) controller. In some embodiments, the present invention can use visibility into the network topology and routing to map the demand originating from a server to network elements. Further, various embodiments provide for continuously monitoring and identifying network elements that do not conform to the set policies. Depending on the programmability in the cloud network realized by a software-defined underlay controller for dynamically configuring network elements, the present invention can modify the QoS settings of a switch to reflect the intended traffic handling behavior under a new traffic state. In some implementations, the QoS policy can be changed, adjusted, configured, or a combination thereof, based on the expected traffic demand in a scalable manner. The allocation can be modified to match the demand of the new traffic class only when the expected traffic demand between one or more of the traffic classes exceeds a predetermined threshold. As a result, the proposed invention alleviates the problem in the feasibility of the QoS priority plane when the traffic situation changes constantly.

[0021] As used herein, "network element" can refer to, for example, switches, routers, and other packet processing elements. Also, the use of the term "network switch" can be considered as an example only, or by way of illustration. As such, the use of the term "network switch" may be replaced by "network element" in order to address a broader view of the present invention and capture a broader perspective.

[0022] In addition, the bandwidth allocation between queues can be explicitly defined, for example, such that queue 3 receives 50 gigabits per second ("Gbps") per second. Alternatively, it can be implicitly defined such that the scheduler services queue 3 50% of the time, which, on a 100 Gbps port, has the net effect of a 50 Gbps allocation on queue 3. Also, the bandwidth allocation can be implicitly realized as well.

[0023] Furthermore, an important aspect of the present invention is to utilize QoS policies. These policies are applicable to ports on network elements and define how bandwidth is divided among the queues of a given port.

[0024] Other examples of various aspects of the illustrated embodiments, and the attendant advantages, will be further described herein.

[0025] Although this disclosure includes a detailed description regarding cloud computing, it should be understood in advance that the implementation of the teachings described herein is not limited to a cloud computing environment, a computing system associated with one or more vehicles, or a combination thereof. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment known now or developed in the future.

[0026] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and deployed with minimal management effort or interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0027] The characteristics are as follows:

[0028] On-demand self-service: Cloud users can unilaterally provision computing functions such as server time and network storage automatically as needed, without requiring human interaction with service providers.

[0029] Broad network access: The functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and personal digital assistants (PDAs)).

[0030] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated as needed. Consumers generally do not have control over, or knowledge of, the exact location of the resources provided, although they may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0031] Rapid scalability: Various functions can be provisioned rapidly and flexibly, sometimes automatically, allowing for quick scaling out or rapid release and rapid scaling in. To consumers, it often appears as if there are unlimited functions available for provisioning, and they can be purchased anytime, in any quantity.

[0032] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging appropriate metric capabilities for service types (e.g., storage, processing, bandwidth, and active user accounts) at a certain level of abstraction. Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0033] The service model is as follows:

[0034] Software as a Service (SaaS): The functionality provided to consumers is the use of a provider's applications running on cloud infrastructure. These applications are accessible from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application functionalities. However, limited user-specific application configuration settings may be an exception.

[0035] Platform as a Service (PaaS): The functionality offered to consumers is the deployment of applications created or acquired by the consumer, using programming languages ​​and tools supported by the provider, onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they do control the deployed applications and, in some cases, the applications that host the environment configuration.

[0036] Infrastructure as a Service (IaaS): The functionality provided to consumers is the provisioning of processing, storage, networking, and other basic computing resources, allowing consumers to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating system, storage, and deployed applications, and in some cases have limited control over selected networking components (e.g., host firewalls).

[0037] The deployment model is as follows:

[0038] Private Cloud: A cloud infrastructure operated for a single organization only. It can be managed by the organization or a third party and can reside on-premises or off-premises.

[0039] Community Cloud: A cloud infrastructure shared by several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). The community cloud may be managed by those organizations or a third party and may reside on-premises or off-premises.

[0040] Public cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0041] Hybrid Cloud: A cloud infrastructure that combines two or more clouds (private, community, or public), where each cloud remains a distinct entity, but they are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing across clouds).

[0042] Cloud computing environments are service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0043] Referring here to Figure 1, a schematic diagram of an example of a cloud computing node is shown. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to imply any limitation on the scope of use or functionality of the embodiments of the invention described herein. In any case, cloud computing node 10 is capable of implementing or performing any of the functions described above, or a combination thereof.

[0044] The cloud computing node 10 contains computer systems / servers 12 that operate with a number of other general-purpose or purpose-specific computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer systems / servers 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0045] The computer system / server 12 may be described in the general context of computer system executable instructions, such as program modules executed by the computer system. Generally, a program module may include routines, programs, objects, components, logic, and data structures that perform a specific task or implement a specific abstract data type. The computer system / server 12 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked over a communication network. In a distributed cloud computing environment, program modules may reside on both local computer system storage media, including memory storage devices, and remote computer system storage media.

[0046] As shown in Figure 1, the computer system / server 12 in the cloud computing node 10 is represented in the form of a general-purpose computing device. The components of the computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, system memory 28, and a bus 18 that connects various system components, including the system memory 28, to the processor 16.

[0047] Bus 18 represents any one or more of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and local buses that use a processor or any of various bus architectures. Examples of such architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Microchannel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0048] The computer system / server 12 typically includes various computer system-readable media. Such media may be any available media accessible by the computer system / server 12, and such media may include both volatile and non-volatile media, removable and non-removable media.

[0049] The system memory 28 (or memory subsystem 28) may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 30, cache memory 32, or both. The cache memory 32 may include, for example, a shared cache (such as an L2 cache) shared among multiple cores of the processor 16, a private cache (such as an L1 cache), or both. The computer system / server 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. For illustrative purposes only, a storage system 34 may be provided for reading from and writing to a non-removable non-volatile magnetic medium (not shown, typically called a “hard drive”). Not shown, a magnetic disk drive may be provided for reading from and writing to a removable non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive may be provided for reading from and writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such an example, each can be connected to the bus 18 by one or more data media interfaces. As will be further depicted and described below, the system memory 28 may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of embodiments of the present invention.

[0050] A program / utility 40 (e.g., P / U) having a set (at least one) of program modules 42 may, but is not limited to, be stored in system memory 28, as exemplary, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a network environment. A program module 42 ("PM") generally performs a function, methodology, or combination thereof of the embodiments of the present invention as described herein.

[0051] The computer system / server 12 can also communicate with one or more external devices 14, such as a keyboard, pointing device, display 24, one or more devices that enable a user to interact with the computer system / server 12, or any device that enables the computer system / server 12 to communicate with one or more other computing devices (e.g., a network card, modem, etc.), or a combination thereof. Such communication may occur via the input / output (I / O) interface 22. Furthermore, the computer system / server 12 can also communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via the network adapter 20. As depicted, the network adapter 20 communicates with other components of the computer system / server 12 via the bus 18. It should be understood that other hardware and / or software components, or both, that are not shown, may be used in conjunction with the computer system / server 12. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Array of Independent Disks (RAID) systems, tape drives, and data archive storage systems.

[0052] Referring now to Figure 2, an exemplary cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 comprises one or more cloud computing nodes 10 to which local computing devices used by cloud users, such as a PDA or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, an automotive computer system 54N, or a combination thereof, can communicate. The nodes 10 can communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, or a combination thereof, such as private, community, public, or hybrid clouds as described above. This enables the cloud computing environment 50 to provide infrastructure, platforms, or software, or a combination thereof, as a service, without requiring cloud users to maintain resources on their local computing devices. The types of computing devices 54A-N shown in Figure 2 are for illustrative purposes only, and it should be understood that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network or network-addressable connection, or a combination thereof (e.g., using a web browser).

[0053] Referring now to Figure 3, a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 2) is shown. It should be understood in advance that the components, layers, and functionalities shown in Figure 3 are for illustrative purposes only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functionalities are provided:

[0054] Device Layer 55 includes standalone or both physical devices, virtual devices, or combinations thereof, integrated with electronics, sensors, actuators, and other objects for performing various tasks in a cloud computing environment 50. Each device in Device Layer 55 incorporates networking capabilities to other functional abstraction layers. As a result, information obtained from devices may be provided to them, information from other abstraction layers may be provided to devices, or both. In one embodiment, the various devices encompassing Device Layer 55 may incorporate a network of entities collectively known as the “Internet of Things” (IoT). Such a network of entities, as those skilled in the art will understand, enables the communication, collection, and propagation of data to achieve a wide variety of purposes.

[0055] The device layer 55 as shown includes, as shown, a sensor 52, an actuator 53, a “learning” thermostat 56 with integrated processing, sensors, and networking electronics, a camera 57, a controllable household outlet / receptacle 58, and a controllable electronic switch 59. Other possible devices may include, but are not limited to, a variety of additional sensor devices, networking devices, electronic devices (such as remote control devices), additional actuator devices, so-called “smart” devices such as refrigerators or washer / dryers, and a wide range of other possible interconnected objects.

[0056] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include a mainframe 61; a RISC (Reduced Instruction Set Computer) architecture-based server 62; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0057] The virtualization layer 70 provides an abstraction layer that may provide the following examples of virtual entities: virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems 74, and virtual clients 75.

[0058] In one example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources used to perform tasks within the cloud computing environment. Measurement and pricing 82 provides cost tracking as resources are used within the cloud computing environment and billing or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud users and tasks, and protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides allocation and management of cloud computing resources to ensure that required service levels are met. Service level agreement (SLA) planning and execution 85 provides proactive preparation and procurement of cloud computing resources for which future needs are anticipated in accordance with SLAs.

[0059] Workload layer 90 provides examples of functions that can be utilized in a cloud computing environment. Examples of workloads and functions that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, provision of virtual classroom education 93, data analysis processing 94, transaction processing 95, and various workloads and functions 96 for dynamically allocating bandwidth between queues of switch ports in a cloud network switch, in the context of the illustrated embodiments of the present invention. In addition, workloads and functions 96 for dynamically allocating bandwidth between queues of switch ports in a cloud network switch may include operations such as data analysis, data analytics, and detection and comparison functions, which will be further described. Those skilled in the art will understand that workloads and functions 96 for dynamically allocating bandwidth between queues of switch ports in a cloud network switch may also work in conjunction with other parts of various abstraction layers, such as hardware and software 60, virtualization 70, management 80, and other workloads 90 (such as data analysis processing 94) for achieving various purposes of the illustrated embodiments of the present invention.

[0060] As previously demonstrated, the present invention provides dynamic bandwidth allocation in cloud network elements within a cloud computing environment. A Quality of Service (QoS) policy can be dynamically changed in one or more cloud network switches based on dynamically estimating the expected traffic demand for each of several traffic classes. Here, bandwidth is dynamically allocated among queues based on the change in the QoS policy.

[0061] Referring here to Figure 4, an example of system 400 including a network 401 supporting software-defined networking (SDN) is described in more detail here. In the example depicted in Figure 4, system 400 is an enterprise system including multiple servers 402 and client systems 404 configured to communicate over network 401 using, for example, an SDN-enabled switch 406 compatible with OpenFlow. Thus, network 401 may also be referred to as enterprise network 401 and may be geographically distributed among multiple physical locations. In exemplary embodiments, a server 402, also referred to as a host or host system, is a high-speed processing device (e.g., a mainframe computer, desktop computer, laptop computer, handheld device, embedded computing device, or similar) including at least one processing circuit (e.g., computer processor / CPU) capable of reading and executing instructions and handling interactions with various components of system 400. One or more of the servers 402 may be storage system servers configured to access large amounts of data and store large amounts of data in one or more data storage systems 408. Server 402 may also be a compute node containing one or more workload managers 420, subprograms 422, and other applications (not shown).

[0062] The client system 404 may include a variety of desktop, laptop, general-purpose computer devices, mobile computing devices, network devices, or a combination thereof, having processing circuits and input / output (I / O) interfaces such as keys / buttons, touchscreens, audio inputs, display devices, and audio outputs. The client system 404 may be linked to one or more of the switches 406 directly or wirelessly through one or more wireless access points 410.

[0063] The data storage system 408 refers to any type of computer-readable storage medium and may comprise one or more secondary storage elements, such as a hard disk drive (HDD), solid-state memory, tape, or an internal or external storage subsystem of the server 402. The types of data that may be stored in the data storage system 408 may include, for example, various files and databases. There may be multiple data storage systems 408 utilized by one or more of the servers 402, and these may be distributed at various locations within the system 400.

[0064] System 400 also includes an SDN controller 410, which is a central software-defined network controller configured to make routing decisions within network 401. The SDN controller 412 establishes a secure link 403 to configure communication properties between switch 406 and link 405 between switch 406. For example, the SDN controller 412 may configure switch 406 as well as one or more firewalls 414 and one or more load networks 418 to control packet routing paths for data flows between server 402 and client system 404. One or more firewalls 414 restrict access and flow of network traffic between network 401 and one or more external networks 418. One or more load networks 418 may distribute workloads across multiple computers, such as between server 402. The SDN controller 412 may also configure switch 406 to define flows between server 402, programs (e.g., virtual machines), and subprograms 422 that run on server 402.

[0065] The server 402, client system 404, and SDN controller 412 may include various computer / communication hardware and software technologies known in the art, such as one or more processing units or circuits, volatile and non-volatile memory including removable media, powered network interfaces, support circuits, operating systems, and the like. Although the SDN controller 412 is depicted as a separate component, it will be understood that the network configuration function can alternatively be implemented in one or more of the servers 402 or client systems 404, either in a standalone or distributed form.

[0066] Network 401 may include a combination of wireless, wired, and / or fiber optic links. Network 401 as depicted in Figure 4 represents a simplified example for illustrative purposes. For example, each of the links 405 depicted in network 401 may include one or more physical links. Embodiments of network 401 may include a number of switches 406 (e.g., hundreds) each having dozens of ports and links. A switch 406 may also represent any type of device, commonly referred to as a network resource, capable of transferring data through one or more ports. Network 401 may support a variety of known communication standards that enable data to be transmitted between a server 402, a client system 404, a switch 406, an SDN controller 412, a firewall 414, a load balancer 416, or a combination thereof. Communication protocols are typically implemented in one or more layers, such as the physical layer (layer-1), the link layer (layer-2), the network layer (layer-3), the transport layer (layer-4), and the application layer (layer-5). In an exemplary embodiment, network 401 supports SDN as a Layer-2 protocol. Switch 406 may be a dedicated SDN switch or an SDN-enabled general-purpose switch that also supports Layer-2 and Layer-3 Ethernet®.

[0067] In an exemplary embodiment, one of the servers 402 is an enterprise server 402 capable of operating to constitute an SDN controller 412. A secure link 403 may be used between the enterprise server 402 and the SDN controller 412. The SDN controller 412 can aggregate and allocate flows and manage interactions. The SDN controller 412 may also list default quality of service requirements, such as end-to-end latency and bandwidth requirements, as well as other requirements on a per-link basis, such as jitter. The SDN controller 412 may perform initial allocation and provisioning based on traffic demand and traffic class.

[0068] Referring now to Figure 5, a block diagram is shown illustrating the functional component 500 as an example of various mechanisms of the embodiment shown. Figure 5 shows a system 500 for dynamic bandwidth allocation in a cloud network switch in a cloud computing environment. In one embodiment, one or more of the components, modules, services, applications, functions, or combinations thereof described in Figures 1 to 4 may be used in Figure 5. In one embodiment, repeated descriptions of similar elements, components, modules, services, applications, functions, or combinations thereof employed in other embodiments described herein (e.g., Figures 1 to 4) are omitted for brevity.

[0069] With the above in mind, the module / component block 500 may also be incorporated into various hardware and software components of the system for dynamic bandwidth allocation in a cloud network switch within a cloud computing environment (for example, dynamically changing a Quality of Service (QoS) policy) according to the present invention. Many functional blocks 500 can run as background processes on various components in a distributed computing component, a user device, or elsewhere.

[0070] The computer system / server 12 in Figure 1 is shown incorporating a dynamic bandwidth allocation service 510. The dynamic bandwidth allocation service 510 may incorporate a processor 520 and memory 530 to perform various calculations, data processing, and other functions according to various aspects of the present invention. The dynamic bandwidth allocation service 510 may be provided by the computer system / server 12 in Figure 1.

[0071] As those skilled in the art will understand, the depiction of various functional units in the dynamic bandwidth allocation service 510 is for illustrative purposes only, as the functional units may be located within the dynamic bandwidth allocation service 510, or elsewhere within, between, or in combination with distributed computing components.

[0072] In one embodiment, a computer system / server 12, a dynamic bandwidth allocation service 510, or a combination thereof may provide virtualized computing services (i.e., virtualized computing, virtualized storage, virtualized networking, etc.). More specifically, the dynamic bandwidth allocation service 510 may provide, or be incorporated into, virtualized computing, virtualized storage, virtualized networking, and other virtualized services running on a hardware board, or both.

[0073] In one embodiment, the dynamic bandwidth allocation service 510 may provide, or be associated with, a QoS component 540, a traffic class component 550, a configuration component 560, and an allocation component 570, or both. Each of these may communicate with one another.

[0074] In one embodiment, the dynamic bandwidth allocation service 510 may dynamically change the Quality of Service (QoS) policy on one or more cloud network switches based on the expected traffic demand for each of several traffic classes, using one or more of the QoS component 540, traffic class component 550, configuration component 560, and allocation component 570. Here, bandwidth is dynamically allocated among queues on the cloud network switches based on the dynamic change in the QoS policy.

[0075] In one embodiment, the dynamic bandwidth allocation service 510 may use one or more of the QoS component 540, the traffic class component 550, and the configuration component 560 to determine traffic demand based on the scheduling of one or more virtual entities by multiple overlay network controllers.

[0076] In one embodiment, the dynamic bandwidth allocation service 510 may use one or more of the QoS component 540, the traffic class component 550, and the configuration component 560 to map traffic demand to network elements using knowledge of topology and routing in the computing network, and based on the mapping, monitor and identify network elements that conflict with one or more of the QoS policies.

[0077] The QoS component 540, in conjunction with the configuration component 560, may switch or adjust the QoS policy based on the expected traffic demand.

[0078] In one embodiment, the dynamic bandwidth allocation service 510 may determine the maximum amount of traffic demand for each of several traffic classes by using one or more of the QoS component 540, the traffic class component 550, and the configuration component 560 to determine the number of one or more virtual entities running on one or more compute servers.

[0079] In some implementations, the configuration component 560 can consist of multiple network elements based on dynamically changing the QoS policy.

[0080] In other implementations, in relation to dynamically changing QoS policies on one or more cloud network switches based on expected traffic demand, the dynamic bandwidth allocation service 510 may use one or more of the QoS component 540, traffic class component 550, and configuration component 560 to determine when the traffic demand for each of the multiple traffic classes exceeds a predetermined traffic threshold, and may dynamically allocate bandwidth among queues on the cloud network switch to process the traffic demand and serve the traffic demand based on the QoS policy.

[0081] For further explanation, Figure 6 is a block diagram illustrating the operation of dynamic bandwidth allocation in a cloud network switch within a cloud computing environment based on traffic demand forecasting according to one embodiment of the present invention.

[0082] In other words, Figure 6 is a block diagram depicting a spine / leaf network 600 with an equal-cost multipath ("ECMP") protocol operating between spine and leaf switches, such as spine switches 652A-M and leaf switches 642A-D. In one embodiment, one or more of the components, modules, services, applications, functions, or combinations thereof described in Figures 1-5 may be used in Figure 6. In one embodiment, repeated descriptions of similar elements, components, modules, services, applications, functions, or combinations thereof employed in other embodiments described herein (e.g., Figures 1-5) may be omitted for the sake of brevity. In some implementations, a data center network having a spine / leaf network 600 topology such as spine switches 652A-M in network 630 may be assumed, but other network topologies may be applied as well.

[0083] As depicted in Figure 6, the configuration of the three servers is contained within Rack 1 (i.e., Rack 640A), and the overall configuration of Rack 1 is modified beyond an already established threshold. As a result, one or more QoS policies on all associated ports are modified (e.g., all ports shown as black dots, such as the ports on leaf switch 642A and spine switches 652A-M, and e.g., all ports, such as the ports shown as transparent dots, such as leaf switches 642A and 642D). The QoS policies on some ports (e.g., the ports on leaf switches 642A and 642D, e.g., transparent dots) are based on the server traffic configuration. Similarly, the QoS policies on some ports (e.g., all ports, shown as black dots, such as the ports on leaf switch 642A and spine switches 652A-M) reflect the changes in aggregated rack traffic.

[0084] Thus, the present invention, for example using a spine / leaf network 600, provides the ability to dynamically change the QoS policy on cloud network switches within the cloud computing network 630 based on demand expectations for each traffic class (TC). An underlay cloud network controller 610 (e.g., an underlay SDN controller) and an overlay cloud network controller 620 (e.g., an overlay SDN controller), and the communication between them are depicted in Figure 6. The underlay cloud network controller 610 and the overlay cloud network controller 620 may be located in the same place, incorporated into a single network stack, or both. The underlay cloud network controller 610 has visibility into the topology of the cloud computing network 630 and the routes between servers in the network 630, and has the ability to update the traffic processing behavior on the network switches.

[0085] The overlay cloud network controller 620 may contain all the necessary information to generate expected traffic demand for each traffic class ("TC") on each server, such as the servers in each of server racks 640A-640D. These expected demands may be calculated based on the virtual machine ("VM") profiles running on server racks 640A-640D.

[0086] For example, network 630 can speed up each of a given type of VM hosted on a server (e.g., one of the servers in racks 640A–640D), which can be used as the expected tenant traffic demand for that given VM type. In addition, if one of the traffic classes is for storage, the maximum amount of traffic allocated to a server (e.g., one of the servers in racks 640A–640D) can be calculated by using the upper limit of virtual disk in / out operations per second ("IOPS") and adding up the storage demands of all VMs running on the server (e.g., one of the server racks 640A–640D). The information can be aggregated at the rack level by adding up the expected demand for a given class across all servers in a rack, such as each of the servers in one or more of the racks 640A–640D.

[0087] The overlay cloud network controller 620 periodically informs the underlay cloud network controller 610 of changes in expected demand per TC due to the arrival, departure, or both of virtual entities such as VMs, virtual NICs, and virtual disks. For example, if k traffic classes are supported, the underlay cloud network controller 610 maintains the expected amount of demand for each of the k classes based on the network 630 resources allocated to the virtual entities running on each server (e.g., one or more servers on one or more of racks 640A-640D).

[0088] The underlay cloud network controller 610 can keep track of the server-level and rack-level demand configuration for each traffic class (e.g., one or more servers on one or more of racks 640A-640D) and can map multiple traffic classes to output queues on the switch ports.

[0089] This mapping of traffic classes to output queues is configurable. The underlay cloud network controller 610 also maintains a QoS profile for each port in network 630. The port's QoS profile reflects how much switch resources should be allocated to processing traffic for each output queue. Thus, the QoS policy determines how traffic from each class is processed by the switch.

[0090] In some implementations, the QoS policy on a switch port may use round-robin scheduling to allocate scheduler time to each output queue. The QoS policy may be defined using traffic caps or reservations that reflect user preferences based on the expected demand for each output queue. For example, assuming a port speed of 100 gigabytes per second (Gbps) for illustrative purposes, if the underlay cloud network controller 610 is aware that the demand mapped to i traffic calls will never exceed pi Gbps, then the resource allocation for queuing i traffic calls may be configured to pi%, where i is a positive integer.

[0091] For example, a QoS policy allocates the following percentages [p1, p2, p3, p4, p5, p6, p7, p8], where p1 + ... + p8 equals 100%. If the expected amount of traffic mapped to a queue changes, the QoS profile can be modified to reflect the change. The mapping of traffic classes to output queues and then to resource allocation can be managed by the underlay cloud network controller 610. Initially, all queues on all underlay switches can be allocated so that available resources are shared equally among the TCs.

[0092] When the configuration of traffic demand in the cloud network changes, resulting in expected changes in demand, the proposed invention modifies the QoS policy on the port accordingly. The underlay cloud network controller 610 identifies servers (e.g., one or more servers in one or more of racks 640A-640D) whose traffic configuration has changed beyond an established threshold compared to the last update from the overlay cloud network controller 620.

[0093] The goal is to avoid updating for minor changes and to make corrections only when there are essential differences in the traffic configuration. Assuming k traffic classes, this calculation involves comparing two vectors. For example, this identification could be based on a heuristic method such as flagging ports where the demand for any traffic class has doubled or halved. The sensitivity of this calculation can be adjusted based on the needs of network 630. When the overlay cloud network controller 620 notifies the underlay cloud network controller 610, the underlay cloud network controller 610 performs the following: In step 1a, it is identified that the traffic configuration of a set of servers S has changed by an established threshold compared to the last update. In step 1b, for each port on a leaf switch, such as on one of the leaf switches 642A-D connected to a server in S, the egress QoS policy may be modified to reflect the new configuration. In stage 2a, a set of racks R (e.g., one of server racks 640A-640D) may be identified as having a traffic configuration that has changed by more than an established threshold compared to the last update. In stage 2b, for each leaf l connected to the racks in R, the QoS policy may be changed at the ports facing the spine switches to reflect the new QoS policy at each spine (e.g., each of spine switches 652A-M), and the QoS policy may be changed at the ports to l to reflect the new QoS policy.

[0094] As depicted in Figure 6, an exemplary spine / leaf network is shown with an Equal-Cost Multipath (ECMP) protocol operating between spine and leaf switches. In this example, the configuration of the three servers in rack 1, as well as the overall configuration of rack 1, has changed beyond an already established threshold. As a result, the QoS policies on all shown ports (e.g., one of server racks 640A-640D, one of 642A, and each of spine switches 652A-M) are modified. The QoS policy on the orange port is based on the server traffic configuration by stage 1a. Similarly, the QoS policy on the red port reflects the changes in the aggregated rack traffic by stage 2b.

[0095] Changes to QoS policies can be applied in predefined, individual steps and triggered only when a specific threshold is exceeded. The logic for adjusting thresholds or triggering QoS policy changes on switch ports may take real-time information into account, such as packet loss for a particular traffic class or real-time sampling of traffic flow within the fabric. QoS policies for traffic classes that consistently exceed their allocations may be adjusted.

[0096] Referring here to Figure 7, a method 700 for dynamic bandwidth allocation in a cloud network switch within a cloud computing environment by a processor is depicted, and various aspects of the illustrated embodiment can be implemented in this method. Function 700 can be implemented as an instruction on a machine, where the instruction is contained in at least one computer-readable medium or at least one non-temporary machine-readable storage medium. Function 700 may begin in block 702.

[0097] The Quality of Service ("QoS") policy may be dynamically changed in one or more cloud network switches based on dynamically estimating the expected traffic demand for each of several traffic classes, as shown in block 704, and bandwidth may be dynamically allocated between queues based on the change in the QoS policy. Bandwidth in one or more cloud network switches may be dynamically allocated based on the dynamic change in the QoS policy, as shown in block 706. Function 700 may be terminated, as shown in block 708.

[0098] In one embodiment, in conjunction with, as part of, or in combination with at least one block of Figure 7, the operation of Method 700 may include each of the following: The operation of Method 700 may determine traffic demand based on communication with an overlay controller that schedules one or more virtual entities. The operation of Method 700 may use topology and routing in a computing network to map traffic demand from one or more computing servers to network elements, and based on the mapping, monitor and identify network elements that conflict with one or more of the QoS policies.

[0099] The operation of Method 700 may switch or adjust the QoS policy based on expected traffic demand. The operation of Method 700 may determine the maximum amount of traffic demand for each of several traffic classes by determining the number of one or more virtual entities running on one or more compute servers and using the profiles of one or more virtual entities. The operation of Method 700 may configure several network elements based on dynamically changing the QoS policy. The operation of Method 700 may determine that the traffic demand for each of several traffic classes exceeds a predetermined traffic threshold in relation to dynamically changing the QoS policy on one or more cloud network switches based on expected traffic demand, and may dynamically allocate network resources, such as bandwidth to one or more cloud network elements, to enable processing the traffic demand based on the QoS policy and serving the traffic demand.

[0100] The operation of Method 700 may switch or adjust the QoS policy based on expected traffic demand. The operation of Method 700 may determine the maximum amount of traffic demand for each of several traffic classes by determining the number of one or more virtual entities running on one or more compute servers. The operation of Method 700 may configure several network elements based on dynamically changing the QoS policy. The operation of Method 700 may determine that the traffic demand for each of several traffic classes exceeds a predetermined traffic threshold and, based on the QoS policy, dynamically allocate bandwidth between queues in the cloud network switch to enable service to the traffic demand.

[0101] The operation of Method 700 may determine that one or more virtual entities are scheduled or removed to run on one or more cloud network switches, and based on the determination that one or more virtual entities are scheduled or removed, may reserve or release one or more network elements and resources for the traffic demand of each of the traffic classes.

[0102] The present invention may be an apparatus, system, method, computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or a set of mediums) having computer-readable program instructions thereon for causing a processor to perform an aspect of the present invention.

[0103] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any preferred combination of those described above. A non-exhaustive list of more specific examples of computer-readable storage media may also include, the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punched cards or grooved structures on which instructions are recorded, and any preferred combination of those described above. When used herein, computer-readable storage media should not be construed as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or transient signals such as electrical signals transmitted through wires.

[0104] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or they may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0105] The computer-readable program instructions that perform the operation of the present invention may be source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or object-oriented programming languages ​​such as Smalltalk®, C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can be personalized by executing computer-readable program instructions using state information of computer-readable program instructions in order to perform an aspect of the present invention.

[0106] Aspects of the present invention are described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0107] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a purpose-built computer, or other programmable data processing device to manufacture a machine. As a result, instructions executed via the computer's processor or other programmable data processing device may generate means for implementing functions / operations specified in blocks or multiple blocks of a flowchart or block diagram or a combination thereof. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, or other device or combination thereof to function in a particular manner. Consequently, a computer-readable storage medium containing instructions may comprise a product containing instructions for implementing modes of functions / operations specified in blocks or multiple blocks of a flowchart or block diagram or a combination thereof.

[0108] Computer-readable program instructions are also loaded onto a computer, other programmable data processing device, or other device to perform a series of operational steps on the computer, other programmable device, or other device, resulting in a computer-implemented process. As a result, instructions executed on a computer, other programmable device, or other device may implement a function / operation specified in a block or multiple blocks of a flowchart or block diagram or a combination thereof.

[0109] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the system, method, and computer program product according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in a block may occur in an order other than that shown in the figure. For example, two blocks shown consecutively may actually be executed substantially simultaneously, and blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram or flowchart diagram, or a combination thereof, and a combination of blocks in a block diagram or flowchart diagram, or a combination thereof, can be implemented by an application-specific hardware-based system that performs a specified function or operation, or a combination of application-specific hardware and computer instructions.

Claims

1. A method for dynamically allocating bandwidth in cloud network elements within a cloud computing environment using a processor, A method comprising the steps of dynamically changing a Quality of Service (QoS) policy in one or more cloud network switches based on dynamically estimating expected traffic demand for each of several traffic classes, wherein bandwidth is dynamically allocated between queues based on the step of changing the QoS policy, and further comprising the step of determining the traffic demand based on communication with an overlay controller that schedules one or more virtual entities.

2. The steps include mapping the traffic demand from one or more computing servers to network elements using topology and routing within the computing network, The method according to claim 1, further comprising the step of monitoring and identifying network elements that conflict with one or more of the QoS policies based on the mapping.

3. The system further comprises steps of switching or adjusting the QoS policy based on the expected traffic demand, The method according to claim 1.

4. The further step includes determining the number of virtual entities running on one or more computing servers and determining the maximum amount of traffic demand for each of the multiple traffic classes by using profiles of the one or more virtual entities. The method according to claim 1.

5. Based on the step of dynamically changing the QoS policy, the system further comprises the step of configuring multiple network elements. The method according to claim 1.

6. The step of dynamically changing the QoS policy on one or more cloud network switches based on expected traffic demand is: The step of determining whether the traffic demand for each of the aforementioned multiple traffic classes exceeds a predetermined traffic threshold, Based on the QoS policy, the steps include dynamically allocating network resources to one or more cloud network elements in order to process the traffic demand and provide services to the traffic demand, The method according to any one of claims 1 to 5, further comprising:

7. A system for dynamically allocating bandwidth in cloud network elements within a cloud computing environment, A system comprising one or more computers having an executable instruction that, when executed, causes the system to dynamically change a Quality of Service (QoS) policy in one or more cloud network switches based on dynamically estimating the expected traffic demand for each of a plurality of traffic classes, wherein bandwidth is dynamically allocated between queues based on the change in the QoS policy, and the executable instruction, when executed, causes the system to determine the traffic demand based on communication with an overlay controller that schedules one or more virtual entities.

8. If the aforementioned executable instruction is executed, the system will, Using topology and routing within the computing network, the traffic demand from one or more computing servers is mapped to network elements. The system according to claim 7, which monitors and identifies network elements that conflict with one or more of the QoS policies based on the mapping.

9. The system according to claim 7, wherein, if the executable instruction is executed, the system causes the system to switch or adjust the QoS policy based on the expected traffic demand.

10. The system according to claim 7, wherein, if the executable instruction is executed, the system causes the system to determine the maximum amount of traffic demand for each of the plurality of traffic classes by determining the number of one or more virtual entities running on one or more computing servers and by using the profiles of the one or more virtual entities.

11. The system according to claim 7, wherein, if the executable instruction is executed, the system causes the system to configure a plurality of network elements based on dynamically changing the QoS policy.

12. Dynamically changing the QoS policy on one or more cloud network switches based on expected traffic demand is Determining that the traffic demand for each of the aforementioned multiple traffic classes exceeds a predetermined traffic threshold, Based on the QoS policy, network resources are dynamically allocated to the one or more cloud network elements in order to process the traffic demand and provide services to the traffic demand. The system according to any one of claims 7 to 11, further comprising:

13. A computer program for dynamically allocating bandwidth in cloud network elements within a cloud computing environment, If executed by a computer, the computer will The system includes program instructions for dynamically changing the Quality of Service (QoS) policy in one or more cloud network switches based on dynamically estimating the expected traffic demand for each of several traffic classes, and program instructions for determining traffic demand based on communication with an overlay controller that schedules one or more virtual entities, and switching or adjusting the QoS policy based on the expected traffic demand, wherein bandwidth is dynamically allocated between queues based on the change in the QoS policy. Computer program.

14. When executed by the aforementioned computer, the aforementioned computer will Using topology and routing in a computing network, the traffic demand from one or more computing servers is mapped to network elements. Based on the mapping, the system monitors and identifies network elements that conflict with one or more of the QoS policies. It further includes program instructions. The computer program according to claim 13.

15. When executed by the aforementioned computer, the aforementioned computer will The number of one or more virtual entities running on one or more computing servers, and the profiles of the one or more virtual entities, are used to determine the maximum amount of traffic demand for each of the multiple traffic classes. It further includes program instructions. The computer program according to claim 13.

16. When executed by the aforementioned computer, the aforementioned computer will Multiple network elements are configured based on dynamically changing the aforementioned QoS policy. It further includes program instructions. The computer program according to claim 13.

17. Dynamically changing the QoS policy on one or more cloud network switches based on expected traffic demand is Determining whether the traffic demand for each of the aforementioned multiple traffic classes exceeds a predetermined traffic threshold, Based on the QoS policy, network resources are dynamically allocated to the one or more cloud network elements in order to process the traffic demand and provide services to the traffic demand. Furthermore, A computer program according to any one of claims 13 to 16.