1) Historiquement, la Qualité de Service est née avec le champ ToS de l'en-tête IPv4 (cf RFC791). Codé sur un octet, le champ ToS embarque deux valeurs :- precedence (3 bits),
- type of service (3 bits + 00).
ToS a été rarement utilisé en pratique. Essentiellement parce que chacun en faisait un peu ce qu'il en voulait. On en trouve encore quelques vestiges chez Cisco : OSPF/RIP/EIGRP et les flux Telnet de/vers un routeur sont marqués avec une IP Precedence 110 (Internetwork Control).
Alors on a fait un peu de ménage pour rationaliser la QoS... En 1998, les RFC 2474 et 2475 ont posé les fondements de DSCP (DiffServ Code Points). Grosso modo, on a réutilisé l'octet réservé à ToS et on a redistribué les cartes. Au lieu d'avoir 3 bits de precedence et 5 bits de type of service, on a créé le DSCP field (6 bits) et l'ECN field (2 bits). Le passage de la precedence (qui n'offrait que 8 valeurs possibles) vers DSCP a essentiellement permis d'avoir plus de granularité et il existe une matrice de correspondance (non bijective évidemment) entre valeurs de DSCP et d'IP Precedence :
1 2 3 4 5 6 7 8
| 0 0 :Best Effort
8,10,12,14 1 :Priority
16,18,20,22 2 :Immediate
24,26,28,30 3 :Flash/voice signaling
32,34,36,38 4 :Flash Override
40,46 5 :Critical
48 6 :Internet
56 7 :Network |
Voilà pour ToS et DSCP... Comme tu peux constater, tout se passe dans l'en-tête IP.
2) Parce qu'il existe aussi une façon d'implémenter la QoS dans la couche OSI MAC (Medium Access Control). C'est l'objectif de CoS/802.1p (c'est la même chose).
CoS (Class of Service) est un champ codé sur 3 bits qui se trouve dans l'en-tête Ethernet **si et seulement si** il existe en plus un en-tête 802.1q dans cette trame Ethernet. En d'autres termes, CoS n'est applicable que sur des trames "tagguées" au sens 802.1q.
L'exemple classique, c'est la ToIP. Parce que sans la CoS, un switch congestionné n'aurait aucun moyen de savoir quel traffic est prioritaire par rapport à un autre. Ce qui explique d'ailleurs pourquoi on parle toujours de "VLAN Voice". Et de façon générale, les flux temps réel doivent impérativement être taggués pour tirer bénéfice du champ CoS.
Une particularité de CoS, et ça n'est pas un hasard, c'est qu'il est codé sur 3 bits comme l'IP Precedence.
Ce qui signifie qu'un routeur évolué est capable de réécrire le champ DSCP en fonction du champ CoS, reflétant ainsi la QoS L2 niveau MAC vers la couche IP. Ce qui est intéressant lorsque des trames Ethernet CoS/802.1p doivent traverser un réseau de transit IP "L3 pur". On préserve ainsi la QoS. Dans l'IOS Cisco, la commande 'show mls qos maps' permet de visualiser la matrice de correspondance entre valeurs CoS et DSCP.
3) Dernier point concernant la QoS, que ce soit ToS/DSCP ou CoS/802.1p... La QoS n'a de réel intérêt que si elle configurée de bout-en-bout. Le marquage DSCP/CoS permet de forcer/contrôler le comportement du switch/routeur qui traite le paquet (on parle de PHB, Per Hop Behavior). Si, durant le transit entre source et destination, un switch/routeur n'est pas correctement configuré, la QoS ne servira pas à grand chose. C'est typiquement le cas des flux qui transitent dans l'Internet. Tu auras beau mettre la plus haute priorité à tes paquets, ton ISP fera un reset du DSCP de chaque paquet entrant dans son infra. Ce qui est un peu normal... Parce que sinon, j'enverrais tous mes paquets IP depuis ma machine Linux en Express Forwarding (EF) pour faire croire aux ISP que c'est de la voix.
Steph
Partager