Comme pour toute nouvelle technologie, il n'existe pas encore de définition universellement acceptée de ce que l'on entend par réseau défini par logiciel (SDN, Software Defined Networks). Au cours de ces deux dernières années, la plupart des définitions ont mis l'accent sur le découplage entre le contrôle du réseau et le transport dans le réseau.

De nombreux fournisseurs proposent leur offre baptisée SDN : Alcatel-Lucent, HP, Juniper Networks, Cisco, Brocade, etc. Un premier réseau a même été déployé pour des applications Big Data.

Découplage entre logique de contrôle et transmission

Le découplage entre le contrôle du réseau et la transmission effective n'est pas un concept nouveau. C'est un élément clé de la technologie MPLS et c'est aussi une caractéristique de nombreux réseaux WiFi actuels. Toutefois, si on regarde le SDN strictement de ce point de vue, sa valeur est limitée à des caractéristiques telles que la réduction de la latence du réseau.

La définition du SDN qui émerge actuellement se concentre un peu moins sur le découplage et plus sur la capacité à fournir des interfaces de programmation au sein des équipements de réseau, qu'il y ait ou pas une séparation entre le contrôle et la transmission. La raison pour ce changement de cap provient du fait que Cisco a récemment annoncé que dans le cadre de ses offres SDN, il fournira des API pour ses différentes plateformes.

Le risque propriétaire et le besoin d'automatisation

Ce n'est pas seulement l'approche de Cisco, étant donné que d'autres fournisseurs; notamment Arista, Extreme Networks ou Juniper offrent aussi un accès direct à leurs produits. L'avantage de cette approche est qu'elle permet d'accéder de manière très détaillée sur les éléments du réseau et d'en prendre le contrôle. Cette approche, cependant, ne fournit pas un point de contrôle central et reste propriétaire. Si certains fournisseurs de services réseau adoptent cette vision à court terme, il est peu probable qu'elle s'implante sur le marché de l'entreprise.

La première raison d'être du SDN réside dans la valeur ajoutée qu'apporte les API. En effet, le SDN permet aux entreprises de remplacer une interface manuelle dans l'équipement de réseau par une interface de programmation autorisant l'automatisation des tâches telles que la configuration et la gestion des politiques de contrôle des flux et peut également permettre au réseau de répondre dynamiquement aux exigences des applications.

Avec la définition la plus commune du SDN, le contrôle global du réseau est assuré par la centralisation logique de la fonction de contrôle, et les équipes en charge des opérations réseau peuvent traiter avec un ensemble d'équipements réseau comme étant une seule entité. Avec le SDN, les flux de réseau sont contrôlés à un niveau d'abstraction global, généralement, mais pas toujours, à l'aide du protocole OpenFlow, plutôt qu'au niveau de chacun des équipements.

OpenFlow ou les ambitions d'un futur standard

Networking Foundation (ONF). L'ONF a été lancé en 2011 et a pour vision de faire des SDN basés sur OpenFlow la prochaine norme pour les réseaux. Pour réaliser cette vision, l'organisme a pris la responsabilité de conduire la standardisation du protocole OpenFlow.

L'ampleur de l'écosystème SDN se reflète dans le fait que l'ONF a actuellement plus de 70 membres, y compris les fournisseurs qui offrent les chipsets aussi bien que ceux délivrant les commutateurs, les équipements réseau, les contrôleurs, les équipements de test, les services de télécommunications, les services de datacenters et les smartphones.

Une architecture en couches pour un SDN est présentée en illustration. Dans cette architecture, la fonction de contrôle est centralisée dans le logiciel du contrôleur de SDN. La plupart du temps, le protocole OpenFlow est utilisé pour programmer le comportement de retransmission du commutateur.

Il existe cependant des alternatives à l'utilisation de OpenFlow, y compris l'Extensible Messaging and Presence Protocol (XMPP),  le Networking Configuration Protocol (protocole Netcong) et OpenStack  de Rackspace et de la NASA.

[[page]]

Dans ce modèle, les applications sont écrites avec un ensemble d'API qui sont fournies par le contrôleur de SDN. Malheureusement, ces API ne sont pas standardisées, une application qui s'exécute sur un contrôleur donné SDN devrait être modifiée pour fonctionner sur un autre contrôleur.

Le contrôleur de SDN embarque un certain nombre de règles qui contrôlent le comportement des éléments de réseau sous-jacents, de sorte que le réseau fournira les services de réseau souhaités. Le dispositif de commande fournit des fonctions de gestion pour la performance et des défauts via SNMP, ainsi que d'autres protocoles standards. Le contrôleur gère la configuration des dispositifs compatibles avec OpenFlow afin de fournir la gestion de la topologie du réseau, de la transmission, de la qualité de service et des liaisons.

Les commutateurs Ethernet et les routeurs les plus modernes contiennent des tables de flux (typiquement supportées par la mémoire adressable de contenu ternaire) qui fonctionnent à la vitesse de la ligne et sont utilisées pour effectuer des fonctions de transfert selon  les couches 2,3 et 4, indiquées dans les en-têtes de paquets. Bien que chaque fournisseur ait des tables de routage différentes, il existe un ensemble commun de fonctions pour une large gamme de commutateurs et de routeurs. Ce socle de fonctions est mis à profit par OpenFlow, qui est un protocole ouvert entre un contrôleur central et un commutateur gérant ce protocole et qui, comme indiqué, peut être utilisé pour programmer le comportement de retransmission du commutateur.

Avec OpenFlow, un seul contrôleur central peut programmer tous les commutateurs physiques et virtuels dans un réseau. Bien qu'il soit possible de mettre en oeuvre un SDN avec un seul contrôleur, des fournisseurs tels que Big Switch et NEC ont annoncé soit un cluster à haute disponibilité soit leur intention de mettre en oeuvre un tel groupe de contrôleurs. Il est probable qu'IBM suivra.

Une montée en puissance lente

Il ne fait aucun doute que le SDN peut apporter une valeur très importante pour les DSI. Mais dans le contexte actuel, il est seulement approprié pour les pionniers.  Compte tenu de l'immaturité des produits actuels, des normes et des API, toute organisation informatique qui cherche à mettre en oeuvre un SDN à court terme ne doit le faire que d'une manière quelque peu limitée pour une utilisation très spécifique.

En outre, étant donné l'état embryonnaire du marché, l'interopérabilité des produits qui prétendent soutenir les mêmes normes connexes de SDN ne peut être garantie. Dès lors, les organisations informatiques ne devraient travailler qu'avec des fournisseurs qui ont démontré un niveau élevé d'interopérabilité.

Toutefois, compte tenu des énormes investissements que les vendeurs font, combinés avec la vague d'acquisitions en cours, le paysage du SDN est susceptible de changer, notamment au cours des 12 à 18 prochains mois. Les organisations informatiques peuvent s'attendre à une série d'annonces à la fois en termes de produits, des protocoles et une amélioration de l'interopérabilité.

Les directions informatiques peuvent également s'attendre à ce que les blocs de base de construction d'un SDN, tels que les protocoles et les API, vont se stabiliser. En partant du principe que tout cela se concrétise, il y a deux événements qui doivent se produire pour que le SDN puisse passer du statut de « strictement pour les pionniers » à  au «prêt pour le marché grand public ».

Le premier est la disponibilité d'une fonction qui permette aux organisations IT de gérer efficacement cette future forme de réseau. Le second est la disponibilité d'une large gamme d'applications qui tirent parti de la centralisation de la commande inhérente à la plupart des formes de SDN et qui réponde à la question que tous les responsables informatiques vont se poser: «Pourquoi devrions-nous dépenser nos ressources sur du SDN. Quels sont exactement les avantages? »