Discussion



t y p e =SS H ·s w =A·p t=1· (P_AC·t)∗ ·

s w=B·p t=2



≡0

2.3 Discussion

Après cette description détaillée des langages de programmation réseau existants, nous allons, dans cette section, discuter de leurs motivations et principaux apports. Par ailleurs, il est important de noter que cette discussion n’a pas pour objectif de déterminer quel est le meilleur langage d’entre eux, mais plutôt de proposer une grille de lecture qui permettra de mieux situer les problématiques ainsi que les principaux apports de chacun.

En effet, de par la nature et le rôle que jouent les Northbound API, nous pensons qu’il n’est pas pertinent d’essayer de statuer que telle approche ou telle fonctionnalité est meilleure ou plus intéressante que les autres, surtout considérant leurs différents contextes d’utilisation et les constantes évolution de leurs exigences [Robert Sherwood, 2013, Isabelle GUIS, 2012, Brent Salisbury, 2012, Greg Ferro, 2012,Ivan Pepelnjak, 2012,Sally Johnson, 2012,Rivka Gewirtz Little, 2013]. Pour étayer plus notre propos, nous pourrions faire l’analogie avec les systèmes d’exploitation machine ou mobile tels Windows ou MAC OS, qui ne proposent aucune API standard et ceux malgré leur longue existence. De plus, leur écosystème applicatif se porte très bien et est en constante évolution. Ainsi, la même chose s’applique aux Northbound API dans le contexte SDN où ces interfaces représentent la brique qui permettra aux opérateurs et aux administrateurs de créer le plus de valeur ajoutée. En effet, c’est en les utilisant qu’un administrateur pourra faire évoluer, rapidement et efficacement, le comportement de son réseau afin d’atteindre au mieux ses objectifs métiers.

Ainsi, nous avons vu que plusieurs langages de programmation ont été proposés dans un cadre SDN, le tableau1résume brièvement ces langages ainsi que leurs principaux apports.

Un point commun entre tous ces langages est que tous proposent des abstractions pour le standard OpenFlow. Pour ce faire, chaque langage utilise un paradigme de programmation différent. On peut aussi noter que le paradigme déclaratif, sous ses diverses formes (logique, fonctionnel, etc.), est le plus prédominant, cela est notamment dû à la nature déclarative des règles OpenFlow qui suivent une logique de typefiltre-action.

Chapitre 2 : État de l’art des langages de contrôle sur l’interface nord de SDN

Langage Paradigme de programmation Points clés

FML logique, réactif Règles avec une logique si-alors, deux mécanismes de résolution de conflits.

Nettle fonctionnel, réactif Basé sur le paradigme FRP, un programme est une fonction signal.

Frenetic fonctionnel, réactif, requête Deux sous-langages : surveillance et contrôle, règles avec une logique filtre-actions

Procera fonctionnel, réactif Concepts de fenêtrage et d’agrégation, création fonctionnelle d’évènements.

NetCore fonctionnel Fait suite aux travaux Frenetic, nouveaux algorithmes de compilation, primitives pour consulter l’état du contrôleur.

Pyretic impératif Opérateurs de composition séquentielle et parallèle, virtualisation de réseau.

Splendid

descriptif Isolation de trafic, virtualisation de réseau.

Isolation

Merlin expression régulière Gestion unifiée de tous les équipements (commutateur, hôte, boite noir) d’un réseau.

FatTire expression régulière Utilise les expressions régulières pour exprimer des chemin ainsi que les contraintes de tolérance aux fautes.

Mapple imperatif Algorithme de compilation, exécution parallèle, abstraction d’un algorithme centralisé.

NetKat fonctionnel Respecte la base mathématique KAT, permet la vérification des politiques.

TABLE1.Synthèse des langages de programmation réseau

2.3.1 Une API OpenFlow de plus haut niveau

Les touts premiers langages comme FML, Nettle et Procera sont des langages fonctionnels et réactifs. Ainsi, les politiques et les programmes de contrôle qui sont écrits avec ces langages prendront la forme d’une fonction, ou une composition de fonctions, qui va recevoir un flux d’évènements OpenFlow (ou évènements extérieurs telle l’authentification d’un hôte), éventuellement appliquer des transformations sur ces évènements, puis retourner comme résultat un nouveau flux d’évènements qui correspondra souvent à des actions de type allowoudenyqui serviront ensuite à configurer les tables de commutation des équipements réseaux.

Ainsi, cette démarche permet de masquer une grande partie de la complexité des interactions entre le programme de contrôle et l’infrastructure physique, notamment le fait de construire les différents types de messages OpenFlow ou de devoir considérer à chaque fois le type de l’API et du contrôleur sous-jacent.

2.3.2 Composition et modularité

D’autres langages SDN comme Frenetic, NetCore et Pyretic ont été conçus dans l’objectif d’exprimer plus efficacement les règles de commutation des paquets, notamment en se basant sur des prédicats et des primitives qui permettent de spécifier des filtres incomplets et d’envoyer des requêtes afin de récupérer des statistiques sur l’état du contrôleur. Les règles de contrôle de ces langages suivent principalement la logique filtre→actions, où filtre capture un ensemble de paquets etactionsreprésente la liste d’actions à appliquer sur ces

paquets.

Par ailleurs, ces langages offrent plusieurs mécanismes pour résoudre les problèmes d’intersection entre les règles de différents modules de contrôle, principalement à travers l’introduction des opérateurs de composition séquentielle et parallèle (opérateurs intégrés par exemple dans le langage Pyretic et que nous réutiliserons dans notre contribution).

Ces opérateurs permettent, d’une part, de composer plus facilement les diverses primitives d’un langage afin d’obtenir des politiques plus élaborées, et d’autre part, permettent aussi de composer des modules de contrôle existants, améliorant ainsi la réutilisabilité des programmes.

2.3.3 Fonctionnalités avancées

D’autres fonctionnalités plus avancées sont fournies par des langages tels que FatTire qui permet aux administrateurs d’exprimer leurs chemins réseau tout en positionnant des exigences de tolérance aux fautes. Par la suite, c’est la responsabilité de l’environnement d’exécution de FatTire d’installer des chemins de secours pour répondre à ces exigences en se basant notamment sur de nouveaux types de tables de commutation introduites dans les versions récentes du standard OpenFlow.

Le langage Merlin a été, quant à lui, une des premières tentatives pour avoir un environnement de gestion unifié (dans un contexte SDN) pour tous les équipements d’un réseau tels que, les commutateurs OpenFlow, les machines hôtes et les différentes middleboxes qu’on peut retrouver. Pour ce faire, Merlin génère un code spécifique pour chaque type d’équipement, tout en proposant aussi une possible délégation du contrôle d’une partie de ces équipements à un tier (tenant) extérieur.

Le langage Mapple introduit une abstraction qui permet aux administrateurs de voir leur programme de contrôle comme un seul algorithme central qui va être appliqué sur tous les paquets qui entreront dans leur réseau. Ainsi, un administrateur n’a plus besoin de penser quel paquet doit remonter au contrôleur et quels sont ceux qui doivent être traités au niveau des commutateurs, tout cela est fait automatiquement par le compilateur de Maple qui optimise au mieux cette répartition afin de préserver les performances du réseau.

En dernier, le langage NetKat, dont les primitives respectent la base mathématiqueKAT, permet aux administrateurs de vérifier leurs programmes de contrôle. En effet, NetKat est capable de répondre formellement à des questions telles que : les flux SSH sont-ils autorisés entre l’hôteAet un serveur webS.

2.3.4 Virtualisation de réseau

Des langages comme Pyretic et Splendid Isolation, fournissent un support pour la virtualisation de réseau. Ainsi, en utilisant ces langages, un administrateur peut définir ses propres topologies virtuelles, suivant ses propres objectifs de haut-niveau, puis d’appliquer des politiques sur ces topologies abstraites. L’avantage de cette démarche est qu’elle facilite significativement la configuration d’un réseau, étant donné que l’administrateur ne va considérer que les informations qui sont les plus pertinentes pour sa politique de configuration globale. Encore plus important, cette démarche permet d’augmenter

Chapitre 2 : État de l’art des langages de contrôle sur l’interface nord de SDN

significativement la réutilisabilité des programmes vu que les politiques sont spécifiées sur des topologies virtuelles et peuvent être par la suite utilisées sur des infrastructure physiques différentes.

De plus, Splendid Isolation permet de définir desslices(c.-à.d., des tranches) de réseau avec un mapping un-à-un entre équipements virtuels et physiques, et où chaque slice pourra avoir son propre programme de contrôle, assurant ainsi une isolation stricte entre ces différents modules de contrôle. Pyretic, quant à lui, fournit un modèle de paquets qui permet de définir des topologies virtuelles avec des possibilités de mapping très flexibles.

L’administrateur pourra, par la suite, appliquer ses politiques de contrôle sur cette topologie virtuelle et cela sera la responsabilité de l’hyperviseur d’installer une configuration physique qui est sémantiquement équivalente à la politique virtuelle.