Resumen
- Los niveles EXCELLENT, GOOD, FAIR, BAD y NONE dependen del hardware, el software y sus umbrales. RFC 5184 advierte que decidir con ellos puede ser erróneo y no garantiza el enlace óptimo.
- El expediente de un traspaso debe preservar la medición original, la decisión, el Ack que inicia la operación, el evento LinkUp, la convergencia IP y el tráfico observado.
Dos interfaces ofrecían un punto de acceso con la etiqueta EXCELLENT. El planificador las trató como equivalentes y eligió la que parecía tener más margen. Una etiqueta provenía de RSSI amortiguado; la otra combinaba reintentos, tasa y una ventana distinta. El nombre coincidía. La escala no.
RFC 5184 crea precisamente una abstracción para que L3 no dependa de cada tecnología. Pero también dice que los niveles de un dispositivo son independientes de los de otros y que las decisiones basadas en esas métricas son propensas a errores. La abstracción coordina; no calibra el mundo.
Tres usos, no un único veredicto
Las nueve primitivas se reparten en tres tipos. Tipo 1 solicita información actual y recibe Confirm: estado del enlace o lista de PoA. Tipo 2 registra eventos y después recibe Indication: PoA encontrado o perdido, LinkUp, LinkDown o cambio de estado. Tipo 3 solicita una acción: conectar o desconectar.
Request, Confirm, Indication y Response conservan el orden. En una acción tipo 3, Ack o Nack vuelve inmediatamente. L2-LinkConnect comienza después del Ack. El documento no dice que ese Confirm sea el final de la asociación, mucho menos de la configuración IP.
Un sistema que mezcla lectura, evento y acción en un solo campo “estado” pierde la naturaleza de la evidencia. Un PoA en la lista no es un PoA autenticado. Un umbral cruzado no es una decisión obligatoria. Un Ack no es un LinkUp.
La escala abstracta necesita su ficha técnica
Condition combina ancho de banda disponible y calidad. El algoritmo queda a la implementación. Para que EXCELLENT sea auditable, el registro debe incluir dispositivo, controlador, firmware, señales originales, promedio, duración, histéresis y tabla de conversión.
Sin esa ficha, una actualización puede cambiar el significado manteniendo el texto. El algoritmo también puede perder contexto: interferencia asimétrica, carga del punto de acceso, autenticación pendiente o cuello de botella aguas arriba.
Por eso RFC 5184 no promete elección óptima. La decisión pertenece a una política local que puede ponderar identidad, coste, energía, seguridad y servicio además de radio.
Las indicaciones rápidas también se equivocan rápido
El documento observó traspasos ping-pong y reconoce que umbrales mal configurados producen indicaciones engañosas. L2-LinkStatusChanged puede ser poco fiable porque abstraer calidad es difícil; una señal inválida puede provocar un movimiento redundante.
La recuperación forma parte del diseño. L3 puede consultar de nuevo L2-LinkStatus y cancelar si el acceso actual sigue siendo el más adecuado. RFC 4907 recomienda tratar las indicaciones como pistas y validarlas, no como disparadores con autoridad automática.
Un sistema estable separa sensibilidad y compromiso. Puede iniciar preparación con un umbral temprano sin cortar el camino actual. Solo avanza al commit después de comprobar las condiciones que importan para ese servicio.
La aceptación de la orden abre otra fase
El enlace elegido recibe L2-LinkConnect.request. Confirm/Ack indica que la petición es válida y que comienza la operación. Más tarde llega LinkUp al terminar el traspaso L2. Luego L3 configura o valida dirección, router y binding. Finalmente, el tráfico demuestra continuidad.
Incluso LinkUp depende de la tecnología. En el ejemplo Wi-Fi de RFC 5184 corresponde a asociación. RFC 4957 muestra que en Ethernet una señal física positiva no prueba que un puente ya reenvíe tramas. RFC 4907 insiste en que LinkUp no certifica condiciones simétricas ni baja pérdida.
La palabra “completado” solo puede aparecer acompañada de su capa: comando aceptado, enlace asociado, IP preparado o servicio verificado.
Un PoA detectado puede ser una observación adversaria
El RFC explica que balizas falsificadas de un punto malicioso pueden producir PoAFound y llevar al móvil a pedir conexión. Alternar RSSI fuerte y débil puede generar PoAFound y PoALost repetidamente hasta degradar el servicio.
La defensa no consiste en eliminar las indicaciones. Consiste en restringir su autoridad: autenticar el enlace, registrar procedencia, amortiguar oscilaciones, limitar tasa y validar reachability. La etiqueta de calidad aporta información; la política decide qué puede autorizar.
El resultado experimental tiene coordenadas
La evaluación informa cero o una respuesta ICMP perdida con sondeos cada diez milisegundos en un montaje concreto. Convertir ese dato en SLA exige más que copiar la cifra. Hay que conservar radio, controlador, seguridad, movilidad, carga y definición de pérdida.
RFC 5568 separa además latencia de operaciones IP y latencia de conmutación del enlace. Preparar un túnel no garantiza la recepción inmediata tras conectar: el nuevo router todavía debe detectar al nodo.
El control profesional mide distribuciones por tramo: señal a decisión, decisión a Ack, Ack a LinkUp, LinkUp a IP listo e IP listo a primer intercambio bidireccional. Esa serie permite ver qué cambió sin pedir a EXCELLENT que explique todo.
Un contrato local para transferir autoridad
El recibo de traspaso conserva ID de operación, interfaz, PoA, build, señales, umbrales, evento, decisión, Request, Confirm, autenticación, LinkUp, configuración L3, paquetes, cancelaciones y estado final. Los huecos se registran como huecos.
Así se aplica la separación de capas de realidad: el símbolo normalizado no sustituye al código que corre ni a la consecuencia observada. RFC 5184 permite una especificación inicial pequeña y adopción voluntaria. La organización completa localmente la confianza sin fingir que la etiqueta común ya la contiene.
Fuentes
- RFC 5184 — HTML
- RFC 5184 — texto sin formato
- Página informativa de RFC Editor
- Documento en IETF Datatracker
- Historial en IETF Datatracker
- Referencias en IETF Datatracker
- Erratas de RFC 5184
- RFC 4907 — implicaciones de las indicaciones de enlace
- Página informativa de RFC 4907
- RFC 4957 — notificaciones L2
- RFC 5568 — traspasos rápidos de Mobile IPv6
- Página informativa de RFC 5568
- RFC 5944 — movilidad IPv4
- RFC 6275 — movilidad IPv6
- RFC 4140 — movilidad IPv6 jerárquica
- RFC 3819 — consejos para diseñadores de subredes
- RFC 4968 — análisis de modelos de enlace IPv6
- Heng Lu — capas de realidad
- Heng Lu — especificación mínima y adopción voluntaria
- Heng Lu — primacía del código en ejecución
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance