WO2014086978A1 - Method of allocating virtual resources - Google Patents

Abstract

A method of allocating a virtual resource in a network comprising at least two virtual networks is provided, wherein the method comprises sharing the virtual resource among the at least two virtual networks.

Description

DESCRIPTION

Method of allocating virtual resources

Field of Invention

The present invention relates to a method of allocatin resources, in particular virtual network resources in network, e.g. a communication network or datacenters including a network of databases. Moreover, it relates network entity or device of a network, to a network, a program element and a computer-readable medium.

Art Background

The present invention relates to various technology fields, e.g. radio resource management, database handling, network virtualization, software defined networking and network optimization. In particular, the invention refers to virtual resources allocated in virtual networks. The virtual networks may include the roles and mechanisms of Virtual Network Operators (VNOs), Virtual Network Providers (VNPs) and Physical Infrastructure Providers (PIPs) as well as the control plane in virtual networks . In virtual networks it is normally not possible to share resources on the virtual level. Virtual resources can be allocated only to a single virtual network. Summary

Thus, there may be a need to provide a more flexible method for allocating virtual resources in a network.

This need may be met by a method of allocating virtual resources, a network entity for a network, a computer readable medium and a program element, according to the independent claims. Further embodiments are described by the dependent claims .

According to an exemplary aspect a method of allocating a virtual resource in a network comprising at least two virtual networks is provided, wherein the method comprises sharing the virtual resource among the at least two virtual networks .

In particular, the network may be a physical network and/or may comprise two or several network entities and/or network instances. For example, the network instances may refer to at least one of a physical network or infrastructure provider, a virtual network provider and a virtual network operator. The network may be a communication network, e.g. a mobile communication network. The virtual networks may be owned by one network operator or may be owned by different network operators. For example, in the network one virtual network may be shared by different virtual network

operators and/or parts of at least two virtual networks may be shared by different virtual network operators. It should be noted that the two virtual networks may be already existing networks or may be virtual networks which have to be formed. For example, one virtual network may already exist while the other one is formed or generated

afterwards, in particular taking into account specific conditions, e.g. in order to enable sharing of the virtual resources with the already existing virtual network.

According to an exemplary aspect of allocating a virtual resource in a network, in particular a physical network, comprising at least two network entities is provided, wherein the method comprises receiving a message at one network entity including information concerning a

shareability of a specific virtual resource of the network; and allocating the specific virtual resource as a shared virtual resource based on the shareability information. In particular, the network entity may be a virtual network operator, a virtual network provider or a physical

infrastructure provider. Preferably, the at least two network entities relate to different network instances. For example, one of the network entities may be a virtual network operator (VNO) and the other one may be a virtual network provider (VNP) or a physical infrastructure provider (PIP) . Optionally, the method may further comprise sending the message from a further network entity to the network entity.

According to an exemplary aspect a network entity (e.g. VNO, VNP, PIP) or device (e.g. physical eguipment) for a network is provided, wherein the network entity is adapted to perform a method according to an exemplary aspect. According to an exemplary aspect a network or system is provided comprising at least two network entities according to an exemplary aspect.

In particular, the network may comprise a plurality of network entities and/or several or all of the network entities are network entities according to an exemplary aspect .

According to another exemplary aspect a program element is provided, which, when being executed by a processor, is adapted to control or carry out a method according to an exemplary aspect .

According to another exemplary aspect a computer-readable medium is provided, in which a computer program is stored which, when being executed by a processor, is adapted to control or carry out a method according to an exemplary aspect .

The term "resource" may particularly denote any limited goods or commodities needed to maintain a functionality of the network. Examples may be IT resources or transport resources. In particular, the term "resource" may denote a resource which is associated with a functionality of a machine, engine or entity. In case of a communication network, resources may be communication bandwidths, like freguencies, transmission bandwidth; a radio resource; a bandwidth resource; spectrum resources; transport

resources; virtual machine resources; application

resources; link capacity, computing power, memory space, physical nodes, etc. It should be noted that under the term "resource" itself physical as well as virtual resources may be subsumed, since virtual resources like virtual machines or applications running on virtual machines, may also be limited .

The term "network" may particularly denote a system of elements (network entities) which are connected with each other in such a sense that information, data, elements, or signals can be transferred from one of the elements to the other. Examples of such networks may be communication networks, e.g. mobile communication networks, or

datacenters in which a plurality of databases and/or storage units are connected with each other. The term "network" may encompass a physical network as well as a virtual network, wherein the term "physical network" may particularly denote a network which is formed by physical structures, e.g. (radio) communication links, base

stations, servers, databases, physical machines or engines which are connected to each other and may be owned by a physical infrastructure provider, while the term "virtual network" may particularly denote a network which is formed or at least comprises some virtual elements or units, e.g. virtual machines or virtual connections .

The term "network entity" may particularly denote entities which are participants of the respective network, e.g. a communication network or computer network, and maintaining the services of the network. In particular, the term may encompass virtual network operators, virtual network providers and physical infrastructure providers and devices owned by the same. Thus, in a broad sense the term "network entity" encompasses physical units and person owning or having control over .

The term "network instance" may particularly be a network entity belonging to a specific level or layer in the network. For example, all physical infrastructure providers may form one network instance, all virtual network

providers may form another network instance and all virtual network operators may form yet another network instance. Each level or layer may provide different functionalities for the network and/or users of the network.

By sharing a virtual resource among at least two virtual networks it may be possible to more efficiently use the (virtual) resources of a network, e.g. a communication network. It may also be possible to move virtual resources directly from one virtual network to another virtual network, e.g. by allocating the specific virtual resource to another virtual network. By moving the resource instead of deleting and adding the resource it may be possible to guarantee that the resource is still available. It may also be possible to provide multiple virtual networks with the same service by sharing virtual resources, e.g. by sharing the respective virtual machine which provides the

respective service.

Summarizing a gist of an exemplary aspect may be to provide a method and a network entity which may enable a sharing of a virtual network resource . Sharing of a virtual network resource may in principle be difficult since none of the network entities involved in such a sharing, e.g. a virtual network operator and/or a virtual network provider and/or a physical infrastructure provider may have all the necessary information for sharing a virtual resource.

In the following further embodiments of the method of allocating a virtual network resource will be described. However, the described components and features may also be used in connection with the network entity, the network, the program element and the computer-readable medium.

According to an exemplary embodiment of the method the network comprises at least two instances and the method further comprises exchanging shareability information of the virtual resource via a message or messages.

The term "exchanging shareability information" may

particularly denote any transmission of information via a message and relating to the shareability of the virtual resource. In particular, it may encompass "sending a message" from as well as "receiving a message" at one instance of the network. For example, the message may include information concerning a so called "atomic

activity" "sharing". Such atomic activities are known for example in the GEYERS project of the EU which includes atomic activities as "Add a link", "Add a node", "Delete a link", "Delete a node", "Change a property of a link" and "Change a property of a node". The message may be sent by a virtual network operator, a virtual network provider and/or a physical infrastructure provider.

According to an exemplary embodiment of the method the message includes information relating to at least one information out of the group consisting of: reguest for sharing of the virtual resource; offer to share the virtual resource; cost information related to the virtual resource; disjointness information concerning different virtual resources; topology of at least one network; quality of service; and virtual network ID.

Preferably, the virtual network ID or the information relating to the virtual network ID is always included in the method. In particular, several network IDs may be included into the message, e.g. the virtual network ID of both virtual network which are shared and/or the virtual network ID of a new virtual network created and to which the both networks may be mapped to. It should be noted that the respective information may be sent in a single message or may be sent using several messages, which may also be called sub- or partial messages. For example, the

"offer/request information" may be included in one message while the disjointness or disjunction information may be included in another message.

The "topology of a network" may particularly be defined by nodes and links of the respective network irrespective of whether it is a virtual or physical network. The "quality of service" (QoS) may particularly be defined by

delay/latency, bandwidth, jitter and the like. Furthermore the SLA (Service Level Agreement) comprises the

availability requirements and so on.

In particular, a virtual network operator may send a request/suggest message (for sharing a virtual resource) to VNP and/or a PIP. Based on this request the VNP and/or the PIP may check whether it is feasible to share the indicated virtual resource, e.g. virtual network (VN) or parts of the VNs .

Alternatively or additionally a PIP or VNP may send an offer/suggest message to a VNO. Based on this reguest the VNO may check whether it is feasible to share the indicated virtual resource, e.g. VN or parts of the VNs.

In particular, the cost information may indicate a price a network instance or network entity is willing to pay for a reguested virtual network resource, e.g. in case the sharing is initiated by a reguest, or ask for its offered virtual resource, e.g. when the sharing is initiated or triggered by an offer, for example by a PIP. The

disjointness information may indicate whether two network resources (virtual or physical) are disjoint or disjunct with each other.

According to an exemplary embodiment of the method of sharing the virtual resource among the at least two virtual networks is based on an analysis of the information included in the message.

In particular, the sharing reguest/offer may be rejected by all instances of the network involved in the sharing of the respective virtual resource, e.g. the VNO and/or the VNP and/or the PIP. That means, all instances involved in the sharing of a virtual resource may have to agree in the sharing of the virtual resource. That is, each instance may object or accept the sharing of the virtual resource. According to an exemplary embodiment the method further comprises exchanging of a further message including information concerning a successful sharing of the virtual resource .

According to an exemplary embodiment of the method the sharing of a virtual resource relates to a shared

protection, and/or statistical multiplexing using shared virtual resources; and/or moving virtual resources from one virtual network to another virtual network.

According to an exemplary embodiment of the method the shared network is a congruent network or a non-congruent network .

The term "congruent network" may particularly denote networks which have the same topology and/or whose

resources are residing on the same physical (or virtual) networks . In the case of non-congruent or not congruent networks a message including an ADD information or reguest may be sent before a message including share information or shareability information is sent. Thus, it may be possible to enable a re-allocating and re-mapping of virtual resources to physical resources since such an ADD

information may be suitable to form congruent networks out of non-congruent networks by changing the topologies of the respective networks .

According to an exemplary embodiment of the method the sharing of the virtual resource among the at least two virtual networks comprises a mapping of the virtual resource of one virtual network to the other virtual network .

In particular, the sharing may be performed for two virtual networks by mapping the virtual resources of the two virtual networks to a third virtual network.

According to an exemplary embodiment of the method the shared resource is associated with shared protection.

According to an exemplary embodiment of the method the sharing of the virtual resource includes the moving of the virtual resource from one of the at least two virtual networks to the other one of the at least two virtual networks .

Summarizing an exemplary specific embodiment may be based on the idea of providing a method or mechanism enabling the sharing of virtual resources in a network, in particular in virtual networks (VN) in the field of communication technologies. According to exemplary embodiments a method, a network entity or device and a network or system capable of realizing an environment is provided where a virtual resource can be used simultaneously by multiple virtual networks. For example, the sharing of the backup resources among several virtual networks of a VNO may be enabled or the method may be used to provide the same service in multiple virtual networks by sharing the virtual machine which provides the service. One of the objects of this specific embodiment may be to improve the allocation of virtual resources in virtual networks and to overcome the problems and disadvantages mentioned before. According to embodiments of the invention a virtual resource may be moved or shifted directly from a first virtual network to second virtual network. By moving this virtual resource a new allocation may be performed more easily and faster. Moreover, it may also be guaranteed that the reguested resource is available and will be provisioned in any case.

The network according to specific embodiments may provide a network virtualization environment which may comprise multiple instances of different types of network entities. That means that multiple PIPs, VNPs and VNOs can co-exist in such an environment. These network entities may be separate companies, or a single company might comprise any combination of different network entities . It should be noted that a VNO may operate one or multiple virtual networks . In particular, an allocating of virtual resources may comprise or may consist of a reguest of the VNO to the VNP and the final allocation of reguested resources by the VNP at the PIP, for example. However, the allocation may be initiated by an offer of a PIP to a VNP and/or VNO, by a reguest of the VNP to a PIP or an offer of the VNP to the VNO.

According to an exemplary aspect a method for allocating resources in a network is provided.

In particular, the resources may be virtual resources.

According to a specific embodiment the network may comprise or host at least two virtual networks. Optionally, the network may comprise several instances. For example, the instances may refer to at least one of a physical network provider, a virtual network provider and a virtual network operator . According to another exemplary aspect a system configured to perform the methods according to any of the preceding aspects/embodiments is provided. According to another exemplary aspect a device configured to control the method according to any of the preceding aspects /embodiments is provided .

The aspects and exemplary embodiments defined above and further aspects of the invention are apparent from the examples of embodiment to be described hereinafter and are explained with reference to these examples of embodiment.

Brief Description of the Drawings

Fig. 1 schematically shows information exchange among roles/instances.

Figs. 2A and 2B schematically show access to IT-resources .

Figs. 3A and 3B schematically show label stacking for multiple ownership of a virtual link.

Figs. 4A and 4B schematically illustrate an example of shared protection.

Fig. 5 schematically illustrates an example of shared protection for non-congruent protection paths . Figs. 6A to 6D show results of a comparison of shared vs. dedicated protection. Figs. 7A to 7D show results of a comparison of VNO- resilience vs. PIP-resilience .

Detailed Description

The illustrations in the drawings are schematic. In the following a detailed description of exemplary embodiments is given.

In particular, a detailed description with respect to a technical field of application will be given. While a specific field (communication network) is chosen for the following description, it should be mentioned that the same principles may be applied in different fields.

In the beginning some consideration concerning the

technical field may be given. Exemplary embodiments of the invention generally relate to virtual networks (VN) in the field of communication technologies. In particular, they refer to virtual

resources allocated in virtual networks. The virtual networks may include the roles and mechanisms of Virtual Network Operators (VNO) , Virtual Network Providers (VNP) , Physical Infrastructure Providers (PIP) as well as the control plane in virtual and physical networks . In common virtual networks it is not possible to share resources on the virtual level. For example, virtual resources can only be allocated to a single virtual network. Embodiments of the present invention may provide a method, devices and a system capable of realizing an environment where a virtual resource can be used simultaneously by multiple virtual networks. Embodiments of the present invention enable e.g. the sharing of the backup resources among several virtual networks of a VNO or they can be used to provision the same service in multiple virtual networks by sharing a virtual machine which provides this service.

In current or commonly known telecommunication networks it is not possible to move virtual resources from one virtual network to another. In the case that a resource is not needed in a first virtual network and that it is reguested by a second virtual network, the resource may be deleted from the first network and reguested as a new resource for the second network. One of the objectives of embodiments of the invention is to improve the allocation of virtual resources in virtual networks and to overcome the problems and disadvantages mentioned above.

According to embodiments of the invention virtual resource may be moved of shifted directly from a first virtual network to a second virtual network. By moving this virtual resource a new allocation may be performed more easily and faster. Moreover, it can also be guaranteed that the reguested resource is available and will be provisioned in any case. In current or common communication networks it is also not possible to keep redundant resources in a separate virtual network and to serve several virtual networks using them for resilience purposes. Embodiments of the present invention support such a shared backup protection among different VNs . According to embodiments of the invention virtual resources may be shared among multiple virtual networks . In current networks the vertical division of the roles and abstraction of the networks cause a limitation of available information at each role. However, exchanging a certain level of information without revealing the details of the topologies or the services can result in savings at each layer .

Embodiments of the present invention intend to introduce sharing as an enabler for saving of resources that are reserved e.g. for protection purposes. Resources are physical, e.g. link capacity, computing power, memory space, physical nodes, etc., shared in the sense of shared spare capacity for protection purposes in case of a single failure .

Expected results are better utilization of physical resources and cost reduction for the VNO, the VNP and the PIP. The present invention provides details of how sharing can be realized where a virtual resource is used

simultaneously by multiple virtual networks. The invention also enables e.g. provisioning of the same service in multiple virtual networks by sharing the virtual machine, which provides this service or multiplexing gain for the bandwidth resource. In radio access networks (RAN) "RAN sharing" is known. However, RAN sharing only relates to networks using the air interface. By RAN sharing dedicated resources are assigned to the different operators either in the beginning or during operation. To setup virtual networks multiple possibilities exist.

For example, one concept is the concept of atomic

activities, studied e.g. by the EU project GEYSERS. Embodiments of the present invention may be implemented m the field of the atomic activities by introducing a new one allowing the sharing of virtual resources among multiple virtual networks .

In the following the atomic operations published in the literature and research community, e.g. in the EU project GEYSERS http://www.geysers.eu/, are listed and are shortly described. The GEYSERS project considers both the IT and the network resources. However, GEYERS does not deal with the sharing of virtual resources. Also the update of any virtual resource does not include the property that one virtual resource simultaneously belongs to multiple VNs .

1. Add a link :

This operation adds a link to a single V . Possible parameters for this operation are bandwidth, delay, disjointness (e.g. SRLG) of the link.

2. Add a node :

This operation adds a node to a single VN. Depending on the type of this node, namely if this node is an IT node or a telco node, different properties can be specified:

o Telco Node: Throughput capacity, switching capacity, number of maximum ports, speed of the interfaces, properties (e.g. reach) of transponders, o IT Node: Size of RAM, CPU power, hard disk space, connection speed and latency to the network,

Delete a link: This operation deletes a specified link from the virtual network .

4. Delete a node :

This operation deletes a specified node from the virtual network .

5. Changing the properties of a link:

This operation changes the properties of a link, e. changing the bandwidth, changing the maximum jitter, changing the maximum delay.

6. Changing the properties of a node:

This operation changes the properties of a node.

Depending if this node is an IT node or a telco node different properties can be specified:

o Teleo Node: Changing the throughput, changin the RAM, changing the CPU power, ...

o IT Node: Size of RAM, CPU power, hard disk space, connection speed and latency to the network,

To set up isolated virtual networks a vertical control plane between the involved business roles VNO (Virtual Network Operator), VNP (Virtual Network Provider), PIP

(Physical Infrastructure Provider) may be implemented in order to set up virtual transport networks. Using this vertical control plane e.g. setup reguests for virtual networks and confirmation messages are sent.

According to embodiments of the invention for the

implementation the concept of label stacking (see RFC3031, eh. 3.9) and hierarchical LSPs may be used. Hierarchical LSPs are created by embedding one or more client LSPs onto an existing server LSP or a new client LSP on a newly created lower level server LSP. Within this concept it is possible to transmit multiple client LSPs in a server LSP. (see RFC4726 and RFC4206).

With the invention statistical multiplexing at the VN level may be realized. "Statistical multiplexing is a type of communication link sharing, very similar to dynamic bandwidth allocation (DBA) . In statistical multiplexing, a communication channel is divided into an arbitrary number of variable bitrate, digital channels or data streams. The link sharing is adapted to the instantaneous traffic demands of the data streams that are transferred over each channel .

When performed correctly, statistical multiplexing may provide a link utilization improvement, called the

statistical multiplexing gain." (see Wikipedia) . However, it should be noted that with statistical multiplexing packets can be dropped, if the overall capacity of the link is not big enough to carry all the different traffic streams at peak rate. Within GMPLS/MPLS there is already the capability, which is called shared protection. See

RFC3471 "GMPLS Signaling Functional Description" method. With this it is possible to share several generalized MPLS paths on one and the same physical link or underlying GMPLS path .

However for virtualized networks with VNOs, VNPs and PIPs no such feature exists today. In the following different concepts of sharing a virtual resource among different VNs according to the invention will be explained. Furthermore, a realization of the inventive idea is given as an example Through introducing the concept of virtual networks the PIP hosts multiple VNs sharing one physical resource. One idea of an embodiment of the present invention is to allow also the VNO (or VNP) to apply the same concept as the PIP is doing with the difference that this time the same virtual resources are shared among different VNs. A VNO cannot simply share the resources since it has lack of knowledge about the physical topology and the physical location of the virtual resources. Therefore, a certain information exchange among the roles is implemented.

According to embodiments of the invention a new atomic activity (called, for instance, "SHARE") may be introduced. This activity takes as input parameter the resources of different VNs, which should be shared. It is a sharing offer that is to be sent from the VNO to a VNP. It may be translated by the VNP to the PIPs . PIP results may be processed by the VNP and reported to the VNO. The reguired information exchange will be explained in detail when referring to Fig. 1.

A VNO being the owner of two virtual networks VNl and VN2 may know that these networks may have complementary time reguirements in terms of statistical multiplexing for specific parts of the networks or the VNO may wish to let protect parts of the networks on a shared underlying physical or virtual network. The driver for this might be cost savings for the concerned VNO the VNP and the PIP in the business relationship. For that the following procedure could be applied:

1) The VNO informs (or suggests or reguests) the VNP to check whether it is feasible to share (and at which prices) the indicated VNs or parts of the VNs as signaled in the SHARE message towards the VNP. If prices are known

beforehand (due to pre-arranged bilateral agreements, for example), the VNO may simply inform ( suggest/reguest ) the VNP to perform the sharing without charging negotiation.

2) On receipt of the message from the VNO the VNP may reject the offer ( suggestion/reguest ) . If it is not rejected - and since the VNP in turn again does not know whether the said resources can be shared on the physical layer at all or at reasonable prices - the VNP could consult the involved PIP (or PIPs, respectively) for checking whether the resources can be shared (and at which prices) . Note: If prices are known beforehand (due to pre- arranged bilateral agreements), the VNP may simply inform (suggest/reguest) the PIP to perform the sharing without charging negotiation.

3) On receipt of the message from the VNP at the PIP, the PIP may reject the offer (suggestion/reguest) . If it is not rejected the PIP can continue either to perform the sharing on the PIP level and return a message indicating the successful sharing to the VNP or, alternatively, determine the related costs for the reconfiguration and return that information back to the VNP. 4) On receipt the VNP may change the related costs as the VNP may also want to participate in the efficiency gain before forwarding the message to the VNO. If the sharing was already performed by the PIP the message indicating the successful reconfiguration is forwarded to the VNO.

5) If the sharing of resources was already performed the procedure is completed with the receipt of the message at the VNO. However, if the VNO received an indication about the resulting costs the VNO may accept or reject it by sending a message towards the VNP.

6) On receipt of the message from the VNO the message is forwarded to the PIP and the procedure is completed.

Each role or instance generally can object or accept the reguest from the adjacent roles according to their

respective technical or business needs. It is to be noted that the above description mainly consist of two conceptual procedures. One is the case where the involved partners have a price pre-arrangement for the invocation of the service, which shortens the procedure to the steps 1 to 4. Another case is the approach where the partners may renegotiate the price for the service of sharing. Then the procedure is completed with step 6.

The following important use cases and advantages will be described later: resiliency spanning multiple VNs - shared protection; statistical multiplexing using shared virtual resources; move of virtual resources from one VN to another . For the case of shared protection, i.e. when redundant resources are intended to be shared which are reserved for resilience purposes, an additional information exchange is required to determine which virtual protection paths can share resources. Namely, only the protection paths

belonging to disjoint working paths can share resources. If two virtual working paths share physical links or nodes this means that said paths belong to the same "Shared Risk Link Group" (SRLG) and, hence, can fail simultaneously. Thus, their protection paths might be required to be used at the same time and resource sharing among them is not possible .

The disjointness information can be gained in two ways. First, a VNO can request disjoint links at the setup of the VN and, hence, would have implicitly the knowledge that they are disjoint. If this has not been the case, a VNO can send a message to the VNP (e.g.

"ISDISJOINT (Rl,R2,dis jointnessType) " ) , where Rl and R2 are two virtual resources of any type, i.e. they can be of type virtual link, virtual node or virtual IT resources .

"dis jointnessType" defines what type of disjointness is looked for. For a virtual link this can be physical link, physical node or sub-network disjoint. Similarly, for the node and IT resources it can be physical node or server or sub-network disjoint. The sub-network disjointness can be agreed on between the roles by defining availability regions inside the physical topology. For the examples described in the following, it is assumed that a VNO has already sent a sharing offer that has been accepted by all the involved roles. The details of how sharing is done technologically is now described.

For simplicity it is assumed that the VNs are belonging to the same VNO. However, it should be noted that the whole concept can be easily generalized for the case of multiple VNOs and that the example as described herein is by no means meant to limit the overall invention.

It is assumed that the virtual networks VNl and VN2 want to use the same virtual resource.

For simplicity a case where the virtual resource is a virtual IT-resource is described at first. In this case the IT-service is both offered to VNl and to VN2, i.e. users of both VNs can use the IT-resource. Inside the virtual shared IT-resource a separate process, e.g. a virtual machine, a web-server daemon, is started for each VN namely VNl and VN2 in this example. As usual in each computer there exists a scheduler - an additional process, which is responsible for managing the different processes including the

processes for VNl and VN2.

For the access of the process two options exist:

1. The user communicates directly with the VN specific processes. This is for example possible, if each VN specific process has a unigue IP address and if processes of different VNs are residing in different IP networks. This access option is sketched in Fig. 2B which will be described later on. 2. The user identifies the target IT-resource via two identifiers: The first one identifies the shared IT- resource, whereas the second one identifies the IT-resource of the corresponding V . The scheduler or an additional process forwards the data to the corresponding VN resource as soon as it has reached the shared IT resource. The scheduler ensures that the data coming from e.g. VNl is allowed to communicate only with the VNl specific

processes. This access option is sketched in Fig. 2A which will be described later on.

In the special case where only read access is needed for the different processes, it is possible that only a single process serves the different VNs. One simple example for such an IT-service is a web-server, which delivers static web pages. One possible realization may be that the webserver has two - perhaps virtual - interfaces. Each one is connected to one VN and the web-server is listening on both interfaces for incoming reguests. The web-server itself is only started once, i.e. only one process exists for this read-only server .

If the resource is a telco-node also the reguirements for separation between the VNs must be ensured, which can be done in a similar manner as in the IT-resource cases.

If the virtual resource used by multiple VNs is a virtual link, one can make use of the concept of label stacking - similar to option 2 described above for the access of IT resources. The case of two VNs sharing one virtual link is shown in Fig. 3, which will be described later on. Fig. 3A shows the situation before the multiple ownership of the link. In that case VNl is using links 302, 303 and 305, and VN2 is using links 301 and 304. Assuming that the virtual link 303 has a certain capacity C in the beginning it is utilized only by the VNl. Therefore, the packets flowing on that link have the label "VNl" and the traffic flow has the upper limit C.

In Fig. 3B, it is shown that link 303 is simultaneously used by another VN, namely VN2. It should be noted that the upper limit of each traffic flow from VNl and VN2 on link 303 is still C, which is egual to the total capacity of this link. Isolation is provided by two distinct labels. Label stacking can be used for realizing the sharing.

Namely, a new label is created for the link, which is added on top of the labels of the VNs 1 and 2. It should be noted that across link 303 all the switching is performed on the outer label; the inner labels are never observed or changed until the outer header is removed and the packets reach their destination networks, i.e. VNl and VN2 respectively. It should be noted that the number of owners for a virtual resource is not limited to two and can be an arbitrary number depending on the capacity of the resource and the QoS ("quality of service") requirements of the VNs. As just described statistical multiplexing of the traffic flows is required and, in practice, the sum of the traffic from both VNs is limited to C. The minimum bandwidth specification for VNl and VN2 might be configured. In this case the node which performs the label stacking, i.e. the node which adds the L3 label has to ensure that VNl and VN2 are not consuming too much traffic. This means that this node has implemented a scheduler that realizes the statistical multiplexing. This scheduler may also have a feedback loop.

In the following embodiments of the present invention is shown. General implementation details of the virtual resource sharing and the relevant messages will be

provided. Two implementation possibilities are considered and compared. Subseguently, use cases are described.

Amongst others, the following options for an implementation are possible:

- Sharing of congruent networks

- Sharing of not congruent networks

Congruent networks are (virtual) networks which have the same topology and whose resources are residing on the same physical (or virtual) substrate networks. It is very likely that one virtual network is not egual to any other virtual network from a topology perspective. Still, one can probably identify one or several subsets or intersections of two or more virtual networks which are congruent . One example would be the case where VNl and VN2 have

independent virtual IT-resources residing on the same physical substrate at the beginning and which then both could share a virtual machine as shown in Fig. 2A.

An example of not congruent networks could be the networks as depicted in Fig. 3A. The virtual network VNl consists of the connected links 302, 303 and 305. The VN2 consists only of links 301 and 304 that are not connected, but the two virtual networks can become congruent by adding a link between 301 and 304 to the VN2. This common link of VNl and VN2 as shown in Fig. 3B is the intersection of the two virtual networks. Moreover, instead of a simple link the two networks may have a network in common . a) Sharing of congruent networks

The VNO can reguest from a VNP to setup a virtual network being identified by a VNetID (Virtual network identifier) by consulting the PIP for collecting and combining the virtual resources such that the reguirements as given by the VNO are met. There can be also an association of

Computing Resources with Communication Resources while keeping isolation also for the computing resource. By this in general any associated virtual resources (IT or network) are expected to be isolated from any other virtual

association and can be handled in a generic way, when it comes to the sharing of any abstract resources .

Therefore, it is to be assumed that at first at least two combined associations of IT and virtual networks exist, for instance VNetlDl and VNetID2 owned by the same VNO. Per definition these virtual networks are clearly separated and isolated. In the following the plain procedure or option without charging re-negotiation is explained in more detail .

Step 1

If the VNO wants to share particular resources it expresses itself by reguesting from (suggesting to or informing about) the VNP that the resources of the VNetlDl or a subset of them are to be shared with the resources of the VNetID2 or a subset of them. For instance, the VNO may issue a message like the following in a generalized format towards the VNP:

SHARE ((part x of VNetlDl, part y of VNetID2), [VNetID3]) by which it is reguested to share part x of VNetlDl and part y of VNetID2 on the VNetID3. [] denotes that the ID of the VNetID might optionally be added in case the reguestor wants to share the resources on the particular virtual network VNetID3. From a functional view the VNO in fact reguires the implicitly creation of another virtual network VNetlD3, which is able to carry both the resources (or parts) of VNetlDl and VNetID2 and map them within the VNetID3. Step 2

On receipt of the SHARE message from the VNO at the VNP and before continuing at the VNP the VNP may apply some kind of policing in order to ensure that the networks to be shared are owned by the same VNO. Alternatively, the policy decision point at the VNP may allow the sharing of the resources after implicit or explicit approval by the concerned VNOs involved. If, for whatever reasons, the VNP does not want to allow sharing the message from the VNO is rejected by means of a negative response and the procedure is completed.

As both, the VNO and the VNP, in general do not know about the current physical location of the virtual resources and in order to instantiate the sharing network the VNP in turn informs ( suggests/reguests ) the sharing from the PIPs by forwarding the reguest (for the implicit creation of the VNetID3 and the mapping of the resources of VNetlDl and VNetID2 onto it). Also, the VNP can itself, i.e. without being triggered by the VNO, reguest from the PIPs to share some Virtual network VNx and VNy, etc. on a virtual network VNz .

Step 3

Eventually the PIP will receive the SHARE ( (part x of VNetlDl, part y of VNetID2), [VNetID3]) from the VNP. From a functional view now it is up to the PIP to create the new VNetID3 on the real physical substrates owned by the PIP at first. It is clear that only resources, parts of the virtual network VNetlDl, which are congruent with the virtual network VNetID2 can be shared on a new virtual network .

Before continuing at the PIP the PIP may apply some kind of policing, in order to ensure that the networks to be shared are owned by the same VNO, but as the PIP normally does not know about the VNO in general the PIP relies on the integrity of the VNP from which the reguest for the sharing was received. However, in another embodiment, alternatively the policy decision point at the PIP may allow the sharing of the resources after implicit or explicit approval by the concerned VNPs/VNOs involved, or based on any other internal technical or business related reason.

Furthermore, the PIP evaluates the resources of the concerned virtual networks as to whether all of the VRs really are residing on the same physical nodes or

resources. (As the PIP does have a view about each virtual resource as to whom it belongs and where it currently resides, the PIP can simply check for each VR of one VN whether the corresponding VR of the other VN are residing on the same physical hardware.)

If this is the case the PIP continues with the next step, otherwise the PIP rejects the information

( suggestion/reguest ) for the sharing of resources with a negative response towards the VNP/VNO and the procedure is completed. If the sharing is possible now the PIP can setup a new VN for instance (Setup of virtual networks), by issuing a RSVP-TE* path message on the control plane by which the new virtual resources (in accordance with QoS reguirements, etc.) are allocated on the physical

resources, (e.g. by means of the RFC4875 (P2MP networks) augmented with the capability to create MP2MP (CAA

(conjunction allowed active); CAP (conjunction allowed passive) objects, networks and the access to the virtual machines) . The access to the virtual resources of an established virtual network is handed over via the means of RRO (Record Route Object), SRRO (Subseguent Record Route Object), CAP and CPP carried within the RSVP message resv. So, any VNet is defined by combination of them.

In the next step the virtual resources (of VNetlDl and 2) are to be mapped to the VNetID3, such that the resources of VNetlDl and VNetID2 are still separated, but completely confined within the VNetID3. This may be achieved by applying the so called label stacking mechanism in the conventional networks . However, within the scope of virtualized networks being set up dynamically via a control plane this can be achieved for instance like given in the following procedure . As already stated the sharing of networks is only possible in case the parts of VN in guestion are congruent. That means that, especially, the topology needs to be the same. However, besides that some characteristics as for instance the bandwidth allocated to one virtual network may differ. The topology, however, is the same.

Currently in the IETF hierarchical LSPs ("label switched paths") are created by embedding a new client LSP onto an existing server LSP or a new client LSP on a newly created lower level server LSP. However, within the scope of this embodiment the VNetlDl and VNetID2 are already existing but now need to be stacked on the VNetID3.

As such the nesting of VNs on top of another VN is

performed by a further enhancement of the concept of hierarchical LSPs (also known as LSP nesting) by sending a RSVP Path message for or from each of the LSPs to be nested on the nesting LSP.

Instead of sending the Path message for the VNetID3 as for the creation of a completely new and independent network and especially in order to be distinct from that, this Path message may carry an new flag called "sharing" in the existing object "Attribute Flags for LSP-Attributes Object" (where stitching or nesting is currently signaled) together with the VNetlDl (RRO, SRRO, CAP, CAA) and the VNetID2 (RRO, SRRO. CAP, CAA) to be nested on the VNetID3. As the VNetID3 network is created as normal the forwarding plane is instructed to map or stack the labels of the VNetlDx at each node on top of the nesting label. By this the control plane of the physical resource recognizes that the said virtual resources of the corresponding virtual networks are to be shared on the VNetID3, stacking the labels of each of the virtual networks on top of the label of the VNetID3.

As the path message traverse along the paths of the VNetID3 up to the edges each physical node is configured

accordingly. Once an edge node is reached the edge node will return the indication of the successful configuration back within the RSVP Resv message.

Traffic hit and race condition:

Probably the inner virtual resource of the VNs may have to be configured before the traffic at or from the edges can be propagated onto the nesting LSP, because traffic is expected to be affected. Conseguently there is a need to send a RSVP Notify with a new indication "perform cut through at the edges now" simultaneously to each of the edge nodes after the configuration within the network. Only after each of the edge nodes acknowledge the successful conduction of the actions the PIP can report back a response to the VNP/VNO.

Therefore, as another major enhancement the PIP may not only rely on the usage of the amended RSVP Path message, but also on the option to send a RSVP Notify message with new indications or meaning or information elements to each of the physical node in guestion simultaneously. In general these individual as well as a newly introduced RSVP Notify message will at each node result in nesting the LSPs of each VNs onto the LSP of the underlying LSP of the VNetID3. Since this can, theoretically, be performed in parallel on each physical node the race conditions are likely to be minimized at the expense of increasing the control plane traffic load. In any case it must clear to the VNO that for an

intermediate transition period the traffic flow is impacted somehow. That means that on successful mapping or

configuration of the VNetlDs to the VNetID3 the PIP sends SHARE ACK back to the VNP .

Step 4

On receipt at the VNP the VNP in turn forwards this to the VNO. Step 5

On receipt at the VNO the procedure is completed.

It is to be noted that the PIP may perform such sharing of the resource on its own and independent from any reguest from VNP/VNO, as the PIP does know each virtual network it hosts on its physical resources already. In terms of conventional network this sharing would possibly be based on some kind of simple aggregation, which is an option always at the hand of the existing network operator, but with an important difference and significant modification that the independent paths of VNl and VN2 (see Fig. 3B) which may have allocated the bandwidth M and N,

respectively for the links in common for VNl and VN2, are now bound by the capacity C of the VN3, which may be lower than the sum of M and N. By this one takes advantage from the statistical multiplexing between the two. However, the procedure to let the VNO/VNP

information/suggestion/request the PIP to share some resources on each other in addition gives the PIP the possibility to charge the VNO/VNP tor performance/service of the explicit sharing of resources .

In terms of the most popular GMPLS control plane protocol family the atomic operation SHARE may be carried on top of a RSVP Notify message carrying the above described

information elements. A combined control of network and IT resources may be possible, and both kind of resources may be requested and maintained by means of GMPLS, as GMPLS in general is available for all kind of resources as the name generalized MPLS already implies. b) Sharing of not congruent networks (VNO sends at first ADD operation and then requests to share)

The above description assumes that the existing resources are congruent to be shared on a virtual network. However there might be case where the two virtual networks are non- congruent, for being shared.

In that case it is possible that the VNO is adding the missing virtual resource to the virtual network (for instance as required in Fig. 3A for the VN2 to become congruent as given Fig. 3B with mechanism as known from the state of the art before the sending of the request for sharing as given in a) . Furthermore, it is also not excluded that for each VN involved resources may be added separately for each VN before the request for sharing is sent . c) Sharing of not congruent networks (VNO sends one combined operation)

As another option it might be possible to even combine the SHARE and ADD in another single atomic command called "SHARAD", by simply expressing SHARAD () as the

simultaneously performing ADD and SHARE at once.

With the present invention, amongst other things, the following use cases are supported. With respect to the options above most of the options rely on option a) . I.e. the SHARE command is the most atomic one. However, on the other hand also option c) can be regarded as an atomic operation as it relieves the VNO from issuing two commands.

There are several important use cases for this property. One of them is enabling shared protection in the virtual layer. This is realized by sharing the backup resources among several VNs of a VNO as described in the following. Other possible use cases are the efficient move operation of a virtual resource, where it is reguired that a resource can belong concurrently to multiple VNs. The last

considered use case is statistical multiplexing where the same service can be provided in multiple VNs.

Resilience: Shared protection in virtual networks

The concept of sharing virtual resources among different VNs enables a shared backup protection applied at the virtual layer. Shared protection reduces the cost and capacity usage compared to dedicated protection. Today shared protection mechanisms are applied in the current networks. In next-generation networks, application of shared protection is not straight forward due to the separation of the physical and virtual layers. The service routing information is available only at the VNO layer and the physical topology information only at the PIP layer. With this invention, the appropriate messages are defined, which allow the necessary level of information sharing without elaborating about the details of the corresponding topology. This method allows all the three roles, the VNO, the VNP and the PIP to save costs and resources by applying shared protection.

An example is provided to describe the proposed method. Assume that two VNs exist on the same physical topology, namely VNl, VN2 as shown in Fig. 4. It is assumed that these VNs are created at different times and the

disjointness of the VNs is not known ahead at the VNO layer. The PIP alone cannot apply shared protection either since it lacks the knowledge about the services. Therefore, there is a need for a relevant information exchange which can result in sharing the protection paths in these VNs, which in turn will enable savings possibly in all VNO, VNP and PIP layers. Firstly, the VNO can reguest the

disjointness information for the working paths of the demands via the ISDISJOINTO message as described. If the answer is positive, it can start the sharing reguest by sending the SHARE message as described.

Fig. 4A shows the situation before sharing the resources. Two demands in two different VNs are shown, where the working paths are labeled with Wl and W2, respectively.

Without shared protection, the total bandwidth reguired on the link A-B would be 50/70 as the total of the reguired bandwidths of the two protection paths with 20/30 and 30/40 capacities, respectively. Since the working paths of the two demands are physically disjoint and the protection path are congruent on the link A-B, it is sufficient to reserve a total capacity of 30/40 on this link as shown in Fig. 4B, which is the maximum of the disjoint demands using this protection path. The example is given for two demands but the same process can be directly applied for multiple demands with disjoint working edges.

Fig. 5 describes the situation, where the protection paths are not congruent. In this case one of the protection paths should be re-routed to enable sharing. This might not be possible due to the lack of sufficient resources in the physical domain, due to the unwillingness of the PIP to do so (e.g. the resource usage might be actually increasing due to the re-routing) or due to the changing QoS

parameters of the demands with the re-routing if they do not meet the reguired SLAs . As mentioned before there might be either a sharing-cost agreement between the roles covering the possible re-routing and migration costs or the PIP can create a sharing report containing this

information. If sharing is possible this report is sent to the VNO via the VNP and the VNO is then decides if shared protection should take place.

With the move operation as described below it is guaranteed that the resource is available for the other VN - compared to the trivial implementation that it is first deleted and then added to the other V . Furthermore, it is ensured that the same resource is available in the other V . The VNO can request that a specified resource (R) , e.g. some IT resource, a network link or a network node, is moved from one virtual network (VNl) to another one (VN2) . This operation is defined as Move (R, VNl , VN2 ) . In the following it is assumed that the VNO operates both virtual networks, i.e. the originating (VNl) and the destination network (VN2) .

This operation is realized by first sharing R with VNl and VN2, as described in this chapter. The next step is to delete the shared virtual resource from VNl. This means that this resource is deleted completely from VNl. At this step R is only be used by VN2 and there is no need for label stacking, i.e. for the shared VN, any more. Hence, this label stacking is canceled.

The move itself, i.e. the above steps, can be either executed by the VNO, VNP or PIP. The VNO always triggers the move. However, when the move is realized at the VNO layer, the VNO splits the move operation into the different atomic activities.

By introducing shared virtual resources statistically multiplexing both for IT services as well as for network resources can be achieved at the VNO level. This highly cost efficient method is today commonly used in the access areas in other technology areas. Now it can also be applied to VNs . The invention additionally provides more advantages: - Simple and cost efficient introduction of read only IT services into multiple VNs, since only one IT resource has to be setup and maintained.

- The possibility that resources can be shared between different VNOs creates new business opportunities. The VNOs can work cost efficiently together and still maintaining their networks individually

- A single VNO can operate its VNs more cost efficiently by using the shared backup concept and statistical

multiplexing.

- The move of the resources and the sharing of resource open also a door for further inter-VNO business cases.

Network virtualization is proposed as a key enabler for future Internet and future networks. Different from current virtualization technigues, namely Virtual Private Networks (VNPs) and overlay networks, network virtualization enables operation of isolated network slices, which are called Virtual Networks (VNets), consisting of computational resources inside the virtualized physical network, as well as network resources between them. The isolation of different VNetS allows an efficient sharing of the network resources and the usage of test networks, multi-generation networks, enhanced resilience and energy efficiency.

Especially with the increasing cost for mobile networks, network sharing and hence network virtualization is becoming a very important topic in research and industry.

In a virtual network environment new business roles realizing different tasks are expected to be established. This will result in trading of virtual resources between them. Hence, new control mechanisms and interfaces are necessary to realize the setup and operation of the VNets. Several architecture proposals and interface definitions are available in the literature . In the network

virtualization model, four business roles are defined, namely the Physical Infrastructure Provider (PIP) owning the physical substrate, the Virtual Network Provider (VNP) providing the virtual resources to the Virtual Network Operator (VNO) , which is operating a VNet on the physical substrate and the Service Provider (SP), reguesting connectivity services from the VNOs .

A PIP is the owner of the physical infrastructure, which can be e.g. fixed or mobile networks (Layer 1, 2 or 3) . IT- resources like processing or storage units or any

combination of them. All of these physical resources are virtualized. A PIP can monitor all of its physical and virtual resources and has the knowledge of the usage and physical location of its virtual resources. The VNP is the role enabling the VNet setup by having an overview on the virtualized resources of different PIPs and advertising this resource pool to the VNOs. A VNO can operate one or several VNets, which are mapped onto the physical

infrastructure of one or more PIPs. In this application, it is assumed that for the VNet setup all the available virtual resources of the PIPs are advertised to the VNOs through the VNP. Note that in case a VNO acts also as a VNP, the resources can be directly advertised to the VNO. The VNP or the VNO can negotiate with various PIPs and compute an optimal VNet according to the specific customer needs coming from the VNOs or the SPs, respectively. Resilience is a crucial issue in today's networks and it will continue to be for the future networks. Increasing growth of data and the dependency on communication and online services makes resilience mechanisms in networks even more essential. Especially for new services there are very high guality of experience (QoE) reguirements .

Finally, the impact of disasters like tsunamis or

hurricanes on networks and IT services shows the importance of having efficient resilience mechanisms in place.

Different resilience mechanisms are available for today's networks, which can be grouped as protection and

restoration mechanisms. Restoration mechanisms reguire a longer recovery time due to the on-demand path calculation and signaling. Protection mechanisms are fast, however, in case of dedicated protection, where each working path of a demand is protected with a dedicated protection path. They become very costly due to the high amount of reguired redundant bandwidth. Therefore, shared protection can be a good solution with a fast recovery time and reduced resource reguirements . The application of shared protection to physical networks is studied extensively in the

literature. In this application, it is focused on

resilience mechanisms for future networks, namely for virtual networks . What kind of opportunities and challenges VNets bring in terms of resilience and how it can be implemented are important research guestions. In the described virtual network environment there are two fundamental resilience architecture options; resilience can be provided either by the physical layer, namely by the PIP, PIP-Resilience, or by the virtual layer, namely by the VNO (or by the VNP), VNO-Resilience . These two cases require certain levels of information exchange and

interfaces enabling resilience. In this application, the architecture for resilient VNet setup as well as the required enhancements to this architecture allowing sharing of the redundant resources among existing VNets. The main difference compared with existing sharing mechanisms lies in the separation of the layers along the vertical axis. The VNO has the information about the routing of the services in the VNet, their working and protection paths, however, lacks the physical mapping information. On the other hand, the PIPs do have the mapping information but would not be able to apply shared protection without the knowledge of the service routing. Embodiments of the invention enable a certain level of information exchange, which is beneficial for all the roles since shared

protection decreases the VNet cost for the VNO and

increases the network utilization efficiency for the VNP and the PIP. Once the resilient VNet creation request is sent to the PIP or VNP, there is the need for efficient resilient VNet design models. Several algorithms to have resilience in virtual networks already exist in the literature. For example the resilient overlay networks are investigated, it is assumed that the VNet is already mapped onto the physical substrate and running and the services are then routed in the VNet in a survivable way. Other documents deal with the question of how to embed a given VNet in a survivable way onto the physical substrate. Note that these works assume that the virtual topology is already given and in case of survivable embedding, the VNet has to be even bi-connected so that the mapping can be realized at all. However, in a virtual network environment, the VNet is not given but has to be designed according to the service reguests, their reguirements and the available physical resources. Also resilient VNP designs are realized but they assume a direct mapping of the virtual links on shortest physical paths. This approach may be extended by allowing several mapping choices for a virtual link, which

outperforms the shortest path mapping model in terms of feasibility and delay performance. The proposed models offer virtual network designs with dedicated protection. As stated earlier, dedicated protection is very costly. Hence, in this application new optimal virtual network design models with shared protection as mixed-integer linear problems are introduced reducing the VNet cost and

increasing the resource utilization efficiency. Both the performance of VNO-Resilience and PIP-Resilience as well as the gain of shared protection compared with dedicated protection via simulations are compared.

The remainder of this application is organized as follows. Next the architecture and information exchange for dynamic resilient virtual network setup are introduced. Then the necessary messages and architecture extension to allow shared protection in virtual networks are presented.

Afterwards the optimal virtual network design models with shared protection are provided. Then Simulations are conducted to show the gain resulting with shared

protection, wherein the simulation and the results are discussed later on.

In the following the dynamic creation of virtual networks will be explained. Before one can apply any shared protection for virtual networks in a first step the setup of virtual networks with amended GMPLS (Generalized

Multiprotocol Switching) technigues is described in the following. This is because one can expect that vendors and operators, as well, are highly interested to save recent capital investments in their network infrastructure when introducing the support of network virtualization . Several architectures and procedures are discussed in the prior art for the creation of virtual networks . The present model is based on the models and further detailed such that with minor modification and without excluding Software-Defined Networks (SDN) virtual networks can be dynamically set up and operated. The dynamic creation of virtual networks based on the roles SP . VNO, VNP and PIP in general can be split into the dissemination of Virtual Resource (VR) from the PIP which allows the VNP to have a limited view about the possibly VR available at the PIP which might be shared via an augmented OSPF, the reservation of the virtual network by VNO via VNP at the PIP, and the action of handing over of the control of the resulting virtual network from the PIP via the VNP to the VNO for further operation. The reguest of the virtual resource can be expressed by an augmented RSVPTE protocol such that after having calculated the mapping of the resources to the physical layer the RSVP Path message carries the individual VNetlDl (identifying the particular virtual network) and the particular VR within a new sub-object as additions to the ERO (Explicit Route Object) and SERO (Secondary

Explicit Route Object) objects, as defined in RFC4875.

While traversing the hosting physical nodes the augmented RSVP process attaches the selected Virtual Machines (VMs) and the corresponding virtual links to the local nodal physical interconnections and external forwarding plane links .

As with the conventional RSVP procedure the Resv message, which is a confirmation message to the Path message, the indication of successful allocation of the virtual

resources is returned back. In particular the Resv message is to carry the addresses of the virtual resources knowing that finally the VNO need to have access to the resources exclusively being granted. It is suggested that the addresses for the related configuration interfaces of the virtual resources are to be collected along the paths in a new sub-object attached to an augmented RRO (Record Route Object) and SSRO (Secondary Record Route Object) contained in the RSVP Resv message. Finally the Resv message arrives at the VNO, which enables the VNO to configure the

resources .

The above mostly focused on the mechanism to be able to set up a network for virtualized resources for plain

connectivity between the endpoints in guestion. However in future carrier grade Telco networks not only this simple connectivity is reguired. As of today, any customer and operator expects to be able to utilize and provide services with certain reguirements as for instance contracted via the SLA (Service Level Agreements) . Especially in case the VNP need to compose a network across several PIPs the guaranteed service availability (SA) need to receive special attention. The VNO wants to dynamically reguest a highly reliable virtualized network from the VNP. The VNP can either perform the resilience on its own responsibility or delegates it down to the PIPs. But whoever and wherever one of the involved parties places the task for performing the resilience, a dynamic mechanism is needed between them to decide and signal who is responsible for a particular virtual network. As RFC4872 defined the protection object which can indicate which kind of protection is to be applied (unprotected, 1+1, I:N, etc.) this can be exploited in the scope of network virtualization . With the signaling of the protection object the VNO requests the protection from VNP/PIP or no protection, if the object is omitted. In the latter case the VNP/PIP is not requested to protect the corresponding virtual network and the VNO can create an own dedicated backup virtual network for protection. On the other hand the VNO does not know the PIP and the physical location of the virtual resources leased by the VNO. None of the players is able to further optimize because of limited knowledge within their realm alone. Therefore it was of interest how one can gain from a shared protection in a virtualized environment. Subsequently an optimal virtual network design with shared protection will be explained. The mixed-integer linear problems (MILPs) used for optimal virtual network design with shared protection are introduced. There are proposed two models, one having resilience in the virtual layer, VNO-Resilience and the second one in the physical layer, PIP-Resilience . The models describe the sharing of

redundant virtual resources for different services within a VNet, however, it can be also applied for sharing redundant resources among different VNets by defining the services representing separate VNets. All the sets, parameters and variables used in both models are given in Table 1.

A. VNO-Resilience In VNO-Resilience, the resilience is provisioned in the virtual layer. This is enabled by providing the physical disjointness information of the virtual links to the VNO as described before. Each service is routed on k physically disjoint virtual paths in the VNet . For simplicity, k is taken as 2 in this model. In the following the constraints used in VNO-Resilience model are explained in detail.

(1) is the non-splitable link flow constraint and (2) states that if a node is used as the source or destination of a service, it would be flagged as used by that service. (3) and (4) state that a virtual link or node is part of the resulting VNet if it is used by any service,

respectively. (5) is the node capacity constraint

calculating the reguired capacity on the virtual nodes.

In VNO-Resilience the working and protection paths of each service need to be physically disjoint, which is ensured by (6)

Used protection capacity on link I e L , φ_ι e [0,∞]

Used working capacity on link / e L , ψ_ι e [0,∞]

Used capacity on node v e V , ω_ν e [0,∞]

Binary variable taking the value of 1 if the physical edge e e E is used for thef^h route of the demand d e Don the physical substrate, 0 otherwise

Binary variable taking the value of 1 if the physical edge e'≡E is used for the protection of the physical edge e G E for the demand d e D on the physical substrate, 0 otherwise

Used capacity on physical edge e'eE that is used for the protection of the physical edge e e E , _{e e}. e [0,∞]

Used protection capacity on physical edge e e E , _e e [0,∞]

Used working capacity on physical edge e e E , p_e e [0,∞] Used capacity on physical edge e . E , y_e e [0,∞]

Sets, parameters and variables used in the model

The following constraints enable shared protection in the virtual networks. The first path with the path indicator i = 1 is assumed to be the working path and the second path with I = 2 to be the protection path of a service. It is common to have the working path shorter than or equal to the protection path to decrease the latency of the services in normal operation. Therefore, (7) ensures that the first path is shorter than the second one.

∑s,(0_W -A_,</,/ )≤0 V e fl (7)

Constraints (8) and (9) are used to determine the value of the indicator τ^,Ι,Ι' showing if a certain link 1' is used to protect the link 1 for the service d. fii,_dj + Pi,j,r≤ 1 + ^_,/_,/_' e D; 1,1' e L, I≠ V (8)

(10) is used to calculate the protection capacity required on a link 1' due to the link 1 with all the involved should be at least the sum of the capacities of affected working links .

(13) is used to calculate the working capacity on each virtual link as the summation of the reguested capacities of all services using that link in their working path.

Finally, the total reguired capacity on each link is calculated in (14) as the summation of the reguired working and protection capacities.

The objective function used in VNO-Resilience model minimizing the setup cost of the VNet is presented in (15) . The cost is defined as the summation of link costs and node costs. Both link and node costs consist of two parts, namely the fixed setup cost of establishing a new virtual link or node and the capacity-dependent cost depending on the reguired capacity on this link or node.

B. PIP-Resilience Model

In case of PIP-Resilience, the resilience is provisioned by the physical layer and hence the sharing is also done in the physical network. In PIP-Resilience, the services are routed on a single path in the VNet and the protection is provisioned by mapping the virtual links on two disjoint physical paths. The constraints (l)-(5) form also the basis for PIP-Resilience. Since the sharing is performed in the physical network, the capacity calculation of the virtual links is done by simply summing over the capacity

reguirements of the services using that link as given in (16) .

To relate the routing information to the physical mapping, (17) and (18) set the values of the indicator for the working and protection physical edges depending on the service routing in the VNet and the mapping of the virtual links .

Similar to the VNO-Resilience model, the constraints (19) and (20) are used for determining the value of the

protection edge indicator v_d,_e,e' . This variable indicates if an edge e' is used for the protection of the edge e for the service d.

(21) and (22) calculate the protection capacities on the edges per working edge and generally, respectively, are used for the calculation of the working, protection and total capacity used on each physical edge. Constraint (23) is used to calculate the working capacity on the edges and finally, (24) computes the total capacity needed on the physical edges.

The objective functions needs to be updated for PIP- Resilience as given in (25) with the addition of network utilization minimization and the insertion of the

resilience premium compared with (15) . Physical network utilization should be minimized in case of PIP-Resilience to optimize sharing of the redundant resources . Network utilization is defined as the multiplication of the used capacity on an edge e, y_e, with the length of the physical edge, s_e.

It was looked at different cost settings in the analysis, where the cost of the virtual links can be either a fix value or dependent on the physical length of the virtual link. In PIP-Resilience, this length is calculated as the sum of the lengths of the two disjoint paths on which the virtual link is mapped. Hence, if the cost of the virtual link is a function of its length, the resilience premium due to the resilience provisioning by the PIP is implicitly included to the cost. However, for the case of fixed link cost, a resilience premium τ_Ρ1Ρ was defined, which is taken as 2 for the evaluations. Finally, the weighting factor τ_Νυ was defined to balance the weight of the cost and network utilization minimization.

In the following the simulator architecture and parameters used in the evaluation of the proposed models are

presented. The simulations are conducted with a Java

Virtual Network tool, which is enhanced to support shared protection models. For the performance evaluation, as the physical test network a NobelUS topology having 14 nodes and 21 links was used. The optimization problems are implemented using the IBM Concert library and solved with CPLEX 12.3.

In the simulations the models of PIP-Resilience and VNO- Resilience with shared protection are compared with each other as well as their corresponding models with dedicated protection. In each simulation, random VNets are generated, a certain number of service nodes were randomly selected from the physical network and uniform demands are reguested between all of them. For each generated VNet its properties are measured, which can be cost, delay, network utilization or number of the virtual links. The average of the

simulation aim value is taken at each simulation step for a different VNet until the results lie in a ±5% confidence interval with a confidence level of 95%.

Six cost settings were used in the simulations to create a framework for all possible cost values which can occur in the future in virtual networks. The cases are defined as guadruples; {the fixed link setup cost, the capacity dependent link setup cost, the fixed node setup cost, the capacity dependent node setup cost}. The cases are defined as A={Length, Length, 1, 1} . B={Length, Lenget, 2000, 2000 } , C={1, 1,1,1}, D={1,100,1,1}, E={100, 1,1,1} and F={ 1, 1, 100, 100 } . "Length" means that the resulting physical length of the virtual link j is used as the cost factor instead of using a fixed value. These six cases are chosen to investigate the effect of each individual cost component in case of fixed and length-dependent cost factors. Hence, in cases A and D the emphasis is on the link cost, in case F on the node cost and in B and C they are in the same level. Cases A and B assume that the link cost is dependent on the length of the virtual links, where for the remainder the link cost is set as a fixed value. In case B, the node cost factor is taken as 2000, which is a value in the range of average virtual link length for the used lest network. Finally, the value of the weighting factor τ_Νυ is

calculated as the ratio of the average cost values for each cost setting to the network utilization value. The value of τ_Νϋ used in the simulations for each cost setting is given as: τ_ΝϋΑ = 1. τ_ΝϋΒ = 2, τ_Νυα = 0.00067, v_NUD = 0.02, τ_ΝυΕ = 0.04 and v_NUF = 0.067.

In the following the simulation results are presented and evaluated. The simulations are carried out for 3 and 4 virtual service nodes due to the scalability issues.

However, they give a good insight for the gain offered by shared protection already for small virtual networks and form a good basis for development of heuristics.

Performance comparisons among the dedicated and shared protection models of VNO-Resilience and PIP-Resilience are provided to evaluate the gain provided by shared

protection. The performance of the two resilience models for shared protection with different cost settings are as well compared to form a framework as an answer to the guestion of at which business role resilience should be provisioned. All the results shown are for three virtual nodes. For the results shown in Fig. 6, the gain is calculated as the relative percentage difference of the performance values coming from shared and dedicated protection, where the bars show the gain for shared protection. Fig. 6a shows the gain in virtual network setup cost with shared protection. For the cost settings A and D. where the capacity dependent cost of the virtual links constitute a high portion of the total cost, a cost saving of around 20% is observed for VNO-Resilience . This

reduction is caused by the reduced capacity usage with the sharing of the redundant links. For PIP-Resilience the cost remains in the same range since the sharing is performed in the physical layer, which has no direct impact on the VNet cost. For PIP-Resilience in cost setting E, an increase of VNet setup cost is observed, which is due to the increased network utilization efficiency that is realized by using more and slightly longer virtual links as depicted in Fig. 6b, 6c and 6d, respectively. This increase reaches 23% for 4 virtual nodes. For the remaining cost settings both models provide similar gain levels for 3 and 4 virtual nodes .

Fig. 6b presents the gain in physical network utilization, which is defined as the multiplication of the used capacity and the length for all the physical edges. Since

minimization of the used capacity is directly part of the objective function in case of PIP-Resilience, it provides a high gain of more than 20% for all the cost settings, reaching 44% for cost setting B. VNO-Resilience also provides a gain of 20-30% in network utilization for the cost settings A, B and E, where the link cost is the dominant factor within the total VNet cost. For cost setting F, a slight increase in the network utilization and delay is observed, which is due to the nature of this cost setting where the link cost has almost no effect in the objective function and hence sharing is not optimized. The network utilization gain increases with increasing number of virtual nodes and reaches 27% and 58% for cost setting A with VNO-Resilience and PIP-Resilience, respectively, 42% for cost setting F and 70% for cost setting E with PIP- Resilience for 4 virtual nodes.

Delay performance comparison of shared and dedicated protection is presented in Fig. 6c. In the simulations only the propagation delay which is linearly related to the physical length of the path of a service were considered. However, the model can be directly applied for the end-to- end service delay. It was observed that shared protection increases the service delay for VNO-Resilience since the number and/or the length of the virtual link mappings is increased to enable sharing. For PIP-Resilience the increase in delay is lower and cost setting E results even in a gain in service delay due to the increased number of virtual links as shown in Fig. 6d. The results for maximum delay observed inside the VNet show the same trend as the average delay and are hence omitted due to lack of space. For 4 virtual nodes, the delay gain of PIP-Resilience decreases due to the increased network utilization

efficiency. However, the difference in delay for VNO- Resilience remains in the same range except for cost settings A and E, where for the former the excess delay reaches 21 % and for the latter vanishes completely.

Finally, Fig. 6d shows the difference in number of virtual links for VNO-Resilience and PIP-Resilience in case of shared vs. dedicated protection. In VNO-Resilience, except for the cost settings E and F, the number of the virtual links is decreased by 10-20%. In cost setting E, already for dedicated protection only 3 virtual links are used since the fixed setup cost of the virtual links is the dominant cost factor and hence it cannot be reduced more. For cost setting F, the link cost is not the dominant factor and hence no change in the number of the virtual links is observed. In case of PIP-Resilience, on the opposite to VNO-Resilience, 15-20% more virtual links are used in case of shared protection in cost setting A, Band E, which increase the cost slightly however provides a high network utilization gain.

In conclusion, shared protection reduces the VNet setup cost for VNO-Resilience up to 22% and the physical network utilization for both VNO-Resilience and PIP-Resilience, whereas for PIP-Resilience this gain can go up to 70% for 4 virtual node VNets. This gain occurs with the trade-off of increased delay for both models and increased number of virtual links for PIP-Resilience.

In Fig. 7 the performance of VNO-Resilience and PIP- Resilience is compared. The results in Fig. 7 are for 3 virtual nodes and the gain of VNO-Resilience is shown with positive bars. Fig. 7a shows the cost gain of VNO- Resilience to PIP-Resilience. It is observed that VNO- Resilience results in lower cost when the setup cost of the links is the dominant factor, which allows optimization of sharing and hence cost reduction in VNO-Resilience. The cost gain increases with 4 virtual nodes to 52% for cost setting A and to 83% for cost setting E. In cost settings C and F, where the cost of a node is egual to the link or is the dominant factor. PIP-Resilience offers a lower cost. Hence, the decision of the resilience provisioning layer would depend on the actual cost factors.

Regarding network utilization, delay and number of virtual links, PIP-Resilience always offer better results compared with VNO-Resilience, where the gain of PIP-Resilience can reach 30%, 35% and 50% for network utilization, delay and number of virtual links, respectively, as shown in

Figs. 7b, 7c and 7d.

Network virtualization is seen as a key enabler for future Internet and future networks allowing as well the

implementation and spreading of cloud services . Since future networks need to flexibly provide reliable services, virtual network (VNet) architectures are introduced allowing dynamic creation of resilient VNets. In

traditional networks, shared protection is applied to reduce the costs caused by the redundant resources used to enable resilience. However, the application of these mechanisms on virtual networks is not straight-forward due to the separation of the business roles along the vertical axis and the limited information each role possesses.

Therefore, a novel architecture for the application of shared protection in VNets is proposed. Moreover, a novel optimization models for the design of resilient VNets with shared protection at the physical and virtual layers are provided and simulations on these models are performed to evaluate their performance compared with dedicated

protection models. Simulation results show that models with shared protection outperforms the dedicated protection models with a reduction of the VNet setup cost of up to 22% and of the physical network utilization of up to 70% for the used topology and parameters. The simulations were performed under different cost settings and the results show for certain cost settings having resilience in the virtual layer bring a cost benefit of up to 83% for the used topology and parameters. However, having resilience in the physical layer results always in a lower delay, a lower number of virtual links and a higher network utilization efficiency .

In the following the figures 1 to 5 will be explained in more detail .

Fig. 1 schematically shows information exchange among roles/instances. In particular Fig. 1 shows a VNO 101 which sends a reguest message 102 including information

(SHARE (part x of V etlDl, part y of VNetID2, part z of VNetlDN, VnetID( N+l)) concerning an atomic activity to a VNP 103. In particular, the message includes the

information that the VNO would like to share parts of its virtual networks VNl, VN2, VNN on a virtual network VN(N+1). Then, VNP 103 sends a message 104 to PIP 105 including information/reguests concerning the shareability of x, y, z. After PIP 105 has determined whether the virtual resources can be shared a next message (sharing report) 106 is sent back to the VNP 103 including

information concerning the sharing, e.g. cost changes and sharing status. The VNP 103 forwards the respective message 107 to VNO 101, which then can send a further message 108 to the VNP 103 including information concerning whether it accepts or declines the specific offer. VNP 103 then forwards the further message 109 to the PIP 105.

Fig. 2A and 2B schematically show access to IT-resources . In particular, in Fig. 2A a system 200 is shown, on which a plurality of virtual machines 201, 202 and 203 are

implemented. As an example two virtual machines 204 and

205 belonging to two different virtual networks VNl and VN2 are schematically depicted as being implemented on virtual machine 201. A user communicates with the two virtual machines 204 and 205 via a scheduler 206. On contrary to that a user can access the virtual machines directly in the example of Fig. 2B as indicated by lines 210 and 211 bypassing the scheduler 206.

Figs. 3A and 3B schematically show label stacking for multiple ownership of a virtual link. In particular,

Fig. 3A shows the situation before a link is shared between two virtual networks VNl and VN2. In Fig. 3A a first node 300 is schematically depicted and is connected to links 301, 302 and 303. In addition a second node 306 is

connected to links 303, 304 and 305. The first virtual network VNl is formed by the two nodes and the connected links 301, 303 and 305, while the second network is formed by the two nodes and the connecting links 301 and 304.

In Fig. 3B it is schematically depicted that the link 303 is now commonly shared by both virtual networks VNl and VN2. It should be noted that in case a single VNO owns VNl and VN2 the VNO would own the third virtual network VN3 and is possibly free to place further virtual networks (VNx) on top of the VN3. Fig. 4 schematically illustrates an example of shared protection. In this figure, the physical topology is shown where the solid lines 401 show the unused (in terms of "physically" available for others, however, not assigned to any of the depicted virtual networks yet) edges for the current configuration and the further lines 402 show the mapping of the corresponding VNs . Each grey level and/or line type in Figs. 4A and 4B refers to a different VN . Wl and W2 are the mappings of two working paths shown with a solid line and pi and p2 are the corresponding protection paths shown with dashed fines. In Fig. 4A it can be seen that between the nodes A and B, a total capacity of 20/30 and 30/40 is reguired for each of the VNs . However, since the working paths are physically disjoint and the

protection paths are congruent, the protection paths can be directly shared. This results in a reduction of the reguired capacity, where a capacity of 30/40 is now sufficient on the link between nodes A and B. Sharing can be in general applied to multiple protection paths if the working paths are mutually disjoint.

Fig. 5 schematically illustrates an example of shared protection for non-congruent protection paths. In this example the protection paths pi and p2 of two disjoint working paths Wl and W2 are not collocated physically and hence sharing is not possible. If sharing is desired, one of the paths has to be re-routed to enable collocation of the virtual resources on the physical substrate. Some VMs might be also migrated if needed. In this case, the resulting changes in cost should be calculated and given to the reguesting VNO . As in Fig. 4 each grey level and/or line type in Fig. 5 refers to a different V .

Finally, it should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises , and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. In a device claim enumerating several means, several of these means may be embodied by one and the same item of software or hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

List of reference signs:

101 virtual network operator

102 request message

103 virtual network provider

104 message

105 physical infrastructure provider

106 sharing message

107 forwarded sharing message

108 accept message

109 forwarded accept message

200 system

201 virtual machine

202 virtual machine

203 virtual machine

204 virtual network

205 virtual network

206 scheduler

210 bypass

211 bypass

300 first node

301-305 links

306 second node

401 unused edges

402 used edges

Wl, W2 working paths

pi, p2 protection paths

Abbreviations

CAA conjunction allowed active

CAP conjunction allowed passive

PIP Physical Infrastructure Provider RRO Record Route Object

SRRO Subsequent Record Route Object

SP Service Provider

VN virtual network

VNO Virtual Network Operator

VNP Virtual Network Provider

MP2MP Multipoint to Multipoint

P2MP point to Multipoint

Claims

CLAIMS :

1. A method of allocating a virtual resource in a network comprising at least two virtual networks, the method comprising :

sharing the virtual resource among the at least two virtual networks .

2. The method according to claim 1, wherein the network comprises at least two instances and the method further comprises exchanging shareability information of the virtual resource via a message.

3. The method according to claim 2, further comprising: wherein the message includes information relating to at least one information out of the group consisting of: reguest for a sharing of the virtual resource;

offer to share the virtual resource;

cost information relating to the virtual resource; disjoint information concerning different virtual resources ;

topology of at least one network;

guality of service;

service level agreement;

virtual network ID.

4. The method according to claim 3, wherein the sharing of the virtual resource among at least two virtual networks is based on an analysis of the information included in the message .

5. The method according to any one of the claims 1 to 4, further comprising:

exchanging of a further message including information concerning a successful sharing of the virtual resource.

6. The method according to any one of the claims 1 to 5, wherein the sharing of a virtual resource relates to shared protection, and/or statistical multiplexing using shared virtual resources; and/or moving virtual resources from one virtual network to another virtual network.

7. The method according to any one of the claims 1 to 6, wherein the shared network is a congruent network or a non- congruent network.

8. The method according to any one of the claims 1 to 7, wherein the sharing of the virtual resource among the at least two virtual networks comprises a mapping of the virtual resource of one virtual network to the other virtual network.

9. The method according to any one of the claims 1 to 8, wherein the shared resource is associated with shared protection .

10. The method according to any one of the claims 1 to 9, wherein the sharing of the virtual resource includes the moving of the virtual resource from one of the at least two virtual networks to the other one of the at least two virtual networks .

11. A method of allocating virtual resources in a network comprising at least two network entities, the method comprising :

receiving a message at a network entity including information concerning a shareability of a specific virtual resource of the network; and

allocating the specific virtual resource as a shared virtual resource based on the shareability information.

12. The method according to claim 11, further comprising: sending the message from a further network entity to the network entity.

13. A network entity for a network,

wherein the network entity is adapted to perform a method according to any one of the claims 1 to 12.

14. The network entity according to claim 13,

wherein the network entity is a virtual network operator, a virtual network provider or a physical

infrastructure provider.

15. A network comprising at least two network entities according to claim 13 or 14.

16. A computer-readable medium, in which a computer program is stored, which, when being executed by a

processor, is adapted to control or carry out a method according to any one of the claims 1 to 12.