Zusammenfassung
- RFC 3038 behandelte einen konkreten Widerspruch: Das ATM-VPI/VCI war ein lokales Label, das am nächsten Hop umgeschrieben werden konnte; benachbarte ATM-LSR mussten dieselbe virtuelle Verbindung in LDP dennoch gemeinsam zuordnen.
- Im Inband-Verfahren für Punkt-zu-Punkt-Verbindungen galt PROPOSE noch nicht als Einigung. Erst ein passendes ACK und die anschließende LDP-REQUEST-Nachricht vervollständigten den Drei-Nachrichten-Austausch, bevor das Mapping die VCID führte.
Eine Verbindung, mehrere lokale Namen
Im Januar 2001 sollte die MPLS-Standardfamilie ATM-Switches als Label-Switching-Router nutzbar machen. Die Hardware leitete Zellen bereits anhand von VPI- und VCI-Feldern weiter. Diese Werte bezeichneten jedoch meist nur den jeweiligen Linkabschnitt: Ein Switch konnte sie beim Weiterleiten auf den nächsten Link ersetzen. Für LDP war das VPI/VCI, das ein Nachbar sah, daher nicht zwangsläufig eine stabile Identität der virtuellen Verbindung, die beide koordinieren mussten.
RFC 3038 ergänzte neben dem lokalen Label einen Virtual Connection Identifier, die VCID. Entscheidend war, dass beide Enden derselben VC denselben Wert zuordneten. Die VCID ersetzte nicht die VPI/VCI-Werte im Datenpfad und machte lokale Labels auch nicht netzweit eindeutig. Sie erlaubte benachbarten ATM-LSR, ihre jeweiligen lokalen Ein- oder Ausgangslabels einer gemeinsamen Identität zuzuordnen und diese in LDP-Labelinformationen zu verwenden.
Die Reihenfolge ist wichtig. RFC 3038 setzt eine VC voraus, die bereits per Signalisierung oder Management eingerichtet wurde. Die Benachrichtigung erzeugt den ATM-Kreis nicht; sie gleicht ab, wie zwei Nachbarn ihn erkennen. Erst danach folgen LDP-Request und Mapping. VC-Einrichtung, lokales Label, VCID-Zuordnung, verteiltes Mapping und tatsächlich übertragener Verkehr sind unterschiedliche Sachverhalte. Keiner davon beweist für sich, dass eine Anwendung Daten empfangen hat.
Warum das ACK nicht genügte
Bei einer Inband-Punkt-zu-Punkt-VC wählte der Upstream-Knoten eine VCID und sendete eine VCID PROPOSE-Nachricht mit Nachrichtenkennung über die neu eingerichtete Verbindung. Beide Enden ordneten die VCID ihrem lokalen Label zu. Der Downstream-Knoten antwortete mit einem ACK, das die empfangene VCID und Nachrichtenkennung enthielt. Der Upstream musste beide Werte abgleichen und die Proposal-Nachricht erneut senden, falls das erwartete ACK ausblieb.
Danach schickte der Upstream eine LDP REQUEST mit der Nachrichtenkennung. Der Downstream wertete diese Anfrage als Beleg, dass der Upstream das ACK empfangen hatte. RFC 3038 begründet die drei Nachrichten damit, dass PROPOSE unzuverlässig übertragen wird. Der Downstream konnte wissen, dass er ein ACK gesendet hatte, aber nicht, ob es angekommen war. Bis REQUEST eintraf, sollte er auf der VC alle Pakete außer der VCID PROPOSE verwerfen.
Nach Abschluss des Austauschs konnte das LDP Mapping die VCID im Label-TLV tragen. Damit war eine Kontrollplane-Zuordnung zwischen Nachbarn etabliert. Es war weder eine Erfolgsbestätigung einer Anwendung noch ein Nachweis, dass jeder Switch eines längeren Pfads zugestimmt hatte oder Nutzdaten geflossen waren.
Der Verbindungstyp änderte das Verfahren
RFC 3038 schrieb nicht für jede ATM-Verbindung denselben Ablauf vor. Ein transparenter direkter Punkt-zu-Punkt-Link mit gleichem VPI/VCI an beiden Enden benötigte keine Benachrichtigung. Ein Virtual Path konnte Inband- oder VPID-Benachrichtigung verwenden; unter der engen Bedingung, dass es zum Nachbarn nur einen VP gab, konnte die gemeinsame VCI genügen. Eine PVC verwendete Inband-Benachrichtigung. Bei einer SVC konnte ein ausreichend großes Signalisierungsfeld die VCID tragen; alternativ gab es ein kleineres temporäres Feld oder eine Inband-Nachricht.
Auch die Richtung zählte. Der Upstream-Endpunkt leitete die Benachrichtigung ein. Eine bidirektionale VC benötigte je eine Prozedur pro Richtung, eine unidirektionale nur für die zulässige Richtung. „Dieselbe Verbindung“ war also kein globaler Name, der im gesamten ATM-Netz automatisch galt, sondern eine Beziehung, die zwischen den jeweils relevanten Nachbarn hergestellt werden musste.
Das kleine Feld zeigt den Unterschied zwischen temporärer Korrelation und dauerhafter Zuordnung. Das BLLI-Benutzerspezifikfeld konnte während der Signalisierung vorübergehend eine Verbindung kennzeichnen. Derselbe Wert durfte nicht für eine weitere unvollständige Transaktion mit diesem Nachbarn verwendet werden; nach Abschluss der VCID-Zuordnung wurde das BLLI wieder frei. Im Multipunktfall war BLLI beim Sender eindeutig, nicht zwingend beim Empfänger, der zusätzlich die ATM-Adresse des Senders benötigte. Ein knapper temporärer Token durfte erst nach einer beobachtbaren Zustandsänderung wiederverwendet werden.
RFC 3038 definierte zudem VPID-Benachrichtigung für einen Virtual Path. Daraus und aus der VCI ließ sich eine VCID bilden, ohne jede VC einzeln auszuhandeln. Multipunktverfahren erschienen als künftige Nutzung; das damalige LDP unterstützte laut Dokument kein Multicast. Bei einem Switch ohne VC-Merge konnte das Hinzufügen eines Leafs eine vorübergehende Aufteilung eines aktiven LSP erfordern, um die Inband-Nachricht zu senden, mit möglichen Folgen für Leistung und QoS. Das sind beschriebene Designgrenzen, keine Messungen aus dem Betrieb.
Eine klare historische Abgrenzung
RFC 3033 erschien im selben Monat und definierte typisierte Kennungen für Sitzungen und Ressourcen in der ATM-Signalisierung. Das war ein anderer Gegenstand als die VCID von RFC 3038, die lokale Labels benachbarter LDP-Knoten nach Einrichtung der VC zusammenführte. Die FEC-Definitionen von RFC 3036 und die allgemeine MPLS-Architektur liegen ebenfalls auf anderen Ebenen. Wer all dies wegen des Wortes „Kennung“ zusammenfasst, vermischt Aufbau, Paketklassifikation, Hop-Weiterleitung und Zustellung.
Der RFC Editor führt RFC 3038 heute als Proposed Standard und vermerkt RFC 7274 als Aktualisierung. RFC 7274 behandelt Zuweisung und Rücknahme von MPLS-Special-Purpose-Labels und die ältere Bezeichnung „reserved label“; damit ist die VCID-Verhandlung nicht aufgehoben. Keines der Dokumente nennt eine eingesetzte Implementierung, zählt die Nutzung oder berichtet Interoperabilitätstests. Die belastbare historische Aussage bleibt enger: Wenn ein ATM-Label hoplokal sein konnte, brauchte die MPLS-Kontrollplane eine gemeinsame Identität unter Nachbarn; die Spezifikation machte diese Einigung durch einen expliziten Austausch beobachtbar.
Quellen
- RFC-3038-Eintrag
- RFC 3038, VCID-Benachrichtigung über ATM für LDP
- RFC 3031, MPLS-Architektur
- RFC 3032, MPLS-Label-Stack-Kodierung
- RFC 3033, ATM-Signalisierungskennungen
- RFC 3034, LDP über Frame Relay
- RFC 3035, MPLS mit LDP und ATM-VC-Switching
- RFC 3036, LDP-Spezifikation
- RFC 3037, Anwendbarkeit von LDP
- RFC 5036, überarbeitete LDP-Spezifikation
- RFC 7274, Zuweisung und Rücknahme spezieller MPLS-Labels
- RFC 2684, ATM-Kapselung
- RFC 2119, Anforderungsbegriffe
- Heng Lu, Vorrang des ausgeführten Codes
- Heng Lu, minimale Anfangsspezifikation und freiwillige Einführung
- Heng Lu, über Realitätsebenen
Heng Lus Essays sind ausdrücklich nur analytische Bezugspunkte; Lu hat RFC 3038 weder verfasst noch gebilligt.
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
