Résumé

  • Avec LLC/SNAP, plusieurs protocoles partageaient un même circuit virtuel ATM parce que chaque PDU portait son identifiant. Avec le multiplexage par VC, un circuit ne transportait qu’un seul protocole et tenait lieu d’étiquette.
  • Le second choix économisait des octets, mais faisait de la configuration du PVC ou de la négociation du SVC une condition de lecture. Une enveloppe AAL5 intacte ne prouvait ni la bonne association, ni l’acceptation supérieure, ni le résultat applicatif.

Payer en circuits ou payer dans chaque paquet

Le compromis économique apparaît avant même les formats. Si la création de nombreux circuits virtuels était rapide et peu coûteuse, RFC 1483 envisageait qu’un protocole dispose de son propre VC. Si les circuits permanents étaient rares ou facturés en nombre, un seul VC pouvait porter plusieurs protocoles, mais chaque PDU devait alors dire ce qu’il contenait.

L’encapsulation LLC ajoutait un en-tête IEEE 802.2, éventuellement suivi de SNAP. Pour un protocole routé non ISO, AA-AA-03, l’OUI et le PID/EtherType formaient le reçu de type. IP utilisait l’OUI nul et 0x0800. Le destinataire pouvait choisir son parseur à partir des octets présents.

Le multiplexage par VC supprimait cette étiquette générale. Le protocole était identifié implicitement par le circuit ; plusieurs protocoles exigeaient plusieurs VC. La notice du RFC 1483 résume cette opposition, mais son effet opérationnel est plus profond : l’information quitte le PDU pour entrer dans la relation entre un identifiant de circuit et une configuration.

Le même partage valait pour les trames pontées. LLC/SNAP indiquait le média d’origine et la présence éventuelle du FCS. Un CPCS-PDU correctement réassemblé et validé par CRC ne disait donc pas, à lui seul, comment reconstruire la trame interne.

L’en-tête court avait une mémoire longue

Le multiplexage par VC réduisait le traitement et l’occupation par PDU. Mais il imposait un accord préalable aux deux extrémités. Pour un PVC, cet accord venait de la configuration manuelle. Pour un SVC, il venait de la signalisation lors de l’établissement de l’appel.

Une erreur LLC/SNAP pouvait rester attachée à un PDU. Une mauvaise association de VC pouvait orienter tous les PDU pourtant valides de ce circuit vers le mauvais protocole. L’optimisation transformait donc une erreur de champ en erreur d’état partagé.

RFC 1755 rendit cet état négociable avec l’élément B-LLI. L’appelant proposait les encapsulations par ordre de préférence ; l’appelé en sélectionnait une compatible ou libérait l’appel. Sa notice le présente comme un guide d’interopérabilité de la signalisation IP sur ATM.

Cette négociation constituait un reçu de contrôle, pas un reçu de livraison. SETUP, CONNECT, attribution de ressources et choix d’encapsulation pouvaient réussir sans qu’un futur PDU arrive, soit correctement interprété ou accomplisse une opération applicative.

Le choix par défaut ne transformait pas la règle en observation

RFC 2225 retint LLC/SNAP comme format par défaut pour Classical IP et ATMARP lorsqu’aucune autre connaissance ou entente n’existait. Cette base, identifiée dans la notice du RFC 2225, facilitait l’interopérabilité sans prétendre décrire chaque circuit en service.

Le document rappelait aussi que le type AAL d’un VC était configuré pour un PVC ou communiqué pendant l’établissement d’un SVC, et non répété dans l’en-tête de chaque cellule. AAL5 conservait l’ordre et détectait certaines erreurs, mais fournissait un service non assuré : la retransmission restait aux couches supérieures.

RFC 2364 reprit les deux méthodes pour PPP. Il formula clairement la différence entre le type implicitement convenu par provisionnement ou contrôle et le type explicitement indiqué dans chaque PDU. La notice du RFC 2364 situe ce mécanisme dans une liaison point à point pouvant utiliser contrôle, authentification et compression. Même alors, l’authentification d’une session PPP ne sécurisait pas les autres flux LLC du même VC.

Le remplacement conserva la frontière

RFC 2684 remplaça RFC 1483 en 1999, en corrigeant des ambiguïtés découvertes par les implémenteurs. LLC tendait à réduire le nombre de VC ; le multiplexage par VC tendait à réduire la charge par PDU. La notice du RFC 2684 enregistre la succession normative, non la disparition instantanée des équipements antérieurs.

Le texte ajoutait une limite décisive : l’encapsulation multiprotocole était nécessaire mais généralement insuffisante au routage et au pontage sur ATM. Identifier une charge utile ne prouvait ni la résolution d’adresse, ni le chemin, ni l’autorité, ni la réception finale.

Sources