Vous êtes sur la page 1sur 6

SDN/NFV, une approche hybride

Xavier Jeannin
RENATER
23-25 rue Daviel
75013 Paris

Frédéric Loui
RENATER
23-25 rue Daviel
75013 Paris

Résumé
Le concept de SDN (Software Defined Networking) repose sur un découplage entre le plan de
commutation local aux équipements réseaux et le plan de contrôle qui devient déporté, autorisant une
gestion centralisée du réseau. La conséquence majeure est que le réseau devient programmable et peut
être couplé aux applications métiers des usagers.
Network Functions Virtualization (NFV) propose d’extraire les fonctions réseaux des équipements dédiés
et de les faire fonctionner dans un environnement virtualisé. Pour les opérateurs réseau, NFV constitue
une opportunité de proposer des services de manière plus agile, capable de fonctionner à des échelles
extrêmement importantes, mais surtout de manière plus rapide en exploitant les propriétés intrinsèques à
la virtualisation.
Certains services assurant des fonctions particulières peuvent donc être concentrés sur certains points en
périphérie du réseau comme la fonction de suppression des DDOS. Le trafic des usagers nécessite par
conséquent de pouvoir être dérouté de son chemin et envoyé au travers de ces services pour traitement
spécifique : on parle ainsi de chainage de service ou « Service Chaining ». Dans une optique de
standardisation, l’IETF a constitué un groupe de travail relatif au « Service Chaining » dont le concept
repose fortement sur SDN et NFV.
Les data-centers mettent déjà en place ce type de services pour leurs usagers. Dans le domaine du WAN,
les contraintes sont différentes et, si elles ne sont pas encore totalement résolues, elles sont déjà
partiellement traitées par les techniques d’interconnexion de data-centers et notamment Ethernet VPN.

Mots-clefs
NFV, SDN, Service Function Chaining

1 Introduction
Les réseaux des opérateurs sont composés d’équipements propriétaires ayant des fonctions diversifiées
(accélérateur WAN, pare-feu, routeur PE, cache, carrier-grade NAT…). Compte-tenu de leurs
spécialisations et de leurs capacités à travailler à l’échelle d’un réseau d’opérateur, les coûts liés à
l’acquisition (CAPEX) et à la maintenance (OPEX) de ces équipements sont considérables. Ces machines
fonctionnant en environnement propriétaire sont onéreuses à maintenir par les équipes de production,
mais sont surtout très peu flexibles.
Une des conséquences de ce modèle de déploiement est l’enfermement de l’utilisateur dans une solution
propriétaire, ce qui a considérablement freiné l’innovation ouverte en matière de réseau qui se concentrait
surtout chez les industriels. Le concept de « Software-Defined Networking » (SDN), qui se situe à contre-
courant du mouvement dans lequel les industriels donnaient le « La », a levé ce frein. Au SDN s’ajoute le

JRES 2015 - Montpellier 1/6


concept de « Network Functions Virtualization » (NFV) qui marque l’arrivée de la virtualisation de
fonctions réseaux dans le monde des télécommunications.
L’avènement de ces deux concepts ouvre de nouvelles opportunités d’architectures afin de rationaliser les
coûts opérationnels selon de nouveaux paradigmes et développer de nouveaux services aux utilisateurs.
Le mode de déploiement de ces nouveaux services doit permettre une grande flexibilité et une montée en
charge très importante, tout en maintenant un TCO1 raisonnable.

2 Définitions

2.1 Software Defined Networking


Il existe de nombreuses définitions de SDN. Nous en proposons une sans volonté d’être le plus pertinent
possible, mais simplement pour éviter les ambiguïtés dans le reste de cet article : le concept SDN est une
approche qui consiste à séparer le plan de commutation et le plan de contrôle. Le plan de contrôle peut
être déporté, permettant ainsi une centralisation de ce dernier. Le réseau est ainsi séparé en deux
couches :
 le plan de contrôle centralisé supervise et contrôle le réseau par le biais d’un protocole de
programmation d’interfaces des éléments physiques de l’infrastructure du réseau. Cette fonction
est assurée par le contrôleur SDN ;
 le plan de commutation, composé d’éléments physiques, réalise la commutation effective des
paquets conformément aux décisions prises au niveau du plan de contrôle.
La conséquence majeure est que le réseau devient programmable et peut être couplé aux applications
métiers des usagers. On peut donc ajouter une dernière couche, la couche applicative :
 la couche applicative comprend les applications des utilisateurs et interagit avec le plan de
contrôle pour mobiliser les ressources réseau lui apportant une meilleure efficacité.
L’idée d’une gestion centralisée des réseaux n’est pas une idée révolutionnaire. Le concept de « Path
Computation Element », qui permet de calculer les chemins MPLS (« Label Switched Path » ou LSP) de
manière centralisée et de distribuer ces LSP sur les routeurs, existe depuis des années mais ne s’était pas
imposée. Si l’idée n’est pas neuve, elle bénéficie d’un nouvel élan en matière d’innovation et elle est riche
en nouveaux développements.

2.2 Network Functions Virtualization (NFV)


La virtualisation de fonctions réseaux (« Network Functions Virtualization » ou NFV) propose d’extraire
les fonctions réseaux des équipements dédiés pour les faire fonctionner dans un environnement virtualisé.
Pour les opérateurs réseaux, NFV constitue une opportunité pour proposer des services de manière plus
agile, capables de fonctionner à des échelles extrêmement importantes, mais surtout de les déployer de
manière plus rapide en exploitant les propriétés intrinsèques à la virtualisation.

2.3 Virtual Function Network (VNF)


« Virtual Function Network » (VNF) désigne les différentes fonctions réseaux virtualisables. Les
fonctions purement « plan de contrôle », faisant appel à l’utilisation intensive du CPU et de la mémoire,
représentent de bons candidats pour être « NFV-isées ». La fonction de « réflexion de route BGP » (route
réflecteur) par exemple, peut être centralisée sur une ou plusieurs machines virtuelles. De même, la
disponibilité d’un CPE2 virtuel permettrait de simplifier le déploiement de nouveaux services au plus

1
« Total Cost of Ownership », ou coût de possession total.
2
« Customer Premises Equipment » : il s’agit de l’équipement placé, chez l’abonné, en interface avec le réseau de l’opérateur.

JRES 2015 - Montpellier 2/6


proche des utilisateurs. Il existe un grand nombre de fonctions réseaux virtualisables, certaines le sont
déjà et sont même au catalogue des constructeurs comme le route réflecteur virtuel.
La virtualisation des fonctions réseaux peut être employée pour les services réseaux de l’opérateur : route
réflecteur, OSS/BSS, NMS, CGNAT... La virtualisation peut également être employée pour d’autres
services réseaux, comme des services dédiés spécifiquement à certains utilisateurs : « DDOS mitigation »,
pare-feu, service de chiffrement, CPE virtuel, NAT, partage de charge…

Figure 1 : fonctions réseau virtualisables

3 Bénéfices de NFV et SDN


Les bénéfices de la virtualisation de fonctions réseaux sont nombreux :
- la réduction du TCO : le route réflecteur, par exemple, n’a pas besoin des caractéristiques d’un
routeur. En termes de TCO, une NFV (par exemple un service de pare-feu) peut s’adapter
facilement à l’évolution de la demande. C’est particulièrement intéressant au lancement du
service où on n’est pas obligé d’immobiliser un fort investissement sans connaitre l’évolution
ultérieure ;
- la virtualisation offre une grande souplesse et élasticité pour le déploiement ;
- à la réduction des coûts de mise en place (CAPEX) s’ajoutent des réductions sur le coût de
fonctionnement (OPEX) ;
- avec NFV, le passage à l’échelle peut être réalisé de manière horizontale (« horizontal
scalability ») : par exemple, en cas de congestion d’un service, il est facile de déployer une
nouvelle occurrence de ce service, permettant ainsi de s’adapter à la montée en charge.
- enfin, la virtualisation permet de s’affranchir de la contrainte géographique en permettant de
positionner le service indépendamment des contraintes physiques.

4 Approche hybride

4.1 Stabilité réseau


Pour qu’un produit ou un service soit déployé en production, les environnements opérationnels des
réseaux exigent un très bon niveau de disponibilité (par exemple 99, 999 %). Il n’est pas pensable de
mettre un service en exploitation sans avoir validé les tests de fiabilité et l’intégration à l’environnement
de production de l’opérateur (mêmes machines, mêmes architectures, mêmes contraintes comme le

JRES 2015 - Montpellier 3/6


nombre de routes supportées, etc...). De plus, le monde opérationnel demande un support pour tout
produit mis en production : non seulement ce produit doit être considéré comme très fiable, mais les
équipes opérationnelles doivent pouvoir compter sur un support en cas de panne majeure (coupure de
service pour l’utilisateur). Ces prérequis ont permis à l’industrie télécom de bâtir des services à haut
niveau de fiabilité sur lesquels l’activité des utilisateurs repose quotidiennement.
Il existe néanmoins des domaines dans lesquels la souplesse et la « programmabilité » de NFV et SDN
permettent une réactivité si rapide qu’ils peuvent s’imposer, comme par exemple dans le domaine de la
sécurité (« DDOS mitigation », pare-feu, etc…). C’est certainement dans ces domaines que nous verrons
les premiers déploiements opérationnels.

4.2 Centralisation des services de gestion du réseau


L’approche décentralisée consiste à déployer des machines capables d’effectuer les calculs du plan de
contrôle, c’est-à-dire des routeurs tels que nous les connaissons tous, chez les opérateurs. Cette approche
classique est plus coûteuse en termes de ressources utilisées sur chaque point du réseau (chaque routeur),
mais elle est plus résistante aux pannes, point crucial pour l’exploitation réseau. Elle est aussi opposée à
l’approche SDN où les calculs du plan de contrôle sont effectués centralement. Il parait délicat de
centraliser le plan de contrôle en remplaçant un IGP tout en conservant une bonne résistance aux pannes
(convergence rapide). De même, les fonctions (ACL, QOS, chiffrement, flow monitoring…) faisant un
recours intensif aux processeurs réseaux (Network Processor Unit) ne sont pas de bons candidats pour la
centralisation. Il existe néanmoins des services qui peuvent être centralisés : on peut imaginer facilement
le calcul et la mise en place de filtres de sécurité pour contrer des attaques. L’utilisation de SDN pour
contrer les attaques DDOS est une piste très prometteuse, la capacité de programmation, l’extrême
flexibilité et la réactivité étant bien adaptées à ce type de fonctions réseaux (« SDN DDOS mitigation »).
Si l’on considère les différents traitements utilisés pour la gestion du réseau, on remarque qu’une
stratégie uniquement centralisée ne peut répondre à toutes les exigences d’un opérateur en termes de
fiabilité et de performances. Néanmoins, l’approche centralisée apporte un ensemble d’améliorations en
termes d’exploitation du réseau, d’économie, d’investissement et de création de nouveaux services.
L’adoption d’une approche hybride du déploiement de SDN et NFV en complément de l’approche
traditionnelle distribuée sur les routeurs prend tout son sens : les fonctions ne nécessitant pas de gros
débits, peu sensibles à la latence et utilisant peu les processeurs réseaux sont des candidates à la
virtualisation et la centralisation, les autres resteront embarquées dans les routeurs. Cette étape de
développement et de déploiement de SDN et NFV constitue une étape majeure pour l’adoption de ces
technologies.

4.2.1 Résultats de premier tests


Le premier service qu’un opérateur peut adopter est le déploiement de routeurs virtuels pour tester de
nouvelles architectures et développer de nouveaux protocoles. Juniper, Cisco et Alcatel proposent des
versions de leurs routeurs en mode virtuel. Un routeur peut être modélisé sous la forme de plusieurs
machines virtuelles, qui peuvent jouer le rôle de la « routing-engine » ou d’une carte de ligne chez
Alcatel, ou encore une machine peut représenter le plan de contrôle complété par une seconde machine
représentant le plan de commutation chez Juniper. Ces routeurs virtuels sont particulièrement adaptés
pour des maquettes et des tests.
Chez Cisco, il s’agit de la version IOS-XRv du route-réflecteur. Les fonctions de niveau 2 de
commutation ne sont pas actives, cela veut dire qu’il n’est pas possible de commuter (forwarder) de
paquets de VPN de niveau 2, par exemple. Sur Juniper, le Virtual MX (vMX) est un routeur réel complet
et s’installe très rapidement, le seul bémol étant que le vMX exige 8 giga-octets de mémoire vive. Alcatel
propose deux versions de son SROS, un routeur standard et route réflecteur. Les constructeurs proposent
maintenant leur route-réflecteur virtuel dans leur catalogue.

JRES 2015 - Montpellier 4/6


Nous avons pu très facilement monter une maquette du protocole Ethernet VPN grâce au vMX de
Juniper. Nous envisageons d’étudier d’autres cas d’utilisation dans le cadre du service « innovation » à la
Direction Technique de RENATER.

4.3 De nouveaux services pour les utilisateurs


Avec NFV, on peut décliner de nombreux services spécifiques pour les sites utilisateurs (NAT, pare-feu,
« DDOS mitigation », CPE-virtuel, etc…). Il est facile de s’adapter aux requêtes, car il suffit de déployer
la NFV correspondante à ce service. L’intérêt pour les sites utilisateurs est de ne plus gérer localement
des points techniques réseaux et sécurité pour se concentrer sur leur cœur de métier. Bien sûr, tous les
sites ne sont pas concernés par ce besoin et certains sites préfèreront continuer à gérer ces points
localement.
La mise à disposition de services dédiés (par exemple un pare-feu) se retrouve chez les gestionnaires de
centres de calcul qui pratiquent cette activité dans leur domaine mais, cette fois, elle se trouve portée à
l’échelle d’un backbone opérateur. Certains services doivent se trouver en coupure ou ont des contraintes
géographiques ; dès lors le service doit être délivré dans un lieu précis, par exemple en entrée de site.
L’opérateur doit alors maintenir une machine au plus près de son routeur d’accès.
Dans ce dernier cas, il serait très intéressant de s’affranchir de la contrainte géographique. La
combinaison de NFV et de la faculté de dérouter un trafic utilisateur particulier permettrait de faire passer
ce trafic par des services pour des traitements spécifiques : on parle ainsi de chainage de services ou
« Service Chaining » ou « Service Function Chaining ». Le trafic utilisateur parcourt différents services
situés à l’endroit préconisé pour l’opérateur et le site client. On peut imaginer qu’un site utilisateur
souscrive à une offre pare-feu plus DDOS mitigation et CPE virtuel. Le trafic en entrée du site est dévié
vers un centre de détection d’attaques DDOS, éventuellement vers une fonction de nettoyage de flux
(scrubbing), puis le flux est redirigé vers un cluster de pare-feu, pour enfin continuer son parcours vers un
CPE virtuel avant d’arriver vers le site utilisateurs.
Virtual CPE Firewall service

Cloud

INTERNET

PE1 PE3
Service Client
PE2
Pirate

Network Provider

Utilisateur

Figure 2 : exemple de « Service Chaining »

Le chaînage de services est évidemment une opportunité importante pour les opérateurs. Dans une
optique de standardisation, l’IETF a constitué un groupe de travail relatif au « Service Chaining » dont le
concept repose fortement sur SDN et NFV.
Il existe plusieurs approches de SFC. L’une d’elles est en débat à l’IETF avec pour objectif un
déploiement de service décorrélé de la localisation de l’entité rendant le service. Les technologies pour

JRES 2015 - Montpellier 5/6


cela ne sont pas encore matures, mais il existe néanmoins déjà des débuts d’implémentations permettant
de commencer à expérimenter certains services.

4.4 Couplage des applications métiers et du réseau


Une autre conséquence majeure de l’apparition de SDN et NFV est que le réseau devient programmable
et peut être couplé aux applications métiers des usagers. Là encore, les centres de calcul pratiquent déjà
cette mise en place de service spécifique pour leurs usagers. Dans le domaine du WAN, les contraintes
sont différentes et si elles ne sont pas encore totalement résolues, elles sont déjà partiellement traitées par
les techniques d’interconnexion de data-centers et notamment Ethernet VPN. EVPN permet de fournir un
réseau privé et dédié pour chaque utilisateur (« tenant »). Il manque pour l’instant un peu de
programmation pour créer cette infrastructure virtuelle à la demande via les commutateurs de rack ou les
hyperviseurs, mais SDN devrait pouvoir couvrir ce point. L’infrastructure étant créée pour un utilisateur,
on peut donc imaginer que c’est l’application métier qui pilote la création de cette infrastructure afin de
tirer un meilleur parti du réseau.

5 Perspectives
De nombreux opérateurs projettent d’investir dans ce domaine, l’opportunité d’offrir de nouveaux
services étant trop importante pour être négligée. Les technologies ne sont pas encore matures. Il s’agit
certainement d’un changement technologique que les opérateurs ne doivent pas rater et grâce auquel ils
peuvent développer leur catalogue de services. Pour la recherche, c’est évidemment un point important
que de pouvoir simplifier et améliorer la vie de nos utilisateurs en leur apportant de nouveaux services.
Mais il s’agit d’un changement très important de culture au sein des équipes des opérateurs. Il est donc
nécessaire d’anticiper et de former ces équipes à cette nouvelle forme de gestion du réseau.

Bibliographie
1. RFC 7498 - Problem Statement for Service Function Chaining
2. Draft-ietf-sfc-architecture-11 - Service Function Chaining (SFC) Architecture

JRES 2015 - Montpellier 6/6