La QoS dans le projet SATSIX

Dans le cadre du projet SATSIX [138], l’architecture DiffServ a aussi été choisie au niveau IP, d’une part pour rester en accord avec les recommandations du groupe SatLabs mais aussi pour ses capacités de passage à l’échelle. Trois catégories sont alors utilisées : une classe EF, une classe AF divisée en 3 sous classes (AF31, AF32 et AF33) et une classe BE.

Pour ce qui est de la QoS niveau MAC, trois classes de trafic sont utilisées : DVB-RT pour le trafic temps réel, DVB-nRT pour le trafic prioritaire non temps réel et BE pour le reste,

79 chacune de ces classes étant associée à un canal logique spécifique. On peut voir sur la Figure 29 qu’une fois classifiés, les paquets IP passent par le module SAR (Segmentation and Reassembly) où ils sont segmentés en paquets MPEG2-TS ou en cellules ATM pour ensuite être répartis entre les deux classes de niveau MAC. La classe EF est mappée sur la file DVB- RT qui utilise prioritairement l’allocation statiquement allouée au logon du ST ainsi que des requêtes de capacité de type RBDC (mais on verra que certains mécanismes peuvent permettre l’utilisation de CRA), les classes AF sont mappées sur la file DVB-nRT correspondant aussi à des requêtes de type RBDC tandis que la classe BE est mappée sur la file MAC BE associée, a priori, à des requêtes de type RBDC ou VBDC. Cependant, ces associations entre file MAC et requête de capacité sont totalement configurables et peuvent être modifiées à souhait. De plus, les files nRT et BE peuvent bien sûr utiliser les timeslots alloués statiquement lorsque la file RT est vide. Finalement les paquets MPEG2-TS (ou cellules ATM) sont encapsulés dans des trames DVB-RCS envoyées sur le lien satellite.

Figure 29 – Architecture de QoS SATSIX d’un ST

80 Le client DAMA, localisé au niveau de la couche MAC du ST, est en charge de contrôler l’accès au lien satellite en communiquant avec les autres ST ainsi qu’avec le NCC. Il reçoit aussi des mesures concernant la taille des files MAC et du taux de paquet les traversant.

Pour éviter que les files de niveau MAC débordent, des mécanismes d’interaction MAC/IP ont aussi été mis en place dans le cadre du projet. Par exemple, lorsque la file BE (au niveau MAC) dépasse un seuil fixé (correspondant au threshold indiqué sur la Figure 29) un algorithme de « backpressure » permet ainsi d’empêcher le module d’ordonnancement (scheduling) de continuer à alimenter la file. Le seuil peut être défini en fonction de l’algorithme d’allocation de bande passante à la demande.

Comparée à une architecture « traditionnelle » dans laquelle les paquets IP, après avoir été régulés, sont placés dans des buffers correspondant à différentes classes de trafic, segmentés en paquets MPEG2-TS, mappés vers des classes de niveau MAC, puis re-régulés et finalement réordonnancés, l’architecture proposée offre plusieurs avantages : 1) d’une part, cela évite la duplication des procédures d’ordonnancement, de mise en forme et d’application des politiques réalisées aux niveaux MAC et IP ; 2) ensuite, cela évite des débordements au niveau des files MAC qui impliquent une transmission partielle des paquets IP, ce qui cause un gaspillage de ressources ; 3) lorsqu’une congestion a lieu, les paquets s’accumulent dans les files IP et lorsque la congestion se termine, l’ordonnanceur est capable d’utiliser tous les critères de discrimination qui y ont été configurés, sélectionnant ainsi les paquets IP ayant les plus fortes exigences de délai.

Pour la configuration de la QoS, différents outils, initialement introduits dans le cadre du projet SATIP6 [139] ont été aussi la base de différentes améliorations et développements que j’ai réalisé, notamment pour le projet SATSIX. Ces outils, décrits dans [140], sont les suivants :

• Le QoS Server, un outil localisé au niveau de chaque ST/GW qui collecte des informations identifiant un flux, lui permettant ainsi de le rederiger dans une file DiffServ spécifique.

• Le QoS Agent, un outil localisé au niveau d’un terminal utilisateur et permettant à ce dernier d’indiquer dans un message de type RESV au QoS Server dans quelle classe de service il souhaite qu’un flux soit redirigé.

• L’idée de faire communiquer un proxy SIP avec le QoS Server avait été précédemment introduite et développée pour automatiser la configuration de la QoS mais uniquement pour la redirection d’un flux vers la file désirée dans le cas des applications SIP.

Cependant, pour une configuration plus fine de la QoS, même s’il est nécessaire de pouvoir rediriger des flux dans différentes classes de service en fonction des exigences de QoS qui leurs sont propres, il est aussi indispensable de mettre en place d’autres mécanismes permettant de quantifier précisemment les ressources qui vont être consommées par les flux pour lesquels on veut effectuer une réservation et configurer ainsi les différents élements du système satellite après avoir vérifié que ces ressources sont effectivement disponibles. Nous allons donc présenter nos propositions d’architecture pour la gestion de la QoS dans le paragraphe suivant.

81