UMBRELLA : Une nouvelle fabrique SDN pour les IXPs

UMBRELLA : Une nouvelle fabrique SDN pour les IXPs

Les IXPs appliquent des règles strictes [19], [20] pour réduire l’effet de bord dû à l’utilisation d’un domaine broadcast partagé de niveau 2 ; par exemple, l’adresse MAC du routeur sur lequel les membres se connectent à la fabrique doit être connu à l’avance. C’est seulement à ce moment que l’IXP alloue un port Ethernet sur le commutateur de bordure et une adresse IP publique de son espace [21] et configure une liste de contrôle d’accès (ou ACL pour Access control List) avec cette adresse MAC. C’est ainsi que la localisation de tous les routeurs des membres est connue de l’IXP. C’est pour cela qu’Umbrella élimine le besoin d’un mécanisme de découverte des localisations des équipements et qui reposerait sur des messages en mode broadcast (i.e., requêtes ARP, IPv6 neighbor discovery) et par conséquent rend inutile un proxy-ARP comme cela est proposé dans les précédentes solutions pour les IXP-SDN [15], [16], [2], [3]. Umbrella convertit à la volée les paquets broadcast en paquets unicast en utilisant la possibilité offerte par OF de ré-écrire le champ d’adresse MAC et qui correspond à une règle donnée [22].

Nous proposons d’utiliser un mécanisme de forwarding basé sur des labels pour réduire le nombre de règles dans le cœur de la fabrique de l’IXP. Les commutateurs de bordure Umbrella écrivent explicitement les ports destination pour chaque saut dans le champ destination de la trame MAC du paquet. Le premier octet de l’adresse MAC indique donc pour chacun des commutateurs de cœur traversés le numéro de port de sortie à utiliser.

Lorsque la source et la destination sont directement connectées au même commutateur de bordure, aucun encodage n’est requis, et l’adresse broadcast de destination est directement remplacée par l’adresse MAC de destination par le commutateur de bordure concerné. Dans un scénario IPv6, l’indication OF dans le commutateur de bordure doit être placée dans le champs IPv6 ND target du paquet de sollicitation ICMPv6 Neighbor [23]. La table de correspondance sur le commutateur de bordure doit conserver les associations entre les adresses IPv6 et leur localisation, comme dans le cas IP4.

Une approche de commutation basée sur des labels 

Le mécanisme de propagation (forwarding) d’umbrella permet d’utiliser des commutateurs traditionnels (sans implémentation d’OF) dans le cœur, limitant ainsi les investissements (et coûts) de mise à jours des matériels. Un commutateur de cœur doit seulement forwarder les paquets sur la base de règles de filtrage d’accès, alors que les commutateurs de bordure doivent intégrer OF pour ré-écrire le champ MAC de destination. Cette approche est directement applicable pour des IXPs permettant un seul saut dans le cœur (comme AMS-IX et DE-CIX), mais n’est pas applicable pour des fabriques autorisant plusieurs sauts (comme LINX et MSK-IX). Avec un seul saut, le port de sortie est encodé dans l’octet de poids fort de l’adresse MAC de destination. Dans le cas multi-sauts, comme un paquet peut traverser plusieurs commutateurs de cœur, un nouveau mécanisme d’encodage est requis pour indiquer les différents ports de sortie au niveau des différents commutateurs de cœur.

Adapter Umbrella aux topologies multi-sauts d’IXP n’est pas trivial. Il faudrait pour cela définir un mécanisme d’encodage des adresses MAC de destination dans lequel l’octet de poids fort indique le port de sortie du premier commutateur de cœur (i.e., core-a), le second octet indique le port de sortie du second commutateur de cœur (i.e., core-b), et ainsi de suite. C’est tout bonnement impossible. En effet, selon la route, un commutateur de cœur peut être soit le premier soit le second sur le chemin à suivre. Une autre solution pourrait consister à considérer les ports d’entrée de la trame dans les règles de forwarding installées au niveau des commutateurs de cœur. Avec les ports d’entrée, on peut savoir où se situe le commutateur sur le chemin entre la source et la destination, et ainsi considérer le bon octet dans le champ de l’adresse MAC de destination. Hélas, cette approche ne peut pas fonctionner sur des topologies arbitraires. De plus, un tel mécanisme conduirait à une explosion du nombre de règles dans le cœur, le nombre de règles de forwarding grandissant de façon quadratique avec le nombre de ports d’entrée possibles.

En mettant en place une méthode à base de source routing, Umbrella s’absout enfin de ce problème. Dans l’approche Umbrella pour les fabriques multi-sauts d’IXP, le premier commutateur de bordure doit sélectionner le chemin à emprunter pour chaque paquet. Une liste ordonnée des ports de sortie est alors encodée dans le champ d’adresse MAC de destination, comme une pile de labels. Finalement, chaque nœud de cœur traite les trames en considérant la valeur au sommet de la pile, et la dépile avant de les forwarder .

Avec cette configuration, chaque commutateur n’a besoin de ne regarder que l’octet de poids fort de l’adresse, peut importe la place qu’il occupe sur le chemin vers la destination. Retirer de la pile le dernier label utilisé nécessite de pouvoir ré-écrire les entêtes, rendant cette solution possible uniquement sur des commutateurs de cœur compatibles avec OF. En particulier, chaque commutateur de cœur doit posséder deux tables d’actions : forwarding et coppy-field . Cette solution présente donc deux limites pratiques :

• Le nombre maximum de ports de sorties qui peuvent être adressés lors de chaque saut est limité à 256, puisque le numéro de port de sortie pour chaque commutateur est encodé dans l’octet de poids fort du champ d’adresse MAC de destination.

• Le nombre maximal de sauts au sein de l’IXP est limité à 6, car nous ne pouvons utiliser que les 6 octets de l’adresse MAC pour encoder tout le cheminement des trames.

Cependant, nous devons surtout considérer Umbrella comme une approche permettant une séparation plus forte entre les plans de contrôle et de données. Les limitations pratiques peuvent se résoudre avec l’apparition de nouvelles implémentations des différents protocoles.

Déploiement et évaluation d’Umbrella sur TouIX : de TouIX à TouSIX

Le réseau TouIX était une infrastructure interconnectée autour de 4 POPs (Point of Presence) et interconnectée avec deux autres IXP : FranceIX et LyonIX. TouIX a été renommé TouSIX après sa migration vers une approche OF. Depuis mai 2015, TouSIX est le premier IXP européen (et à ce jour le seul) à exploiter la technologie OF pour ses opération quotidiennes. L’architecture TouSIX utilise l’approche Umbrella. Cette partie commence par présenter les travaux de migration de TouIX vers une solution OF, puis montre ensuite comment TouSIX et son approche Umbrella fonctionnent et résolvent les problèmes présents avec l’ancien réseau TouIX.

TouIX

En particulier, les mauvaises configurations de membres (i.e., avec des boucles non souhaitées) affectaient l’ensemble des opérations de la fabrique, et rendaient délicate la gestion de l’IXP. Plusieurs « tempêtes ARP » (ARP storm) ont été subies. L’absence d’un système de monitoring moderne et efficace couplée à des apparitions irrégulières de ce phénomène l’ont rendu difficile à détecter. Les commutateurs CISCO ne disposaient pas des règles de filtrage requises pour empêcher ce trafic non voulu de perturber la fabrique. Protéger la fabrique du trafic indésirable est une nécessité, non seulement pour protéger les routeurs pairs, mais aussi pour améliorer la stabilité et la facilité de gestion de toute l’infrastructure. Umbrella a été notre réponse pour solutionner ces problèmes.

Table des matières

1. Introduction
2. UMBRELLA : Une nouvelle fabrique SDN pour les IXPs
Une approche de commutation basée sur des labels
3. Déploiement et évaluation d’Umbrella sur TouIX : de TouIX à TouSIX
TouIX
TouSIX : un IXP totalement opéré par SDN
4. Amélioration de la robustesse des SFC dans un IXP
Architecture SFC
Renforcement de la robustesse d’un chainage SFC
Evaluation
5. Etat de l’art
6. Conclusion
7. Références

Lire le rapport complet