Diferencia entre revisiones de «Calidad de servicio»

De Wikipedia, la enciclopedia libre
Contenido eliminado Contenido añadido
Isha (discusión · contribs.)
m Revertidos los cambios de 201.244.224.60 a la última edición de Gustronico
Línea 68: Línea 68:
# Soporte a calidad de servicio con prioridades y parametrizada.
# Soporte a calidad de servicio con prioridades y parametrizada.
# Basado, en la medida de lo posible, en soluciones estándares.
# Basado, en la medida de lo posible, en soluciones estándares.
Y TODOS LOS Q COPIARON ESTO SON UNOS GRANDISIMOS INBESILES


== Enlaces externos ==
== Enlaces externos ==

Revisión del 03:40 18 may 2009

QoS o Calidad de Servicio (Quality of Service, en inglés) son las tecnologías que garantizan la transmisión de cierta cantidad de datos en un tiempo dado (throughput). Calidad de servicio es la capacidad de dar un buen servicio. Es especialmente importante para ciertas aplicaciones tales como la transmisión de video o voz.

QoS en ATM

Una de las grandes ventajas de ATM (Asynchronous Transfer Mode – Modo de Transferencia Asíncrona) respecto de técnicas como el Frame Relay y Fast Ethernet es que admite niveles de QoS. Esto permite que los proveedores de servicios ATM garanticen a sus clientes que el retardo de extremo a extremo no excederá un nivel específico de tiempo o que garantizarán un ancho de banda específico para un servicio. Esto es posible marcando los paquetes que provengan de una Dirección IP determinada de los nodos conectados a un gateway (como por ejemplo la IP de un teléfono IP, según la puerta del router, etc.). Además, en los servicios satelitales da una nueva perspectiva en la utilización del ancho de banda, dando prioridades a las aplicaciones de extremo a extremo con una serie de reglas.

Una red IP está basada en el envío de paquetes de datos. Estos paquetes de datos tienen una cabecera que contiene información sobre el resto del paquete. Existe una parte del paquete que se llama ToS (Type of Service), en realidad pensada para llevar banderas o marcas. Lo que se puede hacer para darle prioridad a un paquete sobre el resto es marcar una de esas banderas (flags).

Para ello, el equipo que genera el paquete, por ejemplo un Gateway de Voz sobre IP, coloca una de esas banderas en un estado determinado. Los dispositivos por donde pasa ese paquete después de ser transmitido deben tener la capacidad para poder discriminar los paquetes para darle prioridad sobre los que no fueron marcados o los que se marcaron con una prioridad menor a los anteriores. De esta manera podemos generar prioridades altas a paquetes que requieren una cierta calidad de envío, como por ejemplo la voz o el video en tiempo real, y menores al resto.

QoS en escenarios inalámbricos

El entorno inalámbrico es muy hostil para medidas de Calidad de Servicio debido a su variabilidad con el tiempo, ya que puede mostrar una calidad nula en un cierto instante de tiempo. Esto implica que satisfacer la QoS resulta imposible para el 100% de los casos, lo que representa un serio desafío para la implementación de restricciones de máximo retardo y máxima varianza en el retardo (jitter) en sistemas inalámbricos.

Los sistemas de comunicaciones ya estandarizados con restricciones QoS de retardo y jitter en entornos inalámbricos (Ej. GSM y UMTS) sólo pueden garantizar los requisitos para un porcentaje (<100%) de los casos. Esto implica un “Outage” en el servicio, generando las cortes de llamadas y/o los mensajes de “red ocupada”. Por otro lado, algunas aplicaciones de datos (Ej. WiFi) no requieren de restricciones de máximo retardo y jitter, por lo que su transmisión sólo necesita de la calidad media del canal, evitando la existencia del Outage.

Soluciones para la calidad de servicio

El concepto de QoS ha sido definido dentro del proyecto europeo Medea+ PlaNetS, proporcionando un término común para la evaluación de las prestaciones de las comunicaciones en red, donde coexisten aplicaciones sin requisitos de retardo con otras aplicaciones con estrictas restricciones de máximo retardo y jitter. Dentro de PlaNetS, cuatro diferentes clases de aplicaciones han sido definidas, donde cada clase se distingue por sus propios valores de máximo retardo y jitter. La figura (1) muestra estas clases:

  1. Conversación: caracterizada por la más alta prioridad y los requerimientos de menor retardo y jitter.
  2. Flujo de datos (streaming).
  3. Servicios Interactivos.
  4. Aplicaciones secundarias: la más baja prioridad y mayor permisividad de retardo y jitter.


Los beneficios de la solución PlaNetS se resumen en:

  1. La posibilidad de pre-calcular el máximo retardo y jitter de la comunicación; y para cada una de las clases de aplicaciones.
  2. La solución propuesta es implementada con un simple scheduler que conoce la longitud de las colas de paquetes.
  3. La conformidad de los nodos de la comunicación es fácilmente comprobable.
  4. Una mayor QoS, tanto para el sistema como para el usuario final.
  5. La posibilidad de obtener esquemas prácticos de control de acceso (CAC en inglés).

Figura 1: Las cuatro diferentes clases de servicios en Medea+ PlaNetS

Calidad de servicio utilizando UPnP

UPnP es una tecnología desarrollada por el UPnP Forum que permite a los dispositivos en una red formar comunidades y compartir servicios. Cada dispositivo se ve como colección de uno o más dispositivos y servicios empotrados no necesitando establecer ninguna conexión preliminar o persistente para comunicarse con otro dispositivo. Existe un punto de control que descubre los dispositivos y sincroniza su interacción. Esta tecnología se usa sobre todo en el entorno multimedia, pudiéndola utilizar en dispositivos comerciales como la XBOX 360 (compartir archivos multimedia entre la videoconsola y el ordenador), la generación de móviles N de Nokia, etc.

Dentro del UPnP Forum se trabaja en la especificación de arquitecturas de calidad de servicio, y considerando la calidad de servicio local, es decir dentro de la red local. La segunda versión de la especificación de la arquitectura de calidad de servicio UPnP se ha publicado Quality of Service v2.0, Octubre 2006., donde la especificación no define ningún tipo de dispositivo, sino un Framework de UPnP QoS formado básicamente por tres distintos servicios. Estos servicios por lo tanto van a ser ofrecidos por otros dispositivos UPnP. Los tres servicios son:

  1. QosDevice
  2. QosPolicyHolder
  3. QosManager

La relación entre estos servicios puede verse en la figura (2) en la que se muestra un diagrama con la arquitectura UPnP QoS.

Figura 2: La arquitectura UPnP QoS

En la figura se aprecia que un punto de control es el que inicia la comunicación (por ejemplo, puede ser un punto de control multimedia). Este punto de control tiene información del contenido a transmitir, origen y destino de la transmisión, así como de la especificación del tráfico. Con esta información, accede al gestor de QoS (QosManager), que a su vez actúa como punto de control para la arquitectura QoS. El QosManager consulta al QosPolicyHolder para establecer las políticas para el tráfico (básicamente para establecer la prioridad de ese flujo de tráfico).

El QosManager calcula además los puntos intermedios en la ruta desde el origen al destino del flujo, y con la información de la política, configura los QosDevices que hay en dicha ruta. En función de los dispositivos QosDevices, o bien ellos mismos o bien la pasarela pueden realizar control de admisión de flujos. Estas interacciones entre los distintos componentes de la arquitectura se reflejan en la figura (3).

Figura 3: Las interacciones de la arquitectura

Soluciones para la calidad de servicio

El proyecto PlaNetS amplía las arquitecturas de calidad de servicio actuales en redes locales para proporcionar calidad de servicio extremo a extremo. Por lo tanto el objetivo es que desde los propios dispositivos locales que tiene el usuario hasta la entrada/salida del entorno residencial se guarda el esquema de QoS UPnP.

Los objetivos concretos son:

  1. Diseño de un mecanismo de gestión de QoS extremo a extremo, potencialmente desde un dispositivo multimedia en una red local a otro en otra red local, incluyendo la configuración de la QoS en las pasarelas, red de acceso y red core.
  2. Flexibilidad en el soporte de distintas tecnologías de red y dispositivos perifericos.
  3. Desarrollo de un modelo de datos flexible que permita la integración de la gestión de la calidad de servicio en sistemas heterogéneos, y que tenga en cuenta distintos aspectos que influyen en la calidad de un servicio.
  4. Soporte a calidad de servicio con prioridades y parametrizada.
  5. Basado, en la medida de lo posible, en soluciones estándares.

Enlaces externos