«Conception et implémentation d un nœud DiffServ actif»

Transcription

1 UNIVERSITE LIBANAISE (Faculté de Génie) UNIVERSITE SAINT-JOSEPH (Faculté d'ingénierie) Sous l'égide de l'agence Universitaire de la Francophonie AUF Diplôme d'etudes Approfondies Réseaux de télécommunications «Conception et implémentation d un nœud DiffServ actif» Par Rima TFAILY Encadré par : MM. Yacine GHAMRI Nadjib ACHIR Guy PUJOLLE Soutenance le 19 décembre 2001 devant le jury composé de MM. Samir Tohmé Président Wajdi Najem Membre Imad Mougharbel Membre Mahmoud Doughan Membre Maroun Chamoun Membre Nicolas Rouhana Membre 1

2 Dédicace A ma famille, mon fiancé Ali et mes amis Aux martyrs, aux victimes du terrorisme et de l injustice Aux prisonniers de guère en Palestine occupée Aux enfants handicapés par les mines A mon pays le Liban ET Pour une vie juste, sans racisme, sans gourmand et sans haine Je dédie ce travail modeste 2

3 Remerciements Je remercie tout d abord mes encadreurs exceptionnels Yacine Ghamri Doudane et Nadjib Achir pour leur encouragement et leurs conseils à tout niveau durant la durée de stage. Je voudrais exprimer ma gratitude au prof. Guy Pujolle, Professeur dans le thème réseaux et performance au Lip6, pour m avoir fait l honneur de suivre ce travail. Je n oublie pas Prof. Imad Mougarbel, directeur administratif du DEA, Prof. Samir Tohmé, directeur académique, et mes enseignants à l université libanaise et à l université saint Joseph. Enfin, mes remerciements à tous les membres du thème réseau et performance au laboratoire Lip6 qui ont été gentil et coopératifs. 3

4 Résumé :...8 Chapitre I...11 Introduction Chapitre II...13 Le modèle DiffServ I. Introduction II. Objectifs de DiffServ : III. Les principes de base : IV. Définition du champ DSCP : V. Les règles d applications du champ DS : VI. Le comportement par saut (PHB : Per Hop Behaviour) : VI.1 Le service Expedited Forwarding (EF): VI.1.a. Définition: VI.1.b. La description de l EF PHB : (NB : l IETF ne spécifie pas les PHBS) VI.1.c. Les exigences du service EF: VI.2 Le service Assured Forwarding (AF): VI.2.a. Définition et description du service AF : VI.2.b. Les règles d application : VI.2.c. Un PHB par DEFAULT (Best-EFFORT) : VII. Le modèle Architectural de DiffServ : VII.1. Le domaine DS ou «Differentiated Services Domain»: VII.2. La région DS ou «Differentiated Services Region»: VII.3. Les TCBs des routeurs de DiffServ : VII.4. Classification et Conditionnement de trafic : VII.4.a. «Classifiers» : VII.4.b. «Conditionners» : VII.4.c. «Meter» : VII.4.d. «Marker» : VII.4.e. «Shaper» : VII.4.f. «Droppers» : VII.4.g. Profils de trafic : VIII. Complémentarité et grandes tendances: IX. Conclusion : Chapitre III...26 Le contrôle par politique et le protocole COPS (COMMON OPEN POLICY SERVICE PROTOCOL) I. Le contrôle par politique I.1. Introduction: I.2. Le control par politique: I.2.a. Un exemple de gestion des ressources par politique: I.2.b. Architecture politique inter domaine : II. Le Protocole COPS II.1. Définition du COPS: II.2. Vue conceptuelle de la pile COPS : II.3. Les modèles de la gestion par politique «Policy Management Model»: II.3.a. Le modèle Outsourcing( COPS-RSVP): II.3.a.1. Le rôle du modèle Outsourcing :

5 II.3.a.2. Les messages RSVP-COPS : II.3.b. Le Modèle Provisioning (COPS_PR) : II.3.b.1. Le rôle de COPS-PR : II.3.b.2. Propriétés du COPS-PR: II.3.b.3. Interaction entre PEP et PDP : Dans le cas ou un PEP démarre : Dans les autres cas : III. Conclusion : Chapitre IV...37 Réseaux Actifs I. Les architectures et les applications du réseau actif : I.1. Introduction : I.2. Les Réseaux Actifs : I.3. Les différentes architectures des réseaux actifs I.3.a. L approche par paquet actif : I.3.a.1. Le projet «Smart paquets» I.3.a.2. L Option IP active : I.3.b. L approche par nœud actif (Programmables) I.3.b.1. L architecture ANTS (Active Node Transport System) I.3.c. L approche par paquets et nœuds actifs: I.3.c.1. L'Architecture SwitchWare : I.4. Quelques applications des réseaux actifs : I.4.a. Le caching: I.4.b. Le contrôle de congestion : I.4.c. Le multicast : I.4.d. La gestion des réseaux : I.5. La Sécurité et la Sûreté dans les réseaux actifs: I.6. Active Network Encapsulation Protocol (ANEP): I.7. Conclusion II. La plate- forme ANTS II.1. Introduction : II.2. Les composantes de l architecture : ( protocoles, code groupe et les capsules) : II.3. Format de la capsule : II.4. Le modèle d exécution dans les nœuds actifs : II.5. Le protocole de chargement du code : II.6. Prototype d implémentation : II.6.a. La Classe nœud : II.6.b. La Classe Channel : II.6.c. La Classe Capsule : II.6.d. La Classe Application : II.6.e. Les extensions du nœud actif: II.6.f. La configuration II.7. Avantage et limites de ANTS III. Conclusion Chapitre V...54 L architecture ACDN (Actif Control DiffServ Network) I. Introduction : II. L architecture ACDN II.1. Fonction de filtrage

6 II.2. Exemple d application active : Agrégats adaptés dans un segment du réseau (SATA : Segmented Adaptation of Traffic Agregates) III. Implémentation sous ANTS : III.1. Les disciplines pour les routeurs de bordure : III.2. Les disciplines pour les routeurs de cœur: III.3. Le «design» de programmation : IV. Conclusion: Chapitre VI...65 Conclusion et Perspectives Annexe :...66 Contrôle Actif des Réseaux DiffServ Introduction DiffServ Le contrôle par politiques Les Réseaux Actifs L architecture ACDN Fonction de filtrage Conclusion & Perspectives Bibliographies LES REFERENCES:

7 Liste des Figures et des Tableaux Figure 1 : Région DS et Domaine DS Figure 2 : Blocs de conditionnement de trafic pour le : (a) routeur de bordure, (b) routeur de cœur Figure 3 : Blocs de conditionnement de trafic pour le routeur de cœur Figure 4 : Classifier & conditionner Figure 5 : Exemple de réseau IntServ/DiffServ Figure 6 : Hiérarchie conceptuelle de politique Figure 7 : Modèle de l architecture par politique Figure 8 : Bandwidth Broker Figure 9 : Modèle client/serveur Figure 10 : La pile du COPS Figure 11 : Demander et Reporter une Décision Figure 12 : IntServ/DiffServ, RSVP&COPS Figure 13 : Le modèle COPS Provisioning Figure 14 : Un réseau IP actif Figure 15 : Approche par paquet actif Figure 16 : Architecture du système Smart Packets Figure 17 : Format du champ Option IP Active Figure 18 : L approche par nœud actif Figure 19 : Format de l en tête ANEP Figure 20 : Format du champ Options Figure 21 : Hiérarchie de la composition de la capsule Figure 22 : Format de la capsule Figure 23 : Protocole de chargement sur demande de ANTS Figure 24 : Les principales composantes d ANTS Figure 25 : Architecture de contrôle des réseaux DiffServ Figure 26 : Architecture ACDN Figure 27 : Mise à jour de la table des FlowID et fonction de filtrage Figure 28 : Implémentation du DiffServ Actif Figure 29 : Scénario (1) de différentiation des services Figure 30 : Scénario (2) de différentiation des services Figure 31 : Placement de QdS dans la plate forme ANTS Figure 32 : Hiérarchie des classes (a) Figure 33 : Hiérarchie des classes (b) Figure 34 : Hiérarchie des classes (c) Tableau 1 : Classes de AF Tableau 2 : Les classes et les méthodes d ANTS

8 Résumé : Initialement, l Internet était un outil pour une petite communauté d agences et d organisations, où des services comme le transfert de fichier «FTP», le courrier électronique «SMTP» et les procédures de connexion à distance dominaient. Cependant, avec l apparition de nouveaux types d applications multimédia telles que la vidéoconférence, la téléphonie et le commerce électronique, de nouvelles exigences en qualité de services (QdS) ont vus le jour. Deux approches sont actuellement proposées par l IETF (Internet Engineering Task Force) pour assurer la QdS : L approche IntServ et l approche DiffServ qui est l objet de notre étude. L approche DiffServ, ou services différentiés, normalisée actuellement dans le groupe de travail DiffServ de l IETF, permet d introduire une nouvelle façon de traiter les flux dans le réseau et de partager les ressources de ce dernier. Dans l architecture à différentiation de service, la bande passante, le taux de perte et le délai de transit des paquets sont influencés par les opérations de conditionnement de trafic lors de l entrée dans le réseau ainsi que par les modifications apportées au comportement des routeurs de cœur du réseau. Dans ce type de service, la différenciation s opère au niveau des agrégats plutôt qu au niveau des flux eux-mêmes et ce afin de pallier les problèmes de mise à l échelle. En plus des fonctions permettant la prise en compte de la qualité de service (Modèle DiffServ), l administrateur du réseau et les fournisseurs de services, auront besoins d une infrastructure de gestion leurs permettant de configurer, contrôler et maintenir le niveau de QdS demandée. Cette infrastructure peut se baser sur des politiques dérivées des critères associés aux applications. L une des infrastructures les plus intéressantes pour la mise en place de cette gestion est le modèle de contrôle par politiques. Cette infrastructure est un ensemble de protocoles, modèles d information, et services permettant de traduire les règles administratives sous la forme de traitements différentiés des paquets dans le réseau. Cependant, ces règles administratives sont actuellement introduites de façon manuelle et statique nécessitant souvent une intervention humaine. En effet, l administrateur du réseau doit avoir une connaissance quasi complète de ce qui va se passer dans son réseau afin de pouvoir gérer et configurer ses différents éléments. Ce qui induit, un manque de dynamicité et de réactivité aux éventuels dysfonctionnements (non-respect des SLAs). Pour pallier à cela, nous proposons une architecture où le contrôle se fera en deux phases (i) un contrôle par applications actives, où des algorithmes de contrôle distribués sont déployés, par l administrateur du domaine, dans différents nœuds du réseau, et (ii) un contrôle par politiques actives, qui à partir des informations obtenues par les algorithmes de contrôle distribués, entreprend des décisions au niveau du serveur de politique. Le modèle proposé a donc pour but d introduire un ensemble de fonctionnalités permettant d automatiser et de distribuer le contrôle des différents nœuds du réseau. Le paradigme des réseaux actifs permettra une introduction rapide et transparente de ces fonctionnalités. Les réseaux actifs représentent une nouvelle approche de conception de services réseaux. En effet, leur but réside en la conception, le développement et l implémentation de nouvelles architectures de communications permettant la création, la reconfiguration et le déploiement rapide et sûre de fonctionnalités réseaux avancées. Ces fonctionnalités peuvent aussi bien être des services personnalisés, des protocoles dédiés ou des composants de gestion et de contrôle. En effet, la technologie des réseaux actifs peut être très bénéfique dans ce dernier cas où les réseaux 8

9 actifs vont définir une extension du plan de contrôle. L avantage de cela est que le plan de données pourra continuer à respecter le traditionnel argument de bout en bout. Le modèle ACDN, que nous proposons, est donc composé des éléments suivants : Application de Contrôle : C est l application qui va permettre d installer dynamiquement et de façon automatique de nouveau TCBs dans le réseau. Cette application offre également la possibilité de configurer (provisionner) dynamiquement les TCB en déclenchant l envoi d une décision de configuration par le PDP. Station d administration : L introduction de nouvelles politiques ainsi que des nouveaux algorithmes de contrôle sera réalisée au travers de cette entité. De nouveaux algorithmes de conditionnement de trafic peuvent également être introduit. Cette station aura également pour tache de vérifier la validité et la conformité des politiques introduites dans le policy repository. Serveurs de codes : Ces serveurs contiendront les différents codes des applications actives ainsi que des algorithmes de conditionnement de trafic qui seront utilisés dans le réseau. A chacun de ces serveurs sera associé un mécanisme d installation de code permettant le chargement du code et son installation dans les nœuds. Fonction de filtrage : Les applications actives étant des applications distribuées constituées d agents communicants dans la plupart des cas, il est donc nécessaire que les nœuds puissent interpeller et rediriger les paquets destinés à ces applications. Cette redirection est réalisée grâce à la fonction de filtrage. Le but final de notre travail étant d implémenter un nœud DiffServ actif afin de valider l architecture proposée et ses composantes. Nous avons choisi d utiliser l architecture ANTS 1 développée au MIT 2, et plus précisément la plate-forme ANTS V1.2, écrite en JAVA et développée par le Loria. Cette version permet à ANTS de fonctionner sur IPv6. L architecture ANTS introduit la notion de capsule : un paquet contenant du byte code java avec des données utilisateur (payload). Les API 3 s d ANTS consistent en une Machine Virtuelle Java (JVM 4 ) augmentée par les classes ANTS. Ces classes implémentent les méthodes permettant aux capsules d être interprétées, décodées puis transmises. Dans le plan d implémentation, le nœud DiffServ réside entre le niveau IP et l environnement d exécution, plus précisément, au niveau de la classe "Channel". La classe "Channel", sera modifiée pour créer plusieurs files d attente, chacune correspondant à une classe de service donnée. De plus, au lieu d une discipline de scheduling FIFO, la discipline Priority Queuing (PQ) sera intégré pour servir les différentes files d attente selon leurs priorités. Les différents algorithmes de classification et les éléments constituants le TCB seront également intégrés dans cette classe. Notre travail fait partie du projet RNRT Amarage où d autres partenaires du projet utiliserons notre implémentation pour faire passer des flux Multimédia. Pour cela, nous avons 1 Active Node Transport System 2 Massachusetts Institute of Technology 3 Application Programming Interface 4 Java Virtual Machine 9

10 spécifié une hiérarchie de classes générique pour intégrer les différents éléments du TCB. De plus, nous avons offert des interfaces entre les composants de l architecture ANTS/ACDN pour permettre une extensibilité et utilisabilité facile de notre implémentation. Des études complémentaires sont en cours afin d introduire et de tester différents algorithmes de contrôle distribués. Nous nous intéressons plus particulièrement, aux sondes de métrologies actives et aux algorithmes de provisionning dynamique. Finalement, Un article, soumit à la conférence JDIR 2002 qui se déroulera en mars à Toulouse, France, résume notre travail. Cet article s intitule : Contrôle Actif des Réseaux DiffServ Mots clefs : DiffServ, ANTS, réseaux actifs, contrôle par politiques, contrôle actif. 10

11 Chapitre I Introduction Un des plus grands challenges de ces dernières années est la distribution d applications multimédia à grande échelle en prenant en considération toutes les exigences de celles-ci. De plus, avec l'explosion de l'internet de nouvelles perspectives ont émergées, principalement l'intégration de ces nouvelles applications. Cette intégration offre beaucoup d'avantages incluant une grande couverture, une grande flexibilité et un coût réduit. Cependant, tel que l'internet est conçu actuellement, plusieurs problèmes propres ont été identifiés. Principalement le manque ou l absence de qualité de service (QdS) adéquate à ce type d applications. De ce fait de nouvelles réflexions sur la manière d optimiser l utilisation de ces réseaux ont vu le jour afin de fournir aux applications des services appropriés à leurs exigences. Une des premières solutions proposées par l IETF, pour remédier à ce manque, est l approche IntServ. Cette approche permet de garantir une QdS, par flux, sur le chemin qu il emprunte dans les réseaux. Le principal inconvénient de cette approche est le passage à l échelle (c à d la croissance du nombre de flux traversant un nœud). Pour palier à cet inconvénient, une autre approche, DiffServ ou différentiation de services, a été proposée par l IETF. En effet, cette approche résiste mieux au facteur d échelle puisqu elle assure la QdS à des agrégats plutôt qu aux flux de données individuels. Cette agrégation de flux se traduit en un tri s effectuant aux nœuds de bordure d un réseau en fonction des critères de QdS propres à chaque flux. Dans les nœuds de cœur du réseau, Les traitements différentiés s appliqueront sur des agrégats et non plus sur des flux. Ces traitements, effectués dans les nœuds du réseau, sont appelés algorithmes de conditionnement de trafic et sont organisés en blocs appelés TCB (Traffic Conditionning Bloc). En plus des modèles permettant la prise en compte de la qualité de service (IntServ, DiffServ), l administrateur du réseau et les fournisseurs de services, auront besoins d une infrastructure de gestion leurs permettant de configurer, contrôler et maintenir le niveau de QdS demandée. Cette infrastructure peut se baser sur des politiques dérivées des critères associés aux applications. L une des infrastructures les plus intéressantes pour la mise en place de cette gestion est le modèle de contrôle par politiques. Cette infrastructure est un ensemble de protocoles, modèles d information, et services permettant de traduire les règles administratives sous la forme de traitements différentiés des paquets dans le réseau. Ces règles administratives sont cependant introduites actuellement de façon manuelle et statique. Un utilisateur voulant souscrire à un service (Service Level Agreement, SLA) devra faire parvenir à l administrateur du réseau ses exigences en terme de QdS. En fonction des différentes demandes de QdS, l administrateur introduira donc manuellement les règles administratives appropriées. Cependant aucun moyen n est actuellement offert pour permettre de contrôler la bonne délivrance des SLAs souscrits par les clients, et surtout il n existe aucun moyen de remédier à des éventuels dysfonctionnements dans le réseau (non-respect des SLAs, congestion à long terme, ). Une multitude d algorithmes de contrôle distribués sont actuellement proposés par la communauté de recherche afin de pallier à ces éventuels dysfonctionnements. Comme certains de ces algorithmes nécessitent une architecture très flexible, l utilisation du paradigme des réseaux actifs peut être un moyen d intégration rapide de ce genre d algorithmes dans les architectures courantes telles que DiffServ. Pour atteindre cet objectif, nous proposons dans ce rapport une architecture complète de contrôle pour les réseaux DiffServ. Cette architecture permettra : 11

12 D administrer dynamiquement le réseau en cas de dysfonctionnement aux travers de politiques actives. D offrir une infrastructure flexible pour l introduction d algorithmes de contrôle distribués sous forme d applications actives. La suite du rapport est organisée de la manière suivante : Le chapitre 2 est dédié à la présentation de l approche DiffServ. Au chapitre 3, on présentera le protocole COPS et le contrôle par politique. Une présentation des réseaux actifs se fera au chapitre 4. Le chapitre 5 donne la description détaillée de notre architecture de contrôle actif des réseaux DiffServ (ACDN). Par la suite, On présentera les conclusions et les perspectives au chapitre 6. Finalement, un article résumant ce travail est mis en annexe. Cet article est en cours de soumission pour la conférence JDIR 2002 qui se déroulera à Toulouse (France) en MARS L article s intitule : Contrôle Actif des Réseaux DiffServ 12

13 I. Introduction Chapitre II Le modèle DiffServ Actuellement, La majeure partie des recherches dans le domaine des réseaux consiste à l étude de l introduction de la qualité de service dans l Internet, dominé par un modèle de service de type best-effort. La qualité de service (QdS), qui est un attribut du service, est orientée utilisateur et se mesure à l aide des variables d états qui peuvent être directement observées et mesurées à l endroit où l utilisateur accède au service. Elle est généralement assimilée à la discrimination des services ; Elle englobe tous les mécanismes permettant de différencier le trafic et de le caractériser par des critères comme: le délai, la gigue, le taux d erreur, la bande passante ou le débit. En effet, les mauvaises performances de l Internet best-effort sont dues essentiellement à la quantité de la bande passante disponible (i.e, les congestions allongent les délais, génèrent de la gigue et provoquent la perte de nombreux paquets). Dans la littérature deux différentes approches pour assurer la QdS se distinguent: l approche Informatique propose le surdimensionnement du réseau, une solution simple et un service unique pour tous, le best-effort. L approche Télécom [A.12] propose la gestion de la capacité et les ressources existantes, donc une solution complexe nécessitant des mécanismes de traitement différenciés des différents types de trafics. Augmenter la bande passante est nécessaire comme première étape pour répondre aux contraintes requises par les applications pour assurer la QdS demandée, mais le surdimensionnement a toujours un coût. Cette solution ne résout pas entièrement le problème, même si les ressources sont abondantes. L approche Télécom est donc nécessaire et l IETF (Internet Engineering Task Force) propose l utilisation de l un des deux grands modèles de services suivants : les services intégrés (INTSERV) et les services différenciés (DIFFSERV). Le service DiffServ enrichit le fonctionnement traditionnel de l Internet, best effort, d un certain nombre de possibilités correspondantes à des niveaux de service supérieurs. Le service IntServ donne un niveau de service prévisible et non affecté par les états du réseau. Le modèle INTSERV opère au niveau du flot. Il est basé sur l idée que des mécanismes de réservation de ressources sont nécessaires pour fournir la QoS et que le réseau IntSrev doit être contrôlé et soumis aux mécanismes de contrôle d admission. Le modèle IntServ a fait apparaître un certain nombre de difficultés. Premièrement, la granularité très fine au niveau des micro-flux implique une charge de routage très forte ainsi que la gestion d un très grand nombre de contexte et leur maintien dans tous les nœuds du réseau. Deuxièmement, la charge de signalisation peut être extrêmement importante, et croître avec la taille du réseau et du nombre d utilisateurs connectés. Cette gestion par micro flux est difficile à supporter sur de gros réseaux et constitue un obstacle important à la scalabilité. Par contre, le modèle DiffServ est basé sur une notion d agrégat. Un agrégat étant le regroupement des flux homogènes. Ces flux sont classifiés, marqués de façon identique et transportés entre deux nœuds adjacents. Le transport des agrégats n a pas besoin de signalisation de réservation à travers les nœuds mais un comportement par saut (per Hop Behavior). Ce comportement est basé sur la priorité par classe pour répondre à la QdS demandée sachant que l agrégation des flux offre des services en quelques classes (par Agrégat). Pour offrir de tels services, DiffServ ne suffit pas. Il est nécessaire de le renforcer d une fonction de contrôle d admission. Cette fonction s assure que le réseau pourra bien délivrer un 13

14 service aussi invariable que possible et conforme aux caractéristiques de la charge demandée. Cependant, cette fonction de contrôle d admission ne devra introduire aucune signalisation/ état par flux au niveau du cœur du réseau. II. Objectifs de DiffServ : Pour l IETF, L objectif numéro un de DiffServ, est donc de fournir un moyen de construire des réseaux facilement extensibles, c est à dire «scalables», sans nécessairement gérer des états flux par flux, ni de la signalisation inter nœuds. Ceci est obtenu au moyen de l agrégation des flux en classes offrant des services spécifiques par agrégat. Parmi les autres objectifs, il y a : Traiter une grande variété de types de service et les provisionner de bout en bout ou à l intérieur d un domaine particulier. Découpler le service de l application qui l utilise pour éviter la modification au niveau des applications existantes et pour être capable de fournir des mécanismes efficaces de classification, marquage et conditionnement du traffic 5. Etre indépendant de la signalisation. Utiliser une classification agrégée dans le cœur du réseau et permettre des implémentations simples de la classification des paquets dans les nœuds de cœur du réseau, (BA classifier). Permettre une interopérabilité raisonnable avec des nœuds non DiffServ. Faciliter le déploiement du réseau. III. Les principes de base : Les services différenciés peuvent être soit de bout en bout [A.13], ou inter domaine. Ils sont construits en utilisant une combinaison de : - Positionnement de bits dans l en-tête du paquet IP, au niveau des nœuds de bord. Il s agit de positionner/marquer la valeur du champ de l en tête IP appelé Differentiated Services field ou code point (DSCP). - Déterminer comment ces paquets vont être acheminés par les nœuds à l intérieur du réseau en utilisant le champ DSCP. - Conditionnement des paquets marqués aux bords du réseau, conformément aux exigences ou règles associées à chaque service. Sur le chemin d acheminement, la différenciation des services est réalisée en associant le champ DSCP contenu dans l en-tête du paquet IP à un traitement particulier de «forwarding», au niveau de chaque nœud sur le chemin. Ce traitement s appelle «Per Hop Behavior (PHB)» ou comportement par saut. Les valeurs de champs DSCPs peuvent être choisies dans une collection de valeurs : Soit obligatoires. Soit «recommandées». 5 Qu on va détailler dans les prochains paragraphes. 14

15 Soit avec des significations purement locales. IV. Définition du champ DSCP : C est un champ de remplacement de l en-tête IP nommé champ DiffServ (DS) défini afin de constituer un ensemble étendu du champ TOS de IPv4 [A.13], et du champ «Traffic Class» de Ipv6. Il est utilisé pour désigner son comportement par saut. De plus, il détermine qu elle traitement d acheminement subira un paquet. Seulement, six bits du champ DS sont utilisés comme DSCP pour sélectionner le PHB. La structure du champ DS est la suivante : DSCP La structure du champ DS DSCP: Differentiated Services CodePoint, CU : non utilisés actuellement. CU V. Les règles d applications du champ DS : Un nœud DS doit supporter l équivalent d une table de «mapping» configurable des DSCP sur les PHBs [A.13]. Les spécifications des PHBs doivent inclure un DSCP recommandé par défaut. Les opérateurs peuvent choisir d utiliser différents DSCP pour un même PHB, soit en addition, soit à la place du défaut recommandé. Les paquets reçus avec un DSCP non reconnu devraient être acheminés comme s ils étaient marqués avec le PHB par défaut (DE), sans changer leurs DSCPs. Ces paquets ne doivent pas entraîner de dysfonctionnement au niveau des nœuds du réseau, Les nœuds peuvent marquer les DSCP pour fournir le service local ou de bout en bout désiré. Les spécifications des classes de services (SLS) aux nœuds de bordure sont l objet de «Service Level Agreements, SLA» entre fournisseurs et utilisateurs de services. Ces spécifications ne font pas l objet de standardisations. VI. Le comportement par saut (PHB : Per Hop Behaviour) : En plus des comportements par défaut (BE), comportement Best-Effort, deux autres services sont définis: VI.1 Le service Expedited Forwarding (EF): VI.1.a. Définition: 15

16 EF est défini comme un traitement d acheminement appliqué à un agrégat DiffServ où son débit en sortie dans un nœud quelconque doit être supérieur ou égal à une valeur configurable [A.6]. Il correspond à un service critique similaire à un lien dédié ou VLL (Virtuel Leasing Line) dans lequel un débit instantané et un délai instantané sont garantis. EF possède une forte priorité dans les nœuds et doit cependant être contrôlé pour que la somme des capacités provienne des différentes sources et passant par un même nœud ne dépasse pas la capacité de la liaison de sortie. Le trafic en excès est rejeté. VI.1.b. La description de l EF PHB : (NB : l IETF ne spécifie pas les PHBS) L EF PHB peut être utilisé pour simuler un lien dédié caractérisé par : 1) un faible taux d erreur, 2) un temps de traversée faible, 3) Une gigue minimum, 4) un débit garanti, 5) Un service de bout en bout au travers d un domaine DS. Cependant, la création d un tel service implique deux prérequis : Premièrement, Il faut configurer les nœuds de façon que l agrégat considéré ait un débit maximum de départ indépendant de l état dynamique du nœud (la charge de processing [A.6], l état des files et des ressources mémoire influent sur l état de charge de trafic) et par conséquent, la bufferisation doit être minimale. Deuxièmement, Via les fonctions adéquates de «Dropping : Rejeté les paquets en excès» et de «shaping : retardés les paquets», l agrégat est conditionné de façon que son débit d arrivée dans un nœud soit toujours inférieur au débit maximum de départ. VI.1.c. Les exigences du service EF: Le trafic EF doit être soumis à un débit de façon indépendante de l intensité de tout autre trafic traversant le nœud. Il doit en moyenne être au moins égal au débit configuré sur une période de temps plus grande ou égale que le temps de transmission d une MTU [A.6]. Les débits minimum et maximum peuvent être les mêmes et être configurables via un seul paramètre. Ils doivent être configuré par l administrateur du réseau. Afin que le trafic EF ne monopolise pas les ressources d un nœud, l implémentation doit prévoir des moyens de ne pas nuire aux autres trafics. Le trafic en excès doit être systématiquement détruit. La valeur du champ DSCP recommandé pour EF est «101110». VI.2 Le service Assured Forwarding (AF): VI.2.a. Définition et description du service AF : 16

17 Le service AF est un moyen pour un opérateur d un domaine d offrir différents niveaux de garantie d acheminement. Ces garanties sont associées à des paquets IP en provenance d un domaine source particulier [A.7]. A l inverse de EF, dans AF, il n y a pas de notion de timing quantifiable (délai et gigue) 6. N Classes AF, voir le tableau 1, sont définies dans chaque nœud DS avec leurs ressources d acheminement associées (buffers, bande passante). Les paquets IP, qui veulent utiliser le service mis à disposition par AF, sont attribués par l utilisateur ou l administrateur du domaine DS dans une ou plusieurs de ces classes AF. Cet attribut doit être en accord avec les services auxquels l utilisateur a souscrit. Il s agit dans ce cas de groupes de services réellement différenciés et soumis à des règles de priorités et de précédence. A l intérieur de chaque Classe AF, on associe à un paquet IP une priorité parmi M différents niveaux de priorité d élimination (drop precedence). Un paquet IP appartenant à la i ème Classe AF et ayant une précédence «j» est marqué avec le DSCP AFij avec 1<=i<=N et 1<=j<=M. Actuellement, 4 Classes AF (N=4) et 3 niveaux de précédence dans chaque Classe (M=3) sont prévus. Rien n empêche de définir des nouvelles classes AF pour des utilisations locales. Tableau 1 : Classes de AF Classe 1 Classe 2 Classe 3 Classe 4 Low Drop Prec Haute priorité Med Drop Prec Moyenne priorité High Drop Prec Basse priorité VI.2.b. Les règles d application : Afin que DiffServ fonctionne correctement [A.7], plusieurs règles doivent être respectées : Règle 1 : Un nœud DS devra implémenter les 4 Classes AF. Règle 2 : Les paquets appartenant à une Classe AF doivent être acheminés indépendamment des paquets appartenant à d autres Classes AF. Règle 3 : Un nœud DS ne doit pas agréger plus d une Classe AF. Règle 4 : Un nœud DS doit allouer via la configuration une quantité minimale de ressources d acheminement (espace mémoire et bande passante) à chaque classe AF implémentée. Règle 5 : Chaque classe AF doit supporter le débit configuré pour le service correspondant sur des échelles de temps courtes et longues. Règle 6 : Une Classe AF peut aussi être configurer de façon à recevoir plus de ressources d acheminement que le minimum prévu dans la règle 4 quand des ressources sont non utilisées par d autres Classes AF. 6 Dans EF, la qualification consiste en la minimisation de ces temps là. 17

18 Règle 7 : A l intérieur de chaque Classe AF, un nœud DS doit accepter les trois niveaux de précédence qui doivent produire au moins deux niveaux de probabilité de perte. On admet généralement que deux niveaux devraient être suffisants pour des contextes de congestion normale. Trois niveaux ne se justifiant que dans des domaines DS où la congestion est potentiellement importante. Règle 8 : Un nœud DS ne doit pas réordonner les paquets IP d une micro flux quand ils appartiennent à une même classe AF sans se soucier de leurs précédence. VI.3 Un PHB par DEFAULT (Best-EFFORT) : Le PHB par DEFAULT correspond au comportement classique «best effort». Il doit être présent dans chaque nœud DS [A.7]. Quand il n existe pas d autres contrats, SLA, les paquets concernés sont transportés dans cet agrégat. Il est suggéré que les nœuds DS réservent une certaine bande à ces flux de façon que les utilisateurs classiques «best effort» ne soient pas totalement pénalisés. La valeur DSCP recommandé pour le PHB DEFAULT est «000000». Un paquet marqué pour le traitement par défaut, peut être remarqué en sortie d un domaine en fonction des contrats, SLA convenus entre deux domaines (opérateurs). VII. Le modèle Architectural de DiffServ : L architecture associée à DiffServ est un modèle simple où le trafic entrant dans un réseau est classifié et a la possibilité d être conditionné dans les nœuds de bordures du réseau [A.5], et se voit affecter différents «behavior agregates, BA». Chaque BA est identifié par un seul DSCP. A l intérieur du cœur de réseau, les paquets subissent le traitement adéquat, c est à dire le PHB associé à leur «DSCP». VII.1. Le domaine DS ou «Differentiated Services Domain»: Un domaine DS est un ensemble contigu de nœuds sous une administration commune, déterminant en particulier le service de provisionnement «Service Provisionning». Chaque nœud connaît l ensemble des PHB implémentés. Il a des limites bien définies consistant en des nœuds de bordure «DS Boundary Nodes» qui au moins classent et conditionnent le trafic entrant [A.5], «Ingress traffic», afin de s assurer que les paquets sont correctement marqués pour sélectionner un PHB parmi les PHBs supportés à l intérieur d un domaine DS. A l intérieur du domaine, les nœuds sélectionnent le PHB pour les paquets en se basant sur leurs DSCPs. L administration unique d un Domaine DS est la responsable de la réservation adéquate des ressources et de leur «provisionning» pour supporter les SLAs offerts à l intérieur d un domaine. Les SLAs ne peuvent résulter que d une analyse statistique du comportement du réseau, en fonctions des différents flux. Etant donné que les services sont seulement différenciés sur une base relative d allocation de ressources et de gestion des files. Un SLA passe par un «Traffic Conditionning Agreement, TCA» spécifiant les règles à respecter. Ce TCA est de nature purement administrative. VII.2. La région DS ou «Differentiated Services Region»: 18

19 Une région DS (figure 1) inclut un ensemble de (un ou plusieurs) domaines DS contigus. Les domaines DS dans la région peuvent supporter des groupes de PHBs différents ainsi que différentes correspondances entre DSCP et PHBs [A.5]. Dans une région et au niveau des nœuds du bord, On doit, soit récupérer le trafic pour le délivrer à l utilisateur final, soit assurer l interconnexion avec d autres domaines, d où la notion de Transit. Pour fournir un service homogène sur la région, il est nécessaire dans les nœuds de bordure d établir un SLA qui définit un TCA spécifiant comment le trafic qui transite d un domaine à l autre est conditionné à la limite des deux domaines. C est une tentative de gestion de bout en bout. Mais le problème qui est posé est, comment, en cas d hétérogénéité inter domaines (réseau IP, ATM,..etc), assurer un service de bout en bout? Pour résoudre ce problème, la solution idéale est de passer des accords entre les autorités administratives des différents domaines afin de consolider un SLA de bout en bout. Pour que ces opérations soient faisables, chaque domaine doit avoir une connaissance des PHBs standardisés ou non, utilisés dans le ou les domaines voisins, afin de s y adapter. Mais Ceci n est pas applicable vu des différents niveaux d abstractions dans chaque domaine. Les règles d interconnexion inter domaines pour aboutir à un comportement correct risquent de devenir complexes ou irréalistes. Domaine1DS Région DS Domaine3 DS Domaine2 DS Figure 1 : Région DS et Domaine DS. Les composantes essentielles de l architecture DiffServ et les éléments de conditionnement de trafic seront expliqués dans les paragraphes suivants. Des services différenciés sont étendus au travers d un domaine DS en établissant un SLA entre le domaine DS source et le domaine DS en aval [A.5]. Le TCA inter domaines est dérivé des SLAs. Le SLS d un SLA peut spécifier : - la classification du paquet, - les règles applicables pour le marquage, - les profils de trafic, - Les actions à prendre pour des paquets non conformes en termes de profil de trafic. VII.3. Les TCBs des routeurs de DiffServ : On distingue deux types de routeurs dans l architecture à différentiation de service. Les routeurs de bordure (Edge router) et les routeurs de cœur (Core router). Les routeurs de bordure 19

20 se situent aux frontières d un domaine et se chargent (i) de la mise en forme d un flux en fonction de sa spécification de service (SLS : Service Level Specification) et (ii) de la classification du trafic par l attribution d une étiquette (DSCP : DiffServ Code Point) à chaque paquet entrant dans le domaine (MF classifier). La valeur de cette étiquette pour un flux donné dépend de son SLS et de son comportement instantané (exemple, Three color Marker, paquet in ou out profile). Une fois étiquetée, le paquet utilise le DSCP pour choisir la file d attente adéquate (agrégat adéquat), dans les routeurs de cœur, ainsi que le traitement adéquat en cas de congestion. Le comportement du routeur est donc dépendant du DSCP. La figure (2) montre les blocs de conditionnement de trafic (TCB : Traffic Conditionning Bloc) pour chacun des deux types de routeurs présentés plus haut. Le TCB du routeur de cœur peut contenir des fonctionnalités de mise en forme de trafic (figure 3). Ces fonctionnalités sont nécessaires dans le cas où le réseau n est pas bien dimensionné. Elles sont similaires à celle du routeur de bordure mais elles agissent sur les agrégats et non sur les flux. Ces fonctionnalités sont détaillées dans la section VII.4. Marker1 Meter1 Absolute Dropper1 Classifier /MF Marker2 Meter2 Absolute Dropper2 MUX 1 Marker3 Meter3 Absolute Dropper3 (a) Queue1 Classifier/ BA Shaper/ Scheduler1 Queue2 (b) Figure 2 : Blocs de conditionnement de trafic pour le : (a) routeur de bordure, (b) routeur de cœur. 20

21 Meter1 Queue1 Counter1 Absolute Dropper1 Algorithmic Dropper1 Queue2 Shaper/ Scheduler 1 Classifier/ par agrégat Meter2 Mux1 Algorithmic Dropper2 Queue3 Marker1 Algorithmic Dropper3 Queue4 Figure 3 : Blocs de conditionnement de trafic pour le routeur de cœur. VII.4. Classification et Conditionnement de trafic : Les règles de classification de trafic identifie le sous-ensemble de trafic qui peut recevoir un service différencié par conditionnement et/ou mis en correspondance avec un ou plusieurs BA (par remarquage de DSCP) à l intérieur du domaine DS. Le conditionnement du trafic a en charge de réaliser les opérations suivantes : - «Metering» qui est la mesure du trafic, - «Shaping» qui réorganise la succession des trames en fonction de l objectif final en termes de contraintes de débit et de délai. - «Policing/ Dropping» qui vérifie que le trafic est bien conforme quantitativement au SLA, et effectue les opérations correctives adéquates, - «Marquage» qui assure que le trafic subira un traitement adéquat dans le domaine DS. VII.4.a. «Classifiers» : Il s agit de trier les paquets selon le contenu de certains champs de l en tête du paquet. Deux types de «classifiers» sont définis : - Le «Behavior Agregate (BA) Classifier» qui classifie les paquets uniquement en fonction du DSCP. - Le «MultiField (MF) Classifier» qui classifie les paquets selon des règles beaucoup plus complexes telles que : adresse source/adresse destination, DSCP, protocole, port source et port destination. VII.4.b. «Conditionners» : Les «conditionners» sont composé de 4 composants : 21

22 VII.4.b.1. «Meter» : Le «Meter» mesure les propriétés temporelles d un train de paquets sélectionné par la fonction «classifier», par rapport au profil de trafic qui leur est associé au niveau du TCA. Il passe les informations aux autres membres du «conditionner» selon que les paquets sont dans et hors profile «in and out of profile» afin de prendre les actions de «policing» adéquates. Il doit également pouvoir fournir les informations nécessaires aux règles d ingénieries du trafic «Traffic Engineering» associés à chaque flux, quoi que cette possibilité ne soit pas explicitement prévue dans DiffServ. Les règles d ingénieries du trafic sont appliquées afin de dimensionner le réseau de façon que la probabilité de rejet des paquets sera la plus petite possible. C à d, borner le trafic, dimensionner la file d attente, etc... VII.4.b.2. «Marker» : Le «Marker» positionne le champ DSCP à une valeur particulière et ajoute le paquet marqué à un agrégat particulier. Le Marker peut être configuré pour «marquer» un paquet avec un simple DSCP ou avec un ensemble de DSCP utilisé pour sélectionner un PHB dans un Groupe des PHBs, selon l état du «Meter». C est le cas des «Multicolore Markers». Le «Marker» peut également être amené à changer le DSCP d un paquet, on dit alors qu il a remarqué le paquet. VII.4.b.3. «Shaper» : Le «Shaper» est utilisé pour retarder les paquets d un flux pour être remis en conformité avec le profil du trafic. Cette fonction est assez délicate dans la mesure où la taille des «buffers» est finie et que les flux peuvent avoir des contraintes supplémentaires de délais. De plus, si ces buffers sont pleins, les paquets peuvent être perdus. VII.4.b.4. «Droppers» : Cette fonction est également connue sous le nom de «policing». Elle supprime un certain nombre de paquets afin que le flux de paquets demeure dans le profil du trafic. Les «conditionners» travaillent en relation avec les «classifiers». Leur fonction est essentielle pour un fonctionnement correct de l architecture DiffServ. Les «classifiers» et le «conditionners» aux nœuds de bordure sont configurés en fonction de spécification de services «SLS», couvertes par des fonctions administratives non spécifiées actuellement. La figure (4) suivante donne une représentation possible de l ensemble «classifier» et «conditionner». Meter Classifier Marker Shaper/Drop. 22 Conditionner

23 Figure 4 : Classifier & conditionner 7 VII.4.c. Profils de trafic : Un profil de trafic spécifie les propriétés temporelles d un trafic sélectionné par un «classifier». Il fournit les règles permettant de vérifier si le paquet est dans ou hors profil. Le profil de trafic est optionnel dans DiffServ. Mais c est la seule façon de construire des SLAs et TCAs. VIII. Complémentarité et grandes tendances: La QdS n a aucune importance si elle n est pas de bout en bout. Dans le cas d IntServ, on a une QdS dure mais comme vue précédemment, ce modèle est peu scalable. Par contre, DiffServ n a pas de signalisation mais offre une QdS dite relative et il est scalable. La granularité par micro-flux doit être abandonnée dans le cœur du réseau au profit d agrégats [A.14], qui peuvent être gérés comme des flux. Elle devra être assurée par RSVP, soit de host à host, soit de proche en proche dans le cas où la classification devrait être faite par les nœuds de bordure. RSVP peut être utilisé soit pour transporter des objets IntServ soit des objets DiffServ. La tendance logique est de faire migrer aux «edges» la gestion des «micro-flux», du routage et des métriques nécessaires au «Traffic Engineering», et à l intérieur du réseau la gestion des agrégats ; c.-à-d., utiliser DiffServ dans le cœur réseau et IntServ dans les périphéries (réseaux d accès). Ceci nécessite une mise en correspondance entre les messages RSVP et les PHB. De plus, plusieurs alternatives pour le contrôle d admission du domaine DIFFSERV se présentent (un contrôle d admission à chaque nœud DS, sans contrôle d admission ou autre..) On se dirige donc vers un scénario où la visibilité de l utilisateur est IntServ, alors que le système de communication utilise DiffServ, rendant ainsi IntServ un client de DiffServ. La figure (5) illustre un exemple de ce fonctionnement. 7 Le «Meter» est considéré comme optionnel dans la mesure où, initialement, la notion de profil de trafic n était pas un prérequis dans l architecture DiffServ 23

24 Figure 5 : Exemple de réseau IntServ/DiffServ 1. L émetteur A génère un message RSVP-PATH contenant les caractéristiques du trafic de l application ; 2. Le message PATH a pour rôle d établir les informations d état et les réservations dans les routeurs de la zone 1 où la garantie de QdS est fournie par des méthodes d allocation de ressource/flux ; 3. Le message PATH est acheminé d une manière transparente à travers le réseau de transit DiffServ pour arriver à la zone 2 ; 4. Le message PATH arrive au récepteur B en mettant en place les informations d allocation de ressources dans les routeurs de la zone 2 ; 5. La station B génère un message RSVP-RESV indiquant le niveau de service. Ce message, en retournant vers l émetteur, peut être rejeté dans la zone 2 à cause d un manque de ressources. Sinon, les réservations appropriées sont établies dans les routeurs de la zone 2 ; 6. Les messages RESV traversent la zone DiffServ en «tunnel» jusqu au routeur ER1. A ce niveau, le message est traité par un module DACS (DiffServ Admission Control) qui compare les ressources demandées aux ressources disponibles au niveau du DiffServ correspondant. Si le message RESV est accepté, le DACS soustrait la capacité demandée de la capacité disponible ; 7. Etablissement des réservations dans les routeurs IntServ de la zone 1 où le message RESV peut également échouer par manque de ressources ; 8. L émetteur A reçoit le message RESV ; 9. L émetteur A commence à générer les paquets de la session. Le marquage du champ DSCP se fera au niveau de routeur d entrée du domaine DiffServ (ingress Router) qui est ici BR1. IX. Conclusion : 24

25 DiffServ est basé sur l idée qu il n est pas nécessaire de prévoir de signalisation inter nœuds et que l Administration du Réseau peut être dissociée de ses états. Ce qui a mené à la notion d agrégat, un agrégat étant le regroupement de flux homogènes, classifiés et marqués de façon identique. Les avantages majeurs de la gestion par agrégats sont les suivants : 1) une classification et un marquage plus simples à condition qu ils soient effectués au plus près de la source, 2) une gestion par agrégats qui propage beaucoup moins de contextes dans le réseau, 3) une meilleure scalabilité, 4) une gestion statistique des ressources optimisant les effets du multiplexage statistique Via les mécanismes de marquage, de re-marquage et de shaping intelligent. Le majeur inconvénient est : L absence de notification de congestion, qui pourrait permettre une régulation des microflux, mais qui augmentera la complexité du problème. Dans DiffServ, il est nécessaire de gérer l allocation des ressources du réseau. Afin de réaliser cette gestion, des règles sont associées aux différents flux et agrégats. Cette gestion et le protocole qui s occupe de l échange de ces règles sont le sujet du chapitre suivant. 25

26 Chapitre III Le contrôle par politique et le protocole COPS (COMMON OPEN POLICY SERVICE PROTOCOL) I. Le contrôle par politique I.1. Introduction: Le terme politique [A.9] étant largement utilisé, il est impératif de donner une définition claire dans le contexte des réseaux. Comme point de départ, le terme politique dénote un règlement unifié pour l accès aux ressources et aux services réseaux en se basant sur des critères administratifs. La figure (6) montre les différents niveaux auxquels un tel règlement peut être exprimé et exercé. La vue réseaux d une politique s exprime en terme de performances de bout en bout, de connectivité et d états dynamiques du réseau. Cette vue se compose de plusieurs vues nodales, auxquelles correspondent les objectifs de la politique et ses besoins au niveau de différents nœuds. Celles ci, à leurs tours, sont composées de règles politiques, lesquelles doivent être vues comme des injonctions atomiques à travers lesquelles différents nœuds du réseau sont contrôlés. Comme chaque nœud possède des mécanismes d allocation de ressources spécifiques, chaque vue nodale doit finalement être translater en des instructions spécifiques aux dispositifs hardware du nœud. Niveau Réseau (Topologie, Objectifs réseau, Utilisation globale des ressources) Niveau Noeud (régles de politiques, TCAs, objectifs de QoS) niveau dispositif hardware (Classification, gestion des files d'attentes, ordonnencement) Figure 6 : Hiérarchie conceptuelle de politique. Dans le cas du modèle Diffserv, cette décomposition est aussi valide du fait qu il sépare entre le contrôle par politique et les mécanismes du plan de données [A.10]. Cette séparation permet d ajuster ou d ajouter, au besoin, n importe qu elle contrôle par politique avec une simple reconfiguration ou organisation «remapping» entre politique et mécanismes. Tous les mécanismes implantés restent inchangeables. Ce contrôle par politique sera détaillé dans les paragraphes suivants au travers d un exemple de gestion des ressources par politique et d une architecture politique «inter- domaine». I.2. Le control par politique: Une politique spécifie les règlements d'accès aux ressources du réseau et aux services en se basant sur des critères administratifs. Ces règles contrôlent quels utilisateurs, applications, ou nœud devraient avoir l'accès à quelles ressources et services et sous quelles conditions [A.10]. 26