Zusammenfassung

  • draft-ietf-nmop-simap-concept-13 beschreibt die Navigation vom Dienst zu stützenden logischen und physischen Ressourcen sowie den umgekehrten Weg von einer Ressource zu abhängigen Diensten.
  • Die Antwort zeigt, was ein SIMAP-Server unter einer bestimmten Berechtigung, Abstraktion, Quelle und Zeitlage dargestellt hat. Vollständigkeit, Synchronisation, Ursache, Entscheidungsbefugnis, Ausführung und Ergebnis benötigen eigene Nachweise.

Für eine Auswirkungsanalyse genügt keine Geräteliste. Ein Betreiber muss von einem Kundendienst durch logische Knoten und Links, Schicht 3 und Schicht 2 bis zu den physischen Betriebsmitteln gelangen. Beginnt die Untersuchung bei einer gestörten Ressource, muss derselbe Zusammenhang nach oben zu den Diensten führen, die von ihr abhängen.

Genau dafür soll die Service & Infrastructure Map eine gemeinsame, abfragbare Struktur schaffen. Je überzeugender der Pfad aussieht, desto größer ist allerdings die Gefahr einer Verwechslung: Der Graph ist eine Repräsentation des Netzes. Er ist nicht automatisch ein vollständiger und zeitgleicher Abdruck des Netzes.

Grundlage ist Revision 13 von draft-ietf-nmop-simap-concept vom 4. September 2026. Der IETF Datatracker führt sie als aktiven Internet-Draft der NMOP Working Group mit beabsichtigtem Status Informational. Die Historie verzeichnet den IETF Last Call bis zum 26. September. Der Text ist kein fertiger RFC und kann sich noch ändern.

Ein Graph, zwei Suchrichtungen

Zum Kern gehören Netze, Knoten, Links und Termination Points. Supporting Relationships verbinden Elemente innerhalb einer Schicht und über Schichten hinweg. Bei der Suche vom Dienst zur Ressource ermittelt der Client zunächst logische und schließlich physische Ressourcen. In der Gegenrichtung beginnt er bei einer physischen Ressource oder einem Element der Schicht 2 oder 3 und findet Dienste, Knoten, Links und Endpunkte, die darauf aufbauen.

RFC 8345 definiert bereits Supporting Networks, Nodes, Links und Termination Points im YANG-Modell für Netztopologien. SIMAP erweitert den betrieblichen Zusammenhang und verweist auf Inventar, Assurance, Konfiguration und Beobachtungsdaten.

Ein Verweis übernimmt jedoch nicht die Gewissheit des anderen Systems. Ein Inventarobjekt kann eine andere Kennung tragen, ein Assurance-Symptom kann später erhoben worden sein und eine Messung kann nur für ein Zeitfenster gelten. Technisch verknüpfte Datensätze sind nicht zwangsläufig dieselbe Sache zur selben Zeit.

Berechtigung bestimmt den Ausschnitt

Revision 13 macht jede Abfrage davon abhängig, was der Client sehen darf. Ein Server kann Schichten verbergen oder aus Sicherheits-, Verwaltungs- oder Geschäftsgründen eine Abstraktion anstelle der nativen Topologie liefern. Die Antwort kann für diesen Client korrekt und als Gesamtbeschreibung dennoch unvollständig sein.

Was in der Antwort fehlt, ist deshalb nicht im Netz widerlegt. Ein abstrakter Knoten kann mehrere native Knoten zusammenfassen. Ein logischer Link kann physische Pfade mit unterschiedlichen gemeinsamen Ausfallrisiken verdecken. Ein Kunde kann die für seinen Dienst nötige Abhängigkeit sehen, ohne Einblick in die interne Infrastruktur des Anbieters zu erhalten.

Auch Schichtwechsel und Abstraktionswechsel sind verschieden. Der Weg von einem Layer-3-Link zu seinem Layer-2-Pfad erklärt eine stützende Schicht. Der Weg von einem abstrakten Knoten zu den darin zusammengefassten nativen Knoten erklärt Granularität. Ein Abfragenachweis muss beide Achsen benennen.

„Live“ braucht einen Zeitpunkt

Der Entwurf nennt die Live-Topologie den neuesten Snapshot des realen Netzes und verlangt Erkennung sowie Synchronisation. Das sind Anforderungen an eine Implementierung. Eine erfolgreiche Antwort prüft nicht unabhängig, ob genau diese Instanz vollständig und frisch synchronisiert war.

Zusätzlich gibt es Snapshots, potenzielle, beabsichtigte und passive Topologien. Die beabsichtigte Topologie beschreibt ein Soll und kann Zwischenstationen oder Geräte auslassen. Passive Infrastruktur lässt sich womöglich nicht aus dem Netz entdecken und stammt aus einem anderen Register. Status und Historie können in SIMAP liegen oder nur über SIMAP erreichbar sein.

Vor einer Gegenüberstellung müssen daher Instanz, Sichttyp, Quelle, Beobachtungszeit und Synchronisationszustand feststehen. Ohne diese Angaben ist „live“ eine Kategorie, kein Aktualitätsbeleg.

Abhängigkeit ist noch keine Ursache

Liefert eine Ressource-zu-Dienst-Abfrage fünf Dienste, waren diese fünf in der gewählten Sicht als abhängig modelliert. Daraus folgt nicht, dass die Ressource fünf Störungen verursacht hat. Sie kann auf einem Ersatzpfad liegen, Last teilen, in einer veralteten Beziehung stehen oder ihren Zustand nach dem Snapshot geändert haben. Ein Dienst kann aus einem anderen Grund ausfallen.

Für Kausalität braucht es eine Chronologie: Zustandswechsel der Ressource, passende Änderung bei Verkehr oder Dienst, Prüfung alternativer Ursachen und Beobachtung der Erholung nach einem Eingriff. SIMAP ordnet die Untersuchung, ersetzt aber keine solche Beweiskette.

In die Karte zu schreiben ändert nicht das Netz

Der Entwurf trennt SIMAP-Schreiboperationen ausdrücklich von der Konfiguration des Live-Netzes. Schreiben dient What-if-Analysen und beabsichtigten oder passiven Topologien. Reale Änderungen laufen über die üblichen Controller-Operationen.

Automatisierung benötigt deshalb getrennte Belege für Karte oder Vorschlag, Entscheidung und Befugnis, die an Controller oder Gerät gesendete Operation sowie die Beobachtung danach. Eine akzeptierte Modelländerung beweist keine Geräteaktion. Eine akzeptierte Geräteaktion beweist keinen wiederhergestellten Dienst.

Dasselbe gilt für Closed Loop. SIMAP kann Überwachung und Analyse unterstützen; der Kreis umfasst zusätzlich eine autorisierte Korrektur und Feedback. Ohne unabhängige Nachmessung kennt das System nur den Fortschritt seines Workflows.

Die Antwort braucht einen Sichtbeleg

Für folgenreiche Abfragen sollten Server, Instanz, Modellversion, Client-Rolle und Berechtigungsumfang, Schicht und Abstraktion, externe Quellen, Erfassungszeiten, Beziehungsrichtung, Filter und Synchronisationszustand erhalten bleiben. Folgen Aktionen, bleiben Genehmigung, Ausführung, Beobachtung und Rollback getrennt.

Diese Begrenzung macht SIMAP nicht schwächer. Sie macht die Automatisierung überprüfbar. Die belastbare Aussage lautet nicht „So ist das Netz“, sondern: Unter diesen Quellen, Rechten und Zeitbedingungen hat dieser Server diese Abhängigkeit dargestellt.

Quellen

Text und Status: SIMAP Revision 13 und Datatracker-Historie. Zugehörige Grundlagen: RFC 8345, RFC 8341, RFC 8040, RFC 9417 und RFC 9408. Der SIMAP-YANG-Entwurf ist ein individueller Internet-Draft ohne formellen Stand im IETF-Standardisierungsprozess. Eingefrorener Quelltext: Archiv der Revision 13. Traffic-Engineering-Kontext: RFC 9522.