Zusammenfassung

  • Revision 14 von draft-ietf-mpls-mna-ioam vom 11. September 2026 ergänzt eine normative Regel für MPLS-Knoten mit unbekanntem Load-Balancing-Verfahren.
  • Für einen per Flow ID MNA identifizierten Flow müssen 19 Bits des Sequence Number MNA ab Bit 1 des LSE unverändert bleiben, wenn Label-Stack-Informationen ins Load-Balancing eingehen – und nun auch dann, wenn das Verfahren nicht bekannt ist.
  • Wie ein Betreiber das Verfahren eines Knotens ermittelt, bleibt außerhalb des Entwurfs. Die fixierten Bits beseitigen eine mögliche Störgröße, sind aber kein Nachweis eines stabilen Messpfads.
  • Vor einem Vergleich von IOAM-DEX-Beobachtungen braucht es einen lokalen Beleg für die Hash-Annahme, ihre Quelle, die erfassten Knoten und den Messpunkt.

Aus einem Zähler wird möglicher Hash-Input

Sequence Numbers schaffen Ordnung in Beobachtungen. RFC 9326 verwendet sie bei IOAM Direct Export: Üblicherweise beginnt die Nummer bei null und steigt für jedes DEX-tragende Paket desselben Flows um eins. Ein Flow ID kann Exporte dieses Flows korrelieren; wie der Identifier zugeteilt wird, schreibt das RFC nicht vor.

Der MPLS-Entwurf bringt beide Felder in unmittelbare Nähe des Forwarding-Kontexts. In draft-ietf-mpls-mna-ioam-14 belegen Flow ID MNA und Sequence Number MNA jeweils ein vollständiges, 32 Bit breites Format-D-LSE. Nach dem festgelegten führenden Bit und dem MPLS-S-Bit bleiben jeweils 30 Nutzbits.

Wenn ein Router Informationen aus dem Label Stack für die Verteilung gleichartiger Flows hasht, kann eine pro Paket wechselnde Sequence Number neue Entropie liefern. Dann beobachtet der Zähler nicht nur die Folge der Pakete. Er kann an der Auswahl des Pfads mitwirken, über den diese Pakete später beobachtet werden.

Der neue Umgang mit fehlendem Wissen

Revision 13 kannte zwei entschiedene Fälle. Ist bekannt, dass Label-Stack-Informationen verwendet werden, muss der 19 Bit lange Teil ab Bitposition 1 des LSE für einen bestimmten Flow ID unverändert bleiben. Ist dagegen bekannt, dass andere Load-Balancing-Techniken zum Einsatz kommen, dürfen sämtliche Bits der Sequence Number variieren.

Der offizielle Vergleich zwischen Revision 13 und 14 fügt die dritte Lage hinzu: Ist die Technik eines Knotens unbekannt, gilt dieselbe 19-Bit-Unveränderlichkeit. Gleich danach grenzt der Text seine Leistung ein. Mechanismen, mit denen die eingesetzten Techniken erlernt werden könnten, gehören nicht zum Dokument.

Das ist eine Verteilung von Beweislast. Ohne Wissen gilt die restriktive Variante. Wer alle Sequenzbits verändern will, muss zunächst begründen können, warum der Knoten in die andere Kategorie fällt. Der Entwurf definiert keine Geräteabfrage und keinen Test, der diese Begründung automatisch liefert.

Revision 14 präzisiert außerdem die Präsenzregeln. Ist das F-Flag nicht gesetzt, muss das gesamte Format-D-LSE für den Flow ID einschließlich seiner festen Bits fehlen; beim Q-Flag gilt dasselbe für die Sequence Number. Wird Alternate Marking nicht genutzt, muss die Block-Number im Post-Stack-Header nun null sein – zuvor war das nur eine Empfehlung. Mehrere falsche Kombinationen von In-Stack- und Post-Stack-Aktionen gelten als missgebildet und verlangen den Paketverwurf.

Die Einbettung stützt sich auf die IOAM-Architektur von RFC 9197, die einen begrenzten Verwaltungsbereich voraussetzt und bereits vor Wechselwirkungen mit ECMP warnt, sowie auf das MNA-Rahmenwerk in RFC 9789 und die Basislösung in RFC 9994. Hinzu kommen der noch bearbeitete MNA-Post-Stack-Header und bestehende IOAM-Felder aus der IANA Trace-Type Registry.

Kein Zertifikat für Pfadstabilität

Die fixierten Bits beantworten eine begrenzte Frage: Dieser Teil der Sequence Number soll einen möglichen Label-Stack-Hash nicht verändern. Daraus folgt nicht, welche Felder der Chip tatsächlich liest, wie tief er in den Stack blickt, ob ein späterer Knoten anders entscheidet oder ob sich das Verhalten mit Software und Konfiguration ändert.

Auch der Flow ID beglaubigt keinen universellen Flow-Begriff. Er hilft, Datensätze zusammenzuführen, zwingt verschiedene Geräte aber nicht zu identischer Klassifizierung. Eine lückenlose Folge kann trotz einer Pfadabweichung entstehen; eine Lücke kann ebenso im Export oder Collector liegen wie im Forwarding. Der Quellenbestand enthält weder eine benannte Implementierung noch Interoperabilitätstest, Paketmitschnitt, Pfadmessung oder gemessenen Verarbeitungsaufwand.

Die Vertrauensgrenze ist ausdrücklich administrativ. IOAM- und IOAM-DEX-Aktionen sind für eine einzige vertrauenswürdige Domäne vorgesehen. Randknoten müssen entsprechende MPLS-Pakete aus einer anderen Domäne oder nicht vertrauenswürdigen Quelle vor der Zulassung filtern. Begleitdaten können im Klartext übertragen werden und dürfen ohne zusätzlichen Schutz nicht als integer gelten.

Auch institutionell ist nur ein Zwischenschritt erreicht. Der Datatracker-Eintrag führt ein aktives Internet-Draft der MPLS-Arbeitsgruppe mit Ziel Proposed Standard. Der WG-Status lautet „Submitted to IESG for Publication“, der IESG-Status „Publication Requested“; die Historie dokumentiert die Fassungen. Die beantragten Opcodes stehen weiter auf TBA. Das ist weder IANA-Zuteilung noch Genehmigung, RFC oder Einsatznachweis.

Quellen