Partage de bande passante et plan de contrôle optique dans les grilles

Transcription

1 Laboratoire de l Informatique du Parallélisme École Normale Supérieure de Lyon Unité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL n o 5668 Partage de bande passante et plan de contrôle optique dans les grilles Sébastien Soudan encadré par Pascale Primet Février Juin 2006 Rapport de Master 2 Informatique Fondamentale N o DEA École Normale Supérieure de Lyon 46 Allée d Italie, Lyon Cedex 07, France Téléphone : +33(0) Télécopieur : +33(0) Adresse électronique : lip@ens-lyon.fr

2

3 Partage de bande passante et plan de contrôle optique dans les grilles Sébastien Soudan Février Juin 2006 Abstract In this report, we consider the problem of bandwidth sharing in grid s networks. Unified control plane allows creation of bandwidth guaranteed tunnels across optical core network and Ethernet local network. We studie how they can be used in grids. This report proposes a model for such networks and studies the problem of bandwidth sharing with bulk data transfers. Several allocation algorithms based on QoS routing works are proposed and compared. Keywords : grid, bandwidth sharing, GMPLS, unified control plane Résumé Dans ce rapport, nous nous intéressons au problème de partage de bande passante dans les réseaux de grilles. Le concept de plan contrôle unifié permet la création et la réservation de tunnels à bande passante garantie au travers des réseaux locaux Ethernet et des réseaux de coeur optique. Nous étudions comment il peut être utilisé dans les réseaux de grilles. Ce rapport propose une modélisation intégrant les particularités de cette approche ainsi que l étude du problème de partage de bande passante pour les transferts de fichiers massifs dans ce modèle. Plusieurs algorithmes d allocation basés sur les travaux de QoS routing sont proposés et comparés. Mots-clés : grille, partage de bande passante, GMPLS, plan contrôle unifié

4

5 Table des matières 1 Contexte et état de l art Partage de bande passante dans les grilles Évolution des réseaux de grilles Plan contrôle unifié À qui appartiennent les ressources? Systèmes de réservation Problématique Modélisation d une interconnexion flexible de grille Contexte du modèle Modèle proposé Éléments du modèle Utilisation des liens Tunnels Dépendances entre les tunnels Utilisation des tunnels Contraintes de faisabilité Discussion Partage de bande passante dans le cas de transferts massifs Contexte Modélisation des requêtes et formulation du problème Hypothèses Formulation du problème État de l art sur le partage de bande passante Objectif et flexibilité Algorithmes Simulations et analyses des résultats Gsim Simulations Conclusions et perspectives 28 2

6 Table des figures 1 Exemple de LSP utilisant d autres LSP dans un réseau hétérogène muni d un plan contrôle Exemple de réseaux disposant de plusieurs couches de routage Layer (1) de StarPlane Grandeurs associées à la définition d un tunnel dans un autre Exemple de TE-LSP disponibles dans une couche et utilisant des liens/tunnels d une couche inférieure Dépendances entre liens/tunnels Contraintes de tailles sur les tunnels Couche Couche Couche Graphe de dépendance des tunnels entre les noeuds 13 et Requêtes Zone dans laquelle la requête peut être allouée Couche 1 de G-lambda Couche 2 de G-lambda Comparaison entre les ratios de requêtes acceptées de ODS RMAX et ODS RMIN Différence entre le ratio de requêtes acceptées avec des allocations sur r min et r max Ratio de requêtes acceptées pour les algorithmes allouants sur r min Liste des tableaux 1 Systèmes de réservation Requêtes/Réponses Liste des algorithmes 1 Algorithme ST AT IC RMAX Algorithme MODS RMAX

7 Introduction L apparition de plan contrôle unifié autorisant la création de tunnels à la demande dans des réseaux hétérogènes par leurs technologies permet d envisager la mise en place d infrastructure de réservations de ressources dans les grilles. Plusieurs solutions ont été proposées dont DRA- GON 12 un projet NSF fondé sur GMPLS 3, le plan de contrôle proposé par l IETF 4, qui semble le plus prometteur. Cependant bien que DRAGON propose de la réservation en avance, il ne permet que de spécifier un ensemble de circuits que l on souhaite réserver et non des réservations adaptées aux transferts de fichiers. Réservations dans lesquels c est le volume de données à transferer, la date à partir de laquelle le transfert peut commencer et la date à laquelle le transfert doit être fini. Elles nous semblent intéressantes car elles permettent à l utilisateur de spécifier son besoin tout en nous laissant une certaine flexibilité qui permet d optimiser l allocation de ces transferts. La suite de ce rapport est consituté ainsi : Dans la premiere partie, nous présenterons le contexte et l état de l art, c est à dire les évolutions des besoins et celles des réseaux de grilles. La seconde partie présente le modèle de réseau que nous avons créé et sur lequel nous nous basons. La troisième partie présente le problème et les algorithmes développés. La quatrième partie présente des simulations de ces algorithmes avant de conclure et d exposer les perspectives de ce travail. 1 Contexte et état de l art Le contexte de ce rapport est celui des réseaux utilisés pour interconnecter les nœuds dans les grilles de calculs. Il convient tout d abord de donner une brève définition de ce qu est une grille. Pour cela nous utiliserons celle que donne Ian Foster dans [FKT01] : The grid concept is coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organization.. À l heure actuelle, les aspects dynamiques et multi-institutionels des grilles en sont à leurs débuts. Cependant la généralisation des plans de contrôle unifiés comme GMPLS, pourrait contribuer à cela en permettant d interconnecter à la demande des sites éventuellement détenus par des institutions différentes. 1.1 Partage de bande passante dans les grilles Les grilles que nous considérons sont des infrastructures composées de ressources de calcul, de stockage et de communications dédiées au calcul haute performance. Dans ce contexte, les réseaux considérés sont les réseaux locaux qui interconnectent les ressources sur un même site ainsi que ceux qui interconnectent les sites entre-eux. Dans les grilles existantes actuellement, les premiers sont typiquement des réseaux gigabits/s Ethernet (à commutation de paquets) et les seconds des réseaux MPLS 5 (à commutation de circuits virtuels) dans des réseaux de recherche ou des fibres éclairées spécifiquement pour cette grille dans lesquelles transite de l Ethernet gigabits/s ou 10 gigabits/s. Les réseaux locaux dans les grilles sont souvent secondés par un réseau faible latence (Myrinet, SCI, Infiniband,... ) mais nous ne nous y intéresserons pas dans ce rapport. Les topologies de ces réseaux sont actuellement très statiques et les opérations d ajout de connexions entre sites peuvent prendre plusieurs mois en partie parce que la configuration des équipements doit être faite à la main sur tous les équipements concernés. 1 Dynamic Resource Allocation via GMPLS Optical Networks Generalized Multi Protocol Label Switching Multi Protocol Label Switching 4

8 Internet ne permet pas actuellement de réserver de la bande passante. Diverses propositions [XN99] comme DiffServ et IntServ n ont pas abouti dans ce contexte. Cependant, les grilles ont pour objectifs de répondre à des besoins importants en terme de calculs et de quantité de données traitées comme dans le projet du CERN LHC Computing Grid 6. Ce projet a besoin de transférer des quantités importantes de données afin que celles-ci soient traitées avant d être stockées sur des ressources de stockage présentent sur le réseau. De ce fait les besoins de garantie sur les paramètres de qualité de service réseau sont plus marqués, car le fait de ne pas savoir quand un tansfert sera fini empêche de pouvoir déterminer quand on pourra commencer un calcul. De plus, les approches de partage de bande passante utilisée sur Internet avec TCP cherchent l équité du partage de la bande passante. Ce n est pas ce que l on recherche dans les grilles où l on recherche la garantie de disposer de ce que l on a réservé. Dernier point, les interfaces disponibles sur les machines ont des bandes passantes de 1 à 10 gigabits/s alors que les liens des réseaux locaux ont des bandes passantes de 1 à 10 gigabits/s et ceux des réseaux de cœurs de 1 à 40 gigabits/s. Le nombre de flux simultanés nécessaires pour congestionner un lien est très faible par rapport à Internet et les congestions peuvent avoir lieu partout dans le réseau. On a donc besoin de réservations de bout en bout y compris dans le réseau local et ces réservations doivent pouvoir être faites en avance comme le sont les ressources de calcul [FFR + 04]. 1.2 Évolution des réseaux de grilles Plan contrôle unifié L apparition du concept de plan contrôle unifié est sans doute une évolution plus remarquable que l augmentation perpetuelle des débits. Plan contrôle est une terminologie provenant des réseaux de transport et de la décomposition des fonctionnalités nécessaires dans ceux-ci. On distingue quatres plans : le plan gestion (Management plane) est responsable des activités de gestion de réseau comme la collecte des informations sur les trafics, le plan signalisation (Signaling plane) permet la création de nouveaux chemins, le plan routage (Routing plane) assure la diffusion des informations de connectivité, le plan données (Data plane) assure la transmission des données.. Avant l apparition des plans contrôle unifiés, l établissement d une nouvelle connexion dans un réseau de transport nécessitait de passer par les interfaces d administration (qui peuvent être différentes) de chaque équipement. L unification permet de faire automatiquement la configuration des équipements par le biais de protocoles standardisés. Cela facilite pour les opérateurs les opérations de reconfiguration du réseau lors des changements de matrices de trafic afin d optimiser l utilisation des ressources. Ces opérations sont nommées Traffic Engineering. C est pour cela que les plans contrôle unifiés ont été créés. Cependant il devient également envisageable de donner accès à ce plan aux utilisateurs ce qui leur permettrait d agir sur le réseau et sur les chemins qu empruntent leurs flux. Il existe plusieurs solutions de plan contrôle, nous pouvons noter celui de l IETF : GMPLS 7, celui de l ITU 89 : ASON 10 et celui de CA*net4 11, le réseau de recherche canadien : UCLP Generalized Multi-Protocol Label Switching 8 International Telecommunication Union Automated Switched Optical Network User Controlled LightPath 5

9 GMPLS [Man04] est une suite de protocoles issue de l évolution de MPLS, de la prise en compte et de l unification des différents modes de commutation que l on rencontre dans les réseaux : multiplexage spatial (choix physique d une fibre par exemple), de longueur d onde (sélection d une longueur d onde dans une fibre), temporel (sélection d un slot dans une trame SONET), de paquets. En tant qu évolution de MPLS, dans les réseaux GMPLS, le routage est effectué sur des labels (label switching) et non sur une adresse IP de destination prise dans l en-tête des paquets. Cela permet d être plus rapide puisque la décision de routage dépend directement du label. On évite ainsi le Longest Prefix Match nécessaire dans le cas du routage IP. GMPLS est composé de trois parties : gestion des liens, routage et signalisation. Le rôle de la première est d échanger des informations sur les capacités des extremités d un lien entre les deux routeurs qui composent ce lien (longueurs d onde utilisables par exemple) ainsi que la détection des pannes. La deuxième s occupe d échanger les informations permettant de prendre une décision de routage : annonce des liens, de leurs bande passantes disponibles, de leur longueurs et de leur type de multiplexage. Enfin la troisième partie permet de configurer les routeurs pour qu il puisse acheminer des données sur un chemin (LSP 13 ) particulier dont la bande passante est réservée dans chaque routeur qu il traverse. Les protocoles réalisant les deux dernières parties sont respectivement OSPF-TE [KR05] et RSVP-TE [KL04] qui sont des extensions de OSPF et RSVP. L établissement d un nouveau chemin dans un réseau utilisant GMPLS nécessite donc d écouter les annonces de liens (TE-Link) faites par OSPF-TE, de calculer le chemin que l on veut et enfin de le signaler (de le configurer sur chacun des routeurs qui le compose) par RSVP-TE. Il y a cependant des contraintes. Un LSP doit commencer et terminer dans un même type de multiplexage. D autre part, il est possible de créer un LSP et de l annoncer ensuite comme un lien disponible par OSPF-TE. Ce lien est alors un TE-LSP et pourra être utilisé par un autre LSP plus tard. Il est donc possible de faire passer au travers d un réseau tel que celui de la figure 1 des LSP dans d autres LSP à condition de respecter une hiérarchie entre les types de multiplexage qui découle de ce que l on sait encapsuler dans un autre multiplexage. Il est par exemple possible d encapsuler des paquets Ethernet dans une longueur d onde d une fibre mais le contraire ne l est pas. GMPLS offre également d autres possibilités que nous avons passées sous silence comme la protection des liens, la détection de pannes. Si nous revenons au cadre des grilles, en faisant l hypothèse que le réseau d interconnexion des sites utilise GMPLS, il serait possible d établir de nouveaux liens entre des sites et donc de mettre à disposition des utilisateurs plus de ressources quand ceux-ci en ont besoin. Le quand reste à définir mais nous voyons que GMPLS apporte une certaine flexibilité dans la gestion des ressources réseaux disponibles. Il y a cependant des limitations dans l état actuel de GMPLS. L article [VZH06] en identifie plusieurs dont l impossibilité de faire des réservations en avance et les problèmes de la gestion des autorisations qui ne sont pas pris en compte. Le premier problème est traité dans un Network Ressources Manager chargé de plannifier l utilisation du réseau dans plusieurs propositions d infrastructure de réservation de ressources réseaux pour grille dont DRAGON. Le second problème est un problème de modèle économique de réseaux et plus généralement de grilles : qui possède les ressources? Ce problème se retrouve dans la définition et la mise en place d interface entre l utilisateur et le réseau : UNI 14, et entre deux réseaux : NNI Label Switched Path 14 User to Network Interface 15 Network to Network Interface 6

10 Fig. 1 Exemple de LSP utilisant d autres LSP dans un réseau hétérogène muni d un plan contrôle À qui appartiennent les ressources? La question de savoir à qui les ressources appartiendraient dans une grille commerciale est assez délicate car pour l instant les grilles existantes sont majoritairement dans les réseaux de recherche. Nous pouvons néanmoins envisager plusieurs cas : les ressources d interconnexion sont louées à un opérateur et les opérateurs de la grille ou les utilisateurs finaux ne disposent d aucun contrôle dessus, l opérateur autorise à allouer dynamiquement dans son réseau des tunnels entre les sites, les ressources d interconnexion appartiennent aux opérateurs de la grille. Le premier cas correspond au modèle actuel de location de bande passante pour Internet. À première vue le second cas est problématique car les opérateurs n ont pas pour habitude de donner du contrôle sur leurs réseaux aux utilisateurs. Cependant plusieurs propositions telles que les L1VPN [FB05, Chapitre 12] permettent d envisager que l opérateur puisse fournir un contrôle limité sur une partie de ses ressources. Nous pouvons ainsi envisager de négocier avec l opérateur un ensemble de ressources que nous pouvons utiliser pour signaler des tunnels. Ces ressources peuvent être virtuelles dans le sens où il ne s agit pas de ressources physiques mais de ressources que l opérateur s engage à approvisionner en fonction d un contrat entre lui et son client [DGG + 99]. Enfin dans la dernière solution, chaque site dispose de ses propres fibres l interconnectant avec les autres. Dans ce modèle il n y a plus d opérateur mais éventuellement des loueurs de fibres noires. Chaque site est alors opérateur de ses propres fibres. C est le modèle proposé dans [WSC + 05] et mis en place dans CA*net4. Il ressort de ce panorama que plusieurs modèles sont possibles. Tous ont en commun une tendance marquée vers l augmentation du contrôle dont dispose les utilisateurs et de la quantité d information dont celui-ci dispose pour pouvoir faire ce contrôle. Cette étude se place dans les deux derniers cas. Dans la suite, nous supposons disposer de ressources que l on contrôle, que ces ressources soient des ressources physiques ou virtuelles Systèmes de réservation Plusieurs propositions d infrastructures de réservations de ressources réseaux ont été faites. Toutes ne sont pas spécifiques aux grilles et ne sont pas orientées réseaux utilisant GMPLS. Le 7

11 DRAGON GARA DWDM-RAM G-Lambda CHEETAH Multi-Domaines oui oui non non non Réservations en avance oui oui oui oui non Plan contrôle GMPLS DiffServ ODIN et GMPLS GMPLS GMPLS Requêtes Circuits Trafics Diffserv Circuits Circuits Circuits Tab. 1 Systèmes de réservation tableau 1 compare quelques unes de ces solutions. DRAGON 16 est un projet qui a pour but de créer une infrastructure de réservation de bout en bout dans des réseaux basés sur GMPLS. DRAGON propose d utiliser des VLAN Ethernet pour réaliser des tunnels dans le réseau d un site. Grâce à un équipement (VLSR 17 ) qui configure les switchs, l infrastructure de DRAGON est capable de contourner le routage (Spanning Tree) d Ethernet. On se retrouve donc dans le réseau local dans une situation très proche de celle d un réseau de cœur optique dans lequel on peut choisir également son chemin. DRAGON propose un service appellé NARB 18 chargé de recevoir les informations de routage par OSPF- TE, de signaler les tunnels par RSVP-TE pour les clients finaux (machines) qu il représente et d échanger les informations sur la disponibilité des ressources avec ses homologues dans les autres sites. DRAGON permet la réservation à l avance de topologies avec des bandes passantes définies. En revanche il ne permet pas d ordonnancer des transferts de fichiers massifs spécifiés par le volume. Nous allons à présent comparer quelques grilles et leurs réseaux. DAS3, la grille de recherche hollandaise, repose sur une infrastructure optique Starplane 19 fournie par SURFnet6. DAS3 est composée de quatres sites sur un anneau de fibres pouvant contenir huits longueurs d onde. Les longueurs d onde permettent d acheminer de l Ethernet 10 gigabits/s d un site à un autre. L accès au plan contrôle s effectue par le Network Operation Center de SURFnet6. G-lambda 20 est une grille japonnaise utilisant GMPLS. Elle est composée de six sites, six routeurs optiques disposés en anneaux et chaque fibre transporte entre deux et trois longueurs d onde. Grid est la grille de recherche française, les interconnexions entre les sites sont fournies par Renater4 et à terme devraient être des liens 10 Gigabits/s Ethernet. Aucun contrôle de la part des utilisateurs n est possible sur le réseau de cœur et la topologie est un arbre. On retiendra de cela que le nombre des sites est infèrieur à dix, et que le nombre de longueurs d onde ne permet pas d allouer un circuit entre chaque paire de sites. 1.3 Problématique Dans les sections précédentes, nous avons montré qu aujourd hui émergent des mécanismes permettant d allouer des ressources réseaux à la demande grâce aux plans contrôle unifiés et automatisés comme GMPLS. De plus, nous avons vu qu il est possible de faire de la réservation en avance et ce de bout en bout (dans le réseau de cœur optique et dans les réseaux Ethernet des sites) grâce à des systèmes comme DRAGON par exemple. Le problème que nous nous 16 Dynamic Resource Allocation via GMPLS Optical Networks 17 Virtual Label Switching Router 18 Network Aware Resources Broker

12 posons dans cette étude est donc d analyser comment cette flexibilité offerte par ces nouvelles infrastructures de contrôle des réseaux permet d optimiser l utilisation des ressources réseaux et de satisfaire les attentes des utilisateurs. Cette étude se décompose en deux parties. Dans la première partie nous proposons une modélisation de l interconnexion flexible de grille et une modélisation des requêtes des utilisateurs. Nous identifions ensuite les problèmes d allocation et d optimisation sous-jacents. Dans la seconde partie, nous proposons quelques heuristiques pour résoudre le problème du routage et du partage de bande passante. Nous analysons ensuite les résultats de ces algorithmes par simulation en utilisant des exemples d interconnexions existantes. 2 Modélisation d une interconnexion flexible de grille 2.1 Contexte du modèle Nous voulons modéliser un réseau à I > 0 couches dans lequel il faut faire une hiérarchie de tunnels (TE-LSP) dans les couches inférieures avant de pouvoir y faire passer du trafic lui même dans un tunnel (LSP). Il s agit de modéliser un réseau utilisant GMPLS pour lesquel DRAGON propose une infrastructure permettant la réservation en avance. Pour cela, nous allons utiliser un multigraphe Layer (i) pour représenter les ressources de la couche i. Ces réseaux peuvent être vus comme des réseaux disposant de plusieurs couches dans lesquels nous pouvons choisir la route que nous voulons emprunter. Fig. 2 Exemple de réseaux disposant de plusieurs couches de routage Sur la Figure 2 nous avons en rouge les routeurs, en blanc les noeuds réalisant les extremités des tunnels et en bleu et jaune deux chemins au travers de ces couches. La couche la plus haute ne contenant que les machines n est pas représentée. Dans la suite, nous faisons plusieurs hypothèses. Nous supposons d abord que les liens sont symétriques (même bande passante dans les deux sens), il s agit d une des hypothèses de GM- PLS. La couche la plus haute (I) ne contient que des extremités de tunnels (T ermup), ce sont les machines des sites. Enfin les tunnels ne sont pas bifurqués, c est à dire qu un tunnel ne passe que par un seul chemin dans le réseau. 9

13 2.2 Modèle proposé Éléments du modèle La modélisation du réseau fait intervenir des nœuds de natures différentes permettant ainsi de différentier les fonctions réalisées par ces différents types de nœuds. Définition 1 Nodes Ce sont les nœuds du réseau. Ils sont en nombre fini et nous les identifierons par un entier. Le premier type spécialisé de nœud est celui des routeurs. Il n est relié qu à des nœuds de sa couche. Définition 2 Routers (i) Ce sont les routeurs de la couche i du réseau. C est une partie de Nodes. Pour modéliser les extremités des tunnels, nous avons recours à deux ensembles par couche. Cela nous permet de différentier les nœuds qui sont point d entrée vers un tunnel dans une couche inférieure et les nœuds qui sont point d entrée pour une couche supérieure dans un tunnel qui est réalisé dans la couche considérée. L ensemble contenant les premiers nœuds pour la couche i est nommé T ermup (i) et celui contenant les seconds est nommé T ermdown (i). Définition 3 T ermdown (i) C est l ensemble des nœuds qui permettent de faire des tunnels dans la couche i pour une couche supérieure. C est une partie de N odes. Ces nœuds réalisent des terminaisons de tunnels et modélise la capacité d adaptation qu ont les équipements qui permettent d encapsuler le trafic d une couche (d un multiplexage) dans des tunnels d une autre couche. Définition 4 T ermup (i) C est l ensemble des nœuds qui permettent à la couche i d accéder à des tunnels des couches inférieures. C est également une partie de N odes. Soit x appartenant à Nodes, il existe au plus un seul couple d entier (i, j) (avec 1 i < j I) tel que x appartient à T ermup (j) T ermdown (i). Nous imposons également que T ermup (1) soit vide. La couche 1 est la plus basse, elle ne peut utiliser de tunnels dans les couches inférieures. La figure 3 représente la couche 1 du réseau StarPlane. Similairement, la couche I ne contient que des nœuds de type T ermup.. Voici la définition d une couche i : Définition 5 Layer (i) C est un multigraphe G dont les arêtes sont pondérées. Il représente la couche i du réseau. G = (V, E, N max, Bandwidth) tel que : V = Routers (i) T ermdown (i) T ermup (i) E est le multi-ensemble des arêtes (TE-links) Si v V \Routers (i) alors deg(v) = 1 N max : E N Bandwidth : E R N max (e) est le nombre de tunnels que nous pouvons faire à l interieur du lien e et Bandwidth(e) est la taille du lien e. Il s agit de données décrivant les liens physiques disponibles. 10

14 La taille des tunnels que nous pouvons faire dans un autre tunnel ou lien est contrainte par le paradigme de commutation utilisé. Dans le cas où il s agit de commutation de longueur d onde, par exemple, la taille d une longueur d onde est fixée à une certaine valeur. Nous utilisons deux variable LSP (i) min et LSP (i) max comme bornes pour les tailles possibles des tunnels. Définition 6 LSP (i) (i) min et LSP max Nous définissons deux valeurs (réelles) LSP (i) min et LSP (i) max par couches. Ces valeurs sont les bornes sur la taille des tunnels faisables dans une couche i. C est une simplification du modèle car il s agit normalement d une propriété de chaque TElink. Le choix de la taille lors de la création d un tunnel est soumis à plusieures contraintes. Sur la figure 4, nous pouvons voir que le choix de la taille Bandwidth d un nouveau tunnel dans un autre lien ou tunnel doit être comprise entre LSP min et LSP max, et doit être plus petite que F reebandwith, la bande passante disponible. Nous reviendrons sur les contraintes plus tard dans ce rapport. Fig. 3 Layer (1) de StarPlane Définition 7 TE-links (i) Pour tout 1 i I, TE-links (i) est l ensemble des triplets (e, N max (e), Bandwidth(e)) pour tout e appartenant à l ensemble des arêtes du Layer (i). 11

15 Fig. 4 Grandeurs associées à la définition d un tunnel dans un autre Utilisation des liens Les liens (TE-links) que nous venons de définir vont être utilisés pour créer des tunnels, il va donc nous falloir définir des fonctions donnant les ressources disponibles dans ces liens. Ces ressources sont la bande passante disponible (F reebandwidth) et les labels disponibles (F reen). Pour cela, nous allons utiliser deux fonctions en escalier pour chaque lien e. Le choix des fonctions en escalier se justifie par le fait que l on ne peut changer la bande passante d un tunnel alloué de manière continue, ce changement nécessite la signalisation de ce changement sur le chemin (par RSVP-TE par exemple). Définition 8 F reebandwidth et F reen Soit e un lien, c est à dire une arête d un des Layer (i), F reebandwidth e est une fonction en escalier du temps (R + ) dans R et F reen e est une fonction en escalier du temps (R + ) dans N. F reebandwidth e (t) correspond à la bande passante non utilisée dans le lien à l instant t, et F reen e (t) au nombre de labels non utilisés à ce même instant Tunnels À présent nous disposons d un modèle pour les TE-links, c est à dire une partie des ressources disponibles dans une couche pour établir des circuits, l autre partie de ces ressources provient des tunnels que l on peut créer dans les couches inférieures. Ces tunnels peuvent utiliser des liens ou des tunnels des couches inférieures comme le schématise la figure 5. C est ce que nous allons définir maintenant. Dans la suite nous ne ferons pas de différence entre le LSP et le TE-LSP car dans la nomenclature GMPLS, les TE-LSP sont des LSP qui sont annoncés par OSPF-TE et qui peuvent donc être réutilisés par d autres tunnels. Les TE-LSP ont les mêmes propriétés que les TE-links, c est à dire (N max, Bandwidth). Cependant elles dépendent pour une part des liens (TE-links et TE-LSP) utilisés pour les réaliser dans les couches inférieures et d autre part de propriétés de leurs points d extremités : les T ermup (i). Ce sont les extremités qui déterminent comment elles vont pouvoir découper le tunnel pour faire passer les tunnels des couches supérieures. Nous noterons également que 12

16 Fig. 5 Exemple de TE-LSP disponibles dans une couche et utilisant des liens/tunnels d une couche inférieure contrairement aux liens, la bande passante d un tunnel est une fonction du temps puisqu un tunnel est signalé 22 pour un certain temps. La bande passante maximum utilisable (Bandwidth) provient des liens supportant les TE- LSP alors que les autres propriétés proviennent des nœuds d extremité. Pour simplifier la modélisation, nous supposerons que les propriétés des TE-LSP dépendantes des T ermup (i) sont identiques dans une couche et donc ne dépendent que de i. Nous les noterons N max, (i) LSP (i) min et LSP max. (i) Dans les approches classiques d allocations de bande passante sur un réseau multicouche [PM04], les requêtes des couches supérieures sont agrégées et servies par des liens virtuels entre les points d accès aux couches inférieures et ces liens deviennent alors des demandes pour ces couches. Dans notre cas, nous souhaitons pouvoir choisir parmi plusieurs chemins dans les couches inférieures car nous ne voulons pas découper une requête sur plusieurs chemins et ne savons pas agréger les chemins pour n en faire qu un. Il nous faut donc remonter les chemins possibles vers les demandes afin de pouvoir les sélectionner pour servir les requêtes. Nous allons construire l ensemble des tunnels que l on peut faire dans une couche en utilisant celles du dessous. Dans un premier temps, nous ne nous préoccuperons pas des problèmes de bande passante. Définition 9 TE-LSPs (i) Si i = 1, TE-LSPs (i) est vide. Si i > 1, TE-LSPs (i) est l ensemble des ({s, d}, P, n, j) tel que : 1 j < i (j est le numéro de la couche dans laquelle se trouvent les liens que le tunnel utilise) s est un élement de T ermup (i) T ermdown (j), d est un élément de T ermup (i) T ermdown (j) distinct de s, P est une chaine élémentaire entre s et d dans Layer (j) auquel nous avons ajouté des arêtes entre deux nœuds de T ermup (j) s il existe un tunnel dans TE-LSPs (j) les reliant n est un entier compris entre 1 et N p = min e P ({N max (e)}) (où si e est un tunnel de la couche k, N max (e) = N max). (k) n représente le label GMPLS du TE-LSP. Pour chaque pair de nœuds de T ermup (i), nous avons un nombre p de chemins, et sur chaque chemin N m (avec 1 m p) TE-LSP. Dans la suite, nous identifierons chacun de ces tunnels par un entier e unique et distinct des représentants des arêtes des Layer (i). De plus, nous noterons L e la couche dans laquelle le tunnel e est réalisé (i.e, le j de la définition). 22 créé 13

17 Définition 10 Nous noterons l e si le tunnel e utilise le tunnel (ou le TE-link) l. Définition 11 TE-LSPs TE-LSPs = TE-LSPs (i) 1 i I Nous avons également besoin de définir la taille Bandwidth de ces tunnels, cette fois il s agit d une fonction en escalier du temps. Il en est de même pour les fonctions en escalier F reen et F reebandwith. Définition 12 Bandwidth e, F reen e et F reebandwith e Pour 1 i I, Soit e une arête de Layer (i) ou un tunnel de TE-LSPs (i), nous définissons sa taille par la fonction en escalier Bandwidth e : R + R +, son nombre de labels disponibles par la fonction en escalier F reen e : R + N et sa bande passante disponible F reebandwidth e : R + R + dont nous donnerons une expression dans la définition 17. Pour le cas des liens, nous avons t R +, Bandwidth e (t) = Bandwidth(e). Tous ces tunnels ne sont pas réalisables en même temps et toutes les tailles de tunnel ne sont pas accessibles. Il nous faut donc exprimer les conditions permettant de déterminer si des tunnels sont faisables. Tous les tunnels de TE-LSPs (i) sont faisables mais pas forcément en même temps Dépendances entre les tunnels Nous avons vu dans la construction des TE-LSPs (i) que ceux-ci utilisent les TE-links et/ou les tunnels des couches inférieures. Ces dépendances peuvent être traduites sous la forme d un graphe acyclique orienté. À partir de la relation, nous définissons le graphe de dépendances suivant : Définition 13 Dep Pour 1 i I, nous noterons E (i) les arêtes de Layer (i). Dep = (V, E) est le graphe de dépendances des TE-LSPs tel que : V = TE-LSPs E (j) 1 j I (e1, e2) E ssi e2 est dans TE-LSPs et e1 e2, c est à dire que e2 utilise e1. Un exemple d un tel graphe est représenté sur la figure 6. Un tunnel de la couche 3 est réalisé à partir de liens et/ou de tunnels d une couche inférieure qui sont eux-même réalisés à partir de liens de la couche 1. Définition 14 Dépendance entre e et l : δ l,e Soit e un entier représentant un TE-LSP et l un entier représentant un TE-LSP ou un TE-link, { 1 si l e δ l,e = 0 sinon 14

18 Fig. 6 Dépendances entre liens/tunnels Utilisation des tunnels Nous avons besoin de pouvoir marquer un tunnel comme utilisé afin d exprimer des contraintes sur sa taille et sur le nombre de labels utilisés dans un tunnel. Pour cela, nous définissons pour chaque tunnel et lien, une fonction du temps InUse e à valeurs dans {0, 1} qui vaut 0 lorsque e n est pas utilisé, et 1 lorsqu il l est. Définition 15 Contraintes de signalisation des tunnels Activité des tunnels : l TE-LSPs TE-Links, e TE-LSPs, δ l,e InUse e InUse l (1) Contraintes de faisabilité Les contraintes de faisabilité portent sur trois points : 1. le nombre de tunnels que l on peut faire dans un autre tunnel ou dans un TE-link ; 2. la taille Bandwidth(e) d un tunnel qui doit être comprise entre LSP (Le) min tunnel est utilisé ; (Le) et LSP max si le 3. la somme des tailles des tunnels contenus dans un TE-link ou dans un autre tunnel ne doit pas excéder celle de ce dernier. La définition des TE-LSPs (i) ne suffit pas pour nous garantir que les contraintes sur le nombre de TE-LSP par rapport au N max sont vérifiées. Il nous faut vérifier explicitement que le nombre de labels utilisés dans chaque tunnel et TE-Links est inférieur au nombre disponible N max. Définition 16 F reen Soit l un lien ou un tunnel, F reen l = N max (l) δ l,e InUse e e TE-LSPs En ce qui concerne les contraintes d utilisation des tunnels et des liens du point de vue de la bande passante, nous allons définir F reebandwidth afin de pouvoir exprimer le fait que nous ne voulons pas que la somme des tailles des tunnels créés dans un lien ou tunnel soit plus grande que la taille de ce tunnel comme le montre la figure 7. 15

19 Définition 17 F reebandwidth l Soit l un lien ou un tunnel, F reebandwidth l = Bandwidth l δ l,e InUse e Bandwidth e e TE-LSPs Les contraintes sont alors les suivantes : Fig. 7 Contraintes de tailles sur les tunnels Définition 18 Contraintes de faisabilités des TE-LSP Capacité des TE-link : Capacité des tunnels : Taille des tunnels : Nombre de tunnels : 2.3 Discussion l TE-links, F reebandwidth l 0 (2) l TE-LSPs, F reebandwidth l 0 (3) l TE-LSPs, InUse l LSP (L l) min Bandwidth l LSP (L l) max (4) l TE-LSPs TE-Links, F reen l 0 (5) Les figures 8, 9, 10 et 11 donnent respectivement la description de la topologie des couches 1, 2 et 3 d un réseau très simple ainsi que le graphe des dépendances entre les tunnels possibles entre les noeuds de la couche 3 : 13 et 18 où nous n avons gardé qu un tunnel pour représenter tous les tunnels qui ne diffèrent que par leur label n. Les étiquettes sur les arêtes contiennent dans le cas d un lien, le nombre de labels maximum et la bande passante, et dans le cas d un tunnel, le label de ce tunnel, le nombre de labels disponibles et la bande passante. Sur les trois premières figures, les éléments nommés Router sont en rouge, en bleu sont les T ermdown et en vert les T ermup. Ces deux derniers éléments sont les extremités des TE-LSPs 16

20 (en bleu) et les TE-Links sont en rouge. Chaque arc est étiqueté par trois valeurs : le numéro du lien ou tunnel, le nombre de labels disponibles ainsi que la bande passante (Bandwidth). Nous remarquons sur la figure 10 qu elle ne comporte que des TE-LSPs. Dans cet exemple, la couche 1 ne comporte que des liens, la couche 2 comporte des liens et des tunnels entre les noeuds verts de cette couche. Les T ermup (en vert) de la figure 9 correspondent aux T ermdown (en bleu) de la figure 8 et les tunnels (en bleu) sont constitués de liens de la couche 1. De même, les T ermdown de la couche 2 correspondent aux T ermup de la couche 3 et les tunnels présentés dans cette dernière couche sont réalisés par les liens et tunnels accessibles dans la couche 2. La figure 11 représente les dépendances entre les différents tunnels et liens. Cette structure devient rapidement très importante. Cependant, nous n avons pas besoin de différencier les tunnels de la couche 3 qui utilisent les mêmes chemins et comme nous le verrons par la suite, l état du réseau dont nous avons besoin pour allouer une nouvelle requête ne requiert pas de connaître tous les tunnels de la couche 3, et nous pouvons utiliser l information agrégée dans les fonctions d état F reen et F reebandwidth des liens et tunnels des couches 1 et 2. 17

21 Fig. 8 Couche 1 Fig. 9 Couche 2 Fig. 10 Couche 3 Fig. 11 Graphe de dépendance des tunnels entre les noeuds 13 et 18 18

22 Requêtes Réponses Utilisation Article (Date de début, {(Débit, {LSP,... } Générique [LSJ06] Source, Destination),... }) (Volume, Débit max, {(Début, Débit, Fin), Transfert de fichiers [VZcF + 03] Date de début, Source,... } Destination) (Débit, Date de début, (Débit) Requête de longue durée Source, Destination) (Volume, Débit max, Date de début, Date de fin, Source, Destination) (Début, Débit, Fin) Réservation de courte durée Tab. 2 Requêtes/Réponses [VBZ05] 3 Partage de bande passante dans le cas de transferts massifs 3.1 Contexte Maintenant que nous disposons d un modèle pour décrire un réseau, nous allons étudier comment allouer des requêtes de transfert de fichiers dans une grille similaire à G-lambda (la grille japonaise) du point de vue de sa topologie. Nous nous restreignons donc à un réseau à trois couches, la couche 1 est le réseau optique, la couche 2 correspond à la couche Ethernet et la couche 3 représente les machines et les LSP utilisés pour servir les requêtes que nous allons décrire dans la section suivante. Nous disposons dans cette situation de deux niveaux de granularité pour servir les requêtes, d une par la création de tunnels optiques et d autre part la création de tunnels Ethernet dans les tunnels optiques. Sur les premiers, nous ne disposons pas du choix de la bande passante (LSP max = LSP min ) alors que sur les seconds il n y a pas de contraintes particulières en dehors de la bande passante disponible dans les liens et tunnels utilisés. Notons que nous laissons de côté les aspects concernant l interface entre les applications ou les machines et le NRM 23 ainsi que les problèmes relatifs à la mise en place de limitations et de contrôle du débit des flux Ethernet. En effet, nous voulons réaliser des circuits dans un monde de paquets (Ethernet), il faut donc s assurer qu aucun des circuits de paquets ne dépasse les limites qui lui sont imposées pour ne pas perturber les autres flux en créant des congestions dans les équipements. Dans la suite nous supposons que ces mécanismes sont mis en place. 3.2 Modélisation des requêtes et formulation du problème Hypothèses Comme le montre le tableau 2, plusieurs formats de requêtes et de réponses ont été proposés. Celui que nous allons retenir dans la suite repose sur la donnée d un volume à transférer entre une source et une destination entre deux dates tout en utilisant une bande passante inférieure à une valeur donnée. Il s agit du modèle de requête utilisé dans [VBZ05]. 23 Network Ressources Manager 19

23 Définition 19 Requête Nous définissons une requête r comme étant un 7-uplet (s, d, r max, volume, start, deadline, release) où : s est la source. d est la déstination, r max R est le débit maximum de la source, volume R est le volume des données à transférer, start est la date à partir de laquelle le transfert peut commencer, deadline est la date à laquelle le transfert doit être fini, release est la date à laquelle la requête est transmise au système de réservation. Dans le cas où nous pouvons et décidons de servir cette requête, la réponse est un tunnel d une taille donnée plus petite que r max, entre la source et la destination pendant une fenêtre de temps comprise entre start et deadline, qui permet de faire passer la quantité de données volume. Définition 20 r min Nous définissons r min (r) comme étant la bande passante qu il faut allouer pour satisfaire la requête r si nous utilisons une bande passante constante entre start(r) et deadline(r). volume(r) r min (r) = deadline(r) start(r) Une telle spécification des requêtes nous offre de la flexibilité sur la taille et les dates de début et de fin de signalisation des tunnels alloués pour servir ces requêtes comme le montre la figure 12. En se limitant à des solutions où l on sert la requête sur une bande passante constante, nous pouvons d une part choisir le débit de service et d autre part la date de début et de fin. On ne s intéresse pas au cas où la bande passante peut changer car cela suppose une reconfiguration (resignalisation) des tunnels. Fig. 12 Requêtes 20

24 3.2.2 Formulation du problème Nous nous limitons à un schéma d ordonnancement où nous traitons les requêtes online et nous ne considèrons qu une requête à la fois, c est à dire que nous traitons les requêtes lorsqu elles sont soumises au système de réservation. Le problème est donc de prendre la décision d accepter ou de rejeter une requête et de lui trouver une place en fonction de l état que nous connaissons du réseau pendant la durée dans laquelle nous pouvons allouer cette requête (start, deadline) et des contraintes précédemment mentionnées. Dans le cas où nous acceptons une requête, la réponse du système de réservation est un quadruplet (date de début réelle, date de fin réelle, débit, chemin) où le chemin est un tunnel de Layer (I). Nous nous limitons à regarder le cas où la décision est prise au moment de l arrivé de la requête dans le système. Nous pourrions envisager de prendre cette décision plus tard (mais avant start). L état du réseau qui nous intéresse est celui entre la date de début start et celle de fin deadline d une requête puisque c est entre ces deux dates que la requête doit être servie. Cet état est l ensemble des fonctions en escalier (F reen, F reebandwidth, InUse) des liens et tunnels du réseau sur l interval de temps considéré. Par rapport à ce qui a été étudié dans [VBZ05], le réseau de cœur n est pas considéré comme surdimensionné 24, il nous faut donc considérer chacun de ses liens pour s assurer qu il n y ait pas de congestion alors que dans l article seul les deux liens d accès des sites concernés par les requêtes sont à considérer. D autre part, nous considèrons également les congestions possibles dans les réseaux locaux aux sites et enfin nous pouvons créer dynamiquement de nouveaux tunnels entre des sites à condition de respecter les contraintes de nombre de labels, de bande passante disponible et de taille des tunnels. Du fait que nous pouvons créer de nouveaux tunnels et que nous considèrons les topologies des réseaux des sites, il est possible que nous ayons à choisir entre plusieurs chemins, ce qui n était pas le cas dans l article précédemment cité. Nous sommes donc face à un problème à la fois de routage et d ordonnancement État de l art sur le partage de bande passante Notre problème de partage de bande passante, nécessite à la fois de trouver un créneau temporel dans lequel la requête pourra être servie et un chemin sur lequel elle pourra l être. Le premier problème a été étudié dans [CVB06] pour les réseaux de coeur surdimensioné. Dans ce cas, seuls les liens d accès sont considérés et il n y a alors qu un chemin entre deux sites. On peut alors rechercher un interval de temps qui permet de servir la requête sur les deux liens. Dans notre cas, il faut également calculer la route entre la source et la destination. On se rapproche plus d un problème de QoS routing où l on cherche un chemin satisfaisant certaines contraintes et optimal suivant d autres métriques. Ces problèmes de routage ont largement été étudiés et [CN98] présente un état de l art des problèmes et des solutions. Les problèmes de routage link-constrained path-optimization peuvent être résolut par un shortest-path sur le graphe où l on a éliminé les arêtes ne satisfaisant pas les contraintes. Le fait de trouver le chemin le plus court dont tous les liens ont une bande passante disponible plus grande qu une valeur donnée est l un de ces problèmes. C est à ce cas que nous allons nous ramener. La perspective d utiliser le routage dans des problèmes de réservations en avance à été abordée dans [GO00] dans le cas où le temps est discret. 24 C est à dire que nous ne considèrons que les liens d accès au cœur qui est alors assimilable à un seul routeur central dans un réseau à une seule couche de routage. 21

25 3.3 Objectif et flexibilité Notre objectif est de maximiser le nombre de requêtes acceptées. Nous ne cherchons pas à servir la requête au plus tôt car nous supposons que le client nous a exprimé ses contraintes dans la requête où il aurait pu mettre une deadline plus tôt au besoin. Nous allons à présent regarder les différents choix qui nous sont offerts. Dans cette partie, nous supposons que nous avons déja les tunnels candidats, c est à dire les tunnels de la couche I dont la source et la destination correspondent à celles de la requête. Nous nous préoccuperons plus tard de savoir quels sont les tunnels candidats et comment les obtenir. Le problème est de construire la zone dans laquelle il est possible d allouer une bande passante pour notre requête, c est à dire pour le tunnel qui pourrait potentiellement répondre à la requête. Nous faisons toujours l hypothèse que nous ne modifions pas les requêtes précédemment allouées. Toutes les requêtes précédentes sont agrégées dans la bande passante utilisée des tunnels, et nous ne disposons que de l information véhiculée par F reebandwidth. Pour que nous puissions accepter une requête, il nous faut pouvoir modifier les fonctions InUse e et Bandwidth e d un tunnel candidat e de telle façon que les requêtes précédentes ne soient pas touchées. Il faut pour cela que les fonctions ne soient modifiées que sur des intervals où InUse e vallait 0 et que l ajout d un créneau à ces fonctions sur un interval [a, b] [start, deadline] tel que b a Bandwidth e (t) dt = volume soit possible en respectant les contraintes mentionnées plus haut. Deux cas sont possibles. Dans le premier cas, les liens/tunnels utilisés par le tunnel candidat sont signalés (InUse = 1) tout le temps entre start et deadline et dans le second, ce n est pas le cas, il faut donc envisager de signaler un autre tunnel dans une couche inférieure et donc de lui donner une taille. Revenons au premier cas. Nous considèrons un tunnel candidat e, dont l ensemble des tunnels qu il utilise est P. Nous supposons que pour tout l de P, sur l interval [start, deadline], InUse l (t) = 1. Dans ce cas, tous les tunnels de P sont signalés et ont une taille, on ne peut pas les changer et elles sont correctes du point de vue des contraintes. De ce fait, les tunnels l de P ont une bande passante libre F reebandwidth l qui est positive sur [start, deadline]. Afin de déterminer la taille du tunnel e que nous pouvons utiliser pour (éventuellement) répondre à la requête, il nous faut regarder quelles sont les valeurs possibles. Pour cela nous allons considérer le minimum des F reebandwidth l, LSP max (Le), r max (r) sur les intervals où InUse e (t) = 0 entre start et deadline. Cette fonction sup est en escalier et donne la limite supérieure de la taille du tunnel e. Définition 21 sup Pour une requête r et un tunnel candidat e qui utilise les tunnels/liens l de P, nous définissons pour t [start(r), deadline(r)], sup(t) = min({lsp (Le) max, r max (r)} l P {F reebandwidth l(t)}) si InUse e (t) = 0 et min( l P {F reen l(t)}) > 0 0 sinon Nous définissons également une fonction inf, donnant la taille minimum que le tunnel peut avoir si la requête est acceptée. Définition 22 inf Pour une requête r et un tunnel candidat e qui utilise les tunnels/liens l de P, nous définissons pour { t [start(r), deadline(r)], max({lsp (Le) inf(t) = min, r min(r)}) si InUse e (t) = 0 et min( l P {F reen l(t)}) > 0 0 sinon 22