FR 3059796 A1 20180608 FR 1662063 A 20161207 Arrière-plan de l'invention L'invention se situe dans le domaine général de la virtualisation des fonctions dans un réseau de télécommunication. On rappelle que la virtualisation de fonction réseau (en anglais « Neteork Function Virtualisation », VNF) désigne la mise en oeuvre de fonctions logicielles éseeu virtualisées, sur une infrastructure, par exemple en nuage (en anglais « cloud computing »), ces fonctions pouvant fonctionner sur du matériel informatique générique et être instanciées ou déplacées dans divers endroits du réseau en fonction des besoins des 10 opérateurs. La figure 1 représente une architecture définie par l'ETSI (European Telecommunications Standards Institute) dans le cadre du projet « NFV », cette architecture (ci-après « architecture NFV ») étant conforme au modèle réseau de gestion des télécommunications (en anglais « Telecommunication Management Network », TMN) 15 des normes ITU-T M.3010, M.3400. Conformément à cette architecture NFV, des fonctions logicielles virtualisées VNF (en anglais Virtual Network. Function » VNF) s'exécutent sur une infrastructure NFVI (en anglais « NFV Infrastructure », NFVI), par exemple en nuage, composée de ressources matérielles RM de base aptes à mettre en oeuvre par exemple des opérations 20 réseau, des opérations de calcul, de stockage. Chaque fonction logicielle virtualisée VNF est implémentée par un ou plusieurs composants yuc appelé(s) aussi « machine(s) virtuelle(s)». Au niveau fonctionnel, chaque fonction logicielle virtualisée VNF est gérée par un élément de gestion EM (en anglais « Bernent Manager »), ces éléments de gestion EM étant en lien avec des 25 applications e opérationnelles et métier (en anglais « Operational Support System » 0S5 et « Business Support System » BSS). Conformément à cette architecture NFV, le déploiement, l'exécution et l'exploitation des fonctions logicielles virtualisées VNF sont pilotés par des fonctions MANO de gestion et d'exploitation (en anglais «Management and Orchestration », 30 MANO) comprenant - un orchestrateur NFVO (en anglais « NFV Orchestrator »), en interaction avec les applications AP opérationnelles et métier et en charge du cycle de vie des services réseau ; - un gestionnaire VNFM (en anglais « VNF Manager »), en interaction avec les 35 éléments de gestion EM et en charge du cycle de vie des fonctions logicieiir2.s virtualisées VNF ; 3 0 5 9 796 2 - un gestionnaire VIM (en anglais « Virtualized Infrastructure Manager »), en charge de la gestion des ressources matérielles RM de l'infrastructure NFVI. Dans l'état actuel de la technique, lorsqu'une nouveiie ronchon logicielle virtualisée VNF est installée dans le réseau, l'administrateur de cc réseau doii ajouter manuellement un élément de gestion EM dédié à cette fonction. L'invention propose un mécanisme de gestion de la virtualisation d'un réseau qui ne présente pas ces inconvénients. Objet et résumé de l'invention 10 A cet effet, l'invention concerne un procédé de gestion des fonctions logicielles virtualisées dans un réseau de communication. Ce procédé comporte : - une étape de réception d'un modèle de données décrivant la fonctionnalité d'une fonction logicielle virtualisée ; 15 - une étape de génération d'une interface de configuration définissant ladite fonctionnalité, ladite interface étant destinée à être utilisée pour invoquer ladite fonction logicielle virtualisée ; - une étape de génération et d'installation d'un premier agent logiciel qui implémente cette interface de configuration, ce premier agent étant configuré pour permettre, 20 lorsqu'il est invoqué, l'appel d'une machine virtuelle mettant en oeuvre la fonction log iciel le virtualisée. Corrélativement, l'invention concerne un dispositif de contrôle des fonctions logicielles virtualisées dans un réseau de communication. Ce dispositif comporte : - un module de réception d'un modèle de données décrivant la fonctionnalité d'une 25 fonction logicielle virtualisée ; - un module de génération d'une interface de configuration définissant cette fonctionnalité, cette interface étant destinée à être utilisée pour invoquer la fonction logicielle virtualisée ; - un module de génération et d'installation d'un premier agent logiciel qui implémente 30 cette interface de configuration, ce premier agent étant configuré pour pannettre, lorsqu'il est invoqué, l'appel d'une machine virtuelle mettant en oeuvre ladite fonction logicielle virtualisée ; - un module configuré pour, lorsqu'il est appelé pour invoquer ladite fonction logicielle virtualisée, appeler une machine virtuelle mettant en oeuvre la fonction logicielle 35 virtualisée. 3059796 Ainsi, et d'une façon générale, l'invention propose d'enrichir l'architecture SDN pour permettre la gestion de fonctions logicielles virtualisées. On rappelle que l'architecture SDN (en anglais « Software-defined Networking ») propose de découpler les fonctions de contrôle du réseau des fonctions d'acheminement des données à proprement parler, de sorte (i) à permettre le contrôle du réseau par des fonctions logicielles programmables et (ii) à isoler l'infrastructure sous-jacente du réseau des applications et services réseau. Selon la recommandation Y.3300 (« Framework of software-defined networking ») de l'organisme de normalisation ITU-T (en anglais « International Telecommunication Union - Telecommunication »), l'architecture SDN est 10 définie comme un ensembli?, de techniques permettant de programmer, d'orchestrer, de contrôler et de gérer directement les ressources du réseau, ce qui facilite la conception, la fourniture et l'exploitation de services réseau de manière dynamique et évolutive. La couche de contrôle SDN, ou contrôleur SDN (en anglais « SDN contrôle layer ») fournit un moyen pour contrôler dynamiquement le comportement des 15 ressources/éléments du réseau selon les instructions d'une application SDN. Les applications SDN spécifient comment les ressources réseau doivent être contrôlées et allouées, en interagissant avec la couche de contrôle SDN via les interfaces de contrôle d'application NBI (en anglais « North Bound Interface » NBI). Les informations de commande de la couche de contrôle SDN vers les 20 ressources/éléments de réseau sont ensuite délivrées via des interfaces de contrôle de ressources SBI (en anglais « South Bound Interface). La configuration et/ou les propriétés exposées aux applications SDN sont abstraites au moyen de modèles d'information et de données. Cette architecture SDN permet ainsi la mise en oeuvre d'une plateforme logicielle 25 (dite « .plateforme SDN ») programmable et flexible offrant une vue globale et logique du réseau et une gestion dynamique des ressources hétérogènes du réseau. La plateforme SDN est ouverte à un ensemble d'interfaces, notamment .SNMP, Netconf, Openflow et PCEP. Plus précisément, et en référence à la figure 2, l'architecture SDN est structurée 30 en trois couches principales, séparées entre elles par les interfaces SBI, NBI, à savoir : - une couche de ressources réseau constituée par des éléments de réseau NE 1 anglais « Network Elements ») physiques ou virtuels, par exemple des routeurs, commutateurs, réseaux de diffusion de contenus (en anglais «Content Delivery Network CDN) ; 35 - un contrôleur SDN SDN-CTRL comportant des fonctions d'abstraction et de programmation des éléments de réseau NE de la couche de ressources réseau et 3059796 4 offrant des gestionnaire de service de base comme la gestion des noeuds et des liens associés ; - une couche de services applicatifs réseau NAP (en anglais « Network Applications ») comportant un ensemble d'applications de gestion (par exemple de gestion de VPN), da supervision, de connectivité vers une plateforme d'un réseau en nuage. La figure 3A représente schématiquement la technologie orientée-modèle (en anglais « model-oriented ») OpenDaylight proposée par le consortium du même nom, et permettant à un contrôleur SDN de prendre en compte dynamiquement des nouveaux 10 éléments de réseau NE. Plus précisément, lorsqu'un nouvel éément de réseau NE rejoint le réseau, il s'enregistre, au cours d'une étape El, auprès- du contrôleur SDN SDN-CTRL, en lui envoyant, via l'interface SW, un modèle M décrivant sa fonctionnalité. Au cours d'une étape E2, le contrôleur SDN SDN-CTRL génère une interface 15 réseau (à savoir une classe java Network Interface) à partir du modèle M, puis au cours d'une étape E3 un agent NE-P (Network Element Plug-In). Cet agent permet à un module de contrôle 292 du contrôleur SDN SDN-CTRL d'accéder à l'élément de réseau NE et de le contrôler (au cours d'une étape générale E10). 20 La figure 3B représente l'envoi, par un élément réseau NE, du modèle M au contrôleur SDN SDN-CTRL (étape El) et l'installation de l'agent NE-P au niveau de l'interface SBI (étape E3). L'invention propose donc un mécanisme de gestion des fonctions logicielles virtualisés VNF dans un réseau dans lequel ces fonctions logicielles VNF sont gérées selon 25 une approche orientée-modèle (model-driven) et non plus via des éléments de gestion EM statiques créés et installés manuellement par un opérateur humain. Elle étend ainsi la notion de contrôleur SDN à la gestion des fonctions virtualisécs VNF et introduit le nouveau concept de contrôleur VNF (en anglais « VNF controller »). Dans un mode de réalSation' le procédé de gestion selon l'invention comporte en 30 outre: - une étape de génération et d'installation d'un deuxième agent logiciel destiné à être exécuté sur invocation du premier agent logiciel, ce deuxième agent étant apte à sélectionner la machine virtuelle pour gérer la répartition de charge de la fonction logicielle virtualisée. 35 Ce deuxième agent logiciel est ainsi utilisé pour gérer de façon flexible le dimensionnement et la répartition de charge (en anglais « scalability ») de la fonction 3059796 logicielle virlualisée, là où le premier agent logiciel ne gère que la fonctionnalité elle-même de cette fonction virtuelle. On rappelle en effet que la fonction logicielle virtualisée peut être implémentée par une ou plusieurs machines virtuelles, c'est-à-dire par un ou plusieurs composants VNFC. Ainsi, lorsque le gestionnaire VNFM souhaite invoquer une fonctionnalité, il invoque le premier agent pour cette fonctionnalité, ce premier agent invoquant le deuxième agent pour que celui-ci sélectionne une ou plusieurs machines virtuelles en prenant en compte des contraintes de répartition de charge. 10 Dans un mode particulier de réalisation, le deuxième agent est configure pour permettre l'enregistrement des machines virtuelles qui implémentent la fonction virtualisée VNF lorsque celles-ci rejoignent le réseau. Ainsi, dans ce mode particulier de réalisation, l'invention se distingue du mécanisme model-driven en ce qu'elle permet : 15 La gestion dynamique de nouvelles fonctions logicielles virtualisées VNF lorsque celles-ci sont intégrées dans le réseau, par la création automatique du premier agent, par enrichissement de l'architecture SDN ; et La gestion de la flexibilité (scalability) de ces fonctions logicielles virtualisees par le deuxième agent. 20 Les différentes étapes du procédé de gestion des fonctions logicielles virtualisées selon l'invention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur, sur un support d'informations, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de gestion selon l'invention. 25 Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et 30 comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, trel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un 35 disque dur. 3059796 6 D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier teiechargé sur un réseau de type Internet. Alternativement, ie support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève descriptlon des dessins 10 D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 déjà décrite représente l'architecture NFV de l'état actuel de la 15 technique ; - la figure 2 déjà décrite représente l'architecture SDN de l'état actuel de la technique; - les figures 3A et 3B déjà décrites illustrent le mécanisme orienté modèle (« model-driven ») de la technologie OpenDaylight ; 20 - la figure 4A illustre les principales étapes d'un procédé de gestion de fonctions logicielles virtualisées conforme à un mode particulier de réalisation de l'invention ; et - la figure 4B illustre un dispositif de contrôle conforme à un mode particulier de réalisation de l'invention. 25 Description détaillée d'un mode de réalisation de l'invention La figure représente les principales étapes d'un procédé de gestion de fonctions logicielles virtualisées conforme à l'invention. Ce procédé permet d'intégrer la gestion des fonctions logicielles virtualisées VNF dans l'architecture modèle-orienté 30 Opendaylight décrite en référence à la figure 3A. Lorsqu'une nouvelle fonction virtualisée VNF doit être implémentée dans le réseau, cette fonction s'enregistre auprès du dispositif de contrôle (« VNF Controller ») VNF-LIRL conforme à l'invention en lui fournissant un modèle de données M décrivant ses fonctionnalités (étape F1). 35 Au cours d'une étape F2, le dispositif de contrôle Vi.lF-Cl-RL génère une interface de configuration (à savoir une classe java) à partir du modèle M. 3059796 7 Au cours d'une étape F3, le dispositif de contrôle VNP-C ru génère un premier agent VNF-LP (en anglais « VNF-Ievel plugin ») qui implémente l'interface de configuration générée à l'étape F2 et installe cet agent VNF-LP dans le dispositif VNFCTRL. Au cours d'une étape F4, le dispositif VNF-CTRL génère un deuxième agent VNFC-LP (en anglais « VNFC-level p ugin » et installe cet agent VNFC-LP dans le dispositif de contrôle. Ce nouvel agent VNFC-LP gère la répartition de charge de la fonction logicielle virtualisée VNF par la sélection dynamique des machines virtuelles VFNC. Il permet aussi 10 l'enregistrement des machines virtuelles Vr,.FC qu! rejoignent le réseau pour implémenter la fonction virtualisée VNF. Lorsqu'ensuite le dispositif de contrôle VNF-CTRL souhaite invoquer la nouvelle fonction logicielle virtualisée VNF, il utilise l'interface de configuration générée à l'étape F2 qui appelle le premier agent VNF-LP (étape F10). Cet agent VNF-LP appelle le 15 deuxième agent VNFC-LP au cours d'une étape F12 et l'agent VNFC-LP sélectionne une machine virtuelle VFC en fonction de la répartition de charge de la fonction VNF et l'exécute au cours d'une étape F14. La figure 4B représente un dispositif de contrôle VNF-CTRL conforme à l'invention dans son environnement. 20 Ce contrôleur VNF 490 comporte : un module 491 apte à recevoir le modèle de données M émis par une nouvelle fonction virtualisée VNF lorsque celle-ci rejoint le réseau, et à mettre en oeuvre les étapes F2 à F4 déjà décrites pour générer une interface de configuration pour cette fonction, créer et installer les agents VNF-LP et VNFC-LP ; et 25 un module 492 configuré pour, lorsqu'il est appelé par une application AP opérationnelle de la couche OSS/BSS pour invoquer une fonction logicielle virtualisée VNF, invoquer l'agent VNFC-LP généré par le module 491 pour cette fonction. Ces agents VNFC-LP VNFC-LP se substituent ainsi aux éléments de gestion EM définis dans le cadre du projet NFV. 30 Par ailleurs, l'agent VNF-LP installé par re module 491 constitue un gestionnaire VNFM au sens du projet NFV, apte, en interaction avec les agents VNFC-LP, à prendre en charge le cycle de vie de la fonction logicielle virtualisée VNF associée. REVENDICATIONS1. Procédé de gestion des fonctions logicielles virtualisées (VNF) dans un réseau de communication, ledit procédé comportant - une étape (F1) de réception d'un modèle de données (M) décrivant la fonctionnalité d'une fonction logicielle virtualisée (VNF) ; - une étape (F2) de génération d'une interface de configuration définissant ladite fonctionnalité, ladite interface étant destinée à être utilisée (F10) pour invoquer ladite fonction logicielle viduaUsée (VNF) ; 10 - une étape (F3) de génération et d'installation d'un premier agent logiciel (VNF-LP) qui implémente ladite interface de configuration, ledit premier agent étant configuré pour permettre, lorsqu'il est invoqué, l'appel d'une machine virtuelle (VFNC) mettant en oeuvre ladite fonction logicielle virtualisée (VNF). 15 2. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comporte en outre : - une étape (F4) de génération et d'installation d'un deuxième agent logiciel (VNFC-LP) destiné à être exécuté sur invocation dudit premier agent (VNF-LP), ledit deuxième agent (VNF-LP) étant apte à sélectionner (F14) ladite machine virtuelle 20 pour gérer la répartition de charge de ladite fonction logicielle virtualisée. 3. Procédé de gestion selon la revendication 2 caractérisé en ce que ledit deuxième agent est configuré pour permettre l'enregistrement des machines virtuelles (VNFC) implémentant ladite fonction virtualisée VNF (VNF). 25 4. Dispositif (VNF-CTRL) de contra, des fonctions logicielles virtualîsées (VNF) dans un réseau de communication, ledit dispositif comportant : - un module (491) de réception d'un modèle de données (M) décrivant la fonctionnalité d'une fonction logicielle virtuaiisée (VNF) ; 30 - un module (491) de génération d'une interface de configuration définissant ladite fonctionnalité, ladite interface étant destinée à être utilisée (F10) pour invoquer ladite fonction logicielle virtualisée (VNF) - un module (491) de génération et d'installation d'un premier agent logiciel (VNF-LP) qui implémente ladite interface de configuration, ledit premier agent (VNF-LP) étant 35 configuré pour permettre, lorsqu'il est invoqué, l'appel d'une machine virtuelle (VFNC) mettant en oeuvre ladite fonction logicielle virtualisée (VNF) ; 3059796 g - un module (492) configuré pour, lorsqu'il est appelé pour invoquer ladite fonction logicielle virtualisée (VNF), appeler une machine virtuelle (VFNC) mettant en oeuvre ladite fonction logicielle virtualisée (VNF) 5. Dispositif selon la revendication 4, caractérisé en ce qu'il comporte en outre : - un module (491) cic génération et d'installation d'un deuxième agent logiciel (VNFC-LP) destiné à être exr:cuté sur invocation dudit premier agent (VNF-LP), ledit deuxième ugent étant apte à sélectionner (F14) ladite machine virtuelle (VFNC) pour gérer la rç pærÜüondechorge de ladite fonction logicielle virtualisée. 10 6. Dispositif selon la revendication 5 caractérisé en ce que ledit deuxième agent est configure pour permettre l'enregistrement des machines virtuelles (VNFC) implémentant ladite fonction virtualisée (VNF). 15 7. Dispositif selon l'une quelconque des revendications 4à 6, caractérisé en ce que ledit premier agent (VNF-LP) constitue un gestionnaire (VNFM) au sens du projet NFV.