Verständnis von Komprimierung (einschließlich cRTP) und Quality of Service

Einführung

In diesem Dokument werden bekannte Probleme bei der Aktivierung der Cisco IOS^®-Softwarefunktionen für Komprimierung und Quality of Service (QoS) auf demselben Router beschrieben.

Die Cisco IOS-Software bietet zahlreiche Funktionen zur Optimierung von WAN-Verbindungen (Wide Area Network), um Engpässe bei der WAN-Bandbreite zu vermeiden. Die Komprimierung ist eine effektive Optimierungsmethode und umfasst zwei Typen:

• Datenkomprimierung - Stellt jedem Ende ein Codierungsschema zur Verfügung, mit dem Zeichen aus den Frames auf der Absenderseite der Verbindung entfernt und dann auf der Empfängerseite korrekt ersetzt werden können. Da die kondensierten Frames weniger Bandbreite beanspruchen, können pro Zeiteinheit größere Zahlen übertragen werden. Beispiele für Datenkomprimierungsschemata sind STAC, Microsoft Point-to-Point Compression (MPPC) und Frame Relay Forum 9 (FRF.9).

• Header Compression - Komprimiert einen Header auf verschiedenen Ebenen des OSI-Referenzmodells (Open System Interconnection). Beispiele hierfür sind die Transmission Control Protocol (TCP)-Header-Komprimierung, komprimiertes RTP (cRTP) und das komprimierte Internet Protocol/User Datagram Protocol (IP/UDP).

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions.

Übersicht über die Datenkomprimierung

Die grundlegende Funktion der Datenkomprimierung besteht darin, die Größe eines über eine Netzwerkverbindung übertragenen Datenrahmens zu reduzieren. Durch die Reduzierung der Frame-Größe wird die Zeit für die Übertragung des Frames über das Netzwerk reduziert.

Die beiden am häufigsten verwendeten Datenkomprimierungsalgorithmen auf Internetarbeitsgeräten sind Stacker und Predictor.

Die folgenden Beispielkonfigurationen zeigen zwei Möglichkeiten zur Aktivierung der Payload-Komprimierung auf einer Frame-Relay-Schnittstelle oder Subschnittstelle.

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

Cisco Komprimierungs-Hardware

Hardwareunterstützte Datenkomprimierung bietet dieselbe allgemeine Funktionalität wie softwarebasierte Datenkomprimierung, beschleunigt jedoch die Komprimierungsrate, indem sie diese Computing-Leistung von der Haupt-CPU auslagert. Mit anderen Worten:

• Softwarekomprimierung - Die Komprimierung wird in der Cisco IOS-Software implementiert, die im Hauptprozessor des Routers installiert ist.

• Hardwarekomprimierung - Komprimierung wird in der Komprimierungshardware implementiert, die in einem Systemsteckplatz installiert ist. Durch Hardwarekomprimierung werden die Verantwortlichkeiten für Komprimierung und Dekomprimierung vom Hauptprozessor in Ihrem Router entfernt.

  In der folgenden Tabelle sind Cisco Hardware für Komprimierung und unterstützte Plattformen aufgeführt:

Die Konfiguration der Komprimierung auf einer seriellen Schnittstelle mithilfe eines Befehls wie Komprimierungsstatus ermöglicht automatisch eine Hardwarekomprimierung, sofern verfügbar. Andernfalls ist die Softwarekomprimierung aktiviert. Sie können den Befehl compress stac software verwenden, um die Verwendung von Softwarekomprimierung zu erzwingen.

Fancy Queuing und Hardware-Komprimierung

In diesem Abschnitt wird ein gelöstes Problem mit der Funktion für Legacy Priority Queueing (PQ) und der Komprimierungshardware von Cisco beschrieben. Bei der Komprimierungshardware wurden Pakete ursprünglich aggressiv von den PQs dewartete, wodurch die Vorteile von PQs praktisch wegfielen. Mit anderen Worten, PQ funktionierte ordnungsgemäß, aber Warteschlangen funktionell in die eigenen Warteschlangen der Komprimierungshardware (holdq, hw ring und compQ) verschoben, die streng First-In, First-Out (FIFO) sind. Die Symptome dieses Problems sind in der Cisco Bug-ID CSCdp33759 (als Duplikat von CSCdm91180 gekennzeichnet) dokumentiert.

Die Auflösung ändert den Treiber der Komprimierungshardware. Insbesondere wird die Geschwindigkeit gedrosselt, mit der die Komprimierungshardware Pakete dewartet, indem die Größe der Hardware-Warteschlangen auf Basis der Bandbreite der Schnittstelle reduziert wird. Dieser Rückdruckmechanismus stellt sicher, dass Pakete in den Fancy Queues verbleiben, anstatt in den Warteschlangen der Komprimierungshardware gehalten zu werden. Weitere Informationen finden Sie unter den folgenden Bug-IDs:

Hinweis: Weitere Informationen zu diesen Bug-IDs finden Sie im Bug Toolkit (nur registrierte Kunden) .

• CSCdm91180 - Gilt für Frame-Relay-Kapselung und den Compression Service Adapter (CSA).

• CSCdp33759 (und CSCdr18251) - Gilt für PPP-Kapselung und das CSA.

• CSCdr18251 - Gilt für PPP-Kapselung und die asynchrone Schnittstellenmodul-Komprimierung (AIM-COMPR).

Die Warteschlangen auf Hardwareebene der Cisco 3660-Komprimierung sind in der folgenden Beispielausgabe des Befehls show pas caim stats zu sehen. Wenn die Hardware-Komprimierungswarteschlangen viele Pakete speichern, wartet ein vom PQ dewartetes Paket am Ende dieser Warteschlange und vergeht somit Verzögerungen.

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

Hinweis: CSCdr86700 entfernt die in CSCdm91180 implementierten Änderungen von Plattformen, die kein CSA unterstützen.

Zusätzlich wurden bei der Behebung dieses Problems Paketerweiterungsprobleme bei kleinen Paketen (ca. 4 Byte) und bestimmten sich wiederholenden Mustern, wie z. B. Cisco Pings mit dem Muster 0xABCDABCD, mit der Bug-ID CSCdm1401 behoben. Kleine Pakete sind weniger wahrscheinlich mit anderen Paketen im Stream verwandt, und der Versuch, diese zu komprimieren, kann zu erweiterten Paketen führen oder zu einem Zurücksetzen des Wörterbuchs führen. Die Ursache hierfür ist ein Problem mit dem Chip, der auf dem CSA verwendet wird. Die Cisco Bug-ID CSCdp64837 löst dieses Problem, indem der FRF.9-Komprimierungscode geändert wird, um zu verhindern, dass Pakete mit einer Nutzlast von weniger als 60 Byte komprimiert werden.

Fancy Queuing und Softwarekomprimierung

Im Gegensatz zur Hardwarekomprimierung werden Softwarekomprimierung und Fancy Queueing, einschließlich benutzerdefinierter Warteschlangen, Priorität und gewichteter fairer Warteschlangen, auf Schnittstellen, die mit der PPP-Kapselung konfiguriert sind, nicht unterstützt. Diese Einschränkung ist in den Bug-IDs CSCdj45401 und CSCdk86833 dokumentiert.

Der Grund für diese Einschränkung ist, dass die PPP-Komprimierung nicht stateless ist und einen Komprimierungsverlauf über den Datenstrom aufrechterhält, um die Komprimierungsraten zu optimieren. Die komprimierten Pakete müssen aufbewahrt werden, um den Komprimierungsverlauf aufrechtzuerhalten. Wenn Pakete vor der Warteschlange komprimiert werden, müssen sie in einer einzigen Warteschlange gespeichert werden. Wenn sie in verschiedene Warteschlangen gestellt werden, wie dies bei der benutzerdefinierten Warteschlange und der Prioritätswarteschlange der Fall ist, können Pakete aus dieser Sequenz kommen, wodurch die Komprimierung unterbrochen wird. Alternative Lösungen sind nicht optimal und wurden nicht implementiert. Zu diesen Alternativen gehören das Komprimieren von Paketen während der Dewarteschlange (aus Leistungsgründen nicht akzeptabel), das Beibehalten eines separaten Komprimierungsverlaufs für jede Warteschlange (nicht unterstützt und mit erheblichem Overhead verbunden) und das Zurücksetzen des Komprimierungsverlaufs für jedes Paket (was sich erheblich auf Komprimierungsraten auswirkt). Als Problemumgehung können Sie eine High-Level Data Link Control (HDLC)-Kapselung konfigurieren. Diese Konfiguration kann sich jedoch auf die Systemleistung auswirken und wird nicht empfohlen. Verwenden Sie stattdessen Hardwarekomprimierung.

RTP Header Compression und QoS

RFC 1889 legt das RTP fest, das den Audio-Path-Transport für Voice over IP (VoIP) verwaltet. RTP stellt Dienste wie Sequenzierung zur Identifizierung verlorener Pakete und 32-Bit-Werte bereit, um mehrere Absender in einem Multicast-Stream zu identifizieren und zwischen diesen zu unterscheiden. Wichtig ist, dass keine QoS bereitgestellt oder sichergestellt wird.

VoIP-Pakete bestehen aus einem oder mehreren Sprach-Codec-Beispielen oder Frames, die in 40 Byte von IP-/UDP-/RTP-Headern gekapselt sind. 40 Byte sind eine relativ große Menge an Overhead für die typischen 20-Byte-VoIP-Payloads, insbesondere bei Verbindungen mit niedriger Geschwindigkeit. RFC 2508 gibt komprimiertes RTP (cRTP) an, das darauf ausgelegt ist, die IP/UDP/RTP-Header für die meisten Pakete auf zwei Byte zu reduzieren, wenn keine UDP-Prüfsummen gesendet werden, oder auf vier Byte mit Prüfsummen. Der in diesem Dokument definierte Komprimierungsalgorithmus basiert stark auf dem Design der TCP/IP-Header-Komprimierung, wie in RFC 1144 beschrieben.

RFC 2508 gibt zwei Formate von cRTP an:

• Komprimiertes RTP (CR) - Wird verwendet, wenn die IP-, UDP- und RTP-Header konsistent bleiben. Alle drei Header sind komprimiert.

• Komprimiertes UDP (CU) - Wird verwendet, wenn der RTP-Zeitstempel stark geändert wird oder sich der RTP-Payload-Typ ändert. Die IP- und UDP-Header sind komprimiert, der RTP-Header jedoch nicht.

Mit der Cisco IOS Software Version 12.1(5)T wurden bei den Cisco Routern der Serien 2600, 3600 und 7200 verschiedene Verbesserungen für die Komprimierung über permanente Virtual Circuits (PVCs) mit Frame-Relay eingeführt. Zu diesen Verbesserungen gehören:

Bekannte Probleme

In der folgenden Tabelle sind bekannte Probleme mit cRTP- und Cisco IOS QoS-Funktionen aufgeführt. Diese Liste ist zum Zeitpunkt der Veröffentlichung korrekt. Weitere Informationen finden Sie in den Versionshinweisen für Ihre Version der Cisco IOS-Software.

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

Zugehörige Informationen

• QoS-Support-Seite
• Technischer Support - Cisco Systems