30/9/2014 Le protocoles RSVP

http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 1/7
IntServ et RSVP (8/12/01)
Quelle est la problmatique ?
Que dsigne le modle 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 problmatique ?
Les protocoles RTP/RTCP permettent de rgler les problmes aux extrmits. Ce sont des protocoles de bout
en bout comme TCP qui ne traitent pas les problmes lis l'augmentation du trafic et au comportement des
routeurs pour la rsolution de cette congestion.
En effet, pour IP les paquets sont tous traits de la mme faon sans aucun diffrenciation. Ainsi, un flux
temps rel (comme le streaming vido) et la messagerie sont traits avec le mme service: "Best Effort". Ils
sont stocks 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, phnomne auquel la transmission multimdia et en particulier la transmission audio est trs sensible.
Depuis 1989, des propositions ont t faites au sein de l'IETF ("Integrated Services Architecture - INTSERV
WG") pour offrir une qualit de service adapte aux besoins de l'application. Le protocole RSVP (Resource
ReSerVation Protocol) a t adopt.
Que dsigne le modle IntServ ?
Le modle IntServ dfinit une architecture capable de prendre en charge la QoS en dfinissant des mcanismes
de contrle complmentaires sans toucher au fonctionnement IP. C'est un modle bas sur un protocole de
signalisation RSVP.
Dans le modle, les routeurs rservent les ressources pour un flot de donnes spcifiques en mmorisant des
informations d'tat. Il est important de raffrachir priodiquement les informations au cas o il y a eu
changement de la route emprunt par le flot. En effet, il est inutile de continuer rserver les ressources sur un
routeur qui ne fait plus partie du chemin emprunt.
IntServ a dfini trois types d'lments rseau ( NE:Network Elements):
- QoS-capable NE offrant un ou pkusieurs services IntServ;
- QoS-aware NE ayant les interfaces ncessaires pour raliser des services qui ne sont pas IntServ
mais qui sont quivalents;
- non-QoS-NE ne supportant pas les fonctionnalits IntServ;
IntServ dfinit deux types de services:
- Guaranteed Service (GS) qui garantit la bande passante et un dlai 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.
30/9/2014 Le protocoles RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 2/7
"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
orientes rseaux dans des environnements traditionnellement datagramme. Il est particulirement utile pour
les applications multimdias de type CBR. RSVP est utilis dans le modle 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 rcepteur (l'application participante) plutt que par
l'metteur (l'application source). Le rcepteur apprend les spcifications du flux multimdia par un mcanisme
hors-bande. Le rcepteur peut ainsi faire les rservations qui lui sont appropries. Cela est trs utile dans le
cas d'une transmission multicast. En effet, dans le cas o on aurait prvu 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 adapte
aux besoins du rcepteur. D'autre part, certains metteurs auraient eu tendance toujours demander la
rservation la plus importante qui aurait nui au systme dans sa globalit. Le fait que le rcepteur dcide des
ressources dont il a besoin permet une facturation diffrencie par rcepteur.
Les quipements d'interconnexions (routeurs), sur le chemin du flot des donnes, rpondent aux requtes
RSVP , tablissent et maintiennent les connexions. Les routeurs communiquent via RSVP pour initialiser et
grer la QoS rserve 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 donnes utilisateurs (Protocole #46)comme ICMP ou IGMP. Dans les cas
o le systme ne permet pas l'utilisation de services rseau directement ("raw"), RSVP est encapsul dans des
paquets UDP.
RSVP passe de faon 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
30/9/2014 Le protocoles RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 3/7
RSVP fait des rservation 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 rcepteur de manire diffrente.
Il est utilis par un "host" pour le compte d'une application, pour demander une QoS au rseau (bande passante
garanti, dbit crte,..).
Il est utilis par les routeurs pour le contrle de la QoS et l'tablissement et maintient du service demand.
RSVP peut tre utilise avec RTP/RTCP mais ce n'est pas obligatoire.
Comparaison X.25 - RSVP
X.25 RSVP
Chemin
Circuit virtuel tabli lors de la phase d'appel et
libr la fin. Les paquets aprs le paquet d'appel
ne contient pas les @ source et destination
Protocoles de routage pouvant faire
varier le chemin emprunt et nuire au
protocole de rservation
Etats
Beaucoup d'tats maintenus durant toute la
communication (numro de CV, ressources par flot,
change d'acquittements, compteurs...)
Etats transitoires ncessitant un
raffrachissement priodique. Gnration
de trafic du ces raffrachissements.
Acquittements
entre noeuds
Oui. Perte de paquets dtects. Non. Pas de connexion.
Contrle de
flux
Oui. Crdits, fentres.
Non. Seul un contrle d'admission est
prvu.
Comment fonctionne RSVP ?
Sept Types de Messages RSVP ont t prvus:
Path: envoy par la source pour indiquer la liste des routeurs du chemin suivi par les donnes;
Resv: demande de rservation;
PathErr: message d'erreur concernant le chemin;
ResvErr: message d'erreur de demande de rservation;
PathTear: indique aux routeurs d'annuler les tats concernant la route;
ResvTear: indique aux routeurs d'annuler les tats de rservation (fin de session);
ResvConf (optionnel): message de confirmation envoy par le routeur au demandeur de la rservation;
Un message RSVP est constitu d'une en-tte et d'un nombre variable d'objets qui dpend du type du message.
L'entte est constitu de 64 bits:
Vers Flags Type du Msg Checksum
Send_TTL Rserv Longueur Msg.
Vers (4 bits): version du protocole RSVP (=1);
30/9/2014 Le protocoles RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 4/7
Flags (4): non utilis ce jour;
Type de Msg (8): 1 7 selon le type ci-dessus;
Checksum (16): Contrle 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-tte et objets)
RSVP fonctionne en mode non connect avec les routeurs. Les systmes terminaux sont en mode connect.
Session = flot de donnes avec une destination particulire 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 dterminer le chemin qui sera emprunt par la requte (Resv), l'metteur envoie un message Path qui de
hop en hop dresse la liste des routeurs qui seront emprunts par les messages RSVP de demande de
rservation.
Pour avoir une vision globale des capacits des routeurs emprunts, un mcanisme a t prvu connu sous le
nom d'OPWA (One Pass With Advertising): des messages de contrle sont mis par la source qui rcoltent un
certain nombre d'informations au niveau des routeurs destination des rcepteurs. Cela permet ces derniers
d'ajuster leurs demandes en fonction des possibilits offertes par le rseau.
Dans le cas de flux multicast, les messges Resv sont fusionns au niveau des points de rplication. Le
FlowSpec le plus important est utilis. Ainsi, deux demandes de 25 Mbps et de 10 Mbps donne une demande
de 25 Mbps.
Une requte lmentaire de rservation Resv
requte de QoS: FlowSpec - positionne les paramtres du packet scheduler -classe de service (Garanteed
Service ou Controlled Load Service) + 2 jeux de paramtres numriques (Average Rate, Burst rate)
indication de slection: Filter Spec - positionne les paramtres du packet classifier - dans la version
actuelle : @IP metteur, port UDP/TCP
La paire FlowSpec et FilterSpec est nomme FlowDescriptor
ex.
Garanteed Service 100 kbps Avg. Rate 300 kbps Burst Rate 130.120.84.34 3265
Styles de Rservation
La sparation entre la description d'une ressource rserve (FlowSpec) et qui elle est rserve (FilterSpec)
permet d'tablir des styles de rservation.
"reservation style" = jeu d'options inclus dans la requte de rservation de ressources
Quelle rservation pour diffrents metteurs dans la mme session ?
- rservation distincte pour chaque metteur.
- rservation partage(shared) par tous les paquets des metteurs.
slection des metteurs
- liste explicite
- slection implicite de tous : wildcard
Fonctionnement de RSVP
30/9/2014 Le protocoles RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 5/7
1) Le rcepteur envoie la requte de QoS au dmon RSVP local
2) La requte Qos est passe 2 modules de dcision:
Admission Control : qui dtermine si les ressources sont suffisantes en fonction de la requte (dbit, taux
de pertes...)
Policy Control : qui vrifie que l'utilisateur a l'autorisation administrative de faire cette rservation. Il
authentifie le demandeur et pemret la facturation.
Si un des modules a une rponse ngative alors envoie d'une notification d'erreur au demandeur
3) Envoie des paramtres de QoS aux deux modules de gestion de flots: Packet Classifier et Packet Scheduler
Le packet Classifier trie les paquets. Il dtermine la route et la classe de QoS pour chaque paquet entrant
Le Packet Scheduler prend la dcision de transmettre chaque paquet en choisissant sa place dans la file
d'attente correspondant au service demand. Il peut demander une allocation supplmentaire du temps
CPU ou une augmentation de la taille de mmoire tampon dans le routeur...
4) Le scnario se reproduit pour le "hop" suivant
Un cache pour le contrle du trafic est construit dans chaque routeur.
Pour rpondre 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 rservation est dtruit.
30/9/2014 Le protocoles RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 6/7
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 consquent avec le trafic gnr pour les raffrachissements. Cela nuit aux performances du systme
dans son ensemble. C'est pourquoi RSVP est plus adapt des rseaux de petite taille comme les LAN.
RSVP ne s'applique pas au dernier Km puisqu'il n'est pas possible de contrler la gestion des files d'attente sur
les quipements de la couche liaison avec les rseaux locaux.
Les oprateurs prfrent augmenter les ressources que de rserver les ressources vu la complexit du systme
sans oublier que la dmarche de rservation des ressources est ingalitaire 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 paratre comme
concurrents de RSVP peuvent tre ses allis en allgeant au maximum la tche de maintien d'tats, de
raffrachissements 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 rseaux fibres (IP over Sonet, IP over SDH...) et
dans ce cas, la gestion de QoS au niveau IP est indpendante de tout autre mcanisme sous-jacent.
Mais pour l'heure actuelle, IP s'appuie sur des technologies de "bas niveau" qui intgrent 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 rseau sous-jacents.
IntServ a t spcifi pour les technologies suivantes:
liens rseau bas dbit :
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
30/9/2014 Le protocoles RSVP
http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/rsvp/ 7/7
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.
Rseaux 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.
HTTR
Tous droits rservs
2001 Universit Paul Sabatier (Toulouse III)
Andr Aoun