CAPITULO 4: CONTROL DE CONGESTION Introducción El

CAPITULO 4: CONTROL DE CONGESTION
Introducción
El aspecto central del control de congestión y de la calidad de servicio es el tráfico de datos.
En el control de congestión se intenta evitar la congestión del tráfico. En la calidad de
servicio, se intenta crear un entorno apropiado para el tráfico.
Lección 1: TRÁFICO DE DATOS
Antes de hablar sobre el control de congestión y la calidad de servicio, se tratará el tráfico
de datos.
DESCRIPTORES DE TRÁFICO
Los descriptores de tráfico son valores cualitativos que representan un flujo de datos. La
figura muestra un flujo de tráfico con algunos de estos valores.
Tasa de datos media
La tasa de datos media es el número de bits enviados durante un periodo de tiempo,
dividido por el número de segundos de ese periodo. Se utiliza la siguiente ecuación:
Tasa de datos media = cantidad de datos / tiempo
La tasa de datos media es una característica muy útil del tráfico debido a que indica el
ancho de banda medio que necesita el tráfico.
Tasa de datos pico
La tasa de datos pico define la máxima tasa de datos del tráfico. En la figura es el valor
máximo del eje y. La tasa de datos pico es una medida muy importante debido a que
indica el ancho de banda pico que la red necesita para que el tráfico pase por ella sin
cambiar su flujo de datos.
Tamaño de la ráfaga máxima
Aunque la tasa de datos pico es un valor crítico para la red, puede normalmente ser
ignorada si la duración del valor pico es muy corto. Por ejemplo, si los datos fluyen a una
tasa de 1Mbps con un pico de datos repentino de 2 MBPS durante solo 1 ms, la red
probablemente podrá tratar la situación. Sin embargo, si la tasa de datos pico dura 60 ms,
puede que haya problemas en la red. El tamaño de la ráfaga máxima normalmente se
refiere a la duración máxima de tiempo en el que el tráfico se genera a la tasa pico.
Ancho de banda efectivo
El ancho de banda efectivo es el ancho de banda que la red necesita asignar al flujo de
tráfico. El ancho de banda efectivo es una función de tres valores: tasa de datos media,
tasa de datos pico y tamaño de la ráfaga máximo. El cálculo de este valor es muy complejo.
PERFILES DE TRÁFICO
Para el objetivo de este capítulo, un flujo de datos puede tener uno de los siguientes
perfiles de tráfico: tasa de bits constante, tasa de bit variable o tasa de bit a ráfagas.
Tasa de bits constante
Un modelo de tráfico con una tasa de bits constante (CBR) o tasa de datos fija, tiene una
tasa de datos que no cambia. En este tipo de flujo, la tasa de datos media y la tasa de
datos pico son iguales. El tamaño de la ráfaga máximo no es aplicable. Este tipo de tráfico
es muy sencillo de tratar para una red puesto que es predecible. La red conoce por
adelantado cuanto ancho de banda necesita asignar para este tipo de flujo.
Tasa de bits variable
En la categoría de tasa de bits variable (VBR), la tasa de datos cambia con el tiempo, siendo
los cambios suaves y no repentinos. En este tipo de flujo, la tasa de datos media y la tasa
de datos pico son diferentes. El tamaño de la ráfaga máxima tiene normalmente un valor
pequeño. Este tipo de tráfico es más difícil de gestionar que el tráfico con tasa de bits
constante, pero normalmente no necesita ser reajustado como se verá más tarde.
Datos a ráfagas
En la categoría de datos a ráfagas, la tasa de datos cambia de forma repentina en un
tiempo muy corto. Puede saltar de cero, por ejemplo, hasta 1 Mbps en unos pocos
microsegundos y viceversa. Puede también permanecer en este valor durante un largo
periodo. La tasa media de bits y la tasa pico son muy diferentes en este tipo de flujo. El
tamaño de la ráfaga máxima es significativo. Este es el tipo de tráfico más difícil de tratar
debido a que el perfil de tráfico es muy impredecible. Para manejar este tipo de tráfico, la
red normalmente necesita reajustarse, utilizando técnicas de ajuste, como se verá en breve.
El tráfico de datos a ráfaga es una de las principales causa de congestión en una red.
Lección 2: CONGESTIÓN
Un aspecto importante en una red de conmutación de paquetes es la congestión. La
congestión en una red puede ocurrir si la carga de la red (el número de paquetes enviados
a la red) es mayor que la capacidad de la red (el número de paquetes que una red puede
tratar). El control de congestión se refiere a los mecanismos y técnicas que permiten
controlar la congestión y mantener la carga por debajo de la capacidad.
Se puede preguntar por qué hay congestión en una red. La congestión en un sistema
que involucra espera. Por ejemplo, la congestión ocurre en una autopista debido a que
cualquier incidente en el flujo, como un accidente durante una hora punta, crea un
bloqueo.
La congestión en una red o interconexión de redes ocurre debido a que los routers y
conmutadores tienen colas –búferes que almacenan los paquetes antes y después de su
procesamiento. Un router, por ejemplo, tiene una cola de entrada y una cola de salida
para cada interfaz. Cuando un paquete llega a la interfaz de entrada, se llevan a cabo tres
etapas antes de su salida..
1. El paquete se coloca al final de la cola de entrada mientras espera a ser comprobado.
2. El módulo de procesamiento del router extrae el paquete de la cola de entrada cuando
alcanza el frente de la cola y utiliza su tabla de encaminamiento y la dirección de destino
para encontrar el camino.
3. El paquete se coloca en la cola de salida de la interfaz apropiada y espera su turno para
ser enviado.
Se necesita tener en cuenta dos aspectos. En primer lugar, si la tasa de llegada de
paquetes es mayor que la tasa de procesamiento de paquetes, las colas de entrada se
harán cada vez más largas. En segundo lugar, si la tasa de salida de paquetes es menor
que la tasa de procesamiento de los paquetes, las colas de salida se harán cada vez más
largas.
PRESTACIONES DE UNA RED
El control de congestión involucra dos factores que miden las prestaciones de una red: el
retardo y la productividad.
Retardo frente a carga
Observe que cuando la carga es mucho menor que la capacidad de la red, el retardo está
al mínimo. El retardo mínimo se compone del retardo de propagación y del retardo de
procesamiento, los cuales son insignificantes. Sin embargo, cuando la carga alcanza la
capacidad de la red, el retardo se incrementa bruscamente debido a que ahora se necesita
añadir el tiempo de espera en las colas (para todos los routers en el camino) al retardo
total. Observe que el retardo se hace infinito cuando la carga es mayor que la capacidad.
Si esto no es obvio, considere el tamaño de las colas cuando casi ningún paquete alcanza
el destino, o alcanza el destino con un retardo de infinito; las colas se hacen cada vez más
grandes. El retardo tiene un efecto negativo sobre la carga y consecuentemente sobre la
congestión. Cuando un paquete es retrasado, el origen no recibe confirmación y
retransmite el paquete, lo que empeora el retardo y la congestión.
Productividad frente a carga
La productividad se define como el número de bits que pasan a través de un punto en un
segundo. Se puede extender esa definición de bits a paquetes y de punto a red. Así se
puede definir la productividad en una red como el número de paquetes que pasan a
través de una red en una unidad de tiempo. Observe que cuando la carga está por
debajo de la capacidad de la red, la productividad se incrementa proporcionalmente con
la carga. Se espera que la productividad permanezca constante una vez que la carga
alcanza la capacidad, pero en su lugar la productividad se reduce repentinamente. La
razón se debe a los paquetes descartados por los routers. Cuando la carga excede a la
capacidad, las colas se llenan y los routers descartan algunos paquetes. El hecho de
descartar paquetes, sin embargo no reduce el número de paquetes en la red debido a
que las fuentes retransmiten los paquetes, utilizando mecanismos de temporización,
cuando los paquetes no alcanzan los destinos.
Lección 3: CONTROL DE CONGESTIÓN
El control de congestión se refiere a las técnicas y mecanismos que o previenen la
congestión, antes de que ocurra, o eliminan la congestión una vez que ha ocurrido. En
general, se pueden dividir los mecanismos de control de congestión en dos amplias
categorías: Control de congestión de bucle abierto (prevención) y control de congestión
de bucle cerrado (eliminación).
CONTROL DE CONGESTIÓN DE BUCLE ABIERTO
En el control de congestión de bucle abierto, las políticas se aplican para prevenir la
congestión antes de que ocurra. En estos mecanismos, el control de congestión es
manejado por el origen o por el destino. A continuación se muestra una breve lista delas
políticas que pueden prevenir la congestión.
Política de retransmisión
La retransmisión en algunas ocasiones es inevitable. Si el emisor cree que un paquete
enviado se ha perdido o se ha dañado, el paquete necesita ser retransmitido. La
retransmisión en general, puede incrementar la congestión en la red. Sin embargo, una
buena política de retransmisión puede prevenir la congestión. La política de retransmisión
y los temporizadores de retransmisión se deben diseñar para optimizar la eficiencia y al
mismo tiempo prevenir la congestión. Por ejemplo, la política de retransmisión utilizada
por TCP (explicada más tarde) se ha diseñado para prevenir o aliviar la congestión.
Política de la ventana
El tipo de ventana en el emisor puede también afectar a la congestión. La ventana de
repetición selectiva es mejor que la ventana. Adelante – atrás – N para el control de la
congestión. En la ventana Adelante – atrás – N, cuando vence el temporizador para un
paquete, se pueden reenviar varios paquetes, aunque algunos de ellos ya hayan llegado
al receptor. Esta duplicación puede empeorar la congestión. La ventana de repetición
selectiva, por otro lado, intenta evitar los paquetes concretos que se han perdido o
dañado.
Política de confirmación
La política de confirmación impuesta por el receptor puede también afectar a la
congestión. Si el receptor no confirma cada paquete que recibe, puede ralentizar al emisor
y ayudar a prevenir la congestión. Se han utilizado varios enfoques en este caso. Un
receptor puede enviar una confirmación sólo si tiene un paquete para enviar o vence un
temporizador especial. Un receptor puede decidir confirmar sólo N paquetes cada vez.
Se necesita conocer que las confirmaciones son también parte de la carga de la red. Enviar
menos confirmaciones reduce la carga en la red.
Política de descarte
Una buena política de descarte en los routers pueden prevenir la congestión y al mismo
tiempo puede no dañar la integridad dela transmisión. Por ejemplo, en la transmisión de
audio, si la política es descartar los paquetes menos sensibles cuando es probable que
ocurra la congestión, la calidad del sonido aún se mantiene y la congestión se previene o
alivia.
Política de admisión
Una política de admisión, que es un mecanismo de calidad de servicio, puede también
prevenir la congestión en redes de circuitos virtuales. Los conmutadores en un flujo
pueden comprobar primero los requisitos de recursos del flujo antes de admitirlo en la red.
Un router puede denegar el establecimiento de la conexión de un circuito virtual si hay
congestión en la red o si existe la posibilidad de congestión en un futuro.
CONTROL DE CONGESTIÓN DE BUCLE CERRADO
El mecanismo de control de congestión de bucle cerrado intenta aliviar la congestión una
vez que ésta ha ocurrido. Se han utilizado varios mecanismos en diferentes protocolos. A
continuación se describen algunos de ellos.
Presión hacia atrás
La técnica de presión hacia atrás se refiere a un mecanismo de control de congestión en
el que un nodo congestionado detiene la recepción de datos de un nodo o de los nodos
inmediatos en el flujo ascendente. Esto puede causar que el nodo o nodos situados en el
flujo ascendente se congestionen y a su vez, rechacen datos de su nodo o nodos situados
en el flujo ascendente, y así sucesivamente. La presión hacia atrás es un mecanismo de
control de congestión nodo a nodo que comienza con un nodo y se propaga en el
sentido opuesto del flujo de datos, hacia el origen. La técnica de la presión hacia atrás se
puede aplicar sólo a redes basadas en circuitos virtuales, en las que cada nodo conoce al
nodo situado en el flujo ascendente por el que llega el flujo de datos. La figura muestra
la idea de la presión hacia atrás.
El nodo III de la figura tiene más datos de entrada de los que puede manejar. Descarta
algunos paquetes de su búfer de entrada e informa al nodo II para que ralentice el envío.
El nodo II, a su vez, puede estar congestionado debido a la ralentización en la salida de
flujo de datos. Si el nodo II se congestiona, informa al nodo I para que ralentice el envío,
el cual a su vez puede congestionarse. Si es así, el nodo I informa al emisor de los datos
para que ralentice el envío. Esto alivia la congestión. Observe que la presión en el nodo
III se mueve hacia atrás, hasta el origen para eliminar la congestión.
Ninguna de las redes basadas en circuitos virtuales que se han estudiado en este libro
utiliza esta técnica. Fue, sin embargo, implementada en la primera red basada en circuitos
virtuales, X25. Esta técnica no se puede implementar en una red basada en datagrama,
debido a que este tipo de redes, un nodo (router) no tiene conocimiento del router
situado en el flujo ascendente.
Paquete de contención
Un paquete de contención es un paquete enviado por un nodo al origen para informarle
de la congestión. Observe la diferencia entre esta técnica y la anterior. En la presión hacia
atrás, la técnica se aplica de nodo a nodo, aunque eventualmente puede alcanzar a la
estación origen. En este método, la advertencia se realiza directamente desde el router,
que se encuentra congestionado, a la estación origen. Se ha visto un ejemplo de este tipo
de control en el protocolo ICMP. Cuando un router en Internet se congestiona con
diagramas IP, puede descartar algunos; pero informa al origen, utilizando un mensaje
ICMP de tipo source quench. El mensaje de advertencia va directamente ala estación
origen; los routers intermedios no realizan ninguna acción. La figura muestra la idea del
paquete de contención.
Señalización implícita
En la señalización implícita, no hay comunicación entre el nodo o nodos congestionados
y el origen. El origen adivina que hay congestión en algún punto de la red a través de
otros síntomas. Por ejemplo, cuando un origen envía paquetes y no hay confirmación
durante un cierto tiempo, puede asumir que la red está congestionada. El retardo en la
recepción de los mensajes de confirmación se puede interpretar como congestión en la
red; el origen podría ralentizarse. Se verá este tipo de señalización cuando se describa el
control de congestión de TCP más tarde en el capítulo.
Señalización explícita
El nodo que experimenta la congestión puede explícitamente enviar una señal al origen
o al destino. El método de señalización explícita, sin embargo, es diferente del método
que utiliza el paquete de contención. En el método del paquete de contención, se utiliza
un paquete diferente para este objetivo. En el método de señalización explícita, la señal
se incluye en los paquetes que transportan datos. La señalización explícita, como se verá
en el control de congestión de Frame Relay, puede ocurrir hacia delante o hacia atrás.
Señalización hacia atrás
Se puede activar un bit en un paquete que se mueve en el sentido contrario a la
congestión. Este bit puede advertir al emisor que hay congestión y que necesita ralentizar
su envío para evitar el descarte de paquetes.
Señalización hacia delante
Se puede activar un bit en un paquete que va en la dirección dela congestión. Este bit
puede advertir al destino de que hay congestión. El receptor en este caso puede utilizar
políticas, como ralentizar las confirmaciones, para aliviar la congestión.
Lección 4: CONTROL DE CONGESTIÓN EN TCP
Ahora veremos el control de congestión que utiliza TCP para evitar o aliviar la congestión
de la red.
Ventana de congestión
Anteriormente se habló sobre el control de flujo y se intentaron describir soluciones a
emplear cuando el receptor se sobrecarga con datos. Se dijo que el tamaño de la ventana
del emisor viene determinada por el espacio disponible en el búfer del receptor ( rwnd).
En otras palabras, se asume que sólo el receptor puede dictar al emisor el tamaño de la
ventana del emisor. Se ignoró a otra entidad – la red. Si la red no puede entregar los
datos tan rápidamente como son originados por el emisor, debe decir al emisor que se
ralentice. En otras palabras, además del receptor, la red es una segunda entidad que
determina el tamaño de la ventana del emisor.
Hoy en día, el tamaño de la ventana del emisor viene determinada sólo por el receptor
pero también por la congestión de la red.
El emisor tiene dos elementos de información: el tamaño de la ventana anunciado por el
receptor y el tamaño de la ventana de congestión (cwnd). El tamaño real de la ventana
es el mínimo de estos dos valores:
Tamaño real de la ventana = mínimo (rwnd, cwnd)
Se va a mostrar brevemente como se determina el tamaño de la ventana de congestión.
Política de congestión
La política general de TCP para tratar la congestión se basa en tres fases: comenzar lento,
evitación de la congestión y detección de la congestión. En la fase de comienzo lento, el
emisor comienza con una tasa de transmisión muy baja, pero la incrementa rápidamente
hasta alcanzar un umbral. Cuando se alcanza el umbral, la tasa de datos se reduce para
evitar la congestión. Finalmente si se detecta congestión, el emisor vuelve a tras a la fase
de comienzo lento o a la fase de evitación de la congestión dependiendo de cómo se
detecte la congestión.
Comienzo lento: incremento exponencial
Uno delos algoritmos utilizados por TCP en el control de congestión es el denominado
comienzo = 2comienza con un tamaño de segmento máximo (MSS). El tamaño MSS se
determina en la fase de establecimiento de la conexión utilizando una opción del mismo
nombre. El tamaño de la ventana se incrementa en un MSS cada vez que se recibe una
confirmación. Como su nombre implica, la ventana comienza lentamente, pero crece
exponencialmente. Para mostrar la idea, observe la Figura 8. Observe que se han utilizado
tres simplificaciones para que el ejemplo sea más sencillo. Se han utilizado números de
segmentos en lugar de números de bytes. Se ha asumido que el valor rwnd es mucho
más grande que el valor de cwnd, de forma que el tamaño de la ventana del emisor
siempre iguale a cwnd. Se ha asumido que cada segmento se confirma de forma
individual.
El emisor comienza con un valor para cwnd = 1 MSS. Esto significa que el emisor puede
enviar sólo un segmento. Después de recibir la confirmación para el segmento 1, el
tamaño de la ventana de congestión se incrementa en 1, lo que significa que el valor de
cwnd ahora es 2. Ahora se pueden enviar dos segmentos. Cuando se recibe la
confirmación, el tamaño de la ventana se incrementa en 1 MSS. Cuando se han
confirmado todos los segmentos el valor de cwnd es 8.
Si se ve el tamaño de cwnd en términos de rondas (confirmación de todos los segmentos
de una ventana), se encuentra que la tasa es exponencial como se indica a continuación:
Comienzo
cwnd = 1
Después de la ronda 1
cwnd = 21 = 2
Después de la ronda 2
cwnd = 22 = 4
cwnd = 23 = 8
Es necesario mencionar que si hay un ACK retrasado, el incremento en el tamaño de la
ventana es menor que la potencia de 2.
Después de la ronda 3
El comienzo lento no puede continuar indefinidamente. Debe haber un umbral para
parar esta fase. El emisor mantiene la pista de una variable denominada sstresh (umbral
de comienzo lento). Cuando el tamaño de la ventana en bytes alcanza este umbral, el
comienzo lento para y se pasa a la siguiente fase. En la mayoría de las implementaciones,
el valor de sstresh es 65.536 bytes.
En el algoritmo de comienzo lento, el tamaño de la ventana de congestión se incrementa
exponencialmente hasta que alcanza un umbral.
Evitación de la congestión: incremento aditivo
Si se comienza con el algoritmo de comienzo lento, el tamaño de la ventana de congestión
se incrementa exponencialmente. Para evitar la congestión antes de que ocurra, uno
debe parar este crecimiento exponencial. TCP define otro algoritmo denominado
evitación de la congestión, que lleva a cabo un incremento aditivo en lugar de uno
exponencial. Cuando el tamaño de la ventana de congestión alcanza el umbral del
comienzo lento, se para la fase de comienzo lento y se pasa a la fase aditiva. En este
algoritmo, cada vez que la ventana completa es confirmada (una ronda), se incrementa el
tamaño de la ventana en 1. Para mostrar la idea, se va a aplicar este algoritmo al mismo
escenario anterior, aunque como se verá el algoritmo de evitación de la congestión
normalmente comienza con un tamaño de la ventana mucho mayor que 1. La figura 9
muestra la idea.
En ese caso, una vez que el emisor ha recibido las confirmaciones para un tamaño de
ventana completo, el tamaño de la ventana se incrementa en 1 segmento.
Si se observa el tamaño de cwnd en términos de rondas, se ve que la tasa es aditiva como
se muestra a continuación:
Comienzo
cwnd = 1
Después de la ronda 1
cwnd = 1 + 1 = 2
Después de la ronda 2
cwnd = 2 + 1 = 3
Después de la ronda 3
cwnd = 3 + 1 = 4
En el algoritmo de evitación de la congestión, el tamaño de la ventana de congestión se
incrementa aditivamente hasta que se detecta la congestión.
Detección de la congestión: reducción multiplicativa
Si ocurre congestión, el tamaño de la ventana de congestión debe reducirse. La única
forma que tiene el emisor para adivinar que ha ocurrido congestión es la necesidad de
retransmitir un segmento. Sin embargo, la retransmisión puede ocurrir en dos casos:
cuando vence un temporizador o cuando se han recibido tres mensajes ACK. En ambos
casos, el tamaño del umbral se reduce a la mitad, una reducción multiplicativa. La mayor
parte de las implementaciones de TCP tiene dos reacciones:
1. Si vence un temporizador, hay una alta probabilidad de congestión; un segmento
probablemente ha sido descartado en la red y no hay noticias sobre los segmentos
enviados.
En este caso, TCP reacciona de una forma agresiva:
a. Fija el valor del umbral a la mitad del tamaño actual.
b. Fija el valor de cwnd al tamaño del segmento.
c. Comienza de nuevo con la fase de comienzo lento.
1.
Si se han recibido tres ACK hay una probabilidad baja de que haya una congestión;
se puede haber perdido un segmento, pero algunos segmentos ya han llegado
puesto que se han recibido tres ACK. Esto se conoce como transmisión rápida y
recuperación rápida. En este caso, TCP tiene una reacción menos agresiva:
a. Fija el valor del umbral a la mitad del tamaño de la ventana actual.
b. Fija el valor de cwnd al valor del umbral (algunas implementaciones suman tres
segmentos al umbral).
c. Comienza con la fase de evitación de la congestión.
Una implementación reacciona a la detección de la congestión con uno de los siguientes
modos:
 Si la detección se debe al vencimiento de un temporizador, comienza de nuevo la fase
de comienzo lento.
 Si la detección se debe a tres ACK, comienza una nueva fase de evitación de la
congestión.
Lección 5: CONTROL DE CONGESTIÓN EN FRAME RELAY
La congestión en una red Frame Relay reduce la productividad e incrementa el retardo.
Una alta productividad y un bajo retardo son los principales objetivos del protocolo Frame
Relay. Frame Relay no tiene control de flujo. Además, Frame Relay permite al usuario
transmitir datos a ráfagas. Esto significa que una red Frame Relay tiene una posibilidad
real de congestionarse, por lo que requiere control de congestión.
Evitación de la congestión
Para evitar la congestión, Frame Relay utiliza dos bits de la trama para avisar de forma
explícita al origen y al destino de la presencia de congestión.
Notificación de congestión explícita hacia atrás (BECN)
El bit de notificación de congestión explícita hacia atrás (BECN) avisa al emisor de que
existe una situación de congestión en la red. La pregunta inmediata es cómo se puede
hacer esto si las tramas parten del emisor. Existen dos métodos: el conmutador puede
utilizar las tramas de respuesta del receptor (modo full-dúplex) o sino, el conmutador
puede utilizar una conexión predefinida (DLCI=1023) para enviar tramas especiales para
este propósito específico. El emisor puede responder a este aviso simplemente reduciendo
la velocidad de transmisión. La figura muestra el empleo del BECN.
Notificación de congestión explícita hacia adelante (FECN)
El bit de notificación de congestión explícita hacia adelante (FECN) se utiliza para avisar al
receptor de que existe congestión en la red. Podría parecer que el receptor no puede
hacer nada para aliviar la congestión. Sin embargo, el protocolo Frame Relay asume que
el emisor y el receptor se están comunicando utilizando algún tipo de control de flujo en
un nivel superior. Por ejemplo, si existe un mecanismo de confirmación en este nivel
superior, el receptor puede retrasar la confirmación, forzando de esta forma al emisor a
ralentizarse. La figura muestra el uso de FECN. Cuando dos puntos finales están
comunicándose utilizando una red Frame Relay, existen cuatro situaciones relacionadas
con la congestión. La figura muestra estas cuatro situaciones y los valores de FECN y
BECN.
CAPITULO 5: CALIDAD DE SERVICIO
Introducción
Se puede definir informalmente la calidad de servicio(QoS) como algo que un flujo busca
alcanzar.
Calidad de servicio
Dado que distintas aplicaciones como, por ejemplo, teléfono, correo electrónico y
videovigilancia, pueden utilizar la misma red IP, es necesario controlar el uso compartido
de los recursos de la red para satisfacer los requisitos de cada servicio. Una solución es
hacer que los enrutadores y los conmutadores de red funcionen de maneras distintas para
cada tipo de servicio (voz, datos y vídeo) del tráfico de la red. Al utilizar la Calidad de servicio
(QoS), distintas aplicaciones de red pueden coexistir en la misma red sin consumir cada
una el ancho de banda de las otras.
El término Calidad de servicio hace referencia a una cantidad de tecnologías, como DSCP
(Differentiated Service Codepoint), que pueden identificar el tipo de datos que contiene
un paquete y dividir los paquetes en clases de tráfico para priorizar su reenvío. Las ventajas
principales de una red sensible a la QoS son la priorización del tráfico para permitir que
flujos importantes se gestionen antes que flujos con menor prioridad, y una mayor
fiabilidad de la red, ya que se controla la cantidad de ancho de banda que puede utilizar
cada aplicación y, por lo tanto, la competencia entre aplicaciones en el uso del ancho de
banda. El tráfico PTZ, que a menudo se considera crítico y requiere una latencia baja, es
un caso típico en el que la QoS puede garantizar respuestas rápidas a solicitudes de
movimiento. El requisito previo para utilizar QoS en una red de vídeo es que todos los
conmutadores, enrutadores y productos de vídeo en red admitan QoS.
Red ordinaria (sin QoS). En este ejemplo, PC1 está reproduciendo dos secuencias de
vídeo de las cámaras 1 y 2. Cada cámara transmite a 2,5 Mbit/s. De repente, PC2 inicia
una transferencia de archivos desde PC3. En este escenario, la transferencia de archivos
intentará utilizar la capacidad total de 10 Mbit/s entre los enrutadores 1 y 2, mientras
que las secuencias de vídeo intentarán mantener su total de 5 Mbit/s. Así, ya no se
puede garantizar la cantidad de ancho de banda destinada al sistema de vigilancia y
probablemente se reducirá la frecuencia de imagen de vídeo. En el peor de los casos,
el tráfico del FTP consumirá todo el ancho de banda disponible.
Red con QoS. En este escenario, se ha configurado el enrutador 1 para dedicar hasta
5 Mbit/s de los 10 disponibles a la transmisión de vídeo. El tráfico del FTP puede utilizar
un máximo de 2 Mbit/s, y HTTP, junto con el resto del tráfico, pueden utilizar un máximo
de 3Mbit/s. Con esta división, las transmisiones de vídeo siempre tendrán disponible el
ancho de banda que necesitan. Las transferencias de archivos se consideran menos
importantes y, por lo tanto, obtienen menor ancho de banda; sin embargo, aún
quedará ancho de banda disponible para la navegación web y el resto del tráfico. Hay
que tener en cuenta que estos valores máximos sólo se aplican en caso de congestión
en la red. El ancho de banda disponible que no se use se podrá utilizar por cualquier
tipo de tráfico.
Tradicionalmente, se han atribuido cuatro características a un flujo: fiabilidad, retardo,
deriva o Jitter y ancho de banda.
Fiabilidad
La fiabilidad es una característica que necesita un flujo. La falta de fiabilidad significa
PERDER UN paquete o una confirmación, lo que provoca la retransmisión. Sin embargo,
la sensibilidad de los programas de aplicación a la fiabilidad no es la misma. Por ejemplo,
es más importante que el correo electrónico, la transferencia de archivos y el acceso a
Internet sean más fiables que la telefonía.
Retardo
El retardo de fuente a destino es otra característica de un flujo. De nuevo las aplicaciones
pueden tolerar el retardo en diferente grado. En este caso, la telefonía, la
videoconferencia y el inicio de sesión remoto necesitan un mínimo retardo, mientras que
en la transferencia de un archivo o el correo electrónico es menos importante.
Deriva o jitter
La deriva en la variación de retardo que sufren los paquetes que pertenecer a un mismo
flujo. Por ejemplo, si cuatro paquetes salen en los instantes 0, 1,2 y 3 y llegan en los
instantes 20, 21, 22 y 23, todos tienen el mismo retardo, 20 unidades de tiempo. Por otro
lado, si los paquetes anteriores llegan en los instantes 21, 23, 21 y 28, todos tienen retardos
diferentes de 21, 22, 19 y 24.
Para aplicaciones como el audio o el sonido, el primer caso es completamente aceptable;
el segundo no. Para estas aplicaciones, no importa si los paquetes llegan con un retardo
pequeño o grande, siempre que el retado sea el mismo para todos los paquetes.
La deriva se define como la variación en el retardo de un paquete. Una deriva alta significa
que la diferencia entre los retardos de grandes; una deriva baja significa que la variación
es pequeña.
Ancho de banda
Diferentes aplicaciones necesitan diferentes anchos de banda. En la transmisión de vídeo
se necesita enviar millones de bits por segundo para representar una pantalla de color
mientras que el número total de bits en un correo electrónico pueden no llegar al millón.
Clase de flujos
De acuerdo a las características de un flujo, se pueden clasificar los flujos en grupos,
teniendo cada grupo niveles de características similares. Esta clasificación no es formal o
universal, algunos protocolos como ATM han definido clases, como se verá más tarde.
Lección 1: TÉCNICAS PARA MEJORAR LA CALIDAD DE SERVICIO
En esta sección, se describe algunas técnicas que se pueden utilizar para mejorar la calidad
de servicio. Se van para describir brevemente cuatro métodos comunes: la planificación,
el ajuste de tráfico, el control de admisión y la reserva de recursos.
PLANIFICACIÓN
Los paquetes de diferentes flujos llegan a un conmutador o router para su
procesamiento. Una buena técnica de planificación trata los flujos diferentes de manera
apropiada. Se han enseñado varias técnicas de planificación para mejorar la calidad de
servicio. Se van a describir tres de ellas: la planificación FIFO, la planificación basada en
prioridades y la planificación con pesos.
Planificación FIFO
En la planificación FIFO (first-in-first-out), los paquete esperan en un búfer (cola) hasta que
el (router o conmutador) está listo para procesarlos. Si la tasa de llegada es mayor que la
tasa de procesamiento media, la cola se llenaran y los nuevos paquetes serán descartados.
Una planificación FIFO es familiar para aquellos que tienen que esperar en una parada de
autobús. La figura siguiente muestra una visión conceptual de la planificación FIFO.
Planificación basada en prioridades
En la planificación basada en prioridades, los paquetes tienen asignada un nivel de
prioridad. Cada nivel de prioridad tiene su propia cola. Los paquetes de la cola de mayor
prioridad se procesan primero. Los paquetes de la cola de menor prioridad se procesan
los últimos. Observe que el sistema no para de servir una cola, hasta que esta no esté vacía.
La figura siguiente muestra una planificación que utiliza dos niveles de prioridad (por
simplicidad. Una planificación basada en prioridades puede mejorar los QoS mejor que la
planificación FIFO debido a que el tráfico con mayor prioridad, como el multimedia puede
alcanzar el destino con menos retardo. Sin embargo, hay un posible problema. Si hay un
flujo continuo, con una prioridad muy alta, los paquetes con prioridades más bajas nunca
tendrán la oportunidad de ser procesados. Esta es una condición denominada inanición.
Planificación con pesos
Una técnica mejor de planificación es la planificación con pesos. En esta técnica, los
paquetes tienen asignadas clases diferentes y se admiten en colas distintas. Las colas, sin
embargo, llevan asignadas unos pesos de acuerdo al nivel de prioridad de las colas. Las
colas de mayor prioridad tienen pesos mayores. El sistema procesa los paquetes en cada
cola de manera cíclica con el número de paquetes seleccionado para cada cola de
acuerdo al peso correspondiente. Por ejemplo, si los pesos son 3, 2, 1, se procesarán tres
paquetes en la primera cola, dos en la segunda y uno en la tercera. Si el sistema no impone
prioridades a las clases, todos los presos todos los pesos son iguales. La figura siguiente
muestra la técnica con tres clases.
AJUSTE DE TRÁFICO
El ajuste de tráfico es un mecanismo para controlar la cantidad y tasa de tráfico enviado a
la red. Existen dos técnicas de ajuste de tráfico: algoritmo del cubo de escape y algoritmo
del cubo con testigo.
Algoritmo del cubo con escape
Si un cubo tiene un pequeño agujero su parte inferior, el agua deja el cubo a una
velocidad constante mientras haya agua en el cubo. La velocidad con la que el agua deja
el cubo no depende de la velocidad con la que el agua se introduce en él. La velocidad
de entrada puede variar, pero la velocidad de salida permanece constante. De forma
similar, en una red, una técnica denominada cubo con escape, puede suavizar la salida
de tráfico a ráfagas. Los bloques a ráfagas se almacenan en un cubo y se envían a una
tasa media. La figura siguiente muestra un cubo con escape y sus efectos.
La figura, se asume que la red ha comprometido un ancho de banda de 3 Mbps para una
estación. El uso de un cubo con escape ajusta el tráfico de entrada para que se cumpla
este compromiso. En la figura siguiente la estación envía una ráfaga de datos a una tasa
de 12 Mbps durante 2 s, con un total de 24 Mbits. La estación está en silencio durante 5 s
y envía datos a una taza de 2 Mbps durante 3 s, con un total de 6 Mbits de datos.
En total, la estación enviado 30 Mbps de datos en 10 s. Sin un cubo con escape, la ráfaga
inicial puede afectar a la red y consumir más ancho de banda del que está fijado para esta
estación. Se puede también ver que el cubo con escape previene la congestión.
La figura siguiente muestra una sencilla implementación de un cubo con escape. Una
cola FIFO almacena los paquetes. Si el tráfico consta de paquetes de tamaño fijo (por
ejemplo celdas de una red ATM), el proceso elimina un número fijo de paquetes de la cola
en cada pulso de reloj. Si el tráfico consta de paquetes de longitud variable, la tasa de
salida fija debe basarse en el número de bits o bytes.
A continuación se muestra un algoritmo para paquetes de longitud variable:
1. Inicializar un contador a n en cada pulso de reloj.
2. Si n es mayor que el tamaño del paquete, enviar el paquete y restar al contador el
tamaño del paquete. Repetir esta etapa hasta que n sea más pequeño que el tamaño del
paquete.
3. Poner el contador a cero y volver al paso 1.
Un algoritmo de cubo con escape ajusta el tráfico de ráfagas en un tráfico con tasa fija
promediando la tasa de datos. Puede perder paquetes si el cubo está lleno.
Cubo de testigos
El cubo con escape es muy restrictivo. No da crédito a una estación inactiva. Por ejemplo,
si una estación no envía datos durante un cierto tiempo, su cubo está vacío. Ahora sí la
estación tiene datos a ráfagas, el cubo con escape sólo permite una tasa media. El tiempo
en el que la estación está inactiva no se tiene en cuenta. Por otro lado, cubo de testigos,
permite a la estación inactivas acumular crédito para que el futuro en forma de testigos.
En cada pulso de reloj, el sistema envía n testigos al cubo. El sistema elimina un testigo
para cada celda (o byte) de datos enviados. Por ejemplo, si n es 100 y la estación está
inactiva durante 100 pulsos de reloj, el cubo tendrá 10.000 testigos. Ahora la estación
puede consumir todos estos testigos en un pulso de reloj con 10.000 celdas o la estación
tarda 1000 pulsos con 10 celdas por pulsos. En otras palabras, la estación puede enviar
datos a ráfagas siempre que el cubo no esté vacío. En la figura siguiente se muestra la
idea.
El cubo de testigos se puede implementar de forma sencilla con un contador. El testigo se
inicializa a cero. Cada vez que se añade un testigo se incremente el contador en uno. Cada
vez que se envía una unidad de datos, al contador se le resta 1. Cuando el contador se
hace cero, la estación no puede enviar datos.
El cubo de testigos permite tráfico a ráfagas a una tasa máxima regulada
Combinación del cubo de testigos y del cubo con escape
Las dos técnicas anteriores se pueden combinar para dar crédito a una estación inactiva
al mismo tiempo que se regula el tráfico. El cubo con escape se aplica después de cubo
de testigos; la tasa del cubo con escape necesita ser mayor que la tasa de testigos
descartados en el cubo de testigos.
RESERVA DE RECURSOS
Un flujo de datos necesita recursos como un búfer, ancho de banda, tiempo de CPU, etc.
La calidad del servicio se mejora si estos recursos están reservados por adelantado. En esta
sección se describe un modelo de calidad de servicio denominado servicios integrados,
que depende de la reserva de recursos para mejorar la calidad del servicio.
CONTROL DE ADMISIÓN
El control de admisión se refiere al mecanismo utilizado por un router, o un conmutador
para aceptar o rechazar un flujo de acuerdo a los parámetros predefinidos denominados
especificaciones del flujo. Antes de que un router acepte un flujo para su procesamiento,
comprueba las especificaciones del flujo para ver si su capacidad (en términos de ancho
de banda, tamaño de búfer, velocidad de la CPU, etc.) y sus compromisos anteriores para
otro flujos pueden tratar el nuevo flujo.
Lección 2: SERVICIOS INTEGRADOS
De acuerdo a los temas tratados se han diseñado dos modelos para mejorar la calidad de
servicio de Internet: los servicios integrados y los servicios diferenciados. Ambos modelos
enfatizan el uso de la calidad de servicio en el nivel de red (IP), aunque el modelo también
se puede utilizar en otros niveles de enlace de datos. En esta sección se tratan los servicios
integrados y en la sección siguiente se describen los servicios diferenciados.
IP fue originalmente diseñado con una entrega lo mejor posible. Esto significa que cada
usuario recibe al mismo nivel de servicio. Este tipo de entrega no garantiza el mínimo de
servicios, como ancho de banda, a las aplicaciones que transmite audio o vídeo en tiempo
real. Si una aplicación que necesita de forma accidental un ancho de banda extra, puede
ir en detrimento de otras aplicaciones, dando lugar a situaciones de congestión.
Los servicios integrados, conocidas también como IntServ, constituyen un modelo de QoS
basada en flujo, lo que significa que un usuario necesita crear un flujo, un tipo de circuito
virtual, desde el origen hasta el destino e informar a todos los routers de sus requisitos de
recursos.
Los servicios integrados constituyen un modelo de QoS basada en flujo diseñado para IP.
SEÑALIZACIÓN
El lector puede recordar que IP es un protocolo no orientado a conexión, basado en
datagramas que utiliza conmutación de paquetes. ¿Cómo se puede implementar un
modelo basado en flujo sobre un protocolo no orientado a conexión? La solución es un
protocolo de señalización que ejecuta sobre IP que at ofrece el mecanismo de señalización
por hacer la reserva. Este protocolo se denomina Protocolo de reservas de recursos (RVSP)
y se describirá en breve.
ESPECIFICACIÓN DEL FLUJO
Cuando un origen hace una reserva, necesita definir una especificación de
flujo. Una especificación de flujo tiene dos partes: Rspec (especificación del recurso) y Tspec
(especificación de tráfico). Rspec define los recursos que necesita reservar el flujo (búfer,
ancho de banda, etc.) Tspec define las características del tráfico del flujo.
ADMISIÓN
Cuando un router recibe la especificación del flujo de una aplicación, decide admitir o
denegar el servicio. La decisión se basa en los compromisos previos del router y la
disponibilidad actual de recursos.
CLASES DE SERVICIOS
Se han definido dos clases de servicios para los servicios integrados: servicios garantizados
y servicios controlados por la carga.
Clase de servicios garantizados
Este tipo de servicio está diseñado para tráfico de tiempo real que necesita un retardo
extremo a extremo mínimo garantizado. El retardo extremo a extremo es la suma de los
retardos de todos los routers, retardo de propagación en el medio y el mecanismo de
configuración. Sólo el primero, las sumas de los retardos en los routers, puede ser
garantizado por el router. Este tipo de servicio garantiza que los paquetes llegarán dentro
de un cierto tiempo y que no serán descartados si el tráfico del flujo se encuentra dentro
del límite de Tspec. Se puede decir que los servicios garantizados son servicios
cuantitativos, en los que la cantidad de retardo extremo a extremo y la tasa de datos deben
ser definidas por la aplicación.
Clase de servicio controlado por la carga
Este tipo de servicio está diseñado para aplicaciones que pueden aceptar algunos
retardos, pero que son sensibles a la sobrecarga de la red y al peligro por la pérdida de
paquetes. Buenos ejemplos de este tipo de aplicaciones son la transferencia de archivos,
el correo electrónico y el acceso a Internet. El servicio controlado por la carga es un servicio
lo cualitativo en que la aplicación solicitar la posibilidad de bajar pérdida o no pérdida de
paquetes.
RVSP
En el modelo de servicios integrados, un programa de aplicación necesita una reserva de
recursos. Como se vio en la descripción del modelo IntServ, la reserva de recursos se
realizada para un flujo. Esto significa que si se quiere utilizar el modelo IntServ en el nivel
IP, se necesita crear un flujo, un tipo de red basada en circuitos virtuales, fuera del nivel IP,
que fue originalmente diseñado como una red de conmutación de paquetes basada en
datagramas. Una red basada en circuitos virtuales necesita un sistema de señalización para
configurar el circuito virtual antes de que el tráfico de datos pueda comenzar. El protocolo
de reserva de recursos (RSVP) es un protocolo de señalización que ayudar protocolo IP a
crear un flujo y consecuentemente a hacer una reserva de recursos. Antes de describir el
protocolo RVSP, es necesario mencionar que es un protocolo independiente y separado
del modelo de servicios integrados. Se puede utilizar en otros modelos en el futuro.
Árboles de multienvío
RVSP es diferente de otros sistemas de señalización que se han visto antes en que es un
sistema de señalización diseñado para multienvío. Sin embargo, el protocolo RVSP también
se puede utilizar para envío unidestino debido a que éste es un caso especial de multienvío
con sólo un miembro en el grupo de multienvío. La razón de este diseño permitir al
protocolo RVSP ofrecer una reserva de recursos para todo tipo de tráfico de incluyendo
multimedia que con frecuencia utiliza multienvío.
Reserva basada en el receptor
En el protocolo RVSP, los receptores, no el emisor, hacen la reserva. Esta estrategia coincide
con otros protocolos de multienvío. Por ejemplo, en uno de los protocolos de
encaminamiento de multienvío, los receptores, no el emisor, hacen la decisión de unirse o
dejar el grupo de multienvío.
Mensajes del protocolo RVSP
RVSP tiene varios días tipos de mensajes. Sin embargo, se va a escribir sólo dos de ellos:
Path y Resv.
Mensajes path. Recuerde que los receptores en un flujo hacen la reserva en el protocolo
RVSP. Sin embargo, los receptores no saben el camino atravesado por los paquetes antes
de que se haga la reserva. Es necesario el camino para hacer la reserva. Para solucionar
este problema, el protocolo RVSP utiliza mensajes path. Un mensaje path viaja desde el
emisor y alcanza a todos los receptores en el camino multienvío. Un mensaje path,
almacena la información necesaria para los receptores. Un mensaje path se envía en un
entorno de envío multidestino; un nuevo mensaje se crea cuando el camino diverge. La
figura siguiente muestra mensajes de tipo path.
Mensajes resv. Una vez que el receptor ha recibido un mensaje path, envía un mensaje
resv. El mensaje Resv viaja hacia el emisor (en el flujo ascendente) y hace la reserva de
recursos en los routers que soportan RVSP. Si un router en el camino no soporta RVSP
encamina el paquete de acuerdo a los métodos de mejor entrega posible. La figura
siguiente muestra los mensajes resv.
Mezcla de reservas
En el protocolo RVSP, los recursos no se reservan para cada receptor en un flujo; las
reservas se mezclan. En la figura siguiente, Rc3 solicita un ancho de banda de
2 Mbps mientras que Rc2 solicita un ancho de banda de 1 Mbps. El router R3, necesita
hacer una reserva de ancho de banda, mezcla las dos solicitudes. La reserva se hace para
2 Mbps, mayor de los dos, debido a que una reserva de 2 Mbps puede tratar ambas
solicitudes. La misma situación es cierta para R2. El lector puede preguntarse por qué Rc2
y Rc3, ambos pertenecientes a un mismo flujo, los visitan diferentes cantidades de ancho
de banda. La respuesta de que, en un entorno multimedia, diferentes receptores pueden
tratar diferentes grados de calidad. Por ejemplo, Rc2 puede ser capaz de recibir vídeo sólo
a 1 Mbps (baja calidad) mientras que Rc3 puede ser capaz de recibir vídeo a 2 Mbps
(mayor calidad).
Estilos de reserva
Cuando hay más de un flujo, el router necesita hacer la reserva para acomodar todos ellos.
El protocolo RVSP define tres tipos de estilos de reserva.
1. Estilo de filtro will card. En este estilo, el router crea una única reserva para todos los
emisores. La reserva se basa en la petición mayor. Este tipo de estilo que se utiliza cuando
los flujos de diferentes emisores no ocurren al mismo tiempo.
2. Estilo de filtro fijo. En este estilo, el router crea una reserva distinta para cada flujo. Esto
significa que si hay n flujos, se hace n diferentes reservas. Este tipo de estilo se utiliza cuando
hay una alta probabilidad de que los flujos de diferentes emisores no ocurran al mismo
tiempo.
3. Estilo explícito compartido. En este estilo, el router crea una única reserva que es
compartida por todos los flujos.
Estado de tipo soft
La información de reserva (estado) almacenada en cada nodo para un flujo necesita ser
refrescada periódicamente. Esto se conoce como un estado de tipo soft comparado con
un estado de tipo hard utilizado en otros protocolos basados en circuitos virtuales como
ATM o Frame Relay, donde la información sobre el flujo se mantiene hasta que se borra.
El intervalo por defecto es actualmente de 30 s.
PROBLEMAS CON LOS SERVICIOS INTEGRADOS
Hay al menos dos problemas con los servicios Integrados que pueden evitar su completa
implementación en Internet: la escalabilidad y la limitación del tipo de servicio.
Escalabilidad
El modelo de servicios integrados requiere que cada router mantenga información para
cada flujo. Como Internet está creciendo día a día, esto es un serio problema.
Limitación del tipo de servicio
El modelo de servicios integrados proporciona sólo dos tipos de servicios, garantizado y
controlado por la carga. Aquellos que se oponen a este modelo argumentan que las
aplicaciones pueden necesitar más de estos dos tipos de servicios.
Lección 3: SERVICIOS DIFERENCIADOS
Los servicios diferenciados (DS o DiffServ) fueron introducidos por el IETF (Internet
Engering Task Force) para solucionar los problemas de los servicios integrados. Se hicieron
dos cambios fundamentales:
1. El principal procesamiento fue movido del núcleo de la red al extremo de la
red. Esto soluciona el problema de escalabilidad. Los encaminadores no tienen que
almacenar la información sobre los flujos. Las aplicaciones, o estaciones, definen el tipo de
servicio que ellos necesitan cada vez que envía un paquete.
2. El servicio por flujo se ha cambiado a un servicio por clase. El encaminador encamina el
paquete de acuerdo a la clase de servicio definido en el paquete, no en el flujo. Esto
soluciona el problema de limitación del tipo de servicio. Se pueden definir diferentes tipos
de clases de acuerdo a las necesidades de las aplicaciones.
Los
servicios
diseñada para IP.
diferenciados
un
modelo
QoS
basada
en
clases
CAMPO DS
En DifServ, cada paquete contiene un campo denominado campo DS. El valor de este
campo es fijado en los extremos de la red por las estaciones o por el primer encaminador
designado como encaminador frontera. El IETF propone sustituir el campo TOS (tipo de
servicio) existente en IPv4 o el campo de clase IPv6 por el campo DS, como se muestra en
la figura siguiente.
El campo DS contiene dos subcampos: DSCP y CU. El campo de DSCP (punto de código
de servicios diferenciados) es un subcampo de 6 bits que define el funcionamiento por
salto (PHB). El campo CU en un campo de 2 bits que no se utiliza actualmente.
Funcionamiento por salto
El modelo DifServ define funcionamientos por salto (PHB) para cada nodo que recibe un
paquete. Hasta ahora se han definido tres PDH: DE PHB, EF PHB y AF PHB.
DE PHB. Este funcionamiento (PHB por defecto) es el mismo que la entrega mejor posible,
que es compatible con el campo TOS.
EF PHB. Este funcionamiento (PHB de reenvío rápido) ofrece los siguientes servicios:
 Pérdida baja.
 Latencia baja.
 Ancho de banda asegurado.
Esto es lo mismo que tener una conexión virtual entre el origen y el destino.
AF PHB. Este funcionamiento (PHB de reenvío asegurado) entrega el paquete con una
alta seguridad siempre que el tráfico no exceda el perfil de tráfico del nodo. Los usuarios
de la red necesitan ser conscientes de que algunos paquetes pueden ser descartados.
Acondicionador de tráfico
Para implementar DifServ, el nodo DS utiliza acondicionadores de tráfico como
contadores, marcadores, adaptadores y descartadores, como se muestra en la figura
siguiente.
Contador. El contador comprueba si el flujo de entrada coincide con el perfil de tráfico
negociado.
El
contador
también
envía
este
resultado
a
otros
componentes. El contador puede utilizar varias herramientas como un cubo de testigos
para comprobar el perfil.
Marcador. Un marcador puede remarcar un paquete si está utilizando la entrega mejor
posible (DSCP: 000000) o marcar por debajo un paquete de acuerdo a la información
recibida por el contador. El marcado por debajo (marca a un nivel de servicio más bajo)
ocurre si el flujo no coincide con el perfil. Un marcador no hace un marcado hacia arriba
(eleva el nivel de servicio) de un paquete.
Adaptador. Un adaptador utiliza la información recibida del contador para adaptar o
ajustar el tráfico si no cumple con el perfil negociado.
Descartador. Un descartador, que funciona como un adaptador sin búfer, descarta los
paquetes si el flujo viola de forma severa el perfil negociado.
Lección 4: QoS EN FRAME RELAY
Se utilizan cuatro atributos diferentes para controlar el tráfico en Frame Relay: tasa de
acceso, tamaño de la ráfaga comprometido Bc, tasa de información comprometida y
tamaño de la ráfaga en exceso. Estos atributos se fijan durante la negociación entre el
usuario y la red. Para conexiones PVC, se negocian sólo una vez; para conexiones SVC se
negocian en cada conexión durante la fase de establecimiento de la conexión. La figura
siguiente muestra las relaciones entre estas cuatro medidas.
Velocidad de acceso
Para cada conexión se define una velocidad de acceso (en bits/segundo). La velocidad de
acceso realmente depende del ancho de banda del canal que conecta al usuario con la
red. El usuario no puede nunca exceder esta velocidad. Por ejemplo, si el usuario se
conecta a una red Frame Relay mediante una línea T-1, la velocidad de acceso es de 1,544
Mbps y ésta no se puede sobrepasar.
Tamaño de la ráfaga comprometido
Para
cada
conexión, Frame Relay
define un
tamaño de
ráfaga
comprometido (Bc). Este es el número máximo de Bits durante un periodo
predefinido de tiempo que la red se compromete a transferir sin descartar ninguna trama
o activar el bit DE. Por ejemplo si se compromete un valor para Bc de
400 kbits durante un periodo de cuatro segundos, el usuario puede enviar hasta 400 kbits
durante un u intervalo de cuatro segundos sin preocuparse de que se pierdan tramas.
Observe que no se trata de una velocidad definida para cada segundo. Es una medida
acumulativa. El usuario puede enviar 300 kbits durante el primer segundo, ningún dato
durante los dos siguientes segundos y finalmente 100 kbits durante el cuarto segundo.
Velocidad de información comprometida
La velocidad de información comprometida (CIR) es similar al concepto de tamaño de
ráfaga comprometido excepto que define una velocidad media de bits por segundo. Si el
usuario mantiene esta velocidad, la red se compromete entregar la trama. Sin embargo
debido a que es una medida media, un usuario puede enviar en algunos instantes datos
a una velocidad mayor al CIR. Siempre que se cumpla la media para el período pre
definido, las tramas serán entregadas.
El número acumulativo de bits enviados durante el periodo predefinido no debería
exceder de Bc Observe que el CIR no es una medida independiente; se puede calcular
utilizando la siguiente fórmula:
CIR =Bc/T bps
Por ejemplo, si el Bc es de cinco kbits en un período de cinco segundos, el CIR es 5000/5
= 1kbps.
Tamaño de la ráfaga en exceso
Para cada conexión, Frame Relay define un tamaño de la ráfaga en
exceso (Bc). Este valor es el número máximo de bits, que pueden exceder a Bc que un
usuario puede enviar durante un periodo predefinido de tiempo. La red se compromete
a transferir estos bits si no hay congestión. Observe que en este caso existe menos
compromiso que en el caso de Bc. El compromiso de la red es condicional.
Tasa del usuario
La figura siguiente muestra cómo puede un usuario enviar datos a ráfagas. Si un usuario
nunca excede Bc, la red se compromete a transferir las tramas sin
descartarlas. Si el usuario excede el valor de Bc, en menos que Be (es decir, el número total
de bits es menor que Bc + Be), la red se compromete a transferir todas las tramas si no hay
congestión. Si existe congestión, algunas tramas serán descartadas. El primer conmutador
que recibe las tramas del usuario tiene un contador y fija el bit DE para aquellas tramas
que exceden el valor Bc. El resto de conmutadores descartarán esta trama si hay
congestión. Observe que un usuario que necesita enviar datos más rápido puede exceder
el nivel Bc. Siempre que el nivel no supere Bc + Be, existe la posibilidad de que las tramas
alcancen el destino sin ser descartadas. Recuerde, sin embargo, que el momento en el que
el usuario supere Bc + Be, todas las tramas enviadas después son descartadas por el primer
conmutador.
Lección 5: QoS EN ATM
La QoS en ATM se basa en las clases, los atributos relacionados con el usuario y los
atributos relacionados con la red.
Clases
El foro ATM define cuatro clases de servicios: CBR, VBR, ABR y UBR.
CBR. La clase de tasa de bits constante (CBR) se ha diseñado para los clientes que necesitan
servicios de vídeo y audio de tiempo real. El servicio es similar al ofrecido por una línea
dedicada como la línea T.
VBR. La clase de tasa de bits variable (VBR) se divide en dos subclases: tiempo real (VBRNRT). VBR-RT se diseñó para los usuarios que necesitan servicio de tiempo real (como
transmisión de audio y vídeo) y utilizan técnicas de compresión para crear una tasa de bits
variable. VBR-NRT se diseñó para aquellos usuarios que no necesitan servicios de tiempo
real de utilizan técnica de compresión para crear una tasa de bits variable.
ABR. La clase de tasa de bits disponible (ABR) entrega las celdas a la mínima tasa. Si hay
más capacidad de red, la tasa mínima puede incrementarse. ABR es particularmente
adecuado para aplicaciones que utilizan por su naturaleza ráfagas.
UBR. La clase de tasa de bits no especificada (UBR) es un servicio de mejor entrega posible
que no garantiza nada.
La figura 31 muestra la relación entre las diferentes clases y la capacidad total de la red.
ATRIBUTOS RELACIONADOS CON EL USUARIO
ATM define dos conjuntos de atributos. Los atributos relacionados con el usuario son
aquellos que definen la velocidad con la que el usuario quiere enviar los
datos. Estos atributos se negocian cuando se realiza el contrato entre un usuario y una
red. A continuación se describen algunos atributos relacionados con el usuario.
SCR. La tasa de celdas sostenida (SCR) es la tasa de celdas media en un intervalo de tiempo
largo. La tasa de celdas real puede ser mayor o menor, pero la media debería ser igual o
menor que la SCR.
PCR. La tasa de celdas pico (PCR) define la máxima tasa de celdas del emisor. La tasa de
celdas del usuario puede en algunas ocasiones alcanzar este pico, mientras que se
mantenga la SCR
MCR. La tasa de celdas mínima (MCR) define la tasa de celdas mínima aceptable para el
emisor. Por ejemplo, si la MCR 50.000, la red debe garantizar que el emisor puede enviar
al menos 50.000 celdas por segundo.
CVDT. La tolerancia en el retardo a la variación de celdas (CVDT) es una medida de la
variación en los instantes de transmisión de celdas. Por ejemplo, si la CVDT es de 5 ns,
entonces la diferencia entre los retardos mínimos y máximos en la entrega de celdas no
debería exceder los 5 ns.
ATRIBUTOS RELACIONADOS CON LA RED
Los atributos relacionados con la red son los que definen las características de la red. A
continuación se definen algunos de estos atributos:
CLR. La tasa de celdas perdidas (CLR) define la fracción de celdas perdidas (o entregadas
demasiado
tarde
y
que
se
consideran
pérdidas)
durante
la
transmisión. Por ejemplo, si el emisor envía 100 celdas y una se pierde, la CLR es:
CLR = 1/100 = 10-2
CTD. El retardo en la transferencia de celdas (CTD) es el tiempo medio necesario para que
una celda viaje del origen al destino. También se consideran como atributos al CTD
máximo y el CTD mínimo.
CVD. La variación en el retardo de celdas (CVD) es la diferencia entre el CTD máximo y el
CTD mínimo.
CER. La tasa de celdas con error (CER) define la fracción de celdas entregadas con error.