Institut national des sciences appliquees de lyon

8.3 Service et interactions avec la sous-couche LLC :

La sous-couche MAC fournit un service
* de transfert de données point à point ou avec diffusion partielle ou totale.
Pour ce service on utilise les primitives
MA_DATA.request (adresses source et destination, MA_SDU, qualité demandée)

MA_DATA.indication (adresses source et destination, MA_SDU, qualité)

MA_DATA.confirm (qualité, état)

la qualité précise le niveau de priorité ou de confirmation par exemple.

* d'administration du réseau

qui permet d'initialiser le protocole, de fixer ou de modifier les variables, de donner les tables d'adresse de diffusion que l'entité doit reconnaître, d'indiquer les défauts observés et de transférer aux autres stations des données d'administration. Les variables qui peuvent être manipulées sont par exemple l'adresse de la station, la durée maximale pour transmettre une trame (slot time), des paramètres de priorité, etc.

On utilise les interactions :

MA_INITIALIZE_PROTOCOL.request

MA_INITIALIZE_PROTOCOL.confirm

MA_SET_VALUE.request MA_SET_VALUE.confirm

MA_READ_VALUE.request MA_READ_VALUE.confirm

MA_VALUE_CHANGE.indication

MA_FAULT_REPORT.indication

MA_GROUP_ADRESS.request MA_GROUP_ADRESS.confirm

MA_CDATA.request MA_CDATA.indication

MA_CDATA.confirm

8.4 Eléments de protocole :

Pour assurer ce service, le protocole doit être robuste et survivre à des défauts multiples : perte de jeton, jetons multiples, défaut dans la transmission du jeton, station "sourde", adresses dupliquées par exemple.
Sur ce réseau toutes les stations sont connectées en parallèle sur le médium (bus); lorsqu'une station transmet toutes les autres stations "l'écoutent" et reçoivent un signal (pas forcément ce qui a été émis). Ainsi une trame reçue à une station peut être ou non valide et ne permet pas de présager de ce qui a été reçu par les autres stations.
Le droit d'émettre est régi par un jeton; toutes les stations ne sont pas obligatoirement intéressées par ce droit. Les stations concernées constituent un "anneau logique".
La principale difficulté consiste lors de l'initialisation ou sur une réinitialisation, à constituer cet "anneau logique", puis à le maintenir.

5. Opérations de base :

Chaque station participante doit connaître l'adresse de son prédécesseur (PS) et de son successeur (NS) sur l'anneau logique.
Lorsqu'une station reçoit de PS un jeton (droit de parole) elle dispose d'un temps fixé maximal (slot time) pour émettre une ou plusieurs trames de données. Elle cède alors le jeton à NS et surveille ce qu'en fait son successeur en "écoutant" le réseau.
Si la trame "jeton" qu'elle reçoit (et émet..) lui semble perturbée (FCS) elle positionne un indicateur et continue d'écouter. Si elle ne reçoit rien dans un délai donné elle présume que le jeton est perdu et le réémet.
Si NS ne transmet rien après ce second jeton, la station présume qu'il est défaillant et émet une trame "who_follows" avec l'adresse de NS. Toutes les stations analysent cette trame et la station dont le prédécesseur est NS envoie une trame "set_successor". La station qui émet le jeton met à jour ses tables et peut envoyer ce jeton à ce nouveau successeur.
Si aucune station ne répond à "who_follows" (après un deuxième essai) la station recherche un successeur par "sollicit_successor_2" avec sa propre adresse dans les champs DA et SA. Toutes les stations qui reçoivent cette trame vont participer à un processus de contention pour rétablir l'anneau logique. Si personne ne répond la station présume un défaut très grave, émet à toutes fins utiles ses données en attente puis se met en attente.

6. Fenêtres de réponse.

L'insertion d'une nouvelle station à l'anneau logique ou les reprises sur défaut grave sont traitées par un processus de contention durant une "fenêtre de réponse". Il s'agit d'une intervalle de temps (égal au slot_time) durant lequel les stations émettrices font une pause et attendent une réponse.

Les trames "sollicit_successor_1 et _2" débutent ces périodes de temps. Les stations qui veulent participer à l'anneau logique répondent à ces trames. Un algorithme basé sur la valeur des adresses permet à plusieurs stations de s'insérer dans l'anneau logique en minimisant les collisions. En cas de contention aucune trame valide n'est détectée et un autre mécanisme utilisant "resolve_contention" est utilisé.
L'initialisation constitue un cas particulier d'ajout de nouvelles stations. A l'expiration d'un délai d'inactivité du réseau, une station émet une trame "claim_token" qui démarre une fenêtre de réponse.
Ce mécanisme est aussi utilisé quand la station détentrice du jeton tombe en défaut.

7. Priorités

Un système de priorité peut être mis en place pour adapter la rotation du jeton sur l'anneau logique aux besoins.

D'autre part, durant la période d'émission (slot_time) la station doit émettre ses trames de données en respectant leurs priorités.

9.PROTOCOLE 8802.5

Ce protocole est implanté dans le réseau "IBM Token Ring". (Une version voisine est utilisée pour le réseau à haut débit FDDI.)

9.1 Profil :

Le profil suivant décrit un réseau en anneau utilisant des jetons priorisés.

8. Liaison physique

anneau

supports variés (câble coaxial, paire, fibre optique)

prises actives

bande de base

codage Manchester différentiel

synchrone

9. Méthode d'accès (MAC)

jeton priorisé

10. Liaison logique

avec ou sans connexion (LLC1 ou LLC2)

2.