Architecture et algorithmes pour les services inter-domaines

Transcription

1 Architecture et algorithmes pour les services inter-domaines Proposé et encadré par : Bernard Cousin, Samer Lahoud ARMOR2, IRISA. Rennes bernard.cousin@irisa.fr samer.lahoud@irisa.fr Nicolas Le Sauze Projet PTI Alcatel-Lucent. Nozay nicolas.le_sauze@alcatel-lucent.fr Nabil Bachir DJARALLAH nabil.djarallah@etudiant.univ-rennes1.fr Rapport bibliographique Master de Recherche en Informatique de l'université de Rennes

2 Table des matières 1. Introduction Réseaux MPLS Commutation de labels Construction des chemins Ingénierie de trafic et réseaux MPLS MPLS-TE inter-domaine Quelques défis de MPLS TE Inter-AS Services inter-domaines et la nouvelle architecture IPsphere Gestion des services inter-domaine : IPsphere Aperçu sur l architecture IPsphere IPsphere : modèle en trois couches Rôle des fournisseurs dans l IPsphere Utilisations du IPsphere Calcul de chemins contraints Calcul de chemins par-domaine Calcul de chemins basé sur les PCE Définition du PCE (Path Computation Element) Calcul de chemins récursif arrière basé sur les PCE Architecture d un nœud PCE Modes de calcul Mode de calcul centralisé Mode de calcul distribué Etude comparative entre les deux méthodes de calcul de chemins Approche de calcul de chemins basé sur les PCE Approche de calcul de chemins par-domaine Métriques de performance Résultats et analyses Description de l environnement de simulation Pannes des liens Résultats des simulations Conclusion

3 1. Introduction Aujourd hui, la diversité des flux de trafic issue des différents réseaux existants (réseaux haut-débit, réseaux radio mobiles), et la difficulté de partager des ressources dans un contexte multiservice à travers différents réseaux, complexifient les modèles économiques. Cela favorise la mise en œuvre de réseaux de convergence multiservices interconnectant des acteurs avec des stratégies économiques différentes. La diversité des acteurs (opérateurs de réseaux de données ou de réseaux de transport, fournisseurs de contenu, ) nécessite l'utilisation d'une nouvelle architecture de réseaux pour répondre aux besoins des applications émergentes en terme de garantie de performances. Cette architecture est nécessaire parce que ces acteurs proposent des services qui sont en général disponibles uniquement au sein de leur propre domaine. Ainsi, tous les clients potentiels (ex. entreprises, opérateurs, utilisateur final, etc.) doivent être connectés au même opérateur pour bénéficier de ces services évolués, ce qui est très désavantageux pour les fournisseurs comme pour les consommateurs. De ce fait, les services inter-domaines évolués sont quasiment inexistants, pour des raisons à la fois techniques et économiques. Pour résoudre ce problème, il faut que cette architecture facilite la définition, la négociation, la commercialisation et la production de services évolués tout en garantissant de bout-en-bout le niveau de performance requis par les applications. Cette architecture doit permettre l interconnexion des différents réseaux qui peuvent être de différentes natures (ATM, Frame Relay, Ethernet, etc.) d une façon transparente, souple et efficace. Le problème réside dans l hétérogénéité de l infrastructure réseau et le routage des données à travers ces différents réseaux. Pour cela, il fallait un nouveau protocole qui fait cohabiter ces différentes technologies et offrir une meilleure gestion du réseau pour assurer les différents niveaux de services pour l optimisation des ressources. Après de nombreuses propositions, l IETF (Internet Engineering Task Force) adopta finalement un nouveau protocole, MPLS (MultiProtocol Label Switching) qui répond à la majorité des besoins que nous venons d évoquer. Ces réseaux permettent aux opérateurs d avoir un cœur de réseau unique qui est capable de fournir à ses abonnés de multiples services (voix, données, vidéo). Avec cette évolution de l architecture réseau, de nouveaux modèles économiques sont proposés pour répondre aux nouveaux enjeux de l'interconnexion des réseaux. L'objectif du stage est de développer les modèles et de définir les solutions qui permettront de répondre aux enjeux économiques et technologiques de l'évolution de l'interconnexion des réseaux, afin de lever les verrous relatifs à la définition de l'architecture de services et la mise au point d'algorithmes pour l'optimisation des ressources. L'étude se base sur le modèle de services proposé par le forum IPSphere qui utilise une couche de type Service Oriented Architecture (SOA). Cette couche permet de publier les offres de services et de les combiner afin de construire des services évolués faisant intervenir plusieurs acteurs. De plus, les travaux récents de l'ietf sur le Path Computation Element (PCE) offrent une perspective importante pour les problématiques de la couche réseau, notamment le calcul de chemin en inter-domaine et qui satisfait les lacunes de la méthode de calcul de chemin par domaine. Mais, il faut concrétiser cette perspective et évaluer cette technique de calcul de chemins en présence de multiples contraintes. Dans ce contexte, nous définirons une solution permettant de gérer de bout en bout les ressources des réseaux tout en considérant les besoins des applications et l'optimisation des réseaux. Une étude sur l architecture de service est menée afin de spécifier les blocs fonctionnels pour la publication, la négociation et l'établissement des services inter-domaines. 3

4 Le reste de ce rapport est structuré en cinq chapitres. Le deuxième chapitre introduira l infrastructure utilisée (MPLS) toute en discutant son principe de fonctionnement et la façon dont les chemins sont construits. Ensuite nous verrons comment les flux de trafic sont répartis et comment les fournisseurs de services assurent des niveaux de qualité de service (QoS) compatibles en se basant sur l ingénierie de trafic apportée à ces réseaux. A la fin de ce chapitre nous présentons les défis liés à l ingénierie de trafic des réseaux MPLS. Le troisième chapitre abordera la notion de services inter-domaines et la gestion de ces derniers avec l architecture de référence IPsphere. Pour bien comprendre l architecture de IPsphere, nous allons voir le modèle en couches de cette architecture et le rôle des fournisseurs. Pour conclure ce chapitre, nous avons consacré une section pour donner les différentes utilisations de IPsphere et comment cette architecture de référence est employée pour résoudre le problème de MPLS-TE inter-domaine (MPLS Traffic Engineering). Dans ce contexte, nous allons voir que le calcul de chemins contraints représente un défi majeur pour la solution IPsphere. Dans le chapitre quatre, nous mettons la lumière sur deux méthodes de calcul de chemins (calcul par domaine et celui basé sur les PCE), mais tout en se concentrant sur celle basée sur le PCE. Ici, nous donnons l architecture d un nœud PCE et les différents modes de communication. Ensuite nous arriverons au chapitre cinq qui illustre une comparaison des deux méthodes de calcul de chemins selon certains critères d évaluation choisis par les auteurs de l article [13]. A la fin nous terminerons ce rapport par une conclusion où nous donnons les différentes contributions envisagées pour la continuation du stage. 2. Réseaux MPLS Face à la demande en forte croissance des VPN (Virtual Private Network), les opérateurs proposent généralement deux types de solutions: la première reposant sur le protocole IPSec (Internet Protocol Security [1]) qui privilégie la sécurisation des flux d'informations par encryptage des données, la seconde s'adossant à la norme plus récente MPLS (MultiProtocol Label Switching) [2] qui gère les problèmes de qualité de service et de la priorité des flux. En effet, MPLS est un protocole de transport de données, opérant sur la couche de Liaison de données du modèle OSI (Figure 1), donc en dessous du protocole IP. Il a été conçu pour fournir un service unifié de transport de données en utilisant une technique de commutation de labels. MPLS peut être utilisé pour transporter tout type de trafic numérique, par exemple la voix/vidéo ou des paquets IP. Figure 1 : La couche MPLS Le premier objectif de MPLS était d accroître la vitesse du traitement des flux au niveau des équipements de routage. Avec l évolution de la technologie de ces équipements, cet 4

5 objectif est passé au second plan. L aspect fonctionnalité est devenu plus important et les objectifs sont maintenant les suivants : l intégration IP/WDM (Wavelength Division Multiplexing), la QoS (Qualité de service) et la mise en place de VPN (Réseaux privés virtuels) Commutation de labels L'idée fondamentale de la commutation de labels consiste à remplacer le mécanisme d'acheminement usuel ("packet forwarding") par un mécanisme plus rapide. Dans cette configuration, l'acheminement des paquets est basé sur l'analyse du label ajouté au paquet et non plus sur l analyse de l'adresse IP de destination, opération longue et coûteuse effectuée au niveau 3. Au cœur du réseau à commutation de labels, la route empruntée par chaque paquet est déterminée par le label qu ils contiennent. Le label fournit suffisamment d'informations aux équipements du cœur de réseau (LSR : Label Switching Router) pour qu'ils puissent décider du prochain saut que le paquet doit effectuer. Le choix d'un label tient compte principalement de l'adresse de destination et des informations contenues dans l entête IP. Tous les paquets portant le même label suivront le même chemin dans le réseau. Le traitement complexe du choix du label étant fait uniquement à la frontière du réseau (LER : Label Edge Routers) permet de mieux gérer le facteur d'échelle. Le protocole de routage IP détermine, à partir de l adresse IP de l egress node, la (FEC: Forwarding Equivalence Class Définit les caractéristiques de QoS attribuées aux flux traversant le réseau MPLS), le label et port de sortie. L'ensemble de paquets qui hérite du même label fait partie d'une même classe d'équivalence FEC (Forwarding Equivalence Class), le chemin qu'ils suivent est appelé chemin commuté ou LSP (Label Switched Path) Construction des chemins Pour qu'un chemin soit construit, il faut que les tables des routeurs (commutateurs) participant à l'établissement de ce chemin soient remplies. Chaque routeur doit avoir une entrée correspondant au label du paquet IP à commuter. Pour qu'un chemin soit établi, il faut que le routeur suivant ait une entrée pour le label de sortie du routeur précédent. Il existe deux méthodes pour construire un chemin. La première est le routage explicite, on laisse alors à une entité spécialisée la fonction du choix et d'établissement des chemins au sein du réseau. La seconde consiste à donner à chaque routeur la possibilité de choisir le routeur voisin à qui il devra passer le paquet. Contrairement à la première approche, la seconde prive l'opérateur d'un niveau de gestion du réseau. Un réseau MPLS permet de faire cohabiter les deux approches. Puisque MPLS permet à ces routeurs de décider des chemins, ils peuvent donc être construits en fonction de la topologie du réseau. D'autres méthodes sont disponibles pour mettre en place des chemins sur un réseau MPLS. Des méthodes manuelles (configuration statique des routeurs-commutateurs) et des méthodes automatiques tel que le LDP (Label Distribution Protocol) [3]. Les différentes méthodes peuvent être couplées entre elles. 5

6 2.3. Ingénierie de trafic et réseaux MPLS La croissance des débits d'accès et la convergence des services (Internet, voix/visioconférence, télévision/vidéo à la demande) sur une infrastructure IP fédératrice entraînent une augmentation considérable des volumes de trafic IP ainsi que de nouvelles contraintes en termes de qualité de service (QoS) et de disponibilité (sûreté de fonctionnement) pour les réseaux IP. Des mécanismes d'ingénierie de trafic, de QoS et de sécurisation deviennent nécessaires pour supporter cette évolution du volume et de la nature des trafics transportés. L'ingénierie de trafic regroupe l'ensemble des méthodes de contrôle du routage permettant d'optimiser l'utilisation des ressources, tout en garantissant la qualité de service (bande passante, délai...). L'objectif des mécanismes d'ingénierie de trafic est de maximiser la quantité de trafic pouvant transiter dans un réseau tout en maintenant la qualité de service. Diverses méthodes d'ingénierie de trafic pour les réseaux IP ont été spécifiées depuis plusieurs années. Parmi ces méthodes, on trouve celle basée sur l'utilisation de la technologie MPLS. La technologie MPLS est particulièrement bien adaptée à l'ingénierie de trafic car elle permet la création de chemins routés de façon explicite, indépendamment du routage IP. Cela permet d'utiliser des chemins alternatifs au chemin IP, et donc de proposer des chemins différents répondant de manière plus efficace à des critères variés, de mieux répartir la charge dans le réseau et ainsi de gérer de manière très efficace les cas de congestion. [4] MPLS-TE permet l'établissement de tunnels MPLS routés de façon explicite en fonction des contraintes du trafic transporté (bande passante, délai...) et des ressources disponibles dans le réseau. Ces tunnels MPLS-TE peuvent être assimilés à des connexions. MPLS-TE crée ainsi un mode connecté pour les réseaux IP, permettant d'optimiser l'utilisation des ressources et de maximiser la charge de trafic pouvant circuler sur le réseau tout en préservant la qualité de service (gestion des besoins des applications et gestion de la congestion). Ce routage par contrainte MPLS-TE nécessite un ensemble de protocoles et d'algorithmes de routage et de signalisation. Les protocoles de réservation de ressources comme RSVP-TE (Resource ReSerVation Protocol TE) permet en outre d'associer des caractéristiques de qualité de service aux chemins et de subordonner leur établissement à la disponibilité de ressources dans les équipements intermédiaires. MPLS autorise la mise en place de fonctions évoluées de partage de charge et de routage différencié en fonction d informations contenues dans l entête du paquet ou de l interface d entrée. L intégration de l ingénierie de trafic se fait par un IGP (Interior Gateway Protocol) qui peut être OSPF ou IS-IS MPLS-TE inter-domaine Il est très intéressant d assurer des niveaux de qualité de service (QoS) compatibles à travers les frontières de différents fournisseurs de services ou Service Provider (SP). Certaines caractéristiques de l ingénierie de trafic peuvent être nécessaires pour offrir des garanties de QoS pour les connexions. L ingénierie de trafic inter-domaine devrait permettre d optimiser l utilisation des liens entre les fournisseurs, délivrer une QoS inter-domaine garantie et stricte (bande passante, délai, gigue, taux d'erreur, etc.) et doit offrir une fonctionnalité de récupération rapide dans le cas d'une panne de noeud ou de lien (Figure 2). [10] Une solution pertinente pour supporter l ingénierie de trafic est de s'appuyer sur les LSP utilisant la technologie MPLS Inter-AS, c.-à-d. des TE LSP (TE Label Switched Paths) qui traversent les frontières des AS (Système autonome). Les exigences liées à MPLS-TE Inter- 6

7 AS sont décrites dans [5]. Le TE LSP combiné avec DiffServ [6] peut assurer une bande passante garantie de bout en bout avec une borne sur le délai et la gigue. Il peut être protégé sur les liens entre les différents AS en utilisant un Fast Reroute Backup LSP [7]. Label exchange & Bw reservation using RSVP-TE Inter-AS TE LSP Voice GTW 1 ASBR 2 ASBR 3 Voice GTW 2 ASBR 1 ASBR 4 Provider A Inter-AS TE Bypass LSP => ASBR2-ASBR3 link protection Provider B Figure 2: TE-LSP entre deux passerelles de voix localisées dans deux réseaux différents, [10] Il faut spécifier les mécanismes de calcul de chemins et de signalisation (RSVP-TE) pour mettre en place TE-LSP Inter-AS. Il y a actuellement trois types de TE LSP interdomaine définis pour MPLS-TE inter-as [8]: Contiguous LSP, LSP Hierarchy, LSP Stitching 2.5. Quelques défis de MPLS TE Inter-AS Pour permettre à un fournisseur de services (un fournisseur de service peut avoir plusieurs systèmes autonomes) de contrôler l admission des LSP inter-as, un contrat (Figure 3) [10] doit être établi. Le contrat indique si le LSP inter-as peut être mis en place entre les deux SP. Dans le cas où c est possible, le contrat doit indiquer des paramètres de TE (pour le contrôle d admission) comme la bande passante permise et le nombre maximum qui peut être utilisés vers le SP destinataire. Notons que des politiques liées à Diffserv peuvent être appliquées. On peut trouver d autres politiques liées au contrat (comme le degré tolérable de dépassement du volume de trafic et comment réagir avec ce problème). Un autre défi est la facturation des services fournis qui peut être selon la bande passante allouée, selon les LSP établis ou selon la nature du TE LSP établi. Le dernier point concerne le routage, lorsqu'on peut trouver plusieurs routes empruntant des AS différents (figure 3) pour atteindre la destination. Ainsi, certains mécanismes sont nécessaires pour choisir parmi ces chemins potentiels. Par exemple dans la figure 3, il y a deux chemins possibles inter-as entre SP1 et SP2 : le transit peut être soit via SP2 ou SP4. Fondamentalement, seul SP1 peut décider où il envoie la requête d établissement du LSP. Ces choix sont gérés par la politique du système autonome, la qualité du chemin etc,. 7

8 SP1-SP4 TE Contract Transit SP1 : 0, Transit SP4 100m End SP1: 100m, End SP4: 0 Provider 4 SP3-SP4 TE Contract Transit SP3 : 0, Transit SP4 100m End SP3: 100m, End SP4: 0 ASBR 2 ASBR 2 ASBR 2 AS path 2 AS path 1 ASBR 2 Voice GTW 1 ASBR 2 ASBR 3 ASBR 5 ASBR 7 Voice GTW 2 ASBR 1 ASBR 4 ASBR 6 ASBR 8 Provider 1 Provider 2 Provider 3 SP1-SP2 TE Contract Transit SP1 : 0, Transit SP2 100m End SP1: 100m, End SP2: 0 SP2-SP3 TE Contract Transit SP3 : 0, Transit SP2 100m End SP3: 100m, End SP2: 0 Inter-SP pte DB Figure 3: L aspect de contrats et la multitude de chemins, [10] 3. Services inter-domaines et la nouvelle architecture IPsphere 3.1. Gestion des services inter-domaine : IPsphere Les réseaux IP actuels sont construits sur un modèle Internet dans lequel tous les utilisateurs finaux payent un prix identique pour accéder aux services quelqu ils soient. Dans ce cas, les fournisseurs interconnectent ces utilisateurs librement et sans mettre des spécifications ou des règlements sur les contrats de services. Mais les fournisseurs de services cherchent un tout autre modèle pour les services sur lesquels ils dépendent des revenus. Ce modèle alternatif implique des contrats pour les services, des règles (ou politiques) spécifiques et une gestion d interconnexion basée sur des accords bilatéraux ou multilatéraux entre les fournisseurs. De nombreux opérateurs, constructeurs, développeurs de solutions applicatives, consultants, ont décidé de se regrouper pour définir des solutions pragmatiques aux problèmes que nous venons d évoquer. Initialement appelée Infranet [11], cette initiative a finalement adopté la forme d un forum au secrétariat indépendant, nommé IPsphere Forum, qui regroupe plus de 40 membres dont Alcatel-Lucent, British Telecom, Cisco Systems, Ericsson, France Telecom, Hewlett Packard, IBM, Juniper Networks (initiateur), Oracle, Siemens, T-Com, T-System, Internet2, l organisme de recherche et enseignement des Etats- Unis et plusieurs autres. 8

9 3.2. Aperçu sur l architecture IPsphere Le forum IPsphere affirme que l approche actuelle de l Internet ne peut pas continuer sur la même trajectoire [12]. Comme solution, le forum a créé une couche business (couche entreprise ou service) dans le monde IP. Cette couche se concentre sur la façon dont les services IP sont demandés par les utilisateurs et fournis par les fournisseurs. IPsphere complète à la fois les efforts des standards existants et les mécanismes du réseau IP afin de ne pas interférer avec les standards ou les protocoles existants. La mission du forum IPsphere est d offrir un cadre commercial meilleur pour les services IP qui préserve l'ubiquité fondamentale de l'internet. Le IPsphere permet aux fournisseurs, d une façon concurrente, d optimiser la flexibilité et l efficacité en se concentrant sur la décomposition d un service en un ensemble de ressources pour répondre à l'ensemble des objectifs du service IPsphere : modèle en trois couches Le IPsphere se base sur deux aspects. Le premier est l abstraction du service ; en fournissant un mécanisme pour déclarer un service donné en termes de contraintes techniques et contraintes d affaire. Le deuxième est la décomposition du service, c'est-à-dire la décomposition d un service donné en engagements de ressources à travers un ou plusieurs fournisseurs. [12] IPsphere a clairement identifié les trois couches indispensables pour cette nouvelle infrastructure, que nous retrouvons dans la figure 4. La première couche qui est la couche de traitement des paquets ou «Packet Handling Stratum» : ce niveau assure l acheminement des paquets entrants et sortants en respectant les contraintes de disponibilité, de sécurité et de qualité de service. Ce niveau s articule autour des protocoles existants, donc le forum IPsphere n est pas très actif à cette couche. Cependant, des règles d usages, voire des demandes d extension, pourraient être formulées. La deuxième couche est la couche de règles et contrôle ou «Policy and Control Stratum» : ce niveau est responsable des aspects de l allocation et de suivi des ressources pour assurer la fiabilité, la sécurité et la disponibilité des engagements liés à un service demandé. Figure 4 : L architecture de l IPsphere, [12] 9

10 La troisième couche qui est la couche de structuration de service ou «Service Structuring Stratum» (SSS) : ce niveau est la base du framework IPsphere. C est à ce niveau que l abstraction et la décomposition de services sont faites. Cette couche de signalisation de haut niveau permet d une part aux opérateurs de publier leurs services dans un répertoire global contenant la description des différents éléments, leurs conditions d accès et d activation, leurs moyens de contrôle de qualité, etc. Tous les opérateurs accèdent à ce répertoire qui gère les différents accords d échange de service entre eux. D autre part la couche SSS permet à l utilisateur final de signaler ou de déclencher un service dans l IPsphere. Cette couche communique via la couche de règles (ou politiques) et contrôle pour traduire les requêtes des services abstraits en ressources concrètes à travers les opérateurs et entre les opérateurs et les consommateurs. [12] Selon la vision de IPsphere, un service peut être créé par la collection de plusieurs Eléments ou Service-Element, où chaque élément peut être fourni par un fournisseur de service (Element Provider ou EP) différent. Dans l architecture IPsphere, on trouve deux processus : 1. Registration & Publishing : avec ce processus, les EP peuvent publier leur éléments (Service Elements) pour qu'il puissent être utilisés par les autres fournisseurs de services. Ces fournisseurs de services utilisent ces éléments pour construire leurs propres offres de services. Le résultat de ce processus constitue des ensembles de partenaires potentiels dans le but de fournir un service de bout en bout. [10] 2. Run-Time (Temps d exécution) : ce processus représente le cycle de vie des services actuels, où le propriétaire d'administration (Administrative Owner : le fournisseur qui a une relation commerciale avec le client) gère le service de bout en bout à travers les trois phases: a. La phase de configuration : ici le AO (Administrative Owner) est comme un acheteur, il doit se mettre d accord avec chaque EP sur les plans commerciaux et les termes de l ingénierie (SLA : Service Level Agreement). b. La phase d exécution : où le AO et les EP activent les éléments qui font partie du service de bout en bout vendu. c. La phase d assurance : où le service (en cours) et tous les éléments fournis par les EP conserveront leurs engagements établis lors de la phase de configuration. [10] 3.4. Rôle des fournisseurs dans l IPsphere Les Propriétaires Administratifs (Administrative Owners) et les Propriétaires d Eléments (Element Owners) communiquent à travers le Bus de Messages SSS (SSS Message Bus) dans le but d approvisionner, activer et gérer les services. Les communications à travers le bus de message SSS sont bidirectionnelles. Le Propriétaire Administratif dirige l approvisionnement et l activation d un service donné par l envoi des messages aux Propriétaires d Eléments associés. Une fois le service activé, un EO (Element Owner) peut signaler des failles, des paramètres de QoS et d autres données connexes par l'envoi d'alertes au propriétaire administratif. [12] La figure 5 illustre la vision du IPsphere avec plus de détails. Elle montre comment les fournisseurs de services offrent les services aux consommateurs. Le propriétaire administratif est l entité qui a la responsabilité d offrir et d assurer le service de bout en bout. 10

11 Le processus d affaire supporté par le framework IPsphere peut être visualisé de haut en bas (c.-à-d. du point de vue des services) ou de bas en haut (c.-à-d. du point de vue des ressources). Figure 5 : Contexte du IPsphere, [12] Dans la vision de haut en bas, le propriétaire administratif entre en relation avec un consommateur pour fournir un service. Les éléments se décomposent en plusieurs types de ressources, dont chacune peut être offerte par un autre contributeur. Pour chaque type de ressource, le meilleur contributeur est déterminé et l'ensemble des contributeurs optimaux est, ensuite, liés à la fois à un contrat de service et à une ressource technique telle qu elle est demandée par le consommateur. Dans la vision de bas en haut, les opérateurs qui veulent contribuer peuvent définir des offres très spécifiques, appelés éléments. Les éléments peuvent être offerts uniformément à tous les propriétaires administratifs ou à un sous-ensemble de ce groupe. Optionnellement, les termes commerciaux peuvent être définies pour chaque élément individuellement pour refléter le prix et les politiques appliqués entre les fournisseurs de services. Ces termes commerciaux sont protégés contre la divulgation non désirée et ils peuvent être stockées séparément. Chaque AO (Administrative Owners) voit uniquement les termes commerciaux offerts par le EO Utilisations du IPsphere Le IPsphere supporte trois grandes catégories d'applications, qui peuvent être sélectionnées par un fournisseur de service: 1. Le Framework peut servir de mécanisme par lequel les propriétaires d éléments publient leurs participations dans les services et les conditions auxquelles ils accepteront de participer. 11

12 2. Le Framework peut fournir un moyen pour automatiser les opérations de création de services, y compris ceux fournis, en totalité ou en partie, par les partenaires et ceux qui sont créés en intra-fournisseur. 3. Le Framework peut fournir un moyen de créer des pratiques communes pour la fourniture et le suivi du service à travers de multiples fournisseurs et technologies. Le schéma qui suit (Figure 6) présente une illustration montrant comment le problème peut être résolu dans l'architecture de référence IPsphere. Service Structuring Stratum SMS SP1 SMS SP2 Policy control & Management Stratum E/NMS PM PCE Inter-PCE proto E/NMS PM PCE MPLS Sig PCC-PCE proto MPLS-TE sig proto MPLS Sig Packet handling Stratum MPLS Forwarding MPLS, DiffServ MPLS Forwarding Figure 6 : Inter-Carrier TE MPLS et IPsphere, [10] Chaque couche de l architecture de IPsphere est responsable d un ensemble d activités. La couche de manipulation de paquets est essentiellement responsable de la QoS (la gestion du trafic, Queuing/Scheduling et le Forwarding. La couche de règles et contrôle est responsable de l allocation et de suivi des ressources (la signalisation MPLS, calcul de chemins, règles et contrôle au niveau du RSVP/ PCE, établissement de rapports SLA et le suivi de ce dernier). La couche de structuration de service est responsable du coté commercial des interfaces (mettre en place les contrats inter-domaines, Définir le service de tunnel interdomaine (Points finaux, paramètres ), la sélection de la chaîne de fournisseurs, activer (ou désactiver) une politique donnée et la facturation/comptabilité). Le défi ici est le calcul de chemins. Le calcul de chemins ne peut plus être effectué par le LSP initiateur, car il a une vue limitée à son AS. Il y a actuellement deux méthodes de calcul de chemins définies dans l IETF : calcul de chemins par domaine et le calcul de chemins basé sur les PCE (ces deux méthodes seront détaillées dans les chapitres suivants). 4. Calcul de chemins contraints Le calcul de chemins contraints est une composante stratégique de l'ingénierie de trafic dans les réseaux MPLS. Elle est utilisée pour déterminer le chemin que le trafic doit suivre à travers le réseau. Dans ce chapitre nous allons voir en premier lieu la méthode de calcul de 12

13 chemins par domaine, ensuite nous détaillons la deuxième méthode de calcul de chemins contraints basé sur les PCE. Les deux méthodes de calcul de chemins que nous venons de les citer, utilisent l algorithme CSPF (Constrained Shortest Path First) [18]. Le CSPF est une extension des algorithmes de calcul du plus court chemin comme ceux utilisés dans OSPF et IS-IS. Le chemin calculé en utilisant le CSPF est le chemin le plus court qui satisfait l ensemble des contraintes. Il exécute simplement l algorithme du plus court chemin après avoir exclure les liens qui violent l ensemble des contraintes. Une contrainte peut être le minimum de bande passante demandé par un lien, le délai de bout en bout, le nombre maximal de liens traversés, inclure/exclure des nœuds. Le CSPF est largement utilisé dans les réseaux MPLS TE. [13] Prenons l exemple de trois domaines (figure 7) pour bien comprendre les deux techniques de calcul de chemins. Chaque domaine a un certain nombre de routeurs de bordure d entrée (Boundary Nodes ou BN), d autres routeurs de sortie et des routeurs de cœur. Figure 7 : Exemple d un réseau avec des coûts sur les liens, [13] 4.1. Calcul de chemins par-domaine La technique de calcul par domaine invoque le calcul individuel de chaque segment dans chaque domaine intermédiaire. Durant ce calcul, aucune donnée concernant le calcul n est partagée entre les domaines. Le chemin complet pour le TE-LSP est obtenu par la concaténation des segments qui sont calculés dans chaque domaine i. Le routeur source commence par le calcul du chemin le plus court jusqu au BN de sortie le plus proche. Le deuxième segment est ensuite calculé pour le deuxième domaine vers le plus proche BN de sortie. Cette méthode de calcul ne donne pas toujours le chemin le plus court de la source à la destination à travers les domaines Calcul de chemins basé sur les PCE Définition du PCE (Path Computation Element) Le PCE est une entité qui est capable de calculer un chemin dans le réseau tout en respectant certaines contraintes. La mise en œuvre du PCE, utilise un modèle de type clientserveur. Le client appelé PCC ("Path Computation Client") envoie une demande de calcul de chemin au PCE responsable, en utilisant le protocole de communication du PCE (PCECP : PCE Communication Protocol) [19]. Un plan de contrôle synchronise les différents PCE pour calculer le meilleur chemin de bout en bout (Figure 8). Le PCE se base sur la TED Traffic 13

14 Engineering Database pour calculer le chemin demandé et reçoit aussi les informations liées au protocole de routage pour mettre à jour le TED. La vision du PCC est différente par rapport à celle du PCE [14], car le PCC a une connaissance limitée vis-à-vis de la manière dont fonctionne le PCE pour répondre aux requêtes. Par contre, le PCC est intéressé par la sélection d'un PCE qui est capable de fournir, dans un délai suffisamment court, le chemin qui répond aux contraintes fournies. Le calcul doit être distingué de la transmission réelle des paquets. Le PCE peut être placé au sein d'un nœud du réseau, être un système spécifique de gestion du réseau ou une plate-forme de calcul dédiée. Le PCE possède une connaissance sur l état des ressources du réseau et il a la capacité d envisager de multiples contraintes pour un calcul donné de chemin. Le calcul de chemin est utilisé dans les contextes variés suivants : inter-domaine, intradomaine et inter-couche. Le calcul peut faire intervenir un ou plusieurs PCE qui peuvent être mis en œuvre de d une façon centralisée ou distribuée. Le chemin calculé par le PCE est généralement un chemin explicite (c'est-à-dire la liste des routeurs intermédiaires est explicitement établie). Le chemin explicite pouvant être de type "strict path" ou "loose path". Dans le premier cas la liste exhaustive de tout les routeurs intermédiaires est donnée. Dans le deuxième cas la liste n'est pas exhaustive. [13] Calcul de chemins récursif arrière basé sur les PCE Le calcul de chemins récursif arrière basé sur les PCE (BRPC : Backward Recursive PCE-Based Computation), utilise plusieurs PCE pour calculer le chemin le plus court à travers les domaines et qui répond aux contraintes. La technique basée sur les PCE préserve la confidentialité tout au long des domaines traversés (chose importante quand les domaines sont gérés par des fournisseurs de services différent). La procédure BRPC est arrière parce que le chemin est calculé de la destination à la source. Elle est récursive parce que les mêmes étapes sont répétées dans chaque domaine intermédiaire entre la source et la destination. Toutefois, il est intéressant de noter que les mêmes résultats obtenus seront identiques avec la récursivité avant ; le choix entre ces deux directions étant du à des contraintes protocolaires Le BRPC utilise le concept VSPT (Virtual Shortest Path Tree). VSPT(i) dénote l arbre multipoint-à-point formé par l ensemble des chemins contrains les plus courts, partants des routeurs d entrée du domaine i jusqu à le routeur de destination. Avec BRPC et un domaine de destination n, VSPT(n) est calculé à partir de la liste des chemins les plus courts vers les BN d entrée en partant de la destination. VSPT(n) est envoyé par la suite au PCE du domaine qui le précède (domaine n-1) où il est concaténé au TED du domaine n-1 (comme des liens). 14

15 Cette TED est utilisée par le PCE du domaine n-1 pour calculer le VSPT(n-1). Cette séquence est répétée jusqu à la source Architecture d un nœud PCE Le développement de l architecture PCE a été motivé par de nombreuses exigences (des motivations comme : visibilité limitée, surcoût dans les traitements ( Overhead ), capacité de routage limitée et les réseaux multicouche) pour le calcul de chemins. [13] L architecture PCE [14] est basée soit sur un seul nœud PCE externe (External PCE) [14, 15], soit sur plusieurs PCE qui coopèrent entre eux. La figure 9 montre les composants d'un noeud typique. Ici le noeud est un routeur qui supporte la fonctionnalité PCE et donc qui offre un service de calcul de chemins. Dans un PCE, une base de données de l ingénierie du trafic (TED : Traffic Engineering Database) est maintenue et mise à jour. Le protocole de routage est utilisé pour échanger des informations de type "Traffic Engineering" (TE) à partir desquelles la TED est construite. La TED est utilisée pour calculer les chemins demandés par les PCC. Le PCE qui est externe à l entité qui demande le calcul du chemin utilise sa propre TED (liée à lui) pour les calculs, ensuite il rend les résultats. Plusieurs PCE peuvent être utilisés ensemble pour calculer un chemin dans différents scénarios. Un chemin partiel rendu par un PCE peut nécessiter un autre chemin partiel calculé par un autre PCE pour compléter le chemin. La communication inter-pce peut être aussi le résultat d un calcul coopératif d un seul chemin. Response Figure 9 : Composants d un nœud PCE, [15] Le routage entre le nœud qui a les fonctionnalités de type PCE et un autre routeur peut être effectué par une connectivité directe ou autre mécanisme de tunnel. PCE externe Le PCE peut être mis en œuvre dans un nœud qui ne participe pas au routage du trafic, dans ce sens il est externe ("External"). Il reçoit l information d ingénierie de trafic et participe au plan de contrôle. Dans cette architecture, le PCE utilise les informations contenues dans la TED pour calculer le chemin demandé. Ici, le PCE reçoit les informations 15

16 liées au protocole de routage pour construire le TED. La représentation graphique du PCE externe est donnée dans la figure 10. Figure 10 : PCE externe, [15] En se basant sur ces éléments, un fournisseur peut déployer un modèle de calcul centralisé ou distribué Modes de calcul Mode de calcul centralisé Un mode de calcul centralisé considère que tous les calculs de chemins pour un domaine donné seront effectués par un seul PCE et tous les PCC dans le domaine doivent envoyer leurs demandes de calcul de chemins au PCE central. [14] Mode de calcul distribué Un mode de calcul distribué fait référence à un domaine qui peut comporter plusieurs PCE, et où le calcul de chemins est partagé entre les différents PCE. Un chemin donné peut à son tour être calculé par un seul PCE ("single PCE") ou plusieurs PCE ("multiple PCE"). Le PCC peut être lié à un PCE particulier comme il peut choisir librement entre plusieurs PCE. [14] Single PCE Multiple PCE Mode de calcul centralisé Facilité de mis en œuvre ---- Mode de calcul distribué Partage de charge Partage de charge et coopération plus optimale Tableau 1 : Comparaison entre les différents modes de calcul 16

17 5. Etude comparative entre les deux méthodes de calcul de chemins Les auteurs de l article [13] ont fait une étude comparative entre les deux techniques de calcul de chemins. Ils ont choisi comme contrainte : la taille du TE-Label Switched Path (la bande passante qui va être réservée dans chaque lien du chemin). Mais réellement, il n y a pas que cette contrainte dans les réseaux. Nous pensons qu il sera plus intéressant d analyser le problème en ajoutant d autres contraintes comme le nombre de systèmes autonomes traversés pour atteindre la destination. Nous avons vu dans les chapitres précédents les différentes techniques de calcul de chemins. Après cette phase de calcul, une réservation des ressources tout au long du chemin est lancée par le routeur de tête en utilisant le protocole RSVP-TE (Resource Reservation Protocol avec une extension d ingénierie de trafic). Mais plusieurs questions se posent après l'installation d un chemin et la réservation des ressources. Ces questions sont liées à la TED qui n est pas mise à jour (ou plusieurs TED tout au long du chemin établi). Si la TED d un routeur qui participe au chemin calculé n est pas à jour ou si un BN d entrée n a pas un chemin dans le domaine, un échec de tentative de connexion (CAC Failures : Call Admission Control) sera signalé au point d entrée du routeur qui maintient le lien qui n est pas à jour. Dans ce cas là, si le protocole de routage utilisé est le OSPF-TE, un LSA (Link State Advertisement) est diffusé pour informer tous les autres routeurs locaux dans la même aire OSPF de la nouvelle topologie locale de routage. Si le protocole de routage utilisé est le IS-IS TE, alors un LSP (Link State Packet) est envoyer (flooding) pour informer les autres des nouveaux voisins, la défaillance d un lien ou encore le changement des coûts des liens. Cette inondation permet de mettre à jours les TED, sachant que cela concerne seulement le domaine où le CAC est généré. Le calcul par domaine et le calcul basé sur les PCE se comportent différemment dans cette situation Approche de calcul de chemins basé sur les PCE On a vu avant que cette méthode utilise la notion VSPT. Si un échec du CAC est survenu dans un domaine donné alors un nouveau VSPT est calculé pour ce domaine. Les auteurs de l article [13] disent que le nombre de défaillances du CAC qui ont lieu avec l approche basée PCE est au plus égale à celui de l'approche par domaine Approche de calcul de chemins par-domaine Dans ce cas là, un crankback est utilisé pour rapporter une défaillance de configuration ou installation au routeur qui a essayé d établir le chemin. Pour un domaine i, la k ième entrée est notée BN k en (i ) et la k ième sortie est notée BN k ex (i ). Supposons qu une défaillance CAC est survenue dans un domaine i quand une BN k en (i ) essaya de configurer le chemin vers BN j ex (i ). Dès la réception d une information qui indique qu il y a eu une défaillance, BN k en (i ) essaiera de trouver un nouveau chemin (le plus court possible) vers le routeur de 1 sorti le plus proche BN j + ex ( i ). Ce processus continu jusqu à ce qu il n y a aucun chemin de BN k en (i ) à n importe quelle BN ex ( i ). Dans cette situation, l information de défaillance 17

18 est envoyée de BN k en (i ) à BN k en ( i 1) dans le domaine i-1 en utilisant le mécanisme du crankback. Le BN k ( i + en 1) sélectionne le prochain BN j 1 ex ( i 1) pour entrer le domaine i. L information de défaillance peut être propagée, en utilisant le crankback, jusqu à le domaine source qui contient le routeur qui a demandé la route. Cette procédure se répète jusqu à ce que un chemin puisse être établi ou non Métriques de performance On trouve plusieurs métriques de performances dans l article [13], qui sont utilisées pour capter et comparer les performances des deux approches. Coût du chemin : Le cumul des poids affectés à chaque lien qui constitue le chemin. Echecs de tentatives d établissement de connexion (CAC Failures) : Cette métrique capte le nombre total des échecs du CAC durant la phase initiale de mise en place d un TE- LSP (avec la présence de liens défaillants). Signalisation de retour arrière Crankback Signaling : Cette métrique vise à calculer la distribution du nombre de crankback et le temps que peut prendre la mise en place d un TE-LSP quand on utilise l approche de calcul par domaine. Capacité des TE-LSP/Bande passante : Cette métrique calcule le nombre de TE-LSP avec leur bande passante correspondante qui peuvent être mise en place dans les deux approches. Echec d établissement de TE-LSP/bande passante : Des liens défaillants sont introduits durant la simulation. Cette métrique capte le nombre de TE-LSP et la bande passante correspondante qui n ont pas trouvé leurs routes lors qu il y a des liens défaillants Résultats et analyses Description de l environnement de simulation Les auteurs de [13] ont développé un simulateur afin de représenter une certaine réalité du comportement des réseaux. Pour avoir des résultats significatifs reflétant la topologie réelle des fournisseurs, ils ont choisis deux topologies représentatives des fournisseurs de services actuels. La première topologie est la MESH-CORE [16] et la deuxième topologie est SYM- CORE (Symmetrical backbone), avec quatre petits réseaux (domaines). Ces quatre domaines sont obtenus de [17]. Dans toutes les simulations on trouve les deux cas : PD-setup et PCE-setup (sous les deux topologies). Elles correspondent aux résultats des configurations initiales de la mise en place des TE-LSP dans un réseau vide en utilisant l approche per-domain et l approche basée sur le PCE. La même chose pour PD-Failure et PCE-Failure qui dénotent les résultats avec un scénario où il y a des liens défaillants. La période d une semaine a été simulée les résultats sont collectés après l expiration d une période transitoire. 18

19 Pannes des liens Pour des raisons d analyse et de comparaison, des liens qui peuvent tomber en panne sont envisagés dans tous les domaines. Chaque lien dans un domaine peut tomber en panne indépendamment avec une moyenne de défaillance de 24 heures et restauré avec une moyenne de 15 minutes. Quand un lien tombe en panne, un LSA (Link State Advertisement) est broadcasté par les routeurs adjacents au lien. Après le broadcast toutes les TED des routeurs du même domaine sont mis à jour. Aussi, quand un lien d un chemin TE-LSP tombe en panne, les ressources réservées sont retirées et le routeur de tête (Head-end) essayera de mettre à nouveau le TE-LSP autour de la panne. Notons ici que le lien qui relie deux domaines ne tombe jamais en panne Résultats des simulations Les auteurs de [13] ont montré que durant la mise en place des TE LSP (ou setup), avec ou sans pannes, dans les deux topologies, que l approche de calcul par domaine atteint assez rapidement des coûts élevés par rapport à l approche basée sur le PCE. Cela vient de la capacité de la procédure BRPC à sélectionner le chemin le plus court qui satisfait les contraintes. Pour la défaillance du CAC, leurs schémas [13] montrent bien que le nombre des défaillances CAC est nettement plus supérieur avec l approche de calcul par domaine que l approche basée sur les PCE (ex. dans la topologie MESH-CORE et pour 100% LSP établis, le nombre du CAC Failures est 15 avec l approche de calcul par domaine et seulement 2 avec l approche basée PCE). Une autre simulation concerne le nombre de crankbacks survenants avec l approche de calcul par domaine. Les résultats ont montré que le nombre de crankbacks est le même que le nombre de CAC Failures, cela confirme ce qui est dit dans la section 5.2. Les délais de retard découlant des crankbacks sont très larges, qui peut être très désavantageux à la qualité de service. Les auteurs [13] ont montré clairement que l approche basée sur les PCE permet à plus de TE-LSP de trouver leurs routes et qu elle est plus tolérante aux échecs des liens. Cela est dû à la méthode de calcul elle-même. L approche basée PCE inclus toujours tous les liens qui satisfont les contraintes dans l arbre VSPT. Par contre l approche de calcul par domaine n a pas toutes les informations concernant les liens dans les autres domaines. Donc après un certain nombre de TE-LSP qui sont mis en place, la bande passante restante sera insuffisante pour router toutes les requêtes, ce qui conduit à des échecs d installation de liens. 19

20 6. Conclusion Durant cette recherche bibliographique nous avons montré que les fournisseurs de services ont besoin d une nouvelle architecture qui facilite la négociation, la commercialisation et la production de services de communication évolués. Ainsi, nous avons étudié les travaux menés dans les groupes de recherche et de normalisation, en particulier l IETF et l IPsphere forum. Ces travaux pourraient apporter plus de services, de dynamisme et flexibilité à l interface inter-domaine, facilitant ainsi le déploiement de bout en bout des services évolués dans cette nouvelle architecture. Cette étude a étudié la création, la publication, la gestion et l'activation dynamique des services évolués inter-domaines, qui sont actuellement quasiment inexistants. Mais avec le modèle en couches de IPsphere, nous avons vu que la couche de structuration de service ou «Service Structuring Stratum» (SSS) peut résoudre ces aspects. Les techniques de l ingénierie de trafic sont devenues très importantes pour les fournisseurs de services, afin de gérer les ressources d une façon efficace et fournir une qualité de services (QoS) consistante. L ingénierie de trafic appliquée dans les réseaux MPLS est basée sur des calculs de chemins contraints. Nous avons vu que le processus de calcul de chemins est efficace et facile lorsqu on a un seul domaine. Mais dès qu on passe aux multidomaines, ce processus peut être potentiellement difficile et inefficace. Dans ce cadre là, le groupe de travail PCE de l IETF a développé une architecture qui se base sur une entité de calcul et qui coopère avec d autres entités similaires pour calculer le meilleur chemin à travers différents domaines. Pour montrer les avantages de cette nouvelle entité, nous avons présenté une étude comparative entre les deux approche de calcul de chemins inter-domaines : l approche de calcul basée sur les PCE et l approche de calcul par domaine. Pour des mesures de robustesse et crédibilité, les auteurs de [13] ont choisi deux topologies différentes (MESH-CORE et SYM-CORE). L approche basée sur les PCE a montrée des meilleurs résultats par rapport à celle qui se fait au niveau de chaque domaine séparément. Ce qui nous encourage à continuer sur cette piste. Dans le contexte de ce stage, nous allons proposer des solutions algorithmiques pour les problèmes tels que la négociation de services ou le calcul de chemin contraint. Ces solutions algorithmiques seront évaluées par des simulations et confrontées aux critères de faisabilité, de passage à l'échelle et de stabilité. 20

21 [1] S. Kent, R. Atkinson "Security Architecture for the Internet Protocol", RFC 2401 November [2] E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, January [3] L. Anderson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. LDP Specification, RFC 3036, January [4] Multiprotocol Label Switching (MPLS) Traffic Engineering. CISCO IOS documentation. 0s5/mpls_te.htm [5] R. Zhang, J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", November RFC4216. [6] F. Le Faucheur, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering, June RFC4124. [7] P. Pan, G. Swallow A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", May RFC4090. [8] A. Farrel, J.-P. Vasseur, A. Ayyangar, A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering, November 2006, RFC [9] Y. Lee, G. Bernstein, Path Computation Element Communication Protocol (PCEP) Requirements and Extensions for the Support of Wavelength Switched Optical Networks, November 2, 2007, Internet Draft. [10] J.-L. Le Roux, J.-P. Vasseur, J. Ron, Inter-Carrier Traffic-Engineering LSP Component use-case architecture spec, IPsphere [11] Juniper Network. The Foundation Infranet A Cookbook for Network Service Providers, [12] J. Alateras, C. Australia, IPsphere Framework Technical Specification (Release 1), June [13] S. Dasgupta, J.C. De Oliveira, J.-P. Vasseur, Path-Computation-Element-Based Architecture for Interdomain MPLS/GMPLS Traffic Engineering: Overview and Performance, IEEE Network, July/August [14] A. Farrel, J.-P. Vasseur, J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August