Eléments de solution partiels

CSMA-CD

1. cf cours.
2. non. Les éléments de la méthode d'accès ne concernent que des stations désirant émettre au même moment. La résolution du problème est alors entièrement équilibré entre les stations en conflit d'émission.
3. Problème d'affaiblissement du signal. Nécessité de mettre des répéteurs (équipement d'interconnexion de niveau physique)
4. La détection physique d'une collision doit se faire alors que les stations concernées sont toujours en train d'émettre. Ceci implique une longueur minimale des trames qui est fonction du temps maximal de transit (propagation et traversée des répéteurs) entre 2 stations du réseau. Dans le cas ethernet $10Mbit/s$, le temps maximum de traversée est fixée à $25,6\mu s$. Le temps d'émission doit donc être au minimum $51,2\mu s$, soit une taille minimum des trames de $512\; bits$ ou $64\; octets$. Il y a aussi en pratique, des tailles maximums des trames pour éviter la monopolisation par une station et aussi pour des contraintes très pratiques de taille de buffer sur les équipements (carte ethernet, équipement d'interconnexion). Une taille maximum usuelle (MTU) est de $1500\; octets$.
5. La contrainte de taille minimum des trames peut être très pénalisante pour des applications de type terminal virtuel (telnet..) dans la mesure où les messages utilisateurs peuvent être de petite taille et implique de faire du bourrage très pénalisant en terme d'occupation de la bande passante. L'autre contrainte critique pour les utilisateurs (applicatifs) est le phénomène de congestion associé à la résolution des collisions. En pratique les débits effectifs sur des réseaux ethernet dépassent guère les $3$ à $4\; Mbits/s$ sous peine de saturation totale du support et refus d'émission (rejet des trames après 10 tentatives d'émission). Il est d'autre part très rarement implanté de mécanisme de contrôle de congestion ou de contrôle de flux sur ce type de réseau (LLC encore rarement utilisé). Les applications auront donc un très bon comportement et un bon service au niveau 2 si le débit global de l'ensemble des stations reste faible, mais on a aucune garantie de service en cas de montée en charge du réseau. Des applis de type temps réel ou voix sont donc possibles à condition de surdimensionner les supports et de contrôler les utilisations.

Anneau à jeton

1. cf cours.
2. Le problème important est de garantir l'existence d'un jeton unique à tout moment sur l'anneau. Un autre problème genant est aussi d'enlever les trames du support quand l'émetteur ne le fait pas. Pour cela on a besoin d'une fonction de supervision qui contrôle la cohérence de l'anneau indépendamment de l'émission de chacune des stations. Les mécanismes à mettre en oeuvre pour cette supervision peuvent difficilement être réalisés de manière répartie entre toutes les stations, d'ou l'existence d'une station de supervision. Par contre pour des contraintes de fiabilité on préfère que cette supervision puisse être assurée par n'importe quelle station (problèmes d'élection du superviseur et de maintien de la fonction de supervision).
3. Si toutes les stations ont un volume infini de données à émettre le temps entre le moment où l'on rend un jeton que l'on vient de consommer et le moment où il revient est de 49 fois l'émission de 2Koctets plus le temps de propagation sur l'anneau ($\approx 5\mu s$) plus le retard d'un temps bit par station ($\approx 50/(4\; *\; 106)\; =\; 12,5\mu s$. Le temps maximum d'attente est donc de l'ordre de $50*(2000\; *\; 8)/(4\; *\; 106)\; s\; =\; 0.2\; s$. Dans le cas d'un débit global moyen de l'ensemble des stations plus faible que le débit du support, le temps d'attente sera à peu de chose près proportionnel à ce débit. Ceci diffère d'ethernet où le temps d'attente est epsilonesque à faible charge mais devient intolérable si la charge augmente.
4. Problème de contenance de l'anneau : le nombre de bits sur l'anneau est de l'ordre de $4\; *\; 106/\; (2*\; 105)\; =\; 20\; bits$. Il faut donc qu'une station insère plus d'un bit de décalage sur l'anneau pour que l'anneau puisse contenir le message jeton de $24\; bits$.
5. La contrainte principale pour les applications au dessus de token ring est le temps d'attente pour émettre. Des applications de type temps réel peuvent ainsi être exclues suivant leurs contraintes de temps de transit. Une façon de corriger ce défaut est d'implanter des mécanismes de priorité sur la prise du jeton et ainsi d'avoir des temps d'attente à l'émission dépendant du type d'utilisateur applicatif.

Interconnexion

1. Du côté Transpac l'équipement d'interconnexion doit être conforme à la norme X25 : c'est à dire couche physique (V24/V28..), couche liaison de données HDLC-LAPB, couche réseau X25.3 (protocole X25). L'accès par PAD serait ridicule.

   Pour le côté Ethernet, la transparence aux architectures (IP,DECNET,Appletalk,...) implique de ne pas traiter les protocoles supérieurs à la couche 2. On aura donc les deux couches physique et liaison de données. La question ouverte reste de savoir si l'on met seulement la sous-couche MAC ou si on met aussi une sous-couche LLC (0,1,2,..).

   La connexion X25 sera établie et rompue ``manuellement'' à l'aide d'une station pilotant l'équipement d'interconnexion (ou utilisation de circuits virtuels permanents). Les temps d'établissement des connexions sur transpac interdit de faire de l'établissement de connexion trame par trame.

   Le type d'équipement que l'on veut définir s'appellent usuellement un demi-pont. Le réseau Transpac est utilisé comme un service de liaison de données spécifique. L'ensemble des 2 demi-ponts et la liaison intermédiaire fournissent un service de pont entre 2 réseaux locaux ; par rapport à un pont usuel on a ``simplement'' délocalisé géographiquement les 2 ports en utilisant un service de communication grande distance ou public.

   Le cheminement des données correspond aux étapes :

   Station émetteur, Ethernet1, équipement d'interconnexion 1 (récupération de la trame MAC, analyse de l'adresse MAC pour filtrage si le destinataire est sur Ethernet 1, encapsulation de la trame avec entête MAC dans un paquet X25 DATA), TRANSPAC, équipement d'interconnexion2 (récupération de la trame MAC), Ethernet 2, station réceptrice.

2. Les trames erronées sur Ethernet 1 sont détruites au niveau MAC du demi-pont (pas de reprise). Les ``trames erronées'' sur TRANSPAC sont détruites puis récupérées par retransmission X25. Les trames erronées sur Ethernet 2 sont détruites par la station réceptrice. Les trames qui ont été détruites sans mécanismes de reprise doivent être récupérées par les couche transport ou réseau au niveau des 2 stations d'extrémités
3. Dans ce cas 2 CV partent de chaque passerelle qui se comporte comme un pont multiport. Le problème est de réaliser une sorte de ``routage'' afin de ne dupliquer que le strict minimum de trame sur les 2 CVs, on ne veut dupliquer que les multicasts ou les broadcasts. Il n'y a en réalité pas une fonction de routage mais une fonction de filtrage qui va être utilisée. Le routage consisterait à déterminer où doit aller la trame alors que le filtrage va consister à déterminer où il est inutile d'envoyer la trame. En pratique on maintient dynamiquement au niveau de chaque passerelle des tables d'adresses MAC connues dans chaque réseau (c'est-à-dire derrière chaque port). On fait cela en regardant les adresses sources dans toutes les trames MAC que l'on voit sur la passerelle. Quand la passerelle reçoit une trame avec une adresse destination $A$ connue (c'est-à-dire si la passerelle a déjà reçu une trame émise par $A$) la trame n'est envoyée que vers ce réseau (ou ignorée si la trame est arrivée à la passerelle par ce réseau), sinon la trame est diffusée sur tous les ports (à l'exception du port d'entrée).

   Ce mécanisme n'est toutefois pas suffisant pour répondre à la question, dans la mesure où l'on vient de créer une fonction de ``routage'' par inondation sans contrôler les possibilités de bouclage. Pour notre configuration, il suffit de rajouter une contrainte de filtrage qui est de ne pas renvoyer sur un CV des données reçues sur un autre CV. Dans le cas général d'interconnexion de réseau locaux par des ponts on met en oeuvre des algorithmes distribués de spanning tree qui vont désactiver dynamiquement certains ports sur les ponts afin d'avoir une topologie de diffusion de l'info qui soit un arbre. Ici l'utilisation d'une structure d'arbre est pénalisante en terme de coût (duplication de traffic sur Transpac).

4. Du côté LS l'équipement n'a besoin que des couches 1 et 2 avec libertés de choix sur les protocoles. Le mécanisme de filtrage décrit précédemment fonctionne de manière identique et même plus simplement car on n'a pas de problèmes de boucle. La structure d'arbre est ici pénalisante en terme de charge (le traffic inter-filiales passe 2 fois sur LS) mais économique en nombre de liaisons. Dans le cas transpac le coût est marginal sur le nombre de liaisons mais important sur le traffic.

Àpropos de ce document...

Réseaux locaux et Interconnexion

This document was generated using the LaTeX2HTML translator Version 96.1-h (September 30, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -t Solution Petite Classe Reseaux locaux et Interconnexion -no_navigation -html_version 3.1 LAN-sol.tex.

The translation was initiated by Pascal Hennequin (LOR-AIGRI) on Tue Jan 21 15:47:28 MET 1997