Rôle
Assurer le transfert de blocs de données entre équipements directement connectés avec un taux d’erreurs résiduelles négligeable.
Le support n’est pas parfait, loin s’en faut ! Il peut se rompre ou générer des erreurs de transmission, il faut donc le contrôler, c’est le rôle de la couche 2.
Dans cette définition les mots importants sont :
- Blocs de données : qui suppose que la PDU (vous vous souvenez ?) n’est plus un EB, mais un ensemble d’EB structurés en blocs (un bloc, une trame, une cellule, etc…).
- Equipements directement connectés : car, à un support correspond une et une seule couche 2, indépendante d’une autre couche 2, qui surveille un autre support. Attention ! Ces deux couches peuvent employer le même protocole, mais il n’y a aucune interaction entre-elles. (voir schéma ci-contre)
- Taux d’erreurs résiduelles : qui suppose en premier lieu que la couche 2 peut contrôler les erreurs par un mécanisme du protocole, et; qu’en deuxième lieu il existe un certain nombre d’erreurs non détectées (les erreurs résiduelles). Il sera dans ce cas possible de faire d’ultimes contrôles d’erreurs dans les couches supérieures.
Fonctions
1 – Il faut formater une trame (un bloc de données).
La couche 1, nous l’avons vu, véhicule des
EB, qui sont les PDUs de niveau 1. Au niveau 2, la PDU est une trame, une cellule ou un bloc, qui véhicule la PDU de niveau 3 (un paquet) dans son champ information.
La couche 2, pour réaliser ses fonctions (contrôle d’erreurs, séquencement, contrôle de flux, etc …) doit nécessairement possèder dans sa PDU un ou plusieurs champ dans lesquels elle pourra inscrire ces contrôles (le PCI : Protocol Control Identifier). Souvent un champ spécifique est réservé pour assurer le contrôle d’erreur.
Il faut aussi pouvoir délimiter le début et la fin d’un bloc d’information (une trame). Il faudra donc utiliser des délimiteurs (fanions) de début et de fin afin de permettre au récepteur de répèrer la trame dans le flot de bits de niveau 1 qu’il reçoit.
2 – Il faut assurer la transparence du protocole aux codes de données.
Nous venons d’admettre qu’une trame, pour être repérée par la couche 2 dans le flot binaire de la couche 1, doit comporter des fanions de début et fin. Ces fanions correspondent forcément (ou du moins souvent !) à des séquences binaires définies.
Par exemple si la couche 2 détecte une séquence binaire 01110 elle identifiera un fanion de début (qui peut être le même que celui de fin, d’ailleurs !).
La situation se complique si vous devez absolument transmettre dans vos données une séquence identique !
La procédure de niveau 2, doit donc mettre en oeuvre un mécanisme permettant d’acheminer cette séquence sans pour autant qu’elle soit prise pour un fanion. La méthode la plus courante, consiste à insérer un zéro à la suite de toutes séquences de deux 1 consécutifs, que ces suites soit suivies d’un 0 ou d’un 1. Le récepteur retirera tous les 0 se situant après deux 1 consécutifs. Si les deux 1 sont suivis d’un 1 c’est alors un fanion qui indique la fin de trame (et le début de la suivante).
Ce mécanisme est communément appelé « la moulinette 7E« , car il est utilisé dans les procédures SDLC d’IBM, HDLC de l’ISO (ainsi que les dérivés comme LAP B, LAP D et même PPP) sur des séquences 01111110 (7E en héxadécimal) qui sont les fanions.
3 – Il faut contrôler les erreurs de transmission.
Nous avons admis que le support n’était pas parfait. Une connexion à travers le réseau téléphonique peut-être longue (en distance), elle emprunte beaucoup d’équipements et parcourt de grandes longueurs de câble. Si lors d’une conversation téléphonique on peut accepter un taux d’erreur important qui a peu d’incidence sur la qualité de la communication, il n’en est pas de même pour les transmissions informatiques qui nécessitent une transmission parfaite de chaque EB. Restituer un 0 pour un 1 transmis peut avoir des conséquences catastrophiques. Il est donc inconcevable de faire confiance au support de transmission. Le protocole de niveau 2 mettra donc en oeuvre des mécanismes de contrôle d’erreurs.
Il existe différents mécanismes de contrôles d’erreurs. Les plus connus sont les VRC, LRC et CRC, suivis de près par le Checksum.
Le VRC (Vertical Redundancy Code) est réservé aux procédures dites « Orientées Caractères » fonctionnant sur support asynchrone (si vous avez oublié la notion d’asynchrone : retour à la page précédente). Une procédure orientée « caractères » est un protocole de niveau 2, qui utilise une grille de code de caractère (ASCII ou EBCDIC généralement) pour définir les différents champs d’une trame ou les différentes commandes (connexion, libération, acquittement, gestion de flux, etc…). Une trame commencera par un caractère STX (Start of TeXt) et se terminera par un caractère ETX (End of TeXt) de la grille de code ASCII par exemple. Le VRC propose d’effectuer un contrôle d’erreur caractère par caractère en insérant un bit supplémentaire au caractère, appelé « Bit de Parité« . Le VRC comptera, par exemple, le nombre de 1 dans le caractère défini sur 7 bits. Si il trouve un nombre impair de 1 il insérera un huitième bit à la valeur 1 afin d’avoir sur 8 bits un nombre pair de 1. Le récepteur vérifiera qu’il y a bien un nombre pair de 1 sur un caractère de 8 EB. Si ce n’est pas le cas, il considérera qu’il y a une erreur sur le caractère et le rejettera. Cette parité peut être de type Paire (EVEN), Impaire (ODD), Sans parité (NONE), Forcé à 1 (MARK) ou Forcée à 0.
Le LRC s’applique aux procédures orientées « caractères » mais en transmission synchrone. Les données ne sont plus émises caractères par caractères, mais blocs par blocs (ou trames). La procédure de niveau 2 va stocker dans une mémoire tampon un ensemble de caractères qui formera un bloc. Caractère par caractère une opération VRC sera appliquée. Puis sur l’ensemble des bits de parité du bloc et sur l’ensemble de bits des caractères une opération de parité telle que décrite précédemment sera appliquée. Il en résultera donc un octet complet qui sera un octet de contrôle d’erreur. Cet octet sera émis à la suite de la trame, on l’appelle le LRC (Longitudinal Redundancy Code). Le récepteur va stocker la trame dans ses buffers, recalculer le LRC et le comparer avec le LRC reçu, s’il y a une différence, il y a erreur.
Le CRC (Cyclique Redundancy Check) est une opération mathématique complexe (enfin un peu …), que je ne peux pas vous présenter ici. Le principe est d’effectuer une division polynômiale sur le bloc de données grâce à un polynôme diviseur appelé : « Polynôme Générateur ». Cette division donne en résultat un reste qui est émis à la suite de la trame sur le support. Le choix du polynôme générateur déterminera la taille maximum des trames qu’il sera possible de contrôler ainsi que la taille du reste. Ce reste est placé à la fin de la trame et est appelé le CRC4, CRC8, CRC16 ou CRC32 selon le nombre de bits qui lui est réservé. Les trames HDLC, PPP, LLC utilisent des CRC16. Les trames sur réseau local utilisent des CRC32.
Le CRC effectue des opérations au niveau bit, il est donc utilisé sur des procédures « Orientées Bits ». C’est à dire des procédures dont la valeur d’un seul EB dans une trame peut être interprété et être significatif pour le protocole. La procédure n’utilise donc pas des caractères pour structurer ses champs mais des nombres variables de bits.
Chacun de ces contrôles d’erreurs possède ses limites en détection d’erreurs. Le VRC sera par exemple incapable de détecter une erreur si deux bits ont changé dans le caractère, le LRC ne détectera pas les erreurs simultanées sur des bits en quadrature (formant un carré) dans le bloc. Le CRC est beaucoup plus fiable mais n’est pas infaillible non plus. Il existe donc des erreurs qui ne sont pas détectées, c’est le taux d’erreurs résiduelles. Il relèvera des couches supérieures d’effectuer un nouveau contrôle (généralement en couche 4).
4 – Il faut gérer le dialogue.
Le protocole de niveau 2 est un dialogue qui s’établi entre deux équipements séparés par un support. Comme dans la vie courante, il existe deux modes essentiels de partage de l’information orale, le mode dirigé et le mode libre.
Dans le mode dirigé, c’est comme à l’école ! Il y a un maître et un esclave (oui, oui, je sais ! Un élève ! Mais j’ai gardé de mauvais souvenirs …). L’esclave parle quand le maître l’y autorise. A l’école, le maître voit qu’un élève lève le doigt. En téléinformatique ça ne peut pas marcher comme ça, puisque le maître n’a pas d’yeux ! (NDLR: Elle est bien bonne celle-là !). En fait le maître va envoyer à l’esclave (ou aux esclaves) des invitations à émettre. Ces invitations sont communément appelées des POLLING. L’esclave répondra par une émission de données ou par « Rien à émettre, CHEF !!! ». Le maître est tout de même légérement civilisé, ainsi lorsqu’il a quelque chose à dire à l’esclave, il le prévient par un SELECTING. Bien sûr l’esclave n’a pas le choix, il reçoit ! C’est ça la démocratie ! En bref, l’esclave se tait tant que le maître ne l’a pas autorisé à parler, les procèdures fonctionnant sous ce mode sont dites « Non Equilibrées« , dans le sens ou la répartition de faculté à prendre l’initiative d’un dialogue n’est pas équilibrée. En Anglais on dit : Unbalanced. La procèdure VIP de BULL est une procédure non-équilibrée fonctionnant en mode caractère (un dinosaure, quoi !).
Dans le mode libre (et non pas « Le Monde Libre »), c’est comme à l’assemblée nationale ! Chaque extrémité peut prendre la parole quand bon lui semble (quand elle a quelque chose à dire, pas comme à l’assemblée nationale !). Les équipements doivent donc être capable d’écouter en même temps qu’ils parlent (ce qui n’est pas à la portée du premier venu, et surtout pas de nos députés …). Ces procédures sont extrêmement rentables en terme de capacités de transmission car elles évitent les temps morts pendant lesquels un esclave doit se taire ! Elles présentent par contre l’inconvénient de nécessiter des mécanismes de gestion du dialogue beaucoup plus complexes (hors de portée de nos députés …). Ce mode est démocratique, égalitaire, il est « Equilibré » (moralement aussi, ce qui n’est pas toujours le cas de …)
La mode est plutôt à la procédure équilibrée et orientée bit ! (L’idéal pour un député, quoi !).
Remarques
Encore une fois, cette page ne vous présente que quatres malheureuses fonctions de la couche 2, pourtant il en existe bien d’autres :
- la correction d’erreurs (car nous n’avons parlé ici que de détection d’erreurs),
- le contrôle de flux,
- l’adressage,
- la gestion d’accès au support (le MAC pour les fins connaisseurs),
- la gestion de connexion,
- et puis, et puis …
Vous avez toujours une meilleure idée du rôle de ce satané protocole PPP que l’on voit apparaître dans l’onglet « Serveur » des propriétés de connexion sur l’icône d’accès à distance à Wanadoo. Ci-dessous quelques noms de procédures :
- PPP : Point to Point Protocol : Protocole non ISO, mais défini par l’IETF sous une RFC, permettant l’acheminement du protocole IP (et d’autres) sur un lien série en communication synchrone ou asynchrone, équilibrée ou non, et offrant nombre de services tels que l’authentification d’accès.
- HDLC : High level Data Link Control : Protocole de niveau 2 très élaboré normalisé ISO. Nombre d’autres protocoles prennent leur source dans cette gigantesque boîte à outils. Ainsi le LAP-B utilisé pour les accès à un réseau X25 ou le LAP-D, utilisé pour la signalisation sur le canal D Numéris sont-ils directement issus de ce protocole.
- LLC (1,2 ou 3) : Logical Link Control : Protocoles normalisés ISO s’inspirant fortement d’HDLC. Ils définissent des champs d’adressages évolués et des niveaux de services différents en fonction du type de procédure LLC. Avec ou sans connexion, avec ou sans acquittement, avec ou sans gestion de flux etc… Ils sont très utilisés en environnement réseau local.
- SDLC : Synchronous Data Link Control : La maman d’HDLC. Développée par IBM, cette procédure permet de gérer des dialogues synchrones en mode équilibré ou non, avec un ou plusieurs équipements simultanés à travers de nombreux types de supports (RTC, Liaisons Louées, etc…). HDLC est très fortement inspiré de SDLC, et merci IBM.
- DLC : Data Link Control : La grand-mère d’HDLC ou la maman de SDLC si vous préférez ! Le papa c’est bien sûr IBM !
Si la couche 3 vous a toujours intriguée, si l’utilité d’un protocole comme IP ou X25 vous semble nébuleuse … Suivez-moi !