7. Die Verbindungssteuerung
Voraussetzung, um Pakete über ein leitungsvermittelndes Netz (Circuit Switching) übertragen zu können, ist der Aufbau von Verbindungen. Im folgenden Abschnitt ist daher die Wahl einer geeigneten Schnittstelle zum Wählnetz, sowie eines Protokolls und einer adäquaten Strategie für die Verbindungssteuerung in einem ISDN-LAN zu treffen.
7.1 Protokolle für die Kommunikationssteuerung
Heute ist der Aufbau einer Verbindung in einem Computerwählnetz weitgehend automatisiert. Ähnlich wie beim Aufbau eines Telefongespräches müssen auch beim rechnergestützten Verbindungsaufbau Regeln eingehalten werden. Diese Regeln sind bei der computerisierten Verbindungssteuerung zu Protokollen zusammengefaßt.
7.1.1 Automatische Kommunikationssteuerung
Ein Protokoll zur Verbindungssteuerung muß alle Situationen, die beim Aufbau, beim Abbau und während einer Verbindung auftreten können, erfassen. Grundsätzlich wird bei der Verbindungssteuerung zwischen der aktiven Station, die den Wunsch zum Verbindungsaufbau äußert, und der passiven Station, die eine Verbindung entgegennimmt, unterschieden. Somit ergeben sich vier Funktionen, die ein Protokoll zu bewältigen hat:
v Anforderung zum aktiven Verbindungsaufbau
v Anforderung zur aktiven Verbindungsauflösung
v Entgegennahme eines ankommenden Anrufs vom Netz
v Entgegennahme einer Verbindungsauflösungsanforderung von Netz
Diese Funktionen sind wiederum unterteilt in einzelne Teilschritte. So besteht die Verbindungsaufbauphase zumeist aus der Rufanforderung (Setup), der Anforderungsbestätigung, der Rufnummernübermittlung und der Verbindungsbestätigung (Connect). Die Entgegennahme eines ankommenden Anrufs besteht aus der Rufanzeige (Alerting) und der Rufentgegennahme (Abb. 7.1.1). Um eine Verbindung abzubrechen, wird von einer Station eine Auslöseanforderung an die Netzschnittstelle übermittelt. Diese antwortet mit einer Auslösebestätigung. Die Auflösung einer Verbindung durch das Netz wird einer Station durch eine Verbindungsauflöseanzeige über die Schnittstelle mitgeteilt.
Abb. 7.1.1: Schematischer Ablauf eines Verbindungsaufbaus
Charakteristische Vertreter solcher Protokolle sind die D-Kanal-Protokolle und das X.21-Protokoll. Beim D-Kanal-Protokoll geschieht die Signalisierung über den Austausch von Steuer- und Informationspaketen[1]. Aufbauend auf dem D-Kanal eines ISDN-Kanals wird dazu ein LAP-D-Protokoll implementiert, das dem HDLC-Protokoll[2] entspricht. Die eigentliche Signalisierung geschieht auf der Netzwerkschicht des D-Kanal-Protokolls.
Eine Abwandlung eines D-Kanal-Protokolls wird von Nixdorf zur Verbindungssteuerung über V.24-Schnittstellen verwendet[3]. Hier geschieht die Signalisierung allerdings nicht über Pakete, sondern über Steuersequenzen. Dieses Protokoll ist daher wesentlich einfacher zu implementieren als etwa das LAP-D-Protokoll und kann sogar an einem Terminal verwendet werden:
Verbindungsanforderung Rufnummer
Wahlaufforderung Verbindungsbest.
Eingabe am Terminal: ^A^B+ 150
Meldungen von der Schnittstelle: D+ C+
Aufwendiger, jedoch weit verbreitet, ist das X.21-Protokoll. Die X.21-Norm legt eine Schnittstelle fest, die den Zugang zu synchronen Datennetzen mit leitungsvermittelnder Struktur ermöglicht[4]. Die Signalisierung erfolgt hier über 6 spezielle Signalleitungen, die Informationen und Signale, wie das Indicate und das Control, liefern. Zusätzlich bietet die Schnittstelle einen Schritt- und einen Byte-Takt an. Die physikalischen und elektrischen Parameter werden durch die X.27-Norm festgelegt. Besonders zu bemerken ist, daß durch die X.30-Norm die Abbildung der X.21-Signalisierung auf das D-Kanal-Protokoll des ISDN bereits festgelegt ist. Somit ermöglicht die X.21-Schnittstelle auch den Zugang zu ISDN.
7.1.2 Wahl des Verfahrens und der Schnittstelle
Für eine Übertragung von Daten über eine digitale Nebenstellenanlage stehen verschiedene Schnittstellen zur Auswahl. Im Falle der Nixdorf 8818 sind das eine asynchrone GSVA-Schnittstelle mit 48 kbit/s Übertragungsleistung und verschiedene synchrone X.21-Schnittstellen (DSX, GSX, GSXI). Die Implementierung einer Verbindungssteuerung über ein D-Kanal-Protokoll nach CCITT I.450/1 steht mangels einer S0-Schnittstelle nicht zur Diskussion.
Ähnlich den bekannten asynchronen GSVA-Schnittstellen sind von der Firma Nixdorf asynchrone Schnittstellen mit einer Übertragungsleistung von 48 kbit/s erhältlich. Der Verbindungsaufbau geschieht, wie von den GSVA-Schnittstellen gewohnt, über ein vereinfachtes „Nixdorf-eigenes“ D-Kanal-Protokoll. Dieses Protokoll wird von anderen Herstellen von CPBX-Anlagen nicht unterstützt. Wenn überhaupt, so bieten die verschiedenen Hersteller eigene Produkte und Protokolle für den Zugang zu Wählnetzen an. Die Verwendung einer asynchronen Schnittstelle hat außerdem den Nachteil, daß bei der Übertragung von Paketen ein hoher Implementierungsaufwand entsteht[5].
X.21-Schnittstellen dagegen sind für die Übertragung von Daten in leitungsvermittelnden Systemen weit verbreitet und genormt. Nahezu jeder Hersteller von modernen digitalen Nebenstellenanlagen[6] bietet für seine CPBX eine X.21-Schnittstelle zur synchronen Datenübertragung an. Als weiterer, nicht unerheblicher Vorteil muß die Normierung der Abbildung der X.21-Signalisierung auf das D-Kanal-Protokoll im öffentlichen ISDN betrachtet werden. Somit wird die X.21-Schnittstelle auch nach der Einführung des öffentlichen ISDN ihren Stellenwert behalten.
Das X.21-Protokoll bietet nach dem Verbindungsaufbau einen völlig transparenten Kanal, der individuell genutzt werden kann. Somit wird es möglich, über eine bestehende Verbindung ein HDLC-Protokoll zu betreiben, was einen erheblichen Vorteil gegenüber einer asynchronen oder BSC-Datenübertragung darstellt. Vorteilhaft ist auch, daß über die X.21-Schnittstelle vom Netz ein externer 64 kHz Takt angeliefert wird, der für die Synchronisation der Übertragung verwendet werden kann[7].
7.2 Der X.21-Verbindungsaufbau
Im Ruhezustand, wenn die DCE (die Schnittstelle) und die DTE (der Rechner) bereit sind eine Verbindung aufzubauen, sendet die DCE auf ihrer Receive-Leitung (R) kontinuierlich binäre „1“ und das Indicate-Signal der Schnittstelle ist im OFF-Zustand. Die DTE sendet auf der Transmit-Leitung ständig „1“ und das Control-Signal signalisiert OFF.
Abb. 7.2.1: Die Übergänge der Ruhezustände im X.21-Protokoll
Wie das Zustandsdiagramm aus Abbildung 7.2.1 zeigt, sind bereits in der Ruhephase verschiedene Fehlersituationen der DCE und auch der DTE denkbar. Diese Fehlersituationen müssen vom X.21-Protokoll erkannt und, falls möglich, behoben werden.
7.2.1 Verbindungsanforderung
Die DTE signalisiert nun einen Verbindungswunsch, indem sie das Control-Signal auf ON setzt und auf der Transmit-Leitung beginnt, kontinuierlich „0“ zu senden. Das Control-Signal muß dabei innerhalb von 7 Bitzeiten vor oder nach dem Übergang der Transmit-Leitung wechseln[8].
Innerhalb von 3 Sekunden antwortet die DCE mit der Wahlaufforderung. Diese besteht aus zwei einleitenden SYN-Zeichen ($16) gefolgt von einer unbestimmt langen Sequenz von „+“-Zeichen. Nach spätestens 6 Sekunden muß die DTE mit dem Senden der Wahlzeichen beginnen, und nach 36 Sekunden muß dieser Vorgang abgeschlossen sein. Eine Wahlsequenz besteht aus zwei einleitenden SYN-Zeichen, gefolgt von Zeichen des Internationalen Alphabetes Nr. 5 (IA5) und abgeschlossen durch einen „+“-Character. Danach sendet die DTE auf der Transmit-Leitung kontinuierlich binäre „1“.
Abb. 7.2.2: Schematisches Zeitverhalten der Signale beim Verbindungsauf- und -abbau
Das Netz reagiert mit der Übermittlung von Dienstsignalen und der Anschlußkennung auf der Receive-Leitung, die unter Umständen durch längere Sequenzen von SYN-Zeichen voneinander getrennt sind. Durch das Senden von 1-Bits signalisiert das Netz, daß die Verbindung im Aufbau ist. Sobald eine Verbindung besteht, signalisiert das Netz der DTE durch Versetzen des Indicate-Signals vom OFF- in den ON-Zustand, daß es bereit ist, Daten entgegenzunehmen und an die Gegenseite der Verbindung zu übertragen (siehe Abb. 7.2.2). Über die Transmit-Leitung kann nun ein beliebiger Bitstrom übertragen werden. Dazu wird von der Schnittstelle ein Bit- und optional ein Bytetakt angeliefert.
7.2.2 Abbau einer Verbindung
Wünscht eine DTE eine bestehende Verbindung abzubrechen, so setzt sie die Control-Leitung vom ON- in den OFF-Zustand und beginnt auf der Transmit-Leitung kontinuierlich 0-Bits zu senden. Das Netz reagiert seinerseits mit einer Auslösebestätigung, indem es das Indicate-Signal auf OFF setzt und auf der Receive-Leitung kontinuierlich binäre „0“ sendet. Die DCE begibt sich schließlich in den Ruhezustand und sendet auf der Receive-Leitung 1-Bits. Hierauf geht auch die DTE in den Ruhezustand über und sendet 1-Bits auf der Transmit-Leitung (vgl. Abb. 7.2.2).
7.2.3 Entgegennahme eines Anrufs
Abb. 7.2.3: Zeitverhalten bei ankommender Ruf- und Auslöseanforderung
Ein ankommender Anruf wird bei der angerufenen DTE durch eine Sequenz von SYN-Zeichen, gefolgt von BEL-Zeichen, signalisiert (Abb. 7.2.3). Nimmt eine DTE einen ankommenden Anruf entgegen, so zeit sie das dem Netz an, indem sie das Control-Signal vom OFF- in den ON-Zustand versetzt. Hierauf sendet das Netz der DTE auf der Receive-Leitung Dienstsignale und die Anschlußkennung. Anschließend signalisiert das Netz durch das Senden von 1-Bits, daß die Verbindung im Aufbau ist. Sobald die Verbindung steht, zeigt das Netz der DTE durch Versetzen des Indicate-Signals vom OFF- in den ON-Zustand an, daß es bereit ist, Daten entgegenzunehmen und an die Gegenseite der Verbindung zu übertragen.
7.2.4 Anforderung einer Verbindungsauslösung
Wird die Verbindung nicht von der DTE, sondern vom Netz aufgelöst, so signalisiert dieses den Auslösewunsch durch Versetzen des Indicate-Signals vom ON- in den OFF-Zustand und durch Senden von 0-Bits auf der Receive-Leitung. Die DTE antwortet mit der Auslösebestätigung, indem sie die Control-Leitung in den OFF-Zustand bringt und auf der Transmit-Leitung kontinuierlich 0-Bits sendet. Die DCE begibt sich schließlich wieder in den Ruhezustand und schickt auf der Receive-Leitung 1-Bits. Hierauf geht auch die DTE in den Ruhezustand über und überträgt 1-Bits auf der Transmit-Leitung.
7.2.5 Behandlung von Fehlersituationen und Timeouts
Bei Aufbau einer Verbindung, während der Datenübertragungsphase und beim Verbindungsabbau können verschiedene Fehlersituationen eintreten. Diese werden entweder von der DCE erkannt und an die DTE signalisiert, oder die DTE erkennt ein Fehlverhalten selbständig. Oft sind bestimmte Anfragen und Aktionen durch einen Timeout begrenzt.
Anhand der Receive-Leitung und des Indicate-Signals kann die DTE den Zustand der Schnittstelle erkennen (siehe Abb. 7.2.3). Der Zustand der DTE wird der Schnittstelle über die Transmit-Leitung und das Control-Signal angezeigt. Befindet sich ein Signal nicht im gewünschten Zustand, so wird ein Fehler erkannt.
Beim Aufbau einer Verbindung kann eine Fehlersituation von der DTE durch Auswertung der Dienstsignalisierung des Netzes erkannt werden. Im Normalfall liefert die Schnittstelle die Rufnummer der Gegenseite und, falls gewünscht, das Datum und die Uhrzeit. Tritt ein Fehler auf, so wird nicht die Rufnummer, sondern ein Fehlercode empfangen. Dieser Code besteht aus zwei Ziffern, wobei die erste die Fehlerklasse determiniert und die zweite Ziffer die genaue Ursache bestimmt[9] (siehe Abb. 7.2.4). Ein besetzter Teilnehmer wird beispielsweise durch die Meldung '+21+' signalisiert. Die DTE versucht daraufhin, nach kurzem Warten, einen erneuten Verbindungsaufbau.
|
Meldungsklasse (Erste Ziffer des Codes) |
Bedeutung für die DTE |
|
0 |
Bitte warten |
|
2, 6 |
Verbindungsaufbau hatte keinen Erfolg, kurzzeitige Störung, erneut versuchen |
|
4, 5, 7 |
Verbindungsaufbau hatte keinen Erfolg, längere Störung, nicht mehr versuchen |
Abb. 7.2.4: Die Fehlerklassen des X.21-Protokolls
Alle Aktionen der DTE oder des Netzes, die eine Antwort der jeweiligen Gegenseite erfordern, sind mit einem Timeout versehen. Nach Ablauf eines für jede Aktion spezifischen Zählers wird ein Fehler erkannt und in einen durch ein Zustandsdiagramm festgelegten Zustand übergegangen[10]. Zu diesen Timeouts ist noch anzumerken, daß sie zum Teil für die Übertragung von AppleTalk-Paketen über eine CPBX zu lang sind und bei Fehlern unnötige Wartezeiten verursachen.
Aufgrund der höheren Übertragungsleistung und der weiten Verbreitung von X.21-Schnittstellen im Bereich der digitalen Datenübermittlung über Wählnetze wird zur Übertragung von AppleTalk-Paketen eine GSXI-Schnittstelle verwendet.
7.3 Verbindungssteuerung
Der folgende Abschnitt beschäftigt sich mit der Wahl einer adäquaten Verbindungssteuerung für die verbindungslosen AppleTalk-Protokolle. Bei der Emulation einer LAN-Topologie ist einerseits darauf zu achten, daß der Protokolloverhead, der durch die Diskrepanz zwischen der Zeit für einen Verbindungsaufbau und der Übertragung eines Paketes entsteht, minimiert wird und andererseits eine Monopolisierung von Netzwerkressourcen auszuschließen ist. Außerdem müssen mehrere konkurrente Transaktionen unterstützt werden.
7.3.1 Strategien zur Verbindungssteuerung
Anders als bei LANs oder paketvermittelnden Systemen genügt es bei leitungsvermittelnden Systemen zu Beginn einer Übertragung eine Verbindung herzustellen und diese am Ende wieder abzubauen. Den Daten müssen keine Adreßinformationen mitgegeben werden, die Übertragung kann wie über ein Nullmodem verlaufen. Durch eine permanente Aufrechterhaltung von Verbindungen entsteht über die Leitung aber eine Monopolisierung einer Netzwerk-Ressource (z.B. eines Dateiservers), da andere Teilnehmer für die Dauer der Verbindung vom Zugriff auf diese Ressource ausgeschlossen werden. Daher muß eine akzeptable Strategie zur Verbindungssteuerung gefunden werden, die klärt, wann und für wie lange eine Verbindung hergestellt wird. Einfluß auf die Wahl dieser Strategie haben folgende Faktoren:
v Die Kosten eines Verbindungsaufbaus: Hierzu zählen sowohl die Dauer eines Verbindungsaufbaus als auch die Gebühren, die für einen Verbindungsaufbau anfallen.
v Die Dauer einer Datenübermittlung: Sind nur wenige, vereinzelte Pakete zu übertragen oder lange Dateiblöcke?
v Das Format der Daten: Insbesondere ob in den Daten die Ziel- und die Quelladresse enthalten sind oder nicht.
v Die Frequenz des Zugriffes auf eine Netzwerk-Ressource: Die Häufigkeit des Zugriffs auf ein Gerät beeinflußt die Anzahl der notwendigen Verbindungen.
v Die Anzahl der um eine Ressource konkurrierenden Stationen: Je weniger Stationen auf eine Ressource zugreifen, desto länger kann eine Verbindung bestehen.
Unter Berücksichtigung dieser Faktoren und des sequentiellen Ablaufs einer Sitzung haben sich folgende Strategien zur Verbindungssteuerung bewährt (vgl. Abb. 7.3.1):
• Die halbautomatische Verbindungssteuerung erlaubt dem Benutzer über ein Hilfsprogramm einen Teilnehmer auszuwählen, eine Verbindung zu installieren und wieder abzubrechen. Ein derartiges Verfahren findet Verwendung im Zusammenhang mit den Wähldeskaccessories des PluriCom-Paketes.
• Die sessionorientierte Verbindungsteuerung[11] hält eine Verbindung für die Dauer einer Session aufrecht. Da eine Sitzung unter Umständen sehr lange dauern kann, entsteht so eine starke Monopolisierung von Netzwerk-Ressourcen. Mit einem Diskserver im LAN können mehrere Workstations eine Session aufrechterhalten, auch wenn sie zur Zeit nicht auf den Server zugreifen. Ein Beispiel für diese Art der Verbindungssteuerung ist das Drucken über die PDEF10 des PluriCom-Paketes.
• Die transaktionsorientierte Verbindungsteuerung baut eine Verbindung auf, jedesmal wenn ein Request an eine Station gerichtet wird, und wieder ab, wenn die erwartete Antwort erhalten wurde. Diese Strategie wird als Fast Disconnect bezeichnet. Oft ist es jedoch schwierig einen Ansatzpunkt für eine Transaktion zu finden[12]. Ferner können an einem Server mehrere Transaktionen gleichzeitig ablaufen. Eine transaktionsorientierte Verbindungssteuerung kommt beispielsweise beim Lesen des Server-Directories im PluriCom-Kermit zur Anwendung.
• Die objektorientierte Verbindungssteuerung richtet für jedes zu übertragende Datenobjekt eine neue Verbindung ein. Als Objekte können Dateien, Resourcen, Sektoren oder im Extremfall einzelne Pakete betrachtet werden. Diese Strategie bietet eine optimale Ausnutzung der Schnittstellen durch mehrere Geräte. Da jedoch unter Umständen die Dauer eines Verbindungsaufbaus[13] im Verhältnis zur Übertragungsdauer eines Datenobjektes sehr lange sein kann, mindert diese Strategie den Datendurchsatz einer Schnittstelle.
Abb. 7.3.1: Verbindungssteuerungsstrategien im Vergleich
Die adäquate Verbindungstrategie für ein Rechnernetz muß, entsprechend den Rahmenbedingungen, im Einzelfall gewählt werden. Da Parameter, wie die Zugriffsfrequenz und die Dauer der Datenübermittlung stark variieren können, ist keine dieser Strategien unter allen Einsatzbedingungen optimal. Die Kombination und Abwandlung einzelner Strategien kann zur Verbesserung der Schnittstellenausnutzung durch mehrere Geräte und des Durchsatzes führen.
7.3.2 Hooks für den aktiven Verbindungsaufbau
Um ein LAN wie AppleTalk über das leitungsvermittelnde System einer CPBX zu betreiben, muß unter Berücksichtigung der Besonderheiten des AppleTalk und der CPBX eine geeignete Strategie zur automatischen Verbindungsteuerung gefunden werden. Eine manuelle Verbindungsteuerung wäre durchaus denkbar, führt aber zu einer unnötigen Belastung des Benutzers.
7.3.2.1 Sessionorientierte Verbindungssteuerung
Eine sitzungsorientierte Verbindungsteuerung für ISDN-AppleTalk muß die unterschiedlichen Protokolle der Sitzungsschicht des AppleTalk berücksichtigen. Ein Ansatzpunkt für den Verbindungsaufbau könnten die OpenXXXSession-Prozeduren dieser Protokolle sein. Über CloseXXXSession wird eine Verbindung wieder abgebrochen. Nach diesem Prinzip der sessionorientierten Verbindungssteuerung arbeitet das modifizierte PAP des PluriCom-Paketes. Im Zusammenhang mit dem Drucken funktioniert dieses Prinzip auch einwandfrei, da immer nur eine Printer Session aktiv ist. Gegen die generelle Verwendbarkeit dieser Methode zur Anpassung von AppleTalk an eine leitungsvermittelnde Struktur sprechen aber folgende Gründe:
v Es genügt nicht, die Verbindungsteuerung nur mit dem ASP-Protokoll zu koppeln. Sämtliche Protokolle der Sitzungsschicht (ASP, ZIP, PAP, ADSP) müßten angepasst werden, was einen erheblichen Aufwand bedeuten würde[14].
v Die Anpassung der Protokolle kann sich schwierig gestalten und es entsteht eine Vielzahl neuer Treiber, die beim Wechsel des Übertragungsmediums jeweils installiert und deinstalliert werden müßten. Speziell das ASP ist mit Teilen des AFP zum .XPP-Treiber zusammengefaßt, so daß hier keine klare Schnittstelle vorliegt.
v Eine Modifikation der Protokolle der Session-Schicht genügt noch nicht, da zahlreiche autonome Protokolle unterhalb dieser Schicht angesiedelt sind und gleichfalls Verbindungen benötigen.
v AppleTalk-Workstations können jeweils mehrere aktive Sitzungen mit verschiedenen Servern unterhalten. CPBX-Anlagen erlauben jedoch zur gleichen Zeit nur eine aktive Verbindung zu einer Station.
v Eine AppleTalk-Sitzung kann sehr lange dauern. Da eine Verbindung für die Dauer der Sitzung bestehen bleibt, wird somit über die Leitung ein Gerät monopolisiert.
7.3.2.2 Transaktionsorientierte Verbindungssteuerung
Auch auf der Transportschicht finden sich Ansatzpunkte für den Auf- und Abbau einer Verbindung. Hier kann eine Verbindung mit dem Beginn einer Transaktion eingerichtet und mit Beendigung dieser wieder ausgelöst werden. Ein Kombinieren des Verbindungsauf- und -abbaus mit dem Öffnen und Schließen eines ATPSockets ist durchaus denkbar. Eine transaktionsorientierte ist einer sitzungsorientierten Verbindungssteuerung vorzuziehen, da sie keine Monopolisierung eines Gerätes verursacht. Dennoch sprechen auch hier entscheidende Gründe dagegen:
v Nicht nur das ATP-Protokoll müßte modifiziert werden. Vielmehr wären sämtliche Protokolle der Transportschicht (ATP, NBP, RTMP, EP) anzupassen.
v Die Protokolle sind wieder in verschiedenen Treibern untergebracht. Auch hier ist es also nicht damit getan, nur einen Treiber zu modifizieren.
v Eine Kopplung der Verbindungssteuerung mit den Protokollen der Transportschicht reicht nicht aus. Klienten und Protokolle höherer Schichten können auch direkt auf die Netzwerk- oder Verbindungsschicht zugreifen.
v Schließlich können mehrere ATPSockets gleichzeitig geöffnet oder in den neueren AppleTalk-Versionen auch mehrere Name LookUps pendent sein. Zu jedem Zeitpunkt ist aber stets nur eine Wählverbindung möglich.
v Schwierigkeiten bereitet zudem das Erkennen des Endes einer Transaktion, d.h. wann eine Verbindung wieder abgebaut werden soll. Eine Kopplung mit dem Öffnen und Schließen von ATPSockets ist ebenso nicht unproblematisch, da dieses oft sessionorientiert geschieht und somit zu Monopolisierung führt. Programmierer öffnen ATPSockets oft am Anfang eines Programmes und schließen sie erst am Ende[15].
7.3.2.3 Objektorientierte Verbindungssteuerung
Als Objekte können Dateien und Dokumente aber auch einzelne Pakete aufgefaßt werden. Dateien und Dokumente findet man nur in den höheren Schichten des AppleTalk Protocol Stack. Pakete transportieren die Schichten 2 und 3. Auf diesen Schichten ist in AppleTalk jeweils nur ein Protokoll vorhanden. Gegen eine Koppelung der Verbindungssteuerung mit der Übertragung von DDP-Datagrammen spricht, daß ein Klient auch Pakete direkt über das LAP-Protokoll übertragen kann und der .MPP-Treiber modifiziert werden müßte. Die Verbindungsschicht jedoch ist für alle höheren Protokolle die Basis der Paketübertragung. Zudem gibt es hier eine Schnittstelle, die die Substitution des Link Access Protocols erlaubt.
Da für jedes Datenobjekt (Paket) eigens eine Verbindung eingerichtet wird, unterstützt eine objektorientierte Verbindungssteuerung mehrere Transaktionen und Sitzungen gleichzeitig. Eine rein paketorientierte Verbindungsteuerung bewirkt jedoch bei jedem Paket einen Verbindungsauf- und -abbau. Da die Zeit für einen Verbindungsaufbau, verglichen mit der reinen Übertragungszeit eines Paketes, sehr lange sein kann, ist diese Methode sehr ungünstig und kann so nicht verwendet werden. Sowohl der Rechner als auch die PBX-Anlage wäre ständig mit dem Auf- und Abbau von Verbindungen belastet[16]. Eine Lösung für dieses Problem wird im nächsten Abschnitt vorgestellt.
Eine transaktionsorientierte Verbindungssteuerung ist einer objekt- oder einer sitzungsorientierten Verbindungssteuerung, aufgrund der geringeren Monopolisierung und des höheren Durchsatzes, vorzuziehen. Oft ist es jedoch schwierig einen Ansatzpunkt für eine Transaktion zu finden.
7.4 Retardierende objektorientierte Verbindungssteuerung
Die retardierende objektorientierte Verbindungssteuerung läßt eine Verbindung nach der Übertragung eines Paketes noch für kurze Zeit bestehen. Abgebaut wird sie erst dann, wenn während dieser Zeit kein weiteres Paket an dieselbe Adresse übertragen oder empfangen wurde (Abb. 7.4.1). Zusätzlich kann eine Verbindung durch die Gegenstation abgebrochen werden. Da es sehr wahrscheinlich ist, daß mehrere Pakete unmittelbar hintereinander an dieselbe Adresse zu übertragen sind, bewirkt diese Strategie eine erhebliche Reduzierung der notwendigen Verbindungen[17] (vgl. hierzu Abb. 7.4.1).
Abb. 7.4.1: Passiver versus aktiver Verbindungsabbau
Werden während einer Wählverbindung mehrere Transaktionen mit derselben Gegenstation durchgeführt, so ist das Prinzip des retardierenden Verbindungsabbaus bezüglich der Anzahl der notwendigen Verbindungen besser als eine transaktionsorientierte Verbindungssteuerung. Bei mehreren logischen Verbindungen (Sitzungen) zu verschiedenen Gegenstationen wird jedoch ein ständiger Wechsel der Wählverbindungen notwendig.
7.4.1 Der Verbindungsaufbau
Im Detail funktioniert die Verbindungssteuerung wie folgt: Bevor eine Station ein Paket sendet, prüft sie, ob bereits eine Verbindung besteht. Besteht keine Verbindung, so wird die Rufnummer zur Zieladresse des Paketes gewählt. Andernfalls wird geprüft, ob das zu sendende Paket an den Knoten adressiert ist, zu dem die Verbindung besteht. Unterscheiden sich die Adressen, so muß die bestehende Verbindung abgebrochen und die der Zieladresse entsprechende Rufnummer gewählt werden. Schließlich wird das Paket übertragen. Dieses Schema verdeutlicht das Flußdiagramm in Abbildung 7.4.2.
Abb. 7.4.2: Schema einer Sendeanforderung
7.4.2 Der Verbindungsabbau
Nach dem aktiven oder passiven[18] Verbindungsaufbau und der Übertragung eines Paketes bleibt die Verbindung zunächst bestehen. Aktiv abgebrochen wird sie nur dann, wenn die Zieladresse des zur Übertragung anstehenden Paketes nicht mit der Knotenadresse der Gegenstation übereinstimmt. Passiv abgebrochen wird eine Verbindung zeitlich verzögert durch einen Timeout oder durch die Gegenstation. Dieser Timeout wird jedesmal, wenn ein Paket empfangen oder übertragen wurde, zurückgesetzt, so daß die Verbindung erst dann abbricht, wenn für eine bestimmte Zeit kein Verkehr auf der Leitung zu verzeichnen war. Dieses Verhalten ist vergleichbar mit dem Nachlaufen eines Diskettenlaufwerks.
Unter ungünstigen Bedingungen kann es auch hier zu einer Monopolisierung kommen. Die Länge des Timeouts kann von Station zu Station unterschiedlich sein. So kann ein Server schon nach sehr kurzer Zeit auflegen, um eine Monopolisierung des Zugriffs durch eine Station zu verhindern. Eine Verkürzung des Timeouts in Abhänigkeit von der Dauer einer Verbindung kann zur Verringerung der Monopolisierungsgefahr beitragen.
7.4.3 Das Leistungsmerkmal „Anklopfen“
Um eine Momopolisierung, die bei der eben vorgestellten retardierenden objektorientierten Verbindungssteuerung unter ungünstigen Umständen immer noch denkbar ist, zu verhindern, wäre in leitungsvermittelnden Systemen ein zusätzliches Leistungsmerkmal „Anklopfen“ nützlich:
v Eine Verbindung zu einer Ressource im Netzwerk würde dann solange bestehen bleiben, bis eine weitere Station auf diese zuzugreifen wünscht. Dadurch könnte nicht nur die Anzahl der Verbindungen minimiert, sondern auch eine Monopolisierung verhindert werden. Greift nur eine einzige Station auf eine Netzwerk-Ressource zu, so bleibt nach dem ersten Datenpaket die Verbindung für die Dauer der Sitzung bestehen.
v Zusammen mit diesem Leistungsmerkmal wäre auch denkbar, daß bei besetzter Leitung keine Wahlwiederholung durchgeführt wird, sondern sich die angerufene Station merkt, welche Teilnehmer sie vergeblich zu erreichen versuchten. Wird die Leitung wieder frei, so ruft die Station die Teilnehmer in der Reihenfolge, in der sie anklopften, zurück.
Leider wird ein derartiges Leistungsmerkmal durch das X.21-Protokoll nicht unterstützt, so daß es für die Verbindungssteuerung in ISDN-AppleTalk nicht zur Verfügung steht.
Der Auf- und Abbau einer Verbindung erfolgt nach dem X.21-Protokoll und wird durch die retardierende objektorientierte Verbindungssteuerung geregelt.