Compressione (inclusa la tecnologia cRTP) e qualità del servizio

Introduzione

Questo documento esamina i problemi noti relativi all'abilitazione delle funzionalità software di compressione e Quality of Service (QoS) di Cisco IOS^® sullo stesso router.

Il software Cisco IOS offre molte funzioni per ottimizzare i collegamenti WAN (Wide-Area Network) e ridurre i colli di bottiglia della larghezza di banda della WAN. La compressione è un metodo di ottimizzazione efficace e include due tipi:

• Compressione dei dati: fornisce a ciascuna estremità uno schema di codifica che consente la rimozione dei caratteri dai frame sul lato di invio del collegamento e la loro corretta sostituzione sul lato di ricezione. Poiché i frame condensati occupano meno larghezza di banda, è possibile trasmettere un numero maggiore di frame per unità di tempo. Esempi di schemi di compressione dati includono STAC, Microsoft Point-to-Point Compression (MPPC) e Frame Relay Forum 9 (FRF.9).

• Compressione header: comprime un'intestazione a vari livelli del modello di riferimento OSI (Open System Interconnection). Gli esempi includono la compressione dell'intestazione TCP (Transmission Control Protocol), il protocollo RTP compresso (cRTP) e il protocollo IP/UDP (Internet Protocol/User Datagram Protocol) compresso.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Panoramica della compressione dei dati

La funzione di base della compressione dei dati consiste nel ridurre le dimensioni di un frame di dati trasmesso attraverso un collegamento di rete. Riducendo le dimensioni del frame si riduce il tempo necessario per trasmettere il frame attraverso la rete.

I due algoritmi di compressione dei dati più comunemente usati sui dispositivi di internetworking sono Stacker e Predictor.

Le seguenti configurazioni di esempio mostrano due modi per abilitare la compressione del payload su un'interfaccia o sottointerfaccia 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 Cisco Compression

La compressione dei dati basata su hardware offre le stesse funzionalità generali della compressione basata su software, ma accelera i rapporti di compressione scaricando il carico di elaborazione dalla CPU principale. In altre parole:

• Compressione del software: la compressione è implementata nel software Cisco IOS installato nel processore principale del router.

• Compressione hardware - La compressione è implementata nell'hardware di compressione installato in uno slot di sistema. La compressione hardware elimina le responsabilità di compressione e decompressione dal processore principale installato nel router.

  Nella tabella seguente vengono elencati l'hardware di compressione Cisco e le piattaforme supportate:

Configurando la compressione su un'interfaccia seriale con un comando quale compress stack, la compressione hardware viene attivata automaticamente, se disponibile. In caso contrario, la compressione software è attivata. È possibile utilizzare il comando compress stack software per forzare l'uso della compressione software.

Coda sofisticata e compressione hardware

In questa sezione viene descritto un problema risolto con la funzionalità PQ (Priority Queueing) di Cisco legacy e l'hardware di compressione. L'hardware di compressione ha originariamente rimosso i pacchetti dai PQ in modo aggressivo, rimuovendo in modo efficace i vantaggi di PQ. In altre parole, PQ ha funzionato correttamente, ma le code funzionalmente vengono spostate nelle code dell'hardware di compressione (holdq, hw ring e compQ), che sono strettamente FIFO (First-In, First-Out). I sintomi di questo problema sono documentati nell'ID bug Cisco CSCdp33759 (contrassegnato come duplicato di CSCdm91180).

La risoluzione modifica il driver dell'hardware di compressione. In particolare, limita la velocità con cui l'hardware di compressione rimuove i pacchetti dalla coda, riducendo le dimensioni delle code hardware in base alla larghezza di banda dell'interfaccia. Questo meccanismo di contropressione garantisce che i pacchetti rimangano nelle code più sofisticate anziché essere tenuti nelle code dell'hardware di compressione. Per ulteriori informazioni, fare riferimento ai seguenti ID bug:

Nota: per ulteriori informazioni su questi ID, consultare il Bug Toolkit (solo utenti registrati).

• CSCdm91180 - Si applica all'incapsulamento Frame Relay e alla scheda CSA (Compression Service Adapter).

• CSCdp33759 (e CSCdr18251) - Si applica all'incapsulamento PPP e alla CSA.

• CSCdr18251 - Si applica all'incapsulamento PPP e alla compressione asincrona del modulo di interfaccia (AIM-COMPR).

Le code a livello di hardware della compressione Cisco 3660 sono riportate nell'output di esempio seguente del comando show pas caim status. Se le code di compressione hardware memorizzano molti pacchetti, un pacchetto rimosso dalla coda PQ attende alla fine di questa coda, con un conseguente ritardo.

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:  CSCdr8670 rimuove le modifiche implementate in CSCdm91180 dalle piattaforme che non supportano CSA.

Inoltre, durante la risoluzione del problema, i problemi di espansione dei pacchetti con pacchetti di piccole dimensioni (circa 4 byte) e particolari modelli ripetitivi, come i ping Cisco con modello 0xABCDABCD, sono stati risolti con l'ID bug CSCdm11401. È meno probabile che i pacchetti di piccole dimensioni siano correlati ad altri pacchetti nel flusso e il tentativo di comprimerli potrebbe causare l'espansione dei pacchetti o la reimpostazione del dizionario. La causa principale è un problema del chip utilizzato nel CSA. L'ID bug Cisco CSCdp64837 risolve questo problema modificando il codice di compressione FRF.9 in modo da evitare la compressione dei pacchetti con meno di 60 byte di payload.

Fancy Queueing e compressione software

A differenza della compressione hardware, la compressione software e le code avanzate, incluse le code personalizzate, di priorità e ponderate, non sono supportate sulle interfacce configurate con l'incapsulamento PPP. Questa limitazione è documentata negli ID bug CSCdj45401 e CSCdk86833.

Il motivo di questo limite è che la compressione PPP non è senza stato e mantiene una cronologia della compressione sullo streaming di dati per ottimizzare i rapporti di compressione. I pacchetti compressi devono essere conservati per conservare la cronologia della compressione. Se i pacchetti vengono compressi prima dell'accodamento, devono essere inseriti in un'unica coda. L'inserimento di questi pacchetti in code diverse, come avviene con le code personalizzate e con priorità, può causare l'uscita dei pacchetti dalla sequenza, interrompendo la compressione. Le soluzioni alternative non sono ottimali e non sono state implementate. Tali alternative includono la compressione dei pacchetti quando vengono rimossi dalla coda (inaccettabile per motivi di prestazioni), il mantenimento di una cronologia di compressione separata per ciascuna coda (non supportata e con un sovraccarico significativo) e la reimpostazione della cronologia di compressione per ciascun pacchetto (che influisce in modo sostanziale sui rapporti di compressione). Per ovviare al problema, è possibile configurare l'incapsulamento HDLC (High-Level Data Link Control), ma questa configurazione potrebbe influire sulle prestazioni del sistema e non è consigliata. Utilizzare invece la compressione hardware.

Compressione header RTP e QoS

RFC 1889 specifica il protocollo RTP, che gestisce il trasporto del percorso audio per il protocollo VoIP (Voice over IP). Il protocollo RTP fornisce servizi come il sequenziamento, per identificare i pacchetti perduti, e i valori a 32 bit, per identificare e distinguere tra più mittenti in un flusso multicast. È importante notare che non fornisce né garantisce la qualità del servizio.

I pacchetti VoIP sono composti da uno o più esempi di codec vocali o frame incapsulati in 40 byte di intestazioni IP/UDP/RTP. I 40 byte sono un sovraccarico relativamente grande per i tipici payload VoIP da 20 byte, in particolare sui collegamenti a bassa velocità. La RFC 2508 specifica il protocollo RTP compresso (cRTP), progettato per ridurre le intestazioni IP/UDP/RTP a due byte per la maggior parte dei pacchetti nel caso in cui non venga inviato alcun checksum UDP, o a quattro byte con checksum. L'algoritmo di compressione definito in questo documento si basa in gran parte sulla struttura della compressione dell'intestazione TCP/IP descritta nella RFC 1144 .

La RFC 2508 specifica effettivamente due formati di cRTP:

• RTP compresso (CR): utilizzato quando le intestazioni IP, UDP e RTP rimangono coerenti. Tutte e tre le intestazioni vengono compresse.

• Compressed UDP (CU) - Utilizzata quando si verifica una modifica importante nel timestamp RTP o quando cambia il tipo di payload RTP. Le intestazioni IP e UDP sono compresse, ma l'intestazione RTP no.

Il software Cisco IOS versione 12.1(5)T ha introdotto diversi miglioramenti per la compressione sui circuiti virtuali permanenti (PVC) Frame Relay sui router Cisco serie 2600, 3600 e 7200. Tali miglioramenti includono:

Problemi noti

Nella tabella seguente vengono elencati i problemi noti relativi alle funzionalità QoS di Cisco IOS e cRTP. L'elenco è accurato al momento della pubblicazione. Fare riferimento anche alle note sulla versione del software Cisco IOS in uso per ulteriori informazioni.

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

Informazioni correlate

• Pagina di supporto QoS
• Supporto tecnico – Cisco Systems