DE69729040T2

DE69729040T2 - Netzwerkübertragung

Info

Publication number: DE69729040T2
Application number: DE1997629040
Authority: DE
Inventors: Takahiro Shinagawa-ku Fujimori; Makoto Shinagawa-ku Sato; Tomoko Shinagawa-ku Tanaka
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1996-09-11
Filing date: 1997-09-10
Publication date: 2005-04-28
Anticipated expiration: 2017-09-11
Also published as: EP1161058A2; EP0833485A1; US6542510B1; EP0833485B1; US6438607B1; JP3731263B2; EP1161058A3; US5978854A; JPH1093597A; KR100475776B1; KR19980024775A; DE69729040D1

Description

Die Erfindung betrifft ein Verfahren für die Kommunikation über ein Netz, ferner ein Netz, ein ARP- oder RARP-Antwort-Paket und ein Gerät für die Verwendung als Netzknoten.
Es gibt viele bekannte Protokolle für die Implementierung einer elektronischen Kommunikation in einem Netz. Bill Croft, John Gilmore "Bootstrap Protocol (BOOTP) Network Working Group, Request for Comments Nr. 951, September 1985 XP002053146" beschreibt ein Bootstrap-Protokoll, das es einer plattenlosen Klienten-Maschine ermöglicht, seine eigene IP-Adresse, die Adresse eines Server-Hosts und den Namen einer in den Speicher zu ladenden und auszuführenden Datei zu entdecken. Zwei allgemein bekannte Protokolle sind das Adress-Resolution-Protokoll (ARP) und das Reverse-Adress-Resolution-Protokoll (RARP). Eine Beschreibung des RARP findet sich in "A Reverse Adress Resolution Protocol", Finlayson Mann, Mogul, Theimer (Stanford University) Network Working Group, Request for Comments, Nr. 903, Juni 1984 XP-002053148. ARP ist in diesem Dokument ebenfalls kurz beschrieben. Die ARP- und RARP-Protokolle können z.B. zur Implementierung von Übertragungen in einem Netz benutzt werden, das zwei oder mehr Netzknoten enthält, die über einen elektronischen Bus miteinander verbunden sind. Ein Beispiel für ein solches Netz ist in 1 dargestellt.
Wie aus 1 ersichtlich ist, sind Übertragungen, die von einem ersten Universalcomputer 2 zu einem zweiten Universalcomputer 4 gerichtet sind, durch einen Pfeil 6 gekennzeichnet. Ähnlich sind Übertragungen, die von dem zweiten Computer zu dem ersten Computer gerichtet sind, durch einen Pfeil 8 gekennzeichnet. Es ist vorausgesetzt, daß ein elektronischer Bus, z.B. ein serieller IEEE-1394-Bus, die Computer 2 und 4 miteinander verbindet und zur Kanalisierung der Übertragungen zwischen den Computern benutzt wird. Die Übertragungen sind abstrakt durch die Pfeile 6 und 8 dargestellt. Es sei ferner darauf hingewiesen, daß 1 zwar nur zwei Computer zeigt, das in 1 dargestellte Netz jedoch auch aus mehr als zwei Computern aufgebaut sein kann. Weiter unten wird auf 1 Bezug genommen, um die ARP- und RARP-Kommunikation detaillierter zu beschreiben.
ARP kann benutzt werden, wenn ein erster Netz-Computer mit einem zweiten Netz-Computer kommunizieren soll, die physikalische Adresse des zweiten Computers jedoch nicht kennt. Der Computer 2 kann z.B. eine Kommunikation mit dem Computer 4 wünschen, besitzt jedoch nur die Internet-Protokoll-Adresse (oder "IP-Adresse") des Computers 4, nicht jedoch seine physikalische Adresse. Entsprechend dem ARP sendet der Computer 2 eine (durch den Pfeil 6 repräsentierte) "ARP-Anforderung" über den Netz-Bus. Diese Anforderung enthält die IP-Adresse des Computers 4. Durch die Prüfung der IP-Adresse der Anforderung erkennt der Computer 4, daß er der gewünschte Rezipient der Anforderung ist. Der Computer 4 sendet dann eine (durch den Pfeil 8 repräsentierte) "ARP-Antwort", die an den Computer 2 adressiert ist und die physikalische Adresse des Computers 4 enthält.
RARP kann benutzt werden, wenn ein Netz-Computer seine IP-Adresse durch das Netz bestimmen möchte. Wenn z.B. der Computer 2 seine IP-Adresse bestimmen möchte, sendet er eine (durch den Pfeil 6 repräsentierte) "RARP-Anforderung" über das Netz. Die RARP-Anforderung enthält die IP-Adresse des Computers 4 sowie die physikalische Adresse des Computers 2. Nachdem der Computer 4 – durch Prüfung der IP-Adresse – festgestellt hat, daß er der gewünschte Rezipient der RARP-Anforderung ist, bestimmt er die IP-Adresse des Computers 2 durch Querbezug der physikalischen Adresse des Computers 2 zu der IP-Adresse des Computers 2 und sendet dann eine (durch den Pfeil 8 repräsentierte) "RARP-Antwort", die die IP-Adresse des Computers 2 enthält.
Sowohl ARP als auch RARP haben Nachteile, die ihre Effektivität einschränken. Bei ARP ist ein anfordernder Knoten darauf beschränkt, die physikalische Adresse eines Zielknotens zu akquirieren und kann keine Information akquirieren, die die Kommunikation zwischen ihm selbst und dem Zielknoten erleichtern würde. Insbesondere kann der anfordernde Knoten nicht innerhalb des Ziel-Computers die Adresse der Anwendung akquirieren, die Gegenstand der Anforderung ist. So kann in 1 z.B. die Kommunikation zwischen den beiden Computern vonstatten gehen, sobald der Computer 2 die physikalische Adresse des Computers 4 ermittelt, jedoch jedesmal, wenn der Computer 4 ein Kommunikations-Paket von dem Computer 2 empfängt, muß die Verarbeitungseinheit (CPU) des Computers 4 das empfangene Paket prüfen und dann das Paket an eine passende Anwendung in seinem Speicher weiterleiten. Darüber hinaus ist bei ARP die Größe der Kommunikationspakete begrenzt, wodurch die Flexibilität weiter eingeschränkt wird.
Ein Nachteil von RARP ist seine Anfälligkeit gegenüber Rücksetzungen des Busses. Wenn ein Netz-Bus zurückgesetzt wird – wenn z.B. die Stromversorgung umgeschaltet wird oder ein neues Gerät mit dem Netz verbunden wird – können sich die physikalischen Adressen der Netz-Knoten ändern, was zur Erzeugung von unkorrekten Querbezügen durch Knoten führt, die RARP-Antworten generieren, und damit zur Übertragung von inkorrekten IP-Adressen zu den anfordernden Knoten.
Nach einem ersten Aspekt der Erfindung ist ein Verfahren vorgesehen zur Durchführung einer Kommunikation über ein Netzwerk, das mehrere Knoten aufweist, mit den Verfahrensschritten: Senden eines ARP-Anforderungspakets von einem ersten Netzknoten zu einem zweiten Netzknoten und Senden eines ARP-Antwortpakets von dem zweiten Knoten zu dem ersten Knoten, wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Nach einem zweiten Aspekt der Erfindung ist ein Kommunikationsnetzwerk vorgesehen mit einer Mehrzahl von Knoten, das aufweist: erste Mittel, die so eingerichtet sind, daß sie ein Adress-Resolution-Protocol-Anforderungspaket von einem ersten Netzknoten zu einem zweiten Netzknoten senden, zweite Mittel, die so eingerichtet sind, daß sie ein Adress-Resolution-Protocol-Antwortpaket von dem zweiten Knoten zu dem ersten Knoten senden, wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Nach einem dritten Aspekt der Erfindung ist ein ARP-Antwort-Paket vorgesehen, das eine physikalische Adresse enthält, die den Ort eines Knotens in einem Netz kennzeichnet, der das Antwortpaket erzeugt, sowie eine Offset-Adresse, die innerhalb des Knotens den Ort eines Anwendungsprogramms zur Verarbeitung von Kommunikationspaketen angibt.
Nach einem vierten Aspekt der Erfindung ist ein Gerät zur Verwendung als Knoten in einem Kommunikationsnetz vorgesehen, wobei das Gerät Mittel aufweist, die so eingerichtet sind, daß sie als Reaktion auf ein empfangenes Adress-Resolution-Protocol-Anforderungspaket ein Adress-Resolution-Protocol-Antwortpaket erzeugen, das die physikalische Adresse des Geräts enthält, sowie eine Offset-Adresse, die innerhalb des Geräts den Ort eines Anwendungsprogramms zur Verarbeitung von Kommunikationspaketen angibt.
Das Anordnen einer Offset-Adresse in dem Antwortpaket macht es möglich, daß die nachfolgenden Kommunikationspakete direkt an das Anwendungsprogramm gerichtet werden, und daß die nachfolgenden Pakete variable Größe haben können.
Nach einem bevorzugten Ausführungsbeispiel der Erfindung wird die ARP-Kommunikations-Sitzung durch Anforderungs- und Antwortpakete initiiert, wobei das Antwortpaket eine Offset-Adresse enthält, die den Ort der Software-Applikation spezifiziert, die Gegenstand der Sitzung ist. Dadurch ist es möglich, daß die auf das Antwortpaket folgenden Sitzungspakete direkt an die Anwendung adressiert werden und daß diese nachfolgenden Pakete variable Größe haben können.
Nach einem fünften Aspekt der Erfindung ist ein Verfahren vorgesehen zur Durchführung einer Kommunikation über ein Netz, das mehrere Knoten aufweist, mit den Verfahrensschritten: Senden eines Reverse-Adress-Resolution-Protocol-Anforderungspakets von einem ersten Netzknoten zu einem zweiten Netzknoten, wobei das Anforderungspaket eine eindeutige Knoten-ID enthält, die den ersten Knoten identifiziert, Senden eines Reverse-Adress-Resolution-Protocol-Antwortpakets von dem zweiten Knoten zu dem ersten Knoten, wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Nach einem sechsten Aspekt der Erfindung ist ein Kommunikations-Netz mit einer Mehrzahl von Knoten vorgesehen, das aufweist: erste Mittel, die so eingerichtet sind, daß sie ein Reverse-Adress-Resolution-Protocol-Anforderungspaket von einem ersten Netzknoten zu einem zweiten Netzknoten senden, wobei das Anforderungspaket eine eindeutige Knoten-ID enthält, die den ersten Knoten identifiziert, zweite Mittel, die so eingerichtet sind, daß sie ein Reverse-Adress-Resolution-Protocol-Antwortpaket von dem zweiten Knoten zu dem ersten Knoten senden, wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Nach einem bevorzugten Ausführungsbeispiel der Erfindung ist jedem Knoten eine eindeutige ID zugeordnet, zu dem Zweck, für jeden Knoten einen sich nicht ändernden Identifizierer vorzusehen, eine sich nicht ändernde physikalische Adresse für die Benutzung bei RARP-Anforderungen vorzusehen und die Durchführung einer RARP-Kommunikation ohne Störung durch Rücksetzungen des Netzes zu ermöglichen.
Die folgende detaillierte Beschreibung, die als Beispiel dient und auf die die vorliegende Erfindung nicht beschränkt sein soll, nimmt auf die anliegenden Zeichnungen Bezug, in denen gleiche Elemente und Teile durchgehend mit gleichen Bezugszeichen versehen sind.
1 zeigt ein schematisches Diagramm eines elektronischen Netzes, das für die Beschreibung von ARP- und RARP-Kommunikationen benutzt wird,
2 zeigt ein schematisches Diagramm eines elektronischen Netzes gemäß der Erfindung,
3 zeigt eine Darstellung einer Adressen-Cache-Tabelle gemäß der Erfindung,
4 zeigt eine Darstellung eines ARP-Anforderungs-Pakets gemäß der Erfindung,
5 zeigt eine Darstellung eines ARP-Antwort-Pakets gemäß der Erfindung,
6 zeigt eine Darstellung eines RARP-Anforderungs-Pakets gemäß der Erfindung,
7 zeigt eine Darstellung eines RARP-Antwort-Pakets gemäß der Erfindung.
2 zeigt ein exemplarisches elektronisches Netz, in dem Ausführungsbeispiele der vorliegenden Erfindung benutzt werden können. Wie aus dieser Figur ersichtlich ist, besitzt das Netz zwei Busse, den Bus 24 und den Bus 26, die über eine Brücke 28 miteinander verbunden sind. Der Bus 24 ist mit drei Knoten verbunden, den Knoten 10, 12 und 14, und der Bus 26 ist mit vier Knoten verbunden, den Knoten 16, 18, 20 und 22. Zum Zwecke der Veranschaulichung wird jeder Knoten von 2 als Universalcomputer betrachtet, die Busse 24 und 26 werden als IEEE-1394-Busse betrachtet, und die Brücke wird als IEEE-1394-Brücke betrachtet, obwohl es sich im Hinblick auf diese Offenbarung zeigen wird, daß viele Typen von Knoten, Bussen und Brücken sich für die Realisierung der Erfindung eignen.
Auf jeden Fall sind den Bussen und Knoten von 2 Identifikationsnummern (IDs) zugeteilt. Die Busse 24 und 26 werden als Busse "0" bzw. "1" bezeichnet. Die Knoten 10, 12 und 14 werden als Knoten "0", "1" bzw. "2" bezeichnet, und die Knoten 16, 18, 20 und 22 werden als Knoten "0", "1", "2" bzw. "3" bezeichnet, wobei zwei Knoten, die die gleiche ID haben, durch die Busse unterschieden werden, mit denen sie verbunden sind. Zusätzlich ist jedem der Knoten 10 bis 22 eine eindeutige Knoten-ID zugeordnet, die ausreicht, um jeden Knoten eindeutig zu identifizieren, ohne daß auf die Bus-IDs und/oder die Knoten-IDs Bezug genommen werden muß. Die Bus-IDs, die Knoten-IDs und die eindeutigen Knoten-IDs sind zusammen mit den Knoten-IP-Adressen in einer Adressen-Cache-Tabelle gespeichert. Vorzugsweise ist in jedem Netz-Knoten eine Kopie der Adressen-Cache-Tabelle gespeichert.
3 zeigt eine exemplarische Adressen-Cache-Tabelle, die dem Netz von 2 entspricht. Eine Möglichkeit, nach der jeder Netz-Knoten die Adressen-Cache-Tabelle akquirieren kann, ist durch ARP-Signalisierung gegeben. Das heißt, im Verlauf einer ARP-Sitzung kann ein antwortender Knoten dem anfordernden Knoten seine Bus-ID, die Knoten-ID, die eindeutige Knoten-ID und die IP-Adresse senden, die der anfordernde Knoten dann in seiner Adressen-Cache-Tabelle speichert. Natürlich kann die Tabelle des anfordernden Knotens zu jeder gegebenen Zeit die aktualisierte Information für alle Knoten in dem Netz enthalten oder nicht.
Nach der Beschreibung einer exemplarischen Netz-Konfiguration und einer exemplarischen Adressen-Cache-Tabelle wird nun die ARP- und die RARP-Kommunikation in Ausführungsbeispielen der Erfindung im Detail beschrieben.
4 und 5 zeigen exemplarische ARP-Kommunikationspakete gemäß der Erfindung. 4 zeigt ein ARP-Anforderungs-Paket, und 5 zeigt ein ARP-Antwort-Paket. Wie diese Figuren zeigen, sind die ARP-Anforderungs- und -Antwortpakete asynchrone Pakete. Jedes Pa ket enthält fünf primäre Abschnitte, nämlich einen asynchronen Paket-Header 30, einen Strom-Typ 32, einen Logical-Link-Control/SNAP-(LLC/SNAP)-Header 34, einen ARP/RARP-Header 36 und ARP/RARP-Daten 38. Jeder dieser primären Abschnitte ist wiederum in einen oder mehrere horizontale Unterabschnitte mit einer Länge von jeweils vier Bytes unterteilt.
An dem ARP-Anforderungs-Paket von 4 ist ersichtlich, daß der erste Posten in dem asynchronen Paket-Header ein Broadcast-Bus-Indikator ist (d.h. 10 Bits, die den String 0×3FE repräsentieren), für die Angabe, welcher Bus oder welche Busse in dem Netz das Anforderungspaket empfangen (z.B. alle Busse 0 und 1). Der nächste Posten ist ein Broadcast-Knoten-Indikator für die Angabe, welcher Knoten oder welche Knoten in dem Netz die Anforderung empfangen sollen (z.B. alle Knoten 10–22). Auf den Broadcast-Knoten-Indikator folgt eine Quell-ID, die die Knoten-ID des Knotens ist, der die Anforderung sendet. Auf die Quell-ID folgt ein Ziel-Offset (z.B. 6 Bytes, die den String 0×FFFF FFFF FFFF repräsentieren) für die Kennzeichnung eines Orts in dem Speicher des gewünschten Rezipienten-Knotens, an den die Anfrage gerichtet werden soll.
Der Abschnitt Strom-Typ (ST) enthält einen Kommunikationstyp-Indikator (z.B. Bits, die den String 0×00 repräsentieren) für die Kennzeichnung des Kommunikationstyps, auf den sich das Anforderungspaket bezieht (z.B. Logical Link Control-ARP/RARP/IP).
Der Abschnitt LLC/SNAP-Header enthält einen Resolution-Protokoll-Indikator (z.B. Bits, die den String 0×0806 repräsentieren) für die Kennzeichnung des Protokolltyps, auf den sich das Anforderungspaket bezieht (d.h. ARP).
Der Abschnitt ARP-Header enthält einen Protokolltyp-Indikator und einen Operations-Indikator. Der Protokolltyp-Indikator enthält eine Information (z.B. Bits, die den String 0×0800 repräsentieren) für die Kennzeichnung des Protokolls, auf das sich das Anforderungspaket bezieht (z.B. IP-Protokoll). Der Operations-Indikator enthält eine Information, die den Operationstyp kennzeichnet, auf den sich das Paket bezieht (d.h. ARP-Anforderung).
Zuletzt wird der Abschnitt ARP-Daten des ARP-Anforderungs-Pakets beschrieben. Der erste Posten in dem Abschnitt ARP-Daten ist eine Senderadresse, die die Adresse des Knotens kennzeichnet, der das ARP-Anforderungs-Paket sendete. Die Senderadresse kann z.B. eine 64-Bit-Adresse sein, wobei die ersten 16 Bit die Knoten-ID des sendenden Knotens angeben und die folgenden 48 Bits eine Offset-Adresse des anfordernden Knotens angeben, wobei die Offset-Adresse des anfordernden Knotens eine Adresse in dem Speicher des sendenden Knotens ist, an der Kommunikationspakete verarbeitet werden (z.B. die Adresse eines Anwendungsprogramms). Der zweite Posten in dem Abschnitt ARP-Daten ist die ein deutige Knoten-ID des sendenden Knotens (z.B. 64 Bits). Der dritte Posten ist die IP-Adresse des sendenden Knotens (z.B. 32 Bits), und der vierte Posten ist die IP-Adresse (z.B. 32 Bits) des Knotens, der der gewünschte Rezipient des Anforderungspakets ist.
Als Option kann der Abschnitt ARP-Daten Bereiche für eine Zieladresse und eine eindeutige Knoten-ID des Zielknotens enthalten. Diese Bereiche sind zu denjenigen analog, die für die Senderadresse bzw. die eindeutige Knoten-ID des sendenden Knotens vorgesehen sind. Da das Anforderungspaket jedoch an alle gesendet wird, sind die Zielbereiche unbestimmt und deshalb nicht mit tatsächlichen Adressen ausgefüllt. In einem exemplarischen Ausführungsbeispiel sind die Bereiche für die Zieladresse und die eindeutige Ziel-ID 64-Bit-Bereiche, die mit Nullen ausgefüllt sind, um ihren unbestimmten Zustand anzuzeigen.
Als zusätzliche Option kann das Anforderungspaket Fehlerprüfbit(s) enthaften sein. Diese Bits können zur Fehlererfassung und/oder -korrektur in dem Paket durch Implementierung eines Fehlerprüfcodes, z.B. eines zyklischen Redundanzcodes (CRC) dienen. Darüber hinaus können in dem Paket mehrere Gruppen von Fehlerprüfbits enthalten sein, wobei jede Gruppe der Fehlererfassung und/oder -korrektur innerhalb eines besonderen Teils des Pakets gewidmet ist. Es kann z.B. der Abschnitt ARP-Header eine erste Gruppe von dedizierten Fehlerprüfbits für die Benutzung bei der Fehlererfassung und/oder -korrektur in den Inhalten des Header-Abschnitts enthalten, während der Abschnitt ARP-Daten eine zweite Daten von dedizierten Fehlerprüfbits für die Benutzung bei der Fehlererfassung und/oder -korrektur in den Inhalten des Daten-Abschnitts enthalten kann.
Anhand von 5 wird nun das ARP-Antwort-Paket beschrieben. 5 zeigt, daß der erste Posten in dem asynchronen Paket-Header eine Sender-Knoten-ID (z.B. 16 Bits) ist, die die Knoten-ID des Knotens ist, der das ARP-Anforderungs-Paket sendete, das die Antwort veranlaßt. Der nächste Posten ist eine Antwort-Quell-ID (z.B. 16 Bits), die die Knoten-ID des Knotens ist, der das Antwortpaket sendet. Auf die Antwort-Quell-ID folgt ein Antwort-Ziel-Offset (z.B. 6 Bytes), der den Ort in dem Speicher des antwortenden Knotens kennzeichnet, an dem das durch den "Protokoll-Typ"-Indikator spezifizierte Protokoll verarbeitet wird.
Die Abschnitte Strom-Typ (SST), LLC/SNAP-Header und ARP-Header des Antwortpakets gleichen den Abschnitten ST, LLC/SNAP-Header und ARP-Header des Anforderungspakets. Der Abschnitt ST des Antwortpakets enthält einen Kommunikationstyp-indikator (z.B. Bits, die den String 0×00 repräsentieren) für die Kennzeichnung des Kommunikationstyps, auf den sich das Anforderungspaket bezieht (z.B. Logical Link Control-ARP/RARP/IP). Der Abschnitt LLC/SNAP-Header enthält einen Resolution-Protokoll-Indikator (z.B. Bits, die den String 0×0806 repräsentieren) für die Kennzeichnung des Protokolltyps, auf den sich das Antwortpaket bezieht (d.h. ARP). Der Abschnitt ARP-Header des Antwortpakets enthält einen Protokolltyp-Indikator und einen Operations-Indikator – wobei der Protokolltyp-Indikator eine Information enthält (z.B. Bits, die den String 0×0800 repräsentieren) für die Kennzeichnung des Protokolls, auf das sich das Antwortpaket bezieht (z.B. IP-Protokoll), und wobei der Operations-Indikator eine Information enthält, die den Operationstyp kennzeichnet, auf den sich das Paket bezieht (d.h. ARP-Antwort).
Zuletzt wird der Abschnitt ARP-Daten des ARP-Antwort-Pakets beschrieben. Der erste Posten in dem Abschnitt ARP-Daten ist eine Antwort-Sender-Adresse, die die Adresse des Knotens kennzeichnet, der das ARP-Antwort-Paket sendete. Die Antwort-Sender-Adresse kann z.B. eine 64-Bit-Adresse sein, wobei die ersten 16 Bits die Knoten-ID des antwortenden Knotens angeben und die folgenden 48 Bits eine Offset-Adresse des antwortenden Knotens angeben, wobei die Offset-Adresse des antwortenden Knoten eine Adresse innerhalb des Speichers des antwortenden Knotens ist, an der Kommunikationspakete verarbeitet werden (z.B. die Adresse eines Anwendungsprogramms). Der zweite Posten in dem Abschnitt ARP-Daten ist die eindeutige Knoten-ID des die Antwort sendenden Knotens (z.B. 64 Bits). Der dritte Posten ist die IP-Adresse des die Antwort sendenden Knotens (z.B. 32 Bits), und der vierte Posten ist die IP-Adresse (z.B. 32 Bits) des Knotens, der der gewünschte Rezipient des Antwortpakets ist.
Der Abschnitt ARP-Daten des Antwortpakets enthält ferner die Adresse des gewünschten Rezipienten des Antwortpakets (d.h. des anfordernden Knotens) und die eindeutige Knoten-ID des gewünschten Rezipienten. Das Format für diese zusätzlichen Posten kann dem Format für die Anforderungs-Sender-Adresse bzw. für die eindeutige Knoten-ID des Anforderungs-Senders analog sein. Somit kann der antwortende Knoten einfach die ersten beiden Posten der ARP-Daten des Anforderungspakets als zusätzlicher Posten in dem Antwortpaket enthalten, wodurch die Erzeugung des Antwortpakets erleichtert wird.
Wie im Fall des Anforderungspakets enthält das Antwortpaket optional Fehlerprüfbit(s). Diese Bits können zur Fehlererfassung und/oder -korrektur in dem Paket durch Implementierung eines Fehlerprüfcodes, z.B. eines zyklischen Redundanzcodes (CRC) dienen. Darüber hinaus können in dem Paket mehrere Gruppen von Fehlerprüfbits enthalten sein, wobei jede Gruppe der Fehlererfassung und/oder -korrektur innerhalb eines besonderen Teils des Pakets gewidmet ist. Es kann z.B. der Abschnitt ARP-Header eine erste Gruppe von dedizierten Fehlerprüfbits für die Benutzung bei der Fehlererfassung und/oder -korrektur in den Inhalten des Header-Abschnitts enthalten, während der Abschnitt ARP-Daten eine zweite Daten von dedizierten Fehlerprüfbits für die Benutzung bei der Fehlererfassung und/oder -korrektur in den Inhalten des Daten-Abschnitts enthalten kann.
Nach der Beschreibung eines für die Implementierung der Erfindung geeigneten Netzes und von ARP-Paketen gemäß der Erfindung wird nun eine exemplarische ARP-Kommunikation beschrieben.
In einer exemplarischen ARP-Kommunikation gemäß der Erfindung möchte der Knoten 0 an dem Bus 0 (oder der "Knoten 10", wie in 2 dargestellt) die physikalische Adresse des Knotens mit der IP-Adresse 4 (oder des "Knotens 18", wie in 2 dargestellt) erfahren. Deshalb sendet der Knoten 10 an alle Knoten in dem Netz ein ARP-Anforderungs-Paket mit dem in 4 dargestellten Format – das Paket wird über die Brücke zu den Knoten an dem Bus 1 gesendet (siehe 2). Wie oben erwähnt wurde, enthält das Anforderungspaket in dem Abschnitt ARP-Header ein Ziel-Offset und in dem Abschnitt ARP-Daten eine Ziel-IP-Adresse. In dem vorliegenden Beispiel enthalten die ARP-Daten die Ziel-IP-Adresse "4".
Beim Empfang des Broadcast-Anforderungspakets sendet jeder Knoten in dem Netz die ARP-Daten des Pakets an die durch den Ziel-Offset gekennzeichnete Adresse. Jeder Knoten überprüft dann die in den ARP-Daten der Anforderung angegebene Ziel-IP-Adresse, und wenn die Ziel-IP-Adresse nicht mit der IP-Adresse des überprüfenden Knotens übereinstimmt, ignoriert der überprüfende Knoten die Anforderung. Falls die Ziel-IP-Adresse mit der IP-Adresse des überprüfenden Knotens übereinstimmt, erzeugt der überprüfende Knoten ein ARP-Antwort-Paket wie das in 5 dargestellte Antwortpaket. Wenn der Knoten 18 so die Ziel-IP-Adresse des Anforderungspakets prüft, stellt er fest, daß er der gewünschte Rezipient ist und geht zur Erzeugung eines ARP-Antwort-Pakets über.
Die Erzeugung des ARP-Antwort-Pakets wird übrigens durch die Verwendung des IP-Protokolls vereinfacht. Indem er aus dem ARP-Header des ARP-Antwort-Pakets ersieht, daß es sich um das IP-Protokoll handelt, kann der Knoten, der das Antwortpaket erzeugt, den Antwort-Ziel-Offset (48 Bits) bilden, indem er aus der Antwort-Sender-Adresse (64 Bits) die Antwort-Ziel-ID (16 Bits) extrahiert.
Eine ARP-Kommunikation gemäß der Erfindung hat Vorteile gegenüber früheren ARP-Systemen. Einer dieser Vorteile ist die reduzierte Rechenbelastung in der CPU des antwortenden Knotens, die daraus resultiert, daß in dem Antwortpaket eine Offset-Adresse des antwortenden Knotens enthalten ist. Und zwar ermöglicht es die Einbeziehung der Offset-Adresse des antwortenden Knotens in das Antwortpaket dem anfordernden Knoten, die Offset-Adresse des antwortenden Knotens zu gewinnen und anschließend die Information direkt zu einem Anwendungsprogramm zu senden, das sich an der Offset-Adresse befindet. Dadurch kann die CPU des antwortenden Knotens umgangen werden.
Ein weiterer Vorteil besteht in der Möglichkeit, ARP-Pakete unterschiedlicher Länge unterzubringen. Wie oben erwähnt wurde, ermöglicht es die Einbeziehung der Offset-Adresse des antwortenden Knotens in das Antwortpaket, die CPU des antwortenden Knotens von der Interpretation der nachfolgend empfangenen Pakete zu entlasten. Es ist deshalb nicht erforderlich, Pakete, die in dem antwortenden Knoten empfangen werden, in dem CPU-Puffer des antwortenden Knotens temporär zu speichern, und die Größe der Pakete, die benutzt werden können, wird durch die Größe des CPU-Puffers nicht eingeschränkt (d.h. die Pakete müssen nicht in den CPU-Puffer passen). Deshalb ermöglicht die Erfindung eine größere Flexibilität in der Paketlänge.
Als Nächstes wird eine RARP-Kommunikation gemäß der Erfindung beschrieben.
6 und 7 zeigen ein exemplarisches RARP-Anforderungs-Paket gemäß der Erfindung bzw. ein exemplarisches RARP-Antwort-Paket gemäß der Erfindung.
Wie im Fall der ARP-Kommunikation kann in dem Netz von 2 auch RARP-Kommunikation implementiert werden, wobei die Adressen-Cache-Tabelle von 3 benutzt wird. Die RARP-Pakete von 6 und 7 gleichen den ARP-Paketen von 4 bzw. 5. Deshalb werden nur die Unterschiede zwischen den jeweiligen ARP- und RARP-Paketen diskutiert.
Aus 6 ist ersichtlich, daß das RARP-Anforderungs-Paket die gleichen ersten fünf primären Abschnitte enthält wie das ARP-Anforderungs-Paket, sich von dem ARP-Anforderungs-Paket jedoch in dreien der primären Abschnitte unterscheidet. Der Abschnitt RARP-LLC/SNAP-Header enthält einen Resolution-Protokoll-Indikator (d.h. Bits, die den String 0×8035 repräsentieren), der anzeigt, daß der Protokolltyp, auf den das Anforderungspaket bezogen ist, RARP statt ARP ist. Weiterhin enthält der Abschnitt RARP-Header einen Operations-Indikator, der eine Information enthält, die anzeigt, daß der Operationstyp, auf den sich das Paket bezieht, eine RARP-Anforderung statt einer ARP-Anforderung ist. Schließlich enthält der Abschnitt RARP-Daten nicht die IP-Adresse des Sender-Knotens, sondern einen Indikator, der anzeigt, daß die IP-Adresse des Senders unbestimmt ist (d.h. Bits, die einen String von Nullen anzeigen). Das Fehlen der IP-Adresse des anfordernden Knotens ist mit der RARP-Operation konsistent, weil der wahre Grund für die Erzeugung von RARP-Anforderungen darin besteht, daß der anfordernde Knoten seine eigene IP-Adresse bestimmen kann.
Das RARP-Antwort-Paket unterscheidet sich von dem ARP-Antwort-Paket in zweien der primären Abschnitte. Der Abschnitt RARP-LLC/SNAP-Header enthält einen Resolution-Protokoll-Indikator (d.h. Bits, die den String 0×8035 repräsentieren), der anzeigt, daß der Protokolltyp, auf den sich das Anforderungs-Paket bezieht, RARP statt ARP ist, und der Abschnitt RARP-Header enthält einen Operations-Indikator mit einer Information, die anzeigt, daß der Operations-Typ, auf den sich das Paket bezieht, RARP-Antwort statt ARP-Antwort ist.
Wenn eine RARP-Kommunikation initiiert wird, erzeugt ein Knoten, der seine eigene IP-Adresse bestimmten möchte, ein RARP-Anforderungs-Paket, wie dies oben beschrieben wurde. Die RARP-Anforderung wird an alle Knoten in dem Netz (z.B. dem Netz von 2) gesendet, und ein Knoten, der der Beantwortung von RARP-Anforderungen zugeteilt ist (z.B. ein Server), bestimmt die IP-Adresse des anfordernden Knotens und erzeugt eine RARP-Antwort. Bei der Bestimmung der IP-Adresse des anfordernden Knotens bestimmt der RARP-Antwort-Knoten zunächst die physikalische Adresse des anfordernden Knotens durch Bezugnahme auf die Knoten-ID des Sender-Knotens, wie sie in dem asynchronen Paket-Header der RARP-Anforderung festgelegt ist, alternativ durch Bezugnahme auf die eindeutige Knoten-ID des Sender-Knotens, wie sie in dem Daten-Abschnitt der RARP-Anforderung angegeben ist. Sobald die physikalische Adresse des anfordernden Knotens bestimmt wurde, benutzt der antwortende Knoten seine Adressen-Cache-Tabelle (z.B. die Tabelle von 3) für Querbezüge der physikalischen Adresse (Knoten-ID oder eindeutige Knoten-ID) des anfordernden Knotens zu der IP-Adresse des anfordernden Knotens, und fügt die IP-Adresse des anfordernden Knotens in den RARP-Datenabschnitt des RARP-Antwort-Pakets ein.
Wenn z.B. der Knoten 0 des Busses 0 (Knoten 10 in 2) ein Server ist und der Knoten 1 des Busses 1 (Knoten 18) seine IP-Adresse bestimmen möchte, sendet der Knoten 18 an alle eine RARP-Anforderung, der seine eindeutige Knoten-ID ("641") enthält. Der Knoten 10 empfängt die Anforderung und benutzt die Adressen-Cache-Tabelle von 3 für einen Querbezug der empfangenen eindeutigen Knoten-ID "641" mit der IP-Adresse des Knotens 18 ("4"). Der Knoten 10 fügt dann die bestimmte IP-Adresse "4" in ein RARP-Antwort-Paket ein und sendet das Antwort-Paket an den Knoten 18.
Ein Vorteil der RARP-Signalisierung gemäß der Erfindung besteht darin, daß ein Netz, das eine solche Signalisierung implementiert, weniger anfällig gegen Bus-Rücksetzungen ist. In früheren Systemen kann sich, wie oben beschrieben, die physikalische Adresse der Knoten in dem Netz ändern, wenn ein Netz-Bus zurückgesetzt wird, was zu inkorrekten RARP-Querbezügen führen kann. Wenn z.B. der Bus 1 des Netzes von 2 zurückgesetzt wird, kann sich die Knoten-ID des Knotens 1 an dem Bus 1 (Knoten 18) von "1" in "3" ändern. Wenn der Knoten 18 anschließend eine RARP-Anforderung sendet, die seine Knoten-ID "3" enthält, und der antwortende Knoten die Tabelle von 3 für den Querbezug der Knoten-ID benutzt, wird die IP-Adresse des Knotens 18 unkorrekt als "7" ermittelt. Die vorliegende Erfindung ermöglicht hingegen Querbezüge von IP-Adressen über eindeutige Knoten-IDs. Da eindeutige Knoten-IDs sich beim Auftreten von Bus-Rücksetzungen nicht ändern, sichert ihre Benutzung bei RARP-Querbezügen die korrekte Bestimmung der IP-Adresse eines anfordernden Knotens. Somit würde in dem Beispiel der antwortende Knoten die Cache-Tabelle benutzen, um einen korrekten Querbezug der eindeutigen Knoten-ID des Knotens 18 zu der IP-Adresse "4" herzustellen.
Es wurden Ausführungsbeispiele der vorliegenden Erfindung beschrieben, wobei der einschlägige Fachmann ohne weiteres erkennt, daß zahlreiche Änderungen vorgenommen werden können, ohne daß dadurch der Rahmen der Erfindung verlassen wird. So wurde die Erfindung z.B. im Kontext von IEEE-1394-Übertragungen beschrieben, kann jedoch auch in dem Kontext von IPX-Übertragungen und Apple-Talk-Übertragungen angewendet werden.

Claims

Verfahren zur Durchführung einer Kommunikation über ein Netzwerk, das mehrere Knoten aufweist, mit den Verfahrensschritten: Senden eines Adress-Resolution-Protocol-Anforderungspakets von einem ersten Netzknoten (10, 12, 14) zu einem zweiten Netzknoten (16, 18, 20, 22) und Senden eines Adress-Resolution-Protocol-Antwortpakets von dem zweiten Knoten (16, 18, 20, 22) zu dem ersten Knoten (10, 12, 14), wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten (16, 18, 20, 22) befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens (16, 18, 20, 22) angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Verfahren nach Anspruch 1, bei dem die Offset-Adresse in einem 64-Bit-String enthalten ist.
Verfahren nach Anspruch 1 oder 2, bei dem das Anforderungspaket eine eindeutige Knoten-ID enthält, die den ersten Knoten (10, 12, 14) identifiziert.
Verfahren nach Anspruch 1, 2 oder 3 mit dem weiteren Verfahrensschritt, daß Kommunikationspakete von dem ersten Netzknoten zu dem zweiten Netzknoten gesendet werden.
Verfahren nach Anspruch 4, bei dem Kommunikationspakete nach dem Internet-Protokoll verarbeitet werden. 6, Verfahren nach Anspruch 4 oder 5, bei dem in dem zweiten Knoten empfangene Kommunikationspakete vor einer Verarbeitung der Pakete zu dem durch die Offset-Adresse angegebenen Ort übermittelt werden.
Verfahren nach Anspruch 1, 2, 3, 4,5 oder 6. bei dem das Netzwerk einen oder mehrere IEEE-1394-Busse (24, 26) aufweist.
Adress-Resolution-Protocol-Antwortpaket, das eine physikalische Adresse enthält, die einen Ort eines Knotens in einem Netzwerk angibt, der das Antwortpaket erzeugt, sowie eine Offset-Adresse, die innerhalb des Knotens einen Ort eines Anwendungsprogramms zur Verarbeitung von Kommunikationspaketen angibt.
Kommunikationsnetzwerk mit einer Mehrzahl von Knoten (10 – 22), das aufweist: erste Mittel (10, 12, 14), die so eingerichtet sind, daß sie ein Adress-Resolution-Protocol-Anforderungspaket von einem ersten Netzknoten zu einem zweiten Netzknoten senden, zweite Mittel (16, 18, 20, 22), die so eingerichtet sind, daß sie ein Adress-Resolution-Protocol-Antwortpaket von dem zweiten Knoten zu dem ersten Knoten senden, wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Netzwerk nach Anspruch 9, bei dem die Offset-Adresse in einem 64-Bit-String enthalten ist.
Netzwerk nach Anspruch 9 oder 10, bei dem das Anforderungspaket eine eindeutige Knoten-ID enthält, die den ersten Knoten (10, 12, 14) identifiziert.
Netzwerk nach Anspruch 9, 10 oder 11, das einen oder mehrere IEEE-1394-Busse (24, 26) aufweist.
Netzwerk nach einem der Ansprüche 9 bis 12, das so ausgebildet ist, das es Kommunikationspakete von einem zu einem anderen der genannten Knoten sendet.
Netzwerk nach Anspruch 13, bei dem Kommunikationspakete nach dem Internet-Protokoll verarbeitet werden.
Gerät zu Verwendung als Knoten in einem Kommunikationsnetzwerk, wobei das Gerät Mittel aufweist, die so eingerichtet sind, daß sie als Reaktion auf ein empfangenes Adress-Resolution-Protocol-Anforderungspaket ein Adress-Resolution-Protocol-Antwortpaket erzeugen, das die physikalische Adresse des Geräts enthält, sowie eine Offset-Adresse, die innerhalb des Geräts den Ort eines Anwendungsprogramms zur Verarbeitung von Kommunikationspaketen angibt
Gerät nach Anspruch 15, bei dem Kommunikationspakete, die in dem Knoten empfangene Kommunikationspakete vor einer Verarbeitung der Pakete zu dem durch die Offset-Adresse angegebenen Ort übermittelt werden.
Verfahren zur Durchführung einer Kommunikation über ein Netzwerk, das mehrere Knoten aufweist, mit den Verfahrensschritten: Senden eines Reverse-Adress-Resolution-Protocol-Anforderungspakets von einem ersten Netzknoten (10, 12, 14) zu einem zweiten Netzknoten (16, 18, 20, 22), wobei das Anforderungspaket eine eindeutige Knoten-ID enthält, die den ersten Knoten (10, 12, 14) identifiziert, Senden eines Reverse-Adress-Resolution-Protocol-Antwortpakets von dem zweiten Knoten (16, 18, 20, 22) zu dem ersten Knoten (10, 12, 14), wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten (16, 18, 20, 22) befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens (16, 18, 20, 22) angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Verfahren nach Anspruch 17, bei dem die Offset-Adresse in einem 64-Bit-String enthalten ist.
Verfahren nach Anspruch 17 oder 18 mit dem weiteren Verfahrensschritt, daß Kommunikationspakete von dem ersten Netzknoten zu dem zweiten Netzknoten gesendet werden.
Verfahren nach Anspruch 19, bei dem Kommunikationspakete nach dem Internet-Protokoll verarbeitet werden.
Verfahren nach Anspruch 19 oder 20, bei dem in dem zweiten Knoten empfangene Kommunikationspakete vor einer Verarbeitung der Pakete zu dem durch die Offset-Adresse angegebenen Ort übermittelt werden.
Verfahren nach Anspruch 17, 18, 10, 20 oder 21, bei dem das Netzwerk einen oder mehrere IEEE-1394-Busse (24, 26) aufweist.
Kommunikationsnetzwerk mit einer Mehrzahl von Knoten (10 – 22), das aufweist: erste Mittel (10, 12, 14), die so eingerichtet sind, daß sie ein Reverse-Adress-Resolution-Protocol-Anforderungspaket von einem ersten Netzknoten zu einem zweiten Netzknoten senden, wobei das Anforderungspaket eine eindeutige Knoten-ID enthält, die den ersten Knoten (10, 12, 14) identifiziert. zweite Mittel (16, 18, 20, 22), die so eingerichtet sind, daß sie ein Reverse-Adress-Resolution-Protocol-Antwortpaket von dem zweiten Knoten zu dem ersten Knoten senden, wobei das Antwortpaket eine physikalische Adresse und eine Offset-Adresse enthält, die physikalische Adresse den Ort innerhalb des Netzwerks angibt, an dem sich der zweite Knoten befindet, und die Offset-Adresse einen Ort innerhalb des zweiten Knotens angibt, an dem ein Anwendungsprogramm Kommunikationspakete verarbeitet.
Netzwerk nach Anspruch 23, bei dem die Offset-Adresse in einem 64-Bit-String enthalten ist.
Netzwerk nach Anspruch 23 oder 24, das einen oder mehrere IEEE-1394-Busse (24, 26) aufweist.
Netzwerk nach Anspruch 23, 24 oder 25, das so ausgebildet ist, das es Kommunikationspakete von einem zu einem anderen der genannten Knoten sendet.
Netzwerk nach Anspruch 26, bei dem Kommunikationspakete nach dem Internet-Protokoll verarbeitet werden.