L’intérêt qu’a suscité le paradigme SDN a fait que, en l’espace de quelques années, beaucoup de travaux ont été menés au sein de la communauté de gestion de réseaux afin de proposer des Northbound API métiers et modernes, principalement sous la forme de langage de programmation haut niveau. De par leurs contributions, chacun de ces travaux a permis de faire évoluer les exigences et le type de fonctionnalités que nous attendons d’une Northbound API. Néanmoins, en dépit de ces nombreux travaux, aucun consensus n’a pu être dégagé quant à la nature et au rôle précis de la Northbound API, notamment son niveau d’abstraction et le type de fonctionnalités qu’elle doit proposer. Ainsi, l’objectif premier de ce chapitre a été de présenter une synthèse de ces travaux et une analyse de leurs principales contributions à la problématique de conception et d’implémentation d’une Northbound API.
A la fin de cette étude, nous avons constaté que l’approche de virtualisation de réseau devient de plus en plus incontournable pour une Northbound API, étant donné les gains considérables que cela peut apporter, en termes d’expressivité, de modularité et de flexibilité, pour les langages de contrôle. En effet, disposer d’une vision abstraite de l’infrastructure physique, avec seulement les détails les plus pertinents pour les politiques de contrôle de haut niveau, permettrait de simplifier grandement leur expression.
Parmi les langages présentés dans ce chapitre, les plus récents d’entre eux (notamment Pyretic, Merlin et Splendid Isolation) ont eu recours à la virtualisation de réseau afin d’assurer diverses propriétés telles que la montée en abstraction ou le partage des ressources. Pour ce faire, ces derniers se sont basés sur des modèles d’abstraction afin de cacher la nature complexe et dynamique de l’infrastructure physique. Toutefois, la plupart de ces travaux manipulent des abstractions dans un objectif bien précis : par exemple, Splendid Isolation dans le but d’isoler des programmes de contrôle ou encore Merlin pour résoudre des problèmes de satisfaction de contraintes sur des chemins réseau. Il en résulte des interfaces nord qui sont orientées vers ces spécificités. Dans notre cas, nous ciblons des politiques de contrôle réseau métiers de haut niveau, non dédiées à un objectif ou domaine particulier. Ainsi, les modèles d’abstraction utilisés par ces travaux ne nous paraissent pas appropriés dans notre contexte. Dans le chapitre suivant, nous reviendrons plus en détails
sur ces modèles d’abstraction, leurs avantages et inconvénients, puis nous détaillerons notre proposition de modèle d’abstraction sur lequel notre langage de programmation réseau est bâti.
Deuxième partie
Chapitre 3
Le modèle d’abstraction Edge-Fabric
Ce chapitre a pour objectif de présenter le nouveau modèle d’abstraction que nous préconisons pour les langages de programmation SDN supportant la virtualisation de réseau. Dans un premier temps nous présentons les exigences que nous avons identifiées pour un plan de contrôle SDN se présentant sous la forme d’un langage de programmation réseau. Puis, nous introduirons l’approche de virtualisation de réseau. Dans un second temps, nous présenterons les modèles d’abstraction qui ont été utilisés par les langages de programmation existants. Enfin, nous détaillerons notre modèle d’abstraction qui est basé sur l’idée clé de séparation entre les fonctions de cœur et de bordure de réseau.
3.1 Exigences pour un plan de contrôle SDN modulaire et flexible
Tout le paradigme SDN est basé sur l’idée clé de séparer le plan de contrôle du plan de données et de le placer dans un point logiquement centralisé. C’est notamment à travers cette séparation que le paradigme SDN est parvenu à introduire de la modularité et de la flexibilité dans les modules de contrôle, comparé aux infrastructures traditionnelles. Ainsi, pour être en cohérence avec les fondements du paradigme SDN, un plan de contrôle, exposant ses services sous la forme d’un langage de programmation réseau, devrait satisfaire les trois grandes exigences suivantes :
• Expressivité : le langage doit être orienté métier, tant par sa syntaxe que par son modèle de programmation. Plus concrètement, le langage doit permettre aux administrateurs de décrire, le plus simplement possible, des services réseaux et leurs interactions (le comportement du réseau), plutôt que de spécifier comment ces services vont être mis en œuvre sur les équipements physiques (leur implémentation concrète).
• Modularité et réutilisation : les administrateurs réseaux doivent être en mesure de mettre en œuvre leurs fonctions réseau en tant que modules séparés qui peuvent être, d’une part, facilement composés pour construire des programmes de contrôle élaborés, et d’autre part, réutilisés sur différentes infrastructures physiques.
• Flexibilité : le langage doit permettre de spécifier des politiques de contrôle qui répondent à la diversité des fonctionnalités actuelles (par exemple, le routage, le contrôle d’accès ou la surveillance), et dans divers contextes d’utilisation (par exemple, les réseaux de campus, centres de données ou réseaux d’opérateurs). De plus, le langage
ne doit pas imposer des restrictions trop fortes pour être en mesure de répondre, dans la mesure du possible, aux évolutions futures.
3.2 Virtualisation de réseau
La virtualisation de réseau peut aider à réaliser les exigences précédemment présentées. En effet, la virtualisation de réseau est une approche qui propose de découpler les fonctionnalités du réseau de l’infrastructure physique. Ainsi, un environnement réseau supporte la virtualisation de réseau s’il permet la définition et la coexistence de réseaux virtuels, où chacun d’entre eux inclut plusieurs composants et liens virtuels qui partagent les ressources de l’infrastructure physique sous-jacente [Chowdhury and Boutaba, 2009,
Chowdhury and Boutaba, 2010].
Actuellement, il existe plusieurs motivations à virtualiser des ressources, nous en citons ci-dessous les principales[Jain and Paul, 2013] :
• Partage : quand une ressource est trop "grande" pour un seul utilisateur, sa virtualisation permet de la partager entre plusieurs utilisateurs, optimisant ainsi son utilisation.
• Agrégation : si une ressource est trop petite, la virtualisation peut permettre de regrouper plusieurs de ces petites ressources en une seule, qui pourra être par la suite allouée à un utilisateur.
• Isolation : les utilisateurs de ressources ne devraient pas être capable de surveiller ou d’interférer dans les ressources virtuelles des autres utilisateurs, même s’ils partagent la même ressource physique.
• Réservation dynamique : les ressources virtuelles sont beaucoup plus simples à réserver, à déplacer et à détruire.
• Facilité de gestion : à travers des abstractions, la virtualisation peut significativement simplifier la gestion d’une infrastructure physique en n’exposant que les informations qui sont essentielles pour l’administrateur.
Parmi ces motivations, faciliter la gestion d’une infrastructure physique en est peut-être la plus importante[Casado et al., 2010], surtout dans ce contexte de Northbound API où la
virtualisation réseau peut apporter des gains considérables quant à la facilité de spécification, modularité et réutilisabilité des programmes de contrôle réseau. En effet, penser et écrire des modules ou des programmes de contrôle sera une tâche beaucoup plus simple et moins sujette aux erreurs, étant donné que les administrateurs spécifieront leurs politiques sur des visions abstraites (topologies virtuelles) de l’infrastructure physique. Ces topologies virtuelles n’exposeront alors que les informations les plus pertinentes et essentielles pour les politiques de contrôle des administrateurs. Idéalement, ces visions abstraites devraient aussi introduire des frontières logiques entre les différents types de politiques afin d’éviter tout couplage fort entre elles, améliorant ainsi la modularité des programmes de contrôle. Enfin, étant donné que les politiques sont écrites au-dessus de topologies virtuelles, elles seront alors complètement détachées de l’infrastructure physique, leur permettant ainsi, d’une part,
Chapitre 3 : Le modèle d’abstraction Edge-Fabric
d’être toujours valides en cas de mise à jour ou changement au niveau de l’infrastructure physique sous-jacente, et d’autre part, d’être réutilisées dans d’autres contextes et sur différents réseaux.
Néanmoins, pour exploiter au mieux la virtualisation de réseau et obtenir le maximum de gain en matière de faciliter d’utilisation, de modularité et de réutilisabilité, le modèle
d’abstraction utilisé pour définir des vues virtuelles doit être adapté à ce contexte de
Northbound API. En effet, le modèle d’abstraction représente un enjeu majeur dans un approche basée sur la virtualisation de réseaux [Casado et al., 2010], étant donné que
ses propriétés intrinsèques (facilité d’utilisation, modularité, réutilisation, flexibilité) se répercuteront, in fine, sur les propriétés de la Northbound API.
Dans ce qui suit, nous présentons les différents modèles d’abstraction qui ont été utilisés par les langages de programmation SDN existants. Puis, nous présenterons notre modèle d’abstraction qui est la pièce centrale du langage AirNet que nous proposons.