Der Text, der unter "http://www.2cool4u.ch/atm_fddi/atm_febe/atm_febe.htm" und "http://home.pages.at/tele/technik_tips/html_seiten/atm.htm" angeboten wird, ist ijeweils eine nicht genehmigte Kopie dieser Arbeit, bei der jegliche Autorennennung fehlt. Indeed, very cool...

(PDF Version))

Claus Schönleber

Fehlerbehandlung und Fehlerkorrektur in ATM

© 1997


Inhalt
Obwohl die Fehlerbehandlung in Breitbandnetzen in der Regel höheren Schichten überlassen wird, kommen in ATM eine Reihe verschiedener Methoden zur Bitsicherung zum Einsatz.

Abstract
Although error detection and correction are implemented above ATM, there are several techniques in ATM to guarantee correct data transmission. 


Inhalt

1. Begriffe

1.1 Netzbegriffe

1.2 ATM-Begriffe

2. Fehler 2.1 Fehlerarten in ATM

2.2 Alternativen zur Rückgewinnung unkorrigierbar empfangener Daten

2.3. Leistungsmerkmale in ATM

2.3.1 physikalische Schicht

2.3.2 ATM Schicht

3. Bitsicherungsmechanismen in den ATM-Schichten 3.1 ATM-Zelle, ATM-Schichtenmodell

3.2 Physikalische Schicht

3.2.1 Physical Medium Dependent Sublayer

3.2.2 Transmission Convergence Sublayer

3.2.2.1 Direkte Zellenübertragung (Cell Based Physical Layer)

3.2.2.2 Zellenanpassung auf vorhandene Übertragungsrahmen (Cell Mapping)

3.3 ATM Schicht 3.3.1 Header Error Control in der ATM-Zelle (HEC) 3.3.1.1 HEC: Synchronisation

3.3.1.2 HEC: Fehlerbehandlung

3.4 ATM-Adaption Layer 3.4.1 AAL1 3.4.1.1 AAL1 Segmentation and Reassembling Sublayer (SAR)

3.4.1.2 AAL1 CS

3.4.2 AAL-2

3.4.3 AAL3/4

3.4.3.1 AAL3/4 SAR

3.4.3.2 AAL3/4 CS

3.4.4 AAL-5

3.4.5 SAAL Anpassungsschicht für Signalisierung

4. Anwendungsschicht 4.1 ATM in lokalen Netzen 4.1.1 Allgemeines

4.1.2 Native Protocol Support

4.1.2.1 RFC 1483

4.1.2.2 RFC 1577

4.1.3 LAN Emulation (LANE)

4.1.4 Cell Relay

4.1.5 Schlußbemerkung zu ATM im LAN

4.2 IP und TCP

4.3 Video, Audio

4.3.1 Forward Error Correction (FEC)

4.3.2 "ohne Korrektur"?

5 Verweise auf externe ATM-Seiten ATM Forum

IP over ATM Working Group

An ATM Tutorial

ATM Standard Documents

ATM Physical Layer Specification

The Cell Relay Mailing List Archive

ATM Software

Charles Retter Homepage (Coding; FEC, Reed Solomon, ...)

Development of ATM

Cellware ATM Page

6 Referenzen 6.1 Standards

6.2 Buchliteratur

6.3 Zeitschriftenartikel

6.4 Netzquellen, Softwarequelle (external URLs)


1 Begriffe

1.1 Netzbegriffe

Unter Übertragunsgnetz wird eineEinrichtung zur Übertragung digitaler Signale mit Hilfe physikalischer Größen verstanden.

Unter Breitbandnetz wird die Klasse von Übertragungsnetzen bezeichnet, deren Übertragungsrate höher als die Primärmultiplexrate (1,544 Mbit/s in USA, 2,048 Mbit/s in Europa [A]) ist. Der Begriff "Breitbandnetz" beschreibt ausschließlich Fernverkehrsnetze (WANs).

Unter B-ISDN (Broadband-ISDN) wird eine international einheitliche Vereinbarung verstanden, welche die zum Aufbau eines Breitbandnetzes notwendigen Dienstleistungsmerkmale definiert. (ATM-Forum: B-ISDN ist die Menge aller Dienste, die durch den Einsatz von ATM möglich werden (Stimme, Video, Daten)).

Unter ATM (Asynchronous Transfer Mode) versteht man den Transportmechanismus, der auf der Basis der Zellenvermittlung den Transport der Nutzdaten übernimmt. Der Begriff asynchron beschreibt, daß das Auftreten von ATM-Zellen, die Nutzdaten eines Endanwenders enthalten, nicht zwingenderweise periodisch erfolgen muß.

1.2 ATM-Begriffe

ATM-Netzelement: Bezeichnung für ATM-Switches, ATM-Crossconnects, ATM-Konzentratoren, etc. im Gegensatz zum ATM-Endgerät.

Virtual Channel (VC) wird die unidirektionale Verbindung zwischen zwei oder mehr ATM-Endgeräten zum sequentiellen Transport von ATM Zellen verstanden.

Virtual Channel Identifier (VCI): 16 Bit Identifikation aus dem ATM-Zellenkopf für eine Teilstrecke eines VC zwischen ATM-Endgerät und Vermittlungsstelle oder zwischen zwei ATM-Vermittlungsstellen.

Virtual Path (VP): Zusammenfassung einer Gruppe von VCs (Kanalbündel) als Transporteinheit zwischen ATM.Endgerät und ATM-Netzelement oder zwischen ATM-Netzelementen.

Virtual Path Identifier (VPI): 8 Bit Identifikation aus dem ATM-Zellenkopf für das zum Transport der ATM-Zelle erforderliche Kanalbündel (VP)

Virtual Channel Link (VCL): Unidirektionaler Transportweg von ATM Zellen zwischen dem Punkt, an dem eine VCI zugewiesen wird und dem Punkt, an dem dieser Wert verändert oder entfernt wird. Ein VPL ist also in diesen Fällen ein durch einen VCI eindeutig bezeichneter Teil eines VC zwischen zwei Switches.

Virtual Path Link (VPL): Unidirektionaler Transportweg von ATM Zellen zwischen dem Punkt, an dem eine VPI zugewiesen wird und dem Punkt, an dem dieser Wert verändert oder entfernt wird. Ein VPL ist ein durch eine bestimmte VPI definiertes Kanalbündel zwischen ATM-Engerät und ATM-Netzelement oder zwischen ATM-Netzelementen.

Virtual Channel Connection (VCC): ATM-Verbindung zwischen zwei ATM-Endgeräten, die sich aus mehreren, hintereinandergeschalteten VCLs zusammensetzt. Aus diesem Grunde kann sich die VPI einer VCC vom Sender bis zum Empfänger mehrmals ändern.

Virtual Path Terminator (VPT): ATM-Netzelement, das die VCs eines VP zur einzelnen Weitervermittlung aus dem Kanalbündel heraustrennt.

Virtual Path Connection (VPC): Eine unidirektionale Hintereinanderschaltung von VPLs zwischen zwei VPTs.

ATM-Crossconnect: Weiche. ATM-Netzelement zur Schaltung der Kanalbündel anhand der VPIs in verschiedene Richtungen.

ATM-Switch: Vermittlungsstelle. ATM-Netzelement, das virtuelle Verbindungen vermittelt. Dabei können sowohl VPI als auch VPI entsprechend der Durchschaltungsinformation verändert werden.

ATM-Connection: Geschaltete physikalische oder virtuelle Kanäle zwischen ATM-Endgeräten.

Header (Verwaltungskopf): Teil einer Dateneinheit (z.B. Zelle), der die Verwaltungs- und Steuerdaten für die zu übertragenden Daten enthält.

Payload (Nutzdaten): Die zu übertragenden Benutzerdaten.

Trailer: Steuerdaten, die an den Nutzdatenbereich angehängt werden.

2. Fehler

2.1 Fehlerarten in ATM

Verfälschungen während einer Datenübertragung können größtenteils durch geeignete Mechanismen erkannt oder korrigiert werden. Es gibt zwei Arten von Verfälschungen:

In welcher Art Fehler auftreten, ist vom verwendeten Medium und den verwendeten Mechanismen abhängig. Zwei Hauptgruppen werden unterschieden: Die für ATM typischen Fehlerarten werden in [74] in zwei Gruppen eingeteilt: Während burst bit errors für Kupferdrahtmedien typisch ist, treten in Glasfaserverbindungen eher random bit errors auf [15]. Allerdings sind auch in Glasfaserleitungen burst errors denkbar. Ein plötzlicher Verlust einer Gruppe von Zellen kann beispielsweise durch defekte Repeater auf der Glasfaserstrecke verursacht werden, wenn auf eine Ersatzleitung umgeschaltet werden muß, was ungefähr alle vier Tage geschieht [115]. Die dazu benötigte Zeit von 20 bis 40 ms erhöhen die Bitfehlerrate beträchtlich. Bei einer Übertragungsrate von 155 Mbit/s werden dadurch durchnittlich ungefähr 10900 Zellen (was einem Nutzdatendatenumfang von ca. 0,5 MByte entspräche) in Mitleidenschaft gezogen. Das entspricht einer Fehlerwahrscheinlichkeit von ca. 8,6 * 10^-8 bei einer angenommenen durchschnittlichen burst-Länge von 30 ms.

Ein Verlust (loss) von ATM-Zellen tritt auf, wenn

  1. ein nicht korrigierbarer Fehler auftritt,
  2. durch Stau (congestion) auf der Übertragungsstrecke Zellen verworfen werden und den Empfänger dadurch nicht erreichen. Wegen der hohen Variabilität der Datenraten der auf ATM benutzten Dienste, sind weder genaue Voraussagen noch allgemeingültige Statistiken möglich. Die in [115] angenommene Verlustrate von 10^-6 erscheint vor dem Hintergrund von modernen Übertragunsgraten im Gbit/s-Bereich nicht mehr als ausreichend. Eine Optimierung zur Vermeidung Zellenverlustes durch Stau wird in [19] beschrieben.
  3. ATM-Zellen falsch geleitet werden (misrouting). Das kann entweder aus einem verfälschten Header resultieren, bei dem der Fehler nicht erkannt wurde oder weil die Zelle absichtlich mit einem falschen Header versehen wurde. Im Fehlerfalle müßte allerdings die fehlerhafte Kombination von VPI/VCI-Feld und passendem HEC-Wert eine gülitige Route ergeben. Werte im Bereich besser als 10^-10 [115] lassen dies jedoch sehr unwahrscheinlich erscheinen.
In den meisten Arbeiten wird der Typ a) aufgrund von random errors bei der typischen Übertragung über Glasfaserstränge als vernachlässigbar klassifiziert. Da die hier auftretenden Verfälschungen mit einer charakteristischen Rate von 10^-9 auftreten [A, 15], sind ATM-Zellenverluste hierdurch sehr unwahrscheinlich. Selbst bei einer Datentransferrate von 622 Mbit/s und einer Wahrscheinlichkeit von 10^-18 kommen theoretisch solche Verfälschungen in sinnvollen Zeiträumen nicht vor. Allerdings könnten Fehler vom Typ burst error Zellenverluste in größerem Umfange verursachen.

Typ b) hingegen ist nicht von physikalischen Bedingungen abhängig, sondern von der im benutzten Netz vorgefundenen Verkehrsdichte und den dafür verwendeten Steuermechanismen. Der mögliche Überlauf in den Eingangspuffern der Netzelemente (z.B. ATM-Switches) oder Protokollimplementationen (z.B. AAL-1 Byteumschichtung) ist eine Ursache von Zellenverlust, die in ATM-Netzen typischerweise in nicht vernachlässigbaren Größenordnungen vorkommt. Diese Art von Zellenverlust (congestion loss) kann in zeitlich begrenzten Ausbrüchen auftreten (bursts) und betrifft in der Regel direkt hintereinanderfolgende Zellen. Um dies zu minimieren, werden außer effektiven Korrekturmechanismen (FEC) an die ATM-Zellen zusätzlich Sequenznummern vergeben.

In [117] zeigen Partridge, Hughes und Stone allerdings, daß die traditionelle Grundannahme für Fehlerraten, Nutzdaten kämen in statistischer Gleichverteilung (random data) vor, falsch ist und aus diesem Grunde die Eigenschaften von Prüfsummen und CRCs in praxi verzerrt werden können. In einem speziellen Falle kamen nur 0,01% der zulässigen Datenwerte in 19% der benötigten Zeit vor. Die aus solchen Eigenschaften resultierenden Extremverteilungen der Prüfsummen und CRCs beeinflussen das Verhalten im Fehlerfalle nicht unerheblich.

Eine weitere Fehlerursache berichten Druschel, Peterson und Daviein [75]. Durch die Zusammenschaltung (striping) von vier 155 MBit/s-Kanälen wird im "Osiris"-Adapter eine effektive Übertragungsrate von 622 Mbit/s erzielt. Durch die unterschiedlichen Verzögerungen, welche die Zellen in den unterschiedlichen Kanälen erfahren, kann es zu einer Unterbrechung der vorgegebenen Reihenfolge der Zellen kommen. Gründe für die einzelnen Verzögerungen können durch unterschiedliche Pfadlängen auf der physikalischen Ebene, durch unterschiedliches Multiplexing und durch unterschiedliche Pufferung an verschiedenen Stellen des Netzes gegeben sein.

2.2 Alternativen zur Rückgewinnung unkorrigierbar empfangener Daten

Zwei Hauptgruppen von Mechanismen dienen zu Rückgewinnung fehlerhafter und nicht korrigierbarer Daten:

Auch bei der Standardisierung von B-ISDN und ATM wurden verschiedene Ansätze diskutiert. Beispielsweise ARQ in [22] und FEC in [20].

Während ein reines ARQ-Protokoll in Netzen, die eine relativ große Verzögerung (delay) erlauben, unproblematisch zu implementieren ist, muß bei der Übertragung von Daten auf verzögerungsempfindlichen Strecken (Raumsonden, Breitbandnetze, etc.) oder bei hohen Übertragunsgraten ARQ versagen. Aus diesem Grunde werden intelligente Redundanzerweiterungsverfahren benutzt, mit deren Hilfe verfälschte oder verlorene Dateneinheiten effizient zurückgewonnen werden können ohne eineWiederholung anzufordern.

2.3 Leistungsmerkmale in ATM

Es werden verschiedene Werte (Leistungsparameter) definiert, um die auftretenden Fehler in meßbaren Werten darstellen zu können

2.3.1 Physikalische Schicht

Corrected Header Ratio (CHR): Verhältnis der empfangenen Zellen mit fehlerhaftem, aber korrigierbarem Header (im Rahmen der durch das Verfahren gegebenen Korrigierbarkeit) und den insgesamt empfangenen Zellen.

Discarded Cell Ratio: Verhältnis der mit fehlerhaftem, aber nicht korrigierbarem Zellenheader bestückten Header, die verworfen wurden und aller empfangenen Zellen.

Loss of Cell Delineation Rate: Anzahl der Zellensynchronisationsverluste innerhalb eines definierten Zeitintervalls, dividiert durch die Zeitintevalldauer.

Mean Loss of Delineation Duration: Anzahl der nicht eingetretenen Referenzereignisse aufgrund von Zellensynchronisationsverlusten innerhalb eines bestimmten Zeitintervalls, dividiert durch die Summe aus dieser Zahl plus Anzahl aller anderen Referenzereignisse (CRE2) während desselben Zeitintervalls.

Demux-Error-Ration: Verhältnis aller korrekt übertragenen Zellen mit ungültigem VPI-Wert zur Anzahl der insgesamt korrekt übertragenen Zellen.

2.3.2 ATM Schicht

cell error ration: Zellenfehlerrate: Verhältnis zwischen Anzahl der fehlerhaft übertragenen Zellen zur Summe aus der Anzahl der erfolgreich übertragenen Zellen plus der Anzahl der fehlerhaft übertragenen Zellen. Fehlerhafte Zellen in Zellenfehlerblöcken werden dabei nicht mitgerechnet.

severely errored cell block ratio: Zellenblockfehlerrate ist das Verhältnis der fehlerhaften Zellenblöcke zur gesamten Blöcklänge innerhalb eines bestimmten Zeitintervalls.

cell loss ratio: Verhältnis der verlorenen Zellen zu den insgesamt übertragenen Zellen innerhalb eines bestimmten Zeitintervalls. Verlorene Zellen innerhalb von Zellenblöcken werden nicht mitgerechnet.

Cell Misinsertion Rate: Anzahl der Falschzellen innerhalb eines bestimmten Zeitintervalls (falsche VPI/VCI Information aufgrund nicht erkannter Headerfehler), dividiert durch diesen Zeitintervall.

3. Bitsicherungsmechanismen in den ATM-Schichten

Die im Folgenden benutzte Einteilung in physikalische Schicht, ATM-Schicht und Anpassungsschicht dient zwar einer sinnvollen Unterteilung der Aufgaben; sie kann jedoch nicht durchgehend eingehalten werden, weil

Zum Beispiel wird die Header Error Control zwar in der ATM-Schicht berechnet und kontrolliert, sie wird aber auch in der physikalischen Schicht zur Zellensynchronisation benutzt.

3.1 ATM-Zelle, ATM-Schichtenmodell

Das Grundelement von ATM ist die Zelle. Eine Zelle besteht aus 53 Oktetts (Bytes), von denen 5 Oktetts den Verwaltungskopf (header) enthalten. Die übrigen 48 Oktetts beinhalten die Nutzdaten.


Abbildung 1:ATM-Zellenformat

 



Abbildung 2: Aufbau des ATM-Zellenkopfes (Header) an der UNI (user-network interface). Die Breite des Kopfes ist 8 Bit. Dabei bedeuten GFC Generic Flow Control, VPI Virtual Path Indetification, VCI Virtuel Channel Identification, PT Payload Type, CLP Cell Loss Priority und HEC Header Error Control. Im Zellenkopf an der NNI (network node interface) fehlt GFC, sodaß für VP ein größerer Adreßraum entsteht.I

 


Abbildung 3: Schichtenmodell für ATM


3.2 Physikalische Schicht

Wegen der unterschiedlichen Anforderungen, die durch das benutzte Übertragungsmedium bedingt sind, ist die physikalische Schicht in zwei Teilschichten eingeteilt:

Ob ein physikalisches Medium geeignet ist, um ATM-Zellen zu übertragen, hängt alleine von der Existenz der zugehörigen TC ab. Über TC liegende Schichten sind unabhängig von Art und Übertragungsrate des benutzten Übertragungsverfahrens.

Die Unterteilung erscheint zunächst überflüssig, zumal TC Eigenschaften aufweist, die man eigentlich in Schicht 2 (Data Link Layer) erwarten würde. Da man für ATM aber unbedingt die Zelle als primitivstes Element (Atom) betrachten wollte, mußte man schon in Schicht 1 entsprechende Vorkehrungen treffen, um dies zu erreichen.

Die in anderen Schichtenmodellen angewandte Datenkapselung findet zwar auch hier statt, jedoch wird hier das Modell der 53-Byte-ATM-Zelle durch alle Schichten hindurchgereicht.

3.2.1 Physical Medium Dependent Sublayer

Die Schicht PMD definiert das Übertragungsmedium (physical medium), die Methode (line coding) und das Zeitverhalten (bit timing) der Signalübertragung, sowie weitere physikalische Eigenschaften (z.B. Normen für Steckverbindungen). Diese Teilschicht entspricht der klassischen Schicht 1 des ISO-OSI-7-Schichten-Modells.

3.2.2 Transmission Convergence Sublayer

Die Schicht TC ist in ihrer Ausführung abhängig von der Schicht PMD (Bitrate). Sie definiert die Mechanismen zu der Zellensynchronisation (cell delineation) und die Entkopplung von Zellrate und Übertragungsrate (cell rate decoupling), z.B. durch Einfügen von leeren Zellen. Desweiteren sind in dieser Schicht die Vorschriften zum Einbetten der ATM-Zellen in die PDH- oder SDH-Übertragungsrahmen definiert. TC übernimmt Aufgaben, die sonst in Schicht 2 (nach ISO-OSI) vermutet werden [A, B].

Die beiden wichtigsten Aufgaben von TC sind

Cell Delineation (Erkennung der Zellgrenzen)

Die ATM Zellen erscheinen hier als Strom von Bits. Es ist also notwendig, einen Mechanismus zur Erkennung der in den Bitketten enthaltenen Struktur einzusetzen. Problematisch ist dabei die Synchronisation des Empfängers mit dem vom Sender erzeugten Bitstrom. Um zu vermeiden, daß Sender und Empfänger nicht "auseinanderlaufen" (i.e. eine ungünstige Bitfolge im Empfänger nicht mehr korrekt erkannt werden kann; z.B. lange Folgen von 0), werden die Nutzdaten der Zelle (payload) durch ein einfaches Verfahren (payload scrambling) in eine statistisch günstigere Bitfolge verschlüsselt. Damit können die Zellgrenzen in der Regel sicher erkannt werden.

Header Error Control (Fehlererkennung des Kopfinhalts)

Mittels einer üblichen CRC-Prüfsumme werden die ersten vier Oktetts des Verwaltungskopfes gegen einfache Fehler abgesichert. Die Prüfsumme schließt als fünftes Oktett den Verwaltungskopf gegenüber dem Nutzdatenfeld ab. TC übernimmt die Berechnung der HEC-Prüfsumme (Senderseite) und wendet sie auf den Verwaltungskopf an (Empfängerseite). Die HEC-Prüfsumme wird außerdem auch für die Zellensynchronisation verwendet.

3.2.2.1 Direkte Zellenübertragung (Cell Based Physical Layer)

Die ATM-Zelle wird direkt Bit für Bit direkt in die physikalischen Signale des Übertragungsmediums umgewandelt und übertragen. Zur Sicherung der Synchronisation wird der Nutzdatenanteil (payload) mit dem Generatorploynom

G (x) = x^31 + x^28 + 1 verschlüsselt. Damit wird ebenfalls verhindert, daß eine Bitfolge des Nutzdatenteils, die einem Verwaltungskopf (4 Oktetts) mit HEC (1 Oktett) gleicht, die Synchronisation stören könnte. Die verwendete Methode heißt "Distributed Sample Scrambling".

3.2.2.2 Zellenanpassung auf vorhandene Übertragungsrahmen (Cell Mapping)

Ähnlich wie bei der direkten Zellenübertragung wird beim Transport in SDH- bzw. PDH-Medien der Nutzdatenteil verschlüsselt. Allerdings kommt hierbei ein anderes Verfahren zum Einsatz, SSS (self synchronizing scrambling [2], synchronized sample scrambling [A]).

Das verwendete Generatorpolynom ist

G (x) = x^43 + 1

3.3 ATM Schicht

Die ATM-Schicht ist die Grenzschicht zur physikalischen Schicht. Die ATM-Schicht liefert ATM-Zellen, die von der darunterliegenden Schicht in entsprechende Rahmen integriert werden. Bei der Übergabe in die Adaptionsschicht (AAL) wird die ATM-Zelle von ihrem Kopf befreit und der Zelleninhalt weitergereicht. Gleichzeitig ist die ATM-Schicht auch der obere Abschluß des Leitungsnetzes (Carrier network) und stellt die transparente Ende-zu-Ende-Verbindung der Adaptionsschicht zur Verfügung.


Abbildung 4:Trennung von Anpassungsschicht und ATM-Netz


Die ATM-Schicht sorgt für den Zellentransport und die Vermittlung von ATM-Zellen. Ebenso findet hier die Kopfsicherung statt.

3.3.1 Header Error Control in der ATM-Zelle (HEC)

Die Absicherung des Zellenkopfes geschieht mit einer 8-Bit CRC (Header Error Control, HEC). Über die ersten 4 Oktetts des ATM-Zellenheaders wird die CRC-Prüfsumme errechnet und als fünftes Oktett in den dafür vorgesehenen Ort im ATM-Zellenkopf abgelegt.

Das Generatorpolynom dafür ist

G (x) = x^8 + x^2 + x + 1 Mit diesem Generatorpolynom können mehrere Bitfehler erkannt oder ein Bitfehler korrigiert werden. Die HEC dient nicht nur zur Fehlerbehandlung, es wird auch zur Zellensynchronisation (cell delineation) eingesetzt [S2].

ITU-Empfehlung I.432 legt nahe, daß zum HEC-Wert vor dem Ablegen in das HEC-Feld des ATM-Zellenkopfes noch das Muster "01010101" modulo-2 addiert wird. Dies dient, wie das Mischen der Nutzdaten ("Scrambling"), der Sicherung der Zellensynchronisation, indem lange Ketten von "0" weitestgehend vermieden werden. Der Empfänger hat dann vom Wert des empfangenes HEC-Feldes dieses Muster wieder abzuziehen, bevor der CRC-Rest (syndrome) berechnet wird.

3.3.1.1 HEC: Synchronisation

Das zur Synchronisation verwendete Verfahren wird durch ein Zustandsdiagramm mit drei Zuständen definiert.

Begonnen wird im HUNT-Zustand. Das empfangende Signal wird bitweise nach einem HEC-Muster abgesucht. Dies geschieht durch laufende Berechnung der HEC über einem 40-Bit-Block, wobei die ersten 36 Bit als Kopfinhalt, die "abschließenden" 8 Bit als HEC angenommen werden. Ergibt die HEC eine gültige Prüfsumme über den restlichen 40 Bit, so wird angenommen, daß es sich um einen Zellenkopf handelt. In diesem Falle geht das Verfahren in den zweiten, den PRESYNC-Zustand über. Nunmehr werden die folgenden DELTA Zellen (für ein empfohlenes DELTA=6) untersucht. Ergeben die Prüfsummen ebenfalls gültige Kopfinhalte, so wird Synchronizität zum Zellenstrom angenommen.. Es erfolgt dann der Übergang in den SYNC-Zustand. Wurden n < DELTA Zellen auf diese Weise gefunden, erfolgt der Übergang in den HUNT-Zustand. Der SYNC-Zustand bleibt solange erhalten, bis ALPHA aufeinanderfolgende (für empfohlene ALPHA = 7) HEC-Prüfsummen fehlerhafte Zellenköpfe anzeigen. Es wird dann vom Verlust der Synchronizität ausgegangen und es erfolgt der Übergang in den HUNT-Zustand.

Da der HUNT-Zustand von einer unstrukturierten Bitkette ausgehen muß, wird die Zuverlässigkeit des Verfahrens dadurch erhöht, daß die Bitfolgen, die dem Nutzdatenfeld (payload) zugeordnet werden, auf der Senderseite "gemischt" werden (scrambling), so daß ungünstigen Bitfolgen (z.B. längere Ketten von 0-Bits) vermieden werden. Das Mischen geschieht XOR-ing im Schieberegister mit einer definierten Bitfolge (Generatorpolynom). Als Generatorpolynom kommt

G (x) = x^43 + 1 zum Einsatz (Self Synchronizing Scrambler). Die einzige Ausnahme hiervon ist die direkte Zellenübertragung. Als Ersatz wird das Distributed Sample Scrambling mit dem Generatorpolynom G (x) = x^31+x^28+1 eingesetzt.

Da im HUNT-Zustand nach dem Kopf gesucht wird, bleibt das Entmischen (descrambling) des Nutzdatenfeldes hier ausgeschaltet. Erst im PRESYNC- und SYNC-Zustand wird das Entmischen zugeschaltet und dann jeweils bei Empfang des nächsten Kopfes wieder zeitweise deaktiviert.

Das Mischen hat noch zusätzliche Effekte. Zunächst wird so mit großer Wahrscheinlichkeit vermieden, daß ein Nutzdatenfeld einer ATM-Zelle zufällig die für einen sie transportierenden Rahmen (frame) gültige Headerbitfolge enthält und so die die ATM-Zelle transportierende physikalische Schicht ihre Synchronisierung verliert. Desweiteren ist ein aktiver Angriff eines Benutzers auf die Netzsicherheit so unwahrscheinlicher. Zwar kann ein solcher Benutzer z.B. die Scramblingfunktion in SONET leicht nachbilden und so eventuell frames fälschen; da aber in einer darüberliegenden Schicht ebenfalls Mischen auf den eigentlichen Zelleninhalt der ATM-Zelle angewandt wird, müßte ein solcher Benutzer ein Bitmuster finden, das gleichzeitig SONET und ATM-Mischen nachzubilden in der Lage ist. Der dazu nötige Aufwand ist erheblich größer.


Abbildung 5: HEC Synchronisation (Zustandsdiagramm nach ITU I.432)


3.3.1.2 HEC: Fehlerbehandlung

Die sendende Seite errechnet den Wert für das HEC-Feld. Der Empfänger besitzt zur Auswertung zwei verschiedene Zustände:

Anfangs ist der Empfänger im Korrekturmodus. Jeder empfangene Zellenkopf wird untersucht und wenn ein Fehler erkannt wird, tritt einer von zwei möglichen Zuständen auf.

Ist der Empfänger im Korrekturmodus, können einfache Bitfehler korrigiert werden oder im Falle mehrfacher Fehler die Zelle verworfen werden und der Empfänger wechselt in den Zustand "Erkennen". Wird danach kein Fehler erkannt, erfolgt wieder der Wechsel in den Zustand "Korrigieren", andernfalls wird die Zelle verworfen.

Eine ältere Arbeit von 1994, [115], schlägt ein Modell mit vier Zuständen vor, um die Leistung bei der Fehlerbehandlung zu verbessern. Vor allem aufgrund von Bitfehlern auftretendes misrouting kann so noch besser verhindert werden. Desweiteren wird die Unfähigkeit kritisiert, mit Hilfe einer Segment-CRC den Verlust einer Zelle, eine fehlgeleitete Zelle oder vermengte Rahmen bemerken zu können. Es wird deswegen für AAL3/4 eine Rahmen-CRC vorgeschlagen.

3.4 ATM-Adaption Layer

In der Anpassungsschicht (AAL) wird die Abbildung der Datenstrukturen höherer Schichten in die ATM-Zelle durchgeführt. Ebenso ist hier die dafür notwendige Steuerung und das Management untergebracht.


Zur Definition der Anforderungen der verschiedenen transportierten Dienste an die AAL werden Klassen eingeführt. Es werden vier Klassen mit Rahmenbedingungen unterschieden, deren technische Ausführung in den jeweiligen Varianten der AAL festgelegt wird.
Abbildung 6: Serviceklassen und Zuordnung der AAL-Varianten


Generell unterteilt sich eine AAL-Schicht in zwei Teilschichten:

Während in der SAR ausschließlich das Segmentieren der Daten höherer Schichten zur Weiterleitung an die ATM-Schicht durchgeführt wird, hat die CS vielfältigere Aufgaben zu erfüllen, wie beispielsweise Fehlerbehandlung (verlorene oder falsche ingefügte Zellen), Resynchronisation mit der Sendefrequenz, Prüfen auf Bitfehler des AAL-Informationsfeldes, etc. Die verschiedenen Varianten der AAL werden als AAL-1, AAL-2, AAL-3/4 und AAL-5 bezeichnet. Mit AAL-0 wird die Abwesenheit jeglicher AAL-Funktionalität bezeichnet.

3.4.1 AAL1

Beispielsweise werden darunter alle Schnittstellen der PDH, die über B-ISDN übertragen werden, zusammengefaßt. AAL-1 bietet Merkmale für Anwendungen mit konstanten Bitraten oder mit zu übertragender Taktinformation. Auch strukturierte Daten (z.B. auf Abtastperioden basierende) können hiermit übertragen werden.

3.4.1.1 AAL1 Segmentation and Reassembling Sublayer (SAR)

Die SAR empfängt von der darüberliegenden CS 47 Bytes lange Datenblöcke und ergänzt diese mit einem SAR-Header. Die nun enstandene 48 Bytes lange Struktur wird SAR-PDU genannt. Analog wird die von der ATM-Schicht empfangene PDU (die von ihrem Header befreite ATM-Zelle, ATM-Payload) von ihrem SAR-Header getrennt und als 47-Bytes-Datenblock an die CS weitergereicht.


Abbildung 7: AAL-1 SAR-PDU


Der 8 Bit lange AAL1-SAR-Header besteht aus 2 Teilen:

Sequenznummer (4 Bits)

Das SN-Feld unterteilt sich wiederum in zwei Teile, nämlich in das CSI (Konvergenzidentifikationsfeld, 1 Bit) und das SC (Sequenzzahlfeld, 3 Bits).


Abbildung 8:Sequenznummernfeld


Das CSI dient verschiedenen Aufgaben aus der AAL1-CS, beispielsweise zur Übertragung der Taktinformation oder bei der Übertragung der Datenstrukturinformation als Indikatorflag [A, B].

Sequenznummernprüfsumme CRC-3 (4 Bit)

Um das Sequenznummernfeld abzusichern, wird eine CRC-3 Prüsumme verwendet, das Generatorpolynom ist hierbei

G(x) = x^3 + x + 1 Über die sieben Bits, die das Sequenznummernfeld und die CRC-3 Prüfsumme bilden, wird abschliessend ein Paritätsbit berechnet und in das vierte Bit der Sequenznummenprüsumme abgelegt.

3.4.1.2 AAL1 CS

Übertragung von Leitungsschnittstellen (PDH, SDH):

Zellen mit falscher Sequenznummer werden verworfen. Bei Überlauf des Empfangspuffers werden die zur Segmentierung auflaufende Zellen verworfen. Als Ersatz fuer verworfene Zellen werden zur Erhaltung der Bitratenintegrität Füllzellen mit einer Payload aus lauter Einsen generiert.

Übertragung von Videosignalen:

Bei Zellenverlusten und Bitfehlern kommt ein Korrekturmodus zum Einsatz. Dies garantiert, daß eine von höheren Schichten definierte Grenze für Zellenverlustrate und Bitfehlerrate in der ATM-Schicht überschritten wird. Die benutzten Verfahren gehören zur Gruppe der Forward Error Correction Codes (FEC). Es wird eine Kombination von FEC und Byteumschichtung benutzt.

Das FEC-Polynom ist

G(x) = (x - a ^120) * (x - a ^121) * (x - a ^122) * (x - a ^123)

mit a = x^8 + x^7 + x^2 + x + 1

Dieses Verfahren ermöglicht die Korrektur von zwei fehlerhaften Bytes oder vier verlorenen Bytes aus einem 128-Byteblock.. Aus 124 Datenbytes werden 4 Reed-Solomon-Code-Bytes berechnet. Daraus wird eine 128 Spalten Matrixstruktur generiert, die 47 Zeilen besitzt. Hiernach erfolgt eine Umschichtung. Dabei werden die 47 128-Byte-Zeilen eingelesen und im nächsten Schritt die 47-Bit-Spalten ausgelesen. Eine solche Matrix hat also 128 * 47 = 6016 Bytes.Dies entspricht 128 SAR-PDUs oder einer CS-PDU. Der Beginn einer CS-PDU wird im CSI-Bit (Wert eins) der SAR-PDU mit dem ersten Informationsfeld angezeigt.


Abbildung 9: Byteumschichtung (byte interleave)


Innerhalb einer CS-PDU koennen

Der durch den FEC-Code erzeugte Overhead vergrößert den ursprünglich zu übertragenden Datenumfang bei 124-Byte-Blocks um 4 Bytes, also um 3,23 %.

Durch das Verfahren ergibt sich eine Zellenverzögerung von 128 Zellen, das jeweils auf das Füllen einer CS-PDU gewartet werden muß

Übertragung von Sprachsignalen:

Für Zellenverluste und Bitfehler ist noch keine Regelung getroffen.

3.4.2 AAL-2

AAL-2 bietet Datenströme mit variabler Bitrate mit zeitlicher Koordination zwischen Sender und Empfänger (Taktinformation). AAL-2 ist noch nicht komplett spezifiziert. Es existieren nur Vorstellungen von Grundfunktionen. Laut aktueller Information des ATM-Forums findet hier noch Entwicklungstätigkeit statt. Es handelt sich hierbei um die wichtig Gruppe der Dienste mit stark schwankendem Verkehrsaufkommen (bursty traffic), wie z.B. packet voice, packet video, etc. Unter anderem sollen hier Handhabung von verlorenen oder falsch eingefügten Zellen, Überprüfung und Handhabung des AAL-Protokoll-Headers (Protocol-Control-Information, PCI) auf Bitfehler, Überprüfung des AAL-Informationsfeldes auf Bitfehler und mögliche Korrektur. AAL2 ist nicht Hauptfokus der Implementationsbemühungen. In AAL2 ist zur Absicherung eine 10 Bit CRC vorgesehen.

3.4.3 AAL3/4

AAL-3/4 bieten verbindungslosen oder verbindungsorientierten Verkehr mit Paketen. AAL3/4 unterscheidet zwei Betriebsarten (auf die hier nicht näher eingegangen wird):

AAL3/4 unterscheidet in der CS noch weiter Teilschichten:  


Abbildung 10: CS-Schichtenunterteilung AAL-3/4. SSCS: Service Specific Convergence Sublayer, CPCS: Common Part Convergence Sublayer, SAS: Segmentation and Reassembly Sublayer, CS: Convergence Sublayer.


Eine vereinfachte Zusammenfassung der Abläufe innerhalb von AAL-3/4 soll die Zusammenhänge erläutern:

Oberhalb von AAL-3/4 können Datenpakete variabler Länge im Bereich 1..65535 Bytes auftreten. Diese werden zunächst auf ganzzahlige Vielfache von 32 ergänzt (padding). Desweiteren kommen ein Header und ein Trailer hinzu. Die resultierende Struktur wird CS-PDU genannt.

Diese CS-PDU wird danach in Segmente zu je 44 Bytes aufgeteilt, wiederum jeweils mit einem Header und einem Trailer versehen und dann als 48 Bytes lange SAR-PDU an die ATM-Schicht weitergeleitet.

3.4.3.1 AAL3/4 SAR


Abbildung 11: Zusammenhang zwischen ATM-Zelle und PDUs aus den Teilschichten CS und SAR.


Von der CS übergebene SAR-SDUs variabler Länge, die in SAR-PDUs verpackt sind, sind weiterzusenden.

Die SAR-PDU enthält wiederum:

Die 10-Bits CRC wird benutzt, um Bitfehler innerhalb des PDU Rahmens zu erkennen. Die Prüfsumme wird über den SAR-PDU Header, das Informationsfeld und das Längenfeld gebildet. Das verwendete Generatorpolynom ist G(x) = x^10 + x^9 + x^5 + x^4 + x + 1 Um den Abbruch der Übertragung einer SAR-SDU anzuzeigen, ist eine Abbruch-PDU (abort PDU) vorgesehen, die gesendet werden kann. Hierbei handelt es sich um einen SAR-Rahmen, der im MID Feld als EOM gekennzeichnet ist (End of Message) und im Längenfeld den Wert 63 enthält. Das Informationsfeld wird vom Empfänger ignoriert (es kann mit dem Wert 0 belegt werden).

3.4.3.2 AAL3/4 CS

Für Klasse C Protokolle ist keine SSCS Teilschicht noetig. Fuer Klasse D ist sie noetig.

CPCS

Unter anderem stellt CPCS der ihr übergeordneten SSCS (falls implementiert) oder Anwendungsschicht Fehlererkennung und -anzeige (Bitfehler und Zellenverlust) sowie die Einhaltung der Übertragungsreihenfolge zur Verfügung.

SSCS

Ein Beispiel für diese Teilschicht ist SSCOP (B-ISDN Signalisierungskanäle). Weiteres dazu im Kapitel über Anwendungsschichten.

3.4.4 AAL-5

AAL5 ist eine stark vereinfachte Version des AAL3/4. Wie in AAL3/4 wird die CS in zwei Teilschichten unterteilt, SSCS und CPCS, mit analogen Eigenschaften.

Es gibt kein Multiplexen von Zellen, Alle Zellen einer CS-PDU werden sequentiell übertragen. Datenpakete variabler Länge werden auf Vielfache von 48 Bytes aufgefüllt und mit einem Trailer ergänzt. Es existiert kein Header. Die CS-PDU wird dann direkt in Segmente zu 48 Bytes unterteilt, die genau in ein ATM-Zellen-Informationsfeld passen. Um Beginn, Fortsetzung oder Ende des Stroms zu kennzeichnen, wird das ATM.-Zellenfeld PTI missbraucht.

AAL5-SAR

AAL-5 SAR übernimmt:

AAL-5-CS

Dienstmerkmale für übergeordnete Anwendungsschicht bzw. SSCS (falls implementiert):

AAL5-CPCS


Abbildung 12: AAL-5 CPCS-PDU


Die Absicherung gegen Fehler wird von einer 32-Bit CRC übernommen, die die gesamte CPCS-PDU schützt. Also Informationsfeld, Füllbitfeld und die ersten vier Bytes des CPCS-Trailers. Das Generatorpolynom ist

G (x) = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1 AAL5-SSCS

Wie AAL3/4, siehe Anwendungsschicht.

3.4.5 SAAL Anpassungsschicht für Signalisierung

Die Signalisierung in B-ISDN wird - wie in Schmalband ISDN - über von den Nutzverbindungen getrennten Kanälen abgewickelt. SAAL, ITU Q.2100, ist die Anpassungsschicht hierfür. SAAL bietet der über ihr liegenden Signalisierungsschicht Q.2931 (die keine Fehlerkompensation kennt) einen zuverlässigen Übertragungsdienst.

SAAL wird ebenfalls in mehrere Teilschichten unterteilt.

Die CPCS Teilschichten von AAL-3/4 und AAL-5 führen "nicht garantierte Übertragung durch, deswegen muß SSCOP Prozeduren bereitstellen, die eine garantierte Übertragung der SSCOP-Informationsfelder sichern. Außerdem muß selbstverständlich die Übertragung der Signalisierungsdaten (z.B. Aufbau und Beenden einer Verbindung) extrem zuverlässig ablaufen, da andernfalls der reibungsfreie Betrieb des Netzes nicht gewährleistet werden kann. Da in B-ISDN, wie schon im Schmalband-ISDN, eine out-band-Signalisierung durchgeführt wird, die unabhängig von den Datenpfaden ist, existiert ein vom "Datennetz" separates Signalisierungsnetz. SSCOP benutzt als Sicherungsmechanismus "selective retransmission", also ein ARQ-Protokoll, das hohe Datenübertragungssicherheit sowohl unter schlechten Übertragungsbedingungen als auch unter hohen Übertragungsraten garantiert. Es werden nur die Rahmen wiederholt übertragen, die vom Empfänger explizit angefordert werden; ein "time out" existiert also nicht. SSCOP arbeitet zudem mit "sliding window"-Technik (variables, dynamisch veränderbares Fenster), um möglichst einen Leerlauf der Übertragungsleitung durch Warten auf eine Bestätigung zu verhindern.

Ursprünglich als Bitsicherung einer Ende-zu-Ende-Verbindung für den Bereich der Nutzdatenübertragung gedacht [9], hat sich die Anwendung von SSCOP zur Sicherung der Signalisierung etabliert, nachdem in der Vergangenheit die Verlagerung der ATM-Anwendungen vom Backbone hin zur Implementation von IP-Subnetzen erfolgte, für dessen verbindungslosen IP-Dienst SSCOP nicht geeignet ist.

SSCOP stellt der darüberliegenden Anwendungsschicht, "Service Specific Coordination Function" genannt, eine Reihe von Funktionen zur Verfügung: Unter anderem sind dies:

Mechanismus zur Fehlerbehebung im SSCOP Protokoll:

Nachdem einige PDUs in der korrekten Folge empfangen wurden, kann der Empfänger verlorene PDUs nicht bemerken, da noch nichts weiter empfangen wurde (kein time-out). Der Sender fordert nun mit einer Poll-PDU die Bestätigung der letzten Rahmen an. Die Steuerung eines solchen "Polls" kann durch Timer oder durch Erreichen eines vorher definierten Wertes erfolgen. Der Empfänger bestätigt die empfangenen Rahmen durch eine STAT-PDU die empfangenen Rahmen und teilt dem Sender weiterhin mit, welche Rahmen noch fehlen. Daraufhin verschickt der Sender zunächst den seit der Unterbrechung noch nicht verschickten Rahmen, woraufhin der Empfänger durch eine unaufgeforderte Statusmeldung (USTAT-PDU) dem Sender den Bereich der durch die Unterbrechung im sliding window verlorengegangenen PDUs mit. Danach kann der reguläre Betrieb wieder aufgenommen werden.

Die Art der Signalisierung ist nicht Bestandteil dieser Arbeit und kann beispielsweise in [A] oder [9] nachvollzogen werden.

4. Anwendungsschicht

Bei den in der Anwendungsschicht benutzten Protokollen aus der MAC-/Transportschicht oder aus höheren Schichten handelt es sich in praxi hauptsächlich um bewährte Standards (z.B. Ethernet) sowie TCP/IP, Novell, Apple-Talk, etc. Soweit für die thematische Bearbeitung wichtig, werden die benutzten Verfahren kurz beschrieben.

In der Regel tauchen in diesem Bereich weniger Probleme mit den bekannten Fehlermechanismen auf, sondern in der Kombination der herkömmlichen Protokolle mit speziellen ATM-Eigenschaften (z.B. ist ATM verbindungsorientiert) oder mit den bei ATM auftretenden hohen Übertragungsraten oder Bandbreiten.

4.1 ATM in lokalen Netzen

4.1.1 Allgemeines

Bei der Integration von ATM in bestehende lokale Netze (LANs) muß vor allem das Haupproblem beider Architekturen, die Art der Datenzustellung, gelöst werden. Üblicherweise nutzen die Netzelemente eines herkömmlichen LANs (legacy LAN, z.B. unter IEEE 802, FDDI, etc.) ein gemeinsames Übertragungsmedium, gesteuert durch entsprechende Kanalzugriffsmechanismen. Die für alle Netzelemente lesbaren Datenpakete (broadcast-Prinzip) werden vom Empfänger selektiert und verarbeitet. Die Basis für ATM sind Verbindungen und durch spezielle Netzelemente (switches) geschaltete Übertragungskanäle. Während also in herkömmlichen LANs Datenpakete jederzeit ohne Ankündigung verschickt werden können, benötigt ATM eine Verbindungsaufbauphase und eine Phase zum Abbau der Verbindung. Damit clients nicht die netzbelastende Broadcastfähigkeiten von ATM mißbrauchen, wird ihnen nur eine beschränkte Anzahl von broadcast frames gestattet [6].

Weiterhin spiegeln ATM-Adressen die Netzhierarchie wieder (z.B. Addressierungsschema E.164), herkömmliche LAN-Adressen dagegen nicht.

Solange Datenpakete von einem Netzknoten A zu einem Netzknoten B gesendet werden sollen, ist die notwendige Abbildungen LAN-ATM relativ einfach. Problematisch ist die in herkömmlichen LAN-Protokollen häufigen Multicast oder Broadcast-Funktionen. Deren Emulation oder Nachbildung steht im Gegensatz zur ATM-Philosophie.

Deswegen werden in ATM-Netzen werden zwei Ansätze betrachtet.

Daneben gibt es Methoden, ISO-OSI-Schicht-3-Protokolle direkt auf ATM-Zellen ohne Umweg über die Schicht 2 und AAL aufzusetzen (cell relay) [35].

In der Regel dienen lokale ATM-Lösungen als Backbone für verschiedene LANs; allerdings ist der geplante "Gigabit-Ethernet"-Standard ein technischer (und vielleicht auch wirtschaftlicher) Konkurrent für ATM, zumal in diesem Falle die "Verwandschaft" enger ist.

4.1.2 Native Protocol Support

Neben den IETF-Bemühungen unterhält das ATM-Forum eine Arbeitsgruppe "Multiprotocol over ATM" (MPOA).

Größtenteils sind die Arbeiten an notwendigen Standards noch nicht abgeschlossen; allerdings gibt es nur für verbreitete Protokolle, allen voran IP, entsprechend fortgeschrittene Bemühungen.

4.1.2.1 RFC 1483

LAN-Protokolle werden durch Einkapselung (encapsulation) der LLC-Pakete in AAL-5 PDUs. Der gesamte Datenstrom erfolgt über einen einzigen VC. Mit dieser Methode können alle Protokolle über ATM transportiert werden, die auf Token Ring, Ethernet, FDDI oder anderen basieren.

4.1.2.2 RFC 1577

Dieser Standard bietet eine vollständige IP-Implementation für die Anwendung in ATM. Die Abbildung der IP-Adressen auf die MAC-Adressen erfolgt über ATMARP (entspricht ARP) bzw. InATMARP (entspricht RARP), die zugehörigen Tabellen werden auf einem ATMARP-Server verwaltet, der in jedem logischen IP-Netz (LIS) vorhanden sein muß.

4.1.3 LAN Emulation (LANE)

Das ATM-Forum definiert LAN-Emulation (LANE) als einen auf AAL-5 aufsetzenden Dienst mit vier Modulen (z.B. [A]):

Zur Steuerung einer LANE werden die ATM-Verbindungsarten Control-VCC (Koppelung von LECs mit LESs und LESCs, ) und Data-VCC (Datenverkehr zwischen BUS und LECs sowie zwischen LECs untereinander) unterschieden. Die hauptsächliche Sicherung der Nutzdaten zwischen den beiden Endpunkten einer LANE-Verbindung findet in den üblichen LAN-Transportschichten statt (z.B. TCP).

Das Modell des BUS stellt sowohl Flaschenhals als auch Fehlerquelle dar. Die Abbildung der Broadcast/Multicastadressen auf einzelne ATM-Adressen und die daraufhin etablierte Menge an Einzelverbindungen verursachen eine erhebliche Belastung des Netzes. Zudem müssen an die Zuverlässigkeit des BUS hohe Ansprüche gestellt werden, denn der Verlust des BUS durch Ausfall beeinträchtigt das gesamte davon abhängige "LAN" in signifikanter Weise (single point of failure [6]). Zusätzliche Redundanz wäre hier eventuell eine Lösungsmöglichkeit. Da der BUS Multicast-Rahmen auf jeden Fall wieder zunächst zusammensetzen und in Reihenfolge bringen muß, ensteht an dieser Stelle ein bei herkömmlichen LANs unbekannter zusätzlicher Auf- und Abstieg in der Protokollhierarchie. Schließlich ist eine Umkonfiguration des Netzes (z.B. Austausch einer Workstation) umständlicher und weniger problemlos als in traditionellen LANs.

4.1.4 Cell Relay

Mit "cell relay" werden Übertragungsdienste bezeichnet, die direkt für ATM-basierende Netzinfrastrukturen entwickelt wurden. Eine explizite Anpassung für Datenstrukturen oder Adressen ist deswegen nicht erforderlich. Diesem Standard werden Chancen für den Einsatz in lokalen Hochleistungsnetzen eingeräumt, beispielsweise im Multimediabereich.

Für cell relay Netze gelten alle Überlegungen zu ATM.

4.1.5 Schlußbemerkung zu ATM im LAN

Es ist fraglich, ob in LANs die charakteristischen Eigenschaften von ATM, Verbindungen statt Paketvermittlung und der erheblich größere Overhead an Protokollen, eine lokale Anwendung dieser Netztechnik wünschenswert ist. In den meisten LANs bestehen keine Forderungen an gesicherte Dienstmerkmale (quality of services) oder Bandbreite; vielmehr ist eine gesicherte und relativ schnelle Datenübertragung, wobei jedoch in der Regel leichte Geschwindigkeitseinbußen ohne Probleme verkraftet werden. Hier könnte der zu erwartende "Gigabit Ethernet"-Standard in lokalen Netzen mit wenig anspruchsvollem Datenverkehr (z.B. keine garantierte Bandbreite) eventuell die bessere und effektivere Lösung sein.

Für spezielle lokale Anwendungen jedoch könnten lokale ATM-Lösungen wünschenswert sein. Beispielsweise gab Cisco Systems, Inc., auf der CeBIT 97 bekannt, für ein neues, extrem großes Kreuzfahrtschiff der amerikanischen Carnival Cruiselines ein ATM-Backbonenetz zu planen, das für ca. 7500 zahlende Gäste Video-on-demand in die Kabinen liefern soll. Dies kann durchaus als typisches Beispiel für ATM-Anwendung dienen.

4.2 IP und TCP

Ein IP-Paket verursacht einen "burst" von ATM-Zellen bei der Übergabe nach AAL (z.B. AAL-5) durch die Segmentierung. Verkehrsanalysen darüber findet man z.B. in [36].

Da IP keine Bitsicherung vorsieht, ist es für diese Diskussion weniger interessant. RFC1932 informiert über Einzelheiten zum Thema "IP über ATM".

TCP ist das Protokoll der Wahl für gesicherte Datenübertragung in den meisten Netzen. Bei der Verwendung von TCP in ATM treten einige Probleme auf. Benutzt wird TCP über AAL-3/4 oder AAL-5, die für Paketprotokolle definiert sind.

Der einfachste Fall für Probleme von TCP in ATM ist die Situation eines Senders, der Daten mit hoher Übertragungsrate an einen Netzknoten mit niedriger Übertragungsrate verschickt. Solange die Puffergröße nicht ungefähr den Umfang eines 64k-Fensters besitzt, arbeitet TCP nicht sehr effektiv. Durch die dynamische Größenanpassung des benutzten Fensters läuft der betroffene Puffer über, verwirft einige Pakete, was TCP zur wiederholten Aussendung und zur Anpassung der Fenstergröße veranlaßt ([N2]. Damit wird der größte Teil der Zeit mit Wiederholungen ausgefüllt. Ein genügend großer Puffer kann diese Wirkung größtenteils kompensieren.

Weiterhin führt der Verlust einer einzigen ATM-Zelle dazu, daß das gesamte TCP-Segment verworfen wird. In Anbetracht der beteiligten Größenordnungen eine recht uneffektive Ausnutzung der Bandbreite. Es wird deswegen ein frühes Verwerfen des gesamten TCP-Segmentes empfohlen (z.B. early packet discard, [N2]), sonst ergibt sich ein typisches, extremes "Sägezahnverhalten" (Kapazität über Zeit).

Insgesamt erweisen sich die Puffer- und Paketgröße als entscheidende Faktoren bei der Anpassung von TCP auf höhere Geschwindigkeiten. Eine Puffergröße von annähernd 64 kByte ist sehr effektiv; beihöheren Werten muß die Paketgröße ebenfalls größer werden, was aber ein Problem der konstanten Erzeugung solcher Pakete sein kann ([40], [41]).

Als aktuelle Methode, den noch nicht standardisierten Verkehrsfluß von TCP zu steuern, wird "cell level pacing" benutzt. In der Regel wird die erforderliche Übertragungsrate manuell an die Pufferkapazität des benutzten Netzelements angeglichen, um TCP in erträglicher Effizienz transportieren zu können, d.h. um die Wahrscheinlichkeit des Zellenverlustes durch Pufferüberlauf (congestion loss) zu minimieren. Die Methoden sind jedoch proprietäre Lösungen und nicht sehr ausführlich dokumentiert.

Bei älteren TCP-Implementationen, die noch stark auf dem Wert der "retransmit clock" basieren, sollte die Taktgranularität von 300 ms auf 0,1 ms verfeinert werden [41].

In [112] wird auf ein allgemeines Problem von TCP hingewiesen, das auf die Effizienz des bei TCP verwendeten "piggy backing" eingeht (Transport der Empfangsbestätigung über in die Gegenrichtung zu versendende Daten), daß bei Duplexverbindungen (z.B. telnet) effektiver ist als bei solchen mit ungleicher Richtungsauslastung (z.B. ftp) ([112]). Dieser Effekt wird sich bei hohen Geschwindigkeiten eher verstärken.

4.3 Video, Audio

Im Bereich der Video- und Audiodaten werden Forderungen an die Zellverlustrate und die Bitfehlerrate gestellt. In AAL1 wird deswegen FEC benutzt, um trotz der hohen Anforderungen mögliche Übertragungsfehler zu kompensieren.

4.3.1 Forward Error Correction (FEC)

Reed-Solomon-Codes, die Basis für FEC-Verfahren, ist seit den 60er Jahren bekannt [114]. Für die Praxis wichtig wurden sie erst, als es entsprechend leistungsfähige Algorithmen (Berlekamp) und Hardware gab. Sie werden hauptsächlich dann eingesetzt, wenn die verwendeten Medien keine große Verzögerung (z.B. durch im Fehlerfalle wiederholte Sendeung der Daten) erlauben, wie das bei weit entfernten Raumsonden oder dichtgepackten CD-ROMs der Fall ist.

Reed-Solomon-Codes basieren auf der Abbildung eines m-dimensionalen Vektorraums über einem endlichen Körper K in einen n-dimensionalen Verktorraum (n > m) über demselben Körper. Ausgehend von einer Nachricht (a_0, a_1, . . ., a_{m-1}), wobei a_k Element von K ist, wird (P(0), P(g), P(g^2), . . ., P(g^{N-1})) erzeugt. N ist dabei die Ordnung von K, und g ist ein Generator der zyklischen Gruppe der Elemente aus K ungleich 0. P(x) ist das Polynom a_0 + a_1x + . . . + a_{m-1} x^{m-1}. Durch N > m wird das Polynom P(x) dadurch überbestimmt und somit können die Koeffizienten von P durch mindestens m beliebige Werte rückgewonnen werden ([N1], [D]).

Anders ausgedrückt handelt es sich hierbei um eine Art Polynominterpolation, was auch durch die Tatsache gezeigt wird, daß es der Diskreten Fouriertransformation ähnliche Verfahren zur Implementation gibt. Das erklärt die Effizienz dieser Art der Fehlerbehandlung, ohne daß verfälschte Daten neu angefordert werden müßten. Kombiniert mit einem ARQ-Protokoll können weitere, grobe Fehler korrigiert werden. In der Praxis sieht man deswegen entsprechende Kombinationen beider Verfahren eingesetzt.

Es können somit - bei einer Nachrichtenlänge von kleiner als N - 2s maximal s Fehler korrigiert werden. In der Regel benutzt man den endlichen Körper vom Grad 8 über Z_2 oder anderen, den Wortlängen angepaßten Gradzahlen.

Reed-Solomon-Codes werden - als Blockcodes - mit "(n,m)-Code" bezeichnet, wobei z.B. in praxi Werte von m=124 und n=124 vorkommen (Cellware AAL-1-Board, max. 80 MBit/s). In diesem Falle können 2 Fehler (unbekanntes Falschbit an unbekannter Stelle) oder 4 Löschungen (unbekanntes Bit an bekannter Stelle) oder die Kombination aus einem Bitfehler und zwei Löschungen korrigiert werden.

[A] erwähnt, daß bei Vermittlung von ATM-Zellen über sieben Vermittlungen mit jeweils sieben Schaltstufen die Wahrscheinlichkeit von Zellenverlusten mit Blocklängen von mehr als vier Zellen vernachlässigbar gering ist.

4.3.2 "ohne Korrektur"?

Gespräche mit Praktikern aus verschiedenen Firmen lassen erkennen, daß in bestimmten Anwendungen und bei der Benutzung hochwertiger Glasfaserstrecken auf Korrektur verzichtet werden kann (und wird), ohne daß das auf der Empfängerseite die Qualität erkennbar verschlechtert werden würde (bei einer Übertragungsdauer von einigen Stunden). Das würde bedeuten, daß man sich - bewußt oder unbewußt - entweder auf die durch FEC geleistete Rückgewinnung verläßt oder tatsächlich wegen der Qualität der Übertragungsstrecken auf Fehlerkorrekturmechanismen verzichten könnte. Genauere Daten sind aber momentan wegen eines möglichen Verlustes des Know-How-Vorsprungs von Seiten der Industrie nicht zu erfahren.

5. Verweise auf externe ATM-Seiten

(siehe Anfang des Dokuments.)

6. Referenzen

6.1 Standards

[S1] ITU SG XVIII Draft I.113 Jan 1990

[S2] ITU I.432

[S3] ITU I.361

[S4] ITU I.363

[S5] ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1; Upper Saddle River: Prentice Hall, 1995

[S5] IETF RFCs 1323, 1483, 1577, 1680, 1755, 1932

6.2 Buchliteratur

[A] Othmar Kyas: ATM Netzwerke; Bergheim: Datacom Buchverlag GmbH, 1996 (3. Aufl.)

[B] Gerd Siegmund: Technik der Netze; Heidelberg: R. v. Decker&acute;s Verlag, 1996

[C] Andrew S. Tanenbaum: Computer Networks; Englewood Cliffs: Prentice Hall, 1989

[D] Arnold M. Michelson, Allen H. Levesque: Error-Control Techniques For Digital Communication; New York, Chichester, Brisbane, Toronto, Singapore: John Wiley & Sons, 1985

[E] ATM Forum: The ATM Forum Glossary, April 1996

6.3 Zeitschriftenartikel

[1] Ronald J. Vetter, David H. C. Du: Issues and Challanges in ATM Networks; Comm. ACM, Feb 95, Vol.38, No. 2, p.29-38

[2] B. G. Kim, P. Wang: ATM Network: Goals and Challenges; Comm ACM, Feb 95, Vol.38, No. 2, p.40-44

[3] Shivi Fotedar, Mario Gerla, Paola Crocetti, Luigi Fratta: ATM Virtual Private Networks Comm ACM, Feb 95, Vol.38, No. 2, p.102-109

[4] Mostafa H. Ammar, Victor O. K. Li, Mehmet Ulema: Broadband ISDN: Standards, switches, and traffic management; ComNet and ISDN, 27(1994)1-3

[5] Jaime Bae Kim, Tatsuya Suda, Masaaki Yoshimura: International standardization of B-ISDN; ComNet and ISDN, 27(1994)5-27

[6] Nail Kavak: Data Communication in ATM Networks; IEEE Net, May/June 1995, p.28-37

[7] Kai-Yeung Siu, Raj Jain: A Brief Overview of ATM: Protocol Layers, LAN Emulation, and Traffic Management; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.6-20

[8] Sailesh K. Rao, Mehdi Hatamian: The ATM Physical Layer; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.73-81

[9] Thomas R. Henderson: Design Priciples and performance analysis of SSCOP: a new ATM Adaption Layer protocol; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.47-59

[10] Kazuo Imai, Tadashi Ito, Hideki Kasahara, Naotaka Morita: ATMR: Asynchronous transfer mode ring protocol; ComNet and ISDN 26(1994)785-798

[11] Nicholas Yeadon, Francisco Garcia, David Hutchinson, Doug Shepherd: Filters: QoS Support Mechanisms for Multipeer Communications; IEEE Sel, Vol. 14, No. 7, Sep 96, p.1245-1263

[12] Jae-Il Jung: Translations of user&acute;s QoS requirements into ATM performance parameters in B-ISDN; ComNet and ISDN, 28(1996)1753-1767

[13] Gertraud Hoffmann: B-WiN - The ATM-based high-speed network for the DFN community; ComNet and ISDN, 28(1996)1953-1960

[14] Frank Feather, Dan Slewiorek, Roy Maxion: Fault Detection in an Ethernet Network Using Anomaly Signature Matching; ACM SIGCOMM, Vol. 23, No. 4, Oct 93, p.279-288

[15] Ernst W. Biersack: A Simulation of Forward Error Correction in ATM Networks; ACM SIGCOMM, Vol. 22, Jan 92

[16] Zheng Wang, Jon Crowcroft: Analysis of Burstiness and Jitter in Real-Time Communications; ACM SIGCOMM, Vol. 23, No. 4, Oct 93

[17] Jane M. Simmons: A Strategy for Designing Error Detection Schemes for General Data Networks; IEEE Net, July/August 1994, p.41-48

[18] Jean-Chrysotome Bolot: End-to-End Packet Delay and Loss Behavior in the Internet; ACM SIGCOMM, Vol. 23, No. 4, Oct 93, p.289-298

[19] C. J. Hughes: Feedback restricted access queues for contolling cell loss in ATM networks; ComNet and ISDN, 28(1996)345-350

[20] Anthony J. McAuley: Reliable Broadband Communication Using a Burst Erasure Code; ACM SIGCOMM, Vol. 20, No. 4, Sep 90, p.297-306

[21] Josep Solé-Pareta, Jordi Domingo-Pascual: Burstiness characterization of ATM cell streams; ComNet and ISDN, 26(1994)1351-1363

[22] Andre B. Bondi, Wai-Sum Lai: The influence of cell loss patterns and overheads on retransmission choices in broadband ISDN; ComNet and ISDN, 26(1994)585-598

[23] Mohammad Peyravian: An improved selective repeat protocol and ist performance in high-speed environments; ComNet and ISDN, 26(1994)1595-1605

[24] Hyong S. Kim: Design of a fault-tolerant multichannel ATM switch for BISDN; ComNet and ISDN, 27(1994)29-43

[25] Cui-Qing Yang, Alapati V. S. Reddy: A Taxonomy for Congestion Control Algorithms in Packet Switching Networks; IEEE Net, July/August 1995, p.34-45

[26] Narayanan Prithviraj, Carey L. Williamson: A Virtual Loss-Load Congestion Control Strategy for High Speed Networks; ACM SIGCOMM, Vol. 24, No. 5, p.44-63

[27] Hiroyuki Ohsaki, Masayuki Mureta, Hiroshi Suzuki, Chinatsu Ikeda, Hideo Miyahara: Rate-Based Congestion Control for ATM Networks; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.60-72

[28] Kai-Yeung Siu, Hong-Yi Tzeng: Intelligent Congestion Control for ABR Service in ATM Networks; ACM SIGCOMM, Vol. 24, No. 5, Oct 95, p.81-106

[29] Raj Jain: Congestion control and traffic management in ATM networks: Recent advances and a survey; ComNet and ISDN, 28(1996)1723-1738

[30] A.Iwata, N.Mori, C.Ikeda, H.Suzuki, M.Ott: ATM Connection and Traffic Management Schemes for Multimedia Internetworking; Comm ACM, Feb 95, Vol. 38, No. 2, p.73-89

[31] Irfan Khan, Victor O. K. Li: Traffic Control in ATM Networks; ComNet and ISDN, 27(1994)85-100

[32] Wen-Tsuen Chen, Uan-Jiun Liu: A feasible framework of traffic control on an ATM wide-area network; ComNet and ISDN, 27(1994)67-84

[33] Andrew Schmidt, Roy Campbell: Internet Protocol Traffic Analysis with Application for ATM Switch Design; ACM SIGCOMM, Vol. 23, No. 2, Apr 93, p.39-52

[34] Dilip D. Kandlur, Debanjan Saha, M. Willebeek-LeMair: Protocol Architecture for Multimedia Applications over ATM Networks; ACM SIGCOMM, Vol. 25, No. 3, Jul 95, p.33-43

[35] G. J. Armitage: Multicast and Multiprotocol support for ATM based Internets; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.34-46

[36] Grenville J. Armitage, Keith M. Adams: How Inefficient is IP over ATM Anyway?; IEEE Net, January/February 1995, p.18-26

[37] Jeremy Barnes, Dave Ginsburg, Dave Newson, Dave Pratt: IP multicast of real-time MPEG over ATM; ComNet and ISDN, 28(1996)1929-1937

[38] Guru Parulkar, Douglas C. Schmidt, Jonathan S. Turner: a Stragtegy for Integrating IP with ATM; ACM SIGCOMM, Vol. 25, No. 4, Oct 95, p.49-58

[39] Raj K. Singh, Stephen G. Tell, Shaun J. Bharrat: Comparison of Raw and Internet Protocols in a HIPPI/ATM/SONET based Gigabit Network; ACM SIGCOMM, p.18-28

[40] Alexander Schill, Sabine Kühn, Frank Breiter: Internetworking with IP/IPng and RSVP; ComNet and ISDN, 28(1996)1915-1927

[41] Allyn Romanow, Sally Floyd: Dynamics of TCP Traffic over ATM Networks; ACM SIGCOMM Vol. 24, No. 4, Oct 94, p.79-88

[42] Curtis Villamizar, Cheng Song: High Performance TCP in ANSNET; ACM SIGCOMM, Vol. 24, No. 5, Oct 95, p.45-60

[43] Michael Perloff, Kurt Reiss: Improvements to TCP Performance in High-Speed ATM Networks; Comm ACM, February 1995, Vol. 38, No. 2, p.91-100

[44] K. K. Ramakrishnan, Peter Newman: Integration of Rate and Credit Schemes for ATM Flow Control; IEEE Net, March/April 1995, p.49-56

[45] H. T. Kung, Robert Morris: Credit-Based Flow Control for ATM Networks; IEEE Net, March/April 1995, p.40-48

[46] Flavio Bonomi, Kerry W. Fendick: The Rate-Based Flow Control Framework for the Available Bit Rate ATM Service; IEEE Net, March/April 1995, p.25-39

[47] Cüneyt Özveren, Robert Simcoe, George Varghese: Reliable and Efficient Hop-by-Hop Flow Control; ACM SIGCOMM, Vol. 24, No. 4, Oct 94, p.89-100

[49] Jan Vis: A Simple LAN Performance Measure; ACM SIGCOMM, Vol. 24, No. 1, Jan 94, p.7-11

[50] Fabrice Guillemin, Charles Levert, Catherine Rosenber: Cell conformance testing with respect to the peak cell rate in ATM networks; ComNet and ISDN, 27(1995)703-725

[51] Tien-Yu Huang, Jean-Lien C. Wu: Performance analysis of prioritized state-dependent buffer-management schemes in ATM networks; ComNet and ISDN, 27(1994)45-66

[52] Anurag Kumar, Robert G. Cole: Comparative Performance of interleaved and non-interleaved pipelinig in ATM terminal adapters; ComNet and ISDN, 27(1995)521-535

[53] P. Venkat Rangan, Srinvas Ramanathan, Thomas Kaeppner: Performance of intermedia synchronization in distributed and heterogenous multimedia systems; ComNet and ISDN, 27(1995)549-565

[54] Edward Chan, Victor C. S. Lee: On the Performance of Bandwidth Allocation Strategies for Interconnecting ATM and Connectionless Networks; ACM SIGCOMM, p.29-31

[55] Ivy Hsu, Jean Walrand: Admission control for multi-class ATM traffic with overflow constraints; ComNet and ISDN, 28(1996)1739-1751

[56] L. Kurt Reiss, Lazaros F. Merakos: Performance analysis of an adaptive Bandwidth reservation scheme for ATM virtual path traffic; ComNet and ISDN, 28(1996)391-400

[57] Herwig Bruneel, Sabine Wittevrongel: An approximate analytical technique for the performance evaluation of ATM switching elements with burst routing; ComNet and ISDN, 28(1996)325-343

[58] Joao L. Sobrinho, José M. Brázio: Proposal and performance analysis of a multiple-access protocol for high-speed wireless LANs; ComNet and ISDN, 28(1996)283-305

[59] Aled Edwards, Greg Watson, John Lumlex, David Banks, Costas Calamvokis, Chris Dalton: User-space protocols deliver high performance to applications on a low-cost Gb/s LAN; ACM SIGCOMM, Vol. 24, No. 4, Oct 94, p.14-23

[60] Zsehong Tsai, Wen-der Wang, Chien-Hwa Chiou, Jin-Fu Chang, Lung-Sing Liang: Performance Analysis of Two Echo Control Designs in ATM Networks; IEEE/ACM, Vol. 2, No. 1, Feb 94, p.30-39

[61] Nikos G. Aneroussis, Aurel A. Lazar, Dimitrious E. Pendarakis: Taming Xunet III; ACM SIGCOMM, Vol. 25, No. 3, Jul 95, p.44-65

[62] P. Crocetti, L. Fratta, M. Gerla, M. A. Marsiglia: SMDS multicast support in ATM networks; ComNet and ISDN, 27(1994)117-132

[63] Satoru Ohta, Ken-Ichi Sato: Dynamic Bandwidth Control of the Virtual Path in Asynchronous Transfer Mode Network; IEEE Trans, Vol. 40, No. 7, July 1992, p.1239-1247

[64] Tim Kwok: A Vision for Residential Broadband Services: ATM-to-the-Home; IEEE Net, September/October 1995, p.14-28

[65] Aurel A. Lazar, Koon-Seng Lim, Franco Marconcini: Realizing a Foundation for Programmability of ATM Networks with the Binding Architecture; IEEE Sel, Vol. 14, No. 7, Sep 96, p.1214-1227

[66] H. T. Kung, Trevor Blackwell, Alan Chapman: Credit-Based Flow Control for ATM Networks: Credit Update Protocol, Adaptive Credit Allocation, and Statistical Multiplexing; ACM SIGCOMM, Vol. 24, No. 4, Oct 94, p.101-114

[67] Richard Black, Ian Leslie, Derek McAuley: Experiences of building an ATM switch for the Local Area; ACM SIGCOMM, Vol. 24, No. 4, Oct 94, p.158-167

[68] Chiung-Shien Wu, Nen-Fu Huang, Gin-Kou Ma: A Dual Bus Approach for LAN Interworking With ATM Networks; ACM SIGCOMM, Vol. 25, No. 3, Jul 95, p.66-85

[69] R. Sharma, S. Keshav: Signaling and Operating System Support for Native-Mode ATM Application; ACM SIGCOMM, Vol. 24, No. 4, Oct 94, p.149-157

[70] Daniel Stevenson, Nathan Hillary, Greg Byrd: Secure Communications in ATM Networks; Comm ACM, February 1995, Vol. 38, No. 2, p.46-52

[71] James A. Schnepf, David H.C. Du, E. Russell Ritenour, Aaron J. Fahrmann: Medical Education Environment Over ATM Networks; Comm ACM, February 1995, Vol. 38, No. 2, p.55-69

[72] Daniel J. Reininger, Dipankar Raychaudhuri, Joseph Y. Hui: Bandwidth Renegotioation for VBR Video Pver ATM Networks; IEEE Sel, Vol. 14, No. 6, Aug 96, p.1076-1086

[73] Jean M. McManus, Keith W. Ross: Video-on-Demand Over ATM: Constant-Rate Transmission and Transport; IEEE Sel, Vol. 14, No. 6, Aug 96, p.1087-1098

[74] Sudhir Dixit, Paul Skelly: MPEG-2 over ATM for Video Dial Tone Networks: Issues and Strategies; IEEE Net, September/October 1995, p.30-40

[75] Peter Druschel, Larry L. Peterson: Experiences with a High-Speed Network Adaptor: A Software Perspective; ACM SIGCOMM, Vol. 24, No. 4, Oct 94, p.2-13

[76] Robert J. Simcoe, Tong-Bi Pei: Perspectives on ATM Switch Architecture and the Influence of Traffic Pattern Assumptions on Switch Design; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.93-105

[77] Thomas M. Chen, Steve S. Liu: Management and Control Functions in ATM Switching Systems; IEEE Net, July/August 1994, p.27-40

[78] Guiseppe Bianchi, Achille Pattavina: Architecture and performance of non-blocking ATM switches with shared internal queueing; ComNet and ISDN, 28(1996)835-853

[79] Lu Wie, Peter Hansson: Further research on dynamic time slice in ATM switch; ComNet and ISDN, 28(1996)789-798

[80] Joan Garcia-Haro, Andrzej Jajszczyk: ATM Shared-Memory Switching Architectures; IEEE Net, July/August 1994, p.18-26

[81] Nen-Fu Huang, Chiung-Shien Wu, Yi-Jang Wu: Some routing problems on Broadband ISDN; ComNet and ISDN, 27(1994)101-116

[82] Zheng Wang, Jon Crowcroft: Quality-of-Service Routing for Supporting Multimedia Applications; IEEE Sel, Vol. 14, No. 7, Sep 96, p.1228-1234

[83] Ronny Vogel, Ralf Guido Herrtwich, Winfried Kalfa, Hartmut Wittig, Lars C. Wolf: QoS-Based Routing of Multimedia Streams in Computer Networks; IEEE Sel, Vol. 14, No. 7, Sep 96, p.1235-1244

[84] Sandeep Sibal, Antonio DeSimone: Controlling Alternate Routing in General-Mesh Packet Flow Networks; Vol. 24, No. 4, Oct 94, p.168-179

[85] Whay C. Lee: Topology Aggregation for Hierarchical Routing in ATM Networks; ACM SIGCOMM, Vol. 25, No. 2, Apr 95, p.82-92

[86] Amarnath Mukherjee: A proof of quasi-independence of sliding window flow control and go-back-n error recovery under independent packet errors; ComNet and ISDN, 28(1996)873-887

[87] Qinglin Wang, Victor S. Frost: Efficient Estimation of Cell Blocking Probability for ATM Systems; IEEE Trans, Vol. 1, No. 2, Apr 1993, p.230-235

[88] Mohammad Ghanbari, Charles J. Hughes: Packing Coded Video Signals into ATM Cells; IEEE Trans, Vol. 1, No. 5, Oct 1993

[89] Mark W. Garrett: Joint Source/Channel Coding of Statistical Multiplexed Real-Time Services on Packet Networks; IEEE Trans, Vol. 1, No. 1, Feb 1993

[90] George Kesidis: Effective Bandwidths for Multiclass Markov Fluids and Other ATM Sources; IEEE Trans, Vol. 1, No. 4, Aug 1993

[91] Anwar I. Elwalid: Effective Bandwidth of General Markovian Traffic Sources and Admission Control of High Speed Networks; IEEE Trans, Vol. 1, No. 3, Jun 1993

[92] Inder Gopal: Network Transparency: The plaNET Approach; IEEE Trans, Vol. 2, No. 3, Jun 1994

[93] Allen R. Bonde, jr., Sumit Ghosh: A Comparative Study of Fuzzy Versus "Fixed" Tresholds for Robust Queue Management in Cell-Switching Networks; IEEE Trans, Vol. 2, No. 4, Aug 1994

[94] Mohamed Abdelaziz, Ioannis Stavrakakis: Some Optimal Traffic Regulation Schemes for ATM Networks: A Markov Decision Approach; IEEE Trans, Vol. 2, No. 5, Oct. 1994

[95] Catherine Rosenberg, Bruno Lague: A Heuristic Framework for Source Policing in ATM Networks; IEEE Trans, Vol. 2, No. 4, Aug 1994

[96] Duan-Shin Lee, Bhaskar Sengupta: Queueing Analysis of a Treshold Based Priority Scheme for ATM Networks, IEEE Trans, Vol. 1, No. 6, Dec 1993

[97] Paul Skelly, Mischa Schwartz: A Histogram-Based Model for Video Traffic Behaviour in an ATM-Multiplexer; IEEE Trans, Vol. 1, No. 4, Aug 1993, p.446-459

[98] Achille Pattavina, Giocomo Bruzzi: Analysis of Input and Output Queueing for Nonblocking ATM Switches; IEEE Trans, Vol. 1, No. 3, Jun 1993, p.314-328

[99] Debasis Mitra, John A. Morrison: Erlang Capacity and Uniform Approximations for Shared Unbuffered Resources; IEEE Trans, Vol. 2, No. 6, Dec 1994, p.558-570

[100] Israel Cidon, Roch Guérin, Asad Khamisy: On Protective Buffer Policies: On Protective Buffer Policies; IEEE Trans, Vol. 2, No. 3, Jun 1994, p.240-246

[101] Wen De Zhong, Yoshikuni Onozato, Jaidev Kaniyil: A Copy Network with Shared Buffers for Large-Scale Multicast ATM Switching; IEEE Trans, Vol. 1, No. 2, Apr 1993, p.157-165

[102] Leandros Tassiulas, Yao Chung Hung, Shivendra S. Panwar: Optimal Buffer Control During Congestion in an ATM Network Node; IEEE Trans, Vol. 2, No. 4, Aug 1994, p.374-386

[103] Steven H. Low, Pravin P. Varaiya: A New Approach to Service Provisioning in ATM Networks; IEEE Trans, Vol. 1, No. 5, Oct 1993, p.547-312

[104] Daniel S. Omundsen, A. Roger Kaye, Samy A. Mahmoud: A Pipelined, Multiprocessor Architecture for a Connectionless Server for Broadband ISDN; IEEE Trans, Vol. 2, No. 2, Apr 1994, p.181-192

[105] Jae W. Byun, Tony T. Lee: The Design and Analysis of an ATM Multicast Switch with Adaptive Traffic Controller; IEEE Trans, Vol. 2, No. 3, Jun 1994, p.288-298

[106] Jacob Sharony, Thomas E. Stern, Yao Li: The University of Multidimensional Switching Networks; IEEE Trans, Vol. 2, No. 6, Dec 1994, p.602-612

[107] Hyong S. Kim: Design and Performance of Multinet Switch: A Multistage ATM Switch Architecture with Partially Shared Buffers; IEEE Trans, Vol. 2, No. 6, Dec. 1994, p.571-580

[108] Paolo Coppo, Matteo D’Ambrosio, Ricardo Melen: Optimal Cost/Performance Design of ATM Switches; IEEE Trans, Vol. 1, No. 5, Oct 1993

[109] Stefano Giannatti, Achille Pattavina: Performance Analysis of ATM Banyan Networks with Shared Queueing - Part I: Random Offered Traffic; IEEE Trans, Vol. 2, No.4, Aug 1994, p.398-410

[110] Stefano Giannatti, Achille Pattavina: Performance Analysis of ATM Banyan Networks with Shared Queueing - Part II:Correlated/Unbalanced Offered Traffic; IEEE Trans, Vol. 2, No.4, Aug 1994, p.411-424

[111] Burkhard Stiller: A Survey of UNI Signaling Systems and Protocols for ATM Networks; ACM SIGCOMM, Vol. 25, No. 2, Apr 1995, p.21-33

[112] Zheng Wang, Jon Crowcroft, Ian Wakeman: A Simple TCP Extension for High-Speed Paths; ACM SIGCOMM, Vol. 22, Jan 1992, p.48-51

[113] Vern Paxson, Sally Floyd: Wide-Area Traffic: The Failure of Poisson Modeling; ACM SIGCOMM, Vol. 24, No. 4, Oct 1994, p.257-268

[114] Irving S. Reed, Gustave Solomon: Polynomial Codes over Certain Finite Fields; Journal of the Society for Industrial and Applied Mathematics, 1960

[115] Andrea Baiocchi, Nicola Bléfari-Malazzi: An Error-Controlles Approximate Analysis of a Stochastic Fluid Flow Model Applied to an ATM Multiplexer with Hetergogenous On-Off Sources; IEEE/ACM, Vol. 1, No. 6, Dec 1993, p.628-637

[116] Jane M. Simmons, Robert G. Gallager: Design of Error Detection Scheme for Class C Service in ATM; IEEE/ACM, Vol. 2, No. 1, Feb 1994, p.80-88

[117] Craig Partridge, Jim Hughes, Jonathan Stone: Performance of Checksums and CRCs over Real Data; ACM SIGCOMM, Vol. 25, No. 4, Oct 1995, p.68-76

Abkürzungen für die Zeitschriften:

[a] Comm ACM: Communcations of the ACM, Association for Computing Machinery.

[b] CommNet and ISDN: Computer Networks and ISDN Systems, Elsevier Science B.V.

[c] IEEE Net: IEEE Network, IEEE

[d] ACM SIGCOMM: ACM Computer Communication Review

[e] IEEE Sel: IEEE Journal on Selected Areas in Communications, IEEE

[f] IEEE/ACM: IEEE/ACM Transactions on Networking, IEEE

[g] IEEE Trans: IEEE Transactions on Communications

6.4 Netzquellen, Softwarequellen

[N1] Charles T. Retter: An Intuitive Introduction to Reed-Solomon Codes; e.al.; http://homepage.arl.mil/~retter/coding.html

[N2] rtm@eecs.harvard.edu/H. T. Kung, Robert Morris: Detaild Behaviour of TCP over ATM (simpliefied version of the paper in GLOBECOM ‘95)

[N3] Dan Stern, Frank Mazella: Norm Al Dude, Professor N. Erd On the subject of ATM, 1996, SCAN Technologies (WWW)

[N4] Peter Newman: ATM: Myth, Marketing, or Virtual Reality?; Conference on the Internet and Society, Harvard University, Mai 1996; http://www.ipsilon.com/aboutipsilon/staffpages/pn/presentations/harvard96/transcript/harvard_transcript.html

[N5] rtm@eecs.harvard.edu: Detailed Behaviour of TCP over ATM; http://www.eecs.harvard.edu/~rtm/tcp-atm/tcp-atm-1.html

[N7] Cellware: Pocket Guide To ATM; Cellware, Berlin, März 1996; Papierversion von Teilen von http://www.cellware.de/

[N8] ATM-Forum: Intermediate ATM, LAN Emulation & PNNI, Release 1.0 (Computer Based Training), 1996; 2 Disketten (Format MS-Windows, US$10)

[N9] Usenet newsgroup comp.dcom.cell-relay

[N10] cell-relay Mailinglist; ftp://netlab.ucs.indiana.edu/pub/mail_archive/cell-relay und http://netlab.ucs.indiana.edu/hypermail/cell-relay/.

[N11] CISCO Systems: LAN-Emulation; http://www.cisco.com/warp/public/729/c5000/c5000_tc.htm

[N12] Anthony Alles: ATM Internetworking (white paper); Cisco Systems, Inc.: May 1995; http://www.univ-valenciennes.fr/ATM/doc.html

[N13] Digital Equipment: LAN Emulation Quellcode; http://www.networks.digital.com:80/dr/atmkit/index.html, atm-starter-kit@digital.com


[ Back to Homepage | ATM-Site ]