EP4662551A1 - Procede de determination d'un groupe de serveurs - Google Patents

Procede de determination d'un groupe de serveurs

Info

Publication number
EP4662551A1
EP4662551A1 EP24702167.8A EP24702167A EP4662551A1 EP 4662551 A1 EP4662551 A1 EP 4662551A1 EP 24702167 A EP24702167 A EP 24702167A EP 4662551 A1 EP4662551 A1 EP 4662551A1
Authority
EP
European Patent Office
Prior art keywords
software component
programmable device
function
software
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24702167.8A
Other languages
German (de)
English (en)
Inventor
Bruno Chatras
Roland Picard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4662551A1 publication Critical patent/EP4662551A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0886—Fully automatic configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • the present disclosure belongs to the field of communication networks implemented from virtualized functions, that is to say from software instantiated on standardized computer servers.
  • the invention aims more precisely to allow the automatic deployment of such virtualized functions requiring hardware or software acceleration functions by identifying a zone or a cluster comprising at least one server capable of hosting a virtualized function but also at least one server capable of implementing an acceleration function.
  • NFV Network Function Virtualization
  • VNF package Virtualized Network Function
  • MANO Management and orchestration functions
  • An NFV architecture involves the use of standardized computer servers, known as “off-the-shelf” servers, to host the network functions software, as opposed to specialized equipment.
  • These servers are equipped with processors that are themselves standardized (general-purpose processor as opposed to specialized or function-dedicated processors), such as processors based on Intel’s x86 architecture.
  • processors particularly in the case of so-called multi-core configurations, make it possible to obtain high performance, this performance remains insufficient in certain cases, for example when the volume of traffic to be processed is very high and/or the latency constraints are very high.
  • the present disclosure aims to remedy all or part of the limitations of the prior art solutions, in particular those set out above, by proposing a solution which makes it possible to automatically deploy a virtualized function requiring an associated software function, for example acceleration of a flow or data, adapted to the virtualized function.
  • a method for determining a group of computer servers of a virtualized communication network said group being capable of hosting a software component contributing to the provision of a service in said network, said software component requiring the implementation of an associated software function for processing data of the service, said method being implemented in an orchestration entity and comprising:
  • a determination of said group of servers comprising at least a first server adapted to host the software component and a second server comprising said programmable device compatible with said characteristic obtained.
  • one or more parameters relating to the programmable device capable of hosting the software function in a manner correlated with the request for deployment of the software component ensures that the choice that will be made to determine a server, a zone or a cluster to host the software component will be made by taking into account, in the choice process, the availability of a server comprising the programmable device nearby or even on the same server on which the software component is installed.
  • the performance of the software component assisted for certain processing by the associated software function will be ensured and the quality of the service using the software component will be guaranteed.
  • the identifier of the software component and at least one parameter of the associated software function may advantageously be included in a descriptive document, for example of the VNFD type, comprising for example VNFC and/or VNF identifiers as well as programs or executables associated with the VNFC components and/or the VNF.
  • Obtaining the characteristic of a programmable device adapted to accommodate the associated software function can be advantageously coupled or included in a request for authorization of the deployment of the software component to be able to ensure that the software component will be deployed with a guarantee of the availability of the associated software function.
  • the method for determining a group of servers further comprises a reservation of a resource of the second server comprising said programmable device.
  • the method also makes it possible to reserve capacities, i.e. a resource of the second server on which the associated software function will be installed and thus to ensure that during the installation of the software component, the software function, or the executable of the associated software function, can actually be installed.
  • the method for determining a group of servers further comprises the deployment via a management entity of the virtualized communication network of the software function on said programmable device of the second server for which a resource has been reserved.
  • the software function can advantageously be installed or downloaded onto the programmable device determined by the orchestration entity via an entity in charge of the resources of the virtualized network, such as a VIM (Virtual Infrastructure Manager) type entity.
  • VIM Virtual Infrastructure Manager
  • the reserved resource is allocated with certainty to the software function and the software component, such as a VNF component (VNFC) can use it as soon as it is downloaded onto a server of the cluster or zone.
  • VNFC VNF component
  • the method for determining a group of servers further comprises creating a group of servers comprising at least one server adapted to host the software component and a server comprising said programmable device compatible with said characteristic.
  • the characteristic of the programmable device used to select or create a server may correspond to one or more of the following characteristics. These may thus be so-called hardware capabilities corresponding to a number of CPUs (Central Processing Units) required, a virtual memory size or a virtual disk size. It may also be a type of programmable device to be used, for example between FPGA (Field-Programmable Gate Array) and eBPF (Extended Berkeley Packet Filter). It may also be an identifier of the programmable device comprising one or more of the following data: name of the supplier of the programmable device, name of the programmable device, server supporting the programmable device, version of the programmable device, type of programmable device (hardware or software). The parameter may also comprise a download address of the software function or a pointer to a program to be loaded onto the programmable device.
  • CPUs Central Processing Units
  • eBPF Extended Berkeley Packet Filter
  • programmable devices can possibly accommodate a software function associated with a software component and the characteristic can correspond to one or more programmable devices compatible with the transmitted parameters.
  • the method thus makes it possible to select a server comprising a suitable programmable device, among the compatible devices, for a software function or for a set of software functions according to the parameters of the associated software function understood by example in the description document.
  • the software function is a function of accelerating the processing of the data of the flow.
  • the method can be advantageously implemented for a software function corresponding to a function of accelerating the processing of certain data flows, thus making it possible to relieve the software component of certain tasks which are costly in terms of resources for the virtual server hosting the software component.
  • the method for determining a group of servers further comprises transmitting to a management entity of the virtualized network a computer program of the associated software function intended to update the programmable device of the second server.
  • the invention also relates to a method for determining a programmable device capable of hosting a software function associated with a software component contributing to the provision of a service in a virtualized communication network, said programmable device being implemented in a server of the network, the method implemented in a management entity of the software component comprising:
  • a virtualized communication network may comprise, for example, one or more access networks and one or more network cores.
  • This virtualized communication network may be implemented to route communication data to fixed or mobile terminals and the network may be implemented with/by virtualized functions but non-virtualized functions may also be included in the primarily virtualized network, for example by using specific equipment for a given function.
  • This network may be used for the routing and/or processing of residential or corporate customer data.
  • the virtual functions VF1 and VF2, and more particularly the respective components C2, C3 and C5 of these virtual functions VF1 and VF2, require software functions to ensure certain processing with greater efficiency than if the components alone ensured this processing. This is particularly the case for certain components of the network functions operating directly on the data flows exchanged between the equipment of users connected to the Res network or between this user equipment and application or content servers. These network functions are generally referred to as belonging to the data plane or user plane.
  • the emblematic example in 5G network cores is the UPF (User Plane Function).
  • the components operating on the data plane possibly require software functions to improve data processing (Acc1, Acc2, Acc3 in [Fig. 1]).
  • a family of solutions consists of relieving the main processor of the server hosting the VNF of certain processing which is then transferred to an auxiliary processor, installed for example on a network card or a specialized card added to the same server (alternative not shown in [Fig 1]), or a remote server (Srv 2 for Srv1 or Srv3 for Srv4 in [Fig 1], knowing that the remote server can be accessible for example through a communication infrastructure when possible (not shown in [Fig 1]).
  • the auxiliary processors in question can be specialized or programmable, such as programmable logic circuits of the FPGA (Field-Programmable Gate Array) type.
  • FPGA Field-Programmable Gate Array
  • An example of a programming language adapted to packet processing is the P4 language (in English Programming Protocol-Independent Packet Processor).
  • P4 in English Programming Protocol-Independent Packet Processor
  • a virtualized function VF1 and VF2 and more precisely the elementary components C1, C2, ..., C6 which compose these virtualized functions VF1 and VF2 can be instantiated dynamically in the communication network Res to meet a need for a new service, to improve performance or to adapt the network to a new context. Knowing that certain virtualized functions or certain components also require an associated software function, the deployment of a new component requires taking into account the implementation of a new software function or programming a programmable device with a software function required for the new component installed.
  • zone Z1 or Z2 to deploy a new software component C2 will be made based on the possibility of being able to effectively update a programmable device with the required software function Acc1 on a server in said zone.
  • the associated software function corresponds to an executable computer program providing an acceleration function to be loaded onto a programmable device which may correspond to a programmable accelerator.
  • FIG 2 presents a schematic view of a determination method implemented in an NFV architecture (Network Function Virtualization).
  • an NFVO entity Network Function Virtualization Orchestrator
  • the OSS entity Operations Support Systems
  • the VNFM entity Virtualized Network Function Manager
  • an NFVO type entity When a new virtualized function must be deployed, for example following a request issued by the OSS entity, or when a virtualized function must be updated for example by adding a new software component, an NFVO type entity must decide on the area, for example represented by a cluster, in which the component is to be instantiated. This decision may be made based on a service, the position of another software component or even physical equipment, but in the case where the virtualized function or the software component also requires an associated software function, for example an acceleration function, then the decision takes into account the presence in the area or cluster of a programmable device hosted by a server and adapted to be programmed to implement the software function associated with the software component.
  • FIG 3 presents a diagram illustrating the main steps of a method for determining a group of servers according to a first embodiment.
  • the virtualization technique is based on virtual machines.
  • the servers as presented in the previous figures are equipped with virtual machines adapted to host software components and software functions.
  • This figure is deliberately simplified in relation to the NFV MANO architecture (Network Functions Virtualization (NFV) Management and Orchestration) for the purposes of understanding.
  • NFV MANO architecture Network Functions Virtualization (NFV) Management and Orchestration
  • VNFD file provides in particular the list of elementary components (VNFC) which constitute, according to this example, the software component and the way to connect them together. It also indicates for each elementary component the number of instances to be deployed at different stages of the life cycle of this software component.
  • VDU Virtualised Deployment Unit
  • a software component can therefore correspond to an elementary component or to a plurality of elementary components.
  • One or more of the following parameters may possibly be present in the VNFD file such as parameters linked to a software function associated with the software component, such as:
  • the programmable device will indeed be determined according to its capacity to support one or more of these executables and if several programmable devices are suitable for an executable, that is to say a software, another parameter of the software function such as for example its energy consumption, its capacity to handle high traffic or a performance ratio compared to its energy consumption may be considered to determine a characteristic of the programmable device, such as for example its energy consumption, its capacity to handle high traffic or a performance ratio compared to its energy consumption.
  • step E2 can be broken down into several sub-steps not shown.
  • the NFVO can transmit a request for deployment of a software component comprising an identifier of the required software component and the VNFM, upon receipt of this request, asks the NFVO for information relating to this software component and to the associated software function, if it does not already have this information.
  • the NFVO then transmits the information, for example in a VNFD file corresponding to the identifier, in a second step, namely after having received the request from the VNFM.
  • This alternative has the advantage of limiting the sending of this information relating to the software component and to the associated software function systematically, and therefore of increasing the traffic on the communication network.
  • the VNFM determines the resource requirements for deploying the software component and the software function associated with this software component.
  • the VNFM characterizes the programmable device adapted to host the associated software function by determining a characteristic of the programmable device compatible with the parameters of the associated software function, received in the deployment request. Determining the programmable device comprises determining characteristics based on the parameters of the software function received from the NFVO.
  • the determining method comprises determining one or more of the following characteristics:
  • the VN FM transmits to the NFVO a request for authorization to deploy the software component comprising a characteristic of a programmable device adapted to accommodate the associated software function, determined according to the parameter received.
  • This deployment request transmitted by the NFVO comprises one or more of the characteristics defined in the determination step E3. This information will allow the NFVO to effectively ensure that the deployment of the software component will be able to be carried out in an area where the software function associated with the software component will be able to be installed or is already installed. Thus, the deployment can be carried out while respecting the constraints issued in the deployment request.
  • the NFVO determines during a step E5 a zone within the communication network comprising a computer server on which the software component can be instantiated and further comprising a computer server comprising a programmable device compatible with the characteristic(s) received.
  • the zone may correspond to a cluster according to one alternative and according to another example, the two servers may correspond to the same server hosting the software component and the associated software function.
  • the associated software function may already be installed on a programmable device of a server in the zone, in which case all that remains is to instantiate the software component on a server in the same zone as this server.
  • This determination by the NFVO may also be accompanied by the identification of a VIM entity, a virtualized network management entity responsible for managing the virtualized resources of the communication network, for the instantiation of the software component and possibly the associated software function.
  • the NFVO determines an area within the communication network comprising a computer server on which the software component can be instantiated and further comprising a computer server comprising a programmable device compatible with the characteristic(s) obtained before step E2 and the request sent during step E2 is equivalent to authorization, which implies, according to this example, that step E4 where the VNFM requests authorization as described above is not required.
  • the NFVO obtains for example from a database, a characteristic of a programmable device adapted to accommodate the software function associated, determined based on a parameter of the associated software function.
  • the NFVO reserves resources on the second server for the purpose of deploying the associated software function on the programmable device. This reservation can be made with the VIM entity responsible for managing the virtualized resources of the zone comprising the server.
  • the NFVO can also reserve resources on the first server intended to host the software component.
  • the NFVO can install the associated software function on the server whose resources have been reserved during an optional step E7 not shown.
  • the NFVO sends to the VIM the computer program of the associated software function intended to update the programmable device of the second determined server.
  • the VIM can thus install the
  • the NFVO transmits to the VN FM the authorization to deploy the required software component.
  • This authorization includes information on the zone in which the server must be selected and possibly an identifier of the first server determined to host the virtualized function.
  • the identifier of the first server is not required if all the servers in the zone can host the software component knowing that the zone is selected if it also comprises a computer server comprising a programmable device adapted to host the associated software function, whether or not the latter is already installed.
  • the identity of the VIM to be requested may be transmitted to the VNFM during this step E8, in particular if the VIM was determined during step E5.
  • the VNFM requests a VIM to deploy the software component in the determined zone by specifying this zone, or even by transmitting the identifier of the first server. If no reservation has been made for the installation of the software component during step E6, the VNFM can indicate to the VIM the constraints relating to the software component and the associated software function, so that the server of the zone selected to host the software component complies with the constraints induced by the associated software function, in accordance with the characteristics determined during step E3.
  • This alternative is useful if the first server determined by the NFVO no longer has the resources necessary for instantiating the software component, which can occur in particular in the absence of a resource reservation on the first server. This alternative is also useful if the NFVO entity has not specifically determined a server but a zone comprising the required servers.
  • the VIM interacts with entities of the communication network.
  • the software component and the associated software function are deployed to create the resources, including in particular the virtual machine and the CPU and disk resources for example, necessary for the instantiation of the software component on the first server in the determined zone.
  • the software component and the associated software function may interact in a step not shown in [Fig 3].
  • the software component may transmit rules indicating which types of traffic are to be handled by the associated software function.
  • the VNFM entity or the VIM entity may transmit to the software component an identifier, such as an address, of a server comprising a programmable device updated with an associated software function relating to the software component, as well as possibly security elements allowing the software component to securely communicate the associated software function.
  • the VNFM informs the NFVO that the software component has been instantiated and that the associated software function is loaded onto the programmable device of the server, thus informing the NFVO of the availability of the software component and of an operation of this component as required in the service whose deployment was requested in the step EO, that is to say with the assistance of the associated software function.
  • FIG 4 presents a diagram illustrating the main steps of a determination method according to a second embodiment.
  • the virtualization technique is based on containers.
  • the computer servers as presented in the preceding figures are equipped with containers adapted to accommodate software components and are for example capable of hosting software functions, for example via a network card equipped with an FPGA processor.
  • This figure is deliberately simplified in relation to the NFV MANO architecture (in English Network Functions Virtualization (NFV) Management and Orchestration) for the purposes of understanding.
  • NFV MANO architecture in English Network Functions Virtualization (NFV) Management and Orchestration
  • Steps EO to E4 of [Fig 4] are comparable to those presented in [Fig 3] and are independent of the type of virtualization implemented in the communication network.
  • the NFVO determines an area within the communication network comprising a computer server on which the software component can be instantiated and further comprising a computer server comprising a programmable device compatible with the received characteristic(s) of the programmable device. More specifically, the NFVO determines a cluster, also identified as a group of servers, in which one or more physical or virtual servers of the cluster acting as CIS are equipped with a programmable device compatible with the associated software function, and that one or more physical or virtual servers acting as CISM are equipped with a programmable device management function on which to deploy the associated software function, knowing that a server in the cluster must also be suitable for instantiating the required software component.
  • a new cluster can be created.
  • This new cluster or group of servers comprises at least one server adapted to host the software component and one server adapted to comprise a programmable device which can be updated with the associated software function, in accordance with the characteristic received during step E4.
  • This creation is carried out in interaction with the VIM, CISM and CCM entities of the orchestration and management system of the virtualized infrastructure of the communication network.
  • the NFVO informs the OSS during a step E51 that no existing zone or cluster comprises the two servers required for the software component and the associated software function, this second server having to comprise a programmable device in accordance with the characteristics received during step E4.
  • a step E52 the OSS determines that a new cluster meeting the needs as determined must be created.
  • the NFVO can thus transmit the characteristics required for the new cluster in step E51.
  • the CCM creates the new cluster and informs the OSS in return, during a step E55, possibly via the NFVO.
  • This information message relating to the new cluster created also includes the characteristics of the new cluster and possibly the characteristics of two servers adapted to respectively host the software component and the associated software function.
  • steps EO to E5 may be repeated to determine the cluster in which the software component and the associated software function may be installed.
  • the CISM installs it on the second server determined according to the characteristics and the CISM possibly interacts with the VIM to create the resources necessary for the installation of the software component during step E10.
  • the CISM informs the NFVO, via the VNFM, that the software component has been instantiated on the first server of the determined cluster and that the associated software function is installed on the programmable device of the second server of the same cluster, thus informing the NFVO of the availability of the software component and of an operation of this component as required in the service whose deployment was requested in the step EO.
  • the VNFM entity or the VIM entity or the CISM entity can transmit to the software component an identifier, such as an address, of a server comprising a programmable device updated with an associated software function relating to the software component, as well as possibly security elements allowing the software component to request the associated software function.
  • a server designates both a physical server and a virtual machine, the container then being instantiated on a virtual machine.
  • the CCM interacts with the VIM to install the associated software function on the programmable device of the virtual machine on a server.
  • a transmitter 101 adapted to transmit to a management entity of the software component a request Depl for deployment of the software component, said request comprising an identifier of the software component and at least one parameter of the function associated software,
  • FIG. 6 presents a representation of a device for determining a programmable device according to an example.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne un procédé de détermination d'un groupe de serveurs (Srv1, Srv2) informatiques d'un réseau (Res) virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel (VF1, C1) contribuant à la fourniture d'un service dans ledit réseau, ledit composant logiciel requérant la mise en oeuvre d'une fonction logicielle (Acc1) associée de traitement d'une donnée du service, ledit procédé étant mis en œuvre dans une entité d'orchestration (NFVO) et comprenant une émission à destination d'une entité (NFVM) de gestion du composant logiciel d'une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel (VF1, C1) et au moins un paramètre de la fonction logicielle associée (Acc1), une obtention d'une caractéristique d'un dispositif programmable (DISP) adapté pour accueillir la fonction logicielle associée (Acc1, Acc2), déterminée en fonction de l'au moins un paramètre, une détermination dudit groupe de serveurs (Srv1, Srv2) comprenant au moins un premier serveur adapté (Srv1 ) pour accueillir le composant logiciel (VF1, 01) et un deuxième serveur (Srv2) comprenant ledit dispositif programmable (DISP) compatible avec ladite caractéristique obtenue.

Description

Description
PROCEDE DE DETERMINATION D'UN GROUPE DE SERVEURS
Domaine technique
[0001] La présente divulgation appartient au domaine des réseaux de communication mis en œuvre à partir de fonctions virtualisées, c’est-à-dire à partir de logiciels instanciés sur des serveurs informatiques banalisés. L’invention vise plus précisément à permettre le déploiement automatique de telles fonctions virtualisées requérant des fonctions d’accélération matérielle ou logicielle en identifiant une zone ou un cluster comprenant au moins un serveur apte à héberger une fonction virtualisée mais aussi au moins un serveur apte à mettre en oeuvre une fonction d’accélération.
Technique antérieure
[0002] La virtualisation des fonctions réseau (NFV signifiant en anglais Network Function Virtualisation) est devenue une tendance de fond dans l’industrie des télécommunications. Ainsi les réseaux mobiles de cinquième génération sont nativement conçus comme des ensembles de fonctions réseau virtualisées et il est admis qu’il en sera de même pour la sixième génération ainsi que pour les suivantes. Dans ce cas, les fonctions réseau sont livrées sous forme d’un fichier archive appelé « VNF package » (en anglais Virtualised Network Function) contenant en particulier les logiciels à installer ainsi qu’un ou plusieurs fichiers contenant les informations nécessaires à l’installation des logiciels dans une infrastructure NFV ainsi qu’à la gestion du cycle de vie de la fonction réseau par des fonctions dites de gestion et d’orchestration (MANO (en anglais Management and Orchestration). Selon les cas ces logiciels sont déployés dans des machines virtuelles et/ou dans des containers.
[0003] Une architecture NFV implique l’utilisation de serveurs informatiques banalisés, dits « sur étagère » pour héberger le logiciel des fonctions réseau, par opposition à des équipements spécialisés. Ces serveurs sont équipés de processeurs eux-mêmes banalisés (processeur généraliste par opposition à processeur spécialisé ou dédié à une fonction), tels que des processeurs fondés sur l’architecture x86 d’Intel. Bien que ces processeurs, en particulier dans le cas de configuration dites multicœurs, permettent d’obtenir des performances élevées, ces performances restent insuffisantes dans certains cas, par exemple lorsque le volume de trafic à traiter est très élevé et/ou les contraintes de latence sont très fortes.
[0004] C’est en particulier le cas des fonctions réseau opérant directement sur les flux de données échangés entre les équipements des utilisateurs connectés au réseau ou entre ces équipements et des serveurs d’applications ou de contenu. On désigne en général ces fonctions réseau comme appartenant au plan de données (en anglais data plane) ou plan utilisateur (en anglais user plane). L’exemple emblématique dans les cœurs de réseau 5G est la fonction UPF (en anglais User Plane Function).
[0005] Pour ce type de fonction réseau, les industriels ont recours à des solutions d’accélération logicielle ou matérielle en complément de la fonction réseau virtualisée déployée sur un serveur banalisé. Une famille de solutions, appelée « hardware offload » consiste à délester le processeur principal du serveur hébergeant la VNF de certains traitements qui sont alors déportés sur un processeur auxiliaire, installé par exemple sur une carte réseau ou une carte spécialisée ajoutée sur ce serveur, ou un équipement distant accessible à travers le réseau de l’infrastructure. Les processeurs auxiliaires en question peuvent être spécialisés ou programmables.
[0006] Les spécifications existantes ne permettent pas de déterminer comment une image logicielle à installer sur un accélérateur programmable et proposant la fonction logicielle associée, telle qu’un accélérateur, est identifiée dans un fichier descriptif VNFD (élément du VNF package décrit ci-dessus), ni comment une telle information peut être transmise et prise en compte par des gestionnaires d’une architecture virtualisée pour permettre une automatisation totale du processus d’installation d’une VNF accélérée dans une infrastructure NFV.
Résumé de l’invention
[0007] La présente divulgation a pour objectif de remédier à tout ou partie des limitations des solutions de l’art antérieur, notamment celles exposées ci-avant, en proposant une solution qui permette de pouvoir déployer de façon automatique une fonction virtualisée requérant une fonction logicielle associée, par exemple d’accélération d’un flux ou d’une donnée, adaptée à la fonction virtualisée.
[0008] A cet effet, il est proposé un procédé de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel contribuant à la fourniture d’un service dans ledit réseau, ledit composant logiciel requérant la mise en œuvre d’une fonction logicielle associée de traitement d’une donnée du service, ledit procédé étant mis en œuvre dans une entité d’orchestration et comprenant :
- une émission à destination d’une entité de gestion du composant logiciel d’une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- une obtention d’une caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée, déterminée en fonction de l’au moins un paramètre,
- une détermination dudit groupe de serveurs comprenant au moins un premier serveur adapté pour accueillir le composant logiciel et un deuxième serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique obtenue.
Le procédé de détermination permet de pouvoir s’assurer qu’un composant logiciel, tel qu’un logiciel comprenant des instructions relatives à une fonction virtualisée, puisse être déployé dans un groupe de serveurs, qui peut correspondre à une zone ou à un cluster, comprenant par ailleurs un dispositif programmable sur lequel peut être installé une fonction logicielle associée à ce composant logiciel. Dans le cas où la fonction logicielle associée assure une fonction permettant de pouvoir délester le composant logiciel de certains traitements, par exemple coûteux en termes de performance et/ou de capacités de traitement, il sera ainsi possible qu’une mise à jour du réseau de communication comprenant le déploiement d’un nouveau composant logiciel pourra être opérée en garantissant que ce composant logiciel peut effectivement bénéficier de capacités optimisées mises en œuvre par la fonction logicielle associée. La prise en compte d’un ou plusieurs paramètres relatifs au dispositif programmable apte à accueillir la fonction logicielle de façon corrélée avec la demande de déploiement du composant logiciel assure que le choix qui sera fait pour déterminer un serveur, une zone ou un cluster pour accueillir le composant logiciel sera effectué en prenant en compte, dans le processus du choix, la disponibilité d’un serveur comprenant le dispositif programmable à proximité voire sur le même serveur sur lequel est installé le composant logiciel. Ainsi, la performance du composant logiciel assisté pour certains traitements par la fonction logicielle associée sera assurée et la qualité du service utilisant le composant logiciel sera garantie. Ce procédé de détermination est donc très avantageux par rapport à l’état de la technique puisqu’un serveur, une zone ou un cluster ne sera sélectionné que si un serveur de la zone ou du cluster comprend en outre un dispositif programmable compatible avec la fonction logicielle ou plus précisément avec une ou plusieurs paramètres de la fonction logicielle.
[0009] Ce procédé permet en outre que les différents serveurs, et même les composants logiciels et fonctions logicielles, soient hétérogènes et par exemple puissent être d’origine de constructeurs distincts. En effet, les caractéristiques du dispositif programmable requis pour l’installation de la fonction logicielle sont par exemple décrites dans un document de description et n’importe quel serveur comprenant un dispositif programmable compatible avec un ou plusieurs paramètres de la fonction logicielle associée, donc compatible avec le composant logiciel, peut être sélectionné. Le procédé accentue en outre les possibilités de mises à jour du réseau virtualisé de communication, puisqu’une contrainte qui pouvait exister auparavant, à savoir avoir une garantie de disposer d’une fonction logicielle associée à un composant logiciel, est désormais résolue par le procédé de détermination. Un paramètre de la fonction logicielle associée peut par exemple correspondre à un programme écrit dans un langage spécialisé (Domain Specific Language, DSL), par exemple P4, indépendant de toute cible d’exécution, soit un ou plusieurs exécutables qui résulte de la compilation du programme vers une ou plusieurs cibles d’exécution du dispositif programmable. Le paramètre peut en outre correspondre à un identifiant de la fonction logicielle associée, ou un lien (ou pointeur) pointant sur un exécutable permettant le déploiement effectif de la fonction logicielle associée, dispensant de transmettre l’exécutable. La fonction logicielle associée pourra par exemple être présente dans le VNF package. L’identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée peuvent avantageusement être compris dans un document descriptif, par exemple de type VNFD, comprenant par exemple des identifiants de VNFC et/ou de VNF ainsi que des programmes ou des exécutables associés aux composants VNFCs et/ou à la VNF.
[0010] Plusieurs fonctions logicielles peuvent être requises pour un ou plusieurs composants logiciels. Dans ce cas, le procédé de détermination peut avantageusement comprendre des paramètres permettant de pouvoir déterminer un ou plusieurs serveurs adaptés pour héberger les fonctions logicielles. Par ailleurs, deux fonctions logicielles distinctes peuvent également être hébergées sur un même serveur, par exemple dans le cas où le paramètre caractérisant le dispositif programmable d’accueil est identique pour ces deux fonctions logicielles. Selon un cas particulier, le premier et le deuxième serveur peuvent correspondre à des serveurs virtuels et être possiblement déployés sur un même serveur physique. Un réseau virtualisé de communication est considéré dans sa signification la plus large. Il peut ainsi être considéré que le réseau virtualisé de communication est établi par le déploiement et la configuration de fonctions logicielles sur des serveurs physiques conformément à des requêtes et instructions transmises par des entités d’administration diverses communément appelées fonctions MANO (Management and Orchestration) dans un environnement NFV.
[0011] Ainsi, plusieurs réseaux virtualisés de communication peuvent être établis sur une infrastructure virtualisée et il est considéré que la mise à jour de cette infrastructure pour les besoins d’un réseau de communication correspond à une mise à jour d’un réseau de communication. Les opérateurs assurant la gestion des réseaux de communication et les opérateurs assurant la gestion de l’infrastructure virtualisée sur laquelle sont mis en œuvre les réseaux de communication peuvent être distincts. La détermination d’une zone au sein du réseau virtualisé de communication peut ainsi correspondre à une détermination d’une zone au sein d’une infrastructure d’exécution comprenant notamment une infrastructure virtualisée et des entités d’administration (MANO) de l’infrastructure virtualisée mise en œuvre sur des serveurs physiques génériques. Un composant logiciel déployé sur un tel serveur ainsi que la fonction logicielle associée permet ainsi de mettre à jour l’infrastructure d’exécution et donc un réseau de communication établi sur cette infrastructure.
[0012] Selon un aspect de l’invention, dans le procédé de détermination d’un groupe de serveurs, l’obtention d’une caractéristique comprend une réception en provenance de l’entité de gestion du composant logiciel d’une demande d’autorisation de déploiement du composant logiciel.
[0013] L’obtention de la caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée peut être avantageusement couplée ou comprise dans une demande d’autorisation du déploiement du composant logiciel pour pourvoir s’assurer que le composant logiciel sera déployé en ayant une garantie de la disponibilité de la fonction logicielle associée.
[0014] Selon un autre aspect, le procédé de détermination d’un groupe de serveurs comprend outre une réservation d’une ressource du deuxième serveur comprenant ledit dispositif programmable.
[0015] Selon ce mode, le procédé permet en outre de pouvoir réserver des capacités, c’est- à-dire une ressource du deuxième serveur sur lequel sera installé la fonction logicielle associée et ainsi de s’assurer que lors de l’installation du composant logiciel, la fonction logicielle, ou l’exécutable de la fonction logicielle associée, pourra effectivement être installée.
[0016] Selon un autre aspect, le procédé de détermination d’un groupe de serveurs comprend en outre le déploiement par l’intermédiaire d’une entité de gestion du réseau virtualisé de communication de la fonction logicielle sur ledit dispositif programmable du deuxième serveur dont une ressource a été réservée.
[0017] La fonction logicielle peut être avantageusement installée ou téléchargée sur le dispositif programmable déterminé par l’entité d’orchestration par l’intermédiaire d’une entité en charge des ressources du réseau virtualisé, telle qu’une entité de type VIM (en anglais Virtual Infrastructure Manager). Ainsi, la ressource réservée est allouée de façon certaine à la fonction logicielle et le composant logiciel, tel qu’un composant VNF (VNFC) peut l’utiliser dès que celui-ci est téléchargé sur un serveur du cluster ou de la zone.
[0018] Selon un autre aspect, le procédé de détermination d’un groupe de serveurs comprend en outre la création d’un groupe de serveurs comprenant au moins un serveur adapté pour accueillir le composant logiciel et un serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique.
[0019] Dans le cas où l’étape de détermination n’a permis d’identifier aucun cluster ou aucune zone comprenant les serveurs requis pour l’instanciation du composant logiciel et de la fonction logicielle associée au composant logiciel, le procédé peut avantageusement comprendre la création d’un tel cluster comprenant à minima les deux serveurs requis de façon à pouvoir télécharger le composant et la fonction logicielle associée conformément au paramètre et donc à la caractéristique obtenue. Cette création peut être réalisée par l’intermédiaire d’une entité de gestion du réseau virtualisé de communication de type CCM (en anglais CIS (Container Infrastructure Service) Cluster Management) qui peut lui-même s’appuyer sur une entité de type VIM s’il s’agit d’un cluster basé sur des serveurs virtuels ou de type PIM (Physical Infrastructure Manager) s’il s’agit de serveurs physiques (ex. Openstack Ironie). Le CCM se charge ainsi de la création du cluster et si c’est un cluster sur serveurs virtuels, il s’appuie sur le VIM. Si c’est un cluster physique (container sur baremetal) il s’appuie sur un PIM (Physical Infrastructure Manager (ex : OpenStack Ironie)). [0020] Selon un autre aspect, dans le procédé de détermination d’un groupe de serveurs, au moins une caractéristique d’un dispositif programmable est comprise dans les caractéristiques du groupe suivant :
- une taille d’espace mémoire du dispositif programmable,
- un nombre d’unités de traitement du dispositif programmable,
- un type de dispositif programmable,
- un identifiant du dispositif programmable,
- une adresse de téléchargement de la fonction logicielle sur le dispositif programmable.
[0021] La caractéristique du dispositif programmable utilisée pour sélectionner ou créer un serveur peut correspondre à un ou plusieurs caractéristiques parmi les suivantes. Il peut ainsi s’agir de capacités dites matérielles correspondant à un nombre de CPU (en anglais Central Processing Unit) requis, à une taille de mémoire virtuelle ou à une taille d’un disque virtuel. Il peut également s’agir d’un type dispositif programmable à utiliser, par exemple entre FPGA (en anglais Field-Programmable Gate Array) et eBPF (en anglais Extended Berkeley Packet Filter). Il peut également s’agir d’un identifiant du dispositif programmable comprenant une ou plusieurs données parmi les données suivantes : nom du fournisseur du dispositif programmable, nom du dispositif programmable, serveur supportant le dispositif programmable, version du dispositif programmable, type de dispositif programmable (matériel ou logiciel). Le paramètre peut également comprendre une adresse de téléchargement de la fonction logicielle ou un pointeur vers un programme à charger sur le dispositif programmable.
Plusieurs dispositifs programmables peuvent possiblement accueillir une fonction logicielle associée à un composant logiciel et la caractéristique peut correspondre à un ou plusieurs dispositifs programmables compatibles avec les paramètres transmis. Le procédé permet ainsi de sélectionner un serveur comprenant un dispositif programmable adapté, parmi les dispositifs compatibles, pour une fonction logicielle ou pour un ensemble de fonctions logicielles en fonction des paramètres de la fonction logicielle associée compris par exemple dans le document de description.
[0022] Selon un autre aspect, selon le procédé de détermination d’un groupe de serveurs, la fonction logicielle est une fonction d’accélération de traitement de la donnée du flux.
[0023] Le procédé peut être avantageusement mis en œuvre pour une fonction logicielle correspondant à une fonction d’accélération de traitement de certains flux de données, permettant ainsi de délester le composant logiciel de certaines tâches coûteuses en termes de ressources pour le serveur virtuel hébergeant le composant logiciel.
[0024] Selon un autre aspect, le procédé de détermination d’un groupe de serveurs comprend en outre l’émission à une entité de gestion du réseau virtualisé d’un programme informatique de la fonction logicielle associée destiné à mettre à jour le dispositif programmable du deuxième serveur.
[0025] Selon un autre aspect, dans le procédé de détermination d’un groupe de serveurs, la demande de déploiement comprend l’émission d’un document comprenant l’identifiant du composant logiciel et l’au moins un paramètre de la fonction logicielle associée, ledit document comprenant en outre une référence à la fonction logicielle associée et une référence à un programme informatique à partir duquel la fonction logicielle associée est rendue compatible avec le dispositif programmable.
[0026] La demande de déploiement peut avantageusement comprendre un document de description. Celui-ci peut correspondre par exemple à un document de type VNFD, par exemple compris dans un VNF Package, comprenant notamment des références à un exécutable à installer sur un dispositif programmable ainsi que possiblement une indication du type de dispositif et de sa version, un programme informatique, par exemple écrit dans un langage spécifique à partir duquel générer un exécutable compatible avec un dispositif programmable, ou possiblement un ensemble d’exécutables correspondant au même programme avec pour chacun une indication du type de dispositif programmable et de sa version.
[0027] Les différents aspects du procédé de détermination d’un groupe de serveurs qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
[0028] L’invention concerne également un procédé de détermination d’un dispositif programmable apte à héberger une fonction logicielle associée à un composant logiciel contribuant à la fourniture d’un service dans un réseau virtualisé de communication, ledit dispositif programmable étant mis en œuvre dans un serveur du réseau, le procédé mis en œuvre dans une entité de gestion du composant logiciel comprenant :
- une réception en provenance d’une entité d’orchestration d’une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- une détermination d’une caractéristique du dispositif programmable adapté pour accueillir la fonction logicielle associée en fonction de l’au moins un paramètre reçu dans la demande de déploiement.
[0029] Selon un aspect, le procédé de détermination d’un dispositif programmable comprend en outre une émission à destination de l’entité d’orchestration d’une demande d’autorisation de déploiement du composant logiciel comprenant la caractéristique déterminée.
[0030] Selon un autre aspect, le procédé de détermination d’un dispositif programmable comprend en outre, préalablement à l’étape de détermination, une émission d’une demande d’un document descriptif du composant logiciel et une réception dudit document.
[0031] Selon un autre aspect, le procédé de détermination d’un dispositif programmable comprend en outre la réception d’un message de demande d’installation du composant logiciel sur un premier serveur d’un groupe de serveurs déterminé et d’installation de la fonction logicielle sur un dispositif programmable compris dans un deuxième serveur du groupe de serveurs, ledit dispositif programmable étant compatible avec ladite caractéristique déterminée.
[0032] Selon un aspect, le procédé de détermination d’un dispositif programmable comprend en outre l’émission d’un message de demande de déploiement du composant logiciel sur le premier serveur dudit groupe.
[0033] Dans le cas où le composant logiciel, qui peut correspondre à un composant VNF (VNFC) ou à une VNF, le procédé comprend, selon un mode de réalisation, l’instanciation du composant logiciel sur le premier serveur déterminé par une entité d’orchestration. Ce téléchargement du composant logiciel peut être opéré de façon indépendante ou conjointe avec le téléchargement de la fonction logicielle associée au composant logiciel. Cette instanciation peut être opérée par l’intermédiaire de l’entité de gestion du composant logiciel et possiblement également par l’intermédiaire d’une entité de gestion du réseau virtualisé de communication. Ainsi, le réseau virtualisé de communication est mis à jour et devient opérationnel pour la fourniture du service utilisant le composant logiciel.
[0034] Les différents aspects du procédé de détermination d’un dispositif programmable qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
[0035] L’invention concerne également un dispositif de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel contribuant à la fourniture d’un service dans ledit réseau, ledit composant logiciel requérant la mise en œuvre d’une fonction logicielle associée de traitement d’une donnée du service, ledit dispositif de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication étant configuré pour :
- émettre à destination d’une entité de gestion du composant logiciel une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- obtenir une caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée, déterminée en fonction de l’au moins un paramètre,
- déterminer ledit groupe de serveurs comprenant au moins un premier serveur adapté pour accueillir le composant logiciel et un deuxième serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique obtenue.
[0036] Ce dispositif de détermination d’un groupe de serveurs informatiques est apte à mettre en œuvre dans tous ses modes de réalisation le procédé de détermination d’un groupe de serveurs qui vient d'être décrit.
[0037] L’invention concerne également un dispositif de détermination d’un dispositif programmable apte à héberger une fonction logicielle associée à un composant logiciel contribuant à la fourniture d’un service dans un réseau virtualisé de communication, ledit dispositif programmable étant mis en œuvre dans un serveur du réseau, ledit dispositif de détermination d’un dispositif programmable étant configuré pour:
- recevoir en provenance d’une entité d’orchestration une demande de déploiement du composant logiciel, ladite demande d’un identifiant du composant logiciel comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- déterminer une caractéristique du dispositif programmable adapté pour accueillir la fonction logicielle associée en fonction de l’au moins un paramètre reçu dans la demande de déploiement.
[0038] Ce dispositif de détermination d’un dispositif programmable est apte à mettre en œuvre dans tous ses modes de réalisation le procédé de détermination d’un dispositif programmable qui vient d'être décrit.
[0039] L’invention concerne également un système de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel contribuant à la fourniture d’un service dans ledit réseau, ledit composant logiciel requérant la mise en œuvre d’une fonction logicielle associée de traitement d’une donnée du service, ledit système comprenant :
- Un dispositif de détermination d’un groupe de serveurs décrit ci-dessus,
- Un dispositif de détermination d’un dispositif programmable également décrit ci-dessus. [0040] L’invention concerne également des produits programmes d’ordinateur comportant un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par au moins un processeur, configurent ledit au moins un processeur pour mettre en œuvre les procédés respectifs de détermination d’un groupe de serveur et de dispositif programmable selon l’un quelconque des modes de mise en œuvre de la présente divulgation.
[0041] L’invention concerne également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par au moins un processeur, configurent ledit au moins un processeur pour mettre en œuvre un procédé de détermination d’un groupe de serveurs ou un procédé de détermination d’un dispositif programmable selon l’un quelconque des modes de mise en œuvre de la présente divulgation.
Brève description des dessins
[0042] L’invention sera mieux comprise à la lecture de la description suivante, donnée à titre d’exemple nullement limitatif, et faite en se référant aux figures qui représentent :
[Fig. 1] Figure 1 : une représentation schématique d’un réseau de communication composé de fonctions virtualisées,
[Fig. 2] Figure 2 : une représentation schématique d’un procédé de détermination d’un groupe de serveurs mis en œuvre dans une architecture NFV,
- [Fig. 3] Figure 3 : un diagramme illustrant les principales étapes d’un procédé de détermination d’un groupe de serveurs selon un premier mode de réalisation, [Fig. 4] Figure 4 : un diagramme illustrant les principales étapes d’un procédé de détermination d’un groupe de serveurs selon un deuxième mode de réalisation, [Fig. 5] Figure 5 : une représentation d’un dispositif de détermination d’un groupe de serveurs selon un exemple,
[Fig. 6] Figure 6 : une représentation d’un dispositif de détermination d’un dispositif programmable selon un autre exemple.
[0043] Dans ces figures, des références identiques d’une figure à une autre désignent des éléments identiques ou analogues. Pour des raisons de clarté, les éléments représentés ne sont pas à l’échelle, sauf mention contraire.
Description des modes de réalisation
[0044] De manière plus générale, il est à noter que les modes de mise en œuvre et de réalisation considérés ci-dessus ont été décrits à titre d’exemples non limitatifs, et que d’autres variantes sont par conséquent envisageables.
[0045] Dans la suite de la description, on présente des modes de réalisation de l'invention dans un réseau virtualisé de communication pouvant comprendre par exemple un ou plusieurs réseaux d’accès et un ou plusieurs cœurs de réseaux. Ce réseau virtualisé de communication peut être mis en œuvre pour acheminer des données de communication à destination de terminaux fixes ou mobiles et le réseau peut être mis en œuvre avec/par des fonctions virtualisées mais des fonctions non virtualisées peuvent également être comprises dans le réseau principalement virtualisé, par exemple en utilisant un équipement spécifique pour une fonction donnée. Ce réseau peut être utilisé pour l’acheminement et/ou le traitement de données de clientèle résidentielle ou d’entreprise.
[0046] On se réfère tout d’abord à la [Fig 1] qui présente une représentation schématique d’un réseau Res virtualisé de communication composé de fonctions virtualisées.
Ce réseau Res de communication est composé de deux zones Z1 et Z2, aussi appelées clusters, qui peuvent par exemple être des zones géographiques. Le réseau peut comprendre un plus grand nombre de zones, le nombre de 2 ayant été choisi pour que la figure soit lisible. Chaque zone Z1 et Z2, selon l’exemple retenu, est composé de 2 serveurs, à savoir Srv1 et Srv2 pour la zone Z1 et les deux serveurs Srv3 et Srv4 dans la zone Z2.
Les serveurs Srv1 et Srv3 sont par exemple des serveurs informatiques banalisés, dits « sur étagère » pour héberger le logiciel des fonctions virtualisées VF1 et VF2, par opposition à des équipements spécialisés. Ces serveurs sont équipés de processeurs eux- mêmes banalisés (processeur généraliste par opposition à processeur spécialisé ou dédié à une fonction), par exemple des processeurs fondés sur l’architecture x86 d’Intel. Les serveurs Srv2 et Srv4 sont par exemple également des serveurs informatiques banalisés mis en œuvre pour accueillir des fonctions logicielles telles que des fonctions d’accélération Acc1 , Acc2 et Acc3.
Sur le serveur Srv1 de la zone Z1 est installée une fonction virtualisée VF1 . Cette fonction virtualisée VF1 assure une fonction d’acheminement et/ou de traitement de données transmises ou reçus par le terminal Terml . Cette fonction virtualisée VF1 peut être, selon quelques exemples non limitatifs, une fonction d’un plan usager d’un réseau mobile de communication, une fonction d’un plan de contrôle d’un réseau mobile de communication, une fonction d’un plan de gestion d’un réseau mobile de communication ou bien des fonctions équivalentes d’un réseau fixe de communication ou bien encore une fonction de traitement applicatif associé par exemple à un service de communication.
[0047] Les fonctions virtualisées VF1 et VF2 peuvent être composées d’un ou plusieurs composants assurant chacun un traitement élémentaire de la fonction VF1 ou VF2. Selon l’exemple décrit dans la [Fig 1], la fonction virtualisée VF1 est composée de quatre composants C1 , C2, C3 et C4 et la fonction virtualisée VF2 est composée de 3 composants C2, C5, C6. Selon un autre exemple non représenté, une fonction virtualisée peut être mono-composant, ce composant étant identifié avec l’identifiant de la fonction virtualisée et/ou du composant.
[0048] Les fonctions virtualisées VF1 et VF2, et donc leurs composants associés, peuvent être instanciés sur des machines virtuelles ou des conteneurs selon la technique de virtualisation retenue s’appuyant sur une virtualisation au niveau du matériel pour les machines virtuelles et au niveau du système d’exploitation pour les conteneurs.
[0049] Les fonctions virtuelles VF1 et VF2, et plus particulièrement les composants respectifs C2, C3 et C5 de ces fonctions virtuelles VF1 et VF2, requièrent des fonctions logicielles pour assurer certains traitements avec une meilleure efficacité que si les seuls composants assuraient ces traitements. C’est notamment le cas de certains composants des fonctions réseau opérant directement sur les flux de données échangés entre les équipements des utilisateurs connectés au réseau Res ou entre ces équipements utilisateurs et des serveurs d’applications ou de contenu. On désigne en général ces fonctions réseau comme appartenant au plan de données (en anglais data plane) ou plan utilisateur (en anglais user plane). L’exemple emblématique dans les cœurs de réseau 5G est l’UPF (en anglais User Plane Function). Les composants intervenant sur le plan de données nécessitent possiblement des fonctions logicielles pour améliorer le traitement des données (Acc1 , Acc2, Acc3 dans la [Fig1 ]).
[0050] Pour déployer ces fonctions logicielles Acc1 , Acc2 et Acc3, les industriels ont recours à des solutions d’accélération logicielle ou matérielle. Une famille de solutions, appelée « hardware offload » consiste à délester le processeur principal du serveur hébergeant la VNF de certains traitements qui sont alors déportés sur un processeur auxiliaire, installé par exemple sur une carte réseau ou une carte spécialisée ajoutée sur ce même serveur (alternative non représentée sur [Fig 1 ]), ou un serveur distant (Srv 2 pour Srv1 ou Srv3 pour Srv4 dans la [Fig 1], sachant que le serveur distant peut être accessible par exemple à travers une infrastructure de communication lorsque cela est possible (non représentée sur la [Fig 1 ]). Les processeurs auxiliaires en question peuvent être spécialisés ou programmables, comme des circuits logiques programmables de type FPGA (en anglais Field-Programmable Gate Array). Un exemple de langage de programmation adapté au traitement des paquets (DSL, en anglais Domain Specific Language) est le langage P4 (en anglais Programming Protocol-Independent Packet Processor). Comme pour tout langage non interprété, un programme écrit en P4 nécessite d’être compilé pour le traduire dans un langage machine compréhensible pour le matériel sur lequel il doit s’exécuter.
[0051] Une fonction virtualisée VF1 et VF2 et plus précisément les composants élémentaires C1 , C2, ... , C6 qui composent ces fonctions virtualisées VF1 et VF2 peuvent être instanciés de façon dynamique dans le réseau Res de communication pour répondre à un besoin d’un nouveau service, pour améliorer des performances ou pour adapter le réseau à un nouveau contexte. Sachant que certaines fonctions virtualisées ou certains composants requièrent en outre une fonction logicielle associée, le déploiement d’un nouveau composant requiert de prendre en compte l’implémentation d’une nouvelle fonction logicielle ou la programmation d’un dispositif programmable avec une fonction logicielle requise pour le nouveau composant installé. Le choix de la zone Z1 ou Z2 pour déployer, selon un exemple, un nouveau composant logiciel C2 sera effectué en fonction de la possibilité de pouvoir effectivement mettre à jour un dispositif programmable avec la fonction logicielle requise Acc1 sur un serveur dans ladite zone. Selon un exemple, à titre d’illustration uniquement et de façon non exhaustive, la fonction logicielle associée correspond à un programme informatique exécutable assurant une fonction d’accélération à charger sur un dispositif programmable qui peut correspondre à un accélérateur programmable.
[0052] On se réfère ensuite à la [Fig 2] qui présente une vue schématique d’un procédé de détermination mis en œuvre dans une architecture NFV (en anglais Network Function Virtualisation). Au sein de cette architecture, une entité de type NFVO (en anglais Network Function Virtualisation Orchestrator) a la charge du cycle de vie des services instanciés à partir d’une ou plusieurs fonctions virtualisées, parmi lesquelles la fonction virtualisée VF1 . L’entité OSS (en anglais Operations Support Systems) assure la gestion du réseau de communication (Res dans [Fig 1]) notamment déployé à partir d’une architecture NFV et utilise l’entité NFVO pour cela. L’entité VNFM (Virtualised Network Function Manager) assure la gestion et le cycle de vie d’une fonction virtualisée telle que la fonction VF1. L’entité VIM (Virtualised Infrastructure Manager) assure la gestion des ressources d’une infrastructure NFV (NFVI en anglais Network Function Virtualisation Infrastructure) sur laquelle est déployée une fonction virtualisée telle que VF1 . La fonction virtualisée VF1 est possiblement composée d’une pluralité de composants logiciels aussi appelés composants élémentaires, chacun de ces composants assurant la mise en œuvre d’un ou plusieurs traitements d’une donnée ou d’un flux de données.
[0053] Dans le cas où le réseau de communication s’appuie sur une technique de conteneurisation, des entités de type CISM (en anglais Container Infrastructure Service Management), CCM (Container Cluster Management) et CIR (Container Image Repository) peuvent en outre contribuer au déploiement et à la mise à jour de l’infrastructure virtualisée. Le CISM assure la gestion des conteneurs et de l’infrastructure de conteneurs tandis que le CCM assure la gestion des clusters, consistant en des ensembles de machines qui permettent d'exécuter des applications conteneurisées. Le CIR comprend des images à installer dans des conteneurs et un ensemble d’images utilisées pour fournir différentes versions d’une application.
[0054] Lorsqu’une nouvelle fonction virtualisée doit être déployée, par exemple à la suite d’une requête émise par l’entité OSS, ou bien qu’une fonction virtualisée doive être mise à jour par exemple en ajoutant un nouveau composant logiciel, une entité de type NFVO doit décider de la zone, par exemple représentée par un cluster, dans laquelle le composant doit être instancié. Cette décision peut être prise en fonction d’un service, de la position d’un autre composant logiciel voire d’un équipement physique mais dans le cas où la fonction virtualisée ou le composant logiciel requiert en outre une fonction logicielle associée, par exemple une fonction d’accélération, alors la décision prend en compte la présence dans la zone ou le cluster d’un dispositif programmable hébergé par un serveur et adapté pour être programmé pour mettre en œuvre la fonction logicielle associée au composant logiciel.
[0055] Parmi les quatre options possibles (Srv1 , Srv10, Srv1 1 , Srv12) pour héberger la fonction virtualisée VF1 ou le composant C1 si seulement le composant C1 est requis, le serveur Srv1 est sélectionné car il est dans une zone Z1 comprenant en outre un serveur Srv2, ce serveur Srv2 comprenant un dispositif DISP programmable sur lequel la fonction logicielle Acc1 associée à la fonction VF1 (ou au composant C1 ) peut être ajoutée, permettant ainsi à la fonction virtualisée de fonctionner de façon optimale en bénéficiant des fonctions de traitements avancées permises par ladite fonction logicielle Acc1 associée, ce qui n’aurait pas été le cas si l’un des autres serveurs Srv10, Srv11 , Srv12 avait été sélectionné. Cette sélection assurée par l’entité NFVO, en lien avec l’entité VNFM, repose sur la spécification de l’application logicielle associée, via un ou plusieurs paramètres, et sur la détermination du dispositif programmable par l’entité VNFM à partir de la spécification de la fonction logicielle associée. Une fois le dispositif programmable caractérisé, il convient d’identifier une zone ou un cluster, c’est-à-dire un groupe de serveurs, comprenant un serveur adapté pour accueillir le composant logiciel, tel que la fonction virtualisée, et comprenant en outre un serveur comprenant le dispositif programmable caractérisé. Il est à noter que selon un exemple, le serveur hébergeant le composant logiciel et le serveur comprenant le dispositif programmable peuvent être un même serveur. L’entité NFVO détermine ainsi la zone Z1 dans laquelle la fonction virtualisée VF1 , et ensuite une entité VIM et/ou CISM détermine, dans la zone Z1 , le serveur le plus apte à héberger le composant logiciel, donc dans ce cas le serveur Srv1 , présent dans le même cluster que le serveur Srv2 comprenant le dispositif programmable.
[0056] L’entité NFVO, en interagissant avec l’entité VIM, peut en outre réserver les ressources sur le serveur Srv1 pour installer le composant logiciel, et possiblement des ressources sur le Srv2 pour installer la fonction logicielle associée au composant logiciel, et compatible avec le dispositif programmable du serveur Srv2.
[0057] L’entité VNFM interagit ensuite avec l’entité VIM, et possiblement avec les entités CISM voire CCM et CIR si les serveurs utilisent la technique de conteneurisation, pour effectuer les déploiements effectifs dans le réseau virtualisé, les ressources allouées pouvant être possiblement communiquées à l’entité VIM si c’est le cas.
[0058] On se réfère ensuite à la [Fig 3] qui présente un diagramme illustrant les principales étapes d’un procédé de détermination d’un groupe de serveurs selon un premier mode de réalisation. Dans ce mode de réalisation, la technique de virtualisation est basée sur des machines virtuelles. Dans ce mode, les serveurs tels que présentés dans les figures précédentes sont dotés de machines virtuelles adaptées pour accueillir des composants logiciels et des fonctions logicielles. Cette figure est volontairement simplifiée par apport à l’architecture NFV MANO (en anglais Network Functions Virtualisation (NFV) Management and Orchestration) à des fins de compréhension.
[0059] Lors d’une étape EO, une entité OSS requiert auprès d’une entité NFVO, correspondant à une entité d’orchestration, le déploiement d’un nouveau service requérant la mise en œuvre d’une ou plusieurs fonctions virtualisées dans le réseau de communication, une ou plusieurs d’entre elles requises pour le service pouvant déjà être présentes dans l’infrastructure virtualisée (NFVI) du réseau de communication. Cette requête comprend par exemple un identifiant d’un fichier de type NSD (en anglais Network Service Descriptor) et selon un autre exemple le fichier NSD. Ce fichier comprend par exemple des informations sur les fonctions virtualisées, par exemple de type VNFD (en anglais Virtualised Network Function Descriptors) et les fonctions non virtualisées, par exemple de type PNFD (en anglais Physical Network Function Descriptors), requises pour le déploiement du service, ainsi que des informations sur les liens entre ces fonctions. Selon un exemple, préalablement à cette étape EO, lors d’étapes non représentées, l’OSS récupère un VNF package comprenant le fichier NSD, auprès d’un fournisseur de VNF et l’OSS transmet le VNF package à l’entité NFVO.
[0060] Lors d’une étape E1 , le NFVO analyse la description NSD et détermine le type de fonction virtualisée et le nombre d’instances de cette fonction virtualisée à mettre en œuvre dans le réseau de communication ainsi que les liens virtuels à établir entre ces fonctions virtualisées. Selon un exemple, plusieurs fonctions virtualisées et plusieurs instances d’une ou plusieurs fonctions virtualisées peuvent être déterminées.
[0061] Lors d’une étape E2, le NFVO émet à destination d’un VNFM, correspondant à une entité de gestion d’un composant logiciel, au moins une demande de déploiement d’une instance de fonction virtualisée, telles que déterminée lors de l’étape E1. De façon à rendre la figure suffisamment claire, un seul VNFM est représenté, mais le NFVO peut solliciter plusieurs VNFM, notamment dans le cas où des VNFM distincts gèrent des fonctions virtualisées spécifiques. La demande de déploiement du composant logiciel, à savoir la fonction virtualisée ou un composant élémentaire d’une fonction virtualisée, comprend la référence, par exemple un identifiant relatif à un document descriptif du composant logiciel requis ou le document lui-même, tel qu’un document de type VNFD (en anglais Virtualised Network Function Descriptor) comprenant notamment un identifiant du composant logiciel requis et comprenant également un paramètre ou plusieurs paramètres de la fonction logicielle associée requise en complément du composant logiciel.
Selon un exemple, un document VNFD est un fichier décrivant les caractéristiques d’un ou plusieurs composants logiciels (la VNF et ses composants VNFC, le composant logiciel pouvant être la VNF ou un VNFC) en termes de besoins en ressources du réseau de communication et de règles pour en gérer le cycle de vie (instanciation, changement de dimension, suppression, etc.). Pour être interprétables par des systèmes de gestion et d’orchestration développés indépendamment des composants logiciels, ces descripteurs sont conformes à un standard, tel que TOSCA ou YANG.
Ce fichier VNFD fournit en particulier la liste des composants élémentaires (VNFC) qui constituent, selon cet exemple, le composant logiciel et la manière de les connecter entre eux. Il indique aussi pour chaque composant élémentaire le nombre d’instances à déployer à différents stades du cycle de vie de ce composant logiciel. Pour chaque composant élémentaire, le fichier VNFD contient un bloc d’information appelé VDU (Virtualised Deployment Unit) qui décrit précisément les besoins du composant élémentaire en ressources du réseau de communication. Ces besoins concernent des ressources de base (CPU, mémoire, stockage, etc.) nécessaire à l’exécution du logiciel du composant élémentaire. Un composant logiciel peut donc correspondre à un composant élémentaire ou à une pluralité de composants élémentaires. Un ou plusieurs des paramètres suivants peuvent être possiblement présents dans le fichier VNFD tels que des paramètres liés à une fonction logicielle associée au composant logiciel, tels que :
- Nombre de CPU virtuels, taille de la mémoire virtuelle, taille d’un disque virtuel, requis pour la fonction logicielle
- Type de fonction logicielle associée = FPGA ou eBPF
- Données d’identification de la fonction logicielle associée comprenant par exemple :
- nom du fournisseur de la fonction logicielle associée
- nom de la fonction logicielle associée à installer
- version de la fonction logicielle associée
- une adresse de téléchargement de la fonction logicielle sur le dispositif programmable.
Le fichier VNFD peut être compris dans un VNF package, celui-ci pouvant comprendre un exécutable de la fonction logicielle associée. Selon un autre exemple, un lien vers l’exécutable peut être présent dans le VNFD. Le paramètre de la fonction logicielle associée peut également correspondre à un ou plusieurs exécutables de la fonction logicielle associée et la caractéristique du dispositif programmable est ensuite obtenue en fonction d’un ou plusieurs de ces exécutables. Le dispositif programmable sera en effet déterminé en fonction de sa capacité à supporter un ou plusieurs de ces exécutables et si plusieurs dispositifs programmables sont adaptés pour un exécutable, c’est-à-dire un logiciel, un autre paramètre de la fonction logicielle tel que par exemple sa consommation énergétique, sa capacité à traiter un fort trafic ou un ratio performance par rapport à sa consommation énergétique pourra être considéré pour déterminer une caractéristique du dispositif programmable, tel que par exemple sa consommation énergétique, sa capacité à traiter un fort trafic ou un ratio performance par rapport à sa consommation énergétique.
[0062] Selon une alternative, l’étape E2 peut se décomposer en plusieurs sous étapes non représentées. Le NFVO peut transmettre une demande de déploiement d’un composant logiciel comprenant un identifiant du composant logiciel requis et le VNFM, à la réception de cette demande, demande au NFVO les informations relatives à ce composant logiciel et à la fonction logicielle associée, s’il ne détient pas d’ores et déjà ces informations. Le NFVO transmet alors les informations, par exemple dans un fichier VNFD correspondant à l’identifiant, dans un second temps, à savoir après en avoir reçu la demande de la part du VNFM. Cette alternative a pour intérêt de limiter l’envoi de ces informations relatives au composant logiciel et à fonction logicielle associée systématiquement, et donc d’augmenter le trafic sur le réseau de communication.
[0063] A la réception de l’identifiant du composant logiciel et d’un ou plusieurs paramètres de la fonction logicielle associée, lors d’une étape E3, le VNFM détermine les besoins en ressources pour le déploiement du composant logiciel et de la fonction logicielle associée à ce composant logiciel. En particulier, le VNFM caractérise le dispositif programmable adapté pour accueillir la fonction logicielle associée en déterminant une caractéristique du dispositif programmable compatible aux paramètres de la fonction logicielle associée, reçus dans la requête de déploiement. La détermination du dispositif programmable comprend la détermination de caractéristiques en fonction des paramètres de la fonction logicielle reçus en provenance du NFVO.
[0064] Selon un exemple, le procédé de détermination comprend la détermination d’une ou plusieurs caractéristiques parmi les caractéristiques suivantes :
- une taille d’espace mémoire du dispositif programmable requis pour accueillir la fonction logicielle,
- un nombre d’unités de traitement du dispositif programmable requis pour accueillir la fonction logicielle,
- un type de dispositif programmable requis pour accueillir la fonction logicielle,
- un identifiant du dispositif programmable requis pour accueillir la fonction logicielle ,
- une adresse de téléchargement de la fonction logicielle sur le dispositif programmable. II est à noter qu’un ou plusieurs paramètres de la fonction logicielle peuvent être compris dans les caractéristiques déterminées dans l’étape de détermination du dispositif programmable.
[0065] Lors d’une étape E4, le VN FM transmet au NFVO une demande d’autorisation de déploiement du composant logiciel comprenant une caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée, déterminée en fonction du paramètre reçu. Cette demande de déploiement transmise par le NFVO comprend une ou plusieurs des caractéristiques définies dans l’étape E3 de détermination. Cette information va permettre au NFVO de pouvoir effectivement s’assurer que le déploiement du composant logiciel va pouvoir s’effectuer dans une zone où la fonction logicielle associée au composant logiciel va pouvoir être installée ou bien est déjà installée. Ainsi, le déploiement pourra être opéré en respectant les contraintes émises dans la demande de déploiement.
[0066] A partir de la demande d’autorisation du déploiement du composant logiciel et de la (ou des) caractéristique(s) du dispositif programmable requis pour l’activation de la fonction logicielle associée, le NFVO détermine lors d’une étape E5 une zone au sein du réseau de communication comprenant un serveur informatique sur lequel le composant logiciel peut être instancié et comprenant en outre un serveur informatique comprenant un dispositif programmable compatible avec la (ou les) caractéristique(s) reçue(s). La zone peut correspondre à un cluster selon une alternative et selon un autre exemple, les deux serveurs peuvent correspondre à un même serveur accueillant le composant logiciel et la fonction logicielle associée. Selon une autre alternative, la fonction logicielle associée peut être d’ores et déjà installée sur un dispositif programmable d’un serveur de la zone, auquel cas il ne restera qu’à instancier le composant logiciel sur un serveur de la même zone que ce serveur. Cette détermination par le NFVO peut également s’accompagner de l’identification d’une entité VIM, une entité de gestion du réseau virtualisé en charge de la gestion des ressources virtualisées du réseau de communication, pour l’instanciation du composant logiciel et possiblement de la fonction logicielle associée.
[0067] Selon un autre exemple, le NFVO détermine une zone au sein du réseau de communication comprenant un serveur informatique sur lequel le composant logiciel peut être instancié et comprenant en outre un serveur informatique comprenant un dispositif programmable compatible avec la (ou les) caractéristique(s) obtenues avant l’étape E2 et la demande envoyée lors de l’étape E2 vaut autorisation, ce qui implique, selon cet exemple, que l’étape E4 où le VNFM demande une autorisation comme décrit ci-dessus n’est pas requise. Selon ce mode de réalisation, le NFVO obtient par exemple d’une base de données, une caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée, déterminée en fonction d’un paramètre de la fonction logicielle associée.
[0068] Lors d’une étape E6 optionnelle, par exemple si le NFVO a identifié une zone et les serveurs dans la zone, le NFVO réserve des ressources sur le deuxième serveur en vue du déploiement de la fonction logicielle associée sur le dispositif programmable. Cette réservation peut s’effectuer auprès de l’entité VIM en charge de la gestion des ressources virtualisées de la zone comprenant le serveur. Le NFVO, selon un autre exemple, peut également réserver des ressources sur le premier serveur destiné à accueillir le composant logiciel.
[0069] Selon un exemple, avec la contribution du VIM, le NFVO peut installer la fonction logicielle associée sur le serveur dont des ressources ont été réservées lors d’une étape E7 optionnelle non représentée. Ainsi, le NFVO émet au VIM le programme informatique de la fonction logicielle associée destiné à mettre à jour le dispositif programmable du deuxième serveur déterminé. LE VIM peut ainsi installer le
[0070] Selon un exemple, lors d’une étape E8, le NFVO transmet au VN FM l’autorisation de déployer le composant logiciel requis. Cette autorisation comprend une information sur la zone dans laquelle le serveur doit être sélectionné et possiblement un identifiant du premier serveur déterminé pour accueillir la fonction virtualisée. L’identifiant du premier serveur n’est pas requis si l’ensemble des serveurs de la zone peuvent accueillir le composant logiciel sachant que la zone est sélectionnée si elle comprend en outre un serveur informatique comprenant un dispositif programmable adapté pour accueillir la fonction logicielle associée, que celle-ci soit déjà installée ou non. L’identité du VIM à solliciter peut-être transmis au VNFM lors de cette étape E8, notamment si le VIM a été déterminé lors de l’étape E5.
[0071] Lors d’une étape E9, le VNFM demande à un VIM le déploiement du composant logiciel dans la zone déterminée en précisant cette zone, voire en transmettant l’identifiant du premier serveur. Si aucune réservation n’a été effectuée pour l’installation du composant logiciel lors de l’étape E6, le VNFM peut indiquer au VIM les contraintes relatives au composant logiciel et à la fonction logicielle associée, de façon que le serveur de la zone sélectionné pour accueillir le composant logiciel respecte bien les contraintes induites par la fonction logicielle associée, conformément aux caractéristiques déterminées lors de l’étape E3. Cette alternative est utile si le premier serveur déterminé par le NFVO ne dispose plus des ressources nécessaires à l’instanciation du composant logiciel, ce qui notamment peut se produire en l’absence d’une réservation de ressources sur le premier serveur. Cette alternative est également utile si l’entité NFVO n’a pas déterminé spécifiquement un serveur mais une zone comprenant les serveurs requis.
[0072] Lors d’une étape E10, le VIM interagit avec des entités du réseau de communication dans lequel est déployé le composant logiciel et la fonction logicielle associée pour créer les ressources, comprenant notamment la machine virtuelle et les ressources CPU et disque par exemple, nécessaires à l’instanciation du composant logiciel sur le premier serveur de la zone déterminée.
[0073] Une fois déployés, le composant logiciel et la fonction logicielle associée peuvent interagir dans une étape non représentée sur la [Fig 3]. Selon un exemple, si le composant logiciel est relatif à un pare-feu, le composant logiciel peut transmettre des règles indiquant quels types de trafic sont à gérer par la fonction logicielle associée. Selon un exemple non représenté sur la [Fig 3], l’entité VNFM ou l’entité VIM peut transmettre au composant logiciel un identifiant, tel qu’une adresse, d’un serveur comprenant un dispositif programmable mis à jour avec une fonction logicielle associée relative au composant logiciel, ainsi que possiblement des éléments de sécurité permettant au composant logiciel de communiquer de façon sécurisée la fonction logicielle associée.
[0074] Lors d’une étape E11 , le VNFM informe le NFVO que le composant logiciel a été instancié et que la fonction logicielle associée est chargée sur le dispositif programmable du serveur, informant ainsi le NFVO de la disponibilité du composant logiciel et d’un fonctionnement de ce composant tel que requis dans le service dont le déploiement a été demandé dans l’étape EO, c’est-à-dire avec l’assistance de la fonction logicielle associée.
[0075] On se réfère ensuite à la [Fig 4] qui présente un diagramme illustrant les principales étapes d’un procédé de détermination selon un deuxième mode de réalisation. Dans ce mode de réalisation, la technique de virtualisation est basée sur des conteneurs. Dans ce mode, les serveurs informatiques tels que présentés dans les figures précédentes sont dotés de conteneurs adaptés pour accueillir des composants logiciels et sont par exemple aptes à accueillir des fonctions logicielles, par exemple via une carte réseau équipée d’un processeur FPGA. Cette figure est volontairement simplifiée par apport à l’architecture NFV MANO (en anglais Network Functions Virtualisation (NFV) Management and Orchestration) à des fins de compréhension.
[0076] Les étapes EO à E4 de la [Fig 4] sont comparables à celles de présentées dans la [Fig 3] et sont indépendantes du type de virtualisation mis en œuvre dans le réseau de communication.
[0077] Lors de l’étape E5, le NFVO détermine une zone au sein du réseau de communication comprenant un serveur informatique sur lequel le composant logiciel peut être instancié et comprenant en outre un serveur informatique comprenant un dispositif programmable compatible avec la (ou les) caractéristique(s) du dispositif programmable reçue(s). Plus précisément, le NFVO détermine un cluster, également identifié comme un groupe de serveurs, dans lequel un ou plusieurs serveurs physiques ou virtuels du cluster jouant le rôle de CIS sont équipés d’un dispositif programmable compatible avec la fonction logicielle associée, et que un ou plusieurs serveurs physiques ou virtuels jouant le rôle de CISM soient équipés d’une fonction de gestion du dispositif programmable sur lequel déployer la fonction logicielle associée sachant qu’un serveur du cluster doit être également adapté pour instancier le composant logiciel requis.
[0078] Selon une alternative, si aucun cluster n’est déterminé, un nouveau cluster peut être créé. Ce nouveau cluster ou groupe de serveurs comprend au moins un serveur adapté pour héberger le composant logiciel et un serveur adapté pour comprendre un dispositif programmable qui peut être mis à jour avec la fonction logicielle associée, conformément à la caractéristique reçue lors de de l’étape E4. Cette création est réalisée en interaction avec les entités VIM, CISM et CCM du système d’orchestration et de gestion de l’infrastructure virtualisée du réseau de communication. Selon un exemple, le NFVO informe l’OSS lors d’une étape E51 qu’aucune zone ou aucun cluster existant ne comprend les deux serveurs requis pour le composant logiciel et la fonction logicielle associée, ce deuxième serveur devant comprendre un dispositif programmable conforme aux caractéristiques reçues lors de l’étape E4.
[0079] Lors d’une étape E52, l’OSS détermine qu’un nouveau cluster répondant aux besoins tels que déterminés, doit être créé. Le NFVO peut ainsi transmettre les caractéristiques requises pour le nouveau cluster dans l’étape E51.
[0080] Lors d’une étape E53, l’OSS sollicite directement le CCM ou bien par l’intermédiaire du NFVO, notamment dans le cas où l’OSS n’a pas reçu les caractéristiques du nouveau cluster à créer, pour créer un nouveau cluster conformément aux caractéristiques relatives aux deux serveurs.
[0081] Lors d’une étape E54, le CCM crée le nouveau cluster et en informe en retour, lors d’une étape E55, l’OSS possiblement par l’intermédiaire du NFVO. Ce message d’information relatif au nouveau cluster créé comprend en outre les caractéristiques du nouveau cluster et possiblement les caractéristiques de deux serveurs adaptés pour accueillir respectivement le composant logiciel et la fonction logicielle associée.
[0082] Si un nouveau cluster est créé, conformément aux étapes E51 à E55 décrites ci- dessus, les étapes EO à E5 peuvent être répétées pour déterminer le cluster dans lequel le composant logiciel et la fonction logicielle associée peuvent être installées.
[0083] Selon un exemple, avec la contribution du CCM, le NFVO peut installer en collaboration avec le CCM la fonction logicielle associée sur le dispositif programmable du second serveur adapté aux caractéristiques reçues lors de l’étape E4. Ainsi, lors de l’étape E6 le NFVO émet au CCM le programme informatique de la fonction logicielle associée destiné à mettre à jour le dispositif programmable du deuxième serveur déterminé, cette mise à jour étant effectuée par le CCM et le CISM lors de l’étape E7 possiblement en collaboration avec le VIM. Le deuxième serveur comprenant le dispositif programmable sur lequel est installé la fonction logicielle associée est alors spécifiquement étiqueté ou identifié pour le repérer lors de l’installation du composant logiciel sur le premier serveur.
[0084] Lors d’une étape E8, selon un exemple, le NFVO transmet au VN FM l’autorisation de déployer le composant logiciel requis. Cette autorisation comprend une information sur le cluster dans laquelle le serveur doit être sélectionné et dans le cas où la fonction logicielle associée a été installée conformément à l’étape E7, cette autorisation comprend en outre une information relative à l’étiquetage du deuxième serveur permettant ainsi au VN FM de sélectionner un premier serveur adapté pour le composant logiciel à installer et l’interaction requise entre le composant logiciel et la fonction logicielle associée.
[0085] Lors d’une étape E9, le VNFM interagit avec le CISM pour déployer le composant logiciel. Si le NFVO a transmis lors de l’étape E8 une information relative à l’étiquetage du second serveur à utiliser pour sélectionner le premier serveur, alors le VNFM la transmet au CISM lors de l’étape E9. Dans le cas où cette information n’a pas été transmise, le VNFM transmet au CISM les caractéristiques requises du dispositif programmable telles que déterminées lors de l’étape E3 et le CISM sélectionne alors un ou plusieurs serveurs adaptés pour héberger le composant logiciel et situé dans le même cluster que le deuxième serveur comprenant le dispositif programmable.
[0086] Si l’installation de la fonction logicielle associée n’a pas été réalisée, le CISM l’installe sur le deuxième serveur déterminé en fonction des caractéristiques et le CISM interagit possiblement avec le VIM pour créer les ressources nécessaires à l’installation du composant logiciel lors de l’étape E10.
[0087] Une fois installés, le composant logiciel et la fonction logiciel associée interagissent conformément à ce qui est décrit ci-dessus en relation avec la [Fig 3].
[0088] Lors d’une étape E11 , le CISM informe le NFVO, via le VNFM, que le composant logiciel a été instancié sur le premier serveur du cluster déterminé et que la fonction logicielle associée est installée sur le dispositif programmable du deuxième serveur du même cluster, informant ainsi le NFVO de la disponibilité du composant logiciel et d’un fonctionnement de ce composant tel que requis dans le service dont le déploiement a été demandé dans l’étape EO.
[0089] Selon un exemple non représenté sur la [Fig 4], l’entité VNFM ou l’entité VIM ou l’entité CISM peut transmettre au composant logiciel un identifiant, tel qu’une adresse, d’un serveur comprenant un dispositif programmable mis à jour avec une fonction logicielle associée relative au composant logiciel, ainsi que possiblement des éléments de sécurité permettant au composant logiciel de requérir à la fonction logicielle associée. [0090] Dans le cas d’un composant logiciel mis en œuvre dans un conteneur, selon le mode de réalisation de la [Fig 4], le terme serveur utilisé désigne aussi bien un serveur physique qu’une machine virtuelle, le conteneur étant alors instancié sur une machine virtuelle. Dans ce deuxième cas, le CCM interagit avec le VIM pour installer la fonction logicielle associée sur le dispositif programmable de la machine virtuelle sur un serveur.
[0091] Les programmes informatiques relatifs à la fonction logicielle associée peuvent être obtenus par l’entité en charge de l’installer par l’intermédiaire d’un lien par exemple de type URI (en anglais Uniform Resource Identifier) spécifié par exemple dans un document de type VNFD.
[0092] Un composant logiciel fait appel à une fonction logicielle qui lui est propre et ces différentes fonctions logicielles peuvent être déployées sur un même dispositif programmable selon un exemple. Un composant logiciel peut requérir plusieurs fonctions logicielles associées dans les modes de réalisation décrits.
[0093] Le programme informatique relatif à la fonction logicielle associée peut requérir une compilation avant son installation pour le rendre compatible avec le dispositif programmable du deuxième serveur.
[0094] La description du besoin d’une fonction logicielle associée pour un composant logiciel peut être présente dans un fichier de type VNFD décrit ci-dessus ou bien dans un document spécifique à la technique de virtualisation utilisée, par exemple dans des fichiers de type Helm Charts si une solution de type Kubernetes est utilisée.
[0095] Si une fonction virtualisée comprenant plusieurs composants élémentaires doit être instanciée, et que la fonction virtualisée ou qu’un ou plusieurs de ses composants doit être associé à une fonction logicielle, alors les procédés décrits dans la [Fig 3] et la [Fig 4] peuvent être exécuté pour la fonction virtualisée et/ou répétés pour les différents composants et leurs fonctions logicielles associées. Le composant logiciel correspond indifféremment à une fonction virtualisée ou un composant élémentaire. Selon une alternative, la fonction virtualisée représente un composant logiciel selon la terminologie utilisée dans les différents modes de réalisation et les procédés décrits dans la [Fig 3] et la [Fig 4] sont mis en œuvre de façon unique pour l’ensemble des composants élémentaires de la fonction virtualisée.
[0096] Le chargement ou l’installation d’une fonction logicielle associée sur un dispositif programmable d’un serveur d’une zone ou d’un cluster voire la création d’un cluster peuvent être effectués préalablement à l’étape EO, par exemple dans une étape de mise à jour de l’infrastructure virtualisée du réseau de communication, préalablement au besoin d’un composant logiciel associé.
[0097] Les deux modes de réalisation décrits en support des [Fig 3] et [Fig 4] peuvent comprendre deux serveurs distincts dans une zone ou un cluster ou bien un seul serveur de cette zone ou du cluster, ce seul serveur hébergeant un ou plusieurs composants logiciels et une ou plusieurs fonctions logicielles associées.
[0098] Un dispositif programmable n’est pas nécessairement matériel. Le recours à un dispositif programmable matériel représente une famille de solutions comme mentionné dans la description du contexte de l’invention au début de cette description. Une autre famille consiste à déployer des dispositifs programmables logiciels. C’est le cas par exemple pour optimiser le chemin de traitement des paquets au sein du serveur en utilisant des techniques logicielles (par exemple eBPF (en anglais Extended Berkeley Packet Filter) ou DPDK (en anglais Data Plane Development Kit), constituant des dispositifs programmables logiciels.
[0099] Les procédés de détermination d’un groupe de serveurs et de détermination du dispositif programmable décrits en support des [Fig 3] et [Fig 4] sont notamment pertinents dans les environnements ouverts multi-constructeurs. En effet, les procédés permettent de caractériser le dispositif programmable requis pour une fonction logicielle associée à un composant logiciel installé et de s’assurer qu’une zone dans laquelle est déployée un composant logiciel comprend un serveur disposant du dispositif programmable adéquat, assurant un fonctionnement optimal du composant logiciel déchargé de certaines opérations par la fonction logicielle associée.
[0100] On se réfère désormais à la [Fig. 5] qui présente une représentation d’un dispositif de détermination d’un groupe de serveurs selon un exemple.
[0101] Un tel dispositif de détermination d’un groupe de serveurs peut être mis en œuvre dans une entité d’orchestration, comme une entité de type NFVO selon la terminologie NFV, présentée dans les [Fig 2], [Fig 3] et [Fig 4], Ce dispositif de détermination peut ainsi être opéré par une entité de gestion des zones d’une infrastructure virtualisée d’un réseau de communication.
[0102] Par exemple, le dispositif 100 de détermination d’un groupe de serveurs comprend une unité de traitement 130, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 110, stocké dans une mémoire 120 et mettant en œuvre le procédé de détermination d’un groupe de serveurs selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 110 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 130. Un tel dispositif 100 de détermination d’un groupe de serveurs comprend
- un émetteur 101 , adapté pour émettre à destination d’une entité de gestion du composant logiciel une demande Depl de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- un module d’obtention 102, adapté pour obtenir une caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée, déterminée en fonction de l’au moins un paramètre,
- un module 103 de détermination, adapté pour déterminer ledit groupe de serveurs comprenant au moins un premier serveur adapté pour accueillir le composant logiciel et un deuxième serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique obtenue, par exemple reçue dans une demande d’autorisation de déploiement du composant logiciel.
[0103] On se réfère désormais à la [Fig. 6] qui présente une représentation d’un dispositif de détermination d’un dispositif programmable selon un exemple.
[0104] Un tel dispositif de détermination d’un dispositif programmable peut être mis en œuvre dans une entité dans une entité de gestion du composant logiciel tel qu’une fonction virtualisée VNF. L’entité de gestion, selon un exemple, est une entité de type VNFM selon la terminologie NFV, présentée dans les [Fig 2], [Fig 3] et [Fig 4], Ce dispositif de détermination d’un dispositif programmable peut ainsi être opéré par une entité de gestion des fonctions virtualisées d’une infrastructure virtualisée d’un réseau de communication.
[0105] Par exemple, le dispositif 200 de détermination d’un dispositif programmable comprend une unité de traitement 230, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 210, stocké dans une mémoire 220 et mettant en œuvre le procédé de détermination d’un dispositif programmable selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 210 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 230. Un tel dispositif 200 de détermination d’un dispositif programmable comprend
- un récepteur 201 , adapté pour recevoir en provenance d’une entité d’orchestration une demande Depl de déploiement du composant logiciel, ladite demande d’un identifiant du composant logiciel comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- un module 202 de détermination, adapté pour déterminer une caractéristique du dispositif programmable adapté pour accueillir la fonction logicielle associée en fonction de l’au moins un paramètre reçu dans la demande de déploiement.

Claims

Revendications
[Revendication 1] Procédé de détermination d’un groupe de serveurs informatiques (Srv1 , Srv2, Srv3, Srv4) d’un réseau (Res) virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel (VF1 , VF2, C1 , C2,... , C6) contribuant à la fourniture d’un service dans ledit réseau, ledit composant logiciel requérant la mise en œuvre d’une fonction logicielle associée (Acc1 , Acc2, Acc3) de traitement d’une donnée du service, ledit procédé étant mis en œuvre dans une entité d’orchestration (NFVO) et comprenant :
- une émission (E2) à destination d’une entité (VNFM) de gestion du composant logiciel d’une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- une obtention (E4) d’une caractéristique d’un dispositif programmable (DISP) adapté pour accueillir la fonction logicielle associée, déterminée en fonction de l’au moins un paramètre,
- une détermination (E5) dudit groupe de serveurs comprenant au moins un premier serveur adapté pour accueillir le composant logiciel et un deuxième serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique obtenue.
[Revendication 2] Procédé de détermination, selon la revendication 1 , dans lequel l’obtention d’une caractéristique comprend une réception en provenance de l’entité de gestion du composant logiciel d’une demande d’autorisation de déploiement du composant logiciel.
[Revendication 3] Procédé de détermination, selon la revendication 1 ou la revendication 2, comprenant en outre une réservation d’une ressource du deuxième serveur comprenant ledit dispositif programmable.
[Revendication 4] Procédé de détermination selon la revendication 2, comprenant en outre le déploiement par l’intermédiaire d’une entité de gestion du réseau virtualisé de communication de la fonction logicielle sur ledit dispositif programmable du deuxième serveur dont une ressource a été réservée.
[Revendication 5] Procédé de détermination selon l’une quelconque des revendications précédentes comprenant en outre la création d’un groupe de serveurs comprenant au moins un serveur adapté pour accueillir le composant logiciel et un serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique.
[Revendication 6] Procédé de détermination selon l’une quelconque des revendications précédentes dans lequel au moins une caractéristique d’un dispositif programmable est comprise dans les caractéristiques du groupe suivant :
- une taille d’espace mémoire du dispositif programmable,
- un nombre d’unités de traitement du dispositif programmable,
- un type de dispositif programmable,
- un identifiant du dispositif programmable,
- une adresse de téléchargement de la fonction logicielle sur le dispositif programmable.
[Revendication 7] Procédé de détermination selon l’une quelconque des revendications précédentes dans lequel la fonction logicielle est une fonction d’accélération de traitement de la donnée du flux.
[Revendication 8] Procédé de détermination selon l’une quelconque des revendications précédentes comprenant en outre l’émission à une entité de gestion du réseau virtualisé d’un programme informatique de la fonction logicielle associée destiné à mettre à jour le dispositif programmable du deuxième serveur.
[Revendication 9] Procédé de détermination selon l’une quelconque des revendications précédentes dans lequel la demande de déploiement comprend l’émission d’un document comprenant l’identifiant du composant logiciel et l’au moins un paramètre de la fonction logicielle associée, ledit document comprenant en outre une référence à la fonction logicielle associée et une référence à un programme informatique à partir duquel la fonction logicielle associée est rendue compatible avec un type de dispositif programmable.
[Revendication 10] Procédé de détermination d’un dispositif programmable apte à héberger une fonction logicielle associée à un composant logiciel contribuant à la fourniture d’un service dans un réseau virtualisé de communication, ledit dispositif programmable étant mis en œuvre dans un serveur du réseau, le procédé mis en œuvre dans une entité de gestion du composant logiciel comprenant :
- une réception en provenance d’une entité d’orchestration d’une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- une détermination d’une caractéristique du dispositif programmable adapté pour accueillir la fonction logicielle associée en fonction de l’au moins un paramètre reçu dans la demande de déploiement.
[Revendication 11] Procédé de détermination, selon la revendication 10, comprenant en outre une émission à destination de l’entité d’orchestration d’une demande d’autorisation de déploiement du composant logiciel comprenant la caractéristique déterminée.
[Revendication 12] Procédé de détermination selon la revendication 10 ou la revendication 1 1 comprenant en outre, préalablement à l’étape de détermination, une émission d’une demande d’un document descriptif du composant logiciel et une réception dudit document.
[Revendication 13] Procédé de détermination selon l’une des revendication 10 à 12 comprenant en outre la réception d’un message de demande d’installation du composant logiciel sur un premier serveur d’un groupe de serveurs et de demande d’installation de la fonction logicielle sur un dispositif programmable compris dans un deuxième serveur du groupe de serveurs, ledit dispositif programmable étant compatible avec ladite caractéristique déterminée.
[Revendication 14] Procédé de détermination selon l’une des revendication 10 à 13 comprenant en outre l’émission d’un message de demande de déploiement du composant logiciel sur le premier serveur dudit groupe déterminé.
[Revendication 15] Dispositif de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel contribuant à la fourniture d’un service dans ledit réseau, ledit composant logiciel requérant la mise en œuvre d’une fonction logicielle associée de traitement d’une donnée du service, ledit dispositif de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication étant configuré pour :
- émettre à destination d’une entité de gestion du composant logiciel une demande de déploiement du composant logiciel, ladite demande comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- obtenir une caractéristique d’un dispositif programmable adapté pour accueillir la fonction logicielle associée, déterminée en fonction de l’au moins un paramètre,
- déterminer ledit groupe de serveurs comprenant au moins un premier serveur adapté pour accueillir le composant logiciel et un deuxième serveur comprenant ledit dispositif programmable compatible avec ladite caractéristique obtenue.
[Revendication 16] Dispositif de détermination d’un dispositif programmable apte à héberger une fonction logicielle associée à un composant logiciel contribuant à la fourniture d’un service dans un réseau virtualisé de communication, ledit dispositif programmable étant mis en œuvre dans un serveur du réseau, ledit dispositif de détermination d’un dispositif programmable étant configuré pour:
- recevoir en provenance d’une entité d’orchestration une demande de déploiement du composant logiciel, ladite demande d’un identifiant du composant logiciel comprenant un identifiant du composant logiciel et au moins un paramètre de la fonction logicielle associée,
- déterminer une caractéristique du dispositif programmable adapté pour accueillir la fonction logicielle associée en fonction de l’au moins un paramètre obtenu.
[Revendication 17] Système de détermination d’un groupe de serveurs informatiques d’un réseau virtualisé de communication, ledit groupe étant apte à héberger un composant logiciel contribuant à la fourniture d’un service dans ledit réseau, ledit composant logiciel requérant la mise en œuvre d’une fonction logicielle associée de traitement d’une donnée du service, ledit système comprenant :
Un dispositif de détermination d’un groupe de serveurs selon la revendication 15, Un dispositif de détermination d’un dispositif programmable selon la revendication 16.
[Revendication 18] Produit programme d’ordinateur comportant un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par au moins un processeur, configurent ledit au moins un processeur pour mettre en œuvre un procédé de détermination d’un groupe de serveurs selon l’une quelconque des revendications 1 à 9.
[Revendication 19] Produit programme d’ordinateur comportant un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par au moins un processeur, configurent ledit au moins un processeur pour mettre en œuvre un procédé de détermination d’un dispositif programmable selon l’une quelconque des revendications 10
EP24702167.8A 2023-02-06 2024-01-29 Procede de determination d'un groupe de serveurs Pending EP4662551A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2301072A FR3145630A1 (fr) 2023-02-06 2023-02-06 Procédé de détermination d’un groupe de serveurs
PCT/EP2024/052017 WO2024165345A1 (fr) 2023-02-06 2024-01-29 Procede de determination d'un groupe de serveurs

Publications (1)

Publication Number Publication Date
EP4662551A1 true EP4662551A1 (fr) 2025-12-17

Family

ID=86604216

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24702167.8A Pending EP4662551A1 (fr) 2023-02-06 2024-01-29 Procede de determination d'un groupe de serveurs

Country Status (3)

Country Link
EP (1) EP4662551A1 (fr)
FR (1) FR3145630A1 (fr)
WO (1) WO2024165345A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3287897B1 (fr) * 2015-05-19 2024-07-03 Huawei Technologies Co., Ltd. Procédé d'accélération de matériel et dispositif pertinent

Also Published As

Publication number Publication date
WO2024165345A1 (fr) 2024-08-15
FR3145630A1 (fr) 2024-08-09

Similar Documents

Publication Publication Date Title
US9450783B2 (en) Abstracting cloud management
US8271653B2 (en) Methods and systems for cloud management using multiple cloud management schemes to allow communication between independently controlled clouds
US8316125B2 (en) Methods and systems for automated migration of cloud processes to external clouds
US10001821B2 (en) Cloud management with power management support
US8935687B2 (en) Incrementally updating a software appliance
US8862720B2 (en) Flexible cloud management including external clouds
US10678580B2 (en) Methods and apparatus to publish internal commands as an application programming interface in a cloud infrastructure
US11403147B2 (en) Methods and apparatus to improve cloud management
EP3931694B1 (fr) Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
EP3519958A1 (fr) Procédé d'audit d'une ressource virtualisée déployée dans un réseau informatique en nuage
WO2022034273A1 (fr) Procede de traitement d'un service de transport de donnees
EP3991356B1 (fr) Procédé d'allocation de ressources d'une infrastructure de réseau
WO2024165345A1 (fr) Procede de determination d'un groupe de serveurs
EP4367854A1 (fr) Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise
US20200089544A1 (en) Managing computer resources
FR3154829A1 (fr) Procédé de gestion d’un accès à au moins une tâche exécutée par un conteneur instancié dans un premier nœud de calcul d’une première grappe de nœuds par un nœud de calcul appartenant à une deuxième grappe de nœuds.
Camiciola Cloudifying Desktop Applications: Your Laptop is your Data Center
Costa et al. Capi: cloud computing api
Serón Esnal A novel Edge Computing framework for automotive data processing
WO2025114164A1 (fr) Procédé de déploiement d'un service dans un environnement distribué
FR3140229A1 (fr) Procédé, dispositif et système de sélection d’au moins un dispositif apte à héberger un processus d’une application
FR3135543A1 (fr) Procédé, dispositif et système de certification d’une ressource
EP4523388A1 (fr) Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données
CN120216092A (zh) 服务器、服务器系统、虚拟机创建方法及云管理平台

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250901

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR