Laboratoire de SEG 3550: Protocole IP, Deuxieme Partie

11 Mars  2004.

Objectif:

Le but de ce laboratoire est d'attacher ensemble la couche LAN et la couche IP des laboratoires precedents pour obtenir un système en couches fonctionnel. La couche 3  mettra en application une partie du  Protocole Internet (IP) version 4, tel qu' indiqué dans RFC 791, plus une partie du Protocole de Resolution d'Adresse, ARP, tel qu'indiqué dans RFC 826.

Fichiers à télécharger:

IP_LANLab.zip: fichier  nécessaire pour le laboratoire

Contenu du fichier IPlab.zip:

• IP_LAN.sdt:  Un fichier de Telelogic Tau organizer.

• IP_LANpkg.sun : Un paquet SDL contenant des définitions de signal, etc...

• IP_LAN.ssy : Un fichier de système SDL, contenant un bloc avec 4 instances d'un Layer2and3 type block, connecte a un block de type PhysicalLayer.  Les instances de Layer2and3 sont connectees a l'environment.

• Layer2and3.sbt:  Un fichier de type block SDL  contenant deux blocks.  un block de type IPHost et l'autre de type  LANHost.

• IPHost.sbt : Un fichier de type  bloc SDL, contenant un processus (vide) appelé IP qui represente le processus de la couche 3

• LANHost.sbt:  Un fichier de type  bloc SDL, contenant un processus (vide) appelé LANFramer, qui represente le processus de la couche 2.
• PhysicalLayer.sbt:  Un fichier de type  bloc SDL, contenant un processus appelé Hub qui represente le processus de la couche Physique.
• Hub.spr:  Un processus SDL  qui  "re-broadcast" les octets entrant a toutes les stations.

• Int16ToOctetString.spd:  procédure SDL qui convertit un nombre entier de 0 a 65535 en string d'octet de longueur 2.

• CompareOctetStrings.spd:  procédure SDL qui retourne ( return) "true" if deux strings d'octet sont egales et "false" si autrement.
• removeFirstOctet.spd:  procédure SDL qui eneleve le premier octet du string d'octet.

Vous devriez pouvoir ouvrir les fichiers dans un repertoire et double-cliquer sur IP_LAN.sdt fichier pour telecharger tous les fichiers.

Cliquez ici pour voir les fichiers dans un browser

Dans le fichier a télécharger contient aussi les fichiers de trois diagrammes de message sequentiel ( MAC ) et deux  commandes simulateur. Les MSC sont: 

CompleteDemo.msc: Tous les processus sont montrés, et la simulation est procedee pour un message IP qui a besoin de resolution d'adresse . 

AVERTISSEMENT: ce fichier, s'il est imprimé, produira 60 pages. Il est vraiment seulement de 30 pages, mais la dimension de chaque page est large.

ReducedDemo.msc: C'est identique au fichier précédent, sauf que des messages "à" et "de"  la couche physique (processus Hub) sont ecartés. C'est-à-dire, vous voyez seulement les messages entre les processus de la couche 2 et 3, et entre les processus de la couche 3 et l'environnement. 

Resolution.msc: Ceci a également des messages "à" et "de"  la couche physique ecartés. C'est une extention du ReducedDemo.msc qui prouve que les messages suivants n'ont pas besoin d'exiger le address resolution, une fois qu'une adresse IP a été comparée avec une adresse hardware.

Changements au laboratoire de LAN:

Vous devrez faire deux changements dans les fichiers de laboratoire LAN:

1. Les trames auront maintenant un champ supplémentaire, indiquant le type de trame. Ce champ consiste d'un octet, et il suit le champs d'adresse de destination, comme illustré ci-dessous:

1. Quand le LANFramer processus reçoit son adresse du Hub par l'intermédiaire du message registerInd(OCTET), il devrait immédiatement l'expédier à la couche supérieure en utilisant le message hwAddrInd(OCTET).

Resolution d'Adresse

L'entité de protocole de la couche 3 est installée de sorte que des adresses IP soient assignées indépendamment des adresses de LAN de la couche 2. Les adresses de la couche 2 seraient normalement prédéterminées dans une carte d'interface du hardware; dans notre cas, elles ont été assignées automatiquement sur initialisation du système par "la couche physique". Des adresses IP sont normalement assignées dans un de deux méthodes: elles sont introduites manuellement par un utilisateur (dans le cas l'adresse IP doit rester fixe), ou elles sont affectées a partir d'une "pool" des adresses disponibles sur démarrage de système (comme est fait sur le réseau de campus pour des machines de non-serveur c-a-d dynamiquement assigner ). Pour les buts du laboratoire, nous supposerons que l'utilisateur assigne manuellement une adresse  IP en utilisant le message assignIP.

Cependant, il y a une fonction de "resolution d'adresse " qui est nécessaire pour associer des adresses IP aux adresses de la couche 2. Par la suite, le logiciel de protocole de la couche 3 doit découvrir les adresses IP d'autres stations sur le LAN, aussi bien que les adresses de leur couche 2. 

Pour faire ceci, un ARP "Address Resolution Protocol" est employé. Le format du paquet ARP suivant est une partie de RFC 826.

Le champ d'Opcode indique si le message ARP est une demande (valeur: ARPrequest = hex 01) ou une réponse (valeur: ARPreply = hex 02). 

Un poste IP devrait garder une table des adresses IP connues et de leurs adresses hardware associées. Dans le paquet fourni, on a défini le type ROUTE_TABLE qui représente la correspondance entre un OCTET_STRING représentant une adresse IP, et un OCTET représentant une adresse hardware. Initialement, cette table est vide. 

Quand un poste IP a un paquet à envoyer, il devrait rechercher "look up"  l'adresse IP dans la table. Si la table retourne 0 octets, c'est-à-dire, l'adresse IP n'est pas registree dans la table. alors le poste IP devra résoudre l'adresse. Il devrait construire un paquet ARP avec Opcode ARPrequest, lui introduit  son propres adresses hardware et IP dans les deux champs suivants, laisser l'adresse hardware de cible egale a 0, et mettre l'adresse IP dont il a besoin de résoudre en champ d'adresse IP de cible. Puis, il devrait envoyer une trame demande d'être envoyé a l'adresse broadcastID, avec le trame de type ARPprot, qui contient le paquet ARP comme données. 

Chaque poste sur le LAN recevra le paquet ARP par l'intermédiaire d'un message frameInd. Chaque poste devrait mettre à jour sa propre table de cheminement avec les adresses IP de source et de hardware de source. Puis, il devrait vérifier l'adresse IP de cible pour voir si elle est sa propre adresse IP. Si elle l'est, il devrait construire un paquet ARP comme message réponse, où il introduit son propre adresses  hardware et IP dans les deux premiers champs, et copie les adresses hardware et IP de l'expéditeur original dans les champs de cible. Le message réponse ARP devrait être envoyée à l'adresse hardware de l'expéditeur original; ce message n'est pas un "broadcast" comme le message demande.

Ce que vous - devez faire:

Les processus IP.spr et LANFramer.spr sont laissés vides. Le processus LANFramer.spr devrait être connecté au  processus précédent de laboratoire LAN, et puis  être mis à jour comme décrit ci-dessus.

Le processus  SDL IP.spr  devrait exécuter les fonctions suivantes: 

1. Attendez la couche 2 pour qu'elle assigne l'adresse hardware a travers un message hwAddrInd.
2. Attendez l'utilisateur pour qu'il assigne une Adresse IP.
3. Quand la couche supérieure envoie un message ipSend ( voir IP_lab_part_1 pour le format du message), créez un string d'octet où les 20 premiers octets sont une en-tête IP, tel que décrit dans RFC 791 . Mettez ceci dans une trame de la couche 2 avec  IPprot de type trame . 
4. Résolvez l'adresse IP en le regardant "look up" dans une table. 
   1. Si l'adresse hardware est trouvée, le paquet IP peut être envoyé immédiatement par l'intermédiaire d'un message frameReq.
   2. Si l'adresse hardware n'est pas trouvée, construisez un paquet ARP et le "broadcast"  pour demander l'adresse hardware. Quand la réponse arrive, mettez à jour la table de cheminement et puis envoyez le paquet IP qui est en attente.
5. Quand un message frameInd arrive de la couche inférieure, vérifier le type du trame pour voir s'il a la valeur IPprot. 

1. Si c'est le cas, interpréter les 20 premiers octets du champs de donnees comme une en-tête IP, et former un message ipRecv à la couche supérieure ( voir IP_lab_part_1 pour le format ).  
2. Si la trame a la valeur ARPprot,  mettez à jour la table de cheminement basée sur le contenu, et envoyez une réponse ARP si c'est necessaire.

Ce que vous ne devrez pas faire:

En ce moment, dans les spécifications IP, n'inquiéter pas sur:

• fragmentation et re-assemblage (ce  qui signifier le champ offset seront tous des zéros)
• Options IP
• Type de service (juste complétez ce que l'utilisateur indique)
• calcul de Checksum (laisser  tous les champs zéros)