SERVICE ET DE CONTROLE DE TRAFIC SOUS LINUX
EmmanuelLo hin
1 er
1 QUALITE DE SERVICE DANS L'INTERNET 5 1.1 Avant propos . . . 5 1.2 Introdu tion . . . 5 1.3 Le modèle Intserv /RSVP . . . 6 1.3.1 RSVP . . . 7 1.4 Le modèle Diserv . . . 7 1.4.1 Ar hite ture Diserv . . . 7
1.4.2 Classi ationet onditionnement dutra . . . 9
1.4.3 LesPHB . . . 10
2 GESTION DES FILES & ORDONNANCEMENTS 11 2.1 Présentation . . . 11
2.2 Introdu tion . . . 11
2.3 Les ordonnan eurs . . . 12
2.3.1 FirstIn FirstOut (FIFO) . . . 12
2.3.2 PriorityQueuing . . . 12
2.3.3 RoundRobin . . . 13
2.3.4 Weighted FairQueuing. . . 13
2.3.5 Sto hasti FairQueuing . . . 14
2.4 Les Ar hite tures d'ordonnan ements . . . 14
2.4.1 Clark-Shenker-Zhang . . . 14
2.4.2 ClassBased Queuing . . . 14
2.5 Politiquede tra . . . 17
2.5.1 Lissagedu tra . . . 17
2.5.1.1 LeakyBu ket. . . 17
2.5.1.2 Token Bu ket. . . 17
2.5.2 Prévention dela ongestion . . . 17
2.5.2.1 Random EarlyDete tion . . . 18
2.5.2.2 WeightedRandomEarly Dete tion . . . 18
3 LINUX ET LA QoS 19 3.1 La ou he réseau dunoyau Linux . . . 19
3.1.2 So ket Buers. . . 19
3.1.3 Transmission des paquetsIP. . . 19
3.1.4 Leséléments de QoS . . . 20
3.2 Con guration . . . 21
3.3 Implémentation du ontr le de tra . . . 21
3.3.1 Introdu tion . . . 21
3.3.2 Prin ipe de base . . . 22
3.3.2.1 Le ontr le detra sousLinux. . . 22
3.4 Prin ipe des led'attentes . . . 23
3.4.1 Fon tionnement de la led'attente, étape par étape: . . . 27
3.5 Prin ipe des lasses . . . 29
3.5.1 Fon tionnement de l'instan iation en lasse despaquets . . . 31
3.6 Prin ipe des ltresou lassi ers . . . 31
3.7 Prin ipe de politiquede tra (poli ing) . . . 33
4 MISE EN OEUVRE DE LA QoS 35 4.1 Présentation dela plateformede test . . . 35
4.2 LinuxTra Control :t . . . 35
4.2.1 Installationet on guration . . . 35
4.2.2 Présentation. . . 38
4.3 LesQueuing Dis iplines . . . 39
4.3.1 s h_[p|b℄fifo. . . 39 4.3.2 s h_tbf . . . 40 4.3.3 s h_prio. . . 41 4.3.4 s h_ bq . . . 48 4.3.5 s h_sfq . . . 49 4.3.6 s h_red . . . 49 4.4 Les lasses . . . 49 4.4.1 La lasseCBQ . . . 49
4.4.1.1 Expli ationdesmots lés boundedetisolated. . . 50
4.5 Les ltres ou lassi eurs . . . 51
4.5.1 Le lassi eurroute . . . 52
4.5.2 Le lassi eurfw . . . 52
4.5.3 Le lassi euru32 . . . 53
4.5.3.1 Filtragesurl'en-tête IPave u32:mat h ip . . . 54
4.5.3.2 Filtragesurl'en-tête TCPave u32 :mat h t p. . . 54
4.5.3.3 Filtragespé i ques :mat h u32 | u16 | u8 . . . 54
4.5.4 poli e . . . 55
4.6 La ommandeestimator . . . 55
5 SCENARIOS DE TESTS 56 5.1 FluxTCP ordonnan és par CBQ . . . 56
5.3.1 Partage ave CBQ . . . 63
5.3.1.1 S ript de générationdu tra . . . 63
5.3.1.2 S ript d'ordonnan ement etrésultat . . . 63
5.3.2 Partage ave SFQ . . . 67
QUALITE DE SERVICE DANS
L'INTERNET
1.1 Avant propos
Cette partie a pour but de présenter su intement la théorie né essaire à la ompréhension
desmé anismes de QoSsousLinux. Elle n'est en au un asune présentation exhaustive.
1.2 Introdu tion
La onvergen e vers IPest de plus en plusomniprésente, que elasoient les opérateurs
télé-phoniquesqui veulent passerdeleurtraditionnelle ommutation de ir uit àdelavoiesurIPou
les grands p les multisites qui veulent passerde leurs liaisonsspé ialisées privées versun réseau
IP partagéave VPN .Enbref, toutlemonde veututiliserIP.
Le problème d'IP est qu'il soured'un léger handi ap. Contrairement à ATM, il traite tout
le monde de manière indiéren iée. Toutes les données traversant un réseau IP sont routées de
manière équivalente en best-eort.
A tuellement,leseulmoyenqu'ontlesISPdelimiterlabande passantedesutilisateursestde
vendre desservi es basés surles apa ités desinterfa es desutilisateurs ommeles modem33.6
et56 Kbpsou les 1à 3Mbps desmodems xDSL.
Le but a tuel de la QoS est de pouvoir donner la possibilité à l'utilisateur de payer une
onnexionplus hèrea nd'appré ierunequalitédetransmissionsupérieureà elled'unutilisateur
lambda. Le multimédiaest l'autre raison d'êtrede la QoS. Eneet, les appli ationsmultimédia
répondent à des exigen es stri tes en terme de délai et de bande passante que la QoS est en
mesured'orir.
Bienévidemment,laQoSasapropredé nitionpour ha und'entrenous.Eneet,demanière
générale, on peut assimiler le servi e d'un grand restaurant supérieur à un fast-food, plus de
hoix,meilleurequalitédesproduits,meilleura ueil...,vouspayez plus herpourlerestaurant,
en revan he, pour un autre utilisateur; il pourra trouver la qualité de servi e d'un fast-food
Letempsdel'Internetéquitable estdon révoluetnouspouvonsdon onstaterl'arrivéed'un
système de astes ou de ou hes so iales sur Internet ave eux qui auront payé et eux qui
n'auront paspayé.
Plusieurste hniquespermettantdegérerlabandepassantea ndepouvoirgarantirdelaQoS
ont étéproposées par l'IETF (Internet EngineeringTaskFor e).
L'appro he Intserv
Dans le passé, une appro he ave servi es intégrés (via RSVP) avait été proposée par l'IETF.
Cetteappro he Intserv/RSVP nepossèda paslesu èses omptéduàunmanque de e queles
anglaisappelle s alability (littérallement lepassage àl'é helle). Cettete hnique deréservation
debout enbout édalapla e àune autre onnue sous lenomde ...
L'appro he Diserv
Servi esdiéren iés donnant la possibilité auxéléments a tifs du réseau un plus grand ontr le
surlagestionde labande passante.
Passonsmaintenant àuneprésentationplusexhaustive de esdeuxappro hes, ena entuant
notreétudesur Diserv.
1.3 Le modèle Intserv / RSVP
Lebut dugroupedetravailIntservdel'IETF estlatransformationdel'Interneta tuel enun
réseauà intégration de servi es.
L'ar hite ture Intserv s'organise autour du on ept de ot de données orrespondant à un
ensemble de paquets résultant d'une appli ation utilisatri e et ayant un besoin d'une ertaine
QoS.A n de satisfairelaQoSrequise, Intservpropose d'ee tuer uneréservation desressour es
né essairesàl'établissementde elle- ivialeproto olederéservationderessour esnomméRSVP.
Le signal RSVP étant onstitué par l'information de ontr le de la QoS, elui- i propose des
dire tives a n de mettre en pla e la réservation mais ne dit pas omment la mettre en pla e,
e domaine étant réservé aux routeursduréseau qui prennent en ompte lasignalisationRSVP.
Pour sefaire,les routeursdisposent de quatrefon tionsde ontr le du tra :
1. Leproto olederéservationderessour e:qui,defaçonimpli ite,signalisele heminàétablir
ensolli itant desréservations de bande passante sur haque routeurstraversésduréseau.
2. Le ontr le d'admission : permet d'autoriser l'arrivée d'un nouveau ot muni de sa QoS
sansperturberles QoSdesautres ots existant.
3. Les lassi eurs de paquets :qui lassent les paquets de ots admis dans les lasses
spé i- ques.
4. L'ordonnan eurde paquets:qui détermine l'ordrede servi edespaquets.
1.3.1 RSVP
RSVPaété présenté en 1995 àInterop, une démonstrationmettant ens ène desordinateurs
re evant dusonetdesimages. Ilaétéprouvé que,àtraversunréseau Internet, même hargé, la
qualitédelatransmissiondelavidéoetdusonétaitbonnelorsquelesdonnéesétaienta heminées
via des sessions RSVP. Sansles mé anismes de réservation fournis par RSVP,les présentations
devenaient inintelligibles. Cetteperforman eétait dueàRSVP asso iéauxmé anismes
d'ordon-nan ement des ux implantés dans les routeurs. C'est à dire, Weight Fair Queuing hez Cis o
Systems, etClassBased Queuing hez BayNetworks.
L'IETF a onçu le proto ole RSVP pour la réservation de ressour e au sein d'un réseau
Internet.Ilpeutêtreutilisé pour assurerlaqualité deservi eetgérerlesressour esde transport
du réseau pour les sessionspoint à point (uni ast) etpoint à multipoint (multi ast). RSVP est
un systèmede ontr le et de signalisationqui donne lapossibilitéde réserver labande passante
né essaire au bon fon tionnement d'une appli ation. C'est un besoin qui tou he prin ipalement
les uxmultimédias,plussensiblesauxaléasde l'a heminement queles uxdedonnéespuresdu
fait deleurs ontraintestemporelles.
UnesessionRSVPestidenti éeparl'adressedudestinatairedu otdedonnées(ils'agitd'une
adresse IPUni ast ou Multi ast), le numéro de portde destination etle proto ole utilisé (TCP
ouUDP).RSVPfon tionne ave troistypesd'éléments:l'expéditeur,leréseauetledestinataire.
L'expéditeur indique au réseau la ara tèristation du ux qu'il va envoyer. Le réseau enregistre
les demandes, les traite, noti e au destinataire que des messages sont en route. Le destinataire
informe le réseau de e qu'il est apable de re evoir et du moment où la ré eption est a hevée.
C'est le destinataire du ot de données qui fait la demande de réservation en s'adressant à un
pro essus RSVP lo al. La requête formulée, RSVP la transporte de routeur en routeur dans le
sens inverse de elui que vont emprunterles données on ernées. Pour ette raison, e proto ole
n'agit jamais seul, mais s'appuie sur les proto oles de routage. Il peut être aussi asso ié ave
le proto ole IP Multi ast, mono ou multi emetteurs, lorsque des é hanges ont lieu au sein d'un
groupe d'ordinateursselon unmondeanalogue à eluiutilisé dansle asdelatélévision oude la
radio.
1.4 Le modèle Diserv
Au ontraire du modèle Intserv qui traite indépendamment haque ot, le modèle diserv
proposedeséparerletra par lasses.Nousavonsdon aaireàunegranularitémoins nemais
quidevientenrevan hepluss alable.Eneet,lagranularitédu otimpliquelaréa tionen haine
suivante:plus il ya d'utilisateurs dansle réseau, plusil y ade ots, plus il ya de variables de
lassi ationsetd'ordonnan ementsdanslesrouteursàmaintenir, equiapour onséquen eune
hargeimportante au niveaudes routeursquideviennent alors demoinsen moinsperformants.
1.4.1 Ar hite ture Diserv
Snd1
Snd2
R1
R2
R3
R4
R7
R5
Rcv2
R6
Rcv1
classe A
R8
Fig. 1.1 Les noeuds R1, R2, R6, R8 sont des edges routers, les noeuds en gris sont des ore
routers
plut tquede lassede tra )Chaque lasseestidenti ée parune valeur odéedansl'en-têteIP.
Cette lassi ation doit sefairesur lesrouteursde bordures(edge router) àl'entrée duréseau.
L'ar hite turedesservi esdiéren iés proposéedansle[RFC2475℄ ontient deuxtypes
d'élé-mentsfon tionnels :
1. Lesélémentsdebordures(edgefun tions):ilssontresponsablesdela lassi ationdes
paquetsetdu onditionnementdutra .Enbordureduréseau, 'estàdireàl'arrivée
dupremierélémenta tif apabledetraiterle hampsDS(DS- apable),lespaquetsarrivant
ont dans leur hamp TOS (pour IPv4) ou Tra Class O tet (pour IPv6), une ertaine
valeur DS. La marquequ'un paquet reçoitidenti e la lassede tra auquel il appartient.
Aprèssonmarquage, le paquetest envoyé dansleréseau ou jeté.
2. Les éléments du oeur du réseau ( ore fun tions) : ils sont responsables de l'envoi
uniquement.Quandunpaquet,marquédeson hampsDS,arrivesurunrouteurDS- apable,
elui- i est envoyé au pro hain noeud selon e que l'on appelle son Per Hop Behaviour
(PHB)asso iéàla lassedupaquet.Le PHBin uen elafaçon dont lesbuersdurouteur
et le lien sont partagés parmi les diérentes lasses de tra . Une hose importante dans
l'ar hite tureDSestquelesPHBrouteurssebasentuniquementsurlemarquagedepaquet,
'est à dire la lasse de tra auquel le paquet appartient; en au un as ils ne traiteront
diéremment despaquetsde sour esdiérentes.
Par exemple : Comme le montre la gure 1.1 page 9, le noeud R3 ne fait au unediéren e
Classification
Marquage
Paquets
Emission
Edge Router
Fig. 1.2 Arrivée despaquets dansunedge router.
aggregate, dé ni par le [RFC 2475℄, préféré à lasse de tra . Le omportement qui est dé ni
au noeud R3 agrègeles otsde même lassevers lemême noeud.
L'avantage de Diserv est qu'il n'y a plus né essité de maintenir un état des sour es et des
destinations dansles ore routers,d'oùune meilleures alability.
1.4.2 Classi ation et onditionnement du tra
La lassi ations'ee tuesuivantuneouplusieursvaleurs ontenuesdansl'en-têteIP(exemple:
adresse sour e - destination, port sour e - destination, proto ol ID, ...). Celle- i faite,elle dirige
lepaquet vers lafon tion demarquage appropriée ommele montrela gure 1.2page 9.
Une fois les paquetsmarqués, ils sont envoyés à leur destination puis à haque routeur
DS- apable, ils re oivent leservi easso iéà leur lasse.
Il n'est pas pré isé par le groupe de travail Diserv omment le lassi ateur est paramétré
pour ee tuer ette lassi ation, ouplus exa tement,qui leparamètre? Celadoitêtre fait
ma-nuellement, auxbon soinsdel'administrateurqui paramètreles tablesdemarquage despaquets
en fon tion d'une table d'adresse sour e, par exemple, donnée au edge router. Ou par le biais
d'unproto oledesignalisation...RSVPpourraitd'ailleurstrèsbienfairel'aaire,en eet,
elui- i n'étant pas un proto ole de signalisation propre à Intserv uniquement, on pourrait l'utiliser
a n de signalerles lasses qu'auront lesrouteurs àtraiter.
En plus de ette lassi ation/marquage, un mé anisme de pro lage du tra est dé ni par
le groupede travail Diserv.Ce tra pro le a pour objetla prise en ompte dutaux d'arrivée
des paquets, a n de ne pas dépasser le seuil maximum de paquets pouvant être envoyés sur le
réseau. Ainsi, un mé anisme de mesure du tra permet de savoir si le ot de paquets entrant
orrespond au pro lde tra négo ié. Si e ot dépasse un ertainseuil, ertains paquetsseront
Classification
Paquets
Emission
Edge Router
Marquage
Lissage
Paquets jetés
Mesure
Fig. 1.3Classi ation, marquage et onditionnement du tra au niveaudu edge router
1.4.3 Les PHB
Passonsmaintenantàlapartie on ernantles ore routerDS- apable.LeRFC2475donnepour
dé nition du PHB : Comportement de relayage observable à un noeud DS- apable appliqué à
unbehaviour aggregate parti ulier. ChaquePHB orrespond don àun traitement par lasse.
Le servi e de meilleur qualité pouvant être oert par un PHB porte le nom de expedited
fowarding ou premium servi e; il a pour but de garantir une bande passante ave des taux
de perte, de délai et de gigue faible. Ensuite, un ensemble de PHB a été regroupé sous le nom
d'assured forwarding. Cette famille de PHB est s indée en 4 lasses garantissant de fournir
GESTION DES FILES &
ORDONNANCEMENTS
2.1 Présentation
Cettepartie a pour but la présentation desdiérents a teurs d'ordonnan ement présents au
seindu odesour eLinux.Tousnesontpasen oreopérationnelset ertainsd'entreeuxpossèdent
despartiesdedéveloppementin omplètes. Lapremièreimplémentation datantdunoyau2.1.90 1
,
l'aventurene faitque ommen er ...
2.2 Introdu tion
Lagestion des lesest né essairepour équilibrer letra [RFC2309℄. Elle évitela
monopoli-sation de la queue par un seul ux. Une simple gestionde le n'évite pasque les queuessoient
pleines pour des périodes longues, alors que pour avoir de faibles délais il est souhaitable que
les queues ne soient pas trop hargées. En eet, de petites les d'attenteréduisent les délais de
transmission.L'obje tifdelabuerisationdansleréseauestavanttoutd'absorberdespointesde
tra sfugitives.Pour esraisonsdesmé anismessupplémentaires omplètentlasimplegestionde
led'attente desortie. L'obje tif de es mé anismes estde diminuerlenombre dedatagrammes
éliminés,dediminuerledélaideboutenbout,d'éviterleremplissagepermanentdes lesd'attente
et ela touten gardant une bonne utilisation duréseau.
Le[RFC2309℄dé nitdeuxtypesd'algorithmesde ontr le de ongestion :lagestiondes les
et l'ordonnan ement. Le premier gère la taille de la le en éliminant des paquets si né essaire
tandis quele se onddétermine quel est lepro hain paquet àenvoyer sur lelien.Tousdeux sont
utilisés pour gérer labande passanteutilisée par les otsde paquets.
1
Serveur
File d’attente de priorité haute
File d’attente de priorité basse
Classifier
Fig. 2.1 Priority Queuing
2.3 Les ordonnan eurs
2.3.1 First In First Out (FIFO)
C'est l'ordonnan ement par défaut, le plus simple qui soit. Les paquets sont mis dans la
le de sortie et servis dansl'ordre ave lequel ils ont été reçus par le ou les interfa es d'entrée.
C'estaussiladis ipline laplusrapideau pointde vuede lavitessedetransmissiondes paquets,
étant donné qu'elle n'ee tue au un traitement sur eux- i. Cette te hnique est su sante dans
unréseau à forte apa ité aron peut onsidérer que les les restant presque toujours vides, les
délais sont alors faibles voir insigni ants. Par ontre, dans le as d'une rafale, la le d'attente
peut seretrouver en débordement etles paquetsarrivésaprès la rafale peuvent êtrejetés. Dans
e as,les paquetsjetés lesont de manière indiéren iée,sans prise en ompte dutype de tra
auquelils orrespondent.Enutilisantdesstratégiesdemiseen led'attentediéren iée, onpeut
permettre à ertains types de tra d'être privilègiés en detruisant ertains paquets plut t que
d'autres.
2.3.2 PriorityQueuing
C'est laforme primitive de ladiéren iation de servi e. Eneet,sous e type
d'ordonnan e-ment,lespaquetsarrivant surleliende sortiesont lassi ésenune,deux, voire plusieurs lasses
surla ledesortie.La lassed'unpaquet dépend alorsd'un marquageexpli itesetrouvantdans
l'en-têtemême de elui- i. Par exemple, en prenant en ompte le hamps TOS d'IPv4,ou alors
en prenant en ompte les autres données présentent nativement dans l'en-tête omme l'adresse
sour e- destination, leportsour e - destination,ou unautre ritère.
Comme le montre la gure 2.1 page 12, haque lasse a sa propre le d'attente. Le serveur
hoisirad'abordunpaquetsetrouvant dansla led'attente hautepriorité,si elle- iestnonvide
avant eux setrouvant dansla lebasse priorité.
La granularité de lassi ation sebasant surl'en-tête même du paquet estassez exible. En
revan he, e système implique une dégradation des performan es. Il peut y avoir un problème
Serveur
Classifier
Fig. 2.2 Weighted Fair Queuing
L'autreproblèmequiestsoulevépartouteslesdis iplinesnonFIFO,estqueletempsd'attente
danslesbuersrestant indéterminé, onne peutpas al ulerlagigue duréseaude bouten bout.
En eet, dans le asdu priority queuing par exemple, il estimpossible, au niveau du temps de
miseen attente dansles les,de déterminerau bout de ombiende temps unpaquet de priorité
basse va être servi, e servi e ne pouvant être fait que lorsque au un paquet ne se trouve en
priorité haute.
2.3.3 Round Robin
Delamême manièrequeladis iplinepriorityqueuing, lespaquetssont triéspar lasses dans
des les, ensuite, un tourniquet alterne les paquets à servir parmi les les présentes. Dans sa
forme la plus simple, ave deux lasses de paquets, on obtiendrait le tra suivant :paquet de
lasse 1transmis, suivid'un lasse 2,suivid'un lasse 1,suivid'un lasse2...
2.3.4 Weighted Fair Queuing
Lepartageéquitable pondéréestuneémulation duround robin bitàbit.Lespaquetsarrivant
sont lassi és puis mis dans leurs les d'attente respe tives et de la même manière quepour le
round robin, lespaquetssontservisde façon ir ulaire ommelemontrela gure2.2page 13.
Cemé anismedegestiondes lesd'attente (quipeut,parexemple,êtrepondéréparle hamp
IPPre eden e), permetuneallo ation debandepassanteplusoumoinsimportantepour haque
lasse. En eet, le tourniquet servant bit à bit, un poids va être donné pour la le de haute
priorité. Dans l'exemple de la gure 1.5: on sert 3 bits de la le de priorité haute, 2 bits de la
lede priorité intermédiaire et1bit dela lede prioritébasse.
Cemé anisme de tri estdépendant du onstru teur arle hamps IPPre eden e peut avoir
milles interprétations diérentes et don tout dépend de e qu'entend le onstru teur dans le
2.3.5 Sto hasti Fair Queuing
Dérivé de WFQ, qui limite le nombre de le d'attente en agrègeant les ots grâ e à un
pro essusaléatoire.SFQ estune solutionau problèmede s alability deWFQ.
2.4 Les Ar hite tures d'ordonnan ements
2.4.1 Clark-Shenker-Zhang
[CSZ92℄ propose une ar hite ture pour les réseaux de type ISPN 2
supportant deux types
distin tsde servi estemps réel :
1. Lesservi es garantis : 'estla forme traditionnelle des servi estemps réelsbornés par des
ontraintes de délai orrespondant au piredes as.
2. Les servi es prédi tifs :ils utilisent des mesures de performan e du réseau par le biais de
al uldebornesde délai d'a heminement de paquet.
Les on epts dé rits dans l'arti le s'intéresse tout parti ulièrement aux servi es prédi tifs ainsi
qu'aux paramètres d'installation passés entre le réseau et la sour e. Notamment, l'interfa e de
servi edoitin lure:
1. Une ara téristion de lasour e,
2. Unedes ription dela QoSqueleréseau esten mesured'orir.
La dernière pie e de ette ar hite ture est l'ordonnan eur de paquets utilisé, né essaire pour
répondreauxattentes dé rites i-dessus.
Selonlale turedu odesour enet/s hed/s h_ sz. et[CSZ92℄,l'idée prin ipaleestde réer
des otsWFQ pour haque servi esgarantis etd'allouer lereste de la bande passante à, e que
Alexey Kuznetsov appelle dans le ode de s h_ sz, un ow-0. Le ow-0 in luant le tra de
servi eprédi tifetletra best-eort. Ce otestgéréparunordonnan eurdeprioritéattribuant
labande passantehautepriorité autra prédi tif,lereste étantpartagé parletra best-eort.
[CSZ92℄ utilise une forme parti ulière de ara térisation de tra : le token bu ket (voir la
se tionsuivante).Cemé anismeest ara térisépar untauxr etune taillemaximumderafaleb.
Unesour e detra est onforme àun tokenbu ket(r,b) siilya toujoursassez dejetondansle
seau haque foisqu'unpaquet estgénéré.L'ar hite ture [CSZ92℄supposeégalement queles ots
soient passéspar un mé anismede ontr le d'admission àl'entréedu réseau.
2.4.2 Class Based Queuing
C'est une variation de WFQ, qui utilise également un tourniquet sur plusieurs les mais un
lassi erenamont delabatteriede levas'intéresser à lassi er haquepaquetenfon tiondesa
lassedanssa le orrespondante. Il n'y a don plusde lassi ation sur le ot.Grâ e auround
robin ensortiedes les,onévitequ'uneseule lassedetra nemonopolisetoutesles ressour es.
Dans[CBQ℄, SallyFloydetVanJa obson proposentune ar hite turebaséesurlepartage de
lien(link sharing) .Ce dé oupagede labande passante peutêtre faiteen prenant en ompte :
Lien
audio
video
20%
ftp
telnet
50%
20%
10%
0%
Fig.2.3 Partage de lien entreplusieurs lasses deservi es.
La famille deproto oles utiliséssurlelien,
Lestypesde tra s appli atifs(telnet, ftp,mail, ...),
Lesdiérentes organisations partageant le lien.
Le but du link sharing est la lassi ation de es diérents types de tra a n d'opérer à un
partage de labande passante entre estra s ommelemontre la gure2.3page 15.
Le but prin ipal du link-sharing est que haque lasse, ave une demande orrespondante à
sesbesoins,doitêtreen mesurede re evoirapproximativement sabande passanteallouéedurant
un ertainintervalledetemps orrespondantàune ongestionsurleréseau.Surla gure2.3page
15,le link-sharing nedonne au unegarantie de bande passante pour letra mail.
Lepartage peutégalement êtrehierar hisé,entrediversesorganisations parexemple, omme
lemontre la gure2.4page 16.
Unepartdelabandepassanteestdon attribuéeà haqueniveau.Lagestiondesqueuesmeten
oeuvrelesdiérentesvariantesdegestiondeslistesdepro essus:priorité,tempspartagé.Enfait,
pourles asextrêmesilestutiledepouvoir onsidérer qu'un ertaintypedetra estéliminable.
Les mé anismes de partage dans[CBQ℄ ne tentent pasde fournir un ontr le de ongestion au
niveau des feuilles de l'arbre ( orrespondant à une lasse de tra ). Ces mé anismes étant à
implémenter par l'ordonnan eur général à l'entrée du réseau. [WGC94℄ donne de plus amples
expli ationssur l'implémentation de es te hniquesd'où esttiréela gure2.5 page 16.
Uneautreappro he onsisteàralentirles uxplut tqu'àgérerlesprioritésoulapénuriele as
é héant.Leralentissementse ommandeàl'aidedemessagesICMPderalentissementémisdepuis
unrouteurintermédiaireversl'émetteurinitialdumessage.Cesmessagesneremontent ependant
pas à l'appli ation etne sont don pas for ément suivisd'eet, d'où l'idée de tra shaper qui
diminue la taille de la fenêtre d'anti ipation dans l'en-tête TCP de façon à réduire le débit de
ertains ux.Le lassement destra ssefait selondiérents ritères : hamps TOS,adressesIP
sour e et/ou émetteurs,numérosde ports UDPou TCP qui permettent d'identi er les ux. On
distinguelesappli ationsàtra tempsréeloulesappli ationsdutypemessagerieautra moins
urgent.Cesmodesdegestionsontplusoumoinsextensiblesàdesréseauximportants.Letra est
Lien
org A
org B
org C
ftp
telnet
UDP
TCP
Fig. 2.4Partage hiérar hisé d'unlien.
Routing & class database
packet scheduler
packet classifier
output driver
Network management
Pkt In
Pkt Out
One file for each priority
2.5 Politique de tra
En omplément ou en alternative deste hniquesd'ordonnan ement présentées i-dessus, des
te hniques de ontr le etdelissage du tra permettent de ontr lerle volume detra entrant
dansleréseau ainsiqu'ave ledébit ave lequelil esttransmis.
Onpourrait donner omme dé nition à la politique de tra :la spé i ation du taux ave
lequel un ot est autorisé à envoyer des paquets à l'intérieur d'un réseau. Pour se faire, trois
ritères importantssontà retenir:
1. Le débit moyen
2. Le débit rête
3. Lataille maximumdelarafale :elle limitelenombredepaquetsquipeuventêtre transmis
dansun intervalle de temps très ourt.
2.5.1 Lissage du tra
2.5.1.1 Leaky Bu ket
Letra entrant dansla le(le seau)estrégulé pour sortiràdébit onstant surleréseau.La
tailleduseauetledébitensortiesont on gurablesparl'utilisateur.Latailleétantdéterminante
en e qui on erne les pertes de paquets (lorsque le seau est plein le tra entrant peut être
jeté).Le leaky bu ket est omposé d'un ompteur , d'unseuil t et d'untaux de vidage, le leaky
rate : r. Chaque fois qu'un paquet arrive dans le seau, le ompteur est in rémenté et e même
ompteurest dé rémenté par leleakyrate.Siun paquetarriveau moment ou =t;alors elui- i
est jeté.
2.5.1.2 Token Bu ket
Letra ne traverse pasdire tement leseau maisesttransmis surlabasede jetons présents
dans le seau. Un jeton orrespond à un nombre de bits donnée, le taux d'arrivée des jetons
orrespond au débitmoyen etlaprofondeur du seauàlataille de larafale.
Ce mé anisme permet à un tra en rafale d'être transmis tant qu'il ya des jetons dans la
led'attente, eux- i ayant pu êtrea umulés ensituation de réseau peu hargé.
2.5.2 Prévention de la ongestion
TCP etUDP ohabitent mal, UDPne possèdant pasde mé anisme de omportement
adap-tatif, la miseen route d'unalgorithme de ongestion avoidan e de TCP laisse pla e à une
aug-mentation de tra UDP.Ilexisteégalement unautreproblèmelorsquedespointsde ongestion
sedéveloppent unpeupartoutdansunréseau hargé; haque uxTCP vadéte terdespertes et
engager un algorithmede ongestion avoidan e. Ainsi, de nombreux uxvont repasser en mode
slow start et tenter de réémettre les paquets perdus, e qui ne resolvera en rien la ongestion
déjà présente ar leredémmarrage des ux se ferade manière syn hrone. Ce phénomène onnu
2.5.2.1 Random Early Dete tion
Cette méthode a pour vo ation la déte tion de la ongestion avant que ette dernière ne se
produise.Pour sefaire, onva:
1. soit jeter aléatoirement des paquetspar mesurepréventive a nque TCP réduise sa
trans-mission.
2. soitutiliserle agECNpourindiqueràTCPquelespaquetsonttraverséunnoeud
onges-tionné.
Le seuilà partirduquel on ommen e à jeter les paquets, ainsique letaux de remplissage de la
le,doivent être on guré par l'administrateur.
Dans unrouteur, ela reviendrait àmesurer letaux d'o upation dela mémoire.
Le[RFC2309℄re ommandel'implantationsurlesrouteursdumé anismeREDetladé nition
demé anismedegestion des uxnonrégulés. Le ouplagede l'algorithmeREDà unmé anisme
de gestion de priorité du type de elui dé nit dans DiServ pour le hoix des datagrammes à
éliminerestévoqué.
2.5.2.2 Weighted RandomEarly Dete tion
Mêmete hniquequelapré édentemaisquipermetdedéterminerqueltra onjettegrâ eàla
priseen ompte du hampsIPPre eden epar lesrouteurset elaa nd'éviterlamonopolisation
des ressour es par ertaines lasses de tra . Cette pondération gérée via e hamp permet au
réseau de demander aux ux de tra moins prioritaires de s'adapter au pro t du tra plus
LINUX ET LA QoS
3.1 La ou he réseau du noyau Linux
Cettepartie présente demanière su inte lafaçon dont la ou he réseau Linux travailleave
lesdonnées.Onpourraseréférerauxdo uments[HMO00℄et[Rus99℄a nd'obtenirdeplusamples
approfondissements.
3.1.1 IPv4 et Qos
Entre le noyau 2.0et 2.2, le hier net/ipv4/ip_output. a été modi é a n que les en-têtes
despaquetsIPv4 puissent utiliserlesmé anismes de QoSgrâ e au hampTOS de IPv4.
3.1.2 So ket Buers
Linuxutilise lesso ketbuers ousk_buffspourpasserlesdonnéesentreles ou hes
proto o-laires etles driversdes artes réseaux. Le but de ette buerisation est la onnaissan e, par la
ou heen ours,de equiaétéajoutédansl'en-têtedudatagrammeparla ou hepré édente.La
stru ture dedonnéesk_buffs estvisibledansle hierin lude/linux/skbuff.h.Cettestru ture
possède un blo de données qui lui est asso ié, 4 pointeurs permettant des opérations sur es
so kets buers et 2 hamps de variables de longueurs. Elle donne la possibilité aux diérentes
ou hes de la pile TCP/IP de Linuxd'ajouter ou de retirer l'entête mis par les proto oles ainsi
quelamiseenqueuedesdonnéesappli atives.Deplusamplesrenseignementssur esmé anismes
sont disponiblesdans[Rus99℄.
3.1.3 Transmission des paquets IP
Dans tous les as, lorsque des données sont générées en vue d'être transmises surle réseau,
une stru ture sk_buff est onstruite a n de ontenir les données et les divers en-têtes ajoutés
par les ou hes proto olaires que es mêmes données ont traversées. Il faut don donner ette
stru ture au périphérique de sortie a n que le paquet soit transmis. Dans e as, IP a besoin
de onnaître le périphérique qu'il doit utiliser. IP utilise pour ela la table de routage a n de
table de routage renvoie la stru ture rtable(Cf. in lude/net/route.h) qui va dé rire la route
à utiliser. Cela in lus l'adresse IP sour e à utiliser, l'adresse réseau de la stru ture devi e et,
dans ertain as, un entête ontenant l'adressematérielle déjà onstruite 1
.Cet entête ontenant
l'adresse matérielle ontient l'adresse sour e et destination physique de l'interfa e (dans le as
d'Ethernet 'estl'adresse MACqui est utilisée).
Nous nous sommes attardés sur la transmission des paquets ar 'est l'étape pré edant le
ontr le du tra sous Linux, de plus amples détails vous être donnés dans les paragraphes
suivants. Une expli ation détaillée des mé anismes de ré eption des paquets et du routage IP
sous Linux est diponible dans [Rus99℄. Un petit tour par le ode du noyau peut s'avérer utile
notamment pour omprendre l'implémentation du proto ole ARP, voir:
ip_build_xmit()dans net/ipv4/ip_output.
eth_rebuild_header()dansnet/ethernet/eth.
3.1.4 Les éléments de QoS
Element t keyword Filename pre xKernel Filename pre x t
Queuing dis ipline qdis s h_ q_
Class lass (s h_) (q_)
Filter filter ls_ f_
Le tableau i-dessusprésente les mots- lés utilisés omme nomde hier ou omme nom de
fon tion pour lesélémentsde ontr le detra .
Sur maversion du noyau 2.2.13, le ode réside prin ipalement dans le répertoire net/s hed.
Lesordonnan eurset les lassi ateurs sedistinguent par leur nomquidébute par :
ls:pour les lassi er
s h:pour less heduler
Lesinterfa esentreles élémentsde ontr lede tra du noyau etlesprogrammesutilisateurs
lesutilisant sont dé larés danslesheaders suivant :
in lude/net/pkt_ ls.h
in lude/net/pkt_s hed.h
Les mé anismes rtnetlink utilisés pour la ommuni ation entre les programmes utilisateur
de ontr le de tra etle noyau sont implémentés dans:
in lude/net/rtnetlink.h
net/ ore/rtnetlink.
rtnetlink est basé sur netlink et est une extension permettant de passer au travers de
l'interfa e so ketdesparamètres de QoSaunoyau.
Lesnetlink so ketssontutiliséespourtransférerdesinformationsentrelesmodulesdunoyau
et les appli ations utilisatri es, ette ommuni ation se fait au travers d'un lien bidire tionnel.
Elles sont onformes aux so kets de Berkerley. Une so ket linux peut être rée par la fon tion
suivante:
so k_fd = so ket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)
Cette so keta pour domaine AF_NETLINK.Son type estSOCK_RAW.NETLINK_ROUTEfait partie de la
NETLINK_FAMILYqui sele tionnele moduledunoyau ave lequelnousallons ommuniquer.
Lesmembres de lafamille NETLINK_FAMILYsont :
NETLINK_ROUTE:reçoitlesmiseàjour deroutageet peutêtreutiliséepourmodi er latable
deroutageIPv4,l'adresseIP,lesparamètresdulien,les lesd'attentes,les lassesdetra ,
les ltres ...,
NETLINK_FIREWALL:reçoitles paquetstraités parle odede rewallingd'IPv4,
NETLINK_ARPD:utilisé pour lagestionde latable ARP,
NETLINK_ROUTE6:envoieetreçoit desmisesà jour detable de routage IPv6,
...
d'autres fon tionssont dé rites beau oupplus endétail dans[DhS99℄.
3.2 Con guration
Le support de la QoS est disponible depuis les versions du noyau postérieures à 2.1.90. A
partir du noyau 2.2.1, elui- i possède un support pour les servi es diéren iés sous forme de
pat h disponible surle site ftpde l'EPFL 2
àl'adressesuivante:
ftp ://lr ftp.epfl. h/pub/linux/diffserv/pat hes/ds-X.pat h.gz
Le dernierpat h en dateétant :ds-4.pat h.gz
Cepat hestné essaireaunoyau2.2a nd'obtenirtouteslesfon tionnalitésdeQoSsupportées
par Linux.
La on guration dunoyau s'ee tuede lamanièresuivante :
1. Se pla er dans/usr/sr /linux
2. Dé ompresser lepat h:gunzip ds-4.pat h.gzet appliquer elui- iaunoyau :pat h -p0 <
ds-4.pat h
3. Tapermake x onfig (ou make menu onfigenmode texte)
4. Dans lemenu QoS and/or Fair Queuing,sele tionner toutesles options.
5. Faire un make dep; make lean; make bzlilo et redémarrer le système sur le nouveau
noyau frai hement ompilé.
3.3 Implémentation du ontr le de tra
3.3.1 Introdu tion
La partie on ernant le ontr le du tra et plusieurs outils de gestion de es ontr les ont
été implémentés par Alexey Kuznetsov (kuznetms2.inr.a .ru). Son travail est inspiré par les
on epts dé rits dans [CSZ92℄ mais il ouvre également les mé anismes requis pour supporter
l'ar hite ture Intservde l'IETFetplus ré emment Diserv.
Fig.3.1 Traitement despaquetsdu réseau.
3.3.2 Prin ipe de base
Les paquets entrant sont examinés a n de déterminer si il sont destinés au noeud où ils se
trouvent.Si 'estle as,ilssontenvoyésaux ou hessupérieures(TCP,UDP)sinon,ilspassentpar
latablederoutagea ndedéterminerquelestlepro hainnoeudàatteindre.Une foisl'opération
faite,lerouteur envoielespaquetsversune led'attentesurl'interfa edetransmission.C'estsur
ette interfa e que vont se jouer la QoS etle ontr le de tra du noyau Linux. Le ontr le de
tra étant implémenté justeavant quelepaquetsoit misdansla led'attentemaintenue par le
périphérique desortie (Cf.s héma3.1page 22).
Le ontr le de tra peut,entre autredé ider sile paquet estmis dansune led'attente ou
si il est jeté ( e as peut survenir lorsque la le a atteint une taille limite ou si le tra ex ède
undébit seuil). Il peutégalement dé ider dansquel ordreles paquets vont être envoyés(a n de
donnerlaprioritéà ertain ots)ou retarderl'envoidepaquetsdanslebut delimiterletra en
sortie.
3.3.2.1 Le ontr le de tra sous Linux
Le onditionnement despaquetspar leLinuxTra Control(LTC)est ee tuéaprès queles
mé anismesde routage aient dé idéssurquelle interfa e lepaquetdoit sortir. Don ,il n'ya que
lespaquetssortant qui sont assujettisàun ontr le de tra .
Leséléments né essairesau LTC sont lessuivants:
La queuing dis ipline :pourl'instant, lesdis iplines validessont CBQ, CSZ 3
,Priority.
Les lasses :ellessont gérées parladis iplinede led'attentedupériphérique.Une lasse
orrespondàunensemblederèglesmarquantlesdonnéespropresàune lasse.Onpourrait,
par exemple, avoir une lasselimitant letaux despaquetsà 1Mbps pendant lajournéeet
quipasse etauxà5 Mbpsdurant lanuit.Plusieurs queuingdis iplinepeuvent êtreliéesà
des lasses, 'estle aspour lesdis iplinesRED,SFQettokenbu ket.Pardéfaut,siau une
dis ipline n'est stipulée,on utilise FIFO.
Les lassi ersou ltres : ils dé rivent les paquets a n de les organiser dansdes lasses
gérées pardesdis iplinesde led'attente.Plusieurs ltressontdisponibles ommele
route-based lassi er, RSVP Classi er (un pour IPv4 et un pour IPv6), et le u32 lassi er.
Les ltresde rewallingpeuvent être également utilisés, on pourraitdon utiliserip hains
3
omme lassi er 4
.Leu32 lassi er estplusperformantquelesroute lassi ers qui lassent
lespaquets enfon tion de latablede routage.Lesu32 lassi er sont utiliséspour fairede
la lassi ationbaséesurl'adresseIPdedestination,l'adresseIPsour e,leportTCP/UDP
de destination,leportTCP/UDP sour e,le hampTOS etProto ol.
Poli ing:Lebutdelapoli ing,quel'onpeuttraduireparpolitiquedetra estdes'assurer
queletra n'ex èdepas ertaines bornes.
Chaque périphérique réseau possède une dis ipline de le d'attente qui lui est asso ié et
qui ontr le la façon dont les paquets mis en le d'attente sont traités. En amont des les, il
est possible d'utiliser un ltre qui lassi era les paquets en fon tion de la lasse auxquels ils
appartiennent. Sans mise en pla e d'ordonnan eurs ou de ltres quel onques, la dis ipline de
miseen led'attente par défaut estFIFO.
La gure 3.2 page 24 montre la relation existante entre les terminologies de l'IETF en e
qui on erne les modèles ar hite turaux Intserv etDiservet omment leséléments du ontr le
de tra Linux y sont relatés. Ce s héma nous montre omment a été intégré les diérentes
ar hite tures IntServ et DiServ au sein du noyau Linux. Ainsi, grâ e à ette implémentation,
unema hinefaisanto ede routeurpeutprendre pla eàdiversendroitsd'unear hite ture.En
eet, ette ma hine peut être,dansle asde l'ar hite ture DiServ,être on gurée en tant que
ore router ouedge router.
3.4 Prin ipe des le d'attentes
A nde larri er les termesutilisés nousallonsposer deuxdé nitions :
1. Une le : estun ordonnan eur,un shaperouun dropper.
2. Une dis ipline de le d'attente : l'ensemble formé par une ou plusieurs le(s) et un
lassi eur.
Il ya théoriquement 8 typesde les supportées:
CBQ:ClassBased Queue :s h_ bq
CSZ:Clark-Shenker-Zhang :s h_ sz(voirremarque en 2.2.2)
TBF:Token Bu kettFlow:s h_tbf
FIFO :FirstInFirst Out :s h_fifo
Priority :s h_prio
TEQL :Tra Equalizer :s h_tql
SFQ:Sto hasti Fair Queuing :s h_sfq
RED :RandomEarlyDete tion :s h_red
GRED: GeneralizedRED :donné en appliquant lepat h ds-3.pat h.gz
DS_MARK:s h_dsmarkDiservMarker
4
Fig. 3.3 Exemple de les
Les les sont identi éespar un handle omposé d'unnuméro majeuretd'unnuméro mineur
<major num :minor num> où le mineur est à 0 pour identi er les les. Les lasses et les les
d'attentespeuventêtre ombinées,pour ertaines,ensemble. Cen'estpasle asduTokenBu ket
qui luine possède pasde lasse. Linuxest très exible en e qui on erne les ombinaisons entre
les lassesetles lesd'attentes.Ainsi,lehandleestutilisé lorsquedes lassessont asso iéesàdes
les.
La gure 3.3 page 25 donne un exemple de dis ipline de le d'attente. La dis ipline qui est
atta hée surl'interfa e estune PriorityQueuing, ette di ipline possède deux lassesde tra et
un ltre fait o e de lassi eur entre la lasse haute priorité, servie par un token bu ket et la
lasse bassepriorité, utiliséepar défaut, serviepar FIFO.
Ainsi, l'ensemble formé par la "grand uvette" du s héma, symbolise la dis ipline de le
d'attenteasso iéeaupériphériquede sortie.A n demieux omprendre, voi i unautreexemple :
supposons que nous her hions à obtenir le partage de lien hierar hique, sur une interfa e de
sortie, selon lemodèle présenté surla gure3.4page 26.
Pour ee tueruntelpartage,l'interfa ede sortiedevraêtre on gurée ommeill'estmontré
surla gure 3.5page 26.
Cette gurenousmontre l'implantation dupartage delienprésentésurla gure3.4page 26.
Nous avons deux instan iation de CBQ : la première (1 :0) orrespondant au tra des lasses
TCP (1 :1)etUDP(2:2), lase onde(2 :0) orrespond aupartage entre letra Telnet (2 :1)et
Mail(2 :2). Nousverronsdansunautre hapitre les ommandesà passerau noyau Linuxa nde
réaliserun teltype de partagede lien.
QuandunnoyauLinux, ompiléave lesoptions deQoS, estlan é;lafon tionnet_dev_init
(net/ ore/dev. ) appelle la fon tion pkts hed_init (net/s hed/s h_api. ) a n d'initialiser le
ontr ledetra dunoyau.Danspkts hed_init,touteslesdis iplinesde lesd'attentequiontété
hoisies et ompilées ave lenoyau sont initialisées. Les pointeurs t _ tl_qdis ,t _dump_qdis ,
t _ tl_t lass,t _dump_t lass,utiliséspourexé uterdesfon tionssurles lassesetles lessont
également initialisés.
Chaque led'attentefournitunensemblede fon tionsde ontr le, elles- isontvisibles dans
stru t Qdis _opsdu hier in lude/net/pkts hed.hprésenté i-dessous:
FTP
TELNET
TCP
UDP
Lien
Fig. 3.4 Exemple departage d'un lien
CBQ 1:0
Filtre
Filtre
Class 1:2
Class 1:1
FIFO
CBQ 2:0
FIFO
Class 2:1
Class 2:2
FIFO
stru t Qdis _ops *next;
stru t Qdis _ lass_ops * l_ops;
har id[IFNAMSIZ℄;
int priv_size;
int (*enqueue)(stru t sk_buff *, stru t Qdis *);
stru t sk_buff * (*dequeue)(stru t Qdis *);
int (*requeue)(stru t sk_buff *, stru t Qdis *);
int (*drop)(stru t Qdis *);
int (*init)(stru t Qdis *, stru t rtattr *arg);
void (*reset)(stru t Qdis *);
void (*destroy)(stru t Qdis *);
int (* hange)(stru t Qdis *, stru t rtattr *arg);
int (*dump)(stru t Qdis *, stru t sk_buff *);
};
1. enqueue : met un paquet dans une le d'attente en fon tion de sa lasse, si il y a. Cette
fon tion estpropre à haque le
2. dequeue : donne le pro hain paquet élligible à envoyer. Si la le est vide, ette fon tion
retourne NULL. Le paquet élu est déterminé par l'ordonnan eur de la dis ipline de le
d'attente.
3. requeue : remet un paquet élu dans sa le d'attente exa tement à la pla e qu'il o upait
auparavant.Cettefon tionestutiliséedansle asd'unproblèmematérielsurlepériphérique
de sortie.
4. drop:jette,retire un paquet delaqueue. C'est une fon tion trèssimple qui est né essaire
pour RED ou GRED. En eet, es deux derniers ont besoin de jeter des paquets dans
ertaines onditions ( f.le ode s h_red. etlapartie 1.6.2).
5. init: on gureetinitialise la lequivient d'être réée.
6. reset:toutes les les sont remisesàzéro etles ompteurs sont stoppés.
7. destroy: omme sonnoml'indique, retireune dis iplinede led'attentedu périphérique.
8. hange: hange la on guration d'unedis ipline de le d'attente.
9. dump:utilisé pour lamaintenan e etlediagnostique.
3.4.1 Fon tionnement de la le d'attente, étape par étape :
Lorsqu'une dis ipline de le d'attente est réée pour un périphérique, un pointeur de la le
est maintenu danslastru ture suivante :(in lude/netdevi e.h)
stru t devi e
{
.
/* Proto ol spe ifi pointers */
void *atalk_ptr; /* AppleTalk link */
void *ip_ptr; /* IPv4 spe ifi data */
void *dn_ptr; /* DECnet spe ifi data */
stru t Qdis *qdis ;
stru t Qdis *qdis _sleeping;
stru t Qdis *qdis _list;
unsigned long tx_queue_len; /* Max frames per queue allowed */
.
.
.
};
Puisla ou heIPmetlesinformationsné essairesdansl'en-têtedupaquet(net/ipv4/ip_output. )
etappelle lafon tion dev_queue_xmit(net/ ore/dev. ) i dessous:
int dev_queue_xmit(stru t sk_buff *skb)
{
stru t devi e *dev = skb->dev;
stru t Qdis *q; #ifdef CONFIG_NET_PROFILE start_bh_atomi (); NET_PROFILE_ENTER(dev_queue_xmit); #endif start_bh_atomi (); q = dev->qdis ; if (q->enqueue) { q->enqueue(skb, q); qdis _wakeup(dev); end_bh_atomi (); . . . } . . };
Cettefon tion montre qu'avant d'envoyer lepaquet surl'interfa e de sortie(en utilisant une
fon tion se trouvant plus en avant dans le ode nommée hard_start_xmit) , le paquet est mis
dansla le maintenue par le périphérique (si la le existe!) Ainsi, omme il l'est montré sur la
gure3.1, le ontr le de tra est bienimplémenté justeavant quelepaquet soit envoyé surson
La fon tionenqueue orrespondante àla le d'attenteatta hée à l'interfa e est invoquée.
dev_queue_xmitappelle qdis _wakeup,a nde onnaîtrelepériphérique desortiesurlequel
il faut envoyer le paquet qui vient d'être mis en le d'attente. La fon tion qdis _wakeup
estutilisée pour retirer lepaquet de sa le a nde l'envoyersurl'interfa e desortie. Cette
fon tionpeutêtreutiliséeparunwat hdog timerprésentdanslesordonnan eursCSZ,CBQ
ou TBF.
qdis _wakeupappelle immédiatement qdis _restartqui estla fon tion prin ipale envoyer
lespaquets.
qdis _restart tente d'obtenir un paquet de la le, si ela mar he, il invoque la fon tion
hard_start_xmitdu périphériquepour envoyer lepaquet.
Sinon, lepaquet estremis dansla leave requeue.
A noter queqdis _wakeuppeutêtre être également invoqué par la le si elle- i se rend ompte
qu'unpaquetauraitduêtreenvoyéetque en'estpasle as,parexemple,surla nd'un ompteur
témoin.
3.5 Prin ipe des lasses
De la même manière que les les d'attente, les lasses (Class_ID) sont identi ées par un
handledutype<majornum:minornum>,lemajeur orrespondant toujoursàl'instan iationde
la le asso iée àla lasse.
Les lasses sont identi ables :
soit par laClass_ID (detype u32)attribuée par l'utilisateurau travers de l'interfa e t ,
soit par l'Internal_ID (de type unsigned long) attribué par la le. Cet ID est unique et
estdonné ave une le,il peutêtre unindex, unpointeur... 5
Dans le noyau, le seul moyen de faire référen e à une lasse est par son Internal_ID. Seules les
fon tions get et hange utilisent Class_ID. Plusieurs Class_ID peuvent être regroupés en un
unique Internal_ID, dans e asleClass_ID transporte desinformations additionnelles pour le
lassi eurasso iéaux les. 6
Anoter quetoutes les les d'attentesne supportentpasles lasses.Cellesqui lessupportent
sont :CBQ, DS_MARK, CSZetPRIO.
Il est également possible d'appliquer des politiques de tra (en anglais :poli ing) entre les
lassi eurs et les ordonnan eurs. Ces poli ing sont utilisées pour que le tra n'ex ède pas
ertaines bornes...
De même que pour les les d'attentes, les lasses possèdent un ensemble de fon tions de
ontr le dé nies dansin lude/net/pkts hed.h :
stru t Qdis _ lass_ops
5
Anoter:lavaleur0pourunInternal_IDapoursigni ation: lassenontrouvéelorsque ettevaleuraété
retournéeparlafon tionget.
6
Remarque:laraisondel'implémentationdesdeuxvariablesClassIDetInternalIDestdedonnerunefa ilité
denotationàl'utilisateur.Lapremièrevariableestusitéeparl'utilisateurqui rééses lassesasso iéesàsa leave
saproprenotation.Lenoyau,lui,utilisesaproprenotation orrespondante.Lorsdestestsetdel'implémentation
{
/* Child qdis manipulation */
int (*graft)(stru t Qdis *, unsigned long l, stru t Qdis *, stru t Qdis **);
stru t Qdis * (*leaf)(stru t Qdis *, unsigned long l);
/* Class manipulation routines */
unsigned long (*get)(stru t Qdis *, u32 lassid);
void (*put)(stru t Qdis *, unsigned long);
int (* hange)(stru t Qdis *, u32, u32, stru t rtattr **, unsigned long *);
int (*delete)(stru t Qdis *, unsigned long);
void (*walk)(stru t Qdis *, stru t qdis _walker * arg);
/* Filter manipulation */
stru t t f_proto ** (*t f_ hain)(stru t Qdis *, unsigned long);
unsigned long (*bind_t f)(stru t Qdis *, unsigned long, u32 lassid);
void (*unbind_t f)(stru t Qdis *, unsigned long);
/* rtnetlink spe ifi */
int (*dump)(stru t Qdis *, unsigned long, stru t sk_buff *skb, stru t t msg*);
};
1. graft: atta he une nouvelle le à une lasse et retourne la le pré edemment utilisée. Si
au une len'aétédé nie, lafon tion atta he ladis iplineFIFOà la lasse.
2. leaf:retourne la led'une lasse.
3. get:permetd'obtenirl'Internal_ID par laClass_ID.Cettefon tionin rémenteun
omp-teurd'utilisation des lasses:ref ntsila lasse maintient untel typede ompteur.
4. put:est utilisé lorsqu'une lasse pré edemment référen épar getestdéréféren é. Sirf nt
estprésent,il estdé rémenté.
5. hange: hangelespropriétésdela lasse.Egalementutilisépour réerdenouvelles lasses.
6. delete:supprime une lasse si elle- i n'est pas en ours d'utilisation. Cette fon tion
dé-terminel'utilisation dela lasseen regardant le ompteur: ref ntetsi elui- iest àzéro,
désa tive etsupprime la lasse.
7. walk:fon tion de diagnostique.
8. t f_ hain: ettefon tionestutiliséepourretournerlepointeursurlalistede ltresasso iés
àune lasse. Eneet, haque lasse estasso iéeave une listede ltres ontenant tous les
ltrespouvantidenti erlespaquetsappartenantà elle- i.Despaquetsayantdespropriétés
diérentes, omme une adresse sour e diérente, peuvent être regroupés dans la même
lasse.Ainsi, il peutyavoirplusieurs ltres asso iés à une lasse.
9. bind_t f : ette fon tion atta he un ltre à une lasse. Cette fon tion est similaire à la
fon tion get dans le sens où elle possède un ompteur d'utilisation des ltres : filters.
Celuiestin rémentéà haque appeldela fon tionbind_t f. 7
10. unbind_t f:déta heun ltredesa lasseetdé rementele ompteurd'utilisationdes ltres.
11. dump_ lass:fon tion de diagnostique.
3.5.1 Fon tionnement de l'instan iation en lasse des paquets
Les lasses sont séle tionnées dans la fon tion enqueue de la dis ipline de le d'attente par
appel de t _ lassify (in lude/net/pkt_ ls.h) qui retourne une stru ture stru t t f_result
(in lude/net/pkt_ ls.h) ontenant leClass_ID etselon[Alm99℄ probablement l'Internal_ID.
La valeurretournée par t _ lassifyest soit :
soit -1:TC_POLICE_UNSPEC,
soit ladé isionpolitiquedu ltre.
Lesvaleursderetoursontdé laréesdansin lude/linux/pkt_ ls.h.dontvoi iunepartie du ode
i-dessous: . . . stru t t _poli e { __u32 index; int a tion; #define TC_POLICE_UNSPEC (-1) #define TC_POLICE_OK 0 #define TC_POLICE_RECLASSIFY 1 #define TC_POLICE_SHOT 2 __u32 limit; __u32 burst; __u32 mtu; stru t t _ratespe rate;
stru t t _ratespe peakrate;
};
.
.
.
3.6 Prin ipe des ltres ou lassi ers
Les ltres sont utiliséspour lasser les paquetsen se basant sur ertaines valeursde hamps
ontenusdansl'en-têtede elui- i.Exemple,le hampTOSdansIPV4,lesadressesIP,lenuméro
deport,...Un ltre estutilisélorsquelafon tion demiseen led'attente:enqueueestinvoquée.
Les dis iplines de les d'attente utilisent les ltres pour mettre les paquets entrant dans leurs
lasses respe tives. Ces les d'attente possèdent don enamont des lassi ersqui permettent de
distinguer les uxde plusieurs lassesde paquets.
Les ltres/ lassi er ont au nombrede 5:
ls_rsvp: lassi erRSVP IPv4,
Queuing discipline/Classes
Filtre de priorité 1
Filtre de priorité 2
Element C
Element A
Element B
Fig. 3.6Organisation des ltres
ls_route: lassi er sebasantsur ladé isionde routage appliquée aupaquet,
ls_u32 : lassi ersebasant surles ontenus hampsde l'en-têtedu paquet.
Les ltres sont organisés dans une lter_list. Une stru ture : stru t t f_proto ontenue dans
in lude/net/pkt_ ls.hestutiliséepourreprésenterla lter_list.Les ltressont lassésparordre
roissant de priorité etles entrées dansla lter_list sont marquées par le proto ole ave lequel
elle s'applique.
Les ltresserépartissent suivant deuxtypes:
1. Les ltres generiques : Une instan e de ltre par di ipline de le d'attente est su sante
pour haque lasse. Ces ltres utilisent le Class_ID setrouvant dansl'en-tête du paquet.
CetIDaétépré edemment sto ké:soitpar lafon tiondemarquagedu odede rewalling
deLinuxdansle as du ltre ls_fwd,soit par lemarquage delafon tion deroutage dans
le asdu ltre ls_route.
2. Les ltres spe i ques : Il y a une instan e de ltres par lasse, 'est la as pour tous les
autres ltres.
Commenouslemontrela gure3.6page 32,lare her hedansle ltres'ee tueparordre de
priorité.Onpar oursd'abordlesélémentsdelapriorité1,puis2,...La lter_listétant ordonnée
dansl'ordre roissant despriorités. Le hire1 orrespondant àlapriorité laplus haute.
La liste des fon tions on ernant les ltres est spé i ée dans stru t t f_proto_ops dans
in lude/net/pkt_ ls.h.
stru t t f_proto_ops
har kind[IFNAMSIZ℄;
int (* lassify)(stru t sk_buff*, stru t t f_proto*, stru t t f_result *);
int (*init)(stru t t f_proto*);
void (*destroy)(stru t t f_proto*);
unsigned long (*get)(stru t t f_proto*, u32 handle);
void (*put)(stru t t f_proto*, unsigned long);
int(* hange)(stru t t f_proto*, unsigned long, u32 handle, stru t rtattr **, unsigned long *);
int (*delete)(stru t t f_proto*, unsigned long);
void (*walk)(stru t t f_proto*, stru t t f_walker *arg);
/* rtnetlink spe ifi */
int (*dump)(stru t t f_proto*, unsigned long, stru t sk_buff *skb, stru t t msg*);
};
1. lassify : ette fon tion est utilisée pour mettre un paquet dans une lasse en se
ba-sant sur ertaines propriétés de elui- i. Lerésultat de toute lassi ation doitêtre
a om-pagnée des quatre valeurs suivante : TC_POLICE_OK, TC_POLICE_RECLASSIFY,
TC_POLICE_SHOT, TC_POLICE_UNSPEC 8
. (les mé anismes de poli age sont
expli-qués ense tion 3.7).
2. init:initialisation desparamètres du ltre.
3. destroy : fon tion utilisée pour retirer un ltre. Si le ltre est enregitré ave des lasses,
ettefon tionferaappelàunbind_t f(Cf.3.5).Ilenlèveégalement touslespoli er quiont
étéatta hésà la le.
4. get:retournel'Internal_ID du ltre.L'Internal_ID estunevariablede32bitsreferençant
les élementsde la lter_list.
5. put :est invoqué lorsqu'un élément d'un ltre pré edemment reféren é par get n'est plus
utilisé depuis un ertain temps.
6. hange : on gure un nouveau ltre ou hange les propriétés d'un ltre existant. Cette
fon tion enregistre l'addition d'un nouveau ltre ou d'un élement du ltre à une lasse
grâ e àlafon tion bind_t f.
7. delete :supprime un élément du ltre au ontraire de destroy qui détruit le ltre
entiè-rement.Sil'élement était enregistréave une lasse, lefon tion unbind_t fsupprime alors
etenregistrement.
8. walk&dump:fon tionsd'itérationet dediagnostique.
3.7 Prin ipe de politique de tra (poli ing)
Le but de la poli ing est de s'assurer que le tra n'ex ède pas ertaines bornes. En fait, le
ontr le detra sousLinuxpossèdeunedé nitionassez large omprenant touttypede ontr le
de tra dépendant du volume de tra . Il existe quatre types de mé anisme de politique de
tra .
1. Celledé idée par les ltres.
2. Lerefus demettre unpaquet dansune led'attente.
3. De lasserunpaquet d'une led'attente.
4. Retirerunpaquet de la lea n d'enmettre unautre.
La fon tion lassify d'un ltre peut retourner 3 types de valeurs, elles- i sont dé larées dans
in lude/linux/pkt_ ls.h:
1. TC_POLICE_OK :pasdetraitement spé i que.
2. TC_POLICE_RECLASSIFY : les paquets séle tionnés par un ltre mais dépassant une
ertainebornesont re lassi és.
3. TC_POLICE_SHOT :les paquetssele tionnés par un ltre mais dépassant une ertaine
bornesont supprimés.
Les ltres ls_rsvp, ls_rsvp6 et ls_u32 supportent les politiques de tra . Il est né essaire
également que les ordonnan eurs prennent en ompte es hamps, 'est le as de s h_ bq mais
pas elui des h_prio.
Les ltres peuvent utiliser la fon tion t f_poli e ontenue dans net/s hed/poli e. et qui
détermine si le ot est onforme à un token bu ket. Plusieurs dé isions sont alors possible en
fon tiondu résultatdutoken bu ket, [Alm99℄nousdonne unpanel despossibilitésde gestiondu
MISE EN OEUVRE DE LA QoS
4.1 Présentation de la plateforme de test
Les héma4.1page 36 présente laplateforme utiliséepour les tests.
Hylaspossède également deuxalias sursa arte :192.168.1.10 et192.168.1.100. Ces aliasIP
ont été dé nis a n d'ee tuer des testssur la lassi ation des paquets faitespar des ltres. Le
routeur :Youpiet lesdeuxma hines HylasetLy os,sontreliés par un HUB8 ports 10Mb/s.
Le système Linux installé sur le routeur Youpi provient d'une Sla kware 7.0 possédant un
noyau 2.2.13.
Comme indiqué dans l'aide de la on guration du noyau la fon tion de routage est a tivée
grâ e à la ompilation du module : CONFIG_IP_ADVANCED_ROUTER=yet par le positionnement à 1
du ag deroutage dans :
/pro /sys/net/ipv4/ip_forward
Lesdeux artesréseauxsont dé larées dansleLilo grâ eà la ommande:
append=ether=11,0x1000,eth0 ether=15,0x320,eth1
pour de plus amples informations sur ette ommande se référer au Multi-Ethernet-HOWTO
disponible surftp://ftp.lip6.fr
Lestestsee tuéssur ette plateformeont étéfaitsà l'aided'ungénérateurdetra nommé
BENCH. Une présentation de elui- iest diponible enannexe.
4.2 Linux Tra Control : t
4.2.1 Installation et on guration
Ré upérerlepa kage iproute2à l'adressesuivante:ftp://ftp.inr.a .ru/ip-routing/
Ladernièreversionendateà ejourestiproute2-2.2.4-now-ss000305.tar.gz(5mars2000),
a nd'êtresûrdenepassetromper,vouspouveztélé hargeriproute2- urrent.tar.gzquipointe
dire tement surla dernièreversiond'iproute2.
Jusqu'à etteversion,a nd'utilisersansproblème epa kage,ilm'aéténé essaired'appliquer
192.168.1.2/24
192.168.2.3/24
HYLAS
AMD K6 2 300 - 32Mo
192.168.1.1/24
192.168.1.10/24
192.168.1.100/24
LYCOS
Pentium 100 - 48Mo
192.168.2.4/24
YOUPI
Fig.4.1 Plateforme de test
bien que elui- i date du 17 mars 1999, son appli ation for ée m'a permis de orriger des bugs
surl'appli ation de ltres.
Avantde ompiler iproute2,veillez àavoir ompilévotrenoyauLinuxave toutes lesoptions
on ernant la QoS,sinon,la ompilation d'iproute2vousrenverra uneerreur.
#
# Code maturity level options #
# CONFIG_EXPERIMENTAL=y # # Networking options # # CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_FIREWALL=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y
CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_LARGE_TABLES=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_NETLINK=y CONFIG_NETLINK_DEV=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_MASQUERADE=y CONFIG_IP_MASQUERADE_ICMP=y CONFIG_IP_MASQUERADE_MOD=y CONFIG_IP_MASQUERADE_IPAUTOFW=m CONFIG_IP_MASQUERADE_IPPORTFW=m CONFIG_IP_MASQUERADE_MFW=m CONFIG_IP_ROUTER=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_IP_ALIAS=y CONFIG_ARPD=y CONFIG_SYN_COOKIES=y CONFIG_INET_RARP=m CONFIG_SKB_LARGE=y CONFIG_IPV6=m CONFIG_IPV6_EUI64=y CONFIG_IPV6_NO_PB=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_BRIDGE is not set
# CONFIG_LLC is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
# CONFIG_CPU_IS_SLOW is not set
#
CONFIG_NET_SCHED=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NET_SCH_CBQ=y CONFIG_NET_SCH_CSZ=y CONFIG_NET_SCH_PRIO=y CONFIG_NET_SCH_RED=y CONFIG_NET_SCH_SFQ=y CONFIG_NET_SCH_TEQL=y CONFIG_NET_SCH_TBF=y CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_ROUTE4=y CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_U32=y CONFIG_NET_CLS_RSVP=y CONFIG_NET_CLS_RSVP6=y CONFIG_NET_CLS_POLICE=y 4.2.2 Présentation
t estun programmeutilisateur permettant de réer etd'asso ierdes les àune interfa e de
sortie. C'estun touten un, ilest utilisé pour installerdivers types de les,asso ier des lasses à
es les,mettre enpla e les ltres de lassi ation.
Il faitpartie dupa kage iproute2 ontenant également d'autresutilitairestelqueip
permet-tantnotamment d'ee tuer de l'IP aliasing oude l'IP tunneling.
Sa syntaxe estlasuivante:
t [ OPTIONS ℄ OBJECT COMMAND | help
ave :
OBJECT = qdis | lass | filter
OPTIONS = -s[tatisti s℄ | -d[etails℄ | -r[aw℄
qdis :estutilisé pour réer unequeuing dis ipline
lass :estutilisé pour dé nirdes lasses
filter: permetde mettreen pla e des ltres
Lesoptions :
-s permet d'avoir les statistiques de sortie des paquets sur l'interfa e et au travers des
diérentesqueuing dis ipline asso iéeà elle- i,
-d permet d'obtenir tous les détails on ernant l'interfa e et les paramètres passés aux
t peut être assez di le à appréhender. En eet,en as d'erreur le noyau retourne simplement
unentierindiquantlesu èsoul'é he dela ommande.Don ,àpartsivousavezfaituneerreur
dansl'orthographe des ommandes,les seuleserreursque vousretourna t sont lessuivantes:
RTNETLINK answers :No su h file or dire tory: 'estle assivousréféren ezune qdis ,
unparent, une lassequi n'existepas...
RTNETLINK answers:File exists: 'estle asinverse, 'estquevousréféren ezquelque hose
quiexiste déjà.Par exemple,vous réezune queuing dis iplineCBQ enroot, puisun TBF
en root aussi. Pour le TBF, vous obtiendrez e message d'erreur puisque vous avez une
dis iplinede ledéjà atta hée àlara ine.
RTNETLINK answers : Invalid argument : 'est une erreur de paramètres. Exemple, vous
dé nissezun CBQ ave une option perturb.Or ette option faitpartie du SFQ et nondu
CBQ.
4.3 Les Queuing Dis iplines
t qdis [ add | del | repla e | hange | get ℄ dev STRING
[ handle QHANDLE ℄ [ root | ingress | parent CLASSID℄
[ estimator INTERVAL TIME_CONSTANT ℄
[ [ QDISC_KIND ℄ [ help | OPTIONS ℄ ℄
t qdis show [ dev STRING ℄ [ ingres ℄
ave :
QDISC_KIND = [p|b℄fifo | tbf | prio | bq | red | et .
[ add | del | repla e | hange | get ℄ :sont les diérentes opérations disponibles
asso- iéesaux dis ipline de le d'attente. Pour de plus amplesrenseignements voir le Chapitre
3.
dev STRING:Interfa esurlaquelleonatta helaqueuingdis ipline:eth0, eth1, ppp0, ...
[ handle QHANDLE ℄ :nombre majeur hoisipar l'utilisateur a n deréféren er la le.
[ root | ingress | parent CLASSID℄:permetd'atta herune dis iplineàlara ine de
l'in-terfa e (root)ou àune autre leparente.
[ estimator INTERVAL TIME_CONSTANT ℄:voirlase tion 4.6.
Ces dé nitionssont aussivalidesen equi on erne les lassesetles ltresetdon neseront pas
redé nies.
4.3.1 s h_[p|b℄fifo
Usage:t qdis ... [p|b℄fifo [limit NUMBER℄
Commeill'est indiquédanslenomde ette dis ipline,les paquetsnere oivent au un
traite-ment spé i que. Ilssont toutsimplement FirstIn FirstOut.
Cettedis iplinene gère pasles lasses.
jetons
Buffer
Rate : taux de regénération des
Limit
Fig. 4.2Token Bu ket
[limit NUMBER℄: orrespond àlalongueur dela leexpriméeenpaquetsou enbytesselon
que l'ona hoisipfifoou bfifo.
4.3.2 s h_tbf
Usage :t qdis ... tbf limit BYTES burst BYTES[/BYTES℄ \
rate KBPS [ mtu BYTES[/BYTES℄ ℄ [ peakrate KBPS ℄ [ laten y TIME ℄
Cettedis iplinenegèrepasles lasses, 'estàdirequ'endé nissantleTBF ommedis ipline
de le d'attente ra ine de l'interfa e de sortie, et vu que elle- i ne sait pas gérer de lasse de
tra ,touslespaquetssortantserontalors soumisàson ontr le.Anoterquelavaleurdu burst
estlimitéeà 640 Kbit.
La syntaxe utiliséepour atta herun TBF sureth1par exemple estlasuivante:
t qdis add dev eth1 root handle 1 : tbf rate 64kbit buffer 1
5kb limit 10kb
Le Token Bu ket Filter estune mise en led'attente simple.Elle nefait que passerles paquets
entrant ave un tauxde transfert dont les bornes limitessont xéespar l'administrateur.
Comme nous le montre la gure 4.2 page 40, l'implémentation d'un TBF onsiste en un
tampon(buffer,seau), onstamment remplipar desjetons,ave undébit spé i que(rate, débit
de jeton). Le paramètre le plus important du tampon est sa taille, qui est le nombre de jetons
qu'ilpeutsto ker.
Chaquejetonarrivantlaissesortirunpaquetdedonnéesentrantdela led'attente.Cepaquet
estalorsea éduseau.L'asso iationde etalgorithmeave lesdeux uxdejetonsetdedonnées,
nousdonne troiss énarios possibles:
Lesdonnées arrivent dansleTBFave un débitégal audébit desjetonsentrants. Dans e
as, haquepaquet entrant a sonjeton orrespondant etpassela le d'attente sansdélai.
UDP1
UDP2
UDP3
Y
X
2.5000
3.0000
3.5000
4.0000
4.5000
5.0000
5.5000
6.0000
6.5000
7.0000
7.5000
8.0000
0.0000
5.0000
10.0000
15.0000
20.0000
25.0000
30.0000
Fig. 4.3 Génération de 3 ux UDP à des taux respe tif de 500, 1000 et 1500 paquets par
se onde.
Les données arrivent dans le TBF ave un débit plus petit que le débit des jetons. Seuls
quelquesjetonssontsupprimésquandlespaquetsdedonnéessortentdela led'attente.Les
jetons s'a umulent don jusqu'àatteindre lataille du tampon.Lesjetons sauvéspeuvent
être utilisés pour envoyer des données ave un débit supérieur au débit des jetons, si de
ourtesrafalesde donnéesarrivent.
Les données arrivent dans leTBF ave un débit plus grand que ledébit des jetons.Dans
e as, un dépassement de ltre a lieu. Les données entrantes peuvent être envoyées sans
perte jusqu'à e que les jetons a umulés soient utilisés. Après,les paquetsau dessous de
lalimite sont jetés.
La gure 4.3 page 41 nous présente 3 ux UDP générant des paquets d'une taille de 1024
o tetsàdestauxrespe tifsde500paquetsparse onde puisau boutde 10se ondesà1000 pkt/s
eten n, aubout de 10nouvellesse ondes1500 pkt/s. A noterqu'UDP n'aa uséau une perte
de paquetsdurant ette générationde tra . En utilisant unTBF atta hé à l'interfa e desortie
du routeur parla ommandesuivante :
t qdis add dev eth0 root tbf limit 10000 rate 5.461Mbit burst 640Kb
Ave untauxduTBF orrespondantaudébitdu uxUDP2,onobtientlesrésultatsprésentéssur
la gure 4.4page 42 etla gure4.5 page 43qui illustrebien le omportement duTBF expliqué
plus haut.
4.3.3 s h_prio
Usage:t qdis ... prio bands NUMBER priomap P1 P2...
