Christophe Benoit
Rauch Jérome
Morgado Gonçalves Nuno
ESIAL 3A – TRS
La qualité de service dans
l’Internet
IntServ et RSVP
Sommaire
I) PROBLEMATIQUE DE LA QUALITE DE SERVICES 2
1) INTRODUCTION 2
2) HISTORIQUE 2
II) DESCRIPTION RAPIDE DU MODELE INTSERV / RSVP 4
1) DESCRIPTION 4
2) QUE DESIGNE LE MODELE INTSERV ? 4
III) QUELLES SONT LES FONCTIONS DE RSVP ? 5
IV) FONCTIONNEMENT DE RSVP 7
1) TYPES DE MESSAGES 7
2) FONCTIONNEMENT DE RSVP 9
V) LIMITATIONS ET DEVELOPPEMENT DE QOS SUR COUCHE LIAISON 14
1) LES LIMITATIONS DU PROTOCOLE RSVP 14
2) CORRESPONDANCE QOS DE NIVEAU IP QOS DE NIVEAU LIEN 14
2.1) RSVP SUR ATM 14
VI) CONCLUSION 15
1
I) Problématique de la qualité de services
1) Introduction
À ses débuts, Internet avait pour seul objectif de transmettre les paquets à leur destination.
Conçu pour le transport asynchrone des données, IP (Internet Protocol) n'a pas été prévu pour
les applications en temps réel comme la téléphonie ou la vidéo, très contraignantes. Les
paquets sont tous traités de la même façon sans aucun différenciation. Ainsi, un flux temps
réel (comme le streaming vidéo) et la messagerie sont traités avec le même service: "Best
Effort". Ils sont stockés dans la file d'attente selon le principe FIFO (First In First Out). C'est
pourquoi le temps de transmission peut être long et surtout il n'est pas constant d'où
l'apparition de Gigue, phénomène auquel la transmission multimédia et en particulier la
transmission audio est très sensible.
Le besoin en équipements de plus en plus fiables, d'un bout à l'autre du réseau, est donc
devenu incontournable. Cependant, les défauts rencontrés sur les réseaux (perte de paquets,
congestion) ne peuvent pas être surmontés sans une rénovation profonde de l'architecture.
Afin de garantir cette qualité de service, trois protocoles se sont imposés : Intserv (Integrated
Service, protocole inclus dans RSVP, Ressource Reservation Protocol), Diffserv
(Differentiated Services) et MPLS (MultiProtocol Label Switching). Leur standardisation est
effectuée par l'IETF (Internet Engineering Task Force). Le premier, Intserv, repose sur un
mécanisme de réservation des ressources. Dans la pratique, il dédie une partie de la bande
passante pour assurer l'acheminement des messages prioritaires.
Depuis 1989, des propositions ont été faites au sein de l'IETF ("Integrated Services
Architecture - INTSERV WG") pour offrir une qualité de service adaptée aux besoins de
l'application. Le protocole RSVP (Resource ReSerVation Protocol) a été adopté.
2) Historique
Court Historique de la QOS
1976 : recherches préliminaires sur Arpanet
Le Department of Defense américain décide de migrer le réseau
Arpanet, ancêtre d'Internet, vers TCP/IP, et teste les premiers
mécanismes de qualité de service sur le réseau.
1995 : création du protocole RSVP
Développement et mise au point de RSVP (dont Intserv fait partie),
projet conduit par Xerox PARC, le MIT ainsi que l'Information
Sciences Institute et le Computer Science Department, deux entités de
l'université de Californie.
1997 : Diffserv comble les lacunes de l'architecture IP
2
Le groupe de travail Diffserv au sein de l'IETF revisite l'entête du
paquet IPv4 et réutilise le champ dédié à la qualification des flux
transportés.
1998 : MPLS rénove l'approche de la QoS
Poussés par Cisco, les équipementiers et opérateurs se rallient au sein
de l'IETF pour standardiser la procédure de routage MPLS. À ce sujet,
de nombreux travaux sont encore en cours.
3
II) Description rapide du modèle Intserv / RSVP
1) Description
Le but du groupe de travail Intserv de l'IETF est la transformation de l'Internet actuel en un
réseau à intégration de services.
L'architecture Intserv s'organise autour du concept de flot de données correspondant à un
ensemble de paquets résultant d'une application utilisatrice et ayant un besoin d'une certaine
QoS. Afin de satisfaire la QoS requise, Intserv propose d'effectuer une réservation des
ressources nécessaires à l'établissement de celle-ci via le protocole de réservation de
ressources nommé RSVP. Le signal RSVP étant constitué par l'information de contrôle de la
QoS, celui-ci propose des directives afin de mettre en place la réservation mais ne dit pas
comment la mettre en place, ce domaine étant réservé aux routeurs du réseau qui prennent en
compte la signalisation RSVP. Pour se faire, les routeurs disposent de quatre fonctions de
contrôle du trafic :
1. Le protocole de réservation de ressource : qui, de façon implicite, signalise le chemin
à établir en sollicitant des réservations de bande passante sur chaque routeurs traversés
du réseau.
2. Le contrôle d'admission : permet d'autoriser l'arrivée d'un nouveau flot muni de sa
QoS sans perturber les QoS des autres flots existant.
3. Les classifieurs de paquets : qui classent les paquets de flots admis dans les classes
spécifiques.
4. L'ordonnanceur de paquets : qui détermine l'ordre de service des paquets.
Ainsi RSVP va maintenir un chemin dynamique à l'intérieur du réseau, dynamique car
rafraîchit par des messages periodiques stipulant l'état du chemin au travers des routeurs.
2) Que désigne le modèle IntServ ?
Le modèle IntServ définit une architecture capable de prendre en charge la QoS en définissant
des mécanismes de contrôle complémentaires sans toucher au fonctionnement IP. C'est un
modèle basé sur un protocole de signalisation RSVP. Dans le modèle, les routeurs réservent
les ressources pour un flot de données spécifiques en mémorisant des informations d'état. Il
est important de rafraîchir périodiquement les informations au cas où il y a eu changement
de la route emprunté par le flot. En effet, il est inutile de continuer à réserver les ressources
sur un routeur qui ne fait plus partie du chemin emprunté.
IntServ a défini trois types d'éléments réseau (Network Elements) :
- QoS-capable NE offrant un ou pkusieurs services IntServ
- QoS-aware NE ayant les interfaces nécessaires pour réaliser des services qui ne sont
pas IntServ mais qui sont équivalents
- non-QoS-NE ne supportant pas les fonctionnalités IntServ
4
IntServ définit deux types de services:
- Guaranteed Service qui garantit la bande passante et un délai d'acheminement limité.
"Guaranteed service guarantees that datagrams will arrive within the guaranteed delivery
time and will not be discarded due to queue overflows, provided the flow's traffic stays within
its specified traffic parameters. This service is intended for applications which need a firm
guarantee that a datagram will arrive no later than a certain time after it was transmitted by
its source. For example, some audio and video "play-back" applications are intolerant of any
datagram arriving after their play-back time. Applications that have hard real-time
requirements will also require guaranteed service. This service does not attempt to minimize
the jitter (the difference between the minimal and maximal datagram delays)"
- Controlled Load qui est équivalent à un service Best Effort dans un environnement non
surchargé.
"Assuming the network is functioning correctly, these applications may assume that: A very
high percentage of transmitted packets will be successfully delivered by the network to the
receiving end-nodes.(The percentage of packets not successfully delivered must closely
approximate the basic packet error rate of the transmission medium).* The transit delay
experienced by a very high percentage of the delivered packets will not greatly exceed the
minimum transmit delay experienced by any successfully delivered packet. (This minimum
transit delay includes speed-of-light delay plus the fixed processing time in routers and other
communications devices along the path.)
III) Quelles sont les fonctions de RSVP ?
RSVP est un protocole de signalisation pour allouer dynamiquement de la bande
passante aux applications orientées réseaux dans des environnements traditionnellement
datagramme. Il est particulièrement utile pour les applications multimédias de type CBR.
RSVP est utilisé dans le modèle IntServ mais il peut être utilisé hors de ce contexte (par
exemple pour établir des chemins MPLS).
RSVP rend obligatoire la demande de QoS par le récepteur (l'application participante) plutôt
que par l'émetteur (l'application source). Le récepteur apprend les spécifications du flux
multimédia par un mécanisme hors-bande. Le récepteur peut ainsi faire les réservations qui lui
sont appropriées. Cela est très utile dans le cas d'une transmission multicast. En effet, dans le
cas où on aurait prévu que la demande de ressources soit faite par l'émetteur, une QoS
identique à tous les émetteurs aurait été mise en oeuvre et n'aurait pas été adaptée aux besoins
du récepteur. D'autre part, certains émetteurs auraient eu tendance à toujours demander la
réservation la plus importante qui aurait nui au système dans sa globalité. Le fait que le
récepteur décide des ressources dont il a besoin permet une facturation différenciée par
récepteur.
5
Réservation de ressources dans un flux multicast
Fusion des messages Resv
Les équipements d'interconnexions (routeurs), sur le chemin du flot des données, répondent
aux requêtes RSVP , établissent et maintiennent les connexions. Les routeurs communiquent
via RSVP pour initialiser et gérer la QoS réservée aux sessions.
RSVP travaille au dessus de IP (IPv4 ou IPv6) et occupe la place d'un protocole de transport
dans la pile des protocoles mais ne transporte pas de données utilisateurs (Protocole
#46)comme ICMP ou IGMP. Dans les cas où le système ne permet pas l'utilisation de services
réseau directement ("raw"), RSVP est encapsulé dans des paquets UDP. RSVP passe de façon
transparente les routeurs non RSVP.
RSVP n'est pas un protocole de routage. Il est censé travailler avec les protocoles de routage
unicast et multicast
RSVP fait des réservation de ressources pour les applications unicast et multicast et s'adapte
dynamiquement aux évolutions (participants, changements de routes). Il demande des
ressources dans une seule direction et traite l'émetteur et le récepteur de manière différente.
Il est utilisé par un "host" pour le compte d'une application, pour demander une QoS au réseau
(bande passante garanti, débit crête,..). Il est utilisé par les routeurs pour le contrôle de la QoS
et l'établissement et maintient du service demandé.
RSVP peut être utilisée avec RTP/RTCP mais ce n'est pas obligatoire.
6
Comparaison X.25 - RSVP
X.25 RSVP
Circuit virtuel établi lors de la phase
Protocoles de routage pouvant faire
d'appel et libéré à la fin. Les paquets
Chemin varier le chemin emprunté et nuire
après le paquet d'appel ne contient pas
au protocole de réservation
les @ source et destination
Beaucoup d'états maintenus durant Etats transitoires nécessitant un
toute la communication (numéro de raffraîchissement périodique.
Etats
CV, ressources par flot, échange Génération de trafic du à ces
d'acquittements, compteurs...) raffraîchissements.
Acquittements
Oui. Perte de paquets détectés. Non. Pas de connexion.
entre noeuds
Non. Seul un contrôle d'admission
Contrôle de flux Oui. Crédits, fenêtres.
est prévu.
IV) Fonctionnement de RSVP
1) Types de messages
Sept Types de Messages RSVP ont été prévus:
Path: envoyé par la source pour indiquer la liste des routeurs du chemin suivi par les données;
Resv: demande de réservation;
PathErr: message d'erreur concernant le chemin;
ResvErr: message d'erreur de demande de réservation;
7
PathTear: indique aux routeurs d'annuler les états concernant la route;
ResvTear: indique aux routeurs d'annuler les états de réservation (fin de session);
ResvConf (optionnel): message de confirmation envoyé par le routeur au demandeur de la réservation;
Un message RSVP est constitué d'une en-tête et d'un nombre variable d'objets qui dépend du type du message.
L'entête est constitué de 64 bits:
Vers Flags Type du Msg Checksum
Send_TTL Réservé Longueur Msg.
Vers (4 bits): version du protocole RSVP (=1);
Flags (4): non utilisé à ce jour;
Type de Msg (8): 1 à 7 selon le type ci-dessus;
Checksum (16): Contrôle d'erreurs;
Send_TTL (8): valeur du TTL IP à comparer avec le TTL du paquet IP pour savoir s'il y a des routeurs
non-RSVP;
Longueur (16): longeur du mesage en octets (en-tête et objets)
RSVP fonctionne en mode non connecté avec les routeurs. Les systèmes terminaux sont en
mode connecté.
Session = flot de données avec une destination particulière et un protocole de transport
DestAdress: groupe d'adresses Ip pour le multicast, adresse unicast pour un destinataire unique
ProtocolId : protocole de transport
DestPort : port UDP/TCP
Pour déterminer le chemin qui sera emprunté par la requête (Resv), l'émetteur envoie un
message Path qui de hop en hop dresse la liste des routeurs qui seront empruntés par les
messages RSVP de demande de réservation.
Pour avoir une vision globale des capacités des routeurs empruntés, un mécanisme a été prévu
connu sous le nom d'OPWA (One Pass With Advertising): des messages de contrôle sont
émis par la source qui récoltent un certain nombre d'informations au niveau des routeurs à
destination des récepteurs. Cela permet à ces derniers d'ajuster leurs demandes en fonction des
possibilités offertes par le réseau.
Dans le cas de flux multicast, les messges Resv sont fusionnés au niveau des points de
réplication. Le FlowSpec le plus important est utilisé. Ainsi, deux demandes de 25 Mbps et de
10 Mbps donne une demande de 25 Mbps.
8
Une requête élémentaire de réservation Resv
requête de QoS: FlowSpec - positionne les paramètres du packet scheduler -classe de
service (Garanteed Service ou Controlled Load Service) + 2 jeux de paramètres
numériques (Average Rate, Burst rate)
indication de sélection: Filter Spec - positionne les paramètres du packet classifier -
dans la version actuelle : @IP émetteur, port UDP/TCP
La paire FlowSpec et FilterSpec est nommée FlowDescriptor
ex.
Garanteed Service 100 kbps Avg. Rate 300 kbps Burst Rate 130.120.84.34 3265
Styles de Réservation
La séparation entre la description d'une ressource réservée (FlowSpec) et à qui elle est
réservée (FilterSpec) permet d'établir des styles de réservation.
"reservation style" = jeu d'options inclus dans la requête de réservation de ressources
Quelle réservation pour différents émetteurs dans la même session ?
- réservation distincte pour chaque émetteur.
- réservation partagée(shared) par tous les paquets des émetteurs.
sélection des émetteurs
- liste explicite
- sélection implicite de tous : wildcard
2) Fonctionnement de RSVP
9
10
11
1) Le récepteur envoie la requête de QoS au démon RSVP local
12
2) La requête Qos est passée à 2 modules de décision:
Admission Control : qui détermine si les ressources sont suffisantes en fonction de la
requête (débit, taux de pertes...)
Policy Control : qui vérifie que l'utilisateur a l'autorisation administrative de faire cette
réservation. Il authentifie le demandeur et pemret la facturation.
Si un des modules a une réponse négative alors envoie d'une notification d'erreur au
demandeur
3) Envoie des paramètres de QoS aux deux modules de gestion de flots: Packet Classifier et
Packet Scheduler
Le packet Classifier trie les paquets. Il détermine la route et la classe de QoS pour
chaque paquet entrant
Le Packet Scheduler prend la décision de transmettre chaque paquet en choisissant sa
place dans la file d'attente correspondant au service demandé. Il peut demander une
allocation supplémentaire du temps CPU ou une augmentation de la taille de mémoire
tampon dans le routeur...
4) Le scénario se reproduit pour le "hop" suivant
Un cache pour le contrôle du trafic est construit dans chaque routeur. Pour répondre aux
modifications des sessions multicast par exemple, RSVP envoie des messages de
rafraîchissement le long du chemin.
En l'absence de messages de rafraichissement, le cache relatif a une réservation est détruit.
13
V) Limitations et développement de QoS sur couche liaison
1) Les limitations du protocole RSVP
Le protocole RSVP est obligé de maintenir l'état d'un flot. En effet, dès l'ouverture d'une
session, un chemin est établi grâce à l' "Admission Controller". Ce chemin doit rester le même
tant que la session est utilisée.
Le nombre d'états à maintenir devient donc vite très conséquent ce qui dégrade les
performances du réseau lorsque l'on doit rafraîchir les états ( les routes mise en place pour une
session sont elles toujours utilisées ?).
Ce protocole est donc plus adapté pour de petits réseaux (LAN). De plus, RSVP fonctionne en
mode non connecté avec les routeurs. Les systèmes terminaux étant en mode connecté, il n'est
pas possible d'utiliser RSVP pour la gestion des files d'attentes sur les équipements terminaux.
Actuellement, les opérateurs préfèrent augmenter les ressources plutôt que d'utiliser un
contrôleur d'admission avec rafraîchissement des états, pour alléger la complexité du système.
2) Correspondance QoS de niveau IP QoS de niveau lien
Il est possible d'utiliser le protocole IP directement sur les réseaux fibres (IP over Sonet, IP
over SDH...) et dans ce cas, la gestion de QoS au niveau IP est indépendante de tout autre
mécanisme sous-jacent.
Mais pour l'heure actuelle, IP s'appuie sur des technologies de "bas niveau" qui intègrent pour
certaines d'entre elles une gestion de QoS.
2.1) RSVP sur ATM
La correspondance de la QoS IP – QoS Liaison, a pu être résolue d’une part en faisant de l’IP
over ATM et d’autre part en utilisant un serveur de résolution d’adresses multicast (MARS).
L’un des modèles RSVP over ATM reposant sur de l’IP over ATM, fonctionne tant que les
paquets de contrôle et de données RSVP suivent le même chemin IP à travers le réseau. Ce
qui est important, c’est que les messages RSVP PATH suivent le même chemin IP que les
données. Ainsi, l’état PATH pourra être installé dans les routeurs qui se trouvent sur la route
construite par le chemin IP.
Pour un sous réseau ATM, cela implique que les points d’entrées et de sorties soient les
mêmes dans les deux directions (Récepteur -> Emetteur et Emetteur -> Récepteur) pour des
messages de contrôle et des messages transmettant des données. L’état PATH installé par
RSVP permet aux messages « RESV » de retracer les nœuds que le message PATH a traversé.
A travers chacun des modèles IP over ATM, des décisions concernant la distribution de
certains types de données sont prises.
14
VI) Conclusion
Très complexe à mettre en oeuvre, Intserv convient plutôt aux réseaux de petites tailles, mais
n'est pas vraiment adapté à Internet dans son ensemble. De ce fait, il a été peu déployé. Pour
pallier ces carences, l'IETF a adopté un second modèle, Diffserv, qui assure une distinction
des paquets par classes de flux. Les données sont identifiées grâce à un marquage dans le
champ ToS (Type of Service, champ spécifique réservé dans l'en-tête IP de 8 bits), qui fixe les
priorités. Cette zone se décompose en un premier champ de trois bits baptisé " IP Precedence
", qui précise le niveau de priorité appliqué au paquet. Vient ensuite un champ de 4 bits, dont
la valeur détermine un critère de routage. Le dernier bit du champ reste inutilisé. Cette
classification s'opère à l'entrée du réseau étendu, déchargeant ainsi les routeurs de la tâche.
Diffserv définit quatre classes de services : Best Effort (priorité basse) ; Assured Forwarding
(AF), qui garantit la transmission des données sans tenir compte des délais ; Expedited
Forwarding (EF), correspondant à la priorité maximale, qui garantit le délai pour un trafic en
temps réel ; et Default Forwarding (DF), utilisé uniquement pour les flux Internet qui ne
nécessitent pas un trafic en temps réel. Chaque noeud du réseau apporte un traitement
différencié en fonction de la classe de service du paquet. Mais l'arrivée de MPLS a changé la
donne. Cette nouvelle architecture permet de véhiculer davantage de trafic IP à des vitesses de
transmission très élevées. Dans ce cas, les paquets transférés sont directement étiquetés (label
de 32 bits) à l'entrée du réseau, spécifiant leur chemin, ce qui évite au routeur de chercher
l'adresse à laquelle le paquet doit être envoyé. MPLS s'appuie sur les classes de service
Diffserv et fonctionne avec tout protocole existant - IP, bien sûr, mais aussi ATM et Frame
Relay -, ce qui en fait un protocole de choix, car les réseaux transportent de plus en plus de
paquets issus de diverses plates-formes.
15