03 Mars 2004.
Par ce laboratoire, nous commencerons une exécution de SDL d'une partie du Internet Protocol (IP), la version 4. Le but est de mettre en application les spécifications IPv4, RFC 791 .
IPLab.zip : fichier nécessaire pour le laboratoire
Contenu du fichier IPlab.zip:
IPLab.sdt : Un fichier de Telelogic Tau organizer.
IP.ssy : Un fichier de système SDL, contenant un bloc avec 3 instances d'un IPHost
IPHost.sbt : Un fichier de type bloc SDL, contenant un processus (vide) appelé IP.
IPpkg.sun : Un paquet SDL contenant des définitions de signal, etc...
Int16ToOctetString.spd: procédure SDL qui convertit un nombre entier de 0 en 65535 en string d'octet de longueur 2.
Vous devriez pouvoir ouvrir les fichiers dans un repertoire et double-cliquer sur IPLab.sdt fichier pour telecharger tous les fichiers.
Cliquez ici pour voir les fichiers dans un browser
Dans RFC 791, il y a une interface de niveau supérieur suggérée (voir la page 31). Nous emploierons une approximation étroite, qui laisse les options IP, mais qui les messages SDL au lieu des appelles de procedure ( procedure calls):
ipSend
( OCTET_STRING, OCTET_STRING, NOMBRE ENTIER, OCTET,
NOMBRE ENTIER, OCTET_STRING, NOMBRE ENTIER, PEU),
ipRecv
( OCTET_STRING, OCTET_STRING, OCTET_STRING, OCTET),
assignIP
( OCTET_STRING);
Le message ipSend
a les paramètres suivants, dans
l'ordre:
|
Nom |
Type |
But |
|
src
|
OCTET_STRING |
Adresse IP de l'expéditeur.
|
|
dst |
OCTET_STRING |
Adresse IP de la destination. |
|
prot |
ENTIER |
Numero du protocole des données d'utilisateur. |
|
TOS |
OCTET |
Type de service a demandé. |
|
TTL |
ENTIER |
temps-à-vivre "time to live" valeur pour le paquet IP. |
|
buffer |
OCTET_STRING |
Contient les données
d'utilisateur. (ceci remplace"bufptr"
et " len"
dans RFC 791). |
|
ID |
ENTIER |
Nombre de sequence. |
|
DF |
BIT |
Le " don't fragment" flag. |
Pour indiquer qu'un message IP est arrivé, au lieu d'attendre que l'utilisateur demander de recevoir un message, un message ipRecv est envoyé à la couche supérieure pour annoncer l'arrivée d'un message.
Le message ipRecv a les paramètres suivants, dans l'ordre:
|
Nom |
Type |
But |
|
buffer |
OCTET_STRING |
Contient les données
d'utilisateur. (ceci remplace 'bufptr'
et 'len'
dans RFC 791). |
|
src
|
OCTET_STRING |
Adresse IP de l'expéditeur.
|
|
dst |
OCTET_string |
Adresse IP de la destination. |
|
TOS |
OCTET |
Le type de service a demandé. |
Le "user" peut assigne manuellement une adresse IP à un poste en utilisant le message suivant:
assignIP
(OCTET_STRING);
L'interface supérieure de IP serait normalement employée par TCP ou UDP à la couche 4, mais l'interface est rendue disponible pour d'autres protocoles qui peuvent fonctionner directement au dessus de IP.
L'interface plus basse sera légèrement modifiée des laboratoires précédents:
frameReq
(
OCTET,
OCTET, OCTET_STRING)
frameInd
(
OCTET,
OCTET, OCTET_STRING)
Les paramètres pour les deux messages sont:
|
Nom |
Type |
But |
|
dest |
OCTET |
Adresse de la couche 2 de la
destination (meme qu'avant) |
|
type |
OCTET |
Nouveau: Indique le type de message de la couche 3 contenu dans la trame |
|
données |
OCTET_STRING |
"données d'utilisateur" ce qui est le paquet de la couche 3 |
Le champ de type de trame sera introduit quand nous enverrons deux types de trames: Paquets IP, et le Protocol de Resolution d'Adresse (ARP). Le champ de type de trame contiendra un de deux constantes prédéfinies:
IPprot (valeur: hex 00): indique que la trame de la couche 2 contient un paquet de la couche 3 IP.
ARPprot (valeur: hex 06): indique que la trame de la couche 2 contient un paquet de la couche 3 ARP .
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 un IP ADDRESS 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. En outre, alors que l'adresse IP du routeur local peut être fixée par un assignement manuel, l'adresse de la couche 2 du routeur doit également être découverte.
L'approche pour résoudre les adresses de la couche 2 et la couche 3 pour l'Ethernet est décrite dans RFC 826 , et le protocole pour l'échange d'information d'adresse est connu par Protocole de Resolution d'Adresse ARP (Address Resolution Protocol).
Implementer
le processus SDL IP.spr
. Ce processus devrait exécuter ces
fonctions:
En ce moment, dans
les spécifications IP, n'inquiéter pas sur:
En outre, la
fonction de address resolution n'est pas d'être mise en application en ce
moment.