Rápido, fluido y sin cortes: RFC 3753 separó tres sentidos de handover

Resumen

• RFC 3753 describió el handover como una familia de situaciones, no como una única operación evidente. Propuso cinco formas, en buena parte independientes, de caracterizar quién controla el proceso y cuándo ocurre.
• «Rápido», «fluido» y «sin cortes» no prometían lo mismo: el primero priorizaba la latencia, el segundo las pérdidas y el tercero dependía del servicio y del usuario que pudieran notar un cambio.

Un handover necesitaba más de un adjetivo

Un teléfono pasa de un punto de acceso a otro. Cambia la conexión radioeléctrica. El router puede cambiar o seguir siendo el mismo. La red puede preparar la ruta antes del desplazamiento o reaccionar después. El móvil puede elegir el momento, aportar mediciones o limitarse a seguir una decisión de la red. Los paquetes pueden demorarse, perderse o viajar por una ruta con propiedades de seguridad distintas a las anteriores.

Llamar a todo «handover» resulta cómodo hasta que toca comparar dos diseños. Para una persona es el salto entre puntos de acceso de capa 2; para otra, un nuevo acceso IP. Un equipo puede llamar «rápido» a un traspaso porque el tráfico se reanuda enseguida, aunque la aplicación haya perdido paquetes. Un panel puede mostrar «sin cortes» aunque haya cambiado la seguridad de una forma importante para el usuario.

RFC 3753, Mobility Related Terminology, intentó que esas conversaciones fueran más precisas. Publicado en junio de 2004 como RFC Informacional, surgió del grupo de trabajo Seamoby de la IETF, cuyo cometido reunía transferencia de contexto, descubrimiento de routers candidatos y alertas para hosts en modo dormido. Sus autores esperaban que otros grupos de movilidad aprovecharan los términos. También aclararon que el documento no pretendía acuñar una terminología nueva ni cerrar todas las definiciones. Era un primer esfuerzo colaborativo, abierto a debate y correcciones. RFC 3753, resumen y §1

Ese alcance modesto forma parte de su historia. La RFC ofrecía un sistema común de coordenadas; no normalizaba un procedimiento de traspaso, no obligaba a las implementaciones a usar todas las etiquetas ni probaba que los grupos de trabajo aplicaran el glosario de forma uniforme.

Cinco preguntas de control, no un único «tipo de handover»

RFC 3753 decía que cinco clasificaciones eran «en gran medida independientes» y que cada handover debía poder describirse en cada una. Eran dimensiones descriptivas, no cinco protocolos que compitieran entre sí.

Pregunta	Distinción de RFC 3753
¿Quién toma la decisión inicial?	El móvil o la red inicia el traspaso
¿Quién conserva el control principal?	Control del móvil o de la red
¿Quién aporta las mediciones útiles?	Asistencia del móvil, de la red o ninguna
¿Desde qué lado se prepara el cambio?	Push a través del router anterior o pull a través del nuevo
¿Era posible señalizar por adelantado?	Handover planificado o no planificado

Es fácil mezclar las dos primeras preguntas; conviene mantenerlas separadas. El móvil puede decidir primero y, aun así, la red conservar el control principal de la ejecución. La tercera distinción se refiere a las mediciones: las del móvil pueden ayudar al router de acceso a decidir; la red de acceso puede recopilar información para que la use el móvil; o ninguno puede asistir al otro. La RFC contempla incluso que ambos midan y decidan.

Push y pull describen otra relación: si la preparación la inicia o canaliza el router de acceso anterior (PAR) o el nuevo (NAR). Planificado y no planificado se refieren a si puede haber señalización antes de que el móvil se conecte al nuevo router. Un movimiento previsto puede permitir preparar un túnel temporal; uno inesperado no tiene ese intercambio previo.

Cada etiqueta responde a algo distinto. «Iniciado por la red» no indica quién controla el proceso. «Asistido por el móvil» no revela qué router inicia la preparación. «Planificado» tampoco significa que el cambio vaya a funcionar. Las cinco dimensiones evitan reducir a una sola palabra quién decide, quién controla, de dónde procede la información, en qué dirección circula la señalización y cuándo se intercambia. RFC 3753, §4.2

Por separado, la RFC clasificaba el alcance del movimiento: capa 2, dentro de un router de acceso, dentro de una red de acceso, entre redes o entre tecnologías. También distinguía handovers horizontales y verticales, pero reconocía que la frontera podía ser ambigua. Cambiar entre dos tipos de WLAN podía describirse de cualquiera de las dos formas según la perspectiva; un mismo router podía gestionar varias tecnologías de acceso sin que cambiaran la dirección IP o la interfaz. La taxonomía no exigía que el mapa de radio y el mapa IP compartieran límites. RFC 3753, §4.1

Rápido, fluido y sin cortes no miden lo mismo

La distinción más duradera está en el vocabulario de rendimiento. RFC 3753 definió la latencia del handover como un intervalo: desde el último momento en que el móvil podía enviar o recibir un paquete IP por el PAR hasta el primero en que podía hacerlo por el NAR. Es un límite de medición de red, no una medida completa de la experiencia de una aplicación.

Un handover «fluido» tenía como objetivo principal reducir la pérdida de paquetes, sin preocuparse expresamente por un retraso adicional de reenvío. Un handover «rápido» priorizaba reducir la latencia, sin tener la pérdida de paquetes como interés explícito. Eso no significa que un handover rápido necesariamente pierda paquetes ni que uno fluido tenga que ser lento. Significa que los términos nombran prioridades distintas; para comparar resultados todavía hay que medir tanto las pérdidas como el retraso.

«Sin cortes» va más allá, pero depende del contexto. La RFC lo describía como la ausencia de cambios en la capacidad del servicio, la seguridad o la calidad. Para juzgarlo en la práctica, proponía preguntarse si otros protocolos, aplicaciones o usuarios notarían un cambio relevante para su funcionamiento habitual. Un cambio invisible para el correo puede no serlo en una llamada sensible a la latencia. Una sesión que sobrevive a una degradación de seguridad no cumple toda esa definición solo porque sigan pasando paquetes.

El documento también diferenciaba make-before-break y break-before-make: ¿podía el móvil comunicarse a la vez con los routers antiguo y nuevo, o terminaba primero la conexión anterior? Advertía que make-before-break no debía confundirse con «soft handover», que se apoya en la macrodiversidad. Solapamiento, pérdida, retraso y continuidad perceptible están relacionados, pero no son mediciones intercambiables. RFC 3753, §§4.3–4.5

Un glosario no certifica el rendimiento

RFC 3753 convivía con trabajos prácticos sobre movilidad. Entre sus referencias estaban Mobile IPv4, la especificación Mobile IPv6 entonces vigente y documentos de trabajo sobre handover rápido y descubrimiento de routers candidatos. Una RFC posterior de estándares, RFC 5568, especificó los handovers rápidos de Mobile IPv6. RFC 6275 reemplazó después RFC 3775 y citó RFC 3753 como referencia informativa. Esta cronología muestra una conversación documental continuada; no demuestra que otro protocolo adoptara el glosario como prueba de conformidad ni que un operador lo desplegara. RFC 5568 · RFC 6275

El límite importa especialmente porque RFC 3753 dice que solo presenta terminología y no señala problemas de seguridad en el documento. Eso no es una evaluación de seguridad de los sistemas de movilidad. Tampoco prueba que un handover específico fuera rápido, fluido, seguro o sin cortes. El texto aporta distinciones para hacer mejores preguntas; las pruebas tienen que proceder de la implementación, las mediciones y el servicio afectado.

La aportación de 2004 fue menos un protocolo nuevo que un intento de impedir que varios niveles de significado se confundieran. Un cambio podía describirse por su alcance, quién lo iniciaba y controlaba, de dónde venían las mediciones, qué router lo preparaba y si era posible señalizar antes. Después se podían medir por separado latencia y pérdidas, dejando que la continuidad dependiera del servicio y del usuario.

La lección histórica para los estándares es concreta: compartir vocabulario facilita colaborar, pero no elimina las diferencias de control, medición o consecuencia. Una luz verde de «handover completado» solo informa si mantiene visibles esas preguntas.

Fuentes

Registro principal y cronología: texto de RFC 3753, ficha del RFC Editor y registro de IETF Datatracker.

Especificaciones relacionadas y posteriores consultadas para delimitar y comparar: RFC 3132, RFC 3154, RFC 3374, RFC 3344, RFC 3775, RFC 5568, RFC 5213, RFC 5944 y RFC 6275. Aportan contexto, pero no prueban que se adoptara la terminología de RFC 3753.