Calidad de servicio para Voz sobre IP Contenidos Calidad de servicio para Voz sobre IP Información general de QoS para VoIP Ancho de banda suficiente Clasificación de paquetes Información general de clasificación de paquetes Clasificación y marcado Ejemplo de marcado y clasificación de pares de marcado por voz Ejemplo de marcado y clasificación de índice de acceso comprometido Ejemplo de marcado y clasificación del enrutamiento basado en políticas Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular Mecanismos de colocación en cola de QoS Cola de latencia baja Ejemplo de configuración de LLQ Otros mecanismos de colocación en cola de QoS Fragmentación y entrelazado Información general de entrelazado y fragmentación Ejemplo de entrelazado y fragmentación de enlaces MLP Ejemplo de entrelazado y fragmentación FRF.12 Modelado de tráfico Información general de modelado de tráfico Ejemplo de modelado de tráfico de retransmisión por frame (frame relay) Compresión de encabezados IP RTP Servicios diferenciados para VoIP Información general de DS y DSCP (RFC 2474, RFC 2475) Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598) Ejemplo de configuración de marcado basado en la clase DSCP Protocolo de reserva de recursos Información general de RSVP Información general de RSVP para CAC Implementación de CAC basada en RSVP Configuración de recursos de puertas de enlace locales si CAC falla Uso de RSVP con LLQ Implementación del soporte de RSVP para LLQ QoS de VoIP sobre líneas alquiladas (mediante PPP) VoIP sobre escenario de líneas alquiladas (mediante PPP) Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP) QoS de VoIP sobre redes de retransmisión por frame (frame relay) QoS de VoIP sobre redes de retransmisión por frame (frame relay) Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay) QoS de VoIP sobre ATM QoS de VoIP sobre escenario de ATM QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos Documentos relacionados

Calidad de servicio para Voz sobre IP Historial de la versión

Número de versión

Fecha

Notas

1

16 de abril de 2001

Se creó este documento.

2

15 de mayo de 2001

Se incorporaron los comentarios editoriales.

3

30 de junio de 2001

Se incorporaron comentarios editoriales adicionales.

Calidad de servicio para Voz sobre IP trata los conceptos de la Calidad de Servicio (QoS) y las características aplicables a la voz, en particular, a la Voz sobre IP (VoIP). En este documento también se proporcionan ejemplos de alto nivel en los que se muestran cómo implementar estas características en entornos de red diferentes. Calidad de servicio para Voz sobre IP contiene las siguientes secciones: Información general de QoS para VoIP Ancho de banda suficiente Clasificación de paquetes Mecanismos de colocación en cola de QoS Fragmentación y entrelazado Modelado de tráfico Compresión de encabezados IP RTP Servicios diferenciados para VoIP Protocolo de reserva de recursos QoS de VoIP sobre líneas alquiladas (mediante PPP) QoS de VoIP sobre redes de retransmisión por frame (frame relay) QoS de VoIP sobre ATM Documentos relacionados

Información general de QoS para VoIP Para que la VoIP sea un reemplazo realista para los servicios de telefonía de redes de telefonía pública conmutada estándar (PSTN), los clientes deben recibir la misma calidad de transmisión de voz que reciben con los servicios de telefonía básica, es decir, transmisiones de voz de alta calidad sistemáticamente. Al igual que otras aplicaciones de tiempo real, VoIP es extremadamente sensible al ancho de banda y al retraso. Para que las transmisiones de VoIP sean inteligibles para el receptor, los paquetes de voz no se deben perder ni retrasar excesivamente ni sufrir distintos retrasos (también conocido como "fluctuación"). Por ejemplo, se deben cumplir las siguientes normas: El códec G.729 predeterminado necesita que haya una pérdida de paquetes bastante inferior al 1 por ciento para evitar errores audibles. Lo mejor sería que no se perdieran paquetes para VoIP. La especificación ITU G.114 recomienda un retraso de extremo a extremo unidireccional inferior a 150 milisegundos (ms) para el tráfico en tiempo real de alta calidad como la voz. (Para las llamadas internacionales, se acepta un retraso unidireccional de hasta 300 ms, en especial para las trasmisiones por satélite. Este retraso unidireccional tiene en cuenta el retraso de propagación; es decir, el tiempo necesario para que la señal recorra la distancia). Las memorias intermedias para fluctuación (utilizadas para compensar los diferentes retrasos) se agregan posteriormente al retraso de extremo a extremo y normalmente sólo son efectivas en las variaciones de retraso inferiores a 100 ms. Por tanto, se debe minimizar la fluctuación. VoIP sólo puede garantizar una transmisión de voz de alta calidad si los paquetes de voz, tanto para el canal de audio como para el de señal, tienen prioridad sobre otros tipos de tráfico de red. Para que VoIP se implemente de forma que los usuarios reciban un nivel aceptable de calidad de voz, el tráfico de VoIP debe tener garantizados ciertos requisitos de fluctuación, latencia y ancho de banda de compensación. QoS garantiza que los paquetes de voz VoIP reciban el trato preferente que requieren. En general, QoS proporciona un servicio de red mejor (y más predecible) al proporcionar las siguientes características: Soporte de ancho de banda dedicado Mejora de las características de pérdida Impedimento y administración de la congestión de red

Modelado del tráfico de red Configuración de las prioridades del tráfico a través de la red

Calidad de servicio para Voz sobre IP trata los conceptos de QoS y las características aplicables a la voz, en particular a VoIP.

Ancho de banda suficiente Antes de que se plantee aplicar cualquiera de las características de QoS abordadas en este documento, deberá proporcionar un ancho de banda de red suficiente para soportar el tráfico de voz en tiempo real. Por ejemplo, una llamada G.711 de VoIP de 80 kbps (carga útil de 64 kbps más encabezado de 16 kbps) no será suficiente en un enlace de 64 kbps porque se perderán al menos 16 kbps de los paquetes (es decir, el 20 por ciento). En este ejemplo, también se supone que no fluye más tráfico a través del enlace. Una vez que proporcione un ancho de banda suficiente para el tráfico de voz, podrá dar más pasos para garantizar que los paquetes de voz dispongan de un determinado porcentaje del ancho de banda total y que tengan prioridad.

Clasificación de paquetes La base para proporcionar cualquier QoS reside en la capacidad de un dispositivo de red para identificar y agrupar paquetes específicos. Este proceso de identificación se denomina clasificación de paquetes. Una vez clasificado el paquete, éste debe marcarse estableciendo los bits designados en el encabezado IP. Las siguientes secciones describen la clasificación y el marcado: Información general de clasificación de paquetes Ejemplo de marcado y clasificación de pares de marcado por voz Ejemplo de marcado y clasificación de índice de acceso comprometido Ejemplo de marcado y clasificación del enrutamiento basado en políticas Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular

Información general de clasificación de paquetes Para garantizar el ancho de banda para los paquetes VoIP, un dispositivo de red debe poder identificar los paquetes VoIP en todo el tráfico IP que fluye a través de él. Los dispositivos de red utilizan una dirección IP de origen y de destino en el encabezado IP o en los números de puerto de protocolo de datagrama de usuario (UDP) de origen y de destino en el encabezado de UDP para identificar los paquetes VoIP. Este proceso de agrupamiento e identificación se denomina clasificación y es la base para proporcionar QoS. Aparte de los métodos de clasificación estática que implican la coincidencia de información del encabezado de la Capa 3 o Capa 4, puede utilizar un mecanismo como el protocolo de reserva de recursos (RSVP) para la clasificación dinámica. RSVP utiliza paquetes de señalización H.245 para determinar el puerto UDP que utilizará la conversación de voz. A continuación, configura listas de acceso dinámico para identificar el tráfico de VoIP y coloca el tráfico en una cola reservada. RSVP se abordará más adelante en este documento. La clasificación de paquetes puede ser un procesamiento intensivo, por lo que debería tener lugar lo más lejos posible del borde de la red. Puesto que cada salto necesita realizar una determinación del tratamiento que el paquete debería recibir, necesitará disponer de un método de clasificación más eficiente y más simple en el núcleo de la red. Esta clasificación más simple se logra mediante el marcado o configuración del byte ToS (tipo de servicio) en el encabezado IP. Los tres bits más importantes de byte ToS se denominan bits de precedencia de IP. La mayoría de las aplicaciones y de los proveedores soportan actualmente la configuración y el reconocimiento de estos tres bits. El marcado se lleva a cabo para que los seis bits más significativos del byte ToS, llamados "punto de código de servicios diferenciados" (DSCP), puedan usarse para definir las clases de servicios diferenciados (DS). DSCP se abordará más adelante en este documento. Cuando cada uno de los saltos en la red pueda clasificar e identificar los paquetes VoIP (ya sea mediante información de la dirección del puerto o mediante el byte ToS), dichos saltos podrán entonces proporcionarle a cada paquete VoIP la QoS necesaria. En este punto, se pueden configurar las técnicas especiales para proporcionar almacenamiento en cola prioritario para garantizar que los paquetes de datos grandes no interfieren en la transmisión de datos de voz y para reducir los requisitos de ancho de banda comprimiendo la IP de 40 bytes más UDP más encabezado RTP a entre 2 y 4 bytes. Clasificación y marcado La clasificación es un proceso de identificación de la clase o grupo al que pertenece un paquete. Los dispositivos de red utilizan varios criterios de concordancia para colocar el tráfico en un determinado número de clases. Las concordancias se basan en los siguientes criterios: El comando de configuración global dial-peer voice voip Lista de acceso (estándar y extendida)

Protocolo (por ejemplo, URL, protocolos con estado o protocolo de Capa 4) Puerto de entrada Precedencia IP o DSCP Clase de servicio (CoS) Ethernet 802.1p Como ya se ha mencionado, puede ser un procesamiento intensivo si los nodos deben repetir la clasificación basada en las coincidencias de las listas de acceso. Por lo tanto, los nodos deberían marcar los paquetes en cuanto hayan identificado y clasificado los paquetes VoIP. Si un nodo puede establecer la precedencia IP o los bits DSCP en el byte ToS del encabezado IP en cuanto identifica el tráfico como tráfico de VoIP, los demás nodos de la red pueden clasificar en función de estos bits. El marcado es el proceso del nodo mediante el que establece una de las siguientes opciones: Tres bits de precedencia de IP en el byte ToS de IP. Seis bits de DSCP en el byte ToS de IP Tres bits experimentales de MPLS (EXP) Tres bits de CoS de Ethernet 802.1p Un bit de probabilidad de pérdida de celda (CLP) de ATM En la mayoría de las redes IP, el DSCP o la precedencia IP de marcado debería ser suficiente para identificar el tráfico como de VoIP.

Ejemplo de marcado y clasificación de pares de marcado por voz Con las puertas de enlace de VoIP de Cisco, por lo general, utilizará pares de marcado de voz para clasificar los paquetes VoIP y marcar los bits de precedencia de IP. En el siguiente ejemplo de configuración se muestra cómo marcar los bits de precedencia de IP: Ejemplo de configuración 1: Clasificación y marcado mediante pares de marcado dial-peer voice 100 voip destination-pattern 100 session target ipv4:10.10.10.2 ip precedence 5

En este ejemplo, cualquier llamada VoIP que coincida con el comando dial-peer voice 100 voip tendrá todos los paquetes de carga de voz definidos con la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP están definidos en 101.

Ejemplo de marcado y clasificación de índice de acceso comprometido El índice de acceso comprometido (CAR) es una técnica antigua que implica el control del tráfico o la limitación de velocidad que coincide con determinados criterios en un límite superior. CAR admite la mayoría de los mecanismos de concordancia y permite que los bits de DSCP o de precedencia IP se definan de forma diferente en función de si los paquetes se ajustan a una determinada velocidad o la sobrepasan. En general, CAR resulta más útil para los paquetes de datos que para los de voz. Por ejemplo, todo el tráfico de datos en una interfaz Ethernet de al menos 1 Mbps se puede colocar en una precedencia IP de clase 3 y todo el tráfico con una velocidad superior a un 1 Mbps se puede poner en una clase 1 o perder. Otros nodos de la red pueden así tratar de forma diferente el tráfico excesivo o que no cumpla con las normas marcado con una precedencia IP inferior. Todo el tráfico de voz deberá ajustarse a la velocidad especificada, si se ha configurado correctamente. En el siguiente ejemplo de configuración se muestra cómo utilizar CAR para clasificar y marcar los paquetes VoIP: Ejemplo de configuración 2: Clasificación y marcado mediante CAR access-list 100 permit udp any any range 16384 32767 access-list 100 permit tcp any any eq 1720 ! interface Ethernet0/0 ip address 10.10.10.1 255.255.255.0 rate-limit input

access-group 100 1000000 8000 8000 conform-action set-prec-continue 5 exceed-action set-prec-continue 5

En este ejemplo, el tráfico que coincida con la lista de acceso 100 se establecerá en la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720.

Ejemplo de marcado y clasificación del enrutamiento basado en políticas El enrutamiento basado en políticas (PBR) es otra característica anterior que permite que el tráfico se enrute en función de la lista de acceso o del puerto de origen. También se puede utilizar para clasificar y marcar paquetes. Un ejemplo de configuración simple sería: Ejemplo de configuración 3: Clasificación y marcado mediante PBR access-list 100 permit udp any any range 16384 32767 access-list 100 permit tcp any any eq 1720 ! route-map classify_mark match ip address 100 set ip precedence 5 ! interface Ethernet0/0 ip address 10.10.10.1 255.255.255.0 ip policy route-map classify_mark

En este ejemplo, el tráfico que coincida con la lista de acceso 100 se establecerá en la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720.

Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular El método de marcado y clasificación recomendado es la característica de interfaz de línea de comandos QoS modular (Mod QoS CLI o MQC), un método de configuración basado en plantilla que separa la clasificación de la política, permitiendo que varias características de QoS se configuren conjuntamente para varias clases. Utilice la asignación de clase para clasificar el tráfico en función de varios criterios de coincidencia y una asignación de políticas para determinar qué debería ocurrir con cada clase. A continuación, aplique la política al tráfico entrante o saliente en una interfaz mediante el comando de configuración de interfaz service-policy. En el siguiente ejemplo de configuración se muestra cómo utilizar QoS modular para clasificar y marcar los paquetes: Ejemplo de configuración 4: Clasificación y marcado mediante MQC access-list 100 permit udp any any range 16384 32767 access-list 100 permit tcp any any eq 1720 ! class-map voip match access-group 100 ! policy-map mqc class voip set ip precedence 5 class class-default set ip precedence 0 ! interface Ethernet0/0 service-policy input mqc

En este ejemplo, el tráfico que coincida con la lista de acceso 100 se clasificará como clase voip y se establecerá con la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720. El resto del tráfico se define con precedencia IP 0. La política se denomina mqc y se aplica al tráfico entrante en la interfaz Ethernet 0/0.

Mecanismos de colocación en cola de QoS Una vez que se ha colocado el tráfico en las clases de QoS en función de los requisitos de QoS, necesitará proporcionar garantías de ancho de banda y servicio prioritario a través de un mecanismo de colocación en cola de salida inteligente. En esta sección se describen los mecanismos de colocación en cola y se incluyen las siguientes subsecciones: Cola de latencia baja Ejemplo de configuración de LLQ Otros mecanismos de colocación en cola de QoS

Cola de latencia baja Se requiere una cola de prioridad para VoIP. Puede utilizar cualquier mecanismo de colocación en cola que efectivamente le dé alta prioridad a VoIP, aunque se recomienda una cola de tiempo latencia bajo (LLQ) porque es flexible y fácil de configurar. El método de colocación en cola más flexible que satisface los requisitos de VoIP es la LLQ. LLQ utiliza el método de configuración MQC para priorizar determinadas clases y proporcionar un ancho de banda mínimo garantizado para otras. Durante los períodos de congestión, la cola de prioridad se controla en la velocidad configurada de manera que el tráfico prioritario no monopolice todo el ancho de banda disponible. (Si el tráfico de prioridad monopoliza el ancho de banda, impide que se alcancen las garantías de ancho de banda para otras clases). Si se ofrece LLQ correctamente, el tráfico que vaya a la cola de prioridad nunca debería exceder la velocidad configurada. LLQ también permite que se especifiquen las profundidades de la cola para determinar cuándo el router debería eliminar paquetes si hay demasiados esperando en cualquier cola de clase determinada. También hay un valor predeterminado de clase que se utiliza para definir el tratamiento de todo el tráfico no clasificado por una clase configurada. Es posible configurar la clase predeterminada mediante el comando de configuración de interfaz fair-queue, lo que significa que a cada flujo sin clasificar se le dará una parte más o menos igual del ancho de banda restante. La figura 1 muestra cómo funciona LLQ. Figura 1: Funcionamiento de LLQ

En la Figura 1, todo el tráfico que sale de una interfaz o subinterfaz (para retransmisión por frame (frame relay) y ATM) se clasifica en primer lugar mediante MQC. Existen cuatro clases: una clase de alta prioridad, dos clases de ancho de banda garantizado y una clase predeterminada. El tráfico de clase de prioridad se coloca en una cola de prioridad y el tráfico de clase de ancho de banda garantizado junto a las colas reservadas. Se podrá ofrecer una cola reservada al tráfico de clase predeterminada o colocarlo en una cola predeterminada sin reservar donde cada flujo obtendrá una parte más o menos igual del ancho de banda disponible y sin reservar. El planificador presta servicio a las colas de manera que el tráfico de la cola de prioridad salga en primer lugar a menos que exceda un ancho de banda de prioridad configurado y que una cola reservada lo necesite (es decir, hay congestión). Se presta servicio a las colas reservadas según el ancho de banda reservado, que el planificador utiliza para calcular un peso. El peso se utiliza para determinar la frecuencia con que se presta servicio a una cola reservada y cuántos bytes se ofrecen cada vez. Los servicios del planificador se basan en el algoritmo de colocación en cola equilibrada y ponderada (WFQ), una tema que supera el ámbito de este documento. Si la cola de prioridad se llena porque la velocidad de transmisión del tráfico de prioridad es superior al ancho de banda de prioridad configurado, los paquetes situados al final de la cola de prioridad se eliminarán sólo en el caso de que no haya más ancho de banda sin reservar disponible. No se restringe ninguna de las colas reservadas al ancho de banda configurado si hay ancho de banda disponible. Los paquetes que infrinjan el ancho de banda y la prioridad garantizados sólo se eliminarán durante los periodos de congestión. Por tanto, la cola de prioridad deberá contar con ancho de banda suficiente para manejar todo el tráfico de VoIP que necesite servicio prioritario.

Ejemplo de configuración de LLQ En el siguiente ejemplo de configuración se muestra cómo configurar LLQ: Ejemplo de configuración 5: LLQ access-list 100 permit udp access-list 100 permit tcp access-list 101 permit tcp access-list 102 permit tcp ! class-map voip match access-group 100 class-map data1 match protocol

any any any any

any any any any

range 16384 32000 eq 1720 eq 80 eq 23

class-map data2 match access-group 102 ! policy-map llq class voip priority 32 class data1 bandwidth 64 class data2 bandwidth 32 class class-default fair-queue ! interface Serial1/0 bandwidth 256 service-policy output llq

En este ejemplo, el tráfico que coincida con la lista de acceso 100 será clasificado como clase voip, (lo que quiere decir "tráfico de voz"), y se le dará alta prioridad hasta un máximo de 32 kbps. La lista de acceso 100 coincide con los puertos UDP comunes utilizados por el tráfico de señalización VoIP y H.323 para el puerto TCP 1720. El comando class data1 coincide con el tráfico web (el puerto TCP 80 tal y como se ve en la lista de acceso 101) y garantiza 64 kbps. El comando class data2 coincide con el tráfico Telnet (puerto TCP 23 tal y como se ve en la lista de acceso 102) y garantiza 32 kbps. La clase predeterminada se configura para dar una parte igual del ancho de banda restante a los flujos sin clasificar. La política se denomina llq y se aplica al tráfico saliente en la interfaz de serie 1/0, que tiene un ancho de banda total de 256 kbps. Nota En forma predeterminada, el ancho de banda total garantizado y el ancho de banda de prioridad para todas las clases debería ser inferior al 75 por ciento del ancho de banda de la interfaz. Puede modificar este porcentaje usando el comando de configuración de interfaz max-reserved bandwidth.

Otros mecanismos de colocación en cola de QoS Hay otros métodos de colocación en cola disponibles. Por ejemplo, el Ordenamiento cíclico con déficit modificado (MDRR) es un mecanismo de colocación en cola disponible en las series 12000 de los routers switches Gigabit (GSR) de Cisco que permite la garantía de ancho de banda y el servicio prioritario basado en la precedencia IP, DSCP y clases MPLS EXP. MDRR soporta una cola de prioridad, siete reservadas y una de multidifusión. Una vez más, VoIP necesita prioridad pero hay aplicaciones de datos que no pueden quedarse sin ancho de banda y necesitan garantías de que lo van a tener. Puede usar cualquier mecanismo de colocación en cola que proporcione de hecho alta prioridad a VoIP, aunque recomendamos LLQ. En la Tabla 1 se describen algunos de los mecanismos de colocación en cola de software disponibles. Tabla 1: Mecanismos de colocación en cola de software Mecanismos de colocación en cola de software

Descripción

Beneficios

Limitaciones

FIFO

Los paquetes llegan y dejan la cola exactamente en el mismo orden.

Configuración simple y rápida operación.

No es posible ofrecer el servicio prioritario ni las garantías de ancho de banda.

WFQ

Un algoritmo de hash coloca flujos en colas independientes donde los pesos se utilizan para determinar a cuántos paquetes se presta servicio en cada momento. Los pesos se definen al establecer los valores de precedencia IP y DSCP.

Configuración simple. Valor predeterminado en enlaces inferior a 2 Mbps.

No es posible ofrecer el servicio prioritario ni las garantías de ancho de banda.

Almacenamiento en cola personalizado (CQ)

El tráfico se clasifica en colas múltiples con límites de cola configurables. Los límites de cola se calculan según el tamaño medio del paquete, la unidad de

Ha estado disponible durante algunos años y permite la asignación aproximada de ancho de banda para varias

No es posible la prestación de servicio prioritario. Las garantías de ancho de banda son aproximadas y hay un número limitado de colas. La

transmisión máxima (MTU) y el porcentaje de ancho de banda que se va a asignar. Los límites de cola (en número de bytes) se quitan de la cola para cada cola, por lo que se proporciona el ancho de banda asignado estadísticamente.

colas.

configuración es relativamente difícil.

Priority Queuing (PQ)

El tráfico se clasifica en colas de prioridad alta, media, normal y baja. Primero se presta servicio al tráfico de alta prioridad, después al de prioridad media y, por último, al de prioridad normal y baja.

Ha estado disponible durante algunos años y ofrece prestación de servicios prioritarios.

El tráfico de prioridad más alta puede privar de ancho de banda a las colas de prioridad más bajas. No es posible ofrecer garantía de ancho de banda.

WFQ basado en clases (CBWFQ)

MQC se utiliza para clasificar el tráfico. El tráfico clasificado se coloca en colas de ancho de banda reservado o en una cola predeterminada no reservada. Los planificadores prestan servicio a las colas según los pesos de manera que se cumplan las garantías de ancho de banda.

Es similar a LLQ, a excepción de que no hay una cola prioritaria. Configuración simple y capacidad de proporcionar garantías de ancho de banda.

No es posible la prestación de servicio prioritario.

WFQ de cola de prioridad (PQWFQ, también denominado "prioridad IP RTP")

Se utiliza un comando de interfaz único para ofrecer prestación de servicios de prioridad a todos los paquetes UDP destinados a números de puerto pares dentro de un rango especificado.

Configuración simple de un único comando. Proporciona servicio prioritario a paquetes RTP.

El tratamiento del resto del tráfico se realizará con WFQ. El tráfico RTCP no se prioriza. No hay capacidad de ancho de banda garantizada.

LLQ (denominado anteriormente "PQCBWFQ")

MQC se utiliza para clasificar el tráfico. El tráfico clasificado se coloca en una cola de prioridad, colas de ancho de banda reservado o en una cola no reservada predeterminada. Un planificador se ocupa de las colas basándose en el peso para que el tráfico de prioridad sea enviado primero (hasta un cierto límite regulado durante la congestión) y para que se cumplan las garantías del ancho de banda.

Configuración simple. Capacidad de otorgar prioridad a distintas clases de tráfico y ofrecer más límites sobre la utilización del ancho de banda prioritario. También puede configurar clases de ancho de banda garantizado y una clase predeterminada.

No hay ningún mecanismo para ofrecer varios niveles de prioridad todavía ya que todo el tráfico de prioridad se envía a través de la misma cola de prioridad. Las clases de prioridad independientes pueden tener límites superiores de prioridad de ancho de banda durante la congestión, aunque compartir la cola de prioridad entre aplicaciones puede crear fluctuaciones.

Fragmentación y entrelazado Debido a que las transmisiones de VoIP son extremadamente sensibles a los retrasos, los paquetes VoIP deberán entrelazarse o insertarse entre los fragmentos del paquete de datos. Esta sección describe la fragmentación y el entrelazado e incluye, además, las siguientes subsecciones: Información general de entrelazado y fragmentación Ejemplo de entrelazado y fragmentación de enlaces MLP Ejemplo de entrelazado y fragmentación FRF.12

Información general de entrelazado y fragmentación Aunque la colocación en cola esté funcionando a pleno desempeño y priorizando el tráfico de voz, hay ocasiones en las que la cola de prioridad está vacía y se presta servicio a un paquete de otra clase. Se debe prestar servicio a los paquetes de las clases de ancho de banda garantizado de acuerdo con el peso configurado. Si un paquete de voz con prioridad llega a la cola de salida mientras se está prestando servicio a estos paquetes, el paquete VoIP podría esperar un tiempo considerable antes de ser enviado. Si asumimos que un paquete VoIP tendrá que esperar detrás de un paquete de datos y que puede ser, al menos, igual en tamaño que la MTU (1500 bytes para interfaz de serie y 4470 bytes para interfaces de serie de alta velocidad), podremos calcular el tiempo de espera según la velocidad del enlace. Por ejemplo, en el caso de una velocidad de enlace de 64 kbps y un tamaño de MTU de 1500 bytes, tendremos lo siguiente:

Serialization delay = (1500 bytes * 8 bits/byte) / (64,000 bits/sec) = 187.5 ms Por tanto, es posible que un paquete VoIP tenga que esperar hasta un máximo de 187,5 ms antes de que pueda enviarse si se retrasa detrás de un paquete de 1500 bytes en un enlace de 64 kbps. Por lo general, los paquetes VoIP se envían cada 20 ms. Con un presupuesto de retraso de extremo a extremo de 150 ms y unos requisitos de fluctuación estrictos, una brecha de más de 180 ms es inaceptable. Necesita un mecanismo que garantice que el tamaño de una unidad de transmisión sea inferior a 10 ms. Los paquetes que tengan un retraso de serialización superior a 10 ms tendrán que dividirse en partes de 10 ms. Una parte o fragmento de 10 ms es el número de bytes que puede enviarse por el enlace en 10 ms. Puede calcular el tamaño usando la velocidad del enlace: Fragmentation size = (0.01 seconds * 64,000 bps) / (8 bits/byte) = 80 bytes Se tarda 10 ms en enviar un paquete o fragmento de 80 bytes por un enlace de 64 kbps. En enlaces de baja velocidad donde un paquete de 10 ms de tamaño es más pequeño que la MTU, será necesaria la fragmentación. Sin embargo, la simple fragmentación no es suficiente porque si el paquete VoIP debe esperar detrás de todos los fragmentos de un único paquete de datos de gran tamaño, el paquete VoIP seguirá sufriendo un retraso más allá del límite de retraso de extremo a extremo. El paquete VoIP debe estar entrelazado o insertado entre los fragmentos del paquete de datos. En la Figura 2 se ilustra la fragmentación y el entrelazado. Figura 2: Fragmentación y entrelazado de paquete VoIP

En la Tabla 2 se muestran los tamaños de fragmentos recomendados para varias velocidades de enlace basadas en la regla de los 10 ms. Tabla 2: Velocidad de enlace y tamaño de fragmentación Velocidad de enlace (kbps)

Tamaño de fragmentación (bytes)

56

70

64

80

128

160

256

320

512

640

768

960

1024

1280

1536

1920 (No es necesario realizar una fragmentación si el tamaño del fragmento es mayor que el tamaño del enlace de MTU. Por ejemplo, en el caso de un enlace T1 con un MTU de 1500 bytes, el tamaño del fragmento será 1920 bytes; por tanto, no será necesaria la fragmentación).

Nota El tamaño de fragmentación del paquete nunca debería ser inferior al tamaño del paquete VoIP. Además, nunca debería fragmentar los paquetes VoIP ya que puede causar numerosos de problemas de configuración y de calidad de las llamadas. Hay disponibles tres mecanismos de fragmentación y entrelazado de enlaces (LFI). En la Tabla 3 se muestran sus ventajas y limitaciones. Tabla 3: Velocidad de enlace y tamaño de fragmentación Mecanismo de LFI

Descripción

Beneficios

Limitaciones

Fragmentación de MTU con WFQ

Comando de nivel de interfaz para cambiar el tamaño de MTU o de MTU de IP. Utilizado para fragmentar paquetes IP de gran tamaño en el tamaño de MTU especificado. LFI usa WFQ para entrelazar paquetes en tiempo real entre los fragmentos.

Configuración simple.

Los fragmentos vuelven a ensamblarse únicamente mediante la aplicación de recepción, por lo que el uso de la red es ineficaz. Sólo los paquetes IP con el bit No fragmentar (DF) no definido podrán manejar la fragmentación correctamente. Uso intensivo del procesador. No recomendado.

Fragmentación y entrelazado de enlace (LFI) del protocolo punto a punto de enlaces múltiples (MLP)

En los enlaces seriales de punto a punto, deberá configurarse primero MLP, a continuación, deberá definirse el tamaño de fragmentación en milisegundos. También deberá activarse el entrelazado en la interfaz de enlace múltiple.

Los paquetes se fragmentan en un extremo del enlace y se vuelven a ensamblar en el otro. Es posible combinar varios enlaces para que actúen como un gran conducto virtual.

Únicamente disponible en enlaces configurados para PPP. Las soluciones para PPP sobre retransmisión por frame (frame relay) o PPP sobre ATM también se soportan en la versión 12.1(5)T o posterior de Cisco IOS.

Fragmentación de retransmisión por frame (frame relay) (FRF.12)

En los PVC de retransmisión por frame (frame relay), debe activarse el comando de configuración de interfaz frame-relay trafficshaping y establecerse el tamaño de la fragmentación en la clase de asignación.

Los paquetes se fragmentan en un extremo de PCV y se vuelven a ensamblar en el otro.

Sólo está disponible en los PVC de retransmisión por frame (frame relay) con el comando de configuración de interfaz frame-relay traffic-shaping activado.

Ejemplo de entrelazado y fragmentación de enlaces MLP En el siguiente ejemplo de configuración se muestra cómo configurar la fragmentación y el entrelazado mediante MLP LFI: Ejemplo de configuración 6: MLP LFI interface Serial1/0 bandwidth 256 encapsulation ppp no fair-queue ppp multilink multilink-group 1 ! interface Multilink1 ip address 10.1.1.1 255.255.255.252 bandwidth 256 ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave multilink-group 1

En este ejemplo, se configura MLP LFI con un tamaño de fragmentación de 10 ms, que se calcula según el ancho de banda configurado para la interfaz de enlaces múltiples. La interfaz de serie 1/0 se coloca en el grupo de enlaces múltiples 1 y, por tanto, hereda la configuración de enlace múltiple en la interfaz de enlace múltiple 1.

Ejemplo de entrelazado y fragmentación FRF.12 En el siguiente ejemplo de configuración se muestra cómo configurar la fragmentación y el entrelazado mediante FRF.12: Ejemplo de configuración 7: LFI de fragmentación de retransmisión por frame (frame relay) (FRF.12) interface Serial 0/1 no ip address encapsulation frame-relay frame-relay traffic-shaping !

interface Serial 0/1.64 point-to-point ip address 10.14.96.2 255.255.255.252 frame-relay interface-dlci 128 class voice ! map-class frame-relay voice frame-relay cir 256000 frame-relay fragment 320

En este ejemplo, el modelado de tráfico de retransmisión por frame (frame relay) se activa en DLCI 128. FRF.12 se configura con un tamaño de fragmentación de 320 bytes, que es 10 ms de la velocidad de información comprometida (CIR). El tamaño de fragmentación debería ser 10 ms de la menor velocidad de puerto en los puntos extremos de PVC. En este ejemplo se asume que CIR y la menor velocidad de puerto es la misma: 256 kbps.

Modelado de tráfico El modelado de tráfico es un mecanismo de QoS que se utiliza para enviar tráfico en ráfagas cortas a una velocidad de transmisión configurada. Se utiliza más comúnmente en los entornos de retransmisión por frame (frame relay) donde la velocidad del reloj no es la misma que el ancho de banda garantizado o CIR. En esta sección se describen los mecanismos de modelado de tráfico y se incluyen las siguientes subsecciones: Información general de modelado de tráfico Ejemplo de modelado de tráfico de retransmisión por frame (frame relay)

Información general de modelado de tráfico El modelado de tráfico de retransmisión por frame (frame relay) es la aplicación de modelado de tráfico más común en entornos de VoIP. Los escenarios de retransmisión por frame (frame relay) tienen por lo general una red radial donde la velocidad del enlace de hub es superior a cualquiera de las velocidades de enlace remoto. En algunos casos, la suma de las velocidades de enlace remoto es superior a la velocidad de enlace de hub, lo que provoca un exceso de suscripciones. Sin el modelado de tráfico de retransmisión por frame (frame relay), es posible que el hub trate de enviar a velocidades más altas de las que los remotos pueden recibir, lo que provocará que la red de retransmisión por frame elimine tráfico de forma arbitraria. Sin embargo, los remotos podrían enviar todo a una velocidad agregada superior a la que el hub puede recibir, con lo que de nuevo se provocará que la red de retransmisión por frame (frame relay) elimine tráfico en forma arbitraria. Cuando hablamos de red de retransmisión por frame (frame relay), nos referimos a la red del proveedor de servicio (SP) de los switches WAN que ofrecen la conectividad de PVC de extremo a extremo. Debido a que la nube WAN SP no cuenta con la Capa 3 ni con una inteligencia superior, podrá eliminar tráfico de VoIP si se infringen los contratos. Por tanto, necesita controlar las velocidades de transmisión en una nube de retransmisión por frame (frame relay) de manera que pueda controlar qué paquetes se eliminan y cuáles reciben la prestación de servicio prioritario. En la Figura 3 se muestra un ejemplo de una red típica de retransmisión por frame (frame relay) sin modelado de tráfico. Figura 3: Red de retransmisión por frame (frame relay)

Ejemplo de modelado de tráfico de retransmisión por frame (frame relay) En el siguiente ejemplo de configuración se muestra cómo configurar el modelado de tráfico de retransmisión por frame (frame relay): Ejemplo de configuración 8: Modelado de tráfico de retransmisión por frame (frame relay) interface Serial 0/1 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial 0/1.64 point-to-point ip address 10.14.96.2 255.255.255.252 frame-relay interface-dlci 128 class voice ! map-class frame-relay voice no frame-relay adaptive-shaping frame-relay cir 256000 frame-relay bc 2560 frame-relay mincir 256000

En este ejemplo, el modelado de tráfico de retransmisión por frame (frame relay) está activado en la interfaz de serie principal 0/1 mientras que DLCI 128 se coloca en una clase de modelado para voz. La voz de clase de asignación configura un CIR de 256.000 bps y una velocidad de ráfaga comprometida (Bc) de 2.560 bits. Esta configuración significa que el router enviará 2.560 bits cada 2.560/256.000 segundos (10 ms) y colocará en cola cualquier ráfaga en exceso. El CIR mínimo se define en el mismo valor de CIR y se desactiva el modelado adaptable. El valor de la ráfaga en exceso (Be) de retransmisión por frame (frame relay) no está definido y, por tanto, el valor predeterminado es 0, lo que impide cualquier ráfaga sobre CIR. Esta es la configuración recomendada para el modelado de tráfico cuando lleva VoIP.

Compresión de encabezados IP RTP La compresión de encabezados IP RTP reduce el encabezado IP+UDP+RTP de 40 bytes a un valor de entre 2 y 4 bytes, por lo que se reduce el ancho de banda necesario por llamada de voz en enlaces de punto a punto. El encabezado se comprime en un extremo del enlace y se descomprime en el otro. Otro nombre estándar para esta técnica es cRTP, que quiere decir "RTP comprimido". En la Figura 4 se muestra la funcionalidad de la compresión del encabezado RTP. Figura 4: Compresión de encabezado RTP

Para configurar la compresión de encabezado IP RTP, tendrá que configurar el comando ip rtp header-compression en la interfaz de serie o el comando frame-relay ip rtp header-compression en la subinterfaz de retransmisión por frame (frame relay). También puede configurar el comando de configuración de interfaz ip rtp compression-connections para definir un número máximo de flujos que se comprimirán. Debido a que cRTP puede hacer un uso intensivo del procesador, usted deberá limitar el número de flujos comprimidos para impedir la disminución del desempeño del router. El RTP comprimido está recomendado en enlaces de baja velocidad donde el ancho de banda es escaso y hay pocas llamadas VoIP.

Servicios diferenciados para VoIP El modelo QoS de la arquitectura de servicios diferenciados (DS) ofrece un mecanismo escalable para clasificar paquetes en grupos o clases que cuenten con requisitos de QoS similares. En esta sección se describen los DS y se incluyen las siguientes subsecciones: Información general de DS y DSCP (RFC 2474, RFC 2475) Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598) Ejemplo de configuración de marcado basado en la clase DSCP

Información general de DS y DSCP (RFC 2474, RFC 2475) Las primeras redes IP estaban basadas en el modelo de servicio de mejor esfuerzo, lo que significaba que los retrasos, fluctuaciones, pérdida de paquetes y asignación de ancho de banda no eran predecibles. Hoy en día, un gran número de redes siguen este modelo de mejor esfuerzo y no soportan aplicaciones mejoradas que requieren algún tipo de garantía de servicio. Con el modelo de mejor esfuerzo, los proveedores de servicio no cuentan con medios para ofrecer acuerdos de niveles de servicio (SLA) a sus clientes que no sea abastecer en exceso la red para enfrentarse a las horas de tráfico más intenso. Los clientes de empresa y los usuarios finales no tienen manera de ofrecer el tratamiento de prioridad o el ancho de banda garantizado para VoIP. El tráfico se trata de una forma simple, basada en FIFO, sin aplicación de QoS. El primer enfoque de arquitectura para ofrecer QoS de extremo a extremo necesitaba que la aplicación señalara sus requisitos de recursos de QoS (como el ancho de banda y el retraso garantizado) a la red. En un escenario de VoIP, este enfoque arquitectónico significaba que la telefonía IP o la puerta de enlace de voz necesitaban realizar solicitudes de QoS en cada salto de la red de manera que se asignarían los recursos de extremo a extremo. Cada salto necesitaba mantener la información del estado de la llamada para determinar cuándo liberar los recursos de QoS para las otras llamadas y aplicaciones y, en el caso de que hubiera recursos suficientes disponibles, aceptar las llamadas con garantías de QoS. Este método se denomina "modelo de QoS de servicios integrados". La implementación más común de los servicios integrados utiliza el protocolo de reserva de recursos (RSVP). RSVP cuenta con algunas ventajas, como el Control de admisión de llamadas (CAC), donde una llamada puede volver a enrutarse al enviar una señal adecuada a la persona que llama si la red no cuenta con los recursos de QoS disponibles para soportarla. Sin embargo, RSVP también presenta algunos problemas de escalabilidad, que se tratarán más adelante en este documento. La arquitectura DS es el modelo de QoS más ampliamente implementado y soportado hoy día. Ofrece un mecanismo escalable para clasificar paquetes en grupos o clases que cuenten con requisitos de QoS similares y luego ofrece a estos grupos el tratamiento necesario en cada salto de la red. La escalabilidad proviene del hecho de que los paquetes se clasifican en los bordes de la "nube" o región DS y se marcan de forma adecuada, de manera que los routers del núcleo de la nube puedan ofrecer QoS basado simplemente en la clase DS. Los seis bits más significativos del byte ToS de IP se utilizan para especificar la clase DS. El punto de código de servicios diferenciados (DSCP) será el que defina estos seis bits. Los dos

bits restantes en el byte ToS de IP no se utilizan en la actualidad. En la Figura 5 se muestra cómo el encabezado IP define la clase DS. Figura 5: Definición del campo de servicios diferenciados

Los servicios diferenciados se describen y se definen en los RFC siguientes: RFC 2474, definición del campo de servicio diferenciado (campo DS) RFC 2475, arquitectura para el servicio diferenciado RFC 2597, grupo PHB de reenvíos garantizados RFC 2598, reenvío acelerado PHB RFC 2474 propone una manera de interpretar un campo que siempre ha sido parte de un paquete IP. Tal y como se ha mencionado anteriormente en este documento, el campo ToS describe un byte completo (ocho bits) de un paquete IP. La precedencia se refiere a los tres bits más significativos del byte ToS; es decir, [123]45678. (De vez en cuando, el término ToS se utiliza para referirse a los siguientes tres bits: 123[456]78. No obstante, en este documento, para ser coherentes con la especificación RFC original para el encabezado IP (RFC 791), ToS se refiere al conjunto completo de ocho bits). Los primeros tres bits de DSCP se utilizan como bits de selector de clase, los cuales se encargan de hacer DSCP compatible con la precedencia IP porque ésta utiliza los mismos tres bits para determinar la clase. En la Tabla 4 se muestran los valores de los bits de precedencia de IP asignados a DSCP. Tabla 4: Precedencia IP para la asignación DSCP Precedencia IP

Valor del bit de precedencia de IP

Bits DSCP

Clase DSCP

5

101

101000

Reenvío acelerado

4

100

100000

Reenvío asegurado 4

3

011

011000

Reenvío asegurado 3

2

010

010000

Reenvío asegurado 2

1

001

001000

Reenvío asegurado 1

0

000

000000

Mejor esfuerzo

Los dos bits siguientes se usan para definir la preferencia de eliminación. Por ejemplo, si el tráfico en la Clase 4 (los primeros tres bits son 100) supera una determinada velocidad contratada, los paquetes excedentes podrían volver a marcarse de manera que se alcance la preferencia de eliminación en lugar de eliminarse. Si se produjera la congestión en la nube DS, los primeros paquetes que se eliminarían serían los paquetes de "preferencia de eliminación alta". Esto es parecido al marcado del bit DE en retransmisión por frame (frame relay) y el del bit CLP en ATM. Estos mecanismos permiten que la red de Capa 2 tome decisiones de eliminación inteligentes para el tráfico que no cumpla con las normas en los períodos de congestión. DS permite una acción similar sobre una red IP. El sexto bit debe definirse en 0 para indicar a los dispositivos de red que las clases se definieron según la norma DS. La arquitectura DS define un grupo de acondicionadores de tráfico que se usan para limitar el tráfico en una región DS y colocarlo en las clases DS adecuadas. Los medidores, marcadores, modeladores y eliminadores son acondicionadores de tráfico. Los medidores son, básicamente, reguladores de tráfico. El control de tráfico basado en la clase (que se configura mediante el comando police policy-map configuration debajo de una clase en la?CLI de QoS modular) es una implementación compatible con DS de un medidor. Puede usar el marcado basado en la clase para definir DSCP y el modelado basado en la clase como el modelador. La Random Early Detection ponderada (WRED) es un mecanismo de eliminación soportado, aunque no debería invocar WRED en la clase VoIP. El comportamiento por salto (PHB) describe lo que debería experimentar una clase DS en términos de pérdida, retraso y fluctuación. Un PHB determina cómo se asignará el ancho de banda, se restringirá el tráfico y se eliminarán los paquetes durante la congestión.

En DS se definen tres PHB según el comportamiento de reenvío necesario: Clase de mejor esfuerzo: los bits de selector de clases se definen en 000 PHB de reenvío asegurado: bits de selector de clases definidos en 001, 010, 011 o 100 PHB de reenvío acelerado: bits de selector de clases definidos en 101 La norma de reenvío asegurado (AF) especifica las cuatro clases de ancho de banda garantizado y describe el tratamiento que cada una debería recibir. También especifica los niveles de preferencia de eliminación, con un resultado total de 12 clases AF posibles, tal y como se muestran en la Tabla 5. Tabla 5: Clases posibles de reenvío asegurado Niveles de preferencia de eliminación

Clase AF1

Clase AF2

Clase AF3

Clase AF4

Precedencia de eliminación baja

001010

010010

011010

100010

Precedencia de eliminación media

001100

010100

011100

100100

Precedencia de eliminación alta

001110

010110

011110

100110

Es muy probable que utilice las clases de reenvío asegurado para el tráfico de datos que no necesite tratamiento de prioridad y que esté basado en gran medida en TCP. El reenvío acelerado coincide en gran medida con los requisitos de QoS de VoIP.

Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598) El reenvío acelerado (EF) está diseñado para las aplicaciones sensibles al retraso que necesiten ancho de banda garantizado. Un marcado EF garantiza el servicio prioritario al reservar una cantidad mínima de ancho de banda que pueda usarse para el tráfico de alta prioridad. En EF, la velocidad de salida (o el ancho de banda de prioridad configurado) debe ser superior o igual a la suma de las velocidades de ingreso de manera que no haya congestión para los paquetes marcados como EF. El comportamiento EF se implementa mediante la cola de prioridad estricta en la cola de latencia baja (LLQ). Se garantizará el ancho de banda constante para el tráfico que pertenezca a la clase EF, pero si en el mismo momento hay congestión, los paquetes que no cumplan las normas que superen la velocidad de prioridad especificada se eliminarán para asegurar que los paquetes en las otras colas que pertenezcan a clases distintas no se queden sin ancho de banda. El valor DSCP recomendado para EF es 101110 (46). Los primeros tres bits de este valor EF se corresponden con la precedencia IP 5, que es a su vez el ajuste recomendado del comando de configuración del par de marcado ip precedence para el tráfico de VoIP. Por tanto, si los dispositivos IP de la red pueden reconocer la precedencia IP o DSCP para la clasificación y el marcado, podrá proporcionar QoS de extremo a extremo.

Ejemplo de configuración de marcado basado en la clase DSCP La arquitectura DS especifica cómo clasificar, marcar, regular y modelar el tráfico que entra en una región DS y cómo tratar las diferentes clases en cada salto en la región DS. En el borde DS, todos los paquetes IP se marcan con el DSCP adecuado de manera que se puede ofrecer QoS según el DSCP dentro de la región DS. El siguiente ejemplo de configuración muestra cómo configurar el marcado DSCP en el borde mediante el marcado basado en la clase: Ejemplo de configuración 9: Marcado basado en la clase de DSCP access-list 100 permit udp any any range 16384 32000 access-list 100 permit tcp any any eq 1720 access-list 101 permit tcp any any eq 80 ! class-map voip match access-group 100 class-map webtraffic match access-group 101 ! policy-map dscp_marking class voip set ip dscp 46 #EF Class class webtraffic set ip dscp 26 #AF Class ! interface Ethernet0/0

service-policy input dscp_marking

En este ejemplo, todo el tráfico que entra en una interfaz Ethernet 0/0 se inspecciona y se clasifica según las asignaciones de clasevoip y webtraffic. El comando de configuración global de asignación de políticas define el DSCP en el tráfico de clase voip a 46 (101110 para EF) y el de webtraffic en 26 (011010 para AF3).

Ahora es posible definir la colocación en cola y otros parámetros de QoS para que coincidan con DSCP en el resto de la región DS. En las restantes secciones de este documento, se hará coincidir el tráfico de precedencia IP 5 como VoIP y el tráfico de precedencia IP 3 como HTTP (tráfico web), mientras que el resto del tráfico se dirigirá a la clase predeterminada. De igual forma, se podría utilizar DSCP 46 para VoIP y DSCP 26 para HTTP. Podríamos usar varios mecanismos de clasificación y marcado pero para mantener la coherencia y la simplicidad, usaremos la precedencia IP.

Protocolo de reserva de recursos El protocolo de reserva de recursos (RSVP) es una implementación de la arquitectura de servicios integrados para QoS (RFC 2205). Cuando se introdujo VoIP, RSVP fue considerado inmediatamente como un componente fundamental que ofrecería control de admisión y QoS para flujos de VoIP. Sin embargo, la manera en que se integraron RSVP y H.323 previamente no ofreció control de admisión ni QoS adecuado para los flujos de voz. Se han realizado varias mejoras para corregir estas limitaciones. Ahora, RSVP puede usarse para implementar el CAC y para señalar un QoS deseado que ofrecerá una buena calidad de voz de extremo a extremo aún cuando haya congestión. En esta sección, se describe RSVP (en general) con especial atención a un subconjunto particular de plataformas, topologías y protocolos. También asumimos que está usando H.323 como el protocolo de sesión para una red de VoIP basada en la puerta de enlace. Esta sección incluye a su vez las siguientes subsecciones: Información general de RSVP Información general de RSVP para CAC Implementación de CAC basada en RSVP Configuración de recursos de puertas de enlace locales si CAC falla Uso de RSVP con LLQ Implementación del soporte de RSVP para LLQ

Información general de RSVP La implementación inicial de RSVP para VoIP tenía dos limitaciones. La primera era que el CAC no podía implementarse con RSVP porque el proceso de reserva no estaba sincronizado con la señalización de la llamada de voz. La llamada se produciría aunque la reserva de RSVP hubiera fallado o no se hubiera completado. La segunda limitación era que existía la posibilidad de que una reserva de RSVP correcta no ofreciera una buena calidad de voz durante los períodos de congestión de red. RSVP creó un flujo reservado de cola-por-tráfico dentro del sistema WFQ y confió en ese sistema para garantizar un retraso limitado. Sin embargo, en algunos casos WFQ no era capaz de ofrecer un retraso limitado aceptable para la voz. RSVP tenía que ser capaz de usar la cola de prioridad en LLQ para garantizar un retraso limitado que no afectara a la calidad de la voz. Además, no había soporte para RSVP en ATM ni en los PVC de retransmisión por frame (frame relay) modelados. Debe implementar RSVP para mejorar la QoS de VoIP allí donde sólo pueda tener un impacto positivo en la calidad y funcionalidad. Las ventajas de usar RSVP supera los costes (gestión, tara e impacto del desempeño) pero sólo donde haya ancho de banda limitado y frecuente congestión de red. Algunos entornos IP cuentan con ancho de banda suficiente para garantizar la QoS adecuada sin tener que implementar el CAC para cada llamada. En el software Cisco IOS se introdujeron los siguientes cuatro mecanismos para manejar el CAC basado en recursos: Repliegue de PSTN: este método se basa en el sondeo de la red para medir el retraso, la fluctuación y las pérdidas a fin de estimar los problemas potenciales de voz que la llamada puede sufrir. (Este problema potencial se denomina "factor de defecto de planificación calculado" (ICPIF) y se explica en ITU-T G.113). Gracias a este mecanismo, podrá definir varios umbrales de manera que las llamadas se rechacen si una red IP está congestionada. CAC definido en recursos de puertas de enlace locales como CPU, memoria y el número de llamadas: gracias a este método, puede configurar umbrales que activarán diferentes acciones, como devolución y rechazo de llamadas, o reproducción de un mensaje. Gestión de ancho de banda mediante el control de acceso H.323: en este método, podrá configurar una cantidad máxima de ancho de banda que los controles de acceso podrán asignar a las llamadas.

RSVP. En este documento, sólo trataremos el uso de RSVP para el CAC.

Información general de RSVP para CAC El uso de RSVP para el CAC de VoIP necesita la sincronización de la señalización de la configuración de la llamada y la señalización de RSVP. Esta sincronización garantiza que el teléfono de la parte llamada sólo suene después de que los recursos de la llamada se hayan reservado. Esta sincronización también proporciona a las puertas de enlace de voz el control de la acción que hay que realizar antes de que la configuración de la llamada pase a la etapa de alerta si la reserva falla o no puede completarse dentro de un período de tiempo predefinido. La llamada de voz activará dos reservas de RSVP porque los mecanismos de reserva y control de admisión ofrecidos por RSVP son unidireccionales. Cada puerta de enlace de voz es responsable de iniciar y mantener una reserva hacia la otra puerta de enlace de voz. El CAC para una llamada VoIP falla si falla al menos una de las reservas. En la Figura 6 se muestra la secuencia de paquetes intercambiados entre las puertas de enlace durante una configuración de llamada si se usa RSVP en la reserva de recursos. Figura 6: Configuración de llamada con RSVP activado

En la Figura 6, una puerta de enlace de origen (OGW) inicia una llamada hacia una puerta de enlace de destino (TGW). La puerta de enlace de origen envía un mensaje SETUP de H.323 a la puerta de enlace de destino para iniciar la llamada. Dicho mensaje lleva la QoS que la puerta de enlace de origen considera aceptable para la llamada. La puerta de enlace de destino responde con un mensaje CALL PROCEEDING de H.323. Tanto el puerta de enlace de origen como la de destino inician una solicitud de reserva enviando un mensaje PATH de RSVP. Los flujos de paquete de ambas reservas son independientes entre ellos a menos que uno de ellos falle. La puerta de enlace de destino bloquea el proceso de configuración de llamada que está a la espera de los resultados de la reserva. La puerta de enlace de destino controla la decisión de admisión de la llamada y necesita que se le notifique de que las reservas en ambas direcciones son correctas. La puerta de enlace de destino descubre que la reserva se ha realizado correctamente cuando recibe el mensaje RESV de RSVP. La puerta de enlace de destino detecta que la reserva de la puerta de enlace de origen se ha realizado correctamente cuando recibe un mensaje RESV CONFIRMATION de RSVP procedente de la puerta de enlace de origen. En este punto, la puerta de enlace de destino permite que la configuración de llamada continúe y envía un mensaje ALERTING de H.323 a la puerta de enlace de origen una vez que se le notifique que el lado llamado se encuentra en estado de alerta. Se iniciará una desconexión normal cuando se envía un mensaje RELEASE COMPLETE de H.323 después de que se haya conectado la llamada. En este punto, las puertas de enlace cerrarán las reservas enviando mensajes RSVP PATH TEAR y RESV TEAR. Si falla al menos una de las reservas de RSVP, podrá configurar una puerta de enlace de voz para realizar las acciones siguientes: La puerta de enlace de voz puede informar acerca del fallo de la llamada al usuario o al switch que la ha entregado. La llamada puede volver a enrutarse a través de otra ruta. Se puede conectar la llamada con la QoS de mejor esfuerzo. Este último comportamiento es posible debido a que la puerta de enlace de destino sabe qué QoS es aceptable para la llamada desde su propia configuración y para el valor incluido por la puerta de enlace de origen en el mensaje SETUP de H.323. Si las puertas de enlace de destino y origen solicitan QoS que no sea de mejor esfuerzo y, al menos, una reserva falla, la llamada sólo se realizará como mejor esfuerzo si las puertas de enlace de origen y destino desean aceptar el servicio de mejor esfuerzo. La liberación de la llamada y el reenrutamiento son posibles si una de las dos puertas de enlace de voz no aceptan el servicio de mejor esfuerzo. Si configura la puerta de enlace para rechazar la llamada e informar el fallo, los troncales de CAS y las líneas analógicas generan una señal de ocupado rápido. En los troncales CCS PRI, se generará un mensaje DISCONNECT de Q.931 y la causa que indica que QoS no está disponible (49). En la Figura 7 se muestran los detalles de una llamada que se ha rechazado porque se ha producido un error en la reserva iniciada desde la puerta de enlace de destino. Figura 7: Fallo de llamada en el CAC de RSVP debido a un fallo en la reserva de puerta de enlace de destino

Implementación de CAC basada en RSVP Tal y como se ha mencionado anteriormente, debería implementar RSVP para mejorar la QoS de VoIP allí donde sólo pueda tener un impacto positivo en la calidad y funcionalidad. Las ventajas de usar RSVP superan los costes sólo donde el ancho de banda es limitado. Recomendamos el uso de la versión 12.1(5)T o superior de Cisco IOS si desea implementar CAC para VoIP mediante RSVP. Debe realizar los siguientes tres pasos básicos para configurar CAC para las llamadas VoIP mediante RSVP:

Activar la sincronización entre RSVP y la señalización de llamadas. Esta sincronización está activada en forma predeterminada cuando la versión 12.1(5)T o posterior de Cisco IOS se está ejecutando. Configure las puertas de enlace de voz en ambos lados de los pares de marcado de VoIP para solicitar una QoS particular mediante RSVP. Active RSVP y especifique el ancho de banda máximo en todos los enlaces que atraviesan los paquetes de voz donde es probable que ocurra la congestión. En el siguiente ejemplo de configuración se muestra cómo configurar CAC para llamadas VoIP mediante RSVP: Ejemplo de configuración 10: Implementación de CAC mediante SVP hostname LongBay ! isdn switch-type primary-ni call rsvp-sync ! controller T1 1/0 framing esf linecode b8zs pri-group timeslots 1-24 ! interface Ethernet0/0 ip address 10.0.152.254 255.255.255.0 ! interface Serial0/0 bandwidth 1536 ip address 10.10.1.1 255.255.255.0 encapsulation ppp ip tcp header-compression iphc-format ip rtp header-compression iphc-format ip rsvp bandwidth 1152 24 ! interface Serial1/0:23 no ip address no logging event link-status isdn switch-type primary-ni isdn incoming-voice voice no cdp enable ! ip route 0.0.0.0 0.0.0.0 10.10.1.2 ! voice-port 1/0:23 ! dial-peer voice 100 pots destination-pattern 2...... no digit-strip direct-inward-dial port 1/0:23 ! dial-peer voice 300 voip destination-pattern 3...... session target ipv4:10.77.39.129 req-qos guaranteed-delay acc-qos guaranteed-delay ! line con 0 line aux 0 line vty 0 4 ! end

Este ejemplo muestra una configuración de puerta de enlace de voz completa que describe los comandos para configurar CAC mediante RSVP. La puerta de enlace de voz puede actuar como una puerta de enlace de origen y destino con esta configuración. No hemos priorizado la señalización de la voz en este ejemplo.

La configuración predeterminada del par de marcado solicita y acepta QoS de mejor esfuerzo para llamadas VoIP. Esto se traduce en que la puerta de enlace no inicia una reserva de RSVP para la llamada porque IP ofrece el servicio de mejor esfuerzo en forma predeterminada. Las otras dos alternativas de servicio son QoS de carga controlada o retraso garantizado. Estos servicios exigen la señalización de RSVP. Se solicitan

mediante el comando de configuración del par de marcado req-qos. La QoS aceptable controla cuán estrictos o permisivos deberían ser los criterios de CAC. Los controles de QoS aceptables se configuran mediante el comando de configuración del par de marcado acc-qos. Recomendamos que configure la puerta de enlace de origen y la de destino para solicitar y aceptar el retraso garantizado. En ocasiones, puede configurar la coincidencia del par de marcado implícito en una puerta de enlace de destino para solicitar y aceptar la QoS de mejor esfuerzo. Este par de marcado surte efecto cuando no hay una coincidencia explícita del par de marcado.

Configuración de recursos de puertas de enlace locales si CAC falla Tal y como se ha mencionado anteriormente, puede configurar una puerta de enlace de voz para que realice distintas acciones si el control de admisión falla. La primera alternativa es que la señal de las puertas de enlace envíen una señal al usuario o al switch que ha entregado la llamada con una señal de ocupado rápido o con una causa de desconexión. Si la llamada se ha entregado a la puerta de enlace mediante un switch de ISDN, podrá ajustar la causa de desconexión Q.931 para garantizar que el switch maneje las llamadas correctamente. En forma predeterminada, se devuelve la causa de QoS no disponible (49) cuando se produce un error de CAC en una llamada de ISDN debido a la QoS solicitada y aceptable configurada. Puede modificar esta causa con los comandos de configuración de interfaz isdn network-failure-cause o isdn disconnect-cause. La implementación actual del comando isdn network-failure-cause anula el valor configurado mediante el comando isdn disconnect-cause. El siguiente ejemplo de configuración muestra cómo configurar los recursos de puerta de enlace locales si se produce un error en CAC al ajustar la causa de desconexión Q.931: Ejemplo de configuración 11: Ajuste de la causa de desconexión Q.931 ! interface Serial1/0:23 no ip address no logging event link-status isdn switch-type primary-ni isdn network-failure-cause 42 isdn incoming-voice voice no cdp enable !

En este ejemplo, el router envía un mensaje DISCONNECT de Q.931 con una causa que indica que hay congestión en el equipo de conmutación (42) cuando se produce un error de CAC en una llamada ISDN en el tramo de VoIP.

La segunda opción es permitir que la puerta de enlace vuelva a enrutar la llamada a través de otra ruta. Si el par de marcado que coincide con la llamada forma parte de un grupo de búsqueda, se probarán otros pares de marcado en ese grupo según el comando de configuración del par de marcado preference. De esta manera, se permite que implemente diferentes tipos de enrutamiento de llamada en la puerta de enlace que considera QoS en las redes IP. En el siguiente ejemplo de configuración se muestra cómo configurar los recursos de puertas de enlace locales al volver a enrutar llamadas en la puerta de enlace si se produce un error de CAC: Ejemplo de configuración 12: Reenrutamiento de llamadas en la puerta de enlace dial-peer voice 100 pots destination-pattern 2...... no digit-strip direct-inward-dial port 1/0:23 ! dial-peer voice 300 voip preference 0 destination-pattern 3...... session target ipv4:10.77.39.129 req-qos guaranteed-delay acc-qos guaranteed-delay ! dial-peer voice 400 voip preference 2 destination-pattern 3...... session target ipv4:10.23.45.2 req-qos guaranteed-delay acc-qos guaranteed-delay ! dial-peer voice 500 pots preference 5 destination-pattern 3......

no digit-strip direct-inward-dial port 1/1:23

!

Este ejemplo muestra una implementación del reenrutamiento de llamadas en la puerta de enlace. Las llamadas a números de siete dígitos que comiencen con el dígito 3, prueban dos puertas de enlace de voz en primer lugar. Las llamadas se enrutan mediante la PSTN a través del puerto de voz 1/1:23 si se producen errores en las llamadas VoIP debido al CAC o a cualquier otra razón.

La tercera posibilidad, disponible en las versiones de Cisco IOS posteriores a la 12.1(5)T, es configurar las puertas de enlace para seguir con la llamada aún cuando se produzcan errores en las reservas de RSVP. Esta opción, sin embargo, no ofrece una mejora sustancial frente a la funcionalidad de versiones anteriores de Cisco?IOS. El único beneficio que ofrece es que, en caso de una reserva válida de RSVP, la llamada no se produce hasta que no se haya establecido la reserva. Tal y como se ha mencionado anteriormente, se puede producir un error de la llamada en el control de admisión si falla al menos una de las dos reservas de RSVP necesarias para la llamada. Para cada reserva de RSVP, el control de admisión se realiza en todas las interfaces donde se haya activado RSVP usando el comando de configuración de interfaz ip rsvp bandwidth. Puede configurar dos valores con el comando ip rsvp bandwidth: el ancho de banda máximo total reservado y el ancho de banda máximo por reserva. El ancho de banda máximo total está limitado en forma predeterminada a no más del 75 por ciento del ancho de banda total de la interfaz. Puede modificar ese límite con el comando de configuración de interfaz max-reserved-bandwidth. Las excepciones a la limitación de ancho de banda máximo total son PVC de retransmisión por frame (frame relay) y ATM. En el caso de PVC de retransmisión por frame (frame relay), al ancho de banda máximo reservable es el CIR mínimo o, si no está configurado, la mitad del CIR. Para los PVC ATM, el ancho de banda máximo reservable es el 75 por ciento de la velocidad mínima de celda de salida de la velocidad de bits disponible, cerca de la SCR de salida de VBR en tiempo real o la velocidad media de VBR en tiempo real, sea cual sea la que esté configurada. El ancho de banda total disponible para las reservas de RSVP puede ser inferior si ya tiene ancho de banda reservado usando CBWFQ o LLQ mediante MQC. El administrador de ancho de banda se asegura de que la interfaz o el ancho de banda de PVC no ha recibido suscripciones en exceso durante la operación del router. Nota Esta comprobación no se realiza durante la configuración del router.

Debería configurar el ancho de banda máximo por reserva que no sea inferior al que el códec necesita más toda la tara de protocolo excepto la de la Capa 2. En la Tabla 6 se muestran los valores más bajos que puede usar para códecs diferentes. Recuerde que estos valores no darán cuenta de los ahorros de ancho de banda introducidos por cRTP o la detección de la actividad de voz (VAD). La secuencia de voz real puede usar menos ancho de banda pero el sistema usará el peor ancho de banda. Tabla 6: Ancho de banda reservado por RSVP por llamada VoIP Códec

Ancho de banda reservado por llamada VoIP (kbps)

G711alaw

80

G711ulaw

80

G723ar53

22

G723ar63

23

G723r53

22

G723r63

23

G726r16

32

G726r24

40

G726r32

48

G728

32

G729br8

24

G729r8

24

GSMEFR

29

GSMFR

30

Una consideración que hay que tener en cuenta al implementar RSVP para VoIP es el impacto de la reserva de recursos en el retraso posterior al marcado. La implementación del CAC de VoIP basada en RSVP depende de una confirmación o rechazo del mensaje de la reserva solicitada. El tiempo que se ha tomado para reservar los recursos se añade al retraso posterior al marcado, que debería mantenerse tan bajo como sea posible en la mayoría de los casos. Los paquetes de RSVP se transportan dentro de datagramas IP y son no confiables por naturaleza. Si se pierde un paquete de RSVP durante la configuración de reserva inicial, deberá caducar un temporizador de actualización de RSVP antes de que el paquete perdido se reenvíe. Debido a que el temporizador de actualización se define normalmente en decenas de segundos, la situación en la que se puede añadir un retraso posterior al marcado no es aceptable para el usuario. El comando de configuración global call rsvp-sync resv-timer permite controlar el tiempo máximo que la puerta de enlace de destino esperará el resultado de las solicitudes de reserva de RSVP. El valor predeterminado de este temporizador es 10 segundos. Puede definirlo en un valor de 1 a 60 segundos de acuerdo con la expectativa de un retraso de marcado posterior.

Uso de RSVP con LLQ Los flujos que soliciten una QoS concreta mediante RSVP pueden sacar partido de las alternativas de colocación en cola disponibles en LLQ, el cual tiene dos componentes principales: una cola de prioridad (PQ) y un sistema CBWFQ. Las implementaciones anteriores de RSVP se basan en WFQ para ajustarse a los requisitos de QoS correspondientes al tráfico sensible al retraso. Se creó una cola reservada con un peso inferior cuando se instaló la reserva de RSVP. Sin embargo, WFQ podría no ajustarse a los requisitos de retraso del tráfico de voz con lo que las llamadas de voz que utilizan RSVP no podrían sacar partido a la PQ disponible en todo LLQ. En la versión 12.1(3)T y posteriores de Cisco IOS, existe un perfil de prioridad basado en características de tráfico de manera que algunos flujos puedan sacar partido de la PQ estricta en LLQ. Cuando se recibe una solicitud de reserva de RSVP en una interfaz donde haya activado WFQ, la especificación de flujo de tráfico (TSpec) se compara con el perfil para decidir si ese flujo debería sacar partido de la PQ o si la cola debería reservarse en el sistema WFQ. La TSpec es la descripción de tráfico transportada en mensajes de RSVP. Esta descripción de tráfico se realiza en términos de una cubeta con ficha (velocidad de ficha r, más un tamaño de cubeta b) y algunos parámetros adicionales (velocidad máxima p, unidad mínima regulada m y el tamaño máximo del paquete M). El perfil de PQ se define en función de la velocidad de ficha, el tamaño de cubeta y una relación de velocidad máxima opcional con la velocidad de ficha. Las reservas de flujo con una TSpec que no superan las definidas en el perfil de PQ usarán la PQ. Aquellos flujos con una TSpec que supera al menos un parámetro definido en el perfil obtendrán una cola reservada en el sistema WFQ. El perfil de prioridad le permite clasificar los flujos de prioridad basándose en las características del tráfico y no sólo en el protocolo de transporte y el puerto. En la Figura 8 se muestra la estructura de LLQ para una interfaz en la que el tráfico se clasifica en colas diferentes usando varios métodos, incluido RSVP. Figura 8: Soporte de RSVP para LLQ en las interfaces de punto a punto

En la versión 12.1(5)T de Cisco IOS se presentó el soporte de RSVP para LLQ en los PVC de retransmisión por frame (frame relay). En este caso, cada PVC cuenta con su propia estructura de colocación en cola con una PQ y un sistema CBWFQ. En la interfaz, se configura una cola FIFO a menos que haya activado la fragmentación FRF.12. En ese caso, se configurará un sistema FIFO dual con una cola de alta prioridad y otra de baja. La primera recibirá el tráfico de la PQ de todos los PVC más el tráfico de control de la Capa 2. La segunda recibirá todo el tráfico de todos los PVC. Recuerde que se necesita el modelado de tráfico de retransmisión por frame (frame relay) (FRTS) para los circuitos de retransmisión por frame tanto si la fragmentación FRF.12 está activada como si no. FRTS ofrece el mecanismo de contrapresión para detectar la congestión por PVC. El soporte para los PVC ATM está disponible en la versión 12.2(1)T de Cisco IOS.

Implementación del soporte de RSVP para LLQ El soporte de RSVP se activa para LLQ en forma predeterminada para los flujos de voz en interfaces donde se activan RSVP y WFQ. No es necesario que configure en forma explícita las colas de prioridad para los paquetes de voz. Puede configurar un perfil de cola de prioridad personalizado mediante el comando de configuración global ip rsvp pq-profile. Configurar el perfil como ip rsvp pq-profile voice-like restaura el comportamiento predeterminado. El perfil de cola de prioridad predeterminado utiliza una velocidad de ficha de 12.288 bytes por segundo (aproximadamente 98 kbps), un tamaño de cubeta de 592 bytes y una velocidad máxima igual al 110 por ciento de la velocidad de ficha (13.516 bytes por segundo o aproximadamente 108 kbps). Estos valores de parámetros soportan todas las configuraciones de códec posibles en las puertas de enlace de voz que ejecuten el software Cisco IOS. La puerta de enlace de voz de Cisco configurada para reservar recursos mediante RSVP inferirá la TSpec correcta en forma exclusiva a partir del códec utilizado en el par de marcado. No es posible controlar los valores de TSpec mediante CLI. No se tendrá en cuenta ninguna otra característica de almacenamiento de ancho de banda (como VAD). Algunas revisiones de Microsoft NetMeeting para Windows 98 y Windows 2000 (que utilizan RSVP) señalan un tamaño de cubeta en la TSpec que no es compatible

con estos valores predeterminados. Este problema afecta a Microsoft NetMeeting en las llamadas que utilicen códecs que necesiten 32 kbps o más. En esos casos, tendrá que crear un perfil predeterminado para coincidir con los parámetros señalados por Microsoft Windows. El siguiente ejemplo de configuración muestra cómo configurar el soporte de RSVP para LLQ en un circuito de retransmisión por frame (frame relay) que cuenta con dos PVC: Ejemplo de configuración 13: soporte de RSVP para LLQ en los PVC de retransmisión por frame (frame relay) hostname LongBay ! isdn switch-type primary-ni call rsvp-sync ! interface Serial0/0 bandwidth 1536 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point ip address 10.10.1.2 255.255.255.0 frame-relay interface-dlci 16 class VoIPoFR ip rsvp bandwidth 48 24 ! interface Serial0/0.2 point-to-point ip address 10.10.2.2 255.255.255.0 frame-relay interface-dlci 17 class VoIPoFRip rsvp bandwidth 48 24 ! ip rsvp pq-profile voice-like ! map-class frame-relay VoIPoFR no frame-relay adaptive-shaping frame-relay cir 64000 frame-relay bc 640 frame-relay mincir 64000 frame-relay fair-queue frame-relay fragment 80 !

En este ejemplo, WFQ está activado en los PVC y desactivado en la interfaz física. Cada PVC cuenta con una cola de prioridad para el tráfico de voz. La interfaz física cuenta con una estructura de cola FIFO dual. FRTS está activado y sus parámetros definidos en la clase de asignación VoIPoFR.

Una de las implicaciones importantes del soporte de RSVP para LLQ es que le permite clasificar el tráfico de voz según sus características de tráfico en lugar de en el protocolo de transporte (UDP) y el número de puerto (16384 a 32767). El funcionamiento adecuado de LLQ se basa en la suposición de que la cola de prioridad sólo se usa para el tráfico que se comporta bien (como la voz) con una velocidad predecible y un tamaño de ráfaga muy bajo. La clasificación basada en el protocolo de transporte y los puertos podrían permitir tráfico intermitente y poco importante en la cola de prioridad, lo que podría afectar a la calidad de las llamadas de voz existentes y al desempeño del tráfico que utilice el sistema WFQ. Tendrá que tener en cuenta los efectos del tráfico intermitente o poco importante cuando defina un perfil de cola de prioridad personalizado. Debe comprender todas las implicaciones en otros tipos de tráfico, en concreto, cuándo el perfil de PQ podría dejar entrar flujos con grados de intermitencia en la cola de prioridad. El soporte de RSVP para LLQ da prioridad a los paquetes de voz pero no está pendiente de la señalización de voz. Quizá no sea posible iniciar nuevas llamadas durante períodos de mucha congestión debido a la pérdida de paquetes de señalización. Para afrontar esta situación, puede reservar una cantidad de ancho de banda explícitamente para señalar paquetes mediante MQC. También podrá marcar los mensajes de RSVP para un tratamiento especial usando el comando de configuración de interfaz ip rsvp signaling dscp. En el siguiente ejemplo de configuración, se priorizan los paquetes de voz mediante RSVP. A la señalización se le garantiza un mínimo de ancho de banda durante períodos de congestión a través de MQC: Ejemplo de configuración 14: Soporte de RSVP para LLQ + QoS para la señalización del tráfico hostname LongBay ! class-map h323 match access-group 101 ! policy-map VOIP_SIG

class h323 set ip dscp 34 bandwidth 96 class class-default fair-queue

! isdn switch-type primary-ni call rsvp-sync ! controller T1 1/0 framing esf linecode b8zs pri-group timeslots 1-24 ! interface Ethernet0/0 ip address 10.0.152.254 255.255.255.0 ! interface Serial0/0 bandwidth 1536 ip address 10.10.1.1 255.255.255.0 encapsulation ppp ip tcp header-compression iphc-format ip rtp header-compression iphc-format service-policy output VOIP_SIG ip rsvp bandwidth 1152 24 ! interface Serial1/0:23 no ip address no logging event link-status isdn switch-type primary-ni isdn incoming-voice voice no cdp enable ! access-list 101 permit tcp any eq 1720 any access-list 101 permit tcp any any eq 1720 ! voice-port 1/0:23 ! dial-peer voice 100 pots destination-pattern 2...... no digit-strip direct-inward-dial port 1/0:23 ! dial-peer voice 300 voip destination-pattern 3...... session target ipv4:10.77.39.129 req-qos guaranteed-delay acc-qos guaranteed-delay ! line con 0 line aux 0 line vty 0 4

En este ejemplo, la lista de acceso 101 coincide con el tráfico de señalización H.323 hacia y desde el puerto TCP 1720. Este tráfico se ubica en la clase h323, que tiene garantizada 96 kbps de ancho de banda usando LLQ. Con la configuración de RSVP se puede dar prioridad a la carga útil de voz.

QoS de VoIP sobre líneas alquiladas (mediante PPP) En esta sección se describe cómo configurar VoIP en una red típica en la que los enlaces WAN de baja velocidad se utilizan para transportar tráfico de datos y voz. Incluye las siguientes subsecciones: VoIP sobre escenario de líneas alquiladas (mediante PPP) Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP)

VoIP sobre escenario de líneas alquiladas (mediante PPP) Una aplicación típica de VoIP sería para una gran empresa en la que se usaría la infraestructura WAN existente para el tráfico de datos con objeto de transportar las llamadas de voz entre sus oficinas principales y las sucursales. En la Figura 9 se muestra un entorno de red de VoIP típico en el

que se utilizan los enlaces WAN de baja velocidad para llevar tráfico de voz y de datos. Figura 9: Entorno de red de VoIP típico

En el caso de enlaces WAN de baja velocidad que no cuenten con los recursos para prestar servicio al tráfico de voz, se acentuarán los problemas tales como los retrasos, fluctuaciones y pérdidas. En este entorno de red concreto, los siguientes factores pueden contribuir a que la calidad de la voz sea deficiente: Los paquetes de datos de gran tamaño enviados antes que los de voz provocan largos retrasos. Los paquetes de datos de longitud variable enviados antes que los paquetes de voz hacen que los retrasos sean impredecibles, lo que origina fluctuaciones. Un ancho de banda reducido hace que el RTP combinado de 40 bytes, UDP y encabezado IP de un paquete VoIP de 20 bytes sea todo un derroche. Un ancho de banda reducido provoca enormes retrasos y pérdidas porque el enlace se congestiona con frecuencia. Muchas técnicas de QoS populares que prestan un buen servicio al tráfico de datos, como WFQ y RED, son ineficaces para las aplicaciones de voz: Si aplica WFQ tanto a la voz como a los datos, conforme el número de flujos de aplicaciones de datos y voz aumenta por el enlace, el WFQ basado en flujo asignará cada vez menos ancho de banda a cada flujo. A diferencia del tráfico de datos elástico que se adapta al ancho de banda disponible, la calidad de voz se vuelve inaceptable después de demasiadas caídas y retrasos. RED está específicamente diseñado para el tráfico TCP. VoIP viaja por encima de UDP. Por tanto, cuando sea posible, debería clasificarse el tráfico de voz y de datos en categorías independientes y RED debería aplicarse a los datos pero no a la voz. Además, cada enlace o parte del equipo en la ruta de VoIP añade retraso a la transmisión del paquete de voz. La posibilidad de pérdida del paquete de voz también aumenta cuando el tráfico de voz se desplaza una distancia mayor y por encima de más saltos en la red. Normalmente, las conexiones WAN de baja velocidad son los enlaces más débiles.

Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP) En circunstancias normales, el equipo de red y las estaciones finales no pueden diferenciar entre los requisitos de los paquetes de voz en tiempo real y el tráfico de datos estándar. Esto podría resultar en una pérdida considerable de calidad de la conversación. Para garantizar la calidad de la voz, debe clasificar el tráfico de datos y de voz en distintas categorías y proporcionar manejo de prioridad al tráfico de voz en una estructura básica de red de datos compartidos. El manejo de prioridad del tráfico de voz minimiza los retrasos y las pérdidas y, cuando es posible, proporciona al tráfico de voz un desempeño de transmisión predecible. En el caso de los enlaces PPP, recomendamos las siguientes características de QoS: Clasificación de paquetes mediante MQC Marcado basado en clases (en el borde DS) Manejo de prioridad mediante LLQ CRTP: necesario sólo en enlaces de baja velocidad con un número bajo de llamadas para la optimización del ancho de banda MP LFI: necesario sólo en enlaces de baja velocidad (por debajo de 1,2 Mbps) para garantizar que el tiempo de transmisión de un fragmento sea inferior a 10 ms El siguiente ejemplo de configuración muestra una configuración completa con todas las características de QoS enumeradas anteriormente activadas: Ejemplo de configuración 15: QoS para VoIP sobre los enlaces WAN PPP Comandos

Descripción

class-map voip match ip precedence 5 !

Crea la clase voip para el tráfico de voz que ha sido marcado con la precedencia IP 5 mediante uno de los métodos de marcado disponibles.

class-map webtraffic match ip precedence 3 !

Crea la clase webtraffic para el tráfico web que ha sido marcado con la precedencia IP 3 mediante uno de los métodos de marcado disponibles.

policy-map llq class voip priority 64 class webtraffic bandwidth 64 class class-default fair-queue !

Define la asignación de políticas de QoS llq: el tráfico de clase voip consigue la prioridad y está limitado a 64 kbps durante la congestión. A los paquetes de clase webtraffic se les garantizan 64 kbps. El resto del tráfico comparte el ancho de banda restante.

interface Serial1/0 bandwidth 256 encapsulation ppp no fair-queue ppp multilink multilink-group 1 !

Conecta la interfaz de serie 1/0 a la interfaz de enlaces múltiples en el grupo 1. (Para los anchos de banda de enlaces por encima de 1,2 Mbps, no se necesitará LFI de PPP de enlaces múltiples ni cRTP. En ese caso, la dirección IP y la declaración de política de servicio irían bajo la configuración de la interfaz de serie).

interface Multilink1 ip address 10.1.1.1 255.255.255.252 bandwidth 256 !

Configura LFI de PPP de enlaces múltiples para enlaces inferiores a 1,2 Mbps.

ip rtp header-compression iphc-format ip tcp header-compression iphc-format !

Configura cRTP para reducir los requisitos de ancho de banda de cada llamada de voz.

ppp multilink ppp multilink fragment-delay 10

Permite un tamaño de fragmentación de 10 ms. Permite el entrelazado de paquetes y fragmentos.

multilink-group 1 service-policy output llq

Conecta la interfaz de enlaces múltiples al grupo 1. Conecta la política de QoS llq al tráfico saliente en la interfaz de enlaces múltiples.

!

ppp multilink interleave

En este ejemplo, el LFI de PPP de enlaces múltiples impide que los paquetes VoIP se retrasen detrás de paquetes de datos de gran tamaño, cRTP reduce los requisitos de ancho de banda de VoIP y LLQ ofrece prioridad al tráfico de VoIP y ancho de banda garantizado a otra clase. Necesita configurar estas características en ambos extremos del enlace PPP. LFI de PPP de enlaces múltiples sólo es necesario en el caso de enlaces inferiores a 1,2 Mbps. cRTP sólo está recomendado en enlaces con un número inferior de llamadas VoIP y si el uso de la CPU no es demasiado intenso.

QoS de VoIP sobre redes de retransmisión por frame (frame relay) En esta sección se describe cómo configurar VoIP en una red típica en la que los enlaces WAN de retransmisión por frame (frame relay) se utilizan para transportar tráfico de voz. Incluye las siguientes subsecciones: QoS de VoIP sobre redes de retransmisión por frame (frame relay) Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay)

QoS de VoIP sobre redes de retransmisión por frame (frame relay) Otra aplicación típica de VoIP sería para una gran empresa en la que se usaría la infraestructura existente de tráfico de datos WAN de retransmisión por frame (frame relay) para transportar las llamadas de voz entre las oficinas principales y las sucursales. Existen dos opciones en este caso: llevar la voz y los datos en PVC independientes o usar el mismo PVC para el tráfico de voz y datos. En el primer caso, deberá seguir dando prioridad al tráfico de voz usando una técnica como Cola de prioridad de interfaz PVC (PIPQ). PIPQ permite asignar varias prioridades para los PVC: alta, media, normal o baja. PIPQ también permite que los PVC se coloquen en cola en la interfaz física principal de manera que el tráfico de alta prioridad vaya antes que el tráfico de prioridad media, normal y baja. Sin embargo, PIPQ tiene el mismo problema que la colocación en cola de prioridad: el tráfico de alta prioridad puede privar de ancho de banda al resto del tráfico. No obstante, si utiliza el modelado de tráfico de retransmisión por frame (frame relay) correctamente, podrá minimizar este problema porque cada PVC tendrá una velocidad de transmisión máxima definida. En la situación más común, se usa sólo un PVC para transportar todo el tráfico entre los sitios, tal y como se muestra en la Figura 10.

Figura 10: QoS de VoIP sobre enlaces de retransmisión por frame (frame relay) de baja velocidad

Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay) Debe configurar el modelado de tráfico de retransmisión por frame (frame relay) para garantizar que las discordancias de la velocidad en los sitios remotos y del hub se manejen correctamente. Por ejemplo, si el sitio del hub cuenta con un conexión T1 en la red de retransmisión por frame (frame relay) y el sitio remoto tiene una velocidad de acceso de 128 kbps, el sitio del hub cuenta con la capacidad para enviar a velocidades de T1 en dirección a este único sitio remoto. Los switches de retransmisión por frame (frame relay) colocarán en la memoria intermedia este tráfico en una pequeña proporción pero después eliminará de forma arbitraria lo que supere los 128 kbps. Tiene que decidir qué debería eliminarse y a qué debería dársele prioridad en los puntos extremos del PVC. El modelado de tráfico de retransmisión por frame (frame relay) permite que los routers envíen tráfico a la nube de retransmisión por frame por debajo de una velocidad configurada previamente. Cualquier tráfico por encima de esta velocidad se colocará en cola. Se podrá utilizar un algoritmo de colocación en cola tal como LLQ para tomar decisiones inteligentes sobre los paquetes que deberían enviarse. Si las colas se llenan, los paquetes simplemente se eliminarán. Sin embargo, si se ha dado prioridad a VoIP y el tráfico total de VoIP está por debajo de la velocidad de modelado de tráfico, los paquetes VoIP recibirán servicio con latencia baja a y no se eliminarán. En el caso de enlaces con una velocidad inferior a 1,2 Mbps, debe configurar la fragmentación del paquete para garantizar que un paquete VoIP no tenga que esperar detrás de un gran paquete. La fragmentación de paquetes de datos de gran tamaño a 10 ms de la velocidad del enlace puede vincular el período máximo de espera. Puede utilizar cRTP para usar de manera eficaz el ancho de banda si el número de llamadas no es demasiado alto. Para ofrecer alta calidad a VoIP sobre retransmisión por frame (frame relay), debe configurar las siguientes características: Modelado de tráfico de retransmisión por frame (frame relay): Defina el comando de configuración de clase de asociador frame-relay cir en una velocidad de transmisión máxima (debería ser la velocidad garantizada negociada del proveedor de servicios). Desactive el comando de configuración de clase de asociador frame-relay adaptive-shaping y defina el valor del comando mincir para que coincida con el de cir a fin de obtener una calidad de voz mejor. Defina el comando de configuración de clase de asociador frame-relay bc en 1/100 de CIR para permitir que el modelado de tráfico preste servicio a los paquetes, al menos, cada 10 ms. LFI de FRF.12: sólo necesita LFI si la velocidad del puerto del extremo remoto o del hub es inferior a 1,2 Mbps. El tamaño de fragmentación debería ser 10 ms u 80 bytes multiplicados por el número de DS0 (por ejemplo, para 4x64k, el tamaño de fragmentación debería ser 4x80 = 320 bytes). LLQ en PVC de retransmisión por frame (frame relay): LLQ se aplica bajo la clase de asignación para el modelado de tráfico de retransmisión por frame. cRTP: se aplica bajo la subinterfaz de retransmisión por frame (frame relay). Debería usar cRTP sólo si la utilización de la CPU es baja y para un pequeño número de llamadas, según la plataforma. El siguiente ejemplo de configuración muestra cómo activar las características de QoS descritas en la sección anterior: Ejemplo de configuración 16: QoS para VoIP sobre los enlaces WAN de retransmisión por frame (frame relay) Comandos

Descripción

class-map voip match ip precedence 5 !

Crea la clase voip para el tráfico de voz que ha sido marcado con la precedencia IP 5 mediante uno de los métodos de marcado disponibles.

class-map webtraffic match ip precedence 3 !

Crea la clase webtraffic para el tráfico web que ha sido marcado con la precedencia IP 3 mediante uno de los métodos de marcado disponibles.

policy-map llq class voip priority 64 class webtraffic bandwidth 64

Define la asignación de políticas de QoS llq: el tráfico de clase voip consigue la prioridad y está limitado a 64 kbps durante la congestión. A los paquetes de clase webtraffic se les garantizan 64 kbps. El resto del tráfico comparte el ancho de banda restante.

class class-default fair-queue

!

interface Serial 0/1 no ip address encapsulation frame-relay frame-relay traffic shaping !

Activa el modelado de tráfico de retransmisión por frame (frame relay). Debe activar el modelado de tráfico de retransmisión por frame (frame relay) para manejar las discordancias de la velocidad y el exceso de suscripciones. (LLQ por PVC de retransmisión por frame (frame relay) también necesita el modelado de tráfico de retransmisión por frame).

interface Serial 0/1.64 point-to-point ip address 10.14.96.2 255.255.255.252 frame-relay interface-dlci 128 class voice

Conecta la clase de modelado de tráfico voice a este PVC de retransmisión por frame (frame relay).

frame-relay ip rtp header-compression

!

map-class frame-relay voice no frame-relay adaptive-shaping

Configura cRTP para reducir los requisitos de ancho de banda de cada llamada de voz. Desactiva el modelado adaptable. No es recomendable utilizar el modelado adaptable para VoIP.

frame-relay cir 256000

Define el CIR o la velocidad de transmisión superior a 256 kbps.

frame-relay bc 2560

Define la velocidad de ráfaga comprometida en 1/100 de CIR.

frame-relay mincir 256000

Define la velocidad mínima aceptable de CIR. El valor mincir tiene que ser superior a la prioridad total y el ancho de banda asignado.

frame-relay fragment 320

Permite la fragmentación FRF.12 con un tamaño de fragmento de 320 bytes.

service-policy output llq!

Conecta la política de QoS llq a la clase de asignación definida.

En este ejemplo, el modelado de tráfico de retransmisión por frame (frame relay) maneja las discordancias de velocidad. La fragmentación FRF.12 evita que los paquetes VoIP se retrasen al colocarse detrás de paquetes de datos de gran tamaño. cRTP reduce los requisitos de ancho de banda de VoIP y LLQ otorga prioridad al tráfico de VoIP y garantiza ancho de banda a otra clase. Debe configurar estas características en ambos extremos del enlace de retransmisión por frame (frame relay). FRF.12 sólo es necesario en el caso de enlaces inferiores a 1,2 Mbps y cRTP sólo está recomendado en enlaces con un número inferior de llamadas VoIP y si el uso de la CPU no es muy intenso.

QoS de VoIP sobre ATM En esta sección se describe cómo configurar la QoS de VoIP sobre ATM e incluye las siguientes subsecciones: QoS de VoIP sobre escenario de ATM QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos

QoS de VoIP sobre escenario de ATM La tecnología ATM cuenta con ventajas inherentes en el manejo de tráfico de VoIP debido a sus celdas pequeñas y de tamaño fijo, y a los mecanismos de clase de servicio (CoS). Estas ventajas no aseguran, sin embargo, que el tráfico de VoIP obtenga automáticamente la QoS que necesita de la red ATM que lo lleva. El tráfico de VoIP no obtendrá de forma automática la QoS que necesita porque las definiciones de QoS en la capa IP, tal como la configuración de la precedencia IP en el encabezado de paquete, no coinciden automáticamente con la configuración de CoS de ATM, es decir, la clase de tráfico (velocidad de bits constante [CBR], velocidad de bits variable [VBR], velocidad de bits disponible [ABR] y velocidad de bits no definida [UBR]) y los parámetros de tráfico como la velocidad de célula sostenida (SCR), la velocidad de célula de cresta (PCR) y el tamaño de ráfaga. Por tanto, después de que se identifiquen los paquetes de datos y voz y se ordenen en la capa IP, el operador de red debe configurar manualmente los circuitos virtuales (VC) de ATM para garantizar QoS para los paquetes de voz en la red ATM. Esta labor manual lleva tiempo, requiere mucho trabajo, es más propensa a errores y, sobre todo, no tiene capacidad de ampliación cuando en la red entra cada vez más tráfico de voz. En la Figura 11 se muestra un ejemplo de QoS de VoIP configurado para dar soporte a ATM.

Figura 11: QoS de VoIP sobre los enlaces ATM

Hay dos soluciones disponibles para ofrecer QoS a VoIP sobre una red ATM: una utiliza VC de voz y datos independientes y la otra usa VC de voz y datos compartidos.

QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado En el caso de que el tráfico de datos y de voz compartan el mismo destino pero necesiten una QoS distinta, tendrá que definir los grupos de VC de ATM para formar los agrupamientos de PVC. En un agrupamiento de PVC, todos los PVC comparten el mismo origen y destino, y se asigna a cada agrupamiento para que lleve el tráfico IP con un nivel de precedencia IP específico o un rango de niveles. Después de configurar los agrupamientos de PVC, tendrá que configurar cada PVC con sus parámetros concretos de QoS de ATM. Conforme el tráfico de voz y datos con distintos niveles de precedencia IP llegan a la interfaz ATM del router, el software Cisco IOS lo envía de forma dinámica al PVC adecuado, asignando de manera eficaz las clases de QoS de IP a las CoS de ATM. Las ventajas principales de implementar la QoS de VoIP mediante este método son las siguientes: Separación automática del tráfico de voz y datos en PVC distintos. Conservación de los servicios diferenciados de la red IP mediante la red ATM. El siguiente ejemplo de configuración muestra cómo configurar VoIP sobre ATM usando los agrupamientos de PVC para separar los PVC de datos y voz: Ejemplo de configuración 17: QoS para VoIP sobre ATM con PVC de datos y voz separados Comandos

Descripción

ip cef !

Permite la conmutación de IP de Cisco Express Forwarding (CEF). Debe activar la conmutación de IP de CEF para que funcione esta solución.

interface ATM 2/0/0 no ip address ! interface ATM 2/0/0.1 point-to-point ip address 10.1.1.2 255.255.255.252 bundle qosmap

Crea un grupo de agrupamiento de PVC denominado qosmap.

protocol ip 10.1.1.1 broadcast pvc-bundle control 1/100 precedence 6-7

Asigna un tráfico de precedencia IP 6 y 7 a un identificador de ruta virtual (VPI) o a un identificador de canal virtual (VCI) de 1/100.

pvc-bundle voice 1/101 vbr-rt 6000 5000 1000 precedence 5

Asigna el tráfico de precedencia IP 5 (VoIP) a un VPI o VCI de 1/101 con un SCR de 5 Mbps y algunas funciones de ráfaga.

pvc-bundle web 1/102 cbr 5000 precedence 4

Asigna el tráfico de precedencia IP 4 a 1/102 con un SCR de 5 Mbps.

pvc-bundle data 1/103 precedence 0-3

Asigna otro tráfico de precedencia a un PVC con un VPI o VCI de 1/103.

En este ejemplo, se asignan cuatro clases de tráfico basadas en la precedencia IP a cuatro PVC ATM independientes en un agrupamiento. El PVC de voz cuenta con un ancho de banda garantizado de 5 Mbps con algunas funciones de ráfagas. El PVC de tráfico web también tiene garantizado 5 Mbps pero sin ráfagas (CBR). Al tráfico de control y al resto de flujos de tráfico no se les proporciona ninguna garantía de velocidad ATM.

QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos Si decide usar PVC distintos para voz y datos, debe ajustar la asignación de ancho de banda correspondiente en cuanto el tráfico de voz crezca más allá del ancho de banda configurado en el PVC de voz. Este reajuste manual no es necesario cuando la voz y los datos comparten el mismo

PVC, siempre que la voz obtenga la prioridad que necesita. Puede configurar el tráfico de VoIP para tener prioridad absoluta sobre el tráfico de datos al configurar LLQ en el PVC ATM. En el siguiente ejemplo de configuración se muestra cómo configurar VoIP sobre ATM usando el mismo PVC para el tráfico de datos y de voz: Ejemplo de configuración 18: QoS para VoIP sobre ATM usando el PVC de voz y datos compartido Comandos

Descripción

ip cef !

Permite la conmutación de IP de CEF. Debe activar la conmutación de IP de CEF para que funcione esta solución.

class-map voip match ip precedence 5 !

Crea la clase voip para el tráfico de voz que ha sido marcado con la precedencia IP 5 usando uno de los métodos de marcado disponibles.

class-map webtraffic match ip precedence 3 !

Crea la clase webtraffic para el tráfico web que ha sido marcado con la precedencia IP 3 usando uno de los métodos de marcado disponibles.

policy-map llq class voip priority 1000 class webtraffic bandwidth 1000 class class-default fair-queue !

Define la asignación de políticas llq, que define la política de QoS: el tráfico de clase voip consigue la prioridad y está limitado a 1 Mbps durante la congestión. A los paquetes de clase webtraffic se les garantizan 1 Mbps. El resto del tráfico comparte el ancho de banda restante.

interface ATM2/0/0 no ip address ! interface ATM2/0/0.1 point-to-point ip address 10.1.1.2 255.255.255.252 pvc data+voice 1/101 vbr-rt 6000 5000 1000 encapsulation aal5snap!

Configura los parámetros de modelado de ATM.

service-policy output llq !

Conecta la asignación de políticas de QoS llq al PVC ATM.

En este ejemplo, LLQ se utiliza en un único PVC ATM que lleva tanto VoIP como datos. La política de LLQ se aplica a una subinterfaz de ATM para un PVC. El tráfico de clase voip obtiene una prioridad de un máximo de 1 Mbps y a la clase webtraffic se le garantiza 1 Mbps pero no entra dentro de la asignación de prioridad. El modelado de ATM también garantiza que el PVC obtenga una velocidad sostenida de 5 Mbps.

Documentos relacionados Guía de configuración de soluciones de calidad de servicio de Cisco IOS, versión 12.1 http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_book09186a008007ff1d.html Referencia de comandos de soluciones de calidad de servicio de Cisco IOS, versión 12.1 http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a00800807a7.html Guía de configuración de aplicaciones multiservicio de Cisco IOS, versión 12.1 http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_book09186a008008739c.html Referencia de comandos de aplicaciones multiservicio de Cisco IOS, versión 12.1 http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a0080087c1a.html Módulo de características de COPS para RSVP de la versión 12.1(1)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/ copsrsvp.htm Módulo de características de marcación de paquetes basada en la clase de la versión 12.1(2)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/cbpmark.htm

Módulo de características de modelado basado en la clase de la versión 12.1(2)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/ clsbsshp.htm Módulo de características de mejoras en la compatibilidad de compresión del encabezado de retransmisión por frame (frame relay) de la versión 12.1(2)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/ dtfrhccc.htm Módulo de características de cola de latencia baja para retransmisión por frame (frame relay) de la versión 12.1(2)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/ dtfrpqfq.htm Módulo de características de configuración del tamaño de ráfaga en la cola de latencia baja de la versión 12.1(3)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/ dtcfgbst.htm Módulo de características de soporte de RSVP para la cola de latencia baja de la versión 12.1(3)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/ rsvp_llq.htm Módulo de características de marcado basado en la clase de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ cbpmark2.htm Módulo de características de colocación en cola equilibrada y ponderada basada en la clase y la Random Early Detection ponderada distribuida de la versión 12.1(5)T de Cisco IOS. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtcbwred.htm Módulo de características de protocolo de tiempo real comprimido distribuido de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtdcrtp.htm Módulo de características de cola de latencia baja distribuida de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtllqvip.htm Módulo de características de modelado de tráfico distribuido de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtdts.htm Módulo de características de implementación de DiffServ para la calidad de servicio de extremo a extremo de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtdfsv.htm Módulo de características de fragmentación y entrelazado de enlaces para retransmisión por frame (frame relay) y circuitos virtuales de ATM de la versión 12.1 (5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtlfifra.htm Módulo de características de control del tráfico de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dtpoli.htm Módulo de características de control de admisión de llamadas VoIP mediante RSVP de la versión 12.1(5)T de Cisco IOS http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/ dt4trsvp.htm

© 1992-2014 Cisco Systems Inc. Todos los Derechos Reservados. Fecha de Generación del PDF: 14 Abril 2008 http://www.cisco.com/cisco/web/support/LA/8/81/81646_tech_tk652_tk698_tech_white_paper09186a00800d6b73.html