Introduction aux technologies SDN: évolution ou révolution architecturale?
Cet article expert tente de décrypter ce qui se cache derrière le concept de SDN, ou réseaux programmables. Un concept où partisans du contrôle centralisé et du contrôle distribué des réseaux s’affrontent.
S'il n'existe pas de définition claire et unique du concept de SDN (Software defined Networking) ou de réseaux programmables, il existe aujourd'hui deux camps parmi les rangs des protagonistes des SDN,ayant chacun leur point de vue : d'un côté les puristes, de l'autre les pragmatiques. Les "puristes" croient en une gestion et un contrôle centralisés de l'acheminement des paquets au sein du réseau, tandis que "les pragmatiques" s'appuient sur des principes d'architecture distribuée dans laquelle la prise de décision quant au routage des paquets épend de l'ensemble des éléments du réseau. Chaque stratégie SDN a ses points forts et sera mise en œuvre en fonction du scénario d'usage.
Le problème des réseaux traditionnels
Les commutateurs présents sur les réseaux physiques acheminent les informations sous la forme de paquets en s'appuyant sur la connaissance combinée de différents éléments, notamment l'adresse réseau intégrée aux paquets, des informations d'ordre topologique et la connectivité du réseau proprement dit. Pour un paquet donné, les tables d'acheminement renseignent chaque équipement sur le port à utiliser en guise de destination. Dans les réseaux traditionnels, ces tables sont élaborées via l'échange d'informations de topologie et d'état à l'échelle des différents équipements réseau. Ce sont des paquets de contrôle spécifiques qui gèrent ce processus de découverte. La table de découverte et d'acheminement est donc appelée « plan de contrôle » et se distingue du « plan de données », plan sur lequel sont manipulés les paquets de données.
Toutefois, un comportement de découverte et d’adaptation autonome entrave l'ingénierie du trafic, la prévision des performances ou encore la création rapide et ordonnée de reprises sur incident. Les problèmes de réseau engendrent un désordre temporaire lorsque les équipements tentent de découvrir de nouveaux chemins. Lorsque c’est le cas, les pertes et les retards d'acheminement de données peuvent être considérables. Par ailleurs, aucun équipement n'est pleinement conscient de la contribution que ses pairs sont susceptibles d'apporter au trafic de ces données. Les calculs de charge et la qualité de service, ou QoS (Quality of Service) deviennent donc difficiles à sécuriser.
Les puristes SDN et le modèle des contrôleurs centralisés
Le modèle puriste des technologies SDN est apparu lorsque la recherche a eu pour objectif de remplacer la découverte adaptative par un contrôle centralisé de l'acheminement. Dans cette architecture, un processus logiciel central - le contrôleur SDN centralisé - administre l'intégralité de la topologie du réseau, ainsi que l'état de ses équipements et tronçons, et appréhende son adressage et sa connectivité du point de vue de l'utilisateur.
Ce processus central fait alors appel à différents algorithmes et politiques pour définir, au sein du réseau, les chemins destinés à chaque flux autorisé. Ces chemins sont créés en ordonnant à tous les équipements qui s'y trouvent de modifier leurs tables d'acheminement, afin de transmettre correctement les paquets sur un chemin spécifique. Par conception, le protocole OpenFlow constitue le langage qu'utilise le contrôleur central pour communiquer aux équipements du réseau les modifications apportées aux tables d'acheminement. Cette communication peut s'effectuer de manière proactive selon une carte du réseau ou en réaction à une demande d'instructions émanant d'un équipement sur la manière de gérer un paquet pour lequel il ne dispose d'aucune entrée d'acheminement.
Toute la difficulté de cette approche SDN centralisée tient à l'absence d’un modèle de contrôle centralisé éprouvé. Si Internet et son fondement IP ont fait la preuve de leur capacité d'évolution à l'échelle de l'univers en ligne actuel, rien ne prouve en revanche qu'un contrôle centralisé de la mise en réseau puisse faire montre d'une telle évolutivité. Qui plus est, aucune technologie couramment acceptée ne permet de tester ces capacités.
La technologie SDN centralisée va donc tout d'abord avoir faire ses preuves dans des déploiements internes, à l'échelle d'un datacenter ou d'un opérateur de cloud. En effet, les problèmes d'évolutivité et de contrôle centralisé sont plus faciles à gérer au sein d'un datacenter, d'un cloud, d'un réseau de mise à disposition de contenus ou d'un noyau WAN, qu'à l'échelle d'Internet, voire d'un WAN d'entreprise.
Déployer une technologie SDN centralisée dans ces domaines internes permet des développements rapides et à grande échelle. Au fil du temps, les organismes de normalisation et fournisseurs sauront trouver une manière optimale d'interconnecter des domaines SDN disparates au sein d'un réseau complet de bout en bout. Une fois cette interconnexion mise en œuvre - si tant est qu'elle soit possible - l'état des modèles SDN centralisé et distribué permettra une comparaison, et la question de la technologie SDN idéale trouvera alors sa réponse.
Technologie SDN distribuée ; l'évolution plutôt que la révolution
Mais pour le moment, de nombreux experts et fournisseurs considèrent cette stratégie SDN centralisée, aussi pur que soit son fondement, comme une approche révolutionnaire superflue ; la voie de l'évolution étant plus prudente. En matière de génération de tables d'acheminement, la découverte adaptative tire sa légitimité de décennies d'utilisation, et notamment du succès du protocole IP en tant que fondement d'Internet. Aux yeux de ce groupe partisan, qui compte nombre d'experts IP et de constructeurs d'équipements de routage, le logiciel tenu de définir le comportement du réseau se trouve à un degré d'abstraction supérieur ; il peut même s'agir d'un logiciel.
La stratégie SDN centralisée préconise de remplacer les processus logiciels hébergés sur différents équipements (routeurs, commutateurs..) pour les remplacer par un contrôleur unique pour décider des comportement d'acheminement, là où le modèle distribué ajoute aux réseaux IP et Ethernet traditionnels, des mécanismes de contrôle des logiciels et (de plus en plus) du cloud.
À l'instar de ce modèle centralisé, la technologie SDN distribuée admet la nécessité de collecter des informations sur l'état du réseau, et de les rassembler à un emplacement central depuis lequel les éléments du réseau peuvent être contrôlés en vue, par exemple, de gérer les performances. Reste que l'objectif du modèle SDN distribué consiste à proposer un comportement plus contrôlable, et qu'il pourrait être atteint en tirant parti de protocoles d'extension tels que PCC/PCE/PCRF (fonction de règles de charge et de politique), MPLS et GRE.
Au sein de ces protocoles, l'aspect prépondérant reste une mise en réseau contrôlée par des politiques. Des principes de mise en réseau virtuelle, tels que ceux employés par Nicira (société récemment acquise par VMware), pourraient rendre les technologies Ethernet et IP plus efficaces en termes d'informatique en cloud et d'applications en réseau virtuel, et permettraient de les placer plus facilement sous forme de couche au-dessus du modèle évolutif. Ce processus s'exécuterait via une prise de décision distribuée.
Le défi auquel se heurte la technologie SDN distribuée tient à ce qu'elle doit encore prouver qu'elle est en mesure de proposer un contrôle du trafic et de la connectivité la hauteur de ce que les technologies SDN centralisées prétendent offrir. Ici encore, on retrouve le problème d'une infrastructure adaptée à la mise en application des principes de la technologie SDN distribuée. Nombre d'utilisateurs craignent que ce modèle SDN ne devienne propriétaire, car les fournisseurs travaillent à l’intégrer à leurs systèmes fermés existants.