Zusammenfassung

  • RFC 3020 definierte vier Aktivierungsklassen: mindestens ein aktiver Link, alle Links, eine konfigurierte Schwelle oder eine herstellerspezifische Regel.
  • Das logische up bestätigte das Bestehen dieses Tests; es bestätigte weder volle Kapazität noch fehlerfreie Reihenfolge, Frame-Zustellung oder Anwendungserfolg.

Drei von vier Leitungen waren betriebsbereit. Das logische Interface blieb rot.

Unter Aktivierungsklasse B war genau das vorgeschrieben: Alle Mitglieder mussten up sein. Mit denselben drei Leitungen wäre ein Bundle unter Klasse A längst grün gewesen. Unter Klasse C hing das Ergebnis von mfrBundleThreshold ab. Der physische Zustand allein bestimmte die Anzeige nicht.

RFC 3020 erschien im Dezember 2000 und definierte die MIB für UNI/NNI Multilink Frame Relay nach FRF.16. Mehrere physische Links wurden zu einem logischen Bundle zusammengefasst, das gegenüber Q.922 wie ein einziges Interface wirkte und die Reihenfolge verteilter Frames wiederherstellen sollte.

Der bleibende historische Wert liegt in der Trennung von Komponentenzustand und Aggregatentscheidung. Ein Aggregate-Status ist eine Auswertung über eine Menge von Mitgliedern. Ohne Regel und Nenner ist sein Wahrheitsgehalt nicht rekonstruierbar.

Zwei Indexräume beschrieben dasselbe logische Objekt

Jeder Bundle-Link erschien mit eigenem ifIndex in der Interface MIB. Auch das Bundle erhielt einen ifIndex. Die MFR-spezifische Tabelle verwendete dagegen mfrBundleIndex.

Der Manager wählte beim Anlegen den MFR-Index, der Agent vergab den allgemeinen Interface-Index. Mapping-Tabellen verbanden beide Richtungen. Unterschiedliche Nummern konnten also dasselbe Bundle bezeichnen; sie waren keine unabhängigen Existenzbelege.

Mit mfrBundleRowStatus=createAndGo legte ein Manager die Bundle-Zeile an, worauf der Agent das allgemeine Interface erzeugte. createAndWait war optional. Eine Link-Zeile verwendete den ifIndex des physischen Interfaces und musste über mfrBundleLinkConfigBundleIndex auf ein vorhandenes Bundle zeigen. Ohne gültige Zuordnung blieb sie notReady.

Die Konfigurationszeile belegte die Existenz des verwalteten Objekts. Sie belegte noch keinen Protokollzustand, keine Aktivierung und keine Übertragung.

Vier Regeln erzeugten denselben Ausgabewert

Klasse A verlangte mindestens einen operativ aktiven Link. Klasse B verlangte alle. Klasse C verlangte die in mfrBundleThreshold festgelegte Zahl. Klasse D war benutzerdefiniert und implementierungsspezifisch. Standardwert war Klasse A.

In Klasse C schaltete das Bundle beim Erreichen der Schwelle auf aktiv und beim Unterschreiten auf inaktiv. Wo die Schwelle nicht galt, wurde -1 gemeldet. Für Klasse D hing ihre Verwendung von der Implementierung ab.

Auch die Bundle-Traps folgten diesem Prädikat. LinkUp begleitete den Wechsel des ifOperStatus, sobald genügend Mitglieder up waren; linkDown folgte, sobald es zu wenige waren.

Bei vier konfigurierten Links konnte Klasse A mit einem Mitglied up sein. Klasse B blieb mit drei down. Klasse C mit Schwelle zwei änderte beim zweiten Mitglied den binären Zustand; das dritte und vierte Mitglied änderten nur noch Kapazität. Klasse D erforderte Code- und Versionswissen.

Wer nur den Trap speicherte, verlor die Erklärung. Aktivierungsklasse, Schwelle, konfigurierte und aktive Mitglieder gehörten zum selben Beleg.

Das grüne Bit war kein Kapazitätsmesser

RFC 3020 führte konfigurierte Links, aktive Links und verfügbare Bundle-Bandbreite getrennt. Damit war ein Bundle-up gerade nicht gleichbedeutend mit vollständiger Mitgliederzahl.

Die gemeldete Bandbreite war ebenfalls kein gemessener Anwendungsdurchsatz. Sie enthielt keine Last, kein Zeitfenster, keine Staugeschichte, keine Wiederholungen und keine Empfangsbestätigung.

Weitere Objekte beschrieben Fragmentierung, maximale Fragmentgröße, Sequenznummernlänge, maximale Laufzeitdifferenz und Round-Trip-Delay pro Link. Ein Aggregat musste nicht nur Mitglieder aktivieren, sondern unterschiedlich ankommende Frames wieder ordnen.

Minimale Erreichbarkeit und zugesagte Kapazität waren daher zwei verschiedene Betriebsziele. Eine Anzeige durfte nicht beide Verträge stillschweigend zusammenlegen.

Ein Resequencing-Ereignis konnte mehrere Verluste enthalten

mfrBundleResequencingErrors zählte Fehlerereignisse. RFC 3020 erklärte: Treffen 56, 59 und 60 ein und gelten 57 und 58 als verloren, steigt der Zähler um eins.

Ein Delta von eins war deshalb kein Beweis für genau einen verlorenen Frame. Ein unveränderter Zähler bewies auch keine vollständige Zustellung, solange Reset, Wrap, Polling-Lücke, Agent-Neustart und nicht erfasste Fehler offenblieben.

Pro Link gab es Zähler für ungültige Kontrollframes, Timerablauf, vermutete Schleifen, unerwartete Sequenzen und Bundle-Namenskonflikte. Der Linkzustand entstammte der FRF.16-Zustandsmaschine und war mehr als ein elektrisches Signal.

Der Mismatch-Trap stellte konfigurierte Nah- und zuvor oder aktuell gemeldete Fernnamen gegenüber. Konfigurierte Werte konnten laut RFC automatisch erzeugt worden sein. Der Trap belegte einen Widerspruch, nicht dessen Urheber.

So konnte ein weiterhin aktives Bundle klare Integritätswarnungen enthalten. Für den Erfolg beim Empfänger brauchte es trotzdem eine eigene Beobachtung.

Eine Policy-Änderung konnte wie Reparatur aussehen

Aktivierungsklasse, Schwelle, Timer, Fragmentierung und Sequenzgröße waren als read-create deklariert. Manager konnten außerdem Zeilen anlegen, ändern, löschen und Links Bundles zuordnen.

Die maximale Zugriffsangabe garantierte nicht, dass jedes Produkt Schreibzugriff anbot. Die Compliance-Regeln erlaubten für mehrere Objekte mindestens read-only, verlangten aber die Meldung des tatsächlich genutzten Werts. Schema, Implementierung und Berechtigung blieben getrennt.

War Schreiben möglich, konnte eine Senkung der Schwelle von drei auf zwei den Zustand ändern, ohne eine Leitung zu reparieren. Das neue up war relativ zur neuen Policy korrekt. Ein Bericht über „Wiederherstellung“ wäre dennoch irreführend.

Die Sicherheitsbetrachtung warnte vor ungeschützten SET-Operationen. SNMPv1 regelte selbst in einem per IPsec geschützten Netz nicht, welcher Principal welche Objekte lesen, ändern, anlegen oder löschen durfte. Empfohlen wurden USM und VACM von SNMPv3; die richtige Autorisierung blieb Betreiberpflicht.

Authentisierung identifizierte den Ändernden. Autorisierung erlaubte den Eingriff. Beides bewies nicht, dass die neue Schwelle den Servicevertrag erfüllte.

Standardstatus war kein Einsatznachweis

RFC 3020 wurde als Proposed Standard veröffentlicht. RFC 9141 aktualisierte später lediglich Verweise auf den eingestellten IETF-FTP-Dienst. Die Aktivierungssemantik blieb unverändert.

Die Quellen belegen die Spezifikation, nicht eine konkrete Implementierung, Verbreitung, Störung, Verfügbarkeit oder Kundenzustellung. Solche Behauptungen werden hier nicht erhoben.

Lu Hengs Reality Layers trennt Zeile, Policy, Mitgliedszustand, Aggregate-Interface, Integritätszähler und Empfängergebnis. Running-Code Primacy ist für Klasse D entscheidend. Minimum Initial Specification erklärt, weshalb eine begrenzte MIB nützlich sein konnte, ohne End-to-End-Nachweis zu versprechen.

Diese Perspektiven sind offengelegt. Lu Heng war weder Autor noch Befürworter von RFC 3020.

Vollständig lautete die Aussage: Unter dieser Regel, über diese Mitglieder und in dieser Konfigurationsepoche war die Mindestbedingung erfüllt. Alles Weitere verlangte eigene Belege.

Quellen