Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

NFV, SDN : comment la virtualisation va modifier en profondeur les réseaux

Du bon et du moins bon
Mobilité 9 min
NFV, SDN : comment la virtualisation va modifier en profondeur les réseaux
Crédits : nadla/iStock

La virtualisation offre un monde de possibilités aux opérateurs pour améliorer leurs réseaux fixes et mobiles. Mais elle a des impacts importants sur les performances, les finances, la sécurité et la souveraineté. L'Arcep dresse un état des lieux.

Dans le cadre de l'analyse des réseaux du futur, l'Arcep s'est penchée sur la voiture connectée (lire notre analyse) et la virtualisation des réseaux fixes et mobiles. Elle est déjà en marche depuis plusieurs années chez au moins un opérateur français. Si elle apporte de la souplesse dans la gestion des ressources, elle n'est pas pour autant exempte de défauts.

Cet état des lieux est le fruit d’un premier cycle d’auditions qui « détaille ces questions afin de permettre l’identification des enjeux qui devront faire l’objet d’une analyse plus approfondie ». Alors qu'il fallait historiquement un équipement pour se charger du contrôle d’accès au réseau, des pare-feux, des routeurs, des passerelles, etc. La virtualisation permet de briser cette association avec des logiciels d'un côté et des serveurs banalisés de l'autre.

La virtualisation en deux mots : NFV et SDN 

Avant d'entrer dans le vif du sujet, il faut comprendre deux notions importantes :

  • NFV (Network Function Virtualization). La capacité de dissocier le matériel du logiciel pour les équipements réseau : plusieurs fonctions réseau peuvent par exemple s’exécuter de manière indépendante sur un même matériel générique. Les fonctions réseau peuvent également migrer d’un matériel à un autre. Ce concept a été introduit en 2012 dans un livre blanc cosigné par treize opérateurs.
  • SDN (Software Defined Networks). La capacité de configurer les équipements réseau à la volée en fonction des besoins de l’application/service au moyen d’un « contrôleur de réseau ».

Bien qu'indépendante l'une de l'autre, leur déploiement se fait généralement en simultané. « 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 », explique le gendarme des télécoms. 

Pour les exploitants des réseaux, il y a un intérêt financier. Ils peuvent « espérer réduire les coûts fixes en s’approvisionnant, en lieu et place d’équipements spécifiques, avec des équipements génériques sur lesquels s’exécuteront des fonctions logicielles ». Mais attention à bien prendre en compte les coûts éventuels des licences logicielles, de leur intégration et de la formation du personnel.

SDN NFV
Crédits : Vividcomm

Problème de la virtualisation : la latence

Le régulateur explique que les « machines virtuelles intègrent leurs propres systèmes d’exploitation et ne permettent généralement pas un accès direct à la ressource physique », elles sont donc légèrement moins réactives qu'une machine physique. Si ce n'est pas problématique pour un ordinateur classique, la chanson est différente avec certaines fonctions réseau ayant des contraintes strictes. 

Une alternative est mise en avant par certains : les conteneurs. Il s'agit d'une « variante miniature de la machine virtuelle qui s’appuie sur une isolation moins étanche entre la machine virtuelle et l’infrastructure physique ». Les conteneurs sont ainsi plus réactifs que les machines virtuelles, mais ils sont plus volatiles : « Contrairement à une machine virtuelle, le container est un micro composant, ce qui induit des risques spécifiques : traçabilité plus complexe, risque de défaillance plus distribué, complexité pour coordonner et orchestrer l’ensemble... ».

Des logiciels open-source... nécessitant des compétences

La bonne nouvelle pour les opérateurs, c'est que de nombreux logiciels utilisés pour la virtualisation « sont disponibles en open-source sous forme de composants logiciels qu’il est nécessaire d’assembler pour créer un équipement réseau virtualisé complet ». Simple et économique en théorie, cette opération demande des compétences particulières pour la mise en œuvre et le suivi.

D'un autre côté, des équipementiers proposent des solutions clés en main avec des licences payantes. Ce genre de service entraine une baisse prévisible des revenus fixes et une hausse de ceux variables. La virtualisation ouvre aussi la porte à de nouveaux acteurs pour entrer en concurrence avec les équipementiers : les spécialistes de la virtualisation et du cloud.

Des sociétés comme VMWare ont ainsi « développé des versions "premium" et optimisées de leurs logiciels pour bénéficier des avantages de la virtualisation (flexibilité, mutualisation) tout en atténuant les inconvénients (diminution des performances, fiabilité amoindrie) ».

Impact sur les opérateurs télécoms

Pour l'Arcep, « la virtualisation des réseaux permettra probablement de réaliser des gains financiers à terme. Toutefois l’ampleur et l’horizon de ces gains restent incertains et dépendants des situations propres et des scénarios retenus ». Il ne faut pas non plus exclure la mise en lumière ultérieure de coûts cachés. 

Et une solution hybride combinant l’intégration de logiciels open-source et des licences achetées aux équipementiers ne semble pas simple à mettre en œuvre : « en pratique cette approche pourrait potentiellement faire perdre aux opérateurs les garanties que les équipementiers leur offrent ».

Ce n'est pas la seule problématique et trois défis opérationnels doivent être pris en compte :  « la requalification de leurs équipes, une possible dégradation de leur qualité de service, et la redéfinition des responsabilités contractuelles en cas de panne sur le réseau ».

Ce dernier point rejoint un peu la problématique des voitures autonomes en cas d'accident : qui est responsable entre le fabricant de la voiture, l'éditeur du logiciel, l'intégrateur, le vendeur, le client, etc. ? 

Network slicing et neutralité du Net

La virtualisation aura un impact important sur la fourniture de service. Elle permet en effet de mettre en place des tranches de réseaux cloisonnées (network slicing) avec des qualités de service différentes. La 5G s'en servira par exemple pour des réseaux avec une latence très faible. 

Sur cette question, l'Arcep soulève la question de la neutralité du Net : « le BEREC n’identifie pas à ce jour le network slicing comme une atteinte à la neutralité du Net en tant que tel, dès lors qu’il est utilisé conformément aux possibilités de différenciation de qualité de service autorisée par le règlement européen sur l’internet ouvert ».

Il appartient aux autorités de régulation de vérifier que ce principe est correctement appliqué. Le problème réside dans la manière de procéder à cette  analyse. L'Arcep évoque une première piste complexe et longue : « la consultation des fichiers de configuration au niveau du contrôleur et de l’orchestrateur, ainsi que la consultation des journaux d’événements réseau ».

Permettre une ouverture à de nouveaux acteurs

Les opérateurs pourront également partager avec des tiers l'accès à leurs infrastructures réseau. Techniquement, les clients pourront « opérer leurs propres réseaux virtuels sur sa plateforme, soit en conservant une certaine maîtrise de l’intelligence de la plateforme (orchestration, contrôle, vision de bout en bout…), soit en se désengageant complètement de l’intelligence et en se confinant à un rôle d’opérateur d’infrastructure ».

Conséquence : de nouveaux opérateurs pourront se lancer en s'appuyant sur un réseau entièrement virtualisé sans détenir la moindre infrastructure physique en propre. Un bon point pour la concurrence, au moins pour les acteurs disposant d’une expertise dans la virtualisation et le cloud.

Pour le régulateur, « le paysage concurrentiel des télécommunications pourrait être profondément modifié »... à condition que les opérateurs jouent le jeu. En effet, « la nécessité d'obtenir un accord d’accès auprès de détenteurs d’infrastructures physiques demeure ».

Cette possibilité de nouveaux acteurs du cloud était déjà clairement mise en avant par Sébastien Soriano lors d'une interview sur l'attribution des fréquences 5G : « On ne peut pas exclure qu'il y ait des acteurs, notamment du cloud, qui puissent se lancer dans cette couche-là. Il y a des mutualisations évidentes, on est dans une couche réseau qui ressemble beaucoup à celle du cloud, on utilise des infrastructures télécom et on gère l'algorithmique, le stockage et la data. C'est beaucoup plus du service informatique que des télécoms en fin de compte ».

Un autre enjeu de la virtualisation est l'interopérabilité, aussi bien à l'intérieur d'un même réseau que pour des interconnexions. « Des travaux de standardisation, menés notamment par l’industrie – par exemple au sein de l’ETSI ou d’organisations/consortiums ad-hoc – et le monde de l’open-source pourraient aider à répondre, techniquement parlant, à cette problématique d’interopérabilité ».

Quatre principaux problèmes sur la sécurité

Tout n'est pas rose pour autant et le gendarme met en garde contre quatre problématiques de sécurité :

  • Création d’un point unique de défaillance (SPOF) due à la centralisation du contrôle des fonctions de réseau
  • Nécessité de garantir l’étanchéité entre applications
  • Augmentation des surfaces d’attaques
  • Hétérogénéité des configurations.

Mais il est également possible que le SDN « permette une meilleure maîtrise des configurations et favorise la modification rapide de celles-ci ». L'élaboration d'un cadre sécurisé fait partie des actions de l'ANSSI

Enfin, dernier point, mais pas des moindres, la question de souveraineté : « Certains opérateurs français pourraient choisir de réaliser certaines de ces activités en dehors du territoire national, soit pour des raisons de coût, soit pour les mutualiser avec les activités similaires de filiales ou de sociétés sœurs exerçant dans d’autres pays ». 

Pour l'instant, la réglementation prévoit que certaines opérations aient lieu sur le territoire national, « notamment la mise en œuvre des moyens nécessaires aux interceptions de correspondances ». La délocalisation pourrait également « avoir un impact sur la capacité de l’État à mettre en œuvre ses capacités en matière de détection de cyberattaques ou de réaction en cas de crise ».

Sans compter que les opérateurs ou leurs partenaires pourraient alors être assujettis à des réglementations étrangères. Pour finir, l'Arcep explique que « ces questions de souveraineté relèvent davantage des compétences notamment du gouvernement (ANSSI et SGDSN entre autres) ».

Orange et Bouygues Telecom sur les rangs

En France, Orange a déjà commencé à virtualiser son réseau depuis plusieurs années : au MWC 2017 par exemple, le FAI exposait déjà certains services virtualisés. Lors d'une interview, Jehanne Savi, responsable mondial du programme « on-demand network », nous affirmait qu'Orange avait virtualisé huit datacenters un peu partout dans le monde en 2016. L'opérateur prévoit d'en déployer quelques dizaines supplémentaires en 2017, dont deux ou trois en France.

L'opérateur était dans une logique de mise à jour, pas de faire table rase du passé : la virtualisation est mise en place lors d'un « changement de matériel en cas de panne, le besoin de déployer des services exploitant la virtualisation, et enfin l'ajout d'un nouveau datacenter pour absorber la croissance du trafic »

À cette époque, Bouygues Telecom nous confirmait avoir « effectivement entamé la préparation de la virtualisation du cœur de réseau, nous commençons par la mise en place de l’infrastructure NFV (NFVi = Network Functions Virtualisation Infrastructure), sur laquelle viendront se poser les applications du cœur de réseau, tout d’abord 4G et ensuite 5G », sans plus de détails.

SFR et Free n'avaient pas répondu à nos sollicitations. 

22 commentaires
Avatar de brazomyna INpactien
Avatar de brazomynabrazomyna- 22/03/19 à 18:03:21

Il n'y a que chez NXI qu'on peut espérer trouver ce genre d'article.

J'adore. Merci.

Avatar de MoonRa Abonné
Avatar de MoonRaMoonRa- 22/03/19 à 18:42:29

SOPF, pu rien

Avatar de spidermoon Abonné
Avatar de spidermoonspidermoon- 22/03/19 à 18:48:03

Avec Nokia, Orange vient de basculer son réseau longue distance dans un mode de fonctionnement softwarisé

Avatar de kgersen Abonné
Avatar de kgersenkgersen- 22/03/19 à 18:59:52

le buzz meter est au max, le bullshit meter aussi (en general les 2 sont liés :) ). J'entend les lobbys des équipementiers et éditeurs de logiciel qui jubilent.

Pendant ce temps, depuis quelque années, la petite ville d'Ammon aux US fait du simple L2 avec vlan sur son réseau fibre pour permettre la concurrence des opérateurs, le choix des services (internet chez X, TV chez Y, telephone chez Z) et meme a 2 particuliers de relier leur maisons ...

Imaginer ca : un simple portail web et on choisi ses opérateurs internet fibre et on peut en changer en quelques secondes sans rien débrancher...et sans la complexité et le bullshit technique que l'article décrit.

Avatar de Sym INpactien
Avatar de SymSym- 22/03/19 à 21:03:19

En fait y'a deux volet dans le "SDN" :

  • la configuration à la volé des équipements déjà installés. Et là ton exemples est le bon je pense. On peut faire cela depuis deux décennies avec une simple page WEB et deux scripts à la con (j'ai fait aussi, je confirme, EXPECT cela déchire depuis 20 ans)

  • la configuration automatique des équipements sortant du carton. Et LA par contre on parle de la partie en dure. L'idée est que avec le renouvellement massif du réseau lié au THD, la dissémination dans le réseau de certain équipements avant concentrés dans des "datacenter" il est plus simple d'envoyer un technicien spécialiste en cablage courant fort et courant faible (déjà pas si simple à trouver) que le spécialiste MPLS/BGP/ autres sur chacun des 15 000 NRA/NRO de france.

    Pour le NFV, pas de commentaire, là je pense que l'on est dans le "HYPE WOLRD" pour la simple virtualisation de fonction comme on a fait en info serveurs depuis 10 ans maintenant.

    Ou alors pour le NFV y'a un truc que j'ai vraiment pas compris.

Avatar de KP2 Abonné
Avatar de KP2KP2- 23/03/19 à 09:35:11

kgersen a écrit :

le buzz meter est au max, le bullshit meter aussi (en general les 2 sont liés :) ). J'entend les lobbys des équipementiers et éditeurs de logiciel qui jubilent.

Pendant ce temps, depuis quelque années, la petite ville d'Ammon aux US fait du simple L2 avec vlan sur son réseau fibre pour permettre la concurrence des opérateurs, le choix des services (internet chez X, TV chez Y, telephone chez Z) et meme a 2 particuliers de relier leur maisons ...

Imaginer ca : un simple portail web et on choisi ses opérateurs internet fibre et on peut en changer en quelques secondes sans rien débrancher...et sans la complexité et le bullshit technique que l'article décrit.

Ouais mais là, on parle pas de réseaux avec qq dizaines de routeurs ni même qq centaines de routeurs. On parle de réseaux avec des dizaines ou centaines de milliers d'équipements réseaux très variés...
C'est pas du tout la même échelle et je vois pas où est le bullshit.

La virtualisation de serveurs a révolutionné les infras techniques des entreprises quelque soit leur taille et on voit même de plus en plus de particuliers enthousiastes jouer avec. La virtualisation du réseau était une suite logique même si ça ne s'applique pas à tout et à tout le monde.

Avatar de patos Abonné
Avatar de patospatos- 23/03/19 à 10:25:11

Sym a écrit :

Pour le NFV, pas de commentaire, là je pense que l'on est dans le "HYPE WOLRD" pour la simple virtualisation de fonction comme on a fait en info serveurs depuis 10 ans maintenant.

Ou alors pour le NFV y'a un truc que j'ai vraiment pas compris.

Oui et non.
 
Pour ma part, la partie intelligente du NFV est de rapprocher le paquet pour être traité lentement par du CPU au lieu d'être passé dans un goulot.
De plus, la plupart du temps, le CPU consommé est du CPU IDLE.
Ce sera parfait lorsque nous aurons des ASIC PCIe dédiés au réseau, avec sa propre VM.

Exemple de NFV:
Tu as 8 serveurs hôtes de virtualisation chargés à 20% chacun, répartis dans 2 salles (l'installation est de type metro-cluster). Sur ces 8 serveurs, tu installes un switch NFV (voir 2 en VRRP sur le même hôte) qui va permettre que les paquets pour deux serveurs du même hôte n'aient pas à sortir de l'hôte (certaines cartes réseau font ça: coucou Intel série X).Ce switch NFV est en LACP avec deux autres switchs (un dans chaque salle) avec une sortie au plus proche.
En face, tu as deux switchs type 10G/100G stackés 100G (donc vus comme un seul switch) . Ces switchs vont également au plus proche dans le LAGs. Le tout (switch + switch NFV) est configuré par un orchestrator
Au final, ce que tu gagnes:

  • de la redondance sur la partie NFV
  • de la redondance sur les switchs très cher sans en acheter 2 par salles, ni acheter des switchs un poil moins cher pour les connecter aux switchs cher, en rajoutant donc de la complexité au truc.
  • tu économises un maximum ton lien 100G entre les 2 switchs
  • tes switchs bossent moins, sont plus réactifs
  • c'est moins compliqué à gérer (donc moins de personnel également)
  • tu peux mixer ton iSCSI avec ton LAN avec un simple VLAN et une QoS sans aucune complexité ni perte de performance. Si tu fais du vSAN, tu peux également le mixer sans problème. Les performances du merdier sont folles.
  • tu n'as de point de panne unique que pour la configuration, que tu peux d'ailleurs faire à la main. Le chef d'orchestre porte ici mal son nom: il n'est qu'un distributeur de procédure et en contrôle le déroulement: son absence n'empêche rien du fonctionnement du réseau, en toute sécurité. C'est d'ailleurs souvent une simple VM que tu peux restaurer (attention aux modifications d'ordres donnés entre temps).

Au final, tu as des économies (ton patron te remercie), un ensemble plus simple (tes collègues te remercient), un fonctionnement plus que satisfaisant (tes utilisateurs te remercient) et une redondance de partout (tu te remerciera quand tu auras un équipement HS).
 

Avatar de Tophe Abonné
Avatar de TopheTophe- 23/03/19 à 11:13:37

Sym a écrit :

 Pour le NFV, pas de commentaire, là je pense que l'on est dans le "HYPE WOLRD" pour la simple virtualisation de fonction comme on a fait en info serveurs depuis 10 ans maintenant.

Ou alors pour le NFV y'a un truc que j'ai vraiment pas compris.

Avec une grosse difference: ce n'est pas une virtualisation "standard" dans le sens où les ressources doivent être dédiées: tous ces VNFs, parce qu'ils utilisent exclusivement le CPU, (pas de HW dédié, seule la crypto arrive doucement), ont en gros 250cycles pour traiter 1 packet. (Hypothèse de base pour 1 interface 10Gb: 14M packets / seconde, coeur qui tourne à  3,5GHz).

Le point que tout le monde oublie ici est la possibilité d'avoir plusieurs vendeurs, avec plusieurs orchestrateurs.
Pour de l'orchestration réseau, un opérateur pouvait prendre 1 fournisseur (Cisco, Juniper, E///, Nokia, ...) pour tout ou une partie des services (Fixe, mobile, coeur de réseau) ; cependant, ces différents services étaient gérés de manière indépendante, et manuelle. Pas d'integration, ou d'automatisation.

En effet, c'est une rationalisation du materiel: au lieu d'avoir 1 serveur dédié par fonction, c'est une VM avec des resources dédiées, qui est – en théorie – capable de faire tourner n'importe quelle fonction (FW, DPI, CGNAT, BNG, EPC, ... ), et cela permet de fournir des fonctions au plus proche du besoin et/ou distribuer les fonctions pour avoir un moindre impact en cas de problème.
Par exemple, si il y a une coupure d'alimentation dans un PoP, on peut repartir les VNFs dans d'autres PoPs tant que le problème persiste.
 
Cependant, atteindre le niveau de performance requis requiert l'utilisation de vswitchs accélérés (DPDK, par de kernel) ou directement d'interfaces physiques (SRIOV, VF), ce qui peut grandement limiter, les possibilités existantes pour de la live migration par exemple (difficile quand tu as des hugespages, impossible aujourd'hui avec un device physique, comme une carte réseau).

Bref, plein de choses qui n'ont rien a voir avec la virtualisation de papy.

patos a écrit :

  
Pour ma part, la partie intelligente du NFV est de rapprocher le paquet pour être traité lentement par du CPU au lieu d'être passé dans un goulot.
De plus, la plupart du temps, le CPU consommé est du CPU IDLE.
Ce sera parfait lorsque nous aurons des ASIC PCIe dédiés au réseau, avec sa propre VM.

Pas avec du DPDK: qu'il y ait des packets ou non, le CPU est en boucle active, et est dédié pour ca !
Des qu'on est dans le data path, ca bouffe 1 ou plusieurs coeurs, avec le Turbo Boost désactivé et pas d'économie d'énergie.
 
Les ASIC PCIe dédiés aux réseaux existent deja, voir les carte Mellanox Connect X5 ou Netronome qui supportent TC Flower [1] pour OpenvSwitch[2].
Cependant, ces implementations ont leur limites. Pour le full offload, ce n'est pas encore en PoC, les cartes sont toujours en dev, et l'integration commence à peine.
 
De plus, ces integrations complexifient le déploiement et l'orchestration, on n'est pas encore certain des perfs, et on remet en place une dependance sur du materiel spécifique (et donc les problèmes de certification inhérents ), sans compter que ca ne supporte pas la live migration.

[1]&nbsphttps://www.netdevconf.org/2.2/papers/horman-tcflower-talk.pdf 
[2]&nbsphttps://open-nfp.org/s/pdfs/dxdd-europe-ovs-offload-with-tc-flower.pdf

Avatar de OB Abonné
Avatar de OBOB- 23/03/19 à 11:48:15

kgersen a écrit :

Imaginer ca : un simple portail web et on choisi ses opérateurs internet fibre et on peut en changer en quelques secondes sans rien débrancher...et sans la complexité et le bullshit technique que l'article décrit.

"L’Education Populaire, monsieur, ils n’en ont pas voulu !" :-)

Le réseau FTTH a été spécifiquement conçu pour que ce que tu décrit soit impossible. 
Il faut absolument limiter le churn, le nombre de FAI, garder le principe des box & des offres intégré, garder des barrières à l'entré,...

 
Après il y a UN inconvénient à la solution présenté: Ca revient à un accès activé, sur lequel les FAI (ou autres fournisseurs de services) n'ont pas de visibilité.
Par exemple, à Pau et dans l'Ain, l'activé est à 100Mbps. Pour évoluer il faut remplacer tous l'actif, chez les particuliers. Et rebelotte plus tard. Et quid si un FAS veux passer par exemple de la TV en overlay sur les fibres ?
Ne te méprends pas, je trouve, bien sur, cette solution (utilisé aussi à Oslo il me semble) largement plus ouverte & efficace que la solution française de refaire un réseau téléphonique en verre. Simplement, il faut bien préparer la solution technique...
 

Avatar de Ubik! Abonné
Avatar de Ubik!Ubik!- 23/03/19 à 12:03:49

Merci pour ce complément d'information :chinois:

Il n'est plus possible de commenter cette actualité.
Page 1 / 3
  • Introduction
  • La virtualisation en deux mots : NFV et SDN 
  • Problème de la virtualisation : la latence
  • Des logiciels open-source... nécessitant des compétences
  • Impact sur les opérateurs télécoms
  • Network slicing et neutralité du Net
  • Permettre une ouverture à de nouveaux acteurs
  • Quatre principaux problèmes sur la sécurité
  • Orange et Bouygues Telecom sur les rangs
S'abonner à partir de 3,75 €