Zusammenfassung

  • RFC 1294 ist ein Standards-Track-RFC vom Januar 1992 für Multiprotokoll-Kapselung von geroutetem und gebridgetem Verkehr über Frame Relay. Bei mehreren Verfahren müssen die Endpunkte vorher wissen, welcher virtuelle Kanal welches Verfahren trägt; diese Kapselung darf nur auf ausdrücklich dafür konfigurierten VCs verwendet werden.
  • NLPID und SNAP sagen dem Empfänger, wie eine bestimmte PDU zu interpretieren ist. Sie konfigurieren keinen VC und beweisen weder Einigung, Annahme, Bridging, Routing, Zustellung noch ein Dienstresultat.

Der RFC 1294 — Multiprotocol Interconnect over Frame Relay ist ein Gegenmittel gegen eine bequeme Verkürzung: Ein lesbarer Header wirkt wie ein fertiger Betriebszustand. Der RFC verlangt zwar, dass der Frame genügend Information zur Identifikation des enthaltenen Protokolls oder der Kapselung trägt. Doch seine Einleitung verlangt ebenso, dass die Zuordnung von Kapselungsmethode zu virtuellem Kanal vorher bekannt ist. Die Kennung im Paket beantwortet eine Auslegungsfrage; die Konfiguration beantwortet eine Zulassungsfrage.

Alle Protokolle werden nach RFC 1294 in einen Q.922-Annex-A-Frame gekapselt. NLPID kann das nachfolgende Protokoll direkt bezeichnen. Fehlt einem gerouteten Protokoll ein eigener NLPID, folgen auf NLPID 0x80 OUI 00-00-00 und EtherType. Für ein IP-Datagramm kann NLPID 0xCC verwendet werden. Stationen müssen für geroutete Pakete sowohl die NLPID- als auch die SNAP-Kapselung akzeptieren.

Akzeptanz beider Formen heißt: Der Empfänger muss beide Grammatiken verstehen. Es heißt nicht: Jede erkannte Form ist auf jedem VC zulässig. Genau dort setzt die explizite VC-Konfiguration an. Ein Protokollfeld kann eine Auswertung auslösen, ohne die vorherige Zuordnung des Verfahrens geschaffen zu haben.

Ein DLCI war ein lokaler Bezug, keine vollständige Beziehung

Eine Frame-Relay-Gruppe kann vollständig oder nur teilweise vermascht sein. Jeder virtuelle Kanal wird an jeder Schnittstelle durch einen Data Link Connection Identifier gekennzeichnet. RFC 1294 betont, dass DLCIs in den meisten Fällen streng lokale Bedeutung haben. Das macht den Wert an der beobachteten Schnittstelle brauchbar, nicht aber zu einem weltweit tragbaren Namen des Kanals.

Der RFC erläutert später, dass das Netz den DLCI beim Durchlauf verändern kann. Was die sendende Station in den Header schreibt, kann beim Empfänger als ein anderer, aus dessen lokaler Sicht passender Wert ankommen. Ein erfasster DLCI belegt deshalb eine lokale Beobachtung von Frame, Interface und Zeitpunkt. Er belegt nicht die Identität eines Partners, die VC-Zuweisung, die vereinbarte Kapselung oder eine erfolgreiche Übertragung.

Diese Einschränkung ist keine pedantische Namensfrage. Ein einzelner Wert überlebt oft in einem Ticket, während die Konfiguration und der Zeitpunkt verloren gehen. Dann wird aus einem lokalen Label nachträglich eine scheinbare Berechtigung. Der RFC gibt dem DLCI diese Autorität nicht.

Der Header wählte einen Parser, nicht die Kanalpolitik

Der normale Steuerwert ist UI 0x03, soweit nichts anderes ausgehandelt wurde. Füllbytes zur Ausrichtung müssen null sein. NLPID 0x00 ist unter dieser Kapselung ungültig, weil er nicht von Padding unterschieden werden kann und hier keine sinnvolle Bedeutung besitzt. Schon diese Regel zeigt: Eine Kennung funktioniert nur innerhalb klarer Strukturgrenzen.

Für gebridgete Frames kündigt NLPID 0x80 SNAP an. OUI 00-80-C2 bezeichnet den 802.1-Kontext; der PID unterscheidet die MAC-Headerform und ob die ursprüngliche FCS erhalten bleibt. Das sind präzise Hinweise für die Interpretation. Sie beglaubigen keinen ursprünglichen LAN-Frame, garantieren kein Bridging, bestätigen keine gemeinsame Endpunktpolitik und belegen keine Ankunft in einem LAN.

„Der Header bezeichnete gebridgetes Ethernet“ ist eine Aussage über Format. „Ethernet wurde gebridget“ ist eine Aussage über Verarbeitung. „Der VC war für diese Kapselung konfiguriert“ ist eine Aussage über vorherige Politik. Der RFC legt nicht nahe, diese Sätze mit derselben Headerbeobachtung zu beweisen.

XID hatte eine bestimmte, kleine Reichweite

Beim Initialisieren eines Frame-Relay-Kanals kann Exchange Identification, XID, optional N201, T200 und K aushandeln. Ohne XID müssen diese Werte durch gegenseitige statische Konfiguration der DLC-Endpunkte festgelegt werden oder die Q.922-Vorgaben erhalten. Eine XID-fähige Station muss auf einen XID-Frame antworten; ist der entfernte maximale Frame kleiner, muss sie ihre auf diesem DLC verwendete Größe vor der Antwort verringern.

Das ist ein echtes Verfahren für benannte Parameter. Es ersetzt weder die vorgängige Zuweisung einer Kapselung zum VC noch schafft es Beweise für spätere PDU-Annahme, Routing oder Dienstverfügbarkeit. Gerade die benannte Reichweite schützt vor der falschen Annahme, irgendein Handshake habe den ganzen Kanal umfassend legitimiert.

Ein belastbarer Befund braucht mehrere Aufzeichnungen

Eine reproduzierbare Untersuchung trennt lokales Interface und DLCI, die zeitlich gültige VC-Kapselungszuweisung, XID oder statische Parameter, rohe Q.922-Bytes, NLPID/SNAP-Dekodierung, Empfängerhandlung und einen späteren Nachweis eines Ergebnisses. Ein Capture kann die enthaltenen Bytes beweisen. Ein Policy-Datensatz kann die verzeichnete Erlaubnis beweisen. Keiner erzeugt ohne Weiteres den Nachweis der nächsten Stufe.

RFC 1294 machte gemeinsame Transportinfrastruktur lesbar, ohne Lesbarkeit zur Steuerungsgewalt zu machen. Der Frame kann den Parser anleiten. Der virtuelle Kanal muss vorher einem Verfahren zugeordnet sein. Was nach der Interpretation geschieht, bleibt ein eigenes Ereignis mit eigener Evidenz.

Quellen und Evidenzgrenzen

Quelle ist RFC 1294 — Multiprotocol Interconnect over Frame Relay. Er belegt Status und Datum, explizite Konfiguration, lokale DLCI-Bedeutung, Q.922/NLPID/SNAP, Routing/Bridging und den begrenzten XID-Mechanismus. Er belegt keinen aktuellen VC, Carrier, Partner, wirksame Konfiguration, Schutz, Forwarding, Zustellung oder Dienstresultat.