L’architecture NFV repose sur un cadre de gestion et d’orchestration baptisé MANO (Management and Orchestration), défini par l’ETSI. Ce cadre se décompose en trois blocs fonctionnels distincts : le NFV Orchestrator, le VNF Manager et le Virtualized Infrastructure Manager. Comprendre leur périmètre respectif et leurs interactions permet de mesurer ce que chaque bloc contrôle réellement dans une infrastructure virtualisée.
Tableau comparatif des trois blocs fonctionnels de NFV MANO
Avant d’analyser chaque bloc en détail, un aperçu synthétique de leurs responsabilités, de leur périmètre d’action et de leurs interfaces facilite la lecture de l’architecture globale.
A lire aussi : Quels outils pour mesurer la performance ?
| Bloc fonctionnel | Abréviation | Périmètre principal | Objets gérés | Interaction directe |
|---|---|---|---|---|
| NFV Orchestrator | NFVO | Services réseau, coordination multi-domaines | Network Services, VNFFG | VNFM, VIM, OSS/BSS |
| VNF Manager | VNFM | Cycle de vie des fonctions réseau virtualisées | VNF individuelles | NFVO, VIM |
| Virtualized Infrastructure Manager | VIM | Ressources de calcul, stockage et réseau | Machines virtuelles, conteneurs, réseaux virtuels | VNFM, NFVO, NFVI |
Ce découpage reste un modèle fonctionnel. Les implémentations modernes peuvent regrouper plusieurs de ces responsabilités dans une même plateforme, notamment lorsque l’infrastructure s’appuie sur Kubernetes.
A découvrir également : Quels sont les métiers les mieux payés dans l'informatique ?
NFV Orchestrator : coordination des services réseau et allocation des ressources
Le NFVO occupe le sommet de la pile MANO. Son rôle premier est d’orchestrer les services réseau de bout en bout, c’est-à-dire de coordonner l’assemblage de plusieurs VNF pour former un service complet (par exemple, un chaînage pare-feu, routeur, équilibreur de charge).
Gestion du graphe de chaînage VNFFG
Le NFVO pilote le Virtual Network Function Forwarding Graph (VNFFG). Ce graphe décrit l’ordre dans lequel le trafic traverse les différentes fonctions virtualisées. Sans cette coordination, chaque VNF fonctionnerait de manière isolée, sans logique de service.
Le NFVO gère aussi l’allocation des ressources à l’échelle de plusieurs domaines. Quand un service réseau nécessite des VNF réparties sur des sites géographiques distincts, c’est l’orchestrateur qui arbitre la distribution des ressources entre les différents VIM concernés.
Interface avec les systèmes OSS/BSS
Le NFVO expose des interfaces vers les systèmes de support opérationnel (OSS) et de support commercial (BSS) de l’opérateur. Cette connexion lui permet de traduire une demande commerciale (activation d’un service client) en opérations concrètes sur l’infrastructure virtualisée.
En revanche, le NFVO ne gère pas directement le cycle de vie d’une VNF individuelle. Il délègue cette responsabilité au VNF Manager via des interfaces standardisées.
VNF Manager : cycle de vie des fonctions réseau virtualisées
Le VNFM administre chaque VNF de sa création à sa suppression. Son périmètre couvre l’ensemble des opérations qui touchent une fonction réseau virtualisée en tant qu’entité logicielle.
Les opérations prises en charge par le VNFM incluent :
- Instanciation et configuration initiale de la VNF, à partir d’un descripteur qui spécifie les ressources nécessaires et les paramètres de déploiement
- Mise à l’échelle (scaling) horizontale ou verticale, pour adapter la capacité de traitement à la charge réseau
- Auto-guérison (healing), qui détecte une défaillance et relance ou remplace automatiquement l’instance concernée
- Suppression ordonnée de la VNF lorsque le service n’est plus requis
Un point souvent sous-estimé : plusieurs VNFM peuvent coexister dans une même architecture. Un VNFM générique peut gérer des VNF standards, tandis qu’un VNFM spécifique, fourni par l’éditeur de la VNF, prend en charge des fonctions réseau qui exigent une logique de gestion propriétaire.
Le VNFM communique vers le haut avec le NFVO (pour recevoir les ordres d’orchestration) et vers le bas avec le VIM (pour obtenir les ressources d’infrastructure nécessaires à chaque opération).
Virtualized Infrastructure Manager : gestion des ressources de calcul, stockage et réseau
Le VIM constitue la couche la plus basse de MANO. Il contrôle et pilote les ressources matérielles virtualisées sur lesquelles s’exécutent les VNF : puissance de calcul, espace de stockage et connectivité réseau.
Un rôle comparable à celui d’un hyperviseur étendu
Le VIM supervise l’infrastructure NFV (NFVI). Dans les déploiements classiques, OpenStack a longtemps occupé ce rôle. Le VIM alloue les machines virtuelles, configure les réseaux virtuels et surveille la consommation des ressources.
Le VIM remonte des informations de performance et de capacité au NFVO et au VNFM. Ces données permettent à l’orchestrateur de prendre des décisions de placement (sur quel site déployer une nouvelle VNF) et au VNFM de déclencher un scaling ou un healing.
Vers une gestion cloud-native avec Kubernetes
L’évolution récente montre un glissement du VIM traditionnel vers des plateformes cloud-native. Les fonctions réseau ne s’exécutent plus uniquement dans des machines virtuelles, mais aussi dans des conteneurs, sous forme de CNF (Cloud-native Network Functions). Kubernetes devient alors le gestionnaire d’infrastructure, remplaçant ou complétant le VIM classique.
Le projet ETSI Open Source MANO a renforcé la prise en charge des clusters Kubernetes, de l’auto-scaling et d’un cadre de gestion fondé sur des approches déclaratives de type GitOps. Ce déplacement modifie la nature du VIM sans supprimer sa fonction : gérer les ressources d’infrastructure reste nécessaire, quel que soit le modèle d’exécution.
Interactions entre NFVO, VNFM et VIM : où se situent les écarts fonctionnels
La séparation en trois blocs crée des interfaces précises, mais aussi des zones de friction. Le NFVO a besoin d’une vision globale des ressources disponibles, que seul le VIM peut fournir. Le VNFM, lui, doit traduire une demande de scaling en requêtes concrètes vers le VIM, tout en respectant les contraintes posées par le NFVO.
En pratique, les écarts entre le modèle ETSI et les implémentations réelles se concentrent sur deux points :
- La frontière entre NFVO et VNFM devient floue quand une plateforme unique gère à la fois l’orchestration et le cycle de vie des VNF
- Le VIM perd en autonomie lorsque Kubernetes absorbe la gestion des conteneurs, des volumes de stockage et des réseaux overlay, centralisant des fonctions qui relevaient auparavant du VIM seul
- Les déploiements hybrides (VNF dans des VM et CNF dans des conteneurs) obligent parfois à maintenir deux couches de gestion d’infrastructure en parallèle
Ces écarts ne remettent pas en cause la pertinence du modèle à trois blocs. Ils montrent que MANO est un cadre d’architecture, pas une spécification d’implémentation figée. Chaque opérateur ou fournisseur de services adapte la répartition des responsabilités à sa pile technologique et à ses contraintes opérationnelles.
Le modèle NFVO, VNFM, VIM reste la grille de lecture la plus opérationnelle pour analyser une architecture NFV. L’arrivée des conteneurs et des approches cloud-native redistribue les cartes entre ces blocs, sans en supprimer aucun.
