Il n’est pas possible de parler de SDN sans se tourner vers l’organisation ONF (Open Networking Foundation) qui porte, aujourd’hui, le concept « Open SDN » d’origine ayant été connu comme étant associé au protocole OpenFlow. Leur message est clair : « Transforming Networks into Agile Platforms for Service Delivery ». Lorsqu’on analyse leur définition, on retrouve la description des trois plans d’un équipement réseau avec le fait de séparer physiquement le « Control Plane » du « Data Plane », en poursuivant l’objectif d’offrir un « Control Plane » commun ayant une vue centralisée du réseau afin d’apporter une synchronisation adaptée.
La volonté de désagrégation des éléments réseau a entrainé plusieurs conséquences. La première a été de devoir structurer le modèle en couches autour du contrôleur SDN [0].
Des implémentations, sous forme de produits Open Source, se sont multipliées pour donner aussi naissance à des offres commerciales [7]. Dans les produits Open Source, on peut citer le contrôleur SDN le plus connu ODL (OpenDaylight), mais aussi ONOS le système d’exploitation orienté SDN, Floodlight essentiellement porté par des ingénieurs de Big Switch Networks, OpenContrail et la librairie Python RYU utilisée, entre autre, par la NSA. Beaucoup d’autres noms sont disponibles dans la littérature, mais leur maintient à jour est douteux face à ceux qui se sont implantés dans le domaine.
La couche « Control Layer » ou « Control Plane » représente le contrôleur SDN et elle communique avec le matériel de la couche « Infrastructure Layer » ou « Data Plane » au travers d’une interface appelée « Southbound APIs ». Le protocole OpenFlow n’est qu’un exemple d’implémentation d’une interface « Southbound » et son objectif n’est en aucun cas d’effectuer des configurations sur les matériels, mais uniquement de modifier la table des flux. C’est pour cette raison que des protocoles comme NETCONF, BGP, OVSDB, SNMP, mais aussi CLI et bien d’autres sont utilisables en interface « Southbound ». Le projet OpenDataPlane propose des APIs Open Source pour interagir de façon transparente, avec le « Data Plane » de différents matériels.
Dans la littérature réseau, la FIB (Forwarding Information Base) porte souvent le nom de « Forwarding Table » ou « MAC Table » en référence aux adresses Ethernet MAC, ou encore « CAM Table » en référence à la mémoire CAM (Content-Addressable Memory). Sans l’utilisation d’une table, un switch se comporterait comme un hub Ethernet et enverrait l’ensemble des trames sur tous les ports. Parfois, on peut faire la distinction entre les éléments mis en œuvre pour traiter le niveau 2 du modèle OSI (FIB) et ceux utilisés pour prendre des décisions au niveau 3 (RIB ou Routing Information Base), mais quoi qu’il en soit admettre le vocabulaire suivant :
- MAC Switching, pour lequel la décision de transmission est prise sur l’adresse MAC
- IP Routing, pour lequel la décision de transmission est prise sur l’adresse IP
- Flow Forwarding, pour lequel la décision de transmission est prise, de façon réactive ou proactive, sur le flux
A titre d’illustration, l’étude de l’architecture Open vSwitch permet de comprendre le positionnement du protocole OpenFlow pour la mise à jour de la table des flux et du protocole OVSDB, décrit dans le RFC 7047, pour la configuration du commutateur virtuel.
La couche « Control Layer » communique avec la couche « Application Layer » ou « Application Plane » au travers d’une interface appelée « Northbound APIs ». Les APIs REST (Representational State Transfer) sont généralement utilisées pour implémenter l’interface « Northbound » et permettre le développement de modules complémentaires qui viennent enrichir les fonctionnalités du contrôleur.
Pour information, les interfaces « Eastbound » et « Westbound » sont utilisées pour les communications inter-contrôleurs.
Mais le fait est que, comme souvent et malgré une adoption par de gros acteurs, la révolution annoncée autour du protocole OpenFlow n’a pas eu lieu [5]. Au-delà de l’idée de départ, on trouve maintenant de nombreuses technologies qui tournent, de façon plus ou moins liée, autour du « Software-Defined Networking », et qui chacune revendique l’appellation de SDN. Un bon exemple est la notion d’automatisation qui se réclame d’être une forme de programmation du réseau par le logiciel.
