Description

METHOD, DEVICE AND SYSTEM FOR CONVEYING

INFORMATION IN A NETWORK The invention relates to a method and to a device for convey ^¬ ing information in a network. Also, a communication system comprising at least one such device is suggested.

Telecommunication networks are constructed in a multi-layer fashion. Network devices rely on the functionality of lower layer devices and provide additional features to upper layer devices. Higher layer devices therefore have none or only an abstract view on the realization of a lower layer's functio ^¬ nality (see ISO/OSI model) .

When an efficient transport of data is required, however, a more detailed knowledge of lower layer characteristics, rea ^¬ lizations or possibilities would be beneficial to reduce transport costs or to increase a quality of service (QoS) supplied on end-to-end paths.

IP routers, for example, are only aware of the (layer-3) net ^¬ work they participate in. Hence, such an IP router is aware of the layer-3 topology, costs and characteristics of

existing IP links and nodes, but lacks knowledge about possi ^¬ bilities that lower (service) layers could provide on their respective layer (e.g., providing an additional link or addi ^¬ tional bandwidth for the layer-3 by connecting two routers with layer-2 technologies) .

A similar problem becomes apparent when connecting administratively separated domains to provide an end-to-end path across such domains. Limited knowledge is available along such an end-to-end connection regarding, e.g., characte- ristics of intermediate networks or domains. However, additi ^¬ onal information about an actual implementation, characteristics and possibilities of other (intermediate) domains would drastically reduce end-to-end transmission costs and improve an end-to-end QoS (e.g., by using inter-domain paths with short delay or reduced peering costs) .

It may theoretically be possible to provide all information to other layers and/or to other domains. However, from a practical perspective, such approach is not feasible, in par ^¬ ticular because of the following:

(a) Technological complexity: Upper layers would require

knowledge about other (lower layer) technologies (e.g., an IP router would need to become aware of optical rout ^¬ ing constraints and algorithms) and characteristics.

(b) Scalability: An immense amount of information would have to be conveyed to the higher layers and/or other do ^¬ mains .

(c) Secrecy: Some information should not be widely distrib ^¬ uted across domains or layers in case these are operated or owned by different entities.

(d) Ownership of control: Operators may be reluctant to give access or control to devices of other layers or domains that are operated by different entities.

(e) In addition, it is a huge and complex operational task to control several layers and/or domains.

However, without the information being available at any domain or entity, the following problems emerge:

(a) Limited knowledge: An upper layer is only aware of al ^¬ ready existing paths/services that are already provided by the lower layers or domains.

(b) Additional information can only be obtained by actively initiating requests (from the higher layers to the lower layers or towards other domains) . High costs: The lower layer does not offer any possibil ^¬ ity to reduce costs; hence, the system may be stuck with high end-to-end connection costs based on the connec ^¬ tions set up on the upper layer.

Low QoS: Without the possibility of lower layer enhance ^¬ ment, the end-to-end QoS cannot be improved from the up ^¬ per layer for a chosen multi-layer path.

Enhancement processes are slow and require intricate re ^¬ quest/response mechanisms towards lower layers.

Overall, this results in sub-optimal dimensioning, routing and traffic-engineering at high costs and low or unpredictable QoS of end-to-end connections.

Hence, with regard to the multi-layer scenario, currently, a client (upper) layer does not have detailed information about a server (lower) layer. The client layer operates only on a virtual network topology, which is constructed from the links advertised by the server layer. However, without more detai ^¬ led information about the server layer, no optimized multi ^¬ layer paths can be computed by the client layer, wherein such optimized multi-layer path might use fewer resources compared to the non-optimized single layer path.

With regard to the multi-domain scenario, currently, a single domain does not have the required information to compute an optimized path across multiple domains. A single domain mere ^¬ ly has reachability information, i.e. it knows via which next hop a target domain can be reached. However, without more de ^¬ tailed information about the other domains, no optimized mul ^¬ ti-domain path can be computed.

Multi-layer cooperation architectures are subject to IETF discussions using the approach of a Path Computation Elements (PCE) according to http : //en . wikipedia . org/wiki/Path_computation_element , http://www.rfc-editor.org/rfc/rfc4655.txt or http://www.rfc- editor .org/rfc/rfc5623.txt. The Path Computation Element (PCE) is defined by the Internet Engineering Task Force (IETF) in RFC 4655 as "an entity (component, application, or network node) that is capable of com ^¬ puting a network path or route based on a network graph and applying computational constraints". Thus, a PCE is an entity capable of computing complex paths for a single or a set of services. The PCE might be a network node, network management station, or dedicated computational platform which is aware of the network resources and has the ability to consider mul ^¬ tiple constraints for sophisticated path computation. PCE ap- plications include computing Label Switched Paths for MPLS and GMPLS Traffic Engineering.

The PCE has information about its own layer or domain and se- veral PCEs may collaborate to compute an end-to-end path. For multiple PCE inter-layer path computation, different approa- ches exist:

Flat request/response :

A (first) PCE calculates and/or (re-) optimizes a path by combining information about already existing (own) topology (nodes and links) and network extensions (addi ^¬ tional links) . With regard to the network extensions, specific requests are sent to lower-layer PCEs in order to determine whether such a (not yet existing) link could be established. The lower-layer PCEs can further process this request and send it to other PCEs. After a short delay, the first PCE will be notified about the possibility to extend or realize the link requested. Disadvantageously, such mechanism does not scale well in larger or (highly) meshed environments. Also, such re ^¬ quest/response polling mechanism may lead to a signifi ^¬ cant delay required for path computation purposes. (b) Hierarchical Abstraction:

In this scenario, PCEs are arranged in a hierarchical fashion. If inter-domain routes are to be calculated, a domain PCE can request an inter-domain route from an inter-domain PCE . This inter-domain PCE is aware of the domains and their internal bypass route characteristics and can calculate the domain chain towards a remote des ^¬ tination without having to know the exact details of each domain. The inter-domain PCE responds to the domain PCE with the inter-domain chain information and the chain characteristics.

(c) Virtual Links:

Another variant is to use information about already es ^¬ tablished paths as well as additional virtual (not yet existing) links. These virtual links are provided by virtual network topology managers (VNTM) of other layers or domains. The VNTM is defined as a functional element that manages and controls the virtual network topology. PCE and VNTMs are distinct functional elements that may or may not be co-located. The concept of the virtual network topology (VNT) , which is developed for multi ^¬ layer path computation, is similar to the hierarchical abstraction used for inter-domain path computation purposes.

It is noted that the VNTM entity is introduced for the PCE concept according to RFC 5623 and manages already established lower layer paths and therefore links in the higher layer. It can be triggered by the PCE to setup lower layer paths.

It is an unsolved issue as how to advertise virtual not yet established TE links, i.e. links between instances of a hig ^¬ her layer (also referred to as links on such higher layer that are based on a path of a lower layer) , on such higher layers . The problem to be solved is to overcome these disadvantages stated above and in particular to suggest an approach that allows for an efficient advertising of virtual not yet established TE links on an upper layer.

This problem is solved according to the features of the inde ^¬ pendent claims. Further embodiments result from the depending claims . In order to overcome this problem, a method is provided for conveying information in a network

- wherein a first instance of the network determines a path information within a sphere of the first instance ;

- wherein the path information is conveyed to a second instance of the network.

Advantageously, the sphere of the first instance can be used by said first instance to determine said path information, e.g., determine at least one path across the network or a portion thereof. Such path information is conveyed to the se ^¬ cond instance, which has no insight into the sphere of the first instance. It is noted that the first instance can be a topology adver ^¬ tiser, in particular a virtual topology advertiser (VTA) as will be described later.

It is noted that several topology advisers of first instances can be supplied within the sphere of the first instance, the ^¬ reby increasing an availability of the overall service supplied by these topology advisers.

The path information may comprise a link or several links, in particular virtual not yet established links that are adver ^¬ tised or transmitted to the second instance. It is also noted that the second instance may be deployed within a second sphere, wherein the first sphere and the se ^¬ cond sphere are separated from one another. Furthermore, it is noted that the concept of the virtual to ^¬ pology is independent from the PCE concept. As soon as paths are established in the lower layer, the higher layer may be ^¬ come ("see") aware of them automatically. Hence, the virtual topology may comprise paths of the lower layer, which are al ^¬ ready established.

It is yet another remark that the first instance can be a physical infrastructure provider and the second instance can be a virtual network provider. Hence, the concept introduced herein could be applied to virtual networks accordingly. Such virtual network may comprise

- a physical infrastructure provider (PIP) , which owns, operates and/or administers the physical resource;

- a virtual network provider (VNP) , which acquires re- sources from at least one PIP thereby obtaining a virtual network;

- a virtual network operator (VNO) , which requests a virtual network from the VNP and operates and con ^¬ trols the virtual network;

- a customer ("end-user") and/or an application service provider, which requests and/or offers services that are supplied by the virtual network.

Hence, the virtual network can be regarded as a multi-layer network, wherein each instance PIP, VNP, VNO is perceived as a single layer. Paths across such virtual network are to be determined and/or signaled. The higher layers, e.g. VNP, need to be informed about potential paths provided by the PIP, which can be achieved according to the solution provided her- ein.

In an embodiment, said sphere of the first instance is a lay ^¬ er of a multi-layer network. In another embodiment, the second instance is part of a dif ^¬ ferent sphere or another layer of the multi-layer network, in particular an upper layer.

The first instance and the second instance may thus be asso ^¬ ciated with different layers of a multi-layer model (e.g., according to ISO/OSI model) . The first instance provides path information to this upper layer second instance that could be used for determining or calculating an optimized path

The approach suggested in particular introduces a virtual to ^¬ pology advertiser (VTA) as well as an interface between the VTA and the upper layer (also referred to as higher layer) . Hence, the virtual network topology (VNT) comprising virtual TE links that can be determined (calculated) by a lower layer and conveyed to the higher layer. Properties of these VNT may comprise, e.g.: costs, shared risk link group (SRLG) informa ^¬ tion, QoS properties and availability information for each link.

In a further embodiment, said sphere of the first instance is a domain of a multi-domain network. In a next embodiment, the second instance is part of a diffe ^¬ rent sphere or another domain of the multi-domain network.

Hence, the first and the second instance are part of diffe ^¬ rent domains of a multi-domain network.

It is noted that the approach suggested herein can combine a multi-domain and a multi-layer approach.

It is also an embodiment that the second instance determines an optimized path across the network utilizing said path information . Hence, the path information gathered within the sphere of the first instance can be used to determine an optimized path, in particular an end-to-end path, on an upper layer or at a domain beyond said sphere of the first instance.

The path computation provided within the sphere of the first instance is an encapsulated and/or transparent service provi ^¬ ded to the second instance.

Pursuant to another embodiment, the path information compri ses at least one link and/or at least one virtual link.

The link may be a traffic engineering (TE) link that could be used by the upper layer for optimized path determination purposes. The virtual link is a link for which no resources are allocated .

It is further noted that the TE link referred to herein re ^¬ fers any virtual (established) link to a link between instan- ces of a higher layer, wherein each such TE link may actually be based on at least one path via at least one lower layer.

According to an embodiment, the path information is sent from the first instance to the second instance with or without a previous request from the second instance.

Hence, said path information may be actively pushed from the first instance to the second instance or it may be polled by the second instance.

It is noted that incremental updates can be used instead of conveying the full path information.

The first instance and the second instance may in particular support an extended OSPF protocol, which provides services of an incremental update and/or a recovery mode. According to another embodiment, the path information is processed within the sphere of the first instance and this pro ^¬ cessed path information is conveyed to the second instance of the network.

Such processing may comprise a filter or selection mechanism applied within the sphere of the first instance, e.g., by the first instance or by a filter or processing unit deployed within this sphere.

Such processing allows filtering the path information to be provided to the second instance pursuant to predefined constraints .

In yet another embodiment, the path information is determined based on at least one of the following criteria:

- a policy, in particular provided by a policy server within the sphere of the first instance;

- a service level agreement;

- a cost information;

- a topology information, in particular provided by a topology information database within the sphere of the first instance;

- a traffic-engineering information, in particular provided by a traffic-engineering database within the sphere of the first instance;

- quality of service information;

- availability information;

- service type information.

The path information may in particular be selected, processed or filtered according to at least one of these criteria.

According to a next embodiment, the first instance determines optimized paths per customer in particular considering service level agreements, policies and costs for each customer. Pursuant to yet an embodiment, the first instance determines optimized paths based on at least one of the following crite ^¬ ria :

- resources required for a path;

- a latency;

- a jitter;

- a number of hops;

- a length of the whole path. These criteria (or a portion thereof) can be minimized and therefore be used as a metric for an optimal path. The actual metric selected may depend on a service requested. Hence, for the same source-destination pair of a path, different links can be computed by the topology adviser and conveyed to the second instance.

According to another embodiment, the first instance utilizes or comprises a PCE functionality. The PCE functionality may be used for determining path infor ^¬ mation within the sphere of the first instance and the topo ^¬ logy adviser computes paths within the sphere of the first instance that are destined for the second instance (e.g., up ^¬ per layer) .

According to a further embodiment, the path information conveyed to the second instance comprises at least an identifi ^¬ cation associated with a link. In particular, this identification can be used to address a link or a portion of the path information. Hence, if a link or path should be established, the path computation for this link does not have to be repeated, but can be addressed by said identification.

The problem stated above is also solved by a network element for conveying information, comprising or being associated with a processing unit that is arranged to execute the steps of the method as described herein.

The problem stated above is further solved by a network ele- ment comprising a first instance that is arranged

- for determining a path information within a sphere of the first instance;

- for conveying the path information to a second instance of the network.

The first instance may comprise or be associated with a pro ^¬ cessing unit. It is noted that the steps of the method stated herein may be executable on this processing unit as well. It is further noted that said processing unit can comprise at least one, in particular several means that are arranged to execute the steps of the method described herein. The means may be logically or physically separated; in particular seve ^¬ ral logically separate means could be combined in at least one physical unit.

Said processing unit may comprise at least one of the follo ^¬ wing: a processor, a microcontroller, a hard-wired circuit, an ASIC, an FPGA, a logic device.

According to an embodiment, said sphere of the first instance is a domain of a multi-domain network and/or a layer of a multi-layer network. As indicated, the second instance is associated with a sphere that is different from the sphere of the first instance.

Pursuant to a further embodiment,

- the network element comprises at least one of the

following: a policy server, a service level agreement database, a cost database, a topology database, a traffic engineering database, - wherein the first instance is arranged to determine the path information based on information provided by at least one of the policy server, the service level agreement database, the cost database, the topology database or the traffic engineering database.

According to another embodiment, the network element comprises a PCE functionality that is accessible to the first in ^¬ stance .

This PCE functionality may be based on a standardized PCE functionality and it may be implemented as a separate entity or combined with the first instance.

According to another embodiment, the network element comprises a filter that filters the path information before it is conveyed to the second instance.

Furthermore, the problem stated above is solved by a communi ^¬ cation system comprising at least one device as described herein .

Embodiments of the invention are shown and illustrated in the following figures:

Fig.l shows an OSPF packet header with an LSA header and an extension;

Fig.2 shows a block diagram visualizing a virtual topology advertiser concept;

Fig.3 shows a block diagram based on Fig.2 with a single lower layer being connected to two higher layer customers ;

Fig.4 shows the opposite case of Fig.3 and is also based on

Fig.2 with a single higher layer being connected to two lower layers; Fig.5 shows a schematic illustration to visualize the proc ^¬ ess of calculating and setting up a path in a multilayer network;

Fig.6A shows a schematic diagram visualizing an advertisement or transfer of path information in a multi-layer scenario ; Fig.6B shows a schematic diagram visualizing an advertise ^¬ ment or transfer of path information in a multi- domain scenario.

In multi-layer networks, a lower layer may advertise TE links to an upper (or higher) layer. These TE links form a virtual network topology (VNT) of the higher layer. Such TE links can be realized by setting up label switched paths (LSPs) in the lower layer. Depending on resource usage strategies and other TE-related considerations, it might not be feasible to in- stantiate the full set of lower layer LSPs that constitute the VNT, since this would reserve an amount of bandwidth that may be required otherwise. However, these LSPs could be ad ^¬ vertised to the higher layer without actually allocating re ^¬ sources. In this case, the TE links advertised can be regar- ded as "virtual" TE links that are not yet established, since they represent lower layer LSPs that have not yet been established, i.e. they are "planned" and insofar not yet existing (virtual) . For (optimized) path computation purposes, a path computation entity may have to consider different layers, which may be difficult or impossible due to (operator) policies, manage ^¬ ment and other reasons that stipulate a strict separation of the layers. Hence, an upper layer has no insight into its lo- wer layer; therefore, the upper layer path computation entity has no knowledge of the lower layer. However, in order to conduct an efficient path computation, the upper layer path computation entity requires information about the lower lay- er, i.e. it preferably requires knowing about (all) possible lower layer paths, which result in TE links in the VNT, including their corresponding properties. Such properties comprise cost values, SRG information, free resources on a link and other QoS parameters.

The path computation entity is also referred to as "path cal ^¬ culator" and it may comprise or be based on a PCE functiona ^¬ lity.

The path calculator of a higher layer obtains the information required, e.g., regarding (all) possible lower layer paths, by using the virtual TE links. It is noted that these TE links may not be established (yet) and insofar no resources are allocated in the lower layer for such TE links.

Fig.2 shows a block diagram visualizing a virtual topology advertiser concept comprising in particular the following < tities of an upper (higher) layer 211 and of a lower layer 212 :

Lower Policy Server 201:

The Lower Policy Server 201 stores operator policies of a lower layer network. These policies may affect a vir ^¬ tual topology advertiser (VTA) 202, i.e. they define, which paths the VTA 202 computes. Also, this Lower Pol ^¬ icy Server 201 is connected to a filter 203, i.e. the Lower Policy Server 201 defines which of the computed paths should be actually advertised to the higher layer

Filter 203:

The filter 203 is a lower layer filter. It provides a filter function and selects the paths that are to be an nounced to a specific customer. The filter 203 can be configured for each customer and/or topology and/or TE- database. The filter 203 may consider restrictions de ^¬ fined by the Lower Policy Server 201 and the SLA and cost database 204. A path determined by the VTA 202 is input to the filter 203, which takes into account poli ^¬ cies as well as SLAs and outputs the result to a higher layer filter 205.

Service Level Agreement (SLA) and cost database 204: This database 204 stores SLAs and costs for each cos- turner. This information may be considered by the VTA 202 as well as by the (lower layer) filter 203.

Lower Path Calculator 206:

The Lower Path Calculator 206 is also referred to as (lower) traffic engineering engine. It may be based on or comprise a PCE and it computes paths that have been requested by the lower layer. The computation is based on the information stored in a lower topology and TE- database 207.

It is noted that the PCE may also comprise a database (also referred to as traffic engineering database (TED) ) and the actual path computation engine. The TED can be used both for the VTA 202 and for the PCE 206.

The PCE may compute only the paths that are requested by the lower layer. Hence, these path computation results of the PCE do not have to be transmitted to any higher layer nor to the VTA 202. An interface (not shown) between the PCE and the network and/or the management sys ^¬ tem can be provided, and such entities (or network nodes, or the management system) may request path compu ^¬ tations from the PCE.

Lower Topology and TE-database 207:

This database 207 stores a topology, free resources and physical characteristics and/or QoS parameters of the lower layer.

Higher Policy Server 208: The Higher Policy Server 208 stores policies of the op ^¬ erator of the higher layer network. It configures the filter 205, i.e. the Higher Policy Server 208 defines which of the received paths should be forwarded to a higher topology and TE-database 209.

(g) Higher Topology and TE-database 209:

This database 209 stores a virtual topology, free re ^¬ sources, costs and other QoS parameters of the higher layer.

(h) Filter 205:

The higher layer filter 205 filters the paths that should be forwarded to the higher topology and TE- database 209. The filter 205 considers the policies of the higher layer.

(i) Higher Path Calculator 210:

The Higher Path Calculator 210 is also referred to as (higher) traffic engineering engine. It may be based on or comprise a PCE (functionality) and it computes paths that have been requested for the higher layer. The com ^¬ putation is based on the information stored in the data ^¬ base 209. Hence, the Higher Path Calculator 210 computes paths in the VNT of the higher layer.

(j) VTA 202:

The VTA 202 calculates (all) possible routes and/or paths in the lower layer taking into account the poli- cies provided by the Lower Policy Server 201 and cus ^¬ tomer-specific requirements and costs provided by the database 204. The path computation is conducted based on the Lower Topology and TE-database 207. All calculated paths are sent to the filters 203, 205. The VTA 202 com- putes optimized (or optimal) paths per customer taking into account the costs for each customer. It is noted that the Higher Path Calculator 210 and/or the Lower Path Calculator 206 may comprise a (standardized) PCE, which is an entity being capable of computing a path using, e.g., a standardized interface via a PCEP (PCE Protocol) . On request, the PCE may compute the cheapest path with regard to the resources used.

It is further noted that the VTA 202 considers SLAs and costs provided by the database 204. For example, a higher layer operator may have an SLA including a price agreement with a lower layer operator; hence, the VTA 202 computes the chea ^¬ pest paths considering this price agreement for the higher layer for a particular customer. It may also be the case that the lower layer has multiple higher layer customers; depen- dent on the SLA and price negotiated for each customer, the VTA 202 may compute different paths for the same source and destination .

Hence, the VTA 202 computes paths within the lower layer for the higher layer and the PCE computes paths for the lower layer only.

As an option, the VTA 202 and the lower PCE may be combined into a single entity.

The VTA 202 may compute for all possible source and destina ^¬ tion pairs the cheapest paths and send those paths to the filter 203. The filter 203 uses information provided by the Lower Policy Server 201 as well as the SLA and cost database 204 to check if all computed paths should be conveyed to the higher layer or any of the paths determined violates a policy or an SLA. The filter 203 does not forward paths, i.e. the virtual TE links, which are not conform to the policy and SLA. Such separate filtering can be useful, if the VTA 202 is not able to compute the paths and take all the required poli ^¬ cies and SLA into account in parallel. The Lower Policy Server 201 may comprise rules, which need to be taken into account by the VTA 202 and rules, which are to be enforced by the filter 203.

It is an option to combine the VTA 202 and the filter 203 in ^¬ to a single entity. In this case, such entity comprising VTA 202 and filter 203 may compute and forward (all) paths to the higher layer, which meet the requirements set forth by the Lower Policy Server 201 and the database 204.

An optimized (or optimal) path can be determined or computed based on at least one of the following criteria:

- resources required for a path;

- a latency;

- a jitter;

- a number of hops;

- a length of the whole path.

These criteria (or a portion thereof) can be minimized and therefore be used as a metric for an optimal path. The actual metric selected may depend on a service requested. Hence, for the same source-destination pair, different TE links can be computed by the VTA 202 and advertised to the upper layer via the filter 203.

The VTA 202 may consider at least one of the following pro ^¬ perties in order to compute the paths, which are advertised as virtual TE links:

Costs :

The costs can be provided via the SLA and cost database 204. This information may comprise costs for each cos- turner for each link. Based on this information, the shortest path between two nodes can be calculated.

SLAs :

This information can be provided via the SLA and cost database 204. An SLA may comprise properties like a minimum availability, a maximum number of hops, a maxi ^¬ mum bit error rate (BER) acceptable, an amount of money for violating a SLA. Using this information, additional constraints can be specified for the path computation.

QoS parameters:

QoS parameters are, e.g., the physical properties of, e.g., optical networks. This information can be used to calculate the actual BER for a TE link. The QoS parame ^¬ ters can be stored in the Lower Topology and TE-database 207, which may be configured during or before start-up either manually or it can be automatically initialized via a network management system (NMS) . The QoS parame ^¬ ters may comprise: a BER, a latency, a jitter, a band ^¬ width, an availability.

Availability :

To satisfy the availability for a whole virtual link specified in the SLAs, the VTA 202 uses availability in ^¬ formation of each individual link and each individual node. The availability can be a QoS parameter (see above) and thus be stored in and provided by the Lower Topology and TE-database 207.

Service types:

The service type, which the client (upper) layer will run on the TE links computed, may be an information to be considered by the VTA 202. Depending on the type of service, different QoS requirements and hence, different links in the lower layer may be admissible.

The database 204 may contain SLAs for each customer. In this database 204, admissible services for one customer can be linked to the SLA. The VTA 202 can thus compute for each service type the optimal path, i.e. the service is mapped to QoS parameters required and the VTA 202 computes the optimal path considering the QoS require ^¬ ments. In such scenario, a maximum or minimum value for a QoS parameter can be defined or the QoS parameter can be minimized or maximized.

The service type may comprise real-time services, nearly real-time services or non real-time services. Based on these service types, the boundaries for the QoS parame ^¬ ters like delay and/or jitter can be set.

(6) Policies:

Policies can be defined by the operator and the VTA 202 may consider such policies when determining the paths.

The policies may comprise restrictions, e.g., which path and/or link should be (not) considered and/or (not) ad ^¬ vertised . For example, a policy may be required that a computed and an ^¬ nounced path must not traverse a node, which has a load hig ^¬ her than 80%. In this case, the VTA 202 computes the paths as usual and they will be conveyed to the higher layer as desc ^¬ ribed. As soon as a node's load exceeds 80%, this node will be masked (not used) during path computation in the VTA 202.

According to a further example, an operator may decide that only a few links should be advertised to the upper layer (for example, only transit links should be directly announced to the higher layer) . So he specifies that TE links should be advertised only between the cities Munich, Bremen, Frankfurt and Berlin. This policy is considered by the VTA 202, i.e. the VTA 202 computes paths between these cities. The advertisement of the virtual TE links can include an identification (ID) of this link. This ID can be linked inside the VTA 202 to the actual computed path. Hence, if a virtual TE link should be established, the path computation for this link does not have to be repeated, but can be loaded from the VTA 202, which has already computed this path.

The actual advertisement of the virtual TE links to the hig ^¬ her layer can be either done by polling, i.e. the higher lay- er actively requests the virtual TE links from the lower lay ^¬ er and only after such a request the paths are sent to the higher layer. Alternatively, the virtual TE links are pushed to the higher layer, i.e. the VTA 202 sends the virtual TE links to the higher layer. In both cases incremental updates can be utilized.

For this advertisement, i.e. between the two filters 203, 205, extensions to the OSPF protocol (RFC 2328) can be used. Such an extended interface may support incremental updates and/or a recovery mode, i.e. that all virtual TE links are sent to the higher layer.

Hence, new OSPF messages can be used for exchanging the vir- tual TE links between the lower and higher layer filters 203, 205. In this regard, the filters 203, 205 may each be modi ^¬ fied to comprise a (modified) OSPF functionality. The VTA 202 computes the paths, the filter 202 checks the policies and SLAs provided by the Lower Policy Server 201 and the database 204 and forwards the TE links to the higher layer, i.e. to the filter 205. This forwarding is done by transforming a link out of the path, and announcing this link to the higher layer filter 205 using a Link State Advertisement (LSA) mes ^¬ sage as shown in Fig.l.

The LSA message shown in Fig.l comprises an OSPF packet hea ^¬ der 102 (see RFC 2328, A.3.1), an LSA header 103 (see

RFC 2328, A.4.1) and an extension 101. The "LS type" within the LSA header 103 may be set to "6" in ^¬ dicating a virtual TE link in a higher layer.

The extension 101 will be described in more detail hereinaf ^¬ ter :

- A destination address specifies an IP address of a destination of this LSA advertisement. This could be the filter 205 of the higher layer. - A source address specifies an IP address of the source of this LSA advertisement, which could be the VTA 202.

- Flags:

- A U-Flag indicates whether or not the following information is an update of the virtual TE link.

- An R-Flag indicates whether or not the following TE link should be removed.

- A V-Flag indicates whether or not a virtual TE link is specified.

- A "source node in higher layer" specifies an IP ad ^¬ dress of a source node in the higher layer from which the virtual TE link starts.

- A "target node in higher layer" specifies an IP ad- dress of a target node in the higher layer at which the virtual TE link ends.

- A "link ID of virtual TE link" specifies (as an inte ^¬ ger) an ID of the virtual TE link if a path key mechanism is used. If this mechanism is not used, this value is set to 0.

- A "duration of validity" specifies (as an integer in seconds) how long this TE link is valid.

- Link ID, Link Data, Type, #TOS, and metric are used as specified in RFC 2328.

- After these data further information like costs, QoS parameter, availability and technology realization can be specified as "Optional TLVs".

It is possible that multiple VTAs are deployed inside one layer or one network. Hence, a VTA redundancy is provided, in particular increasing the availability of the service

supplied by the VTAs.

When the path key mechanism is used, the VTA stores path IDs for the virtual TE links and a virtual TE link can be addres sed via such path ID. Hence, with regard to the multi-layer scenario, the approach suggested herein provides all required information to a client layer, such that it can compute optimal paths traver ^¬ sing both the client and the server layers. The information revealed to the client (upper) layer, however, does not have to include topology details of the server layer, which are sometimes required (by the operators) to remain hidden.

With regard to the multi-domain scenario, the approach sug- gested provides all required information to different do ^¬ mains, such that optimal paths traversing multiple domains can be computed. The information revealed by the (other) do ^¬ mains, however, may not include topology details of other do ^¬ mains, which are sometimes required (by the operators) to re- main hidden.

Hence, the concept suggested allows

- advertising possible and/or required TE links to

higher layer and/or other domains, such that optimal paths can be computed by such higher layer;

- taking into account policies and/or requirements of the lower layer and/or own domain and/or higher layer and/or other domain (s);

- determining paths depending on customer requirements.

The higher layer can compute the paths based on its virtual topology. The virtual topology is based on the advertised links from the lower layer. Hence, it is a significant advan ^¬ tage that the higher layer does not have to communicate with the lower layer during the path computation process.

Fig.3 shows a block diagram based on Fig.2 with a single lo ^¬ wer layer 301 being connected to two higher layer customers 302 and 303. References already introduced with regard to Fig.2 refer to the same components. Instead of the filter 203 shown in Fig.2, Fig.3 comprises two filters 304, 305, wherein the filter 304 is associated with the customer 302 and the filter 305 is associated with the customer 303. For example, the lower layer 301 can be a layer-1 advertising some links directly to a layer-3 being the customer 302 and some other links to layer-2 being the customer 303.

Fig.4 shows the opposite case of Fig.3 and is also based on Fig.2 with a single higher layer 403 being connected to two lower layers 401 and 402. References already introduced with regard to Fig.2 refer to the same components.

For example, the higher layer 403 may be a layer-3 obtaining advertisements from a layer-2 401 as well as from a layer-1 402. As indicated, the concept of the multi-layer scenario can be accordingly applied to the multi-domain scenario. It is also noted that the multi-layer and multi-domain scenarios can be combined . Fig.2 can be applied to the multi-domain scenario as follows: The blocks of the higher layer (i.e. 205, 208, 209 and 210) are associated with a domain 2 and the blocks of the lower layer (i.e. 201, 202, 203, 204, 206, 207) are associated with a domain 1. In addition, the concept can be mirrored, i.e. further to conveying links from the domain 1 to the domain 2 (from the filter 203 to the filter 205) , links can also be advertised in the opposite direction, i.e. from the domain 2 to the domain 1. In this case, domain 2 also comprises a VTA. The TE links advertised can be either transit links or links which either start or end in domain 1, domain 2 respectively. The advertisement of links to domain 2 (or to domain 1) is conducted as described before for the multi-layer scenario. The peering agreements can be stored in the SLA and cost da ^¬ tabase 204. The amount of information that should be hidden as well as the amount of information to be shared could be indicated by or stored in the policy server 201. Based on this information, the VTA 202 may compute paths traversing its domain.

Fig.3 could be implemented comprising three different layers, i.e. the higher layer customer 302 is a CET layer-2 and the higher layer customer 303 is an MPLS layer-3. The lower layer 301 is a DWDM layer-1.

For this example, the SLA and cost database 204 and the poli- cy servers 201, 208 are configured manually. The Higher Topo ^¬ logy and TE-database 209 is initialized via an NMS, which transfers topology information and other relevant data like latency, jitter, etc. for each link to this database 209. Currently used resources of the network can be updated by listening to the IS-IS or OSPF-TE message exchange that oc ^¬ curs on the control plane (assuming that a GMPLS control pla ^¬ ne is running for the DWDM layer) . According to this example, four nodes A, B, C and D are spe ^¬ cified in the policy server 201 for which paths are to be calculated for layer-3. Furthermore, nodes B, C, E, F, G are specified for which paths should be calculated for layer-2. To determine the paths for layer-3, the VTA 202 queries the Lower Policy Server 201 and the SLA and cost database 204. Based on the input provided by the Lower Policy Server 201, the VTA 202 determines paths for the start and end node A-B, A-C, A-D, B-C, B-D and C-D. At one step of the path computa- tion, the VTA 202 considers also the input from the database 204, i.e. the VTA 202 calculates the cheapest paths for lay ^¬ er-3. Furthermore, the VTA 202 considers the SLAs (provided by said database 204), i.e. for each possible service it com ^¬ putes a path for each source and target node.

In a similar manner, the VTA 202 computes the paths for layer-2. This could be achieved re-using the results from the layer-3 path calculation already conducted, i.e., the paths for the source-destination pair B-C, if the database 204 cor ^¬ responds to both layers.

As described also above with regard to Fig.2, the paths are determined by the VTA 202 considering input from the Lower Policy Server 201, the SLA and cost database 204 and the Lo ^¬ wer Topology and TE-database 207. The result of the VTA com ^¬ putation may reveal multiple paths for each source- destination pair specified in the policy server, each one op- timized with regard to a specified service class for each layer and/or customer as defined in the SLAs .

For calculating a path, a shortest path algorithm (Dijkstra), a modified Dijkstra algorithm, heuristics or integer linear programming (ILP) can be used.

The VTA may thus consider constraints that are in particular dependent on SLAs. Such constraints may require considering only links with a BER amounting to less than a predefined va- lue or links with an availability that is higher than a pre ^¬ defined value. Constraints may also be derived from service types (e.g., real time service or the like) .

The paths computed by the VTA are forwarded to the filters and the filters determine which paths are to be forwarded. In the example described with regard to Fig.3, the filter 305 is passed only by paths comprising the nodes A, B, C and D.

Furthermore, the filter may check if a specified availability and other required QoS parameters are met. Based on the paths forwarded to the upper layer, TE links are determined.

The filter itself has two tasks: First, the filter derives virtual TE links from the paths and forwards those TE links to the higher layer. Second, the filter may check if the com- puted paths meet the requirements specified by the Lower Po ^¬ licy Server 201 and by the SLA and cost database 204. This can in particular be useful in case the VTA 202, e.g., due to performance reasons, cannot consider all constraints relevant for a path. As indicated, the functionalities of the filter and the VTA may be merged into a single component.

It is noted that the scenario may be applicable between lay- er-2 and layer-3 as well, i.e. layer-2 may advertise virtual TE links to layer-3.

As indicated in Fig.4, the approach presented herein can be used to support several operators at (e.g., different) lower layers. Each operator has the components described in detail with regard to Fig.2 above, i.e. the VTA 202, the filter 203, the Lower Policy Server 203, the Lower Topology and TE- database 207 and the Lower Path Calculator 206. The paths are conveyed via the filter 203 to the upper layer filter 205, which receives the paths from both lower layers (i.e. opera ^¬ tors) 401, 402. The filter 205 conducts a policy-dependent filtering and stores the links of both operators 401, 402 in the Higher Topology and TE-database 209. This concept allows calculating optimized paths using TE links of both operators 401 and 402.

Fig.5 shows a schematic illustration to visualize the process of calculating and setting up a path in a multi-layer network .

In this example, the VTA concept is realized together with the PCE approach. As a preliminary step, the virtual TE links have been calculated by the VTA and advertised to the higher layer (not shown in Fig.5) .

Fig.5 shows a two-layer network comprising nodes A, B, C, D of a higher layer and nodes Nl to N10 of a lower layer. The node A is connected to the node Nl, the node B is connected to the node N5, the node C is connected to the node N6 and the node D is connected to the node N10.

In an exemplary implementation, the node A and the node Nl, the node B and the node N5, the node C and the node N6, the node D and the node N10 are deployed within the same physical entity, respectively.

The nodes of the higher layer that are connected to nodes of the lower layer are aware of their interconnection to this lower layer. Also, on the higher layer, the following links already exist (these links can be logical or physical links) : A-B, B-C, C-D. On the lower layer, the links shown in Fig.5 exist: N1-N2, N2-N4, N4-N6, N2-N3, N3-N5, N5-N6, N6-N7, N7- N8, N8-N9, N9-N10.

A communication between nodes of different layers can be achieved via the advertised virtual TE links (as described herein, see block 501, wherein said block 501 comprises the structure depicted in Fig.2) and via a control plane, e.g. via the nodes A-Nl, B-N5, C-N6, D-N10.

Hereinafter, the steps shown in Fig.5 are described:

The node A wants to set up a path from the node A to the node D. In order to compute the path, the node A

launches a request to the PCE of the Higher Path Calcu ^¬ lator 210 (indicated by block 501) to provide a corre ^¬ sponding path (step 511) . This PCE computes an optimal path using the information of the Higher Topology and TE-database 209, which includes virtual TE links of the lower layer. These virtual TE links have already been conveyed to the higher layer as described herein.

The path determined by the PCE of the Higher Path Calcu ^¬ lator 210 is sent back to the node A including a virtual TE link between the node A and the node C (step 512) . The response of this PCE includes an additional path key for the virtual TE link between the nodes A and C. Based on this information, a normal signaling process for the control plane may be initiated using the path key con ^¬ cept (see also RFC 5520) . The node A recognizes that the first link is merely a virtual TE link, since no direct link goes from the node A to the node C. Therefore, the node A sends the path key to the lower layer node Nl with a request to estab ^¬ lish a path between the node A and the node C (step 513) . Such forwarding and triggering of a path or LSP can be done either via a control plane message, e.g. RSVP-TE, or via a universal network interface (UNI) . (4) The node Nl asks the VTA 202 (indicated by block 501) for the corresponding path associated with the path key provided, i.e. the node Nl sends the path key to the VTA 202 (step 514) . (5) The VTA 202 provides the pre-computed path which matches the path key to the nodes Nl (step 515) .

(6) The node Nl signals the provided path to be established in the lower layer (step 516) .

(7) The path established on the lower layer is automatically advertised as a new TE link to the higher layer (step 517), e.g., via an OSPF LSA (broadcast). (8) As soon as the new TE link (which is a logical TE link that has already been established) is advertised to the higher layer, the node A continues the signaling process to establish the path between the node A, the node C and the node D (step 518) and to obtain a confirmation that this path is established (step 519) . Hence, the complete path from the node A to the node D via the node C is set up .

The Node Nl does not need to know anything about the higher layer, except that it is connected to the higher node A. Al ^¬ so, all other lower layer nodes N2 to N10 have no information of the higher layer, except for the node to which each of them is directly connected. Accordingly, the higher layer no- des are not aware of any lower layer information or path other than the lower layer node to which the higher layer node is connected. With regard to the multi-domain scenario, the approach can be applied in a similar manner, i.e. transit paths across do ^¬ mains and paths starting and ending in a domain 1 are advertised to other domains. The domain 1 receives the correspon ^¬ ding information from other domains. This information can be utilized to determine an optimized path across several do ^¬ mains. Information can be hidden by using the path key mechanism.

Fig.6A shows a schematic diagram visualizing an advertisement or transfer of path information 605 from a first instance 601 (in particular a VAT) of a sphere 602 to a second instance 603 of sphere 604. The sphere 602 and the sphere 604 may be layers of a multi-layer environment. The path information 605 may comprise at least one path, at least one link, in parti- cular at least one virtual link. The path information 605 is conveyed to the second instance 603, which may poll or re ^¬ quest this path information 605 or the path information can be transmitted (pushed) to the second instance 603 by the first instance (without any previous request) .

Fig.6B shows a schematic diagram visualizing a multi-domain scenario. A path information 610 is conveyed or advertised from a first instance 606 (in particular a VAT) of a sphere 607 to a second instance 608 of sphere 609. The sphere 607 and the sphere 609 can be domains of a multi-domain environ ^¬ ment. The path information 610 may comprise at least one path, at least one link, in particular at least one virtual link. The path information 610 is conveyed to the second in ^¬ stance 608, which may poll or request this path information 610 or the path information 610 can be transmitted (pushed) to the second instance 608 by the first instance 606 (without any previous request) . Further Advantages

The concept suggested allows computing of optimized paths meeting predefined requirements or constraints (e.g., QoS) in a fast and scalable way. This computation can be done at a single layer without any detailed knowledge about how virtual TE links are realized on the lower layer. Hence, the techno ^¬ logy and complexity of the lower layer is hidden to the hig ^¬ her layer.

Advantageously, the virtual TE links are merely advertised, but do not have to be established at the moment of advertise ^¬ ment. Hence, the TE link can be advertised to several custo ^¬ mers at the same time. As soon as one customer actually uses this TE link, this information is updated in the lower layer, the path is set up, and the resource is allocated. In such case, the virtual TE link is automatically replaced by an established TE link. A request can be sent to a PCE with specified QoS require ^¬ ments. This PCE is aware of the network topology and the QoS parameters of each link and can therefore compute the optimal path taking into account these constraints. Only the VNT including the virtual TE link can be announced to the higher layer. So only a very limited amount of information has to be exchanged between the layers. This allows for a high degree of scalability. The concept using VTAs can be used in multi-vendor and multi- operator environments. Furthermore, the approach provided can be used for multi-domain path computation purposes.

Another advantage is the fact that the virtual network topo- logy including the virtual TE links can be easily advertised to the higher layer. The layers can also be operated separa ^¬ tely. Hence, the solution results in reduced operation expen ^¬ ditures (OPEX) . With this solution it is possible to advertise virtual TE links to higher layers and/or other domains. Hence, optimal multi-layer and/or multi-domain paths can be determined without any further communicating path information to the lo wer layer.

The approach is in particular useful in case a PCE is deploy ed on each layer (and/or domain) and each PCE is only aware of its own layer or domain. Existing approaches require sending a significant amount of path computation traffic from the higher layer PCE to the lower layer PCE in order to determine optimal paths. The solution presented herewith, howe ver, does not require any such additional path computation requests and thus significantly reduces the traffic load.

List of Abbreviations:

BER Bit Error Rate

CET Carrier Ethernet Transport

DWDM Dense Wavelength Division Multiplex

GMPLS Generalized MPLS

ID Identification

ILP Inductive Logic Programming

IP Internet Protocol

IS-IS Intermediate System to Intermediate System Protocol

LSA Link State Advertisement

LSP Label Switched Path

ML Multi-Layer

MPLS Multiprotocol Label Switching

NMS Network Management System

OSPF Open Shortest Path First

PCE Path Computation Element

PCEP PCE Protocol

QoS Quality of Service

RFC Request For Comments

SDH Synchronous Digital Hierarchy

SLA Service Level Agreement

SRG Shared Risk Group

SRLG Shared Risk Link Group

TE Traffic Engineering

U I Universal Network Interface

V T Virtual Network Topology

VNTM VNT Manager

VTA Virtual Topology Advertiser

VTAC Virtual Topology Advertisement Concept Reference List:

101 extension of OSPF packet header

102 OSPF packet header

103 LSA header

201 Lower Policy Server

202 VTA

203 filter

204 SLA and cost database

205 filter

206 Lower Path Calculator

207 Lower Topology and TE-database

208 Higher Policy Server

209 Higher Topology and TE-database

210 Higher Path Calculator / higher traffic engineering engine

211 upper (=higher) layer

212 lower layer

301 lower layer

302, 303 higher layer customer

304, 305 filter 401, 402 lower layer

403 higher layer

501 block (corresponds to Fig.2)

511 to 519 steps of the process shown in Fig.5

601, 606 first instance

602, 607 sphere of first instance

603, 608 second instance

604, 609 sphere of second instance

605, 610 path information