Le modèle IntServ

II.2.1.1. Principes de base

Les travaux du groupe de travail IntServ ont abouti en 1994 à la définition d’une

architecture de services intégrés [94] composée essentiellement de deux éléments : un modèle

de service étendu, appelé modèle IS et un cadre d’implémentation de référence permettant la

mise en œuvre de ce modèle.

55

Cette architecture, permettant de prendre en charge la QoS sans modifier le protocole IP,

se base sur une réservation de ressource par flux. Chaque routeur doit alors conserver l’état

des flux qui le traversent, ce qui modifie fondamentalement le fonctionnement de l’Internet,

qui, au contraire, se basait jusqu’à présent sur une conservation de l’état des flux au niveau

des terminaux utilisateurs. Les routeurs se voient alors ajouter 4 fonctionnalités

supplémentaires :

• L’ordonnanceur de paquet, en charge de l’acheminement des différents flux de

paquets, utilisant un ensemble de files ainsi que d’autres mécanismes tels que les

timers.

• Le classifieur qui réalise la correspondance entre un paquet entrant et la classe de

service à laquelle il est associé. Le niveau de QoS fourni par chaque classe de service

est programmable pour chaque flux.

• Le contrôle d’admission qui implémente l’algorithme de décision que le routeur

utilise pour déterminer si un nouveau flux peut ou non obtenir la QoS demandée sans

dégrader les garanties précédemment offertes.

• Le protocole d’établissement de réservation, nécessaire pour créer et maintenir

l’état des flux au niveau des routeurs. Le protocole choisi pour réaliser cette fonction

est RSVP (ReSerVation Protocol), défini un peu plus tard comme Resource

reSerVation Protocol dans [95].

Deux nouvelles classes de service sont alors définies en plus du best-effort qui ne reçoit

aucun traitement spécifique au niveau des routeurs :

• Le service garanti (GS, Guaranteed Service) [96] permet d’obtenir des garanties en

termes de bande passante et de délai maximal d’acheminement des paquets,

exprimables quantitativement. Si le flux respecte les paramètres réservés, ce service

garantit que tous les paquets arriveront avec un délai maximal et qu’ils ne seront pas

perdus dans les files d’attente en cas de congestion. Ce service se prête à des

applications temps réel ayant de fortes contraintes de délai telles que les applications

de vidéoconférence ou de VoIP. Cependant, aucun délai moyen n’est garanti, c’est

donc à l’application elle-même de gérer au niveau du récepteur les variations de ce

délai en utilisant des mécanismes de bufferisation.

• Le service de contrôle de charge (CL, Controlled-Load) [97] est un service

exprimable qualitativement en termes de bande passante qui assure à l’utilisateur que

son flux de données sera transmis avec une QoS proche de celle d’un réseau non

surchargé (non congestionné).

Les garanties sont obtenues de bout-en-bout par la concaténation de ces garanties offertes

séparément par chaque routeur traversé le long du chemin. De plus, comme on l’a précisé

précédemment, le protocole permettant de configurer ces routeurs est RSVP.

II.2.1.2. Le protocole RSVP

Dans cette partie, nous précisons le principe de fonctionnement du protocole de

réservation de ressource RSVP.

56

Dans un premier temps, un message PATH est propagé depuis l’émetteur (application

émettrice) vers le récepteur. Ce message contient la spécification du trafic (TSPEC) qui sera

généré par l’application. Cette spécification ne peut être modifiée tout au long du chemin ; par

contre, d’autres informations peuvent être ajoutées par l’intermédiaire de spécification

additionnelle (ADSPEC) pour préciser des contraintes de ressources spécifiques. Une fois le

message arrivé à destination, le récepteur répond par un message RESV qui contient la

description du flux de trafic auquel la réservation de ressource doit s’appliquer (Receiver

TSPEC) ainsi que les paramètres requis pour mettre en œuvre le service demandé (RSPEC).

Ces descriptions peuvent aussi changer en cours de chemin.

Les messages RESV doivent suivre le chemin inverse des messages PATH et déclenchent

la réservation effective des ressources (état à mémoriser au niveau de chaque routeur) si les

mécanismes de contrôle d’admission de chaque routeur valident la requête. Si un routeur

valide la requête, il crée et maintient un état correspondant à ce flux. Cependant, la durée de

vie des réservations est limitée et les messages PATH/RESV doivent être périodiquement

échangés pour que la réservation reste valable. Cela permet d’être robuste aux changements

de routage entre autres.

Une fois la QoS configurée, lorsqu’un flux ayant fait l’objet d’une réservation traverse un

routeur, il est identifié par son quintuplet {Adresse IP source, Adresse IP destination,

Protocole, Port TCP/UDP source, Port TCP/UDP destination} par le classifieur.

L’ordonnanceur s’occupe ensuite de la gestion des files.

Pour permettre la libération de ressource lorsqu’une application se termine, les messages

« PathTear » et « ResvTear » sont respectivement envoyés pour indiquer aux routeurs de

supprimer les états concernant la route et les états de réservation. D’autre part, des messages

d’erreur, PathErr et ResvErr, indiquent des erreurs concernant respectivement le chemin et la

demande de réservation et, enfin, le message ResvConf est envoyé par le dernier routeur

recevant le message RESV pour confirmer au récepteur que la réservation a bien eu lieu.

II.2.1.3. Conclusion sur RSVP et le modèle IntServ

Le protocole RSVP est donc un protocole de signalisation qui permet de réserver

dynamiquement de la bande passante et de garantir un délai maximal, et cela de bout en bout.

Cette réservation, initiée par le récepteur, permet d’éviter que certaines applications

émettrices monopolisent des ressources inutilement et permet dans le cas de communication

multicast de différencier la réservation (et donc la facturation) par récepteur. De plus, son

fonctionnement dynamique permet de s’adapter aux évolutions des communications

(changement du nombre de participants, changements de route, etc.). Enfin, ce protocole

présente aussi l’avantage de pouvoir s’adapter aussi bien à IPv4 qu’à IPv6 et passe de façon

transparente les routeurs non RSVP.

Cependant, RSVP oblige à maintenir des informations d’état pour chaque flux au niveau

de chaque nœud ou routeur le long d’un chemin reliant un émetteur à son récepteur. Donc,

lorsque le nombre d’usagers et de flux augmente, le nombre d’états devient conséquent et le

trafic est d’autant plus saturé que les rafraichissements de RSVP entre routeurs deviennent

importants et créent de l’overhead. Le principal défaut du modèle IntServ et du protocole

associé RSVP reste donc leur manque d’adaptation au facteur d’échelle, d’autant plus que la

57

réservation dans RSVP est unidirectionnelle. Donc, pour une application bidirectionnelle

nécessitant de la QoS dans les deux sens, la quantité de messages est deux fois plus élevée. Le

modèle IntServ/RSVP est donc plus adapté à des réseaux de petites tailles, tels que les réseaux

locaux (LAN).

C’est pour cette raison notamment qu’un autre modèle d’architecture a été proposé :

l’architecture DiffServ.

Dans le document Architectures pour la mobilité et la qualité de service dans les systèmes satellites DVB-S2/RCS (Page 74-77)