Caractérisation du trafic sur le Réseau National Universitaire Tunisien (RNU)

SETIT 27 4 th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 25-29, 27 TUNISIA Caractérisation du trafic sur le Réseau National Universitaire Tunisien (RNU) Hela BOUCETTA *, Khadija RAMAH ** and Farouk KAMOUN * * CRISTAL ENSI, Campus universitaire de Manouba,21 Manouba hela.boucetta@cristal rnu.tn frk.kamoun@planet.tn ** CRISTAL ENSI, Campus universitaire de Manouba, 21 Manouba Khadija.ramah@planet.tn Abstract: L'évolution de l'internet est étroitement liée à une meilleure compréhension du trafic et du comportement de ce réseau. Par conséquent, le développement de la métrologie et des techniques de monitoring est crucial. Cet article présente une infrastructure de mesures passives mise en place pour capturer le trafic Internet sur le Réseau National Universitaire Tunisien (RNU) et met en évidence les caractéristiques de ce trafic. En effet, il s'intéresse à l'étude de la distribution de la taille des paquets, la composition du trafic par protocole et par application. De plus, Une attention particulière est portée au trafic TCP: nous étudions la taille et la durée des connexions TCP. Quatre classes de flux TCP sont distinguées: les éléphants, les souris, les libellules et les tortues. Les caractéristiques des lois d'inter-arrivée des paquets et des flux de chaque classe sont étudiées afin de juger le niveau de la dépendance à long terme dans le trafic du réseau RNU. Key words: mesures passives, RNU, caractérisation de trafic, classification, dépendance à long terme. INTRODUCTION L augmentation de la complexité de l'internet ainsi que l'apparition de nouvelles applications aux besoins divers et évolutifs introduisent sur le trafic Internet de nombreuses caractéristiques. La métrologie fournit une caractérisation des flux d informations circulant sur les réseaux. De ce fait, elle est considérée comme une activité fondamentale pour l étude des réseaux. Elle propose une connaissance exacte de l utilisation et de l évolution de ces réseaux. C est pour cette raison que plusieurs opérateurs et fournisseurs d accès Internet ont développé des infrastructures et des systèmes de mesures pour le réseau Internet. Citons à titre d exemple le projet IPMON [CHU 1] qui constitue une infrastructure de mesures passives pour le réseau IP de Sprint. Afin de disposer d un moyen d étude du Réseau National Universitaire (RNU) et de caractériser le trafic véhiculé par ce réseau, nous avons mis en place une infrastructure de mesures passives. Cette infrastructure constituera une base pour son dimensionnement et la planification de son développement. Dans cet article, nous décrivons dans un premier temps le système de mesure déployé pour enregistrer le trafic véhiculé par le réseau RNU. Nous nous intéressons ensuite à la caractérisation globale de ce trafic : à savoir, la répartition du trafic par application et par sens, l étude de la taille des paquets et l étude de la taille et de la durée des flux TCP. Par la suite, nous présentons une classification des flux TCP, selon leurs tailles et leurs durées, en quatre types : les éléphants, les souris, les libellules et les tortues. Nous déterminons les distributions des arrivées des flux et des paquets de chaque classe et nous étudions la présence de dépendance à long terme (LRD) dans les processus d'arrivée des paquets et des flux pour chaque classe. Enfin, une conclusion générale présente les principaux résultats et les prolongements possibles de ce travail. 1. Plateforme de mesures sur RNU Dans cette section nous présentons l architecture du réseau RNU et nous décrivons l emplacement de la sonde de mesures ainsi que les traces enregistrées. 1.1. Architecture du réseau RNU Le Réseau National Universitaire (RNU) est le réseau qui connecte les institutions universitaires entre elles et à Internet. Il fournit plusieurs services dont l'accès à des serveurs de calcul et l'accès aux services Internet. Le réseau RNU comporte deux points de - 1 -

présence: l'un au niveau de CCK/EL Manar et l'autre au niveau de la centrale de télécommunication EL Kasbah reliés entre eux par une liaison de 1Mb/s (figure 1). Comme, la plupart des institutions universitaires, sont connectés au réseau RNU via le backbone national, le noeud CCK/El Kasbah est relié au backbone par une liaison Ethernet 1Mbits/s alors que celui d'el Manar possède plusieurs connexions à 2Mbits/s avec le backbone. L'accès Internet est assuré par une liaison Ethernet 1Mbits/s au niveau du POP CCK/El Kasbah et plusieurs liaisons à 2Mbits/s au niveau du POP CCK/El Manar. Tout le trafic des institutions universitaires vers Internet traverse le POP El Kasbah. Les liaisons au niveau du POP El Manar ne sont utilisées qu'en cas de problème au niveau de celles du POP El Kasbah. Figure 1. Architecture du réseau RNU La principale contrainte que pose l'installation de sondes de mesure au niveau du réseau RNU est qu'il s'agit d'un réseau opérationnel devant continuer à fonctionner sans dégradation de service malgré la présence de la sonde. Il est nécessaire que la sonde de mesure à installer soit transparente pour le réseau et son trafic. C'est pour cette raison, que nous avons opté pour les techniques de mesures passives. 1.2. Technique de capture des paquets Pour la capture des paquets traversant un point de mesure, deux techniques existent: - Installer une sonde logicielle au niveau des équipements actifs. Nous pouvons utiliser par exemple le logiciel Netflow de Cisco qui collecte le trafic au niveau des routeurs [NET]. Cet outil effectue des mesures niveau flux donc agrégées et ne permet pas des mesures niveau paquet. - Installer une sonde qui capte le trafic au niveau des liens physiques. Nous avons besoin d'un "splitter" sur le lien physique de façon à dévier vers la sonde une partie du signal transportant les données. Cette méthode est relativement coûteuse et ne peut être utilisée que par un opérateur qui construit lui-même ses liaisons. La plupart des compagnes de mesures utilisent cette technique. Ils utilisent des sondes possédant une carte réseau DAG qui enregistre la totalité des paquets reçus ou seulement leurs entêtes tout en ajoutant les estampilles associées à leur date de passage. Une technique alternative existe. Elle consiste à capter le trafic au niveau des commutateurs Ethernet. Il s'agit de la technique de SPAN (Switched Port Analyser). On connecte la sonde de mesure sur un port miroir c'est à dire configuré de sorte qu'il reçoit une copie du signal traversant un port qu'on veut superviser. Les ports du commutateur sont configurés de sorte que la machine sniffer récupère le trafic au niveau de l interface Ehternet du routeur connectant CCK/El Manar à CCK/El Kasbah. Pour chaque paquet traversant la sonde de mesures nous enregistrons 68 octets correspondant au time stamp et aux entêtes des couches liaison, réseau et transport. A cause de l'espace de stockage limité et des difficultés de traitement de très gros fichiers, nous avons choisi de fragmenter les durées des fichiers traces pour avoir la possibilité de couvrir des durées plus longues. Nous avons donc enregistré des traces de durée une heure couvrant une semaine (du 1 au 18 août 24). 2. Caractérisation du trafic sur RNU Dans cette section, nous présentons les résultats de mesures effectuées sur le réseau RNU. Les résultats présentés permettent de montrer un état général de la nature du trafic Internet véhiculé par ce réseau. Les traces contiennent le trafic échangé entre les deux noeuds CCK/El Kasbah et CCK/El Manar. Ce trafic est composé du trafic Internet des institutions de la région Tunis El Manar et du trafic destiné aux serveurs hébergés par le CCK (serveur mail du réseau RNU et sites web). 1.3. Caractérisation niveau paquet Dans un premier temps, nous présentons une caractérisation générale du trafic véhiculé par le réseau RNU. Cette caractérisation englobe la décomposition du trafic par sens (interne, entrant et sortant du réseau RNU), l'étude des tailles des paquets et la répartition du trafic par protocole et par application. 31..1. Décomposition du trafic par sens Nous avons isolé le trafic entrant au réseau RNU de celui sortant ou interne. Pour ce faire, nous avons appliqué un filtre, en se basant sur les adresses IP du RNU, pour générer trois traces à partir des traces initiales. La figure 2 illustre l'évolution du trafic au cours du temps en octets par seconde pour les trois - 2 -

O ctets/s 6 5 4 3 2 1 sens. Le trafic entrant représente 6% du trafic total en nombre d'octets contre 8% seulement pour le trafic sortant alors que le trafic interne représente les 32% restants. Le trafic interne représente le trafic de consultation des serveurs mails, authentification, DNS et proxy présents au niveau du noeud CCK/EL Manar. % : 1: 2: Decomposition du trafic par sens (1-8-4) 3: 4: 5: 6: 7: 8: 9: 1: 11: 12: Temps Figure 2. Décomposition du trafic par sens 12 1 8 6 4 2 Distribution cumulée de la taille des paquets: 1/8/24 Entrant Sortant Interne Total 13: 14: 15: 16: 17: 18: 19: 2: 21: 22: 23: 31..2. Etude de la taille des paquets La figure 3 présente trois distributions cumulées des tailles des paquets IP relatifs aux trafics entrants, sortants et internes. La distribution du trafic Internet entrant décrit le même comportement tri-modal observé dans d'autres résultats notamment ceux de [MCC ] et [CHU 1]. 46 152 258 364 47 576 682 788 894 1 116 1212 1318 1468 Taille des paquets (octets) Figure 3.Distribution cumulée de la taille des paquets IP pendant une journée A partir de ces courbes nous remarquons que le trafic entrant renferme plus de paquets de grande taille que celui interne ou sortant: 56% du trafic entrant est Interne Entrant Sortant de l'ordre de 142 octets alors que 65% du trafic sortant a la taille minimale. Cela indique qu'une portion significative du trafic entrant est due aux réponses des serveurs externes aux demandes des clients internes du réseau RNU. Le trafic généré en sortie représente les acquittements et les demandes de connexions de ces machines. Comparés aux résultats d'autres réseaux comme Sprint, sur lequel: 7% des paquets sont de 4 octets, 1% entre 4 et 576 octets et seulement 15% des paquets ont une taille dépassant 576 octets [SPR 4], nous retrouvons presque les mêmes pourcentages malgré que les réseaux sont différents en terme d'architecture et de débits. En effet ces résultats sur le réseau Sprint concernent une trace de durée 3 heures de 17h à 2h du 6 février 24. Cette trace est enregistrée sur un lien de capacité 2.5Gbits/s du POP de San José en Californie. Pour l interprétation des différents modes observés dans les différentes distributions, nous signalons que le mode 4 octets correspond à des paquets d'acquittement TCP et des paquets d'ouverture et de fermeture de connexions SYN et FIN. Le mode 576 octets correspond aux paquets générés par des machines utilisant des implémentations TCP/IP ne supportant pas la découverte de la valeur maximale de transmission (MTU et Path MTU discovery) et fixant le MTU à 576 octets. La valeur 15 octets correspond à la taille maximale des paquets supportée par un réseau Ethernet. Certaines implémentations TCP/IP fixent la taille maximale d'un segment MSS à 146 octets pour avoir des paquets de taille 15 octets. D autres implémentations TCP/IP fixent cette taille maximale à 138 octets afin de tenir compte des valeurs maximales des entêtes IP et TCP. Dans ce cas : si les entêtes IP et TCP ont la taille minimale (2 octets), nous retrouvons une taille des paquets égale à 142 octets. Par contre, si les entêtes IP et TCP ont la taille maximale (6 octets), nous retrouvons une taille de paquets égale à 15 octets. Le fait de retrouver dans la distribution des tailles des paquets entrants que 56% ont une taille de 142 octets, montre qu au moins un équipement traversé par ces paquets utilise comme valeur de MSS 138 octets. 31..3. Répartition du trafic par protocole et par sens Nous remarquons que le trafic TCP est largement majoritaire. Le tableau 1 résume les pourcentages des différents protocoles par sens de trafic. Nous notons une similitude entre le trafic sortant, entrant et interne. Trace TCP % UDP % ICMP % IPv6 Entrant 91,36 6,87 1,76 Sortant 86,75 12,5,62,11 Interne 9,87 7,74 1,8,167 Tableau 1. Pourcentage des paquets par protocole par sens de trafic - 3 -

31..4. Répartition du trafic par application Pour déterminer la répartition du trafic par application, nous utilisons une identification basée sur les numéros de ports UDP et TCP. La figure 4 décrit l'évolution de la répartition du trafic par application au cours d'une journée. L'application dominante est le web. Derrière elle, l'application la plus utilisée est HTTP alternate sur le port 88. Nous remarquons aussi l'existence d'un pourcentage non négligeable du trafic non classifié (others : 13%). Afin de déterminer la nature des applications générant ce trafic il est nécessaire d'effectuer une identification basée sur les protocoles applicatifs. Les autres applications liées au transfert de fichiers (FTP), à la messagerie (SMTP pour l'envoi de messages et POP3 pour la consultation des boîtes aux lettres) et HTTP sécurisé restent négligeables. Contrairement aux mutations du trafic Internet dans les réseaux marqués par l'émergence des applications pair à pair et vidéo, nous n'avons pas remarqué la dominance de ces applications sur le trafic du réseau RNU. Mais nous ne pouvons pas affirmer l'absence du trafic pair à pair du fait que ces applications négocient les numéros de ports à utiliser pendant les communications. De ce fait, ce trafic ne peut être identifié correctement par une méthode basée sur les numéros de ports. Composition du trafic par application en nombre de paquets /s (1-8-4) TCP définie par les 5-uplets et délimitée par {SYN, FIN ou RESET}. Dans ce qui suit nous exposons la répartition des connexions TCP par type: complètes, incomplètes et reset au cours du temps, La distribution de la taille des connexions TCP en nombre de paquets et la distribution de leur durée. 41..1. Etude des connexions TCP par type Nous distinguons trois types de connexions TCP selon les paquets de contrôles SYN, FIN et RESET échangés. Une connexion est complète si l'ouverture et la fermeture de la connexion s'effectuent selon le fonctionnement normal de TCP. Une connexion est incomplète si l'un des paquets SYN ou FIN sont manquants. Les connexions "reset" comportent un paquet reset envoyé par l'un des hôtes. Nous remarquons que le pourcentage des connexions reset et celui des connexions incomplètes est important. En effet, seulement 31,18% des connexions sont complètes. Les connexions reset représentent 53%. Celles incomplètes représentent 15,8%. Ces dernières (connexions incomplètes et reset) appartiennent au trafic non utile (non productive traffic ou unwanted traffic). Le pourcentage important du nombre de ces connexions n'est pas propre au réseau RNU. En effet, sur le réseau de Lawrence Berkeley National Laboratory (LBL) le volume du trafic inutile représente les mêmes pourcentages par rapport au trafic total [PAN 4]. 7 HTTP Types des connexions TCP 6 5 FTP SMTP HTTPS POP3 OTHERS 6 5 connexions tcp connexions incomplete connexions reset connexions complètes nombre de p a q uets/s 4 3 TOTAL HTTP-alternate (88) 4 3 2 1 : 1: 2: 3: 4: 5: 6: 7: 8: 9: 1: 11: 12: Temps Figure 4. Composition du trafic par application 1.4. Caractérisation niveau flux 13: 14: 15: 16: 17: 18: 19: 2: 21: 22: 23: La définition générale d'un flux est l'ensemble des paquets partageant des caractéristiques communes. Une définition, couramment utilisée, consiste à considérer un flux comme un 5-uplets formé par tous les paquets ayant les mêmes adresse IP source, adresse IP destination, numéro de port source, numéro de port destination et numéro de protocole de transport. Etant donné que le trafic TCP est majoritaire dans le trafic RNU, nous considérons un flux comme une connexion 2 1 1-8 11-8 12-8 13-8 14-8 15-8 16-8 Figure 5. Evolution du nombre des connexions TCP au cours du temps pendant une semaine (du 1/8/4 au 17/8/4) Afin d'évaluer la part des connexions incomplètes et reset engendrées par les attaques de type scan nous distinguons pour chacun huit types selon le nombre de paquets SYN et FIN échangés. Le premier sous type de connexions incomplètes est constitué par des connexions ne contenant aucun paquet SYN ni FIN (SYN FIN). Ils peuvent être engendrées par des Jour - 4 -

connexions TCP commençant avant et se terminant après la période de capture. Le deuxième sous type SYN FIN2 correspond à des connexions TCP dans les quelles la fermeture de la connexion s'effectue normalement mais les paquets d'ouverture sont absents. Elles peuvent être engendrées par des connexions commençant avant le début de la période de capture. Le troisième sous type SYN1 FIN correspond à des connexions demi-ouvertes causées par des attaques scan sur des ports TCP filtrés. Le quatrième sous type SYN2 FIN correspond à des connexions TCP dont l'ouverture est complète mais aucun paquet n'est échangé pour la fermeture. Il s'agit de connexions commençant pendant la période de capture mais se terminant après la fin de cette période ou d'attaques scan sur des ports TCP ouverts. Le tableau 2 résume les pourcentages de chacun de ces types. Nous remarquons que la majorité des connexions incomplètes (69,23%) sont de type SYN1 FIN donc engendrées par des attaques scan, alors que les connexions incomplètes de type SYN FIN et SYN FIN2 pouvant être causées par la méthode de capture ne représentent que 3.1% du total des connexions incomplètes. % SYN % SYN % SYN % SYN1 FIN FIN1 FIN2 FIN 1,95,9 1,41 69,23 % SYN1 % SYN1 % SYN2 % SYN2 FIN1 FIN2 FIN FIN1 13,81 1,2 7,29 4,38 Tableau 2. Répartition des connexions TCP incomplètes par type Pour les connexions reset : nous notons que les connexions demi-ouvertes SYN1 FIN représentent 43%. Il s'agit d'attaques de type scan. Cependant les connexions reset correctement ouvertes (SYN2 FIN et SYN2 FIN1) représentent 53%. Il s'agit de connexions annulées par l'un des hôtes à cause d'un temps d'attente élevé dû à la congestion du réseau ou du serveur lui même. 41..2. Evolution du nombre des connexions TCP reset et incomplètes au cours du temps La figure 6 décrit la composition des connexions TCP reset selon le nombre de paquets SYN et FIN. Les connexions reset de type SYN1 FIN causées par les attaques scan varient entre 7% et 85% à faible charge et diminuent pour varier entre 23% et 32% à forte charge. Par contre les connexions reset ouvertes (SYN2 FIN et SYN2 FIN1) dues à l annulation des requêtes TCP par l un des hôtes augmentent pendant les heures de travail et diminuent ailleurs. En effet, ces connexions reset ouvertes varient entre 1% et 15% à faible charge et constituent 4% à forte charge. 25 2 15 1 5 Composition des connexions RESET h 1h 2h 3h 4h 5h 6h 7h 8h 9h 1h 11h 12h 13h 14h 15h 16h 17h 18h 19h 2h 21h 22h 23h Figure 6. Evolution du nombre des connexions reset différentiées selon le nombre des paquets SYN et FIN au cours du temps 41..3. Distributions des tailles et des durées des connexions TCP Les figures 7 et 8 tracent respectivement les distributions cumulées des durées et des tailles des connexions TCP. Il apparaît que 4% des flux ont une durée ne dépassant pas deux secondes. 57% des connexions TCP ont une durée comprise entre 2 secondes et 15 minutes. Seulement 3% des connexions dépassent 15 minutes. Si nous nous interessons à la taille des connexions TCP, nous notons que 5% des flux TCP sont des flux de moins de 1 paquets. Les longs flux de plus de 1 paquets représentent 3% des flux TCP dans le réseau RNU. De nombreuses études ont montré que les mécanismes de TCP engendrent des modèles de trafic complexes et auto-similaires. De ce fait, nous nous sommes intéressé à l étude du degré de la LRD dans les flux TCP. Nous avons considéré quatre classes de trafic : les éléphants, les souris, les tortues et les libellules. Ces classes se distinguent selon la taille ou la durée des flux. Un flux éléphant comporte au moins 1 paquets et un flux souris comporte au plus 1 paquets. Nous considérons également qu'un flux tortue dure au moins 9 secondes tandis qu'un flux libellule dure au plus 2 secondes. Ces valeurs sont issues de l'article [BRO 2] qui définit la méthodologie pour distinguer les différentes classes de flux au sein du trafic Internet. SYN2 FIN1 SYN1 FIN1 SYN1 FIN SYN FIN1 SYN FIN2 SYN FIN SYN1 FIN2 SYN2 FIN total RESET - 5 -

Figure 7.Distribution cumulée des durées des connexions TCP Pour le processus d arrivé des paquets du trafic global la valeur du paramètre de hurst est : H=,639. D où les arrivées des paquets, composant le trafic RNU sont dépendantes entre elles. La valeur de H pour le trafic composé de flux éléphants est,621 ( cf figure 1). Cette valeur est proche du paramètre déterminé pour les paquets des flux TCP (H=,623 cf figure 9). Le même facteur pour les paquets souris est moins important H=,545. Nous pouvons constater que les paquets des flux éléphants sont responsables d'une grande partie de la LRD dans le trafic global. Une similitude entre les caractéristiques de la LRD des flux et des paquets des classes éléphants et tortues a été observée (Idem pour les classes libellules et souris). Ces résultats constituent, dans cette perspective, une esquisse des caractéristiques du trafic pour l'étude du phénomène d'oscillations dans le trafic Internet. Ceux-ci auront d'autant plus d'importance qu'on prévoit une augmentation des capacités du réseau universitaire et qu'on constate dans plusieurs projets métrologiques une corrélation entre la LRD et l'accroissement des capacités des liens [OWE 4]. H=,623 Figure 8.Distribution cumulée des tailles des connexions TCP 3. Etude de la dépendance à long terme dans le trafic du réseau RNU Les caractéristiques statistiques que nous étudions dans cette section concernent les différentes lois d'arrivée des flux et des paquets composant le trafic RNU. L'objectif est de vérifier l'existence et mesurer le degré de la dépendance à long terme (LRD) dans les processus des arrivées des paquets et des flux. Cette évaluation de LRD dans le trafic RNU, se justifie car de nombreuses études ont mis en évidence la présence de la LRD dans le trafic Internet [ERR 95] [PAR ]. Pour évaluer le degré de la dépendance à long terme dans le trafic RNU, nous avons utilisé l'outil SELFIS [SEL] et l'outil LDESTIMATE [VEI 99]. Le principe de ces estimateurs repose sur une décomposition en ondelettes des séries temporelles du trafic. Ils permettent de calculer le facteur de Hurst H. Un processus est dit dépendant à long terme si H est compris entre,5 et 1. Le degré de LRD est d autant plus grand que H est proche de 1. Figure 9. Evaluation de la LRD pour les paquets des flux TCP H=,6216 Figure 1. Evaluation de la LRD pour les paquets des flux éléphants - 6 -

4. Conclusion et travaux futurs Dans ce papier, nous avons décrit le système de mesures passives, permettant de capturer des traces niveau paquet, mis en place sur le réseau national universitaire tunisien (RNU). Nous avons présenté une synthèse des résultats d analyses des traces collectées. Nous avons remarqué une asymètrie dans le trafic sortant par rapport à celui entrant. En effet, les paquets entrants dans le réseau RNU sont généralement des paquets de données de grandes tailles tandis que ceux composant le trafic sortant sont de petits paquets de contrôle. Nous avons pu déduire, à partir des distributions des tailles des paquets, que la plupart des implémentations TCP/IP supportent le mécanisme de Path MTU discovery et que le fait d utliser une taille maximale de segment TCP égale à 138 n est pas judicieux car très peu de paquets sont une entete IP ou TCP supérieure à 2 octets. Une comparaison des résultats de l étude de la dépendance à long terme dans le trafic du réseau RNU à celles mentionnés dans le projet Metropolis [OWE 4], permet de détecter une différence entre les valeurs du paramètre de Hurst et donc du niveau de dépendance à long terme. En effet, dans le cadre de ce projet la valeur de H estimée pour l'inter-arrivée des paquets des flux TCP est,844. Les paquets éléphants présentent une valeur égale à,84, qui est beacoup plus importante que celle pour les paquets souris (,622). Nous constatons à partir de ces valeurs une différence dans l'échelle de la LRD entre le réseau RNU et le réseau Métropolis. Le niveau de la LRD dans le trafic véhiculé par RNU n'est pas très important comparé à celui présent dans le trafic enregistré dans le cadre du projet Métropolis. Cependant, les constations concernant la contribution des paquets éléphants par rapport aux paquets souris dans la LRD du trafic global restent les mêmes. Cette différence dans l'échelle de la LRD peut être due à la différence des capacités des liens de l'internet dans Métropolis par rapport à ceux du réseau RNU. Etant donné que le phénomène de dépendance de TCP se propage dans le trafic par l'intermédiaire des flux (connexions TCP) [VER ], l'augmentation de la taille des flux induit une augmentation de la portée de la dépendance pouvant atteindre des échelles importantes [OWE 4]. Au final, ces résultats s'introduisent dans le cadre de l'amélioration des performances du réseau RNU et fournissent des données cruciales pour la compréhension de la dynamique du trafic. C est par la compréhension précise de la dynamique du trafic qu il serait possible de modéliser et controler le trafic Internet. D autres traces peuvent être enregistrées via la mise en place d'un système de mesure multipoint utilisant une synchronisation GPS (Global Positioning System) et des cartes DAG. Ceci permettrait d'affiner les résultats déjà obtenus et de suivre périodiquement l'évolution du réseau RNU. Il serait aussi opportun d'exploiter ces traces pour identifier des attaques éventuellement présentes et leur impact sur le trafic dans le cadre de la métrologie des attaques en rapport avec les techniques de détection d'intrusions. 5. Bibliographie [BRO 2] Brownlee N., «Understanding Internet Traffic Streams: Dragonflies and Tortoises», IEEE Communications, Vol 4, no 1, Octobre 22. [CHU 1] Chuck F., Christophe D., Bryan L., Sue M., Philippe O., «Design and Deployment of a Passive Monitoring Infrastructure», Proceeding of Passive and Active Measurement: PAM-21, Avril 21. [CHU 2] Chuck F., Sue M., Bryan L., Chase C., Mujahid K., Deb M., Rob R., Ted S., Christophe D., «Packet- Level Traffic Measurements from a Tier-1 IP Backbone», Sprint Technical Report, 22. [ERR 95] Erramilli A., Pruthi P. et Willinger W., «Selfsimilarity in high-speed network traffic measurements: fact or artifact?», Proceeding of the 12th Nordic Teletraffic Seminar, NTS12, Espoo, Finland, 22-24 Aout 1995. [LEL 93] Leland W.E, Taqqu M.S, Willinger W et Wilson D.V, «On the Self-Similar Nature of Ethernet Traffic», ACM SIGCOMM, 1993. [MCC ] McCreary S., Claffy K.C., «Trends in wide area internet traffic patterns», ITC Specialist Seminar, Monterey, California, Mai 2. [NET] NetFlow, «Site web : http://www.cisco.com/univercd/cc/td/doc/- cisintwk/intsolns/ netflsol/». [OWE 4] Owezarski P. et Larrieu N., «Internet traffic characterization--an analysis of traffic oscillations», IEEE International Conference on High Speed Networks and Multimedia Communications (HSNMC'24), Toulouse, France, 3 Juin -- 2 Juillet, 24. [PAN 4] Pang R., Yegneswaran V., Barford V., Paxon V. et Peterson L., «Characteristics of Internet background radiation», Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, Taormina, Sicily, Italy, October 25-27, 24. [PAR ] Park K. et Willinger W., «Self-similar network traffic: an overview», In Self-similar network traffic and performance evaluation, J.Wiley & Sons, 2. [SEL] SELFIS, «Site web : http://www.cs.ucr.edu/~tkarag/selfis/ Selfis.html». [SPR] IPMON, «Site web : http://ipmon.sprint.com/ipmon.php». [VEI 99] Veitch D., Abry P., «A wavelet based joint estimator for the parameters of LRD, Special issue on Multiscale Statistical Signal Analysis and its applications», IEEE Trans. Info. Th. April 1999, Volume 45, No.3, 1999. [VER ] Veres A., Kenesi Z., Molnar S. et Vattay G., «On the propagation of long-range dependence in the Internet», SIGCOMM'2, Stockholm, Sweden, Septembre 2. - 7 -