Résumé

  • RFC 1490 proposait, sans l’imposer, de fragmenter les paquets trop grands pour la taille maximale d’une trame du réseau Frame Relay ; la reconstruction restait à la limite entre les équipements du réseau.
  • Le mécanisme supposait un ordre strict sur un circuit virtuel. Une pièce manquante ou corrompue entraînait la suppression du message entier ; le protocole supérieur devait le retransmettre.
  • En 1998, RFC 2427 indiquait que l’encapsulation multiprotocole avait été largement mise en œuvre, mais que cet algorithme n’avait pas d’implémentations interopérables. Le texte l’a retiré au profit de FRF.12.

Le constat ne porte pas sur toute la RFC 1490. En 1998, la RFC 2427 explique que l’encapsulation multiprotocole qu’elle remplace avait été largement mise en œuvre et utilisée. Dans la même annexe, elle précise qu’aucune implémentation de l’algorithme de fragmentation de la RFC 1490 n’interopérait avec une autre. Le mécanisme disparaît de la nouvelle spécification et cède la place à FRF.12. Le texte ne prétend pas que personne n’a jamais écrit ce code ; il dit que les implémentations n’étaient pas interopérables. Cette distinction est le cœur de l’histoire.

La difficulté de 1993 était concrète. Publiée en juillet, la RFC 1490 décrit comment transporter du trafic routé ou ponté sur une dorsale Frame Relay. Selon le réseau, la taille maximale d’une trame pouvait descendre à 262 octets. Un paquet déjà encapsulé pouvait dépasser cette limite. La RFC recommandait donc la fragmentation et le réassemblage, tout en les laissant facultatifs. Le transport multiprotocole pouvait fonctionner sans que chaque paire d’équipements adopte cette fonction particulière.

La portée du mécanisme était décisive. La fragmentation RFC 1490 ne traversait pas l’Internet comme une succession de petits datagrammes IP : elle s’arrêtait aux DTE, les équipements raccordés aux extrémités du réseau Frame Relay. L’émetteur encapsulait d’abord le paquet, puis le découpait en trames adaptées au réseau. Le DTE destinataire reconstituait le paquet avant de le remettre au traitement habituel. La taille et l’identité du datagramme IP ne changeaient pas à cause de cette opération.

La RFC 791 décrit une autre fragmentation, à la couche IP : le datagramme porte son identifiant, son décalage et ses indicateurs, puis la destination IP le réassemble. RFC 1490 place au contraire une enveloppe de fragmentation autour du paquet déjà encapsulé et attend la reconstruction à la frontière Frame Relay, avant le traitement du protocole transporté. Les deux procédures découpent des données, mais elles ne désignent ni le même niveau du réseau ni le même récepteur.

Le format de RFC 1490 devait garder l’état d’un message en cours. Chaque fragment portait l’identifiant d’encapsulation, un numéro de séquence sur deux octets, un décalage et un bit marquant le dernier fragment. Le numéro progressait à chaque nouveau message fragmenté et partait d’une valeur aléatoire au démarrage. Le décalage comptait par unités de 32 octets ; le premier fragment commençait à zéro. Ces champs devaient permettre au récepteur d’identifier les pièces, de les replacer et de savoir quand le message était complet.

Le contrat de service complétait le format. Les fragments devaient arriver dans l’ordre, du décalage zéro à la pièce finale. Aucune autre donnée destinée au même circuit ne devait s’intercaler. Chaque extrémité devait pouvoir reconstruire au moins 2 Kio ; 8 Kio était recommandé. Si une pièce manquait ou était altérée, l’équipement supprimait le message entier. La retransmission relevait du protocole supérieur. La procédure ne prévoyait pas de nouvelle tentative fragment par fragment.

La RFC ne définissait pas non plus de temporisateur de réassemblage. Elle invoquait la livraison en ordre exigée du service Frame Relay : le récepteur n’aurait donc pas à décider, par un délai local, qu’une séquence incomplète était périmée. C’est une hypothèse écrite dans la spécification, pas la preuve que chaque transporteur la respectait ou que tous les équipements savaient l’exploiter. La mémoire nécessaire à un message inachevé restait bien réelle ; une pièce perdue supprimait toujours l’ensemble, et la récupération dépendait d’une retransmission de couche supérieure.

Cinq ans plus tard, RFC 2427 dissocie explicitement les résultats. Elle décrit l’encapsulation globale de RFC 1490 comme largement mise en œuvre, y compris dans des textes sectoriels, mais rapporte qu’aucune implémentation interopérable de son algorithme de fragmentation n’existait alors. Elle mentionne des remarques selon lesquelles le mécanisme ne suffisait pas à certaines applications Frame Relay, le supprime et renvoie à FRF.12. Elle ne nomme ni fournisseur, ni trace de paquet, ni défaut précis. L’évidence permet de raconter l’issue, pas d’inventer sa cause.

Deux raccourcis sont donc à éviter. Le premier ferait de l’échec d’une option la preuve que RFC 1490 n’a pas été adoptée : RFC 2427 dit le contraire pour l’encapsulation. Le second déduirait de l’usage répandu de l’encapsulation que chaque option était compatible : la même annexe affirme que l’algorithme de fragmentation ne l’était pas. Une norme contient plusieurs contrats. L’un peut circuler entre produits quand un autre ne devient jamais une base commune d’interopérabilité.

Le fait historique n’est pas que le code l’emporte toujours sur les textes, ni qu’une option sans interopérabilité invalide tout le document. Il est plus précis : une étiquette comme « compatible RFC 1490 » ne répond pas à la question opérationnelle. Quelle fonction ? Quelle taille maximale par circuit ? Les deux DTE connaissent-ils le même format de fragments et les mêmes règles d’ordre ? Savent-ils quand un message est complet ? RFC 2427 documente un résultat mécanisme par mécanisme : l’encapsulation avait son ensemble de compatibilité ; la fragmentation ne l’avait pas.

Le remplacement FRF.12 est inscrit dans cette histoire, sans démontrer son adoption universelle.