Zusammenfassung In diesem Anhang wird Internet Protocol (IP)-Multicast sowohl für Internet Protocol Version 4 (IPv4) als auch Internet Protocol Version 6 (IPv6) und dessen Unterstützung unter den Betriebssystemen Microsoft® Windows Server™ 2003 und Windows® XP beschrieben. IP-Multicast ist ein zentraler Verteilungsmechanismus, der sich für die effiziente Verteilung von Daten an interessierte empfangsbereite Hosts an beliebigen Standorten in einem privaten Netzwerk oder im Internet eignet. Netzwerkadministratoren müssen im Umgang mit Multicastkonzepten, Multicastadressierung und -weiterleitung, Multicastadresszuweisung und zuverlässigem Multicast sicher sein, um den IP-Multicastverkehr effektiv verwenden und Probleme damit behandeln zu können. Auf dieser SeiteIP-Multicast im ÜberblickNeben der Unterstützung von Unicast und Broadcast stellt IP auch einen Mechanismus zum Senden und Empfangen von IP-Multicastverkehr bereit. IP-Multicastverkehr wird an eine einzige IP-Zieladresse gesendet, jedoch von mehreren IP-Hosts empfangen und verarbeitet. Der Standort der Hosts im IP-Netzwerk spielt dabei keine Rolle. Ein Host überwacht eine bestimmte IP-Multicastadresse und empfängt alle an diese IP-Adresse gesendeten Pakete. IP-Multicast arbeitet bei der zentralen Verteilung von Daten effizienter als IP-Unicast oder -Broadcast. Im Gegensatz zu Unicast wird nur eine Kopie der Daten gesendet, und im Gegensatz zu Broadcast wird der Verkehr nur von Computern empfangen und verarbeitet, die diesen Verkehr überwachen. Die Hosts, die eine bestimmte IP-Multicastadresse überwachen, werden als Hostgruppe bezeichnet. Ein Host kann Verkehr an eine IP-Multicastadresse senden, ohne Mitglied der entsprechenden Hostgruppe zu sein. Die Mitgliedschaft in der Hostgruppe ist dynamisch. Hosts können der Gruppe jederzeit beitreten bzw. die Gruppe jederzeit verlassen, und es gelten keine Beschränkungen für die Größe einer Hostgruppe. Eine Hostgruppe kann IP-Router in mehreren Netzwerksegmenten umfassen. Damit diese Konfiguration möglich ist, müssen die IP-Router IP-Multicast unterstützen, und die Hosts müssen in der Lage sein, ihre Empfangsbereitschaft für Multicastverkehr von den benachbarten Routern zu registrieren. Die Hosts verwenden für IPv4 das Internet Group Management Protocol (IGMP) und für IPv6 die Multicast-Listener-Erkennung (Multicast Listener Discovery, MLD) zur Registrierung der Mitgliedschaft in der Hostgruppe. IP-Multicast-fähiges IntranetIn einem IP-Multicast-fähigen Intranet kann jeder Host IP-Multicastverkehr an eine beliebige Gruppenadresse senden, und jeder Host kann IP-Multicastverkehr von jeder beliebigen Gruppenadresse empfangen. Der Standort der Hosts spielt dabei keine Rolle. Abbildung A-1 zeigt ein Beispiel für ein IP-Multicast-fähiges Intranet.  Abbildung A-1: Ein IP-Multicast-fähiges Intranet Damit dies möglich ist, müssen die Hosts und Router im Netzwerk IP-Multicast unterstützen. Hostunterstützung für IP-MulticastDamit ein Host IP-Multicastpakete senden kann, muss er die folgenden Schritte ausführen: | • | Feststellen der zu verwendenden IP-Multicastadresse Die IP-Multicastadresse kann von der Anwendung fest codiert oder über einen Mechanismus bezogen werden, durch den eine eindeutige Multicastadresse zugewiesen wird. | | • | Platzieren des IP-Multicastpakets auf dem Medium Der sendende Host muss ein IP-Paket erstellen, das die IP-Multicastadresse des Ziels enthält, muss das Paket auf das Medium setzen. Bei Technologien für den gemeinsamen Zugriff wie Ethernet und Token Ring wird die MAC-Adresse (Media Access Control) des Ziels aus der IP-Multicastadresse abgeleitet. |
Damit ein Host IP-Multicastpakete empfangen kann, muss er die folgenden Schritte ausführen: | • | Vorbereiten von IP zum Empfang von Multicastverkehr. Zur Ermittlung der zu verwendenden IP-Multicastadresse muss die Anwendung zuerst feststellen, ob eine neue Hostgruppe erstellt werden oder ob der Host einer bereits vorhandenen Hostgruppe beitreten soll. Soll der Host einer bereits vorhandenen Gruppe beitreten, kann die Anwendung eine fest codierte Multicastadresse oder eine Adresse verwenden, die aus einem URL (Uniform Resource Locator) abgeleitet wurde. Nachdem die Gruppenadresse festgelegt wurde, muss IP von einer Anwendung darüber informiert werden, den an die Gruppenadresse gesendeten Multicastverkehr zu empfangen. Die Anwendung kann z. B. Windows Sockets-Funktionen verwenden, um IP über die Multicastgruppen zu informieren, denen sie beigetreten ist. Wenn mehrere Anwendungen die gleiche IP-Multicastadresse verwenden, muss IP an jede Anwendung eine Kopie des Multicastpakets übergeben. IP muss verfolgen, von welchen Anwendungen welche Multicastadressen verwendet werden, wenn Anwendungen einer Hostgruppe beitreten bzw. eine Hostgruppe verlassen. Bei einem mehrfach vernetzten Host muss IP die Mitgliedschaft von Anwendungen bei Hostgruppen für jedes Subnetz verfolgen. | | • | Registrieren der Multicast-MAC-Adresse beim Netzwerkadapter. Wenn die Netzwerktechnologie das hardwarebasierte Multicasting unterstützt, wird der Netzwerkadapter angewiesen, Pakete für eine bestimmte Multicastadresse weiterzuleiten. Der Host weist den Netzwerkadapter mithilfe der Windows-Funktion NdisRequest() an, auf eine Multicast-MAC-Adresse zu antworten, die einer IP-Multicastadresse entspricht. | | • | Informieren lokaler Router. Der Host muss Router im lokalen Subnetz informieren, die er mithilfe von IGMP oder MLD an einer bestimmten Gruppenadresse auf Multicastverkehr überwacht. |
Routerunterstützung für IP-MulticastDamit IP-Multicastpakete nur an die Subnetze weitergeleitet werden, für die Gruppenmitglieder vorhanden sind, muss ein IP-Multicastrouter Folgendes leisten: | • | Empfangen des gesamten IP-Multicastverkehrs. Bei Technologien für den gemeinsamen Zugriff ist Unicast der normale Empfangsmodus für Netzwerkadapter. Der Empfangsmodus ist die Art und Weise, wie der Netzwerkadapter die MAC-Zieladresse eingehender Frames analysiert, um festzustellen, ob sie weiter verarbeitet werden sollen. Im Unicast-Empfangsmodus sind die einzigen Frames, die zur weiteren Verarbeitung berücksichtigt werden, in einer Tabelle zu verwendender MAC-Zieladressen enthalten, die auf dem Netzwerkadapter gespeichert sind. In der Regel sind nur die Broadcastadresse (0xFF-FF-FF-FF-FF-FF) und die Unicast-MAC-Adresse des Adapters die einzigen interessanten Adressen. Damit ein IP-Multicastrouter den gesamten IP-Multicastverkehr empfangen kann, muss er den Netzwerkadapter jedoch in einen speziellen Empfangsmodus versetzen, den so genannten gemischten Multicastmodus. Im gemischten Multicastmodus wird das durch IEEE (Institute of Electrical and Electronic Engineers) definierte I/G-Bit (Individual/Group) analysiert, um festzustellen, ob der Frame weiter verarbeitet werden muss. Das I/G-Bit für Ethernet-Adressen ist das niedrigwertige Bit des ersten Bytes der MAC-Zieladresse. Das I/G-Bit hat die folgenden Werte: | • | Wenn es auf 0 festgelegt ist, handelt es sich bei der Adresse um eine Unicast- oder individuelle Adresse. | | • | Wenn es auf 1 festgelegt ist, handelt es sich um eine Multicast- oder Gruppenadresse. Für die Broadcastadresse wird das Multicastbit ebenfalls auf 1 festgelegt. |
Wenn der Netzwerkadapter in den gemischten Multicastempfangsmodus versetzt wird, werden alle Frames, deren I/G-Bit auf 1 festgelegt ist, zur weiteren Verarbeitung weitergeleitet. Der gemischte Multicastmodus unterscheidet sich vom gemischten Modus. Im gemischten Modus werden alle Frames – unabhängig von der MAC-Zieladresse – zur Verarbeitung weitergeleitet. Protokollanalyseprogramme, beispielsweise die Vollversion von Microsoft Netzwerkmonitor, die zu Microsoft Systems Management Server gehört, verwenden den gemischten Modus. Netzwerkadapter von Hosts werden in der Regel nicht in den gemischten Multicastmodus versetzt. | | • | Weiterleiten des IP-Multicastverkehrs. Die Weiterleitung der IP-Multicastpakete ist eine Funktion des IP. Wenn die IP-Multicastweiterleitung aktiviert ist, werden IP-Multicastdatenpakete von IP analysiert, um die Schnittstellen zu ermitteln, über die die Pakete weitergeleitet werden sollen. Bei dieser Analyse werden die Adressen der IP-Quell- und der -Zielgruppe mit Einträgen in der IP-Multicast-Weiterleitungstabelle verglichen. Bei Empfang eines nicht lokalen IP-Multicastpakets wird die Gültigkeitsdauer (Time to Live, TTL) im IPv4-Header oder das Feld "Hop Limit" im IPv6-Header um 1 dekrementiert. Wenn die TTL oder das Hop Limit nach dem Dekrementieren größer ist als 0, wird die Multicast-Weiterleitungstabelle überprüft. Wenn in der Multicast-Weiterleitungstabelle ein Eintrag gefunden wird, der der IP-Multicast-Zieladresse entspricht, wird das IP-Multicastpaket mit der neuen TTL bzw. dem neuen Hop Limit über die entsprechenden Schnittstellen weitergeleitet. Bei der Multicastweiterleitung erfolgt keine Unterscheidung zwischen Hosts in lokal verbundenen Subnetzen, die Multicastverkehr empfangen, und Hosts in einem Netzwerksegment, die dem lokal verbundenen Subnetz über einen anderen Router im Subnetz nachgelagert sind. Ein Multicastrouter leitet also unter Umständen ein Multicastpaket in einem Subnetz weiter, für das es keine empfangsbereiten Hosts gibt. Der Multicastrouter leitet das Paket weiter, weil ein anderer Router in diesem Subnetz angegeben hat, dass ein ihm nachgelagerter Host den Multicastverkehr empfängt. In der Multicast-Weiterleitungstabelle wird nicht jedes Mitglied der Hostgruppe oder die Anzahl der Hostgruppenmitglieder erfasst, sondern nur, dass der Multicastverkehr über bestimmte Schnittstellen weitergeleitet werden muss. | | • | Empfangen und Verarbeiten von Nachrichten zur Mitgliedschaft in Multicastgruppen, die von Hosts gesendet wurden. Multicastrouter empfangen IGMP- oder MLD-Nachrichten von Hosts aus allen lokal verbundenen Subnetzen. Anhand dieser Informationen wird die Hostgruppenmitgliedschaft erfasst, und Einträge werden in die Multicast-Weiterleitungstabelle eingefügt bzw. aus dieser Tabelle entfernt. Da alle Multicastrouter im gemischten Multicastmodus empfangsbereit sind, empfangen sie alle IGMP- und MLD-Nachrichten, die an eine Gruppenadresse gesendet werden. Um die Wartezeit beim Verlassen zu verbessern – dies ist die Zeit zwischen dem Zeitpunkt, zu dem der letzte Host in einem Subnetz die Gruppe verlassen hat, und dem Zeitpunkt, ab dem kein Multicastverkehr für die betreffende Gruppe mehr an das betreffende Subnetz weitergeleitet wird – sendet ein Host, der eventuell das letzte Mitglied einer Gruppe in einem Subnetz ist, eine IGMP Leave Group- oder eine MLD Multicast Listener Done-Nachricht. Wenn der Router multicastadressenspezifische IGMP- oder MLD-Abfragen an die verlassene Gruppe gesendet und keine Antwort empfangen hat, stellt der Router fest, dass sich in dem betreffenden Subnetz keine Gruppenmitglieder mehr befinden. | | • | Abfragen verbundener Subnetze nach dem Status der Hostmitgliedschaft. Multicastrouter senden von Zeit zu Zeit allgemeine IGMP- und MLD-Abfragen an das lokale Subnetz, um Informationen über die Hostmitgliedschaft abzufragen. Die Abfrage wird von einem Host beantwortet, der noch Mitglied einer Multicastgruppe ist. | | • | Informieren anderer IP-Multicastrouter über die Gruppenmitgliedschaft. Um multicastfähige IP-Netzwerke zu erstellen, die mehrere Router enthalten, müssen Multicastrouter einander Informationen über die Gruppenmitgliedschaft mitteilen, damit die Gruppenmitglieder unabhängig von ihrem Standort im IP-Netzwerk IP-Multicastverkehr empfangen können. Multicastrouter tauschen Informationen über die Hostmitgliedschaft mittels eines Multicastroutingprotokolls wie Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF) oder Protocol Independent Multicast (PIM) aus. Die Gruppenmitgliedschaft wird entweder explizit durch Angeben von Gruppenadresse und Subnetz mitgeteilt oder implizit. In diesem Fall werden vorgelagerte Router darüber informiert, ob der Quelle des Multicastverkehrs Gruppenmitglieder nachgelagert sind. Ein Multicastroutingprotokoll dient folgenden Zielen: | • | Weiterleiten von Verkehr weg von der Quelle, um Schleifen zu verhindern. | | • | Minimieren oder Beseitigen von Multicastverkehr zu Subnetzen, für die der Verkehr nicht bestimmt ist. | | • | Minimieren der Prozessor- und Speicherbelastung auf dem Router zur Verbesserung der Skalierbarkeit. | | • | Minimieren des Verwaltungsaufwands für das Routingprotokoll. | | • | Minimieren der Verknüpfungswartezeit; dies ist die Zeit, die vergeht, bis das erste Hostmitglied in einem Subnetz Gruppenverkehr empfängt. |
Das Multicastrouting ist komplizierter als das Unicastrouting. Beim Unicastrouting wird der Unicastverkehr an ein global eindeutiges Ziel weitergeleitet. Unicastrouten fassen Bereiche global eindeutiger Ziele zusammen. Unicastrouten im Netzwerk sind vergleichsweise konsistent und müssen nur dann aktualisiert werden, wenn sich die Topologie des IP-Netzwerks ändert. Beim Multicastrouting wird der Multicastverkehr an ein mehrdeutiges Gruppenziel weitergeleitet. Gruppenadressen stellen einzelne Gruppen dar und können im Allgemeinen nicht in der Multicast-Weiterleitungstabelle zusammengefasst werden. Der Standort der Gruppenmitglieder ist nicht konsistent, und die Multicast-Weiterleitungstabellen von Multicastroutern müssen eventuell jedes Mal aktualisiert werden, wenn ein Mitglied der Hostgruppe einer Hostgruppe beitritt oder eine Gruppe verlässt. Ebenso wie die Unicast-IP-Routingtabelle von Unicastroutingprotokollen aktualisiert wird, so wird die IP-Multicast-Weiterleitungstabelle von Multicastroutingprotokollen aktualisiert. Der Routing und RAS-Dienst in Windows Server 2003 enthält keine IPv4- oder IPv6-Multicastroutingprotokolle, allerdings stellt er eine Plattform bereit, auf der IPv4-Multicastroutingprotokolle von Drittanbietern ausgeführt werden können. Die einzige Komponente von Windows Server 2003, mit der Einträge in der IPv4-Multicast-Weiterleitungstabelle aktualisiert werden können, ist die IGMP-Routingprotokollkomponente von Routing und RAS. |
MulticastadressenMulticastadressen werden sowohl für IPv4- als auch für IPv6-Adressen definiert. IPv4-MulticastadressenIPv4-Multicastadressen, die auch als Gruppenadressen bezeichnet werden, befinden sich im Klasse-D-Bereich 224.0.0.0/4 (von 224.0.0.0 bis 239.255.255.255) und werden definiert, indem die ersten vier höherwertigen Bits auf 1110 festgelegt werden. Multicastadressen im Bereich 224.0.0.0/24 (von 224.0.0.0 bis 224.0.0.255) sind für das lokale Subnetz reserviert und werden unabhängig vom TTL-Wert im IPv4-Header nicht von IPv4-Routern weitergeleitet. Es folgen einige Beispiele für reservierte IPv4-Multicastadressen: | • | 224.0.0.1 – alle Hosts in diesem Subnetz | | • | 224.0.0.2 – alle Router in diesem Subnetz | | • | 224.0.0.5 – alle Open Shortest Path First (OSPF)-Router in einem Subnetz | | • | 224.0.0.6 – alle OSPF zugeordneten Router in einem Subnetz | | • | 224.0.0.9 – Routing Information Protocol (RIP) Version 2 |
Die aktuelle Liste reservierter IPv4-Multicastadressen finden Sie unter http://www.iana.org/assignments/multicast-addresses. Zuordnen von IPv4-Multicastadressen zu Multicastadressen der MAC-EbeneZur Unterstützung des IPv4-Multicasting haben die Internet-Behörden den Multicastadressbereich von 01-00-5E-00-00-00 bis 01-00-5E-7F-FF-FF für Ethernet-MAC-Adressen reserviert. Wenn eine IPv4-Multicastadresse einer Multicastadresse der MAC-Ebene zugeordnet werden soll, werden die 23 niedrigwertigen Bits der IPv4-Multicastadresse den 23 niedrigwertigen Bits in der Multicastadresse der MAC-Ebene direkt zugeordnet. Abbildung A-2 zeigt die Zuordnung einer IPv4-Multicastadresse zu einer Ethernet-Multicastadresse.  Abbildung A-2: Zuordnen von IPv4-Multicastadressen zu Ethernet-Multicastadressen Beispiel: | • | Die IPv4-Multicastadresse 224.0.0.1 wird 01-00-5E-00-00-01 zugeordnet. Beim Zuordnen der 23 niedrigwertigen Bits wird das erste Oktett nicht verwendet, und nur die letzten sieben Bits des zweiten Oktetts werden verwendet. Das dritte und vierte Oktett wird direkt in Hexadezimalzahlen umgewandelt. Beim zweiten und dritten Oktett entspricht 0 dem Hexadezimalwert 0x00. Beim letzten Oktett entspricht 1 dem Hexadezimalwert 0x01. Die MAC-Zieladresse, die 224.0.0.1 entspricht, lautet daher 01-00-5E-00-00-01. | | • | Die IPv4-Multicastadresse 224.192.16.1 wird 01-00-5E-40-01-01 zugeordnet. Beim zweiten Oktett wird 192 binär mit 11000000 ausgedrückt. Wenn Sie das höherwertige Bit weglassen, wird die Zahl zu 1000000 oder 64 (dezimal) bzw. 0x40 (hexadezimal). Beim dritten Oktett entspricht 16 dem Hexadezimalwert 0x10. Beim letzten Oktett entspricht 1 dem Hexadezimalwert 0x01. Die MAC-Zieladresse, die 224.192.16.1 entspricht, lautet daher 01-00-5E-40-10-01. |
Da die ersten vier Bits einer IPv4-Multicastadresse nach den Konventionen der Klasse D festgesetzt sind, enthält die IPv4-Multicastadresse 5 Bits, die der Multicastadresse der MAC-Ebene nicht zugeordnet werden. Daher empfängt ein Host unter Umständen Multicastpakete der MAC-Ebene für Gruppen, zu denen er nicht gehört. IPv4 verwirft diese Pakete jedoch, sobald die IPv4-Zieladresse ermittelt ist. Token Ring verwendet die gleiche Methode für die Multicastadressierung auf MAC-Ebene. Von vielen Token Ring-Netzwerkadaptern wird diese Methode jedoch nicht unterstützt. Daher wird standardmäßig für den gesamten IP-Multicastverkehr, der über Token Ring-Netzwerke gesendet wird, die funktionale Adresse 0xC0-00-00-04-00-00 verwendet. Weitere Informationen über die Token Ring-Unterstützung für IPv4-Multicasting finden Sie in RFC 1469. IPv6-MulticastadressenBei IPv6-Multicastadressen sind die ersten acht Bits auf 1111 1111 (FF00::/8) festgelegt. Eine IPv6-Multicastadresse beginnt daher stets mit FF. Multicastadressen können in einem Routingheader nicht als Quelladressen oder als Zwischenziele verwendet werden. Zusätzlich zu den ersten acht Bits enthalten IPv6-Multicastadressen eine Struktur, um Flags, den Gültigkeitsbereich und die Multicastgruppe zu identifizieren. Abbildung A-3 zeigt die Struktur der IPv6-Multicastadresse.  Abbildung A-3: Struktur der IPv6-Multicastadresse Die Multicastadresse enthält folgende Felder: | • | Flags Zeigt Flags an, die in der Multicastadresse gesetzt sind. Dieses Feld hat eine Größe von vier Bits. Nach RFC 3513 ist nur das Flag "Transient (T)" definiert; dieses verwendet das niedrigwertige Bit des Feldes "Flags". Wenn das T-Flag auf 0 festgelegt ist, so handelt es sich bei der Multicastadresse um eine permanent zugeordnete (wohlbekannte) Multicastadresse, die von IANA reserviert wurde. Wenn das T-Flag auf 1 festgelegt ist, so handelt es sich bei der Multicastadresse um eine nicht permanent zugeordnete (vorübergehende) Multicastadresse, die von IANA reserviert wurde. | | • | Scope Gibt den Bereich des IPv6-Netzwerks an, für den der Multicastverkehr übermittelt werden muss. Dieses Feld hat eine Größe von vier Bits. Neben Informationen, die von Multicastroutingprotokollen bereitgestellt werden, stellen Router mithilfe des Multicastbereichs fest, ob Multicastverkehr weitergeleitet werden kann. Üblicherweise verwendete Werte für das Feld "Scope" sind 1 für den Node-Local-Bereich, 2 für den Link-Local-Bereich und 5 für den Site-Local-Bereich. Weitere Werte für das Feld "Scope" sind in RFC 3513 definiert. | | • | Group ID Identifiziert die Multicastgruppe und ist innerhalb des Bereichs eindeutig. Dieses Feld hat eine Größe von 112 Bit. Permanent zugewiesene Gruppen-IDs sind unabhängig vom Bereich. Vorübergehende Gruppen-IDs gelten nur für einen bestimmten Bereich. Multicastadressen von FF01:: bis FF0F:: sind reservierte wohlbekannte Adressen. |
Zur Identifizierung aller Knoten für den Node-Local- und den Link-Local-Bereich werden die folgenden Adressen definiert: | • | FF01::1 (Multicastadresse für alle Knoten im Node-Local-Bereich) | | • | FF02::1 (Multicastadresse für alle Knoten im Link-Local-Bereich) |
Zur Identifizierung aller Router für den Node-Local-, den Link-Local- und den Site-Local-Bereich werden die folgenden Adressen definiert: | • | FF01::2 (Multicastadresse für alle Router im Node-Local-Bereich) | | • | FF02::2 (Multicastadresse für alle Router im Local-Local-Bereich) | | • | FF05::2 (Multicastadresse für alle Router im Site-Local-Bereich) |
Die aktuelle Liste permanent zugewiesener IPv6-Multicastadressen finden Sie unter http://www.iana.org/assignments/ipv6-multicast-addresses. IPv6-Multicastadressen ersetzen alle Arten von IPv4-Broadcastadressen. Die Adressen für den IPv4-Netzwerkbroadcast (alle Hostbits werden in einer Klassenumgebung auf 1 festgelegt), für den Subnetzbroadcast (alle Hostbits werden in einer klassenlosen Umgebung auf 1 festgelegt) und für den beschränkten Broadcast (255.255.255.255) werden in IPv6 durch die Multicastadresse für alle Knoten im Link-Local-Bereich (FF02::1) ersetzt. Adresse des angeforderten KnotensDie Adresse für den angeforderten Knoten vereinfacht die effiziente Abfrage von Netzwerkknoten während der Auflösung der Adresse auf Verknüpfungsebene, der Auflösung einer Verknüpfungsebenenadresse einer bekannten IPv6-Adresse. In IPv4 wird der ARP Request-Frame an den MAC-Ebenen-Broadcast gesendet, wobei alle Knoten im Netzwerksegment gestört werden, einschließlich derer, auf denen IPv4 nicht ausgeführt wird. IPv6 verwendet für die Auflösung von Adressen auf Verknüpfungsebene die Nachbaranfragenachricht. Anstatt jedoch die Multicastadresse für alle Knoten im Link-Local-Bereich als Ziel der Nachbaranfragenachricht zu verwenden, wodurch alle IPv6-Knoten in der lokalen Verknüpfung gestört würden, wird die Multicastadresse des angeforderten Knotens verwendet. Diese Adresse wird mithilfe des Präfix FF02::1:FF00:0/104 und der letzten 24 Bits der aufgelösten IPv6-Unicastadresse konstruiert. Abbildung A-4 zeigt die Zuordnung einer IPv6-Unicastadresse zu der entsprechenden Multicastadresse des angeforderten Knotens.  Abbildung A-4: Zuordnen einer IPv6-Unicastadresse zu der entsprechenden Multicastadresse des angeforderten Knotens Beispiel: Knoten A wird die Link-Local-Adresse FE80::2AA:FF:FE28:9C5A zugewiesen und ist außerdem auf der entsprechenden Multicastadresse des angeforderten Knotens FF02::1:FF28:9C5A empfangsbereit (mit der Fettformatierung wird hervorgehoben, dass sich die letzten sechs Hexadezimalziffern entsprechen). Knoten B in der lokalen Verknüpfung muss die Link-Local-Adresse FE80::2AA:FF:FE28:9C5A von Knoten A in die entsprechende Adresse auf Verknüpfungsebene auflösen. Knoten B sendet eine Nachbaranfragenachricht an die Multicastadresse FF02::1:FF28:9C5A des angefragten Knotens. Da Knoten A auf dieser Multicastadresse empfangsbereit ist, wird die Nachbaranfragenachricht verarbeitet und als Antwort eine Unicastnachricht für die Nachbarankündigung zurückgesendet. Aufgrund der Verwendung der Multicastadresse des angeforderten Knotens wird bei Auflösungen von Adressen auf Verknüpfungsebene, ein bei Verknüpfungen häufig auftretendes Ereignis, kein Mechanismus verwendet, durch den alle Netzwerkknoten gestört werden. Bei Verwendung der Adresse des angeforderten Knotens werden während der Adressauflösung sehr wenige Knoten gestört. Wegen der Beziehung zwischen der MAC-Adresse auf Verknüpfungsebene, der IPv6-Schnittstellen-ID und der Adresse des angeforderten Knotens, fungiert die Adresse des angeforderten Knotens als Pseudo-Unicastadresse und gewährleistet eine sehr effiziente Adressauflösung. Zuordnen von IPv6-Multicastadressen zu Multicastadressen der MAC-EbeneZur Unterstützung des IPv6-Multicasting haben die Internet-Behörden den Multicastadressbereich von 33-33-00-00-00-00 bis 33-33-FF-FF-FF-FF für Ethernet-MAC-Adressen reserviert. Wenn eine IPv6-Multicastadresse einer Multicastadresse der MAC-Ebene zugeordnet werden soll, werden die 32 niedrigwertigen Bits der IPv6-Multicastadresse den 32 niedrigwertigen Bits in der Multicastadresse der MAC-Ebene direkt zugeordnet. Abbildung A-5 zeigt die Zuordnung einer IPv6-Multicastadresse zu einer Ethernet-Multicastadresse.  Abbildung A-5: Zuordnen von IPv6-Multicastadressen zu Ethernet-Multicastadressen Beispiel: | • | Die Multicastadresse FF02::1 für alle Knoten im Link-Local-Bereich wird der Ethernet-Multicastadresse 33-33-00-00-00-01 zugeordnet. | | • | Die Beispieladresse FF02::1:FF3F:2A1C des angeforderten Knotens wird der Ethernet-Multicastadresse 33-33-FF-3F-2A-1C zugeordnet. |
Empfohlene IPv6-MulticastadressenAufgrund der Art und Weise der Zuordnung von IPv6-Multicastadressen zu Ethernet-Multicast-MAC-Adressen empfiehlt RFC 3513, die Gruppen-ID der 32 niedrigwertigen Bits der IPv6-Multicastadresse zuzuordnen und die übrigen ursprünglichen Bits des Feldes "Group ID" auf 0 festzulegen. Wenn nur die 32 niedrigwertigen Bits verwendet werden, wird jede Gruppen-ID einer eindeutigen Ethernet-Multicast-MAC-Adresse zugeordnet. Verwaltung der Mitgliedschaft im MulticastsubnetzFür die Gruppenmitgliedschaft im Multicastsubnetz verwenden IPv4-Knoten IGMP und IPv6-Knoten MLD. IGMP für IPv4Zur Verwaltung der Subnetz-Hostmitgliedschaft in IPv4-Multicastgruppen verwenden Router und Hosts das Protokoll IGMP. IGMP-Nachrichten haben folgende Formen: | • | Wenn ein Host einer Hostgruppe beitritt, sendet er eine IGMP-Hostmitgliedschaftsbericht-Nachricht an die IPv4-Multicastadresse (224.0.0.1) für alle Hosts oder an die festgelegte IPv4-Multicastadresse und deklariert seine Mitgliedschaft in einer bestimmten Hostgruppe durch Verweis auf die IPv4-Multicastadresse. | | • | Wenn ein Router ein Netzwerk abfragt, um sicherzustellen, dass sich dort Mitglieder einer bestimmten Hostgruppe befinden, sendet er eine IGMP-Hostmitgliedschaftsabfrage-Nachricht an die IPv4-Multicastadresse für alle Hosts. Wenn nach mehreren Abfragen keine Antworten auf die Abfrage empfangen werden, geht der Router davon aus, dass die Gruppe für das betreffende Netzwerk keine Mitglieder enthält, und stoppt die Bekanntgabe dieser Gruppen-Netzwerkinformationen an andere Router. | | • | Wenn ein Host eine IPv4-Multicastgruppe verlässt und festgestellt hat, dass er das letzte Mitglied dieser Gruppe in dem Subnetz ist, sendet er eine IGMP-Nachricht, dass er die Gruppe verlassen hat. |
Die Internet Protocol (TCP/IP)-Komponente in Windows Server 2003 und Windows XP unterstützt IGMP, IGMP Version 2 (IGMP v2) und IGMP Version 3 (IGMP v3). Es ist nicht erforderlich, IGMP zu konfigurieren, damit ein Windows-Computer alle drei Versionen von IGMP verwendet. IGMP ist in RFC 1112 definiert. IGMP v2 ist in RFC 2236 definiert, IGMP v3 in RFC 3376. MLD für IPv6MLD ist die IPv6-Entsprechung für IGMP v2 für IPv4. MLD besteht aus einer Reihe von ICMPv6-Nachrichten, die von Routern und Knoten ausgetauscht werden und mit deren Hilfe Router die Multicastadressen entdecken können, für die es an den einzelnen verbundenen Schnittstellen empfangsbereite Knoten gibt. Ebenso wie IGMPv2 entdeckt MLD nur die Liste der Multicastadressen, für die es mindestens einen Listener gibt, jedoch nicht die Liste einzelner Multicastlistener für jede Multicastadresse. MLD ist in RFC 2710 beschrieben. Es gibt drei Arten von MLD-Nachrichten: | • | Wenn ein Host einer Hostgruppe beitritt, sendet er eine MLD-Multicast-Listener-Bericht-Nachricht an die entsprechende IPv6-Multicastadresse und deklariert seine Mitgliedschaft in einer bestimmten Hostgruppe. | | • | Wenn ein Router ein Netzwerk abfragt, um sicherzustellen, dass sich dort Mitglieder einer bestimmten Hostgruppe befinden, sendet er eine MLD-Multicast-Listener-Bericht-Nachricht an die IPv6-Multicastadresse (FF02::1) für alle Hosts im Link-Local-Bereich. | | • | Wenn ein Host eine IPv6-Multicastgruppe verlässt und festgestellt hat, dass er das letzte Mitglied dieser Gruppe in dem Subnetz ist, sendet er eine MLD-Multicast-Listener-Done-Nachricht. |
In Tabelle A-1 sind die IGMPv2-Nachrichten und die MLD-Entsprechungen aufgeführt. |
Hostmitgliedschaftsbericht | Multicast-Listener-Bericht | Hostmitgliedschaftsabfrage | Multicast-Listener-Abfrage | Leave Group | Multicast Listener Done |
Unterstützung der IPv4-Multicastweiterleitung unter Windows Server 2003Die Multicastweiterleitung unter Windows Server 2003 umfasst folgende Komponenten: | • | IPv4-Multicastweiterleitung durch die Internet Protocol (TCP/IP)-Komponente | | • | Die IGMP-Routingprotokollkomponente für Routing und RAS |
IPv4-MulticastweiterleitungUnter Windows wird die IPv4-Multicastweiterleitung durch die Internet Protocol (TCP/IP)-Komponente unterstützt. Von der Version 6 der Microsoft-TCP/IP-Komponente wird die IPv6-basierte Multicastweiterleitung nicht unterstützt. Die IPv4-Multicastweiterleitung wird aktiviert, wenn Sie Routing und RAS konfigurieren und aktivieren. Die Internet Protocol (TCP/IP)-Komponente verwaltet eine IPv4-Multicast-Weiterleitungstabelle, die im Snap-In Routing und RAS oder mithilfe des Befehls netsh routing ip show mfe angezeigt werden kann. IGMP-RoutingprotokollkomponenteDa von Windows Server 2003 keine Multicastroutingprotokolle bereitgestellt werden, ist die Verwaltung von Einträgen in der IPv4-Multicast-Weiterleitungstabelle eine Funktion von IGMP, einer Komponente, die als IPv4-Routingprotokoll hinzugefügt wird. Gehen Sie folgendermaßen vor, um die IGMP-Routingprotokollkomponente hinzuzufügen: 1. | Klicken Sie auf Start und anschließend auf Systemsteuerung. Doppelklicken Sie auf Verwaltung und dann doppelt auf Routing und RAS. | 2. | Öffnen Sie Routing und RAS in der Konsolenstruktur, klicken Sie auf den Namen des Servers und dann auf IP-Routing. | 3. | Klicken Sie in der Konsolenstruktur mit der rechten Maustaste auf Allgemein, und klicken Sie anschließend auf Neues Routingprotokoll. | 4. | Klicken Sie im Dialogfeld Routingprotokoll auswählen auf IGMP-Router und -Proxy und anschließend auf OK. |
Je nach den Einstellungen, die Sie im Setup-Assistenten für den Routing- und RAS-Server gewählt haben, wurde die IGMP-Routingprotokollkomponente eventuell bereits hinzugefügt. Zwar bietet die IGMP-Routingprotokollkomponente einige begrenzte Möglichkeiten, multicastfähige IPv4-Netzwerke zu erstellen oder zu erweitern, allerdings ist sie keine vollwertige Entsprechung für ein Multicastroutingprotokoll wie DVMPRP oder PIM. Es wird nicht empfohlen, sie zur Erstellung eines multicastfähigen IPv4-Netzwerks beliebiger Größe oder Topologie zu verwenden. Nachdem das IGMP-Routingprotokoll hinzugefügt wurde, müssen Sie auf folgende Weise Routerschnittstellen hinzufügen: 1. | Klicken Sie auf Start und anschließend auf Systemsteuerung. Doppelklicken Sie auf Verwaltung und dann doppelt auf Routing und RAS. | 2. | Öffnen Sie Routing und RAS in der Konsolenstruktur, klicken Sie auf den Namen des Servers und dann auf IP-Routing. | 3. | Klicken Sie in der Konsolenstruktur mit der rechten Maustaste auf IGMP, und klicken Sie anschließend auf Neue Schnittstelle. | 4. | Klicken Sie unter Schnittstellen auf die zu aktivierende Schnittstelle, und klicken Sie dann auf OK. | 5. | Überprüfen Sie im Dialogfeld IGMP-Eigenschaften für die Schnittstelle auf der Registerkarte Allgemein, ob das Kontrollkästchen IGMP aktivieren aktiviert ist. | 6. | Klicken Sie unter Modus auf IGMP-Router oder auf IGMP-Proxy. Wählen Sie unter IGMP-Protokollversion die in Ihrem Netzwerk verwendete IGMP-Version aus. | 7. | Klicken Sie auf OK. |
Abbildung A-9 zeigt die Registerkarte Allgemein für die Eigenschaften einer IGMP-Schnittstelle.  Abbildung A-9: Registerkarte "Allgemein" für die Eigenschaften einer IGMP-Schnittstelle Wenn Sie im Snap-In Routing und RAS eine Schnittstelle zur IGMP-Routingprotokollkomponente hinzufügen, müssen Sie für die Schnittstelle einen der folgenden Modi konfigurieren: | • | IGMP-Routermodus | | • | IGMP-Proxymodus |
IGMP-RoutermodusWenn eine IGMP-Routingprotokollschnittstelle im IGMP-Routermodus konfiguriert ist, führt sie die folgenden Funktionen aus: | • | Sie ist im gemischten Multicastmodus empfangsbereit. | | • | Sie ist empfangsbereit für IGMP-Hostmitgliedschaftsbericht-Nachrichten und Nachrichten bezüglich des Verlassens der Gruppe. | | • | Sie sendet IGMP-Hostmitgliedschaftsabfragen. | | • | Sie verwaltet Einträge in der IPv4-Multicast-Weiterleitungstabelle. |
Der IGMP-Routermodus kann auf mehreren Schnittstellen aktiviert werden. Für jede Schnittstelle kann eine bestimmte Version von IGMP konfiguriert werden. Die Standardversion ist IGMP v3. IGMP-ProxymodusWährend der IGMP-Routermodus den Zweck hat, dass die IGMP-Schnittstelle als Multicastrouter fungiert, hat der IGMP-Proxymodus den Zweck, dass die IGMP-Schnittstelle an Schnittstellen, für die der IGMP-Routermodus aktiviert ist, als Multicastproxy für Hosts fungiert. Wenn eine IGMP-Routingprotokollschnittstelle im IGMP-Proxymodus konfiguriert ist, führt sie die folgenden Funktionen aus: | • | Sie leitet IGMP-Hostmitgliedschaftsabfragen weiter. Alle IGMP-Hostmitgliedschaftsberichte, die über Schnittstellen im IGMP-Routermodus empfangen wurden, werden über die Schnittstelle im IGMP-Proxymodus erneut übertragen. | | • | Sie registriert MAC-Multicastadressen Bei Technologien für den gemeinsamen Zugriff wie Ethernet bleibt der Netzwerkadapter im Empfangsmodus Unicast. Für jede eindeutige Gruppe, die von IGMP-Hostmitgliedschaftsberichten registriert wurde, die über die Schnittstelle im IGMP-Proxymodus weitergeleitet werden, wird der Netzwerkadapter so programmiert, dass er Frames mit der entsprechenden MAC-Multicastadresse weiterleitet. Jede zusätzliche MAC-Multicastadresse ist ein Eintrag in der Tabelle zu verwendender MAC-Zieladressen auf dem Netzwerkadapter. Auf jedem Netzwerkadapter kann ein bestimmtes Maximum an Einträgen gespeichert werden. Wenn dieses Maximum erreicht ist, aktiviert das IGMP-Routingprotokoll auf dem Netzwerkadapter den gemischten Multicastempfangsmodus. | | • | Sie fügt Einträge zur IPv4-Multicast-Weiterleitungstabelle hinzu. Wenn auf einer Schnittstelle im IGMP-Routermodus nichtlokaler Multicastverkehr empfangen wird, fügt das IGMP-Routingprotokoll einen Eintrag zur Multicast-Weiterleitungstabelle hinzu bzw. aktualisiert einen solchen Eintrag, um den Multicastverkehr über die Schnittstelle im IGMP-Proxymodus weiterzuleiten. Dieser Prozess führt schließlich dazu, dass jeglicher nichtlokaler Multicastverkehr, der über Schnittstellen im IGMP-Routermodus empfangen wird, zur Schnittstelle im IGMP-Proxymodus gelenkt oder kopiert wird. | | • | Sie empfängt Multicastverkehr, der über Schnittstellen im IGMP-Proxymodus empfangen wird. Multicastverkehr, der über die Schnittstelle im IGMP-Proxymodus empfangen wird, die den Gruppen entspricht, die von Hosts über Schnittstellen im IGMP-Routermodus registriert werden, wird mithilfe von IP und der Multicast-Weiterleitungstabelle an die entsprechenden Schnittstellen weitergeleitet. |
Der IGMP-Proxymodus hat die Funktion, einen Windows Server 2003-Router mit einem multicastfähigen IPv4-Netzwerk zu verbinden, beispielsweise den Multicastbackbone des IPv4-Internets (MBone) oder eines privaten Intranets, das Multicastroutingprotokolle wie DVMRP und PIM verwendet. Abbildung A-7 zeigt ein Beispiel für die Verwendung des IGMP-Routermodus und des IGMP-Proxymodus zur Verbindung eines kleinen Büronetzwerks mit dem MBone.  Abbildung A-7: Verwenden des IGMP-Proxymodus zur Verbindung eines kleinen Büronetzwerks mit dem MBone Die Schnittstelle im IGMP-Proxymodus fungiert als Host und verbindet Hostgruppen für Hosts an ihren Schnittstellen im IGMP-Routermodus. Multicastverkehr, der an Hostmitglieder an Schnittstellen im IGMP-Routermodus gesendet wird, wird an der Schnittstelle im IGMP-Proxymodus empfangen und von der Internet Protocol (TCP/IP)-Komponente weitergeleitet. Multicastverkehr, der von Hosts an Schnittstellen im IGMP-Routermodus gesendet wird, wird zur Schnittstelle im IGMP-Proxymodus gelenkt. Dort können nachgelagerte IPv4-multicastfähige Router den Verkehr entweder weiterleiten oder ignorieren. Der IGMP-Proxymodus kann nur auf einer einzelnen Schnittstelle mit IGMP-Routingprotokoll aktiviert werden. Die richtige Schnittstelle für den IGMP-Proxymodus ist diejenige, die mit einem Subnetz verbunden ist, das einen Multicastrouter enthält, auf dem Multicastroutingprotokolle ausgeführt werden. Das bedeutet, dass die Schnittstelle im IGMP-Proxymodus auf das multicastfähige Intranet "zeigt". Zuordnung von IPv4-Multicastadressen mit MADCAPDas Multicast Address Dynamic Client Allocation Protocol (MADCAP) ist ein in RFC 2730 definierter Internetstandard für die Zuordnung von Multicastadressen. Der Hauptvorteil von MADCAP liegt darin, dass IPv4-Multicastadressen mithilfe der vorhandenen DHCP-Infrastruktur von Windows auf die gleiche Weise zugewiesen werden können wie IPv4-Unicastadressen. Bei der Zuordnung von Multicastadressen werden die folgenden Komponenten verwendet: | • | MADCAP-Server IPv4-Multicastadressen werden von MADCAP-Servern zugeordnet. Für Windows handelt es sich bei einem MADCAP-Server um einen Computer, auf dem Windows Server 2003 und der DHCP-Dienst ausgeführt werden. Wenn Sie das DHCP-Snap-In verwenden, müssen Sie mindestens einen Multicastbereich konfigurieren und aktivieren. | | • | MADCAP-Clients MADCAP-Clients verwenden MADCAP zur Anforderung von IPv4-Multicastadressen von einem MADCAP-Server. Sowohl Windows Server 2003 als auch Windows XP unterstützen eine MADCAP-Anwendungsprogrammierschnittstelle (Application Programming Interface, API). Daher können Anwendungen mithilfe von MADCAP eine eindeutige IPv4-Multicastadresse von einem MADCAP-Server anfordern, erneuern oder freigeben lassen. |
Ein Beispiel für eine MADCAP-Clientanwendung ist ein Videokonferenzserver, der über MADCAP eine eindeutige Multicastadresse empfängt und diese Adresse anschließend an Videoclients weitergibt, die eine Verbindung mit dem Server herstellen. Nach der Aushandlung der Verbindung ist der Videoclientcomputer an der IPv4-Multicastadresse für den Videodatenstrom empfangsbereit. Verwenden von MulticastbereichenBei einem Multicastbereich handelt es sich um einen auf dem MADCAP-Server konfigurierten Bereich von IPv4-Multicastadressen, die von diesem Server anfordernden MADCAP-Clients zugewiesen werden. Die beiden folgenden Multicastadressbereiche werden zur Verwendung als Multicastbereiche auf dem MADCAP-Server empfohlen: | • | Multicastadressen für den administrativen Bereich liegen im Bereich 239.192.0.0/14 (von 239.192.0.1 bis 239. 255.255.255) und sind für Organisationen vorgesehen, die Multicastbereiche privat für interne Zwecke verwenden. Multicastadressen dieser Art werden in RFC 2365 detailliert beschrieben. | | • | Multicastadressen für den globalen Bereich liegen im Bereich 233.0.0.0/8 (von 233.0.0.1 bis 233. 255.255.255) und sind für Organisationen vorgesehen, die Multicastbereiche im Internet verwenden. Innerhalb des Bereichs 233.0.0.0/8 sind das zweite und dritte Oktett für die AS-Nummer (Autonomous System) vorgesehen, die der Organisation durch eine Internet Assigned Numbers Authority (IANA)-Registrierung zugewiesen wird. Mit dem letzten Oktett wird die Multicastgruppe identifiziert. Weitere Informationen zur AS-Nummerierung finden Sie in RFC 1930. |
Der Windows Server 2003-Dienst DHCP-Server unterstützt sowohl DHCP als auch MADCAP. Diese Protokolle funktionieren unabhängig von einander. Wenn Sie einen Server konfigurieren möchten, der nur DHCP verwendet, konfigurieren Sie DHCP-Bereiche, jedoch keine Multicastbereiche. Wenn Sie einen Server konfigurieren möchten, der nur MADCAP verwendet, konfigurieren Sie Multicastbereiche und keine DHCP-Bereiche. Gehen Sie folgendermaßen vor, um auf einem Computer, auf dem Windows Server 2003 und der Dienst DHCP-Server ausgeführt werden, einen Multicastbereich zu erstellen: 1. | Klicken Sie auf Start, Einstellungen, Systemsteuerung, doppelklicken Sie auf Verwaltung und dann auf DHCP. | 2. | Klicken Sie in der Konsolenstruktur auf den entsprechenden DHCP-Server. | 3. | Klicken Sie im Menü Aktion auf Neuer Multicastbereich. | 4. | Folgen Sie den Anweisungen des Assistenten zum Erstellen von Multicastbereichen. |
Der Assistent zum Erstellen von Multicastbereichen führt Sie durch die Konfiguration des Multicastadressbereichs, von Ausschlüssen, der Leasedauer und der Bereichsaktivierung. Reliable Multicast mit Pragmatic General Multicast (PGM)Multicastdatenströme werden in der Regel unter Verwendung des User Datagram Protocol (UDP) gesendet. Transmission Control Protocol (TCP) wird nicht verwendet, da dieses Protokoll für 1:1-Unicastdatenströme vorgesehen ist. Über UDP gesendete Multicastdatenströme sind generell unzuverlässig, da UDP keine Übermittlung oder erneute Übertragung verloren gegangener Pakete garantiert. Verloren gegangene Pakete in UDP-Multicastdatenströmen können nur dann erkannt oder wiederhergestellt werden, wenn das Protokoll der oberen Ebene für eine zuverlässige Übertragung sorgt. Die Arbeitsgruppe "Reliable Multicast Transport" der Internet Engineering Task Force (IETF) hat verschiedene Standards für die zuverlässige Übertragung von Multicastdatenströmen von einem oder mehreren Absendern an mehrere Empfänger festgelegt. Es gibt viele Protokollstandards, die für eine zuverlässige Multicastübertragung auf der Transport- oder Anwendungsebene sorgen. Die vorhandenen Multicastprotokolle gehören den vier folgenden Kategorien an: 1. | Nur negative Bestätigung (Negative Acknowledgement, NACK) Empfänger senden NACK-Pakete, um vom Absender die erneute Übertragung von Paketen anzufordern, die im Multicastdatenstrom fehlen. Nur-NACK-Protokolle erfordern keine zusätzliche Unterstützung durch Router im Netzwerk. | 2. | Strukturbasierte Bestätigung (ACK) Empfänger geben in positiven Bestätigungen Multicastpakete an, die erfolgreich empfangen werden. | 3. | Asynchrone Schichtcodierung (Asynchronous Layered Coding, ALC) Die Absender übernehmen die Korrektur von Weiterleitungsfehlern (Forward Error Correction, FEC), ohne dass die Empfänger oder Router im Netzwerk Nachrichten senden. | 4. | Routerunterstützung Die Empfänger senden NACK-Pakete. Router im Netzwerk unterstützen durch die erneute Übertragung verloren gegangener Pakete. |
PGM im ÜberblickPGM ist ein zuverlässiges Multicastprotokoll vom Typ "Router Assist", das in RFC 3208 beschrieben ist. PGM-fähige Empfänger verwenden NACK-Pakete, um die erneute Übertragung fehlender Pakete anzufordern. PGM-fähige Router in einem Netzwerk definieren eine logische PGM-Topologie und ermöglichen die Wiederherstellung verloren gegangener Pakete, indem sie sie für den Absender senden. Die PGM-Topologie wird über die physische IPv4-Netzwerktopologie gelegt. PGM-Router definieren eine Reihe von PGM-Hops zwischen einem Absender und dessen Empfängern. Obwohl PGM-Router in RFC 3208 definiert sind, werden sie nicht benötigt. Die PGM-Topologie eines Netzwerks kann aus einem einzigen logischen Hop zwischen dem Absender und den Empfängern bestehen. PGM bietet bei Multicastdatenströmen nicht alle Fähigkeiten wie TCP. PGM verfügt z. B. nicht über eine Flusssteuerung auf Absender- oder Empfängerseite, über eine Datenstromfenstersteuerung oder Überlastungssteuerung. PGM bietet grundlegende Zuverlässigkeit für PGM-fähige Anwendungen. PGM ist ein Multicastprotokoll der Transportschicht, das mithilfe der Protokollnummer 113 direkt über IPv4 ausgeführt wird. Für eigene Nachrichten oder für die Multicastdatenübertragung wird weder TCP noch UDP verwendet. PGM ist das einzige zuverlässige Multicastprotokoll, das von Windows Server 2003 unterstützt wird. Hinzufügen und Verwenden des Reliable Multicast-ProtokollsWenn Sie PGM auf Computern unter Windows Server 2003 verwenden möchten, müssen Sie die Komponente Reliable Multicast-Protokoll hinzufügen und PGM-fähige Anwendungen erstellen. Hinzufügen Reliable Multicast-ProtokollsFühren Sie die folgenden Schritte aus, um das Reliable Multicast-Protokoll zu einer Verbindung hinzuzufügen: 1. | Klicken Sie auf Start und dann auf Systemsteuerung. Doppelklicken Sie anschließend auf Netzwerkverbindungen. | 2. | Klicken Sie unter Netzwerkverbindungen mit der rechten Maustaste auf die Verbindung, und klicken Sie dann auf Eigenschaften. | 3. | Klicken Sie im Dialogfeld für die Verbindungseigenschaften auf Installieren. | 4. | Doppelklicken Sie unter Netzwerkkomponententyp auswählen auf Protokoll. | 5. | Klicken Sie in der Liste Netzwerkprotokoll auf Reliable Multicast-Protokoll und anschließend auf OK. | 6. | Wenn Sie die Änderungen an den Verbindungseigenschaften speichern möchten, klicken Sie auf Schließen. |
Die Komponente Reliable Multicast-Protokoll wird in der Liste der von der Verbindung verwendeten Elemente angezeigt, hat jedoch keine konfigurierbaren Eigenschaften. Schreiben von PGM-fähigen AnwendungenDamit PGM verwendet werden kann, muss eine Anwendung Windows Sockets und die PGM-Socketoptionen verwenden. Absenderanwendungen verwenden Windows Sockets zur Erstellung eines PGM-Sockets, zum Binden des Sockets an eine beliebige Adresse und zum Herstellen einer Verbindung mit der Adresse der Multicastgruppe. Empfängeranwendungen verwenden Windows Sockets, um ein PGM-Socket zu erstellen, das Socket an die Adresse der Multicastgruppe zu binden, das neue Socket abhören zu lassen und anschließend mithilfe der Funktion accept() einen Sockethandle für die PGM-Sitzung zu beziehen. Microsoft-Produkte, in denen PGM verwendet wird, sind z. B. Message Queuing (auch MSMQ genannt) und Automatisierte Bereitstellungsdienste (Automated Deployment Services, ADS). Funktionsweise von PGM und Reliable Multicast-ProtokollEin Empfänger verwendet folgendes Verfahren: 1. | Die Multicastanwendung öffnet ein Abhörsocket mit den entsprechenden Socketoptionen für Reliable Multicast. | 2. | Der Empfänger sendet eine IGMP-Hostmitgliedschaftsbericht-Nachricht, um die lokalen Router über die Mitgliedschaft des Empfängers in der Multicastgruppe zu informieren. |
Ein Absender verwendet folgendes Verfahren: | • | Die Multicastanwendung öffnet ein Sendesocket mit den entsprechenden Socketoptionen für Reliable Multicast. | | • | Die Multicastanwendung beginnt mit dem Senden der Daten. PGM-Pakete, die Daten enthalten, werden beginnend mit der Sequenznummer 0 gesendet, die bei nachfolgenden Paketen jeweils um 1 inkrementiert wird. | | • | Die multicastfähigen Router leiten die Multicastdatenpakete durch das gesamte IPv4-Netzwerk an die Subnetze weiter, in denen sich Gruppenmitglieder befinden. |
Wenn ein Empfänger feststellt, dass ein Paket fehlt, sendet er eine PGM-Nachricht an den nächsten PGM-Router und verlangt, dass das fehlende Paket mit einer bestimmten Sequenznummer erneut gesendet wird. Diese Anforderung wird entweder an die ursprüngliche Quelle oder an einen PGM-Router weitergeleitet, auf dem Kopien von Paketen gespeichert sind, die vor kurzem von der Quelle gesendet wurden. In beiden Fällen wird das fehlende Paket direkt an den anfordernden Empfänger gesendet.
| |
