OSI-Begriffe

Für OSI (Open System Interconnection) sind die Regeln und Leistungen normiert, die zwei Partner einhalten bzw. erbringen müssen, wenn sie miteinander kommunizieren wollen.

Die Organisation ISO (International Organization for Standardization) hat dazu das OSI-Referenzmodell entwickelt. Im OSI-Referenzmodell sind die Kommunikationsaufgaben auf 7 Schichten (Instanzen) verteilt. Für jede Schicht ist festgeschrieben, welche Leistungen sie erbringen muss. Die 7 Schichten bauen hierarchisch aufeinander auf. Jeder Schicht stehen die Leistungen der darunterliegenden Schicht als Dienst zur Verfügung. Diese Dienste stehen der höheren Schicht an Dienstzugriffspunkten (Service Access Point) zur Verfügung.

Bei der Kommunikation greift die Anwendung über einen solchen Zugriffspunkt auf die Dienste des Kommunikationssystems zu:

Wollen nun zwei Anwendungen miteinander kommunizieren und Daten austauschen, so muss zwischen ihnen eine Transportverbindung bestehen. Eine Transportverbindung kann nur zwischen zwei adressierbaren Einheiten im Netz aufgebaut werden. Jede Anwendung muss also über eine im Netz eindeutige Adresse identifizierbar sein.

In der OSI-Welt wird jedem Dienstzugriffspunkt eine Adresse zugeordnet, nicht der Anwendung. Die Anwendung ist dann im Netz identifizierbar über die Adresse des Zugriffspunktes, über den die Anwendung die Kommunikation abwickelt.

Jedem Dienstzugriffspunkt wird deshalb eine im Netz eindeutige Adresse zugeordnet. Sie setzt sich zusammen aus einem Selektor und der Adresse des darunterliegenden Zugriffspunktes.

Wie die Adressen der Zugriffspunkte im OSI-Referenzmodell gebildet werden, ist in der folgenden Grafik dargestellt.

Bild 7: Adressen der Dienstzugriffspunkte im OSI-Referenzmodell

Eine UTM-Anwendung bindet sich an einen Dienstzugriffspunkt, wenn sie mit anderen Anwendungen im Netz kommunizieren will. Die Bindung wird mit der KDCDEF-Anweisung ACCESS-POINT generiert. Über die Adresse dieses Zugriffspunktes ist die UTM-Anwendung dann von ihren Partnern im Netz ansprechbar.

Der Aufbau der Adresse des Zugriffspunktes über den die Anwendung adressierbar ist, ist abhängig von der Hierarchie des Zugriffspunktes. Wickelt die UTM-Anwendung die Kommunikation über OSI TP ab, so bindet sie sich an einen Dienstzugriffspunkt zu den Diensten der Schicht 6. Die Adresse des Zugriffspunktes im lokalen System besteht dann aus dem Transportselektor (Selektor der Transportschicht), dem Session-Selektor (Selektor der Kommunikationssteuerschicht) und dem Presentation-Selektor (Selektor der Darstellungsschicht). Die Netzadresse des Zugriffspunktes besteht damit aus der Netzadresse des Rechners und der Adresse des Zugriffspunktes im lokalen System.

Die Selektoren der einzelnen Schichten müssen im lokalen System eindeutig sein. Die Rechneradresse ist im Netz eindeutig. Die Werte, die Sie für die Adresse des Zugriffspunktes angeben, müssen Sie mit dem Netzverwalter absprechen.

Die Selektoren setzen sich aus Octets zusammen. Octet ist eine andere Bezeichnung für ein Byte (8 Bit). Die Bezeichnung legt aber auch die Nummerierung der Bits in dem Byte fest und damit die Reihenfolge, in der die Bits übertragen werden.

Reihenfolge der Bitübertragung eines Octets

Zu einem Kommunikationspartner können mehrere parallele Verbindungen (auch Association genannt) bestehen. Alle Verbindungen zu einem fernen Partner werden in einer OSI-CON-Anweisung generiert. Die Anzahl der parallelen Verbindungen zu einem Partner legen Sie in einer OSI-LPAP-Anweisung fest. Jeder einzelnen Verbindung muss ein im lokalen System eindeutiger Name, der Association-Name, zugeordnet werden. Die Namen der Associations zu einem fernen Partner generieren Sie ebenfalls in der OSI-LPAP-Anweisung.

Jede Verbindung zwischen zwei Partnern wird von einem dieser Partner verwaltet. Der Partner, der die Verbindung verwaltet, heißt Contention Winner. Der andere Partner ist der Contention Loser. Aufträge können von beiden Partnern gestartet werden. Starten beide Partner zur gleichen Zeit einen Auftrag, so belegt der Auftrag des Contention Winners die Verbindung. Contention Winner einer Verbindung sollte immer der Kommunikationspartner sein, der am häufigsten Aufträge startet.

Existieren zwischen zwei Partnern mehrere parallele Verbindungen, so muss nicht für jede Verbindung festgelegt werden, welcher Partner Contention Loser und welcher Contention Winner ist. Es wird lediglich festgelegt, für wieviele der Verbindungen die einzelnen Partner Contention Winner sein sollen (Anweisung OSI-LPAP). Wiederum sollte der Partner die meisten Verbindungen verwalten, der am häufigsten Aufträge startet.

openUTM unterstützt den TPSU-title (Transaction Processing Service User). Dies ist ein Benutzer der OSI TP nutzt und bestimmte Dienste innerhalb einer Anwendung erbringt. In openUTM ist das die Folge von Teilprogrammen, die einen Vorgang bilden. Ein TPSU-title ist ein eindeutiger Name innerhalb einer Anwendung. In openUTM ist dies der TAC-Name des ersten Teilprogramms eines Vorgangs. Der initiating TPSU-title ist der TPSU-title des Auftraggebers und der recipient TPSU-title der TPSU-title des Auftragnehmers.

openUTM unterstützt den in einer ISO-Norm definierten Application Entity Title (AET). Er wird dann benötigt, wenn mit Transaktionssicherung (Commit Functional Unit) gearbeitet wird, oder aber ein heterogener Partner einen AET für den Verbindungsaufbau erwartet. In openUTM wird der AET zusätzlich angegeben, für die Adressierung des Partners hat er keine Bedeutung.

Für jeden fernen Partner, mit dem die UTM-Anwendung über das OSI TP-Protokoll kommunizieren will, muss der Application Context definiert werden, der bei der Kommunikation mit diesem Partner verwendet werden soll.

Die OSI-Begriffe Application Entity Title und Application Context werden in den beiden folgenden Abschnitten etwas ausführlicher beschrieben.

Application Entity Title (AET)

In der OSI-Welt werden die Kommunikationspartner durch Anwendungsinstanzen (Application Entities) repräsentiert. Eine Anwendungsinstanz ist eine adressierbare Einheit in Schicht 7 des OSI-Referenzmodells (Anwendungsschicht). Eine solche Anwendungsinstanz ist z.B. der Zugriffspunkt (Access Point) einer UTM-Anwendung, über den sich ein OSI TP-Kommunikationspartner an die UTM-Anwendung binden kann. In der OSI TP-Norm wird jeder Anwendungsinstanz ein Application Entity Title zugeordnet, über den die Anwendungsinstanz im OSI-Netz eindeutig adressierbar ist.

In der ISO-Norm sind zwei Formen des AET definiert, die Directory-Form und die Object-Identifier-Form. openUTM unterstützt die Object-Identifier-Form des AET. Er wird dann benötigt, wenn mit Transaktionssicherung (Commit Functional Unit) gearbeitet wird, oder wenn ein heterogener Partner einen AET für den Verbindungsaufbau erwartet. Bei homogener UTM-UTM-Kommunikation wird der AET zusätzlich angegeben, für die Adressierung des Partners hat er keine Bedeutung. Ein AET besteht aus zwei Teilen:

• Application Process Title (APT)

• Application Entity Qualifier (AEQ)

Application Process Titel (APT)

Der APT wird zur Kennzeichnung der Anwendung verwendet. Der APT sollte gemäß der ISO-Norm global, d.h. weltweit eindeutig sein. Aus diesem Grund sollte er von einem Standardisierungsgremium vergeben und registriert werden, z.B. in Deutschland von der deutschen Gesellschaft für Warenkennzeichnung GmbH (DGWK).

Ein APT in Object-Identifier-Form besteht aus maximal 10 Komponenten:

(komponente1,komponente2,...,komponente10)

Die Werte für komponente1 bis komponente10 sind bereits teilweise standardisiert. Hierbei wurde einigen Zahlen ein symbolischer Name zugeordnet. Der Wertebereich für kkomponente2 hängt vom Wert für komponente1 ab. In der folgenden Tabelle sind die von openUTM unterstützten symbolischen Namen und die Wertebereiche dargestellt:

komponente1	0:CCITT	1:ISO	2:JOINT-ISO-CCITT
komponente2	0:RECOMMENDATION 1:QUESTION 2:ADMINISTRATION 3:NETWORK-OPERATOR	0:STANDARD 1:REGISTRATION-AUTHORITY 2:MEMBER-BODY 3:IDENTIFIED-ORGANIZATION
	erlaubte Werte: 0 - 39	erlaubte Werte: 0 - 39	erlaubte Werte: 0 - 67 108 863
komponente3 bis komponente10	erlaubte Werte: 0 - 67 108 863	erlaubte Werte: 0 - 67 108 863	erlaubte Werte: 0 - 67 108 863

Der APT, den Sie bei openUTM angeben, muss nicht von einem Standardisierungsgremium vergeben werden, d.h. Sie können den APT selbst vergeben. Er muss die beiden folgenden Anforderungen erfüllen:

• er muss innerhalb des Netzes eindeutig sein

• aus Werten bestehen, die gemäß der obigen Tabelle zulässig sind 

Application Entity Qualifier (AEQ)

Der AEQ identifiziert einen Zugriffspunkt innerhalb einer Anwendung. Den Zugriffspunkten einer Anwendung können Sie nur dann AEQs zuordnen, wenn Sie der Anwendung selbst einen APT zugeordnet haben.

Der AEQ ist eine positive ganze Zahl zwischen 0 und 67 108 863.

Denselben AEQ dürfen Sie innerhalb einer Anwendung nicht mehrfach verwenden, d.h. in einer Anwendung dürfen nie zwei Zugriffspunkte mit demselben AEQ existieren. Sie müssen jedoch nicht allen Zugriffspunkten in einer Anwendung einen AEQ zuordnen.

Bei parallelen Associations wird beim Verbindungsaufbau geprüft, ob der AEQ derselbe ist wie bei der ersten aufgebauten Association.

Application Context

Mit jeder Partner-Anwendung, mit der Ihre lokale Anwendung über das OSI TP-Protokoll kommuniziert, muss der Application Context abgestimmt werden, der bei der Kommunikation verwendet werden soll.

Der Application Context muss für jede Partner-Anwendung explizit festgelegt werden. Der Application Context legt die Regeln fest, nach denen die Nachrichten zwischen der lokalen Anwendung und der Partner-Anwendung übertragen werden. openUTM unterstützt die folgenden vordefinierten Application Contexts:

• UDTAC

• UDTDISAC

• XATMIAC

• UDTCCR

• UDTSEC

• XATMICCR

Wenn Sie nicht einen der oben aufgeführten Standard-Application Contexts verwenden, können Sie weitere Application Contexts mit der Anweisung APPLICATION CONTEXT im Abschnitt "APPLICATION-CONTEXT - Application Context definieren" generieren.

Für einen Application Context vereinbaren alle beteiligten Partner Folgendes:

• Eine Abstrakte Syntax, die festlegt, wie die Benutzerdaten für die Übertragung codiert werden. openUTM unterstützt standardmäßig die folgenden Abstrakten Syntaxen:

  • UDT (Unstructured Data Transfer)

  • XATMI

  • CCR

  • UTMSEC

  Sehen Sie dazu auch die Anweisung ABSTRACT-SYNTAX im Abschnitt "ABSTRACT-SYNTAX - Abstrakte Syntax definieren".

• Eine Transfersyntax (Transfer Syntax), die festlegt, in welcher Form die Benutzerdaten übertragen werden. openUTM unterstützt standardmäßig die Transfersyntax Basic Encoding Rules (BER).

  Sehen Sie dazu auch die Anweisung TRANSFER-SYNTAX im Abschnitt "TRANSFER-SYNTAX - Transfersyntax definieren".

Beide Kommunikationspartner müssen dieselben Abstrakten Syntaxen als Application Context für die Kommunikation generieren. Wenn der generierte Application Context nicht mit dem im Partner generierten Application Context übereinstimmt, lehnt openUTM den Aufbau der Association mit einer entsprechenden Meldung ab.

Die Anweisungen ABSTRACT-SYNTAX, TRANSFER-SYNTAX und APPLICATION-CONTEXT werden nur benötigt, wenn Sie keinen der Standard-Application Contexts verwenden, die openUTM zur Verfügung stellt.