Zusammenfassung

  • RFC 9994 normiert einen Network Action Sub-Stack für MPLS-Aktionen und Ancillary Data. Ein darin sichtbarer Opcode beweist keine Ausführung im Netz.
  • Scope, lesbare Labeltiefe, bekannte Fähigkeiten, U-Bit und Knotenrolle legen fest, was ein Knoten tatsächlich verarbeiten kann oder muss.
  • Belastbare Betriebsaussagen trennen Codierung, Pfadannahme, lokale Verarbeitung, Weiterleitung und beobachtete Wirkung.

Die Regel für unbekannte Aktionen ist der beste Einstieg in RFC 9994. Ein Knoten, der den Wert eines Opcode in einem NAS nicht erkennt, folgt dem Feld für Unknown Network Action Handling: Bit 0 bedeutet, zur nächsten Network Action weiterzugehen; Bit 1 bedeutet, das Paket zu verwerfen. Das ist weder ein Fehler der Paketform noch ein Widerruf der Spezifikation. Es ist die vom Format vorgesehene Anerkennung, dass ein Aktionshinweis nur dort wirkt, wo ein Knoten seine Semantik kennt und lokal verarbeiten kann.

Der RFC beschreibt den MPLS Network Action Sub-Stack, kurz NAS, als Teil des Label Stacks. Der erste Eintrag verwendet das MNA base Special-Purpose Label mit dem Wert 4. Es folgt zwingend Format B mit erstem Opcode und NAS-Feldern; Formate C und D können weitere Aktionen oder zusätzliche Daten tragen. Der Mechanismus kann Weiterleitungsentscheidungen beeinflussen, OAM-Informationen transportieren und benutzerdefinierte Operationen aufnehmen. Das sind Möglichkeiten der gemeinsamen Syntax, keine Tatsachenbehauptungen über ein bestimmtes Netz.

Ein einzelner Opcode reicht ausdrücklich nicht als vollständige Betriebsbeschreibung. Die Definition einer neuen Network Action Indicator muss Format, Scope, Menge und Syntax der Ancillary Data, detaillierte Verarbeitung und Wechselwirkungen mit anderen Aktionen festlegen. Eine Nummer in einem IANA-Register macht eine Referenz verfügbar. Sie löst weder Konflikte auf einem konkreten Pfad noch belegt sie Implementierung, Capability, Policy oder Erfolg.

Die Pfadannahme liegt vor dem Paket

Der kapselnde Knoten muss sicherstellen, dass Transit- und Egress-Knoten den NAS verarbeiten können und das Paket die Path MTU nicht überschreitet. Die für die Pfadauswahl verantwortliche Stelle muss MNA-Fähigkeiten und Readable Label Depth der Transitknoten sowie die Fähigkeiten am Egress berücksichtigen. Diese Informationen dürfen konfiguriert, über Management erhoben oder mit Kontrollprotokollen verteilt werden. Wie sie gelernt werden, regelt RFC 9994 nicht.

Das ist keine Lücke, die ein sauberer NAS schließen könnte. Es ist eine Zuständigkeitsgrenze. Ein Paket kann eine Aktion anzeigen, aber es kann nicht selbst beweisen, dass der gewählte Pfad die Voraussetzung ihrer Verarbeitung erfüllt. Ohne dokumentierte Capability- und RLD-Eingaben bleibt die Behauptung einer pfadweiten Wirkung eine Annahme.

Auch der Scope verändert diese Reihenfolge nicht. I2E bedeutet Verarbeitung nur am Egress. Bei HbH sollen alle Knoten auf dem Pfad den NAS verarbeiten. Bei Select handeln nur bestimmte Knoten, die den NAS an die Spitze des Stacks bringen. Verschiedene Scopes erfordern verschiedene NASes. HbH ist somit eine Vorgabe für fähige verarbeitende Knoten, nicht das Inventarprotokoll eines homogenen Netzes. Select benennt eine Verarbeitungsbedingung, nicht den Verantwortlichen, der Auswahl und Fähigkeit dauerhaft nachweist.

Die Rollen zeigen, wo Prüfung stattfinden muss. Der Encapsulating Node kann NASes gemäß eigener Policy, Platzierungsregeln und erlernten Fähigkeiten hinzufügen. Ein Transitknoten verarbeitet die NASes in der festgelegten Reihenfolge. Ein Penultimate Node darf die letzte exponierte HbH- oder I2E-Kopie nicht entfernen, damit der Egress sie verarbeiten kann. Der Egress entfernt jeden NAS, den er erhält. Wer behauptet, eine Aktion sei gelaufen, muss deshalb mehr zeigen als einen erzeugten Header: Pfadwahl, Capability-Eingaben, Knotenbehandlung und Egress-Ergebnis gehören zur Aussage.

Ancillary Data ist ebenfalls keine harmlose Beilage. RFC 9994 warnt, dass Änderungen in bestimmten Labelwert-Bits ECMP-Auswahl beeinflussen und Pakete desselben Flows umordnen können. In entsprechenden Umgebungen dürfen veränderliche Daten diese Bits nicht belegen; alternative Platzierungen sind vorgesehen. Der RFC liefert damit eine technische Einschränkung, keine Leistungszusage für eine Anwendung oder ein bestimmtes Hardwareprofil.

Im Sicherheitsmodell bleibt die Verantwortung lokal und nachweisbar. Aktionen des Kapselungsknotens können viele Knoten auf dem Pfad betreffen. Lokal definierte Aktionen haben nur begrenzte Aufsicht. Zwischenknoten können Ancillary Data verändern. Vor einer Einführung müssen Provider-Grenzknoten MNA-Pakete aus anders verwalteten Domänen filtern können. Zähler für verarbeitete NASes, unbekannte übersprungene oder verworfene Aktionen und fehlerhafte NASes helfen bei der Diagnose. Sie bilden jedoch ohne Korrelation keinen Beleg, dass das erwartete Serviceergebnis eintrat.

Heng Lus Running-Code Primacy formuliert die passende Disziplin: Die gemeinsame Spezifikation soll nur das bestimmen, was Interoperabilität erfordert. Danach entscheiden lokal prüfbare Implementierung, Annahme und Nachweis. Ein Opcode ist Syntax. Erlernte Fähigkeit, lokale Zulassung, Knotenverarbeitung, Forwarding-Effekt und beobachtete Dienstwirkung sind andere Realitätsebenen.