Zusammenfassung

  • LLC/SNAP erlaubte mehrere Protokolle auf einem VC, weil jedes PDU eine Typkennung trug. VC-Multiplexing ließ diese allgemeine Kennung weg und reservierte je Protokoll einen eigenen VC.
  • Der geringere PDU-Overhead verlagerte den Typ in PVC-Konfiguration oder SVC-Aushandlung. Erfolgreiche AAL5-Reassemblierung bewies weder die richtige Zuordnung noch Annahme durch höhere Schichten oder Anwendungserfolg.

Headeraufwand gegen Zustandsaufwand

RFC 1483 stellte 1993 zwei Kostenmodelle nebeneinander. LLC-Kapselung setzte IEEE-802.2- und gegebenenfalls SNAP-Felder vor das Nutz-PDU. AA-AA-03, OUI und PID/EtherType identifizierten nicht-ISO-Protokolle; für IP galt 0x0800. Mehrere Protokolle konnten so denselben VC benutzen.

VC-Multiplexing verzichtete auf die allgemeine Typkennung im Payload. Jeder VC transportierte genau einen Protokolltyp. Mehr Protokolle bedeuteten mehr VCs. Der RFC-1483-Datensatz fasst diese Wahl zusammen; technisch verlagerte sie den Typ vom aktuellen Datenobjekt in eine externe Beziehung.

Das konnte Headerverarbeitung und Zellverbrauch senken. Der Empfänger musste den Typ dennoch kennen. Bei einem PVC wurde er an beiden Endpunkten konfiguriert, bei einem SVC während des Verbindungsaufbaus ausgehandelt. Ein Feld verschwand, eine zustandsbehaftete Zuordnung entstand.

Bei gebridgten PDUs bezeichneten OUI und PID zusätzlich das Ursprungsmedium und den FCS-Erhalt. Ein korrekter AAL5-CRC bestätigte deshalb nur die äußere Einheit, nicht die richtige Rekonstruktion des inneren Frames.

Der Fehler konnte eine ganze Verbindung erben

Eine falsche LLC/SNAP-Kennung kann ein einzelnes PDU betreffen. Eine falsche VC-Zuordnung kann jedes formal intakte PDU des Kanals zum falschen Parser schicken. Der Effizienzgewinn veränderte damit auch die Reichweite eines Konfigurationsfehlers.

RFC 1755 konkretisierte die B-LLI-Aushandlung für SVCs. Der rufende Endpunkt bot Kapselungen an, der gerufene wählte eine unterstützte oder beendete den Ruf. Der Informationsdatensatz beschreibt das Dokument als Implementierungsleitfaden für ATM-Signalisierung.

SETUP und CONNECT waren jedoch Kontrollbelege. Sie bewiesen kein späteres PDU, keinen CRC, keine fortbestehende Zuordnung und keinen Anwendungsausgang.

Ein Default blieb eine Regel, keine Messung

RFC 2225 machte LLC/SNAP zum Default für Classical IP und ATMARP, wenn kein anderes Wissen oder Abkommen vorlag. Sein RFC-Editor-Eintrag ordnet dies als stabile Interoperabilitätsbasis ein.

Auch der AAL-Typ eines VC kam bei PVCs aus Administration und bei SVCs aus Rufaufbau, nicht aus jedem Zellheader. AAL5 erhielt Reihenfolge und erkannte Fehler, bot aber keinen zugesicherten Dienst; Wiederholung blieb Aufgabe höherer Schichten.

RFC 2364 verwendete beide Wege für PPP. VC-Typ war durch Provisionierung oder Kontrolle implizit vereinbart, LLC-Typ pro PDU explizit. Der Eintrag zu RFC 2364 zeigt den Punkt-zu-Punkt-Kontext. Selbst PPP-Authentisierung schützte nicht automatisch andere LLC-Flüsse desselben VC.

RFC 2684 behielt die Bilanz und begrenzte die Aussage

RFC 2684 ersetzte RFC 1483 1999, behielt beide Methoden und klärte Implementierungsfragen. LLC benötigte typischerweise weniger VCs, VC-Multiplexing weniger Aufwand pro PDU. Der Datensatz belegt die normative Ablösung, nicht das Verschwinden aller Altgeräte.

Entscheidend war die Grenze: Multiprotokoll-Kapselung war für Routing und Bridging über ATM notwendig, aber im Allgemeinen nicht hinreichend. Typkennung war kein Beweis für Adresse, Weg, Autorität oder Zustellung.

Quellen