WO2018224151A1

WO2018224151A1 - Device and method for providing a network slice

Info

Publication number: WO2018224151A1
Application number: PCT/EP2017/064006
Authority: WO
Inventors: Lazaros GKATZIKIS; Spyridon VASSILARAS; Georgios Paschos
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2017-06-08
Filing date: 2017-06-08
Publication date: 2018-12-13

Abstract

The present invention provides a device (100) for providing a minimum-cost network slice. The device (100) comprises an interface (101), a cost modifier module (103), a placement module (104), a connection embedding module (105), and a path computation module (106). The device (100) is configured to receive a network slice request (102) and a capacity (107) of each physical link in the network over the interface (101), the request including at least one placement constraint and at least one Quality of Service, QoS, constraint. The cost modifier module (103) is configured to modify real network costs according to congestion. The placement module (104) is configured to select a set of candidate paths based on the capacities (107) of the physical links, and to determine, for the set of candidate paths and according to the modified costs, the optimal placement of VNFs on network nodes satisfying the at least one placement constraint. The connection embedding module (105) is configured to determine, based on the capacities (107) of the physical links, actual paths to connect the placed VNFs so that the available network resources are not exceeded and the at least one QoS constraint is satisfied. The path computation module (106) is configured to determine at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraints. Advantageously, the modules (103-106) of the device (100) are configured to jointly determine the implementation of the network slice by determining the placement of the VNFs and their connections so that the overall network costs are minimized and all the constraints are satisfied.

Description

DEVICE AND METHOD FOR PROVIDING A NETWORK SLICE

TECHNICAL FIELD The present invention relates to a device and to a corresponding method for providing a minimum-cost network slice. Minimum-cost thereby means an overall minimization of network costs for providing the network slice. In particular, the device and method are for providing the minimum-cost network slice with Quality of Service (QoS) guarantees. BACKGROUND

Traditionally, cellular networks have been architected to support specific services, namely voice, messaging, and internet access. However, wireless operators are now faced with the major challenge to also support a number of diverse vertical industry applications, in order to expand the wireless market. Next-generation networks need to simultaneously accommodate applications and services with requirements as diverse as ultra-low latency and high resilience for real-time control of critical systems, or scalability to hundreds of thousands of connected devices towards the Internet-of-Things. This flexibility can only be achieved through softwarization (and especially cloudification) of the infrastructure. Further, novel network orchestration algorithms are required, which can split the physical network into logical (virtual) network slices with QoS guarantees.

A network slice is a collection of virtualized resources (e.g. processing, storage and network bandwidth), which are devoted to a specific communication service. Via network slicing, each service may rely on a different subset of network functions. The virtualization introduces an additional degree of freedom regarding the placement of these network functions (in the form of Virtual Network Functions (VNFs)) on network nodes. For example, a caching application can be either deployed on a network node located at the edge of the network, in order to minimize access latency and backhaul network traffic, or on a network node located at the core of the network, if the available resources at the edge are not adequate. Other optimizations supported by network slicing include statistical resource multiplexing, isolation between network slices, scaling in/out, down/up the slice resources, etc. Any slicing architecture should thus support such optimization algorithms for creation of one or more slices. When a controller calculates resource provisioning, and installs a network slice, a number of features are foreseen necessary for the operation of future networks. For instance, the network slice needs to satisfy bandwidth requirements, since the actual network is developing congestion bottlenecks, satisfy end-to-end latency constraints between traffic endpoints, reserve extra bandwidth to withstand possible failures, ensure that there are sufficient resources (e.g. processing and storage) for the VNFs, ensure that the network functions can be executed in a given order, and more. At the same time, any slicing algorithm should optimize the network slice selection with diverse optimization objectives, such as admitting the maximum number of slices, and operating each slice at the minimum network cost. However, achieving such complicated traffic engineering and optimization objectives is challenging, since it requires coordination of all the involved entities, and a joint consideration of cloud and network resources.

SUMMARY

In view of the above-mentioned challenges, the present invention aims to improve conventional network slicing. The present invention has thereby the object to provide a device and method that can provide a minimum-cost network slice, while also providing QoS guarantees, for instance, latency and resilience. The device and method should thus serve to orchestrate the network slicing in an improved manner. The network slicing should particularly be efficiently instantiated by the device and method. Additionally, the device and method should support algorithms for optimizing the slice selection with diverse optimization objectives, such as admitting the maximum number of slices. The object of the present invention is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

A first aspect of the invention provides a device for providing a minimum-cost network slice, comprising an interface configured to receive a network slice request including at least one placement constraint and at least one Quality of Service, QoS, constraint, and configured to receive a capacity of each physical link in the network, a cost modifier module configured to modify real network costs according to congestion, a placement module configured to select a set for candidate paths based on the capacities of the physical links, and determine, for the set of candidate paths and according to the modified costs, the optimal placement of Virtual Network Functions, VNFs, on network nodes satisfying the at least one placement constraint, a connection embedding module configured to determine, based on the capacities of the physical links, actual paths to connect the placed VNFs so that the available network resources are not exceeded and the at least one QoS constraint is satisfied, and a path computation module configured to determine at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraints, wherein the modules are configured to jointly determine the implementation of the network slice by determining the placement of the VNFs and their connections so that the overall network costs are minimized and all the constraints are satisfied.

The device of the first aspect can provide a minimum-cost network slice, while also providing certain QoS guarantees according to the QoS constraint, for instance, can fulfill latency and resilience requirements. The connection embedding module, by determining the actual paths, is configured to control congestion. Due to the modular but joint approach for determining the implementation of the network slice, the device is further able to provide the network slice with higher efficiency than a conventional device. Additionally, the device enables novel network slicing feature. In an implementation form of the first aspect, the at least one QoS constraint comprises a number of additive constraints, e.g. latency.

By taking into account additive constraints, particularly latency constraints, when providing the minimum-cost network slice, new services can be implemented and customer experience is significantly improved.

In a further implementation form of the first aspect, the network slice request further includes a resilience constraint, and the path computation module is configured to determine multiple paths between each two connected VNFs with lowest connection costs according to the resilience constraint.

By taking into account resilience constraints, when providing the minimum-cost network slice, the determined paths can be protected, which leads to a more reliable network performance. In a further implementation form of the first aspect, the placement module is further configured to determine the placement based on network node capacity constraints.

By taking into account capacity constraints of the network nodes, when providing the minimum-cost network slice, for instance, the network load can be balanced, and the overall network performance can be further increased.

In a further implementation form of the first aspect, the device further comprises a resource monitoring unit configured to monitor, periodically or event-based, a resource availability characteristic, particularly a residual node capacity statistic.

Thus, a violation of the node capacity can be avoided or at least countered, which leads to a better network performance. In a further implementation form of the first aspect, the cost modifier module is configured to modify the network costs based on a current resource utilization and a capacity of each physical link.

Thus, the network costs are determined more accurately, so as to capture congestion, and can be determined dynamically with changing network characteristics.

In a further implementation form of the first aspect, the cost modifier module is configured to modify the network costs based on historical data via machine learning techniques. Thus, a particular accurate cost modification is implemented.

In a further implementation form of the first aspect, the set of candidate paths used by the placement module are the shortest paths according to the network costs for at least one candidate VNF placement of each VNF.

In a further implementation form of the first aspect, the placement module and the connection embedding module are respectively configured to iteratively repeat the determination of the placement and the determination of the actual paths, and the path computation module is asked to provide the candidate paths based on modified network costs that are updated with each iteration according to the output of at least one previous iteration and the capacity constraints.

In a further implementation form of the first aspect, the device is configured to terminate the iterative determinations according to one or more termination criteria, wherein the one or more termination criteria comprise a number of iterations, a time budget and/or a cost difference between two iterations.

In a further implementation form of the first aspect, the path computation module is configured to determine a number of k disjoint paths with lowest connection costs between two VNFs by disregarding any connections that do not have sufficient capacity, normalizing connection capacities of the remaining connections to a single unit of flow, and then routing k units of flow from one of the VNFs to the other, and applying a rounding afterwards if needed.

In this manner, the k disjoint paths with lowest connection costs can be calculated very efficiently.

In a further implementation form of the first aspect, the device is further configured to output to the user of the network slice through an interface, slice information about the network slice and control functions of the slice, the slice information comprising the exact placement and paths connecting the VNFs.

The user of the network slice can thus utilize the network slice in a desired own way.

In a further implementation form of the first aspect, the slice information comprises an overlay graph representing the network slice as an abstraction of the actual placement and paths connecting the VNFs. This enables a user of the network slice to utilize the resources in a way, which is compatible with the slice design. It also enables the user to use novel services, such as fast routing with QoS requirement. A second aspect of the present invention provides a method for providing a minimum-cost network slice, comprising the steps of receiving a network slice request including at least one placement constraint and at least one Quality of Service, QoS constraint, and receiving a capacity of each physical link in the network, modifying real network costs according to congestion, selecting a set of candidate paths based on the capacities of the physical links, and determining, for the set of candidate paths and according to the modified network costs, the optimal placement of Virtual Network Functions, VNFs, on network nodes satisfying the at least one placement constraint, determining, based on the capacities of the physical links, actual paths connecting the placed VNFs so that available network resources are not exceeded and the at least one QoS constraint is satisfied, wherein in the determining of the placement and the determining of the actual paths, at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraint is determined, and determining the implementation of the network slice by determining the placement of the VNFs and their connections so that the overall network costs are minimized and all the constraints are satisfied.

In an implementation form of the second aspect, the determining of the placement is based on network node capacity constraints, the determining of the placement and the determining of the actual paths are repeated iteratively, and the candidate paths are provided based on modified network costs that are updated with each iteration according to the output of at least one previous iteration and the capacity constraints.

In a further implementation form of the second aspect, the at least one QoS constraint comprises a number of additive constraints, e.g. latency.

In a further implementation form of the second aspect, the network slice request further includes a resilience constraint, and the path computation module is configured to determine multiple paths between each two connected VNFs with lowest connection costs according to the resilience constraint.

In a further implementation form of the first aspect, the method further comprises monitoring, periodically or event-based, a resource availability characteristic, particularly a residual node capacity statistic. In a further implementation form of the second aspect, the network costs are modified based on a current resource utilization and a capacity of each physical link.

In a further implementation form of the second aspect, the network costs are modified based on historical data via machine learning techniques.

In a further implementation form of the second aspect, the set of candidate paths are the shortest paths according to the network costs for at least one candidate VNF placement of each VNF.

In a further implementation form of the second aspect, the method further comprises terminating the iterative determinations according to one or more termination criteria, wherein the one or more termination criteria comprise a number of iterations, a time budget and/or a cost difference between two iterations.

In a further implementation form of the second aspect, a number of k disjoint paths with lowest connection costs between two VNFs are determined by disregarding any connections that do not have sufficient capacity, normalizing connection capacities of the remaining connections to a single unit of flow, and then routing k units of flow from one of the VNFs to the other, and applying a rounding afterwards if needed.

In a further implementation form of the second aspect, the method further comprises outputting to the user of the network slice through an interface, slice information about the network slice and control functions of the slice, the slice information comprising the exact placement and paths connecting the VNFs.

In a further implementation form of the second aspect, the slice information comprises an overlay graph representing the network slice as an abstraction of the actual placement and paths connecting the VNFs.

The method of the second aspect and its implementation forms achieve all the advantages and effects of the device of the first aspect and its implementation forms, respectively. A third aspect of the present invention provides a computer program product comprising a program code for performing, when running on a computer, the method according to the second aspect and its implementation forms. Accordingly, the product of the third aspect achieves all advantages and effects of the method of the second aspect.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

Fig. 1 shows a device according to an embodiment of the present invention.

Fig. 2 shows a method according to an embodiment of the present invention and a conventional device.

Fig. 3 shows a generic model including a device according to an embodiment of the present invention.

Fig. 4 shows a device according to an embodiment of the present invention. Fig. 5 shows a performance comparison between a device according to an embodiment of the present invention and a conventional device.

Fig. 6 shows a device according to an embodiment of the present invention.

Fig. 7 shows a flow chart of a method according to an embodiment of the present invention.

Fig. 8 shows a flow chart of a method according to an embodiment of the present invention.

Fig. 9 shows a network slice of four interconnected VNFs.

Fig. 10 shows a flow chart of a method according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Fig. 1 shows a device 100 according to an embodiment of the present invention. The device 100 is configured to provide a minimum-cost network slice. The device 100 may also be referred to as a network orchestrator.

The device 100 comprises an interface 101, which is configured to receive a network slice request 102. The network slice requests 102 includes at least one placement constraint and at least one QoS constraint. The QoS constraint may comprise, for instance, a number of additive constraints, e.g. one or more latency constraints. The network slice request 102 may further include at least one resilience constraint. Via the interface 101, the device 100 is further configured to receive a capacity 107 of each physical link in the network, i.e. capacities 107 of all physical links. For instance, the capacities 107 may be received as an information message and, for example, from a network monitoring unit provided external of the device 100.

The device 100 further comprises a cost modifier module 103, which is configured to modify real network costs c according to congestion. The real network costs may, for instance, relate to a currency, but also to other kinds of costs. Congestion in the network may change, for example, due to changing network traffic over time or due to certain network events, like network node failures or link failures between network nodes. The device 100 further comprises a placement module 104, which is configured to select a set of candidate paths based on the capacities 107 of the physical links, and to determine, for the set of candidate paths and according to the modified costs, the optimal placement of VNFs, on network nodes satisfying the at least one placement constraint. The candidate paths are potential paths that could connect the VNFs.

The device 100 further comprises a connection embedding module 105, which is configured to determine, based on the capacities 107 of the physical links, actual paths to connect the placed VNFs, so that the available network resources are not exceeded and the at least one QoS constraint is satisfied.

It is noted that the VNFs are at the network slice level, and may also be referred to as "virtual nodes". A path connecting two placed VNFs may accordingly be referred to as a "virtual link". At the physical level, the network consists of the (physical) network nodes, which are connected by (physical) links. A path between two VNFs may be defined by one or more sequential links. That is, the interconnection of any two VNFs is realized via a "virtual link" consisting of one or more physical links.

The device 100 further comprises a path computation module 106, which is configured to determine at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraints.

In the device 100, the modules 103-106 are advantageously configured to jointly determine the implementation of the network slice by determining the placement of the VNFs and their connections, i.e. by the paths, so that the overall network costs are minimized and all the constraints are satisfied. As a result, the minimum-cost network slice can be provided by the device 100.

Fig. 2 shows a method 200 according to an embodiment of the present invention, the steps of which correspond to the functions of the device 100 shown in Fig. 1. In particular, the device 100 can advantageously perform the method 200. The method 200 is in particular adapted for providing a minimum-cost network slice, and comprises the following steps. A step 201 of receiving a network slice request 102 including at least one placement constraint and at least one QoS constraint, and receiving a capacity 107 of each physical link in the network. This step 201 may be performed by the interface 101 of the device 100. A step 202 of modifying real network costs according to congestion. This step 202 may be performed by the cost modifier module 103 of the device 100. A step 203 of selecting a set of candidate paths based on the capacities 107 of the physical links, and determining, for the set of candidate paths and according to the modified network costs, the optimal placement of VNFs, on network nodes satisfying the at least one placement constraint. This step 203 may be performed by the placement module 104 of the device 100. A step 204 of determining, based on the capacities 107 of the physical links, actual paths connecting the placed VNFs so that available network resources are not exceeded and the at least one QoS constraint is satisfied. This step 204 may be performed by the connection embedding module 105 of the device 100. The determining steps 204 and 205 of the placement and the actual paths, respectively, include that at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraint is determined. This determination may be performed by the path calculation module 106 of the device 100. Overall, the steps 202-204 (jointly) determine the implementation of the network slice by determining the placement of the VNFs and their connections so that the overall network costs are minimized and all the constraints are satisfied. This step may preferably be performed by the modules 103-106 of the device 100 together (modular joint approach).

Fig. 3 shows a generic model for network slicing, in which the device 100, and respectively the method 200, according to an embodiment of the present invention may advantageously be employed. The model is compliant with ongoing network slicing standardization activities. According to this model, one or more network operators own and operate a physical network 301, and provide services to one enterprise 302 or multiple enterprises 302 (e.g. OTT services, Virtual Network Operators). An enterprise 302 can introduce its own service requirements in an abstract way via an interface 303 (which may be the interface 101 or be connected to the interface 101 of the device 100).

A network slice request 102 of an enterprise 302, which request is a specific resource request 305, can be addressed to the device 100 (which is referred to as network orchestrator in Fig. 3). The device 100 is preferably able to keep an up-to-date view of the current network state, for instance through a network monitoring module 304. Based on the thus obtained physical network image and the network slice request 102 at hand, the device 100 can select, how to create one or more network slices in an optimal way, for example, i.e. with minimum cost and preferably according to specific optimization objectives and constraints.

Following the network slice creation, the network slice is then provided to the enterprise 302, which can apply its own management of the allocated resources (e.g. a flow control, user priorities, and/or QoS routing) via appropriate control functions that are preferably exposed, for instance, to a network slice controller 306. The device 100 provides in summary a network slice with QoS guarantees, which can be further managed by the slice controller 304.

Advantageously, additional signaling/interfaces are defined, namely for the network slice request 102, for the abstraction of the network slice, and for the providing of slice control functions. The signaling/interfaces enable the reception of a network slice request 102, the instantiation of network slices in an optimal cost- sensitive manner, and the management of each network slice having QoS guarantees.

Fig. 4 shows a specific device 100 according to an embodiment of the present invention, which builds on the general device 100 shown in Fig. 1. With respect to the device 100 of Fig. 4, the providing of a network slice with QoS guarantee is now described in more detail.

The first step for the creation of a network slice is the receiving of an issued network slice request 102. As can be seen in Fig. 4, the network slice request 102 (like any other resource request 305) may be received by the device 100 via a signal S.l over the interface 101, for instance, from a network slicing application (NS App) 403 of an enterprise 302. The network slice request 102 includes the at least one placement constraint and QoS constraint. Advantageously, with the network slice request 102, the following parameters may be provided: protection requirement (yes/no), type of protection, latency constraints (yes/no), a latency requirement per VNF interconnection, required resources for each VNF and their interconnections (e.g. as vector (CPU, Storage, BW etc.) or as a predetermined service template), and/or candidate VNF placement locations.

The device 100 also receives via interface 101 (here interface 101 is illustrated as two separate parts of the interface 101) the capacities 107 of the physical links. Via interface 101, the capacities 107, for instance in the form of an information message, are provided to the path computation module 106 and the connection embedding module 105, respectively.

The device 100 is then configured to decompose the problem of network slice providing into at least four functional elements, wherein preferably each functional element is implemented in a different one of the modules 103-106 (the modules are shown both in Fig. 1 and 4). This is referred to as modular joint approach.

M.O in Fig. 4 denotes the function of the cost modifier module 103 introduced in Fig. 1. It is configured to modify real network costs c according to network congestion.

M. l denotes the function of the placement module 104 introduced in Fig. 1. The module 104 is particularly configured to select a set of candidate paths based on the capacities 107 of the physical links, and find, for the set of candidate paths, the best location for each VNF by satisfying the at least one placement constraint in the network slice request 102. Preferably, the module 104 also takes into account the QoS constraint, interconnection costs and/or a resilience constraint. The module 104 may have a sub-module 401 for selecting the (sub) set of candidate paths. M.2 denotes the function of the connection embedding module 105 introduced in Fig. 1. The module 105 is particularly configured to find, based on the capacities 107 of the physical links, the best path or paths to interconnect the placed VNFs, so that the available network resources are not exceeded, and so that the at least one QoS constraint is met. M.3 denotes the function of the path computation module 106 introduced in Fig. 1. The module 106 is configured to determine based on the capacities 107 of the physical links particularly the at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraint. It may also be configured to calculate for resilience purposes k disjoint paths between a source VNF and a destination VNF with the lowest connection costs, and preferably by taking into account also latency constraints.

The four modules 103-106 of the device 100 work together in coordination, in order to find the optimal network slicing solution (i.e. they jointly determine the implementation of the network slice by determining the placement of the VNFs and their connections, so that the overall network costs are minimized and all the constraints are satisfied). This modular joint approach stands in stark contrast to conventional approaches and devices, which either solve the VNF placement problem and connection embedding problem in isolation (this is fast, but far from optimal), or solve these problems in combination (this can provide a good approximation to the optimal, but is in general very slow).

For the coordination of the modules 103-106 of the device 100, two additional signals (shown as the signals S.2a and S.2b in Fig. 4) may advantageously be implemented. In particular, the signal S.2a may correspond to a request for a shortest path with QoS over a modified graph (i.e. modified costs), while the signal S.2b corresponds to shortest paths over the original graph.

The device 100 can provide particularly a more efficient method for solving the optimization problems. In contrast to solving a full-fledged combinatorial problem, which would require extensive time and computational resources, the device 100 by its modular joint approach is up to two orders of magnitude faster than a conventional approach.

The modular design of the device 100 further allows implementing the path computation module 106 by a selected appropriate module, for instance, selected for specific QoS and resilience requirements. For example, if a single path without any QoS constraints is needed, the module 106 can be implemented by Dijsktra (a known algorithm for finding shortest paths between nodes in a graph). If, however, two disjoint paths are needed, the module 106 may be implemented by Suurballe (a known algorithm for finding two disjoint paths in a nonnegatively- weighted directed graph, wherein both paths have minimum total length).

In addition, the different modules 103-106 of the device 100 can potentially be placed on different systems. For example the path computation module 106 could be run by the physical network operator(s) (e.g. as part of a Software Defined Network (SDN) controller), in which case the device 100 does not need to know all the details of the physical network links. However, the modules 103-106 can of course also be placed on one and the same system, e.g. a controller.

In Fig. 4, the connection embedding module 105 is further configured to calculate updated costs, when the placement module 104 and the connection embedding module 105 iteratively repeat their determination of the placement and connecting of the VNFs, and feed the updated costs as signal to the cost modifier module 103 . The network costs are preferably updated with each iteration according to the output of at least one previous iteration and the capacity constraints. Thus, signal S.3 achieves the coordination of VNF placement and connection embedding for the network slice creation through the modification of costs. Through signal S.2a, the path computation module 106 is configured to provide the paths based on the respectively updated network costs.

Further in Fig. 4, also the possibility for slice management after the network slice is provided by the device 100 is shown. In particular, slice management is preferably enabled via a signal S.4, by which the device 100 can provide, to the user of a network slice, that is e.g. to a slice controller 303, slice information about the provided network slice. The slice information may comprise the exact placement and paths connecting the VNFs. The slice information may also comprise an overlay graph representing the network slice as an abstraction of the actual placement and paths connecting the VNFs. That is, the device 100 can provide an overlay abstraction of the physical network. Additionally, the device 100 may provide control signals via the signal S.4, which enable the slice controller 304 to use the reserved resources in a predetermined or flexible way. Thus, the present invention also enables the decomposition of slice creation (providing) and the subsequent slice management. In particular, once the network slice has been provided by the device 100, the slice controller 304 can apply his own control of the reserved resources based on the provided abstraction of the physical network. Whereas conventional slicing paradigms suggest that a slice controller 304 has only an abstract view of the reserved resources (i.e. it has no details on the physical network or the created slice are provided), the device 100 according to an embodiment of the present invention may expose routing information in the form of the overlay graph. This enables the slice controller 304 to utilize the reserved slice resources according to its will but in a way that is compatible with the slice design. It also enables new services, such as fast routing with QoS requirements.

In terms of performance gains, the main advantage of the device 100, and respectively the method 200, according to an embodiment of the present invention is, that it makes a joint decision in optimizing the node and connection (path) embedding. Conventional solutions make resource allocation in a different way, namely by either solving the whole NP-hard combinatorial problem as an ILP optimization problem (which is very slow), or by deciding separately on the VNF placement and the connection embedding (disjoint approach). Any disjoint approach always performs strictly worse in terms of embedding costs than the joint approach of the device 100.

Fig. 5 shows a performance comparison between the device 100 and a disjoint approach in 29 random network slicing problems. On the left-hand side (Fig. 5A), the costs of the approach taken by the device 100, the disjoint approach and an approach that solves the full ILP problem exactly (which is extremely time and memory consuming) are plotted. For a number of cases, the disjoint approach cannot even find a feasible solution to the problem (this is why the respective line stops before the other lines). But even when the disjoint approach does find a solution, the optimality gap compared to the exact calculation approach is very large (up to 45%), while the joint approach taken by device 100 keeps the optimality gap below 5%. This is illustrated on the right-hand side (Fig. 5B).

Several aspects of the device 100, and respectively the method 200, can be implemented in different specific ways, which may depend on the application scenario at hand. In the following, a detailed implementation of the device 100, and respectively the method 200, is described, specifically for the application scenario of a core of a next-generation mobile network. This embodiment is compatible with the Cross Stratum Orchestration approach described in "Mapping Cross Stratum Orchestration (CSO) to the SDN Architecture", Open Network Foundation, Issue 1, March 11, 2016, ONF TR-528.

A schematic representation of a preferred implementation for this application scenario is shown in Fig. 6. In this implementation, a number of datacenters serve as the hosts of VNFs and a transport SDN controller 603 is responsible for the management of the underlying network. In this implementation, the path computation module 106 of the device 100 and the connection embedding module 105 are part of the SDN controller 603. The device 100 shown in Fig. 6 can also make use of standard modules such as a network monitoring unit 604, which is here exemplarily implemented in the SDN controller 603, or a resource monitoring unit 606 exemplarily implemented in a Could Hypervisor 605. Here, the network monitoring unit 604 does not need to provide the capacities 107 of the physical links to the device 100. Monitoring protocols may be used by network monitoring unit 604, in order to keep track of, for instance, the network residual capacity and its characteristics. OpenFlow or a Path Computation Element Protocol (PCEP) can be used by the network monitoring unit 604 to retrieve, periodically or on an event based manner, statistics about the utilization of links. This data may be implicitly exploited by the device 100 to make decisions through modules 105 and 106. Similar functionalities are provided by the resource monitoring unit 606 regarding cloud resources, which may be explicitly exposed to the placement module 104.

The device 100 shown in Fig. 6 at first receives the network slice request 102 for a new slice via the signal S.l, for instance, from a NS APP 403. Indicative ways to perform this network slice request 102 can alternatively be the following:

• Using a formal language (such as NEMO), an enterprise 302 may describe the requested service and service requirements over interface 601. It is then the job of the device 100 to decide, which VNFs are needed to implement this service, and to decide, what are the QoS and resilience requirements, and what are the possible physical nodes on which they can be placed.

• Using predetermined templates describing the VNFs, their interconnections, their potential placements on the physical network and the associated QoS and resilience requirements.

• Using a detailed description of a virtual network topology, the computational and network resources required by each VNF and path, the potential placement of VNFs on physical nodes, and the QoS and resilience requirements.

All in all, given the signal S. l, the device 100 can represent the network slice request 102 as a network of interconnected VNFs (referred to in the following as "virtual network"), along with a tuple, e.g. {latency requirement, Bandwidth requirement, protection type}, for each pair of interconnected VNFs, and a tuple describing the capacity requirements (e.g. storage, processing) of each VNF. Generally, any type of protection supported by the transport SDN controller 603 could be requested. However, an efficient method for the calculation of k disjoint paths with latency constraints is proposed for device 100, and is described further below. The request requirements are denoted for the following with R. For an optimized creation of a network slice, the device 100 is optimally aware about the availability of resources at each datacenter. Such information is typically available at the Cloud Hypervisor 605, and can be provided to the device 100 upon request or periodically. In addition, some information about the network state may need to be exposed to the device 100 by the network monitoring unit 604. All in all, the device 100 preferably has always at its disposal a representation of the physical infrastructure in the form of a network of interconnected datacenters. For each datacenter node, the available resources are preferably represented in the form of a multi-dimensional vector. Each physical network link may be assigned a {latency, bandwidth, costs} tuple. These "costs" represent the metric, over which the device 100 optimizes, and does not necessarily correspond to actual cost. The system state is denoted for the following with S. The network slice creation problem can be seen as a problem of embedding the virtual network (i.e. the connected VNFs) on the physical network (the linked network nodes) so that the at least one QoS constraint is met. Fig. 7 shows a specific method, which builds on the general method 200 shown in Fig. 2. In particular, a flow diagram of this method is shown, and the method can be used by the device 100, in order to determine an optimal network slice. The method depicted in Fig. 7 makes use of the known mathematical tools of Lagrangian relaxation and subgradient optimization. First, the candidate locations for each VNF are determined according to the system state S and the request requirements R. Then, the following sequence of steps is repeated, until convergence, or until a termination criterion (e.g. execution time) has been reached.

Step 1: This step performs uncapacitated VNF placement. That is, capacity constraints are relaxed, and a new simplified graph (which is called VNF graph) is constructed via several calls to the function M.3 implemented by the path computation module 106 (via signal S.2). Each call corresponds to two interconnected VNFs, and returns the minimum-cost (QoS satisfying) path for each pair of candidate locations of VNFs. Then, the optimal placement of each VNF, under no capacity constraints, can be easily calculated, e.g. via a generic Integer Linear Program (ILP) solver. Hence, the above procedure may be run once, and then the capacity constraints are checked. If they are not violated, then the produced solution z(k) is optimal and complete (as it contains both the VNFs embedding locations, and the optimal paths for their interconnections). Otherwise the method proceeds with the connection embedding function M.2. Step 2: This step finds a feasible embedding of connections between the placed VNFs. The solution z(k) obtained above does not satisfy the capacity constraints and is therefore not feasible. A feasible solution can be obtained by "projecting" z(k) to the feasible space. One way to do this is by keeping the VNF embedding in z(k) fixed, and find the optimal associated connection embedding satisfying the capacity constraints. Since this is generally an NP-Hard problem, the method depicted in Fig. 8 may be used. This method solves a fractional min cost multicommodity flow problem, followed by rounding to derive an integral routing solution if needed. For the generation of paths that satisfy multiple QoS constraints, e.g. both reliability and latency constraints, an advanced PCE is needed. Thus, it uses function M.3 implemented by the path computation module 106.

According to the method in Fig. 8, a candidate path is taken, and at first link costs of the path may be modified (as in classical column generation). Then the function M.3 of the path computation module 106 is called on the modified graph. If a better path is found, the above- described procedure is repeated, i.e. the better path serves as new input. If no better path is found and integral paths need to be found, randomized rounding is performed, and the result is output. Column generation and randomized rounding are well-known methods that any skillful person in the field knows how to implement and apply. Step 3: This step updates Lagrange multipliers. Since the capacity constraints have not been yet taken into account, the corresponding Lagrange multipliers need to be updated, so as to penalize any capacity violation. This can be implemented in several ways, e.g., via a subgradient update. Step 4: This step updates costs. The costs are updated so as to take into account the new Lagrange multipliers. The updates of the associated costs c(k) may be performed by function M.O. Function M.2 receives the current solution z(k) by function M.l provided by the placement module 104. Then, in the next iteration, function M. l uses the updated costs c(k+l), in order to calculate minimum cost paths and so on. Through the iterative cost adjustment, the solution to the uncapacitated problem in Step 1 will provide increasingly improved lower bounds to the optimal cost.

The algorithm of the above steps terminates preferably after a number of iterations. A number of different termination criteria can be used, such as the number of iterations, a time budget, or a desired optimality gap between the cost upper bound calculated in Step 2 by the cost of the projection and the cost lower bound calculated by the infeasible solution in Step 1. Combinations of the above criteria can be used as well. Once the network slice has been created (provided) by device 100, an abstract view of the physical infrastructure may be output by the device 100 to the slice controller 304. Depending on the level of abstraction, a different set of management functions can thereby be supported. This bidirectional type of information exchange (abstraction and control) may be implemented in compliance with the Application-Layer Traffic Optimization (ALTO) Protocol over an interface 602. Together with the interface 601 for receiving resource requests, like the network slice request 102 (e.g. NEMO), the interface 602 may compose the interface 101 of the device 100.

In the simplest case, the full detail of physical network (only regarding the resources allocated to the slice) may be exposed by the device 100 to the slice controller 304. In this case, the latter can apply any traditional network management protocol, as if the reserved resources were a real isolated physical network.

At the other extreme, an abstraction at the level of Virtual Network could be exposed by the device 100 to the slice controller 304. In this case, the slice controller 304 is only aware of the network characteristics (e.g. latency, bandwidth) at "virtual connection" (path) level and resource allocation decisions, such as ensuring the agreed level of protection, are automatically handled by the device 100 in a predetermined way. In order to illustrate this new concept, a novel type of service, namely "Ultra-fast routing with protection & latency guarantees within a slice" is described.

For example, the slice shown in Fig. 9 may be considered, which may have specific characteristics (e.g. 1+1 protection with 5ms latency). All VNF connections are identical and are protected via the dashed paths. The primary connections (paths) are denoted with black solid lines, and the device 100 may expose to the slice controller 304 just a simple overlay view of the primary topology, in which the capacity of each virtual link (path) is set equal to the minimum of its primary and backup path capacity, and its latency equal to the maximum of the corresponding latencies. A new bandwidth reservation request may arise from A to C of 50 Mbps and latency requirement 10ms. Through a fast route calculation (e.g. a simple Dijkstra on the slice abstraction), the path A-B->C is found, and its protection via the corresponding dashed paths is predetermined. Thus, a significantly faster routing within the network slice of Fig. 9 can be achieved. Notably, the alternative would be to find 2 disjoint paths with latency guarantees from A->C on the physical network graph.

The main advantage of this approach is that the slice controller 304 operates on a simple overlay graph (solid black). The device 100 can automatically translate this into protection paths with QoS guarantees. Without the device 100, the protection of this path would have to be calculated, which is generally much more complex and time consuming.

Notably, one main component of the device 100 according to the present invention is the path computation module 106, which is able to implement an efficient method for the above described calculation of k disjoint paths with latency constraints. The main idea implemented here by the path computation module is illustrated by the flow-diagram of Fig. 10. A first step is to prune links that cannot be part of the solution for finding the paths between two VNFs because their capacity is lower than the demand of the flow to be routed. A second step scales down all link capacities so that each fits a single unit of flow. Then, an optimal fractional solution can be found. To this end, k units of flow are routed from the source VNF to the destination VNF. This can be efficiently done by the delay-constrained column generation shown in Fig. 8. If k disjoint paths are found, the method outputs these. If not, then the fractional solution is rounded to derive k disjoint paths. The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. Device (100) for providing a minimum-cost network slice, comprising:

an interface (101) configured to receive a network slice request (102) including at least one placement constraint and at least one Quality of Service, QoS, constraint, and configured to receive a capacity (107) of each physical link in the network,

a cost modifier module (103) configured to modify real network costs according to congestion,

a placement module (104) configured to select a set of candidate paths based on the capacities (107) of the physical links, and to determine, for the set of candidate paths and according to the modified costs, the optimal placement of Virtual Network Functions, VNFs, on network nodes satisfying the at least one placement constraint,

a connection embedding module (105) configured to determine, based on the capacities (107) of the physical links, actual paths to connect the placed VNFs so that the available network resources are not exceeded and the at least one QoS constraint is satisfied, and

a path computation module (106) configured to determine at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraints,

wherein the modules (103-106) are configured to jointly determine the implementation of the network slice by determining the placement of the VNFs and their connections so that the overall network costs are minimized and all the constraints are satisfied.

2. Device (100) according to claim 1, wherein

the at least one QoS constraint comprises a number of additive constraints, e.g. latency.

3. Device (100) according to claim 1 or 2, wherein

the network slice request (102) further includes a resilience constraint, and

the path computation module (106) is configured to determine multiple paths between each two connected VNFs with lowest connection costs according to the resilience constraint.

4. Device (100) according to one of claims 1 to 3, wherein

the placement module (104) is further configured to determine the placement based on network node capacity constraints.

5. Device (100) according to one of claims 1 to 4, further comprising:

a resource monitoring unit (605, 606) configured to monitor, periodically or event- based, a resource availability characteristic, particularly a residual node capacity statistic.

6. Device (100) according to one of claims 1 to 5, wherein

the cost modifier module (103) is configured to modify the network costs based on a current resource utilization and the capacity of each physical link.

7. Device (100) according to one of claims 1 to 5, wherein

the cost modifier module (103) is configured to modify the network costs based on historical data via machine learning techniques.

8. Device (100) according to one of claims 1 to 7, wherein

the set of candidate paths used by the placement module (104) are the shortest paths according to the modified network costs for at least one candidate VNF placement of each VNF.

9. Device (100) according to one of claims 4 to 8, wherein

the placement module (104) and the connection embedding module (105) are respectively configured to iteratively repeat the determination of the placement and the determination of the actual paths, and

the path computation module (106) is asked to provide the candidate paths based on modified network costs that are updated with each iteration according to the output of at least one previous iteration and the capacity constraints.

10. Device (100) according to claim 9, configured to:

terminate the iterative determinations according to one or more termination criteria, wherein the one or more termination criteria comprise a number of iterations, a time budget and/or a cost difference between two iterations.

11. Device (100) according to one of claims 1 to 10, wherein

the path computation module (106) is configured to determine a number of k disjoint paths with lowest connection costs between two VNFs by

disregarding any connections that do not have sufficient capacity, normalizing connection capacities of the remaining connections to a single unit of flow, and then

routing k units of flow from one of the VNFs to the other, and

applying a rounding afterwards if needed.

12. Device (100) according to one of claims 1 to 11, further configured to:

output to the user of the network slice through an interface (101), slice information about the network slice and control functions of the slice, the slice information comprising the exact placement and paths connecting the VNFs.

13. Device (100) according to claim 12, wherein

the slice information comprises an overlay graph representing the network slice as an abstraction of the actual placement and paths connecting the VNFs. 14. Method (200) for providing a minimum-cost network slice, comprising the steps of receiving (201) a network slice request (102) including at least one placement constraint and at least one Quality of Service, QoS constraint, and receiving a capacity (107) of each physical link in the network,

modifying (202) real network costs according to congestion,

selecting a set of candidate paths based on the capacities (107) of the physical links, and determining (203), for the set of candidate paths and according to the modified network costs, the optimal placement of Virtual Network Functions, VNFs, on network nodes satisfying the at least one placement constraint,

determining (204), based on the capacities (107) of the physical links, actual paths connecting the placed VNFs so that available network resources are not exceeded and the at least one QoS constraint is satisfied,

wherein in the determining (203) of the placement and the determining (204) of the actual paths, at least one minimum-cost path between two connected VNFs satisfying the at least one QoS constraint is determined, and

wherein the steps (202-204) determine the implementation of the network slice by determining the placement of the VNFs and their connections so that the overall network costs are minimized and all the constraints are satisfied.

Method (200) according to claim 14, wherein the determining (203) of the placement is based on network node capacity constraints, the determining (203) of the placement and the determining (204) of the actual paths are repeated iteratively, and

the candidate paths are provided based on modified network costs that are updated with each iteration according to the output of at least one previous iteration and the capacity constraints.

16. Computer program product comprising a program code for performing, when running on a computer, the method (200) according to claim 14 or 15.