Ce chapitre a introduit le paradigme SDN et ses concepts les plus fondamentaux. L’un des objectifs était de montrer que ce paradigme consiste en un ensemble de couches d’abstraction (acheminement,distribution, etspécification) destinées à cacher la nature complexe et dynamique d’un réseau physique. Cela nous a permis également de présenter le contexte et les enjeux qui entourent la dernière couche d’abstraction de ce paradigme, à savoir laNorthbound API. Le chapitre suivant aborde plus en détail cette dernière, notamment en présentant les différents travaux qui ont porté sur la conception et l’implémentation de langages de contrôle de réseaux de haut niveau.
Chapitre 2
État de l’art des langages de contrôle sur l’interface nord de SDN
Après avoir présenté le paradigme SDN ainsi que les principaux concepts qui le définissent, nous nous intéresserons plus particulièrement dans ce deuxième chapitre aux différents travaux de recherche qui ont porté sur la conception et le développement d’une Northbound API. Ainsi, ce chapitre commence par présenter les principaux enjeux et motivations qui sont à l’origine de propositions de nouvelles Northbound API, principalement sous la forme de langages de programmation de haut-niveau. Puis, il introduit avec un certain niveau de détails l’ensemble de ces langages, leurs motivations ainsi que leurs principales contributions. La dernière section du chapitre propose une analyse de l’ensemble de ces contributions, sans pour autant essayer de sélectionner un "gagnant". En effet, nous pensons que chaque langage a apporté des contributions qui ont permis de mieux définir les exigences qui doivent être satisfaites, et les services qui peuvent être fournis par une Northbound API.
2.1 Quels usages ?
Durant des décennies, le monde informatique a connu une prolifération de langages de programmation. Au départ, la principale problématique était d’essayer de remplacer les langages-machine, bas-niveau, spécifiques à chaque constructeur, tel l’assembleur pour les machines x86, par des langages plus fonctionnels et modulaires tels que Java et Python.
Ainsi, industriels et académiques étaient toujours sans cesse à la recherche de nouvelles abstractions qui permettraient de cacher ou, à la rigueur, de simplifier les détails de conception et d’implémentation des plateformes sous-jacentes. Aujourd’hui, nous observons le même phénomène pour les langages de programmation réseau, où l’objectif est de remplacer les instructions de bas-niveau (communément des règles OpenFlow) utilisées par les contrôleurs SDN par des langages de plus haut niveau capablent de fournir des fonctionnalités avancées qui permettront aux programmeurs réseaux d’innover, d’être plus productifs et de se concentrer davantage sur leur problématique métier (sécurité, routage, QoS, etc.) plutôt que sur la maîtrise de la complexité du réseau sous-jacent et des différents équipements hétérogènes qui le composent.
Ainsi, dans ce contexte des réseaux SDN, nous pensons que la conception et
l’utilisation d’un langage de programmation réseau de haut niveau peuvent être motivées, principalement, par ces quatre points :
• Disposer d’abstractions de haut niveau qui permettent de simplifier la configuration des équipements réseaux.
• Améliorer la modularité des programmes de contrôle et permettre aussi leur composition et réutilisation.
• Avoir des modèles de programmation qui permettent de penser des problématiques métiers afin de faciliter le développement des programmes de contrôle.
• Fournir des fonctionnalités plus avancées telles que la vérification formelle des politiques ou la virtualisation de réseaux.
Nous détaillons ces motivations dans les sous-sections qui suivent.
2.1.1 Faciliter la configuration des équipements d’un réseau SDN
Pour configurer un réseau SDN, un administrateur doit utiliser l’API qui est fournie par un contrôleur SDN. Le point commun entre ces API est que toutes reprennent, avec un certain niveau d’abstraction, les principales fonctionnalités du standard OpenFlow. Néanmoins, l’implémentation et l’utilisation d’une API diffèrent suivant le type et la version du contrôleur utilisé. En effet, chaque API définit des modules, fonctions et structures de données qui lui sont propres. De plus, la nature bas-niveau de ces API fait que beaucoup de détails du standard OpenFlow subsistent, tels que la priorité des règles ou le type de protocole utilisé, détails qui sont souvent non pertinents pour la politique de configuration globale.
Ainsi, la plus-value que peut apporter un langage de programmation est de permettre aux administrateurs de s’affranchir de tous ces détails de bas-niveau et de faire en sorte que leur programme de contrôle soit expressif et complètement agnostique au type et à la version du contrôleur utilisé. Pour ce faire, un langage de programmation doit idéalement fournir des abstractions qui permettent de cacher ou de simplifier toutes ces interactions entre les modules de contrôle et l’infrastructure physique comme les messages de commandes qui sont construits puis envoyés pour configurer les équipements OpenFlow ou les requêtes qui remontent des statistiques ou des informations sur la topologie physique.
2.1.2 Modularité et réutilisation
Dans la communauté du génie logiciel, il est communément admis que la modularité et la réutilisabilité sont des propriétés primordiales d’un bon programme informatique, étant donné les gains considérables que cela peut apporter en termes de temps et d’argent. En effet, décomposer un programme en plusieurs composants facilite grandement les phases de développement, de test et de maintenance des programmes. De plus, cela permet leur réutilisation dans d’autres contextes ou sur des infrastructures différentes, simplement en les composant avec d’autres modules existants.
Malheureusement, les API actuelles que fournissent les contrôleurs SDN n’offrent que très peu de possibilités de modularité et de réutilisabilité. En effet, ces API, de bas niveau,
Chapitre 2 : État de l’art des langages de contrôle sur l’interface nord de SDN
sont dépourvues de concepts qui permettraient de regrouper au sein d’un même conteneur logique des actions qui collaborent pour réaliser une même tâche de plus haut-niveau.
De ce fait, un langage de programmation réseau permettrait d’écrire des programmes de contrôle qui soient plus modulaires et réutilisables. Un administrateur pourra ainsi développer des fonctions et des modules de contrôle indépendants qui représenteront ses principaux services réseaux (contrôle d’accès, transport, équilibrage de charge, etc.). Par la suite, ces modules pourrant être composés ensemble afin d’obtenir des politiques de contrôle plus élaborées et réalistes.
2.1.3 Modèle de programmation métier
Un aspect primordial d’un langage de programmation réseau est le fait qu’il doit être un langage métier. Concrètement, le langage doit fournir un modèle de programmation et des structures de données qui permettent aux administrateurs de penser leurs problématiques réseaux d’une manière simple et intuitive. Ce modèle de programmation doit, entre autre, permettre de décrire les divers types de services rencontrés, la manière dont ces services seront composés et chaînés entre eux et cela dans divers contextes d’utilisations (réseaux d’entreprise, réseaux d’opérateurs, etc.).
2.1.4 Fonctionnalités avancées
En plus de ces fonctionnalités de base qui sont assurées par presque tous les langages qui ont été proposés (de façon et à des niveaux différents), un certain nombre de fonctionnalités plus avancées peuvent être aussi fournies, permettant ainsi d’ajouter une plus-value au langage. Nous en citons-ici les plus importantes :
• verification formelle : être capable de vérifier, formellement, la sémantique d’un programme de contrôle.
• virtualisation de réseau : permettre de créer et de spécifier des topologies et des programmes virtuels afin de se détacher complètement de l’infrastructure physique.
A noter que notre travail et contribution s’inscrivent dans ce contexte bien précis.
• performance: faire en sorte de pousser le plus possible le traitement au niveau des équipements qui sont présents dans le plan de données et n’exécuter au niveau du contrôleur que ceux qui sont expressément souhaités.
• tolérance aux fautes: le langage et son système d’exécution doivent être capables, à partir d’une défaillance qui se produit dans le réseau, d’installer des chemins de secours soit d’une manière proactive (à l’initialisation), soit d’effectuer des modifications en cours d’exécution sur la configuration courante.
2.2 Langages de contrôle existants