Réseaux SDN : pourquoi il est important de s'y intéresser
Les réseaux SDN (Software Defined Networks) ne sont pas encore prêts pour être en première ligne, pas encore. Mais les responsables informatiques doivent savoir quels sont les avantages de ce changement radical dans la technologie des réseaux.
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 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 de 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. Une 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 dans les multiples plates-formes qu'il fournit.
Des APIs fournies par les constructeurs
Ce n'est pas seulement l'approche de Cisco, étant donné que d'autres fournisseurs; notamment Arista, Extreme Networks ou Juniper Networks offrent aussi un accès direct à leurs produits. Un avantage de cette approche est qu'elle permet d'accéder de manière très détaillée, et de prendre le contrôle, sur les éléments du réseau.
Cette approche, cependant, ne fournit pas un point de contrôle central et est spécifique du fournisseur. Alors que certains fournisseurs de services réseau peuvent adopter cette approche à court terme, il est peu probable qu'elle s'implante sur le marché de l'entreprise.
Une interface de programmation
Une raison plus puissante pour le changement d'orientation de la définition de la SDN, c'est que si le SDN est regardé comme délivrant des interfaces de programmation dans les équipements de réseau, alors sa valeur est beaucoup plus large.
Vu de cette manière, le SDN permet aux entreprises de remplacer une interface manuelle dans l'équipement de réseau par une interface de programmation qui peut permettre 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.
SDN: révolution ou évolution?
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.
Architecture SDN
Le groupe le plus souvent associé au développement des standards SDN est l'Open Networking Foundation (ONF). L'ONF a été lancé en 2011 et a pour vision de faire des SDN basés sur OpenFlow la nouvelle norme pour les réseaux. Pour réaliser cette vision, l'ONF 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 de divers types, 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 Data Centers 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 l'OpenStack de Rackspace et de la NASA.
(cliquer sur l'image pour l'agrandir)
Une architecture SDN en couches
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 SDN. Des exemples d'applications réseau qui pourraient fonctionner sur un contrôleur SDN sont donnés ci-dessous.
Le contrôleur de SDN embarque un certain nombre de directives 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 telles que la gestion de la performance et des défauts via SNMP et 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 liaison.
OpenFlow
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 flux différentes, il existe un ensemble commun de fonctions pour une large gamme de commutateurs et de routeurs. Cet ensemble commun de fonctions est mis à profit par OpenFlow, qui est un protocole ouvert entre un contrôleur central OpenFlow et un commutateur OpenFlow 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.
Le protocole OpenFlow a été développé à Stanford, avec la v1.0 publiée à la fin de 2009 et la v1.1 au début de 2011. En Mars 2011, l'ONF a été créé et les droits de propriété intellectuelle d'OpenFlow lui ont été transférés. Une partie de la charte de l'ONF est de contrôler et de commercialiser OpenFlow.
Avec cet objectif à l'esprit, l'ONF a récemment publié OpenFlow v1.3 et en Mars 2012, l'ONF a parrainé un événement d'interopérabilité qui était ouvert à tous les membres de l'ONF. Un total de 14 entreprises et deux instituts de recherche ont participé à l'événement qui a mis l'accent sur la norme OpenFlow v1.0. Les informations sur le test et les leçons tirées peuvent être trouvées sur le site de l'ONF.
Dans un commutateur uniquement OpenFlow, toutes les fonctions de commande d'un commutateur traditionnel sont exécutées dans le contrôleur central OpenFlow. Il s'agit par exemple des protocoles de routage qui sont utilisés pour construire les bases d'informations de transmission (FIB).
Un commutateur compatible OpenFlow (surnommé un commutateur OpenFlow-hybride en v1.1) prend en charge à la fois le transfert de flux selon OpenFlow et le pontage et le routage Ethernet traditionnels. Des commutateurs hybrides permettent l'OpenFlow et au traditionnel pontage/routage de partager la même infrastructure Ethernet.
Plusieurs commutateurs ayant des fonctionnalités évoluées sur les couches 2 et 3 peuvent être convertis en commutateurs hybrides OpenFlow par l'ajout relativement simple d'un agent OpenFlow dans le firmware pris en charge par le système d'exploitation natif du commutateur réseau (NOS pour Network Operating System).
Sinon, une fois que les fournisseurs de composants électroniques auront produit des puces qui traitent efficacement le protocole OpenFlow, un commutateur uniquement OpenFlow serait extrêmement simple et peu coûteux à construire, car il aurait très peu de logiciel résident et ne nécessiterait pas un processeur puissant ni de mémoire de grande capacité pour soutenir les fonctions de contrôle étendus généralement intégrées dans un NOS traditionnel.
Il existe un certain nombre de moyens pour que la centralisation du contrôle, la programmabilité, ainsi que les caractéristiques de transfert de flux d'OpenFlow puissent être exploitées pour fournir de la valeur aux services informatiques. Par exemple, l'un des principaux avantages d'OpenFlow est le caractère centralisé de la FIB. La centralisation permet de calculer des trajets optimums de façon déterministe pour chaque flux, en s'appuyant sur un modèle complet de la topologie de bout en bout du réseau.
Basé sur une compréhension des niveaux de service requis pour chaque type de flux, le contrôleur centralisé OpenFlow peut appliquer des principes d'ingénierie de trafic pour s'assurer que chaque flux est correctement servi. Un avantage de cette fonctionnalité est qu'elle permet au réseau de répondre dynamiquement aux exigences des applications. Il permet également un meilleur usage du réseau sans pour autant sacrifier la qualité du service.
Un autre avantage est que les commutateurs OpenFlow peuvent filtrer les paquets quand ils entrent sur le réseau, et par conséquent, ces commutateurs peuvent agir en tant que pare-feu simples à la périphérie du réseau.
Avec les commutateurs OpenFlow qui prennent en charge la modification des en-têtes de paquets (une fonction optionnelle d'OpenFlow v1.0), le contrôleur OpenFlow pourra également faire en sorte que le commutateur redirige le trafic suspect vers des contrôles de sécurité des couches supérieures, telles que des systèmes IDS / IPS, des pare-feu applicatifs et des systèmes de type Data Loss Prevention (DLP).
Les commutateurs OpenFlow qui prennent en charge la modification des en-têtes de paquets seront également en mesure de fonctionner comme un simple et rentable dispositif d'équilibrage de charge.
Avec la fonction de modification, un nouveau flux peut entraîner une nouvelle entrée dans la table de routage et un flux qui est dirigé vers un serveur sélectionné par le contrôleur OpenFlow pour de l'équilibrage de charge. Afin de créer des politiques d'équilibrage de charge basé sur la charge du serveur, le contrôleur OpenFlow serait obligé de surveiller le pool de serveurs quand ils font état de leurs niveaux de charge.
Appel à l'action
Il ne fait aucun doute que le SDN peut apporter une valeur très importante pour les organisations informatiques. Il ne fait aucun doute que dans le contexte actuel le SDN 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, telle que la mise en oeuvre de SDN pour un cas d'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 nouveaux produits, des protocoles nouveaux ou améliorés et une amélioration de l'interopérabilité.
Les organisations 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 nouvelle 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? »
