DE69835809T2 - Kommunikationssteuereinheit und Kommunikationssteuerungsverfahren angewendet für ein Mehrfachsende-unterstützendes LAN - Google Patents

Kommunikationssteuereinheit und Kommunikationssteuerungsverfahren angewendet für ein Mehrfachsende-unterstützendes LAN Download PDF

Info

Publication number
DE69835809T2
DE69835809T2 DE69835809T DE69835809T DE69835809T2 DE 69835809 T2 DE69835809 T2 DE 69835809T2 DE 69835809 T DE69835809 T DE 69835809T DE 69835809 T DE69835809 T DE 69835809T DE 69835809 T2 DE69835809 T2 DE 69835809T2
Authority
DE
Germany
Prior art keywords
multicast
packet
port
control unit
received
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
DE69835809T
Other languages
English (en)
Other versions
DE69835809D1 (de
Inventor
c/o Fujitsu Limited Naofumi Kawasaki-shi Kobayashi
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Application granted granted Critical
Publication of DE69835809D1 publication Critical patent/DE69835809D1/de
Publication of DE69835809T2 publication Critical patent/DE69835809T2/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
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/20Support for services
    • H04L49/201Multicast operation; Broadcast operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/35Switches specially adapted for specific applications
    • H04L49/351Switches specially adapted for specific applications for local area network [LAN], e.g. Ethernet switches
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/25Routing or path finding in a switch fabric
    • H04L49/253Routing or path finding in a switch fabric using establishment or release of connections between ports
    • H04L49/254Centralised controller, i.e. arbitration or scheduling

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf eine Kommunikationssteuereinheit zur Steuerung eines Ports, der z.B. zu benutzen ist, wenn ein Paket durch Verwendung eines Multicast unterstützenden LAN (Local Area Network) übertragen wird, und bezieht sich auf ein Kommunikationssteuerverfahren, das auf ein Multicast unterstützendes LAN angewendet wird.
  • HINTERGRUND DER ERFINDUNG
  • In Verbindung mit schneller und weitverbreiteter Benutzung von PCs in den letzten Jahren ist das LAN auch zunehmend bekannt geworden, während Computer und Netzwerke selbst fortschrittlicher und leistungsstärker geworden sind. Außerdem erleben die weitreichende Verwendung von WWW (World Wide Web) genauso wie von Multimedia-Daten wie bewegten Bildern und Stimmen einen Fortschritt, und der Verkehr von Netzwerken nimmt immer mehr zu, so dass die Einführung von Netzwerk-Repeatern wie z. B. einer Kommunikationssteuereinheit und eines Hochgeschwindigkeits-Routers, und eines Schalt-Hubs, der die Übertragung von großen, mit hoher Geschwindigkeit zu einem Netzwerk zu übertragenden Datenmengen erlaubt, weiterentwickelt werden. Zudem wurde eine Datenübertragung basierend auf einer Multicast-Technologie als eine Technologie zur effizienten Übertragung von großen Datenmengen angeführt, und es kann angenommen werden, dass die weitverbreitete Benutzung von Datenübertragung, die Multicast benutzt, von jetzt an immer mehr zunimmt.
  • Im Folgenden wird ein Multicast unterstützendes LAN beschrieben, in dem eine herkömmliche Art von Kommunikationssteuereinheit angewendet wird. 15 ist eine Abbildung, die eine Ausführung der herkömmlichen Art eines Multicast unterstützenden LAN aufzeigt. Das Multicast unterstützende LAN, das in 15 aufgezeigt ist, umfasst Multicast-Router 1001 und 1002 zur Weitergabe der Datenübertragung, die Multicast gemäß einer IP-Adresse benutzt; Kommunikationssteuereinheiten 1101, 1102 und 1103 zum Schalten des Eingangs/Ausgangs eines Pakets mit Daten, die gemäß MAC-Adressen zu übertragen sind; ein Hub 1201, der z. B. als ein Mehrfachport-Sende-Empfangsgerät fungiert; und Host-Vorrichtungen 1301-1307, die alle als ein Endgerät fungieren: Der Netzwerk-Aufbau, der in 15 aufgezeigt wird, ist ein Bestandteil eines LAN, das herausgenommen wurde, um das auf der herkömmlichen Technologie basierende Netzwerk zu beschreiben.
  • 16 und 17 sind Darstellungen zur Erklärung eines allgemeinen Überblicks eines Betriebs von IGMPv2 (Internet Group Management Protocol Version 2), die z. B. in RFC 2236, XP-02230720 beschrieben wird). 16 zeigt einen Ablauf für eine Host-Vorrichtung auf, die ein Mitglied einer Multicast-Gruppe wird, und 17 zeigt einen Ablauf für eine Host-Vorrichtung auf, die eine Multicast-Gruppe verlässt. Es sollte bemerkt werden, dass 16 und 17 einen Aufbau aufzeigen, der durch Herausnehmen eines Bestandteils mit dem Multicast-Router 1001 und Host-Vorrichtungen 1304 und 1305 aus dem Aufbau in 15 erhalten wird.
  • Zuerst wird ein Verfahren mit Bezug auf 16 beschrieben, das darin besteht, ein Mitglied einer Multicast-Gruppe zu werden. Es wird hier angenommen, dass die Host-Vorrichtung 1305 ein Mitglied einer Multicast-Gruppe zu werden wünscht, und es wird der Betrieb innerhalb eines Bereichs des Aufbaus beschrieben, der in 16 aufgezeigt wird, um die Beschreibung einfacher zu machen. Der Multicast-Router 1001 überträgt periodisch eine Anfrage- Nachricht (Host-Mitgliedschaftsanfrage) zu einem Zielort mit der IP-Adresse 224.0.0.1 (All-Systems-Group = Gesamt-System-Gruppe), um die Host-Vorrichtungen 1304 und 1305, die alle mit einem lokalen Netzwerk verbunden sind, zu fragen, ein Mitglied von einer der Multicast-Gruppen zu werden und herauszufinden, wo die gewünschte Multicast-Gruppe existiert.
  • In diesem Fall überträgt die Host-Vorrichtung 1305, die ein Mitglied einer Multicast-Gruppe zu werden wünscht, eine Bericht-Nachricht (Host Member Report = Host-Mitgliedsbericht) an eine Multicast-Adresse einer Gruppe, in der Hoffnung ein Mitglied zu werden, um die Multicast-Adresse, unter der die Host-Vorrichtung ein Mitglied zu sein wünscht, zu berichten, als Antwort auf die empfangene Anfrage vom Multicast-Router 1001.
  • Zu diesem Zeitpunkt überträgt die Host-Vorrichtung 1305, die einen Bericht zu übertragen versucht, den Bericht zu einer zufälligen Zeit während einer Zeitspanne, bis eine maximale Antwortzeit (vorgegebener Wert: 10 Sekunden), die in die Anfrage-Nachricht eingebettet ist, verstrichen ist. Wenn es eine Mehrzahl von anderen Host-Vorrichtungen gibt, die alle einen Bericht zur selben Gruppe wie den zu sendenden Bericht senden wollen, empfängt der Multicast-Router einen ersten übertragenen Bericht durch eine der Host-Vorrichtungen, so dass die anderen Host-Vorrichtungen den Bericht nicht übertragen. Und zwar, wenn eine Vielzahl von Host-Vorrichtungen in einem Netzwerkmedium mit dem gemeinsam benutzten Medium verbunden sind, wird nur ein Bericht an jede Multicast-Gruppe übertragen.
  • Der Multicast unterstützende Router 1001 empfängt den Bericht, findet eine Multicast-Gruppe heraus, von der die Host-Vorrichtung 1305 ein Mitglied zu werden wünscht, und beginnt Multicast-Daten zu einem lokalen, auf einem Multicast-Routingprotokoll basierenden Netzwerk zu übertragen, wenn herausgefunden wird, wo Multicast für die Multicast-Gruppe existiert,.
  • Die nächste Beschreibung bezieht sich auf ein Verfahren des Verlassens einer Multicast-Gruppe mit Bezug auf 17. Es wird hier angenommen, dass die Host-Vorrichtung 1305 eine Multicast-Gruppe zu verlassen wünscht, und es wird der Betrieb innerhalb eines Bereichs des Aufbaus, der in 17 aufgezeigt ist, beschrieben, um die Beschreibung einfacher zu machen. Die Host-Vorrichtung 1305, welche die Multicast-Gruppe, von der die Vorrichtung ein Mitglied ist, zu verlassen wünscht, überträgt eine Verlassen-Nachricht an die IP-Adresse 224.0.0.2 (All-Routers-Group = Gesamt-Router-Gruppe) zum Zeitpunkt, zu dem das Verlassen entschieden wird.
  • Der Multicast-Router 1001, der die Verlassen-Nachricht empfangen hat, überträgt eine GS-Anfrage-Nachricht (gruppenspezifische Anfrage-Nachricht) an die Multicast-Gruppen-Adresse, um zu überprüfen, ob irgendwelche anderen Host-Vorrichtungen, die ein Mitglied der Multicast-Gruppe sind, anwesend sind oder nicht. Wenn es einige Host-Vorrichtungen gibt, die alle ein Mitglied der Multicast-Gruppe sind, abgesehen von der Host-Vorrichtung, der die Verlassen-Nachricht übertragen hat, überträgt die Host-Vorrichtung 1305 einen Bericht an den Multicast-Router 1001, um die Anwesenheit davon zu vermitteln.
  • Obwohl es hierbei auch eine Version 1 von IGMP (definiert in RFC1112) gibt, unterstützt IGMPv2 eine Kompatibilität mit IGMPv1, so dass irgendeine Host-Vorrichtung und eine Router unterstützende Version 1 in einem lokalen Netzwerk anwesend sein können. Die Verlassen-Nachricht ist eine Nachricht, die in IGMPv2 hinzugefügt wird, und zwar findet ein Multicast-Router in Version 1 die Anwesenheit oder das Verlassen einer empfangenen Host-Vorrichtung heraus, die von der Anwesenheit oder Abwesenheit einer Antwort mit einem Bericht auf eine periodische Übertragung einer Anfrage abhängig ist.
  • In der herkömmlichen Art werden physikalische Unicast-Adressen von Endgeräten, die mit jedem Port verbunden sind, in einer Kommunikationssteuereinheit, wie einem Schalt-Hub, gespeichert und die Hochgeschwindigkeits-Paketübertragung eines Unicast-Pakets mit einer physikalischen Unicast-Adresse eines Endgeräts oder eines Broadcast-Pakets an Terminals wird nur an ein Ziel-Port realisiert oder an, auf einer Hardware-Schalttechnologie basierenden Ziel-Ports.
  • Wie für ein Multicast-Paket, das für Multimedia-Datenübertragung benutzt wird, ist es jedoch schwierig, eine Mehrzahl von bestimmten Ports, die das Multicast-Paket von anderen Ports verglichen mit dem Fall von Unicast benötigen, zu unterscheiden, und aus diesem Grund wird ein Multicast-Paket nicht nur an Ports übertragen, die das Multicast-Paket benötigen, sondern es wird an alle Ports übertragen, wie das Broadcast-Paket.
  • Das oben beschriebene Multicast-Paket hat in vielen Fällen kontinuierliche Stromdaten, genauso wie eine große Datenmenge mit einem Datentyp von bewegten Bildern und anderen Daten, die Verarbeitungsbegrenzungen verursachen durch die Kommunikationssteuereinheit, und aus diesem Grund treten Unbequemlichkeiten auf, so dass eine Beseitigungsrate von Multicast-Paketen höher wird, eine Übertragungsverzögerungszeit länger wird oder sich ein schlechter Einfluss auf die Übertragung von anderen Unicast-Paketen ergibt.
  • Obwohl es eine Vorrichtung gibt zur Ausführung des Nachrichtenvorgangs mit einem Multicast-Router, der mit einem Netzwerk, welcher ein bestimmtes Protokoll zur Übertragung eines Multicast-Pakets nur an einen Port einer erforderlichen Kommunikationssteuereinheit benutzt, verbunden ist, kann der Betrieb der Übertragung eines Multicast-Pakets nur an einen erforderlichen, bestimmten Port nicht realisiert werden, außer wenn der Multicast-Router, der das bestimmte Protokoll unterstützt, mit der Kommunikationssteuereinheit kombiniert wird.
  • In der oben beschriebenen Multicast unterstützenden LAN gibt es eine Kommunikationssteuereinheit, die IGMP für sich allein als ein Management-Protokoll einer Multicast-Gruppe zwischen einem Multicast-Router und Host-Vorrichtungen verpackt, aber durch den Vorzug, dass ein LAN-Schalter von Natur aus Datenübertragung mit hohen Geschwindigkeiten durch Übermitteln eines Datenpakets in einer Datensicherungsschicht realisiert, kann das Datenpaket verloren gehen.
  • Wenn ein bestimmtes, auf eine Vorrichtung abgestimmtes Protokoll benutzt wird, kann die Verbindungsfähigkeit zwischen den Machern oder den Vorrichtungen nicht garantiert werden.
  • Außerdem wird in US-1-5,608,726 ein System und ein Verfahren zum Routen von Multicast-Paketen beschrieben, so dass Bandbreite in zumindest einigen der Netzwerk-Segmenten oder Kollisions-Bereichen von einem Sub-Netzwerk eingespart wird. Insbesondere werden Multicast-Pakete nur in den Netzwerkfrequenzen erneut übertragen, die auf einem Weg zu einem Host sind, das ein Mitglied einer Multicast-Gruppe ist, für die das Multicast-Paket bestimmt ist.
  • In Anbetracht des oben erwähnten, besteht das Ziel der vorliegenden Erfindung darin, effiziente Übertragung von sowohl Multicast- als auch von Unicast-Daten nur an die erforderlichen Ports mit einem existierenden Protokoll und einem Netzwerk-Aufbau zu erreichen.
  • Gemäß der vorliegenden Erfindung wird das Ziel durch eine Kommunikationssteuereinheit mit den Merkmalen von Anspruch 1 erreicht.
  • Außerdem wird das Ziel durch ein Kommunikationssteuerverfahren mit den Merkmalen von Anspruch 21 erreicht.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, dass das empfangene Paket sowohl ein Multicast-Paket als auch ein Multicast-Gruppen-Management-Protokoll-Paket ist, wird eine Tabelle erzeugt, die gemäß dem empfangenen Paket eine Korrelation zwischen den Host-Vorrichtungen und den Multicast-Gruppen aufzeigt, und die Paketübertragung für jede Multicast-Gruppe zwischen dem Multicast-Router und den Host-Vorrichtungen wird gemäß der Tabelle gesteuert, so dass ein Multicast-Paket über Multicast nur an die erforderlichen Host-Vorrichtungen mit dem existierenden Protokoll und dem Netzwerkaufbau übertragen werden kann, und mit diesem Merkmal ist es möglich, die effiziente Übertragung von sowohl Multicast- als auch von Unicast-Daten zu realisieren.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, dass sowohl das Multicast-Paket als auch das Multicast-Gruppen-Management-Protokoll-Paket ein Anfrage-Paket ist, wird der Port, der das Anfrage-Paket unter einer Vielzahl von Ports empfangen hat, in der Tabelle als ein Port registriert, mit dem der Multicast-Router verbunden ist, so dass es möglich ist, eine Korrelation zwischen einem Port und einem Multicast-Router wie erforderlich gemäß den Inhalten des Pakets zu aktualisieren.
  • Wenn mit der vorliegenden Erfindung ein Anfrage-Paket empfangen wird, wird die Übertragung des Pakets an alle Ports gesteuert, abgesehen von demjenigen Port, der das empfangene Paket unter der Vielzahl von Ports empfangen hat, so dass die Anfrage sicherlich an Vorrichtungen übertragen werden kann, unter der Kontrolle durch einen Multicast-Router.
  • Mit der vorliegenden Erfindung wird ein Ping periodisch an den Port übertragen, mit dem der Multicast-Router unter der Vielzahl von Ports verbunden ist durch Bezugnahme auf die Tabelle, und wenn es irgendeinen Port gibt, der nicht auf den Ping antwortet, wird die Korrelation zwischen dem Port und dem Multicast-Router aus der Tabelle entfernt, so dass es möglich ist, das Verschwinden einer Korrelation zwischen einem Multicast-Router und einem Port wie erforderlich gemäß den Inhalten des Pakets zu aktualisieren.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, das sowohl das Multicast-Paket als auch das Multicast-Gruppen-Management-Protokoll-Paket ein Bericht-Paket ist, wird der Port, der das Bericht-Paket unter der Vielzahl von Ports empfangen hat, in einer Tabelle als ein verbindender Port registriert, der benutzt wird, wenn die mit dem Port verbundene Host-Vorrichtung ein Mitglied einer beliebigen Multicast-Gruppe sein soll, so dass es möglich ist, die Erzeugung einer Korrelation zwischen einem Port und einer Host-Vorrichtung für jede Multicast-Gruppe wie erforderlich gemäß den Inhalten des Pakets zu aktualisieren.
  • Wenn mit der vorliegenden Erfindung ein Bericht-Paket empfangen wird, wird das Bericht-Paket so gesteuert, dass es nur an den Port übertragen wird, mit dem der Multicast-Router durch Bezugnahme auf die Tabelle verbunden ist, so dass der Bericht von der Host-Vorrichtung sicherlich an den Multicast-Router übertragen werden kann.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, dass sowohl das Multicast-Paket als auch das Multicast-Gruppen-Management-Protokoll-Paket ein Verlassen-Paket ist, wird der Port, der das Verlassen-Paket unter der Vielzahl von Ports empfangen hat, aus der Tabelle gelöscht, wobei der Port als ein verbindender Port betrachtet wird und benutzt wird, wenn die mit dem Port verbundene Host-Vorrichtung eine beliebige Multicast-Gruppe verlässt, so dass es möglich ist, das Verschwinden einer Korrelation zwischen einem Port und einer Host-Vorrichtung für jede Multicast-Gruppe wie erforderlich gemäß den Inhalten des Pakets zu aktualisieren.
  • Wenn mit der vorliegenden Erfindung ein Verlassen-Paket empfangen wird, wird das Verlassen-Paket so gesteuert, dass es nur an den Port übertragen wird, mit dem der Multicast-Router verbunden ist durch Bezugnahme auf die Tabelle, so dass das Verlassen-Paket von der Host-Vorrichtung sicherlich an den Multicast-Router übertragen werden kann.
  • Wenn mit der vorliegenden Erfindung ein Verlassen-Paket empfangen wird, wird das Verlassen-Paket so gesteuert, dass es an alle Ports übertragen wird, abgesehen von demjenigen Port, der das Verlassen-Paket unter der Vielzahl von Ports empfangen hat, so dass der Bedarf nach Verarbeitung des Suchens eines Ports, mit dem der Multicast-Router verbunden ist, eliminiert wird, und mit diesem Merkmal ist es möglich die Verarbeitung des Verlassens mit geringer Geschwindigkeit schneller zu machen durch Beschränkung der Verarbeitungslast zum Zeitpunkt des Verlassensbetriebs.
  • Wenn mit der vorliegenden Erfindung ein Paket auf einer gruppenspezifischen Anfrage empfangen wird, zur Überprüfung, dass es keine Host-Vorrichtung gibt, die ein Mitglied einer Multicast-Gruppe ist, wird das Paket auf einer gruppenspezifischen Anfrage so gesteuert, dass es an alle Ports übertragen wird, mit denen ein Multicast-Router verbunden ist, durch Bezugnahme auf die Tabelle, abgesehen von demjenigen Port der mit derjenigen Host-Vorrichtung verbunden ist, der ein Mitglied einer Multicast-Gruppe gewesen ist und abgesehen von demjenigen Port, der das Paket auf einer gruppenspezifischen Anfrage empfangen hat, so dass die gruppenspezifische Anfrage nicht über Broadcast gesendet werden muss, und mit diesem Merkmal ist es möglich auf effiziente Art und Weise zu überprüfen, das es keine Host-Vorrichtung gibt, der ein Mitglied einer Multicast-Gruppe gewesen ist.
  • Wenn mit der vorliegenden Erfindung ein Paket auf einer gruppenspezifischen Anfrage empfangen wird, wird das Paket auf einer gruppenspezifischen Anfrage so gesteuert, dass es an alle Ports übertragen wird, abgesehen von demjenigen Port, der das Paket auf einer gruppenspezifischen Anfrage empfangen hat unter der Vielzahl von Ports, so dass der Bedarf nach Verarbeitung des Suchens eines Ports, mit dem der Multicast-Router verbunden ist, eliminiert wird, und mit diesem Merkmal ist es möglich die Verarbeitung der Übertragung der gruppenspezifischen Anfrage schneller zu machen durch Beschränkung der Verarbeitungslast zum Zeitpunkt des Betriebs der gruppenspezifischen Anfrage.
  • Wenn es mit der vorliegenden Erfindung irgendeinen Port gibt, von dem aus ein Bericht innerhalb einer spezifischen Zeitspanne nicht beantwortet wird, nachdem das Anfrage-Paket empfangen wurde, wird die Korrelation zwischen dem Port und der Host-Vorrichtung aus der Tabelle entfernt, so dass es möglich ist die Information, die nichts mit der Multicast-Paketübertragung wie erforderlich zu tun hat, zu aktualisieren, und mit diesem Merkmal kann die Verarbeitung auf effiziente Art und Weise ausgeführt werden.
  • Mit der vorliegenden Erfindung nach Anspruch 13 wird ein Aktualisierungsbetrieb der Tabelle unter der Kontrolle durch die externe Vorrichtung ausgeführt, so dass eine Last auf die Kommunikationssteuereinheit an sich beschränkt werden kann.
  • Wenn mit der vorliegenden Erfindung ein Paket durch einen mit dem Multicast-Router verbunden Port empfangen wird, und wenn das empfangene Paket ein Multicast-Paket ist, wird das empfangene Paket an die Host-Vorrichtungen, die zur Multicast-Gruppe gehören, übertragen, durch Bezugnahme auf die Tabelle, so dass ein Ablauf der Überprüfung des Multicast-Gruppen-Management-Protokolls weggelassen werden kann, und mit diesem Merkmal kann die Übermittlung eines Multicast-Pakets schneller gemacht werden.
  • Wenn mit der vorliegenden Erfindung ein Paket durch ein mit einer Host-Vorrichtung verbundenen Port, der zu einer in der Tabelle gespeicherten Multicast-Gruppe gehört, empfangen wird, und wenn das empfangene Paket ein Multicast-Paket ist, wird das empfangene Paket an den zur Multicast-Gruppe gehörenden Multicast-Router, übertragen, durch Bezugnahme auf die Tabelle, so dass ein Ablauf der Überprüfung des Multicast-Gruppen-Management-Protokolls weggelassen werden kann, und mit diesem Merkmal kann die Übermittlung eines Multicast-Pakets schneller gemacht werden.
  • Wenn mit der vorliegenden Erfindung ein Paket durch einen Port, mit dem der Router verbunden ist, empfangen wird, und wenn das empfangene Paket ein Multicast-Paket ist, wird das empfangene Paket an den Multicast-Router übertragen, durch Bezugnahme auf die Tabelle, so dass es möglich ist den Betrieb eines Multicast-Routing-Protokolls auf dem Netzwerk zu garantieren, wobei das Netzwerk eine Vielzahl von Multicast-Routern und eine Vielzahl von Schalt-Hubs umfasst.
  • Wenn mit der vorliegenden Erfindung das Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll eine Anfrage ist, die eine Host-Vorrichtung danach fragt ein Mitglied einer Multicast-Gruppe zu werden, wird nur ein erster Bericht in jeder Multicast-Gruppe unter den Berichten, die alle einen Wunsch haben ein Mitglied einer Multicast-Gruppe zu werden, welche durch jeden der Ports empfangen werden, an einen entsprechenden Port übertragen, mit dem der Multicast-Router verbunden ist, durch Bezugnahme auf die Tabelle während der spezifischen, vorbestimmten Zeitspanne innerhalb der Anfrage, und die folgenden Berichte werden verworfen, nachdem die spezifische Zeitspanne verstrichen ist, so dass die Überlappung von Berichten an einen Multicast-Router durch ihre Übertragung sogar auf einem Netzwerk vermieden werden kann, in dem das Subnetz eine große Anzahl von Schalt-Hubs umfasst und die Host-Vorrichtungen, die den Empfang von Multicast-Daten wünschen, mit einer großen Anzahl von Ports aller Schalt-Hubs verbunden werden.
  • Sogar wenn mit der vorliegenden Erfindung bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß einem Multicast-Gruppen-Management-Protokoll ist, aber wenn das empfangene Paket nicht einer jeglichen Art von Anfrage an eine Host-Vorrichtung, ein Mitglied einer Multicast-Gruppe zu werden, entspricht, und/oder einem Bericht, dass eine Host-Vorrichtung wünscht ein Mitglied einer Multicast-Gruppe zu werden, und/oder eines Verlassens, das anzeigt, dass eine Host-Vorrichtung wünscht eine Multicast-Gruppe zu verlassen, wird das empfangene Paket an die Vielzahl aller Ports übertragen, so dass, wenn nicht bestimmt werden kann, zu welcher Art ein Multicast-Paket entspricht, die Bestimmung jeder Vorrichtung überlassen werden kann als ein Zielort, an den das Paket übertragen wird.
  • Sogar wenn mit der vorliegenden Erfindung bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß einem Multicast-Gruppen-Management-Protokoll ist, aber wenn das empfangene Paket nicht einer jeglichen Art von Anfrage an eine Host-Vorrichtung, ein Mitglied einer Multicast-Gruppe zu werden entspricht, und/oder einem Bericht, das eine Host-Vorrichtung wünscht ein Mitglied einer Multicast-Gruppe zu werden, und/oder eines Verlassens, das anzeigt, dass eine Host-Vorrichtung wünscht eine Multicast-Gruppe zu verlassen, das empfangene Paket verworfen wird, so dass eine unklare Art von Multicast-Paket aus einem Netzwerk gelöscht wird, wodurch eine effizientere, herkömmliche Multicast-Paketübertragung erlaubt wird.
  • Mit der vorliegenden Erfindung gibt es Schritte zur Bestimmung von Inhalten eines empfangenen Pakets und Erzeugens einer Tabelle, die eine Korrelation zwischen den Host-Vorrichtungen und den Multicast-Gruppen aufzeigt zur Kontrolle eines Wegs von einem Multicast-Paket gemäß dem empfangenen Paket, wenn bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß einem Multicast-Gruppen-Management-Protokoll ist, so dass Bedingungen aufrechterhalten werden können innerhalb des Pakets zur Steuerung der Multicast-Übertragung eines Multicast-Pakets nur an die erforderlichen Host-Vorrichtungen mit dem existierenden Protokoll und dem Netzwerk-Aufbau.
  • Mit der vorliegenden Erfindung gibt es auch einen Schritt zur Übertragung, eines Pakets für jede Multicast-Gruppe zwischen dem Multicast-Router und Host-Vorrichtungen gemäß der Tabelle, die eine Korrelation zwischen Host-Vorrichtungen und Multicast-Gruppen aufzeigt, wenn ein Multicast-Paket vom Multicast-Router empfangen wird, so dass ein Multicast-Paket über Multicast nur an die erforderlichen Host-Vorrichtungen mit dem existierenden Protokoll und dem Netzwerk-Aufbau übertragen werden kann, und mit diesem Merkmal ist es möglich effiziente Übertragung sowohl für Multicast- als auch für Unicast-Daten zu realisieren.
  • Andere Ziele und Merkmale der Erfindung werden von der folgenden Beschreibung unter Bezugnahme auf die begleitenden Zeichnungen vermittelt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist eine Darstellung, die ein Beispiel der Ausführung eines Multicast unterstützenden LAN aufzeigt, in dem die Kommunikationssteuereinheit gemäß einer Ausführungsform der vorliegenden Erfindung angewendet wird.
  • 2 ist ein Blockdiagramm, das funktionsgemäß die Kommunikationssteuereinheit gemäß einer Ausführungsform der vorliegenden Erfindung aufzeigt;
  • 3 ist ein Blockdiagramm, das die Hardware der Kommunikationssteuereinheit gemäß einer Ausführungsform der vorliegenden Erfindung aufzeigt;
  • 4 ist eine Darstellung, die ein Beispiel von Inhalten, die in einer Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle gespeichert werden, aufzeigt;
  • 5 ist eine Darstellung, die ein Beispiel von Inhalten, die in einer Multicast-Routerverbindungsportnummer-Speicherungstabelle gespeichert werden;
  • 6 ist eine Darstellung zur Erklärung eins IGMP-Pakets auf Ethernet;
  • 7 ist eine Darstellung, die ein Format auf einem IGMP-Nachrichtenpaket aufzeigt;
  • 8 ist eine Darstellung, die ein Format auf einem IP-Header aufzeigt;
  • 9 ist eine Darstellung, die ein Format auf einer IGMP-Version 1-Nachricht aufzeigt;
  • 10 ist eine Darstellung, die ein Format auf einer IGMP-Version 2-Nachricht aufzeigt;
  • 11 ist eine Darstellung, die den Aufbau eines MAC-Headers im Fall von Ethernet aufzeigt;
  • 12 ist eine Darstellung, die den Aufbau eines Ping-Pakets aufzeigt;
  • 13 ist ein Flussdiagramm zur Erklärung eines Hauptbetriebs einer Kommunikationssteuereinheit gemäß der Ausführungsform;
  • 14 ist ein Flussdiagramm zur Erklärung eines Betriebs zum Zeitpunkt des Empfangs einer Anfrage;
  • 15 ist eine Darstellung, die einen Aufbau der herkömmlichen Art von Multicast unterstützenden LAN aufzeigt;
  • 16 ist eine Darstellung zur Erklärung eines Ablaufs der Teilnahme einer Host-Vorrichtung an einer Multicast-Gruppe; und
  • 17 ist eine Darstellung zur Erklärung eines Ablaufs des Verlassens einer Multicast-Gruppe durch eine Host-Vorrichtung.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Im Folgenden werden bevorzugte Ausführungsformen einer Kommunikationssteuereinheit und eines Kommunikationssteuerverfahrens detailliert beschrieben, die auf ein Multicast unterstützendes LAN mit Bezug auf die damit in Verbindung stehenden Zeichnungen angewendet werden.
  • Zuerst wird ein Multicast unterstützendes LAN beschrieben. 1 ist eine Darstellung, die ein Beispiel des Aufbaus des Multicast unterstützenden LAN aufzeigt, in dem die Kommunikationssteuereinheit gemäß einer Ausführungsform der vorliegenden Erfindung angewendet wird. Das Multicast unterstützende LAN, das in der Figur aufgezeigt ist, zeigt einen Abschnitt eines Subnetzes SN. Dieses Subnetz SN umfasst zwei Einheiten der Kommunikationssteuereinheiten 1A und 1B, die zwischen Multicast-Router 11 und 12 seriell miteinander verbunden werden; Host-Vorrichtungen 21, 22, 23 und 24 sind mit der Kommunikationssteuereinheit 1A verbunden; und Host-Vorrichtungen 25 und 26 sind mit der Kommunikationssteuereinheit 1B verbunden.
  • Hierin sind die Multicast-Router 11 und 12 Router, die IGMP unterstützen als ein Multicast-Management-Protokoll, das für Kommunikationen mit den Host-Vorrichtungen benutzt wird. Die Host-Vorrichtungen 21 bis 26 sind Vorrichtungen wie PCs und Arbeitsstationen, und jede Vorrichtung hat eine Funktion, die gemäß IGMP betriebsbereit ist. Deswegen werden die existierenden Vorrichtungen auf die Multicast-Router 11, 12 und die Host-Vorrichtungen 21 bis 26 angewendet.
  • Im Folgenden werden die Kommunikationssteuervorrichtungen 1A und 1B detailliert beschrieben. Die Ausführung der Kommunikationssteuereinheit 1A ist dieselbe wie die der Kommunikationssteuereinheit 1B, Funktionen und Hardware betreffend, so dass die Beschreibung nachstehend den Aufbau der Kommunikationssteuereinheit 1A als einen Stellvertreter herausgreift. 2 ist ein Blockdiagramm, das funktionsgemäß die Kommunikationssteuereinheit 1A gemäß einer Ausführungsform der vorliegenden Erfindung aufzeigt.
  • Die Kommunikationssteuereinheit 1A umfasst, wie in 2 aufgezeigt, einen Port-Abschnitt 2 zur Verbindung mit den Host-Vorrichtungen 21 bis 24, einen Multicast-Router 11 und die Kommunikationssteuereinheit 1B; ein Multicast-Verarbeitungsabschnitt 3, die ein Multicast-Pakettyp-Bestimmungs-/-Paketumschaltabschnitt 4 umfasst zur Bestimmung, ob ein Paket, der vom Port 2 empfangen wurde, ein Multicast-Paket oder ein IGMP-Nachrichtenpaket ist und zur Verarbeitung als eine bestimmte Art, und einen IGMP-Verarbeitungsabschnitt 5 zur Verarbeitung einer IGMP-Nachricht; ein Paketumschaltabschnitt 6 zur Durchführung derselben Paketübertragung wie die der üblichen Kommunikationssteuereinheit; ein Portnummer-Unicast-Adressen-Korrelationsspeicherungsabschnitt 7 zur Speicherung einer Korrelation zwischen Portnummern und Unicast-Adressen; ein Portnummer-Multicast-Adressen-Korrelationsspeicherungsabschnitt 8 zur Speicherung einer Korrelation zwischen Portnummern und Multicast-Adressen; und ein Multicast-Routerverbindungsport-Speicherabschnitt 9 zur Speicherung einer Korrelation zwischen Multicast-Routern und verbundenen Ports.
  • Im Folgenden wird die Hardware der Kommunikationsteuereinheit 1A beschrieben, die funktionsgemäß in 2 aufgezeigt ist. 3 ist ein Blockdiagramm, das die Hardware der Kommunikationssteuereinheit 1A aufzeigt.
  • Die Kommunikationssteuereinheit 1A umfasst, wie in 3 als eines der Beispiele aufgezeigt, einen Port 101 entsprechend dem Portabschnitt 2 zur Durchführung der Funktion davon; einen Multicast-Paketverarbeitungsabschnitt 102 genauso wie einen Bericht-Steuerungstimer 110 entsprechend des Multicast-Verarbeitungsabschnitts 3 zur Durchführung der Funktion davon; einen Pakettyp-Bestimmungs-/-Übermittlungsabschnitt 103 entsprechend des Multicast-Pakettyp-Bestimmungs-/-Paketumschaltabschnitts 4 zur Durchführung der Funktion davon; einen IGMP-Verlassensnachricht-Verarbeitungsabschnitt 104 entsprechend des IGMP-Verarbeitungsabschnitts 5 zur Durchführung der Funktion davon; einen Schalt-Hub-Abschnitt 105 entsprechend des Paketumschaltabschnitts 6 zur Durchführung der Funktion davon; eine Portnummer-Unicast-Adressen-Korrelationsspeicherungstabelle 106 entsprechend des Portnummer-Unicast-Adressen-Korrelationsspeicherabschnitts 7 zur Durchführung der Funktion davon; einen Portnummer-Multicast-Adressenkorrelations-Datenspeicher 107 entsprechend des Portnummer-Multicast-Adressen-Korrelationsspeicherungsabschnitts 8 zur Durchführung der Funktion davon; einen Tabellen-Eingangstimer 111; einen Multicast-Router-Verbindungport-Datenspeicher 108 genauso wie einen Ping-Verarbeitungsabschnitt 112 entsprechend des Multicast-Router-Verbindungsport-Speicherabschnitt 9 zur Durchführung der Funktion davon; und eine externe Endgerätschnittstelle 109.
  • Der Port 101 wird als ein Beispiel in sieben Portnummern aufgeteilt. Wenn das Subnetz SN in 1 als ein Beispiel herausgegriffen wird, ist der Multicast-Router 11 mit einem Port #1 verbunden, die Host-Vorrichtungen 21, 22, 23 und 24 sind mit dem Ports #2, #3, #4 bzw. #5 verbunden, und die Kommunikationssteuereinheit 1B ist mit einem Port #7 verbunden. Es sollte bemerkt werden, dass ein Port #6 nicht zugänglich ist.
  • Im Multicast-Paketverarbeitungsabschnitt 102 umfasst der Pakettyp-Bestimmungs-/-Übermittlungsabschnitt 103 einen Unicast-Broadcast-/Multicast-Paketbestimmungsabschnitt 201, einen Unicast-Broadcast-/Multicast-Paketumschaltabschnitt 202, und einen IGMP-Nachricht-Bestimmungs-/-Verarbeitungsabschnitt 203. Der Unicast-Broadcast-/Multicast-Paketbestimmungsabschnitt 201 bestimmt, ob ein empfangenes Paket ein Unicast-Broadcast-Paket oder ein Multicast-Paket ist.
  • Der Unicast-Broadcast-/Multicast-Paketumschaltabschnitt 202 führt Paketübertragung sowohl gemäß eines Falls des Unicast-Broadcast als auch eines Falls des Multicast aus. Der IGMP-Nachrichten-Bestimmungs-/-Verarbeitungsabschnitt 203 bestimmt, wenn bestimmt wird, dass das empfangene Paket das Multicast-Paket ist, die Art der IGMP-Nachricht (Anfrage, Bericht, Verlassen) und führt Verarbeitung gemäß der Art aus.
  • Hier kennzeichnet ein Begriff „Anfrage" eine Nachricht, die an jede Host-Vorrichtung von einem Multicast-Router übertragen wird, um die Host-Vorrichtung zu fragen, ein Mitglied einer Multicast-Gruppe zu werden, und ein Begriff „Bericht" kennzeichnet eine Nachricht, die von einer Host-Vorrichtung an einen Multicast-Router übertragen wird, um dem Router den Wunsch ein Mitglied einer Multicast-Gruppe zu werden, mitzuteilen. Ein Begriff „Verlassen" kennzeichnet eine Nachricht, die von einer Host-Vorrichtung an einen Multicast-Router übertragen wird, um das Verlassen von der Multicast-Gruppe zu wünschen.
  • Der IGMP-Verlassen-Nachrichtenverarbeitungsabschnitt 104 umfasst einen Multicast-physikalische Adressen-Erzeugungsabschnitt 204. Dieser Multicast-physikalische Adressen-Erzeugungsabschnitt 204 holt eine IP-Multicast-Adresse, der in einem Abschnitt einer IGMP-Verlassens-Nachricht eingebettet ist, und zwar von einer Verlassensnachricht vom IGMP-Nachrichten-Bestimmungs-/-Verarbeitungsabschnitt 203, wandelt die Adresse in eine Multicast-MAC-Adresse um und löscht eine entsprechende Korrelation zwischen einer Portnummer und einer Multicast-MAC-Adresse des Portnummer-Multicast-Adressenkorrelations-Datenspeichers 107. Der Bericht-Steuerungstimer 110 ist mit dem IGMP-Nachrichten-Bestimmungs-/-Verarbeitungsabschnitt 203 verbunden und misst, wenn ein empfangenes Paket eine Anfrage ist, eine maximale Ankunftszeit, die in der Anfrage zum Zeitpunkt festgesetzt wird, wenn die Anfrage empfangen wird.
  • Der Schalt-Hub-Abschnitt 105 und die Portnummer-Unicast-Adressen-Korrelationsspeicherungstabelle 106 realisieren eine Funktion wie ein Schalt-Hub, der in einer üblichen Kommunikationssteuereinheit in Betrieb ist. Und zwar, wenn im Unicast-Broadcast-/Multicast-Paketbestimmungsabschnitt 201 bestimmt wird, dass das empfangene Paket ein Unicast-Paket oder Broadcast-Paket ist, wird das Unicast-Paket oder Broadcast-Paket zum Schalt-Hub 105 durch den Unicast-Broadcast-/Multicast-Paketumschaltabschnitt 202 gesendet, und ein herkömmlicher Schaltbetrieb wird hierin ausgeführt.
  • Der Portnummer-Multicast-Adressenkorrelations-Datenspeicher 107 ist eine Datenspeichereinheit zur Regelung einer Korrelation zwischen jeder Portnummer des Ports 101 und Multicast-Adresse (jede MAC-Adresse von Host-Vorrichtungen als Mitglieder der Multicast-Gruppe). Dieser Portnummer-Multicast-Adressenkorrelations-Datenspeicher 107 umfasst einen Tabellen-Lese-/-Schreib-/-Entfernungssteuerungsabschnitt 205, eine Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 und einen Tabellen-Schreibe-Entfernungssteuerungsabschnitt 207.
  • Die Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 speichert eine Korrelation zwischen jeder Portnummer des Ports 101 und Multicast-Adresse (jede MAC-Adresse von Host-Vorrichtungen als Mitglieder der Multicast-Gruppe) als eine Tabelle. Der Tabellen-Lese-/Schreib-/-Entfernungssteuerungsabschnitt 205 aktualisiert (Lesen/Schreiben/Aktualisieren) die Korrelation auf der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gemäß Kontrollen, die durch den Multicast-Paket-Verarbeitungsabschnitt 102 vorgesehen sind.
  • Der Tabellen-Schreib-/-Entfernungssteuerungsabschnitt 207 entfernt eine entsprechende Korrelation auf der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206, wenn durch einen Tabellen-Eingangstimer 111 gemessen wird, dass eine vorbestimmte Zeitspanne oder mehr verstrichen ist, für eine Zeitspanne zwischen einer Anfrage und einem Bericht dazu. Der Tabellen-Eingangstimer 111 misst eine Zeitspanne zwischen einer Anfrage und einem Bericht dazu in der Korrelation auf der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206.
  • Der Multicast-Router-Verbindungport-Datenspeicher 108 ist eine Datenspeichereinheit zur Regelung einer Korrelation zwischen jeder Portnummer des Ports 101 und Multicast-Router-Adresse. Dieser Multicast-Router-Verbindungsport-Datenspeicher 108 umfasst einen Tabellen-Lese-/-Schreib-/-Entfernungssteuerungsabschnitt 208, eine Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 und einen Tabellen-Schreib-/Entfernungssteuerungsabschnitt 210.
  • Die Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 speichert eine Korrelation zwischen jeder Portnummer des Ports 101 und Multicast-Router-Adresse als eine Tabelle. Der Tabellen-Lese-/-Schreib-/-Entfernungssteuerungsabschnitt 208 aktualisiert (Lesen/Schreiben/Aktualisieren) die Korrelation auf der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gemäß Kontrollen, die vom Mutlicast-Paket-Verarbeitungsabschnitt 102 vorgesehen sind.
  • Der Tabellen-Schreib-/Entfernungssteuerungsabschnitt 210 entfernt eine entsprechende Korrelation (Multicast-Router-Adresse) auf der Multicast-Router-Verbindungsportnummer-Speicherungstabelle 209, wenn durch den Pingverarbeitungsabschnitt 112 gemessen wird, dass eine vorbestimmte Zeit oder mehr verstrichen ist, für eine Zeitspanne, bis eine Antwort auf den Ping zum Multicast-Router erfolgt. Der Pingverarbeitungsabschnitt 112 misst eine Antwortszeit zu einem Ping in der Korrelation auf der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209.
  • Hierin arbeitet die externe Endgeräteschnittstelle 109 als eine Schnittstelle zwischen einer externen Vorrichtung, die dazu verbunden ist und den internen Abschnitten. Inhalte, die in der Portnummer-Mutlicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 genauso wie in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert werden, können mit einer Vorschrift durch eine externe Vorrichtung aktualisiert werden, die mit der externen Endgeräteschnittstelle 109 verbunden ist.
  • Im Folgenden werden die Inhalte der Tabellen beschrieben. 4 ist eine Darstellung, die ein Beispiel der Inhalte aufzeigt, die in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gespeichert werden, und 5 ist eine Darstellung, die ein Beispiel der Inhalte aufzeigt, die in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert werden. Jede der gespeicherten Inhalte in 4 bzw. 5 folgt dem Subnetz SN, das in 1 aufgezeigt ist. 4 zeigt eine Korrelation zwischen Portnummern und Multicast-MAC-Adressen. Eine Anzahl von Multicast-MAC-Adressen bis zu m-Einheiten (m: natürliche Zahl) kann an alle Portnummern gesetzt werden. Im Beispiel von 4 werden eine oder mehrere Multicast-MAC-Adressen an jede der Portnummern 2, 3, 4, 5 und 7 zugewiesen.
  • Der Portnummer 2 sind zwei Adressen, 01:00:5e:xx:xx:xx und 01:00:5e:zz:zz:zz, als Multicast-MAC-Adressen zugewiesen. Dementsprechend ist die Host-Vorrichtung 21 ein Mitglied von zwei Multicast-Gruppen. Der Portnummer 3 ist eine Adresse von 01:00:5e:yy:yy:yy als eine Multicast-MAC-Adresse zugewiesen.
  • Dementsprechend ist die Host-Vorrichtung 22 ein Mitglied einer Multicast-Gruppe. Der Portnummer 4 ist eine Adresse 01:00:5e:zz:zz:zz als eine Multicast-MAC-Adresse zugewiesen.
  • Dementsprechend ist die Host-Vorrichtung 23 ein Mitglied einer Multicast-Gruppe.
  • Der Portnummer 5 sind zwei Adressen, 01:00:5e:ww:ww:ww und 01:00:5e:zz:zz:zz, als Multicast-MAC-Adressen zugewiesen. Dementsprechend ist die Host-Vorrichtung 24 ein Mitglied von zwei Multicast-Gruppen. Der Portnummer 7 sind drei Adressen, 01:00:5e:zz:zz:zz, 01:00:5e:yy:yy:yy und 01:00:5e:xx:xx:xx, als Mutlicast-MAC-Adressen zugewiesen. Dementsprechend sind die Host-Vorrichtungen 25 und 26, die zur Kommunikationssteuereinheit 1B gehören, Mitglieder von drei Multicast-Gruppen.
  • In den Multicast-MAC-Adressen wird die Adresse 01:00:5e:xx:xx:xx den Portnummern 2 und 7 zugewiesen, die anzeigen, dass die Host-Vorrichtung 21 und die Host-Vorrichtungen, die zur Kommunikationssteuereinheit 1B gehören, Mitglieder der gemeinsamen Multicast-Gruppe sind. Die Adresse 01:00:5e:yy:yy:yy wird den Portnummern 3 und 7 zugewiesen, die anzeigen, dass die Host-Vorrichtung 22 und die Host-Vorrichtungen, die zur Kommunikationssteuereinheit 1B gehören, Mitglieder der gemeinsamen Multicast-Gruppe sind.
  • Die Adresse 01:00:5e:zz:zz:zz wird den Portnummern 2, 4, 5 und 7 zugewiesen, die anzeigen, dass sowohl die Host-Vorrichtungen 21, 23 und 24 als auch die Host-Vorrichtungen, die zur Kommunikationssteuereinheit 1B gehören, Mitglieder der gemeinsamen Multicast-Gruppe sind. Die Adresse 01:00:5e:ww:w:ww wird nur der Portnummer 5 zugewiesen, die anzeigt, dass nur die Host-Vorrichtung 24 im Subnetz SN ein Mitglied dieser Multicast-Gruppe ist. Es sollte bemerkt werden, dass alle Bezugsymbole X, Y, Z, W in „xx:xx:xx", „yy:yy:yy", „zz:zz:zz" und „ww:ww:ww" nicht immer dieselbe Nummer anzeigen.
  • 5 zeigt eine Korrelation zwischen Portnummern und detektierten oder nichtdetektierten Multicast-Router-Adressen. Die Anzahl der Multicast-Router-Adressen bis zu m-Einheiten kann an jede der Portnummern gesetzt werden. Im Beispiel von 5 werden eine oder mehrere der Multicast-Router-Adressen den Portnummern 1 und 7 zugewiesen. Der Multicast-Router 11 mit der Adresse aaa.aa.aaa.a und der Multicast-Router 12 (durch die Kommunikationssteuereinheit 1B) mit der Adresse bb.bb.bbb.bbb sind mit den Portnummern 1 bzw. 7 verbunden.
  • Dementsprechend ist in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209, wie in 5 gezeigt, „verbunden mit Multicast-Router oder nicht" JA, und „Multicast-Router-Adresse" ist aaa.aa.aaa.a, wobei jede Adresse der Portnummer 1 entspricht, und „verbunden mit Multicast-Router oder nicht" ist JA, und „Multicast-Router-Adresse" ist bbb.bb.bbb.bbb, wobei jede Adresse der Portnummer 7 entspricht. Es sollte bemerkt werden, dass alle Referenzsymbole a und b nicht immer dieselbe Nummer anzeigen.
  • Im Folgenden wird ein Paket beschrieben. Die unten angeführte Beschreibung setzt einen Fall voraus, dass ein Netzwerkmedium Ethernet ist. 6 ist eine Darstellung zur Erklärung eines IGMP-Pakets auf Ethernet. 7 ist eine Darstellung, die ein Format eines IGMP-Nachrichtenpakets aufzeigt, 8 ist eine Darstellung, die ein Format eines IP-Headers aufzeigt, 9 ist eine Darstellung, die ein Format einer IGMP-Version 1-Nachricht aufzeigt, 10 ist eine Darstellung, die ein Format einer IGMP-Version 2-Nachricht aufzeigt, 11 ist eine Darstellung, die einen Aufbau eines MAC-Headers im Fall von Ethernet aufzeigt, und 12 ist eine Darstellung, die einen Aufbau eines Ping-Pakets aufzeigt.
  • In der Abbildung von Multicast-IP-Adressen und Bitübertragungsschicht-Adressen, wie im Fall in 6 aufgezeigt, wird im Standard eine Korrelation zwischen einer Multicast-IP-Adresse (auch genannte eine IP-Adresse in Klasse D) und einer physikalischen Adresse (die aktuelle Version ist RFC1700) definiert, dass 23 Bits in der niedrigen Reihenfolge einer IP-Adresse der Klasse D in 23 Bits in der niedrigen Reihenfolge einer Multicast-physikalischen Adresse „01.00.5E.00.00.00 (hexadezimal)" gesetzt werden sollte. Zum Beispiel entspricht eine Multicast-IP-Adresse „239.133.130.34 (hexadezimal)" einer MAC-Adresse „01.00.5E.82.22 (hexadezimal)".
  • Das IGMP-Nachrichtenpaket besteht aus, wie in 7 aufgezeigt, einem MAC-Header (14 Bytes), einem IP-Header (20 Bytes, keine Option), einer IGMP-Nachricht (8 Bytes) und einem FCS (Flag Check Sequence).
  • Der IP-Header besteht aus, wie in 8 aufgezeigt, Version, Header-Länge (IHL), Dienstart, Paketlänge (totale Länge), Identifikation, Flags, Fragment-Offset, Lebenszeit, Protokoll, Header-Prüfsumme, Quellen-IP-Adresse (Quellen-Adresse), Zielort-IP-Adresse (Zielort-Adresse), Optionen, Padding.
  • Die Version besteht aus 4 Bits und kennzeichnet eine Versionsnummer des IP-Headers. Die Header-Länge (IHL) besteht aus 4 Bits und kennzeichnet eine Größe des IP-Headers an sich. Die Dienstart besteht aus 8 Bits und kennzeichnet die Dienstqualität des übertragenen IP. Die Paketlänge besteht aus 16 Bits und kennzeichnet eine Oktettlänge eines gesamten Pakets, die erhalten wird durch Hinzufügen des IP-Headers und IP-Daten dazu. Die Identifikation besteht aus 16 Bits und wird benutzt als Bezugsinformation, wenn Daten an eine höheren Schicht übertragen werden. Die Flags bestehen aus 3 Bits und kennzeichnen eine Anweisung, um eine Aufteilung des Pakets zu steuern. Der Fragment-Offset besteht aus 13 Bits und kennzeichnet, an welchem Teil der Originaldaten jedes aufgeteilte Fragment positioniert ist.
  • Die Lebenszeit besteht aus 8 Bits und kennzeichnet, wie lange das Paket auf dem Netzwerk in Sekundeneinheiten existieren kann. Das Protokoll besteht aus 8 Bits und kennzeichnet ein Protokoll auf der höheren Schicht. Die Header-Prüfsumme besteht aus 16 Bits und kennzeichnet eine Prüfsumme für den IP-Header.
  • Die Quellen-IP-Adresse besteht aus 32 Bits und kennzeichnet eine IP-Adresse der Quelle. Die Zielort-IP-Adresse besteht aus 32 Bits und kennzeichnet eine IP-Adresse des Zielorts. Die Optionen haben eine variable Länge und werden für Fälle benutzt wie beispielsweise einer Sicherheitskennzeichnung, einer Quellenroute, einer Routenaufnahme und einer zeitlichen Abtastung. Padding wird benutzt, wenn die Optionen hinzuaddiert werden und wenn die Größe des Headers kein ganzzahliges Vielfaches von 32 Bits ist, wodurch das Defizit abgedeckt wird.
  • Die IGMP-Version 1-Nachricht besteht aus, wie in 9 aufgezeigt, Version, Typ, unbenutzt, Prüfsumme und Gruppen-Adresse. Die Version besteht aus 4 Bits und kennzeichnet Version 1 in RFC 1112. Der Typ besteht aus 4 Bits und kennzeichnet einen Typ der IGMP-Nachricht. Und zwar, „1" kennzeichnet eine Anfrage und „2" kennzeichnet einen Bericht. Unbenutzt besteht aus 8 Bits und kennzeichnet Null (0). Die Prüfsumme besteht aus 16 Bits und kennzeichnet eine Prüfsumme, die auf dieselbe Art und Weise wie bei ICMP berechnet wird. Die Gruppen-Adresse besteht aus 32 Bits und kennzeichnet Null, wenn die Nachricht einer Anfrage ist und auch eine Adresse einer Multicast-Gruppe, unter der eine Host-Vorrichtung ein Mitglied sein soll, wenn die Nachricht ein Bericht ist.
  • Die IGMP-Version 2-Nachricht besteht aus, wie in 10 aufgezeigt, 8-Bit Typ, 8-Bit maximale Antwortzeit (Max Resp Time), Prüfsumme, und Gruppen-Adresse ohne Version darin. In Version 2 wird die maximale Antwortzeit eingefügt. Diese maximale Antwortzeit kennzeichnet eine temporäre Zeit zur Übertragung nur eines ersten Teils des Berichts für jede Multicast-Adresse unter den Berichten, die von jedem Port empfangen wurden, zum Multicast-Router.
  • Der MAC-Header besteht aus, wie in 11 aufgezeigt, einem Zielort-Adressfeld zur Einfügung einer Zielort-MAC-Adresse (6 Bytes), einem Quellen-Adressfeld zur Einfügung einer Quellen-MAC-Adresse (6 Bits), und eines Typfelds zur Einfügung eines Protokolltyps (2 Bytes).
  • Das Ping-Paket besteht aus, wie in 12 aufgezeigt, einem MAC-Header (4 Bits), einem IP-Header (20 Bytes, keine Optionen), einer ICMP (Internet Control Message Protocol = Internet-Steuerungsnachricht-Protokoll)-Nachricht und FCS.
  • Im Folgenden wird ein Betrieb beschrieben. 13 ist ein Flussdiagramm zur Erklärung eines Hauptbetriebs der Kommunikationssteuereinheit. In der Konfiguration in 3, wenn ein Paket durch den Port 101 (Schritt S1) empfangen wird, wird in der Unicast-Broadcast-/Multicast-Paketbestimmungsabschnitt 201 bestimmt, ob das Paket ein Unicast-/Broadcast-Paket oder ein Multicast-Paket (Schritt S2) ist. Ein Verfahrung zur Bestimmung wird basierend auf einer physikalischen Adresse eines Multicast-Pakets durchgeführt. Und zwar, die MAC-Adresse, wie in 6 aufgezeigt und die Bestimmung können nur gemacht werden durch Bestätigung, dass die Adresse „0000 0001" in 8 Bits vom Header davon ist, die schnell bestimmt werden können durch die Verarbeitung in der Hardware.
  • Wenn bestimmt wird, dass das Paket kein Multicast-Paket (Schritt S2) ist, wird das Paket durch die übliche LAN-Umschaltfunktion (Schritt S3) übertragen. Und zwar wird das Paket zum Schalt-Hub-Abschnitt 105 von dem Unicast-Broadcast-/Multicast-Paketumschaltabschnitt 202 gesendet, und wird dazu veranlasst die Verarbeitung für ein übliches Unicast-/Broadcast-Paket zu übermitteln, durch Bezugnahme auf die Portnummer-Unicast-Adressen-Korrelationsspeicherungstabelle 106.
  • Wenn andererseits bestimmt wird, dass das Paket ein Multicast-Paket (Schritt S2) ist, wird bestätigt, ob das Multicast-Paket Multicast-Daten oder ein IGMP-Nachrichtenpaket (Schritt S4) darstellt. Für die Bestätigung wir das Multicast-Paket zum IGMP-Nachrichten-Bestimmungs-/-Verarbeitungsabschnitt 203 gesendet. Das IGMP-Nachrichtenpaket hat das Format, wie in 7 aufgezeigt, und es wird bestimmt durch die Bestätigung, das das Protokollfeld im IP-Header, wie in 8 aufgezeigt, „2" ist. In diesem Fall kann die Bestimmung mit hoher Geschwindigkeit durch die Verarbeitung in der Hardware gemacht werden.
  • Dann, wenn bestimmt wird, dass das Multicast-Paket kein IGMP-Nachrichtenpaket (Schritt S4) ist, wird das empfangene Paket zum Port, mit dem eine Host-Vorrichtung als ein Mitglied damit verbunden ist übertragen, genauso wie eine andere Kommunikationssteuereinheit durch Bezugnahme auf die Portnummer-Mutlicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 (Schritt S5). Wenn andererseits bestimmt wird, dass das Multicast-Paket ein IGMP-Nachrichtenpaket (Schritt S4) ist, wird in den folgenden Schritten S6, S8 und S10 überprüft, welcher Typ die IGMP-Nachricht ist.
  • Es gibt hier zwei Versionstypen: Version 1, die in 9 aufgezeigt ist und Version 2 die in 10 aufgezeigt ist. Wenn Host-Vorrichtungen oder Multicast-Router die IGMP-Version 1 und IGMP-Version 2 unterstützen zusammen miteinander existieren, wie als eine Funktion der IGMP-Version 2 definiert, wird eine IGMP-Version 2 unterstützender Multicast-Router definiert, so dass der Router eine Nachricht verstehen kann, basierend auf der IGMP-Version 1 und Verarbeitung dafür ausführen kann. Aus diesem Grund treten keine Probleme auf, wenn die IGMP-Version 1 und IGMP-Version 2 zusammen miteinander existieren.
  • Eingebettet in die IGMP sind eine Anfrage und eine gruppenspezifische Anfrage, die alle als Nachricht durch einen Multicast-Router übertragen werden, und ein Bericht, der durch eine Host-Vorrichtung übertragen wird, und außerdem gibt es Verlassen, die durch eine Host-Vorrichtung in der IGMP-Version 2 übertragen wird. Jene Nachrichten können voneinander unterschieden werden durch Bezugnahme auf das Typfeld in der IGMP-Nachricht. Wenn der Betrieb basierend auf der IGMP-Version 1 durchgeführt wird, ist jedes Typfeld einer Anfrage und einer gruppenspezifischen Anfrage 0001 (binär) und das Typfeld eines Berichts ist 0010 (binär).
  • Wenn der Betrieb durchgeführt wird basierend auf der IGMP-Version 2, ist jedes Typfeld eine Anfrage eine gruppenspezifische Anfrage 00010001 (0x16), das Typfeld eines Berichts ist 00010110 (0x16), das Typfeld von Verlassen ist 00010111 (0x17) und das Typfeld eines Berichts für Kompatibilität mit IGMP-Version 1 ist 00010010 (0x12). Wie oben beschrieben wird es so verstanden, dass das obige Typfeld das selbe ist wie 00010010, das erhalten wird. durch Hinzufügen des Versionsfelds von Bericht, basierend auf der IGMP-Version 1 zum Typfeld davon.
  • Die Abgrenzung zwischen einer Anfrage und einer gruppenspezifischen Anfrage kann gemacht werden, weil eine Zielort-IP-Adresse in einer Anfrage 224.0.0.1 ist, die MAC-Adresse ist damit 01:00:5E:00:00:01, und eine gruppenspezifische Anfrage wird zu einer bestimmten Multicast-Gruppe übertragen, prüfend, ob jede Anfrage irgendeine Multicast-MAC-Adresse hat, die sich von den oben beschrieben Adressen unterscheidet oder nicht. Durch Bezugnahme auf jene Bit-Felder kann jede Nachricht zwischen IGMP-Version 1 und IGMP-Version 2 unterschieden werden, und diese Verarbeitung kann schnell in der Hardware ausgeführt werden. Da irgendwelche Nachrichten den oben beschriebenen Bit-Arrays nicht entsprechen, wird die Nachricht ohne darauf abgezielte Verarbeitung gelöscht, wie im Standard definiert.
  • Wenn bestimmt wird, dass das IGMP-Paket eine Anfrage ist gemäß dem Verfahren der Bestimmung, die oben beschrieben wurde (Schritt S6), wird die Portnummer, die das Paket empfangen hat, betrachtet, als wenn sie mit einer Multicast-Router verbunden ist und in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 registriert, und das empfangene Paket wird an alle anderen Ports übertragen (Schritt S7).
  • Wenn bestimmt wird, dass das IGMP-Paket ein Bericht (Schritt S8) ist, wird die physikalische Multicast-Adresse des Pakets korreliert mit einem empfangenen Port, und die Korrelation wird in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 registriert. Dann wird das empfangene Paket zum Multicast-Routerverbindungsport übertragen, durch Bezugnahme auf die Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 (Schritt S9).
  • Wenn bestimmt wird, dass das IGMP-Paket Verlassen (Schritt S10) ist, wird eine Korrelation zwischen der physikalischen Multicast-Adresse des Pakets und einem empfangenen Port aus der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 erfasst, und die entsprechende Korrelation wird gelöscht. Dann wird das empfangene Paket zum Multicast-Routerverbindungsport übertragen durch Bezugnahme auf die Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 (Schritt S11).
  • Wenn bestimmt wird, dass das IGMP-Paket nicht einer Anfrage, einem Bericht und Verlassen (Schritt S10) entspricht, wird das empfangene Paket betrachtet als ein unklares IGMP-Paket, das an alle anderen Ports zu übertragen ist (Schritt S12).
  • Im Folgenden wird ein konkretes Beispiel des Betriebs beschrieben, wenn eine Anfrage empfangen wird durch irgendeinen Port, der mit der Kommunikationssteuereinheit 1A oder 1B verbunden ist. 14 ist ein Flussdiagramm zur Erklärung des Betriebs zum Zeitpunkt des Empfangs der Anfrage. Wenn ein Paket auf eine Anfrage durch ein Port empfangen wird, wird das empfangene Paket an alle anderen Ports übertragen, wie oben beschrieben. Dann wird die maximale Antwortzeit, die im Anfrage-Paket eingebettet ist, im Bericht-Steuerungstimer 110 gesetzt, und der Bericht-Steuerungstimer 110 wird betätigt (Schritt S21).
  • Wenn die Messung durch den Bericht-Steuerungstimer 110 abgeschlossen ist, nämlich wenn überprüft wird, dass die maximale Antwortzeit verstrichen ist (Schritt S22), und wenn es abgeschlossen worden ist (verstrichen), wird die Verarbeitung beendet. Und wenn es nicht abgeschlossen worden ist (noch nicht verstrichen), wird die Anwesenheit des Ports, der den Bericht empfangen hat, überprüft, nachdem eine Anfrage empfangen worden ist (Schritt S23). Folglich, wenn irgendein Port, der den Bericht empfangen hat, nicht überprüft werden kann (Schritt S23), geht die Verarbeitung wieder auf Schritt S22 zurück. Wenn andererseits ein Bericht durch einen Port empfangen wird (Schritt S23), wird bestimmt, ob der Bericht den selben Zielort hat als den Zielort der Multicast-Adresse des Berichts, der empfangen worden ist, nachdem eine Anfrage empfangen worden ist oder nicht (Schritt S24).
  • Folglich, wenn bestimmt wird, dass der Bericht einen Zielort hat, der unterschiedlich ist von dem Zielort des Berichts, der bereits empfangen worden ist (Schritt S24), wird die physikalische Multicast-Adresse des empfangenen Pakets korreliert mit dem Port, der das empfangene Paket empfangen hat, und die Korrelation wird in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 registriert.
  • Das empfangene Paket wird zum Multicast-Router übertragen, durch Bezugnahme auf die Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 (Schritt S26). Dann geht die Verarbeitung auf Schritt S22 zurück. Wenn andererseits bestimmt wird, dass der Bericht den selben Zielort hat wie den Zielort des Berichts, der bereits empfangen worden ist (Schritt S24), sollte das empfangene Paket verworfen werden, weil die Berichte dann wiederholt zum Multicast-Router übertragen werden können. Dadurch soll die Wiederholung im Betrieb (Schritt S25) verhindert werden. Dann geht die Verarbeitung auf Schritt S22 zurück.
  • Mit der Ausführungsform von obiger Beschreibung wird ein Unicast-Broadcast-Paket unterschieden von einem Multicast-Paket, und außerdem wird das Multicast-Paket unterschieden von einem IGMP-Nachrichtenpaket, und wenn eine Anfrage bestimmt wird als ein Ergebnis der Unterscheidung, gibt es realisierte Betriebe zur Speicherung der Portnummer, die das Paket empfangen haben, und der Quellenadresse des Anfrage-Pakets in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 als eine Adresse des Multicast-Routers, und auch zur Übertragung der Daten an Ports, abgesehen von demjenigen Port, der die Anfrage empfangen hat.
  • Wenn mit jenen Betrieben die Anfrage empfangen wird durch alle Host-Vorrichtungen oder durch andere Router, oder wenn die Mehrzahl der Multicast-Router 11, 12 in 1 mit dem Subnetz SN verbunden werden, ist es möglich einen Betrieb des IGMP zu realisieren, dass die Anfrage durch beide Multicast-Router 11, 12 empfangen wird und dass die Bestimmung gemacht werden kann, welche der Router die Anfrage im Subnetz SN überträgt.
  • Wie im Subnetz SN, z. B. wenn eine Mehrzahl von Multicast-Router 11, 12 dazu verbunden sind, ist es möglich Betriebe zu garantieren, wobei irgendeine der Multicast-Router mit der kleinsten Adresse unter den Anfragen, die alle durch die Router empfangen werden, entschieden wird ein Multicast-Router zur konstanten und periodischen Übertragung einer Anfrage zu sein, während die anderen Multicast-Router die Anfrage empfangen, und wenn die Anfrage nicht empfangen wird, wird bestimmt, dass der Multicast-Router beschädigt ist, so dass ein Multicast-Router mit der zweitkleinsten IP-Adresse ein Router ist zur periodischen Übertragung einer Anfrage.
  • Da irgendeine der Multicast-Router 11, 12 eine Anfrage einmal überträgt, werden die Multicast-Router in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert, aber wenn herausgefunden wird, dass irgendeine der Multicast-Router 11, 12 beschädigt ist oder aus dem Subnetz SN entfernt worden ist, kann der Eingang des entsprechenden Multicast-Routers aus der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gelöscht werden.
  • Aus diesem Grund wird gleichzeitig eine Quellenadresse (Adresse eines Multicast-Routers) einer Anfrage-Nachricht als eine Schnittstellenadresse des Multicast-Routers gespeichert, wenn die Anfrage empfangen wird, und ein Ping wird auch zum Multicast-Router übertragen, der die Anfrage einmal durch den Ping-Verarbeitungsabschnitt 112 empfangen hat, und wenn eine Antwort auf den Ping nicht zurückkehrt, kann der Adresseneingang des Multicast-Routers automatisch aus der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gelöscht werden.
  • Es sollte bemerkt werden, dass die Inhalte, die in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert werden, manuell hineingeschrieben oder davon entfernt werden können durch eine externe Vorrichtung, die mit der externen Endgeräteschnittstelle 109 verbunden ist.
  • Wenn Bericht empfangen wird durch ein Port, werden eine Zielort-Multicast-MAC-Adresse des Pakets und eine Portnummer, der das Paket empfangen hat, in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gespeichert, und werden auch an die Ports übertragen, die in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert werden. Wenn Daten mit den gespeicherten Multicast-Adressen in einem Schalt-Hub eingegeben werden, wird eine Portnummer, die die Übertragung der Multicast-Daten erfordert, erhalten, durch Bezugnahme auf die Inhalte, die in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gespeichert werden, so dass es möglich ist die Daten nur zu einem erforderlichen Port zu übertragen.
  • Wie für Funktionen der IGMP führt eine Host-Vorrichtung mit empfangenen Bericht für die selbe Multicast-Gruppe einen Betrieb aus, wobei die Host-Vorrichtung den Bericht an sich nicht überträgt, und in diesem Fall kann die Übertragung des Multicast-Pakets zum Port, mit dem die Host-Vorrichtung verbunden ist, nicht im Schalt-Hub gespeichert werden, so dass die Host-Vorrichtung das Paket nur zum, mit dem Multicast-Router verbundenen Port übertragen kann, der in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert ist und die Bericht-Nachricht nur zum Multicast-Router übertragen kann.
  • Die Inhalte, die in der Portnummer, Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gespeichert werden, können durch eine externe Vorrichtung, die mit der externen Endgeräteschnittstelle 109 verbunden ist, hineingeschrieben oder daraus entfernt werden
  • Wenn Verlassen empfangen wird durch einen Port in einem Schalt-Hub, kann das Verlassen nur durch einen Multicast-Router an der ersten Stelle empfangen werden. Daher kann das Verlassen-Paket nur zu einem, mit einem Multicast-Router verbundenen Port übertragen werden, der in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert ist.
  • Wenn außerdem das empfangene Paket zum IGMP-Verlassen-Nachricht-Verarbeitungsabschnitt 104 gesendet wird, wird eine IP-Multicast-Adresse, die in der Verlassen-Nachricht eingebettet ist, entnommen, und die entnommene Adresse wird umgewandelt in eine Multicast-MAC-Adresse in dem Multicast-physikalische Adressen-Erzeugungsabschnitt 204, und wenn herausgefunden wird, dass eine Korrelation zwischen der entsprechenden Portnummer und der Multicast-MAC-Adresse in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gespeichert wird, kann programmiert werden, die Korrelation daraus zu löschen und die Daten für die Multicast-Adresse nicht zum Port zu übertragen, der die Verlassen-Nachricht empfangen hat.
  • Wie für die Entnahme aus einer IP-Multicast-Adresse und der Umwandlung davon in eine physikalische Multicast-Adresse werden das IGMP-Paketformat und das Adresszuordnungsverfahren definiert, wie in 6, 9 und 10 aufgezeigt, so dass eine Verarbeitung mit hoher Geschwindigkeit durch die Hardware möglich ist.
  • Außerdem wird die folgende Modifikation in Betracht gezogen. Wenn die Verlassen-Nachricht empfangen wird um die Übertragung der Verarbeitung der Verlassen-Nachricht schneller zu machen, wird die Verlassen-Nachricht nicht nur zum, mit dem Multicast-Router verbundenen Port übertragen, der in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert wird, aber kann schnell übertragen werden an alle Ports, abgesehen von demjenigen Port, der die Verlassen-Nachricht empfangen hat, durch Weglassen der Verarbeitung durch Bezugnahme auf die Tabelle. Sogar wenn das Paket an ein Port übertragen wird, der dieses Paket nicht benötigt, hat das Paket eine kleine Menge von Daten, und die IP-Adresse von Verlassen ist ALL-ROUTERS-GROUP (224.0.0.2), so dass das Paket, das dabei empfangen wurde, dadurch ignoriert wird, und der Port kaum beeinflusst wird.
  • Wenn eine gruppenspezifische Anfrage empfangen wird, wird die gruppenspezifische Anfrage zur Multicast-Adresse des Verlassens übertragen, der unmittelbar vor dieser Übertragung übertragen wird. Aus diesem Grund wird durch die IGMP-Nachrichten-Bestimmtungs-/-Verarbeitungsabschnitt 203 detektiert, dass das Paket eine gruppenspezifische Anfrage ist, und wenn das herausgefunden wird, dass es irgendeinen Port gibt, der in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 in Korrelation mit der Multicast-MAC-Adresse gespeichert wird, mit der die gruppenspezifische Anfrage übertragen wird, wird das Paket nur zum Portübertragen, und es kann auch zu den Ports übertragen werden, die in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert werden, abgesehen von demjenigen Port, der das Paket empfangen hat.
  • Außerdem kann die folgende Modifikation in Betracht gezogen werden. Wenn eine gruppenspezifische Anfrage empfangen wird, um die Übertragungsverarbeitung der gruppenspezifischen Anfrage schneller zu machen, wird die gruppenspezifische Anfrage nicht nur zum entsprechenden Port übertragen, der in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 in Korrelation mit der Multicast-MAC-Adresse gespeichert ist, zu der die gruppenspezifische Anfrage übertragen wird, genauso wie der Port, der in der Multicast-Routerverbindungsportnummer-Speicherungstabelle 209 gespeichert ist, aber kann schnell an alle Ports übertragen werden, abgesehen von denjenigen Port, der die gruppenspezifische Anfrage empfangen hat, durch Ausführung der Verarbeitung der Bezugnahme auf die Tabelle.
  • Sogar wenn das Paket zu einem Port übertragen wird, der dieses Paket nicht benötigt, hat das Paket der gruppenspezifischen Anfrage eine kleine Menge von Daten, und wenn eine mit dem Port verbundene Host-Vorrichtung den Empfang des Pakets mit einem Zielort einer Multicast-Adresse nicht benötigt, wird das Paket ignoriert, so dass der Port kaum beeinflusst wird, wenn das Paket ignoriert wird durch die Host-Vorrichtung, die dieses Paket nicht benötigt.
  • Folgende Modifikation kann auch in Betracht gezogen werden. Wie für den Betrieb von IGMP überträgt eine Host-Vorrichtung, die eine Anfrage, welche periodisch durch einen Multicast-Router übertragen wird, empfängt, wenn die Host-Vorrichtung ein Mitglied einer Multicast-Gruppe wird, um Multicast-Daten zu empfangen, einen Bericht als eine Antwort, aber braucht nicht Multicast-Daten zum, mit der Host-Vorrichtung verbundenen Port zu übertragen, z. B. wenn die Anwendung ohne Übertragung des Verlassens beendet wird, der benötigt wird, wenn eine Host-Vorrichtung eine Gruppe verlassen soll, oder wenn die Leistungszufuhr unterbunden wird.
  • Wenn aus diesem Grund eine Anfrage von einem mit dem Multicast-Router verbundenen Port empfangen wird, wird ein Timer für jede Korrelation, der in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 gespeichert ist, die den Tabellen-Eingangstimer 111 benutzt, und wenn ein Bericht nicht von jeden der Ports empfangen wird, bis jeder Timer aufhört, wird eine Korrelation zwischen der physikalischen Multicast-Adresse und der Portnummer gelöscht, und die Übertragung von einem Multicast-Paket zum Port kann gestoppt werden.
  • Wenn der Empfang von Bericht und Verlassen im IGMP-Nachrichten-Bestimmungs-/-Verarbeitungsabschnitt 203 in den Kommunikationssteuereinheiten 1A und 1B überprüft wird, wird das IGMP-Paket an eine externe Vorrichtung, die mit der externen Endgeräteschnittstelle 109 verbunden ist, gesendet, und die externe Vorrichtung kann die Inhalte der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 aktualisieren.
  • In diesem Fall werden zumindest Abschnitte des Multicast-Paketverarbeitungsabschnitts 102 genauso wie der Bericht-Steuerungstimer 110 in der externen Vorrichtung vorgesehen, und wenn die Inhalte der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 aktualisiert werden, aktualisiert die externe Vorrichtung die Inhalte der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206, und kann die Übermittlung eines Datenpakets gemäß den aktualisierten Inhalten durchführen.
  • Mit diesem Merkmal kann die Registrierung des Empfangs eines Berichts in die Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 und eine Last einer Funktion der Entfernung des entsprechenden Ports genauso wie der Multicast-MAC-Adresse aus der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 durch Empfang einer Verlassen-Nachricht, den Einfluss auf die Umschaltfunktion für ein Datenpaket als eine Originalfunktion des Schalt-Hub einschränken.
  • Es wird auch eine Modifikation berücksichtigt, die auf eine Paketübermittlung mit hoher Geschwindigkeit abzielt, durch Weglassen eines Teils der Sequenz der Überprüfung einer IGMP-Nachricht. Eine IGMP-Nachricht, der von einem Port, welcher als ein mit dem Multicast-Router verbundenen Port gespeichert wird, übertragen, dadurch, dass eine Anfrage zu einer bestimmten Gruppe (unterschiedlich von der Adresse von ALL-ROUTERS-GROUP oder ALL-SYSTEMS-GROUP) empfangen wurde, zu der der Multicast-Router gehört, ist nur die gruppenspezifische Anfrage, die durch eine der Ports als Antwort auf die Aufnahme einer Verlassen-Nachricht übertragen wird zur Adresse von ALL-ROUTERS-GROUP, der durch eine Host-Vorrichtung übertragen wird. Aus der oben beschriebenen Tatsache wird klar, dass ein Paket, das durch mit dem Multicast-Router verbundenen Ports empfangenen wird, nur Multicast-Daten sind zu einer bestimmten Gruppe oder einer Anfrage, bis Verlassen durch eine der Ports empfangen wird.
  • Aus diesem Grund, bis eine Verlassen-Nachricht mit einer Multicast-MAC-Adresse, die in der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 existiert, durch einen der Ports empfangen wird, wird ein Multicast-Paket, der durch einen Port, der als ein mit dem Multicast-Router verbindender Port gespeichert wird, empfangen wird, nur mit den Inhalten der Portnummer-Multicast-physikalische Adressen-Korrelationsspeicherungstabelle 206 überprüft und die Bestimmung der Verarbeitung, ob das Paket eine IGMP-Nachricht ist oder nicht, damit weggelassen wird.
  • Dann wird das empfangene Paket auf dieselbe Art und Weise übermittelt, wie das für übliche Unicast-Daten durch Übertragung zu einem Port, der mit derselben physikalischen Multicast-Adresse korreliert ist, wie das des Pakets, der die Übermittlung der Verarbeitung eines Multicast-Pakets erlaubt, um schneller gemacht zu werden.
  • Außerdem kann die folgende Modifikation in Betracht gezogen werden. In den Kommunikationssteuereinheiten 1A und 1B wird ein Multicast-Paket durch einen Port empfangen, außer den mit den Multicast-Router verbundenen Port, der ein Multicast-Paket ist, der durch eine Host-Vorrichtung übertragen wird. Ein Bericht oder Verlassen im IGMP. Dementsprechend kann mit der Absicht der Einschränkung einer Verarbeitungslast im Schalt-Hub genauso wie die Übermittlungsverarbeitung eines Datenpakets schneller zu machen, ein Paket mit seiner Multicast-MAC-Adresse, die durch einen Port empfangen wird, unterschiedlich vom, mit dem Multicast-Router verbundenen Port eines Schalt-Hub übertragen werden an alle, mit dem Multicast-Router verbundenen Ports, ohne die Ausführung der Verarbeitung, ob das Paket eine IGMP-Nachricht ist oder nicht.
  • Die folgende Modifikation kann auch in Betracht gezogen werden. Ein Paket mit seiner Multicast-Adresse, der durch einen mit dem Multicast-Router verbundenen Port übertragen wird, enthält Nachrichten für ein Multicast-Routing-Protokoll wie PIM (Protocol Independet Multicast = protokollunabhängiges Multicast) und DVMRP (Distance Vector Multicast Routing Protocol = Distnazvektor-Multicast-Routing-Protokoll), abgesehen vom IGMP-Nachrichtenpaket und dem Multicast-Paket.
  • In einigen Fällen wird jede dieser Nachrichten zum Beispiel übertragen an „ALL-PIM-ROUTERS-GROUP (224.0.0.3)" und „DVMRP ROUTERS GROUP (224.0.0.4)", basierend auf einer Multicast zusätzlich zu einem benachbarten Router basierend auf Unicast, so dass ein Multicast-Paket, der durch einen mit dem Router verbundenen Port empfangen wird, an einen anderen Port, der in der Multicast-Router-Verbindungsportnummer-Speicherungstabelle gespeichert ist, übertragen werden kann, ohne einen Fehler in der Reihenfolge, um den Betrieb des Multicast-Routing-Protokolls auf dem Netzwerk, das eine Mehrzahl von Multicast-Routern und eine Mehrzahl von Schalt-Hubs umfasst, zu garantieren.
  • Es kann im Port, der den Bericht empfangen hat, herausgefunden werden, dass Daten, mit denen die Multicast-Adresse mit der Host-Vorrichtung verbunden ist, einen Wunsch signalisiert. Wenn dennoch ein Subnetz eine große Anzahl von Kommunikationssteuereinheiten umfasst, und wenn Host-Vorrichtungen, die die Aufnahme von Multicast-Daten wünschen, mit einer großen Anzahl von Ports verbunden werden, in jede der Kommunikationssteuereinheiten, wird die Anzahl von Berichten, die von allen Host-Vorrichtungen übertragen werden, groß, und führen zur Überlappung.
  • Wenn dann eine Anfrage-Nachricht, die durch einen Multicast-Router empfangen wird, übertragen wird, liest der IGMP-Nachrichten-Bestimmungs-/-Verarbeitungsabschnitt 203 eine maximale Antwortzeitwert, der innerhalb der Anfrage gesetzt wird, betätigt den Bericht-Steuerungstimer 110, der in einer maximalen Antwortszeit gesetzt wird, zum Zeitpunkt des Empfangs der Anfrage, überträgt nur jeden ersten Bericht für jede Multicast-Adresse unter den Berichten, die von den Ports empfangen werden, an einen mit dem Multicast-Router verbundenen Port, bis der Timer aufhört, und verwirft die verbleibenden Berichte. Mit jenen Betrieben ist es möglich die Wiederholung der Übertragung eines Berichts an den Multicast-Router zu vermeiden.
  • Die folgende Modifikation kann auch in Betracht gezogen werden. Eine IGMP-Nachricht kann überprüft werden mit der Tatsache, dass das Protokollfeld ein IP-Headers „2" ist, aber wenn ein Typfeld einer IGMP-Nachricht ein unbekannter Wert ist und der Typ davon nicht bestimmt werden kann, kann die Nachricht an alle Ports übertragen werden, abgesehen von denjenigen Ports, der die Nachricht empfangen hat, basierend auf der Idee, dass die Bestimmung den Host-Vorrichtungen, die zu einer Kommunikationssteuereinheit und Multicast-Router gehören, überlassen wird.
  • Die folgende Modifikation kann auch in Betracht gezogen werden. Ein unbekannter IGMP-Typwert kann in einer Stufe verworfen werden, wenn die Nachricht in den Kommunikationssteuereinheiten 1A und 1B empfangen wird.
  • Wie oben beschrieben, wenn mit der vorliegenden Erfindung bestimmt wird, dass das empfangene Paket sowohl ein Multicast-Paket als auch ein Multicast-Gruppen-Management-Protokoll-Paket ist, wird gemäß dem empfangenen Paket eine Tabelle erzeugt, die eine Korrelation zwischen den Host-Vorrichtungen und den Multicast-Gruppen aufzeigt, und die Paketübertragung für jede Multicast-Gruppe zwischen den Multicast-Router und den Host-Vorrichtungen wird gesteuert gemäß der Tabelle, so dass ein Multicast-Paket nur über Multicast an die erforderlichen Host-Vorrichtungen mit dem existierenden Protokoll und dem Netzwerk-Aufbau übertragen werden kann, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die die effiziente Übertragung von Multicast- sowie Unicast-Daten realisieren kann.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, dass das Multicast-Paket genauso wie das Multicast-Gruppen-Management-Protokoll eine Anfrage ist, wird der Port, der das Paket auf einer Anfrage unter einer Mehrzahl von Ports empfangen hat, in der Tabelle als ein Port registriert, mit dem der Multicast-Router verbunden wird, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die eine Korrelation zwischen einem Port und einem Multicast-Router aktualisieren kann, wie erforderlich gemäß den Inhalten des Pakets.
  • Wenn mit der vorliegenden Erfindung ein Paket auf einer Anfrage empfangen wird, wird die Übertragung des Pakets an alle Ports gesteuert, abgesehen von denjenigen Ports, die das empfangene Paket unter der Mehrzahl von Ports empfangen hat, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die selbstverständlich eine Anfrage an Vorrichtungen unter der Steuerung eines Multicast-Routers übertragen kann.
  • Wenn mit der vorliegenden Erfindung ein Ping periodisch an den Port übertragen wird, mit dem der Multicast-Router unter der Mehrzahl von Ports durch Bezugnahme auf die Tabelle verbunden ist, und wenn es irgendeinen Port gibt, der auf diesen Ping nicht antwortet, wird die Korrelation zwischen dem Port und dem Multicast-Router aus der Tabelle gelöscht, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die das Verschwinden einer Korrelation zwischen einem Multicast-Router und einem Port aktualisieren kann, wie erforderlich gemäß den Inhalten des Pakets.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, dass ein Multicast-Paket genauso wie das Multicast-Gruppen-Management-Protokoll ein Bericht ist, wird der Port, der das Paket auf einem Bericht unter der Mehrzahl von Ports in der Tabelle als ein verbindender Port registriert, der benutzt wird, wenn die Host-Vorrichtung, der mit dem Port verbunden ist, ein Mitglied einer beliebigen Multicast-Gruppe sein kann, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die eine Korrelation zwischen einem Port und einer Host-Vorrichtung für jede Multicast-Gruppe aktualisieren kann, wie erforderlich gemäß den Inhalten des Pakets.
  • Wenn mit der vorliegenden Erfindung ein Bericht-Paket empfangen wird, wird das Bericht-Paket so gesteuert, dass dieses Paket nur an den Port übertragen wird, mit dem der Multicast-Router verbunden ist, durch Bezugnahme auf die Tabelle, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die garantiert einen Bericht von einer Host-Vorrichtung an einen Muticast-Router übertragen kann.
  • Wenn mit der vorliegenden Erfindung bestimmt wird, dass ein Multicast-Paket genauso wie das Multicast-Gruppen-Management-Protokoll Verlassen ist, wird der Port, der das Verlassen-Paket unter der Mehrzahl von Ports empfangen hat, aus der Tabelle gelöscht, wobei der Port als ein verbindender Port betrachtet wird, welcher benutzt wird, wenn die Host-Vorrichtung, die mit dem Port verbunden ist, eine beliebige Multicast-Gruppe verlässt, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die das Verschwinden einer Korrelation zwischen einem Port und einer Host-Vorrichtung für jede Multicast-Gruppe aktualisieren kann, wie erforderlich gemäß den Inhalten des Pakets.
  • Wenn mit der vorliegenden Erfindung ein Verlassen-Paket empfangen wird, wird das Verlassen-Paket so gesteuert, dass dieses Paket nur an den Port übertragen wird, mit dem der Multicast-Router durch Bezugnahme auf die Tabelle verbunden ist, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die garantiert die Verlassen-Nachricht von einer Host-Vorrichtung an einen Multicast-Router übertragen kann.
  • Wenn mit der vorliegenden Erfindung ein Verlassen-Paket empfangen wird, wird das Verlassen-Paket so gesteuert, dass dieses Paket an alle Ports übertragen wird, abgesehen von demjenigen Port, der das Verlassen-Paket unter der Mehrzahl von Ports empfangen hat, so dass der Bedarf nach Verarbeitung des Suchens eines Ports, mit dem der Multicast-Router verbunden ist, eliminiert wird, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die eine Verarbeitung des Verlassens mit niedriger Geschwindigkeit schneller machen kann, durch Einschränkung der Verarbeitungslast zum Zeitpunkt des Verlassensbetriebs.
  • Wenn mit der vorliegenden Erfindung ein Paket auf einer gruppenspezifischen Anfrage zur Überprüfung, dass es keine Host-Vorrichtung gibt, die ein Mitglied einer Multicast-Gruppe ist, empfangen wird, wird das Paket auf einer gruppenspezifischen Anfrage so gesteuert, dass dieses Paket, durch Bezugnahme auf die Tabelle, an alle Ports übertragen wird, mit denen ein Multicast-Router verbunden ist, abgesehen von demjenigen Port, der mit der Host-Vorrichtung dazu verbunden ist, wobei die Host-Vorrichtung ein Mitglied einer Multicast-Gruppe gewesen ist genauso wie derjenige Port, der das Paket auf einer gruppenspezifischen Anfrage empfangen hat, so dass die gruppenspezifische Anfrage nicht über Broadcast gesendet werden muss, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die effizient überprüfen kann, dass es keine Host-Vorrichtung gibt, die ein Mitglied einer Multicast-Gruppe gewesen ist.
  • Wenn mit der vorliegenden Erfindung ein Paket auf einer gruppenspezifischen Anfrage empfangen wird, wird das Paket auf einer gruppenspezifischen Anfrage so gesteuert, dass dieses Paket an alle Ports übertragen wird, abgesehen von demjenigen Port, der das Paket auf einer gruppenspezifischen Anfrage unter der Mehrzahl von Ports empfangen hat, so dass der Bedarf nach Verarbeitung des Suchens eines Ports, mit dem der Multicast-Router verbunden ist, eliminiert wird, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die die Verarbeitung der Übertragung der gruppenspezifischen Anfrage schneller machen kann, durch Einschränkung einer Verarbeitungslast zum Zeitpunkt des Betriebs der gruppenspezifischen Anfrage.
  • Wenn es mit der vorliegenden Erfindung irgendeinen Port gibt, von dem ein Bericht nicht innerhalb einer spezifischen Zeitspanne beantwortet wird, nachdem das Paket auf einer Anfrage empfangen wurde, wird die Korrelation zwischen dem Port und der Host-Vorrichtung aus der Tabelle gelöscht, so dass es möglich ist, die Information, die nicht mit der Multicast-Paketübertragung wie erforderlich zu tun hat, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die die Verarbeitung effizient ausführen kann.
  • Mit der vorliegenden Erfindung wird ein Aktualisierungsbetrieb der Tabelle unter der Steuerung durch die externe Vorrichtung ausgeführt, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die eine Last der Kommunikationssteuereinheit an sich einschränken kann.
  • Wenn mit der vorliegenden Erfindung durch einen Port, der mit dem Multicast-Router verbunden ist, empfangen wird, und wenn das empfangene Paket ein Multicast-Paket ist, wird das empfangene Paket an die Host-Vorrichtung übertragen, die zur Multicast-Gruppe durch Bezugnahme auf die Tabelle gehören, so dass eine Sequenz der Überprüfung des Multicast-Gruppen-Management-Protokolls weggelassen werden kann, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die die Übermittlung eines Multicast-Pakets schneller machen kann.
  • Wenn mit der vorliegenden Erfindung ein Paket empfangen durch einen Port wird, verbunden mit einer Host-Vorrichtung, der zu einer Multicast-Gruppe gehört, welcher in der Tabelle gespeichert ist, und wenn das empfangene Paket ein Multicast-Paket ist, wird das empfangene Paket an den Multicast-Router, der zur Multicast-Gruppe gehört, durch Bezugnahme auf die Tabelle, übertragen, so dass eine Sequenz der Überprüfung der Multicast-Gruppen-Protokolls weggelassen werden kann, und mit diesem Merkmal ist es möglich eine Kommunikationssteuereinheit zu erhalten, die die Übermittlung eines Multicast-Pakets schneller machen kann.
  • Wenn mit der vorliegenden Erfindung ein Paket durch einen Port, mit dem der Router verbunden ist, empfangen wird, und wenn das empfangene Paket ein Multicast-Paket ist, wird das empfangene Paket an den Multicast-Router durch Bezugnahme auf die Tabelle übertragen, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die den Betrieb eines Multicast-Routing-Protokolls auf dem Netzwerk, das eine Vielzahl von Multicast-Routern und eine Vielzahl von Schalt-Hubs umfasst, garantieren kann.
  • Wenn mit der vorliegenden Erfindung ein Multicast-Paket genauso wie das Multicast-Gruppen-Management-Protokoll eine Anfrage ist, um eine Host-Vorrichtung zu fragen, ein Mitglied einer Multicast-Gruppe zu werden, wird nur ein erster Bericht in jeder Multicast-Gruppe unter den Berichten übertragen, die alle einen Wunsch haben ein Mitglied einer Multicast-Gruppe zu sein, die durch jede der Ports empfangen wird, an einen entsprechenden Port, mit dem der Multicast-Router verbunden ist, durch Bezugnahme auf die Tabelle, während der spezifischen Zeitspanne, die innerhalb der Anfrage gesetzt ist, und die folgenden Berichte werden verworfen, nachdem die spezifische Zeitspanne verstrichen ist, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die die Wiederholung der Übertragung eines Berichts an einen Multicast-Router vermeiden kann, sogar auf einem Netzwerk, in den das Subnetz eine große Anzahl von Schalt-Hubs und Host-Vorrichtungen, die die Aufnahme von Multicast-Daten wünschen, umfasst, und welche verbunden sind mit einer großen Anzahl von Ports von jeder der Schalt-Hubs.
  • Wenn mit der vorliegenden Erfindung sogar bestimmt wird, dass das empfangene Paket sowohl ein Multicast-Paket als auch ein Multicast-Gruppen-Management-Protokoll-Paket ist, aber wenn das empfangene Paket nicht zumindest einem Typ einer Anfrage entspricht, eine Host-Vorrichtung danach zu fragen, ein Mitglied einer Multicast-Gruppe zu werden, eines Berichts, dass eine Host-Vorrichtung wünscht ein Mitglied einer Multicast-Gruppe zu sein, und eines Verlassens, anzeigend, dass eine Host-Vorrichtung eine Multicast-Gruppe zu verlassen wünscht, wird das empfangene Paket an die gesamte Mehrzahl von Ports übertragen, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die die Bestimmung zu jeder Vorrichtung verlassen kann als ein Zielort, an den das Paket übertragen wird, wenn nicht bestimmt werden kann, welchem Typ ein Multicast-Paket entspricht.
  • Wenn mit der vorliegenden Erfindung sogar bestimmt wird, dass das empfangene Paket sowohl ein Multicast-Paket als auch ein Multicast-Gruppen-Management-Protokoll-Paket ist, aber wenn das empfangene Paket nicht zumindest einem Typ einer Anfrage entspricht, die eine Host-Vorrichtung danach fragt ein Mitglied einer Multicast-Gruppe zu werden, einem Bericht, dass eine Host-Vorrichtung wünscht ein Mitglied einer Multicast-Gruppe zu sein, und eines Verlassens, anzeigend, dass eine Host-Vorrichtung eine Multicast-Gruppe zu verlassen wünscht, wird das empfangene Paket verworfen, so dass es möglich ist eine Kommunikationssteuereinheit zu erhalten, die einen unklaren Typ des Multicast-Pakets aus einem Netzwerk entfernen kann und die Effizienz der herkömmlichen Multicast-Paketübertragung steigern kann.
  • Mit der vorliegenden Erfindung gibt es Schritte der Bestimmung der Inhalte eines empfangenen Pakets und der Erzeugung einer Tabelle, die eine Korrelation zwischen den Host-Vorrichtungen und Multicast-Gruppen zur Steuerung eines Wegs eines Multicast-Pakets gemäß dem empfangenen Paket anzeigt, wenn bestimmt wird, dass das empfangene Paket sowohl ein Multicast-Paket als auch ein Multicast-Gruppen-Management-Protkoll-Paket ist, so dass es möglich ist ein Kommunikationssteuerverfahren zu erhalten, das auf ein Multicast unterstützendes LAN angewendet wird, die Bedingungen aufrechterhalten kann zur Steuerung der Multicast-Übertragung eines Multicast-Pakets nur an die erforderlichen Host-Vorrichtungen mit dem existierenden Protokoll und dem Netzwerk-Aufbau innerhalb des Pakets.
  • Mit der vorliegenden Erfindung gibt es auch einen Schritt der Übertragung eines Pakets für jede Multicast-Gruppe zwischen dem Multicast-Router und Host-Vorrichtungen gemäß der Tabelle, die eine Korrelation zwischen Host-Vorrichtungen und Multicast-Gruppen anzeigt, wenn ein Multicast-Paket empfangen wird von einem Multicast-Router, so dass ein Multicast-Paket über Multicast nur an die erforderlichen Host-Vorrichtungen mit dem existierenden Protokoll und dem Netzwerk-Aufbau übertragen werden kann, und mit diesem Merkmal ist es möglich ein Kommunikationssteuerverfahren zu erhalten, das auf ein Multicast unterstützendes LAN angewendet werden kann, das die effiziente Übertragung von Multicast- genauso wie Unicast-Daten realisieren kann.
  • Diese Anmeldung basiert auf der Japanischen Patentanmeldung Nr. HEI 10-170339, die beim Japanischen Patentamt am 17. Juni 1998 eingereicht und unter der Nr. JP-2000004251 veröffentlicht wurde.

Claims (23)

  1. Eine Kommunikationssteuereinheit (1A, 1B), die sowohl mit einem oder einer Mehrzahl von Multicast-Router(n) (11, 12) als auch mit einer Mehrzahl von Host-Vorrichtungen (21 bis 26) verbunden ist zur Steuerung der Paketübertragungen zwischen dem Multicast-Router oder der Mehrzahl von Multicast-Routern (11, 12) und der Mehrzahl von Host-Vorrichtungen (21 bis 26), wobei die Kommunikationssteuereinheit umfasst: eine Paketbestimmungseinheit (201), die angepasst ist zur Bestimmung des Inhalts eines empfangenen Pakets; eine Tabellenerzeugungseinheit (205, 208), die angepasst ist zur Erzeugung einer Tabelle (206), die einen Zusammenhang zwischen einem Port der Kommunikationssteuereinheit (1A, 1B) und einer Multicast-Adresse jeder Multicast-Gruppe gemäß dem empfangenen Paket erfasst, wenn durch die Paketbestimmungseinheit (4) bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß einem Gruppen-Management-Protokoll ist, wobei das Multicast-Paket an den Port zu senden ist und der Port über die Kommunikationssteuereinheit (1A, 1B) indirekt mit dem Multicast-Router verbunden ist; eine Steuereinheit (202), die angepasst ist zur Steuerung der Paketübertragung für jede Multicast-Gruppe zwischen dem Multicast-Router (11, 12) und Host-Vorrichtungen (21 bis 26) gemäß der Tabelle, die durch die Tabellenerzeugungseinheit (205, 208) erzeugt wurde; und gekennzeichnet durch eine Pingübertragungseinheit (112), welche angepasst ist zur periodischen Übertragung eines Pings zum Port, mit dem der Multicast-Router (11, 12) unter der Mehrzahl von Ports verbunden ist, durch Bezugnahme auf die Tabelle; und eine Entfernungseinheit (208, 210), die angepasst ist zur Entfernung des Zusammenhangs zwischen dem Port und dem Multicast-Router aus der Tabelle (209), wenn es irgendeinen Port gibt, der auf den durch die Pingübertragungseinheit übertragenen Ping nicht antwortet.
  2. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Tabellenerzeugungseinheit (205, 208) angepasst ist, wenn bestimmt wird, dass das Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll eine Anfrage an eine Host-Vorrichtung ist, ein Mitglied einer Multicast-Gruppe zu werden, zur Registrierung eines Ports unter einer Mehrzahl von Ports aus der Tabelle (209), der das Paket bei einer Anfrage empfangen hat, als ein Port, mit dem der Multicast-Router (11, 12) verbunden ist.
  3. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, wenn ein Paket bei einer Anfrage an eine Host-Vorrichtung, ein Mitglied einer Multicast-Gruppe zu werden, empfangen wird, zur Steuerung der Übertragung des Pakets an alle Ports außer dem Port unter der Mehrzahl von Ports, der das betreffende Paket empfangen hat.
  4. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Tabellenerzeugungseinheit (205, 208) angepasst ist, wenn bestimmt wird, dass das Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll ein Bericht ist, dass eine Host-Vorrichtung (21 bis 26) ein Mitglied einer Multicast-Gruppe zu werden wünscht, zur Registrierung eines Ports unter der Mehrzahl von Ports aus der Tabelle (206), der das Paket bei einem Bericht empfangen hat, als ein verbindender Port, der benutzt wird, wenn die mit dem Port verbundene Host-Vorrichtung (21 bis 26) ein Mitglied einer beliebigen Multicast-Gruppe sein soll.
  5. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, wenn ein Paket bei einem Bericht, dass eine Host-Vorrichtung (21 bis 26) ein Mitglied einer Multicast-Gruppe zu werden wünscht, empfangen wird, zur Steuerung der Übertragung des Pakets bei dem Bericht nur an den Port, mit dem der Multicast-Router (11, 12) verbunden ist, durch Bezugnahme auf die Tabelle (209).
  6. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Tabellenerzeugungseinheit (205, 208) angepasst ist, wenn bestimmt wird, dass das Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll ein Verlassen ist, das anzeigt, dass eine Host-Vorrichtung (21 bis 26) eine Multicast-Gruppe zu verlassen wünscht, zur Entfernung eines Ports unter einer Mehrzahl von Ports aus der Tabelle (206), welcher das Paket bei Verlassen empfangen hat und welcher als ein verbindender Port angesehen wird, der benutzt wird, wenn die mit dem Port verbundene Host-Vorrichtung (21 bis 26) eine beliebige Multicast-Gruppe verlässt.
  7. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, wenn ein Paket bei Verlassen empfangen wird, welches anzeigt, dass eine Host-Vorrichtung (21 bis 26) eine Multicast-Gruppe zu verlassen wünscht, zur Steuerung der Übertragung des Pakets bei Verlassen nur an den Port, mit dem der Multicast-Router (11, 12) verbunden ist, durch Bezugnahme auf die Tabelle (206).
  8. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, wenn ein Paket bei Verlassen, welches anzeigt, dass eine Host-Vorrichtung eine Multicast-Gruppe zu verlassen wünscht, empfangen wird, zur Steuerung der Übertragung des Pakets bei Verlassen an alle Ports, außer dem Port, der das Paket bei Verlassen unter der Mehrzahl von Ports empfangen hat.
  9. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, wenn ein Paket bei einer gruppenspezifischen Anfrage zur Überprüfung, dass es keine Host-Vorrichtung gibt, die ein Mitglied einer Multicast-Gruppe ist, empfangen wird, zur Steuerung der Übertragung des Pakets bei einer gruppenspezifischen Anfrage an alle Ports, mit denen ein Multicast-Router (11, 12) verbunden ist, durch Bezugnahme auf die Tabelle (209), außer dem Port, über den die Host-Vorrichtung (21 bis 26) verbunden ist, die ein Mitglied einer Multicast-Gruppe gewesen ist, und dem Port, der das Paket bei einer gruppenspezifischen Anfrage empfangen hat.
  10. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, wenn ein Paket bei einer gruppenspezifischen Anfrage angepasst ist zur Überprüfung, dass es keine Host-Vorrichtung gibt, die ein Mitglied irgendeiner Multicast-Gruppe ist, empfangen wird, zur Steuerung der Übertragung des Pakets bei einer gruppenspezifischen Anfrage an alle Ports, außer dem Port unter der Mehrzahl von Ports, welcher das Paket bei einer gruppenspezifischen Anfrage empfangen hat.
  11. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Tabellenerzeugungseinheit (205, 208) angepasst ist, wenn es irgend einen Port gibt, von dem ein Bericht, der einen Wunsch ein Mitglied einer Multicast-Gruppe zu werden, anzeigt, innerhalb einer spezifischen Zeitspanne nicht beantwortet wird, nachdem das Paket bei einer Anfrage an eine Host-Vorrichtung (21 bis 26), ein Mitglied einer Multicast-Gruppe zu werden, empfangen wird, zur Entfernung eines Zusammenhangs zwischen dem Port und der Host-Vorrichtung (21 bis 26) aus der Tabelle (206).
  12. Die Kommunikationssteuereinheit (1A, 1B) nach Anspruch 1, mit einer externen Vorrichtung, die angepasst ist, zur unabhängigen Aktualisierung der damit verbundenen Tabelle (206, 209), um eine Aktualisierungsoperation der Tabelle (206, 209) unter der Kontrolle der externen Vorrichtung auszuführen.
  13. Die Kommunikationssteuereinheit nach Anspruch 1, die ferner eine Multicast-Bestimmungseinheit (201, 203) umfasst, die angepasst ist, wenn ein Paket durch einen mit dem Multicast-Router verbundenen Port empfangen wird, zu bestimmen, ob das empfangene Paket ein Multicast-Paket ist oder nicht; und eine Multicast-Übertragungseinheit (105), die angepasst ist, wenn durch die Multicast-Bestimmungseinheit (201, 203) bestimmt wird, dass das empfangene Paket ein Multicast-Paket ist, zur Übertragung des empfangenen Pakets an die Host-Vorrichtungen (21 bis 26), die zu der Multicast-Gruppe gehören, durch Bezugnahme auf die Tabelle.
  14. Die Kommunikationssteuereinheit nach Anspruch 1, die ferner eine Multicast-Bestimmungseinheit (201, 203) umfasst, die angepasst ist, wenn ein Paket durch einen Port empfangen wird, der mit einer zu einer Multicast-Gruppe, welche in der Tabelle (206) gespeichert ist, gehörenden Host-Vorrichtung (21 bis 26) verbunden ist, zu bestimmen, ob das empfangene Paket ein Multicast-Paket ist oder nicht; und eine Multicast-Übertragungseinheit (105), die angepasst ist, wenn durch die Multicast-Bestimmungseinheit (201, 203) bestimmt wird, dass das empfangene Paket ein Multicast-Paket ist, das empfangene Paket an die Multicast-Router (11, 12) zu übertragen, die zu der Multicast-Gruppe gehören, durch Bezugnahme auf die Tabelle (206).
  15. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Mehrzahl von Ports durch einen oder eine Mehrzahl von Routern, außer einem Multicast-Router, verbunden ist und wobei ein Zusammenhang zwischen einem oder einer Mehrzahl von Routern und Ports in der Tabelle (209) registriert ist; die Kommunikationssteuereinheit ferner eine Multicast-Bestimmungseinheit umfasst, welche angepasst ist, wenn ein Paket durch einen mit dem Router verbundenen Port empfangen wird, zu bestimmen, ob das empfangene Paket ein Multicast-Paket ist oder nicht; und eine Multicast-Übertragungseinheit (201, 203), die angepasst ist, wenn durch die Multicast-Bestimmungseinheit bestimmt wird, dass das empfangene Paket ein Multicast-Paket ist, zur Übertragung des empfangenen Pakets an den Multicast-Router, durch Bezugnahme auf die Tabelle (209).
  16. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Kommunikationssteuereinheit mit einem Netzwerk verbunden ist, in dem ein Subnetz eine große Anzahl von Schalt-Netzknoten (105) umfasst, wobei Host-Vorrichtungen (21 bis 26), die den Empfang von Multicast-Daten wünschen, mit einer großen Anzahl von Ports jedes Schalt-Netzknotens verbunden sind; und die Kommunikationssteuereinheit ferner eine Mess-Einheit (110) umfasst, die angepasst ist, wenn das Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll eine Anfrage an eine Host-Vorrichtung (21 bis 26) ist, ein Mitglied einer Multicast-Gruppe zu werden, zur Messung einer spezifischen Zeitspanne, die innerhalb der Anfrage vorgegebenen ist; und eine Übertragungs- /Verwerfungs-Steuereinheit, die angepasst ist, nur einen ersten Bericht in jeder Multicast-Gruppe unter den Berichten, die jeweils einen Wunsch haben, ein Mitglied einer Multicast-Gruppe zu werden, die durch jede der Ports empfangen wird, an einen entsprechenden Port zu übertragen, mit dem der Multicast-Router verbunden ist, durch Bezugnahme auf die Tabelle (209), während der spezifischen Zeitspanne, die durch die Mess-Einheit (110) gemessen wird, und um die folgenden Berichte zu verwerfen, nachdem die durch die Mess-Einheit (110) gemessene, spezifische Zeitspanne verstrichen ist.
  17. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, sogar wenn bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll ist, und falls das empfangene Paket nicht zumindest einer jeglichen Art von Anfrage an eine Host-Vorrichtung (21 bis 26), ein Mitglied einer Multicast-Gruppe zu werden, entspricht, und/oder einem Bericht, dass eine Host-Vorrichtung (21 bis 26) wünscht ein Mitglied einer Multicast-Gruppe zu sein, und/oder eines Verlassens, das anzeigt, dass eine Host-Vorrichtung (21 bis 26) wünscht eine Multicast-Gruppe zu verlassen, zur Übertragung des empfangenen Pakets an die Mehrzahl aller Ports.
  18. Die Kommunikationssteuereinheit nach Anspruch 1, wobei die Steuereinheit (202) angepasst ist, sogar wenn bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß dem Multicast-Gruppen-Management-Protokoll ist, und falls das empfangene Paket nicht zumindest einer jeglichen Art von Anfrage an eine Host-Vorrichtung (21 bis 26), ein Mitglied einer Multicast-Gruppe zu werden, entspricht, und/oder einem Bericht, dass eine Host-Vorrichtung (21 bis 26) ein Mitglied einer Multicast-Gruppe zu sein wünscht, und/oder eines Verlassens, das anzeigt, dass eine Host-Vorrichtung (21 bis 26) eine Multicast-Gruppe zu verlassen wünscht, zum Verwerfen des empfangenen Pakets.
  19. Die Kommunikationssteuereinheit nach Anspruch 1, wobei, wenn eine Kommunikationssteuereinheit (1A, 1B) mit der Mehrzahl von Multicast-Routern (11, 12) verbunden ist, die Tabelle (206) ferner einen Zusammenhang zwischen einem anderen Port der Kommunikationssteuereinheit (1A, 1B) und einer Multicast-Adresse jeder Multicast-Gruppe enthält und der andere Port direkt mit einem anderen Multicast-Router (11, 12) verbunden ist.
  20. Die Kommunikationssteuereinheit nach Anspruch 1, wobei der Port über eine andere Kommunikationssteuereinheit (1A, 1B) mit dem Multicast-Router (11, 12) verbunden ist.
  21. Ein Verfahren zur Kommunikationssteuerung, das bei einem LAN angewendet wird, welche Multicast unterstützt, um Paketübertragung durchzuführen, indem eine Kommunikationssteuereinheit (1A, 1B) benutzt wird, die sowohl mit einem oder einer Mehrzahl von Multicast-Router(n) (11, 12) als auch mit einer Mehrzahl von Host-Vorrichtungen (21 bis 26) verbunden ist, wobei das Verfahren umfasst: einen ersten Schritt der Bestimmung des Inhalts eines empfangenen Pakets; einen zweiten Schritt der Erzeugung einer Tabelle (206), welche einen Zusammenhang zwischen einem Port der Kommunikationssteuereinheit (1A, 1B) und einer Multicast-Adresse jeder Multicast-Gruppe anzeigt, zur Steuerung eines Weges eines Multicast-Pakets gemäß dem empfangenen Paket, wobei das Paket zum Port zu senden ist und der Port über die Kommunikationssteuereinheit mit dem Multicast-Router (11, 12) indirekt verbunden wird, wenn im ersten Schritt bestimmt wird, dass das empfangene Paket ein Multicast-Paket gemäß einem Multicast-Gruppen-Management-Protokoll ist; und einen dritten Schritt der Übertragung eines Paketes für jede Multicast-Gruppe zwischen dem Multicast-Router und Host-Vorrichtungen gemäß der Tabelle (206, 209), die im zweiten Schritt erzeugt wurde, wenn ein Multicast-Paket vom Multicast-Router (11, 12) empfangen wird; gekennzeichnet durch einen vierten Schritt der periodischen Übertragung eines Pings an den Port, mit dem der Multicast-Router (11, 12) unter der Mehrzahl von Ports verbunden ist, durch Bezugnahme auf die Tabelle (209); und einen fünften Schritt der Entfernung des Zusammenhangs zwischen dem Port und dem Multicast-Router aus der Tabelle (209), wenn es irgendeinen Port gibt, welcher auf den Ping nicht antwortet, der im vierten Schritt übertragen wurde.
  22. Das Verfahren zur Kommunikationssteuerung nach Anspruch 21, wobei, wenn eine Kommunikationssteuereinheit (1A, 1B) mit der Mehrzahl von Multicast-Routern (11, 12) verbunden ist, die Tabelle (206) ferner einen Zusammenhang zwischen einem anderen Port der Kommunikationssteuereinheit (1A, 1B) und einer Multicast-Adresse jeder Multicast-Gruppe enthält und der andere Port direkt mit einem anderen Multicast-Router (11, 12) verbunden wird.
  23. Das Verfahren zur Kommunikationssteuerung nach Anspruch 21, wobei der Port über eine andere Kommunikationssteuereinheit (1A, 1B) mit dem Multicast-Router (11, 12) verbunden wird.
DE69835809T 1998-06-17 1998-10-13 Kommunikationssteuereinheit und Kommunikationssteuerungsverfahren angewendet für ein Mehrfachsende-unterstützendes LAN Expired - Lifetime DE69835809T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP17033998A JP4080599B2 (ja) 1998-06-17 1998-06-17 通信制御装置およびマルチキャスト対応lanに適用される通信制御方法
JP17033998 1998-06-17

Publications (2)

Publication Number Publication Date
DE69835809D1 DE69835809D1 (de) 2006-10-19
DE69835809T2 true DE69835809T2 (de) 2007-03-15

Family

ID=15903102

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69835809T Expired - Lifetime DE69835809T2 (de) 1998-06-17 1998-10-13 Kommunikationssteuereinheit und Kommunikationssteuerungsverfahren angewendet für ein Mehrfachsende-unterstützendes LAN

Country Status (4)

Country Link
US (8) US6457059B1 (de)
EP (1) EP0967753B1 (de)
JP (1) JP4080599B2 (de)
DE (1) DE69835809T2 (de)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4080599B2 (ja) * 1998-06-17 2008-04-23 富士通株式会社 通信制御装置およびマルチキャスト対応lanに適用される通信制御方法
US6785274B2 (en) * 1998-10-07 2004-08-31 Cisco Technology, Inc. Efficient network multicast switching apparatus and methods
US6574194B1 (en) * 1998-12-18 2003-06-03 Cypress Semiconductor Corporation Architecture of data communications switching system and associated method
US7974192B2 (en) * 1999-10-13 2011-07-05 Avaya Inc. Multicast switching in a distributed communication system
US7002955B1 (en) * 2000-03-06 2006-02-21 Advanced Micro Devices, Inc. Selective address table aging in a network switch based on application state determined from a received data packet
US7225243B1 (en) * 2000-03-14 2007-05-29 Adaptec, Inc. Device discovery methods and systems implementing the same
WO2002003614A2 (en) * 2000-06-29 2002-01-10 Cachestream Corporation Virtual multicasting
US8301137B1 (en) * 2000-07-31 2012-10-30 Interdigital Patent Corporation Method and apparatus for wireless router multicast
US7310335B1 (en) 2000-09-06 2007-12-18 Nokia Networks Multicast routing in ad-hoc networks
US6963573B1 (en) * 2000-09-13 2005-11-08 Nortel Networks Limited System, device, and method for receiver access control in a multicast communication system
US7870183B1 (en) * 2000-10-25 2011-01-11 International Business Machines Corporation Multicast enabled mail
US7007100B1 (en) * 2000-12-20 2006-02-28 Nortel Networks Limited Method for synchronization of multicast routing table changes with a plurality of multicast routing protocols
US7433942B2 (en) * 2001-02-27 2008-10-07 Intel Corporation Network management
EP1364500B1 (de) * 2001-03-02 2005-11-30 Alcatel Internetworking, Inc. Verfahren und vorrichtung zum klassifizieren von abfrageknoten
KR20020023100A (ko) * 2001-05-28 2002-03-28 박현제 가상 멀티캐스트 네트워크 구축을 위한 시스템
US7089324B1 (en) * 2001-06-14 2006-08-08 Gateway Inc. Dynamic internet gateway service
US7302700B2 (en) 2001-09-28 2007-11-27 Juniper Networks, Inc. Method and apparatus for implementing a layer 3/layer 7 firewall in an L2 device
JP3914036B2 (ja) 2001-11-19 2007-05-16 富士通株式会社 Pon通信の親機及び子機
EP1333693A1 (de) * 2002-02-04 2003-08-06 Koninklijke KPN N.V. Verfahren und System zur Nachrichtenübertragung an Endgerätegruppen
TW569575B (en) * 2002-04-30 2004-01-01 Realtek Semiconductor Corp Transmission setup method and device for multicast packet
US7089323B2 (en) * 2002-06-21 2006-08-08 Microsoft Corporation Method for multicasting a message on a computer network
JP4025593B2 (ja) * 2002-07-11 2007-12-19 富士通株式会社 放送型通信データ配送装置および放送型通信システム
US7936752B2 (en) 2002-07-31 2011-05-03 Cisco Technology, Inc. Source specific multicast group to source mapping
DE10234939A1 (de) * 2002-07-31 2004-02-19 Siemens Ag Verfahren, Kommunikationsanordnung und Kommunikationseinrichtung zum Übermitteln von Rundsende-Informationen über ein Kommunikationsnetz
US8931085B2 (en) 2002-08-16 2015-01-06 Thomson Licensing Download optimization in the presence of multicast data
EP1404053A1 (de) * 2002-09-25 2004-03-31 Thomson Multimedia Broadband Belgium Verfahren zur Leitweglenkung von Datenpaketen, und Vorrichtungen zur Implementierung dieses Verfahrens
JP3800158B2 (ja) * 2002-09-27 2006-07-26 ブラザー工業株式会社 データ送信システム、端末装置、及びプログラム
CN100341305C (zh) 2002-11-26 2007-10-03 华为技术有限公司 基于802.1x协议的组播控制方法
US7359939B2 (en) * 2002-12-06 2008-04-15 Alcatel Canada, Inc. Fast service restoration for lost IGMP leave requests
DE602004003025T2 (de) 2003-01-16 2007-05-24 Sony United Kingdom Ltd., Brooklands Video-/audionetzwerk
GB0301033D0 (en) * 2003-01-16 2003-02-19 Sony Uk Ltd Networks and methods and devices therefor
US7590114B1 (en) * 2003-03-24 2009-09-15 Marvell International Ltd Efficient IP multicast bridging in ethernet switches
JP4141304B2 (ja) 2003-03-27 2008-08-27 富士通株式会社 マルチキャスト通信ネットワークにおける通信方法、受信端末、l2スイッチおよびl3スイッチ
JP3883133B2 (ja) 2003-03-31 2007-02-21 富士通株式会社 通信システム及び通信装置
IL156727A0 (en) * 2003-07-01 2004-02-08 Method and apparatus for assignment of computer hardware address in local area network
EP1545072A1 (de) * 2003-12-19 2005-06-22 Alcatel Border router für ein Telekommunikationsnetzwerk
US7716363B1 (en) * 2004-02-10 2010-05-11 Cisco Technology, Inc. Method and apparatus of providing zero configuration single source multicasting reporting
FR2866498A1 (fr) * 2004-02-17 2005-08-19 Thomson Licensing Sa Methode de transmission d'un flux multipoint dans un reseau local et dispositif de connexion implementant la methode
CN100454888C (zh) * 2004-03-06 2009-01-21 鸿富锦精密工业(深圳)有限公司 组播流量控制管理方法
JP4401864B2 (ja) * 2004-05-17 2010-01-20 パナソニック株式会社 パケット生成方法、通信方法、パケット処理方法及びデータ構造
TWI271648B (en) * 2004-12-24 2007-01-21 Realtek Semiconductor Corp Method for multicast packet forwarding in a switch
US20060159091A1 (en) * 2005-01-19 2006-07-20 Arjen Boers Active multicast information protocol
WO2006081454A2 (en) 2005-01-26 2006-08-03 Internet Broadcasting Corporation Layered multicast and fair bandwidth allocation and packet prioritization
CN100442706C (zh) * 2005-04-19 2008-12-10 华为技术有限公司 一种使维护节点标识与媒体访问控制地址对应的方法
CN1881913A (zh) * 2005-06-15 2006-12-20 上海贝尔阿尔卡特股份有限公司 一种网络接入设备中用户接口组播管理方法及其装置
US7944846B1 (en) * 2005-08-18 2011-05-17 Avaya Inc. DVMRP border router for reverse path forwarding validation with external sources
US20070058646A1 (en) * 2005-08-25 2007-03-15 Siemens Aktiengesellschaft Device and method for forwarding multicast traffic in a hybrid device
JP4681472B2 (ja) * 2006-02-24 2011-05-11 富士通株式会社 トポロジ情報収集プログラム、トポロジ情報収集装置およびトポロジ情報収集方法
US7742457B2 (en) 2006-06-29 2010-06-22 Scientific-Atlanta, Llc Systems and methods of configuring a layer-2 switch for multicast filtering
US7649892B2 (en) * 2006-08-30 2010-01-19 Hewlett-Packard Development Company, L.P. Method and system of network communication receive load balancing
US7813286B2 (en) * 2006-08-30 2010-10-12 Hewlett-Packard Development Company, L.P. Method and system of distributing multicast group join request in computer systems operating with teamed communication ports
DE102006047112A1 (de) * 2006-09-27 2008-04-03 T-Mobile International Ag & Co. Kg Verfahren zur Vernetzung einer Mehrzahl von konvergenten Messaging Systemen und entsprechendes Netzsystem
US8458350B2 (en) * 2006-11-03 2013-06-04 Rockwell Automation Technologies, Inc. Control and communications architecture
JP5034558B2 (ja) * 2007-02-28 2012-09-26 日本電気株式会社 Ipマルチキャスト配信装置、コンテンツ配信システム及びそれらに用いるipマルチキャスト配信方法
US20100046516A1 (en) * 2007-06-26 2010-02-25 Media Patents, S.L. Methods and Devices for Managing Multicast Traffic
CN101766000A (zh) * 2007-06-26 2010-06-30 传媒专利有限公司 管理组播组的方法和设备
US8184630B2 (en) * 2007-10-15 2012-05-22 Media Patents, S.L. Method for managing multicast traffic in a data network and network equipment using said method
US8064449B2 (en) * 2007-10-15 2011-11-22 Media Patents, S.L. Methods and apparatus for managing multicast traffic
WO2009056175A1 (en) * 2007-10-30 2009-05-07 Soporte Multivendor S.L. Method for managing multicast traffic between routers communicating by means of a protocol integrating the pim protocol; and router and switch involved in said method
US9031068B2 (en) * 2008-02-01 2015-05-12 Media Patents, S.L. Methods and apparatus for managing multicast traffic through a switch
WO2009095041A1 (en) * 2008-02-01 2009-08-06 Soporte Multivendor S.L. Method for managing multicast traffic through a switch operating in the layer 2 of the osi model, and router and switch involved in said method
WO2009109684A1 (es) * 2008-03-05 2009-09-11 Media Patents, S. L. Procedimiento para monitorizar o gestionar equipos conectados a una red de datos
EP2139159A1 (de) * 2008-06-27 2009-12-30 THOMSON Licensing Verfahren und Vorrichtung zur Verwaltung der Verteilung von Multicast-Inhalten
US20100135298A1 (en) * 2008-12-01 2010-06-03 Electronics And Telecommunications Research Institute Method and system for providing source specific multicast service on ethernet network
BRPI0823351A8 (pt) * 2008-12-19 2015-09-22 Thomson Licensing método e aparelho para aperfeiçoar funcionalidade de multidifusão de comutador de rede
US8189584B2 (en) 2009-07-27 2012-05-29 Media Patents, S. L. Multicast traffic management in a network interface
JP5540679B2 (ja) * 2009-12-10 2014-07-02 株式会社リコー ネットワーク機器、通信制御方法、及びプログラム
US20110149960A1 (en) * 2009-12-17 2011-06-23 Media Patents, S.L. Method and apparatus for filtering multicast packets
CN102714616A (zh) * 2009-12-18 2012-10-03 爱立信(中国)通信有限公司 分组交换网络中的方法和设备
CN102104488B (zh) 2009-12-22 2013-03-13 华为技术有限公司 一种组播报文处理方法及装置
JP5569057B2 (ja) * 2010-03-15 2014-08-13 ヤマハ株式会社 通信システム、スイッチングハブ、およびルータ
US9559855B2 (en) 2010-05-20 2017-01-31 Cisco Technology, Inc. System and method for providing multicast delivery in a network environment
TW201228301A (en) * 2010-12-24 2012-07-01 Accton Technology Corp Multicast routing device, network system, and package transmitting method thereof
US9152580B1 (en) * 2011-10-27 2015-10-06 Marvell International Ltd. Method and apparatus for transferring data between a host and an embedded device
US9363227B2 (en) 2012-08-17 2016-06-07 Cisco Technology, Inc. Multicast source in group address mapping
JP6102214B2 (ja) 2012-11-22 2017-03-29 富士通株式会社 転送プログラム、設定プログラム、送信プログラム、転送装置、設定装置、送信装置、転送方法、設定方法および送信方法
US9210072B2 (en) * 2013-03-08 2015-12-08 Dell Products L.P. Processing of multicast traffic in computer networks
US9143437B1 (en) * 2013-03-15 2015-09-22 Extreme Networks, Inc. Apparatus and method for multicast data packet forwarding
JP6132980B2 (ja) 2013-06-19 2017-05-24 株式会社日立製作所 非集中的な分散型コンピューティング・システム
US9350607B2 (en) * 2013-09-25 2016-05-24 International Business Machines Corporation Scalable network configuration with consistent updates in software defined networks
US9021296B1 (en) 2013-10-18 2015-04-28 Hitachi Data Systems Engineering UK Limited Independent data integrity and redundancy recovery in a storage system
CN105227471B (zh) * 2014-05-29 2018-10-09 新华三技术有限公司 一种evi网络中建立组播转发表项的方法和边缘设备
US10491512B2 (en) * 2015-05-20 2019-11-26 Qualcomm Incorporated Supporting packet query-response transactions at lower layer
US10999188B1 (en) * 2020-01-22 2021-05-04 Gigamon Inc. Tool port aliasing in a network visibility fabric

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07170279A (ja) 1993-12-14 1995-07-04 Nec Eng Ltd Lanブリッジシステムにおけるユーザグループ 設定方式
US5519704A (en) 1994-04-21 1996-05-21 Cisco Systems, Inc. Reliable transport protocol for internetwork routing
US6026095A (en) * 1994-09-27 2000-02-15 3Com Corporation Method and apparatus for controlling latency and jitter in shared CSMA/CD (repeater) environment
US5517494A (en) * 1994-09-30 1996-05-14 Apple Computer, Inc. Method and system of multicast routing for groups with a single transmitter
US5539737A (en) * 1994-12-30 1996-07-23 Advanced Micro Devices, Inc. Programmable disrupt of multicast packets for secure networks
US5553083B1 (en) 1995-01-19 2000-05-16 Starburst Comm Corp Method for quickly and reliably transmitting frames of data over communications links
US5608726A (en) * 1995-04-25 1997-03-04 Cabletron Systems, Inc. Network bridge with multicast forwarding table
US6370142B1 (en) * 1995-07-12 2002-04-09 Nortel Networks Limited Method and apparatus for performing per-port IP multicast pruning
US5818838A (en) 1995-10-12 1998-10-06 3Com Corporation Method and apparatus for transparent intermediate system based filtering on a LAN of multicast packets
JPH09162920A (ja) 1995-12-13 1997-06-20 Hitachi Cable Ltd スイッチングハブ
JP2982727B2 (ja) * 1996-08-15 1999-11-29 日本電気株式会社 認証方法
US6052718A (en) * 1997-01-07 2000-04-18 Sightpath, Inc Replica routing
CN1253641A (zh) * 1997-04-23 2000-05-17 摩托罗拉公司 在一个多点广播网络中用于管理多点广播分组成员的系统、装置与方法
US6331983B1 (en) 1997-05-06 2001-12-18 Enterasys Networks, Inc. Multicast switching
US5959989A (en) * 1997-06-25 1999-09-28 Cisco Technology, Inc. System for efficient multicast distribution in a virtual local area network environment
US5982775A (en) * 1997-08-14 1999-11-09 Tektronix, Inc. Forwarding multicast frames on an ethernet bridge
US6215766B1 (en) * 1998-01-30 2001-04-10 Lucent Technologies Inc. Hierarchical rate control of receivers in a communication system transmitting layered video multicast data with retransmission (LVMR)
US6181697B1 (en) 1998-03-31 2001-01-30 At&T Corp. Method for a unicast endpoint client to access a multicast internet protocol (IP) session and to serve as a redistributor of such session
US6058431A (en) * 1998-04-23 2000-05-02 Lucent Technologies Remote Access Business Unit System and method for network address translation as an external service in the access server of a service provider
JP4080599B2 (ja) * 1998-06-17 2008-04-23 富士通株式会社 通信制御装置およびマルチキャスト対応lanに適用される通信制御方法
US6785274B2 (en) * 1998-10-07 2004-08-31 Cisco Technology, Inc. Efficient network multicast switching apparatus and methods
BRPI0518290A2 (pt) * 2004-11-18 2008-11-11 Shell Int Research processo para a fabricaÇço de um composto alquenil aromÁtico sob baixas condiÇÕes de processo de vapor-para-àleo

Also Published As

Publication number Publication date
US20090135821A1 (en) 2009-05-28
EP0967753A2 (de) 1999-12-29
US20080165773A1 (en) 2008-07-10
US8370512B2 (en) 2013-02-05
JP4080599B2 (ja) 2008-04-23
US7487251B2 (en) 2009-02-03
US8521894B2 (en) 2013-08-27
US20030041171A1 (en) 2003-02-27
US20080165772A1 (en) 2008-07-10
US8364834B2 (en) 2013-01-29
US8516139B2 (en) 2013-08-20
JP2000004251A (ja) 2000-01-07
US20100254384A1 (en) 2010-10-07
US20080159284A1 (en) 2008-07-03
US6457059B1 (en) 2002-09-24
EP0967753A3 (de) 2004-04-07
EP0967753B1 (de) 2006-09-06
DE69835809D1 (de) 2006-10-19
US9088505B2 (en) 2015-07-21
US20130315240A1 (en) 2013-11-28
US8429283B2 (en) 2013-04-23

Similar Documents

Publication Publication Date Title
DE69835809T2 (de) Kommunikationssteuereinheit und Kommunikationssteuerungsverfahren angewendet für ein Mehrfachsende-unterstützendes LAN
DE69727930T2 (de) Zusammenfassung von verbindungen in vermittlungskommunikationsnetzen
DE60030050T2 (de) Vorrichtung und verfahren zur effiziente abgabe von mehrfachdaten im pacs (personal access communications system)
DE69628724T2 (de) Netzknotenvorrichtung und Verbindungsaufbauverfahren zum Aufbauen von Durchgangsverbindungen
DE60030527T2 (de) Rpcu (radio port control unit) und entsprechendes verfahren
DE60103942T2 (de) Lastausgleich in einem Telekommunikationssystem das Mobil IP unterstützt
DE69737643T2 (de) Vorrichtung zur Paketübertragung
DE60028254T2 (de) Steuerungsgerät und -verfahren für paketbasierte kommunikation
DE60133641T2 (de) Kommunikationssystem und verfahren dafür
DE60114649T2 (de) Adressvergabe an mobile stationen
EP0996257A2 (de) Netzwerk mit Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken
DE60018723T2 (de) Adressierungsschema für ein IP basiertes funkzugriffsnetz
DE19639845C1 (de) Lokales Netzwerk mit Sende- und Empfangsvorrichtung
DE60037914T2 (de) Multicasting von Daten in einem mobilen IP-Kommunikationsnetz
DE60133175T2 (de) Kommunikationsnetz
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
EP0831620A2 (de) Lokales Netzwerk mit zur Funkübertragung vorgesehenen Terminals
EP0996258A2 (de) Lokales Netzwerk mit einem Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken und zur Schleifendetektion
DE60019474T2 (de) Leitweglenkungsverfahren in einem Intranetzwerk mit sehr niedriger Bandbreite
EP1854267A1 (de) Verfahren zum einrichten einer kommunikationsbeziehung in zumindest einem kommunikationsnetz
EP1049294B1 (de) Netzwerk mit mehreren Netzwerk-clustern zur drahtlosen Übertragung von Paketen
DE19848341A1 (de) Automatische Konfigurierung eines Brücken-Terminals zur Übertragung von Daten zwischen mehreren Sub-Netzwerken in einem lokalen Netzwerk
EP1266493A1 (de) Verfahren und anordnung zum übertragen eines datenpakets von einer ersten vermittlungseinheit an eine zweite vermittlungseinheit in einem datennetz
DE69921776T2 (de) Mobiles IP mit Dienstqualität für fremdes Netz mit fremdem Agent und mehreren mobilen Knoten
EP1992127B1 (de) Kommunikationssystem, rechner und verfahren zum ermitteln eines zu verwendenden kommunikationsprotokolls in einem kommunikationssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition