DE10252448B4

DE10252448B4 - Verfahren für das Identifizieren von Vorrichtungen, die ein Multicast-Kanalzuweisungsprotokoll (MCAP) auf demselben Netzwerk unterstützen und Multicast-Kommunikationsnetzwerk das dieses verwendet

Info

Publication number: DE10252448B4
Application number: DE10252448A
Authority: DE
Inventors: Jae-hwa Siheung Kim; Il-ju Anyang Na
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2002-03-07
Filing date: 2002-11-12
Publication date: 2007-01-04
Anticipated expiration: 2022-11-13
Also published as: CN1444357A; CN1237753C; KR100433545B1; JP2003273874A; KR20030072878A; JP3720026B2; DE10252448A1; US20050073966A1

Abstract

Verfahren zur Bestimmung, ob ein Multicast-Kanalzuweisungsprotokoll (MCAP) in einem Netz unterstützt wird oder nicht, wobei das Verfahren folgendes umfasst:
(a) eine MCAP-Vorrichtung überträgt eine MCAP-Ankündigungsnachricht an alle Vorrichtungen im selben Netz;
(b) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, überträgt eine Internet-Gruppen-Verwaltungsprotokoll-Abfragenachricht (IGMP-Abfragenachricht) an alle Vorrichtungen im selben Netz; und
(c) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, bestimmt, ob jede der Vorrichtungen im selben Netz das MCAP unterstützt oder nicht, durch die Kanalnummer des Kanals, durch den eine IGMP-Berichtsnachricht von den Vorrichtungen im selben Netz übertragen wurde.

Description

Die vorliegende Erfindung bezieht sich, wenn es auf einem Netzwerk Vorrichtungen, die ein Multicast-Kanalzuweisungsprotokoll (MCAP) unterstützen, und Vorrichtungen, die das MCAP nicht unterstützen, gibt, auf ein Verfahren für eine Bestimmung, ob Vorrichtungen das MCAP unterstützen oder nicht, und auf ein Multicast-Kommunikationsverfahren, das dieses verwendet.
Im Stand der Technik wird bei einem Multicast-Kommunikationsverfahren ein Multicasting, das den Broadcast-Kanal verwendet, unabhängig davon, ob die Vorrichtungen auf demselben Netz, beispielsweise einem IEEE1394-Netz, das MCAP unterstützen oder nicht, durchgeführt. In diesem Fall wird, obwohl Vorrichtungen das MCAP unterstützen, das Übertragungsverfahren unnötigerweise verwendet, und die MCAP-Funktion selbst wird aufgehoben, so dass eine ausgewählte Übertragungsfunktion, die die Kernfunktion der Multicast-Kommunikation darstellt, nicht verwendet werden kann.

FENNER, W.: Internet Group Management Protocol, Version 2. Network Working Group, RFC 2236, November 1997, beschreibt IGMPv2, das von IP-Hosts verwendet wird, um ihre Multicast-Gruppenzugehörigkeiten an Router zu berichten. IGMPv2 erlaubt, die Beendigung einer Gruppenzugehörigkeit schnell an das Routing-Protokoll und/oder an Sub-Netze mit sich stark ändernder Gruppenzugehörigkeit zu berichten.

Um die obigen Probleme zu lösen, besteht eine erste Aufgabe der vorliegenden Erfindung darin, ein Verfahren für die Bestimmung, ob Vorrichtungen auf demselben Netzwerk ein Multicast-Kanalzuweisungsprotokoll (MCAP) unterstützen oder ob sie das nicht tun, zu liefern.

Eine zweite Aufgabe der vorliegenden Erfindung besteht darin, ein Multicast-Kommunikationsverfahren, das das oben beschriebene Verfahren verwendet, zu liefern.

Um die erste Aufgabe der vorliegenden Erfindung zu lösen, wird ein Verfahren für die Bestimmung, ob ein MCAP in einem Netz unterstützt wird oder nicht, geliefert, wobei das Verfahren (a) eine MCAP-Vorrichtung, die eine MCAP-Ankündigungsnachricht an alle Vorrichtungen im selben Netz überträgt, einschließt, (b) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, eine Internet-Gruppen-Verwaltungsprotokoll-Abfragenachricht (IGMP-Abfragenachricht) an alle Vorrichtungen im selben Netz überträgt, und (c) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, durch die Kanalnummer, durch die eine IGMP-Berichtsnachricht von den Vorrichtungen im selben Netz übertragen wurde bestimmt, ob jede der Vorrichtungen im selben Netz das MCAP unterstützt oder nicht.

Um die zweite Aufgabe der vorliegenden Erfindung zu lösen, wird ein Multicast-Kommunikationsverfahren in einem Netz bereitgestellt, wobei das Verfahren (a) eine MCAP-Vorrichtung, die zu einer Multicast-Gruppe gehört, umfasst, die eine MCAP-Ankündigungsnachricht an alle Vorrichtungen im selben Netz überträgt, (b) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, eine IGMP-Abfragenachricht an alle Vorrichtungen im selben Netz überträgt, (c) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, durch die Kanalnummer, durch die eine IGMP-Berichtsnachricht von den Vorrichtungen im selben Netz übertragen wurde, bestimmt, ob jede der Vorrichtungen im selben Netz das MCAP unterstützt oder nicht, und (d) eine Kommunikation mit der entsprechenden Multicast-Adresse unter Verwendung des Multicast-Kanals, wenn die IGMP-Berichtsnachrichten von allen Vorrichtungen, an die die MCAP-Broadcast-Nachricht übertragen wurde, durch den Multicast-Kanal empfangen werden, durchgeführt wird, und eine Kommunikation mit der entsprechenden Multicast-Adresse durch das Verwenden von Broadcast-Kanälen, wenn nur einige der IGMP-Berichtsnachrichten von allen Vorrichtungen durch den Multicast-Kanal empfangen werden, durchgeführt wird.

Die obigen Aufgaben und Vorteile der vorliegenden Erfindung werden durch die detaillierte Beschreibung bevorzugter Ausführungsformen unter Bezug auf die angefügten Zeichnungen deutlicher.
1 ist ein schematisches Diagramm, das ein Unicast-Verfahren, ein Broadcast-Verfahren und ein Multicast-Verfahren zeigt;
2 ist ein schematisches Diagramm, das die Beziehungen zwischen den Schichten im IEEE1394 zeigt;
3 ist ein schematisches Diagramm, das das Multicast-Kommunikationsverfahren des Stands der Technik auf einem IEEE1394-Netz zeigt;
4 ist ein Flussdiagramm, das ein Verfahren für die Bestimmung, ob ein Multicast-Kanalzuweisungsprotokoll (MCAP) unterstützt wird oder nicht, zeigt;
5 ist ein schematisches Diagramm, das das Verfahren der 4 zeigt;
6 ist ein Flussdiagramm, das ein Multicast-Kommunikationsverfahren gemäß der vorliegenden Erfindung zeigt; und
7 ist ein schematisches Diagramm, das das Verfahren der 6 zeigt.
Internet-Übertragungsverfahren können im Hinblick auf die Quelle und das Ziel in Unicast-, Broadcast- und Multicast-Verfahren aufgeteilt werden.
1 ist ein schematisches Diagramm, das ein Unicast-Verfahren, ein Broadcast-Verfahren und ein Multicast-Verfahren zeigt.
Beim Unicast-Übertragungsverfahren überträgt eine Quelle Daten zu einem Ziel. Normale Internetanwendungsprogramme verwenden dieses Unicast-Verfahren. Mittlerweile überträgt im Broadcast-Übertragungsverfahren eine Quelle Daten an alle Ziele auf demselben Subnetzwerk.
Beim Multicast-Übertragungsverfahren übertragen eine oder mehrere Quellen Daten zu einem oder mehreren vorbestimmten Zielen. Das Multicast-Übertragungsverfahren wird bei Internet-Videokonferenz-Anwendungen verwendet.
Wenn dieselben Daten zu einer Vielzahl von Zielen für eine Gruppenkommunikation übertragen werden sollen, so sollten, wenn das Unicast-Übertragungsverfahren verwendet wird, Datenpakete, die übertragen werden sollen, mehrmals an jedes Ziel gesandt werden. Mit dieser redundanten Übertragung derselben Pakete wird die Effizienz des Netzes verschlechtert, und wenn die Anzahl der Ziele stark zunimmt, so wird dieses Problem immer schlimmer.
Mittlerweile kann, wenn eine Multicast-Übertragung unterstützt wird, die Quelle eine Nachricht zu einer Zeit übertragen, und natürlich kann die Verschwendung von Netzresourcen durch die redundante Übertragung von Daten minimiert werden.
Die Multicast-Übertragung unterscheidet sich von der normalen Unicast-Übertragung zuerst durch die Übertragungspakete. Im allgemeinen markiert in einem Internet-Anwendungsprogramm oder bei einem TCP/IP-Protokoll die Quelle der Daten die Internet-Adresse eines Ziels, das die Daten empfangen wird, im Kopfteil des Übertragungspakets und überträgt dann das Paket. Bei einer Multicast-Übertragung wird eine Gruppenadresse, zu der eine Vielzahl von Zielen gehört, statt der Adresse eines Ziels markiert, und dann wird das Paket übertragen.
Die Gruppenadresse für eine Multicast-Übertragung ist eine IP-Adresse der D-Klasse (223.0.0.0-239.255.255.255), die im Gegensatz zu IP-Adressen der A-, B- und C-Klasse die jeweiligen Internet-Hosts überall auf der Welt bezeichnet und die nicht einen tatsächlichen Host bezeichnet. Ein Ziel, das ein Multicast-Paket empfängt, das eine Gruppenadresse aufweist, bestimmt, ob es das Paket empfangen soll oder nicht, durch die Bestimmung, ob das Ziel in der Gruppe des Pakets eingeschlossen ist oder nicht.
Die IP-Multicast-Adressierung ist eine Internet-Norm, die in RFC1112 (Host Extensions for IP Multicasting) spezifiziert ist und die durch viele Hersteller von Workstation-Rechnern (SUN, SGI, DEC, HP etc.) unterstützt wird, und die formal als IP-Adresse der D-Klasse definiert wird.
Der Adressenbereich der D-Klasse erstreckt sich von 224.0.0.1 bis 239.255.255.254. Diese Adressen sind nicht ausschließlich einem vorbestimmten Host zugeordnet, sondern sie werden stattdessen aktiv einer Multicast-Gruppe zugeordnet, was einen Unterschied gegenüber den bisherigen Adressenzuweisungsverfahren darstellt.
Eine Workstation, die die D-Klasse erkennen, das heißt unterstützen, kann, tauscht Information mit anderen aus, indem sie zwei Adressen von Multicast-Gruppen, zu denen die Workstation gehört oder gehören will, zusätzlich zu einer Adresse, die der Workstation ausschließlich zugewiesen ist, verwendet. Ein Internet-Gruppen-Verwaltungsprotokoll (Internet Group Management Protocol, IGMP) spezifiziert ein Verfahren, das einen Host, der eine neue Gruppe bilden will oder der in eine Gruppe eintreten will, verwenden sollte. Somit wird eine ausgebildete Multicast-Gruppe durch eine Sitzungsanzeige (session display, sd) dargestellt, wobei es sich um ein führendes Darstellungsmittel handelt. Mit der sd können Multicast-Gruppen aktuell betrieben und Mitglieder der Gruppe identifiziert werden.
Mittlerweile hat die IEEE1394-Technologie, die ursprünglich als Festplattenschnittstelle von der Firma Apple seit 1986 entwickelt wurde, für eine Home-Netzschnittstellentechnologie der nächsten Generation Aufmerksamkeit erweckt. Später ist mit der Teilnahme von IBM und Sony die Normierung fortgeschritten. 1995 wurde die 1394 Trade Association gegründet, um die IEEE1394 publik zu machen.
1995 wurden die Normspezifikationen für die IEEE1394 formal unter dem Namen IEEE Norm 1394-1995 angenommen. In den Normspezifikationen werden drei Geschwindigkeiten für eine Hochgeschwindigkeitsübertragung, nämlich 100 Mbps, 200 Mbps und 400 Mbps spezifiziert. Es wurde auch die IEEE Norm 1394a-2000 im Jahr 2000 spezifiziert, indem Funktionen zur IEEE Norm 1394-1995 hinzugefügt und ergänzt wurden.
2 ist ein schematisches Diagramm, das die Beziehung zwischen den Schichten in der IEEE1394 zeigt. Die IEEE1394-1995 ist die Norm für Hardware und Software, die aus drei Schichten gebildet wird, die eine physikalische Schicht (physical layer), eine Verbindungsschicht (link layer) und eine Transaktionsschicht (transaction layer) einschließen. Die Funktionen der drei Schichten und die Beziehungen zwischen den Schichten sind in 2 gezeigt. Gewöhnlicherweise führt ein IEEE1394-Adapter Funktionen der physikalischen Schicht und der Verbindungsschicht aus, während ein Host für die Transaktionsschicht und eine Busverwaltungsfunktion verantwortlich ist. Die physikalische Schicht führt gewöhnlicherweise eine beliebige Funktion für das Erhalten einer Zulassung, um einen seriellen Bus zu verwenden, aus, und die Datenverbindungsschicht führt eine Steuerung der Buszyklen durch. Die Transaktionsschicht führt die Grundfunktionen einer Netzwerkvorrichtung aus, das heißt Lesen und Schreiben, und verwaltet die Resourcen, die bei einer gleichzeitigen Übertragung in Bezug auf die Bussteuerfunktion benötigt werden.
Die Schnittstelle der IEEE1394 ist im Grunde eine serielle Schnittstelle, die durch 6 Kupferdrähte gebildet wird, wobei diese zwei Paare von Signalleitungen und ein Paar von Stromleitungen einschließen. Die beiden Paare der Signalleitungen werden in einer Halb-Duplex-Betriebsart verwendet, wobei ein Paar beim Übertragen eines Datensignals verwendet wird, während das andere Paar beim Übertragen eines Zeitsignals für die Datenabtastsynchronisation verwendet wird. Der Grund für die Verwendung des Paars der Zeitsignalleitungen liegt darin, dass eine Belastung vermieden werden soll, um die Last der Verdopplung der Übertragungsgeschwindigkeit zu vermeiden, wenn Daten, die Zeitinformation einschließen, wie bei der Manchester-Kodierung, mit hoher Übertragungsgeschwindigkeit übertragen werden.
Vorrichtungen, die die IEEE1394 unterstützen, werden als Knoten bezeichnet. Das am meisten verwendete physikalische Verbindungsverfahren ist eine Baumstruktur, und eine Busstruktur wird verbreitet als Betriebsverfahren verwendet. Das heißt, zu einer beliebigen Zeit kann nur ein Knoten Daten übertragen, während alle andere Knoten, die mit dem Knoten verbunden sind, Daten empfangen können.
Spezifikationen für das Unterstützen eines IP-Multicast-Verfahrens auf einem IEEE1394 Netz werden durch draft-ieft-ip1394-ipv6 und draft-ietf-ip1394-mcap der Internet Engineering Task Force (IETF), das ein Forschungskomitee unter dem Internet Architecture Board (IAB), das Internet-Normspezifikationen entwickelt, darstellt, und IPv4 wird durch RFC2734 (IPv4 über IEEE1394) definiert. Diese Spezifikationen spezifizieren, dass ein IP-Multicast-Paket entweder unter Verwendung einer asynchronen reihenweisen Übertragungsbetriebsart oder einer gleichzeitigen reihenweisen Übertragungsbetriebsart. Hier wird die zu verwendende Betriebsart gemäß der Eigenschaft einer Dienstanforderung des IP-Pakets bestimmt. Das heißt, das asynchrone reihenweise Verfahren wird für ein Paket, das Best-Effort-Dienste anfordert, verwendet, während das gleichzeitige reihenweise Verfahren für ein Paket, das Dienstgüte (Quality of Service, QoS) anfordert, verwendet wird.
Bei diesen zwei Übertragungsverfahren werden bei der Übertragung Kanalnummern statt Knotennummern verwendet. Verfahren für das Zuweisen und Zurückgeben einer Kanalnummer und das Zuweisen einer Bandbreite werden unter Verwendung eines Multicast-Kanalzuweisungsprotokolls (MCAP) in einer Kanalzuwei sungsverwaltungsvorrichtung (CAM) durchgeführt. Die CAM empfängt eine Anforderung von einer Multicast-Quelle oder einem Gruppenmitglied und weist einen Multicast-Kanal und eine Bandbreite zu. Das Anforderungs/Antwort-Paket, das zu dieser Zeit verwendet wird, verwendet das MCAP-Protokoll.
Das MCAP definiert zwei Verfahren für das Zuweisen von Kanälen. Im ersten Verfahren verwenden alle Knoten (Vorrichtungen, die die IEEE1394 unterstützen), die die IP-Funktion durchführen, einen Übertragungskanal, der im Grunde gemeinsam genutzt wird. Im zweiten Verfahren wird ein anderer Kanal als der Übertragungskanal verwendet.
Im ersten Verfahren kann eine Multicast-Kommunikation ohne zusätzliche Protokolle durchgeführt werden, aber es werden unnötige Pakete empfangen, so dass die Rechenbelastung der Vorrichtungen zunimmt.
Im zweiten Verfahren wird ein Kanal für eine vorbestimmte Multicast-Gruppen-Adresse einer Vorrichtung zugewiesen, die der vorbestimmten Multicast-Gruppe zugehört. Durch eine MCAP-Ankündigungsnachricht (MCAP advertise message) wird allen Vorrichtungen des Netzes die Verbindung zwischen dem zugewiesenen Kanal und der entsprechenden Multicast-Adresse zur Kenntnis gebracht. Alle Knoten des Netzes, die die MCAP-Ankündigungsnachricht empfangen, sollten das entsprechende Multicast-Paket durch den zugewiesenen Kanal übertragen und empfangen.
Wenn alle Vorrichtungen in einem IEEE1394-Netz den Broadcast-Kanal als das erste Verfahren verwenden, verursachen Multicast-Übertragungen kein Problem. Durch die Durchführung des Broadcast-Verfahrens verursachen jedoch unnötige Pakete unvermeidlich eine Rechenbelastung der Vorrichtungen, die nicht in der entsprechenden Multicast-Gruppe enthalten sind.
Wenn alle Vorrichtungen auf dem Netz Vorrichtungen sind, die MCAP unterstützen, die die MCAP-Nachricht interpretieren und dann die Kanäle einstellen, wie beim zweiten Verfahren, so verursachen die Multicast-Übertragungen ebenfalls kein Problem. In diesem Fall kann der Empfang unnötiger Pakete minimiert werden.
Somit besteht kein Problem bei Multicast-Übertragungen, wenn alle Vorrichtungen die MCAP-Funktion nicht unterstützen oder wenn alle Vorrichtungen die MCAP-Funktion unterstützen.
Aktuell unterstützen jedoch nur einige der Knoten des IEEE1394-Netzes das MCAP, so dass Vorrichtungen, die das MCAP unterstützen und Vorrichtungen, die das MCAP nicht unterstützen, gemeinsam im Netz existieren. Somit werden durch das ungünstige Broadcast-Verfahren Multicast-Übertragungen durchgeführt.
3 ist ein schematisches Diagramm, das ein Multicast-Kommunikationsverfahren eines IEEE1394-Netzes des Stands der Technik zeigt.
Das Multicast-Kommunikationsverfahren des Stands der Technik auf einem IEEE1394-Netz verwendet ein Verfahren, bei dem eine Multicast-Nachricht an alle Vorrichtungen durch einen Broadcast-Kanal (Kanal 31) übertragen wird, wie das in (a) der 3 gezeigt ist. In diesem Fall kann das Verfahren so ausgebildet werden, dass alle Vorrichtungen ohne Rücksicht auf die MCAP-Vorrichtungen 302 und 306 und die Nicht-MCAP-Vorrichtungen 304 eine Multicast-Nachricht übertragen.
Wenn jedoch beispielsweise die MCAP-Vorrichtung 306 eine Multicast-Kommunikation durch das Zuweisen eines anderen Kanals, beispielsweise des Kanals 7, wie das in (b) von 3 ge zeigt ist, statt des Broadcast-Kanals durchführt, so tritt ein Problem auf.
Das heißt, wenn die MCAP-Vorrichtung 306 den Kanal 7 einer Multicast-Adresse (beispielsweise 239.255.255.250) zuordnet und eine MCAP-Nachricht überträgt, und die MCAP-Vorrichtung 302, die dies erkennt, eine Multicast-Nachricht, die eine Adresse von 239.255.255.250 aufweist, durch den Kanal 7 überträgt, so kann die Nicht-MCAP-Vorrichtung 304 die Multicast-Nachricht nicht empfangen.
Somit gibt es, wenn Nicht-MCAP-Vorrichtungen, die das MCAP nicht unterstützen und die ein Multicast-Verfahren nur durch einen Broadcast-Kanal durchführen können, und MCAP-Vorrichtungen im selben Netz vorhanden sind, ein Problem bei der Kommunikation zwischen den beiden Typen von Vorrichtungen.
Das heißt, obwohl eine MCAP-Vorrichtung einen anderen Kanal als den Broadcast-Kanal einer vorbestimmten Multicast-Adresse zuordnet und dies allen Vorrichtungen im Netz durch eine MCAP-Ankündigungsnachricht kundtut, können Nicht-MCAP-Vorrichtungen ein Paket, das einen anderen Kanal als den Broadcast-Kanal aufweist, nicht empfangen, da die Nicht-MCAP-Vorrichtungen ausgebildet sind, ein Multicast-Verfahren über einen Broadcast-Kanal auszuführen.
Dies kann zu einem schweren Problem bei einer häuslichen Netzumgebung führen. Damit die häusliche Netzumgebung in der Zukunft sicher eingeführt werden kann, werden alle Haushaltsgeräte, die Mobiltelefone, Internet-Telefone, digitale Anrufbeantworter, Funkrufempfänger, Kühlschränke und Toaster als auch alle vorstellbaren Computerprodukte, die Personalcomputer, Notebookcomputer, Palmtopcomputer, TV-Set-Top-Boxes (STP), Videospielgeräte, Drucker, Modems und Scanner einschließen, miteinander verbunden.
Die Vorrichtungen werden in einem Host-zu-Haus-Netzsystem durch eine Netz-Plug-and-Play-Funktion (PnP-Funktion) verbunden.
Beispielsweise ist eine Universal Plug and Play (UPnP), die von der Firma Microsoft entwickelt wurde eine Art Netz-PnP, wie Jini, das von der Firma SUN Microsystems entwickelt wurde.
UPnP verwendet ein neues Netzprotokoll als ein Arbitrator (Schiedsrichter), der die Vorrichtungen interaktiv verbindet. Das heißt, wie beim HTTP, das ein Hypertext-Übertragungsprotokoll darstellt, wird unabhängig von den Typen der Computer, die mit einem Netzserver verbunden sind, das HTTP-Protokoll passend auf die erforderlichen Orte verteilt. Aktuell wird von Windows 2000 das Internet Printing Protocol (Internetdruckprotokoll) unterstützt, so dass ein Nutzer in der Ferne ein Dokument unter Verwendung eines Druckers, der mit einem Netz verbunden ist, drucken kann. Das IPP-Protokoll hängt nicht vom Betriebssystem des Nutzers, dem Hersteller des Druckers oder den Typen der Computer ab.
Mittlerweile übernimmt in Jini Java dieselbe Rolle wie das IPP von Microsoft. Die meisten heutigen PC laden Java-Applets von einem Server nur dann herunter und führen sie aus, wenn die PC Webbrowser aufweisen, die Java unterstützen. Somit werden unter Verwendung von diesem in Jini Java-Applets, die Vorrichtungen erkennen, unterstützt, häufig herabgeladen und wenn sie nicht notwendig sind, von der Maschine weggenommen. Im Kern von Jini steht die Remote Method Invocation (RMI). Insbesondere aus der Sicht eines Nutzers ist dies vorteilhaft, da das Verfahren des Herabladens und Löschens von Java-Applets vom menschlichen Auge nicht erkannt werden kann.
Im Heim-Netz, das die Änderbarkeit und Skalierbarkeit durch das Netz-PnP aufweist, ist es notwendig, den Verkehr zwischen den Vorrichtungen im IEEE1394-Netz wirksam zu verwalten, und es ist insbesondere notwendig, eine Übertragung unnötiger Pakete bei einer Multicast-Kommunikation zu verhindern.
Daher verwenden in der vorliegenden Erfindung durch die Bestimmung über eine IGMP-Anfrage/Nachricht, ob Nicht-MCAP-Vorrichtungen auf demselben Netz existieren, nur dann, wenn Nicht-MCAP-Vorrichtungen existieren, die MCAP-Vorrichtungen einen Broadcast-Kanal, und wenn alle Vorrichtungen das MCAP unterstützen, so wird das MCAP-Protokoll für eine Multicast-Übertragung verwendet.
Dadurch können Rechenbelastungen, die durch eine unnötige Verwendung von Broadcast-Kanälen verursacht werden, sogar wenn alle Vorrichtungen zu einer Multicast-Gruppe im IEEE1394-Netz gehören, die die MCAP-Abtastung unterstützen, verhindert werden. Auch sogar dann, wenn Nicht-MCAP-Vorrichtungen in der Multicast-Gruppe vorhanden sind, kann eine Multicast-Kommunikation durchgeführt werden.
4 ist ein Flussdiagramm, das ein Verfahren für die Bestimmung, ob MCAP unterstützt wird oder nicht, zeigt, und 5 ist ein schematisches Diagramm, das das Verfahren der 4 zeigt.
Betrachtet man die 4 und 5, so wird nun das Verfahren für die Bestimmung, ob das MCAP unterstützt wird oder nicht, gemäß der vorliegenden Erfindung erläutert.
Zuerst weist, wie das in 4 gezeigt ist, eine MCAP-Vorrichtung in Schritt S402 einen beliebigen anderen Kanal als den Broadcast-Kanal einer Multicast-Adresse zu und überträgt dann durch diesen Multicast-Kanal eine MCAP-Ankündigungsnachricht an alle Vorrichtungen auf dem IEEE1394-Netz.
Beispielsweise weist, wie das in 5 gezeigt ist, eine MCAP-Vorrichtung 402, die zur Multicast-Gruppe 239.255.255.250 gehört, den Kanal 7 einer Multicast-Adresse zu und überträgt dann durch einen Broadcast-Kanal (Kanal 31) eine MCAP-Ankündigungsnachricht an alle Vorrichtungen im gleichen IEEE1394-Netz.
Als nächstes überträgt die MCAP-Vorrichtung 402, die die MCAP-Ankündigungsnachricht überträgt, in Schritt S404 auch eine IGMP-Abfragenachricht an alle Vorrichtungen 404 und 406 auf demselben IEEE1394-Netz durch den Broadcast-Kanal (Kanal 31).
Das IGMP-Protokoll dient für die Verarbeitung eines Eintritts in oder eines Austritts aus der Multicast-Gruppe. Das IGMP-Protokoll wird für einen Multicast-Router, der das Vorhandensein von Hostgruppenmitgliedern auf einem entsprechenden Subnetz erkennt, verwendet.
Das IGMP-Protokoll verwendet im Grunde eine Abfragenachricht und eine Berichtsnachricht. Die Abfragenachricht ist eine Nachricht, mit der das IGMP-Protokoll fragt, ob es ein Host gibt, der in eine entsprechende Gruppe eintreten will. Die Abfragenachricht wird periodisch an das Subnetz übertragen, um das aktuelle Mitglied der Gruppe zu prüfen. Die Berichtsnachricht ist eine Antwort auf die Abfragenachricht, die ein Host, der die Absicht hat, in die Gruppe einzutreten, überträgt.
Wenn das IGMP eine Abfragenachricht an ein entsprechendes Subnetz überträgt, so kann ein Host, der die Absicht hat, in die entsprechende Multicast-Gruppe einzutreten, die Gruppe betreten, indem er eine Berichtsnachricht sendet. Indem auf die Abfragenachricht während einer vorbestimmten Zeit nicht geantwortet wird, kann ein Austritt aus einer Gruppe akzeptiert werden.
Die MCAP-Vorrichtung 402 überträgt in Schritt S404 eine IGMP-Abfragenachricht an die Multicast-Gruppe 239.255.255.250.
Die MCAP-Vorrichtung 402, die die MCAP-Ankündigungsnachricht überträgt, empfängt in Schritt S406 die IGMP-Nachrichten von allen Vorrichtungen im selben IEEE1394-Netz.
Die MCAP-Vorrichtung 402, die die MCAP-Ankündigungsnachricht überträgt, bestimmt in Schritt S408, ob die IGMP-Nachricht, die von allen Vorrichtungen im selben IEEE1394-Netz übertragen wird, durch den zugewiesenen Kanal (Kanal 7) übertragen wird.
Die Vorrichtungen 404 und 406, die zur Multicast-Gruppe 239.255.255.250 im IEEE1394-Netz gehören, übertragen IGMP-Berichtsnachrichten als Antworten auf die IGMP-Abfragenachricht. Die Bestimmungsadresse der IGMP-Berichtsnachrichten ist die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, das heißt, die MCAP-Vorrichtung 402, die die IGMP-Abfragenachricht überträgt.
Da die MCAP-Vorrichtung 406 schon die Kanalnummer für die entsprechende Multicast-Adresse 239.255.255.250 durch die empfangene MCAP-Ankündigungsnachricht kennt, überträgt die MCAP-Vorrichtung 406 die IGMP-Berichtsnachrichten durch den Kanal 7.
Mittlerweile überträgt, da die Nicht-MCAP-Vorrichtung 404 nicht die MCAP-Ankündigungsnachricht erkennt, die Nicht-MCAP- Vorrichtung 404 die IGMP-Berichtsnachricht durch den Broadcast-Kanal (Kanal 31).
Somit kann die MCAP-Vorrichtung 402 durch das Prüfen der Kanalnummern, durch die die IGMP-Nachrichten übertragen werden, bestimmen, ob die jeweilige Vorrichtung 404 und 406 das MCAP unterstützt oder ob sie das nicht tut.
Wenn die IGMP-Nachrichten, die von allen Vorrichtungen im selben IEEE1394-Netz übertragen werden, durch den zugewiesenen Kanal (Kanal 7) übertragen werden, bestimmt die MCAP-Vorrichtung 402 in Schritt S410, dass alle Vorrichtungen im selben IEEE1394-Netz das MCAP unterstützen.
Wenn die IGMP-Nachrichten, die nur von einigen der Vorrichtungen im selben IEEE1394-Netz übertragen werden, durch den zugewiesenen Kanal (Kanal 7) übertragen werden, so bestimmt die MCAP-Vorrichtung 402 in Schritt S412, dass nur einige der Vorrichtungen im selben IEEE1394-Netz das MCAP unterstützen.
Die MCAP-Ankündigungsnachricht umfasst ein Zeitablauffeld. Das Zeitablauffeld muss auf eine Zeit eingestellt werden, um einen Kanal, der durch die MCAP-Ankündigungsnachricht zugewiesen ist, zu halten. Die MCAP-Vorrichtung hält den zugewiesenen Kanal für das Multicast-Verfahren für die Zeit, die im Zeitablauffeld eingestellt ist.
Wenn die IGMP-Nachrichten, die nur von einigen der Vorrichtungen im selben IEEE1394-Netz übertragen werden, durch den zugewiesenen Kanal (Kanal 7) übertragen werden, ist es nicht notwendig, den Kanal, der durch die MCAP-Ankündigungsnachricht zugewiesen wurden, zu halten.
Somit wird, wenn die IGMP-Nachrichten, die nur von einigen der Vorrichtungen im selben IEEE1394-Netz übertragen werden, durch den zugewiesenen Kanal übertragen werden, eine MCAP-Ankündigungsnachricht die den Inhalt "Ablaufzeit = 0" aufweist, an alle Vorrichtungen im selben Netz übertragen, so dass der Kanal, der für das Multicast-Verfahren zugewiesen wurde, in Schritt S414 freigegeben wird.
6 ist ein Flussdiagramm, das ein Multicast-Kommunikationsverfahren gemäß der vorliegenden Erfindung zeigt, und 7 ist ein schematisches Diagramm, das das Verfahren der 6 zeigt.
Betrachtet man die 6 und 7, so wird nun das Verfahren für die Multicast-Kommunikation gemäß der vorliegenden Erfindung beschrieben.
Zuerst weist, wie das in 6 gezeigt ist, eine MCAP-Vorrichtung 402, die zu einer Multicast-Gruppe gehört, einen beliebigen anderen Kanal (einen Multicast-Kanal, beispielsweise Kanal 7) als die Broadcast-Kanäle einer Multicast-Adresse zu, und überträgt durch diesen Multicast-Kanal eine MCAP-Ankündigungsnachricht an alle Vorrichtungen auf demselben IEEE1394-Netz.
Als nächstes überträgt die MCAP-Vorrichtung 402, die die MCAP-Ankündigungsnachricht überträgt, im Schritt S604 eine IGMP-Abfragenachricht an alle Vorrichtung im selben IEEE1394-Netz.
Die MCAP-Vorrichtung 402, die die MCAP-Ankündigungsnachricht überträgt, empfängt im Schritt S606 die IGMP-Nachrichten von allen Vorrichtungen im selben IEEE1394-Netz.
Die MCAP-Vorrichtung 402, die die MCAP-Ankündigungsnachricht überträgt, bestimmt in Schritt S608, ob die IGMP-Nachrichten, die von allen Vorrichtungen auf demselben IEEE1394-Netz über tragen werden, durch den zugewiesenen Kanal (Kanal 7) übertragen werden.
Die Vorrichtungen 404 und 406, die zur Multicast-Gruppe 239.255.255.250 im IEEE1394-Netz gehören, übertragen IGMP-Berichtsnachrichten als Antworten auf die IGMP-Abfragenachricht. Die Bestimmungsadresse der IGMP-Berichtsnachrichten ist die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, das heißt, die MCAP-Vorrichtung 402, die die IGMP-Abfragenachricht überträgt.
Da die MCAP-Vorrichtung 406 schon die Kanalnummer für die entsprechende Multicast-Rdresse 239.255.255.250 durch die empfangene MCAP-Ankündigungsnachricht kennt, überträgt die MCAP-Vorrichtung 406 die IGMP-Berichtsnachricht durch den Kanal 7.
Mittlerweile überträgt, da die Nicht-MCAP-Vorrichtung 404 die MCAP-Ankündigungsnachricht nicht erkennt, die Nicht-MCAP-Vorrichtung 404 die IGMP-Berichtsnachricht durch den Broadcast-Kanal (Kanal 31).
Somit kann die MCAP-Vorrichtung 402 durch das Prüfen der Kanalnummern, durch die die IGMP-Nachrichten übertragen werden, bestimmen, ob die jeweilige Vorrichtung 404 und 406 das MCAP unterstützt oder ob sie das nicht tut.
Wenn die IGMP-Nachrichten, die von Vorrichtungen auf demselben IEEE1394-Netz übertragen werden, durch den zugewiesenen Kanal (Kanal 7) übertragen werden, so bestimmt die MCAP-Vorrichtung 402 in Schritt S610, dass alle Vorrichtungen im selben IEEE1394-Netz das MCAP unterstützen. Die MCAP-Vorrichtung 402 führt eine Kommunikation mit der entsprechenden Multicast-Adresse unter Verwendung des Multicast-Kanals in Schritt S616 durch.
Wenn die IGMP-Nachrichten nur von einigen der Vorrichtungen im selben IEEE1394-Netz durch den zugewiesenen Kanal (Kanal 7) übertragen werden, so bestimmt die MCAP-Vorrichtung 402 in Schritt S612, dass nur einige der Vorrichtungen im selben IEEE1394-Netz das MCAP unterstützen. Die MCAP-Vorrichtung 402 überträgt in Schritt S614 eine MCAP-Ankündigungsnachricht, die den Inhalt "Zeitablauf = 0" (sofortige Freigabe) aufweist, an alle Vorrichtungen im selben Netz.
Die MCAP-Vorrichtung 402 führt in Schritt S618 eine Kommunikation mit der entsprechenden Multicast-Adresse unter Verwendung des Broadcast-Kanals durch.
Wie in 7 gezeigt ist, führt die MCAP-Vorrichtung 402 eine Kommunikation mit der entsprechenden Multicast-Adresse (239.255.255.250) durch den zugewiesenen Kanal 7 durch, wenn alle IGMP-Berichte durch den zugewiesenen Kanal 7 empfangen werden, und überträgt eine Nachricht durch den Broadcast-Kanal (Kanal 31), wenn irgend eine der IGMP-Berichtsnachrichten durch den Broadcast-Kanal (Kanal 31) empfangen wurde.
Das heißt, wenn alle Vorrichtungen, die zu einer Multicast-Gruppe gehören, das MCAP unterstützen, so wird eine Multicast-Kommunikation durch das MCAP-Protokoll durchgeführt, wohingegen, wenn es Nicht-MCAP-Vorrichtungen gibt, die Multicast-Kommunikation durch das Broadcast-Verfahren durchgeführt wird.
Somit können Rechenbelastungen, die durch das unnötige Verwenden von Broadcast-Kanälen verursacht werden, sogar dann wenn alle Vorrichtungen, die zu einer Multicast-Gruppe im IEEE1394-Netz gehören, das MCAP unterstützen, verhindert werden. Es kann auch sogar, wenn es Nicht-MCAP-Vorrichtungen in der Multicast-Gruppe gibt, eine Multicast-Kommunikation durchgeführt werden.

3(a)

302: MCAP-Vorrichtungen
304: Nicht-MCAP-Vorrichtungen
306: MCAP-Vorrichtungen

3(b)

4

S402: Weise Multicast-Adresse zu, übertrage MCAP-Ankündigungsnachricht
S404: Übertrage IGMP-Abfragenachricht
S406: Empfange IGMP-Berichtsnachricht
S408: Werden alle IGMP-Berichtsnachrichten durch den zugewiesenen Kanal
: empfangen?
S410: Bestimme, dass alle Vorrichtungen auf dem Netz MCAP unterstützen
S412: Bestimme, dass nicht alle Vorrichtungen auf dem Netz MCAP unterstützen
S414: Übertrage MCAP-Ankündigungsnachricht, Zeitablauf = 0

5

402: MCAP-Vorrichtungen
404: Nicht-MCAP-Vorrichtungen
406: MCAP-Vorrichtungen

6

S602: Weise Multicast-Adresse zu, übertrage MCAP-Ankündigungsnachricht
S604: Übertrage IGMP-Abfragenachricht
S606: Empfange IGMP-Berichtsnachricht und prüfe, ob MCAP unterstützt wird oder
: nicht

S608: Werden alle IGMP-Berichtsnachrichten durch den zugewiesenen Kanal
: empfangen?
S610: Bestimme, dass alle Vorrichtungen auf dem Netz MCAP unterstützen.
S612: Bestimme, dass nicht alle Vorrichtungen auf dem Netz MCAP unterstützen
S614: Übertrage MCAP-Ankündigungsnachricht, Zeitablauf = 0
S616: Multicast im MCAP-Verfahren
S618: Multicast im Broadcast-Verfahren

7

Claims

Verfahren zur Bestimmung, ob ein Multicast-Kanalzuweisungsprotokoll (MCAP) in einem Netz unterstützt wird oder nicht, wobei das Verfahren folgendes umfasst: (a) eine MCAP-Vorrichtung überträgt eine MCAP-Ankündigungsnachricht an alle Vorrichtungen im selben Netz; (b) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, überträgt eine Internet-Gruppen-Verwaltungsprotokoll-Abfragenachricht (IGMP-Abfragenachricht) an alle Vorrichtungen im selben Netz; und (c) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, bestimmt, ob jede der Vorrichtungen im selben Netz das MCAP unterstützt oder nicht, durch die Kanalnummer des Kanals, durch den eine IGMP-Berichtsnachricht von den Vorrichtungen im selben Netz übertragen wurde.
Verfahren nach Anspruch 1, wobei im Schritt (c), wenn die IGMP-Berichtsnachricht nicht durch einen Kanal empfangen wird, der durch eine MCAP-Broadcast-Nachricht zugewiesen wird, bestimmt wird, dass nur einige der Vorrichtungen im selben Netz das MCAP unterstützen.
Verfahren nach Anspruch 2, weiter umfassend: (d) Übertragen einer MCAP-Broadcast-Nachricht, die alle Vorrichtungen im selben Netz anweist, den zugewiesenen Kanal freizugeben, wenn die IGMP-Berichtsnachricht nicht durch den Kanal empfangen wird, der durch die MCAP-Broadcast-Nachricht zugewiesen wurde.
Verfahren nach Anspruch 3, wobei im Schritt (d) eine MCAP-Broadcast-Nachricht, die den Inhalt "Ablaufzeit = 0" aufweist, übertragen wird.
Verfahren nach Anspruch 1, wobei das Netz ein IEEE 1394-Netz ist.
Multicast-Kommunikationsverfahren in einem Netz, wobei das Verfahren folgendes umfasst: (a) eine MCAP-Vorrichtung, die zu einer Multicast-Gruppe gehört, überträgt eine MCAP-Ankündigungsnachricht an alle Vorrichtungen im selben Netz; (b) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, überträgt eine IGMP-Abfragenachricht an alle Vorrichtungen im selben Netz; (c) die MCAP-Vorrichtung, die die MCAP-Ankündigungsnachricht überträgt, bestimmt, ob jede der Vorrichtungen im selben Netz das MCAP unterstützt oder nicht, durch die Kanalnummer des Kanals, durch den eine IGMP-Berichtsnachricht von den Vorrichtungen im selben Netz übertragen wurde; und (e) Durchführen einer Kommunikation mit der entsprechenden Multicast-Adresse unter Verwendung des Multicast-Kanals, wenn die IGMP-Berichtsnachrichten von allen Vorrichtungen, an die die MCAP-Broadcast-Nachricht übertragen wurde, durch den Multicast-Kanal empfangen werden, und Durchführen einer Kommunikation mit der entsprechenden Multicast-Adresse durch das Verwenden von Broadcast-Kanälen, wenn nur einige der IGMP-Berichtsnachrichten von allen Vorrichtungen durch den Multicast-Kanal empfangen werden.
Verfahren nach Anspruch 6, wobei im Schritt (c), wenn die IGMP-Berichtsnachricht nicht durch einen Kanal empfangen wird, der durch eine MCAP-Broadcast-Nachricht zugewiesen wird, bestimmt wird, dass nur einige der Vorrichtungen im selben Netz das MCAP unterstützen.
Verfahren nach Anspruch 7, weiter umfassend: (d) Übertragen einer MCAP-Broadcast-Nachricht, die alle Vorrichtungen im selben Netz anweist, den zugewiesenen Kanal freizugeben, wenn die IGMP-Berichtsnachricht nicht durch den Kanal empfangen wird, der durch die MCAP-Broadcast-Nachricht zugewiesen wurde.
Verfahren nach Anspruch 8, wobei im Schritt (d) eine MCAP-Broadcast-Nachricht, die den Inhalt "Ablaufzeit = 0" aufweist, übertragen wird.
Verfahren nach Anspruch 6, wobei das Netz ein IEEE 1394-Netz ist.