4 REDES LOCALES

En el capítulo 1 vimos que las redes podían por su tecnología clasificarse en redes broadcast y redes formadas por enlaces punto a punto. En este último caso la información se envía al ordenador situado al otro lado del enlace, que está claramente identificado y el medio de transmisión normalmente está siempre disponible. Todos los protocolos de nivel de enlace que hemos visto en el capítulo anterior parten de estas dos suposiciones; a lo sumo en el caso de una conexión semi-dúplex el uso del canal se ha de alternar entre los dos ordenadores participantes.

En las redes broadcast hay una complejidad añadida. Dado que el canal de comunicación es compartido entre varios ordenadores, es preciso habilitar mecanismos que permitan a cada uno de ellos utilizarlo para enviar sus tramas al ordenador de destino. El hecho de compartir el canal generará conflictos o incluso pérdida de tramas en algunos casos; los protocolos deberán establecer los mecanismos adecuados para resolver dichos conflictos y permitir que los ordenadores retransmitan en caso necesario las tramas que no hayan podido ser enviadas correctamente.

Debido a esta característica singular de las redes broadcast la capa de enlace tiene en ellas una complejidad mayor que en las redes punto a punto, por lo que el modelo OSI se suele dividir en este caso en dos subcapas: la inferior, que se ocupa de controlar esta nueva funciónde acceso al medio de transmisión que hemos comentado, se denomina subcapa MAC (Media Access Control); la superior, conocida como subcapa LLC (Logical Link Control) corresponde a las funciones de la capa de enlace comunes a todo tipo de redes como las que hemos visto en el capítulo anterior.

Aunque siguiendo en sentido ascendente el modelo OSI la subcapa MAC es previa a la subcapa LLC nosotros las veremos en orden inverso como hacen muchos libros de texto, porque resulta mas fácil comprender primero el funcionamiento entre dos ordenadores unidos por un enlace punto a punto y abordar luego el problema más complejo de una comunicación entre múltiples ordenadores de una red broadcast.

Aunque la mayoría de las redes broadcast son redes locales y viceversa, existen algunas excepciones. Por ejemplo las redes vía satélite, que evidentemente no son redes locales, son redes broadcast. Inversamente las redes locales basadas en conmutación (por ejemplo HIPPI) no emplean un medio broadcast. En este capítulo abarcaremos tanto las redes locales utilicen o no un medio broadcast como las redes broadcast sean o no redes locales. Además en lo relativo a las redes locales abarcaremos no sólo el nivel de enlace sino también el nivel físico característico de cada una de ellas. Por último diremos también que no hablaremos en este capítulo de las redes locales basadas en ATM ya que eso corresponde claramente al nivel de red, que abordaremos en el capítulo correspondiente.

4.2 PROTOCOLOS DE ACCESO MÚLTIPLE

4.2.1 Protocolos sin detección de portadora: ALOHA

En 1970, cuando la red ARPANET solo llevaba unos meses en funcionamiento, un equipo de la Universidad de Hawai, dirigido por Norm Abramson, quería poner en marcha una red para interconectar terminales ubicados en las islas de Kauai, Maui y Hawaii, con un ordenador situado en Honolulu, en la isla de Oahu. Lo normal habría sido utilizar enlaces telefónicos, pero la baja calidad y el elevado costo de las líneas hacían prohibitiva esta opción (por aquel entonces AT&T aún disfrutaba del monopolio de la telefonía en los Estados Unidos, lo cual no le estimulaba a bajar precios).

Abramson y su equipo estaban decididos a llevar a cabo su proyecto a toda costa, pero no a cualquier costo. Consiguieron varios transmisores de radio taxis viejos y construyeron módems de forma artesanal. Con esto pusieron en marcha una red de radioenlaces entre las islas. Si se hubiera asignado un canal diferente para la comunicación en cada sentido entre Oahu y las otras tres islas habrían hecho falta seis canales; en vez de eso asignaron solamente dos: uno a 413,475 MHz para las transmisiones de Oahu a las demás islas y otro a 407,350 MHz para el sentido inverso. Cada canal tenía un ancho de banda de 100 KHz y una capacidad de 9,6 Kb/s. En caso de haber creado seis canales en el mismo ancho de banda la capacidad de cada uno habría sido proporcionalmente menor; creando solo dos se disponía de una mayor capacidad a costa de tener que compartirlos entre las tres islas. Las transmisiones desde Oahu no planteaban problemas pues había un único emisor. Sin embargo el canal de retorno era compartido por tres emisores (Kauai, Maui y Hawaii), por lo que podía suceder que dos emisores transmitieran simultáneamente, con lo que se producía una colisión con lo que ambas tramas se perdían; había pues que establecer reglas que especificaran como se resolvía una situación de este tipo; estas reglas es lo que denominamos un protocolo de acceso al medio o protocolo MAC (Media Acccess Control).

La solución que adoptó Abramson fue muy simple. Cuando un emisor quiere transmitir una trama simplemente la emite, sin preocuparse en ningún momento de si el canal está libre; una vez ha terminado se pone a la escucha, esperando recibir confirmación de que la información ha sido recibida correctamente por el destinatario, cosa que éste puede comprobar mediante el CRC de la trama. Si pasado un tiempo razonable no se recibe confirmación el emisor supone que ha ocurrido una colisión; en este caso espera un tiempo aleatorio (para no colisionar nuevamente) y a continuación reenvía la trama.

Este protocolo MAC, que fue el primero en implementarse, se denominó Aloha. La red creada por Abramson en Hawai se denominó ALOHANET. Aloha es una palabra Hawaiana que se utiliza para saludar, tanto al llegar como al despedirse. Seguramente esta ambigüedad pareció apropiada a sus inventores para indicar el carácter multidireccional o broadcast de la transmisión, por contraste con los enlaces punto a punto utilizados hasta entonces donde se sabe con certeza si la información va o viene.

En el protocolo Aloha original la emisión de tramas por parte de cada ordenador o estación se hace de forma completamente caótica y basta que dos tramas colisionen o se solapen solamente en un bit para que ambas sean completamente inútiles, a pesar de lo cual tanto la primera como la segunda serán irremediablemente transmitidas, ya que los emisores sólo se percatarán del problema después de haber terminado la transmisión; además la segunda trama podría colisionar con una tercera, y así sucesivamente; en una red Aloha cuando el tráfico crece las colisiones aumentan de manera no lineal y el rendimiento decae rápidamente.

4.2.1.1 Aloha ranurado

En 1972 Roberts propuso una mejora al protocolo Aloha que consistía en dividir el tiempo para la emisión de tramas en intervalos de duración constante. De alguna manera las estaciones estarían sincronizadas y todas sabrían cuando empezaba cada intervalo. Esto reduce la probabilidad de colisión, ya que al menos limita su efecto a un intervalo concreto (no se pueden 'encadenar' colisiones). A esta versión mejorada de Aloha se la denomina Aloha ranurado, porque utiliza tiempo ranurado o a intervalos. Por contraposición al Aloha original, con tiempo aleatorio, se le suele denominar Aloha puro.

La eficiencia de un sistema Aloha se puede estimar fácilmente si se supone que los emisores transmiten las tramas de acuerdo con una distribución de Poisson. En ese caso se puede demostrar con un razonamiento matemático-estadístico simple que el rendimiento máximo de un Aloha puro es del 18,4 %, y que esta eficiencia se consigue con una utilización del canal del 50%. Es decir que por ejemplo un canal de 10 Mb/s funcionando con Aloha puro daría su máxima eficiencia cuando las estaciones estuvieran enviando un tráfico de 5 Mb/s, del cual se transmitirían correctamente 1.84 Mb/s y los restantes 3,16 Mb/s se perderían por colisiones; si el nivel de utilización pasa del 50% el caudal útil transmitido disminuye. Para un Aloha ranurado, también con una distribución de Poisson, Abramson dedujo que la eficiencia máxima es justamente el doble, del 36,8 % y se consigue con una utilización del 100%. Así por ejemplo en un canal de 10 Mb/s con Aloha ranurado el máximo caudal útil que podría obtenerse es de 3,68 Mb/s y para elo sería preciso inyectar en la red 10 Mb/s de tráfico.

Los valores de eficiencia antes mencionados y la mayoría de las simulaciones que se han hecho de tráfico en redes locales se basan en la hipótesis de que las estaciones transmiten de acuerdo con una distribución de Poisson. La distribución de Poisson se utiliza en estadística para estudiar la probabilidad de eventos discretos que suceden de forma aleatoria entre la población y que pueden tener dos posibles valores o estados, por ejemplo la probabilidad de avería de un componente (bombilla fundida, pinchazo, etc.). En realidad la utilización de distribuciones de Poisson en las simulaciones de redes locales se debe mas a la simplificación que esto introduce en el tratamiento matemático correspondiente que al parecido que dichas distribuciones puedan tener con la realidad. Hoy en día está universalmente aceptado que la distribución de Poisson no representa adecuadamente el comportamiento del tráfico en redes locales, el cual corresponde a lo que los matemáticos denominan un proceso auto-similar o de tipo fractal en el que no se siguen patrones de distribución puramente aleatorios. Podemos comprender esto fácilmente de forma intuitiva si pensamos que en cualquier red local hay algunos ordenadores (por ejemplo servidores) que transmiten mucho más que otros, por lo que el tráfico no se genera de forma aleatoria. Una consecuencia de esta distribución menos aleatoria del tráfico es que la eficiencia de las redes locales suele ser mayor en la práctica de lo que cabría esperar según las simulaciones basadas en distribuciones de Poisson, ya que cualquier cambio que reduzca la aleatoriedad y aumente el orden redundará en beneficio de la eficiencia, de la misma forma que con Aloha ranurado se mejoraba el rendimiento al imponer un cierto orden frente a Aloha puro. Conviene por tanto no tomar demasiado en serio los estudios puramente teóricos sobre rendimiento de redes locales. Comentaremos de paso que actualmente se acepta que el tráfico en Internet corresponde también a procesos auto-similares, por lo que las simulaciones de tráfico Internet basadas en distribuciones de Poisson deberían también tomarse en consideración con gran cautela.

Los protocolos Aloha aún se utilizan hoy en día (normalmente Aloha ranurado) en situaciones donde no es posible o no es práctico detectar las colisiones en tiempo real, por ejemplo algunas redes de satélite o el canal de acceso aleatorio que se utiliza en las redes GSM para acceder al canal de control.

4.2.2 Protocolos con detección de portadora

En Aloha las estaciones se ponen a transmitir sin preguntar antes si el canal está libre. Veamos ahora protocolos más 'diplomáticos', que antes de transmitir miran si alguien ya lo está haciendo. Esto permite hacer un uso más eficiente del canal y llegar a mayores grados de ocupación, ya que no se interrumpe la transmisión en curso. Estos protocolos se denominan de acceso múltiple con detección de portadora o CSMA (Carrier Sense Multiple Access); la denominación ‘detección de portadora’ hace referencia a esa consulta previa sobre la ocupación del canal.

4.2.2.1 CSMA 1-persistente

En su nivel más primitivo el protocolo CSMA hace lo siguiente: cuando tiene una trama que enviar primero escucha el canal para saber si está libre; si lo está envía la trama; en caso contrario espera a que se libere y en ese momento la envía. Este protocolo se denomina CSMA 1-persistente porque hay una probabilidad 1 (es decir certeza) de que la trama se transmita cuando el canal esté libre.

En una situación real con tráfico intenso es muy posible que cuando un ordenador termine de transmitir haya varios esperando para enviar su trama; con CSMA 1-persistente todas esas tramas serán emitidas a la vez y colisionarán, pudiéndose repetir el proceso varias veces con la consiguiente degradación del rendimiento. En realidad la colisión ocurre aunque no empiecen a transmitir exactamente a la vez: basta con que dos ordenadores empiecen a transmitir con una diferencia de tiempos menor que la distancia que los separa, ya que en tal caso ambos detectarán el canal libre en el momento de iniciar la transmisión; por ejemplo, supongamos dos ordenadores unidos por un cable de un kilómetro de longitud, con lo que la señal tardará unos 5 ms en llegar de uno al otro; si la diferencia de tiempo con la que ambos empiezan a transmitir es menor de 5 ms se producirá una colisión, pues el segundo no habrá recibido la señal del primero a tiempo de evitarla. En este tipo de redes el retardo de propagación de la señal puede tener un efecto importante en el rendimiento.

A pesar de sus inconvenientes el CSMA 1-persistente supone un avance respecto al ALOHA ranurado, ya que toma la precaución de averiguar antes si el canal está disponible, con lo que se evitan un buen número de colisiones. Suponiendo una distribución de Poisson la máxima eficiencia puede llegar al 55% aproximadamente, obteniéndose ésta con un grado de ocupación del 100%.

4.2.2.2 CSMA no persistente

En un intento por resolver el problema de colisiones de CSMA 1-persistente podemos adoptar la estrategia siguiente: antes de enviar escuchamos, si el canal está libre transmitimos, pero si está ocupado, en vez de estar a la escucha, pendientes de usarlo en cuanto se libere, esperamos un tiempo aleatorio después del cual repetimos el proceso; a este protocolo se le denomina CSMA no persistente. Este protocolo tiene una menor eficiencia que CSMA 1-persistente para tráficos moderados, pues introduce una mayor latencia; sin embargo se comporta mejor en situaciones de tráfico intenso ya que evita las colisiones producidas por las estaciones que se encuentran a la espera de que termine la transmisión de una trama en un momento dado.

4.2.2.3 CSMA p-persistente

CSMA p-persistente intenta combinar las ventajas de CSMA 1-persistente y CSMA no persistente. Este protocolo se aplica con tiempo ranurado o a intervalos y funciona de la siguiente manera: cuando el ordenador tiene algo que enviar primero escucha el canal, si está libre transmite, en caso contrario espera; cuando el canal se libera transmite con una probabilidad p (o no transmite con una probabilidad q=1-p); si no transmite en el primer intervalo el proceso se repite en el siguiente, es decir transmite con una probabilidad p, o no transmite con una probabilidad q. El proceso se repite hasta que finalmente la trama es transmitida o bien otro ordenador utiliza el canal, en cuyo caso espera un tiempo aleatorio y empieza de nuevo el proceso desde el principio.

Ajustando el valor del parámetro p el funcionamiento de este protocolo se puede regular en todo el rango entre el de CSMA 1-persistente y el de CSMA no persistente. Su eficiencia es en general superior a la de ambos.

4.2.2.4 CSMA con detección de colisión

En los protocolos que hemos descrito hasta ahora una vez se había empezado a transmitir una trama el ordenador seguía transmitiendo aun cuando detectara una colisión. En ese caso sería lógico y más eficiente parar de transmitir, ya que la trama será errónea e inútil. Esta mejora es la que incorporan los protocolos conocidos como CSMA/CD (Carrier Sense Multiple Access with Collision Detection, acceso múltiple detección de portadora con detección de colisiones) que se utiliza en la red local IEEE 802.3, también conocida como Ethernet, en sus múltiples variantes.

En una red CSMA/CD la única circunstancia en la que puede producirse una colisión es cuando dos ordenadores empiezan a transmitir a la vez, o con una diferencia de tiempo lo bastante pequeña como para que la señal de uno no haya podido llegar al otro antes de que éste empiece a transmitir. Supongamos que tenemos dos ordenadores A y B situados en extremos opuestos de la red y que la señal tarda un tiempo t en propagarse de uno a otro extremo a otro; cabría pensar que si A empieza a transmitir pasado ese tiempo t ya puede estar seguro de que no observará colisiones, ya que sus señal ha llegado al otro extremo de la red; pero en el caso más desfavorable B podría haber empezado a transmitir justo en el instante t-e, o sea inmediatamente antes de que le haya llegado la trama de A; por lo que sólo después de un tiempo 2t puede A estar seguro de no colisionar con ninguna otra estación, habiéndose entonces ‘apoderado’ del canal de transmisión. Dado que el período de incertidumbre en CSMA/CD se reduce a ese intervalo 2t estas redes se suelen modelar como un sistema ALOHA ranurado con intervalos de tamaño 2t.

4.2.3 Protocolos sin colisiones

En cualquiera de los protocolos que hemos visto hasta ahora puede haber competencia entre ordenadores por acceder al medio. Dicha competencia produce colisiones, que en la práctica suponen una disminución del rendimiento ya que las transmisiones que se producen durante la colisión son inútiles; estos efectos se agravan a medida que aumenta el tráfico en la red, ya que la probabilidad de colisiones aumenta. Las cosas mejoran a medida que refinamos el protocolo, pero incluso con CSMA/CD cuando la ocupación del canal es elevada el rendimiento empieza a bajar.

Vamos a estudiar ahora protocolos que por su funcionamiento no tienen colisiones, y que suelen tener por tanto una mayor eficiencia cuando la carga de la red es elevada.

4.2.3.1 Protocolo bitmap

Si los protocolos basados en colisiones se parecen a una reunión de vecinos donde el orden es casi nulo, el protocolo bitmap se asemeja a una sesión del parlamento (sin presidente), donde cada representante solicita turno de palabra de acuerdo con unas rígidas reglas.

Supongamos que la red tiene N ordenadores, numerados de 0 a N-1. Para empezar a funcionar establecemos una ronda 'exploratoria' de N intervalos en la que por riguroso turno cada ordenador, empezando por el 0, tiene la posibilidad de enviar un bit con el valor 1 ó 0 para indicar si tiene alguna trama que transmitir. Pasados N intervalos todos los ordenadores han podido manifestar su situación, y todos saben quien tiene tramas para transmitir.

Supongamos que tenemos 8 ordenadores, y que después de la ronda inicial sabemos que los ordenadores 1, 3 y 7 tienen tramas para transmitir. A continuación toma la palabra el ordenador 1, que transmite la trama que tenía pendiente. Después vendrá el 3 y por último el 7. Agotados los turnos que había solicitados se inicia otra ronda de sondeo para saber quien tiene tramas pendientes de transmitir, y así sucesivamente.

Puede suceder que a algún ordenador le surja la necesidad de transmitir una trama justo después de haber dejado pasar su turno; en tal caso tendrá que esperar a la siguiente vuelta.

Desde el punto de vista del rendimiento este protocolo genera una trama adicional de N bits. Si la red no tiene tráfico se generará una trama bitmap que estará continuamente dando vueltas por la red. Si la carga en la red es baja (una trama transmitida por vuelta) la eficiencia es d/(N+d), donde d es el tamaño de la trama de información transmitida y N el número de ordenadores. Si la red está saturada cada ordenador tendrá una trama que enviar y la eficiencia será Nd/(Nd+N), o sea d/(d+1). Vemos pues que el rendimiento de este protocolo aumenta a medida que lo hace el tráfico en la red, justo lo contrario de lo que ocurría con los protocolos basados en colisiones.

Además de la eficiencia global del protocolo podemos analizar la calidad de servicio que cada ordenador percibe. En principio cuando un ordenador quiere enviar algo, suponiendo que la red esté muy poco cargada tendrá que esperar una media de N/2 turnos para poder expresar su deseo, en ese instante reserva su 'plaza'. Si se trata del ordenador 0 tendrá además que esperar N intervalos más para que se efectúe la ronda y se transmita su trama, lo cual da un tiempo de respuesta de 1,5N intervalos. En cambio si se trata del ordenador N la trama se transmitirá inmediatamente; suponemos que al estar la red muy poco cargada nadie mas reserva sitio, por lo que al terminar la ronda exploratoria se va directamente a satisfacer la petición, por tanto el tiempo de respuesta es de 0,5N intervalos. Vemos pues que en situaciones de poco tráfico el protocolo bitmap no da un trato equitativo, sino que favorece a los ordenadores con dirección elevada. En cambio en situaciones de saturación este efecto desaparece, ya que si todos los ordenadores tienen tramas que enviar cada uno podrá transmitir una trama cada vez.

En situaciones de saturación donde todos los ordenadores tienen tramas que transmitir, y suponiendo que todas las tramas tienen el mismo tamaño el protocolo bitmap produce un reparto equitativo, por lo que resulta equivalente a utilizar multiplexación por división en el tiempo para repartir el canal entre los ordenadores de la red.

Resumiendo, el protocolo bitmap resulta más eficiente y más homogéneo en su comportamiento a medida que la carga de la red aumenta.

Los protocolos como el que hemos descrito, en los que se emite un paquete indicando el deseo de transmitir información, se denominan protocolos de reserva.

4.2.3.2 Protocolo de cuenta atrás binaria

El protocolo bitmap requiere reservar un intervalo de un bit para cada ordenador. Con un número elevado de ordenadores esto puede suponer un costo elevado que lo haga impracticable. Veremos ahora una alternativa que resuelve ese inconveniente, el protocolo denominado cuenta atrás binaria.

Supongamos que tenemos una red con 16 ordenadores. Cada uno recibirá una dirección codificada en 4 bits. Supongamos ahora que los ordenadores 0010, 0100, 1001 y 1010 desean transmitir tramas. El protocolo de cuenta atrás binaria procede de la siguiente forma:

En el primer intervalo los cuatro ordenadores que desean transmitir envían a la red el primer bit de su dirección; el medio de transmisión está diseñado de tal forma que retransmite el OR de todos los bits transmitidos, es decir en este caso los cuatro ordenadores reciben un 1.

Al haber recibido un 1 los ordenadores 0010 y 0100 (que tienen un 0 en su primer bit) reconocen que hay ordenadores superiores a ellos en la competición y se retiran; los dos 'finalistas' envían a la red su segundo bit, que es cero para ambos; la red retransmite un cero.

Al haber recibido un cero los dos ordenadores siguen compitiendo y envían su tercer bit, un cero para 1001 y un 1 para 1010; la red retransmite un 1 y el ordenador 1001 se retira al ver que hay uno que le supera.

El ordenador ganador, el 1010, envía su trama.

El proceso se repite para los tres ordenadores restantes, y así sucesivamente hasta que eventualmente todos envían su trama. La eficiencia de este protocolo es d/(d + ln N), que para tráficos reducidos supera al bitmap; además, el mecanismo de selección suministra la dirección del ordenador transmisor que a menudo es parte de la información que se pretende transmitir, con lo que incluso este overhead se aprovecha y la eficiencia puede ser del 100%.

4.2.4 Protocolos de contención limitada

Hemos visto que los protocolos con contención (es decir, con colisiones) son ideales cuando los niveles de tráfico son bajos, ya que tienen retardos pequeños y no introducen overhea,; todos los datos transmitidos son tramas de información útil. En cambio, cuando el tráfico aumenta, es preferible perder una parte de la capacidad del canal en habilitar mecanismos que habiliten 'turnos de palabra', ya que de lo contrario no es posible utilizar el canal al máximo de sus posibilidades.

Cabría pensar en un protocolo ideal que contuviera lo mejor de ambos mundos. Debería ser lo bastante astuto como para funcionar de forma 'caótica' (es decir con colisiones) a bajos niveles de tráfico, y poner en marcha mecanismos de arbitraje riguroso en caso de que el tráfico aumente por encima de ciertos niveles considerados peligrosos, es decir, debería ser autoadaptativo. Este tipo de protocolos se denomina protocolos de contención limitada.

En caso de que la red tenga poco tráfico estos protocolos se comportarán según alguno de los protocolos con colisiones que hemos visto. Pero cuando se superen determinados umbrales de ocupación el protocolo dividirá el canal en intervalos asignando uno a cada ordenador, en riguroso turno. Este comportamiento es equivalente a realizar multiplexación por división en el tiempo sobre el canal. En la práctica suelen ser unos pocos ordenadores los que generan la mayor parte del tráfico (recordemos que el tráfico es auto-similar), por lo que lo ideal es identificar a los 'culpables' y aislarlos en intervalos propios, independientes del resto de los ordenadores; de esta forma esos ordenadores con tráfico elevado consiguen un buen rendimiento sin perjudicar a la mayoría 'silenciosa'. Precisamente la pronta identificación de esos 'culpables' es la clave del funcionamiento de estos protocolos. Los ordenadores no necesariamente han de ser identificados individualmente, es suficiente detectar un grupo con tráfico elevado (que presumiblemente contendrá algún 'sospechoso') y aislarlo del resto. Uno de los protocolos que funciona con este principio es el denominado protocolo del paseo adaptativo por el árbol.

Aunque hay una gama muy amplia de protocolos MAC que han sido propuestos en teoría, modelados por simulación e incluso probados en redes experimentales, en la práctica las posibles opciones se reducen a un número muy pequeño. Además como veremos luego el protocolo MAC va implícito en la tecnología de red local utilizada, que muchas veces se decide en base otros factores, tales como costo, disponibilidad de productos, etc. por lo que el margen de maniobra en cuanto a la elección del protocolo MAC es prácticamente nulo.

4.2.5 Protocolos de redes inalámbricas

Las ondas electromagnéticas no guiadas son un medio ideal para la creación de redes broadcast; ya hemos visto como algunas de las primeras experiencias (Aloha) se hicieron con este tipo de medios de transmisión. Actualmente, con el auge de los sistemas móviles han aparecido redes locales basadas en ondas radioeléctricas e infrarrojos; los sistemas infrarrojos por sus características tienen un alcance reducido y requieren estricta visión directa entre emisor y receptor. Los de radio solo pueden transmitir a muy baja potencia (0,1 W) por restricciones legales, por lo que su alcance es también reducido, aunque no tanto como los infrarrojos. Normalmente se emplea la banda conocida como Industrial/Científica/Médica (2,4 - 2,484 GHz). Típicamente una LAN inalámbrica está formada por un conjunto de estaciones base, unidas entre sí por algún tipo de cable, y una serie de estaciones móviles que comunican con la estación base más próxima. El conjunto de estaciones base forma en realidad un sistema celular en miniatura.

Dado que la transmisión se realiza mediante ondas electromagnéticas podríamos pensar que nos encontramos ante un caso similar al de las redes Aloha. Sin embargo existen alternativas más eficientes que el Aloha para este tipo de entornos, como la que describimos a continuación.

Supongamos cuatro ordenadores A, B, C y D situados en línea y separados 10 metros cada uno del siguiente:

A B C D

Supongamos también que el alcance máximo de cada uno de ellos es de 12 metros.

Ahora imaginemos que implementamos un protocolo CSMA para su comunicación; la secuencia de sucesos para transmitir una trama podría ser la siguiente:

A desea transmitir datos a B; al detectar el medio lo encuentra libre y empieza la transmisión.

Con A transmitiendo C desea transmitir datos hacia B; detecta el medio y lo encuentra libre (C no escucha a A pues esta a 20m de distancia), por tanto C empieza a transmitir.

El resultado es una colisión en el receptor (B) que no es detectada ni por A ni por C. Esto se conoce como el problema de la estación oculta.

Imaginemos ahora la misma distribución de estaciones y otra secuencia de sucesos:

B desea transmitir datos hacia A, detecta el medio libre e inicia la transmisión.

A continuación C desea transmitir datos hacia D; como detecta que B está transmitiendo se espera a que termine para evitar una colisión.

El resultado es que una transmisión que en principio podría haberse hecho sin interferencias (ya que A no puede escuchar a C y D no puede escuchar a B) no se lleva a cabo, reduciendo así la eficiencia del sistema. Esto se conoce como el problema de la estación expuesta.

4.2.5.1 MACA

MACA (Multiple Access with Collision Avoidance) es el protocolo MAC que ha servido de base para el estándar IEEE 802.11 que es el que especifica el funcionamiento de LANs inalámbricas. MACA resuelve los dos problemas antes mencionados de la siguiente forma:

1. Cuando una estación tiene una trama que transmitir antes de enviarla envía una trama pequeña de aviso (de 30 bytes) denominada RTS (Request To Send). La trama RTS contiene información sobre la longitud de la trama que se pretende transmitir y la estación de destino.

Al recibir la trama RTS la estación de destino, si está en condiciones de recibir la transmisión, responde con otra trama denominada CTS (Clear To Send). La trama CTS también indica la longitud de la trama que se va a recibir.

Ahora apliquemos este protocolo al caso de la estación oculta para ver que ocurre:

1. A transmite una trama RTS a B indicando la longitud de trama que desea enviarle.

B responde con una trama CTS que también especifica la longitud de la trama. En este momento C capta la respuesta de B, por lo que se percata de que va a tener lugar una transmisión en la que B actuará de receptor y sabe que deberá permanecer en silencio durante el tiempo que dure la transmisión (C sabe lo que durará pues conoce la longitud de la trama y la velocidad de la red).

A envía a B la trama correspondiente.

En el caso de la estación expuesta ocurriría lo siguiente:

1. B transmite a A una trama RTS indicando que quiere enviarle datos. En ese momento C se entera de las intenciones de B.

A devuelve a B una trama CTS. Entretanto C, que ha captado el RTS pero no el correspondiente CTS, comprende que aunque detecta que B está transmitiendo el destinatario está fuera de su alcance, por lo que puede comunicar con D cuando quiera, sin esperar a que B termine.

Hasta hace relativamente poco todos los productos LAN inalámbricos del mercado eran de un único fabricante. Sólo en fechas recientes se han estandarizado estos protocolos.

El comité 802.11 del IEEE estandarizó en 1997 varios sistemas basados en ondas de radio (1 y 2 Mb/s) y en luz infrarroja (1,2, 4 y 10 Mb/s).

En Europa el ETSI (European Telecommunications Standards Institute) esta desarrollando otro estándar de LANs inalámbricas denominado HiperLAN, que pretende obtener velocidades de 10 a 20 Mb/s con un alcance de 50 metros utilizando ondas de radio.

4.3 REDES LOCALES Y ESTÁNDARES

Una vez descritos algunos ejemplos de protocolos MAC desde el punto de vista teórico vamos a estudiar las implementaciones prácticas que se han hecho de algunos de ellos en redes locales.

La mayoría de las redes locales han sido estandarizadas por el IEEE, en el comité denominado 802. Los estándares desarrollados por este comité están enfocados a las capas 1 y 2 del modelo de referencia OSI. Este comité se divide en subcomités, cuyo nombre oficial es 'Grupos de Trabajo', que se identifican por un número decimal. En total el comité 802 está formado por diversos grupos de trabajo que dictan estándares sobre LANs y MANs y se organizan de la siguiente forma:

o 802.1: Aspectos comunes: puentes, gestión, redes locales virtuales, etc.

o 802.2: Logical Link Control (LLC). En hibernación e inactivo

o 802.3: Redes CSMA/CD (Ethernet)

o 802.4: Redes Token-Passing Bus. En hibernación e inactivo

o 802.5: Redes Token Ring

o 802.6: Redes MAN DQDB (Distributed Queue Dual Bus). En hibernación e inactivo

o 802.7: Grupo asesor en redes de banda ancha. En hibernación e inactivo.

o 802.8 Grupo asesor en tecnologías de fibra óptica

o 802.9: Redes de servicios Integrados (Iso-Ethernet). En hibernación e inactivo

o 802.10: Seguridad en estándares IEEE 802. En hibernación e inactivo.

o 802.11: WLAN (Wireless LANs)

o 802.12: Redes Demand Priority (100VG-AnyLAN). En hibernación e inactivo

o 802.14: Redes de TV por cable, pendiente de ratificación. Disuelto.

o 802.15: WPAN (Wireless Personal Area Network)

o 802.16: BWA (Broadband Wireless Access)

El 802.1 describe aspectos generales, de arquitectura o aspectos comunes a todas las LANs, por ejemplo gestión y el funcionamiento de puentes. El 802.2 describe la subcapa LLC (Logical Link Control), también común a todas las redes 802. La mayoría de los demás grupos de trabajo (802.3, .4, .5, .6, .9, .11, .12, 14, 15 y 16) tienen que ver con diversas tecnologías LAN o MAN. Cada uno de ellos especifica el nivel físico y la subcapa MAC correspondiente. Por ejemplo el estándar 802.3 describe el nivel físico y el subnivel MAC de la red con protocolo MAC CSMA/CD, mas conocida como Ethernet.

Como se puede observar, el hecho de haber evitado el número 13 en la creación de los grupos no ha librado de su fatídico destino al grupo que ocupa la decimotercera posición. Este grupo se disolvió en mayo del 2000 sin llegar a ratificar ningún estándar vista la poca viabilidad comercial que éste habría tenido.

Los grupos de trabajo 802 no son algo estático; continuamente se están planteando para su estandarización nuevas técnicas y protocolos, nuevos medios físicos, etc. Cuando surge una nueva propuesta el grupo de trabajo correspondiente nombra un grupo de estudio que la analiza, y si el informe es favorable se crea un 'subgrupo' de trabajo (llamado oficialmente proyecto) que eventualmente propone una adenda al estándar para su aprobación. Los proyectos se identifican por letras añadidas al grupo de trabajo del que provienen. A título de ejemplo detallamos a continuación algunos de los proyectos más relevantes del comité 802:

802.1D: puentes transparentes
802.1G: puentes remotos
802.1p: Filtrado por clase de tráfico (Calidad de Servicio)
802.1Q: Redes locales virtuales (VLANs)
802.3u: Fast Ethernet
802.3x. Ethernet Full dúplex y control de flujo
802.3z: Gigabit Ethernet
802.3ab: Gigabit Ethernet en cable UTP-5
802.3ad: Agregación de enlaces

Normalmente todos los estándares IEEE 802 son aprobados más tarde por el ANSI y por la ISO, convirtiéndose así en estándares internacionales. La ISO les da la denominación 8802.x, así por ejemplo el estándar ISO 8802.3 es equivalente al IEEE 802.3

Existen algunas tecnologías de red local que siguen fielmente la arquitectura IEEE 802 pero que han sido estandarizadas por el ANSI y no por el IEEE. Estos estándares, que se han caracterizado por emplear tecnologías muy avanzadas en el momento de su aprobación, son los siguientes:

X3T9.3: HIPPI
X3T9.5: FDDI
X3T11: Fibre Channel

A fin de dar una idea orientativa de los costes de las diversas tecnologías de red local incluimos en la tabla 4.1 los precios aproximados de las tarjetas adaptadoras de red para PC (bus PCI) ofrecidas en 1998 por 3Com, un fabricante líder del sector y por una segunda marca (Accton). Se incluyen también a efectos comparativos las tarjetas de red ATM, ya que aunque ATM no es una red local propiamente dicha se puede utilizar para dicha función.

Tarjetas de red (bus PCI)	3Com (feb. 1998)	Accton (feb. 2000)
10BASE-T (bus ISA)	12.614	2.600
100BASE-TX	20.323	3.400
100BASE-T4	28.908
Token Ring (16 Mb/s)	34.865
ATM 25 Mb/s	56.940
ATM 155 Mb/s UTP-5	95.484
1000BASE-T		90.000
1000BASE-SX (1999)	110.000
ATM 155 Mb/s Fibra MM	121.764
FDDI SAS	226.884
FDDI DAS	314.484

Tabla 4.1.- Precio de las tarjetas de red local para PC

Empezaremos nuestro estudio por las dos redes locales más utilizadas y conocidas, Ethernet y Token Ring. Además de ser las más extendidas su diferente protocolo MAC las convierte en ejemplos contrapuestos interesantes. Nos extenderemos más en el caso de Ethernet debido a su mayor implantación y mayores perspectivas de futuro.

4.4 ETHERNET

Según IDC a finales de 1997 mas del 85% de las conexiones de red instaladas en el mundo eran Ethernet, lo cual representa unos 118 millones de ordenadores. El 17% restante estaba formado por Token Ring, FDDI, ATM y otras tecnologías. Todos los sistemas operativos y aplicaciones populares son compatibles con Ethernet, así como las pilas de protocolos tales como TCP/IP, IPX, NetBEUI y DECnet.

Las previsiones para 1998 eran de que el 86% de las nuevas conexiones LAN fueran Ethernet, lo cual supone mas de 48 millones de interfaces de red y otros tantos puertos de concentradores y conmutadores. Las ventas de ATM, FDDI, Token Ring y otras tecnologías conjuntamente serían de 5 millones de interfaces y 4 millones de puertos, un 10 y un 7% del total respectivamente.

4.4.1 Historia de Ethernet

4.4.1.1 El Nacimiento

En 1970, mientras Abramson montaba ALOHANET en Hawaii, un estudiante recién graduado en el MIT llamado Robert Metcalfe se encontraba realizando sus estudios de doctorado en la Universidad de Harvard trabajando para ARPANET, que era el tema de investigación candente en aquellos días. En un viaje a Washington Metcalfe estuvo en casa de Steve Crocker (el inventor de los RFCs de Internet) donde éste le dejó dormir en el sofá. Para poder conciliar el sueño Metcalfe empezó a leer una revista científica donde encontró un artículo de Norm Abramson en el que describía la red Aloha. Metcalfe pensó como se podía mejorar el protocolo utilizado por Abramson, y escribió un artículo describiendo un protocolo que mejoraba sustancialmente el rendimiento de Aloha. Ese artículo se convertiría en su tesis doctoral, que presentó en 1973. La idea básica era muy simple: las estaciones antes de transmitir deberían detectar si el canal ya estaba en uso (es decir si ya había 'portadora'), en cuyo caso esperarían a que la estación activa terminara. Además, cada estación mientras transmitiera estaría continuamente vigilando el medio físico por si se producía alguna colisión, en cuyo caso se pararía y retransmitiría más tarde. Este protocolo MAC recibiría más tarde la denominación Acceso Múltiple con Detección de Portadora y Detección de Colisiones, o mas brevemente CSMA/CD (Carrier Sense Multiple Access / Colision Detect).

En 1972 Metcalfe se mudó a California para trabajar en el Centro de Investigación de Xerox en Palo Alto llamado Xerox PARC (Palo Alto Research Center). Allí se estaba diseñando lo que se consideraba la 'oficina del futuro' y Metcalfe encontró un ambiente perfecto para desarrollar sus inquietudes. Se estaban probando unos ordenadores denominados Alto, que ya disponían de capacidades gráficas y ratón y son considerados los primeros ordenadores personales. También se estaban fabricando las primeras impresoras láser. Se quería conectar los ordenadores entre sí para compartir ficheros y las impresoras. La comunicación tenía que ser de muy alta velocidad, del orden de megabits por segundo, ya que la cantidad de información a enviar a las impresoras era enorme (tenían una resolución y velocidad comparables a una impresora láser actual). Estas ideas que hoy parecen obvias eran completamente revolucionarias en 1973.

A Metcalfe, el especialista en comunicaciones del equipo con 27 años de edad, se le encomendó la tarea de diseñar y construir la red que uniera todo aquello. Contaba para ello con la ayuda de un estudiante de doctorado de Stanford llamado David Boggs. Las primeras experiencias de la red, que denominaron ‘Alto Aloha Network’, las llevaron a cabo en 1972. Fueron mejorando gradualmente el prototipo hasta que el 22 de mayo de 1973 Metcalfe escribió un memorándum interno en el que informaba de la nueva red. Para evitar que se pudiera pensar que sólo servía para conectar ordenadores Alto cambió el nombre de la red por el de Ethernet, que hacía referencia a la teoría de la física hoy ya abandonada según la cual las ondas electromagnéticas viajaban por un fluido denominado éter que se suponía llenaba todo el espacio (para Metcalfe el 'éter' era el cable coaxial por el que iba la señal). Los dos ordenadores Alto utilizados para las primeras pruebas de Ethernet fueron rebautizados con los nombres Michelson y Morley, en alusión a los dos físicos que demostraron en 1887 la inexistencia del éter mediante el famoso experimento que lleva su nombre.

La red de 1973 ya tenía todas las características esenciales de la Ethernet actual. Empleaba CSMA/CD para minimizar la probabilidad de colisión, y en caso de que ésta se produjera se ponía en marcha un mecanismo denominado retroceso exponencial binario para reducir gradualmente la ‘agresividad’ del emisor, con lo que éste se adaptaba a situaciones de muy diverso nivel de tráfico. Tenía topología de bus y funcionaba a 2,94 Mb/s [1] sobre un segmento de cable coaxial de 1,6Km de longitud. Las direcciones eran de 8 bits y el CRC de las tramas de 16 bits. El protocolo utilizado al nivel de red era el PUP (Parc Universal Packet) que luego evolucionaría hasta convertirse en el que luego fue XNS (Xerox Network System), antecesor a su vez de IPX (Netware de Novell).

En vez de utilizar el cable coaxial de 75 W de las redes de televisión por cable se optó por emplear cable de 50 W que producía menos reflexiones de la señal, a las cuales Ethernet era muy sensible por transmitir la señal en banda base (es decir sin modulación). Cada empalme del cable y cada 'pincho' vampiro (transceiver) instalado producía la reflexión de una parte de la señal transmitida. En la práctica el número máximo de ‘pinchos’ vampiro, y por tanto el número máximo de estaciones en un segmento de cable coaxial, venía limitado por la máxima intensidad de señal reflejada tolerable.

En 1975 Metcalfe y Boggs describieron Ethernet en un artículo que enviaron a Communications of the ACM (Association for Computing Machinery), publicado en 1976 [1]. En él ya describían el uso de repetidores par aumentar el alcance de la red. En 1977 Metcalfe, Boggs y otros dos ingenieros de Xerox recibieron una patente por la tecnología básica de Ethernet, y en 1978 Metcalfe y Boggs recibieron otra por el repetidor. En esta época todo el sistema Ethernet era propietario de Xerox.

Aunque no relacionado con Ethernet merece la pena mencionar que David Boggs construyó en 1975 en el Xerox PARC el primer router y el primer servidor de nombres de la Internet.

4.4.1.2 La alianza DIX

En 1976 Xerox creó una nueva división denominada SDD (Systems Development Division) para el desarrollo de los ordenadores personales y de la red Ethernet (ambos proyectos estaban íntimamente relacionados). Metcalfe, Boggs y varios ingenieros más fueron asignados para trabajar en la mejora de la red. Se introdujeron algunos cambios en la tecnología, y por razones de marketing se decidió cambiar el nombre de la red de Ethernet a X-wire.

Por aquellos años la tendencia de la mayoría de los fabricantes era hacia arquitecturas de redes jerárquicas. Un ejemplo claro en este sentido lo constituía la arquitectura SNA (Systems Network Architecture), anunciada por IBM en 1974. La filosofía de SNA se basaba en dar acceso a través de la red al usuario final desde un terminal 'tonto' a un ordenador central o 'mainframe'. Para ello se definían diferentes tipos de equipos con funcionalidades distintas y una estructura fuertemente jerárquica. Una configuración típica de SNA comprendía cuatro niveles diferentes desde el terminal al mainframe.

El planteamiento de Xerox era radicalmente opuesto y novedoso. Cada usuario disponía de un ordenador conectado directamente a la red local, integrando en él todas las funciones. No existía ningún control centralizado de la red. La comunicación entre dos usuarios cualesquiera ocurría directamente, sin intermediarios y en condiciones de igual a igual ('peer to peer'). Ligada a esta arquitectura distribuida estaba la necesidad - no percibida entonces por la mayoría de los usuarios - de una red de muy alta velocidad para los estándares de la época (baste recordar que por aquel entonces los módems mas veloces eran de 1200 b/s, y en el año 1976 Intel anunció el procesador 8080 que funcionaba a 4,77 MHz).

Hoy en día sabemos que el planteamiento de Xerox era el correcto. Sin embargo, como en tantas otras ocasiones Xerox no supo o no pudo aprovechar comercialmente este acierto. En el caso de Ethernet jugaba en su contra el hecho de ser una tecnología propietaria y no ser Xerox una empresa lo suficientemente grande como para imponer sus productos frente a sus competidores, aspecto fundamental tratándose de comunicaciones. Seguramente también influyó el hecho de ser una tecnología demasiado avanzada para su época. Metcalfe comprendió perfectamente que Ethernet solo podría avanzar si se desarrollaba como un estándar abierto y en cooperación con otros fabricantes, puesto que solo así obtendría el impulso comercial y tecnológico necesario.

Metcalfe abandonó Xerox en enero de 1979 para realizar tareas de consultoría con el MIT y con DEC (Digital Equipment Corporation). Por aquellos años DEC estaba interesada en Ethernet pero las patentes que tenía Xerox le dificultaban adoptar esa tecnología. Metcalfe propuso entonces a DEC que realizara un consorcio con Xerox; propuso además que Intel se uniera al grupo para asegurar que los productos desarrollados se pudieran integrar en chips de bajo costo.

Los miembros del consorcio DIX (DEC-Intel-Xerox) llegaron a un acuerdo en todos los aspectos excepto en el nombre X-wire. DEC e Intel no aceptaban que el nombre de la red empezara por X, por lo que Xerox volvió al nombre inicial Ethernet que parecía satisfacer a todos. También por aquel entonces se decidió subir la velocidad de la red a 10 Mb/s, ya que se consideró que esto era factible con la tecnología existente a unos precios razonables. A la Ethernet original de 2,94 Mb/s se la conoce actualmente como Ethernet Experimental para distinguirla de la de 10 Mb/s que fue la primera que apareció como producto comercial.

Una vez constituida la alianza DIX Metcalfe estimó que se produciría una gran demanda de productos compatibles con Ethernet, por lo consideró que era un buen momento para crear una compañía especializada en este campo. En junio de 1979 creó su propia empresa especializada en Computadores, Comunicaciones y Compatibilidad, mas conocida como 3Com. 3Com adoptó todos los estándares emergentes, no solo Ethernet sino también los protocolos TCP/IP, por ejemplo.

Metcalfe también intentó convencer a IBM en 1980 de que adoptara la tecnología Ethernet, pero entonces IBM aun estaba pensando fundamentalmente en arquitecturas mainframe, con un ordenador central al que se conectaban terminales 3270, que era el tipo de terminales utilizado por los grandes sistemas de IBM.

En 1990 Metcalfe, ya multimillonario, se retiró de 3Com. Actualmente vive en Boston donde ejerce como periodista y es vicepresidente de International Data Group, grupo editorial que publica algunas de las revistas más prestigiosas en el mundo de la informática como PC World, Mac World, Computerworld, Linux World, etc. Regularmente escribe artículos, da charlas y organiza eventos y debates sobre el presente y futuro de las tecnologías de la información y las comunicaciones. A través de sus artículos y ponencias generalmente presenta opiniones críticas y provocadoras acerca de la manera como evoluciona el mundo de Internet y las redes informáticas.

David Boggs siguió trabajando en el Xerox PARC hasta 1984, en que pasó a trabajar en el Western Research Laboratory de DEC (hoy Compaq) también en Palo Alto. En 1988 Boggs publicó un artículo sobre el rendimiento de Ethernet que es considerado un clásico en la materia [2].

Por su parte el consorcio DIX siguió adelante y en septiembre de 1980 publicó las especificaciones de Ethernet Versión 1.0 conocidas como 'libro azul'. La publicación del libro azul hizo de Ethernet la primera tecnología de red local abierta multivendedor, ya que a partir de ese momento cualquier fabricante podía construir equipamiento conforme con la norma Ethernet. Como muestra de su política aperturista Xerox aceptó entonces licenciar su tecnología patentada a todo el que lo quisiera por una cuota reducida, consistente en el pago de 1,000 dólares por cada asignación de un rango de los 24 primeros bits de las direcciones MAC, que eran gestionadas por Xerox (mas tarde con la aprobación de los estándares 802 la gestión de esas direcciones pasó a desempeñarla el IEEE, que cobra actualmente 1,250 dólares por rango, en concepto de tareas administrativas). En 1982 se publicó Ethernet Versión 2.0, que fue la última especificación de Ethernet publicada por DIX. En las especificaciones de Ethernet el único medio físico que se contemplaba era el cable coaxial grueso hoy conocido como 10BASE5. En ese mismo año 1982 Xerox liberó la marca registrada que ostentaba sobre el nombre Ethernet.

4.4.1.3 Las relaciones con IEEE y la estandarización

A finales de los años setenta se realizaban paralelamente a Ethernet otras experiencias de redes locales en universidades y centros de investigación utilizando diversas tecnologías y topologías en bus, anillo o estrella. Había muy pocos productos comerciales disponibles y ningún estándar al respecto, la mayoría de las redes locales eran modelos únicos construidos de forma artesanal.

Para resolver esta situación en febrero de 1980 el IEEE puso en marcha un proyecto con el objetivo de acordar la tecnología idónea para establecer el estándar de red local. De esta forma los productos de diferentes fabricantes podrían interoperar, habría libre competencia y los precios bajarían, beneficiando al usuario. El proyecto se denominó 802 por se este el número que correspondía al siguiente proyecto en la numeración del IEEE (no por alusión al mes y año de su creación como se ha recogido en diversas referencias bibliográficas). Inicialmente el proyecto no tenía unas ideas claras de como debía ser la tecnología a utilizar, pero si de cómo debía llevarse a cabo el proceso de estandarización: debía ser abierto, ordenado y justo. Lo último que se quería era recibir una propuesta ya terminada de un reducido grupo de fabricantes. Esto fue precisamente lo que ocurrió cuando dos meses mas tarde, en abril de 1980, la alianza DIX informó al comité 802 que estaba terminando el diseño y especificación de una tecnología de red local, que la propondría para su estandarización cuando estuviera terminada, pero que entretanto el comité no podría participar en su elaboración. Al margen del espíritu abierto antes mencionado y sus indudables méritos técnicos la forma como se propuso la adopción de Ethernet al comité 802 no fue precisamente un derroche de tacto.

Después de la propuesta de DIX para la adopción de Ethernet el comité 802 recibió otra de General Motors de una red denominada Token Bus, también con topología de bus pero que utilizaba un protocolo MAC basado en paso de testigo. Algo mas tarde IBM presentó una tercera propuesta de una red con topología de anillo y paso de testigo que recibía el nombre de Token Ring. Finalmente, viendo que no sería posible elaborar un único estándar a gusto de todos y considerando que el apoyo de la industria a cada una de las tres propuestas era demasiado importante como para descartar cualquiera de ellas, en 1982 el comité 802 optó en una polémica decisión por aceptar las tres propuestas y crear un subcomité para cada una de ellas: 802.3 para CSMA/CD (Ethernet), 802.4 para Token Bus y 802.5 para Token Ring (802.1 y 802.2 cubrirían aspectos generales y comunes a las tres tecnologías).

Dado el polémico estreno de Ethernet antes descrito no es de extrañar que en el comité 802 (mas tarde subcomité 802.3) hubiera cierta aversión hacia la propuesta de la alianza DIX. Según algunos había incluso cierto deseo de fastidiar, para lo cual se revisó a fondo la propuesta. En cualquier diseño de ingeniería complejo hay un montón de aspectos cuestionables y susceptibles de modificación, por lo que si se dispone del tiempo suficiente para revisar todos los detalles de una propuesta siempre se pueden encontrara algunos que se podrían haber decidido de manera diferente. El comité 802.3 pasó varios meses revisando el estándar Ethernet e introdujo diversos cambios, el mas importante de los cuales fue la sustitución en la trama del campo tipo de dos bytes de longitud (que especifica el protocolo del nivel de red) por un campo longitud, inexistente hasta entonces. Los diseñadores originales de Ethernet consideraron en su momento que este campo era innecesario porque la mayoría de los protocolos a nivel de red (y ciertamente todos aquellos en los que ellos estaban interesados) incluyen en la información de cabecera un campo indicando la longitud; aun en el caso de que esto no ocurriera la longitud de la trama se puede averiguar simplemente contando el número de bytes que ésta contiene (siempre y cuando no haya campo de relleno, es decir que la trama tenga al menos 64 bytes de longitud). Sin embargo el comité 802.3 creyó conveniente incluir el campo longitud en vez del campo tipo para no condicionar la información que debiera aparecer en el nivel de red. Casualmente esta pequeña modificación tenía el efecto colateral de hacer incompatible el estándar IEEE 802.3 con Ethernet DIX, cosa que según algunos era el verdadero objetivo de muchos de los miembros del comité que votaron a favor de esta modificación [3].

Los valores utilizados para identificar el protocolo, conocidos como ‘Ethertypes’, se establecían en una tabla que mantenía Xerox y en la que registraba cualquier nuevo protocolo que se registrara, asignándole un valor en el campo de dos bytes. El problema de incompatibilidad producido por la decisión del IEEE lo resolvió Xerox asignando a todos los protocolos nuevos valores superiores a 1536 bytes, que es el valor máximo del campo longitud [2], y trasladando a valores superiores los protocolos ya registrados, que afortunadamente eran aun pocos; por ejemplo el PUP (Parc Universal Packet), protocolo utilizado en la Ethernet Experimental, tenía el código 512 y se le puso el 2560. De esta forma era posible saber si la trama tenía formato DIX u 802.3 analizando el valor del campo tipo/longitud; si era mayor de 1536 se trataba de una trama DIX y por tanto el campo representaba el Ethertype, de lo contrario era una trama 802.3 y estos dos bytes indicaban la longitud. Los dos formatos eran incompatibles entre sí, pero al menos podían diferenciarse y por tanto coexistir en una misma red.

En el caso de una trama 802.3 la información sobre el protocolo a nivel de red aparece en la cabecera LLC (Logical Link Control) que se encuentar en la parte de datos de la trama MAC y cuyo formato veremos mas tarde. La estructura de esta cabecera, común a todas las redes locales 802, se especifica en el estándar IEEE 802.2. El trabajo conjunto del IEEE y de la ISO en el diseño de la cabecera LLC produjo un diseño absurdo e innecesariamente complejo [3] que hace que en la mayoría de los protocolos sea necesario analizar los cuatro campos y los ocho bytes de la cabecera LLC SNAP [4] para averiguar lo que Xerox conseguía usando solo dos bytes en la cabecera DIX. Más aun, en la mayoría de los casos los primeros seis bytes de la cabecera LLC solo sirven, como veremos más tarde, para especificar que en los dos siguientes se encuentra el Ethertype correspondiente al protocolo utilizado. Esto complica el proceso de los paquetes y añade un overhead innecesario, sobre todo en el caso de tramas pequeñas. Por este motivo el formato DIX es mas utilizado, empleándose por ejemplo en TCP/IP, DECNET fase 4, LAT (Local Area Transport, de DEC) y algunas implementaciones de IPX (Netware de Novell). El formato 802.3/LLC es utilizado normalmente en Appletalk fase 2, NetBIOS y algunas implementaciones de IPX.

En 1997 el grupo de trabajo 802.3x estandarizó un mecanismo de control de flujo para Ethernet Full Dúplex del cual hablaremos en detalle más adelante. Desde el punto de vista de la subcapa MAC el control de flujo se consideraba un protocolo nuevo, por lo que había que asignarle un valor nuevo en la tabla de tipos. Entonces se vió que resultaba más eficiente disponer de la información sobre el tipo de protocolo en la cabecera MAC, como hacía el formato DIX, ya que esto permitía tratar las tramas a bajo nivel, es decir por hardware; el control de flujo es una tarea de máxima prioridad y se debe realizar con la máxima eficiencia posible. El comité podía haber optado por estandarizar el formato DIX únicamente para las tramas de control de flujo, y mantener el 802.3/LLC para los demás protocolos, pero finalmente decidió aceptar ambos formatos para todos los protocolos considerando válidos los dos significados, tipo y longitud, para el polémico campo de dos bytes. La elección de cual significado es aplicable en cada caso concreto se haría en función del valor de este campo, si era igual o menor que 1536 sería longitud y si era mayor sería un Ethertype. Dicho de otro modo el comité IEEE 802.3 estandarizó en 1997 lo que ya venía siendo práctica habitual en todos los fabricantes de hardware y software desde los principios de Ethernet. De alguna manera esto representaba una reconciliación quince años mas tarde con DIX (y con el mundo real).

Tradicionalmente Xerox se ocupaba de la labor administrativa de asignación de ‘Ethertypes’. Desde 1997, con la adopción del formato DIX como parte del estándar 802.3 el IEEE reemplazó a Xerox en esta función. Los valores de Ethertype vigentes se pueden consultar por ejemplo en el web de la IANA (Internet Assigned Number Authority) www.iana.org/numbers.html.

Finalmente el 24 de junio de 1983 el IEEE aprobó el estándar 802.3, contemplando como medio físico únicamente el cable coaxial grueso, al cual denominó 10BASE5 [5] .En el estándar se recomienda que el cable sea de color amarillo con el único objetivo de que no se confunda en las conducciones con los cables de alimentación eléctrica. El estándar IEEE 802.3 fue propuesto a continuación a ANSI, que lo aprobó en diciembre de 1984, elevándolo así a la categoría de estándar conjunto ANSI/IEEE 802.3. Después fue propuesto para su aprobación por el ISO, que lo aceptó como DIS (Draft International Standard) en 1985 bajo la denominación ISO/IEC 8802-3, pasando luego al estado de IS (International Standard). Como detalle curioso diremos que la especificación de ISO es técnicamente equivalente pero no idéntica a la de IEEE/ANSI, el documento difiere en las unidades (que están basadas en el sistema métrico), se utiliza terminología internacional, se eliminan referencias a otros estándares nacionales de Estados Unidos, y se formatea el documento para papel de tamaño ISO A4.

4.4.1.4 Nuevos tipos de cables

Los componentes de las primeras redes Ethernet (repetidores, transceivers, tarjetas de red, etc.) eran muy caros. El cable coaxial y el cable ‘drop’ (el que conectaba el equipo al cable coaxial), aunque tenían un costo elevado resultaban despreciables al lado de los componentes electrónicos. Gradualmente la electrónica fue bajando de precio, con lo que los cables y su instalación empezaban a representar una parte significativa del presupuesto de una red. Además el elevado grosor y rigidez de estos cables los hacía poco apropiados para entornos de oficina. Los usuarios demandaban cables más baratos y más finos. En respuesta a estos requerimientos aparecieron a partir de 1982 productos en el mercado que permitían utilizar Ethernet sobre cable coaxial RG58, también de 50 W pero más fino y más barato. Este cable utilizaba conectores BNC en vez de los voluminosos conectores tipo ‘N’, y no requería cable drop ya que el equipo se podía enchufar directamente al cable coaxial mediante un conector en T, estando en este caso la función del transceiver integrada en la tarjeta de red. En conjunto se conseguía un ahorro importante respecto al cable grueso tradicional, razón por la cual este cable se conocía con el nombre de cheapernet ('red más barata'). El cable cheapernet tenía un menor apantallamiento que el 10BASE5, lo cual le confería una mayor atenuación y por ende menor alcance (185 m por segmento en vez de 500 m). La interconexión de segmentos cheapernet (o thinwire como también se le llamaba) con segmentos de coaxial grueso (o thickwire) se podía realizar mediante repetidores. El cable coaxial fino fue incorporado al estándar 802.3 con la denominación 10BASE2 mediante una adenda que el IEEE aprobó en 1985.

Para permitir mayores distancias y mejorar la conectividad entre edificios también se incluyó la fibra óptica como medio de transmisión. El FOIRL (Fiber Optic Inter-Repeater Link) fue incorporado al estándar 802.3 en 1989, y permitía unir repetidores a una distancia máxima de 1000 m. Actualmente FOIRL esta en desuso, en su lugar se emplea 10BASE-FL que permite unir repetidores y equipos con una distancia máxima de 2.000 m.

4.4.1.5 El cable de pares trenzados y el cableado estructurado

Las primeras redes locales utilizaban cables especiales, normalmente coaxiales ya que presentaban menor atenuación y soportaban mejor las altas frecuencias. Dado que el cable era instalado a propósito se elegía el más conveniente por razones puramente técnicas. Paralelamente a la red local los edificios tenían la red de telefonía que utilizaba cable de pares no apantallados. Por imperativos legales estas redes de telefonía eran instaladas y mantenidas en todo el mundo por las compañías telefónicas, incluso dentro de los edificios. El 1 de enero de 1984 se produjo en Estados Unidos una decisión judicial histórica que rompió el monopolio en telefonía ostentado hasta entonces por AT&T en ese país. Esta es probablemente la decisión judicial que más ha influido en el mundo de las telecomunicaciones. Esta decisión tuvo entre otras muchas la consecuencia de que las empresas fueran de la noche a la mañana propietarias de su red telefónica interior y a partir de entonces pudieran gestionarla. La red telefónica estaba omnipresente y su costo de instalación y mantenimiento era inferior al de la red basada en cable coaxial, incluso a cheapernet. Después de todo AT&T y las telefónicas de todo el mundo llevaban muchos años cableando edificios y algo debían saber del tema. Por ejemplo un operario era capaz de poner un conector RJ-45, utilizado habitualmente en telefonía, en menos tiempo de lo que tardaba en sacar de la bolsa los componentes de un conector BNC. Además, la red telefónica tenía una topología en estrella organizada jerárquicamente que la hacía mas versátil y robusta que una de tipo bus. El diagnóstico y aislamiento de problemas era más rápido y sencillo. Estos factores provocaron una demanda por parte de los usuarios en el sentido de aprovechar el cableado telefónico de pares trenzados para proveer el acceso a la red local de los puestos de trabajo. Dicho de otro modo, los usuarios requerían un cableado integral para voz y datos.

Ya en el mismo año 1984 el comité 802.3 empezó a estudiar la posibilidad de implementar Ethernet en cable telefónico. Por aquel entonces muchos expertos aseguraban que una red de 10 Mb/s jamás podría funcionar sobre cable de pares sin apantallar, debido a la mayor atenuación de este medio a altas frecuencias. Sin embargo ya en 1985 la empresa Synoptics [6] sacó al mercado un producto denominado LattisNet que permitía utilizar cableado UTP para constituir redes Ethernet de 10 Mb/s. En 1987 el comité 802.3 estandarizó una red denominada StarLAN [7] o 1BASE5, variante de Ethernet que funcionaba a 1 Mb/s sobre cable de pares no apantallado a distancias máximas de 500 m. En 1990 se estandarizó 10BASE-T (T = 'Twisted')[8] que utilizaba cable de pares trenzados no apantallado (UTP, Unshielded Twisted Pair). Esto significó en la práctica el final de StarLAN ya que la mayoría de los usuarios que habían optado provisionalmente por esa red migraron a 10BASE-T que ofrecía mayor velocidad y evitaba tener que utilizar costosos puentes conversores de velocidad para conectar la red de 1 Mb/s con la de 10 Mb/s.

Paralelamente al desarrollo por parte del IEEE de los estándares de red local para cable UTP se desarrollaron normativas de cableado de telecomunicaciones para edificios comerciales que permitían constituir lo que se conoce como cableado estructurado. Inicialmente se utilizaron sistemas propietarios (IBM Cabling System, DECConnect, AT&T SYSTIMAX, etc.) pero al cabo de unos años se elaboraron normativas independientes. La primera fue la EIA/TIA 568 que se publicó en 1991, seguida poco después por la ISO/IEC 11801. Actualmente estas dos son las mas utilizadas, en sus versiones de 1995. Para asegurar máxima compatibilidad con cualquier fabricante es conveniente seguir simultáneamente tanto la norma ISO como la EIA siempre que sea posible.

4.4.1.6 Puentes y conmutadores

Ya en su artículo de 1976 [1] Metcalfe y Boggs mencionaban la posibilidad de extender la red mediante el uso de repetidores 'filtradores de tráfico' o de paquetes. Los primeros puentes transparentes fueron desarrollados por DEC a principios de los ochenta, apareciendo los primeros productos comerciales en 1984. Aunque caros y de bajo rendimiento comparados con los actuales, suponían una alternativa interesante a los routers por su sencillez y relación precio/prestaciones. En 1987 el IEEE se puso en marcha para estandarizar el funcionamiento de los puentes transparentes. El resultado fue el estándar 802.1D aprobado en 1990.

En 1991 una empresa de reciente creación denominada Kalpana [9] comercializó un nuevo tipo de puentes Ethernet con un número elevado de interfaces y alto rendimiento, supuestamente capaces de dar los 10 Mb/s de tráfico simultáneamente en cada una de sus interfaces. Estos equipos se anunciaban como conmutadores LAN para diferenciarlos de los tradicionales puentes, aun cuando su principio de funcionamiento era el mismo. Para conseguir el alto rendimiento se implementaba el algoritmo de filtrado de paquetes a bajo nivel en el hardware de los equipos.

El mercado de los conmutadores LAN tuvo y tiene un crecimiento considerable, especialmente porque daba una cómoda vía de crecimiento a los usuarios de Ethernet sin necesidad de cambiar a otras tecnologías.

Llevada al extremo la filosofía de los conmutadores LAN produce redes en las que cada puerto está dedicado a un ordenador. De esta forma cada usuario puede disfrutar de 10Mb/s de capacidad y su tráfico no es visto por ningún otro ordenador salvo por aquel al que va dirigido, con lo que se mejora el rendimiento y la seguridad de la red. El uso de redes conmutadas nos lleva de una situación de medio compartido a una de medio dedicado donde ya no es necesario el uso del protocolo CSMA/CD. Por otro lado, los dos medios físicos mas populares de Ethernet (10BASE-T y 10BASE-FL) ofrecen un canal diferente para cada sentido de la comunicación. Aprovechando estas dos circunstancias se implementó lo que se denomina Ethernet full-dúplex, que aprovecha la posibilidad que brinda el medio físico para establecer dos canales dedicados de 10 Mb/s, uno para cada sentido, como si se tratara de una línea punto a punto. Aunque los productos comerciales Ethernet full-dúplex están en el mercado desde poco después de la aparición de los conmutadores LAN su funcionamiento no fue estandarizado por el IEEE hasta 1997 en la especificación 802.3x, donde además se estableció como ya hemos comentado un control de flujo para su funcionamiento.

4.4.1.7 Ethernet rápida

Cuando Ethernet comenzó su andadura comercial a principios de los ochenta muchos consideraban que 10 Mb/s era una velocidad excesiva y que esto encarecía innecesariamente la red; por aquel entonces ningún ordenador era capaz de enviar a esa velocidad, por ejemplo en 1983 un mainframe VAX 8600 (considerado en su tiempo una máquina potente) podía transmitir unos 6 Mb/s en el mejor de los casos; con los protocolos de transporte habituales los rendimientos eran sensiblemente inferiores.

En 1988 Van Jacobson (seguramente la persona que mas ha contribuido a mejorar el rendimiento del protocolo TCP), envió un artículo a las news de usenet informando que había conseguido una velocidad de transferencia de 8 Mb/s sobre Ethernet entre dos estaciones de trabajo Sun utilizando una versión optimizada de TCP. A partir de ese momento las mejoras en el hardware (CPUs, discos, tarjetas controladoras, etc.) y en el software (sistemas operativos, protocolos, etc.) empezaron a hacer cada vez mas fácil que un solo equipo saturara una Ethernet.

Entonces la única solución estándar para pasar a velocidades superiores era FDDI (que por cierto es un estándar ANSI e ISO, pero no IEEE). Sin embargo FDDI nunca se mostró como una alternativa interesante para los usuarios de Ethernet. Aunque robusta y fiable esta red tenía una gestión compleja y permanecía en unos precios inaccesibles para la mayoría de las instalaciones, o solo asumibles cuando se trataba de la red principal o 'backbone', pero no para el acceso del usuario final. Su compatibilidad con Ethernet es reducida, ya que FDDI no es CSMA/CD y utiliza una estructura de trama diferente. Esto complicaba las cosas cuando se quería migrar desde Ethernet, y más aun si habían de coexistir ambas redes.

En un intento por cubrir esta demanda de redes de alta velocidad compatibles con Ethernet y de bajo costo Grand Junction [10] sacó en 1992 una versión de Ethernet que funcionaba a 100 Mb/s. Esto tuvo un éxito considerable y provocó la creación ese mismo año en el seno del IEEE de un grupo de estudio sobre redes de alta velocidad, con la misión de estudiar la posibilidad de ampliar el estándar a 100 Mb/s. Inicialmente se plantearon dos propuestas:

o Mantener el protocolo CSMA/CD en todos sus aspectos salvo la velocidad que se aumentaría en un factor 10. Al mantener constante el tamaño de trama mínimo (64 bytes) se reducía en diez veces la distancia máxima entre estaciones, lo cual daba un diámetro máximo de unos 400 metros. El uso de CSMA/CD suponía además la ya conocida pérdida de eficiencia debida a las colisiones.

o Aprovechar la revisión para crear un nuevo protocolo MAC sin colisiones mas eficiente y con mas funcionalidades (mas parecido en cierto modo a Token Ring), pero manteniendo la misma estructura de trama de Ethernet.

La primera propuesta tenía la ventaja de acelerar el proceso de estandarización y el desarrollo de productos, mientras que la segunda era técnicamente superior. El subcomité 802.3 decidió finalmente adoptar la primera propuesta, que siguió su camino hasta convertirse en lo que hoy conocemos como Fast Ethernet, incorporado a la norma 802.3 en junio de 1995 a propuesta del grupo de trabajo 802.3u. Para acelerar el proceso de estandarización el grupo 802.3u utilizó para el nivel físico buena parte de las especificaciones ya desarrolladas por ANSI para FDDI [11]. Los medios físicos soportados por Fast Ethernet son fibra óptica multimodo, cable UTP categoría 3 y categoría 5 y cable STP (Shielded Twisted Pair).

Los partidarios de la segunda propuesta, considerando que sus ideas podían tener cierto interés, decidieron crear un nuevo subcomité del IEEE, el 802.12, que desarrolló la red conocida como 100VG-AnyLAN. Durante cierto tiempo hubo competencia entre ambas redes por conseguir cuota de mercado; hoy en día la balanza se decanta ampliamente hacia Fast Ethernet. Algunos fabricantes (notablemente HP, autor de la propuesta) aun mantienen un amplio catálogo de productos para 100VG-AnyLAN. Merece la pena recalcar que 100VG-AnyLAN, aunque puede funcionar con estructura de trama Ethernet (y también con Token Ring, de ahí la denominación de AnyLAN) no utiliza CSMA/CD y por tanto no puede denominarse Ethernet. Alguna literatura confunde esta red con la Fast Ethernet.

Las redes Fast Ethernet se extendieron con una rapidez incluso superior a las expectativas mas optimistas. Como consecuencia de esto los precios bajaron y su uso se popularizó hasta el punto de que se utilizaba Fast Ethernet no solo en los enlaces troncales sino en la conexión del usuario final. Para mantener un diseño coherente y equilibrado de la red se requerían velocidades superiores en el backbone, requerimiento que no podía ser satisfecho con los productos habituales, salvo quizá por ATM a 622 Mb/s, pero a unos precios astronómicos. Este hecho junto con la experiencia positiva habida con Fast Ethernet animó al subcomité 802.3 a iniciar en 1995 otro grupo de trabajo que estudiara el aumento de velocidad de nuevo en un factor diez, creando lo que se denomina Gigabit Ethernet. Aunque en 1995, recién aprobado Fast Ethernet, parecía descabellado plantear velocidades de esa magnitud para redes convencionales, las previsiones de aumento en rendimiento y nivel de integración de los chips hacían prever entonces que para 1998 sería factible construir tarjetas de red y componentes que funcionaran a 1 Gb/s con tecnología convencional a precios asequibles [12]. Siguiendo un calendario similar al empleado en Fast Ethernet y con un grupo de personas parecido se inició un proceso que culminó el 29 de junio de 1998 con la aprobación del suplemento 802.3z.

De forma análoga a lo que Fast Ethernet hizo con FDDI para el nivel físico, el grupo que elaboró las especificaciones de Gigabit Ethernet se basó en lo posible en los estándares ANSI de Fibre Channel a 800 Mb/s, aumentando adecuadamente las velocidades. Se pretendía poder utilizar los mismos medios físicos que en Fiber Channel: emisores láser con fibra óptica multimodo y monomodo, cable de pares trenzados apantallado y además cable UTP categoría 5. En el caso de la fibra multimodo se quería llegar a una distancia mayor que en Fibre Channel, lo cual planteó algunos problemas técnicos que retrasaron en unos meses la elaboración del estándar. En el caso de Gigabit Ethernet sobre cable UTP categoría 5 el reto tecnológico era de tal magnitud que en marzo de 1997 se decidió segregar un nuevo grupo de trabajo, el 802.3ab, para desarrollar exclusivamente este caso y no retrasar por él la aprobación del resto de medios físicos. El estándar de Gigabit Ethernet sobre cable UTP categoría 5 se aprobó en junio de 1999.

Finalmente, y siguiendo en la tradición ya establecida de aumentar cada vez la velocidad en un factor diez, el IEEE aprobó en enero del 2000 la creación de un grupo de estudio de alta velocidad para la eventual estandarización de una Ethernet de 10 Gigabits. Las decisiones sobre como se implementará el nivel físico de esta red se encuentran todavía en fases muy preliminares.

La tabla 4.2 resume los hechos mas importantes que han marcado la historia de Ethernet.

1970	o Abramson realiza primeras experiencias de redes broadcast en Hawaii (ALOHANET) mediante el protocolo MAC Aloha.
1972	o Roberts propone el protocolo MAC Aloha ranurado
22/5/1973	o Robert Metcalfe y David Boggs conectan dos ordenadores Alto con cable coaxial a 2,94 Mb/s en el Xerox Palo Alto Research Center, mediante una red denominada Ethernet.
5/1975	o Metcalfe y Boggs escriben un artículo describiendo Ethernet, y lo envían para su publicación a Communications of the ACM.
1976	o Xerox crea SSD, una división para el desarrollo de los ordenadores personales y la red X-wire (nuevo nombre de Etherent).
1979	o Se constituye la alianza DIX (DEC-Intel-Xerox) para impulsar el desarrollo técnico y comercial de la red. Se vuelve al nombre original de Ethernet. o Metcalfe abandona Xerox y crea 3Com.
2/1980	o El IEEE crea el proyecto 802.
4/1980	o DIX anuncia al IEEE 802 que está desarrollando una tecnología de red local que pretende estandarizar.
9/1980	o DIX publica Ethernet (libro azul) versión 1.0. Velocidad 10 Mb/s.
1981	o 3Com fabrica las primeras tarjetas Ethernet para PC (10BASE5).
1982	o DIX publica Ethernet (libro azul) versión 2.0. o 3Com produce las primeras tarjetas 10BASE2 para PC.
24/6/1983	o IEEE aprueba el estándar 802.3, que coincide casi completamente con DIX Ethernet. El único medio físico soportado es 10BASE5.
1/1/1984	o AT&T se subdivide en AT&T Long Lines y 23 BOCs (Bell Operating Companies). Los tendidos de cable telefónico internos de los edificios pasan a ser propiedad de los usuarios.
1984	o DEC comercializa los primeros puentes transparentes
21/12/1984	o ANSI aprueba el estándar IEEE 802.3.
1985	o Se publica el estándar IEEE 802.3 o ISO/IEC aprueba el estándar 8802-3, versión adaptada del IEEE 802.3. o IEEE añade al estándar el cable 10BASE2. o Primeros productos 10BASE-T de Synoptics.
1987	o IEEE estandariza StarLAN (1BASE5, Ethernet a 1 Mb/s con cable UTP). o Comienza la estandarización de los puentes transparentes
1989	o IEEE estandarizaFOIRL (Fiber Optic Inter-Repeater Link)
1990	o IEEE estandariza 10BASE-T. o Primeros conmutadores Ethernet de Kalpana o Se aprueba el estándar 802.1D (puentes transparentes)
1992	o Primeros productos Fast Ethernet, fabricados por Grand Junction o IEEE crea el grupo de estudio para redes de alta velocidad (100 Mb/s)
1993	o Primeros conmutadores Full Dúplex
6/1995	o Se estandariza Fast Ethernet (100BASE-FX, 100BASE-TX y 100 BASE-T4)
10/1995	o IEEE crea el grupo de estudio para redes de 1 Gb/s
7/1996	o Se aprueba el grupo de trabajo 802.3z para la estandarización de Gigabit Ethernet
3/1997	o Se escinde del grupo de trabajo 802.3z el 802.3ab para la estandarización de 1000BASE-T (Gigabit Ethernet sobre cable UTP categoría 5).
1997	o Se aprueba el estándar Ethernet full-dúplex (802.3x), incluyendo en el estándar el formato de trama DIX. o Se publican los drafts 802.1p y 802.1Q (VLANs y prioridades) o Primeros productos comerciales Gigabit Ethernet
29/6/1998	o Se estandariza Gigabit Ethernet (802.3z) que comprende los medios físicos 1000BASE-SX, 1000BASE-LX y 1000BASE-CX.
6/1999	o Se estandariza 1000BASE-T (Gigabit Ethernet sobre cable UTP-5).
1/2000	o Se crea un grupo de estudio de altas velocidades para valorar la posibilidad de estandarizar una Ethernet de 10 Gigabits

Tabla 4.2.- Cronología de Ethernet

4.4.2 El medio físico

4.4.2.1 Cables de cobre

Actualmente casi todo el cable de cobre utilizado en redes Ethernet es el de pares trenzados sin apantallar (UTP, Unshielded Twisted Pair); mas raramente se emplea cable de pares trenzados apantallado (STP, Shielded Twisted Pair) o también cable coaxial. Esto no se debe a las virtudes del cable UTP, que es peor que el STP o el coaxial para transmitir señales de alta frecuencia, sino al requerimiento de utilizar un cable de bajo costo que permita un cableado integral de voz y datos.

Como ya hemos visto en el capítulo 2 las normativas de cableado estructurado clasifican los diferentes tipos de cable de pares trenzados en categorías de acuerdo con sus características. Una categoría mayor soporta mayores frecuencias y supone una mayor capacidad para transmitir datos.

Cuando se publicó la primera normativa de cableado estructurado en julio de 1991 (la EIA/TIA 568) solo se especificaba la categoría 3. Un mes mas tarde se publicaba la especificación de las categorías 4 y 5. Desde entonces no se han estandarizado nuevas categorías, pero las especificaciones han sido revisadas y modificadas varias veces. La última modificación se realizó en 1995, por tanto no es lo mismo un cable certificado categoría 5 según la norma de 1991 que según la de 1995. A falta de una especificación aprobada para categorías superiores a la 5 las redes que transmiten a alta velocidad sobre cable UTP-5, tales como Fast Ethernet o ATM a 155 Mb/s, han tenido que ir apurando cada vez más las prestaciones del cable, reduciendo por tanto el margen de seguridad de las instalaciones.

Como es lógico estos problemas son aun mayores en el caso de Gigabit Ethernet, donde se ha visto que las especificaciones de la categoría 5 actualmente vigente no son suficientemente precisas para asegurar el funcionamiento de 1000BASE-T. Por esto a petición del IEEE se ha iniciado un proceso para añadir parámetros adicionales al proceso de certificación de cables categoría 5. Estos parámetros se incluirán en la normativa TIA/EIA 568-A en lo que se denomina categoría 5E (E de 'Enhanced', mejorada). En ISO/IEC 11801 se harán las mismas modificaciones, pero en vez de definir una categoría nueva se añadirá un apéndice a la especificación de la categoría 5 para incluir estas medidas adicionales. Las modificaciones a la categoría 5 no alteran la frecuencia máxima a la que se comprueba el cable, que seguirá siendo 100 MHz.

Con estas adiciones a la norma se tendrá un mayor margen de seguridad al utilizar cableado categoría 5 en redes de alta velocidad, tales como Fast Ethernet o Gigabit Ethernet. En teoría una instalación categoría 5 certificada con anterioridad a las adiciones debería certificarse nuevamente para saber si cumple la nueva normativa, y en caso contrario modificarse para su correcto funcionamiento con Gigabit Ethernet. Se estima que entre un 5 y un 10% de las instalaciones categoría 5 requerirán este tipo de modificaciones, debido fundamentalmente a problemas relacionados con los conectores. En [5] se especifica el procedimiento a seguir para resolver ese tipo de problemas.

En la actualidad existen cables UTP que superan con creces los requerimientos de la categoría 5 Enhanced, aproximándose algunos a lo que según el borrador actual será la categoría 6. A la espera de que los organismos oficiales aprueben las normas correspondientes, el integrador Anixter ha definido unas categorías propias denominadas niveles. La clasificación actualmente vigente, definida en 1997 y conocida como Levels'97, especifica tres niveles denominados 5, 6 y 7. El nivel 5 corresponde con pequeñas mejoras a la categoría 5. El nivel 6 supone una mejora importante respecto a la categoría 5, coincidiendo con lo que algunos fabricantes denominan categoría 5 de gama alta o 5+. Por último el nivel 7, que ofrece un ancho de banda doble que la categoría 5 con una frecuencia de 200 MHz, podemos considerarlo de prestaciones similares a las que tendrá la futura categoría 6. El lector interesado puede consultar más detalles sobre los niveles de Anixter en la ref. [6].

Cualquier instalación nueva en la que se prevea la posibilidad de utilizar Gigabit Ethernet sobre cable UTP debería considerar la instalación de un cableado que cumpliera como mínimo los requisitos del nivel 6 de Anixter, para reducir el riesgo de problemas.

Incluso en el caso de que un enlace no cumpla la categoría 5E es posible que la instalación funcione correctamente con 1000BASE-T, ya que influyen múltiples factores tales como la calidad de los transceivers utilizados en los equipos. La mejor forma de saberlo es hacer la conexión, provocar un flujo masivo de tráfico entre los dos equipos, y calcular la tasa de errores obtenida, también llamada BER (Bit Error Rate). Para calcular la BER debemos dividir el número de tramas recibidas con CRC erróneo por el número total de bits recibidos (esta información la podemos obtener por ejemplo de las estadísticas de un conmutador); solo se debe considerar el tráfico en el lado receptor, puesto que los equipos nunca detectan errores de CRC en lo que transmiten. Según el estándar la BER no debe ser superior a 10^-10 (es decir un bit erróneo cada 10¹⁰ bits transmitidos). Si obtenemos un valor superior debemos revisar la instalación, mejorándola o rehaciéndola en caso necesario hasta conseguir un BER menor. Para que el resultado sea representativo deberemos transmitir al menos 10¹¹ bits (11,64 Gbytes). Para comprobar el enlace en ambos sentidos habría que realizar la prueba primero transmitiendo desde un equipo y luego desde el otro. Estas pruebas, aunque son la mejor verificación del correcto funcionamiento de la red, estrictamente hablando solo son válidas para la configuración concreta de equipos y cables con los que se prueba; no todos los transceivers tienen la misma tolerancia al ruido, por lo que en situaciones que se encuentren fuera de normas podrían presentarse problemas al cambiar los equipos conectados.

La tabla 4.3 resume los medios físicos de cobre más utilizados en Ethernet, Fast Ethernet y Gigabit Ethernet.

Denominación	Cable	Pares	Full dúplex	Conectores	Distancia
10BASE5	Coaxial grueso	1	No	‘N’	500 m
10BASE2	RG 58 (Coaxial fino)	1	No	BNC	185 m
10BASE-T	UTP cat. 3	2	Sí	RJ-45	100 m
10BASE-T	UTP cat. 5	2	Sí	RJ-45	150 m⁽¹⁾
100BASE-TX	UTP cat. 5	2	Sí	RJ-45	100 m
100BASE-TX	STP	2	Sí	9 pin D sub.	100 m
100BASE-T4	UTP cat. 3	4	No	RJ-45	100 m
100BASE-T2	UTP cat. 3	2	Sí	RJ-45	100 m
1000BASE-CX	STP	2	Sí	8 pin HSSDC o 9 pin D sub.	25 m
1000BASE-T	UTP cat. 5	4	Sí	RJ-45	100 m

⁽¹⁾La longitud máxima del cable UTP-5 según las normativas de cableado estructurado es 100 m, pero la norma 802.3 permite una longitud de 150 m cuando se utiliza 10BASE-T con cable categoría 5.

Tabla 4.3.- Medios físicos de cobre utilizados en Ethernet, Fast Ethernet y Gigabit Ethernet

Los medios preferidos hoy en día son 10BASE-T y 100BASE-TX , ambos sobre cable categoría 5.

4.4.2.2 Fibras ópticas

En Ethernet a 10 Mb/s sobre fibra óptica (10BASE-FL) se utiliza primera ventana (850nm) por ser la que permite emplear optoelectrónica más barata; con esto se tiene un alcance de 2 Km. En cambio Fast Ethernet (100BASE-FX) utiliza segunda ventana (1300nm) que es la empleada en FDDI [13]; como la mayor velocidad requiere menor atenuación se cambia a la segunda ventana con lo que se consigue mantener el alcance máximo en 2Km; desgraciadamente la optoelectrónica de segunda ventana es bastante más cara, por este motivo la relación de costo fibra/cobre es mayor en Fast Ethernet que en Ethernet. Si se mira directamente a un emisor 10BASE-FL se aprecia una luz roja tenue, ya que la primera ventana se encuentra muy cerca del espectro visible, que va de 400 a 760nm. En cambio en 100BASE-FX no se aprecia ninguna luz ya que la segunda ventana se encuentra bastante mas lejos de la zona visible.

Aunque los estándares 10BASE-FL y 100BASE-FX contemplan únicamente fibra 62,5/125 la mayoría de los equipos pueden funcionar también con fibra 50/125 [14]. Sin embargo el uso de fibra 50/125 provoca una pérdida de señal que puede llegar a ser de 5 ó 6 dB debido al desacoplamiento entre el transceiver y la fibra [15]; por tanto el uso de fibra 50/125 puede reducir la distancia máxima efectiva en el caso de Ethernet o Fast Ethernet, y su uso está desaconsejado. Aun menos aconsejable es mezclar en un mismo trayecto fibras de 50/125 y 62,5/125, ya que se producirían pérdidas de señal en cada cambio de diámetro.

Tradicionalmente las redes locales, al tener que cubrir distancias pequeñas (menores de 2Km), han utilizado fibras multimodo con emisores LED (no láser) de primera o segunda ventana, mientras que los emisores láser y las fibras monomodo con alcance mucho mayor (hasta 160 Km en tercera ventana) han quedado reservados a las redes de área extensa, donde el mayor costo de los emisores se ve compensado por la reducción en equipos amplificadores y regeneradores de la señal.

Además de su menor alcance los LEDs también tienen una limitación en velocidad; pueden llegar como máximo a 400-600 Mbaudios [16]. Para velocidades superiores es preciso utilizar emisores láser, aun cuando por distancia no sea necesario su uso, porque permiten enviar pulsos más cortos. Esta situación se planteó por primera vez en Fibre Channel, que transmite a velocidades de hasta 1062 Mbaudios. El problema era que la luz láser requiere normalmente fibras monomodo, cosa que habría limitado mucho la utilización de Fibre Channel, ya que estas fibras no están disponibles normalmente en los edificios. La propagación de luz láser en fibra multimodo presenta problemas que limitan seriamente su alcance. En Fibre Channel se optó por restringir el uso de fibra multimodo a distancias muy cortas, sin investigar a fondo el problema, ya que para distancias mayores se utilizaba fibra monomodo. Además en Fibre Channel se utiliza fibra de 50/125 únicamente ya que presenta menos problemas de propagación con la luz láser que la 62,5/125 (lo cual es hasta cierto punto lógico puesto que su diámetro es más parecido al de la monomodo).

En Gigabit Ethernet los pulsos se transmiten a una velocidad de 1250 Mbaudios, por lo que es necesario utilizar láser. Para aumentar la versatilidad se decidió incluir los dos tipos de fibra multimodo, 50/125 y 62,5/125, y extender todo lo posible el alcance, tanto en primera como en segunda ventana (Fibre Channel en multimodo utilizaba primera ventana únicamente). Las primeras experiencias de transmisión de Gigabit Ethernet en fibras multimodo pusieron de manifiesto un fenómeno nuevo denominado 'retardo del modo diferencial' que tiene el efecto de ensanchar los pulsos luminosos de forma proporcional a la distancia recorrida; esto limita el alcance, ya que a partir de una cierta distancia un pulso se solapa con el siguiente. La búsqueda de una solución a este problema retrasó unos meses la aprobación del estándar respecto a lo inicialmente previsto. Finalmente se aprobaron dos sistemas denominados 1000BASE-SX (S de 'Short wavelength', o sea primera ventana), que funciona en fibra multimodo únicamente (50/125 ó 62,5/125), y 1000BASE-LX (L de 'Long wavelength', segunda ventana) que puede utilizar multimodo (ambos tipos) o monomodo. El alcance depende como es lógico del tipo de fibra y la ventana utilizados.

Los emisores láser de primera ventana emplean una técnica denominada VCSEL (Vertical Cavity Surface Emitting Laser) muy similar a la de los lectores de discos compactos, por lo que resultan muy baratos de fabricar. Desgraciadamente aún no existen emisores láser VCSEL de segunda ventana, por lo que para 1000BASE-LX hay que emplear otras técnicas bastante más costosas como el láser Fabry-Perot, con lo que las interfaces LX resultan unas tres veces más caras; a cambio la segunda ventana permite generalmente un mayor alcance. Con 1000BASE-LX sobre fibra monomodo se puede llegar según el estándar a 5 Km. Se emplean los mismos emisores LX en fibra multimodo que en monomodo.

Los emisores láser VCSEL de primera ventana son tan baratos de fabricar que pueden resultar competitivos frente a los emisores LED no láser de segunda ventana; utilizados por ejemplo en Fast Ethernet (100BASE-FX). Esto ha provocado recientemente un interés por utilizar emisores de primera ventana, hasta el punto que en 1998 se creó con este objetivo una asociación denominada Short Wave Length Alliance (SWLA) en el seno de la TIA (entidad que estandariza las normativas de cableado estructurado). Las propuestas presentadas al comité 802.3 de crear un grupo de trabajo que elabore un estándar Fast Ethernet en primera ventana no prosperaron, por lo que los interesados, siguiendo una actitud plenamente pragmática, crearon un grupo de trabajo en el seno de la TIA para elaborar este estándar denominado 100BASE-SX. El estándar fue ratificado finalmente en junio del 2000. Los productos comerciales basados en 100BASE-SX tienen un costo aproximadamente la mitad que el de los 100BASE-FX. El alcance es de unos 500m y viene limitado por la atenuación. La principal finalidad del 100BASE-SX es competir con el cobre UTP-5 en el cableado interior (vertical y horizontal) de los edificios; aquí su mayor alcance permite una mayor concentración de los armarios de cableado, tendencia que se da mucho en la actualidad para simplificar la gestión de la red de distribución; además 100BASE-SX brinda las ventajas de seguridad e inmunidad radioeléctrica de la fibra a un precio más competitivo que antes. Sin embargo, y a pesar de la aparición de los emisores VCSEL la fibra seguirá siendo, en todas las velocidades, más cara que el cobre puesto que requiere componentes adicionales.

La tabla 4.4 resume las principales características de todos los medios de fibra óptica actualmente utilizados en Ethernet, y sus alcances.

Medio	Ventana	Luz	Fibra	Conector	Distancia
10BASE-FL	1ª	Normal	62,5/125	ST	2 Km
100BASE-FX	2ª	Normal	62,5/125	SC	2 Km
100BASE-SX (propuesto)	1ª	Láser	62,5/125 50/125	SC o ST	500 m 500 m
1000BASE-SX	1ª	Láser	62,5/125 50/125	SC	275 m 550 m
1000BASE-LX	2ª	Láser	62,5/125 50/125 9/125	SC	550 m 550 m 5 Km

Tabla 4.4.- Medios de transmisión en fibra óptica utilizados en Ethernet

Es importante mencionar que la práctica, utilizada frecuentemente en 10BASE-FL, de ver directamente con el ojo un emisor o una fibra óptica para saber cual es el lado transmisor se convierte en algo peligroso con Gigabit Ethernet ya que existe el riesgo de que la retina reciba luz láser, que puede producir un daño irreversible. Además, a diferencia de lo que ocurría en 10BASE-FL, incluso funcionando en primera ventana la luz láser resulta invisible para la mayoría de las personas ya que tiene toda su potencia concentrada en una banda de solo 0,5nm de anchura en una longitud de onda que puede estar entre los 770 y 860 nm.

4.4.2.3 Gigabit Ethernet y el retardo en modo diferencial

A diferencia de lo que sucede con 10BASE-FL o 100BASE-FX, donde el alcance viene limitado por la atenuación de la señal, en Gigabit Ethernet sobre fibra multimodo el alcance está limitado fundamentalmente por el efecto antes mencionado del retardo en modo diferencial. Descrito de forma muy sencilla este fenómeno consiste en que cuando el haz láser llega a la fibra, al ser ésta apreciablemente más ancha que el haz éste genera haces de luz secundarios que van ‘rebotando’ por las paredes al avanzar por la fibra. Este rebote no ocurre exactamente por igual para todos los rayos, por lo que unos realizan un trayecto un poco mas largo que otros, con lo que el pulso de luz se ensancha ligeramente. El ensanchamiento es mayor cuanto mayor es la distancia recorrida; además a mayor velocidad de transmisión menos ensanchamiento puede tolerarse, ya que un pulso se solaparía con el siguiente; el efecto del retardo en modo diferencial es por tanto proporcional a la distancia y a la frecuencia de los pulsos, es decir a la velocidad de transmisión. Existe un parámetro característico de las fibras que mide esta limitación, que se conoce como ancho de banda modal o simplemente ancho de banda, y se mide en MHz*Km. Por ejemplo con un ancho de banda de 1000 MHz*Km podremos enviar como máximo 1 millón de pulsos por segundo a una distancia de 1 Km, o medio millón de pulsos a 2 Km, o dos millones a 500 m.

Los factores principales que influyen en el ancho de banda de una fibra son los siguientes:

o El diámetro del núcleo: el ancho de banda es menor cuanto mayor es el diámetro del núcleo, ya que el pulso va más ‘ancho’ y rebota más. Por tanto en general la fibra de 62,5/125 tiene menor ancho de banda que la de 50/125, y el retardo en modo diferencial no se da, o es despreciable, en fibras monomodo (de hecho el parámetro ancho de banda modal no se especifica en las fibras monomodo).

o La longitud de onda: el ancho de banda es mayor cuanto mayor es la longitud de onda, ya que el haz viaja más ‘ajustado’ en la fibra. Por tanto una misma fibra suele tener mayor ancho de banda en segunda ventana que en primera.

o La calidad de la fibra. Los procesos de fabricación permiten reducir hasta cierto punto la creación de haces secundarios, con lo que el ensanchamiento se reduce. Por tanto las fibras construidas con mayores controles de calidad tienen un ancho de banda mayor.

Los catálogos de los fabricantes suelen especificar para cada tipo de fibra el ancho de banda para cada ventana. Hoy en día los anchos de banda exigidos por los estándares EIA e ISO son ampliamente superados por las fibras de alta calidad, por lo que en la elección de una fibra que se prevea utilizar en Gigabit Ethernet es conveniente elegir la de mayor ancho de banda posible, no conformándose con que cumpla los estándares habituales. El encarecimiento que esto supone en el costo total de la instalación es normalmente despreciable. Con un ancho de banda mayor tendremos mayores alcances y podremos usar emisores 1000BASE-SX en mas situaciones, no teniendo que recurrir a los de segunda ventana 1000BASE-LX más caros. A título de ejemplo mostramos en la tabla 4.5 los anchos de banda de fibra multimodo según los estándares EIA/TIA e ISO/IEC, así como los valores garantizados de algunas de las mejores fibras del mercado.

Fibra o estándar	Diámetro (mm)	Ancho de banda *850 nm (MHzkm)**	Ancho de banda *1300 nm (MHzkm)**
EIA/TIA 568	62,5/125	160 (220m)	500(550 m)
ISO/IEC 11801	62,5/125	200(275 m)	500(550 m)
Alcatel GIGAlite	62,5/125	500	500
BRUGG FG6F	62,5/125	300	1200

ISO/IEC 11801	50/125	200 (275 m)	500 (550 m)
ISO/IEC 11801 (propuesto)	50/125	500 (550 m)	500 (550 m)
ANSI Fibre Channel	50/125	500 (550 m)	500 (550 m)
Alcatel GIGAlite	50/125	700	1200
BRUGG FG5F	50/125	600	1200

Tabla 4.5.- Ancho de banda en 1ª y 2ª ventanas de los estándares y algunas fibras típicas de alta calidad (entre paréntesis aparece el alcance máximo en Gigabit Ethernet para cada caso)

Aunque hay una correlación entre el ancho de banda y la distancia máxima la proporción no es lineal, por lo que no es fácil extrapolar. Además a distancias mayores habrá que cuidar de no superar el valor máximo de atenuación, que ha sido fijado con criterios muy severos [7]. En todo caso la prueba definitiva es realizar la conexión y hacer un seguimiento de la tasa de error o BER siguiendo la misma técnica que hemos descrito para el caso de cable de cobre [17]. En caso de problemas habría que revisar la instalación y eventualmente pasar a un medio de mayor alcance (de SX a LX o de multimodo a monomodo).

En general en el diseño de cualquier instalación en la que se prevea la posibilidad de utilizar Gigabit Ethernet a distancias de mas de 200 m se deberían analizar en detalle las características de la fibra a emplear y las distancias a cubrir, y considerar la posibilidad de emplear fibra de 50/125, que tiene un mayor ancho de banda y por tanto mayor alcance (ver por ejemplo tabla 4.5), Desgraciadamente la fibra 50/125 tiene como ya hemos comentado un menor alcance en 10BASE-FL y 100BASE-FX, por lo que su instalación puede comprometer en algún caso el funcionamiento en entornos donde haya también Ethernet o Fast Ethernet. En cableado entre edificios se debería considerar, además de fibra multimodo, el tendido de fibra monomodo, ya que nos permitirá distancias de hasta 5 Km en segunda ventana [18].

4.4.2.4 Códigos

En Ethernet, como en todas las redes locales, la transmisión se realiza de manera asíncrona, es decir no hay un reloj maestro que mantenga sincronizados los equipos. Por este motivo se utiliza un sincronismo embebido en los propios datos mediante el uso de códigos que incorporan cierto nivel de redundancia. Por ejemplo a 10 Mb/s Ethernet emplea el código Manchester, que utiliza dos voltajes (+0,85 y -0,85 voltios en 10BASE5) e identifica el bit 0 como una transición alto-bajo y el 1 como una transición bajo-alto [19]. Según cual sea la secuencia de bits a transmitir habrá o no otra transición además entre los bits, que carece de importancia a la hora de interpretar la información transmitida pero que permite mantener sincronizados los equipos. El código Manchester tiene el inconveniente de que duplica la frecuencia de funcionamiento, el emisor debe poder generar doble número de pulsos de lo que haría falta con un código binario simple, como el NRZ (Non Return to Zero). Dicho de otro modo, en Manchester se transmiten 20 Mbaudios (o Msímbolos/s) para enviar 10 Mb/s de información útil. Como consecuencia de esto la señal transmitida por el cable es también de una frecuencia doble de lo que sería necesario con un código binario simple. La frecuencia fundamental de la señal en Ethernet oscila entre 5 MHz (para la secuencia 010101...) y 10 MHz (para las secuencias 1111... o 0000...)[20].

El código Manchester es poco eficiente, pero resulta sencillo y barato de implementar. Su mayor inconveniente estriba en la elevada frecuencia de la señal, que requiere un cable de altas prestaciones, pero esto no preocupaba a los diseñadores originales de Ethernet que utilizaban cable coaxial. El uso de código Manchester complicó bastante las cosas cuando se adaptó Ethernet para cable no apantallado; entonces habría sido preferible otro código más eficiente que utilizara una frecuencia menor, pero la arquitectura de Ethernet a 10 Mb/s obliga a utilizar código Manchester en todos los medios físicos en que se implemente [21].

En Fast Ethernet el uso de código Manchester habría requerido transmitir 200 Mbaudios, lo cual habría hecho muy difícil llegar con cable categoría 5 a la distancia de 100m que fijan las normativas de cableado. Por esto se eligieron otros códigos más ricos, es decir con menos overhead [22], que permitían reducir la frecuencia de la señal, y consecuentemente el requerimiento en cuanto al cable utilizado. Los medios 100BASE-FX y 100BASE-TX, conocidos conjuntamente como 100BASE-X, utilizan el código 4B/5B desarrollado originalmente para FDDI que emplea 5 símbolos para enviar 4 bits. De las 2⁵ = 32 combinaciones posibles solo se utilizan 16, lo cual permite evitar las combinaciones con todo ceros o todo unos, que serían nefastas desde el punto de vista del sincronismo [23], y da una cierta capacidad de detección de errores. Con 4B/5B la señalización para 100 Mb/s es de 125 Mbaudios, con lo que la frecuencia fundamental es de 62,5 MHz. Esto permite utilizar cable categoría 5 (especificado hasta 100 MHz).

Según el teorema de Nyquist el ancho de banda mínimo necesario para transmitir n baudios es n/2 Hertzios, por lo que a dicha frecuencia se le denomina frecuencia de Nyquist. En las señales digitales esa es la frecuencia fundamental máxima de la señal. Por ejemplo, con un código binario simple (1 bit = 1 baudio) podríamos enviar 10 Mb/s en 10 Mbaudios, utilizando por tanto una frecuencia fundamental máxima de 5 MHz. Al utilizar codificación Manchester se duplican los baudios y por tanto la frecuencia. Ahora bien, para recibir con fiabilidad suficiente la onda cuadrada de una señal digital hay que transmitir no solo la frecuencia fundamental sino también componentes de frecuencia superior. Cuanto mayor sea la capacidad del medio físico de transmitir señales de alta frecuencia más componentes se transmitirán, más fidelidad tendrá la señal recibida y se producirán menos errores. Generalmente transmitiendo hasta el doble de la frecuencia de Nyquist se consiguen valores de BER inferiores a 10^-10, que es lo requerido habitualmente en los estándares para las transmisiones sobre cable UTP. La mayoría de los transceivers se diseñan partiendo de esta hipótesis, y se filtran en emisión las señales de frecuencia superior. Por tanto el medio físico debería ser capaz de transmitir señales hasta una frecuencia igual al número de baudios, aproximadamente. Así por ejemplo en el medio 100BASE-TX, con una frecuencia fundamental de 62,5 MHz, las señales que viajan por el cable llegan a valores de hasta 125 MHz, y es importante que lleguen correctamente para garantizar una BER aceptable. Este valor es ligeramente superior al máximo previsto en la categoría 5 (100 MHz), pero esto normalmente no supone un problema ya que las prestaciones a 125 MHz suelen ser muy similares a las de 100 MHz. Pero en el caso por ejemplo de ATM a 155,52 Mb/s (que utiliza código NRZ) sobre cable UTP la frecuencia máxima a transmitir es de 155,52 MHz, que ya supera de forma sensible el límite de la categoría 5; está demostrado [8, 9, 10] que un cable puede cumplir perfectamente las exigencias de la normativa categoría 5 hasta 100 MHz y no ser capaz de satisfacer la BER de 10^-10 exigida por los estándares ATM correspondientes [11] si sus prestaciones decaen de forma drástica en el intervalo 100-155 MHz [24]. Afortunadamente estas situaciones, además de poco frecuentes, solo suponen un problema cuando el enlace se encuentra en el límite de las especificaciones (100m de longitud por ejemplo) lo cual ocurre raramente. En cualquier caso es preciso recordar la conveniencia de realizar un estudio y seguimiento de los valores de BER de la red.

Cuando se estandarizó Fast Ethernet además del cable categoría 5 se quería utilizar el categoría 3, del cual había una base instalada importante. Para ello se diseñó el medio físico 100BASE-T4, que a diferencia de los demás no derivaba de FDDI. Para reducir la frecuencia máxima a valores aceptables se adoptaron dos medidas novedosas:

Emplear códigos que utilizan más de dos voltajes y permiten una mayor eficiencia; concretamente se utiliza el 8B/6T que prevé tres voltajes posibles y tiene una eficiencia de 1,33 bits/baudio. La denominación 8B/6T significa 8 bits / 6 trits.

Repartir la señal en tres pares: el 1, 3 y 4 para un sentido y el 2, 3 y 4 para el contrario [25].

En 100BASE-T4 se transmiten 25 Mbaudios por cada par. Debido a la eficiencia del código utilizado (1,33) esto equivale a 33,3 Mb/s, que al transmitirse simultáneamente por tres pares da los 100 Mb/s. La frecuncia máxima transmitida es por tanto de 25 MHz. Por su forma de funcionamiento 100BASE-T4 no permite la transmisión full dúplex.

Una evolución de 100BASE-T4 es el medio denominado 100BASE-T2, que utiliza únicamente dos pares de cable categoría 3. Los dos pares restantes se pueden aprovechar para servicios de baja velocidad, tales como telefonía [26]. Además 100BASE-T2 permite una comunicación full dúplex, cosa que no era posible con 100BASE-T4. Para conseguir esto utilizando la misma frecuencia máxima que en 100BASE-T4 (25 MHz) se aplican dos técnicas novedosas:

Se emplea una codificación quinaria (5 voltajes) denominada PAM 5x5. Los símbolos se agrupan de dos en dos; cada grupo tiene por tanto 5²=25 posibles valores que se utilizan para representar 4 bits (16 estados). Esto permite elegir los 16 valores mas adecuados y descartar los 9 menos interesantes desde el punto de vista de sincronismo (por ejemplo los que no provocan transiciones), con lo que se tiene además cierta capacidad de detección de errores. La codificación PAM 5x5 tiene una eficiencia de 2 (cada baudio representa dos bits).

Se emplea transmisión dual-duplex, consistente en transmitir y recibir datos simultáneamente en ambos sentidos por cada par; esto se consigue mediante circuitos híbridos que filtran la señal de ida y vuelta en cada transceiver. Al repartir la señal en dos pares cada uno transporta 50 Mb/s, que con PAM 5x5 supone 25 Mbaudios, equivalentes a 25 MHz de frecuencia máxima.

En Gigabit Ethernet los medios 1000BASE-SX, 1000BASE-LX y 1000BASE-CX (conocidos genéricamente como 1000BASE-X) emplean código 8B/10B (8 bits/10 baudios) que ya se utilizaba en Fibre Channel (de donde deriva toda la capa física de 1000BASE-X). Este código tiene una eficiencia de 0,8, igual que 4B/5B, pero al agrupar mas símbolos tiene una mayor redundancia, ya que solo una de cada cuatro combinaciones posibles es válida (2⁸/2¹⁰ = 256/1024 = 1/4), mientras que en 4B/5B es válida una de cada dos (2⁴/2⁵= 16/32 = 1/2). A cambio en caso de error se pierde el doble de información, ya que se manejan bloques de 8 bits en vez de 4. La señalización se realiza a 1250 Mbaudios.

La transmisión de Gigabit Ethernet por cable UTP categoría 5 (1000BASE-T) se realiza de forma muy similar a 100BASE-T2: se utiliza codificación PAM 5x5 con una frecuencia de señalización de 125 Mbaudios, lo cual da 250 Mb/s; a continuación se envía este caudal en paralelo por los cuatro pares, llegando así a 1 Gb/s; para funcionar en modo full dúplex se emplea transmisión dual duplex. Dado que la frecuencia máxima es la misma que la de 100BASE-TX se puede aprovechar circuitería ya desarrollada para la sincronización de la señal y para la supresión de interferencia electromagnética. Se ha preferido no aumentar la frecuencia por encima de los 125 MHz para evitar problemas como los de ATM a 155 Mb/s que ya hemos comentado.

El reparto de la información transmitida en varios pares plantea nuevos requerimientos en lo que a las características del cable se refiere. El ejemplo mas claro en este sentido es la diferencia de retardo entre los diversos pares, producida por su diferente longitud; esto no es un problema cuando la información viaja en un solo par, pero cuando se reparte en varios existe una tolerancia máxima en la denominada ‘delay skew’ (asimetría en el retardo) por encima de la cual la información no podrá reconstruirse adecuadamente en el destino; este es uno de los parámetros que se han añadido en la especificación 5 Enhanced, a fin de ampliar el margen de seguridad para el funcionamiento de 1000BASE-T. También es preciso medir y limitar la interferencia electromagnética mutua inducida entre pares que transmiten simultáneamente. Aunque 100BASE-T4 y 100BASE-T2 también reparten la información en varios pares, no existe una especificación 3 Enhanced que contemple estos casos, ya que al funcionar a velocidades 10 veces inferiores los márgenes de tolerancia son más amplios.

A título de ejemplo la tabla 4.6 muestra los códigos utilizados en algunas de las tecnologías de red local más habituales.

Tipo de red	Velocidad (Mb/s)	Esquema de codificación	Número de pares	Frecuencia Señalizac. (Mbaud.)	Categoría mínima de cable UTP
1BASE-5	1	Manchester	1	2	2
Token Ring	4	Manchester Diferencial	1	8	3
10BASE-T	10	Manchester	1	20	3
100BASE-T4	100	8B/6T	3	25	3
100BASE-T2	100	PAM 5x5	2	25	3
100VG-AnyLAN	100	5B/6B	4	30	3
Token Ring	16	Manchester Diferencial	1	32	3
ATM	25,6	4B/5B	1	32	3
FDDI, 100BASE-X	100	4B/5B	1	125	5
1000BASE-T	1000	PAM 5x5	4	125	5
ATM	155,52	NRZ	1	155,52	5
1000BASE-X	1000	8B/10B	1	1250	-

Tabla 4.6.- Códigos y frecuencias máximas utilizadas en las redes locales mas habituales

4.4.2.5 Fiabilidad

El estándar 802.3 establecía inicialmente una BER máxima de 10^-8. Las nuevas especificaciones de medios físicos han ido fijado requerimientos superiores, por ejemplo FDDI (en la que se basa el 100BASE-X) fija una BER no superior a 4 x 10^-11, y Fibre Channel (en que se basa 1000BASE-X) una BER no superior a 10^-12; los medios en cable UTP exigen una BER máxima de 10^-10. Una buena instalación de red Ethernet actual en un entorno de oficina puede dar sin problemas una BER inferior a 10^-12. Transmitiendo a 10 Mb/s ininterrumpidamente esto representa menos de un error por día, por lo que los errores de CRC en una red Ethernet funcionando correctamente (y en cualquier red local excepto las inalámbricas) deberían ser virtualmente inexistentes, salvo los originados por la conexión y desconexión de equipos.

Debido a la elevada fiabilidad del medio físico el protocolo MAC de Ethernet no realiza ningún tipo de verificación, ya que la probabilidad de que una trama no llegue a su destino es tan baja que esto sería perjudicial para el rendimiento de la red. Pero precisamente por eso en el caso de que se produzcan errores el rendimiento decae de forma espectacular. Es importante por tanto hacer un seguimiento regular de los errores de CRC en la red para detectar y corregir lo antes posible cualquier anomalía que pueda producirse.

4.4.3 Funcionamieneto de Ethernet

4.4.3.1 Topología

El correcto funcionamiento de CSMA/CD requiere que el tiempo de ida y vuelta entre dos estaciones cualesquiera no supere el tiempo de transmisión mínimo, es decir lo que tarda en emitirse la trama mínima permitida. El tiempo de transmisión mínimo depende de la velocidad de la red, y el tiempo máximo de ida y vuelta fija a su vez unas distancias máximas entre las estaciones. Estos cuatro parámetros (velocidad de la red, tamaño de trama mínimo, tiempo de ida y vuelta y distancia máxima) están relacionados entre sí, como se muestra en la tabla 4.7.

Velocidad (Mb/s)	Tamaño de trama mínimo (bits)	Tiempo de ida Y vuelta (ms)	Distancia Máxima (m)	Número de Repetidores
10	512	51,2	4000	1
100	512	5,12	412	0
1000	4096	4,096	330	0

Tabla 4.7.- Relación entre la velocidad, trama mínima, tiempo de ida y vuelta y distancia máxima en una red Ethernet.

Las distancias indicadas en la tabla 4.7 son el valor máximo, y sólo pueden conseguirse muy raramente. En la práctica la necesidad de utilizar repetidores reduce la distancia máxima de forma considerable. En principio una determinada topología de red es válida si el tiempo de ida y vuelta entre cada par de estaciones de la red es inferior al que aparece en la tabla 4.7.

El estándar IEEE 802.3 establece dos formas de verificar si una determinada topología Ethernet es válida. La primera, denominada Modelo 1, corresponde a un conjunto de reglas 'enlatadas' sobre el número máximo de repetidores que puede haber entre dos estaciones, y la distancia máxima entre ellos. Cumpliendo esas reglas el usuario se asegura de que su red no excede los valores máximos en el tiempo de ida y vuelta. Sin embargo el Modelo 1 realiza una serie de suposiciones simplificadoras, por lo que no siempre una topología que incumpla sus reglas supera el tiempo máximo de ida y vuelta. Para esos casos el estándar establece el denominado Modelo 2, que consiste en realizar cálculos detallados del retardo para cada componente y tramo de cable en cada trayecto. Una topología aceptable según el Modelo 2 es válida, aun cuando viole alguna de las reglas del Modelo 1.

Veamos un ejemplo. Supongamos que queremos montar una red Fast Ethernet 100BASE-TX conectando entre sí dos concentradores de clase II [27]. Las reglas del Modelo 1 establecen en este caso que entre los concentradores no puede haber más de 5m de cable. Esto da una distancia máxima entre equipos finales de 205m, 5 entre los concentradores y 100 de cada concentrador al ordenador (ya que el Modelo 1 supone que el cable del usuario final puede tener hasta 100m de longitud).

Supongamos que queremos instalar los concentradores separados entre sí por una distancia de 100m. En principio esto viola la regla del Modelo I para esta topología, ya que supondría una distancia de 300m entre ordenadores, lo cual excede el máximo permitido. Pero imaginemos que podemos asegurar que los equipos finales nunca utilizarán más de 50m de cable, con lo que en principio la distancia máxima no superaría los 200m. Vamos a aplicar las reglas del Modelo 2 para ver si realmente esta topología es conforme al estándar. Para ello calcularemos el tiempo de ida y vuelta del trayecto utilizando los valores especificados por el estándar para cada componente. El trayecto en que estamos interesados es el siguiente:

50m 100m 50m

ordenador ---------------- concentrador ---------------- concentrador ------------------ ordenador

clase II clase II

Los valores del tiempo de ida y vuelta se detallan en la tabla 4.8.

Componente	Tiempo de ida y vuelta (en ms)	Tiempo de ida y vuelta (en bits)
2 Tarjetas de red 100BASE-TX	1,00	100
2 Repetidores clase II	1,84	184
200 metros de cable UTP-5	2,22	222
TOTAL	5,06 ms	506 bits

Tabla 4.8.- Cálculo del tiempo de ida y vuelta para una topología de red 100BASE-TX siguiendo el Modelo 2

Como el resultado obtenido es inferior a 5,12 ms concluimos que la topología es válida y debe funcionar.

Ahora supongamos que sustituimos los cables de 50m por cables de 100m, con lo que la topología queda de la siguiente manera:

100m 100m 100m

ordenador ---------------- concentrador ---------------- concentrador ------------------ ordenador

clase II clase II

Si repetimos el cálculo del tiempo de ida y vuelta para este caso obtenemos el resultado que aparece en la tabla 4.9.

Componente	Tiempo de ida y vuelta (en ms)	Tiempo de ida y vuelta (en bits)
2 Tarjetas de red 100BASE-TX	1,00	100
2 Repetidores clase II	1,84	184
300 metros de cable UTP-5	3,34	334
TOTAL	6,18 ms	618 bits

Tabla 4.9.- Cálculo de una topología de red 100BASE-TX inválida siguiendo el Modelo 2

Al superar el valor máximo permitido la topología es inválida, como era de esperar.

Este cálculo se debería hacer para el par de estaciones más distante de la red. Generalmente será necesario hacerlo para varias parejas, ya que en una red compleja no suele ser evidente cual es la que está más distante.

Similares cálculos se pueden hacer también para otras topologías para redes de 10, 100 o 1000 Mb/s. Para información detallada sobre validación de topologías en redes Ethernet, siguiendo el Modelo 1 o el Modelo 2, se pueden consultar las referencias [3], [13], [14] y [15] así como la documentación de los fabricantes.

En el ejemplo anterior hemos supuesto los valores estándar de retardo. Los valores reales serán siempre inferiores. Si se dispone del retardo real suministrado por el fabricante para cada componente es posible hacer el cálculo con mas precisión. Por ejemplo el cable categoría 5 debe tener según el estándar un retardo máximo de 1,112 bits/m (equivalente a una velocidad de la onda electromagnética de 180.000 Km/s), pero hoy en día prácticamente todo el cable categoría 5 que se fabrica tiene un retardo de 1,0 bits/m (200.000 Km/s). Tomando esto en cuenta el cálculo de la tabla 4.9 habría dado un resultado final de 4,84 ms. En algún caso puede suceder que una topología supere el límite de retardo con valores estándar, pero esté por debajo al utilizar los valores de los componentes utilizados. Aunque dicha topología es válida y debe funcionar correctamente, en general no es recomendable ajustar tanto ya que esto puede suponer que una determinada topología válida deje de serlo si más adelante se sustituye un componente por otro con un retardo mayor. Si a pesar de todo se hace deberá documentarse el hecho de forma muy detallada para evitar problemas futuros.

Una ventaja del Modelo 2 es que nos permite conocer el retardo en la comunicación de ordenadores de nuestra red; como veremos más adelante este dato tiene su interés a la hora de optimizar el rendimiento de la red, y para interpretar de forma correcta datos tales como la tasa de colisiones.

Es fundamental para el correcto funcionamiento de una red asegurarse de que no se supera en ningún caso el retardo máximo permitido. En caso de duda siempre deberemos comprobar recurriendo al cálculo detallado en base al Modelo 2. El principal síntoma de una topología inválida es la pérdida injustificada de tramas y las colisiones tardías, de las que hablaremos mas adelante; en casos extremos puede llegar a ser imposible el intercambio de paquetes pequeños entre determinados pares de estaciones de la red.

Por suerte en las redes que se diseñan actualmente es raro encontrarse con problemas de topología, ya que hoy en día los equipos normalmente se conectan directamente a conmutadores, o si se conectan a concentradores éstos solo aparecen en el primer nivel, estando el segundo nivel y superiores ocupados por un conmutador. Además al conectar directamente equipo a conmutador la transmisión puede realizarse en modo full duplex, con lo que desaparecen las colisiones y por tanto la limitación de distancias impuesta por la necesidad de detectarlas.

4.4.3.2 Direcciones IEEE

Los inventores de Ethernet decidieron asignar direcciones globalmente únicas a cada dispositivo Ethernet direccionable (es decir a cada estación) en todo el mundo. Para ello utilizaban una dirección de seis bytes, de los cuales los tres primeros correspondían al fabricante y los tres últimos al dispositivo. Xerox se ocupaba de administrar la asignación de los tres primeros a los diversos fabricantes.

Este formato de direcciones y este sistema de reparto debió parecer adecuado a los responsables del proyecto 802, ya que decidieron extenderlo a todas las redes locales estandarizadas por ellos. Al adoptarse para otras redes locales Xerox traspasó al IEEE la labor administrativa de registro de los prefijos que hasta entonces había desempeñado. Actualmente el IEEE cobra una cuota de 1250 dólares por cada prefijo asignado a un fabricante. Aunque en principio la asignación de prefijos no es información pública existen diversas recopilaciones mas o menos completas de los prefijos asignados. Algunos analizadores de red utilizan dicha información para facilitar el fabricante de las tarjetas activas en una red.

El estándar permite direcciones de 2 ó 6 bytes, aunque en la práctica sólo se utilizan las de 6 bytes. Ademas de utilizarse en otras redes 802 las direcciones MAC IEEE se emplean en redes locales no IEEE, como FDDI y Fibre Channel. También se esta extendiendo su uso como sufijo en direcciones de red para construir direcciones únicas de forma automática, por ejemplo en ATM e IPv6; en estos casos la longitud del campo dirección de estos protocolos (20 ó 16 bytes respectivamente) permite emplear sin problemas 6 para la dirección MAC.

Los dos primeros bits de los 48 que componen una dirección MAC IEEE tienen un significado especial:

El primer bit indica el ámbito del envío. Se contemplan tres posibilidades: envío unicast (a un ordenador), envío multicast (a un grupo de ordenadores) o envío broadcast (a todos los ordenadores). Si el primer bit está a 0 se trata de un envío unicast, mientras que si está a 1 es un envío multicast o broadcast. En caso de que toda la dirección esté a 1 será un envío broadcast, que deberá ser atendido por todos los ordenadores de la red. Si se trata de una trama multicast tendrá a 1 el primer bit, viniendo especificado por el resto de la dirección el grupo multicast al que va dirigida. En una trama unicast el primer bit será 0, en cuyo caso la trama solo deberá ser interpretada por el ordenador al que va dirigida; las direcciones multicast y broadcast sólo tienen sentido en el campo dirección de destino; en una dirección de origen el primer bit siempre debe estar a cero.

El segundo bit se utiliza para indicar si se trata de una dirección global (la grabada por el fabricante en el hardware de la tarjeta) o si se trata de una dirección local, asignada por software a ese equipo. Las direcciones locales solo pueden ser utilizadas dentro de la red, ya que en otras redes podrían estar duplicadas. En cambio las globales, dado que son únicas en todo el mundo, podrían utilizarse en principio para enviar tramas a cualquier tarjeta de red existente (otra cosa es que la trama pueda llegar a su destino). Las direcciones locales se emplean en algunos protocolos de red poco utilizados actualmente.

4.4.3.3 La trama Ethernet

La estructura de trama Ethernet es la que se muestra en la tabla 4.10:

Campo	Tamaño (Bytes)
Hueco entre tramas	(12)
Preámbulo	7
Delimitador inicio de trama	1
Dirección de destino	6
Dirección de origen	6
Protocolo/Longitud	2
Datos	0-1500
Relleno	0-46
Secuencia de comprobación (CRC)	4

Tabla 4.10.- Estructura de la trama Ethernet

El hueco entre tramas es un período de tiempo en que no se transmite nada, de duración equivalente a 12 bytes (por ejemplo 9,6 ms a 10 Mb/s) que sirve para separar las tramas. Este hueco entre tramas es el único mecanismo fiable para detectar cuando termina una trama, ya que el campo longitud puede no existir y aunque exista no se utilizará en tiempo de captura para averiguar cuando termina la trama. El hueco también sirve para dar un respiro al receptor, que puede necesitar un pequeño respiro al final de una trama para realizar diversas tareas de mantenimiento (transvase de buffers de la interfaz de red al host, interrupciones a la CPU, etc.) antes de volver a la escucha. Para asegurar que se respete el hueco el estándar establece que siempre que una estación vaya a enviar una trama deberá esperar el tiempo equivalente a 12 bytes antes de empezar a transmitir el preámbulo [28].

El preámbulo está formado por la secuencia 10101010 repetida siete veces, y el delimitador de inicio por la secuencia 10101011. Esta secuencia al ser transmitida con codificación Manchester genera una onda cuadrada de 10 MHz durante 6,3 ms, lo cual permite a los demás ordenadores sincronizar sus relojes con el emisor. Los dos últimos bits del delimitador de inicio de trama marcan el final del preámbulo y el comienzo de ésta.

Los campos dirección contienen las direcciones de origen y destino utilizando el formato de direcciones IEEE de 6 bytes que hemos descrito.

El campo datos puede tener una longitud variable entre 0 y 1500 bytes.

La secuencia de comprobación es un CRC de 32 bits basado en un generador polinómico de grado 32.

El estándar 802.3 establece que la trama (entendiendo por trama la parte que va desde dirección de destino hasta el checksum, ambos inclusive) debe tener una longitud mínima de 64 bytes; en caso de que el campo datos sea menor de 46 bytes se utiliza el campo relleno para asegurar que este requisito se cumpla. A efectos de la longitud de la trama el preámbulo y el delimitador de inicio no se consideran parte de esta. La longitud máxima de una trama 802.3 es por tanto 1518 bytes.

La longitud mínima de una trama Ethernet fija el diámetro de la red [29], ya que para el correcto funcionamiento del protocolo CSMA/CD es preciso que el tiempo de ida y vuelta no sea nunca superior a lo que tarda en emitirse una trama del tamaño mínimo. De haber mantenido la trama mínima de 64 bytes en Gigabit Ethernet el diámetro máximo habría sido de unos 45 m, inaceptable en la mayoría de situaciones. Para evitar esto la trama Gigabit Ethernet incorpora un segundo relleno denominado ‘extensión de portadora’ que se añade al final de la trama para garantizar que la longitud mínima nunca sea inferior a 512 bytes (4096 bits). De esta forma el tiempo de ida y vuelta máximo es de 4,096 ms y el diámetro puede ser de 330 m. Este segundo relleno no es formalmente parte de la trama Ethernet, por lo que solo existirá mientras la trama viaje por Gigabit Ethernet. De esta forma se respeta la compatibilidad con los tipos anteriores de Ethernet. En el caso de que una trama con extensión de portadora sea transmitida a una red de 100 o 10 Mb/s la extensión de portadora se eliminará, e inversamente, si una trama menor de 512 bytes llega a una red Gigabit Ethernet desde Fast Ethernet o Ethernet el conmutador correspondiente añadirá la extensión de portadora necesaria para que la longitud sea de 512 bytes.

El uso de extensión de portadora supone una pérdida de eficiencia en el caso de tramas pequeñas, y un mayor riesgo de colisiones como veremos luego. Para reducir en lo posible estos problemas se prevé la posibilidad de que una estación que quiera enviar varias tramas pequeñas seguidas lo haga como una ráfaga sin necesidad de 'envolver' cada una en una extensión de portadora independiente (sin embargo si aún así la ráfaga es menor de 512 bytes seguirá generándose una extensión de portadora).

La longitud máxima de una trama Ethernet es de 1518 bytes (1500 bytes de datos mas cabeceras) Un tamaño mayor permitiría mejorar la eficiencia, ya que se transmitirían menos tramas y se enviarían menos cabeceras; también se reducirían los recursos de procesador empleados en procesar las tramas (en la mayoría de las implementaciones actuales el procesado de cada trama provoca una interrupción en la CPU). Por contra un tamaño mayor supondría que una estación pudiera monopolizar la red por mas tiempo (1518 bytes suponen 1,214 ms a 10 Mb/s). El tamaño máximo de trama condiciona también la cantidad de memoria para buffers que debe tener la interfaz de red; cuando se diseñaba Ethernet (1979-1980) 1500 bytes de datos se consideró un compromiso razonable entre costo y eficiencia a la vista de los precios de memoria entonces vigentes. Actualmente, con costos mucho menores y redes mas rápidas estos mismos argumentos aconsejarían el uso de tramas mayores, por lo que de vez en cuando surge la propuesta de ampliar el tamaño máximo de trama de Ethernet implementando lo que se conoce como 'jumbo-frames'. Pero no parece factible que esta idea prospere en un futuro próximo, ya que requiere importantes modificaciones al estándar. Por otro lado parece que buena parte de la mejora en eficiencia que podría obtenerse con tramas mayores (la relativa al tiempo de proceso y las interrupciones a la CPU) puede conseguirse con pequeñas mejoras en los controladores de red (poniendo algunas puertas lógicas mas, es decir un poco mas de silicio, en la tarjeta), con lo que los beneficios de utilizar tramas mayores serían menores de lo que a primera vista podría pensarse.

4.4.3.4 Colisiones

Respecto a lo que supondría un protocolo basado en el puro azar, como es el caso de ALOHA, el CSMA/CD incorpora dos mejoras que aumentan el rendimiento: en primer lugar, no se transmite si hay otra estación hablando (CSMA, Carrier Sense Multiple Access) y en segundo, si mientras se está transmitiendo detecta que otra estación también transmite (es decir se produce una colisión) la estación se calla, en lugar de seguir transmitiendo inútilmente hasta el final de la trama (CD, Colision Detect). Mucho se ha dicho (y no siempre acertadamente) sobre las colisiones y su efecto en el rendimiento de Ethernet, por lo que este tema merece tratarse con cierto detalle.

Se produce una colisión cuando dos o más estaciones empiezan a transmitir simultáneamente, o con una separación en el tiempo menor que el tiempo de propagación que las separa [30]. Por ejemplo en la red que aparece en la tabla 4.8 (2t=5,06 µs) se producirá una colisión siempre que los dos ordenadores transmitan con una separación en el tiempo menor de 2,53 µs. Si la separación es mayor que 2,53 µs no se producirá colisión ya que el segundo detectará el medio ocupado cuando vaya a transmitir; en ese caso esperará a que el primero termine y transmitirá inmediatamente a continuación, respetando eso sí el tiempo del hueco entre tramas, que para una red de 100 Mb/s como la de este ejemplo es de 0,96 µs. Aunque transcurridos t µs ya no puede ocurrir colisión, desde el punto de vista de la estación emisora la garantía de no colisión sólo se tiene pasados 2t µs, ya que si otra estación empieza a transmitir justamente t-e µs después (siendo e arbitrariamente pequeño), entonces la colisión se producirá justo en el otro extremo de la red y tendrán que transcurrir otros t µs para que la primera estación detecte la colisión.

Siguiendo con nuestro ejemplo de la tabla 4.8 supongamos que los dos ordenadores intentan transmitir con una separación en el tiempo menor que 2,53 µs. Al detectar la colisión ambos dejan de transmitir y a partir de ese momento dividen el tiempo en intervalos de 5,12µs [31]. Entonces esperan 0 ó 1 intervalos para reintentar (la elección entre 0 y 1 la hace cada uno independientemente de forma aleatoria, por lo que la probabilidad de colisión es ahora de 0,5); si se produce la segunda colisión cada ordenador espera aleatoriamente 0, 1, 2 ó 3 intervalos para reintentar, con lo que la probabilidad de colisión baja a 0,25. Si siguen colisionando el número de intervalos se duplica en cada intento sucesivo, con lo que la probabilidad de colisión decrece exponencialmente, hasta que eventualmente ambos eligen intervalos distintos, momento en el cual el que elige el intervalo más bajo transmite primero. El segundo lo hará más tarde, cuando llegue su intervalo elegido, siempre y cuando el primero ya haya terminado para entonces; de lo contrario el segundo quedará entonces a la espera de que el primero termine para transmitir inmediatamente después. El cómputo del tiempo a efecto del cálculo de intervalos discurre independientemente de que el medio físico se encuentre libre u ocupado. Este mecanismo se conoce con el nombre de retroceso exponencial binario.

Supongamos ahora que una estación ha sufrido una primera colisión, por lo que se encuentra en su segundo intento; aquí elegirá uno de dos posibles intervalos (0 y 1). Si elige el primero transmitirá inmediatamente, mientras que si elige el segundo esperará 5,12 µs. Por tanto el primer reintento introduce de media un retardo de 2,56 µs (suponiendo un reparto equitativo entre ambos intervalos). Si se produce una segunda colisión la estación tendrá que iniciar un tercer intento, eligiendo esta vez entre cuatro posibles intervalos (0, 1, 2 y 3) lo cual introducirá un retardo medio adicional de 7,68 µs (0+5,12+10,24+15,36=30,72/4=7,68). Como este segundo retardo se sumará al ya sufrido en el primer intento podemos estimar que el retardo acumulado en este segundo intento es de 2,56+7,68=10,24 µs.

El retroceso exponencial binario tiene la interesante propiedad de ser autoadaptativo, ya que a medida que crece el tráfico aumenta la probabilidad de colisión, lo cual introduce un retardo creciente en las estaciones emisoras con la consiguiente disminución del tráfico. Para evitar introducir retardos excesivos el número de intervalos deja de duplicarse cuando una estación sufre diez colisiones sucesivas. A partir de ese momento se intenta transmitir la trama seis veces más, pero manteniendo constante el número de intervalos [32]. Si la colisión no se resuelve en 16 intentos el protocolo MAC descarta la trama y reporta el fallo al nivel de red.

En la tabla 4.11 se muestra la evolución en el número de intervalos, rango de tiempo, retardo medio por intento y retardo acumulado medio, para los 16 intentos posibles, en el caso de una red de 10 Mb/s. Sustituyendo los valores de tiempos apropiados se podría construir una tabla similar para el caso de 100 ó 1000 Mb/s.

Número del Intento	Rango de Intervalos	Rango de Tiempo (ms)	Retardo medio (ms)	Retardo acumulado Medio (ms)
0	0	0	0,0	0,0
1	0 - 1	0 - 51,2	25,6	25,6
2	0 - 3	0 - 153,6	76,8	102,4
3	0 - 7	0 - 358,4	179,2	281,6
4	0 - 15	0 - 768,0	384,0	665,6
5	0 - 31	0 - 1.587,2	793,6	1.459,2
6	0 - 63	0 - 3.225,6	1.612,8	3.072,0
7	0 - 127	0 - 6.502,4	3.251,2	6.323,2
8	0 - 255	0 - 13.056,0	6.528,0	12.851,2
9	0 - 511	0 - 26.163,2	13.081,6	25.932,8
10	0 - 1023	0 - 52.377,6	26.188,8	52.121,6
11	0 - 1023	0 - 52.377,6	26.188,8	78.310,4
12	0 - 1023	0 - 52.377,6	26.188,8	104.499,2
13	0 - 1023	0 - 52.377,6	26.188,8	130.688,0
14	0 - 1023	0 - 52.377,6	26.188,8	156.876,8
15	0 - 1023	0 - 52.377,6	26.188,8	183.065,6
16	Se descarta	-	-	-

Tabla 4.11.- Evolución de los intentos tras sucesivas colisiones para una red Ethernet de 10 Mb/s

Un detalle importante a destacar del retroceso exponencial binario es que cuando una estación consigue finalmente transmitir una trama su contador de iteraciones se pone a cero, con lo que al transmitir la siguiente empezará el proceso desde el principio, como si nada hubiera ocurrido. No existe por tanto memoria entre tramas. Esta circunstancia discrimina positivamente a la estación afortunada en una colisión frente al resto, ya que además de conseguir enviar su trama se encuentra en posición ventajosa de cara a los nuevos ‘enfrentamientos’ que tenga que celebrar más tarde con la estación (o estaciones) perdedoras. Esta es la causa del fenómeno denominado efecto captura, del que hablaremos más adelante.

La colisión es el mecanismo previsto en Ethernet para la regulación del tráfico, por lo que una cierta proporción de colisiones es algo completamente normal, especialmente si hay tráfico elevado y se transmiten tramas pequeñas. La denominación colisión es desafortunada, ya que hace pensar en un suceso incorrecto e indeseable, que normalmente no debería ocurrir. Probablemente si se hubiera elegido el término coincidencia o solapamiento el evento parecería menos alarmante y la industria de los LEDs amarillos no se habría desarrollado tanto como lo ha hecho.

4.4.4 Rendimiento de Ethernet

4.4.4.1 Tasa de colisiones y rendimiento

Muchos concentradores y equipos de medida incorporan algún indicador de la tasa de colisiones de una red. Dado que a menudo esta información se utiliza como un primer indicador del rendimiento de una red es importante comprender su significado.

Podemos definir la tasa de colisiones mediante la siguiente fórmula:

        Tasa_col = N_col / (N_col +N_trans)

Donde:

        Tasa_col:        Tasa de colisiones

        N_col:           Número de colisiones ocurridas por segundo

        N_trans:   Número de tramas transmitidas correctamente por segundo

A menudo la tasa se especifica de forma porcentual. Por ejemplo una tasa de colisiones del 10% indica que se produce de media una colisión por cada nueve tramas transmitidas correctamente.

Si conocemos la tasa de colisiones y el tamaño medio de trama de una red (Tr_med) podemos realizar un cálculo aproximado del rendimiento o eficiencia (Ef) de la misma. Para ello haremos la simplificación de suponer que una colisión bloquea el medio de transmisión durante un tiempo equivalente a lo que tarda en transmitirse una trama del tamaño mínimo; dado que, como sabemos, todas las colisiones serán detectadas antes, esta aproximación resulta bastante conservadora y nos debe dar una aproximación pesimista de la situación [33]. Haciendo dicha suposición podemos derivar la siguiente fórmula para la eficiencia:

        Ef =1-(Tasa_col*512)/(Tasa_col * 512+(1-Tasa_col)* Tr_med)

Por ejemplo en una red con una tasa de colisiones del 30% y un tamaño medio de trama de 512 bits la eficiencia será:

        Ef =1-(30% * 512 bits)/(30% * 512 bits+70%*512 bits) =0,7=70%

Así pues para tramas de tamaño mínimo la tasa de colisiones en la red expresa directamente la eficiencia perdida. Supongamos ahora la misma tasa de colisiones, pero con un tamaño de trama de 534 bytes (4272 bits), que según diversos estudios corresponde al valor medio de redes Ethernet en entornos de grupos de trabajo. Aunque las tramas sean mayores la hipótesis de que cada colisión consume el tiempo equivalente a 512 bits es igualmente válida, por lo que la eficiencia sería en este caso de:

Ef = 1-(30% * 512 bits)/(30%*512 bits+70%*4272 bits)=0,951=95,1%

Podemos ver pues que el efecto de las colisiones en la pérdida de eficiencia se atenúa de forma notable a medida que aumenta el tamaño de trama en la red.

A menudo se plantea la cuestión de cual es la tasa de colisiones máxima aceptable en una red Ethernet. Lamentablemente no existe una respuesta única a esta pregunta, ya que las colisiones pueden variar en un rango muy amplio en función de diversos factores, en especial el tamaño de trama. Por ejemplo con tramas de 512 bits puede ser normal una tasa de hasta el 20-30%; en cambio con tramas de 1500 bytes una tasa de colisiones del 4% podría indicar una importante saturación. De forma muy general podemos decir que en redes ‘normales’ (con tamaños de trama en torno a los 500 bytes) una tasa de colisión superior al 10% de forma sostenida debe ser investigada y aclarada, ya que podría ser síntoma de algún problema. El nivel de ocupación es un parámetro mucho más indicativo del estado de una red que la tasa de colisiones.

4.4.4.2 Capacidad de Ethernet: mitos y realidades

En su artículo de 1976 sobre Ethernet [1] Metcalfe y Boggs realizaban una estimación de rendimiento basada en datos puramente teóricos. Según ellos cuando en una red Ethernet hay un número muy elevado de estaciones, todas ellas separadas por la distancia máxima y transmitiendo tramas del tamaño mínimo permitido de acuerdo con una distribución de Poisson la situación es equivalente a la de un ALOHA ranurado con intervalo 2t. Como ya era sabido entonces el rendimiento máximo de un sistema de este tipo es del 36,8%. Esto provocó la creencia muy extendida (y recogida en alguna literatura) de que el límite práctico del funcionamiento de una red Ethernet se situaba en torno al 30-40% de su capacidad nominal [34]. Pero en la realidad las condiciones son muy diferentes a las supuestas por Metcalfe y Boggs:

La separación entre las estaciones es normalmente bastante menor que la distancia máxima.

o Las tramas transmitidas son normalmente mayores que el tamaño mínimo.

o Raramente se encuentran más de 100 estaciones en una misma red Ethernet.

o El tráfico no sigue una distribución de Poisson, sino que tiene un comportamiento autosimilar.

Cada uno de estos factores aumenta el rendimiento respecto al modelo seguido por Metcalfe y Boggs, hasta el punto de que la estimación del 36,8% resulta tan conservadora que no tiene nada que ver con la realidad. La confusión creada respecto al rendimiento de una red Ethernet fue tal que en 1988 Boggs escribió un artículo titulado ‘Measured Capacity of an Ethernet: Myths and Reality’ [2] en el que realizaba medidas con tráfico real en redes con diversos retardos y tamaños de trama, y comprobaba la influencia decisiva de estos factores en el rendimiento. Boggs y sus colaboradores demostraron que en la práctica una red Ethernet puede llegar a niveles de ocupación muy próximos al 100%, y que en la mayoría de los casos en que se produce inestabilidad o problemas de rendimiento en una Ethernet la causa es una implementación incorrecta del protocolo, sobre todo del algoritmo de retroceso exponencial binario, en los equipos y controladores de red.

Las pruebas realizadas por Boggs demuestran que el rendimiento de una red Ethernet depende fundamentalmente de tres factores:

El tamaño de trama utilizado. A mayor tamaño de trama mayor rendimiento.

El número de estaciones. A menor número de estaciones mayor rendimiento.

El tiempo de ida y vuelta, A menor tiempo mayor rendimiento

Boggs concluye su estudio con las siguientes recomendaciones:

No instalar ‘cables’ largos [35]: para cubrir un área extensa es preferible dividir el cable con puentes o routers, no con repetidores.

o No poner demasiados ordenadores en un mismo cable: es conveniente utilizar routers o puentes para dividir la red en comunidades de interés; de esta forma se aumenta el retardo del tráfico inter-comunidades a cambio de un mejor rendimiento y menor tiempo de respuesta en el tráfico intra-comunidades.

o Implementar el protocolo correctamente: una detección de colisiones y un retroceso exponencial binario apropiados en la interfaz y el software del host son esenciales para un buen rendimiento.

o Utilizar el tamaño de trama máximo posible: esto reduce la probabilidad de colisión y el costo de proceso en los hosts.

o No mezclar aplicaciones de transferencia masiva de datos con aplicaciones de tiempo real: no es posible garantizar simultáneamente el mínimo retardo y el máximo rendimiento (aunque para requerimientos moderados ambos tipos de aplicaciones puedan coexistir).

Probablemente el factor que más influye en el rendimiento de Ethernet es el tamaño de trama utilizado. Dado que la colisión sólo puede suceder durante los primeros 512 bits de la trama podemos decir simplificando que cuando ésta tiene 512 bits de longitud el riesgo de colisión es permanente, mientras que si tiene 12144 bits (1518 bytes) la colisión sólo puede producirse durante los primeros 512, es decir el 4,2% del tiempo. Realmente el riesgo de colisión no existe durante los primeros 512 bits, sólo durante los primeros 2t bits (2t=tiempo de ida y vuelta entre esas dos estaciones) pero en cualquier caso el riesgo de colisión será 24 veces menor con tramas de 12144 bits que con tramas de 512 bits. Por tanto dado un nivel de ocupación constante el número de colisiones se reduce, y el rendimiento aumenta, si aumenta el tamaño de trama. Otras consideraciones (tiempo de proceso, cabeceras, etc..) aconsejan también la utilización de tramas grandes para mejorar el rendimiento de una red Ethernet.

Otro factor que influye en la eficiencia, es el número de estaciones transmisoras. Esto se puede comprender fácilmente de manera intuitiva con el siguiente razonamiento. Supongamos que en una red hay una sola estación que transmite de forma aleatoria, con un nivel de ocupación medio de 8 Mb/s: en tal caso no podrá haber colisiones (ya que una estación nunca colisiona consigo misma). Si hay dos estaciones, cada una transmitiendo (aleatoriamente) una media de 4 Mb/s, existirá un cierto riesgo de colisión. Si hay ocho estaciones transmitiendo cada una a 1 Mb/s de media el riesgo será mayor, ya que al aumentar el número de transmisores su distribución en el tiempo es más aleatoria y hay más probabilidad de que dos o más colisionen. Así pues dado un nivel de ocupación constante el número de colisiones disminuye si se reduce el número de estaciones transmisoras. Así por ejemplo la práctica de poner dos tarjetas de red a un servidor para mejorar su rendimiento podría llegar a ser contraproducente si ambas tarjetas se conectan a la misma red (salvo que esto permita superar limitaciones inherentes a otras partes del sistema, en cuyo caso el rendimiento global aumentará). Evidentemente en estos casos lo aconsejable sería conectar las dos tarjetas a redes diferentes y a ser posible dedicadas, por ejemplo a puertas de un conmutador.

El tercer parámetro que influye en el rendimiento de Ethernet, y sobre el que más se puede influir es el tiempo de ida y vuelta entre estaciones. Como ya sabemos las colisiones siempre ocurren en los primeros 512 bits de la trama. En realidad casi siempre ocurren mucho antes, ya el valor de 2t entre estaciones raramente es igual al máximo permitido. Para verlo consideremos de nuevo la red de la 4.8, formada por dos ordenadores unidos a través de dos concentradores y separados por 200 m de cable; esto daba un valor de 2t equivalente a 506 bits. Las colisiones entre estos dos ordenadores siempre ocurrirán en el bit 506, o antes. En el caso de tramas de 512 bits de longitud el riesgo de colisión estará presente el 99% del tiempo de transmisión (506/512=0,99 [36]).

Supongamos que podemos conectar todos nuestros ordenadores a un solo concentrador, con lo que suprimimos un concentrador (0,92 µs) y 100 m de cable (1,11 µs) y reducimos el valor de 2t a 303 bits (1 µs de las tarjetas, 0,92 µs de un concentrador y 1,11 µs de 100m de cable). En este caso el riesgo de colisión sólo estará presente durante los primeros 303 bits por lo que con tramas de 512 bits el riesgo se dará el 59% del tiempo (303/512=0,59). Así pues con este cambio hemos reducido las colisiones en un factor 303/506, o sea en un 40%. Aunque en el razonamiento anterior hemos supuesto el tamaño de trama mínimo el razonamiento se puede aplicar a cualquier tamaño de trama obteniendo idéntica mejora en cualquier caso. Por consiguiente dado un nivel de ocupación constante el número de colisiones disminuye si se reduce el tiempo de ida y vuelta entre las estaciones que transmiten en la red. Por tanto para mejorar el rendimiento de una red es recomendable revisar su topología aproximando en lo posible las estaciones (suprimiendo concentradores innecesarios o tendidos de cable innecesariamente largos). Este tipo de reestructuraciones deberán aplicarse en primer lugar a las estaciones que más tráfico generan, ya que de esta forma se conseguirá una máxima rentabilidad de los esfuerzos invertidos.

Una consecuencia curiosa de la influencia del tiempo de ida y vuelta en las colisiones es que, dada una misma topología de red, tamaño de trama, número de estaciones y nivel de ocupación relativa, la probabilidad de colisión aumenta a medida que aumenta la velocidad, ya que el valor de 2t.medido en bits aumenta. Este efecto es especialmente notable en el caso de Gigabit Ethernet. Por ejemplo supongamos tres redes a 10, 100 y 1000 Mb/s, formadas todas ellas por un concentrador al que se conectan varios ordenadores con cables de 100 m. El valor de 2t entre dos ordenadores cualesquiera será entonces de 203, 414 y 3860 bits para las redes de 10, 100 y 1000 Mb/s, respectivamente (valores calculados según las reglas del Modelo 2). Suponiendo un tamaño de trama de 512 bytes (4096 bits) en todos los casos, existirá riesgo de colisión durante el 5% del tiempo de transmisión de una trama en la red de 10 Mb/s (203/4096=0,05), mientras que para las redes de 100 y 1000 Mb/s este riesgo estará presente durante el 10 y 94% del tiempo de transmisión, respectivamente. La tasa de colisiones, dada una misma ocupación relativa en las tres redes, seguirá proporciones similares; por ejemplo supongamos que para una ocupación del 60% (equivalente a un caudal de 6 Mb/s) hemos medido en la red de 10 Mb/s una tasa de colisiones del 2%; en ese caso podemos predecir que la red de 100 Mb/s tendrá una tasa de colisiones del 4% para un tráfico similar con una ocupación equivalente a 60 Mb/s, y la de 1000 Mb/s tendrá una tasa del 38% con una ocupación de 600 Mb/s [37]. Aplicando a este supuesto las fórmulas que hemos visto en el apartado anterior podemos calcular la eficiencia, que resulta ser del 99,9%, 99,6% y 63,4% para 10, 100 y 1000 Mb/s respectivamente. Por último a partir de ésta y del nivel de ocupación podemos calcular el caudal útil o ‘goodput’ de cada red, que es de 5,994, 59,76 y 380,4 Mb/s para las tres redes, respectivamente.

Las estimaciones que hemos hecho en este apartado y el anterior se basan en un modelo muy simplificado del funcionamiento de Ethernet. Esta sencillez, aunque no da resultados muy precisos, resulta de gran utilidad ya que permite, a partir de un conjunto reducido de parámetros normalmente fáciles de obtener, realizar estimaciones, comparaciones, y predecir de forma cuantitativa las consecuencias que pueden tener modificaciones en la topología, velocidad, caudal o tipo de tráfico de una red. Esta información es muy valiosa en la planificación de redes.

4.4.4.3 Excesivas colisiones y colisiones tardías

Mientras que una tasa importante de colisiones puede ser normal en una red en determinadas circunstancias, hay dos situaciones excepcionales relacionadas con las colisiones que merecen comentarse, ya que en caso de producirse pueden tener un fuerte impacto en el rendimiento. Estas son la ocurrencia de 16 colisiones consecutivas (también denominada excesivas colisiones) y las colisiones tardías.

Como ya hemos comentado cuando una estación sufre 16 colisiones consecutivas el nivel MAC descarta la trama e informa del suceso al nivel de red, que decide las acciones a tomar. Por ejemplo en el caso de IP el evento es ignorado, por lo que cuando se requiere un transporte fiable son los niveles superiores (TCP o NFS [38], por ejemplo) los que por omisión detectan la pérdida de la trama y solicitan su reenvío. Dado que estos protocolos han sido diseñados bajo la premisa de que el nivel de red es altamente fiable, la retransmisión es una acción extraordinaria que genera una merma considerable en el rendimiento. Por ejemplo en el caso de TCP la pérdida de una trama genera el reinicio del proceso conocido como ‘slow-start’, con una drástica reducción en el tamaño de ventana utilizado. En NFS el estándar establece que el período de retransmisión ha de ser de al menos 700 ms, con lo que en el caso de perder una trama la retransmisión se hará al menos 700 ms más tarde. En [16]puede encontrarse una discusión detallada de los aspectos de rendimiento de Ethernet, con especial énfasis en el caso de NFS.

Normalmente la ocurrencia de 16 colisiones consecutivas se debe a una saturación extrema o a algún problema físico en el cableado, tarjeta o transceiver de alguna estación y debe considerarse síntoma de mal funcionamiento. El suceso se puede monitorizar mediante un analizador o a través de los contadores de dispositivos de red (por ejemplo conmutadores) accesibles vía SNMP. Ante una situación de este tipo es importante localizar la causa y remediarla, corrigiendo la avería o aislando al ‘culpable’ en la medida de lo posible (por ejemplo aumentando la capacidad o reorganizando los equipos para repartir mejor el tráfico en la red).

El otro tipo de suceso anormal es el que se conoce como colisiones tardías, y en cierto modo es aún más grave que el anterior, ya que si bien las excesivas colisiones se pueden dar en condiciones de saturación extrema, no puede haber colisiones tardías en una red de topología válida. Cuando una estación Ethernet transmite una trama se supone que la colisión sólo puede ocurrir durante los 512 primeros bits¹⁰. Una colisión pasado el bit 512 sólo puede ocurrir si existen en la red dos estaciones separadas por una distancia de ida y vuelta mayor que 2t. Esto se debe a una topología inválida o a una avería en el nivel físico.

Supongamos por ejemplo la red ‘ilegal’ de la Tabla 4.9. Teníamos un valor de 2t de 621 bits. En este caso la detección de las colisiones sólo está garantizada para tramas superiores a 621 bits. Cuando dos estaciones transmitan tramas que tengan entre 512 y 621 bits podrán ocurrir tres cosas, en función del instante exacto en que cada estación empiece a transmitir, por ejemplo:

a) Ambas estaciones empiezan a transmitir en el mismo instante. Se producirá una colisión en el centro de la red, que ambas detectarán cuando estén transmitiendo el bit número 310. El evento se considera normal y se aplica el mecanismo de retroceso exponencial binario.

b) Una estación empieza a transmitir 3 µs después que la otra. En este caso la primera estación detectará una colisión cuando esté transmitiendo el bit número 610 de la trama, y la segunda la detectará en el bit 10 [39]. Para la primera estación se trata de una colisión tardía, ya que ha ocurrido pasado el bit 512. La estación aplica el retroceso exponencial binario pero reporta el suceso como anormal mediante un mensaje en consola, o incrementando un contador de colisiones tardías. Para la segunda estación se trata de una colisión completamente normal.

c) La segunda estación empieza a transmitir 3 µs después que la primera, pero esta vez la trama que envía la primera estación tiene una longitud menor de 610 bits. En este caso la colisión no es detectada por la primera estación, ya que para cuando ésta tiene lugar la estación ya ha terminado y ha dado por buena la transmisión. La trama se perderá sin que el nivel MAC del transmisor reciba ninguna notificación del incidente, ya que aparentemente para él todo ha sido normal. Si los protocolos de nivel superior implementan un servicio fiable la pérdida será finalmente detectada y la trama retransmitida, a costa de una pérdida importante de rendimiento.

Las colisiones tardías (caso b anterior) no producen en sí mismas problema de rendimiento, puesto que, aunque con retraso, son detectadas. Sin embargo su presencia indica que se están produciendo colisiones no detectadas, como el caso c) anterior, y éstas sí que suponen un problema de rendimiento. Por tanto las colisiones tardías deben investigarse siempre que se produzcan. Una red Ethernet puede estar funcionando normalmente y tener decenas de colisiones por segundo, pero una sola colisión tardía es síntoma de un problema grave en la red.

4.4.4.4 Reparto no equilibrado de recursos y Efecto captura

Uno de los objetivos de diseño de cualquier red local es que en condiciones de alta ocupación la capacidad se debe repartir de forma equilibrada entre las estaciones. A primera vista cabría pensar que el protocolo CSMA/CD cumple esta condición, al carecer de un mecanismo de reserva de capacidad o asignación de prioridades, pero la realidad es muy distinta. Debido a la forma como se resuelven las colisiones la red reparte de forma equitativa el número de tramas transmitidas por segundo, no el número de bits por segundo, por lo que el ancho de banda que obtiene una estación en una red saturada es proporcional al tamaño de las tramas que emite; una estación que emita tramas grandes conseguirá más ancho de banda que una que envíe tramas pequeñas.

Como consecuencia de lo anterior en condiciones de saturación los usuarios que transmiten paquetes grandes (por ejemplo servidores FTP, HTTP o flujos de vídeo MPEG) consiguen proporciones sustancialmente mayores de la capacidad disponible que los que manejan paquetes pequeños (como sesiones Telnet o voz sobre IP). Si en una red saturada se encuentran compitiendo usuarios que transmiten paquetes pequeños y grandes (cosa muy normal dada la diversidad de aplicaciones en uso en cualquier red actual) se producirán diferencias notables en el reparto de los recursos entre ellos. Por ejemplo un usuario que transmita voz sobre IP y tenga que competir en una red saturada con otros que envían flujos de vídeo MPEG detectará retrasos en la comunicación que probablemente hagan inviable su comunicación, aun cuando el esté utilizando una proporción pequeña de la capacidad existente. En estos casos habrá que diseñar la red de forma que dichos usuarios no compitan entre sí por el ancho de banda, o sobredimensionar la red para evitar llegar a la saturación.

Otro desequilibrio más sutil que el anterior es el que se conoce como efecto captura, que se da en una circunstancia como la siguiente: supongamos una red Ethernet formada por dos ordenadores, A y B, cada uno de los cuales dispone de una cola infinita de tramas a enviar. A es un ordenador muy potente, capaz de procesar y preparar la trama a enviar en un tiempo inferior al del hueco entre tramas (96 bits), por tanto A sería capaz en principio de saturar la red él solo, concatenando cada trama con la siguiente. Por el contrario B es un ordenador más lento, incapaz de saturar la red, ya que no puede preparar las tramas en tan poco tiempo. Supongamos ahora que A y B intentan empezar a transmitir a la vez, produciéndose por tanto una colisión. Supongamos que en la segunda iteración A elige el intervalo 0 y B el 1, con lo que A consigue transmitir primero y B lo hará después. B no puede transmitir enseguida que A termine, ya que tiene que respetar el hueco entre tramas; pero B colisionará con A, ya que para entonces A tiene preparada una segunda trama que intenta enviar a la vez que B intenta reenviar la primera; esta colisión es segundo intento para B pero primero para A (puesto que para A se trata de una nueva trama que no ha sufrido ninguna colisión anterior). Por tanto A reintentará eligiendo entre los intervalos 0 y 1, mientras que B reintentará eligiendo entre 0, 1, 2 y 3. Estadísticamente A tendrá más probabilidades de transmitir antes, ya que ha de elegir entre un rango de intervalos menor, y por tanto tiene más probabilidades de elegir uno más pequeño. Este proceso se repite en las tramas siguientes, siendo la situación cada vez más favorable a A, ya que B aumentará su número de intervalos en cada nuevo intento, mientras que A, al conseguir transmitir su trama, pone a cero su contador cada vez. Finalmente B agotará el máximo de 16 colisiones consecutivas, momento en el cual descarta la trama y pone a cero su contador; sólo entonces podrá competir en igualdad de condiciones con A, pero dada la rapidez de A el ciclo se repite y la situación pronto se vuelve de nuevo desfavorable a B. A puede transmitir miles de tramas por cada trama que transmite B. Este fenómeno se conoce como efecto captura [17]y para que se dé es preciso que una estación sea capaz de encadenar tramas, es decir que su potencia de proceso le permita saturar la red.

El efecto captura provoca retardos muy grandes e impredecibles en la red; se puede detectar por diversos síntomas, siendo el más obvio una proporción anormal de excesivas colisiones. Obsérvese sin embargo que la estación o estaciones que producen excesivas colisiones son las víctimas, no los culpables. La culpable será evidentemente una estación potente, que ocupe una gran cantidad de la capacidad de la red durante ciertos períodos de tiempo (no necesariamente muy largos) y que tenga un número de colisiones relativamente bajo para las tramas transmitidas. Evidentemente el concepto de estación ‘potente’ hay que entenderlo relativo a la velocidad de la red; cualquier PC actual es capaz de saturar una Ethernet de 10 Mb/s. También se puede producir el efecto captura por la acción combinada de dos estaciones que actuando en ‘tándem’ sean capaces de saturar la red

El efecto captura es consecuencia de la forma como funciona el retroceso exponencial binario y de su ausencia de ‘historia’, es decir de la puesta a cero del contador de colisiones después de cada transmisión. Algunos autores lo consideran un fallo del diseño original de Ethernet. La verdad es que cuando Metcalfe diseñó Ethernet partía de la hipótesis de que la capacidad de la red era bastante superior que la de los ordenadores a ella conectados; entonces no era concebible que un ordenador fuera capaz de saturar una red de 3 ó 10 Mb/s (un gran ordenador de finales de los 70 difícilmente podía enviar datos a 500 Kb/s). En cambio hoy en día un ordenador personal adecuadamente preparado es capaz de saturar una red de 100 Mb/s.

Se han planteado diversas soluciones al problema del efecto captura. Algunas suponen pequeñas modificaciones al algoritmo del retroceso exponencial binario, y otras plantean su completa sustitución por otros algoritmos, como el denominado Método de Arbitración Logarítmico Binario (BLAM, Binary Logarithmic Arbitration Method) propuesto en 1994 [17]. Con este algoritmo se asegura un reparto más homogéneo de los recursos. El IEEE ha puesto en marcha un grupo de trabajo, el 802.3w, para el estudio del BLAM y su posible incorporación al protocolo 802.3. Sin embargo el futuro de este grupo es incierto, ya que el algoritmo ha de implementarse en hardware y requiere nuevas interfaces de red, lo cual complica la migración. Los fabricantes no han mostrado gran interés (hasta la fecha no existe ninguna interfaz de red y sólo IBM ha desarrollado un chip que incorpora BLAM). Además, la actual tendencia a constituir redes conmutadas, en las que cada ordenador se conecta a una puerta de conmutador dedicada, tiene el efecto colateral de resolver el problema del efecto captura, ya que cada ordenador dispone de un enlace full dúplex dedicado donde no se producen colisiones.

4.4.5 Comparación con otras tecnologías

El abrumador dominio que Ethernet presenta en el mundo de las redes locales no es fruto de la casualidad. Las ventajas que a finales de los ochenta o principios de los noventa podían presentar otras tecnologías de red local, tales como Token Ring, FDDI o 100VG-AnyLAN, desaparecieron o quedaron muy reducidas al aparecer Fast Ethernet y las redes conmutadas (que al permitir la transmisión full-dúplex eliminaban la restricción de la distancia). Si alguna ventaja podía quedar en algún caso para las otras redes el precio se encargó de compensarla sobradamente. La aparición de Gigabit Ethernet hace la diferencia aún más evidente, ya que ni por precio ni por prestaciones se puede argumentar a favor de otras tecnologías. La disponibilidad de velocidades de 10/100/1000 Mb/s permite estructurar de forma jerárquica y racional el backbone de una compleja red de campus sin cambio en el formato de las tramas,cosa que no sería posible con ninguna de las otras tecnologías. Por no mencionar la posibilidad de agregar paulatinamente enlaces de una misma velocidad, cubriendo así la gama intermedia de velocidades. La fiabilidad y robustez, argumento que a veces se ha esgrimido a favor de FDDI, puede obtenerse de forma sencilla en Ethernet con un diseño redundante que utilice el protocolo spanning-tree. En esta competición solamente parece quedar un rival en pie, que justamente no proviene del mundo de las redes locales sino de las de área extensa. Ese rival es ATM.

Es bien conocida la flexibilidad de ATM en el desarrollo de redes integradas para el transporte de tráfico multimedia (voz, vídeo y datos), y éste es el principal argumento que normalmente se esgrime en su favor. Sin duda una red local basada en ATM es más apropiada que una red Ethernet cuando se pretende basar en ella la telefonía clásica de una empresa. Sin embargo, si el tráfico multimedia va a ser transportado sobre IP es muy probable que las sofisticadas funciones de control de tráfico ATM no se aprovechen en absoluto.

Por ejemplo, si utilizamos LAN Emulation en nuestra red local ATM todo el tráfico discurre por circuitos UBR, con lo que las posibilidades de calidad de servicio son las mismas que si hubiéramos utilizado Gigabit Ethernet, o sea ningunas. Sin embargo estaremos pagando una penalización en torno al 20% de la capacidad nominal de los enlaces debido a las cabeceras ATM, la información de control AAL5 y la fragmentación en celdas de 53 bytes, que requerirá la mayoría de las veces la inclusión de relleno en la última celda.

Si en vez de LAN Emulation utilizamos por ejemplo Classical IP sobre ATM reduciremos el overhead, pero no podremos utilizar mas que un protocolo en la red.

Para poder aprovechar realmente las facilidades de calidad de servicio que ATM nos brinda debemos conectar directamente a ATM los equipos de usuario final. En este caso tendremos que asumir unos costos bastante mayores que los de Ethernet. Una tarjeta ATM con interfaz OC-3c (155,52 Mb/s) cuesta unas cuatro veces mas que una Fast Ethernet. Incluso la ATM25 (25,6 Mb/s), que fue diseñada para ofrecer conectividad ATM a bajo costo, cuesta el doble que una Fast Ethernet. La tarjeta con interfaz 1000BASE-T tiene ya un precio solo ligeramente superior al de la OC-3c y es previsible que su precio baje de forma considerable en los próximos meses conforme se populariza su uso. Además si ofrecemos conectividad ATM al usuario final tendremos que asumir otros costos menos evidentes, como los que supone configurar, administrar y gestionar una red en la que cada equipo está conectado a ATM, donde las cosas aun distan mucho del plug & play de Ethernet.

El tráfico multicast/broadcast, tan utilizado por algunos protocolos de red local, no está tan bien resuelto en ATM como en Ethernet.

Cabe plantearse la posibilidad de utilizar un entorno híbrido, en el que la conectividad del usuario final se realice por Ethernet y el backbone discurra por ATM, utilizando conmutadores LAN-ATM para el acceso. Antes de la aparición de Gigabit Ethernet esta configuración aún tenía cierto sentido, ya que con la interfaz de 155 Mb/s se conseguía una capacidad ligeramente superior a Fast Ethernet o FDDI (125 Mb/s efectivos al restar el overhead introducido por LAN Emulation); y a unos precios realmente elevados era posible disponer de velocidades superiores utilizando la interfaz OC-12c (622,08 Mb/s, 500 Mb/s efectivos con LAN Emulation), disponible en algunos fabricantes.

Sin embargo, con la aparición de Gigabit Ethernet las redes ATM se han quedado por debajo en velocidad, y bastante por arriba en precios. Un conmutador ATM con puertas OC-12c cuesta entre tres y cinco veces lo que un conmutador Gigabit Ethernet con un número similar de puertas, y como hemos visto este último ofrece aproximadamente el doble de capacidad por puerta.

A pesar de todo lo anterior hay que destacar que ATM sigue teniendo un papel en las redes locales cuando la versatilidad y control de tráfico sean factores fundamentales, independientemente de las consideraciones de costo y sencillez.

4.4.6 Futuro

La tabla 4.12 resume los desarrollos en marcha en grupos de trabajo del IEEE y de la TIA que hemos ido comentando:

Grupo de trabajo	Objetivo	Productos comerciales pre-estándar
IEEE 802.1p	Prioridades	Sí
IEEE 802.3w	Algoritmo BLAM (Binary Logarithmic Arbitration Method)	Chips únicamente
IEEE 802.3ad (borrador)	Agregación de enlaces	Sí
TIA SWLA (Short Wave Length Alliance) PMD (Physical Media Dependent)	Medio físico 100BASE-SX	Sí
TIA SWLA (Short Wave Length Alliance) AN (Autonegotiation)	Autonegociación de velocidad en fibra óptica en 1ª ventana (10BASE-FL/100BASE-SX)	Sí

Tabla 4.12.- Grupos de trabajo activos en tecnología Ethernet

Con la posible excepción del 802.3w es muy probable que todos estos grupos cumplan sus objetivos.

Aparte de los desarrollos en marcha comentados existen ya un grupo de trabajo en marcha para estudiar la viabilidad de elaborar un estándar de Ethernet de 10 Gb/s.

La información sobre este futuro estándar es tan escasa que poco podemos decir al respecto. Actualmente las únicas tecnologías de transmisión de datos estándar que superan en velocidad a Gigabit Ethernet son las que aparecen en la tabla 4.13.

Estándar	Velocidad (Gb/s)	Aplicación
OC-48c	2,488	SONET/SDH, ATM
OC-192	9,953	SONET/SDH, ATM (experimental)
SCI (Scalable Coherent Interface)	4	LANs
GSN (Gigabyte System Network)	8	LANs

Tabla 4.13.- Tecnologías estandarizadas con velocidades superiores a 1 Gb/s

El nivel físico de Ethernet a 10 Gb/s se podría basar en la tecnología desarrollada para SONET/SDH OC-192, procediendo de forma análoga a como se hizo en su día con FDDI o Fibre Channel. Sin embargo, mientras que FDDI o Fibre Channel eran tecnologías LAN más o menos maduras, SONET/SDH OC-192 es una tecnología de área extensa de reciente aparición, de desarrollo muy limitado y extremadamente cara, utilizada hasta ahora únicamente en enlaces principales de grandes operadores. Si se decide utilizar código 8B/10B será preciso elevar la velocidad de señalización hasta 12,5 Gbaudios para obtener 10 Gb/s efectivos [40].

En OC-192 la transmisión es por fibra óptica monomodo mediante láser, con alcances de 20-40 Km en segunda ventana y 60-120 Km en tercera. Parece pues que el medio natural de transmisión para 10Gb Ethernet será la fibra monomodo en segunda ventana. En fibra multimodo la dispersión limitaría la distancia máxima a valores muy reducidos (en principio unos 60m), difícilmente aprovechables salvo para un entorno de sala de máquinas. Sin embargo es posible que la continua mejora de la calidad de las fibras, junto al reparto de la señal en varias fibras (con lo que la señalización podría hacerse a menor frecuencia), permita mantener una distancia de 200-300m en fibra multimodo, lo cual la haría aprovechable para entornos de edificios. Incluso cabe pensar en el uso de cables de cobre de 50 pares para conexiones de corta distancia (equivalente al actual 100BASE-CX). Este tipo de soluciones se están adoptando en GSN, como veremos más adelante.

Los problemas habidos en Gigabit Ethernet para mantener el funcionamiento en modo half dúplex hacen sospechar que la nueva 10Giga Ethernet solo funcionará en modo full dúplex. Con unas velocidades de transmisión cada vez más elevadas la latencia, debida a la distancia física entre los equipos, empezará a ser cada vez mas el factor limitante de la capacidad. Será necesario adaptar los protocolos de transporte para poder aprovechar tales velocidades.

La combinación de las técnicas de agregación de enlaces (etherchannel) y WDM podrían permitir un aumento aun mayor en la capacidad. Los dispositivos WDM podrían estar embebidos en el propio conmutador, con lo que el funcionamiento sería transparente al usuario. Mas aún, las versiones recientes de WDM (DWDM Dense Wavelength Division Multiplexing) permiten multiplexar 16 o 32 canales en una misma fibra, lo cual ampliará aún más las posibilidades.

Yendo aun mas lejos podemos imaginar la velocidad que tendrá una red Ethernet dentro de 25 años. Para entonces podríamos estar hablando de Terabit Ethernet (1000 Gb/s), pero empezaremos a tener otro problema: la notación 1000000BASE-TX resulta excesivamente tediosa. Seguramente este será uno de los más fáciles de resolver.

4.4.7 Ethernet isócrona

Como ya hemos visto el protocolo CSMA/CD no permite asegurar un reparto equitativo del ancho de banda. Un ordenador con suficiente capacidad de generación de tramas puede monopolizar la red sin que las demás puedan hacer nada por evitarlo. Tampoco existe un límite máximo al tiempo que un ordenador ha de esperar para enviar una trama en una situación de congestión. Este problema se ve acentuado por fenómenos como el efecto captura, ya explicado. Por estos motivos Ethernet no es una red apropiada para la transmisión de tráfico isócrono, como voz o vídeo en tiempo real.

Para este tipo de tráfico se creó una variante de Ethernet denominada Ethernet Isócrona, cuya estandarización ha llevado a cabo el comité IEEE 802.9. Las primeras implementaciones de Ethernet isócrona (también llamada Iso-Ethernet o ISLAN, de Integrated Services LAN)) se llevaron a cabo en 1992, si bien el estándar no se aprobó hasta 1995.

La Ethernet isócrona utiliza codificación 4B/5B, más eficiente que la Manchester para acomodar una capacidad mayor. De esta forma empleando la misma velocidad de señalización de 20 Mbaudios de Ethernet se pueden transmitir 20 * 4/5 = 16 Mb/s. Solo estan soportados los medios UTP-5 y fibra óptica.

De la capacidad total del medio físico se reservan 6,208 Mb/s para transportar una trama síncrona de 97 bytes que es generada cada 125 ms, y que se estructura como 97 canales de 64 Kb/s compatibles con RDSI, de los cuales 96 actúan como canales B (Bearer,portadores) y uno como canal D de señalización; por tanto lo podemos ver como un 'superprimario' RDSI de 96 B + D. Esto permite utilizar en la red local aplicaciones diseñadas para RDSI; las estaciones de la red que lo deseen pueden a través del canal D solicitar los canales B que deseen, quedando reservados 64 Kb/s por cada canal asignado. El tráfico asíncrono (es decir el normal de Ethernet) no se ve afectado ya que utiliza la capacidad restante (9,792 Mb/s) funcionando con el protocolo CSMA/CD de la misma forma que en Ethernet.

En la práctica la Ethernet Isócrona nunca ha llegado a extenderse comercialmente, y no es probable que lo haga en el futuro. Esto probablemente se deba en parte a que requería sustituir todo el equipamiento de red (concentradores, tarjetas, etc.) debido al sistema de codificación utilizado, que difiere de Ethernet.

4.5 ESTÁNDAR IEEE 802.5: TOKEN RING

Con cierto retraso respecto a los experimentos de Xerox con Ethernet IBM estaba experimentando con un protocolo MAC denominado Token Ring (anillo con paso de testigo). Este protocolo también fue estandarizado por el IEEE con el número 802.5, si bien su desarrollo comercial fue algo más lento que el de 802.3; los primeros productos comerciales de Token Ring aparecieron en 1986. Existen tres variantes de Token Ring: a 1, 4 y 16 Mb/s; las de 4 y 16 Mb/s son las más utilizadas (la de 1 Mb/s ha sido suprimida del estándar).

El cableado utilizado es STP o UTP de categoría 3 o superior para 4 Mb/s, y STP para 16 Mb/s. La señal se representa usando codificación Manchester diferencial, con señales de +3,0 y -4,5voltios. La codificación Manchester diferencial emplea la presencia o ausencia de transición entre dos voltajes para indicar un 0 o un 1, respectivamente. Requiere un equipo mas caro y complejo que la codificación Manchester, pero es mas inmune al ruido y esta mejor adaptada al uso de cable de pares, ya que no tiene problemas de polaridad invertida como ocurre con Manchester (a diferencia de Ethernet el cable de pares fue previsto en Token Ring ya en el diseño original).

En las redes tipo bus (como 802.3) la fiabilidad depende de la continuidad del cable, que pasa por todas las estaciones y puede ser motivo de manipulaciones no autorizadas. Este problema se resolvió en 802.3 con el cableado 10BASE-T, que manteniendo la topología lógica de bus utiliza un cableado en estrella. En el caso de topologías en anillo como Token Ring el problema es similar, ya que la rotura del anillo en un punto impide la comunicación. Para evitar este problema en Token Ring lo que se hace es colapsar el anillo en un hub o concentrador, también llamado centro de cableado, al cual se conectan los cables de entrada y salida de cada estación. El cableado sigue siendo lógicamente un anillo, aún cuando físicamente sea una estrella. En el concentrador se instalan relés de derivación (bypass) alimentados por la estación correspondiente, de forma que si la conexión de ésta falla el relé cortocircuita la conexión correspondiente restaurando así el anillo. En la práctica la topología física no es muy diferente a la de una red Ethernet. Una red Token Ring puede estar formada por varios concentradores interconectados, lo cual permite reducir apreciablemente la cantidad de cable necesario. También es posible constituir dobles anillos para tener mayor fiabilidad, pues en caso de corte por un punto el doble anillo puede cerrarse sobre sí mismo superando el problema. Aunque la topología física de cableado pueda estar formada por varios anillos o estrellas interconectadas, desde el punto de vista del protocolo una red Token Ring está formada siempre por un único anillo lógico.

4.5.1 El protocolo de subcapa MAC de Token Ring

Podemos considerar a una red Token Ring como un conjunto de líneas punto a punto simplex que interconectan cada estación del anillo con la siguiente. Los bits se transmiten en un determinado sentido dentro del anillo. Cada bit y cada trama transmitida da la vuelta completa, por lo que a efectos prácticos la red funciona como un medio broadcast.

Cada estación de la red puede funcionar en uno de los dos modos siguientes:

o Modo a la escucha: cada bit que se recibe del ordenador anterior se transmite al siguiente. En algunos casos que luego veremos un ordenador a la escucha puede modificar algún bit de la trama que pasa por el.

o Modo transmisión: el ordenador emite una secuencia de bits propia (trama) hacia el siguiente; paralelamente recibe y procesa los bits que le llegan del ordenador anterior en el anillo.

En un determinado momento sólo un ordenador en una red Token Ring puede estar en modo transmisión, y los demás han de estar a la escucha. Si no hay tráfico en la red todos los ordenadores están a la escucha.

El protocolo Token Ring funciona de la siguiente manera:

o Cuando ningún ordenador desea transmitir todos están en modo escucha y se envía por el anillo una secuencia especial de tres bytes denominada token. El token va pasando de un ordenador a otro indefinidamente.

o Cuando algún ordenador desea transmitir debe en primer lugar esperar a que pase por él el token; en ese momento modifica un bit de éste, con lo que el token se convierte en el delimitador de inicio de trama; a partir de ese momento el ordenador pasa a modo transmit y envía la trama al siguiente.

o Todos los demás ordenadores del anillo (incluido aquel para el que va destinada la trama) siguen en modo escucha, por lo que retransmitirán la trama recibida bit a bit hacia el siguiente ordenador; el ordenador destinatario además de retransmitirla retiene una copia de la trama que pasará al nivel de red para su proceso.

o Pasados unos instantes desde el inicio de la transmisión el ordenador emisor empieza a recibir su misma trama, que le es enviada desde el ordenador anterior; el transmisor puede optar entonces por descartar los bits recibidos o compararlos con la trama enviada para verificar si la transmisión ha sido correcta.

o Cuando el ordenador ha terminado de transmitir el último bit de su trama pueden ocurrir dos cosas: que restaure el token en el anillo inmediatamente, o que espere a recibir de la estación anterior toda su trama y solo entonces restaure el token. El primer modo de funcionamiento se conoce Early Token Release y es el que se utiliza en las redes de 16 Mb/s; el segundo es el utilizado en las redes de 4 Mb/s.

Si el ordenador transmisor tiene varias tramas listas para emitir puede enviarlas una tras otra sin liberar el token, hasta consumir el tiempo máximo permitido, denominado 'token-holding time', que normalmente es de 10 mseg. Una vez agotadas las tramas que hubiera en el buffer, o el tiempo permitido (lo que ocurra primero) el ordenador restaura el token en el anillo. Bajo ninguna circunstancia debe un ordenador estar en modo transmit durante un tiempo superior al token-holding time; si la longitud de la trama a enviar es tal que no terminaría de enviarse dentro del tiempo restante se regenera el token y se espera a la siguiente vuelta para enviarla. Esta condición establece un tamaño máximo para la trama; así por ejemplo en una Token Ring de 4 Mb/s con un token-holding time de 10 ms una trama nunca podrá ser mayor de 5.000 bytes.

Cada estación que se integra en la red añade una cierta cantidad de 'jitter' en la retransmisión de la información, lo cual limita el número máximo de estaciones que pueden estar presentes en una red Token Ring. En las redes de 4 Mb/s con cable UTP el máximo de estaciones es de 72, mientras que en las de 16 Mb/s con cable STP el máximo es de 250 estaciones.

Veamos cual es la estructura de una trama de datos Token Ring:

Campo	Longitud (bytes)	Formato o significado
SD (Start Delimiter)	1	JK0JK000
AC (Access Control)	1	PPPTMRRR
FC (Frame Control)	1	FFZZZZZZ
Dirección de destino	2 ó 6	IEEE 802
Dirección de origen	2 ó 6	IEEE 802
Datos	Sin límite	Cualquiera
Checksum	4	CRC
ED (End Delimiter)	1	JK1JK1IE
FS (Frame Status)	1	AcrrACrr

Tabla 4.14.- Estructura de la trama 802.5

Los símbolos J y K utilizados en el campo SD son símbolos inválidos, es decir que no pueden ocurrir en la codificación manchester diferencial. Esto permite una fácil identificación del inicio de la trama.

El byte de control de acceso (AC) contiene tres bits de prioridad P, el bit de token T (un 1 indica una trama, un 0 un token), el bit monitor (M) y tres bits de reserva (R).

Las direcciones tienen el mismo formato que en 802.3. Normalmente sólo se utilizan las de 6 bytes.

El campo datos puede tener cualquier longitud, sin más limitación que la impuesta por el token-holding time como se ha explicado.

El campo checksum es un CRC que se calcula de la misma forma que en 802.3.

El campo ED (end delimiter) marca el final de la trama. Sus seis primeros bits forman una secuencia inválida en la codificación Manchester diferencial, ya que contiene los símbolos J y K. El séptimo bit (I) se utiliza para indicar la última trama cuando lo que se transmite es una secuencia de tramas (vale 1 en todas excepto en la última). El octavo bit (E) indica si se ha producido un error en la transmisión de la trama entre dos ordenadores del anillo. Si alguno detecta un error en la trama al pasar por su interfaz (por ejemplo una secuencia de símbolos inválida en la codificación Manchester diferencial, o un error en el campo checksum) pondrá a 1 este bit.

El campo FS (frame status) contiene dos bits denominados A y C (Address-recognized y frame-Copied) que están siempre a cero en la trama enviada. Cuando la trama pasa por el ordenador de destino, éste pone a 1 el bit A; si además la interfaz de red ha podido copiar la trama en su buffer pondrá también a 1 el bit C (un ordenador podría no poder copiar una trama por carecer de espacio en su buffer, por ejemplo). Los dos bits siguientes están reservados. La estructura de los cuatro primeros bits se repite idéntica en los cuatro siguientes, de forma que los bits A y C están repetidos. Esto da una mayor seguridad ya que por su posición en la trama el byte FS no es comprobado en el checksum.

La estructura de un token es una versión simplificada de la de una trama. Contiene únicamente los campos SD, AC y ED. En el campo AC el bit de token está siempre puesto a 0. En el campo ED los bits I y E están siempre a 0.

De la estructura de una trama token ring podemos deducir algunas de sus características. En primer lugar, el protocolo incorpora un mecanismo de acuse de recibo automático en los bits A y C del campo FS.

El bit E del campo ED suministra un mecanismo de detección de errores en la transmisión, que también esta integrado en el protocolo.

Por otro lado, el campo AC dispone de tres bits para prioridad, lo cual permite establecer hasta 8 niveles distintos de prioridad, que funcionan de la siguiente manera: cuando un ordenador desea transmitir una trama con prioridad n debe esperar a que pase por el un token de prioridad menor o igual que n. Además, los ordenadores pueden aprovechar una trama en tránsito para solicitar al emisor un token de una determinada prioridad; estas solicitudes se escriben en los bits de reserva del campo AC. Un ordenador sólo puede utilizar los bits de reserva si éstos no contienen ya una petición de mayor prioridad. Cuando la trama de datos vuelva a su originador éste emitirá un token de la prioridad solicitada, que será la más alta que hubiera pendiente en el anillo. En el caso de funcionar con Early Token Release este mecanismo de prioridad queda parcialmente deshabilitado debido a que el emisor ha de restaurar el token antes de haber recibido las solicitudes de reserva.

Las tramas Token Ring tienen un Interframe Gap menor que Ethernet, de sólo 1 byte (equivalente a 2 ms) en las redes de 4 Mb/s y de 5 bytes (equivalente a 2,5 ms) en las de 16 Mb/s. Esto se debe a que en Token Ring no es preciso utilizar el Interframe Gap como indicador del principio o final de la trama, estos estan delimitados mediante las secuencias SD y ED.

Resumiendo, el protocolo MAC de Token Ring incorpora una serie de mecanismos que permiten:

o Definir niveles de prioridad

o Disponer de mecanismos de acuse de recibo y detección de errores en la red

o Un sistema de asignación de canal que permite ocupar prácticamente en su totalidad el ancho de banda disponible sin que se produzcan colisiones.

A cambio la necesidad de esperar la llegada del token impone una mayor latencia que Ethernet en situaciones con poca carga.

Aunque Token Ring implementa un mecanismo con ocho niveles de prioridad en la práctica virtualmente todas las aplicaciones diseñadas para Token Ring utilizan únicamente la más alta, ya que a falta de un mecanismo que motivara a emplear prioridades inferiores nadie está interesado en utilizarlas. Esta funcionalidad se ha traducido pues en algo inútil pero complejo y costoso de implementar.

Existe una iniciativa denominada High Speed Token Ring dirigida a modificar el estándar para incluir velocidades de funcionamiento superiores.

4.5.2 Mantenimiento del anillo

Hasta ahora hemos supuesto que los tokens están permanentemente 'flotando' en la red cuando no hay tramas de datos viajando. Pero que ocurre si por ejemplo se pierde una trama, o si sencillamente la estación encargada de regenerar el token desaparece de repente?. En toda red Token Ring hay una estación denominada monitor que se ocupa de resolver estas situaciones y garantizar el normal funcionamiento del protocolo. En caso de problemas restaurará un token en el anillo para que el tráfico pueda seguir circulando normalmente. Cualquier estación de una red token ring está capacitada para actuar como monitor en caso necesario. Veamos en detalle como sucede.

Cuando un ordenador se añade a la red (bien porque se conecte a ella o porque se encienda estando ya previamente conectado) escucha la red en busca de tokens o tramas de datos. Si no detecta actividad emite una trama de control especial denominada claim token. Si existe ya un monitor éste responderá con un token a la petición. Si no, el ordenador recién incorporado a la red recibirá su propio claim token, momento en el cual pasará a constituirse en monitor.

El monitor se ocupa también de una importante función. El token es de 24 bits pero no se almacena en ningún ordenador en concreto, sino que va pasando bit a bit de uno a otro. Para que el protocolo pueda funcionar es necesario que el tamaño de la red permita mantener el token 'volando' en todo momento. Por ejemplo, en una red Token Ring de 4 Mb/s se emite un bit cada 0,25 ms, equivalente a una longitud de 50m (a 200.000 Km/s); en este caso un anillo de 1.200 metros permitiría mantener en el cable los 24 bits del token, aún cuando todos los ordenadores de la red estuvieran fuera de servicio. Inversamente, en un anillo con 24 ordenadores funcionando, independientemente de cual fuera la longitud del anillo, los 24 bits siempre podrían estar en los buffers de los ordenadores que se encuentran a la escucha (cada uno de ellos tiene un buffer de un bit); sin embargo, si el número de ordenadores conectados y la longitud de cable existente no permiten albergar el token la red podría dejar de funcionar al no tener el anillo capacidad suficiente. El monitor se ocupa entonces de facilitar los buffers necesarios para garantizar que en todo momento la red puede albergar los 24 bits del token.

4.6 FDDI (ANSI X3T9.5)

FDDI funciona a 100 Mb/s. El estándar correspondiente fue definido inicialmente por ANSI y más tarde adoptado por ISO como el estándar internacional ISO 9314. No se trata pues de un estándar IEEE, aunque sigue su misma arquitectura. Análogamente a los otros estándares, el documento describe la capa física y la subcapa MAC. Para la parte LLC se utiliza el estándar IEEE 802.2.

Las características de velocidad, distancia y fiabilidad de FDDI la convirtieron durante algún tiempo en la red ideal para ser utilizada como columna vertebral (backbone) que concentre las redes locales de una gran organización, como una fábrica o un campus universitario.

FDDI tiene muchos elementos comunes con Token Ring, y en cierta medida puede considerarse una evolución de aquella tecnología. La topología es de doble anillo para aumentar la seguridad, no la velocidad. En condiciones normales un token gira por cada anillo en sentido opuesto. Las estaciones pueden ser SAS (Single Attach Station) si están enchufadas a un anillo únicamente, o DAS (Dual Attach Station) si lo están a ambos. Si se produce un corte en los anillos las estaciones DAS más próximas a cada lado del corte unen entre sí ambos anillos, con lo que se crea un anillo de mayor longitud que permite mantener conectados todos los ordenadores. En el caso de producirse un segundo corte en otro punto del anillo se crean dos anillos aislados, cada uno de los cuales puede seguir funcionando. Las interfaces DAS son más caras que las SAS, pero dan una mayor tolerancia a fallos al permitir cerrar el anillo.

El medio físico de transmisión es fibra óptica multimodo o cable de cobre UTP Categoría 5. En ocasiones la FDDI de cobre se denomina CDDI (Copper Distributed Data Interface), aunque realmente este nombre corresponde a una implementación antigua, no estándar; el nombre correcto del estándar en cable de cobre es TP-PMD (Twisted Pair- Physical Media Dependent). En este caso se utiliza una topología física similar a la de 10Base-T, con los ordenadores conectados a concentradores. La distancia máxima del ordenador al concentrador es de 100 metros. También es posible utilizar concentradores para la conexión de ordenadores por fibra óptica.

FDDI puede considerarse una versión evolucionada de Token Ring en muchos de sus aspectos. No se utiliza señalización Manchester ya que esto supondría 200 Mbaudios, lo cual hubiera requerido una electrónica demasiado cara en las tarjetas de red. En su lugar se diseñó una codificación denominada 4B/5B, que también se utilizó mas tarde en Iso-Ethernet y Fast Ethernet. De esta forma la interfaz física funciona a 125 Mbaudios.

La codificación 4B/5B ahorra ancho de banda, pero pierde la característica de autosincronismo que tenía la codificación Manchester. Para compensar este inconveniente se introduce un largo preámbulo de al menos 16 símbolos (90 bits) al principio de la trama o del token.

La estructura de una trama y token FDDI es muy similar a los de Token Ring. La longitud máxima del campo datos puede ser de hasta 4500 bytes.

El protocolo MAC de FDDI es también muy parecido al de Token Ring. La diferencia más notable es que en FDDI siempre se funciona con el principio de Early Token Release, es decir, la estación emisora no espera a escuchar su propia trama para restaurar el token. Existe también un token-holding timer que establece el tiempo máximo que una estación puede transmitir de una vez. Este parámetro tiene importantes consecuencias en el rendimiento de la red; el valor por defecto de 4 ms es adecuado en la mayoría de las situaciones, excepto en las redes muy grandes (más de 20 Km) en que es conveniente aumentarlo.

Existe una versión modificada de FDDI, denominada FDDI-II, que permite manejar tráfico isócrono (voz, vídeo y datos en tiempo real). Para la transmisión de este tipo de tráfico FDDI-II define una trama especial, denominada trama síncrona, que se emite cada 125 ms por un ordenador que actúa como maestro; una trama síncrona contiene 96 bytes de información útil, equivalentes a 6,144 Mb/s, que con la información de cabecera ocupan 6,25 Mb/s . Este ancho de banda queda reservado para la estación maestra y no puede ser utilizado para tramas asíncronas (es decir, normales). La estación maestra puede reservar espacio para tramas síncronas adicionales, hasta un máximo de 16, con lo que toda la capacidad de la red quedaría reservado para tráfico síncrono. En resumen, en FDDI-II coexiste TDM con un canal compartido en el mismo medio físico. En cierto modo es algo parecido a Iso-Ethernet, salvo que aquí en vez de usar capacidad adicional se 'roba' parte de la capacidad normal. Para poder utilizar FDDI-II es preciso que todas las estaciones del anillo soporten el funcionamiento en modo híbrido, es decir, la coexistencia de tramas síncronas con tramas asíncronas.

El desarrollo de FDDI-II ha quedado prácticamente congelado con la aparición de ATM en redes locales, ya que ATM ofrece el mismo tipo de servicios de forma mas flexible y a un precio inferior.

Hasta 1995-1996 FDDI era la principal tecnología de red de alta velocidad; sin embargo su grado de implantación siempre ha sido escaso. La principal razón de esto ha sido su elevado costo comparado con las redes locales más tradicionales, como Ethernet o Token Ring. Hoy en día ha sido completamente superada por Fast Ethernet y Gigabit Ethernet.

4.7 ESTÁNDAR IEEE 802.2: LLC

Como ya hemos dicho, la subcapa MAC forma la mitad inferior de la capa de enlace en las redes broadcast. Sobre ella se encuentra la subcapa LLC (Logical Link Control) que corresponde en funciones a la capa de enlace de las líneas punto a punto, esto es realiza la comunicación punto a punto entre lso dos equipos que interactúan.

El IEEE ha desarrollado el estándar 802.2 para especificar el protocolo de esta subcapa. Este protocolo es compatible con todos los protocolos de nivel MAC de la serie 802, de forma que todas las redes locales 802 presentan una interfaz común a la capa de red independientemente de cual sea el medio físico y el protocolo MAC que se esté utilizando. El protocolo LLC está basado en HDLC.

LLC suministra tres tipos de servicio:

o LLC Tipo 1: datagramas sin acuse de recibo. Este es el mas utilizado. Es un servicio similar al ofrecido por PPP en redes de área extensa. No hay control de flujo, pues no hay realimentación del receptor al emisor. A diferencia de PPP aquí no se realiza verificación de errores pues esta ya ha sido efectuada por la subcapa MAC, como hemos visto.

o LLC Tipo 2: servicio orientado a conexión fiable. Es similar al ofrecido por HDLC. Se realiza control de flujo, es decir el receptor solicitará al emisor que pare en caso necesario. El receptor solicita además retransmisión si detecta error en el checksum.

o LLC Tipo 3: Es un intermedio de los dos anteriores. El emisor envía datagramas y solicita acuse de recibo, pero estos son enviados también como datagramas, no hay un proceso explícito de establecimiento de la conexión como ocurre en el tipo 2.

La mayoría de los protocolos de red utilizados, como IP, requieren únicamente el LLC de tipo 1; en este caso las funciones de la subcapa LLC son casi inexistentes (recodemos que se ha suprimido incluso la verificación del CRC).

La principal función que desempeña la subcapa LLC es suministrar el soporte multiprotocolo, es decir multiplexar o 'etiquetar' adecuadamente los paquetes recibidos de los diferentes protocolos posibles en el nivel de red antes de pasarlos a la subcapa MAC. Esto se hace mediante unos campos especiales en la trama LLC, como veremos a continuación. En el caso de redes Ethernet con trama en formato DIX la capa LLC es totalmente inexistente ya que esta información se suministra en el Ethertype como ya hemos visto.

La estructura de una trama LLC normal es compleja y poco elegante. Para comprender como se llegó a ella es preciso repasar la evolución histórica. La estructura inicialmente aprobada por el IEEE para la trama LLC era la indicada en la tabla 4.15.

Campo	Longitud (bytes)
DSAP (Destination Service Access Point)	1
SSAP (Source Service Access Point)	1
LLC Control	1 ó 2
Datos	Variable

Tabla 4.15.- Estructura de la trama LLC 802.2

El campo LLC Control desempeña aquí un papel equivalente al campo control de la trama HDLC. Según el tipo de servicio LLC utilizado sus valores podrán ser unos u otros. Por ejemplo en LLC tipo 2 se utilizan los mismos tipos de trama y comandos que en HDLC, mientras que en LLC tipo 1 el campo control siempre vale X'03' (00000011) que significa tramas no numeradas, es decir envío de datagramas sin acuse de recibo, como ocurre en PPP, por ejemplo.

Los campos DSAP y SSAP tienen la finalidad de permitir identificar a que protocolo de red pertenece la trama LLC. La posibilidad de identificar por separado el protocolo en el origen y el destino permite que los dos ordenadores asignen diferentes números al mismo protocolo, cosa realmente rebuscada, o que dos protocolos de red diferentes puedan intercambiar directamente paquetes, cosa también nada habitual . Aunque se reserva un byte para especificar el protocolo los dos primeros bits del DSAP y el SSAP estan reservados, ya que tienen significados de grupo/individual y local/global, igual que ocurre con las direcciones MAC del IEEE. Por tanto en realidad solo hay seis bits disponibles para especificar el protocolo. Con únicamente 64 posibles valores el campo DSAP/SSAP se mostró rápidamente insuficiente (solo unos pocos protocolos privilegiados del IEEE y de ISO han podido obtener números de DSAP/SSAP), por lo que había que idear un mecanismo que permitiera extender en longitud el campo protocolo.

La solución fue reservar un valor en el DSAP y el SSAP (el hexadecimal 'AA') para indicar la existencia de un campo adicional denominado SNAP (SubNetwork Access Protocol), inmediatamente a continuación del campo LLC Control y antes de los datos, que permitiría especificar con holgura cualquier protocolo (afortunadamente se abandonó la idea absurda de que diferentes ordenadores utilizaran diferentes códigos para un mismo protocolo, con lo que no fue preciso incluír dos campos SNAP). Como la mayoría de las arquitecturas trabajan de forma más eficiente extrayendo campos cuyo número de bytes sea potencia entera de dos se consideró que 5 bytes era la longitud más adecuada para el campo SNAP, ya que así la cabecera LLC-SNAP tendría 8 bytes (en la mayoría de los casos el campo LLC control tiene una longitud de 1 byte, ya que normalmente se utiliza LLC tipo 1). El campo SNAP se divide en dos partes, de forma parecida a las direcciones MAC del IEEE: los primeros tres bytes forman lo que se denomina el OUI (Organizationally Unique Identifier) que identifica al fabricante que registra el protocolo ante el IEEE, mientras que los dos últimos identifican el protocolo dentro de ese fabricante.

En realidad el IEEE no abrió un nuevo registro de OUIs, sino que asignó a cada fabricante de forma automática los OUIs correspondientes a los rangos de direcciones MAC que ese fabricante tenía asignadas. De esta forma cuando un fabricante compra al IEEE un rango de 16 millones de direcciones MAC también esta comprando por el mismo precio un rango de 65536 posibles protocolos que puede definir.

Merece la pena mencionar que el 'OUI' '000000' se reserva para indicar que el campo Tipo (los dos bytes siguientes) especifican el protocolo utilizado siguiendo el convenio de la trama DIX Ethernet ya comentado.

Así, excepto para los pocos protocolos privilegiados que reciben directamente un número de SAP del IEEE (todos ellos por supuesto definidos por el IEEE o la ISO) la estructura de una trama LLC 802.2 es normalmente la que se muestra en la tabla 4.16, donde a título de ejemplo mostramos el valor que tienen los diversos campos en el caso de utilizar una trama 802.2 para transportar datagramas IP.

Campo	Longitud (bytes)	Valor en datagrama IP
DSAP (Destination Service Access Point)	1	X 'AA'
SSAP (Source Service Access Point)	1	X 'AA'
LLC Control	1	X '03'
OUI (Organizationally Unique Identifier)	3	X '000000'
Tipo	2	X '0800'
Datos	Variable	Datagrama

Tabla 4.16.- Estructura de la trama LLC 802.2-SNAP

La trama LLC es la manera normal de enviar los datos en cualquier red local excepto en Ethernet, donde como ya hemos visto existen dos posiblidades:

o Usar el campo longitud en la trama MAC y poner en el campo datos una trama LLC que contiene el tipo de protocolo utilizado a nivel de red; en este caso normalmente se utilizará una trama LLC-SNAP, por lo que la longitud máxima del paquete a nivel de red será de 1500-8 = 1492 bytes. Esta es la aproximación empleada por Appletalk fase 2, NetBIOS y algunas implementaciones de IPX (Netware de Novell), por ejemplo.

o Usar el campo tipo en la trama MAC y poner directamente en el campo datos el paquete a nivel de red. En este caso la longitud máxima del paquete a nivel de red podrá ser de 1500 bytes. Este formato es empleado por TCP/IP, DECNET fase 4, LAT (Local Area Transport, de DEC) y algunas implementaciones de IPX.

El primero es referido a menudo como formato IEEE, y el segundo como formato DIX (aunque actualmente ambos formatos son aceptados por el IEEE). Si tenemos una red en la que funcionen varios de estos protocolos tendremos normalmente tramas de los dos formatos.

4.8 OTRAS REDES LOCALES

Hasta finales de los ochenta prácticamente todas las redes locales eran Ethernet o Token Ring, y en menor medida Token Bus. A finales de los 80 empezaron a aparecer otros tipos de redes locales que funcionaban a velocidades de 100 Mb/s y superiores. Vamos a dar una breve descripción de las más importantes sin entrar en tantos detalles como hemos hecho con Ethernet y Token Ring.

4.8.1 ESTÁNDAR IEEE 802.4: TOKEN BUS.

Cuando se desarrollaba el estándar ethernet algunas grandes empresas interesadas en la automatización de fábricas tenían serias dudas de la viabilidad de su aplicación a sistemas en tiempo real. La razón principal de este reparo estaba en el comportamiento no determinista de Ethernet, en principio cabía la posibilidad de que dos ordenadores no pudieran comunicarse debido al exceso de tráfico en la red. No había un límite superior al caso más desfavorable. Además, no era posible reservar capacidad o establecer prioridades.

Token Ring resolvía muchos de los problemas que se le achacaban a Ethernet , pero seguía presentando dos inconvenientes serios: el papel de la estación monitor resultaba demasiado importante, y muchas cosas podían fallar si el monitor dejaba de funcionar o se volvía loco. Además, una topología en bus era mas adecuada que un anillo para la cadena de montaje de una fábrica.

En un intento por resolver estos inconvenientes, General Motors promovió el desarrollo del estándar 802.4, también llamado Token Bus. Esta red se utiliza en algunas fábricas para el control de la maquinaria. Su uso es mucho más restringido que Ethernet o Token Ring, por lo que sólo la describiremos muy brevemente.

De una manera muy simplista podemos decir que Token Bus es un híbrido entre Ethernet y Token Ring, si bien guarda mucho más parecido con esta última red. Tiene topología de bus. Las velocidades pueden ser de 1, 5 o 10 Mb/s. La señal se transmite de forma analógica sobre cable coaxial de 75 ohmios. El medio físico es completamente incompatible con Ethernet y mucho más complejo y caro.

El protocolo MAC es más parecido a Token Ring. Aunque la topología física es de bus las estaciones constituyen un anillo lógico sobre el que va pasando el token. Existe un mecanismo de prioridades. La trama puede tener un tamaño de hasta 8190 bytes. Aunque hay un mecanismo de mantenimiento del anillo (generación del token, labores limpieza de tramas perdidas, etc.) no existe una estación omnipotente equivalente al monitor de Token Ring.

Al igual que Token Ring, Token Bus utiliza un protocolo sin colisiones por lo que puede llegar a tener un rendimiento muy cercano a su límite teórico.

4.8.2 Estándar IEEE 802.12: 100VG-AnyLAN

La alternativa paralela que nació junto con Fast Ethernet se constituyó en el comité IEEE 802.12. El nombre por el que se conoce comúnmente a esta red es 100VG-AnyLAN; VG significa Voice Grade, y AnyLAN indica el objetivo de crear una red que pudiera interoperar con las dos redes locales más habituales (Ethernet y Token Ring).

Los medios físicos y la topología de 100VG-AnyLAN son muy similares a los de Fast Ethernet.

El formato de trama de 100VG-AnyLAN puede ser Ethernet o Token Ring; en una misma red sólo es posible utilizar uno de ambos formatos a la vez. Esto permite adaptar esta red a una ya existente con el máximo de compatibilidad a la hora de utilizar puentes. Para comunicar dos redes 100VG-AnyLAN con diferente tipo de trama se debe utilizar un puente traductor 802.3 <-> 802.5, o un router.

El protocolo a nivel MAC está basado en el principio de polling (votación o sondeo en inglés); el concentrador desempeña el papel de moderador y va preguntando a las estaciones una a una en riguroso turno rotatorio si tienen alguna trama que transmitir. Después de un ciclo completo todos los nodos han sido interrogados una vez y han disfrutado de acceso al canal en igualdad de oportunidades. Cuando existe más de un concentrador se crea una estructura jerárquica donde uno de ellos se constituye en raíz y da la vez a cada uno de sus ‘hijos’, que a su vez la dan a sus nietos, y así sucesivamente. En esencia el mecanismo es similar al de una red Token Ring, pero el control de la red lo ejercen los concentradores.

Además del sondeo 'democrático' hay un rudimentario mecanismo de prioridad bajo demanda con dos niveles, alta y normal. La rondas de sondeo se hacen en dos etapas, primero buscando tráfico de alta prioridad únicamente, y luego tráfico normal. Este mecanismo permite transmitir tráfico isócrono, como voz o vídeo, clasificándolo como de alta prioridad.

Siguiendo el ejemplo de Ethernet el comité 802.12 está elaborando modificaciones al estándar para incluír velocidades de transmisión superiores, de 531 y 850 Mb/s.

Cuando aparecieron en el mercado los primeros productos Fast Ethernet y 100VG-AnyLAN se produjo una cierta pugna entre fabricantes partidarios de una u otra red. A pesar de que técnicamente 100VG-AnyLAN sea más sofisticado y versátil el mercado se ha decantado en favor de Fast Ethernet. El principal proponente y fabricante de productos 100VG-AnyLAN actualmente es HP, que fue quien efectuó la propuesta del protocolo al IEEE.

4.8.3 HIPPI - High Performance Parallel Interface (ANSI X3T9.3)

La especificación HIPPI tiene su origen en Los Alamos, uno de los principales laboratorios de armamento nuclear de los Estados Unidos. Este laboratorio es famoso por tener uno de los mayores parques instalados de supercomputadores del mundo. Dado que sus requerimientos de ancho de banda no se veían satisfechos con ninguna de las redes existentes, los investigadores de Los Alamos decidieron en 1987 diseñar una interfaz que les permitiera interconectar los supercomputadores y sus periféricos con el máximo de prestaciones posible utilizando la tecnología disponible, sin tener que diseñar componentes a propósito. Tanto en el nivel físico como en los protocolos utilizados se quería el máximo de sencillez; todos los esfuerzos debían ir enfocados a obtener el máximo rendimiento posible.

El sistema diseñado en Los Alamos se propuso en 1991 a ANSI para su estandarización. Existe también el HIPPI Networking Forum, un consorcio de vendedores y usuarios interesados en redes de alta velocidad basadas en HIPPI.

HIPPI es un protoclo orientado a conexión, establece siempre conexiones punto a punto entre los ordenadores a conectar; no existe red broadcast ni medio compartido. Existen conmutadores crossbar que permiten interconectar diversos dispositivos HIPPI entre sí.

La señalización se realiza a una velocidad relativamente baja, 25 Mbaudios (después de todo se diseñó en 1987 con componentes estándar); la elevada capacidad se consigue transmitiendo simultáneamente en paralelo por muchos cables (de ahí el nombre de 'parallel'). El medio físico de conexión es un cable de cobre STP (Shielded Twisted Pair) de 50 pares. Cada 40 ns viajan por estos pares 50 bits de información, de los cuales 32 corresponden a datos y 18 a información de control. De esta forma se consigue una velocidad nominal de 800 Mb/s. Existe también una especificación de 1.600 Mb/s, que se consigue sencillamente utilizando dos cables y doblando las interfaces, es decir, enviando 64 bits de datos y 36 de control cada 40 ns. El medio de transmisión es simplex, por lo que si se quiere comunicación full-dúplex es preciso utilizar dos (o cuatro) cables.

La distancia máxima de los cables es de 25 metros. Si se realiza una conexión a través de un conmutador HIPPI la distancia máxima entre dos dispositivos cualesquiera es de 50 metros. Es posible conectar varios conmutadores HIPPI en cascada, pudiendo en éste caso llegar a una distancia máxima de 200 metros. Existe una interfaz serie denominada 'HIPPI serial extension' (parallel-serial, suena realmente curioso) que utiliza fibra óptica, y que puede llegar a una distancia de 300 metros en multimodo y 10 kilómetros en monomodo. También es posible utilizar SONET/SDH como medio de transporte de tramas HIPPI para largas distancias.

En una conexión HIPPI el diálogo típicamente se inicia con un comando REQUEST en el que el originador solicita la conexión, que es respondido con un CONNECT por el destinatario, seguido de un READY para indicar que está en condiciones de aceptar tráfico. Las direcciones de las estaciones son de 24 bits.

Las tramas que se transmiten en un canal HIPPI son de 256 palabras (1024 bytes). Una trama se transmite en 256 pulsos de 40 ns cada uno; el protocolo utilizado a nivel de enlace es de parada y espera, aunque también puede utilizarse ventana deslizante. El control de errores se realiza mediante un bit de paridad horizontal por palabra y un bit vertical al final de cada trama. No se calculan checksums porque se consideraron innecesarios y habrían hecho demasiado lenta la transmisión.

Debido a su relativa sencillez y ausencia de florituras, HIPPI ha sido implementado por muchos fabricantes y se ha extendido con rapidez en áreas donde es necesaria una velocidad elevada, por ejemplo equipos de representación gráfica de altas prestaciones, o supercomputadores utilizados en computación paralela (aquí una gran ventaja es su pequeñísima latencia, del orden de 160 ns); también es una opción interesante como super-backbone de redes locales. Actualmente HIPPI constituye un estándar de facto en conexiones de muy altas prestaciones, y su precio aunque elevado no es exagerado si se compara con la capacidad que ofrece. Existen interfaces HIPPI incluso para ordenadores personales.

La aparición de Gigabit Ethernet ha dejado un poco olvidado a HIPPI. Recientemente se ha definido un nuevo estándar denominado GSN (Gigabyte System Network)[41] también conocido como HIPPI-6400 o 'SuperHIPPI', que contempla enlaces que funcionan a 6,4 Gb/s, ocho veces HIPPI. Actualmente GSN es la tecnología de red estándar mas rápida que existe. A pesar de su nombre GSN tiene poco en común con HIPPI, salvo el enfoque general: intentar obtener la máxima velocidad posible de forma sencilla para que el costo no sea exagerado y la implementación realizable. La señalización empleada en GSN es de 10 Gbaudios; con codificiación 4B/5B esto da 8 Gb/s; de los que 1,6 Gb/s se utilizan para direccionamiento y control de errores quedando 6,4 Gb/s netos para el nivel de red. De forma parecida a HIPPI la elevada capacidad se consigue agregando múltiples enlaces físicos, para evitar una velocidad de señalización excesiva. El estándar actualmente aprobado contempla interfaces de cobre con una distancia máxima de 40m que utilizan cable STP de 50 pares; la información se envía utilizando 20 pares para cada sentido, y diversas señales de control en los restantes; cada par transmite 500 Mbaudios. Se están preparando los estándares para dos interfaces de fibra óptica, una en primera ventana que llegará a 220m (multimodo) y una en segunda que llegará a 300m (multimodo) o a 1 Km (monomodo); en ambos casos la señal se reparte en diez fibras para cada sentido, cada una enviando 1 Gbaudio. Obsérvese el parecido con las interfaces y velocidades utilizadas en Gigabit Ethernet.

Actualmente se está considerando la posibilidad de aumentar la velocidad por fibra de GSN a 2,5 Gbaudios (2 Gb/s), y agregar 10 ó 12 enlaces, con lo que se podría tener HIPPI-16,000 o HIPPI-19,200.

4.8.4 Fibre Channel (ANSI X3T11)

Dada la capacidad y fiabilidad de las fibras ópticas resultaba paradójico que HIPPI, que durante un tiempo fue la red de mayor velocidad, estuviera basada en cable de cobre. La especificación Fibre Channel, que empezó en 1988, era una evolución natural de HIPPI. Sin embargo, a diferencia de lo que ocurrió con HIPPI, la especificación de Fibre Channel está repleta de opciones y marcada por la complejidad. Aunque esto en principio puede parecer positivo, en la práctica supuso que los productos tardaran en aparecer en el mercado y nunca hayan obtenido el éxito esperado.

Fibre Channel, al igual que HIPPI, puede utilizarse tanto para redes locales como para conectar periféricos potentes a grandes ordenadores (arrays de discos, por ejemplo). Puede utilizarse como medio de transporte de un sinfín de otras tecnologías de red, tales como tramas 802.2, celdas ATM, paquetes IP, o tramas HIPPI (HIPPI también puede transportar tramas Fibre Channel).

Una red Fibre Channel se constituye utilizando conmutadores (crossbar), concentradores o anillos. En los conmutadores cada estación tiene un ancho de banda dedicado; en el concentrador y el anillo la capacidad es compartida entre todas las estaciones; puede haber hasta un máximo de 127 estaciones en un concentrador o anillo. Los anillos Fibre Channel también se denominan FC-AL (Fibre Channel Arbitrated Loop). Se utilizan direcciones de 48 bits compatibles con las de las redes IEEE 802.

La velocidad de transferencia neta puede ser de 100, 200, 400 u 800 Mb/s. Los datos, junto con cierta información de control adicional, se codifican mediante el esquema 8B/10B, diseñado originalmente por IBM y utilizado más tarde en Gigabit Ethernet; las velocidades de señalización son 133, 266, 531 o 1.062 Mbaudios, según la velocidad de transferencia utilizada. También se contemplan en el estándar velocidades de 1,6 y 3,2 Gb/s, a las que corresponderían velocidades de señalización de 2,12 y 4,25 Gb/s, pero no existen implementaciones de estas velocidades. La interconexión de equipos se hace mediante conmutadores Fibre Channel (crossbar). El medio de transmisión puede ser cable de cobre coaxial o STP y fibra óptica monomodo o multimodo. Cada medio tiene unas limitaciones de distancia y velocidad, como muestra la tabla 4.17.

Tipo de cable	800 Mb/s	400Mb/s	200 Mb/s	100 Mb/s
Fibra monomodo	10 Km	10 Km	10 Km	-
Fibra multimodo 50 mm	500 m	1.000 m	2.000 m	10 Km
Fibra multimodo 62,5 mm	175 m	350 m	1.500 m	1.500 m
Cable coaxial de vídeo	25 m	50 m	75 m	100 m
Cable coaxial miniatura	10 m	15 m	25 m	35 m
Cable STP			50 m	100 m

Tabla 4.17.- Distancia máxima en Fibre Channel según el medio físico y la velocidad

Para reflejar la versatilidad en los medios físicos soportados se eligió el nombre fibre (fibra en francés) en vez de la denominación habitual en inglés (fiber).

Fibre Channel suministra tres clases de servicio: conmutación de circuitos con entrega en orden garantizada, conmutación de paquetes con entrega garantizada, y conmutación de paquetes sin entrega garantizada, que corresponden al servicio LLC tipo 2, tipo 3 y tipo 1 respectivamente. La parte de datos de la trama puede ser de hasta 2048 bytes. Ésta contiene un CRC de 32 bits. La tasa de errores es menor de 1 en 10¹².

Algunos consideran que la utilización por parte de Gigabit Ethernet del nivel físico de Fibre Channel permitirá aprovechar adecuadamente el trabajo realizado en su momento. Es posible que la aparición de Gigabit Ethernet, que sin duda supondrá un abaratamiento de la tecnología de redes de alta velocidad, permita una mayor difusión de Fibre Channel, ya que la mayoría de los componentes físicos desarrollados para una red pueden aprovecharse en la otra.

4.8.5 Estándar IEEE 802.6: MAN DQDB

DQDB (Distributed Queue Dual Bus) es la única tecnología de red que se identifica claramente como MAN. Ha sido especificada por el comité 802.6 de IEEE.

La topología de DQDB es un doble bus al cual se van conectando las estaciones. Cada uno se utiliza para la transmisión de los datos en un sentido. El doble bus está formado por dos cables coaxiales y puede tener una longitud de hasta 160 Km, por lo que puede realmente cubrir toda una ciudad.

La velocidad típica de DQDB es de 34/45/140/155 Mb/s (E3/T3/E4/OC3). La información viaja en celdas de 53 bytes, de lo que podemos intuir que esta tecnología tiene alguna relación con ATM.

En España ha habido muy pocas experiencias de redes DQDB, y no es probable que aparezca ninguna nueva en el futuro. Actualmente este servicio no es ofrecido por los operadores.

4.9 REDES DE SATÉLITES

Todos los tipos de redes broadcast que hemos visto hasta ahora son de corto alcance (LANs) o de mediano alcance (MANs). Aunque la gran mayoría de redes broadcast que existen son de este tipo, hay al menos una que es de largo alcance: las redes de datos vía satélite. El alcance de la huella de un satélite de comunicaciones puede variar entre 250 y 10.000 Km; dentro de esta zona sus señales pueden ser recibidas por cualquier estación que disponga de los medios necesarios.

Como ya hemos visto, la transmisión de señales ascendentes y descendentes ocurre a diferentes frecuencias, para evitar interferencias. La mayoría de los satélites no procesan las señales recibidas, y se limitan a reproducir las que reciben de la tierra; se les conoce como satélite de tubería doblada (bent pipe).

Las redes vía satélite tienen unas características singulares que dan lugar a unos problemas peculiares en lo que se refiere al protocolo de acceso al medio. Estas características son fundamentalmente dos:

o El satélite puede captar a todas las estaciones, y todas ellas pueden captar al satélite, pero una estación no puede captar directamente la señal de otra estación.

o La señal tarda aproximadamente 270 ms en hacer el trayecto completo arriba y abajo. En el caso de comunicación a través de un hub (redes VSAT) el viaje se hace dos veces, con lo que el tiempo se duplica.

Como consecuencia de estas dos características resulta imposible utilizar protocolos con detección de portadora, como CSMA/CD, ya que en el mejor de los casos la estación podría saber el estado en que se encontraba el canal 270 ms antes, o dicho de otro modo el valor de 2t sería tan grande que el rendimiento sería muy bajo, o bien el tamaño de trama mínimo tendría que ser muy grande. Los satélites son demasiado caros como para poder permitirse el lujo de no aprovecharlos bien.

En el canal descendente (satélite -> tierra) la situación es mucho más simple, ya que existe un único emisor, por lo que no existe conflicto. En cuanto al canal ascendente se emplean cinco tipos de protocolos: polling (votación), ALOHA, FDM, TDM y CDMA.

4.9.1 Polling

Hemos visto ya el concepto de polling al estudiar el protocolo MAC de la red 100VG-AnyLAN. En aquel caso el concentrador interrogaba a las estaciones una a una en riguroso turno rotatorio, por si tenían algo que transmitir. Podemos imaginar un protocolo parecido en el que el propio satélite va interrogando o 'dando la vez' a las estaciones una a una; el inconveniente es que cada secuencia pregunta-respuesta requiere como mínimo 270 ms y si la densidad de estaciones deseando transmitir es pequeña la eficiencia puede ser extremadamente baja.

Sin embargo, es posible utilizar este protocolo si la ronda de preguntas se lleva a cabo por algún medio de transmisión terrestre de bajo retardo. Por ejemplo, las estaciones podrían estar conectadas a una red X.25 o por líneas punto a punto; de esta forma podrían ir pasándose la vez formando un anillo lógico, empleando un protocolo que podríamos considerar inspirado en la red Token Ring. Cada estación sólo puede enviar datos al satélite cuando posee el Token; éste nunca subiría al satélite, pero serviría para asegurar que ninguna otra estación está utilizando el canal. La conexión terrestre entre las estaciones no necesita ser de alta velocidad, ya que la cantidad de datos a transmitir por este medio es pequeña.

4.9.2 ALOHA

Como ya hemos visto, el uso de ALOHA puro da un rendimiento máximo del 18%. Con ALOHA ranurado podemos doblar la eficiencia, pero hemos de suministrar por algún medio la señal de reloj maestra a todas las estaciones. Esto puede conseguirse de manera sencilla con el propio satélite, ya que todas las estaciones captan su señal. En la práctica la señal de referencia es generada en una estación en tierra, denominada estación de referencia, y retransmitida a través del satélite a todas las estaciones, que la utilizan para sincronizarse. La señal se repite cada cierto tiempo para corregir posibles desplazamientos. Además las estaciones toman en cuenta su distancia respecto al satélite para compensar las diferencias de tiempo que la señal tarda en llegar a cada una de ellas.

Con el ALOHA ranurado el rendimiento puede llegar al 37%. Para aumentar aún más la eficiencia se utilizan en sentido ascendente dos canales independientes; cada estación elige al azar uno de ellos (en sentido descendente sigue habiendo un único canal, ya que ahí no hay problema de contención). Si llegan dos tramas a la vez al satélite éste deberá reenviar una y almacenar la otra en su buffer para enviarla en el intervalo siguiente, suponiendo que en dicho intervalo no reciba ninguna trama. Dado que cada canal ascendente funciona como un sistema ALOHA independiente del otro el rendimiento máximo del conjunto podría llegar al 74%, por lo que no sería preciso un espacio en buffers exagerado para reducir a una cantidad despreciable la probabilidad de que se agote el espacio en buffers del satélite. Con este sistema se multiplica por 2 la eficiencia habiendo incrementado en 1,5 el ancho de banda utilizado (hemos pasado de 1+1 a 2+1).

4.9.3 FDM

La multiplexación por división de frecuencias resuelve el problema de acceso al medio repartiendo el canal de manera más o menos estática entre las estaciones que lo requieren. Una vez asignado un ancho de banda a una estación ésta lo tendrá reservado para su uso mientras no lo libere, independientemente de que lo use o no. Existen sin embargo algunos sistemas FDM que asignan canales a las estaciones de manera dinámica de acuerdo a sus necesidades.

La FDM tiene el inconveniente de que en general no se adapta bien a un tratamiento digital; la elevada componente analógica requiere establecer márgenes de seguridad entre los canales asignados, ya que los transmisores no pueden evitar emitir parte de su potencia fuera del canal ( o dicho de otra manera, la representación de potencia frente a frecuencia no es una onda cuadrada).

4.9.4 TDM

Con TDM se resuelven algunos de los problemas de FDM, especialmente los relativos al proceso analógico de la señal y a la asignación de márgenes de seguridad debido a la naturaleza no abrupta de las señales FDM. Con TDM es preciso disponer de un reloj que sincronice todas las estaciones, para lo que se utilizan mecanismos similares al que hemos visto para el ALOHA ranurado.

En su versión más simple TDM reparte la capacidad del satélite en canales o intervalos de tiempo (slots) que asigna a las estaciones que lo solicitan. Cuando una estación solicita uno o varios canales se le reserva esa capacidad hasta que la libere, independientemente de que la utilice o no.

En un nivel de sofisticación superior los slots TDM se pueden asignar dinámicamente a las estaciones que lo requieran; esto permite un mayor aprovechamiento de la capacidad del satélite. Existen varios mecanismos para la asignación dinámica de slots:

o Si el número de slots es mayor que el número de estaciones, se asigna a cada estación un slot 'de su propiedad'; los slots sobrantes quedan sin asignar y pueden ser utilizados por cualquier estación que lo solicite. Cuando en una trama una estación no ocupa su slot éste queda marcado como disponible y puede ser 'prestado' a otra. Si la estación propietaria desea recuperar su slot mas tarde transmite algo y fuerza así una colisión; en ese momento se le devuelve 'su' slot.

o El segundo mecanismo consiste sencillamente en que las estaciones compitan usando ALOHA ranurado por cada uno de los slots; una vez una estación adquiere un slot lo utiliza mientras tenga datos que enviar (siguiendo algunas reglas mínimas de cortesía). Si cada estación utiliza el slot únicamente una vez este mecanismo tiene la eficiencia de ALOHA ranurado, pero si como es de esperar la estación retiene el slot durante varias tramas la eficiencia mejora notablemente.

o En el tercer mecanismo existe un slot especial en la trama que se divide en 'subslots' donde las estaciones pueden 'solicitar' slots; si una estación solicita un slot y no colisiona con otra dicho slot le queda asignado en la siguiente trama.

4.9.5 CDMA

CDMA (Code Division Multiple Access) es un sistema de asignación de canal utilizado en telefonía celular, que también se emplea en redes de satélite.

4.10REFERENCIAS

[1] R. M. Metcalfe y D. R. Boggs: "Ethernet: Distributed Packet Switching for Local Computer Networks" Communications of the ACM 19 (7), julio 1976. Disponible en http://www.acm.org/classics/apr96/

[2] D.R. Boggs, J. C. Mogul y C. A. Kent. "Measured Capacity of an Ethernet: Myths and Reality", ACM SIGCOMM'88 Symposium on Communications Architectures & Protocols, pp. 222-234, agosto 1988. Disponible en http://www.research.digital.com/wrl/publications/abstracts/88.4.html

[3] H. W. Johnson: "Fast Ethernet - Dawn of a New Network", pag. 19, Prentice Hall, 1996

[4] R. Perlman: "Interconnections: Bridges and Routers", Addison-Wesley, 1992

[5] “Gigabit Ethernet Over Copper”. URL:http://www.gigabit-ethernet.org/technology/whitepapers/gige_1098/Gea_Cop.pdf, o mas concretamente http://www.gigabit-ethernet.org/technology/whitepapers/gige_1098/copper_2.html#correcting, octubre de 1998.

[6] “Anixter Levels Channel Solutions: Performance, not Promises”. URL:http://www.anixter.com/solution/cabling/levels97/

[7] “Testing Fiber Optic Cabling for Gigabit Ethernet”. URL:ftp://ftp.scope.com/whitepap/GigEN_fiber.pdf, julio de 1998.

[8] "Analysis of Physical Layer Requirements For 155 Mb/s Twisted Pair ATM". URL: http://www.scope.com/whitepap/WHITE12.HTM. 1998.

[9] "The ATM Controversy". URL: http://www.scope.com/whitepap/WHITE18.HTM. Julio de 1996.

[10] "Energy of 155 Mb/s ATM Power Spectrum Above 100 MHz". URL: http://www.scope.com/whitepap/WHITE13.HTM. 1998.

[11] ATM Forum: AF-PHY-0015.000, "ATM Physical Medium Dependent Interface Specification for 155 Mb/s over Twisted Pair Cable", 9/1994

[12] TIA/EIA-568-A-5 Addendum 5 (draft) "Additional Transmission Performance Specifications for 100 ohm 4-Pair Enhanced Category 5 Cabling", 8/1998.

[13] R. Seifert, “Gigabit Ethernet”. Addison Wesley, 1998.

[14] C. E. Spurgeon, "Charles Spurgeon's Ethernet Web Site". URL:http://wwwhost.ots.utexas.edu/ethernet/Topol.

[15] C. E. Spurgeon, "Practical Networking With Ethernet". International Thomson Computer Press, 1998.

[16] R. Seifert: “The Effect of Ethernet Behavior on Networks using High-Performance Workstations and Servers”, URL:http://wwwhost.ots.utexas.edu/ethernet/pdf/techrept13.pdf. Technical Report, Networks and Communications Consulting, marzo 1995

[17] Mart L. Molle: “A New Binary Logarithmic Arbitrarion Method for Ethernet". URL:ftp://www.cs.ucr.edu/pub/blam/report.ps Technical Report CSRI-298, Computer Systems Research Institute, University of Toronto, Toronto, Canada, M5S 1A1, abril 1994.

[18] B.E. Carpenter. "Characteristics and Practical use of Networks for High Energy Physics", Proc. 1986 CERN School of Computing, CERN, p. 3, 1987

4.11EJERCICIOS

1. Indique si es verdadera o falsa cada una de las siguientes afirmaciones:

a) En un protocolo MAC de tipo ALOHA el rendimiento es bajo, al no haber detección de portadora.

b) Un protocolo MAC sin colisiones (por ejemplo Token Ring) tiene siempre una latencia menor que uno con colisiones (por ejemplo Ethernet).

c) En Ethernet el mecanismo del retroceso exponencial binario asegura que en caso de producirse contención la capacidad disponible se reparte de forma equilibrada entre las estaciones.

d) La longitud máxima de una red Ethernet viene fijada por el tamaño de trama máximo y su velocidad.

e) En una red Token Ring no es posible reservar una determinada capacidad a una estación concreta de la red.

f) La codificación 8B/10B, empleada en Fibre Channel y Gigabit Ethernet, supone el envío de 10 bits codificados en 8 baudios.

g) Las direcciones IEEE (direcciones MAC de seis bytes) solo pueden utilizarse en tecnologías de red que han sido estandarizadas por dicha organización (por ejemplo IEEE 802.3, 802,5, etc.).

2. El IEEE cobra 1250 dólares USA por cada rango de direcciones MAC asignado. Calcule cuales serán los ingresos máximos que podría obtener el IEEE por este concepto.

3. Suponga que se desarrolla una variante de Fast Ethernet en la que el tamaño de trama máximo es diez veces mayor que el actual (es decir, 15180 bytes) manteniendo la velocidad de 100 Mb/s. ¿Que consecuencia tendría esto en la distancia máxima entre estaciones, también llamada diámetro de la red? Explique su respuesta.

4. Suponga que se le pide desarrollar una LAN a 10 Mb/s, optimizada para tramas de pequeño tamaño. El protocolo será CSMA/CD, idéntico a Ethernet, pero las distancias y el número máximo de repetidores entre estaciones se han definido de forma que el RTT (Round Trip Time) máximo es de 40 ms. Calcule el tamaño de trama mínimo que podría utilizarse en dicha red.

5. Cual sería la longitud mínima de cable en una red Token Ring de 4 Mb/s para que todo el token se pudiera mantener en el cable? Suponga que el cable tiene una velocidad de propagación de 0,77 c.

6. La estructura de trama Token Ring prevé la utilización de los últimos tres bits del campo AC (Access Control) para reserva de prioridad, tanto en las tramas de token como en las de datos. ¿Como cambiaría el funcionamiento del protocolo si se suprimieran estos tres bits en las tramas de datos y se mantuvieran únicamente en las de Token?

Suponga que se trata de una red de 4 Mb/s, que no utiliza por tanto el mecanismo de Early Token Release.

7. Suponga que quiere transmitir información de un host A a otro B por una red ethernet (802.3) usando tramas LLC 802-SNAP. Calcule la velocidad máxima teórica con que podrá transmitirse la información del nivel de red (cabeceras incluidas) en el caso mas favorable (usando tramas del tamaño máximo posible) y en el más desfavorable (usando tramas con un byte de información útil). Repita el cálculo usando tramas en formato DIX. Suponga que la estación A es la única que transmite en la red y que su capacidad le permite saturarla.

Si con un analizador medimos el tráfico a nivel físico en la red que resultado obtendremos en cada caso?

8. Repita el ejercicio anterior para una red Token Ring; suponga que el token holding-time es de 10 ms y que hay 20 estaciones en el anillo (aunque solo la estación A genera tráfico).

9. En una red IEEE 802.3 se envía un fichero de un ordenador a otro empleando LLC tipo 1, mediante tramas de la longitud máxima permitida; el protocolo de transporte utilizado implementa un mecanismo de acuse de recibo que permite solicitar retransmisión selectiva en caso de pérdida de una trama. Los respectivos subniveles LLC disponen de sendos contadores de las tramas enviadas y recibidas, y se quiere utilizar éstos para estimar la fiabilidad de la conexión física entre ambos ordenadores. Se contemplan dos posibles causas por las que una trama puede no ser recibida por el subnivel LLC en el receptor:

o Colisión en la red: en este caso la trama no llega a ser recibida ni siquiera por el subnivel MAC del receptor; dado que las pruebas se realizan en un momento en que no hay otra actividad en la red, este efecto se considera despreciable.

o Error en la transmisión: en este caso el subnivel MAC del receptor al comprobar el CRC descartará la trama silenciosamente sin pasarla al subnivel LLC; se supone que el nivel de transporte pedirá retransmisión más tarde (si se utiliza un protocolo de transporte fiable).

Se efectuó una prueba en la que el LLC del emisor contó 75000 tramas y el del receptor contó 74991.

Se le pide que calcule:

a) El BER (Bit Error Rate) de la conexión física entre ambos ordenadores.

b) Cada cuantas tramas transmitidas se producirá una trama errónea que será aceptada como válida al tener por pura casualidad un CRC correcto.

10. Se tiene una red Fast Ethernet formada por varios ordenadores conectados con tarjetas 100BASE-TX y cables de 10m de longitud a un concentrador clase II (bajo retardo).

El nivel de ocupación del medio físico medido con un analizador es del 40%, es decir el 40% del tiempo hay portadora en la red (la portadora indica que una o más estaciones están transmitiendo, si son más de una se producirá una colisión). El analizador detecta también una tasa de colisiones del 30%, es decir que el 30% de las tramas que se transmiten terminan en una colisión.

Calcule el 'goodput' de la red (es decir la tasa de información útil transferida) en Mb/s. Suponga que todas las tramas emitidas son de la longitud máxima permitida en Ethernet. Considere que la duración de una colisión es constante e igual al tiempo de ida y vuelta de la señal entre las estaciones que colisionan.

¿Podría decir de forma cualitativa como evolucionaría la tasa de colisiones y el goodput si los ordenadores se conectan con cables de 100 metros? Intente cuantificar su respuesta.

Información adicional

La tasa de colisiones se define como:

Número de colisiones

Tasa de colisiones = --------------------------------------------------------------------------------------

Número de tramas transmitidas correctamente + número de colisiones

Por ejemplo una tasa de colisiones del 10% significa que de cada diez intentos en nueve se ha transmitido correctamente la trama y en uno se ha producido una colisión.

11. De los tres tipos de redes que se enumeran a continuación indique cual es la más adecuada y cual la menos adecuada para establecer una vídeoconferencia que necesita 256 Kb/s:

Token Ring
Ethernet Isócrona
Fast Ethernet

4.12SOLUCIONES

S1.-

a) Verdadera. El rendimiento máximo puede ser del 18% o del 37%, según se trate de ALOHA puro o ranurado, respectivamente. Los protocolos CSMA (con detección de portadora) dan rendimientos superiores en todas las circunstancias.

b) Falsa. Si la carga de la red es baja (y por tanto la probabilidad de colisión también) Ethernet tiene una latencia menor, ya que la estación emite cuando lo desea, sin tener que esperar a que le llegue el token.

c) Falsa. En una situación de contención la estación 'ganadora' (la que consigue transmitir) pone a cero su contador, con lo que adoptará una postura mas agresiva para los envíos sucesivos que las demás; cosa que la sitúa en posición ventajosa. Esto produce el fenómeno conocido como 'efecto captura' en el que una o unas pocas estaciones pueden llegar a saturar una red.

d) Falsa. La longitud máxima viene fijada por el tamaño de trama mínimo y su velocidad.

e) Verdadera. A lo sumo es posible fijar prioridades, pero no reservar capacidad como se hace en IsoEthernet o FDDI II.

f) Falsa. La codificación 8B/10B envía 8 bits codificados en 10 baudios.

g) Falsa. También se utilizan en FDDI, Fibre Channel, y ATM, por ejemplo.

S2.-

El IEEE asigna 22 bits (los 3 primeros bytes menos los dos primeros bits, que se utilizan para indicar si la dirección es unicast o broadcast/multicast y para indicar si es local o global). Por tanto podrá asignar como máximo 2²² = 4194304 direcciones, que da un total de 5 242 880 000 dólares.

S3.-

El diámetro de una red tipo ethernet viene fijado por el valor del tiempo de ida y vuelta 2t, el cual a su vez depende del tamaño de trama mínimo utilizado (normalmente 64 bytes). El tamaño de trama máximo no tiene ninguna influencia en el diámetro de la red.

S4.-

La trama mínima debe tardar en emitirse 40 ms, lo cual a 10 Mb/s supone 400 bits. El tamaño de trama mínimo será pues de 50 bytes.

S5.-

La señal eléctrica se propaga con una velocidad de 0,77 * 3*10⁸ = 2,31 * 10⁸ m/s

A 4 Mb/s un bit tarda en emitirse 0,25 ms; en este tiempo la señal viaja:

2,31 * 10⁸ * 0,25 * 10 ^-6 = 57,75 m

El token tiene en total 24 bits, por tanto:

57,75 * 24 = 1386 m

S6.-

En el funcionamiento normal de token ring cuando una estación tiene para enviar en su buffer una trama de datos con prioridad n pueden ocurrir tres cosas:

a) Que pase por ella una trama de datos, en cuyo caso anotará en el campo reserva la prioridad que desea utilizar (salvo que este campo ya tuviera anotada una prioridad igual o superior).

b) Que pase por ella un token de prioridad m (m igual o menor que n), en cuyo caso toma el token y transmite inmediatamente. Después restaura un token con prioridad m. En el caso de que alguna otra estación le hubiera solicitado entretanto (en la trama de datos) una prioridad p (p mayor que m) generará un token con prioridad p, y solo cuando se agoten todas las peticiones de prioridad superiores a m generará el token con prioridad m. La estación que sube la prioridad del token es siempre la responsable de volverlo al valor con que lo recibió, para lo cual debe recordar la prioridad inicial.

c) Que pase por ella un token con una prioridad mayor que n; en este caso anotará en el campo de reserva de prioridad la prioridad n (salvo que ya hubiera reservada allí una prioridad igual o superior).

Obsérvese que el único mecanismo que permite aumentar la prioridad del token es el b), reserva en una trama de datos, ya que la reserva en una trama de token solo permite solicitar una prioridad inferior a la actual.

Por tanto, si se suprimen los bits de reserva de prioridad en las tramas de datos las estaciones no tienen forma de solicitar una mayor prioridad cuando otra esta transmitiendo; el token nunca cambiaría de prioridad y permanecería siempre con su valor inicial, que es cero. El resultado sería pues equivalente a haber suprimido totalmente el mecanismo de prioridades de token ring.

Así el campo reserva en las tramas de token resultaría inútil, ya que el único caso en que puede servir (supuesto c) anterior) desaparece al no poderse crear nunca tokens de prioridad superior a cero.

S7.-

En el caso más favorable la parte de datos de la trama 802.3 tendrá 1500 bytes, de los cuales 8 corresponden a la cabecera 802.2, por lo que en cada trama viajan 1492 bytes de información útil.

La información de control 802.3 añade 18 bytes a la trama 802.2 (6 dirección origen, 6 dirección destino, 2 longitud y 4 checksum) mas los 8 correspondientes al preámbulo y delimitador de inicio, lo cual nos da una trama a nivel físico de 1526 bytes. En el caso ideal cada trama estará separada de la siguiente por el interframe gap, de 9,6 ms de duración. Por sencillez vamos a considerar el interframe gap como un campo adicional de 12 bytes, ya que su duración es equivalente (aunque sabemos que durante el interframe gap no se transmite señal alguna por la red). Podemos por tanto considerar que se transmiten 1492 bytes de información útil (a nivel de red) en tramas de 1538 bytes; la eficiencia será por tanto:

1492/1538 = 0,97009

Así pues, la velocidad máxima con que puede transferirse información a nivel de red es en este caso de 9,7009 Mb/s.

En el caso de tener solo un byte de información útil a nivel de red tendremos toda la información de control de 802.2 y 802.3 (26 bytes en total) mas 37 bytes de relleno para asegurar que la trama 802.3 tiene como mínimo una longitud de 64 bytes. Estos 64 bytes unidos al preámbulo y delimitador de inicio nos dan una trama física de 72 bytes, y con el interframe gap tenemos una trama 'virtual' de 84 bytes:

1/84 = 0,011905

La velocidad máxima con que se transfiere la información en este caso es pues de 0,11905 Mb/s

Para saber el tráfico máximo que puede circular por la red calcularemos la relación entre la trama física real y la trama mas el interframe gap. En el caso de tramas del tamaño máximo será:

1526/1538 = 0,99220 -> 9,9220 Mb/s

y en el de tramas de 64 bytes:

72/84 = 0,85714 -> 8,5714 Mb/s

S8.-

Supongamos una red Token Ring a 4 Mb/s (Interframe Gap 1 byte)

Con Token Holding Time = 10 ms la trama máxima es de 5000 bytes.

En 802.5 tenemos 21 bytes de información de control, que con los ocho de 802.2 nos da 29 en total. La trama puede contener pues 4971 bytes de información útil a nivel de red. La eficiencia será:

4971/(5000+1) = 0,99400 -> 4 * 0,99400 = 3,976 Mb/s

Pero esto sería suponiendo que cada trama fuera seguida inmediatamente de otra; el protocolo token ring obliga a la estación a regenerar el token después de cada trama (pues ha consumido el token holding time); como suponemos que las demás estaciones no transmiten nada el token volverá enseguida a la estación emisora, que podrá enviar otra trama, y así sucesivamente.

Tenemos pues que en el caso óptimo se alternará una trama de datos con una de token indefinidamente. Dado que el token es una trama de 3 bytes (y su interframe gap) bastará para tenerla en cuenta añadir 4 bytes de overhead en el cálculo anterior:

4971/(5001+4) = 0,99321 -> 4 * 0,99321 = 3,973 Mb/s

En el caso de tramas del tamaño mínimo tendremos tramas de 30 bytes (29 de overhead mas 1 de información útil) y un byte de interframe gap; como el token holding time nos permite enviar durante el tiempo equivalente a 5000 bytes podremos enviar 161 de estas tramas (5000/31 = 161,2) antes de tener que regenerar el token; la eficiencia será por tanto de:

161/ (161*31+4) = 0,0322 -> 4* 0,0322 = 0,1289 Mb/s

Para calcular el nivel de ocupación bastará tener en cuenta el interframe gap; en el primer caso cada 5003 bytes de datos hay dos 'interframe gaps':

5003/5005 = 0,9996 -> 4* 0,9996 = 3,998 Mb/s

En el segundo caso se envían grupos de 161 tramas de 30 bytes seguidas de un token, y así sucesivamente:

(161*30+3) / (161*31 + 4) = 4833/4995 = 0,9676 -> 4 * 0,9676 = 3,870 Mb/s

En el caso de una red de 16 Mb/s los cálculos serían análogos, salvo por el interframe gap que sería equivalente a 5 bytes.

S9.-

a) La trama 802.3 esta compuesta por los siguientes campos:

Dirección de destino (6 bytes)

Dirección de origen (6 bytes)

Longitud del campo datos (2 bytes)

Datos (hasta 1500 bytes)

CRC (4 bytes)

Esto nos da una longitud máxima de 1518 bytes. Los demás campos de la trama 802.3 (preámbulo, delimitador de inicio e interframe gap) no se utilizan en el cómputo del CRC, por lo que no estan cubiertos por éste y en principio no deberían ser considerados en este caso; sin embargo un error en el preámbulo o el delimitador de inicio, aunque no cubiertos por el CRC, tendría la consecuencia de producir una trama errónea en la dirección de destino por lo que sería igualmente descartarda; por consiguiente estos ocho bytes también han de tenerse en cuenta a efectos de este cálculo.

Como se nos dice que se han enviado 75000 y cada una tiene 1526 bytes se han enviado en total:

75000 * 1526 * 8 = 915 600 000 bits

De las 75000 tramas se han recibido correctamente 74991; por tanto 9 tramas tenían al menos un bit erróneo. Vamos a suponer en principio que cada una de estas tramas tiene solo un bit erróneo (esta suposición la comprobaremos mas tarde). En tal caso el BER sería:

BER = 9 / 915 600 000 = 9,83 * 10^-9 » 10^-8

Con un BER de esta magnitud la probabilidad de tener una trama con un bit erróneo es de:

1518 * 8 * 10^-8 = 0,00012144

o sea una cada o sea una cada 8234 tramas (1 / 0,00012144 = 8234).

Ahora bien, la probabilidad de tener una trama con dos bits erróneos es aproximadamente de:

1518 * 8 * 10^-8
*10^-8 = 1,2144 * 10^-12

o sea, una cada 823 mil millones (1 / (1,2144 * 10^-12) = 823 * 10⁹ ). Comprobamos así que es razonable la aproximación inicialmente adoptada, de que la probabilidad de que se den dos errores en una misma trama es despreciable.

b) La probabilidad de que el CRC de una trama sea correcto por pura casualidad es de 1 en 2³², o sea 2,33 * 10^-10. La probabilidad de que esto ocurra con una trama errónea será pues:

2,33 * 10^-10 * 0,00012 = 2,79 * 10^-14

Por tanto se aceptará como correcta una trama errónea cada 1 / (2,79 * 10^-14) = 3,58 * 10¹³ tramas transmitidas.

S10.-

Calcularemos en primer lugar el retardo de ida y vuelta de la red:

Componente	Retardo (en ms)	Retardo (en bits)
2 Tarjetas de red 100BASE-TX	1,00	100
1 Repetidor clase II	0,92	92
20 metros de cable UTP-5	0,22	22
TOTAL	2,14 ms	214 bits

Como la tasa de colisiones es del 30% significa que en 30 de cada 100 tramas emitidas se produce una colisión; las 70 restantes transmiten con éxito la trama.

El tiempo de cada colisión lo estimamos igual al tiempo de ida y vuelta de la red, o sea 214 bits, o 2,14 ms (a 100 Mb/s). El tiempo de transmitir correctamente una trama es de 12144 bits (1518 * 8) o sea 121,44ms. Por tanto la eficiencia relativa es de:

(70 * 12144) / (30 * 214 + 70 * 12144) = 0,9925

y el goodput será:

100 * 0,4 * 0,9925 = 39,7 Mb/s

Por tanto la capacidad 'desperdiciada' por colisiones será de 0,3 Mb/s.

En el caso de conectar los mismos ordenadores con cables de 100m el retardo aumentara de la siguiente forma:

Componente	Retardo (en ms)	Retardo (en bits)
2 Tarjetas de red 100BASE-TX	1,00	100
1 Repetidor clase II	0,92	92
200 metros de cable UTP-5	2,22	222
TOTAL	4,14 ms	414 bits

Suponiendo que la tasa de colisiones sea ahora la misma de antes, es decir el 30%, la eficiencia sería:

(70 * 12144) / (30 * 414 + 70 * 12144) = 0,9856

y el goodput:

100 * 0,4 * 0,9856 = 39,4 Mb/s

Sin embargo en el cálculo anterior hemos supuesto que el riesgo de colisión no variaba al aumentar la distancia entre las estaciones. Esto evidentemente no es así, ya que sabemos que al aumentar la distancia el retardo aumenta y con él el riesgo de colisión. Antes la colisión solo se podía producir durante los primeros 214 bits de la trama, mientras que ahora puede ocurrir en los primeros 414 bits. Suponiendo que la probabilidad de colisión por bit es la misma en ambos casos (cosa bastante razonable dado que tenemos el mismo nivel de ocupación) significa que en el segundo caso la probabilidad de colisión es 414/214 = 1,93 veces la del primero. Si esa probabilidad era antes de 0,3 ahora será pues de 0,3 * 1,93 = 0,58. Por tanto la tasa de colisión en la nueva red será del 58% aproximadamente, si los demás factores se mantienen constantes. Esto nos da pues una eficiencia de:

(42 * 12144) / (58 * 414 + 42 * 12144) = 0,9550

y el goodput será:

100 * 0,4 * 0,9550 = 38,2 Mb/s

En este caso se pierden 1,8 Mb/s por colisiones.

Obsérvese que, con las simplificaciones que hemos aplicado, la tasa de colisiones es directamente proporcional a la distancia entre las estaciones de la red. Al aumentar ese valor aproximadamente al doble del original la tasa de colisiones prácticamente se ha duplicado. Sin embargo la capacidad 'perdida' por este efecto aumenta de forma mas acentuada, ya que se ha multiplicado por seis (ha pasado de 0,3 a 1,8 Mb/s).

S11.-

La más adecuada es Ethernet Isócrona, ya que es la única que permite reservar capacidad, con lo cual se tiene garantizada una calidad de servicio constante. En segundo lugar esta token ring, ya que nos da la posibilidad de marcar tráfico prioritario y además el protocolo MAC asegura un mínimo de recursos independientemente de la carga de la red. En último lugar esta Fast Ethernet, ya que aunque es la mas rápida de las tres no permite reservar capacidad, no establece prioridades y no garantiza una latencia máxima. La mayor capacidad de Fast Ethernet no es requerida por la aplicación que se plantea.

[1] Se eligió precisamente esta velocidad por ser exactamente la mitad que la del reloj maestro del Alto (5,88 MHz), lo cual permitía aprovechar los tics del reloj y simplificaba el diseño del adaptador de red.

[2] Se utilizaron valores superiores a 1536, no a 1500 (longitud máxima de una trama Ethernet) para dejar sitio a posibles ampliaciones que pudieran producirse en la longitud de la trama debido a información de control que pudiera aparecer en el futuro. Por ejemplo el soporte de VLANs que incorpora 802.1Q utiliza parte de este espacio adicional.

[3] Cosa por otra parte previsible (cinismo intencionado). El lector interesado en conocer el proceso que llevó al IEEE a definir la cabecera LLC de esa forma puede consultar [4].

[4] Esos campos son el DSAP (Destination Service Access Point), SSAP (Source Service Access Point, LLC Control y SNAP (SubNetwork Access Protocol), ver apartado 4.7.

[5] Escrito así, en mayúsculas y sin guión. El guión aparecería más tarde al aparecer nuevos medios físicos en los que el número se cambió por letras, por ejemplo 10BASE-T.

[6] Synoptics más tarde se fusionó con Wellfleet para constituir Bay Networks. A su vez Bay Networks fue después comprada por Northern Telecom.

[7] El nombre deriva del hecho de tratarse de una red con topología en estrella (hasta entonces todas las redes Ethernet estándar tenían topología de bus).

[8] Esta fue la primera vez que apareció el guión en la denominación para separar la letra T de la E.

[9] Comprada mas tarde por Cisco.

[10] Comprada más tarde por Cisco.

[11] Los medios físicos 100BASE-TX y 100BASE-FX de Fast Ethernet derivan totalmente de FDDI. Los medios 100BASE-T4 y 100BASE-T2 (que apareció mas tarde) tienen una especificación propia del nivel físico.

[12] En efecto, actualmente multitud de fabricantes ofrecen toda la gama de productos Gigabit Ethernet (conmutadores, tarjetas de red, etc.) a precios razonables.

[13] Recordemos que el nivel físico de 100BASE-FX deriva completamente de FDDI.

[14] Esto se debería comprobar en cada caso consultando la documentación correspondiente.

[15] Técnicamente ese desacoplamiento se denomina diferente ‘apertura numérica’. En teoría la pérdida producida por una unión 62,5-50 es de 10log₁₀(62,5/50)² = 1,9 dB. Esto habría que añadirlo a la pérdida de 0,3-0,5 dB que tiene cualquier conexión normal. Con esta fórmula podemos calcular también la pérdida que tendría un acoplamiento multimodo-monomodo que sería de 10log₁₀(62,5/10)²=16 dB; esto haría que el enlace no funcionara en la mayoría de los casos.

[16] Actualmente el límite se encuentra en los enlaces ATM OC12, que transmiten a 622 Mbaudios.

[17] Sin embargo el BER considerado aceptable para fibra óptica es cien veces menor que en el caso de cable UTP, del orden de 10^-12.

[18] La optoelectrónica utilizada para fibra monomodo en 1000BASE-LX es la misma que en multimodo.

[19] En realidad los estándares no especifican si el código Manchester ha de ser así o al contrario. El convenio aquí descrito es el que se utiliza habitualmente en redes locales, aunque muchos libros lo describen al revés.

[20] Por esto en el estándar 802.3 para 10 Mb/s se especifican las atenuaciones máximas del cable a 5 y 10 MHz.

[21] Esto se debe a que en la Ethernet a 10 Mb/s la codificación se realiza en el controlador, no en el transceiver. Dicho de otro modo, el código Manchester ya está presente en el conector AUI, por lo que se ha de emplear en todos los medios físicos. En cambio a 100 Mb/s y 1000 Mb/s la codificación se realiza en el transceiver, con lo que para cada medio físico puede elegirse el código que mas convenga. Evidentemente los diseñadores de Fast y Gigabit Ethernet aprendieron la lección a partir de los errores cometidos por sus predecesores.

[22] Decimos que un código es mas ‘rico’ cuando la eficiencia (cociente bits-por-segundo/baudios) es mayor. Por ejemplo Manchester tiene una eficiencia de 0,5, mientras que el código 4B/5B (4 bits/5 baudios) tiene una eficiencia de 0,8.

[23] Podemos decir que el sincronismo 'odia' la monotonía.

[24] Por este motivo es interesante cuando se comprueba una instalación categoría 5 hacer medidas de los parámetros habtuales hasta 155 MHz, aun cuando las normativas solo requieran llegar a 100 MHz; si el cable tiene un comportamiento normal en ese rango de frecuencias no se presentarán normalmente problemas si se utiliza la red para enlaces ATM.

[25] No se utilizan los cuatro pares porque el protocolo CSMA/CD requiere, para poder detectar las colisiones, que haya un par asignado de manera permanente para cada sentido.

[26] El uso de los pares libres para telefonía o servicios de baja velocidad está permitido por la norma 802.3 también en el caso de 10BASE-T o 100BASE-TX. En cambio no está permitido utilizar los pares libres para una segunda conexión de datos (10BASE-T por ejemplo) ya que el crosstalk NEXT (interferencia entre señales paralelas viajando en el mismo sentido) que esto introduciría sería excesivo.

[27] En Fast Ethernet existen dos tipos de concentradores, los de clase I que tienen un retardo de 1,4 ms (equivalente a 140 bits) y los de clase II que tienen un retardo de 0,92ms (equivalente a 92 bits).

[28] En 1993 un investigador del centro de investigación de Xerox en Palo Alto detectó que muchas interfaces de red no respetaban en determinadas circunstancias el hueco entre tramas. Esta violación de la norma provocaba que se perdieran tramas, ya que algunas estaciones no estaban a la escucha, confiadas de que nadie transmitiría en ese momento. El problema causó un notable revuelo ya que entre los que incumplían la nroma se encontraban equipos muy habituales de fabricantes tales como AMD, Cisco, HP, Intel, Network General y Silicon Graphics. Como el fallo afectaba incluso a analizadores (HP y Network General) el problema solo podía detectarse con un osciloscopio.

[29] Definimos diámetro de la red como la distancia máxima entre dos estaciones.

[30] Este tiempo, también llamado t, es el que tarda la señal eléctrica en viajar de una estación a otra y corresponde a la mitad del tiempo de ida y vuelta 2t.

[31] Este es el valor de 2t máximo permitido en una red Ethernet a 100 Mb/s. En el caso de 10 Mb/s los intervalos serían de 51,2µs, y en el de 1000 Mb/s, debido a la extensión de portadora, serían de 4,096µs.

[32] Que para entonces es ya de 2¹⁰= 1024. Este límite se fijó en concordancia con el número máximo de estaciones de una red Ethernet; supuestamente si en una red con 1024 estaciones colisionaran todas a la vez sería posible satisfacerlas en diez intervalos. Realmente esto sólo ocurriría en el caso, extremadamente improbable, de que cada una de las 1024 estaciones eligiera un intervalo diferente. Hoy en día, dada la potencia de los ordenadores, el número de estaciones se mantiene generalmente muy por debajo del valor máximo.

[33] En realidad cuando se produce una colisión las estaciones Ethernet no paran inmediatamente de transmitir, sino que emiten entonces una señal especial de 32 bits denominada ‘señal de atasco’ (jam signal) para asegurarse de que cualquier estación que esté a la escucha sabrá que se ha producido una colisión y descartará lo recibido hasta ese momento. Al nivel de aproximación en que estamos trabajando podemos ignorar el efecto que tiene en el rendimiento la señal de atasco.

[34] Por ejemplo Carpenter [18] afirmaba en 1986: ‘Esta técnica [CSMA] funciona muy bien siempre y cuando la carga en la Ethernet no supere el 30%, aproximadamente’.

[35] El concepto de ‘cable’ debe interpretarse aquí como dominio de colisión, es decir uno o varios cables unidos por repetidores o concentradores. El concepto de longitud debe entenderse en términos del tiempo de ida y vuelta de la red.

[36] Durante la transmisión de los últimos seis bits (507 a 512) no hay riesgo de colisión, puesto que todas las estaciones ya se han percatado de la existencia del emisor.

[37] Si en vez de hablar en términos relativos lo hiciéramos en valores absolutos (por ejemplo 6 Mb/s de ocupación en los tres casos) la red de 100 Mb/s tendría muchas menos colisiones que la de 10, y la de 1000 aun menos, ya que con ese caudal esas redes estarían prácticamente vacías.

[38] NFS utiliza UDP en el nivel de transporte, por lo que la verificación de la información en este caso se implementa en el nivel de aplicación.

[39] La explicación es la siguiente: si 2t=621 bits entonces t=310 bits; si la segunda estación empieza a transmitir 3 µs (300 bits) después la colisión se producirá a 305 bits de la primera y a 5 bits de la segunda. Para que la colisión sea detectada la señal ha de volver a cada estación, por lo que los tiempos en que se detecta la colisión son el doble de los anteriores, o sea 610 bits para la primera y 10 bits para la segunda.

[40] Algo parecido ya ocurrió con Gigabit Ethernet, puesto que la frecuencia máxima de Fiber Channel es de 1,062 Gbaudios.

[41] La denominación Gigabyte proviene del hecho de ser la primera red estándar que consigue una tasa de transferencia superior a 1 GigaByte por segundo: 6,4 Gb/s = 800 MB/s. Como esta velocidad se da para cada sentido simultáneamente el total es 1,6 GB/s, superior a 1 GB/s.