Laboratoire de l’Informatique du Parallélisme

École Normale Supérieure de LyonUnité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL no 5668

Partage de bande passante et plande controle optique dans les grilles

Sebastien Soudanencadre parPascale Primet

Fevrier–Juin 2006

Rapport de Master 2 Informatique Fondamentale No DEA2006-01

École Normale Supérieure de Lyon46 Allée d’Italie, 69364 Lyon Cedex 07, France

Téléphone : +33(0)4.72.72.80.37Télécopieur : +33(0)4.72.72.80.80

Adresse électronique : lip@ens-lyon.fr

Partage de bande passante et plan de controle optique dans les

grilles

Sebastien Soudan

Fevrier–Juin 2006

Abstract

In this report, we consider the problem of bandwidth sharing in grid’snetworks. Unified control plane allows creation of bandwidth guaranteedtunnels across optical core network and Ethernet local network. Westudie how they can be used in grids. This report proposes a modelfor such networks and studies the problem of bandwidth sharing withbulk data transfers. Several allocation algorithms based on QoS routingworks are proposed and compared.

Keywords : grid, bandwidth sharing, GMPLS, unified control plane

Resume

Dans ce rapport, nous nous interessons au probleme de partage de bandepassante dans les reseaux de grilles. Le concept de plan “controle” unifiepermet la creation et la reservation de tunnels a bande passante garantieau travers des reseaux locaux Ethernet et des reseaux de coeur optique.Nous etudions comment il peut etre utilise dans les reseaux de grilles.Ce rapport propose une modelisation integrant les particularites de cetteapproche ainsi que l’etude du probleme de partage de bande passantepour les transferts de fichiers massifs dans ce modele. Plusieurs algo-rithmes d’allocation bases sur les travaux de QoS routing sont proposeset compares.

Mots-cles : grille, partage de bande passante, GMPLS, plan “controle” unifie

Table des matieres

1 Contexte et etat de l’art 41.1 Partage de bande passante dans les grilles . . . . . . . . . . . . . . . . . . . . . . 41.2 Evolution des reseaux de grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Plan “controle” unifie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 A qui appartiennent les ressources ? . . . . . . . . . . . . . . . . . . . . . 71.2.3 Systemes de reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Problematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Modelisation d’une interconnexion flexible de grille 92.1 Contexte du modele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Modele propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Elements du modele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Utilisation des liens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Dependances entre les tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.5 Utilisation des tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.6 Contraintes de faisabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Partage de bande passante dans le cas de transferts massifs 193.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Modelisation des requetes et formulation du probleme . . . . . . . . . . . . . . . 19

3.2.1 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 Formulation du probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 Etat de l’art sur le partage de bande passante . . . . . . . . . . . . . . . . 21

3.3 Objectif et flexibilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Simulations et analyses des resultats 254.1 Gsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Conclusions et perspectives 28

2

Table des figures

1 Exemple de LSP utilisant d’autres LSP dans un reseau heterogene muni d’unplan “controle” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Exemple de reseaux disposant de plusieurs couches de routage . . . . . . . . . . . 93 Layer(1) de StarPlane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Grandeurs associees a la definition d’un tunnel dans un autre . . . . . . . . . . . 125 Exemple de TE-LSP disponibles dans une couche et utilisant des liens/tunnels

d’une couche inferieure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Dependances entre liens/tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Contraintes de tailles sur les tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 168 Couche 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Couche 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1810 Couche 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811 Graphe de dependance des tunnels entre les noeuds 13 et 18 . . . . . . . . . . . . 1812 Requetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013 Zone dans laquelle la requete peut etre allouee . . . . . . . . . . . . . . . . . . . 2314 Couche 1 de G-lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2715 Couche 2 de G-lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2716 Comparaison entre les ratios de requetes acceptees de ODS RMAX et ODS RMIN 2817 Difference entre le ratio de requetes acceptees avec des allocations sur rmin et rmax 2818 Ratio de requetes acceptees pour les algorithmes allouants sur rmin . . . . . . . . 29

Liste des tableaux

1 Systemes de reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Requetes/Reponses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Liste des algorithmes

1 Algorithme STATIC RMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Algorithme MODS RMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3

Introduction

L’apparition de plan“controle”unifie autorisant la creation de tunnels a la demande dans desreseaux heterogenes par leurs technologies permet d’envisager la mise en place d’infrastructurede reservations de ressources dans les grilles. Plusieurs solutions ont ete proposees dont DRA-GON12 un projet NSF fonde sur GMPLS3, le plan de controle propose par l’IETF4, qui semblele plus prometteur. Cependant bien que DRAGON propose de la reservation en avance, il nepermet que de specifier un ensemble de circuits que l’on souhaite reserver et non des reservationsadaptees aux transferts de fichiers. Reservations dans lesquels c’est le volume de donnees a trans-ferer, la date a partir de laquelle le transfert peut commencer et la date a laquelle le transfertdoit etre fini. Elles nous semblent interessantes car elles permettent a l’utilisateur de specifierson besoin tout en nous laissant une certaine flexibilite qui permet d’optimiser l’allocation deces transferts.

La suite de ce rapport est consitute ainsi : Dans la premiere partie, nous presenterons lecontexte et l’etat de l’art, c’est a dire les evolutions des besoins et celles des reseaux de grilles.La seconde partie presente le modele de reseau que nous avons cree et sur lequel nous nousbasons. La troisieme partie presente le probleme et les algorithmes developpes. La quatriemepartie presente des simulations de ces algorithmes avant de conclure et d’exposer les perspectivesde ce travail.

1 Contexte et etat de l’art

Le contexte de ce rapport est celui des reseaux utilises pour interconnecter les nœuds dansles grilles de calculs. Il convient tout d’abord de donner une breve definition de ce qu’est unegrille. Pour cela nous utiliserons celle que donne Ian Foster dans [FKT01] : “The grid conceptis coordinated resource sharing and problem solving in dynamic, multi-institutional virtualorganization.” . A l’heure actuelle, les aspects dynamiques et multi-institutionels des grilles ensont a leurs debuts. Cependant la generalisation des plans de controle unifies comme GMPLS,pourrait contribuer a cela en permettant d’interconnecter a la demande des sites eventuellementdetenus par des institutions differentes.

1.1 Partage de bande passante dans les grilles

Les grilles que nous considerons sont des infrastructures composees de ressources de calcul,de stockage et de communications dediees au calcul haute performance. Dans ce contexte, lesreseaux consideres sont les reseaux “locaux” qui interconnectent les ressources sur un meme siteainsi que ceux qui interconnectent les sites entre-eux. Dans les grilles existantes actuellement, lespremiers sont typiquement des reseaux gigabits/s Ethernet (a commutation de paquets) et lesseconds des reseaux MPLS5 (a commutation de circuits virtuels) dans des reseaux de rechercheou des fibres eclairees specifiquement pour cette grille dans lesquelles transite de l’Ethernet giga-bits/s ou 10 gigabits/s. Les reseaux locaux dans les grilles sont souvent secondes par un reseaufaible latence (Myrinet, SCI, Infiniband, . . . ) mais nous ne nous y interesserons pas dans cerapport. Les topologies de ces reseaux sont actuellement tres statiques et les operations d’ajoutde connexions entre sites peuvent prendre plusieurs mois en partie parce que la configurationdes equipements doit etre faite a la main sur tous les equipements concernes.

1Dynamic Resource Allocation via GMPLS Optical Networks2http://dragon.maxgigapop.net/3Generalized Multi Protocol Label Switching4http://www.ietf.org5Multi Protocol Label Switching

4

Internet ne permet pas actuellement de reserver de la bande passante. Diverses proposi-tions [XN99] comme DiffServ et IntServ n’ont pas abouti dans ce contexte. Cependant, lesgrilles ont pour objectifs de repondre a des besoins importants en terme de calculs et de quan-tite de donnees traitees comme dans le projet du CERN LHC Computing Grid6. Ce projet abesoin de transferer des quantites importantes de donnees afin que celles-ci soient traitees avantd’etre stockees sur des ressources de stockage presentent sur le reseau. De ce fait les besoins degarantie sur les parametres de qualite de service reseau sont plus marques, car le fait de ne passavoir quand un tansfert sera fini empeche de pouvoir determiner quand on pourra commencerun calcul. De plus, les approches de partage de bande passante utilisee sur Internet avec TCPcherchent l’equite du partage de la bande passante. Ce n’est pas ce que l’on recherche dans lesgrilles ou l’on recherche la garantie de disposer de ce que l’on a reserve. Dernier point, les inter-faces disponibles sur les machines ont des bandes passantes de 1 a 10 gigabits/s alors que les liensdes reseaux locaux ont des bandes passantes de 1 a 10 gigabits/s et ceux des reseaux de cœursde 1 a 40 gigabits/s. Le nombre de flux simultanes necessaires pour congestionner un lien esttres faible par rapport a Internet et les congestions peuvent avoir lieu partout dans le reseau. Ona donc besoin de reservations de bout en bout y compris dans le reseau local et ces reservationsdoivent pouvoir etre faites en avance comme le sont les ressources de calcul [FFR+04].

1.2 Evolution des reseaux de grilles

1.2.1 Plan “controle” unifie

L’apparition du concept de plan “controle” unifie est sans doute une evolution plus remar-quable que l’augmentation perpetuelle des debits. Plan“controle”est une terminologie provenantdes reseaux de transport et de la decomposition des fonctionnalites necessaires dans ceux-ci. Ondistingue quatres plans :

– le plan “gestion” (Management plane) est responsable des activites de gestion de reseaucomme la collecte des informations sur les trafics,

– le plan “signalisation” (Signaling plane) permet la creation de nouveaux chemins,– le plan “routage” (Routing plane) assure la diffusion des informations de connectivite,– le plan “donnees” (Data plane) assure la transmission des donnees.

.Avant l’apparition des plans“controle”unifies, l’etablissement d’une nouvelle connexion dans

un reseau de transport necessitait de passer par les interfaces d’administration (qui peuvent etredifferentes) de chaque equipement. L’unification permet de faire automatiquement la configura-tion des equipements par le biais de protocoles standardises. Cela facilite pour les operateurs lesoperations de reconfiguration du reseau lors des changements de matrices de trafic afin d’opti-miser l’utilisation des ressources. Ces operations sont nommees Traffic Engineering. C’est pourcela que les plans “controle” unifies ont ete crees. Cependant il devient egalement envisageablede donner acces a ce plan aux utilisateurs ce qui leur permettrait d’agir sur le reseau et sur leschemins qu’empruntent leurs flux.

Il existe plusieurs solutions de plan“controle”, nous pouvons noter celui de l’IETF : GMPLS7,celui de l’ITU89 : ASON10 et celui de CA*net411, le reseau de recherche canadien : UCLP12.

6http://lcg.web.cern.ch/LCG/7Generalized Multi-Protocol Label Switching8International Telecommunication Union9http://www.itu.int/

10Automated Switched Optical Network11http://www.canarie.ca/canet4/12User Controlled LightPath

5

GMPLS [Man04] est une suite de protocoles issue de l’evolution de MPLS, de la prise encompte et de l’unification des differents modes de commutation que l’on rencontre dans lesreseaux : multiplexage spatial (choix physique d’une fibre par exemple), de longueur d’onde(selection d’une longueur d’onde dans une fibre), temporel (selection d’un slot dans une trameSONET), de paquets. En tant qu’evolution de MPLS, dans les reseaux GMPLS, le routage esteffectue sur des labels (label switching) et non sur une adresse IP de destination prise dansl’en-tete des paquets. Cela permet d’etre plus rapide puisque la decision de routage dependdirectement du label. On evite ainsi le Longest Prefix Match necessaire dans le cas du routageIP.

GMPLS est compose de trois parties : gestion des liens, routage et signalisation. Le role de lapremiere est d’echanger des informations sur les capacites des extremites d’un lien entre les deuxrouteurs qui composent ce lien (longueurs d’onde utilisables par exemple) ainsi que la detectiondes pannes. La deuxieme s’occupe d’echanger les informations permettant de prendre une deci-sion de routage : annonce des liens, de leurs bande passantes disponibles, de leur “longueurs” etde leur type de multiplexage. Enfin la troisieme partie permet de configurer les routeurs pourqu’il puisse acheminer des donnees sur un chemin (LSP13) particulier dont la bande passante estreservee dans chaque routeur qu’il traverse. Les protocoles realisant les deux dernieres partiessont respectivement OSPF-TE [KR05] et RSVP-TE [KL04] qui sont des extensions de OSPFet RSVP.

L’etablissement d’un nouveau chemin dans un reseau utilisant GMPLS necessite donc d’ecou-ter les annonces de liens (TE-Link) faites par OSPF-TE, de calculer le chemin que l’on veut etenfin 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 meme type demultiplexage. D’autre part, il est possible de creer un LSP et de l’annoncer ensuite comme unlien disponible par OSPF-TE. Ce lien est alors un TE-LSP et pourra etre utilise par un autreLSP plus tard. Il est donc possible de faire passer au travers d’un reseau tel que celui de lafigure 1 des LSP dans d’autres LSP a condition de respecter une hierarchie entre les types demultiplexage qui decoule de ce que l’on sait encapsuler dans un autre multiplexage. Il est parexemple possible d’encapsuler des paquets Ethernet dans une longueur d’onde d’une fibre maisle contraire ne l’est pas. GMPLS offre egalement d’autres possibilites que nous avons passeessous silence comme la protection des liens, la detection de pannes.

Si nous revenons au cadre des grilles, en faisant l’hypothese que le reseau d’interconnexiondes sites utilise GMPLS, il serait possible d’etablir de nouveaux liens entre des sites et donc demettre a disposition des utilisateurs plus de ressources quand ceux-ci en ont besoin. Le “quand”reste a definir mais nous voyons que GMPLS apporte une certaine flexibilite dans la gestion desressources reseaux disponibles. Il y a cependant des limitations dans l’etat actuel de GMPLS.L’article [VZH06] en identifie plusieurs dont l’impossibilite de faire des reservations en avanceet les problemes de la gestion des autorisations qui ne sont pas pris en compte. Le premierprobleme est traite dans un Network Ressources Manager charge de plannifier l’utilisation dureseau dans plusieurs propositions d’infrastructure de reservation de ressources reseaux pourgrille dont DRAGON. Le second probleme est un probleme de modele economique de reseauxet plus generalement de grilles : qui possede les ressources ? Ce probleme se retrouve dans ladefinition et la mise en place d’interface entre l’utilisateur et le reseau : UNI14, et entre deuxreseaux : NNI15.

13Label Switched Path14User to Network Interface15Network to Network Interface

6

Fig. 1 – Exemple de LSP utilisant d’autres LSP dans un reseau heterogene muni d’un plan“controle”

1.2.2 A qui appartiennent les ressources ?

La question de savoir a qui les ressources appartiendraient dans une grille commerciale estassez delicate car pour l’instant les grilles existantes sont majoritairement dans les reseaux derecherche.

Nous pouvons neanmoins envisager plusieurs cas :– les ressources d’interconnexion sont louees a un operateur et les operateurs de la grille ou

les utilisateurs finaux ne disposent d’aucun controle dessus,– l’operateur autorise a allouer dynamiquement dans son reseau des tunnels entre les sites,– les ressources d’interconnexion appartiennent aux operateurs de la grille.Le premier cas correspond au modele actuel de location de bande passante pour Internet.

A premiere vue le second cas est problematique car les operateurs n’ont pas pour habitude dedonner du controle sur leurs reseaux aux utilisateurs. Cependant plusieurs propositions tellesque les L1VPN [FB05, Chapitre 12] permettent d’envisager que l’operateur puisse fournir uncontrole limite sur une partie de ses ressources. Nous pouvons ainsi envisager de negocier avecl’operateur un ensemble de ressources que nous pouvons utiliser pour signaler des tunnels. Cesressources peuvent etre virtuelles dans le sens ou il ne s’agit pas de ressources physiques maisde ressources que l’operateur s’engage a approvisionner en fonction d’un contrat entre lui etson client [DGG+99]. Enfin dans la derniere solution, chaque site dispose de ses propres fibresl’interconnectant avec les autres. Dans ce modele il n’y a plus d’operateur mais eventuellementdes loueurs de fibres noires. Chaque site est alors operateur de ses propres fibres. C’est le modelepropose dans [WSC+05] et mis en place dans CA*net4.

Il ressort de ce panorama que plusieurs modeles sont possibles. Tous ont en commun unetendance marquee vers l’augmentation du controle dont dispose les utilisateurs et de la quantited’information dont celui-ci dispose pour pouvoir faire ce controle. Cette etude se place dans lesdeux derniers cas. Dans la suite, nous supposons disposer de ressources que l’on controle, queces ressources soient des ressources physiques ou virtuelles.

1.2.3 Systemes de reservation

Plusieurs propositions d’infrastructures de reservations de ressources reseaux ont ete faites.Toutes ne sont pas specifiques aux grilles et ne sont pas orientees reseaux utilisant GMPLS. Le

7

DRAGON GARA DWDM-RAM G-Lambda CHEETAHMulti-Domaines oui oui non non non

Reservations en avance oui oui oui oui nonPlan “controle” GMPLS DiffServ ODIN et GMPLS GMPLS GMPLS

Requetes Circuits Trafics Diffserv Circuits Circuits Circuits

Tab. 1 – Systemes de reservation

tableau 1 compare quelques unes de ces solutions.DRAGON16 est un projet qui a pour but de creer une infrastructure de reservation de bout

en bout dans des reseaux bases sur GMPLS. DRAGON propose d’utiliser des VLAN Ethernetpour realiser des tunnels dans le reseau d’un site. Grace a un equipement (VLSR17) qui configureles switchs, l’infrastructure de DRAGON est capable de contourner le routage (Spanning Tree)d’Ethernet. On se retrouve donc dans le reseau local dans une situation tres proche de celled’un reseau de cœur optique dans lequel on peut choisir egalement son chemin. DRAGONpropose un service appelle NARB18 charge de recevoir les informations de routage par OSPF-TE, de signaler les tunnels par RSVP-TE pour les clients finaux (machines) qu’il representeet d’echanger les informations sur la disponibilite des ressources avec ses homologues dans lesautres sites. DRAGON permet la reservation a l’avance de topologies avec des bandes passantesdefinies. En revanche il ne permet pas d’ordonnancer des transferts de fichiers massifs specifiespar le volume.

Nous allons a present comparer quelques grilles et leurs reseaux.DAS3, la grille de recherche hollandaise, repose sur une infrastructure optique Starplane19

fournie par SURFnet6. DAS3 est composee de quatres sites sur un anneau de fibres pouvantcontenir huits longueurs d’onde. Les longueurs d’onde permettent d’acheminer de l’Ethernet 10gigabits/s d’un site a un autre. L’acces au plan “controle” s’effectue par le Network OperationCenter de SURFnet6. G-lambda20 est une grille japonnaise utilisant GMPLS. Elle est composeede six sites, six routeurs optiques disposes en anneaux et chaque fibre transporte entre deux ettrois longueurs d’onde. Grid500021 est la grille de recherche francaise, les interconnexions entreles sites sont fournies par Renater4 et a terme devraient etre des liens 10 Gigabits/s Ethernet.Aucun controle de la part des utilisateurs n’est possible sur le reseau de cœur et la topologieest un arbre.

On retiendra de cela que le nombre des sites est inferieur a dix, et que le nombre de longueursd’onde ne permet pas d’allouer un circuit entre chaque paire de sites.

1.3 Problematique

Dans les sections precedentes, nous avons montre qu’aujourd’hui emergent des mecanismespermettant d’allouer des ressources reseaux a la demande grace aux plans “controle” unifies etautomatises comme GMPLS. De plus, nous avons vu qu’il est possible de faire de la reservationen avance et ce de bout en bout (dans le reseau de cœur optique et dans les reseaux Ethernetdes sites) grace a des systemes comme DRAGON par exemple. Le probleme que nous nous

16Dynamic Resource Allocation via GMPLS Optical Networks17Virtual Label Switching Router18Network Aware Resources Broker19http://www.starplane.org/20http://www.g-lambda.net/21http://www.grid5000.fr/

8

posons dans cette etude est donc d’analyser comment cette flexibilite offerte par ces nouvellesinfrastructures de controle des reseaux permet d’optimiser l’utilisation des ressources reseauxet de satisfaire les attentes des utilisateurs. Cette etude se decompose en deux parties.

Dans la premiere partie nous proposons une modelisation de l’interconnexion flexible degrille et une modelisation des requetes des utilisateurs. Nous identifions ensuite les problemesd’allocation et d’optimisation sous-jacents.

Dans la seconde partie, nous proposons quelques heuristiques pour resoudre le probleme duroutage et du partage de bande passante. Nous analysons ensuite les resultats de ces algorithmespar simulation en utilisant des exemples d’interconnexions existantes.

2 Modelisation d’une interconnexion flexible de grille

2.1 Contexte du modele

Nous voulons modeliser un reseau a I > 0 couches dans lequel il faut faire une hierarchie detunnels (TE-LSP) dans les couches inferieures avant de pouvoir y faire passer du trafic lui memedans un tunnel (LSP). Il s’agit de modeliser un reseau utilisant GMPLS pour lesquel DRAGONpropose une infrastructure permettant la reservation en avance. Pour cela, nous allons utiliserun multigraphe Layer(i) pour representer les ressources de la couche i. Ces reseaux peuventetre vus comme des reseaux disposant de plusieurs couches dans lesquels nous pouvons choisirla route que nous voulons emprunter.

Fig. 2 – Exemple de reseaux disposant de plusieurs couches de routage

Sur la Figure 2 nous avons en rouge les routeurs, en blanc les noeuds realisant les extremitesdes tunnels et en bleu et jaune deux “chemins” au travers de ces couches. La couche la plushaute ne contenant que les machines n’est pas representee.

Dans la suite, nous faisons plusieurs hypotheses. Nous supposons d’abord que les liens sontsymetriques (meme bande passante dans les deux sens), il s’agit d’une des hypotheses de GM-PLS. La couche la plus haute (I) ne contient que des extremites de tunnels (TermUp), ce sontles machines des sites. Enfin les tunnels ne sont pas bifurques, c’est a dire qu’un tunnel ne passeque par un seul chemin dans le reseau.

9

2.2 Modele propose

2.2.1 Elements du modele

La modelisation du reseau fait intervenir des nœuds de natures differentes permettant ainside differentier les fonctions realisees par ces differents types de nœuds.

Definition 1 Nodes

Ce sont les nœuds du reseau. Ils sont en nombre fini et nous les identifierons par un entier.

Le premier type specialise de nœud est celui des routeurs. Il n’est relie qu’a des nœuds desa couche.

Definition 2 Routers(i)

Ce sont les routeurs de la couche i du reseau. C’est une partie de Nodes.

Pour modeliser les extremites des tunnels, nous avons recours a deux ensembles par couche.Cela nous permet de differentier les nœuds qui sont point d’entree vers un tunnel dans unecouche inferieure et les nœuds qui sont point d’entree pour une couche superieure dans untunnel qui est realise dans la couche consideree.

L’ensemble contenant les premiers nœuds pour la couche i est nomme TermUp(i) et celuicontenant les seconds est nomme TermDown(i).

Definition 3 TermDown(i)

C’est l’ensemble des nœuds qui permettent de faire des tunnels dans la couche i pour unecouche superieure. C’est une partie de Nodes. Ces nœuds realisent des terminaisons de tunnelset modelise la capacite d’adaptation qu’ont les equipements qui permettent d’encapsuler le traficd’une couche (d’un multiplexage) dans des tunnels d’une autre couche.

Definition 4 TermUp(i)

C’est l’ensemble des nœuds qui permettent a la couche i d’acceder a des tunnels des couchesinferieures. C’est egalement une partie de Nodes.

Soit x appartenant a Nodes, il existe au plus un seul couple d’entier (i, j) (avec 1 ≤ i < j ≤I) tel que x appartient a TermUp(j) ∪ TermDown(i).

Nous imposons egalement que TermUp(1) soit vide. La couche 1 est la plus basse, elle nepeut utiliser de tunnels dans les couches inferieures. La figure 3 represente la couche 1 du reseauStarPlane. Similairement, la couche I ne contient que des nœuds de type TermUp..

Voici la definition d’une couche i :

Definition 5 Layer(i)

C’est un multigraphe G dont les aretes sont ponderees. Il represente la couche i du reseau.G = (V,E, Nmax, Bandwidth)tel que :– V = Routers(i) ∪ TermDown(i) ∪ TermUp(i)

– E est le multi-ensemble des aretes (TE-links)– Si v ∈ V \Routers(i) alors deg(v) = 1– Nmax : E → N– Bandwidth : E → RNmax(e) est le nombre de tunnels que nous pouvons faire a l’interieur du lien e et Bandwidth(e)

est la taille du lien e. Il s’agit de donnees decrivant les liens physiques disponibles.

10

La taille des tunnels que nous pouvons faire dans un autre tunnel ou lien est contrainte par leparadigme de commutation utilise. Dans le cas ou il s’agit de commutation de longueur d’onde,par exemple, la taille d’une longueur d’onde est fixee a une certaine valeur. Nous utilisons deuxvariable LSP

(i)min et LSP

(i)max comme bornes pour les tailles possibles des tunnels.

Definition 6 LSP(i)min et LSP

(i)max

Nous definissons deux valeurs (reelles) 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 modele car il s’agit normalement d’une propriete de chaque TE-

link.

Le choix de la taille lors de la creation d’un tunnel est soumis a plusieures contraintes. Surla figure 4, nous pouvons voir que le choix de la taille Bandwidth d’un nouveau tunnel dans unautre lien ou tunnel doit etre comprise entre LSPmin et LSPmax, et doit etre plus petite queFreeBandwith, la bande passante disponible. Nous reviendrons sur les contraintes plus tarddans ce rapport.

Fig. 3 – Layer(1) de StarPlane

Definition 7 TE-links(i)

Pour tout 1 ≤ i ≤ I, TE-links(i) est l’ensemble des triplets (e, Nmax(e), Bandwidth(e))pour tout e appartenant a l’ensemble des aretes du Layer(i).

11

Fig. 4 – Grandeurs associees a la definition d’un tunnel dans un autre

2.2.2 Utilisation des liens

Les liens (TE-links) que nous venons de definir vont etre utilises pour creer des tunnels,il va donc nous falloir definir des fonctions donnant les ressources disponibles dans ces liens.Ces ressources sont la bande passante disponible (FreeBandwidth) et les labels disponibles(FreeN). Pour cela, nous allons utiliser deux fonctions en escalier pour chaque lien e. Le choixdes fonctions en escalier se justifie par le fait que l’on ne peut changer la bande passante d’untunnel alloue de maniere continue, ce changement necessite la signalisation de ce changementsur le chemin (par RSVP-TE par exemple).

Definition 8 FreeBandwidth et FreeNSoit e un lien, c’est a dire une arete d’un des Layer(i),FreeBandwidthe est une fonction en escalier du temps (R+) dans R et FreeNe est une

fonction en escalier du temps (R+) dans N. FreeBandwidthe(t) correspond a la bande passantenon utilisee dans le lien a l’instant t, et FreeNe(t) au nombre de labels non utilises a ce memeinstant.

2.2.3 Tunnels

A present nous disposons d’un modele pour les TE-links, c’est a dire une partie des ressourcesdisponibles dans une couche pour etablir des circuits, l’autre partie de ces ressources provientdes tunnels que l’on peut creer dans les couches inferieures. Ces tunnels peuvent utiliser des liensou des tunnels des couches inferieures comme le schematise la figure 5. C’est ce que nous allonsdefinir maintenant. Dans la suite nous ne ferons pas de difference entre le LSP et le TE-LSPcar dans la nomenclature GMPLS, les TE-LSP sont des LSP qui sont annonces par OSPF-TEet qui peuvent donc etre reutilises par d’autres tunnels.

Les TE-LSP ont les memes proprietes que les TE-links, c’est a dire (Nmax, Bandwidth).Cependant elles dependent pour une part des liens (TE-links et TE-LSP) utilises pour lesrealiser dans les couches inferieures et d’autre part de proprietes de leurs points d’extremites :les TermUp(i). Ce sont les extremites qui determinent comment elles vont pouvoir decouperle tunnel pour faire passer les tunnels des couches superieures. Nous noterons egalement que

12

Fig. 5 – Exemple de TE-LSP disponibles dans une couche et utilisant des liens/tunnels d’unecouche inferieure

contrairement aux liens, la bande passante d’un tunnel est une fonction du temps puisqu’untunnel est signale22 pour un certain temps.

La bande passante maximum utilisable (Bandwidth) provient des liens supportant les TE-LSP alors que les autres proprietes proviennent des nœuds d’extremite. Pour simplifier la mo-delisation, nous supposerons que les proprietes des TE-LSP dependantes des TermUp(i) sontidentiques dans une couche et donc ne dependent que de i. Nous les noterons N

(i)max, LSP

(i)min et

LSP(i)max.

Dans les approches classiques d’allocations de bande passante sur un reseau multicouche [PM04],les requetes des couches superieures sont agregees et servies par des liens virtuels entre les pointsd’acces aux couches inferieures et ces liens deviennent alors des demandes pour ces couches. Dansnotre cas, nous souhaitons pouvoir choisir parmi plusieurs chemins dans les couches inferieurescar nous ne voulons pas decouper une requete sur plusieurs chemins et ne savons pas agregerles chemins pour n’en faire qu’un. Il nous faut donc remonter les chemins possibles vers lesdemandes afin de pouvoir les selectionner pour servir les requetes.

Nous allons construire l’ensemble des tunnels que l’on peut faire dans une couche en utilisantcelles du dessous. Dans un premier temps, nous ne nous preoccuperons pas des problemes debande passante.

Definition 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 numero de la couche dans laquelle se trouvent les liens que le tunnel

utilise)– s est un element de TermUp(i) ∩ TermDown(j),– d est un element de TermUp(i) ∩ TermDown(j) distinct de s,– P est une chaine elementaire entre s et d dans Layer(j) auquel nous avons ajoute des

aretes entre deux nœuds de TermUp(j) s’il existe un tunnel dans TE-LSPs(j) les reliant– n est un entier compris entre 1 et Np = mine∈P ({Nmax(e)}) (ou si e est un tunnel de la

couche k, Nmax(e) = N(k)max). n represente le label GMPLS du TE-LSP.

Pour chaque pair de nœuds de TermUp(i), nous avons un nombre p de chemins, et surchaque chemin Nm (avec 1 ≤ m ≤ p) TE-LSP.

Dans la suite, nous identifierons chacun de ces tunnels par un entier e unique et distinctdes representants des aretes des Layer(i). De plus, nous noterons Le la couche dans laquelle letunnel e est realise (i.e, le j de la definition).

22cree

13

Definition 10 _Nous noterons l _ e si le tunnel e utilise le tunnel (ou le TE-link) l.

Definition 11 TE-LSPsTE-LSPs =

⋃1≤i≤I

TE-LSPs(i)

Nous avons egalement besoin de definir la taille Bandwidth de ces tunnels, cette fois il s’agitd’une fonction en escalier du temps. Il en est de meme pour les fonctions en escalier FreeN etFreeBandwith.

Definition 12 Bandwidthe, FreeNe et FreeBandwithe

Pour 1 ≤ i ≤ I,Soit e une arete de Layer(i) ou un tunnel de TE-LSPs(i), nous definissons sa taille par la

fonction en escalier Bandwidthe : R+ → R+, son nombre de labels disponibles par la fonctionen escalier FreeNe : R+ → N et sa bande passante disponible FreeBandwidthe : R+ → R+

dont nous donnerons une expression dans la definition 17.Pour le cas des liens, nous avons ∀t ∈ R+, Bandwidthe(t) = Bandwidth(e).

Tous ces tunnels ne sont pas realisables en meme temps et toutes les tailles de tunnel nesont pas accessibles. Il nous faut donc exprimer les conditions permettant de determiner si destunnels sont faisables. Tous les tunnels de TE-LSPs(i) sont faisables mais pas forcement en memetemps.

2.2.4 Dependances entre les tunnels

Nous avons vu dans la construction des TE-LSPs(i) que ceux-ci utilisent les TE-links et/oules tunnels des couches inferieures. Ces dependances peuvent etre traduites sous la forme d’ungraphe acyclique oriente. A partir de la relation “_”, nous definissons le graphe de dependancessuivant :

Definition 13 Dep

Pour 1 ≤ i ≤ I, nous noterons E(i) les aretes de Layer(i).Dep = (V,E) est le graphe de dependances des TE-LSPs tel que :– V = TE-LSPs ∪

⋃1≤j≤I

E(j)

– (e1, e2) ∈ E ssi e2 est dans TE-LSPs et e1 _ e2, c’est a dire que e2 utilise e1.Un exemple d’un tel graphe est represente sur la figure 6. Un tunnel de la couche 3 est realise

a partir de liens et/ou de tunnels d’une couche inferieure qui sont eux-meme realises a partirde liens de la couche 1.

Definition 14 Dependance entre e et l : δl,e

Soit e un entier representant un TE-LSP et l un entier representant un TE-LSP ou unTE-link,

δl,e ={

1 si l _ e0 sinon

14

Fig. 6 – Dependances entre liens/tunnels

2.2.5 Utilisation des tunnels

Nous avons besoin de pouvoir marquer un tunnel comme utilise afin d’exprimer des contr-aintes sur sa taille et sur le nombre de labels utilises dans un tunnel. Pour cela, nous definissonspour chaque tunnel et lien, une fonction du temps InUsee a valeurs dans {0, 1} qui vaut 0lorsque e n’est pas utilise, et 1 lorsqu’il l’est.

Definition 15 Contraintes de signalisation des tunnelsActivite des tunnels :

∀l ∈ TE-LSPs ∪ TE-Links,∀e ∈ TE-LSPs, δl,eInUsee ≤ InUsel (1)

2.2.6 Contraintes de faisabilite

Les contraintes de faisabilite 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 etre comprise entre LSP(Le)min et LSP

(Le)max si le

tunnel est utilise ;

3. la somme des tailles des tunnels contenus dans un TE-link ou dans un autre tunnel nedoit pas exceder celle de ce dernier.

La definition des TE-LSPs(i) ne suffit pas pour nous garantir que les contraintes sur lenombre de TE-LSP par rapport au Nmax sont verifiees. Il nous faut verifier explicitement quele nombre de labels utilises dans chaque tunnel et TE-Links est inferieur au nombre disponibleNmax.

Definition 16 FreeN

Soit l un lien ou un tunnel,FreeNl = Nmax(l)−

∑e∈TE-LSPs

δl,eInUsee

En ce qui concerne les contraintes d’utilisation des tunnels et des liens du point de vue de labande passante, nous allons definir FreeBandwidth afin de pouvoir exprimer le fait que nousne voulons pas que la somme des tailles des tunnels crees dans un lien ou tunnel soit plus grandeque la taille de ce tunnel comme le montre la figure 7.

15

Definition 17 FreeBandwidthl

Soit l un lien ou un tunnel,FreeBandwidthl = Bandwidthl −

∑e∈TE-LSPs

δl,eInUseeBandwidthe

Fig. 7 – Contraintes de tailles sur les tunnels

Les contraintes sont alors les suivantes :

Definition 18 Contraintes de faisabilites des TE-LSPCapacite des TE-link :

∀l ∈ TE-links, F reeBandwidthl ≥ 0 (2)

Capacite des tunnels :

∀l ∈ TE-LSPs, F reeBandwidthl ≥ 0 (3)

Taille des tunnels :

∀l ∈ TE-LSPs, InUselLSP(Ll)min ≤ Bandwidthl ≤ LSP (Ll)

max (4)

Nombre de tunnels :

∀l ∈ TE-LSPs ∪ TE-Links, F reeNl ≥ 0 (5)

2.3 Discussion

Les figures 8, 9, 10 et 11 donnent respectivement la description de la topologie des couches1, 2 et 3 d’un reseau tres simple ainsi que le graphe des dependances entre les tunnels possiblesentre les noeuds de la couche 3 : 13 et 18 ou nous n’avons garde qu’un tunnel pour representertous les tunnels qui ne different que par leur label n. Les etiquettes sur les aretes contiennentdans le cas d’un lien, le nombre de labels maximum et la bande passante, et dans le cas d’untunnel, le label de ce tunnel, le nombre de labels disponibles et la bande passante.

Sur les trois premieres figures, les elements nommes Router sont en rouge, en bleu sont lesTermDown et en vert les TermUp. Ces deux derniers elements sont les extremites des TE-LSPs

16

(en bleu) et les TE-Links sont en rouge. Chaque arc est etiquete par trois valeurs : le numerodu 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 lienset des tunnels entre les noeuds verts de cette couche. Les TermUp (en vert) de la figure 9correspondent aux TermDown (en bleu) de la figure 8 et les tunnels (en bleu) sont constituesde liens de la couche 1. De meme, les TermDown de la couche 2 correspondent aux TermUpde la couche 3 et les tunnels presentes dans cette derniere couche sont realises par les liens ettunnels accessibles dans la couche 2.

La figure 11 represente les dependances entre les differents tunnels et liens. Cette structuredevient rapidement tres importante. Cependant, nous n’avons pas besoin de differencier lestunnels de la couche 3 qui utilisent les memes chemins et comme nous le verrons par la suite,l’etat du reseau dont nous avons besoin pour allouer une nouvelle requete ne requiert pas deconnaıtre tous les tunnels de la couche 3, et nous pouvons utiliser l’information agregee dansles fonctions d’etat FreeN et FreeBandwidth des liens et tunnels des couches 1 et 2.

17

Fig. 8 – Couche 1

Fig. 9 – Couche 2

Fig. 10 – Couche 3

Fig. 11 – Graphe de dependance des tunnelsentre les noeuds 13 et 18

18

Requetes Reponses Utilisation Article(Date de debut, {(Debit,Source, Destination),. . . })

{LSP, . . . } Generique [LSJ06]

(Volume, Debit max,Date de debut, Source,Destination)

{(Debut, Debit, Fin),. . . }

Transfert de fichiers [VZcF+03]

(Debit, Date de debut,Source, Destination)

(Debit) Requete de longue duree

(Volume, Debit max,Date de debut, Date defin, Source, Destination)

(Debut, Debit, Fin) Reservation de courteduree

[VBZ05]

Tab. 2 – Requetes/Reponses

3 Partage de bande passante dans le cas de transferts massifs

3.1 Contexte

Maintenant que nous disposons d’un modele pour decrire un reseau, nous allons etudiercomment allouer des requetes de transfert de fichiers dans une grille similaire a G-lambda (lagrille japonaise) du point de vue de sa topologie.

Nous nous restreignons donc a un reseau a trois couches, la couche 1 est le reseau optique,la couche 2 correspond a la couche Ethernet et la couche 3 represente les machines et les LSPutilises pour servir les requetes que nous allons decrire dans la section suivante. Nous disposonsdans cette situation de deux niveaux de granularite pour servir les requetes, d’une par la creationde tunnels optiques et d’autre part la creation de tunnels Ethernet dans les tunnels optiques.Sur les premiers, nous ne disposons pas du choix de la bande passante (LSPmax = LSPmin)alors que sur les seconds il n’y a pas de contraintes particulieres en dehors de la bande passantedisponible dans les liens et tunnels utilises.

Notons que nous laissons de cote les aspects concernant l’interface entre les applications oules machines et le NRM23 ainsi que les problemes relatifs a la mise en place de limitations et decontrole du debit des flux Ethernet. En effet, nous voulons realiser des circuits dans un mondede paquets (Ethernet), il faut donc s’assurer qu’aucun des circuits de paquets ne depasse leslimites qui lui sont imposees pour ne pas perturber les autres flux en creant des congestionsdans les equipements. Dans la suite nous supposons que ces mecanismes sont mis en place.

3.2 Modelisation des requetes et formulation du probleme

3.2.1 Hypotheses

Comme le montre le tableau 2, plusieurs formats de requetes et de reponses ont ete proposes.Celui que nous allons retenir dans la suite repose sur la donnee d’un volume a transferer entreune source et une destination entre deux dates tout en utilisant une bande passante inferieurea une valeur donnee. Il s’agit du modele de requete utilise dans [VBZ05].

23Network Ressources Manager

19

Definition 19 RequeteNous definissons une requete r comme etant un 7-uplet (s, d, rmax, volume, start, deadline,

release) ou :– s est la source.– d est la destination,– rmax ∈ R est le debit maximum de la source,– volume ∈ R est le volume des donnees a transferer,– start est la date a partir de laquelle le transfert peut commencer,– deadline est la date a laquelle le transfert doit etre fini,– release est la date a laquelle la requete est transmise au systeme de reservation.

Dans le cas ou nous pouvons et decidons de servir cette requete, la reponse est un tunneld’une taille donnee plus petite que rmax, entre la source et la destination pendant une fenetrede temps comprise entre start et deadline, qui permet de faire passer la quantite de donneesvolume.

Definition 20 rmin

Nous definissons rmin(r) comme etant la bande passante qu’il faut allouer pour satisfaire larequete r si nous utilisons une bande passante constante entre start(r) et deadline(r).

rmin(r) =volume(r)

deadline(r)− start(r)

Une telle specification des requetes nous offre de la flexibilite sur la taille et les dates dedebut et de fin de signalisation des tunnels alloues pour servir ces requetes comme le montre lafigure 12. En se limitant a des solutions ou l’on sert la requete sur une bande passante constante,nous pouvons d’une part choisir le debit de service et d’autre part la date de debut et de fin. Onne s’interesse pas au cas ou la bande passante peut changer car cela suppose une reconfiguration(resignalisation) des tunnels.

Fig. 12 – Requetes

20

3.2.2 Formulation du probleme

Nous nous limitons a un schema d’ordonnancement ou nous traitons les requetes online etnous ne considerons qu’une requete a la fois, c’est a dire que nous traitons les requetes lorsqu’ellessont soumises au systeme de reservation.

Le probleme est donc de prendre la decision d’accepter ou de rejeter une requete et de luitrouver une place en fonction de l’etat que nous connaissons du reseau pendant la duree danslaquelle nous pouvons allouer cette requete (start, deadline) et des contraintes precedemmentmentionnees. Dans le cas ou nous acceptons une requete, la reponse du systeme de reservationest un quadruplet (date de debut reelle, date de fin reelle, debit, chemin) ou le “chemin” est untunnel de Layer(I). Nous nous limitons a regarder le cas ou la decision est prise au moment del’arrive de la requete dans le systeme. Nous pourrions envisager de prendre cette decision plustard (mais avant start).

L’etat du reseau qui nous interesse est celui entre la date de debut start et celle de findeadline d’une requete puisque c’est entre ces deux dates que la requete doit etre servie. Cetetat est l’ensemble des fonctions en escalier (FreeN , FreeBandwidth, InUse) des liens ettunnels du reseau sur l’interval de temps considere.

Par rapport a ce qui a ete etudie dans [VBZ05], le reseau de cœur n’est pas considere commesurdimensionne24, il nous faut donc considerer chacun de ses liens pour s’assurer qu’il n’y aitpas de congestion alors que dans l’article seul les deux liens d’acces des sites concernes par lesrequetes sont a considerer. D’autre part, nous considerons egalement les congestions possiblesdans les reseaux locaux aux sites et enfin nous pouvons creer dynamiquement de nouveauxtunnels entre des sites a condition de respecter les contraintes de nombre de labels, de bandepassante disponible et de taille des tunnels. Du fait que nous pouvons creer de nouveaux tunnelset que nous considerons les topologies des reseaux des sites, il est possible que nous ayons achoisir entre plusieurs chemins, ce qui n’etait pas le cas dans l’article precedemment cite. Noussommes donc face a un probleme a la fois de routage et d’ordonnancement.

3.2.3 Etat de l’art sur le partage de bande passante

Notre probleme de partage de bande passante, necessite a la fois de trouver un creneautemporel dans lequel la requete pourra etre servie et un chemin sur lequel elle pourra l’etre.Le premier probleme a ete etudie dans [CVB06] pour les reseaux de coeur surdimensione. Dansce cas, seuls les liens d’acces sont consideres 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 requete sur les deuxliens. Dans notre cas, il faut egalement calculer la route entre la source et la destination. On serapproche plus d’un probleme de “QoS routing” ou l’on cherche un chemin satisfaisant certainescontraintes et optimal suivant d’autres metriques. Ces problemes de routage ont largement eteetudies et [CN98] presente un etat de l’art des problemes et des solutions. Les problemes deroutage “link-constrained path-optimization” peuvent etre resolut par un “shortest-path” sur legraphe ou l’on a elimine les aretes ne satisfaisant pas les contraintes. Le fait de trouver le cheminle plus court dont tous les liens ont une bande passante disponible plus grande qu’une valeurdonnee est l’un de ces problemes. C’est a ce cas que nous allons nous ramener. La perspectived’utiliser le routage dans des problemes de reservations en avance a ete abordee dans [GO00]dans le cas ou le temps est discret.

24C’est a dire que nous ne considerons que les liens d’acces au cœur qui est alors assimilable a un seul routeurcentral dans un reseau a une seule couche de routage.

21

3.3 Objectif et flexibilite

Notre objectif est de maximiser le nombre de requetes acceptees. Nous ne cherchons pas aservir la requete au plus tot car nous supposons que le client nous a exprime ses contraintesdans la requete ou il aurait pu mettre une deadline plus tot au besoin.

Nous allons a present regarder les differents choix qui nous sont offerts. Dans cette partie,nous supposons que nous avons deja les tunnels candidats, c’est a dire les tunnels de la coucheI dont la source et la destination correspondent a celles de la requete. Nous nous preoccuperonsplus tard de savoir quels sont les tunnels candidats et comment les obtenir.

Le probleme est de construire la “zone” dans laquelle il est possible d’allouer une bandepassante pour notre requete, c’est a dire pour le tunnel qui pourrait potentiellement repondre ala requete. Nous faisons toujours l’hypothese que nous ne modifions pas les requetes precedem-ment allouees. Toutes les requetes precedentes sont agregees dans la bande passante utilisee destunnels, et nous ne disposons que de l’information vehiculee par FreeBandwidth.

Pour que nous puissions accepter une requete, il nous faut pouvoir modifier les fonctionsInUsee et Bandwidthe d’un tunnel candidat e de telle facon que les requetes precedentes nesoient pas touchees. Il faut pour cela que les fonctions ne soient modifiees que sur des inter-vals ou InUsee vallait 0 et que l’ajout d’un creneau a ces fonctions sur un interval [a, b] ⊂

[start, deadline] tel que∫ b

aBandwidthe(t) dt = volume soit possible en respectant les contr-

aintes mentionnees plus haut.Deux cas sont possibles. Dans le premier cas, les liens/tunnels utilises par le tunnel candidat

sont signales (InUse = 1) tout le temps entre start et deadline et dans le second, ce n’est pasle cas, il faut donc envisager de signaler un autre tunnel dans une couche inferieure et donc delui donner une taille.

Revenons au premier cas. Nous considerons un tunnel candidat e, dont l’ensemble des tun-nels qu’il utilise est P . Nous supposons que pour tout l de P , sur l’interval [start, deadline],InUsel(t) = 1. Dans ce cas, tous les tunnels de P sont signales et ont une taille, on ne peut pasles changer et elles sont correctes du point de vue des contraintes. De ce fait, les tunnels l deP ont une bande passante libre FreeBandwidthl qui est positive sur [start, deadline]. Afin dedeterminer la taille du tunnel e que nous pouvons utiliser pour (eventuellement) repondre a larequete, il nous faut regarder quelles sont les valeurs possibles. Pour cela nous allons considererle minimum des FreeBandwidthl, LSP

(Le)max , rmax(r) sur les intervals ou InUsee(t) = 0 entre

start et deadline. Cette fonction sup est en escalier et donne la limite superieure de la taille dutunnel e.

Definition 21 supPour une requete r et un tunnel candidat e qui utilise les tunnels/liens l de P , nous definis-

sons pour t ∈ [start(r), deadline(r)],

sup(t) =

min({LSP(Le)max , rmax(r)}∪⋃

l∈P {FreeBandwidthl(t)}) si InUsee(t) = 0 et min(⋃

l∈P {FreeNl(t)}) > 00 sinon

Nous definissons egalement une fonction inf , donnant la taille minimum que le tunnel peutavoir si la requete est acceptee.

Definition 22 infPour une requete r et un tunnel candidat e qui utilise les tunnels/liens l de P , nous definis-

sons pour t ∈ [start(r), deadline(r)],

inf(t) =

{max({LSP

(Le)min , rmin(r)}) si InUsee(t) = 0 et min(

⋃l∈P {FreeNl(t)}) > 0

0 sinon

22

Fig. 13 – Zone dans laquelle la requete peut etre allouee

Finalement, nous obtenons entre ces deux fonctions en escalier, la zone (partie non hachureedans la figure 13) dans laquelle peut se situer la taille du tunnel envisage pour servir la requete.

Il reste encore a verifier la contrainte∫ b

aBandwidthe(t) dt = volume. C’est a dire que nous

pouvons trouver une taille de tunnel sur un interval suffisamment long pour que la requetepuisse etre servie pendant ce temps.

Passons au second cas, c’est a dire celui ou nous devons choisir la taille d’au moins un destunnels servants a realiser le tunnel candidat considere et le signaler. Dans ce cas, determiner lestailles que nous pouvons donner a ce tunnel revient a considerer recursivement les tunnels quile compose (c’est a dire ses antecedents dans le DAG Dep) ainsi que les liens afin de determinerles tailles qui sont accessibles. Il reste neanmoins a fixer les tailles des tunnels avant la remontee.Nous pouvons envisager differentes strategies comme celle de prendre les plus grandes taillesdisponibles pour les tunnels mais l’impact de ces choix n’a pas encore ete investigue dans cetravail.

Les deux cas presentes precedemment supposent que nous connaissions un chemin sur lequelnous pouvons envisager de servir la requete. Ce choix est delicat. Si nous ne fixons pas la bandepassante sur laquelle nous voulons servir la requete (entre rmin et rmax) et les dates de debut etde fin reelles de service de la requete, nous ne pouvons pas eliminer a priori les aretes de notregraphe avant de calculer un chemin puisque c’est par rapport a sup et inf que nous pouvonssavoir si la requete peut passer ou pas. Ces deux fonctions dependent du chemin entier. Pourretomber dans un cas ou le calcul de chemin est facile, il nous faut donc fixer avant ce calculles dates reelles de debut et de fin ainsi que la bande passante. Nous envisagerons les deuxapproches extremes dans la partie suivante : allocation sur rmin et allocation sur rmax au debutde la fenetre [start, deadline].

Si nous resumons les points sur lesquels nous pouvons agir, nous avons le choix du chemin,la forme sur laquelle nous servons la requete, et le fait de signaler de nouveaux tunnels ou non.Dans la suite nous allons regarder les solutions dans lesquelles la forme des requetes que nousvoulons servir est fixee avant le routage puisque comme nous l’avons vu dans la section 3.2.3,le probleme de trouver le chemin le plus court dont la bande passante est plus grande qu’une

23

valeur donnee se resoud simplement.

3.4 Algorithmes

Nous nous placons dans le cas d’un reseau a trois couches (I = 3), c’est a dire avec deuxcouches dans lesquels nous pouvons faire du routage. Un exemple de tel reseau est G-lambdaou Starplane. Nous allons presenter plusieurs algorithmes qui seront compares dans la sectionsuivante. Ces algorithmes sont gloutons et s’inspirent de CSPF25, c’est a dire que nous eliminonsles aretes qui ne satisfont pas les contraintes avant de calculer le chemin le plus court dans legraphe resultant.

La reponse a une requete etant un chemin26 dans le graphe Layer(2), il nous faut connaıtreles liens et tunnels utilisables dans cette couche. Les liens sont connus mais les tunnels (TE-LSP) proviennent des chemins composes des liens de Layer(1). La couche 1 est composee depeu de liens, de routeurs, de noeuds de terminaison et de longueurs d’onde par liens dans lesreseaux de coeur de grilles, nous pouvons donc calculer tous les chemins possibles entre lesTermDown de la couche par un simple algorithme recursif qui calcule les chemins27 entre unnoeud (TermDown) et tous les autres. Il y en a 59 dans G-lambda et 96 dans Starplane. Nousconnaissons les deux couches basses de Dep mais nous devons encore calculer a la demande lesparties de la derniere couche dont nous avons besoin a partir de la couche 2.

Le premier algorithme suppose que les tunnels qui doivent etre signales dans Layer(2) ontdeja ete choisis (en fonction d’une matrice de trafic par exemple). Dans cet algorithme, nous netentons pas de signaler de nouveaux tunnels. La metrique utilisee pour le SPF est le nombre desauts.

Algorithme 1 Algorithme STATIC RMAX

Entrees: r = (s, d, rmax, volume, start, deadline) une requeteEntrees: Layer(2), Layer(1).Sorties: Si la requete est acceptee, (date de debut reel du transfert, date de fin effective, debit),

et les Layer(2), Layer(1) mis a jour, sinon rien.ratee ← rmax

starte ← startfinishe ← start + volume/rmax

G← prune layer(Layer(2), ratee, starte, finishe)path← SPF (G, s, d)si path alors

Mettre a jour Layer(2)

Retourner (starte, finishe, ratee)finsiEchec de l’allocation.

La fonction prune layer(Layer(2), ratee, starte, finishe) est chargee d’eliminer les liens/-tunnels qui ne peuvent supporter un tunnel dont la bande passante serait ratee (verification dela contrainte sur les labels, de la contrainte sur la signalisaton de tunnels et la contrainte sur labande passante) entre les deux dates.

L’algorithme d’allocation sur rmin differe seulement par le fait que ratee recoit rmin, finishe

recoit deadline au lieu de rmax, et start + volume/rmax.25Constrained Shortest Path First26C’est a dire un tunnel dans Layer(3).27Nous sommes dans un contexte de routage, les chemins que nous calculons n’utilisent jamais deux fois la

meme arete et ne passent jamais deux fois par le meme noeud.

24

Le second algorithme ODS RMAX effectue de l’allocation de tunnels a la demande. Lestunnels de Layer(2) ne sont plus choisis a l’avance et c’est a notre algorithme de les signalerau besoin. Dans ce cas, nous ne pouvons plus eliminer les tunnels qui ne sont pas signalesdans la fonction prune layer. Nous ne verifions alors les contraintes que dans les parties ou lestunnels sont signales. Dans le cas ou la requete pourrait etre acceptee d’apres cette verification,la metrique du tunnel est mise a une valeur qui est la somme d’une penalite liee au fait quenous allons devoir essayer de signaler le tunnel et de la longueur du tunnel dans la couche 1.Ainsi le calcul du plus court chemin nous donnera en priorite des chemins dont les tunnels sontdeja signales, puis des chemins dont les tunnels a signaler sont les plus courts. Cela provientdu fait qu’un chemin plus court utilise moins de ressources. Une fois un chemin obtenu par leSPF, si celui-ci contient des tunnels non signales, il nous faut essayer de les signaler en verifiantles contraintes vis-a-vis des liens qu’il utilise dans la couche 1. Cette tentative peut echouerauquel cas la requete est rejetee. La taille choisie pour les tunnels lorsque nous envisageons deles signaler est la taille maximum (ie. LSPmax).

Le troisieme algorithme STATIC ODS RMAX utilise une approche mixte a savoir, qu’unepartie des tunnels est deja signalee en avance et que nous tentons egalement de signaler denouveaux tunnels dans la couche 2.

Enfin deux derniers MODS RMAX et MSTATIC ODS RMAX sont bases sur les deuxalgorithmes precedemment mentionnes mais dans le cas ou le premier chemin ne permet pasd’aboutir a l’allocation de la requete parce que la signalisation d’un tunnel a echoue, le tunnel estelimine du graphe G et un nouveau chemin est calcule. Le nouveau chemin obtenu est differentpuisque l’ancien chemin passait par le tunnel qui a ete elimine. L’algorithme termine parce quele nombre de tunnel dans la couche 2 est fini et qu’une fois qu’il n’y a plus de tunnel, le SPFne retourne plus de chemin et donc l’allocation echoue.

La complexite des algorithmes ou nous n’essayons que le premier chemin est celle du ShortestPath First c’est a dire O(v.log(v) + e) ou e est le nombre de tunnels/liens et v ne nombre denoeuds de la couche 2. Pour le cas ou nous tentons plusieurs chemins, la complexite est majoreepar O((v.log(v) + e).e).

Nous allons a present comparer ces algorithmes du point de vue du nombre de requetesacceptees.

4 Simulations et analyses des resultats

4.1 Gsim

Les algorithmes presentes dans la section precedente ont ete implantes dans le simulateurGsim developpe specifiquement pour notre probleme afin d’evaluer leurs performances. Ce si-mulateur est developpe en C et represente environ 5800 lignes. Il instancie le modele proposedans la section 2.2. Ce programme dispose de trois fonctionnalites, il permet de calculer l’en-semble des tunnels ainsi que les DAG Dep, il permet egalement de generer les requetes et enfinde simuler l’allocation de ces requetes. Ce programme ne dispose pas d’interface graphique,cependant les sorties au format Graphviz 28 permettent de tracer les graphes (figures 8, 9, 10 et11 par exemple).

4.2 Simulations

Dans cette section nous allons comparer les differents algorithmes presentes dans la section3.4 en fonction de notre objectif qui est le nombre de requetes acceptes.

28http://www.graphviz.org/

25

Algorithme 2 Algorithme MODS RMAX

Entrees: r = (s, d, rmax, volume, start, deadline) une requeteEntrees: Layer(2), Layer(1).Sorties: Si la requete est acceptee, (date de debut reel du transfert, date de fin reelle, debit,

chemin), et les Layer(2), Layer(1) mis a jour, sinon rien.ratee ← rmax

starte ← startfinishe ← start + volume/rmax

G← prune layer(Layer(2), ratee, starte, finishe)path← SPF (G, s, d)tantque path faire

si path contient au moins un tunnel a tenter de signaler alorsEssayer de signaler les tunnels de path.si Les tunnels ont ete signales avec succes alors

Mettre a jour Layer(2)

Retourner (starte, finishe, ratee, path)sinon

Eliminer le tunnel dont la signalisation a echoue de Gpath← SPF (G, s, d)

finsisinon

Mettre a jour Layer(2)

Retourner (starte, finishe, ratee, path)finsi

fin tantqueEchec de l’allocation.

26

Les requetes utilisees ont toutes les memes caracteristiques, le volume est de 1 Go, le rmax esta 500 Mbits/s, et la difference entre start et deadline est calculee de telle facon que rmin = rmax

2 .Les requetes sont distribuees uniformement sur la duree de l’experience (4000 s), les dates derelease sont tirees uniformement et le delai entre release et start est fixe a 100 s. Elles sonttraitees dans l’ordre de leurs dates de release sans prendre en compte les dates start et deadline.La source et la destination sont egalement distribuees uniformement sur les TermUp de lacouche 3.

La topologie utilisee est celle de G-lambda dont les couches 1 et 2 sont representees sur lesfigures 14 et 15. Les liens de la couche 1 comportent entre deux et trois longueurs d’onde de 1gigabits/s, et les liens de la couche 2 font 1 gigabits/s entre les routeurs et les machines. Noussupposons de plus que chaque lien/tunnel de la couche 2 dispose de 65000 labels (qui pourraientetre les tags de VLAN dans le cas de DRAGON). La couche 3 n’est pas representee, elle necontient que les TermUp correspondants aux TermDown de la couche 2 et les tunnels associes.

Dans les variantes des algorithmes presentes ou une partie ou tous les tunnels a signaler sontchoisis a la main de facon a ce qu’il y ait un chemin entre tous les noeuds.

Fig. 14 – Couche 1 de G-lambda Fig. 15 – Couche 2 de G-lambda

Les simulations ont ete faites avec un nombre de requetes variant entre 100 et 3000 par pasde 100, chaque experience etant repetee 15 fois et c’est finalement la moyenne du ratio entre lenombre de requetes et le nombre de requetes acceptes qui est utilisee.

La figure 17 montre la difference entre le ratio de requetes acceptees avec des allocations surrmin et sur rmax. Nous observons que pour tous les algorithmes sauf celui qui n’utilise que de lasignalisation a la demande en n’essayant que sur le premier chemin trouve par le SPF (ODS),les courbes avec l’allocation sur rmin sont meilleures que celles avec les allocations sur rmax.Ce que nous pouvons expliquer par le fait que les allocations sur rmin consomment moins debande passante et qu’il est possible de faire passer plus de requetes sur le meme lien au mememoment. Pour l’algorithme ODS (figure 16), tant que le nombre de requetes est peu important,le fait d’allouer sur rmax permet de liberer les tunnels plus rapidement et donc d’accepter plusde requetes mais quand la charge augmente, il devient alors plus interessant d’allouer sur rmin.

A present, nous allons comparer les variantes des algorithmes allouants sur rmin29. Les

29La courbe de ODS RMAX reste au dessous des courbes des autres algorithmes sur rmin, elle n’est donc pastrace.

27

Fig. 16 – Comparaison entre les ratios de re-quetes acceptees de ODS RMAX et ODS RMIN

Fig. 17 – Difference entre le ratio de requetesacceptees avec des allocations sur rmin et rmax

courbes sont sur la figure 18. Nous remarquons sur cette courbe que les deux algorithmes quiutilisent la signalisation a la demande et tentent d’utiliser d’autres chemins que le premier encas d’echec de la signalisation sont globalement meilleurs que les autres et qu’a faible charge, lefait d’utiliser une partie des tunnels afin d’assurer la connectivite entre tous les noeuds permetd’avoir un meilleur ratio de requetes acceptees.

5 Conclusions et perspectives

Ce travail s’inscrit dans la continuite des travaux sur le partage de bande passante dans lesgrilles ou le cœur est considere comme surdimensione [VBZ05] et [CVB06]. Le travail presentedans ce rapport propose une modelisation qui prend en compte le reseau de cœur optique et lesreseaux d’extremites Ethernet qui peuvent egalement etre congestionnes ainsi que les contraintesliees au modele de reseaux controles par GMPLS. A partir de ce modele, le probleme de partagede bande passante pour les transferts massifs est expose, ainsi que les parametres sur lesquelsnous pouvons agir lors de la decision d’allocation. Plusieurs algorithmes reposants sur les travauxde QoS routing sont proposes et compares. D’apres les simulations nous pouvons gagner sur lenombre de requetes acceptees en exploitant le fait qu’il nous est permis de choisir notre chemindans le reseau.

Les algorithmes proposes dans ce rapport sont simples et n’exploitent que le choix du cheminmais il ne s’agit que d’une premiere etape. Les etapes suivantes seront d’utiliser les autresparametres sur lesquels nous pouvons agir : le choix du debit et des dates effectives de debut etde fin de transfert, ce qui a ete investigue dans le dernier rapport de recherche cite. L’influencede la topologie, du nombre de nœuds et du nombre de longueurs d’onde (labels) par fibre sontegalement a investiguer pour etudier le dimensionnement des infrastructures reseaux de grilles.Il est aussi souhaitable de pouvoir imposer d’autres contraintes lors de la reservation, permettantainsi de specifier la gigue, le taux de pertes, les protections des liens mises en œuvre dans leschemins calcules par le NRM. Il reste enfin toute la partie concernant la mise en œuvre de cettesolution, du point de vue definition des interfaces entre l’utilisateur et le systeme de reservation,mise en place des limitations de bande passante pour les reseaux Ethernet et mise en place d’uneversion distribuee de l’algorithme d’allocation avant de pouvoir realiser un prototype.

28

Fig. 18 – Ratio de requetes acceptees pour les algorithmes allouants sur rmin

References

[CN98] Shigang Chen and Klara Nahrstedt. An overview of quality-of-service routing forthe next generation high-speed networks: Problems and solutions. IEEE NetworkMagazine, Special Issue on Transmission and Distribution of Digital Video, 1998.

[CVB06] Bin Bin Chen and Pascale Vicat-Blanc/Primet. A flexible bandwidth reservationframework for bulk data transferts in grid networks. Research Report no. 2006-20,LIP, ENS-Lyon, France, May 2006.

[DGG+99] Nick G. Duffield, Pawan Goyal, Albert G. Greenberg, Partho Pratim Mishra, K. K.Ramakrishnan, and Jacobus E. van der Merive. A flexible model for resource man-agement in virtual private networks. In SIGCOMM, pages 95–108, 1999.

[FB05] Adrian Farrel and Igor Bryskin. GMPLS: Architecture and Applications (The Mor-gan Kaufmann Series in Networking). Morgan Kaufmann Publishers Inc., San Fran-cisco, CA, USA, 2005.

[FFR+04] Ian Foster, Markus Fidler, Alain Roy, Volker Sander, and Linda Winkler. End-to-end quality of service for high-end applications. Computer Communications,27(14):1375–1388, 2004.

[FKT01] Ian Foster, Carl Kesselman, and Steven Tuecke. The anatomy of the grid: Enablingscalable virtual organizations. Int. J. High Perform. Comput. Appl., 15(3):200–222,2001.

[GO00] Roch A. Guerin and Ariel Orda. Networks with advance reservations: The rout-ing perspective. In Proceedings of the 19th Annual Joint Conference of the IEEEComputer and Communications Societies INFOCOM, 2000.

29

[KL04] K. Kompella and J. Lang. Procedures for Modifying the Resource reSerVationProtocol (RSVP). RFC 3936 (Best Current Practice), October 2004.

[KR05] K. Kompella and Y. Rekhter. OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). RFC 4203 (Proposed Standard), October 2005.

[LSJ06] Thomas Lehman, Jerry Sobiesky, and Bijan Jabbari. Dragon: A framework for ser-vice provisioning in heterogeneous grid networks. IEEE Communications Magazine,44(3):84–90, March 2006.

[Man04] E. Mannie. Generalized Multi-Protocol Label Switching (GMPLS) Architecture.RFC 3945 (Proposed Standard), October 2004.

[PM04] Michal Pioro and Deppankar Medhi. Routing, Flow, and Capacity Design in Com-munication and Computer Networks. Morgan Kaufmann Publishers, 2004.

[VBZ05] Pascale Vicat-Blanc/Primet and J. Zeng. Traffic isolation and network resourcesharing for performance control in grids. In ICAS/ICNS, page 87. IEEE ComputerSociety, 2005.

[VZcF+03] Malathi Veeraraghavan, Xuan Zheng, Wu chun Feng, Hojun Lee, Edwin K. P.Chong, and Hua Li. Scheduling and transport for file transfers on high-speed opticalcircuits. J. Grid Comput., 1(4):395–405, 2003.

[VZH06] Malathi Veeraraghavan, Xuan Zheng, and Zhanxiang Huang. On the use ofconnection-oriented networks to support grid computing. IEEE CommunicationsMagazine, 44(3):118–123, March 2006.

[WSC+05] Jing Wu, Michel Savoie, Scott Campbell, Hanxi Zhang, Gregor V. Bochmann, andBill St. Arnaud. Customer-managed End-to-End lightpath provisioning. Interna-tional Journal of Network Management, 15(5):349–362, 2005.

[XN99] Xipeng Xiao and Lionel M. Ni. Internet QoS: A Big Pictures. IEEE Network,13(2):8–18, March 1999.

30