Resumen

  • CATS elige instancias usando recursos de cómputo junto con condiciones de red. Si el cliente se desplaza y el servicio conserva estado, RFC 10054 exige que la aplicación indique si permite activar CATS.
  • Redirigir paquetes, mantener la afinidad de un flujo y trasladar correctamente el contexto de la aplicación son resultados distintos. Una ruta más rápida no demuestra que el segundo sitio pueda continuar la sesión.

El sitio menos cargado no conoce el último paso del usuario

Pensemos en una experiencia de realidad aumentada que procesa cada movimiento del usuario en un nodo de borde y devuelve el siguiente cuadro. La persona sale del centro de la ciudad; el enlace hacia un segundo sitio mejora y allí sobra capacidad de cómputo. La red tiene razones para preferir ese destino. La aplicación debe responder una pregunta que las métricas no pueden resolver: ¿puede esta sesión continuar allí con su historial intacto?

Ese límite atraviesa RFC 10054. Computing-Aware Traffic Steering (CATS) selecciona instancias y dirige tráfico atendiendo tanto a los recursos de cómputo como a las condiciones de red. La cercanía física no garantiza que un sitio tenga capacidad o hardware adecuados. Además, la carga cambia y los clientes se mueven, de modo que el destino apropiado al inicio puede dejar de serlo.

Desde el punto de vista del enrutamiento, CATS puede ser transparente para la aplicación y servir tanto a servicios con estado como sin él. Esa transparencia ayuda a que la red elija un punto de servicio sin pedir a cada aplicación que calcule cada ruta. No vuelve transparente el estado que la aplicación mantiene entre solicitudes. Para un cliente móvil con un servicio con estado, RFC 10054 exige que la aplicación indique explícitamente si permite que el sistema de enrutamiento active CATS. Sin esa indicación, la reorientación a mitad de sesión puede desalinear el contexto entre sitios o interrumpir el servicio.

“Permitir” debe entenderse en el alcance técnico que le da el documento. RFC 10054 no define un formato universal de señalización, una pantalla de consentimiento para el usuario ni una autorización jurídica. Tampoco afirma que la señal pruebe que el nuevo sitio ya recibió una copia válida del estado. Es una condición operativa que el servicio debe declarar; aún falta demostrar que la migración se completó correctamente.

El paquete, el flujo y el contexto cuentan historias diferentes

La palabra “traslado” suele mezclar tres hechos. Primero, la red puede cambiar el camino de los paquetes. Segundo, puede preservar la afinidad para que un flujo siga llegando a una instancia y un camino coherentes. Tercero, el servicio puede transferir el contexto de la aplicación, restaurarlo en otro sitio y continuar sin cambiar el significado de la sesión. El primer hecho es una acción de reenvío; el segundo, una propiedad de afinidad; el tercero, una transición de estado del servicio.

RFC 10053 describe la afinidad de instancia de contacto como el envío de los paquetes de un flujo a la misma instancia y por la misma ruta, entre otras razones para evitar desorden y variaciones impredecibles de latencia. Pero el marco no introduce por sí mismo un mecanismo que defina o imponga esa afinidad. RFC 10054 añade tres requisitos: R14 pide afinidad por flujo para sesiones y transacciones con estado; R15 pide evitar que los nodos de red mantengan estados por aplicación y flujo para lograrla; R16 recomienda continuidad cuando se mueve el equipo del usuario o la instancia de servicio.

La combinación señala un problema de arquitectura, no un protocolo acabado. La red necesita suficiente información para tratar el flujo de forma estable sin convertirse en el almacén del estado de la aplicación. La aplicación debe indicar si admite el cambio y definir qué se copia, qué se reconstruye y qué permanece en el sitio actual. En el ejemplo de realidad aumentada, RFC 10054 separa recursos base reutilizables de entradas específicas del cliente que alimentan una instancia con estado. Que el siguiente paquete llegue a otro sitio no prueba que el siguiente cuadro se genere a partir del historial correcto.

Por eso, una buena métrica identifica una alternativa; no certifica una sesión portable. Un cambio en la tabla de rutas no equivale a un recibo de restauración. Que el nuevo punto responda no demuestra que una transacción larga haya conservado su coherencia.

Un documento de requisitos no certifica un servicio desplegado

RFC 10054 es un documento de consenso de la comunidad IETF aprobado por el IESG, pero es Informativo y no pertenece al Standards Track. Sus casos de uso y requisitos se limitan a escenarios de un solo dominio. El texto delimita el problema y el comportamiento deseado; no prueba que un operador pueda migrar cualquier servicio ni que dos proveedores compartan la misma semántica de estado.

Un rótulo genérico como “compatible con CATS” no basta. El contrato operativo debe identificar qué clases de servicio y sesión pueden trasladarse, qué evento habilita el cambio, quién emite la indicación y qué prueba se exige antes de redirigir paquetes. Una petición independiente no debería heredar por defecto las mismas condiciones que una transacción cuya siguiente etapa depende del nodo actual.

Si no hay señal explícita, una política prudente es conservar la afinidad de las sesiones activas hasta que la aplicación coordine su migración, o reservar la reorientación para nuevas solicitudes. Es una recomendación operativa, no un requisito adicional de la RFC. Su ventaja es simple: evita presentar una mejora de utilización como garantía de continuidad.

Fuentes y estatus