Resumen

  • RFC 2353 utilizó UDP/IP como control de enlace nativo para APPN/HPR; el RTP de HPR aportaba recuperación y orden, mientras LDLC detectaba la vida del enlace.
  • Al suspender pruebas durante la inactividad, un nodo podía borrar un enlace fallido y el vecino conservarlo como activo.
  • Una reactivación podía recibir un código de enlace paralelo no admitido, aunque en realidad intentara sustituir estado obsoleto. El código explicaba el rechazo local; la recuperación debía consultar el enlace.

Los códigos de error son atractivos porque parecen comprimir una historia. “Ya existe un enlace” suena concluyente. Sin embargo, en RFC 2353, esa frase podía ser la huella de una observación ausente: el nodo que rechazaba la reactivación aún no había descubierto que su enlace antiguo había muerto.

El RFC de mayo de 1998 describió APPN/HPR en redes IP. Era Informational, no una norma de Internet, y registraba una arquitectura aprobada como “Closed Pages” por el APPN Implementers’ Workshop en diciembre de 1997. El nivel indicaba detalle para interoperabilidad en ese marco, no adopción universal.

La propuesta trataba IP como un control de enlace nativo para HPR, conservaba clases de servicio y permitía redes de conexión sin definir por anticipado cada enlace. Para ello eligió UDP en vez de TCP.

La ausencia de conexión era parte del diseño

RFC 768 define un servicio mínimo de datagramas. RFC 791 define el transporte de datagramas IPv4 por la interred. Ninguno mantiene el estado de conexión que HPR necesitaba para su propia arquitectura.

RFC 2353 asignó la pérdida, duplicación, demora, desorden y pérdida de conectividad a capas superiores. El RTP de HPR —distinto del protocolo de transporte en tiempo real de la IETF— realizaba retransmisión selectiva, reordenamiento y control adaptativo. LDLC mantenía el control lógico y las pruebas de vida. TCP habría duplicado colas, temporizadores y bloques de control.

La consecuencia era una cadena de recibos. UDP/IP observaba datagramas. RTP observaba recuperación extremo a extremo. LDLC observaba una instancia de enlace. Ningún recibo contenía por sí solo la memoria del vecino.

Dos nodos, dos tiempos de fallo

UDP no notificaba la caída de una conexión, por lo que LDLC debía enviar pruebas periódicas. El RFC mostraba valores predeterminados de diez segundos para vida, quince para reintento y tres intentos.

La opción de no sondear un enlace inactivo reducía tráfico y podía permitir que instalaciones inferiores descansaran. También podía hacer que una parte detectara el fallo mucho antes que la otra. El primer nodo desactivaba su instancia. El segundo, sin tráfico ni aviso, seguía marcándola activa.

Cuando el primer nodo intentaba reactivar, el segundo podía interpretar la solicitud como un segundo enlace definido o dinámico entre los mismos puertos y responder con los códigos X'10160045' o X'10160046'. Desde su base local, el rechazo era coherente. Desde la historia del solicitante, era una recuperación necesaria.

El flujo inverso era igual de peligroso. El nodo que ignoraba la falla podía enviar datos o una activación de sesión por el enlace antiguo. El par, que ya lo había desactivado, podía descartar el tráfico.

El error activaba una comprobación, no un veredicto

El RFC pedía que un rechazo por enlace paralelo disparara pruebas de vida sobre los enlaces activos relacionados, especialmente con la misma pareja de direcciones IP y distintas parejas SAP. El objetivo era descubrir estado viejo.

Si llegaba una activación con la misma pareja IP y SAP que una instancia activa, el receptor debía desactivar la instancia y permitir que se restableciera, usando un temporizador para limitar mensajes XID extraviados. También recomendaba intentar reactivación antes de actuar definitivamente sobre un fallo detectado por LDLC.

El sentido del código quedaba así delimitado. Indicaba por qué el nodo local no aceptó una transición. No demostraba quién perdió primero la conectividad, si el otro nodo había procesado datos ni si una sesión llegó a su resultado.

Fiabilidad, vida y sesión no eran sinónimos

RTP podía proporcionar entrega ordenada y recuperación dentro de su alcance sin eliminar la divergencia de los autómatas de enlace. Una prueba LDLC exitosa podía confirmar una instancia sin confirmar una sesión APPN. Un código de activación podía llegar a la unidad primaria sin contar toda la secuencia remota.

La seguridad estaba separada: autenticación y cifrado de sesión SNA, IPsec para datagramas y filtros de cortafuegos. Proteger el paquete no armonizaba los recuerdos del enlace.

La ficha del RFC Editor y el historial del Datatracker prueban estatus documental, no uso actual. RFC 1122 aporta requisitos de host citados, no una autoridad sobre el estado HPR.

La primacía del código en ejecución de Lu Heng obliga a comprobar qué acepta el par, no qué afirma un registro local. La especificación mínima con decisión local favorece transiciones verificables. Las capas de realidad separan datagrama, vida, enlace, sesión y resultado.

RFC 2353 enseñó que un código preciso puede ser evidencia limitada. La respuesta correcta ante dos historias no era coronar una, sino volver a probar el estado compartido.