PLAN

• Qualité de service
– Besoins et fonctionnalités
• IntServ (Integrated Services)
Les évolutions d ’IP – Architecture
– Le protocole RSVP
– Les classes de service
Lila Boukhatem
LRI – Laboratoire de Recherche en Informatique
Université de Paris-Sud
• DiffServ (Differentiated Services)
Septembre 2002
Lila@[Link]
– Architecture
– Les classes de service

Notion de QoS Notion de QoS

• La QoS
• est un attribut du service fourni par le réseau
• elle détermine le degré de satisfaction d ’un utilisateur
• IP est un protocole dont l'objectif principal est
– Quantitativement, elle est exprimée par un ensemble de paramètres
• Délai (transparence temporelle) l'
acheminement des messages entre un émetteur et
– Délai de bout-en-bout τ (délai entre l'
émission et la réception d'
un message) un (ou plusieurs) récepteur par l'intermédiaire d'un
– La variation de délai (gigue γ) réseau.
• Intégrité des données (transparence sémantique)
– Taux de pertes π (rapport entre la quantité de message reçu sur la quantité émise) • Définition "QoS (Quality of Service) IP" : manière
– Taux d ’erreurs
d'être, bonne ou mauvaise, de la couche IP pour
– Taux de cellules mal-insérées
• Fiabilité et disponibilité s'acquitter de certains devoirs, de certaines
– Exemples : fonctions envers le transport des messages.
• fichiers : π = 0 et γ < τ < +∞ (très subjectif) ;
• la voix interactive : π < 10%, τ < 400ms et γ < 100ms.
 Pourquoi la QoS? Le compromis
• Comment garantir la QoS?
– Besoin d ’intégration (auparavant : réseaux dédiés) • Réservation de ressources
– Support de différents types d ’applications nécessitant des QoS – Les principales ressources réseaux (routeurs et stations inclus) sont :
différentes • le débit des interfaces ;
– Support de nouvelles applications (multimédia) • la mémoire pour stocker les messages.
• Les applications nécessitant de la QoS – nécessaire si le débit d'
entrée est supérieur au débit de sortie.
– La fourniture de la QoS nécessite une réservation de ressources
– La voix, la vidéo, les applications multimédias sont des flux de
• La difficulté de la garantie de la QoS réside dans le compromis
trafic temps réel qui imposent des contraintes concernant les
délais Optimisation de l ’utilisation
– Le transfert des données impose des contraintes en terme de taux Allocation de ressource
des ressources du réseau
de perte
– Les business applications basées sur une architecture Réservation Multiplexage Pur
Client/Serveur ayant des contraintes sévères en terme de temps Bonne QoS Mauvaise QoS
de réponse Mauvaise utilisation Bonne utilisation
des ressources des ressources

La QoS : les fonctionnalités La QoS : les fonctionnalités

• Contrôle de conformité (Policy)
– Pour vérifier si la source n ’émet pas au-delà des ressources
• Assurer la QoS passe par : réservées
– Le définition d ’un contrat de trafic • Scheduling (ordonnancement)
• L ’utilisateur spécifie les besoins de QoS de ses applications
– Pour l ’allocation des capacités de transmission pour atteindre
– La définition de fonctionnalités de contrôle les objectifs de QoS
• Contrôle d ’admission • Mécanismes de rejet
– Pour décider s ’il faut accepter ou rejeter la nouvelle
demande de réservation en fonction des ressources – Pour rejeter des paquets, en cas de congestion, en fonction des
disponibles besoins de QoS des paquets.

Mécanismes de
• Réservation

Scheduling
Sélection
– Réserver la quantité nécessaire de ressources (mémoire, de file
bande passante, …)
 La QoS IP La QoS IPv4
• Deux possibilités
• La QoS IP version 4 (IPv4) est absente :
• Sur-dimensionner le réseau
– QoS native
– pas de contrôle sur le taux de perte π :
• best-effort (si cela passe tant mieux, si cela ne passe pas tant
– Pas besoin de mécanismes de contrôle de trafic complexes
pis),
– Mais il faut retenir les leçons du passé :
– « It is hard to imagine that a computer will ever need more than 8 Kwords
– pas de contrôle sur les délais de traversé τ;
of main memory », John Von Neumann, 1947 – pas de contrôle sur la gigue γ;
– « The Ethernet has more bandwidth than will ever be needed » Group of – pas de distinction des besoins de transport.
experts, Berkeley, California, 1982
– Remarque : le sur-dimentionnement des tampons évite les pertes mais • TCP permet d' avoir un taux de perte nul, au
augmente les délais de bout-en-bout! détriment de la gigue et du délai de traversé.
• Implémentation de mécanismes de contrôle de QoS • IPv4 n'est pas adapté pour le support de la QoS
– Ces fonctionnalités doivent être implémentées au niveau IP (sauf dans le cas d'
un réseau sur-dimensionné)
• Deux approches
– IntServ, DiffServ

IntServ IntServ
• But
– Intégration de services : temps réel et données
– RFC 2205 à 2210 • Besoins de l’architecture
• Caractéristiques – Réservation de ressources
– Garantie de la QoS par flux • Un protocole de signalisation (RSVP)
– Un profile QoS est associé à chaque flux
– Réservation par flux (RSVP) – Scheduling
• Groupes de travail – Mécanismes de contrôle d’admission
• Le groupe de travail RSVP – Mécanismes de contrôle de conformité
• Le groupe de travail IntServ
• Le groupe de travail Issll (Integrated Services over Specific
Link Layer)
• Le groupe de travail QoSR (QoS Routing)
 Le protocole RSVP Le protocole RSVP - Architecture
• RSVP : Resource Reservation Protocol - RFC Source 1
2205 à 2210 Récepteur 1
• Caractéristiques
– Protocole de signalisation
– Un flux est identifié par une adresse de destination et
un numéro de port
– Support de flux unicast et multicast
– Réservation en Soft-State dans les routeurs
– Protocole orienté récepteur
Récepteur 2

Source 2

Le protocole RSVP - fonctionnement Le protocole RSVP - Architecture

• Le message PATH assure les fonctions suivantes : Machine Routeur
– Il transporte les caractéristiques du flux de données émis par la
source Agent Contrôle Agent Contrôle
Application RSVP des Application RSVP des
– Il transporte les possibilités du réseau (des routeurs) autorisations autorisations

– Il détermine le chemin de retour qui sera emprunté par les

messages de réservation

ordonnanceur

ordonnanceur
Classificateur

Classificateur
d ’admission

d ’admission
• Le message RESV . .

Contrôle

Contrôle
. .
. .
– Ces messages sont envoyés par les récepteurs
– Ils suivent les chemins inverse des données venant des sources
– Ils ne suivent pas le plan de routage du réseau
Messages de contrôle interne
Messages RSVP de signalisation Flux de données
 Le protocole RSVP - Architecture Le protocole RSVP - Architecture

• Les éléments de l ’architecture

– L ’application source • Les éléments de l ’architecture
• produit les données
– Le classificateur
• dialogue avec un agent RSVP pour lui indiquer la nature des flux qu ’elle
émet • classifie les paquets en fonction de leur « priorité » (choix de la
file)
• reçoit de l ’agent RSVP les informations sur la QoS demandée par les
récepteurs – L ’ordonnanceur
– L ’agent RSVP • définit la discipline de service (politique de sélection des
paquets)
• Il émet les messages de signalisation RSVP vers les autres agents
– Le contrôle d ’admission
– Le contrôle des autorisations
• vérifie qu ’il est techniquement possible de faire des demandes
• Il vérifie que les demandeurs ont administrativement le droit de faire des de réservation
demandes de réservation

Le protocole RSVP - le format des messages Le protocole RSVP - le format des messages

0 7 15 23 31 • Format des messages

– Version : version du protocole (1 pour RSVP1)
Version drapeau Type de message Checksum
– Drapeau : n ’est pas utilisé
TTL réservé Longueur du message RSVP
– Type de message : indique la nature des données
Longueur Objet1 Classe Type de classe transportées
• Exemple : 1: Path, 2: Resv, 3: PathErr, 4:ResvErr
– Checksum : contient le complément à 1 de la somme
en complément à 1 du message
Longueur Objet i Classe Type de classe – TTL : permet de détecter si un routeur non-RSVP a
renvoyé le paquet en comparant sa valeur avec celle du
paquet IP
– Longueur : longueur du message RSVP (en octets)
Longueur Objet n Classe Type de classe
 Le protocole RSVP - le format des messages Le protocole RSVP - le format des messages
• Quelques objets
– SESSION (classe 1)
• Il Sert à identifier les flux • Quelques objets
• Une session est caractérisée par l’adresse IP source/ destinataire, – SENDER_TSPEC (classe 12)
numéro de port source/destinataire, et l’identificateur du protocole
• Contient les caractéristiques du flux tel qu ’il est émis par la
– RSVP-HOP (classe 3) source
• Il contient l’adresse IP du routeur RSVP qui émet ce message
• Il permet aux routeurs en amont de connaître l’adresse du routeur – ADSPEC (classe 13)
précédent pour lui faire remonter les messages de réservation • Contient les caractéristiques du chemin emprunté par le flux.
– FLOWSPEC (classe 9) Ces caractéristiques sont mises à jour par les routeurs traversés
• Définit la QoS demandée dans un message RESV • En les combinant avec les informations du SENDER_TSPEC,
les clients sont capables de déterminer la QoS qui peut être
– FILTER_SPEC (classe 10) demandée.
• Définit le sous-ensemble de sources pour lesquelles s’applique la QoS
définie dans FLOWSPEC

Les classes de service IntServ IntServ - Bilan

• Le service Best Effort (BE)
• Service actuellement offert par l ’Internet • Points forts
• Suffisant pour les applications actuelles (ftp, Email, etc.) – Introduit de la QoS dans un domaine IP sans faire appel
• Classe par défaut si aucune autre n ’est spécifiée à d ’autres technologies (ATM)
• Le service à charge contrôlée - Controlled Load Service – Fournit une bonne granularité de QoS
(CLS) - RFC 2211 • Points faibles
– Offre un comportement identique à celui d ’un réseau Internet peu chargé – Non résistant au facteur d ’échelle (scalability) puisque
• Le service garanti - Guaranteed Service (GS) - RFC 2212 c ’est une approche basée flux
– Offre un service avec un taux de perte faible (0) et des délais bornés pour les – La description du CLS est vague et donne lieu à
applications sensibles aux délais différentes interprétations
– Les paquets n ’arriveront pas avec un retard supérieur à une borne – Nécessité d ’introduire de la facturation (pas évident!)
mathématique calculable – L ’approche Soft-State nécessite des rafraîchissements
réguliers => perte de bande passante
 Int-Serv - Bilan Diffserv
• But
• Fournir de la QoS en se basant sur une approche de flux agrégés
• Fournir une grande variété de services généralistes
• Utilisation • Approche simple et « scalable »
• Les paquets de plusieurs utilisateurs sont agrégés dans le même flux (la
– Dans les réseaux internes des entreprises pour même classe de service)
l ’intégration de services • Pas de signalisation
– Pas dans les réseaux d ’ISPs
• Principe
• Améliorations • Chaque paquet dispose dans son en-tête d ’un champ DS
– Modification de RSVP pour prendre en compte le • Le DS identifie la classe de service
facteur d ’échelle
• Possibilité de faire de la réservation de flux agrégés
• Le DS identifie le PHB (Per Hop Behavior)
• Possibilité de regrouper les rafraîchissements (Bundled – Trois grandes classes de service
refreshments) • Expedited Forwarding (EF)
• Assured Forwarding (AF)
• Best Effort (BE)

Diffserv Diffserv
• Un domaine Diffserv est un ensemble de nœuds fournissant les - Observer le DS
mêmes services • Principe - Déterminer le PHB associé
– Accords entre domaines pour la continuité des services
• Une classe de service devrait subvenir à un panel Données En-tête IP PHB : comportement
d’applications local d’un nœud sur
• L’aggrégation consiste à associer des flux ayant des besoins de un flux agrégé : π ,
0 5 7
QoS similaires. γ,...
DSCP CU Champ DS
• Tous les flux appartenant au même flux agrégé subiront les
mêmes traitements :
– réduit les problèmes de mise à l'échelle; Ver HL TOS T Length Ver Traffic class Flow label
– le traitement peut se contenter d'
un paramétrage manuel;
Ident. Flags FO Payl. Length N. header Hop lim
– moins efficace que le mode flux par flux.
TTL Protocol HEC SA
• Le codepoint (DS) d’un message identifie:
SA
– La classe de service souscrit par le flux individuel du message DA
DA
– Le flux agrégé auquel appartient le message
 Diffserv Diffserv
• Le marquage des paquets peut se faire :
– Par la source
Domaine DS
– A l’entrée du réseau
Routeur PHB1 PHB1
• SLA (Service Level Agreement) d ’entrée PHB1
– C’est un contrat qui lie : PHB1
• Un usager et le domaine auquel il est connecté
• Deux domaines interconnectés
– Pour un flux de données, il définit :
• Le service demandé SLA
• Le comportement futur de la source du lux
• Les moyens de contrôle de ce comportement
• Le contrat inclut les règles de « conditionnement » de trafic Traffic conditioning
– TCA (Traffic Conditioning Agreement)
– Il permet de spécifier les profiles de trafic et les règles de politique associées

Diffserv - architecture des routeurs d’extrémité Diffserv - architecture des routeurs d’extrémité
• Composants de l ’architecture • Composants de l ’architecture

En-tête IP En-tête TCP

Marker
…. DS .… …. AS …. N° port Données
Classifier Meter Shaper
Dropper
Classifier

– Classifier Traffic Conditioner

– Traffic Conditioner
• MF (MultiField) Classifier
• Le SLA associe à un flux un profile de trafic (Traffic Profile)
• Il a pour rôle de sélectionner les paquets en se basant sur la
combinaison d ’un ou des champs suivants : adresse source, • Le Traffic Conditioner se base sur le trafic profile pour
adresse destination, le DSCP, le numéro de port déterminer si le trafic est conforme au SLA
source/destination, etc. • Le trafic conforme au SLA et le trafic non conforme au SLA
sont traités différemment
Diffserv - architecture des routeurs d’extrémité Diffserv - architecture des routeurs d’extrémité

• Traffic Conditioner • Traffic Conditioner

– Le composant Meter – Le In-profile trafic est transmis tel quel
• permet de mesurer les propriétés temporelles du paquet par • Il peut être marqué s ’il ne l ’est pas encore
rapport au profile défini dans le SLA et de voir si le trafic (domaine source)
est conforme (in-profile) ou non (out-of-profile) • Il peut être remarqué (quand il passe d ’un domaine
DS à un autre avec une correspondance différente
de DSCP)
Marker – Le out-of-profile trafic peut être
Classifier Meter Shaper • remis en forme (shaped)
Dropper • re-marqué (re-marked) (niveau de priorité inférieur)
Trafic In-profile • rejeté (dropped)
ou Trafic out-of-profile?
Traffic Conditioner

Diffserv - architecture des routeurs d’extrémité Diffserv - architecture des routeurs d’extrémité

• Les composants du « Traffic conditioner » • Composants de l ’architecture

– Le composant Shaper
In-profile
• permet de retarder les paquets pour rendre le flux Oui Non
Tester DSCP
compatible au profile de trafic Classifier Conformité Marqué mapping
Out
– Le composant Marker Non Oui
• permet de marquer le champ DSCP et ajouter le paquet à un Out-of-profile Marquer Re-marquer
agrégat particulier
– Le composant Dropper Lisser
• permet de rejeter des paquets pour rendre le flux compatible Re-marquer
au profile de trafic Rejeter
Diffserv - architecture des routeurs d’extrémité Les classes de service

• Composants de l ’architecture – Expedited Forwarding (EF)

– Exemples de Meter – Assured Forwarding (AF)
• Token Bucket – Best Effort (BE)
• Average Rate Meter • La classe EF
• Exponentially weighted Moving Average Rate – DSCP = 101110
Meter – Premium service, équivalent à une ligne spécialisée (Virtual
– Exemples de Dropper leased Line)
• Head dropper – Faible taux de perte, faible délai, faible gigue, bande passante
• Tail dropper garantie
• RED dropper – Pour atteindre ces performances les paquets d ’un service EF
ne devraient pas subir de file d ’attente (ou passer par des files
• Weighted RED dropper
de très petite taille)

Les classes de service Les classes de service

• La classe AF
• La classe EF – Son objectif est limiter le risque de perte des paquets
– Tant que le trafic n ’excède pas le niveau négocié, la probabilité
– Pour un agrégat de trafic EF le taux maximal de perte des paquets doit être faible
d ’arrivée doit être inférieur au taux minimal de départ – 4 classes
(departure rate), ce qui suppose : – 3 niveaux de « drop precedence » (priorité à la perte)
– Dans les nœuds internes une bande passante minimale
Classe 1 Classe 2 Classe 3 Classe 4
est disponible au service EF
Low Drop 001010 010010 011010 100010
– Dans les nœuds d ’extrémité un « traffic Precedence
conditioning » est effectué Medium Drop 001100 010100 011100 100100
Precedence

High Drop 001110 010110 011110 100110

Precedence
 Les services Exemple de modélisation d ’un service Diffserv

• La classes AF
– Les niveaux de « drop precedence » correspondent à une • Diffserv Model - RFC 2475 – An Architecture for
probabilité de perte de paquets Differentiated Services
– En cas de congestion, les paquets sont rejetés en fonction de leur
« drop precedence »
– Remarque
• Chaque classe possède des minimas de bande passante et d’espace tampon
• Pas de garantie de délai, ni de perte (par défaut)
– Exemple de trafic AF : Olympic service (bronze,silver, gold)
• Nécessité de mise en place de mécanismes de Queue
Management (selective packet discarding)
• RED (Random Early Discard)
• RIO (Random Early Discard In/Out)

Exemple de modélisation d ’un service Diffserv Exemple de modélisation d ’un service Diffserv

• Queuing System
• Classifier Meter – Packet storage. Queues
- DSCP - Average Rate Meter • FIFO
- IPV4/IPV6 - Token Bucket – Selective packet discarding. Algorithmic Dropper.
- 802 MAC - Exponentially Weighted • Head Dropper.
Moving Average Rate Meter • Tail Dropper.
• RED Dropper.
• Weighted RED Dropper.
• Action Elements – Scheduler
Marking : pour marquer et re-marquer les paquets en fonction des • FIFO Scheduler
résultats du Classifier • Strict Priority Scheduler
Absolute dropping : rejeter les paquets • Round Robin Packet Scheduler
Null action • Weighted Round Robin Packet Scheduler
 Exemple de modélisation d ’un service Diffserv Exemple de modélisation d ’un service Diffserv

" #$
%

DSCP Profile Treatment

! " #$

EF 001001 Profile1 Discard non- *+,!-

conforming. '(
%

AF1, DP1 001100 Profile2 Discard to profile,

" #$
tail-drop when full. '(
% .

AF2, DP1 001101 Profile3 Re-mark non-conforming

'(
to DSCP 001000, tail-drop ! "
( #, - *
.

when full.
none Apply RED-like
'(

Best-Effort other
% &
)

dropping.
Service

-4 + " #, $

- .
$ /
" #$ 01
! %" " #$
%
2 '
# $ % & '$ (
- .
$ /
0 3!
2 '
-4
! " #$ ! " #$
*+,!- *+,!-
! "
# $ % &
'( '$ (
% '(
%

" #$ " #$
'(
% . '(
! " % .
# $ )% & -4
'$ ( - .
$ /
0 3!
'(
.
'( , '
! "
( #, - * ! "
( .
#, - * - .
$ )/
0 3!
! "$ )% & 2 ) '
'( '$ (
% & '(
) * ! "$ )% & % &
)
'$ (
-4
 Bilan
– Diffserv est plus résistant au facteur d ’échelle qu ’Intserv,
mais avec une granularité réduite
– Permet de construire une variété de services différenciés avec
la notion de PHB
• Complexité
– Le choix et la configuration des algorithmes de scheduling
dans les nœuds internes
– L ’implémentation des « Traffic conditoners » dans les nœuds
d ’extrémité
– Nécessité de centraliser la gestion
• Pour la configuration des Edge et Core routers
• La gestion des SLAs et leur traduction en PHBs
• La mise en place des services AAA (Authentication, Authorization,
Accounting)