comprendre le SDN, ou l'art de virtualiser le réseau

Depuis 2010, le Cloud change de visage avec l'arrivée de mécanismes d'automatisation de gestion des serveurs et du stockage, ainsi que de l'autoconfiguration du réseau. Dans les grands clouds publics, privés ou hybrides, ces tâches deviennent impossibles manuellement, surtout dans un contexte de concurrence où l'adaptation instantanée aux besoins des clients devient primordiale.

A l'origine, les deux initiatives n'avaient rien en commun. D'un côté, le projet OpenStack, lancé en 2010, par la fondation Openstack, pour créer et offrir des services dynamiques dans le monde du Cloud Computing. D'un autre côté, le projet SDN (Software Defined Network), développé par l'Open Networking Foundation (ONF), créée en 2011. Il vise à découpler, dans un équipement réseau, la partie plan de données de la partie plan de contrôle.

En d'autres termes, ne laisser aux commutateurs ou routeurs que l'aiguillage des paquets. Les services réseaux (affectation des priorités, décisions de routage...) sont rassemblées dans un contrôleur, commun à plusieurs équipements.

On peut donc utiliser l'un ou l'autre projet, mais également les deux à la fois car ils se complètent. En effet, le Cloud Computing se caractérise par une forte agilité des infrastructures destinées à s'adapter quasi instantanément aux besoins des utilisateurs, que ce soit dans un Cloud privé ou public. Dès lors, toute automatisation des tâches, tant côté informatique que côté réseau, ne peut que bénéficier aux fournisseurs de services Cloud et, en fin de compte, aux utilisateurs.

Le SDN : quand le réseau s'autoconfigure


Dans un réseau classique, lorsqu'un paquet arrive sur un port d'un commutateur ou d'un routeur, celui-ci applique les règles de routage ou de commutation qui sont inscrites dans son système d'exploitation. Généralement, tous les paquets qui ont la même destination suivent le même chemin. Dans les modèles haut de gamme, les matériels sont capables de reconnaître le type d'application et de lui appliquer les règles spécifiques. Mais cette programmation est rigide. Elle ne peut être changée que manuellement, par l'administrateur, ce qui prend évidemment du temps et ne se prête guère à des changements de contexte rapides.

Avec le SDN, ces changements sont automatisés et même programmables. L'administrateur définit les règles dans le contrôleur, et celles-ci sont instantanément transmises dans les équipements réseaux. Par exemple, si une entreprise réalise des sauvegardes toutes les nuits, il est possible de configurer le réseau pour leur offrir à ce moment-là le maximum de bande passante, le trafic métier de la journée étant alors fort réduit. Autre exemple : une entreprise qui possède des établissements de chaque côté de l'Atlantique. Sachant que le coût de ces liaisons est élevé, elle peut choisir de l'optimiser, en fonction de l'heure et/ou du type de trafic. L'avantage qu'offre le SDN réside dans l'automatisation de ces configurations, sans que l'administrateur ait à intervenir.

Le côté découplage entre la partie matérielle et la partie logicielle n'est pas sans rappeler le fameux IMS (IP Multimedia Subsystem), qui introduisait dans les équipements télécoms plan de données et plan de contrôle. Apparu au tournant des années 2000, il était poussé par les constructeurs, tels que Lucent ou Ericsson. Il répondait à un besoin né de l'arrivée des réseaux UMTS (3G). D'où son rapport très étroit avec le 3rd Generation Partnership Project (3GPP), organisme de normalisation de la téléphonie mobile 3G dans les réseaux UMTS.

Plus tard, sont venus s'ajouter d'autres types d'accès et de protocoles, tels que SIP ou la VoIP et même l'interfonctionnement avec les réseaux fixes, fruit d'une collaboration avec TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks), d'origine ETSI (European Telecommunications Standards Institute). Cette nouvelle architecture, s'appliquant uniquement aux réseaux d'opérateurs, fut nommée NGN (Next Generation Network). Elle permet d'utiliser le même plan de contrôle pilotant un cœur de réseau IP unique sur lequel se raccordent différents types d'accès. D'une certaine manière, le SDN est une déclinaison de l'IMS au niveau de l'entreprise et du Cloud computing.


Certains spécialistes ont déclaré que le SDN était l'arme anti-Cisco par excellence. L'industriel a bâti sa réussite sur la fourniture de boîtiers. Or, le SDN les relègue au second plan, favorisant le contrôleur, cerveau du système. Celui-ci peut piloter des équipements de différentes marques, dans la mesure où ils respectent les normes de l'ONF.

Mais encore faut-il qu'il transmette ces ordres du contrôleur au réseau, via un protocole et des interfaces de programmation (API). Et c'est là que les choses se gâtent car si tout le monde est d'accord sur le principe, sa mise en œuvre peut varier d'un constructeur à l'autre. L'ONF a défini le protocole OpenFlow, aujourd'hui en version 1.3. Brocade, par exemple, l'a adopté. Le constructeur l'estime aujourd'hui assez stable (après la rafale de versions successives tous les six mois) et offrant suffisamment de possibilités. Il l'intégrera dans ses équipements dès 2014.

En revanche, pour Juniper, il n'est pas assez mûr et n'offre que des performances réduites. Pour le moment, il lui préfère le protocole BGP (Border Gateway Protocol) pour la partie contrôle et MPLS (MultiProtocol Label Switching) pour la partie transport. Parallèlement, il travaille avec des partenaires sur sa propre solution Contrail, issue du rachat de la société éponyme en décembre 2012. Il l'estime mieux taillée pour les grands Clouds publics et la met en OpenSource. Tout en offrant une interface OpenFlow sur ses équipements, notamment sur le récent Nexus 9000, Cisco a développé également sa propre solution, OnePK, possédant des extensions propriétaires. Cependant, on observe qu'OpenFlow semble de plus en plus enclin à rallier les suffrages, avec des poids lourds comme HP, IBM, Ericsson, NEC ou Alcatel-Lucent.



Le concept de SDN, ici résumé par HP

Cette boite magique que constitue le contrôleur est en fait un logiciel qui se substitue au logiciel de commande inclus dans chaque équipement réseau. Il devient donc possible de prendre les commandes d'un réseau entier, même hétérogène, au lieu d'avoir à intervenir sur chaque boîtier. On peut résumer les fonctions de base du contrôleur en trois catégories : gérer la commutation et le routage des trames en appliquant des règles prédéfinies, effectuer cette tâche dynamiquement et en fonction des besoins en capacité, enfin, pouvoir être programmé, afin de les exécuter à des moments déterminés par l'administrateur, en fonction des exigences métier par exemple.

Pour le gestionnaire du réseau, cela se traduit par : la suppression des délais de d'allocation de réseau, la modification des bandes passantes à la volée, l'adaptation du paramétrage réseau aux besoins des applications et une réduction de la complexité de gestion des réseaux. A ces fonctions de base, certains constructeurs et éditeurs ajoutent des applications qui enrichissent les possibilités du contrôleur, ce qui nécessite un protocole de communication avec les équipements propriétaire. C'est notamment le cas de Cisco, qui propose sur ses machines une interface standard OpenFlow et une autre Cisco OnePK.

IBM et HP possèdent leur propre contrôleur. Juniper également, avec Contrail. Cisco en annonce deux. Le premier, c'est le XNC (eXtensible Network Controller). Récemment, il vient d'annoncer l'APIC (Application Policy Infrastructure Controller), cœur de sa nouvelle architecture ACI (Application Centrix Infrastructure), à la fois logicielle et matérielle puisqu'elle s'appuie notamment sur le commutateur Nexus 9000. Brocade ne développera pas de contrôleur. Parmi ceux du marché, on trouve notamment Big Switch Networks et son Big Network Controller.


Alors, le SDN, la panacée ? Selon Bruno Dutriaux, responsable du pôle Business Cloud Services chez Cisco France, « les entreprises n'ont pas systématiquement besoin du SDN, en tout cas sur l'ensemble de leurs équipements. Le choix ne dépend pas de la taille de l'entreprise, mais plutôt de son activité et de son environnement. Elle peut choisir de piloter à distance 10, 20 ou 90 % de ses équipements ».

Une position d'ailleurs corroborée par François Fort, responsable des projets spéciaux chez SFR, qui estime que « si les demandes métier ne nécessitent pas de souplesse de l'infrastructure réseau, il n'est pas nécessaire de se précipiter. Au contraire, si les besoins métiers exigent des réponses rapides, une forte adaptation du SI, le SDN est une bonne réponse, soit en interne, soit par l'emploi de Cloud Service Provider fournissant des services SDN ». Le SDN ne va donc pas s'imposer du jour au lendemain, car si c'était le cas, le paysage du monde des réseaux en serait bouleversé.

En effet, selon David Limery, ingénieur avant-vente chez Brocade : « si le SDN se généralise, il n'y aura plus besoin de protocole de routage. On peut imaginer que ces besoins seront définis par l'administrateur du réseau par le biais d'un portail Web : quand telle ou telle condition survient ou tel ou tel seuil est atteint, le réseau doit se configurer de telle ou telle manière. C'est le contrôleur qui donne les ordres aux équipements ». Voilà de quoi donner de l'urticaire à Cisco.

Brad Boooks, vice-président exécutif et responsable marketing chez Juniper, pense que « les premiers intéressés sont les fournisseurs de services. En effet, grâce à ces logiciels virtualisés, il leur est possible de créer autant de machines virtuelles que nécessaire en cas de pics de trafic, par exemple, puis les supprimer lorsqu'elles deviennent inutiles ». Il ajoute : « les entreprises seront également également bénéficiaires de cette souplesse. Un grand constructeur automobile allemand a ainsi développé un service permettant à ses clients de suivre l'évolution de la commande de leur véhicule, depuis la chaîne de montage jusqu'à la livraison et même proposer un rendez-vous pour la prise en main de la voiture ».

Pour certains, l'arrivée du SDN ne se limite pas à une évolution technique ; elle aura également des conséquences humaines. Généralement, dans l'entreprise, les équipes chargées de l'informatique et celles du réseau constituent deux groupes séparés. Désormais, elles devront fusionner, car il n'y aura plus de frontière nette entre informatique et réseaux. De plus, cette simplification de l'exploitation du réseau permet de dégager du personnel jusque-là attaché à des tâches basiques de configuration des équipements pour l'affecter, notamment, à la création de nouveaux services qui peuvent amener un avantage concurrentiel.



Extrait de la documentation associée à Contrail, une des solutions SDN de Juniper

Au départ, il s'agissait d'un projet entre Rackspace Hosting et la NASA, qui ont lancé, conjointement, un nouveau projet OpenSource en 2010 dans le domaine du cloud computing sous le nom d'OpenStack, sous licence Apache. Puis sont venus se greffer d'autres membres. Trois ans plus tard, la Fondation OpenStack compte 12 000 membres. Environ 1 000 d'entre eux écrivent du code et les autres réalisent les tests des différentes versions (une environ tous les six mois), produisent la documentation ou s'occupent des aspects juridiques.