-
STAND DER
TECHNIK
-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft Computersysteme und im Besonderen
Systeme und Verfahren zur Kopplung von Nachrichten zwischen vernetzten Computern.
-
Beschreibung
des Stands der Technik
-
Im
Zuge der immer umfassenderen Nutzung von Computern und der immer
leistungsfähiger
werdenden Computer besteht zunehmendes Interesse an der Nutzung
von Power-Management-Systemen, die dafür sorgen sollen, den Strom-
bzw. Energieverbrauch von Computern im Ruhezustand so gering wie
möglich
zu halten. Die Advanced Control And Power Interfache („ACPI"), gesponsort von
Intel, Microsoft und Toshiba ist ein Beispiel für ein derartiges Power-Management-Protokoll
(ACPI V.1 ist unter www.teleport.com/~acpi erhältlich). Ein Computer, der
ACPI implementiert, wechselt zum Beispiel auf Anweidung durch das
lokale Betriebssystem in einen Zustand mit niedrigerem Stromverbrauch
(„niedriger Leistungszustand"), wenn ausgewählte „Ruhezustände" detektiert werden.
In einem vernetzten Computer, schaltet ACPI die CPU und die unterstützende Logik
eines Computers im Ruhezustand in einen Leistungszustand um, der
im Einklang mit der Rolle des Computers in Netzwerkoperationen die
geringste Leistungsaufnahme bereitstellt. Dieser niedrige Leistungszustand
verlässt
für gewöhnlich die
Netzwerksteuereinheit des Computers, die den Computer mit dem Netzwerkmedium
in einem Bereitschaftszustand koppelt, um das Netzwerk in Bezug
auf interessante „Ereignisse" zu überwachen.
Zu diesen Ereignissen zählen
zum Beispiel Telefonanrufe oder Nachrichtenpakete. Wenn die Netzwerksteuereinheit
diese Ereignisse detektiert, leitet sie an dem Computer einen Übergang
bzw. Wechsel in einen höheren
Leistungszustand ein, in dem die durch die CPU implementierten Kommunikationsprogramme
(„Kommunikationsstapel") auf den Anruf oder
das Nachrichtenpaket ansprechen.
-
Wenn
sich ein Computer einmal in seinem höheren Leistungszustand befindet,
ist die einzige von ihm angeforderte Maßnahme häufig die Reaktion bzw. Antwort
auf eine verhältnismäßig einfache
Statusabfrage. In der folgenden Beschreibung betrifft der Begriff „Statusabfrage" bzw. „Statusanforderung" eine Nachricht,
die Informationen auf verhältnismäßig niedriger
Ebene zu dem Zustand des Computers anfordert. Diese Informationen
umfassen statische Informationen über den Computer selbst oder
Informationen, die selbstverständlich überwacht
bzw. verwaltet werden, wenn die CPU arbeitet. Ein allgemein bekanntes
Beispiel für
eine Statusabfrage ist die IP-Echoabfrage oder Ping. IP-Echoabfragen werden für gewöhnlich durch
Server erzeugt werden, die Netzwerkverwaltungssoftware ausführen, um
zu bestimmen, ob ein oder mehrere Zielcomputer mit dem Netzwerk
verbunden sind und sich in einem funktionstüchtigen Zustand befinden. Ein
Knoten befindet sich in einem funktionstüchtigen Zustand, wenn er eingeschaltet
wird, unabhängig
von dem aktuellen Leistungszustand des Knotens. Ein Computer, der eine
Echoabfrage empfängt,
antwortet, indem eine verhältnismäßig einfache
Antwort erzeugt wird, wenn die Abfrage detektiert wird. Im Allgemeinen
können Statusabfragen
dazu verwendet werden, das Vorhandensein von Computern in einem
Netzwerk zu überprüfen, Statistiken
zu Netzwerkoperationen zu sammeln, den Verkehr an verschiedenen
Knoten zu überwachen
und den Bestand der Einrichtungen zu verfolgen. Viele Statusabfragen
werden periodisch von der Netzwerkadministrationssoftware zur Überwachung
des Zustands des Netzwerks übertragen.
-
Trotz
der verhältnismäßig einfachen
Beschaffenheit der von Statusabfragen gesuchten Informationen wird
die vollständige
Kommunikationsinfrastruktur des Computers zur Verarbeitung und zum Antworten
auf diese Nachrichten in vielen Fällen eingesetzt. Wenn sich
die abfragenden und antwortenden Computer zum Beispiel in verschiedenen
Netzwerken befinden, verlässt
sich der antwortende Computer darauf, dass die Kommunikationsinfrastruktur eine
lenkbare Antwort auf die Statusabfrage erzeugt. Im Besonderen implementieren
die CPU und andere funktionale Elemente des Systems den benötigten Übertragungsprotokollstapel
für das
Lesen jeder Anforderungsnachricht und zum Erzeugen einer entsprechenden
Antwort. Diese Routinen stellen die Leitinformationen bereit, die
erforderlich sind, um die entsprechenden Informationen zu dem Knoten
zurückzuführen, von
dem die Statusabfrage stammt.
-
Wenn
ein Computer in einem niedrigen Leistungszustand eine Statusabfrage
empfängt,
löst die Netzwerksteuereinheit
des Computers den Wechsel in einen Leistungszustand aus, in dem
die CPU und deren unterstützende
Logik genügend
Leistung für den
Betrieb zur Verfügung
haben. Die CPU führt
die Übertragungs-
bzw. Kommunikationsroutinen aus, welche die Abfrage verarbeiten,
und erzeugt eine entsprechende Antwort, bevor in einen niedrigen Leistungszustand
zurückgekehrt
wird. Periodische Statusabfragen laufen somit wiederholt zwischen niedrigen
und hohen Leistungszuständen
durch einen Computer im Ruhezustand. Dies reduziert die Zeit, die
der Computer im Ruhezustand in dem niedrigen Leistungszustand verbringt,
und der Wechselvorgang selbst verbraucht zusätzliche Leistung. Die Verarbeitung
dieser Statusabfragen kann somit die Leistungseffizienz von Computern
reduzieren und die Erhaltungsstrategie des Power-Management-Systems
schwächen.
-
Eine
mögliche
Lösung
für dieses
den Leistungs- bzw. Energieverbrauch betreffenden Problem ist das
Hinzufügen
eines Kommunikationsstapels zu der Netzwerksteuereinheit, um Statusabfragen
zu verarbeiten, wenn sich die CPU und ihre unterstützende Logik
in einem niedrigen Leistungszustand befinden. Dieser Ansatz fügt der Netzwerksteuereinheit jedoch
erhebliche Schaltkreisanordnungen hinzu. Zudem erfordert er ein
verhältnismäßig komplexes Synchronisierungssystem
zur Koordination des Kommunikationsstapels in der Netzwerksteuereinheit
mit dem durch die CPU implementierten Kommunikationsstapel. Der
zuletzt genannte Stapel wird weiter für die Verarbeitung komplexerer
Nachrichten benötigt. Aus
diesen und anderen Gründen
wird es allgemein als unpraktisch angesehen, einen zusätzlichen
Kommunikationsstapel in der Netzwerksteuereinheit bereitzustellen.
-
EP-A-0777171
offenbart eine Netzwerksteuereinheit mit Vollleistungs- und Niederleistungsmodi und
mit einem verbesserten Rahmenadressierungsabstimmungssystem. Wenn
das in dem niedrigen Leistungsmodus arbeitende Rahmenadressierungsabstimmungssystem
einen an die Netzwerksteuereinheit adressierten Rahmen detektiert,
wird die Steuereinheit in einen Weck- oder Vollleistungszustand
versetzt. Die Netzwerksteuereinheit tritt somit in einen Vollleistungszustand,
wenn sie eine an die Netzwerksteuereinheit adressierte Nachricht
empfängt.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Vorgesehen
ist gemäß einem
ersten Aspekt der vorliegenden Erfindung eine Netzwerksteuereinheit
gemäß dem gegenständlichen
Anspruch 1.
-
Vorgesehen
ist gemäß einem
zweiten Aspekt der vorliegenden Erfindung ein Verfahren gemäß dem gegenständlichen
Anspruch 4.
-
Vorgesehen
ist gemäß einem
dritten Aspekt der vorliegenden Erfindung ein Computersystem gemäß dem gegenständlichen
Anspruch 7.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
vorliegende Erfindung ist in den anhängigen Zeichnungen durch Beispiele
veranschaulicht, wobei die gleichen Elemente darin mit den gleichen Bezugsziffern
bezeichnet sind. Die Zeichnungen offenbaren verschiedene Ausführungsbeispiele
der Erfindung, die lediglich Veranschaulichungszwecken dienen und
welche den Umfang der Erfindung nicht einschränken. In den Zeichnungen zeigen:
-
1A eine
schematische Darstellung eines Netzwerks, in dem die vorliegende
Erfindung ausgeführt
werden kann;
-
1B eine
schematische Darstellung eines Übertragungsprotokolls,
das zur Kopplung von Nachrichten zwischen den Knoten des Netzwerks
aus 1A verwendet wird;
-
2 ein
Blockdiagramm einer herkömmlichen
Nachricht zur Übertragung
eines Datagramms zwischen den Knoten eines Computernetzwerks;
-
3 ein
Blockdiagramm einer modifizierten Statusabfragenachricht zur Verarbeitung
durch eine Netzwerksteuereinheit gemäß der vorliegenden Erfindung;
-
4 ein
Blockdiagramm eines Ausführungsbeispiels
einer Netzwerksteuereinheit, mit Abfrageerkennungs- und Daten-Routing-Modulen gemäß der vorliegenden
Erfindung;
-
5 ein
Blockdiagramm eines Ausführungsbeispiels
der Nebenschlussschaltung aus 4;
-
6 ein
Blockdiagramm eines anderen Ausführungsbeispiels
der Nebenschlussschaltung aus 4; und
-
7 ein
Flussdiagramm eines Verfahrens zur Verarbeitung der Statusabfrage
aus 3 gemäß der vorliegenden
Erfindung.
-
GENAUE BESCHREIBUNG
DER ERFINDUNG
-
In
der folgenden Beschreibung sind zahlreiche besondere Einzelheiten
ausgeführt,
um ein umfassendes Verständnis
der vorliegenden Erfindung zu vermitteln. Der Durchschnittsfachmann
auf dem Gebiet, der von der vorliegenden Offenbarung profitiert,
erkennt jedoch, dass die vorliegende Erfindung auch ohne diese besonderen
Einzelheiten ausgeführt
werden kann. In anderen Fällen
wurde auf die genaue Beschreibung allgemein bekannter Verfahren,
Abläufe,
Komponenten und Schaltungen verzichtet, um die Merkmale der vorliegenden
Erfindung besser in den Vordergrund zu stellen.
-
In
erstem Bezug auf die Abbildung aus 1A zeigt
diese ein Netzwerk 100, in dem die vorliegende Erfindung
eingesetzt werden kann. Das Netzwerk 100 weist ein erstes
Teilnetzwerk 110, ein zweites Teilnetzwerk 120 und
ein intervenierendes Netzwerk 140 auf, über welches das erste und das zweite
Teilnetzwerk 110, 120 miteinander gekoppelt sind.
Das intervenierende Netzwerk 140 kann zum Beispiel eines
oder mehrere Teilnetzwerke aufweisen, wie etwa Wide Area Networks
(WANs), Local Area Networks (LANs) sowie verkabelte und kabellose
Datenübermittlungsabschnitte.
-
Hiermit
wird festgestellt, dass die Teilnetzwerke 110, 120 selbst
Netzwerke darstellen. Sie werden in der Beschreibung als Teilnetzwerke
bezeichnet, um anzuzeigen, dass sie auch Teil eines größeren Netzwerks
sind, das auch das Internet 140 einschließt.
-
Die
Datenübertragungen
zwischen den Knoten in den ersten und zweiten Teilnetzwerken 110, 120 und
dem intervenierenden Netzwerk 140 befolgen alle ein Standard-Datenübertragungsprotokoll. Wenn
das intervenierende Netzwerk 140 zum Beispiel dem Internet
entspricht, handelt es sich bei dem Kommunikations- bzw. Datenübertragungsprotokoll für gewöhnlich um
eines der Protokolle der Familie der Internetprotokolle. Dazu zählen das
Transport Control Protocol („TCP"), das Unreliable
Datagram Protocl („UDP") und verschiedene
andere Protokolle, von denen viele in Verbindung mit dem Internet
Protocol („IP") verwendet werden,
wie zum Beispiel TCP/IP, UDP/IP, etc. Sofern keine größere Genauigkeit
erforderlich ist, werden diese Protokolle in der folgenden Beschreibung
als IPs bezeichnet.
-
Zu
Zwecken der Veranschaulichung ist das erste Teilnetzwerk 110 als
ein Ethernet-Netzwerk dargestellt, das einen Personalcomputer (PC) 102, eine
Workstation 106, einen Server 108 und einen Router 104 aufweist.
In ähnlicher
Weise umfasst das zweite Teilnetzwerk 120 in der Abbildung
ein Token Ring-Netzwerk,
das einen Personalcomputer 112, eine Workstation 116,
einen Großrechner 118 und
einen Router 114 aufweist. Die Router 104 und 114 verbinden
die Teilnetzwerke 110 und 120 entspricht mit dem
Internet (intervenierendes Netzwerk 140). Im Allgemeinen
werden Rechenvorrichtungen wie etwa die Personalcomputer 102, 104,
die Workstations 106, 116, der Server 108,
der Großrechner 118 und die
Router 104, 114 häufig als die Knoten des Netzwerks 100 bezeichnet.
Die vorliegende Erfindung ist nicht von der Art oder der Anzahl
der Rechenvorrichtungen in den Teilnetzwerken 110, 120 abhängig.
-
Die
Hauptvorteile der vorliegenden Erfindung werden realisiert, wenn
Nachrichten durch zwei oder mehr Netzwerke geführt werden, wie zum Beispiel
zwischen Konten in den (Teil)Netzwerken 110 und 120.
Sie eignet sich aber auch für
die Behandlung von Kommunikationen zwischen Knoten des gleichen
Teilnetzwerks, wie zum Beispiel des PC 102 und des Servers 108 in
dem Teilnetzwerk 110.
-
Eine
der wichtigsten Motivationen für
das Bilden von Computernetzwerken ist es, es den Rechenvorrichtungen,
welche die verschiedenen Knoten bilden, zu ermöglichen, miteinander zu kommunizieren. Dies
wird für
gewöhnlich
durch den Austausch von Nachrichtenpaketen oder Datagrammen erreicht.
Die Nachrichtenpakete können
heterogene Netzwerkumgebungen wie das Netzwerk 100 durchlaufen,
indem sie einem Standard-Übertragungsprotokoll
folgen. Die vorstehend genannten IPs sind kennzeichnend für die für Internet-basierte
Kommunikationen verwendeten IPs, wobei die vorliegende Erfindung
jedoch in Verbindung mit allen bekannten Übertragungsprotokollen einsatzfähig ist.
-
In
folgendem Bezug auf die Abbildung aus 1B sind
die Übertragungsprotokollstapel 152, 154, 156, 158 (gemeinsam „Übertragungsprotokollstapel 150") dargestellt, welche
die Ressourcen für die
Verarbeitung und Erzeugung von Nachrichten darstellen, die erforderlich
sind, um Nachrichtenpakete zwischen den Knoten der Teilnetzwerke 110 und 120 zu übertragen.
Im Besonderen stellen die Übertragungsstapel 152, 154, 156 und 158 die
mit Schichten aufgebaute Architektur dar, in der die Software- und
die Hardwareressourcen der entsprechenden Rechenvorrichtungen 108, 104, 114, 112 zur
Verarbeitung der Netzwerkübertragungen
organisiert sind. Zu diesen Ressourcen zählen für gewöhnlich die CPU, die unterstützende Logik
für die
CPU, durch die CPU implementierte Übertragungsroutinen und eine Netzwerksteuereinheit,
welche die Rechenvorrichtung mit dessen Teilnetzwerk koppelt. Die
in Schichten aufgebaute Architektur aus 1B ist
die Architektur der TCP/IP Protokolle, die zum Beispiel in IPng and
the TCP/IP Protocols von Stephen Thomas, John Wiley & Sons, New York,
USA (1996), beschrieben ist.
-
In
weiterem Bezug auf die Abbildung aus 1B umfassen
die Übertragungsprotokollstapel 152, 158 jeweils
Anwendungs-, Transport-, Internetwork- und Netztechnikschichten.
Die Anwendungsschicht stellt die Anwendungen dar, die auf einer
Rechenvorrichtung ausgeführt
werden, die Daten zu anderen Rechenvorrichtungen in dem Netzwerk überträgt und von
diesen empfängt.
Zu diesen Anwendungen zählen
Dateiübertragungsanwendungen, Emulationsanwendungen
für entfernte
Endgeräte
sowie E-Mail-Anwendungen. Die Transportschicht weist Module auf,
die Daten der Anwendungsschicht für eine zuverlässige Zustellung
verpacken und von anderen Netzwerkknoten empfangene Daten an die entsprechenden
Anwendungen verteilen. Diese Schicht entspricht ungefähr den TCP-
oder UDP-Abschnitten des Beispielprotokolls.
-
Die
Internetwork-Schicht weist Module auf, welche die verpackten Daten
von der Transportschicht in „Datagrammen" zur Übertragung über das Netzwerk
verpacken, wie etwa das Netzwerk 100, und wobei sie die
verpackten Daten aus den empfangenen Datagrammen zu der Transportschicht
weiterleiten. Im Besonderen erzeugt die Internetwork-Schicht einen
IP-Header für
jedes Datagramm. Der IP-Header weist IP-Adressen auf, die eindeutig den
ursprünglichen
Quellknoten und den bzw. die letztendlichen Zielknoten des Datagramms
unter allen knoten des Netzwerks 100 identifizieren. In
diesem Fall bezeichnet der ursprüngliche
Quellenknoten die Rechenvorrichtung, von welcher das Datagramm stammt,
und der letztendliche Zielknoten bezeichnet die Rechenvorrichtung(en),
die das Datagramm verarbeitet bzw. verarbeiten. Das Datagramm verläuft häufig durch
weitere Knoten zwischen den ursprünglichen Quellenknoten und
den letztendlichen Zielknoten bzw. Bestimmungsknoten, wobei diese
weiteren Knoten lediglich das Datagramm weiterleiten. Wie dies nachstehend
im Text beschrieben ist, obliegt die Formatierung des Datagramms
zur Übertragung
zwischen zwei beliebigen Knoten in dem Übertragungspfad zum größten Teil
der Netztechnikschicht. Die Internetwork-Schicht entspricht ungefähr dem IP-Abschnitt
zum Beispiel der TCP/IP- und
UDP/IP-Protokolle.
-
Die
Netztechnikschicht verpackt das Datagramm in einem Format, das sich
zur Übertragung über das
Teilnetzwerk eignet, mit dem der Knoten über dessen Netzwerksteuereinheit
gekoppelt ist. Das formatierte Datagramm wird häufig als Rahmen bzw. englisch
Frame bezeichnet. Wenn ein Rahmen zwischen Netzwerken übertragen
wird, weist er einen Header („NT-Header") auf, der dem Datagramm
vorangestellt ist, und einen Trailer bzw. Nachsatz („NT-Trailer"), der an das Datagramm
angehängt
ist. Der NT-Header und Trailer sind für die Art des durchlaufenen
Teilnetzwerks spezifisch. Der NT-Header weist die lokale Adresse
des Knotens in dem Teilnetzwerk auf, das den Rahmen erzeugt (lokaler
Quellenknoten) sowie die lokale Adresse des Ziels des Rahmens in
dem Teilnetzwerk. Im Gegensatz zu IP-Adressen sind die lokalen Adressen nur
innerhalb eines bestimmten Teilnetzwerks einzigartig und sie verändern sich,
wenn das Datagramm mit einem anderen Teilnetzwerk gekoppelt wird.
-
Die
lokalen/letztendlichen Quellen- und Zielknoten können in Bezug auf die Abbildung
aus 1A veranschaulicht werden. Für ein Datagramm, das das intervenierende
Netzwerk 140 zwischen dem Server 108 (dem ursprünglichen
Quellenknoten) an dem Teilnetzwerk 110 und dem PC 112 (dem
letztendlichen Zielknoten) in dem Teilnetzwerk 120 durchläuft, ist
der Server 108 der lokale Quellenknoten in dem Rahmen,
der das Teilnetzwerk 110 durchläuft, und der PC 112 ist
der lokale Zielknoten in dem Rahmen, der das Teilnetzwerk 120 durchläuft. Der
lokale Zielknoten in dem Rahmen in dem Teilnetzwerk 110 ist
der Router 104, der das Teilnetzwerk 110 mit dem intervenierenden
Netzwerk 140 koppelt. Der Router 104 modifiziert
für gewöhnlich den
NT-Header und NT-Trailer des empfangenen Rahmens gemäß der Art
der von dem Netzwerk 140 eingesetzten Technik bzw. Technologie.
Der lokale Quellenknoten in dem Rahmen in dem Teilnetzwerk 120 ist
der Router 114, der das Datagramm aus dem Internet empfängt und den
zugeordneten NT-Header und Trailer gemäß der Art der in dem Teilnetzwerk 120 eingesetzten
modifiziert. Das Datagramm bleibt über die verschiedenen Teilnetzwerke
konstant, wobei der Server 108 und der PC 112 entsprechend
in dem IP-Header als ursprüngliche
Quellenknoten und letztendliche Zielknoten angezeigt werden. Da
die Router 104, 114 für gewöhnlich nur Nachrichtenpakete
weiterleiten, die von anderen Knoten des Netzwerks 100 empfangen
werden, weisen die Stapel 152, 154 nur Internetwork- und
Netztechnikschichten auf.
-
In
folgendem Bezug auf die Abbildung aus 2 zeigt
diese ein Blockdiagramm eines Rahmens bzw. Frame 200 zur Übertragung über eines der
Teilnetzwerke des Netzwerks 100. Ein NT-Trailer 212 zeigt
das Ende eines Nachrichtenpakets 200 an und weist für gewöhnlich eine
Prüfsumme
zum Prüfen
der Zuverlässigkeit
der Übertragung
auf. Ein NT-Header 210 spezifiziert ein lokales Ziel (L_DST) 214 und
eine lokale Quelle (L_SRC) 216 für den Rahmen in dem aktuellen
Teilnetzwerk. Während
der Rahmen 200 zwischen den ursprünglichen Quellenknoten und
letztendlichen Ziel- bzw. Bestimmungsknoten durch verschiedene Teilnetzwerke
geleitet wird, werden die Ausführungen
des NT-Headers und NT-Trailers 210, 212 durch
die Übertragungsstapel der
Router und Switches modifiziert, welche die Teilnetzwerke miteinander
verbinde. Im Besonderen werden der NT-Header 210 und der
NT-Trailer 212 so modifiziert, dass sie die Netzwerktechnologie
widerspiegeln, wie z.B. Ethernet, Token Ring, FDDI, sowie das lokale
Ziel 214 und die lokale Quelle 216 in dem aktuellen
Teilnetzwerk. Die lokale Quelle 216 zeigt auf den ursprünglichen
Quellenknoten, wenn der Rahmen 200 das Teilnetzwerk kreuzt,
mit dem der ursprüngliche
Quellenknoten gekoppelt ist. In ähnlicher Weise
zeit das lokale Ziel 216 auf den letztendlichen Zielknoten,
wenn der Rahmen 200 das Teilnetzwerk kreuzt, mit dem der
letztendliche Zielknoten gekoppelt ist.
-
Auf
den NT-Header 210 folgt ein Datagramm 218, das
einen IP-Header 220 und
ein Datenfeld 230 umfasst. Der IP-Header 220 spezifiziert
ein letztendliches Ziel (U_DST) 222 und eine ursprüngliche
Quelle (O_SRC) 224 für
das Datagramm 218. Im Besonderen spezifiziert O_SRC 224 die
Internetprotokolladresse (IP-Adresse) des ursprünglichen Quellenknotens, wie
zum Beispiel in dem vorstehenden Beispiel des Servers 108,
während
U_DST 222 die IP-Adresse des Knotens spezifiziert, an den
das Datagramm letztendlich gerichtet ist. Der IP-Header 220 weist
für gewöhnlich zusätzliche
Felder auf, die zum Beispiel die Nachrichtenpriorität und die
Version des IP-Protokolls spezifizieren, die von dem Quellenknoten
eingesetzt werden. Der IP-Header 220 wird durch die Internetwork-Schicht
erzeugt und dem Datenfeld 230 vorangestellt, das Daten
aufweist, die durch die Anwendungsschicht erzeugt und durch die
Transportschicht formatiert werden.
-
In
herkömmlichen
Computervorrichtungen, wie zum Beispiel dem Server 108 und
den PCs 102, 112, sind die Module der Anwendungs-,
der Transport-, der Internetwork- und der Netztechnikschichten für gewöhnlich als
Softwareroutinen in der CPU der Rechen- bzw. der Computervorrichtung
implementiert. Folglich setzen es die Rechenvorrichtungen allgemein
voraus, dass ihre CPUs und die unterstützende Logik den Rahmen 200 verarbeiten,
das Datagramm 218 abrufen und ein Antwortdatagramm mit dem
entsprechenden NT-Header 210 und dem NT-Trailer 212 erzeugen.
Aus diesen Gründen
erfordert der Empfang des Rahmens 200 durch eine Rechenvorrichtung
in einem niedrigen Leistungszustand, wie zum Beispiel des PC 112,
dass die CPU und ihre unterstützende
Logik aus dem niedrigen Leistungszustand in den hohen Leistungszustand wechseln,
um die entsprechenden Softwareroutinen auszuführen.
-
Die
vorliegende Erfindung ermöglicht
es, dass eine Rechenvorrichtung mit anderen Rechenvorrichtungen
kommuniziert, die über
ein Netzwerk mit der Vorrichtung gekoppelt sind, ohne die Power-Management-Systeme
zu beeinträchtigen,
die an diesen Rechenvorrichtungen arbeiten. Im Besonderen ermöglicht die
vorliegende Erfindung es einem ersten Computer, Status-, Bestands-
und andersartige Informationen von einem zweiten Computer abzurufen,
der sich in einem Zustand mit geringem Leistungs- bzw. Stromverbrauch
befindet, ohne dass dies bewirkt, dass der Kern des zweiten Computers
(dessen CPU und unterstützende
Logik) in einen Zustand mit höherem
Leistungsverbrauch wechseln.
-
In
einem Ausführungsbeispiel
der Erfindung ist der zweite Computer über eine Netzwerksteuereinheit,
die eine Nebenschlussschaltung aufweist, mit dem Netzwerk gekoppelt.
Die Nebenschlussschaltung weist ein Abfrageerkennungsmodul zum Erkennen
von Anforderungsnachrichten (nachstehend „Statusabfragen") auf, die bearbeitet
werden können,
ohne die CPU und die unterstützende
Logik des zweiten Computers aufzurufen. Die Nebenschlussschaltung
weist ferner ein Daten-Routing-Modul
zum Extrahieren von NT-Header-Daten und Prototyp-Antwortdaten aus
der Statusabfrage auf, sowie zum Erzeugen einer vollständig lenkbaren
Antwort auf die Statusabfrage von den abgerufenen Daten. Die Annahme
einer standardisierten Form für
diese Abfragen vereinfacht die zum Erzeugen von Antworten erforderlichen
Erkennungs- und Routing-Module.
-
In
folgendem Bezug auf die Abbildung aus 3 zeigt
diese ein Blockdiagramm eines Rahmens 300, mit einer Statusabfrage 302 zur
Verwendung in Verbindung mit der vorliegenden Erfindung. Wie in
der Abbildung aus 2 beginnt der Rahmen 300 mit
einem NT-Header 310, der entsprechende lokale Ziel- und Quellenknoten
LQ_DST 314 und LQ_SRC 316 spezifiziert und mit
einem NT-Trailer 312 endet. Die Statusabfrage 302,
der Datagrammabschnitt des Rahmens 300, weist einen IP-Header 320 auf,
der seinen letztendlichen Zielknoten und ursprünglichen Quellenknoten UR_DST 322 und OR_SRC 324 spezifiziert.
-
Zwei
zusätzliche
Merkmale der Statusabfrage 302 sind ein Erkennungscode 340 und
eine Prototypantwort 350. In dem offenbarten Ausführungsbeispiel
handelt es sich bei dem Erkennungscode 340 um eine spezifizierte
Bitfolge, die eine Nachricht als eine Statusabfrage 302 identifiziert.
In einem Ausführungsbeispiel
der Erfindung tastet eine Schaltkreisanordnung in einer Netzwerksteuereinheit
(4 bis 6) eine eingehende Nachricht
ab und bestimmt, ob diese den Erkennungscode 340 aufweist,
d.h. ob es sich bei der Nachricht um eine Statusabfrage handelt.
Wenn eine Statusabfrage 302 erkannt wird, ruft die Schaltkreisanordnung
in der Netzwerksteuereinheit ausgesuchte Daten aus dem Rahmen ab
und erzeugt eine Antwortnachricht aus den abgerufenen Daten, ohne
Rückgriff
auf die CPU oder unterstützende
Logik des Zielknotens.
-
Die
Prototypantwort 350 wird zur Gestaltung des IP-Abschnitts
der Antwort auf die Statusabfrage 302 verwendet. Die Prototypantwort 350R weist
einen IP-Header 320R auf, der entsprechend dessen letztendlichen
Zielknoten UR_DST 322R und ursprünglichen Quellenknoten OR_SCR 324R spezifiziert
und optional ein IP-Datenfeld 330R aufweist. Da die Prototypantwort 350 durch
die Statusabfrage 330 bereitgestellt wird, spezifiziert
UR_DST 322R die IP-Adresse des Quellenknotens, von dem
die Statusabfrage 300 stammt, d.h. OQ_SRC 324.
In ähnlicher Weise
spezifiziert OR_SRC 324R die IP-Adresse des in UQ_DST 322 bezeichneten
Zielknotens, d.h. den aktuellen Knoten. Bei Punkt zu Punkt übertragenen (Knoten
zu Knoten) Statusabfragen können
der ursprüngliche Quellenknoten
und der letztendliche Zielknoten der Antwort somit in der Prototypantwort 350 spezifiziert
werden, wenn die Abfrage erzeugt wird. Dies macht es überflüssig, den Übertragungsstapel des
entsprechenden Knotens aufzurufen, um den Datagrammabschnitt der
Antwort zu erzeugen.
-
Die
vorliegende Erfindung unterstützt
auch Statusabfragen, die als Multicast- oder Anycast-Nachrichten
(an mehrere oder beliebige Adressaten) ausgegeben werden, wobei
mehrere Zielknoten das Ziel des Quellenknotens sind. Wie vorstehend
handelt es sich bei dem letztendlichen Zielknoten für die Antwort
um den ursprünglichen
Quellenknoten der Abfrage, und er kann in der Prototypantwort spezifiziert
werden, wenn die Abfrage erzeugt wird. Jeder die Anforderung bzw.
Abfrage empfangende Knoten stellt seine IP-Adresse und seine lokale
Adresse an die IP-Quelle und entsprechende lokale Quellenfelder
des Antwortrahmens 300R unter Verwendung der Schaltkreisanordnung
der Netzwerksteuereinheit bereit.
-
Zusätzlich zu
UR_DST 322R und OR_SRC 324R kann die Prototypantwort 350 ferner
ein Datenfeld oder einen Platzhalter 330R aufweisen, dem
eine Daten-Routing-Schaltkreisanordnung
in der Netzwerksteuereinheit ausgesuchte Daten aus einem oder mehreren
Registern hinzufügt,
auf welche die Netzwerksteuereinheit zugreifen kann. Im Besonderen
kann ein Register Status-, Bestands- oder Zugangsdaten aufweisen,
welche der Quellenknoten benötigt,
um ausgesuchte Knoten in dem Netzwerk 100 zu verwalten,
zu überwachen
oder zu pflegen. Ähnliche
Register können
zum Speichern der IP-Adresse und lokaler Adressinformationen für den Knoten
zur Verwendung bei der Antwort auf Multicast- und Anycast-Nachrichten
verwendet werden.
-
In
folgendem Bezug auf 4 ist ein Ausführungsbeispiel
einer Netzwerksteuereinheit 400 zur Kopplung einer Rechenvorrichtung
mit einem Netzwerk gemäß der vorliegenden
Erfindung dargestellt. Ein Netzwerkschnittstellenmodul 410,
ein Paketerfassungsmodul 420 und Empfangs- und Sendepuffer 430, 434 bilden
entsprechend ein Front-End, das die Netzwerksteuereinheit 400 mit
dem physikalischen Netzwerk koppelt. Ein DMA-Modul 444 und
ein Peripherals Component Interconnect Interface (PCI IF) Modul 448 bilden
ein Back-End, das die Netzwerksteuereinheit 400 mit dem
Rest der Rechenvorrichtung koppelt. Ein Mikrocontroller 440 steuert
den Datenfluss zwischen dem Front-End und dem Back-End der Netzwerksteuereinheit 400.
Ebenfalls dargestellt ist ein optionales Register 490 zum
Speichern ausgewählter
Status-, Bestands- und verwandter Daten. In dem offenbarten Ausführungsbeispiel
ist eine Nebenschlussschaltung 450 zum Identifizieren und
Antworten auf Abfragepakete mit der Front-End-Logik der Netzwerksteuereinheit 400 gekoppelt.
-
Das
Netzwerkschnittstellenmodul 410 sorgt für die elektrische und mechanische
Kopplung zwischen dem Paketerfassungsmodul 420 und der
Netzwerkhardware, mit der die Netzwerksteuereinheit 400 gekoppelt
ist. Das Paketerfassungsmodul 420 weist eine Logik zur Überwachung
des Paketverkehrs des zugrunde liegenden Netzwerks auf, um zu bestimmen,
wann das Netzwerk zum Senden von Nachrichtenpaketen zur Verfügung steht.
In Bezug auf die Ethernet-Netzwerktechnologie implementiert das
Paketerfassungsmodul 420 für gewöhnlich ein Carrier Sense Multiple
Access/Collision Detection (CSMA/CD) Protokoll. In Bezug auf die
Token Ring Netzwerktechnologie bestimmt das Paketerfassungsmodul 420,
wann die Netzwerksteuereinheit 400 den Token empfängt, der
für die Übertragung
einer Nachricht über
das Netzwerk erforderlich ist.
-
Die
Puffer 430 und 434 dienen als entsprechende temporäre Speicher
für eingehende
und abgehende Nachrichten. Der Mikrocontroller 440 steuert
den Datenfluss zwischen den Puffern 430, 434 und
dem Rest der Rechenvorrichtungen über das DMA-Modul 444 und
die PCI IF 448.
-
In
dem offenbarten Ausführungsbeispiel
der Netzwerksteuereinheit 400 ist das Nebenschlussmodul 450 mit
dem Paketerfassungsmodul 420 gekoppelt, um eingehende Nachrichtenpakete
zu überwachen
und um auf Statusabfragen anzusprechen, wenn diese detektiert werden.
Die Konfiguration der Nebenschlussschaltung 450 in dem
Front-End der Netzwerksteuereinheit 400 beschränkt das
Ausmaß der
Logik, die zum Antworten auf eine Statusabfrage mit Strom versorgt
werden muss. Verschiedene andere nachstehend beschriebene Konfigurationen können vergleichbare
Stromeinsparungen bereitstellen.
-
Das
Nebenschlussmodul 450 weist eine Schaltkreisanordnung zum
Abrufen von Daten aus dem NT-Header 310 und der Prototypantwort 350 auf,
wenn eine Statusabfrage 302 identifiziert wird und einen
Antwortrahmen 300R (3) aus den
abgerufenen Daten bildet. Darüber
hinaus kann das Nebenschlussmodul 450 eine Schaltkreisanordnung aufweisen,
um in dem Antwortpaket 300R Status-, Bestands- und ähnliche
Daten zu integrieren, die in dem bzw. den Register(n) 490 zur
Verfügung
sehen.
-
In
erneutem Bezug auf die Abbildung aus 3 weist
der Rahmen 300 Daten in einer spezifischen bzw. bestimmten
Anordnung auf. Dies erleichtert das Abtasten einer Nachricht in
Bezug auf den Erkennungscode 340 und sofern zweckmäßig auch das
Erzeugen einer Antwort unter Verwendung von aus der Nachricht abgerufenen
Daten. Zum Beispiel umfasst der den Rahmen 300 darstellende
Bitstrom das lokale Ziel (LQ_DST 314), die lokale Quelle (LQ_316),
den IP-Header 320 und die Prototypantwort 350 in
entsprechender Reihenfolge bzw. Anordnung. Da die Länge und
die Anordnung dieser Datenfelder für jedes Protokoll spezifiziert
sind, muss die erforderliche Schaltkreisanordnung zum Abrufen und neuen
Anordnen der gewünschten
Daten nicht sehr komplex sein.
-
In
folgendem Bezug auf die Abbildung aus 5 ist ein
Ausführungsbeispiel
der Nebenschlussschaltung 550 dargestellt, die ein Abfragedetektionsmodul 550 und
ein Daten-Routing-Modul 570 umfasst. Das Abfragedetektionsmodul 550 weist
einen eingehenden Puffer 510 und eine Vergleichsschaltung 520 auf.
Der eingehende Puffer 510 ist so gekoppelt, dass er Nachrichtenpakete
von dem Paketerfassungsmodul 420 empfängt und Daten aus den empfangenen
Nachrichtenpaketen mit dem Back-End
der Netzwerksteuereinheit 400 oder der Daten-Routing-Schaltung 530 gemäß der Art
der empfangenen Nachricht koppelt. Im Besonderen ist die Vergleichsschaltung 520 so
gekoppelt, dass ausgesuchte Slots des eingehenden Puffers 510 für den Erkennungscode 340 gelesen
werden. Wenn der angezeigte Erkennungscode 340 vorhanden
ist, löst
die Vergleichsschaltung 520 das Daten-Routing-Modul 530 aus,
um Daten aus dem eingehenden Puffer 510 heraus zu koppeln.
In einem Ausführungsbeispiel
der Nebenschlussschaltung 450 werden Daten parallel aus
dem eingehenden Puffer 510 gekoppelt. Wenn der Erkennungscode 340 in
den ausgesuchten Slots des eingehenden Puffers 510 nicht
detektiert wird, wird das Nachrichtenpaket zu dem Back-End der Netzwerksteuereinheit 400 weitergeleitet.
-
Das
Daten-Routing-Modul 570 weist eine Routing-Schaltung 530 und
einen abgehenden Puffer 540 auf. Die Routing-Schaltung 530 ist
so gekoppelt, dass sie Daten von dem eingehenden Puffer 510 empfängt und
diese an ausgesuchte Slots des abgehenden Puffers 540 überträgt, wenn
eine Auslösung
durch die Vergleichsschaltung 520 erfolgt. Die Routing-Schaltung 530 kann
optionale Daten von dem Register 490 empfangen und diese
an ausgewählte
Slots des abgehenden Puffers 540 übertragen, wenn dies durch
die detektierte Statusabfrage angezeigt wird. Zum Beispiel können der
Knotenstatus oder Aktivitätsdaten
einem Datenfeld (548) des abgehenden Puffers 540 bereitgestellt
werden. IP-Adressinformationen können
einem IP-Header-Feld
(544) als Reaktion auf den Empfang einer Statusabfrage
bereitgestellt werden, die als Multicast- oder Anycast-Nachricht übertragen
wird.
-
In
dem offenbarten Ausführungsbeispiel
der Nebenschlussschaltung 450 sind die Slots des eingehenden
Puffers 510 in Felder 512, 514, 516 und 518 aufgeteilt,
die entsprechend LQ_DST 314, LQ_SRC 316, dem Erkennungscode 340 und
der Prototypantwort 350 des Abfragerahmens 300 entsprechen.
Die in den Feldern 512, 514 und 518 vorhandenen
Daten, wenn eine Statusabfrage empfangen wird, werden über die
Routing-Schaltung 530 entsprechend zu den Feldern 544, 542 und 546 des abgehenden
Puffers 540 gekoppelt. Die Routing-Schaltung 530 wird so ausgelöst, dass
sie Daten aus dem eingehenden Puffer 510 durch die Vergleichsschaltung 520 zu
dem abgehenden Puffer 540 speichert, wenn der Erkennungscode 340 in
dem Feld 516 detektiert wird.
-
Für die Statusabfragen 300,
die Daten aus dem Register 490 abfragen, werden die abgefragten bzw.
angeforderten Daten über
die Routing-Schaltung 530 dem Feld 548 bereitgestellt,
wenn die Schaltung durch die Vergleichsschaltung 520 ausgelöst wird.
Verschiedene Einträge
in dem Register 490 können abhängig von
dem Wert des Erkennungscodes 340 mit dem Feld 548 des
abgehenden Puffers 540 gekoppelt werden. Zur Erleichterung
der Erkennung von Statusabfragen wird der Erkennungscode 340 einem
leicht lokalisierbaren Feld in der Statusabfrage 300 zugeordnet.
In einem Ausführungsbeispiel handelt
es sich bei dem Erkennungscode 340 um einen allgemein bekannten
Port, der in einem Ziel-Port-Feld (nicht abgebildet) des IP-Headers 320 bezeichnet
ist. In einem alternativen Ausführungsbeispiel
kann der Erkennungscode 340 einem Bitfeld in dem Datensegment
der Abfrage 300 zugeordnet werden, die dem Antwortprototyp 350 vorangestellt ist.
Der NT-Trailer 312 wird für gewöhnlich durch ein Paketerfassungsmodul 420 bereitgestellt,
obgleich auch andere Implementierungen möglich sind.
-
In
einem Ausführungsbeispiel
der Nebenschlussschaltung 450 handelt es sich bei dem eingehenden
Puffer 510 und dem ausgehenden Puffer 540 um die
Empfangs- und Sendepuffer 430, 434 der Netzwerksteuereinheit 400.
In dem vorliegenden Ausführungsbeispiel
ermöglicht
der Empfangspuffer 430 sowohl serielle als auch parallele
Ausgaben, während
der Sendepuffer 434 serielle und parallele Eingaben ermöglicht.
Das vorliegende Ausführungsbeispiel
weist den Vorteil der Beschränkung
der Anzahl der erforderlichen Puffer für die Implementierung der Netzwerksteuereinheit 400 auf.
In einem anderen Ausführungsbeispiel
der Erfindung werden die Funktionen des Vergleichsmoduls 520 und
des Routing-Moduls 530 durch den Mikrocontroller 440 als Softwaremodul
implementiert. In einem weiteren Ausführungsbeispiel der Erfindung
können
diese Funktionen unter Verwendung verschiedener Kombinationen aus
Schaltkreisanordnungen, Software und Firmware implementiert werden.
-
In
folgendem Bezug auf die Abbildung aus 6 zeigt
diese ein alternatives Ausführungsbeispiel
der Nebenschlussschaltung 450, die den Bitstrom sozusagen
fliegend analysiert, der einem Nachrichtenpaket entspricht. In diesem
Fall wird der Bitstrom sowohl an den Modulpuffer 430 als
auch die Nebenschlussschaltung 450 gesteuert. Die Nebenschlussschaltung 450 weist
ein Routing-Modul 610 auf, das Datenfelder in einem Nachrichtenpaket
identifiziert und die zugeordneten Daten durch den MUX 620 zu
den Registern 630, 640, 650, 660 leitet.
Da die NT- und IP-Header-Felder bestimmte Bitgrößen aufweisen, kann das Routing-Modul 610 verschiedene
Datenfelder lokalisieren, indem die Bits ab dem Beginn des Nachrichtenpakets
gezählt
werden. Wenn das Routing-Modul 610 die Bits für ein bestimmtes
Feld erreicht, wird er MUX 620 ausgelöst, um die Bits an ein entsprechendes
Register 630, 640, 650 oder 660 bereitzustellen.
Zum Beispiel können die
Bitpositionen, die N_SRC, NT_DST, der Prototypantwort 350 und
dem Erkennungscode 340 einer Nachricht entsprechen, entsprechend
zu den Registern 630, 640, 650 und 660 geleitet
werden.
-
Das
Vergleichsmodul 670 kann bestimmen, ob es sich bei der
Nachricht um eine Statusabfrage handelt, indem die Bits in dem Register 660 mit
einem oder mehreren zulässigen
Erkennungscodes 340 verglichen werden. Wenn eine Statusabfrage identifiziert
wird, löst
das Vergleichsmodul 670 eine Zustandsmaschine 680 aus,
so dass ein Paket mit einem geeigneten NT-Header aus den Daten in
den Registern 630, 640 und 650 gebildet
wird. Die Daten aus dem NIC-Register 490 können dem
Antwortpaket hinzugefügt
werden, wenn dies durch den Erkennungscode angezeigt wird, und das
Antwortpaket kann durch die Zustandsmaschine 680 ausgegeben werden.
-
In
dem offenbarten Ausführungsbeispiel
sind die Daten aus einem Nachrichtenpaket in dem Puffer 430 und
der Nebenschlusschaltung 450 vorhanden. Wenn die Nachricht
folglich als eine Statusabfrage identifiziert ist, zeigt die Nebenschlussschaltung 450 der
Steuereinheit 400 an, dass sie die Antwort verarbeitet.
Dies verhindert es, dass die Daten in dem Puffer 430 durch
die Netzwerksteuereinheit 400 weiter verarbeitet werden,
und zudem verhindert es einen Wechsel der CPU des Knotens in einen
höheren Leistungszustand.
-
Die
Ausführungsbeispiele
des Erkennungsmoduls 550 und des Daten-Routing-Moduls 570 aus 6 sind
als dedizierte Schaltungen dargestellt. Allerdings können einige
oder alle dieser Module als Softwaremodule implementiert werden,
wie zum Beispiel durch einen Mikroprozessor oder einen integrierten
Prozessor.
-
In
folgendem Bezug auf die Abbildung aus 7 zeigt
diese ein Flussdiagramm eines Verfahrens 700 gemäß der vorliegenden
Erfindung zum Antworten auf Statusabfragen ohne den Aufruf der CPU
oder ihrer unterstützenden
Logik. Wenn eine Nachricht 710 empfangen wird, wird sie
in Bezug auf einen Erkennungscode abgetastet 720. In einem Ausführungsbeispiel
der Erfindung kann es sich bei dem Erkennungscode um einen Erkennungscode
einer Mehrzahl von Erkennungscodes handeln, die alle jeweils verschiedene
Arten von Statusdaten von dem Empfangsknoten voraussetzen. Wenn
etwaige der Erkennungscodes in der Nachricht nicht identifiziert 720 werden,
handelt es sich bei der Nachricht um keine Statusabfrage, und das
Verfahren 700 wartet 710 auf die nächste Nachricht.
In diesem Fall wird die Nachricht unter Verwendung anderer Ressourcen verarbeitet,
die der Netzwerksteuereinheit zugeordnet sind, wie z.B. der zugeordneten
CPU.
-
Wenn
ein Erkennungscode in der Nachricht identifiziert wird 720,
werden NT-Daten, wie z.B. L_SRC und L_DST, und IP-Daten, wie z.B.
Prototypantwortdaten, aus der Nachricht abgerufen 730. Wenn
der identifizierte Erkennungscode anzeigt 750, dass zusätzliche
Statusdaten oder IP-Adressdaten von dem Knoten benötigt werden,
so werden die Daten au einem entsprechenden Puffer abgerufen 760, und
eine lenkbare Antwort wird unter Verwendung der abgerufenen NT-,
IP- und Statusdaten erzeugt 770. Wenn der Erkennungscode
anzeigt 750, dass keine Status- oder Adressdaten erforderlich sind, wird
die Antwort unter Verwendung der abgerufenen NT- und IP-Daten erzeugt.
-
Bereitgestellt
wird somit eine Netzwerksteuereinheit, die auf ausgewählte Statusabfragen
antworten kann, ohne auf die CPU und deren unterstützende Logik
zurückzugreifen.
Zu diesem Zweck weist die Netzwerksteuereinheit ein Abfrageerkennungsmodul
und ein Daten-Routing-Modul auf. Das Abfrageerkennungsmodul erkennt
spezifizierte Bitfolgen in den Bitströmen, die eingehenden Nachrichten zugeordnet
sind, um Statusabfragen zu identifizieren. Das Daten-Routing-Modul
ruft NT- und IP-Daten aus Nachrichten ab, die als Statusabfragen
identifiziert sind, und das Modul erzeugt eine Antwort aus den abgerufenen
Daten. Die abgerufenen IP-Daten umfassen eine Prototyp-Nachricht,
welche die IP-Header-Daten für
die Antwort bereitstellt. Sie können
auch knotenspezifische Daten aufweisen, die durch einen Puffer in
der Netzwerksteuereinheit zur Verfügung gestellt worden sind.
Das Daten-Routing-Modul verwendet die abgerufenen NT-Daten zum Erzeugen
eines NT-Headers
für die
Antwort, welche die abgerufenen Daten zurück zu dem Ursprungsknoten leitet.