Au contraire du modèle IntServ qui traite indépendamment chaque flot, le modèle DiffServ propose de séparer le trafic par classes.
Le groupe Diffserv propose donc d'abandonner le traitement du trafic sous forme de flots pour le caractériser sous forme de classes.
Chaque classe est identifiée par une valeur codée dans l'en-tête IP. Cette classification doit se faire sur les routeurs de bordures (edge router) à l'entrée du réseau.
L'architecture des services différenciés contient 2 types d'éléments fonctionnels :
1. Les éléments de bordures (edge functions) : ils sont responsables de la classification des paquets et du conditionnement du trafic. En bordure du réseau, c'est à dire à l'arrivée du premier élément actif capable de traiter le champs DS (DS-capable), les paquets arrivant ont dans leur champ TOS (pour IPv4) ou Traffic Class Octet (pour IPv6), une certaine valeur DS. La marque qu'un paquet reçoit identifie la classe de trafic auquel il appartient. Après son marquage, le paquet est envoyé dans le réseau ou jeté.
2. Les éléments du coeur du réseau (core functions) : ils sont responsables de l'envoi uniquement. Quand un paquet, marqué de son champs DS, arrive sur un routeur DS-capable, celui-ci est envoyé au prochain noeud selon ce que l'on appelle son Per Hop Behaviour (PHB) associé à la classe du paquet. Le PHB influence la façon dont les buffers du routeur et le lien sont partagés parmi les différentes classes de trafic. Une chose importante dans l'architecture DS est que les PHB routeurs se basent uniquement sur le marquage de paquet, c'est à dire la classe de trafic auquel le paquet appartient ; en aucun cas ils ne traiteront différemment des paquets de sources différentes.
L'avantage de Diffserv est qu'il n'y a plus nécessité de maintenir un état des sources et des destinations dans les core routers, d'où une meilleure scalability.
Comportement du routeur :
" Expedited Forwarding (EF)
_ le routeur assure une émission à bas délai (file prioritaire)
_ les flux utilisant ce comportement ne doivent pas expérimenter des pertes.
_ un contrôle d'accès est nécessaire pour faire respecter la condition.
" Assured Forwarding (AH)
_ L'utilisateur
choisit une des 4 classes AF pour chaque flux.
(tous les paquets
d'un même flux appartiennent à la même classe)
_ Chaque classe obtient une quantité différente de ressources dans les routeurs du Backbone.
_ A l'intérieur de chaque classe, un algorithme de rejet sélectif différencie entre 3 niveaux de priorité.
_ En cas de congestion dans une des classes AF, les paquets de basse priorité sont rejetés en premier.
" Service Premium
_ Le routeur d'entrée ne laisse passer que des paquets conformes (shape, discard)
_ Basé sur le comportement EF.
_ Garantir aucune perte demande une coordination entre domaines (Bandwidth Brokers).
_ Son utilisation risque de demander une politique de facturation élaborée.
" Service Olympique
_ L'utilisateur définit pour chaque flux:
" la classe AF à utiliser (or, argent, bronze)
" le profile du flow (paramètres token-bucket)
_ A l'entrée du réseau, une étiquette est ajoutée à chaque paquet qui reflète:
" La classe AF pour le flux
" une priorité calculée par le routeur d'entrée en fonction du respect du profile accordé.
_ La différentiation entre flux est atteinte grâce à une attribution différente des priorités en fonction du profile.
Avantages de l'Assured Forwarding
_ peut offrir une meilleure différentiation
_ le marquage à l'entrée du réseau est une opération moins coûteuse que le shaping.
_ Il ne demande pas une coordination entre domaines.
_ Une facturation simple peut être utilisé.
Inconvénients de l'Assured Forwarding
_ la qualité offerte dépend énormément du niveau d'agrégation et de la présence de flux concurrents.
_ Il n'existe aucune assurance de délai.
Partie II - ETUDE PRATIQUE
Matériels :
- 2 Web caméras
- Routeur CISCO 3620
- 2 terminaux : une machine dite " Internet " et une dite " Interne "
- 2 câbles RJ45 croisés,
- 1 câble BD9/RJ45
Logiciels utilisés :
- Netmeeting
- Hyperterminal pour accéder à l'IOS du routeur (Internetwork Operating System)
- Serveur FTP
Configurations du Routeur CISCO
Utilisation de la console du routeur.
Pour configurer le routeur nous avons utilisé une des machines de la maquette comme console.
Nous avons donc créé une liaison physique à l'aide d'un câble DB9/RJ45 entre une des deux machines au niveau du port série (COM 2 par exemple) et le routeur au niveau de la sortie " console " ci-dessous.
Ensuite nous avons utilisé l'Hyperterminal de Windows pour établir une connexion.
Il est à noter qu'une fois la connexion établie, on est prêt maintenant à démarrer le routeur
Configurer les interfaces du routeur nécessaires.
Nous allons maintenant procéder à la configuration Deux des trois interfaces du routeurs :
Démarche :
Routeur> enable
Routeur# configure terminal
Routeur(conf)# interface FastEthernet 0/0
Routeur(conf-if)# ip adress 192.168.14.161 255.255.255.0
Routeur(conf-if)# no shutdown
Routeur(conf-if)# interface FastEthernet 0/1
Routeur(conf-if)# ip adress 192.168.14.193 255.255.255.0
Routeur(conf-if)# no shutdown
Pour les 2 machines, il ne faut pas oublier de choisir une adresse IP en concordance avec chaque interface crée pour que celles-ci se retrouvent dans le sous réseau approprié.
Sur chaque sous réseau, dans les propriétés de la machine, on fixe également l'adresse de la passerelle qui est l'adresse de l'interface appropriée du routeur.
Machine Internet :
Machine Interne :
Création d'une politique de qualité de service:
a. Filtrage des flux
Pour établir une qualité de service il faut tout d'abord sélectionner les flux qu'on veut différencier. Pour cela on utilise une certaine technique de filtrage disponible dans l'IOS du routeur qui est l'utilisation d'ACLs (Access Control List)
Une liste de contrôle d'accès est une collection d'instructions permettant d'autoriser ou de refuser des paquets en fonction d'un certain nombre de critères, tels que:
-L'adresse d'origine
-L'adresse de destination
-Le numéro de port.
-Les protocoles de couches supérieures
Il existe 3 types de liste de contrôle d'accès:
les ACLs standards,
les ACLs étendues et
les ACLs nommées.
Les ACLs standards utilisent des spécifications d'adresses simplifiées et autorisent ou refusent un ensemble de protocole.
C'est-à-dire en d'autres termes que l'on peut interdire par exemple à une machine l'accès à une autre machine ou à un autre réseau.
Les ACLs étendues utilisent des spécifications d'adresses plus complexes et autorisent ou refusent des protocoles précis.
Ce type d'ACL utilisent un filtrage bien plus spécifique - on peut selon nos besoins, interdire (ou permettre) des flux depuis et vers une autre machine (ou réseaux) suivant des critères tels :
- Le type de protocole de niveau 4 (en l'occurrence TCP ou UDP).
- Le numéro de port utilisé.
- Ou même le type de l'application (ftp,telnet .....).
Les ACLs nommées peuvent être soit standards, soit étendues; elles n'ont pour but que de faciliter la compréhension et de connaître la finalité de l'ACL.
Au moment de configurer les listes de contrôle d'accès il faut identifier chaque liste de protocole en lui attribuant un numéro unique.
Le numéro choisi pour identifier une liste de contrôle d'accès doit se trouver à l'intérieur d'une plage précise, valable pour le protocole.
Plage Protocole
1-99 IP Standard
100-199 IP Etendue
600-699 AppleTalk
800-899 IPX Standard
900-999 IPX Etendue
1000-1099 IPX Service Advertising Protocol
Tab 1.
Par exemple, si l'on affecte le numéro 30 à une ACL, cela induit le fait que cette ACL sera de type standard et concernera le trafic IP.
Tandis que le numéro 950 indiquera que cette ACL est de type étendue et pour le trafic IPX
Paramètres d'une ACL :
access-list numéro { permit ou deny } protocole source destination opérateur (numéro de port)
numéro : voir tableau ci-dessus
protocole : IP, TCP, UDP, ICMP, GRE, IGRP
source : adresse source
destination : adresse destination
opérateur : lt less than (plus petit que ),
gt greater than (plus grand que),
eq equal (egal à),
neq not equal (différent de )
numéro de port : le numéro de port de l'application
Dans notre cas le filtrage ce fait au niveau de l'application et par conséquent au niveau du numéro de port c'est pourquoi nous avons utilisé des ACLs de type étendues.
Lors d'une communication établie avec NetMeeting, nous avons utilisé la commande netstat dans une fenêtre ''cmd'', afin de connaître le port utilisé. Comme c'est un numéro fixé aléatoirement à chaque communication, nous avons recommencé ceci plusieurs fois afin d'avoir une gamme moyenne : numéro de port : de 1050 à 2000
Routeur# access-list 101 permit tcp any any range 1050 2000
access-list : commande pour la création d'un filtre.
101: numéro choisit correspondant à une ACL de type étendu (voir Tab.1)
permit: on permet le passage de ce type de trafic
tcp: pour indiquer que le protocole de niveau 4 est TCP.
any: adresse source (équivalent à tout le monde).
any: adresse destination (équivalent à tout le monde).
range: on donne la plage des numéros de ports.
Maintenant pour capturer le flux FTP on utilise les commandes:
Routeur# access-list 102 permit tcp any any eq ftp
Routeur# access-list 102 permit tcp any any eq ftp-data
La première ligne correspond à la capture à un filtrage des paquets correspondant au contrôle de transfert de données FTP (port 20)
La deuxième correspond aux flux de données FTP (port 21).
b. Classification du trafic
Après avoir établir le filtrage il faut classifier les différents flux et les mettre dans des groupes différents. Pour cela on utilise le système de classe disponible dans l'IOS du routeur.
Une classe de trafic contient trois éléments essentiels:
le nom de la classe,
une série de commandes match,
et comment évaluer ces commandes match.
Les commandes match sont utilisées pour spécifier divers critères de classification des paquets.
Les paquets sont vérifiés pour déterminer s'ils appartiennent ou non à ces critères spécifier par la commande match.
Si un paquet appartient à un de ces critères il sera alors considéré comme membre de cette classe et sera transféré suivant les spécifications de qualité de service indiqué dans une policy-map (sera expliqué par la suite).
En utilisant la classification des paquets on peut par la suite partitionner notre réseau en plusieurs niveaux de priorités ou en classes de services (class-map).
Paramètres des class-map
routeur(config)#class-map nom-de-la-classe
On associe un nom à une class-map pour mieux la désignée par la suite
routeur(config)#class-map match-all nom-de-la-classe
On spécifie que TOUS les critères doivent être vérifier pour que le paquet appartienne à la classe.
routeur(config)#class-map match-any nom-de-la-classe
On spécifie qu'AU MOINS un des critères doivent être vérifier pour que le paquet appartienne à la classe.
routeur(config-cmap)#match access-group numéro-de-l'ACL
On spécifie que le paquet doit vérifier l'ACL correspondante pour qu'il appartienne à la classe.
routeur(config-cmap)#match any
On spécifie que tous les paquets seront dans cette classe.
routeur(config-cmap)#match {destination ou source}-address mac adresse
On spécifie que le paquet doit vérifier l'adresse MAC source ou destination pour qu'il appartienne à cette classe.
routeur(config-cmap)#match input-interface nom-de-l'interface
On spécifie que le paquet doit vérifier l'interface d'entrée indiquer pour qu'il appartienne à la classe.
routeur(config-cmap)#match ip dscp valeur-du-ip-dscp
Pour l'utilisation de DiffServ on a la possibilité de spécifier la valeur du ip dscp entre 0 et 63 pour que le paquet appartienne à la classe.
routeur(config-cmap)#match ip precedence valeur-de-champs-TOS
3 bits du champs TOS dans l'entête ip forment l'IP precedence utilisé pour la qualité de service. Dans un paquet reçu, si la valeur de ce champ est égal à la valeur indiqué ici alors le paquet appartient à cette classe.
routeur(config-cmap)#match protocol protocole
On spécifie le protocole suivant lequel les paquets appartiennent à la classe
Dans notre cas on a utilisé les access-list déjà créer pour effectuer la répartition des différents flux dans différentes classes :
Routeur(conf)# class-map ftp
Routeur(conf-cmap)# match access-group 102
Routeur(conf-cmap)# exit
Routeur(conf)# class-map video
Routeur(conf-cmap)# match access-group 101
Routeur(conf-cmap)# exit
c . Création d'une politique de service
Maintenant qu'on a différencié le trafic on doit partager la bande passante de notre routeur.
C'est pourquoi on doit utiliser des cartes de priorités (policy-map)
C'est à partir du moment où on utilise les policy-map, qu'effectivement on met en place la Qualité de Service voulue.
Une policy-map contient trois éléments :
le nom de la police,
les classes associer et
les commandes de qualité de service
Paramètres des Policy-map
routeur(config)#policy-map nom-de-la-policy-map
On spécifie un nom pour la policy-map
routeur(config-pmap)#class nom-de-la-classe
On spécifie le nom de la classe sur laquelle on veut appliquer la politique de qualité de service
routeur(config-pmap-cmap)#bandwidth debit en kbps ou pourcentage
On spécifie la bande passante du routeur qu'on veut allouer à cette classe
routeur(config-pmap-cmap)#pritority en kbps ou en percentage
On spécifie pour la classe une bande passante avec un niveau de priorité élevé
Cette commande est en général utilisé pour le trafic temps réel.
Notre application :
routeur(conf)# policy-map QOSVIDEO
routeur(conf-pmap)# class ftp
routeur(conf-pmap-c)# bandwidth percent 10
routeur(conf-pmap-c)# exit
Routeur(conf-pmap)# class video
Routeur(conf-pmap-c)# bandwidth percent 50
Routeur(conf-pmap-c)# exit
De cette façon on a privilégié le trafic video par rapport au trafic ftp : on alloue 50% de la bande passante pour les flux video contre 10% pour les flux ftp.
d . Attachement de la politique à une interface
Aprés avoir céer une politique de service il faut l'appliquer sur une (ou les deux) interface(s) du routeur. Suivant le flux du trafic il est possible de l'attacher soit à l'interface entrante soit à l'interface sortante. Par exemple pour limiter les paquets arrivant de l'extérieur afin d'éviter la congestion du réseau internet on l'applique sur l'interface entrante.
Par contre pour avoir une certaine priorité d'accés vers l'exterieur (pour une visio-conférence) par exemple on l'applique sur l'interface sortante.
c'est la commande service-policy qui permet d'attacher une policy-map à une interface.
En général le choix de l'attachement de l'interface dépend de l'architecture du réseau et suivant le sens du trafic qu'on veut privilégié.
routeur(conf)# interface FastEthernet 0/0
routeur(conf-if)# service-policy output QOSVIDEO
e . Implémentation de DiffServ dans le routeur
DiffServ est utilisé pour établir une qualité de service End-to-End.
Une qualité de service End-to-End permet au réseau d'assurer lui même une QOS requise par un autre réseau.
Avec DiffServ on se base sur le DSCP (Differenciated Services Code Point)
Le DSCP est l'utilisation du champs TOS dans l'entête IP.
Pour cette exemple on peut s'imaginer dans un cas de réseau local dont l'interface attacher au routeur est l'interface qui reçoit le trafic. Et l'interface reliée vers l'extérieur est l'interface qui l'envoie.
L'interface qui reçoit le trafic :
1-Création des Access Control Lists
2-Création des classes.
3-Positionnement de la valeur du DSCP
1- Création des Access Control Lists :
access-list 101 permit tcp any any range 1050 2000 (traffic video NetMeeting)
access-list 102 permit tcp any any eq ftp (traffic de control ftp)
access-list 102 permit tcp any any eq ftp-data (traffic de données ftp)
access-list 103 permit tcp any any eq www (traffic web)
2- Création des classes :
class-map match-all video
match access-group 101
class-map match-all ftp
match access-group 102
class-map match-all web
match access-group 103
3- Positionnement de la valeur du DSCP
policy-map SETDSCP
class video
set ip dscp 46
class ftp
set ip dscp 22
class web
set ip dscp 26
L'interface qui envoie les données :
1- Création des classes
2- Allocation de la bande
1- Création des classes
class-map match-all priorite1
match ip dscp 46
class-map match-all priorite2
match ip dscp 22
class-map match-all priorite3
match ip dscp 26
2- Allocation de la bande
policy-map QoSVIDEO
class priorite1
bandwidth percent 50
class priorite2
bandwidth percent 25
class priorite3
bandwidth percent 20
Tests
Les tests que nous avons effectué :
a. Vérification de la configuration pour la mise ne place du réseau :
Après cette configuration terminée, on teste si notre réseau est correctement mis en place
Dans une fenêtre ''cmd'' on utilise la commande ping
- sur les interfaces des machines d'abord
- puis sur les interfaces du routeur
- et enfin on test du machine à une autre.
b. Création d'une congestion dans le réseau
On installe ensuite la WebCam qui est sur le port USB.
En redémarrant la machine, Windows la reconnaît automatiquement.
On lance NetMeeting pour établir une communication et faire transmettre du flux video entre les deux machines.
Les utilisateurs peuvent voir la même video.
L'image est de qualité égale des deux côtés à celle que peut offrir la caméra.
Après avoir téléchargé sur Internet un serveur FTP gratuit (BFTP Server) on regarde brièvement ses fonctionnalités.
On crée un utilisateur "spike" avec un mot de passe simple "spike" et l'attribution d'un accès à un répertoire pour qu'il puisse y déposer ou retirer des fichiers.
On essaie de générer un flux FTP avec de très gros fichiers (de l'ordre de 35 Mo).
Pour cela l'utilisateur Spike se connecte au serveur FTP via la machine Internet comme suit:
C:\
C:\ftp
ftp> open 192.168.14.194
ftp> Utilisateur (192.168.14.194) : spike
331 Please specify the password.
Mot de passe : ****
230 Login successful.
ftp> get grand_fichier.zip
On voit, pendant le transfert des gros fichiers, que la qualité de l'image video à fortement diminuée du côté machine Interne : apparition de pixels statiques, effet de saccades
On va donc faire en sorte que l'image ait une meilleure qualité.
Conclusion
La première partie de notre travail a surtout consisté à la recherche car il existe plusieurs façons d'établir une politique de Qualité de Service et d'apprendre les fonctionnalités que pouvait offrir le routeur.
Ce sujet nous a permis de rafraîchir et d'approfondir nos connaissances dans le domaine des réseaux. Mais il nous a aussi fait comprendre l'importance du dynamisme et de la coordination dans une équipe.
Notre deuxième partie a été donc de mettre en ?uvre notre décision à propos de cette politique.
Pour satisfaire le ''cahier des charges'' de départ, nous avons vu aussi qu'il faut savoir retomber sur nos pattes en prévoyant ou en élaborant par le biais de consultation fréquente au sein de l'équipe, d'autres solutions de mise en place d'un tel projet.
Le seul regret aura été de ne pas avoir pu mettre en ?uvre, par manque de moyens, la première solution que nous avions envisagée. En effet celle que nous avions choisie était celle qui utilisait l'architecture DiffServ mais pour cela il aurait fallut avoir plus de matériel afin de tester le dialogue entre les équipements (la maquette serait devenu alors très coûteuse).