Resumen

  • La RFC 1434 terminaba LLC Type 2 en cada Data Link Switch, de modo que los dos terminales mantenían enlaces locales independientes y no una única sesión de enlace extendida por la WAN.
  • SSP todavía debía descubrir la estación, intercambiar dos Circuit ID de significado local y completar CONTACT/CONTACTED; que TCP estuviera conectado no demostraba esos estados.
  • La terminación local evitaba que el retardo variable alterara los temporizadores de LAN, pero el transporte multiplexado concentraba el riesgo: su caída derribaba todos los circuitos asociados.

El temporizador pertenecía al recinto local

LLC Type 2 partía de una expectativa sencilla: en una LAN, el tiempo de tránsito debía ser breve y bastante predecible. Un temporizador fijo podía interpretar una espera excesiva como pérdida. Al atravesar enlaces extensos lentos o congestionados, la variación de demora convertía esa regla en una fuente de errores. Una trama tardía parecía perdida, comenzaban retransmisiones innecesarias y el procedimiento podía acabar cerrando la conexión.

Data Link Switching no intentó fingir que la WAN tenía el reloj de una LAN. Desplazó el punto de terminación. El terminal de un extremo hablaba LLC Type 2 con su conmutador cercano. El terminal del otro extremo mantenía otra conexión LLC con su propio conmutador. Las dos conexiones eran, en palabras de la RFC, totalmente independientes. Entre los Data Link Switches, SSP retransmitía la información mediante un transporte fiable.

Así, los acuses y temporizadores LLC no cruzaban la WAN. El sondeo SDLC también podía resolverse localmente. Cada conmutador absorbía los reintentos adecuados a su enlace adyacente y aplicaba contrapresión al terminal sin obligar al extremo opuesto a seguir la cadencia de un medio distinto.

La ventaja tenía una consecuencia semántica. RR o UA ya no significaban que el terminal lejano hubiese recibido algo. Significaban que el conmutador local aceptaba una responsabilidad en el enlace inmediato. La sesión aparente estaba formada por promesas sucesivas: dos enlaces locales, un circuito SSP, un transporte entre pares y, más allá, el comportamiento de la aplicación.

El socket común no era la sesión del usuario

Antes de activar DLS entre dos routers, estos debían establecer una conexión de transporte. La implementación inicial de SSP utilizaba TCP, aunque el texto permitía imaginar otro transporte fiable. Solo después, SSP establecía circuitos DLS sobre esa conexión. Muchos circuitos podían viajar multiplexados en el mismo flujo.

La secuencia impedía usar “TCP conectado” como sinónimo de “terminal conectado”. El socket solo demostraba una asociación entre dos conmutadores. Todavía podía faltar la localización de la estación, la selección del par capaz de alcanzarla, la pareja de identificadores o el contacto del enlace remoto. La luz verde de una capa no heredaba la autoridad de las demás.

La RFC separaba el nombre de la relación buscada y el identificador de su instancia. El Data Link ID reunía las direcciones MAC y SAP de ambos terminales. Cada DLS asignaba además un Circuit ID de 64 bits, formado por un DLC Port ID y un Data Link Correlator. El circuito de extremo a extremo se reconocía por la pareja de Circuit ID, y cada conmutador debía mantener la correspondencia local-remota.

Antes de formar esa pareja, los mensajes necesitaban el Data Link ID completo. Tras el establecimiento, INFOFRAME podía usar una cabecera breve con el identificador del DLS remoto. La reducción de cabecera no eliminaba contexto: lo trasladaba a una tabla. Un número aislado, sin el conmutador que lo asignó y sin su pareja, no permite unir dos registros operativos.

Una pregunta, varias respuestas y una elección

SSP formulaba el descubrimiento como conversación. CANUREACH preguntaba quién podía alcanzar la estación. ICANREACH respondía afirmativamente e incluía el Circuit ID del destino. REACH_ACK devolvía el Circuit ID del origen. Después, CONTACT y CONTACTED avanzaban el contacto con la estación remota.

Cada mensaje cerraba una incertidumbre distinta. La vida del par de transporte no daba ubicación. La ubicación positiva no completaba la pareja de identificadores. El circuito identificado no garantizaba que el enlace local lejano hubiese aceptado el contacto. Saltarse una transición hacía imposible ubicar un fallo.

Podían llegar varios ICANREACH. El DLS de origen elegía el primero y enviaba REACH_ACK al conmutador seleccionado. La ubicación efectiva era, por tanto, el resultado temporal de una búsqueda, no una propiedad eterna y única. Para reconstruirla hacen falta todas las respuestas, su orden y la decisión posterior.

Las cachés reducían el coste de preguntar. Sin una localización conocida, CANUREACH o determinadas consultas NetBIOS podían difundirse a todos los pares DLS conocidos. Una entrada fresca evitaba exploración; una entrada vieja dirigía nuevos intentos a un lugar que quizá ya no servía. La procedencia y vigencia de la caché eran parte del circuito.

El borde podía aceptar antes que el destino

La independencia quedaba expuesta al iniciar LLC. Tras recibir SABME del terminal local, el DLS de origen podía responder UA sin haber contactado aún con el terminal remoto. Para que el emisor no se adelantara, contestaba localmente con RNR. Cuando llegaba CONTACTED desde el otro conmutador, RR permitía reanudar el envío.

UA no inventaba una aceptación remota. Marcaba que el conmutador había asumido el enlace local. RNR conservaba la duda sobre el tramo restante. El problema aparece cuando una consola combina ambos hechos con la respuesta de la aplicación y los presenta como un único estado “arriba”.

Hay que distinguir al menos el circuito SSP, el contacto remoto, el permiso de envío local y el intercambio de aplicación. Incluso si TCP entrega los bytes al conmutador distante de forma ordenada, la LLC de ese lado puede estar reintentando o cerrándose, y el programa final puede no haber actuado.

La RFC 1795 hizo más visible otra separación mediante su ritmo adaptativo. Después de intercambiar capacidades, cada sentido de cada circuito tenía control de flujo propio. El emisor empezaba sin unidades concedidas y esperaba una autorización FCIND. Esa función es de la revisión de 1995, no de la RFC 1434, pero demuestra por qué la fiabilidad del transporte no bastaba para regular la entrada de cada circuito.

La economía de conexiones produjo destino compartido

Mantener los acuses cerca del terminal ahorraba tráfico WAN. Multiplexar muchos circuitos evitaba abrir un transporte por cada pareja. A cambio, sesiones lógicamente independientes quedaban sujetas a una misma dependencia central.

La RFC 1434 establecía que, si fallaba la conexión TCP entre los dos DLS, se derribaban todas las conexiones multiplexadas sobre ella. Ambos conmutadores enviaban DISC a todos los sistemas locales afectados. Un terminal podía conservar cable, puerto y estado físico correctos y aun así ver desaparecer su sesión por una rotura en el medio compartido.

Diez desconexiones coincidentes podían tener una sola causa TCP. Tratarlas como diez fallos raíces distorsionaba el diagnóstico. Registrar solo una alarma de transporte ocultaba el alcance. La representación correcta contiene una causa común, la lista de circuitos dependientes, los dos enlaces locales por circuito y los efectos finales.

También existía desconexión individual. HALT_DL solicitaba detener el enlace y DL_HALTED confirmaba el resultado; un error DLC local podía llevar un circuito hacia el cierre. El mismo síntoma del terminal tenía varias procedencias. Importaba conservar la primera transición y no clasificar por el último estado visible.

De protocolo a superficie de operación

La RFC 1795 declaró cambios importantes y sustituyó a la RFC 1434. El grupo DLSw del APPN Implementers Workshop buscaba una versión de SSP interoperable entre proveedores y corregía problemas de documentación. Añadió un intercambio inicial de capacidades después del transporte y antes del control ordinario de circuitos, además de la negociación del transporte y el ritmo adaptativo.

La RFC 2024 convirtió esas fronteras en objetos administrables. Un transporte podía estar conectando, intercambiando capacidades iniciales, conectado, entrando en reposo, desconectándose o desconectado. Había contadores para exploraciones y circuitos, además de motivos de cierre. Operar DLSw exigía observar más que un socket.

La RFC 2166 describió las presiones al crecer: configurar muchos pares, replicar búsquedas y tráfico NetBIOS por conexiones punto a punto, mantener transportes y terminar gran cantidad de LLC2 en un nodo central. DLSw v2.0 añadió motivos de HALT, descubrimiento con multicast, conexiones bajo demanda y una única TCP bidireccional cuando ambos pares podían usarla.

No son funciones que deban atribuirse retrospectivamente a 1993. Su aparición muestra que mover el estado hacia los conmutadores resolvió una incompatibilidad temporal, pero generó necesidades nuevas de negociación, observación y escala.

La evidencia termina después del circuito

Un registro completo enlaza el par de transporte y su estado, el Data Link ID buscado, todas las respuestas de alcance, el par elegido, ambos Circuit ID, CONTACT/CONTACTED, los DLC adyacentes, el crédito de envío, los contadores de datos y la primera causa de cierre. Después necesita evidencia de la aplicación, que no se deduce de ninguna transición anterior.

Tanto la RFC 1434 como la RFC 1795 dicen que no tratan las cuestiones de seguridad. Por sí solas no prueban autenticación de pares, autorización de terminales, confidencialidad ni integridad frente a un adversario. La entrega fiable de TCP dentro del modelo no es una garantía de seguridad.

Tampoco prueban adopción, despliegue presente o incidentes de una red concreta. Su valor histórico reside en hacer visible una disciplina: una experiencia de extremo a extremo puede construirse con contratos locales, pero cada contrato conserva alcance, dueño y forma de fallo propios.

Fuentes