Voici donc les sources de nos fichiers. Les fichiers évoluerons au fur et à mesure de l'avancement du projet qui devrais être terminé pour la fin du mois de mai au plus tard

Dernière mise à jour: 15 mai 2006 à 13h18

routeur En bref, le fonctionnement est basé sur un transit de paquet IP encastré dans les datagram UDP. Pour l'instant le routeur ne gère que les port entrant. La prochaine étape sera de travailler sur le routage et les ports de sortie.

Bonne lecture de code ;-)

Voici l'énoncé du projet en question:

INGI2142 : Implémentation en C d'un routeur

1  Introduction

L'objectif du travail est de permettre aux étudiants d'approfondir leur connaissance des protocoles IP en implémentant en C un petit prototype de routeur.

Ce routeur sera modélisé sous la forme d'un logiciel serveur écrit en langage C et les paquets IP seront transportés à l'intérieur de segments UDP.

2  Première phase : le port d'entrée

L'objectif de la première phase est d'implémenter le forwarding des paquets qui arrivent sur un port d'entrée du routeur. Le lien physique entre deux routeurs sera modélisé comme étant composé d'une paire de ports UDP : un port sur le routeur en amont et un port sur le routeur en aval.

Le format des paquets qui sont encapsulés dans les segments UDP est celui des paquets IP tel que décrit dans RFC791. Cependant, deux simplifications sont introduites pour le projet :
  • Aucune option IP n'est supportée et tous les paquets contenant une option IP sont jetés silencieusement par le routeur
  • La fragmentation n'est pas supportée. On suppose que tous les liens ont la même valeur du MTU.
Lorsqu'un paquet arrive, le routeur doit vérifier son checksum, analyser son champ TTL et décider sur quelle interface forwarder le paquet sur base de sa table de routage. Cette table de routage sera fournie au routeur sous la forme d'un fichier texte composé de lignes ascii au format suivant :
A.B.C.D/M E.F.G.H:N
Où A.B.C.D et E.F.G.H sont des adresses IP, M un entier représentant le nombre de bits du masque de sous-réseau et N un numéro de port UDP. Il faut noter que la table de routage utilisée par un routeur peut contenir autant d'entrées qu'un routeur réel (plusieurs centaines de milliers). De nombreux algorithmes efficaces ont été proposés pour la consultation d'une table de routage, voir notamment :
  • R. Perlman : Interconnections: Bridges, Routers, Switches, and Internetworking Protocols, 2nd Edition, Addison Wesley, 2000
  • G. Varghese : Network Algorithmics, First Edition : An Interdisciplinary Approach to Designing Fast Networked Devices, Morgan Kaufmann, 2005
  • Ruiz-Sanchez, M A;Biersack, Ernst W;Dabbous, Walid Survey and taxonomy of IP address lookup algorithms IEEE Network Magazine, Volume 15 N° 2 , March/April 2001 , pp 8-23
Lorsqu'un routeur reçoit un paquet IP qu'il ne peut acheminer vers sa destination, il devra pouvoir générer le message ICMP conformément à RFC792. Dans le cadre de ce travail, on se limitera aux messages ICMP suivants :
  • Destination unreachable (uniquement 0 = net unreachable et 1 = host unreachable)
  • Time Exceeded (uniquement 0 = time to live exceeded in transit)
En outre, le routeur devra pouvoir recevoir un message ICMP Echo request (utilisé par ping) et retourner le message ICMP Echo reply correspondant.

Lorsqu'un routeur renverra un paquet IP sur un port de sortie, il devra bien entendu mettre à jour le TTL et recalculer le checksum IP. Des informations complémentaires sur ce calcul sont disponibles dans RFC1071 et les documents qui l'ont mis à jour.

L'implémentation du routeur sera prévue pour supporter ultérieurement un agent SNMP. Pour cela, le routeur maintiendra une variable correspondant à chaque compteur défini dans les groupes IP et ICMP de la MIB-2 définie dans RFC2011. Les tables définies dans ce document ne seront pas implémentées.

Les RFC sont les documents qui décrivent les protocoles utilisés sur Internet. Ils sont disponibles depuis de nombreuses sources, dont http://ftp.belnet.be/packages/rfc/.