FatTire

FatTire[Reitblatt et al., 2013]est un langage qui permet aux administrateurs de spécifier leurs politiques de commutation sous la forme d’un ensemble de chemins avec des contraintes de tolérance aux fautes explicitement indiquées. De façon similaire à Merlin, FatTire propose l’utilisation des expressions régulières afin de décrire les chemins de transmission ainsi que les possibles contraintes qui y sont imposées.

Traditionnellement, la reprise d’une erreur qui se produit dans l’infrastructure physique est réalisée au niveau du contrôleur SDN. En effet, les administrateurs doivent écrire en amont des algorithmes complexes qui permettent de générer des nouvelles règles dés que le contrôleur reçoit des événements qui indiquent qu’un commutateur ou un lien est hors service. Les auteurs de FatTire jugent que cette démarche est à la fois complexe et non optimale. En effet, lors de la réception d’un événement qui indique une erreur au niveau de l’infrastructure physique, le contrôleur enclenche une procédure de reprise sur erreur pour installer des nouvelles règles qui permettent d’emprunter le chemin de secours.

Malheureusement, cette approche nécessite une quantité considérable de temps, de plus pendant cette phase de mise à jour des politiques de transmission, les paquets circulant encore sur le réseau peuvent être relayés sur différents équipements suivant une table de

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

commutation partielle et inconsistante, violant ainsi la politique globale de commutation et de sécurité.

Pour pallier cette problématique, FatTire repose sur l’utilisation d’une nouvelle version du standard OpenFlow (version 1.3). En effet, les versions les plus récentes d’OpenFlow proposent l’utilisation de règles conditionnelles dont les actions à exécuter dépendent de l’état local du commutateur. Ainsi, un nouveau type de table appelée group table a été introduit dans les commutateurs OpenFlow. Les entrées de cette nouvelle table contiennent des règles qui incluent une liste de seaux d’actions (actions buckets) à exécuter suivant un certain nombre de paramètres. Ces seaux d’actions permettent de définir plusieurs types de comportement pour une règle. En effet, à un instant donnée, un seul seau d’actions est actif pour une règle et si éventuellement une erreur se produit (un port est hors service), la règle de commutation change de seau, s’adaptant ainsi sans devoir attendre une mise à jour de la part du contrôleur.

FIGURE14.Exemple de topologie FatTire[Reitblatt et al., 2013]

Pour mieux illustrer l’utilisation de FatTire, les auteurs proposent le cas d’utilisation suivant. L’objectif est d’installer, sur la topologie qui est schématisée à la figure 14, la configuration qui respecte les contraintes suivantes :

• Le trafic SSH qui arrive au niveau de la passerelle (GW) doit être transmis au commutateur A.

• Le trafic SSH entrant doit passer par un système de détection d’intrusion (IDS).

• Le fonctionnement du réseau doit être assuré même dans le cas de la défaillance d’un lien.

Suivant ces contraintes de haut-niveau, un premier chemin a été sélectionné :[GW, S1, IDS, S2, A]. Cependant, pour assurer la contrainte de tolérance à la défaillance d’un lien, les chemins de secours suivant ont été proposés :

• le chemin[GW,S2,IDS,S2,A]si le lien (GW,S1) est défaillant.

• le chemin[GW,S1,S2,IDS,S2,A]si le lien (S1,IDS) est défaillant.

• le chemin[GW,S1,IDS,S1,A]si le lien (IDS,S2) est défaillant.

• le chemin[GW,S1,IDS,S2,S1,A]si le lien (S2,A) est défaillant.

Transcrire ces chemins en utilisant OpenFlow est une tâche fastidieuse et sujette à erreurs. La figure15affiche les tables de commutation et les tablesgroupnécessaires pour implémenter les chemins décris précédemment.

FIGURE15.Tables des équipements dans l’exemple FatTire[Reitblatt et al., 2013]

Ainsi, sur chacun des équipements intermédiaires (GW, S1 et S2) on a deux tables qui sont installées. La première est la table de commutation, elle contient les règles qui permettent de capturer un flux de paquets, puis d’appliquer un ensemble d’actions. Ici, la partie actions contient juste un pointeur vers un groupe d’actions qui sont enregistrées dans lagroup table. Par exemple, sur le commutateur GW, on retrouve une règle dans la table de commutation qui capture tous les flux SSH entrant (tpDst=22) et y applique le premier groupe d’actions. Ce dernier inclut deux seaux d’action, le premier commute les paquets vers le commutateur S1, mais si le lien vers le commutateur S1 est défaillant, alors le deuxième seau est appliqué et ce dernier inclut une action qui commute les paquets vers le commutateur S2.

Ainsi, en regroupant toutes ces tables on retrouve les quatre chemins alternatifs à mettre en œuvre en cas de défaillance d’un lien particulier. Néanmoins, il est clair que construire ces tables d’une manière manuelle en utilisant l’interface de bas-niveau d’un contrôleur SDN est une tâche complexe. Le langage FatTire permet la description de ces chemins principaux et alternatifs d’une manière très intuitive en utilisant les expressions régulières.

L’exemple ci-dessous représente le programme nécessaire pour implémenter la politique décrite précédemment.

( tpDst = 22 ⇒ [Æ. IDS .Æ] ) ^p ( tpDst = 22 ⇒ [Æ] with 1 ) ^p ( any ⇒ [GW.Æ. A ] )

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

La première ligne du programme spécifie une règle qui indique que tout flux SSH entrant doit passer par un système de détection d’intrusions. La deuxième ligne utilise la primitive with pour indiquer que la politique d’acheminement doit être résiliante à la défaillance d’un lien. La troisième ligne représente la politique de routage et indique que tous les flux provenant de la passerelle (GW) doivent être acheminés vers le commutateur S1. Le programme complet consiste en l’intersection des ces trois sous-politiques pour donner une politique globale qui stipule que le trafic SSH entrant doit traverser unIDS, être résilient à une défaillance d’un lien et doit être acheminé de la passerelle jusqu’au commutateur A.

La figure 16 représente un résumé des primitives les plus importantes de FatTire, beaucoup de ces primitives ont été déjà proposées dans le cadre de travaux précédent tels que NetCore, mais le langage FatTire propose une méthode intuitive et performante pour gérer les contraintes de tolérances aux fautes.

Switch ID sw ∈ N

En−t ê t e sh ::= d l S r c −−a d r e s s e MAC s o u r c e

| d l D s t −−a d r e s s e MAC d e s t i n a t i o n

| . . . .

Pr é d i c a t s pr ::= any −−j o k e r

| h =v −−f i l t r e s u r un en−t ê t e

| not pr −−né g a t i o n d ’ un pr é d i c a t

| pr1 and pr2 −−i n t e r s e c t i o n de deux pr é d i c a t s P o l i t i q u e s p o l ::= pr ⇒ P with n

| p o l1

U p o l2

| p o l1

p p o l2

FIGURE16.Primitives principales du langage FatTire