DLSW – Data Link Switching

Descrito en la RFC 1795, Data Link Switching (DLSW), provee mecanismos de despacho de tramas para los protocolos propietarios de IBM SNA, (System Network Architecture) y NetBIOS, (Network Basic Input Output Services). Utiliza un Protocolo denominado SSP, (Switch to Switch Protocol) para interconectar Data Link Switches. Este protocolo no provee enrutamiento propiamente dicho, solo provee switching a nivel de enlace de SNA, encapsulado sobre TCP/IP para el transporte sobre la Internet.  Como el transporte es sobre TCP el enrutamiento lo provee IP. La implementación inicial de SSP utiliza TCP como Protocolo de transporte confiable entre los Data Link Switches, aunque otros protocolos de transporte podrían ser soportados.

Un Data Link Switch puede soportar sistemas SNA, y sistemas NetBIOS conectados a LAN’s IEEE 802.2 compatibles, así como sistemas SNA conectados a enlaces SDLC, (Sinchronous Data Link Control) de IBM.

DLSW fue desarrollado para soportar SNA y NetBios en Routers multiprotocolo. En función de que tanto SNA como NetBios son protocolos orientados a la conexión, el procedimiento de control de enlace de datos usado sobre la LAN es IEEE 802.2 LLC (Logical Link Control) tipo 2. Además, DLSW también transporta protocolo SNA sobre un enlace de WAN usando el Protocolo SDLC.

LLC tipo 2 (IEEE 802.2) fue diseñado bajo la suposición de que los retardos de tránsito en la LAN son predecibles. Por lo tanto los procedimientos que manejan LLC tipo 2 utilizan temporizadores para detectar las tramas perdidas. Cuando se utiliza Remote Bridging sobre líneas WAN, (en especial a bajas velocidades), el retardo en la red es más grande y puede variar fuertemente en función de la congestión. Cuando el retardo excede el timeout del LLC tipo 2, este intenta retransmitir. Si la trama no se perdió, y tan solo sufrió retardo, los procedimientos LLC tipo 2 probablemente entren en confusión. Esto eventualmente conduciría a que el enlace se caiga ante determinadas relaciones entre el tiempo entre retransmisiones y los timers.

Basado en el uso de servicios LLC tipo 2, DLSW apunta a resolver los siguientes problemas de Bridging:

• DLC time-outs
• DLC ACK sobre la WAN
• Control de flujo y de congestión
• Control de broadcast
• Límite de Conteo de saltos de SRB (Source Route Bridging) (7 hops)

Para NetBIOS se hace uso de servicios de datagrama basados en LLC tipo 1, (no orientado a la conexión). En este caso, apunta a resolver lo siguiente:

• Control de broadcast
• Límite de Conteo de saltos de SRB (Source Route Bridging) (7 hops)

La principal diferencia entre Data Link Switching y Bridging es que, para redes de datos orientadas a la conexión DLSW termina el Data Link Control, mientras que el Bridging no.

En enrutamiento convencional, el "Data Link Control" es del tipo "end to end". Los Data Link Switches concluyen la conexión LLC tipo 2 en el switch. Esto significa que las conexiones LLC tipo 2 no cruzan la WAN. El DLSW multiplexa conexiones LLC sobre una conexión TCP hacia el otro DLSW. Así, las conexiones LLC en cada extremo son totalmente independiente la una de la otra. Es responsabilidad del DLSW transportar las tramas que él ha recibido de la conexión LLC hacia el otro extremo. Se usa TCP entre los Data Link Switches para garantizar la entrega de las tramas. Como resultado de este diseño, los Timeouts del LLC se encuentran limitados a la LAN Local, (o sea no atraviesan la WAN). Además, tampoco los "acknoledge" de LLC tipo 2 atraviesan la WAN, lo que redunda en disminuir el tráfico que cruza los enlaces WAN. . Finalmente, los Switches pueden interactuar con los sistemas locales para proveer control de flujo y control de congestión.

Data Link Switching utiliza direccionamiento de LAN para establecer conexiones entre los sistemas SNA. Los dispositivos SDLC conectados son definidos con direcciones MAC y SAP a fin de habilitarlos para comunicarse con dispositivos LAN conectados. Para sistemas NetBIOS, DLSW utiliza nombres NetBIOS para enviar datagramas y para establecer conexiones para sesiones NetBIOS.

Dado que los Data Link Switches pueden ser implementados en Routers Multiprotocolo, pueden darse situaciones en que Bridging y Switching estén simultáneamente habilitados. Las tramas SNA pueden ser identificadas por su valor de enlace SAP. Los valores típicos son 0x04, 0x08, 0x0C. NetBIOS utiliza siempre como valor de enlace SAP 0xF0.

Conexión de Transporte:

Los Data Link Switches se pueden usar por pares o por sí mismos de a uno. Un DLSW simple, conmuta un Data link a otro sin utilizar TCP.

Dos DLSW apareados multiplexan enlaces de datos sobre transporte confiable utilizando SSP. Previamente a que DLSW pueda establecerse entre dos routers, estos deben establecer dos conexiones TCP entre ellos. Cada DLSW mantendrá una lista de Routers DLSW y su estado, (disponible/no disponible). Luego de que la conexión TCP está establecida, mensajes SSP son intercambiados para establecer las capacidades de los dos Data Link Switches. Una vez concluido este intercambio, el DLSW utilizará mensajes de control SSP para establecer los circuitos "end to end" sobre la conexión de transporte. Dentro de la conexión de transporte, mensajes SSP de DLSW son intercambiados. Los formatos y tipos de mensajes SSP no serán documentados en el presente trabajo, tan solo se refiere que SSP posee mensajes de control de72 Bytes y los mensajes de información son de 16 Bytes.

Quede destacar que dos o más DLSW pueden ser conectados a la misma red LAN, que consista en un número de segmentos Token Ring interconectados por Bridges de Source Routing. En este caso, no se define una conexión TCP entre los Bridges conectados a una misma LAN. Esto permitirá el uso de sistemas para seleccionar uno de los DLSW posibles en forma similar a la selección de un camino de Switching en una red de Bridging enrutada según "Source Routing".

Hacia 1995 se publicó la RFC 2166, en la que se presentan los denominados "DLSW Enhancements". Son un set de extensiones a la RFC 1795 diseñado para la escalabilidad de DLSW. Entre las mejoras presentadas se enuncian las Siguientes:

• Conexiones TCP sobre demanda
• Resolución de Direcciones sobre UDP
• Broadcast de NetBIOS sobre UDP
• Grupos de Multicast y de Direccionamiento