Type de service - Type of service
Le champ type de service ( ToS ) est le deuxième octet de l' en-tête IPv4 . Il a eu divers objectifs au fil des ans et a été défini de différentes manières par cinq RFC .
Avant la redéfinition, le champ ToS pouvait spécifier la priorité d'un datagramme et demander une route pour un service à faible latence, à haut débit ou hautement fiable. Sur la base de ces valeurs ToS, un paquet serait placé dans une file d'attente sortante prioritaire ou emprunterait une route avec une latence, un débit ou une fiabilité appropriés. Dans la pratique, le domaine de la ToS n'a jamais été largement utilisé en dehors des réseaux du département américain de la Défense. Cependant, de nombreux travaux expérimentaux, de recherche et de déploiement se sont concentrés sur la manière d'utiliser ces huit bits, ce qui a abouti à la définition actuelle du champ DS .
La redéfinition moderne du champ ToS, également utilisé pour le champ Classe de trafic dans les paquets IPv6 , est un champ de services différenciés de 8 bits (champ DS) qui se compose d'un champ DSCP ( Differentiated Services Code Point ) de 6 bits et d'un 2- bit Champ de notification explicite d'encombrement (ECN). Alors que les services différenciés sont quelque peu rétrocompatibles avec ToS, ECN ne l'est pas.
Histoire
Le champ Type de service dans l'en-tête IP a été initialement défini dans la RFC 791 , et a été interprété pour la priorité IP et ToS depuis. La définition a été largement dérivée d'une spécification du DoD américain JANAP-128, qui définit la priorité des messages. Il a défini un mécanisme pour attribuer une priorité à chaque paquet IP, ainsi qu'un mécanisme pour demander un traitement spécifique tel qu'un débit élevé, une fiabilité élevée ou une faible latence, etc. Dans la mise à jour RFC 1349 , le bit de coût monétaire est introduit (ce bit était auparavant marqué «Réservé pour une utilisation future»). La section 2.4 de la RFC 1583 (OSPFv2) présente une méthode de routage compatible ToS.
En pratique, seule la partie IP Precedence du champ a jamais été utilisée en dehors des réseaux US DoD: plus la valeur du champ IP Precedence est élevée, plus la priorité du paquet IP est élevée. Certains réseaux américains du DoD ont utilisé le bit de retard pour la sélection d'itinéraire entre les chemins de câbles océaniques et les chemins de communication par satellite (SATCOM) lorsque les deux chemins existaient. IPv6 n'a jamais eu de champ ToS «traditionnel» de type IPv4, en partie parce que les auteurs étaient au courant des efforts de DiffServ lors de sa rédaction ( RFC 2460, section 7).
Dans la RFC 2474, la définition de ce champ entier a été modifiée. Il est maintenant appelé le champ "DS" (Differentiated Services, "DiffServ") et les 6 bits supérieurs contiennent une valeur appelée "DSCP" (Differentiated Services Code Point). Les 3 bits supérieurs de DS maintiennent la compatibilité avec la priorité IP. Depuis la RFC 3168 , les deux bits restants (les deux bits les moins significatifs) sont utilisés pour la notification explicite d'encombrement.
La RFC 8622 a ajouté un DS à moindre effort (LE) pour le trafic qui peut être préempté par un autre trafic (trafic au mieux). Il est destiné au trafic d'arrière-plan de faible priorité, comme les transferts de données en masse avec une faible priorité dans le temps.
Allocation
Priorité et ToS
Avant son abandon, le champ Type de service était défini comme suit à partir de la RFC 791 :
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| Priorité | Type de service | Inutilisé (0) | |||||
La priorité était un champ de 3 bits qui traite les paquets de haute priorité comme plus importants que les autres paquets. Si un routeur est encombré et doit rejeter certains paquets, il rejettera d'abord les paquets ayant la priorité la plus basse. Bien que le champ de priorité fasse partie de la version IP 4, il n'a jamais été utilisé.
La RFC 1349 a introduit un champ "lowcost" supplémentaire. Les quatre bits ToS disponibles deviennent maintenant:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| (Priorité IP) | faible retard | débit | fiabilité | faible coût ( RFC 1349 ) | (Doit être zéro) | ||
La dénomination ici suit la convention des systèmes d'exploitation Unix. La RFC 1349 et la RFC 1060 ne montrent que des exemples d'un bit utilisé à la fois pour les valeurs par défaut de l'application, bien que la RFC 791 mentionne qu'au plus deux des trois indications dont elle dispose doivent être définies de manière nominale. Une de ces utilisations est connue de mod_iptos.
Parce que les trois derniers bits ont traversé de nombreuses définitions avant la RFC 2474 (voir ci-dessous), la documentation et les implémentations peuvent être déroutantes et contradictoires.
DSCP et ECN
La RFC 2474 (qui a été publiée en décembre 1998) a réservé les six premiers bits du champ DS (ou IPv4 ToS) pour le point de code de services différenciés (DSCP), et la RFC 3168 a réservé les deux derniers bits pour la notification explicite d'encombrement .
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| DSCP | ECN | ||||||
DSCP définit un sélecteur de classe (CS) nommant chaque valeur qu'il définit, reflétant ce qui aurait été interprété comme la priorité IP si l'on suivait l'ancienne spécification:
| Nom DSCP | Valeur du champ DS (décembre) | Priorité IP (description) |
|---|---|---|
| CS0 | 0 | 0: meilleur effort |
| LE | 1 | n / A |
| CS1, AF11-13 | 8,10,12,14 | 1: priorité |
| CS2, AF21-23 | 16,18,20,22 | 2: immédiat |
| CS3, AF31-33 | 24,26,28,30 | 3: Flash - principalement utilisé pour la signalisation vocale |
| CS4, AF41-43 | 32,34,36,38 | 4: remplacement du flash |
| CS5, EF | 40,46 | 5: critique - principalement utilisé pour la voix RTP |
| CS6 | 48 | 6: Contrôle interréseau |
| CS7 | 56 | 7: Contrôle du réseau |
Nomenclature DSCP:
- CS
- Sélecteur de classe ( RFC 2474 )
- AFxy
- Transfert assuré (x = classe, y = priorité de suppression) ( RFC 2597 )
- EF
- Transfert accéléré ( RFC 3246 )
- LE
- Moins d'effort ( RFC 8622 )
Le tableau ci-dessus, avec des valeurs individuelles écrites pour les valeurs de l'ensemble du champ ToS (à ne pas confondre avec la partie 5 bits peu utilisée):
| DSCP déc | Valeur ToS | IP Prec |
|---|---|---|
| 0 | 0 | 0 |
| 8 | 32 | 1 |
| dix | 40 | 1 |
| 14 | 56 | 1 |
| 18 | 72 | 2 |
| 22 | 88 | 2 |
| 24 | 96 | 3 |
| 28 | 112 | 3 |
| 34 | 136 | 4 |
| 36 | 144 | 4 |
| 38 | 152 | 4 |
| 40 | 160 | 5 |
| 46 | 184 | 5 |
| 48 | 192 | 6 |
| 56 | 224 | 7 |
Remarque: Dans le tableau ci-dessus, ToS est affiché au format décimal. Cependant, de nombreux routeurs expriment ToS au format hexadécimal.
Exemple: interprétation mixte
Commençons par une priorité IP de 1, ou 0b001 en binaire. Le champ ToS entier serait alors 001 00000 , en supposant que les 5 bits inutilisés sont nuls. Le DSCP peut être interprété par resegmenting to 001000 00 , où 001000 = 8 est la valeur DSCP.
Support logiciel
Bien que peu utilisée, les définitions ToS IP sont largement connues dans netinet/ip.h de type Unix ou Unix systèmes d' exploitation comme IPTOS_FIELDNAME macros. Le champ "lowcost" est commenté dans OpenBSD en raison de son utilisation plus récente pour indiquer le support ECN. Des restes de l'ancienne terminologie RFC 1349 peuvent être trouvés dans Transmission 2.93 ainsi que d'autres outils qui prennent en charge la définition de ce champ.
Un ancien module Apache "mod_iptos", une fois emballé dans Ubuntu, note qu'une manière d'utiliser plusieurs bits d'option RFC 1349 ensemble est apparue après un certain temps.
Voir également
Les références
Lectures complémentaires
- John Evans, Clarence Filsfils (2007). Déploiement de la qualité de service IP et MPLS pour les réseaux multiservices: théorie et pratique . Morgan Kaufmann. ISBN 978-0123705495 .
