No
hay duda de que Frame Relay pasa información mas rápidamente
que X.25. Esto supondrá que hay un menor trabajo para el
procesador. El tiempo que tardar para completar este trabajo debe
ser menor, y los retraso de la tramas reducidos. Pero hay dos
posibles preguntas a este respuesta
- ¿Cuánto es la reducción del porcentaje?
- ¿Cual es tiempo actual de retraso
reducido?
Aunque
parece haber una pequeña diferencia entre ambas cuestiones, la
diferencia es vital para entender la implicaciones de las
acciones de la redes Frame Relay. Algunos vendedores indican que
el retraso de transito reducido esta entre un 50% y un 75%. Esto
puede ser muy significativo hasta que te das cuenta que la
reducción representa el paso de 3 a 2 milisegundos. Los paquetes
conmutados esta tan optimizada que un usuario no debería esperar
retrasos as significativos más de 5 milisegundos por paquete.
Muchos de los paquetes conmutados proporcionan un retraso en un
radio entre 3 y 6 milisegundos, pero incluso, la reducción de
los retrasos 2 milisegundos ¿no representa un mayor mejora?
Puede ser quiza un ventaja para un único conmutador, pero un
factor muy importante para el usuario es el retraso extremo a
extremo en la red
Hay
tres factores que contribuyen a este retraso de extremo a
extremos
- Ejecución del procedimiento: este
es el tiempo que tarda un conmutador de
paquetes o tramas en recibir un paquete o trama desde un
enlace de llegada, e interceptar la información
apropiada, y pasar el mismo paquete o trama al enlace de
salida. Este tiempo normalmente es medido
desde la llegada del ultimo bit del paquete o trama al
conmutador, hasta que es transmitido el primer bit del
paquete o de la trama. Este retaso no se ve afectado por
la rapidez de la transmisión de las líneas de llegada o
salida, o por el tamaño de la trama, en caso de
conmutadores bien diseñado.
- Retraso en la transmisión:
Este es el tiempo que tarda el paquete o trama en
transitar en un enlace. Es medido desde la
salida del primer bit desde del nodo de transmisión,
hasta la recepción del ultimo bit en el nodo de recepción.
Este tiempo es proporcional a la longitud del paquete, a
la velocidad de transmisión del enlace y a la longitud
del enlace. Sin embargo, el retraso introducido por la
longitud de la línea es normalmente ignorado
- Retaso en Cola:
El encolado ocurre porque un único paquete o trama puede
cruzar el enlace en un momento determinado y otro paquete
esta listo para ser retransmitido cuando el primero esta
siendo transmitido. La probabilidad de que
esto ocurra y la longitud del la cola, dependen de la
utilización del enlace, a mayor utilización, mayor cola.
Para un uso eficiente de la red, hay que tener siempre
ciertos niveles de encolado, la falta de una cola muestra
que la línea esta disponible, pero que esto no es
eficiente.
Los principios generales del diseño indican
que para que las operaciones en los enlaces sean económicamente
viables se requiere que haya siempre al menos una trama o
paquete esperando por la transmisión en el enlace. Esto
produce un retaso de la cola para cada trama o paquete de
entre uno dos periodos de retaso de transmisión de un
trama o paquete en la cola.
Veamos
un ejemplo. Asumiendo que el tamaño total de la trama es de 1024
bytes y la conexión es de 64 kbps cada parte, la tabla siguiente
representa el retaso dentro la red de conmutación de paquetes y
dentro de la red de Frame Relay mostrada en la figura asumiendo
los retrasos típico de procesado de 5 y 2 milisegundos
respectivamente.
La
primera tabla muestra que los retrasos en la red para ambos métodos
son virtualmente idénticos. El retraso en la conmutación de
paquetes representa únicamente un 1,5 %, del retraso total
dentro de la red de conmutación de paquetes. Dentro de la red
Frame Relay, el retraso de transito a través de los conmutadores
representa un 0.6% del retraso total Incluso reduciendo el
retraso del conmutador a 0 tenemos un efecto despreciable sobre
el retraso de transito.
Entonces
¿dónde está el cuello de botella de la red.? La
tabla siguiente muestra que cerca del 60% del retraso total es
debido al retraso de la transmisión. Este retraso es una función
de la velocidad de las líneas y del tamaño del trama. Si
alteramos la velocidad de la línea (a 2 Mbps) se alteran los
resultados. La tabla siguiente detalla el retraso de
transito cuando se incrementa la velocidad de la red de enlace de
64 Kbps a 2 Mbps.
Reduciendo
el tamaño del paquete también afecta a los resultados,
sin embargo existen otras implicaciones al hacer esto. La reducción
del tamaño del paquete dentro de la red de conmutación
,probablemente, causa a los conmutadores de paquete el
fragmentado de los datos de llegada y surecombinación posterior
en el punto de destino. Esto es posible de por la
existencia de un numero de secuencia. Sin embargo,
esto no es posible en Frame Relay. En ambos casos
el afectara al retraso de conmutación en los puntos de fuente y
destino.
En
la tabla se muestra que con el incremento de la
velocidad de la líneas, el retraso total de la red se reduce (
representando una reducción del 95 % aproximadamente).
Por lo encontramos que hay todavía una diferencia entre los
retrasos totales en conmutación de paquetes y los retrasos
dentro de la red de Frame Relay
En los paquete individuales el retaso de procesamiento en los
conmutadores representa un 27% del total del retaso para una red
de conmutación de paquetes. Dentro de la red de Frame Relay este
mismo retraso representa un 13% del retraso total de la red, la
diferencia como podemos ver es grande.
Como
conclusión podemos observar que se puede proporcionar
una reducción significativa en los retrasos de la red al
incrementar la velocidad de las líneas. El cambio a tecnologías
mas rápidas en los conmutadores no tiene ningún efecto si se
realiza sobre líneas de baja velocidad. Reducir el tamaño de la
trama también tiene una aportación significativa para la
reducción del retraso, pero esto también tiene un efecto sobre
el incremento de carga de paquetes dentro de la red.
Otro
factor que afecta el retraso esta relacionado con el
mecanismo de control de flujo. Las redes
de conmutación de paquetes contiene un control de flujo,
que consiste en que el usuario únicamente puede generar un
numero determinado de paquetes dentro de la red antes de parar y
esperar por su reconocimiento Este mecanismo de rotación de
ventana tiene un máximo de 127 paquetes, Si el usuario ha
mandado esta ventana entera de paquete, no puede mandar más
paquetes hasta que reciba el reconocimiento de alguno de los
paquetes. Este proceso es conocido como ventana
deslizante. Una red ideal estaría diseñada de tal
manera que el usuario no tendría que suspender nunca el envío
de datos a causa del falta de reconocimientos a paquetes
anteriores. En Frame Relay no hay concepto de
reconocimiento o ventanas, y permite a los usuarios mandar tantos
datos como ellos requieran.
En
resumen , Frame Relay no debería ser considerado como un
protocolo únicamente conveniente para el incremento del numero
de acciones en la red y el decremento de los retrasos. Frame
Relay tiene, además, ciertos atractivos sobre la bajas
velocidades de X.25, pero cuando los comparamos con X.25 a altas
velocidades , la ventaja de la velocidad de Frame Relay no es tan
clara.
Frame Relay puede únicamente proporcionar ventajas
sobre las redes de conmutación de paquetes si la velocidad del
enlace dentro de la red son incrementados enormemente y su los
procesos en los conmutadores son mejorados,
proporcionando tiempo de sub-milisegundos.
La
discusión asume que Frame Relay ha sido implementado como una
arquitectura modificada de la conmutación de paquetes. Esto es
cierto en la mayoría de la implementaciones iniciales de Frame
Relay. Sin embargo, sin que la comprobación de
errores sea obligatoria para la características del protocolo,
es posible implementar un conmutador en el cual no se tenga que
esperar a que la trama sea completamente recibida antes de mandar
otra.
Esto tiene como resultado que el retraso del conmutador pueda ser
ignorado. Una vez que la cabecera de la tramas sea
leída, la trama puede ser dirigida directamente a el buffer de
salida. Sin embargo el retraso de cola debe ser considerado,
porque muchas de las redes se construyen basándose en unos
objetivos previamente diseñados donde la encolamiento es un
elemento esencial.
2.- Desventajas
Una
característica existente en la conmutación de paquetes es una técnica
que es actualmente muy considera por los usuarios, el
proceso de garantizar el envío de datos.
Frame Relay no ofrece esto, no se establece ninguna orden acerca
como lastramas deben pasar a través de la red. La única
recomendación de Frame Relay es que las tramas deben llegar en
el mismo orden en que fueron mandadas. Para garantizar la
correcta secuenciación de la tramas.
Este
mecanismo de secuenciación no debe confundirse con el proceso de
garantizar la integridad de los datos. Las redes de
conmutación de paquetes, generalmente garantizan que los datos
que son mandados en la red son recibidos por el usuario en el
misma secuencia y sin errores. Mediante un número
de comprobación secuencia de paquetes y su validación, una
comprobación de error en los paquetes y de las capacidades de
buffering.
En cambio Frame Relay no hay garantiza la entrega de
los datos. Los requisitos para que los datos sean entregados en
la misma secuencia en que fueron recibidos esta relacionado únicamente
con que los datos no sean perdidos dentro de la red.
La
intención del protocolo de Frame Relay es operar a altas
velocidades, en circuitos digitales de excepcionalmente buena
calidad, donde los errores en los bits son extremadamente raros.
Sin embargo, mientras que el numero de errores introducido por el
uso de esa infraestructura es pequeño, la red podría perder
muchas tramas simplemente por que es incapaz de entregarlas a
causa de la congestión.
Consideremos
el ejemplo de la figura anterior en el que una trama pasa a través
de distinto conmutadores de trama en su camino por la red desde
un origen a un destino. Cada salto de trama representa el paso
entre dos conmutadores. En nuestro ejemplo la trama para ir de
extremo a extremo da 5 saltos de trama.
Consideremos
el ejemplo anterior asumiendo que la trama es perdida en el
primer salto ( o por congestión en el primer conmutador), los
saltos de tramas 2 al 6 representan la petición de retransmisión
y los saltos del 7 al 11 representan la retransmisión. Por
tantos para una trama única pasando a través de la red se
requieren al menos 11 saltos de procesamiento, mas del doble de
los requeridos si no ocurre error.
Si
una trama es perdida en el ultimo salto, 14 saltos de
procesamiento son necesarios para recuperarla, como se muestra en
la figura, los saltos del 1 al 5 para el camino inicial, 6 al 10
para la petición de retransmisión, y los saltos del 11 al 15
para la retransmisión , esto representa mas de tres veces el
procesamiento requerido para el paso de una trama simple.
Esta
metodología de recuperación es la practica estándar para redes
diseñadas bajo los principios de Frame Relay y puede significar
una carga adicional para la red. Los ejemplos solo muestran la
perdida de una trama y su recuperación. Si hay gran cantidad de
tramas perdidas, la cantidad de trafico que la red recibe podrá
expandirse significativamente. Todo este trafico adicional es un
componente mas de los problemas de congestión que probablemente
causen el descarte de mas tramas .
Esta
es la razón por la cual algunos vendedores eligen la entrega
garantizada como característica añadida Frame Relay. Esta es una
combinación de Frame Relay y de la conmutación de paquetes en
la cual no hay necesariamente un protocolo de control de errores
de extremo a extremo dentro de la red, pero hay asegurada una
integridad de los datos y su recuperación en el nivel de enlace.
Tomando
el ejemplo previo, mostramos los principios básicos sobre el
siguiente ejemplo:. La trama errónea o perdida es ahora
recuperada localmente en el salto 2 solicitando su retransmisión,
el salto 3 representa la retransmisión, y los salto 4 al 7 la
transmisión de la trama.
En este caso un único salto adicional de la trama es requerido
para solventar la situación anómala. Naturalmente, la
integridad del enlace requiere procesamientos adicionales dentro
de la trama, pero este proceso no hay tantos intentos como X.25,
y por consiguiente obtiene un retraso situado entre el retaso de
Frame Relay y X.25.