SDL, Estelle und Lotos, präsentiert am Beispiel des ISDN-D-Kanal-Protokolls (1. Teil):

Formale Methoden zur Spezifikation von Protokollen

04.10.1985

Bei der Normung von Kommunikationsprotokollen (zum Beispiel OSI) wächst wegen der Unzulänglichkeit von herkömmlichen informalen Beschreibungsmitteln der Bedarf an formalen Methoden. Bei CCITT und ISO befinden sich solche Methoden zur Zeit in der Standardisierung. Auch im Software-Life-Cycle sind sie als sinnvolle und wertvolle Hilfsmittel einsetzbar.

Eine formale Spezifikationsmethode oder Formal Description Technique (FDT) ist ein Mittel zur Beschreibung von Systemen, das bereits in der Spezifikationsphase eingesetzt wird mit dem Ziel, in möglichst kompakter Form das Verhalten eines Systems darzustellen. Dabei soll nur berücksichtigt werden, wie sich das System einem außenstehenden Beobachter darstellt, das heißt insbesondere, daß interne Eigenschaften einer möglichen Implementation außer Betracht bleiben. Dennoch soll eine solche Beschreibung auf diesem Abstraktionsgrad vollständig und exakt sein. Darüber hinaus sind Konsistenz und Eindeutigkeit wichtige Eigenschaften einer Spezifikation, was durch den Einsatz einer FDT ermöglicht werden soll. Schließlich ist die mögliche Überprüfung der geforderten Eigenschaften einer Spezifikation ein weiterer wichtiger Punkt.

Damit eine FDT solche Forderungen erfüllen kann, bedarf es einer weitgehenden Formalisierung der zur Beschreibung eines Systems verwendeten Elemente und einer Festlegung ihrer Bedeutung. Dies erfolgt durch die Definition einer Syntax und einer Semantik für die Elemente der FDT und ihres Zusammenwirkens. Weiterhin ist ein abstraktes Systemmodell als theoretische Grundlage nötig, mit dessen Hilfe ein spezifiziertes System analysiert werden kann, um die Korrektheit einer Spezifikation im Hinblick auf Anforderungen, die a priori an ein System gestellt werden, beweisen zu können.

Die Vorteile, die sich durch den Einsatz einer FDT für die Systementwicklung ergeben, liegen auf der Hand. Wenn einer Spezifikation solch weitreichende Bedeutung zukommt wie zum Beispiel bei der Definition von höheren Protokollen und Diensten in offenen Kommunikationsnetzen, wird die Notwendigkeit für den Einsatz von FDTs besonders groß, da das "richtige" Zusammenwirken unterschiedlichster Implementationen derselben Spezifikation gewährleistet sein muß. Besonders an diesem Beispiel wird deutlich, wie wichtig die oben angeführten Eigenschaften sind.

Als weiterer Vorteil von formalen Spezifikationen eröffnet sich die Möglichkeit der automatischen Implementation. Allerdings ist dieser Punkt nicht das vordringliche Anliegen für den Einsatz von FDTs. Außerdem ist es bis zur Verwirklichung maschineller Umsetzungen formaler Spezifikationen in ablauffähige Programme mit akzeptablem Laufzeitverhalten voraussichtlich noch ein weiter Weg. Dennoch könnten auch Teilerfolge auf diesem Weg bereits große Hilfe bei der Implementation leisten.

Im weiteren wollen wir uns mit FDTs beschäftigen, die in erster Linie zur Spezifikation von Kommunikationssystemen, hauptsächlich in offenen Netzen, dienen, wenngleich sie nicht auf den alleinigen Einsatz auf diesem Gebiet festgelegt sind.

Solche FDTs müssen zusätzlich noch so spezifiziert sein, daß ihre Beschreibungsmittel von allen, die damit zu tun haben, akzeptiert und eindeutig interpretiert werden können woraus sich der Bedarf einer Standardisierung von FDTs ergibt. Es ist davon auszugehen, daß die intuitive Verständlichkeit und die Handhabbarkeit einer Methode Einfluß auf ihre Akzeptanz haben.

Die Artikelfolge beschäftigt sich mit drei speziellen FDTs. Dabei handelt es sich um SDL (Specification and Description Language), das von CCITT standardisiert wird, und Estelle und Lotus, die sich beide gerade bei der ISO im Normungsprozeß befinden.

Für jede der Methoden wird einer allgemeinen Beschreibung ein Beispiel folgen. Dazu werden wir jedesmal dasselbe Beispielprotokoll zugrunde legen, das nachfolgend beschrieben wird. Dieses Vorgehen zeigt die Möglichkeiten jeder FDT im praktischen Einsatz und erlaubt eine vergleichende Diskussion der Methoden, die am Ende der Artikelfolge stehen wird.

In den Beispielen zu den FDTs wird versucht, den Teil des ISDN-D-Kanal-Protokolls, der für den Verbindungsaufbau einer B-Kanal-Verbindung zuständig ist, mit den jeweiligen Beschreibungsmitteln formal zu spezifizieren.

Da nur der Verbindungsaufbau behandelt werden soll, müssen wir voraussetzen, daß eine einmal eingeleitete Verbindung auch zustande kommt. Es würde sonst das Verbindungsabbau-Protokoll zur Freigabe der schon belegten Ressourcen benötigt.

Weiterhin sind weder Optionen noch die (verbindungsbezogenen oder nicht verbindungsbezogenen) Möglichkeiten des Informationsaustauschs zwischen Vermittlungsstelle und Endgerät berücksichtigt.

Zum Verständnis der Beispiele ist eine gewisse Kenntnis der ISDN-Protokolle vorteilhaft, jedoch nicht erforderlich. Um die Übersicht zu erleichtern, stellen wir das Protokoll in der grafischen Beschreibungssprache SDL vor und erläutern es anhand des Diagramms (Bild 1).

Obwohl wir an dieser Stelle auf die Sprachelemente von SDL nicht eingehen wollen, ist doch ihre Bedeutung direkt einleuchtend. Eine genauere Beschreibung des der FDT "SDL" zugrunde liegenden Modells und der Sprachelemente wird in der nächsten Folge dieser Artikelserie durchgeführt werden.

Obwohl ISDN allgemeine Datenverbindungen (also nicht nur Telefonverbindungen) unterstützt, setzen wir im Interesse einer eingänglicheren Darstellung zunächst voraus, daß eine Telefonverbindung aufgebaut werden soll. Im Falle einer Datenverbindung ist dann zum Beispiel das Abheben des Telefonhörers als eine entsprechende Nachricht eines Programms zu interpretieren.

Bei der folgenden Darstellung ist zu beachten, daß der Nachrichtenaustausch immer zwischen Endgerät, also Telefonapparat, und Vermittlungsstelle stattfindet. Daher sind die Nachrichten, die die rufende Seite sendet, nicht in gleicher Weise an der gerufenen Seite zu sehen. Sie werden von der Vermittlungsstelle verarbeitet, und erst nachdem die Verbindung über eventuell mehrere Vermittlungsstellen durchgeschaltet wurde, wird das Aufbauprotokoll an der gerufenen Seite unabhängig von der rufenden Seite durchgeführt.

Die Beispiele geben nicht an, in welcher Weise das Protokoll den Benutzer (einen Menschen oder ein Programm) über Zustandswechsel informiert (Indications). Hier macht auch die ISDN-Protokollspezifikation keine genauen Aussagen.

Aktiver und passiver Verbindungsaufbau

Alle anderen Kommunikationsvorgänge (Mitteilungen des Benutzers an das Protokoll und die Nachrichten zwischen Protokoll und der Vermittlungsstelle - "Service User Requests", "Service Provider Requests" und "Service Provider Indications") sind genau aufgeführt.

Der Protokollablauf in Bild 1 beginnt im Zustand 0: Null. Hier wird zunächst einmal zwischen aktivem und passivem Verbindungsaufbau, also zwischen Rufen und Gerufenwerden, unterschieden. Wir beschreiben zunächst den aktiven Aufbau.

Er wird eingeleitet durch das Abnehmen des Telefonhörers (in den Beispielen als Connect Req dargestellt). Das Telefon schickt darauf eine Setup-Nachricht an die Vermittlungsstelle. Diese Nachricht kann schon Wählziffern enthalten (bei automatisch wählenden den Geräten).

Das Protokoll wartet jetzt im Zustand 1: Start Call auf die Quittung für das Setup. Die Vermittlungsstelle prüft, ob Setup schon genügend Wählziffern geliefert hat, um den gerufenen Teilnehmer eindeutig zu identifizieren. Ist das der Fall, wird der Ruf mit Call Sent quittiert. Ansonsten schickt die Vermittlungsstelle ein Setup Ack.

In diesem Fall (2: Send Info) können weitere Wählziffern über Info-Nachrichten übermittelt werden. Das Drücken einer Wähltaste wird in den Beispielen als Info sending Req bezeichnet. Der Zustand 2: Send Info wird nach dem Aussenden von Info-Nachrichten immer wieder eingenommen.

Auch jetzt prüft die Vermittlungsstelle ständig, ob schon genügend Wählziffern eingetastet wurden. Ist das der Fall, meldet sie das mit Call Sent. Das Protokoll erreicht dadurch den Zustand 3: Call Complete, in dem auf die Reaktion des Partners gewartet wird.

Wenn beim gerufenen Teilnehmer das Telefon anfängt zu klingeln, informiert die Vermittlungsstelle den rufenden Teilnehmer darüber durch Schicken einer Alert-Nachricht. Das Protokoll geht dann in den Zustand 4: Partner alerted über.

Nimmt schließlich der gerufene Teilnehmer das Telefon ab, wird die Sprechverbindung hergestellt und der rufende Teilnehmer mit einer Connect-Nachricht informiert.

Andere, kürzere Varianten des Verbindungsaufbaus lassen bestimmte Nachrichten aus und schicken direkt die folgenden. So kann das Alert ausbleiben, wenn auf der Seite des gerufenen Teilnehmers der Ruf direkt angenommen wird (zum Beispiel durch einen Anrufbeantworter).

Auch das Call Sent kann ausbleiben, wenn die Vermittlungsstelle nicht erkennen kann, wann die Wählziffern komplett sind (wenn zum Beispiel Ziffer für Ziffer an eine andere, herkömmliche Vermittlungsstelle weitergereicht wird und keine Rückmeldung von dieser Vermittlungsstelle möglich ist). In diesem Fall kann auf eine Info-Nachricht direkt ein Alert oder Conn folgen.

In jedem Fall ist nach Empfang der Conn-Nachricht die Verbindung aufgebaut, und das Gespräch kann geführt werden (Zustand 5: Active).

Der passive Fall, in dem die Vermittlungsstelle ruft, wird durch eine Setup-Nachricht von der Vermittlungsstelle eingeleitet. Das Telefongerät prüft zunächst, ob es zu der verlangten Verbindungsart kompatibel ist. Zum Beispiel könnte ein Ruf für ein Telefaxgerät eintreffen, und es wäre nicht sinnvoll, wenn ein normales Telefongerät darauf antworten würde.

Endgeräte, die zu einem Ruf nicht kompatibel sind, dürfen auf Setup nicht antworten, um anderen Geräten, die am gleichen Hauptanschluß betrieben werden, die Möglichkeit zur sinnvollen Antwort zu geben.

Kompatible Geräte antworten abhängig davon, ob sie belegt oder frei sind. Belegte Geräte schicken eine Rel-Nachricht, die von der Vermittlungsstelle mit Rel Ack quittiert wird. (Gewartet wird darauf im Zustand 7: Releasing).

Ein Gerät, das kompatibel und nicht belegt ist, teilt dies der Vermittlungsstelle durch Alert mit. Gleichzeitig wird dem Teilnehmer durch 1 Betätigen der Klingel der Ruf mitgeteilt und im Zustand 6: User alerted darauf gewartet, daß der Telefonhörer abgenommen wird.

Nimmt der Teilnehmer den Hörer ab (Connect Req), schickt das Telefon ein Conn an die Vermittlungsstelle und wartet auf Quittung (Conn Ack, Zustand 8: Connect). Trifft sie ein, wird damit die Durchschaltung der Verbindung signalisiert. (Fortsetzung der Serie folgt in der nächsten Ausgabe)

Die Autoren, Klaus-Peter Fischer (Dipl.-Math.) und Stephan Hesse (Dipl.-Inform.), sind Software Entwickler speziell für Kommunikationssysteme sowie Berater auf diesem Gebiet bei der Telenet GmbH, Geschäftsstelle Rhein-Main.