Requisitos de QoS para VoIP

CCNA Voice
Calidad de Servicio
Contenido
Definición de QoS
1
5
Requisitos de QoS para VoIP
Ancho de Banda
2
6
Requisitos de QoS para tráfico de datos
Latencia o Retardo
3
7
AutoQoS
Pérdida de Paquetes
4
8
Configurar AutoQoS
@ 2012 Ibitec S.L. Todos los derechos reservados.
2
DEFINICIÓN DE QOS
@ 2012 Ibitec S.L. Todos los derechos reservados.
3
Definición de QoS

Definición de QoS:



“La capacidad de la red para proporcionar un mejor servicio, o servicios
especiales, a un conjunto de usuarios y aplicaciones, a expensas de otros
usuarios y aplicaciones.”
El tráfico de voz y video es muy sensible al retardo, la pérdida de
paquetes y la variación en el retardo (jitter).
Efectos de estos problemas:

audio entrecortado, sonidos que faltan, eco, o pausas excesivamente largas en
la conversación, que causan sobreimposición de conversaciones, o la
interrupción de la persona que habla por otra.

La configuración de QoS ofrece AB garantizado, reduce la latencia
y el jitter para el tráfico prioritario, como VoIP.
 Las áreas donde aplicar QoS son:
 Ancho de banda
 Retardo o latencia (incluyendo la variación del retardo o jitter)
 Pérdida de paquetes
@ 2012 Ibitec S.L. Todos los derechos reservados.
4
ANCHO DE BANDA
@ 2012 Ibitec S.L. Todos los derechos reservados.
5
Ancho de Banda


Una llamada VoIP sigue un camino de extremo a extremo. Este
camino puede cruzar una variedad de enlaces LAN y WAN. El
enlace más lento es el que determina el AB disponible para todo el
camino, y a veces se crea un cuello de botella por la congestión
que genera.
Soluciones para la congestión:


Aumentar el AB: aumentar el ancho de banda es caro, y no siempre necesario
si se aplica QoS.
Colas: QoS utiliza estrategias de colas avanzadas para clasificar los diferentes
tipos de tráfico, y organizar las clases en colas para darles prioridad.




Weighted Fair Queuing (WFQ).
Class Based Weighted Fair Queuing (CBWFQ).
Low-Latency Queuing (LLQ).
Compresión.



Compresión del payload.
Compresión del enlace.
Compresión de cabecera.
@ 2012 Ibitec S.L. Todos los derechos reservados.
6
AB – Colas: Weighted Fair Queuing (WFQ)







Método automatizado que provee una asignación justa de AB para
todo el tráfico de la red.
WFQ ordena el tráfico en flujos, usando una serie de parámetros.
Una vez distinguidos los flujos, el router determina cuáles son de
uso intensivo o sensibles al retardo, priorizándolos y asegurando
que los sensibles al retardo son empujados al principio de la cola.
WFQ se adapta a las condiciones cambiantes del tráfico de red.
La carga para el procesador en los equipos de enrutamiento, hace
de este método poco escalable, al requerir recursos adicionales en
la clasificación y manipulación dinámica de las colas.
No necesita configuración, está habilitado por defecto en todos los
enlaces de velocidades ≤ T1.
No es un método adecuado para VoIP ya que no garantiza AB para
el tráfico de voz, puesto que asigna el AB proporcional al tamaño
de los flujos.
@ 2012 Ibitec S.L. Todos los derechos reservados.
7
AB – Colas: Class Based Weighted Fair Queuing (CBWFQ)

Limitaciones de WFQ:





CBWFQ permite la creación de clases definidas por el usuario para un
mayor control sobre las colas de tráfico y asignación del AB.
CBWFQ garantiza una determinada tasa de transmisión para cierto tipo de
tráfico.
Las clases pueden ser determinadas según protocolo ACL, valor DSCP, o
interfaz de entrada. Cada clase posee una cola separada, y todos los
paquetes que cumplen el criterio definido para una clase son asignados a
dicha cola.
Una vez que establecidos los criterios para las clases, es posible
determinar cómo los paquetes pertenecientes a dicha clase serán
gestionados.



Su rendimiento disminuye a medida que el tráfico por enlace aumenta y se colapsa debido
a la cantidad de flujos a analizar.
Si una clase no utiliza su porción de ancho de banda, otras pueden hacerlo.
Se puede configurar el AB y el límite de paquetes máximos para cada clase.
CBWFQ no es una opción adecuada para VoIP ya que no tiene Priority
Queuing.
@ 2012 Ibitec S.L. Todos los derechos reservados.
8
AB – Colas: Low-Latency Queuing (LLQ)




LLQ es CBWFQ con PQ (Priority Queuing).
Método recomendado para VoIP y Telefonía IP, que también
trabaja adecuadamente con tráfico de videoconferencias.
LLQ consta de colas de prioridad personalizadas, basadas en
clases de tráfico, con una cola de prioridad que tiene preferencia
sobre las otras colas.
Funcionamiento:




Si existe tráfico en la cola de prioridad, ésta es atendida antes que las otras
colas de prioridad personalizadas.
Si la cola de prioridad está libre, se procede a atender las otras colas según su
prioridad.
Es necesario configurar un AB límite reservado para la cola de
prioridad, evitando la inanición del resto de las colas.
La cola de prioridad asegura un retardo máximo garantizado para
los paquetes, calculado como el tamaño del MTU dividido por la
velocidad de enlace.
@ 2012 Ibitec S.L. Todos los derechos reservados.
9
Ancho de Banda - Compresión


Tipos de compresión:
Compresión de payload:



Compresión del enlace:


Para enlaces punto a punto donde la cabecera no es necesaria para enrutar el
paquete.
Compresión de cabecera:



No afecta a las cabeceras.
Es apropiado para enlaces en los que la cabecera tiene que ser legible para
enrutar los paquetes correctamente (p.ejem. Frame Relay y ATM).
Si se usa cRTP (RTP comprimido), las cabeceras de capa 3 y capa 4 de un
paquete VoIP se reducen de 40 hasta 2 bytes.
También se permite la compresión de cabeceras TCP para el tráfico de datos.
La compresión requiere tiempo y recursos de CPU, lo que
aumenta el retardo. Hay que tenerlo en cuenta al decidir cuáles
son las estrategias adecuadas para cada enlace.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 10 
LATENCIA O RETARDO
@ 2012 Ibitec S.L. Todos los derechos reservados.
 11 
Latencia o Retardo


Latencia: suma de todos los retardos acumulados desde el origen
hasta el destino.
Clasificación:

Fija: Predecible y constante. Fuentes de retardo:
-
-
Propagación: Es el tiempo que tarda la señal en cruzar el enlace. Es
equivalente a la velocidad de la luz desplazándose por un hilo de cobre o
una fibra óptica. Puede introducir retardos significativos en enlaces de
larga distancia.
Serialización: Es el tiempo que se tarda en “poner” los bits en el medio.
Depende de la velocidad del enlace y no varía a no ser que se cambie la
velocidad del enlace.


Variable: incluye los retardos de procesamiento y colas, que dependen
del tráfico, el rendimiento del router y otros factores que no son fáciles
de predecir ni constantes.
Para la reducción de la latencia:
 Aumentar la velocidad del enlace
 Utilizar Priority Queuing.
 Utilizar técnicas de compresión adecuadas.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 12 
PÉRDIDA DE PAQUETES
@ 2012 Ibitec S.L. Todos los derechos reservados.
 13 
Pérdida de Paquetes - Causas
 Posibles causas de pérdida de paquetes:
 Tail drop: Si la cola de salida está llena, no se pueden poner más paquetes en
cola y se eliminan del final (tail) de la cola, y se pierden. Causa más común de
perdida de paquetes.
 Input drop: Si la cola de entrada está llena, los paquetes se descartan a medida
que llegan, y se pierden. Esto sucede en contadas ocasiones y es un síntoma
de saturación de la CPU del router.
 Overrun: También son resultado de la saturación de la CPU, cuando el router no
puede asignar los paquetes al espacio vacío del buffer.
 Ignore: No hay espacio disponible en el buffer.
 Frame errors: Los problemas de transmisión generan errores CRC, tramas de
tipo giant o runt, debido a Interferencia electromagnética (EMI) o a problemas en
el hardware de la interfaz.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 14 
Pérdida de Paquetes – Estrategias de resolución
 Mecanismos QoS para paliar la reducción de pérdidas de paquetes:
 LLQ
 Compresión
 Aumentando la velocidad del enlace.
 Estrategias complementarias, denominadas mecanismos de
eficiencia de Enlace (Link Efficiency), para prevenir la congestión:
 Modelado de tráfico (Traffic shaping): Retrasa los paquetes para que se envíen
a una velocidad máxima configurada. Por ejemplo, si un servidor TFTO genera
un flujo de 512 kbps, el modelado podría limitar el output a 256 kbps, y retrasar
la salida del tráfico excesivo.
 Políticas de tráfico (Traffic policing): Descarta los paquetes que superan un
umbral. Estos paquetes pueden ser retransmitidos si el tráfico es TCP, no
debería aplicarse al tráfico VoIP porque no usa TCP como protocolo de
transporte.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 15 
REQUISITOS DE QOS PARA VOIP
@ 2012 Ibitec S.L. Todos los derechos reservados.
 16 
Requisitos de QoS para VoIP

Existen valores aceptables para la latencia, el jitter y la pérdida de
paquetes para VoIP. Utilizamos QoS y mecanismos de eficiencia
del enlace para mantener estos valores:




Latencia menor a 150 ms en un sentido.
El jitter debe ser menos de 30 ms en un sentido.
La perdida de paquetes debe ser de menos del 1%
Cada llamada VoIP requiere entre 17 y 106 kbps de ancho de banda priorizado,
dependiendo del códec, la compresión y el protocolo de capa 2 que se utiliza;
también son necesarios otros 105 bps para el tráfico de señalización.
 Los requisitos para video son similares. El consumo de ancho de banda se
calcula como [output del códec de video] + 20%. Por ejemplo, un canal de video
de 384 kbps debería reservar 460 kbps de ancho de banda.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 17 
REQUISITOS DE QOS PARA
TRÁFICO DE DATOS
@ 2012 Ibitec S.L. Todos los derechos reservados.
 18 
Requisitos de QoS para Tráfico de datos
 Los requerimientos de QoS para datos no son tan estrictos como
los de VoIP.
 Es recomendable clasificar el tráfico de datos en clases y asignar a
cada una, una cierta cantidad de AB a su cola.
 Las herramientas de clasificación de QoS de Cisco incluyen
Reconocimiento de Aplicaciones basadas en Red (Network-Based
Application Recognition – NBAR).
 Las clasificaciones que se crean componen la política de calidad de
servicio para la organización.
 La política refleja las necesidades reales tanto del tráfico de voz
como del tráfico de datos en la red.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 19 
Requisitos de QoS para Tráfico de datos
 Procedimiento de la Política de QoS:
1. Realizar una auditoría de red para determinar el estado del tráfico. Determinar
si existen problemas de congestión y enumerar las aplicaciones que se
detectan activas.
2. Realizar una auditoría de negocio para comprobar que las aplicaciones usadas
están alineadas con las necesidades del negocio. De esta auditoría, algunas
aplicaciones se identificaran como críticas para el funcionamiento del negocio,
otras como rutina, algunas serán triviales e incluso innecesarias.
3. Determinar el nivel de servicio requerido para cada aplicación. Esto irá desde
Prioritario (Priority) para voz y video, a Crítico (mission critical), Urgente
(Urgent), Rutina (Routine) y Carroñero (Scavenger) hasta incluso no permitido
(Disallowed).
4. Diseñar el esquema de clasificación adecuado para los resultados de la
auditoría. Utilizar las decisiones ejecutivas y la auditoría de negocio para crear
un sistema de clasificación que cubra las necesidades de negocio.
5. Definir los parámetros de QoS para cada clase de tráfico. Esto incluye anchos
de banda mínimos y máximos, prioridad por clase, estrategia de colas y
métodos de eficiencia de enlace.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 20 
AUTOQOS
@ 2012 Ibitec S.L. Todos los derechos reservados.
 21 
AutoQoS
 AutoQoS automatiza y simplifica las configuraciones de QoS.
 AutoQoS genera las clases de tráfico y las políticas de servicio a
partir de plantillas predeterminadas, eliminando la necesidad de
tener un gran conocimiento de los comandos.
 La configuración generada se adapta a los cambios (como puedan
ser los movimiento de teléfonos) y se puede personalizar
manualmente para dar respuesta a necesidades específicas,
después de terminar el proceso automático.
 AutoQoS está disponible en todos los routers y switches para voz
con el IOS correcto.
 El comando AutoQoS se limita a los siguientes interfaces:
 Enlaces Serial PPP or HDLC
 Enlaces Frame Relay solo punto-a-punto
 PVCs de ATM, a baja y alta velocidad
@ 2012 Ibitec S.L. Todos los derechos reservados.
 22 
QoS Trust Boundary
 Frontera de Confianza (Trust Boundary): punto en el que el switch o
router crean el etiquetado de QoS del paquete o trama.
 Si es de confianza, el paquete es tratado de acuerdo con su marca de QoS y
política correspondiente.
 Si no es de confianza, puede ser etiquetado de nuevo y tratado de forma
diferente.
 Queremos que el Trust Boundary esté lo más cerca posible del
origen. Para ello el trust boundary debería estar entre el teléfono IP
y el PC conectado, ya que normalmente no confiamos en el PC
pero sí en el teléfono. Si no hay teléfono, el trust boundary está
entre el PC y el switch. El switch debe ser capaz de identificar y
configurar el trust boundary, si no lo hace, debemos mover el trust
boundary hasta el router gateway.
 AutoQoS puede detectar y configurar el trust boundary
automáticamente.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 23 
CONFIGURAR AUTOQOS
@ 2012 Ibitec S.L. Todos los derechos reservados.
 24 
Configurar AutoQoS
 El comando auto qos voip [trust] [fr-atm] habilita AutoQoS en la interfaz.
 El parámetro [trust] hace que las marcas DSCP del paquete sean de confianza para
la clasificación. Si no se utiliza la opción trust, el tráfico se clasifica según NBAR, y
los paquetes se marcan con DSCO según corresponda.
 La palabra [fr-atm] se usa en enlaces punto-a-punto Frame Realy o ATM. AutoQoS
se basa en el AB configurado en cada interfaz cuando se ejecuta por primera vez. Si
el AB se reduce, no cambia la configuración de AutoQoS. Si queremos que los
cambios en el AB de un interfaz se reflejen en AutoQoS, deberíamos borrarlo y volver
a aplicarlo.
 En un interfaz de un switch, la opción [ciscophone] habilita la función de
trusted boundary cuando detecta a u teléfono Cisco a través de
mensajes CDP.
 Cuando se detecta el teléfono, se confía en el etiquetado del paquete y si no se
detecta un teléfono no se confía en las marcas.
 La opción [trust] en el interfaz del switch hace que la marca de los
paquetes entrantes sea de confianza (trusted) independientemente de
si se ha detectado un teléfono.
@ 2012 Ibitec S.L. Todos los derechos reservados.
 25 
Fin
Preguntas
@ 2012 Ibitec S.L. Todos los derechos reservados.
 26 