Les Réseaux Informatiques Couche Liaison Protocole Ethernet Questions sur le cours précédent ? Boukli HACENE Sofiane

le modèle OSI de ISO Rôle selon la norme ISO Alias N° 7 6 5 4 3 2 1 Physique Connexion au réseau Liaison de données Transfert local Correction d’erreurs Réseau Routage, contrôle de flux Transport Transfert de bout en bout Session Outils synchro, gestion disque Présentation Mise en forme des informations Application Interprétation des données

Rôle de la couche Liaison Couche liaison de données Allocation du canal Données  Trame Trame  bits  trame Adressage physique Qui est concerné ? Gestion des erreurs Détection ? Correction ? Couche 2 Découpe les bits en trames et vice-versa Gestion des erreurs Cause des erreurs ? Comment détecter ? Comment corriger ? Notion d’adressage LLC MAC Couche Physique

Historique d’Ethernet 1980 : Première version « Blue Book » Digital, Intel, et Xerox 10 Mbit/s Bus en 10Base5 1982 : Seconde version 1985 : Norme IEEE 802.3 1993 : Norme IEEE 802.3u  100 Mbit/s Juste un petit historique En ce moment, ça bouge pas mal au niveau du vthd Principalement fibre optique  en général, pas ethernet mais FDDI

Objectifs du protocole Liaison de données à 10 Mbit/s Faible coût Réseau égalitaire Pas de priorité Pas de censure Erreur souhaitée < 1E-8 Voici les objectifs principaux du protocole Ethernet. Il s’agit des objectifs recherchés au moment de sa création. Ils ont évolué depuis. Tous ne sont pas atteints, n’autres points importants l’ont été entre temps. Faire rechercher aux étudiants ce que signifie « égalitaire »

Principes de fonctionnement Topologie en bus, Pas de boucle Communication en bande de base (baseband) Pas de modulation  Simplicité 1 baud = 1 bit/s Transfert par diffusion passive Circulation autonome des données Chaque station reçoit toutes les données Pas de trames simultanées Ethernet a été bâti sur la technologie de 1980 : le 10Base5. Topologie en bus simple, pas de circuit Transmission en bande de base… Quels avantages ?  Simplicité & coût ! Quels inconvénients ?  1bit/modulation = gaspillage Tellement simple que la diffusion passive fonctionne Circulation autonome Pas d’agent de circulation Pas de source de courant nécessaire Peu de délais Chaque station reçoit l’intégralité des données Avantage Pas besoin de savoir comment joindre une station Pas d’adresse nécessaire Inconvénient ? Adresse nécessaire pour savoir qui est visé Une seule trame sur le réseau à la fois ! (Click)

Adressage MAC Chaque station reçoit toutes les données Emetteur d’une trame ? Destinataire d’une trame ? Ajout d’un bordereau d’envoi Entête de trame Adresse destination Adresse source Notion de trame structurée Bien, on vient de voir que la diffusion des signaux électriques permettait d’atteindre toutes les stations du réseau. On aura donc besoin d’adresses. Chaque station aura donc une adresse dite « MAC », car tout est géré par cette couche. Ces adresses sont physiquement inscrites dans les transceivers comme on le verra tout à l’heure. On aura donc une adresse source et une adresse de destination. Pour transporter ces informations, on va joindre aux données un ‘bordereau’. Pour des raisons simples, on stockera ces informations devant les données.  Seule la machine destinataire aura à stocker les données Pour les mêmes raisons, on stockera d’abord la destination, puis la source. On voit donc apparaître une forme simple de trame structurée. Plusieurs données sont envoyées simultanément Chaque donnée a et type et une place bien précis

Trame de données @ Destination @ Source Données Adresses MAC Voici donc notre premier schéma de trame. On y retrouve les données à émettre, et on y ajoute le bordereau de routage @ source @ destination Cependant, comme nous allons le voir tout de suite, ce n’est pas suffisant pour pouvoir atteindre tous les objectifs que s’étaient fixés Digital, Intel et Xerox Pouvez-vous voir certains de ces problèmes ?

Adresses MAC Norme 802.3 6 octets  chaque adresse est UNIQUE au monde 3 octets constructeur 3 octets numéro de série  chaque adresse est UNIQUE au monde 1 Adresse de Broadcast FF-FF-FF-FF-FF-FF La Norme 802.3 fixe ce que nous appelons « adresse MAC » Il s’agit de valeurs sur 48 bits, ou 6 octets Les trois premiers sont caractéristiques du constructeur du transceiver Ces valeurs sont attribuées directement par l’IEEE Certains constructeurs ont plusieurs identifiants Les trois octets suivants sont un numéro de série du matériel. Chaque série peut donc répertorier 16 777 216 éléments. Cette adresse est UNIQUE dans le monde entier. Par construction. Il existe un jeu d’adresses particulières : les multi-cast. Le bit de poids faible de l’octet de poids fort de ces adresses est positionné à 1. Cette adresse désigne alors un ensemble de machines. Parmi ces adresses, une nous intéresse particulièrement: LE BROADCAST. Toutes les machines du réseau sont ciblées !

Reconnaissance des trames Comment reconnaître le début de trame ? Présence de signaux transitoires Synchronisation du récepteur Nécessité d’un préambule Ensemble d’octets connus Permet de synchroniser les horloges Ne transmet pas d’information  perte non gênante Le premier des problèmes à régler est bien entendu de savoir QUAND est-ce que des données sont en cours de transfert. YAKA écouter ce qui passe sur le câble MAIS, parasites  nouvelles données ? MAIS, présence de signaux transitoires Début du signal Avant signaux stables D’autre part, il y a un autre problème : Les signaux sont asynchrones ! Pas d’horloge transmise ! Les données sont émises selon l’horloge de l’émetteur La vitesse de transmission est connue  reste à synchroniser les deux horloges Mise en place d’un préambule Avant le premier octet de la trame Bien connu pour pouvoir s’en servir et non pas juste à cause des transitoires Sa forme doit permettre la synchronisation des horloges Ne doit pas véhiculer d’information (risque majeur de perte !)

Trame de données Préambule @ Destination @ Source Données On retrouve donc notre trame. Afin de permettre sa lecture, on ajoute un préambule.

Le préambule Réception du préambule en cours de route Déjà commencé Depuis quand ? Nécessité de marquer la fin du préambule Insertion d’un « Start Frame Delimitor » Caractère spécial Suit le préambule Précède les données Par nature, le préambule est destiné à absorber : les transitoires Les délais Les aléas de calibrage des horloges On commence TOUJOURS à le recevoir par le milieu. Aucun moyen de savoir où on en est. Comment savoir quand il se termine ? AJOUT d’une marque AJOUT d’un Délimiteur de Début de Trame Caractère spécial Intercalé entre les informations de la trame et le préambule

Préambule Start Frame Delimitor 7 octets 1 octet 10101010 Donnée régulière  synchronisation horloges Start Frame Delimitor Le préambule est constitué de 7 octets Comme on ne sait pas à quel moment la lecture va commencer, ils sont TOUS égaux à 10101010. Vous pouvez remarquer que c’est une valeur très régulière. Ainsi, il est possible à la machine de synchroniser son horloge sur le signal. Après le préambule vient le SFD Il s’agit d’un seul octet, qui va venir briser le rythme du préambule… Il est en tout point identique aux octets du préambule, sauf le dernier bit qui est inversé. Dès lors que les deux bits positifs successifs ont été lus, la trame va être transmise. Le préambule est fini. 1 octet 10101011 Fin du préambule, début des données

Trame de données Préambule SFD @ Destination @ Source Données A notre trame, on ajoute donc le SFD. On a donc déjà : Le préambule Le SFD L’adresse de la machine destination L’adresse de l’émetteur Les données à véhiculer MAIS ce n’est toujours pas suffisant. Que manque t’il encore ?

Reconnaissance des trames 2 Comment reconnaître la fin de trame ? Plus de données ? Selon le code utilisé, pas toujours possible Marqueur de fin SONET (Synchronous optical networking ) US SDH (Synchronous Digital Hierarchy ) EU Longueur de trame Norme 802.3 Maintenant, on sait reconnaître quand quelqu’un envoie un message. On sait reconnaître les données importantes. On peut donc extraire les données de la trame… Jusque quand ? Comment reconnaître la fin des données ? Faire chercher les étudiants Plus de données Dépend du code Pas de signal = « 0 » ? (modulation d’amplitude) Marqueur de fin En fin de trame Quel caractère ? Problème des octets de transparence Longueur de la trame Donnée supplémentaire à stocker

Trame de données Norme 802.3 Préambule SFD @ Destination @ Source Long Norme Ethernet Le modèle utilisé par ethernet est celui de « pas de signal ». La norme 802.3 utilise en plus une indication de longueur. Ces deux trames sont volontairement compatibles. On discutera les différences entre les deux formats un peu plus loin… Préambule SFD @ Destination @ Source Données Type

Gestion des erreurs Ajout de bruit au signal Réductible, mais Inévitable Possibilité de modifier les données  Ajout de redondance avant émission Code détecteur d’erreur Recalcul à la réception Différence  modification données  destruction de la trame endommagée  Silence inter – trames de 9,6 ms Impossible de mélanger deux trames Le dernier paramètre à prendre en compte est la présence de bruit sur le canal. En effet, il reste toujours un bruit résiduel. On peut au mieux réduire son intensité en mettant en place des blindages multiples, des paires croisées, des structures de câbles particulières,… Les fibres optiques sont exemptes de bruit… mais pas d’atténuation. Trop affaibli, un signal peut être indécodable (bruit électronique du capteur, …) Il existe donc une probabilité non nulle de présence de bits modifiés dans la trame. Il faut donc détecter au maximum ces situations. Comment faire ? Ajouter de la redondance ! Transmettre les mêmes infos plusieurs fois. Très volumineux !!!  Codes détecteurs d’erreurs Si différence après recalcul sur données reçues, erreur ! Destruction de la trame Pourquoi ? Reste le problème de deux trames qui se suivent Rien n’indique la fin d’une trame Cumul des deux trames en une seule ! Ajout d’un intervalle de silence obligatoire de 9,6us Combien de bits à 10Mbps ?

Trame de données Norme 802.3 Préambule SFD @ Destination @ Source Long CRC Norme Ethernet Voilà donc finalement le format définitif de nos trames. Le préambule permet de synchroniser la machine qui reçoit le message avec la machine émettrice. Le SFD marque la fin du préambule de façon à déclencher la lecture des données de la trame L’adresse de destination indique quelle machine est ciblée L’adresse de la source indique à qui doit être envoyée une éventuelle réponse Le type indique comment interpréter la trame, La longueur donne la taille DU BLOC DE DONNEES Les données sont celles reçues par la couche 2 de la machine émettrice. SANS MODIFICATION Le dernier champ contient le CRC, pour détecter les erreurs. Préambule SFD @ Destination @ Source Type Données CRC

Trame de données Norme 802.3 Préambule SFD @ Destination @ Source Long CRC 7 octets 1 6 6 2 4 Norme Ethernet Voilà donc notre trame complète. On peut voir que chaque trame contient 26 octets d’entête. A chaque envoi de données, on transmet donc 26 octets d’informations spécifiques à la couche 2. Je n’ai pas indiqué la taille des données, car elle est variable. Préambule SFD @ Destination @ Source Type Données CRC

Bilan La couche 3 envoie un paquet de données La couche MAC crée une trame avec Adresse Destination Adresse Source Type/Longueur des données Les données Calcul du CRC Ajout Préambule, SFD et CRC à la trame Envoi à la couche physique Je vous ai résumé en un petit transparent le rôle de la couche 2. Avez-vous des questions ? Et la sous-couche LLC ? Dans Ethernet, elle n’est pas utilisée Dans le protocole défini par le groupe 802, elle contient le 802.2; ce protocole remplace plus ou moins le protocole IP, mais en plus simple. On le trouve donc principalement dans les équipements autonomes.

Acquisition du canal Le problème : La solution : Chaque machine peut utiliser le canal Pas d’arbitre donnant la parole Comment ne pas tous parler simultanément ? La solution : CSMA : Carrier Sensing Multiple Access On n’interrompt pas une communication On écoute, on attend la fin, et on enchaîne « Conversation civilisée » Jusqu’à présent, nous avons regardé le problème de : l’envoi de données, La détection des données La réception des données A chaque étape, nous avons supposé qu’il existait une seule trame sur le réseau. Or, (Click) Comment faire pour garantir que chaque trame reste isolée ? Une idée ? La norme 802.3 définit un protocole d’acquisition du médium: Le CSMA Il se base sur les principes suivants : En somme, il s’agit d’une conversation civilisée.

Collision, vous avez dit collision ? DTE1 DTE2 Malgré ces précautions, il reste un écueil à franchir : le problème des collisions Prenons un exemple simple : La machine de gauche envoie un message Le message parcourt le câble à raison de 200 000 km/s Juste après, la machine de droite envoie à son tour un message C’est légal puisque personne n’a envoyé de message depuis au moins 9,6 us. Au moment où les deux signaux se rencontrent, il y a collision. Cette collision est non destructive : Les signaux continuent leur route (petit crobar au tableau) La machine de droite reçoit le signal corrompu. Le message de la machine de gauche est fini. La trame est donc suivie par une période de silence. La machine de gauche reçoit donc sans problème le message de la machine de droite. Collision ! DTE2 voit la collision DTE1 ne voit rien !

Comment Faire ? Méthode CSMA / CD CSMA with Collision Detection Chaque station vérifie son message Si collision Arrêt d’émission Attente aléatoire Ré-émission La parade proposée par le 802.3 se nomme CSMA / CD. Chaque machine écoute ce qu’elle dit pour vérifier qu’il n’y a pas de collision. Sinon, Elle : Arrête son message Attend un moment Recommence Cela peut donc produire des « runts ». Ce sont des trames très courtes, car elles ont été interrompues par une collision qui a été détectée. Ces événements sont visibles dans le panneau de contrôle de Domino. Cependant, cette approche ne résout que la moitié du problème… quand une machine voit une collision.

Collision inaperçue Dans l’exemple: DTE2 voit la collision DTE1 ne voit rien DTE2 ré-émet sa trame, puisque collision DTE1 en reçoit une deuxième copie !!!  Eviter à tout prix les collisions discrètes Eviter les trames trop courtes Limiter la longueur du réseau Si l’on revient à l’exemple, (dérouler l’exemple) La machine DTE1 est donc heureuse… Elle a envoyé son message sans problème, et a reçu des nouvelles de DTE2. DTE2, de son côté, envoie deux fois son message, mais ne récupèrera jamais le message de DTE1 ! Il faut donc éviter à tout prix cette situation. Comment le garantir ? Il suffit de garantir que toute collision soit détectée. Il suffit que les trames soient assez longues il suffit que le réseau ne soit pas trop long

La solution Ethernet La norme impose : Round-Trip-Delay < 50 ms. A 10 Mbit/s, 50 ms  65,5 octets >64 octets  Détection de collision garantie Toute trame doit contenir au moins 72 octets 26 octets de protocole 46 octets de données minimum Si moins de 46 octets à envoyer : Padding (ajout d’octets de bourrage) Ex : requête = 28 octets + 18 padding Pour s’affranchir des problèmes de collision, la norme impose donc les trois contraintes simultanément : CSMA / CD Temps d’aller-retour d’une trame inférieure à 50 us À 10Mbps 500 bits=62,5 octets. Toute collision sera détectée au bout de 64 octets maximum Par sécurité, toute trame devra contenir 72 octets. 26 octets de protocole de couche 2 46 octets de données minimum Collision détectée à coup sûr. Et si moins de 46 octets ? On bourre des octets en plus.

Temps de réponse Le problème des applications interactives : Un utilisateur transfère de gros fichiers Un autre utilisateur effectue un « telnet ». Chaque touche est envoyée au serveur Le serveur renvoie une réponse (écho à l’écran) Une trame sur le réseau à chaque instant !  Il faut attendre ! Les maths : Temps moyen = ½ (taille trame / débit réseau) Il reste encore un problème dont nous n’avons pas parlé. Il s’agit des considérations en terme de temps de réponse. Le temps de réponse correspond au temps d’attente moyen nécessaire entre l’envoi d’une requête et la réception de la réponse. C’est à peu près la façon dont les utilisateurs perçoivent le réseau. Prenons un exemple caricatural : soit un réseau quelconque, et deux utilisateurs : Le premier transfère de gros fichiers d’un serveur vers sa machine. Exemple, il récupère les 7 CD d’une distribution Linux. Le second travaille à distance sur un serveur de calcul. Il utilise un programme nommé Telnet. Ce programme permet en effet à l’utilisateur de travailler sur une machine distance. Tout se passe alors comme si son clavier et son écran étaient branchés sur la machine distante. En particulier, toute frappe clavier est envoyée au serveur Le serveur prend en compte cette touche et met à jour l’écran La modification est envoyée au client Je rappelle la règle de base : UNE SEULE TRAME sur le réseau à la fois. Conclusion : L’utilisateur interactif (telnet) doit attendre la fin de l’envoi de chaque CD entre chaque frappe de touches et l’affichage des caractères à l’écran ! 1 CD = 650Mo = 5200Mbits @10Mbps, 520 secondes, soit 8 minutes et 40 secondes !!! Les maths nous disent : En moyenne, il faut attendre la moitié de ce temps, car la trame a pu être commencée avant.  en moyenne 4 minutes 20 d’attente !

Le MTU La norme IP impose : Maximum Transfer Unit octets par paquets. Le MTU dépend du réseau Internet ≥ 576 octets Ethernet = 1500 octets Pour résoudre ces problèmes de latence, la norme IP impose un MTU. Le Maximum Transfer Unit est la quantité maximale pouvant circuler sur un réseau donné en une seule trame. Cette quantité dépend bien sûr du réseau. Normalement, pour un réseau Internet, chaque MTU >= 576 octets. Sur un réseau Ethernet, MTU = 1500 => Trames de taille 1526 au maximum. Sur une ligne SLIP (IP sur ligne série), le MTU est seulement de 296 octets. En effet, le débit étant moindre, 576 correspond à une latence trop importante. Ex : 20Kbps => 230ms ( Ethernet, 1526octets @10Mbps = 1,2 ms) Le MTU dépend donc du chemin parcouru par le message. On parle donc de MTU de chemin. Ce MTU de chemin est défini très simplement : Min(MTU(segments)) Il existe des protocoles de découverte de ces MTU. Ils ont été intégrés directement à la norme IPv6.

Trame de données finale Norme 802.3 Préambule SFD @ Destination @ Source Long Données CRC 7 octets 1 6 6 2 46  1500 4 Norme Ethernet Voici donc le schéma de toutes les trames légales pouvant circuler sur un réseau Ethernet, ou 802.3 Un décompte rapide nous donne une taille comprise entre 72 et 1526 octets. Une trame trop courte (des « runts ») est donc de taille inférieure à 72 octets. Ces trames résultent typiquement de collisions lointaines… non détectée par la machine qui capte le runt. Une trame trop longue (des « jabbers ») est une trame de longueur supérieure à 1526 octets. Ces trames sont rarissimes et proviennent souvent de parasites, ou de défauts. Les autres erreurs qui sont lues par Domino sont les suivantes : Trame non alignée : Le nombre de bits reçus n’est pas multiple de 8 Trame corrompue : Le CRC est incorrect, un ou plusieurs bits de la trame ont été altérés. Préambule SFD @ Destination @ Source Type Données CRC

Services de couche 1 utilisés Transmission en bande de base La couche physique offre des services : Envoi d’un bit Réception d’un bit Canal libre ? Collision ? Pour être capable de supporter le protocole Ethernet, un réseau doit donc fournir : Transmission en bande de base Diffusion passive Une couche 1 offrant les services suivants Envoi d’un bit (un octet ?) Réception d’un bit (ou un octet) Détection de l’état du réseau (libre ou occupé) Détection des collisions Certains canaux n’offrent pas ces caractéristiques Transmission radio/fibre optique modulation obligatoire ADSL Multiplexage fréquentiel pour augmenter débit. Full Duplex Etc…