WO2016150511A1

WO2016150511A1 - Device and method for allocating communication resources in a system employing network slicing

Info

Publication number: WO2016150511A1
Application number: PCT/EP2015/056519
Authority: WO
Inventors: Amine Mohamed Houyou; Andreas Fischer; Waseem MANDARAWI; Hermann De Meer; Hans-Peter Huth
Original assignee: Siemens Aktiengesellschaft
Priority date: 2015-03-26
Filing date: 2015-03-26
Publication date: 2016-09-29

Abstract

The invention relates to a device for allocating communication resources of a communication network to a plurality of applications, each application having a requirement for a set of communication resources, said device comprising an interface for receiving at least a first request for a set of communication resources and an interface for transmitting information for allocating communication resources to at least one of the requests taking into consideration at least one rank, in which the request is categorized.

Description

DEVICE AND METHOD FOR ALLOCATING COMMUNICATION RESOURCES IN A SYSTEM EMPLPOYING NETWORK SLICING

Field of the Invention

The invention relates to a device and a method for allocating communication resources of communication network to a plurality of applications.

Background

Many networks, in particular in the industrial context, re^¬ quire a predictable operation with tight timings and high re^¬ liability.

For example, in automation systems, safety-critical, deter^¬ ministic and real-time applications, e.g. the control of a conveyer belt for transporting a work piece, share the same communication network with other non real-time-critical applications .

In order to accommodate the needs of all applications, cur^¬ rent network technology for automation systems rely mostly on over-dimensioning and a detailed engineering and planning of network resources.

It is one object of the invention to offer a possibility to assign a right portion of the available network resources to an application and further to optimize the distribution of the network resources.

Brief Summary of the Invention

This is solved by what is disclosed in the independent claims . Advantageous embodiments are subject of the dependent claims . The invention relates to a device for allocating communica^¬ tion resources, e.g. bandwidth, available in a real or physi^¬ cal or substrate communication network to a plurality, i.e. two or more, of applications. Each application has a require- ment for a set of communication resources, e.g. a certain ar^¬ rangement of minimum/maximum bandwidth. The device comprises, i.e. has an integrated or is connectable to, an interface for receiving at least a first request for a set of communication resources. Via an interface information for allocating commu- nication resources to the at least one request is generated taking into consideration a rank assigned to the request can be transmitted. This allows assigning resources to an appli^¬ cation, such that the demands are satisfied, in particular taking into account a certain needed priority associated with the assigned rank.

In particular the device further comprises a processing unit which forms part of the device or is connectable to the de^¬ vice which is arranged such that the request is categorized in at least two ranks. Information for allocating communica^¬ tion resources to the at least one request is generated tak^¬ ing into consideration the rank.

According to an advantageous embodiment the physical set-up of the communication network is known to the device. This al^¬ lows the mapping of the requested set of communication re^¬ sources or slice on the physical network.

According to an advantageous embodiment the request for a set of communication resources or slice request comprises an overlay link or description of a connection between a source node and destination node, which requires a subset, i.e. all or less, of the required resources. Splitting the request in^¬ to its details allows for easier implementation on the physi- cal communication network.

According to a further advantageous embodiment the generated information specifies at least one physical path for an over- lay link. By providing more physical paths switching between different paths is facilitated which may be necessary due to new request or changing physical or substrate network. This further reduces the risk of failures.

According to another embodiment one or more requests are re^¬ ceived at the device at the same time or one after the other or/and not correlated to each other. The allocation of re^¬ sources according to the requests is adapted due to the re- spective ranks of the individual requests. This allows e.g. in the case of simultaneous requests, to embed the request first, which has the highest rank, e.g. is the most important one. Advantageously therefore also an order may be indicated in the generated information. In the case of a request arriv- ing, when the communication resources asked for in a previous request are already allocated, this allows for adaptive changing according to actual requirements and thus having the communication network operating such that as many as possible slices are embedded or/and the correct functioning of the ap- plications regarded as most important is ensured.

According to an advantageous embodiment the rank or priority parameter may be determined by considering a type of the ap^¬ plication or/and a required degree of reliability of the transmission for the application or/and a degree of importance of the application. In particular the type of appli^¬ cation may be mandatory and the degrees of reliability or/and importance may be optional. By considering this factors a ranking can be established that satisfies requirements of a resource efficient and effective network functioning.

According to another embodiment the request for the set of network resources specifies a minimum bandwidth or/and a max^¬ imum bandwidth or/and an average bandwidth or/and a maximum allowed delay or/and a maximum allowed jitter or/and a re^¬ quired security of the application. According to a further embodiment the device is formed by a controller. In particular the functions of the controller may be distributed across several entities or localities in the network .

The invention further relates to a corresponding method and a computer program.

Brief description of the drawings :

Further embodiments, features, and advantages of the present invention will become apparent from the subsequent descrip^¬ tion and dependent claims, taken in conjunction with the accompanying drawings of which show:

Fig. 1: An overlay network with full mesh connectivity;

Fig. 2: A publish-subscribe overlay with the logical rendez^¬ vous points depicting subscription relationships;

Fig. 3: An overlay link between two nodes and

Fig. 4: A flow diagram of implementing slices on a physical or substrate network.

For ensuring that each application in a network is treated according to its communication requirements, separation of their traffic in virtual ( sub) -networks associated with a portion of the network resources is adopted. This approach is called in this application network slicing, where each slice of the real or physical network is deployed to meet the re^¬ quirements of the application it connects.

The embodiments below refer to of how to associate the right portion of network resources to each slice, and how to opti^¬ mize the embedding of as many slices as possible while ac^¬ counting for the finiteness of network resources. Network slices should -as far as possible in regard to the constraints implied e.g. by other applications or the physi^¬ cal substrate network- consider as many application requirements as possible, while making sure that the most critical application flows are protected, guaranteed and best treated in the network. In order to address these problems without over-dimensioning or detailed engineering of the network, embodiments are described, which offer an autonomic slice con^¬ figuration mechanism capable of embedding slices into the network.

Therefore applications are separated in their respective vir^¬ tual network or slice, which can be deployed in the physical network. Each virtual network can be dimensioned in terms of network resources, such as bandwidth, and behavior to best match the requirements of the application. The shared physi^¬ cal network, where the virtual network or slice is deployed or embedded has to fulfill the requirements of several in^¬ stances of such virtual networks simultaneously, as a plural- ity, i.e. two or more applications are running.

The virtual network deployment or embedding is controlled by a centralized instance or controller that is able to allocate managed physical resources among multiple instances of virtu- al networks. As the deployment of each virtual network in^¬ stance is decided and defined by the controller, the control^¬ ler has to define a strategy of allocating resources, network paths among multiple instances of virtual networks. For doing so, the requirements of applications have to be in^¬ terpreted, which can be then automatically mapped to the real or physical network resources. This mapping or embedding has to calculate the ideal route or path mapping each connection of the application, while fulfilling other requirements and demands described by a slice request. The other optimization goal of the mapping or embedding procedure has to be the ability to fulfill as many slice requests as possible and therefore populate the real network with as many slices as possible while being able to prioritize and differentiate be^¬ tween slices and their respective resources.

Such an admission control is adapted to suit the needs for automation systems allowing many applications to coexist in the same physical network (e.g. factory automation processes, SCADA (supervisory control and data acquisition) and maintenance applications, logistics and enterprise data collectors, etc.) . The expected correct behavior of the whole communica- tion system should be guaranteed by the admission mechanism.

As said before, current network technology for automation systems rely mostly on over-dimensioning and a detailed engi^¬ neering and planning of network resources. With help of the embodiments described below, the requirements of determinis^¬ tic applications such as control processes can be guaranteed despite unexpected peaks introduced through bursty applica^¬ tions. The network can reduce the effect of the bursts by classifying traffic and using some scheduling mechanism to prioritize traffic in network nodes. In the case of industri^¬ al Ethernet a reservation mechanism combines priorities and special real-time schedulers in order to treat marked traffic according to the class it belongs to. Depending on the type of scheduling used, the treatment of the traffic can approach the required behavior as much as possible, despite the varia^¬ tions imposed by cross traffic which can lead to congestions, jitter, etc. Such effects of packet-based networks are hard to control without some limiting of the cross traffic or mak^¬ ing sure of having some time-division access control sched- ulers everywhere.

By applying the proposed improvements, existing disad^¬ vantages, such as e.g. for TDMA (time division multiple ac^¬ cess) based industrial Ethernet can be overcome: E.g. for Profinet IRT (isochronous real-time) deterministic real-time channels are available for controller-based communication to reserve a given capacity in the network. The network is very rigid and any changes could lead to the loss of the optimiza- tion goals. Also there is no mechanism to cater for other less deterministic applications whose QoS (Quality of Ser^¬ vice) demands can be retrieved. However, not all QoS sensi^¬ tive applications need to use the rather limited IRT channels or classify their traffic as "high priority". Therefore the embodiments enclose a classification or ranking with a finer granularity of applications needs or requirements, which takes into account of interdependencies of how and when to satisfy which need.

Examples of such requirements are related to a single appli^¬ cation flow, such as reliability, quality of service, securi^¬ ty, etc. Other examples of requirements can affect the whole network as such and result from the desired system behavior as a whole: Such examples are, protecting all production sys^¬ tems against failures or interruptions, prohibiting eaves^¬ dropping and protecting against denial of service, energy ef^¬ ficient use of network infrastructure, avoiding of over- dimensioning of the network.

Networking requirements of an application instance, e.g. a client-server communication, group communication, P2P communication, transfer of messages via buses, may be described according to the overlay connecting its hosting application end-points. Such an overlay is then seen as a separate net^¬ work, whose qualities and behavior could be summarized in what is called here a slice request. A slice request defines the kind of overlay network describing the interactions of the application and the qualities and different attributes this network has to fulfill.

Besides the list of end-devices members of a slice, an over^¬ lay graph is defined in the slice request, where each link between two overlay nodes is described or, in other words, an overlay link between a source node and a destination node, is defined in the slice request. Not all nodes need to be con^¬ nected with each other, leading to a variation of overlay graphs which describe the way the application interacts with its end-points.

In particular, an overlay link is between two end-nodes, a physical link is between two physical nodes, including end- nodes and intermediate networking nodes.

Mapping an overlay link to a physical network, means in particular selecting one or k-paths between the end-nodes. A path is in particular a concatenation of several links and intermediate nodes that all fulfill the overlay link resource demands .

For example, in the case of server-client applications, serv- ers have a single overlay link to each client, while clients do not require an overlay link to each server.

According to another embodiment, which is depicted in Fig.l, each node N has one overlay link, depicted as a solid line, to each other node part of the slice, which is also called full mesh connectivity.

According to another embodiment, which is depicted in Fig. 2, connectivity between a group or subset of the nodes N forming overlay end-points to some imaginary middle points MP is es^¬ tablished. This kind of topology would apply to applications relying on publish/subscribe interactions, for example, where each end-point is both publisher and subscriber at the same time. The imaginary middle points MP symbolize the subscrip- tion between these end-points, which could be deployed in the network as a message bus or multicast group. E.g. an event is published by an node N and sent to a middle point MP, which again distributes it so a set of further nodes, thus acts as a broker.

A message bus is understood as a logical component to connect different applications and specializes in transporting mes^¬ sages between applications. A multicast group is understood as a group where there is a message transfer between a point to a group.

According to another embodiment, which is depicted in Fig. 3, an overlay definition just defines a single overlay link be^¬ tween two end-nodes N, a source node and a destination node.

In terms of resource requirements, the slice request or re^¬ quest for a separate network with defined qualities and be- havior could be classified as a whole without distinguishing the requirements of each single overlay link. Three types of classes, which will be called slice classes in the applica^¬ tion, are outlined below for supporting the Quality of Service (QoS) demands of communication in Production Systems. These slice classes describe a type of the application and can be used to establish a rank of the respective request for network resources:

Class #1: 'Available Resource Service' (ARS)

The ARS slice class offers no guarantees and will use whatev^¬ er bandwidth is available. It mimics the behaviour of stand^¬ ard non-QoS Ethernet. In particular this means that the full physical bandwidth may be used as far as it is not allocated for other slices. There are no user definable parameters and no traffic specification is needed. Therefore no space is provided in the relevant request.

In an application view, i.e. a view where a relation between talkers and listeners in respect to an application is depict- ed, the slice request includes only a list of slice members.

System-wide policies on a minimum available bandwidth may still exist to ensure optimal operation and best resource utilization. For example, a system administrator may decide to ensure a minimum of 500 Kbps and a maximum of 1 Mbps per ARS slice. Such policies will affect the network resources that can be assigned to other classes on the respective paths . The ARS type of service is limited to the slice participants and spans the underlying substrate network to connect each slice member (end point of this slice) . As one important predefined instance of the ARS slice class is the 'Configuration Slice'. Though having limited network bandwidth, it offers a gradual connectivity to management points within the network, made available through a boot se^¬ quence. Within this slice, spanning tree protocol could be used to guarantee loop-free communication.

Class #2: 'Controlled Service' (CS)

The CS slice class allows the specification of QoS, reliabil^¬ ity, and security requirements on the slice or virtual net- work, such as upper and lower bounds for the bandwidth available to a single end point.

The upper boundary is checked by a controller or and - if validated - packets are dropped or delayed. The lower bound shall be guaranteed under all circumstances. Both bandwidth specifications are defined as averages over a certain time window which is to be defined; consequently single packets will use physical wire speed. Another user definable parameter is a 'High Importance' flag that, if set, will make this slice highly resilient.

An optional parameter is the 'Average Bandwidth' which can be specified to allow an optimal resource usage. If not given, the slice resource management will assume 'minimum bandwidth' == 'average bandwidth'. An extended traffic specification al^¬ lowing better planning and optimization is for further study.

Class #3_DELAY: 'Minimum Delay Service' (MDS)

The MDS slice class allows the mapping of hard real time re- quirements to a slice. It is essentially a Controlled Service plus guaranteed maximum delay and jitter. In the table below, slice definition attributes and their plicability for the above introduced classes are described These can be extracted from the service descriptions:

Slice Slice Request Parameter Set Avai^¬ ConMini¬

Request lable trol^¬ mum

AttriRe^¬ led Delay bute source SerSer¬

Service vice vice

(ARS) (CS) (MDS)

SimpliThe overlay network (as op^¬ X X X fied posed to the physical or sub^¬ traffic strate network) describes the

matrix type of connectivity required

between any two end-nodes

part of the slice. The over^¬ lay network consists of links

between end-nodes. The over^¬ lay network graph can be

structured, fully meshed, or

star like.

In the case of CS and MDS

slice requests, the traffic

matrix summarizes the band^¬ width demand and direction of

this demand along each overlay link.

The simplest case applies the

same bandwidth and other link

conditions to all overlay

links equally. The more com^¬ plex case could define min BW

demands per overlay link sep^¬ arately.

Minimum The minimum required band^¬ - X X

Band^¬ width (minBW) of the slice

width overlay is according to one

demand embodiment defined for the (minBW) | whole slice, i.e. each over^¬ lay link has to fulfill a bi^¬ directional minBW. Alterna^¬ tively, the slice request could also define minBW per overlay link separately.

The minBW is a value origi^¬ nates from the knowledge of the application traffic re^¬ quirements. The following ap^¬ plication characteristics are distinguished :

1) A cyclic controller commu^¬ nication defines code words per cycle time. The minBW is defined according to the number of periphery devices communicating in cyclic manner with the controller.

2) Default estimates e.g. 200Kbps per TCP (transmission control protocol flow) or UDP (user datagram protocol) flow, publish-subscribe rela^¬ tion between any two service instances .

3) If a maximum delay max_delay requirement is known, this can be used to deduce minimum required band^¬ width minBW, which can be compared with estimates from (1) and (2) , namely the re^¬ lation between delay and bandwidth: minBW >> MTU/max_delay, where a maxi^¬ mum transfer unit (MTU) size is 1500Bytes for Ethernet. 4) In case a reliability lev^¬ el = "No-Loss" (see below re^¬ liability attributes) , add a

bandwidth margin to avoid

congestion or loss through

buffer overflow.

Maximum A maximum bandwidth is alloX X X

Band^¬ cated to each slice. The

width slice request does not indi^¬ per cate any bandwidth upper

Slice bound. This upper bound is

assigned by the slice manager

automatically, and is at

least equal to the minimum

bandwidth plus some margin.

Relia^¬ No Loss: near zero packet - X X bility loss in case of failure sce^¬

Levels narios such as:

(No- -failed link/node

Loss, -bit error/channel error

High, -congestion/buffer overflow.

Non- High reliability: lit^¬ speci^¬ tle packet loss tolerated at

fied) link or network layer for

above scenarios. Requires

some L2/L3 resilience

measures such as HSR (High

Availability Seamless Redun^¬ dancy) or Rapid Ring Protec^¬ tion Protocol.

Non-Specified: does not ex^¬ pect any additional measures

to insure resilience against

loss besides relying on the

slice system ability to self- heal, e.g. to calculate a new

physical path should certain

physical paths become una- vailable .

App1i- This should be part of the

cation description of the applica^¬ X X

Type & tion name or flow type. The

Imporlist is not limited and can - tance be extended by the user or

operator :

-Production related

-Safety critical

-Cyclic Control

-Asynchronous control

Video

-Voice

-Just data

The association of each application type with some priority class could be part of

a system-wide policy, where

each application type named

above is linked to an im^¬ portance level:

"Very high importance" refers

to safety critical and pro^¬ duction critical applica^¬ tions .

"High" are control systems

which do not affect safety,

do not affect the production

either due to redundancy,

modularity, etc. Monitoring

services whose data are fed

in the production system to

control system load for example .

"Not specified": unless de^¬ fined through a system-wide

policy, any other application

(MES, ERP, Video, Software updates, etc.) can be ser^¬ viced last, or if the network

is overloaded, the ARS slice

request can be postponed.

maxDelay Is indicated by the applica^¬ X tion programmer as a value

that cannot be exceeded for

the correct functioning of a

given service interaction.

maxJit^¬ Should be declared by the ap^¬ X ter plication programmer. It

could be specified per over^¬ lay link individually.

In the following embodiments are described, where there are several requests which need to be embedded. In this context a resource constrained routing procedure is used.

Bandwidth is the resource which is managed in the slice sys^¬ tem. All other timeliness or real-time behaviour is all linked to how much bandwidth is allocated to a certain flow and with which guarantee. The bandwidth guarantee has to be ensured along every single portion of the substrate network (i.e. each link and hop) . Otherwise, the link that does not reach the required bandwidth is called a bottleneck and can cause delays. The overlay embedding procedure is a search for shortest path routes that fulfil the same end-to-end band- width demand per overlay link.

The slice manager keeps an overview of the topology and the resources and characteristics of the substrate network. The table below summarizes both the required network characteris- tics and the consequence on the search method for substrate routes. The focus on fulfilling the overlay needs in terms of bandwidth and connectivity are addressed first. In table 2 below for the slice request attributes the source allocation per node or path and implications on

decision/search procedure is described.

Slice Re^¬

Resource Allocation per Implication on Deciquest At^¬ Node or Path sion/Search Procedures tribute

Traffic The overlay describes Select substrate routes matrix the type of connectivity that can host the highest required between any two number of overlay links of end-nodes part of the the same slice. slice. The traffic ma^¬ Use multicast communication trix summarizes the when possible.

bandwidth demand and di^¬ Use shortest available rection of this demand paths first.

along each overlay link. Meet all requirements of According to a simple controlled service (CS) and embodiment the same minimum delay service (MDS) bandwidth to all overlay slice requests, while se^¬ links is applied equal^¬ lecting shortest path.

ly. According to more

complex embodiments QoS

demands per overlay link

are defined separately.

minBW (for Traffic Control can be Each substrate interface sending TX used to define a minimum and link can be included in /receiving or maximum bandwidth. the mapping of a slice if RX) Network calculus methods all links supply at least could be used, i.e. the required minimum band^¬ methods for analyzing a width minBW and all interperformance guarantee in faces have at least minBW the network. available resources. All interfaces are able to han^¬ dle data streams at a band^¬ width equal or larger than the minimum bandwidth. maxBW The slice manager asso^¬ The maximum bandwidth maxBW ciates the maximum band^¬ is calculated according to width maxBW with polica heuristic:

ing the traffic peak al^¬ The total allocated band^¬ lowed per slice. The width allocated BW cannot maximum bandwidth could exceed 90% of the overall be part of a security bandwidth or full capacity policy, e.g., an availa^¬ Tot BW per interface or per ble resource request link .

(ARS) slice only re^¬ maxBW ≥ minBW; maxBW < ceives in general maxi^¬ tot BW * 90% - allocated BW mum 1Mbps per overlay

link. In the absence of

policies, the maxBW is

calculated on the fly,

i.e. there is no policy

but the calculation

takes place if neces^¬ sary, to distribute the

available total band^¬ width among slices

equally, given that the

slice minBW has been

guaranteed for con^¬ trolled service (CS) and

minimum delay (MDS)

slices .

work nodes) : has a ser^¬ vice curve associated

with the scheduler

strategy defined in the

AVB (audio video bridging

standard) .

IR ( isochronous real

time) : along each interface, two service curves

need to be defined. One

for deterministic syn^¬ chronous communication

channels, and the re^¬ maining best effort

Ethernet channels.

Table -1 CS and MDS Parameter Interpretation and Implications on mapping Strategies

Below slice prioritization and admission control is further described: The slice requests or definitions are received by the slice manager. The sequence in which slice requests are dealt with is the reason why prioritization and admission controls are needed. This part of the procedure precedes the constrained routing procedure explained above and applies al^¬ so to the following cases:

a) Embedding several slice requests received at the same time at the slice manager, where a priority or order needs to be calculated .

b) Embedding an additional slice request, in a substrate where other slices already exist.

c) Dealing with changes within a given slice and its conse^¬ quence on other deployed slices.

d) Dealing with changes of the substrate network like exten^¬ sion of the network, link/node failures.

The slice manager tries to fulfill as many slice requests as possible. The optimal prioritization strategy has to provide answers to the following questions: In which order should slices be embedded?

Can the resource allocated to an already embedded slice be changed because of a request from another slice? How does the slice manager deal with failure scenarios?

The rank or priority parameter assigned by the slice manager is a function of

(1) the slice class (MDS, CS, and ARS) ,

(2) the reliability level, and

(3) the importance level attributes of the slice request.

The proposed method to capture this priority function is as follows :

SliceOrder = classValue * importanceValue * reliabilityValue ; wherein

ClassValue: refers to the QoS class of the slice (ARS:1, CS : 10, MDS : 100) .

importanceValue: refers to the importance of the slice (low: 1, high: 10) .

sliceReliability : refers to the required reliability level of the slice (Normal :1, High:10, No-Loss : 100 ) .

Note for the three values and the calculated order, a higher value means a higher priority of the slice. A sorted map or list is used to order the slices. If two slices have the same calculated order, the order is increased by one until a dis^¬ tinct order is found. E.g. the ClassValue is increased by 1 or depending on the parameters therein. The equal slices are served then according to the order of arrival of the specific request. The range of values in the previous example (1, 10, 100) allows for 9 slices of the same calculated order to be mapped correctly. By changing the values we can support a larger number of equal slices. In particular, the rank is used for mapping several slice requests that are received or known simultaneously. Alternatively or additionally, if a slice request arrives later, the rank alone is not decisive but also the application type, importance and reliability are considered in order to remove resources or change an existing slice to service a higher ranked newly arrived slice request.

In Table 3 below the resource allocation and implications on the decision/search procedure is described for the above en- tities class value, importance value and reliability value:

Slice Re^¬

Resource Allocation Implication on Deciquest At^¬ per Node or Path sion/Search Procedures tribute

Class value Not applicable The slice manager should assigned to always try to embed CS and Slice Class MDS slices if the availa^¬ (MDS, CS, ARS) ble bandwidth allows this.

Otherwise the maximum Bandwidth maxBW allocated to other slices could be reduced to provide the bandwidth for a new slice. The maximum bandwidth values maxBW of ARS slices are reduced first.

ARS slices can be even re^¬ moved from the system if not enough bandwidth is available .

CS could be reduced to minBW or removed if they are not "important" enough, i.e. the importance parameter is to low .

Reliability K-path procedures, No-Loss: link protection Levels (No- i.e. procedures that procedure with at least Loss, High, select a plurality of one redundant path. There^¬ Non- possible paths out of fore the minimum bandwidth specified) all paths, could se^¬ guarantee per link is in^¬ lect multiple paths creased and very fast re- that fulfil the same covery mechanisms or packconditions simultane^¬ et duplication if supportously. ed are used. Further, only

Links can be catego^¬ wired links or high resil^¬ rized according to ience wireless links are their reliability lev^¬ used. In order to avoid el: congestion, the total al^¬

To different located bandwidth per link links/nodes various to avoid congestion may be reliability level are reduced .

assigned : High: Link protection with wireless: least fast switch over time,

Ethernet: high i.e. the time until the

Industrial Ethernet, change from one physical or Ethernet with link path to another is perprotection protocol, formed is short. Further packet duplication the minimum bandwidth along two separate guarantee per link may be paths: highest reduced and any link may

Fail-over mechanisms be used.

can be categorized ac^¬ Normal: no specific condi^¬ cording to available tions on selected links. technology or proto^¬ col :

Locally-triggered link

protection protocol

with fail-over mechanisms

Guaranteed failover- time

Congestion (which may

be a cause for fail^¬ ure) probability high-

"c: -L ·

load per node (corre^¬ lating with number of

slices) higher

allocated BW (closer to Tot BW)

Importance Importance has no re^¬ Very-high: always serve (Very high, quirement on single first; do not remove in high, non- nodes or paths. case of change during op^¬ specified) eration except in case of failure, inform applica^¬ tion.

High: in case of contention, serve after very- high, avoid re-routing except in cases of failure

In table 2 possible influences of importance and reliability on the route selection and admission priority are set out. The advantage of the above described embodiments lies in re^¬ solving a multi-dimensional optimization problem when mapping multiple type of application requirements to the network.

The network slice system is capable of configuring real net- working devices and embedding network slices in the network substrate. The network slice manager implements the virtual network embedding procedure which has been detailed above.

The latter procedure aims at resolving contention during the whole life-cycle of automation system, thus that an applica- tion configuration may be adapted such that new application flows may be admitted and adaptations and errors can be han^¬ dled. The same rules allow prioritizing the requested commu^¬ nication services and guaranteeing a correct deployment of networks. The result is a correctly configured network that corresponds to a correctly configured automation system, e.g. industrial automation system. This configuration effort can now occur autonomously and without manual configuration nor over-dimensioning of the network, e.g. no additional wires for specific applications like safety have to be used. Further, a multi-dimensional optimization problem by structuring optimization goals into different steps and defining inter-dependencies between the different optimization goals can be solved.

Also, system correctness through rules and policies behind the virtual network embedding procedure can be achieved.

This offers the possibility to develop an industrial optimi- zation procedure for any type of SDN (software defined net^¬ work) solution.

According to a further embodiment, the used link mapping procedure utilizes the k-shortest paths approach. The procedure first reads the substrate network and slices from input files, then converts them to a network stack or memory available in the network. The slices are sorted using the afore^¬ mentioned methodology before the mapping is performed. The link mapping procedure runs for each slice. For each link in the slice, the procedure finds k shortest paths between the source and destination nodes of this link. The path is a set of substrate links. Each path is then verified for all the demands of the slice link such as bandwidth capacity. The verification ensures that each substrate link in the path can satisfy all the demands of the slice link by checking, for example, if each substrate link has enough residual bandwidth capacity for mapping the slice link. If an appropriate path is found, the slice link is mapped on^¬ to this path. Then the resource capacities in the mapped sub^¬ strate links are updated. If no suitable path is found, the mapping is considered to be failed. If all slices are suc^¬ cessfully mapped, the results (mapped substrate links for each slice link) are then written to the output file.

This is depicted also in Fig. 4 which shows a flow diagram of an embodiment of the procedure. In a first step 1 information about the physical substrate network and the existing slice requests is gathered. Then, in a second step 2 the slices are sorted according to their rank or priority. In a step 3 a mapping of the slices takes place. For that it is investigat- ed in a step 3.1 whether the stack contains more than one slice request. If there is only one slice request, then, in a step 4, information is generated about how the slice is to be mapped on the physical network or/and resources are allocated for that slice.

If there is more than one slice request, then a overlay link mapping takes place in a step 3.2. and a decision is taken in a step 3.2.1. whether there are more overlay links in the slices. If the slice request specifies only one overlay link, then by mapping this overlay link the slice request can be embedded. If there are more overlay links, then in a step 3.2.2 the end-nodes, i.e. the source node and the destination node of the overlay link, are determined. In a step 3.2.3 the demands in regard of communication resources of the overlay link are gathered. Then, in a step 3.2.4 all or a part of the possible physical paths are determined. This is done in in^¬ creasing order of hops, i.e. connections between physical nodes. Several implementations for that are known, such as Eppstein implementation. For all paths it is checked, whether the demand of the overlay link can be fulfilled, which is done in loop 3.2.5 until the overlay link is mapped or it can be seen, that it is not possible.

Although the present invention has been described in accord- ance with preferred embodiments, it is obvious for the person skilled in the art that modifications or combination between the embodiments, fully or in one or more aspects, are possi^¬ ble in all embodiments.

Claims

1. Device for allocating communication resources of a communication network to a plurality of applications, each ap- plication having a requirement for a set of communication resources, said device comprising

a. an interface for receiving at least a first request for a set of communication resources and

b. an interface for transmitting information for allocating communication resources to the at least one request tak^¬ ing into consideration a rank, by which the request is categorized out of a selection of at least two ranks.

2. Device according to claim 1, wherein the device further comprises a processing unit which is arranged such that i. the request is categorized in at least two ranks;

ii. information for allocating communication resources to the at least one request is generated taking into con^¬ sideration the rank;

or/and the device comprises an interface for receiving infor^¬ mation on the physical set-up of the communication network.

3. Device according to any of the previous claims, wherein a request comprises at least one overlay link defining a con- nection between a source node and a destination node within the application, the overlay link demanding a certain subset of the set of the communication resources.

4. Device according to claim 3, wherein the information for allocation of communication resources specifies at least one physical path for an overlay link.

5. Device according to claim 4, wherein the processing unit is arranged such that upon simultaneous or asynchronous or/and independent arrival of a further request the infor^¬ mation for allocating communication resources to the at least one request is changed taking into account the ranks of the at least one request and the further request.

6. Device according to the previous claim 5, wherein the information further comprises an order in which the resources for different requests are embedded in the physical set-up of the communication system.

7. Device according to the previous claims, wherein the rank depends on one or more of the following parameters:

a. a type of the application or/and the associated request^¬ ed set of communication resources;

b. a degree of reliability of the transmission;

c. a degree of importance of the application;

8. Device according to the previous claims, wherein the re^¬ quest for the set of network resources specifies one or more of the following parameters:

a. a minimum bandwidth;

b. a maximum bandwidth;

c. an average bandwidth;

d. a maximum delay;

e. a maximum jitter;

f. a required security of the transmission.

9. Device according to any of the previous claims, arranged as controller.

10. Method for allocating communication resources in a communication network to a plurality of applications, each ap^¬ plication having a requirement for a set of communication resources, comprising the following steps

a. Receiving at least a first request for a set of communi^¬ cation resources;

b. Categorizing the requirement for a set of communication resources in at least two ranks;

c. Generating information for allocating communication resources to the at least one request taking into consid^¬ eration the rank.

11. Method according to the previous claim 10 comprising the further step of allocating the required set of communication resources of the request taking into consideration the as^¬ signed rank.

12. Method according to the previous claims comprising the further steps of

receiving at least a second request for communication resources ;

- sorting the requests according to their ranks in a order;

allocating communication resources demanded in the requests corresponding to their order.

13. Method according to the previous claims 10 to 12, where^¬ in a request for physical communication resources comprises a demand for at least one overlay link describing a connection between a source node and a destination node, the overlay link demanding an individual part of the required set of com^¬ munication resources, and wherein a mapping of the at least one overlay link contained in the request to the physical communication network is done while taking into account its demand for an individual part of the required set of communi^¬ cation resources.

14. Method according to the previous claim 13 wherein for a mapping of one or more paths between a source node and a des^¬ tination node of the overlay link is determined such, that the demand for an individual part of the required set of com^¬ munication resources denoting one or more of the parameters is satisfied.

15. Software program comprising commands for executing a method according to claims 10 to 14.