Zusammenfassung

  • RFC 2213 bildete reservierbare Interface-Ressourcen und aktive Flows in einer SNMPv2-MIB ab, einschließlich Selektoren, Rate, Burst, Queue, Policing, Discard und RowStatus.
  • Jede Aussage blieb begrenzt: Die Flow-Nummer war nur ein SNMP-Index, Owner eine Prozessklasse, Zähler begannen bei der Installation, und Queue-Bedeutungen waren implementierungsspezifisch.

Ein MIB-Designer kann ein Objekt als read-create definieren. Ein konkretes Gerät kann es gemäß RFC 2213 dennoch nur lesbar implementieren. Wer aus dem Schema direkt auf eine verfügbare Schreibmacht schließt, verwechselt den Vertrag des Modells mit der Fähigkeit einer Instanz.

Diese Vorsicht zog sich durch das gesamte Dokument. Fred Baker, John Krawczyk und Arun Sastry veröffentlichten die MIB im September 1997. Sie machte Integrated Services administrierbar, ohne eine lokale Zeile zum Beweis für Signalisierung, Autorisierung und Ergebnis zu erheben.

Interface und Flow als getrennte Sichten

Die Interface-Tabelle zeigte zugewiesene und maximal reservierbare Bandbreite, Buffer, Flow-Anzahl, zusätzlichen Propagation Delay und Status. Die Flow-Tabelle beschrieb reservierte Flows auf den Interfaces eines Systems.

Eine Zeile verband Session-Typ, Installationsprozess, Quell- und Zielselektoren, Protokoll, Ports, Interface, Rate, Burst, Weight, Queue, Paketgrößen, Best-Effort- und Policing-Zähler, Discard-Policy, QoS-Service, Klassifizierungsreihenfolge und RowStatus. Sie war eine reichhaltige lokale Projektion, kein End-to-End-Protokoll.

Für neue Zeilen koordinierte intSrvFlowNewIndex konkurrierende Manager mit TestAndIncr. Ein Kandidat wurde gelesen, im SET zurückgeschrieben und nach inconsistentValue erneut beschafft. intSrvFlowNumber hieß zwar SessionNumber, diente laut Definition aber ausschließlich der SNMP-Indexierung und hatte keine Beziehung zu einem Protokollwert. Tabellenadresse war keine RSVP-Identität.

Owner sagte, welcher Prozess installierte

intSrvFlowOwner kannte other, rsvp und management. Das Feld beschrieb den Prozess, der den Flow in die Queue-Policy-Datenbank eintrug. Es nannte keinen Menschen, keine Organisation, kein Credential und keine Genehmigung.

Auch rsvp bewies weder den ursprünglichen Resv noch fortgesetzte Refreshes. RFC 2205 trennte Routing, RSVP und Traffic Control. Classifier, Admission Control und Scheduler hatten eigene Aufgaben. Die MIB-Zeile zeigte einen lokalen Zustand über dieser Kette, nicht die Kette selbst.

Adressen, Masken, Protokoll, Ports und Interface beschrieben die lokale Auswahl. Dass einige Felder bei active nicht änderbar waren, schützte Konsistenz. Es belegte weder einen Pakettreffer noch einen kompatiblen Zustand auf weiteren Hops.

Queue und Counter brauchten zusätzliche Metadaten

Die reservierte Rate stammte für Controlled-Load aus dem Tspec und für Guaranteed Service aus dem Rspec. Burst war ein erwarteter Grenzwert; zusätzliches Pacing blieb optional. MinTU und MaxTU regelten Policing, nicht beobachtete Paketgrößen.

Weight und Queue waren ausdrücklich implementation-specific. Gleiche Zahlen konnten auf zwei Routern verschiedene Verfahren bezeichnen. Sie bewiesen weder Scheduler-Algorithmus noch Wartezeit oder tatsächliche Behandlung.

intSrvFlowPoliced begann mit der Flow-Installation. intSrvFlowBestEffort zählte zurückgestufte Pakete. Nach Löschen und Neuerstellen begann eine neue Epoche. Ein steigender Wert belegte eine lokale Zähleraktualisierung unter Agent-Regeln, nicht Antragsteller, Vollständigkeit oder Zustellung. Die Discard-Einstellung entschied Verlust oder Best Effort, doch eine Policy war noch kein beobachtetes Ereignis.

Active blieb ein Managementzustand

intSrvFlowStatus war für aktive Flows active und konnte statische Classifier-Information installieren, löschen oder autorisieren. RowStatus sagte, dass die Zeile dem managed device zur Verfügung stand. Es war kein Audit-Protokoll ihrer Entstehung.

Die Security Considerations zogen die schärfste Grenze: Ein SNMP SET konnte eine RSVP- oder Integrated-Services-Reservierung nach anderen Regeln erzeugen als eine RSVP-Verhandlung. Ein erfolgreiches SET war daher keine Zustimmung des Empfängers. Active bewies ebenso wenig Soft State, Policy Control, Classifier Hits, Scheduler-Ausführung oder path-weiten Dienst.

Selbst eine RSVP-Bestätigung war in RFC 2205 nur ein Hinweis hoher Wahrscheinlichkeit und keine Garantie bis zu den Sendern. Die lokale RFC-2213-Zeile war ein noch engerer Beleg.

Quellen