- Traffic policing
-
Le Traffic policing, ou limitation du flux, consiste à vérifier que les flux réseau se conforment à un accord de service et à prendre les mesures pour faire respecter un tel contrat.
Les sources de données qui sont informées de l'existence d'un tel accord peuvent appliquer le traffic shaping (régulation de flux) pour faire en sorte que ce qu'elles envoient reste dans les limites de ce contrat. Les paquets échangés dépassant ce qui est prévu dans l'accord peuvent être immédiatement jetés, marqués comme étant en excès, ou laissés inchangés par le processus de limitation du flux. Le sort réservé aux données excédentaires est fonction de choix administratifs et des caractéristiques des données échangées.
Sommaire
Conséquences
Dans le cas où l'excédent est jeté, celui qui reçoit les données dont le volume a été ainsi limité constate une perte de paquets aux moments où le volume des flux a dépassé ce qui était prévu dans le contrat. Si la source ne limite pas son rythme d'émission (par exemple au moyen d'un mécanisme de retour d'information), cela continuera, et on pourra croire que la liaison est défectueuse ou qu'un autre facteur externe provoque des pertes de paquets aléatoires.
Dans le cas d'un protocole fiable, comme TCP par opposition à UDP, les paquets jetés ne seront pas acquittés par le récepteur et seront donc réémis par l'émetteur, ce qui augmentera encore le volume du flux échangé.
Le flux reçu, qui a été limité en route, se conformera en général à l'accord de service. Dans certains cas, le mécanisme de limitation peut introduire de la gigue.
Cas où l'émetteur utilise le contrôle de congestion
Lorsque l'on utilise un mécanisme de contrôle de congestion par retour d'information, comme celui de TCP, l'émetteur s'adapte en général assez vite au traffic policing statique. L'émission a tendance à se stabiliser à un rythme immédiatement inférieur à la limite imposée.
Il en résulte que les extrémités de la communication peuvent avoir du mal à distinguer du trafic ayant subi du shaping de trafic ayant subi du policing.
Cas d'ATM
Lorsque des cellules ATM sont éliminées alors qu'elles transportent du protocole IP, les conséquences sont particulièrement graves dans le cas de longs paquets.
En effet, les cellules ATM sont bien plus petites que les paquets IP, et la limitation de flux peut éliminer des cellules sans tenir compte des limites de paquets. Dans ce cas, la quantité totale de données éliminées sera répartie sur un grand nombre de paquets. Pratiquement tous les mécanismes de réassemblage de paquets réagissent en éliminant complètement le paquet correspondant, ce qui provoque un très grand nombre de pertes de paquets alors même que le contrat n'a été dépassé que de peu.
Procédé
La RFC 2475 décrit des éléments qui assurent le traffic policing tels que l'unité de mesure et l'unité d'élimination, ainsi qu'éventuellement une unité de marquage[1]. L'unité de mesure mesure le volume de données échangées et détermine si ce volume excède ou non les termes du contrat. Un exemple d'algorithme de mesure dans le cas d'ATM est GCRA). Quand le volume dépasse celui qui est prévu dans le contrat, il est décidé si l'on rejette une unité de données du protocole, ou, si le marquage est implémenté, si celle-ci doit être marquée et comment. Le marquage peut consister à lever un drapeau de congestion (comme le bit ECN de TCP ou le bit CLP d'ATM), ou à mettre en place un identifiant de classe de trafic (comme les bits Differentiated Services Code Point).
Dans les implémentations simples, le flux réseau est classé en deux catégories ou « couleurs » : conforme (vert) et en excès (rouge). La RFC 2697 propose un classement plus fin à l'aide de trois « couleurs[2] ». Dans ce document, le contrat est décrit au moyen de trois paramètres : le débit d'informations garanties (Committed Information Rate, CIR), la taille des rafales garanties (Committed Burst Size, CBS) et la taille des rafales en excès (Excess Burst Size, EBS). Un paquet est « vert » s'il ne dépasse pas le CBS, « jaune » s'il dépasse le CBS mais pas l'EBS et « rouge » sinon.
Le « marquage à trois couleurs simple débit » décrit dans la RFC 2697 permet des rafales temporaires. Les rafales sont autorisées lorsque la ligne était sous-utilisée auparavant. Un algorithme plus prévisible est décrit dans la RFC 2968 qui propose un « marquage à trois couleurs double débit[3] ». La RFC 2968 définit un nouveau paramètre, le débit d'informations en pic (Peak Information Rate, PIR).
Implémentations
Sur de l'équipement Cisco, le policing et le shaping sont tous deux assurés au moyen de l'algorithme du seau de jetons (token bucket algorithm)[4].
Le traffic policing dans les réseaux ATM est connu sous les noms Usage Parameter Control (UPC) et Network Parameter Control (NPC)[5]. Le réseau peut également jeter des flux non conformes à l'aide du Priority Control.
Le traffic policing suppose de tenir à jour des statistiques numériques et des mesures de chaque flux réseau, mais ne demande pas de gérer des mémoires tampons volumineuses. Le traffic policing est donc bien plus facile à implémenter que le traffic shaping qui, lui, a besoin de files d'attente.
Une alternative : le contrôle d'admission de nouvelles connexions
Les réseaux orientés connexion (par exemple les réseaux ATM) permettent de faire du contrôle d'admission des connexions (connection admission control, CAC) s'appuyant sur des accords de service. Dans le contexte de la voix sur IP (VoIP), cette pratique est également connue sous le nom de contrôle d'admission des appels (Call Admission Control, CAC)[6].
Une application qui souhaite utiliser un réseau orienté connexion pour transporter des données doit d'abord demander une connexion (via un protocole de signalisation, par exemple Q.2931). Cela implique d'informer le réseau des caractéristiques du flux et de la qualité de service (Quality of Service, QoS) nécessaires à l'application[7]. Ces informations sont comparées à l'accord de service. Si la demande de connexion est acceptée, l'application est autorisée à utiliser le réseau pour transporter des données.
Cette fonction protège les ressources réseau contre les connexions mal intentionnées et assure que chaque connexion se conforme à l'accord de service.
La différence entre le CAC et le contrôle de trafic est que le CAC est un contrôle a priori (avant que la connexion ne débute) alors que le traffic policing est un contrôle a posteriori (quand la transmission est en cours).
Voir aussi
Articles connexes
Références
- IETF RFC 2475 "An Architecture for Differentiated Services" section 2.3.3 - definitions of meter, dropper and marker
- IETF RFC 2697 "A Single Rate Three Color Marker"
- IETF RFC 2698 "A Two Rate Three Color Marker"
- What is a token bucket? sur le site de Cisco
- Hiroshi Saito, Teletraffic Technologies in ATM Networks, Artech House, 1993. ISBN 0-89006-622-1.
- VoIP Call Admission Control sur le site de Cisco
- Ferguson P., Huston G., Quality of Service: Delivering QoS on the Internet and in Corporate Networks, John Wiley & Sons, Inc., 1998. ISBN 0-471-24358-2.
Wikimedia Foundation. 2010.
