Voz : Voice over Frame Relay (VOFR)

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

24 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (10 Abril 2009) | Inglés (22 Abril 2015) | Comentarios


Contenido


Introducción

El Multilink PPP sobre la atmósfera y el Multilink PPP sobre el Frame Relay (MLPoATM y MLPoFR) fueron introducidos en el Software Release 12.1(5)T de Cisco IOS�. 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.

prerrequisitos

Requisitos

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

  • Interfuncionamiento de ATM/Frame Relay

  • 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:

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:

  • El Cisco IOS Software Release 12.2(5.8)T del funcionamiento de los Cisco 3660 Router de la base. El requisito para el cRTP sobre la atmósfera dicta el uso del 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 link de datos en MLP en PVC ATM y Frame Relay 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 de VoIP no 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.

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 Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay
                 
Indicador de Frame (0x7e) 1 0 0 1 1 0 0 1
Encabezado de Retransmisión de Tramas 2 0 0 2 2 0 0 2
LLC DSAP/SSAP1 (0xfefe) 0 0 2 2 0 2 2 0
Control LLC (0x03) 1 1 1 1 1 1 1 1
NLPID2 (0xcf para PPP) 1 1 1 1 1 1 1 1
ID de protocolo MLP (0x003d) 2 2 2 2 2 2 2 2
Número de secuencia MLP 4 4 4 4 4 4 4 4
Id. de Protocolo PPP (Sólo primer fragmento) 2 2 2 2 2 2 2 2
Carga útil (Capa 3+) 0 0 0 0 0 0 0 0
Capa de adaptación (AAL)5 de ATM 0 8 8 0 0 8 8 0
Secuencia de verificación de tramas (FCS) 2 0 0 2 2 0 0 2
Tara total (bytes) 15 18 20 17 15 20 20 15

1DSAP/SSAP — Punto de acceso del servicio de destino/punto de acceso de servicio de origen.

2NLPID — Network Layer Protocol Identification.

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.

Modo FRF.8 Transparente Traducción Frame Relay a Frame Relay
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 Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay  
                   
Indicador de Frame (0x7e) 1 0 0 1 1 0 0 1 1
Encabezado de Retransmisión de Tramas 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0 0
Control LLC (0x03) 1 1 1 1 1 1 1 1 1
NLPID (Identificador de protocolo de capa de red) (0xcf para PPP) 1 1 1 1 1 1 1 1 1
PPP ID 2 2 2 2 2 2 2 2 0
Carga útil (IP+protocolo de datagrama de usuario (UDP)+RTP+voz) 0 0 0 0 0 0 0 0 0
AAL5 0 8 8 0 0 8 8 0 0
FCS 2 0 0 2 2 0 0 2 2
Tara total (bytes) 9 12 14 11 9 14 14 9 7

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.

Modo FRF.8 Transparente Traducción Frame Relay a Frame Relay
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 Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay  
                   
G.729 - 20 ms muestras - ningún cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G.729 - 20 ms muestras - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G.729 - 30 ms muestras - ningún cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G.729 - 30 ms muestras - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G.711 - Muestras de 20 ms - Sin cRTP 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
G.711 - Muestras de 20 ms - cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G.711 - 30 ms muestras - ningún cRTP 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G.711 - 30 ms muestras - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

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: el cRTP sobre la atmósfera requiere el Cisco IOS Software Release 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 retardo que resulta puede ser levemente más alto que lo configurada. 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.

Velocidad del PVC Tamaños del fragmento ppp multi-link fragment-delay Ancho de banda Retraso real
(Kbps) (celdas) (msec) (Kbps) (msec)
56 2 12 57 13.7
64 2 10 68 12.0
128 4 11 132 12.0
192 6 11 202 12.0
256 7 10 260 10.5
320 9 10 337 10.8
384 11 10 414 11.0
448 12 10 452 10.3
512 14 10 529 10.5
576 16 10 606 10.7
640 17 10 644 10.2
704 19 10 721 10.4
768 21 10 798 10.5

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 y poco realista dicta un SCR que sea 53 veces el CIR. Dos más ejemplos 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 de la norma de foro ATM, la versión de especificación inter 2.0 de la interfaz de portadora BISDN (B-ICI), describe dos métodos de asignación entre el SCR y el CIR. Mientras que ambos proporcionan una manera científica de derivar el SCR del CIR, ninguno son más exactos que los datos a los cuales son aplicados. 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 con el dispositivo asociado Frame Relay del Customer Premises Equipment (CPE), el portador limpia el tráfico según el CIR contratante. Esta política de establecimiento de políticas 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.

    http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-ingress-policing.gif

  • 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, comienzo de los paquetes a caer. y puesto que las redes de relay del ATM/Frame no distinguen entre la Voz y los datos, los paquetes de VoIP también se caen.

    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 tráfico del conjunto no será carga equilibrada bien a través de los circuitos, puesto que el driver PPPOFR no proporciona la señalización de control de flujo que lo hacen los drivers seriales reales. El Equilibrio de carga MLPPP sobre la atmósfera o el Frame Relay pudo mostrar perceptiblemente menos eficacia que el mismo Equilibrio 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.

ID de falla de funcionamiento de Cisco Descripción
CSCdt09293 (sólo para clientes registrados) LFI: La conmutación rápida en 7200 origina llamadas de voz en una sola dirección.
CSCdt25586 (sólo para clientes registrados) El acceso inestable PPPoA o el circuito virtual conmutado (SVC) no se cierran en tiempo de espera de inactividad.
CSCdt29661 (sólo para clientes registrados) MLP: El cierre de la interfaz ATM durante la conmutación rápida produce desperfectos en el router.
CSCdt53065 (sólo para clientes registrados) Mejora del funcionamiento en el código atm_lfi para la función LFI ATM.
CSCdt59038 (sólo para clientes registrados) MLPoATM: Ping con paquetes grandes presenta fallas en PA-A3.
CSCdu18344 (sólo para clientes registrados) El rendimiento del PVC de MLPoATM/Frame Relay es inferior a la mitad de la SCR/CIR.
CSCdu19297 (sólo para clientes registrados) El PVC de MLPoATM sin política de servicio genera errores.
CSCdu41056 (sólo para clientes registrados) MLPoATM: Se llama dos veces a la rutina vc_soutput del controlador.
CSCdu44491 (sólo para clientes registrados) Los contadores de acceso virtual muestran valores incorrectos en MLPoFR.
CSCdu51306 (sólo para clientes registrados) Las señales de mantenimiento se interrumpen en PPPoX.
CSCdu57004 (sólo para clientes registrados) El CEF no funciona con MLP.
CSCdu84437 (sólo para clientes registrados) Implementación del control de flujo entre los controladores adaptados al anillo de transmisión y MLP.
CSCdv03443 (sólo para clientes registrados) Arreglo del cometer para u76585 en el Software Release 12.2 de Cisco IOS� - los paquetes MLP entrantes son proceso conmutado.
CSCdv10629 (sólo para clientes registrados) MLPoATM: Los paquetes de voz no son colocados en la cola LLQ.
CSCdv20977 (sólo para clientes registrados) Los paquetes MLP de entrada están siendo conmutados por proceso.
CSCdw44216 (sólo para clientes registrados) El cRTP origina un uso excesivo de la CPU cuando se congestiona el enlace CBWFQ/LLQ.
CSCdy70337 (sólo para clientes registrados) Cuando un MLP se combina con QoS, la política de servicio está en uso.
CSCdx71203 (sólo para clientes registrados) En algunas ocasiones, un agrupamiento MLP puede tener algunos enlaces inactivos.

Caso Práctico

Introducción

Esta sección describe uno de los primeros despliegues de clientes de la función MLPoATM/Frame Relay. El nombre ficticio XYZ Ltd refiere al cliente. En 2001, XYZ Ltd substituyó sus PBX por una solución de telefonía IP. Como parte de este proyecto, una nueva red del IP fue construida. y el interfuncionamiento de ATM/Frame Relay fue elegido para 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. Todo el Routers de sucursales es Cisco 2620. Una atmósfera de punta a punta PVC conecta a los dos 3660 Router en los dos sitios del eje de conexión. La siguiente figura ilustra la topología.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-network.gif

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

‘Sitio’ Sitio remoto Acceso (kbps) CIR (kbps) Cantidad de llamadas
Sucursal 1 Core 1 320 192 6
Bifurcación 2 Bifurcación 22 128 64 2.0
Bifurcación 3 Core 1 576 256 8.0
Bifurcación 4 Bifurcación 16 64 32 2.0
Bifurcación 5 Core 1 128 64 2.0
Bifurcación 6 Bifurcación 3 64 32 2.0
Bifurcación 7 Core 1 512 256 8.0
Bifurcación 8 Core 1 512 256 8.0
Bifurcación 9 Bifurcación 13 128 256 2.0
Bifurcación 10 Core 1 256 128 4.0
Bifurcación 11 Base 2 128 96 2.0
Bifurcación 12 Core 1 128 64 2.0
Bifurcación 13 Core 1 768 256 12.0
Bifurcación 14 Core 1 192 96 4.0
Bifurcación 15 Core 1 192 96 4.0
Bifurcación 16 Core 1 448 192 8.0
Bifurcación 17 Bifurcación 13 128 64 2.0
Bifurcación 18 Core 1 128 96 2.0
Bifurcación 19 Bifurcación 16 128 64 2.0
Bifurcación 20 Core 1 64 32 2.0
Base 2 Core 1 34000 256 12.0
Bifurcación 21 Bifurcación 13 128 64 2.0
Bifurcación 22 Core 1 384 192 6.0
Bifurcación 23 Core 1 512 256 8.0
Bifurcación 24 Core 1 192 96 2.0
Bifurcación 25 Core 1 128 96 4.0
Bifurcación 26 Sucursal 1 64 32 2.0

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 Cisco IOS se fija para formar a la velocidad de acceso, con el mincir igual al CIR. Si las notificaciones explícitas de la congestión del reenvío (BECN) se reciben del portador, entonces el router estrangula de nuevo al 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. Hot spot por lo que el CPU es el router de distribución del Cisco 3660 en el sitio del núcleo 1. Agregando los números en la tabla antedicha, se determina que el máximo hipotético de número de llamadas VoIP que atraviesen a 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%.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-3660-performance.gif

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

!--- 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.
 

Router de retransmisión de tramas secundario

!--- 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

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 25084