Zusammenfassung

  • RFC 3181 verglich die Preemption Priority eines neuen Datenstroms mit der Defending Priority bereits zugelassener Reservierungen. Nach dem Eintritt verlor der erste Wert seine Bedeutung; der eigene Verteidigungswert trat künftigen Ankünften entgegen.
  • Zusammengeführte Multicast-Reservierungen brauchten eine eigene Rangentscheidung. Die Bindung an den höchsten beigetragenen QoS verringerte Verzerrung; das bloße Maximum begünstigte Trittbrettfahrer; die Ablehnung heterogener Zusammenführung konnte einem unvereinbaren Empfänger ein Vetorecht geben.
  • Ein Policy-Element, eine lokale Entscheidung oder ein Verdrängungsfehler bewies weder End-to-End-Reservierung noch vollzogene Verkehrssteuerung, Paketbehandlung oder Anwendungskontinuität.

Knappheit machte die Reihenfolge verhandelbar

RFC 3181 erschien im Oktober 2001 als Standards Track, löste RFC 2751 ab und korrigierte eine Typzuweisung in RSVP-Policy-Daten. Er definierte das Signaled Preemption Priority Policy Element für Verfahren wie RSVP und COPS. Der Status belegt einen Standardisierungspfad, nicht die Einführung in einem bestimmten Netz.

Wirksam wurde der Mechanismus erst bei Überbuchung. Reine Kapazitätskontrolle ließ Anfragen bis zur Erschöpfung ein und bevorzugte damit die ersten. Policy-basierte Kontrolle konnte eine Rangfolge verwenden: Ein Knoten durfte einen niedrigen Neuankömmling ablehnen oder eine ältere, niedrige Reservierung für eine spätere höhere Anfrage verdrängen.

Dadurch entstand keine Kapazität. Der Mangel wechselte den Träger. Zulassung des Gewinners und Verlust des Verlierers waren dieselbe Entscheidung. Eine Statistik nur erfolgreicher Eintritte würde Umverteilung als Ausbau ausgeben.

Das Element sollte einfach, zustandslos und leicht genug für einen Local Decision Point sein. Zustandslosigkeit betraf seine Interpretation. Die Betriebsgeschichte blieb nötig: Wer war anwesend, wer kam hinzu, wie viel Ressource war frei und wer wurde entfernt?

Eintritt und Aufenthalt hatten verschiedene Ränge

Die Preemption Priority gehörte der neuen Anfrage und wurde mit den Defending Priorities bestehender Reservierungen verglichen. Größere Werte bedeuteten innerhalb der geltenden Policy einen höheren Rang.

Nach der Zulassung wurde dieser Eintrittswert für den Strom bedeutungslos. Nun verteidigte der zweite Wert gegen spätere Ankünfte. Eine Reservierung besaß also einen Eintrittsanspruch und einen Überlebensanspruch. Ein einzelnes Feld „Priorität“ verlor den zeitlichen Geltungsbereich.

Der Eintrittswert musste kleiner oder gleich dem Verteidigungswert sein. Ein großer Abstand konnte stabilisieren: Der Strom verdrängte andere nur schwer, war aber nach erfolgreichem Eintritt gegen mittlere Bewerber gut geschützt. So ließ sich Abhängigkeit von Reihenfolge gegen ständige Rotation abwägen.

Der Schutz war nicht dauerhaft. Ein höherer künftiger Bewerber konnte gewinnen, Kapazität und lokale Zuordnung konnten sich ändern. Die Zahlen waren relative Policy-Werte und keine universelle soziale oder geschäftliche Hierarchie.

„Zum Zeitpunkt A zugelassen“ ist ein vergangenes Ereignis. „Zum Zeitpunkt B geschützt“ ist ein gegenwärtiger Vergleich. Die alte Quittung sah weder neue Konkurrenz noch neue Kapazität.

Regel, Entscheidung und Vollzug lagen nicht in einer Hand

Ein Policy Decision Point reduzierte Regeln auf ein Kriterium. Ein Local Decision Point interpretierte, leitete weiter oder führte Elemente zusammen. Ein Policy Enforcement Point verband die Entscheidung mit Verkehrs- und Kapazitätskontrolle.

Das war eine Beweiskette. Die Autorität erzeugte Rang, der lokale Punkt verwendete die kodierte Strategie, der Vollzug änderte lokalen Zustand, RSVP transportierte, COPS konnte Entscheidungen auslagern. Kein Glied sah allein den gesamten Pfad oder das Anwendungsergebnis.

RFC 2750 beschrieb den RSVP-Policy-Container; RFC 2748 und 2749 lieferten COPS-Kontext. Schnittstellen garantieren keine Folge. Ein integres Objekt kann eine falsche Regel, veraltete Zuordnung oder uneinheitlich vollzogene Entscheidung tragen.

Die Sicherheit stützte sich auf die Integrität des umgebenden Policy Data und einen vertrauenswürdigen beziehungsweise einzelnen Bereich. Die Hülle konnte Manipulation erkennen. Sie bescheinigte weder Fairness und Aktualität noch den Dienst nach dem Vollzug.

Beim Zusammenführen konnte Rang ausgeliehen werden

RSVP-Reservierungen konnten verschmelzen. Das Beispiel kombinierte hohe Qualität mit niedrigem Rang und niedrige Qualität mit hohem Rang. Das Ergebnis brauchte die hohe Qualität; sein Rang war unklar.

Der hohe Rang ließ die teure Anfrage von der kleinen mitfahren. Der niedrige Rang entzog dem berechtigt hohen Teilnehmer Schutz. Trittbrettfahren und Denial of Service waren Gegenbilder: Unverdiente Macht für einen nimmt einem anderen die verdiente Chance.

Die empfohlene Strategie ließ nur Elemente teilnehmen, deren Ströme zum zusammengeführten QoS beitrugen, und wählte unter ihnen den höchsten Rang. Wer die Ressourcenkosten bestimmte, bestimmte damit eher auch die Priorität. Das minderte Verzerrung, beseitigte sie nicht vollständig.

Die zweite Strategie nahm schlicht das Maximum aller Elemente. Sie war einfach und nicht empfohlen, weil eine kleine hochrangige Beteiligung die ganze teure Reservierung aufwerten konnte.

Die dritte Strategie erzwang bei heterogenen QoS-Werten einen Fehler. Sie passte, wenn Homogenität im gesamten Baum koordiniert und durchgesetzt wurde. Ohne diese Voraussetzung konnte ein unvereinbarer Empfänger alle übrigen blockieren.

Eine neutrale Verdichtung gab es nicht. Für Elemente verschiedener Strategien war kein Verfahren bekannt, das ohne für andere Knoten wichtigen Informationsverlust zusammenführte. Integritätsgeschützte Objekte sollten zudem nicht verändert werden. Teilnehmer, Strategie und Schutzhülle gehörten zum Sinn des Werts.

Der Fehler meldete den Wettbewerb, nicht den Dienst

PREEMPTION zeigte die Verdrängung einer zugelassenen Reservierung. HETEROGENEOUS zeigte eine unvereinbare Zusammenführung. Beim ersten Fehler ging eine Kopie des gewinnenden Elements zum Entscheidungspunkt des Verlierers zurück. Mit beiden Rängen konnte er eine Wiederzulassung mit höherem Wert versuchen.

Die Nachricht bewies nicht, dass die verlierende Anwendung sie empfing, Sendung einstellte, Ressourcen freigab oder sauber weiterarbeitete. Ebenso wenig belegte sie die Installation des Gewinners an jedem Hop. Lokale Zulassung und vollständiger Pfad waren verschiedene Behauptungen.

Wiederzulassung konnte schwingen. Priorität, eine verdrängende Reservierung und RSVP-Blockadezustand konnten Entfernung, Rückkehr und erneute Entfernung erzeugen. Jeder Eintritt als Erfolg würde Instabilität belohnen. Aufenthaltszeit und sichtbare Unterbrechung waren ehrlicher.

Auch der Heterogenitätsfehler war begrenzt. Er sagte, dass eine Kombination der lokalen FLOWSPEC-Definition widersprach, nicht dass kein anderer Pfad, keine geringere Qualität und keine Alternative existierte.

Registrierung und Nachfolger waren kein Einsatznachweis

RFC 3181 koordinierte den Typwert. Das heutige IANA-Register bestätigt die Zuweisung, aber nicht Erkennung, Erzeugung, Vollzug oder Nutzen.

Spätere RSVP-TE-Texte und RFC 6401 geben historischen Kontext. Sie beweisen keine RFC-3181-Implementierung und dürfen ihre Felder nicht rückwirkend in 2001 einfügen.

Auch Standards Track ist keine Bestandsaufnahme. Die Quellen nennen keinen aktuellen Betreiber, Datenstrom, Notfalldienst, Kapazitätsgewinn, Zulassungswert oder Anwendungserfolg.

Eine verantwortliche Spur hielt den Verlierer fest

Ein Journal beginnt mit Identität, QoS, Policy-Ursprung, Integritätskontext und beiden Rängen. Es speichert interpretierende und zusammenführende Rollen, Strategie, Kapazität, Konkurrenten und jede Aktion.

Bei Zusammenführung bleiben QoS- und Rangbeiträge je Empfänger erhalten. Bei Verdrängung verbindet es gewinnende Ankunft, verlorene Reservierung, Fehler, Entfernung aus der Verkehrssteuerung und Rückkehrversuche. Der jüngste Zustand überschreibt keine Episode.

Pfadbestätigung, Paketbeobachtung und Anwendung folgen als eigene Belege. Rang führt eine Wahl unter Knappheit; er erzeugt keine Ressource und zertifiziert keinen Dienst.

Die zwei Werte bewahren eine klare Lehre: Wer die Tür öffnet, garantiert nicht, dass sie offen bleibt. Belastbare Evidenz nennt Zeitpunkt, Konkurrent, Entscheider, Vollzieher und Folge.

Quellen und Grenzen

Status, Prioritäten, Rollen, Strategien, Fehler, Registrierung und Sicherheit stehen im Text von RFC 3181, im RFC-Editor-Datensatz, in der HTML-Fassung, in der IETF-Historie und in der Errata-Abfrage. Der Versionsvergleich ist auf den abgelösten Text von RFC 2751 und dessen Datensatz begrenzt.

Benachbarte Schnittstellen stammen aus RSVP, den RSVP-Policy-Erweiterungen, COPS und COPS für RSVP. Späterer Kontext kommt aus RSVP-TE, der RSVP-Zulassungspriorität und dem IANA-RSVP-Register.

Die Trennung von Rang, Vollzug und beobachtetem Ergebnis ist von Lu Hengs Essays über Vorrang laufenden Codes, Realitätsebenen und minimale Anfangsspezifikation geprägt. Die siebzehn Quellen wurden am 2. Oktober 2026 nach Schanghai-Zeit eingefroren.

Sie belegen Spezifikation und Kontext, nicht Einsatz oder Wirkung. Keine aktuelle Implementierung, kein Anbieter, Betreiber, Strom, Vorfall, Angriff, Gewinn, Paketverhalten oder Dienstergebnis wird identifiziert. Die Werte sind relativ, nicht universal. Die Belegkette ist Sofia Rens redaktionelle Analyse, keine Aussage des Autors, IETF, IANA oder Lu Hengs.