Cisco France Blog

Software Defined Networking : concept et réalité

2 min read



Lorsque de nouvelles  technologies ou architectures émergent il n’est pas toujours facile de faire le tri entre concept, objectifs, définition, cas d’usage et implémentation concrète.

Alors remercions ceux qui font œuvre de synthèse et de vulgarisation et qui facilitent ainsi la compréhension de ceux qui s’interrogent sur les nouveaux thèmes comme le Software Defined Networking.

  Je me permets donc de livrer quelques extraits de l’article «SDN, fiction ou réalité ? » écrit par Frédéric Braibant de la société Nomios dans Global Security Mag. La totalité de l’article est disponible sur le site du journal.

  •  Définition et concept :

« 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 duquel 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’’). »

  •  SDN et normalisation :

« 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 serons forcément sur des architectures hybrides avec plusieurs protocoles côté southbound : propriétaires, rest api, OpenFlow (Netconf), vxlan … ainsi que les protocoles actuels. »….

…« Le manque de normalisation est très certainement dû au fait que les grands éditeurs n’aient pas eu un business case qui les ait 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. »

  • A qui s’adressera le SDN

« 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, qui, elles, ne sont pas confrontées aux problèmes adressés par le SDN. »

Vous pouvez également relire les billets publiés sur SDN sur ce blog:

Tags:
Laisser un commentaire