1 août 2013
Parmi les acronymes qui font le buzz et que nous trouvons régulièrement dans les publications, SDN pour ‘’Software Defined Networking’’ tient de plus en plus le haut du pavé.
Il n’y a pas de définition propre du terme SDN, les différents éditeurs le définissent selon leurs intérêts. Un exemple probant est la qualification de ‘’SDN enable’’ des produits disposant d’une API permettant d’automatiser sa configuration. Il est donc assez difficile de s’y retrouver.
A l’origine du SDN se trouve un concept permettant d’opérer le réseau différemment. Ce concept est basé sur l’idée que le flux réseau peut être programmé à souhait en fonction du besoin.
La réflexion première, issue du monde universitaire, est de découpler le ‘’Control Plane’’ (qui détermine comment les paquets sont transmis) du ‘’Forwarding Plane’’ (qui est responsable de la transmission des paquets) des équipements réseaux et de transférer ainsi le contrôle du réseau à un « cerveau central », le contrôleur, à partir du quel s’opérera la programmation. Il y a donc trois niveaux dans ce nouveau modèle d’architecture : le réseau (dit ‘’southbound’’ dans la terminologie SDN), le contrôleur et les applications (dites ‘’northbound’’).
La volonté sous-jacente est aussi d’être indépendant de l’équipementier réseau. Qui dit indépendance dit normalisation, pour se faire l’Open Networking Foundation (ONF), un consortium dont l’objectif est de développer le SDN, travaille pour définir des standards. Il s’est jusqu’à présent focalisé sur la partie réseau (southbound) et le protocole OpenFlow, qui permet de découpler le plan de données du plan de contrôle et à la base du concept.
Ce protocole est timidement implémenté par les grands équipementiers réseaux, ce qui est compréhensible car cela va à l’encontre de leurs intérêts. Certains utilisent les champs supplémentaires présents pour prendre en considération les fonctions non encore supportées. Mais d’autres fournissent leurs protocoles propriétaires en parallèle d’Open Flow pour essayer de « garder le contrôle ». En outre certaines start-up du secteur ne proposent pas le protocole dans leur solution ou sont en attente de l’adoption de celui-ci par le marché.
L’avenir dira si ce protocole deviendra la norme, j’en doute étant donné l’impact qu’il aura sur l’écosystème actuel. OpenFlow sera très certainement un protocole réseau (southbound) parmi d’autres. Son implémentation par le projet OpenDaylight laisse présager cela. Dans des architectures de Datacenter nous seront forcément sur des architectures hybrides avec plusieurs protocoles côté southbound : propriétaires, rest api, OpenFlow (Netconf), vxlan … ainsi que les protocoles actuels. Il faut voir aussi que OpenFlow est une manière de transmettre les paquets, dans son implémentation actuelle, il se limite aux fonctions adressées par la commutation et le routage et ne prend pas en considération les fonctionnalités d’analyse avancée des paquets permettant d’effectuer de la prévention d’intrusion ou de la répartition de charge évoluée. Une ‘’Network Fabric’’, certes une solution propriétaire, peut aussi être une alternative à une gestion centralisée de la transmission des paquets dans un Datacenter. D’autres solutions (de virtualisation de réseau) tablent sur la-non adoption d’OpenFlow au niveau des commutateurs physiques et utilisent sur les besoins actuels et futurs des technologies d’overlay (de niveau 2 et de niveau 3) pour être indépendantes de l’architecture physique de commutation.
L’architecture côté Southbound commence à se dessiner et sera très certainement un mixe de ces différentes solutions. Dans le monde SDN nous sommes surement rentrés dans l’ère post-OpenFlow. Les avancées vont se déporter côté applications.
Le côté Nortbound est à ce jour encore plus confus ! Aucune standardisation n’y est formalisée. Le manque de standard au niveau des API pénalisent cette partie primordiale du SDN. Pourquoi un développeur privilégierait tel ou tel contrôleur ?
Le contrôleur est le « middleware », il est une couche d’abstraction du réseau pour les applications, il doit présenter les APIs aux applications pour que celles-ci puissent programmer le réseau. Dans les approches actuelles les éditeurs fournissent le contrôleur et les applications dans un seul produit. La principale application des start-up du secteur est une solution de virtualisation du réseau qui peut être couplée avec les solutions d’orchestration (principalement OpenStack).
Le manque de normalisation est très certainement dû au fait que les grands éditeurs n’aient pas eu un business case qui les aient fait investir sur le sujet. Les start-up apportent les évolutions, les grands éditeurs dictent le marché. Le projet OpenDaylight, qui a vu le jour en avril dernier, peut être un excellent accélérateur. Il a pour objectif de fournir un contrôleur et framework SDN ouvert mais surtout il est porté par les éditeurs (dont les grands).
Le SDN n’est pas OpenFlow (sauf à s’appeler Google) il est actuellement orienté business mais c’est un accélérateur pour une évolution obligatoire. Le réseau ne peut rester le seul composant ‘’statique’’. Le SDN ne deviendra même très certainement pas un standard tel qu’il est défini actuellement (la partie réseau actuelle fonctionne correctement pour acheminer des paquets) mais les avancées apportées ou tirées vers le haut par le SDN, à savoir la programmation centralisée du réseau, la capacité à gérer la scabilité, la faculté à apporter des réseaux dynamiques, à mieux prendre en compte la virtualisation sont l’avenir. La définition future du SDN tendra très certainement vers une nouvelle façon de manager le réseau.
Un petit bémol à cela cependant, les évolutions apportées par le SDN seront profitables aux acteurs du Cloud, aux opérateurs ou aux grandes sociétés disposant de Datacenters interconnectés mais pas aux nombreuses plus petites sociétés disposant de leur infrastructure propre mais qui ne sont pas confrontées aux problèmes adressés par le SDN.