Zusammenfassung

  • RFC 7212 erlaubt einem MPLS-Endpunkt, Fähigkeiten, Konfigurationsparameter und anwendungsspezifische Informationen über den G-ACh anzukündigen; der Absender wird dadurch nicht zur Konfigurationsinstanz des Empfängers.
  • Der Empfänger behält die Kontrolle durch kanalweise Aktivierung, lokale Anwendungsberechtigung, anwendungseigene Verarbeitungsregeln, explizite Lebensdauer und authentisierte Aktualitätsprüfung.
  • Sichere Automatisierung braucht eine sichtbare Begründungskette: empfangene Daten, Authentisierung, Gültigkeitsende, konsumierende lokale Regel und Anlass jeder Änderung.

Eine Ankündigung ist eine Tatsache, kein Befehl

Das G-ACh Advertisement Protocol, kurz GAP, löst ein praktisches Problem in Transportnetzen. Ein Endpunkt eines LSP, Pseudowires oder Abschnitts muss seinem Peer möglicherweise mitteilen, welche Fähigkeiten er unterstützt, welche Parameter er nutzt oder welche Informationen eine Anwendung über den Kanal benötigt. In einer MPLS-TP-Umgebung ohne IP können übliche IP-Erkennungsverfahren fehlen. Ein von der Sicherungsschicht unabhängiger Ankündigungskanal reduziert fragile statische Konfigurationen und macht Inkonsistenzen früher sichtbar.

Die maßgebliche Zuständigkeitsgrenze steckt im Wort „Ankündigung“. RFC 7212 definiert einen einfachen unidirektionalen Betrieb: Ein entsprechend konfigurierter Sender überträgt typisierte Anwendungsdatenblöcke. Der Empfänger kann seine Konfiguration prüfen oder anpassen, doch die Verwaltungsrollen verschmelzen nicht. Senden und Empfangen arbeiten pro Datenkanal und werden vom Betreiber konfiguriert. Alle GAP-Anwendungen sind standardmäßig deaktiviert. Empfangene Daten gehen nur an lokale Anwendungen, die sie benötigen und lokal zu ihrer Einsicht berechtigt sind.

Damit ist die Machtverteilung klar. Der Sender verantwortet die Aussage über sich selbst. Der Betreiber der Empfangsseite entscheidet, ob GAP läuft, welche Anwendung die Information sehen darf und wozu sie berechtigt ist. Die Anwendungsspezifikation bestimmt die Bedeutung ihrer TLVs. Die bloße Ankunft eines Pakets belegt keine dieser Befugnisse.

Ein konkretes Kontrollbeispiel

Zwei benachbarte MPLS-TP-Knoten teilen einen Ethernet-Abschnitt ohne IP-Weiterleitung. Knoten A kündigt seine Quell-MAC-Adresse und maximale Frame-Größe über die in RFC 7213 definierte Anwendung Ethernet Interface Parameters an. Knoten B kann die Adresse lernen und die angegebene Größe mit seinem lokalen Mindestwert vergleichen.

Das ist wertvolle Evidenz, aber kein Fernbefehl zum Abschalten des Links. RFC 7213 überlässt die Folge der konfigurierten Richtlinie: Der Betreiber kann den Link bei einer Abweichung herunterfahren oder ihn aktiv lassen und die effektive Größe per OAM prüfen. Dieselbe empfangene Tatsache kann unter verschiedenen lokalen Richtlinien unterschiedliche legitime Handlungen stützen.

Nicht nur die Implementierung profitiert. Der Betreiber erhält eine prüfbare Sicht auf den Peer-Zustand, kann veraltete statische Annahmen ersetzen und Abweichungen zwischen den Enden diagnostizieren. RFC 7213 empfiehlt, die betreffende Ankündigung nach Neukonfiguration, Neustart oder erkannter Unterbrechung frühzeitig zu senden, damit der Link-Zustand neu initialisiert werden kann. Anwendungen nutzen einen gemeinsamen Träger, der kein bestimmtes Erkennungsprotokoll voraussetzt. Dafür muss die lokale Änderungshoheit nicht aufgegeben werden.

Aktualität, Identität und Bedeutung sind getrennte Prüfungen

Jeder Anwendungsdatenblock enthält eine Lebensdauer. Statische Daten dürfen nur so lange aufbewahrt werden. Null markiert sie sofort als abgelaufen; ein leerer Block kann frühere Daten der Anwendung verfallen lassen. Nach einem Neustart müssen aus Peer-Ankündigungen gespeicherte Zustände verworfen werden. So kann eine alte Beobachtung nicht als aktuelle Grundlage auftreten.

Die Authentisierung beantwortet eine andere Frage. RFC 7212 definiert Nachrichtenauthentisierung und nutzt Zeitstempel gegen Replay-Angriffe. Schlüsselkennungen werden durch ausdrückliche Betreiberkonfiguration oder einen separaten Schlüsselaustausch mit Parametern verbunden. Authentizität, Aktualität und semantische Autorisierung bleiben getrennt. Ein gültiger MAC zeigt den Schutz durch einen zugelassenen Schlüssel; er entscheidet nicht über das Umschreiben eines lokalen Parameters und verlängert keine abgelaufenen Daten.

Kann der Empfänger eine Anwendung nicht interpretieren, darf er ihre Bytes für die angegebene Lebensdauer behalten, weil sie dem Betreiber helfen können. Evidenz aufzubewahren heißt nicht, sie auszuführen. Das System kann unbekannte Bedeutung offenlassen, statt eine Handlung zu erfinden.

Entscheidungsbefugnis bringt Betriebsverantwortung mit sich

GAP belässt mehrere Lasten bewusst bei Anwendungen und Betreibern. Der Sender wählt die Frequenz. Zu große Daten muss die Anwendung fragmentieren, denn GAP bietet weder Fragmentierung noch Wiederzusammenbau. Anwendung und Betreiber müssen verhindern, dass Ankündigungen den Peer-Link überlasten. Schlüssel, Uhren, Replay-Toleranz, Ablauf, Neustartbereinigung und Audit-Sichtbarkeit brauchen klare Eigentümer.

RFC 7212 verlangt zudem, dass empfangene Daten für Betreiber prüfbar sind. Ändert eine eingehende Information die lokale Konfiguration, muss der Grund verständlich sein. Das ist der entscheidende Kontrollpunkt für einen verantwortbaren Betrieb: Automatisierung bleibt beherrschbar, wenn ein Beleg den Weg von der authentisierten Beobachtung über die lokale Regel bis zum Konfigurations-Diff rekonstruiert. Ohne diese Spur wird die Aussage eines Peers stillschweigend zu unerklärter Autorität.

Quellen