Les outils pour la gestion de la QoS

5.2.3.1 Proxy SIP conscient de la QoS

L’une des possibilit´es pour la configuration de la QoS au niveau des routeurs de bordures est l’utilisation d’un proxy SIP conscient de la QoS en s’inspirant des concepts pr´esent´es dans la section 2.5.8. Pour cela, nous avons apport´e toutes les modifications au proxy Jain-SIP [97] pour qu’il supporte la QoS DDS.

Concernant les nouvelles impl´ementations `a r´ealiser sur le Proxy SIP, il faut d’abord lui per- mettre de reconnaˆıtre un message REGISTER sp´ecifique lui indiquant qu’il doit pr´evenir un ou plusieurs autres Proxies SIP. Pour cela, `a la r´eception du message REGISTER, il doit v´e- rifier que les champs ”From” et ”To” sont diff´erents et que les deux SIP URI sont de la forme ”sip : user name@domain name”. Les deux domain name doivent ˆetre diff´erents pour s’assu- rer qu’il achemine le message REGISTER vers le proxy SIP distant correspondant au champ ”To”. En plus des fonctions classiques de relais entre applications SIP, le proxy SIP `a QoS a la capacit´e de configurer la QoS sur son domaine. Le proxy doit intercepter le descripteur des sessions dans les messages SDP pour en d´eduire les caract´eristiques de la session QoS du Topic DDS qu’il va installer. Les messages SIP doivent alors dans tous les cas passer par ou moins deux proxy SIP am´elior´es pour la mise en place de la QoS de bout-en-bout. Les deux Proxies sont en mode ”Assured ” dans lequel l’´etablissement de la session ne se fait que si la r´eservation de QoS a bien ´et´e r´ealis´ee. Au contraire, dans le mode ”enabled ”, l’´etablissement de la session avec une r´eservation des ressources n’est pas une condition bloquante. En effet, la sp´ecification de DDS n´ecessite que le Publisher et le Subscriber se mettent d’accord sur les param`etres de QoS DDS afin que la communication entre eux puisse s’´etablir. Pour cela, il doit d’une part fonctionner en mode ”stateful” pour maintenir les informations d’´etats de session, et d’autre part garder les traces des messages ´echang´es ce qui n´ecessite la configuration du champ ”Record Route”. Cette solution requiert un serveur de QoS d´ej`a install´e qui, apr`es avoir ´et´e sollicit´e par le proxy, se charge de configurer ces routeurs.

5.2.3.2 Le serveur de QoS am´elior´e

L’outil commun´ement utilis´e pour l’installation des politiques de QoS sur le r´eseau de sortie est le serveur de QoS qui a pour fonction principale de recevoir et analyser les messages de r´eservation et de lib´eration des ressources en provenance du proxy SIP. Nous avons d´ecrit dans

le paragraphe 2.5.7 les propositions qui ont ´et´e faites pour le choix du serveur de QoS. Nous avons choisi celui bas´e sur le protocole COPS-DRA parce que, d’une part il est d´edi´e aux architectures de QoS impl´ementant DiffServ, et d’autre part parce que le nombre de messages ´echang´es est plus faible que pour les autres solutions (qui augmentent la dur´ee n´ecessaire `a l’´etablissement de la session de QoS).

En effet, les modifications apport´ees au proxy SIP touchent les fonctions qui permettent la mise en place de la reservation des ressources garantissant une QoS appropri´ee au pr´ealable de l’ouverture de la session SIP, ceci en introduisant une pr´econdition de type reservation de resource via un module qui r´ealise les proc´edure de r´eservation et de lib´eration de ressources en ´echangeant des messages Request (RQT), D´ecision (DEC), Report (RPT) avec le serveur QoS, et un module d’extraction et d’analyse de descripteur de session SDP.

De plus, une fois les caract´eristiques de la session QoS (@IP, N˚ ports, attributs QoS DDS, descripteur champ DSCP, descripteur du media, etc. illustr´e dans le Tableau 5.5) d´eduites des descripteurs de session SDP, chaque proxy SIP se charge de communiquer ces informations `a son serveur de QoS le plus proche. Chaque fois que le serveur de QoS re¸coit une requˆete de r´eservation/lib´eration en provenance du proxy SIP, il compare les adresses source et destination et le num´ero du port du flux concern´e contenu dans le message de r´eservation/lib´eration avec les adresses enregistr´ees dans sa base. Si ces adresses correspondent, il pr´evient le proxy SIP de la r´eservation/lib´eration des ressources par un message RESV/FREE en indiquant les param`etres correspondant aux flux et le service auquel le flux doit ˆetre associ´e, ainsi que le d´ebit que nous l’avons d´ecrit dans le paragraphe 5.2.2.1.

5.2.3.3 Configuration de la QoS au niveau routeurs

Pour la configuration de la QoS au niveau IP, lorsque le serveur de QoS re¸coit une requˆete de r´eservation, il doit modifier les param`etres des diff´erentes files d’attentes du routeur de sortie pour configurer le d´ebit n´ecessaire pour l’application.

Cependant, nous ne disposons pas des informations `a partir de l’application DDS ou de l’in- terface du service networking de DDS concernant le taux de perte des paquets et la gigue maximale admissible. L’approche suivie est alors de favoriser le traitement des donn´ees ayant des exigences les plus strictes au niveau des routeurs. Ainsi, pour la mise en oeuvre de la QoS au niveau IP, nous utilisons 3 cat´egories DiffServ principales, dont une EF et une AF avec deux sous-cat´egories.

La classification des paquets permet d’organiser les ´el´ements du r´eseau en plusieurs flux de trafic et de mettre les politiques en application selon le champ de QoS de couche 3. Le rou- teur commence par identifier les flux de trafic ou les groupes de paquets. Il classifie ensuite ou reclassifie ces groupe `a l’aide du champ DSCP. Pour cela, 4 classes de trafic sont identifi´ees `a la base des concepts retenus dans la mise en place de la communication DDS sur des r´eseaux locaux. Ces diff´erentes classes de trafic sont identifi´ees dans le Tableau 5.6.

– Pour les Topics p´eriodiques, nous avons allou´e le service du PHB-EF,

– Les Topics ”State” et ”Contrˆole” ont des contraintes temps-r´eel plus lˆaches, auxquelles nous avons associ´e le traitement AF3.

– Les Topics multim´edia ne n´ecessitant pas un service temps-r´eel dur, nous leur avons attribu´e le traitement AF1.

– Le trafic du Build-in Topic ne n´ecessitant aucun traitement particulier, nous lui avons attribu´e la valeur DSCP 0.

Topics DDS PHB classe de trafic probabilit´e de DSCP suppression Binaire D´ecimal P´eriodiques EF RT 101110 46 State et Controle AF3 NRT1 Low 010100 28 MultimediaMedia AF2 NRT2 Medium 001100 20 Build-in Topic BE STD High 000000 0

Table 5.6: Correspondance entre les Topics DDS, les classes de trafic et leurs valeurs DSCP

Figure 5.2: Enregistrement initi´e par le Proxy SIP am´elior´e local