Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundtheorie

FRF.12-Fragmentierung

FRF.11-Standard

FRF.11 Annex-C-Fragmentierung

Frame-Relay FRF.12 und FRF.11-Fragmentierung im Vergleich

Zugehörige Informationen

Einführung

In diesem Dokument werden zwei der FRF-Standards (Frame Relay Forum) (FRF.11 und FRF.12) erläutert, die Pakete in kleinere Frames fragmentieren. Weitere Informationen zum Design und zur Konfiguration von VoIP über ein Frame Relay-Netzwerk finden Sie im Dokument VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, IP RTP Priority).

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Hintergrundtheorie

Eine große Herausforderung bei der Integration von Sprachdaten besteht darin, die maximale unidirektionale End-to-End-Verzögerung für zeitkritischen Datenverkehr wie Sprache zu kontrollieren. Für eine gute Sprachqualität beträgt diese Verzögerung weniger als 150 Millisekunden (ms). Ein wichtiger Teil dieser Verzögerung ist die Serialisierungsverzögerung für die Schnittstelle, die 20 ms nicht überschreiten darf. Die Serialisierungsverzögerung ist die Zeit, die erforderlich ist, um die Bits auf einer Schnittstelle zu platzieren.

Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps])

Beispielsweise benötigt ein 1500-Byte-Paket (B) 187 ms, um den Router über eine 64-Kbit/s-Verbindung zu verlassen. Wenn Sie ein Datenpaket von 1500 B in Echtzeit senden, werden Echtzeit-Datenpakete (Sprache) bis zur Übertragung des großen Datenpakets in eine Warteschlange gestellt. Diese Verzögerung ist für Sprachdatenverkehr inakzeptabel. Wenn Datenpakete ohne Echtzeit in kleinere Frames fragmentiert werden, werden die Frames mit Echtzeit-Frames (Sprache) verschachtelt. Auf diese Weise können Sprach- und Daten-Frames ohne übermäßige Verzögerung des Echtzeit-Sprachdatenverkehrs über Low-Speed-Verbindungen übertragen werden.

FRF.12-Fragmentierung

FRF.12 ist ein Implementierungsvertrag, der Sprache und andere verzögerungsempfindliche Echtzeitdaten auf Low-Speed-Verbindungen unterstützt. Der Standard berücksichtigt Variationen in Frame-Größen, sodass eine Mischung aus Echtzeit- und Nicht-Echtzeit-Daten möglich ist.

FRF.12 legt fest, dass beim Einschalten der Fragmentierung für eine Data Link Connection Identifier (DLCI) nur Datenframes fragmentiert werden, die die angegebene Fragmentierungsgröße überschreiten. Auf diese Weise können kleine VoIP-Pakete, die aufgrund der Größe nicht fragmentiert sind, als Frames zwischen großen Datenpaketen, die in kleinere Frames fragmentiert wurden, verschachtelt werden. Dadurch wird die Serialisierungsverzögerung für Pakete, die den Router verlassen, erhöht. Sprachpakete warten daher nicht auf den Prozess großer Datenpakete.

Bei einer VoIP-Implementierung kann Frame Relay (Layer-2-Protokoll) nicht zwischen VoIP- und Daten-Frames unterscheiden. FRF.12 fragmentiert alle Pakete, die größer als die Fragmentgrößeneinstellung sind. Konfigurieren Sie die Fragmentierungsgröße des DLCI so, dass die Sprach-Frames nicht fragmentiert sind. Sie können die Fragmentgröße mithilfe des Befehls Frame-Relay der Cisco IOS® Software mit dem Problem des Befehls Frame-Relay Fragment Fragment_Size konfigurieren. Die Fragmentgröße ist in Byte angegeben, der Standardwert ist 53 B. Viele Variablen bestimmen die Größe der Sprachpakete. Weitere Informationen zur Größe von Sprachpaketen finden Sie im Dokument Voice over IP - Per Call Bandwidth Consumption (Bandbreitennutzung pro Anruf).

FRF.11-Standard

Eine VoFR-Implementierung (Voice over Frame Relay) definiert mithilfe von FRF.11, wie Sprache und Daten in den Frame-Relay-DLCI eingekapselt werden. Daten, Fax-Signalisierung und Sprache verwenden daher FRF.11-Kapselung für die Übertragung auf einem DLCI, der Sprache überträgt. Um diese Datenverkehrstypen in einem DLCI zu kombinieren, definiert FRF.11 Subkanäle (erkennbar durch Channel-IDs) innerhalb des DLCI. Jeder Unterkanal verfügt über ein Headerfeld, das den Nutzlasttyp des Frames beschreibt. FRF.11 kann bis zu 255 Subkanäle pro DLCI angeben.

Hinweis: Wenn Sie keine DLCIs für VoFR konfiguriert haben, verwenden die DLCIs die standardmäßige Frame-Relay-Datenkapselung, wie es in FRF.3.1 festgelegt ist.

FRF.11 Annex-C-Fragmentierung

FRF.11 Annex-C-Fragmentierung beschreibt, wie ein FRF.11-DLCI (konfiguriert für VoFR) Daten überträgt. FRF.11 Annex-C enthält eine Fragmentierungsspezifikation für die Daten-Subkanäle.

Nur Frames mit dem Datennutzlasttyp werden fragmentiert. Frame Relay unterscheidet Sprach-Frames von Nicht-Echtzeit-Daten-Frames, da die FRF.11-Payload den Datenverkehrstyp angibt. Aus diesem Grund umgeht der Sprach-Frame unabhängig von der Größe des Sprach-Frames die Fragmentierungs-Engine.

Frame-Relay FRF.12 und FRF.11-Fragmentierung im Vergleich

Es gibt mehrere bekannte Formen der Frame-Relay-Fragmentierung:

- FRF.11 Annex-C-Fragmentierung - Wird auf DLCIs verwendet, die für VoFR konfiguriert sind.

- FRF.12-Fragmentierung - Wird auf DLCIs verwendet, die Datenverkehr (FRF.3.1) übertragen, einschließlich VoIP. Das Layer 2 Frame Relay-Protokoll betrachtet die VoIP-Pakete als Daten.

Es besteht ein häufiges Missverständnis, dass die Fragmentierung von FRF.12 VoFR unterstützt, und es besteht generelle Unkenntnis darüber, dass FRF.11 auch ein Fragmentierungsschema angibt. Diese Verwirrung führt zu Missverständnissen bei der Fragmentierung für VoFR und VoIP über Frame Relay. In dieser Liste werden einige wichtige Unterschiede erläutert:

- Ein Frame-Relay-DLCI läuft entweder FRF.12 oder FRF.11, aber nie beides. FRF.12 und FRF.11 schließen sich gegenseitig aus.

- Wenn Sie den DLCI für VoFR konfiguriert haben, verwendet der DLCI FRF.11. Wenn die Fragmentierung für diesen DLCI eingeschaltet ist, verwendet der DLCI für die Fragmentierungs-Header FRF.11 Annex-C (oder das Cisco-Derivat).

- Wenn Sie den DLCI für VoFR nicht konfiguriert haben, verwendet der DLCI die Datenkapselung FRF.3.1. Wenn die Fragmentierung für diesen DLCI eingeschaltet ist, verwendet der DLCI FRF.12 für die Fragmentierungs-Header. DLCIs, die VoIP übertragen, verwenden FRF.12-Fragmentierung, da VoIP eine Layer-3-Technologie ist, die für Layer-2-Frame-Relay transparent ist.

- Sie können VoIP und VoFR auf verschiedenen DLCIs an derselben Schnittstelle, aber nicht im gleichen DLCI unterstützen.

- FRF.12 fragmentiert Sprachpakete, wenn Sie den Parameter "fragmentation size" (Fragmentierungsgröße) auf einen Wert festgelegt haben, der kleiner als die Größe des Sprachpakets ist. FRF.11 Annex-C (VoFR) fragmentiert Sprachpakete nicht, unabhängig von der von Ihnen konfigurierten Fragmentierungsgröße.

- FRF.11 Annex-C benötigt nur Unterstützung für Plattformen, die VoFR unterstützen. Da FRF.12 hauptsächlich für VoIP verwendet wird, ist es wichtig, FRF.12 als allgemeine Funktion auf Cisco IOS-Softwareplattformen zu unterstützen, die VoIP über langsame WAN-Verbindungen (langsamer als 1,5 Mbit/s) übertragen. Aus diesem Grund wird FRF.12 in der Cisco IOS Software Version 12.1.2T und höher auf Nicht-Voice-Gateway-Plattformen wie 805, 1600, 1700, 2500, 4500 und 4700 unterstützt.

Zugehörige Informationen

- Voice over IP - Bandbreitennutzung pro Anruf

- Befehlsreferenz - Voice over Frame Relay

- Unterstützung von Sprachtechnologie

- Produkt-Support für Sprach- und Unified Communications

- Fehlerbehebung bei Cisco IP-Telefonie

- Technischer Support - Cisco Systems