VoIP de diseño y que despliega sobre el ISDN

Transcripción

1 VoIP de diseño y que despliega sobre el ISDN Contenido Introducción prerrequisitos Requisitos Componentes Utilizados Convenciones Problemas de diseño Ancho de banda variable El reordenar del paquete causado por el LFI Limitaciones CAC del Cisco CallManager Opciones del diseño Voz y datos que coexisten en un solo Canal B con o sin el crtp Voz y datos sobre los Canales B Separate con o sin el crtp Voz y datos que coexisten en los Canales B múltiples sin el crtp Voz y datos que coexisten en los Canales B múltiples con el crtp Información Relacionada Introducción La voz sobre IP (VoIP) sobre Integrated Service Digital Network (ISDN) es a veces una combinación recomendable, especialmente en las redes para empresas que utilicen telefonía IP. Las características requeridas para facilitar la Calidad de Servicio (QoS) necesaria para VoIP, Low Latency Queuing (LLQ), Class Based Weighted Fair Queuing (CBWFQ) y Link Fragmentation and Interleaving (LFI) se soportan en ISDN y su combinación funciona bien. Sin embargo, hay diversos aspectos importantes sobre diseño que se deben tener en cuenta. Este documento describe las excepciones y limitaciones que implica el uso de estas características de QoS con ISDN relativas a VoIP y facilita algunas configuraciones de muestra probadas. prerrequisitos Requisitos Cisco recomienda que tenga conocimiento sobre estos temas: ISDN Point-to-Point Protocol (PPP) Multilink PPP (MLPPP) LFI LLQ CBWFQ Protocolo Compressed Real-time (crtp) Este documento no proporciona la capacitación acerca de la tecnología en estos temas sino bastante una explicación de cómo estas Tecnologías trabajan juntas en una red VoIP. Vea la sección de información relacionada para más información sobre estos temas. Componentes Utilizados La información que contiene este documento se basa en las siguientes versiones de software y hardware. Software Release 12.2 del del Cisco IOS Cisco IOS Software Release 12.2(2)T a 12.2(10)T Cisco IOS Software Release 12.2(12)T y Posterior Estas opciones del diseño se presentan en este documento y se han probado con las versiones de Cisco IOS Software conocidas: Voz y datos sobre un solo Canal B con el crtp probado con el Cisco IOS Software Release 12.2(7a). Voz y datos sobre los Canales B Separate con el crtp probado con el Cisco IOS Software Release 12.2(7a). Voz y datos que coexisten en los Canales B múltiples sin el crtp probado con el Cisco IOS Software Release 12.2(8)T.

2 Estos problemas fueron encontrados: Id. de bug Cisco CSCdx09590 (clientes registrados solamente) El retiro de la servicio-directiva de la interfaz del dialer cuelga el router. Id. de bug Cisco CSCdw82424 (clientes registrados solamente) El LLQ no trabaja en el marcador después de una recarga. Usted debe reaplicar la servicio-directiva. Precaución: Verifique que estos bug se hayan resuelto en la versión que usted se prepone utilizar o que no afectan su red. La Voz y los datos que coexistían en los Canales B múltiples con el crtp no probado puesto que Cisco IOS Software Release 12.2(12)T y no estaban disponibles a la hora de esta escritura. La prueba fue realizada usando el equipo siguiente. Este Routers fue conectado directamente a través del ISDN. Pagent fue utilizado para simular el tráfico y el oversubscribe RTP la conexión. Cisco 7200 Router con la interfaz PRI Cisco 2600 Router con la interfaz BRI La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando. Convenciones Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento. Problemas de diseño Hay tres problemas que requieren la Consideración especial cuando usted diseña el VoIP sobre las redes ISDN. Éstos se describen abreviadamente en esta tabla y después se amplían sobre. Problema Ancho de banda variable El reordenar del paquete causado por el LFI Limitaciones del control de admisión de llamadas del Cisco CallManager (CAC) Descripción El ancho de banda del link ISDN varía mientras que se agregan o se caen los Canales B. Cuando se interpolan los paquetes RTP pueden llegar fuera de servicio cuando están transmitidos a través de los Canales B múltiples. El CAC basado en la ubicación del Cisco CallManager no es actualmente topología enterada. Ancho de banda variable El ISDN permite que caens los Canales B sean agregados o en respuesta a la demanda para el ancho de banda. El hecho de que el ancho de banda de un link varíe en un cierto plazo presenta un desafío especial a los Mecanismos para formar la cola CBWFQ y LLQ del Cisco IOS. Hasta el Cisco IOS Software Release 12.2(2)T, un directiva-mapa que implementó LLQ o el CBWFQ se podría asignar solamente una cantidad fija de ancho de banda. Por abandono, el ancho de banda asignado puede consumir solamente el 75% del ancho de banda disponible. En una interfaz de ISDN, el CBWFQ y el LLQ asume que solamente 64 kbps están disponibles, aunque la interfaz tiene el potencial para proporcionar o el Mbps del ancho de banda. Por lo tanto, el solamente 75% de 64 kbps, o de 48 kbps, se pueden afectar un aparato por un directiva-mapa en cualquier interfaz de ISDN. Esto restringe el número de llamadas VoIP que puedan ser llevadas. Si se afecta un aparato más ancho de banda, después se genera un mensaje de error cuando el directiva-mapa se aplica a la interfaz de ISDN. Considere este uso del directiva-mapa como un ejemplo: policy-map isdn-qos class VoIP-RTP priority 64 class VoIP-Sig bandwidth 10 El comando policy-map Cuando se aplica a una interfaz BRI, rechazan al comando policy-map porque más el de 75% de un Canal B (48 kbps) es reservado: El comando service-policy output

3 !--- Note the highlighted error message when the policy!--- is applied to the dialer interface. router(config)# interface dialer 0 router(config-if)# service-policy output isdn-qos I/f Dialer0 class VoIP-RTP requested bandwidth 64 (kbps) Available only 47 (kbps) La solución a este problema fue introducida en el Cisco IOS Software Release 12.2(2)T. A partir de esta versión, es posible reservar un porcentaje de ancho de banda disponible en vez de un monto total de ancho de banda. Para reservar 64 kbps para el RTP y 8 kbps para señalar en una interfaz BRI con dos Canales B que es el kbps del total 128 y un canal D de 8 kbps, la servicio-directiva: policy-map isdn-qos class VoIP-RTP priority percent 50 class VoIP-SIG bandwidth 8 El comando policy-map Como consecuencia, hay 32 kbps disponibles para el RTP cuando sube el primer Canal B, y 64 kbps disponibles cuando sube el segundo canal. Además, el Cisco IOS nunca quita la servicio-directiva de la interfaz debido al oversubscription, puesto que un oversubscription puede nunca ocurrir. El reordenar del paquete causado por el LFI Cuando usted realiza el VoIP sobre el ISDN, el MLPPP se utiliza para el LFI. El LFI divide los paquetes de datos grandes en fragmentos más pequeños y los transmite paralelamente a través de todos los Canales B en el conjunto. Al mismo tiempo los paquetes de voz se interpolan entre los fragmentos y se reduce su retardo. Los paquetes entrelazados no están conforme a la encapsulación MLPPP, ellos se encapsulan como paquetes PPP regulares. Por lo tanto, no tienen ningún número de secuencia MLPPP y no pueden ser reordenados si llegan fuera de servicio. La posibilidad de reordenar es real. La profundidad de las diversas colas de administración del tráfico del link en el conjunto puede diferenciar, que hace los paquetes RTP alcanzarse como resultado de la diferencia en el retardo de colocación en cola. Los diversos Canales B pueden también tomar diversas trayectorias a través de la red ISDN y terminar para arriba con diversos retrasos de la transmisión. Generalmente, este reordenamiento de paquetes no es problema para los paquetes RTP. Los buffers de jitter en los dispositivos de VoIP de recepción reordenan los paquetes basados en los números de secuencia RTP. Sin embargo, el reordenar se convierte en un problema si se utiliza el crtp. El algoritmo crtp asume que los paquetes RTP son comprimidos y descomprimidos en la misma orden. Si consiguen reordenados, después la descompresión no ocurre correctamente. No es actualmente seguro utilizar el crtp si hay más de un Canal B en el conjunto MLPPP. La misma restricción solicita el MLPPP over ATM o el Frame Relay. En este caso, el crtp no es posible si hay más de un virtual circuit (VC) en el conjunto. Una solución al problema que reordena es ofrecida por el Multilink PPP multiclase (MCMP). El MCMP da a paquetes entrelazados una pequeña encabezado con un número de secuencia. Esto permite que los paquetes entrelazados sean reordenados por el otro extremo del conjunto, antes de que ocurra la descompresión de crtp. El soporte MCMP se espera en el Cisco IOS Software Release 12.2(12)T. Refiera al RFC 2686 y al Id. de bug Cisco CSCdv46666 (clientes registrados solamente) para más información. Limitaciones CAC del Cisco CallManager Los clientes de Enterprise con las redes derivadas utilizan a menudo el ISDN para el backup de los datos. Cuando se despliega la Telefonía IP, los clientes les gusta utilizar el link del backup ISDN para la Voz, así como los datos. Esta configuración es posible pero hay algunas advertencias a observar. La Telefonía IP en las redes derivadas se basa típicamente en el modelo centralizado del procesamiento de llamadas, y utiliza el CAC basado en la ubicación para limitar el número de llamadas a través de WAN. El CAC basado en la ubicación no tiene actualmente ningún mecanismo para seguir los cambios de la topología en la red. El Cisco CallManager no es consciente si va el link principal a una bifurcación abajo y el backup ISDN activa. Por este motivo, es crítico que el link del backup ISDN soporta el mismo número de llamadas VoIP que el link principal. Si no, el CAC podría oversubscribe el link de backup. El ancho de banda real del link principal y del link de backup no necesita ser idéntico. Los links apenas necesitan poder llevar el mismo número de llamadas VoIP. Por ejemplo, el link de backup puede utilizar el crtp mientras que no hace el link principal. En este caso, menos ancho de banda se requiere en el link de backup para llevar el mismo número de llamadas que el link principal. Opciones del diseño Hay opciones de diseño amplio diversas disponibles para el diseñador de red basado en la versión de Cisco IOS Software usada. Estas opciones son: Voz y datos que coexisten en un solo Canal B con o sin el crtp

4 Esta capacidad está disponible en el Cisco IOS Software Release 12.2 y asigna un solo Canal B por mandato para la Voz y los datos. el crtp puede ser utilizado puesto que el ningún reordenar del paquete puede ocurrir en un solo link. Voz y datos sobre los Canales B Separate con o sin el crtp Esta opción está también disponible en el Cisco IOS Software Release 12.2 e intenta hacer un mejor uso de los canales B ISDN disponibles con la separación de Voz y de datos sobre diversos canales. Voz y datos que coexisten en los Canales B múltiples sin el crtp Esta capacidad fue introducida con el soporte para la reserva de ancho de banda del porcentaje en el Cisco IOS Software Release 12.2(2)T. Voz y datos que coexisten en los Canales B múltiples con el crtp Esta capacidad está disponible con el apoyo del MCMP en el Cisco IOS Software Release 12.2(12)T. La discusión sobre cada opción sigue incluyendo los ejemplos de configuración enumerados aquí. Configuración para la Voz y datos sobre un solo Canal B con el crtp Configuración para la Voz y datos sobre los Canales B Separate con el crtp Configuración para la Voz y datos que coexisten en los Canales B múltiples sin el crtp Configuración para la Voz y datos que coexisten en los Canales B múltiples con el crtp Voz y datos que coexisten en un solo Canal B con o sin el crtp En el Cisco IOS Software Release 12.2, el ancho de banda en un directiva-mapa se puede especificar solamente como cantidad fija hasta un máximo predeterminado del 75% del ancho de banda de link. Además, el ISDN se asume siempre para proporcionar 64 kbps del ancho de banda con independencia del número de Canales B usados en una interfaz BRI o PRI. Por lo tanto, 48 kbps son el máximo predeterminado del ancho de banda que se puede reservar en el directiva-mapa para el ISDN. Estas limitaciones significan que tiene solamente sentido de utilizar un Canal B para los paquetes RTP que llevan. De acuerdo con los requisitos, usted puede elegir llevar los datos y la Voz en el mismo Canal B. Alternativamente, usted puede utilizar el segundo Canal B de un BRI para los datos solamente. En ambas opciones del diseño, es seguro utilizar el crtp como todos los paquetes RTP viajan abajo de un solo Canal B, y no puede llegar fuera de servicio. Esta opción del diseño envía todo el tráfico de voz y de datos abajo de un solo Canal B. Puesto que la Voz y los datos compiten para el mismo link, usted necesita el LFI, el LLQ, y el CBWFQ. Usted puede utilizar también con seguridad el crtp puesto que no hay oportunidad para los paquetes RTP reordenarse. Por abandono, una servicio-directiva no puede reservar más de 48 kbps (el 75% de 64 kbps) para el RTP y la señalización VoIP. La cantidad mínima que usted puede asignar a la clase de la señalización VoIP es 8 kbps. Con los 40 kbps restante disponibles para uso del RTP, usted puede producir esta tabla que muestre el número máximo de llamadas que se puedan llevar por un solo BRI. Ejemplo de tamaño (bytes) PPS crtp Longitud del paquete (bytes) Ancho de banda (kbps) No Sí No Sí No Sí Llamadas por el BRI Esta salida muestra una configuración de muestra para la Voz y los datos sobre el mismo Canal B. Configuración para la Voz y datos sobre un solo Canal B con el crtp!--- This section shows only relevant parts of the configuration. class-map match-all VoIP-RTP match ip dscp ef!--- RTP packets. class-map match-all VoIP-SIG match ip dscp af31!--- VoIP signaling packets. policy-map voice-and-data

5 class VoIP-RTP priority 40! Kbps available for voice. class VoIP-SIG bandwidth 8!--- 8 Kbps is the minimum value allowed by Cisco IOS. interface BRI0/0 dialer pool-member 1 interface Dialer1 bandwidth 64!--- Increase the bandwidth from 56 to 64 Kbps. dialer pool 1 dialer remote-name routerb-dialer1 dialer-group 1 dialer string service-policy output voice-and-data!--- The service policy. ppp chap hostname routera-dialer1 ppp chap password cisco ppp multilink ppp multilink fragment-delay 10!--- THe LFI delay equals 10 msec. ppp multilink interleave!--- Enable LFI. ip rtp header-compression!--- RTP header compression is OK. Voz y datos sobre los Canales B Separate con o sin el crtp Este diseño es también posible por medio del Cisco IOS Software Release Sin embargo, para hacer un mejor uso de los canales B ISDN disponibles, se separan la Voz y los datos. El ejemplo elegido es conveniente para una configuración de la velocidad básica donde los paquetes RTP utilizan un Canal B, y el uso de los datos y de la señalización de voz el segundo Canal B. Los conceptos similares solicitan una configuración de la velocidad primaria donde más canales se pueden utilizar para los datos. Porque los paquetes RTP no compiten con ningunos datos, el LFI y el LLQ en el canal de voz no deben ser requeridos. Sin embargo, es una práctica adecuada habilitarla de todos modos. El Cisco Discovery Protocol (CDP) y las actualizaciones de ruteo se pueden habilitar por el error, o un ataque de Negación de servicio (DoS) puede inundar el canal de voz. En el canal de datos, no se requiere ningún LFI. Pero el CBWFQ se requiere para proteger la señalización VoIP contra los datos generales. Las actualizaciones de ruteo en el canal de voz necesitan ser suprimidas para evitar el tráfico que se rutea a través de esta interfaz. En su lugar, utilice la directiva basada encaminamiento para forzar los paquetes RTP a través del canal de voz. Usted puede utilizar con seguridad el crtp puesto que no hay oportunidad para los paquetes RTP reordenarse. Por abandono una servicio-directiva no puede reservar más de 48 kbps (el 75% de 64 kbps) para el RTP y la señalización VoIP. Sin embargo, es seguro aumentar el porcentaje hasta el 90% con este diseño, pues no hay otro tráfico en el canal de voz. Este máximo creciente se puede especificar con el comando max-reserved-bandwidth. De acuerdo con 57 kbps para el RTP, usted puede producir esta tabla que muestre el número máximo de llamadas que un solo BRI pueda llevar. Ejemplo de tamaño (bytes) PPS crtp Longitud del paquete (bytes) Ancho de banda (kbps) No Sí No Sí No Llamadas por el BRI

6 40 25 Sí Esta tabla muestra una configuración de muestra para la Voz y los datos sobre los Canales B separados. Configuración para la Voz y datos sobre los Canales B Separate con el crtp!--- This section shows only relevant parts of the configuration. Class-map match-all VoIP-RTP match ip dscp ef class-map match-all VoIP-SIG match ip dscp af31 policy-map voice-only class VoIP-RTP priority 57 policy-map data-and-signaling class VoIP-SIG bandwidth 8 interface BRI0/0 dialer pool-member 1 interface Dialer1 bandwidth 64!--- Increase the bandwidth from 56 to 64 Kbps. dialer pool 1 dialer remote-name routerb-dialer1 max-reserved-bandwidth 90!--- Allow 90% of the bandwidth to be reserved. dialer-group 1 dialer string service-policy output voice-only!--- RTP packets only. ppp chap hostname routera-dialer1 ppp chap password cisco ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave ip rtp header-compression interface Dialer2 dialer pool 1 dialer remote-name routerb-dialer2 dialer-group 1 dialer string service-policy output data-and-signaling!--- Data and VoIP signaling. ppp chap hostname routera-dialer2 ppp chap password cisco router eigrp 1 passive-interface dialer 1!--- Suppress routing on the voice channel. interface fastethernet 0/1 ip policy route-map ip-rtp!--- Policy route RTP packets.

7 route-map ip-rtp permit 10 match ip address 100 set interface dialer 1!--- Route RTP packets out dialer 1. access-list 100 permit udp any range any range dscp ef Voz y datos que coexisten en los Canales B múltiples sin el crtp Este diseño se aprovecha del hecho que a partir del Cisco IOS Software Release 12.2(2)T, usted puede especificar el ancho de banda en el directiva-mapa como porcentaje en vez de un número absoluto. Esta capacidad permite que usted aplique una política de servicio a un conjunto con los Canales B múltiples. Como consecuencia, los paquetes RTP se pueden llevar a través de los Canales B múltiples. El equilibrio es que la implementación de los trayectos múltiples significa que el crtp no es seguro utilizar debido al reordenamiento potencial de los paquetes RTP. El Cisco IOS proporciona dos mecanismos para que usted controle cómo los Canales B adicionales se traen en respuesta a la demanda. El primer mecanismo se refiere comúnmente como On-Demand Routing del dial (DDR). El DDR requiere un umbral de carga ser especificado como una parte de ancho de banda disponible. Cuando el flujo de tráfico excede número de umbral, un canal adicional se agrega al conjunto. Se calcula el umbral pues una media corriente, y allí es cierto retardo en sacar a colación los Canales B adicionales cuando la carga aumenta. Este retardo no es un problema con los datos. Sin embargo, con la Voz, no es aceptable si un usuario hace las llamadas telefónicas, y tardan los minutos para sacar a colación el ancho de banda necesario para soportar el QoS para la llamada. Usted puede reducir el retardo para sacar a colación los canales adicionales a alrededor 30 segundos con el comando load-interval en la interfaz de ISDN física. Sin embargo, incluso 30 segundos son demasiado largos para que una llamada vaya sin el QoS requerido. La solución es tener el comando dialer load-threshold fijado a un valor que asegure el ancho de banda suficiente en la reserva para soportar por lo menos una llamada VoIP adicional con QoS apropiado. Puesto que todavía existe el problema si dos llamadas se sacan a colación dentro del intervalo 30-second, se prefiere un segundo y una solución más drástica. La solución es sacar a colación todos los Canales B inmediatamente y guardarlos para arriba mientras requieran al servicio ISDN. Usted puede utilizar el comando ppp multilink links minimum de especificar esta acción. Con dos Canales B disponibles, la servicio-directiva puede ahora reservar 96 kbps (el 75% del kbps 128) para el RTP y la señalización VoIP. Usted necesita 8 kbps para la señalización VoIP, así que ésta deja 88 kbps para el RTP. De acuerdo con el uso de dos Canales B, esta tabla muestra el número máximo de llamadas que se puedan llevar en el BRI. Ejemplo de tamaño (bytes) PPS crtp Longitud del paquete (bytes) Ancho de banda (kbps) No Sí No Sí No Sí Llamadas por el BRI Esta salida muestra una configuración de muestra para la Voz y los datos que coexisten en los Canales B múltiples sin el crtp. Configuración para la Voz y datos que coexisten en los Canales B múltiples sin el crtp!--- This section shows only relevant parts of the configuration. Class-map match-all VoIP-RTP match ip dscp ef class-map match-all VoIP-SIG match ip dscp af31 policy-map voice-and-data class VoIP-RTP priority percent 65!--- This is 65% of 64/128K for RTP. class VoIP-SIG bandwidth percent 10

8 !--- This is 10% of 64/128K for VoIP signaling. interface BRI0/0 dialer pool-member 1 interface Dialer1 dialer pool 1 dialer remote-name routerb-dialer1 dialer-group 1 dialer string service-policy output voice-and-data ppp chap hostname routera-dialer1 ppp chap password cisco ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave ppp multilink links minimum 2!--- Bring up two B-channels immediately. no ip rtp header-compression!--- crtp is not safe Voz y datos que coexisten en los Canales B múltiples con el crtp Con la introducción de MCMP en el Cisco IOS Software Release 12.2(12)T, el crtp que reordena el problema se soluciona, y es posible tener Canales B múltiples del uso de la Voz y todavía hacer el crtp. Los principios de diseño para esto son idénticos a ése discutidos en la Voz y los datos que coexisten en los Canales B múltiples sin la sección del crtp, con la única diferencia siendo que usted puede ahora habilitar el crtp. Esta tabla agrega el número máximo de llamadas que se puedan llevar en el BRI, sobre la base del uso del crtp en dos Canales B. Ejemplo de tamaño (bytes) PPS crtp Longitud del paquete (bytes) Ancho de banda (kbps) No Sí No Sí No Sí Llamadas por el BRI Para este escenario la configuración para la Voz y los datos que coexisten en los Canales B múltiples sin el crtp se aplica. La excepción es que ahora el MCMP está habilitado y el crtp está en cuando usted agrega esta salida a la interfaz del dialer. Configuración multiclase del multilink ppp de la muestra!--- This command is available with Cisco IOS Software Release 12.2(12)T. interface Dialer1 ppp multilink multiclass!--- Enable MCMP. ip rtp header-compression!--- Support crtp on the bundle Información Relacionada El protocolo del multilink PPP (MP), RFC1717, noviembre de 1994 Encabezados de compresión IP/UDP/RTP para los links de los seriales de baja velocidad La extensión multiclase a la multiconexión PPP Troubleshooting de Cisco IP Telephony Notas Técnicas de Troubleshooting