30/9/2014 Le protocoles RSVP

IntServ et RSVP (8/12/01)

Quelle est la problématique ?

Que désigne le modèle IntServ ?
Quelles sont les fonctions de RSVP ?
Comment fonctionne RSVP ?
Quels sont les limitations de RSVP ?
Comment faire corresponbdre la QoS de niveau IP avec la QoS de niveau lien ?
Quels sont les documents relatifs à RSVP ?

Quelle est la problématique ?

Les protocoles RTP/RTCP permettent de régler les problèmes aux extrémités. Ce sont des protocoles de bout
en bout comme TCP qui ne traitent pas les problèmes liés à l'augmentation du trafic et au comportement des
routeurs pour la résolution de cette congestion.

En effet, pour IP 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.

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é.

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 raffraî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 ( NE: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;

IntServ définit deux types de services:

- Guaranteed Service (GS) 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é.
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 1/7
30/9/2014 Le protocoles RSVP

"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.)

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.

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​

http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 2/7
30/9/2014 Le protocoles RSVP

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.

Comparaison X.25 - RSVP

X.25 RSVP
Circuit virtuel établi lors de la phase d'appel et Protocoles de routage pouvant faire
Chemin libéré à la fin. Les paquets après le paquet d'appel varier le chemin emprunté et nuire au
ne contient pas les @ source et destination protocole de réservation
Beaucoup d'états maintenus durant toute la Etats transitoires nécessitant un
Etats communication (numéro de CV, ressources par flot, raffraîchissement périodique. Génération
échange d'acquittements, compteurs...) de trafic du à ces raffraîchissements.
Acquittements
Oui. Perte de paquets détectés. Non. Pas de connexion.
entre noeuds
Contrôle de Non. Seul un contrôle d'admission est
Oui. Crédits, fenêtres.
flux prévu.

Comment fonctionne RSVP ?

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;
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);

http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 3/7
30/9/2014 Le protocoles RSVP

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.

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

Fonctionnement de RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 4/7
30/9/2014 Le protocoles RSVP

1) Le récepteur envoie la requête de QoS au démon RSVP local

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
rafraichissement le long du chemin.
En l'absence de messages de rafraichissement, le cache relatif a une réservation est détruit.

http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 5/7
30/9/2014 Le protocoles RSVP

Quels sont les limitations de RSVP ?

RSVP oblige à maintenir l'état d'un flot. Lorsque le nombre d'usagers augmente (scalability), le nombre d'états
devient conséquent avec le trafic généré pour les raffraîchissements. Cela nuit aux performances du système
dans son ensemble. C'est pourquoi RSVP est plus adapté à des réseaux de petite taille comme les LAN.

RSVP ne s'applique pas au dernier Km puisqu'il n'est pas possible de contrôler la gestion des files d'attente sur
les équipements de la couche liaison avec les réseaux locaux.

Les opérateurs préfèrent augmenter les ressources que de réserver les ressources vu la complexité du système
sans oublier que la démarche de réservation des ressources est inégalitaire puisqu'elle favorise les
consommateurs payants.

Enfin, d'autres architectures reposant sur l'étiquettage de priorité dans les paquets et la classification des
services sont plus simples à mettre en oeuvre. Paradoxalement, ces architectures qui peuvent paraître comme
concurrents de RSVP peuvent être ses alliés en allégeant au maximum la tâche de maintien d'états, de
raffraîchissements et de classification.

Comment faire correspondre la QOS de niveau IP avec la 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.

Le groupe de travail IISL (Integrated Services over Specific Link Layers) a pour but d'établir les
correspondances entre IntServ et les technologies des liens réseau sous-jacents.

IntServ a été spécifié pour les technologies suivantes:

liens réseau à bas débit :

RFC 2686: The Multi-Class Extension to Multi-Link PPP. C. Bormann. September 1999.

RFC 2687: PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. September 1999.

RFC 2688: Integrated Services Mappings for Low Speed Networks. S.Jackowski, D. Putzolu, E.
Crawley, B. Davie. September 1999.

RFC 2689: Providing Integrated Services over Low-bitrate Links. C. Bormann. September 1999.

ATM

http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 6/7
30/9/2014 Le protocoles RSVP

RFC 2379: RSVP over ATM Implementation Guidelines. L. Berger. August 1998.

RFC 2380: RSVP over ATM Implementation Requirements. L. Berger. August 1998.

RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM. M. Garrett, M.
Borden. August 1998.

RFC 2382: A Framework for Integrated Services and RSVP over ATM. E.Crawley, L. Berger, S.
Berson, F. Baker, M. Borden, J. Krawczyk.
August 1998.

Réseaux locaux IEEE 802

RFC 2814: SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over
IEEE 802-style networks. R. Yavatkar, D.
Hoffman, Y. Bernet, F. Baker, M. Speer. May 2000.

RFC 2815: Integrated Service Mappings on IEEE 802 Networks. M. Seaman, A.Smith, E. Crawley, J.
Wroclawski. May 2000.

RFC 2816: A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN
Technologies. A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. May 2000.

Quels sont les documents relatifs à IntServ et RSVP ?

Integrated Services Management Information Base using SMIv2 (RFC 2213)

Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 (RFC 2214)
General Characterization Parameters for Integrated Service Network Elements (RFC 2215)
Network Element Service Specification Template (RFC 2216)
The Use of RSVP with IETF Integrated Services (RFC 2210)
Specification of the Controlled-Load Network Element Service (RFC 2211)
Specification of Guaranteed Quality of Service (RFC 2212)
Integrated Services in the Presence of Compressible Flows (RFC 3006)

Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification (RFC 2205)

RSVP Management Information Base using SMIv2 (RFC 2206)
RSVP Extensions for IPSEC Data Flows (RFC 2207)
Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment
(RFC 2208)
Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules (RFC 2209)
RSVP Diagnostic Messages (RFC 2745)
RSVP Operation Over IP Tunnels (RFC 2746)
RSVP Cryptographic Authentication (RFC 2747)
RSVP Cryptographic Authentication-New Message Type (RFC 3097)
RSVP Refresh Overhead Reduction Extensions (RFC 2961)

RFC 3175: Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C.Iturralde, F. Le Faucheur, B.
Davie. September 2001.
RFC 3182: Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S.
Herzog, R. Hess. October 2001.

Tous droits réservés

© 2001 Université Paul Sabatier (Toulouse III)
HTTR André Aoun

http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 7/7