Ce chapitre présente les 4 paramètres principaux d’HDLC que vous pourriez être amené à définir. Il explique également leurs rôles de le processus de transfert de données ainsi leurs impacts.
Paramètres T2, T1, K et N2 …
Etudions tout d’abord ces 4 paramètres qui vous ont déjà été légérement présentés dans le chapitre précédent.
Calcul de T2 et T1
Nous avons précédemment vu que ces deux timers étaient liés mais n’avait pas la même fonction :
- T2 est un temporisateur d’attente de trame INFO pour acquittement
- T1 est un temporisateur d’acquittement de trame INFO
Dans le schéma ci-contre R envoie une trame INFO à U alors que celui-ci venait juste de commencer à émettre également une trame INFO (délai a). Dès que U a réceptionné toute la trame il enclenche un T2. Il devra acquitter cette trame avant expiration du timer.
Il effectue un traitement de la trame (notamment vérification du FCS), mais même si son traitement est rapide (délai c) il ne peut pas émettre d’acquittement tant qu’il n’a pas fini d’émettre sa propre trame d’INFO (délai b). Or ce délai d’émission est directement lié à la longueur de la trame (nombre de bits) et au débit binaire de la liaison.
Si l’on considère que les délais a et c sont négligeables (ils sont de toutes façons très difficile à estimer !), on peut en déduire que T2 doit être égal au minimum au temps nécessaire pour émettre la trame la plus longue possible sur le débit binaire donné de la liaison (T2 mini = Lmax Trame / Débit de la liaison)
Vous aurez remarqué que R a activé son T1 dès l’émission de sa trame INFO. U doit acquitter cette trame avant expiration de ce T1. Le schéma illustre la configuration la plus défavorable où U émet une trame INFO juste avant la fin de réception de la trame INFO de R. Il ne peut donc pas l’acquitter avec cette trame émise, il est obligé d’attendre l’expiration du T2 ou l’arrivée des couches supérieures de données à émettre dans des trames INFO. Ici nous illustrons le cas où en effet U doit attendre la fin du T2. T1 cumule donc les délais (e) (émission de la trame INFO de R), le délai T2 et le délai (d) correspondant au temps de transmission de la trame d’acquittement (on néglige ici le délai c). Cependant cette trame RR pourrait être remplacée par une trame INFO de longueur max qui s’est présentée juste avant expiration du T2 ! Donc dans ce cas (d) = (b) = délai de transmission d’une trame max. Au final on a donc T1 = (e) + T2 + (d) (en négligeant c) avec (e) = (d) = T2 = Lmax trame / Débit, soit donc T1 = 3 x T2 ! Heu … Vous m’avez suivi, j’espère !
Pour avoir un peu de marge on admet plutôt : T1 = 4 x T2. En effet, nous avons négligé le délai de traitement (c) qui peut influencer le délai de réponse. Nous avons également négligé un point important : L’insertion des 0 supplémentaires dans les trames par la moulinette 7E pour garantir la transparence au code ! Ceci peut allonger la taille max de trame est donc influer sur le T1.
Nous avons beaucoup parlé de taille max de trame. Comment connaître cette taille ? C’est relativement simple :
- Il vous faut vous référer à la taille max du paquet niveau 3 qui sera véhiculé dans le champ INOF de la trame. Pour celà consultez le paramètrage du niveau 3 choisi (IP ou X25 ?).
- Ces paquets sont véhiculés dans le champ Data des trames INFO.
- Comme les trames présentent également un champ Adresse de 1 octet (8 bits), un champ Commande de 1 octet et un champ FCS de 2 octets, il faut ajouter 4 octets (32 bits) à la taille max du paquet pour obtenir la taille max de la trame. Donc Lmax trame = Lmax PQ + 32.
Facteur K : Fenêtre d’anticipation d’acquittement
K = nombre de trames que l’on peut émettre sans acquittement.
Nous avons évoqué ce paramètre dans le paragraphe précédent en parlant d’émission par anticipation d’acquittement. Ce paramètre permet à un équipement LAP B d’émettre K trames INFO consécutives sans avoir à attendre d’acquittement. Par contre une fois K atteint l’équipement doit absolument attendre un acquittement qui va « ouvrir la fenêtre » ou « accorder un crédit« . Ces deux expressions sont utilisées pour décrire ce mode de fonctionnement dit « émission par fenêtre d’anticipation » ou « émission par crédit« .
L’avantage de ce fonctionnement est qu’il permet de rentabiliser l’utilisation du support. Nous avons vu que l’on préférait attendre T2 avant d’acquitter avec une RR, en espèrant avoir une trame INFO à émettre dans ce laps de temps (paragraphe Calcul de T2). Par contre, si l’on n’autorise pas l’émetteur à émettre des trames sans avoir reçu un acquittement pour chacune d’elles on oblige dans ce cas l’émetteur à attendre au minimum T2+d pour émettre chaque trame. Je m’explique (et suivez sur le schéma précédent !) :
- R émet une trame INFO à U (flèche bleu). Il enclenche un T1 et U enclenche un T2 à réception de la trame.
- Si R ne peut pas émettre d’autres trames tant qu’il n’a pas reçu d’acquittement de U, et si U attend pendant T2 d’avoir une trame INFO à envoyer, R devra attendre au moins T2 !
- Si U n’a pas de trames INFO à émettre, il envoie au bout de T2 une RR. Le délai de transmission de la RR est égal à d.
- Donc R devra attendre T2+d (et encore je ne compte pas le temps de transmission de la trame INFO initiale !) pour émettre une seconde trame INFO !
Vous croyez qu’il est payé à rien faire R ? Non ! Donc en l’autorisant à émettre K trames sans acquittement, il n’est plus obligé d’attendre T2+d ! Toujours ça de gagné !
Maintenant quelles valeurs données à K ? Au minimum on s’en doute c’est 0 ! Dans ce cas il n’y a pas d’anticipation d’acquittement. Et au maximum ?… Je vous laisse « computer » … Ouuuuiii, j’en vois un dans le fond qui lève son doigt ! Combien ? Oui ! 7 au maximum ! Et pourquoi ? …. On ne sait pas ? Coup de chance ? Amateur va … Réfléchissons :
- Comment acquittons nous les trames ? Par le compteur Nr, qui donne le numéro de la prochaine trame attendu.
- Comment est fixé le numéro d’une trame ? Par son compteur Ns.
- Combien a de bits un compteur Ns ? 3 bits.
- Quelles valeurs peut donc prendre ce compteur Ns ? De 0 à 7 !
Si l’on vous envoie les trames 0, 1, 2, 3, 4, 5, 6, 7 (soit donc 8 trames), quelle sera la valeur du Nr à donner pour acquitter ce bloc de trames ? Nr = 0 = numéro de la prochaine trame attendue !
Donc vous dites à l’émetteur de vous envoyer la trame 0, c’est bien ça que ça veut dire Nr=0, non ? Mais il vient de vous l’envoyer ! C’est la première trame du bloc de 8 trames ! Il ne va rien comprendre le pauvre ! Il va croire que vous n’avez rien reçu, et au bout des timers T1 de chaque trame, il va vous les renvoyer !
Donc on ne peut pas vous envoyer plus de 7 trames consécutives. Si vous recevez les trames 0,1,2,3,4,5,6 (7 trames) vous retournez un Nr=7 et l’émetteur comprend que vous attendez la trame 7 et que donc vous validez les trames 0 à 6 !
Maintenant pourquoi ne pas fixer définitivement le K à 7 et on en parle plus ? Parce qu’en imaginant que la trame 1 du bloc de 7 trames précédentes, arrive avec une erreur de transmission ! L’équipement va rejeter la trame et même si les trames suivantes (2,3,4,5,6) sont bonnes il devra retourner un Nr = 1, qui indiquera à l’émetteur que le destinataire ne valide que la trame 0. Donc à expiration des T1 des trames suivantes, il va toutes les réémettre ! Pour le coup, ce n’est pas aussi rentable qu’on l’aurait souhaité ! Vous réémettez 6 trames pour une trame fausse !
Donc si vous avez un taux d’erreur important sur la ligne, il est préférable d’avoir un K plus faible ! Vous réémettrez moins de trames en cas d’erreur ! Et oui ! C’est ça du « tunning » de réseau !
En résumé :
K : Fenêtre d’anticipation d’acquittement. Il est compris entre 0 et 7. Un K à 4 est bien si votre ligne n’est pas exceptionnellement bonne. Un K à 7 si vous avez un taux d’erreur très faible est mieux.
Facteur N2 : Compteur de réémission
Nous allons ici étudier ce qui justement arrive en cas d’erreurs de transmissions. Dans les paragraphes précédent j’ai dis plusieurs fois que l’émetteur renvoie les trames à expiration de leurs T1 respectifs s’il n’a pas reçu d’acquittement dans ce délai.
Dans l’exemple ci-contre la trame 0 émise par U est soumise à une erreur de transmission. R détecte l’erreur en vérifiant le FCS. Il jette donc la trame (enfin, il l’oublie plutôt ! Vous avez déjà vu des petits tas de trames à coté des équipements HDLC, vous ?).
A expiration du T1 de la trame, U n’ayant pas reçu d’acquittement, réémet la trame 0. Mais il place le bit P (puisque c’est une trame de commande on dit bit P) du champ Commande à 1. Il indique ainsi au destinataire (R ici) que cette trame est une réémission et qu’il veut un acquittement immédiat de cette trame ! C’est la règle :
Toute trame non acquittée à expiration de son timer (T1) doit être réémise avec son bit P à 1.
R reçoit correctement la trame et acquitte par une RR. Cette RR doit avoir le bit F (puisque c’est une trame de réponse on dit bit F) à 1 car elle acquitte une trame INFO ayant le bit P à 1. La régle est la suivante :
Toute trame de commande émise avec le bit P à 1 doit être acquittée par une trame de réponse ayant le bit F à 1.
J’ai bien dit « par une trame de réponse ». Donc R ne peut pas acquitter la trame INFO par une trame INFO (s’il avait eu des données à émettre) même en plaçant son bit P à 1. Car la trame INFO est une trame de commande, pas de réponse.
Dans la deuxième partie du schéma, U émet une trame 1, qui est reçue avec une erreur (perturbation sur la ligne) par R. A expiration de sont T1, U réémet la trame en positionnant son bit P. Celle-ci subit également une erreur de transmission. Il la réémet donc au bout de son T1, et ainsi de suite. U va réémettre la trame N2 fois. Au bout de N2 tentative U passera en mode déconnecté (DM) car il supposera que R a disparu ! Il faudra réinitialiser toute la connexion niveau 2 pour réémettre du trafic.
N2 permet d’accorder une chance à la connexion lorsque celle-ci est fortement perturbée. Souvent on le positionne à la valeur 9 (Pourquoi ? J’en sais rien !).
Petit subtilité : il y a un flou dans la norme HDLC à propos de ce paramètre. Il n’est pas clairement explicité si N2 inclus la première trame émise (avec le bit P à 0) ou s’il ne comptabilise que les trames émises avec P à 1. Dans le deuxième cas, cela suppose que la trame aura été émise en tout N2+1 fois. Mon schéma présente le cas où la première trame est comptabilisé. L’implémentation varie selon les constructeurs de matériel ou leur version logicielle. Pour ma part je pense qu’il est préférable d’implémenter la deuxième version qui est plus près de la réalité de la norme. Mais pour tout vous dire, tout le monde s’en fiche, ce n’est pas le paramètre le plus important !
Résumé des méthodes d’acquittement …
Dans le schéma ci-dessous, je résume trois cas d’acquittements les plus courants.
Acquittement par RR à expiration de T2 :
Ici R acquitte toutes les trames reçues à l’expiration du T2 de la trame 3. Comme il a reçu pendant le laps de temps du T2 de la trame 3, les trames 4 et 5, il acquitte avec une RR (puisqu’il n’a pas d’infos à envoyer) avec Nr = 6. Vous remarquez que, bien sûr, les T2 et T1 des trames sont donc tous stoppés par cet acquittement.
Acquittement par INFO avant expiration de T2 :
Ici R a des données à envoyer qui se présentent après la réception de la trame 4. Il envoie donc une trame INFO qui acquitte les trames 3 et 4 (Nr:5) mais pas la trame 5 qu’il n’a pas encore reçu. Les T1 de U pour les trames 3 et 4 sont donc stoppés ainsi que les T2 correspondant chez R ! Par contre les T2 et T1 de la trame 5 continuent de courir.
Acquittement au fil de l’eau par RR à expiration de T2 :
Ce mode de fonctionnement est moins courant, mais existe. J’ai du mal à lui trouver une justification. On préférera utiliser le premier mode présenté ci-dessus. Ici R émet une RR à chaque expiration d’un T2. Par contre la RR, au lieu de cumuler les acquittements pour toutes les trames reçues, n’acquitte que la trame associée au T2 qui vient d’expirer. Ici la première RR aurait pu acquitter les trames 3, 4 et 5 par un Nr=6 comme dans le premier exemple. Mais non ! Son RR est placé à 4, donc elle n’acquitte que la trame 3. Il faudra encore deux RR pour acquitter les trames suivantes ! Bonjour la rentabilité !
Synthèse
Jusqu’ici nous avons donc étudié un certain nombre de fonctions intéressantes :
- format de la trame LAP B
- principe de transparence au code (7E)
- établissement des connexions (SABM/UA)
- échange de données et fonctionnement des compteurs (Nr, Ns)
- fonctionnement par anticipation d’acquittement (K et T2)
- reprise sur erreur de transmission simple (T1, N2, bit P/F)
J’attire ici votre attention sur deux points :
- Vous aurez bien remarqué que le fonctionnement en mode connecté mobilise un certain nombre de ressources et oblige à un certain nombre d’échanges qui n’avaient jamais été présentés dans les cours IP. Par contre dans le modèle OSI j’avais bien attiré votre attention sur ce point, l’établissement d’une connexion protocolaire nécessite des moyens d’établissement, gestion et libération de la connexion ainsi que des ressources (essentiellement mémoires) sur les équipements.
- Nous avions beaucoup évoqué les problématiques de maintien du séquencement des infos et du contrôle d’erreurs avec reprises sur erreurs lors du cours OSI, vous avez ici un exemple concret. Si vous avez lu les cours IP vous avez pu remarquer que nous n’avions pas toutes ces préoccupations.
Nous allons maintenant dans les chapitres suivant, compléter l’étude du mode connecté en étudiant les modes de déconnexions et vérifier la robustesse du protocoles en vérifiant le fonctionnement sur des cas d’erreurs un peu plus complexes.
Page Précédente | Page suivante