NETWORK FUNCTION VIRTUALISATION (NFV)
Introduction
La virtualisation des fonctions réseau (NFV) vise à transformer la façon dont les opérateurs de
réseau conçoivent les réseaux en faisant évoluer la technologie de virtualisation informatique
standard pour consolider de nombreux types d'équipements réseau sur des serveurs, des
commutateurs et un stockage à volume élevé standard de l'industrie, qui pourraient être situés
dans une variété de NFVIPoP, y compris les centres de données, les nœuds de réseau et dans les
locaux des utilisateurs finaux.
De nombreux fournisseurs de services proposent des services de cloud computing en plus des
services réseau (agissant alors en tant que fournisseurs de services cloud CSP). Les services de
cloud computing nécessitent des ressources physiques de calcul, de réseau et de stockage. Les
fonctions réseau virtualisées nécessitent des ressources physiques de réseau et de stockage. La
mutualisation des ressources est une caractéristique essentielle du cloud computing selon la
définition du NIST (National Institute of Standards and Technology). La mutualisation des
ressources est également une caractéristique souhaitée de l'infrastructure NFV. Il serait
souhaitable de mutualiser les ressources de réseau et de stockage de manière à ce que des
éléments d'infrastructure communs puissent aider un fournisseur de services à fournir des
services de cloud computing ainsi que des services réseau.
1. Virtualisation des fonctions réseau Infrastructure en tant que service
(NFVIaaS)
Description
Les services de cloud computing sont généralement proposés aux consommateurs selon l'un des
trois modèles de service NIST SP 800146 : Infrastructure as a Service (IaaS), Plateforme as a
Service (PaaS) ou Logiciel as a Service (SaaS). Plus précisément, NIST SP 800146, p. 21 définit
l'IaaS comme la capacité à offrir aux consommateurs des ressources de traitement, de stockage et
de calcul fondamentales. Le consommateur peut ensuite utiliser les ressources fournies pour
exécuter des applications spécifiques dont il a le contrôle. Il ne contrôle pas l'infrastructure sous-
jacente.
Certaines publications font également référence à la capacité d'offrir des services de connectivité
réseau sous le nom de « Network as a Service » (NaaS), mais aucune référence n'a été trouvée
pour une définition normalisée de ce terme. Une application du NaaS semble être la création à la
demande de connectivité réseau entre les CSP et les CSC, bien qu'il puisse également faire
référence à la création à la demande de connectivité réseau au sein des centres de données ou
entre les nœuds de calcul d'une infrastructure de CSP.
Le terme « service » désigne généralement l'acte d'accomplir une tâche utile pour une autre entité,
souvent contre rémunération ou dans le cadre d'une transaction commerciale, ou une
fonctionnalité offerte par un fournisseur de services au consommateur de ce service ; il s'applique
notamment aux réseaux informatiques, logiciels et orientés services. Cependant, il peut
également désigner une fonction exécutée par un logiciel pour une autre entité (logicielle).
L'infrastructure NFV peut être considérée comme offrant la capacité ou la fonctionnalité de
fournir un environnement d'exécution des fonctions réseau virtualisées. La NFVI doit offrir des
capacités de calcul comparables à celles d'un service de cloud computing IaaS (environnement
d'exécution), et prendre en charge les services de connectivité réseau dynamique comparables au
NaaS. Ce cas d'utilisation propose une approche permettant de cartographier les modèles de
services de cloud computing IaaS et NaaS en tant qu'éléments de l'infrastructure de virtualisation
des fonctions réseau (NFV) lorsqu'elle est fournie en tant que service. Des études plus
approfondies pourraient identifier des éléments d'IaaS et de NaaS qui ne sont pas nécessaires à
certains objectifs ou à l'instanciation de
NFVI, mais pour l'instant, il semble approprié de supposer que ces modèles de service peuvent
être utilisés pour fournir certaines des capacités qu'un NFVI peut fournir, comme le montre le
diagramme de la figure 1. Dans le cas d'un fournisseur de services utilisant sa propre
infrastructure NFVI/cloud computing dans un modèle de déploiement de cloud privé, les services
fournis par le NFVI sont fournis à des entités logicielles, c'est à dire des VNF.
Figure 1 : Cartographie de l'IaaS et du NaaS au sein de l'infrastructure NFV
Les ressources à mutualiser entre ces services sont le réseau physique, le stockage et les
ressources de calcul. Dans le modèle NFV, ces ressources sont considérées comme les domaines
de calcul, d'hyperviseur et de réseau de l'infrastructure de virtualisation des
fonctions réseau. Dans le modèle de cloud computing, ces ressources sont considérées comme
des éléments supportant les modèles de services de cloud computing IaaS ou NaaS. Les modèles
de services de cloud computing PaaS et SaaS fournissent des fonctionnalités logicielles qui
doivent s'exécuter sur une infrastructure (éventuellement la même infrastructure que celle offrant
les services IaaS ou
NaaS). Les nœuds de calcul de l'infrastructure NFV seront situés dans des points de présence
NFVI tels que des bureaux centraux, des installations externes, des pods spécialisés ou intégrés à
d'autres équipements réseau ou appareils mobiles. L'emplacement physique de l'infrastructure est
largement indifférent pour les services de cloud computing, mais de nombreux services réseau
présentent un certain degré de dépendance géographique. Le concept de mutualisation des
ressources inclut la notion de multitenant, où un même pool de ressources prend en charge
plusieurs applications issues de différents domaines d'administration ou de confiance. La figure 2
illustre un NFVIaaS prenant en charge à la fois les applications de cloud computing et les
instances VNF de différents domaines administratifs.
Lorsqu'un fournisseur de services (n° 2) exécute des instances VNF sur l'infrastructure
NFVI/cloud d'un autre fournisseur de services (n° 1), cela s'appuie sur un accord de service
commercial entre eux. La figure 3 illustre cet exemple. Le fournisseur de services n° 1 exigera
que seules les entités autorisées puissent charger et exploiter des instances VNF sur son
infrastructure NFV. L'ensemble des ressources (par exemple, capacité de calcul, d'hyperviseur, de
réseau, liaisons aux terminaisons réseau, etc.) que le fournisseur de services n° 1 met à
disposition du fournisseur de services n° 2 sera limité.
Le fournisseur de services n° 2 doit pouvoir intégrer ses instances VNF exécutées sur
l'infrastructure NFV du fournisseur de services n° 1 à une instance de service réseau de bout en
bout , avec des instances VNF exécutées sur sa propre infrastructure NFV. La figure 3 illustre cet
exemple.
Cible de virtualization
L'un des objectifs de la virtualisation est de rendre la NFVI disponible comme environnement
d'exécution pour les entités logicielles. La NFVIaaS doit prendre en charge les services
d'infrastructure nécessaires au cycle de vie opérationnel des instances VNF.
Le NFVIaaS doit également être capable de prendre en charge la création dynamique de
connectivité (par exemple, NaaS) entre les points de terminaison de réseau virtuel et physique
(par exemple, instances VNF, terminaisons de réseau physique). Il doit également être capable de
prendre en charge des charges de calcul génériques (« applications cloud ») sur une base IaaS.
Les services fournis par le NFVIaaS doivent pouvoir être fournis au sein d'un domaine
administratif et/ou audelà des frontières administratives.
Le fournisseur de services n° 1 souhaite proposer une infrastructure NFV en tant que service,
compte tenu des contraintes de capacité et autres limitations, car cette offre commerciale peut
favoriser le déploiement de l'infrastructure NFV. Il doit choisir les conditions de l'offre
commerciale proposée et les ressources spécifiques mises à disposition, mais ces détails
commerciaux ne doivent pas faire l'objet d'une normalisation. L'un des objectifs de la
normalisation devrait être la description des métadonnées des types de ressources NFVI pouvant
être mises à disposition via NFVIaaS.
Le fournisseur de services n° 2 pourrait être intéressé par l'exécution d'une instance VNF sur
l'infrastructure NFV du fournisseur de
services n° 1, en plus de sa propre infrastructure NFV, afin d'améliorer sa résilience. Les
infrastructures NFV des deux fournisseurs de services sont distinctes et indépendantes. Les
pannes sur l'une des infrastructures NFV doivent être indépendantes de celles sur l'autre.
L'exécution d'instances VNF redondantes sur une infrastructure NFV indépendante devrait
permettre au fournisseur de services n° 2 d'offrir un service plus résilient qu'avec sa propre
infrastructure NFV (alors que la virtualisation convertit généralement les pannes d'infrastructure
en réductions de capacité). La virtualisation devrait également cibler des mécanismes de prise en
charge des récupérations après panne sur les infrastructures NFV gérées par différents domaines,
ainsi que des mécanismes de validation de l'indépendance des infrastructures NFV gérées par
différents domaines administratifs.
Le fournisseur de services n° 2 pourrait être intéressé par l'exécution d'une instance VNF sur
l'infrastructure NFV du fournisseur de services n° 1 afin d'améliorer l'expérience client en
réduisant la latence. Cette réduction peut être obtenue en plaçant certaines fonctions réseau à
proximité du consommateur de ce service réseau. Un service CDN réduit la latence (et les coûts)
pour les consommateurs de contenu en mettant en cache ce contenu plus près du consommateur.
Certaines fonctions EPC peuvent réduire la latence et améliorer le débit pour le consommateur
mobile si elles peuvent être localisées plus près du RAN. La cible de virtualisation doit également
cibler des mécanismes de mesure de la latence pour des déploiements spécifiques, ainsi que des
outils de planification permettant de prédire la latence attendue lors des déploiements prévus.
Le fournisseur de services n° 2 pourrait être intéressé par l'exécution d'une instance VNF sur
l'infrastructure NFV du fournisseur de services n° 1 afin de se conformer aux exigences
réglementaires. Certaines autorités de régulation imposent des restrictions géographiques quant
au lieu de stockage et de traitement de certaines informations clients. L'infrastructure NFV du
fournisseur de services n° 1, si elle est située dans la région géographique appropriée, peut
s'avérer pratique pour le stockage et le traitement de ces informations. La virtualisation devrait
également cibler des mécanismes permettant d'identifier et de restreindre les emplacements de
stockage et de traitement des informations.
Coexistence de fonctions réseaux virtualisés et non virtualisés
Les fonctions réseau non virtualisées existeraient en parallèle avec les VNF dans ce cas
d'utilisation, mais ne devraient pas soulever de problème particulier à ce cas d'utilisation.
Les fonctions réseau virtualisées de plusieurs fournisseurs de services peuvent coexister au sein
d'une même infrastructure NFV. Cette infrastructure doit assurer une isolation appropriée entre
les ressources allouées aux différents fournisseurs. Les pannes d'instances VNF ou les demandes
de ressources d'un fournisseur de services ne doivent pas perturber le fonctionnement des
instances VNF des autres fournisseurs de services.
Il sera nécessaire de mettre en œuvre des mécanismes de transfert de paquets IP, Ethernet et
autres pour s'interconnecter et gérer les instances VNF dans l'infrastructure d'un autre fournisseur
de services, ainsi que pour se connecter aux utilisateurs connectés au réseau d'accès d'un autre
fournisseur de services.
2. Fonction de réseau virtuel en tant que service (VNFaaS)
Les réseaux de fournisseurs de services préNFV incluent un routeur Provider Edge (PE) à la
périphérie du cœur, face au périphérique Customer Premises Equipment (CPE), comme illustré
dans la figure 5. Il existe deux modèles commerciaux : le fournisseur de services ou l'entreprise
peut posséder et exploiter le CPE.
La virtualisation de l’entreprise peut inclure :
- Virtualisation des fonctions CPE (vECPE) dans le cloud du fournisseur de services.
- Virtualisation des fonctions PE (vPE) où les fonctions de services de réseau virtuel et les
fonctions PE orientées cœur peuvent être exécutées dans le cloud du fournisseur de
services.
Ces deux étapes sont indépendantes et peuvent être déployées séparément. Les routeurs PE sont
généralement partagés par un grand nombre de clients, tandis qu'un routeur CPE est utilisé
exclusivement par un seul client. Ainsi, les économies d'échelle réalisées grâce à la virtualisation
CPE sont nettement supérieures à celles de la virtualisation PE. Il est donc probable que la
virtualisation du CPE intervienne en premier, offrant ainsi le plus grand avantage aux utilisateurs
professionnels et aux fournisseurs de services.
La virtualisation du PE peut être effectuée à un stade ultérieur pour compléter la transition vers
une solution NFV entièrement virtualisée.
Cible de virtualisation
De nombreuses fonctions réseau sont aujourd'hui généralement déployées dans les réseaux
d'entreprise sous forme d'infrastructures matérielles dédiées, et il pourrait être judicieux, à
l'avenir, qu'un fournisseur de services les fournisse sous forme de VNFaaS. Ces fonctions réseau
d'entreprise comprennent :
- AR Routeur d'accès d'entreprise / CPE d'entreprise
- PE Routeur périphérique du fournisseur
- FW Parefeu d'entreprise
- NGFW Entreprise NGFW
- WOC Contrôleur d'optimisation WAN d'entreprise
- DPI Inspection approfondie des paquets (Appareil ou fonction)
- IPS Système de prévention des intrusions et autres dispositifs de sécurité
- Surveillance des performances du réseau.
Coexistence de fonctions réseaux virtualisés et non virtualisés
Virtualisation partielle
Un modèle de virtualisation combiné consiste à fournir des fonctions de services de réseau virtuel
avec ou sans fonctions CPE (vECPE/PPVPNS vs. PPVPNS dans la figure 9), tout en conservant
les fonctions PE centrales sur le PE. Ce
scénario de décomposition du PE peut être limité aux implémentations monofournisseur, car
l'interopérabilité nécessiterait la standardisation de l'interface entre le PE et les services de réseau
privé virtuel (RPV) fournis par le fournisseur (ce qui peut ne pas être couvert par la NFV).
Virtualisation mixte
La figure 10 démontre la coexistence et l’interopérabilité des fonctions CPE d’entreprise
virtualisées et non virtualisées. Dans la branche supérieure, le vECPE est implémenté dans le
réseau NFV de l'opérateur. Le trafic local de la branche s'étend jusqu'au réseau de l'opérateur et
se termine au vECPE.
La branche inférieure représente une solution héritée fournie par des appliances non virtualisées.
Dans ce cas, le trafic local de l'entreprise reste dans la branche.
Une connectivité transparente est maintenue entre les succursales virtualisées et les succursales
non virtualisées déployant des solutions WAN héritées.
Virtualisation des fonctions réseau – Architecture
La virtualisation des fonctions réseau (NFV) envisage la mise en œuvre de NF sous forme
d'entités purement logicielles fonctionnant sur l'infrastructure NFV (NFVI). La figure 1 illustre le
cadre NFV de haut niveau. Ainsi, trois principaux domaines d'application sont identifiés dans la
NFV :
- Fonction réseau virtualisée, en tant qu'implémentation logicielle d'une fonction réseau
capable de s'exécuter sur le NFVI.
- Infrastructure NFV (NFVI), y compris la diversité des ressources physiques et la manière
dont cellesci peuvent être virtualisées. NFVI prend en charge l'exécution des VNF
- Gestion et orchestration NFV, qui couvre l'orchestration et la gestion du cycle de vie des
ressources physiques et/ou des ressources logicielles qui prennent en charge la
virtualisation de l'infrastructure et la gestion du cycle de vie des VNF. NFV Management
and Orchestration se concentre sur toutes les tâches de gestion spécifiques à la
virtualisation nécessaires dans le cadre NFV.
1. NFVI
L’Infrastructure NFV (NFVI) est un composant clé de l'architecture de virtualisation des
fonctions réseau (NFV) qui décrit les composants matériels et logiciels sur lesquels les réseaux
virtuels sont construits.
NFV définit des normes pour les ressources de calcul, de stockage et de mise en réseau qui
peuvent être utilisées pour créer des fonctions réseau virtualisées.
NFV Infrastructure exploite les économies d’échelle du secteur informatique. NVFI est basé sur
des composants informatiques standardisés, largement disponibles et peu coûteux. Le NFVI
fonctionne avec les serveurs – virtuels, nus ou autres – et les logiciels, hyperviseurs, machines
virtuelles et gestionnaires d'infrastructure virtuelle pour activer la couche physique et virtuelle du
réseau.
Les normes NFVI contribuent à accroître l'interopérabilité des composants de la fonction de
réseau virtuel (VNF) et visent à permettre des environnements multifournisseurs.
2. VNFs
Au cœur de la NFV (virtualisation des fonctions réseau) se trouvent des fonctions de réseau
virtuel (VNF) qui gèrent des fonctions réseau spécifiques telles que les pare-feu ou l'équilibrage
de charge.
Les VNF individuels peuvent être connectés ou combinés comme éléments de base pour créer un
environnement entièrement virtualisé. Les VNF s'exécutent sur des machines virtuelles (VM) au-
dessus de l'infrastructure réseau matérielle. Il peut y avoir plusieurs machines virtuelles sur un
même boîtier matériel utilisant toutes les ressources du boîtier.
3. MANO (Gestion et Orchestration)
De par sa nature, la virtualisation des fonctions réseau (NFV) modifie la façon dont les réseaux
sont gérés.
Il s'agit du cadre défini par l'ETSI pour la gestion et l'orchestration de toutes les ressources dans
un centre de données virtualisé, y compris les ressources de calcul, de mise en réseau, de
stockage et de machine virtuelle (VM). L'objectif principal de NFV MANO est de permettre une
intégration flexible, en évitant le chaos qui peut être associé à une mise en service rapide des
composants réseau.
NFV MANO est découpé en trois blocs fonctionnels :
• NFV Orchestrator : responsable de l'intégration de nouveaux packages de services
réseau (NS) et de fonctions de réseau virtuel (VNF); Gestion du cycle de vie des NS ;
gestion mondiale des ressources; validation et autorisation des demandes de ressources
d'infrastructure de virtualisation des fonctions réseau (NFVI).
• VNF Manager : supervise la gestion du cycle de vie des instances VNF ; remplit le rôle
de coordination et d'adaptation pour la configuration et le reporting d'événements entre
l'infrastructure NFV (NFVI) et les systèmes de gestion d'éléments/réseau.
• Virtualized Infrastructure Manager (VIM) : contrôle et gère les ressources de calcul,
de stockage et de réseau NFVI.
Combiner SDN et NFV
Les technologies NFV et SDN se sont développées en parallèle et font partie d’une même
transformation générale de l’industrie des télécommunications s’inspirant des mutations du
domaine de l’informatique. NFV vise à rendre polyvalents les équipements physiques utilisés en
leur permettant de multiplier les fonctions qu’ils peuvent remplir (chaque fonction devenant un
logiciel plutôt qu’un équipement physique propre) ; SDN vise pour sa part à rendre
programmables l’acheminement et le traitement de flux. Les deux technologies confèrent ainsi
davantage de flexibilité et d’agilité opérationnelle et permettent aux opérateurs d’aller encore
plus facilement audelà de la simple fourniture de connectivité, en développant la fourniture de
services. Au-delà des apports spécifiques de chacune de ces technologies, leur combinaison ouvre
le champ à un enrichissement mutuel. En effet, une mise en œuvre efficace des principes du NFV
suppose l’établissement automatique et flexible de réseaux virtuels reliant les différentes
fonctions virtualisées, ce qui peut être fourni par un contrôleur SDN5. Inversement, établir les
règles d’acheminement des flux via un contrôleur SDN nécessite des fonctions de réseau dont la
réalisation sous une forme virtualisée pourrait apporter des avantages indéniables en termes de
disponibilité, de flexibilité et de tenue en charge. Ainsi il est attendu qu’utilisateurs et
développeurs de ces deux technologies cherchent à promouvoir leur combinaison.