Integrated services

Au début, le protocole IP n'était pas prévu pour gérer la qualité de service QoS, du coup, les flux soumis à de fortes contraintes sur le plan de la qualité de service ont eu du mal à obtenir les « privilèges » nécessaires à leur bon acheminement sur le réseau Internet. Des recherches se sont alors lancés pour pallier ce problème. Ces derniers ont été axés sur plusieurs modèles, parmi ces derniers :

• les protocoles temps réel RTP/RTCP ;
• le modèle IntServ ;
• le modèle DiffServ ;
• le modèle MPLS.

IntServ avait pour objectif de migrer vers des échanges temps réel de bout en bout. Ainsi, il fallait apporter des solutions pour :

• le réseau local (celui de la maison ou de l'entreprise par exemple) ;
• le réseau d'accès (celui du site du travail par exemple) ;
• le fournisseur d'accès à internet (FAI) ;
• le cœur de l'Internet.

Ce qui distingue IntServ des autres solutions c'est le fait qu'il est déterministe.

IntServ est déterministe et pour garantir cet aspect, il se base sur la réservation.

Ceci veut dire qu'IntServ réserve suffisamment de ressources sur tous les routeurs par lesquels le flux passera jusqu'à la destination. Ainsi on garantit que le flux passera sans aucun problème ni retard.

La spécification du trafic par l’émetteur est appelée TSPEC. Celle des ressources du récepteur RSPEC.

Le protocole qui permet à ce modèle de fonctionner est le protocole de signalisation RSVP.

On distingue deux types de message[1] :

• PATH : envoyé régulièrement par les expéditeurs.
• RESV : envoyé par les destinataires en réponse.

Comme IntServ repose sur la réservation, l'unique limite de ce modèle est la mise à l'échelle ou plus exactement la « scalabilité » (scalability en anglais).

• seau à jetons
• seau percé

• (en) RFC 1633 Integrated Services in the Internet Architecture
• (en) Cisco Whitepaper about IntServ and DiffServ