Résumé

  • CATS choisit des instances de service à partir des conditions du réseau et des ressources de calcul. Pour un client mobile utilisant un service à état, la RFC 10054 demande à l’application d’indiquer explicitement si elle autorise cette fonction.
  • Un chemin disponible ne prouve ni que l’affinité du flux est préservée, ni que le contexte applicatif a été restauré sur le nouveau site.

Le calculateur a changé de site ; l’historique, lui, n’a peut-être pas suivi

Un poste de réalité augmentée reçoit des images rendues à la périphérie du réseau. Tant que la personne reste dans la même zone, un site proche conserve le contexte nécessaire aux images suivantes. Puis elle se déplace. Un autre site dispose de davantage de capacité, et la route vers celui-ci paraît meilleure. Le réseau peut constater ces deux faits. Il ne peut pas en déduire que la session peut être continuée ailleurs.

La RFC 10054 expose précisément cette différence. Computing-Aware Traffic Steering, ou CATS, choisit des instances de service et dirige le trafic en tenant compte des ressources de calcul autant que des conditions de réseau. Le site le plus proche n’est pas toujours le mieux équipé ; la charge et la mobilité du client peuvent aussi changer l’équilibre après le début d’une session.

Du point de vue du routage, CATS peut rester transparent à l’application et s’appliquer à des services avec ou sans état. Cette transparence concerne la manière dont le réseau choisit un point de service. Elle ne rend pas visible ou portable l’état que l’application associe à une série d’échanges. Pour un client mobile et un service à état, la RFC demande donc à l’application d’indiquer explicitement si elle autorise l’activation de CATS. À défaut, une réorientation en cours de session peut rendre le contexte incohérent entre les sites, voire interrompre le service.

Il faut lire « autorise » dans le sens opérationnel étroit du texte. La RFC ne définit pas une API universelle, un format de signalisation, une interface de consentement de l’utilisateur ou une règle juridique. L’indication dit que le service accepte la fonction de réorientation dans ce contexte ; elle ne prouve pas que le nouvel hôte possède déjà une copie correcte de l’état. Il faut encore rendre le transfert effectif et vérifiable.

Le chemin, l’affinité et le contexte ne sont pas le même objet

Un « basculement » peut désigner trois opérations différentes. Le réseau peut d’abord changer le chemin des paquets. Il peut ensuite maintenir les paquets d’un flux sur la même instance de service et le même chemin. Enfin, le service peut déplacer l’état applicatif, le restaurer sur une autre instance et reprendre sans rupture de sens. Le premier changement est un acte de transfert ; le deuxième est une propriété d’affinité ; le troisième est une transition de service.

La RFC 10053 décrit l’affinité de l’instance de contact : conserver les paquets d’un flux sur la même instance et le même trajet, notamment pour éviter le désordre et des variations de latence imprévisibles. Mais son cadre ne définit ni n’impose lui-même un mécanisme d’affinité. La RFC 10054 ajoute trois exigences distinctes : R14 demande l’affinité par flux pour les sessions et transactions à état ; R15 demande d’éviter les états applicatifs par flux dans les équipements réseau à cette fin ; R16 recommande la continuité lors de la mobilité du terminal ou de l’instance.

Cette combinaison pose la question d’architecture sans fournir un protocole complet de migration. Le réseau doit pouvoir préserver le traitement d’un flux sans devenir l’entrepôt de l’état applicatif. L’application doit préciser si une session peut bouger et définir ce qui doit être copié, reconstruit ou laissé sur place. Dans l’exemple de réalité augmentée, la RFC distingue des ressources de base réutilisables des entrées propres au client qui alimentent un service à état. Le prochain paquet reçu par un second site n’est pas une preuve que le prochain rendu s’appuie sur le bon historique.

On peut donc conclure qu’une métrique aide à classer des destinations, pas à certifier la migration d’un contexte. Une mise à jour de routage ne vaut pas reçu de restauration. Un service joignable au nouvel emplacement ne garantit pas qu’une transaction longue a gardé sa cohérence.

Une exigence d’information, pas une preuve de déploiement

La RFC 10054 est un document IETF de consensus communautaire approuvé par l’IESG, mais de catégorie Informational, hors du Standards Track. Ses cas d’usage et exigences concernent des scénarios dans un domaine unique. Cela limite les conclusions : le texte décrit le problème et les propriétés souhaitées ; il ne prouve pas qu’un opérateur sait migrer tous ses services, ni qu’une frontière entre fournisseurs partage la même sémantique d’état.

L’opérateur doit donc éviter un indicateur générique « compatible CATS ». Le contrat utile identifie les classes de services et de sessions pouvant bouger, l’événement qui rend le changement possible, l’acteur qui émet l’indication et la preuve attendue avant la redirection. Une requête indépendante et une transaction dont la prochaine étape dépend du site actuel ne devraient pas hériter par défaut de la même politique.

Sans indication explicite, il est raisonnable de maintenir l’affinité active jusqu’à ce que le mécanisme de migration de l’application prenne le relais, ou de ne réorienter que de nouvelles requêtes. C’est une recommandation d’exploitation, pas une exigence supplémentaire de la RFC. Elle évite de faire passer un gain de capacité pour une garantie de continuité.

Sources et statut