Zusammenfassung

  • RFC 3034 bezeichnete eine Folge von Frame-Relay-LSRs, die DLCIs austauschten, ohne MPLS-TTL zu senken, als Nicht-TTL-Segment; die ausgelassenen Hops mussten an einer Grenze gesammelt abgerechnet werden.
  • Ein per LDP verbreiteter Hop Count konnte die Subtraktion am Unicast-Eingang speisen, blieb aber eine Control-Plane-Behauptung und war weder Paketbeobachtung noch Zustellnachweis.

Der Switch scheiterte nicht an seiner eigentlichen Aufgabe. Er las den eingehenden DLCI, suchte den Ausgang, schrieb einen neuen DLCI und leitete den Frame weiter. Was seiner Hardware typischerweise fehlte, war die einzelne Subtraktion, die Router für jedes Paket ausführten: TTL minus eins. Als ein solcher Switch zum MPLS Label Switching Router wurde, musste jemand diese ausgelassene Operation übernehmen.

RFC 3034 erschien im Januar 2001 als Proposed Standard. Das Dokument erfand keine Hardwarefähigkeit, sondern definierte eine Folge dieser Geräte als „non-TTL segment“. Statt jeden Kernknoten zahlen zu lassen, belastete es eine Grenze mit der gesamten Segmentlänge.

Der wirksame Labelwert steckte im DLCI

Auf einer Frame-Relay-Verbindung lag das aktuelle MPLS-Label im DLCI-Feld des Link-Headers. Weitere Labels sowie die übrigen Felder des obersten Stack-Eintrags blieben in der generischen MPLS-Kapselung. Ein FR-LSR im Kern schlug daher den DLCI nach, ersetzte ihn durch den Ausgangs-DLCI und sendete den Frame.

Die logische Darstellung war geteilt. Der Wert, der die Weiterleitung auslöste, befand sich auf der Sicherungsschicht; TTL und andere relevante Felder blieben im Label Stack gültig. An einer Kapselungsgrenze musste ein LSR den logischen Stack dekodieren, die MPLS-Operation ausführen und ihn für den nächsten Link neu kodieren. Dasselbe LSP konnte auf benachbarten Links unterschiedlich aussehen.

Wurde am Ausgang das letzte Label entfernt, enthielt der Stack keine ausdrückliche Kennung des folgenden Netzschichtprotokolls. Diese musste aus der Labelzuordnung hervorgehen. Die Zuordnung steuerte damit eine begrenzte Interpretation und Weiterleitung; sie authentifizierte weder den Absender noch den Pfad und bewies auch nicht die tatsächliche Durchquerung oder Zustellung.

Unsichtbare Hops verbrauchten weiterhin Reichweite

MPLS-TTL sollte Schleifen unterdrücken und die Reichweite eines Pakets begrenzen. Zählten fünf Frame-Relay-Switches dauerhaft als null, käme ein Paket mit mehr Restlebensdauer heraus als nach fünf vergleichbaren Routern. Korrekte DLCI-Wechsel allein bewahrten die Ende-zu-Ende-Eigenschaft nicht.

RFC 3034 schrieb die Rechnung als Ausgangs-TTL = Eingangs-TTL - d. Der Wert d hing von Eingangs-, Weiterleitungs- und Ausgangskapselung ab. Ein Frame-Relay-Kernwechsel auf gleicher Ebene verwendete null, weil die Belastung an anderer Stelle erfolgte. Generische MPLS-Weiterleitung verwendete gewöhnlich eins. Der Eintritt in ein Nicht-TTL-Segment konnte die vollständig verbreitete Hopzahl verwenden.

Für Unicast wurde eine sinnvolle Segmentlänge zum Eingang gemeldet und vor dem Eintritt abgezogen. Für Multicast wanderte sie zum Ausgang, der dort die Grenzabrechnung vornahm. Der Ort der Belastung änderte sich; die Hops selbst durften nicht aus dem Reichweitenbudget verschwinden.

Der Eingang konnte ein Paket vor dem Verfall abweisen

Die Vorauszahlung erlaubte eine Entscheidung vor dem ersten DLCI-Wechsel. Zeigte die Rechnung, dass eine Unicast-TTL vor dem Segmentausgang ablaufen würde, durfte der Eingang das Paket nicht label-switched in das Nicht-TTL-Segment senden.

Stattdessen sollte er nach den Label-Stack-Regeln versuchen, einen ICMP-Fehler zurückzugeben, oder das Paket ohne Label und mit einer zur IP-Weiterleitung passenden TTL weiterreichen. Bei einer Eingangs-TTL von eins blieb nur der Fehlerpfad.

Ein Versuch ist kein Ergebnis. Ein erzeugter ICMP-Fehler belegt nicht seinen Empfang beim Absender. Eine unlabeled Weiterleitung belegt keine spätere Zustellung. Der Grenzbeleg reicht nur bis zur Entscheidung und zu den Werten, aus denen sie folgte.

Hop Count war verteilter Zustand, keine Pfadmessung

LDP konnte einer Labelzuordnung ein Hop-Count-Objekt beifügen. Erhielt ein FR-LSR von downstream einen bekannten Wert, erhöhte er ihn vor der Meldung upstream um eins. Unbekannt blieb unbekannt. Hätte die Erhöhung das Maximum überschritten, durfte die Zuordnung nicht weitergegeben werden; stattdessen war ein Fehler zu senden.

Bei Ordered Control wartete der Knoten auf eine Downstream-Zuordnung, bevor er upstream antwortete, und konnte gleich die erhöhte Zahl liefern. Bei Independent Control durfte er früher mit unbekanntem Hop Count werben und den korrekten Wert nachreichen. Lieferte LDP keinen Wert oder markierte ihn als unbekannt, setzte die in RFC 3034 beschriebene Rechnung standardmäßig eins ein.

Dieser Standardwert maß keinen Ein-Hop-Pfad. Er definierte Verhalten bei fehlendem Wissen. Auch ein bekannter Wert wurde aus Routingzustand und Verteilungsnachrichten zusammengesetzt. Er bewies weder den Betrieb jedes Switches noch den Weg eines bestimmten Pakets oder dessen Ankunft am Ausgang.

Eine neue Route entzog der alten Rechnung die Grundlage

Eine bereits nach upstream gemeldete Zuordnung fror die Zahl nicht ein. Ein abgeschlossener Downstream-Aufbau oder ein neu gewählter Next Hop konnte sie ändern. Der FR-LSR musste den neuen Wert erhöhen und Richtung Eingang weiterreichen. Überschritt die neue Zahl das Maximum, waren die betroffenen Labels für die FEC upstream zurückzuziehen, damit Schleifenerkennung nicht auf einer unmöglichen Zahl beruhte.

Auch Fehler entwerteten gespeicherten Zustand. Konnte eine Downstream-Anforderung nicht erfüllt werden, sollte eine vorläufige Zuordnung für die Upstream-Anforderung zerstört und zurückgezogen werden. Beim Verlust einer LDP-Sitzung mussten die über diese Verbindung gelernten Bindings verworfen werden. Liberal Retention erlaubte Wiederverwendung nur unter den passenden Routen- und Hop-Count-Bedingungen des RFC.

Eine Zeile in der Label Information Base war daher kein Nachweis für einen betriebsbereiten Pfad. Herkunftssitzung, Downstream-Abhängigkeit, aktuelle Route und bis zum Eingang gelangte Zählung gehörten zu ihrer Gültigkeit.

Anpassung an Hardware vereinigte nicht die Beweisebenen

Ein als LSR eingesetzter Frame-Relay-Switch musste Labels zuweisen und pflegen sowie am Netzschicht-Routing als Peer teilnehmen. Gleichzeitig konnten klassische Frame-Relay-Steuerung und Label-Switching-Steuerung unabhängig auf demselben Gerät und denselben Schnittstellen laufen. Sie teilten nur begrenzte Dinge wie die Aufteilung des DLCI-Raums; das kombinierte Betriebsmodell blieb außerhalb des Geltungsbereichs.

Der Kompromiss war eng gefasst: Routing bestimmte die Abhängigkeit, LDP meldete eine Länge, der Eingang rechnete, der Kern tauschte DLCIs. Paketbeobachtung und Ausgangs-TTL waren eigene Belege. RFC 3034 verlegte Arbeit wegen einer Siliziumgrenze. Es verlegte nicht die Wahrheit über den Weg in die Control-Plane-Zahl.

Quellen

Lu Heng hat RFC 3034 und die verwandten Standards weder verfasst noch unterstützt. Seine Essays dienen hier als ausdrücklich offengelegte analytische Perspektiven.