Universit Cady Ayyad Ecole Nationale des Sciences Appliques de Marrakech

Intitul du projet :

Etude et simulation des techniques de compression den-tte

Ralis par : Mr. BACHIRI Oussama Mlle. BAROUDI Noura Mlle. BENABDELKRIM Iman

Encadr par : Mr. IDBOUFKER Noureddine Composition du jury

Remerciement
Par le prsent travail, on tient tout dabord exprimer notre gratitude envers notre encadreur Monsieur IDBOUFKER pour son aide, ses conseils, sa disponibilit et sa patience. On tient aussi exprimer nos plus vifs remerciements tous le cadre professoral et administratif de lENSA Marrakech. On remercie finalement toute personne ayant contribu de prs ou de loin llaboration du prsent projet.

Table des matires

Remerciement ........................................................................................................................................ 1 Abstract .................................................................................................................................................. 4 Rsum ................................................................................................................................................... 5 ........................................................................................................................................................ 6 Introduction gnrale ............................................................................................................................ 7 Chapitre 1 : Gestion de Projet ............................................................................................................. 8 1. Cahier de charge ........................................................................................................................... 9 1.1 Objectifs du projet .................................................................................................................. 9 1.2 Phasage du projet ................................................................................................................... 9 2. Diagramme de Gantt prvisionnel ............................................................................................ 10 3. Rseau de tches prvisionnel ................................................................................................... 10 4. Diagramme de Gantt Rel ......................................................................................................... 11 5. Rseau de tches rel .................................................................................................................. 11 Chapitre 2 : Etat de lart de la compression den-tte ..................................................................... 12 Introduction ..................................................................................................................................... 13 1. Les Algorithmes de compression................................................................................................ 13 1.1 Contexte.................................................................................................................................. 13 1.2 Classification des en-ttes ..................................................................................................... 13 1.3 Algorithmes de Codage ......................................................................................................... 14 1.4 Algorithme de Rgnration de contexte............................................................................. 15 2. Les Protocoles de compression .................................................................................................. 16 2.1 Compression des en-ttes TCP/IP ....................................................................................... 16 2.2 CTCP & CRTP ..................................................................................................................... 17 2.3 Enhanced Compressed Real-Time Transport Protocol) .................................................... 18 2.4 ROHC .................................................................................................................................... 18 3. la compression d'en-tete dans le cas opensource ..................................................................... 27 4. Etude comparative ...................................................................................................................... 27 5. les domaines d'applications de la compression d'en-tte (3g, 4g,...) ....................................... 28 Conclusion ........................................................................................................................................ 28 Chapitre 3 : Etude des outils dvaluation de performance et inventaire des prrequis de test .. 29 Introduction : ................................................................................................................................... 30 1. Etude et benchmarking doutils dvaluation de performance .............................................. 30 1.1 IP Level Service Agreement : ............................................................................................... 30 1.2 MRTG .................................................................................................................................... 30 1.3 Cacti ........................................................................................................................................ 31

3 1.4 Open NMS ............................................................................................................................. 32 1.5 WhatsUp Gold ...................................................................................................................... 33 1.6 PRTG Network Monitor ....................................................................................................... 33 1.7 Sevone Voip performance monitoring ................................................................................. 34 2 Inventaire des pr-requis de test ................................................................................................. 34 2.1 IPSLA .................................................................................................................................... 34 2.2 MRTG sous Windows .......................................................................................................... 36 2.3 Autre Outils ........................................................................................................................... 39 Chapitre 4 : Design de plateforme de simulation et reporting des rsultats de tests ................... 41 Introduction ..................................................................................................................................... 42 1. Plate-forme dvaluation des performances et scnarios de validation.................................. 42 2. Reporting des rsultats .............................................................................................................. 43 2.1 Paramtres de scnario et conditions de test....................................................................... 43 2.2 Paramtres de scnario ........................................................................................................ 43 2.3 RTT Max ............................................................................................................................... 44 2.4 Utilisation de la bande passante .......................................................................................... 45 Conclusion ........................................................................................................................................ 47 Conclusion gnrale ............................................................................................................................ 48 Rfrences ............................................................................................................................................ 49 Glossaire ............................................................................................................................................... 50 Liste de figures ..................................................................................................................................... 52 Annexes ................................................................................................................................................ 53

Abstract

The use of the compression mechanisms reduces the transmission time and increases the use of networks resources. Header compression also means the elimination of the redundancy in the transmitted information which results in packet loss if an error occur. Headers compression mechanisms as ECRTP, ROHC integrate features for compression that give better performance over noisy networks. The concept behind header compression protocols is to reduce the redundancy of information contained in a header, also the redundancy between consecutive headers. Thus information which is not changed is sent at the beginning of the session. The work of this project will focus primarily on the development of a network and monitoring platform of a header compression protocol and analysis of results obtained by a set of tools like IP SLA and MRTG, which allowed us to see the positive impact of the compression header on a set of parameters such as the Round Trip Time and the bandwidth utilisation.

Keywords: header compression, ECRTP, ROHC, network monitoring, IP SLA, MRTG.

Rsum

L'utilisation des mcanismes de compression permet de rduire le temps de transmission et augmenter l'utilisation des ressources. Mais la compression des en-ttes signifie aussi la rduction de la redondance dans l'information transmise qui se traduit par la perte des paquets s'il y erreur. les mcanismes de compression des en-ttes comme ECRTP et ROHC intgrant des fonctionnalits pour la compression qui donnent une meilleure performance aux flux compresss quand ils sont transmis sur les rseaux bruits. Le principe la base de la compression d'en-ttes est la rduction de la redondance de l'information contenue dans un en-tte, mais aussi la redondance entre plusieurs en-ttes conscutifs. Ainsi l'information qui ne change pas est envoye au dbut de la session; pour les autres champs, un mcanisme de prdiction ou de dpendance permet de rduire encore l'information transmise. Les travaux de ce projet se concentrent principalement sur l'laboration d'une plate-forme de compression d'en-tte, la simulation du protocole de compression den-tte CRTP, et l'analyse des rsultats obtenus par un ensemble d'outils, qui nous a permis de voir l'impact positif de la compression d'en-tte sur un ensemble de paramtres tels que le dlai de transfert et le taux d'utilisation de la bande passante.

Mots cls : mcanisme de compression, CRTP, ECRTP, protocole de compression.

. . . . . , . , , , , .

: , .

Introduction gnrale

La compression des en-ttes des paquets IP dans les rseaux de donnes est apparue partir des annes 1990 quand lInternet a commenc se dmocratiser et que les particuliers ont voulu se connecter depuis leur domicile laide de modems. Diffrents groupes de travail au sein de lIETF (Internet Engineering Task Force) ont commenc satteler au problme et ont entrepris damliorer les performances dInternet en particulier pour la prise en charge dIP sur des liaisons srie bas dbit. La compression des en-ttes est une de ces nouvelles fonctionnalits qui ont t conues pour amliorer la performance des liaisons sries bas dbit. Les premiers mcanismes de compression ont t cibls uniquement pour les flux TCP/IPv4 qui reprsentaient la majorit du trafic. Depuis, de nouvelles applications sont apparues et des services multimdias se sont dvelopps entranant une augmentation du trafic utilisant le protocole UDP, mettant mal les mcanismes de compression den-tte prcdemment dfinis. Laugmentation du nombre dquipements connects sur lInternet a fait apparatre galement le problme de pnurie dadresses. LIETF a donc entrepris de dfinir une nouvelle version du protocole IP (appele IPv6 pour IP version 6) permettant de saffranchir des problmes dadressage dont souffre la version prcdente IPv4. Un en-tte IPv6 est sur 40 octets alors que celui dIPv4 est sur 20 octets. Toutes ces volutions ont conduit la redfinition des mcanismes de compression des en-ttes avec CTCP et CRTP. Le dveloppement de nouveaux mcanismes est toujours ncessaire car la tlphonie cellulaire veut intgrer des services de lInternet, principalement les services multimdia, et offrir galement une connectivit vers lInternet aux utilisateurs. Ainsi les release 99, 4 et 5 du standard de tlphonie cellulaire dit de 3e gnration, UMTS (Universal Mobile Telecommunication System) ajoutent dans leur pile protocolaire la compression des en-ttes pour prendre en compte le taux lev derreur de transmission sur le lien radio. On parle alors de la compression robuste des en-ttes ROHC.

Chapitre 1 Gestion de projet

Une des cls de la russite dun projet est la planification. Elle consiste dterminer et ordonnancer les tches dun projet et estimer leurs charges respectives. Simple d'utilisation, pratique mettre jour, et facilement comprhensible, le diagramme de Gantt est aujourdhui communment utilis pour planifier les projets. Le diagramme des Figures suivantes illustre lenchainement et la dure des diffrentes tches de la ralisation de notre projet.

1. Cahier de charge :
1.1 Objectifs du projet : La qualit de service vise la diffrentiation de traitement par le rseau travers des mcanismes intelligents traitant les flux en fonction de leurs comportements et de leurs exigences tout en optimisant les ressources rseaux. La compression den-tte est un concept ayant vu le jour aux annes 90 dans lobjectifs est loptimisation de lutilisation des liens de transmission. Plusieurs algorithmes et protocoles ont vu le jour visant la minimisation des informations transportes comme sur-dbit protocolaire. Ce projet vise ltude et la simulation de quelques protocoles de compression den-tte. 1.2 Phasage du projet : Phase 1 : Etat de lart des techniques de compression den-tte ; Protocoles de compression ; Algorithmes de compression ; Etude comparative. Phase 2: Choix de la plateforme de simulation ; Elaboration de simples scnarios de simulation. Phase 3 : Etude et benchmarking doutils dvaluation de performance ; Inventaire des prrequis de test ; Design et mise en uvre dune plate-forme dvaluation des performances. Phase 4 : Mise en oeuvre et paramtrage des diffrents mcanismes de compression den-tte ; Elaboration des scnarios de validation ; Reporting des rsultats de tests.

10

2. Diagramme de Gantt prvisionnel :

Figure 1.1 : Gantt prvisionnel

3. Rseau de tches prvisionnel :

Figure 1.2 : Rseaux des taches prvisionnelles

11

4. Diagramme de Gantt Rel :

Figure 1.3 : Gantt rel

5. Rseau de tches rel :

Figure 1.4 : Rseau de tches rel

12

Chapitre 2 Etat de lart de la compression den-tte

13

Introduction
Le principe la base de la compression den-ttes est la rduction de la redondance de linformation contenue dans un en-tte, mais aussi de la redondance entre plusieurs en-ttes conscutifs. Ainsi, linformation qui ne change pas nest envoye quau dbut de la session ou un faible rythme ; pour les autres champs, un mcanisme de prdiction ou de dpendance permet de rduire encore linformation transmise. En 1990, Van Jacobson (VJ) proposait un mcanisme, compressant len-tte TCP/IPv4 de 40 octets 4 octets, bas sur la redondance de linformation. Il existe dautres propositions pour les diffrents en-ttes comme les en-ttes UDP/IP, UDP/RTP/ IP, TCP/IP. Elles sont bases sur le mme principe que celui de VJ, mais elles supportent les options de TCP et la compression de IPv6 : la compression CTCP (TCP/IP Header Compression), qui gre un nombre important de flux parallles et qui donne une importance au protocole IPv6, et la compression CRTP (IP/UDP/RTP Header Compression) qui utilise le principe de CTCP pour faire la compression de flux RTP.

1. Les Algorithmes de compression

1.1. Contexte Les algorithmes de compression utilisent un contexte pour stocker linformation den-ttes redondante dans les flux de donnes. Le compresseur et le dcompresseur contiennent le contexte avec linformation du dernier entte.

Figure 2.1 : Paradigme dune transmission avec compression den-ttes Les flux arrivent lmetteur qui va compresser len-tte, celui-ci garde les valeurs originales de len-tte appeles contexte compresseur. Lquipement rcepteur dcompresse len-tte et garde les valeurs comme contexte dcompresseur. 1.2 Classification des en-ttes Tous les protocoles de compression utilisent des algorithmes de classification des champs den-ttes, la classification est base sur le changement des valeurs des champs den -ttes pendant une session. On va voir les diffrentes classifications et leur signification utilises par les protocoles.

14

VJ CONSTANT VARIABLE

CRTP INFERED [1] RANDOM [2] NO_CHANGE

[3]

ROHC INFERED [1] STATIC_DEF [3] STATIC_KNOWN

[5]

DELTA

[4]

STATIC [6] CHANGING [7]

Figure 2.2 : Tableau des classes de champs den-ttes utilis par les protocoles VJ, CRTP, ROHC. INFERED [CRTP, ROHC] sont les champs quon peut en dduire partir de lexamen du paquet et ils sont jamais envoys. RANDOM sont les champs dune valeur variable et ils sont envoys dans chaque paquet. NO_CHANGE [CRTP], STATIC_DEF [ROHC] sont les champs dune valeur fixe et ils sont envoys au dbut de la transmission. DELTA sont les champs avec une valeur variable mais prdictible et ils sont envoys cods dans tous paquets. STATIC_KNOWN sont les champs connus et ils sont jamais envoys. CHANGING peuvent tre subdivis en cinq sous-classes : SEMISTATIC sont les champs qui change occasionnellement ou se rinitialise aprs un nombre de paquets. RARELY_CHANGING sont les champs qui changent rarement. ALTERNATING sont les champs que leur valeur appartient un ensemble petit de valeurs diffrentes IRREGULAR sont les champs qui nont aucun model de changements. Comme RANDOM. 1.3 Algorithmes de Codage 1.3.1 Codage Diffrentiel

La valeur compresse dun champ est la diffrence entre la valeur de champs actuelle et la valeur du champ de len-tte prcdent. Vc = Vi - Vi-1 Vc : Valeur Compresss Vi : Valeur de champs actuelle Vi-1 :Valeur de champs prcdentes Cette diffrence est appele DELTA, est utilis dans len-tte des formats de paquets compresss, le dcompresseur ainsi peut calculer la valeur actuelle du champ en ajoutant au DELTA son contexte qui nest rien que la valeur de len-tte prcdent.

15

1.3.2

Codage LSB

Le codage LSB est utilis pour les champs den-tte qui ont un modle de changement faible comme CHAGING. Avec le codage LSB les x bits moins significatifs sont envoys, aprs avoir reu les x bits le dcompresseur calcule la valeur originale en utilisant la valeur v_ ref dans son contexte.

Figure 2.3 : exemple du codage LSB 1.3.3 Codage W-LSB

Dans cet algorithme de codage on dfinit la taille de la fentre w qui est le nombre de paquets, chaque fois quont atteint cette fentre la valeur v_ref dans son contexte change, on ajoute w et la valeur des x bits LSB est rinitialise.

Figure 2.4 : exemple de codage W-LSB

1.4 Algorithme de Rgnration de contexte 1.4.1 Slow Start

La synchronisation des contextes entre compresseur et dcompresseur est trs importante pour tous les protocoles de compression, dans un cas ou le dcompresseur perd son contexte, cet algorithme envoi son contexte avec une priode qui augmente exponentiellement. Le problme que pose cet algorithme en cas dune liaison trs bruit le dcompresseur risque de perdre un nombre important de paquet original et compress entre deux instants de rgnration car ce dernier crot exponentiellement.

16

1.4.2

Algorithme de Temporisation

En plus de lalgorithme Slow-Start on va ajouter deux temporisateurs T1, T2. T1 : se base sur le nombre de paquets compresss pour calculer la vitesse du flux compress. T2 : il est bas sur le temps. Lorsque la vitesse du flux est faible on dclenche le temporisateur T2, quand ce dernier est fini un paquet original est envoy.

Packet original

Packet compress

Vitesse de flux diminue

T1

T2

Packet original

Figure 2.5: Algorithme Slow-Start avec temporisation En plus de lalgorithme Slow-Start on va ajouter deux temporisateurs T1, T2. T1 : se base sur le nombre de paquets compresss pour calculer la vitesse du flux compress. T2 : il est bas sur le temps. Lorsque la vitesse du flux est faible on dclenche le temporisateur T2, quand ce dernier est achev, un paquet original est envoy.

2. Les Protocoles de compression :

2.1 Compression des en-ttes TCP/IP : Pendant plusieurs annes, la proposition de Van Jacobson tait le seul mcanisme de compression disponible. La principale caractristique est quil enlve la redondance dans linformation des en-ttes successifs dun flux TCP/IPv4. Le mcanisme VJ consiste mettre le diffrentiel entre deux en-ttes de paquets conscutifs sur une mme connexion TCP, donc seuls les champs qui ont chang sont transmis. Le compresseur utilise trois types de paquets pour envoyer linformation reue : TYPE_IP, UNCOMPRESSED_TCP et COMPRESSED-TCP. Type_IP: est le paquet originel sans compression, et utilis quand le paquet compresser est un fragment dIP, ou si TCP comporte des options. UNCOMPRESSED_TCP: si le paquet nappartient pas une connexion ouverte et identifie, ou sil actualise linformation du contexte. COMPRESSED_TCP: sert envoyer le delta des champs qui ont chang.

17

Le mcanisme VJ est limit puisquil ne prend pas en compte les flux TCP avec des options, qui sont de plus en plus utilises vu des extensions de TCP, ni les flux UDP. Avec le dveloppement de la nouvelle version dIP, le mcanisme VJ est devenu obsolte. Le compresseur cre un contexte avec lidentificateur et linformation dans len-tte. Chaque station garde pour chaque sens de la transmission un contexte avec la dernire information de len-tte. Le paquet COMPRESSED_TCP envoie le delta des champs qui ont chang et actualise le contexte avec la dernire information. Quand le contexte est perdu cause derreurs de transmission, le dcompresseur doit attendre un en-tte non compress pour resynchroniser linformation. Le mcanisme de compression des en-ttes se base sur les proprits de TCP pour rcuprer son contexte automatiquement. Le mcanisme VJ est limit puisquil ne prend pas en compte les flux TCP avec des options, qui sont de plus en plus utiliss cause des extensions de TCP, ni les flux UDP. Avec le dveloppement de la nouvelle version dIP, le mcanisme VJ est devenu obsolte. 2.2 CTCP & CRTP : LIETF a tendu le mcanisme VJ en dfinissant le CTCP, qui compresse les flux TCP avec ou sans options, les flux UDP, et les flux utilisant le protocole IPv6. Tandis que le mcanisme CRTP compresse les flux multimdia en prenant en compte len-tte du protocole RTP. CTCP et CRTP utilisent un identificateur de flux pour les flux conscutifs, qui est ajout len-tte de chaque paquet, ensuite les champs sont classifis et envoys dans diffrents paquets. La classification pour CTCP et CRTP est faite en prenant en compte des changements dans la valeur des champs. Quatre catgories sont dfinies : INFERRED champs avec une valeur qui peut tre connu par lexamen du paquet, et ne sont jamais envoy; RANDOM champs avec une valeur variable, et sont envoys dans chaque paquet; NO_CHANGE : Champs avec valeur fixe et sont envoys au dbut de la transmission; DELTA : Champs dont la valeur change avec une variation rgulire qui est toujours envoye. CTCP et CRTP utilisent un contexte maintenu entre le compresseur et le dcompresseur. Le contexte contient : tous les champs de len-tte du dernier paquet envoy, le delta des valeurs RANDOM, la dernire modification du numro de squence et le codage pour les champs DELTA. Pour tablir le contexte parce quil est perdu, ou pour initier la communication, CTCP et CRTP utilisent lalgorithme Slow-Start et deux temporisateurs. Le dcompresseur en cas derreur essaie de rparer len-tte avec lalgorithme Twice. Ces mcanismes utilisent diffrents types de paquets pour envoyer les donnes. FULL_HEADER: utilis initialement ou quand le contexte est perdu.

18

COMPRESSED_RTP, COMPRESSED_UDP, COMPRESSED_TCP envoient les diffrentiels des champs DELTA et RANDOM. COMPRESSED_NON_TCP envoie un paquet compresss qui nest pas TCP. COMPRESSED_TCP_NODELTA utilis si le dcompresseur demande les valeurs de len-tte sans codage. CONTEXT_STATE acquittement ngatif du dcompresseur pour les paquets reus avec erreur.

Lutilisation de lalgorithme Slow-Start donne une rgnration exponentielle du contexte, mais la priode est rduite par les deux temporisateurs. Si une erreur se produit, le dcompresseur essaie de rparer len-tte avec lalgorithme Twice, mais si lerreur continue, une requte de contexte est demande au compresseur. Quand le paquet CONTEXT_STATE arrive au compresseur, lalgorithme Slow-Start est rinitialis, et les paramtres sont envoys par le paquet FULL-HEADER. 2.3 Enhanced Compressed Real-Time Transport Protocol): ECRTP (Enhanced CRTP) a tait dveloppe dans la perspective damliorer les performances de CRTP sur les liens avec un taux derreur trs lev et un RTT long. Pour Ce faire, ECRTP fait appel un mcanisme hybride qui se base sur une boucle ouverte/ferme pour la correction derreur. La Boucle Ferme est similaire celle de CRTP, cest la transmission du CONETXTE_STATE paquet lorsque le dcompresseur perd la synchronisation avec le compresseur. La diffrence entre ECRTP et CRTP est la boucle ouverte, en effet, le compresseur envoie le contexte multiple fois, par exemple lors dun changement dune valeur, le compresseur envoie le contexte N fois, de cette faon, le dcompresseur sassure de lintgrit du contexte mme dans un milieu bruit. ECRTP ajoute aussi des extensions qui permettent lenvoie de la valeur absolue au lieu de la diffrence de quelques valeurs volatiles, et un checksum pour assurer de lintgrit des enttes compresss.

2.4 ROHC : Lalgorithme de compression den-tte ROHC a t dvelopp pour rduire la taille des paquets IP transmis sur un lien caractris par un BER lev et un long RTT. Pour compresser len-tte, ce mcanisme effectue une classification du champ den-tte. Cette classification est base sur la manire avec laquelle la valeur de len-tte change durant la transmission dun flux. Le mcanisme ROHC dfinit 5 types de classes : INFERED, STATIC-DEF, STATICKNOWN, STATIC, CHANGING. La dernire classe est subdivise en 4 sous-classes : SEMISTATIC, RARELYCHANGING, ALTERNATING, IRREGULAR.

19

INFERED : Ces champs contiennent des valeurs qui peuvent tre dduites dautres valeurs, par exemple la taille de la trame qui porte le paquet, et nont donc pas tre traites du tout par le schma de compression. STATIC : Ces champs sont supposs tre constants tout au long de la dure de vie du flux de paquets. Les informations statiques doivent dune certaine faon tre communiques une fois. STATIC_DEF : Les champs STATIC dont les valeurs dfinissent un flux de paquets. Ils sont en gnral traits comme STATIC. STATIC_KNOWN : Ces champs STATIC sont supposs avoir des valeurs bien connues et nont donc pas besoin dtre communiqus du tout. CHANGING peuvent tre subdivis en quatre sous-classes : SEMISTATIC : sont les champs qui change occasionnellement ou se rinitialise aprs un nombre de paquets. RARELY_CHANGING : sont les champs qui changent rarement. ALTERNATING : sont les champs que leur valeur appartient un ensemble petit de valeurs diffrentes. IRREGULAR : sont les champs qui nont aucun model de changements.

Figure 2.6 : Classification des champs de len-tte IPv4 Au dbut, les informations statiques sont envoyes au dcompresseur, puis le niveau de compression augmente en envoyant les informations dynamiques. Le principe du ROHC est denvoyer le minimum dinformation tout en gardant une robustesse maximale. 2.4.1 Le contexte ROHC : ROHC utilise un contexte maintenu entre le compresseur et le dcompresseur afin denregistrer les informations du flux den-ttes. Ce contexte contient la dernire mise jour de correction de len-tte originale et linformation redondante dans le flux. Ce contexte est maintenu dans le compresseur et le dcompresseur afin de garantir la robustesse du mcanisme. A chaque fois quune valeur change dans le contexte, le contexte est mis jour. Si le contexte est perdu du aux erreurs de transmission, le compresseur et le dcompresseur ne seront plus synchroniss. Le dcompresseur envoie alors une requte de mise jour. Le contexte dans le compresseur et le dcompresseur stocke la partie statique et dynamique de len-tte. Il stocke aussi le temps darrive du paquet, lestampille

20

temporelle du RTP (RTT), le checksum dUDP, la liste de sources RTP (CSRC), les extensions dIPv6, la fentre glissante pour le dcodage du numro de squence, ainsi quune indication davoir reu/envoy des acquittements, les drapeaux pour les extensions de ROHC, le profil qui est en cours dutilisation, ltat des variables Mode et Transition pour le contrle de mode dopration. Chaque flux dans le canal a son contexte, qui est identifi par le CID (Context IDentifier), et il appartient au compresseur de dcider quels paquets associer un contexte(ou, de faons quivalente, quels paquets constituent un seul flux) ; cependant, ROHC nest efficace que lorsque tous les paquets dun flux partagent certaines proprits statiques, par exemple des adresses IP. 2.4.2 La ngociation : La premire phase du protocole ROHC est la ngociation. Dans cette tape, le compresseur et le dcompresseur font la connaissance des caractristiques du lien et les paramtres qui seront utilises pour la compression. Cette ngociation tablie les paramtres suivants : MAX_CID : le plus fort numro didentifiant de contexte utiliser par le compresseur. MAX_HEADER : la taille den-tte la plus large compresser, et dautres informations. MRRU (Maximum Received Reconstructed Unit) : Dans le cas o la segmentation serait utilise, ce paramtre donne la taille maximale en octets de chaque segment. 2.4.3 Les profils ROHC : Les profils dfinissent les en-ttes protocolaires qui doivent tre compresss. Ils permettent au dcompresseur de connatre la version dIP, si le flot utilise RTP ou ESP (Encapsulating Security Payload) ou sil sagit dun flot UDP. Actuellement les profils dfinis sont au nombre de cinq, ce nombre pourra voluer dans le futur : Profil 0 sans compression. Si ce profil est choisi, seul lidentificateur de ROHC est ajout pour que le dcompresseur puisse reconnatre les paquets mais il ny a pas de compression. Profil 1 compression des en-ttes IPv6/v4/UDP/RTP. Ce profil est le plus gnrique, il compresse tout len-tte depuis IP jusqu len-tte RTP. Cest galement le plus utile dans le cas de la VoIP et le plus simple pour la compression car lestampille temporelle et le numro de squence de RTP vont faciliter la mise jour du contexte. Profil 2 compression des en-ttes IPv6/v4/UDP. Ce profil est une variation du profil 1 sauf quici la compression sarrte au protocole UDP. Les formats de len-tte des paquets ROHC sont diffrents de ceux du profil 1. Profil 3 compression des en-ttes IPv6/v4/ESP. Ce profil compresse le protocole ESP, il peut aussi tre pris en compte comme une variation du profil 2. Profil 4 compression des en-ttes IPv6/v4. Ce profil compresse seulement le protocole IP, et ses paquets sont crs sur les formats de paquets du profil 2.

21

2.4.4 Les tats de compression et de dcompression : a. Ltat du compresseur : Pour la compression ROHC, les trois tats de compresseur sont Initialisation et rafrachissement (IR), Premier ordre (FO, First Order) et Second ordre (SO). Le compresseur commence dans le plus bas tat de compression (IR) et transite graduellement aux tats de compression plus levs. Le compresseur va toujours fonctionner dans ltat de compression le plus lev possible, sous rserve que le compresseur soit suffisamment confiant que le dcompresseur ait les informations ncessaires pour dcompresser un en-tte compress conformment cet tat. tat Initialisation et rafrachissement (IR) : Lobjet de ltat IR est dinitialiser les parties statiques du contexte chez le dcompresseur ou de rcuprer aprs dfaillance. Dans cet tat, le compresseur envoie des informations den-tte compltes. Cela inclut tous les champs statiques et non statiques en forme non compresse plus quelques informations supplmentaires. Le compresseur reste dans ltat IR jusqu ce quil soit bien sr que le dcompresseur a reu correctement les informations statiques. tat Premier ordre (FO) : Lobjet de ltat FO est de communiquer efficacement les irrgularits du flux de paquets. Lorsquil fonctionne dans cet tat, le compresseur envoie rarement des informations sur ses champs dynamiques, et les informations envoyes sont usuellement compresses au moins partiellement. Seuls quelques champs statiques peuvent tre mis jour. tat Second ordre (SO) : Cest ltat o la compression est optimale. Le compresseur entre dans ltat SO lorsque len-tte compresser est compltement prvisible et que le compresseur est suffisamment sr que le dcompresseur a acquis tous les paramtres ncessaires.

Figure 2.7 : niveau de compression dans chaque mode dopration b. Ltat du dcompresseur :

22

Au dpart, le dcompresseur travaille dans ltat "Pas de contexte", il na pas encore russi dcompresser un paquet. Une fois quun paquet a t dcompress correctement (par exemple, rception dun paquet dinitialisation avec les informations statiques et dynamiques) le dcompresseur peut passer directement ltat "Contexte plein", et cest seulement en cas de dfaillances rptes quil va revenir des tats infrieurs. Cependant, lorsque cela arrive, il revient dabord ltat "Contexte statique". L, la rception de tout paquet envoy dans ltat FO est normalement suffisante pour activer nouveau la transition ltat "Contexte plein". Cest seulement lorsque la dcompression de plusieurs paquets envoys dans ltat FO choue dans ltat "Contexte statique" que le dcompresseur revient directement ltat "Pas de contexte". Le dcompresseur utilise la rgle dite kn_out_of_nn pour dterminer ltat dans lequel il doit travailler et lacquittement quil doit envoyer au compresseur. k est le nombre de paquets errons reus parmi n paquets envoys. Cette rgle est utilise pour dterminer un contexte endommag. Les valeurs de k et n ne sont pas dfinies dans le standard. Le dcompresseur envoie des NACK jusquau kime1 parmi n1 paquets o il essaie de corriger lerreur. Si la limite de k1 paquets errons est dpasse, le dcompresseur passe dans ltat STATIC_CONTEXT. Le dcompresseur a le contexte endommag. Si le dcompresseur narrive toujours pas poursuivre la dcompression pour ki me2 paquets errons parmi n2, le dcompresseur indique le contexte comme perdu et revient ltat NO_CONTEXT. Il ignore tous les paquets sauf les paquets Initiation (IR). Si la liaison est bidirectionnelle, il envoie un paquet STATIC_NACK au compresseur, si la liaison est unidirectionnelle, il attend lactualisation priodique de len-tte. Le dcompresseur gre aussi les modes de transition en envoyant un acquittement avec le nouveau mode dopration dans lequel il est prfrable de travailler. Il dcide de cette transition en fonction du comportement du lien. Si les caractristiques de la liaison bidirectionnelle le permettent, il peut dcider de travailler en mode fiable (R), pour pouvoir mieux communiquer avec le compresseur. Mais si la liaison est unidirectionnelle il ne peut travailler quen mode unidirectionnel.

Figure 2.8 : la machine dtat du dcompresseur 2.4.5 Les modes oprationnels :

23

Le schma ROHC a trois modes de fonctionnement, appels Unidirectionnel, Bidirectionnel optimiste, et Bidirectionnel fiable. a. Mode Unidirectionnel- Mode U : Quand ils sont dans le mode de fonctionnement unidirectionnel, les paquets sont envoys dans une seule direction : du compresseur au dcompresseur. Ce mode rend donc ROHC utilisable sur les liaisons o un chemin de retour du dcompresseur au compresseur est indisponible ou indsirable. En mode U, les transitions entre les tats du compresseur ne sont effectues quen fonction de temporisations priodiques et dirrgularits dans les schmas de changement de champ den-tte dans le flux de paquets compresss. Du fait des rafrachissements priodiques et du manque de retour pour linitiation de rcupration derreur, la compression dans le mode unidirectionnel sera moins efficace et aura une probabilit lgrement plus forte de propagation des pertes compare tous les modes bidirectionnels. La compression avec ROHC doit dbuter dans le mode unidirectionnel. La transition vers tout mode bidirectionnel peut tre effectue aussitt quun paquet a atteint le dcompresseur et quil a rpondu par un paquet de retour indiquant quune transition de mode est dsire. b. Mode bidirectionnel optimiste mode O Le mode bidirectionnel optimiste est similaire au mode unidirectionnel. La diffrence est quun canal de retour est utilis pour envoyer des demandes de rcupration. Les rafrachissements priodiques ne sont pas utiliss dans le mode bidirectionnel optimiste. Le mode O vise maximiser lefficacit de compression et un usage modr du canal de retour. Il rduit le nombre den-ttes endommags livrs aux couches suprieures du fait derreurs rsiduelles ou dinvalidation du contexte. c. Mode bidirectionnel fiable mode R Le mode bidirectionnel fiable diffre sur de nombreux points des deux prcdents. Les diffrences les plus importantes sont un usage plus intensif du canal de retour et une logique plus stricte aussi bien au compresseur quau dcompresseur qui prvient les pertes de synchronisation de contexte entre compresseur et dcompresseur. Un retour est envoy pour accuser rception de toute mise jour de contexte. Le mode R vise maximiser la robustesse contre la propagation de perte et la propagation de dommage, cest--dire, minimiser la probabilit dune invalidation de contexte, mme dans des conditions de salves de perte/erreur den-tte. Il peut avoir une moindre probabilit dinvalidation de contexte que le mode O.

24

Figure 2.9 : Les modes oprationnels du ROHC 2.4.6 Les paramtres de compression et dcompression : La valeur des paramtres qui ont un impact sur lefficacit et la robustesse du mcanisme de compression ne sont pas prcisment dfinis dans le standard et ne sont pas ngocis initialement. Les paramtres de compression sont : L : dans le mode unidirectionnel (U) et optimiste (O), le compresseur de ROHC utilise la variable de confiance (L) pour assurer la transmission correcte de linformation de lentte. Cette confiance est base sur le nombre de fois (L) que les diffrents formats de paquets des deux premiers niveaux de compression (IR, FO) vont tre mis avant de passer au niveau SO. Si un seul paquet est reu linformation est communique. Timer_1 (IR_TIMEOUT) : dans le mode unidirectionnel (U), le compresseur utilise ce temporisateur pour revenir au niveau IR et retransmettre priodiquement len-tte complet car il ny a aucun moyen de savoir si linformation est toujours bien reue par le dcompresseur. Timer_2 (FO_TIMEOUT): ce temporisateur est utilis par le compresseur en mode unidirectionnel (U) pour descendre priodiquement au niveau FO si le compresseur est au niveau SO. SWW (Sliding Window Width): pendant la compression des champs comme le numro de squence (SN) et lestampilles temporelle (TS : Timestamp), le compresseur utilise le codage W_LSB3 pour rduire leur taille. W_LSB est bas sur une fentre glissante de longueur SWW. k1, n1, k2, n2 : le dcompresseur utilise la rgle dchec (k out of n). Si la liaison est bidirectionnelle un acquittement ngatif sera envoy au compresseur, si k paquets parmi les n derniers reus sont errons. Les valeurs de k1, n1 sont utilises quand la partie dynamique du contexte est endommage et k2, n2 quand la partie statique du contexte est perdue.

25

MODE : dans les formats des en-ttes de paquets, deux bits ont t dfinis pour dterminer le mode dopration dans lequel le compresseur et le dcompresseur vont travailler. Comme indiqu prcdemment, il existe trois modes : Unidirectionnel (U), Bidirectionnel Optimiste (O) et Bidirectionnel Fiable (R). 2.4.7 Format des Acquittements : Les acquittements sont utiliss seulement dans les liaisons bidirectionnelles, deux formats diffrents ont t dfinis. Le premier est utilis seulement pour un acquittement positif. Par contre le deuxime format du paquet acquittement peut servir envoyer un acquittement positif ou ngatif. Dans le deuxime format dacquittement le mode dopration peut aussi tre envoy ainsi que le numro de squence et les options si ncessaire. Les options des acquittements ont une taille variable. Les options peuvent tre : CRC : pour vrifier linformation dans lacquittement ; REJECT : pour rejeter un nouveau flux ; SN-NOT-VALID : quand le numro de squence nest pas valide ; SN : numro de squence ; CLOCK : pour informer le compresseur de la rsolution de lhorloge dans le dcompresseur ; JITTER : le dcompresseur peut donner au compresseur la valeur maximale de la gigue observe; LOSS : le dcompresseur indique la perte maximale de paquets conscutifs. Pour les acquittements sans options, le format est le paquet acquittement 1 o le numro de squence est indiqu. Pour un acquittement en cas de mode de transition ou quand le compresseur a besoin de connatre quelques paramtres du dcompresseur, le format est lacquittement 2 avec ou sans options. 2.4.8 Les modes de transition : Le Mode dOpration dans lequel le compresseur doit travailler est gr par le dcompresseur. Pour aller dun mode dopration lautre, le dcompresseur peut utiliser les 5 modes de Transition. Chaque fois quil est capable de travailler avec un nouveau mode dopration, il lance un acquittement avec le nouveau mode dopration dans lequel il veut travailler. En gnral tous les modes de transition travaillent avec les deux premiers niveaux de compression du mode dopration prcdant qui peuvent actualiser le contexte. Tous les paquets envoys pendant la transition contiennent le CRC pour vrifier linformation. Pour la transition dUnidirectionnel Optimiste, la transition peut tre initie tout instant, le dcompresseur envoie les acquittements avec le CRC et le paramtre mode rgl Optimiste. Si lacquittement est correctement reu le compresseur passe au mode dopration Optimiste directement. Les autres transitions sont possibles seulement aprs avoir initi le contexte. Un acquittement positif ou ngatif avec CRC et le paramtre mode rgl dans le nouveau mode dopration initialise la transition. Pendant la transition le second niveau de compression (SO) ne peut pas tre utilis.

26

Le compresseur et dcompresseur utilisent deux variables pour contrler la transition et interdisent linitiation dune autre transition, les variables de contrle sont : Mode et Transition. Les valeurs de la variable Mode peuvent tre Unidirectionnelle (U), Bidirectionnelle Optimiste (O) et Bidirectionnelle Fiable (R). Une fois initie la transition, la variable Transition prend la valeur I (initiate). Elle prend la valeur P (pending) quand le compresseur/dcompresseur attend un paquet avec le numro de squence de lacquittement initial et le nouveau mode dopration ; elle prend la valeur D (done) quand le procs de transition est fini et acquitt. Si une erreur se produite pendant la transition, les variables de contrle vont rester bloques et elles seront rinitialises au bout dun certain temps, le compresseur va continuer dans lancien mode dopration et le dcompresseur peut dclencher la transition une fois que la variable Transition a la valeur D.

. Figure 2.10 : Les modes de transition ROHC Larchitecture du mcanisme de Compression ROHC est complexe, mais permet de sadapter aux caractristiques du lien, et au flux de donnes. Ce qui reprsente une flexibilit dans le mcanisme travers les diffrents profils et modes dopration. En mme temps ROHC offre une logique pour suivre les transmissions bruites. La dcision du passage dans le dcompresseur pour travailler dans le mode optimiste ou fiable nest pas dfinie et ressort de la mise en uvre. Ainsi comme les valeurs des diffrents paramtres utiliss pour la compression. Il y a des tudes importantes faire comme le paramtrage de ROHC dans les diffrentes liaisons bas dbit, soit PPP soit UMTS, o la performance du protocole pour le rseau radio reprsente un dfi, puisque les erreurs rsiduelles et les transferts intercellulaires ont besoin dun protocole qui assure la compression en travaillant sur trs haut taux derreurs.

27

3. la compression d'en-tte dans le cas open source :

Robust Header Compression (ROHC ) est une mthode normalise dfinie par l'IETF pour comprimer le IP , UDP , RTP , et les en-ttes de paquets TCP Internet . Ce schma de compression diffre des autres systmes de compression par le fait qu'il se comporte bien sur des liaisons o le taux de perte de paquets est lev, tels que les liaisons sans fil.

Dans les applications de streaming, la surcharge de IP, UDP, et RTP est de 40 octets pour IPv4, ou 60 octets pour IPv6. Pour VoIP ce qui correspond environ 60% de la quantit totale de donnes envoyes. Ces grands frais gnraux peuvent tre tolrable dans des liens cbls o la capacit n'est souvent pas un problme, mais sont excessifs pour les systmes sans fil sont la bande passante est rare. ROHC comprime ces 40 octets ou 60 octets de charge gnralement en seulement 1 ou 3 octets en plaant un compresseur avant le lien qui a une capacit limite, et un dcompresseur aprs ce lien. Le compresseur convertit la grande tte de seulement quelques octets, tandis que le dcompresseur fait le contraire.

La bibliothque implmente le protocole ROHC Robust Header Compression (ROHC) telle que dfinie par l'IETF. Son objectif est de fournir une implmentation libre ROHC conformes aux normes ROHC (voir http://rohc-lib.org/wiki/doku.php?id=library-compliance-rfcs pour plus de dtails ) . La bibliothque est publie comme open source sous licence GPL (version2 ou ultrieure).

4. Etude comparative
Le tableau suivant prsente une comparaison entre les diffrents Protocoles de compression den-tte. Enttes TCP IP RTP UDP IP RTP UDP IP RTP UDP IP GRE ESP, AH Taille Minimum de compression 2 octets Algorithm e de Codage DELTA Algorithme de rgnration Algorithme de Classification STATIC VARIABLE INFRED RANDOM NO_CHANG E DELTA Similaire CRTP INFERED STATIC_DEF STATIC_KN OWN STATIC CHANGING(s ous-class)

Protocole Van Jacobson

IP version

IPv4

CRTP

IPv4/6

2 octets

DELTA

Boucle ferm (Temporisation)

ECRTP

IPv4/6

2 octets

DELTA

Boucle ouvert, ferm

ROHC

IPv4/6

1 octet

W-LSB

Temporisation, Mode dopration (acquittement).

28

Van Jacobson est lun des premiers Protocoles de compression, il supporte la compression des en-ttes TCP/IP jusqu' 2 octets on utilisant le codage diffrentielle et en classant les champs den-tte en deux classe, (VJ ne supporte pas IPv6). CRTP/ECRTP vient pour amliorer VJ, en fait ce protocole est propre aux applications temps rel, vu quil compresse RTP/UDP a une taille de 4 2 octets, sa classification est plus prcise que VJ, mais son inconvnient majeur est quil est sensible au bruit. ECRTP vient contourner le problme du CRTP en introduisant des mcanismes dintgrit dinformation. ROHC est sans doute le protocole le plus robuste parmi sa famille, il peut compresser jusqu une taille de 1 octets, il utilise un codage W-LSB qui est plus performant que DELTA, et une classification de champs plus fine que tous autre Protocole, son dsavantage est sa complexit qui introduit des temps de traitement, ce qui nest pas adapt aux applications temps relle.

5. Les domaines d'applications de la compression d'en-tte :

La compression d'enttes RoHC (Robust Header Compression) est une technologie prsente dans LTE l'interface radio o la bande passante est limite et coteuse. RoHC permet de rduire la taille des paquets IP des applications multimdia dans lesquels la taille de payload est souvent petite par rapport la taille d'entte. La deuxime version de RoHC (RoHCv2) simplifie l'implmentation de RoHC et amliore la performance dans le cas de handover. Elle est prise en compte dans l'architecture de LTE. Pour le flux RTP plusieurs voies ont t explores comme la compression den-ttes adaptative pour multimdia en temps rel (ACE) ; la compression den -ttes robustes en utilisant des paquets mot-cl; lalgorithme de compression den-ttes bas sur le checksum (ROCCO). Ces trois derniers travaux sont la base pour le dernier standard de lIETF (Internet Engineering Task Force) pour la compression des en-ttes de flux multimdia ROHC (Robust Header Compression).

Conclusion:
Dans la plupart des services ou dapplications, comme la voix sur IP ou les jeux vido interactifs, la charge utile des paquets IP est presque de la mme taille voir moins que celle des en-ttes. Dans les connexions de bout en bout, ces en-ttes sont extrmement importantes, mais dans les liens hop to hop, ces en-ttes seront compresses et dcompresses la fin du lien. On produit ainsi un gain de 90% en termes de bande passante, ce qui implique une optimisation de lutilisation des ressources.

29

Chapitre 3 Etude des outils dvaluation de performance et inventaire des prrequis de test

30

Introduction :
Lvaluation des performances du rseau permet dobtenir les informations ncessaires pour prendre des dcisions rflchies dordre technique, commercial et financier en matire de mises niveau et de modifications. Ces outils permettent aux administrateurs rseaux dlaborer des analyses, des tests et des mesures du trafic rseau, afin de dterminer si le fonctionnement dun systme existant est cohrent avec les exigences de fonctionnement actuelles et sil dispose de la bande passante et de larchitecture appropries pour grer des exigences ou des quipements supplmentaires. De plus, les donnes qui en rsultent fournissent une base dvaluation de ltat physique et fonctionnel actuel du rseau, qui permet destimer les futurs contrles de maintenance afin de garantir des performances optimales.

1. Etude et benchmarking doutils dvaluation de performance :

1.1 IP Level Service Agreement : Cisco IOS IP SLA utilise une technique de monitoring actif par gnration de trafic. Il peut simuler diffrents protocoles rseau ainsi que des services applicatifs et collecter les informations correspondant au transit de ces donnes sur le rseau. Ceci inclut des mtriques concernant le temps de rponse, la latence unidirectionnelle, la gigue, la perte de paquets, les temps de rponse serveurs. Les diffrentes classes de qualit de service sont prises en compte. Cisco IOS IP SLA est intgr dans le logiciel IOS de Cisco. Il n'y a donc aucun dispositif additionnel dployer. Les mesures sont effectues de bout en bout et peuvent utiliser les diffrents chemins de donnes entre deux points. Il permet galement daider au diagnostic dun problme rseau en gnrant des mesures saut par saut et permettant didentifier quel tronon de rseau est responsable dune dgradation. De plus, Cisco IOS IP SLA permet de prendre en compte la qualit de service. Il est en effet possible de marquer le trafic gnr par Cisco IOS IP SLA afin quil soit associ aux classes de service souhaites. Enfin, Cisco IOS IP SLA permet de surveiller de faon proactive le niveau de qualit VoIP dun rseau. Il est en effet possible de simuler prcisment un trafic VoIP et de calculer les scores de qualit de voix MOS (Mean Opinion Score) et ICPIF (Calculated Planning Impairment Factor) entre deux quipements dun rseau. 1.2 MRTG : MRTG signifie Multi Router Traffic Grapher. Cest un logiciel programm en perl, et dvelopp l'initiative de Tobi Oetikeest, il reprsente un outil de surveillance du trafic sur les liens rseau. Il gnre des pages HTML contenant des images PNG qui fournissent une reprsentation visuelle de ce trafic (occupation mmoire, espace disque, occupation CPU, dbit rseau...). Il se base sur des requtes SNMP excutes intervalles de temps rguliers, collectant les informations du trafic sur lensemble des interfaces des quipements. De plus, sa configuration est simple, et il a le grand avantage de gnrer les graphes sur le web, dtre gratuit, et de se baser sur SNMP qui

31

est le protocole admis comme standard dans le monde informatique pour superviser les quipements rseaux.

Figure 3.1 : Exemple de graphique MRTG. Linconvnient majeur de MRTG, est quil gnre chaque graphique toutes les 5 minutes, consommant ainsi beaucoup de temps systme, et ne comporte que trs peu d'options graphiques personnalisables, Cependant, cest le systme de graphes le plus rpandu pour superviser de manire trs simple et visuelle un rseau.

1.3 Cacti 1.3.1 RRDTool Le programme RRDtool a t dvelopp par Tobias Etiker ds 1995. Il est librement tlchargeable sur Internet. RRD est lacronyme de Round Robin Database, qui peut se traduire par base de donnes cyclique . Ce mcanisme permet de stocker des donnes dans des fichiers de taille invariante, dfinie la cration, par un mcanisme de pile LILO. Un fichier RRD peut contenir plusieurs RRA qui correspondent aux diffrents cycles de conservation des donnes (jour, semaine, mois, anne, etc.). Une fois les donnes collectes, RRDtool fournit des outils permettant de gnrer des graphiques hautement personnalisables, retraitant les donnes la vole. 1.3.2 Cacti Cest est un logiciel de supervision bas sur RRDtool permettant de surveiller lactivit de son architecture informatique partir de graphiques quotidiens, hebdomadaires, mensuels et annuels.

32

Figure 3.2: exemple de graphique Cacti Cette solution nest pas destine alerter en temps rel sur les dysfonctionnements dun systme, mais de proposer une vision dans le temps de lvolution dindicateurs matriels et logiciels (trafic rseau, occupation des disques, temps de rponse, etc). Cacti stocke toute linformation ncessaire pour crer des graphiques et pour les peupler avec des donnes dans une base de donnes MySQL, Il supporte galement SNMP et tend se substituer MRTG pour crer des graphiques. Il offre galement une gestion dutilisateurs qui permet chacun la possibilit de personnaliser linterface mais aussi dy limiter laccs. 1.4 Open NMS : OpenNMS est la premire plate-forme applicative de gestion de rseau de niveau entreprise dvelopp en Java dans le cadre du modle open source, et implmente sur une base Linux. OpenNMS a t conu, ds ses dbuts en 1999, pour rpondre aux exigences des grandes entreprises telles que la scalabilit, l'automatisation et la flexibilit lui permettant ainsi de surveiller plusieurs dizaines de milliers de ressources. Parmi ses nombreuses fonctionnalits on retrouve : la dcouverte et la surveillance automatique des quipements et services, la collection et le traitement de donnes (en SNMP, et autres), la gestion avance d'vnements actifs et passifs, Les alertes et notifications, La gnration de rapports, graphiques et cartes rseaux, etc. L'architecture dOpen NMS est une architecture de serveur Web classique. L'application Open NMS est principalement constitue par une servlet, qui communique avec les lments du rseau l'aide de SNMP et avec les utilisateurs au moyen de pages Web en utilisant le protocole HTTP classique. Cette architecture a le mrite de permettre une gestion de rseau depuis l'extrieur (le port 80 tant en principe transparent aux firewalls), ce qui constitue un dfaut, puisque potentiellement un utilisateur malveillant a accs aux donnes de gestion. Un mot de passe protge l'accs. De plus, pour un rseau complexe (et qui donc mriterait une reprsentation sophistique), on se retrouve souvent confront une salade de fentres superposes sur un cran, et l'on perd la vue d'ensemble, si tant est qu'il y en ait une.

33

1.5 WhatsUp Gold : WhatsUp Gold de lditeur Ipswitch, est une solution puissante de gestion et de surveillance, conue pour administrer aisment les rseaux de toutes tailles, du rseau des PME celui des grandes entreprises. C'est un outil test, prouv et valid sur plus de 100000 rseaux. WhatsUp Gold garantit une visibilit totale, des donnes et un contrle total qui permet de prendre rapidement des dcisions claires. Il comporte plusieurs fonctionnalits : Dtection : Dtection rapide et automatise des priphriques de la couche 3 via de multiples types doptions de dtection. Cartographie : Obtention dune reprsentation hirarchique de la couche 3 du rseau, y compris une image complte du rseau rel ainsi que des informations dtailles sur les sous-rseaux et les rseaux LAN virtuels. Surveillance : exploitation des mcanismes de surveillance active et passive pour assurer le suivi de ltat et de l'intgrit de tous les priphriques du rseau. Alertes : Le Centre d'alertes WhatsUp Gold regroupe l'ensemble des alertes, notifications et validations d'alertes, afin de simplifier les oprations de configuration et de gestion. Le Centre d'alertes est une fonctionnalit exclusive du logiciel WhatsUp Gold. Reporting : Bnfice dune visibilit totale sur l'tat et les performances du rseau grce la fonction de reporting personnalis et aux espaces de travail configurables de WhatsUp Gold. Comporte plus de 200 rapports prdfinis, personnalisables, pour rpondre aux besoins les plus spcifiques. 1.6 PRTG Network Monitor: PRTG Network Monitor couvre lensemble complet de surveillance rseau actuel. Allant de la surveillance de disponibilit la surveillance de bande passante, de consommation et dactivit jusqu la surveillance des Accords sur la Qualit de Service (SLA). Les fonctionnalits de base sont les suivantes :

Surveillance de bande passante, de consommation, dactivit, de disponibilit et des SLA (Accords sur la Qualit de Service). Moteur de logiciel extrmement puissant. Compatible avec des rseaux de tout type et de toute dimension. Surveillance LAN, WAN, WLAN, et VPN des rseaux loigns gographiquement laide de Probes (= agents).

PRTG Network Monitor fonctionne en permanence sur un ordinateur Windows l'intrieur du rseau. Il enregistre les donnes de lutilisation de ce dernier. Les donnes collectes sont alors stockes dans une base de donnes pour tre exploites ultrieurement. Une interface Web intuitive aide administrer le systme, mettre en place les capteurs, configurer des rapports et valuer les rsultats. Il est possible de crer des comptes rendus sur la charge et permettre ses collgues ou clients d'accder en temps rel des graphes et des tableaux.

34

1.7 Sevone Voip performance monitoring: SevOne, dite une solution de mesure de la performance de l'IT pour les entreprises et les oprateurs. SevOne, fournit la plateforme de management de l'IT la plus rapide et la plus volutive. Il permet un reporting et une supervision de l'infrastructure et des applications sous forme d'appliance. La solution aide dtecter de faon pro active les problmes rseau qui impactent les applications mtiers ou les problmes rseaux. SevOne excelle sur trois axes:

Vitesse - Une appliance SevOne est dploye en quelques minutes et gnre des tableaux de bord en temps rel pour la mesure de performance de l'IT. Contrairement aux solutions connues sur le march, les rapports de SevOne sont dlivrs immdiatement. Avec SevOne, il n'est pas ncessaire d'attendre plusieurs minutes voir, pour certaines solutions, plusieurs dizaines de minutes un rapport. Evolutivit - La technologie dploye, SevOne Cluster, permet de monitorer des millions d'objets et de calculer automatiquement des milliards d'indicateurs au sein du rseau sans dgradation de la performance systme. Simplicit - Le tout en un propos par l'appliance SevOne embarque ce qui est ncessaire pour ce quon souhaite monitorer, la collecte, l'analyse le reporting de l'infrastructure sont dans l'appliance. Plus besoin d'agent logiciel, de pr-requis hardware, de licence supplmentaire pour atteindre son objectif.

SevOne apporte, instantanment, aux quipes IT la visibilit, de bout en bout, pour les applications, les systmes, les environnements virtualiss, et la VoIP tout en garantissant les SLA. Les services IT sont enfin capable de troubleshooter les performances rseaux, amliorer le capacity planning et garantir la qualit de service des mtiers.

2 Inventaire des pr-requis de test:

2.1 IPSLA : Cisco IOS IP SLA envoie des donnes travers le rseau pour mesurer la performance du rseau. Il simule les donnes du rseau et des services IP et recueille les informations sur les performances du rseau en temps rel. Cisco IOS IP SLA gnre et analyse le trafic soit entre les priphriques Cisco IOS ou d'un priphrique Cisco IOS un dispositif IP distance. Les mesures fournies par les diverses oprations de Cisco IOS IP SLA peuvent tre utilises pour dpannage, pour l'analyse du problme, et pour la conception de topologies de rseau. IP SLA recueille un sous-ensemble unique dindicateurs de performance: Delay (both round-trip and one-way) Jitter (directional) Packet loss (directional) Packet sequencing (packet ordering) Path (per hop)

35

Connectivity (directional) Server or website download time IPSLA prsente plusieurs avantages: Intgr dans le logiciel IOS ; Excution automatique, en temps rel et prcise de mesures de performances rseau ; Prise en compte de la qualit de service (surveillance de trafic par classe) ; Mesures de bout en bout et mesures saut par saut ; Recherche des chemins de donnes et mesures suivant les diffrents chemins ; Notification proactive en cas de dpassement de seuil ; Surveillance de protocoles applicatifs (http, dns, ftp, dhcp, tcp connect) ; Surveillance VoIP : calcul de MOS et de ICPIF, simulation de codec, prise en compte de DSP hardware ; Surveillance MPLS (test LSP) ; Surveillance VRF (oprations par VRF) ; Configuration en langage de commandes ou via SNMP (mib Cisco-rttmon) ; Rcupration des mtriques via CLI ou via SNMP ; Intgration dans de nombreux outils danalyse de performances Cisco et du march. 2.1.1 Principe de fonctionnement dIP SLA : Un administrateur en mode CLI configure un test IP SLA partir dun routeur ou commutateur. Lagent IP SLA est schedul par exemple pour effectuer des tests priodiques vers une destination. La destination peut tre soit un autre quipement rseau, soit un quipement rseau disposant de la fonction Cisco IOS IP SLA responder, soit une machine IP par exemple un serveur http. La fonction Cisco IOS IP SLA responder dcrite plus loin permet de raliser certains tests particuliers comme la mesure de la qualit de la voix et damliorer la prcision des mesures. Lapplication rcupre les rsultats des mesures sur lagent Cisco IOS IP SLA source soit en SNMP, soit en CLI. Noter quil est possible dhistoriser des mesures en mmoire sur lagent. 2.1.2 Oprations et applications de Cisco IOS IP SLA : Le tableau ci-dessous rsume les oprations disponibles avec Cisco IOS IP SLA.

Tableau : Commandes IP SLA

36

2.1.3 Configuration dIP SLA : La mise en place dIP SLA est trs simple. Ci-dessous les commandes CLI pour lexemple prcdent : Dans la source :

Dans le responder :

2.2

MRTG sous Windows :

2.2.1 Prrequis: a. Installation dActive Perl Windows : Perl est un langage de programmation cr par Larry Wall en 1987 et reprenant certaines fonctionnalits du langage C et des langages de scripts sed, awk et shell.

37

C'est un langage interprt, polyvalent et adapt au traitement et la manipulation de fichiers texte, notamment du fait de l'intgration des expressions rgulires dans la syntaxe mme du langage. Lutilisation de la solution MRTG dans un environnement Windows implique dinstaller un interprteur Perl.

Figure 3.3 : Page de tlchargement Perl b. Installation de MRTG : On copie le dossier du package MRTG sur C:\mrtg.

Figure 3.4 : Dossier tinstallation MRTG Vrification de linstallation par la commande:

*Commande : perl mrtg en se plaant sous le rpertoire C:\mrtg\bin>

38

Voir Annexe 2 Article 2

c.

SNMP & SNMP OIDs :

Simple Network Management Protocol (abrg SNMP), en franais protocole simple de gestion de rseau , est un protocole de communication qui permet aux administrateurs rseau de grer les quipements du rseau, de superviser et de diagnostiquer des problmes rseaux et matriels distance. Le principe de SNMP :

Les systmes de gestion de rseau sont bass sur trois lments principaux : un superviseur, des nuds (ou nodes) et des agents. Dans la terminologie SNMP, le synonyme manager est plus souvent employ que superviseur. Le superviseur est la console qui permet l'administrateur rseau d'excuter des requtes de management. Les agents sont des entits qui se trouvent au niveau de chaque interface, connectant au rseau l'quipement gr (nud) et permettant de rcuprer des informations sur diffrents objets. Commutateurs, concentrateurs, routeurs, postes de travail et serveurs (physiques ou virtuels) sont des exemples d'quipements contenant des objets grables. Ces objets grables peuvent tre des informations matrielles, des paramtres de configuration, des statistiques de performance et autres objets qui sont directement lis au comportement en cours de l'quipement en question. Ces objets sont classs dans une sorte de base de donnes arborescente dfinie par l'ISO appele MIB ( Management Information Base ). SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaits dans la MIB. L'architecture de gestion du rseau propose par le protocole SNMP est donc fonde sur trois principaux lments : Les quipements grs (managed devices) sont des lments du rseau (ponts, commutateurs, concentrateurs, routeurs ou serveurs), contenant des objets de gestion (managed objects) pouvant tre des informations sur le matriel, des lments de configuration ou des informations statistiques ; Les agents, c'est--dire les applications de gestion de rseau rsidant dans un priphrique, sont chargs de transmettre les donnes locales de gestion du priphrique au format SNMP ; Les systmes de gestion de rseau (network management systems nots NMS), c'est--dire les consoles travers lesquelles les administrateurs peuvent raliser des tches d'administration. SNMP OIDs :

Les objets stocks dans la MIB sont identifis par leur identificateur nomme Object ID (OID), les objets qui concernes les mesures IP SLA sont stocks sous la base de donnes CISCO-RTTMON-MIB.

39

Les OID sont utilis dans les scripts MRTG pour obtenir les graphes associes a ces objets. Voir Annexe 2 Article 1 Configuration de SNMP Prrequis : a. Image IOS routeur supporte le SNMPv2 b. Configuration SNMP Extrait de la configuration de R-2 ! ! no ip http server ! ! snmp-server community public RO snmp-server host 50.0.0.3 version 2c public ! ! ! ! control-plane ! Voir Annexe 3 Articele 1 2.3 Autre Outils : 2.3.1 Getif : Getif est un outil gratuit multi-fonctionnel, bas sur Windows GUI Rseau, crit par Philippe Simonet. Cest un excellent outil permettant de collecter les informations des priphriques SNMP. Ces dispositifs comprennent Windows, et dautres systmes d'exploitation ainsi que les appareils fabriqus par la plupart des grandes entreprises de rseau (c.- Cisco, 3COM, Dlink, Nokia, etc, etc.)

40

Figure 3.5 : Interface Graphique de Getif 2.3.2 GNS3 :

Figure 3.6 : Logo GNS3 et exemple de maquette rseaux GNS3 est un logiciel open source qui simulent des rseaux complexes tout en tant aussi proche que possible des rseaux rels. GNS3 fournit une interface utilisateur graphique intuitive pour concevoir et configurer des rseaux virtuels, il fonctionne sur du matriel classique d'un PC et peut tre utilis sur plusieurs systmes d'exploitation, y compris Windows, Linux et MacOS X.

Conclusion
MRTG et IPSLA, sont les outils dvaluation de performance que nous avons choisi en plus de GNS3 pour la ralisation de ce projet. Le chapitre suivant sera consacr la mise en uvre de lensemble de ces outils pour llaboration des scnarios de validation et lanalyse des rsultats.

41

Chapitre 4 Design de plateforme de simulation et reporting des rsultats de tests

42

Introduction
Dans ce chapitre, nous allons prsenter la plateforme rseau utilise pour la ralisation de notre projet, ainsi que les rsultats de tests que nous avons obtenu en laborant deux scnarios de validation, Un premier scnario avec un en-tte non compress, et un deuxime avec compression. Notre objectif est montr limpact du protocole CRTP en particulier, et les protocoles de compression den-ttes en gnral, sur les performances des rseaux informatiques, notamment les rseaux de convergence.

1. Plate-forme dvaluation des performances et scnarios de validation:

30.0.0.0/2424 2

10.0.0.0/24 IP SLA Source

IP SLA Reciever 20.0.0.0/24 Plateforme MRTG 40.0.0.0/24

Figure 4.2 : Plateforme rseaux La plateforme que nous avons labore, se constitue de cinq rseaux interconnects via quatre routeurs par des liens de 64 et 32 kbps. Le routeur R2 est configur comme source IP SLA pour la gnration du trafic. Le routeur R3 reprsente le nud de rception du trafic IP SLA gnr au niveau du routeur R2.

IPv4 sans CRTP

IPv4 avec CRTP

43

Durant ce travail, nous avons ralis deux scnarios de validation, le premier scnario concerne la gnration dun flux sans compression den-tte (1), tandis que dans le deuxime scnario, on a utilis la compression den-tte avec le protocole CRTP (2), en but de comparer les performances du rseau dans les deux cas.

2. Reporting des rsultats :

2.1 Paramtres de scnario et conditions de test: Paramtres de scnario :

Round Trip Time RTT Utilisation de bande-passante BW Jitter Jitter

Figure 4.3 : Paramtres de test Condition de test et contraintes:

Frquence des mesures de la plateforme MRTG : 5 min Date de test : 02/02/2014 Priode de collecte de data : 20h 2 Fv. 15h 3 Fv. 2014 on na pas pu trouver limage IOS qui supporte IPv6 IP SLA pour tablir des scnarios avec IPv6. On na pas pu rduire la frquence de la plateforme a 1 min pour collecter plus de data.

44

2.2 RTT Max :

RTT max : 424 ms RTT Avg : 151 ms

RTT max : 185 ms RTT Avg : 128 ms

Figure 4.4 : Graphe RTT Max sans CRTP

Figure 4.5 : Graphe RTT Max avec CRTP

RTT Chart
500 400 300 200 100 0 Sans CRTP Avec CRTP 151 185 128 424 RTT Max RTT Avg

Figure 4.6 : Graphe rcapitulatif du RTT Max Daprs les graphes ci- dessus, on remarque que dans le premier scnario ou la compression est dsactive, le RTT Max a atteint une valeur maximale de 424 ms, par contre, aprs lactivation du CRTP dans le deuxime scnario, la valeur du RTT Max a diminu pour atteindre une valeur de 185 ms. Il en est de mme pour la valeur du RTT Avg qui tait de 151 ms avant lactivation du CRTP, et qui a t rduite 128 ms aprs lactivation de la compression.

45

2.3 Utilisation de la bande passante :

BW utilise : 51.3kbps BW disponible : 64 kbps % : 80.2

Interface s1/0

Figure 4.7 : Graphe Bande-passante sans CRTP

BW utilise : 45.6kbps BW disponible : 64 kbps % : 71.3 Interface s1/0

Figure 4.8 : Graphe Bande-passante avec CRTP

BW Chart
100 80 60 40 20 0 Sans CRTP Avec CRTP 80,2 51,3 71,3 45,6 BW (kpbs) % BW

Figure 4.9 : Graphe rcapitulatif de la bande-passante Lutilisation de la bande-passante est un facteur trs important dans le dimensionnement des rseaux pour la voix sur IP (VoIP). Daprs les graphes obtenus par MRTG, nous pouvons constater que le taux dutilisation de la bande passante de linterface serial 1/0 est de 80% dans le premier scnario (sans compression CRTP), alors que dans le deuxime scnario (compression CRTP active), lutilisation a diminu jusqu' 70 %, ce qui nous a permis de gagner 10% en bande passante.
2.4 La gigue :

46

Jitter Max : 12 ms Jitter Avg : 11 ms

Figure 4.10 : Graphe gigue sans CRTP

Jitter Max : 12 ms Jitter Avg : 11 ms

Figure 4.11 : Graphe gigue avec CRTP

Jitter Chart
12,5 12 11,5 11 10,5 Sans CRTP Avec CRTP 11 11 12 12 Jitter Max Jitter Avg

Figure 4.12 : Graphe rcapitulatif gigue

47

Conclusion
Sans doute limpact des protocoles de compression den-ttes sur les rseaux, notamment de la VoIP est trs important, car il permet de diminuer les dlais, chose qui est trs pnalisante pour les applications temps rel, et permet galement une utilisation efficace de la bande passante pour supporter une grande capacit de flux sur le rseau.

48

Conclusion gnrale
Il y a plusieurs raisons de faire de la compression den-tte sur des liaisons faible ou moyenne vitesse. La compression den-tte peut : Amliorer le temps de rponse interactive. Diminuer la redondance d'en-tte. En effet, une taille courante de segments TCP pour les transferts sur des liaisons moyenne vitesse est aujourd'hui de 512 octets. Lorsque les segments TCP sont tunnels, par exemple cause de l'utilisation d'IP mobile, les en-ttes IPv4/IPv6/TCP font 100 octets. La compression d'en-tte va diminuer la redondance d'en-tte pour IPv6/TCP de 19,5 pour cent moins de 1 pour cent, et pour le tunnage IPv4/TCP de 11,7 moins de 1 pour cent. C'est un gain significatif pour les vitesses de ligne jusqu' quelques Mbit/s.

Rduire le taux de perte de paquet sur les liaisons perte ; comme moins de bits sont envoys par paquet, le taux de perte de paquets sera infrieur pour un taux d'erreurs binaires donn. Il en rsulte un dbit plus lev pour TCP car la fentre d'envoi peut s'ouvrir plus entre les pertes, et moins de pertes de paquets pour UDP. Dans ce projet, nous nous sommes intresss dans un premier lieu faire un tat de lart des diffrents protocoles de compression den-ttes protocolaires, ainsi que ses diffrents algorithmes. Deuximement, on a fait une tude comparative entre les diffrents outils ncessaires pour limplmentation des protocoles de compression den-tte au niveau de la plateforme choisie. Finalement, nous avons effectu des tests dimplmentation du protocole CRTP qui ont montr que la compression d'en-tte devient particulirement cruciale pour offrir une bonne qualit de service.

49

Rfrences
[1]http://abcdrfc.free.fr/rfc-vf/pdf/rfc2507.pdf [2]http://www2.ifi.auf.org/rapports/stages-promo13/vu_dinh_dau.pdf [3]Degermark M., Requirements for Robust IP/UDP/RTP Header Compression , RFC 3096. [4]Bormann C., et AL., Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed, IETF RFC 3095, 2001. [5]Degermark M., IP Header Compression, IETF RFC 2507? February 1999. [6]http://francois.janssens.free.fr/Elexo/SevOne/Diaporama.html [7]http://www.id1itsolutions.com/?type=colonnes&id=27&nom=En%20un%20 coup%20d%27oeil [8]http://www.cisco.com/web/FR/documents/pdfs/newsletter/ciscomag/2007/06/ciscomag_9_ dossier_cisco_ios_ip_sla.pdf [9] http://www-igm.univ-mlv.fr/~dr/XPOSE2010/IPSLA/presentation.html [10]Cisco, CCNPv6 SWITCH Lab5-2 IP SLA Campus Env Student Form [11]Cisco, Cisco IOS IP SLAs Configuration Guide [12]Cisco , Configuring Cisco IOS IP SLAs Operations, chap 27 [13]Cisco, CCNP Troubleshooting, IP SLA Operation [14]Cisco, Configuring Compressed Real-Time Protocol [15]http://oss.oetiker.ch/mrtg/ [16]http://oss.oetiker.ch/mrtg/doc/index.en.html [17]Whitepaper Robust Header Compression [18]http://www.docstoc.com/docs/165626916/Rapport-2 [19]http://depozit.isae.fr/theses/2010/2010_Soro_Alexandre.pdf [20]http://www.serveurpro.net/Documents/Installation%20et%20configuration%20de%20MR [21]http://wiki.monitoring-fr.org/cacti/start [22]http://mediatools.iict.ch/document?url=Mobile_ENMP/Rapport.pdf&dpId=19 [23]http://www.whatsupgold.com/resources/datasheets/ip-address-manager-datasheet_fr.pdf

50

Glossaire
C CRTP CTCP E ESP I IP IPv6 IR ISO L LAN LSB LILO M MRTG MRRU MIB O OID R RRD RTP ROHC RTT RRA S SNMP SO SN SWW SLA Simple Network Management Protocol Second Order, tat dans le compresseur Sequence Number Sliding Window Width Service Level Agreement Round Robin Database Real Time Protocol Robust Header Compression Round Trip Time Round Robin Archive Object Identifier Multi Router Traffic Grapher Maximum Received Reconstructed Unit
Management Information Base

IP/UDP/RTP Compression IP/TCP Compression

Encapsulating Security Payload

Internet Protocol Internet Protocol version 6 Initiation and Refresh, tat dans le compresseur et format de paquet International Organization for Standardization

Local Area Network Least Significant Bit Last In Last Out

51

T TS U UDP U UM UMTS V VoIP W W_LSP Window Least Significant Bits Voice over IP User Datagram Protocol Unidirectional Mode Unacknowledged Mode Universal Mobile Telecommunication System Timestamp, estampille temporelle

52

Liste de figures
Figure 1.1 : Gantt prvisionnel Figure 1.2 : Rseau de tches prvisionnel Figure 1.3 : Gantt rl Figure 1.4 : Rseau de tches rel Figure 2.1 : Paradigme dune transmission avec compression den-ttes Figure 2.2 : Tableau des classes de champs den-ttes utilis par les protocoles VJ, CRTP, ROHC Figure 2.3 : exemple du codage LSB Figure 2.4 : exemple de codage W-LSB Figure 2.5: Algorithme Slow-Start avec temporisation Figure 2.6 : Classification des champs de len-tte IPv4 Figure 2.7 : niveau de compression dans chaque mode dopration Figure 2.8 : la machine dtat du dcompresseur Figure 2.9 : Les modes oprationnels du ROHC Figure 2.10 : Les modes de transition ROHC Figure 3.1 : Exemple de graphique MRTG Figure 3.2: exemple de graphique Cacti Figure 3.3: page de tlchargement PERL Figure 3.4: Dossier dinstallation MRTG Figure 3.5: Interface GETIF Figure 3.6: Logo GNS3 et exemple maquette rseaux Figure 4.1: Scnario de test Figure 4.2: Plateforme rseaux Figure 4.3: Paramtres de test Figure 4.4: Graphe RTT Max sans CRTP Figure 4.5: Graphe RTT Max avec CRTP Figure 4.6: Graphe rcapitulatif RTT MAX Figure 4.7: Graphe BW sans CRTP Figure 4.8: Graphe BW avec CRTP Figure 4.9: Graphe rcapitulatif BW Figure 4.10: Graphe Gigue sans CRTP Figure 4.11: Graphe Gigue avec CRTP Figure 4.12: Graphe rcapitulatif gigue

53

Annexes

Annexe 1 Article 1 Table des OID SNMP pour IP SLA

Objects rttMonLatestJitterOperTable rttMonLatestJitterOperSum2NegativesDS rttMonLatestJitterOperPacketLossSD rttMonLatestJitterOperPacketLossDS rttMonLatestJitterOperOWMinDS rttMonLatestJitterOperOWMaxDS rttMonLatestJitterOperNumOfOW rttMonLatestJitterOperMOS rttMonLatestJitterOperICPIF rttMonLatestJitterOperIAJOut rttMonLatestJitterOperIAJIn rttMonLatestJitterOperAvgJitter rttMonLatestJitterOperAvgSDJ rttMonLatestJitterOperAvgDSJ rttMonLatestJitterOperOWAvgSD rttMonLatestJitterOperRTTMax rttMonLatestRttOperTable rttMonLatestRttOperTime OID 1.3.6.1.4.1.9.9.42.1.5.2.1 1.3.6.1.4.1.9.9.42.1.5.2.1.25 1.3.6.1.4.1.9.9.42.1.5.2.1.26 1.3.6.1.4.1.9.9.42.1.5.2.1.27 1.3.6.1.4.1.9.9.42.1.5.2.1.39 1.3.6.1.4.1.9.9.42.1.5.2.1.40 1.3.6.1.4.1.9.9.42.1.5.2.1.41 1.3.6.1.4.1.9.9.42.1.5.2.1.42 1.3.6.1.4.1.9.9.42.1.5.2.1.43 1.3.6.1.4.1.9.9.42.1.5.2.1.44 1.3.6.1.4.1.9.9.42.1.5.2.1.45 1.3.6.1.4.1.9.9.42.1.5.2.1.46 1.3.6.1.4.1.9.9.42.1.5.2.1.47 1.3.6.1.4.1.9.9.42.1.5.2.1.48 1.3.6.1.4.1.9.9.42.1.5.2.1.49 1.3.6.1.4.1.9.9.42.1.5.2.1.5 1.3.6.1.4.1.9.9.42.1.2.10.1.5

54

Annexe 2 Article 2 Script MRTG, RTT Max

WorkDir: D:\mrtghtml\RTTmax RunAsDaemon: Yes Interval: 5 Options[_]: growright, bits

Target[RTTmax.SLA.1]:.1.3.6.1.4.1.9.9.42.1.5.2.1.5.1&.1.3.6.1.4.1.9. 9.42.1.5.2.1.5.1:public@50.0.0.1 Maxbytes[RTTmax.SLA.1]: 20000 Ylegend[RTTmax.SLA.1]: RTT max LegendI[RTTmax.SLA.1]: ms LegendO[RTTmax.SLA.1]: Title[RTTmax.SLA.1]: RTT max PageTop[RTTmax.SLA.1]: <H1>Graphe of RTT max</H1> <TABLE> <TR><TD>Graphe of RTT max</TD></TR> <TR><TD>by NIOGroup</TD><TD></TD></TR> <TR><TD>at Cadi Ayyad University, ENSA, Marrakesh</TD><TD></TD></TR> </TABLE> Options[RTTmax.SLA.1]: gauge

55

Annexe 3 Article 1 Configuration R-2

! hostname R2 ! ip sla monitor 1 type jitter dest-ipaddr 30.0.0.1 dest-port 16384 codec g729a codecsize 160 timeout 150 frequency 30 ip sla monitor schedule 1 life forever start-time now ! ! interface Serial1/0 bandwidth 64 ip address 10.0.0.2 255.255.255.0 encapsulation ppp ip tcp header-compression iphc-format ip rtp header-compression iphc-format serial restart-delay 0 ! interface Serial1/1 bandwidth 32 ip address 20.0.0.2 255.255.255.0 encapsulation ppp serial restart-delay 0 ! interface FastEthernet2/0 ip address 50.0.0.1 255.255.255.0 duplex auto speed auto ! ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 0 network 20.0.0.0 0.0.0.255 area 0 network 50.0.0.0 0.0.0.255 area 0 ! ! snmp-server community public RO snmp-server host 50.0.0.3 version 2c public !

56

Annexe 3 Article 2 Configuration R-1

! ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! ! ! interface Serial1/0 bandwidth 64 ip address 10.0.0.1 255.255.255.0 encapsulation ppp serial restart-delay 0 ! interface Serial1/1 bandwidth 32 ip address 30.0.0.2 255.255.255.0 encapsulation ppp serial restart-delay 0 ! ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 0 network 30.0.0.0 0.0.0.255 area 0 ! !

57

Annexe 3 Article 3 Configuration R-4

! ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R4 ! ! ! interface Serial1/0 bandwidth 32 ip address 20.0.0.1 255.255.255.0 encapsulation ppp serial restart-delay 0 ! interface Serial1/1 bandwidth 64 ip address 40.0.0.2 255.255.255.0 encapsulation ppp serial restart-delay 0 ! ! router ospf 1 router-id 4.4.4.4 log-adjacency-changes network 20.0.0.0 0.0.0.255 area 0 network 40.0.0.0 0.0.0.255 area 0 ! !

58

Annexe 3 Article 4 Configuration R-3

! ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R3 ! ! ! ip sla monitor responder ! ! interface Serial1/0 bandwidth 64 ip address 40.0.0.1 255.255.255.0 encapsulation ppp serial restart-delay 0 ! interface Serial1/1 bandwidth 32 ip address 30.0.0.2 255.255.255.0 encapsulation ppp serial restart-delay 0 ! ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 30.0.0.0 0.0.0.255 area 0 network 40.0.0.0 0.0.0.255 area 0 ! !