La couche de Liaison.
La couche de liaison est l'une des couches les plus importantes des Réseaux, puisque c'est elle qui définit les trames à transmettre et qu'elle gère l'accès à la ligne de communication. Ces 2 éléments étant extrêmement différents et extrêmement importants, on a scindé, en 2 la couche de liaison, pour former la sous-couche d'accès au médium (MAC qui en anglais veut dire MEDIUM ACCES CONTROL), et la sous-couche de contrôle logique de la liaison (LLC qui en anglais veut dire LOGICAL LINK CONTROL).
Décomposition en sous couche de la couche 2 . La sous couche LLC.
La sous couche LLC est une entité de la couche de liaison, dédiée au service. Elle permet un ensemble de fonctions de services entre la sous couche MAC et les couches supérieures. Dans la suite, nous "étudierons" la couche LLC du Réseau ETHERNET.
Les SAP (ou LLC SAP ou LSAP).
On définit dans cette entité des fonctions permettant de créer des accès vis à vis des couches supérieures, en particulier de la couche Réseau, ou dans les Réseaux locaux, de la couche d'application. Ces points d'entrée sont nommés SAP pour SERVICE ACCES POINT ou point d'accès pour le service.
Chaque SAP est repéré par une adresse codée sur 8 bits. Les 7 bits de poids faible repèrent l'adresse individuelle, tandis que le 8ème bit définit le groupe dont fait partie le SAP pour des accès groupés.
Exemple de sous-couche LLC.
Mais les SAP ne sont que des points d'accès, le corps du service LLC est défini par 2 types de fonctions normalisées. Le type 1 ou service minimal, et le type 2 où la sous-couche LLC prend en charge une grande partie des fonctions indispensables au maintien des connexions. Type de fonctionnement de la sous-couche LLC.
Fonctionnement type 1.
Le fonctionnement de type 1 ou service minimal, est le mode le plus simple de fonctionnement. Ce mode permet l'émission et la réception des paquets sans assurer ni le contrôle du flux, ni établissement de connexion logique avec le récepteur, ni même la vérification de la bonne réception des données.
Il n'existe alors qu'une seule primitive dédoublée pour créer 2 commandes l'une pour l'émission, l'autre pour la réception des données : L.DATA. Cette primitive utilisée avec le suffixe REQUEST sert à émettre et avec INDICATION sert à la réception. On doit alors et quelque soit la direction fournir les paramètres suivants :
Dans le cas d'un fonctionnement de type 1, les couches supérieures sont chargées des éléments non-traités par la sous-couche LLC. Ce format est donc adapté à des Réseaux utilisant les couches OSI supérieures. Dans le cas des Réseaux locaux de type SENSOR BUS, on a tendance à préférer à ce mode de fonctionnement des types 2 (ou 3), ou alors pas de fonction LLC du tout.
Fonctionnement type 2.
Le fonctionnement de type 2 lui par contre, contient un nombre beaucoup plus important de fonctions, la sous-couche LLC prenant en charge quelques fonctions des couches supérieures, il y a cette fois ci une liaison logique entre sous-couches LLC d'émission et de réception.
En effet, dans ce mode de fonctionnement, les sous-couches gèrent non seulement les possibles erreurs de transmission, mais aussi l'établissement des connexions et le contrôle du "débit" des paquets émis. Par débit, il faut comprendre ce terme comme le fruit d'une communication asynchrone, c'est à dire l'envoi d'un message quand le récepteur est capable de le recevoir (gestion des mémoires tampons). On appelle en général cette fonction le contrôle du flux.
Bien entendu, le nombre de commandes croit en conséquence, on ne trouve plus uniquement L.DATA. L'ensemble de ces commandes de contrôle est résumés dans le tableau de la page suivante.
Attention, il faut comprendre que le mot REQUEST permet aux couches supérieures de signaler leurs volontés d'émission, cette dernière est alors transmise au SAP récepteur qui sous forme d'INDICATION prévient ses couches supérieures. La fonction CONFIRM permet à l'émetteur de signaler aux couches supérieures comment le SAP récepteur s'est comporté vis à vis de la commande (et pas quand ni comment les couches supérieures du récepteur ont reçu l'information).
Vers un type 3.
Il existe actuellement un nouveau type (type 3) en cours de spécification (donc encore incomplet et risque de changer). Ce protocole est de type purement asynchrone, il permet de s'affranchir de la mise en rapport des SAP. Son fonctionnement en est donc simplifié. Toutefois, il prend en charge les fonctions de contrôle d'erreur sur les paquets émis.
Bien sûr, le nombre de primitive diminue en conséquence et passe alors à 2, L.DATA.ACK (primitive de transmission) et L.REPLY_UPDATE (primitive d'interrogation).
Les PDU (ou LLC PDU ou LPDU)
L'autre point très important de la sous-couche LLC est le PDU ou PROTOCOL DATA UNIT (unité de donnée des protocoles). Cette unité représente la façon dont la sous-couche LLC présente ses données à la couche MAC. On peut donc considérer que les PDU sont les petits frères des SAP, l'un reçoit des données des couches supérieures, l'autre se charge de les envoyer pour transmission.
Les PDU utilisent les paramètres transmis aux primitives SAP pour définir le paquet à transmettre. Le format de ce paquet est strictement défini et normé ce qui le rend totalement compatible pour toutes les machines d'un Réseau.
Le paquet PDU est donc composé de 4 champs, le champ de destination qui définit le SAP récepteur, le champ de source qui définit le SAP émetteur, le code définissant le type de transmission et les données à transmettre.
Format du PDU (DSAP = destination SAP et SSAP = source SAP).
Ce PDU dispose de plus de différents modes de fonctionnement permettant de transmettre des ordres ou des opérations. On a donc une certaine forme de codage, aussi bien au niveau de la définition des adresses, qu'au niveau des octets de contrôle.
Les champs d'adresses permettent de définir, par exemple, les accès groupés (1er bit du champ DSAP) ou le type d'information en transit (1er bit du champ SSAP).
D : définition de l'adresse de destination. S : définition de l'adresse de source. I/G : individuel / groupé (1 si groupé, 0 si individuel) C/R : commande / réponse (1 si réponse, 0 si commande).
Mais l'élément le plus important des PDU reste le (ou les) octet(s) de contrôle. Ces éléments ont une signification qui permet de définir comment sont réalisées les commandes, à qui elles s'adressent, ce qu'elles représentent. Pour reprendre une analogie simple, on peut les considérer un peu comme le codage des mnémoniques de l'assembleur, d'un coté, on présente un texte, de l'autre, on récupère du "code machine".
On définit ainsi 3 types de codes, les codes de type I (pour informatif) qui sont chargés de transmettre des données en fonctionnement de type 2, les codes de type S (pour superviseur) qui permettent de transmettre des ordres de supervision en fonctionnement de type 2 et enfin les codes de type U (pour Indéfini en anglais UNNUMBERED) qui permettent de transmettre tous types d'information, dans tous les modes de fonctionnement.
Format I.
Analysons les trames présentées sur la page suivante, et commençons par les PDU de format I. Le rôle de ce signal de contrôle est de transmettre les paquets dans un ordre acceptable ou en tout cas déchiffrable par le récepteur. On dispose en plus d'un indicateur permettant de définir, selon qu'il s'agisse d'un PDU de commande ou de réponse, si l'expédition du message doit entraîner une réponse ou si c'est un marqueur de fin.
Les valeurs de N°S et de N°R permettent de définir respectivement le numéro du groupe à l'émission et à la réception. On peut ainsi définir un ordre pour la circulation des paquets.
L'indicateur P/F permet de définir si l'émetteur souhaite recevoir une réponse. Placé à 1 dans un PDU de commande, il signifie une demande de réponse, placé à 1 dans un PDU de réponse, il signifie la fin de la transmission.
Les formats des PDU
Format S.
Le format de supervision permet de superviser les échanges entre machine, il ne transfère pas de données, mais des informations de contrôle du flux, comme les demandes de retransmission en cas d'erreur, la suspension de la transmission pour permettre à une machine d'effectuer une tâche plus prioritaire.
Il existe 3 PDU utilisable en commande et en réponse.
RR ou REICEIVE READY (reçu et prêt à recevoir), cette fonction permet de signaler à l'émetteur que les paquets de format I numérotés jusqu'à N°R-1 ont été acquittés et que la machine peut à nouveau recevoir.
REJ ou REJECT (rejet), cette fonction permet de signaler à l'émetteur que les paquets de format I reçus depuis le numéro N°R sont à retransmettre.
RNR ou REICEIVE NOT READY (reçu et incapable de recevoir), cette commande permet de signaler à l'émetteur que les paquets de format I envoyés avant N°R-1 ont été acquittés et que depuis, le récepteur n'est plus capable de recevoir de nouvelles données.
Format U.
Le format U fonctionne aussi bien avec des types de fonctionnement 1 qu'avec des types 2. On doit donc séparer l'étude de ce format selon le type utilisé.
Type 1.
Le format U adapté au type 1 est composé de 4 commandes dont 1 qui est bidirectionnelle (utilisable par l'émetteur et par le récepteur). Le fonctionnement n'est plus asynchrone, mais réalisé sous forme d'émissions de données en série. Seule l'interrogation (régulière) du récepteur permet de définir s'il est encore capable de recevoir.
Attention, il ne faut pas croire qu'il n'y a aucun contrôle de réalisé lors de la circulation des données, simplement, ils ne se situent pas à ce niveau.
UI ou UNNUMBERED INFORMATION (information indéfinie), cette commande permet d'émettre un paquet dont le numéro d'ordre et le format ne sont pas défini à ce niveau. Cette émission n'implique pas de la part des SAP l'établissement d'une connexion.
XID ou EXCHANGE IDENTIFICATION (échange d'identité), cette commande permet à l'émetteur de préciser son identité et donc les modes de service supporté.
ID ou IDENTIFICATION (identité), cette commande est la réponse du récepteur à une commande XID de l'émetteur. Elle permet à ce dernier de s'identifier.
TEST (test), cette commande est bidirectionnelle, elle permet de définir l'état du récepteur. Lorsque l'émetteur émet la commande TEST, le récepteur lui répond s'il est capable ou incapable de recevoir.
Type 2.
Dans le cas du type 2, on se trouve en face de 2 commandes et de 3 réponses, dans ce mode de fonctionnement, on "retrouve" partiellement les commandes du mode S et du mode I. Comme on cherche à contrôler le flux d'information, et que l'on fonctionne en mode connecté, on établit donc un mode de transmission asynchrone.
SABME ou SET ASYNCHRONOUS BALANCED MODE EXTENDED (activation du mode asynchrone équilibré), cette commande permet d'établir la connexion et ses règles de fonctionnement en respectant les indications fixées par la norme du Réseau. Cette commande exige un acquittement du récepteur.
DISC ou DISCONNECT (déconnexion), cette commande permet de terminer la connexion. Cette commande exige un acquittement du récepteur.
UA ou UNNUMBERED ACKNOWLEDGMENT (acquittement), cette commande permet au récepteur de répondre à toutes les commandes de l'émetteur. Il ne permet pas de préciser si les données ont été acquittées. DM ou DISCONNECTED MODE (mode déconnecté), cette commande permet au récepteur de signaler qu'il est actuellement déconnecté.
FRMR ou FRAME REJECTION (trame rejetée), cette commande permet de signaler que la trame reçue n'est pas valable et doit être réémise. Cette commande permet aussi de définir le type d'erreur détectée (non-respect des N° de réception ou d'émission, erreur de transmission non corrigible, mauvaise définition de PDU).
Vers un type 3.
Dans ce mode on dispose alors d'une commande et de 2 réponses qui établissent un dialogue asynchrone sans établir de connexion.
UI ou UNNUMBERED INFORMATION (information indéfinie), cette commande permet d'émettre des données.
UA ou UNNUMBERED ACKNOLEDGMENT (acquittement indéfini), cette réponse signale à l'émetteur que les données envoyées précédemment ont été acquittées.
FRMR ou FRAME REJECTION (rejet de trame), cette réponse signale une erreur de transmission nécessitant une réémission du paquet.
Ce qu'il faut retenir de la sous-couche LLC.
Les formats des mots de contrôle ne sont pas incompatibles entre eux, on peut par exemple expliciter par des commandes de format U, l'établissement d'une communication, puis utiliser un format I pour transmettre des données. Il n'y a pas d'incompatibilité à ce niveau. Il est par contre totalement interdit de changer de type de fonctionnement pendant une transmission.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
