QoS para VoIP Sobre Frame Relay, AMT y PPP

Calidad de servicio para Voz sobre IP
Contenidos
Informacin general de QoS para VoIP
Ancho de banda suficiente
Clasificacin de paquetes
Informacin general de clasificacin de paquetes
Clasificacin y marcado
Ejemplo de marcado y clasificacin de pares de marcado por voz
Ejemplo de marcado y clasificacin de ndice de acceso comprometido
Ejemplo de marcado y clasificacin del enrutamiento basado en polticas
Ejemplo de marcado y clasificacin de la interfaz de lnea de comandos de QoS modular
Mecanismos de colocacin en cola de QoS
Cola de latencia baja
Ejemplo de configuracin de LLQ
Otros mecanismos de colocacin en cola de QoS
Fragmentacin y entrelazado
Informacin general de entrelazado y fragmentacin
Ejemplo de entrelazado y fragmentacin de enlaces MLP
Ejemplo de entrelazado y fragmentacin FRF.12
Modelado de trfico
Informacin general de modelado de trfico
Ejemplo de modelado de trfico de retransmisin por frame (frame relay)
Compresin de encabezados IP RTP
Servicios diferenciados para VoIP
Informacin general de DS y DSCP (RFC 2474, RFC 2475)
Implementacin de DS para VoIP: reenvo acelerado PHB (RFC 2598)
Ejemplo de configuracin de marcado basado en la clase DSCP
Protocolo de reserva de recursos
Informacin general de RSVP
Informacin general de RSVP para CAC
Implementacin de CAC basada en RSVP
Configuracin de recursos de puertas de enlace locales si CAC falla
Uso de RSVP con LLQ
Implementacin del soporte de RSVP para LLQ
QoS de VoIP sobre lneas alquiladas (mediante PPP)
VoIP sobre escenario de lneas alquiladas (mediante PPP)
Solucin recomendada de VoIP sobre lneas alquiladas (mediante PPP)
QoS de VoIP sobre redes de retransmisin por frame (frame relay)
Solucin recomendada de QoS de VoIP sobre retransmisin por frame (frame relay)
QoS de VoIP sobre ATM
QoS de VoIP sobre escenario de ATM
QoS de VoIP sobre solucin ATM mediante PVC ATM para voz y datos por separado
QoS de VoIP sobre solucin ATM mediante PVC ATM para voz y datos compartidos
Documentos relacionados

Historial de la versin
Nmero de versin 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 caractersticas aplicables a la voz, en particular, a
la Voz sobre IP (VoIP). En este documento tambin se proporcionan ejemplos de alto nivel en los que se muestran cmo implementar estas
caractersticas en entornos de red diferentes.
Calidad de servicio para Voz sobre IP contiene las siguientes secciones:
Modelado de trfico

Para que la VoIP sea un reemplazo realista para los servicios de telefona de redes de telefona pblica conmutada estndar (PSTN), los clientes
deben recibir la misma calidad de transmisin de voz que reciben con los servicios de telefona bsica, es decir, transmisiones de voz de alta
calidad sistemticamente. 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 (tambin conocido como "fluctuacin"). Por ejemplo, se deben cumplir las siguientes normas:
El cdec G.729 predeterminado necesita que haya una prdida de paquetes bastante inferior al 1 por ciento para evitar errores audibles. Lo
mejor sera que no se perdieran paquetes para VoIP.
La especificacin ITU G.114 recomienda un retraso de extremo a extremo unidireccional inferior a 150 milisegundos (ms) para el trfico
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 satlite. Este retraso unidireccional tiene en cuenta el retraso de propagacin; es decir, el tiempo
necesario para que la seal recorra la distancia).
Las memorias intermedias para fluctuacin (utilizadas para compensar los diferentes retrasos) se agregan posteriormente al retraso de
extremo a extremo y normalmente slo son efectivas en las variaciones de retraso inferiores a 100 ms. Por tanto, se debe minimizar la
fluctuacin.
VoIP slo puede garantizar una transmisin de voz de alta calidad si los paquetes de voz, tanto para el canal de audio como para el de seal,
tienen prioridad sobre otros tipos de trfico de red. Para que VoIP se implemente de forma que los usuarios reciban un nivel aceptable de calidad
de voz, el trfico de VoIP debe tener garantizados ciertos requisitos de fluctuacin, latencia y ancho de banda de compensacin. QoS garantiza
que los paquetes de voz VoIP reciban el trato preferente que requieren. En general, QoS proporciona un servicio de red mejor (y ms predecible)
al proporcionar las siguientes caractersticas:
Soporte de ancho de banda dedicado
Mejora de las caractersticas de prdida
Impedimento y administracin de la congestin de red

Modelado del trfico de red
Configuracin de las prioridades del trfico a travs de la red
Calidad de servicio para Voz sobre IP trata los conceptos de QoS y las caractersticas aplicables a la voz, en particular a VoIP.

Antes de que se plantee aplicar cualquiera de las caractersticas de QoS abordadas en este documento, deber proporcionar un ancho de banda de
red suficiente para soportar el trfico de voz en tiempo real. Por ejemplo, una llamada G.711 de VoIP de 80 kbps (carga til de 64 kbps ms
encabezado de 16 kbps) no ser suficiente en un enlace de 64 kbps porque se perdern al menos 16 kbps de los paquetes (es decir, el 20 por
ciento). En este ejemplo, tambin se supone que no fluye ms trfico a travs del enlace. Una vez que proporcione un ancho de banda suficiente
para el trfico de voz, podr dar ms pasos para garantizar que los paquetes de voz dispongan de un determinado porcentaje del ancho de banda
total y que tengan prioridad.
La base para proporcionar cualquier QoS reside en la capacidad de un dispositivo de red para identificar y agrupar paquetes especficos.
Este proceso de identificacin se denomina clasificacin de paquetes. Una vez clasificado el paquete, ste debe marcarse estableciendo los
bits designados en el encabezado IP. Las siguientes secciones describen la clasificacin y el marcado:

Para garantizar el ancho de banda para los paquetes VoIP, un dispositivo de red debe poder identificar los paquetes VoIP en todo el trfico IP que
fluye a travs de l. Los dispositivos de red utilizan una direccin IP de origen y de destino en el encabezado IP o en los nmeros 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 identificacin se denomina clasificacin y es la base para proporcionar QoS.
Aparte de los mtodos de clasificacin esttica que implican la coincidencia de informacin del encabezado de la Capa 3 o Capa 4, puede utilizar
un mecanismo como el protocolo de reserva de recursos (RSVP) para la clasificacin dinmica. RSVP utiliza paquetes de sealizacin H.245
para determinar el puerto UDP que utilizar la conversacin de voz. A continuacin, configura listas de acceso dinmico para identificar el trfico
de VoIP y coloca el trfico en una cola reservada. RSVP se abordar ms adelante en este documento.
La clasificacin de paquetes puede ser un procesamiento intensivo, por lo que debera tener lugar lo ms lejos posible del borde de la red. Puesto
que cada salto necesita realizar una determinacin del tratamiento que el paquete debera recibir, necesitar disponer de un mtodo de
clasificacin ms eficiente y ms simple en el ncleo de la red. Esta clasificacin ms simple se logra mediante el marcado o configuracin del
byte ToS (tipo de servicio) en el encabezado IP.
Los tres bits ms importantes de byte ToS se denominan bits de precedencia de IP. La mayora de las aplicaciones y de los proveedores soportan
actualmente la configuracin y el reconocimiento de estos tres bits. El marcado se lleva a cabo para que los seis bits ms significativos del byte
ToS, llamados "punto de cdigo de servicios diferenciados" (DSCP), puedan usarse para definir las clases de servicios diferenciados (DS). DSCP
se abordar ms adelante en este documento.
Cuando cada uno de los saltos en la red pueda clasificar e identificar los paquetes VoIP (ya sea mediante informacin de la direccin del puerto o
mediante el byte ToS), dichos saltos podrn entonces proporcionarle a cada paquete VoIP la QoS necesaria. En este punto, se pueden configurar
las tcnicas especiales para proporcionar almacenamiento en cola prioritario para garantizar que los paquetes de datos grandes no interfieren en la
transmisin de datos de voz y para reducir los requisitos de ancho de banda comprimiendo la IP de 40 bytes ms UDP ms encabezado RTP a
entre 2 y 4 bytes.
Clasificacin y marcado
La clasificacin es un proceso de identificacin de la clase o grupo al que pertenece un paquete. Los dispositivos de red utilizan varios criterios
de concordancia para colocar el trfico en un determinado nmero de clases. Las concordancias se basan en los siguientes criterios:
El comando de configuracin global dial-peer voice voip
Lista de acceso (estndar 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 clasificacin basada en las coincidencias de las
listas de acceso. Por lo tanto, los nodos deberan 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 trfico como trfico de VoIP, los
dems nodos de la red pueden clasificar en funcin 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 prdida de celda (CLP) de ATM
En la mayora de las redes IP, el DSCP o la precedencia IP de marcado debera ser suficiente para identificar el trfico como de VoIP.
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 configuracin se muestra cmo marcar los bits de precedencia de IP:
Ejemplo de configuracin 1: Clasificacin 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 ms significativos del byte ToS de IP estn definidos en 101.
El ndice de acceso comprometido (CAR) es una tcnica antigua que implica el control del trfico o la limitacin de velocidad que coincide con
determinados criterios en un lmite superior. CAR admite la mayora de los mecanismos de concordancia y permite que los bits de DSCP o de
precedencia IP se definan de forma diferente en funcin de si los paquetes se ajustan a una determinada velocidad o la sobrepasan.
En general, CAR resulta ms til para los paquetes de datos que para los de voz. Por ejemplo, todo el trfico de datos en una interfaz Ethernet de
al menos 1 Mbps se puede colocar en una precedencia IP de clase 3 y todo el trfico 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 trfico excesivo o que no cumpla con las normas marcado con
una precedencia IP inferior. Todo el trfico de voz deber ajustarse a la velocidad especificada, si se ha configurado correctamente.
En el siguiente ejemplo de configuracin se muestra cmo utilizar CAR para clasificar y marcar los paquetes VoIP:
Ejemplo de configuracin 2: Clasificacin 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 trfico que coincida con la lista de acceso 100 se establecer en la precedencia IP 5, lo que significa que los tres bits ms
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 trfico de sealizacin H.323 para el puerto TCP 1720.

El enrutamiento basado en polticas (PBR) es otra caracterstica anterior que permite que el trfico se enrute en funcin de la lista de acceso o del
puerto de origen. Tambin se puede utilizar para clasificar y marcar paquetes. Un ejemplo de configuracin simple sera:
Ejemplo de configuracin 3: Clasificacin y marcado mediante PBR

!
route-map classify_mark
match ip address 100
set ip precedence 5
!
ip address 10.10.10.1 255.255.255.0
ip policy route-map classify_mark
En este ejemplo, el trfico que coincida con la lista de acceso 100 se establecer en la precedencia IP 5, lo que significa que los tres bits ms
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 trfico de sealizacin H.323 para el puerto TCP 1720.
El mtodo de marcado y clasificacin recomendado es la caracterstica de interfaz de lnea de comandos QoS modular (Mod QoS CLI o MQC),
un mtodo de configuracin basado en plantilla que separa la clasificacin de la poltica, permitiendo que varias caractersticas de QoS se
configuren conjuntamente para varias clases. Utilice la asignacin de clase para clasificar el trfico en funcin de varios criterios de coincidencia
y una asignacin de polticas para determinar qu debera ocurrir con cada clase. A continuacin, aplique la poltica al trfico entrante o saliente
en una interfaz mediante el comando de configuracin de interfaz service-policy. En el siguiente ejemplo de configuracin se muestra cmo
utilizar QoS modular para clasificar y marcar los paquetes:
Ejemplo de configuracin 4: Clasificacin y marcado mediante MQC

!
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>>
!
service-policy input mqc
En este ejemplo, el trfico 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 ms 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 trfico de sealizacin H.323 para el puerto TCP 1720. El resto del trfico se define con precedencia
IP 0. La poltica se denomina mqc y se aplica al trfico entrante en la interfaz Ethernet 0/0.
Una vez que se ha colocado el trfico en las clases de QoS en funcin de los requisitos de QoS, necesitar proporcionar garantas de ancho de
banda y servicio prioritario a travs de un mecanismo de colocacin en cola de salida inteligente. En esta seccin se describen los mecanismos de
colocacin en cola y se incluyen las siguientes subsecciones:

Se requiere una cola de prioridad para VoIP. Puede utilizar cualquier mecanismo de colocacin en cola que efectivamente le d alta prioridad a
VoIP, aunque se recomienda una cola de tiempo latencia bajo (LLQ) porque es flexible y fcil de configurar.
El mtodo de colocacin en cola ms flexible que satisface los requisitos de VoIP es la LLQ. LLQ utiliza el mtodo de configuracin MQC para
priorizar determinadas clases y proporcionar un ancho de banda mnimo garantizado para otras. Durante los perodos de congestin, la cola de
prioridad se controla en la velocidad configurada de manera que el trfico prioritario no monopolice todo el ancho de banda disponible. (Si el
trfico de prioridad monopoliza el ancho de banda, impide que se alcancen las garantas de ancho de banda para otras clases). Si se ofrece LLQ
correctamente, el trfico que vaya a la cola de prioridad nunca debera exceder la velocidad configurada.
LLQ tambin permite que se especifiquen las profundidades de la cola para determinar cundo el router debera eliminar paquetes si hay
demasiados esperando en cualquier cola de clase determinada. Tambin hay un valor predeterminado de clase que se utiliza para definir el
tratamiento de todo el trfico no clasificado por una clase configurada. Es posible configurar la clase predeterminada mediante el comando de
configuracin de interfaz fair-queue, lo que significa que a cada flujo sin clasificar se le dar una parte ms o menos igual del ancho de banda
restante. La figura 1 muestra cmo funciona LLQ.
Figura 1: Funcionamiento de LLQ
En la Figura 1, todo el trfico que sale de una interfaz o subinterfaz (para retransmisin 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
trfico de clase de prioridad se coloca en una cola de prioridad y el trfico de clase de ancho de banda garantizado junto a las colas reservadas. Se
podr ofrecer una cola reservada al trfico de clase predeterminada o colocarlo en una cola predeterminada sin reservar donde cada flujo obtendr
una parte ms o menos igual del ancho de banda disponible y sin reservar. El planificador presta servicio a las colas de manera que el trfico 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 congestin). Se presta servicio a las colas reservadas segn 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 cuntos bytes se ofrecen cada vez. Los
servicios del planificador se basan en el algoritmo de colocacin 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 transmisin del trfico de prioridad es superior al ancho de banda de prioridad configurado,
los paquetes situados al final de la cola de prioridad se eliminarn slo en el caso de que no haya ms 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 slo se eliminarn durante los periodos de congestin. Por tanto, la cola de prioridad deber contar con
ancho de banda suficiente para manejar todo el trfico de VoIP que necesite servicio prioritario.
En el siguiente ejemplo de configuracin se muestra cmo configurar LLQ:
Ejemplo de configuracin 5: LLQ

!
class-map voip
class-map data1
match protocol
class-map data2
!
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 trfico que coincida con la lista de acceso 100 ser clasificado como clase voip, (lo que quiere decir "trfico de voz"), y se
le dar alta prioridad hasta un mximo de 32 kbps. La lista de acceso 100 coincide con los puertos UDP comunes utilizados por el trfico de
sealizacin VoIP y H.323 para el puerto TCP 1720. El comando class data1 coincide con el trfico 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 trfico 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 poltica se denomina llq y se aplica al trfico 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
debera ser inferior al 75 por ciento del ancho de banda de la interfaz. Puede modificar este porcentaje usando el comando de
configuracin de interfaz max-reserved bandwidth.
Hay otros mtodos de colocacin en cola disponibles. Por ejemplo, el Ordenamiento cclico con dficit modificado (MDRR) es un mecanismo de
colocacin en cola disponible en las series 12000 de los routers switches Gigabit (GSR) de Cisco que permite la garanta 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
multidifusin.
Una vez ms, VoIP necesita prioridad pero hay aplicaciones de datos que no pueden quedarse sin ancho de banda y necesitan garantas de que lo
van a tener. Puede usar cualquier mecanismo de colocacin en cola que proporcione de hecho alta prioridad a VoIP, aunque recomendamos LLQ.
En la Tabla 1 se describen algunos de los mecanismos de colocacin en cola de software disponibles.
Tabla 1: Mecanismos de colocacin en cola de software
Mecanismos de
colocacin en cola
de software Descripcin Beneficios Limitaciones
FIFO Los paquetes llegan y dejan la cola Configuracin simple y No es posible ofrecer el servicio
exactamente en el mismo orden. rpida operacin. prioritario ni las garantas de ancho
de banda.
WFQ Un algoritmo de hash coloca flujos en Configuracin simple. Valor No es posible ofrecer el servicio
colas independientes donde los pesos se predeterminado en enlaces prioritario ni las garantas de ancho
utilizan para determinar a cuntos inferior a 2 Mbps. de banda.
paquetes se presta servicio en cada
momento. Los pesos se definen al
establecer los valores de precedencia IP
y DSCP.
Almacenamiento en El trfico se clasifica en colas mltiples Ha estado disponible durante No es posible la prestacin de
cola personalizado con lmites de cola configurables. Los algunos aos y permite la servicio prioritario. Las garantas de
(CQ) lmites de cola se calculan segn el asignacin aproximada de ancho de banda son aproximadas y
tamao medio del paquete, la unidad de ancho de banda para varias hay un nmero limitado de colas. La
transmisin mxima (MTU) y el colas. configuracin es relativamente
porcentaje de ancho de banda que se va difcil.
a asignar. Los lmites de cola (en
nmero de bytes) se quitan de la cola
para cada cola, por lo que se
proporciona el ancho de banda asignado
estadsticamente.
Priority Queuing El trfico se clasifica en colas de Ha estado disponible durante El trfico de prioridad ms alta
(PQ) prioridad alta, media, normal y baja. algunos aos y ofrece puede privar de ancho de banda a las
Primero se presta servicio al trfico de prestacin de servicios colas de prioridad ms bajas. No es
alta prioridad, despus al de prioridad prioritarios. posible ofrecer garanta de ancho de
media y, por ltimo, al de prioridad banda.
normal y baja.
WFQ basado en MQC se utiliza para clasificar el trfico. Es similar a LLQ, a excepcin No es posible la prestacin de
clases (CBWFQ) El trfico clasificado se coloca en colas de que no hay una cola servicio prioritario.
de ancho de banda reservado o en una prioritaria. Configuracin
cola predeterminada no reservada. Los simple y capacidad de
planificadores prestan servicio a las proporcionar garantas de
colas segn los pesos de manera que se ancho de banda.
cumplan las garantas de ancho de
banda.
WFQ de cola de Se utiliza un comando de interfaz nico Configuracin simple de un El tratamiento del resto del trfico se
prioridad (PQ- para ofrecer prestacin de servicios de nico comando. Proporciona realizar con WFQ. El trfico RTCP
WFQ, tambin prioridad a todos los paquetes UDP servicio prioritario a paquetes no se prioriza. No hay capacidad de
denominado destinados a nmeros de puerto pares RTP. ancho de banda garantizada.
"prioridad IP dentro de un rango especificado.
RTP")
LLQ (denominado MQC se utiliza para clasificar el trfico. Configuracin simple. No hay ningn mecanismo para
anteriormente "PQ- El trfico clasificado se coloca en una Capacidad de otorgar ofrecer varios niveles de prioridad
CBWFQ") cola de prioridad, colas de ancho de prioridad a distintas clases de todava ya que todo el trfico de
banda reservado o en una cola no trfico y ofrecer ms lmites prioridad se enva a travs de la
reservada predeterminada. Un sobre la utilizacin del ancho misma cola de prioridad. Las clases
planificador se ocupa de las colas de banda prioritario. Tambin de prioridad independientes pueden
basndose en el peso para que el trfico puede configurar clases de tener lmites superiores de prioridad
de prioridad sea enviado primero (hasta ancho de banda garantizado y de ancho de banda durante la
un cierto lmite regulado durante la una clase predeterminada. congestin, aunque compartir la cola
congestin) y para que se cumplan las de prioridad entre aplicaciones
garantas del ancho de banda. puede crear fluctuaciones.
Debido a que las transmisiones de VoIP son extremadamente sensibles a los retrasos, los paquetes VoIP debern entrelazarse o insertarse entre
los fragmentos del paquete de datos. Esta seccin describe la fragmentacin y el entrelazado e incluye, adems, las siguientes subsecciones:
Aunque la colocacin en cola est funcionando a pleno desempeo y priorizando el trfico de voz, hay ocasiones en las que la cola de prioridad
est vaca 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 podra esperar un tiempo considerable antes de ser enviado. Si asumimos que un paquete VoIP tendr que esperar detrs de un
paquete de datos y que puede ser, al menos, igual en tamao 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 segn la velocidad del enlace.
Por ejemplo, en el caso de una velocidad de enlace de 64 kbps y un tamao 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 mximo de 187,5 ms antes de que pueda enviarse si se retrasa detrs de un
paquete de 1500 bytes en un enlace de 64 kbps. Por lo general, los paquetes VoIP se envan cada 20 ms. Con un presupuesto de retraso de
extremo a extremo de 150 ms y unos requisitos de fluctuacin estrictos, una brecha de ms de 180 ms es inaceptable.
Necesita un mecanismo que garantice que el tamao de una unidad de transmisin sea inferior a 10 ms. Los paquetes que tengan un retraso de
serializacin superior a 10 ms tendrn que dividirse en partes de 10 ms. Una parte o fragmento de 10 ms es el nmero de bytes que puede
enviarse por el enlace en 10 ms. Puede calcular el tamao 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 tamao es ms pequeo que la MTU, ser necesaria la fragmentacin. Sin embargo,
la simple fragmentacin no es suficiente porque si el paquete VoIP debe esperar detrs de todos los fragmentos de un nico paquete de datos de
gran tamao, el paquete VoIP seguir sufriendo un retraso ms all del lmite 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 fragmentacin y el entrelazado.
Figura 2: Fragmentacin y entrelazado de paquete VoIP
En la Tabla 2 se muestran los tamaos de fragmentos recomendados para varias velocidades de enlace basadas en la regla de los 10 ms.
Tabla 2: Velocidad de enlace y tamao de fragmentacin
Velocidad de
enlace (kbps) Tamao de fragmentacin (bytes)
56 70
64 80
128 160
256 320
512 640
768 960
1024 1280
1536 1920 (No es necesario realizar una fragmentacin si el tamao del fragmento es mayor que el tamao del enlace de
MTU. Por ejemplo, en el caso de un enlace T1 con un MTU de 1500 bytes, el tamao del fragmento ser 1920 bytes;
por tanto, no ser necesaria la fragmentacin).
Nota El tamao de fragmentacin del paquete nunca debera ser inferior al tamao del paquete VoIP. Adems, nunca debera fragmentar
los paquetes VoIP ya que puede causar numerosos de problemas de configuracin y de calidad de las llamadas.
Hay disponibles tres mecanismos de fragmentacin y entrelazado de enlaces (LFI). En la Tabla 3 se muestran sus ventajas y limitaciones.
Tabla 3: Velocidad de enlace y tamao de fragmentacin
Mecanismo de LFI Descripcin Beneficios Limitaciones

Fragmentacin de Comando de nivel de interfaz para Configuracin simple. Los fragmentos vuelven a ensamblarse
MTU con WFQ cambiar el tamao de MTU o de nicamente mediante la aplicacin de
MTU de IP. Utilizado para recepcin, por lo que el uso de la red es
fragmentar paquetes IP de gran ineficaz. Slo los paquetes IP con el bit
tamao en el tamao de MTU No fragmentar (DF) no definido podrn
especificado. LFI usa WFQ para manejar la fragmentacin
entrelazar paquetes en tiempo real correctamente. Uso intensivo del
entre los fragmentos. procesador. No recomendado.
Fragmentacin y En los enlaces seriales de punto a Los paquetes se fragmentan nicamente disponible en enlaces
entrelazado de enlace punto, deber configurarse primero en un extremo del enlace y configurados para PPP. Las soluciones
(LFI) del protocolo MLP, a continuacin, deber se vuelven a ensamblar en el para PPP sobre retransmisin por frame
punto a punto de definirse el tamao de otro. Es posible combinar (frame relay) o PPP sobre ATM
enlaces mltiples fragmentacin en milisegundos. varios enlaces para que tambin se soportan en la versin
(MLP) Tambin deber activarse el acten como un gran 12.1(5)T o posterior de Cisco IOS.
entrelazado en la interfaz de enlace conducto virtual.
mltiple.
Fragmentacin de En los PVC de retransmisin por Los paquetes se fragmentan Slo est disponible en los PVC de
retransmisin por frame (frame relay), debe activarse en un extremo de PCV y se retransmisin por frame (frame relay)
frame (frame relay) el comando de configuracin de vuelven a ensamblar en el con el comando de configuracin de
(FRF.12) interfaz frame-relay traffic- otro. interfaz frame-relay traffic-shaping
shaping y establecerse el tamao activado.
de la fragmentacin en la clase de
asignacin.

En el siguiente ejemplo de configuracin se muestra cmo configurar la fragmentacin y el entrelazado mediante MLP LFI:
Ejemplo de configuracin 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 tamao de fragmentacin de 10 ms, que se calcula segn el ancho de banda configurado para
la interfaz de enlaces mltiples. La interfaz de serie 1/0 se coloca en el grupo de enlaces mltiples 1 y, por tanto, hereda la configuracin de
enlace mltiple en la interfaz de enlace mltiple 1.

En el siguiente ejemplo de configuracin se muestra cmo configurar la fragmentacin y el entrelazado mediante FRF.12:
Ejemplo de configuracin 7: LFI de fragmentacin de retransmisin 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 trfico de retransmisin por frame (frame relay) se activa en DLCI 128. FRF.12 se configura con un tamao
de fragmentacin de 320 bytes, que es 10 ms de la velocidad de informacin comprometida (CIR). El tamao de fragmentacin debera 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 trfico
El modelado de trfico es un mecanismo de QoS que se utiliza para enviar trfico en rfagas cortas a una velocidad de transmisin configurada.
Se utiliza ms comnmente en los entornos de retransmisin por frame (frame relay) donde la velocidad del reloj no es la misma que el ancho de
banda garantizado o CIR. En esta seccin se describen los mecanismos de modelado de trfico y se incluyen las siguientes subsecciones:

El modelado de trfico de retransmisin por frame (frame relay) es la aplicacin de modelado de trfico ms comn en entornos de VoIP. Los
escenarios de retransmisin 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 trfico de retransmisin por frame (frame relay), es posible que el
hub trate de enviar a velocidades ms altas de las que los remotos pueden recibir, lo que provocar que la red de retransmisin por frame elimine
trfico de forma arbitraria. Sin embargo, los remotos podran 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 retransmisin por frame (frame relay) elimine trfico en forma arbitraria. Cuando hablamos de red de
retransmisin 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 trfico de
VoIP si se infringen los contratos. Por tanto, necesita controlar las velocidades de transmisin en una nube de retransmisin por frame (frame
relay) de manera que pueda controlar qu paquetes se eliminan y cules reciben la prestacin de servicio prioritario. En la Figura 3 se muestra un
ejemplo de una red tpica de retransmisin por frame (frame relay) sin modelado de trfico.
Figura 3: Red de retransmisin por frame (frame relay)
En el siguiente ejemplo de configuracin se muestra cmo configurar el modelado de trfico de retransmisin por frame (frame relay):
Ejemplo de configuracin 8: Modelado de trfico de retransmisin por frame (frame relay)
interface Serial 0/1

no ip address
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
class voice
!
map-class frame-relay voice
no frame-relay adaptive-shaping
frame-relay bc 2560
frame-relay mincir 256000
En este ejemplo, el modelado de trfico de retransmisin 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 asignacin configura un CIR de 256.000 bps y una velocidad
de rfaga comprometida (Bc) de 2.560 bits. Esta configuracin significa que el router enviar 2.560 bits cada 2.560/256.000 segundos (10
ms) y colocar en cola cualquier rfaga en exceso. El CIR mnimo se define en el mismo valor de CIR y se desactiva el modelado adaptable.
El valor de la rfaga en exceso (Be) de retransmisin por frame (frame relay) no est definido y, por tanto, el valor predeterminado es 0, lo
que impide cualquier rfaga sobre CIR. Esta es la configuracin recomendada para el modelado de trfico cuando lleva VoIP.

La compresin 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 estndar para esta tcnica es cRTP, que quiere decir "RTP comprimido". En la Figura 4 se muestra la
funcionalidad de la compresin del encabezado RTP.
Figura 4: Compresin de encabezado RTP
Para configurar la compresin 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 retransmisin por frame (frame relay). Tambin puede configurar el
comando de configuracin de interfaz ip rtp compression-connections para definir un nmero mximo de flujos que se comprimirn. Debido a
que cRTP puede hacer un uso intensivo del procesador, usted deber limitar el nmero de flujos comprimidos para impedir la disminucin del
desempeo del router. El RTP comprimido est recomendado en enlaces de baja velocidad donde el ancho de banda es escaso y hay pocas
llamadas 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 seccin se describen los DS y se incluyen las siguientes subsecciones:
Las primeras redes IP estaban basadas en el modelo de servicio de mejor esfuerzo, lo que significaba que los retrasos, fluctuaciones, prdida de
paquetes y asignacin de ancho de banda no eran predecibles. Hoy en da, un gran nmero de redes siguen este modelo de mejor esfuerzo y no
soportan aplicaciones mejoradas que requieren algn tipo de garanta 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 trfico ms 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 trfico se trata de una forma simple, basada en
FIFO, sin aplicacin de QoS.
El primer enfoque de arquitectura para ofrecer QoS de extremo a extremo necesitaba que la aplicacin sealara 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 arquitectnico significaba que la telefona IP o
la puerta de enlace de voz necesitaban realizar solicitudes de QoS en cada salto de la red de manera que se asignaran los recursos de extremo a
extremo. Cada salto necesitaba mantener la informacin del estado de la llamada para determinar cundo 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 garantas de QoS. Este
mtodo se denomina "modelo de QoS de servicios integrados". La implementacin ms comn de los servicios integrados utiliza el protocolo de
reserva de recursos (RSVP). RSVP cuenta con algunas ventajas, como el Control de admisin de llamadas (CAC), donde una llamada puede
volver a enrutarse al enviar una seal adecuada a la persona que llama si la red no cuenta con los recursos de QoS disponibles para soportarla. Sin
embargo, RSVP tambin presenta algunos problemas de escalabilidad, que se tratarn ms adelante en este documento.
La arquitectura DS es el modelo de QoS ms ampliamente implementado y soportado hoy da. 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 regin DS y se marcan de forma adecuada,
de manera que los routers del ncleo de la nube puedan ofrecer QoS basado simplemente en la clase DS. Los seis bits ms significativos del byte
ToS de IP se utilizan para especificar la clase DS. El punto de cdigo 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 cmo el encabezado IP define la clase DS.
Figura 5: Definicin del campo de servicios diferenciados
Los servicios diferenciados se describen y se definen en los RFC siguientes:
RFC 2474, definicin del campo de servicio diferenciado (campo DS)
RFC 2475, arquitectura para el servicio diferenciado
RFC 2597, grupo PHB de reenvos garantizados
RFC 2598, reenvo 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 ms
significativos del byte ToS; es decir, [123]45678. (De vez en cuando, el trmino ToS se utiliza para referirse a los siguientes tres bits:
123[456]78. No obstante, en este documento, para ser coherentes con la especificacin 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 asignacin DSCP
Precedencia IP Valor del bit de precedencia de IP Bits DSCP Clase DSCP
5 101 101000 Reenvo acelerado
4 100 100000 Reenvo asegurado 4
0 000 000000 Mejor esfuerzo
Los dos bits siguientes se usan para definir la preferencia de eliminacin. Por ejemplo, si el trfico en la Clase 4 (los primeros tres bits son 100)
supera una determinada velocidad contratada, los paquetes excedentes podran volver a marcarse de manera que se alcance la preferencia de
eliminacin en lugar de eliminarse. Si se produjera la congestin en la nube DS, los primeros paquetes que se eliminaran seran los paquetes de
"preferencia de eliminacin alta". Esto es parecido al marcado del bit DE en retransmisin por frame (frame relay) y el del bit CLP en ATM.
Estos mecanismos permiten que la red de Capa 2 tome decisiones de eliminacin inteligentes para el trfico que no cumpla con las normas en los
perodos de congestin. DS permite una accin similar sobre una red IP. El sexto bit debe definirse en 0 para indicar a los dispositivos de red que
las clases se definieron segn la norma DS.
La arquitectura DS define un grupo de acondicionadores de trfico que se usan para limitar el trfico en una regin DS y colocarlo en las clases
DS adecuadas. Los medidores, marcadores, modeladores y eliminadores son acondicionadores de trfico. Los medidores son, bsicamente,
reguladores de trfico. El control de trfico 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 implementacin 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
eliminacin soportado, aunque no debera invocar WRED en la clase VoIP. El comportamiento por salto (PHB) describe lo que debera
experimentar una clase DS en trminos de prdida, retraso y fluctuacin. Un PHB determina cmo se asignar el ancho de banda, se restringir el
trfico y se eliminarn los paquetes durante la congestin.
En DS se definen tres PHB segn el comportamiento de reenvo necesario:
Clase de mejor esfuerzo: los bits de selector de clases se definen en 000
PHB de reenvo asegurado: bits de selector de clases definidos en 001, 010, 011 o 100
PHB de reenvo acelerado: bits de selector de clases definidos en 101
La norma de reenvo asegurado (AF) especifica las cuatro clases de ancho de banda garantizado y describe el tratamiento que cada una debera
recibir. Tambin especifica los niveles de preferencia de eliminacin, con un resultado total de 12 clases AF posibles, tal y como se muestran en
la Tabla 5.
Tabla 5: Clases posibles de reenvo asegurado
Niveles de preferencia de eliminacin Clase AF1 Clase AF2 Clase AF3 Clase AF4
Precedencia de eliminacin baja 001010 010010 011010 100010
Precedencia de eliminacin media 001100 010100 011100 100100
Precedencia de eliminacin alta 001110 010110 011110 100110
Es muy probable que utilice las clases de reenvo asegurado para el trfico de datos que no necesite tratamiento de prioridad y que est basado en
gran medida en TCP. El reenvo acelerado coincide en gran medida con los requisitos de QoS de VoIP.
El reenvo acelerado (EF) est diseado para las aplicaciones sensibles al retraso que necesiten ancho de banda garantizado. Un marcado EF
garantiza el servicio prioritario al reservar una cantidad mnima de ancho de banda que pueda usarse para el trfico 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 congestin 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 trfico que pertenezca a la clase EF, pero si en el mismo momento
hay congestin, los paquetes que no cumplan las normas que superen la velocidad de prioridad especificada se eliminarn 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
configuracin del par de marcado ip precedence para el trfico de VoIP. Por tanto, si los dispositivos IP de la red pueden reconocer la
precedencia IP o DSCP para la clasificacin y el marcado, podr proporcionar QoS de extremo a extremo.

La arquitectura DS especifica cmo clasificar, marcar, regular y modelar el trfico que entra en una regin DS y cmo tratar las diferentes clases
en cada salto en la regin DS. En el borde DS, todos los paquetes IP se marcan con el DSCP adecuado de manera que se puede ofrecer QoS
segn el DSCP dentro de la regin DS. El siguiente ejemplo de configuracin muestra cmo configurar el marcado DSCP en el borde mediante el
marcado basado en la clase:
Ejemplo de configuracin 9: Marcado basado en la clase de DSCP

!
class-map voip
class-map webtraffic
!
policy-map dscp_marking
class voip
set ip dscp 46 #EF Class
class webtraffic
set ip dscp 26 #AF Class
!
service-policy input dscp_marking
En este ejemplo, todo el trfico que entra en una interfaz Ethernet 0/0 se inspecciona y se clasifica segn las asignaciones de clasevoip
y webtraffic. El comando de configuracin global de asignacin de polticas define el DSCP en el trfico de clase voip a 46 (101110 para
EF) y el de webtraffic en 26 (011010 para AF3).
Ahora es posible definir la colocacin en cola y otros parmetros de QoS para que coincidan con DSCP en el resto de la regin DS.
En las restantes secciones de este documento, se har coincidir el trfico de precedencia IP 5 como VoIP y el trfico de precedencia IP 3 como
HTTP (trfico web), mientras que el resto del trfico se dirigir a la clase predeterminada. De igual forma, se podra utilizar DSCP 46 para VoIP
y DSCP 26 para HTTP. Podramos usar varios mecanismos de clasificacin y marcado pero para mantener la coherencia y la simplicidad,
usaremos la precedencia IP.

El protocolo de reserva de recursos (RSVP) es una implementacin de la arquitectura de servicios integrados para QoS (RFC 2205). Cuando se
introdujo VoIP, RSVP fue considerado inmediatamente como un componente fundamental que ofrecera control de admisin y QoS para flujos
de VoIP. Sin embargo, la manera en que se integraron RSVP y H.323 previamente no ofreci control de admisin 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
sealar un QoS deseado que ofrecer una buena calidad de voz de extremo a extremo an cuando haya congestin.
En esta seccin, se describe RSVP (en general) con especial atencin a un subconjunto particular de plataformas, topologas y protocolos.
Tambin asumimos que est usando H.323 como el protocolo de sesin para una red de VoIP basada en la puerta de enlace. Esta seccin incluye
a su vez las siguientes subsecciones:
Uso de RSVP con LLQ
La implementacin inicial de RSVP para VoIP tena dos limitaciones. La primera era que el CAC no poda implementarse con RSVP porque el
proceso de reserva no estaba sincronizado con la sealizacin de la llamada de voz. La llamada se producira aunque la reserva de RSVP hubiera
fallado o no se hubiera completado. La segunda limitacin era que exista la posibilidad de que una reserva de RSVP correcta no ofreciera una
buena calidad de voz durante los perodos de congestin de red. RSVP cre un flujo reservado de cola-por-trfico 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 tena 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. Adems, no haba soporte para RSVP en ATM ni en los PVC de retransmisin por frame (frame relay) modelados.
Debe implementar RSVP para mejorar la QoS de VoIP all donde slo pueda tener un impacto positivo en la calidad y funcionalidad. Las
ventajas de usar RSVP supera los costes (gestin, tara e impacto del desempeo) pero slo donde haya ancho de banda limitado y frecuente
congestin 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 mtodo se basa en el sondeo de la red para medir el retraso, la fluctuacin y las prdidas a fin de estimar los
problemas potenciales de voz que la llamada puede sufrir. (Este problema potencial se denomina "factor de defecto de planificacin
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 nmero de llamadas: gracias a este mtodo, puede
configurar umbrales que activarn diferentes acciones, como devolucin y rechazo de llamadas, o reproduccin de un mensaje.
Gestin de ancho de banda mediante el control de acceso H.323: en este mtodo, podr configurar una cantidad mxima de ancho de banda
que los controles de acceso podrn asignar a las llamadas.
RSVP.
En este documento, slo trataremos el uso de RSVP para el CAC.

El uso de RSVP para el CAC de VoIP necesita la sincronizacin de la sealizacin de la configuracin de la llamada y la sealizacin de RSVP.
Esta sincronizacin garantiza que el telfono de la parte llamada slo suene despus de que los recursos de la llamada se hayan reservado. Esta
sincronizacin tambin proporciona a las puertas de enlace de voz el control de la accin que hay que realizar antes de que la configuracin de la
llamada pase a la etapa de alerta si la reserva falla o no puede completarse dentro de un perodo de tiempo predefinido. La llamada de voz
activar dos reservas de RSVP porque los mecanismos de reserva y control de admisin 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
configuracin de llamada si se usa RSVP en la reserva de recursos.
Figura 6: Configuracin 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 enva 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
configuracin de llamada que est a la espera de los resultados de la reserva. La puerta de enlace de destino controla la decisin de admisin 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 configuracin de llamada contine y enva 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 desconexin normal cuando se enva un mensaje RELEASE COMPLETE de H.323 despus de que se haya conectado la llamada. En este
punto, las puertas de enlace cerrarn 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 travs 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
configuracin 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 slo se realizar como mejor esfuerzo si las puertas
de enlace de origen y destino desean aceptar el servicio de mejor esfuerzo. La liberacin 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 lneas analgicas generan una seal de ocupado rpido. 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
Tal y como se ha mencionado anteriormente, debera implementar RSVP para mejorar la QoS de VoIP all donde slo pueda tener un impacto
positivo en la calidad y funcionalidad. Las ventajas de usar RSVP superan los costes slo donde el ancho de banda es limitado. Recomendamos el
uso de la versin 12.1(5)T o superior de Cisco IOS si desea implementar CAC para VoIP mediante RSVP.
Debe realizar los siguientes tres pasos bsicos para configurar CAC para las llamadas VoIP mediante RSVP:
Activar la sincronizacin entre RSVP y la sealizacin de llamadas. Esta sincronizacin est activada en forma predeterminada cuando la
versin 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 mximo en todos los enlaces que atraviesan los paquetes de voz donde es probable que
ocurra la congestin.
En el siguiente ejemplo de configuracin se muestra cmo configurar CAC para llamadas VoIP mediante RSVP:
Ejemplo de configuracin 10: Implementacin 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
!
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 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
!
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
!
end
Este ejemplo muestra una configuracin 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 configuracin. No hemos priorizado
la sealizacin de la voz en este ejemplo.
La configuracin 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 sealizacin de RSVP. Se solicitan
mediante el comando de configuracin del par de marcado req-qos. La QoS aceptable controla cun estrictos o permisivos deberan ser los
criterios de CAC. Los controles de QoS aceptables se configuran mediante el comando de configuracin 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 implcito 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 explcita del par de marcado.
Tal y como se ha mencionado anteriormente, puede configurar una puerta de enlace de voz para que realice distintas acciones si el control de
admisin falla. La primera alternativa es que la seal de las puertas de enlace enven una seal al usuario o al switch que ha entregado la llamada
con una seal de ocupado rpido o con una causa de desconexin. Si la llamada se ha entregado a la puerta de enlace mediante un switch de
ISDN, podr ajustar la causa de desconexin 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 configuracin de interfaz isdn network-failure-cause o isdn
disconnect-cause. La implementacin actual del comando isdn network-failure-cause anula el valor configurado mediante el comando isdn
disconnect-cause.
El siguiente ejemplo de configuracin muestra cmo configurar los recursos de puerta de enlace locales si se produce un error en CAC al ajustar
la causa de desconexin Q.931:
Ejemplo de configuracin 11: Ajuste de la causa de desconexin Q.931
!
no ip address
isdn network-failure-cause 42
no cdp enable
!
En este ejemplo, el router enva un mensaje DISCONNECT de Q.931 con una causa que indica que hay congestin en el equipo de
conmutacin (42) cuando se produce un error de CAC en una llamada ISDN en el tramo de VoIP.
La segunda opcin es permitir que la puerta de enlace vuelva a enrutar la llamada a travs de otra ruta. Si el par de marcado que coincide con la
llamada forma parte de un grupo de bsqueda, se probarn otros pares de marcado en ese grupo segn el comando de configuracin 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 configuracin se muestra cmo 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 configuracin 12: Reenrutamiento de llamadas en la puerta de enlace

no digit-strip
direct-inward-dial
port 1/0:23
!
preference 0
!
preference 2
!
preference 5
no digit-strip
direct-inward-dial
port 1/1:23
!
Este ejemplo muestra una implementacin del reenrutamiento de llamadas en la puerta de enlace. Las llamadas a nmeros de siete dgitos
que comiencen con el dgito 3, prueban dos puertas de enlace de voz en primer lugar. Las llamadas se enrutan mediante la PSTN a travs del
puerto de voz 1/1:23 si se producen errores en las llamadas VoIP debido al CAC o a cualquier otra razn.
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 an cuando se produzcan errores en las reservas de RSVP. Esta opcin, 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 vlida 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 admisin si falla al menos una de las dos
reservas de RSVP necesarias para la llamada. Para cada reserva de RSVP, el control de admisin se realiza en todas las interfaces donde se haya
activado RSVP usando el comando de configuracin de interfaz ip rsvp bandwidth. Puede configurar dos valores con el comando ip rsvp
bandwidth: el ancho de banda mximo total reservado y el ancho de banda mximo por reserva. El ancho de banda mximo total est limitado
en forma predeterminada a no ms del 75 por ciento del ancho de banda total de la interfaz. Puede modificar ese lmite con el comando de
configuracin de interfaz max-reserved-bandwidth. Las excepciones a la limitacin de ancho de banda mximo total son PVC de retransmisin
por frame (frame relay) y ATM. En el caso de PVC de retransmisin por frame (frame relay), al ancho de banda mximo reservable es el CIR
mnimo o, si no est configurado, la mitad del CIR. Para los PVC ATM, el ancho de banda mximo reservable es el 75 por ciento de la velocidad
mnima 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 operacin del router.
Nota Esta comprobacin no se realiza durante la configuracin del router.
Debera configurar el ancho de banda mximo por reserva que no sea inferior al que el cdec necesita ms toda la tara de protocolo excepto la de
la Capa 2. En la Tabla 6 se muestran los valores ms bajos que puede usar para cdecs diferentes. Recuerde que estos valores no darn cuenta de
los ahorros de ancho de banda introducidos por cRTP o la deteccin 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
Cdec 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 consideracin 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 implementacin del CAC de VoIP basada en RSVP depende de una confirmacin o rechazo del mensaje de la reserva solicitada. El
tiempo que se ha tomado para reservar los recursos se aade al retraso posterior al marcado, que debera mantenerse tan bajo como sea posible en
la mayora 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 configuracin de reserva inicial, deber caducar un temporizador de actualizacin de RSVP antes de que el paquete
perdido se reenve. Debido a que el temporizador de actualizacin se define normalmente en decenas de segundos, la situacin en la que se puede
aadir un retraso posterior al marcado no es aceptable para el usuario. El comando de configuracin global call rsvp-sync resv-timer permite
controlar el tiempo mximo 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 colocacin 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 trfico sensible al retraso. Se cre una cola reservada con un peso inferior cuando
se instal la reserva de RSVP. Sin embargo, WFQ podra no ajustarse a los requisitos de retraso del trfico de voz con lo que las llamadas de voz
que utilizan RSVP no podran sacar partido a la PQ disponible en todo LLQ.
En la versin 12.1(3)T y posteriores de Cisco IOS, existe un perfil de prioridad basado en caractersticas de trfico 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
especificacin de flujo de trfico (TSpec) se compara con el perfil para decidir si ese flujo debera sacar partido de la PQ o si la cola debera
reservarse en el sistema WFQ. La TSpec es la descripcin de trfico transportada en mensajes de RSVP. Esta descripcin de trfico se realiza en
trminos de una cubeta con ficha (velocidad de ficha r, ms un tamao de cubeta b) y algunos parmetros adicionales (velocidad mxima p,
unidad mnima regulada m y el tamao mximo del paquete M). El perfil de PQ se define en funcin de la velocidad de ficha, el tamao de
cubeta y una relacin de velocidad mxima opcional con la velocidad de ficha. Las reservas de flujo con una TSpec que no superan las definidas
en el perfil de PQ usarn la PQ. Aquellos flujos con una TSpec que supera al menos un parmetro definido en el perfil obtendrn una cola
reservada en el sistema WFQ. El perfil de prioridad le permite clasificar los flujos de prioridad basndose en las caractersticas del trfico y no
slo 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 trfico se clasifica en
colas diferentes usando varios mtodos, incluido RSVP.
Figura 8: Soporte de RSVP para LLQ en las interfaces de punto a punto
En la versin 12.1(5)T de Cisco IOS se present el soporte de RSVP para LLQ en los PVC de retransmisin por frame (frame relay). En este
caso, cada PVC cuenta con su propia estructura de colocacin en cola con una PQ y un sistema CBWFQ. En la interfaz, se configura una cola
FIFO a menos que haya activado la fragmentacin 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 trfico de la PQ de todos los PVC ms el trfico de control de la Capa 2. La segunda recibir todo el trfico de
todos los PVC. Recuerde que se necesita el modelado de trfico de retransmisin por frame (frame relay) (FRTS) para los circuitos de
retransmisin por frame tanto si la fragmentacin FRF.12 est activada como si no. FRTS ofrece el mecanismo de contrapresin para detectar la
congestin por PVC. El soporte para los PVC ATM est disponible en la versin 12.2(1)T de Cisco IOS.
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 explcita las colas de prioridad para los paquetes de voz. Puede configurar un perfil de cola de prioridad
personalizado mediante el comando de configuracin 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 tamao de cubeta de 592 bytes y una velocidad mxima igual al 110 por ciento de la velocidad de ficha (13.516
bytes por segundo o aproximadamente 108 kbps). Estos valores de parmetros soportan todas las configuraciones de cdec 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 cdec utilizado en el par de marcado. No es posible controlar los valores de TSpec
mediante CLI. No se tendr en cuenta ninguna otra caracterstica de almacenamiento de ancho de banda (como VAD). Algunas revisiones de
Microsoft NetMeeting para Windows 98 y Windows 2000 (que utilizan RSVP) sealan un tamao de cubeta en la TSpec que no es compatible
con estos valores predeterminados. Este problema afecta a Microsoft NetMeeting en las llamadas que utilicen cdecs que necesiten 32 kbps o
ms. En esos casos, tendr que crear un perfil predeterminado para coincidir con los parmetros sealados por Microsoft Windows.
El siguiente ejemplo de configuracin muestra cmo configurar el soporte de RSVP para LLQ en un circuito de retransmisin por frame (frame
relay) que cuenta con dos PVC:
Ejemplo de configuracin 13: soporte de RSVP para LLQ en los PVC de retransmisin por frame (frame relay)
hostname LongBay
!
call rsvp-sync
!
interface Serial0/0
bandwidth 1536
no ip address
no fair-queue
!
interface Serial0/0.1 point-to-point
ip address 10.10.1.2 255.255.255.0
class VoIPoFR
!
interface Serial0/0.2 point-to-point
ip address 10.10.2.2 255.255.255.0
class VoIPoFRip
rsvp bandwidth 48 24
!
ip rsvp pq-profile voice-like
!
map-class frame-relay VoIPoFR
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 fsica. Cada PVC cuenta con una cola de prioridad para el
trfico de voz. La interfaz fsica cuenta con una estructura de cola FIFO dual. FRTS est activado y sus parmetros definidos en la clase de
asignacin VoIPoFR.
Una de las implicaciones importantes del soporte de RSVP para LLQ es que le permite clasificar el trfico de voz segn sus caractersticas de
trfico en lugar de en el protocolo de transporte (UDP) y el nmero de puerto (16384 a 32767). El funcionamiento adecuado de LLQ se basa en la
suposicin de que la cola de prioridad slo se usa para el trfico que se comporta bien (como la voz) con una velocidad predecible y un tamao de
rfaga muy bajo. La clasificacin basada en el protocolo de transporte y los puertos podran permitir trfico intermitente y poco importante en la
cola de prioridad, lo que podra afectar a la calidad de las llamadas de voz existentes y al desempeo del trfico que utilice el sistema WFQ.
Tendr que tener en cuenta los efectos del trfico intermitente o poco importante cuando defina un perfil de cola de prioridad personalizado. Debe
comprender todas las implicaciones en otros tipos de trfico, en concreto, cundo el perfil de PQ podra 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 sealizacin
de voz. Quiz no sea posible iniciar nuevas llamadas durante perodos de mucha congestin debido a la prdida de paquetes de sealizacin. Para
afrontar esta situacin, puede reservar una cantidad de ancho de banda explcitamente para sealar paquetes mediante MQC. Tambin podr
marcar los mensajes de RSVP para un tratamiento especial usando el comando de configuracin de interfaz ip rsvp signaling dscp.
En el siguiente ejemplo de configuracin, se priorizan los paquetes de voz mediante RSVP. A la sealizacin se le garantiza un mnimo de ancho
de banda durante perodos de congestin a travs de MQC:
Ejemplo de configuracin 14: Soporte de RSVP para LLQ + QoS para la sealizacin del trfico
hostname LongBay
!
class-map h323
!
policy-map VOIP_SIG
class h323
set ip dscp 34
bandwidth 96
class class-default
fair-queue
!
call rsvp-sync
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
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 rtp header-compression iphc-format
service-policy output VOIP_SIG
!
no ip address
no cdp enable
!
access-list 101 permit tcp any eq 1720 any

!
voice-port 1/0:23
!

no digit-strip
direct-inward-dial
port 1/0:23
!
!
line con 0
line aux 0
line vty 0 4
En este ejemplo, la lista de acceso 101 coincide con el trfico de sealizacin H.323 hacia y desde el puerto TCP 1720. Este trfico se ubica
en la clase h323, que tiene garantizada 96 kbps de ancho de banda usando LLQ. Con la configuracin de RSVP se puede dar prioridad a la
carga til de voz.

En esta seccin se describe cmo configurar VoIP en una red tpica en la que los enlaces WAN de baja velocidad se utilizan para transportar
trfico de datos y voz. Incluye las siguientes subsecciones:

Una aplicacin tpica de VoIP sera para una gran empresa en la que se usara la infraestructura WAN existente para el trfico 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 tpico en el
que se utilizan los enlaces WAN de baja velocidad para llevar trfico de voz y de datos.
Figura 9: Entorno de red de VoIP tpico
En el caso de enlaces WAN de baja velocidad que no cuenten con los recursos para prestar servicio al trfico de voz, se acentuarn los problemas
tales como los retrasos, fluctuaciones y prdidas. 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 tamao 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 prdidas porque el enlace se congestiona con frecuencia.
Muchas tcnicas de QoS populares que prestan un buen servicio al trfico 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 nmero 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 trfico de datos elstico que se adapta al
ancho de banda disponible, la calidad de voz se vuelve inaceptable despus de demasiadas cadas y retrasos.
RED est especficamente diseado para el trfico TCP. VoIP viaja por encima de UDP. Por tanto, cuando sea posible, debera
clasificarse el trfico de voz y de datos en categoras independientes y RED debera aplicarse a los datos pero no a la voz.
Adems, cada enlace o parte del equipo en la ruta de VoIP aade retraso a la transmisin del paquete de voz. La posibilidad de prdida del
paquete de voz tambin aumenta cuando el trfico de voz se desplaza una distancia mayor y por encima de ms saltos en la red. Normalmente, las
conexiones WAN de baja velocidad son los enlaces ms dbiles.
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 trfico de datos estndar. Esto podra resultar en una prdida considerable de calidad de la conversacin. Para garantizar la calidad de la
voz, debe clasificar el trfico de datos y de voz en distintas categoras y proporcionar manejo de prioridad al trfico de voz en una estructura
bsica de red de datos compartidos. El manejo de prioridad del trfico de voz minimiza los retrasos y las prdidas y, cuando es posible,
proporciona al trfico de voz un desempeo de transmisin predecible. En el caso de los enlaces PPP, recomendamos las siguientes
caractersticas de QoS:
Clasificacin de paquetes mediante MQC
Marcado basado en clases (en el borde DS)
Manejo de prioridad mediante LLQ
CRTP: necesario slo en enlaces de baja velocidad con un nmero bajo de llamadas para la optimizacin del ancho de banda
MP LFI: necesario slo en enlaces de baja velocidad (por debajo de 1,2 Mbps) para garantizar que el tiempo de transmisin de un
fragmento sea inferior a 10 ms
El siguiente ejemplo de configuracin muestra una configuracin completa con todas las caractersticas de QoS enumeradas anteriormente
activadas:
Ejemplo de configuracin 15: QoS para VoIP sobre los enlaces WAN PPP
Comandos Descripcin
class-map voip Crea la clase voip para el trfico de voz que ha sido marcado con la precedencia IP 5
match ip precedence 5
mediante uno de los mtodos de marcado disponibles.
!
class-map webtraffic Crea la clase webtraffic para el trfico web que ha sido marcado con la precedencia IP 3
!
policy-map llq Define la asignacin de polticas de QoS llq: el trfico de clase voip consigue la
class voip
prioridad y est limitado a 64 kbps durante la congestin. A los paquetes de clase
priority 64
class webtraffic webtraffic se les garantizan 64 kbps. El resto del trfico comparte el ancho de banda
bandwidth 64 restante.
class class-default
fair-queue
!
interface Serial1/0 Conecta la interfaz de serie 1/0 a la interfaz de enlaces mltiples en el grupo 1. (Para los
bandwidth 256
anchos de banda de enlaces por encima de 1,2 Mbps, no se necesitar LFI de PPP de
encapsulation ppp
no fair-queue enlaces mltiples ni cRTP. En ese caso, la direccin IP y la declaracin de poltica de
ppp multilink servicio iran bajo la configuracin de la interfaz de serie).
multilink-group 1
!
interface Multilink1 Configura LFI de PPP de enlaces mltiples para enlaces inferiores a 1,2 Mbps.
ip address 10.1.1.1 255.255.255.252
bandwidth 256
!
ip rtp header-compression iphc-format Configura cRTP para reducir los requisitos de ancho de banda de cada llamada de voz.
!
ppp multilink Permite un tamao de fragmentacin de 10 ms.

ppp multilink fragment-delay 10
ppp multilink interleave Permite el entrelazado de paquetes y fragmentos.
multilink-group 1 Conecta la interfaz de enlaces mltiples al grupo 1. Conecta la poltica de QoS llq al
service-policy output llq
trfico saliente en la interfaz de enlaces mltiples.
!
En este ejemplo, el LFI de PPP de enlaces mltiples impide que los paquetes VoIP se retrasen detrs de paquetes de datos de gran tamao,
cRTP reduce los requisitos de ancho de banda de VoIP y LLQ ofrece prioridad al trfico de VoIP y ancho de banda garantizado a otra clase.
Necesita configurar estas caractersticas en ambos extremos del enlace PPP. LFI de PPP de enlaces mltiples slo es necesario en el caso de
enlaces inferiores a 1,2 Mbps. cRTP slo est recomendado en enlaces con un nmero inferior de llamadas VoIP y si el uso de la CPU no es
demasiado intenso.

En esta seccin se describe cmo configurar VoIP en una red tpica en la que los enlaces WAN de retransmisin por frame (frame relay) se
utilizan para transportar trfico de voz. Incluye las siguientes subsecciones:
Otra aplicacin tpica de VoIP sera para una gran empresa en la que se usara la infraestructura existente de trfico de datos WAN de
retransmisin 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 trfico de voz y datos. En el primer caso, deber seguir
dando prioridad al trfico de voz usando una tcnica como Cola de prioridad de interfaz PVC (PIPQ). PIPQ permite asignar varias prioridades
para los PVC: alta, media, normal o baja. PIPQ tambin permite que los PVC se coloquen en cola en la interfaz fsica principal de manera que el
trfico de alta prioridad vaya antes que el trfico de prioridad media, normal y baja. Sin embargo, PIPQ tiene el mismo problema que la
colocacin en cola de prioridad: el trfico de alta prioridad puede privar de ancho de banda al resto del trfico. No obstante, si utiliza el modelado
de trfico de retransmisin por frame (frame relay) correctamente, podr minimizar este problema porque cada PVC tendr una velocidad de
transmisin mxima definida.
En la situacin ms comn, se usa slo un PVC para transportar todo el trfico entre los sitios, tal y como se muestra en la Figura 10.
Figura 10: QoS de VoIP sobre enlaces de retransmisin por frame (frame relay) de baja velocidad
Debe configurar el modelado de trfico de retransmisin 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 conexin T1 en la red de retransmisin 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 direccin a este nico sitio remoto. Los switches de retransmisin por frame (frame relay) colocarn en la memoria intermedia este
trfico en una pequea proporcin pero despus eliminar de forma arbitraria lo que supere los 128 kbps. Tiene que decidir qu debera
eliminarse y a qu debera drsele prioridad en los puntos extremos del PVC.
El modelado de trfico de retransmisin por frame (frame relay) permite que los routers enven trfico a la nube de retransmisin por frame por
debajo de una velocidad configurada previamente. Cualquier trfico por encima de esta velocidad se colocar en cola. Se podr utilizar un
algoritmo de colocacin en cola tal como LLQ para tomar decisiones inteligentes sobre los paquetes que deberan enviarse. Si las colas se llenan,
los paquetes simplemente se eliminarn. Sin embargo, si se ha dado prioridad a VoIP y el trfico total de VoIP est por debajo de la velocidad de
modelado de trfico, los paquetes VoIP recibirn servicio con latencia baja a y no se eliminarn.
En el caso de enlaces con una velocidad inferior a 1,2 Mbps, debe configurar la fragmentacin del paquete para garantizar que un paquete VoIP
no tenga que esperar detrs de un gran paquete. La fragmentacin de paquetes de datos de gran tamao a 10 ms de la velocidad del enlace puede
vincular el perodo mximo de espera. Puede utilizar cRTP para usar de manera eficaz el ancho de banda si el nmero de llamadas no es
demasiado alto.
Para ofrecer alta calidad a VoIP sobre retransmisin por frame (frame relay), debe configurar las siguientes caractersticas:
Modelado de trfico de retransmisin por frame (frame relay):
Defina el comando de configuracin de clase de asociador frame-relay cir en una velocidad de transmisin mxima (debera ser la
velocidad garantizada negociada del proveedor de servicios).
Desactive el comando de configuracin 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 configuracin de clase de asociador frame-relay bc en 1/100 de CIR para permitir que el modelado de trfico
preste servicio a los paquetes, al menos, cada 10 ms.
LFI de FRF.12: slo necesita LFI si la velocidad del puerto del extremo remoto o del hub es inferior a 1,2 Mbps. El tamao de
fragmentacin debera ser 10 ms u 80 bytes multiplicados por el nmero de DS0 (por ejemplo, para 4x64k, el tamao de fragmentacin
debera ser 4x80 = 320 bytes).
LLQ en PVC de retransmisin por frame (frame relay): LLQ se aplica bajo la clase de asignacin para el modelado de trfico de
retransmisin por frame.
cRTP: se aplica bajo la subinterfaz de retransmisin por frame (frame relay). Debera usar cRTP slo si la utilizacin de la CPU es baja y
para un pequeo nmero de llamadas, segn la plataforma.
El siguiente ejemplo de configuracin muestra cmo activar las caractersticas de QoS descritas en la seccin anterior:
Ejemplo de configuracin 16: QoS para VoIP sobre los enlaces WAN de retransmisin por frame (frame relay)
Comandos Descripcin
!
class-map webtraffic Crea la clase webtraffic para el trfico web que ha sido marcado con la precedencia
IP 3 mediante uno de los mtodos de marcado disponibles.
!
policy-map llq Define la asignacin de polticas de QoS llq: el trfico de clase voip consigue la
class voip
prioridad y est limitado a 64 kbps durante la congestin. A los paquetes de clase
priority 64
class webtraffic webtraffic se les garantizan 64 kbps. El resto del trfico comparte el ancho de banda
class class-default
fair-queue
!
interface Serial 0/1 Activa el modelado de trfico de retransmisin por frame (frame relay). Debe activar
no ip address
el modelado de trfico de retransmisin por frame (frame relay) para manejar las
frame-relay traffic shaping discordancias de la velocidad y el exceso de suscripciones. (LLQ por PVC de
! retransmisin por frame (frame relay) tambin necesita el modelado de trfico de
retransmisin por frame).
interface Serial 0/1.64 point-to-point Conecta la clase de modelado de trfico voice a este PVC de retransmisin por frame
ip address 10.14.96.2 255.255.255.252
(frame relay).
class voice
frame-relay ip rtp header-compression Configura cRTP para reducir los requisitos de ancho de banda de cada llamada de
!
voz.
map-class frame-relay voice Desactiva el modelado adaptable. No es recomendable utilizar el modelado adaptable
para VoIP.
frame-relay cir 256000 Define el CIR o la velocidad de transmisin superior a 256 kbps.
frame-relay bc 2560 Define la velocidad de rfaga comprometida en 1/100 de CIR.
frame-relay mincir 256000 Define la velocidad mnima 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 fragmentacin FRF.12 con un tamao de fragmento de 320 bytes.
service-policy output llq! Conecta la poltica de QoS llq a la clase de asignacin definida.
En este ejemplo, el modelado de trfico de retransmisin por frame (frame relay) maneja las discordancias de velocidad. La fragmentacin
FRF.12 evita que los paquetes VoIP se retrasen al colocarse detrs de paquetes de datos de gran tamao. cRTP reduce los requisitos de ancho
de banda de VoIP y LLQ otorga prioridad al trfico de VoIP y garantiza ancho de banda a otra clase. Debe configurar estas caractersticas en
ambos extremos del enlace de retransmisin por frame (frame relay). FRF.12 slo es necesario en el caso de enlaces inferiores a 1,2 Mbps y
cRTP slo est recomendado en enlaces con un nmero inferior de llamadas VoIP y si el uso de la CPU no es muy intenso.

En esta seccin se describe cmo configurar la QoS de VoIP sobre ATM e incluye las siguientes subsecciones:
La tecnologa ATM cuenta con ventajas inherentes en el manejo de trfico de VoIP debido a sus celdas pequeas y de tamao fijo, y a los
mecanismos de clase de servicio (CoS). Estas ventajas no aseguran, sin embargo, que el trfico de VoIP obtenga automticamente la QoS que
necesita de la red ATM que lo lleva. El trfico de VoIP no obtendr de forma automtica la QoS que necesita porque las definiciones de QoS en
la capa IP, tal como la configuracin de la precedencia IP en el encabezado de paquete, no coinciden automticamente con la configuracin de
CoS de ATM, es decir, la clase de trfico (velocidad de bits constante [CBR], velocidad de bits variable [VBR], velocidad de bits disponible
[ABR] y velocidad de bits no definida [UBR]) y los parmetros de trfico como la velocidad de clula sostenida (SCR), la velocidad de clula de
cresta (PCR) y el tamao de rfaga. Por tanto, despus 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 ms propensa a errores y, sobre todo, no tiene capacidad de ampliacin cuando en la red entra
cada vez ms trfico 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.
En el caso de que el trfico 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 trfico IP con un nivel de precedencia IP especfico o un rango de niveles. Despus de configurar los
agrupamientos de PVC, tendr que configurar cada PVC con sus parmetros concretos de QoS de ATM. Conforme el trfico de voz y datos con
distintos niveles de precedencia IP llegan a la interfaz ATM del router, el software Cisco IOS lo enva de forma dinmica 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 mtodo son las siguientes:
Separacin automtica del trfico de voz y datos en PVC distintos.
Conservacin de los servicios diferenciados de la red IP mediante la red ATM.
El siguiente ejemplo de configuracin muestra cmo configurar VoIP sobre ATM usando los agrupamientos de PVC para separar los PVC de
datos y voz:
Ejemplo de configuracin 17: QoS para VoIP sobre ATM con PVC de datos y voz separados
Comandos Descripcin
ip cef Permite la conmutacin de IP de Cisco Express Forwarding (CEF). Debe activar

!
la conmutacin de IP de CEF para que funcione esta solucin.
interface ATM 2/0/0 Crea un grupo de agrupamiento de PVC denominado qosmap.

no ip address
!
interface ATM 2/0/0.1 point-to-point
ip address 10.1.1.2 255.255.255.252
bundle qosmap
protocol ip 10.1.1.1 broadcast Asigna un trfico de precedencia IP 6 y 7 a un identificador de ruta virtual (VPI)
pvc-bundle control 1/100
o a un identificador de canal virtual (VCI) de 1/100.
precedence 6-7
pvc-bundle voice 1/101 Asigna el trfico de precedencia IP 5 (VoIP) a un VPI o VCI de 1/101 con un
vbr-rt 6000 5000 1000
SCR de 5 Mbps y algunas funciones de rfaga.
precedence 5
pvc-bundle web 1/102 Asigna el trfico de precedencia IP 4 a 1/102 con un SCR de 5 Mbps.
cbr 5000
precedence 4
pvc-bundle data 1/103 Asigna otro trfico de precedencia a un PVC con un VPI o VCI de 1/103.
precedence 0-3
En este ejemplo, se asignan cuatro clases de trfico 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 rfagas. El PVC de trfico web tambin tiene
garantizado 5 Mbps pero sin rfagas (CBR). Al trfico de control y al resto de flujos de trfico no se les proporciona ninguna garanta de
velocidad ATM.
Si decide usar PVC distintos para voz y datos, debe ajustar la asignacin de ancho de banda correspondiente en cuanto el trfico de voz crezca
ms 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 trfico de VoIP para tener prioridad absoluta sobre el trfico de
datos al configurar LLQ en el PVC ATM.
En el siguiente ejemplo de configuracin se muestra cmo configurar VoIP sobre ATM usando el mismo PVC para el trfico de datos y de voz:
Ejemplo de configuracin 18: QoS para VoIP sobre ATM usando el PVC de voz y datos compartido
Comandos Descripcin
ip cef Permite la conmutacin de IP de CEF. Debe activar la conmutacin de IP de CEF para que
!
funcione esta solucin.
usando uno de los mtodos de marcado disponibles.
!
class-map webtraffic Crea la clase webtraffic para el trfico web que ha sido marcado con la precedencia IP 3
usando uno de los mtodos de marcado disponibles.
!
policy-map llq Define la asignacin de polticas llq, que define la poltica de QoS: el trfico de clase voip
class voip
consigue la prioridad y est limitado a 1 Mbps durante la congestin. A los paquetes de
priority 1000
class webtraffic clase webtraffic se les garantizan 1 Mbps. El resto del trfico comparte el ancho de banda
class class-default
fair-queue
!
interface ATM2/0/0 Configura los parmetros de modelado de ATM.

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!
service-policy output llq Conecta la asignacin de polticas de QoS llq al PVC ATM.
!
En este ejemplo, LLQ se utiliza en un nico PVC ATM que lleva tanto VoIP como datos. La poltica de LLQ se aplica a una subinterfaz de
ATM para un PVC. El trfico de clase voip obtiene una prioridad de un mximo de 1 Mbps y a la clase webtraffic se le garantiza 1 Mbps
pero no entra dentro de la asignacin de prioridad. El modelado de ATM tambin garantiza que el PVC obtenga una velocidad sostenida de
5 Mbps.
Gua de configuracin de soluciones de calidad de servicio de Cisco IOS, versin 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, versin 12.1

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a00800807a7.html
Gua de configuracin de aplicaciones multiservicio de Cisco IOS, versin 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, versin 12.1

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a0080087c1a.html
Mdulo de caractersticas de COPS para RSVP de la versin 12.1(1)T de Cisco IOS

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/
copsrsvp.htm
Mdulo de caractersticas de marcacin de paquetes basada en la clase de la versin 12.1(2)T de Cisco IOS
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/cbpmark.htm
Mdulo de caractersticas de modelado basado en la clase de la versin 12.1(2)T de Cisco IOS
clsbsshp.htm
Mdulo de caractersticas de mejoras en la compatibilidad de compresin del encabezado de retransmisin por frame (frame relay) de la
versin 12.1(2)T de Cisco IOS
dtfrhccc.htm
Mdulo de caractersticas de cola de latencia baja para retransmisin por frame (frame relay) de la versin 12.1(2)T de Cisco IOS
dtfrpqfq.htm
Mdulo de caractersticas de configuracin del tamao de rfaga en la cola de latencia baja de la versin 12.1(3)T de Cisco IOS
dtcfgbst.htm
Mdulo de caractersticas de soporte de RSVP para la cola de latencia baja de la versin 12.1(3)T de Cisco IOS
rsvp_llq.htm
Mdulo de caractersticas de marcado basado en la clase de la versin 12.1(5)T de Cisco IOS

cbpmark2.htm
Mdulo de caractersticas de colocacin en cola equilibrada y ponderada basada en la clase y la Random Early Detection ponderada
distribuida de la versin 12.1(5)T de Cisco IOS.
dtcbwred.htm
Mdulo de caractersticas de protocolo de tiempo real comprimido distribuido de la versin 12.1(5)T de Cisco IOS
dtdcrtp.htm
Mdulo de caractersticas de cola de latencia baja distribuida de la versin 12.1(5)T de Cisco IOS
dtllqvip.htm
Mdulo de caractersticas de modelado de trfico distribuido de la versin 12.1(5)T de Cisco IOS

dtdts.htm
Mdulo de caractersticas de implementacin de DiffServ para la calidad de servicio de extremo a extremo de la versin 12.1(5)T de Cisco
IOS
dtdfsv.htm
Mdulo de caractersticas de fragmentacin y entrelazado de enlaces para retransmisin por frame (frame relay) y circuitos virtuales de
ATM de la versin 12.1 (5)T de Cisco IOS
dtlfifra.htm
Mdulo de caractersticas de control del trfico de la versin 12.1(5)T de Cisco IOS

dtpoli.htm
Mdulo de caractersticas de control de admisin de llamadas VoIP mediante RSVP de la versin 12.1(5)T de Cisco IOS
dt4trsvp.htm
1992-2014 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generacin del PDF: 14 Abril 2008
http://www.cisco.com/cisco/web/support/LA/8/81/81646_tech_tk652_tk698_tech_white_paper09186a00800d6b73.html

QoS para VoIP Sobre Frame Relay, AMT y PPP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

QoS para VoIP Sobre Frame Relay, AMT y PPP

Uploaded by

Copyright:

Available Formats

Calidad de servicio para Voz sobre IP

Calidad de servicio para Voz sobre IP

Nmero de versin 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 contiene las siguientes secciones:

Informacin general de QoS para VoIP

Ancho de banda suficiente

Mecanismos de colocacin en cola de QoS

Compresin de encabezados IP RTP

Servicios diferenciados para VoIP

Protocolo de reserva de recursos

QoS de VoIP sobre lneas alquiladas (mediante PPP)

QoS de VoIP sobre redes de retransmisin por frame (frame relay)

QoS de VoIP sobre ATM

Informacin general de QoS para VoIP

Soporte de ancho de banda dedicado

Mejora de las caractersticas de prdida

Impedimento y administracin de la congestin de red

Configuracin de las prioridades del trfico a travs de la red

Ancho de banda suficiente

Informacin general de clasificacin de paquetes

Ejemplo de marcado y clasificacin de pares de marcado por voz

Ejemplo de marcado y clasificacin de ndice de acceso comprometido

Ejemplo de marcado y clasificacin del enrutamiento basado en polticas

Ejemplo de marcado y clasificacin de la interfaz de lnea de comandos de QoS modular

Informacin general de clasificacin de paquetes

El comando de configuracin global dial-peer voice voip

Lista de acceso (estndar y extendida)

Clase de servicio (CoS) Ethernet 802.1p

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 prdida de celda (CLP) de ATM

Ejemplo de marcado y clasificacin de pares de marcado por voz

Ejemplo de configuracin 1: Clasificacin y marcado mediante pares de marcado

dial-peer voice 100 voip

Ejemplo de marcado y clasificacin de ndice de acceso comprometido

Ejemplo de configuracin 2: Clasificacin y marcado mediante CAR

access-list 100 permit udp any any range 16384 32767

Ejemplo de marcado y clasificacin del enrutamiento basado en polticas

Ejemplo de configuracin 3: Clasificacin y marcado mediante PBR

access-list 100 permit udp any any range 16384 32767

Ejemplo de marcado y clasificacin de la interfaz de lnea de comandos de QoS modular

Ejemplo de configuracin 4: Clasificacin y marcado mediante MQC

access-list 100 permit udp any any range 16384 32767

Cola de latencia baja

Ejemplo de configuracin de LLQ

Otros mecanismos de colocacin en cola de QoS

Cola de latencia baja

Figura 1: Funcionamiento de LLQ

Ejemplo de configuracin de LLQ

En el siguiente ejemplo de configuracin se muestra cmo configurar LLQ:

Ejemplo de configuracin 5: LLQ

access-list 100 permit udp any any range 16384 32000

Otros mecanismos de colocacin en cola de QoS

En la Tabla 1 se describen algunos de los mecanismos de colocacin en cola de software disponibles.

Tabla 1: Mecanismos de colocacin en cola de software

Informacin general de entrelazado y fragmentacin

Ejemplo de entrelazado y fragmentacin de enlaces MLP

Ejemplo de entrelazado y fragmentacin FRF.12

Informacin general de entrelazado y fragmentacin