Calidad de servicio (QoS) : Mecanismos de eficiencia de enlace QoS

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

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este problemas conocidos del documento revisa con habilitar las funciones del software del � del Cisco IOS de la compresión y del Calidad de Servicio (QoS) en el mismo router.

El Cisco IOS Software ofrece muchas características que optimicen los links del Red de área ancha (WAN) para facilitar el embotellamiento del ancho de banda WAN. La compresión es un método efectivo de optimización e incluye dos tipos:

  • Compresión de datos - Proporciona cada extremo con un esquema de codificación que permita que los caracteres sean quitados de las tramas en el lado emisor del link, y después las substituye correctamente en el lado de recepción. Puesto que las tramas condensadas ocupan menos ancho de banda, mayores números se pueden transmitir por la unidad de tiempo. Los ejemplos de los esquemas de compresión de datos incluyen el STAC, el Microsoft Point-to-Point Compression (MPPC), y el foro de Frame Relay 9 (FRF.9).

  • Compresión del encabezamiento - Comprime una encabezado en las diversas capas del modelo de referencia del interconexión de sistema abierto (OSI). Los ejemplos incluyen la compresión del encabezamiento del Transmission Control Protocol (TCP), el Compressed RTP (cRTP), y el protocolo de Internet/el protocolo UDP comprimidos (IP/UDP).

prerrequisitos

Requisitos

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. 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 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 los tamaños de un marco de datos transmitido sobre un link de red. La reducción de los tamaños del bastidor reduce el tiempo requerido para transmitir la trama a través de la red.

Los dos algoritmos de compresión de datos más de uso general en los dispositivos de funcionamiento entre redes son apilador y calculador.

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

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 asistidos por hardware alcanza la misma funcionalidad general que la compresión de datos basada en software, pero acelera las tarifas de la compresión descargando esto de cómputo de la CPU principal. En otras palabras:

  • Compresión del software - La compresión se implementa en el Cisco IOS Software instalado en el procesador principal del router.

  • Compresión por hardware - La compresión se implementa en el hardware de compresión instalado en un slot del sistema. La compresión por hardware quita la compresión y las responsabilidades de descompresión del procesador principal instalado en su router.

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

Hardware de compresión Plataformas Soportadas Notas
SA-Comp/1 y SA-Comp/4 adaptadores de servicio (CSA) Cisco 7200 Series Router y el Second-Generation Versatile Interface Processor (VIP2) en los Cisco 7000 y 7500 Series Router Algoritmo de depósito de los soportes sobre las interfaces seriales configuradas con el Point-to-Point Protocol (PPP) o la Encapsulación de Frame Relay.
NM-COMPR Cisco 3600 Series routers Algoritmo de depósito de los soportes sobre los links PPP y los links de Frame Relay con el algoritmo de compresión FRF.9.
AIM-COMPR4 Cisco 3660 Series Router solamente Supports Lempel-Ziv Standard (LZS) y algoritmos MPPC.

Configurar la compresión en una interfaz serial con un comando tal como stac de la compresa habilita automáticamente la compresión por hardware si está disponible. Si no, se habilita la compresión del software. Usted puede utilizar el comando compress stac software de forzar el uso de la compresión del software.

Cola especial y compresión por hardware

Esta sección discute un Problema resuelto con la característica y el hardware de compresión del Asignación de colas de prioridad (PQ) del legado de Cisco. El hardware de compresión dequeued originalmente los paquetes agresivamente de los PQ, quitando con eficacia las ventajas del PQ. Es decir el PQ trabajó correctamente, pero la espera funcionalmente se movió a las propias colas de administración del tráfico del hardware de compresión (holdq, timbre del hw y compQ), que son estrictamente primero en entrar, el primero en salir ((Primero en Salir FIFO)). Los síntomas de este problema se documentan en el Id. de bug Cisco CSCdp33759 (marcado como duplicado de CSCdm91180).

La resolución modifica al driver del hardware de compresión. Específicamente, estrangula la tarifa en la cual el hardware de compresión dequeues los paquetes reduciendo los tamaños de las colas de hardware basadas en el ancho de banda de la interfaz. Este mecanismo de contrapresión se asegura de que los paquetes permanezcan en las colas de administración del tráfico de lujo en vez de ser sostenido en las colas de administración del tráfico del hardware de compresión. Refiera a los ID de bug siguientes para más información:

Nota: Más información sobre estos ID de bug se puede encontrar usando el Bug Toolkit (clientes registrados solamente).

  • CSCdm91180 - Se aplica a la Encapsulación de Frame Relay y al Compression Service Adapter (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 módulo-compresión de la interfaz asincrónica (AIM-COMPR).

Las colas de administración del tráfico del nivel del hardware de la compresión del Cisco 3660 se pueden ver en la salida de muestra siguiente del comando show pas caim stats. Si las colas de administración del tráfico de la compresión por hardware están salvando muchos paquetes, un paquete dequeued del PQ espera en el fin de cola de esta cola, y las experiencias retrasan así.

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 quita los cambios implementados en CSCdm91180 de las Plataformas que no soportan un CSA.

Además, mientras que localizan averías este problema, los problemas de expansión de paquetes con los pequeños paquetes (alrededor 4 bytes) y los patrones repetitivos determinados, tales como Cisco hacen ping con un modelo de 0xABCDABCD, fueron resueltos con el ID de bug CSCdm11401. Los pequeños paquetes son menos probables ser relacionados con otros paquetes en la secuencia, y el intentar comprimirlos puede dar lugar a los paquetes ampliados, o cause los reinicios de diccionario. La causa raíz es un problema con el chip usado en el CSA. El Id. de bug Cisco CSCdp64837 resuelve este problema cambiando el código de la compresión FRF.9 para evitar comprimir los paquetes que tienen menos de 60 bytes de carga útiles.

Cola especial y compresión por software

En contraste con la compresión por hardware, la compresión del software y de lujo la espera, incluyendo la aduana, de la prioridad, y de la feria cargada que hace cola, no se soporta en las interfaces configuradas con la 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 apátrida y mantiene un historial de compresión sobre la secuencia de datos para optimizar las proporciones de compresión. Los paquetes comprimidos se deben guardar para mantener el historial de compresión. Si los paquetes son comprimidos antes de hacer cola, deben ser puestos en una cola única. Ponerlos en diversas colas de administración del tráfico, como espera de la aduana y de prioridad hacen, pueden llevar a los paquetes que llegan fuera de la secuencia, que rompe la compresión. Las soluciones alternativas son subóptimas y no se han implementado. Tales alternativas incluyen los paquetes de compresión como dequeued (inaceptable por las cuestiones de rendimiento), manteniendo un historial de compresión separado para cada cola (sin apoyo e implicando la tara significativa), y reajustando el historial de compresión para cada paquete (substancialmente proporciones de compresión de los impactos). Como solución alternativa, usted puede configurar el High-Level Data Link Control (HDLC) Encapsulation, pero esta configuración puede afectar al rendimiento del sistema y no se recomienda. En lugar, utilice la compresión por hardware.

Compresión de encabezado de RTP y QoS

El RFC 1889leavingcisco.com especifica el RTP, que maneja el transporte del trayecto de audio para la voz sobre IP (VoIP). El RTP proporciona los servicios tales que ordenando para identificar los paquetes perdidos y los valores de 32 bits para identificar y para distinguir entre los remitentes múltiples en una secuencia de multidifusión. Importantemente, no proporciona ni asegura QoS.

Los paquetes de VoIP se componen de una o más muestras o bastidores de los códecs de discurso encapsulados en 40 bytes de las encabezados IP/UDP/RTP. 40 bytes son relativamente una gran cantidad de gastos indirectos para las cargas útiles típicas 20-byte VoIP, determinado sobre los links de baja velocidad. El RFC 2508leavingcisco.com especifica el Compressed RTP (cRTP), que se diseña para reducir las encabezados IP/UDP/RTP a dos bytes para la mayoría de los paquetes en el caso donde no se está enviando ningunos checksums de UDP, o cuatro bytes con las sumas de comprobación. El algoritmo de compresión definido en este documento drena pesadamente sobre el diseño de la compresión del encabezado TCP/IP según lo descrito en el RFC 1144leavingcisco.com .

El RFC 2508 especifica realmente dos formatos del cRTP:

  • Compressed RTP (CR) - Utilizado cuando el IP, el UDP, y los encabezados RTP siguen siendo constantes. Las tres encabezados son comprimidas.

  • Compressed UDP (CU) - Utilizado cuando hay un cambio grande en la hora de RTP o cuando el tipo de carga útil RTP cambia. El IP y los encabezados UDP son comprimidos, pero el encabezado RTP no es.

El Cisco IOS Software Release 12.1(5)T introdujo varias mejoras para compresión sobre los circuitos virtuales permanentes de Frame Relay (PVC) en los Cisco 2600, 3600 y 7200 Series Router. Estas mejoras incluyen el siguiente:

Antes del Cisco IOS Release 12.1(5)T Cisco IOS Releases 12.1(5)T y 12.2
Los métodos de fragmentación PÁLIDOS despacio del borde necesarios para asegurar la Calidad de voz no trabajaron en las interfaces con la compresión por hardware. Estos métodos de fragmentación, que incluyen el C del anexo MLPPP/LFI, FRF.11, y FRF.12, trabajan con la compresión basada en software. Fragmentación (FRF.12 o Link Fragmentation and Interleaving (LFI)) se soportan así como la compresión por hardware. Además, la Fragmentación del anexo C FRF.12 y FRF.11 se soporta con la compresión por hardware FRF.9 en el mismo PVC. Los paquetes de voz del priority queue con el low latency queueing (LLQ) desvían el motor compresor FRF.9. Los paquetes de datos son comprimidos.
Las compresiones FRF.9 se soportan solamente en el IETF-encap PVC el cRTP y la compresión FRF.9 se soportan en el mismo PVC. La compresión FRF.9 se soporta en los PVC configurados con la encapsulación de Cisco y de la Fuerza de tareas de ingeniería en Internet (IETF) (IETF).
el cRTP se soporta en los PVC de Frame Relay configurados con la Encapsulación Cisco solamente. el cRTP continúa siendo soportado solamente en los PVC Cisco-encapsulados.

Problemas conocidos

La tabla siguiente enumera los problemas conocidos con el cRTP y las características de QoS del Cisco IOS. Esta lista es exacta a la hora de la publicación. También refiera el Release Note para su versión del Cisco IOS Software para más información.

ID de la falla Descripción
CSCdv73543 Cuando un jerárquico política de calidad de servicio (QoS), usando los comandos del Modular QoS CLI, se aplica a una interfaz de salida y especifica un policer de dos niveles, las relaciones del tráfico conformadas pueden ser menos que esperadas. El problema ocurre cuando el acción realizada en el paquete en un nivel es diferente de ése en el segundo nivel. Por ejemplo, conforme en el primer nivel y excédase en el segundo nivel. Una política de ejemplo se ilustra abajo:
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
CSCdt52094 Los descensos del paquete inesperado pueden ser considerados al usar el low latency queueing (LLQ) sobre el Frame Relay. El problema fue causado por el sistema de espera que no tomaba en cuenta las ganancias de ancho de banda del cRTP.
CSCds43465 Originalmente, el cRTP sucedió después de hacer cola. El resultado era que haciendo cola (potencialmente) vio un paquete mucho más grande que lo que fue transmitida realmente en el alambre. Este comportamiento se cambia con este bug. La espera ahora considera los paquetes comprimidos. Con este cambio, usted puede configurar las sentencias de ancho de banda con el CBWFQ basado en las tarifas de datos comprimidos.

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