Calidad de servicio para Voz sobre IP

Calidad de servicio para Voz sobre IP
Contenidos
Calidad de servicio para Voz sobre IP
Información general de QoS para VoIP
Ancho de banda suficiente
Clasificación de paquetes
Información general de clasificación de paquetes
Clasificación y marcado
Ejemplo de marcado y clasificación de pares de marcado por voz
Ejemplo de marcado y clasificación de índice de acceso comprometido
Ejemplo de marcado y clasificación del enrutamiento basado en políticas
Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular
Mecanismos de colocación en cola de QoS
Cola de latencia baja
Ejemplo de configuración de LLQ
Otros mecanismos de colocación en cola de QoS
Fragmentación y entrelazado
Información general de entrelazado y fragmentación
Ejemplo de entrelazado y fragmentación de enlaces MLP
Ejemplo de entrelazado y fragmentación FRF.12
Modelado de tráfico
Información general de modelado de tráfico
Ejemplo de modelado de tráfico de retransmisión por frame (frame relay)
Compresión de encabezados IP RTP
Servicios diferenciados para VoIP
Información general de DS y DSCP (RFC 2474, RFC 2475)
Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598)
Ejemplo de configuración de marcado basado en la clase DSCP
Protocolo de reserva de recursos
Información general de RSVP
Información general de RSVP para CAC
Implementación de CAC basada en RSVP
Configuración de recursos de puertas de enlace locales si CAC falla
Uso de RSVP con LLQ
Implementación del soporte de RSVP para LLQ
QoS de VoIP sobre líneas alquiladas (mediante PPP)
VoIP sobre escenario de líneas alquiladas (mediante PPP)
Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP)
QoS de VoIP sobre redes de retransmisión por frame (frame relay)
QoS de VoIP sobre redes de retransmisión por frame (frame relay)
Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay)
QoS de VoIP sobre ATM
QoS de VoIP sobre escenario de ATM
QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado
QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos
Documentos relacionados
Calidad de servicio para Voz sobre IP
Historial de la versión
Número de versión
Fecha
Notas
1
16 de abril de 2001
Se creó este documento.
2
15 de mayo de 2001
Se incorporaron los comentarios editoriales.
3
30 de junio de 2001
Se incorporaron comentarios editoriales adicionales.
Calidad de servicio para Voz sobre IP trata los conceptos de la Calidad de Servicio (QoS) y las características aplicables a la voz, en particular, a
la Voz sobre IP (VoIP). En este documento también se proporcionan ejemplos de alto nivel en los que se muestran cómo implementar estas
características en entornos de red diferentes.
Calidad de servicio para Voz sobre IP contiene las siguientes secciones:
Información general de QoS para VoIP
Ancho de banda suficiente
Clasificación de paquetes
Mecanismos de colocación en cola de QoS
Fragmentación y entrelazado
Modelado de tráfico
Compresión de encabezados IP RTP
Servicios diferenciados para VoIP
Protocolo de reserva de recursos
QoS de VoIP sobre líneas alquiladas (mediante PPP)
QoS de VoIP sobre redes de retransmisión por frame (frame relay)
QoS de VoIP sobre ATM
Documentos relacionados
Información general de QoS para VoIP
Para que la VoIP sea un reemplazo realista para los servicios de telefonía de redes de telefonía pública conmutada estándar (PSTN), los clientes
deben recibir la misma calidad de transmisión de voz que reciben con los servicios de telefonía básica, es decir, transmisiones de voz de alta
calidad sistemáticamente. Al igual que otras aplicaciones de tiempo real, VoIP es extremadamente sensible al ancho de banda y al retraso. Para
que las transmisiones de VoIP sean inteligibles para el receptor, los paquetes de voz no se deben perder ni retrasar excesivamente ni sufrir
distintos retrasos (también conocido como "fluctuación"). Por ejemplo, se deben cumplir las siguientes normas:
El códec G.729 predeterminado necesita que haya una pérdida de paquetes bastante inferior al 1 por ciento para evitar errores audibles. Lo
mejor sería que no se perdieran paquetes para VoIP.
La especificación ITU G.114 recomienda un retraso de extremo a extremo unidireccional inferior a 150 milisegundos (ms) para el tráfico
en tiempo real de alta calidad como la voz. (Para las llamadas internacionales, se acepta un retraso unidireccional de hasta 300 ms, en
especial para las trasmisiones por satélite. Este retraso unidireccional tiene en cuenta el retraso de propagación; es decir, el tiempo
necesario para que la señal recorra la distancia).
Las memorias intermedias para fluctuación (utilizadas para compensar los diferentes retrasos) se agregan posteriormente al retraso de
extremo a extremo y normalmente sólo son efectivas en las variaciones de retraso inferiores a 100 ms. Por tanto, se debe minimizar la
fluctuación.
VoIP sólo puede garantizar una transmisión de voz de alta calidad si los paquetes de voz, tanto para el canal de audio como para el de señal,
tienen prioridad sobre otros tipos de tráfico de red. Para que VoIP se implemente de forma que los usuarios reciban un nivel aceptable de calidad
de voz, el tráfico de VoIP debe tener garantizados ciertos requisitos de fluctuación, latencia y ancho de banda de compensación. QoS garantiza
que los paquetes de voz VoIP reciban el trato preferente que requieren. En general, QoS proporciona un servicio de red mejor (y más predecible)
al proporcionar las siguientes características:
Soporte de ancho de banda dedicado
Mejora de las características de pérdida
Impedimento y administración de la congestión de red
Modelado del tráfico de red
Configuración de las prioridades del tráfico a través de la red
Calidad de servicio para Voz sobre IP trata los conceptos de QoS y las características aplicables a la voz, en particular a VoIP.
Ancho de banda suficiente
Antes de que se plantee aplicar cualquiera de las características de QoS abordadas en este documento, deberá proporcionar un ancho de banda de
red suficiente para soportar el tráfico de voz en tiempo real. Por ejemplo, una llamada G.711 de VoIP de 80 kbps (carga útil de 64 kbps más
encabezado de 16 kbps) no será suficiente en un enlace de 64 kbps porque se perderán al menos 16 kbps de los paquetes (es decir, el 20 por
ciento). En este ejemplo, también se supone que no fluye más tráfico a través del enlace. Una vez que proporcione un ancho de banda suficiente
para el tráfico de voz, podrá dar más pasos para garantizar que los paquetes de voz dispongan de un determinado porcentaje del ancho de banda
total y que tengan prioridad.
Clasificación de paquetes
La base para proporcionar cualquier QoS reside en la capacidad de un dispositivo de red para identificar y agrupar paquetes específicos.
Este proceso de identificación se denomina clasificación de paquetes. Una vez clasificado el paquete, éste debe marcarse estableciendo los
bits designados en el encabezado IP. Las siguientes secciones describen la clasificación y el marcado:
Información general de clasificación de paquetes
Ejemplo de marcado y clasificación de pares de marcado por voz
Ejemplo de marcado y clasificación de índice de acceso comprometido
Ejemplo de marcado y clasificación del enrutamiento basado en políticas
Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular
Información general de clasificación de paquetes
Para garantizar el ancho de banda para los paquetes VoIP, un dispositivo de red debe poder identificar los paquetes VoIP en todo el tráfico IP que
fluye a través de él. Los dispositivos de red utilizan una dirección IP de origen y de destino en el encabezado IP o en los números de puerto de
protocolo de datagrama de usuario (UDP) de origen y de destino en el encabezado de UDP para identificar los paquetes VoIP. Este proceso de
agrupamiento e identificación se denomina clasificación y es la base para proporcionar QoS.
Aparte de los métodos de clasificación estática que implican la coincidencia de información del encabezado de la Capa 3 o Capa 4, puede utilizar
un mecanismo como el protocolo de reserva de recursos (RSVP) para la clasificación dinámica. RSVP utiliza paquetes de señalización H.245
para determinar el puerto UDP que utilizará la conversación de voz. A continuación, configura listas de acceso dinámico para identificar el tráfico
de VoIP y coloca el tráfico en una cola reservada. RSVP se abordará más adelante en este documento.
La clasificación de paquetes puede ser un procesamiento intensivo, por lo que debería tener lugar lo más lejos posible del borde de la red. Puesto
que cada salto necesita realizar una determinación del tratamiento que el paquete debería recibir, necesitará disponer de un método de
clasificación más eficiente y más simple en el núcleo de la red. Esta clasificación más simple se logra mediante el marcado o configuración del
byte ToS (tipo de servicio) en el encabezado IP.
Los tres bits más importantes de byte ToS se denominan bits de precedencia de IP. La mayoría de las aplicaciones y de los proveedores soportan
actualmente la configuración y el reconocimiento de estos tres bits. El marcado se lleva a cabo para que los seis bits más significativos del byte
ToS, llamados "punto de código de servicios diferenciados" (DSCP), puedan usarse para definir las clases de servicios diferenciados (DS). DSCP
se abordará más adelante en este documento.
Cuando cada uno de los saltos en la red pueda clasificar e identificar los paquetes VoIP (ya sea mediante información de la dirección del puerto o
mediante el byte ToS), dichos saltos podrán entonces proporcionarle a cada paquete VoIP la QoS necesaria. En este punto, se pueden configurar
las técnicas especiales para proporcionar almacenamiento en cola prioritario para garantizar que los paquetes de datos grandes no interfieren en la
transmisión de datos de voz y para reducir los requisitos de ancho de banda comprimiendo la IP de 40 bytes más UDP más encabezado RTP a
entre 2 y 4 bytes.
Clasificación y marcado
La clasificación es un proceso de identificación de la clase o grupo al que pertenece un paquete. Los dispositivos de red utilizan varios criterios
de concordancia para colocar el tráfico en un determinado número de clases. Las concordancias se basan en los siguientes criterios:
El comando de configuración global dial-peer voice voip
Lista de acceso (estándar y extendida)
Protocolo (por ejemplo, URL, protocolos con estado o protocolo de Capa 4)
Puerto de entrada
Precedencia IP o DSCP
Clase de servicio (CoS) Ethernet 802.1p
Como ya se ha mencionado, puede ser un procesamiento intensivo si los nodos deben repetir la clasificación basada en las coincidencias de las
listas de acceso. Por lo tanto, los nodos deberían marcar los paquetes en cuanto hayan identificado y clasificado los paquetes VoIP. Si un nodo
puede establecer la precedencia IP o los bits DSCP en el byte ToS del encabezado IP en cuanto identifica el tráfico como tráfico de VoIP, los
demás nodos de la red pueden clasificar en función de estos bits.
El marcado es el proceso del nodo mediante el que establece una de las siguientes opciones:
Tres bits de precedencia de IP en el byte ToS de IP.
Seis bits de DSCP en el byte ToS de IP
Tres bits experimentales de MPLS (EXP)
Tres bits de CoS de Ethernet 802.1p
Un bit de probabilidad de pérdida de celda (CLP) de ATM
En la mayoría de las redes IP, el DSCP o la precedencia IP de marcado debería ser suficiente para identificar el tráfico como de VoIP.
Ejemplo de marcado y clasificación de pares de marcado por voz
Con las puertas de enlace de VoIP de Cisco, por lo general, utilizará pares de marcado de voz para clasificar los paquetes VoIP y marcar los bits
de precedencia de IP. En el siguiente ejemplo de configuración se muestra cómo marcar los bits de precedencia de IP:
Ejemplo de configuración 1: Clasificación y marcado mediante pares de marcado
dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5
En este ejemplo, cualquier llamada VoIP que coincida con el comando dial-peer voice 100 voip tendrá todos los paquetes de carga de voz
definidos con la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP están definidos en 101.
Ejemplo de marcado y clasificación de índice de acceso comprometido
El índice de acceso comprometido (CAR) es una técnica antigua que implica el control del tráfico o la limitación de velocidad que coincide con
determinados criterios en un límite superior. CAR admite la mayoría de los mecanismos de concordancia y permite que los bits de DSCP o de
precedencia IP se definan de forma diferente en función de si los paquetes se ajustan a una determinada velocidad o la sobrepasan.
En general, CAR resulta más útil para los paquetes de datos que para los de voz. Por ejemplo, todo el tráfico de datos en una interfaz Ethernet de
al menos 1 Mbps se puede colocar en una precedencia IP de clase 3 y todo el tráfico con una velocidad superior a un 1 Mbps se puede poner en
una clase 1 o perder. Otros nodos de la red pueden así tratar de forma diferente el tráfico excesivo o que no cumpla con las normas marcado con
una precedencia IP inferior. Todo el tráfico de voz deberá ajustarse a la velocidad especificada, si se ha configurado correctamente.
En el siguiente ejemplo de configuración se muestra cómo utilizar CAR para clasificar y marcar los paquetes VoIP:
Ejemplo de configuración 2: Clasificación y marcado mediante CAR
access-list 100 permit udp any any range 16384 32767
access-list 100 permit tcp any any eq 1720
!
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
rate-limit input
access-group 100 1000000 8000 8000 conform-action
set-prec-continue 5 exceed-action set-prec-continue 5
En este ejemplo, el tráfico que coincida con la lista de acceso 100 se establecerá en la precedencia IP 5, lo que significa que los tres bits más
significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y
el tráfico de señalización H.323 para el puerto TCP 1720.
Ejemplo de marcado y clasificación del enrutamiento basado en políticas
El enrutamiento basado en políticas (PBR) es otra característica anterior que permite que el tráfico se enrute en función de la lista de acceso o del
puerto de origen. También se puede utilizar para clasificar y marcar paquetes. Un ejemplo de configuración simple sería:
Ejemplo de configuración 3: Clasificación y marcado mediante PBR
access-list 100 permit udp any any range 16384 32767
access-list 100 permit tcp any any eq 1720
!
route-map classify_mark
match ip address 100
set ip precedence 5
!
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
ip policy route-map classify_mark
En este ejemplo, el tráfico que coincida con la lista de acceso 100 se establecerá en la precedencia IP 5, lo que significa que los tres bits más
significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y
el tráfico de señalización H.323 para el puerto TCP 1720.
Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular
El método de marcado y clasificación recomendado es la característica de interfaz de línea de comandos QoS modular (Mod QoS CLI o MQC),
un método de configuración basado en plantilla que separa la clasificación de la política, permitiendo que varias características de QoS se
configuren conjuntamente para varias clases. Utilice la asignación de clase para clasificar el tráfico en función de varios criterios de coincidencia
y una asignación de políticas para determinar qué debería ocurrir con cada clase. A continuación, aplique la política al tráfico entrante o saliente
en una interfaz mediante el comando de configuración de interfaz service-policy. En el siguiente ejemplo de configuración se muestra cómo
utilizar QoS modular para clasificar y marcar los paquetes:
Ejemplo de configuración 4: Clasificación y marcado mediante MQC
access-list 100 permit udp any any range 16384 32767
access-list 100 permit tcp any any eq 1720
!
class-map voip
match access-group 100
!
policy-map mqc
class voip
set ip precedence 5
<<#various other QoS commands>>
class class-default
set ip precedence 0
<<#various other QoS commands>>
!
interface Ethernet0/0
service-policy input mqc
En este ejemplo, el tráfico que coincida con la lista de acceso 100 se clasificará como clase voip y se establecerá con la precedencia IP 5, lo
que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos
UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720. El resto del tráfico se define con precedencia
IP 0. La política se denomina mqc y se aplica al tráfico entrante en la interfaz Ethernet 0/0.
Mecanismos de colocación en cola de QoS
Una vez que se ha colocado el tráfico en las clases de QoS en función de los requisitos de QoS, necesitará proporcionar garantías de ancho de
banda y servicio prioritario a través de un mecanismo de colocación en cola de salida inteligente. En esta sección se describen los mecanismos de
colocación en cola y se incluyen las siguientes subsecciones:
Cola de latencia baja
Ejemplo de configuración de LLQ
Otros mecanismos de colocación en cola de QoS
Cola de latencia baja
Se requiere una cola de prioridad para VoIP. Puede utilizar cualquier mecanismo de colocación en cola que efectivamente le dé alta prioridad a
VoIP, aunque se recomienda una cola de tiempo latencia bajo (LLQ) porque es flexible y fácil de configurar.
El método de colocación en cola más flexible que satisface los requisitos de VoIP es la LLQ. LLQ utiliza el método de configuración MQC para
priorizar determinadas clases y proporcionar un ancho de banda mínimo garantizado para otras. Durante los períodos de congestión, la cola de
prioridad se controla en la velocidad configurada de manera que el tráfico prioritario no monopolice todo el ancho de banda disponible. (Si el
tráfico de prioridad monopoliza el ancho de banda, impide que se alcancen las garantías de ancho de banda para otras clases). Si se ofrece LLQ
correctamente, el tráfico que vaya a la cola de prioridad nunca debería exceder la velocidad configurada.
LLQ también permite que se especifiquen las profundidades de la cola para determinar cuándo el router debería eliminar paquetes si hay
demasiados esperando en cualquier cola de clase determinada. También hay un valor predeterminado de clase que se utiliza para definir el
tratamiento de todo el tráfico no clasificado por una clase configurada. Es posible configurar la clase predeterminada mediante el comando de
configuración de interfaz fair-queue, lo que significa que a cada flujo sin clasificar se le dará una parte más o menos igual del ancho de banda
restante. La figura 1 muestra cómo funciona LLQ.
Figura 1: Funcionamiento de LLQ
En la Figura 1, todo el tráfico que sale de una interfaz o subinterfaz (para retransmisión por frame (frame relay) y ATM) se clasifica en primer
lugar mediante MQC. Existen cuatro clases: una clase de alta prioridad, dos clases de ancho de banda garantizado y una clase predeterminada. El
tráfico de clase de prioridad se coloca en una cola de prioridad y el tráfico de clase de ancho de banda garantizado junto a las colas reservadas. Se
podrá ofrecer una cola reservada al tráfico de clase predeterminada o colocarlo en una cola predeterminada sin reservar donde cada flujo obtendrá
una parte más o menos igual del ancho de banda disponible y sin reservar. El planificador presta servicio a las colas de manera que el tráfico de la
cola de prioridad salga en primer lugar a menos que exceda un ancho de banda de prioridad configurado y que una cola reservada lo necesite (es
decir, hay congestión). Se presta servicio a las colas reservadas según el ancho de banda reservado, que el planificador utiliza para calcular un
peso. El peso se utiliza para determinar la frecuencia con que se presta servicio a una cola reservada y cuántos bytes se ofrecen cada vez. Los
servicios del planificador se basan en el algoritmo de colocación en cola equilibrada y ponderada (WFQ), una tema que supera el ámbito de este
documento.
Si la cola de prioridad se llena porque la velocidad de transmisión del tráfico de prioridad es superior al ancho de banda de prioridad configurado,
los paquetes situados al final de la cola de prioridad se eliminarán sólo en el caso de que no haya más ancho de banda sin reservar disponible. No
se restringe ninguna de las colas reservadas al ancho de banda configurado si hay ancho de banda disponible. Los paquetes que infrinjan el ancho
de banda y la prioridad garantizados sólo se eliminarán durante los periodos de congestión. Por tanto, la cola de prioridad deberá contar con
ancho de banda suficiente para manejar todo el tráfico de VoIP que necesite servicio prioritario.
Ejemplo de configuración de LLQ
En el siguiente ejemplo de configuración se muestra cómo configurar LLQ:
Ejemplo de configuración 5: LLQ
access-list 100 permit udp
access-list 100 permit tcp
access-list 101 permit tcp
access-list 102 permit tcp
!
class-map voip
match access-group 100
class-map data1
match protocol
any
any
any
any
any
any
any
any
range 16384 32000
eq 1720
eq 80
eq 23
class-map data2
match access-group 102
!
policy-map llq
class voip
priority 32
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq
En este ejemplo, el tráfico que coincida con la lista de acceso 100 será clasificado como clase voip, (lo que quiere decir "tráfico de voz"), y se
le dará alta prioridad hasta un máximo de 32 kbps. La lista de acceso 100 coincide con los puertos UDP comunes utilizados por el tráfico de
señalización VoIP y H.323 para el puerto TCP 1720. El comando class data1 coincide con el tráfico web (el puerto TCP 80 tal y como se ve
en la lista de acceso 101) y garantiza 64 kbps. El comando class data2 coincide con el tráfico Telnet (puerto TCP 23 tal y como se ve en la
lista de acceso 102) y garantiza 32 kbps. La clase predeterminada se configura para dar una parte igual del ancho de banda restante a los
flujos sin clasificar. La política se denomina llq y se aplica al tráfico saliente en la interfaz de serie 1/0, que tiene un ancho de banda total de
256 kbps.
Nota En forma predeterminada, el ancho de banda total garantizado y el ancho de banda de prioridad para todas las clases
debería ser inferior al 75 por ciento del ancho de banda de la interfaz. Puede modificar este porcentaje usando el comando de
configuración de interfaz max-reserved bandwidth.
Otros mecanismos de colocación en cola de QoS
Hay otros métodos de colocación en cola disponibles. Por ejemplo, el Ordenamiento cíclico con déficit modificado (MDRR) es un mecanismo de
colocación en cola disponible en las series 12000 de los routers switches Gigabit (GSR) de Cisco que permite la garantía de ancho de banda y el
servicio prioritario basado en la precedencia IP, DSCP y clases MPLS EXP. MDRR soporta una cola de prioridad, siete reservadas y una de
multidifusión.
Una vez más, VoIP necesita prioridad pero hay aplicaciones de datos que no pueden quedarse sin ancho de banda y necesitan garantías de que lo
van a tener. Puede usar cualquier mecanismo de colocación en cola que proporcione de hecho alta prioridad a VoIP, aunque recomendamos LLQ.
En la Tabla 1 se describen algunos de los mecanismos de colocación en cola de software disponibles.
Tabla 1: Mecanismos de colocación en cola de software
Mecanismos de
colocación en cola
de software
Descripción
Beneficios
Limitaciones
FIFO
Los paquetes llegan y dejan la cola
exactamente en el mismo orden.
Configuración simple y
rápida operación.
No es posible ofrecer el servicio
prioritario ni las garantías de ancho
de banda.
WFQ
Un algoritmo de hash coloca flujos en
colas independientes donde los pesos se
utilizan para determinar a cuántos
paquetes se presta servicio en cada
momento. Los pesos se definen al
establecer los valores de precedencia IP
y DSCP.
Configuración simple. Valor
predeterminado en enlaces
inferior a 2 Mbps.
No es posible ofrecer el servicio
prioritario ni las garantías de ancho
de banda.
Almacenamiento en
cola personalizado
(CQ)
El tráfico se clasifica en colas múltiples
con límites de cola configurables. Los
límites de cola se calculan según el
tamaño medio del paquete, la unidad de
Ha estado disponible durante
algunos años y permite la
asignación aproximada de
ancho de banda para varias
No es posible la prestación de
servicio prioritario. Las garantías de
ancho de banda son aproximadas y
hay un número limitado de colas. La
transmisión máxima (MTU) y el
porcentaje de ancho de banda que se va
a asignar. Los límites de cola (en
número de bytes) se quitan de la cola
para cada cola, por lo que se
proporciona el ancho de banda asignado
estadísticamente.
colas.
configuración es relativamente
difícil.
Priority Queuing
(PQ)
El tráfico se clasifica en colas de
prioridad alta, media, normal y baja.
Primero se presta servicio al tráfico de
alta prioridad, después al de prioridad
media y, por último, al de prioridad
normal y baja.
Ha estado disponible durante
algunos años y ofrece
prestación de servicios
prioritarios.
El tráfico de prioridad más alta
puede privar de ancho de banda a las
colas de prioridad más bajas. No es
posible ofrecer garantía de ancho de
banda.
WFQ basado en
clases (CBWFQ)
MQC se utiliza para clasificar el tráfico.
El tráfico clasificado se coloca en colas
de ancho de banda reservado o en una
cola predeterminada no reservada. Los
planificadores prestan servicio a las
colas según los pesos de manera que se
cumplan las garantías de ancho de
banda.
Es similar a LLQ, a excepción
de que no hay una cola
prioritaria. Configuración
simple y capacidad de
proporcionar garantías de
ancho de banda.
No es posible la prestación de
servicio prioritario.
WFQ de cola de
prioridad (PQWFQ, también
denominado
"prioridad IP
RTP")
Se utiliza un comando de interfaz único
para ofrecer prestación de servicios de
prioridad a todos los paquetes UDP
destinados a números de puerto pares
dentro de un rango especificado.
Configuración simple de un
único comando. Proporciona
servicio prioritario a paquetes
RTP.
El tratamiento del resto del tráfico se
realizará con WFQ. El tráfico RTCP
no se prioriza. No hay capacidad de
ancho de banda garantizada.
LLQ (denominado
anteriormente "PQCBWFQ")
MQC se utiliza para clasificar el tráfico.
El tráfico clasificado se coloca en una
cola de prioridad, colas de ancho de
banda reservado o en una cola no
reservada predeterminada. Un
planificador se ocupa de las colas
basándose en el peso para que el tráfico
de prioridad sea enviado primero (hasta
un cierto límite regulado durante la
congestión) y para que se cumplan las
garantías del ancho de banda.
Configuración simple.
Capacidad de otorgar
prioridad a distintas clases de
tráfico y ofrecer más límites
sobre la utilización del ancho
de banda prioritario. También
puede configurar clases de
ancho de banda garantizado y
una clase predeterminada.
No hay ningún mecanismo para
ofrecer varios niveles de prioridad
todavía ya que todo el tráfico de
prioridad se envía a través de la
misma cola de prioridad. Las clases
de prioridad independientes pueden
tener límites superiores de prioridad
de ancho de banda durante la
congestión, aunque compartir la cola
de prioridad entre aplicaciones
puede crear fluctuaciones.
Fragmentación y entrelazado
Debido a que las transmisiones de VoIP son extremadamente sensibles a los retrasos, los paquetes VoIP deberán entrelazarse o insertarse entre
los fragmentos del paquete de datos. Esta sección describe la fragmentación y el entrelazado e incluye, además, las siguientes subsecciones:
Información general de entrelazado y fragmentación
Ejemplo de entrelazado y fragmentación de enlaces MLP
Ejemplo de entrelazado y fragmentación FRF.12
Información general de entrelazado y fragmentación
Aunque la colocación en cola esté funcionando a pleno desempeño y priorizando el tráfico de voz, hay ocasiones en las que la cola de prioridad
está vacía y se presta servicio a un paquete de otra clase. Se debe prestar servicio a los paquetes de las clases de ancho de banda garantizado de
acuerdo con el peso configurado. Si un paquete de voz con prioridad llega a la cola de salida mientras se está prestando servicio a estos paquetes,
el paquete VoIP podría esperar un tiempo considerable antes de ser enviado. Si asumimos que un paquete VoIP tendrá que esperar detrás de un
paquete de datos y que puede ser, al menos, igual en tamaño que la MTU (1500 bytes para interfaz de serie y 4470 bytes para interfaces de serie
de alta velocidad), podremos calcular el tiempo de espera según la velocidad del enlace.
Por ejemplo, en el caso de una velocidad de enlace de 64 kbps y un tamaño de MTU de 1500 bytes, tendremos lo siguiente:
Serialization delay = (1500 bytes * 8 bits/byte) / (64,000 bits/sec) = 187.5 ms
Por tanto, es posible que un paquete VoIP tenga que esperar hasta un máximo de 187,5 ms antes de que pueda enviarse si se retrasa detrás de un
paquete de 1500 bytes en un enlace de 64 kbps. Por lo general, los paquetes VoIP se envían cada 20 ms. Con un presupuesto de retraso de
extremo a extremo de 150 ms y unos requisitos de fluctuación estrictos, una brecha de más de 180 ms es inaceptable.
Necesita un mecanismo que garantice que el tamaño de una unidad de transmisión sea inferior a 10 ms. Los paquetes que tengan un retraso de
serialización superior a 10 ms tendrán que dividirse en partes de 10 ms. Una parte o fragmento de 10 ms es el número de bytes que puede
enviarse por el enlace en 10 ms. Puede calcular el tamaño usando la velocidad del enlace:
Fragmentation size = (0.01 seconds * 64,000 bps) / (8 bits/byte) = 80 bytes
Se tarda 10 ms en enviar un paquete o fragmento de 80 bytes por un enlace de 64 kbps.
En enlaces de baja velocidad donde un paquete de 10 ms de tamaño es más pequeño que la MTU, será necesaria la fragmentación. Sin embargo,
la simple fragmentación no es suficiente porque si el paquete VoIP debe esperar detrás de todos los fragmentos de un único paquete de datos de
gran tamaño, el paquete VoIP seguirá sufriendo un retraso más allá del límite de retraso de extremo a extremo. El paquete VoIP debe estar
entrelazado o insertado entre los fragmentos del paquete de datos. En la Figura 2 se ilustra la fragmentación y el entrelazado.
Figura 2: Fragmentación y entrelazado de paquete VoIP
En la Tabla 2 se muestran los tamaños de fragmentos recomendados para varias velocidades de enlace basadas en la regla de los 10 ms.
Tabla 2: Velocidad de enlace y tamaño de fragmentación
Velocidad de
enlace (kbps)
Tamaño de fragmentación (bytes)
56
70
64
80
128
160
256
320
512
640
768
960
1024
1280
1536
1920 (No es necesario realizar una fragmentación si el tamaño del fragmento es mayor que el tamaño del enlace de
MTU. Por ejemplo, en el caso de un enlace T1 con un MTU de 1500 bytes, el tamaño del fragmento será 1920 bytes;
por tanto, no será necesaria la fragmentación).
Nota El tamaño de fragmentación del paquete nunca debería ser inferior al tamaño del paquete VoIP. Además, nunca debería fragmentar
los paquetes VoIP ya que puede causar numerosos de problemas de configuración y de calidad de las llamadas.
Hay disponibles tres mecanismos de fragmentación y entrelazado de enlaces (LFI). En la Tabla 3 se muestran sus ventajas y limitaciones.
Tabla 3: Velocidad de enlace y tamaño de fragmentación
Mecanismo de LFI
Descripción
Beneficios
Limitaciones
Fragmentación de
MTU con WFQ
Comando de nivel de interfaz para
cambiar el tamaño de MTU o de
MTU de IP. Utilizado para
fragmentar paquetes IP de gran
tamaño en el tamaño de MTU
especificado. LFI usa WFQ para
entrelazar paquetes en tiempo real
entre los fragmentos.
Configuración simple.
Los fragmentos vuelven a ensamblarse
únicamente mediante la aplicación de
recepción, por lo que el uso de la red es
ineficaz. Sólo los paquetes IP con el bit
No fragmentar (DF) no definido podrán
manejar la fragmentación
correctamente. Uso intensivo del
procesador. No recomendado.
Fragmentación y
entrelazado de enlace
(LFI) del protocolo
punto a punto de
enlaces múltiples
(MLP)
En los enlaces seriales de punto a
punto, deberá configurarse primero
MLP, a continuación, deberá
definirse el tamaño de
fragmentación en milisegundos.
También deberá activarse el
entrelazado en la interfaz de enlace
múltiple.
Los paquetes se fragmentan
en un extremo del enlace y
se vuelven a ensamblar en el
otro. Es posible combinar
varios enlaces para que
actúen como un gran
conducto virtual.
Únicamente disponible en enlaces
configurados para PPP. Las soluciones
para PPP sobre retransmisión por frame
(frame relay) o PPP sobre ATM
también se soportan en la versión
12.1(5)T o posterior de Cisco IOS.
Fragmentación de
retransmisión por
frame (frame relay)
(FRF.12)
En los PVC de retransmisión por
frame (frame relay), debe activarse
el comando de configuración de
interfaz frame-relay trafficshaping y establecerse el tamaño
de la fragmentación en la clase de
asignación.
Los paquetes se fragmentan
en un extremo de PCV y se
vuelven a ensamblar en el
otro.
Sólo está disponible en los PVC de
retransmisión por frame (frame relay)
con el comando de configuración de
interfaz frame-relay traffic-shaping
activado.
Ejemplo de entrelazado y fragmentación de enlaces MLP
En el siguiente ejemplo de configuración se muestra cómo configurar la fragmentación y el entrelazado mediante MLP LFI:
Ejemplo de configuración 6: MLP LFI
interface Serial1/0
bandwidth 256
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 1
!
interface Multilink1
ip address 10.1.1.1 255.255.255.252
bandwidth 256
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 1
En este ejemplo, se configura MLP LFI con un tamaño de fragmentación de 10 ms, que se calcula según el ancho de banda configurado para
la interfaz de enlaces múltiples. La interfaz de serie 1/0 se coloca en el grupo de enlaces múltiples 1 y, por tanto, hereda la configuración de
enlace múltiple en la interfaz de enlace múltiple 1.
Ejemplo de entrelazado y fragmentación FRF.12
En el siguiente ejemplo de configuración se muestra cómo configurar la fragmentación y el entrelazado mediante FRF.12:
Ejemplo de configuración 7: LFI de fragmentación de retransmisión por frame (frame relay) (FRF.12)
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
!
map-class frame-relay voice
frame-relay cir 256000
frame-relay fragment 320
En este ejemplo, el modelado de tráfico de retransmisión por frame (frame relay) se activa en DLCI 128. FRF.12 se configura con un tamaño
de fragmentación de 320 bytes, que es 10 ms de la velocidad de información comprometida (CIR). El tamaño de fragmentación debería ser
10 ms de la menor velocidad de puerto en los puntos extremos de PVC. En este ejemplo se asume que CIR y la menor velocidad de puerto es
la misma: 256 kbps.
Modelado de tráfico
El modelado de tráfico es un mecanismo de QoS que se utiliza para enviar tráfico en ráfagas cortas a una velocidad de transmisión configurada.
Se utiliza más comúnmente en los entornos de retransmisión por frame (frame relay) donde la velocidad del reloj no es la misma que el ancho de
banda garantizado o CIR. En esta sección se describen los mecanismos de modelado de tráfico y se incluyen las siguientes subsecciones:
Información general de modelado de tráfico
Ejemplo de modelado de tráfico de retransmisión por frame (frame relay)
Información general de modelado de tráfico
El modelado de tráfico de retransmisión por frame (frame relay) es la aplicación de modelado de tráfico más común en entornos de VoIP. Los
escenarios de retransmisión por frame (frame relay) tienen por lo general una red radial donde la velocidad del enlace de hub es superior a
cualquiera de las velocidades de enlace remoto. En algunos casos, la suma de las velocidades de enlace remoto es superior a la velocidad de
enlace de hub, lo que provoca un exceso de suscripciones. Sin el modelado de tráfico de retransmisión por frame (frame relay), es posible que el
hub trate de enviar a velocidades más altas de las que los remotos pueden recibir, lo que provocará que la red de retransmisión por frame elimine
tráfico de forma arbitraria. Sin embargo, los remotos podrían enviar todo a una velocidad agregada superior a la que el hub puede recibir, con lo
que de nuevo se provocará que la red de retransmisión por frame (frame relay) elimine tráfico en forma arbitraria. Cuando hablamos de red de
retransmisión por frame (frame relay), nos referimos a la red del proveedor de servicio (SP) de los switches WAN que ofrecen la conectividad de
PVC de extremo a extremo. Debido a que la nube WAN SP no cuenta con la Capa 3 ni con una inteligencia superior, podrá eliminar tráfico de
VoIP si se infringen los contratos. Por tanto, necesita controlar las velocidades de transmisión en una nube de retransmisión por frame (frame
relay) de manera que pueda controlar qué paquetes se eliminan y cuáles reciben la prestación de servicio prioritario. En la Figura 3 se muestra un
ejemplo de una red típica de retransmisión por frame (frame relay) sin modelado de tráfico.
Figura 3: Red de retransmisión por frame (frame relay)
Ejemplo de modelado de tráfico de retransmisión por frame (frame relay)
En el siguiente ejemplo de configuración se muestra cómo configurar el modelado de tráfico de retransmisión por frame (frame relay):
Ejemplo de configuración 8: Modelado de tráfico de retransmisión por frame (frame relay)
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
!
map-class frame-relay voice
no frame-relay adaptive-shaping
frame-relay cir 256000
frame-relay bc 2560
frame-relay mincir 256000
En este ejemplo, el modelado de tráfico de retransmisión por frame (frame relay) está activado en la interfaz de serie principal 0/1 mientras
que DLCI 128 se coloca en una clase de modelado para voz. La voz de clase de asignación configura un CIR de 256.000 bps y una velocidad
de ráfaga comprometida (Bc) de 2.560 bits. Esta configuración significa que el router enviará 2.560 bits cada 2.560/256.000 segundos (10
ms) y colocará en cola cualquier ráfaga en exceso. El CIR mínimo se define en el mismo valor de CIR y se desactiva el modelado adaptable.
El valor de la ráfaga en exceso (Be) de retransmisión por frame (frame relay) no está definido y, por tanto, el valor predeterminado es 0, lo
que impide cualquier ráfaga sobre CIR. Esta es la configuración recomendada para el modelado de tráfico cuando lleva VoIP.
Compresión de encabezados IP RTP
La compresión de encabezados IP RTP reduce el encabezado IP+UDP+RTP de 40 bytes a un valor de entre 2 y 4 bytes, por lo que se reduce el
ancho de banda necesario por llamada de voz en enlaces de punto a punto. El encabezado se comprime en un extremo del enlace y se
descomprime en el otro. Otro nombre estándar para esta técnica es cRTP, que quiere decir "RTP comprimido". En la Figura 4 se muestra la
funcionalidad de la compresión del encabezado RTP.
Figura 4: Compresión de encabezado RTP
Para configurar la compresión de encabezado IP RTP, tendrá que configurar el comando ip rtp header-compression en la interfaz de serie o el
comando frame-relay ip rtp header-compression en la subinterfaz de retransmisión por frame (frame relay). También puede configurar el
comando de configuración de interfaz ip rtp compression-connections para definir un número máximo de flujos que se comprimirán. Debido a
que cRTP puede hacer un uso intensivo del procesador, usted deberá limitar el número de flujos comprimidos para impedir la disminución del
desempeño del router. El RTP comprimido está recomendado en enlaces de baja velocidad donde el ancho de banda es escaso y hay pocas
llamadas VoIP.
Servicios diferenciados para VoIP
El modelo QoS de la arquitectura de servicios diferenciados (DS) ofrece un mecanismo escalable para clasificar paquetes en grupos o clases que
cuenten con requisitos de QoS similares. En esta sección se describen los DS y se incluyen las siguientes subsecciones:
Información general de DS y DSCP (RFC 2474, RFC 2475)
Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598)
Ejemplo de configuración de marcado basado en la clase DSCP
Información general de DS y DSCP (RFC 2474, RFC 2475)
Las primeras redes IP estaban basadas en el modelo de servicio de mejor esfuerzo, lo que significaba que los retrasos, fluctuaciones, pérdida de
paquetes y asignación de ancho de banda no eran predecibles. Hoy en día, un gran número de redes siguen este modelo de mejor esfuerzo y no
soportan aplicaciones mejoradas que requieren algún tipo de garantía de servicio.
Con el modelo de mejor esfuerzo, los proveedores de servicio no cuentan con medios para ofrecer acuerdos de niveles de servicio (SLA) a sus
clientes que no sea abastecer en exceso la red para enfrentarse a las horas de tráfico más intenso. Los clientes de empresa y los usuarios finales no
tienen manera de ofrecer el tratamiento de prioridad o el ancho de banda garantizado para VoIP. El tráfico se trata de una forma simple, basada en
FIFO, sin aplicación de QoS.
El primer enfoque de arquitectura para ofrecer QoS de extremo a extremo necesitaba que la aplicación señalara sus requisitos de recursos de QoS
(como el ancho de banda y el retraso garantizado) a la red. En un escenario de VoIP, este enfoque arquitectónico significaba que la telefonía IP o
la puerta de enlace de voz necesitaban realizar solicitudes de QoS en cada salto de la red de manera que se asignarían los recursos de extremo a
extremo. Cada salto necesitaba mantener la información del estado de la llamada para determinar cuándo liberar los recursos de QoS para las
otras llamadas y aplicaciones y, en el caso de que hubiera recursos suficientes disponibles, aceptar las llamadas con garantías de QoS. Este
método se denomina "modelo de QoS de servicios integrados". La implementación más común de los servicios integrados utiliza el protocolo de
reserva de recursos (RSVP). RSVP cuenta con algunas ventajas, como el Control de admisión de llamadas (CAC), donde una llamada puede
volver a enrutarse al enviar una señal adecuada a la persona que llama si la red no cuenta con los recursos de QoS disponibles para soportarla. Sin
embargo, RSVP también presenta algunos problemas de escalabilidad, que se tratarán más adelante en este documento.
La arquitectura DS es el modelo de QoS más ampliamente implementado y soportado hoy día. Ofrece un mecanismo escalable para clasificar
paquetes en grupos o clases que cuenten con requisitos de QoS similares y luego ofrece a estos grupos el tratamiento necesario en cada salto de la
red. La escalabilidad proviene del hecho de que los paquetes se clasifican en los bordes de la "nube" o región DS y se marcan de forma adecuada,
de manera que los routers del núcleo de la nube puedan ofrecer QoS basado simplemente en la clase DS. Los seis bits más significativos del byte
ToS de IP se utilizan para especificar la clase DS. El punto de código de servicios diferenciados (DSCP) será el que defina estos seis bits. Los dos
bits restantes en el byte ToS de IP no se utilizan en la actualidad.
En la Figura 5 se muestra cómo el encabezado IP define la clase DS.
Figura 5: Definición del campo de servicios diferenciados
Los servicios diferenciados se describen y se definen en los RFC siguientes:
RFC 2474, definición del campo de servicio diferenciado (campo DS)
RFC 2475, arquitectura para el servicio diferenciado
RFC 2597, grupo PHB de reenvíos garantizados
RFC 2598, reenvío acelerado PHB
RFC 2474 propone una manera de interpretar un campo que siempre ha sido parte de un paquete IP. Tal y como se ha mencionado anteriormente
en este documento, el campo ToS describe un byte completo (ocho bits) de un paquete IP. La precedencia se refiere a los tres bits más
significativos del byte ToS; es decir, [123]45678. (De vez en cuando, el término ToS se utiliza para referirse a los siguientes tres bits:
123[456]78. No obstante, en este documento, para ser coherentes con la especificación RFC original para el encabezado IP (RFC 791), ToS se
refiere al conjunto completo de ocho bits).
Los primeros tres bits de DSCP se utilizan como bits de selector de clase, los cuales se encargan de hacer DSCP compatible con la precedencia IP
porque ésta utiliza los mismos tres bits para determinar la clase. En la Tabla 4 se muestran los valores de los bits de precedencia de IP asignados a
DSCP.
Tabla 4: Precedencia IP para la asignación DSCP
Precedencia IP
Valor del bit de precedencia de IP
Bits DSCP
Clase DSCP
5
101
101000
Reenvío acelerado
4
100
100000
Reenvío asegurado 4
3
011
011000
Reenvío asegurado 3
2
010
010000
Reenvío asegurado 2
1
001
001000
Reenvío asegurado 1
0
000
000000
Mejor esfuerzo
Los dos bits siguientes se usan para definir la preferencia de eliminación. Por ejemplo, si el tráfico en la Clase 4 (los primeros tres bits son 100)
supera una determinada velocidad contratada, los paquetes excedentes podrían volver a marcarse de manera que se alcance la preferencia de
eliminación en lugar de eliminarse. Si se produjera la congestión en la nube DS, los primeros paquetes que se eliminarían serían los paquetes de
"preferencia de eliminación alta". Esto es parecido al marcado del bit DE en retransmisión por frame (frame relay) y el del bit CLP en ATM.
Estos mecanismos permiten que la red de Capa 2 tome decisiones de eliminación inteligentes para el tráfico que no cumpla con las normas en los
períodos de congestión. DS permite una acción similar sobre una red IP. El sexto bit debe definirse en 0 para indicar a los dispositivos de red que
las clases se definieron según la norma DS.
La arquitectura DS define un grupo de acondicionadores de tráfico que se usan para limitar el tráfico en una región DS y colocarlo en las clases
DS adecuadas. Los medidores, marcadores, modeladores y eliminadores son acondicionadores de tráfico. Los medidores son, básicamente,
reguladores de tráfico. El control de tráfico basado en la clase (que se configura mediante el comando police policy-map configuration debajo
de una clase en la?CLI de QoS modular) es una implementación compatible con DS de un medidor. Puede usar el marcado basado en la clase
para definir DSCP y el modelado basado en la clase como el modelador. La Random Early Detection ponderada (WRED) es un mecanismo de
eliminación soportado, aunque no debería invocar WRED en la clase VoIP. El comportamiento por salto (PHB) describe lo que debería
experimentar una clase DS en términos de pérdida, retraso y fluctuación. Un PHB determina cómo se asignará el ancho de banda, se restringirá el
tráfico y se eliminarán los paquetes durante la congestión.
En DS se definen tres PHB según el comportamiento de reenvío necesario:
Clase de mejor esfuerzo: los bits de selector de clases se definen en 000
PHB de reenvío asegurado: bits de selector de clases definidos en 001, 010, 011 o 100
PHB de reenvío acelerado: bits de selector de clases definidos en 101
La norma de reenvío asegurado (AF) especifica las cuatro clases de ancho de banda garantizado y describe el tratamiento que cada una debería
recibir. También especifica los niveles de preferencia de eliminación, con un resultado total de 12 clases AF posibles, tal y como se muestran en
la Tabla 5.
Tabla 5: Clases posibles de reenvío asegurado
Niveles de preferencia de eliminación
Clase AF1
Clase AF2
Clase AF3
Clase AF4
Precedencia de eliminación baja
001010
010010
011010
100010
Precedencia de eliminación media
001100
010100
011100
100100
Precedencia de eliminación alta
001110
010110
011110
100110
Es muy probable que utilice las clases de reenvío asegurado para el tráfico de datos que no necesite tratamiento de prioridad y que esté basado en
gran medida en TCP. El reenvío acelerado coincide en gran medida con los requisitos de QoS de VoIP.
Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598)
El reenvío acelerado (EF) está diseñado para las aplicaciones sensibles al retraso que necesiten ancho de banda garantizado. Un marcado EF
garantiza el servicio prioritario al reservar una cantidad mínima de ancho de banda que pueda usarse para el tráfico de alta prioridad. En EF, la
velocidad de salida (o el ancho de banda de prioridad configurado) debe ser superior o igual a la suma de las velocidades de ingreso de manera
que no haya congestión para los paquetes marcados como EF. El comportamiento EF se implementa mediante la cola de prioridad estricta en la
cola de latencia baja (LLQ). Se garantizará el ancho de banda constante para el tráfico que pertenezca a la clase EF, pero si en el mismo momento
hay congestión, los paquetes que no cumplan las normas que superen la velocidad de prioridad especificada se eliminarán para asegurar que los
paquetes en las otras colas que pertenezcan a clases distintas no se queden sin ancho de banda. El valor DSCP recomendado para EF es 101110
(46). Los primeros tres bits de este valor EF se corresponden con la precedencia IP 5, que es a su vez el ajuste recomendado del comando de
configuración del par de marcado ip precedence para el tráfico de VoIP. Por tanto, si los dispositivos IP de la red pueden reconocer la
precedencia IP o DSCP para la clasificación y el marcado, podrá proporcionar QoS de extremo a extremo.
Ejemplo de configuración de marcado basado en la clase DSCP
La arquitectura DS especifica cómo clasificar, marcar, regular y modelar el tráfico que entra en una región DS y cómo tratar las diferentes clases
en cada salto en la región DS. En el borde DS, todos los paquetes IP se marcan con el DSCP adecuado de manera que se puede ofrecer QoS
según el DSCP dentro de la región DS. El siguiente ejemplo de configuración muestra cómo configurar el marcado DSCP en el borde mediante el
marcado basado en la clase:
Ejemplo de configuración 9: Marcado basado en la clase de DSCP
access-list 100 permit udp any any range 16384 32000
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
!
class-map voip
match access-group 100
class-map webtraffic
match access-group 101
!
policy-map dscp_marking
class voip
set ip dscp 46
#EF Class
class webtraffic
set ip dscp 26
#AF Class
!
interface Ethernet0/0
service-policy input dscp_marking
En este ejemplo, todo el tráfico que entra en una interfaz Ethernet 0/0 se inspecciona y se clasifica según las asignaciones de clasevoip
y webtraffic. El comando de configuración global de asignación de políticas define el DSCP en el tráfico de clase voip a 46 (101110 para
EF) y el de webtraffic en 26 (011010 para AF3).
Ahora es posible definir la colocación en cola y otros parámetros de QoS para que coincidan con DSCP en el resto de la región DS.
En las restantes secciones de este documento, se hará coincidir el tráfico de precedencia IP 5 como VoIP y el tráfico de precedencia IP 3 como
HTTP (tráfico web), mientras que el resto del tráfico se dirigirá a la clase predeterminada. De igual forma, se podría utilizar DSCP 46 para VoIP
y DSCP 26 para HTTP. Podríamos usar varios mecanismos de clasificación y marcado pero para mantener la coherencia y la simplicidad,
usaremos la precedencia IP.
Protocolo de reserva de recursos
El protocolo de reserva de recursos (RSVP) es una implementación de la arquitectura de servicios integrados para QoS (RFC 2205). Cuando se
introdujo VoIP, RSVP fue considerado inmediatamente como un componente fundamental que ofrecería control de admisión y QoS para flujos
de VoIP. Sin embargo, la manera en que se integraron RSVP y H.323 previamente no ofreció control de admisión ni QoS adecuado para los
flujos de voz. Se han realizado varias mejoras para corregir estas limitaciones. Ahora, RSVP puede usarse para implementar el CAC y para
señalar un QoS deseado que ofrecerá una buena calidad de voz de extremo a extremo aún cuando haya congestión.
En esta sección, se describe RSVP (en general) con especial atención a un subconjunto particular de plataformas, topologías y protocolos.
También asumimos que está usando H.323 como el protocolo de sesión para una red de VoIP basada en la puerta de enlace. Esta sección incluye
a su vez las siguientes subsecciones:
Información general de RSVP
Información general de RSVP para CAC
Implementación de CAC basada en RSVP
Configuración de recursos de puertas de enlace locales si CAC falla
Uso de RSVP con LLQ
Implementación del soporte de RSVP para LLQ
Información general de RSVP
La implementación inicial de RSVP para VoIP tenía dos limitaciones. La primera era que el CAC no podía implementarse con RSVP porque el
proceso de reserva no estaba sincronizado con la señalización de la llamada de voz. La llamada se produciría aunque la reserva de RSVP hubiera
fallado o no se hubiera completado. La segunda limitación era que existía la posibilidad de que una reserva de RSVP correcta no ofreciera una
buena calidad de voz durante los períodos de congestión de red. RSVP creó un flujo reservado de cola-por-tráfico dentro del sistema WFQ y
confió en ese sistema para garantizar un retraso limitado. Sin embargo, en algunos casos WFQ no era capaz de ofrecer un retraso limitado
aceptable para la voz. RSVP tenía que ser capaz de usar la cola de prioridad en LLQ para garantizar un retraso limitado que no afectara a la
calidad de la voz. Además, no había soporte para RSVP en ATM ni en los PVC de retransmisión por frame (frame relay) modelados.
Debe implementar RSVP para mejorar la QoS de VoIP allí donde sólo pueda tener un impacto positivo en la calidad y funcionalidad. Las
ventajas de usar RSVP supera los costes (gestión, tara e impacto del desempeño) pero sólo donde haya ancho de banda limitado y frecuente
congestión de red. Algunos entornos IP cuentan con ancho de banda suficiente para garantizar la QoS adecuada sin tener que implementar el
CAC para cada llamada.
En el software Cisco IOS se introdujeron los siguientes cuatro mecanismos para manejar el CAC basado en recursos:
Repliegue de PSTN: este método se basa en el sondeo de la red para medir el retraso, la fluctuación y las pérdidas a fin de estimar los
problemas potenciales de voz que la llamada puede sufrir. (Este problema potencial se denomina "factor de defecto de planificación
calculado" (ICPIF) y se explica en ITU-T G.113). Gracias a este mecanismo, podrá definir varios umbrales de manera que las llamadas se
rechacen si una red IP está congestionada.
CAC definido en recursos de puertas de enlace locales como CPU, memoria y el número de llamadas: gracias a este método, puede
configurar umbrales que activarán diferentes acciones, como devolución y rechazo de llamadas, o reproducción de un mensaje.
Gestión de ancho de banda mediante el control de acceso H.323: en este método, podrá configurar una cantidad máxima de ancho de banda
que los controles de acceso podrán asignar a las llamadas.
RSVP.
En este documento, sólo trataremos el uso de RSVP para el CAC.
Información general de RSVP para CAC
El uso de RSVP para el CAC de VoIP necesita la sincronización de la señalización de la configuración de la llamada y la señalización de RSVP.
Esta sincronización garantiza que el teléfono de la parte llamada sólo suene después de que los recursos de la llamada se hayan reservado. Esta
sincronización también proporciona a las puertas de enlace de voz el control de la acción que hay que realizar antes de que la configuración de la
llamada pase a la etapa de alerta si la reserva falla o no puede completarse dentro de un período de tiempo predefinido. La llamada de voz
activará dos reservas de RSVP porque los mecanismos de reserva y control de admisión ofrecidos por RSVP son unidireccionales. Cada puerta de
enlace de voz es responsable de iniciar y mantener una reserva hacia la otra puerta de enlace de voz. El CAC para una llamada VoIP falla si falla
al menos una de las reservas. En la Figura 6 se muestra la secuencia de paquetes intercambiados entre las puertas de enlace durante una
configuración de llamada si se usa RSVP en la reserva de recursos.
Figura 6: Configuración de llamada con RSVP activado
En la Figura 6, una puerta de enlace de origen (OGW) inicia una llamada hacia una puerta de enlace de destino (TGW). La puerta de enlace de
origen envía un mensaje SETUP de H.323 a la puerta de enlace de destino para iniciar la llamada. Dicho mensaje lleva la QoS que la puerta de
enlace de origen considera aceptable para la llamada. La puerta de enlace de destino responde con un mensaje CALL PROCEEDING de H.323.
Tanto el puerta de enlace de origen como la de destino inician una solicitud de reserva enviando un mensaje PATH de RSVP. Los flujos de
paquete de ambas reservas son independientes entre ellos a menos que uno de ellos falle. La puerta de enlace de destino bloquea el proceso de
configuración de llamada que está a la espera de los resultados de la reserva. La puerta de enlace de destino controla la decisión de admisión de la
llamada y necesita que se le notifique de que las reservas en ambas direcciones son correctas. La puerta de enlace de destino descubre que la
reserva se ha realizado correctamente cuando recibe el mensaje RESV de RSVP. La puerta de enlace de destino detecta que la reserva de la
puerta de enlace de origen se ha realizado correctamente cuando recibe un mensaje RESV CONFIRMATION de RSVP procedente de la puerta
de enlace de origen. En este punto, la puerta de enlace de destino permite que la configuración de llamada continúe y envía un mensaje
ALERTING de H.323 a la puerta de enlace de origen una vez que se le notifique que el lado llamado se encuentra en estado de alerta. Se iniciará
una desconexión normal cuando se envía un mensaje RELEASE COMPLETE de H.323 después de que se haya conectado la llamada. En este
punto, las puertas de enlace cerrarán las reservas enviando mensajes RSVP PATH TEAR y RESV TEAR.
Si falla al menos una de las reservas de RSVP, podrá configurar una puerta de enlace de voz para realizar las acciones siguientes:
La puerta de enlace de voz puede informar acerca del fallo de la llamada al usuario o al switch que la ha entregado.
La llamada puede volver a enrutarse a través de otra ruta.
Se puede conectar la llamada con la QoS de mejor esfuerzo.
Este último comportamiento es posible debido a que la puerta de enlace de destino sabe qué QoS es aceptable para la llamada desde su propia
configuración y para el valor incluido por la puerta de enlace de origen en el mensaje SETUP de H.323. Si las puertas de enlace de destino y
origen solicitan QoS que no sea de mejor esfuerzo y, al menos, una reserva falla, la llamada sólo se realizará como mejor esfuerzo si las puertas
de enlace de origen y destino desean aceptar el servicio de mejor esfuerzo. La liberación de la llamada y el reenrutamiento son posibles si una de
las dos puertas de enlace de voz no aceptan el servicio de mejor esfuerzo. Si configura la puerta de enlace para rechazar la llamada e informar el
fallo, los troncales de CAS y las líneas analógicas generan una señal de ocupado rápido. En los troncales CCS PRI, se generará un mensaje
DISCONNECT de Q.931 y la causa que indica que QoS no está disponible (49).
En la Figura 7 se muestran los detalles de una llamada que se ha rechazado porque se ha producido un error en la reserva iniciada desde la puerta
de enlace de destino.
Figura 7: Fallo de llamada en el CAC de RSVP debido a un fallo en la reserva de puerta de enlace de destino
Implementación de CAC basada en RSVP
Tal y como se ha mencionado anteriormente, debería implementar RSVP para mejorar la QoS de VoIP allí donde sólo pueda tener un impacto
positivo en la calidad y funcionalidad. Las ventajas de usar RSVP superan los costes sólo donde el ancho de banda es limitado. Recomendamos el
uso de la versión 12.1(5)T o superior de Cisco IOS si desea implementar CAC para VoIP mediante RSVP.
Debe realizar los siguientes tres pasos básicos para configurar CAC para las llamadas VoIP mediante RSVP:
Activar la sincronización entre RSVP y la señalización de llamadas. Esta sincronización está activada en forma predeterminada cuando la
versión 12.1(5)T o posterior de Cisco IOS se está ejecutando.
Configure las puertas de enlace de voz en ambos lados de los pares de marcado de VoIP para solicitar una QoS particular mediante RSVP.
Active RSVP y especifique el ancho de banda máximo en todos los enlaces que atraviesan los paquetes de voz donde es probable que
ocurra la congestión.
En el siguiente ejemplo de configuración se muestra cómo configurar CAC para llamadas VoIP mediante RSVP:
Ejemplo de configuración 10: Implementación de CAC mediante SVP
hostname LongBay
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Ethernet0/0
ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
bandwidth 1536
ip address 10.10.1.1 255.255.255.0
encapsulation ppp
ip tcp header-compression iphc-format
ip rtp header-compression iphc-format
ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
ip route 0.0.0.0 0.0.0.0 10.10.1.2
!
voice-port 1/0:23
!
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
!
end
Este ejemplo muestra una configuración de puerta de enlace de voz completa que describe los comandos para configurar CAC mediante
RSVP. La puerta de enlace de voz puede actuar como una puerta de enlace de origen y destino con esta configuración. No hemos priorizado
la señalización de la voz en este ejemplo.
La configuración predeterminada del par de marcado solicita y acepta QoS de mejor esfuerzo para llamadas VoIP. Esto se traduce en que la
puerta de enlace no inicia una reserva de RSVP para la llamada porque IP ofrece el servicio de mejor esfuerzo en forma predeterminada. Las
otras dos alternativas de servicio son QoS de carga controlada o retraso garantizado. Estos servicios exigen la señalización de RSVP. Se solicitan
mediante el comando de configuración del par de marcado req-qos. La QoS aceptable controla cuán estrictos o permisivos deberían ser los
criterios de CAC. Los controles de QoS aceptables se configuran mediante el comando de configuración del par de marcado acc-qos.
Recomendamos que configure la puerta de enlace de origen y la de destino para solicitar y aceptar el retraso garantizado.
En ocasiones, puede configurar la coincidencia del par de marcado implícito en una puerta de enlace de destino para solicitar y aceptar la QoS de
mejor esfuerzo. Este par de marcado surte efecto cuando no hay una coincidencia explícita del par de marcado.
Configuración de recursos de puertas de enlace locales si CAC falla
Tal y como se ha mencionado anteriormente, puede configurar una puerta de enlace de voz para que realice distintas acciones si el control de
admisión falla. La primera alternativa es que la señal de las puertas de enlace envíen una señal al usuario o al switch que ha entregado la llamada
con una señal de ocupado rápido o con una causa de desconexión. Si la llamada se ha entregado a la puerta de enlace mediante un switch de
ISDN, podrá ajustar la causa de desconexión Q.931 para garantizar que el switch maneje las llamadas correctamente. En forma predeterminada,
se devuelve la causa de QoS no disponible (49) cuando se produce un error de CAC en una llamada de ISDN debido a la QoS solicitada y
aceptable configurada. Puede modificar esta causa con los comandos de configuración de interfaz isdn network-failure-cause o isdn
disconnect-cause. La implementación actual del comando isdn network-failure-cause anula el valor configurado mediante el comando isdn
disconnect-cause.
El siguiente ejemplo de configuración muestra cómo configurar los recursos de puerta de enlace locales si se produce un error en CAC al ajustar
la causa de desconexión Q.931:
Ejemplo de configuración 11: Ajuste de la causa de desconexión Q.931
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn network-failure-cause 42
isdn incoming-voice voice
no cdp enable
!
En este ejemplo, el router envía un mensaje DISCONNECT de Q.931 con una causa que indica que hay congestión en el equipo de
conmutación (42) cuando se produce un error de CAC en una llamada ISDN en el tramo de VoIP.
La segunda opción es permitir que la puerta de enlace vuelva a enrutar la llamada a través de otra ruta. Si el par de marcado que coincide con la
llamada forma parte de un grupo de búsqueda, se probarán otros pares de marcado en ese grupo según el comando de configuración del par de
marcado preference. De esta manera, se permite que implemente diferentes tipos de enrutamiento de llamada en la puerta de enlace que
considera QoS en las redes IP.
En el siguiente ejemplo de configuración se muestra cómo configurar los recursos de puertas de enlace locales al volver a enrutar llamadas en la
puerta de enlace si se produce un error de CAC:
Ejemplo de configuración 12: Reenrutamiento de llamadas en la puerta de enlace
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
preference 0
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
dial-peer voice 400 voip
preference 2
destination-pattern 3......
session target ipv4:10.23.45.2
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
dial-peer voice 500 pots
preference 5
destination-pattern 3......
no digit-strip
direct-inward-dial
port 1/1:23
!
Este ejemplo muestra una implementación del reenrutamiento de llamadas en la puerta de enlace. Las llamadas a números de siete dígitos
que comiencen con el dígito 3, prueban dos puertas de enlace de voz en primer lugar. Las llamadas se enrutan mediante la PSTN a través del
puerto de voz 1/1:23 si se producen errores en las llamadas VoIP debido al CAC o a cualquier otra razón.
La tercera posibilidad, disponible en las versiones de Cisco IOS posteriores a la 12.1(5)T, es configurar las puertas de enlace para seguir con la
llamada aún cuando se produzcan errores en las reservas de RSVP. Esta opción, sin embargo, no ofrece una mejora sustancial frente a la
funcionalidad de versiones anteriores de Cisco?IOS. El único beneficio que ofrece es que, en caso de una reserva válida de RSVP, la llamada no
se produce hasta que no se haya establecido la reserva.
Tal y como se ha mencionado anteriormente, se puede producir un error de la llamada en el control de admisión si falla al menos una de las dos
reservas de RSVP necesarias para la llamada. Para cada reserva de RSVP, el control de admisión se realiza en todas las interfaces donde se haya
activado RSVP usando el comando de configuración de interfaz ip rsvp bandwidth. Puede configurar dos valores con el comando ip rsvp
bandwidth: el ancho de banda máximo total reservado y el ancho de banda máximo por reserva. El ancho de banda máximo total está limitado
en forma predeterminada a no más del 75 por ciento del ancho de banda total de la interfaz. Puede modificar ese límite con el comando de
configuración de interfaz max-reserved-bandwidth. Las excepciones a la limitación de ancho de banda máximo total son PVC de retransmisión
por frame (frame relay) y ATM. En el caso de PVC de retransmisión por frame (frame relay), al ancho de banda máximo reservable es el CIR
mínimo o, si no está configurado, la mitad del CIR. Para los PVC ATM, el ancho de banda máximo reservable es el 75 por ciento de la velocidad
mínima de celda de salida de la velocidad de bits disponible, cerca de la SCR de salida de VBR en tiempo real o la velocidad media de VBR en
tiempo real, sea cual sea la que esté configurada. El ancho de banda total disponible para las reservas de RSVP puede ser inferior si ya tiene
ancho de banda reservado usando CBWFQ o LLQ mediante MQC. El administrador de ancho de banda se asegura de que la interfaz o el ancho
de banda de PVC no ha recibido suscripciones en exceso durante la operación del router.
Nota Esta comprobación no se realiza durante la configuración del router.
Debería configurar el ancho de banda máximo por reserva que no sea inferior al que el códec necesita más toda la tara de protocolo excepto la de
la Capa 2. En la Tabla 6 se muestran los valores más bajos que puede usar para códecs diferentes. Recuerde que estos valores no darán cuenta de
los ahorros de ancho de banda introducidos por cRTP o la detección de la actividad de voz (VAD). La secuencia de voz real puede usar menos
ancho de banda pero el sistema usará el peor ancho de banda.
Tabla 6: Ancho de banda reservado por RSVP por llamada VoIP
Códec
Ancho de banda reservado por llamada VoIP (kbps)
G711alaw
80
G711ulaw
80
G723ar53
22
G723ar63
23
G723r53
22
G723r63
23
G726r16
32
G726r24
40
G726r32
48
G728
32
G729br8
24
G729r8
24
GSMEFR
29
GSMFR
30
Una consideración que hay que tener en cuenta al implementar RSVP para VoIP es el impacto de la reserva de recursos en el retraso posterior al
marcado. La implementación del CAC de VoIP basada en RSVP depende de una confirmación o rechazo del mensaje de la reserva solicitada. El
tiempo que se ha tomado para reservar los recursos se añade al retraso posterior al marcado, que debería mantenerse tan bajo como sea posible en
la mayoría de los casos. Los paquetes de RSVP se transportan dentro de datagramas IP y son no confiables por naturaleza. Si se pierde un
paquete de RSVP durante la configuración de reserva inicial, deberá caducar un temporizador de actualización de RSVP antes de que el paquete
perdido se reenvíe. Debido a que el temporizador de actualización se define normalmente en decenas de segundos, la situación en la que se puede
añadir un retraso posterior al marcado no es aceptable para el usuario. El comando de configuración global call rsvp-sync resv-timer permite
controlar el tiempo máximo que la puerta de enlace de destino esperará el resultado de las solicitudes de reserva de RSVP. El valor
predeterminado de este temporizador es 10 segundos. Puede definirlo en un valor de 1 a 60 segundos de acuerdo con la expectativa de un retraso
de marcado posterior.
Uso de RSVP con LLQ
Los flujos que soliciten una QoS concreta mediante RSVP pueden sacar partido de las alternativas de colocación en cola disponibles en LLQ, el
cual tiene dos componentes principales: una cola de prioridad (PQ) y un sistema CBWFQ. Las implementaciones anteriores de RSVP se basan en
WFQ para ajustarse a los requisitos de QoS correspondientes al tráfico sensible al retraso. Se creó una cola reservada con un peso inferior cuando
se instaló la reserva de RSVP. Sin embargo, WFQ podría no ajustarse a los requisitos de retraso del tráfico de voz con lo que las llamadas de voz
que utilizan RSVP no podrían sacar partido a la PQ disponible en todo LLQ.
En la versión 12.1(3)T y posteriores de Cisco IOS, existe un perfil de prioridad basado en características de tráfico de manera que algunos flujos
puedan sacar partido de la PQ estricta en LLQ. Cuando se recibe una solicitud de reserva de RSVP en una interfaz donde haya activado WFQ, la
especificación de flujo de tráfico (TSpec) se compara con el perfil para decidir si ese flujo debería sacar partido de la PQ o si la cola debería
reservarse en el sistema WFQ. La TSpec es la descripción de tráfico transportada en mensajes de RSVP. Esta descripción de tráfico se realiza en
términos de una cubeta con ficha (velocidad de ficha r, más un tamaño de cubeta b) y algunos parámetros adicionales (velocidad máxima p,
unidad mínima regulada m y el tamaño máximo del paquete M). El perfil de PQ se define en función de la velocidad de ficha, el tamaño de
cubeta y una relación de velocidad máxima opcional con la velocidad de ficha. Las reservas de flujo con una TSpec que no superan las definidas
en el perfil de PQ usarán la PQ. Aquellos flujos con una TSpec que supera al menos un parámetro definido en el perfil obtendrán una cola
reservada en el sistema WFQ. El perfil de prioridad le permite clasificar los flujos de prioridad basándose en las características del tráfico y no
sólo en el protocolo de transporte y el puerto. En la Figura 8 se muestra la estructura de LLQ para una interfaz en la que el tráfico se clasifica en
colas diferentes usando varios métodos, incluido RSVP.
Figura 8: Soporte de RSVP para LLQ en las interfaces de punto a punto
En la versión 12.1(5)T de Cisco IOS se presentó el soporte de RSVP para LLQ en los PVC de retransmisión por frame (frame relay). En este
caso, cada PVC cuenta con su propia estructura de colocación en cola con una PQ y un sistema CBWFQ. En la interfaz, se configura una cola
FIFO a menos que haya activado la fragmentación FRF.12. En ese caso, se configurará un sistema FIFO dual con una cola de alta prioridad y otra
de baja. La primera recibirá el tráfico de la PQ de todos los PVC más el tráfico de control de la Capa 2. La segunda recibirá todo el tráfico de
todos los PVC. Recuerde que se necesita el modelado de tráfico de retransmisión por frame (frame relay) (FRTS) para los circuitos de
retransmisión por frame tanto si la fragmentación FRF.12 está activada como si no. FRTS ofrece el mecanismo de contrapresión para detectar la
congestión por PVC. El soporte para los PVC ATM está disponible en la versión 12.2(1)T de Cisco IOS.
Implementación del soporte de RSVP para LLQ
El soporte de RSVP se activa para LLQ en forma predeterminada para los flujos de voz en interfaces donde se activan RSVP y WFQ. No es
necesario que configure en forma explícita las colas de prioridad para los paquetes de voz. Puede configurar un perfil de cola de prioridad
personalizado mediante el comando de configuración global ip rsvp pq-profile. Configurar el perfil como ip rsvp pq-profile voice-like restaura
el comportamiento predeterminado. El perfil de cola de prioridad predeterminado utiliza una velocidad de ficha de 12.288 bytes por segundo
(aproximadamente 98 kbps), un tamaño de cubeta de 592 bytes y una velocidad máxima igual al 110 por ciento de la velocidad de ficha (13.516
bytes por segundo o aproximadamente 108 kbps). Estos valores de parámetros soportan todas las configuraciones de códec posibles en las puertas
de enlace de voz que ejecuten el software Cisco IOS. La puerta de enlace de voz de Cisco configurada para reservar recursos mediante RSVP
inferirá la TSpec correcta en forma exclusiva a partir del códec utilizado en el par de marcado. No es posible controlar los valores de TSpec
mediante CLI. No se tendrá en cuenta ninguna otra característica de almacenamiento de ancho de banda (como VAD). Algunas revisiones de
Microsoft NetMeeting para Windows 98 y Windows 2000 (que utilizan RSVP) señalan un tamaño de cubeta en la TSpec que no es compatible
con estos valores predeterminados. Este problema afecta a Microsoft NetMeeting en las llamadas que utilicen códecs que necesiten 32 kbps o
más. En esos casos, tendrá que crear un perfil predeterminado para coincidir con los parámetros señalados por Microsoft Windows.
El siguiente ejemplo de configuración muestra cómo configurar el soporte de RSVP para LLQ en un circuito de retransmisión por frame (frame
relay) que cuenta con dos PVC:
Ejemplo de configuración 13: soporte de RSVP para LLQ en los PVC de retransmisión por frame (frame relay)
hostname LongBay
!
isdn switch-type primary-ni
call rsvp-sync
!
interface Serial0/0
bandwidth 1536
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
ip address 10.10.1.2 255.255.255.0
frame-relay interface-dlci 16
class VoIPoFR
ip rsvp bandwidth 48 24
!
interface Serial0/0.2 point-to-point
ip address 10.10.2.2 255.255.255.0
frame-relay interface-dlci 17
class VoIPoFRip
rsvp bandwidth 48 24
!
ip rsvp pq-profile voice-like
!
map-class frame-relay VoIPoFR
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay mincir 64000
frame-relay fair-queue
frame-relay fragment 80
!
En este ejemplo, WFQ está activado en los PVC y desactivado en la interfaz física. Cada PVC cuenta con una cola de prioridad para el
tráfico de voz. La interfaz física cuenta con una estructura de cola FIFO dual. FRTS está activado y sus parámetros definidos en la clase de
asignación VoIPoFR.
Una de las implicaciones importantes del soporte de RSVP para LLQ es que le permite clasificar el tráfico de voz según sus características de
tráfico en lugar de en el protocolo de transporte (UDP) y el número de puerto (16384 a 32767). El funcionamiento adecuado de LLQ se basa en la
suposición de que la cola de prioridad sólo se usa para el tráfico que se comporta bien (como la voz) con una velocidad predecible y un tamaño de
ráfaga muy bajo. La clasificación basada en el protocolo de transporte y los puertos podrían permitir tráfico intermitente y poco importante en la
cola de prioridad, lo que podría afectar a la calidad de las llamadas de voz existentes y al desempeño del tráfico que utilice el sistema WFQ.
Tendrá que tener en cuenta los efectos del tráfico intermitente o poco importante cuando defina un perfil de cola de prioridad personalizado. Debe
comprender todas las implicaciones en otros tipos de tráfico, en concreto, cuándo el perfil de PQ podría dejar entrar flujos con grados de
intermitencia en la cola de prioridad. El soporte de RSVP para LLQ da prioridad a los paquetes de voz pero no está pendiente de la señalización
de voz. Quizá no sea posible iniciar nuevas llamadas durante períodos de mucha congestión debido a la pérdida de paquetes de señalización. Para
afrontar esta situación, puede reservar una cantidad de ancho de banda explícitamente para señalar paquetes mediante MQC. También podrá
marcar los mensajes de RSVP para un tratamiento especial usando el comando de configuración de interfaz ip rsvp signaling dscp.
En el siguiente ejemplo de configuración, se priorizan los paquetes de voz mediante RSVP. A la señalización se le garantiza un mínimo de ancho
de banda durante períodos de congestión a través de MQC:
Ejemplo de configuración 14: Soporte de RSVP para LLQ + QoS para la señalización del tráfico
hostname LongBay
!
class-map h323
match access-group 101
!
policy-map VOIP_SIG
class h323
set ip dscp 34
bandwidth 96
class class-default
fair-queue
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Ethernet0/0
ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
bandwidth 1536
ip address 10.10.1.1 255.255.255.0
encapsulation ppp
ip tcp header-compression iphc-format
ip rtp header-compression iphc-format
service-policy output VOIP_SIG
ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
access-list 101 permit tcp any eq 1720 any
access-list 101 permit tcp any any eq 1720
!
voice-port 1/0:23
!
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
En este ejemplo, la lista de acceso 101 coincide con el tráfico de señalización H.323 hacia y desde el puerto TCP 1720. Este tráfico se ubica
en la clase h323, que tiene garantizada 96 kbps de ancho de banda usando LLQ. Con la configuración de RSVP se puede dar prioridad a la
carga útil de voz.
QoS de VoIP sobre líneas alquiladas (mediante PPP)
En esta sección se describe cómo configurar VoIP en una red típica en la que los enlaces WAN de baja velocidad se utilizan para transportar
tráfico de datos y voz. Incluye las siguientes subsecciones:
VoIP sobre escenario de líneas alquiladas (mediante PPP)
Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP)
VoIP sobre escenario de líneas alquiladas (mediante PPP)
Una aplicación típica de VoIP sería para una gran empresa en la que se usaría la infraestructura WAN existente para el tráfico de datos con objeto
de transportar las llamadas de voz entre sus oficinas principales y las sucursales. En la Figura 9 se muestra un entorno de red de VoIP típico en el
que se utilizan los enlaces WAN de baja velocidad para llevar tráfico de voz y de datos.
Figura 9: Entorno de red de VoIP típico
En el caso de enlaces WAN de baja velocidad que no cuenten con los recursos para prestar servicio al tráfico de voz, se acentuarán los problemas
tales como los retrasos, fluctuaciones y pérdidas. En este entorno de red concreto, los siguientes factores pueden contribuir a que la calidad de la
voz sea deficiente:
Los paquetes de datos de gran tamaño enviados antes que los de voz provocan largos retrasos.
Los paquetes de datos de longitud variable enviados antes que los paquetes de voz hacen que los retrasos sean impredecibles, lo que origina
fluctuaciones.
Un ancho de banda reducido hace que el RTP combinado de 40 bytes, UDP y encabezado IP de un paquete VoIP de 20 bytes sea todo un
derroche.
Un ancho de banda reducido provoca enormes retrasos y pérdidas porque el enlace se congestiona con frecuencia.
Muchas técnicas de QoS populares que prestan un buen servicio al tráfico de datos, como WFQ y RED, son ineficaces para las aplicaciones
de voz:
Si aplica WFQ tanto a la voz como a los datos, conforme el número de flujos de aplicaciones de datos y voz aumenta por el enlace, el
WFQ basado en flujo asignará cada vez menos ancho de banda a cada flujo. A diferencia del tráfico de datos elástico que se adapta al
ancho de banda disponible, la calidad de voz se vuelve inaceptable después de demasiadas caídas y retrasos.
RED está específicamente diseñado para el tráfico TCP. VoIP viaja por encima de UDP. Por tanto, cuando sea posible, debería
clasificarse el tráfico de voz y de datos en categorías independientes y RED debería aplicarse a los datos pero no a la voz.
Además, cada enlace o parte del equipo en la ruta de VoIP añade retraso a la transmisión del paquete de voz. La posibilidad de pérdida del
paquete de voz también aumenta cuando el tráfico de voz se desplaza una distancia mayor y por encima de más saltos en la red. Normalmente, las
conexiones WAN de baja velocidad son los enlaces más débiles.
Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP)
En circunstancias normales, el equipo de red y las estaciones finales no pueden diferenciar entre los requisitos de los paquetes de voz en tiempo
real y el tráfico de datos estándar. Esto podría resultar en una pérdida considerable de calidad de la conversación. Para garantizar la calidad de la
voz, debe clasificar el tráfico de datos y de voz en distintas categorías y proporcionar manejo de prioridad al tráfico de voz en una estructura
básica de red de datos compartidos. El manejo de prioridad del tráfico de voz minimiza los retrasos y las pérdidas y, cuando es posible,
proporciona al tráfico de voz un desempeño de transmisión predecible. En el caso de los enlaces PPP, recomendamos las siguientes
características de QoS:
Clasificación de paquetes mediante MQC
Marcado basado en clases (en el borde DS)
Manejo de prioridad mediante LLQ
CRTP: necesario sólo en enlaces de baja velocidad con un número bajo de llamadas para la optimización del ancho de banda
MP LFI: necesario sólo en enlaces de baja velocidad (por debajo de 1,2 Mbps) para garantizar que el tiempo de transmisión de un
fragmento sea inferior a 10 ms
El siguiente ejemplo de configuración muestra una configuración completa con todas las características de QoS enumeradas anteriormente
activadas:
Ejemplo de configuración 15: QoS para VoIP sobre los enlaces WAN PPP
Comandos
Descripción
class-map voip
match ip precedence 5
!
Crea la clase voip para el tráfico de voz que ha sido marcado con la precedencia IP 5
mediante uno de los métodos de marcado disponibles.
class-map webtraffic
match ip precedence 3
!
Crea la clase webtraffic para el tráfico web que ha sido marcado con la precedencia IP 3
mediante uno de los métodos de marcado disponibles.
policy-map llq
class voip
priority 64
class webtraffic
bandwidth 64
class class-default
fair-queue
!
Define la asignación de políticas de QoS llq: el tráfico de clase voip consigue la
prioridad y está limitado a 64 kbps durante la congestión. A los paquetes de clase
webtraffic se les garantizan 64 kbps. El resto del tráfico comparte el ancho de banda
restante.
interface Serial1/0
bandwidth 256
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 1
!
Conecta la interfaz de serie 1/0 a la interfaz de enlaces múltiples en el grupo 1. (Para los
anchos de banda de enlaces por encima de 1,2 Mbps, no se necesitará LFI de PPP de
enlaces múltiples ni cRTP. En ese caso, la dirección IP y la declaración de política de
servicio irían bajo la configuración de la interfaz de serie).
interface Multilink1
ip address 10.1.1.1 255.255.255.252
bandwidth 256
!
Configura LFI de PPP de enlaces múltiples para enlaces inferiores a 1,2 Mbps.
ip rtp header-compression iphc-format
ip tcp header-compression iphc-format
!
Configura cRTP para reducir los requisitos de ancho de banda de cada llamada de voz.
ppp multilink
ppp multilink fragment-delay 10
Permite un tamaño de fragmentación de 10 ms.
Permite el entrelazado de paquetes y fragmentos.
multilink-group 1
service-policy output llq
Conecta la interfaz de enlaces múltiples al grupo 1. Conecta la política de QoS llq al
tráfico saliente en la interfaz de enlaces múltiples.
!
ppp multilink interleave
En este ejemplo, el LFI de PPP de enlaces múltiples impide que los paquetes VoIP se retrasen detrás de paquetes de datos de gran tamaño,
cRTP reduce los requisitos de ancho de banda de VoIP y LLQ ofrece prioridad al tráfico de VoIP y ancho de banda garantizado a otra clase.
Necesita configurar estas características en ambos extremos del enlace PPP. LFI de PPP de enlaces múltiples sólo es necesario en el caso de
enlaces inferiores a 1,2 Mbps. cRTP sólo está recomendado en enlaces con un número inferior de llamadas VoIP y si el uso de la CPU no es
demasiado intenso.
QoS de VoIP sobre redes de retransmisión por frame (frame relay)
En esta sección se describe cómo configurar VoIP en una red típica en la que los enlaces WAN de retransmisión por frame (frame relay) se
utilizan para transportar tráfico de voz. Incluye las siguientes subsecciones:
QoS de VoIP sobre redes de retransmisión por frame (frame relay)
Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay)
QoS de VoIP sobre redes de retransmisión por frame (frame relay)
Otra aplicación típica de VoIP sería para una gran empresa en la que se usaría la infraestructura existente de tráfico de datos WAN de
retransmisión por frame (frame relay) para transportar las llamadas de voz entre las oficinas principales y las sucursales. Existen dos opciones en
este caso: llevar la voz y los datos en PVC independientes o usar el mismo PVC para el tráfico de voz y datos. En el primer caso, deberá seguir
dando prioridad al tráfico de voz usando una técnica como Cola de prioridad de interfaz PVC (PIPQ). PIPQ permite asignar varias prioridades
para los PVC: alta, media, normal o baja. PIPQ también permite que los PVC se coloquen en cola en la interfaz física principal de manera que el
tráfico de alta prioridad vaya antes que el tráfico de prioridad media, normal y baja. Sin embargo, PIPQ tiene el mismo problema que la
colocación en cola de prioridad: el tráfico de alta prioridad puede privar de ancho de banda al resto del tráfico. No obstante, si utiliza el modelado
de tráfico de retransmisión por frame (frame relay) correctamente, podrá minimizar este problema porque cada PVC tendrá una velocidad de
transmisión máxima definida.
En la situación más común, se usa sólo un PVC para transportar todo el tráfico entre los sitios, tal y como se muestra en la Figura 10.
Figura 10: QoS de VoIP sobre enlaces de retransmisión por frame (frame relay) de baja velocidad
Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay)
Debe configurar el modelado de tráfico de retransmisión por frame (frame relay) para garantizar que las discordancias de la velocidad en los
sitios remotos y del hub se manejen correctamente. Por ejemplo, si el sitio del hub cuenta con un conexión T1 en la red de retransmisión por
frame (frame relay) y el sitio remoto tiene una velocidad de acceso de 128 kbps, el sitio del hub cuenta con la capacidad para enviar a velocidades
de T1 en dirección a este único sitio remoto. Los switches de retransmisión por frame (frame relay) colocarán en la memoria intermedia este
tráfico en una pequeña proporción pero después eliminará de forma arbitraria lo que supere los 128 kbps. Tiene que decidir qué debería
eliminarse y a qué debería dársele prioridad en los puntos extremos del PVC.
El modelado de tráfico de retransmisión por frame (frame relay) permite que los routers envíen tráfico a la nube de retransmisión por frame por
debajo de una velocidad configurada previamente. Cualquier tráfico por encima de esta velocidad se colocará en cola. Se podrá utilizar un
algoritmo de colocación en cola tal como LLQ para tomar decisiones inteligentes sobre los paquetes que deberían enviarse. Si las colas se llenan,
los paquetes simplemente se eliminarán. Sin embargo, si se ha dado prioridad a VoIP y el tráfico total de VoIP está por debajo de la velocidad de
modelado de tráfico, los paquetes VoIP recibirán servicio con latencia baja a y no se eliminarán.
En el caso de enlaces con una velocidad inferior a 1,2 Mbps, debe configurar la fragmentación del paquete para garantizar que un paquete VoIP
no tenga que esperar detrás de un gran paquete. La fragmentación de paquetes de datos de gran tamaño a 10 ms de la velocidad del enlace puede
vincular el período máximo de espera. Puede utilizar cRTP para usar de manera eficaz el ancho de banda si el número de llamadas no es
demasiado alto.
Para ofrecer alta calidad a VoIP sobre retransmisión por frame (frame relay), debe configurar las siguientes características:
Modelado de tráfico de retransmisión por frame (frame relay):
Defina el comando de configuración de clase de asociador frame-relay cir en una velocidad de transmisión máxima (debería ser la
velocidad garantizada negociada del proveedor de servicios).
Desactive el comando de configuración de clase de asociador frame-relay adaptive-shaping y defina el valor del comando mincir
para que coincida con el de cir a fin de obtener una calidad de voz mejor.
Defina el comando de configuración de clase de asociador frame-relay bc en 1/100 de CIR para permitir que el modelado de tráfico
preste servicio a los paquetes, al menos, cada 10 ms.
LFI de FRF.12: sólo necesita LFI si la velocidad del puerto del extremo remoto o del hub es inferior a 1,2 Mbps. El tamaño de
fragmentación debería ser 10 ms u 80 bytes multiplicados por el número de DS0 (por ejemplo, para 4x64k, el tamaño de fragmentación
debería ser 4x80 = 320 bytes).
LLQ en PVC de retransmisión por frame (frame relay): LLQ se aplica bajo la clase de asignación para el modelado de tráfico de
retransmisión por frame.
cRTP: se aplica bajo la subinterfaz de retransmisión por frame (frame relay). Debería usar cRTP sólo si la utilización de la CPU es baja y
para un pequeño número de llamadas, según la plataforma.
El siguiente ejemplo de configuración muestra cómo activar las características de QoS descritas en la sección anterior:
Ejemplo de configuración 16: QoS para VoIP sobre los enlaces WAN de retransmisión por frame (frame relay)
Comandos
Descripción
class-map voip
match ip precedence 5
!
Crea la clase voip para el tráfico de voz que ha sido marcado con la precedencia IP 5
mediante uno de los métodos de marcado disponibles.
class-map webtraffic
match ip precedence 3
!
Crea la clase webtraffic para el tráfico web que ha sido marcado con la precedencia
IP 3 mediante uno de los métodos de marcado disponibles.
policy-map llq
class voip
priority 64
class webtraffic
bandwidth 64
Define la asignación de políticas de QoS llq: el tráfico de clase voip consigue la
prioridad y está limitado a 64 kbps durante la congestión. A los paquetes de clase
webtraffic se les garantizan 64 kbps. El resto del tráfico comparte el ancho de banda
restante.
class class-default
fair-queue
!
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic shaping
!
Activa el modelado de tráfico de retransmisión por frame (frame relay). Debe activar
el modelado de tráfico de retransmisión por frame (frame relay) para manejar las
discordancias de la velocidad y el exceso de suscripciones. (LLQ por PVC de
retransmisión por frame (frame relay) también necesita el modelado de tráfico de
retransmisión por frame).
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
Conecta la clase de modelado de tráfico voice a este PVC de retransmisión por frame
(frame relay).
frame-relay ip rtp header-compression
!
map-class frame-relay voice
no frame-relay adaptive-shaping
Configura cRTP para reducir los requisitos de ancho de banda de cada llamada de
voz.
Desactiva el modelado adaptable. No es recomendable utilizar el modelado adaptable
para VoIP.
frame-relay cir 256000
Define el CIR o la velocidad de transmisión superior a 256 kbps.
frame-relay bc 2560
Define la velocidad de ráfaga comprometida en 1/100 de CIR.
frame-relay mincir 256000
Define la velocidad mínima aceptable de CIR. El valor mincir tiene que ser superior a
la prioridad total y el ancho de banda asignado.
frame-relay fragment 320
Permite la fragmentación FRF.12 con un tamaño de fragmento de 320 bytes.
service-policy output llq!
Conecta la política de QoS llq a la clase de asignación definida.
En este ejemplo, el modelado de tráfico de retransmisión por frame (frame relay) maneja las discordancias de velocidad. La fragmentación
FRF.12 evita que los paquetes VoIP se retrasen al colocarse detrás de paquetes de datos de gran tamaño. cRTP reduce los requisitos de ancho
de banda de VoIP y LLQ otorga prioridad al tráfico de VoIP y garantiza ancho de banda a otra clase. Debe configurar estas características en
ambos extremos del enlace de retransmisión por frame (frame relay). FRF.12 sólo es necesario en el caso de enlaces inferiores a 1,2 Mbps y
cRTP sólo está recomendado en enlaces con un número inferior de llamadas VoIP y si el uso de la CPU no es muy intenso.
QoS de VoIP sobre ATM
En esta sección se describe cómo configurar la QoS de VoIP sobre ATM e incluye las siguientes subsecciones:
QoS de VoIP sobre escenario de ATM
QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado
QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos
QoS de VoIP sobre escenario de ATM
La tecnología ATM cuenta con ventajas inherentes en el manejo de tráfico de VoIP debido a sus celdas pequeñas y de tamaño fijo, y a los
mecanismos de clase de servicio (CoS). Estas ventajas no aseguran, sin embargo, que el tráfico de VoIP obtenga automáticamente la QoS que
necesita de la red ATM que lo lleva. El tráfico de VoIP no obtendrá de forma automática la QoS que necesita porque las definiciones de QoS en
la capa IP, tal como la configuración de la precedencia IP en el encabezado de paquete, no coinciden automáticamente con la configuración de
CoS de ATM, es decir, la clase de tráfico (velocidad de bits constante [CBR], velocidad de bits variable [VBR], velocidad de bits disponible
[ABR] y velocidad de bits no definida [UBR]) y los parámetros de tráfico como la velocidad de célula sostenida (SCR), la velocidad de célula de
cresta (PCR) y el tamaño de ráfaga. Por tanto, después de que se identifiquen los paquetes de datos y voz y se ordenen en la capa IP, el operador
de red debe configurar manualmente los circuitos virtuales (VC) de ATM para garantizar QoS para los paquetes de voz en la red ATM. Esta labor
manual lleva tiempo, requiere mucho trabajo, es más propensa a errores y, sobre todo, no tiene capacidad de ampliación cuando en la red entra
cada vez más tráfico de voz.
En la Figura 11 se muestra un ejemplo de QoS de VoIP configurado para dar soporte a ATM.
Figura 11: QoS de VoIP sobre los enlaces ATM
Hay dos soluciones disponibles para ofrecer QoS a VoIP sobre una red ATM: una utiliza VC de voz y datos independientes y la otra usa VC de
voz y datos compartidos.
QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado
En el caso de que el tráfico de datos y de voz compartan el mismo destino pero necesiten una QoS distinta, tendrá que definir los grupos de VC
de ATM para formar los agrupamientos de PVC. En un agrupamiento de PVC, todos los PVC comparten el mismo origen y destino, y se asigna a
cada agrupamiento para que lleve el tráfico IP con un nivel de precedencia IP específico o un rango de niveles. Después de configurar los
agrupamientos de PVC, tendrá que configurar cada PVC con sus parámetros concretos de QoS de ATM. Conforme el tráfico de voz y datos con
distintos niveles de precedencia IP llegan a la interfaz ATM del router, el software Cisco IOS lo envía de forma dinámica al PVC adecuado,
asignando de manera eficaz las clases de QoS de IP a las CoS de ATM.
Las ventajas principales de implementar la QoS de VoIP mediante este método son las siguientes:
Separación automática del tráfico de voz y datos en PVC distintos.
Conservación de los servicios diferenciados de la red IP mediante la red ATM.
El siguiente ejemplo de configuración muestra cómo configurar VoIP sobre ATM usando los agrupamientos de PVC para separar los PVC de
datos y voz:
Ejemplo de configuración 17: QoS para VoIP sobre ATM con PVC de datos y voz separados
Comandos
Descripción
ip cef
!
Permite la conmutación de IP de Cisco Express Forwarding (CEF). Debe activar
la conmutación de IP de CEF para que funcione esta solución.
interface ATM 2/0/0
no ip address
!
interface ATM 2/0/0.1 point-to-point
ip address 10.1.1.2 255.255.255.252
bundle qosmap
Crea un grupo de agrupamiento de PVC denominado qosmap.
protocol ip 10.1.1.1 broadcast
pvc-bundle control 1/100
precedence 6-7
Asigna un tráfico de precedencia IP 6 y 7 a un identificador de ruta virtual (VPI)
o a un identificador de canal virtual (VCI) de 1/100.
pvc-bundle voice 1/101
vbr-rt 6000 5000 1000
precedence 5
Asigna el tráfico de precedencia IP 5 (VoIP) a un VPI o VCI de 1/101 con un
SCR de 5 Mbps y algunas funciones de ráfaga.
pvc-bundle web 1/102
cbr 5000
precedence 4
Asigna el tráfico de precedencia IP 4 a 1/102 con un SCR de 5 Mbps.
pvc-bundle data 1/103
precedence 0-3
Asigna otro tráfico de precedencia a un PVC con un VPI o VCI de 1/103.
En este ejemplo, se asignan cuatro clases de tráfico basadas en la precedencia IP a cuatro PVC ATM independientes en un agrupamiento. El
PVC de voz cuenta con un ancho de banda garantizado de 5 Mbps con algunas funciones de ráfagas. El PVC de tráfico web también tiene
garantizado 5 Mbps pero sin ráfagas (CBR). Al tráfico de control y al resto de flujos de tráfico no se les proporciona ninguna garantía de
velocidad ATM.
QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos
Si decide usar PVC distintos para voz y datos, debe ajustar la asignación de ancho de banda correspondiente en cuanto el tráfico de voz crezca
más allá del ancho de banda configurado en el PVC de voz. Este reajuste manual no es necesario cuando la voz y los datos comparten el mismo
PVC, siempre que la voz obtenga la prioridad que necesita. Puede configurar el tráfico de VoIP para tener prioridad absoluta sobre el tráfico de
datos al configurar LLQ en el PVC ATM.
En el siguiente ejemplo de configuración se muestra cómo configurar VoIP sobre ATM usando el mismo PVC para el tráfico de datos y de voz:
Ejemplo de configuración 18: QoS para VoIP sobre ATM usando el PVC de voz y datos compartido
Comandos
Descripción
ip cef
!
Permite la conmutación de IP de CEF. Debe activar la conmutación de IP de CEF para que
funcione esta solución.
class-map voip
match ip precedence 5
!
Crea la clase voip para el tráfico de voz que ha sido marcado con la precedencia IP 5
usando uno de los métodos de marcado disponibles.
class-map webtraffic
match ip precedence 3
!
Crea la clase webtraffic para el tráfico web que ha sido marcado con la precedencia IP 3
usando uno de los métodos de marcado disponibles.
policy-map llq
class voip
priority 1000
class webtraffic
bandwidth 1000
class class-default
fair-queue
!
Define la asignación de políticas llq, que define la política de QoS: el tráfico de clase voip
consigue la prioridad y está limitado a 1 Mbps durante la congestión. A los paquetes de
clase webtraffic se les garantizan 1 Mbps. El resto del tráfico comparte el ancho de banda
restante.
interface ATM2/0/0
no ip address
!
interface ATM2/0/0.1 point-to-point
ip address 10.1.1.2 255.255.255.252
pvc data+voice 1/101
vbr-rt 6000 5000 1000
encapsulation aal5snap!
Configura los parámetros de modelado de ATM.
service-policy output llq
!
Conecta la asignación de políticas de QoS llq al PVC ATM.
En este ejemplo, LLQ se utiliza en un único PVC ATM que lleva tanto VoIP como datos. La política de LLQ se aplica a una subinterfaz de
ATM para un PVC. El tráfico de clase voip obtiene una prioridad de un máximo de 1 Mbps y a la clase webtraffic se le garantiza 1 Mbps
pero no entra dentro de la asignación de prioridad. El modelado de ATM también garantiza que el PVC obtenga una velocidad sostenida de
5 Mbps.
Documentos relacionados
Guía de configuración de soluciones de calidad de servicio de Cisco IOS, versión 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_book09186a008007ff1d.html
Referencia de comandos de soluciones de calidad de servicio de Cisco IOS, versión 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a00800807a7.html
Guía de configuración de aplicaciones multiservicio de Cisco IOS, versión 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_book09186a008008739c.html
Referencia de comandos de aplicaciones multiservicio de Cisco IOS, versión 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a0080087c1a.html
Módulo de características de COPS para RSVP de la versión 12.1(1)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/
copsrsvp.htm
Módulo de características de marcación de paquetes basada en la clase de la versión 12.1(2)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/cbpmark.htm
Módulo de características de modelado basado en la clase de la versión 12.1(2)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/
clsbsshp.htm
Módulo de características de mejoras en la compatibilidad de compresión del encabezado de retransmisión por frame (frame relay) de la
versión 12.1(2)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/
dtfrhccc.htm
Módulo de características de cola de latencia baja para retransmisión por frame (frame relay) de la versión 12.1(2)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/
dtfrpqfq.htm
Módulo de características de configuración del tamaño de ráfaga en la cola de latencia baja de la versión 12.1(3)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/
dtcfgbst.htm
Módulo de características de soporte de RSVP para la cola de latencia baja de la versión 12.1(3)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/
rsvp_llq.htm
Módulo de características de marcado basado en la clase de la versión 12.1(5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
cbpmark2.htm
Módulo de características de colocación en cola equilibrada y ponderada basada en la clase y la Random Early Detection ponderada
distribuida de la versión 12.1(5)T de Cisco IOS.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtcbwred.htm
Módulo de características de protocolo de tiempo real comprimido distribuido de la versión 12.1(5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtdcrtp.htm
Módulo de características de cola de latencia baja distribuida de la versión 12.1(5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtllqvip.htm
Módulo de características de modelado de tráfico distribuido de la versión 12.1(5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtdts.htm
Módulo de características de implementación de DiffServ para la calidad de servicio de extremo a extremo de la versión 12.1(5)T de Cisco
IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtdfsv.htm
Módulo de características de fragmentación y entrelazado de enlaces para retransmisión por frame (frame relay) y circuitos virtuales de
ATM de la versión 12.1 (5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtlfifra.htm
Módulo de características de control del tráfico de la versión 12.1(5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtpoli.htm
Módulo de características de control de admisión de llamadas VoIP mediante RSVP de la versión 12.1(5)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dt4trsvp.htm
© 1992-2014 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generación del PDF: 14 Abril 2008
http://www.cisco.com/cisco/web/support/LA/8/81/81646_tech_tk652_tk698_tech_white_paper09186a00800d6b73.html