| |  | |
REDESII | | |
 Fuentes del 802.x al 802.y
Se podría pensar con inocencia que un puente de una LAN 802 a otra, seria completamente trivial, pero
éste no es el caso.
En el resto de esta sección se señalarán algunas de las dificultades que se encontrarán cuando se trate
de construir un puente
entre varias LAN 802. Mayores detalles al respecto se pueden encontrar en Berntsen y colaboradores 11
985) y en Hawe y
colaboradores 11 984).
Cada una de las nueve combinaciones posibles de la 802,x a la 802.y, tiene su conjunto propio y exclusivo
de problemas.
Sin embargo, antes de tratar cada uno de ellos en forma separada, examinemos algunos de los problemas
generales que son
comunes a todos los puentes. Para comenzar, cada una de las LAN utiliza un formato de trama diferente
(véase figura 5-30).
No existe ninguna razón técnica válida para esta incompatibilidad. Sólo que ninguna de
las compañías que promueven las tres normas (Xerox, GM e IBM) quisieron modificar las suyas. Como resultado
de esto,
cualquier proceso de copiado entre diferentes LAN necesitará un reformateo, el cual lleva tiempo de
CPU, exige un nuevo
cálculo del código de redundancia y, además, introduce la posibilidad de errores sin detectar, debidos
a bits dañados en la
memoria del puente. Nada de esto seria necesario si los tres comités hubieran sido capaces de aceptar
un solo formato.
_
Otro problema, todavía más serio, es el hecho de que las LAN interconectadas no funcionan necesariamente
a la misma
velocidad. Cada norma permite el uso de varias velocidades. La norma 802.3 permite velocidades de hasta
20 Mbps. Con
la 802.4 se pueden tener varias velocidades que van de 1 a 10 Mbps. Por último, la norma 802.5 se va
desde 1 hasta 4
Mbps. En la práctica, la 802.3 es de 10 Mbps, la 802.4 generalmente es de 10 Mbps, y la 802.5 es de
4 Mbps.
Cuando se reexpide un número grande de tramas desde la 802.3 o 802.4 a la 802.5, el puente no será capaz
de librarse de
las tramas tan rápido como llegan; sino que tendrá que almacenarlas, esperando que no se le termine
la memoria disponible.
El problema también existe, hasta cierto punto, de la 802.4 a la 802. 3, porque una parte del ancho
de banda de la 302.3 se
pierde debido a las colisiones. En realidad no tiene 10 Mbps, en tanto que la 802.4 si los tiene.
_
Un problema más sutil, pero también importante, que está relacionado con el concepto de puente
como un cuello de botella,
es el del valor de los temporizadores en las capas superiores. Supóngase que la capa de red en una LAN
802.4 está
tratando de enviar un mensaje muy largo, como una secuencia de tramas. Después de transmitir la última,
arranca un
temporizador para esperar un asentimiento. Si el mensaje tiene que transitar por un puente hacia una
LAN 802. 5, existe el
peligro de que el temporizador se desactive, antes de que se haya expedido la última trama hacia la
LAN más lenta. La capa
de red supondrá que el problema se debe a una trama extraviada, y retransmite de nuevo la secuencia
completa. Después de
n intentos fallidos puede llegar a renunciar, e indicar a la capa de transporte que el extremo destinatario
está muerto.
Precisamente este problema de velocidades desiguales en una pasarela, fue reportado por Nagle (1984)
en un contexto
ligeramente distinto.
Un tercer problema y potencialmente el más serio de todos, es que las tres LAN 802 tienen diferentes
longitudes máximas
de trama. Para la 802.3, ésta depende de los parámetros de la configuración, pero para el sistema normal
de 10 Mbps es de
1518 octetos. Para la 802.4 esta longitud se fijó en 8191 octetos. Para la 802. 5 no hay limite superior,
excepto que una
estación no puede transmitir por un tiempo mayor que el tiempo de retención del testigo. Con el valor
por defecto de 10
mseg, la máxima longitud de la trama seria de 5000 octetos.
El problema obvio es, ¿qué sucede si una trama larga debe expedirse sobre una LAN que no puede aceptarla?
La idea de
dividir la trama en varios pedazos no es solución porque no puede llevarse a cabo en esta capa. Todos
los protocolos
suponen que las tramas llegan o no llegan. No hay forma de rearmar las tramas a partir de unidades más
pequeñas. Con esto
no se pretende dar a entender que semejantes protocolos no puedan diseñarse. Podrían y de hecho lo han
sido. Es
simplemente que el 802 no proporciona esta característica. Básicamente no hay solución, y las tramas
que sean muy largas
para ser transmitidas, deberán desecharse. Demasiado para la transparencia.
Ahora consideremos con brevedad cada uno de los nueve casos de puentes del 802.x al 802,y, con objeto
de ver qué otros
problemas están ocultos. De un 802.3 a otro 802.3 es fácil. La única cosa que puede andar mal es que
la LAN destinataria
se encuentre tan cargada, que haga que las tramas sigan llenando el puente, y éste no pueda deshacerse
de ellas. Si esta
situación persistiera por mucho tiempo, el puente podrá quedarse sin tampones y comenzar a tirar tramas.
Dado que este
problema siempre está potencialmente presente cuando se transmite hacia una LAN 802.3, ya no lo mencionaremos
más.
Con las otras dos LAN, cada una de las estaciones, incluyendo el puente, tienen garantizado que puedan
adquirir
periódicamente el testigo, y que no estarán calladas durante largos intervalos.
De la 802.4 a la 802.3 existen dos problemas. Primero, las tramas del 802.4 transportan bits de prioridad
que las tramas de
la 802. 3 no tienen. Como resultado de esto, si dos LAN 802.4 se comunican a través de una LAN 802.
3, la LAN
intermedia perderá la prioridad.
El segundo problema está provocado por una característica especifica de la 802.4: intercambio temporal
del testigo. Es
posible, para una trama de la 802.4, poner un bit de la cabecera a 1, para pasar temporalmente el testigo
a su destino,
permitiéndole así enviar un acuse de recibo. Sin embargo, si un puente reexpide esta trama, ¿qué deberá
hacer este puente?
Si éste envía una trama de asentimiento por su cuenta, estará mintiendo, porque la trama realmente no
se ha entregado
todavía. De hecho, el destino podría estar muerto.
Por otra parte, si no generara el asentimiento, seguramente el extremo emisor concluiría que el extremo
destinatario está
muerto y notificará un fallo a sus superiores. Parece que no existe ninguna manera de corregir este
tipo de problema.
Se tiene un problema similar para el caso de la 802.5 a la 802.3. El formato de la trama de la 802.5
tiene los bits A y C en el
octeto que se refiere al estado de la trama. El destino ajusta estos bits para indicarle al emisor si
la estación direccionada vio
la trama y, también si la copió. De nuevo, aquí el puente puede mentir y decir que efectivamente copió
la trama pero, si
después resulta que el extremo destinatario está fuera de servicios pueden surgir problemas muy serios.
En esencia, la
inclusión de un puente en la red, modifica la semántica de los bits.
De la 802.3 a la 802.4 se tiene el problema de qué colocar en los bits de prioridad. Se puede obtener
un buen resultado al
hacer que el puente retransmita todas las tramas con la prioridad más alta, porque probablemente habrán
sufrido ya un
retardo considerablemente largo.
De la 802.4 a la 802.4 el único problema consiste en qué hacer con el intercambio temporal de testigo.
Por lo menos se
tiene la posibilidad de que el puente trate la reexpedición de la trama, lo más rápido que se pueda,
para obtener la respuesta
antes de que el temporizador venza. Al reexpedir la trama con la prioridad más alta, el puente está
contando una pequeña
mentira, pero gracias a esto, incrementa la probabilidad de obtener la respuesta a tiempo.
De la 802. 5 a la 802.4 se tiene con los bits A y C exactamente el mismo problema anterior. También,
la definición de los
bits de prioridad es diferente en las dos LAN, pero los pedigüeños no tienen la oportunidad de escoger.
Al menos las dos
LAN tienen el mismo número de bits de prioridad. Lo único que el puente puede hacer es copiar los bits
de prioridad y
esperar el mejor resultado.
De la 802. 3 a la 802. 5 el puente debe generar los bits de prioridad, pero no surge ningún otro problema
especial. De la
8ó2.4 a la 802.5 hay un problema potencial con las tramas que son demasiado largas, y el problema del
intercambio
temporal del testigo se presenta otra vez. Por último, de la 802. 5 a la 802. 5 el problema radica en
qué hacer con los bits A
y C, nuevamente. En la figura 5-31 se sumarían los diferentes tipos de problemas que se han venido mencionando.
_
Cuando el comité del IEEE 802 (Instituto de ingenieros eléctricos y electrónicos) inició los trabajos
para diseñar una norma
para las LAN, fue incapaz de ponerse de acuerdo en una sola norma, por lo que produjo tres normas incompatibles,
como
acabamos de ver con cierto detalle. Por este fracaso se le ha criticado abiertamente. Cuando después
se le asignó la tarea
de diseñar una norma para puentes, con objeto de interconectar sus tres LAN incompatibles, resolvió
hacerlo mejor, y lo
hizo; pues se sacó la espina con dos diseños incompatibles para los puentes. Hasta ahora, nadie le ha
solicitado diseñar una
norma, para conectar sus dos puentes incompatibles. Sin embargo, la tendencia va en dirección correcta.
Esta sección se ha ocupado de los problemas que se encuentran en dos redes tipo LAN conectadas a través
de un solo
puente. Las siguientes dos secciones se ocuparán de los problemas que se presentan al conectar redes
de interconexión
grandes, que contienen muchas LAN y muchos puentes, así como los dos planteamientos de la IEEE para
el diseño de estos
puentes.
|
