Nous étudions ici les différents cas aboutissants à une déconnexion du niveau 2 HDLC ainsi que la manière de traiter les erreurs « logicielles ». Ce sera également l’occasion de tirer des enseignements sur l’état de votre lien en examinant les cas d’erreurs que le protocole pourrait vous remonter.
Les cas de déconnexions
Il existe différents cas de déconnexion, mais il n’y a qu’une méthode « propre » !
Déconnexion par DISC/UA :
Dans le schéma ci-contre U décide de rompre la connexion de niveau 2. Ceci n’arrive réellement que dans le cas d’un arrêt « propre » de l’équipement X25. Par exemple, la mise hors tension d’une station ou d’un serveur (ou d’un commutateur) par un arrêt logiciel puis mise hors tension. En cas de coupure brusque le comportement est différent.
Ici Les échanges d’informations sont terminés. U acquitte la dernière trame qu’il a reçu. U a également reçu tous les acquittements nécessaires de R. Il émet une trame de commande DISC pour signifier à R sa volonté de rompre la connexion. R accepte par une UA en réponse (entre-nous il n’a pas le choix, s’il refuse U continuera d’émettre des DISC N2 fois). Puis R passe en mode déconnecté en émettant N2 fois des DM. Ensuite « silence radio sur la ligne » !
Déconnexion par Réinitialisation du niveau 2 :
Ici U « perd les pédales » et émet une trame SABM en plein échange de données ! La sanction ne se fait pas attendre ! R accepte la SABM par une réponse UA et passe en mode déconnecté immédiatement après ! Il faudra que U réémette une SABM pour rétablir le niveau 2 ! Au passage vous remarquez que R répond par une UA avec F:1 car la SABM a été émise avec P:1. Ce cas est plutôt rare ! C’est un cas de rupture qui est généralement utilisé en cas d’erreurs logicielles grave, vous le retrouverez lorsque nous étudierons la trame FRMR ci-dessous!
Déconnexion par perte intempestive de niveau 1 :
S’il y a eu perte de niveau 1, il n’y a pas pu avoir de protocole d’échange pour une déconnexion. Donc au rétablissement du niveau 1, on oublie tout et le réseau émet des DM pour informer qu’il se considère en mode déconnecté. L’U devra établir la connexion par SABM/UA. Seules les trames qui ont été acquittées avant la déconnexion intempestives auront été prises en compte. Toutes les trames qui auront été reçues par U ou par R mais qui n’auront pas été acquittées seront « poubellisées« .
Réveille-toi !
Que se passe-t-il si une station arrête d’émettre des données pendant un temps assez long ?
Les cas d’erreurs les plus courants !
Nous allons ici examiner différents cas d’erreurs possibles, il est bien sûr hors de question de dresser une liste exhaustive.
Erreur sur trame INFO :
Nous avons déjà évoqué ce problème dans le chapitre précédent … Ici R a précédemment reçu une trame avec Ns:1. Il attend donc une trame avec Ns:2. Mais celle-ci comporte une erreur qu’il détecte par l’analyse du FCS. Il jette donc la trame et examine la suivante. Celle-ci a un Ns:3, il a donc une erreur de séquencement sur les Ns.
Il rejette la trame par une trame de réponse REJ en indiquant dans le Nr, le numéro de la prochaine trame qu’il attend, entre-autre la 2 pour notre cas !
Dans le deuxième exemple, nous sommes dans un cas d’émission de trames par anticipation d’acquittement (exploitation du facteur K, entre-autre ici K = 4). Vous remarquez que la trame 1 (Ns:1) subit une erreur. R la jette. Il reçoit ensuite 2 et 3, il lui manque 1 ! Il émet donc une REJ avec Nr:1 qui acquitte la réception de 0 mais pas des autres !
La REJ a pour effet de stopper tous les timers T1 en cours chez U.
U va donc réémettre immédiatement les trames 1, 2 et 3 puisque la REJ n’a acquitté que la 0.
Ceux qui suivent bien depuis le début (j’espère que vous êtes nombreux) se demandent pourquoi R n’a pas plutôt envoyé une trame RR avec Nr:1 à la place de la REJ. L’effet semblerait être le même !
Pas tout à fait ! Dans l’exemple ci-contre je simule ce qui arriverait si R émettait une RR au lieu de la REJ.
La RR va stopper les T1 des trames ayant leur Ns < Nr de la RR. Donc ici RR avec Nr:1 stoppe le T1 de la trame Ns:0. Les autres T1 continuent de courir ! Les trames 1, 2 et 3 seront réémises à expiration de leurs T1 respectifs.
Au final il y aura donc bien redressement de l’erreur et rétablissement du séquencement des informations, mais il aura fallu attendre 3 fois T1 au lieu de réémettre immédiatement les trames comme avec la REJ.
Donc signaler l’erreur par une RR induit une réadaptation trop longue !
Il est à noter que dans le cas de la REJ les trames ne sont pas réémises avec le bit P puisqu’elles ne sont pas émises à expiration du T1. Alors que dans le deuxième cas, elles sont émises avec le bit P (à expiration du T1), ce qui oblige en plus R à acquitter chacune d’elle par une RR avec F:1 !
Perte d’une RR :
Ici l’erreur de transmission n’a pas lieu sur trame INFO mais sur une RR émise par R. U jette la RR et ne stoppe donc pas le T1 de la trame qu’elle acquittait (ici trame 1). Donc la trame est réémise avec P:1 à expiration de son T1.
R reçoit alors deux trames consécutives avec Ns:1 ! Il y a encore erreur de séquencement. Il répond donc par une trame REJ avec Nr:2 qui est le numéro de la prochaine trame qu’il attendait ! La REJ a le bit F:1 car la trame INFO qu’il a reçu avait P:1.
U prendra cette REJ comme un acquittement de la trame Ns:1 et émettra donc la trame 2.
Perte d’une RR non détectée :
Ici le cas amusant d’une erreur sur trame RR dont personne ne se rend compte ! R a reçu 3 trames consécutives. Comme il n’a pas de données à émettre à expiration du T2 de la première trame il émet une RR avec Nr:3.
Celle-ci subit une erreur de transmission. U la jette (FCS : Faux). Puis émet une trame INFO avec Ns:4. R reçoit cette trame et active un T2. Dans ce laps de temps, il a tout à coup des données à émettre. Il envoie donc une trame INFO avec Nr:5 (puisqu’il a bien reçu la 4). Il stoppe son T2.
U reçoit la trame INFO et stoppe tous les T1 < Nr de la trame. Et tout le monde est content ! L’INFO est arrivée avant expiration du T1 de la trame Ns:0 ! On ne s’est rendu compte de rien !
Ici on s’en sort bien car le T1 était suffisamment long ! Que serait-il arrivé si le T1 de la trame 0 avait été plus court ? Je vous laisse phosphorer !
Traitement des erreurs logicielles !
A priori, il semble que les équipements HDLC soient très rigoureux ! La norme prévoit tous les cas de dysfonctionnement possibles relatifs notamment aux erreurs potentielles de transmission. Mais la norme sait aussi que nul n’est parfait, et qu’un équipement peut aussi « perdre les pédales » ou peut ne pas implémenter correctement la norme (petits aménagements personnels).
LAP B permet donc de signaler des erreurs détectées dans des trames présentant des CRC corrects. Ces erreurs peuvent se produire essentiellement dans trois cas :
- un dysfonctionnement passager d’un des équipements
- une mauvaise implémentation de la norme sur un des équipements
- une erreur de transmission non détectable par le CRC (rappelez-vous la notion de taux d’erreur résiduel présentée dans le cours OSI).
Dans ce cas, l’équipement qui détecte l’erreur (ou l’incohérence) va retourner à son correspondant une trame spéciale : la trame FRMR.
Cette trame comporte un certain nombre d’informations qui permettront de déterminer d’où peut venir le problème :
- les deux premiers octets (A et C) sont identiques à ceux déjà étudiés précédemment. A est toujours à la valeur 03h, elle est donc toujours une trame de réponse. L’octet C a pour valeur 87h ou 97h selon que le bit F est positionné ou non (en regard de l’état du bit P de la dernière trame de commande reçue).
- le troisième octet est la recopie exact du champ C de la trame qui a déclenché la FRMR (celle qui pose un problème à priori, sans avoir pour autant son CRC faux !).
- le quatrième octet comporte les compteurs Ns et Nr (appelés ici Vr et Vs) de l’émetteur de la trame FRMR. Le bit R de l’octet indique si la trame rejetée est une trame de commande ou de réponse.
- le cinquième octet indique le type d’erreur annoncé, ci-dessous quelques exemples les plus courants :
- 01h : Champ C de la trame reçue inconnu
- 03h : Format de trame incompatible avec le type annoncé par le champ C de la trame reçue (par exemple : Recevoir une trame INFO avec un champ C indiquant une RR)
- 08h : Erreur de séquencement sur compteur Nr (alors qu’il n’y a pas eu de perte de trames).
Les informations véhiculées par cette trame n’ont pas d’utilité réelle pour le protocole lui-même. Par contre elles pourront servir à un administrateur réseau pour déterminer l’origine du problème. Pour lire ces informations il faudra que l’équipement X25 offre une fonction logicielle capable d’interpréter le contenu des trames FRMR et de le remonter sur écran par exemple, ou que l’administrateur installe un analyseur de protocoles sur la ligne de transmission.
Quels sont les effets d’une trame FRMR sur le protocole ? C’est simple ! Déconnexion immédiate !
Ici, il y a détection d’une incohérence de Nr. En effet, R n’a pas émis de trames entre les réceptions des trames 0 et 1 de U, pourtant le Nr de la trame 0 indique 0 et le Nr de la trame 1 indique 1 ! Ceci ne peut qu’être une erreur !
Comme le FCS est OK, R ne peut pas attribuer cette erreur à une erreur de transmission, que R gérerai par l’émission d’un REJ, mais à une erreur logicielle. Il rejette donc par une FRMR :
- le champ adresse est à 03h
- le champ Commande indique une trame FRMR
- le champ Crej comporte la valeur du champ C de la trame INFO 1 que rejette R
- le champ INFO indique Vs:1, R:0, Vr:1 car le Ns de R est à 1 (puisque le Nr de la trame 0 est à 0 … ça va ? Vous tenez le coup ?), la trame rejetée est une trame de commande (R:0) et le compteur Nr de R est en attente de la trame 1 (Ns:1).
U n’a plus qu’une solution : Déconnecter le niveau 2 en réémettant une SABM/UA.
S’il ne le fait pas, R va réémettre N2 fois la trame FRMR puis passera en mode déconnecté (DM).
Lorsque la déconnexion est faite, U devra rétablir la connexion par un nouveau couple SABM/UA.
Remarques et analyses !
A ce stade on peut faire plusieurs remarques.
Surveillance de l’état du niveau 1 par le niveau 2
On pourra se faire une idée assez précise de « l’état de santé » de la connexion physique par une analyse statistiques des trames :
- un fort taux de trames INFO avec P:1 suppose un mauvais support générant un taux d’erreurs important et donc des réémissions fréquentes.
- un nombre de REJ important augure du même genre de problème car il est consécutif à une perte importante de RR
- un nombre élevé de SABM/UA est plus symptomatique de micro coupures du support, qui engendre une tombée intempestive de la connexion niveau 2.
Vous comprenez ici que chaque fois qu’il y a une erreur du support, il y a une correction par retransmission. Cette retransmission prend du temps et au final l’utilisateur trouve que les temps de réponse sont mauvais.
Surveillance de l’état des équipements X25
En examinant la fréquence d’émission des trames FRMR, on sait que :
- le CRC est OK et que les fanions de synchro sont OK. Donc le support est bon.
- mais les formats de trames sont mauvais, ou il y a des soucis de séquencement des Nr ou encore les trames annoncées n’existent pas ! Il y a donc un problème logiciel quelque part. Soit le calcul CRC est inopérant ou pas assez fiable sur un des équipements soit un des équipements ne respectent pas correctement la règle X25.
Conclusion
Nous voici à la fin de notre présentation du LAP B (HDLC). Vous avez pu vérifier que le LAP B rempli bien les fonctions d’une procédure de niveau 2 telle que définie dans le cours OSI, il assure :
- la détection d’erreur par CRC-16
- la correction par retransmission
- la gestion de connexion (établissement et libération)
- la délimitation des blocs de données (trames) par fanion 7E
- le contrôle de séquencement de données par compteurs Ns et Nr
J’espère que ce cours vous aura enthousiasmé et aura développé votre appétit protocolaire. C’est toujours passionnant de découvrir comment d’autres érudits ont pu résoudre des problèmes qui à priori nous semble inaccessibles !
Pour terminer ce cours, dans le chapitre suivant, je vous propose une rapide présentation de l’environnement X25 qui utilise justement le LAP B (et d’autres protocoles comme le LAP D !). Il est vrai qu’X25 n’est plus beaucoup d’actualité, mais en garder une petite trace sera ma petite contribution à sa reconnaissance pour services rendus 😉
Page Précédente | Page Suivante