Zusammenfassung

  • Ein externer FAS konnte Flows zulassen, ablehnen, umleiten oder mit Betriebsregeln versehen; die Verbindung entstand weiterhin im Switch.
  • Die LFAP-Nachrichten quittierten einzelne Übergaben, nicht gemeinsam den vollständigen Dienst- oder Abrechnungserfolg.
  • AMBIGUOUS, NO_SUCH_FLOW und die ausgelassene Sicherheitsanalyse zeigen, weshalb Urteil, Gerätehandlung und wirtschaftliche Aufzeichnung getrennt bleiben müssen.

Im März 1997 beschrieb RFC 2124 eine Antwort auf ein noch ungelöstes Standardisierungsproblem. Die Darstellung von Verbindungspolitik war nicht vereinheitlicht. Dennoch sollte eine Organisation mehrere ATM-Switches von einer Stelle aus steuern können. LFAP verband deshalb die Connection Control Entity (CCE) im Switch mit einem externen Flow Admission Service (FAS).

Der RFC-Editor-Eintrag und der IETF-Datatracker ordnen das Dokument als Informational ein, nicht als Internet Standard. Es belegt eine Schnittstelle, keine flächendeckende Einführung.

Erst fragte der Switch

Der Switch leitete jede anfängliche Kommunikation ein. Unmittelbar vor dem Aufbau sandte die CCE einen Flow Admission Request (FAR) mit Flow ID, Adressen, Dienstkennung, Zeit und optionalen Kundendaten. Der FAS antwortete mit einem Flow Admission Acknowledge (FAA).

Ein FAA konnte zulassen, ablehnen, optionale oder zwingende Betriebsregeln liefern und ein Umleitungsziel nennen. Das war ein Urteil über die übermittelten Angaben. Es bewies weder eine aufgebaute Verbindung noch erfolgreiche Übertragung.

Unbekannte optionale Regeln durfte die CCE ignorieren. Eine unbekannte zwingende Regel musste dagegen zum Abbruch und zu einem Flow Admission Update führen. Die zentrale Politik konnte eine Bedingung setzen; ob daraus Zustand wurde, entschied die lokale Fähigkeit des Geräts.

Der laufende Flow lieferte eigene Belege

Nach dem Aufbau sendete die CCE Flow Update Notifications (FUN). Sie konnten Zeitpunkt, ACTIVE oder INACTIVE sowie Byte- und Paket-, Zellen- oder Framezähler enthalten. Meldungen erschienen periodisch, bei Zustandsänderung oder auf Anforderung.

Kumulative Zähler liefen seit Flow-Beginn, Deltazähler nur seit dem vorherigen FUN. Ohne diesen Typ war eine scheinbar vollständige Summe wertlos. Selbst ein korrekter Zähler bewies keine Berechtigung, Anwendungszustellung oder gültige Rechnung.

Beim Flow Update Acknowledge (FUA) bedeutete SUCCESS, dass der FAS die FUN-Information akzeptiert hatte und nun dafür verantwortlich war. Das war eine Übernahme von Informationsverantwortung, keine Garantie für dauerhafte Speicherung, Vollständigkeit, Replikatgleichheit oder Kundenergebnis.

Ein Flow Change Request (FCR) konnte später Regeln ändern oder den Flow stoppen. Der Switch antwortete mit Flow Change Acknowledge (FCA). POLICY_REJECT zeigte eine nicht unterstützte Änderung, NO_SUCH_FLOW fehlenden Zustand. Die ursprüngliche Zulassung machte spätere Kontrolle nicht automatisch wirksam.

Eindeutigkeit gehörte zur ganzen Anfrage

Kam eine bereits verwendete Flow ID mit einem FAR, das bis auf die Message ID vollständig dem früheren FAR entsprach, durfte der FAS die frühere Antwort wiederholen. Bei anderem Inhalt folgte AMBIGUOUS und die CCE musste eine neue ID wählen. Idempotenz beruhte auf dem vollständigen Auftrag, nicht auf einer Zahl.

NO_SUCH_FLOW legte Zustandsverlust offen. Der FAS konnte ein FUN zu einer nie zugelassenen oder vergessenen Verbindung erhalten; der Switch einen FCR zu einem nicht mehr bekannten Flow. Die Schnittstelle verlangte erneute Zulassung, Meldung oder Stopp statt blinden Vertrauens in eine Seite.

Für Failover kombinierte man einen FAS-Präfix mit der CCE-ID. Ohne Präfix-Unterstützung konnte ein einziger Anruf am Sammelpunkt als zwei erscheinen. Der Namensraum senkte Kollisionsgefahr, bewies jedoch keine identischen Zustände alternativer FAS-Instanzen.

Mächtige Steuerung ohne Sicherheitsmodell

Der FAS durfte ablehnen, umleiten und stoppen. Trotzdem lautet die Security-Considerations-Aussage nur, dass Sicherheitsfragen nicht behandelt werden. Eine TCP-Verbindung authentifizierte nicht automatisch die politische Autorität. Das heutige IANA-Dienst- und Portregister führt csi-lfap auf Port 3145 und vermerkt zugleich bekannte unbefugte Nutzung dieses Ports.

Die Abgrenzung zu bestehender BTW-Berichterstattung ist sauber. RFC 2063 beschreibt die Messarchitektur; der vorhandene Artikel untersucht die Zeitlücke asynchroner Leser. RFC 2123 beschreibt NeTraMet; der vorhandene Artikel untersucht die Projektion durch Regelsätze. RFC 2124 handelt vom Weg des zentralen Urteils zum ausgeführten Zustand und zur späteren wirtschaftlichen Spur.

Heng Lus Running-Code Primacy, Minimum Initial Specification, Localized Future Decision und On Reality Layers liefern dafür eine aktuelle Sprache: Eine administrative Darstellung ersetzt keine ausführbare Wirklichkeit.

LFAP nahm programmierbare Kontrolle vorweg. Dauerhaft wichtig bleibt die Pflicht, Entscheidungs-, Ausführungs-, Abgleich- und Zählbeleg getrennt aufzubewahren.

Quellen