Zusammenfassung
- RFC 3524 führte
SRFein, damit mehrere übermidbezeichnete Medienzeilen einen gemeinsamen Ressourcenreservierungsfluss anfordern konnten. - Die Gruppe beschrieb die Zuordnung. Zulassung, Richtlinienprüfung, installierter Klassifizierer- und Schedulerzustand, Refresh und Medienausgabe blieben getrennte Belege.
a=group:SRF 1 2 war eine kompakte Anweisung. Zwei Kennungen konnten etwa Audio und Video benennen; Single Reservation Flow sagte dem entfernten Endgerät, dass beide in einen Reservierungsversuch gehören sollten. Das Gegenüber musste die gewünschte Aufteilung nicht aus Ports oder Codecs erraten.
RFC 3524 trennte jedoch Medienströme und Reservierungsflüsse. Eine Sitzung konnte alle Medien zusammenfassen, jedem Medium einen eigenen Fluss geben oder beides mischen. SRF wählte die Beziehung. Es stellte weder Bandbreite noch Route oder Warteschlange bereit.
Die Normsprache hielt die Grenze fest. Zeilen innerhalb der Gruppe SHOULD demselben Fluss zugeordnet werden; Zeilen außerhalb SHOULD NOT darin landen. Auch eine einzelne Medienzeile durfte eine Gruppe bilden. Das war eine Regel für den nächsten Antrag, keine Aussage über bereits vorhandene Ressourcen.
Das Gruppierungsrahmenwerk machte Referenzen prüfbar. Jedes mid musste innerhalb einer SDP-Sitzung eindeutig sein, und group listete diese Namen unter einer bestimmten Semantik. Eine unbekannte Kennung erzeugte kein Medium. RFC 5888 behielt die Struktur später bei. Da SDP unbekannte Attribute ignorieren lässt, kann ein gültiges Dokument ohne Wirkung ankommen.
SRF war vor allem dann nützlich, wenn die entfernte Partei an der Reservierung beteiligt werden musste. Konnte der SDP-Erzeuger beide Richtungen selbst zuteilen, durfte er lokal entscheiden. Ohne Gruppenzeile konnte der Empfänger des Beispiels zwei getrennte RSVP-Sitzungen aufbauen.
SIP und RSVP waren Beispiele. Andere Signalisierungs- oder Reservierungsmechanismen konnten dieselbe Syntax umsetzen. SRF blieb damit Beschreibung und war nicht die Ausführungsinstanz.
RSVP zeigt die fehlenden Schritte. Ein Resv transportiert einen Flowspec für die gewünschte QoS und einen Filter Spec für die betroffenen Pakete. Jeder Knoten prüft über Admission Control die Kapazität und über Policy Control die Berechtigung. Scheitert eine Prüfung, wird der gewünschte Zustand dort nicht installiert. Erst danach können Klassifizierer und Scheduler eingerichtet werden.
Der Zustand ist Soft State. Path und Resv müssen ihn erneuern. Bei einem Routenwechsel entsteht Zustand auf dem neuen Pfad, während alter Zustand ausläuft. Die SDP-Gruppe kann unverändert bleiben, obwohl die Ressourcenrealität verschwunden ist.
Selbst ResvConf hat laut RFC 2205 keine Garantie. Eine Bestätigung kann vor einem Fehler eintreffen, wenn weitere Anträge oder die Zusammenführung das Ergebnis verändern. Eine vorgeschaltete SRF-Zeile kann daher erst recht kein Leistungsnachweis sein.
RFC 3312 unterschied aktuellen und gewünschten QoS-Status. Diese Trennung wäre überflüssig, wenn das Beschreiben des Ziels den Istzustand erzeugte. SRF beantwortete, welche Medien den Versuch teilen sollten, nicht ob die Vorbedingung in beiden Richtungen erfüllt war.
Der Sicherheitsabschnitt zeigte eine echte Steuerwirkung. Eingefügte SRF-Zeilen konnten ein Endgerät zu zu vielen oder zu wenigen Reservierungsflüssen zwingen. Zu viele verbrauchten Endpunktressourcen, zu wenige verschlechterten die Qualität. Deshalb wurde Integritätsschutz dringend empfohlen, bei SIP mit S/MIME.
Integrität belegt Autor und Unverändertheit der Anweisung. Sie erzeugt keine Kapazität, überstimmt keine Richtlinie, verleiht keine Unterstützung, hält keinen Refresh aufrecht und beweist keine Wiedergabe. Auch die IANA-Registrierung koordiniert nur das Token und beobachtet keine laufende Sitzung.
Die historische Lehre ist eine Belegkette: gültiges SDP, aufgelöste mid, authentisierte Absicht, gewählte Zuordnung, gesendeter Antrag, Zulassung je Knoten, installierter Zustand, Refresh, Klassifizierung, Pakete und wiedergegebenes Medium. Wer alles auf „SRF vorhanden“ reduziert, verwechselt den Plan mit der Kapazität.
Quellen
- https://www.rfc-editor.org/rfc/rfc3524.html
- https://www.rfc-editor.org/rfc/rfc3524.txt
- https://www.rfc-editor.org/info/rfc3524
- https://datatracker.ietf.org/doc/rfc3524/
- https://datatracker.ietf.org/doc/rfc3524/history/
- https://www.rfc-editor.org/errata_search.php?rfc=3524
- https://www.rfc-editor.org/rfc/rfc3388.html
- https://www.rfc-editor.org/rfc/rfc5888.html
- https://www.rfc-editor.org/rfc/rfc2205.html
- https://www.rfc-editor.org/rfc/rfc3261.html
- https://www.rfc-editor.org/rfc/rfc3312.html
- https://www.rfc-editor.org/rfc/rfc3520.html
- https://www.rfc-editor.org/rfc/rfc3521.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.rfc-editor.org/rfc/rfc8843.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
