Software Defined Networking (SDN) Etat de L’art

Software-Defined Networking (SDN)

Définition

Selon l’ONF (Open Network Fundation) [12] (un consortium d’entreprises à but non lucratif fondé en 2011 pour promouvoir SDN et normaliser ses protocoles) SDN est une architecture qui sépare le plan de contrôle du plan de données, et unifie les plans de contrôle dans un software de contrôle externe appelé Contrôleur, pour gérer plusieurs éléments du plan de données via des APIs (Application Programming Interface).
En d’autres termes, on peut dire qu’une architecture réseau suit le paradigme SDN si elle vérifie les points suivants :
▪ Le plan de contrôle est complètement découplé du plan de données, cette séparation est matérialisée à travers la définition d’une interface de programmation (Southbound API)
▪ Toute l’intelligence du réseau est externalisée dans un point logiquement centralisé appelé contrôleur SDN, ce dernier offre une vue globale sur toute l’infrastructure physique.
▪ Le contrôleur SDN est un composant programmable qui expose une API (NorthboundAPI) pour spécifier des applications de contrôle.

Différence entre un réseau SDN et un réseau traditionnel

Traditionnellement, un réseau informatique est composé d’équipements réseau interconnectés tels que des switchs et des routeurs. Dans chaque équipement, nous trouvons un mécanisme de transmission dans la couche de transmission et un plan de contrôle qui incorpore le système d’exploitation et les applications. Dans ce modèle, les équipements réseau sont fermés et nous n’avons aucune possibilité d’ajouter une nouvelle application. De plus, avec cette approche traditionnelle de gestion des réseaux, chaque équipement doit être configuré indépendamment. Ce qui est non seulement lourd et fastidieux, mais induit aussi le risque de ne pas avoir l’uniformité dans les configurations. D’où le SDN pour permettre la centralisation des configurations.
Le SDN a pour idée de simplifier la gestion des réseaux et de quitter l’architecture distribuée, pour revenir à un système de gestion centraliser du réseau afin de gérer plus facilement les réseaux. La figure 2.1 donne un aperçu sur la différence entre l’architecture traditionnelle et le SDN.

Architecture SDN

L’architecture SDN est constituée de trois couches à savoir la couche infrastructure, la couche de contrôle et la couche application. Ces différentes couches se communiquent via les interfaces Southbound, Northbound et East-Westbound APIs comme l’indique la figure 3
Nous décrivons dans la suite ces couches ainsi que les interfaces de communication entre les couches.
La couche la plus basse est la couche de transmission, aussi appelée plan de données. Elle contient les équipements de transmission (FEs : Forwarding Element) tels que les switchs physiques et virtuels. Son rôle principal est de transmettre les données, surveiller les informations locales et collecter les statistiques. La couche de contrôle, également appelée plan de contrôle, est constituée d’un ou de plusieurs logiciels de contrôle (Contrôleurs), ces contrôleurs utilisent des interfaces Sud ouvertes pour contrôler le comportement des FEs et communiquent via des APIs Nord avec la couche supérieure pour superviser et gérer le réseau. La couche d’application (la plus haute dans la figure3) héberge les applications qui peuvent introduire de nouvelles fonctionnalités réseau, comme la sécurité, la configuration dynamique et la gestion. La couche d’application exploite la vue globale et distante du réseau offerte par le plan de contrôle pour fournir des directives appropriées à la couche de contrôle.

Le Southbound API

L’interface entre la couche infrastructure et la couche de contrôle est appelée Southbound API ou interfaces Sud. Les Southbound APIs représentent les interfaces de communication, qui permettent au contrôleur SDN d’interagir avec les équipements de la couche d’infrastructure, tel que les switches, et les routeurs. OpenFlow est le Southbound API le plus souvent utilisé dans l’architecture SDN permettant la programmation du plan de données. Bien qu’OpenFlow est le Southbound API le plus utilisé et même le standard de facto, il y a aussi plusieurs autres Southbound API pour gérer les communications entre ces deux niveaux de l’architecture SDN, tels que Forwarding and Contrôle Element Separation (ForCES) [13] et OpFlex [14].

Le Northbound API

L’interface entre la couche de contrôle et la couche application est le Northbound API ou l’interface nord qui est une des abstractions clés de l’environnement SDN. Il fournit généralement une liste des fonctions réseaux de base associées au fournisseur, qui est ensuite utilisées pour configurer un équipement spécifique à l’utilisateur, et le contrôleur l’interprète dans un langage que chaque équipement réseau peut comprendre. Au moment de la rédaction de ce mémoire, il n’existe aucun standard intervenant entre la couche de contrôle et celle d’application du côté d’ONF ou d’autres organisations. C’est pourquoi ONF a créé un groupe de travail pour élaborer un protocole standard sur cette interface. Il existe actuellement plusieurs types de contrôleurs SDN qui offrent une grande variété de Northbound API. Les Northbound API peuvent être classées principalement en trois catégories, à savoir les API REST (REpresentational State Transfer) [16], les API ad hoc spécialisées et les langages de programmation tels que Procera [17], Frenetic [18].
L’API REST est le plus utilisé car il fournit une intégration simple et permet une interaction minimale entre un client et un serveur. L’API REST est l’œuvre de Roy Thomas Fielding qui a aussi participé à la définition du protocole HTTP.

Le East Westbound API

L’interface qui permet aux contrôleurs de partager une vue commune du réseau et de coordonner l’exécution des règles et des protocoles est l’API East Westbound ou interfaces Est/Ouest. C’est à travers cette interface qu’est gérée la manière dont les contrôleurs du SDN interagissent les uns avec les autres pour partager des informations. Pour obtenir une vue globale de l’ensemble du réseau, les opérateurs de réseau utilise les API East-Westbound pour faire communiquer les contrôleurs les uns avec les autres et partager les vues du réseau. Une interface East-Westbound est également importante pour automatiser les décisions de réseau afin de limiter les interventions des administrateurs réseaux sur des réseaux opérateurs de grande envergure.
Un avantage considérable dans le développement du SDN est que la plupart de ces interfaces sont du domaine ouvert (disponible sous licence open source). ALTO et HyperFlow sont des exemples de protocoles (Eastbound et Westboud) utilisés entre les contrôleurs en cas d’utilisation de plusieurs contrôleurs.

La couche de contrôle

Le rôle de la couche de contrôle est de contrôler et de gérer les équipements de l’infrastructure, et de les relier avec les applications. Il est composé d’un ou de plusieurs contrôleurs et il est considéré comme système d’exploitation du réseau. Les premières versions du SDN présentent un plan de contrôle composé d’un seul contrôleur centralisé. Par la suite des architectures distribuées utilisant plusieurs contrôleurs ont été proposées pour améliorer les performances et la scalabilité du réseau.

Le protocole OpenFlow

Le protocole OpenFlow est actuellement considéré comme un protocole utilisé comme une interface Sud dans les architectures basées sur SDN, cependant, dans ses débuts il a été la première implémentation réelle du concept SDN avec toute une architecture composée par les switchs, une chaine de communication sécurisée et un contrôleur de référence. Le protocole OpenFlow a été initialement proposé et implémenté par l’université de Stanford, et il a été standardisé par la suite par l’ONF.

L’architecture du protocole OpenFlow

L’architecture d’OpenFlow est une implémentation réelle des réseaux SDN, nous la détaillons ici pour bien comprendre les concepts SDN. Cette architecture est basée sur trois composantes : (1) l’infrastructure appelée aussi le plan de données, composée des commutateurs OpenFlow ; (2) le plan de contrôle, constitué par un ou plusieurs contrôleurs ; (3) la chaîne sécurisée qui connecte les commutateurs avec le plan de contrôle. Un commutateur OpenFlow est un équipement de transmission qui contient des tables de flux ou flow table comme l’indique la figure 4. Ces tables de flux contiennent un ensemble d’entrées aussi appelées règles, où chacune est constituée par les champs d’en-tête, des compteurs et des actions.
Les champs d’en-tête d’une entrée contiennent les informations nécessaires pour déterminer le paquet auquel cette entrée sera appliquée. Pour permettre une transmission rapide des paquets avec OpenFlow, le commutateur utilise une mémoire de type TCAM (Ternary Content Addressable Memory) qui permet une recherche rapide des masques. Le champ d’en-tête peut aussi identifier différents protocoles selon les spécifications d’OpenFlow, comme Ethernet, IPv4, IPv6 ou MPLS. Les Compteurs sont réservés à la collecte des statistiques de flux. Ils enregistrent le nombre de paquets et d’octets reçus et la durée des flux dans la mémoire temporaire. Les Actions spécifient comment les paquets d’un flux seront traités. Les Actions communes sont : transmettre, supprimer, modifier le champ, etc. Le contrôleur est responsable de l’installation et de la mise à jour des tables de flux des commutateurs. En insérant, modifiant et supprimant les entrées de flux, le contrôleur peut modifier le comportement des commutateurs en ce qui concerne la transmission.

NOX

NOX est le premier contrôleur disponible au public écrit en langage C, l’utilisation d’un seul thread dans son cœur limite son déploiement. Plusieurs dérivations du NOX ont été proposées plus tard, notamment le Nox dans sa version multithread appelée NOX-MT, le QNOX, NOX supportant la qualité de service (QoS), FortNOX, une extension du NOX implémentant un analyseur de détection des conflits dans les règles de flux causées par les applications, et enfin, le contrôleur POX un contrôleur basé sur NOX en langage python, dont le but est d’améliorer les performances du contrôleur original NOX.

OpenDayLight

OpenDayLight est un contrôleur SDN Open source modulaire qui permet de concrétiser la virtualisation des fonctions réseaux à travers une définition cohérente de ses interfaces de programmation. Conçu en Java et en Python, le contrôleur OpenDayLight est multiplateforme et fait partir des contrôleurs distribués. Considéré comme une référence dans la programmabilité des réseaux, OpenDayLight permet à ses utilisateurs et équipementiers de personnaliser leurs solutions de gestion des réseaux selon leurs besoins. Depuis son introduction, OpenDaylight a connu plusieurs versions dont chaque version apporte soit des correctifs, des nouveaux services ou le support des nouveaux protocoles. OpenDayLight est très largement adopté par les intégrateurs et par l’industrie des équipements. L’architecture de la plateforme OpenDaylight, représentée sur la figure 6, est basée sur le Model-Driven Service Abstraction Layer (MD-SAL) où les équipements réseaux et les applications sont représentés sous forme d’objets ou de modèles dont les interactions sont traités dans la couche d’abstraction appelé Service Abstraction Layer (SAL). Le SAL est un élément très important du contrôleur OpenDaylight, permettant d’assurer le mécanisme d’échange et d’adaptation de données entres les modèles YANG 24, représentant les équipements réseaux et les applications. Il permet aussi de faciliter l’intégration d’une nouvelle Southbound API pour le développement des services sans lien avec les API utilisées pour les implémenter.
OpenDaylight est un framework modulaire et multi-protocoles. Cet aspect permet aux utilisateurs d’OpenDaylight de choisir et d’installer uniquement les services et protocoles adaptés à leurs contextes. Cela permet aussi aux utilisateurs de résoudre des problèmes complexes en choisissant une combinaison des outils et protocoles qui les intéressent.
Du point de vue sécurité, OpenDaylight est conçu pour fournir l’authentification, l’autorisation, la traçabilité ainsi que la détection et la sécurisation automatique des équipements.