Zusammenfassung

  • Slice-Verkehr darf NRP-unfähige Knoten durchqueren; statische Fähigkeitsangaben passen sich Änderungen nicht automatisch an und müssen deshalb als zeitgebundene Behauptungen behandelt werden.
  • Führungskräfte sollten Soll-Pfad, aktuelle Knotenfähigkeit, installierte NRP-PHB, tatsächliche Warteschlange und Kundenergebnis getrennt nachweisen lassen.

Der Pfadberechner mied alle als unfähig markierten Geräte. Trotzdem lief der Verkehr über einen Router, der das erwartete NRP-PHB nicht mehr ausführte. Das Inventar stammte aus der Zeit vor einem Softwarewechsel. Für den Controller war der Knoten fähig; für die Pakete war er es nicht.

Die Konfiguration besaß Autorität über die Berechnung, aber keine Autorität über die aktuelle Wirklichkeit.

Revision 10 von Realizing Network Slices in IP/MPLS Networks ist ein aktiver TEAS-Working-Group-Internet-Draft vom September 2026 und läuft am 2. April 2027 ab. Er ist weder RFC noch Bereitstellungsbericht, Interoperabilitätsergebnis, Zertifizierung oder Nachweis eines produktiven SLA. IANA-Aktionen sind nicht vorgesehen; Zuordnung, Kodierung und Policy-Installation bleiben teils lokal, implementationsspezifisch oder außerhalb des Dokuments.

Mehrere Verträge können in einer Ausführungsklasse landen

Ein Slice-Flow Aggregate fasst Pakete zusammen, die einem NRP zugeordnet sind und dieselbe Weiterleitungsbehandlung erhalten. Mehrere IETF Network Slices können ein Aggregat teilen. Der Controller verwaltet die Beziehung, doch das Verfahren der Zuordnung ist lokal.

Damit entscheidet die Organisation, welche Unterschiede aus Kundenverträgen in der Laufzeit erhalten bleiben. Das kann wirtschaftlich sinnvoll sein, solange SLOs, Burst-Profile und Wiederherstellungsbedingungen kompatibel sind. Der Nachweis muss Ursprungsslices, Aggregat, Begründung, Genehmiger und Trennungsauslöser enthalten.

Ein Kundenname ohne Aggregat verbirgt die technische Kompression. Ein Aggregat ohne Kundenbezug verbirgt die Verpflichtung. Beide Koordinaten gehören in denselben Prüfpfad.

Zulassung beweist ein Modell, keine Queue

Eine NRP Policy kann Topologie, Reservierungen, gemeinsame Ressourcennutzung, Pfadbedingungen und Per-Hop-Verhalten festlegen. Im Control-Plane-Modus wird Nachfrage anhand reservierbarer Bandbreite zugelassen, vorbehaltlich konfigurierter Überbuchung.

Die logische Topologie kann weniger, gleich viel oder mehr Kapazität als das physische Netz zeigen. Die maximal reservierbare Bandbreite darf die Linkkapazität übersteigen. Eine erfolgreiche Zulassung besagt daher: Die Nachfrage passte in das zu diesem Zeitpunkt autorisierte Modell.

Ohne Durchsetzung pro Paket können NRPs zur Laufzeit um dieselbe Ressource konkurrieren. Der Entwurf nennt die Garantie weich. Überwachung und Neuoptimierung können auf Engpässe reagieren, ersetzen aber nicht das fehlende Paketverhalten während des Ereignisses.

Zwei Kontrollflächen müssen zusammenwirken

Im Data-Plane-Modus trägt das Paket einen NRP Selector. Fähige Knoten ordnen damit das NRP-PHB zu. Dedizierte Hardware kann strikte Isolation liefern; geteilte Hardware bietet statistische Isolation abhängig von Scheduler und Zuteilung.

Die Kombination mit der Zulassung ist am stärksten, weil sie zwei Fragen beantwortet: Wie viel Bedarf wird angenommen, und wie wird er bei Konkurrenz behandelt? Reservierungsdatensatz, Geräte-Readback und Laufzeitmessung sind unterschiedliche Beweismittel.

Ein Controller-Acknowledge darf deshalb nicht als Ausführung gelten. Er muss mit installierter Queue, Schedulerparametern, Auslastung, Verlust und Verzögerung abgeglichen werden.

Fähigkeitsdaten brauchen Gültigkeit und Rückbestätigung

Der Entwurf erlaubt, dass Slice-Pakete NRP-unfähige Knoten passieren. Der Selector kann erhalten bleiben, oder ein Tunnel führt zum nächsten fähigen Knoten, an dem die Behandlung wieder einsetzt.

Für die Pfadberechnung können Fähigkeiten über Controllermechanismen verteilt oder statisch konfiguriert werden. Der Text weist ausdrücklich darauf hin, dass statische Angaben nicht automatisch auf Topologie- oder Fähigkeitsänderungen reagieren. Damit ist nrp_capable=true keine dauerhafte Eigenschaft, sondern eine datierte Behauptung über Software, Hardware und Konfiguration.

Ein belastbarer Datensatz nennt Beobachtungszeit, Quelle, Software- und Hardwarestand, unterstützten Modus, letzte Geräteprüfung und Ablaufzeit. Er kennzeichnet jeden Abschnitt, in dem das PHB aussetzt, samt tatsächlich verwendeter Behandlung und Kapazität.

Unbekannte Selectoren können verworfen, als Best Effort behandelt oder einem Fallback-NRP zugeordnet werden. Auch diese lokale Entscheidung muss aus dem Gerätelesen statt aus dem Wunschpfad abgeleitet werden.

Domänengrenzen erneuern die Beweispflicht

Über mehrere NRP-Domänen hinweg lassen sich Selectoren stapeln oder neu abbilden. Beim Remapping ersetzt der Grenzknoten den eingehenden Wert durch das Äquivalent der Folgedomäne und konditioniert den Verkehr auf deren SLA-Zuteilung.

Die richtige Tabelle beweist nicht die verfügbare Ressource oder den Erfolg der Konditionierung. Jede Domäne stellt ihren Anteil bereit; ein End-to-End-Ergebnis entsteht erst durch kombinierte Zuteilung und Messung.

Der Grenzbeleg braucht Ein- und Ausgangswert, Mappingversion, verantwortlichen Principal, angenommenes Profil, Konditionierung und nachgelagerte Zusage. Gemeinsame Messfenster verhindern, dass eine Lücke zwischen zwei lokalen Erfolgsberichten verschwindet.

Ein Selector ist kein Berechtigungsausweis

Der Security-Abschnitt beschreibt, wie injizierte Selectoren privilegierte Ressourcen stehlen und DoS erzeugen können. Unbekannte Werte können Fallback-Kapazität angreifen; kompromittierte Managementsysteme können die NRP Policy selbst verändern.

Grenzen müssen deshalb Berechtigung und Verkehrsprofil prüfen, nicht nur Bits erkennen. Authentisierung, Autorisierung und Integrität sichern die Policy-Verteilung. Filter und geschützte Routing-Sitzungen begrenzen die Offenlegung von Ressourcenzustand.

Die organisatorische Schlussfolgerung lautet: Inventar, Absicht und laufender Code sind nicht dieselbe Sache. Ein Koordinator kann Fähigkeitsdaten verteilen; nur aktuelle Gerätebeobachtung zeigt, ob sie gelten. Wer harte Zusagen macht, muss diese Differenz finanzieren und verantworten.

Quellen