Class of Service

La Class of Service (CoS), ou classe de service, est, dans les réseaux informatiques et les télécommunications, un mécanisme de différenciation du trafic consistant à regrouper des flux dans des classes de traitement. Ces classes permettent d'appliquer des priorités ou des politiques distinctes selon les exigences des applications, par exemple en matière de latence, de gigue, de perte de paquets ou de bande passante.

Le terme est utilisé de manière variable selon les contextes. Dans un sens large, il renvoie à la classification du trafic et à son traitement différencié dans le cadre de la qualité de service (QoS). Dans un sens plus restreint, notamment dans les réseaux Ethernet, il désigne souvent le marquage de priorité de couche 2 associé au champ Priority Code Point (PCP) de la norme IEEE 802.1Q[1]. Dans les réseaux IP modernes, la notion est généralement articulée avec l'architecture DiffServ, qui repose sur le marquage des paquets et leur traitement par classes de service[2].

Définition et terminologie

Une classe de service regroupe des flux réseau présentant des caractéristiques ou des exigences similaires. Les flux de voix sur IP, de visioconférence, de signalisation réseau, de transfert de fichiers ou de sauvegarde ne réagissent pas de la même manière à la congestion : certains sont sensibles au délai et à la gigue, tandis que d'autres tolèrent un délai plus élevé mais nécessitent un débit important. La CoS permet donc d'identifier ces flux et de leur associer un traitement adapté.

La qualité de service est l'ensemble des mécanismes permettant de gérer la performance d'un réseau : classification, marquage, mise en file d'attente, ordonnancement, lissage, limitation de débit ou évitement de congestion. La CoS est souvent considérée comme l'une des composantes de cette QoS, centrée sur le regroupement du trafic en classes et, selon les cas, sur le marquage associé[3],[4].

La RFC 4594[5] définit une classe de service comme un ensemble de trafic nécessitant des caractéristiques déterminées de délai, de perte et de gigue. Elle précise également qu'un réseau n'implémente généralement qu'un nombre limité de classes réellement utiles, plutôt que toutes les valeurs théoriquement disponibles dans les champs de marquage[6].

Principes généraux

Le fonctionnement de la CoS repose sur trois étapes principales : la classification, le marquage et le traitement différencié.

La classification consiste à identifier un flux selon des critères comme l'adresse IP source ou destination, le port de transport, le protocole, l'application, l'interface d'entrée ou une marque déjà présente dans l'en-tête. Le marquage consiste ensuite à inscrire une valeur dans un champ prévu à cet effet, par exemple le PCP en Ethernet, le DSCP en IP ou le champ Traffic Class en MPLS. Enfin, le traitement différencié applique à chaque classe une politique particulière : priorité plus élevée, file dédiée, limitation de débit, rejet préférentiel ou protection contre la congestion.

La CoS ne crée pas de capacité réseau supplémentaire. Elle permet seulement de répartir différemment les ressources disponibles. Son efficacité dépend donc de la capacité du réseau, de la cohérence du marquage et de la configuration des équipements traversés.

Mécanismes de marquage

Couche 2 : IEEE 802.1Q et 802.1p

Dans les réseaux Ethernet, la priorité de couche 2 est portée par le champ Priority Code Point (PCP) de l'étiquette IEEE 802.1Q.

Schéma montrant l'insertion de l'étiquette IEEE 802.1Q dans une trame Ethernet et la position du champ PCP dans le TCI.
Structure d'une trame Ethernet avec étiquette IEEE 802.1Q. Le champ PCP, codé sur 3 bits dans le TCI, indique une priorité de couche 2 utilisée dans les mécanismes de classe de service.

Ce champ occupe 3 bits et permet donc de représenter 8 valeurs de priorité, numérotées de 0 à 7[1].

Le terme IEEE 802.1p est couramment utilisé pour désigner ce mécanisme de priorité, bien qu'il ne corresponde plus, dans les documents modernes, à une norme autonome séparée. Il est intégré à la norme IEEE 802.1Q relative aux réseaux locaux virtuels (VLAN)[1].

Les valeurs PCP sont souvent associées aux usages suivants, même si leur interprétation exacte peut varier selon les constructeurs et les politiques d'administration du réseau :

Valeurs courantes du champ PCP IEEE 802.1Q
Valeur PCPUsage courant
0Best effort ; trafic par défaut
1Trafic de fond ou de faible priorité
2Trafic avec effort supérieur au trafic de fond
3Applications critiques
4Vidéo ou trafic interactif sensible au délai
5Voix ou trafic temps réel
6Contrôle interréseau
7Contrôle réseau

Ce marquage est limité au domaine de couche 2 dans lequel les trames Ethernet conservent leur étiquette VLAN. Lorsqu'un paquet traverse un routeur ou sort du domaine Ethernet marqué, l'information PCP peut être perdue si elle n'est pas explicitement traduite vers un marquage de couche 3, comme le DSCP.

Couche 3 : DSCP et IP Precedence

Dans les réseaux IP, le principal mécanisme de marquage est le Differentiated Services Code Point (DSCP), défini par la RFC 2474[7]. Le DSCP occupe les 6 premiers bits du champ DS de l'en-tête IPv4 ou du champ Traffic Class de l'en-tête IPv6[8]. Les 2 bits restants sont utilisés pour l'Explicit Congestion Notification (ECN), défini par la RFC 3168[9][10].

Le DSCP permet 64 valeurs possibles. Les principales familles de comportements sont :

  • Default Forwarding : traitement par défaut, généralement associé au trafic best effort ;
  • Class Selector (CS0 à CS7) : valeurs assurant une compatibilité avec l'ancien champ IP Precedence ;
  • Assured Forwarding (AF) : ensemble de classes définies par la RFC 2597[11], combinant plusieurs classes de service avec plusieurs niveaux de priorité de rejet[12] ;
  • Expedited Forwarding (EF) : comportement destiné aux flux nécessitant un délai, une gigue et une perte faibles, défini par la RFC 3246[13][14] ;
  • Voice-Admit : codepoint destiné au trafic voix admis par contrôle de capacité, défini par la RFC 5865[15][16] ;
  • Lower-Effort (LE) : comportement de priorité inférieure au best effort, défini par la RFC 8622[17][18].

Le champ DSCP est plus adapté que le PCP pour le transport de l'information de classe entre routeurs IP, car il est présent dans l'en-tête IP et peut donc être conservé au-delà d'un simple domaine Ethernet.

MPLS Traffic Class

Dans les réseaux MPLS, la différenciation de service peut être portée par le champ de 3 bits situé dans l'entrée de pile d'étiquettes MPLS. Ce champ était historiquement appelé EXP. La RFC 5462[19] a renommé ce champ en Traffic Class (TC), afin d'éviter l'idée erronée d'un champ expérimental[20].

La RFC 3270[21] définit la prise en charge de DiffServ dans les réseaux MPLS. Elle décrit notamment la manière dont les comportements DiffServ peuvent être transportés dans un domaine MPLS, soit au moyen du champ TC, soit par l'association entre l'étiquette MPLS et une classe de service[22].

Comme le champ TC ne comporte que 3 bits, il ne peut représenter que 8 valeurs. Les correspondances entre DSCP, PCP et MPLS TC doivent donc être définies par des politiques de mappage aux frontières du domaine MPLS.

Mise en correspondance entre couches

Un même flux peut traverser plusieurs domaines utilisant des mécanismes de marquage différents. Par exemple, un paquet peut être marqué en PCP dans un réseau Ethernet, en DSCP dans un réseau IP, puis en TC dans un réseau MPLS. Les équipements réseau effectuent alors des opérations de mappage entre ces valeurs.

Un exemple courant consiste à traduire une priorité PCP de couche 2 en valeur DSCP lorsqu'un paquet entre dans un domaine IP, puis à traduire ce DSCP en valeur MPLS TC lorsqu'il entre dans un cœur MPLS. En sortie du domaine, l'opération inverse peut être réalisée afin de préserver une cohérence de traitement.

Ces correspondances ne sont pas universelles. Elles dépendent des politiques de l'opérateur, de l'entreprise ou du domaine administratif concerné. La RFC 9435[23] rappelle que les valeurs DSCP peuvent être modifiées, effacées ou remappées à la frontière des domaines réseau, ce qui limite la portée d'un marquage supposé de bout en bout[24].

Traitement différencié

Une fois le trafic classifié et marqué, les équipements réseau peuvent appliquer plusieurs mécanismes complémentaires.

La mise en file d'attente consiste à placer les paquets dans des files différentes selon leur classe. Certaines files peuvent être servies en priorité stricte, tandis que d'autres reçoivent une part pondérée de la capacité disponible. Des mécanismes comme le Weighted Fair Queuing (WFQ), le Weighted Round Robin (WRR), le Class-Based Weighted Fair Queuing (CBWFQ) ou le Low Latency Queuing (LLQ) sont utilisés dans de nombreux équipements réseau.

Le lissage du trafic, ou shaping, consiste à retarder certains paquets afin de maintenir le trafic sous un débit cible. Le contrôle de débit, ou policing, consiste au contraire à rejeter ou remarquer les paquets qui dépassent un profil défini. Les mécanismes d'évitement de congestion, comme RED ou WRED, peuvent supprimer certains paquets avant la saturation complète d'une file afin de limiter la congestion.

La RFC 3290[25] propose un modèle fonctionnel des routeurs DiffServ, comprenant notamment les classifieurs, compteurs, marqueurs, files, ordonnanceurs et mécanismes de suppression de paquets[26].

Architectures de qualité de service

Services intégrés

Le modèle des services intégrés (IntServ) est défini par la RFC 1633[27]. Il repose sur l'idée de réserver explicitement des ressources pour des flux déterminés, notamment au moyen du protocole RSVP, défini par la RFC 2205[28][29],[30].

Ce modèle permet des garanties plus strictes, mais il nécessite de maintenir un état par flux dans les équipements réseau. Cette contrainte limite son passage à l'échelle dans les grands réseaux IP[31].

Services différenciés

Le modèle des services différenciés (DiffServ) est défini par la RFC 2475[32]. Contrairement à IntServ, il ne maintient pas un état pour chaque flux dans le cœur du réseau. Les paquets sont marqués à l'entrée d'un domaine, puis traités à chaque saut selon un comportement appelé Per-Hop Behavior (PHB)[2].

DiffServ est devenu le modèle dominant pour la QoS dans les réseaux IP d'entreprise et d'opérateur, car il agrège les flux en classes plutôt que de gérer chaque flux individuellement. Cette approche est plus simple à faire évoluer dans les grands réseaux.

Cas d'usage

La Class of Service est utilisée dans de nombreux environnements où plusieurs types de trafic partagent une même infrastructure.

La voix sur IP est l'un des cas les plus classiques. Elle nécessite un délai faible, une gigue limitée et un faible taux de perte. Elle est donc souvent associée à des classes de priorité élevée, comme EF ou Voice-Admit dans les environnements DiffServ[14],[16].

La visioconférence, le streaming interactif et certains flux multimédias peuvent également bénéficier d'un traitement différencié, en particulier lorsque la congestion réseau risque d'entraîner des interruptions visibles ou audibles. Les applications transactionnelles critiques, les systèmes de supervision, les flux de contrôle réseau ou les applications industrielles peuvent aussi recevoir des classes spécifiques.

Dans les réseaux d'opérateurs, la CoS permet de mutualiser une infrastructure tout en proposant plusieurs niveaux de service. Elle est notamment utilisée dans les réseaux MPLS, les VPN d'entreprise, les réseaux de transport Ethernet, les architectures SD-WAN et certains environnements SASE.

Limites et enjeux de déploiement

La CoS ne garantit pas automatiquement une qualité de service de bout en bout. Un marquage n'a de valeur que si les équipements traversés le reconnaissent et appliquent une politique cohérente. Lorsqu'un paquet passe d'un domaine administratif à un autre, son marquage peut être conservé, modifié ou supprimé[24].

La sécurité du marquage constitue également un enjeu important. Un hôte mal configuré ou malveillant peut marquer son propre trafic comme prioritaire afin d'obtenir un meilleur traitement. Les équipements de bordure d'un domaine doivent donc pouvoir vérifier, supprimer ou réécrire les marquages non fiables. L'architecture DiffServ prévoit explicitement ce rôle de conditionnement du trafic aux frontières du domaine[2].

Les tunnels réseau compliquent aussi le traitement de la CoS. Lorsqu'un paquet est encapsulé dans un tunnel GRE, IPsec ou IP-in-IP, les valeurs de marquage peuvent devoir être copiées, traduites ou reconstruites entre l'en-tête interne et l'en-tête externe. La RFC 2983[33] analyse précisément ces interactions entre DiffServ et les tunnels IP[34].

Enfin, le chiffrement réduit parfois la capacité des équipements intermédiaires à classifier finement le trafic. Avec des protocoles comme QUIC, une grande partie des informations de transport est chiffrée, ce qui limite l'inspection par le réseau. Le traitement fondé sur les champs visibles, comme le DSCP ou les informations d'en-tête externes, reste toutefois possible[35].

Voir aussi

Articles connexes

Liens externes

Notes et références

  1. 1 2 3 (en) « IEEE 802.1p Priority Levels », sur Microsoft Learn (consulté le ).
  2. 1 2 3 (en) S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, « RFC 2475 — An Architecture for Differentiated Services », sur RFC Editor, (consulté le ).
  3. ↑ (en) « How Class of Service Manages Congestion and Controls Service Levels in the Network », sur Juniper Networks (consulté le ).
  4. ↑ (en) « Class of service », sur IBM Documentation (consulté le ).
  5. ↑ (en) Request for comments no 4594
  6. ↑ (en) J. Babiarz, K. Chan et F. Baker, « RFC 4594 — Configuration Guidelines for DiffServ Service Classes », sur RFC Editor, (consulté le ).
  7. ↑ (en) Request for comments no 2474
  8. ↑ (en) K. Nichols, S. Blake, F. Baker et D. Black, « RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers », sur RFC Editor, (consulté le ).
  9. ↑ (en) Request for comments no 3168
  10. ↑ (en) K. Ramakrishnan, S. Floyd et D. Black, « RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP », sur RFC Editor, (consulté le ).
  11. ↑ (en) Request for comments no 2597
  12. ↑ (en) J. Heinanen, F. Baker, W. Weiss et J. Wroclawski, « RFC 2597 — Assured Forwarding PHB Group », sur RFC Editor, (consulté le ).
  13. ↑ (en) Request for comments no 3246
  14. 1 2 (en) B. Davie, A. Charny, J. C. R. Bennett, K. Benson, J. Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu et D. Stiliadis, « RFC 3246 — An Expedited Forwarding PHB », sur RFC Editor, (consulté le ).
  15. ↑ (en) Request for comments no 5865
  16. 1 2 (en) F. Baker, J. Polk et M. Dolly, « RFC 5865 — A Differentiated Services Code Point for Capacity-Admitted Traffic », sur RFC Editor, (consulté le ).
  17. ↑ (en) Request for comments no 8622
  18. ↑ (en) R. Bless, « RFC 8622 — A Lower-Effort Per-Hop Behavior for Differentiated Services », sur RFC Editor, (consulté le ).
  19. ↑ (en) Request for comments no 5462
  20. ↑ (en) L. Andersson et R. Asati, « RFC 5462 — Multiprotocol Label Switching Label Stack Entry: EXP Field Renamed to Traffic Class Field », sur RFC Editor, (consulté le ).
  21. ↑ (en) Request for comments no 3270
  22. ↑ (en) F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Väänänen, R. Krishnan, P. Cheval et J. Heinanen, « RFC 3270 — MPLS Support of Differentiated Services », sur RFC Editor, (consulté le ).
  23. ↑ (en) Request for comments no 9435
  24. 1 2 (en) A. Custura, G. Fairhurst et T. Jones, « RFC 9435 — Considerations for Assigning a New Recommended DiffServ Code Point », sur RFC Editor, (consulté le ).
  25. ↑ (en) Request for comments no 3290
  26. ↑ (en) Y. Bernet, S. Blake, D. Grossman et A. Smith, « RFC 3290 — An Informal Management Model for Diffserv Routers », sur RFC Editor, (consulté le ).
  27. ↑ (en) Request for comments no 1633
  28. ↑ (en) Request for comments no 2205
  29. ↑ (en) R. Braden, D. Clark et S. Shenker, « RFC 1633 — Integrated Services in the Internet Architecture: an Overview », sur RFC Editor, (consulté le ).
  30. ↑ (en) R. Braden, L. Zhang, S. Berson, S. Herzog et S. Jamin, « RFC 2205 — Resource ReSerVation Protocol, Version 1 Functional Specification », sur RFC Editor, (consulté le ).
  31. ↑ (en) G. Huston, « RFC 2990 — Next Steps for the IP QoS Architecture », sur RFC Editor, (consulté le ).
  32. ↑ (en) Request for comments no 2475
  33. ↑ (en) Request for comments no 2983
  34. ↑ (en) D. Black, « RFC 2983 — Differentiated Services and Tunnels », sur RFC Editor, (consulté le ).
  35. ↑ (en) M. Kühlewind et B. Trammell, « RFC 9312 — Manageability of the QUIC Transport Protocol », sur RFC Editor, (consulté le ).
  • icône décorative Portail de l’informatique
  • icône décorative Portail des télécommunications
Cet article est issu de Wikipédia. Sauf mention contraire, le texte est disponible sous Creative Commons Attribution-Share Alike 4.0. Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.