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

Transcription

Conception et implémentation d’un nœud DiffServ actif
DEA Réseaux de Télécommunications 2000-2001
UNIVERSITE LIBANAISE
UNIVERSITE SAINT-JOSEPH
(Faculté de Génie)
(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é
Wajdi Najem
Imad Mougharbel
Mahmoud Doughan
Maroun Chamoun
Nicolas Rouhana
1
Président
Membre
Membre
Membre
Membre
Membre
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
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
Résumé : ....................................................................................................8
Chapitre I ................................................................................................11
Introduction ............................................................................................................................ 11
Chapitre II ...............................................................................................13
Le modèle DiffServ.............................................................................................................. 13
I. Introduction ................................................................................................................... 13
II. Objectifs de DiffServ : .................................................................................................. 14
III.
Les principes de base : .............................................................................................. 14
IV.
Définition du champ DSCP :..................................................................................... 15
V. Les règles d’applications du champ DS : ...................................................................... 15
VI.
Le comportement par saut (PHB : Per Hop Behaviour) : ......................................... 15
VI.1 Le service Expedited Forwarding (EF): ................................................................ 15
VI.1.a. Définition: ..................................................................................................... 15
VI.1.b. La description de l’EF PHB : (NB : l’IETF ne spécifie pas les PHBS)........ 16
VI.1.c. Les exigences du service EF: ........................................................................ 16
VI.2 Le service Assured Forwarding (AF):................................................................... 16
VI.2.a. Définition et description du service AF : ...................................................... 16
VI.2.b. Les règles d’application :.............................................................................. 17
VI.2.c. Un PHB par DEFAULT (Best-EFFORT) : ................................................... 18
VII. Le modèle Architectural de DiffServ : ...................................................................... 18
VII.1.
Le domaine DS ou « Differentiated Services Domain »:.................................. 18
VII.2.
La région DS ou « Differentiated Services Region »:....................................... 18
VII.3.
Les TCBs des routeurs de DiffServ : ................................................................ 19
VII.4.
Classification et Conditionnement de trafic :.................................................... 21
VII.4.a. « Classifiers » :............................................................................................. 21
VII.4.b. « Conditionners » : ....................................................................................... 21
VII.4.c. « Meter » :................................................................................................. 22
VII.4.d. « Marker » : .............................................................................................. 22
VII.4.e. « Shaper » : ............................................................................................... 22
VII.4.f. « Droppers » : ............................................................................................ 22
VII.4.g. Profils de trafic :........................................................................................... 23
VIII. Complémentarité et grandes tendances:.................................................................... 23
IX.
Conclusion :............................................................................................................... 24
Chapitre III..............................................................................................26
Le contrôle par politique et le protocole COPS ............................................................ 26
(COMMON OPEN POLICY SERVICE PROTOCOL) ....................................................... 26
I. Le contrôle par politique ............................................................................................... 26
I.1.
Introduction: .......................................................................................................... 26
I.2.
Le control par politique:........................................................................................ 26
I.2.a.
Un exemple de gestion des ressources par politique: ................................... 27
I.2.b.
Architecture politique inter –domaine : ........................................................ 28
II. Le Protocole COPS .......................................................................................................... 29
II.1. Définition du COPS: ............................................................................................. 29
II.2. Vue conceptuelle de la pile COPS : ...................................................................... 29
II.3. Les modèles de la gestion par politique « Policy Management Model »:............. 30
II.3.a. Le modèle Outsourcing( COPS-RSVP):........................................................ 30
II.3.a.1. Le rôle du modèle Outsourcing :.......................................................... 30
4
II.3.a.2. Les messages RSVP-COPS :................................................................. 32
II.3.b. Le Modèle Provisioning (COPS_PR) : ......................................................... 32
II.3.b.1. Le rôle de COPS-PR :............................................................................ 32
II.3.b.2. Propriétés du COPS-PR:....................................................................... 33
II.3.b.3. Interaction entre PEP et PDP :............................................................. 33
•
Dans le cas ou un PEP démarre :................................................................... 34
•
Dans les autres cas : ...................................................................................... 34
III.
Conclusion :............................................................................................................... 35
Chapitre IV ..............................................................................................37
Réseaux Actifs....................................................................................................................... 37
I.
Les architectures et les applications du réseau actif :.................................................... 37
I.1.
Introduction : ......................................................................................................... 37
I.2.
Les Réseaux Actifs :.............................................................................................. 37
I.3.
Les différentes architectures des réseaux actifs .................................................... 38
I.3.a.
L’approche par paquet actif : ....................................................................... 38
I.3.a.1. Le projet « Smart paquets » ................................................................... 39
I.3.a.2. L’Option IP active : ................................................................................. 39
I.3.b.
L’approche par nœud actif (Programmables) .............................................. 40
I.3.b.1. L’architecture ANTS (Active Node Transport System). ..................... 40
I.3.c.
L’approche par paquets et nœuds actifs: ...................................................... 40
I.3.c.1. L'Architecture SwitchWare :.................................................................. 41
I.4.
Quelques applications des réseaux actifs : ............................................................ 41
I.4.a.
Le caching:.................................................................................................... 41
I.4.b.
Le contrôle de congestion : ........................................................................... 42
I.4.c.
Le multicast :................................................................................................. 42
I.4.d.
La gestion des réseaux : ................................................................................ 42
I.5.
La Sécurité et la Sûreté dans les réseaux actifs:.................................................... 43
I.6.
Active Network Encapsulation Protocol (ANEP):................................................ 44
I.7.
Conclusion............................................................................................................. 45
II. La plate- forme ANTS................................................................................................... 45
II.1. Introduction : ......................................................................................................... 45
II.2. Les composantes de l’architecture : ( protocoles, code groupe et les capsules) : ............ 46
II.3. Format de la capsule :............................................................................................ 47
II.4. Le modèle d’exécution dans les nœuds actifs : ..................................................... 47
II.5. Le protocole de chargement du code : .................................................................. 48
II.6. Prototype d’implémentation :................................................................................ 49
II.6.a.
La Classe nœud : ........................................................................................... 50
II.6.b.
La Classe Channel : ...................................................................................... 50
II.6.c.
La Classe Capsule :....................................................................................... 51
II.6.d.
La Classe Application : ................................................................................. 51
II.6.e.
Les extensions du nœud actif:........................................................................ 51
II.6.f.
La configuration............................................................................................ 52
II.7. Avantage et limites de ANTS................................................................................ 52
III.
Conclusion................................................................................................................. 52
Chapitre V ...............................................................................................54
L’architecture ACDN (Actif Control DiffServ Network) .......................................... 54
I.
II.
Introduction : ................................................................................................................. 54
L’architecture ACDN .................................................................................................... 54
II.1. Fonction de filtrage ............................................................................................... 56
5
II.2. Exemple d’application active : Agrégats adaptés dans un segment du réseau
(SATA : Segmented Adaptation of Traffic Agregates) .................................................... 57
III.
Implémentation sous ANTS :.................................................................................... 58
III.1.
Les disciplines pour les routeurs de bordure :................................................... 60
III.2.
Les disciplines pour les routeurs de cœur: ........................................................ 60
III.3.
Le « design » de programmation :..................................................................... 60
IV.
Conclusion:................................................................................................................ 64
Chapitre VI ..............................................................................................65
Conclusion et Perspectives ................................................................................................. 65
Annexe :.................................................................................................66
Contrôle Actif des Réseaux DiffServ .............................................................................. 66
Introduction ............................................................................................................................... 66
DiffServ ..................................................................................................................................... 67
Le contrôle par politiques.......................................................................................................... 69
Les Réseaux Actifs.................................................................................................................... 70
L’architecture ACDN ................................................................................................................ 71
Fonction de filtrage ............................................................................................................... 73
Conclusion & Perspectives........................................................................................................ 74
Bibliographies ........................................................................................................................... 75
LES REFERENCES: ...........................................................................76
6
Liste des Figures et des Tableaux
Figure 1 : Région DS et Domaine DS......................................................................................... 19
Figure 2 : Blocs de conditionnement de trafic pour le : (a) routeur de bordure, (b) routeur
de cœur. ................................................................................................................................ 20
Figure 3 : Blocs de conditionnement de trafic pour le routeur de cœur. ............................... 21
Figure 4 : Classifier & conditionner.......................................................................................... 23
Figure 5 : Exemple de réseau IntServ/DiffServ........................................................................ 24
Figure 6 : Hiérarchie conceptuelle de politique........................................................................ 26
Figure 7 : Modèle de l’architecture par politique .................................................................... 27
Figure 8 : Bandwidth Broker ..................................................................................................... 28
Figure 9 : Modèle client/serveur ................................................................................................ 29
Figure 10 : La pile du COPS ...................................................................................................... 30
Figure 11 : Demander et Reporter une Décision...................................................................... 31
Figure 12 : IntServ/DiffServ, RSVP&COPS ............................................................................ 31
Figure 13 : Le modèle COPS Provisioning. .............................................................................. 32
Figure 14 : Un réseau IP actif .................................................................................................... 37
Figure 15 : Approche par paquet actif ...................................................................................... 38
Figure 16 : Architecture du système Smart Packets...................................................................... 39
Figure 17 : Format du champ Option IP Active ...................................................................... 40
Figure 18 : L’approche par nœud actif. .................................................................................... 40
Figure 19 : Format de l’en tête ANEP....................................................................................... 44
Figure 20 : Format du champ Options...................................................................................... 44
Figure 21 : Hiérarchie de la composition de la capsule ........................................................... 46
Figure 22 : Format de la capsule................................................................................................ 47
Figure 23 : Protocole de chargement sur demande de ANTS. ................................................ 48
Figure 24 : Les principales composantes d’ANTS. .................................................................. 50
Figure 25 : Architecture de contrôle des réseaux DiffServ. .................................................... 54
Figure 26 : Architecture ACDN. ................................................................................................ 56
Figure 27 : Mise à jour de la table des FlowID et fonction de filtrage ................................... 57
Figure 28 : Implémentation du DiffServ Actif.......................................................................... 58
Figure 29 : Scénario (1) de différentiation des services. .......................................................... 59
Figure 30 : Scénario (2) de différentiation des services ........................................................... 59
Figure 31 : Placement de QdS dans la plate forme ANTS. ..................................................... 61
Figure 32 : Hiérarchie des classes (a) ........................................................................................ 62
Figure 33 : Hiérarchie des classes (b) ........................................................................................ 62
Figure 34 : Hiérarchie des classes (c) ........................................................................................ 62
Tableau 1 : Classes de AF........................................................................................................... 17
Tableau 2 : Les classes et les méthodes d’ANTS ...................................................................... 49
7
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
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 ANTS1
développée au MIT2, 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 API3s d’ANTS consistent en une Machine Virtuelle
Java (JVM4) 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
Massachusetts Institute of Technology
3
Application Programming Interface
4
Java Virtual Machine
2
9
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
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,
gestion est le modèle de contrôle par politiques. Cette infrastructure est un ensemble de
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
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 2002. L’article s’intitule :
Contrôle Actif des Réseaux DiffServ
12
Chapitre II
Le modèle DiffServ
I. Introduction
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
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 traffic5.
• 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 :
•
•
5
Soit obligatoires.
Soit « recommandées ».
Qu’on va détailler dans les prochains paragraphes.
14
•
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 :
0
1
2
3
4
5
6
7
CU
DSCP
La structure du champ DS
DSCP: Differentiated Services CodePoint,
CU : non utilisés actuellement.
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
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
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.
001010
010010
011010
100010
Haute priorité
Med Drop Prec.
001100
010100
011100
100100
Moyenne priorité
High Drop Prec.
001110
010110
011110
100110
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
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
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
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
Marker3
MUX
1
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
Meter1
Queue1
Counter1
Absolute
Dropper1
Algorithmic
Dropper1
Meter2
Mux1
Algorithmic
Dropper2
Queue2
Shaper/
Scheduler
1
Queue3
Classifier/
par agrégat
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
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
Conditionner
22
Shaper/Drop.
Figure 4 : Classifier & conditionner7
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
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
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
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
PEP
PEP
PEP
PDP
Management tool
PEP
PDP
Policy Repository
Policy domain
Figure 7 : Modèle de l’architecture par politique
Au lieu de configurer les nœuds du réseau individuellement, Les ISP (Internet services
provider) et les administrateurs d'entreprise souhaiteraient configurer le réseau à travers une
infrastructure par politique. Cette dernière fournit un support pour la traduction de règles
administratives en des traitements différentiés des paquets.
La figure (7) représente une architecture typique « par politique ». Chaque domaine peut
contenir un serveur de politique ou plus dont sa fonction est de choisir les politiques et prendre
les décisions pour la configuration des nœuds du réseau. Le serveur de politique a accès à une
base de données des politiques (via LDAP ou SQL). Chaque entrée de la politique spécifie une
règle de “si une certaine condition se réalise, alors exécute l’action correspondante”.
L’administrateur du réseau utilise une « GUI8 management application » pour mettre à jour et
surveiller l’évolution de la base de données des politiques.
Le serveur de politique consiste en un contrôleur de politique central (CPC) et un ensemble
de PDP. Ces derniers sont responsables de déterminer quelles actions sont applicables à quels
paquets. Le CPC est là pour assurer la consistance globale entre les décisions prises par les PDPs,
et la mise en application (enforcement)9 et l'exécution des actions au niveau des PEP. Un PEP est
généralement colocalisé avec un routeur. Certains composants du réseau peuvent être assez
puissants et flexibles pour prendre leurs propres décisions politiques et les enforcer.
I.2.a. Un exemple de gestion des ressources par politique:
Le Bandwidth Broker (BB) est une entité de gestion qui permet l’allocation de ressources
intra-domaine et négocie des contrats de trafic inter-domaine [A.10]. Un BB pour chaque
domaine peut être configuré avec des politiques d’organisation; Il contrôle les opérations des
routeurs de bord. Du point de vue structure politique, un BB inclut la base de données des
politiques d’allocation de ressources, tandis que les routeurs de bord sont vue comme PEP.
8
9
graphical user interface
Enforcer des décisions d’une politique consiste à traiter les paquets selon les règles qui existent dans la décision.
27
Figure 8 : Bandwidth Broker
Dans son rôle inter-domaine, un BB négocie avec ses domaines voisins, établit des accords
bilatéraux avec chacun d'eux, et envoie les paramètres de configuration appropriés à ces routeurs
de bordure concernés par ces accords bilatéraux (figure 8). L’agrément bilatéral veut dire qu'un
BB a seulement besoin de se co-ordonner avec ses domaines adjacents. La QdS de bout en bout
est assurée par les allocations des ressources intra domaine et par leurs concaténations. Les
concaténations étant assurée par les accords bilatéraux.
Dans un domaine, un BB accomplit l'allocation des ressources à travers un algorithme de
contrôle d'admission propre au domaine. Le choix de l'algorithme de contrôle d’admission est
indépendant de la négociation inter- domaine. Ces allocations fournies par l’agent BB du PDP
peuvent être statiques, dynamiques ou mixtes [A.8] ; Chaque politique permet, par exemple, une
facturation différente.
Un BB est associé à chaque domaine DiffServ, même si on peut prévoir des hiérarchies de
BBs à l’intérieur d’un même domaine. Dans ce cas c’est le BB au sommet de la hiérarchie qui
prend en charge cette communication « inter-domaines ».
I.2.b.
Architecture politique inter –domaine :
Dans un réseau multi-domaines, c'est irréaliste et non scalable de supposer un seul point de
contrôle administratif pour le réseau tout entier [A.9]. Par conséquent, chaque domaine est placé
sous le contrôle administratif d'un PDP. Ces domaines indépendants communiquent afin
d’échanger entre eux des informations de contrôle. C’est une communication bilatérale ; Les
domaines adjacents négocient pour déterminer la nature et le volume du trafic qui passera au
travers leurs limites communes. Comme partie de ce processus, chaque domaine décrit sa
demande de QdS au PDP voisin. Ce dernier fournit une décision de l'admission ou de la non
admission basée sur : (i) sa disponibilité en ressource, (ii) les arrangements financiers bilatéraux,
et (iii) sur l'ensemble des politiques administratives. Chaque PDP exécute trois tâches distinctes:
- Négociation de SLAs avec PDPs les domaines avoisinants,
- Traduction de SLAs en un ou plusieurs TCAs pour les edges routeurs,
- La mise en place des TCAs aux routeurs de bordure correspondants du domaine
administré.
28
Dans le contexte de l'inter-domaine, les routeurs de bordure qui sont à la limite entre deux
domaines jouent un rôle spécial dans la mise en application du SLA entre les deux domaines.
Notons que, le SLA est un élément Niveau Réseau, alors qu'un TCA est un élément Niveau
Nœud (figure 6). Le TCA va être la portion des paramètres du SLA qui sont en rapport avec le
rôle du routeur de bordure.
Pour que le PDP communique avec les routeurs du domaine qu'il administre, plusieurs
protocoles ont été développés. Parmi ceux là, on a le protocole COPS qui est actuellement le
candidat le plus utilisé pour cette tache. Ce protocole sera l'objet de la deuxième partie de ce
chapitre.
II. Le Protocole COPS
II.1.
Définition du COPS:
C’est un protocole du type client/serveur (requête/réponse) développé par le groupe de
travail RAP de l’IETF (Ressource Allocation Protocol) pour assurer des fonctions de contrôle
d’admissions basées sur des règles politiques [A.1] .
Comme vue sur la figure 9, le protocole COPS est utilisé pour échanger, d’une façon
bidirectionnelle dynamique, les informations entre un client PEP10 et un serveur des
règles PDP11. Il est basé sur le concept du type de client, (i.e il permet d’ajouter de nouveaux
types de client sans avoir modifier la base du protocole).
PEP
PDP
COPS
Figure 9 : Modèle client/serveur
II.2.
Vue conceptuelle de la pile COPS :
La pile du protocole COPS peut être conceptuellement divisée en trois couches distinctes
(figure 10 (a) et (b)) : La couche de base du protocole, la couche qui contient les directives pour
un type de client, et la couche qui représente les règles de données.
Policy Data Representation
Client-Type usage Directives
The Base Protocol
(a)
10
11
Policy Enforcement Point
Policy Decision Point
29
RSVP Policy
Data Object
COPS-RSVP
Client-type=1
PIB(Policy
Information Base)
COPS-PR
Client-type=
COPS
COPSClient-type=
(b)
Figure 10 : La pile du COPS
Le client PEP12 a pour rôle de demander une politique d’un serveur PDP qui à son tour lui
communique des décisions politiques [A.1]. Il est responsable d’initier une connexion persistante
TCP au PDP. Cette connexion sera utiliser pour envoyer des demandes et recevoir des décisions.
Il a aussi la capacité de rapporter au PDP (figure 11) qu’il a complété avec succès ou non,
l’exécution de ces décisions. De plus, il est responsable de notifier au PDP de tous les états de
demande qui ont été changés.
II.3.
Les modèles de la gestion par politique « Policy Management Model »:
La gestion par politique fonctionne suivant l’un de des deux modèles suivant: le modèle
Outsourcing (COPS-RSVP) [A.2] et le modèle de Provisionning (COPS-PR) [A.3]. Dans ces
deux modèles, le PEP reçoit les décisions politiques « Policy Decisions » et les appliquent au
niveau des paquets. Le protocole COPS spécifie les caractères fonctionnels de ces deux modèles.
II.3.a.
Le modèle Outsourcing( COPS-RSVP):
II.3.a.1. Le rôle du modèle Outsourcing :
Dans le cas du Outsourcing, le PDP reçoit la demande de politique « Policy Request » d’un
PEP (figure 11 et 12), et décide s’il l’autorise ou non [A.2, A.4]. Typiquement, c’est une décision
de contrôle d’admission liée à un message RSVP pour la réservation des ressources. Basé sur
l’idée de trouver dans le Policy Repository la politique demandée, c- à- d, si
l’utilisateur/application qui demande les ressources a le privilège pour les réserver, le PDP
permet au message RSVP de traverser le réseau, ou autrement il le rejette.
Quand le PEP reçoit un message RSVP qui demande une décision politique, les objets de
RSVP sont encapsulés à l’intérieur de l’objet « Signaled ClientSI » dans un message de requête
de COPS qui est envoyé au PDP.
Le PDP décide si ce message RSVP doit être accepté, envoyer à la ‘Next Hop’ou non
accepter ; Puis le PDP envoie une décision au PEP comme une réponse à la requête. Des
décisions consécutives peuvent être envoyer pour la même requête, si le PDP voit que la décision
politique originale a besoin d’être changé ou supprimé.
Dans le cas ou le PDP détecte l’absence d’un objet RSVP essentiel dans la requête, il doit
retourner un message d’erreur dans la décision qui indique « Mandatory client-specific info
12
Le client PEP peut être un composant faisant parti d’un routeur supportant RSVP, ou DiffServ ou bien les deux.
30
missing ». Dans le cas ou le PDP détecte l’absence d’un objet RSVP optionnel dans la requête, il
doit retourner une décision négative.
server
(PDP)
Decision
Messages
Request
Messages
COPS
Report
Messages
client
(PEP)
Figure 11 : Demander et Reporter une Décision
Pour chaque message de décision reçu, le PEP envoie un rapport (RPT) au PDP qui inclus
les actions qui l’a entrepris (Pour assurer que les décisions sont convenablement installées ou
pour détecter une erreur avec n’importe quelle installation), ainsi le PDP sera « up to date » de la
politique actuellement installé au niveau du PEP.
RSVP a défini l’objet « POLICY DATA » qui joue le rôle d’un cantenaire pour transporter
les informations politiques dans le message RSVP. Quand un message RSVP arrive au PEP, le
PEP communique l’objet « POLICY DATA » au PDP. Le PDP prend sa décision en se basant,
entre autre, sur le contenu de l’objet « POLICY DATA ». Le PDP peut aussi modifier ou
remplacer le ‘POLICY DATA’ pour un « Outgoing RSVP message ».
Figure 12 : IntServ/DiffServ, RSVP&COPS
Le PEP peut avoir la capacité de prendre une décision politique locale via son LPDP (Local
Policy Decision Point). Il doit envoyer cette décision locale au PDP via un objet de décision de
31
LPDP. Le PDP doit prendre alors la décision finale et l’envoie au PEP lequel doit rester fidèle
d’une manière absolue à la décision du PDP.
II.3.a.2. Les messages RSVP-COPS :
Il existe sept types de messages RSVP. Ils sont transportés dans des paquets IP. Ces types
sont : Les messages de réservation (RESV), les messages de route (PATH), les messages de fin
de réservation (RESVTEAR), les messages de fin de route (PATHTEAR), le message optionnel
de confirmation de réservation (RESVCONF) ,et les messages d’erreur (RESVERR) et
(PATHERR). Quatre de ces messages RSVP sont supportés par COPS [A.2]: Path, Resv,
PathErr, ResvErr. Par contre, les autres types de message tel que PathTear, ResvTear, et
ResvConfirm ne le sont pas.
II.3.b.
Le Modèle Provisioning (COPS_PR) :
II.3.b.1. Le rôle de COPS-PR :
Dans le cas du provisioning, quand une nouvelle politique est entrée à la console de
gestion, les politiques sont distribuées en temps réel au PDP (Voir figures 12 et 13). Le PDP
décide alors si la politique doit ou ne doit pas être installée [A.3]. Si les critères sont satisfaits, le
PDP emballe les règles de politique dans un ordre de configuration de telle sorte à ce que le PEP
puisse l’interpréter, et envoie les directives au PEP. PDP met l’information de configuration dans
le PEP et élimine les états du PEP qui ne plus valables.
Le PDP traite simultanément les données politiques qui ont été saisies dans le système de
gestion de politique et les informations sur les ressources du réseau pour prendre les décisions
politiques et pour envoyer des directives aux PEPs du réseau.
Dans ce modèle, il n’y a pas des mécanismes de signalisation de QdS, mais un modèle de
‘PUSH’ est utilisé. Le PDP réagit aux événements externes non venus de PEP tel que : le
changement de politique appliqué, l’heure actuelle, expiration de compte …etc, ou venus du PEP
ou une combinaison des deux et par suite met l’information de configuration au niveau de PEP.
Le « Provisioning » peut être exécuté en gros (par exemple, configuration d’un routeur) ou
en partie (par exemple, mettre à jour un DiffServ marking filter).
QoS
policy rules
External
policy
Event
decision
point
QoS
provisioning
COPS data
provisioning
request
Donnée
data
utilisateur
PEP
Figure 13 : Le modèle COPS Provisioning.
32
Dans COPS - PR, les demandes politiques décrivent le PEP et les paramètres à configurer
plutôt qu'un événement externe. Si un changement se produit dans ces paramètres de base, une
demande de mise à jour est envoyée. Les demandes sont tout à fait rares. Les décisions envoyées
par le PDP sont prises en réponse à des évènements externes arrivée d’un nouveau flux.
Au départ le PDP analyse les règles politiques en considérant les informations externes
pour prendre les décisions politiques. Puis ces décisions sont envoyées d’une manière asynchrone
du PDP au PEP pour l’exécuter. C’est à dire : le PDP prédit les besoins de configuration, et les
envoies au PEP en avance. Au lieu de répondre aux évènements du PEP. Enfin le PEP confirme
si l’installation (de configuration) de cette décision est réussie ou non.
Les données ‘DATA’ transportée par COPS-PR sont un ensemble de données politique
‘Policy Data’. Ces données sont connues sous le nom de PIB (Policy Information Base = La base
de donnée des informations politiques). Les PIBs sont des structure de données proposées pour
être utilisé avec le protocole COPS-PR. Elles décrivent politiques et le format des informations
politique à échanger entre le PEP et le PDP. La PIB contient des informations qui décrivent
techniques de classification et de conditionnement des paquets. La PIB est extensible et flexible
pour additionner des nouveaux type de paramètre provisionnel. Un domaine administratif peut
avoir une PIB ou plus et des domaines administratifs différents peuvent avoir des ensembles
différents de PIBs.
Un modèle incluant plusieurs PDPs contrôlant des régions politiques différentes, le clienttype spécifié par le PEP au PDP est unique. Chaque région politique sera déterminée par un
client-type qui sera utilisé pour toutes les PIBs existant dans cette région. C à d le PEP devrait
traiter indépendamment tous les types de client COPS_PR qui les supporte, i.e leurs instances ne
doivent pas être partagées.
II.3.b.2. Propriétés du COPS-PR:
•
COPS – PR assure un transport effectif d'attributs [A.3] et des grandes transactions
atomiques de données.
•
Comme il n’y a qu’une seule connexion entre le client PEP et un serveur PDP pour une
région de politique identifiée par un COPS Client-Type, ceci garantit qu’un seul serveur
met à jour une configuration particulière de politique à un moment donné.
•
COPS-PR peut être utilisé pour la configuration des différents types de réseaux de
service (DiffServ, MPLS, …etc) au travers la configuration de ses routeurs.
•
COPS utilise la communication fiable TCP ainsi qu’un mécanisme de
partage/synchronisation, par la suite il échange uniquement les mises à jour
différentielles [A.1]. Si le serveur ou le client est redémarrés le second le détecte
rapidement.
•
C’est un mécanisme de communication conduit par des événements temps réel.
II.3.b.3. Interaction entre PEP et PDP :
33
• Dans le cas ou un PEP démarre :
Quand un PEP démarre « boot », il ouvre une connexion COPS avec son PDP primaire
[A.3]. Une fois la connexion établie, le PEP envoie des informations à propos de lui au PDP sous
forme d’une requête de configuration. Ces informations spécifient les caractéristiques de client
(type de matériel ’Hardware’; le logiciel utilisé ; information de configuration).
Le PDP répond à cette requête de configuration en faisant un téléchargement de toutes les
politiques provisionnelles qui sont actuellement approprié pour ce PEP. En recevant ces
politiques provisionnelles, le PEP les organise et les installe. S’il y a des conditions qui sont
changées au niveau du PDP tel qu’il détecte que ces changements exigent une mise à jour des
politiques courantes, le PDP les envoie (Installe, mise à jour, et/ou efface) en politiques au PEP,
qui a son tour met à jour convenablement sa configuration locale.
Si la configuration de PEP change (carte supprimée, carte ajoutée, nouveau software
installé, …) de manière qu’elle ne soit pas couverte par les politiques déjà connus par le PEP ; Le
PEP envoie d’une manière asynchrone ces nouvelles informations non sollicité au PDP dans une
(Update request configuration). En recevant cette nouvelle information, le PDP envoie au PEP
les politiques provisionnelles supplémentaires dont le PEP a besoin, et supprime les politiques
qui ne sont plus nécessaires.
• Dans les autres cas :
Le protocole COPS utilise une connexion TCP, initiée par le PEP. Dès que la connexion est
établie, le PEP envoie un message client_open qui spécifie le type du client. Si le PDP supporte
le type du client de provisionnement spécifié, le PDP répond avec un message Client Accepte
(CAT). Si ce type du client n'est pas supporté, un message Client - close (CC) est retourné par le
PDP au PEP, en lui spécifiant éventuellement un serveur alternatif qui peut supporter la politique
pour le type de client donné.
Après avoir reçu le message CAT, le PEP peut envoyer des requêtes (REQ) au serveur. Le
message REQ contient un « Configuration Request context object » et, facultativement, des
clientSI du PEP. Les informations fournies par ce PEP devraient inclure les ressources
disponibles du client (par exemple, les classes/attributs supportés) et l’information de
configuration de la politique par défaut aussi bien que les données sur la politique existante.
Le message de la demande de configuration d'un client sert pour :
• Donner les informations que le PEP a spécifié dans son message REQ. C'est une
demande au PDP pour toutes les données de configuration que le PDP peut avoir et
lesquelles sont convenables actuellement pour le PEP, tel que les filtres de contrôle
d’accès.
Ou encore
•
13
Ouvrir un canal qui autorisera le PDP, quand c’est nécessaire, d’envoyer de façon
asynchrone les données de la politique au PEP, aussi longtemps que le PEP maintient
son état de demande ouvert (c.-à-d., dès que le PEP n'envoie pas de message « DRQ13 »
spécifiant le « Client Handle » déjà indiqué dans la requête). Ces données peuvent être
Delete Requeste
34
des nouvelles données de la politique ou une mise à jour des données envoyées
précédemment. Tout changement au niveau du PEP est communiqué au PDP via un
message « Updated REQ ».
Après l’envoie d’un message REQ, si le PDP a les données de la politique de configuration
pour le client, alors ces informations sont encapsulés dans un objet « decision data object » et
sont transmise au client dans un message DEC (message de décision) qui spécifie le code de
commande " Install " dans l'objet « Decision Flags ».
Si aucun filtre n’est défini, le message DEC va simplement spécifier qu'il n'y a pas de filtres en
utilisant le commande « NULL Decision » dans l'objet « Decision Flags ». Le PDP copie, dans
les deux cas, le « Client Handle » du message REQ dans le message de la décision.
Le PDP peut ajouter de nouvelles données d’une politique, il peut aussi mettre à jour ou
supprimer des configurations déjà installées en envoyant des messages de décision subséquentes,
mais non sollicités par le PEP, avec le même Client Handle. Le PEP a la possibilité de ne plus
spécifier le client Handle lorsque ce dernier n'est plus nécessaire, par exemple quand une
interface tombe en panne, et pour informer le PDP que le Client Handle doit être effacé par le
message DRQ.
Le PDP peut aussi commander au PEP l’ouverture d’une nouvelle requête d’état (code de
commande « install ») en positionnant le drapeau « Request- state flag » de l’objet « Decision
flags » ou en effaçant une requête existante (code de commande « Remove »). Par la suite, le
PEP crée une nouvelle requête spécifiant le client Handle ou génère un message delete request
DRQ. Les États « request states » existants ne sont affectés par l’échec d’une nouvelle requête
grâce à son indépendance.
Le PEP doit acquitter le message « DEC » et spécifier quelles actions il a pris en envoyant
un message « RPT » sollicité avec un « report-type object » indiquant le " Succès " ou l’"échec ".
Le compte-rendu sert à indiquer au PDP que le demandeur peut être notifié si la demande a été
acceptée par le réseau ou pas.
Si le PEP a besoin de refuser une décision, un message « RPT » est envoyé avec un
« Report-Type » et facultativement un « Client specific Information object » qui spécifie les
données de la politique qui ont été repoussées. En cas d’échec, le PEP doit toujours retourner à
ses états installés précédemment. Le PDP est libre de modifier sa décision et ressayer.
Finalement, les messages « Client - close (CC) » sont utilisés pour annuler le message
« Client – Open » correspondant. Le message « CC » informe l'autre extrémité que le client type
spécifié n'est plus supporté.
III. Conclusion :
Un domaine de politique est la portion d’un réseau qui est administrée et gérée par un
même ensemble de politique. Ces politiques seront stockées dans une entité appelée policy
repository. Le PEP est l’élément responsable de l’application et de l’exécution des actions de la
politique, c’est également l’élément qui va prendre en charge le traitement des paquets en
fonction d’une politique donnée. Le PDP, quant à lui, a pour tache de déterminer quelle action va
être appliquée et à quel paquet. Le PDP interprète les règles des politiques, stockées dans le
policy repository, pour un ou plusieurs PEPs. Pour cela le PDP se base sur les conditions
courantes du réseau ainsi que sur les informations transmises par ces derniers en utilisant un
35
protocole de signalisation tels que COPS. En effet le protocole COPS semble être le candidat
privilégié par l’IETF pour cette tache.
Le PEP peut demander au PDP de prendre des décisions en son nom sur l’occurrence d’un
événement (modèle Outsourcing) ou faire une demande de configuration (modèle Provisionning).
Dans le cas de DiffServ par exemple, le modèle Outsourcing permettrait de faire un contrôle
d’admission au niveau des routeurs de bordures. Le protocole COPS PR, quant à lui, permettrait
de transporter les décisions permettant de configurer les TCBs des routeurs de bordure et des
routeurs de cœur. Notons cependant qu’aucun mécanisme ne permet à ce jour de mettre en place
dynamiquement les TCBs qui sont implantés de façon statique dans les routeurs et utilisent des
algorithmes de conditionnement implémentés en hardware. La technologie des réseaux actifs
peut donc être efficacement utilisée dans ce but, permettant ainsi de mettre en place
dynamiquement les TCBs et de déployer dynamiquement de nouveaux algorithmes de
conditionnement aux besoins. Les réseaux actifs sont le sujet du chapitre suivant.
36
Chapitre IV
Réseaux Actifs
I. Les architectures et les applications du réseau actif :
I.1. Introduction :
Traditionnellement, la fonction d'un réseau a été la transmission des paquets d'un hôte à un
autre. De plus, le traitement dans le réseau à fondamentalement été limité à l’acheminent des
paquets , au contrôle de congestion et à la qualité de service (QdS)[B.1]. Ce genre de réseau peut
être considéré comme " passif ". Mais, Plusieurs problèmes avec " les réseaux passifs " ont été
identifiés: Une difficulté d'intégrer de nouvelles technologies dans l'infrastructure du réseau, la
performance faible dû aux opérations redondantes à plusieurs couches protocolaires et la
difficulté d’intégrer des nouveaux services dans l’architecture existante. Un autre inconvénient
est que, récemment, les applications qui quelquefois exigent des calculs dans le réseau ont
émergés, tel que les firewalls, les proxies Web, les routeurs multicast, et les proxies mobile. Ces
besoins ont fait apparaître un nouveau type de réseau avec une capacité générique autorisant les
utilisateurs à programmer leurs réseaux. Ce nouveau réseau inventé est un réseau actif.
I.2. Les Réseaux Actifs :
Tout d’abord, pour bien clarifier la notion de réseau actif, il va falloir répondre à la question
suivante : Qu'est ce qu'un Réseau actif ?
Source
Routeur
Routeur
standard
Routeur
Client
actif
Destination
Serveu
r actif
Utilisate
Utilisate
Réseau
Réseau
IP
Equipement
IP_actif
IP
Equipement
Equipement
IP_actif
Equipement
IP
Equipement
Figure 14 : Un réseau IP actif
Un réseau actif est un réseau qui permet à des routeurs intermédiaires d'exécuter des
traitements jusqu’à présent destinés à la couche application. Les utilisateurs vont pouvoir
programmer le réseau en injectant leurs propres programmes. Ces programmes voyagent à
l'intérieur des paquets qui traversent le réseau, et sont exécutés dans les nœuds intermédiaires.
37
Ceci a pour résultat la modification de l’état du nœud et de son comportement. De ce fait, les
nœuds peuvent appliquer un traitement personnalisé à chaque paquet les traversant. Par exemple,
un utilisateur d'un réseau actif peut envoyer un programme « trace » à chaque routeur et s'arrange
pour que se programme s'exécute quand ses paquets sont traités. La figure (14) illustre comment
un routeur d'un réseau IP peut être augmenté pour exécuter tel ou tel traitement personnalisé sur
les paquets le traversant. Les routeurs actifs peuvent aussi inter opérer avec les routeurs
standards, qui expédient les paquets d'une façon traditionnelle.
I.3. Les différentes architectures des réseaux actifs
Nous allons voir maintenant quelques architectures pour les réseaux actifs. Les
architectures sont groupées selon leur approche de conception: dans quelques architectures les
paquets actifs transportent le code exécutable, généralement le code s’exécute sur les données du
paquet qui le transporte. D'autres architectures placent le code exécutable dans les nœuds actifs
ou programmables et laissent les paquets transporter que des identificateurs pour indiquer quel
traitement devra être exécuté sur ces paquets.
I.3.a. L’approche par paquet actif :
Appelée aussi approche intégrée (integrated approch) [B.1], cette approche (figure 15) est
fondamentalement caractérisée par le fait que le code est transporté par le paquet traversant le
réseau (au moins une instruction). Quand un paquet arrive dans un nœud actif, son contenu est
évalué, de la même façon qu’une imprimante PostScript interprète le contenu de chaque fichier
qu’elle reçoit.
Après avoir délimité le code dans le paquet, celui-ci est ensuite dispatché sur un
environnement d’exécution, ou il peut être évalué d’une manière sûre et efficace. Nous
supposons que le programme est composé d’instructions appliquant des traitements simples sur
le contenu du paquet, et il peut invoquer des primitives disponibles sur le nœud pour accéder aux
ressources du nœud (exp. mémoires). Le résultat de l’exécution peut être une génération d’une ou
plusieurs capsules en sortie ainsi qu’une possibilité de changement d’état du nœud.
Figure 15 : Approche par paquet actif
Deux exemples de ce type d’architecture sont le projet Smart Packets développé a la BBN
technology et le projet « Active IP Option ».
38
I.3.a.1. Le projet « Smart paquets »
Smart Packets [B.1] est un projet de réseaux actifs se concentrant sur l’application de la
technologie active pour la gestion et la surveillance des réseaux, sans pour autant surcharger les
nœuds.
Nœud
P
Programme
de Gestion
du Réseau
Routeur
Routeur
D
D
D
ANEP
Démon
/Machine
Virtuelle
Réseau
Figure 16 : Architecture du système Smart Packets.
La figure 16 montre l’architecture du système Smart Packets. Les programmes de gestion
du réseau écrits par les utilisateurs produisent des paquets actif (encapsulé dans des trames
ANEP, Active Network Encapsulation Protocol). Ces paquets sont donnés au processus démon
d’ANEP, qui les injecte dans le réseau. Les paquets peuvent être transmis soit en mode bout–en
bout, donc le programme est exécuté par le destinataire, ou en mode saut par saut, dans ce cas, le
programme est exécuté à la source, à la destination, et dans tous les nœuds intermédiaires. Le
processus démon d’ANEP a principalement deux tâches, la première concerne la réception des
paquets, et la seconde l’exécution de la machine virtuelle pour évaluer les paquets.
I.3.a.2. L’Option IP active :
Active IP Option décrit une extension du mécanisme des options IP qui supportent
l’intégration des fragments d’un programme dans des datagrammes. Ces fragments seront
évalués lorsqu’ils traversent le réseau [B.1].
Deux options sont définies: La première est utilisée pour porter des fragments du
programme qui peuvent être codés dans une variété de langages. La seconde est utilisée pour
questionner un routeur actif sur le type de langage qu’il supporte. Ces options actives peuvent
exécuter l’acheminement et la copie, et la fusion des fonctions. Un fragment du programme avec
le format de la capsule est montré dans la figure (17).
39
IP options (IPv4IPv6)
IP Header
User Data
ACTIVE Option
Active : 63
Type
(var)
Code : Tc1
If ! [node]=[destination] ! !………………..!
length
value
Figure 17 : Format du champ Option IP Active
I.3.b. L’approche par nœud actif (Programmables)
Dans cette approche, appelée aussi approche discrète (discret approach). Les paquets ne
transportent pas le code, mais transportent au lieu de cela quelques identifiants ou références à
des fonctions prédéfinies résidents dans les nœuds actifs (figure 18). La cause de l’apparition
d’une telle architecture est due aux problèmes de l’approche par paquets actifs, principalement la
sécurité. La seule façon de minimiser ces problèmes est de restreindre les programmes qui sont
transportés par les paquets.
Figure 18 : L’approche par nœud actif.
Un exemple de ce type d’architecture est le projet ANTS [B.1] [B.2] développe au MIT.
I.3.b.1. L’architecture ANTS (Active Node Transport System).
Développée au MIT (Massachusetts Institute of Technology), cette architecture introduit la
notion de capsule : un paquet contenant du byte code java avec des données utilisateur (payload).
Les APIs d’ANTS consistent en la MVJ (Machine Virtuelle Java) augmentée avec des classes
ANTS, qui implémentent des méthodes permettant aux capsules d’être décodées et interprétées.
Dans ANTS, les capsules peuvent installer un état et invoquer des classes installées par d’autres
capsules. La granularité du contrôle peut être soit par flot ou par capsule.
I.3.c. L’approche par paquets et nœuds actifs:
Dans cette approche, les paquets actifs transportent le code réel. Par contre, les autres codes
les plus complexes résident dans les nœuds actifs. Par conséquent, les avantages de ces deux
approches antérieures existent dans un seul système [B.1]. Ces architectures permettent aux
utilisateurs de choisir l’une ou l’autre approche d'après la nature de leur application. Un exemple
typique est l'architecture SwitchWare proposée à l'Université de Pennsylvanie.
40
I.3.c.1. L'Architecture SwitchWare :
SwitchWare utilise une architecture en couches « layered architecture » pour fournir un
compromis entre la flexibilité, la sécurité, les performances, et l’usage [B.1]. Les trois couches
définies dans SwitchWare sont : Les Paquets Actifs, les Switchlets, et l’Infrastructure du Routeur
Actif. La première couche réalise l’approche par paquets actifs et la deuxième couche réalise
l'approche par nœuds actifs.
Dans SwitchWare, les paquets actifs portent des programmes constituant à la fois de code
et des données, et remplacent l'en-tête et la charge utile d'un paquet conventionnel. Le langage de
programmation utilisée est le « Programming language for actif networks, PLAN ». c’est un
langage léger et qui permet un accès limité aux ressources sans certification. Cependant, elle
exécute des actions autorisées quand c’est exigé.
Les Switchlets forment la couche centrale de l'Architecture SwitchWare. Les paquets actifs
combinés avec les switchlets peuvent implémenter des protocoles. Les Switchlets peuvent
dynamiquement être chargés à travers le réseau, mais elles s’exécutent entièrement dans un
routeur particulier. Donc ce sont des fonctions de base ou des extensions dynamiques plutôt que
du code mobile. Dans l’implémentation courante, les switchlets sont soumises à une sécurité plus
lourde que les paquets actifs. L'infrastructure du routeur active est une base robuste sur laquelle
les paquets actifs et les Switchlets sont construits. La sécurité de l'architecture SwitchWare est
garantie au niveau de cette couche.
I.4.
Quelques applications des réseaux actifs :
Comme mentionné plus haut, la plus importantes application des réseaux actifs provient
directement de sa possibilité de programmer le réseau : de nouveaux protocoles ainsi que des
techniques rentables et innovatrices peuvent être facilement déployées dans les nœuds
intermédiaires. Nous allons voir dans ce qui suit comment ceci est possible pour : le Multicast, le
Caching, le Contrôle de congestion, et finalement la gestion des réseaux.
I.4.a. Le caching:
Une grande quantité du trafic des réseaux actuellement provient des applications dans
lesquelles les clients récupèrent des objets à partir du réseau. L’utilisation de cache dans des
endroits proches des clients, donc des points stratégiques, peut réduire considérablement le trafic
du réseau ainsi que le temps mis pour rechercher des objets ou des pages HTML dans le cas du
World Wide Web.
Les réseaux actifs peuvent être utilisés pour fournir un modèle de configuration de cache,
où l’on aura besoin d’une petite capacité de mémoire, et où d’importantes réductions dans le taux
du trafic et dans la latence peuvent être obtenues.
Les récents travaux au Georgia Technologie Institute ont considéré le bénéfice de
l’association du cache avec les nœuds à travers le réseau. Le modèle proposé est appelé selforganizing wide-area networking cache [B.1]. L’idée de base est de donner la possibilité de
décider ou placer les caches en considérant que tous les nœuds du réseau peuvent enregistrer des
objets et compté sur la technologie des réseaux actifs pour maintenir une distribution uniforme
des caches dans le réseau.
41
I.4.b. Le contrôle de congestion :
Certaines conditions de réseaux, entre autre le contrôle de congestion, peuvent dégrader
d’une manière significative la qualité du flux de l’application. L’utilisation des modèles standard
requérant que l’émetteur s’adapte aux nouvelles conditions du réseau a connu des limitations
incluant : le temps pour que l’émetteur détecte le nouvel état du réseau (notification de
congestion), réagir, et finalement transmettre les données adaptées aux nouvelles conditions du
réseau. Tandis qu’au même moment, le récepteur peut subir d’importantes pertes de données. En
transportant des informations sur comment s’adapter aux conditions pouvant se produire dans les
nœuds du réseau, les modifications appropriées se feront ou et quand ceci est nécessaire.
On peut trouver plusieurs exemples où l’ajout des fonctionnalités des réseaux actifs peut
aider à traiter cette congestion, entres autres :
-
un nœud actif peut gérer la largeur de bande disponible en contrôlant le taux des flux de
données (utilisation du buffering),
-
de plus, si plusieurs flots de données coexistent dans un même nœud et chacun d’entre eux
ayant des exigences propres pour le contrôle de congestion, alors le nœud actif peut gérer
aussi bien les taux d’arrivée de chaque flot en plus du taux globale dans le nœud.
-
la transformation des données (compression et autre) peut être accomplie par les nœuds actifs
subissant une congestion, ainsi donc, le trafic est réduit sans pour autant perdre des données.
-
La destruction des paquets non importants est une technique classique pour la réduction des
taux de charge sur un nœud. Mais, le plus grand problème est comment différentier les
paquets importants des non importants car ceci dépend souvent des applications. Le nœud
actif peut très bien scruter le contenu des paquets et détecter les paquets importants des
autres, bien sur en prenant en compte les types d’applications.
I.4.c. Le multicast :
Les nouvelles générations de réseaux auront à gérer une variété d’applications telles que
l’audio, la vidéo, ou encore la visioconférence. Bon nombre d’entre elles ont besoin du multicast.
L’utilisation d’une architecture de réseau actif peut s’avérer très utile. Les nœuds actifs peuvent
résoudre d’une manière efficace plusieurs problèmes tels que l’implosion des paquets NACKs
(acquittement négatifs), la retransmission inutile, la duplication des paquets et bien d’autres
problèmes. Tandis que l’utilisation d’une architecture de réseau passif fournit seulement des
solutions partielles aux problèmes précédents.
I.4.d. La gestion des réseaux :
L’approche conventionnelle pour la gestion d’un réseau est de scruter les dispositifs
(matériels/logiciels) constituant le réseau et ceci depuis une station de gestion centrale. Cette
station demande les valeurs de certaines variables pour détecter les anomalies. Cette approche
concentre l’intelligence dans la station de gestion. De plus, elle limite considérablement la
42
possibilité de traquer les problèmes en temps réel et d’une manière efficace (généralement due au
temps de rapatriement des valeurs).
Les réseaux actifs sont par conséquence la réponse la plus logique à ces problèmes. Car, en
rendant les nœuds du réseau actifs, on peut transporter le centre de gestion dans le cœur du
réseau et réduire à la fois le délai de réponse et la largeur de bande nécessaire pour la gestion
dans le modèle standard.
I.5.
La Sécurité et la Sûreté dans les réseaux actifs:
La sécurité et la sûreté sont deux propriétés de fiabilité d'un système. Un système sûr
fournit la protection contre les erreurs des utilisateurs autorisés à exécuter du code sur un nœud,
alors qu’un système sécurisé se protège des erreurs qui peuvent être introduites par des
utilisateurs non- autorisés[B.1].
Ces deux aspects sont peut-être les problèmes principaux, actuellement, dans les réseaux
actifs. En effet, les opérateurs sont très soucieux de la capacité à gérer plusieurs utilisateurs sur
un même équipement, surtout quand ces utilisateurs peuvent déployer des programmes et
interagir fortement avec le réseau. Cela nécessite d'avoir des systèmes extrêmement robustes et
fiables.
Effectivement, Dans un réseau actif, les paquets actifs peuvent abuser : des nœuds actifs
(reconfiguration, effacement de la mémoire), des ressources du réseau (consommation constantes
de connexions réseau, ou une grande partie des cycles CPU disponibles), ainsi que sur d'autres
paquets actifs. De plus, les nœuds actifs peuvent à leur tour abuser des paquets actifs. De ce fait
nous remarquons qu’un bon niveau de sécurité et de sûreté est indispensable pour le bon
fonctionnement de tout le système. Traditionnellement, la sécurité est souvent réalisée avec des
mécanismes d'authentification, de cryptographie mais qui pénalisent considérablement les
performances du réseau.
Le principe de base de la sûreté et la sécurité est l'accès contrôlé aux ressources. Le
contrôle de la ressource est dirigé par une politique qui définit quelles opérations peuvent être
exécutées sur ces ressources. L'exemple concret le plus répandu est l'utilisation des listes de
contrôles d'accès (ACL) du type <objet , sujet , action> ou plus spécifiquement <ressource>,
utilisateur , permissions>. Une liste de contrôles d'accès peut donc être vue comme un ensemble
de restrictions qui gouvernent l'accès à un objet .
On peut difficilement envisager une politique de sécurité sans utiliser des restrictions. Il y a
deux types de vérification envisageables : la vérification dynamique et la vérification statique.
La vérification dynamique est très importante car on ne peut pas être sur de l’absence de
mauvaises instructions dans le code avant l'exécution. Cela est du aux différences entre les
langages de programmation qui empêchent d'effectuer des tests communs. Si l'on utilise un
ensemble restreint de langages adaptés, on peut envisager d'effectuer plus de tests statiques.
Ceux-ci sont intéressants car ils ne sont pas réalisés qu'une seule fois, quelque soit le nombre
d'exécutions, tant que le programme n'est pas modifié. Un exemple de cette approche est utilisée
par les concepteurs de PLAN .
Une autre approche est de restreindre l'accès aux fonctionnalités d'un langage de
programmation général (non dédié aux traitements spécifiques des réseaux partagés). Le
43
principal inconvénient est qu'il faut analyser soigneusement les implications en terme de sûreté et
de sécurité d'accès aux fonctionnalités ou aux services.
Les systèmes hybrides forment une approche plus réaliste. L'analyse statique est capable
d'assurer que les programmes sont conformes et la vérification à l'exécution est utilisée pour
effectuer des tests qui ne peuvent pas être réalisés pendant l'analyse statique. Un bon exemple est
l'utilisation de programmes Java; c'est le langage le plus répandu actuellement dans les
réalisations de réseaux actifs.
I.6. Active Network Encapsulation Protocol (ANEP):
Le développement de nombreux projets de Réseaux Actifs a conduit à la création de
formats de paquets actifs spécifiques à chaque équipe de recherche. Afin d'uniformiser cette
hétérogénéité, le DARPA a créé le protocole d'encapsulation ANEP [B.6]. La portabilité et
l'interopérabilité entre les projets sont donc facilitées. Les paquets ANEP peuvent encapsuler les
données de n'importe quel protocole dans un format commun (figure 19) permettant ainsi le
transport des paquets actifs. Les champs publics et les valeurs publiques des paquets ANEP sont
déterminés par l'ANANA (Active Networks Assigned Numbers Authority). ANEP est
indépendant de la technologie de réseau sous-jacente (encapsulation dans UDP, IP, Ethernet...)
même si l'encapsulation dans UDP est actuellement la plus utilisée. On peut donc choisir parmi
plusieurs schémas d'adressage (IPV4, IPv6). Le protocole ANEP permet aussi l'utilisation d'un
CRC et d'une authentification non négociée.
0
7 8
15 16
Version
31
Flags
TypeID
ANEP Header Length
ANEP Packet Length
Options
Payload
Figure 19 : Format de l’en tête ANEP
0
1 2
FLG
15 16
Option Type
31
Option Length
Option Payload (Option Value)
Figure 20 : Format du champ Options
•
•
Les 8 bits du champ version indiquent le format de l’en-tête utilisé (la version aujourd’hui
est ). Seulement, le bit le plus significatif parmi les 8 bits est utilisé dans la version « 1 »
et indique si le nœud doit acheminer le paquet ou l’abandonner dans le cas ou il ne
connaît pas le contenu du champ type ID. Ce champ « type ID » indique l’environnement
d’exécution du message. La valeur «0 » est réservée pour les messages d’erreurs.
Le champ « Header length » indique la longueur de l’en-tête du paquet et le champ «
packet length » indique sa longueur totale (Chacun est composé de 32 bits).
44
•
•
Le champ « Option » est décomposé en 2 bits pour le drapeau et 14 bits du champ
« option type » (figure 20) où ses valeurs sont aussi contrôlées par ANANA. Un drapeau
égal à zéro indique que l’option est non standard.
Le champ « Payload » contient le charge utile du paquet
La robustesse de ce protocole apparaît lors de l’implémentation d’un nouvel environnement
d’exécution où seulement un nouveau « type ID » et « Option type » sont attribués.
Le protocole ANEP offre aux utilisateurs la possibilité de contrôler le routage des paquets
dans un environnement d’exécution particulier. Les paquets arrivant à un nœud et contenant un
en-tête ANEP valide avec un type ID approprié vont être routés au channel connectés à l’EE
convenable présent dans ce nœud. Ces canaux sont crées lors du démarrage du nœud.
L’EEs peuvent exécuter des paquets constituant un flux passif crées par des systèmes non
actif, simplement par création des canaux appropriés. Ces paquets ne contiennent pas des en-têtes
ANEP. Par exemple, un EE qui offre le fonctionnement d’acheminement IPV4, peut être intégré.
I.7.
Conclusion
Comme nous l'avons vu dans ce chapitre, la thématique des réseaux actifs est un domaine
de recherche nouveau où rien n'est encore figé. Les approches et les projets sont nombreux pour
trouver un juste équilibre entre flexibilité et sécurité. Peu de choses ont été standardisées, ce qui
laisse un vaste champ d'exploration.
II.La plate- forme ANTS.
II.1. Introduction :
L’architecture ANTS14 permet de construire et de déployer de nouveau protocoles et
services [B.2]. Ils sont automatiquement déployés dans les nœuds intermédiaires et les systèmes
terminaux en utilisant les techniques de code mobile. C’est un système de programmation
distribué qui fournir un modèle (langage de programmation) afin d’exprimer de nouveaux
protocoles dans le terme des opérations aux nœuds.
Le service réseau offert par ANTS n’est pas fixe ; il est flexible15. Différentes applications
sont capables d’introduire des nouveaux protocoles dans le réseau en spécifiant les routines
exécutées aux nœuds qui acheminent leurs données. Les applications peuvent personnaliser le
traitement du réseau suivant leurs propres besoins. Ce nouvel traitement a de sens seulement dans
le contexte de réseaux actifs.
Trois concepts clés ont guidé la conception d’ANTS [B.2] :

14
15
Les nœuds du réseau doivent supporter une variété de protocoles réseaux utilisés
simultanément.
Les nouveaux protocoles doivent être supportés par un accord mutuel des parties intéressées
et non pas de toutes les parties du réseau.
Finalement, les nouveaux protocoles doivent être déployés d’une façon dynamique et sans
avoir besoin de mettre une portion du réseau « Hors service ».
Un réseau basé ANTS se compose d’un groupe de nœuds interconnectés qui exécutent ANTS.
Le X-Kernel ANTS fournit la plus haute flexibilité accordée à un langage de programmation et convient pour le déploiement dynamique.
45
Les trois concepts précédents ont introduit les notions suivantes [B.2]:

les paquets que l’on trouve dans les réseaux conventionnels sont ici remplacés par des
capsules qui référencent le traitement à effectué sur leurs contenus.

tous les nœuds (intermédiaires ou finaux) sont remplacés par des nœuds actifs, permettant
l’exécution du code correspondant aux capsules et permet aussi de maintenir des variables
d’états dans les nœuds.

un mécanisme de distribution du code pour assurer que les routines des capsules sont
automatiquement et dynamiquement déployées dans les nœuds du réseau, et plus
spécifiquement vers les nœuds qui on ont besoin.
Ce prototype est écrit entièrement en JAVA et s’appuie sur le protocole UDP pour échanger
les messages. On peut parler de couche réseau virtuelle. Chaque nœud sera en fait un Thread
Java qui s’exécutera sur une machine, ou encore un ensemble de Threads Java s’exécutant sur
une même machine.
II.2. Les composantes de l’architecture : ( protocoles, code groupe et les capsules) :
Dans ANTS, on a besoin de combiner les routines d’acheminement aux différents nœuds
dans un protocole [B.2]. Ce protocole définit donc le traitement qui se produire dans le réseau.
Dans ANTS l’utilisation d’un nouveau protocole est faite en utilisant les capsules, les groupes de
code, et les protocoles. La relation entre ces entités est illustrée dans la figure (21).
•
Code
Code
réf
Code
Code
Code
Données
Protocole
Unité de protection
•
Groupe de code
Unité de transfère
•
Code de traitement
Unité de traitement
•
Code implantant
service réseau
un
Seul les capsules d’un
même
protocole
peuvent communiquer
entre eux
Les
capsules
manipulent que
ne
les
Organisation du code
du protocole en unités
de transfère
Capsule
Unité de transmission
Figure 21 : Hiérarchie de la composition de la capsule
Une capsule remplace un paquet, sa fonction la plus importante est d’inclure une référence
à la routine d’acheminement pour être utilisée pour traiter la capsule à chaque nœud actif.
Quelques routines d’acheminement sont disponibles à chaque nœud actif. Par contre d’autres
routines sont spécifiques pour certaines applications. Ces routines ne résident pas à chaque nœud,
mais doivent être transférées à un nœud à travers le système de distribution du code avant que les
capsules de ce type puissent être traitées.
46
Le groupe de code est une collection de capsules de types liés dont les routines
d’acheminements sont transférées comme une seule unité par le système de distribution de code.
Le protocole est une collection des groupes de code liés. Par conséquent, le protocole est l’unité
par laquelle le réseau est personnalisé. Les capsules dans un seul protocole vont typiquement
manipuler l’information partagée dans le réseau.
II.3. Format de la capsule :
Le format de la capsule [B.2] est présenté dans la figure (22). Chaque capsule porte un
identificateur pour son protocole ainsi que le type de la capsule dans ce protocole. Cet
identificateur est utilisé pour le démultiplexage des routines d’acheminement.
Protocol / Capsule
Shared header
rest of header …. payload
Figure 22 : Format de la capsule
Le reste du format de la capsule est composé d’un en-tête partagé qui contient les champs
communs à toutes les capsules, un type dépendant de l’en-tête qui peut être mis à jour quand la
capsule traverse le réseau, et une charge utile. Les composantes importantes de l’en tête
commune sont les adresses sources et destinations et des informations sur les restrictions en
termes de ressources à appliquer dans les nœuds. Le reste des champs de la capsule varie selon
son type.
II.4. Le modèle d’exécution dans les nœuds actifs :
Le modèle d’exécution est basé sur l’hypothèse que le premier but du traitement fait dans le
réseau actif est pour faciliter la communication. Ce modèle est optimisé pour supporter une
forme générale d’acheminement du paquet plutôt qu’un traitement général [B.2]. Il a les
caractéristiques suivantes :
•
La routine d’acheminement d'une capsule est initialisé au niveau de la source et ne peut
pas être changé quand elle traverse le réseau. Aussi les capsules qui appartiennent à un
protocole ne peuvent pas créer ou manipuler des capsules d’un autre protocole. Par
conséquent, un utilisateur ne peut pas contrôler le traitement des capsules d'un autre
utilisateur d’une manière involontaires.
•
Ce n’est pas tous les nœuds du réseau qui ont besoin d’exécuter la routine
d’acheminement d’une capsule. Selon les ressources disponibles et la politique de
sécurité, quelques nœuds peuvent choisir de ne pas exécuter des capsules. Dans ce cas là,
ils accomplissent l’acheminement par défaut, comme dans IP. En outre, les routines
peuvent choisir les nœuds où c'est utile d’exécuter leur traitement selon l'emplacement du
nœud et ses capacités.
•
Dès que ces routines peuvent être définies par des utilisateurs non fiables, ils sont limités
dans leurs privilèges pour éviter des problèmes de fiabilité. De ce fait, l’exécution du
code de l’utilisateur est limitée en terme de consommation mémoire, CPU, et bande
passante.
47
•
Par défaut, seulement les capsules qui appartiennent au même protocole peuvent partager
des états. Une fois un protocole est crée, il sera fermé dans le sens que les nouveaux types
de capsule prétendant appartenir à lui pour manipuler ses données seront interdites.
Etant donnée les primitives précédentes, le nœud doit offrir un modèle d’exécution qui les
supporte.
II.5. Le protocole de chargement du code :
Le chargement in-band du code requière que chaque paquet transporte à la fois son code et
les valeurs d’états correspondantes afin qu’il soit traité par tous les nœuds qu’il traverse. Donc
même si plusieurs paquets consécutifs doivent être traités par le même code, chaque paquet doit
transporter son propre code [B.2].
ANTS élimine cette redondance du transport de code en utilisant un protocole de
chargement sur demande (demand loading protocol). Au lieu de transporter le code dans chaque
paquet, ANTS compte sur les nœuds se situant à l’intérieur de son architecture, d’émettre une
requête de demande de code lorsque celui-ci n’est pas disponible dans son cache. Dans
l’architecture actuelle d’ANTS, le nœud transmet une requête de demande de code seulement à
son voisins en amont, à la réception du code de ce voisin, le nœud enregistre le code dans sa
mémoire cache pour une durée de temps finie. Il utilise ensuite ce code pour traiter tous les
paquets successif ayant le même identifiant de code. La figure (23) montre le processus complet
du protocole de chargement de code d’ANTS. Depuis que ce protocole se charge du transfert du
code, les applications ont seulement besoin de fixer les valeurs d’états correspondantes au code
dans le paquet transmis dans le réseau.
1
capsule
2
demande
réponse
Groupe de code
3
4
capsule
Groupe de code
Nœud
précédent
Nœud
actuel
Figure 23 : Protocole de chargement sur demande de ANTS.
Le protocole de chargement de code d’ANTS a de nombreuses propriétés bénéfiques. En
premier, le code est transmis uniquement aux nœuds qui en font la demande. De plus, les
applications n’ont besoin ni de prédéterminer la route des paquets pour transmettre le code à tous
48
les nœuds du chemin de données, ni encore de faire une diffusion (broadcast) du code à tous les
nœuds du réseau.
En outre, puisque la plupart des protocoles réseaux utilisent fréquemment des flots de
paquets, le nombre de paquets supplémentaires apportés par le protocole de chargement du code
est amorti par le grand nombre de paquets transmis. Bien sur, pour les protocoles utilisant un
faible nombre de paquet l’utilisation de ce protocole peut être un handicape pour la transmission.
II.6. Prototype d’implémentation :
L’implémentation, qui a été faite par ANTS, a été conçue essentiellement pour nous
permettre d’évaluer la capacité de l’approche ANTS pour créer et déployer de nouveau
protocoles.
L’implémentation actuelle est écrite en Java et est exécuté comme un processus de niveau
utilisateur sous Linux [B.2]. Le protocole de distribution du code transforme les routines de
traitement des capsules en un fichier Java au format « .class ». Java a été choisie à cause de son
support pour la sécurité et la mobilité. Sa flexibilité comme un langage de haut niveau et son
support de chargement dynamique, multithreading, et les librairies standard ont permis d’évoluer
ce design en maintenant un petit code de base.
Les composantes principales de l’architecture ANTS (figure 24) sont implémentées en
utilisant les classes suivantes :
Tableau 2 : Les classes et les méthodes d’ANTS.
Classes
Méthodes
Node
Channel
Application
Capsule
address, get, put, routefornode, delivertoapp
send, receive, node
send, receive, (upcall) node
evaluate, length, serialize
Quand un nœud ANTS est lancé, il instancie un objet nœud “Node Object”, un objet
channel « Channel Object » pour chaque interface réseau et un objet application « Application
Object » pour chaque application locale. Les applications peuvent ensuite communiquer en
échangeant des capsules entre elles. Les capsules sont envoyées via le nœud local qui les
transmet comme des paquets en utilisant les services de la couche liaison classique. Quand des
paquets sont reçus de la couche liaison, le channel tente de les convertir en objets « instances »
de la sous classe Capsule appropriée. Dès que l’objet capsule est crée, le channel appelle sa
méthode « evaluate » en passant l’objet Noeud comme paramètre. Lors de son évaluation, le code
de la capsule a accès à la fois au soft state du protocole associé et aux d’autres variables (i.e
tables de routage).
49
End System
End System
EE
E
App
App
Protocol
Active
Node
Extension
Channel
Active
Node
Protocol
Extension
Channel
Capsule
Node
Active
Node
Channel
Capsule
Node
Node
Figure 24 : Les principales composantes d’ANTS.
II.6.a. La Classe nœud :
La classe Node représente l’environnement d’exécution d’un seul nœud du réseau incluant
son cache et son protocole de distribution de code. Elle offre un ensemble de primitives et de
services pouvant être invoquées par :
•
•
•
Les capsules, pour exécuter leurs routines d’acheminement et transférer leurs codes.
Les applications, pour enregistrer les protocoles et envoyer et recevoir des capsules du
réseau.
Les extensions, pour attacher des nouveaux services au nœud.
Ces primitives donnent l’accès aux variables d’état du nœud. Les routines les plus
importantes sont :
-
adresse() : retourne l’adresse du nœud local.
fouteForNode : transmet une capsule vers le nœud spécifié, utilisant la table de routage par
défaut (le chemin le plus court).
sendToNeighbord() : transmet la capsule vers tous les voisins directs.
deliverToApp() : delivre la capsule à l’application attachée au nœud local.
time() : retourne la valeur du temps courant.
softstate.get() : recherche un objet dans le cache du nœud local.
softstate.put() : introduit un objet dans le cache du nœud local.
softstate.remove() : supprime un objet du cache du nœud local.
II.6.b. La Classe Channel :
La classe Channel offre l’interface à la couche liaison, reliant les nœuds via des canaux
point à point ou médium partagé [B.2]. Actuellement, ceci est fait sur UDP. Ce choix permet à de
petits réseaux d’être construits en exécutant un nœud par machine. Des réseaux plus grands
50
peuvent être émulés en exécutant plusieurs nœuds par machine et reliés les nœuds par des canaux
UDP.
II.6.c. La Classe Capsule :
Une capsule est la généralisation d'un paquet. Sa fonction la plus importante vis-à-vis de
l'architecture est de contenir une référence vers une routine de forwarding qui sera utilisée pour
traiter la capsule dans chaque nœud actif.
La création d’une nouvelle capsule se fait toujours en prenant une sous classer de la classe
Capsule du package ANTS. La méthode principale d’une capsule contenant les fonctionnalités
d’un protocole est la méthode evaluate(Node n), elle est exécutée à chaque nœud traversé par la
capsule.
Toute nouvelle capsule hérite des méthodes suivantes pour accéder aux zones d’en-tête qui
font partie de la classe de base Capsule :
-
GetSrc() : retourne l’adresse source de la capsule comme un entier sur 32 bits.
GetDSt() : retourne l’adresse destination de la capsule comme un entier sur 32 bits.
SetDst () : fixe l’adresse destination de la capsule.
GetType() : retourne le type de la capsule. Ce type est identifié par une chaîne de caractère.
En plus de la procédure evaluate() à redéfinir pour chaque capsule, il faut aussi réécrire les
méthodes suivantes :
-
Code() : initialise une représentation linéaire de l’objet Capsule pour une transmission sur le
réseau (sérialisation).
Decode () : initialise une occurrence de l’objet Capsule à partir d’une représentation linéaire
reçue du réseau (désentialisation).
Les deux fonctions ci-dessus sont des fonctions sensibles à la sécurité.
II.6.d. La Classe Application :
Les programmes qui utilisent les services ANTS sont construit en enrichissant la classe
Application. Elle se situe généralement dans les bouts du système et fournit des routines
pour injecter des capsules dans le réseau et recevoir des capsules du réseau. La routine la plus
importante de cette classe est la méthode receive(Capsule cap) pour pouvoir traiter les
capsules et en exploiter le contenu.
II.6.e. Les extensions du nœud actif:
Les extensions d’un nœud augmentent les services intégrés au nœud avec des composantes
plus spécifique pour des traitements particulier. La première extension intégrée est le
GroupsManager [B.3], supportant les primitives du multicast. D’autres candidats sont le RSVP,
les routines de transcodage, et ainsi de suite.
Le nœud actif doit fournir un moyen aux extensions de s’attacher pour qu’elles puissent
offrir leurs services aux routines d’acheminement des capsules. Une fois l’extension est attachée
et localisée, les capsules peuvent invoquer ses services directement :
51
•
•
findExtension() celle ci est appelée, typiquement via un initiateur statique sur la
classe capsule, pour organiser un nom d’une extension à son index local.
getExtension() elle est appelée au nœud pour renvoyer une référence à une
extension particulière. Si l’extension n’est pas présente, une valeur égale a NULL est
renvoyée.
Une nouvelle extension est développée en sous classant la classe Virtuelle Extension.
Elle doit être installée dans le nœud comme faisant partie de la configuration locale. L’interface
offerte par le nœud pour assister les extensions est comme suit :
•
•
attachExtension() Elle informe le nœud sur l’extension et permet aux capsules de
la trouver.
exportClass() Elle permet aux extensions d’exporter des classes eux-mêmes. Sans
cet appel, le nœud va refuser l’accès du code de la capsule aux classes.
II.6.f. La configuration
Pour un but pratique, les expérimentations avec les réseaux actifs nécessitent que la
topologie du réseau soit crée. Pour cela ANTS fournit trois fichiers nécessaires pour la
configuration et l’exécution :
-
nomfichier.start : permet de lancer les nœuds et l'application.
nomfichier.routes : contient les tables de routage initiales.
nomfichier.config : définit la topologie du réseau et les applications à lancer sur chaque
nœud.
Le fichier nomfichier.routes est créé automatiquement grâce au programme en TCL
makeroutes qui calcule les routes à partir du fichier nomfichier.config. Ce dernier est le fichier
qui configure le réseau, c'est-à-dire qu'il contient les nœuds, leurs adresses dans ANTS et la
correspondance avec les adresses physiques, les applications ainsi que les extensions qui doivent
être lancées sur chaque nœud. nomfichier.start est simplement un script de lancement des
différents nœuds [B.3].
II.7. Avantage et limites de ANTS
Le mécanisme le plus intéressant dans ANTS est sûrement son système de chargement de
code à la demande. Ainsi, le code est déployé seulement où l'application en a vraiment besoin.
Par contre, ANTS ne gère pas encore les aspects multi-utilisateurs. Au niveau de la gestion des
protocoles, ANTS fait l'hypothèse qu'une capsule ne contient pas du code qui monopolise les
ressources du nœud. Les traitements doivent être courts. Il faudrait cependant avoir un
mécanisme de vérification et de contrôle sur l'exécution des capsules.
III. Conclusion.
Les réseaux actifs représentent une nouvelle approche pour l’architecture du réseau. Les
routeurs peuvent exécuter des traitements sur les données de l'utilisateur et les paquets peuvent
transporter des programmes qui seront exécutés dans les nœuds et pourront ensuite changer leur
état. Actuellement, la communauté de la recherche est divisée sur l’utilité des réseaux actifs. D'un
côté, les réseaux actifs fournissent une infrastructure réseau plus flexible avec des fonctionnalités
52
intéressantes. De l'autre côté, ils sont évidemment plus complexes que les réseaux traditionnels et
leurs exigences en terme de sécurité sont considérables.
Nous avons vu dans ce chapitre un prototype de réseaux actif ANTS permettant un
déploiement dynamique et automatique de protocoles réseaux dans des nœuds bien spécifiques
du réseau. Donc le réseau est vu comme un système de programmation distribué englobant un
protocole de distribution de code et une technique de cache.
Finalement, à la question : « les réseaux actifs vont-ils remplacer les réseaux actuels ? », on
choisira de rester prudent. En effet, les différents prototypes de réseaux actifs et notamment
ANTS se révèlent encore lourds et d'un niveau de sécurité insuffisant. Les performances sont
encore faibles et les ressources nécessaires trop importantes pour une utilisation à grande échelle,
stable, et performante.
Dans le chapitre suivant, nous proposons une architecture de contrôle actif par politique
dans un réseau DiffServ.
53
Chapitre V
L’architecture ACDN (Actif Control DiffServ Network)
Et son implémentation
I. Introduction :
Dans ce chapitre, nous proposons une architecture permettant d’automatiser et de distribuer
le contrôle dans un réseau DiffServ. En effet, l’architecture de contrôle par politique actuellement
normalisée par l’IETF pour les réseaux DiffServ souffre d’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. Ces décisions peuvent mener à l’installation dynamique de
nouveaux TCBs.
Nous détaillerons également un exemple d’application active qui a fortement inspiré ce
travail Cette application a pour titre « segmented Adaptation of traffic agregates » ou bien
agrégats adaptés dans un segment du réseau. Le but de cette approche est de faire un contrôle de
congestion dépendant de la classe de service (agrégat).
Afin de valider l’architecture ACDN proposée, une implémentation est en cours. Nous
expliquons, comment la plate forme ANTS peut être étendu afin d’intégrer toutes les
composantes d’un nœud DiffServ (TCBs).
II. L’architecture ACDN
Actuellement, les contrôles sont fait de façon 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
(Figure 25). 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. Ce modèle
exploitera les notions introduites par le paradigme des réseaux actifs pour permettre une
introduction rapide et transparente de ces fonctionnalités.
Policy
Repository
station
d'administration
Plan de
contrôle
(serveurs)
Routeur
DiffServ
COPS -PR
PDP
Plan de contrôle (PEP)
plan de données
(DiffServ)
TCB
Figure 25 : Architecture de contrôle des réseaux DiffServ.
54
L’architecture ACDN16 est une architecture de contrôle tirant partie de la flexibilité des
réseaux actifs tout en respectant les spécificités de l’approche DiffServ, ainsi que les spécificités
du modèle de contrôle par politique présenté dans le chapitre III. Cette architecture permet
d’offrir un cadre général pour un contrôle complet d’un domaine DiffServ. Ce contrôle se fera en
deux phases :
1. La première phase, consiste en le déploiement sur les nœuds du réseau, par
l’administrateur du réseau ou un ISP, d’applications de contrôle distribuées sous
forme d’applications actives (AA). Cette phase est appelée contrôle par applications
actives.
2. La seconde phase, consiste en le déploiement et en l’installation de nouveaux TCBs
dans les nœuds DiffServ dépendamment de ce qui se passe dans le réseau. En effet,
lorsque le réseau est peu chargé, et donc bien dimensionné, un administrateur de
réseau peut se contenter d’installer dans les routeur de cœur une version simplifiée du
TCB (figure 2b). Cependant, si le besoin s’en fait ressentir, une application de
contrôle peut déclencher l’installation d’un nouveau TCB plus complexe (figure 3).
La complexité du TCB installé dépendra du problème rencontré dans le réseau, lequel
peut être détecté par une application active. Cette phase est appelée contrôle par
politiques actives.
La figure (26) montre les différents éléments composant l’architecture ACDN, les rôles
respectifs de ces éléments sont :
•
•
•
•
16
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 (TCA) 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 (AA et TCA) : 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
direction est réalisée grâce à la fonction de filtrage que l’on détaille plus bas.
ACDN : Active Control of DiffServ Network .
55
station d'administration
Plan de contrôle (serveurs)
Serveur de
Code
(AA)
Serveur de
code
(TCA)
Policy
Repository
Mecanisme
d'installation
Mecanisme
d'installation
PDP
COPS -PR
Application
de Contrôle
AA
Routeur
DiffServ
Environnement d'execution
ANEP
Fonction de Filtrage
TCB
Plan de donnée (DiffServ)
Figure 26 : Architecture ACDN.
II.1. Fonction de filtrage
Afin que les différents agents, constituants les applications de contrôle distribuées, puissent
communiquer entre eux, une fonction de filtrage a été introduite. Cette fonction aura pour tache
de reconnaître puis d’intercepter les capsules (paquets actifs) appartenant aux applications actives
installées dans le nœud.
Comme vu sur la Figure 27, cette fonction se situe en amont du TCB, permettant ainsi de
retirer les capsules avant que celles ci ne soient prises en compte par le TCB puis de les remettre
sur le chemin des données (Data path). Afin de rester conforme au modèle DiffServ, on notera
également que cette fonction doit marquer les paquets (champs DSCP) avant de les mettre sur le
chemin des données. Ce marquage se fera selon la QdS que l’administrateur attribuera à son
application de contrôle.
Une application active pouvant être installé sur un ensemble restreint de nœuds dans le
réseau, il est nécessaire que la fonction de filtrage puisse intercepter uniquement les capsules des
applications actives que le nœud contient. Pour se faire, la fonction de filtrage utilisera une table
de FlowID identifiant chacune des applications actives du nœud. Cet identifiant pourra être le
quintuplé (adresse source, adresse destination, N° port source, N° port destination, protocole ID)
pour IPv4 ou le champ FlowID pour IPv6.
La table des FlowID est mise à jour à chaque fois qu’une application de contrôle distribuée
est introduite ou retirée du réseau. Cette mise à jour s’effectue par une application active résidant
de façon permanente dans tous les nœuds du réseau.
56
MAJ
FlowID
Routeur DiffServ
(Architecture ACDN)
ANEP
Tableau
FlowId
Fonction de
filtrage
Plan de donnée
(DiffServ)
TCB
Figure 27 : Mise à jour de la table des FlowID et fonction de filtrage
Afin de pallier au problème de mise à l’échelle qui pourra survenir. Le nombre
d’applications actives dans un nœud sera limité.
II.2. Exemple d’application active : Agrégats adaptés dans un segment du réseau
(SATA : Segmented Adaptation of Traffic Agregates)
Dans l’architecture DiffServ, et en particulier les sous-classes AF, la congestion peut
survenir et des violations de contrat de service peuvent se produire malgré le conditionnement de
trafic et le provisionnement des ressources. Les architectures de QdS comptent sur le
provisionning des ressources basées sur les classes et donc essayent, d’un coté, de réduire la
probabilité d’avoir une congestion et de minimiser l’impact de la congestion sur le trafic
privilégié d’un autre côté. L’approche SATA est basée essentiellement sur cet aspect.
La congestion peut être vue comme une cause possible d’erreur ou d’un défaut dans la
livraison d’un service avec une QdS exigée. Pour cela, il vaut mieux prendre en considération,
dans l’architecture de QdS, le besoin d’un modèle de récupération d’erreur. Une des solutions
suggérée pour récupérer l’erreur est basée sur trois éléments : le contrôle de congestion agrégé, le
contrôle de congestion basé au domaine, et le contrôle de congestion basé sur les classes de
service [B.7]. Elle se traduit donc par l'introduction de nouvelles fonctions de contrôle et de
gestion dans les architectures existantes. Actuellement, la seule technologie qui permet le
déploiement des nouvelles fonctions est la technologie des réseaux actifs et programmable. Ces
architectures sont en effet la seule manière de rendre un réseau flexible.
Les recherches actuelles pour la mise en oeuvre de QdS DiffServ se divise en deux
catégories. Une se concentre sur le conditionnement du trafic et le contrôle d'admission aux
extrémités du réseau et l'autre sur le provisionning des ressources au cœur du réseau en
définissant les comportements par saut (PHBs). La combinaison du conditionnement de trafic
aux bords et le provisionning des nœuds de cœur par la spécification des PHBs est conçue pour
offrir des comportements de bout en bout pour un agrégat de trafic. Un tel comportement, limité
à un domaine administratif tel un segment du réseau, est connu sous le nom de comportement du
domaine « per domain behavior, PDB».
Le but ultime de DiffServ étant de composer des services à travers les PDBs. Afin d’éviter
la violation de QdS visé dans un segment, des mécanismes de détection d'erreur de la QdS seront
déployés aux routeurs de bordure pour signaler le défaut. Les routeurs de bordure à leur tour
peuvent choisir de déclencher des techniques de récupération d'erreur. Les actions pour rétablir
57
l’erreur seront exécutées sur l’agrégat tout entier conformément au modèle DiffServ. Ces actions
peuvent être vues comme faisant partie de SLA bilatéral entre les fournisseurs. Cette méthode ne
nécessite aucune connaissance liée au micro flow.
La récupération de l'erreur segmentée permettra au réseau de contrôler sa propre utilisation
des ressources dans la structure DiffServ.
III. Implémentation sous ANTS :
Le but de l’implémentation, qui est en cours, est de valider l’architecture et ses composants.
Notre implémentation se basera sur la plate-forme développée dans le cadre d’un projet RNRT
Amarage. Cette version d’ANTS V1.2, écrit en JAVA, a été développée par le Loria et permet à
ANTS de fonctionner sur IPV6.
A l’inverse du plan architectural, dans l’implémentation, le nœud DiffServ (figure 28)
réside entre l’environnement d’exécution et le niveau IP. Les différents algorithmes du classifier
et ceux des éléments constituants le TCB seront intégrés dans ANTS. Les classes « Channel »,
« AddressChannel »,… « » seront modifiées pour créer plusieurs files d’attente, chacune pour
une classe de service donnée. De plus, au lieu d’une discipline de scheduling FIFO, une Priority
Queuing (PQ) algorithme est intégré pour servir les différentes files d’attente selon leurs
priorités.
Control Plane
Filtrage
Environnement d'Exécution
Active Diffserv/ Data Plane
ANEP
Node OS
Active Node
ANTS
Node OS
Niveau IP
Router (Hardware)
Figure 28 : Implémentation du DiffServ Actif
Dans l’architecture DiffServ, le traitement différencié des paquets s’appuie sur trois
opérations fondamentales. La classification des flux en classes de service, l’introduction de
priorités au sein des classes et la gestion du trafic dans une classe donné.
Pour l’implémentation, deux types de flux seront utilisés dans chacun de deux scénarios :
Un flux qui modélise le trafic EF/AF (flux prioritaire) et un flux qui modélise le trafic BE (flux
non prioritaire), donc deux files d’attentes seront gérées, une pour chaque type de flux (EF, BE).
Ces files sont servies par un Ordonnanceur suivant le modèle PQ où la file de la classe EF a une
priorité plus haute que la file BE.
58
Le premier scénario/démonstrateur (figure 29) utilisé afin de tester cette implémentation,
représente un domaine qui doit être géré par un PDP. Il est constitué de trois nœuds
interconnectés, deux nœuds de bordures et un nœud de cœur. Le trafic est généré par deux
sources clients, Sender1 et Sender 2. Ils sont connectés aux routeurs de bordure, edge1 et edge2.
Ces deux nœuds de bordure contiennent des TCBs comportant la classification du trafic, le
policing et le marquage. Deux récepteurs, receiver1 et receiver2 connectés avec le routeur de
cœur, reçoivent les flux envoyés respectivement par sender1 et sender2. Le routeur de cœur
implémente une « priority scheduling » algorithme pour les agrégats selon leurs priorités. Le
deuxième scénario (figure 30) est plus complexe due à la nécessité d’utilisé un classifier multi
field aux routeurs de bordure. Pour ce deuxième scénario, le premier émetteur génère un flux AF,
par contre le deuxième génère un flux best effort.
Edge Router
Edge Router
Sender 1
Sender 2
BE
EF
Classification
Policing
Marking
Core router
BE
EF
Classification
Policing
Marking
Classification
Priority
Scheduling
Receiver 2
Receiver 1
Figure 29 : Scénario (1) de différentiation des services.
Receiver 1
AF
Sender 1
BE
Sender 2
Edge Router
Edge Router
Classification
Policing
Marking
Priority
Scheduling
AF
Core
router
BE
Classification
Policing
Marking
Classification Priority Priority
Scheduling
Scheduling
Figure 30 : Scénario (2) de différentiation des services
Les disciplines installées au niveau des routeurs sont les suivants :
59
Receiver 2
III.1. Les disciplines pour les routeurs de bordure :
Le Classifieur par flux (Multi field classifier): Il est utilisé aux routeurs de bordure. Dans le
premier scénario, dés qu’une seule application à la station du client génère du trafic, on n’a pas
besoin des filtres de classification aux routeurs de bordure.
Le Marker : Dans notre Démo, on ne mesure pas le trafic avant de marquer ses paquets. Les
paquets classés par le classifier seront directement marqués par le DSCP correspondant à leurs
classes de service. Ces DSCP sont les suivants : « 000000 » pour le trafic BE et « 101110 » pour
le trafic EF. Le tableau 1 « classes de AF », dans le chapitre II, indique les différents DSCPs pour
chaque classe AF.
Le Policer/ dropper : On utilisera dans notre Démo la discipline « Absolute Droppe r » où
tous les paquets qui arrivent à son entré seront rejetés.
Le Scheduler : Pour le premier scénario, une discipline de « FIFO » est appliquée aux
routeurs de bordure. Par contre, au routeur de cœur, une discipline de « Priority Queuing » est
utilisée.
III.2. Les disciplines pour les routeurs de cœur:
Le classifier par agrégat : un classifier BA sert à classer les paquets selon leurs DSCPs.
Le scheduler : Le traitement différentié dans le cœur d’un réseau DiffServ implique deux
axes : les classes de service et la notion de priorités. Chacune des files d’attente dans le routeur
représente une classe de service. Leurs propriétés, en termes de bande passante ou de retard
moyen, dépendent du mécanisme de scheduling. Pour notre démonstrateur, une discipline de
priority queuing a été choisie.
Priority Queuing, PQ
Le modèle PQ utilise plusieurs files d’attente. Les paquets classifiés sont mis dans l’une des
files correspondant à sa valeur du DSCP. Les files sont ensuite servies suivant un algorithme
spécifique. Celle qui contient les paquets avec la plus haute priorité sera favorisée par rapport
aux autres files. Cependant, l’algorithme PQ induit une dégradation de performances. Lorsque le
trafic classé prioritaire est anormalement élevé, le trafic non prioritaire peut être rejeté par
manque de buffer.
III.3. Le « design » de programmation :
Notre travail fait partie du projet RNRT Amarage où d’autres partenaires du projet ont
besoin d’utiliser notre implémentation pour faire passer leurs flux Multimédia. Pour cela, il est
très utile de mettre un « design » flexible pour permettre aux autres partenaires d’insérer
facilement des classes, de profiter des interfaces, …etc que nous offrant par notre architecture.
La figure suivante (figure 31) montre plus en détaille, le placement de notre module de
Qualité de service dans l’architecture de la plate forme ANTS. Notre module se positionne dans
la classe Channel et offre une Qualité de Service en appliquant un modèle DiffServ entre les
différentes capsules reçues. Cette figure montre aussi les quatre interfaces entre ses composantes:
deux interfaces sont entre le système d’exploitation et la classe Channel et les autres sont entre la
classe Channel et le nœud DiffServ. Ces interfaces sont :
60
“sendToEE”: Cette interface a pour rôle d’envoyer les capsules filtrées par la fonction de
« By pass » à l’environnement d’exécution.
“receivefromEE”: Cette interface a pour rôle de délivrer les capsules traitées par
l’environnement d’exécution au plan de données.
“receiveFromOS”: Cette interface a pour rôle de recevoir les paquets arrivant au nœud.
“sendToOS”: Cette interface a pour rôle d’envoyer les paquets traités dans le nœud au
système d’exploitation pour les transmettre au nœud suivant.
Node
Channel
Réception/Emission de capsules
Du Node
QoS
Réception/Emission de capsules
De L’OS
OS
Figure 31 : Placement de QdS dans la plate forme ANTS.
Notre module sera constitué d’une classe Filter et d’une classe TCB (figure 32). La classe
Filter s’occupe de « by passer » les capsules a l’environnement d’exécution si elle le souhaite et
la classe TCB s’occupe du conditionnement du trafic pour offrir de la qualité de service. La
classe TCB est elle-même constituer de plusieurs classes représentant les différents éléments du
TCB. Nous décrivons ci-dessous les différentes classes en spécifiant leurs fonctionnalités dans
l’architecture.
61
ActiveQos
TCB
ActiveQos
CoActiveQos
EdActiveQos
EdActiveQos1
Filter
EdActiveQos2
CoActiveQos2
CoActiveQos1
Figure 32 : Hiérarchie des classes (a)
TcbElem
Classifier
Dropper
Meter
TCB
Scheduler
Classifier
Meter
EdClass
Dropper
CoClass
EdDropp
CoDropp
Figure 33 : Hiérarchie des classes (b)
Capsule
QosCapsule
OpCapsule
MajCapsule
DataCapsule
Figure 34 : Hiérarchie des classes (c)
62
…
La classe ActiveQos :
C’est une classe générique qui représente le plan de données d’un nœud DiffServ. Elle
comporte la classe TCB et la classe Filter et implémente les quatre interfaces citées ci-dessus.
Cette classe initialise un Thread qui s’occupe de recevoir les capsules, les envoyer à
l’environnement d’exécution et les délivrer au premier élément du TCB.
ActiveQos a deux branches : EdActiveQos et CoActiveQos.
La classe EdActiveQos :
Cette classe hérite la classe ActiveQos. Elle représente le plan de données de DiffServ au
niveau du nœud de bordure. Elle instancie les plans de données aux nœuds de bordure :
EdActiveQos1 et EdActiveQos2
La classe CoActiveQos :
Pareillement que la classe précédente, sauf que cette classe représente le plan de données du
DiffServ au niveau du nœud du cœur. Elle instancie CoActiveQos1 et CoActiveQos2.
La classe Filter :
Cette classe fait partie de la classe ActiveQos. Elle contient une fonction de « byPass »
suivant le flow ID d’une capsule. La fonction « bypass » situant en amont du TCB, permettent de
retirer les capsules avant que celles ci ne soient prises en compte par le TCB. Cette fonction doit
être capable d’intercepter uniquement les capsules que devons être exécutées sur le nœud actif.
La classe FlowId :
Elle identifie les flux de chacune des applications actives. Cet identifiant pourra être le
quintuplé (adresse source, adresse destination, N°port source, N° port destination, protocole ID)
pour IPV4, ou le champ FlowID pour IPV6. Donc cette classe contient le quintuplé du IPV4 et le
FlowID du IPV6.
La classe TCB :
Cette classe représente le trafic conditionning block d’un nœud DiffServ. Elle comporte le
classifier, le Dropper, le Scheduler, le Meter, le Marker.
La classe TCBElem :
Cette classe représente chaque élément du TCB (figure 33). Elle a une branche pour chaque
élément : Classifier, Dropper, Scheduler. Elle contient deux fonctions : exec() et
deliverToNext().
La fonction « exec » est une fonction abstract. C à d, qu’elle a un rôle spécifique à chaque
élément du TCB. Par exemple, la fonction « exec » classifie les paquets entrant dans la classe
classifier. Par contre, elle marque les paquets dans le Marker. Cette fonction prend comme
paramètre la capsule.
Chaque élément du TCB, après avoir reçu la capsule, il la traite et l’envoie à l’élément
suivant à travers la fonction « deliverToNext ». Cette fonction prend comme paramètre : la
capsule et l’élément suivant à lequel envoie la capsule.
La classe Classifier :
Cette classe est sous la forme d’un Thread pour recevoir les capsules émises par la classe
filter et se charge de les classifier dans des classes de service.
63
La classe Scheduler :
Cette classe est sous la forme d’un Thread pour lire des capsules à partir des files d’attentes
et les envoyer au système d’exploitation pour les transmettre dans le réseau.
Seulement, le classifier et le scheduler sont sous forme de thread. Tous les classes qui
héritent de la classe TcbElem ont chacun deux branches de classe: Une classe pour l’élément de
bordure, l’autre pour l’élément de cœur. Les autres classes déterminent la fonction exec()
implémenté dans chaque élément du Tcb.
La classe Capsule :
Cette classe faisant partie du package ANTS et est la généralisation d’un paquet. Chaque
nouvelle capsule se fait toujours en prenant une sous classe de la classe capsule (figure 34). La
méthode principale d’une capsule est la méthode evaluate(Node n) qui s’exécute à chaque nœud
traversé par la capsule.
La classe QosCapsule :
Cette classe hérite de la classe Capsule. Elle permet de rendre la capsule fondamentale de
ANTS, une capsule qui transporte des indications de ses exigences de Qds. Donc la classe
QosCapsule est la généralisation d’un paquet DiffServ dans notre architecture. Toutes les classes
des capsules traversant le réseau DiffServ actif sous classe la classe QosCapsule. Ces sous
classes sont : OpCapsule, MajCapsule, DataCapsule
La classe DataCapsule :
Cette classe hérite de la classe QosCapsule. Elle permet aux applications de transmettre les
données utilisant les routes par Défaut et en profitant des paramètres de QdS existants (hérité de
QosCapsule).
La classe OpCapsule :
Cette classe représente les capsules qui transportent les codes des algorithmes des
applications actives et les mécanismes des éléments du TCB.
La classe MajCapsule :
Cette classe représente la capsule d’ouverture de la session quand un opérateur désire
envoyer son flux. C à d, celles de l’application de mettre à jour le tableau de Flow Id dans chaque
nœud.
IV. Conclusion:
Dans ce chapitre, nous avons proposé une architecture de contrôle actif d'un nœud DiffServ
ainsi que donné un exemple d'une application de contrôle active. Nous avons également décrit le
modèle d'implémentation qui nous permettra de valider l'architecture proposée et ses
composantes. Finalement, on a détaillé la spécification de la hiérarchie des classes pour
l'intégration des différents éléments du TCB dans l'approche ANTS.
64
Chapitre VI
Conclusion et Perspectives
Plusieurs problèmes ont été identifiés dans l’Internet actuel. Principalement le manque ou
l’absence de qualité de service (QdS) adéquate pour les applications multimédia. 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 de ses applications est
l’approche DiffServ basé sur la notion d’agrégats pour assurer la QdS. Cependant, L’approche
DiffServ nécessite une infrastructure de gestion de QdS. Cette infrastructure doit les permettre de
configurer, contrôler et maintenir le niveau de QdS demandée. La configuration d’un réseau
DiffServ revient à configurer les TCBs des routeurs de bordure et des routeurs de cœur. Ces
TCBs sont actuellement implantés de façon statique dans les routeurs et utilisent des algorithmes
de conditionnement implémentés en hardware.
Dans ce rapport, nous avons tout d’abord introduit l’architecture de contrôle par politiques
pour les réseaux à différentiation de services, afin de faire ressortir les manques liés à cette
approche. Les principaux inconvénients de cette architecture résident en sa rigidité. En effet,
aucun contrôle n’est effectué afin de vérifier la bonne délivrance des SLAs auxquelles ont
souscrit les clients. Et surtout aucune reprise en cas de problème n’est effectuée. Dans ce cadre
là, nous avons proposé une architecture de contrôle complète qui à pour but :
(i) de faciliter l’introduction de nouveaux algorithmes de contrôles distribué sous forme
d’applications actives et
(ii) D’automatiser la reconfiguration des nœuds du réseau en cas de problème aux travers
de l’installation de nouveaux TCB et/ou de la configuration dynamique des
algorithmes de conditionnement de trafic.
L’approche ACDN, que nous proposons, se base sur le paradigme des réseaux actifs. Ce
choix a été motivé par le besoin d’une infrastructure flexible pour un déploiement rapide et
transparent des différentes fonctionnalités introduites. Cette approche semble pallier aux
manques listés ci dessus tout en respectant les spécificités du modèle DiffServ, normalisé par
l’IETF, et du modèle de contrôle par politiques, également introduit à l’IETF par le groupe de
travail RAP.
Afin d’implémenter le nœud DiffServ actif, on a choisit la plate-forme active ANTS. Nous
avons détaillé comment cette plate-forme peut être étendue afin d’intégrer toutes les composantes
d’un nœud DiffServ (TCBs). Des études complémentaires sont en cours afin d’introduire et de
tester différents algorithmes de contrôle distribués. En effet, ces applications peuvent tirer partie
des possibilités offertes par le paradigme des réseaux actifs. Nous nous intéressons plus
particulièrement, aux sondes de métrologies actives et aux algorithmes de provisionning
dynamique. Le but final étant de minimiser l’apparition de congestions à long terme et le respect
des SLAs souscrits par les clients.
Finalement, Un article, soumis à la conférence de JDIR’2002 qui se déroulera en mars à
Toulouse, France, résume notre travail. L’article s’intitule : Contrôle Actif des Réseaux DiffServ
65
Annexe :
Contrôle Actif des Réseaux DiffServ
Yacine M. GHAMRI-DOUDANE, Rima TFAILY, Nadjib ACHIR et Guy PUJOLLE
Laboratoire LIP6 - Université Pierre et Marie CURIE
8, rue du capitaine Scott, 75015 Paris, France.
{ghamri , tfaily , achir , pujolle}@rp.lip6.fr
Résumé
Dans cet article, nous proposons une architecture permettant d’automatiser et de distribuer
le contrôle dans un réseau DiffServ. En effet, l’architecture de contrôle par politique actuellement
normalisée par l’IETF pour les réseaux DiffServ souffre d’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) le 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) le 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.
Mots clefs : DiffServ, contrôle par politiques, contrôle actif.
Introduction
Un des plus grands challenges de ces dernières années est la distribution d’applications
multimédias à 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é, 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 [1]. Cette approche permet de garantir une QdS, par flux, sur le chemin qu’il
emprunte dans le réseau. 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 pallier à cet inconvénient, une
autre approche, DiffServ ou différentiation de services [2,3], 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égations 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 du modèle permettant la prise en compte de la qualité de service (IntServ,
66
gestion est le modèle de contrôle par politiques [4]. Cette infrastructure est un ensemble de
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 [3].
Un utilisateur voulant souscrire à un service (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 [5,6,7] sont actuellement proposés par la
communauté de recherche afin de pallier à ces éventuels dysfonctionnements. Comme certains de
ces algorithmes nécessite une architecture très flexible [7], 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 pallier à cela, nous proposons dans ce papier une architecture
complète de contrôle pour les réseaux DiffServ. Cette architecture permettra :
1. d’administrer dynamiquement le réseau en cas de dysfonctionnement aux travers
de politiques actives.
2. D’offrir une infrastructure flexible pour l’introduction d’algorithmes de contrôle
distribués sous forme d’applications actives.
La suite de l’article est organisée de la manière suivante. La section 2 est dédiée à la
présentation de l’approche DiffServ. Dans la section 3 nous présenterons plus en détail le modèle
de contrôle par politiques. Une brève présentation des réseaux actifs se fera dans la section 4. Par
la suite, la section 5 donne la description détaillée de notre architecture de contrôle actif des
réseaux DiffServ (ACDN). Finalement, on présente les conclusions et les perspectives dans la
section 6.
DiffServ
L’approche DiffServ [2], 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’Internet actuel le réseau fait de son
mieux pour transporter les paquets d’un bout à l’autre du réseau sans aucune distinction entre les
paquets. Le réseau n’effectue aucune opération de contrôle de flux laissant aux extrémités le soin
de se partager la bande passante disponible. Ainsi, les connexions TCP sont supposées utiliser
chacune une part équitable de la bande passante qu’elles se partagent. 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 aux problème de mise à l’échelle.
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
se situent aux frontières d’un domaine et se chargent (i) de la mise en forme d’un flux en
67
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. La valeur de cette étiquette pour un flux donné dépend de son
SLS et de son comportement instantané. Une fois étiqueté, le paquet utilise le DSCP pour choisir
la file d’attente adéquate, 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.
Meter1
Marker1
Absolute
Dropper1
Classifier
/MF
Marker2
Meter2
Absolute
Dropper2
Marker3
MUX
1
Meter3
Absolute
Dropper3
(a)
Queue1
Classifier/
BA
Shaper/
Scheduler1
Queue2
(b)
Figure 1 : Blocs de conditionnement de trafic pour le : (a) routeur de bordure, (b) routeur de
cœur.
La figure 1 montre les blocs de conditionnement de trafic17 (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 2). 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.
17
Se rapporter à [8], pour une définition complète de chacun des éléments du TCB.
68
Meter1
Queue1
Counter1
Absolute
Dropper1
Algorithmic
Dropper1
Meter2
Mux1
Algorithmic
Dropper2
Queue2
Shaper/
Scheduler
1
Queue3
Classifier/
par agrégat
Marker1
Algorithmic
Dropper3
Queue4
Figure 2 : Blocs de conditionnement de trafic pour le routeur de cœur.
Le contrôle par politiques
Le terme politique [4] é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 3, dénote 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 quand à elle 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 3 : Hiérarchie conceptuelle de politique.
69
Policy
Repository
outil de gestion
PEP
PDP
PDP
PEP
PEP
PEP
Figure 4 : Architecture de contrôle par politique.
La figure 4, montre un model généralisé de l’architecture de contrôle par politique. Cette
figure montre les différents composants d’un domaine de politique, que nous allons détailler plus
bas.
Un domaine de politique est la portion d’un réseau qui est administrée et gérée par un
même ensemble de politique. Ces politiques seront stockées dans une entité appelée policy
repository. Le PEP18 est l’élément responsable de l’application et de l’exécution des actions de la
politique, c’est également l’élément qui va prendre en charge le traitement des paquets en
fonction d’une politique donnée. Le PDP19, quand à lui, a pour tache de déterminer quelle action
va être appliquée et à quel paquet. Le PDP interprète les règles des politiques, stockées dans le
policy repository, pour un ou plusieurs PEPs. Pour cela le PDP se base sur les conditions
courantes du réseau ainsi que sur les informations transmises par ces derniers en utilisant un
protocole de signalisation tels que COPS [9]. En effet le protocole COPS semble être le candidat
privilégié par l’IETF pour cette tache.
Le PEP peut demander au PDP de prendre des décisions en son nom sur l’occurrence d’un
événement (modèle Outsourcing [10]) ou faire une demande de configuration (modèle
Provisionning [11]). Dans le cas de DiffServ par exemple, le modèle Outsourcing permettrait de
faire un contrôle d’admission au niveau des routeurs de bordures. le protocole COPS PR, quand à
lui, permettrait de transporter les décisions permettant de configurer les TCBs des routeurs de
bordure et des routeurs de cœur. Notons cependant qu’aucun mécanisme ne permet à ce jour de
mettre en place dynamiquement les TCBs qui sont implantés de façon statique dans les routeurs
et utilisent des algorithmes de conditionnement implémentés en hardware. La technologie des
réseaux actifs peut donc être efficacement utilisée dans ce but, permettant ainsi de mettre en
place dynamiquement les TCBs et de déployer dynamiquement de nouveaux algorithmes de
conditionnement aux besoins.
Les Réseaux Actifs
Les réseaux actifs [12] représentent une nouvelle approche de conception de services
réseaux. En effet, leurs buts résident 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
18
19
Policy Enforcement Point
Policy Decision Point
70
contrôle. Ce paradigme apparaît donc comme étant tout à fait à l’opposé de l’argument de bout
en bout qui guide traditionnellement la conception et la mise en place des architectures de
communications actuelles [13].
Les majeur partie des recherches sur les réseaux actifs dans ces débuts ayant été soutenue
par la DARPA20 aux états unies [14]. Cette dernière a décomposé l’architecture d’un nœud actif
[15] en trois parties majeures (Figure 5). Les applications actives (AAs) représentant des codes
spécifiques à un environnent d’exécution particulier et déployées par les clients.
L’environnement d’exécution (EE) lequel agit comme un programme fournissant une interface à
travers laquelle des services réseaux élémentaires sont accédés. Le système d’exploitation du
nœud actif (NodeOS) quand à lui fournit les fonctionnalités de base à partir desquelles les
environnements d’exécution construisent les abstractions qui sont présentées aux applications
actives. Au niveau du NodeOS le protocole ANEP [16] s’occupera également du
multiplexage/démultiplexage des flux destinés et provenant des différents environnements
d’exécutions.
AA :
Application
Active
AA :
Application
Active
AA :
Application
Active
EE : Environement d'Exécution
EE : Environement d'Exécution
ANEP
Node OS
Figure 5 : Architecture d’un nœud actif.
Actuellement la communauté de recherche est très divisée sur l’utilité de ce type
d’architecture. D’une part, les réseaux actifs fournissent une infrastructure réseau très flexible
dont tout type de flux peut tiré parti. D’autre part, ces réseaux sont extrêmement plus complexes
à mettre en œuvre que les réseaux traditionnels et soulèvent des problèmes de sécurité
considérables. Cependant cet inconvénient apparaît être moins contraignant dans le cas ou l’accès
aux ressources actives est limité à un ensemble restreint d’utilisateurs. Pour ces différentes
raisons nous préconisons l’utilisation des réseaux actifs non pas par n’importe quel type de
clients plutôt par des administrateurs de réseaux et des fournisseurs de services. Ces derniers
pourront donc développer et déployer différents types de politiques de contrôle et de gestion dans
leurs réseaux. En effet, la technologie des réseaux actifs peut être très bénéfique dans ce cadre
précis où les réseaux actifs vont définir une extension du plan de contrôle indépendamment du
plan de données qui pourra continuer à respecter le traditionnel argument de bout en bout.
L’architecture ACDN
Actuellement, les contrôles sont fait de façon 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
(Figure 6). Le modèle proposé a donc pour but d’introduire un ensemble de fonctionnalités
20
La DARPA est l’organisme de recherche dépendant du ministère de la défense américain.
71
permettant d’automatiser et de distribuer le contrôle des différents nœuds du réseau. Ce modèle
exploitera les notions introduites par le paradigme des réseaux actifs pour permettre une
introduction rapide et transparente de ces fonctionnalités.
Policy
Repository
station
d'administration
Plan de
contrôle
(serveurs)
Routeur
DiffServ
plan de données
(DiffServ)
COPS -PR
PDP
TCB
Figure 6 : Architecture de contrôle des réseaux DiffServ.
L’architecture ACDN21 est une architecture de contrôle tirant partie de la flexibilité des
réseaux actifs tout en respectant les spécificités de l’approche DiffServ ainsi que les spécificités
du modèle de contrôle par politique présenté plus haut. Cette architecture permet d’offrir un
cadre général pour un contrôle complet d’un domaine DiffServ. Ce contrôle se fera en deux
phases :
1. La première phase, consiste en le déploiement sur les nœuds du réseau, par
l’administrateur du réseau ou un ISP, d’applications de contrôle distribuées sous
forme d’applications actives (AA). Cette phase est appelée contrôle par applications
actives.
2. La seconde phase, consiste en le déploiement et en l’installation de
nouveaux TCBs dans les nœuds DiffServ dépendamment de ce qui se passe dans le
réseau. En effet, lorsque le réseau est peut chargé, et donc bien dimensionné, un
administrateur de réseau peut se contenter d’installer dans les routeur de cœur une
version simplifiée du TCB (cf. Figure 1b). Cependant, si le besoin s’en fait ressentir,
une application de contrôle peut déclencher l’installation d’un nouveau TCB plus
complexe (cf. Figure 2). La complexité du TCB installé dépendra du problème
rencontré dans le réseau, lequel peut être détecté par une application active. Cette
phase est appelée contrôle par politiques actives.
La figure 7 montre les différents éléments composant l’architecture ACDN, les rôles
respectifs de ces éléments sont :
•
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
21
ACDN : Active Control of DiffServ Network .
72
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 (TCA) 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 (AA et TCA) : 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 direction est réalisée grâce à la fonction de filtrage que l’on
détaille plus bas.
station d'administration
Plan de contrôle (serveurs)
Serveur de
Code
(AA)
Serveur de
code
(TCA)
Policy
Repository
Mecanisme
d'installation
Mecanisme
d'installation
PDP
COPS -PR
Application
de Contrôle
AA
Routeur
DiffServ
ANEP
Fonction de Filtrage
TCB
Plan de donnée (DiffServ)
Figure 7 : Architecture ACDN
Fonction de filtrage
Afin que les différents agents, constituants les applications de contrôle distribuées, puissent
communiquer entre eux, une fonction de filtrage a été introduite. Cette fonction aura pour tache
73
de reconnaître puis d’intercepter les capsules (paquets actifs) appartenant aux applications actives
installées dans le nœud.
Comme vu sur la Figure 8, cette fonction se situe en amont du TCB, permettant ainsi de
retirer les capsules avant que celles ci ne soient prises en compte par le TCB puis de les remettre
sur le chemin des données (Data path). Afin de rester conforme avec le modèle DiffServ, on
notera également que cette fonction doit marquer les paquets (champs DSCP) avant de les mettre
sur le chemin des données. Ce marquage se fera selon la QdS que l’administrateur attribuera à
son application de contrôle.
Une application active pouvant être installé sur un ensemble restreint de nœuds dans le
réseau, il est nécessaire que la fonction de filtrage puisse intercepter uniquement les capsules des
applications actives que le nœud contient. Pour se faire, la fonction de filtrage utilisera une table
de FlowID identifiant chacune des applications actives du nœud. Cet identifiant pourra être le
quintuplé (adresse source, adresse destination, N° port source, N° port destination, protocole ID)
pour IPv4 ou le champ FlowID pour IPv6.
La table des FlowID est mise à jour à chaque fois qu’une application de contrôle distribuée
est introduite ou retirée du réseau. Cette mise à jour s’effectue par une application active résidant
de façon permanente dans tous les nœuds du réseau.
MAJ
FlowID
Routeur DiffServ
(Architecture ACDN)
ANEP
Tableau
FlowId
Fonction de
filtrage
Plan de donnée
(DiffServ)
TCB
Figure 8 : Mise à jour de la table des FlowID et fonction de filtrage
Afin de pallier au problème de mise à l’échelle qui pourra survenir. Le nombre
d’applications actives dans un nœud sera limité.
Conclusion & Perspectives
Dans ce document, nous avons tous d’abord introduit l’architecture de contrôle par
politiques pour les réseaux à différentiation de services, afin de faire ressortir les manques liés à
cette approche. Les principaux inconvénients de cette architecture résident en sa rigidité. En
effet, aucun contrôle n’est effectué afin de vérifier la bonne délivrance des SLAs auxquelles ont
souscrit les clients. Et surtout aucune reprise en cas de problème n’est effectuée. Dans ce cadre
là, nous avons proposé une architecture de contrôle complète qui à pour but : (i) de faciliter
l’introduction de nouveaux algorithmes de contrôles distribués sous forme d’applications actives
et (ii) d’automatiser la reconfiguration des nœuds du réseau en cas de problème aux travers de
l’installation de nouveaux TCB et/ou de la configuration dynamique des algorithmes de
conditionnement de trafic.
L’approche ACDN se base sur le paradigme des réseaux actifs. Ce choix a été motivé par le
besoin d’une infrastructure flexible pour un déploiement rapide et transparent des différentes
fonctionnalités introduites. Cette approche semble pallier aux manques listés ci dessus tout en
74
respectant les spécificités du modèle DiffServ, normalisé par l’IETF, et du modèle de contrôle
par politiques, également introduit à l’IETF par le groupe de travail RAP.
Des études complémentaires sont en cours afin d’introduire et de tester différents
algorithmes de contrôle distribués. En effet, ces applications peuvent tirer partie des possibilités
offertes par le paradigme des réseaux actifs. Nous nous intéressons plus particulièrement, aux
sondes de métrologies actives et aux algorithmes de provisionning dynamique. Le but finale étant
de minimiser l’apparition de congestions à long terme et le respect des SLAs souscrits par les
clients.
Bibliographies
[1] WROCLAWSKI J., « The Use of RSVP with IETF Integrated Services », RFC 2210,
September 1997.
[2] BLAKE S., ET AL., « An Architecture for Differentiated Services », RFC 2475,
December 1998.
[3] NICHOLS K., JACOBSON V., ZHANG L., « A Two-bit Differentiated Services Architecture
for the Internet », RFC 2638, July 1999.
[4] RAJAN R., VERMA D., KAMAT S., FELSTAINE E., AND HERZOG S., « A policy framework
for integrated and differentiated services in the Internet », IEEE Network Magazine, vol. 13, no.
5, pp. 6-41, September / October 1999.
[5] LIAO R.F., and CAMPBELL A.T., « Dynamic Core Provisioning for Quantitative
Differentiated Service », 9th International Workshop on Quality of Service (IEEE/ACM/IFIP
IWQOS 2001), Karlsruhe, Germany, June 2001.
[6] LIAO R.F., and CAMPBELL A.T., « Dynamic Edge Provisioning for Core IP Networks »,
8th International Workshop on Quality of Service (IEEE/ACM/IFIP IWQOS 2000), Pittsburgh,
USA, June 2000.
[7] DE MEER H., AND O’HANLON P., « Segmented Adaptation of Traffic Aggregates », 9th
International Workshop on Quality of Service (IEEE/ACM/IFIP IWQOS 2001), Karlsruhe,
Germany, June 2001.
[8] FINE M., ET AL., « Differentiated Services Quality of Service Policy Information Base »,
Internet Draft, draft-ietf-diffserv-pib-04.txt, Juillet 2001.
[9] DURHAM D., ET AL., « The COPS (Common Open Policy Service) Protocol », RFC
2748, January 2000.
[10] HERZOG S., ET AL., « COPS usage for RSVP », RFC 2749, January 2000.
[11] CHAN K., ET AL., « COPS Usage for Policy Provisioning (COPS-PR) », RFC 3084,
March 2001.
[12] PSOUNIS K., « Active Networks : Applications, Security, Safety, and Architectures »,
IEEE Communications Surveys Magazine, 1st quarter issue, 1999.
[13] BHATTACHARJEE S., CALVERT K., ZEGURA E., « Active Networking and the end to end
argument, in Proceedings of ICNP `97, Atlanta, GA, Oct. 1997.
[14] http://www.darpa.org/activenets/
[15] CALVERT K. L., « Architectural Framework for Active Networks », Draft, DARPA AN
Working Group, Juillet 1999.
[16] ALEXANDER D. S., ET AL., « Active Network Encapsulation Protocol », Draft, DARPA
AN Working Group, Juillet 1997.
Fin de l’article
75
LES REFERENCES:
A. références DiffServ et COPS
[1] RFC 2748 , Common Open Policy Service Protocol ", January 2000.
[2] RFC 2749 "COPS usage for RSVP " , January 2000.
[3] RFC 3084,“COPS usage for policy provisioning (COPS-PR)”; March 2001.
[4] Cisco systems ; http://www.cisco.com ; Documentation:”COPS for RSVP”.
[5] RFC 2475 : Informational : « An Architecture for Differentiated Services », December
1998.
[6] RFC 2598 : Standard Track « An Expedited Forwarding PHB », June 1999.
[7] RFC 2597 Standard Tracks « Assured Forwarding PHB Group », June 1999.
[8] RFC 2638 « A Two-bit Differentiated Architecture for the Internet », July 1999.
[9] A Policy Framework for integrated and Differentiated services in the Internet.
[10] Internet Quality of service: an overview
[12] http:://www.qosforum.com, QOS Protocols and architectures, July1999
[13] RFC 2474: Definition of the Differentiated services field (DS field) in the Ipv4 and
Ipv6 headers , December 1998
[14]E.Horlait, N.Rouhana, Qualité de service dans l’architecture TCP /IP, Laboratoire
LIP6, Mars 2000.
B. Références réseaux actifs :
[1] IEEE Communications surveys; Active Networks : Applications, Security, Safety, And
Architectures. Konstantinos Psounis, Stanford University; 1999
[2] IEEE Openarch 98; ANTS: A ToolKit for Building and Dynamically Deploying
Network Protocols, David J. Wetherall, John V. Guttage and David L. Tennenhouse; April
1998
[3] Developing Network Protocols With the ANTS ToolKit, David Wetherall ; August
1997
[4] Les Réseaux Programmables 1.0; Olivier Festor, Isabelle Chrisment, Eric Fleury.
[5] Directions in Active Networks; Kenneth L. Clavert, Samrat Bhattacharjee, Ellen Zegura
Http://www.tns.lcs.mit.edu/publications/ieeecomms97.html.
76
[6] RFC Draft , Active Network Encapsulation Protocol (ANEP); D.Scott alexander, Bob
Braden, Garl A.Gunter, Alden W.Jackson, Angelos D. Keromytis, Gar J.Minden, David
Wetherall. Http://www.cis.upenn.edu/~switchware/ANEP
[7] Segmented Adaptation of Traffic Affregates, Hermann de Meer and piers O’Hman.
Department of Computer Science, University College London.
77