Resumen

  • RFC 5271 convierte pilotos, SectorID, ANID y datos del acceso 3G CDMA en una ayuda para descubrir el próximo router; el NAR sigue siendo el resultado de una relación topológica vigente, no un dato contenido en la radio.
  • El modo predictivo tiene una fecha de caducidad causal. Un HI posterior al UNA debe rechazarse y tratarse reactivamente, aunque ambos mensajes sean auténticos y estén bien formados.

Un paquete puede ser verdadero y estar fuera de tiempo

En el flujo predictivo, el móvil aún está unido al router anterior cuando envía el Fast Binding Update. El PAR consulta al NAR mediante Handover Initiate, recibe Handover Acknowledge, establece el reenvío y permite que el NAR acumule paquetes. Más tarde cambia el enlace radio, el móvil completa el acceso y anuncia su disponibilidad mediante UNA.

La congestión altera esa narración. El FBU puede haber salido antes del cambio, pero llegar tarde al PAR. El HI resultante alcanza al NAR después de que este ya recibió el UNA. La preparación llega después de la llegada.

RFC 5271 no intenta salvar la etiqueta predictiva. Indica que el NAR debe responder que el traspaso no fue aceptado y comportarse de manera reactiva. Lo esencial no es sólo cuándo se creó el mensaje, sino dónde cae en el orden observado por quien debe actuar.

Los sistemas de auditoría suelen verificar firmas, campos y tiempos por separado. Aquí hace falta algo más sencillo y más difícil: conservar el orden local. Dos filas marcadas como válidas no demuestran que la primera antecedió a la segunda.

Antes del reloj hubo una traducción topológica

La predicción empieza con medidas del canal piloto. El móvil mantiene conjuntos de pilotos, estima la relación portadora-interferencia y comunica candidatos cuando, por ejemplo, otro piloto supera al actual. Es información temprana sobre sectores vecinos.

Un sector con mejor señal puede pertenecer al mismo acceso y no requerir otro router. La red maneja entonces el movimiento internamente. También puede estar detrás de otro PDSN, que en el modelo de RFC 5271 actúa como router de acceso, y obligar a establecer una nueva conexión.

La observación física no contiene esa decisión. El PAR necesita una cartografía administrada que una sector, acceso, PDSN, dirección del NAR y prefijo. Por eso una política que traduzca automáticamente «piloto más fuerte» en «nuevo router» mezcla dos planos.

La rapidez del indicio es útil porque deja tiempo para preparar. No lo convierte en una autoridad sobre la topología.

SectorID y ANID no ocupan el mismo mapa

SectorID tiene 128 bits y puede escribirse con el aspecto de una dirección IPv6. Designa un sector asociado a un desplazamiento del código PN. Su forma no lo convierte en una dirección del router.

ANID combina SID, NID y PZID en cinco octetos administrados por el operador. Describe una región de red de acceso relevante para la reinscripción. Tampoco es un identificador universal de PDSN.

Los conjuntos de pilotos son mediciones con candidatos. La información de celda, los nodos de servicio de la RAN, la ubicación disponible y los datos de subred aportan otras coordenadas. RFC 5271 los reúne como información de asistencia, no como una verdad única.

Para reconstruir una decisión se necesita guardar el valor y su dominio: qué tipo era, qué operador lo administraba, cuándo se observó, con qué generación de la tabla topológica se evaluó y qué alternativas quedaron fuera. Sin esos datos, un caché sólo recuerda una respuesta, no la razón por la que fue correcta.

La opción 29 conserva el indicio

El modelo FMIPv6 genérico espera una dirección de enlace para el nuevo punto de acceso. Esa representación puede no existir en 3G CDMA. RFC 5271 introduce entonces Handover Assist Information, opción de movilidad tipo 29: código 1 para ANID y código 2 para SectorID, además de longitudes explícitas.

Quien no entienda la opción debe tratarla como opaca y no descartar por ello todo el mensaje. La regla protege interoperabilidad y tránsito. No afirma que el receptor pueda asignar significado a los octetos.

Una plataforma puede transportar fielmente un SectorID y consultarlo después contra la tabla de otro dominio o contra una versión anterior al cambio de alojamiento de la celda. La serialización sería perfecta y la decisión estaría equivocada.

El objeto operativo correcto incluye entrada, espacio de nombres, generación de topología, política, candidato, confianza y vencimiento. nar=2001:... sin esa procedencia es una conclusión arrancada de sus premisas.

El indicador R no aprueba este caso

El modo predictivo requiere conocer con suficiente antelación el lugar y el momento del cambio. El reactivo envía el FBU desde el enlace del NAR y es más apropiado cuando la red no puede identificar a tiempo el próximo router.

El bit R de PrRtAdv declara capacidad. Activado significa que la red sólo admite modo reactivo; desactivado, que admite ambos. Que el bit esté limpio no certifica la predicción concreta. Dice que el mecanismo existe, no que esta observación sea fresca ni que la tabla haya elegido bien.

El móvil debe enviar el FBU predictivo antes de cerrar la conexión anterior. Si no lo logra, debe retroceder al modo reactivo. Ese cambio no es un fracaso de servicio que deba ocultarse, sino la forma de preservar el significado del protocolo.

Una métrica que premie la proporción de “predictivos” sin contar correcciones tardías empujará a la organización a conservar autoridad después de que haya expirado.

El NAR es una inferencia del PAR

El móvil envía RtSolPr con los datos de asistencia. El PAR los utiliza para determinar el NAR y devuelve PrRtAdv con su dirección y el prefijo. RFC 5271 expresa que se supone que el PAR puede identificarlo con esa información.

Esa frase no reduce la inferencia a una lectura directa. El PAR es el componente que cruza la evidencia con la realidad operativa. Si el NAR o la NCoA no pueden conocerse a tiempo, la vía reactiva permite continuar sin inventar certeza.

Una buena traza registra los candidatos considerados, la versión del inventario, la regla de selección, el NAR elegido y la caducidad. También conserva el motivo de rechazo. La decisión debe poder deshacerse intelectualmente hasta llegar a sus datos.

Cuando un proveedor sólo expone “descubrimiento NAR: éxito”, el cliente no puede distinguir una observación actual de una asociación almacenada meses antes.

Preparar una dirección no la hace real

Después de identificar al candidato, el móvil puede formar una NCoA anticipada, enviar FBU y provocar la preparación del reenvío. Pero el enlace antiguo todavía existe. A continuación se cierra, se asigna un canal de tráfico y comienza el acceso propio de 3G CDMA.

El ejemplo del RFC incluye PPP LCP, CHAP o PAP, intercambio con AAA, IPv6CP, creación de dirección link-local, Router Advertisement, prefijo, CoA y posiblemente DHCPv6 para datos de arranque. Después llega la actualización de enlace Mobile IPv6 con el agente local.

Incluso el prefijo anticipado puede no ser el definitivo cuando el NAR elige un prefijo por enlace. En ese escenario, el NAR debe asignar la NCoA correcta. La predicción del PAR no la prueba.

Tampoco el búfer demuestra entrega. El NAR puede estar preparado sin que el móvil termine el acceso; el móvil puede estar autenticado sin que reciba los paquetes; la aplicación puede no recuperar continuidad aunque el protocolo de red avance.

El identificador del móvil tiene una finalidad estrecha

Las conexiones punto a punto pueden carecer de la dirección de enlace que esperan ciertos mensajes. La opción Mobile Node Identifier, tipo 30, admite NAI o IMSI para sustituirla donde RFC 5271 lo prevé.

Eso resuelve correlación dentro del contexto del operador. No demuestra que una persona concreta haya aprobado nada, ni que el enlace esté listo, ni que la NCoA pertenezca al móvil. La autenticación CHAP/PAP y la respuesta AAA pertenecen a la fase posterior de acceso.

El IMSI, además, permite correlacionar una trayectoria extensa. Una plataforma de observabilidad no debería copiar el valor bruto a cada evento. Puede conservar una referencia protegida, limitada al propósito, con política de acceso, caducidad y recibo de borrado.

Transformar una clave de correlación de movilidad en identidad permanente para decisiones comerciales sería una expansión de autoridad ajena al protocolo.

El texto histórico necesita dependencias actuales

RFC 5271 fue publicado como Informational en 2008 y se apoyó en RFC 5268 y RFC 3775. RFC 5568 sustituyó a RFC 5268; RFC 6275 sustituyó a RFC 3775. La aplicación actual debe combinar el mapeo tecnológico con las bases vigentes y revisar las asignaciones de IANA.

RFC 4907 aporta una disciplina más general: una indicación de enlace es una pista con semántica, confianza y filtrado específicos. El protocolo consumidor determina si la optimización sigue siendo válida.

Implementar el formato histórico sin conservar la generación de topología o el orden HI/UNA sería cumplir la superficie y perder el mecanismo. El código que se ejecuta, no la casilla de compatibilidad, es el objeto de verificación.

La causalidad también es una credencial

La primacía del código ejecutado de Lu Heng exige describir lo que ocurrió: medición radio, identificador con espacio propio, relación topológica vigente, elección del NAR, modalidad, secuencia local, acceso real, dirección y entrega.

Las capas de realidad evitan que un hecho herede la autoridad del siguiente. La señal no es un router. El router elegido no es el enlace. El identificador del móvil no es una persona. El acceso autenticado no es la recepción de datos. Y un HI auténtico no autoriza preparación predictiva después de UNA.

Por eso el recibo más importante puede ser un rechazo. Demuestra que el sistema permitió que la realidad posterior desautorizara una inferencia anterior.

Fuentes