Introducción a la Compresión )incluido cRTP) y a la Calidad de Servicio

Introducción

Este documento examina los problemas conocidos al habilitar las funciones de Cisco IOS® Software de compresión y de Calidad de Servicio (QoS) en el mismo router.

El software Cisco IOS ofrece muchas funciones que optimizan los enlaces de red de área extensa (WAN) para aliviar los cuellos de botella del ancho de banda de la WAN. La compresión es un método de optimización eficaz e incluye dos tipos:

• Compresión de datos: proporciona a cada extremo un esquema de codificación que permite quitar caracteres de las tramas en el lado de envío del link y, a continuación, los reemplaza correctamente en el lado de recepción. Dado que las tramas condensadas ocupan menos ancho de banda, se pueden transmitir mayores números por unidad de tiempo. Algunos ejemplos de esquemas de compresión de datos son STAC, Microsoft Point-to-Point Compression (MPPC) y Frame Relay Forum 9 (FRF.9).

• Compresión de encabezados: comprime un encabezado en varias capas del modelo de referencia de interconexión de sistemas abiertos (OSI). Algunos ejemplos son la compresión de encabezados de protocolo de control de transmisión (TCP), RTP comprimido (cRTP) y protocolo de Internet comprimido/protocolo de datagramas de usuario (IP/UDP).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Descripción general de la compresión de datos

La función básica de la compresión de datos es reducir el tamaño de una trama de datos transmitida a través de un link de red. La reducción del tamaño de la trama reduce el tiempo necesario para transmitir la trama a través de la red.

Los dos algoritmos de compresión de datos más utilizados en los dispositivos de conexión entre redes son Stacker y Predictor.

Las siguientes configuraciones de ejemplo muestran dos maneras de habilitar la compresión de carga útil en una interfaz o subinterfaz Frame Relay.

interface Serial0/5
  ip address 10.0.0.1 255.255.255.0
  no ip directed-broadcast
  encapsulation frame-relay IETF
  clockrate 1300000
  frame-relay map ip 10.0.0.2 16 broadcast IETF payload-compression FRF9 stac

interface Serial0/0.105 point-to-point
  ip address 192.168.162.1 255.255.255.0
  no ip directed-broadcast
  frame-relay interface-dlci 105 IETF
  class 128k
  frame-relay payload-compression FRF9 stac

Hardware de compresión de Cisco

La compresión de datos asistida por hardware logra la misma funcionalidad general que la compresión de datos basada en software, pero acelera las tasas de compresión descargando esto computativamente de la CPU principal. En otras palabras:

• Compresión de Software: la Compresión se implementa en el software Cisco IOS instalado en el procesador principal del router.

• Compresión de hardware: la compresión se implementa en el hardware de compresión instalado en una ranura del sistema. La compresión de hardware elimina las responsabilidades de compresión y descompresión del procesador principal instalado en el router.

  La siguiente tabla enumera el hardware de compresión de Cisco y las plataformas soportadas:

La configuración de la compresión en una interfaz serial con un comando como compress stac habilita automáticamente la compresión de hardware si está disponible. De lo contrario, se habilita la compresión de software. Puede utilizar el comando compress stac software para forzar el uso de la compresión de software.

Cola especial y compresión por hardware

Esta sección trata un problema resuelto con la función de almacenamiento en cola de prioridad (PQ) heredada de Cisco y el hardware de compresión. El hardware de compresión originalmente quitó la cola de paquetes agresivamente de las PQ, eliminando de manera efectiva las ventajas de PQ. En otras palabras, PQ funcionó correctamente, pero la colocación en cola se trasladó funcionalmente a las propias colas del hardware de compresión (holdq, hw ring y compQ), que son estrictamente el primero en entrar, el primero en salir (FIFO). Los síntomas de este problema se documentan en el ID de bug de Cisco CSCdp33759 (marcado como un duplicado de CSCdm91180).

La resolución modifica el controlador del hardware de compresión. Específicamente, regula la velocidad a la que el hardware de compresión descoloca los paquetes mediante la reducción del tamaño de las colas de hardware según el ancho de banda de la interfaz. Este mecanismo de contrapresión asegura que los paquetes permanezcan en las colas de lujo en lugar de estar retenidos en las colas del hardware de compresión. Consulte los siguientes ID de bug para obtener más información:

Nota: Se puede encontrar más información sobre estos ID de bug usando el Bug Toolkit (sólo clientes registrados) .

• CSCdm91180: se aplica a la encapsulación Frame Relay y al adaptador de servicio de compresión (CSA).

• CSCdp33759 (y CSCdr18251): se aplica a la encapsulación PPP y al CSA.

• CSCdr18251: se aplica a la encapsulación PPP y a la compresión de módulos de interfaz asíncrona (AIM-COMPR).

Las colas de nivel de hardware de la compresión Cisco 3660 se pueden ver en el siguiente ejemplo de salida del comando show pas caim stats. Si las colas de compresión de hardware están almacenando muchos paquetes, un paquete quitado de la cola de espera en el extremo posterior de esta cola y, por lo tanto, experimenta un retraso.

Router> show pas caim stats 0

CompressionAim0
   ds:0x80F56A44 idb:0x80F50DB8
       422074 uncomp paks in  -->      422076 comp paks out
       422071 comp paks in    -->      422075 uncomp paks out
    633912308 uncomp bytes in -->    22791798 comp bytes out
     27433911 comp bytes in   -->   633911762 uncomp bytes out
          974 uncomp paks/sec in -->      974 comp paks/sec out
          974 comp paks/sec in -->        974 uncomp paks/sec out
     11739116 uncomp bits/sec in -->   422070 comp bits/sec out
       508035 comp bits/sec in -->   11739106 uncomp bits/sec out
   433 seconds since last clear
   holdq: 0  hw_enable: 1  src_limited: 0  num cnxts: 4
   no data: 0  drops: 0  nobuffers: 0 enc adj errs: 0 fallbacks: 0
   no Replace: 0 num seq errs: 0 num desc errs: 0 cmds complete: 844151
   Bad reqs: 0  Dead cnxts: 0 No Paks: 0 enq errs: 0
   rx pkt drops: 0  tx pkt drops: 0 >dequeues: 0 requeues: 0
   drops disabled: 0 clears: 0 ints: 844314 purges: 0
   no cnxts: 0  bad algos: 0 no crams: 0 bad paks: 0
   # opens: 0 # closes: 0 # hangs: 0

Nota: CSCdr86700 elimina los cambios implementados en CSCdm91180 de las plataformas que no soportan un CSA.

Además, mientras se solucionaba este problema, los problemas de expansión de paquetes con paquetes pequeños (alrededor de 4 bytes) y patrones repetitivos particulares, como los pings de Cisco con un patrón de 0xABCDABCD, se resolvieron con el ID de bug CSCdm11401. Es menos probable que los paquetes pequeños estén relacionados con otros paquetes en el flujo, y el intento de comprimirlos puede dar lugar a paquetes expandidos o causar reinicios del diccionario. La causa raíz es un problema con el chip utilizado en el CSA. El ID de bug de Cisco CSCdp64837 resuelve este problema cambiando el código de compresión FRF.9 para evitar comprimir los paquetes con menos de 60 bytes de carga útil.

Cola especial y compresión por software

A diferencia de la compresión por hardware, la compresión por software y la colocación en cola elaborada, incluidas las colas personalizadas, prioritarias y ponderadas equitativas, no se soportan en las interfaces configuradas con encapsulación PPP. Esta limitación se documenta en los ID de bug CSCdj45401 y CSCdk86833.

La razón de la limitación es que la compresión PPP no es sin estado y mantiene un historial de compresión sobre el flujo de datos para optimizar los ratios de compresión. Los paquetes comprimidos deben mantenerse para mantener el historial de compresión. Si los paquetes se comprimen antes de la colocación en cola, deben colocarse en una sola cola. Ponerlos en diferentes colas, como hacen las colas personalizadas y de prioridad, puede llevar a que los paquetes lleguen fuera de secuencia, lo que interrumpe la compresión. Las soluciones alternativas no son óptimas y no se han implementado. Estas alternativas incluyen la compresión de paquetes a medida que se quitan la cola (inaceptable por razones de rendimiento), el mantenimiento de un historial de compresión separado para cada cola (no admitido y que implica una sobrecarga significativa) y el restablecimiento del historial de compresión para cada paquete (afecta sustancialmente a los ratios de compresión). Como solución alternativa, puede configurar la encapsulación de control de enlace de datos (HDLC) de alto nivel, pero esta configuración puede afectar al rendimiento del sistema y no se recomienda. En su lugar, utilice la compresión de hardware.

Compresión de encabezado de RTP y QoS

RFC 1889 especifica el RTP, que administra el transporte de la ruta de audio para Voz sobre IP (VoIP). RTP proporciona servicios como la secuenciación para identificar los paquetes perdidos y los valores de 32 bits para identificar y distinguir entre varios remitentes en un flujo multicast. Es importante destacar que no proporciona ni garantiza la calidad de servicio.

Los paquetes VoIP se componen de una o más muestras de códec de voz o tramas encapsuladas en 40 bytes de encabezados IP/UDP/RTP. 40 bytes es una cantidad relativamente grande de sobrecarga para las cargas VoIP de 20 bytes típicas, especialmente en links de baja velocidad. RFC 2508 especifica RTP comprimido (cRTP), que está diseñado para reducir los encabezados IP/UDP/RTP a dos bytes para la mayoría de los paquetes en el caso de que no se envíen sumas de comprobación UDP, o cuatro bytes con sumas de comprobación. El algoritmo de compresión definido en este documento se basa en gran medida en el diseño de la compresión del encabezado TCP/IP como se describe en RFC 1144 .

RFC 2508 en realidad especifica dos formatos de cRTP:

• RTP comprimido (CR): se utiliza cuando los encabezados IP, UDP y RTP permanecen consistentes. Los tres encabezados están comprimidos.

• UDP comprimido (CU): se utiliza cuando hay un gran cambio en la marca de tiempo RTP o cuando cambia el tipo de carga útil RTP. Los encabezados IP y UDP están comprimidos, pero el encabezado RTP no lo está.

La versión 12.1(5)T del software del IOS de Cisco introdujo varias mejoras para la compresión sobre los circuitos virtuales permanentes (PVC) de Frame Relay en los routers de las series 2600, 3600 y 7200 de Cisco. Estas mejoras incluyen lo siguiente:

Problemas conocidos

La siguiente tabla enumera los problemas conocidos con las funciones de cRTP y Cisco IOS QoS. Esta lista es exacta en el momento de la publicación. Consulte también las Release Notes para su versión del software Cisco IOS para obtener más información.

policy-map test-policer
  class class-default
    police 10000 1500 1500 conform-action
transmit exceed-action transmit
    service-policy inner-police
!
policy-map inner-police
  class prec5
    police 20000 1500 1500 conform-action
transmit exceed-action transmit

Información Relacionada

• Página de Soporte de Qos (Calidad de Servicio)
• Soporte Técnico - Cisco Systems