WO2012055446A1

WO2012055446A1 - Dynamic creation of virtualized network topology

Info

Publication number: WO2012055446A1
Application number: PCT/EP2010/066534
Authority: WO
Inventors: Klaus Hoffmann; Marco Hoffmann; Franz Rambach
Original assignee: Nokia Siemens Networks Gmbh & Co. Kg.
Priority date: 2010-10-29
Filing date: 2010-10-29
Publication date: 2012-05-03

Abstract

For providing resources from a physical network, provided by at least one physical network provider, to a virtual network provider, the following steps are performed: a) identifying a need for certain resources at the virtual network provider (S1); b) requesting resources from the at least one physical network provider (S2); c) conducting virtualization for creating the virtual network by (S3) : c1) identifying and selecting by the at least one physical network provider resources in the physical network (S3); c2) isolating the selected resources from other resources of the physical network and reserving them for exclusive use in the virtual network (S3); and c3) attaching unique identification, address and access information to the isolated and reserved resources in order to enable exclusive accessibility in the virtual network (S3); d) reporting, from the physical network provider to the virtual network provider, a result of the virtualization with information concerning identification, addressability and accessibility of the selected resources (S4); and e) handing over control, from the physical network provider to the virtual network provider, of the resources reserved (S5).

Description

Dynamic Creation of Virtualized Network Topology

BACKGROUND OF THE INVENTION Field of the Invention

The present invention relates to network virtualization. In particular, the present invention relates to dynamic creation of virtualized network topology.

Related Background Art

Prior art which is related to this technical field can e.g. be found in "Network Virtualization from a Signaling Perspec- tive" by Roland Bless and Christoph Werle, Future-Net '09 In^¬ ternational Workshop on the Network of the Future 2009 in conjunction with IEEE ICC 2009, Dresden, June 16th-18th, 2009, "Implementing Network Virtualization for a Future Internet" by P. Papadimitriou, 0. Maennel, A. Greenhalgh, A. Feldmann, and L. Mathy, 20th ITC Specialist Seminar on Network Virtualization, Hoi An, Vietnam, May 2008, as well as Request For Comments (RFC) Nos. 4461, 4655, 4657, 5305, 5810 issued by the IETF. The following meanings for the abbreviations used in this specification apply:

3GPP - 3rd generation partnership project

CAA - conjunction allowed active

CAP - conjunction allowed passive

ERO - explicit route object

IP - Internet protocol

NE - network element

PCE - path computation element

PCEP - path computation element protocol PIP/InP - physical infrastructure provider/infrastructure provider

POP - point of presence

PR - physical resource

RRO - record route object

RSVP - resource reservation protocol

SERO - subsequent explicit route object

SLRG - shared risk link group

SRRO - subsequent record route object

UE - user equipment

VM - virtual machine

VNO - virtual network operator

VNP - virtual network provider

VR - virtual resource

In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), broadband networks, and especially the Internet and other packet based networks based e.g. on the Internet Protocol (IP), Ethernet, MPLS/GMPLS or related technologies and preferably using opti^¬ cal transmission based on SDH/SONET and/or WDM/DWDM, or wireless communication networks, such as the cdma2000 (code divi^¬ sion multiple access) system, cellular 3rd generation (3G) communication networks like the Universal Mobile Telecommuni^¬ cations System (UMTS) , enhanced communication networks based e.g. on LTE, cellular 2nd generation (2G) communication networks like the Global System for Mobile communications (GSM) , the General Packet Radio System (GPRS) , the Enhanced Data Rates for Global Evolutions (EDGE) , or other wireless commu^¬ nication system, such as the Wireless Local Area Network (WLAN) or Worldwide Interoperability for Microwave Access (WiMAX) , took place all over the world. Various organiza^¬ tions, such as the 3rd Generation Partnership Project (3GPP) , Telecoms & Internet converged Services & Protocols for Ad^¬ vanced Networks (TISPAN) , the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers) , the WiMAX Forum and the like are working on standards for telecommunication net- work and access environments.

Recent technology progress deals with network virtualization, which splits the conventional monolithically owned, used and operated networks into subsets to be used, operated and man- aged by different, organizationally independent organiza^¬ tions. Basically, network virtualization is a concept to cre^¬ ate logical network resources, e.g. virtual nodes and virtual links, that form a virtual network, from physical resources. The use of network virtualization promises additional flexi^¬ bility and offers opportunities for deploying future network architectures. That is, network virtualization enables for the creation of logically isolated network partitions over a shared physical network infrastructure, wherein the network virtualization can be driven by the needs in, for example, an enterprise domain. Furthermore, network virtualization covers network elements and protocols that together maintain a co^¬ herent end-to-end view of a virtual network. Basically, network virtualization is considered in 3 main sections :

Network elements: how is traffic separation and iso^¬ lation of different virtual networks maintained in- ternal to a network element for the data part and the control part;

Data path: how is traffic separation enforced across a network path;

Control plane: what extensions to protocols are needed to control and manage partitioned resources

(access to NEs and between NEs) . Considerations regarding network virtualization are made, for example, in connection with several projects, for example 4WARD (European-Union funded) and G-Lab (German national funded) . Results of such projects introduced, for example, a separation into different roles regarding network virtualiza^¬ tion, i.e. a Virtual Network Operator, VNO, role or level, a Virtual Network Provider, VNP, role or level, and a Physical Infrastructure Provider or just Infrastructure Provider, PIP/InP, role or level.

PIP/InP are infrastructure providers, e.g. large companies that own the infrastructure required to enable communication between different locations and which provide end users with access to their networks. Infrastructure providers may also enable the creation of virtual nodes and virtual links on top of and using their own physical resources and provide them to another party.

VNP is a provider which represents an intermediate party be- tween a VNO and the infrastructure providers. This is de^¬ picted, for example, in Fig. 2 which shows a diagram illus^¬ trating the hierarchical levels of entities involved in a creation (or modification) of a virtual network, as well as the responsibilities thereof, in comparison to a "normal" (or conventional) network. The VNP is capable and equipped, for example, to compose and provide a virtual network slice as requested by a VNO from physical resources of one or more in^¬ frastructure providers. The VNO, on the other hand, can install and instantiate a network architecture using the virtual network slice and properly configure it. After the virtual network has been set up, end users may attach to it and use the service it pro^¬ vides. A VNO may provide a service in the virtual network by itself or allow other service providers to offer their ser^¬ vices, e.g., an IP-TV service, inside the virtual network. That is, the VNP is supposed to request and collect virtual resources from a PIP/InP, and to form a whole virtualized network on behalf of a VNO, which in turn operates this vir^¬ tual network. In that way, the physical resources of a

PIP/InP are separated and transformed into virtual resources provided to and managed by a VNP, and configured to form vir^¬ tual networks finally handed over to VNOs for operation and use. In that way also the control of such virtual resources, even if implemented as shares of the same physical entities, is completely handed over to the virtual network operator us^¬ ing it.

Fig. 1 shows an exemplary example of a general virtual net^¬ work topology. The virtual network may span various network domains that belong to different PIP/InP networks 1, 2, 3. End users 4 to 6 can connect to the (virtual) network infra^¬ structure. Within the network domains belonging to the dif^¬ ferent PIP/InP networks 1, 2, 3, the virtual network can use virtual or physical resources (virtual nodes are indicated by black filled circles, physical (or substrate) nodes are indi^¬ cated by white filled circles) to create a virtual network via virtual links (indicated by dashed lines) which run over physical links (solid lines) established between respective nodes .

SUMMARY OF THE INVENTION

The present invention aims at enabling full control, for a virtual network provider, of a virtual network established by means of resources provided by at least one physical network provider .

This is achieved by the methods, apparatuses, systems and computer program product as defined in the appended claims. In the following the present invention will be described by way of embodiments thereof taking into account the accompany^¬ ing drawings . BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 shows an exemplary example of a general virtual net^¬ work topology. Fig. 2 shows a schematic diagram illustrating levels for pro^¬ viding the general virtual network topology.

Fig. 3 shows a schematic block diagram illustrating an arrangement of a virtual network provider and a physical net- work provider according to an embodiment of the invention.

Fig. 4 shows a schematic block diagram illustrating the functions allocated to the virtual network provider according to an embodiment of the invention.

Fig. 5 shows a schematic diagram illustrating a model of vir- tualized resources on a hosting node according to an embodi^¬ ment of the invention. Fig. 6 shows a schematic diagram illustrating a dissemination of information on resources within PIP using enhanced IGP according to an embodiment of the invention.

Fig. 7 shows a schematic diagram illustrating creation of a network structure in a physical network of the physical net^¬ work provider according to an embodiment of the invention.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Referring to Fig. 3, a virtual network provider 10 and a physical network provider 20, such as a physical infrastruc ture provider, according to an embodiment of the invention are shown. There may be more than one physical network pro^¬ vider 20 which provides a physical network from which resources can be provided to the virtual network provider 10.

When the virtual network provider 10 identifies a need for certain resources in a step SI, it requests resources match^¬ ing the identified need from the physical network provider 20 in step S2.

Upon receiving the request, in step S3 the physical network provider 20 conducts virtualization for enabling the virtual network provider 10 to create a virtual network out of re^¬ sources of the physical network provided by the physical net- work provider 20. It is to be noted that the virtual network provider 10 may create more than one virtual network out of resources provided by the physical network provider 20.

In the virtualization, the physical network provider 20 iden- tifies and selects resources in the physical network based on the requested resources, isolates the selected resources from other resources of the physical network and reserves them for exclusive use in the virtual network, and

attaches unique identification, address and access informa- tion to the isolated and reserved resources in order to en^¬ able exclusive accessibility in the virtual network.

Such access information may e.g. comprise one or more of an identification (or name) allocated to a certain piece of re- sources, a physical address and/or a virtual address for ac^¬ cessing these resouces for use, information about protocols supported by or required for using these resources, a physi^¬ cal and/or virtual address for getting access to control of these resources, protocols to be used for controling these resources, or any other information required for or suitable to support access to the usage and/or the control of these resources .

In step S4, the physical network provider 20 reports to the virtual network provider 10 a result of the virtualization with information concerning identification, addressability and accessibility of the selected resources, and hands over control of the resources to the virtual network provider 10, which are reserved for exclusive use in the virtual network.

In step S5 the virtual network provider 10 assembles these resources to compose the virtual network e.g. for providing telecommunication services.

The virtual network provider 10 may identify the need for certain resources based on a given traffic demand created by users, a request from a customer or a request from a virtual network operator, regarding a modification of an existing virtual network or a creation of a new virtual network.

The physical network provider 20 may advertise to the virtual network provider 10 capabilities and capacities regarding technological attributes of the physical network. For exam^¬ ple, the physical network provider 20 may offer a router or a switch of a certain transmission technology and/or a link having special bandwidth.

In the virtualization, according to an embodiment of the invention, the physical network provider 20 may compute a net- work structure out of the selected resources, including paths between nodes, determine whether a signaling to a starting node of the paths is routed via other nodes being not part of the selected resources, and if the determination is positive, include in the signaling an indication for informing the other nodes that they are not part of the selected resources. Furthermore, in the virtualization the physical network pro^¬ vider 20 may determine whether to allow a conjunction between nodes on branched network paths, and if the determination is positive, include in the signaling an information element in- dicating the nodes between which the conjunction is to be established. The physical network provider 20 may then report information on allowed conjunctions between the nodes to the virtual network provider 10 in the information concerning identification, addressability and accessibility of the se- lected resources (S4).

According to an embodiment of the invention, for carrying out the above operation, the virtual network provider 10 may comprise at least one control unit (one shown in Fig. 3) com- prising at least one processor 11 providing processing resources, at least one memory 12 providing memory resources, and at least one interface 13, which are interconnected by a bus 14 or any other suitable means. The memory 12 may func^¬ tion as a working area for the processor 11 for performing steps SI and S5, for example, and may also function as a storage for storing a program which includes software code causing the processor 11 to carry out the above operation, as well as for any other purposes needing to store program code or data. The interface 13 may carry out sending the request and receiving the response of steps S2 and S4, for example.

Fig. 4 shows a schematic block diagram which illustrates a functional implementation of a control unit comprising a re^¬ source control unit and a decision unit. The resource control unit as one of the control units of the virtual network pro^¬ vider performs step S4 (receive resources/control), for exam^¬ ple. The decision unit as another one of the control units of the virtual network provider receives a traffic demand and a resource request as well as special technology information and performs step S2 (request resources) and a release of re^¬ sources, for example. It is obvious to anyone skilled in the art that a control unit comprising means to perform such functions can be implemented on a central or with distributed computing devices. For carrying out the above operation of the physical network provider 20, the physical network provider 20 may comprise at least one control unit (one shown in Fig. 3) comprising at least one processor 21 providing processing resources, at least one memory 22 providing memory resources, and at least one interface 23, which are connected by a bus 24 or any other suitable means. The memory 22 may function as a working area for the processer 21 for performing step S3, for example, and may also function as a storage for storing a program which includes software code causing the processor 21 to carry out the above operation, as well as for any other purposes needing to store program code or data. The interface 23 may carry out receiving the request and sending the response of steps S2 and S4, for example. It is again obvious to any^¬ one skilled in the art that a control unit comprising means to perform such functions can be implemented on a central or with distributed computing devices.

The resources selected in the virtualization may comprise at least one of the following group or groups:

- network nodes or parts of them,

- control entities including computing devices, or parts of them including shares of memory, processing capacity, execution times,

- ports,

- links,

- transmission capacities, and

- paths comprising partial paths and/or end-to-end paths. Note, that resource "virtualization" by definition goes be^¬ yond the boundaries of physical resources and as well com- prises the notion of virtual resources such as e.g. virtual nodes, virtual ports, virtual links, virtual paths, etc.. A network node or node may comprises a role or function of at least one of the following group or groups:

- an access node,

- point of presence,

- transit node, and

- traffic and/or signaling gateway.

The physical network may comprise or consist of equipment lo- cated at customer premises. Thus, the physical network may include potential resources provided by a customer or private network, an enterprise network or the network of a service provider. Such customer premises equipment (CPE) includes terminals and networking equipment located at private

premises, such as e.g. computers, phones, routers, switches, (residential) gateways, set-top boxes, etc. arranged as individual terminals, in networks, server farms, etc.

Ports, links, transmission capacities and paths may be imple- mented on and using physical entities of any type of trans^¬ mission technologies comprising at least one of the following group or groups :

- analog or digital,

- electrical or optical, and

- using wires, fibers or radio transmission.

Different types of higher layer mechanisms and protocols, such as, but not limited to, Ethernet, IP, MPLS, GMPLS, etc. are well known to the practitioner as being suitable to be used on top of these technologies singularily or in combina- tion in the user and/or the control plane.

There is also an option to partially or completely dissolve (or tear down) an existing virtual network. Therefore, upon identifying of no further need for certain resources, the virtual network provider 10 may return control of these re- sources to the physical network provider 20, that provided these resources.

In the following, examples of embodiments for providing re- sources from a physical network, provided by a physical in^¬ frastructure provider, e.g. the physical network provider 20, to a virtual network provider, e.g. the virtual network pro^¬ vider 10, such that the virtual network provider 10 is enabled to assemble these resources to compose at least one virtual network for providing telecommunication services will be described.

Virtualization of physical resources A mechanism for virtualizing physical resources of the physi^¬ cal network and keeping track of virtualized resources by the physical network provider according to an example of the invention will be described. Fig. 5 shows a schematic block diagram illustrating a model of virtualized resources on a hosting node.

As shown in Fig. 5, several VMs (virtual machines) can be de^¬ ployed on a physical hardware/resource (PR) of the physical infrastructure provider (PIP) . The physical resource may have several physical links, and the VMs may share resources on the same physical link as shown in Fig. 5. The physical re^¬ source further comprises a scheduler which allows isolation of the different VMs. In addition the scheduler knows the different physical links and their capabilities, and may separate resources of the different VMs by allocating dedi^¬ cated address spaces for each VM within the physical link in question. The address space separation for instance can be achieved by e.g. introducing an additional label (denoted with 1,2,3) on top of a label of/for an underlying labelled physical link. As such a physical node can carry several vir- tual links on one physical link, and can multiplex data to the corresponding VM. Within an address space of a VM, the physical node can allocate again its own address space, for instance denoted by a and b. Therefore, each VM is completely independent from the other VMs and especially from hardware on which it is running.

It is to be noted that the hosting node is supplied with its own physical address. Furthermore each of the VMs are as- signed with dedicated addresses identifying the VM independ^¬ ently from the physical address of the hosting node. As such a decoupling of VM and hardware is possible, however a corre^¬ lation table between them is needed. Usually, network elements are supplied with a control plane such as GMPLS (generalized multi protocol label switching) including RSVP-TE (resource reservation protocol - traffic engineering) and OSPF-TE (open shortest path first - traffic engineering) with which switching technologies such as TDM (time division multiplex), Lambda, packets, etc. are covered.

Therefore, virtualizing physical hardware can be supplied with an enhanced CP (control plane) such that for instance the VMs shown in Fig. 5 and virtualized bandwidth on physical links can be seen as an attribute/capability within GMPLS.

Hence, the hosting node may run enhanced OPSF* and RSVP* in^¬ stances for virtualized resources in a control link. Based thereon the PIP may internally announce and reserve virtual resources, e.g. VM and bandwidth possibly to be assigned to the VM as dynamically required, on top of its own physical resources. As such the CP together with the help of the scheduler keeps track of the utilisation of the VMs and the bandwidth allocated to them, especially as well as resources still available for usage by potential new upcoming demands. With this approach the PIP may run its own CP (e.g. GMPLS) on its own physical network, by which it can allocate and grant virtual resources (connectivity for paths or whole networks) as required by a VNP (virtual network provider) . A virtual network operator (VNO) then can run in the VMs and within the address space being granted the protocols it wants to deploy.

Hence, in a virtual network which runs within connected VMs, an additional control plane e.g. based on RSVP and OSPF-TE can be deployed, however clearly separated and isolated and, thus, in principle invisible from the control plane of the PIP and vice versa.

The PIP (physical infrastructure provider) may require to have a view of the utilisation of its resources within its network with regard to the virtualized resources.

Therefore, the following information elements may be intro^¬ duced into an IGP (interior gateway protocol) such as e.g. OSPF or IS-IS (intermediate system to intermediate system) protocol :

- a measure for processing resources or control performance, e.g. including at least one of a processor type + MIPS, rout^¬ ing operations (or packets) per second, and busy hour connec- tion attempts (BHCA) ;

- memory capacity;

- storage capacity;

- kind of virtualization technique; and

- an identifier of capabilities of the virtual resources with the physical network.

An indication about the kind of virtualisation being applied on the hosting node is preferable. This is especially of im^¬ portance as the VNO finally using the virtualized network will insist on getting a VM which is the same VM it may have already in use in its legacy network without the capabilities provided by the present invention, thus saving its investment in education of operator personnel. An example of an imple^¬ mentation will be described later on. These information elements may be distributed in IGP messages of OSPF (or /IS-IS) as schematically shown in Fig. 6, depict^¬ ing virtual resources VRs on top of the hosting node together with virtual links (shown as solid lines) riding on physical links (shown as dashed lines) . In this context it is to be noted that a virtual network does not necessarily have to make use of and/or share resources of all physical nodes or links .

Referring to Fig. 6, an enhanced TCE/PCE (topology computa- tion element/path computation element) of the PIP may collect information of the virtual and physical resources, e.g. using enhanced IGP dissemination within the PIP. This enables the PIP to keep track of its own network, where for each node data for virtualized resources are kept and correlated with the physical node. Virtual resources attributes to be kept in a database of the PIP, e.g. an enhanced TED (traffic engi^¬ neering database) , correspond to the above information ele^¬ ments and comprise e.g. a measure for processing resources or control performance, e.g. including at least one of a proces- sor type + MIPS, routing operations (or packets) per second, and busy hour connection attempts, memory capacity, storage capacity, kind of virtualization technique, and an identifier of capabilities of the virtual resources with the physical network .

With this approach the PIP itself will have a notion of its resources available.

Also attaching this information to RSVP-TE attributes of the IGP utilizes capabilities of the protocol also for the an^¬ nouncement of virtual resources based on a stable and already deployed technology, thus minimizing the impact on existent networks, which are very likely to be expected to evolve to also be part of the market of virtualized network resources. By this the virtualization becomes available not only for IP (internet protocol) packet forwarding technology, but also in general for any transport layer such als TDM, PSC (packet switching capability) , LSC (lambda switching capability) , etc. Preferably, an ISC (interface switching capability) is enhanced with another switching capability like for instance a virtualized resource capacity VRC (to be described later on), and then can be further detailed/enhanced via another indication carrying what kind of virtualized resource (such as a virtualizing software) is deployed on the node in ques^¬ tion, as this in particular may vary with the vendor of nodes in question.

When the virtual network provider (VNP) 10 requests resources or possibly asks for the availability of such resources, the physical network provider (PIP) 20 may receive, for instance, at some point of presence (POP) for the enhanced PCEP

(PCEP*), a corresponding PCEP* request. This point of presence, which may not have to have access to the data plane, but which may act as a simple proxy, in turn queries the PCE of the PIP for resources computation.

Once an optimal network structure has been calculated out of selected resources, which includes paths between nodes, and returned by the PCE, there needs to be a means to set up the actual network structure and allocate the resources in the PIP. For example, the point of presence, after the response from the PCE was received, may forward/issue for instance an RSVP Path request e.g. via an RSVP POP of the PIP towards an origin of the path to be created between the origin and a destination. More details about setting up the actual network structure will be described later on in further examples of the invention. Alternatively, the PIP may augment management plane means, by which a starting node/point of a path or network may be triggered to create a path with the virtualized resources to the required destination.

In both cases the VNP is informed about details of the re^¬ sources being allocated, for its further usage. If the VNP does not commit the reserved resources within a certain time- period, the PIP, depending on its policies, may or may not release the resource being allocated.

It may be possible that the PCE and the PCEP* POP of the PIP are collocated.

During the process of setting up the network structure for the virtual resources, not only connectivity between the nodes needs to be ensured, but also the identification/name of the virtual resources being allocated need to be collected in the forward direction, as for instance:

VNetID (Virtual network Identification) ,

VNode-ID (virtual Node Identification) and

Virtual interface (Vif) ,

because the VNO (virtual network operator) via VNP needs to know the resources for its access to them.

Thus, also in the response to a path request, e.g. RSVP Path request, the addresses of allocated virtual resources as shown in Fig. 5, where each VM is assigned an dedicated ad- dress actually residing on the hosting hardware, need to be returned, as will be described later on.

Again depending on the level of trust relationship, the content of signalling may be stripped before forwarding to the VNP in order to hide confidential information. In the following a possible implementation of the above example will be given.

Enhancement to IS-IS-TE:

Information elements:

Modification and definition of the ISC (interface switching capability) for the virtualisation like the following: Interface Switching Capability Descriptor

The Interface Switching Capability Descriptor is a sub-TLV (of type 21) of the extended OSPF reachability TLV. The length is the length of the value field in octets. The fol- lowing illustrates encoding of the Value field of the Inter^¬ face Switching Capability Descriptor sub-TLV.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Switching Cap | Encoding | Reserved I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 0 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 1 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 2 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 3 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 4 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 5 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 6 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Max LSP Bandwidth at priority 7 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Switching Capability-specific information I

I (variable) I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Switching Capability (Switching Cap) field contains one of the following values:

1 Packet-Switch Capable-1 (PSC-1)

2 Packet-Switch Capable-2 (PSC-2)

3 Packet-Switch Capable-3 (PSC-3)

4 Packet-Switch Capable-4 (PSC-4)

51 Layer-2 Switch Capable (L2SC)

100 Time-Di ision-Multiplex Capable (TDM)

150 Lambda-Switch Capable (LSC)

200 Fiber-Switch Capable (FSC)

125 Virtualized Resources Capable (VRC)

Furthermore the Switching capability-specific information for the VRC is defined as follows.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I kind of virtualization I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The kind of virtualization field contains one of the follow^¬ ing values :

1 VM CISCO

2 VM Juniper

3 VM reserved for other vendor

4 VM reserved for other vendor

5 VM reserved for other vendor

6 VM reserved for other vendor

7 VM reserved for other vendor 8 Openflow virtualization

9 ForCES (RFC5810)

Enhancement to OSPF-TE:

Information elements:

See IS-IS-TE described above

Enhancement to RSVP-TE:

Information elements:

Modification of the generalized label request in order to be able to request VR.

The information carried in a Generalized Label Request is:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I LSP Enc. Type | Switching Type | G-PID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LSP Encoding Type: 8 bits. Indicates the encoding of the LSP being requested. The following shows permitted values and their meaning:

Value Type

Packet

Ethernet

3 ANSI/ETSI PDH

4 Reserved

5 SDH ITU-T G.707 / SONET ANSI T1.105

6 Reserved

7 Digital Wrapper

8 Lambda (photonic)

9 Fiber

10 Reserved 11 FiberChannel

12 Virtualized resources itching Type: 8 bits Value Type

1 Packet-Switch Capable-1 (PSC-1)

2 Packet-Switch Capable-2 (PSC-2)

3 Packet-Switch Capable-3 (PSC-3)

4 Packet-Switch Capable-4 (PSC-4)

51 Layer-2 Switch Capable (L2SC)

100 Time-Division-Multiplex Capable (TDM)

150 Lambda-Switch Capable (LSC)

200 Fiber-Switch Capable (FSC)

125 Virtualized Resources Capable (VRC)

The Generalized PID (G-PID) : 16 bits is augmented with the following information:

The kind of virtualization field contains one of the following values :

51 VM CISCO

52 VM Juniper

53 VM reserved for other vendor

54 VM reserved for other vendor

55 VM reserved for other vendor

56 VM reserved for other vendor

57 VM reserved for other vendor

58 Openflow virtualization

59 ForCES (RFC5810)

Modification of the Resv message by adding the virtual re^¬ sources object , defining address of the virtual machine like the following: <Common Header> [ <INTEGRITY> ]

[<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]

[ <MESSAGE_ID> ]

< IME_VALUES>

[ <RESV_CONFIRM> ] [ <SCOPE> ]

[ <NO IFY_REQUEST> ]

[ <ADMIN_STATUS> ]

[ <POLICY_DATA> ... ]

[ Virtual resources] Definition of the virtual resources object: Virtual resources

The following illustrates encoding of the Value object of the virtual resources listing the addresses of the virtual re^¬ sources and the correlated physical address of the hosting node .

The Object may be carried in Path message preferably as part of the RRO (record route object) . The format is:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I Length I Class-Num (x) | C-Type (y) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I virtual IPv4 Address on hostl I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I virtual IPv4 Address on host2 I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I virtual IPv4 Address on hostn I

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also the PCEP protocol is enhanced accordingly.

OSPF* (enhanced OSPF) and I S - I S * (enhanced I S - I S ) are dis^¬ tributing the availability of the virtual resources within the control plane of the PIP's network. Consequently the vTED (TED collecting the virtualized resources) derives the infor^¬ mation about the virtualized resources and capacity of the virtualized links e.g. via the Interface Switching Capability Descriptor indicating the information VRC and the additional specific information about what kind of virtualization is available. Within the PIP virtualization may be supported by the enhanced RSVP via the Path message with the augmented La^¬ bel request switching type for virtual resources and the kind of virtualization required. In the Resv message the address of the virtual resources are sent back to the node which is^¬ sued the Path request.

Computing and setting up the network structure for the vir^¬ tual resources

Conventionally, an RSVP PATH message requires a router to al^¬ locate and connect its "incoming" and "outgoing"

data/forwarding plane/flow ports. However the RSVP needs to traverses transparently for in^¬ stance to the origin of a requested connectivity, where it then in turn may start its path reservation up to the destination of the flow. In other words, when computing the network structure out of the selected resources in the physical provider network, which network structure includes paths between nodes, there may be other nodes which have to be traversed which do not belong to the selected resources. According to an example of the invention, the RSVP protocol is modified (the modified or enhanced RSVP is called RSVP*) by introducing a "transparency" flag/indication in the RSVP Path message requiring that the message is simply to be for- warded unmodified, without starting to allocate resources and internally connect the "incoming" and "outgoing"

data/forwarding plane/flow ports. Only that RSVP aware node/router, which recognises that the "router ID" being signalled as well, is its own router ID, will start the alloca- tion of its "internal" resources, and also will issue a con^¬ ventional RSVP path message, especially by removing the in^¬ formation elements router ID and "transparency" flag and re^¬ quest the next hop/node/router to allocate its resources along the path up to the destination. In the backward direc- tion the same procedure is to be applied as well in the oppo^¬ site order. However, once the response was received in the backward direction, the "transparency" indication does not need to be kept anymore, since the path was setup success^¬ fully.

As shown in Fig. 7, an enhanced PCE (PCE*) of the PIP issues a resource reservation message (signalling), e.g. RSVP*, to a corresponding point in the PIP, e.g. an RSVP POP of the PIP. As only the resources A, B, C, D, E, F, G, H and I have been computed as selected resources, an indication is included in the signalling for informing the other nodes (hatched nodes in Fig. 7) that they are not part of the selected resources. As a result, no data plane is established along a path from the PCE* to the node A, whereas a data plane is established along paths shown as dotted and dashed lines.

A possible implementation example is described below. "Transparency" flag/indication in the RSVP Path message

Modification of the Path and Resv message by adding the new "transparency" object like the following:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]

[ [ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ...] [ <MESSAGE_ID> ]

The flag Object may be carried at least in the Path and Resv message. The format is:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 Length | Class-Num (a) | C-Type (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I Flag | Reserved I

Flag definition

Value Type

1 transparency

Again referring to Fig. 7, the VNP such as the virtual network provider 10 of Fig. 3, requests from the PIP such as the physical network provider 20 of Fig. 3, resources e.g. by is^¬ suing a request according to PCEP* from a PCE/TCE* of the VNP via a PCEP* POP of the VNP to a PCE/TCE* of the PIP via a PCEP* POP of the PIP. Based upon this request, the PIP calcu^¬ lates a network structure in a process of virtualizing physi^¬ cal resources of its physical network in order to meet the request from the VNP.

For setting up the network structure calculated e.g. by the PCE/TCE*, e.g. a PIPs PCC (path computation client) will therefore then issue one or more reservation requests e.g. RSVP requests— As described above, the RSVP* Path message may also be trig^¬ gered by a management plane to set up the calculated network structure .

Furthermore, collected information about the resources se- lected, isolated and reserved in the PIP, which may be re^¬ ceived in the Resv message of the RSVP* protocol within the PIP's network, may be mapped to a PCEP* response and conse^¬ quently those collected information can be handed over to the VNP and then to the VNO for further usage in the virtualized network environment.

Again referring to Fig. 7, the VNP may request resources via the PCEP* from PIP. The PIP receives the request and consults an internal or ex^¬ ternal PCE identifying and selecting resources in the physi^¬ cal network provided by the PIP based on the requested re^¬ sources and to compute a structure of a network out of se^¬ lected resources which includes nodes and paths between nodes.

According to an implementation example of the present invention, the PCE returns ERO (explicit route object) and SERO (subsequent explicit route object) (and possibly carrying CAP and CAA objects defined later on), describing a path of the network to be built on the physical nodes to set up the net^¬ work structure and to fetch the selected resources, thereby isolating the selected resources from other resources of the physical network and reserving them for exclusive use in the virtual network to be created by the VNP, and deriving unique identification, address and access information for the iso- lated and reserved resources in order to enable exclusive ac^¬ cessibility in the virtual network.

The SERO carries the subsequent nodes to the ERO, where a branch is to be built.

Based on this the RSVP reservation procedure is triggered with the ERO and SERO. For instance, referring to Fig. 7, as^¬ suming that a network is to be built by connecting selected resources A (edge/address 1), F (edge/address 2) and I

(edge/address 3), ERO is calculated as {A, B, C, D, E, F}, and a path message is sent from A to F via B, C, D and E. In the example shown in Fig. 7 only one SERO {B, G, H, 1} fol^¬ lows, i.e. another path message is sent from B to I via G, and H describing the remaining network.

In order to provides for an interconnection between nodes of branched paths, e.g. nodes G and C, according to the imple^¬ mentation example, information elements called CAP "conjunc- tion allowed passive" and CAA "conjunction allowed active" are introduced in order to allow a connection between G and C.

These information elements are attached to the ERO and SERO objects indicating that a conjunction is allowed between the nodes G and C like the following:

ERO {A, B, C, D, E, F} , CAP {C, G}, SERO {B, G, H, 1} CAA {G, C}.

The CAP object (attached/correlated with the ERO) indicates to the node C that it can expect to receive a path message from G with the request to connect with G. If such a request is received in the node C it performs the conjunction with a Resv response. On the other hand the CAA object, which is correlated with the SERO object requests the node G to ac- tively request a connection via a path message with the node C. On receipt of the response from C the node performs the conj unction . With this approach the nodes G and C may connect virtual re^¬ sources/machines and corresponding links between them to^¬ gether in addition to the already created paths {A, B, C, D, E, F } and {B, G, H, I } . Moreover, with this approach the selected resources can be isolated and reserved with RSVP* Path and the information re^¬ lating to the isolated and reserved resources can be returned in the RSVP* Resv message. A SRRO (subsequent Record Route object) and an RRO (Record Route object) may also be attached with the CAP and CAA.

Final Resv message (s) may be mapped to a PCEP* response to the VNP. This response carries a result of the virtualization with information concerning identification, addressability and accessibility of the selected resources, and control of the resources reserved for exclusive use in the virtual net^¬ work is handed over from the physical network provider to the virtual network provider. Therefore the CAP and CAA objects may also be signalled in the enhanced PCEP* protocol.

In the following a possible layout of the information ele^¬ ments CAP and CAA is given:

The layout of the CAP (Conjunction allowed passive Object) :

Allowed passive conjunctions are specified via the conjunc^¬ tion allowed passive object (CAP).

The object has the following format: 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I I

// (Subobjects) //

I I

The contents of an CAP object is a pair of variable-length data items called subobjects. The subobjects are defined be^¬ low .

Subobj ects The contents of a Conjunction allowed passive object is a list of pairs of Node addresses (between which a conjunction is to be performed) in a series of variable-length data items called subobjects. Each subobject has the form: 0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // +

I Type I Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // +

Type

The Type indicates the type of contents of the subobject. Defined values are:

1 IPv4

2 IPv6

Length

The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. For the definition of the Conjunction allowed active Object see the definition of the Conjunction allowed passive Object.

The CAP and CAA are attached to the ERO, SERO for requesting a conjunction between nodes of branched paths- It is to be understood that the above description is illus^¬ trative of the invention and is not to be construed as limit^¬ ing the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the ap^¬ pended claims.

Claims

CLAIMS :

1. A method for providing resources from a physical network, provided by at least one physical network provider, to a vir- tual network provider, the virtual network provider assembling these resources to compose at least one virtual network for providing telecommunication services, the method comprising the steps of:

a) identifying a need for certain resources at the virtual network provider;

b) requesting resources matching the identified need from the at least one physical network provider;

c) conducting virtualization for creating the virtual network by :

cl) identifying and selecting by the at least one physical network provider resources in the physical network based on the requested resources;

c2) isolating the selected resources from other resources of the physical network and reserving them for exclusive use in the virtual network; and

c3) attaching unique identification, address and access information to the isolated and reserved resources in order to enable exclusive accessibility in the virtual network;

d) reporting, from the physical network provider to the vir- tual network provider, a result of the virtualization with information concerning identification, addressability and accessibility of the selected resources; and

e) handing over control, from the physical network provider to the virtual network provider, of the resources reserved for exclusive use in the virtual network.

2. The method of claim 1, wherein the need for certain resources is identified based on a given traffic demand created by users and/or a request from a customer and/or a request from a virtual network operator, regarding a modification of an existing virtual network or a creation of a new virtual network .

3. The method of claim 1 or 2, further comprising the step of advertising from the at least one physical network provider to the virtual network provider capabilities and capacities regarding technological attributes of the physical network.

4. The method of any one of claims 1 to 3, wherein the virtu- alization further comprises the steps of:

computing a network structure out of the selected re^¬ sources, including paths between nodes;

determining whether a signaling to a starting node of the paths is routed via other nodes being not part of the se- lected resources,

if the determination is positive, including in the signaling an indication for informing the other nodes that they are not part of the selected resources.

5. The method of claim 4, wherein the virtualization further comprises the steps of:

determining whether to allow a conjunction between nodes on branched network paths,

if the determination is positive, including in the sig- naling an information element indicating the nodes between which the conjunction is to be established.

6. The method of claim 5, wherein the information concerning identification, addressability and accessibility of the se- lected resources comprises information on allowed conjunc^¬ tions between the nodes.

7. The method of any one of claims 1 to 6, wherein the se^¬ lected resources comprise at least one of the following group or groups:

- network nodes or parts of them, - control entities including computing devices, or parts of them including shares of memory, processing capacity, execution times,

- ports,

- links,

- transmission capacities, and

- paths comprising partial paths and/or end-to-end paths.

8. The method of any one of claims 1 to 7, wherein a node comprises a role or function of at least one of the following group or groups :

- an access node,

- point of presence,

- transit node, and

- traffic and/or signaling gateway.

9. The method of any one of claims 1 to 7, wherein the physi^¬ cal network comprises or consists of equipment located at customer premises.

10. The method of any one of claims 1 to 9, wherein ports, links, transmission capacities and paths are implemented on and using physical entities of any type of transmission tech^¬ nologies comprising at least one of the following group or groups:

- analog or digital,

- electrical or optical, and

- using wires, fibers or radio transmission.

11. The method of any one of the preceding claims, wherein upon identifying of no further need for certain resources, the virtual network provider returns control of these re^¬ sources to the physical network provider, that provided these resources .

12. A control unit equipped with processing resources, memory resources and interfaces, the control unit comprising means to

a) identify a need for certain resources at a virtual network provider,

b) request resources matching the identified need from at least one physical network provider,

c) receive information concerning identification, addressability and accessibility of resources selected by the at least one physical network provider based on the requested resources, and

d) take over control of and control the resources selected by the at least one physical network provider.

13. A control unit equipped with processing resources, memory resources and interfaces, the control unit comprising means to

a) receive a request for resources from a virtual network provider ;

b) conducting virtualization for creating a virtual network at a physical network provider by:

bl) identifying and selecting resources in a physical network based on the requested resources;

b2) isolating the selected resources from other resources of the physical network and reserving them for exclusive use in the virtual network; and

b3) attaching unique identification, address and access information to the isolated and reserved resources in order to enable exclusive accessibility in the virtual network;

c) reporting, from the physical network provider to the virtual network provider, a result of the virtualization with information concerning identification, addressability and accessibility of the selected resources; and

d) handing over control, from the physical network provider to the virtual network provider, of the resources reserved for exclusive use in the virtual network.

14. The control unit of claim 12 or 13, implemented with dis^¬ tributed computing devices.

15. A computer program product including a program for a processing device, comprising software code portions for per^¬ forming the steps of any one of claims 1 to 11 when the pro^¬ gram is run on the processing device.