Zusammenfassung

  • CATS wählt Dienstinstanzen anhand von Rechenressourcen und Netzbedingungen. Bei einem mobilen Client mit zustandsbehaftetem Dienst verlangt RFC 10054 eine ausdrückliche Angabe der Anwendung, ob CATS eingesetzt werden darf.
  • Ein neuer Paketpfad, die Affinität eines Flows und ein wiederhergestellter Anwendungskontext sind verschiedene Nachweise. Eine bessere Latenz beweist nicht, dass die Sitzung am zweiten Standort fortgesetzt werden kann.

Der freie Zielknoten kennt nicht automatisch den Sitzungsverlauf

Ein Ingenieur arbeitet mobil an einem interaktiven 3D-Modell. Ein Edge-Dienst verarbeitet seine Eingaben und liefert jeweils das nächste Bild. Nach einem Standortwechsel bietet ein anderes Rechenzentrum einen kürzeren Weg und mehr freie Rechenkapazität. Das Netz kann den Zielknoten bewerten. Es weiß aus diesen Messwerten allein nicht, ob dort auch der Kontext für den nächsten Arbeitsschritt vorliegt.

Diese Grenze macht RFC 10054 sichtbar. Computing-Aware Traffic Steering (CATS) wählt Dienstinstanzen und lenkt den Verkehr, indem es Rechenkapazität und Netzwerkbedingungen gemeinsam betrachtet. Der geografisch nächste Standort muss nicht der geeignetste sein: Ihm können Ressourcen oder spezielle Hardware fehlen, und die Auslastung verändert sich. Auch die Bewegung des Clients verschiebt die Lage.

Aus Sicht des Routings kann CATS anwendungstransparent arbeiten und zustandsbehaftete wie zustandslose Dienste bedienen. Diese Transparenz erspart es Anwendungen, jede einzelne Pfadentscheidung zu treffen. Sie macht den Anwendungszustand aber nicht transparent. Für mobile Clients mit zustandsbehaftetem Dienst verlangt RFC 10054, dass die Anwendung ausdrücklich signalisiert, ob sie CATS zulässt. Ohne diese Angabe kann eine Umsteuerung während der Sitzung den Anwendungskontext zwischen Standorten auseinanderlaufen lassen oder den Dienst unterbrechen.

„Zulassen“ ist dabei eng als betriebliche Angabe zu lesen. RFC 10054 legt weder ein allgemeines Signalformat noch eine API, eine Einwilligungsmaske für Nutzer oder ein juristisches Autorisierungsmodell fest. Ein positives Signal belegt auch nicht, dass der Zustand am Ziel korrekt angekommen ist. Es hält fest, dass der Dienst CATS in dieser Mobilitätssituation erlaubt; Übertragung, Wiederherstellung und Validierung bleiben Aufgaben der Implementierung.

Drei Vorgänge, die oft „Handover“ heißen

Ein Handover kann drei unterschiedliche Dinge bezeichnen. Erstens kann das Netz Pakete anders weiterleiten. Zweitens kann es die Affinität erhalten, damit ein Flow bei derselben Dienstkontaktinstanz und auf einem konsistenten Pfad bleibt. Drittens kann der Dienst den Anwendungskontext zu einer anderen Instanz übertragen, dort wiederherstellen und die Sitzung mit derselben Bedeutung fortsetzen. Das erste ist eine Weiterleitungsaktion, das zweite eine Affinitätseigenschaft, das dritte ein Zustandsübergang des Dienstes.

RFC 10053 beschreibt die Affinität einer Dienstkontaktinstanz als Weiterleitung der Pakete eines Flows an dieselbe Instanz und über denselben Pfad, unter anderem um Umordnung und unvorhersehbare Latenzschwankungen zu vermeiden. Das Framework führt selbst keinen Mechanismus ein, der Affinität definiert oder durchsetzt. RFC 10054 ergänzt drei Anforderungen: R14 verlangt Flow-Affinität für zustandsbehaftete Sitzungen und Transaktionen; R15 verlangt, dass Netzknoten dafür keine anwendungsspezifischen Flow-Zustände halten; R16 empfiehlt Kontinuität bei der Bewegung des Endgeräts oder der Dienstinstanz.

Das ist eine Architekturfrage, noch kein vollständiges Migrationsprotokoll. Das Netz braucht genügend Information, um Flows konsistent zu behandeln, soll aber nicht zum Speicher des Anwendungszustands werden. Die Anwendung muss festlegen, ob eine Sitzung bewegt werden darf und was kopiert, rekonstruiert oder am Ausgangsort belassen werden muss. Das AR/VR-Beispiel in RFC 10054 unterscheidet wiederverwendbare Basisressourcen von clientbezogenen Eingaben, die eine zustandsbehaftete Instanz verarbeitet. Dass am neuen Standort die nächsten Pakete eintreffen, beweist nicht, dass das nächste Bild auf dem richtigen Verlauf beruht.

Eine Netzwerkkennzahl kann also einen geeigneteren Kandidaten zeigen, aber keinen migrierten Kontext bestätigen. Ein Update der Weiterleitungstabelle ist kein Wiederherstellungsnachweis. Eine Antwort vom neuen Dienstkontakt belegt nicht, dass eine längere Transaktion semantisch ohne Bruch weiterlief.

Anforderungen sind kein Betriebsnachweis

RFC 10054 ist ein Informational-Dokument, das den Konsens der IETF-Gemeinschaft repräsentiert und vom IESG zur Veröffentlichung freigegeben wurde. Es ist keine Spezifikation des Internet Standards Track. Seine Anwendungsfälle und Anforderungen sind auf Szenarien innerhalb einer einzelnen Domäne beschränkt. Der Text benennt das Problem und gewünschtes Verhalten, beweist aber weder, dass ein Betreiber jeden Dienst sicher migrieren kann, noch dass mehrere Anbieter denselben Zustandsvertrag verwenden.

Ein pauschales Label „CATS-fähig“ reicht daher nicht. Der Betriebsvertrag sollte festlegen, welche Dienst- und Sitzungsklassen migriert werden dürfen, welches Ereignis den Wechsel auslöst, wer das Signal ausgibt und welcher Nachweis vor der Umleitung erforderlich ist. Eine unabhängige Anfrage sollte nicht automatisch dieselbe Behandlung erhalten wie eine Sitzung, deren nächster Schritt vom Zustand am bisherigen Standort abhängt.

Fehlt das ausdrückliche Signal, ist es vernünftig, die Affinität laufender Sitzungen beizubehalten, bis der Migrationsablauf der Anwendung übernimmt, oder nur neue Anfragen neu auszuwählen. Das ist eine Betriebsempfehlung und keine zusätzliche RFC-Anforderung. Sie verhindert, dass eine bessere Ressourcenauslastung als Kontinuitätsgarantie ausgegeben wird.

Quellen und Status