Le contrôleur est la clef de voûte du réseau défini par logiciel (SDN). Si névralgique que différentes approches existent avec d’incessantes innovations en matière de solutions proposées.
La séparation des plans de données et de contrôle est consubstantielle de la notion de SDN. L’émergence de ce concept constitue une percée incroyable dans le domaine des réseaux avec des notions d’efficacité, de souplesse, de réactivité, d’optimisation des ressources et d’automatisation. Autant d’avantages qui sont intrinsèquement liés au contrôleur. Ce dernier est bien la pierre angulaire du SDN tant et si bien qu’il est essentiel d’en définir les pourtours.
Le réseau défini par le logiciel (SDN pour Software Defined Network) rend les réseaux programmables par le biais d’un contrôleur et d’API (interface de programmation applicative).
En virtualisant le réseau, le SDN ajoute de facto un niveau d’abstraction aux fonctionnalités des équipements, tels que les routeurs et commutateurs, afin d’en optimiser le déploiement et les performances. L’intelligence est donc poussée dans le contrôleur, véritable épine dorsale du réseau virtualité.
Plasticité du réseau
Le contrôleur du SDN embarque des modules « enfichables » capables d’effectuer différentes tâches, comme l’inventaire des périphériques, la collecte de statistiques du réseau…Des extensions peuvent aussi être ajoutées afin d’offrir des fonctionnalités encore plus avancées : exécution d’algorithmes pour effectuer des analyses ou orchestration de nouvelles règles sur tout le réseau.
Le contrôleur permet ainsi d’orchestrer une myriade de tâches sur le réseau. Il en résulte une très grande rapidité de déploiement de celles-ci. Si la souplesse et la réactivité amenées par le contrôleur sont donc l’apanage du SDN, le contrôleur se traduit également par une très grande plasticité du réseau qui peut être modifié à la volée pour supporter plus de charges.
On peut sans conteste dire que le contrôleur du SDN endosse le rôle de système d’exploitation (OS) du réseau. En retirant l’intelligence de l’équipement et en l’exécutant en tant que logiciel, il facilite la gestion automatisée du réseau ainsi que l’intégration et l’administration des applications métier. Un contrôleur SDN représente de ce fait un véritable cerveau virtuel du réseau et offre une meilleure vue de tous les processus aux administrateurs. Il permet de réduire les coûts opérationnels, d’augmenter la fiabilité et la stabilité de fonctionnement ainsi que d’améliorer l’efficacité globale.
API southbound et northbound
L’interaction entre le contrôleur et les équipements déployés est communément appelée interface de programmation d’application (API) southbound, le protocole Open Source le plus populaire en la matière étant OpenFlow. Le premier contrôleur SDN s’appelait NOX, développé initialement par Nicira Neworks avec OpenFlow précisément. Parmi les autres protocoles qui peuvent être utilisés par un contrôleur, on trouve également OVSDB, YANG et NetConf.
Au pôle opposé, on trouve l’API northbound, qui chapeaute la communication d’une application métier au contrôleur. Les interfaces northbound offrent d’énormes possibilités de programmation de réseau, comme la création d’applications pouvant automatiser toutes les tâches de réseautage.
Solutions constructeurs vs Open Source
Basé sur Java et dérivé de la conception Beacon, OpenDaylight (ODL) est le contrôleur de la Fondation Linux. Il supporte OpenFlow et d’autres API southbound (telles que Cisco OpFlex) et comprend des fonctionnalités critiques telles que une haute disponibilité et le clustering.
D’autres acteurs planchent sur des solutions alternatives. Ainsi, un groupe de travail de l’Internet Engineering Task Force (IETF), appelé i2rs, développe une norme SDN qui permet à un contrôleur d’exploiter des protocoles traditionnels éprouvés, tels qu’OSPF, MPLS, BGP et IS-IS.
Une bataille fait rage entre les fournisseurs de réseaux, qui souhaitent fournir leurs propres contrôleurs SDN pour déployer leurs équipements (et potentiellement les équipements d’autres fournisseurs), et les contrôleurs Open Source, conçus pour que tous les fournisseurs puissent les prendre en charge.
Il faut avoir conscience que le type de protocoles pris en charge peut grandement influencer l’architecture globale du réseau. A titre d’exemple, alors qu’OpenFlow tente de centraliser complètement les décisions de transmission de paquets, i2rs divise la prise de décision en exploitant les protocoles de routage traditionnels pour exécuter le routage de manière distribuée et permettre aux applications de modifier les décisions en la matière.
Chemin de contrôle distribué
L’industrie du réseau a largement débattu des avantages et des inconvénients des architectures de réseau fortement centralisées en opposition à celles qui sont hautement distribuées. En général, la notion de centralisation est synonyme de rapidité et de simplicité en matière de gestion. La décentralisation vient avec la capacité d’extension et la redondance.
La première approche est le contrôleur centralisé. Dans ce cas précis, un contrôleur gère tous les éléments d’acheminement du système et conserve une vue globale de l’ensemble du réseau.
La plupart des contrôleurs SDN fonctionnent aujourd’hui de cette façon (ONOS, ODL…).
La deuxième approche est le chemin de contrôle distribué (« distributed control path » en anglais). Dans ce cas, un contrôleur local s’exécute sur chaque nœud de calcul et gère l’élément de transfert directement et localement. Ainsi, le plan de contrôle est distribué sur le réseau. Cependant, la topologie du réseau virtuel doit être synchronisée sur tous les contrôleurs locaux, ce qui se fait en utilisant une base de données distribuée.
Si l’option centralisatrice était la norme lors des débuts du SDN, plusieurs facteurs poussent aujourd’hui les organisations à considérer l’autre option. En particulier la question de la haute disponibilité. Un point névralgique car, dans le SDN, toute faillite du contrôleur (s’il chapeaute tout le réseau) devient critique. En effet, si une attaque compromet le contrôleur unique, toute la gestion du réseau est alors potentiellement perdue.
