Diseño e implementación del PPP de link múltiple sobre Frame Relay y ATM

Introducción

Multilink PPP over ATM y Multilink PPP sobre Frame Relay (MLPoATM y MLPoFR) se presentaron en Cisco IOS® Software Release 12.1(5)T. Esta característica va dirigida a clientes con Frame Relay/conexión entre redes TM (FR/ATM IW) que despliegan voz sobre IP (VoIP) a través de medios en links WAN de velocidad lenta. Antes de esta función, no existía un esquema de fragmentación de Capa 2 común admitido por Cisco IOS tanto en ATM como en Frame Relay; los clientes con FR/ATM IW se veían obligados a realizar la fragmentación de Capa 3.

Prerequisites

Requirements

Este documento está dirigido al personal especializado en redes que participa en el diseño y la implementación de redes VoIP que comprenden redes MLPoATM y Frame Relay. Cisco recomienda que tenga conocimiento sobre estos temas:

• Frame Relay

• ATM

• PPP

• MLP

• Interconexión Frame Relay/ATM

• Configuración de Calidad de Servicio (QoS) para Voz

Este documento no tiene por objetivo proporcionar capacitación tecnológica sobre estos temas. Al final de este documento, se incluye una lista de materiales de referencia . Cisco recomienda que revise y comprenda estos documentos antes de leer éste:

• VoIP sobre Frame Relay con calidad de servicio (fragmentación, diseño de tráfico y prioridad LLQ / IP RTP)

• VoIP (Voz sobre IP) QoS (Calidad de servicio) para el Frame Relay para la interconexión ATM con LLQ (Cola de baja latencia), PPP LFI y cRTP

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Cisco IOS Software Versión 12.1(5)T o posterior para MLP sobre FR/ATM IW

• Cisco IOS Software Versión 12.2(2)T o posterior para Compressed Real Time Transport Protocol (cRTP) sobre ATM

• Cisco IOS Software Versión 12.0(7)T para Low Latency Queueing (LLQ) sobre Frame Relay y ATM en la Interfaz Física

• Cisco IOS Software Versión 12.1(2)T para LLQ sobre Frame Relay y ATM por circuito virtual permanente (PVC)

El caso práctico incluido en este documento está basado en una red de producción que utiliza estas versiones de software y hardware:

• Los routers Cisco 3660 de núcleo ejecutan Cisco IOS Software Release 12.2(5.8)T. El requisito para cRTP sobre ATM dicta el uso de Cisco IOS Software Release 12.2T. Este conocido problema está resuelto en Cisco IOS Software Versión 12.2(8)T1:

  Id. de error de Cisco CSCdw44216 (sólo para clientes registrados): El cRTP origina un uso excesivo de la CPU cuando se congestiona el enlace LLQ/CBWFQ (colocación en cola equilibrada ponderada basada en la clase).

• Los routers secundarios Cisco 2620 están en proceso de ser actualizados de Cisco IOS Software Versión 12.2(3) a uno 2.2(6a). Los Cisco 2620 también actúan como gateways secundarios H.323. La actualización se acciona por un problema relacionado con la gateway. Con respecto a las funciones WAN y QoS, Cisco IOS Software Versión 12.2(3) no presenta problemas significativos.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Diseño

Esta sección analiza diversos conceptos de diseño relacionados con el diseño y la implementación del PPP de Enlaces Múltiples sobre Frame Relay y ATM.

Sobrecarga de Enlace de Datos

Cuando diseña las redes ATM y Frame Relay con MLP, debe comprender la sobrecarga del enlace de datos. El costo operativo influye en la cantidad de ancho de banda consumido por cada llamada VoIP. También ayuda a determinar el tamaño óptimo del fragmento del MLP. Es fundamental optimizar el tamaño del fragmento para que llene un número entero de celdas ATM, especialmente en los PVC de baja velocidad donde se desperdicia una cantidad significativa de ancho de banda en el relleno de celdas. El consumo de recursos de enlace de datos en MLP por Frame Relay y en los ATM PVC depende de estos factores:

• El modo de operación del dispositivo FRF.8 IW (transparente o con traducción).

• La dirección del tráfico (ATM a Frame Relay o Frame Relay a ATM).

• El tramo PVC La tara es diferente en los tramos ATM y de retransmisión de tramas del PVC.

• El tipo de tráfico. Los paquetes de datos tienen un encabezado MLP; Los paquetes VoIP no lo hacen.

Esta tabla muestra la sobrecarga de enlace de datos para un paquete de datos. Especifica la cantidad de bytes en los diversos encabezados Frame Relay, ATM, LLC, PPP y MLD para todas las permutaciones del modo de funcionamiento FRF.8, dirección de tráfico y tramo de PVC.

¹DSAP/SSAP: Punto de Acceso al Servicio de Destino/Punto de Acceso al Servicio de Origen.

²NLPID: Identificación del Network Layer Protocol.

El PVC de traducción es el más fácil de comprender ya que la sobrecarga es la misma en ambas direcciones. Esto se debe a que el dispositivo FRF.8 traduce entre los formatos MLPoATM y MLPoFR. En consecuencia, el formato de trama es MLPoFR en el segmento Frame Relay, en ambas direcciones. El formato en el segmento ATM es MLPoATM en ambas direcciones.

El PVC transparente es un poco más desordenado porque la carga general varía en las dos direcciones. Esta complejidad se debe a que el router de Frame Relay envía paquetes en formato MLPoFR. Este formato es transportado a través del dispositivo IW al extremo ATM. De modo similar, el router de ATM envía paquetes en formato MLPoATM. Este formato es transportado a través del dispositivo IW al extremo Frame Relay. Por lo tanto, el resultado es formatos de trama diferentes en las dos direcciones de cada tramo.

En comparación, la sobrecarga en un PVC de Frame Relay integral que utiliza FRF.12 es 11 bytes. Por lo tanto, en un enlace Frame Relay integral, FRF.12 es una opción más eficaz para la fragmentación e intercalación de enlace (LFI) que MLP. En los circuitos virtuales ATM integrales (VC), MLP es la única elección debido a que no hay fragmentación basada en estándares que esté disponible. Sin embargo, los VC de ATM integrales son de velocidad media a alta. Por lo tanto, la LFI no es necesaria. La excepción a esta regla son los VC de ATM de baja velocidad sobre la línea de suscriptor digital (DSL).

El Id. de PPP está presente sólo en el primer fragmento MLP. Por lo tanto, el gasto en el primer fragmento siempre es dos bytes más que en los fragmentos posteriores.

Esta tabla muestra la sobrecarga de enlace de datos para un paquete VoIP. Especifica la cantidad de bytes en los diversos encabezados Frame Relay, ATM, LLC y PPP para todas las permutaciones del modo FRF.8 de funcionamiento, dirección de tráfico y tramo de PVC. La diferencia principal entre un paquete VoIP y un paquete de datos es que los paquetes VoIP se envían como paquetes PPP y no MLP. Todos los otros aspectos son idénticos al esquema de datos.

En comparación, la sobrecarga de enlace de datos para un paquete VoIP en un PVC de Frame Relay integral se indica en la última columna a la derecha.

Requisitos de ancho de banda para VoIP

Cuando administra ancho de banda para VoIP, debe incluir la sobrecarga de enlace de datos en los cálculos de ancho de banda. Esta tabla muestra los requisitos de ancho de banda por llamada para los diversos tipos de VoIP. Está basada en las características del PVC. Los cálculos en esta tabla presuponen el mejor escenario para cRTP (por ejemplo, sin suma de comprobación UDP ni errores de transmisión). Los encabezados se comprimen de 40 a 2 bytes, de modo uniforme.

Dado que la sobrecarga varía en las diferentes tramas del PVC, es necesario diseñar el peor de los casos. Por ejemplo, considere una llamada G.729 con una muestra de 20 milisegundos (ms) y cRTP a través de un PVC transparente. Los requerimientos de ancho de banda para este escenario en el tramo Frame Relay son de 12.4 Kbps en una dirección y 13.2 Kbps en la otra. Para el suministro debe disponer 13.2 Kbps por llamada.

En comparación, también se indica el requisito de ancho de banda para VoIP en un PVC de Frame Relay integral en la última columna a la derecha de la tabla anterior. Las tareas generales adicionales de PPP comparadas con el encapsulado de retransmisión de tramas nativas da como resultado un consumo adicional de ancho de banda entre 0.5 Kbps y 0.8 Kbps por llamada. Por lo tanto, el encapsulado de Frame Relay con FRF.12 tiene más sentido que el MLP en un VC integral de Frame Relay.

Nota: cRTP sobre ATM requiere Cisco IOS Software Versión 12.2(2)T o posterior.

Optimización del Tamaño de Fragmentación

La razón de utilizar MLP en un PVC de Frame Relay/ATM es permitir la fragmentación de grandes paquetes de datos en segmentos más pequeños. De este modo, el router intercala los paquetes VoIP entre los fragmentos de datos para reenviarlos. En Cisco IOS, el tamaño de fragmentación no está configurado directamente. Por el contrario, el retraso deseado se configura con la ayuda del comando ppp multilink fragment-delay. Cisco IOS utiliza esta fórmula para calcular el tamaño adecuado del fragmento:

fragment size = delay x bandwidth/8

Cuando utiliza MLP a través de ATM, el tamaño del fragmento debe optimizarse de modo que llene un número entero de celdas. Si no optimiza el tamaño, el ancho de banda requerido puede duplicarse debido a la función de relleno. Por ejemplo, si cada fragmento tiene una extensión de 49 bytes, se requieren dos celdas ATM para transportar cada uno. Por lo tanto, se utilizan 106 bytes para transportar una carga útil de sólo 49 bytes.

Cisco IOS optimiza el tamaño del fragmento automáticamente para utilizar un número entero de celdas ATM cuando realiza MLPoATM y MLPoFR. Redondea el tamaño del fragmento calculado al número entero siguiente de celdas ATM automáticamente. No se agregan nuevos comandos CLI. Cisco IOS realiza la optimización en los dos extremos, Frame Relay y ATM, de un PVC MLPoFR/ATM. Es posible que un PVC MLP sea un Frame Relay integral. En este caso, no requiere la optimización para ATM. Sin embargo, Cisco IOS realiza la optimización para ATM debido a que no tiene forma de detectar si el extremo remoto es ATM o Frame Relay.

Nota: Debido al redondeo, el retraso puede ser ligeramente mayor que el configurado. Este error de redondeo es más significativo en los PVC de baja velocidad.

También puede configurar la optimización manualmente. Como el tamaño del fragmento no puede especificarse directamente en Cisco IOS, calcule el tamaño óptimo del fragmento y conviértalo en un retraso. Cuando calcule el tamaño del fragmento, adáptelo según la sobrecarga de enlace de datos, ya que el código MLP supone que cada enlace es High-Level Data Link Control (HDLC) y tiene una sobrecarga de enlace de datos de 2 bytes. Además de la sobrecarga de enlace de datos HDLC, el código MLP incluye en sus cálculos 8 bytes compuestos por el Id. de MLP, el número de secuencia de MLP y el Id. de PPP, como se describe en la primera tabla anterior.

Utilice este procedimiento para calcular el retraso que debe configurar en Cisco IOS:

1. Calcule el tamaño teórico del fragmento en función del retraso y el ancho de banda deseado del PVC:

   fragment = bandwidth * delay / 8

2. Asegúrese de que el fragmento sea un múltiplo de 48 bytes, de manera que encaje dentro de un número entero de celdas ATM.

   La fórmula para calcular el tamaño del fragmento alineado de celdas es:

   fragment_aligned = (int(fragment/48)+1)*48

3. Ajustar para el link de datos de tara que el MLP no toma en cuenta.

   Como ya se indicó anteriormente, esta sobrecarga difiere según las características del PVC. Considere el extremo ATM del PVC, ya que éste es el extremo para el cual optimiza. Esta tabla muestra el número de bytes de la sobrecarga de enlace de datos en el extremo ATM.

   Modo FRF.8	Transparente		Traducción
   Dirección del tráfico	Frame Relay a ATM	ATM a Frame Relay	Frame Relay a ATM	ATM a Frame Relay
   Frame Relay o tramo ATM del PVC	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP (0xfefe)	0	2	2	2
   Control LLC (0x03)	1	1	1	1
   NLPID (Identificador de protocolo de capa de red) (0xcf para PPP)	1	1	1	1
   AAL5	8	8	8	8
   Tara no MLP (bytes)	10	12	12	12

   Para llegar al tamaño del fragmento sobre el que MLP basa sus cálculos, reste la sobrecarga de enlace de datos del tamaño del fragmento alineado de celdas que desea. Vuelva a agregar 2 bytes para compensar el encapsulado HDLC que el MLP siempre contempla.

   La fórmula para calcular el tamaño del fragmento al cual el código MLP apunta es:

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. Convierta el tamaño del fragmento que obtenga en el retraso correspondiente con esta fórmula:

   delay = fragment_mlp/bandwidth x 8bits/byte

5. En la mayoría de los casos, el retraso calculado no es un número entero de milisegundos. Dado que Cisco IOS sólo acepta un valor de número entero, deberá redondear. Por lo tanto, el valor de retraso que usted configura en Cisco IOS con la ayuda del comando ppp multilink fragment-delay es:

   fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)

6. Para compensar el error de redondeo antes mencionado, eluda el ancho de banda utilizado por MLP para convertir de retraso a fragmento. El ancho de banda eludido que usted configura en Cisco IOS con la ayuda del comando bandwidth es:

   bandwidth = fragment_mlp/fragment_delay * 8

Esta tabla muestra los valores óptimos de ppp multilink fragment-delay y bandwidth para la mayoría de las velocidades más comunes del PVC. Se supone un retraso de destino de 10 milisegundos Para simplificar la tabla, los cálculos no establecen diferencias entre PVC transparente o con traducción ni entre las direcciones del tráfico. La diferencia máxima en la tarea general de link de datos es sólo de 2 bytes. Por lo tanto, la penalidad por diseñar considerando el peor caso de 12 bytes es pequeña. En la tabla también se indica el retraso "real" que observará debido al hecho de que usted aumenta el tamaño del fragmento para que éstos llenen un número entero de celdas.

Consideraciones de regulación y modelado del tráfico

En un entorno Frame Relay/ATM IW se presta una atención especial a la regulación y el modelado del tráfico. Los problemas que se presentan de Frame Relay a ATM son distintos de los que surgen de ATM a Frame Relay. Por tal motivo, cada tema se describe por separado.

El problema principal en la dirección Frame Relay a ATM es el posible incremento del consumo de ancho de banda al transportar de la trama a la celda. Por ejemplo, una trama de 49 bytes en el extremo Frame Relay consume dos celdas o 106 bytes en el extremo ATM. Por lo tanto, no puede presuponerse que la velocidad de celda sostenible (SCR) sea equivalente a la velocidad de información comprometida (CIR). El peor de los casos se da cuando cada trama Frame Relay contiene 1 byte de carga útil. Cada uno de estos bytes consume una celda completa de 53 bytes en el extremo ATM. Como ejemplo de este concepto, este escenario extremo e irrealista dicta una SCR 53 veces mayor que la CIR. Dos ejemplos más realistas son:

• Un paquete VoIP G.729 tiene una extensión de 60 o 69 bytes (cuando incluye la sobrecarga de MLP o Frame Relay). En el segmento ATM consume dos celdas o 106 bytes. Por lo tanto, si todo el tráfico transportado es VoIP, entonces una correlación adecuada es SCR = 106/69 = 1.5 x CIR.

• Un paquete Telnet que transporta una sola pulsación de tecla contiene 40 bytes de encabezado TCP/IP y 1 byte de datos. En el lado de retransmisión de tramas, esto totaliza 56 bytes, incluyendo sobrecarga. No obstante, en el extremo ATM este paquete abarca dos celdas. En este caso, SCR = 106/56 = 1.9 x CIR.

El Apéndice A del estándar del Foro ATM, Especificación de la Interfaz entre portadoras BISDN (B-ICI) Versión 2.0, describe dos métodos de asignación entre SCR y CIR. Aunque ambas proporcionan una forma científica de derivar la RSC de la RIC, ninguna de ellas es más precisa que los datos a los que se aplican. Uno de los números requeridos por las fórmulas es el tamaño de trama común, un número que es difícil de determinar en una red real. Además, es un número que puede cambiar al implementar nuevas aplicaciones en una red ATM/Frame Relay existente. La mejor recomendación para resolver el problema es trabajar de cerca con su portadora, dado que su política de regulación es muy importante. Con la asistencia de la portadora, es posible esta metodología de protección contra errores:

• Dirección Frame Relay a ATM: En la dirección Frame Relay a ATM, la portadora debe controlar el tráfico entrante sólo en el punto de ingreso de Frame Relay. Por ejemplo, en el switch de Frame Relay conectado al dispositivo CPE (del inglés Frame Relay Customer Premises Equipment, equipo de las instalaciones del cliente conectado a Frame Relay), la portadora controla el tráfico según el CIR contratado. Esta política de regulación se ilustra en la figura aquí. No debe haber otra regulación una vez que se permite el tráfico en la red en el punto de ingreso. La implicación de esta política de regulación es que los datos recibidos del lado de Frame Relay pueden ampliar y consumir el ancho de banda que sea necesario para permitir impuesto de celda, sobrecarga AAL y relleno a fin de transportarlo por el tramo ATM de la red. En la mayoría de los casos, el ancho de banda ATM requerido es inferior al doble de ancho de banda que utiliza Frame Relay.

  

• Dirección ATM a Frame Relay: En la dirección ATM a Frame Relay, ocurre lo contrario. El uso de ancho de banda se reduce cuando va desde ATM a la trama como impuesto de celda, tara AAL y cuando se elimina el relleno. Sin embargo, como la velocidad de transmisión potencial del extremo ATM es mucho más alta que la del enlace Frame Relay, es fundamental configurar el modelado del tráfico correctamente en el router ATM para la integridad de la voz. Si el modelado es demasiado impreciso, entonces el router ATM suministra datos a una velocidad superior a la velocidad física del enlace Frame Relay en el otro extremo. En consecuencia, los paquetes comienzan a colocarse en la cola del switch FRF.8. En algún momento, los paquetes comienzan a caer . y dado que las redes ATM/Frame Relay no distinguen entre voz y datos, los paquetes VoIP también se descartan.

  Al mismo tiempo, si la modelación es muy restrictiva, el rendimiento se ve afectado. Debido al impuesto de celda ATM, se eliminan la tara y amortiguación de AAL por medio del dispositivo FRF.8. No consume ancho de banda en el enlace Frame Relay. Por lo tanto, puede exceder la suscripción del extremo ATM del PVC moderadamente. La cantidad de amortización y los costos operativos de AAL varían dependiendo del tamaño de trama promedio y de la agresividad de la fragmentación. Como usted no puede calificar esta sobrecarga con precisión, es mejor que no intente optimizar. Por otro lado, el impuesto de celda es un factor completamente determinante. Es de 5 bytes por cada 48 bytes de carga útil. Puede optimizar para el impuesto de celda al configurar el destino de modelado en el router ATM en 53/48 x SCR. La regulación en el extremo de la portadora debe configurarse de modo que permita este moderado exceso de suscripción.

Sugerencias y advertencias

• Actualmente, MLPoATM/Frame Relay sólo es probado y admitido con una política de servicio que se adjunta a la plantilla virtual o a las interfaces de marcado. Si se omite la política de servicio, es posible que no pueda utilizarse la función. En el Id. de error de Cisco CSCdu19313 (sólo para clientes registrados ) se incluye un ejemplo de esto.

• El MLPoATM/Frame Relay replica dos interfaces de acceso virtual para cada PVC. Uno de éstos representa el enlace PPP. El otro representa el agrupamiento MLP. El comando show ppp multilink se utiliza para saber cuál es cuál. No admite enlaces PPPoFR múltiples por agrupamiento. Poner dos circuitos PPPOFR en un solo tráfico de agrupamiento no se equilibrará bien la carga a través de los circuitos, ya que el controlador PPPOFR no proporciona la señalización de control de flujo que hacen los controladores seriales reales. El balanceo de carga MLPPP sobre ATM o Frame Relay puede mostrar notablemente menos efectividad que el mismo balanceo de carga sobre la interfaz física.

• Cada PVC está asociado a cuatro interfaces distintas, a saber, la interfaz física, la subinterfaz, y las dos interfaces de acceso virtual. Sólo la interfaz de acceso virtual MLP tiene habilitada la colocación en cola elaborada. Las otras tres interfaces deben tener la colocación en cola "primero en entrar, primero en salir" (FIFO).

• Cuando usted aplica un comando service-policy a una plantilla virtual, Cisco IOS muestra este mensaje de advertencia normal:

  cr7200(config)#interface virtual-template 1
  cr7200(config-if)#service-policy output Gromit
  Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
  Note CBWFQ supported on MLP bundle interface only.
  

  Estos mensajes son normales. El primer mensaje indica que una política de servicio no es admitida en la interfaz de acceso virtual PPP. El segundo mensaje confirma que se ha implementado la política de servicio en la interfaz de acceso virtual de agrupamiento MLP. Este hecho puede verificarse con la ayuda de los comandos show interfaces virtual-access, show queue y show policy-map interface para comprobar el mecanismo de colocación en cola.

• La autenticación de PPP no es estrictamente necesaria ya que un PVC es como una línea arrendada. No obstante, la autenticación de PPP es simple ya que se utiliza el comando show ppp multilink para determinar el nombre del router en el otro extremo del PVC.

• Debe habilitarse el modelado del tráfico de Frame Relay para los PVC MLPoFR, en el router Frame Relay.

• Al principio, Cisco IOS Software Versión 12.2 admitía un máximo de veinticinco plantillas virtuales por router. Esta limitación puede afectar la escala de un router de distribución ATM si cada PVC debe tener una dirección IP única. La solución temporal para las versiones afectadas es utilizar una interfaz de IP sin numerar o interfaces de marcador en lugar de plantillas virtuales. En Cisco IOS Software Versión 12.2(8)T se admiten hasta 200 plantillas virtuales.

• Algunos proveedores de servicio aún no admiten la traducción PPP en sus dispositivos FRF.8. En los casos que presenten esta limitación, los proveedores deben configurar los PVC en modo transparente.

• La mayoría de los ejemplos de la documentación sobre Cisco IOS muestran las configuraciones que incluye un Frame Relay o una subinterfaz ATM. Esta subinterfaz no cumple ninguna función. La plantilla virtual sólo debe adjuntarse a la interfaz física. Así la configuración es más compacta y fácil de administrar. Esto es especialmente importante si hay una gran cantidad de PVC.

• Utilice el comando show ppp multilink para determinar, de un modo simple, si hay interrupciones de celda/trama en el extremo de la portadora. La única pérdida de fragmento aceptable es aquella causada por errores de verificación por redundancia cíclica (CRC).

• Si bien en Cisco IOS Software Versión 12.1(5)T se implementó MLPoATM/Frame Relay, los errores que presenta esta versión y las posteriores indican que debe tener precaución al seleccionar la versión de Cisco IOS Software. Cisco recomienda utilizar la última versión de mantenimiento de la versión estándar Cisco IOS 12.2. Sin embargo, otros requisitos de funciones de VoIP pueden determinar el uso de una versión diferente de Cisco IOS Software, como 12.2(2)XT, si se requiere Survivable Remote Site Telephony (SRST). La siguiente tabla enumera algunos de los problemas más comunes. Cuando selecciona Cisco IOS, cada Id. de error de Cisco debe ser evaluado en comparación con el IOS seleccionado.

Caso Práctico

Introducción

Esta sección describe uno de los primeros despliegues de clientes de la función MLPoATM/Frame Relay. Se hace referencia al cliente mediante el nombre ficticio XYZ Ltd. En 2001, XYZ Ltd reemplazó los PBX por una solución de Telefonía IP. Como parte de este proyecto, se creó una nueva red IP. y la interconexión Frame Relay/ATM se eligió para la WAN. La portadora que brinda el servicio WAN utiliza switches Newbridge para suministrar los servicios de ATM y Frame Relay.

Información general de la red

XYZ Ltd es una red radial "hub-and-spoke" que conecta veintiséis sucursales con dos sitios centrales. Cada sitio del núcleo está atendido por un router Cisco 3660 conectado a E3 ATM. Dieciocho de las veintiséis sucursales son de tamaño mediano. Cuentan con PVC de Frame Relay dobles que se vuelven a conectar a los 3660 en los dos sitios centrales a través de ATM/Frame Relay IW. Las ocho sucursales restantes son muy pequeñas. Se vuelven a conectar a la sucursal de tamaño mediano más cercana a través de un solo PVC de Frame Relay. Todos los routers de sucursales son Cisco 2620. Un PVC ATM de extremo a extremo conecta los dos routers 3660 en los dos sitios hub. La siguiente figura ilustra la topología.

Esta tabla muestra las velocidades de acceso de Frame Relay y CIR. El CIR varía de 32 kbps a 256 kbps. También se muestra en la tabla la cantidad máxima de llamadas VoIP simultáneas transportadas por cada PVC.

Los routers secundarios realizan el modelado del tráfico de retransmisión de tramas. Las ráfagas por encima de CIR están permitidas. El modelado del tráfico del IOS de Cisco se configura para que se ajuste a la velocidad de acceso, con mincir igual a CIR. Si se reciben notificaciones explícitas de congestión hacia atrás (BECN) de la portadora, el router volverá a la mincir. Este método es contrario a las recomendaciones de Cisco al realizar VoIP sobre Frame Relay. La voz ya presenta problemas en el momento en que el router respondió a las notificaciones de congestión. No obstante, en este caso la portadora cree que su red cuenta con la suficiente provisión como para no perder nunca las tramas o las celdas y, por lo tanto, nunca deberían observarse BECN.

La formación del tráfico ATM se configura para que se produzca a la velocidad del acceso de tramas en el extremo remoto, más impuesto de celda. Por ejemplo, si la velocidad de acceso es 512 Kbps, entonces la SCR se configura en 512x53/48 = 565 Kbps. Esta velocidad de modelado se utiliza para maximizar el rendimiento. Esto es seguro ya que el impuesto de celda se elimina en el punto IW. En el lado de la portadora, la regulación se configura generosamente para permitir así el exceso leve de suscripción.

cRTP se utiliza en toda la WAN. En lo que se refiere a la CPU, el punto clave es el router de distribución Cisco 3660 en el sitio principal 1. Al agregar los números en la tabla anterior, se determina que el número máximo teórico de llamadas VoIP que atraviesan este router es 102 llamadas. Las cifras de rendimiento de este gráfico indican que la carga de la CPU de Cisco 3660 para 100 sesiones cRTP (que son conmutadas rápidamente) es de aproximadamente 50%.

Se utilizan plantillas virtuales con los links WAN con IP numerados. Se requiere una plantilla virtual por PVC, lo cual es posible ya que el número total de PVC que finalizan en cada Cisco 3660 es menor a veinticinco.

Configuraciones

En este documento, se utilizan estas configuraciones:

• Router ATM central

• Router de retransmisión de tramas secundario

!--- Note: This section shows the parts of a core Cisco 3660 router !--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note: Do not configure !--- IP addresses directly on any configuration source, !--- such as a virtual template, whenever the possibility !--- exists that this information is cloned to multiple !--- active interfaces. The exception to this rule is the !--- rare case where the intent is to define multiple parallel !--- IP routes and have IP do load balancing between them. !--- If an IP address is present on the configuration source, !--- this IP address is copied to all the cloned interfaces. !--- IP installs a route to each of these interfaces.
 

!--- Note: This section shows the parts of a branch Cisco 2600 router !--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

Información Relacionada

• VoIP sobre Frame Relay con calidad de servicio (fragmentación, diseño de tráfico y prioridad LLQ / IP RTP)
• VoIP (Voz sobre IP) QoS (Calidad de servicio) para el Frame Relay para la interconexión ATM con LLQ (Cola de baja latencia), PPP LFI y cRTP
• Configuración de la fragmentación y el entrelazado de link para circuitos virtuales ATM y Frame Relay
• PPP sobre AAL5, RFC 2364, julio de 1998
• PPP en Frame Relay, RFC1973, junio de 1996
• Protocolo de enlaces múltiples PPP (MP), RFC 1717, noviembre de 1994
• Compresión de encabezados IP/UDP/RTP para links seriales de baja velocidad, RFC 2508, febrero de 1999
• Acuerdo de implementación de interconexión de servicio PVC ATM / Frame Relay FRF.8.2
• Acuerdo de implementación de fragmentación de Frame Relay FRF.12
• Soporte de tecnología de voz
• Soporte para productos de comunicaciones IP y por voz
• Troubleshooting de Cisco IP Telephony
• Soporte Técnico y Documentación - Cisco Systems