Soutenance mémoire
En 2008, [MCKEOWN et collab., 2008] publiaient le papier intitulé: “Enabling Innovation in Campus Networks”. Les auteurs proposaient le protocole OpenFlow (OF) comme une solution permettant ainsi aux constructeurs d’offrir une interface de programmation à leurs équipements réseaux permettant aux chercheurs d’expérimenter de nouvelles approches et de nouveaux protocoles réseaux. OF proposait une solution pour séparer plan de données et plan de contrôle qui soit facile à mettre à mettre en œuvre par les industriels dans leurs équipements. Cette séparation permettait aussi de centraliser le plan de contrôle en introduisant dans le réseau une fonction de contrôleur centralisée, chargée de piloter le plan de données. Cette proposition déclencha une dynamique profonde de remise en question des architectures réseaux traditionnelles. Cependant, cette approche n’était pas si nouvelle. Des propositions similaires avaient fait par exemple l’objet de travaux de standardisation à l’IETF.
C’était déjà le cas en 2002 avec la RFC 5810 ForCes ou [HALPERN et collab., 2010] distinguaient notamment dans les équipements les “Forwarding Elements” (FE) et les “Control Elements” (CE). L’approche initiale intitulée ForCes prévoyait aussi la centralisation du plan de contrôle mais portait surtout l’idée de séparer plan de contrôle et plan de données, en favorisant ainsi l’indépendance entre les deux plans et en stimulant ainsi la concurrence et les propositions des industriels. L’introduction d’un contrôle centralisé associé à une certaine intelligence était aussi présente dans le concept de Policy Based Networking (PBN) introduit à l’IETF via la notion de Policy Decision Point (PDP) et de Policy Enforcement Point (PEP) qui est mise en oeuvre pour provisionner et appliquer des politiques de QoS. Ces approches et d’autres encore plus récentes ont été ensuite désignées et réunies sous le sigle SDN. Tandis que la recherche cherchait à préciser les limites et les potentialités de l’approche SDN OF dans le monde des réseaux physiques ou virtuels et dans les datacenters, en 2012 est arrivé le paradigme ETSI-NFV qui s’appuyait lui sur les potentialités de la virtualisation pour proposer de faire évoluer les infrastructures des réseaux des opérateurs de télécommunication. L’idée était en particulier de faire supporter les fonctions et services réseaux par un environnement virtuel dans des serveurs banalisés.
Architectures des réseaux SDN
Au début des propositions autour du paradigme SDN, la plupart des travaux envisageaient seulement un contrôleur centralisé pour un domaine donné, ce qui conduisait à une sollicitation importante de la capacité de traitement du contrôleur et conduisait naturellement à des problèmes de mise à l’échelle. Paradoxalement, une des propositions qui a surgi alors était le concept de contrôleur logiquement centralisé s’appuyant sur une certaine distribution physique de cette fonction comparable à la distribution des fonctions dans les réseaux classiques. Il est apparu aussi que la fonctionnalité de contrôleur devait être physiquement distribuée pour permettre de gérer des réseaux à grande échelle. Nous avons donc abordé cet état de l’art en classant les principales propositions d’architecture pour réaliser la centralisation et la distribution du contrôleur SDN. Nous avons aussi abordé les propositions visant à introduire une certaine dynamicité pour répondre aux variations du réseau. En préambule, nous présentons le paradigme NFV chez les opérateurs TelCo dans lequel s’inscrivent les technologies SDN. En effet ce paradigme est devenu le contexte principal dans lequel les technologies SDN doivent être mises en œuvre chez les opérateurs.
Architectures virtualisées pour opérateurs Telco
L’idée générale de NFV est de mettre en œuvre des infrastructures composées de serveurs banalisés (Commercial Of The Shelf (COTS)) pour implémenter des fonctions réseaux hébergées dans des machines virtuelles sous forme de VNFs. Notre objectif n’est pas de présenter les différentes approches autour du paradigme NFV, mais simplement de montrer comment SDN, et en l’occurence OF et NFV peuvent s’articuler de manière complémentaire, en particulier:
• Le contrôleur réseau peut être virtualisé et hébergé sur des serveurs NFV, il peut donc s’agir d’une brique réseau virtuelle, d’une VNF,
• Le switch OF (OpenFlow Switch (SOF)) peut-être virtualisé comme par exemple avec Open-VSwitch, [PFAFF et collab., 2015],
• OF est généralement un moyen de déployer la connectivité dans une infrastructure virtualisée, à différents niveaux, à l’intérieur d’une machine virtuelle (Virtual Machine (VM)), dans un serveur pour connecter des machines virtuelles et des Virtual Network Functions Components (VNF-C)s, à l’intérieur d’une VNF, d’un tenant, ou dans l’infrastructure d’hébergement,
• OF est un moyen de réaliser le chaînage de services pour composer des services réseaux en aiguillant les flux entre VNFs ou entre middleboxes virtualisées,
• La brique OF est très répandue dans les datacenters,
• La brique OF est présente dans le Virtual Infrastructure Manager (VIM) pour réaliser la connectivité entre les machines virtuelles, par exemple dans OpenStack,
• La brique OF permet de réaliser une connectivité dynamique et adaptative,
• OF permet de réaliser le concept de slices réseaux présent par exemple dans la 5G.
Sous certains aspects, le paradigme NFV a supplanté l’approche SDN (en particulier OF) en répondant autrement à certains verrous techniques qui initialement étaient adressés par les deux approches. Par exemple, tandis que le SDN essayait de résoudre le verrou technique des middle-Boxes qui se multipliaient dans les infrastructures (fonctions DPI, firewall, NAT . . . ) en distribuant ces fonctions dans des SOFs améliorés couplés à des contrôleurs plus ou moins distribués, NFV propose plutôt de garder les middleboxes en les virtualisant dans des datacenters, ce qui permet de résoudre les problèmes de coûts et d’évolutivité. Dans le contexte NFV, le SDN est devenu essentiellement un moyen de gérer la connectivité et la ressource réseau au service de l’ensemble de l’infrastructure et est potentiellement utilisable dans différents blocs fonctionnels:
• dans des tenants ou des infrastructures virtuelles,
• au niveau de l’infrastructure physique elle même qui supporte les tenants,
• dans les VNFs pour relier des VNF-Cs,
• pour chaîner des VNFs et aiguiller les flux de manière à réaliser un service réseau complet.
Architectures SDN physiquement centralisées et en clusters
L’organisation des contrôleurs en clusters est un moyen d’améliorer la fiabilité du réseau SDN et de résoudre le problème de défaillance d’un seul point centralisé dans les architectures SDN. La technologie qui organise les clusters est basée sur un processus électif d’un maître parmi des instances de contrôleurs partageant une base de données distribuée. [JAIN et collab., 2013] ont présenté une implémentation concrète et effective d’OF dans le contexte industriel de la gestion du trafic interne entre les data-centers Google. Les motivations pour la mise en œuvre d’OF étaient principalement la facilité pour la mise en œuvre de nouveaux protocoles, des procédures de tests et de validation plus simples, et enfin et surtout un objectif d’optimisation du trafic entre data-centers avec l’idée de réduire le surdimensionnement des liens par la mise en œuvre d’outils d’ingénierie de trafic. Pour Google, chaque Data Center constitue un système autonome AS connecté au réseau internet. Ils sont quelques dizaines disséminés dans le monde et sont interconnectés entre eux via le cœur de réseau B4 d’interconnexion. Ce réseau prend la forme d’un autre système autonome AS qui utilise traditionnellement les protocoles iBGP et ISIS pour le routage. Dans cette architecture, les services de routage et d’ingénierie de trafic sont déployés de manières indépendantes afin d’assurer un fonctionnement minimal par des procédures de routage classique en cas de défection du serveur d’ingénierie de trafic.
Au niveau de l’interface entre les data centers et le réseau B4, les routeurs d’interconnexion ont été convertis progressivement en SOFs, et les fonctions de routage ont progressivement été migrées dans des contrôleurs centralisés (rattachés à chaque data center). Ces contrôleurs mettent en œuvre une pile de routage virtuelle Quagga, [JAKMA et LAMPARTER, 2014], qui calcule les routes iBGP et IS-IS, [PUJOLLE et SALVATORI, 2014], qui sont ensuite descendues dans les SOFs. Ces contrôleurs sont organisés en clusters pilotés par un logiciel (PAXO), [PRISCO et LAMPSON, 1997], qui permet d’assurer par un mécanisme d’élection une redondance à chaud en cas de défection d’un contrôleur. Les SOFs sont des équipements banalisés aux caractéristiques relativement moyennes (buffers, taille des tables de forwarding) qui ont été customisés par Google afin de réduire les coûts. L’optimisation du trafic permet en particulier de pallier les faibles performances des SOFs. De plus, les SOFs ont pu ainsi être rendus conformes aux besoins de Google en terme de contrôle de bas niveau et de nombre d’interfaces. Pour différencier le trafic de routage du trafic d’ingénierie, les SOFs disposent de deux tables différentes qui sont consultées en parallèle. La table pour l’ingénierie de trafic est prioritaire sur la table de routage. La solution centralisée d’ingénierie de trafic a été introduite en overlay (en utilisant des tunnels IP in IP),[PUJOLLE et SALVATORI, 2014], pour optimiser et planifier les flux critiques qui circulent entre les data centers. Cette solution est d’autant plus fiable que des incidents sur la partie ingénierie de trafic provoquent simplement un repli sur le mode de fonctionnement antérieur s’appuyant sur un routage classique. C’est un des avantages procurés par la mise en œuvre d’OF.
Le serveur d’ingéniérie de trafic utilise une abstraction du réseau qui présente chaque datacenter comme un simple nœud du réseau. Le trafic entre deux nœuds peut éventuellement être distribué dans tous les liens du réseau en fonction des politiques adoptées. Le serveur manipule des groupes de flots qui sont une abstraction d’agrégats de trafic correspondant à différentes applications ayant une pondération identique. Ces groupes peuvent être agrégés entre eux quand ils ont la même pondération.
|
Table des matières
1 Introduction générale
1.1 Introduction
1.2 Motivations
1.3 Contributions de la thèse
1.4 Organisation du manuscrit
2 Etat de l’art
2.1 Introduction
2.2 Architectures des réseaux SDN
2.3 Placement de services réseaux
2.4 Algorithmes évolutionnaires
3 Propositions pour une architecture SDN flexible et distribuée
3.1 Introduction
3.2 DICES, Une architecture SDN orientée services
3.3 Un plan de contrôle SDN étendu et flexible
3.4 Conclusion
4 Placement de services réseaux dans une infrastructure SDN & NFV
4.1 Introduction
4.2 Algorithmes de référence pour le placement
4.3 Regroupement hiérarchique basé sur la latence et la charge
4.4 Placement de contrôleurs avec un algorithme évolutionnaire
4.5 Placement de chaînes de VNFs avec un algorithme évolutionnaire
4.6 Conclusion sur le placement de services réseaux
5 Conclusion et perspectives
5.1 Conclusion
5.2 Perspectives
A Annexes
A.1 Notions théoriques sur la connectivité
