ARCHITECTURES

&
PROTOCOLES
 COMMENT PEUT-ON APPLIQUER LA
QoS À TRAVERS UN RÉSEAU?

© El gholami Khalid, ENSA de Khouribga

2
MODÈLE INTSERV

3
© El gholami Khalid, ENSA de Khouribga
 MODÈLE INTSERV
Internet un réseau à intégration de services.

 Concept de flot de données

 Garantie de la QoS de bout-en-bout
 Le modèle IntServ repose sur deux hypothèses :
 L’infrastructure Internet sera utilisée pour supporter les communications
temps réels
 Les ressources doivent être explicitement gérées
 réservation des ressources
 le contrôle d’admission
 Maintient d’état spécifique au flux dans les routeurs

© El gholami Khalid, ENSA de Khouribga

4
 MODÈLE ORIENTÉ SERVICE

(Service) (Routeurs)
 Demande des ressources ➔ Réservation des ressources

Flux individuels Classes de flux (Entités)

© El gholami Khalid, ENSA de Khouribga

5
 FONCTIONS (COMPOSANTES) INTSERV

 Fonctions :
 Un classifieur ("classifier") par flux (suivant les attributs des paquets)
 Un ordonnanceur de paquets ("packet scheduler"),
 Un contrôle d’admission ("admission control routine") ,
 Un protocole de réservation de ressources ("reservation setup protocol").

© El gholami Khalid, ENSA de Khouribga

6
 ROUTEUR INTSERV

Plan de
contrôle

Plan de
Données

© El gholami Khalid, ENSA de Khouribga

7
 INTSERV (CLASSES DE SERVICE)

Best Effort Service a contrôle Service garantie

de charge
•Aucune • Différenciation • garantie du délai
 Best-Effort service garantie entre les trafics « d’attente »
• assure un niveau de
 Controlled-Load Service • les applications BP
• Adapté aux
 Guaranteed Service multimédia plutôt
adaptatives applications temps
réel non adaptatives
• service proche de (Voix).
BE dans un réseau •Basé sur l’hypothèse
non chargé du cas le plus
défavorable
[RFC2211, 1997] [RFC2212, 1997]
© El gholami Khalid, ENSA de Khouribga
8
 INTSERV (SPECIFICATION DU FLUX)

 Besoins de service
 Délai par paquet
 Gigue, Maximum et Minimum de délai
 Bande passante minimale
 Taux de perte des paquets.
 Caractérisation du trafic
 Débit moyen (CIR),
 Débit crête (PIR),
 Taille maximum de la rafale (burst size)
 Sau à jeton (Tocken bucket).
 Classification de trafic :
 Temps réel
 Élastique

© El gholami Khalid, ENSA de Khouribga

9
 INTSERV / RSVP |RFC 2205
 Protocole qui transporte les demande de réservation de
ressources à travers le réseau.
 Doit être présent (activé) sur la source, destination et les routeurs
intermédiaire.
 Établissement d’une classification de paquet et d’état de
transmission pour chaque nœud.
 Reserve/refuse la réservation selon la décision de l’agent de
« contrôle d’admission ».

 Principe :
 Émetteur : Requête de réservation
 Récepteur : Spécification des ressources demandés
 Routeur RSVP : réservation
© El gholami Khalid, ENSA de Khouribga
10
 LE PROTOCOLE RSVP

Protocoles & applications de la couche supérieure

Interface des services IP

ICMP IGMP RSVP
IP

Interface des services LD

Modules Liaison de données

11
© El gholami Khalid, ENSA de Khouribga
 INTSERV / RSVP

 Les opérations RSVP

 Session définie par : @destination, protocole de transport (PID), N° port destination

© El gholami Khalid, ENSA de Khouribga

12
 EXEMPLE

Récepteur 1

Émetteur

© El gholami Khalid, ENSA de Khouribga

13
 OBJECTIFS DE RSVP

 Utilisé dans les réseau non orientés connexion (ex. IP)

 Ne réplique pas les fonctions de routage.
 Indépendant du protocole de routage utilisé.
 Prend en considération les changements de routes.
 Support le multicast.
 Les récepteurs peuvent avoir des capacités différentes et peuvent avoir
des besoin QoS différents.
 Le changement dans le groupe ne doit pas coûter beaucoup de
ressources.
 Les réservation doivent être agrégées. Les membre d’un groupe ne
doivent pas tous réserver.
 Support de l’hétérogénéité des récepteurs
 Conclusion:
 Réservation Orienté récepteur
 État de réservation dite « Soft-state »

© El gholami Khalid, ENSA de Khouribga

14
 ÉTAT ÉPHÉMÈRE « SOFT STATE »

 Soft Stat
 Les routeur garde un état a propos de chaque réservation.
 messages envoyés périodiquement afin de rafraichir les états de réservation
 Les états non rafraichi expirent (times out) et donc sont supprimés
automatiquement.

 Alternative: Hard state

 Pas de messages de rafraichissement périodique
 La présence de l’état de réservation est garantie.
 La suppression de l’état de réservation doit être précédé par une demande explicite.
 Problème ?

 Propretés de “soft state”:

 Adaptes aux changement des routes, sources, et récepteurs.
 Reprise en cas d’erreurs
 Efface l’état si le récepteur n’est plus joignable

© El gholami Khalid, ENSA de Khouribga

15
 MODÈLE DU SERVICE RSVP

 Réservation des ressource pour les flux de données simplexes

 C’est le récepteur qui décide si on doit réserver ou non.
 messages de control encapsulés dans les datagrammes IP (numéro
de protocole 46).
 Les messages PATH/RESV sont envoyés périodiquement afin de
rafraichir les états de réservation « soft state ».
 Résultat possibles :
 Les requêtes qui échouent retournent des messages d’erreur
indiquant que le récepteur doit réessayer.
 Sinon Chemin réservé (Circuit!).
 Rq.: Pas d’acquittement en cas de succès de la réservation.

© El gholami Khalid, ENSA de Khouribga

16
 TYPES DE MESSAGE DE BASE

 Message PATH
 Message RESV
 Message CONFIRMATION
 Envoyé seulement comme réponse à une requête.
 Envoyé en Unicast au récepteur, le message RESV confirme un état
déjà établi.
 Message TEARDOWN
 Message ERROR (si PATH ou RESV échoue)

© El gholami Khalid, ENSA de Khouribga

17
 Message RSVP Champs type Fonction
de message
PATH 1 Envoyé par une source qui initie la session et envoie ses exigences au destinataire.

RESV 2 Envoyé par le récepteur de la session. Il permet de spécifier la QoS souhaitée et de fixer les
réservations correspondantes dans chaque nœud.

PATH Error 3 Utilisé (en réponse à un message PATH) pour signaler les erreurs se produisant lors de l'établissement
d'un chemin entre la source et la destination d'une session.

RESV Error 4 Utilisé (en réponse à un message RESV) pour signaler les erreurs se produisant lors de l'établissement
des réservations le long du chemin de la session.

PATH Tear 5 Envoyé par la source de la session. Ce message annule explicitement le PATH State dans tous les
nœuds d'un chemin de session.

RESV Tear 6 Envoyé par la destination d'une session. Ce message annule explicitement les réservations dans tous
les nœuds d'un chemin de session.
RESV Confirm 7 Fournit une indication positive à l’initiateur de la session en l'informant que tous les nœuds le long du
chemin ont accepté la requête de réservation. Lorsqu'un récepteur formule une requête de
réservation, il peut également demander un message de confirmation pour indiquer que la réservation
a (probablement) été effectuée dans le réseau. Les messages de confirmation RSVP sont envoyés par
la source de la session directement au destinataire de cette session ; les nœuds intermédiaires ne
traitent pas les messages RESV Confirm.

© El gholami Khalid, ENSA de Khouribga

19
 MESSAGE PATH

 L’émetteur envoi le message PATH qui contient les spécification

du trafic de l’émetteur (Transmitter Spec : Tspec)
 Paramètre du seau à jetons
 Les routeurs mettent à jour la table des états PATH en fonction des
infos du message PATH (La table contient par ex, l’adresse du
dernier nœud qui a retransmis le message.
 On enregistre un chemin inverse vers l’émetteur. Utile dans la phase
de réservation.

© El gholami Khalid, ENSA de Khouribga

20
 MESSAGE RESV

 Le récepteur envoi le message RESV via le chemin inverse du

message PATH
 Ce message contient les spécification du trafic du récepteur
(Receiver Spec : Rspec) en plus de Tspec
 On spécifie les besoin en termes de délai des file d’attente et de
bande passante
 Spécification du filtre de réservation
 Quelles transmissions peuvent utiliser les ressources réservées ?
 style de réservation.
 Le routeur effectue le contrôle d’admission et alloue les
ressources si possible. Sinon il envoi un message d’erreur
 RESV toutes les 30s

© El gholami Khalid, ENSA de Khouribga

21
 MANIPULATION DU MESSAGES RESV
PAR LE ROUTER

 Si la requête est rejetée, envoi un message d’erreur.

 Si elle est acceptée:
 Install un filtre de paquet dans la BD de retransmission
 Passe les paramètres de flux à l’ordonnanceur
 Activer la réglementation (policing) de paquet si nécessaire
 Retransmettre le message RESV en avant (upstream).

© El gholami Khalid, ENSA de Khouribga

22
 RÉSERVATIONS RSVP

 Les réservations en provenance de multiple récepteurs pour un

seul émetteur son fusionnées dans les point de branchement.
 Les réservations pour multiple émetteur peuvent être
additionnées:
 Exemple la vidéo conférence
 Les réservations pour multiple émetteur peuvent ne pas être
additionnées:
 Exemple : Audio Conférence, seulement un utilisateur qui parle à la
fois.

© El gholami Khalid, ENSA de Khouribga

23
 INTSERV / RSVP

 Styles de filtres de réservation : "reservation filter style" = jeu d'options

inclus dans la requête de réservation de ressources
 WF :
 Tous les flux des émetteurs upstream
 La bande passante réservé doit être partagée
 FF (opposé de WF)
 Liste d’émetteur spécifique
 La bande passante réservé et distinct
 SE
 Liste d’émetteur spécifique
 La bande passante réservé doit être partagée
© El gholami Khalid, ENSA de Khouribga
24
 EXAMPLE

A C
R1
S1

R2
S2, S3
B D
R3

 S1, S1, S3 : Émetteurs

 R1, R2, R3 : Récepteurs
 A,B,C,D : Interfaces du routeur
© El gholami Khalid, ENSA de Khouribga
26
 RÉSERVATION WILDCARD FILTER

 R1, R2, et R3 souhaitent réserver 4d, 3d, et 2d, respectivement

 d est un débit donné.

4d
4d A C
R1
S1

R2
S2, S3
B D
4d 3d R3

© El gholami Khalid, ENSA de Khouribga

27
 RÉSERVATION FIXED FILTER

 R1 souhaite réserver 4d pour S1 et 5d pour S2.

 R2 souhaite réserver 3d pour S1 et d pour S3.
 R3 souhaite réserver d pour S1.
S1:4d
S2:5d
S1:4d
A C
R1
S1

R2
S2, S3
B D
S2:5d R3
S3:d S1:3d
S3:d

© El gholami Khalid, ENSA de Khouribga

28
 RÉSERVATION DYNAMIC FILTER

 R1 souhaite réserver d pour S1 et S2 (partagé).

 R2 souhaite réserver 3d pour S1 et S3 (partagé).
 R3 souhaite réserver 2d pour S2.

(S1,S2):d
S1:3d A C
R1
S1

R2
S2, S3
B D
R3
(S2,S3):3d
(S1,S2,S3):3d

© El gholami Khalid, ENSA de Khouribga

29
 INTEGRATED SERVICES

 Avantages :
 Réservation des ressources explicite(end to end)
 Contrôle d’admission avant la demande (objet d’autorisation, object
de réglementation)
 Signalisation pour des N° de port dynamique (par exemple, H.323)
 Faiblesses :
 signalisation continue due à l’architecture “stateless”
 complexe à mettre en œuvre
 Scalability (passage à l’échelle)

© El gholami Khalid, ENSA de Khouribga

34
DIFFSERV

35
© El gholami Khalid, ENSA de Khouribga
 DIFFERENCIATED SERVICE

 Séparation du trafic par classes « agrégation des flux »

 La signalisation est faite dans chaque paquet
 La complexité du traitement dans les routeurs aux frontières
 La tarification du service est plus simple

© El gholami Khalid, ENSA de Khouribga

36
 DIFFSERV /PHB

 PHB (Per Hop Behaviour).

 Traitement des paquets par classe
 Comportement définit par les priorités
 Mis en œuvre en utilisant des mécanismes d’ordonnancement et de
régulation de flux
 Variété de services différenciés

© El gholami Khalid, ENSA de Khouribga

37
 DIFFSERV

 Classes de service :
 DF Default Forwarding.
 EF (Expedited Forwarding) ou Premium Service
 AF (Assured Forwarding)

© El gholami Khalid, ENSA de Khouribga

38
 RAPPEL : DSCP

© El gholami Khalid, ENSA de Khouribga

39
 DF | DEFAULT FORWARDING

 Il s’agit de la classe par défaut.

 Aucune garantie de QoS
 Niveau de service : variable / pas de garantie / dépond des condition
réseau
 Valeur du « Code Point » : 000000 (DSCP)

© El gholami Khalid, ENSA de Khouribga

40
 TRANSMISSION EXPÉDIÉE : EF

 RFC 3246 définit le PHB de transmission expédié (EF) : « Le PHB EF peut être
utilisé pour établir une basse perte, une faible latence, une gigue faible, une
bande passante assurée, un service de bout en bout par des domaines DS
(Diffserv). Un tel service apparaît aux points finaux comme une connexion
point par point ou une ligne louée virtuel. « Ce service a été également décrit
comme service de première classe ». Le point de code 101110 est
recommandé pour le PHB EF qui correspond à une valeur DSCP de 46 en
décimale.

 Remarque : RFC 3246 remplace le RFC 2598

© El gholami Khalid, ENSA de Khouribga

41
 EF | PROPRIÉTÉS

 Performances :
 Faible perte de paquet
 Faible latence
 Faible gigue
 Bande Passante Assuré
 Niveau de Service : Premium
 Ressemble à une liaison virtuelle alloué
 Valeur du « Code Point » : 101110 (DSCP)

© El gholami Khalid, ENSA de Khouribga

42
 TRANSMISSION ASSURÉE : AF

 RFC 2597 définit la transmission assurée (AF) PHB et la décrit

comme moyen pour un domaine DS fournisseur d'offrir différents
niveaux de garantie de transmission pour des paquets IP reçus
d'un domaine DS client. Le PHB de transmission assurée garantie
une certaine partie de la bande passante à une classe AF et
permet l'accès à la bande passante supplémentaire si
disponible.

 Remarque : RFC 2597 a été mise à jour par la RFC 3260

© El gholami Khalid, ENSA de Khouribga

43
 AF | PROPRIÉTÉS

 Il y a quatre classes AF, de AF1x à AF4x.

 Dans chaque classe, il y a trois probabilités de perte.
 Niveau de Service : En total, nous avons 12 niveaux de services
possibles
 Selon la stratégie donnée d'un réseau, des paquets peuvent être
sélectionnés pour un PHB selon le débit, le retard, la gigue, la
perte requis ou selon la priorité de l'accès aux services réseau.
 Valeur du « Code Point » : xxxxx0 (DSCP)

© El gholami Khalid, ENSA de Khouribga

44
 DSCP

45
© El gholami Khalid, ENSA de Khouribga
 ARCHITECTURE D’UN DOMAINE DIFFSERV

 Routeur de frontière (The ingress nodes & The Eggress nodes)

 Routeur de cœur (Interior nodes)

© El gholami Khalid, ENSA de Khouribga

46
 FONCTIONS DIFFSERV

 Fonctions de frontière (Edge)

 Classification des paquets et conditionnement du trafic
 Marquage de paquet « DSCP »
 La marque identifie la classe du Trafic « utilisée pour la Classification BA »
 Régulation du trafic par flux agrégés à la sortie du domaine DS

 Fonctions du Cœur (Core)

 Retransmission PHB
 Les paquets marqués sont associés au classe de trafic (ou BA « Behavior
Aggregate »)

© El gholami Khalid, ENSA de Khouribga

47
 INTERCONNEXION DE PLUSIEURS DOMAINES DS

© El gholami Khalid, ENSA de Khouribga

48
 DIFFSERV VS INTSERV

© El gholami Khalid, ENSA de Khouribga

49

IntServ
 Proposé en: 1997
 Qualité de Service par flux
 Deux services:
 Guaranteed Rate
 Controlled Load
 Hard QoS
© El gholami Khalid, ENSA de Khouribga
INTSERV VS DIFFSERV
DiffServ
 Proposé en : 1998
 Qualité de Service par classe
 Deux services:
 Assured Forwarding PHB
 Expedited Forwarding PHB
 Soft QoS
50
 CONCLUSION

 Les problèmes de congestion ont un lien direct avec la qualité

perçu par les utilisateurs.
 Les mécanismes de la qualité de service, à savoir; classification,
Marquage, Ordonnancement, Gestion de la congestion (AQM),
et le conditionnement du trafic (règlementation & régulation),
selon les organismes internationaux de normalisation.
 Gestion des flux de paquets en entrée et en sortie par les routeurs
afin d’assurer un service différencié et d’éviter au maximum les
congestions.

© El gholami Khalid, ENSA de Khouribga

53