D´ efinition de la politique de QoS r´ eseau pour Platsim QoS sur DDS

Pour l’impl´ementation de la QoS pour PlatSim QoS sur DDS sur une architecture DiffServ dans un r´eseau multi-domaines, nous avons utilis´e le serveur de gestion de la QoS propos´e dans le cadre du projet EuQoS appel´e ”Velox”. Velox g`ere la signalisation et la r´eservation des ressources au niveau r´eseau. Nous d´ecrivons dans cette section l’architecture de Velox et son utilisation pour la mise en place de la procedure de signalisation dans le projet PlatSim. Ensuite, nous pr´esenterons le m´ecanisme de r´eservation de ressources et de contrˆole d’admission. Enfin, nous d´ecrirons la mise en place du chemin de donn´ees permettant le transfert des donn´ees de simulation entre les diff´erents participants.

5.3.3.1 Mapping de la QoS r´eseau `a l’aide du middleware DDS

Rappelons que dans le chapitre 3, nous avons d´efini les diff´erentes classes de trafic pour la fourniture de la QoS sur des r´eseaux locaux. Dans le mˆeme esprit, nous avons r´eutilis´e ces classes de trafic pour assurer la signalisation de la QoS de bout en bout entre r´eseaux h´et´erog`enes. Notons aussi que le marquage des paquets au niveau du middleware DDS est g´er´e par la politique de QoS DDS ”Transport Priority”. Ce param`etre permet de sp´ecifier `a l’application le niveau de priorit´e (l’attribut DiffServField) `a prendre en compte lors de la distribution des ´echantillons (au niveau du profil de production), niveau qui sera par la suite converti en champs DSCP pour indiquer le traitement ad´equat au niveau r´eseau.

5.3.3.2 Le serveur de QoS Velox

Velox est un gestionnaire de bande passante qui permet la gestion de la QoS et le contrˆole des ressources r´eseau via des Web services1_{. Son objectif est de cacher la complexit´e du r´eseau sous-}

jacent pour offrir `a l’utilisateur, par exemple de la plateforme Platsim QoS ou `a l’administrateur du r´eseau, des services stables permettant d’installer, de maintenir et de lib´erer les ressources de bout-en-bout avec plusieurs niveaux de QoS diff´erents.

En effet, Velox est exploitable pour la gestion des ressources en r´eseau mono-domaine et/ou r´eseaux multi-domaines. Dans ce dernier cas, Velox communique en mode point-`a-point avec d’autres serveurs de QoS et avec les routeurs de sortie de chaque domaine. Il permet de n´egocier et d´eployer des services de QoS diff´erents (EF, AF, etc.) entre les diff´erents domaines. Il offre une grande granularit´e de classes de services, g´er´ees par deux types de services :

1. Network Service : repr´esente une voie qui comporte un ou plusieurs routeurs. Lors de la cr´eation d’un service r´eseau une bande passante doit ˆetre assign´ee pour cette voie, permettant `a plusieurs sessions r´eseaux d’utiliser cette bande passante. Plusieurs ”Net- work Services” peuvent ˆetre cr´e´es et sont distingu´es par 7 couleurs diff´erentes. En outre, il est possible d’associer des scripts pour les routeurs qui ont ´et´e affect´es `a un service r´eseau donn´e. Ces scripts sont utilis´es pour configurer correctement les routeurs lors du d´eclenchement du service.

2. Session Service : Correspond `a un type de service ou bien `a une classe de service DiffServ dans un ”Network Service” donn´e. Une bande passante doit ˆetre assign´ee `a chaque session et sera allou´ee par le service r´eseau lors du d´eclenchement du service ”Trigger” de Velox.

La Figure 5.9 illustre l’utilisation d’un tunnel MPLS entre les deux routeurs Posets et Mont- perdu pour la r´eservation des ressources pour PlatSim QoS.

Figure 5.9: Configuration du lien entre les routeurs Posets et Montperdu

Velox utilise aussi un service que nous utilisons pour le d´eclenchement de la r´eservation de la bande passante (voir Figure 5.10). Pour chaque ”user channel” que nous cr´eons avec le midd- leware DDS nous cr´eons aussi un service de session (session service) pour la publication du profil de production de Platsim QoS dans le service Trigger. Cela permet `a l’application (Plat- sim QoS) de sp´ecifier ses besoins en QoS au r´eseau sous-jacent.

Figure 5.10: Service de d´eclenchement de la r´eservation des ressources

5.3.3.3 D´efinition de la politique de QoS r´eseau

Dans cette partie nous nous focalisons sur la d´efinition d’une politique de QoS r´eseau adapt´ee `

a l’architecture DiffServ. La d´efinition de cette politique se base essentiellement sur les m´eca- nismes de QoS appliqu´es au niveau des routeurs de bordure (Posets et Montperdu dans notre exp´erimentation). Les m´ecanismes mis en oeuvre sont : la classification de trafic, la gestion des files d’attente, la politique de rejet, le ” policer ” et l’ordonnancement. La configuration suivante a ´et´e mise en place :

Class-of-service { Classifier {

D’abord un classificateur DSCP est d´efini et permet d’assigner chaque paquet entrant `a une classe de service appel´ee ”Forwarding Class”. Dans chaque classe, diff´erentes valeurs possibles du champ DSCP ont ´et´e r´eparties avec une valeur significative de ”Loss Priority”.

dscp platsim_dscp_class #Classes de donn´ees PlatSim {

forwarding-class best-effort #Built-in Topic Data

forwarding-class expedited-forwarding #Periodic Real-Time Simulation Data { loss-priority low code-points [101110]; # EF DSCP 46 }

forwarding-class assured-forwarding #State Data/Control Data /Audio-video Data { loss-priority low code-points [001010];# AF11 DSCP 10

loss-priority low code-points [001100];# AF12 DSCP 12 loss-priority low code-points [001110];# AF13 DSCP 14 loss-priority medium code-points [010010];# AF21 DSCP 18

loss-priority medium code-points [010100];# AF22 DSCP 20 loss-priority medium code-points [010110];# AF23 DSCP 22 loss-priority high code-points [011010];# AF31 DSCP 24 loss-priority high code-points [011100];# AF32 DSCP 26 loss-priority high code-points [011110];# AF33 DSCP 28 }

forwarding-class network-control

{ loss-priority low code-points [110000]; # NC1/CS6 DSCP 48 loss-priority low code-points [111000]; # NC2/CS7 DSCP 56 }

}

Les files d’attente du routeur sont cr´e´ees `a partir du classifier. Pour pouvoir les utiliser, il est n´ecessaire de les mapper dans la section ” Forwarding-classes ” avec les quatre files existantes dans la configuration du routeur (Le routeur Juniper M7i supporte des files dans l’ordre de 0 `

a 3). Si le classificateur ne poss`ede qu’une file d’attente, alors il suffit de remplir uniquement la file 0 et les autres files sont toujours pr´esentes mais non utilis´ees. Il est `a noter que la file Network-Control est appropri´ee pour le routeur Juniper et est responsable du transfert des donn´ees de signalisation et des messages d’´etat des liens des routeurs.

forwarding-classes

{ class best-effort queue-num 0;

class expedited-forwarding queue-num 1; class assured-forwarding queue-num 2; class network-control queue-num 3; }

Il est n´ecessaire ensuite de fixer le classificateur d´efini `a l’interface d’entr´ee du routeur et l’or- donnanceur `a l’interface de sortie. Prenant l’exemple sur Montperdu :

interfaces {

ge-0/0/0 #vers Vlan 203 { unit 0 { classifiers { dscp platsim_dscp_class; } } }

ge-1/3/0 #vers Posets {

scheduler-map platsim-sched;

} }

}

La section ” scheduler-maps ” permet d’appliquer une politique de gestion particuli`ere `a chaque file d’attente en termes de bande passante et de taille de la file.

Figure 5.11: Politiques de gestion des files d’attentes scheduler-maps

{ platsim-sched {

forwarding-class expedited-forwarding scheduler EF; forwarding-class assured-forwarding scheduler AF; forwarding-class best-effort scheduler BE;

forwarding-class network-control scheduler NC; } }

Les caract´eristiques de chaque politique de gestion sont d´efinies dans la section ”schedulers” o`u est pr´ecis´e pour chaque queue la bande passante de sortie avec un ”Transmit-rate” et une priorit´e entre (low, high et strict-high). Ces priorit´es permettent de sp´ecifier le poids de chaque queue pour l’ordonnanceur WFQ et finalement une politique de rejet. Il est possible d’appliquer les politiques Tail-Drop ou RED. Cette caract´eristique est montr´ee sur la Figure 5.11.

schedulers{

BE { transmit-rate 400K exact; priority low;

drop-profile-map loss-priority high protocol any drop-profile segment-RED; } EF { transmit-rate 300K exact;

priority strict-high;

drop-profile-map loss-priority low protocol any drop-profile segment-RED; } AF { transmit-rate 200k exact;

priority high;

drop-profile-map loss-priority medium protocol any drop-profile segment-RED; } NC { transmit-rate 100k exact;

priority high;

drop-profile-map loss-priority low protocol any drop-profile segment-RED; } }

La Figure 5.11 d´ecrit la derni`ere section ”Drop-profiles” qui permet de fournir les caract´eris- tiques de chacune des politiques de gestion des files d’attente. ”fill-level” d´efinit le pourcentage d’occupation de la file et ” drop-probability ” la probabilit´e de suppression d’un paquet. La politique Tail-Drop est configur´ee de telle sorte qu’entre 0 et 90% d’occupation de la file aucun paquet n’est supprim´e puis `a partir de 95% tous les paquets sont supprim´es. La politique ”Segmented-RED” met en place une politique de suppression des paquets par palier.