Resumen

  • RFC 1307 fue un protocolo Experimental de marzo de 1992 para controlar enlaces conmutados bajo demanda: el transporte expresaba la necesidad y un controlador separado ejecutaba detalles físicos y administrativos.
  • El proveedor veía una interfaz binaria, up o down; DSLCP mantenía Down, Coming Up, Up, Going Down, Bring Down y Bring Up para ordenar operaciones pendientes e intenciones invertidas.
  • Una liberación en Up hacía enviar el desmontaje y notificar inmediatamente down, y DSLCP siempre contestaba éxito a la liberación del proveedor aunque el controlador aún no hubiese confirmado.
  • Retransmisiones, duplicados y reordenamiento podían volver obsoleta una respuesta auténtica. Una transacción desconocida permitía continuar como si hubiera éxito, sin probar el estado físico ni sus consecuencias económicas o de datos.

El precio de esperar con el enlace encendido

La motivación era económica antes que semántica. Los enlaces conmutados por circuito permanecían desconectados normalmente porque sostenerlos activos resultaba costoso. El proveedor de transporte tenía una ventaja: podía reconocer el inicio y el fin de una sesión. Por eso era el lugar adecuado para pedir que el enlace subiera cuando aparecía demanda y que bajara cuando desaparecía.

No se le encargaba, sin embargo, accionar el equipo. Un controlador de enlace distinto conocía los detalles de hardware y administración. DSLCP, nacido en un proyecto de Cray Research, mediaba entre ambos. Su propósito era controlar enlaces aguas abajo conocidos por el host sin exponer al proveedor todas las diferencias de los mecanismos de conmutación.

El documento se publicó en marzo de 1992 para investigación adicional. Su categoría Experimental importa: describe una arquitectura y sus reglas, no certifica una práctica presente ni una instalación particular. Lo que permite estudiar es la manera en que una interfaz económica y simple puede adelantarse a la realidad que coordina.

Preparar un camino exigía disponer de otro

Antes de iniciar una transacción DSLCP debía existir conectividad entre el host y el controlador. Las órdenes podían viajar como datagramas IP o UDP y el protocolo no exigía transporte fiable. El canal de control, por tanto, no era el enlace de datos que se intentaba crear. Tenía que precederlo.

Esta dependencia separaba varios hechos. El usuario de transporte solicitaba conectar o liberar. El proveedor decidía según sus sesiones activas. DSLCP enviaba una función al controlador. El controlador mantenía —o no— un registro de transacción y actuaba sobre su dominio. El circuito físico, los datos y la aplicación quedaban después. Ver el primer mensaje no demostraba el último resultado.

El formato ayudaba a conservar la unión. Incluía un identificador de 16 bits, dos direcciones de extremo de 32 bits, función, estado de evento y un cuerpo con significado para el controlador. La transacción se reconocía por el identificador junto con los dos extremos. Un número repetido fuera de esa combinación no nombraba globalmente un circuito ni una sesión.

También el estado del evento era relativo: describía el enlace respecto de la última función solicitada. Había resultados de establecimiento y desmontaje, además de un aviso asíncrono de red caída. Una palabra como “éxito” sin función anterior, extremos, identificador y momento perdía el marco que la hacía interpretable.

La interfaz binaria era una decisión de reparto

RFC 1307 pedía al proveedor que no siguiera el estado detallado del enlace. DSLCP era responsable de hacerlo y podía incluso efectuar redirección u otros procesos que el proveedor no veía. La división evitaba que dos componentes intentaran gobernar la misma máquina de estados.

Al proveedor le bastaban up y down. DSLCP necesitaba seis posiciones. Down y Up eran los polos. Coming Up y Going Down indicaban una orden pendiente. Bring Down y Bring Up retenían la última intención cuando esta se oponía a la operación que ya estaba en vuelo.

Supóngase una petición de liberación mientras el establecimiento espera respuesta. DSLCP pasa a Bring Down. Cuando por fin llega el éxito de establecimiento, no presenta una victoria antigua como estado vigente: envía desmontaje y entra en Going Down. El caso inverso ocurre cuando aparece una nueva conexión durante el desmontaje. Bring Up espera la bajada y luego solicita de nuevo la subida.

La máquina no cancelaba el pasado; lo compensaba. En una misma fracción de tiempo, la intención actual podía ser subir, la función pendiente podía estar bajando y el proveedor podía ver down. Las seis posiciones guardaban esas diferencias para que el consumidor de dos estados no tuviera que resolverlas.

La asimetría protegía al proveedor

El protocolo no trataba igual el establecimiento y el desmontaje. DSLCP informaba al proveedor si una solicitud concreta de subida había tenido éxito o había fallado. En cambio, el proveedor podía asumir que la liberación siempre funcionaba porque DSLCP respondía éxito a todas sus solicitudes de desmontaje.

Desde Up, una liberación provocaba tres pasos con relojes distintos: enviar bring down al controlador, pasar internamente a Going Down y decir enseguida al proveedor que el enlace estaba down. El tercer paso no esperaba una respuesta material. Cerraba el significado local de la sesión mientras la acción de control seguía abierta.

La regla evitaba que el proveedor quedara atrapado en fallos y peculiaridades del controlador. Pero el recibo no enumeraba contactos abiertos, energía retirada ni recursos reasignados. Tampoco demostraba que hubiera cesado un cargo. Todas esas conclusiones pertenecían a otros sistemas y observaciones.

El paquete tardío traía una respuesta a la pregunta anterior

Al no depender de transporte fiable, DSLCP debía manejar temporizadores y retransmisiones. En el entorno de los autores se usaban cinco segundos y tres reintentos, valores que el texto consideraba adaptables. Una petición repetida podía producir varias respuestas. La red podía cambiar su orden.

Por eso una respuesta correcta no siempre describía la intención actual. Si llegaba éxito de establecimiento mientras DSLCP estaba Down, RFC 1307 lo interpretaba como posible efecto de duplicación o reordenamiento y enviaba desmontaje compensatorio. En Bring Down, el mismo éxito llevaba igualmente a Going Down y a una orden de bajar. El éxito no era falso; había perdido vigencia operacional.

Otra inversión era más inquietante. Si llegaba éxito de desmontaje mientras DSLCP figuraba Up, alguna desincronización había ocurrido. La recomendación conservadora era bajar la conexión y recuperar sincronía, aunque el documento admitía que ignorar el mensaje podría resultar satisfactorio. Esa alternativa declarada impide convertir el evento inesperado en una reconstrucción única del circuito.

«No conozco esa transacción» tampoco reconstruía el pasado

En Up, una respuesta de desmontaje fallido significaba que se había enviado una solicitud para una transacción inválida: el controlador no tenía un registro que combinara identificador y extremos. DSLCP debía continuar como si la solicitud hubiera tenido éxito.

La instrucción era una política de convergencia. El host podía cerrar su lado sin resolver por qué faltaba el registro. Quizá el controlador hubiese olvidado la transacción; quizá la hubiera completado antes; quizá nunca hubiese creado esa combinación. RFC 1307 no elegía entre esos relatos y no autorizaba a llamar “acuerdo del controlador” al silencio de su tabla.

El aviso asíncrono de red caída ocupaba otra categoría. Podía llevar a DSLCP desde Coming Up, Bring Up o Up hasta Down, seguido de notificación al proveedor. No nacía de una liberación del host y no era una confirmación ordinaria de desmontaje. Conservar su origen impedía atribuir el evento a la intención equivocada.

La sección de seguridad decía que estos asuntos no se discutían. Por eso direcciones, cadenas y respuestas del protocolo no demuestran autenticación, autorización, integridad ni confidencialidad. El formato identifica una conversación técnica dentro de su diseño; no aporta garantías que la fuente dejó fuera.

Fuente y límites de la evidencia

El análisis utiliza únicamente RFC 1307 — Dynamically Switched Link Control Protocol, de marzo de 1992. Esta historia trata la interfaz de dos estados sobre seis estados internos, las inversiones y la convergencia local. No repite el mecanismo del artículo RFC 1306, centrado en búsqueda de ruta, activación externa, regla de no enviar datos hasta completar el circuito, alias de ruta y un temporizador independiente antes del primer byte. RFC 1307 no prueba controlador, enlace, mensaje, sesión, capacidad, cobro, transferencia ni resultado real.