FR 3145630 A1 20240809 FR 2301072 A 20230206 Procédé de détermination d’un groupe de serveurs 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 œuvre 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, C1) et un deuxième serveur (Srv2) comprenant ledit dispositif programmable (DISP) compatible avec ladite caractéristique obtenue. Figure de l’abrégé : Figure 2 Procédé de détermination d’un groupe de serveurs 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. 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. 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. 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). 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 . 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. 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 Ironic). 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 Ironic)). 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 é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. 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. 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 et é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. 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. 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. 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. 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. 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 : : une représentation schématique d’un réseau de communication composé de fonctions virtualisées, : une représentation schématique d’un procédé de détermination d’un groupe de serveurs mis en œuvre dans une architecture NFV, : 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, : 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, : une représentation d’un dispositif de détermination d’un groupe de serveurs selon un exemple, : une représentation d’un dispositif de détermination d’un dispositif programmable selon un autre exemple. 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. 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. 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. On se réfère tout d’abord à la 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 Term1. 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. 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 , 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. 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. 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 ). 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 ), ou un serveur distant (Srv 2 pour Srv1 ou Srv3 pour Srv4 dans la , 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 ). 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. 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. On se réfère ensuite à la 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 ) 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. 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. 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. Parmi les quatre options possibles (Srv1, Srv10, Srv11, 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. 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. 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. On se réfère ensuite à la 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. Lors d’une étape E0, 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 E0, 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. 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. 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. 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. 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. 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. Il 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. Lors d’une étape E4, le VNFM 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. 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. 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. 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. 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 Selon un exemple, lors d’une étape E8, le NFVO transmet au VNFM 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. 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. 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. 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 . 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 , 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. 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 E0, c’est-à-dire avec l’assistance de la fonction logicielle associée. On se réfère ensuite à la 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. Les étapes E0 à E4 de la sont comparables à celles de présentées dans la et sont indépendantes du type de virtualisation mis en œuvre dans le réseau de communication. 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. 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. 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. 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. 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. Si un nouveau cluster est créé, conformément aux étapes E51 à E55 décrites ci-dessus, les étapes E0 à 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. 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. Lors d’une étape E8, selon un exemple, le NFVO transmet au VNFM 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 VNFM 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. 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. 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. 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 . 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 E0. Selon un exemple non représenté sur la , 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. Dans le cas d’un composant logiciel mis en œuvre dans un conteneur, selon le mode de réalisation de la , 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. 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. 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. 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. 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. 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 et la 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 et la sont mis en œuvre de façon unique pour l’ensemble des composants élémentaires de la fonction virtualisée. 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 E0, 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é. Les deux modes de réalisation décrits en support des et 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. 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. Les procédés de détermination d’un groupe de serveurs et de détermination du dispositif programmable décrits en support des et 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. On se réfère désormais à la qui présente une représentation d’un dispositif de détermination d’un groupe de serveurs selon un exemple. 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 , et . 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. 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 μP, 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. On se réfère désormais à la qui présente une représentation d’un dispositif de détermination d’un dispositif programmable selon un exemple. 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 , et . 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. 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 μP, 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Procédé de détermination selon la revendication 10 ou la revendication 11 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. 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. 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é. 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 é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. 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 et é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. 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. 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. 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 à 14.