DE60300035T2 - Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren - Google Patents

Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren Download PDF

Info

Publication number
DE60300035T2
DE60300035T2 DE60300035T DE60300035T DE60300035T2 DE 60300035 T2 DE60300035 T2 DE 60300035T2 DE 60300035 T DE60300035 T DE 60300035T DE 60300035 T DE60300035 T DE 60300035T DE 60300035 T2 DE60300035 T2 DE 60300035T2
Authority
DE
Germany
Prior art keywords
terminal
packet
address
server
entry
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60300035T
Other languages
English (en)
Other versions
DE60300035D1 (de
Inventor
Takayuki Minato-ku Nyu
Yuta Minato-ku Ishimoto
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of DE60300035D1 publication Critical patent/DE60300035D1/de
Application granted granted Critical
Publication of DE60300035T2 publication Critical patent/DE60300035T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • H04L69/085Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • Die vorliegende Erfindung betrifft die IP-Kommunikation zwischen Endgeräten, die mit Netzwerken mit verschiedenen Protokollen verbunden sind, und insbesondere ein Verfahren zur Verbindung von IEEE 1394-Netzwerken und IP-Netzwerken.
  • Wenn ein Internetprotokollpaket zwischen lokalen Netzwerken mit verschiedenen Protokollen weitergeleitet wird, ist es gängige Praxis, das Paket auf Schicht 2 zu beenden und seine Zieladresse auf Schicht 3 zu untersuchen und das Paket dann an eine passende Schnittstelle weiterzuleiten.
  • Die gegenwärtige Praxis ist nützlich, um große Netze aufzubauen, bei denen die Adresse auf einer Seite eines Grenzpunkts sich von der Adresse auf der anderen Seite unterscheidet. Die Verwendung der gegenwärtigen Praxis für große Netze ist jedoch für Anwendungen, bei denen die Anzahl der Benutzerendgeräte relativ klein ist, nicht gerechtfertigt. Insbesondere würden für Kommunikationen zwischen Endgeräten Server installiert.
  • Ein Verfahren zum Vernetzen einer Anzahl von lokalen Netzwerken mit verschiedenen Protokollen in ein einziges logisches Netzwerk wurde von der IETF (Internet Engineering Task Force) als RFC 925 (Request for Comment 925 „Multi-LAN Address Resolution") standardisiert. In diesem Verfahren arbeitet ein Zwischenverstärker als ein Proxy-ARP-Server für jedes Endgerät, um ARP-Pakete (Address Resolution Protocol = Adreßauflösungsprotokoll) zu verarbeiten. Damit ein IP-Paketzwischenverstärker Unicast-Pakete (Punkt-zu-Punkt-Pakete) zwischen einem IEEE 1394-Netzwerk und einem IEEE 802.x-Netz werk zwischenverstärkt, muß der Zwischenverstärker eine Kopfzeilenübersetzung durchführen, indem er die Quelladresse eines Pakets von einem Endgerät neu in die physikalische Adresse des Zwischenverstärkers schreibt, wenn der Zwischenverstärker ein ARP-Paket als Broadcast sendet, um die physikalische Adresse oder die GUID (global unique ID = global eindeutige Adresse) eines 1394-Endgeräts zu erhalten, und muß die GUID der physikalischen Adresse oder der MAC-Adresse des 802.x-Endgeräts und ihre IP Adressen zuordnen.
  • Wenn ein Gerät an den IEEE 1394-Bus angeschlossen wird, wird ein Zurücksetzen des Busses ausgelöst, und der ganze Bus wird automatisch neu konfiguriert. Diese Businitialisierung besteht aus drei Phasen: Zurücksetzen, Baumidentifizierung und Selbstidentifizierung. Während der ersten Phase werden alle Knoten über das Ereignis informiert, daß ein Bus zurückgesetzt wird. In der folgenden Phase wird die Topologie des Busses bestimmt. Die letzte Phase ist dafür verantwortlich, jedem Gerät eine physikalische ID zuzuweisen. Um ein Gerät nach dem Zurücksetzen eines Busses zu erkennen, wird eine global eindeutige Kennung (GUID) für eine eindeutige Adressierung verwendet.
  • Ansprechend auf das ARP-Anfragepaket liest der Paketzwischenverstärker das Sender-IP-Adreßfeld, das GUID-Feld, das Unicast-Sender-FIFO-Feld und gibt die Inhalte dieser Felder jeweils in das IP-Adreßfeld, das GUID-Feld und das Unicast-Sender-FIFO-Feld (verfügbar beim Empfang von IP-Datagrammen) einer ARP-Paketverwaltungstabelle ein. Der Paketzwischenverstärker schreibt das ARP-Paket mit dem IEEE 1394-Format neu in das IEEE 802.x-Format, indem er die Sender- und Ziel-IP-Adressen von dem 1394-ARP-Paket in das 802.x-ARP-Paket einliest und in dem Ziel-MAC-Adreßfeld des 802.x-ARP-Pakets lauter Nullen und in dem Sender-MAC-Adreßfeld des 802.x-ARP-Pakets die MAC-Adresse des Zwischenverstärkers einstellt.
  • Das 802.x-ARP-Paket wird dann in einen 802.x-Rahmen verpackt, welcher eine 802.x-Kopfzeile enthält, in der das Ziel-MAC-Adreßfeld auf lauter Nullen gesetzt ist und für das Sender-MAC-Adreßfeld die Zwischenverstärker-MAC-Adresse eingestellt ist. Der Rahmen wird dann als Broadcast an alle Endgeräte des 802.x-Netzwerks gesendet. Da in dem Sender-MAC-Adreßfeld des Rahmens die Zwischenverstärker-MAC-Adresse eingestellt ist, erkennen alle Empfängerendgeräte in dem 802.x-Netzwerk, daß der Zwischenverstärker der Sender des Pakets ist. Als ein Ergebnis ist ein ARP-Antwortpaket, das von einem 802.x-Zielendgerät gesendet wird, für den Paketzwischenverstärker bestimmt.
  • Die MAC-Adresse und die IP-Adresse des 802.x-Zielendgeräts sind jeweils in dem Sender-MAC-Adreßfeld und dem Sender-IP-Adreßfeld dieses ARP-Antwortpakets eingestellt. Die MAC-Adresse des Paketzwischenverstärkers ist in dem Ziel-MAC-Adreßfeld und die IP-Adresse des 1394-Engeräts ist in dem Ziel-IP-Adreßfeld des ARP-Antwortpakets eingestellt.
  • Wenn der Paketzwischenverstärker dieses ARP-Antwortpaket empfängt, liest er eine Kopie seiner MAC-Adresse des 802.x-Zielendgeräts aus der Sender-MAC-Adresse und stellt die Kopie in dem MAC-Adreßfeld der ARP-Verwaltungstabelle ein und liest eine Kopie der IP-Adresse des 802.x-Zielendgeräts aus dem Sender-IP-Adreßfeld und stellt die Kopie in dem IP-Adreßfeld ein.
  • Das ARP-Antwortpaket wird dann in ein IEEE 1394-Paket verpackt, das eine asynchrone Blockschreibkopfzeile (ABW-Kopfzeile) enthält, in der das Unicast-FIFO-Feld des anfordernden 1394-Endgeräts in ihrem Versatzadreßfeld eingestellt ist, und wird von dem Paketzwischenverstärker zu dem 1394-Netzwerk gesendet.
  • Wenn das anfordernde 1394-Endgerät nach dem ARP-Verfahren ein Paket an das 802.x-Zielendgerät sendet, bildet das 1394-Endgerät ein Paket, indem es die IP-Adresse des 802.x-Endgeräts in dem Zieladreßfeld einstellt und die GUID und das Unicast-FIFO-Feld des Paketzwischenverstärkers angibt, und leitet das Paket weiter. Bei Empfang des Pakets erkennt der Paketzwischenverstärker, daß er adressiert ist und sendet dieses Paket erneut an das 802.x-Endgerät. Wenn ein Paket von dem 802.x-Endgerät an das 1394-Endgerät gesen det wird, stellt das 802.x-Endgerät die IP-Adresse des 1394-Endgeräts in dem Zieladreßfeld des Pakets ein und gibt die MAC-Adresse des Zwischenverstärkers an.
  • Während einer Session liest der Paketzwischenverstärker die IP-Adresse, die in einem auf einer Seite des Zwischenverstärkers empfangenen Paket eingestellt wurde, als einen Suchbegriff, um die ARP-Paketverwaltungstabelle nach einem zugehörigen Satz aus MAC-Adresse, GUID und Unicast-FIFO-Feld des Zielendgeräts zu durchsuchen, und schreibt die Zieladresse des empfangenen Pakets für eine Übertragung auf die andere Seite des Zwischenverstärkers neu.
  • Andererseits wurde das PPPoE-Protokoll (Point to Point Protocol (PPP) over Ethernet = Punkt-zu-Punkt-Protokoll über Ethernet)(802.3) entwickelt, um eine PPP-Verbindung über Ethernet aufzubauen. Dieses Protokoll ist entsprechend verschiedenen Kommunikationsbetriebsarten in zwei Stufen geteilt. In der ersten Stufe, Discovery Stage genannt, wird eine Verbindung zwischen einem Nicht-1394-Host-Endgerät und einem PPPoE-Server (oder Knoten), der als ein Zugangskonzentrator verwendet werden kann, hergestellt. Das Hostendgerät gibt eine MAC-Adresse des Servers an, um eine Session-Kennung zu bekommen. In der folgenden Stufe oder Verbindungsstufe (Session Stage) wird eine Verbindung mit einem Inernet-Serviceanbieter hergestellt, um unter Verwendung der zugewiesenen Session-ID eine IP-Kommunikation durchzuführen. Wenn die Session beendet wird, wird die Discovery-Stufe wiederaufgenommen. Die Discovery- und Session-Stufen können durch einen in dem Ethernet-Typenfeld des IP 1394-Pakets gesetzten Wert und einen in dem Ethernet-Typenfeld des 802.x-Pakets gesetzten Werts voneinander unterschieden werden. Wenn ein IEEE 802.x-Endgerät eine Kommunikation initiiert, sendet es ein PADI-Paket (PPPoE Active Discovery Initiation = PPPoE-Einleitung der Discovery), welches den Namen eines Service angibt, den der Host anfordert. Da das Nicht-1394-Host-Endgerät die MAC-Adresse des PPPoE-Servers während der Discovery-Stufe nicht kennt, sendet es ein PADI-PAket als Broadcast an das Netz. Ansprechend darauf antwortet ein PPPoE-Server mit einem PADO-Paket (PPPoE Active Discovery Offer = akitves PPPoE Angebot für Discovery) an das Hostendgerät, welches den Namen des Servers und einen unterstützten Servicenamen enthält. Das Hostendgerät antwortet auf dieses PADO-Paket durch Zurücksenden eines PADR-Pakets (PPPoE Active Discovery Request = aktive PPPoE Anforderung für Discovery), welches den Servicenamen und den PPPoE-Servernamen enthält, die vorher in dem PADO-Paket eingestellt wurden. Wenn der PPPoE-Server dieses Paket empfängt, sendet er ein PADS-Paket (PPPoE Active Discovery Session Confirmation = aktive PPPoE-Verbindungsbestätigung für Discovery), in dem entsprechend dem angefragten Servicenamen eine Session-ID eingestellt ist. Wenn das Hostendgerät dieses PADS-Paket empfängt, beginnt eine Session-Stufe. Während der Session-Stufe wird eine durch die Session-Kennung spezifizierte IP-Verbindung zwischen dem Hostendgerät und dem Internet ausgeführt. Die Session-Stufe wird beendet, wenn das Host-Endgerät oder die Zugangssteuerung ein PADT-Paket (PPPoE Active Discovery Terminate = aktive PPPoE-Discovery beenden) senden.
  • Das 1394-Netzwerk kann jedoch dem Punkt-zu-Punkt-Protokoll nicht Rechnung tragen. Wenn ein 1394-Netzwerk mit einem 802.x-Netzwerk verbunden würde, könnten die Hostendgeräte daher keine PPP-Pakete übertragen. Wenn in einem System, in dem ein 1394-Netzwerk und ein 802.x-Netzwerk durch einen Paketzwischenverstärker miteinander verbunden sind, eine PPP-Verbindung aufgebaut würde, könnten am Beginn einer PPP-Verbindung weder der Paketzwischenverstärker noch das 1394-Endgerät die Zieladresse gewinnen. Da Unicast-Verbindungen zwischen 1394-Endgeräten nicht nur mit einer global eindeutigen Kennung ablaufen können, ist zusätzlich eine Unicast-FIFO-Kennung (d. h. eine Registeradresse eines Geräts, das an einen seriellen 1394-Bus angeschlossen ist) erforderlich, um den 1394-Zielknoten zu spezifizieren, der an den seriellen 1394-Bus des Hostendgeräts angeschlossen ist. Das Hostendgerät muß jedoch ein ARP-Paket als Broadcast senden, um durch Anzeigen seiner IP-Adresse die Register adresse des Zielknotens zu erhalten. Da dem Hostendgerät vor der Herstellung einer PPP-Verbindung keine IP-Adresse zugewiesen ist, und da das ARP-Verfahren eine IP-Adresse erfordert, kann das Hostendgerät sich nicht auf das ARP-Verfahren verlassen, um die Adresse eines Ziels zu gewinnen, und folglich kann es das entsprechende Endgerät nicht identifizieren. Daher können zwischen 1394-Endgeräten keine PPP-Verbindungen eingerichtet werden.
  • Die Idee in „RFC 925 – Multi-LAN Address Resolution", Postel J, IETF, Oktober 1984, XP002218286, ist, das ARP zu erweitern, um in einer Umgebung mit vielen miteinander verbundenen LANs zu arbeiten, wobei das ARP genau wie es ist verwendet wird. Das neue Element ist eine „Wunderkiste" („ARP-basierte Bridge"), die die ARP-Anfrage in benachbarte LANs weiterleitet und als ein Agent zum Weiterleiten von Datagrammen zu Hosts von anderen LANs arbeitet.
  • Das Dokument von Johannson, „RFC 2734 – IPv4 over IEEE 1394", IETF, Dezember 1999, XP002238651, spezifiziert, wie der IEEE Standard 1394–1995, Standard for a High Performance Serial Bus (und seine Ergänzungen) für den Transport von Datagrammen der Internetprotokollversion 4 (IPv4) verwendet werden soll; er definiert die notwendigen Verfahren, Datenstrukturen und Codes für diesen Zweck. Diese umfassen nicht nur Paketformate und Verpackungsverfahren für Datagramme, sondern auch ein Adreßauflösungsprotokoll (1394 ARP) und ein Multicast-Kanalzuweisungsprotokoll (MCAP). Sowohl 1394 ARP als auch MCAP sind spezifisch für einen seriellen Bus, das letztere ermöglicht die Verwaltung von seriellen Busressourcen, wenn sie von IP-Multicast-Gruppen verwendet werden.
  • Das Dokument von Makamos L. et al, „RFC 2516 – A Method for Transmitting PPP over Ethernet (PPPoE)", IETF, Februar 1999, XP002198847, beschreibt, wie PPP-Sessions aufzubauen und PPP-Pakete über Ethernet zu verpacken sind. Diese Spezifikation kann von vielen Hosts auf einem gemeinsam genutzten Ethernet verwendet werden, um PPP-Sessions zu vielen Zielen über ein oder mehrere Brückenmodems zu öffnen.
  • Es ist daher ein Hauptziel der vorliegenden Erfindung, einen Paketzwischenverstärker in die Lage zu versetzen, in der Zeit vor der Herstellung einer PPP-Verbindung die physikalische Adresse eines IEEE 1394-Hostendgeräts zu erkennen, woraufhin dem 1394-Hostendgerät eine IP-Adresse zugewiesen wird. Die Aufgabe der Erfindung wird mit den Merkmalen der Patentansprüche gelöst.
  • Das angegebene Ziel der vorliegenden Erfindung wird erreicht durch Bereitstellung eines IEEE 1394-Hostendgeräts zum Übertragen eines PPP-Pakets mit einem neuen Datenformat, welches eine physikalische Adresse des an den seriellen IEEE 1394-Bus angeschlossenen Hostendgeräts anzeigt. Insbesondere umfaßt die physikalische Adresse eine global eindeutige Kennung und eine Registeradresse (oder Unicast-FIFO-Adresse).
  • Die vorliegende Erfindung wird unter Bezug auf die folgenden Zeichnungen weiter im Detail beschrieben, wobei:
  • 1 ein Blockschaltbild eines Kommunikationssystems gemäß einer ersten Ausführungsform der vorliegenden Erfindung ist;
  • 2 eine Abbildung des Datenformats eines IEEE 1394-PPPoE-Pakets ist, das gemäß der vorliegenden Erfindung zwischen IEEE 1394-Hostendgeräten und einem Paketzwischenverstärker transportiert wird;
  • 3 eine Abbildung von Details einer Zielverwaltungstabelle ist;
  • 4 eine Abbildung des Datenformats eines IEEE 802-PPPoE-Pakets ist, das zwischen dem Paketzwischenverstärker und einem PPPoE-Server transportiert wird;
  • 5 ein Flußdiagramm des Betriebs der Steuerung des Paketzwischenverstärkers von 1 ist;
  • 6 ein Blockschaltbild eines Kommunikationssystems gemäß einer zweiten Ausführungsform der vorliegenden Erfindung ist;
  • 7 eine Abbildung von Details der Zielverwaltungstabelle und einer Knotentabelle von 6 ist;
  • 8 ein Ablaufdiagramm zur Darstellung von DHCP-(dynamic host configuration protocol = dynamisches Hostkonfigurationsprotokoll) und ARP-Verfahren ist, die durchgeführt werden, bevor eine PPP-Verbindung hergestellt wird; und
  • 9 ein Flußdiagramm des Betriebs der Steuerung des Paketzwischenverstärkers von 6 ist.
  • Nun Bezug nehmend auf 1 wird ein Kommunikationssystem gemäß einer ersten Ausführungsform der vorliegenden Erfindung gezeigt. Das System weist mehrere IEEE 1394-Endgeräte 11, 12, 13 auf, die zum Beispiel über Wählverbindungen logisch mit einem Paketzwischenverstärker verbunden sind.
  • Der Paketzwischenverstärker 20 umfaßt eine Steuerung 21, die auf einer Seite über eine IEEE 1394-Schnittstelle 22 mit den 1394-Endgeräten 11, 12, 13 verbunden ist und auf der anderen Seite über eine IEEE-802.x-Schnittstelle 23 mit einem ADSL-Modem verbunden ist.
  • Das ADSL-Modem 30 ist über eine Kommunikationsverbindung 31 mit einem PPPoE-Server 40 eines Netzbetreibers verbunden, der seinerseits über eine Kommunikationsverbindung 41 mit dem Internet oder IP-Netzwerk 50 verbunden ist.
  • Ein als IP 1394 (oder IPv4 über IEEE 1394, RFC 2734) bekanntes Protokoll ist in jedem der 1394-Endgeräte installiert, um ein in ein IP 1394-Paket verpacktes IP-Datagramm zu senden. Um das IP 1394-Paket in einem IEEE 802.x-Netzwerk zu wiederholen, extrahiert der Paketzwischenverstärker 20 ein in dem Paket enthaltendes IP-Datagramm und hängt eine IEEE 802.x-Kopfzeile an das Paket und leitet es an das ADSL-Modem 30 weiter.
  • Ein von dem ADSL-Modem 30 gesendetes IEEE 802.x-Paket wird von dem Paketzwischenverstärker 20 empfangen, wo das IP-Datagramm extrahiert und das Format in ein 1394-Paket übersetzt wird, indem eine IEEE 1394-Kopfzeile angehängt wird, die eine GASP-Kopfzeile 201 (wenn die Sendeart Broad cast oder Multicast ist)/asynchrone Blockschreib-Kopfzeile 202 (ABW)(wenn die Sendeart Unicast ist) und IP 1394-Nutzdaten 203 aufweist, und wird, wie in 2 dargestellt, an das 1394-Netzwerk weitergeleitet. 4 stellt das Datenformat eines IEEE 802.x-Rahmens dar, in dem eine PPPoE-Kopfzeile und ein Datagramm in einen IEEE 802.x-Rahmen verpackt sind.
  • Der 802.x-Rahmen umfaßt ein Pakettypen- (oder Code-) Feld 431 zum Einstellen eines Werts, der einen von sechs Pakettypen, einschließlich PADI, PADO, PADR, PADS und PADT, anzeigt. Ein Session-ID-Feld 432 wird verwendet, um eine zugewiesene Session-Kennung einzustellen, die verwendet werden soll, wenn eine Session hergestellt wird. Der in diesem Feld eingestellte Wert ist nur für Pakete, wie etwa PADS-Pakete und diejenigen, die während der Session-Stufe verwendet werden, und PADT-Pakete wirksam. Für andere Pakete wird in dieses Feld der Wert "Null" eingestellt.
  • Wenn der Paketzwischenverstärker 20 dieses PPPo1394-Paket von einem 1394-Endgerät empfängt, liest er die Host-eindeutige ID aus dem Kennzeichenwertfeld 247 des Pakets und die global eindeutige Kennung des 1394-Endgeräts und das Unicast-FIFO-Feld des Endgeräts. Die Host-eindeutige ID ist ein eindeutiger Wert, der aus der physikalischen Adresse eines IEEE 1394-Hostendgeräts abgeleitet wird. Das Kennzeichentypfeld 245 zeigt an, daß die in dem Kennzeichenwertfeld 247 gespeicherten Daten die Host-eindeutige ID sind. Die Länge der Host-eindeutigen ID ist in dem Kennzeichenlängenfeld 246 eingestellt.
  • Während der Discovery-Stufe verwendet der Paketzwischenverstärker 20 die Host-eindeutige ID als einen Suchbegriff, um Knoteninformationen des IEEE 1394-Hostendgeräts zu erhalten. Wie in 3 dargestellt, umfaßt die Zielverwaltungstabelle 25 ein HUID-Feld 25A, in dem die Host-eindeutige ID gespeichert ist, um die Knoteninformationen des Hostendgeräts und die MAC-Adresse des PPPoE-Servers 40 aufeinander abzubilden. Die Knoteninformationen des Hostendgeräts umfassen die Knoten-ID, die GUID und die Unicast-FIFO- ID eines Geräts, das an den seriellen 1394-Bus des Hostendgeräts angeschlossen ist, welche jeweils in einem Knoten-ID-Feld 25C, einem GUID-Feld 25D und einem Unicast-FIFO-Feld 25E eingestellt sind. Die MAC-Adresse des Servers ist in einem MAC-Adreßfeld 25F eingestellt. Die Knoten-ID ist eine logische Adresse, welche ein 1394-Gerät des Hostendgeräts eindeutig identifiziert. Die global eindeutige Kennung (GUID) ist eine physikalische Adresse, um das Gerät eindeutig zu adressieren. Die Unicast-FIFO-Adresse ist eine Registeradresse für eine Unicast-Übertragung.
  • Wie in 2 gezeigt, bildet das Hostendgerät IP 1394-Nutzdaten 203 mit einer IP 1394-Kopfzeile 231, einer PPPo1394-Kopfzeile 232, die eine PPPoE-Kopfzeile 242, ein GUID-Feld 243 (8 Byte) und ein Unicast-FIFO-Feld 244 (6 Byte) enthält, welcher PPPo1394-Nutdaten 233 folgen und welcher eine GASP-Kopfzeile 201 und eine ABW-Kopfzeile 202 vorausgeht. Das Hostendgerät stellt in jeweiligen Feldern 243 und 244 seine eigene global eindeutige Kennung und Unicast-FIFO-Adresse ein. Da die feststehende Maximallänge eines PADI-Pakets 1484 Byte ist, überschreiten die zusätzlichen 14 Byte der GUID- und Unicast-FIFO-Felder 243 und 244 diese Maximallänge nicht. Das PPPo1394-Nutzdatenfeld 233 weist ein Kennzeichentypenfeld 245, ein Kennzeichenlängenfeld 246, ein Kennzeichenwertfeld 247 und ein Nutzdatenfeld 248 auf.
  • Das Folgende ist eine Beschreibung des Betriebs der Steuerung 21 des Paketzwischenverstärkers 20 von 1 mit Hilfe eines in 5 gezeigten Flußdiagramms, wenn ein Paket entweder von einem 1394-Hostendgerät oder einem PPPoE-Server 40 empfangen wird.
  • Wenn der Paketzwischenverstärker 20 zum Beispiel ein Paket mit dem Format von 2 von dem IEEE 1394-Endgerät 11 empfängt, liest die Steuerung 21 das Ethernettypenfeld 241 der IP 1394-Kopfzeile 231 (Schritt 501) und beginnt eine Discovery-Stufe.
  • Die Steuerung 21 fährt fort mit dem Pakettypbestimmungsschritt 502, um die Pakettypendaten aus dem Codefeld 250 der PPPoE-Kopfzeile 242 zu lesen, und erkennt, daß das Paket ein PADI-Paket ist. Die Steuerung 21 geht dann von Schritt 502 weiter zu Schritt 503 und liest das Kennzeichenwertfeld 245 (das die Host-eindeutige ID enthält), das GUID-Feld 243, das Unicast-FIFO-Feld 244 und das Senderknoten-ID-Feld 211 und kopiert die Inhalte dieser Felder in entsprechende Felder der Zielverwaltungstabelle 25.
  • Wie in 2 gezeigt, speichert die Zielverwaltungstabelle 25 eine Host-eindeutige ID, eine Session-Kennung, und eine Knoteninformation, die für eine Unicast-Übertragung notwendig ist. Die Host-eindeutige ID und die Session-Kennung werden einzeln als ein Suchbegriff zur Durchführung einer Suche durch die Zielerwaltungstabelle 25 nach einer entsprechenden Knotenkennung, global eindeutigen Kennung, Sender-Unicast-FIFO-Adresse und einer Server-MAC-Adresse verwendet.
  • Die Steuerung 21 geht von Schritt 503 weiter zu Schritt 504, um das Datenformat des empfangenen PADI-Pakets in ein PADI-Paket mit dem 802.x-Datenformat (4) zu übersetzen. Das IEEE 802.x-Paket weist ein PPPoE-Nutzdatenfeld 401 auf, dem eine 802-Kopfzeile 402 und eine PPPoE-Kopfzeile 403 vorangeht. Das PPPoE-Nutzdatenfeld 401 umfaßt ein Kennzeichentypenfeld 411, ein Kennzeichenlängenfeld 412, ein Kennzeichenwertfeld 413, ein Kennzeichenfeld 414 und ein Nutzdatenfeld 415. Dieses PPPoE-Nutzdatenfeld 401 wird nur während der anfänglichen Discovery-Stufe verwendet.
  • Die Steuerung 21 übersetzt das PADI-Paket mit dem 1394-Format von 2 in das 802.x-Format von 4 und sendet das Paket als Broadcast an das Netzwerk (Schritt 505) und kehrt zu Schritt 501 zurück. Es ist zu beachten, daß das PADI-Paket mit dem 802.x-Format keine global eindeutige Kennung und nicht die Unicast-FIFO-Adresse des anfragenden 1394-Hostendgeräts enthält.
  • Wenn der PPPoE-Server 40 das PADI-Paket über das ADSL-Modem 30 empfängt, antwortet er mit einem PADO-Paket.
  • Wenn der Paketzwischenverstärker 20 das PADO-Paket empfängt, untersucht die Steuerung 21 das Ethernettypenfeld 421 der 802.X-Paketkopfzeile (siehe 4) und erkennt, daß die gegenwärtige Stufe eine Discovery-Stufe ist (Schritt 501) und fährt mit Schritt 502 fort, um den Pakettyp in dem Pakettypenfeld 431 der PPPoE-Kopfzeile 403 zu untersuchen, und erkennt, daß das empfangene Paket ein PADO-Paket ist. Der Paketzwischenverstärker 20 geht weiter zu Schritt 506 und kopiert die MAC-Adresse des PPPoE-Servers 40 aus dem Ziel-MAC-Adreßfeld 422 der 802.x-Kopfzeile 402 in das MAC-Adreßfeld 25F der Zielverwaltungstabelle 25.
  • In Schritt 507 verwendet die Steuerung 21 die in dem Kennzeichenwertfeld 413 der PPPoE-Nutzdaten 401 eingestellte Host-eindeutige ID als einen Suchbegriff und durchsucht die Zielverwaltungstabelle 25 nach einer entsprechenden Host-eindeutigen ID, die in einem Eintrag (einer Reihe) des Host-ID-Felds 25A der Verwaltungstabelle 25 gespeichert ist. Wenn ein derartiger Eintrag erkannt wird, geht die Steuerung 21 von Schritt 507 weiter zu Schritt 508, um die in den Feldern 25C, 25D und 25E des erkannten Eintrags der Verwaltungstabelle 25 gespeicherten Knoteninformationen zu lesen, und bestimmt, ob das Paket für das anfragende 1394-Hostendgerät oder den PPPoE-Server 40 bestimmt ist. Wenn bestimmt wird, daß das Ziel des Pakets das 1394-Hostendgerät ist, geht die Steuerung von Schritt 508 weiter zu Schritt 509, um das PADO-Paket mit dem 802.x-Format (4) in das 1394-Datenformat (2) zu übersetzen, indem die Knoteninformationen aus den Feldern 25C, 25D, 25E in das Zielknoten-ID-Feld 221 und das Versatzadreßfeld 222 der ABW-Kopfzeile 202 kopiert werden. Die Steuerung 21 sendet das PADO-Paket mit dem 1394-Datenformat als Unicast an das 1394-Hostendgerät (Schritt 510) und kehrt zu Schritt 501 zurück.
  • Ansprechend auf das PADO-Paket von dem Paketzwischenverstärker 20 antwortet das 1394-Hostendgerät mit einem PADR-Paket.
  • Bei Empfang des PADR-Pakets geht die Steuerung 21 des Paketzwischenverstärkers 20 durch die Schritte 501 und 502 weiter zu Schritt 507, um die in dem empfangenen Paket enthaltene Host-eindeutige ID im Hinblick auf eine entspre chende Host-eindeutige ID mit den in dem Host-ID-Feld 25A der Zielverwaltungstabelle 25 gespeicherten zu vergleichen. Wenn sie in einem der Einträge (Reihen) der Tabelle 25 übereinstimmen, untersucht die Steuerung 21 die MAC-Adresse des PPPoE-Servers, die in dem übereinstimmenden Eintrag enthalten ist. Wenn die MAC-Adresse des PPPoE-Servers erkannt wird, wandelt die Steuerung 21 das PADR-Paket mit dem 1394-Format in das 802.x-Format um (Schritt 509) und sendet es als Unicast an den PPPoE-Server 40 (Schritt 510).
  • Der Server 40 antwortet auf das PADR-Paket von dem Paketzwischenverstärker 20 mit einem PADS-Antwortpaket.
  • Bei Empfang des PADS-Pakets von dem PPPoE-Server erkennt die Steuerung 21, daß sie ein PADS-Paket empfangen hat und geht von Schritt 502 weiter zu Schritt 512. Da das Paket eine Session-Kennung in dem Session-ID-Feld 432 (siehe 4) enthält, extrahiert die Steuerung diese Session-Kennung und stellt sie in dem Session-ID-Feld 25B der Zielverwaltungstabelle 25 ein (Schritt 512).
  • Die Steuerung 21 geht von Schritt 512 weiter zu Schritt 507, um eine Suche nach einer entsprechenden Host-eindeutigen ID, die in einem Eintrag (einer Reihe) des Host-ID-Felds 25A der Zielverwaltungstabelle gespeichert ist, durch die Zielverwaltungstabelle 25 durchzuführen. Wenn ein derartiger Eintrag erkannt wird, geht die Steuerung 21 von Schritt 507 weiter zu Schritt 508, um die in den Feldern 25D und 25E des ermittelten Eintrags gespeicherten Knoteninformationen zu lesen, und bestimmt, ob das Paket für das anfragende 1394-Hostendgerät oder den PPPoE-Server 40 bestimmt ist. Wenn bestimmt wird, daß das Ziel des Pakets das 1394-Hostendgerät ist, geht die Steuerung von Schritt 508 weiter zu Schritt 509, um das PADS-Paket mit dem 802.x-Format in das 1394-Datenformat zu übersetzen, indem die Knoteninformationen aus den Felder 25C, 25D und 25E in das Zielknoten-ID-Feld 221 und das Versatzadreßfeld 222 der ABW-Kopfzeile 202 kopiert werden. Die Steuerung 21 sendet das PADS-Paket mit dem 1394-Datenformat als Unicast an das 1394-Hostendgerät (Schritt 510) und kehrt zu Schritt 501 zurück.
  • Die Discovery-Stufe endet nun, und der Paketzwischenverstärker tritt in eine Session-Stufe ein. Die Pakete, die während der Session-Stufe verwendet werden, enthalten keine Host-eindeutige ID. Wenn der Paketzwischenverstärker während der Session-Stufe ein Paket empfängt, geht die Steuerung 21 von Schritt 501 weiter zu Schritt 513, um die Session-Kennung aus dem Session-ID-Feld 251 (2) des Pakets zu extrahieren, wenn das Paket von dem 1394-Hostendgerät empfangen wurde, oder es aus dem Session-ID-Feld 432 (4) zu extrahieren, wenn das Paket von dem Server 40 empfangen wurde. Die Steuerung 21 verwendet die extrahierte Session-Kennung als einen Suchbegriff, um die Zielverwaltungstabelle 25 nach einer entsprechenden physikalischen Knotenadresse zu durchsuchen, und fährt mit Schritt 508 fort, um auf der Basis der extrahierten physikalischen Knotenadresse zu bestimmen, ob das Paket für das 1394-Hostendgerät oder für den PPPoE-Server 40 bestimmt ist. Dem 1394-Hostendgerät wird am Beginn der Session-Stufe eine IP-Adresse zugewiesen.
  • Während der Session-Stufe führt die Steuerung 21 für die Paketübertragung von dem Hostendgerät an den PPPoE-Server die Schritte 401, 413, 408, 409 und 410 aus und führt für die Paketübertragung von dem PPPoE-Server zu dem Hostendgerät die Schritte 401, 413, 408, 411 und 410 aus. Wenn für ein empfangenes Paket kein Ziel erkannt wird (Schritt 508), geht die Steuerung 21 weiter zu Schritt 515, um das Paket zu verwerfen.
  • Wenn der 1394-Host oder der PPPoE-Server ein PADT-Anfragepaket sendet, um die Session zu beenden, geht die Steuerung 21 weiter zu Schritt 514, um eine in dem Paket enthaltene Session-Kennung zu lesen und alle in einem dieser Session-Kennung entsprechenden Eintrag der Verwaltungstabelle 25 gespeicherten Daten zu löschen, und geht dann weiter zu Schritt 513, um die Verwaltungstabelle 25 unter Verwendung der Session-Kennung nach einem Zielort zu durchsuchen. Wenn das PADT-Anfragepaket von dem Hostendgerät empfangen wurde, werden die Schritte 508, 509, 510 ausgeführt, um das PADT-Anfragepaket erneut an den PPPoE-Server 40 zu senden. Andernfalls werden die Schritte 508, 511, 510 ausgeführt, um das Paket erneut an das 1394-Hostendgerät zu senden.
  • Wenn der Zielort das PADT-Anfragepaket von dem Paketzwischenverstärker 20 empfängt, antwortet er mit einem PADT-Antwortpaket. Als ein Ergebnis liest der Paketzwischenverstärker 20, wenn er das PADT-Antwortpaket empfängt, die Session-Kennung aus dem Session-ID-Feld 431 des Pakets (4) und löscht alle Daten, die in einem der Session-Kennung entsprechenden Eintrag der Zielverwaltungstabelle 25 gespeichert sind (Schritt 514) und geht weiter zu Schritt 513, um die Verwaltungstabelle 25 unter Verwendung dieser Session-Kennung nach dem Zielort zu durchsuchen. Wenn das PADT-Antwortpaket von dem PPPoE-Server 40 gesendet wurde, werden die Schritte 508, 511, 510 ausgeführt, um das Paket erneut an das 1394-Hostendgerät zu senden. Andernfalls werden die Schritte 508, 509, 510 ausgeführt, um das Paket erneut an den PPPoE-Server zu senden.
  • Ein Kommunikationssystem einer zweiten Ausführungsform der vorliegenden Erfindung ist in 6 gezeigt, wobei Teile, deren Bedeutung denen in 1 entspricht, mit den gleichen Ziffern bezeichnet sind und deren Beschreibung weggelassen wird. Ähnlich der vorhergehenden Ausführungsform sind die Hostendgeräte 11, 12, 13 über Wählverbindungen logisch mit einem Paketzwischenverstärker 60 verbunden.
  • In 6 weist der Paketzwischenverstärker 60 eine Zielverwaltungstabelle 62 und eine Knotentabelle 63 auf, die beide mit einer Steuerung 61 verbunden sind.
  • Wie in 7 gezeigt, ist die Zielverwaltungstabelle 62 im Aufbau identisch mit der Zielverwaltungstabelle 25 von 1. Die physikalische Adreßtabelle 63 hat eine Vielzahl von Hosteinträgen (Reihen), die in ein Hostnamenfeld 63A, ein 1394-Knoten-ID-Feld 63B, ein GUID-Feld 63C und ein Unicast-FIFO-Adreßfeld 63D unterteilt sind. Die Knotentabelle 63 wird verwendet, um den Namen des Hostendgeräts auf seine eigene Knotenkennung (d. h. die logische Adresse eines Geräts des Hostendgeräts), eine global eindeutige Kennung und die Unicast-FIFO-Adresse (die als Kombination eine physikalischen Adresse des Geräts darstellen) abzubilden. Das Knoten-ID-Feld 63C und das entsprechende GUID-Feld 63D jedes Eintrags werden aktualisiert, wann immer die Konfiguration des Hostendgeräts durch ein Ereignis geändert wird, das als „Zurücksetzen des Busses" bekannt ist und das durch das Anschließen eines neuen Geräts (z. B. 1394-Knoten) oder die Entfernung eines vorhandenen Knotens von dem seriellen 1394-Bus des Hostenedgeräts ausgelöst wird.
  • Der Betrieb der Steuerung 61 zum Herstellen einer PPP-Verbindung wird durch die Beschreibung eines in 9 gezeigten Flußdiagramms verständlich. Bevor der Betrieb von 9 beginnt, führt die Steuerung 61 jedoch DHCP- und ARP-Verfahren durch, wie in 8 dargestellt.
  • Wenn die Hostendgeräte 11, 12, 13 nacheinander gestartet werden, sendet jedes Hostendgerät ein DHCP-Discovery-Paket, das die MAC-Adresse des Hosts und Parameter, die der Host von dem IP-Netzwerk erhalten möchte, enthält, an den Paketzwischenverstärker 60. In dem Paketzwischenverstärker ist ein DHCP-Server 64 vorgesehen, um dieses Discovery-Paket zu empfangen, und dieser sendet ein DHCP-Angebot an das anfragende Endgerät. Das Hostendgerät antwortet mit einem DHCP-Anfragepaket, das für den Server bestimmt ist, von dem das DHCP-Angebot gesendet wurde. Der DHCP-Server 64 weist dem anfragenden Hostendgerät eine vorläufige Adresse zu und sendet ein für die IP-Adresse bestimmtes DHCP-Bestätigungspaket. Die Steuerung 61 stellt die zugewiesene IP-Adresse in der Knotentabelle 63 ein. Nach dem Senden des DHCP-Bestätigungspakets sendet die Steuerung 61 ein ARP-Anfragepaket, das für die IP-Adresse bestimmt ist, die der DHCP-Server 64 gerade zugewiesen hat. Daher antwortet das Hostendgerät auf das ARP-Anfragepaket mit einem ARP-Antwortpaket, das seine eigene Knotenkennung, global eindeutige Kennung und Unicast-FIFO-Kennung enthält. Die Steuerung 61 empfängt das ARP-Anfragepaket und bildet die in dem ARP-Antwortpaket enthaltene Knotenkennung, die global eindeutige Kennung und die Unicast-FIFO-ID auf die entsprechende IP-Adresse in der Knotentabelle 63 ab.
  • Wenn die DHCP-/ARP-Verfahren auf allen IEEE 1394-Hostendgeräten 11, 12, 13 ausgeführt wurden, werden in ihren Knotentabellen 63 daher, wie in 7 gezeigt, Daten eingestellt, die für ihre PPP-Verbindungen notwendig sind.
  • Alternativ können die 1394-Hostendgeräte ein DHCP-Discovery-Paket als Broadcast über den Paketzwischenverstärker 60 senden, um ein DHCP-Angebotspaket von einem DHCP-Server außerhalb des Paketzwischenverstärkers 60 zu empfangen. Der Paketzwischenverstärker 60 arbeitet als eine Überwachung zur Überwachung aller an die Hostendgeräte 11, 12, 13 gesendeten DHCP-Bestätigungspakete und speichert ihre zugewiesenen Adressen in der Knotentabelle 63 als vorübergehende IP-Adressen.
  • Nach den DHCP- und ARP-Verfahren ist die Steuerung 61 bereit, gemäß dem Flußdiagramm von 9 zu arbeiten. Es ist zu beachten, daß in 9 Teile, deren Bedeutung der in dem Flußdiagramm von 6 entspricht, mit den gleichen Ziffern markiert sind und ihre Beschreibung weggelassen wird.
  • Wenn das Hostendgerät 11 zum Beispiel ein PADI-Paket an den Paketzwischenverstärker 60 sendet, um eine PPP-Verbindung zu dem IP-Netzwerk 50 herzustellen, erkennt die Steuerung 61 zuerst, daß eine Discovery-Stufe für das Endgerät 11 begonnen wurde (Schritt 501) und geht dann weiter zu Schritt 901, wobei sie erkennt, daß sie ein PADI-Paket empfangen hat (Schritt 502). In Schritt 901 kopiert die Steuerung 61 die Host-eindeutige ID und die 1394-Knotenkennung des anfragenden Endgeräts aus dem PADI-Paket in die Zielverwaltungstabelle 62. Die Steuerung 61 geht weiter zu Schritt 902, um eine Suche nach einer entsprechenden global eindeutigen Kennung und einer Unicast-FIFO-ID (wie in 2 durch eine gestrichelte Linie angezeigt) durch die Knotentabelle 63 mit der Knotenkennung als Suchbegriff durchzuführen, und kopiert die erkannte global eindeutige Kennung und die Uni cast-FIFO-Adresse Zielverwaltungstabelle 62 (wie durch durchgezogene Linien in 7 angezeigt).
  • Die Steuerung 61 geht nun von Schritt 902 weiter zu Schritt 504, um das Paket in das 802.x-Format zu übersetzen, und sendet es als Broadcast an das Netzwerk (Schritt 505) und kehrt zu Schritt 501 zurück. Danach arbeitet die Steuerung 61 auf die gleiche Weise wie in der vorhergehenden Ausführungsform, wenn also in die Session-Stufe eingetreten wird, wird dem Hostendgerät eine formale IP-Adresse zugewiesen, welche die vorübergehend zugewiesene IP-Adresse ersetzt.

Claims (9)

  1. Paketzwischenverstärker (60), der für eine Verbindung zwischen einem IEEE 1394-Endgerät (11, 12, 13) und einem PPPoE-Server (Punkt-zu-Punkt-Protokoll über Ethernet) über ein 802.x-basiertes Netzwerk geeignet ist, der aufweist: eine Knotentabelle (63) mit einem dem Endgerät entsprechenden Eintrag; eine Zielverwaltungstabelle (62) mit einem dem Endgerät entsprechenden Eintrag; und eine Steuerung (61) zum Erkennen einer dem Endgerät in einem DHCP-Verfahren zugewiesenen IP-Adresse, die ein für diese IP-Adresse bestimmtes ARP-Anfragepaket sendet, ein ARP-Antwortpaket, das logische und physikalische Adresse eines Geräts des Endgeräts enthält, von dem Endgerät empfängt, und die logischen und physikalischen Adressen des ARP-Antwortpakets in den genannten Eintrag der Knotentabelle kopiert, wobei die Steuerung (61) während einer Discovery-Stufe einer PPP-Verbindung betreibbar ist, um ein PPP-Paket von dem Endgerät zu empfangen, die logischen und physikalischen Adressen der Knotentabelle, die einer logischen Adresse des Pakets entsprechen, in den Eintrag der Zielverwaltungstabelle zu kopieren, nacheinander PPP-Pakete von dem Server zu empfangen, eine jeweils in den Paketen enthaltene physikalische Adresse des Servers und eine Session-Kennung in den genannten Eintrag der Zielverwaltungstabelle zu kopieren, wobei die Steuerung (61) während der Session-Stufe der PPP-Verbindung betreibbar ist, um entweder von dem Endgerät oder dem Server ein PPP-Paket zu empfangen, und das Ziel des Pakets gemäß der physikalischen Adresse des Endge räts oder des Servers, die in der Zielverwaltungstabelle festgelegt ist, entsprechend einer Session-Kennung des Pakets zu bestimmen, wobei die physikalische Adresse des Geräts eine global eindeutige Kennung und eine Registeradresse aufweist und die physikalische Adresse des Servers eine MAC-Adresse ist; und wobei die IEEE 1394-Seite des Paketzwischenverstärkers eine PPPoE-ähnliche Verbindung aufweist.
  2. Paketzwischenverstärker nach Anspruch 1, der ferner einen DHCP-Server (64) zur Durchführung des DHCP-Verfahrens ansprechend auf ein DHCP-Discovery-Paket von dem Endgerät und zum Zuweisen der IP-Adresse an das Endgerät aufweist, wenn ein DHCP-Anfragepaket von dem Endgerät empfangen wird.
  3. Verfahren zum Herstellen einer PPP-Verbindung zwischen einem IEEE 1394-Endgerät und einem PPPoE-Server (Punkt-zu-Punkt-Protokoll über Ethernet) über ein 802.x-basiertes Netzwerk unter Verwendung einer Knotentabelle mit einem dem Endgerät entsprechenden Eintrag und einer Zielverwaltungstabelle mit einem dem Endgerät entsprechenden Eintrag, das die folgenden Schritte aufweist: a) Erkennen einer IP-Adresse, die dem Endgerät in einem DHCP-Verfahren zugewiesen wird; b) Senden eines für diese IP-Adresse bestimmten ARP-Anfragepakets; c) Empfangen eines ARP-Antwortpakets von dem Endgerät und Kopieren der logischen und physikalischen Adressen eines Geräts des Endgeräts, die in dem ARP-Antwortpaket enthalten sind, in den Eintrag der Knotentabelle; d) während einer Discovery-Stufe einer PPP-Verbindung (d1) Empfangen eines PPP-Pakets von dem Endgerät und Kopieren der logischen und physikalischen Adressen der Knotentabelle, die einer logischen Adresse des Pakets entsprechen, in den Eintrag der Zielverwaltungstabelle und (d2) Empfangen aufeinanderfolgender PPP-Pakete von dem Server und Kopieren einer jeweils in den Paketen enthaltenen physikalischen Adresse des Servers und einer Session-Kennung in den Eintrag der Zielverwaltungstabelle; und e) während einer Session-Stufe der PPP-Verbindung Empfangen eines PPP-Pakets entweder von dem Endgerät oder dem Server und Bestimmen eines Zielorts des Pakets gemäß der physikalischen Adresse entweder des Endgeräts oder des Servers, die in der Zielverwaltungstabelle entsprechend einer Session-Kennung des Pakets eingestellt ist, wobei die physikalische Adresse des Geräts eine global eindeutige Kennung und eine Registeradresse aufweist und die physikalische Adresse des Servers eine MAC-Adresse ist; und wobei die IEEE 1394-Seite des Paketzwischenverstärkers eine PPPoE-ähnliche Verbindung aufweist.
  4. Verfahren nach Anspruch 3, das ferner die folgenden Schritte aufweist: Durchführen des DHCP-Verfahrens ansprechend auf ein DHCP-Discovery-Paket von dem Endgerät; und Zuweisen der IP-Adresse an das Endgerät, wenn eine DHCP-Anfrage von dem Endgerät empfangen wird.
  5. Kommunikationsnetzwerk, das aufweist: ein IEEE 1394-Endgerät; einen PPPoE-Server (Punkt-zu-Punkt-Protokoll über Ethernet); ein 802.x-basiertes Netzwerk; und einen Paketzwischenverstärker (60), der zwischen das Endgerät und den Server geschaltet ist, wobei der Paketzwischenverstärker aufweist: eine Knotentabelle (63) mit einem dem Endgerät entsprechenden Eintrag; eine Zielverwaltungstabelle (62) mit einem dem Endgerät entsprechenden Eintrag; und eine Steuerung (61) zum Erkennen einer dem Endgerät in einem DHCP-Verfahren zugewiesenen IP-Adresse, die ein für diese IP-Adresse bestimmtes ARP-Anfragepaket sendet, ein ARP-Antwortpaket, das logische und physikalische Adresse eines Geräts des Endgeräts enthält, von dem Endgerät empfängt, und die logischen und physikalischen Adressen des ARP-Antwortpakets in den genannten Eintrag der Knotentabelle kopiert, wobei die Steuerung (61) während einer Discovery-Stufe einer PPP-Verbindung betreibbar ist, um ein PPP-Paket von dem Endgerät zu empfangen, die logischen und physikalischen Adressen der Knotentabelle, die einer logischen Adresse des Pakets entsprechen, in den Eintrag der Zielverwaltungstabelle zu kopieren, nacheinander PPP-Pakete von dem Server zu empfangen, eine jeweils in den Paketen enthaltene physikalische Adresse des Servers und eine Session-Kennung in den genannten Eintrag der Zielverwaltungstabelle zu kopieren, wobei die Steuerung (61) während einer Session-Stufe der PPP-Verbindung betreibbar ist, um entweder von dem Endgerät oder dem Server ein PPP-Paket zu empfangen, und das Ziel des Pakets gemäß der physikalischen Adresse des Endgeräts oder des Servers, die in der Zielverwaltungstabelle festgelegt ist, entsprechend einer Session-Kennung des Pakets zu bestimmen, wobei die physikalische Adresse des Geräts eine global eindeutige Kennung und eine Registeradresse aufweist und die physikalische Adresse des Servers eine MAC-Adresse ist; und wobei die IEEE 1394-Seite des Paketzwischenverstärkers eine PPPoE-ähnliche Verbindung aufweist.
  6. Kommunikationsnetzwerk nach Anspruch 5, wobei der Paketzwischenverstärker ferner einen DHCP-Server (64) aufweist zum Durchführen des DHCP-Verfahrens ansprechend auf ein DHCP-Discovery-Paket von dem Endgerät und zum Zuweisen der IP-Adresse an das Endgerät, wenn ein DHCP-Anfragepaket von dem Endgerät empfangen wird.
  7. Computerprogramm zum Herstellen einer PPP-Verbindung zwischen einem IEEE 1394-Endgerät und einem PPPoE-Server (Punkt-zu-Punkt-Protokoll über Ethernet) über ein 802.x-basiertes Netzwerk unter Verwendung einer Knotentabelle mit einem dem Endgerät entsprechenden Eintrag und einer Zielverwaltungstabelle mit einem Eintrag, der dem Endgerät entspricht, wobei das Programm Codeeinrichtungen aufweist, die, wenn das System auf einem Datenverarbeitungssystem abläuft, geeignet sind, die folgenden Schritte auszuführen: a) Erkennen einer IP-Adresse, die dem Endgerät in einem DHCP-Verfahren zugewiesen wird; b) Senden eines für diese IP-Adresse bestimmten ARP-Anfragepakets; c) Empfangen eines ARP-Antwortpakets von dem Endgerät und Kopieren der logischen und physikalischen Adressen eines Geräts des Endgeräts, die in dem ARP-Antwortpaket enthalten sind, in den Eintrag der Knotentabelle; d) während einer Discovery-Stufe (d1) Empfangen eines PPP-Pakets von dem Endgerät und Kopieren der logischen und physikalischen Adressen der Knotentabelle, die einer logischen Adresse des Pakets entsprechen, in den Eintrag der Zielverwaltungstabelle und (d2) Empfangen aufeinanderfolgender PPP-Pakete von dem Server und Kopieren einer jeweils in den Paketen enthaltenen physikalischen Adresse des Servers und einer Session-Kennung in den Eintrag der Zielverwaltungstabelle; und e) während einer Session-Stufe der PPP-Verbindung Empfangen eines PPP-Pakets entweder von dem Endgerät oder dem Server und Bestimmen eines Zielorts des Pakets gemäß der physikalischen Adresse entweder des Endgeräts oder des Servers, die in der Zielverwaltungstabelle entsprechend einer Session-Kennung des Pakets eingestellt ist, wobei die physikalische Adresse des Geräts eine global eindeutige Kennung und eine Registeradresse aufweist und die physikalische Adresse des Servers eine MAC-Adresse ist; und wobei die IEEE 1394-Seite des Paketzwischenverstärkers eine PPPoE-ähnliche Verbindung aufweist.
  8. Computerprogramm nach Anspruch 7, das ferner die folgenden Schritte aufweist: Durchführen des DHCP-Verfahrens ansprechend auf ein DHCP-Discovery-Paket von dem Endgerät; und Zuweisen der IP-Adresse an das Endgerät, wenn ein DHCP-Anfragepaket von dem Endgerät empfangen wird.
  9. Maschinenlesbares Medium zum Speichern des Computerprogramms nach Anspruch 7 oder 8.
DE60300035T 2002-01-08 2003-01-02 Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren Expired - Lifetime DE60300035T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002001802A JP2003204345A (ja) 2002-01-08 2002-01-08 通信システム、パケット中継装置、パケット中継方法、及び中継プログラム
JP2002001802 2002-01-08

Publications (2)

Publication Number Publication Date
DE60300035D1 DE60300035D1 (de) 2004-10-21
DE60300035T2 true DE60300035T2 (de) 2005-09-08

Family

ID=19190658

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60300035T Expired - Lifetime DE60300035T2 (de) 2002-01-08 2003-01-02 Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren

Country Status (4)

Country Link
US (1) US7373407B2 (de)
EP (1) EP1326403B1 (de)
JP (1) JP2003204345A (de)
DE (1) DE60300035T2 (de)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040141511A1 (en) * 2002-12-23 2004-07-22 Johan Rune Bridging between a bluetooth scatternet and an ethernet LAN
KR100542361B1 (ko) * 2003-02-12 2006-01-10 삼성전자주식회사 피피피오이 네트워크 시스템 및 이 시스템의 접속 방법
US7505472B1 (en) * 2003-06-20 2009-03-17 Redback Networks Inc. Method and apparatus for agnostic PPP switching
US7165111B2 (en) * 2003-08-04 2007-01-16 Sbc Knowledge Ventures, L.P. System and method to identify devices employing point-to-point-over Ethernet encapsulation
JP4174392B2 (ja) * 2003-08-28 2008-10-29 日本電気株式会社 ネットワークへの不正接続防止システム、及びネットワークへの不正接続防止装置
WO2005064851A1 (en) * 2003-12-30 2005-07-14 Bce Inc. Remotely managed subscriber station
CA2454408C (en) * 2003-12-30 2012-01-10 Bce Inc Subscriber station
CN100589374C (zh) * 2004-07-08 2010-02-10 中兴通讯股份有限公司 一种使用点到点协议时防止ip地址泄漏的方法
US7627000B2 (en) 2004-09-01 2009-12-01 Cisco Technology, Inc. Using an external router to manage foreign data communication channel traffic
KR100713416B1 (ko) 2004-09-02 2007-05-04 삼성전자주식회사 복수의 프로토콜을 지원하는 리피터 장치 및 그장치에서의 프로토콜 변환을 위한 제어 방법
JP2006094416A (ja) * 2004-09-27 2006-04-06 Nec Corp 加入者回線収容装置およびパケットフィルタリング方法
JP2006094417A (ja) * 2004-09-27 2006-04-06 Nec Corp 加入者回線収容装置およびパケットフィルタリング方法
JP2006324737A (ja) * 2005-05-17 2006-11-30 Matsushita Electric Ind Co Ltd 通信システム、パケット処理装置、及びパケット処理方法
JP2007151070A (ja) * 2005-10-24 2007-06-14 Hajime Fukushima 通信ノード
US20080127254A1 (en) * 2006-09-22 2008-05-29 Satoshi Nakajima Subscriber based tv operation
KR100899809B1 (ko) * 2007-12-11 2009-05-27 한국전자통신연구원 무선 센서 네트워크에서 IPv6를 위한 코디네이터,게이트웨이 및 전송 방법
US8089993B2 (en) * 2008-09-09 2012-01-03 Nec Laboratories America, Inc. Sliceable router with packet over optical OFDM transmission
JP5269641B2 (ja) * 2009-02-23 2013-08-21 富士通テレコムネットワークス株式会社 ユーザ認証システムおよびユーザ認証方法
JP2011004024A (ja) * 2009-06-17 2011-01-06 Hitachi Ltd 通信装置
CN102244689B (zh) * 2010-05-13 2014-01-01 华为技术有限公司 远程ip地址获取方法及设备
CN105472050A (zh) * 2014-08-20 2016-04-06 深圳市中兴微电子技术有限公司 一种网络接入方法及装置
JP2016062232A (ja) * 2014-09-17 2016-04-25 株式会社リコー 情報処理システム、情報処理装置、プログラム及び情報処理方法
CN108259633B (zh) 2017-05-31 2020-05-12 新华三技术有限公司 实现管理报文三层通信的方法、系统及装置
CN108259453B (zh) * 2017-05-31 2020-03-06 新华三技术有限公司 一种报文转发方法及装置
WO2019142327A1 (ja) * 2018-01-19 2019-07-25 富士通株式会社 中継装置および中継方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185184B1 (en) * 1995-09-25 2001-02-06 Netspeak Corporation Directory server for providing dynamically assigned network protocol addresses
JP3865454B2 (ja) * 1997-04-17 2007-01-10 富士通株式会社 通信装置
EP0940959B1 (de) * 1998-03-04 2007-10-10 Sony Deutschland GmbH Verbindungsherstellung zwischen entfernten Einheiten mit Hypertext-Übertragungsprotokoll
GB9909825D0 (en) * 1998-09-08 1999-06-23 Airnet Global Holdings Limited Communications system for aircraft
US6654382B1 (en) * 1998-10-26 2003-11-25 Hewlett-Packard Developmemt Company, L.P. Network device with logical-address learn mode
US7349391B2 (en) * 1999-03-19 2008-03-25 F5 Networks, Inc. Tunneling between a bus and a network
US6801507B1 (en) * 1999-07-27 2004-10-05 Samsung Electronics Co., Ltd. Device discovery and configuration in a home network
US20010030977A1 (en) * 1999-12-30 2001-10-18 May Lauren T. Proxy methods for IP address assignment and universal access mechanism
US6961336B2 (en) * 2001-03-06 2005-11-01 Watchguard Technologies, Inc. Contacting a computing device outside a local network

Also Published As

Publication number Publication date
US7373407B2 (en) 2008-05-13
US20030131133A1 (en) 2003-07-10
EP1326403B1 (de) 2004-09-15
DE60300035D1 (de) 2004-10-21
EP1326403A1 (de) 2003-07-09
JP2003204345A (ja) 2003-07-18

Similar Documents

Publication Publication Date Title
DE60300035T2 (de) Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren
DE69836673T2 (de) Verfahren und Vorrichtung zur Konfigurierung eines Netzknotens um sich selbst Netzübergang zu sein
DE10022431B4 (de) Integriertes IP-Netzwerk
DE602005003189T2 (de) Verfahren und System zum Aufbau eines bidirektionalen Tunnels
DE10392494B4 (de) Mechanismen zum Bereitstellen von Verbindbarkeit zwischen Netzen unterschiedlicher Adressbereiche
DE69934192T2 (de) Verfahren und Einrichtung zur Netzverbindung mittels Brücken
DE60300503T2 (de) Vorrichtung, Verfahren und System für die Konvertierung von Internetadressen
DE60224356T2 (de) Adressenübersetzer, Verfahren und Vorrichtung zur Nachrichtenverarbeitung
US7047314B2 (en) Duplicate private address translating system and duplicate address network system
DE602006000007T2 (de) Automatische Erkennung von Pseudo-Wire Peer-Adressen in Ethernet-basierten Netzen
DE60028254T2 (de) Steuerungsgerät und -verfahren für paketbasierte kommunikation
DE602005000990T2 (de) Verfahren zum Austauschen von Datenpaketen
WO2005112363A1 (de) Einrichtung zur session-basierten vermittlung von paketen
EP0998100B1 (de) Verfahren zum Einrichten eines Internet-Protokoll Netzwerkes
DE60208990T2 (de) Verfahren zur Unterscheidung von Teilnehmer eines Kommunikationssystems, Kommunikationssystem und Kommunikationsgerät
EP1186200B1 (de) Verfahren und einrichtung zum übermitteln von daten
DE69833206T2 (de) Netzwerkkontrolle zum verarbeiten von statusproblemen
CN113660358A (zh) 一种网关为下挂设备分配不同Ipv6 PD前缀的方法
DE602005001578T2 (de) Brücke zur Übersetzung zwsichen lokalen Ethernet- und 1394A-Anschlüssen für Geräte der Unterhaltungselektronik
EP1820324B1 (de) VERFAHREN ZUR KONFIGURIERUNG EINES GERAETES MIT DHCP UEBER PPPoE
DE60316158T2 (de) Filter zur verkehrstrennung
DE60320567T2 (de) Adressenverwaltungsverfahren
DE60318753T2 (de) Endgerätemobilität mit netzübergang zwischen ipv4 und ipv6
EP1543670B1 (de) Verfahren zum transparenten austausch von datenpaketen
DE10018136A1 (de) Verfahren zur Übermittlung von Informationen durch Datenpakete und Netzwerk zur Übermittlung von Daten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition