WO2017182086A1

WO2017182086A1 - Management of network resources shared by multiple customers

Info

Publication number: WO2017182086A1
Application number: PCT/EP2016/058933
Authority: WO
Inventors: Paolo Rebella; Daniele Ceccarelli; Diego Caviglia
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-04-21
Filing date: 2016-04-21
Publication date: 2017-10-26

Abstract

A multi-domain coordination node (10, 11, 12) is associated with multiple network resource domains. The multi-domain coordination node (10, 11, 12) controls network resources (31, 32, 33, 34, 25) of the multiple network resource domains by interaction with control nodes (21, 22, 23, 24, 25) of the network resource domains. For each of the network resources (31, 32, 33, 34, 35), the multi-domain coordination node obtains availability information from the control nodes (21, 22, 23, 24, 25). The availability information indicates whether the network resource (31, 32, 33, 34, 35) is available. Further, the multi-domain coordination node (10, 11, 12; 700) determines accessibility information for each of the network resources (31, 32, 33, 34, 35). The accessibility information indicates to which customer the network resource (31, 32, 33, 34, 35) is accessible. Depending on the availability information and the accessibility information, the multi-domain coordination node (10, 11, 12) controls utilization of at least one of the network resources by at least one of the customers.

Description

Management Of Network Resources Shared By Multiple Customers Technical Field

The present invention relates to methods for management of shared network infrastructure and to corresponding devices and systems. Background

In data networks, such as transport networks of a communication network, it is known to organize the network in terms of virtualized network resources, e.g., in terms of a "Software Defined Network" (SDN). For example, a hierarchy of SDN controllers may be provided to integrate different layers of the network (e.g. a packet layer and an optical layer) and multiple domains under the control of a same entity, thereby allowing efficient control of end-to-end connectivity between different network domains through various layers of the network.

For example, in IETF draft "Framework for Abstraction and Control of Transport Networks" by D. Ceccarelli and Y. Lee (March 2015), a framework termed as "Abstraction and Control of Transport Networks" (ACTN) is defined which allows for establishing a hierarchy of SDN controllers and for abstracting network infrastructure and services.

Further, it is also known that the same network infrastructure is shared by multiple customers. For example, two communication network operators may share parts of the transport network infrastructure. This sharing is typically based on a Service Level Agreement (SLA). As an illustrative example, a first communication network operator could own optical network infrastructure and use this optical network infrastructure for building a first transport network. A second communication network operator may have a SLA with the first communication network operator which allows the second communication network operator to use the optical network infrastructure owned by the first optical network infrastructure and use this shared optical network infrastructure for building a second transport network. In this example, the second communication network operator may be regarded as customers of the same network infrastructure. In other scenarios, the shared optical network infrastructure could be owned by a third party (e.g., a third operator), and both the first communication network operator and the second communication network operator could have a SLA with this third party. In some scenarios, different customers sharing the same network infrastructure could also correspond to different organizational entities of the same communication network operator, e.g., to different business departments having a certain SLA. However, neither the ACTN framework nor other frameworks for hierarchical control of multi- domain networks allow for efficiently supporting such scenarios in which the same network infrastructure is shared by different customers.

Accordingly, there is a need for techniques which allow for efficient hierarchical management of network infrastructure shared by multiple customers.

Summary

According to an embodiment of the invention, a method of managing network infrastructure shared by different customers is provided. According to the method, a multi-domain coordination node is associated with multiple network resource domains. The multi-domain coordination node controls network resources of the multiple network resource domains by interaction with control nodes of the network resource domains. For each of the network resources, the multi-domain coordination node obtains availability information from the control nodes. The availability information indicates whether the network resource is available. Further, the multi-domain coordination node determines accessibility information for each of the network resources. The accessibility information indicates to which customer the network resource is accessible. Depending on the availability information and the accessibility information, the multi-domain coordination node controls utilization of at least one of the network resources by at least one of the customers.

According to a further embodiment of the invention, a method of managing network infrastructure shared by different customers is provided. According to the method, a control node controls network resources of a domain by interaction with a multi-domain coordination node. The multi-domain coordination node is associated with multiple domains of network resources. For each of the network resources of the domain, the control node providing availability information to the multi-domain coordination node. The availability information indicates whether the network resource is available. Further, the control node provides administrative information for each of the network resources of the domain to the multi- domain coordination node. The administrative information enables distinguishing between at least two subgroups of the network resources in terms of accessibility by the customers. According to a further embodiment of the invention, a method of managing network infrastructure shared by different customers is provided. According to the method, a customer-domain node is associated with one of the different customers. The customer- domain node controls network resources by interaction with at least one multi-domain coordination node associated with multiple network resource domains. For each of the network resources, the customer-domain node obtains accessibility information from the at least one multi-domain coordination node. The accessibility information indicates to which customer the network resource is accessible. According to a further embodiment of the invention, a multi-domain coordination node is provided. The multi-domain coordination node is configured to control network resources of the multiple network resource domains by interaction with control nodes of the network resource domains. Further, the multi-domain coordination node is configured to obtain availability information for each of the network resources from the control nodes. The availability information indicates whether the network resource is available. Further, the multi- domain coordination node is configured to determine accessibility information for each of the network resources. The availability information indicates to which customer the network resource is accessible. Further, the multi-domain coordination node is configured to control, depending on the availability information and the accessibility information, utilization of at least one of the network resources by at least one of the customers.

According to a further embodiment of the invention, a control node is provided. The control node is configured to control network resources of a domain by interaction with a multi- domain coordination node associated with multiple domains of network resources. Further, the control node is configured to provide availability information for each of the network resources of the domain to the multi-domain coordination node. The availability information indicates whether the network resource is available. Further, the control node is configured to provide administrative information for each of the network resources of the domain to the multi-domain coordination node. The administrative information enables distinguishing between at least two subgroups of the network resources in terms of accessibility by the customers.

According to a further embodiment of the invention, a customer-domain node is provided. The customer-domain node is configured to control network resources by interaction with at least one multi-domain coordination node. The multi-domain coordination node is associated with multiple network resource domains. Further, the customer-domain node is configured to obtain accessibility information for each of the network resources from the at least one multi- domain coordination node. The accessibility information indicates to which customer the network resource is accessible.

According to a further embodiment of the invention, a system for managing network infrastructure is provided. The system comprises at least one multi-domain coordination node associated with multiple network resource domains. Further, the system comprises a plurality of control nodes of the network resource domains. Further, the system comprises a plurality of customer-domain nodes, each associated with one of multiple customers sharing the network infrastructure. The multi-domain coordination node is configured to control network resources of the multiple network resource domains by interaction with the control nodes of the network resource domains. Further, the multi-domain coordination node is configured to obtain availability information for each of the network resources from the control nodes. The availability information indicates whether the network resource is available. Further, the multi- domain coordination node is configured to determine accessibility information for each of the network resources. The accessibility information indicates to which customer the network resource is accessible. Further, the multi-domain coordination node is configured to control utilization of at least one of the network resources by at least one of the customers depending on the availability information and the accessibility information. The control nodes of the system may each be configured to control network resources of the respective network resource domain by interaction with the at least one multi-domain coordination node. Further, each of the control nodes may be configured to provide the availability information for each of the network resources of the network resource domain to the multi-domain coordination node. Further, each of the control nodes may be configured to provide administrative information for each of the network resources of the network resource domain to the multi-domain coordination node. The administrative information enables distinguishing between at least two subgroups of the network resources in terms of accessibility by the customers and may be used by the multi-domain coordination node for determining the accessibility information.

The customer-domain nodes may each be configured to control network resources by interaction with the at least one multi-domain coordination node. Further, the customer- domain nodes may each be configured to obtain accessibility information for each of the network resources from the at least one multi-domain coordination node. The accessibility information indicates to which customer the network resource is accessible. According to a further embodiment of the invention, a computer program or computer program product is provided, e.g., in the form of a non-transitory storage medium, which comprises program code to be executed by at least one processor of a network control node. The network control node may for example correspond to the above-mentioned multi-domain coordination node, control node, or customer-domain node.

If the network control node corresponds to a multi-domain coordination node associated with multiple network resource domains, execution of the program code causes the network control node to control network resources of the multiple network resource domains by interaction with control nodes of the network resource domains. Further, execution of the program code causes the network control node to obtain availability information for each of the network resources from the control nodes. The availability information indicates whether the network resource is available. Further, execution of the program code causes the network control node to determine accessibility information for each of the network resources. The availability information indicates to which customer the network resource is accessible. Further, execution of the program code causes the network control node to control, depending on the availability information and the accessibility information, utilization of at least one of the network resources by at least one of the customers. If the network control node corresponds to a control node, execution of the program code causes the network control node to control network resources of a domain by interaction with a multi-domain coordination node associated with multiple domains of network resources. Further, execution of the program code causes the network control node to provide availability information for each of the network resources of the domain to the multi-domain coordination node. The availability information indicates whether the network resource is available. Further, execution of the program code causes the network control node to provide administrative information for each of the network resources of the domain to the multi- domain coordination node. The administrative information enables distinguishing between at least two subgroups of the network resources in terms of accessibility by the customers.

If the network control node corresponds to a customer domain node, execution of the program code causes the network control node to control network resources by interaction with at least one multi-domain coordination node. The multi-domain coordination node is associated with multiple network resource domains. Further, execution of the program code causes the network control node to obtain accessibility information for each of the network resources from the at least one multi-domain coordination node. The accessibility information indicates to which customer the network resource is accessible. Details of such embodiments and further embodiments will be apparent from the following detailed description of embodiments. Brief Description of the Drawings

Fig. 1 schematically a hierarchical network management architecture as used in an embodiment of the invention. Fig. 2 shows an example of a scenario in which network resources of different technology and provider domains are managed according to an embodiment of the invention.

Fig. 3 schematically illustrates how access to certain network resources of a certain domain may be controlled.

Fig. 4 shows an example of processes which may be performed in the scenario of Fig. 2 and 3.

Fig. 5 shows a further example of processes which may performed in the scenario of Fig. 2 and 3.

Fig. 6 shows a flowchart for schematically illustrating a method performed by a multi-domain coordination node according to an embodiment of the invention. Fig. 7 shows a block diagram for illustrating functionalities of a multi-domain coordination node according to an embodiment of the invention.

Fig. 8 shows a flowchart for schematically illustrating a further method performed by a control node according to an embodiment of the invention.

Fig. 9 shows a block diagram for illustrating functionalities of a control node according to an embodiment of the invention.

Fig. 10 shows a flowchart for schematically illustrating a further method performed by a customer-domain node according to an embodiment of the invention. Fig. 1 1 shows a block diagram for illustrating functionalities of a customer-domain node according to an embodiment of the invention.

Fig. 12 schematically illustrates structures of a network node according to an embodiment of the invention.

Detailed Description of Embodiments

In the following, concepts in accordance with exemplary embodiments of the invention will be explained in more detail and with reference to the accompanying drawings. The illustrated embodiments relate to management of network infrastructure shared by different customers. Such customer may correspond to an operators of a communication network, e.g., a communication network offering wireless or wire-based access to subscribers. Further, such customer may correspond to a provider of network based services, such as communication services or content distribution services. Further, such customer may correspond to a provider of network infrastructure, e.g., a provider of infrastructure for packet data communication or a provider of infrastructure for optical data communication. For example, such provider of infrastructure may use the shared network infrastructure for supplementing network infrastructure owned by the provider of infrastructure and/or offer the shared network infrastructure to another party (or customer). Further, such different customers may also correspond to different organizational entities of the same operator, service provider or provider of network infrastructure, e.g., two different departments the same organization. Usage of the shared network infrastructure by the different customers is assumed to be based on one or more SLAs. Such SLAs may include a mutual SLA of two or more of the customers and/or an SLA of one or more of the customers with another party, e.g., an owner of the shared network infrastructure. In the examples as further detailed below, it is assumed that the shared network infrastructure is managed based on an ACTN architecture. However, it is to be understood that the concepts could also be applied in a corresponding manner to other frameworks for hierarchical management of multi-domain networks.

Fig. 1 schematically illustrates the ACTN architecture as assumed herein. As illustrated, the ACTN architecture of Fig. 1 is based on a 3-tiers reference model. It allows for hierarchy and recursiveness not only of SDN controllers but also of traditionally controlled domains. It defines three types of controllers, depending on the functionalities they implement, namely one or more multi-domain coordination nodes 10, 1 1 , 12, referred to as MDSC (Multi Domain Service Coordinator), a plurality of control nodes 21 , 22, 23, 24, 25, referred to as PNC (Physical Network Controller), each responsible for controlling network resources 31 , 32, 33, 34, 35 of a corresponding domain, and multiple customer-domain nodes 41 , 42, 43, referred to as CNC (customer network controller), each associated with one of the different customers. These different controllers are coupled to each other through corresponding interfaces, in Fig. 1 shown by dashed arrows and designated as "ACTN i/f". It is noted that a "domain" as used herein may be defined as "everything that is under the control of the same controller", which includes network resources controlled by the same controller and also controllers controlled by the same higher level controller. The MDSC 10, 1 1 , 12 corresponds to a higher level controller that controls multiple domains. The CNCs 41 , 42, 43 are arranged on a first hierarchy level. The CNCs 41 , 42, 43 may instantiate virtual network services through the interface to the MDSCs 10, 1 1 , 12. This interface is also referred to as CMI (CNC-MDSC Interface). The CNC 41 , 42, 43 may have a direct application stratum interface and thus be aware of various application requirements and service needs.

The MDSCs 10, 1 1 , 12 are arranged on a second hierarchy level, situated below the first hierarchy level of the CNCs 41 , 42, 43 and a third hierarchy level of the PNCs 21 , 22, 23, 24, 25. In some scenarios, such as in the example of Fig. 1 , multiple MDSCs 10, 1 1 , 12 may be arranged in an hierarchical manner, for example such hierarchy of multiple MDSCs 10, 1 1 , 12 may used in view of scalability and/or administrative choices. As illustrated, one parent MDSC 10 may control multiple child MDSCs 1 1 , 12. Further, one MDSC 10, 1 1 , 12 may control multiple PNCs 21 , 22, 23, 24 25. In some scenarios, the same PNC could also be controlled by different MDSCs. The latter option may for example be useful when sharing the network resources controlled by the PNC among different customers not necessarily associated with the same MDSC.

The PNCs 21 , 22, 23, 24, 25 may be responsible for configuring physical network elements, such as servers, switches or routers, monitoring the physical topology of the network and passing it, in either raw or abstracted form, to the MDSCs 10, 1 1 , 12.

One functionality of the ACTN architecture may provide is combining the different domains to a single abstracted network topology offering end-to-end connections through different domains. In this way, the ACTN architecture may facilitate computation of end-to-end paths through different domains and thereby provisioning of communication paths and/or provisioning of services by the shared network infrastructure. A further functionality the ACTN architecture may provide is virtualization and/or abstraction of network resources: The ACTN architecture may be used to generate abstracted presentations of the controlled network resources 31 , 32, 33, 34, 35 towards the customers. Such abstracted presentations may be used by the customer itself, e.g., by operating personnel of the customer, and/or as a basis for automated processes at a higher level control entity, such as one of the CNCs 41 , 42, 43.

A still further functionality the ACTN architecture may provide is customer mapping: The ACTN architecture may map requests or commands from the customers into commands or requests to one or more of the PNCs 21 , 22, 23, 24, 25. This may be accomplished according to static policies, e.g. configured through an OSS (Operations Support System) and/or NMS (Network Management System) and/or according to dynamic policies, e.g. determined at the MDSC 10, 1 1 , 12 and/or CNC 41 , 42, 43. Similarly, the ACTN architecture may provide mapping of virtualized network resources (e.g., as presented to the customer) to physical network resources (e.g., as controlled by the PNCs).

A still further functionality the ACTN architecture may provide is coordination of virtual services: This may involve incorporation of service-related information from the customer level into virtual network operations. This may facilitate seamless operation of virtual networks while at the same time meeting the customer's service requirements.

Exemplary use cases and application scenarios for the ACTN architecture and interfaces and include, among the others: integration of network infrastructure provided by different lenders, integration of different domains of network infrastructure (e.g., domains based on different technologies, such as packet-based communication technology and optical communication technology, or domains associated with different providers). As mentioned above, the scenarios considered here and specifically involve sharing of network infrastructure by multiple customers, which is also referred to as "network slicing". The illustrated concepts address problems which may arise if the lower layer controllers, such as the PNCs 21 , 22, 23, 24, 25 are not capable of segregating their controlled network resources in terms of their accessibility by the different customers. In the illustrated concepts accessibility information indicating to which customer a certain network resource is accessible may be determined at the MDSC 10, 1 1 , 12. The accessibility information may then be used for controlling utilization of the network resources by one or more of the customers. On the one hand, this accessibility information may be based on service level information related to the different customers, e.g., based on SLAs of the customers. Corresponding policies may be configured in the MDSCs 10, 1 1 , 12, e.g., through an OSS or NMS. Further, such policies may be determined at the MDSC 10, 1 1 , 12, e.g., based on information received from the CNCs 41 , 42, 43. Further, the accessibility information may be based on administrative information from the PNCs 21 , 22, 23, 24, 25. The administrative information enables distinguishing between two or more subgroups of the controlled network resources in terms of their accessibility to the different customers. For example, this administrative information may correspond to a tagging, e.g., a color tagging similar to that as proposed in IETF RFC 4206 (October 2005) for GMPLS (Generalized Multi-Protocol Label Switching). In other words, the administrative information may correspond to a tagging of the network resources 31 , 32, 33, 34, 35 which assigns the network resources to one or more of different administrative groups, and these administrative groups are in turn mapped to the accessibility of the network resource to a certain customer. By way of example, the accessibility information could declare all network resources tagged as "blue" as being dedicated to a first customer. Similarly, the accessibility information could declare all network resources tagged as "green" as being dedicated to a second customer. Still further, the accessibility information could declare all network resources tagged as "yellow" as being shared by the first customer and the second customer. Such association of the administrative information to different accessibility levels may be valid for all domains controlled by the MDSC 10, 1 1 , 12 or even for all MDSCs 10, 1 1 , 12 utilized in the ACTN control hierarchy.

In this way, it becomes possible to define different abstracted network topologies for the different customers and present these different abstracted network topologies to the customers and/or use these different abstracted network topologies for controlling utilization of the network resources by the different customers. These abstracted topologies may also be augmented by the information whether a certain network resource is dedicated to the given customer, whether it is shared with one or more other customers, and in some cases also with which customer it is shared.

According to the concepts as illustrated herein, the accessibility information determined at the MDSC may be used in interaction of the MDSC with the PNCs and/or in interaction of the MDSC with the CNCs. As a result, management of the network resources may be performed in a highly efficient manner, taking into account the individual customers and the service requirements, such as mutual or other SLAs. In interaction of the PNCs and the MDSC, the PNC may indicate the availability of the network resources of its domain to the MDSC, e.g., in terms of a network topology. The network resources may correspond to physical network resources, such as physical links, and/or to virtualized network resources, such as virtual connections combining one or more physical links, but logically handled in the same way as a physical link. In the examples as further detailed below, the network resources are assumed to correspond to LSPs (Label Switching Paths) of a Multi-Protocol Label Switching (MPLS) technology, such as defined in IETF RFC 3031 (January 2001 ) or IETF RFC 3945 (October 2004). The network resources are associated with administrative information which enables distinction of subgroups of the network resources, such as by the above-mentioned color tagging. The administrative information may classify the network resources in terms of type of connection, in terms of quality, in terms of commercial value, and/or in terms of potential to be shared. The MDSC may then use this information and typically also information on SLAs of the customers to determine the availability information indicating to which customer a given network resource is available. This information may then for example be applied when handling requests or commands for setting up a connection for a certain customer. In interaction of the MDSC and the CNCs, the MDSC may utilize the accessibility information for filtering the network resources indicated by the PNCs. In this way, the MDSC may generate a filtered network topology which includes only the network resources which are accessible to a given customer and indicate the filtered network topology to the CNC of this customer. At the CNC, this filtered network topology may be presented to operating personnel or be otherwise used for improving efficiency of network management by the individual customer.

With reference to Figs. 2 to 5 a more specific use case will be described, which involves using the ACTN architecture (e.g. as shown in Fig. 1 ) for integration of different network domains associated with different providers and different technologies. Specifically, a scenario is assumed which involves a first domain associated with an optical network provider (corresponding to a first customer), a second domain associated with a first packet network provider (corresponding to a second customer), and a third domain associated with a second packet network provider (corresponding to a third customer). In the illustrated example, sharing of the network infrastructure of the optical network provider by the first packet network provider and the second packet network provider is considered. However, it is noted that other sharing scenarios are possible as well, such as sharing of the network infrastructure of the first packet network provider by the first packet network provider and the second packet network provider, sharing of the network infrastructure of the second packet network provider by the first packet network provider and the second packet network provider. Fig. 2 illustrates elements of the ACTN architecture as assumed in the illustrated example. Specifically, Fig. 2 schematically shows network resources 31 of the first domain, i.e., network resources of the optical network provider. Further, Fig. 2 schematically shows network resources 32-A, 32-B of the second domain, i.e., network resources of the first packet network provider. Still further, Fig. 2 schematically shows network resources 33-A, 33-B of the third domain, i.e., network resources of the second packet network provider. By way of example, Fig. 2 shows routers R21 , R22, R23, R24, R25, R26 as exemplary network elements of the second domain, and routers R31 , R32, R33, R34, R35, R36 as exemplary network elements of the third domain. Further, Fig. 2 shows an optical PNC 21 controlling the network resources of the first domain, a first packet PNC 22 (PNC-1 ) controlling the network resources of the second domain, and a second packet PNC 23 (PNC-2) controlling the network resources of the third domain. Moreover, Fig. 2 shows an MDSC 1 1 controlling the PNCs 21 , 22, 23 of the different domains. The different network domains may thus interact and cooperate through the MDSC 1 1 . As indicated by the reference numerals, the MDSC 1 1 and the PNCs 21 , 22, 23 could for example be part of the ACTN architecture as illustrated in Fig. 1 .

In the illustrated example, the network resources 32-A, 32-B of the second domain are assumed to be separated into a first network segment 32-A and a second network segment 32-B, without any connectivity of these two network segments by the network resources of the second domain itself. Similarly, the network resources 33-A, 33-B of the third domain are assumed to be separated into a first network segment 33-A and a second network segment 33-B, without any connectivity of these two network segments by the network resources of the third domain itself. However, connectivity of the separated network segments 32-A, 32-B, 33-A, 33-B can be obtained through the network resources of the first domain: In the illustrated example, the routers R22 and R24 are assumed to provide connectivity of the second domain to the first domain. Specifically, the router R22 connects the first network segment 32-A of the second domain to the first domain, and the router R24 connects the second network segment 32-B of the second domain to the first domain. The routers R32 and R34 are assumed to provide connectivity of the third domain to the first domain. Specifically, the router R32 connects the first network segment 33-A of the third domain to the first domain, and the router R24 connects the second network segment 33-B of the third domain to the first domain. Fig. 3 further illustrates the network resources 31 for the first domain, which may be shared by the first packet network provider and the second packet network provider, and how the network resources 31 of the first domain may be used by the first packet network provider for connecting the first network segment 32-A and the second network segment 32-B of the second network domain. More specifically, Fig. 3 illustrates optical switches S1 1 , S12, S13, S14, S15, S16 as exemplary network elements of the first network domain. Further, Fig. 3 shows a first LSP 301 (illustrated by a solid line), a second LSP 302 (illustrated by a dashed line), and a third LSP 303 (illustrated by a dotted line). The first LSP 301 and the second LSP 302 extend from the optical switch S1 1 via the optical switch S13 to the optical switch S15. The third LSP 303 extends from the optical switch S1 1 via the optical switch S12 and the optical switch S14 to the optical switch S15. The first LSP 301 , the second LSP 302, the third LSP three and 03 are associated with different administrative information. In the illustrated example, the LSPs 301 , 302, 303 is are assumed to be tagged with different administrative colors. In the following, it is by way of example assumed that the first LSP 301 is tagged with the administrative color "green", the second LSP 302 is tagged with the administrative color "red", and the third LSP 303 is tagged with the administrative color "red". The optical PNC 21 indicates the available LSPs 301 , 302, 303 and the associated administrative information, i.e., the tagging with administrative colors, to the MDSC 1 1. Depending on SLAs of the optical network provider, the first packet network provider, and the second network provider, the MDSC 1 1 may then determine the accessibility of the LSPs 301 , 302, 303 to the first packet network provider, the second packet network provider, and the optical network provider. For example, the network resources tagged with the administrative color "green" could be shared and thus accessible to each of the first packet network provider, the second packet network provider, and the optical network provider, while the network resources tagged with the administrative color "red" could be dedicated to the first packet network provider and the network resources tagged with the administrative color "blue" could be dedicated to the optical network provider. Accordingly, the first LSP 301 would be shared by the first packet network provider, the second packet network provider, and the optical network provider, the second LSP 302 would be dedicated to the first packet network provider, and the third LSP 303 would be dedicated to the optical network provider. Accordingly, a filtered network topology customized to the first packet network provider would show the first LSP 301 and the second LSP 302, but not the third LSP 303, while a filtered network topology customized to the second packet network provider would show the first LSP 301 , but not second LSP 302 and the third LSP 303. In the present example, the first packet network provider may thus decide between using the first LSP 301 and the second LSP 302 for establishing an end-to-end connection from a node in the first network segment 32-A to a node in the second network segment 32-B. By way of example, the first packet network provider could decide to use the first LSP 301 , which is shared, to thereby save dedicated network resources (such as the second LSP 302) for other purposes. Fig. 4 shows an example of processes which could be used in the above scenario for setting up an end-to-end connection from a node in the first network segment 32-A of the second domain, e.g., the router R21 , to a node in the second network segment 32-B of the second domain, e.g., the router R26. The processes of Fig. 4 involve the MDSC 1 1 , the optical PNC 21 , the first packet PNC 22, and a CNC 41 of the first packet network provider.

As illustrated by messages 401 and 402, the optical PNC 21 and the first packet PNC 22 may first indicate availability of LSPs to the MDSC 1 1. In the present example, this would involve that the optical PNC 21 indicates availability of the first LSP 301 , tagged with the administrative color "green", the second LSP 302, tagged with the administrative color "red", and the third LSP 303, tagged with the administrative color "blue" to the MDSC 1 1 . Further, this may involve that the first packet PNC 22 indicates available LSPs in the second domain to the MDSC 1 1 , such as LSPs from the node in the first network segment 32-A to the router R22 and LSPs from the route R24 to the node in the second network segment 32-B.

As indicated by step 403, the MDSC 1 1 may then determine the accessibility of the network resources to the different customers. By way of example, for assessing the accessibility of the network resources indicated by the optical PNC 21 , the and MDSC 1 1 may consider information based on an SLA of the first packet network provider and the optical network provider. In this way, the MDSC 1 1 may determine that the first LSP 301 is shared and thus usable by the first packet network provider, that the second LSP 302 is dedicated to the first packet network provider, and that the third LSP 303 is dedicated to the optical network provider and thus not usable by the first packet network provider. Similar determinations may be made for the available LSP is indicated by the first packet PNC 22. Based on this accessibility information, the MDSC 1 1 then determines augmented LSP availabilities, which include the shared resources of other network domains and pushes these augmented LSP availabilities to the PNC's 21 , 22, as indicated by messages 404, 405. In the present example, this means that the first packet PNC 22 is informed of additional available network resources, namely the first LSP 301 and the second LSP 303, which can be used for establishing the end-to-end connection.

As illustrated by message 406, the CNC 41 may then issue a command or request for setting up the end-to-end connection from the node in the first network segment 32-A to the node in the second network segment 32-B. The MDSC 1 1 maps this request or command to a corresponding request or command to the first packet PNC 22. As illustrated by step 408, the first packet PNC 22 may then perform path computation. In this path computation, the first packet PNC 22 may also consider the additional network resources indicated by the augmented LSP availabilities. As a result, the first packet PNC 22 may for example provide a path which includes the first LSP 301 .

As illustrated by signaling 409, the first packet PNC 22 may then negotiate utilization of the first LSP 301 with the MDSC 1 1. For example, the first packet PNC 22 may request access to the first LSP 301 from the MDSC 1 1 , and the MDSC 1 1 may grant this access and acknowledge those to the first packet PNC 22. As illustrated by message 410, the MDSC 1 1 may then instruct the optical PNC 21 to set up a connection between the optical switch 1 1 and the optical switch is 15 using the first LSP 301 , as part of the desired end-to-end connection from the node in the first network segment 32-A to the node in the second network segment 32-B.

Fig. 5 shows a further example of processes which could be used in the above scenario for setting up an end-to-end connection from a node in the first network segment 32-A of the second domain, e.g., the router R21 , to a node in the second network segment 32-B of the second domain, e.g., the router R26. The processes of Fig. 5 involve the MDSC 1 1 , the optical PNC 21 , the first packet PNC 22, and a CNC 41 of the first packet network provider. As compared to the processes of Fig. 4, the processes of Fig. 5 avoid indicating the augmented LSP availability to the PNCs 21 , 22, and the accessibility information is used locally in the MDSC 1 1 for controlling utilization of the network resources by the different customers.

As illustrated by messages 501 and 405, the optical PNC 21 and the first packet PNC 22 may first indicate availability of LSPs to the MDSC 1 1. In the present example, this would involve that the optical PNC 21 indicates availability of the first LSP 301 , tagged with the administrative color "green", the second LSP 302, tagged with the administrative color "red", and the third LSP 303, tagged with the administrative color "blue" to the MDSC 1 1 . Further, this may involve that the first packet PNC 22 indicates available LSPs in the second domain to the MDSC 1 1 , such as LSPs from the node in the first network segment 32-A to the router R22 and LSPs from the route R24 to the node in the second network segment 32-B.

As indicated by step 503, the MDSC 1 1 may then determine the accessibility of the network resources to the different customers. By way of example, for assessing the accessibility of the network resources indicated by the optical PNC 21 , the and MDSC 1 1 may consider information based on an SLA of the first packet network provider and the optical network provider. In this way, the MDSC 1 1 may determine that the first LSP 301 is shared and thus usable by the first packet network provider, that the second LSP 302 is dedicated to the first packet network provider, and that the third LSP 303 is dedicated to the optical network provider and thus not usable by the first packet network provider. Similar determinations may be made for the available LSP is indicated by the first packet PNC 22. As illustrated by message 505, the CNC 41 may then issue a command or request for setting up the end-to-end connection from the node in the first network segment 32-A to the node in the second network segment 32-B. Then MDSC 1 1 may then use the LSP availabilities indicated by the PNCs 21 , 22 and the determined accessibility information for performing path computation. As a result, the first packet MDSC 1 1 may for example provide a path which includes the first LSP 301. Having computed the path, the MDSC 1 1 may also negotiate with the CNC 41 , e.g., to obtain confirmation from the CNC 41 that the computed path should be utilized, as illustrated by signaling 506. The negotiation could also be used for selecting between multiple possible paths, e.g., a path including the first LSP 301 and a path including the second LSP 302. The MDSC 1 1 then generates commands to the optical PNC 21 and to the first packet PNC 22 to set up the end-to-end connection based on the computed path.

It is noted that the process elements explained in connection with Fig. 4 and Fig. 5 are not necessarily a complete representation of the process for setting the up end-to-end connection. For example, this process could also include confirmation of path setup to the CNC 41 . Further, after granting the first packet provider access to the first LSP 301 , the MDSC 1 1 could update the availability of LSPs in the system accordingly and also indicate to other customers that the first LSP 301 is no longer available. Further, the MDSC 1 1 may filter the available network resources indicated by the optical PNC 21 and the first packet PNC 22 based on the accessibility information to generate a filtered representation of the network topology which includes only the network resources accessible to a specific customer. For example, such filtered representation of the network topology could include only the network resources which are accessible to the first packet network provider. The MDSC 1 1 could also indicate the filtered representation of the network topology to the CNC 41 , where it could be used as a basis for control processes for presenting information to operating personnel.

Fig. 6 shows a flowchart for illustrating a method of managing network infrastructure shared by different customers. The method of Fig. 6 may be utilized for implementing the illustrated concepts in multi-domain coordination node associated with multiple network resource domains, e.g., one of the MDSCs 10, 1 1 , 12. If a processor-based implementation of the multi-domain coordination node is used, the steps of the method may be performed by one or more processors of the multi-domain coordination node. In such a case the multi-domain coordination node may further comprise a memory in which program code for implementing the below described functionalities is stored.

At step 610, the multi-domain coordination node controls network resources of the multiple network resource domains, such as the above-mentioned network resources 31 , 32, 33, 34, 35. This is accomplished by interaction with control nodes of the network resource domains, such as the above-mentioned to PNCs 21 , 22, 23, 24, 25. This may for example involve issuing commands to the control nodes or responding to requests from the control nodes. The interaction may also be indirect, e.g., be mediated by one or more intermediate nodes. This may for example be the case when using a multi-level hierarchy of multi-domain coordination nodes as for example shown in Fig. 1. The network resources may include physical network resources, such as physical links. In addition or as an alternative, the network resources may include virtualized network resources, e.g., virtualized links composed of multiple physical links. For example, the network resources may correspond to LSPs.

At step 620, the multi-domain coordination node obtains availability information for each of the network resources from the control nodes. The availability information indicates whether the network resource is available. Examples of such availability information are the LSP availabilities indicated by messages 401 , 402 of Fig. 4 and by messages 501 , 502 of Fig. 5.

At optional step 630, the multi-domain coordination node may obtain administrative information for each of the network resources from the control nodes. The administrative information enables distinguishing between at least two subgroups of the network resources. The administrative information may for example correspond to an administrative color tagging or to a similar kind of administrative extension.

At step 640, the multi-domain coordination node determines accessibility information for each of the network resources. The accessibility information indicates to which customer the network resource is accessible. The multi-domain coordination node may determine the accessibility information depending on service level information defined for each customer, e.g., information based on one or more SLAs of the customers.

In some scenarios, the multi-domain coordination node may determine the accessibility information depending on the administrative information obtained at step 640. For example, the multi-domain coordination node may map different accessibility levels to corresponding administrative extensions, e.g., different administrative colors. The different accessibility levels may for example include that the network resource these shared by multiple customers. In some cases, different accessibility levels may be defined depending on the customers sharing the network resource. Accordingly, the accessibility information may indicate whether the network resource is shared by at least two of the customers, and optionally also by which customers the network resource is shared. In some scenarios, the different accessibility levels may also include that the network resource is dedicated to a certain customer. Different accessibility levels may be defined depending on the customer to which the network resources dedicated. Accordingly, the accessibility information may indicate whether the network resource is dedicated to one of the customers.

In some scenarios, the multi-domain coordination node may determine the accessibility information depending on interaction with a customer-domain node associated with one of the customers. For example, the customer-domain node may provide information for authorizing access to the network resources and/or service level information related to the customer associated with the customer domain node, e.g., information based on an SLA of the customer.

In some scenarios, the multi-domain coordination node may determine the accessibility information depending on the interaction with the control nodes. For example, the multi- domain coordination node may interact with the control nodes to obtain the administrative information of step 630. Further, interaction with one or more of the control nodes may involve granting access to a network resource to a certain customer, which may render the corresponding network resource inaccessible to other customers. As indicated by optional step 650, the multi-domain coordination node may filter the network resources depending on the accessibility information of step 620 and the availability information of step 630. For example, this filtering may be used to obtain a filtered network topology including only those network resources which are accessible to a certain customer. At optional step 660, the multi-domain coordination node may indicate the accessibility information to one or more other nodes. In some scenarios, the multi-domain coordination node may indicate the accessibility information to at least one of the control nodes. For example, in the processes of Fig. 4 the accessibility information is indicated in terms of the augmented LSP availability to the PNCs 21 , 22. In some scenarios, the multi-domain coordination node may indicate the accessibility information to a customer-domain node, such as one of the CNCs 41 , 42, 43. For example, the accessibility information may be indicated in terms of the above-mentioned filtered network topology. At the customer-domain node, the accessibility information may then be used as a basis for control processes and/or for presenting information to operating personnel.

At step 670, the multi-domain coordination node controls utilization of at least one of the network resources by at least one of the customers. This is accomplished depending on the availability information and the accessibility information obtained at steps 620 and 630. This may comprise negotiation of resource utilization with a customer-domain node associated with one of the customers, such as mentioned in connection with signaling 506 of Fig. 5. Further, also message 406 of Fig. 4 and message 505 of Fig. 5 may be part of such negotiation.

In some scenarios, the multi-domain coordination node may indicate, to the control node of a first network resource domain, availability information and administrative information for at least one further network resource of a second network domain. This may be accomplished if the further network resource of the second network resource domain is accessible to the customer associated with the first network resource domain. This information may then be used by the control node of the first network resource domain for controlling control utilization of the network resources of the first network resource domain and of the at least one further network resource. A corresponding example is illustrated in connection with Fig. 4, where the PNC 22 receives availability information and administrative information for network resources of the other domain (the domain of the optical network operator) in terms of the augmented LSP availability and then utilizes this information in path computation.

Fig. 7 shows a block diagram for illustrating functionalities of a multi-domain coordination node 700 which operates according to the method of Fig. 6. As illustrated, the multi-domain coordination node 700 may be provided with a module 710 configured to control network resources by interaction with control nodes of multiple network domains, such as explained in connection with step 610. Further, the multi-domain coordination node 700 may be provided with a module 720 configured to obtain availability information, such as explained in connection with step 620. Further, the multi-domain coordination node 700 may optionally be provided with a module 730 configured to obtain administrative information, such as explained in connection with step 630. Further, the multi-domain coordination node 700 may be provided with a module 740 configured to determine accessibility information, such as explained in connection with step 640. Further, the multi-domain coordination node 700 may optionally be provided with a module 750 configured to filter the network resources depending on the availability information and the accessibility information, such as explained in connection with step 650. Further, the multi-domain coordination node 700 may optionally be provided with a module 760 configured to indicate the accessibility information to one or more other nodes, such as explained in connection with step 660. Further, the multi-domain coordination node 700 may be provided with a module 770 configured to control network resource utilization, such as explained in connection with step 670.

It is noted that the multi-domain coordination node 700 may include further modules for implementing other functionalities, such as known functionalities of an MDSC. Further, it is noted that the modules of the multi-domain coordination node 700 do not necessarily represent a hardware structure of the multi-domain coordination node 700, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof.

Fig. 8 shows a flowchart for illustrating a method of managing network infrastructure shared by different customers. The method of Fig. 8 may be utilized for implementing the illustrated concepts in a control node associated with multiple network resource domains, e.g., one of the PNCs 21 , 22, 23, 24, 25. If a processor-based implementation of the control node is used, the steps of the method may be performed by one or more processors of the control node. In such a case the control node may further comprise a memory in which program code for implementing the below described functionalities is stored.

At step 810, the control node controls network resources of a domain, such as the above- mentioned network resources 31 , 32, 33, 34, 35, by interaction with a multi-domain coordination node associated with multiple domains of network resources, such as one of the MDSCs 10, 1 1 , 12. This interaction may for example involve issuing commands to the control nodes for responding to requests from the control nodes. The interaction may also be indirect, e.g., be mediated by one or more intermediate nodes. This may for example be the case when using a multi-level hierarchy of multi-domain coordination nodes as for example shown in Fig. 1 . The network resources may include physical network resources, such as physical links. In addition or as an alternative, the network resources may include virtualized network resources, e.g., virtualized links composed of multiple physical links. For example, the network resources may correspond to LSPs.

At step 820, the control node provides availability information for each of the network resources of the domain to the multi-domain coordination node. The availability information indicates whether the network resource is available. Examples of such availability information are the LSP availabilities indicated by messages 401 , 402 of Fig. 4 and by messages 501 , 502 of Fig. 5. At step 830, the control node provides administrative information for each of the network resources of the domain to the multi-domain coordination node. The administrative information enables distinguishing between at least two subgroups of the network resources in terms of accessibility by the customers. The administrative information may for example correspond to an administrative color tagging or to a similar kind of administrative extension.

At optional step 840, the control node may obtain accessibility information from the multi- domain coordination node. The accessibility information indicates, for each of the network resources of the domain, to which customer the network resource is accessible. The accessibility information may be determined depending on service level information defined for each customer, e.g., information based on one or more SLAs of the customers. Further, the accessibility information may be determined depending on the availability information and the administrative information provided at steps 820 and 830 to the multi-domain coordination node. For example, different accessibility levels may be mapped to corresponding administrative extensions, e.g., different administrative colors. The different accessibility levels may for example include that the network resource these shared by multiple customers. In some cases, different accessibility levels may be defined depending on the customers sharing the network resource. Accordingly, the accessibility information may indicate whether the network resource is shared by at least two of the customers, and optionally also by which customers the network resource is shared. In some scenarios, the different accessibility levels may also include that the network resource is dedicated to a certain customer. Different accessibility levels may be defined depending on the customer to which the network resources dedicated. Accordingly, the accessibility information may indicate whether the network resource is dedicated to one of the customers.

At optional step 850, the control node may obtain, from the multi-domain coordination node, availability information and administrative information for at least one further network resource of another domain. Depending on the availability information and administrative information for the at least one further network resource of the other domain, the control node may then control utilization of the network resources of the domain and the at least one further network resource of the other domain, as indicated by optional step 860. A corresponding example is illustrated in connection with Fig. 4, where the PNC 22 receives availability information and administrative information for network resources of the other domain in terms of the augmented LSP availability and then utilizes this information in path computation. Fig. 9 shows a block diagram for illustrating functionalities of a control node 900 which operates according to the method of Fig. 8. As illustrated, the control node 900 may be provided with a module 910 configured to control network resources of a domain by interaction with a multi-domain coordination node associated with multiple network domains, such as explained in connection with step 810. Further, the control node 900 may be provided with a module 920 configured to indicate availability information, such as explained in connection with step 820. Further, the control node 900 may be provided with a module 930 configured to indicate administrative information, such as explained in connection with step 830. Further, the control node 900 may optionally be provided with a module 940 configured to obtain accessibility information, such as explained in connection with step 840. Further, the control node 900 may optionally be provided with a module 950 configured to obtain availability information and administrative information for at least one further network resource of another domain, such as explained in connection with step 850. Further, the control node 900 may optionally be provided with a module 960 configured to control utilization of network resources depending on the availability information and administrative information for the at least one further network resource of the other domain, such as explained in connection with step 860.

It is noted that the control node 900 may include further modules for implementing other functionalities, such as known functionalities of a PNC. Further, it is noted that the modules of the control node 900 do not necessarily represent a hardware structure of the control node 900, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof. Fig. 10 shows a flowchart for illustrating a method of managing network infrastructure shared by different customers. The method of Fig. 10 may be utilized for implementing the illustrated concepts in a customer-domain node associated with one of the different customers, e.g., one of the CNCs 41 , 42, 43. If a processor-based implementation of the customer-domain node is used, the steps of the method may be performed by one or more processors of the customer-domain node. In such a case the customer-domain node may further comprise a memory in which program code for implementing the below described functionalities is stored.

At step 1010, the customer-domain node controls network resources, such as the above- mentioned network resources 31 , 32, 33, 34, 35, by interaction with at least one multi-domain coordination node associated with multiple network resource domains, such as the above- mentioned to MDSCs 10, 1 1 , 12. This interaction may for example involve issuing requests or commands to the multi-domain coordination node(s) or responding to requests from the multi-domain coordination node(s). Further, this may involve negotiation of resource utilization with a customer-domain node associated with one of the customers, such as mentioned in connection with signaling 506 of Fig. 5. Further, also message 406 of Fig. 4 and message 505 of Fig. 5 may be part of such negotiation. The interaction may also be indirect, e.g., be mediated by one or more intermediate nodes. This may for example be the case when using a multi-level hierarchy of multi-domain coordination nodes as for example shown in Fig. 1 . The network resources may include physical network resources, such as physical links. In addition or as an alternative, the network resources may include virtualized network resources, e.g., virtualized links composed of multiple physical links. For example, the network resources may correspond to LSPs.

At optional step 1020, the customer-domain node may obtain availability information for each of the network resources from the at least one multi-domain coordination node. The availability information indicates whether the network resource is available. The availability information indicates whether the network resource is available. Examples of such availability information are the LSP availabilities indicated by messages 401 , 402 of Fig. 4 and by messages 501 , 502 of Fig. 5. At step 1030, the node customer-domain node obtains accessibility information for each of the network resources from the at least one multi-domain coordination node. The accessibility information indicates to which customer the network resource is accessible. The accessibility information may be determined depending on service level information defined for each customer. According to an example, different accessibility levels may be mapped to corresponding administrative extensions, e.g., different administrative colors. The different accessibility levels may for example include that the network resource these shared by multiple customers. In some cases, different accessibility levels may be defined depending on the customers sharing the network resource. Accordingly, the accessibility information may indicate whether the network resource is shared by at least two of the customers, and optionally also by which customers the network resource is shared. In some scenarios, the different accessibility levels may also include that the network resource is dedicated to a certain customer. Different accessibility levels may be defined depending on the customer to which the network resources dedicated. Accordingly, the accessibility information may indicate whether the network resource is dedicated to one of the customers.

In some scenarios, accessibility information may be determined depending on interaction of the customer-domain node with the multi-domain coordination node. For example, the customer-domain node may provide information for authorizing access to the network resources and/or service level information related to the customer associated with the customer domain node, e.g., information based on an SLA of the customer, and the multi- domain coordination node may determine the accessibility information based on this information.

In some scenarios, the customer-domain node may receive the availability information of step 1020 and the accessibility information of step 1030 in combination. For example, the availability information and the accessibility information may be indicated in terms of a filtered network topology including only those network resources which are accessible to the customer the customer-domain node is associated with.

At optional step 1040, the customer-domain node may use the accessibility information as a basis for presenting information to operating personnel. Alternatively or in addition, the accessibility information may also be used as a basis for various control processes.

Fig. 1 1 shows a block diagram for illustrating functionalities of a customer-domain node 1 100 which operates according to the method of Fig. 10. As illustrated, the customer-domain node 1 100 may be provided with a module 1 1 10 configured to control network resources by interaction with a multi-domain coordination node associated with multiple network domains, such as explained in connection with step 1010. Further, the customer-domain node 1 100 may optionally be provided with a module 1020 configured to obtain availability information, such as explained in connection with step 1020. Further, the customer-domain node 1 100 may be provided with a module 1030 configured to obtain accessibility information, such as explained in connection with step 930. Further, the customer-domain node 1 100 may optionally be provided with a module 1040 configured to present information to operating personnel, such as explained in connection with step 1040.

It is noted that the customer-domain node 1 100 may include further modules for implementing other functionalities, such as known functionalities of a CNC. Further, it is noted that the modules of the customer-domain node 1 100 do not necessarily represent a hardware structure of the customer-domain node 1 100, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof.

It is noted that the methods of Figs. 6, 8, and 10 may also be combined in a system including at least one multi-domain coordination node operating according to the method of Fig. 6, multiple control nodes operating according to the method of Fig. 8, and multiple customer- domain nodes operating according to the method of Fig. 10.

Fig. 12 illustrates a processor-based implementation of a network control node 1200 which may be used for implementing the above described concepts. The network control node 1200 may correspond to a multi-domain coordination node operating according to the method of Fig. 6, such as one of the above-mentioned MDSC 10, 1 1 , 12. Further, the network control node 1200 may correspond to a control node operating according to the method of Fig. 8, such as one of the above-mentioned PNCs 21 , 22, 23, 24, 25. Further, the network control node 1200 may correspond to a customer-domain node operating according to the method of Fig. 10, such as one of the above-mentioned CNCs 41 , 42, 43.

As illustrated, the network control node 1200 may include a control interface 1210 for sending information to other nodes and/or for receiving information from other nodes. The control interface 1210 may for example correspond to an ACTN interface.

Further, the network control node 1200 may include one or more processors 1250 coupled to the control interface 1210 and a memory 1260 coupled to the processor(s) 1250. By way of example, the interface 1210, the processor(s) 1250, and the memory 1260 could be coupled by one or more internal bus systems of the network control node. The memory 1260 may include a ROM, e.g., a flash ROM, a Random Access Memory (RAM), e.g., a Dynamic RAM (DRAM) or Static RAM (SRAM), a mass storage, e.g., a hard disk or solid state disk, or the like. As illustrated, the memory 1260 may include software 1270, firmware 1280, and/or control parameters 1290. If the network control node corresponds to the above-mentioned multi-domain coordination node, the memory 1260 may include suitably configured program code to be executed by the processor(s) 1250 so as to implement the above-described functionalities of a multi-domain coordination node, such as explained in connection with Fig. 6. If the network control node corresponds to the above-mentioned control node, the memory 1260 may include suitably configured program code to be executed by the processor(s) 1250 so as to implement the above-described functionalities of a control node, such as explained in connection with Fig. 8. If the network control node corresponds to the above-mentioned customer-domain node, the memory 1260 may include suitably configured program code to be executed by the processor(s) 1250 so as to implement the above-described functionalities of a customer-domain node, such as explained in connection with Fig. 10. This program code may be stored as part of the software 1270 and/or as part of the firmware 1280. Further, this program code may operate using one or more of the control parameters 1290. It is to be understood that the structures as illustrated in Fig. 12 are merely schematic and that the network control node 1200 may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces or processors. Also, it is to be understood that the memory 1260 may include further program code for implementing known functionalities of an MDSC, PNC, or CNC. According to some embodiments, also a computer program may be provided for implementing functionalities of the network control node 1200, e.g., in the form of a physical medium storing the program code and/or other data to be stored in the memory 1260 or by making the program code available for download or by streaming.

As can be seen, the concepts as described above may be used for efficiently managing network resources organized in different domains and shared by different customers. For example, the concepts may be used for efficiently augmenting network resources of one domain with accessible network resources of another domain. Further, SLAs of different customers may be considered in an efficient way. Further, some network resources may be dedicated to a certain customer, while others may be declared as shared by multiple customers, and search assignment of network resources as shared or dedicated to a certain customer may be flexibly adapted. For example, such functionalities may be used for dedicating certain network resources to a premium customer, while sharing other network resources among multiple customers.

Further, it is noted that implementing the determination of the accessibility information in the MDSC on a similar multi-domain coordination node allows for efficient modification of the accessibility information. For example, if a policy concerning the accessibility of an individual network resources is changed, only the associated administrators information would need to be changed, e.g., by changing the administrative color. On the other hand, if a policy concerning the accessibility of entire groups of network resources is changed, this may efficiently be accomplished by modifying the mapping of administrators colors to accessibility levels. Further, determining the accessibility information at a centralized node like the MDSC may facilitate scheduling of shared resources, because the controllers of other domains may be informed by the MDSC when a shared resource becomes available. Still further, the MDSC may act as a trusted entity among the different domains and thus allow for implementing the sharing of network resources without a need to consider confidential utility issues associated with direct exchange of information between different domains.

It is to be understood that the examples and embodiments as explained above are merely illustrative and susceptible to various modifications. For example, the illustrated concepts may be applied in connection with various kinds of network technologies, without limitation to a packet network technologies optical network technologies. Further, the illustrated concepts may be applied in connection with various kinds of control nodes or multi-domain control frameworks. It is also noted that when using other kinds of control frameworks, the designations of individual types of controllers may deviate from the above designations according to the ACTN terminology. Moreover, it is to be understood that the above concepts may be implemented by using correspondingly designed software to be executed by one or more processors of an existing device, or by using dedicated device hardware. Further, it should be noted that the illustrated nodes may each be implemented as a single device or as a system of multiple interacting devices.

Claims

1 . A method of managing network infrastructure shared by different customers, the method comprising:

- a multi-domain coordination node (10, 1 1 , 12; 700; 1200) associated with multiple network resource domains (10, 1 1 , 12; 700; 1200) controlling network resources (31 , 32, 33, 34, 35) of the multiple network resource domains by interaction with control nodes (21 , 22, 23, 24, 25; 900; 1200) of the network resource domains;

- for each of the network resources (31 , 32, 33, 34, 35), the multi-domain coordination node (10, 1 1 , 12; 700; 1200) obtaining availability information from the control nodes (21 , 22, 23,

24, 25; 900; 1200), the availability information indicating whether the network resource (31 , 32, 33, 34, 35) is available;

- for each of the network resources (31 , 32, 33, 34, 35), the multi-domain coordination node (10, 1 1 , 12; 700; 1200) determining accessibility information indicating to which customer the network resource (31 , 32, 33, 34, 35) is accessible; and

- depending on the availability information and the accessibility information, the multi-domain coordination node (10, 1 1 , 12; 700; 1200), controlling utilization of at least one of the network resources (31 , 32, 33, 34, 35) by at least one of the customers.

2. The method according to claim 1 , comprising:

the multi-domain coordination node (10, 1 1 , 12; 700; 1200) filtering the network resources (31 , 32, 33, 34, 35) depending on the accessibility information and the availability information.

3. The method according to claim 1 or 2, comprising:

- the multi-domain coordination node (10, 1 1 , 12; 700; 1200) indicating the accessibility information to at least one of the control nodes (21 , 22, 23, 24, 25; 900; 1200).

4. The method according to any one of the preceding claims,

wherein said controlling utilization of at least one of the network resources (31 , 32, 33, 34, 35) by at least one of the customers comprises negotiation of resource utilization with a customer-domain node (41 , 42, 43; 1 100; 1200) associated with one of the customers.

5. The method according to claim 4, comprising:

- the multi-domain coordination node (10, 1 1 , 12; 700; 1200) determining the accessibility information depending on interaction with the customer-domain node (41 , 42, 43; 1 100; 1200).

6. The method according to claim 4 or 5, comprising:

- the multi-domain coordination node (10, 1 1 , 12; 700; 1200) indicating the accessibility information to the customer-domain node (41 , 42, 43; 1 100; 1200).

7. The method according to any one of the preceding claims, comprising:

- the multi-domain coordination node (10, 1 1 , 12; 700; 1200) determining the accessibility information depending on the interaction with the control nodes (21 , 22, 23, 24, 25; 900; 1200).

8. The method according to any one of the preceding claims, comprising:

- for each of the network resources, the multi-domain coordination node (10, 1 1 , 12; 700; 1200) obtaining administrative information from the control nodes (21 , 22, 23, 24, 25; 900; 1200), the administrative information enabling distinguishing between at least two subgroups of the network resources (31 , 32, 33, 34, 35); and

- the multi-domain coordination node (10, 1 1 , 12; 700; 1200) determining the accessibility information depending on the administrative information.

9. The method according to any one of the preceding claims, comprising:

- the multi-domain coordination node (10, 1 1 , 12; 700; 1200) determining the accessibility information depending on service level information defined for each customer.

10. The method according to any one of the preceding claims,

wherein the network resources (31 , 32, 33, 34, 35) comprise label switching paths for establishing a connection between network nodes.

1 1 . The method according to any one of the preceding claims,

wherein the accessibility information indicates whether the network resource (31 , 32, 33, 34, 35) is shared by at least two of the customers.

12. The method according to claim 1 1 ,

wherein the accessibility information indicates by which customers the network resource (31 , 32, 33, 34, 35) is shared.

13. The method according to any one of the preceding claims,

wherein the accessibility information indicates whether the network resource (31 , 32, 33, 34, 35) is dedicated to one of the customers.

14. A method of managing network infrastructure shared by different operator entities, the method comprising:

- a control node (21 , 22, 23, 24, 25; 900; 1200) controlling network resources (31 , 32, 33, 34, 35) of a domain by interaction with a multi-domain coordination node (10, 1 1 , 12; 700; 1200) associated with multiple domains of network resources (31 , 32, 33, 34, 35);

- for each of the network resources (31 , 32, 33, 34, 35) of the domain, the control node (21 , 22, 23, 24, 25; 900; 1200) providing availability information to the multi-domain coordination node (10, 1 1 , 12; 700; 1200), the availability information indicating whether the network resource (31 , 32, 33, 34, 35) is available; and

- for each of the network resources (31 , 32, 33, 34, 35) of the domain, the control node (21 ,

22, 23, 24, 25; 900; 1200) providing administrative information to the multi-domain coordination node (10, 1 1 , 12; 700; 1200), the administrative information enabling distinguishing between at least two subgroups of the network resources (31 , 32, 33, 34, 35) in terms of accessibility by the customers.

15. The method according to claim 14, comprising:

- the control node (21 , 22, 23, 24, 25; 900; 1200) obtaining, from the multi-domain coordination node (10, 1 1 , 12; 700; 1200), availability information and administrative information for at least one further network resource (31 , 32, 33, 34, 35) of another domain; and

- depending on the availability information and administrative information for the at least one further network resource (31 , 32, 33, 34, 35) of the other domain, the control node (21 , 22,

23, 24, 25; 900; 1200) controlling utilization of the network resources (31 , 32, 33, 34, 35) of the domain and the at least one further network resource (31 , 32, 33, 34, 35) of the other domain.

16. The method according to claim 14 or 15, comprising:

- the control node (21 , 22, 23, 24, 25; 900; 1200) obtaining accessibility information from the multi-domain coordination node (10, 1 1 , 12; 700; 1200), the accessibility information being determined depending on the availability information and the administrative information provided to the multi-domain coordination node (10, 1 1 , 12; 700; 1200) and indicating, for each of the network resources (31 , 32, 33, 34, 35) of the domain, to which customer the network resource (31 , 32, 33, 34, 35) is accessible.

17. The method according to claim 16, wherein the accessibility information is determined depending on service level information defined for each customer.

18. The method according to claim 16 or 17,

19. The method according to claim 18,

20. The method according to any one of claims 16 to 19,

wherein the accessibility information indicates whether the network resource (31 , 32, 33, 34, 35) is dedicated to one of the operator entities.

21 . The method according to any one of claims 14 to 20,

22. A method of managing network infrastructure shared by different customers, the method comprising:

- a customer-domain node (41 , 42, 43; 1 100; 1200), associated with one of the different customers, controlling network resources (31 , 32, 33, 34, 35) by interaction with at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200) associated with multiple network resource domains; and

- for each of the network resources (31 , 32, 33, 34, 35), the node customer-domain node (41 , 42, 43; 1 100; 1200) obtaining, from the at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200), accessibility information indicating to which customer the network resource (31 , 32, 33, 34, 35) is accessible.

23. The method according to claim 22, comprising:

wherein the accessibility information is determined depending on interaction of the customer- domain node (41 , 42, 43; 1 100; 1200) with the at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200).

24. The method according to claim 22 or 23, wherein said controlling utilization of at least one of the network resources (31 , 32, 33, 34, 35) by at least one of the customers comprises negotiation of resource utilization with the at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200).

25. The method according to any one of claims 22 to 24,

wherein the accessibility information is determined depending on service level information defined for each customer.

26. The method according to any one of claims 22 to 27,

27. The method according to claim 26,

28. The method according to any one of claims 22 to 27,

29. The method according to any one of claims 22 to 28,

30. A multi-domain coordination node (10, 1 1 , 12; 700; 1200), the multi-domain coordination node (10, 1 1 , 12; 700; 1200) being configured to:

- control network resources (31 , 32, 33, 34, 35) of the multiple network resource domains by interaction with control nodes (21 , 22, 23, 24, 25; 900; 1200) of the network resource domains;

- for each of the network resources (31 , 32, 33, 34, 35), obtain availability information from the control nodes (21 , 22, 23, 24, 25; 900; 1200), the availability information indicating whether the network resource (31 , 32, 33, 34, 35) is available;

- for each of the network resources (31 , 32, 33, 34, 35), determine accessibility information indicating to which customer the network resource (31 , 32, 33, 34, 35) is accessible; and - depending on the availability information and the accessibility information, control utilization of at least one of the network resources (31 , 32, 33, 34, 35) by at least one of the customers. 2. The method according to claim 2, comprising: the multi-domain coordination node (10, 1 1 , 12; 700; 1200) filtering the network resources (31 , 32, 33, 34, 35) depending on the accessibility information and the availability information.

31 . The multi-domain coordination node (10, 1 1 , 12; 700; 1200) according to claim 30, wherein the multi-domain coordination node (10, 1 1 , 12; 700; 1200) is configured to perform the steps of a method according to any one of claims 1 to 13.

32. A control node (21 , 22, 23, 24, 25; 900; 1200), the control node (21 , 22, 23, 24, 25; 900; 1200) being configured to:

- control network resources (31 , 32, 33, 34, 35) of a domain by interaction with a multi- domain coordination node (10, 1 1 , 12; 700; 1200) associated with multiple domains of network resources (31 , 32, 33, 34, 35);

- for each of the network resources (31 , 32, 33, 34, 35) of the domain, provide availability information to the multi-domain coordination node (10, 1 1 , 12; 700; 1200), the availability information indicating whether the network resource (31 , 32, 33, 34, 35) is available; and

- for each of the network resources (31 , 32, 33, 34, 35) of the domain, provide administrative information to the multi-domain coordination node (10, 1 1 , 12; 700; 1200), the administrative information enabling distinguishing between at least two subgroups of the network resources (31 , 32, 33, 34, 35) in terms of accessibility by the customers.

33. The control node (21 , 22, 23, 24, 25; 900; 1200) according to claim 32,

wherein the multi-domain coordination node (10, 1 1 , 12; 700; 1200) is configured to perform the steps of a method according to any one of claims 14 to 21 .

34. A customer-domain node (41 , 42, 43; 1 100; 1200) for association with one of different customers sharing network infrastructure, the a customer-domain node (41 , 42, 43; 1 100; 1200) being configured to:

- control network resources (31 , 32, 33, 34, 35) by interaction with at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200) associated with multiple network resource domains; and

- for each of the network resources (31 , 32, 33, 34, 35), obtain accessibility information from the at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200), the accessibility information indicating to which customer the network resource (31 , 32, 33, 34, 35) is accessible.

35. The customer-domain node (41 , 42, 43; 1 100; 1200) according to claim 34, wherein the customer-domain node (41 , 42, 43; 1 100; 1200) is configured to perform the steps of a method according to any one of claims 22 to 29.

36. A system for managing network infrastructure, the system comprising:

at least one multi-domain coordination node (10, 1 1 , 12; 700; 1200) associated with multiple network resource domains (10, 1 1 , 12; 700; 1200);

a plurality of control nodes (21 , 22, 23, 24, 25; 900; 1200) of the network resource domains; and

a plurality of customer-domain nodes (41 , 42, 43; 1 100; 1200), each associated with one of multiple customers sharing the network infrastructure;

wherein the multi-domain coordination node (10, 1 1 , 12; 700; 1200) is configured to:

- control network resources (31 , 32, 33, 34, 35) of the multiple network resource domains by interaction with the control nodes (21 , 22, 23, 24, 25; 900; 1200) of the network resource domains;

- for each of the network resources (31 , 32, 33, 34, 35), determine accessibility information indicating to which customer the network resource (31 , 32, 33, 34, 35) is accessible; and - depending on the availability information and the accessibility information, control utilization of at least one of the network resources (31 , 32, 33, 34, 35) by at least one of the customers.

37. The system according to claim 36,

wherein the multi-domain coordination node (10, 1 1 , 12; 700; 1200) is configured to perform the steps of a method according to any one of claims 1 to 13.

38. The system according to claim 36 or 37,

wherein each of the control nodes (21 , 22, 23, 24, 25; 900; 1200) is configured to perform the steps of a method according to any one of claims 14 to 21.

39. The system according to any one of claims 74 to 76,

wherein each of the customer-domain nodes (41 , 42, 43; 1 100; 1200) is configured to perform the steps of a method according to any one of claims 22 to 29.

40. A computer program comprising program code to be executed by at least one processor (1250) of a network control node (10, 1 1 , 12, 21 , 22, 23, 24, 25, 41 , 42, 43; 700; 900; 1 100; 1200), wherein execution of the program code causes the network node (10, 1 1 , 12, 21 , 22, 23, 24, 25, 41 , 42, 43; 700; 900; 1 100; 1200) to perform steps of a method according to any one of claims 1 to 35.