DE3810576A1 - Eingebettetes pruefsystem fuer das pruefen der uebereinstimmung von kommunikationssystemen - Google Patents

Description

Die Erfindung betrifft ein Verfahren zum Prüfen der Übereinstimmung einer Implementierung eines Internet- Protokolls in einem zu prüfenden System auf seine Spezifikation.

Allgemein befaßt sich die Erfindung mit der Prüfung der Software von Kommunikationssystemen. Speziell betrifft die Erfindung ein Verfahren, mit dem festgestellt werden kann, ob ein Kommunikationsschema mit einer Spezifikation von Kommunikationsprotokollen übereinstimmt, beispielsweise mit der MAP-Spezifikation, und zwar auf der Basis des Modells offener Systeme (Open Systems Model), welches von der ISO (International Organization for Standardization) entwickelt wurde.

Viele Fertigungsprozesse werden heute durch vernetzte Rechnersysteme gesteuert, die miteinander kommunizieren müssen. Im Interesse der Standardisierung haben die Automobilindustrie und andere Fertigungsbranchen eine Spezifikation von Kommunikationsprotokollen vorgeschlagen, welche dazu verwendet werden, Rechnersysteme und Roboter­ systeme derart miteinander zu verbinden, daß sie miteinander kommunizieren, d. h. in einen Informationsaustausch treten können. Eine dieser Spezifikationen ist die MAP-Spezi­ fikation. Die MAP-Spezifikation basiert auf einem Modell einer Rechnerkommunikation, welches von der ISO entwickelt wurde und als Open Systems Modell bezeichnet wird. Das Open Systems Modell (und die MAP-Spezifikation) unterteilen das Kommunikationsproblem auf sieben Sätze von verknüpften Einheiten, welche Schichten genannt werden, deren Funktion weiter unten näher erläutert wird.

Um die Kompatibilität mit den vorhandenen Rechen- und Automatisierungseinrichtungen eines Herstellers zu gewähr­ leisten, müssen Hersteller und Verkäufer der neuen Aus­ richtungen eine kompatible Kommunikationssoftware entwickeln. Die neuen Einrichtungen müssen dabei der MAP-Spezifikation entsprechen.

Die MAP-Spezifikation und das Open Systems Modell, auf dem sie basiert, sind als vergleichsweise komplexe Kommunikations­ protokolle anzusehen. Das Prüfen eines neuen Kommunikations­ programms oder einer neuen Einheit der Kommunikationshardware zum Feststellen der Übereinstimmung mit der MAP-Spezifikation ist keine einfache Aufgabe. Wie weiter unten näher erläutert, war es bisher zur Prüfung aller Schichten des Kommunikations­ systems auf Übereinstimmung erforderlich, für das neue Produkt (Software oder Hardware) ein neues Prüfprogramm zu schreiben und dieses direkt in die Kommunikationssoftware einzubauen. Dies macht die Software komplizierter und teurer. Außerdem wird das Kommunikationssystem mit zusätzlicher, spezieller Software belastet, die nicht mehr benötigt wird, sobald die Übereinstimmung festgestellt ist. Möglicherweise nocht störender ist die Tatsache, daß die Prüf-Unterprogramme dieser Prüfsoftware bisher eng mit den speziellen Schichten innerhalb der MAP-Spezifikation verknüpft sind. Diese enge Verknüpfung macht es sehr schwierig, gewisse Funktionen (im Informationsaustausch) zwischen benachbarten Schichten zu realisieren bzw. zu integrieren, ohne dabei in Konflikt mit den Prüfprogrammen zu geraten.

Die vorliegende Erfindung überwindet dieses Problem durch ein Verfahren, bei dem die Informationsfluß-Steuermechanismen in einer höheren Schicht manipuliert werden, um zum Zwecke der Prüfung der Übereinstimmung die Aussendung von Nach­ richten und deren Empfang in einer niedrigeren Schicht zu steuern. Die Erfindung ermöglicht ferner die Prüfung eines neuen Produkts ohne die Notwendigkeit, einige der bisher erforderlichen speziellen Testfunktionen in die neue Produktsoftware zu integrieren. Die Erfindung ermöglicht damit ein Prüfen der Übereinstimmung, ohne daß es dabei zu Störungen des Datenaustauschs zwischen benachbarten Schichten der zu prüfenden, d. h. der im Test befindlichen Software käme. Die Erfindung gestattet somit, daß die Kommunikationssoftware integrierte oder verknüpfte, benach­ barte Schichten verwendet, wie z. B. Verknüpfungen zwischen der Netzwerkschicht und der Transportschicht, um die Leistungsfähigkeit der Software zu verbessern.

Speziell liegt der Erfindung die Aufgabe zugrunde, ein verbessertes Verfahren zur Prüfung der Übereinstimmung neuer Teile des Kommunikationssystems mit den bereits vorhandenen Teilen desselben zu schaffen und dabei auf die Notwendigkeit des Einsatzes umfangreicher, zusätzlicher Prüfsoftware zu verzichten.

Diese Aufgabe wird bei dem erfindungsgemäßen Verfahren dadurch gelöst, daß die Signalfluß-Steuer- und/oder Quittungsmechanismen des Transportprotokolls dazu verwendet werden, die Internet (IP)-Protokolleinheit des zu prüfenden Systems zu steuern.

Im einzelnen gestattet die Erfindung die Durchführung der Prüfung der Protokollübereinstimmung an der Netzwerk­ schicht der zu prüfenden Protokollimplementation (IUT= implementation under test). Es wird also die Internet- Protokolleinheit des zu untersuchenden Systems geprüft, ohne daß an der Netwerkschicht/Transportschicht-Grenz­ fläche (zwischen der Netzwerkschicht und der Transport­ schicht) des Produktes Änderungen herbeigeführt würden oder eine spezielle Testsoftware zum Einsatz käme. Gemäß der Erfindung erfolgt indirekt eine Steuerung des Informationsflusses im Bereich der Netzwerk/Transport- Schnittstelle des neuen Produktes, um festzustellen, ob die Netzwerkschicht der zu prüfenden, neu realisierten Einheit Daten in der korrekten Weise von der Transport­ schicht empfängt und zu dieser weiterleitet. Erfindungs­ gemäß erfolgt die Prüfung des Netzwerkschichtprotokolls ohne ein "Eindringen" in das System. Erfindungsgemäß wird der Informationsfluß durch die Transportschicht gesteuert, um auf diese Weise indirekt die Netzwerkserviceschnittstelle durch den Transport zu steuern, und zwar indem indirekt die Kontrolle über den Kredit, d. h. die zulässige Zahl der zu übermittelnden Dateneinheiten und die Quittungssignale übernommen wird, die von der Transportschicht automatisch und periodisch erzeugt werden. Letztlich betrifft die Erfindung damit ein Kommunikationssystem, bei dem neu integrierte Software- und/oder Hardware-Einheiten indirekt überprüft werden, indem die normalen Systemfunktionen auf eine korrekte Durchführung überwacht werden.

Weitere Einzelheiten und Vorteile der Erfindung sind Gegenstand der Ansprüche und werden nachstehend anhand von Zeichnungen noch näher erläutert. Es zeigt:

Fig. 1 ein Blockdiagramm mit den sieben Schichten eines Kommunikationssystemprotokolls;

Fig. 2 ein schematisches Blockdiagramm zur Erläuterung des physikalischen Kommunikationsaufbaus bei einem derzeit bevorzugten Kommunikationssystem;

Fig. 3 ein Blockdiagramm für ein Zwischensystem bzw. einen Router zum Übertragen von Nachrichten zwischen nicht-benachbarten Knoten;

Fig. 4 ein Nachrichten-Sequenzdiagramm zur Erläuterung des Informationflusses bei der Übertragung und Quittierung einer Nachricht zwischen einer sendenden und einer empfangenden Einheit;

Fig. 5 eine schematische Darstellung zur Erläuterung des Fensterprinzips, nach dem die Transport­ schicht des Kommunikationssystems arbeitet, um den Informationsfluß zu regulieren;

Fig. 6 ein Blockdiagramm eines bevorzugten Prüfprogramms gemäß der Erfindung zur Erläuterung der Art und Weise, in der ein beispielhaftes Kommunikations­ systemprogramm geprüft wird;

Fig. 7 eine schematische Darstellung der Form der Protokolldateneinheiten auf der Ebene jeder der sieben Schichten und

Fig. 8 mit den Teilfiguren 8a und 8b ein Flußdiagramm zur weiteren Erläuterung des erfindungsgemäßen Prüfverfahrens oder, mit anderen Worten, eine Darstellung der Funktion eines erfindungsgemäßen Rechnersystems.

Vor einer detaillierten Erläuterung der Erfindung soll zu­ nächst ein kurzer Überblick über die MAP-Spezifikation gegeben werden. Die MAP-Spezifikation ist in der Firmen­ druckschrift "Manufacturing Automation Protocol Version 2.1", 1985, der Firma General Motors Corporation beschrieben. Die MAP-Spezifikation basiert auf dem OSI (Open Systems Interconnection)-Modell der ISO (International Organisation for Standardization). Eine detaillierte Erläuterung des OSI-Modells findet sich in der ISO-Veröffentlichung ISO IS 7498 "Information Systems Processing - Open Systems Interconnection - Basic Reference Model", 1984. Auf den Inhalt dieser Druckschrift wird hiermit ausdrücklich Bezug genommen.

Fig. 1 zeigt schematisch die sieben Schichten, in die das MAP-Kommunikationsprotokoll unterteilt ist. Auf der untersten bzw. einfachsten Ebene liegt die erste Ebene oder Schicht, nämlich die sogenannte physikalische Schicht. Die physi­ kalische Schicht ist für das Kodieren und das physikalische Übertragen von Nachrichten zwischen zwei benachbarten Knoten des Netzwerks verantwortlich. Gemäß dem MAP-(Protokoll)- Standard wird eine Bus-Topologie verwendet, wie sie in Fig. 2 gezeigt ist. Die physikalische Schicht entspricht dem IEEE 802.4-Standard. Die Kommunikation erfolgt über ein Koaxialkabel 10, welches zwei Kommunikationskanäle bereit­ stellt. Einer dieser Kommunikations- bzw. Übertragungskanäle ist ein niederfrequenter Kanal, auf dem die Datenübertragung auf einer ersten Richtung erfolgt, während der andere Kanal ein Hochfrequenzkanal ist, auf dem die Datenübertragung in entgegengesetzter Richtung erfolgt. Eine Kopfeinheit 12 schließt das eine Ende des Kabels ab, um niederfrequente Übertragungen auf die hohe Frequenz umzusetzen und damit die Übertragungseinrichtung zu ändern. Verschiedene Kommunikations­ einheiten 14 übermitteln auf der Niederfrequenzebene Nachrichten auf das Koaxialkabel 10, über welches die Nachrichten bzw. Daten zu der Kopfeinheit 12 wandern, von wo sie mit hoher Frequenz zurückübertragen werden. Alle Kommunikationseinheiten empfangen ihre Daten mit der hohen Frequenz.

Wie Fig. 1 zeigt, befindet sich unmittelbar über der physikalischen Schicht die zweite Ebene bzw. Schicht, nämlich die Datensicherungsschicht. Diese Datensicherungs­ schicht ist dafür verantwortlich, daß die von der physika­ lischen Schicht gehandhabten binären Daten in Datenrahmen zu Oktetten (acht Bits) zusammengefaßt werden. In der Datensicherungsschicht werden mehrere Oktette zu Daten­ paketen gruppiert. Ferner ordnet die Datensicherungsschicht jedem Paket eine Zuordnungsadresse zu, welche festlegt, welche Kommunikationseinheit 14 bzw. welcher Knoten das Datenpaket empfangen soll. Dabei ist die Datensicherungs­ schicht lediglich für das Adressieren von Daten zuständig, die für Einrichtungen bestimmt sind, die physikalisch mit dem Koaxialkabel verbunden sind. Zum Übertragen einer Nach­ richt zu einem nicht-benachbarten Knoten (einem Knoten, der nicht physikalisch mit dem Koaxialkabel verbunden ist) wird eine Zwischensystemeinheit bzw. ein sogenannter Router verwendet.

Die dritte Ebene bzw. Schicht, nämlich die Netzwerkschicht, sorgt netzübergreifend für das Finden und Steuern des Weges für eine Information über Zwischensysteme oder Router. Die Netzwerkschicht erstellt das Protokoll für die Übertragung von Nachrichten von einem Knoten auf einem Kabel zu einem Knoten auf einem anderen davon physikalisch getrennten Kabel. Fig. 3 zeigt ein Zwischensystem bzw. einen Router 16, welches bzw. welcher ein erstes Kommunikationssystem 18, dessen Bausteine über ein Koaxialkabel 10 miteinander in Verbindung stehen, mit einem zweiten Kommunikationssystem 20 verbindet, dessen Bausteine über ein Faseroptikkabel 22 verbunden sind. Das Zwischensystem 16 umfaßt zwei physikalische Schichten 24 und 26, die mit dem Koaxialkabelprotokoll bzw. dem Faser­ optikprotokoll kompatibel sind. Datensicherungsschichten 28 bzw. 30 sprechen auf die physikalischen Schichten 24 bzw. 26 an und kommunizieren ihrerseits mit einer Netzwerkschicht 32 des Zwischensystems. Letztlich kann die Netzwerkschicht 32 des Zwischensystems 16 als Brücke zwischen den betreffenden Netzwerkschichten des ersten und des zweiten Kommunikations­ systems 18 bzw. 20 angesehen werden. Auf diese Weise ist es möglich, Verbindungen zwischen zwei nicht benachbarten Knoten zu schaffen, die mit ähnlichen oder nicht-ähnlichen physikalischen Protokollen arbeiten.

In der Theorie kann die Netzwerkschicht den Empfängerknoten für eine gegebene Nachricht nach einer Anzahl unterschiedlicher Schemata bestimmen. Ein Schema ist dabei das ver­ bindungsorientierte Protokoll, gemäß welchem zwischen zwei Einrichtungen eine permanente virtuelle Verbindung (Pipe) geschaffen wird. Beim Arbeiten nach einem solchen Protokoll ist es nicht erforderlich, die zu übertragende Nachricht mit einer Signatur zu versehen. Es ist auch nicht erforderlich, der Nachricht irgendeine Leitinformation zuzusetzen, da die permanente virtuelle Verbindung automatisch die Identität sowohl des Senders oder Initiators als auch des Empfängers beschreibt. Ein anderes Protokoll ist das verbindungsfrei orientierte Protokoll (connectionless oriented protocol). Das verbindungsfrei orientierte Protokoll macht es erforderlich, daß die Nachricht eine Adresse und eine Signatur um­ faßt oder davon begleitet ist, um den gewünschten Empfänger der Nachricht und außerdem den Sender der Nachricht zu identifizieren. Das verbindungsfrei orientierte Protokoll garantiert, anders als das verbindungsorientierte Protokoll, nicht daß Nachrichten in einer bestimmten Ordnung über­ tragen werden. Die MAP-Spezifikation arbeitet derzeit mit dem verbindungsfreien Protokoll. Dieses verbindungsfreie Protokoll wird üblicherweise als Internet- bzw. IP-Protokoll bezeichnet.

Da das IP-Protokoll nicht garantiert, daß die Nachrichten in der Reihenfolge empfangen werden, in der si ausgesendet wurden, müssen einige Vorkehrungen getroffen werden, um eine zuverlässige Ausgabe und Behandlung von Nachrichten zu gewährleisten. Gemäß Fig. 1 sorgt die vierte Ebene bzw. Schicht, nämlich die Transportschicht, dafür, daß die Nachrichten bzw. Daten korrekt an das gewünschte Ziel übertragen werden. Die MAP-Spezifikation arbeitet nach einem positiven Quittierungsverfahren bzw. mit positiver Quittierung, bei der der Empfänger einer Nachricht den Empfang bestätigt, indem er an den Sender der Nachricht ein Quittungssignal (ACK) zurücksendet. Die Einzelheiten dieses Quittierungssystems werden weiter unten erläutert.

Die Transportschicht dient außerdem der Steuerung des Datenflusses. Unter der Steuerung des Datenflusses ist dabei der Prozeß zu verstehen, der gewährleistet, daß die Ge­ schwindigkeit der Datenübertragungen für die beiden daran beteiligten Einheiten angemessen ist. Wenn beispielsweise eine Verbindung zwischen einem schnellen Hauptrechner und einem langsamen Personalcomputer hergestellt werden muß, dann müssen gewisse Vorkehrungen getroffen werden, um eine Arbeits-Kommunikationsgeschwindigkeit einzustellen. Dies erfolgt im Rahmen einer Abstimmung bzw. von "Verhandlungen" zwischen den beiden kommunizierenden Einheiten, und zwar speziell zwischen den Transportschichten der beiden kommunizierenden Einheiten. Die beiden kommunizierenden Systeme treffen außerdem vor dem Beginn der Übertragung eine Übereinkunft über die maximale Länge der Nachricht (bzw. der Protokolldateneinheit, PDU). Wenn dann der Austausch von Nachrichten fortschreitet, kann jede Kommunikationseinheit Steuerparameter senden, um die Geschwindigkeit der PDU-Übertragung zu steuern.

Der Mechanismus, durch den die Übertragungsgeschwindigkeit gesteuert wird, basiert auf der PDU-Sequenznummer. Jede PDU wird mit einer charakteristischen Sequenzidentifikationsnummer versehen, so daß die Sequenznummern verwendet werden können, um die Datenpakete in die richtige Reihenfolge zu bringen, falls sie in einen ungeordneten Zustand gebracht worden sein sollten. Wenn die Kommunikation eingeleitet wird, übermittelt jede Kommunikationseinheit der jeweils anderen die Sequenzzahl, die der Maximalzahl von PDUs entspricht, zu deren Empfang sie bereit ist. Der Datenaustausch erfolgt im Vollduplex-Betrieb, wobei jede Seite zu der anderen PDUs bis zur maximalen Sequenzzahl übertragen kann, die ihr von der anderen Einheit mitgeteilt wurde.

Ein einfaches Beispiel: Wenn beide Einheiten eine Kommunikation einleiten und die Einheit A bereit ist, drei PDUs zu empfangen, sendet die Einheit A die Zahl 3 zu der Einheit B. Wenn die Einheit A dann mehr als drei PDUs senden möchte, wird die Sequenzzahl auf den neuen Wert 6 gebracht. Die Einheit B könnte gleichzeitig ihre eigene gewünschte Kommunikations­ rate mit der Einheit A festlegen. Die Einheit B könnte die Einheit A zunächst informieren, daß sie bereit ist, PDUs bis zu und einschließlich der Sequenznummer 10 zu akzeptieren. Nachdem diese zehn Einheiten empfangen sind, könnte die Einheit B weitere zehn anfordern, und zwar durch Ändern der Sequenznummer auf die Zahl 20, oder sie könnte die Rate verlangsamen oder beschleunigen, und zwar durch Wahl einer niedrigeren oder höheren Sequenznummer. Die ursprünglichen Sequenznummern werden während einer Verbindungsaufbauphase der Kommunikation festgelegt. Anschließend werden die Sequenznummern als Teil des Quittungssignals ACK aktualisiert, welches von dem Empfänger zum Sender übermittelt wird.

Um das System gegen ein Hängenbleiben zu schützen, wie es eintreten würde, wenn beide Kommunikationseinheiten jeweils auf ein Quittungssignal der anderen warten würden, werden die Transportschichteinheiten in jeder Einheit so ausgebildet oder aufgefordert, routinemäßig zusätzliche Quittungs­ signale zu senden, die über die laufende Zahl noch zusätzlicher Datenbotschaften informieren, die empfangen werden können. Diese Zulässigkeitsinformation wird als ein Fenster bezeichnet.

Zum besseren Verständnis des positiven Quittiersystems, welches nach der MAP-Spezifikation realisiert ist, wird auf Fig. 4 verwiesen, welche ein Beispiel für eine Kommunikation bzw. Datenübertragung zwischen einem Sender und einem Empfänger zeigt. Dabei ist zu bedenken, daß die MAP-Spezifikation ein im Vollduplex-Betrieb arbeitendes Kommunikations­ system implementiert, bei dem beide Kommunikationseinheiten gleichzeitig als Sender und Empfänger arbeiten können. Im einzelnen zeigt Fig. 4 zwei Spalten mit den Überschriften Sender bzw. Empfänger. In diesen Spalten ist die Reihenfolge von Datenübertragungen dargestellt, wobei die eingezeichneten Pfeile die Richtung der Übertragung anzeigen. Die Kommunikation bzw. Datenübertragung beginnt mit einer Sequenz zum Herstellen der Verbindung. Diese Sequenz der Datenübertragung ist mit dem Bezugszeichen 40 bezeichnet. Die Sequenz beginnt bei 42 damit, daß der Sender an den Empfänger eine Anforderung CR für eine Verbindung sendet (connection request=CR). Der Empfänger antwortet durch Senden des Verbindungsbestätigungs­ signals CC (connection confirmation=CC). Der Sender bestätigt dann den Empfang des Signals CC durch Aussenden einer Quittung ACK. Während dieser Verbindungsaufbauphase spezi­ fizieren sowohl der Sender wie auch der Empfänger die minimale und maximale Sequenznummer, zu deren Empfang sie bereit sind, nämlich das Fenster. Zur Erläuterung werden nur die Daten dargestellt, die von der ersten Einheit ein­ geleitet und von der zweiten Einheit empfangen werden. Es versteht sich, daß sich ein ähnliches Diagramm ergeben würde, wenn die von der zweiten Einheit zum Empfang durch die erste Einheit eingeleiteten Übertragungen dargestellt werden sollten.

Wenn die Verbindung erstmals hergestellt wird, wird davon ausgegangen, daß die Kommunikation mit der Sequenznummer 0 beginnt (die erste Nachricht der Transportbenutzerinformation). Die höchste zulässige Sequenznummer, die durch den Empfänger vorgegeben wird, bestimmt zusammen mit der anfänglichen Sequenznummer 0 die Zahl der Nachrichten, welche zum Empfänger übertragen werden können. Diese Zahl kann bequemerweise als ein Fenster dargestellt werden, welches in Fig. 5 als ein Fenster dargestellt ist, welches zwischen der letzten Sequenzanfrage (im vorliegenden Fall die Anfangssequenz 0) und der höchsten zulässigen Sequenznummer, die angefordert wurde, begrenzt ist. Wenn der Empfänger beispielsweise den Empfang auf 100 Nachrichten begrenzen möchte, dann würde die untere Kante 44 des Fensters anfänglich bei der Sequenz­ nummer 0 liegen, während die obere Kante 46 bei der Sequenz­ nummer 100 liegen würde.

Wie Fig. 4 zeigt, beginnt nach der Herstellung der Verbindung - Bezugszeichen 40 - der Sender mit der Datenübertragung von PDUs (DT). Zum Zwecke der Erläuterung wird angenommen, daß der Empfänger die Sendung von drei Nachrichten (PDUs) ver­ langt hat. Folglich übermittelt der Sender die ersten drei Nachrichten, die den Sequenznummern 0, 1 und 2 entsprechen.

Diese Phase ist mit dem Bezugszeichen 48 bezeichnet. Wenn der Empfänger die dritte Sequenz empfängt, sendet er ein Quittungssignal ACK zurück an den Sender. Dies ist bei 50 angedeutet. Das Quittungssignal enthält die Sequenz­ nummer der höchsten empfangenen Sequenz, in diesem Fall die Nachricht 2. Somit weiß der Sender, daß der Empfänger alle drei Pakete empfangen hat. Wenn es erwünscht wäre, könnte der Empfänger zusammen mit dem Quittungssignal seine Fenster­ größe durch Anforderung einer zusätzlichen Gruppe von Paketen ändern, so daß sich ein Unterschied zu der ursprünglich angeforderten Zahl ergeben würde. Beispielsweise kann der Empfänger wünschen, die Übertragung von bis zu zehn Nach­ richten zu ermöglichen. In diesem Fall würde der Empfänger seine Zahl für die höchste zulässige Sequenznummer auf 13 ändern. Wenn der Empfänger die höchste zulässige Sequenz­ nummer nicht ändert, dann bleibt es bei dem ursprünglich gewählten Wert von 3 und es können keine weiteren Sequenzen übertragen werden.

Nimmt man an, daß mehr Sequenzen angefordert wurden, dann würde der Sender fortfahren, Nachrichten auszusenden und würde erwarten, danach Quittungssignale zu empfangen. Dies ist für die Nachrichten 3 und 4 bei 52 gezeigt. Es ist natürlich möglich, daß eine bestimmt Nachricht nicht in der richtigen Folge empfangen wurde. Ein bestimmtes Paket kann zeitweilig verzögert werden oder bei der Übertragung ver­ loren gehen. Bei 54 sendet der Sender die Botschaften 5 und 6. Der Empfänger quittiert nur die Botschaft Nummer 5, um den Fall anzuzeigen, in dem die Botschaft Nummer 6 nicht in der Reihenfolge empfangen wird. Inzwischen fährt der Sender fort, die Botschaften 7 und 8 zu senden, wie dies bei 56 ange­ deutet ist. Der Empfänger kann jedoch den Empfang der Bot­ schaften Nummer 6, 7 und 8 nicht quittieren, da er die Botschaft Nummer 5 noch nicht quittiert hat.

Gemäß dem Standardbetrieb des Transportschichtprotokolls wird der Empfänger aufgefordert, periodisch ein Quittungs­ signal zu senden, welches die letzte Sequenznummer wider­ spiegelt, welche er empfangen hat. Im vorliegenden Fall hat der Empfänger die Botschaft Nummer 5 noch empfangen. Folg­ lich sendet der Empfänger bei Schritt 58 ein periodisches Quittungssignal über den Empfang der Botschaft Nummer 5. Der Sender erkennt aus diesem Quittungssignal, daß der Empfänger die Botschaft Nummer 6, welche bereits früher übertragen wurde (bei 54) noch nicht empfangen hat.

Folglich sendet der Sender erneut die Botschaft Nummer 6 - bei 60 -, und der Empfänger antwortet dann mit einer Quittung für die Botschaft Nummer 8. In diesem Beispiel wurde angenommen, daß nur die Botschaft Nummer 6 von dem Empfänger nicht empfangen wurde, und daß die Botschaften Nummer 7 und 8 empfangen wurden und bis zum Empfang der Botschaft Nummer 5 gespeichert wurden.

Für das Verständnis der Erfindung ist es wichtig zu erkennen, daß sich das Fenster, welches durch eine Oberkante und eine Unterkante begrenzt ist, wie dies in Fig. 5 gezeigt ist, in seiner Größe bei jeder Quittung ändern kann. Die Unter­ kante 44 des Fensters zeigt, welche Sequenznummer zuletzt quittiert wurde, während die Oberkante 46 des Fensters zeigt, wie groß die maximal zulässige Anzahl von Sequenzen ist. Die vorliegende Erfindung befaßt sich in erster Linie mit der Steuerung des Datenflusses zwischen den Netzwerk­ einheiten auf der Ebene 3 unter Verwendung des Transport­ schichtmechanismus auf der Ebene 4. Der Vollständigkeit halber soll aber nachstehend noch eine kurze Beschreibung der fünften bis siebten Schicht des Systems erfolgen.

Die fünfte Schicht, nämlich die Sessions- oder Sitzungs­ schicht (vgl. Fig. 1), dient in erster Linie dazu, die Kommunikationseinheiten derart zu synchronisieren, daß sie bei der Durchführung einer Kommunikation in der richtigen Reihenfolge arbeiten. Die Sitzungsschicht ist grob gesagt der Interpunktion analog, welche einen kompletten Gedanken unterbricht und eine andere Botschaft, möglicherweise von der anderen Einheit, als Antwort ermöglicht.

Die sechste Schicht, nämlich die Darstellungsschicht, ist für die Handhabung der Datendarstellung zwischen den Kommunikationseinheiten verantwortlich. Die Kommunikations­ einheiten können nicht unter Verwendung ähnlich kodierter Sprachen oder ähnlicher Dateitypen kommunizieren. Die Dar­ stellungsschicht sorgt für eine vereinbarte gemeinsame Sprache, eine vereinbarte Kodierung oder einen vereinbarten Dateityp, um auf dieser Basis eine Kommunikation zwischen zwei inkompatiblen Systemen zu ermöglichen. Die Darstellungs­ schicht kann ferner eine Datenkodierung und -dekodierung zum Zwecke einer Datenverschlüsselung oder dergleichen durchführen. Obwohl das OSI-Modell den kommunizierenden Systemen das Aus­ handeln eines Protokolls auf dieser Ebene ermöglicht, wird bei der derzeit realisierten MAP-Spezifikation kein solches Aushandeln angewandt.

Die letzte und siebte Schicht ist die Anwendungsschicht. Die Anwendungsschicht definiert für jeweils einen bestimmten Kontext, welche Sprache während der Kommunikation zu ver­ wenden ist. Der Kontext kann entweder implizit auf der Grund­ lage der Art der Kommunikation gegeben sein oder explizit festgestelt werden. Die Anwendungsschicht wird benötigt, da die übertragenen Daten von verschiedenen Rechnersystemen in fundamental unterschiedlicher Weise organisiert sein können.

Die Anwendungsschicht definiert eine untereinander vereinbarte Art der Bezugnahme auf die Dinge. Von den kommunizierenden Einheiten muß mindestens eine ihre Daten in das vereinbarte Format übersetzen, wenn ein solches Format nicht von vornherein vorgesehen ist.

Wie oben ausgeführt, befaßt sich die vorliegende Erfindung in erster Linie mit der Prüfung der Übereinstimmung der Internet-Protokolleinheit eines zu prüfenden Systems in der Netzwerkschicht. Das Ziel besteht darin, sowohl gültige als auch ungültige Daten zu der Netzwerkschichteinheit zu übertragen, um zu bestimmen, ob diese zwischen den beiden Arten von Daten korrekt unterscheidet. Ein weiteres Ziel besteht darin, die Netzwerkschicht zu veranlassen, Daten fehlerfrei zu der darüber befindlichen Transportschicht zu übertragen und von dort zu empfangen. Die Netzwerkschicht ist insofern "verbindungsfrei" als sie nicht mit verbindungs­ orientierten Protokollen arbeitet, wie dies bei einigen der oberen Schichten der Fall ist. Vor der vorliegenden Verbindung war es zur Prüfung der Nezwerkschicht erforder­ lich, in die Transportschicht des zu prüfenden Systems (oder an der Schnittstelle zwischen Netzwerkschicht und Transportschicht) ein spezielles Prüfprogramm einzugeben, um vorab definierte Prüfdaten über die Transport-Netzwerk­ schnittstelle zu der Netzwerkschicht zu schicken, um fest­ zustellen, ob die Netzwerkschicht dieselben richtig empfängt. Ferner muß das Prüfprogramm auf vorab definierte Prüfdaten reagieren, welche von der Netzwerkschicht über die Transport/Netzwerk-Schnittstelle übertragen werden, um fest­ zustellen, ob die Netzwerkschicht Daten bzw. Nachrichten richtig weiterleitet. Die zusätzliche Verwendung dieser Prüfsoftware erhöht die Komplexität des Kommunikationssystems und macht es schwierig, Hochleistungssoftware zu entwickeln, welche möglicherweise gewisse eng verwandte Funktionen der Transportschicht und der Netzwerkschicht integrieren muß.

Nachdem vorstehend ein allgemeiner Überblick über die Erfindung und deren derzeit bevorzugte Arbeitsumgebung gegeben wurde, soll nachstehend eine detaillierte Er­ läuterung des erfindungsgemäßen "eingebetteten" Test­ systems erfolgen.

Gemäß der Erfindung wird von einem "eingebetteten" Testsystem bzw. einem eingebetteten Verfahren gesprochen, da die Netz­ werkserviceschnittstelle in dem zu untersuchenden System natürlicherweise mit der Transportschicht gekoppelt bleiben kann. Das übliche Testverfahren, bei dem die Netzwerkservice­ schnittstelle von der Transportschicht entkoppelt und in dem zu untersuchenden System mit spezieller Software betrieben werden muß, wird dagegen als "freigelegtes" Prüfsystem bzw. -verfahren bezeichnet. Gemäß der Erfindung wird als Basis für die Realisierung des erfindungsgemäßen Konzepts die Software verwendet, welche entwickelt wurde, um das Test­ verfahren mit freigelegter Schnittstelle durchzuführen. Weiterhin kann nach dem erfindungsgemäßen Verfahren derselbe Satz von Prüfbedingungen durchgeführt werden, wie bei dem Testsystem mit freigelegter Schnittstelle. Die Wahl des Verfahrens bzw. der Technik wird dem Gestalter des zu testenden Systems überlassen. Mit anderen Worten arbeitet das "eingebettete" Testsystem unter Verwendung der existierenden "freigelegten"-Internet-Testsystemsoftware als Ausgangsbasis für seine Realisierung. Tatsächlich wird nur ein Prüfsystem aufrechterhalten, wobei es einen Benutzer­ befehl gibt, um zu wählen, ob eine eingebettete oder eine freigelegte Servicesteuerung verfügbar ist.

Bei der "freigelegten"-Version wird weiterhin das von der NBS definierte Testmanagementprotokoll Data Units (TMPDU) benutzt sowie der zugehörige Upper Tester zur Steuerung der IUT-Serviceschnittstelle. Eine Beschreibung des TM (Testmanagement)-Protokolls findet sich in der Druck­ schrift ICST/SNA-85-7, "The Design of a Test System for Implementations of ISO Connectionless Network Protocol", Juli 1985 (NBS 86) des National Bureau of Standards, USA.

Fig. 8 zeigt das derzeit bevorzugte Verfahren der Realisierung des "eingebetteten" Testsystems gemäß der Erfindung. Die Sequenz beginnt mit dem Startschritt 100 und fährt mit dem Aufbau der verbindungsorientierten Kommunikation zwischen der Testsystemsoftware und dem zu prüfenden System fort - Schritt 102. Der Rest der in dem Flußdiagramm gemäß Fig. 8 gezeigten Testsequenz umfaßt eine Anzahl von Verzweigungs­ punkten (Schritte 104, 110, 120, 122, 128, 136 und 144), wo bestimmte Tests bzw. Prüfungen durchgeführt werden.

Wenn es beispielsweise erwünscht ist, den Internet-Protokoll (IP)-Datentransmitter zu prüfen, erfolgt die Verzweigung bei 104, um die Schritte 106 und 108 durchzuführen. Gemäß Schritt 106 wird eine vorab definierte Einheit von Daten, die mit NSDU bezeichnet ist und eine Information AK-TPDU enthält mit einem "Kredit" ausgesendet, der um eins größer ist als die vorherige Sequenzzahl. Hierdurch wird das "Kredit"-Fenster geöffnet, welches die Rückübertragung einer Dateneinheit von dem zu untersuchenden System ermöglicht. Bei der Durchführung dieser Prüfung würde das untersuchte System normalerweise vorab so konditioniert, daß es eine große Anzahl von Oktetten von Daten sendet und deren Empfang erwartet. Durch Öffnen des Kreditfensters mit einem Kredit bzw. einer Vorgabe der bzw. die um eins größer ist als die frühere Sequenz kann eines der Vielzahl von Datenoktetten aus dem zu untersuchenden System in das Prüf­ system fließen. Beim Schritt 108 setzt das Testsystem eine Flagge, daß es darauf wartet, eine DT-TPDU mit einer um eins größeren Folge als zuvor zu empfangen.

Wenn es erwünscht ist, den IP-Datenempfänger zu prüfen, dann erfolgt bei Schritt 110 eine Verzweigung zu dem Schritt 112, gemäß welchem eine NSDU gesendet wird, welche ein DP-TPDU mit einer Sequenznummer enthält, die um eins größer ist als die vorherige. Gemäß Schritt 114 wird eine Entscheidung ge­ troffen, ob die IPDUs, welche die NSPDs tragen, zu ändern sind oder nicht. Wenn eine Änderung erfolgt, muß eine Flagge gesetzt werden, die dem Prüfsystem sagt, daß eine Fehler­ meldung ER-IPDU oder keine Antwort zu erwarten ist (Block 116). Wenn die Daten nicht geändert werden (nein) wird eine Flagge gesetzt, die dem Prüfsystem sagt, daß eine Quittie­ rungsnachricht AK-TPDU mit einer Sequenznummer zu erwarten ist, die um eins größer ist als zuvor (Block 118).

Wie oben erläutert, fordert das MAP-Kommunikationsprotokoll die periodische Aussendung von Duplikaten von Quittungs­ signalen, um einen Schutz gegen ein Hängenbleiben des Systems zu gewährleisten. Diese Duplikate von Quittungssignalen werden am Verzweigungspunkt 120 abgefangen. Wenn ein Duplikat eines Quittungssignals empfangen wird, wird von dem Prüfsystem keine Aktion eingeleitet und die Durchfluß­ steuerung kehrt einfach an den Anfang der Schleife zurück.

Um zu prüfen, ob die Quittungsfolge empfangen wurde, für die die Flagge gemäß Schritt 118 gesetzt wurde, wird gemäß Schritt 122 der Empfang der erwarteten Quittung überwacht und es erfolgt eine Verzweigung zum Schritt 124, wenn die Quittung empfangen wird. Gemäß Schritt 124 wird die Quittung geprüft, um fest­ zustellen, ob sie aufgrund der Prüfung des Senders empfangen wurde. Wenn dies der Fall ist, wird kein Fehler gemeldet. Andernfalls wird gemäß Schritt 126 ein Fehler gemeldet.

Eine ähnliche Prüfung wird gemäß Schritt 128 durchgeführt, um festzustellen, ob die DT-TPDU empfangen wurde, für die die Flagge bei Schritt 108 gesetzt wurde. Wenn dies der Fall ist, wird gemäß Schritt 130 geprüft, ob dies aufgrund eines Empfängertests geschehen ist. Wenn dies der Fall ist, wird gemäß Schritt 132 ein Quittungssignal AK-TPDU gesendet. Andernfalls wird gemäß Schritt 134 eine Fehlerbedingung signalisiert.

In ähnlicher Weise wird gemäß Schritt 136 eine Prüfung durch­ geführt, um festzustellen, ob die erwartete Fehlermeldung, für die die Flagge gemäß Schritt 116 gesetzt wurde, empfangen wird. Wenn dies der Fall ist, wird eine Entscheidung getroffen, ob dieses Fehlersignal ER-IPDU in Abhängigkeit von einem Empfängertest erhalten wurde. Wenn dies der Fall ist, wird ein Duplikat DT-TPDU gesendet. Andernfalls wird gemäß Schritt 142 eine Fehlerbedingung signalisiert.

Schließlich erfolgt dann, wenn irgendwelche andere Nicht- DT- oder Nicht-ER-IPDUs empfangen werden oder wenn irgend­ welche unvollständig zusammengesetzten DT-IPDUs empfangen werden, eine Verzweigung der Steuerung gemäß Schritt 144, um gemäß Schritt 146 einen Fehler zu signalisieren. Gemäß Schritt 148 erfolgt eine Entscheidung, ob die Prüfung beendet werden soll oder ob für die weitere Prüfung eine Rückkehr zum Anfang der Schleife erfolgen soll. Wenn die Prüfung endet, wird die Verbindung gemäß Schritt 150 unterbrochen, worauf­ hin das Prüfprogramm mit dem Schritt 152 endet.

Die eingebettete Version verwendet die Standardtransport­ protokoll Data Units (TPDU) und das MAP-Protokoll 2.1 ent­ sprechend der Transport Entity für die IUT-Netzwerkservice­ schnittstellensteuerung. Die IUT-Transporteinheit ist ihrer­ seits durch den Remote Scenario Interpreter gesteuert, der bei der Transportprüfung verwendet wird. Lediglich ein Transportscenario (Prüffall) wird zur Verwendung in der eingebetteten IT-Prüfung benötigt. Folglich ist kein direkter Zugriff zu der IUT-Netzwerkserviceschnittstelle erforderlich.

Die kontrollierte Verwendung des MAP/ISO-Klasse 4-Transport­ protokolls bei der eingebetteten Prüfung sorgt für dieselbe Funktionalität bei der Prüfung und Beobachtung der Netzwerk­ serviceschnittstellenaktivtät wie das übliche Protokoll, was für das Verfahren mit freigelegter Schnittstelle benötigt wird. (Es gibt kleinere Ausnahmen, aber die verlorene TM- Funktionalität ist nicht erforderlich, um damit zu beginnen.) Während der Internet-Protokoll-(IP)-Testfalldurchführung werden nur DT-TPDUs und AK-TPDUs in den IPDU-Datenteilen transportiert. Die Herstellung der Transportverbindung und deren Beendigung werden außerhalb der Durchführung eines IP-Testfalles durchgeführt.

Die Verbindungsherstellung wird durch Erzeugung eines Befehls "Verbinden" eingeleitet. Es wird ein CR-CC-AK-TPDU- Datenaustausch erwartet. Das Testsystem fährt für eine vernünftige Zeit fort, CR-Signale zu übertragen, ehe es aufgibt. IP-Testfälle werden nur durchgeführt, wenn ange­ nommen wird, daß eine Verbindung offen ist.

Die Transport-Timer- und Parameter-Werte werden durch CR- CC-Verhandlung definiert oder vorab in dem eingebetteten IP-Testplan definiert. Es wird davon ausgegangen, daß sie denjenigen Werten ähnlich sind, die bei den derzeit üblichen Transportprotokoll-Übereinstimmungstests verwendet werden.

Gültige IPDU-Daten, welche von dem unteren Tester gesendet werden, sind DT-TPDUs in der richtigen Reihenfolge mit einem Datenformat, welches die Erwartung des Remote Scenario Interpreters beachtet. Der Remote Scenario Interpreter (RSI) ist derselbe, der bei der Standard-Transportprotokoll-Prüfung verwendet wird. IPDU-Daten, die in ungültigen IPDUs gesendet werden, werden auch als DT-TPDUs in korrekter Reihenfolge gesendet. Wenn die ungültige IPDU angenommen wird, dann signalisiert das Pulssystem einen Fehler. Wenn eine korrekte Fehlerantwort empfangen wird, dann wird die Prüfung als "in Ordnung" fortgesetzt. Um eine korrekte Transportnachricht­ folge aufrechtzuerhalten, wird die DT-TPDU in einer gültigen IPDU zurückübertragen, nachdem die korrekte Fehlerantwort empfangen ist.

Eine AK-TPDU mit richtig erhöhter unterer Fensterkante wird in Antwort auf ein DT-TPDU, welches in einer gültigen IPDU transportiert wird, erwartet.

Um zu verhindern, daß die IUT-Transporteinheit vorzeitig DT-TPDUs sendet, liefern die AK-TPDUs, die von dem Test­ system gesendet werden, keinen "Kredit". Wenn eine NSDU (Netzwerk-Service-Dateneinheit, d. h. eine DT-TPDU mit korrekter Folge) von der IUT gewünscht wird, dann wird eine AK-TPDU, die den Kredit um eins erhöht, von dem unteren Tester gesendet. Wenn der untere Tester eine gültige NSDU, d. h. eine gültige DT-TPDU, empfängt, wird das Fenster wieder geschlossen und die DT-TPDU quittiert. Diese AK-TPDU, die "Kredit gewährt", spezifiziert nicht die NSDU-Größe. Eine solche Spezifizierung erscheint nicht wünschenswert, da sie versuchen würde, einen implementations­ spezifischen Parameter zu steuern. Folglich ist für die Testzwecke die AK-Einheit mit Kredit ausreichend. Zu beachten ist, daß erwartet wird, daß die DT-TPDU-Daten von der IUT dem korrekten Remote Scenario Interpreter-Format folgen.

Sowohl der untere Tester als auch die IUT müssen periodisch eine AK-TPDU übertragen, um das Transportfenster-Zeiter­ fordernis zu erfüllen. Dies ermöglicht beiden Parteien gegenseitig ihr fortdauernde Funktionsfähigkeit zu er­ kennen.

Eingebettete Servicesteuerung und -beobachtung

Das in der Betriebsart "freigelegt" arbeitende System arbeitet mit einem Übereinstimmungseintrag, um allen erwarteten IPDUs von der IUT zu folgen. Diese Tabelle ist in geeigneter Weise gefüllt, wenn das Testsystem eine IPDU sendet und der Tabelleneintrag wird nach Empfang einer befriedigenden IPDU entfernt.

Bei der eingebetteten Betriebsart wird die Tabelle bei Verbindungs- und Trennprozessen nicht verwendet. Für Ver­ bindungs/Trenn-Prozesse wird nur die Transportverbindungs­ kontextdatenstruktur überprüft.

Während der IP-Testfallausführung werden sowohl die Einträge der Übereinstimmungstabelle und der Transportkontext ver­ wendet. Da während der IP-Testfallausführung nur DT-TPDUs und AK-TPDUs verwendet werden, ist dies eine direkte Lösung. Das Testsystem arbeitet nach den folgenden Regeln:

• 1. Es wird eine DT-TPDU empfangen: Wenn die DT zu der Folge gehört, liegt sie in dem offenen Fenster, der Datenteil ist korrekt formatiert und ein Übereinstimmungseintrag, der durch eine AK-TPDU mit Kredit erzeugt wird, wurde gesendet, und dieser Eintrag wird aufgelöst. Die "Tctx" wird aufdatiert und von dem unteren Tester wird eine AK- TPDU gesendet.
• 2. Eine AK-TPDU mit Duplikatsequenznummer wird empfangen: Aufdatieren des "Tctx" in geeigneter Weise.
• 3. Eine AK-TPDU mit größerer Sequenznummer wird empfangen: Wenn ein Eintrag "gültige Daten IPDU"-Typ-Übereinstimmung vorhanden ist und eine fehlende DT-TPDU übertragen wurde, dann wird der Eintrag aufgelöst und die "Tctx" aufdatiert.
• 4. Es wird eine DT-TPDU innerhalb einer IPDU mit gültigen Daten gesendet: Gemäß dem Prüffall ist eine "gute" DT-IPDU mit der Größe von n Datenoktetten zu senden. Ein Überein­ stimmungseintrag von Typ "Valid Data IPDU" wird erzeugt und die IPDU wird gesendet.
• 5. Eine DT-TPDU wird innerhalb einer IPDU mit ungültigen Daten gesendet: Es muß eine "schlechte" DT-IPDU mit n-Oktetten von Daten gesendet werden und es wird eine Fehlerreport- Flagge auf "ein" gesetzt, und zwar in Übereinstimmung mit dem Testfall. Es wird ein Übereinstimmungseintrag von Typ "Valid Data IPDU" erzeugt und die IPDU wird gesendet.
• 6. Eine AK-TPDU mit Duplikat-Sequenznummer wird gesendet: Das "Tctx" zeigt an, daß der Window timer abgelaufen ist.
• 7. Eine AK-TPDU mit Duplikat-Sequenznummer und Kredit wird gesendet: Es wird eine NSDU mit einer DT-TPDU mit korrekter Folge erwartet. Es wird ein Übereinstimmungseintrag gemacht und die Daten IPDU mit AK-TPDU wird gesendet.
• 8. Es wird eine AK-TPDU mit größerer Sequenznummer gesendet: Ein "Valid Data IPDU"-Eintrag wurde aufgelöst und eine Daten-IPDU wird gesendet.
• 9. Es wird eine ER-IPDU empfangen: Wenn ein "Error-IPDU"-Über­ einstimmungseintrag existiert, dann wird der Eintrag auf­ gelöst.

Integration mit der derzeitigen Internet-Software

Die Funktionalität des eingebetteten Tests wird in einer solchen Weise in die vorhandene Software integriert, daß die Änderungen isoliert und klar strukturiert sind. Es wird ein Überblick über die Software-Struktur für das freigelegte System gegeben, dem sich die Änderungen anschließen, die gemacht werden, um das eingebettete System zu unterstützen.

Die Software für das freigelegte System ist als kontinuierlicher Schleifenprozeß strukturiert. Die Modifikationen bzw. Ände­ rungen zur Unterstützung des eingebetteten Systems arbeiten innerhalb dieser Struktur. Der folgende Pseudo-Kode beschreibt das Dual-Modisystem. Anweisungen, bei denen es sich um Zusätze handelt, sind mit der Markierung "*A" versehen; Modifikationen sind mit der Markierung "*M" versehen.

Es sind folgende Modifikationen zur Unterstützung des eingebetteten Systems vorgesehen:

• 1. Die globale Datenstruktur "Tctx" liefert die erforderlichen Daten zur Unterstützung der Operation der Transport­ verbindung. Dies umfaßt die Variablen, die erforderlich sind, um die Daten für den Remote Scenario Interpreter zu erzeugen und zu analysieren.
• 2. Die IPDU-Daten, die zum Zeitpunkt der Bildung der abstrakten IPDU erzeugt werden, werden durch eine "gen-data()" genannte Funktion geliefert. Diese Funktion wird modifiziert, um im eingebetteten Modus die geeigneten DT-TPDUs zu erzeugen. Es sind kleinere Modifkationen an der Logik zum Erzeugen der Übereinstimmungseinträge erforderlich.
• 3. IPDUs werden erzeugt, um die IUT aufzufordern, Daten zu senden. Der Datenteil solcher IPDUs trägt im freigelegten Modus "Sende-NSDU"-TMPDUs. Diese TMPDUs werden zum Zeit­ punkt der Bildung der abstrakten IPDU durch die Funktion "nsdu-daten()" generiert. Diese Funkton wird für den eingebetteten Modus dahingehend modifiziert, daß AK-TPDUs mit Kredit(en) generiert werden. Kleinere Modifikationen der Logik zum Erzeugen der Übereinstimmungseinträge sind ebenfalls erforderlich.
• 4. Die empfangenen Datenteile der IPDUs werden im freigelegten Modus durch mehrere verschiedene Unterprogramme analysiert. Diese Unterprogramme werden in Abhängigkeit davon ausge­ führt, ob die Daten als eine TMPDU oder einfach als sequentielle Daten identifiziert wurden. Die Unterprogramme werden entweder über die Funktion "Empfänger()" oder die Funktion "reassembler()" aufgerufen.
• 5. Im eingebetteten Modus wird lediglich ein einziges Unter­ programm "scan-data()" aufgerufen. Dieses Unterprogramm wird aus dem Programm "reassembler()" heraus aufgerufen. Alle IPDU-Datenteile werden durch das Programm "reassembler()" gleitet, und zwar unabhängig davon, ob eine Wiederzusammensetzung erforderlich ist oder nicht. (Dies ist auch die derzeitige Praxis für den freigelegten Modus). Das Unterprogramm "scan-data()" wird für die Durchführung der PDU vom Transporttyp modifiziert. Bei empfangenen DTs wird davon ausgegangen, daß sie in dem zulässigen Fenster liegen. Bei empfangenen AKs wird davon ausgegangen, daß sie lediglich ausstehende DTs bestätigen oder Duplikate zum Zwecke der Aufrechterhaltung der Ver­ bindung sind. Die "scan-data()"-Funktion liefert eine Zählung der erfaßten Fehler und "reassembler()" druckt eine Nachricht, welche anzeigt, ob Kodier- oder Längenfehler vor­ liegen.
• 6. Die Steuerung der Transportverbindung erfolgt durch das Unterprogramm "Transport()". Dieses Unterprogramm wird in die ständig durchlaufene Schleife aufgerufen, nachdem eine Verarbeitung in Abhängigkeit von den Befehlen des Benutzers gefordert wurde. Befehle des Benutzers zum Herstellen und Trennen und zum Schließen (von Dateien) setzen, wenn sie gültig sind, "Tctx"-Variable, die anzeigen, daß die ge­ wünschte Funktion durchgeführt wurde. Das Unterprogramm "Transport()" sendet alle erforderlichen konkreten IPDUs direkt. Empfangene IPDUs werden innerhalb des Programms "reassembler()" von dem Unterprogramm "scan-data()" ver­ arbeitet. Die Prüfung gemäß "scan-data()" basiert auf den Indikatoren "Tctx".

Übereinstimmungsanalyse

Der vorhandene Ablauf für die Übereinstimmungsanalyse wird nahezu unmodifiziert für den eingebetteten Modus verwendet. Die Änderungen bestehen darin, daß erstens die Sequenznummer­ variable in jedem Übereinstimmungseintrag so eingestellt wird, daß sie mit der Transport-PDU-Aktivität korreliert ist und zweitens darin, daß es für einen Eintrag erforderlich sein kann, mehr als eine Antwort aufzulösen. Dies setzt voraus, daß irgendwelche Fehler in dem Übereinstimmungs­ analyseprogramm noch nicht korrigiert wurden.

Fehler in der Transportschicht werden durch Fehlermeldungen an die Operatorkonsole gemeldet. Der Operator muß daraufhin entscheiden, ob eine derartige Fehlermeldung eine inkonse­ quente Aktivität, eine fehlende Prüfbarkeit oder eine fehlende Übereinstimmung anzeigt.

Verwendung der Transportverbindung

Die Herstellung der Transportverbindung wird stets durch das Prüfsystem eingeleitet. Die LT schlägt für die meisten Ab­ sprachen "low-bids" vor und läßt der IUT keine Wahl. Diese "bids" sind: Prüfsumme ein, normales Format, und keine transportierten Daten. Als maximale TPDU-Größe wird ein Wert von 512 Oktetten vorgeschlagen.

Dieser Größenwert wird gewählt, um die derzeit bestehenden Hardware-Beschränkungen des Prüfsystems zu unterstützen. Die IUT kann diesen Wert herunterhandeln. Unabhängig von der ausgehandelten maximalen Größe sendet das Prüfsystem niemals eine IPDU, deren Größe die maximale Nachrichtengröße in dem Prüfsystem überschreitet (derzeit 600 Oktetten). Der derzeitige Satz von IP-Testfällen macht es nicht erforderlich, daß eine NSDU von mehr als 512 Oktetten von dem Prüf­ system gesendet oder empfangen wird. Das Prüfsystem leitet auch die Trennung ein, wenn von der Konsole ein entsprechender Befehl eingeht.

Jede übertragene AK trägt den Steuerbestätigungsparameter (fcc). Der Empfang von nackten (parameterlosen) AKs führt zu einer Rückübertragung der letzten AK.

Datenstrukturen

Die folgende Datenstruktur wird verwendet, um den Transportkontext aufrechtzuerhalten.

struct TCCNTEXT Tctx

int state;/* major state */ int TCref;/* LT reference number */ int RTref;/* IUT reference number */ int sizebid;/* maximum negotiated tpdu size */ int send seq;/* sending sequence number */ int send ssq;/* sending subsequence number */ int send cdt;/* sending credit */ int recv seq;/* receiving sequence number */ int recv ssq;/* receiving subsequence number */ int recv cdt;/* receiving credit */ int window time;/* window timer value */ int inact time;/* inactivity timer value */ int giveup time;/* giveup timer value */ int retran time;/* retransmission timer value */ int retran count;/* retransmission count */ intr cr len;/* cr pdu length */ int ak len;/* ak pdu length */ int dt hlen;/* dt pdu header length */ int dt tlen;/* dt pdu total length */ int dr len;/* dr pdu length */ int dc len;/* dc pdu length */ int ip hlen;/* ipdu header length */ int ip dui;/* next dui to use */ unsigned char crpdu [512];/* cr tpdu for sending */ unsigned char akpdu [512];/* ak tpdu for sending */ unsigned char dtpdu [512];/* dt tpdu for sending */ unsigned char drpdu [512];/* dr tpdu for sending */ unsigned char dcpdu [512];/* dc tpdu for sending */ unsigned char ippdu [700];/* data ipdu for sending */ long send count;/* count of transport data sent */ long send goal;/* total amount of data to be sent */ long recv count;/* count of transport data received */ long recv goal;/* total amount of data to be received */ int akstat;/* classification of ak type */ int send dtseq;/* sequence number of last dt sent */ int send akseq;/* sequence number of last ak sent */ int send ect;/* ect sent */ int recv ect;/* ect received */ int timebase;/* time at program initialization */ int send time;/* time last data transmitted */ int recv time;/* time last data received */ int send vector;/* vector indicating next pdu to send */ int reason;/* disconnect reason */ int dest;/* out-of-context pdu dest */ int src;/* out-of-context pdu src */ int TCsent roll;/* count of dt sent sequence number rollover */ int TCack roll;/* count of ak sent sequence number rollover */ int RTsent roll;/* count of dt recv sequence number rollover */ int RTack roll;/* count of ak recv sequence number rollover */ char *fault;/* pointer to pdu error */ struct DTREG DTreg [10];/* registers to buffer sent, but unacked dts */ struct INPDU *pduptr;/* pointer to received pdu */

Aufrechterhalten der Verbindung

Transport-TPDUs werden zum Senden zu zwei Zwecken gebildet. Sie werden entweder benötigt, um den IPDU-Datenteil zu bilden, der durch einen IP-Testfall definiert ist, oder sie werden benötigt, um eine Transportverbindung aufzubauen, aufrechtzuerhalten oder zu beenden.

Die TPDUs, die für die IP-Testfallunterstützung verwendet werden, werden zum Zeitpunkt der Bildung der abstrakten IPDU erzeugt. In ihrem Aufbau beziehen sich diese TPDUs (nur DTs oder AKs) auf die "Tctx"-Struktur für geeignete Werte.

TPDUs, die zum Aufrechterhalten einer Verbindung ausgesandt werden, werden direkt gesendet (die normalen Sende-Warteschlangen werden umgangen). Diese TPDUs werden nach der Verarbeitung von Konsolenbefehlen gesendet. Der IPDU-Kopf wird vorab mit dem DUI (Data Unit Identifier) definiert und der Segmentlängenindikator, der Gesamtlängen­ indikator und die Kopf-Prüfsumme werden in geeigneter Weise modifiziert. All diese Informationen finden sich in "Tctx". Die DUI-Werte beginnen bei (dezimal) 1000, um nicht in Konflikt mit den IP-Testfall-DUIs zu geraten. Die IP-Testfälle müssen sich weigern, IPDUs mit DUI-Werten von mehr als 1000 zu definieren, um einen möglichen Kon­ flikt zu vermeiden. Das alle derzeitigen IP-Testfälle DUIs benutzen, die bei (dezimal) 1 beginnen (oder für die Prüfung von inaktiven Untersätzen überhaupt keine DUI) können die für Steuerzwecke verwendeten IPDUs leicht von den zu prüfenden IPDUs unterschieden werden.

Alle empfangen IPDUs (beide Modi) sind über die Funktion "scan-data()" zugänglich. Im freigelegten Modus werden die IPDU und ihre Daten während der Reassamblierung ausgewertet und die Datenstruktur "Segmt" des Typs "REASM-SEG" wird geschaffen, um die zutreffende Information über das Segment aufrechtzuerhalten. Der Puffer, in dem das tat­ sächliche Segment gespeichert ist, wird dann freigegeben. Der Reassamblierungsprozeß hält eine verknüpfte Liste von "Segmt"-Strukturen zur Verwendung bei der Reassamblierung aufrecht.

Der Datentyp "REASM-SEG" wird modifiziert, um den einge­ betteten Modus zu unterstützen, indem zusätzliche rele­ vante Information für die TPDUs aufrechterhalten wird. Diese umfaßt teilweise reassamblierte IPDUs.

Wenn die IPDU-Daten gemäß den Transportprotokollregeln und den Zielen des Scenario Interpreters gültig sind, dann muß lediglich der Übereinstimmungseintrag erfüllt sein. Dieser Eintrag ist erfüllt, wenn die Sequenznummer der ankommenden DT oder AK mit derjenigen des Überein­ stimmungseintrags korreliert ist.

Ankommende AK-Duplikate setzen einfach die Inaktivitätszeit zurück und werden verworfen. Wenn das Duplikat "nackt" ist, wird in "Tctx" eine Flagge gesetzt, die anzeigt, daß eine AK zu übertragen ist. Alle übertragenen AKs enthalten den fcc-Parameter. Alle anderen, außerhalb der Reihenfolge liegenden DTs und AKs werden als Fehler identifiziert. Die Übertragung der TPDU wird durch Flaggen getriggert, welche in "Tctx" gesetzt sind. In der Hauptschleife wird unmittelbar nach der Prüfung, ob Konsolenbefehle vorliegen, die Funktion "Transport()" aufgerufen. Wenn Flaggen ge­ setzt sind, dann wird eine geeignete IPDU gesendet. Der Mechanismus wird zum Senden aller TPDUs mit Ausnahme von solchen DTs und AKs verwendet, welche während eines IP-Testfalles als IPDU-Daten benötigt werden.

Schablonen-TPDUs werden in der "Tctx"-Struktur aufrecht­ erhalten. Eine solche TPDU wird in einen Puffer kopiert, welcher einen IPDU-Kopf enthält und die entsprechenden Parameter werden in dem IPDU-Kopf und der TPDU modifiziert. Dieser (Puffer(inhalt)) wird dann dem Schreibprogramm der Einrichtung zugeführt, wobei die Warteschlange umgangen wird, die für die IPDUs verwendet wird, die durch die IP-Testfälle erzeugt werden.

Das Unterprogramm "Transport()" sendet TPDUs, die zur Unterstützung eines Benutzerbefehls (Verbinden-Schließen- Trennen) einer AK oder einer gültigen DT und zur Befriedigung des Standardtransporttimers benötigt werden und schließt ein Fenster (welches zuvor aufgrund einer durch einen IP-Testfall erzeugten AK zulässig war).

Claims (5)

1. Verfahren zum Prüfen der Übereinstimmung einer Implementierung eines Internet-Protokolls in einem zu prüfenden System auf seine Spezifikation, dadurch gekennzeichnet, daß die Signalfluß-Steuer- und/oder Quittungsmechanismen des Transportprotokolls dazu verwendet werden, die Internet (IP)-Protokolleinheit des zu prüfenden Systems zu steuern.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Signalfluß-Steuer- und Quittungsmechanismen dazu verwendet werden, eine kontrollierte Prüfumgebung auf­ rechtzuerhalten.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Signalfluß-Steuermechanismen die Menge von Nachrichten angeben, deren Übertragung von der Internet-Protokoll­ einheit in dem zu prüfenden System erwartet wird.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Quittungsmechanismus dazu verwendet wird zu bestimmen, ob die Internet-Protokolleinheit in dem zu prüfenden System die Daten korrekt empfängt und an eine höhere Benutzerebene des zu prüfenden Systems liefert.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Signalfluß-Steuermechanismus dazu verwendet wird, ein Fenster für zulässige Übertragungen in der Internet- Protokolleinheit in dem zu prüfenden System zu definieren.