Zusammenfassung
- RFC 3472 goss GMPLS in CR-LDP-REQUEST, MAPPING und TLVs; die Upstream-Richtung konnte nutzbar sein, bevor das Downstream-MAPPING zurückkam.
- Eine weitergeleitete REQUEST, ein gültiges Upstream Label oder erste Pakete in einer Richtung waren Teilbelege, keine Bestätigung des vollständigen bidirektionalen Dienstes.
„Bidirektional“ klingt nach einem Objekt mit einem Fertigstellungszeitpunkt. RFC 3472 beschrieb zwei Richtungen, die zu verschiedenen Zeiten Wirklichkeit werden konnten.
Das im Januar 2003 auf dem Standards Track veröffentlichte Dokument übertrug die allgemeinen Funktionen aus RFC 3471 in CR-LDP-Nachrichten und TLVs. Anforderung, Label, Waveband, Vorschlag, Menge, Schutz, Verwaltungsstatus und Schnittstellenidentität erhielten konkrete Formen. RFC 3473 tat dasselbe für RSVP-TE.
Eine REQUEST für einen bidirektionalen LSP enthielt ein Upstream Label. Es musste beim Absenden bereits zum Weiterleiten gültig sein. Jeder Empfänger prüfte die Akzeptanz. Bevor ein Zwischenknoten die REQUEST weitergab, musste er ein ausgehendes Upstream Label zuteilen und den internen Datenpfad zwischen seinen lokalen Segmenten herstellen.
Am Terminator war diese Richtung deshalb schon verwendbar. Er durfte sofort Verkehr zum Initiator senden. Die Gegenrichtung hing weiterhin von Generalized Labels ab, die in MAPPING-Nachrichten zurückliefen und an jedem Hop angenommen und installiert werden mussten.
Upstream-Verkehr bei unvollständigem Downstream-MAPPING war somit ein zulässiger Zwischenzustand. Eine eingetroffene bidirektionale REQUEST bewies weder beide Richtungen noch optische Kontinuität oder einen erfolgreichen Anwendungsdialog.
Auch die Generalized Label Request verteilte unterschiedliche Prüfungen. Der Ingress setzte Codierung und G-PID; Switching Type konnte sich je Hop ändern. Jeder Knoten prüfte Eingang, eigene Fähigkeit und Ausgang oder Tunnel. Lokale Politik entschied über Forwarding Adjacencies. Weiterleitung bedeutete nicht dieselbe Prüfung überall.
G-PID wurde gewöhnlich am Egress geprüft, mit PSC/PHP-Ausnahme. Frühere Fehlerfreiheit war keine endgültige Zulassung der Nutzlast.
Suggested Label blieb ein Vorschlag. Fehler wurden ignoriert; ein anderes Downstream-Label erzwang Umkonfiguration oder Ablehnung. Der Ingress sollte vor Rückkehr des passenden Labels keine Daten senden. Frühe Hardwarevorbereitung war keine Zuteilungsmacht.
Label Sets beschrieben Zulässigkeit statt Bestand. Einzelwerte und Bereiche konnten ein- oder ausgeschlossen werden; fehlende TLVs bedeuteten, dass alle akzeptabel waren, nicht frei. Jeder Knoten schnitt die Menge mit real verfügbaren Ressourcen. Eine leere Schnittmenge beendete die Anfrage.
Physische Wellenlängen konnten auf Links verschiedene logische Werte besitzen. Knoten mussten übersetzen oder Optionen verwerfen. Konvertierende Knoten konnten das Set entfernen, sodass die letzte Nachricht frühere Einschränkungen nicht vollständig bewahrte.
Bei gespiegelten Wavebands wurden Start- und Endlabel getauscht, in beiden Richtungen. Gleiche logische Breite belegte keine gleiche physische Zuordnung.
Explicit Label Control band einen Label ER-Hop an die vorherige Adresse oder IF_ID. Falsche Reihenfolge und Richtung führten zu Fehlern; wie der Head-End die Daten gewann, blieb außerhalb des Dokuments.
Bei getrenntem Steuer- und Datenkanal bezeichnete IF_ID den Datenkanal und kam im MAPPING zurück. Ausfall der Out-of-Fiber-Signalisierung sollte bestehende optische Verbindungen nicht stören. Wiederhergestellte Steuerung attestierte umgekehrt keinen korrekten alten Cross-Connect.
CR-LDP besaß nicht die schnelle RSVP-Fehlermeldung. RELEASE und WITHDRAW liefen vom Fehler weg und gaben Ressourcen frei. Entfernung machte beide Labels ungültig; späterer Verkehr wäre ein veralteter Hardwarezustand.
RFC 3468 dokumentierte später die IETF-Entscheidung, CR-LDP-Standardisierung zugunsten von RSVP-TE einzustellen. Das erklärt die institutionelle Richtung, nicht eine sofortige Entfernung aller Implementierungen.
Heng Lus Running-Code-Prinzip trennt Nachricht und Wirkung. Minimale Spezifikation lässt lokale Politik lokal. Realitätsebenen halten Zulassung, Zuteilung, interne Verbindung, MAPPING, Richtungsverkehr und Anwendung auseinander.
Eine vollständige Quittung bewahrt REQUEST, Hop-Entscheidung und -Zuteilung, Terminatorannahme, ersten Upstream-Verkehr, jedes Downstream-MAPPING, Beobachtung beider Richtungen und Entfernung. Erst dann wird „bidirektional“ von einer Anforderungsabsicht zur Diensteigenschaft.
Quellen
- RFC 3472
- RFC 3472 als Text
- IETF-Datatracker-Eintrag
- IETF-Datatracker-Historie
- Errata-Suche zu RFC 3472
- RFC 3036: LDP
- RFC 3212: CR-LDP
- RFC 3471: GMPLS-Signalisierungsfunktionen
- RFC 3473: GMPLS-Erweiterungen für RSVP-TE
- RFC 3468: MPLS-Signalisierungsentscheidung
- RFC 3945: GMPLS-Architektur
- RFC 4201: Link-Bündelung
- RFC 4202: GMPLS-Routinganforderungen
- RFC 4204: Link Management Protocol
- RFC 4328: G.709-Signalisierung
- Heng Lu: Primat des laufenden Codes
- Heng Lu: Minimale Anfangsspezifikation
- Heng Lu: Realitätsebenen
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
