SOFTWARE DEFINED NETWORKING ET OPENFLOW

Télécharger le fichier pdf d’un mémoire de fin d’études

Les couches du modèle de référence

Le modèle de référence OSI comporte sept niveaux protocolaires plus un médium physique. Le médium physique, que l’on appelle parfois le niveau 0, correspond au support physique de communication chargé d’acheminer les éléments binaires d’un point à un autre jusqu’au récepteur final. Ce médium physique peut prendre diverses formes, allant du câble métallique aux signaux hertziens, en passant par la fibre optique et l’infrarouge. [1]

La couche 1 (physique), ou niveau élément binaire

La couche physique contient les règles et procédures à mettre en œuvre pour acheminer les éléments binaires sur le médium physique. On trouve dans la couche physique les équipements réseau qui traitent l’élément binaire, comme les modems, concentrateurs, ponts, hubs, etc.
Les différentes topologies de support physique affectent le comportement de la couche physique. Dans les entreprises, les plans de câblage ont une importance parfois déterminante pour le reste de l’architecture. La couche physique nécessite de surcroît un matériel fiable, et il faut parfois dupliquer ou mailler le réseau pour obtenir des taux de défaillance acceptables.

La couche 2 (liaison), ou niveau trame

La trame est l’entité transportée sur les lignes physiques. Elle contient un certain nombre d’octets transportés simultanément. Le rôle du niveau trame consiste à envoyer un ensemble d’éléments binaires sur une ligne physique de telle façon qu’ils puissent être récupérés correctement par le récepteur. Sa première fonction est de reconnaître, lors de l’arrivée des éléments binaires, les débuts et fins de trame. C’est là, aujourd’hui, le rôle principal de cette couche, qui a été fortement modifiée depuis son introduction dans le modèle de référence.

La couche 3 (réseau), ou niveau paquet

La couche 3, ou niveau paquet, est appelée couche réseau dans le modèle de référence parce que l’échange de paquets de bout en bout donne naissance à un réseau. Le niveau paquet doit permettre d’acheminer correctement les paquets d’information jusqu’à l’utilisateur final. Pour aller de l’émetteur au récepteur, il faut passer par des nœuds de transfert intermédiaires ou par des passerelles, qui interconnectent deux ou plusieurs réseaux.
Un paquet n’est pas une entité transportable sur une ligne physique, car si l’on émet les bits directement sur le support, il n’est pas possible de détecter la limite entre deux paquets arrivant au récepteur. Il y a donc obligation d’encapsuler les paquets dans des trames pour permettre leur transport d’un nœud vers un autre nœud.
Le niveau paquet nécessite trois fonctionnalités principales : le contrôle de flux, le transfert (routage ou commutation) et l’adressage :
• Contrôle de flux. Évite les embouteillages de paquets dans le réseau. Les retards provenant des surcharges de certaines parties du réseau peuvent en effet rendre le temps de réponse inacceptable pour l’utilisateur. Si le contrôle de flux échoue, un contrôle de congestion fait normalement revenir le trafic à une valeur acceptable par le réseau.
• Routage et commutation. Permettent d’acheminer les paquets d’information vers leur destination au travers du maillage des nœuds de transfert. Dans la commutation, les paquets suivent toujours le même chemin, alors que, dans le routage, la route peut changer. Le routage, ou la commutation, ne remplace pas le contrôle de flux mais peut être vu comme une de ses composantes, dont il faut tenir compte pour optimiser le temps de réponse. Les techniques de routage ou de commutation peuvent être centralisées ou distribuées, suivant l’option choisie par le gestionnaire du réseau : soit les tables de routage ou de commutation sont conçues par un nœud central, soit elles sont créées par chaque nœud, avec les problèmes de cohérence que cela pose.
• Adressage. La dernière grande fonction de la couche réseau consiste à gérer les adresses des équipements terminaux. Pour cela, il faut ajouter des adresses complètes dans les différents paquets, pour ce qui concerne le routage, ou dans le paquet de signalisation qui ouvre le chemin, pour la commutation. Les adresses forment un vaste ensemble, qui doit regrouper toutes les machines terminales du monde. L’ISO a dû prévoir une norme d’adressage susceptible de répertorier l’ensemble des équipements terminaux. Dans le monde TCP/IP, un adressage par réseau a été choisi.

La couche Transport

Elle assure la transmission de données de la source jusqu’à la destination (transport de bout en bout). Il doit fournir une qualité de transmission vis-à-vis de la fiabilité, de l’optimisation et de l’utilisation des ressources. [2]

La couche Session

Elle fournit aux entités qui coopèrent les moyens nécessaires pour synchroniser leur dialogue. Elle peut les interrompre ou les reprendre. Les données échangées doivent être cohérentes, malgré ces interruptions et reprises.

La couche Présentation

Elle se charge de la représentation des informations échangées par les entités. Elle fait en sorte que les informations échangées soient lisibles et compréhensibles en masquant les différents codages utilisés par les différents systèmes.

La couche application

La couche application donne au possesseur d’application les moyens d’accéder à l’environnement de communication de l’OSI. Elle comporte de nombreux protocoles adaptés aux différentes classes d’application.

L’architecture TCP/IP

Un protocole de communication est un ensemble de règles permettant à plusieurs ordinateurs de dialoguer entre eux. TCP/IP est un des langages utilisés dans les réseaux. Le terme TCP/IP n’est pas limité à l’expression Transmission Control Protocol/Internet Protocol. TCP/IP recouvre toute une famille de protocoles comme UDP (User Datagram Protocol), FTP (File Transfert Protocol), Telnet (Terminal Emulation Protocol), HTTP (HyperText Transfert Protocol), etc. [3]

Rôle de la DARPA

Dans les années soixante, la DARPA (Defense Advanced Research Projects Agency) remarqua que les ordinateurs utilisés dans le domaine militaire, de marques différentes, ne pouvaient communiquer qu’avec des ordinateurs de la même marque. Aucun protocole ne permettait de faire dialoguer ces ordinateurs.
Pour résoudre ces problème de communication, le ministère de la Défense des Etats-Unis demanda à la DARPA de définir une famille de protocoles pour :
 Simplifier les communications : grâce à un jeu de protocoles communs, tous les appareils pourront communiquer entre eux.
 Développer la compétition entre les différentes sociétés d’informatiques : les constructeurs d’ordinateurs peuvent entrer en compétition pour améliorer encore leurs implémentations des protocoles standards.
 Interopérabilité : en proposant aux constructeurs un ensemble de protocoles communs, l’interopérabilité entre différents équipements devient possible.
 Efficacité et productivité : avec un seul ensemble de protocoles, les constructeurs peuvent consacrer toute leur attention à l’implémentation des protocoles standards sur leurs machines et augmenter ainsi leur productivité.

Le projet ARPAnet

Expérimentation, en 1969, pour relier quatre sites :
 Université de Californie Los Angeles
 Université de Californie Santa Barbara
 Univesité de l’UTAH
 SRI international
En 1972, une démonstration reliant cinquante nœuds et vingt hôtes a eu lieu.
Un hôte : est un terme se rapportant à un ordinateur puissant sur lequel sont connectés plusieurs terminaux. Aujourd’hui, ce terme est utilisé pour toute machine qui offre un service à des utilisateurs. Ce type de machine peut être aussi bien un ordinateur personnel, une station de travail, un mini-ordinateur ou un mainframe.
Serveur : est un terme se rapportant à tout type de machine sur laquelle tourne un logiciel serveur offrant des services à des logiciels utilisateurs.
Client : logiciels utilisateurs utilisant les services de logiciel serveur.
A partir de 1986, le réseau ARPAnet englobait la plupart des grandes universités nord-américaines, le réseau militaire MILNEt et d’autres centres de recherche internationaux.
Peu à peu, le réseau ARPAnet fut remplacé par l’Internet. Celui-ci dépassa le domaine exlusif des universités et passa très vite dans le domaine commercial, à tel point que le trafic commercial l’emporta sur tous les autres.
Le premier backbone aux Etats-Unis fut NSFNET, puis ANSNET pour le trafic commercial. Actuellement, la communauté internet regroupe à la fois des organisations commerciales et de simples utilisateurs. On y trouve les universités, les organismes de recherche, les fournisseurs d’accès, les ministères et les utilisateurs.

Les couches TCP/IP

Un réseau TCP/IP peut être décomposé en plusieurs éléments :
 Les connexions physiques : qui fournissent le support avec lequel les données sont transmises à travers le réseau. Ces connexions peuvent être des câbles coaxiaux, des paires torsadées, de la fibre optique, des lignes téléphoniques, des lignes spécialisées, des micro-ondes, de l’infrarouge, des ondes radio ou des liaisons satellite.
 Les protocoles : pour que le réseau transmette des données, il faut choisir des règles et des conventions pour que tous les périphériques puissent dialoguer entre eux. Ces règles et ces conventions s’appellent des protocoles. Un grand nombre de protocoles remplissent les différentes fonctions nécessaires à la bonne marche du réseau.
 Les applications : au-dessus de ces protocoles se trouvent les applications qui créent les données acheminées sur le réseau par les protocoles. Enfin, les protocoles utilisent les connexions pour transmettre les données.
En analysant ces différentes opérations, on s’aperçoit que les connexions, les protocoles et les applications sont disposés hiérarchiquement. Dans cette hiérarchie, les applications se trouvent au niveau le plus haut et les connexions au niveau le plus bas. Les protocoles agissent comme un « pont » entre les applications et les connexions physiques.
Afin de comprendre cette hiérarchie, il faut disposer d’un modèle. Deux modèles ont été développés le modèle OSI que l’on a vu précédemment et le modèle DOD (Department Of Defense) que nous allons voir dans la section qui suit.

Le modèle DOD

Le modèle OSI a été créé en 1979, bien que le concept de couches existât bien avant d’être normalisé par l’ISO. Avec les protocoles TCP/IP, on a un exemple de protocoles utilisés bien avant le modèle OSI. Comme ces protocoles ont été historiquement crées à la demande du ministère de la Défense des États-Unis, les couches TCP/IP portent le nom de modèle DOD. Le modèle DOD comporte 4 couches :
– La couche accès réseau
– La couche internet
– La couche transport hôte à hôte
– La couche application

La couche accès réseau

La couche la plus basse représente la connexion physique avec les câbles, les transceivers, les cartes réseau, les protocoles d’accès au réseau (CSMA/CD pour les réseaux Ethernet et le jargon pour les réseaux Token ring). La couche accès réseau est utilisée par la couche Internet.

La couche Internet

La couche Internet doit fournir une adresse logique pour l’interface physique. L’implémentation du modèle DOD de la couche Internet est l’IP. Cette couche fournit un mappage entre l’adresse logique et l’adresse logique fournie par la couche accès réseau grâce aux protocoles ARP (Address Resolution Protocol) et RARP (Reverse Address Resolution Protocol). Les problèmes, les diagnostics et les conditions particulières associées au protocole IP relèvent du protocole ICMP (Internet Control Message Protocol), qui opère aussi au niveau de la couche Internet.
La couche Internet est aussi responsable du routage des paquets entre les hôtes. Cette couche est utilisée par les couches plus hautes du modèle DOD.

La couche transport hôte à hôte

La couche transport hôte à hôte définit les connexions entre deux hôtes sur le réseau. Le modèle DOD comprend deux protocoles hôte à hôte : TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Le protocole TCP est responsable du service de transmission fiable de données avec détections et corrections d’erreurs.
TCP permet aussi les connexions simultanées. Plusieurs connexions TCP peuvent être établies sur un hôte, et les données sont envoyées simultanément. TCP permet des connexions full duplex, ce qui signifie que les données peuvent être envoyées et reçues sur une seule connexion.
Le protocole UDP est un protocole peu fiable et peut être utilisée par des applications qui n’exigent pas la fiabilité de TCP.

SOFTWARE DEFINED NETWORKING ET OPENFLOW

Introduction

Le contrôle distribué et les protocoles de réseau de transport en cours d’exécution à l’intérieur des routeurs et des commutateurs sont les technologies clés qui permettent aux informations, sous la forme de paquets numériques, de voyager dans le monde entier. Malgré leur adoption généralisée, les réseaux IP traditionnels sont complexes et difficiles à gérer [5].
Depuis 2008 une nouvelle tendance forte a commencé à apparaître en matière de réseau avec les réseaux SDN (Software Defined Networking), qui découple le plan de données, c’est-à-dire les mécanismes qui permettent de faire avancer les trames et les paquets dans le réseau et le plan de contrôle, correspondant aux fonctions nécessaires pour déterminer les tables de transfert.
L’émergence de cette nouvelle tendance en matière d’architecture réseau a été amené par un désir de mettre en œuvre des principes de conception dans le domaine du réseau. Des principes que nous allons détailler plus en détails dans ce chapitre. Pour voir les raisons qui ont mené à l’idée du SDN, nous allons retracer son histoire. Ensuite, nous allons voir les différents éléments constituant un SDN ainsi que le protocole utilisé de facto pour la communication entre le contrôleur est les switches dans un réseau SDN. [1]

Historique

Le SDN est une nouvelle technologie excitante qui permet beaucoup d’innovation dans la conception et la gestion des réseaux. Même si cette technologie semble être apparue soudainement, SDN fait partie d’un effort de longue haleine pour rendre les réseaux plus programmables. Des efforts incluant les réseaux actifs, les premiers efforts pour séparer le plan de contrôle du plan de donnés pour arriver aux travaux récents sur OpenFlow et les systèmes d’exploitation réseau.
Nous allons présenter le cheminement intellectuel qui a conduit à la notion actuelle de SDN. Notre histoire commence il y a 20 ans, juste au moment où Internet a commencé son décollage. Au moment où l’incroyable succès d’Internet a découragé les défis de gestion et de l’évolution de l’architecture réseau. Nous allons nous baser sur les innovations dans la communauté du réseau (que ce soit par des chercheurs, des entités de standardisation ou des compagnies), même si on reconnait que ces innovations ont dans certains cas été catalysées par le progrès dans d’autres milieux, incluant les systèmes distribués, les systèmes d’exploitation, et les langages de programmation.
L’histoire se divise en trois parties : d’abord les réseaux actifs (depuis le milieu des années 90 au début des années 2000), qui ont introduit les fonctions programmable dans le réseau pour permettre plus d’innovations ; ensuite il y a la séparation du plan de contrôle du plan de données (depuis 2001 jusqu’en 2007), qui a développé des interfaces ouvertes entre le plan de contrôle et le plan de données et troisièmement, il y a l’API OpenFlow et les systèmes d’exploitation réseau (de 2007 à 2010), qui représente la première instance de l’adoption massive d’une interface ouverte et a développé des moyens pour faire de la séparation contrôle-données plus facile à mettre à l’échelle et plus pratique. [6]

Le Réseau actif

Le début et le milieu des années 90 a vu le décollage d’Internet, avec des applications et intérêts qui ont dépassé de loin les premières applications de transfert de fichiers et de courrier entre les scientifiques. Des applications diverses et une plus grande utilisation par le grand public ont attiré les chercheurs qui étaient désireux de tester et de déployer de nouvelles idées pour améliorer les services du réseau. Pour ce faire, les chercheurs ont conçu et testé de nouveaux protocoles de réseau dans des petites installations de laboratoire et ont ensuite simulé le comportement sur les grands réseaux. Ensuite, si la motivation et le financement persistait, ils soumettaient leurs idées à l’Internet Engineering Task Force (IETF) pour standardiser ces protocoles. Le processus de normalisation était lent et a finalement frustré de nombreux chercheurs.
En réponse à cela, des chercheurs en réseau ont poursuivi des chemins différents en ouvrant le contrôle du réseau, grossièrement basé sur l’analogie avec la facilité relative de la reprogrammation d’un unique ordinateur personnel. En réalité, un réseau conventionnel n’est pas « programmable » dans aucun des sens du mot. Le réseau actif représentait une approche radicale sur le contrôle du réseau en visionnant une interface de programmation (ou API réseau) qui exposerait les ressources sur chaque nœud individuel du réseau, et supporterait la construction de fonctionnalité personnalisée à appliquer sur une sous-partie des paquets passant par le nœud. Cette approche a reçu une réaction
négative de la part d’une majorité de la communauté Internet qui a jugé que la simplicité dans le réseau cœur était critique pour le succès d’Internet.
Le programme de recherche sur les réseaux actifs a exploré des alternatives radicales par rapport aux services fournis par le standard Internet via IP ou Asynchronous Transfert Mode (ATM), qui étaient les autres approches prédominantes du début des années 90s. En ce sens, les réseaux actifs constituait l’un des premiers approches qui partait d’une ardoise vide pour l’architecture du réseau [7] et qui fut suivie par d’autres programmes comme GENI (Global Environment for Network Innovations) [5] et NSF FIND (Future Internet Design) [6] aux États-Unis, et l’EU FIRE (Future Internet Research and Experimentation Initiative) [7] dans l’Union Européenne.
La communauté du réseau actif a poursuivi deux modèles de programmation :
– Le modèle capsule où le code à exécuter sur les nœuds sont transportés par les paquets de données [11]
– le modèle routeur / commutateur programmable, où le code à exécuter au niveau des nœuds a été créé par des mécanismes out-of-band [12] [13]
Le modèle capsule est plus étroitement associé au réseau actif. Dans la connexion intellectuelle aux efforts antérieurs, les deux modèles ont cependant les mêmes impacts sur le long terme. Les capsules ont envisagé l’installation d’une nouvelle fonctionnalité de plan de données sur un réseau, transportant du code dans les paquets de données et utilisant la mise en cache pour améliorer l’efficacité de la distribution du code (comme les premiers travaux sur le packet radio [14]). Les routeurs programmables ont quant à eux placé les décisions à propos de l’extensibilité directement dans les mains de l’opérateur réseau.

Poussée technologique et la traction de l’utilisation

La poussée technologique qui a encouragé le réseau actif inclus la réduction du coût de l’informatique, ce qui rend concevable de mettre plus de traitement dans le réseau, les progrès dans les langages de programmation tels que Java qui offre la portabilité entre plate-forme et la sécurité d’exécution du code, et la technologie de machine virtuelle protégeant la machine hôte (dans le cas d’un nœud actif) et d’autres processus des programmes qui pourraient mal se comporter [15]. Certains projets de recherche de réseaux actifs ont également capitalisé depuis les progrès dans la compilation rapide de code et des méthodes formelles.
Un catalyseur important dans l’écosystème du réseau actif est le financement venu de l’intérêt des organismes, en particulier le programme des Réseaux actifs créé et soutenu par l’Agence américaine Defense Advanced Research Projects Agency (DARPA) à partir du milieu des années 1990 jusqu’au début des années 2000. Bien que ce ne sont pas tous les recherches dans des réseaux actifs qui ont été financé par la DARPA, le programme de financement a soutenu une collection de projets et, peut-être plus important encore, a encouragé la convergence sur une terminologie et un ensemble de composants de réseaux actifs de sorte que les projets ont pu contribuer à un ensemble destiné à être supérieur à la somme des parties [7].
Le programme des réseaux actifs a mis l’accent sur les démonstrations et l’interopérabilité des projets, avec un niveau d’effort de développement qui l’accompagne. La poussée audacieuse et concertée d’une agence de financement en l’absence de cas d’utilisation à court terme a peut-être aussi contribué à un certain scepticisme de la part de la communauté par rapport au réseau actif qui était souvent sain mais pourraient être couvert d’hostilité et peut avoir obscurci certaines des connexions intellectuelles entre ce travail et les efforts ultérieurs pour fournir la programmabilité du réseau.
Les tractions de l’utilisation pour le réseau actif décrite dans la littérature de l’époque [16] [17] sont remarquablement similaires aux exemples utilisés pour motiver le SDN d’aujourd’hui. Les questions en ces temps inclus la frustration des fournisseurs de services avec les délais nécessaires pour développer et déployer de nouveaux services de réseau (dite ossification du réseau), l’intérêt des tiers sur la valeur ajoutée, un contrôle plus fin pour dynamiquement rencontrer les besoins des applications ou les conditions du réseau, et le désir des chercheurs d’avoir une plateforme qui pourrait supporter l’expérimentation à grande échelle.
En outre, de nombreux articles sur les premiers réseaux actifs ont cité la prolifération des boîtes intermédiaires, incluant les pare-feu, les serveurs mandataires et les transcodeurs, qui devaient être déployés séparément, dont chacun d’entre eux avait un modèle de programmation distinct (souvent dépendant du constructeur). Les réseaux actifs ont offert une vision d’un contrôle unifié sur les boîtes intermédiaires qui pourrait finalement remplacer la gestion et le contrôle de ces boîtes qui était disponible de fait [17].
Fait intéressant, la littérature du début préfigure les tendances actuelles de virtualisation des fonctions du réseau (NFV) [18], qui vise également à produire un cadre de contrôle unifié pour les réseaux qui ont des fonctions complexes dans des boîtes intermédiaires.

Les contributions intellectuelles

Les réseaux actifs ont offerts des contributions intellectuelles qui se rapportent au SDN. Nous allons noter trois en particulier:

Fonctions programmables dans le réseau pour abaisser la barrière à l’innovation

Les recherches en réseaux actifs ont ouvert la voie aux notions de réseaux programmables comme un moyen d’abaisser la barrière à l’innovation dans le réseau. La notion selon laquelle il est difficile d’innover dans un réseau de production et les plaidoyers pour augmenter la programmation ont été souvent cité dans la motivation initiale pour SDN. Une grande partie des premières visions pour SDN a été axée sur la programmabilité du plan de contrôle, tandis que les réseaux actifs se concentrèrent davantage sur la programmabilité du plan de données. Ledit, programmabilité du plan de données a continué à se développer en parallèle avec les efforts sur le plan de contrôle [19] [20], et la programmation du plan de données est de nouveau mise en avant-garde dans la nouvelle initiative de NFV. Des travaux récents sur SDN explorent l’évolution des protocoles tels que OpenFlow pour soutenir un large éventail de fonctions de plan de données [21]. En outre, les concepts d’isolement du trafic expérimental du trafic normal (qui ont leurs racines dans les réseaux actifs) apparaissent également en premier plan dans les documents de conception pour OpenFlow
[22] et d’autres technologies SDN tel que FlowVisor [23].

La virtualisation du réseau, et la capacité de démultiplexage aux logiciels basé sur les en-têtes de paquets.

La nécessité de soutenir l’expérimentation de multiples modèles de programmation a amené à travailler sur la virtualisation du réseau. Les réseaux actifs ont produit un cadre architectural qui décrit les composants d’une telle plate-forme [24]. Les éléments clés de cette plate-forme sont un Node Operating System (NodeOS) partagé qui gère les ressources partagées ; un ensemble d’Execution Environments (EEs), dont chacune définit une machine virtuelle pour les opérations sur les paquets ; et un ensemble d’Active Applications (AAs) qui travaille au sein d’une EE donnée pour fournir un service de bout-en-bout. La direction des paquets à une EE en particulier dépend de la reconnaissance rapide sur les champs d’en-tête et le démultiplexage à l’EE appropriée. Fait intéressant, ce modèle a été reporté dans l’architecture de PlanetLab [25] dans lequel différentes expériences exécutées dans un environnement d’exécution virtuel, et les paquets sont démultiplexés dans l’EE approprié sur la base de leurs paquets d’en-tête. Le démultiplexage de paquets à différents EEs a aussi été appliqué à la conception des plans de données programmables virtualisés [19].

Vision d’une architecture unifiée pour l’orchestration des boîtes intermédiaires

Bien que la vision n’ait jamais été pleinement réalisée dans le programme de recherche de réseau actif, les premiers documents de conception ont cité la nécessité d’unifier le large éventail de fonctions des boîtes intermédiaires avec un cadre commun de programmation sûr. Bien que cette vision n’a peut-être pas directement influencé le travail plus récent sur NFV, diverses leçons de la recherche sur les réseaux actifs peuvent s’être avérer utiles alors que nous allons de l’avant avec l’application du contrôle basé sur SDN et de l’orchestration des middleboxes.

A la quête d’un pragmatisme

Bien que les réseaux actifs articulent une vision de réseaux programmables, les technologies n’ont pas vu un déploiement généralisé. Plusieurs facteurs (ou l’absence) conduisent à l’adoption d’une technologie. Peut-être l’un des plus grands obstacles auquel les réseaux actifs se sont confrontés était l’absence d’un problème immédiatement convaincant ou un chemin clair pour le déploiement. Une leçon importante retenue de l’effort de recherche sur les réseaux actifs, est que les applications « killer » pour le plan de données sont difficiles à concevoir. La communauté a proféré diverses applications qui pourraient bénéficier d’un traitement en réseau, y compris la fusion d’information, la mise en cache et la distribution de contenu, gestion de réseau, et de qualité de service spécifique à l’application [16] [17]. Malheureusement, bien que les avantages de performance pourraient être quantifiés dans le laboratoire, aucun de ces domaines d’application n’ont démontré une solution suffisamment convaincante pour un besoin pressant.
Les efforts ultérieurs, que nous décrivons dans le prochain paragraphe, ont été plus modestes en termes de l’ampleur des problèmes qu’ils ont adressés, se concentrant étroitement sur le routage et la gestion de configuration. En plus d’une portée plus restreinte, la prochaine phase de recherche a développé des technologies qui ont dessiné une distinction claire et une séparation entre les fonctions des plans de contrôle et de données. Cette séparation définitive a permis de mettre l’accent sur les innovations dans le plan de contrôle, qui non seulement avait besoin d’une refonte importante mais aussi (parce qu’il est couramment mis en œuvre dans le logiciel) présentaient une barrière inférieure à l’innovation que le plan de données.

Séparation du plan de données et du plan de contrôle

Au début des années 2000, l’augmentation des volumes de trafic et un plus grand accent sur la fiabilité du réseau, la prévisibilité et la performance ont conduit les opérateurs de réseau à rechercher de meilleures approches pour certaines fonctions de gestion de réseau tels que le contrôle sur les chemins utilisés pour acheminer le trafic (une pratique couramment connue en tant que ingénierie du trafic). Les moyens pour effectuer l’ingénierie du trafic utilisant les protocoles de routage classiques étaient au mieux primitifs. La frustration des opérateurs face à ces approches a été reconnue par une petite communauté, bien située de chercheurs qui ont soit travaillé pour ou ont interagi régulièrement avec le réseau cœur des opérateurs. Ces chercheurs ont exploré des approches pragmatiques, à court terme qui étaient soit axées sur des normes ou étaient de déploiement imminent en utilisant des protocoles existants.
Plus précisément, les routeurs et les commutateurs classiques incarnent une intégration étroite entre le plan de contrôle et le plan de données. Ce couplage fait des diverses tâches de gestion de réseau, tels que le débogage des problèmes de configuration et de prédiction ou de contrôle du comportement de routage, excessivement difficile. Pour relever ces défis, les divers efforts pour séparer le plan de données et de contrôle ont commencé à émerger.

Poussée technologique et traction de l’utilisation

Comme l’Internet a prospéré dans les années 1990, les vitesses de liaison dans les réseaux cœurs ont augmenté rapidement, ce qui a conduit les principaux fournisseurs d’équipement à mettre en œuvre la logique de transfert de paquets directement dans le matériel, séparé du logiciel du plan de contrôle. En outre, les fournisseurs d’Accès Internet (FAI) ont du mal à gérer l’augmentation de la taille et de la portée de leurs réseaux, et les demandes pour une plus grande fiabilité et de nouveaux services (tels que les réseaux privés virtuels). En parallèle de ces deux tendances, les progrès rapide des plates-formes informatiques standards ont mené à ce que les serveurs ont souvent beaucoup plus de ressources mémoire et de traitement que le processeur du plan de contrôle d’un routeur déployé seulement un ou deux ans plus tôt. Ces tendances ont catalysé deux innovations :
• Une interface ouverte entre le plan de contrôle et le plan de données, comme le ForCES (Forwarding and Control Element Separation) [26] interface standardisée par l’IETF et l’interface NetLink dans la transmission de paquet au niveau du noyau Linux [27] ; et
• Un contrôle logiquement centralisé du réseau, comme ce qui est vu dans le Routing Control Platform (RCP) [28] [29] et les architectures SoftRouter [30], comme le protocole Path Computation Element (PCE) [31] de l’IETF.
Ces innovations ont été dirigées par les demandes de l’industrie pour gérer le routage dans un réseau de FAI. Certains parmi les premières propositions pour séparer le plan de données du plan de contrôle sont également venues des milieux universitaires, dans les deux réseaux ATM [32] [33] [34] et réseaux actifs [35].
Par rapport aux recherches antérieures sur le réseau actif, ces projets ont porté sur les problèmes urgents en matière de gestion de réseau, avec un accent sur : l’innovation par et pour les administrateurs de réseau (plutôt que les utilisateurs finaux et les chercheurs); programmabilité dans le plan de contrôle (plutôt que le plan des données); et la visibilité et le contrôle sur tout le réseau (plutôt que configuration au niveau de l’appareil).
Les applications de gestion de réseau inclus la sélection de meilleurs chemins d’accès réseau basé sur la charge de trafic actuelle, en minimisant les perturbations transitoires lors des changements de routage prévues, donnant aux réseaux de clients plus de contrôle sur le flux du trafic, et de réorienter ou de jeter le trafic présumé d’attaque. Plusieurs applications de contrôle ont marché dans les réseaux des FAI opérationnels utilisant des routeurs existants, y compris l’Intelligent Route Service Control Point (IRSCP) déployé pour offrir des services à valeur ajoutée pour les clients de réseau virtuel privé dans réseau cœur 1-tier d’AT&T [36]. Bien que la plupart des travaux pendant ce temps se soient concentré sur la gestion de routage dans un seul FAI, d’autres travaux [31] [29] ont également proposé des moyens de permettre le contrôle d’itinéraire souple à travers de multiples domaines administratifs.
Déplacer les fonctionnalités de contrôle hors de l’équipement réseau et dans des serveurs distincts a un sens parce que la gestion du réseau est, par définition, une activité pour l’ensemble du réseau. Les contrôleurs logiquement centralisés [28] [30] [36] ont été permis par l’émergence de logiciels de routage open-source [37] [38] [39] qui ont abaissé la barrière à la création d’implémentations de prototypes. Les progrès de la technologie de serveur signifiaient qu’un serveur standard seul pourrait stocker tous l’état de routage et calculer toutes les décisions de routage pour un grand réseau du FAI [28] [40]. Ceci, à son tour, a permis à des stratégies de réplication de sauvegarde primaire simple, où les serveurs de sauvegarde stockent le même état et effectuent le même calcul que le serveur principal, pour assurer la fiabilité du contrôleur.

Les contributions intellectuelles

Les premières tentatives pour séparer le plan de contrôle du plan de données étaient relativement pragmatiques, mais ils représentent un départ conceptuel important après le couplage classiquement fort du calcul de chemin et le transfert de paquet d’Internet. Les efforts visant à séparer le plan de contrôle et de données du réseau ont abouti à plusieurs concepts qui ont été reportés dans les conceptions ultérieures de SDN :

Un contrôle logiquement centralisé utilisant une interface ouverte vers le plan de données.

Les groupe de travail ForCES à l’IETF a proposé une interface standard, ouverte au plan de données pour permettre l’innovation dans le logiciel de plan de contrôle. Le SoftRouter [30] a utilisé l’API ForCES pour permettre à un contrôleur séparé d’installer des entrées de table de transfert dans le plan de données, permettant l’élimination complète des fonctionnalités de contrôle des routeurs. Malheureusement, ForCES n’a pas été adoptée par les principaux fabricants de routeurs, qui ont entravé le déploiement incrémental. Plutôt que d’attendre de nouvelles API ouvertes à émerger, le RCP [28] [29] a utilisé un protocole de plan de contrôle standard existant (Border Gateway Protocol) pour installer les entrées de table de transfert dans les routeurs existants, permettant un déploiement immédiat. OpenFlow a également été face à des défis et des contraintes de compatibilité ascendante similaires: en particulier, la spécification OpenFlow initiale s’est appuyé sur la compatibilité ascendante avec les capacités matérielles des commutateurs standards.

Gestion distribuée de l’état.

Les contrôleurs de route logiquement centralisés, ont été confrontés à des défis impliquant la gestion distribuée de l’état. Un contrôleur logiquement centralisé doit être répliqué pour faire face à l’échec du contrôleur, mais la réplication introduit la possibilité d’état incohérent à travers les répliques. Les chercheurs ont exploré les scénarios de défaillance possibles et la cohérence des exigences. Au moins dans le cas du contrôle de routage, les répliques du contrôleur n’ont pas besoin d’un protocole de gestion de l’état général, puisque chaque réplique finirait par calculer les mêmes routes (après avoir appris la même topologie et informations de routage) et les perturbations transitoires lors de des convergences de protocole de routage étaient acceptables même avec les protocoles existants [28]. Pour une meilleure mise à l’échelle, chaque instance du contrôleur pourrait être responsable d’une partie séparée de la topologie. Ces instances de contrôleurs pourraient alors échanger des informations de routage entre eux pour assurer la cohérence des décisions [40]. Les défis de la construction des contrôleurs distribués se poseraient à nouveau quelques années plus tard dans le cadre des contrôleurs SDN distribués [41] [42]. Les contrôleurs SDN distribués sont confrontés au problème beaucoup plus général du support arbitraire des applications de contrôleurs, qui exige des solutions plus sophistiquées pour la gestion distribuée de l’état.

A la recherche de généralité

Les fournisseurs d’équipements dominants n’étaient guère incités à adopter les API de plan de données standard comme ForCES, sachant que les API ouvertes pourraient permettre à de nouveaux venus d’entrer sur le marché. La nécessité résultante de s’appuyer sur des protocoles de routage existants pour contrôler le plan de données impose des limites significatives à la gamme d’applications que les contrôleurs programmables pourraient supporter. Les protocoles de routage IP classiques calcule des itinéraires pour des blocs d’adresses IP de destination, plutôt que de fournir une gamme plus large de fonctionnalités (par exemple, dropping, flooding, ou modifier les paquets)
basées sur large gamme de paquets d’en-tête (par exemple, l’adresse MAC et l’adresse IP, les ports TCP et UDP), comme le fait OpenFlow.
En fin de compte, bien que les prototypes de l’industrie et les efforts de normalisation fait quelques progrès, l’adoption généralisée est resté insaisissable. Pour élargir la vision de séparation du plan de contrôle du plan de données, les chercheurs ont commencé à explorer des architectures table rase pour le contrôle logiquement centralisé. Le projet 4D [43] a préconisé quatre couches principales : le plan de Données (pour le traitement de paquets sur la base de règles configurables), le plan de Détection (pour la collecte de topologie et des mesures de trafic), le plan de Diffusion (pour l’installation des règles de traitement des paquets), et un plan de Décision (composé de contrôleurs logiquement centralisés qui convertissent les objectifs de niveau réseau en état de gestion de paquets). Plusieurs groupes ont procédé à concevoir et construire des systèmes qui appliquent cette approche de haut niveau à de nouveaux domaines d’application [44] [45] au-delà du contrôle de routage.
En particulier, le projet Ethane [44] (et son prédécesseur direct SANE) [46] a créé, une solution au niveau du flux logique centralisé pour le contrôle d’accès dans les réseaux d’entreprise. Ethane a réduit les commutateurs à des tables de flux qui sont peuplées par le contrôleur sur la base des politiques de sécurité de haut niveau. Le projet d’Ethane, et son déploiement opérationnel dans le département d’informatique de Stanford, ont préparé le terrain pour la création d’OpenFlow. En particulier, la conception simple de switch avec Ethane est devenue la base de l’API OpenFlow originale.

OpenFlow et les Systèmes d’exploitation Réseaux

Dans le milieu des années 2000, les chercheurs et agences de financement ont eu de l’intérêt dans l’idée de l’expérimentation réseau à l’échelle, encouragé par les infrastructures expérimentales (par exemple, PlanetLab [47] et Emulab [48]), et la disponibilité du financement gouvernemental distinct pour l’ »instrumentation » à grande échelle auparavant réservé aux autres disciplines de construction cher, à infrastructure partagée comme les collisionneurs et les télescopes [49].
Une excroissance de cet enthousiasme était la création du GENI [5] avec un projet GENI Project Office financé par NFS et le programme EU FIRE [7].
Les critiques de ces efforts axés sur l’infrastructure soulignent que cet important investissement dans l’infrastructure n’a pas été accompagné par des idées bien conçues pour l’utiliser. Au milieu de cela, un groupe de chercheurs à Stanford a créé le Clean Slate Programme et se sont axé sur l’expérimentation à une échelle plus locale et maniable: les réseaux de campus [22].
Avant l’émergence d’OpenFlow, les idées sous-jacentes de SDN étaient face à une tension entre la vision des réseaux entièrement programmables et le pragmatisme qui permettrait un déploiement dans le monde réel. OpenFlow a choisi un équilibre entre ces deux objectifs en permettant plus de fonctions que les anciens contrôleurs de route et en se basant sur le matériel de commutation existant, grâce à l’utilisation croissante des chipsets en silicone vendus par les constructeurs dans les commutateurs classiques. Bien que s’appuyer sur le matériel de commutation existante ne peut que limiter la flexibilité, OpenFlow était presque immédiatement déployable, ce qui a permis au mouvement SDN d’être à la fois pragmatique et audacieux. La création de l’API OpenFlow [22] a été rapidement suivie par la conception des plateformes de contrôleur comme NOX [50] qui a permis la création de nombreuses nouvelles applications de contrôle.
Un commutateur OpenFlow a une table de règles de gestion de paquets, où chaque règle a un motif (qui correspond aux bits dans l’en-tête de paquet), une liste d’actions (par exemple, drop, flood, renvoi dans une interface particulière, modifier un champ d’en-tête ou envoyer le paquet au contrôleur), un ensemble de compteurs (pour suivre le nombre d’octets et de paquets), et une priorité (pour lever l’ambiguïté entre les règles avec des motifs qui se chevauchent). Lors de la réception d’un paquet, un commutateur OpenFlow identifie la règle de correspondance ayant la plus haute priorité, effectue les actions associées, et incrémente les compteurs.

Table des matières

INTRODUCTION GÉNÉRALE
CHAPITRE 1 LES ÉLÉMENTS DE BASE DES RÉSEAUX
1.1 Introduction
1.2 Introduction aux Réseaux
1.2.1 Evolution des Réseaux
1.2.2 Transfert, commutation et routage
1.2.3 Le transfert de paquet
1.3 Architecture des Réseaux
1.3.1 Le modèle de référence
1.3.2 Les couches du modèle de référence
1.3.2.1 La couche 1 (physique), ou niveau élément binaire
1.3.2.2 La couche 2 (liaison), ou niveau trame
1.3.2.3 La couche 3 (réseau), ou niveau paquet
1.3.2.4 La couche Transport
1.3.2.5 La couche Session
1.3.2.6 La couche Présentation
1.3.2.7 La couche application
1.4 L’architecture TCP/IP
1.4.1 Rôle de la DARPA
1.4.2 Le projet ARPAnet
1.4.3 Les couches TCP/IP
1.4.4 Le modèle DOD
1.4.4.1 La couche accès réseau
1.4.4.2 La couche Internet
1.4.4.3 La couche transport hôte à hôte
1.4.4.4 La couche application
1.4.5 Hiérarchie de l’implémentation de TCP/IP
1.5 Les techniques de transferts
1.5.1 Commutation de circuit
1.5.2 Commutation de paquets
1.5.3 Commutation par paquets (X25)
1.5.4 Relais de trame et la commutation de trames (« Frame Relay » et « Frame Switching »)
1.5.5 ATM
1.6 Routeurs et commutateurs
1.6.1 Architecture des routeurs
1.6.2 Architecture des commutateurs
1.7 Conclusion
CHAPITRE 2 SOFTWARE DEFINED NETWORKING ET OPENFLOW
2.1 Introduction
2.2 Historique
2.2.1 Le Réseau actif
2.2.1.1 Poussée technologique et la traction de l’utilisation
2.2.1.2 Les contributions intellectuelles
2.2.1.3 A la quête d’un pragmatisme
2.2.2 Séparation du plan de données et du plan de contrôle
2.2.2.1 Poussée technologique et traction de l’utilisation
2.2.2.2 Les contributions intellectuelles
2.2.2.3 A la recherche de généralité
2.2.3 OpenFlow et les Systèmes d’exploitation Réseaux
2.2.3.1 La poussée de la technologie et l’attraction de l’utilisation
2.2.3.2 Les contributions intellectuelles
2.2.3.3 À la recherche de programmes de contrôle et les cas d’utilisation.
2.3 L’architecture SDN
2.3.1 Le plan de données
2.3.1.1 L’infrastructure réseau
2.3.1.2 Southbound interface
2.3.2 Le plan de contrôle
2.3.2.1 L’hyperviseur de réseau
2.3.2.2 Système d’exploitation réseau
2.3.2.3 Northbound interface
2.3.3 Le plan de gestion
2.3.3.1 Virtualisation basée sur le langage
2.3.3.2 Langages de programmation
2.3.3.3 Applications réseaux
2.4 OpenFlow
2.5 Conclusion
CHAPITRE 3 BIG DATA
3.1 Introduction
3.2 Définitions
3.3 Historique
3.4 MapReduce
3.4.2 Motivations de MapReduce
3.4.3 Inspiration venant du langage LISP
3.4.4 Modèle de programmation
3.4.5 Exemple
3.4.6 Types
3.5 Systèmes de fichier distribués
3.5.1 Notion de système de fichier distribué
3.5.2 NFS
3.5.3 GFS
3.5.4 HDFS
3.6 Hadoop
3.7 Conclusion
CHAPITRE 4 SIMULATION D’UN RÉSEAU D’AGRÉGATION TAP
4.1 Introduction
4.2 Réseau d’agrégation TAP
4.3 Mininet
4.3.1 Fonctionnalités
4.3.2 Particularités de Mininet
4.4 Emulation de SDN et OpenFlow
4.4.1 Description de l’environnement d’émulation
4.4.1.1 Les logiciels nécessaires
4.4.1.2 Utilitaires spécifiques à OpenFlow et de réseautage générale préinstallés dans la machine virtuelle Mininet
4.4.2 Choix du contrôleur
4.4.3 Implémentation d’un switch d’apprentissage L2
4.5 Émulation d’un cluster Hadoop
4.5.1.1 Configuration d’un cluster à un seul nœud
4.5.1.2 Configuration du mode pseudo-distribué
4.5.1.3 Configuration de l’accès ssh sans mot de passe
4.5.2 Utilisation d’un cluster pour analyser les trafics sur un réseau SDN
4.5.3 Démarrage de Hadoop et implémentation d’une simple tâche
4.5.4 Configuration de YARN
4.5.5 Implémentation d’une tâche MapReduce
4.6 Conclusion
CONCLUSION GÉNÉRALE
ANNEXE 1 Matériels compatible OpenFlow et les dispositifs logiciels
ANNEXE 2 Messages OpenFlow
BIBLIOGRAPHIE

Télécharger le rapport complet