Calidad de servicio para Voz sobre IP Contenidos Calidad de servicio para Voz sobre IP Información general de QoS para VoIP Ancho de banda suficiente Clasificación de paquetes Información general de clasificación de paquetes Clasificación y marcado Ejemplo de marcado y clasificación de pares de marcado por voz Ejemplo de marcado y clasificación de índice de acceso comprometido Ejemplo de marcado y clasificación del enrutamiento basado en políticas Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular Mecanismos de colocación en cola de QoS Cola de latencia baja Ejemplo de configuración de LLQ Otros mecanismos de colocación en cola de QoS Fragmentación y entrelazado Información general de entrelazado y fragmentación Ejemplo de entrelazado y fragmentación de enlaces MLP Ejemplo de entrelazado y fragmentación FRF.12 Modelado de tráfico Información general de modelado de tráfico Ejemplo de modelado de tráfico de retransmisión por frame (frame relay) Compresión de encabezados IP RTP Servicios diferenciados para VoIP Información general de DS y DSCP (RFC 2474, RFC 2475) Implementación de DS para VoIP: reenvío acelerado PHB (RFC 2598) Ejemplo de configuración de marcado basado en la clase DSCP Protocolo de reserva de recursos Información general de RSVP Información general de RSVP para CAC Implementación de CAC basada en RSVP Configuración de recursos de puertas de enlace locales si CAC falla Uso de RSVP con LLQ Implementación del soporte de RSVP para LLQ QoS de VoIP sobre líneas alquiladas (mediante PPP) VoIP sobre escenario de líneas alquiladas (mediante PPP) Solución recomendada de VoIP sobre líneas alquiladas (mediante PPP) QoS de VoIP sobre redes de retransmisión por frame (frame relay) QoS de VoIP sobre redes de retransmisión por frame (frame relay) Solución recomendada de QoS de VoIP sobre retransmisión por frame (frame relay) QoS de VoIP sobre ATM QoS de VoIP sobre escenario de ATM QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos por separado QoS de VoIP sobre solución ATM mediante PVC ATM para voz y datos compartidos Documentos relacionados Calidad de servicio para Voz sobre IP Historial de la versión Número de versión Fecha Notas 1 16 de abril de 2001 Se creó este documento. 2 15 de mayo de 2001 Se incorporaron los comentarios editoriales. 3 30 de junio de 2001 Se incorporaron comentarios editoriales adicionales.
Calidad de servicio para Voz sobre IP trata los conceptos de la Calidad de Servicio (QoS) y las características aplicables a la voz, en particular, a la Voz sobre IP (VoIP). En este documento también se proporcionan ejemplos de alto nivel en los que se muestran cómo implementar estas características en entornos de red diferentes. Calidad de servicio para Voz sobre IP contiene las siguientes secciones: Información general de QoS para VoIP Ancho de banda suficiente Clasificación de paquetes Mecanismos de colocación en cola de QoS Fragmentación y entrelazado Modelado de tráfico Compresión de encabezados IP RTP Servicios diferenciados para VoIP Protocolo de reserva de recursos QoS de VoIP sobre líneas alquiladas (mediante PPP) QoS de VoIP sobre redes de retransmisión por frame (frame relay) QoS de VoIP sobre ATM Documentos relacionados Información general de QoS para VoIP Para que la VoIP sea un reemplazo realista para los servicios de telefonía de redes de telefonía pública conmutada estándar (PSTN), los clientes deben recibir la misma calidad de transmisión de voz que reciben con los servicios de telefonía básica, es decir, transmisiones de voz de alta calidad sistemáticamente. Al igual que otras aplicaciones de tiempo real, VoIP es extremadamente sensible al ancho de banda y al retraso. Para que las transmisiones de VoIP sean inteligibles para el receptor, los paquetes de voz no se deben perder ni retrasar excesivamente ni sufrir distintos retrasos (también conocido como "fluctuación"). Por ejemplo, se deben cumplir las siguientes normas: El códec G.729 predeterminado necesita que haya una pérdida de paquetes bastante inferior al 1 por ciento para evitar errores audibles. Lo mejor sería que no se perdieran paquetes para VoIP. La especificación ITU G.114 recomienda un retraso de extremo a extremo unidireccional inferior a 150 milisegundos (ms) para el tráfico en tiempo real de alta calidad como la voz. (Para las llamadas internacionales, se acepta un retraso unidireccional de hasta 300 ms, en especial para las trasmisiones por satélite. Este retraso unidireccional tiene en cuenta el retraso de propagación; es decir, el tiempo necesario para que la señal recorra la distancia). Las memorias intermedias para fluctuación (utilizadas para compensar los diferentes retrasos) se agregan posteriormente al retraso de extremo a extremo y normalmente sólo son efectivas en las variaciones de retraso inferiores a 100 ms. Por tanto, se debe minimizar la fluctuación. VoIP sólo puede garantizar una transmisión de voz de alta calidad si los paquetes de voz, tanto para el canal de audio como para el de señal, tienen prioridad sobre otros tipos de tráfico de red. Para que VoIP se implemente de forma que los usuarios reciban un nivel aceptable de calidad de voz, el tráfico de VoIP debe tener garantizados ciertos requisitos de fluctuación, latencia y ancho de banda de compensación. QoS garantiza que los paquetes de voz VoIP reciban el trato preferente que requieren. En general, QoS proporciona un servicio de red mejor (y más predecible) al proporcionar las siguientes características: Soporte de ancho de banda dedicado Mejora de las características de pérdida Impedimento y administración de la congestión de red
Modelado del tráfico de red Configuración de las prioridades del tráfico a través de la red Calidad de servicio para Voz sobre IP trata los conceptos de QoS y las características aplicables a la voz, en particular a VoIP. Ancho de banda suficiente Antes de que se plantee aplicar cualquiera de las características de QoS abordadas en este documento, deberá proporcionar un ancho de banda de red suficiente para soportar el tráfico de voz en tiempo real. Por ejemplo, una llamada G.711 de VoIP de 80 kbps (carga útil de 64 kbps más encabezado de 16 kbps) no será suficiente en un enlace de 64 kbps porque se perderán al menos 16 kbps de los paquetes (es decir, el 20 por ciento). En este ejemplo, también se supone que no fluye más tráfico a través del enlace. Una vez que proporcione un ancho de banda suficiente para el tráfico de voz, podrá dar más pasos para garantizar que los paquetes de voz dispongan de un determinado porcentaje del ancho de banda total y que tengan prioridad. Clasificación de paquetes La base para proporcionar cualquier QoS reside en la capacidad de un dispositivo de red para identificar y agrupar paquetes específicos. Este proceso de identificación se denomina clasificación de paquetes. Una vez clasificado el paquete, éste debe marcarse estableciendo los bits designados en el encabezado IP. Las siguientes secciones describen la clasificación y el marcado: Información general de clasificación de paquetes Ejemplo de marcado y clasificación de pares de marcado por voz Ejemplo de marcado y clasificación de índice de acceso comprometido Ejemplo de marcado y clasificación del enrutamiento basado en políticas Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular Información general de clasificación de paquetes Para garantizar el ancho de banda para los paquetes VoIP, un dispositivo de red debe poder identificar los paquetes VoIP en todo el tráfico IP que fluye a través de él. Los dispositivos de red utilizan una dirección IP de origen y de destino en el encabezado IP o en los números de puerto de protocolo de datagrama de usuario (UDP) de origen y de destino en el encabezado de UDP para identificar los paquetes VoIP. Este proceso de agrupamiento e identificación se denomina clasificación y es la base para proporcionar QoS. Aparte de los métodos de clasificación estática que implican la coincidencia de información del encabezado de la Capa 3 o Capa 4, puede utilizar un mecanismo como el protocolo de reserva de recursos (RSVP) para la clasificación dinámica. RSVP utiliza paquetes de señalización H.245 para determinar el puerto UDP que utilizará la conversación de voz. A continuación, configura listas de acceso dinámico para identificar el tráfico de VoIP y coloca el tráfico en una cola reservada. RSVP se abordará más adelante en este documento. La clasificación de paquetes puede ser un procesamiento intensivo, por lo que debería tener lugar lo más lejos posible del borde de la red. Puesto que cada salto necesita realizar una determinación del tratamiento que el paquete debería recibir, necesitará disponer de un método de clasificación más eficiente y más simple en el núcleo de la red. Esta clasificación más simple se logra mediante el marcado o configuración del byte ToS (tipo de servicio) en el encabezado IP. Los tres bits más importantes de byte ToS se denominan bits de precedencia de IP. La mayoría de las aplicaciones y de los proveedores soportan actualmente la configuración y el reconocimiento de estos tres bits. El marcado se lleva a cabo para que los seis bits más significativos del byte ToS, llamados "punto de código de servicios diferenciados" (DSCP), puedan usarse para definir las clases de servicios diferenciados (DS). DSCP se abordará más adelante en este documento. Cuando cada uno de los saltos en la red pueda clasificar e identificar los paquetes VoIP (ya sea mediante información de la dirección del puerto o mediante el byte ToS), dichos saltos podrán entonces proporcionarle a cada paquete VoIP la QoS necesaria. En este punto, se pueden configurar las técnicas especiales para proporcionar almacenamiento en cola prioritario para garantizar que los paquetes de datos grandes no interfieren en la transmisión de datos de voz y para reducir los requisitos de ancho de banda comprimiendo la IP de 40 bytes más UDP más encabezado RTP a entre 2 y 4 bytes. Clasificación y marcado La clasificación es un proceso de identificación de la clase o grupo al que pertenece un paquete. Los dispositivos de red utilizan varios criterios de concordancia para colocar el tráfico en un determinado número de clases. Las concordancias se basan en los siguientes criterios: El comando de configuración global dial-peer voice voip Lista de acceso (estándar y extendida)
Protocolo (por ejemplo, URL, protocolos con estado o protocolo de Capa 4) Puerto de entrada Precedencia IP o DSCP Clase de servicio (CoS) Ethernet 802.1p Como ya se ha mencionado, puede ser un procesamiento intensivo si los nodos deben repetir la clasificación basada en las coincidencias de las listas de acceso. Por lo tanto, los nodos deberían marcar los paquetes en cuanto hayan identificado y clasificado los paquetes VoIP. Si un nodo puede establecer la precedencia IP o los bits DSCP en el byte ToS del encabezado IP en cuanto identifica el tráfico como tráfico de VoIP, los demás nodos de la red pueden clasificar en función de estos bits. El marcado es el proceso del nodo mediante el que establece una de las siguientes opciones: Tres bits de precedencia de IP en el byte ToS de IP. Seis bits de DSCP en el byte ToS de IP Tres bits experimentales de MPLS (EXP) Tres bits de CoS de Ethernet 802.1p Un bit de probabilidad de pérdida de celda (CLP) de ATM En la mayoría de las redes IP, el DSCP o la precedencia IP de marcado debería ser suficiente para identificar el tráfico como de VoIP. Ejemplo de marcado y clasificación de pares de marcado por voz Con las puertas de enlace de VoIP de Cisco, por lo general, utilizará pares de marcado de voz para clasificar los paquetes VoIP y marcar los bits de precedencia de IP. En el siguiente ejemplo de configuración se muestra cómo marcar los bits de precedencia de IP: Ejemplo de configuración 1: Clasificación y marcado mediante pares de marcado dial-peer voice 100 voip destination-pattern 100 session target ipv4:10.10.10.2 ip precedence 5 En este ejemplo, cualquier llamada VoIP que coincida con el comando dial-peer voice 100 voip tendrá todos los paquetes de carga de voz definidos con la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP están definidos en 101. Ejemplo de marcado y clasificación de índice de acceso comprometido El índice de acceso comprometido (CAR) es una técnica antigua que implica el control del tráfico o la limitación de velocidad que coincide con determinados criterios en un límite superior. CAR admite la mayoría de los mecanismos de concordancia y permite que los bits de DSCP o de precedencia IP se definan de forma diferente en función de si los paquetes se ajustan a una determinada velocidad o la sobrepasan. En general, CAR resulta más útil para los paquetes de datos que para los de voz. Por ejemplo, todo el tráfico de datos en una interfaz Ethernet de al menos 1 Mbps se puede colocar en una precedencia IP de clase 3 y todo el tráfico con una velocidad superior a un 1 Mbps se puede poner en una clase 1 o perder. Otros nodos de la red pueden así tratar de forma diferente el tráfico excesivo o que no cumpla con las normas marcado con una precedencia IP inferior. Todo el tráfico de voz deberá ajustarse a la velocidad especificada, si se ha configurado correctamente. En el siguiente ejemplo de configuración se muestra cómo utilizar CAR para clasificar y marcar los paquetes VoIP: Ejemplo de configuración 2: Clasificación y marcado mediante CAR access-list 100 permit udp any any range 16384 32767 access-list 100 permit tcp any any eq 1720 interface Ethernet0/0 ip address 10.10.10.1 255.255.255.0 rate-limit input
access-group 100 1000000 8000 8000 conform-action set-prec-continue 5 exceed-action set-prec-continue 5 En este ejemplo, el tráfico que coincida con la lista de acceso 100 se establecerá en la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720. Ejemplo de marcado y clasificación del enrutamiento basado en políticas El enrutamiento basado en políticas (PBR) es otra característica anterior que permite que el tráfico se enrute en función de la lista de acceso o del puerto de origen. También se puede utilizar para clasificar y marcar paquetes. Un ejemplo de configuración simple sería: Ejemplo de configuración 3: Clasificación y marcado mediante PBR access-list 100 permit udp any any range 16384 32767 access-list 100 permit tcp any any eq 1720 route-map classify_mark match ip address 100 set ip precedence 5 interface Ethernet0/0 ip address 10.10.10.1 255.255.255.0 ip policy route-map classify_mark En este ejemplo, el tráfico que coincida con la lista de acceso 100 se establecerá en la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720. Ejemplo de marcado y clasificación de la interfaz de línea de comandos de QoS modular El método de marcado y clasificación recomendado es la característica de interfaz de línea de comandos QoS modular (Mod QoS CLI o MQC), un método de configuración basado en plantilla que separa la clasificación de la política, permitiendo que varias características de QoS se configuren conjuntamente para varias clases. Utilice la asignación de clase para clasificar el tráfico en función de varios criterios de coincidencia y una asignación de políticas para determinar qué debería ocurrir con cada clase. A continuación, aplique la política al tráfico entrante o saliente en una interfaz mediante el comando de configuración de interfaz service-policy. En el siguiente ejemplo de configuración se muestra cómo utilizar QoS modular para clasificar y marcar los paquetes: Ejemplo de configuración 4: Clasificación y marcado mediante MQC access-list 100 permit udp any any range 16384 32767 access-list 100 permit tcp any any eq 1720 class-map voip match access-group 100 policy-map mqc class voip set ip precedence 5 <<#various other QoS commands>> class class-default set ip precedence 0 <<#various other QoS commands>> interface Ethernet0/0 service-policy input mqc En este ejemplo, el tráfico que coincida con la lista de acceso 100 se clasificará como clase voip y se establecerá con la precedencia IP 5, lo que significa que los tres bits más significativos del byte ToS de IP se definen en 101. La lista de acceso 100 coincide aquí con los puertos UDP comunes utilizados por VoIP y el tráfico de señalización H.323 para el puerto TCP 1720. El resto del tráfico se define con precedencia IP 0. La política se denomina mqc y se aplica al tráfico entrante en la interfaz Ethernet 0/0.
Mecanismos de colocación en cola de QoS Una vez que se ha colocado el tráfico en las clases de QoS en función de los requisitos de QoS, necesitará proporcionar garantías de ancho de banda y servicio prioritario a través de un mecanismo de colocación en cola de salida inteligente. En esta sección se describen los mecanismos de colocación en cola y se incluyen las siguientes subsecciones: Cola de latencia baja Ejemplo de configuración de LLQ Otros mecanismos de colocación en cola de QoS Cola de latencia baja Se requiere una cola de prioridad para VoIP. Puede utilizar cualquier mecanismo de colocación en cola que efectivamente le dé alta prioridad a VoIP, aunque se recomienda una cola de tiempo latencia bajo (LLQ) porque es flexible y fácil de configurar. El método de colocación en cola más flexible que satisface los requisitos de VoIP es la LLQ. LLQ utiliza el método de configuración MQC para priorizar determinadas clases y proporcionar un ancho de banda mínimo garantizado para otras. Durante los períodos de congestión, la cola de prioridad se controla en la velocidad configurada de manera que el tráfico prioritario no monopolice todo el ancho de banda disponible. (Si el tráfico de prioridad monopoliza el ancho de banda, impide que se alcancen las garantías de ancho de banda para otras clases). Si se ofrece LLQ correctamente, el tráfico que vaya a la cola de prioridad nunca debería exceder la velocidad configurada. LLQ también permite que se especifiquen las profundidades de la cola para determinar cuándo el router debería eliminar paquetes si hay demasiados esperando en cualquier cola de clase determinada. También hay un valor predeterminado de clase que se utiliza para definir el tratamiento de todo el tráfico no clasificado por una clase configurada. Es posible configurar la clase predeterminada mediante el comando de configuración de interfaz fair-queue, lo que significa que a cada flujo sin clasificar se le dará una parte más o menos igual del ancho de banda restante. La figura 1 muestra cómo funciona LLQ. Figura 1: Funcionamiento de LLQ En la Figura 1, todo el tráfico que sale de una interfaz o subinterfaz (para retransmisión por frame (frame relay) y ATM) se clasifica en primer lugar mediante MQC. Existen cuatro clases: una clase de alta prioridad, dos clases de ancho de banda garantizado y una clase predeterminada. El tráfico de clase de prioridad se coloca en una cola de prioridad y el tráfico de clase de ancho de banda garantizado junto a las colas reservadas. Se podrá ofrecer una cola reservada al tráfico de clase predeterminada o colocarlo en una cola predeterminada sin reservar donde cada flujo obtendrá una parte más o menos igual del ancho de banda disponible y sin reservar. El planificador presta servicio a las colas de manera que el tráfico de la cola de prioridad salga en primer lugar a menos que exceda un ancho de banda de prioridad configurado y que una cola reservada lo necesite (es decir, hay congestión). Se presta servicio a las colas reservadas según el ancho de banda reservado, que el planificador utiliza para calcular un peso. El peso se utiliza para determinar la frecuencia con que se presta servicio a una cola reservada y cuántos bytes se ofrecen cada vez. Los servicios del planificador se basan en el algoritmo de colocación en cola equilibrada y ponderada (WFQ), una tema que supera el ámbito de este documento. Si la cola de prioridad se llena porque la velocidad de transmisión del tráfico de prioridad es superior al ancho de banda de prioridad configurado, los paquetes situados al final de la cola de prioridad se eliminarán sólo en el caso de que no haya más ancho de banda sin reservar disponible. No se restringe ninguna de las colas reservadas al ancho de banda configurado si hay ancho de banda disponible. Los paquetes que infrinjan el ancho de banda y la prioridad garantizados sólo se eliminarán durante los periodos de congestión. Por tanto, la cola de prioridad deberá contar con ancho de banda suficiente para manejar todo el tráfico de VoIP que necesite servicio prioritario. Ejemplo de configuración de LLQ En el siguiente ejemplo de configuración se muestra cómo configurar LLQ: Ejemplo de configuración 5: LLQ access-list 100 permit udp any any range 16384 32000 access-list 100 permit tcp any any eq 1720 access-list 101 permit tcp any any eq 80 access-list 102 permit tcp any any eq 23 class-map voip match access-group 100 class-map data1 match protocol
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 (PQ- WFQ, 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 "PQ- CBWFQ") 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