Zusammenfassung

  • RFC 2214 stellte Backlog C, Delay D, Slack und RowStatus je Schnittstelle als vier read-create-Objekte bereit.
  • Die Werte beschrieben Implementierungsfehler und eine lokale Ressourcenentscheidung. Sie belegten weder den Weg eines konkreten Flows noch den Fortbestand seiner Reservierung oder eine gemessene Verzögerung.

Vier sauber benannte Felder wirken schnell wie ein Zertifikat. Backlog trägt die Einheit Byte, Delay die Einheit Mikrosekunde, Slack eine verfügbare Marge und Status einen Gültigkeitszustand. In RFC 2214 waren alle vier Spalten außerdem read-create. Ein Managementsystem konnte sie nicht nur betrachten, sondern je nach Implementierung auch anlegen.

Die Spezifikation machte daraus dennoch keinen Leistungsbeweis. Fred Baker, John Krawczyk und Arun Sastry veröffentlichten RFC 2214 im September 1997 als Guaranteed-Service-Erweiterung der Integrated Services MIB. Die quantitative Dienstdefinition lag in RFC 2212. Die MIB legte offen, wie eine konkrete Umsetzung vom idealisierten Fluidserver abwich und wie ein Netzelement Verzögerungsspielraum gegen geringeren Ressourcenverbrauch tauschen konnte.

C war kein aktueller Füllstand

intSrvGuaranteedIfBacklog stellte C in Byte dar. Der Text bezeichnete den Wert als Rückstand, der aus den Eigenheiten einer Implementierung gegenüber einem strengen bitweisen Dienst entsteht. Für paketisiertes Weighted Fair Queueing wurde die maximale Paketgröße als Beispiel genannt.

In RFC 2212 war C der ratenabhängige Fehlerterm. In der Verzögerungsformel wurde er durch die reservierte Rate R geteilt. Damit ließen sich Effekte erfassen, deren Zeitkosten von der Übertragungsrate abhängen, etwa die Serialisierung eines Datagramms.

Die Einheit Byte durfte daher nicht mit einer Live-Messung verwechselt werden. C sagte nicht, wie viele Byte beim SNMP-Abruf gerade warteten. Der Wert sagte, welcher ratenabhängige Implementierungsfehler in das Modell eingehen sollte. Eine Queue-Messung und ein mathematischer Fehlerterm können dieselbe Einheit besitzen und trotzdem verschiedene Tatsachen belegen.

D war kein Paket-Zeitstempel

intSrvGuaranteedIfDelay trug D in Mikrosekunden. D war der ratenunabhängige Fehler pro Element: die schlimmste lokale Laufzeitvariation, die C nicht abbildete. RFC 2214 nannte den Weg vom Eingangsinterface über den Prozessor zum Ausgang und den schlimmsten Kollisionsfall bei Ethernet.

Der Wert konnte beim Start oder durch Konfiguration gesetzt werden. Er war keine Beobachtung eines konkreten Pakets. Für eine Ende-zu-Ende-Grenze mussten lokale Werte entlang des wirklichen Pfads zu Ctot und Dtot zusammengesetzt werden. RFC 2212 überließ die Sammlung einem Setup-, Routing- oder Managementmechanismus.

Auch die Garantie selbst galt nur unter Bedingungen: Der Verkehr musste seinem Profil entsprechen, Komponenten durften nicht ausfallen und die Route durfte sich während des Flows nicht ändern. Begrenzt wurde die maximale Queueing-Verzögerung, nicht der Mittel- oder Mindestwert; die Pfadlatenz kam hinzu. Eine einzelne Interface-Zeile bestätigte keine dieser Voraussetzungen.

Slack speicherte eine Entscheidung

Der Slack-Wert brachte eine zeitliche Pflicht mit sich. Verwendete ein Netzelement Si, um die für Flow i reservierten Ressourcen zu reduzieren, musste es Si speichern. Bei späteren Reservation Refreshes desselben Flows war genau dieser Wert ohne Neuberechnung wiederzuverwenden. Das sollte den Reservierungsprozess konsistent halten.

Im Beispiel galt S = Dreq - (b/r + Ctot/r + Dtot). Ein Zwischenelement durfte s <= S verbrauchen. Ein RCSD-Scheduler konnte seine lokale Verzögerungsgrenze erhöhen; ein WFQ-Scheduler konnte nach den Transformationsregeln die reservierte Rate senken. Zeitlicher Spielraum wurde in geringere lokale Ressourcenbindung umgewandelt, ohne die vorgesehene Gesamtgrenze zu erhöhen.

Slack war damit weder freie Bandbreite noch gemessene Latenz. Es war ein Budget und die gespeicherte Entscheidung über dessen Verwendung. Würde bei jedem Refresh neu gerechnet, könnte dieselbe Anfrage zwischen unterschiedlichen lokalen Zusagen schwanken. Das gespeicherte Si verhinderte dieses Abdriften.

Die Tabelle von RFC 2214 war jedoch nur über ifIndex indiziert. Eine vollständige Flow-Identität, PATH/RESV-Verläufe und die Refresh-Kontinuität gehörten nicht in diese Zeile. Die allgemeine Flow-Tabelle stand in RFC 2213, das empfängerorientierte Soft State von RSVP in RFC 2205. Ein Nachweis musste diese Ebenen verbinden.

Schreibbarkeit belegte Kontrolle, nicht Wirkung

Die Security Considerations zogen eine deutliche Grenze: Ein SNMP SET konnte eine RSVP- oder Integrated-Services-Reservierung nach anderen Regeln erzeugen als eine über RSVP ausgehandelte Reservierung.

Ein erfolgreicher SET war folglich keine Zustimmung des Empfängers. Er bewies weder fortlaufende Refreshes noch die richtige Admission-Entscheidung, tatsächliche Klassifikation oder Ausführung durch den Scheduler.

Auch RowStatus änderte das nicht. RFC 2214 verwendete den Status für Interfaces, die für Guaranteed Service konfiguriert waren. In der allgemeinen Konvention bedeutet active, dass eine konzeptionelle Zeile dem verwalteten Gerät zur Verfügung steht. Es ist ein lokaler Zeilenzustand, kein Urteil über den Pfad.

RFC 2214 machte drei verborgene Größen sichtbar: C erfasste ratenabhängige Abweichung, D ratenunabhängige Zeitabweichung, Slack eine Ressourcenentscheidung, die Refreshes überdauern musste. Diese Sichtbarkeit verbesserte das Management. Vertrauenswürdig blieb sie nur, solange die Zeile nicht mit dem gelieferten Ergebnis verwechselt wurde.

Quellen