Service federation infrastructure and associated process.

Abstract

Service federation infrastructure and associated process. This infrastructure (100), which federates resources shared by partners (MNP1, MNP2, MNP3) operating different local infrastructures, comprises, within each local infrastructure, a local entity (10, 20, 30) to control the local resources and a central entity (40). The central entity maintains a catalog of shared resources and a commitment for each shared resource; calculates a task execution plan; and deploys a configuration corresponding to the plan. Each local entity maintains a catalog of local resources and a commitment for each shared local resource; informs the central entity of a commitment that can be made on each shared local resource; and configures each shared local resource according to the configuration received from the central entity. Figure for the abstract: Figure 1

Description

Title of the invention: Service federation infrastructure and associated method.

[0001] The present invention relates to computer infrastructures and methods for federating services.

[0002] The federation of services makes it possible to group together services shared by the different partners of a coalition with a view to carrying out a common mission.

[0003] A service is the set of resources, hardware and software, implemented and properly configured to offer all or part of a particular functionality.

[0004] This is for example a transit service (communication network, securing exchanges, ...) or an application service (execution of an application instance, database, hosting in a data center, ...).

[0005] A resource is a means, hardware or software, which, once properly configured, enables the performance of an elementary task involved in the realization of a service.

[0006] A mission falls under a particular type of purpose, such as for example an office mission, a radar observation mission, a medical assistance mission, etc.

[0007] A mission is a set of services enabling each user to obtain an expected outcome.

[0008] Thus, for example, a medical assistance mission consists of providing a user – a surgeon – with a preliminary radiological analysis of a patient. The mission then includes, for example, an image acquisition application service implementing a suitable radiology device, a transit service based on a communication network, and an image analysis application service executing an advanced algorithm for analyzing the images received from the radiology device via the communication network.

[0009] In a coalition of partners, each partner - MNP (“Mission Network Participant”), which may belong to different countries or different institutions of the same country, makes available to the coalition a part of its services and underlying resources to ensure this service.

[0010] An MNP can share transit services for data routing (typically a national communications network) and / or application services for data generation (typically the execution of an application hosted in a data center).

[0011] The various services that are shared between the MNPs of a coalition constitute a federation of services.

[0012] Currently, for the execution of a mission using the services of a federation of services, or "joint" mission, an upstream phase of planning the joint mission is carried out.

[0013] The planning, which is carried out by an operator, consists of defining a service federation configuration. A configuration defines which services, from among all the services shared by the different MNPs, are selected and reserved for the effective execution of the common mission. This configuration relates both to the resources shared by each MNP and to the parameterization of these resources to meet the expectations of each user in accordance with the common mission.

[0014] The expected outcome is understood according to a plurality of constraints, not only in terms of quality of service, but also in terms of priority of flows, criticality of flows, etc.

[0015] A configuration therefore implies the definition of a set of parameters such as the IP address of a target machine running an instance of an application required by the user, an encryption key to secure exchanges, bandwidth and latency to satisfy a required quality of service, the type of data exchanged,...

[0016] The operator in charge of planning determines an initial configuration to carry out the joint mission, taking into account the services that each MNP indicates it can share.

[0017] Each MNP is then queried to find out if it can actually allocate the service it has shared, i.e. all the resources underlying this service, with the settings provided by the initial configuration.

[0018] If not, the planning operator looks for another MNP that can provide the required service, or failing that, modifies the initial configuration to seek to obtain the necessary services from MNPs.

[0019] If so, the MNP undertakes to provide the required service for the entire duration of the mission execution phase, i.e. to reserve the various underlying resources configured in accordance with the validated configuration settings.

[0020] Planning therefore requires a series of exchanges between the planning operator and the coalition partners in order to arrive at a final configuration.

[0021] It is a long process, which is essentially carried out manually.

[0022] Furthermore, a planning operator in charge of a common task is not aware of any other planning operators in charge of other common missions, and who may also wish to use some of the shared services, including transit services.

[0023] There may therefore be conflict between several configurations developed at the same time by different planning operators.

[0024] Furthermore, the final configuration, deployed on the service federation, is fixed. It does not allow any modification during the implementation phase of the joint mission.

[0025] In other words, any event affecting a MNP during the joint mission implementation phase and resulting in the fact that this MNP can no longer offer a resource according to the commitment initially made, requires an immediate new iteration of the planning phase.

[0026] Indeed, if, for example, an MNP can no longer offer an incoming resource in a transit service of the common mission, thereby degrading the bandwidth so that it no longer meets the initial commitment of the MNP, the congestion that this causes can affect the application services associated with the common mission, which are offered by the same MNP or by another MNP (a transit network going from 100% to 50% of bandwidth can no longer meet the needs of the application services, which nevertheless continue to try to use the transit service as if nothing had happened).

[0027] Users then no longer have access to the expected services until a new schedule has been deployed.

[0028] This therefore does not address operational constraints in any way, particularly in the case of MNPs subject to stringent and constantly evolving constraints. An MNP may consequently be forced to break its initial commitment to provide certain resources and / or a specific configuration of those resources.

[0029] The aim of the present invention is to solve this problem, by proposing an infrastructure and methods adapted to achieve a dynamic configuration of a federation of services for the purpose of carrying out a common mission.

[0030] To this end, the invention relates to a service federation infrastructure comprising resources shared by a plurality of partners forming a coalition, each partner operating a local infrastructure comprising a plurality of local resources, a partner deciding to share, at any given time, some of said local resources with the other partners so as to form the service federation infrastructure, each local infrastructure comprising a local entity adapted to control the state of each local resource, the service federation infrastructure further comprising a central entity, which is in communication with each of the local entities of the local infrastructures, the central entity being adapted to: maintain an up-to-date catalog of the resources shared at the current time by each partner, a commitment of each shared resource,and a current state of each shared resource by exchanging with the , local entities; calculate a current schedule, based on the content of the shared resource catalog, enabling the execution of a predefined common mission based on the shared resources at the current time and the current state of the shared resources; and, deploy a configuration corresponding to the current schedule by requesting, for each shared resource included in the current configuration, the local entity responsible for said shared resource to configure said shared resource according to the configuration, each local entity being adapted to: maintain an up-to-date catalog of local resources, shared and non-shared, at the current time, a commitment for each shared local resource, and a current state for each local resource; inform the central entity of a commitment that can be made on each shared local resource; and, configure each shared local resource in accordance with the configuration received from the central entity.

[0031] In particular embodiments, the infrastructure comprises one or more of the following characteristics, taken individually or in all technically possible combinations:

[0032] - a service is the set of resources, hardware and software, put into work and properly configured to offer all or part of a particular functionality, a service being either a transit service or an application service.

[0033] - the central entity and each local entity is a management-type computer system and service control, supported by a resource catalogue.

[0034] - a shared resource commitment is a service level agreement characterized by at least one quantitative quantity.

[0035] - said at least one quantitative quantity is selected from: a capacity minimum and maximum bandwidth capacity, quality of service, latency, criticality, security, prioritization, computing capacity, and memory capacity.

[0036] - the central entity calculates a current schedule by executing an algorithm of the type of constrained traffic engineering algorithm.

[0037] - the algorithm takes as input at least one candidate service topology and a A set of data flows to be routed between a source service and a destination service.

[0038] - the algorithm also takes as input a parameter defining a number of alternative paths to consider on the candidate service topology when searching for a routing solution for each flow.

[0039] - the common mission defines, for each user of the infrastructure of federation of services, an expected outcome.

[0040] - the current planning includes a service topology and for each flow a global commitment.

[0041] - each local entity comprises an interface element and a control element, the control element being in charge of orchestrating the local resources of the partner and the interface element controlling the control element and exchanging with the central entity and possibly with the local entities of the other partners.

[0042] The invention also relates to a method for deploying a common configuration in a service federation infrastructure conforming to the previous infrastructure, the method comprising the steps of: the central entity queries each local entity, requesting it to transmit all the resources that can be made available to the service federation; in response, each partner's local entity indicates all the resources it is willing to share, and for each shared resource, a maximum possible commitment; the central entity stores the information received in its catalog; the central entity calculates a schedule enabling the common mission to be fulfilled; the central entity asks each partner's local entity if it can deploy the configuration corresponding to the calculated schedule;If the local entity can effectively commit to reserving the local resource according to the required commitment, then the local entity responds positively to the central entity; if the local entity cannot commit to reserving the local resource according to the required commitment, the local entity responds negatively to the central entity, while indicating a new maximum commitment; in case of a negative response, the central entity reiterates and updates the plan based on the new maximum commitment; once the central entity has received a positive response from each of the local entities, the central entity directs each local entity to deploy the configuration corresponding to the final plan and asks them to provide all the information enabling the connection to the local resources once configured, while also providing the connection information to each of the other resources provided by the other partners;and, the local entity implements each shared local resource according to the configuration received from the central entity and returns the requested connection information.

[0043] The invention and its advantages will be better understood upon reading the following detailed description of a particular embodiment, given solely by way of non-limiting example, this description being made with reference to the accompanying drawings in which:

[0044] [Fig. 1] The [Fig. 1] is a schematic and general representation of an infrastructure federation of services;

[0045] [Fig.2] Fig.2 is a schematic representation of a first method of communication between the central entity and the local entity of the infrastructure of [Fig. 1]; and,

[0046] [Fig.3] The [Fig.3] is a schematic representation of a second communication method between the central entity and the local entity of the infrastructure of the [Fig.1].

[0047] Generalities

[0048] The invention relates to a service federation infrastructure comprising a central entity and a plurality of local entities, each of these local entities being associated with one of the coalition's MNPs.

[0049] An entity is, for example, a computer comprising computing means, such as a processor, storage means, such as memory, and communication means, such as an IP card. The memory stores, in particular, the instructions of computer programs, especially programs whose execution enables the implementation of the methods according to the invention.

[0050] The central entity is responsible for planning the joint mission. It has an overall view of the shared resources. It reacts dynamically to take into account, during the execution phase of the joint mission, any change in commitment relating to a resource shared by a MNP. Based on this information, the central entity dynamically adapts the current configuration and orders the corresponding redeployment, informing the local entities of each MNP.

[0051] Each local entity has a local view of all the resources (shared or not) of the associated MNP. It informs the central entity of changes in commitments and new commitments that this MNP may make on the shared resources. Upon receiving a configuration, it orders the MNP's resources accordingly.

[0052] Advantageously, the central entity calculates not only a primary configuration, but also alternative or fallback configurations based on possible evolution scenarios of the MNPs' commitments. In this way, if one or more MNPs withdraw from all or part of the shared resources, the central entity is able to quickly propose new configurations.

[0053] Thus, with the invention, we move from a static management of a federation of services to a dynamic, slow-loop management.

[0054] With such dynamic planning, it is possible to reconfigure all the resources of the service federation to ensure the continuity of the achievement of the common mission or the evolution of this mission over time.

[0055] The invention relates to the communication methods between central entity and local entities for exchanging the different commitments and changes of commitment of the MNPs on the one hand and for configuration and reconfiguration on the other hand to allow this dynamic planning.

[0056] Fig. 1 represents a 100 service federation infrastructure.

[0057] The infrastructure 100 comprises a central entity 40, a plurality of local entities 10, 20 and 30, and, for each partner – MNP of the coalition – a plurality of shared resources from among all the resources managed by that MNP. In [Fig. 1], only the shared resources are shown.

[0058] The central entity 40 is designated CSE (“Central SMC Operations Element”). It is a service management and control system - SMC (“Service Management & Control”), more specifically a business support system - BSS (“Business Support Systems”) / operational support system - OSS (“Operational Support System”) including service orchestration.

[0059] The central entity 40 includes, in particular, a catalog database listing all the resources shared at the current time by each MNP, as well as the current commitments on each of these resources. This inventory allows the CSE 40 to estimate in real time the operational requirements (bandwidth, CPU load, memory usage, etc.) needed.

[0060] The central entity 40 is adapted to dynamically plan the configuration of the service federation infrastructure 100, i.e. the parameterization of each shared resource that each of the MNPs must put in place to meet the common mission, the management of which has been assigned to the central entity 40.

[0061] In the embodiment of [Fig.1], the partner coalition brings together three partners, respectively MNPb MNP2 and MNP3.

[0062] Each MNP manages a local infrastructure comprising a plurality of local resources that can be configured. A local resource is a local hardware or software means that can be placed in a particular state, that is to say, configured in a certain way, for the performance of a task contributing to the provision of a service.

[0063] The MNPi shares some of its local resources with the coalition. The shared resources 110 are for example: transit resources, namely a network 111, of the type communication network for operations - RCO or of the type protected core segment - PCS (“Protected Core Segment”), and two gateways of type E, 112 and 113.

[0064] The MNP2 makes available to the coalition a fraction of its resources. The shared resources 120 are for example: transit resources, namely a first network 121 with two gateways E, 122 and 123, and a second network 124 with three gateways E, 125, 126 and 127; and application resources, namely a data center 128 equipped with an encryption function 1281 and a gateway P 1282 and a theater network 129 equipped with an encryption function 1291.

[0065] The MNP3 makes a fraction of its resources available to the coalition. The shared resources 130 are, for example: transit resources, namely a networks 131 with three gateways E, 132, 133 and 134; and application resources, namely:

[0066] - a first data center 135 equipped with a gateway E 1353, a gateway P 1352 associated with an encryption function 1351 on the one hand and a gateway P 1354 on the other hand;

[0067] - a second data center 136 equipped with a P gateway 1363 associated with a cipher function 1362; and,

[0068] - a theatre network 137 equipped with an encryption function 1371 and a gateway P 1371.

[0069] A gateway is an entry point on a network. An E-type gateway ("E node") can see several E-type or P-type gateways, but a P-type gateway ("P-Node") can only see an E-type gateway.

[0070] Data transfer takes place either along an internal link within a transit network, between two gateways of that transit network, or along an external link to a transit network, between a gateway of that transit network and a gateway of either another transit network, a theater network, or a data center.

[0071] Each local infrastructure managed by an MNP is further equipped with a local entity. Thus, in [Fig. 1], the local entity of the first MNP1 is referenced 10, the local entity of the second MNP2 is referenced 20, and the local entity of the third MNP3 is referenced 30.

[0072] Each local entity comprises an interface element and a control element.

[0073] The control element – ​​NMCD (“Network Management Cyber ​​Defense”) – is responsible for orchestrating the local resources of the MNP, that is, for configuring each local resource (shared or not) according to the configuration information it receives. [TO BE VERIFIED: What is the function of this component? Who manages the configuration of non-shared resources?]

[0074] The interface element - SSE (“Subordinate SMCOPS Element”) is also a service management and control system - SMC (“Service Management & Control”), more particularly of the type Business Support Systems - BSS (“Business Support Systems”) / Operational Support System - OSS (“Operational Support System”) including a service orchestration.

[0075] The SSE communicates on the one hand with the NMCD control element of the local entity, and on the other hand with the external entities which are the SSEs of the other local entities of the other MNPs and the central entity 40.

[0076] The SSE controls the NMCD element in charge of orchestrating the local infrastructure.

[0077] Each SSE includes a catalogue database, listing all local resources, shared or not, as well as current commitments on each of these shared resources, and the settings of each of these resources. This inventory allows the SSE to estimate in real time the operational needs (bandwidth, CPU load, memory usage, etc.) required.

[0078] The SSE and possibly the NMCD of an MNP are the only points of entry to the MNP's local infrastructure for external entities. Neither an SSE nor an NMCD allows any external entity to take control of a local resource within the local infrastructure it manages. In other words, each MNP remains sovereign in its control of or interactions with other MNPs and the central entity – CSE.

[0079] The service federation infrastructure 100 is thus constituted, at the current moment, of the means shared by each MNP, the local entity of each MNP and the central entity - CSE 40 for planning the joint mission.

[0080] Generally speaking, a service level agreement (SLA) is a commitment that defines a service between a provider and a customer. Such an agreement defines the level of service that the customer wishes to obtain from the provider of a resource.

[0081] Such an agreement is characterized by one or more quantitative quantities including: the minimum and maximum bandwidth capacity in each direction, the quality of service, the latency, etc.

[0082] In what follows, to simplify the description of a particular embodiment, we essentially consider SLAs on each of the communication links between pairs of P or E type gateways. Typically, such an SLA corresponds to a percentage of the bandwidth on an internal or external link between two gateways.

[0083] A MNP participates in the joint mission(s) of the coalition of partners in addition to its own mission(s), such as a national mission to provide mobile network coverage in the territory of a country.

[0084] A local entity of a Multi-Partner Network (MPN) manages and controls local resources for the MPN's own mission to users of the local infrastructure, but only controls local resources for the coalition's common mission to users of the service federation infrastructure, as instructed by the central entity. Therefore, the local entity delegates the management of shared resources to the central entity. The local entity then acts as an interface for deploying the configuration of the shared resources for which it is responsible.

[0085] For continuity of service, the SSE must provide a rapid response in the event of a crisis. In particular, the SSE applies predefined rules.

[0086] For example, before an event affecting the capacity of the transit network, 80% of the capacity was allocated to the network's own mission and 20% to the shared mission. After the occurrence of an event leading to degradation, the total capacity is reduced by half. The SSE decides to prioritize the network's own mission at the expense of the shared mission. common (100% of the remaining capacity is offered to the own mission and 0% to the joint mission).

[0087] For a transit resource, the SSE of a local entity exposes to the CSE only the information necessary to guarantee the exchange of data crossing the network managed and shared by the local entity of the local infrastructure.

[0088] Fig. 2 illustrates a method 500 for mounting a service S implemented in the infrastructure of Fig. 1.

[0089] A joint mission is assigned to CSE 40.

[0090] It includes in particular a list of users and, for each user, an expected service, with an expected SLA.

[0091] For the execution of a joint mission, it is first necessary to identify all the resources shared by the MNPs of the coalition at the current time.

[0092] To this end, in a first step 510, the CSE 40 successively questions each local entity, asking it to transmit all the resources that can be made available to the federation of services.

[0093] In a step 520, in response to this initial request from CSE 40, the SSE of an MNP, for example that of MNPb, responds by indicating the set of resources that it is willing to share, and for each shared resource, a maximum SLA.

[0094] The CSE 40 stores the information received in its catalogue database.

[0095] In a planning step 525, the CSE 40 calculates a configuration enabling the common mission to be fulfilled.

[0096] To do this, the CSE 40 reads its catalogue database and develops at least one service topology from all the resources shared by the MNPs of the coalition, and the maximum SLAs for each shared resource.

[0097] On this service topology, the CSE 40 calculates paths to offer each user the service that this user expects in accordance with the expected SLA.

[0098] A path brings together different shared resources, in particular at least one transit resource and one application resource. For each resource S in the path, a required SLA is calculated.

[0099] Then, CSE 40 commands the SSEs to deploy this configuration. Thus, in step 530, CSE 40 requests the SSE of the MNPi that shared resource S to configure this resource S with the required SLA.

[0100] If the SSE can indeed commit to providing the requested service S with the required SLA value, then in step 540, the SSE responds positively to the CSE. The MNP thus commits to providing the service S with the required SLA.

[0101] If, on the other hand, the SSE cannot commit to providing service S with the required SLA value, then in step 550, the SSE responds negatively to the CSE, while indicating the new maximum SLA value that it can actually offer for the S service.

[0102] This occurs for example when, between step 520 and the final request of step 530, the service S, which was also offered for sharing for the performance of another joint mission, has been reserved (partially or totally) by the CSE managing this other joint mission.

[0103] Following a negative response and a new maximum SLA value for service S, CSE 40 reiterates, in step 555, the calculations of step 525. It possibly updates the service topology and determines whether the paths already calculated still allow the mission to be carried out in view of this new maximum SLA value for service S.

[0104] In step 560, once the CSE has received a commitment from each of the SSEs for all the resources in a path, the CSE requests the SSEs to configure the resources with the negotiated SLA.

[0105] In addition, the CSE asks each SSE to provide it with all the information enabling connection to the resource S once configured, while also providing it with the connection information to each of the other resources provided by these other MNPs.

[0106] In step 565, the SSE of an MNP turns to the NMCD of the local entity to implement the resource S in accordance with the negotiated SLA value. After implementation, the NMCD returns the parameters of the resource S to the SSE.

[0107] In step 570, the SSE responds to the CSE by indicating the parameters necessary for the use of resource S within the framework of the joint mission.

[0108] Fig. 3 illustrates a method for updating a service during the execution of the mission.

[0109] In step 610, the MNPi SSE informs the CSE 40 that it can no longer guarantee the commitment on a resource associated with service S, but has the possibility of sharing this resource in degraded mode, i.e. with an SLA value lower than that initially negotiated.

[0110] Then, in step 620, CSE 40 asks for the reasons for this change if they are available, and the new maximum SLA at which the resource can be accessed.

[0111] In step 630, the MNP's SSE responds by indicating at least the maximum SLA that it can actually offer (this SLA may possibly be zero if the resource is no longer accessible at all).

[0112] In step 640, if this degraded SLA value is acceptable, the CSE 40 responds to the SSE by indicating that it should continue its commitment to the service S with the new SLA value for the resource in degraded mode.

[0113] In step 645, the SSE contacts the local entity's NMCD to reserve the resource in accordance with the new negotiated SLA value. After adjusting the settings, the NMCD returns the new resource settings to the SSE.

[0114] Conversely, if this degraded SLA value is insufficient, in step 650, CSE 40 responds that the resource can no longer be used for service S of the joint mission. Consequently, the MNP SSE withdraws its commitment on this resource.

[0115] CSE 40 requests in step 660 to be informed of any future change in the resource situation (possible return to normal and / or to a higher maximum SLA value).

[0116] Steps 525 to 565 are then executed again by the CSE to identify a new configuration.

[0117] Mission planning step 525 will now be detailed.

[0118] It is implemented by the central entity - CSE 40 which uses the information received from the SSEs of the MNPs stored in the catalogue database.

[0119] Based on this information, the CSE 40 is adapted to construct a candidate service topology by establishing possible links between nodes. Two candidate topologies differ from each other by the links established between the nodes.

[0120] The CSE 40 is adapted to search for paths on a candidate topology.

[0121] A path is both a route through the candidate topology being examined for the The flow of data between a source node and a destination node is defined, along with a global SLA associated with that route. A path is selected when the associated global SLA level guarantees a level predefined by the shared mission.

[0122] The CSE 40 thus calculates a set of paths to satisfy all user expectations.

[0123] All of these paths together allow us to define the configuration in which the service federation must be placed for the completion of the mission.

[0124] Several alternative configurations (mission plan A, B or C) are advantageously calculated.

[0125] The main configuration (plan A) is deployed. To do this, the central entity -CSE 40 informs each local entity - SSE to take all the necessary steps to implement, in the service federation infrastructure, the paths identified on the service topology to carry out the common mission.

[0126] During the mission, in the event of capability losses, the SSE locally makes a change of SLA (in accordance with the governance rules to which it is subject).

[0127] For example, there may be a cyberattack, resulting in a loss of capacity. The local entity in charge of the transit network will then perform a series of actions to ensure the local survival of the services (shared or not) for which it is responsible.

[0128] In a second step, it informs CSE 40 of the changes that have affected the services that it shares with the other partners of the coalition.

[0129] It is the CSE 40 in charge of the mission which sees how to negotiate these changes with all partners in order to respond dynamically to this evolution so as to guarantee the achievement of the mission.

[0130] In particular, to respond without delay to an event, the CSE 40 may decide to deploy without delay a secondary configuration (plan B or plan C) previously calculated.

[0131] In this way, it is possible to redefine the roles and expectations associated with a mission in progress by responding to the urgency.

[0132] This mechanism of first reconfiguring the local infrastructure to take account of the event and then reconfiguring the service federation infrastructure corresponds to the slow loop nation.

[0133] More specifically, CSE 40 executes an algorithm that constructs at least one candidate service topology. Preferably, it constructs several.

[0134] A candidate service topology is a graph consisting of nodes and links. A link connects two nodes.

[0135] Each node represents a shared resource (application or transit) of the service federation at the current time considered.

[0136] A link establishes a relationship between two nodes, that is to say an association between two shared resources.

[0137] Algorithms that can be used to solve such a planning problem are of the constrained traffic engineering type. Examples include integer linear programming (ILP) algorithms, such as the Q-Bate algorithm, which is well known to those skilled in the art.

[0138] In the transit resource example, the algorithm takes three input parameters: • A graph G(N,L) representing the network, where N represents the nodes (in this case, gateways E and P) and L the links (in this case, connecting two gateways). Each link L is associated with a vector of dimension m, pj / , representing the SLAs that this link can guarantee. These SLAs can be additive or concave metrics. They will be handled differently by the algorithm. In the case where a multiplicative metric is considered, it can be transformed into an additive metric without loss of generality. • A set of flows to be routed F where each flow is represented by a triplet s, d and q, s representing the source node of the flow, d, the destination node of the flow, and q a vector of dimension m representing the constraints in terms of SLAs that this flow requires. • An internal parameter K defines the number of alternative paths to consider when searching for a solution for each flow. The exact solution to this optimization problem is guaranteed if K is equal to the dimension of the problem.

[0139] This algorithm returns the calculated paths for each of the flows.

[0140] The algorithm outputs one or more mission plans.

[0141] It is possible to prioritize certain flows, referred to as priority flows, from among all the flows of the common mission. By indicating this prioritization to the algorithm, a sorting based on priority can be performed so that the priority flows are processed first, thus reducing the chance of rejection because they are placed on the service federation first.

[0142] It is possible that the algorithm may not find a solution to route a stream. It then notifies this as a return value.

[0143] The input parameters and / or certain constraints on the flows are then modified, before iterating the execution of the algorithm to try to find an acceptable path for each flow.

[0144] For example, if a confidence level constraint prevents resolution, the SMC may choose to plan additional security measures (e.g., deployment of an IPSec tunnel with enhanced encryption) to relax the confidence constraint.

[0145] SLAs can represent concave metrics (e.g. bandwidth, level of trust between partners) or additive metrics (latency, jitter...).

[0146] Part of the graph is already given by the different PCSs constituted (namely the set of internal links allowing the gateways to be connected), which correspond to resources deployed and shared by the coalition partners.

[0147] To complete the graph with external links in order to take into account all possible plannable federated networks, dummy links are added which are the possible links between the different PCS.

[0148] Each of these fictitious links also carries a notion of SLA defined according to the means of transmission and the partners involved in this external link.

[0149] Once this graph has been constructed, the application of the algorithm makes it possible to calculate a set of possible paths to accomplish the common mission.

[0150] If dummy links have not been used by the algorithm, these links are considered redundant and are eliminated from the set of dummy links.

[0151] The output values ​​of the algorithm and the final graph (cleaned of unused dummy links) constitute a possible plan for the joint mission.

[0152] During pathfinding, the algorithm calculates alternative paths (their number is controlled by the parameter K) for all flows. These alternative paths can be stored in memory to quickly provide alternative planning in case of topology changes (e.g., link loss or modification of a link's SLA).

[0153] If the alternative plans are not sufficient to respond to a change in topology, the algorithm must be restarted to find a new plan, at least for the flows affected by the change in topology.

[0154] To reduce the number of dummy links, it is possible to introduce them iteratively until the maximum number of streams can be placed, at the cost of increased computation time. Alternatively, after an initial calculation with all the links, it is possible to prune the dummy links (e.g., links carrying few streams) to try to reduce the number of dummy links required (this optimization can be useful if a node is limited in terms of the number of possible links).

[0155] The algorithm takes, for example, the following as input:

[0156] - The expected SLAs between different P-type gateways (SLA constraints and connectivity constraint);

[0157] - The list of type E gateways on which type P gateways are connected (service topology for adjacency matrix);

[0158] - The SLAs offered by a transit network between two edge gateways (service topology for adjacency matrix);

[0159] - The possible links between different Type E gateways with the associated SLAs (e.g., Inmarsat link, LAN...) (service topology for adjacency matrix)

[0160] - The maximum number of connectors of a type E gateway (constraints).

[0161] The algorithm outputs, for example:

[0162] - The paths p that respect the SLAs indicated at the input;

[0163] - External links to be used to comply with SLAs (links between gateways of type E or P).

[0164] The connectivity (external links) between the different nodes can advantageously be expressed in the form of Boolean decision variables. These decision variables are used in an objective function, the purpose of which is to minimize the number of links to be used or a metric associated with the links.

[0165] Such an algorithm can advantageously be enhanced to provide fallback paths in case of failure of one or more external links so as to be able to react in a fast loop.

[0166] Alternatively, access to a user service can be considered. In this case, an additional constraint is added corresponding to the presence of a service on a node (in addition to a network SLA requirement). This additional constraint is met if any user can access at least one instance of the user service with a certain guarantee in terms of the network SLA.

[0167] The overall SLA value of a path is given by the list of services constituting this path p=(i,j,k,.. .,l,m) and a metric d(i,j) for each link (i,j) between two successive services of the path p:

[0168] For an additive metric (for example for latency), the SLA value of path p is given by: SLA(p) = d(i,j) + d(j,k) + ... + d(l,m).

[0169] For a multiplicative metric (for example, for the probability of transmission of a packet): SLA(p) = d(i,j) xd(j,k) x ... xd(l,m)

[0170] A multiplicative metric can be transformed into an additive metric by passing the logarithm.

[0171] For a concave metric (for example for the bandwidth of a path: SLA(p) = min[d(i,j),d(j,k),...,d(l,m)]

[0172] Thus, the central entity - CSE 40 relies on a set of SLAs to define a configuration of all the resources (hardware and software) made available to the coalition of partners.

[0173] For example, in [Fig. 1], to connect user U to an application service App, CSE 40 defines the following possible routes:

[0174] Route 1: links 1, 2, 6, 9 and 10.

[0175] Route 2: links 1, 3, 7, 9 and 10.

[0176] Route 3: links 1, 5, 7, 9 and 10.

[0177] Route 4: links 1 and 4.

[0178] He then determines a mission plan A for the mission:

[0179] A mission M is the sum of services for end users. For a Configuration A:

[0180] MA = ^Service n

[0181] M a =SLA a

[0182] SLA A= SLA route i or SLA route 2 or SLA route 2 or 2 (SLA route 1, SLA route 2, SLA route 3) or 2 (SLA route 1, SLA route 2) or 2 (SLA route 1, SLA route 3) or 2 (SLA route 2, SLA route 3) and SLA route 4

[0183] Where

[0184] SLA route k = Min; (SLA link 0

[0185] It advantageously determines a mission plan B for the mission:

[0186] MB = ^Service n

[0187] M b =SLA b

[0188] SLA B = SLA route8 or SLA routeQ or SLA route 10 or 2(SLA route 8,, SLA route 9, SLA route 10) or2(SLA route 8, SLA route 9)or 2(ALS route 8, ALS route 10) gold 2(ALS route 9, ALS route 10) and ALS Route 11

[0189] It advantageously determines a mission plan C for the mission:

[0190] M c = y11 Service n i

[0191] Mc=SLAc

[0192] SLA c = SLA route 8 or SLA route 9 or SLA route 10 or 2(SLA route 8, SLA route 9, SLA route 10) or2(SLA route 8, SLA route 9)or (ALS Route 8, ALS Route 10) gold 2 (SLA route 9, SLA route 10) and ALS Route 11

[0193] The invention thus makes it possible in the end to guarantee a set of end-to-end service SLAs for mission participants, end users and coalition MNPs.

[0194] The CSE 40 is responsible for defining all the rules for ordering, deploying and configuring all end-to-end services of one or more configurations for end users.

[0195] Variants

[0196] Advantageously, the central entity 40 can consider additional constraints such as criticality, security, prioritization, etc. These constraints are expressed in the form of SLAs.

[0197] It can also take into account quality indicators reported in particular by the NMP in charge of the last node of a path which is best placed to evaluate this path at any time and detect the occurrence of an event degrading the overall SLA of this path.

[0198] The central entity can define several global SLA values: A planning value; An actual usage value; A prediction value; Estimate values ​​to evaluate the best solution to take in case of degradations.

[0199] For example, an MNP segregates the flows circulating on its transit resources between so-called "red" data (corresponding to a high security domain) and so-called "black" data (corresponding to a low security domain).

[0200] The local entity of the MNP can then assign a high priority to the data of its national users (considering this data as "red" data) to favor them over the data of users of the service federation, which are then considered as "black" data.

[0201] The SSE of a local entity of an MNP has the ability to exchange information with the SSEs of local entities of other MNPs, not only to exchange SLA commitments of shared resources, but also alerts of failure of shared resources, service catalogs,...

[0202] The NMCD of a local entity of an MNP may also optionally share certain information with the NMCDs of local entities of other MNPs, in order to allow automatic interconnection or exchange of statuses between resources. This information is, for example, topology data.

[0203] If in the preferred embodiment presented above, the system integrates a single central entity - CSE, which is dedicated to the dynamic planning of a common or shared mission, alternatively, a central entity - CSE is responsible for the dynamic planning of several common missions, preferably of the same type (medical, radar observation, etc.).

[0204] In another variant, the system comprises several central entities, each of them dedicated to the dynamic planning of a common mission specific to it.

[0205] The CSE can manage requests for instantiation of application services. In this case, the presence or absence of an application on a node is expressed by means of a decision variable, the constraints then being the capacity of a node to host said application, in terms of computing capacity, memory capacity, etc.

[0206] Advantages

[0207] The dynamic planning mechanism according to the invention makes it possible to offer, at each moment of the execution of the joint mission, the best quality of experience to users taking into account all the possibilities offered.

[0208] The invention proposes a dynamic planning mechanism that provides slow-loop mechanisms to offer the best quality at every moment providing experience to users involved in the joint mission, while taking into account all the possibilities offered by the partners.

Claims

Demands

1. A service federation infrastructure (100) comprising resources shared by a plurality of partners (MNP1, MNP2, MNP3) forming a coalition, each partner operating a local infrastructure comprising a plurality of local resources, a partner deciding to share, at any given time, some of said local resources with the other partners so as to form the service federation infrastructure, each local infrastructure comprising a local entity (10, 20, 30) adapted to control the state of each local resource, the service federation infrastructure (100) further comprising a central entity (40), which is in communication with each of the local entities (10, 20, 30) of the local infrastructures, the central entity (40) being adapted to: - maintain an up-to-date catalog of the resources shared at the current time by each partner, a commitment of each shared resource,and a current state of each shared resource by exchanging information with the local entities (10, 20, 30); - calculate a current schedule, based on the content of the shared resource catalog, enabling the execution of a predefined common mission using the shared resources at the current time and the current state of the shared resources; and, - deploy a configuration corresponding to the current schedule by requesting, for each shared resource included in the current configuration, the local entity responsible for said shared resource to configure said shared resource according to the configuration, each local entity (10, 20, 30) being adapted to: - maintain an up-to-date catalog of local resources, shared and non-shared, at the current time, a commitment for each shared local resource, and a current state for each local resource; - inform the central entity of a commitment that can be made on each shared local resource; and,- Configure each shared local resource according to the configuration received from the central entity.

2. Infrastructure according to claim 1, wherein a service is the set of resources, hardware and software, put into work and properly configured to offer all or part of a particular functionality, a service being either a transit service or an application service.

3. Infrastructure according to claim 1 or claim 2, wherein the central entity and each local entity is a service management and control type computer system, backed by a resource catalog.

4. Infrastructure according to any one of claims 1 to 3, wherein a shared resource commitment is a service level agreement characterized by at least one quantitative magnitude.

5. Infrastructure according to claim 4, wherein said at least one quantitative quantity is selected from: a minimum capacity and a maximum bandwidth capacity, a quality of service, a latency, a criticality, a security, a prioritization, a computing capacity, and a memory capacity.

6. Infrastructure according to any one of claims 1 to 5, wherein the central entity (40) calculates a current schedule by executing an algorithm of the type constrained traffic engineering algorithm.

7. Infrastructure according to claim 6, wherein the algorithm takes as input at least one candidate service topology and a set of flows to be routed between a source service and a destination service.

8. Infrastructure according to any one of claims 6 to 7, wherein the algorithm also takes as input a parameter defining a number of alternative paths to be considered on the candidate service topology when searching for a routing solution for each flow.

9. Infrastructure according to any one of claims 1 to 8, wherein the common mission defines, for each user of the service federation infrastructure, an expectation.

10. Infrastructure according to any one of claims 1 to 9, wherein current planning groups a service topology and for each flow a global commitment.

11. Infrastructure according to any one of claims 1 to 10, wherein each local entity comprises an interface element and a control element, the control element being responsible for orchestrating the partner's local resources and the element

12. interface controlling the control element and exchanging with the central entity and possibly with the local entities of other partners. A method for deploying a common configuration in a service federation infrastructure conforming to any one of claims 1 to 11, the method comprising the steps of: - the central entity queries each local entity requesting it to transmit all the resources that can be made available to the service federation; - in response, the local entity of each partner indicates all the resources it is willing to share, and for each resource shared, a maximum possible commitment; - the central entity stores the information received in its catalogue; - the central entity calculates a plan to fulfill the common mission; - the central entity asks each local entity of each partner if it can deploy the configuration corresponding to the calculated plan; - if the local entity can actually commit to reserving the local resource according to the required commitment, then the local entity responds positively to the central entity and if the local entity cannot commit to reserving the local resource according to the required commitment, the local entity responds negatively to the central entity, while indicating a new maximum commitment; - in case of a negative response, the central entity reiterates and updates the planning based on the new maximum commitment; - once the central entity has received a positive response from each of the local entities, the central entity directs each local entity to deploy the configuration corresponding to the final plan and asks them to provide all the information enabling the connection to the local resources once configured, while also providing the connection information to each of the other resources provided by the other partners; and, - the local entity implements each shared local resource in accordance with the configuration received from the central entity and returns the requested connection information.

Images