Zusammenfassung

  • RFC 3429 weist den reservierten MPLS-Wert 14 als OAM Alert Label aus, damit sich OAM-Pakete der Nutzerebene erkennen lassen. Die Zuweisung ersetzt nicht die von ITU-T Y.1711 definierten Funktionen.
  • Im beschriebenen PHP-Fall entfernt der vorletzte LSR das gewöhnliche oberste Label, lässt OAM-Label und Nutzlast aber bis zu einem MPLS-Endknoten mit OAM-Unterstützung intakt. Ein Ziel ohne Labelverarbeitung ist ein anderer Fall, den Y.1711 damals nicht abdeckte.
  • Die TTSI im Paket hilft, den initiierenden Ingress-LSR zu identifizieren. Sie beweist weder einen fehlerfreien LSP noch die Zustellung von Kundendaten oder die Bearbeitung eines Alarms.

Der Implicit-Null-Wert 3 wird im Kontrollprotokoll verteilt, erscheint jedoch nie auf dem Draht. Er weist den vorletzten LSR an, das oberste Label zu entfernen statt es zu ersetzen. Dieses Verfahren, Penultimate-Hop-Popping (PHP), entlastet einen MPLS-Ausgang, der keine zwei Label-Suchen mit Leitungsrate schafft. Für OAM muss nach dem Pop dennoch erkennbar bleiben, dass das verbleibende Paket keine gewöhnliche Nutzlast ist.

RFC 3429 beantwortet diese Frage durch eine einzelne Nummer: den Wert 14 aus dem reservierten MPLS-Labelbereich von RFC 3032. Er wird als OAM Alert Label verwendet. Das Label klassifiziert ein OAM-Paket auf der MPLS-Ebene. Es definiert weder allein dessen gesamte Nutzlast noch verpflichtet es jeden Router, die darin bezeichnete Funktion zu unterstützen.

Ein Paket, mehrere Zuständigkeiten

Die Protokollgeschichte ist eine Aufteilung von Zuständigkeiten. Die ITU-T-Empfehlung Y.1711 beschreibt MPLS-OAM-Funktionen und ihre Pakete. RFC 3031 liefert die MPLS-Architektur samt PHP. RFC 3429 weist den Paketmarker zu, mit dem ein kompatibler Endknoten OAM von normalem Verkehr unterscheiden kann. Keine dieser Ebenen ist für sich ein Nachweis, dass ein Dienst funktioniert.

Im ersten PHP-Fall bleibt das Ziel ein MPLS-LSR mit Kontroll- und Datenebene. Es fordert PHP an, weil es zwei Label-Suchen nicht mit Leitungsrate ausführen kann. Der vorletzte LSR entfernt das oberste, gewöhnliche Weiterleitungslabel und reicht OAM Alert Label samt Nutzlast unverändert weiter. Unterstützt der Ausgang MPLS OAM, erkennt er das Label 14 an der Spitze der verbleibenden Labelstruktur und behandelt das Paket als Wartungsverkehr.

Die TTSI (Trail Termination Source Identifier) innerhalb der Nutzlast nennt den Ingress-LSR, der das Paket erzeugt hat. Damit bleibt eine Herkunftsangabe erhalten, obwohl das äußere Label verschwindet. Sie ist aber kein Wegprotokoll: Aus der TTSI folgt nicht, dass jeder Hop korrekt weitergeleitet hat, der Rückweg funktioniert oder eine entfernte Anwendung Kundendaten empfangen hat. Selbst die Erkennung des OAM-Labels sagt noch nichts darüber aus, ob ein bestimmtes CV-, FDI-, BDI- oder anderes Y.1711-Ergebnis erfolgreich war.

Zwei PHP-Anfragen, zwei Endpunkte

Der zweite Fall ist ein Ziel ohne MPLS-Label-Suche oder -Verarbeitung, das gelabelte Pakete überhaupt nicht erkennt. Auch dieses Ziel kann Implicit Null und PHP anfordern. Daraus entsteht aber keine OAM-Fähigkeit. RFC 3429 sagt ausdrücklich, dass die damaligen Y.1711-Funktionen nur auf den ersten Fall anwendbar waren; der zweite blieb weiterer Untersuchung vorbehalten. Auch Carrier-Supporting-Carrier-Szenarien wurden vertagt.

RFC 3429 hält fest, dass ein End-LSR ohne MPLS-OAM-Unterstützung das eintreffende OAM-Paket verwirft. Ein fehlender Eintrag am Ausgang beweist deshalb weder einen gesunden Pfad noch, dass PHP den Pfad unterbrochen hat. RFC 3031 erklärt die Vorsicht: Ein unbekanntes Label einfach zu entfernen und den Rest als IP weiterzuleiten kann eine Bedeutung verlieren, die sich aus dem IP-Header nicht rekonstruieren lässt. Verwerfen mag sicherer sein als eine frei erfundene Interpretation, lässt jedoch eine Beobachtungslücke zurück.

Registrierung ist keine Implementierungsliste

Das aktuelle IANA-Register der MPLS-Labelwerte führt den Wert 14 weiterhin als OAM Alert Label mit Verweis auf RFC 3429. Das hält die Bedeutung über verschiedene Spezifikationen hinweg stabil. Es zeigt nicht, welche heutigen LSR Y.1711 implementieren, auf welchen LSPs PHP aktiv ist oder wie ein konkretes Gerät verworfene OAM-Pakete protokolliert.

RFC 3429 erschien im November 2002 als Informational RFC, nicht als Verbreitungs- oder Betriebsbericht. Sein historischer Beitrag liegt in der klaren Grenzziehung: Die ITU-T spezifiziert OAM-Funktionen, das IETF reserviert einen MPLS-Marker, und der Endknoten muss diesen Marker sowie die Nutzlast trotzdem verarbeiten können. Die Registry sorgt für einen gemeinsamen Namen; sie liefert keine Überwachung im laufenden Netz.

Für die Bewertung eines konkreten Pfades müssen die einzelnen Belege zusammengeführt werden: die signalisierte PHP-Anfrage, der Pop am vorletzten LSR, der am Ausgang empfangene Label-Stack, die dortige OAM-Fähigkeit, die Zuordnung der TTSI zum Ingress und das Ergebnis der jeweiligen OAM-Funktion. Kundendaten und Anwendungserfolg erfordern nochmals eigene Beobachtungen. „Label 14 registriert“, „OAM eingeschaltet“ und „LSP aktiv“ sind Aussagen auf unterschiedlichen Ebenen, keine Synonyme für eine erfolgreiche Zustellung.

Quellen