Résumé

  • Le format Header-Last du RFC 1963 permettait à l’émetteur de connaître la taille après compression avant d’indiquer si le paquet commençait, poursuivait ou terminait une trame série.
  • Les bits de segmentation de SDTP étaient B et F. E signalait une extension d’en-tête CS, et SDTP ne comportait aucun numéro de séquence ; la combinaison B/E avec séquence appartenait au PPP Multilink du RFC 1990.
  • Length séparait des paquets SDTP dans une trame PPP composée et Port sélectionnait un canal négocié. Aucun de ces champs ne prouvait qu’aucun fragment n’avait été perdu ni que le service utilisateur avait repris.

Une trame réseau se lit habituellement depuis son en-tête. Le RFC 1963, publié à titre informatif en août 1996, demandait au récepteur de faire autre chose : commencer par les données transportées, puis revenir depuis la fin du paquet pour lire un en-tête d’adaptation dont l’ordre des octets était inversé.

Cette organisation découlait d’une contrainte temporelle. Les travaux à l’origine du protocole concernaient notamment la compression de données synchrones dans des DSU/CSU. Lorsqu’une trame série compressée devait être répartie entre plusieurs paquets SDTP, l’émetteur ne connaissait pas toujours la limite utile avant que le compresseur ait produit suffisamment de sortie. Un en-tête placé au début l’aurait obligé à annoncer trop tôt la nature de la portion. Placé à la fin, il pouvait être ajouté après l’observation de la taille compressée et passer lui aussi par le compresseur.

Header-Last était donc le format par défaut. Header-First restait négociable lorsque les trames n’étaient pas divisées, lorsque la compression était indépendante de SDTP ou lorsque le matériel préférait un parcours conventionnel. Ce choix décrivait le parseur commun et l’ordre des opérations chez l’émetteur. Il ne mesurait ni le taux de compression, ni la synchronisation du compresseur, ni la réussite de la reconstruction.

Avant tout trafic, PPP devait atteindre sa phase Network-Layer Protocol et Serial Data Control Protocol devait se trouver dans l’état Opened. IANA associe 0x0049 à PPP-SDTP et 0x8049 à PPP-SDCP. Ces valeurs et cet état établissaient que les deux extrémités avaient convenu d’une syntaxe. Ils ne certifiaient pas l’état d’un paquet ultérieur.

Sans options supplémentaires, un champ Information PPP contenait exactement un paquet SDTP. Length n’apparaissait que si Length-Field-Present et l’option LCP Compound-Frames du RFC 1570 avaient toutes deux été négociées. Plusieurs paquets SDTP pouvaient alors partager le même conteneur PPP. Chaque Length couvrait son propre champ, le Port éventuel, l’en-tête d’adaptation, les données et le bourrage de bits impairs. Un octet codait une longueur totale de 2 à 255, deux octets étendaient cette limite à 65535, et zéro désignait tout le reste du champ Information.

Length permettait ainsi de savoir où s’arrêtait une unité de transport. Il ne disait pas qu’une trame série originelle était complète. Dans une même trame composée, deux unités successives pouvaient concerner des ports, des trames ou des portions différents. Une frontière syntaxique exacte n’était pas un reçu de livraison.

La même prudence s’applique à Port. Sans Multi-Port, toutes les données appartenaient au Port 0 implicite. Après négociation, chaque paquet portait un numéro : 0 à 254 pour les données, 255 pour le contrôle. Certaines options étaient définies par port, tandis qu’une commande de contrôle de flux sur 255 pouvait viser l’ensemble des ports.

Ce numéro était une clé locale de démultiplexage. Le RFC 1963 ne le liait cryptographiquement ni à un câble, ni à un équipement, ni à un client. La signification de Port 7 dépendait de l’état convenu et conservé aux deux extrémités. Pour prouver une identité physique ou commerciale, il fallait une autre source.

La frontière de la trame série résidait dans les bits B et F. En mode synchrone de type HDLC, B indiquait le début et F la portion finale ; aucun des deux ne décrivait une portion intermédiaire, les deux ensemble une trame entière. En mode asynchrone, les deux devaient être positionnés. E avait un rôle distinct : annoncer l’extension CS. E ne signifiait pas « end ».

Cette précision évite une attribution erronée. Le RFC 1990 consacrait B et E au début et à la fin d’un fragment Multilink et ajoutait un numéro de séquence sur 12 ou 24 bits pour un faisceau de liens. Le RFC 1963 ne possédait pas ce champ de séquence. SDTP ne pouvait donc pas déduire un fragment manquant par la progression d’un compteur Multilink.

La présentation du RFC demande elle-même une lecture critique : son tableau B/F imprime 1,0 pour Begin Frame et Final Frame, alors que la définition immédiatement précédente attribue clairement la fin à F. Le texte et les définitions environnantes fondent l’interprétation B/F. Ils ne révèlent pas le comportement d’un logiciel précis. Seuls son code, ses tests ou une capture pourraient montrer comment il traitait cette ligne répétée.

Le traitement du contrôle de trame établissait une limite encore plus importante. SDTP transportait le contenu entre les fanions HDLC, sans les fanions. Le FCS interne voyageait normalement avec la trame. Une option FCS-Type pouvait autoriser sa suppression à l’émission et sa régénération à la réception. Mais le RFC déconseillait cette régénération sans PPP Reliable Transmission ou une autre couche signalant de façon fiable les paquets perdus. Il interdisait aussi de remettre à l’utilisateur une trame incomplète ou mauvaise accompagnée d’un nouveau FCS valide.

Cette règle explique ce que B/F, Length et Port ne pouvaient pas garantir. Ils indiquaient une forme, une étendue et une destination négociée. Ils n’apportaient aucun signal de perte. Si une portion médiane disparaissait sans alerte inférieure, un récepteur pouvait assembler une structure plausible. Recalculer son FCS aurait changé une absence de preuve en apparence de validité.

Le RFC 1663 proposait séparément Numbered-Mode, fenêtres, acquittements et retransmissions. Le RFC 1962 négociait les algorithmes de compression et leurs échanges Reset. Il serait trompeur de leur emprunter des garanties pour les attribuer à SDTP. Header-Last facilitait la décision de découpe après compression ; il n’était ni le compresseur ni le mécanisme de fiabilité.

La distinction formulée par Lu Heng entre structure déclarée et preuve exécutable éclaire ce dessin. Le RFC 1963 publiait un minimum commun : position des champs, marques de frontière, longueur optionnelle et espace de ports. Un système en fonctionnement devait encore démontrer l’ordre d’arrivée, la détection des pertes, la politique de tampon, les liaisons locales de ports, le traitement du FCS et la remise à l’application. La norme rendait ces questions auditables ; elle n’y répondait pas à la place des machines.

Sources