Résumé

  • Chaque extrémité choisissait une référence de 16 bits que l’autre utiliserait pour retrouver la connexion de transport ; cette référence ne se confondait pas avec la connexion réseau.
  • Le multiplexage faisait porter plusieurs connexions de transport par une seule connexion réseau, tandis que la classe 4 pouvait répartir une connexion de transport sur plusieurs porteurs.
  • La séparation restait conditionnelle : qualité du service réseau, fonctions communes au porteur, classe négociée et procédure de reprise déterminaient la continuité réelle.

Dans la RFC 892, l’abréviation TC ne désigne pas une manière plus précise d’écrire NC. La Transport Connection relie deux utilisateurs du service de transport. La Network Connection relie les entités de transport par le service inférieur. Les TPDU empruntent la seconde pour faire vivre la première.

Avant toute utilisation, une TC devait être affectée à une NC, ou à plusieurs si la fonction de splitting s’appliquait. L’entité locale pouvait réutiliser un porteur adéquat ou en ouvrir un nouveau. L’affectation répondait donc à « par où ? », pas à elle seule à « quel état de transport ? ».

Il faut aussi respecter la nature du document. La RFC 892 reproduisait une spécification ISO à titre informatif et déclarait ne pas établir une norme pour l’ARPA Internet. La RFC 905 la remplaça avec un texte ISO DP 8073 plus récent, sous la même réserve. Sa présence dans la série RFC n’était pas une adoption implicite de l’architecture OSI par l’Internet.

Deux nombres locaux construisaient une référence commune

L’établissement commençait par un Connection Request TPDU, ou CR, puis un Connection Confirm, ou CC. L’initiateur choisissait une source reference. Le répondant choisissait la sienne. Chacun annonçait ainsi à son partenaire le nombre à employer comme destination reference.

Ces références de 16 bits ne pouvaient être ni nulles, ni actives, ni encore gelées après une ancienne connexion. Elles n’étaient pas des identités universelles. Leur sens dépendait de la table locale qui associait une valeur à un état de TC.

La RFC soulignait le caractère symétrique du mécanisme : aucune désignation maître/esclave n’était nécessaire, et la collision de deux appels ne dépendait pas d’un distributeur central de références. Elle expliquait surtout que la TC pouvait ainsi être identifiée indépendamment de la NC.

« Indépendamment » ne signifiait pas « sans preuve de contexte ». Un TPDU devait arriver sur une affectation reconnue, dans une phase valable et avec la bonne référence. Le nombre ne prouvait ni l’identité juridique du pair, ni une autorisation, ni l’achèvement de l’application.

Le CR exprimait une préférence, le CC rendait la sélection visible

La RFC 892 définissait cinq classes. La classe 0 était simple ; la classe 1 ajoutait la reprise après erreur signalée ; la classe 2 apportait le multiplexage ; la classe 3 combinait reprise et multiplexage ; la classe 4 détectait et corrigeait aussi pertes, duplications et désordres du service inférieur.

L’initiateur proposait une classe préférée et, sauf lorsqu’il préférait la classe 0, des classes alternatives. Il pouvait commencer en supposant que son premier choix serait accepté. Cette hypothèse n’avait pas l’autorité d’une confirmation. Le CC du répondant transportait la selected class, et l’initiateur devait adapter ses fonctions si le choix autorisé différait.

La taille maximale des TPDU suivait une négociation distincte. Le répondant pouvait accepter la valeur proposée ou en retenir une plus petite dans l’ensemble permis. Les options proposées devenaient elles aussi des options sélectionnées. Une NC établie, un CR bien formé, une préférence et un contrat de transport confirmé étaient quatre états.

Le service inférieur participait au choix sans posséder la TC. La RFC classait les réseaux selon leurs erreurs résiduelles et leurs défaillances signalées. Besoin de l’utilisateur, coût et qualité disponible entraient dans la décision. Une NC accessible pouvait rester impropre si sa qualité était insuffisante ou si ses fonctions pervasive entraient en conflit avec la nouvelle classe.

Le partage économisait le porteur mais créait une dépendance commune

Avec le multiplexage, plusieurs TC utilisaient simultanément une NC. La destination reference portée par chaque TPDU indiquait l’état de transport destinataire. Le coût de la NC était partagé ; les conversations n’étaient pas fusionnées.

Certaines fonctions étaient toutefois pervasive. Dès que la première TC les employait sur une NC, toutes les TC utilisant cette NC pendant sa durée de vie devaient les employer. Le porteur ne devenait pas l’identité de la conversation, mais il constituait une surface de contrainte commune.

Le splitting and recombining réalisait la relation inverse. Une TC pouvait utiliser plusieurs NC pour la résilience, le débit ou un autre motif. Le tableau des classes réservait cette fonction à la classe 4. Il serait donc faux de décrire tout transport ISO comme multipath ; la bonne conclusion est que le protocole savait représenter un état de transport au-dessus d’un ensemble de porteurs.

La réaffectation ajoutait une continuité conditionnelle. Lorsqu’une NC disparaissait, les classes de reprise qui invoquaient ce mécanisme pouvaient affecter la TC à une autre NC puis se resynchroniser. Le pair reconnaissait la nouvelle affectation grâce à un TPDU valable, aux adresses réseau compatibles avec les mêmes entités et aux références existantes.

La classe 0 ferme la limite. Sa TC n’avait pas de libération de transport indépendante : sa durée de vie était directement corrélée à celle de la NC. La séparation des couches n’était pas une promesse uniforme ; elle était une capacité précisément attribuée.

TCP devint ensuite un autre service porteur

La RFC 983 proposa en 1986 de présenter l’interface ISO TSAP tout en s’appuyant intérieurement sur TCP/IP. Les couches ISO session, présentation et application pouvaient alors ignorer le changement inférieur. Le document refusait cependant d’en faire un plan complet de transition.

La RFC 1006 remplaça cette proposition par la version 3, normalisant la classe 0 sur TCP. TCP fournissait un flux d’octets fiable, mais les TPDU exigeaient des objets délimités. L’enveloppe TPKT, munie d’une longueur, rétablissait la frontière. Elle ne garantissait ni identité, ni intégrité cryptographique.

Dans cette variante, l’ouverture TCP fournissait la connexion inférieure et sa fermeture signalait la déconnexion. La liberté de la RFC 892 se réduisait donc au modèle de classe 0. L’interface de transport pouvait néanmoins survivre au remplacement du service réseau original par TCP.

La RFC 2126 révisa plus tard le modèle pour TCP sur IPv4 ou IPv6 et décrivit les classes 0 et 2. Elle conserva la version TPKT afin de ne pas briser les déploiements RFC 1006. Elle précisa aussi que le port TCP 102 était réservé sans être obligatoire pour toutes les connexions conformes.

Le registre IANA des noms de service et des ports conserve iso-tsap sur 102. Cette ligne atteste une coordination numérique, pas l’existence d’un logiciel, une classe sélectionnée, une référence vivante ou une application réussie.

Sources et limites

Le récit repose sur les RFC 892, 905, 983, 1006 et 2126 ainsi que sur le registre IANA. Il établit des mécanismes, des statuts documentaires et un passage vers TCP. Il ne démontre ni déploiement actuel, ni adoption générale d’OSI, ni filiation directe vers QUIC ou SCTP, ni support universel du splitting, ni authentification du pair, ni comportement d’un produit nommé.