Algorithmes d'allocation de ressources pour réseaux virtuels

MINISTÈRE DE L'ÉDUCATION NATIONALE, DE L'ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE ****** Institut National des Sciences Appliquées TOULOUSE Département de Génie Électrique et Informatique Projet de fin d'études Algorithmes d'allocation de ressources pour réseaux virtuels Mikaël Capelle Marie-José Huguet Slim Abdellatif Pascal Berthou Juin 2014

Algorithmes d'allocation de ressources pour réseaux virtuels Mikaël Capelle Résumé Face aux besoins croissants en terme de communication des applications informatiques actuelles, l'architecture historique des réseaux est en pleine évolution. L'arrivée de composants réseaux programmables, avec centralisation des contrôles, a permis l'arrivée et la mise en place de nouvelles approches. La virtualisation (allocation de réseaux virtuels) en fait partie - Permettant le déploiement sur une même architecture physique, de diérents réseaux virtuels, elle semble aujourd'hui un élément clé pour les besoins futurs de l'internet. Ce document propose un modèle de Programmation Linéaire en Nombres Entiers permettant l'allocation de ressources pour des liens virtuels. Ce modèle a été implémenté dans un solveur de programmation mathématique (CPLEX). Des expérimentations basées sur des simulations de requêtes de virtualisation ont été effectuées sur une architecture à topologie réelle, GÉANT. Les résultats ont montré que l'approche proposée permet l'allocation de liens virtuels dans des temps de calcul limités. Ils ont également permis de mettre en évidence l'apport de méthodes de ce type (en termes de taux d'acceptation des requêtes et revenus) par rapport à des approches heuristiques standards. Tuteurs de stage : Marie-José Huguet, Slim Abdellatif, Pascal Berthou Tuteur pédagogique : Nicolas Jozefowiez 2

Remerciements Je tiens tout d'abord à remercier mes trois tuteurs - Marie-José Huguet, Slim Abdellatif et Pascal Berthou, pour m'avoir suivi, aiguillé et conseillé tout au long de ce projet. Je remercie également tous les membres de l'équipe ROC pour m'avoir chaleureusement accueilli durant ces 5 derniers mois, ainsi que toutes les personnes de l'équipe SARA que j'ai pu rencontrer au cours de mon stage. Enn, je remercie mon tuteur pédagogique Nicolas Jozefowiez, tous les enseignants et personnels du département Génie Électrique et Informatique de l'insa, ainsi que ceux du parcours de Master IAICI 1. 1. Intelligence Articielle, Intelligence Collective et Interaction 3

Table des matières 1 Présentation du laboratoire 7 1.1 Le LAAS - CNRS............................... 7 1.2 L'équipe ROC................................. 7 1.3 L'équipe SARA................................ 8 2 Contexte de la virtualisation réseaux 9 2.1 La virtualisation de réseaux......................... 9 2.1.1 Dénition de la virtualisation.................... 9 2.1.2 Les requêtes de virtualisation.................... 10 2.2 Caractéristiques des problèmes de virtualisation.............. 10 2.2.1 La topologie du réseau........................ 11 2.2.2 Les liens virtuels et les liens physiques............... 11 2.2.3 Les routeurs.............................. 11 2.2.4 Le délai................................ 12 2.2.5 La migration de requête....................... 12 2.2.6 Objectifs............................... 13 2.3 État de l'art de la littérature existante................... 13 2.3.1 L'allocation de ressources pour des réseaux virtuels........ 13 2.3.2 L'allocation de ressources pour des liens virtuels......... 14 2.4 Synthèse.................................... 15 2.5 Positionnement de notre problème..................... 15 2.5.1 Dénition............................... 15 2.5.2 Hypothèses.............................. 17 3 Modélisation 18 3.1 Données en entrée.............................. 18 3.1.1 Le réseau physique.......................... 18 3.1.2 Les requêtes.............................. 18 4

3.1.3 Évolution temporelle......................... 19 3.2 Variables.................................... 19 3.2.1 Flux.................................. 19 3.2.2 Délai.................................. 19 3.2.3 Charge des routeurs......................... 20 3.3 Contraintes.................................. 20 3.3.1 Conservation du ot et respect de la demande en bande passante 20 3.3.2 Respect de la contrainte de capacité des liens physiques..... 20 3.3.3 Respect de la contrainte de bande passante minimale....... 20 3.3.4 Respect de la contrainte de délai des sessions........... 21 3.4 Fonction(s) objective(s)........................... 21 3.4.1 Équilibre des charges......................... 21 3.4.2 Minimisation du nombre de routeurs utilisés............ 21 3.5 Variation sur le calcul de la fonction objective............... 22 3.6 Apport du modèle par rapport à l'existant................. 22 4 Modèle linéaire 23 4.1 Variables.................................... 23 4.2 Contraintes.................................. 24 4.2.1 Flux et bande passante........................ 24 4.2.2 Délai.................................. 24 4.2.3 Charge des n uds.......................... 25 4.2.4 Charges maximales.......................... 25 4.3 Fonction(s) objective(s)........................... 25 4.4 Complexité.................................. 26 5 Expérimentations 27 5.1 Le réseau................................... 27 5.1.1 Capacité des liens.......................... 27 5.1.2 Les délais de transmission des liens................. 28 5.1.3 La capacité des routeurs....................... 28 5.2 Les requêtes.................................. 28 5.2.1 Le taux d'arrivée........................... 28 5.2.2 La durée de vie............................ 28 5.2.3 Les diérents types de requêtes................... 28 5.2.4 Le path-splitting........................... 29 5

5.2.5 Le choix des sources et destinations................. 29 5.3 Les paramètres d'expérimentation...................... 29 5.3.1 La durée d'expérimentation..................... 29 5.3.2 La fonction objective......................... 30 5.4 Fonctionnement des expérimentations................... 30 5.5 Métriques utilisées.............................. 30 5.5.1 Le taux d'acceptation des requêtes................. 30 5.5.2 Les revenus générés.......................... 31 5.5.3 La charge globale des liens du réseau................ 31 5.5.4 Le taux d'utilisation des liens.................... 32 5.6 Implémentations............................... 32 5.6.1 Paramètres du solveur........................ 32 5.6.2 Implémentation C++........................ 32 5.6.3 Les scripts d'analyse des résultats.................. 33 6 Résultats et Analyses 35 6.1 Comparaison avec des méthodes heuristiques............... 35 6.2 Caractérisation des temps de calcul..................... 36 6.3 Validation de la durée de simulation.................... 37 6.4 Inuence des paramètres du modèle..................... 38 6.4.1 Taux d'acceptation des requêtes................... 38 6.4.2 Revenus totaux des simulations................... 40 6.4.3 Charge du réseau........................... 43 6.5 Visualisation de l'équilibre de l'utilisation des liens dans le réseau.... 44 6.6 Analyse du taux d'acceptation des instances de type unicast et multicast 45 6

Introduction An de répondre aux dés posés par les applications émergentes, l'architecture de communication des réseaux historiques, dont l'internet, n'a cessé d'évoluer de manière incrémentale, sans remise en cause des principes fondateurs de celle-ci. Face aux évolutions dans l'usage des réseaux actuels menant à une distribution croissante des contenus (Cloud Computing, Machine-to-Machine (M2M), Internet of Things (IoT)), diérents programmes de recherche sur l'architecture des réseaux du futur ont été initiés durant ces dernières années : Future Internet Architecture [6] ou Global Environment for Network Innovations [8] de la NSF (National Science Foundation), Future Internet Research [5] de l'european Future Internet Assembly ou encore le programme Japonnais, New Generation Network [16]. Ces projets ont permis d'identier diérents nouveaux paradigmes incontournables aux réseaux du futur, et dont certains sont en rupture avec les principes historiques de conception des réseaux. C'est notamment le cas de la virtualisation réseau (où tous les éléments du réseau peuvent être virtualisés, routeurs et n uds internes inclus) [1] ou bien les réseaux programmables / guidés par du logiciel (plus connus sous le nom de SDN pour Software Dened Networks) [12, 18]. La virtualisation s'impose comme un élément clé qui permettra aux réseaux de fournir des services diversiés an de répondre aux besoins des applications actuelles et à venir. Le partitionnement des ressources permet à diérents réseaux virtuels de cohabiter de manière isolée sur un même réseau physique, tout en orant chacun des services spéciques. L'approche SDN quant à elle apporte de la exibilité aux réseaux (propriété très peu développée dans les architectures actuelles) an de s'adapter aux besoins applicatifs et à leurs environnements opérationnels. Le principe des SDNs rompt directement avec l'historique de décentralisation des réseaux : alors qu'avant les fonctions de contrôle étaient localisées au sein même des équipements réseaux (routeurs, switchs), l'approche SDN les déplace vers des composants centraux (contrôleurs SDN). Le pilotage à distance de ces contrôleurs via des interfaces de programmation (API) ouvre la voie à un contrôle n et continu du comportement des réseaux. L'une des applications phares de cette approche SDN est la virtualisation réseau dénie précédemment. En eet, les possibilités de programmation des équipements réseaux oertes par les SDNs permettent le déploiement sur une même architecture physique de plusieurs réseaux logiques isolés avec des caractéristiques diérentes (performances, topologie, etc.). Avec cette possibilité de déploiement des réseaux virtuels, de nouvelles problématiques d'optimisation apparaissent, dont la principale : quelle est la meilleure allocation possible d'un réseau logique sur un réseau physique donné? Le terme meilleure 7

dans cette question peut ramener à diérents objectifs : maximisation des revenus pour un fournisseur de services, minimisation de l'utilisation du réseau, minimisation de l'énergie consommée, etc. Ce document tente de répondre à la problématique de virtualisation de réseaux, et plus particulièrement à celle de l'optimisation de l'allocation de ressources pour des liens virtuels dans un réseau physique à topologie réelle sous contraintes de bande passante, de délai et de charge de commutation des routeurs. Ce rapport décrit le travail réalisé dans le cadre de mon stage de n d'études couplant ma formation d'ingénieurs en Informatique (majeure Systèmes Embarqués Critiques) et ma formation en master recherche Informatique et Télécom (parcours IAICI) de l'insa de Toulouse. Ce stage s'est déroulé au LAAS-CNRS de février à juillet 2014. 8

Chapitre 1 Présentation du laboratoire 1.1 Le LAAS - CNRS Le Laboratoire d'analyse et d'architecture des Systèmes (LAAS) est une unité propre du CNRS localisée à Toulouse. Créé en 1968 par Jean Lagasse, c'est aujourd'hui un des plus grands centres de recherche de la région Midi-Pyrénées. Les travaux qui y sont eectués portent sur les sciences et technologies de l'information, de la communication et des systèmes. Les thématiques de recherche du LAAS s'articulent autour de 8 thèmes animant l'activité de 22 équipes de recherche, unités de base au sein du laboratoire : Informatique Critique Réseaux et Communications Robotique Décision et Optimisation Hyperfréquences et Optique : de l'electromagnétisme aux Systèmes Nano Ingénierie et Intégration Micro Nano Bio Technologies Gestion de l'énergie J'ai eectué mon stage sous la tutelle de Marie-José Huguet (équipe ROC), Slim Abdellatif et Pascal Berthou (équipe SARA). 1.2 L'équipe ROC L'équipe Recherche Opérationnelle / Optimisation Combinatoire / Contraintes (ROC) est une des trois équipes du thème Décision et Optimisation. Sous la responsabilité de Christian Artigues, les recherches qui y sont menées portent principalement sur le développement de modèles et de méthodes pour la résolution de problèmes combinatoires. Les domaines d'application abordés sont variés : gestion de projet, systèmes de production de biens (type ateliers) ou de services (transports, télécom). Les problèmes traités relèvent de l'aectation et l'ordonnancement de tâches, du transport de biens ou de personnes, de l'allocation et de la gestion de ressources ou bien encore de la planication. 9

1.3 L'équipe SARA L'équipe Services et Architectures pour les Réseaux Avancés (SARA), sous la responsabilité de Khalil Drira, s'inscrit dans la thématique Réseaux et Communications. Les recherches qui y sont menées portent majoritairement sur les réseaux, les systèmes de communication de nouvelle génération ainsi que leurs applications (conception, planication, gestion du déploiement, supervision). Les contributions fournies vont de l'élaboration de méthodes, modèles et outils à la proposition d'architectures, protocoles et services, avec comme objectif premier l'analyse et l'évaluation des performances ainsi que le contrôle et le prototypage de logiciels et plates-formes de communication. 10

Chapitre 2 Contexte de la virtualisation réseaux 2.1 La virtualisation de réseaux La virtualisation, dans sa dénition générale, consiste à allouer sur un ensemble de composants physiques, un ensemble de composants virtuels de même type mais avec des caractéristiques moindres (plus faibles). La virtualisation de réseau, dans sa spécicité, consiste à placer sur un réseau physique (ensembles de routeurs et liens physiques), un ou plusieurs réseaux virtuels (ensembles de routeurs et liens logiques) isolés et indépendants. Les ressources consommées par chaque élément logique sur l'élément physique sur lequel il est alloué peuvent être variables et seront discutées par la suite ; Ces ressources ne sont pas partagées entre deux éléments logiques (ou virtuels), ce qui permet d'isoler les réseaux les uns des autres, et ainsi éviter toute interférence entre deux réseaux virtuels, ou encore protéger un réseau virtuel face aux dysfonctionnement d'un autre. Cet isolement des réseaux permet également à chaque réseau virtuel de posséder des propriétés spéci- ques en termes de qualité de services (QoS pour Quality of Service), performances et sécurité, mais également de fournir des services qui lui sont propres. Ainsi, deux réseaux virtuels cohabitant sur une même infrastructure physique pourraient avoir des propriétés diérentes et fournir des services distincts. 2.1.1 Dénition de la virtualisation L'allocation de ressources pour des réseaux virtuels L'allocation de ressources pour des réseaux virtuels est un problème NP-Dicile [11] qui consiste à allouer un réseau virtuel R V sur un réseau physique R P. Cette allocation consiste à trouver un placement M des routeurs et liens virtuels, tel que : Chaque routeur (n ud) virtuel n v soit alloué sur un routeur (n ud) physique n p = M(n v ). Chaque lien virtuel l v reliant deux n uds virtuels n v 1 et n v 2 soit alloué sur un chemin M(l v ) = (l p 1, lp 2,..., lp k ) reliant M(nv 1 ) et M(nv 2 ). Comme expliqué précédemment, le placement M doit en général respecter un ensemble de contraintes en termes de QoS, performances et sécurité. Les diérentes contraintes pouvant être concernées par l'allocation sont dénies dans la section 2.2. 11

Ainsi, l'allocation de ressources pour de la virtualisation réseaux met en jeu deux problèmes d'allocation interdépendants : allocation de n uds virtuels à des n uds physiques et allocation de liens virtuels à des chemins physiques. Un n ud virtuel ne peut être distribué sur plusieurs n uds physiques, et pour une requête de virtualisation donnée, un seul n ud virtuel peut être alloué sur chaque n ud physique. Un lien virtuel peut avoir un ensemble de n uds destination n p d 1, n p d 2,..., n p d k (liens de type multicast), ou un seul (lien de type unicast). De plus, il peut être alloué sur diérents chemins physiques (utilisation du path-splitting). Dans la suite de ce travail, nous nous sommes plus particulièrement centré sur l'allocation de liens virtuels. Cas particulier de l'allocation de ressources pour des liens virtuels L'allocation de liens virtuels trouve sont intérêt auprès de fournisseurs de services proposant la création de tunnels entre diérentes destinations, avec des garantie en termes de bande passante, QoS, sécurité et performances. L'allocation de ressources pour des liens virtuels est un sous-problème de l'allocation de ressources pour des réseaux virtuels dans lequel les n uds virtuels sont déjà placés sur le réseau physique. On cherche donc à trouver un ou plusieurs chemins entre plusieurs routeurs physiques (une source n p s et des destinations n p d 1, n p d 2,..., n p d k ), sous diérentes contraintes (cf. section 2.2). 2.1.2 Les requêtes de virtualisation Dans un problème d'allocation de ressources pour des réseaux virtuels, les requêtes sont des demandes d'allocation d'un ou plusieurs réseaux ou liens virtuels. Elles peuvent être très variées et être plus ou moins contraintes (voir 2.2). L'allocation de ressources peut intervenir : 1. A chaque arrivée de requête : On cherche alors à déterminer puis aecter les ressources nécessaires pour répondre à celle-ci sans remettre en cause les ressources déjà allouées sur le réseau physique pour les requêtes précédentes. Ce cas de gure (que nous considérerons ici) trouve son application dans le cadre d'un fournisseur de réseaux virtuels à la demande avec un déploiement de quelques minutes. 2. En connaissant préalablement toutes les requêtes de réseaux virtuels à satisfaire : On peut alors tirer prot de cette connaissance globale pour obtenir une meilleure allocation. Ce cas de gure intervient dans des phases de dimensionnement et d'optimisation du réseau. Ce modèle de fourniture de réseaux virtuels est beaucoup moins exible que le précédent. 2.2 Caractéristiques des problèmes de virtualisation Les problèmes d'allocation de ressources pour les réseaux virtuels peuvent prendre plusieurs formes ou s'exprimer de diérentes manières selon les contraintes et objectifs visés. 12

2.2.1 La topologie du réseau Dans les problèmes de virtualisation, l'une des données les plus importantes est la topologie des réseaux virtuels et physiques : les routeurs et les liens. En général, on représente une topologie réseau sous forme d'un graphe orienté G = (V, E) où V représente l'ensemble des routeurs (n uds) et E V V l'ensemble des liens. 2.2.2 Les liens virtuels et les liens physiques La bande passante est certainement l'aspect le plus important à prendre en compte lors des problèmes d'allocation de ressources pour réseaux virtuels et liens virtuels. Il est nécessaire de trouver un chemin physique reliant deux n uds avec une capacité susante par rapport aux demandes, c'est à dire : Respectant les contraintes de capacité au niveau des liens physiques formant le chemin. Respectant les contraintes de conservation du ux au niveau des routeurs composant le chemin physique. En plus de ces deux contraintes fondamentales sur la bande passante, d'autres caractéristiques peuvent être prises en compte, notamment : Le Path Splitting - Distribuer le trac correspondant à un lien virtuel (une source et une destination) sur plusieurs chemins physiques. Cette caractéristique requiert des protocoles spéciques au niveau du réseau (le besoin d'étiqueter certains paquets, entre autres). Le Multicast - Envoyer un message d'une source vers m destinations, sans avoir besoin de créer m chemin disjoints. Lors de la dénition des requêtes de virtualisation, il est possible de considérer soit le débit moyen demandé par la requête, soit le débit maximal. Dans le premier cas, le réseau virtuel sera alors surdimensionné, dans le deuxième cas il y des risques de congestion au niveau des routeurs. 2.2.3 Les routeurs La charge de virtualisation des routeur Dans un contexte d'allocation de réseaux virtuels, un des aspects importants à prendre en compte est la charge des routeurs physiques sur lesquels sont alloués des routeurs virtuels : un routeur physique ne peut supporter qu'un nombre ni de routeurs virtuels dépendant de sa capacité et des besoins des composants virtuels. La charge d'un routeur liée à la virtualisation peut apparaître sous diérentes formes : Charge processeur, RAM, etc. En réalité, il est aujourd'hui dicile de quantier les ressources utilisées par la virtualisation d'un routeur [19]. La charge liée à la commutation des routeurs À la fois dans un contexte d'allocation de réseaux et de liens virtuels, la charge des routeurs liée à la commutation des paquets est un élément non négligeable à prendre en compte pour la résolution du problème de virtualisation. Dans un contexte SDN 13

/ OpenFlow [12, 18], la charge de commutation d'un routeur est étroitement liée au nombre de règles traitées par le routeur (i.e. la taille de la table des ots). Les scénarios de routage étant très variés (multicast, path-splitting, etc.), il est actuellement dicile de quantier de façon générique le nombre de règles nécessaire à la réalisation du routage d'un lien virtuel. La localisation Dans certains problèmes, il peut être nécessaire d'ajouter des contraintes de localisation sur les n uds virtuels. Elles peuvent être de diérents types : Des contraintes sur la distance entre les positions physiques des éléments (exemple : deux routeurs physiques sur lesquels sont alloués deux routeurs virtuels reliés par un lien virtuel ne peuvent être distants de plus de 200 mètres) - Cette contrainte peut être utile lors de l'allocation sur des réseaux composés de plusieurs ensembles de n uds (bâtiments / pièces), an de forcer l'emplacement de plusieurs routeurs virtuels dans des endroits peu distants (pour des questions logistiques, par exemple). Des contraintes de placement pour les n uds virtuels : un n ud virtuel ne peut être placé que dans une zone prédénie (ou un ensemble spécique de n uds physiques). Des contraintes d'allocation : certains n uds virtuels sont déjà placés sur le réseau physique. 2.2.4 Le délai Le délai dénit le temps nécessaire pour qu'un paquet circule d'un routeur physique n 1 vers un routeur physique n 2. La contrainte en général exprimée est celle du délai admissible, i.e le délai maximal qu'un paquet ne doit pas dépasser. C'est une contrainte importante en terme de QoS, et donc un aspect très important dans les problèmes de virtualisation. Le délai peut être pris en compte à diérents endroits : Sur les liens, via le temps de transmission d'un message (correspondant au temps d'émission du message par un routeur plus le temps de propagation du message sur le lien). Sur les routeurs, en fonction de la congestion de ceux-ci (cf. ux moyen / max) et du temps de traitement des paquets (dépendant de la charge des routeurs). 2.2.5 La migration de requête La migration est un aspect mis de plus en plus en avant dans les réseaux recon- gurables autorisant la réallocation de requêtes de virtualisation déjà placées an de permettre le traitement d'une nouvelle requête. En général, la migration consiste à identier les éléments critiques du réseaux avant d'essayer de les soulager sans remettre en cause les besoins et contraintes des requêtes déjà traitées. La migration possède en général un coût non négligeable, à la fois au niveau du traitement des requêtes (algorithme plus lourd car plus libre) et au niveau des réaectations (temps de migration des ressources d'un élément vers un autre) alors que le réseau 14

virtuel est en phase opérationnelle. [14] 2.2.6 Objectifs Équilibrage des charges Lors de la résolution du problème d'allocation de réseaux ou liens virtuels, un des objectifs fréquemment considéré consiste à rechercher un équilibrage de l'utilisation du réseau physique. Cette équilibrage consiste à préférer distribuer la bande passante sur plus de liens physiques, plutôt que surcharger un nombre restreint de liens. On peut également vouloir équilibrer la charge des routeurs intermédiaires, an d'éviter toute congestion. Coûts et revenus nanciers Suivant le contexte, l'aspect nancier lié à l'allocation de réseaux et de liens virtuels peut être intégré au problème. Il peut apparaître sous 2 formats : Le coût et le revenu. Le coût est principalement lié à l'utilisation des composants physiques du réseau (lien, routeur, etc.). Le revenu est dépendant de la requête. Dans un concept de fournisseur, une requête avec un revenu élevée peut être vue comme prioritaire par rapport aux autres. Dans ce même concept, la satisfaction d'un maximum de requête (le taux d'acceptation) est un enjeu important. 2.3 État de l'art de la littérature existante La plupart des travaux existants de la littérature actuelle peuvent être séparés en deux familles : ceux traitant de l'allocation de réseaux virtuels (Virtual Network Mapping / Embedding) dans lesquels on considère de manière simultanée les deux problèmes d'allocation de n uds et de liens, et ceux traitant de l'allocation de liens virtuels dans lesquels on ne s'intéresse qu'à l'allocation des liens (les extrémités de ces liens étant déjà placés sur le réseau physique). 2.3.1 L'allocation de ressources pour des réseaux virtuels L'allocation de réseaux virtuels a récemment suscité un engouement dans la communauté scientique qui a mené à l'apparition de diérentes méthodes de résolution. Dans [17], Nogueira et al. proposent un algorithme polynomial pour l'allocation de réseaux virtuels basé sur une heuristique et utilisant la notion de stress. Le stress est une valeur propre à chaque élément physique dépendant des ressources disponibles lors de la requête (Bande passante utilisée et disponible pour les liens, CPU / RAM pour les routeurs). Dans [11], Lischka and Karl utilisent un algorithme de recherche de sous-graphe isomorphisme pour trouver une allocation possible d'un réseau virtuel sur un réseau physique. Leur algorithme prend en compte la charge des routeurs et des liens ainsi 15

qu'un délai calculé par rapport au nombre de sauts sur un chemin physique (nombre de liens physiques utilisés pour créer un lien virtuel). Hsu et al. proposent dans [9] diérents algorithmes pour l'allocation de routeurs et liens virtuels avec possibilité de path-splitting et migration. L'algorithme de pathsplitting proposé est récursif et n'utilise le path-splitting que si nécessaire : pour un besoin B en bande passante, l'algorithme va d'abord chercher un chemin de capacité au moins égale à B, s'il ne trouve pas, il tente de trouver deux chemins de capacité au moins égale à B/2 (avec des arcs en commun de capacité au moins égale à B), et ainsi de suite. Si l'algorithme ne parvient pas à trouver un chemin après plusieurs itérations, il va alors chercher à migrer des chemins existants. Les résultats de Hsu et al. montrent l'intérêt du path-splitting et de la migration dans les problèmes d'allocation de réseaux virtuels. Cette approche utilisant le path-splitting et la migration est également abordée par Yu et al. dans [22] qui propose une méthode de type Try and Error : Allocation des n uds, tentative d'allocation des liens sans path-splitting, tentative avec path-splitting si les premières ont échoué (basée sur la résolution d'un problème de Multi Commodity Flow), migration des n uds si nécessaires et enn migrations des liens (changement de ratio dans les splits ou ré-allocation totale) si aucun des essais précédents n'a abouti. L'approche de Yu et al. dière en revanche de celle de Hsu et al. dans la gestion de l'arrivée des requêtes : Alors que Hsu et al. traitent les requêtes une par une, Yu et al. attendent d'avoir un certains nombre de requêtes avant de les allouer dans le but de commencer par celles orant le meilleur revenu. Les deux articles [2] (réédité en 2012, voir [3]) et [15] utilisent une formulation de Programmation Linéaire en Nombres Entiers pour tenter de résoudre le problème. Dans [15], Melo et al. proposent une résolution du problème sans relaxation, avec prise en compte de plusieurs contraintes (Bande passante, délai, position des routeurs, charge des routeurs (CPU / RAM)), et des résultats avec diérentes fonctions objectives. Chowdhury et al. [2] proposent une résolution utilisant une relaxation du problème : la relaxation permet de trouver rapidement un placement des routeurs. Deux versions sont proposées : la première alloue chaque routeur virtuel n v sur le routeur physique n p possédant le meilleur score retourné par la résolution du problème relaxé, la deuxième ajoute de l'aléatoire dans le choix des routeurs. Les chemins sont ensuite alloués via un algorithme de Multi Commodity Flow. 2.3.2 L'allocation de ressources pour des liens virtuels L'article [7] propose une méthode de résolution par contraintes (CSP) ne prenant en compte que les besoins en bande passante des requêtes. Les routeurs sont regroupés pour former des Blocking Islands, permettant ainsi l'utilisation d'heuristiques ecaces pour le choix des variables et des valeurs à aecter durant la résolution du CSP. Frei and Faltings montrent que leur méthode permet d'éviter l'allocation de liens critiques lorsque ce n'est pas nécessaire, contrairement à des algorithmes de plus court chemin classiques. Le problème de l'allocation de ressources pour liens virtuels peut facilement s'assimiler à un problème de Multi Commodity Flow. Masri et al. [13] proposent un algorithme basé sur une méta-heuristique Colonie de Fourmis pour résoudre le problème du routage de plusieurs ots multisource et multicast avec prise en compte de la bande passante et minimisation du délai et du coût. Wei et al. proposent dans [20] un algorithme basé sur la prédiction du trac dans le réseau et utilisant les algorithmes de Djikstra et de 16

résolution d'un Multi Commodity Flow : L'algorithme tente d'abord de résoudre le problème en utilisant l'algorithme de Djikstra, puis un algorithme de résolution de Multi Commodity Flow si le premier n'a pas abouti. Xi and Yeh proposent dans [21] un algorithme distribué pour le routage de ots multicast. L'algorithme trouve d'abord un chemin de la source vers chaque destination t, utilisant sur chaque lien (i, j) une quantité de bande passante b t (i, j). La quantité de bande passante consommée b(i, j) par le lien multicast peut alors être calculée via b(i, j) = max b t (i, j). Kucharzak and Walkowiak proposent dans [10] diérentes heuristiques pour l'allocation d'arbres multicast prenant en compte uniquement des contraintes au niveau de la bande passante. 2.4 Synthèse Le tableau 2.1 fournit un récapitulatif des diérents aspects pris en compte dans chaque article cité dans la section précédente. Les caractéristiques et contraintes considérées par les travaux de la littérature actuelle sont variés. Alors que tous prennent en compte les besoins en bande passante, seulement quelques un prennent en compte le délai, ou la charge des routeurs. La plupart des algorithmes proposés ne font pas usage du multicast, du path-splitting ou de la migration pour obtenir des meilleurs résultats. Finalement, aucun ne prend en compte la charge des routeurs liée à la commutation de paquets. 2.5 Positionnement de notre problème 2.5.1 Dénition Le problème Dans la suite, nous nous intéressons aux problèmes d'allocation de liens virtuels, avec prise en compte des contraintes de bande passante (avec possibilité de pathsplitting), de délai et de charge des routeurs liée à la commutation de paquets. Bien que la plupart de ces aspects aient déjà été étudiés de manières isolés dans de nombreux travaux, il n'existe pas à notre connaissance de méthode pour l'allocation de réseaux ou liens virtuels les incluant tous. De plus, aucun article à ce jour ne prend en compte la charge des routeurs liées à la commutation dans les problèmes d'allocation de réseaux virtuels. Les requêtes On considérera des requêtes arrivant les unes après les autres, sans remise en cause de l'allocation des requêtes précédentes. Chaque requête sera caractérisée par un temps d'arrivée et une durée de vie. Les requêtes d'allocation traitées seront composées d'une ou plusieurs sessions. Chaque session représente un lien virtuel possédant une source unique (un routeur physique) et un ensemble de destinations (routeurs physiques), permettant ainsi des liens point à 17

Table 2.1 Récapitulatif des diérents types d'allocation et contraintes étudiés par chaque article Allocation Contraintes Type de liens Techniques Masri et al. [13] Liens Bande Passante Multi-sources Délai Multicast Nogueira et al. [17] Réseaux Bande Passante Charge routeurs (CPU / RAM) Unicast Lischka and Karl [11] Réseaux Bande Passante Délai Charge routeurs (CPU / RAM) Unicast Hsu et al. [9] Liens Bande Passante Unicast Path-Splitting Migration Chowdhury et al. [2] Réseaux Bande Passante Localisation des routeurs Charge routeurs (CPU / RAM) Unicast Melo et al. [15] Réseaux Bande Passante Délai Localisation des routeurs Charge routeurs (CPU / RAM) Unicast Frei and Faltings [7] Liens Bande Passante Multicast Wei et al. [20] Réseaux Bande Passante Unicast Hsu et al. [9] Réseaux Bande Passante Path-Splitting Unicast Localisation des routeurs Migration Xi and Yeh [21] Liens Bande Passante Multicast Kucharzak and Walkowiak [10] Liens Bande Passante Multi-sources 18

point et point à multipoint. Une session est caractérisée par une demande identique en termes de bande passante et de délai à respecter. De plus, an de limiter une trop grande fragmentation liée à l'utilisation du pathsplitting, nous ajoutons à chaque session une valeur minimale de bande passante. En eet, il peut être préférable, pour une session demandant une bande passante de 1 Gbps, de ne pas allouer des quantités de bande passante inférieures à 200 Mbps sur un lien physique. Les allocations possibles En fonction de ses caractéristiques, un lien virtuel pourra être alloué sur le réseau physique en utilisant : Un seul chemin : lien virtuel point à point (unicast), sans path-splitting. Un arbre : lien virtuel point à multipoint (multicast), sans path-splitting. Un ensemble de chemins : lien virtuel point à point (unicast) ou point à multipoint (multicast), avec path-splitting. 2.5.2 Hypothèses Dans la suite, on se placera dans l'hypothèse d'un réseau entièrement virtualisé où l'utilisation d'une ressource physique est bornée par sa capacité, i.e. elle ne peut pas être allouée à une requête si celle-ci a un besoin supérieur à la capacité restante. Perte de paquets et délai lié à la congestion Sous cette hypothèse, on peut considérer qu'il n'y a pas de congestion au niveau des routeurs (l'utilisation des liens entrants ne peut être supérieure à celle des liens sortants), et donc qu'il n'y a pas de perte de paquets ou de délai liés à la congestion des routeurs. Charge des routeurs On se place dans le cadre d'un réseau programmable (Software Dened Network), de type OpenFlow par exemple. Comme indiqué précédemment, il est dicile de quantier la charge des routeurs liées à la commutation, c'est pourquoi l'hypothèse suivante sera faite : la charge d'un routeur liée à la commutation de paquets est directement proportionnelle au nombre d'entrées dans sa table des ots, elle même proportionnelle au nombre de ots entrants dans ce routeur. Ainsi la charge d'un routeurs sera proportionnelle au nombre de liens entrants dans ce routeur. Full-Duplex On considérera que l'intégralité des liens du réseau physique fonctionnent en mode full-duplex, c'est à dire permettant les communications dans les deux sens simultanément. Ainsi un lien (i, j) de capacité 100 Gbps possède des ressources pouvant soutenir un lien virtuel de capacité 100 Gbps de i vers j ET un lien virtuel de même capacité 19

de j vers i. Les ressources utilisées dans un sens n'entrent donc pas en compte dans le calcul des ressources utilisées dans l'autre sens. 20

Chapitre 3 Modélisation Après avoir déni le problème de virtualisation considéré dans le chapitre précédent, ce chapitre propose une modélisation non linéaire en utilisant le formalisme de la programmation mathématique. 3.1 Données en entrée 3.1.1 Le réseau physique La topologie du réseau physique est représentée par un graphe G = (V, E) où V ( V = N) est l'ensemble des n uds physiques et E ( E = M, E V V ) l'ensemble des liens physiques reliant deux n uds. On notera sans distinction (i, j) ou e un lien physique, en fonction du contexte, et on considérera que tous les liens sont bidirectionnels (full-duplex). Chaque n ud est déni par sa capacité (nombre d'entrées acceptables dans la table de ots) u i et chaque lien est déni par sa capacité c ij et son temps de propagation d ij. (i, j) E : d ij = d ji et c ij = c ji (3.1) On dénit la fonction Ng : V 2 V qui associe à un n ud i donné sa liste de voisins, i.e. : Ng(i) = {j j V, (i, j) E ou (j, i) E} 3.1.2 Les requêtes On suppose en entrée un ensemble de K sessions unicast ou multicast k 1,..., k K, chaque session étant dénie par : Une source s k V. Un ensemble de destination(s) T k V {s k }. Dans le cas d'un lien unicast, T k = 1. Un besoin en bande passante b k N et un délai acceptable d k N. La taille maximale des paquets p k transmis par la session. 21

La bande passante minimale b min k utilisable sur un lien (pour la gestion du Path- Splitting an d'éviter un trop gros découpage dans les ux). Remarque : Si b min k = b k, le ux associé à la session ne peut pas être divisé et réparti sur diérents chemins. En pratique, on dénira b min k comme un pourcentage (ratio) de b k, b min k = P S ratio b k avec P S ratio [0, 1] (Il y a possibilité de path-splitting si P S ratio 0.5, pour éviter des calculs inutiles on xera P S ratio = 1.0 lorsque que le path-splitting n'est pas autorisé). 3.1.3 Évolution temporelle En pratique, on considérera des requêtes arrivant les unes à la suite des autres, chacune étant traitée indépendamment des autres (i.e. chaque arrivée de requête donne lieu à une nouvelle résolution du modèle, puisque le modèle est construit pour l'allocation d'une seule requête). Lors de l'arrivée d'une requête au temps t, an de prendre en compte les précédentes allocations, il est nécessaire de connaître les ressources du réseaux utilisées au temps t, soit : La charge actuelle d'un routeur i : u i La charge actuelle d'un lien e : c e 3.2 Variables 3.2.1 Flux Pour chaque session k K et chaque destination t T k, on dénit une fonction f k t : E N telle que f k t (i, j) dénit la quantité de bande passante consommée sur (i, j) pour faire transiter des données de s k vers t. La quantité réelle de bande passante utilisée pour une session k K sur un lien physique (i, j) E, f k (i, j) est alors dénie par : 3.2.2 Délai f k (i, j) = max t T k f k t (i, j) (3.2) A nouveau, pour chaque session k K et chaque destination t T k, on dénit une fonction d k t : V N tel que d k t (i) représente le délai maximum pour qu'un message à destination du n ud destination t T k atteigne le n ud i en partant de la source s k. Le calcul des d k t (i) utilise la valeur de bande passante consommée sur les liens et est déni par 3.3. 0 si i = s k k K, t T k, i V : d k t (i) = max (d k p t (j) + k j Ng(i) ft kij + d ji) si i s k (3.3) ft k(j,i)>0 22

Le délai d k t (i) prend en compte l'ensemble des voisins du n ud i (j Ng(i)) tels que le lien (j, i) soit utilisé par la session k pour la cible t (fk t (j, i) > 0). Remarque : Le délai calculé est une borne supérieure du délai réel, ce qui, dans certains cas, pourra entraîner le refus biaisé d'une requête et donc empêchera la résolution optimale du problème. 3.2.3 Charge des routeurs Pour chaque n ud i V et chaque session k K, on associe une variable c k (i) N dénissant les ressources de commutation utilisées par la session k sur le n ud i. Le calcul de la charge, sous l'hypothèse dénie en 2.5.2 correspond donc au nombre d'entrées eectives dans le routeur et est donné par l'équation suivante : { k K, i V : c k (i) = j j Ng(i), f k (j, i) > 0} (3.4) 3.3 Contraintes 3.3.1 Conservation du ot et respect de la demande en bande passante Comme dans un problème de Multi-Commodity Flow standard, on impose une contrainte sur le ux dans chaque n ud du réseau physique, spéciant que la quantité de données entrantes est égale à la quantité de données sortantes (à l'exception des n uds source et destinations). b k si i = s k k K, t T k, i V : (ft k (i, j) ft k (j, i)) = b k si i = t j Ng(i) 0 sinon (3.5) 3.3.2 Respect de la contrainte de capacité des liens physiques Pour s'assurer que la capacité en bande passante de chaque lien physique est respectée, on pose la contrainte suivante : (i, j) E : k K f k (i, j) c ij c ij (3.6) Remarque : Cette contrainte n'est plus valable si certains liens du réseau physique ne sont plus en mode full-duplex. 3.3.3 Respect de la contrainte de bande passante minimale Pour s'assurer que si une partie du ux ft k, associé à la cible t d'une session k est alloué sur le lien e, alors la quantité allouée est au moins b min k, on ajoute la contrainte suivante : 23

k K, t T k, e E : f k t (e) 0 f k t (e) b min k (3.7) 3.3.4 Respect de la contrainte de délai des sessions Le respect de la contrainte de délai pour une session k est dénie par 3.8. k K, t T k : d k t (t) d k (3.8) 3.4 Fonction(s) objective(s) Lors de la résolution du problème de virtualisation considéré, nous allons chercher à la fois à équilibrer la charge du réseau physique mais aussi à limiter l'utilisation des ressources du réseau physique. 3.4.1 Équilibre des charges La première fonction objective considérée cherche à équilibrer la charge du réseau physique exprimée en termes de charge au niveau des routeurs et des liens. Pour exprimer cet objectif d'équilibrage de charge, deux versions de cette fonction objective sont proposées : une basée sur la minimisation de la somme des carrés (3.9), l'autre sur la minimisation du maximum (3.10). Chacune de ces versions est décomposée en deux parties : la première représente la charge des liens (pondérée par le coecient α) et la seconde représente la charge des routeurs (pondérée par le coecient β). minimiser α e E 1 c e ( c e + k K f k (e) ) 2 +β i V 1 u i ( u i + k K c k (i) ) 2 (3.9) minimiser α max e E { 1 c e ( c e + k K f k (e) )} +β max i V { 1 u i ( u i k K c k (i) )} (3.10) La deuxième version proposée (3.10) à l'avantage d'être facilement linéarisable, mais perd très vite de son intérêt lorsqu'un des composants du réseau physique devient surchargé (le max vaut alors 1 et il n'y a plus de recherche d'équilibre). 3.4.2 Minimisation du nombre de routeurs utilisés Le deuxième fonction objective considérée cherche à minimiser le nombre de routeurs utilisés, dans l'optique de réduire la consommation d'énergie. minimiser { i i V, ) (c k (i) + u i > 0} k K (3.11) 24

3.5 Variation sur le calcul de la fonction objective Les valeurs principales utilisées par la fonction objective sont les f k (i) et c k (i). Pour chacun des 2 types de valeurs, on peut considérer 3 variations au niveau des fonctions objectives : 1. Ne prendre en compte que les ressources utilisées par la requête actuelle pour chaque élément. 2. Prendre en compte les ressources utilisées par la requête ainsi que les ressources déjà consommées sur chaque élément, mais ne pas compter les éléments sur lesquels aucune ressource n'est consommée par la requête actuelle. 3. Prendre en compte tous les éléments, ainsi que les ressources déjà utilisées, même si aucune ressource n'est consommée par la requête actuelle sur l'élément. Dans le cas 1, il sut de poser c e = 0 et u i = 0 pour tout e E et i V. Le cas 3 est celui présenté dans ce document. Le cas 2 s'obtient en remplaçant les ensembles d'itérations des sommes et maximums de la façon suivante : { E = e E, } f k (e) > 0 k K { } et V = i V, c k (i) > 0 k K 3.6 Apport du modèle par rapport à l'existant Le modèle présenté ici permet l'allocation de ressources pour des liens virtuels sur un réseau physique. Bien qu'il existe déjà plusieurs modèles pour ce problème (voir chapitre 2), la particularité de celui-ci réside dans : La possibilité d'allouer des liens de type point à point ou point à multipoint (multicast). La prise en compte de contraintes QoS de type bande passante et délai au niveau des liens virtuels. La prise en compte au niveau des routeurs de la charge liée à la commutation des paquets. 25

Chapitre 4 Modèle linéaire Le modèle proposé au chapitre précédent n'est pas linéaire, son ecacité pratique est ainsi limitée. Dans ce chapitre, nous allons présenter une linéarisation possible. La linéarisation consiste à ramener chaque contrainte c du problème (ainsi que la fonction objective) sous une forme linéaire du type a c,1 x 1 +a c,2 x 2 +...+a c,n x n b c, avec x 1 0,..., x n 0 les variables du problème (ft k par exemple dans notre modèle). Le modèle peut alors être écrit sous la forme : { minimiser C X AX B Avec X = (x 0,..., x n ), C un vecteur de taille n (nombre de variables), B un vecteur de taille m (nombre de contraintes) et A une matrice de taille m n. An de linéariser le modèle, plusieurs variables et contraintes doivent être ajoutées, et la fonction objective doit être reformulée. 4.1 Variables An de linéariser la contrainte impliquant un max (3.2), la quantité réelle de bande passante utilisée pour une session k K sur un lien physique (i, j) E, f k (i, j), est maintenant dénie par un ensemble de contraintes (cf. 4.3). On utilisera pour cela deux nouveaux ensembles de variables, gt k (i, j) B et g k (i, j) B, indiquant la présence d'un ux sur le lien (i, j) pour la session k, à destination de t pour les premières. On ajoute la relation suivante entre g(t) k (i, j) et f (t) k (i, j) (cf. équation 4.4 pour la contrainte linéaire) : k K, (i, j) E : g k t (i, j) = 0 f k t (i, j) = 0 (4.1) k K, (i, j) E : g k (i, j) = 0 f k (i, j) = 0 (4.2) On dénit également deux variables f max et c max correspondant respectivement à la charge maximale des liens et des n uds du réseaux physiques, pour l'ensemble des ses- 26

sions de K, et qui seront utilisées dans les fonctions objectives (toujours an de linéariser les max). 4.2 Contraintes 4.2.1 Flux et bande passante Pour linéariser le max déni en 3.2, on ajoute la contrainte suivante : k K, e E, t T k : f k t (e) f k (e) (4.3) An de satisfaire la contrainte dénie en 4.1, on ajoute la contrainte linéaire suivante : k K, e E : g k (e) f k (e) et f k (e) b k g k (e) (4.4) k K, t T k, e E : g k t (e) f k t (e) et f k t (e) b k g k t (e) (4.5) An de prendre en compte la contrainte dénie en 3.7, il sut de contraindre la partie gauche de l'équation 4.5, qui devient alors : 4.2.2 Délai k K, e E : b min k g k t (e) f k t (e) et f k t (e) b k g k t (e) (4.6) On ajoute les contraintes suivantes concernant le délai de transmission des messages appartenant à une session k : k K, t T k : d k t (s k ) = 0 (4.7) k K, t T k, (i, j) E : d k t (i) + p k b min + d ij (1 gt k (i, j)) Ψ d k t (j) (4.8) k Avec Ψ un nombre assez grand pour qu'un n ud sur lequel ne transite aucune donnée à destination de t pour la session k ne soit pris en compte dans l'équation précédente. On notera ici que (i, j) E, b min k ft k p (i, j), et donc k ft k(i,j) < p k. Le délai obtenu b min k après linéarisation est donc une majoration du délai obtenu par la modélisation normale (lui même une majoration du délai réel), la contrainte de délai réel est donc toujours respectée. k K, t T k : d k t (t) d k (4.9) La contrainte 4.9 est juste une copie de 3.8, alors que 4.7 et 4.8 remplacent la contrainte 3.3. 27

4.2.3 Charge des n uds La contrainte 3.4 est remplacée en utilisant les g k (i, j) par 4.10. k K, i V : c k (i) = j V g k (j, i) (4.10) (j,i) E 4.2.4 Charges maximales Toujours pour linéariser les max utilisés dans la fonction objective 3.10, on ajoute les deux contraintes suivantes : e E : i V : ( 1 c e + ) f k (e) f max (4.11) c e k K ( 1 u i + ) c k (i) c max (4.12) u i k K 4.3 Fonction(s) objective(s) La fonction objective dénie en 3.10 devient simplement : minimiser α f max + β c max (4.13) La fonction objective dénie 3.9 est quadratique. Bien qu'elle puisse être implémentée directement dans la plupart des solveurs, elle augmente de façon exponentielle le temps de résolution du problème. À la place de cette fonction quadratique, la fonction suivante est utilisée : minimiser α 1 f max + α 2 S E + β 1 c max + β 2 S V + γ S D (4.14) Où S E, S V et S D représentent respectivement la somme des ux alloués, des capacités utilisés, des délais aux cibles et sont dénis par : S E = S V = ( 1 e E ( c ce e + k K f k (e) )) E ( 1 i V ( u ui i + k K ck (i) )) V (4.15) (4.16) S D = d k t (t) (4.17) k K t T k La fonction objective dénie en 3.11 devient quant à elle : 28

minimiser i V c k b (i) (4.18) Avec c k b (i) B, ck b (i) = (ck (i) + u i > 0) (cf. 4.4 pour la linéarisation de ce genre de contrainte). 4.4 Complexité La complexité du modèle linéaire se retrouve dans le nombre de variables et contraintes nécessaires à sa résolution. Pour un réseau composé de N routeurs et M liens, l'allocation d'une requête composée de K sessions, avec un maximum de T destinations par session nécessite : O(KT (2M + N)) variables. O(KT (4M + N)) contraintes. 29

Chapitre 5 Expérimentations 5.1 Le réseau Contrairement aux travaux existants qui expérimentent sur des réseaux générés aléatoirement, le choix a été fait d'utiliser une topologie réelle de réseau an de se rapprocher des scénarios possibles pour un fournisseur de réseaux virtuels (de liens virtuels dans notre cas). Comme la plupart des réseaux de fournisseurs ne sont pas publiques, le réseau utilisé pour les expérimentations est le réseau européen de recherche, GÉANT, qui possèdent des liens reliant la plupart des capitales et villes importantes européennes. La version considérée du réseau est celle de Janvier 2014, contenant : 41 Routeurs 60 Liens Figure 5.1 Carte de GÉANT - Version Janvier 2014 [4] 5.1.1 Capacité des liens Les capacités des liens sont fournies par la carte. Pour les liens n'ayant pas une capacité précise, les règles suivantes sont utilisées : 1 Gbps, < 10 Gbps : La capacité du lien est xée à 5 Gbps. 100 Gbps : La capacité du lien est ramenée à 100 Gbps. 30

5.1.2 Les délais de transmission des liens La carte ne fournit pas directement les délais de transmissions des liens, mais ceux-ci sont calculables en utilisant la localisation des routeurs. Les liens sont considérés en ligne droite d'un routeur à l'autre, et la vitesse de transmission v tr est xée à 3.10 8 m/s. La distance terrestre D(a, b) entre deux routeurs est calculée à partir de leurs longitudes et latitudes, le délai de propagation du routeur a vers le routeur b, tr(a, b), est alors obtenu simplement par : tr(a, b) = D(a, b) v tr (5.1) 5.1.3 La capacité des routeurs La capacité de commutation des routeurs, exprimées en nombre d'entrées disponibles dans la table des ots, est xée à 2000 entrées. Dans la réalité, la taille maximale de la table des ots varie en fonction de la capacité des routeurs et de la complexité des opérations de recherche sur les entrées (quelques milliers d'entrées pour des recherches impliquant plusieurs champs d'un paquet jusqu'à plusieurs dizaines de milliers pour des recherches n'impliquant qu'un seul champ d'un paquet). De plus, on considère ici que seule une partie de ces entrées sont utilisées pour le routage virtuel, le reste étant utilisé pour du routage classique. 5.2 Les requêtes 5.2.1 Le taux d'arrivée Les requêtes arrivent selon un processus de Poisson de paramètre λ, avec λ variant de 4 à 10 requêtes toutes les 100 unités de temps par pas de 1 : λ {0.04, 0.05, 0.06, 0.07, 0.08, 0.09, 1.0}. 5.2.2 La durée de vie Les requêtes possèdent une durée de vie moyenne de 1000 unités de temps suivant une loi exponentielle de paramètre µ = 1/1000. 5.2.3 Les diérents types de requêtes Deux types de requêtes ont été considérés pour les expérimentations : Unicast et Multicast. Les requêtes Unicast Les requêtes unicast contiennent un seul lien virtuel, soit une session avec une seule destination. Les paramètres du lien virtuel sont générés aléatoirement selon des lois uniformes, avec les contraintes suivantes : Bande passante Entre 7 et 12 Gbps. 31

Délai Entre 50 et 80 millisecondes. Ce type de requêtes peut être envisagé dans le cas de gure d'un fournisseur de réseaux virtuels fournissant des services à d'autres fournisseurs ou opérateurs. Les requêtes Multicast Les requêtes multicast contiennent plusieurs liens virtuels point à multipoint : Entre 4 et 6 liens virtuels, chacun possédant entre 4 et 6 destinations. Les paramètres de chaque lien virtuel sont générés aléatoirement selon des lois uniformes, avec les contraintes suivantes : Bande passante Entre 200 Mbps et 3 Gbps. Délai Entre 50 et 80 millisecondes. Remarque : Pour qu'une requête contenant plusieurs liens virtuels soit acceptée par le modèle, il faut que tous ses liens puissent être alloués sur le réseau, i.e. s'il n'existe pas de chemin de capacité susante reliant la source et les destinations d'un lien, la requête entière est rejetée. 5.2.4 Le path-splitting Les expérimentations ont été eectuées avec utilisation du path-splitting (P S ratio {10%, 33%, 45%}) et sans (P S ratio = 100%). Un lien virtuel avec un P S ratio de 10% (resp. 33% et 45%) ne pourra être allouée sur plus de 10 (resp. 3 et 2) chemins diérents, caque chemin étant utilisé pour 10% (resp. 33% et 45% de la bande passante). Avec un P S ratio > 50% (100% dans notre cas), le lien doit être alloué sur un seul chemin physique. 5.2.5 Le choix des sources et destinations An d'éviter de tomber trop souvent sur des routeurs isolés (Chypre, Bulgarie, Ukraine, par exemple), les routeurs sources et destinations des liens sont choisis suivant une probabilité proportionnelle à la somme des capacités des liens auxquels ils sont connectés, soit : p i (i,j) E 5.3 Les paramètres d'expérimentation 5.3.1 La durée d'expérimentation Les expérimentations ont toutes été eectuées sur une durée de 10000 unités de temps. La courbe 6.3 montre que cette durée est susante pour atteindre un état stationnaire du système. c ij 32

5.3.2 La fonction objective La fonction objective utilisée est celle dénie en 4.14, avec la variation numéro 3 (variation utilisée dans la présentation du modèle). Les paramètres α, β et γ Les coecients α 1 et α 2 ont été fusionnés et xés à la valeur 1 : α 1 = α 2 = α = 1. Les coecients β 1 et β 2 ont également été fusionnés. 4 valeurs diérentes ont été utilisées pour les expérimentations : β 1 = β 2 = β {1, 50, 100, 150}. La minimisation des délais n'étant pas recherchée dans les expérimentations, le coecient γ a été xé à la valeur 0. 5.4 Fonctionnement des expérimentations On considérera dans la suite des instances de test : une instance est un ensemble de requêtes, générées sur une durée xe (10000 unités de temps dans notre cas) avec un taux d'arrivée et des paramètres dénis. Pour chaque type de requête (unicast et multicast), et chaque taux d'arrivée (de 4 à 10 requêtes toutes les 100 unités de temps), deux instances ont été générées avec des paramètres β et P S ratio xés, soit un total de 2 2 7 = 28 instances. Chaque instance générée a ensuite été rejouée en faisant varier les paramètres β et P S ratio, portant le total d'instance à 28 16 = 448. Chaque instance peut alors être caractérisée ainsi : (T ype, λ, β, P S ratio ) 5.5 Métriques utilisées Les performances de l'algorithme ont été mesurées à l'aide de plusieurs métriques : le taux d'acceptation des requêtes, les revenus générés, le taux d'utilisation des liens et la charge globale des liens. Les métriques ont été mesurées : À la n de la simulation (à T = 10000 unités de temps), les graphes sont alors fournis en fonction du taux d'arrivée des requêtes λ. Sur toute la période de simulation d'une expérience liée à une instance (T ype, λ, β, P S ratio ), les graphes sont alors fournis en fonction du temps de simulation T (en unité de temps). 5.5.1 Le taux d'acceptation des requêtes Le taux d'acceptation des requêtes correspond simplement au nombre de requêtes qui ont été allouées sur le réseau, par rapport au nombre total de requêtes générées 33

pendant la durée d'une simulation (ou une partie de cette durée dans le cas d'étude sur la période de simulation). τ acceptation = Nombre de requêtes allouées Nombre de requêtes reçues Exemple : Si une instance contient 400 requêtes, et que 260 requêtes ont été allouées avec succès, alors le taux d'acceptation est de τ = 260 400 = 65%. 5.5.2 Les revenus générés On considère que chaque requête génère des revenus pour le fournisseur de réseau virtuel si son allocation sur le réseau réussi. Le revenu généré par une requête est calculé par la formule ci-dessous : µ(r) ( bk ) T k si R a été allouée Revenu(R) = k K 0 si R n'a pas pu être allouée Avec µ(r) la durée de vie de la requête (en unités de temps), K le nombre de sessions de la requête et b k et T k la bande passante demandée (en Mbps) et le nombre de destinations de la session k. On utilise T k au lieu de T k directement an de se rapprocher des revenus réels : du point de vue du consommateur, un lien multicast vers N destinations est moins polyvalent que N liens unicast, leurs coûts ne peuvent donc pas être identique. Exemple : Une requête durant 800 unités de temps composée d'une session avec 3 destinations pour une bande passante de 400Mbps, et une session avec 2 destinations pour une bande passante de 1Gbps, aura un revenu de : Revenu(R) = 800 (400 3 + 1000 2) = 800 (693 + 1414) = 1, 685.10 6 Le revenu global de la simulation est alors calculé comme la somme du revenu de toutes les requêtes allouées. Revenu(Simulation) = Revenu(R) 5.5.3 La charge globale des liens du réseau La charge globale du réseau correspond à la quantité totale de ressources consommées sur les liens (à un instant donné) par rapport à la capacité totale des liens, soit : C liens = c e e E c e e E Remarque : Comme on considère des liens full-duplex, il est important de noter que l'ensemble E des liens contient, pour chaque lien de GÉANT, deux liens : Un de i 34

vers j et un de j vers i. Lors du calcul de la charge globale des liens du réseaux, chaque lien de GÉANT est donc considéré deux fois, i.e. pour que la charge soit de 100%, il faudrait que chaque lien utilise la totalité de ses ressources dans les deux sens. 5.5.4 Le taux d'utilisation des liens Le taux d'utilisation des liens correspond à la moyenne du taux d'utilisation de chaque lien (à un instant donné), c'est à dire les ressources consommées sur le lien par rapport aux ressources disponibles, soit : τ liens = 1 E c e c e e E Avec c e la capacité du lien e et c e les ressources consommées sur le lien e à l'instant considéré. Comme e E, c e c e, τ liens [0, 1]. Remarque : Tout comme pour la charge globale des liens du réseau, il est important de noter que pour atteindre un taux d'utilisation de 100%, il faudrait que chaque lien utilise 100% de ses ressources dans les deux sens. Tous les liens n'ont pas la même capacité donc τ liens C liens. Contrairement à la charge du réseau, le taux d'utilisation des liens ne fait pas la diérence entre un lien de capacité 50 Gbps chargé à 80% et un lien de capacité 4 Gbps chargé à 80%. La charge globale des liens du réseau et le taux d'utilisation peuvent être utilisés comme indicateur de l'équilibre du réseau. Les résultats concernant la charge sont étudiés dans la section 6.4.3, et des fonctions de répartition du taux d'utilisation des liens en n de simulation sont fournies dans la section 6.5. 5.6 Implémentations 5.6.1 Paramètres du solveur Le modèle a été implémenté en C++ en utilisant le solveur de Programmation Linéaire en Nombres Entiers CPLEX 1. Deux paramètres de contrôles du solveur ont été utilisés : Une limite de 15 secondes a été utilisée pour le temps de résolution (allocation d'une requête sur le réseau). Un gap de 5% a été utilisé, i.e. le solveur ne cherchera pas une solution optimale mais pourra se contenter d'une solution qui se trouve à moins de 5% de la borne inférieure de la solution optimale. 5.6.2 Implémentation C++ Le programme a été conçu de manière modulaire an de pouvoir facilement ajouter de nouvelles méthodes résolutions. Les heuristiques présentées dans la partie analyse et 1. http ://www-01.ibm.com/software/commerce/optimization/cplex-optimizer/ 35

résultats ont été implémentées dans le même projet que le modèle PLNE mais ne font pas usage de CPLEX. Le logiciel développé permet la génération de chier de résultats au format binaire contenant toutes les informations de la simulation (réseau utilisé, requêtes entrantes, requêtes allouées, temps de calculs, etc.). Des chiers au format.dot (graphviz 2 ) peuvent également être générés, bien que leur interprétation soit impossible pour les simulations présentées ici. Un exemple de graphe généré est visible sur la gure 5.2. Figure 5.2 Fichier graphique de résultat construit en utilisant le logiciel dot sur un chier généré par le programme - Réseau GÉANT. Les chiers au format binaire peuvent être rejoués par le programme en changeant certains paramètres (α, β, P Sratio, la limite de temps de CPLEX, le gap de CPLEX, etc.). Cette fonctionnalité permet de rejouer une simulation et ainsi obtenir un second chier de résultat contenant exactement les mêmes requêtes que celui fournit en entrée, mais avec des paramètres de résolution di érents. 5.6.3 Les scripts d'analyse des résultats Un ensemble de scripts Python (version 2.7) ont été créés a n de pouvoir facilement visualiser et analyser le contenu des chiers binaires. Ces scripts permettent, entre autres, de : Rejouer l'allocation des requêtes pas à pas, a n de comprendre pourquoi certaines 2. http ://www.graphviz.org/ 36

requêtes ont été refusées, mais également visualiser la façon dont le programme eectue l'allocation (utilisation des liens, path-splitting, etc.). Générer des chiers au format CSV (Comma-Separated Values) pouvant être importés dans un tableur. Les chiers générés peuvent contenir les résultats de diérentes instances, ce qui permet de rapidement obtenir des graphiques exploitables pour l'analyse. Créer des chier LATEX contenant des graphiques au format pgfplots 3. Les courbes disponibles dans le chapitre 6 ont toutes été générées à partir de ces scripts. 3. http://pgfplots.sourceforge.net/ 37

Chapitre 6 Résultats et Analyses Les résultats présentés dans cette partie ont tous été obtenus via le simulateur développé en C++ dans le cadre de ce travail. L'ensemble des chiers de résultats obtenus ainsi que les scripts décrits à la n du chapitre précédent sont disponibles sur simple demande 1. Les objectifs de ces diérentes analyses sont : 1. La mise en évidence de l'apport (taux d'acceptation et revenus) du modèle par rapport à des méthodes heuristiques. 2. La caractérisation des temps de calcul en fonction du taux d'arrivée des requêtes, de leurs types (unicast / multicast) et de l'utilisation du path-splitting. 3. La validation de la durée de simulation - L'atteinte d'un régime stationnaire pour T = 10000 unités de temps. 4. L'inuence des paramètres sur les résultats du modèle (à nouveau en terme de taux d'acceptation et de revenus). 5. La visualisation de l'équilibre des charges dans le réseau via l'utilisation d'une fonction de répartition sur le taux d'utilisation des liens. Les résultats et analyses mettent en avant de fortes diérences entre les requêtes de type unicast et multicast qui sont discutées dans la dernière section de ce chapitre. 6.1 Comparaison avec des méthodes heuristiques La méthode présentée dans ce document a été comparée à diérentes heuristiques de Plus Court Chemin (PCC). En eet, les algorithmes PCC sont couramment utilisés pour le routage de paquets dans les réseaux actuels, et peuvent donc s'adapter facilement pour de l'allocation de liens virtuels. Pour une requête unicast, l'algorithme de PCC utilisé est standard (avec les coûts dénis ci-dessous). Pour une requête multicast, la procédure adoptée est la suivante : 1. L'allocation des liens virtuels se fait les uns à la suite des autres. La requête est rejetée si, pour un des liens, le chemin trouvé ne possède pas une capacité susante. 1. Pour obtenir les chiers de résultat et les scripts, envoyer un mail à capelle.mikael@gmail.com 38

2. Pour les liens multicast, chaque chemin (source, destination) est calculé par l'algorithme PCC de façon isolée. L'allocation nale du lien est ensuite calculée par le max sur chaque lien physique des capacités allouées aux liens logiques (procédure semblable à celle utilisée par notre modèle). Trois versions du calcul du coût d'un lien ont été considérées : Coût = 1 Chaque lien possède un coût de 1, cela revient à chercher le chemin passant par le moins de routeurs possibles. Coût = f(c e ) Le coût d'un chemin est inversement proportionnel à sa capacité (Coût = 1/c e ). C'est le calcul de coût utilisé dans le protocole OSPF. Coût = g(c e, c e ) Le coût d'un chemin est inversement proportionnel aux ressources disponibles sur le lien (Coût = 1 c e c e ). Les graphiques de la gure 6.1 présentent les résultats de comparaison de la méthode PLNE étudiée avec les algorithmes précédemment décrits. Les paramètres β = 150 et P S ratio = 10 ont été choisis suite aux résultats comparatifs présentées dans la partie 6.4. Les courbes montrent que quelque soit le type d'instance considérée, la méthode de PLNE présente un apport notable en terme de taux d'acceptation et surtout de revenu. L'augmentation est plus importante sur des instances de type multicast (2% pour des taux d'arrivée élevé jusqu'à 10% pour un taux d'arrivée de 0.04) que sur des instances de type unicast (entre 3 et 4%). L'apport de la méthode est d'autant plus visible sur les revenus : Jusqu'à 300 Tb pour les instances de type unicast et 600 Tb pour celles de type multicast par rapport à la meilleure des heuristiques. 6.2 Caractérisation des temps de calcul Les courbes 6.2a et 6.2b indiquent le temps moyen et maximal d'allocation des requêtes sur le réseau. Les valeurs fournies sont calculées sur l'ensemble des requêtes acceptées en utilisant les temps CPUs retournés par le solveur CPLEX 2. Sur les instances de type unicast, les temps de calculs sont en moyenne faibles (inférieurs à 40 millisecondes sans path-splitting, et à 100 ms avec path-splitting) et ne dépassent jamais 700 millisecondes (la limite de 15 secondes xées pour le solveur n'est jamais atteinte). Pour les instances de type multicast, les temps de calcul sont plus élevés (entre une et quatre secondes en moyenne) et la limite du solveur est atteinte (les maximums dépassent les 15 secondes pour tous les taux d'arrivée). Cette diérence s'explique facilement lorsque l'on compare le nombres de variables et contraintes nécessaires pour la modélisation des requêtes de type multicast et unicast (voir 4.4). Quelque soit le type d'instance considéré, l'utilisation du path-splitting augmente de façon notable le temps de calcul, bien que celui-ci reste largement acceptable dans un concept de fournisseur de réseaux virtuels (les temps de calcul restent négligeables en comparaison des temps de déploiement qui peuvent atteindre plusieurs minutes). L'inuence du path-splitting sur le temps de calcul est directement liée à l'espace de recherche des variables de ux ft k - Dans un scénario sans path-splitting, elles sont 2. http://pic.dhe.ibm.com/infocenter/cosinfoc/v12r4/index.jsp?topic=%2filog.odms.ide. help%2frefcppopl%2fhtml%2fclasses%2filotimer.html 39

Taux d'acceptation des requêtes 100 % 95 % 90 % 85 % 80 % 75 % 70 % 65 % 60 % β = 150, P S ratio = 10% PCC, Coût = g(c e, c e ) PCC, Coût = f(c e ) PCC, Coût = 1 Revenu (Mb) 6.5 6 5.5 5 4.5 4 3.5 3 10 9 β = 150, P S ratio = 10% PCC, Coût = g(c e, c e ) PCC, Coût = f(c e ) PCC, Coût = 1 4 5 6 7 8 9 10 Taux d'arrivée des requêtes 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) Requêtes de type Unicast (b) Requêtes de type Unicast Taux d'acceptation des requêtes 80 % 70 % 60 % 50 % 40 % 30 % 20 % 10 % β = 150, P S ratio = 10% PCC, Coût = g(c e, c e ) PCC, Coût = f(c e ) PCC, Coût = 1 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Revenu (Mb) 6 5 4 3 2 1 0 10 9 β = 150, P S ratio = 10% PCC, Coût = g(c e, c e ) PCC, Coût = f(c e ) PCC, Coût = 1 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (c) Requêtes de type Multicast (d) Requêtes de type Multicast Figure 6.1 Comparaison de diérents algorithmes d'allocation limitées à deux valeurs possibles (0 ou b k ), ce qui n'est plus le cas à partir du moment où on utilise un P S ratio inférieur à 50%. 6.3 Validation de la durée de simulation Les courbes de la gure 6.3 montrent l'évolution du taux d'acceptation et du taux d'utilisation des liens du réseau au cours de la simulation. À la n de la simulation (T = 10000 unités de temps), le système a atteint un régime stationnaire. Ce résultat nous permet de cibler les analyses suivantes en regardant uniquement les valeurs en n de simulation. Sur les courbes 6.3a et 6.3b, on remarque que les instances composées de requêtes 40

20 Temps de calcul (secondes) 0.6 0.4 0.2 0 Pas de path splitting Path splitting, P S ratio = 10% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Temps de calcul (secondes) 15 10 5 0 Pas de path splitting Path splitting, P S ratio = 10% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) Requêtes de type unicast (b) Requêtes de type multicast Figure 6.2 Temps de calcul en fonction du taux d'arrivée pour des requêtes de type unicast et multicast, β = 100 de type multicast se stabilisent beaucoup plus vite (vers T = 2000 unités de temps) que les requêtes de type unicast. La chute brutale du taux d'acceptation observée sur ces courbes s'explique par l'augmentation brutale et la stabilisation du taux d'utilisation des liens, visible sur les graphiques 6.3c et 6.3d. Contrairement aux instances composées de requêtes de type unicast (graphiques 6.3c), les instances composées de requêtes de type multicast atteignent toutes le même taux d'utilisation des liens, quelque soit leur taux d'arrivée. Même pour des taux d'arrivée faibles (λ = 0.04), le réseau semble saturer rapidement, ainsi le nombre maximal de requêtes pouvant être allouées en même temps sur le réseau est très vite atteint. 6.4 Inuence des paramètres du modèle Dans cette section, nous allons étudier l'inuence respective des paramètres P S ratio et β (prise en compte de la charge des routeurs) de notre modèle. 6.4.1 Taux d'acceptation des requêtes Les courbes 6.4a à 6.4d et 6.5a à 6.5d présentent les taux d'acceptation des requêtes pour diérentes instances de type unicast et multicast. Requêtes de type unicast Sur les graphiques 6.4a à 6.4d, le path-splitting montre un intérêt (de 2 à 3% de gain en fonction du taux d'arrivée) quelques soient les instances considérées. Les instances possédant un ratio de 10% montrent la plupart du temps de meilleurs résultats que les autres. En revanche, sur ces mêmes graphiques, le paramètre β ne semble avoir quasiment 41

Taux d'acceptation 100 % 95 % 90 % 85 % 80 % λ = 0.04 λ = 0.05 λ = 0.06 λ = 0.07 λ = 0.08 λ = 0.09 λ = 0.10 Taux d'acceptation 100 % 90 % 80 % 70 % 60 % 50 % 40 % λ = 0.04 λ = 0.05 λ = 0.06 λ = 0.07 λ = 0.08 λ = 0.09 λ = 0.10 0 2 000 4 000 6 000 8 000 10 000 Temps (a) Taux d'utilisation des liens - Requêtes Unicast 0 2 000 4 000 6 000 8 000 10 000 Temps (b) Taux d'utilisation des liens - Requêtes Multicast Taux d'utilisation des liens 0.4 0.3 0.2 0.1 0 λ = 0.04 λ = 0.06 λ = 0.07 λ = 0.10 Taux d'utilisation des liens 0.4 0.3 0.2 0.1 0 λ = 0.04 λ = 0.06 λ = 0.07 λ = 0.10 0 2 000 4 000 6 000 8 000 10 000 Temps 0 2 000 4 000 6 000 8 000 10 000 Temps (c) Taux d'acceptation - Requêtes Unicast (d) Taux d'acceptation - Requêtes Multicast Figure 6.3 Taux d'acceptation et d'utilisation des liens en fonction du temps pour des requêtes Multicast et Unicast - β = 150, P S ratio = 0.45 aucun impact sur les résultats, puisque toutes les courbes de la gure 6.4 indiquent des taux d'acceptation semblables. Requêtes de type multicast Contrairement aux instances de type unicast, le path-splitting ne montre pas toujours un intérêt constant pour les instances de type multicast. Pour des taux d'arrivées faibles (λ 6), ne pas utiliser le path-splitting semble le plus intéressant, alors que pour des taux supérieurs à 7 requêtes toutes les 100 unités de temps, l'utilisation du path-splitting avec un ratio de 10 ou 33% semble la meilleure solution. Tout comme pour les instances de type unicast, le paramètre β ne semble pas avoir d'inuence sur les résultats des simulations. 42

Taux d'acceptation des requêtes 100 % 95 % 90 % 85 % 80 % 75 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Taux d'acceptation des requêtes 100 % 95 % 90 % 85 % 80 % 75 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) β = 1 (b) β = 50 Taux d'acceptation des requêtes 100 % 95 % 90 % 85 % 80 % 75 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Taux d'acceptation des requêtes 100 % 95 % 90 % 85 % 80 % 75 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (c) β = 100 (d) β = 150 Figure 6.4 Taux d'acceptation des requêtes de type unicast en fonction de leur taux d'arrivée et des paramètres de simulation. De manière générale, pour les instances de type multicast, les diérences de taux d'acceptation sont plus faibles (1 à 2%) que pour les instances de type unicast (2 à 3%). Ceci s'explique par la quantité plus importante de bande passante demandée par les requêtes de type unicast ( 7Gbps). Il est plus probable que l'utilisation du pathsplitting soit nécessaire pour un lien virtuel de grande capacité que pour un de faible capacité. 6.4.2 Revenus totaux des simulations Les gures 6.6 et 6.7 présentent les courbes de revenu des simulations. Le revenu est exprimé en Mb en supposant qu'une unité de temps soit égale à une seconde (pour des questions de simplicité dans les comparaisons). Dans la réalité, une unité de temps serait en général assimilée à plusieurs secondes (dans le cas d'un fournisseur de réseau, on peut 43

Taux d'acceptation des requêtes 80 % 70 % 60 % 50 % 40 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% Taux d'acceptation des requêtes 80 % 70 % 60 % 50 % 40 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) β = 1 (b) β = 50 Taux d'acceptation des requêtes 80 % 70 % 60 % 50 % 40 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Taux d'acceptation des requêtes 80 % 70 % 60 % 50 % 40 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (c) β = 100 (d) β = 150 Figure 6.5 Taux d'acceptation des requêtes de type multicast en fonction de leur taux d'arrivée et des paramètres de simulation. supposer que les requêtes de réseau arrive à des taux inférieur à 1 requêtes toutes les 25 secondes, puisque le temps de déploiement est supérieur à la dizaine de minutes), ce qui impliquerait des diérences entre les courbes plus importantes (deux fois plus importantes si une unité de temps correspondait à deux secondes, etc.). Requêtes de type unicast Les courbes 6.6a à 6.6d montrent le revenu totale de diérentes instances en fonction du taux d'arrivée de celles-ci. Elles conrment les résultats obtenus par les courbes montrant le taux d'acceptation : les instances utilisant le path-splitting montrent un revenu plus élevé que celles ne l'utilisant pas. La diérence de revenu est d'autant plus importante que le taux d'arrivée des requêtes est élevé (sauf pour β = 100) : de 60 Tb pour λ = 0.04 à 200 Tb pour λ = 0.1. 44

10 9 7 10 9 Revenu (Mb) 6 5 4 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% Revenu (Mb) 6 5 4 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) β = 1 (b) β = 50 10 9 7 10 9 Revenu (Mb) 6 5 4 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% Revenu (Mb) 6 5 4 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (c) β = 100 (d) β = 150 Figure 6.6 Revenu totale de simulation pour des requêtes de type unicast en fonction de leur taux d'arrivée et des paramètres de simulation. Comme pour le taux d'acceptation, l'inuence du paramètre β sur les revenus des simulations semble faible. Requêtes de type multicast Les courbes de revenus des instances de type multicast (6.7a à 6.7d) sont beaucoup moins régulières que les courbes des instances de type unicast. Pour des taux d'arrivée faibles (λ 0.06), les meilleurs instances sont celles n'utilisant pas le path-splitting avec β = 1, pour des taux élevés (λ 0.08), les plus hauts revenus sont en général obtenus avec path-splitting. Malgré leurs irrégularités, les courbes de revenus de la gure 6.7, comme celles de 45

6.2 10 9 6.2 10 9 Revenu (Mb) 6 5.8 5.6 5.4 5.2 5 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Revenu (Mb) 6 5.8 5.6 5.4 5.2 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) β = 1 (b) β = 50 6.2 6 10 9 6.2 109 6 Revenu (Mb) 5.8 5.6 5.4 5.2 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes Revenu (Mb) 5.8 5.6 5.4 5.2 Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (c) β = 100 (d) β = 150 Figure 6.7 Revenu totale de simulation pour des requêtes de type multicast en fonction de leur taux d'arrivée et des paramètres de simulation. la gure 6.6, montrent que même si les variations du taux d'acceptation sont faibles, la diérence dans les revenus générés est conséquente. 6.4.3 Charge du réseau On ne considérera ici que des instances avec β = 150, les analyses précédentes ayant montré la faible inuence de ce paramètre sur les résultats du modèle. Les courbes 6.8a et 6.8b montrent la charge globale des liens du réseau (voir 5.5.3). Pour les instances de type unicast (graphique 6.8a), la charge du réseau dépend très peu des paramètres d'expérimentation, ce qui signie qu'un meilleur taux d'acceptation des requêtes et de meilleurs revenus n'impliquent pas une surcharge notable du réseau. 46

45 % Charge du réseau 40 % 35 % 30 % 25 % 20 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (a) Requêtes de type unicast ' Charge du réseau 42 % 40 % 38 % 36 % Pas de path splitting Path splitting, ratio 10% Path splitting, ratio 33% Path splitting, ratio 45% 4 5 6 7 8 9 10 Taux d'arrivée des requêtes (b) Requêtes de type multicast Figure 6.8 Charge du réseau en fonction du taux d'arrivée pour des requêtes de type unicast et multicast - β = 150 Tout comme leurs courbes de revenus, les courbes des instances de type multicast 6.8b sont beaucoup moins régulières que celles des instances de type unicast. Pour un même type d'instance (caractérisé par β et P S ratio ), les courbes ne sont pas du tout linéaires en fonction du taux d'arrivée des requêtes. Les diérences entre les courbes des instances de type unicast et multicast, principalement au niveau des irrégularités, peuvent s'expliquer par une dépendance aux requêtes (nombre de liens, source, destination(s), etc.) beaucoup plus forte du côté des instances multicast. 6.5 Visualisation de l'équilibre de l'utilisation des liens dans le réseau La gure 6.9 présente les fonctions de répartition du taux d'utilisation des liens du réseau (à la n de la simulation, soit pour T = 10000 unités de temps) pour les instances de type unicast (6.9a) et multicast (6.9b) pour diérents taux d'arrivée. Comme sur le graphique 6.3d, on remarque que la fonction de répartition du taux d'utilisation pour des instances de type multicast varie peu en fonction du taux d'arrivée des requêtes (les courbes sont très proches sur le graphiques 6.9b). Quelque soit le taux d'arrivée des requêtes, environ 60% des liens sont utilisés à plus de 50% de leur capacité. Le graphique 6.9a conrme les résultats des courbes 6.3c : le taux d'utilisation des liens du réseau augmente avec l'augmentation du taux d'arrivée des requêtes. Pour de faibles taux d'arrivées (λ 0.05), moins de 20% des liens sont utilisés à plus de 50%, ce pourcentage atteint 50% pour un taux d'arrivée de 10 requêtes toutes les 100 unités de temps. Quelque soit le taux d'arrivée, on remarque qu'au moins 20% des liens sont utilisés à plus de 80% de leurs capacités pour des instances de type unicast (60% pour celles de 47

1 1 0.8 0.8 0.6 0.4 λ = 0.04 λ = 0.05 λ = 0.06 λ = 0.07 λ = 0.08 λ = 0.09 λ = 0.10 0.6 0.4 0.2 λ = 0.04 λ = 0.05 λ = 0.06 λ = 0.07 λ = 0.08 λ = 0.09 λ = 0.10 0 0.2 0.4 0.6 0.8 1 Taux d'utilisation (a) Requêtes de type unicast 0 0.2 0.4 0.6 0.8 1 Taux d'utilisation (b) Requêtes de type multicast Figure 6.9 Fonction de répartition du taux d'utilisation des liens pour des requêtes unicast et multicast - β = 150, P S ratio = 10% type multicast). 6.6 Analyse du taux d'acceptation des instances de type unicast et multicast Il est important de noter que les seules requêtes de type unicast refusées par le modèle sont celles reliant deux points critiques du réseau (liens surchargés ou de faibles capacités). En supposant que le modèle essaie toutes les solutions possibles (ce qui semble être le cas puisque les temps limites de calcul fournit au solveur ne sont jamais atteints, voir 6.2a), le refus d'une requête de type unicast reliant un routeur a à un routeur b implique qu'il n'existe aucun lien de capacité susante entre a et b. En revanche, une requête contenant plusieurs liens de type multicast peut être refusée à partir du moment où un seul de ses liens ne peut être alloué sur le réseau (une seule destination non atteignable). Dans les simulations eectuées, une requête de type multicast contient en moyenne 5 liens virtuels, chacun contenant en moyenne 5 destinations distinctes (ainsi qu'une source), soit 25 destinations pour un total de 30 routeurs. Si une seul de ces routeurs ne peut être relié, alors la requête sera rejetée. Le réseau GÉANT contient 41 routeurs, 16 d'entre eux étant reliés au c ur du réseau par des liens de capacités inférieures à 10 Gbps. Bien que le choix des cibles et destinations ne soient pas totalement aléatoire (voir 5.2.5), et qu'un routeur puisse être utilisé comme destination (ou source) de plusieurs liens au sein d'une même requête, la probabilité qu'un de ces routeurs isolés soit choisi n'est pas négligeable. En supposant que tous les routeurs isolés soient connectés à un seul lien de 5 Gbps et que tous les autres routeurs soient reliés à deux liens de capacité 100 Gbps (cas pessimiste), la probabilité de choisir un routeur isolé serait 50 fois inférieure à celle de choisir un routeur normal. De façon simpliée, on pourrait alors considérer que sur 50 routeurs tirés aléatoirement, un soit isolé, ce qui nous amènerait à avoir un routeur 48

isolé toutes les deux requêtes. En sachant que la capacité moyenne d'un lien virtuel multicast est de 1,4 Gbps, et en supposant le cas idéal où les routeurs isolés soient connectés par des liens de capacité 10 Gbps, sept requêtes seraient susantes pour saturer un de ces routeurs. En considérant que les routeurs isolés sont tirés les uns à la suite des autres (un toutes les deux requêtes), il faudrait 7 16 2 = 224 requêtes pour saturer l'ensemble des routeurs isolés (sous l'hypothèse que les sessions restent actives susamment longtemps). Ce chire de 224 requêtes peut être vu comme une borne supérieure du nombre réel de requêtes nécessaires à la saturation de tous les routeurs isolés, ce qui donnerait un temps de saturation d'environ 2240 unités de temps pour un taux d'arrivée λ = 0.1 et 5600 unités de temps pour un taux de 0.04. Une fois cette saturation atteinte, au minimum une requête sur deux sera refusée car contenant un de ces routeurs isolés. Pour des analyses futures, l'utilisation d'un réseau mieux maillé (plus de liens physiques) avec des capacités homogènes semble nécessaire, les réseaux actuels, tel que GÉANT, n'étant pas conçu pour de la virtualisation. L'utilisation de requête de plus faible taille (en terme de bande passante demandée) peut également être envisagée pour éviter la saturation trop rapide des liens critiques du réseau. 49

Conclusion Face aux changements radicaux apportés par la virtualisation des réseaux et les réseaux programmables, il devient nécessaire de trouver de nouvelles méthodes pour l'optimisation de l'allocation de ressources, permettant une utilisation optimale de l'architecture physique sous-jacente. L'utilisation de techniques d'optimisation de type Programmation Linéaire en Nombres Entiers semble une bonne alternative pour la résolution de ce genre de problème [15] [2] face aux heuristiques standards utilisées dans les réseaux actuels. Le modèle qui a été présenté dans ce document permet l'allocation de ressources pour des liens virtuels avec prise en compte de contraintes de bande passante et de délai avec des temps de calcul raisonnable. La spécicité du modèle réside à la fois dans la possibilité d'allouer des liens de type point à point et point à multipoint, mais également dans la prise en compte de contraintes et objectifs liés à la charge de commutation des routeurs. Basé sur une optimisation de l'équilibre des charges dans le réseau, le modèle montre un apport certain face aux algorithmes de Plus Court Chemin standards, bien que les apports de certains paramètres ne semblent pas évidents. Dans un contexte de type fournisseur de services, le modèle montre les dicultés d'allocation pour des requêtes arrivant les unes à la suite des autres (pas de vision sur le futur), et donc l'importance, pour des modèle de ce type (PLNE) du choix d'une fonction objective ecace. Les résultats obtenus sur le réseau européen GÉANT montrent que sur une topologie réelle actuelle (conçu avant l'arrivée des SDNs et de la virtualisation), l'allocation de liens virtuels peut rapidement montrer ses limites. L'utilisation d'un réseau avec routeurs moins isolés, ou plus dense, semble un meilleur choix pour mettre en place des techniques de virtualisation. Les réseaux programmables (SDNs) et la virtualisation seront au centre des préoccupations dans les années à venir. Leur utilisation semble une évidence pour obtenir la exibilité nécessaire aux applications émergentes. Malgré cela, les topologies actuelles ne semblent pas être totalement adaptées à ces nouvelles techniques. 50

Bibliographie [1] N.M.M.K. Chowdhury and R. Boutaba. A survey of network virtualization. Computer Networking, 2010. [2] N.M.M.K. Chowdhury, M.R. Rahman, and R. Boutaba. Virtual network embedding with coordinated node and link mapping. In INFOCOM 2009, IEEE, pages 783 791, April 2009. doi : 10.1109/INFCOM.2009.5061987. [3] N.M.M.K. Chowdhury, M.R. Rahman, and R. Boutaba. Vineyard : Virtual network embedding algorithms with coordinated node and link mapping. Networking, IEEE/ACM Transactions on, 20(1) :206219, Feb 2012. ISSN 1063-6692. doi : 10.1109/TNET.2011.2159308. [4] DANTE. GÉANT, Media Library : Maps, 2014. URL http://www.geant.net/ Resources/Media_Library/Pages/Maps.aspx. [5] European Future Internet Assembly. European Future Internet Assemby, 2014. URL http://www.future-internet.eu/home/future-internet-assembly.html. [6] FIA. NSF Future Internet Architecture Project, 2014. URL http://www.nets-fia. net/. [7] Christian Frei and Boi Faltings. Resource allocation in networks using abstraction and constraint satisfaction techniques. In Joxan Jaar, editor, Principles and Practice of Constraint Programming CP'99, volume 1713 of Lecture Notes in Computer Science, pages 204218. Springer Berlin Heidelberg, 1999. ISBN 978-3- 540-66626-4. doi : 10.1007/978-3-540-48085-3_15. URL http://dx.doi.org/10. 1007/978-3-540-48085-3_15. [8] GENI. NSF Global Environment for Network Innovations Project, 2014. URL http://www.geni.net/. [9] Wu-Hsiao Hsu, Yuh-Pyng Shieh, Chia-Hui Wang, and Sheng-Cheng Yeh. Virtual network mapping through path splitting and migration. In Advanced Information Networking and Applications Workshops (WAINA), 2012 26th International Conference on, pages 10951100, March 2012. doi : 10.1109/WAINA.2012.74. [10] M. Kucharzak and K. Walkowiak. Maximum ow trees in overlay multicast : Modeling and optimization. In Future Internet Communications (BCFIC), 2012 2nd Baltic Congress on, pages 260267, April 2012. doi : 10.1109/BCFIC.2012.6217955. [11] Jens Lischka and Holger Karl. A virtual network mapping algorithm based on subgraph isomorphism detection. In Proceedings of the 1st ACM Workshop on Virtualized Infrastructure Systems and Architectures, VISA '09, pages 8188, New 51

York, NY, USA, 2009. ACM. ISBN 978-1-60558-595-6. doi : 10.1145/1592648. 1592662. URL http://doi.acm.org/10.1145/1592648.1592662. [12] ONF Market Education Committee. Software-dened networking : The new norm for networks. Open Network Foundation, 2012. [13] H. Masri, S. Krichen, and A. Guitouni. An ant colony optimization metaheuristic for solving bi-objective multi-sources multicommodity communication ow problem. In Wireless and Mobile Networking Conference (WMNC), 2011 4th Joint IFIP, pages 18, Oct 2011. doi : 10.1109/WMNC.2011.6097256. [14] M. Melo, J. Carapinha, and S. Sargento. Network virtualization : A step closer for seamless resource mobility. In Integrated Network Management (IM 2013), 2013 IFIP/IEEE International Symposium on, pages 692695, May 2013. [15] M. Melo, S. Sargento, U. Killat, A. Timm-Giel, and J. Carapinha. Optimal virtual network embedding : Node-link formulation. Network and Service Management, IEEE Transactions on, 10(4) :356368, December 2013. ISSN 1932-4537. doi : 10.1109/TNSM.2013.092813.130397. [16] NGN. New-Generation Network, 2014. URL http://www.nict.go.jp/en/nrh/ nwgn/. [17] J. Nogueira, M. Melo, J. Carapinha, and S. Sargento. Virtual network mapping into heterogeneous substrate networks. In Computers and Communications (ISCC), 2011 IEEE Symposium on, pages 438444, June 2011. doi : 10.1109/ISCC.2011. 5983876. [18] B. Nunes, Marc Mendonca, Xuan-Nam Nguyen, K. Obraczka, and Thierry Turletti. A survey of software-dened networking : Past, present, and future of programmable networks. IEEE Communications Surveys and Tutorials, 2014. [19] M.S. Rathore, M. Hidell, and P. Sjodin. Performance evaluation of open virtual routers. In GLOBECOM Workshops (GC Wkshps), 2010 IEEE, pages 288293, Dec 2010. doi : 10.1109/GLOCOMW.2010.5700328. [20] Yongtao Wei, Jinkuan Wang, Cuirong Wang, and Xi Hu. Bandwidth allocation in virtual network based on trac prediction. In Wireless Communications Networking and Mobile Computing (WiCOM), 2010 6th International Conference on, pages 14, Sept 2010. doi : 10.1109/WICOM.2010.5601426. [21] Yufang Xi and E.M. Yeh. Distributed algorithms for minimum cost multicast with network coding. Networking, IEEE/ACM Transactions on, 18(2) :379392, April 2010. ISSN 1063-6692. doi : 10.1109/TNET.2009.2026275. [22] Minlan Yu, Yung Yi, Jennifer Rexford, and Mung Chiang. Rethinking virtual network embedding : Substrate support for path splitting and migration. SIG- COMM Comput. Commun. Rev., 38(2) :1729, March 2008. ISSN 0146-4833. doi : 10.1145/1355734.1355737. URL http://doi.acm.org/10.1145/1355734.1355737. 52