Entwerfen und Bereitstellen von Multilink PPP über Frame Relay und ATM

Einleitung

Multilink PPP over ATM und Multilink PPP over Frame Relay (MLPoATM und MLPoFR) wurden in Cisco IOS® Software, Version 12.1(5)T, eingeführt. Diese Funktion richtet sich an Kunden mit Frame Relay/ATM Interworking (FR/ATM IW), die Voice over IP (VoIP) über WAN-Links mittlerer bis niedriger Geschwindigkeit bereitstellen. Vor dieser Funktion gab es kein gemeinsames Layer-2-Fragmentierungsschema, das von Cisco IOS sowohl für ATM- als auch Frame Relay-Kunden mit FR/ATM IW unterstützt wurde, die gezwungen waren, Layer-3-Fragmentierung vorzunehmen.

Voraussetzungen

Anforderungen

Dieses Dokument richtet sich an Netzwerkmitarbeiter, die am Design und der Bereitstellung von VoIP-Netzwerken beteiligt sind, die MLPoATM- und Frame Relay-Netzwerke umfassen. Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Frame Relay

• Geldautomat

• PPP

• MLP

• Frame-Relay/ATM-Interworking

• Konfiguration der Sprachqualität

Dieses Dokument ist nicht dazu gedacht, Technologieschulungen zu diesen Themen anzubieten. Am Ende dieses Dokuments finden Sie eine Liste der Referenzmaterialien. Cisco empfiehlt, die folgenden Dokumente vor dem Lesen dieses Dokuments zu überprüfen und zu verstehen:

• VoIP over Frame Relay mit Quality of Service (Fragmentierung, Traffic Shaping, LLQ/IP RTP-Priorität)

• VoIP QoS für Frame Relay an ATM Interworking mit LLQ, PPP LFI und cRTP

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Cisco IOS Software Release 12.1(5)T oder höher für MLP über FR/ATM IW

• Cisco IOS Softwareversion 12.2(2)T oder höher für Compression Real Time Transport Protocol (cRTP) über ATM

• Cisco IOS Softwareversion 12.0(7)T für Low Latency Queueing (LLQ) über Frame Relay und ATM auf der physischen Schnittstelle

• Cisco IOS Software Release 12.1(2)T für LLQ over Frame Relay und ATM pro Permanent Virtual Circuit (PVC)

Die in diesem Dokument enthaltene Fallstudie basiert auf einem Produktionsnetzwerk, das die folgenden Software- und Hardwareversionen verwendet:

• Auf den Cisco 3660 Core-Routern wird die Cisco IOS Software Version 12.2(5.8)T ausgeführt. Die Anforderung für cRTP über ATM bestimmt die Verwendung der Cisco IOS Software, Version 12.2T. Dieses bekannte Problem wurde in der Cisco IOS Softwareversion 12.2(8)T1 behoben:

  Cisco Bug ID CSCdw44216 (nur registrierte Kunden) - cRTP verursacht eine hohe CPU, wenn die CBWFQ/LLQ-Verbindung (Class-Based Weighted Fair Queueing) eine Überlastung erreicht.

• Die Cisco 2620 Router in der Außenstelle werden derzeit von der Cisco IOS Software Version 12.2(3) auf eine 2.2(6a) aktualisiert. Die Cisco Switches der Serie 2620 fungieren auch als H.323-Gateways der Außenstelle. Das Upgrade wird durch ein Gateway-spezifisches Problem ausgelöst. Hinsichtlich der WAN- und QoS-Funktionen weist die Cisco IOS Software Version 12.2(3) keine wesentlichen Probleme auf.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Design

In diesem Abschnitt werden verschiedene Designkonzepte für das Design und die Bereitstellung von Multilink PPP über Frame Relay und ATM erläutert.

Datenverbindungen-Overhead

Wenn Sie ATM- und Frame Relay-Netzwerke mit MLP entwerfen, müssen Sie den Overhead der Datenverbindung verstehen. Der Overhead beeinflusst die Bandbreite, die von jedem VoIP-Anruf benötigt wird. Sie hilft auch bei der Bestimmung der optimalen MLP-Fragmentgröße. Es ist wichtig, die Fragmentgröße so zu optimieren, dass sie auf eine ganzzahlige Anzahl von ATM-Zellen abgestimmt ist, insbesondere auf langsam wirkenden PVCs, bei denen eine beträchtliche Menge an Bandbreite für die Zellpadding verschwendet wird. Der Datenlink-Overhead auf MLP over Frame Relay und ATM-PVCs hängt von folgenden Faktoren ab:

• Der Betriebsmodus des FRF.8 IW-Geräts (transparent oder übersetzend).

• Die Richtung des Datenverkehrs (ATM zu Frame Relay oder Frame Relay zu ATM).

• Das PVC-Bein. Overhead ist auf den ATM- und Frame Relay-Beinen der PVC unterschiedlich.

• Der Datenverkehrstyp. Datenpakete verfügen über einen MLP-Header; VoIP-Pakete nicht.

Diese Tabelle zeigt den Overhead der Datenverbindung für ein Datenpaket. Es gibt die Byteanzahl in den verschiedenen Frame-Relay-, ATM-, LLC-, PPP- und MLP-Headern für alle Permutationen des FRF.8-Betriebsmodus, der Datenverkehrsrichtung und des PVC-Beins an.

¹DSAP/SSAP: Ziel-Service-Access-Point/Source-Service-Access-Point.

²NLPID - Network Layer Protocol Identification.

Der übersetzende PVC ist am einfachsten zu verstehen, da der Overhead in beide Richtungen gleich ist. Der Grund hierfür ist, dass das FRF.8-Gerät zwischen den Formaten MLPoATM und MLPoFR übersetzt wird. Daher ist das Frame-Format MLPoFR auf dem Frame-Relay-Bein in beide Richtungen. Das Format auf der ATM-Etappe ist MLPoATM in beide Richtungen.

Die transparente PVC ist etwas Messier, weil die Overhead in die beiden Richtungen unterschiedlich. Diese Komplexität entsteht, weil der Frame-Relay-Router Pakete im MLPoFR-Format sendet. Dieses Format wird vom IW-Gerät auf die ATM-Seite übertragen. Ebenso sendet der ATM-Router Pakete im MLPoATM-Format. Dieses Format wird vom IW-Gerät auf die Frame-Relay-Seite übertragen. Das Ergebnis sind daher unterschiedliche Frame-Formate in den beiden Richtungen auf den einzelnen Etappen.

Im Vergleich dazu beträgt der Overhead auf einem End-to-End Frame Relay PVC, der FRF.12 verwendet, 11 Byte. Daher ist FRF.12 auf einer End-to-End Frame Relay-Verbindung eine effizientere Wahl für Link Fragmentation and Interleaving (LFI) als MLP. Auf End-to-End ATM Virtual Circuits (VCs) ist MLP die einzige Wahl, da keine standardbasierte Fragmentierung verfügbar ist. End-to-End-ATM-VCs sind jedoch mittelschnell bis hochgeschwindigkeits. LFI ist daher nicht erforderlich. Eine Ausnahme zu dieser Regel sind langsame ATM VCs über digitale Teilnehmeranschlussleitungen (DSL).

Die PPP-ID ist nur im ersten MLP-Fragment vorhanden. Daher ist der Overhead im ersten Fragment immer zwei Byte größer als in nachfolgenden Fragmenten.

Die Tabelle hier zeigt den Datenlink-Overhead für ein VoIP-Paket. Es gibt die Byteanzahl in den verschiedenen Frame-Relay-, ATM-, LLC- und PPP-Headern für alle Permutationen des FRF.8-Betriebsmodus, der Datenverkehrsrichtung und des PVC-Beins an. Der Hauptunterschied zwischen Daten und VoIP-Paketen besteht darin, dass VoIP-Pakete als PPP-Pakete und nicht als MLP-Pakete gesendet werden. Alle anderen Aspekte sind identisch mit dem Datenszenario.

Im Vergleich dazu wird der Sicherungsschichtoverhead für ein VoIP-Paket auf einer End-to-End Frame Relay-PVC in der Spalte ganz rechts angezeigt.

VoIP-Bandbreitenanforderungen

Wenn Sie Bandbreite für VoIP bereitstellen, muss der Datenverbindungs-Overhead in die Bandbreitenberechnungen einbezogen werden. Diese Tabelle zeigt die Bandbreitenanforderungen pro Anruf für die verschiedenen VoIP-Varianten. Es basiert auf den Eigenschaften der PVC. Bei den Berechnungen in dieser Tabelle wird von einem Best-Case-Szenario für cRTP ausgegangen (z. B. keine UDP-Prüfsumme und keine Übertragungsfehler). Header werden dann konsistent von 40 Byte auf 2 Byte komprimiert.

Da die Overhead auf den verschiedenen PVC-Beinen variiert, ist es notwendig, für das Worst-Case-Szenario zu entwerfen. Beispiel: G.729 mit 20 Millisekunden (msec) Sampling und cRTP über eine transparente PVC. Die Bandbreitenanforderungen für dieses Szenario beim Frame-Relay-Bein betragen 12,4 Kbit/s in eine Richtung und 13,2 Kbit/s in die andere. Für die Bereitstellung wird von 13,2 Kbit/s pro Anruf ausgegangen.

Die VoIP-Bandbreitenanforderung für ein End-to-End Frame Relay PVC ist dagegen auch in der Spalte ganz rechts in der obigen Tabelle aufgeführt. Der zusätzliche Overhead von PPP im Vergleich zur nativen Frame-Relay-Kapselung führt zu einer zusätzlichen Bandbreitennutzung zwischen 0,5 Kbit/s und 0,8 Kbit/s pro Anruf. Daher ist Frame Relay-Kapselung mit FRF.12 sinnvoller als MLP auf einem End-to-End Frame Relay VC.

Hinweis: cRTP over ATM erfordert die Cisco IOS Software, Version 12.2(2)T oder höher.

Größe der Fragmentierung optimieren

Der Grund für die Verwendung von MLP auf Frame Relay/ATM-PVC besteht darin, dass große Datenpakete in kleinere Chunks fragmentiert werden können. Der Router beschleunigt dann die VoIP-Pakete, indem er sie zwischen den Datenfragmenten verbirgt. In Cisco IOS ist die Fragmentierungsgröße nicht direkt konfiguriert. Die gewünschte Verzögerung wird stattdessen mithilfe des Befehls ppp multilink fragment-delay konfiguriert. Anschließend berechnet Cisco IOS anhand dieser Formel die entsprechende Fragmentgröße:

fragment size = delay x bandwidth/8

Wenn Sie MLP über ATM hinweg ausführen, muss die Fragmentgröße so optimiert werden, dass sie in eine ganzzahlige Anzahl von Zellen passt. Wenn diese Optimierung nicht vorgenommen wird, kann sich die erforderliche Bandbreite aufgrund der Hinzufügung fast verdoppeln. Wenn beispielsweise jedes Fragment 49 Byte lang ist, sind zwei ATM-Zellen erforderlich, um jedes Fragment zu übertragen. Daher werden 106 Byte verwendet, um eine Nutzlast von nur 49 Byte zu übertragen.

Cisco IOS optimiert die Fragmentgröße automatisch, um eine ganzzahlige Anzahl von ATM-Zellen zu verwenden, wenn MLPoATM und MLPoFR ausgeführt werden. Cisco IOS rundet die berechnete Fragmentgröße automatisch auf die nächste ganzzahlige Anzahl von ATM-Zellen auf. Es werden keine neuen CLI-Befehle hinzugefügt. Cisco IOS führt diese Optimierung sowohl an den Frame Relay- als auch an den ATM-Enden einer MLPoFR/ATM-PVC durch. Es ist möglich, dass eine MLP-PVC ein End-to-End Frame Relay sein kann. In diesem Fall ist eine Optimierung für ATM nicht erforderlich. Cisco IOS optimiert dieses Szenario jedoch für ATM, da es nicht erkennen kann, ob das Remote-Ende ein ATM oder Frame Relay ist.

Hinweis: Aufgrund von Rundungen kann die Verzögerung etwas größer sein als die konfigurierte. Dieser Rundungsfehler ist bei Low-Speed-PVCs deutlicher.

Sie können die Optimierung auch manuell konfigurieren. Da die Fragmentgröße nicht direkt in Cisco IOS angegeben werden kann, berechnen Sie die optimale Fragmentgröße, und konvertieren Sie sie in eine Verzögerung. Wenn Sie die Fragmentgröße berechnen, passen Sie den Overhead der Datenverbindung an, da im MLP-Code davon ausgegangen wird, dass jede Verbindung eine High-Level Data Link Control (HDLC) ist und über 2 Byte Datenverbindungen-Overhead verfügt. Zusätzlich zum HDLC-Datenverbindungen-Overhead enthält der MLP-Code in seinen Berechnungen die 8 Byte aus der MLP-ID, der MLP-Sequenznummer und der PPP-ID, wie in der ersten Tabelle oben beschrieben.

Verwenden Sie dieses Verfahren, um die Verzögerung zu berechnen, die in Cisco IOS konfiguriert werden muss:

1. Berechnen Sie die theoretische Fragmentgröße basierend auf der gewünschten Verzögerung und der Bandbreite der PVC:

   fragment = bandwidth * delay / 8

2. Stellen Sie sicher, dass das Fragment ein Vielfaches von 48 Byte ist, sodass es in eine ganzzahlige Anzahl von ATM-Zellen passt.

   Die Formel zur Berechnung der zellbasierten Fragmentgröße lautet:

   fragment_aligned = (int(fragment/48)+1)*48

3. Passen Sie den Datenlink-Overhead an, der von MLP nicht berücksichtigt wird.

   Wie bereits erwähnt, unterscheidet sich dieser Overhead je nach PVC-Eigenschaften. Betrachten Sie die ATM-Seite der PVC, da dies die Seite ist, für die Sie optimieren. Diese Tabelle zeigt die Anzahl der Byte des Datenverbindungs-Overheads auf der ATM-Seite.

   FRF.8-Modus	Transparent		Übersetzung
   Richtung des Datenverkehrs	Frame Relay zu ATM	ATM zu Frame Relay	Frame Relay zu ATM	ATM zu Frame Relay
   Frame Relay oder ATM-Bein von PVC	Geldautomat	Geldautomat	Geldautomat	Geldautomat
   LLC DSAP/SSAP (0xfefe)	0	2	2	2
   LLC-Steuerung (0x03)	1	1	1	1
   NLPID (0xcf für PPP)	1	1	1	1
   AAL5	8	8	8	8
   Nicht-MLP-Overhead (Byte)	10	12	12	12

   Um die Fragmentgröße zu ermitteln, auf der die MLP-Berechnungen basieren, ziehen Sie den Overhead der Datenverbindung von der gewünschten zellbasierten Fragmentgröße ab. Fügen Sie 2 Byte zurück, um die HDLC-Kapselung auszugleichen, die MLP immer übernimmt.

   Die Formel zur Berechnung der Fragmentgröße, die für den MLP-Code vorgesehen ist, lautet:

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. Konvertieren Sie die Fragmentgröße, die mit dieser Formel in die entsprechende Verzögerung führt:

   delay = fragment_mlp/bandwidth x 8bits/byte

5. In den meisten Fällen handelt es sich bei der berechneten Verzögerung nicht um eine ganzzahlige Anzahl von Millisekunden. Da Cisco IOS nur einen ganzzahligen Wert akzeptiert, müssen Sie den Wert runden. Der Verzögerungswert, den Sie in Cisco IOS mithilfe des Befehls ppp multilink fragment-delay konfigurieren, lautet daher:

   fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)

6. Um den oben genannten Rundungsfehler auszugleichen, muss die von MLP für die Umwandlung von Verzögerung in Fragment verwendete Bandbreite verschüttet werden. Die erweiterte Bandbreite, die Sie im Cisco IOS mithilfe des Befehls Bandbreite konfigurieren, ist:

   bandwidth = fragment_mlp/fragment_delay * 8

Diese Tabelle zeigt die optimalen Werte für die ppp-Multilink-Fragmentverzögerung und die Bandbreite für die gebräuchlichsten PVC-Geschwindigkeiten. Eine Zielverzögerung von 10 ms wird angenommen. Um die Tabelle zu vereinfachen, wird in den Berechnungen nicht zwischen transparentem und übersetzendem PVC oder zwischen Verkehrsrichtungen unterschieden. Der maximale Unterschied beim Datenlink-Overhead beträgt nur 2 Byte. Daher ist die Strafe für das Design für den schlechtesten Fall von 12 Byte gering. Außerdem wird in der Tabelle die "tatsächliche" Verzögerung angezeigt, die auftritt, weil Sie die Fragmentgröße so erhöhen, dass Fragmente in eine ganzzahlige Anzahl von Zellen passen.

Überlegungen zum Traffic Shaping und Policing

Traffic Shaping und Richtlinienvergabe werden in Frame Relay/ATM IW-Umgebungen besonders berücksichtigt. Die Probleme in der Richtung "Frame Relay to ATM" unterscheiden sich von denen in der Richtung "ATM to Frame Relay". Daher wird jedes Thema separat beschrieben.

Das Hauptproblem bei der Richtung "Frame Relay to ATM" ist die potenzielle Erweiterung der Bandbreitennutzung beim Wechsel von Frame zu Zelle. Beispielsweise benötigt ein Frame mit 49 Byte auf der Frame-Relay-Seite zwei Zellen bzw. 106 Byte auf der ATM-Seite. Daher kann nicht davon ausgegangen werden, dass die nachhaltige Zellenrate (SCR) der zugesicherten Informationsrate (CIR) entspricht. Das Worst-Case-Szenario tritt ein, wenn jeder Frame-Relay-Frame ein Byte Nutzlast enthält. Jedes dieser Bytes benötigt eine vollständige 53-Byte-Zelle auf der ATM-Seite. Ein Beispiel für dieses Konzept ist, dass dieses extreme und unrealistische Szenario eine SCR vorschreibt, die 53 Mal so hoch ist wie die CIR. Zwei realistischere Beispiele sind:

• Ein G.729-VoIP-Paket ist 60 Byte lang oder 69 Byte (wenn MLP- und Frame-Relay-Overhead enthalten sind). Auf der ATM-Seite verbraucht es zwei Zellen oder 106 Byte. Wenn also der gesamte Datenverkehr VoIP ist, ist die entsprechende Zuordnung SCR = 106/69 = 1,5 x CIR.

• Ein Telnet-Paket, das einen einzelnen Tastenanschlag enthält, enthält 40 Byte TCP/IP-Header und 1 Byte Daten. Auf der Frame-Relay-Seite beträgt diese Summe 56 Byte, einschließlich Overhead. Auf der ATM-Seite wird dieses Paket jedoch auf zwei Zellen erweitert. In diesem Fall SCR = 106/56 = 1,9 x CIR.

In Anhang A des ATM Forum-Standards BISDN Inter Carrier Interface (B-ICI) Specification Version 2.0 werden zwei Methoden zur Zuordnung zwischen SCR und CIR beschrieben. Beide bieten eine wissenschaftliche Möglichkeit, SCR aus der CIR abzuleiten, aber keiner ist genauer als die Daten, auf die sie angewendet werden. Eine der für die Formeln erforderlichen Zahlen ist die typische Frame-Größe, eine Zahl, die in einem echten Netzwerk schwer zu bestimmen ist. Eine Zahl, die sich ändern kann, wenn neue Anwendungen in einem bestehenden ATM/Frame Relay-Netzwerk eingeführt werden. Die beste Empfehlung zur Lösung dieses Problems ist die enge Zusammenarbeit mit Ihrem Betreiber, da dessen Policing-Richtlinie von entscheidender Bedeutung ist. Mithilfe des Carriers ist dieser ausfallsichere Ansatz möglich:

• Frame Relay to ATM Direction - In der Frame Relay to ATM-Richtung muss der Carrier den eingehenden Datenverkehr nur am Frame Relay-Eingangspunkt überwachen. Auf dem mit dem CPE-Gerät (Frame Relay Attached Customer Premises Equipment) verbundenen Frame-Relay-Switch regelt der Carrier beispielsweise den Datenverkehr gemäß der vertraglich vereinbarten CIR. Diese Richtlinie wird in der Abbildung hier veranschaulicht. Sobald Datenverkehr in das Netzwerk am Eingangspunkt zugelassen ist, sollte keine weitere Richtlinienvergabe erfolgen. Diese Richtlinie impliziert, dass Daten, die auf der Frame-Relay-Seite empfangen werden, erweitert und genutzt werden können, welche Bandbreite für die Zellsteuer, den AAL-Overhead und das Padding benötigt wird, um diese Daten über den ATM-Bereich des Netzwerks zu übertragen. In den meisten Fällen beträgt die erforderliche ATM-Bandbreite weniger als das Doppelte der verwendeten Frame-Relay-Bandbreite.

  

• ATM zu Frame Relay Direction - In Richtung ATM zu Frame Relay ist das Gegenteil der Fall. Die Bandbreitennutzung wird reduziert, wenn vom Geldautomaten zum Frame als Zellsteuer, AAL-Overhead und Padding entfernt wird. Da die potenzielle Übertragungsrate auf der ATM-Seite jedoch viel höher ist als die der Frame-Relay-Verbindung, ist die richtige Einrichtung des Traffic-Shaping auf dem ATM-Router für die Integrität der Sprachkommunikation entscheidend. Wenn das Shaping zu locker ist, speist der ATM-Router Daten schneller als die physische Geschwindigkeit der Frame Relay-Verbindung am anderen Ende ein. Als Ergebnis starten Pakete die Warteschlange auf dem FRF.8-Switch. An einem bestimmten Punkt beginnen die Pakete zu fallen. Da die ATM/Frame Relay-Netzwerke nicht zwischen Sprache und Daten unterscheiden, werden auch VoIP-Pakete verworfen.

  Wenn das Shaping zu restriktiv ist, leidet der Durchsatz gleichzeitig. Aufgrund der ATM-Zellsteuer werden AAL-Overhead und -Padding vom FRF.8-Gerät entfernt. Auf der Frame-Relay-Verbindung wird keine Bandbreite beansprucht. Daher können Sie die ATM-Seite des PVC etwas überzeichnen. Die Anzahl der Padding- und AAL-Overhead variiert je nach durchschnittlichen Frame-Größen und der Aggressivität der Fragmentierung. Da Sie diese Gemeinkosten nicht genau ermitteln können, sollten Sie besser nicht versuchen, sie zu optimieren. Auf der anderen Seite ist Zellsteuer völlig deterministisch. Sie beträgt 5 Byte pro 48 Byte Nutzlast. Sie können die Zellsteuer optimieren, indem Sie das Shaping-Ziel auf dem ATM-Router auf 53/48 x SCR einstellen. Die Richtlinien auf der Carrier-Seite müssen so festgelegt werden, dass diese leichte Überbelegung möglich ist.

Hinweise und Hinweise

• MLPoATM/Frame Relay wird derzeit nur getestet und mit einer Service-Richtlinie unterstützt, die entweder an die virtuelle Vorlage oder an die Dialer-Schnittstellen angeschlossen ist. Das Auslassen der Dienstrichtlinie kann dazu führen, dass die Funktion nicht funktioniert. Ein Beispiel hierfür ist die Cisco Bug-ID CSCdu19313 (nur registrierte Kunden) .

• MLPoATM/Frame Relay klont zwei virtuelle Zugriffsschnittstellen für jede PVC. Eine davon stellt die PPP-Verbindung dar. Das andere stellt das MLP-Paket dar. Mit dem Befehl show ppp multilink wird ermittelt, welches Gerät verwendet wird. Mehrere PPPoFR-Verbindungen pro Paket werden nicht unterstützt. Wenn zwei PPPOFR-Stromkreise in einem Bündel zusammengefasst werden, wird die Last nicht gleichmäßig auf die Schaltkreise verteilt, da der PPPOFR-Treiber keine Flusssteuerungssignalisierung bereitstellt, wie sie echte serielle Treiber tun. Der MLPPP-Lastenausgleich über ATM oder Frame-Relay weist möglicherweise eine deutlich geringere Effektivität auf als der gleiche Lastenausgleich über die physische Schnittstelle.

• Jede PVC ist mit vier verschiedenen Schnittstellen verknüpft, und zwar der physischen Schnittstelle, der Subschnittstelle und zwei virtuellen Zugriffsschnittstellen. Nur die virtuelle MLP-Zugriffsschnittstelle hat Fancy Queuing aktiviert. Die anderen drei Schnittstellen müssen zuerst in der FIFO-Warteschlange (First In, First Out) stehen.

• Wenn Sie einen Service-Policy-Befehl auf eine virtuelle Vorlage anwenden, zeigt Cisco IOS diese normale Warnmeldung an:

  cr7200(config)#interface virtual-template 1
  cr7200(config-if)#service-policy output Gromit
  Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
  Note CBWFQ supported on MLP bundle interface only.
  

  Diese Nachrichten sind normal. Die erste Meldung weist darauf hin, dass eine Service-Richtlinie auf der PPP-Schnittstelle für den virtuellen Zugriff nicht unterstützt wird. Die zweite Nachricht bestätigt, dass die Service-Richtlinie auf die virtuelle MLP-Zugriffsschnittstelle des MLP-Pakets angewendet wurde. Diese Tatsache wird mithilfe der Befehle show interfaces virtual-access , show queue und show policy-map interface befehle zur Überprüfung des Warteschlangenmechanismus verifiziert.

• PPP-Authentifizierung ist nicht zwingend erforderlich, da eine PVC wie eine Mietleitung aussieht. Die PPP-Authentifizierung ist jedoch praktisch, da der Befehl show ppp multilink zum Ermitteln des Routernamens am anderen Ende der PVC verwendet wird.

• Frame Relay Traffic Shaping muss für MLPoFR-PVCs auf dem Frame Relay-Router aktiviert sein.

• Cisco IOS Software Release 12.2 unterstützte ursprünglich maximal 25 virtuelle Vorlagen pro Router. Diese Einschränkung kann sich auf die Skalierung eines ATM-Distribution-Routers auswirken, wenn jede PVC eine eindeutige IP-Adresse haben muss. Die Problemumgehung für betroffene Versionen ist die Verwendung von nicht nummerierten IP-Adressen oder die Verwendung von Dialer-Schnittstellen anstelle von virtuellen Vorlagen. In Cisco IOS Software Release 12.2(8)T wird die Unterstützung auf 200 virtuelle Vorlagen erhöht.

• Einige Service Provider unterstützen die PPP-Übersetzung auf ihren FRF.8-Geräten noch nicht. Wenn diese Einschränkung besteht, müssen die Anbieter ihre PVCs für den transparenten Modus konfigurieren.

• Die meisten Beispiele in der Cisco IOS-Dokumentation zeigen Konfigurationen mit Frame-Relay oder ATM-Subschnittstelle. Diese Subschnittstelle ist zwecklos. Die virtuelle Vorlage sollte nur an die physische Schnittstelle angeschlossen werden. Das Ergebnis ist eine kompakte und verwaltbare Konfiguration. Dies ist besonders wichtig, wenn es eine große Anzahl von PVCs gibt.

• Verwenden Sie den Befehl show ppp multilink als trübe Methode, um festzustellen, ob Zellen-/Frame-Verwerfungen auf der Trägerseite auftreten. Der einzige akzeptable Fragmentverlust ist ein Verlust, der durch CRC-Fehler (zyklische Redundanzprüfung) verursacht wird.

• Obwohl MLPoATM/Frame Relay in der Cisco IOS Software-Version 12.1(5)T eingeführt wurde, ist es aufgrund von Bugs in dieser und späteren Versionen ratsam, die Cisco IOS-Softwareversion mit Vorsicht zu verwenden. Cisco empfiehlt, die neueste Wartungsversion des Cisco IOS 12.2 Mainstream zu verwenden. Andere VoIP-Funktionsanforderungen können jedoch die Verwendung einer anderen Cisco IOS-Softwareversion vorschreiben, z. B. 12.2(2)XT, wenn Survivable Remote Site Telefony (SRST) erforderlich ist. In dieser Tabelle sind einige der bekannten Probleme aufgeführt. Wenn Sie Cisco IOS auswählen, sollte jede Cisco Bug-ID anhand des ausgewählten IOS bewertet werden.

Anwenderbericht

Einleitung

In diesem Abschnitt wird eine der ersten Kundenbereitstellungen der MLPoATM/Frame Relay-Funktion beschrieben. Der Kunde wird mit dem fiktiven Namen XYZ Ltd. bezeichnet. Im Jahr 2001 ersetzte XYZ Ltd seine PBX-Systeme durch eine IP-Telefonielösung. Im Rahmen dieses Projekts wurde ein neues IP-Netzwerk erstellt. und Frame Relay/ATM-Interworking für das WAN ausgewählt. Der Betreiber des WAN-Service verwendet Newbridge-Switches, um die ATM- und Frame-Relay-Services bereitzustellen.

Netzwerkübersicht

Das Netzwerk XYZ Ltd ist ein Hub-and-Spoke-Netzwerk, das 26 Zweigstellen mit zwei Core-Standorten verbindet. Jeder der Kernstandorte wird von einem an den E3 ATM angeschlossenen Cisco 3660 Router betreut. Achtzehn der sechsundzwanzig Zweigstellen sind mittelgroß. Sie verfügen über Dual-Frame-Relay-PVCs, die über ATM/Frame Relay IW mit den 360-ern an den beiden Kernstandorten verbunden sind. Die verbleibenden acht Zweige sind sehr klein. Sie verbinden sich über eine einzelne Frame Relay-PVC wieder mit der nächstgelegenen mittelgroßen Zweigstelle. Alle Zweigstellen-Router sind Cisco 2620. Ein End-to-End-ATM-PVC verbindet die beiden 3660-Router an den beiden Hub-Standorten. Diese Abbildung zeigt die Topologie.

Diese Tabelle zeigt die Frame-Relay-Zugriffsgeschwindigkeiten und den CIR. Die CIR-Rate liegt zwischen 32 und 256 Kbit/s. Die Tabelle zeigt auch die maximale Anzahl gleichzeitiger VoIP-Anrufe, die von den einzelnen PVCs durchgeführt werden.

Frame-Relay Traffic Shaping wird von den Routern der Außenstelle durchgeführt. Das Bursting über CIR hinaus ist zulässig. Das Cisco IOS Traffic Shaping ist auf die Zugriffsgeschwindigkeit ausgerichtet, wobei Mincir gleich CIR ist. Wenn vom Carrier explizite Überlastungsbenachrichtigungen (BECNs) für den Rückwärtsverkehr empfangen werden, wird der Router zurück an Mincir geworfen. Dieser Ansatz steht im Widerspruch zu den Empfehlungen von Cisco bei der Verwendung von VoIP über Frame Relay. Die Sprachübertragung ist bereits in Schwierigkeiten, als der Router auf Überlastungsbenachrichtigungen reagierte. In diesem Fall ist der Betreiber jedoch der Ansicht, dass sein Netzwerk ausreichend überlastet ist, um keine Frames oder Zellen zu verwerfen, und daher sollten BECNs niemals gesehen werden.

Das ATM Traffic Shaping wird auf die Geschwindigkeit des Frame-Zugriffs am Remote-Ende und die Zellsteuer festgelegt. Wenn die Zugriffsgeschwindigkeit beispielsweise 512 Kbit/s beträgt, wird die SCR auf 512 x 53/48 = 565 Kbit/s festgelegt. Diese Shaping-Rate wird verwendet, um den Durchsatz zu maximieren. Dies ist sicher, da die Zellsteuer am IW-Punkt abgeschafft wird. Die Richtlinien auf der Carrier-Seite werden großzügig konfiguriert, sodass eine leichte Überbelegung möglich ist.

cRTP wird im gesamten WAN verwendet. Was die CPU angeht, so ist der Cisco 3660 Distribution Router am Core-Standort 1 der zentrale Punkt. Durch Hinzufügen der Nummern in der obigen Tabelle wird ermittelt, dass die theoretische Höchstzahl der VoIP-Anrufe, die diesen Router durchlaufen, 102 Anrufe beträgt. Die Leistungszahlen aus diesem Diagramm zeigen an, dass die CPU-Last des Cisco 3660 für 100 cRTP-Sitzungen (die schnell geswitcht sind) ungefähr 50 Prozent beträgt.

Virtuelle Vorlagen werden mit IP-nummerierten WAN-Links verwendet. Pro PVC ist eine virtuelle Vorlage erforderlich, die möglich ist, da die Gesamtzahl der PVCs, die auf jedem Cisco 3660 enden, weniger als fünfundzwanzig beträgt.

Konfigurationen

In diesem Dokument werden folgende Konfigurationen verwendet:

• Core ATM-Router

• Relay-Router für Außenstellen

!--- Note: This section shows the parts of a core Cisco 3660 router !--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note: Do not configure !--- IP addresses directly on any configuration source, !--- such as a virtual template, whenever the possibility !--- exists that this information is cloned to multiple !--- active interfaces. The exception to this rule is the !--- rare case where the intent is to define multiple parallel !--- IP routes and have IP do load balancing between them. !--- If an IP address is present on the configuration source, !--- this IP address is copied to all the cloned interfaces. !--- IP installs a route to each of these interfaces.
 

!--- Note: This section shows the parts of a branch Cisco 2600 router !--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

Zugehörige Informationen

• VoIP over Frame Relay mit Quality of Service (Fragmentierung, Traffic Shaping, LLQ/IP RTP-Priorität)
• VoIP QoS für Frame Relay an ATM Interworking mit LLQ, PPP LFI und cRTP
• Konfigurieren von Link Fragmentation and Interleaving für Frame Relay- und ATM Virtual Circuits
• PPP Over AAL5, RFC 2364, Juli 1998
• PPP in Frame Relay, RFC 1973, Juni 1996
• PPP Multilink Protocol (MP), RFC 1717, Nov. 1994
• Compression IP/UDP/RTP Headers for Low-Speed Serial Links, RFC 2508, Februar 1999
• Frame Relay/ATM PVC Service Interworking Implementation Agreement FRF.8.2
• Frame Relay Fragmentation Implementation Agreement FRF.12
• Unterstützung von Sprachtechnologie
• Produkt-Support für Sprach- und IP-Kommunikation
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support und Dokumentation für Cisco Systeme