DE3853022T2

DE3853022T2 - Verfahren zur Ausbreitung von Netzwerkzustandsnachrichten.

Info

Publication number: DE3853022T2
Application number: DE3853022T
Authority: DE
Inventors: Alan Edward Baratz; John Ellis Drake; James Peyton Gray; George Allan Grover; Melinda Ross Pollard; Diane Phylis Pozefsky; Lee Mark Rafalow
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-06-15
Filing date: 1988-04-12
Publication date: 1995-08-10
Anticipated expiration: 2008-04-13
Also published as: DE3853022D1; US5109483A; JPH0624376B2; EP0295380A2; EP0295380A3; EP0295380B1; JPH01112839A

Description

Die vorliegende Erfindung betrifft Rechnernetzwerke und insbesondere ein Verfahren zur Ausbreitung des Flusses von Netzwerkstatusinformationen zwischen bestimmten neu definierten Arten von Netzwerkknoten, die neu definierte Fähigkeiten haben.
Die folgende Erläuterung von Begriffen und Gedanken ist gegebenenfalls hilfreich, um die Probleme zu verstehen, die mit der vorliegenden Erfindung gelöst werden. Gedanken und Begriffe, die hier als neu betrachtet werden, sind nachstehend so angegeben. Andere sind in einem oder mehreren dieser veröffentlichten Werke beschrieben: (1) Systems Network Architecture, Concepts And Products, IBM Publication GC30-3072-3, Urheberrecht International Business Machines Corporation, Oktober 1986; (2) Systems Network Architecture, Technical Overview, IBM Publication GC30-3073-2, Urheberrecht International Business Machines Corporation, September 1986; (3) Systems Network Architecture, Transaction Programmer's Reference Manual For LU Type 6.2, IBM Publication GC30-3084-2, Urheberrecht International Business Machines Corporation, November 1985; (4) SNA Format And Protocol Reference Manual: Architecture Logic For Type 2.1 Nodes, IBM Publication SC30-3422-0, Urheberrecht International Business Machines Corporation, Dezember 1986; (5) Systems Network Architecture Reference Summary, IBM Publication GA27-3136-6, Urheberrecht International Business Machines Corporation, Mai 1985; (6) Synchronous Data Link Control Concepts, IBM Publication GA27-3093-3, Urheberrecht International Business Machines Corporation, Juni 1986; (7) Systems Network Architecture Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2, IBM Publication SC30-3269-3, Urheberrecht International Business Machines Corporation, Dezember 1985.
Im allgemeinen umfassen Netzwerke Kommunikationsverbindungen, die innerhalb physischer Medien oder elektromagnetischer Wellenkanäle formiert sind, sowie Geräte, die mit diesen Verbindungen an "Knoten" oder Anschlußstellen gekoppelt sind. Im Unterschied zu Netzwerken, die nur sogenannte "nichtintelligente Datenstationen" an allen Knoten haben, sind Rechnernetzwerke durch das Vorhandensein von Rechnern an manchen der Knoten gekennzeichnet.
Knoten, welche die Übertragung in einem Netzwerk steuern, benötigen bestimmte Informationen in bezug auf physische und logische Kenndaten und Zustände von Verbindungen und Knoten ("Topologie"-Informationen), Netzwerkfehlerzustände und an den Knoten verfügbarer Ressourcen ("Ressourcen-Informationen). Der Begriff "Netzwerkstatus"-Informationen wird hier verwendet, um Informationen zu beschreiben, die unter eine beliebige dieser Kategorien fallen. Verfahren, anhand derer einige dieser Informationen verbreitet oder lokalisiert werden, sind in den vorstehenden, durch Querverweis angegebenen Veröffentlichungen beschrieben.
SNA-Netzwerke klassifizieren Knoten derzeit in vier Arten von Kategorien, 2.0, 2.1, 4 und 5, entsprechend der logischen und/oder physischen Kenndaten von Geräten, die in den Knoten enthalten sind (siehe beispielsweise das vorstehend erwähnte Schriftstück GC30-3073, Seiten 1 bis 20 und 1 bis 21). Zum vorliegenden Zweck wird eine neue Art von Knoten des Typs 2.1 mit der Typbezeichnung APPN definiert, und innerhalb dieser Art werden zwei neue Unterarten von Knoten, Typ NN und EN, definiert. Knoten des Typs APPN, wie vorliegend definiert, sind Knoten, die in der Lage sind, bestimmte Übertragungsoperationen des Typs "advanced peer-to-peer networking" (daher das Akronym "APPN") auszuführen, die nachstehend beschrieben werden. Zu diesen Operationen gehört die Übertragung von Knotenleistungsprofil-Informationen und anderen Netzwerkstatusinformationen in bestimmten neuen Kommunikationsverbindungs- und Sitzungskommunikationsformen, die später beschrieben werden. Knoten des Tpys EN (auch "Endknoten" genannt) befinden sich an logischen Endgrenzen des Netzwerks, in dem Sinn, daß sie keine Informationen zwischen anderen Knoten übertragen und keine Dienste für andere Knoten zur Verfügung stellen. Knoten des Typs NN (auch "Netzwerkknoten" genannt) sind Knoten, die Informationen zwischen anderen Knoten übertragen und Dienste für andere Knoten zur Verfügung stellen können. Endknoten enthalten im allgemeinen Endbenutzergeräte wie beispielsweise Daten-Hosts, die nur Geräte unterstützen, auf die als Netzwerkkomponenten nicht zugegriffen werden kann. Netzwerkknoten enthalten Rechner, die nicht nur Daten verarbeiten, sondern darüber hinaus so ausgelegt sind, daß sie Kommunikationsdienste bereitstellen, die den Zugriff auf Ressourcen an anderen Knoten ermöglichen.
In solchen Netzwerken werden Informationen in verschiedenen Formaten übertragen. Zwei Formen, die hier von Interesse sind, sind die Datenübertragungssteuerungs-Kommunikation und Sitzungen. In bezug auf Sitzungen ist die Datenübertragungssteuerungs-Kommunikation im allgemeinen direkter (nur zwischen direkt verbundenen Knoten), kürzer und weniger umfangreich, was die Menge und die Art der Informationen angeht, die übertragen werden können. Eine Form der Datenübertragungssteuerungs-Kommunikation ist in dem vorstehend erwähnten Schriftstück GA27-3093 ausführlicher beschrieben, und Sitzungen sind in dem vorstehend erwähnten Schriftstück GC30-3073 ausführlicher beschrieben. Ein "Kontrollpunkt" ist eine Knotenkomponente, die Sitzungen mit anderen Knoten aktivieren kann und die Steuerungsdienste und Informationen zur Verfügung stellt, die von anderen Komponenten des entsprechenden Knotens und/oder der entsprechenden Kontrollpunkte an anderen Knoten benötigt werden (siehe beispielsweise Seite 3-3 des vorstehend erwähnten Schriftstücks GC30-3073). Ein APPN-Knoten hat nur einen einzigen Kontrollpunkt.
Von besonderem Interesse sind hier der XID-Datenübertragungssteuerungs-Austausch (siehe Kapitel 2 in dem vorstehend erwähnten Schriftstück GA27-3136) und Sitzungen zwischen Netzwerk-Kontrollpunkten (siehe vorstehend erwähntes Schriftstück GC30-3072, Seite 23). Der XID-Austausch dient zur Feststellung der Kenndaten benachbarter Knoten. Zusammenfassend werden Simplex-Sitzungen hier als eine CP-CP-Sitzung des Typs APPN (oder einfach als eine CP-CP-Sitzung) bezeichnet, und sie dienen dazu, es Transaktionsprogrammen an den Knoten zu ermöglichen, Netzwerkstatusinformationen nach Bedarf und nach Sitzungsverfügbarkeit (jede Sitzung ist für jeweils nur ein Programmpaar verfügbar) auszutauschen.
Logische Einheiten (LUs) verwalten den Informationsfluß zwischen Endbenutzern und dem Netzwerk (vergleiche beispielsweise vorstehend erwähntes Schriftstück GC30-3073-2, Seite 1-11). Endbenutzer kommunizieren nur indirekt über zugeordnete logische Einheiten (LUs) miteinander. Die SNA-Architektur definiert Arten von logischen Einheiten (LUs), welche die Arten 1, 2, 3, 4, 6.1 und 6.2 einschließen, die bestimmte Kommunikationsverantwortlichkeiten haben; wobei die Arten 1, 4, 6.1 und 6.2 die Kommunikation zwischen Programmen unterstützen. Jeder Art von logischer Einheit (LU) ist eine entsprechende Art von Kommunikationsprotokoll zugeordnet (beispielsweise sind LU-6.2-Protokolle der logischen Einheit LU 6.2 zugeordnet).
Transaktionsprogramme (TPs), wie in dem vorstehend erwähnten Schriftstück GC30-3084-2 beschrieben, sind Programme, die LU- 6.2-Einrichtungen verwenden, um mit entsprechenden Partnern (anderen Transaktionsprogrammen) an anderen Knoten zu kommunizieren. Ein Transaktionsprogramm (TP) hat Zugriff auf alle Einrichtungen, die jedem Programm zur Verfügung stehen, das in demselben Knoten ausgeführt wird, und es ist darüber hinaus in der Lage, mit fernen Transaktionsprogramm-(TP-)Partnern zu kommunizieren/"sich auszutauschen". Transaktionsprogramme (TPs), die als Partner kommunizieren oder sich als Partner austauschen sollen, müssen koordiniert geschrieben sein, so daß eine nützliche Kommunikation stattfinden kann.
Rechnernetzwerke zur Verarbeitung und Übertragung von Daten sind natürlich bekannt. In einem typischen solchen Netzwerk können ein oder mehr Rechner, die unter entsprechenden Betriebssystemen und unter entsprechender Anwendungs-/Transaktionssoftware laufen, durch Übertragungssteuereinheiten und Übertragungsmedien in Dialogverkehr treten, um Daten auszutauschen und um Operationen von Endbenutzergeräten wie beispielsweise Druckern, Bildschirmen usw. zu steuern. Darüber hinaus sind auch Rechnernetzwerke bekannt, die zu einer verteilten Steuerung an mehreren aktiven Knoten fähig sind.
Solche Netzwerke werden gewöhnlich entsprechend einer Architektur oder Gruppe von Basisprotokollen gesteuert, die einen ordnungsgemäßen Informationsfluß sowohl zwischen den Knoten als auch zwischen Ressourcen gewährleistet, die an den Knoten unterstützt werden. Beispiele für derartige Architekturen finden sich in: (1) "Computer Network Architecture" von S. Wecker in Computer, September 1979, und (2) "An Introduction To Network Architectures And Protocols" von P.S. Green im IBM Systems Journal, Jahrgang 18, Nr. 2, 1979. In diesen Artikeln sind verschiedene Architekturen, wie beispielsweise SNA, DNA usw., in Form einer Schichtstruktur beschrieben, bei der sich Komponenten, die Funktionen für physisch steuernde Übertragungsmedien steuern, in der untersten Schicht und Komponenten, die Funktionen zur Kommunikation mit Endbenutzern steuern, in der obersten Schicht befinden und bei der andere Funktionen in Zwischenschichten gesteuert werden. In der Systemnetzwerkarchitektur (SNA) sind 7 solche Schichten definiert: physikalische Schicht, Datenübertragungssteuerung, Pfadsteuerung, Übertragungssteuerung, Datenflußsteuerung, Darstellungsdienste und Transaktionsdienste. Bestimmte Funktionen, die in jeder Schicht ausgeführt werden, sind in dem vorstehend erwähnten Schriftstück GC30-3073-2 auf der Seite 1-3 näher beschrieben. Eine von der International Organization For Standardization (ISO) vorgeschlagene Architektur weist eine Struktur mit 7 Schichten auf, wobei die Ebenen verschiedene, aber teilweise überlappende Funktionen in bezug auf die SNA-Hierarchie haben. Das ISO-Modell ist von H. Zimmerman in "OSI Reference Model, The ISO Model Of Architecture For Open Systems Interconnection", IEEE Transactions On Communications, April 1980, beschrieben und durch die folgenden Schichten gekennzeichnet: Physikalische Schicht, Leitungsschicht, Netzwerkschicht, Transportschicht, Sitzungsschicht, Darstellungsschicht und Anwendungsschicht.
Ein Verfahren zur Übertragung von Informationseinheiten in einem Rechnernetzwerk ist in Norstedt, EP-A-0 118 037 mit dem Titel "Computer network system and its use for information unit transmission" beschrieben. Bei diesem Verfahren geht es um eine Technik, die es einer Vielzahl von fernen Datenstationen ermöglicht, eine einzige, mit einem fernen Host aufgebaute Sitzung zu benutzen, aber es beschreibt die Benutzung der Sitzung nicht zum Austausch von Netzwerkstatusinformationen oder Knotenleistungsprofil-Informationen.
In bestehenden SNA-Netzwerken müssen neu aktivierte Knoten vor ihrer Aktivierung zumindest die Arten von Knoten kennen, an die sie angeschlossen werden. Diese Vorbereitung "im voraus" ist nicht nur kostspielig, sondern auch dahingehend einschränkend, daß sie die Installation von technologisch neuen Geräten im Netzwerk begrenzt oder kompliziert.
In bestehenden Netzwerken werden Netzwerkstatusinformationen, anders als Informationen über angeschlossene Verbindungen und über benachbarte Knoten, mittels verschiedener Arten von Sitzungskommunikationen mit unterschiedlicher Form und unterschiedlichem Kontext in Abhängigkeit von der Art des Knotens und anderer Faktoren erfaßt. Daher ist die Programmierung solcher Sitzungen im allgemeinen zeitraubend und schließt eine geringere Wiederverwendung des bestehenden Codes ein als dies der Fall wäre, wenn die Übertragung von Statusinformationen auf eine einzige Art von Sitzungskommunikation standardisiert werden könnte.
Gemäß der vorliegenden Erfindung, wie in den Ansprüchen dargelegt, können neu definierte Knoten des Typs APPN (advanced peerto-peer networking) viele verschiedene bestehende und noch zu konzipierende Geräte umfassen, und sie benötigen vor ihrer Aktivierung ein Minimum an Netzwerkstatusinformationen. Bei der Aktivierung eines beliebigen Knotens werden die an diesen Knoten angeschlossenen Verbindungen aktiviert, die wiederum einen Triggerimpuls an den Knoten senden, damit er über jede Verbindung einen XID-Austausch auslöst, bei dem der auslösende Knoten über die Art des an dem anderen Ende der Verbindung angeschlossenen Knotens informiert wird und bei dem der Knoten an diesem Ende über die Art des auslösenden Knotens informiert wird. Bei einem solchen Austausch geben APPN-Knoten sowohl ihre Fähigkeit an, CP-CP-Sitzungen zu unterstützen, als auch ihre Verfügbarkeit für die Ausführung solcher Sitzungen (Endknoten (ENs) können jeweils nur mit einem Partner eine aktive Sitzung haben und würden daher, wenn sie beim Auftreten eines XID-Austausches eine aktive Sitzung haben, anzeigen, daß sie nicht verfügbar sind).
Wenn es sich bei den Knoten auf beiden Seiten einer neu aktivierten Verbindung um APPN-Knoten handelt, lösen die Informationen, die durch den XID-Austausch bereitgestellt werden, einen Austausch von Sitzungsbindungssignalen aus, die bewirken, daß ein Paar Halbduplex-Sitzungen zwischen den Knoten aufgebaut wird. Bei einem anfänglichen Austausch von Leistungsprofil-Informationen auf diesen Sitzungen erhält jeder Knoten Informationen, die bestimmte Fähigkeiten des anderen Knotens beschreiben. Informationen, welche das Service-Leistungsspektrum der Knoten (Endknoten (EN) oder Netzwerkknoten (NN)) beschreiben, werden in dem XID-Austausch geliefert. Dies ist notwendig, um zu verhindern, daß Endknoten (ENs) CP-CP-Sitzungen untereinander aufbauen.
Nachdem der Leistungsprofil-Austausch beendet ist, führen interne Operationen in dem Knoten zur Kennzeichnung des Paares der Simplexsitzungen als eine CP-CP-Sitzung mit einem in jeweils umgekehrter Richtung steuerbaren Informationsfluß (einem Nur- Senden-Informationsfluß und einem Nur-Empfangen-Informationsfluß). Danach wird die CP-CP-Sitzung Transaktionsprogrammen (TPs) nach Erfordernis zur Verfügung gestellt, damit sie nach Bedarf zusätzliche Statusinformationen austauschen können. Bei solchen Übertragungen weist ein Transaktionsprogramm (TP), das Netzwerkstatusinformationen zu senden hat, die logische Einheit (LU), welche die Übertragung ausführt, an, die zugehörige abgehende Nachricht zu markieren, so daß sie wirklich auf der Nur- Senden-Hälfte der CP-CP-Modus-Gruppe übertragen wird.
Somit können viele Transaktionsprogramme (TPs) an einem Knoten über eine einzige seriell wiederbenutzte CP-CP-Sitzung viele verschiedene Arten von Netzwerkstatusinformationen entsprechend individueller Programmbedürfnisse erfassen und verbreiten, und dies ermöglicht eine effizientere Benutzung von Netzwerkverbindungen und Netzwerkressourcen. In den hier beschriebenen APPN- Knoten arbeitet die logische Einheit (LU), die eine Kommunikation zwischen den Transaktionsprogrammen (TPs) und dem Netzwerk ermöglicht, außerdem entsprechend den LU-6.2-SNA-Übertragungsprotokollen, und dies schließt sowohl Transaktionsprogramme (TPs) ein, die speziell für die Verwendung von Netzwerkstatusinformationen geschrieben wurden, die über eine CP-CP-Sitzung erfaßt oder verbreitet werden müssen, als auch vom Benutzer geschriebene Transaktionsprogramme (TPs), die andere Informationen austauschen, was zu einer noch effizienteren Wiederverwendung der logischen Einheit (LU) führt.
Diese und andere Merkmale, Vorteile und Aufgaben der vorliegenden Erfindung lassen sich besser verstehen und werden deutlicher, wenn man die folgende ausführliche Beschreibung in bezug auf die folgenden Zeichnungen betrachtet, bei denen:
Fig. 1 eine typische, "dem Stand der Technik entsprechende" Konfiguration von Hardware- und Softwarekomponenten in einem SNA- Netzwerk veranschaulicht, das gemäß der früheren SNA-Architektur aufgebaut ist.
Fig. 2 eine Tabelle von dem Stand der Technik entsprechenden Arten von Knoten gemäß der früheren SNA-Architektur ist, die strukturelle und funktionale Kenndaten einer jeden Knotenart angibt.
Fig. 3 schematisch die Beziehung zwischen hier definierten APPN- Knotenarten und den Unterarten NN (Netzwerkknoten) und EN (Endknoten) und ihre Beziehung zu früheren Knoten des Typs 2.1 als Arten einer gemeinsamen Gattung darstellt.
Fig. 4 netzwerktopologische Beziehungen zwischen Knoten des Typs NN (Netzwerkknoten) und des Typs EN (Endknoten) zeigt.
Fig. 5 strukturelle und funktionale Kenndaten von Knoten des Typs APPN angibt.
Fig. 6 die Reihenfolge der Operationen zwischen Knoten nach der Aktivierung der Verbindung zeigt, wobei die Betonung auf Operationen liegt, die zwischen Knoten des Typs APPN ausgeführt werden.
Fig. 7 Einzelheiten des XID-3-Nachrichtenformats zeigt.
Fig. 8 Einzelheiten des CP-LEISTUNGSPROFIL-Nachrichtenformats zeigt.
Fig. 9 das Format von CP-CP-Sitzungsnachrichten zeigt.
Fig. 10 Informationen angibt, die zwischen APPN-EN- und APPN-NN- Knoten in CP-CP-Sitzungen übertragen werden können.
Fig. 11 Informationen angibt, die zwischen APPN-NN-Knoten in CP- CP-Sitzungen übertragen werden können.
Fig. 12 angibt, wie verschiedene unterschiedliche Verbindungsarten überwacht werden können, um Fehlerzustände festzustellen, die Ausfälle von CP-CP-Sitzungen darstellen.
Fig. 13 zeigt, wie festgestellte Fehlerzustände in bezug auf Transaktionsprogramme behandelt werden, die vom Ausfall einer CP-CP-Sitzung betroffen sind.
Fig. 14 veranschaulicht, wie Transaktionsprogramme (TPs) und logische Einheiten (LUs) in Dialogverkehr treten, um CP-CP-Sitzungen zu benutzen und zu steuern.
Die vorliegende Erfindung ist bestrebt, bestehende Netzwerkarchitekturen, insbesondere SNA, zu verbessern, um den Anschluß neuer Hardware- und Softwarekomponenten an bestehende Netzwerke zu vereinfachen. Im allgemeinen enthalten bestehende SNA-Netzwerke, wie in Figur 1 typisiert, viele verschiedene Hardware- und Softwarekomponenten (siehe Figur 2), die verschiedene Protokolle zur Übertragung benötigen und verschiedene Prozesse erfordern, um ihre Einbindung ins Netzwerk vorzubereiten und um ihnen die Kommunikation mit momentan aktiven Elementen zu ermöglichen. Dies macht den Anschluß neuer Arten von Komponenten (Hardware und Software) an bestehende Netzwerke komplizierter und teurer, da solche Anbindungen für gewöhnlich Änderungen an bestehenden Protokollen erfordern, um die bestehenden Komponenten in die Lage zu versetzen, die hinzugekommenen neuen Arten zu erkennen, und gegebenenfalls weitere Änderungen erfordern, wenn die hinzugekommenen neuen Arten über Übertragungsfunktionen verfügen, die mit der bestehenden Architektur nicht kompatibel sind.
Bei der Einführung neuer Komponenten in bestehende Netzwerke ist es auch wünschenswert, sowohl die Kosten für das Informieren dieser Komponenten über die Netzwerkstrukturen und -fähigkeiten als auch die Kosten für das Informieren der bestehenden Komponenten über die Kenndaten der neuen Komponente zu minimieren.
Es ist ferner wünschenswert, bestehende Komponenten in einem größtmöglichen Maße zur Ausführung der Architekturprotokolle nutzen zu können, die zur Kommunikation zwischen neuen Programmen und dem Netzwerk erforderlich sind, wodurch die Kosten für die Assemblierung von Programmen, um zwischen neuen Programmen und dem Netzwerk kommunizieren zu können, minimiert werden.
Die vorliegende Erfindung ist eine Antwort auf das Erkennen dieser Bedürfnisse und sieht eine Grundlage vor, um für eine langfristige Anpaßbarkeit von bestehenden Netzwerken an technologische Fortschritte zu sorgen.
Figur 1, die direkt von der Seite 1-5 des vorstehend erwähnten Schriftstücks GC30-3073-2 übernommen wurde, veranschaulicht die Verschiedenartigkeit von Hardware- und Softwarekomponenten in einem typischen bestehenden SNA-Netzwerk. Jeder Knoten in solch einem Netzwerk ist ein Teil einer Hardwarekomponente, die, zusammen mit den zugehörigen Softwarekomponenten, die Funktionen der vorher erwähnten 7 Architekturschichten ausführt (Seite 1-7 desselben Schriftstücks). Figur 2, die direkt von der Seite 1-21 desselben Schriftstücks übernommen wurde, gibt Typkategorien von Knoten, die in solchen Netzwerken vorkommen, ihre jeweilige Strukturbeschreibung und ihre zugehörigen Hauptfunktionen an.
Diese Figuren zeigen, daß SNA-Netzwerke vor der vorliegenden Erfindung im allgemeinen zwei verschiedene Kategorien von Knoten enthalten haben, Unterbereichsknoten und Peripherieknoten, wobei jeder zwei Arten von Knotenarten enthält; Unterbereichsknoten des Typs 4 und 5 (nachstehend als T4 und T5 bezeichnet) und Peripherieknoten des Typs 2.0 und 2.1 (nachstehend als T2.0 und T2.1 bezeichnet). Jeder Unterbereichsknoten ist einem Unterbereich zugeordnet, der aus dem Knoten und angeschlossenen Peripherieknoten besteht. Unterbereichsknoten sind durch die Arten von physischen Einheiten (PUs) charakterisiert, welche die Verbindungen verwalten, die sie mit benachbarten Knoten verbinden. T5-Knoten unterscheiden sich ferner darin, daß sie eine Systemservice-Kontrollpunkt-(SSCP-)Komponente enthalten, um Netzwerkressourcen entsprechend den Befehlen von Netzwerkbedienern in bezug auf einen zugehörigen Teil des Netzwerks verwalten, der als "Domäne" bezeichnet wird (Seite 1-13 desselben Schriftstücks), und um Sitzungsaktivierungen zwischen logischen Einheiten (LUs) innerhalb dieser Domäne und durch andere Systemservice-Kontrollpunke (SSCPs) domänenübergreifend zu koordinieren. Peripherieknoten wurden immer schon Unterbereichen zugeordnet, wie vorstehend erwähnt wurde, und zeichneten sich sowohl durch direktere Verbindungen mit Endbenutzern als auch durch die Unterstützung von bestimmten Arten von logischen Einheiten (LUs) aus. Es ist jedoch nicht erforderlich, daß T2.1-Knoten in Unterbereichen arbeiten (d.h. sie können unabhängig von Unterbereichsknoten bestehen und arbeiten), Direktverbindungsanschlüsse mit anderen T2.1-Knoten und eine Programm-Programm-Kommunikation unterstützen (durch Unterstützung von LU-6.2-Protokollen; siehe Seite 1-12 desselben Schriftstücks).
Bezug nehmend auf Figur 3 sei erwähnt, daß es bei dem gerade eingeführten Verfahren zur Anpassung darum geht, eine neue Art von T2.1-Knoten zu definieren, der als APPN (für "advanced peer- to-peer networking") bezeichnet wird und zwei Unterarten EN (für "Endknoten") und NN (für "Netzwerkknoten") hat. Diese Knoten unterstützen die Weiterleitung von Nachrichten durch das Netzwerk und befriedigen die vorstehend beschriebenen Bedürfnisse.
Figur 4 zeigt, wie APPN-Knoten in Netzwerken topologisch konfiguriert werden können, und Figur 5 gibt strukturelle Kenndaten und Funktionen solcher Knoten an.
Bezug nehmend auf Figur 4 sei erwähnt, daß jedes der Netzwerke 100 und 101, die durch das Gateway 102 miteinander verbunden sind, mehrere Knoten des Typs APPN enthält und andere Knoten des bislang bestehenden Typs enthalten kann (nicht gezeigt und hier nicht von Interesse). Endknoten (ENs), bei 104 angegeben, befinden sich an logischen Endpunkten des Netzwerks, in dem Sinn, daß sie sich für CP-CP-Kommunikationen nur an Netzwerkknoten (NNs) anschließen lassen, die bei 105 gezeigt sind (für andere Formen von vorher bestehender SNA-Kommunikation, die momentan nicht relevant ist, können sie an andere Arten von Knoten angeschlossen werden), und sie stellen keine Querverbindung zwischen anderen Knoten bereit (d.h. sie nehmen keine Datenübertragung zwischen Knoten vor). Netzwerkknoten (NNs) andererseits lassen sich für eine CP-CP-Kommunikation entweder an Endknoten (ENs) oder an andere Netzwerkknoten (MNs) anschließen, und sie leiten Informationen durch das Netzwerk.
Bezug nehmend auf Figur 5 sei erwähnt, daß alle APPN-Knoten vorher bestehende T2.1-Funktionen und eine vorher bestehende T2.1- Architektur sowie Protokolle zum Aufbau und zur Benutzung von CP-CP-Sitzungen unterstützen. Sie unterstützen auch eine Programm-Programm-Kommunikation über LU-6.2-Protokolle (mehr darüber nachstehend) und haben andere Funktionsfähigkeiten gemeinsam. Sie unterschieden sich darin, daß sich Endknoten (ENs) an logischen Endpunkten des Netzwerks befinden, während sich Netzwerkknoten (NNs) an logisch dazwischenliegenden Stellen befinden, Endknoten (ENs) nur eine CP-CP-Sitzung mit einem Partner unterstützen können, während Netzwerkknoten (NNs) CP-CP-Sitzungen mit mehr als einem Partner gleichzeitig unterstützen können und Netzwerkknoten (NNs) knotenumspannende Dienste zur Verfügung stellen können (Weiterleitung von Informationen im Netzwerk, Leitwegwahl, Topologieverwaltung und Verzeichniszugriffsdienste), die Endknoten (ENs) nicht zur Verfügung stellen können.
Wie soeben erwähnt wurde, verwenden diese Knoten LU-6.2-Protokolle, um eine Programm-Programm-Kommunikation zu unterstützen. Dies ist an sich nichts neues. Logische Einheiten (LUs), die LU- 6.2-Protokolle ausführen, wurden früher schon bei T5- und T2.1- Knoten verwendet, um die verschiedenen Funktionen der Architekturschichten auszuführen, die erforderlich sind, um eine Kommunikation zwischen Transaktionsprogrammen (TPs) und dem Netzwerk zu ermöglichen. Was jetzt neu ist, aber nicht in Figur 5 ausgedrückt ist, ist, daß CP-CP-Sitzungen von Transaktionsprogrammen (TPs) benutzt werden, die für spezielle Dienste ausgelegt sind und speziell für den CP-CP-Gebrauch geschrieben wurden, und daß dadurch, daß diese Transaktionsprogramme (TPs) mit derselben logischen Einheit (LU) min geringfügigen Anpassungen eingesetzt werden können, eine höhere Effizienz und weitere Einsparungen realisiert werden. Auch dadurch, daß viele Transaktionsprogramme (TPs) Netzwerkstatusinformationen auf einer einzigen CP-CP-Sitzung austauschen können, kann das Netzwerk effizienter betrieben werden.
Aufgrund der allgemeinen Beschaffenheit der logischen Einheit LU 6.2 sind die Service-Transaktionsprogramme (TPs) von den Sorgen befreit, die gewöhnlich Kontrollpunkt-Sitzungen belasten: die Transaktionsprogramme (TPs) sind in der Lage, Daten zu senden, ohne die Puffergrößen am benachbarten Knoten oder auf der Verbindung berücksichtigen zu müssen. Dies ist ein Dienst, den die LU 6.2 bereitstellt.
Figur 6 gibt den Verlauf von Aktionen an, welche die Aktivierung/den Aufbau einer CP-CP-Sitzung bewirken. Wenn eine Verbindung aktiviert wird (in Betrieb genommen wird), wie bei 120 angedeutet ist, empfangen Knoten (Knoten A und B in der Zeichnung), die an die Verbindung angeschlossen sind, zugehörige Signale (beispielsweise von einem Bediener, der die Verbindung in Betrieb nimmt), und ein Knoten oder beide Knoten beginnen einen XID-Datenübertragungssteuerungs-Austausch; der Beginn ist bei 121 angedeutet (in der Zeichnung beginnt der Knoten A). Ein Beispiel für eine Datenübertragungssteuerungs-Signalgebung und für den Austausch von XID-Signalen ist in der vorstehend erwähnten Veröffentlichung GA27-3093 beschrieben. Ein Knoten, der eine XID-Abfrage empfängt, Knoten B in diesem Fall, antwortet mit einem XID-Signal, das seine Identität angibt, wie bei 122 angedeutet ist. Bei T2.1-Knoten ist die Antwort ein diesen Knoten eigenes XID-3-Signal (die Form ist im Kapitel 2 des vorstehend erwähnten Schriftstücks SC30-3422-0 gezeigt), das Informationen enthält, die angeben, ob der antwortende Knoten CP-CP-Sitzungen unterstützt und wenn ja, ob Dienste zur Verfügung gestellt werden, sowie die Verfügbarkeit des Knotens für eine CP-CP-Sitzung. Endknoten (ENs), die eine aktive CP-CP-Sitzung haben, sind nie verfügbar (siehe Fig. 5). Ein Knoten, der Netzwerkdienste benötigt (d.h. ein Endknoten (EN)) sendet nur BINDS an Knoten, die Netzwerkdienste zur Verfügung stellen (d.h. ein Netzwerkknoten (NN)). Zwei Endknoten (ENs) bauen keine CP-CP-Sitzung auf. Der Knoten, der die XID-Abfrage sendet, der Knoten A in der Abbildung, sendet auch ein XID-Signal, das anzeigt, ob er CP-CP-Sitzungen unterstützt und wenn ja, seine Verfügbarkeit für eine Sitzung, wie bei 123 gezeigt ist.
Die Form des XID-3-Signals ist in Figur 7 gezeigt. Wie vorstehend erwähnt wurde, ist das XID-3-Signal alten als auch neuen T2.1-Knoten gemein. Teile, die hier von Interesse sind, sind das Bit 126 und das Zwei-Bit-Feld 127. Das Bit 126 zeigt an, ob CP- CP-Sitzungen unterstützt oder nicht unterstützt werden. Die Bits 127, die nur ausgewertet werden, wenn das Bit 128 die Unterstützung einer CP-CP-Sitzung anzeigt, werden wie folgt interpretiert:
B'00'' Sender erhält gerade alle benötigten Netzwerkdienste, und ein CP-CP-Sitzungs-BIND wird nicht angefordert
B'01' Sender erhält gerade nicht alle benötigten Netzwerkdienste, und ein CP-CP-Sitzungs-BIND wird angefordert
B'10' Sender stellt Netzwerkdienste über CP-CP-Sitzungen zur Verfügung, aber ein Sitzungs-BIND wird nicht angefordert
B'11' Sender stellt Netzwerkdienste über CP-CP-Sitzungen zur Verfügung, und ein Sitzungs-BIND wird angefordert.
Der Wert dieser Bits bleibt in jedem XID-3-Signal, das ein Knoten an einen bestimmten benachbarten Knoten sendet, jederzeit gleich, egal auf welcher Leitung es gesendet wird. Wenn ein XID- Austausch anzeigt, daß eine CP-CP-Sitzung aufgebaut werden sollte, und es gibt bereits eine, wird keine weitere Maßnahme ergriffen.
Der Abfrageschritt 121 (Fig. 6) wird nicht von allen SMA-Knoten verwendet, und eigentlich ist er nicht wirklich notwendig, denn alles, was erforderlich ist, ist, daß die Knoten auf der Verbindung einander ihre jeweilige Identität und ihre entsprechende Verfügbarkeit für eine CP-CP-Kommunikation mitteilen. Der soeben beschriebene XID-Austausch wird auch ausgelöst, wenn ein Knoten neu installiert wird, da jede Verbindung, an die er angeschlossen wird, dann aktiviert werden muß, wodurch der soeben beschriebene Ablauf automatisch auf jeder Verbindung stattfindet.
Mit der Erläuterung von Figur 6 fortfahrend, sei erwähnt, daß die Knoten die im XID-Austausch erhaltenen Informationen auswerten, und wenn ein Knoten oder beide Knoten nicht für eine CP-CP- Sitzung zur Verfügung stehen oder keiner von beiden Dienste zur Verfügung stellt (beides sind Endknoten (ENs)) (128, Fig. 6), fahren sie mit Operationen des vorher bestehenden Typs fort, die momentan nicht relevant sind. Wenn jedoch beide verfügbar sind und zumindest einer Dienste zur Verfügung stellt (ein Netzwerkknoten (NN) ist) (129, Fig. 6), fahren sie mit weiteren Austauschoperationen auf Verbindungsebene 130 fort. Bei diesen Austauschoperationen lösen die Knoten, die asynchron zueinander arbeiten, symmetrisch Übertragungsoperationen aus, um ein Sitzungspaar aufzubauen und um in ersten Nachrichtenaustauschoperationen auf diesen Sitzungen das entsprechende Leistungsprofil des jeweiligen Knotens wie nachstehend beschrieben festzustellen. Somit wird in einer Folge von Austauschoperationen 131 bis 134, die vom Knoten A ausgelöst wird, ein Sitzungsbindungssignal an den Knoten B gesendet, eine Bestätigung wird von B nach A zurückgeschickt, wodurch eine Sitzung aufgebaut wird, eine Anforderung für Leistungsmerkmale wird auf dieser Sitzung von A nach B geschickt (als erste Nachricht auf der Sitzung), und eine Aussage über Leistungsmerkmale wird als zweite Nachricht auf der Sitzung von B nach A zurückgeschickt. Ein ähnlicher Ablauf in der anderen Richtung, 135 bis 138, baut eine weitere Sitzung auf, und in einem Leistungsprofilanforderungs-Austausch auf dieser Sitzung wird B über die Fähigkeiten von A informiert.
Ein wichtiger Aspekt der BINDs, die gesendet werden (131 und 135), ist der, daß es sich bei ihnen um LU-6.2-BINDs handelt, und alle Einrichtungen, die der logischen Einheit LU 6.2 zur Verfügung stehen, stehen diesen Simplexsitzungen zur Verfügung. Beispielsweise sind LU-6.2-BINDs aushandelbar; das heißt, viele Parameter auf dem BIND können vom Empfänger verändert werden (beispielsweise die größtmögliche Nachricht, die gesendet werden kann). Somit brauchen die Kontrollpunkte nicht die Kenndaten ihrer Partner zu wissen, um die Sitzungen aufzubauen. Eine Information, die ein Kontrollpunkt (CP) gerne hätte, ist die Gewißheit darüber, daß sein Partner der ist, der er vorgibt zu sein. Wieder stellt die logische Einheit LU 6.2 dem Kontrollpunkt diesen Dienst zur Verfügung. Die Sicherheitsfunktionen der logischen Einheit LU 6.2 (ausführlicher in dem vorstehend erwähnten Schriftstück SC30-3269 beschrieben) ermöglichen Kontrollpunkten, die Identität des Knotens zu überprüfen, mit dem er eine CP-CP-Sitzung aufbaut. An dieser Stelle legen interne Operationen in den Knoten Bedingungen fest, welche die Benutzung der beiden Sitzungen als Simple-sitzungen mit gegenläufigen Flußrichtungen beschränken.
Die Leistungsprofilaussage, die gerade betrachtet wird (Fig. 8), umfaßt:
1. Ein Zwei-Byte-Feld 160, das die Länge der Aussage angibt
2. Ein Zwei-Byte-Feld 161, das sie als Leistungsprofilaussage kennzeichnet
3. Ein Vier-Byte-Feld 164, das eine Reihe von "Unterstützungsanzeigern" enthält (Bits, die auf 1 gesetzt werden, wenn der Sender entsprechenden Bitstellen zugeordnete Funktionen unterstützt, und die im anderen Fall auf 0 gesetzt werden). Dazu gehören: ein Bit, das anzeigt, ob RECEIVE_NETWORK_ SEARCH (eine einer Lokalisierungsoperation zugeordnete Suchanforderungsfunktion, die in der vorstehend erwähnten, ebenfalls anhängigen Patentanmeldung von Baratz u.a. beschrieben ist) unterstützt wird, ein Bit, das anzeigt, ob Verzeichniszugriffsdienste in bezug auf Ressourcen in anderen Domänen vom Sender zur Verfügung gestellt werden (was bedeutet, daß der Sender Suchanforderungen nach Bedarf überträgt); ein Bit, das anzeigt, ob der TOPOLOGY_UPDATE_DATA BASE-Service zur Verfügung gestellt wird (d.h., ob der Sender den Empfang bestimmter aktualisierter Topologie-Datenbankinformationen auf dieser Sitzung unterstützt); Bits, die anzeigen, ob der Sender auf Anforderung bestimmte Verwaltungsservicedaten zur Verfügung stellt und den Empfang nicht erwarteter Verwaltungsdaten am Knoten des Senders unterstützt; und zusätzliche Reservierungsbits für andere Service-Anzeigen.
4. Ein Feld variabler Länge 166, das nur von Endknoten (ENs) gesendet wird, gibt die Grenzen von Suchdiensten an, die vom Sender ausgeführt werden können; beispielsweise um bestimmte Ressourcenkategorien anzugeben, nach denen gesucht werden kann. Nur Endknoten (ENs) senden dieses Feld (Netzwerkknoten (NNs) akzeptieren alle Suchläufe ohne Einschränkungen).
Andere Netzwerkstatusinformationen werden von einzelnen Transaktionsprogrammen (TPs) in der CP-CP-Sitzung je nach Bedarf ausgetauscht. Da eine Sitzung eine beliebige Anzahl von Signalübertragungen unterschiedlicher Länge einschließen kann, sind der Art und der Menge der Statusinformationen, die auf diese Weise übertragen werden können, eigentlich keine Grenzen gesetzt. Beispiele für Informationen, die gerade zur Übertragung auf diese Art und Weise betrachtet werden, sind nachstehend aufgeführt.
Nachrichtenformate von CP-CP-Sitzungen sind in Fig. 9 gezeigt. Bezug nehmend auf Fig. 9 sei erwähnt, daß ein CP-CP-Nachrichtenrahmen einen Verbindungsvorsatz 210 enthält, einen Übertragungsvorsatz 212, einen Nachrichtenvorsatz 214, eine Nachrichteneinheit 216 und einen Verbindungsnachsatz 218. Die Funktionen und Formen dieser Teile im allgemeinen sind in der vorstehend erwähnten Veröffentlichung "Reference Summary", GA27-3136-6 beschrieben, und Funktionen und Formen, die für Austauschoperationen zwischen T2.1-Knoten spezifisch sind, sind in der vorstehend erwähnten Veröffentlichung "Format and Protocol", SC30-3422-0, beschrieben.
Verbindungsvorsätze und Verbindungsnachsätze (Kapitel 1, GA27- 3136) enthalten im allgemeinen Anzeigeinformationen, die den entsprechenden Anfangs- und Endpunkt einer Nachricht angeben. Der Verbindungsvorsatz enthält auch Adresseninformationen, die den Bestimmungsort der Nachricht angeben, und Verbindungssteuerungsinformationen. Der Verbindungsnachsatz enthält auch Informationen darüber, daß der Empfänger für gewöhnlich den empfangenen Rahmen auf Fehler prüft, die gegebenenfalls durch den Übertragungskanal eingeführt wurden (Kapitel 1, GA27-3136). Die Teile Verbindungsvorsatz und Verbindungsnachsatz in einem CP-CP- Nachrichtenrahmen haben dieselbe Form wie entsprechende Teile anderer T2.1-Nachrichtenrahmen (Kapitel 1, SC30-3422).
Der Übertragungsvorsatz für eine beliebige Sitzung enthält ein Formatidentifikationsfeld (FID), das je nach den Arten von Knoten, die senden und empfangen, eine von fünf Arten angibt (Kapitel 1, GA27-3136). Die Länge dieses Vorsatzes hängt von seinem Typ ab. Übertragungen zwischen T2.1-Knoten verwenden das Formatidentifikationsfeld (FID) des Typs 2, das eine Länge von 6 Byte hat und auch Sitzungsidentifikationsinformationen enthält (Kapitel 1, SC30-3422). Eine CP-CP-Sitzung erkennt man an einem bestimmten Sitzungsidentifikationswert.
Der Nachrichtenvorsatz enthält ein Bit, das die zugehörige Nachrichteneinheit entweder als eine Anforderung oder als eine Antwort kenntlich macht, und andere Felder in bezug auf die entsprechende Einheit (Kapitel 4, GA27-3136). Diese anderen Felder geben an, ob die entsprechende Informationseinheit Teil einer größeren Kette von Einheiten ist, die in getrennten Nachrichtenrahmen gesendet werden, und wenn ja, die relative Position dieser Einheit in der Kette (Anfang, Ende oder Mitte).
Beispiele für Arten von Informationen, die in CP-CP-Sitzungen ausgetauscht werden, sind in den Figuren 10 und 11 aufgeführt; Fig. 10 bezieht sich auf Austauschoperationen zwischen Netzwerkknoten-(NN-) und Endknoten-(EN-)Paaren, und Fig. 11 bezieht sich auf Austauschoperationen zwischen Netzwerkknoten-(NN-)Paaren. Dazu gehört der vorstehend erläuterte Leistungsprofil-Austausch sowie der Austausch anderer Netzwerkstatusinformationen innerhalb der Grenzen, die in den Leistungsprofil-Austauschoperationen angegeben sind.
Zwischen einem Netzwerkknoten (NN) und einem Endknoten (EN) kann der Leistungsprofil-Austausch die Fähigkeit des Endknotens (EN) angeben, verschiedene Arten von Abfragen zu empfangen und zu verarbeiten (zum Beispiel Verzeichnis- oder Netzwerkverwaltung) sowie die Fähigkeit des Netzwerkknotens (NN), auf Anforderungen für Verzeichnissuchläufe und auf Anforderungen, Ressourcen und/oder ihre Kenndaten zu verzeichnen, zu antworten. Andere Netzwerkstatusinformationen zwischen solchen Knoten können folgendes einschließen: Endknoten-(EN-)Anforderungen für Verzeichnissuchläufe, der Netzwerkknoten (NN) antwortet auf diese Anforderungen, Netzwerkknoten-(NN-)Verzeichnisabfragen, der Endknoten (EN) antwortet darauf, Netzwerkknoten-(NN-)Netzwerkverwaltungsabfragen, der Endknoten (EN) antwortet darauf, usw.
Leistungsprofil-Austauschoperationen zwischen paarweisen Netzwerkknoten (NNs) können angeben, daß der entsprechende Knoten in der Lage ist, Verzeichnissuchläufe und den Austausch von Netzwerktopologieinformationen zu unterstützen. Ein anderer Austausch von Netzwerkstatusinformationen kann diesen Knoten gestatten, Verzeichnissuchläufe in bezug auf Verzeichnisse an einem oder mehreren anderen Knoten durchzuführen, und zwar entweder auf einer Punkt-zu-Punkt-Basis oder im Rundspruchmodus, und auf Topologieinformationen an einem anderen Knoten zuzugreifen.
Bedingungen, die eine nicht geplante Beendigung von CP-CP-Sitzungen herbeiführen (Verbindungsausfall, Modemausfall usw.), werden durch interne Knotenabläufe überwacht, die für die Aktivitäten in diesen Sitzungen transparent sind. Die angewandten Verfahren können für verschiedene Verbindungen anders sein. Beispiele für solche Verfahren sind in Fig. 12 aufgeführt. Maßnahmen, die ergriffen werden, wenn eine solche Bedingung festgestellt wird, werden nachstehend unter "Benachrichtigung von Transaktionsprogrammen.." erläutert.
Entsprechend den geeigneten Verbindungsmedien kann der Knoten- Kontrollpunkt (CP) eine Zeitsperre auslösen, nachdem eine beliebige bestätigbare Nachricht gesendet wurde, und wenn keine Bestätigung vor dem Ablauf der Zeitsperre empfangen wird, kann eine Fehlermeldung gesetzt werden. Das System sollte eine angemessene Anzahl von Wiederholungen vorsehen, wenn während dem Wiederholungsintervall negative Bestätigungen empfangen werden (was auf vorübergehende Störungen schließen läßt), bevor es den Fehlerzustand setzt. Auf Modemverbindungen zu einem Wählnetz (beispielsweise dem öffentlichen Telefonnetz) kann die Feststellung, daß ein Leitungsverlust aufgetreten ist ("kein Träger"), das Setzen des Fehlerzustandes auslösen. Eine unerwartete Reaktivierung einer Verbindung, von der man glaubte, daß sie bereits im Betrieb sei, kann zur Auslösung des Fehlerzustandes führen.
Fig. 13 gibt Aktionen an, die automatisch an einem Knoten ausgeführt werden, wenn ein Fehlerzustand gesetzt ist. Das Datenübertragungssteuerungselement erkennt einen Verbindungsausfall (310, Fig. 13). Dieses Element setzt eine Verbindungsausfall-Meldung (320, Fig. 13) und benachrichtigt ein Pfadsteuerungselement. Das Pfadsteuerungselement schickt eine Pfadsteuerungsausfall-Meldung in bezug auf die zugehörigen Pfade (330, Fig. 13) ab und benachrichtigt alle logischen Einheiten (LUs), einschließlich der logischen Einheit (LU), welche die CP-CP-Sitzung unterstützt (die Sitzungs-LU) (340, Fig. 13). Die Sitzungs-LU setzt Fehlermeldungen in bezug auf alle Sitzungen, die den betroffenen Pfad benutzen (350, Fig. 13) und benachrichtigt alle Transaktionsprogramme (TPs), die eine ausgefallene Sitzung benutzen, sowie alle Transaktionsprogramme (TPs), die eine Benachrichtigung über bestimmte Sitzungsausfälle erhalten sollen (360, Fig. 13; siehe auch Erläuterung der Fehlerbehandlung mit Bezug auf Fig. 14 unten). Für die CP-CP-Sitzung ist das zuletzt erwähnte spezielle Transaktionsprogramm (TP) das Transaktionsprogramm, das dazu dient, das lokale Leistungsprofil anderen Knoten mitzuteilen, und es benachrichtigt den Knoten-Kontrollpunkt (CP), daß eine der Simplexsitzungen ausgefallen ist (370, Fig. 13). Der Kontrollpunkt (CP) benachrichtigt daraufhin alle betroffenen Komponenten am Knoten (Verzeichniszugriffsdienste, Topologie- und Leitwegwahldienste usw.; 380, Fig. 13), und die Sitzung wird damit nicht weiter benutzt.
Die Figuren 14A und 14B, die übereinander angeordnet sind, wie in Fig. 14 gezeigt ist, geben den Verlauf und die Beziehung von Knotenaktivitäten in Verbindung mit der Aktivierung, der Benutzung und der Deaktivierung von CP-CP-Sitzungen an. Die Linie 401 ganz oben in Fig. 14A gibt die verschiedenen Knotenkomponenten an, die an diesen Aktivitäten beteiligt sind. Die einer jeden Aktion zugeordnete Komponente ist durch die senkrechte gestrichelte Linie angegeben, die auf den linken Endpunkt der entsprechenden Aktionslinie und den Kreuzungspunkt derselben senkrechten Linie mit der Linie 401 trifft. Somit zeigt beispielsweise die senkrechte gestrichelte Linie 402A an, daß die Aktion 402 vom Knoten-Kontrollpunkt (CP) ausgeführt wird.
Aktionen, die sich auf die Aktivierung, die Benutzung und die unerwartete Beendigung einer CP-CP-Sitzung beziehen, sind in der Reihenfolge ihres Auftretens von oben nach unten in Fig. 14A angegeben und werden dann von oben nach unten in Fig. 14B fortgesetzt. Aktionen, die sich auf die Aktivierung der Sitzung und des zugehörigen Leistungsprofil-Austausches beziehen, sind mit den Linien 402 bis 412, 420, 421 und 430 bis 439 angegeben.
Bei 402 stellt der Knoten-Kontrollpunkt (CP) fest, daß ein ferner Knoten, der eine CP-CP-Sitzung unterstützt, kontaktiert worden ist und zeigt dieses Vorkommnis dem Transaktionsprogramm (TP) an, das für das Auslösen des CP-LEISTUNGSPROFIL-Austausches an diesem Knoten verantwortlich ist, wie durch die Linie 403 angedeutet ist. Dieses Transaktionsprogramm (TP) fordert die logische Einheit (LU) des Knotens auf, ein Sitzungs-BIND-Signal an den fernen Knoten zu senden und diesen Knoten für den Empfang einer Leistungsprofil-Nachricht auf dieser Sitzung vorzubereiten, wie bei 404 gezeigt ist. Es sei erwähnt, daß die Aktion 402 einen vorherigen Austausch von XID-3-Signalen zwischen den Knoten einschließt, der anzeigt, daß beide Knoten CP-CP-Sitzungen unterstützen und gegenwärtig in der Lage sind, eine solche Sitzung auf der Verbindung zu haben, durch die der Kontakt hergestellt worden ist.
Im Anschluß an die Aktion 404 sendet die logische Einheit (LU) ein BIND-Signal (Linie 405), das, wenn es ordnungsgemäß empfangen wurde, eine positive Antwort von dem anderen Knoten hervorruft (Linie 406). Auf der Grundlage der logischen Einheit (LU), an die das BIND-Signal übertragen wird, und des Modus, der für die Sitzung angefordert wird, erkennt die logische Einheit (LU) das CP-LEISTUNGSPROFIL-Transaktionsprogramm (CP-LEISTUNGSPROFIL- TP in der Figur) als das Transaktionsprogramm (TP), das benachrichtigt werden sollte, wenn die Sitzung ausfällt. Es gibt einen einzigen Fall, wo das CP-LEISTUNGSPROFIL-Transaktionsprogramm (TP) im Knoten ausgeführt wird, und alle Anforderungen für einen Informationsaustausch und Benachrichtigungen über einen Sitzungsausfall werden in eine einzige Warteschlange gestellt, um die richtige Ablauffolge aufrechtzuerhalten. Ein einziges Transaktionsprogramm (zum Beispiel CP-LEISTUNGSPROFIL) ist in der Lage, an mehreren Dialogen gleichzeitig teilzunehmen, so daß dieses einzelne Transaktionsprogramm (TP) in einem Leistungsprofil-Austausch mit mehreren verschiedenen Partnern auf einmal teilnehmen kann. Nach dem Empfang dieser Antwort leitet die logische Einheit (LU) einen Nachrichtenrahmen weiter, der den fernen Knoten für den Empfang einer Leistungsprofil-Nachricht vorbereitet (Linie 407), und tritt dann mit dem CP-LEISTUNGSPROFIL- ANFORDERUNGS-Transaktionsprogramm (CP-Leistungsprofil-ANFORDERUNGS-TP in der Figur) in Dialogverkehr, dem Transaktionsprogramm (TP), das dafür verantwortlich ist, den fernen Knoten anzufragen, ob er die Leistungsprofil-Nachricht über die logische Einheit (LU) senden kann (Linie 408). Wenn die Leistungsprofil- Nachricht von dem fernen Knoten als Antwort zurückgeschickt wird (wieder über die logische Einheit (LU) (Linie 409), benachrichtigt dieses Transaktionsprogramm (TP) den Kontrollpunkt (CP), daß eine Simplexsitzung aktiviert ist (Linie 410). Der Kontrollpunkt (CP) informiert dann die Knotenkomponenten, die für die Verwaltung der Topologie- und Verzeichniszugriffsdienste verantwortlich sind, daß eine Sitzung aktiv ist (Linien 411 und 412).
Das CP-LEISTUNGSPROFIL-ANFORDERUNGS-Transaktionsprogramm (TP) gibt dann den Informationsaustausch frei, wobei es die Sitzung für andere Komponenten verfügbar macht, und informiert die logische Einheit (LU) darüber (Linie 420), woraufhin die logische Einheit (LU) eine ENDE-Nachricht an den fernen Knoten sendet (Linie 421), welche die Beendigung des Leistungsprofil-Austausches auf dieser Sitzung meldet.
Parallel zu den mit 402 bis 412 beschriebenen Funktionen führte der ferne Knoten dieselben Aktionen zum Aufbau eines Sitzungspaares und zur Weiterleitung seines Leistungsprofils aus (Aktionen 430 bis 439). Diese Aktionen sind nur zum Zweck der Darstellung sequentiell gezeigt.
Der ferne Knoten beginnt mit einem BIND-Signal an den lokalen Knoten (Linie 430), das von der lokalen logischen Einheit (LU) mit einer Antwort bestätigt wird (Linie 431). Ausfälle auf dieser Sitzung werden auch dem CP-LEISTUNGSPROFIL-Transaktionsprogramm (TP) gemeldet. Der ferne Knoten folgt mit einer Nachricht, die angibt, daß eine Leistungsprofil-Anforderung folgt (Linie 432), und die lokale logische Einheit (LU) leitet diese an das lokale Transaktionsprogramm (TP) weiter, das für den Austausch von Informationen über die Sitzungstauglichkeit des Kontrollpunktes (CP) verantwortlich ist (CP-LEISTUNGSPROFIL-Transaktionsprogramm). Der ferne Knoten folgt mit seiner Leistungsprofil-Aussage, die von der lokalen logischen Einheit (LU) an das CP-LEISTUNGSPROFIL-Transaktionsprogramm (TP) weitergeleitet wird (Linie 433), woraufhin dieses Transaktionsprogramm (TP) eine passende Antwortnachricht zurückschickt (wieder über die logische Einheit (LU) (Linie 434) und auch den lokalen Kontrollpunkt (CP) benachrichtigt, daß eine Simplexsitzung in der umgekehrten Richtung aktiviert ist (Linie 435). Der Kontrollpunkt (CP) benachrichtigt dann die Komponenten, die Topologie- und Verzeichniszugriffsdienste verwalten, daß eine Sitzung aktiviert ist (Linien 436 und 437). In der Zwischenzeit sendet der ferne Knoten sein ENDE-Signal, was die Beendigung des Leistungsprofilübertragungs-Dialoges anzeigt (Linie 438), und eine damit verbundene Meldung wird von der lokalen logischen Einheit (LU) an das lokale CP-LEISTUNGSPROFIL-Transaktionsprogramm (TP) übertragen (Linie 439).
Nun beginnen die Knoten, die beiden Sitzungen, jeweils im Simplexmodus, zu benutzen, um andere Netzwerkstatusinformationen nach Bedarf zwischen Transaktionsprogrammen (TPs) zu übertragen, die sie benötigen. Beispiele für Lokal-Fern-Übertragungen in diesem Modus sind auf den Linien 450 bis 457 aufgeführt. In einem solchen Übertragungsbeispiel signalisiert die lokale Topologiediensteinrichtung der lokalen logischen Einheit (LU), daß sie die CP-CP-Sitzung für eine Übertragung von Topologiedaten belegen möchte (Linie 450). Die Topologiediensteinrichtung übermittelt ihre Meldung, einen Informationsaustausch zu beginnen, die zu übertragenden Daten und die Meldung, den Informationsaustausch zu beenden, ungeachtet dessen, ob der Dialog unmittelbar zugeordnet wird. Da die Sitzung gegenwärtig nicht benutzt wird, wird sie für die Übertragung der Topologiedaten zugeordnet, und eine entsprechende Startnachricht wird an den fernen Knoten gesendet. Dann werden die Daten an den fernen Knoten übermittelt, und die logische Einheit (LU) sendet ein ENDE-Signal an den fernen Knoten (Linie 451). Wenn die Datenmenge klein genug ist, können die Startmeldung, die Daten und die Endemeldung alle in einer einzigen Nachricht fließen. Wenn es zu viele Daten sind, gibt es mehrere Nachrichten. Ähnliche Abläufe sind bei den Linien 452 und 453 angedeutet, um Verzeichnisdaten an den fernen Knoten weiterzuleiten. Dann sind eine Reihe von Übertragungen, die sich in einer Warteschlange befinden, auf den Linien 454 bis 457 angedeutet, wobei die Transaktionen in Verbindung mit der Sitzungszuordnung und der Übertragung von Verzeichnisdaten in bezug auf die logische Einheit (LU) bei 454 in eine Warteschlange gestellt werden, und es kommt zu ähnlichen Aktionen, um eine Topologienachrichten-Aktivität in die Warteschlange zu stellen, wie bei 455 gezeigt ist, und dann wird die logische Einheit (LU) aktiv, um entsprechende Signale an den fernen Knoten zu übertragen, um zunächst die Übertragung der in der Warteschlange befindlichen Verzeichnisdaten (Linie 456) und anschließend der in der Warteschlange befindlichen Topologiedaten (Linie 457) auszuführen.
Zum Schluß ist ein Beispiel eines Sitzungsausfalls aufgrund von unvorhergesehenen Bedingungen in den Linien 480 bis 485 angegeben. Pfadsteuerungseinrichtungen erfahren von einem Pfadausfall, wie vorher mit Bezug auf Fig. 13 beschrieben wurde (und kurz bei 480 angedeutet ist), und benachrichtigen den lokalen Kontrollpunkt (CP) (Linie 481). Der Kontrollpunkt (CP) informiert die logische Einheit (LU) über alle Sitzungsausfälle (Linie 482) und letztere sendet eine entsprechende Meldung an das CP-LEISTUNGSPROFIL-Transaktionsprogramm (TP) (Linie 483). Dieses Transaktionsprogramm (TP) benachrichtigt dann den Kontrollpunkt (CP), daß eine der Simplexsitzungen ausgefallen ist (Linie 483a), und der Kontrollpunkt (CP) benachrichtigt die Komponenten, welche die Topologie- und Verzeichniszugriffsdienste verwalten (Linien 484 und 485), und die Sitzung wird nicht mehr weiter benutzt.

Claims

1. Verfahren zur Ausbreitung von Netzwerkstatusinformationen NSI in einem Rechnernetzwerk, das Knoten eines vorher festgelegten Typs enthält, wobei jeder der Knoten in der Lage ist, Netzwerkstatusinformations-Austausch-(NSI-Austausch-)Sitzungen nur mit anderen Knoten des gleichen Typs zu unterstützen, das Verfahren an jedem von zwei Knoten an entgegengesetzten Enden einer Verbindung ausgeführt wird und dadurch gekennzeichnet ist, daß es die folgenden Schritte einschließt:

- Senden einer ersten Gruppe von Signalen (121 bis 123) an den anderen Knoten nach der Aktivierung (120) der Verbindung, wobei die erste Gruppe von Signalen die Verfügbarkeit des sendenden Knotens anzeigt, an einer Netzwerkstatusinformations-Austausch-(NSI-Austausch-)Sitzung teilzunehmen;

- Verarbeiten der von dem anderen Knoten empfangenen Signale, um festzustellen (129), ob beide Knoten zur Teilnahme an einer Netzwerkstatusinformations-Austausch-(NSI-Austausch-)Sitzung zur Verfügung stehen und ob der andere Knoten ein Servicegeber ist;

- Senden einer zweiten Gruppe von Netzwerkstatusinformations-Austausch-(NSI-Austausch-)Sitzungsaufbausignalen (131, 132, 135, 136) an die anderen Knoten, wenn beide Knoten für eine Netzwerkstatusinformations-Austausch-(NSI-Austausch-)Sitzung zur Verfügung stehen und zumindest einer der Knoten ein Servicegeber ist;

- Senden einer dritten Gruppe von Signalen (133, 134, 137, 138) an den anderen Knoten auf der aufgebauten Sitzung, um dem anderen Knoten Informationen über das Leistungsprofil des sendenden Knotens zu liefern; und

- Verfügbarmachen der Netzwerkstatusinformations-Austausch- (NSI-Austausch-)Sitzung für Transaktionsprogramme, die an den Knoten ausgeführt werden.

2. Verfahren gemäß Anspruch 1, wobei:

jeder der Knoten an entgegengesetzten Enden der Verbindung unabhängig voneinander eine Sitzung aufbaut, die von dem einen Knoten zu dem anderen Knoten geht.

3. Verfahren gemäß Anspruch 2, wobei:

ein Knoten, der Informationen von dem anderen Knoten empfängt, den Empfang dieser Informationen nicht unmittelbar zu bestätigen braucht.

4. Verfahren gemäß jedem der Ansprüche 1 bis 3, wobei:

- das Rechnernetzwerk, das Knoten eines vorher festgelegten Typs enthält, ein SNA-Rechnernetzwerk ist, das Knoten des Typs 2.1 enthält; und

- die Netzwerkstatusinformations-Austausch-(NSI-Austausch-)Sitzungen als CP-CP-Sitzungen bezeichnet werden.

5. Verfahren gemäß Anspruch 4, wobei:

die dritte Gruppe von Signalen den sendenden Knoten entweder als einen Endknoten identifiziert, der nicht in der Lage ist, anderen Knoten Leitwegdienste zur Verfügung zu stellen, oder als einen Netzwerkknoten, der in der Lage ist, diese Dienste bereitzustellen.