IGMP und MLD wird zwischen dem Endsystem

Transkript

1 1 Internet Group Management Protocol IGMP / Multicast Listener Discovery MLD Bincheng Zhu(56398) Student im Master Elektrotechnik/Informationstechnik Zusammenfassung Dieser Bricht beschreibt die Eingenschaften und die internen Mechanismen vom IGMP und MLD. Internet Group Management Protokoll (IGMP) und Multicast Listener Discovery (MLD) sind die Multicast Group Membership Discovery (MGMD) Protokolle. Sie haben essentiell die gleichen Funktionen erreicht, wie die IGMP für IPv4 Multicast Gruppen und MLD für IPv6 Multicast Gruppen arbeiten. [1] Index Terms Internet, Multicast, IP-Schicht, IGMPv1, IGMPv2, IGMPv3, MLDv1, MLDv2 I. ÜBERSICHT IGMP und MLD wird zwischen dem Endsystem und Multicast Router benutzt. Die Multicast-Routing- Protokolle (Beispiel PIM) übernehmen die Koordination der Übertragung zwischen den Routern. Es gibt drei Versionen von IGMP und 2 Versionen von MLD. Sie arbeiten in IP-Schicht. IGMP : IGMPv1, IGMPv2,IGMPv3 MLD : MLDv1, MLDv2 Alle IGMP Versionen und MLD Versionen können auf der Basis von ASM arbeiten. IGMPv3 und MLDv2 können direkt von SSM benutzt werden. MLDv1 ist ähnlich wie IGMPv2, MLDv2 ist ähnlich wie IGMPv3. IGMP- Pakete werden in IP-Datagramme gekapselt und benutzten die IP-Protokollnummer 2. [2] Die MLD-Pakete sind eingebettet in ICMPv6. ((siehe Abbildung 1)). Abbildung 2: Multicast. Wenn sich ein Endsystem in eine Multicast Gruppe anschließt, dann wird in LAN ein pseudo MAC Adresse bzw. IPv4- oder IPv6-Multicast-Adressen eingegeben. Für IPv4 ist es die Multicast-Adresse. Die Adresse gehört zu diesen Endsystemen der Multicast Gruppe. Die Multicast-Informationen werden an die Empfänger gesendet, die für diese bestimmte MAC-Adresse genannt werden. Bei der Übertragung über Ethernet werden die IPv4- oder IPv6-Multicast-Adressen auf bestimmte Pseudo-MAC-Adressen abgebildet.((siehe Abbildung 3)). A. Multicast Abbildung 1: Lokation der Protokolle. Das Multicast ermöglicht effiziente Pakete in IP- Netzwerken an viele Empfänger gleichzeitig zu senden [3], die Empfänger können zu verschiedenen Subnetzwerken gehören. nachfolgende Abbildung soll das erklären.((siehe Abbildung 2)). Abbildung 3: IPv4 zu Mac Adresse. Die Multicast-Adresse von IPv6 wird die Abbildung 4 abgebildet:. B. Multicast Service Modell Wenn eine Multicast-Source die Datei gesendet hat, ist die Source-Adresse die Adresse von Multicast-Source (normalerweise befindet sich der Multicast-Source

2 2 Abbildung 4: IPv6 Multicast-Adresse. nicht bei der Multicast-Gruppe). Die Bestimmungs- Adresse ist die Multicast-Adresse. Die Empfänger können die Multicast-Source wählen. Dann werden zwei verschiedene Multicast Service Modelle erstellt: ASM und SSM. Sie haben unterschiedliche Adressen. Bei IPv4 ist der ASM für , und SSM für Das ASM verteilt die Datei an jedes Mitglied der Multicast- Gruppe. Wenn ein Empfänger an einer Gruppe des SSM teilgenommen hat, kann er die ungewünschte Multicast- Source filtern. II. PROTOKOLLMECHANISMEN VON IGMPV1 IGMPv1-Pakete haben eine Größe von 64 Bit. Folgendes Folmat wird verwendet:((siehe Abbildung 5)). Abbildung 5: Struktur von IGMPv1. IGMPv1 ist die Basis von Query und Response, um die Multicast-Gruppe zu verwalten. T yp = 0x1 allgemeine Anfrage T yp = 0x2 Report Multicast Gruppenadresse = 0x0 bei der Anfrage Multicast-Gruppenadresse=die Multicastadresse vom Host, beim Report Query (allgemeine Anfrage): Querier sendet allgemeine Query periodisch an alle Hosts und Router (normalerweise je 60s; kann eingestellt werden), die mit ihm direkt verbinden, um zu erkennen, ob es bei ihm ein Multicast-Gruppe-Mitglied gibt. Report: Der Host sendet diese Information an Querier, an einer Multicast-Gruppe teilzunehmen oder um Query zu antworten. Wie die Grafik 6 zeigt,gibt es in einen Subnetz 2 Multicast-Router, aber man braucht nur ein Router als Querier, um Query zu senden. In IGMPv1 wird von PIM (Protokol Independent Multicast, ähnlich wie die Routing Protokol in Unicast) ausgewählt. Falls Router A Querier ist, gibt es 3 Empfänger A,B,C. A,B sind Mitglieder der Multicast-Gruppe G1. C gehört zu G2. Querier sendet generell Query, die Ziel-Adresse ist (Alle Hosts im gleichen Netzwerk-Segment). Die Multicast-Mitglieder starten ihre Timer. Host-A und -B sind Timer-G1 und -C ist Timer-G2. Die Zeit des Timers ist zufällig und das Intervall der Zeit ist sec. Nach Timeout sendet der HostA (Beispiel vielleicht B) Report. B empfängt die Information und beendet sofort seinen Timer, diese Methode kann den Bit-fluss verringen, die Methode heißt IGMP Report Suppression. Router A hat die Information vom HostA erhalten, stellt die Multicast-Routing-Tabelle (*,G1) her oder behält *, das bedeutet beliebige Multicast-Source. Wenn die Dateien im Netzwerk die Multi- castgruppe-adresse als Ziel-Adresse enthält, empfangen diese HostA und HostB. Anschluss: Wenn HostC sich einer Multicastgruppe G2 anschließen will, sendet er den Report an Querier. Querier empfängt den Report und stellt die Multicast-Routing-Tablle (*,G2) her. Austreten: Wenn HostC von der Multicastgruppe G2 austreten will, bracht er nur das Query des Queriers zu ignorieren. Nach Timeout des Queriers hätte Querier noch nicht den Report, der Multi- castgruppe-adresse G2 erhalten. Dann streicht er (*,G2) aus. Aber wenn HostA von der Gruppe G1 austreten will, kann der Querier noch den Report von HostB bekommen, d.h der RouterA übergeht die Datei von G1. [] Abbildung 6: Beispiel III. PROTOKOLLMECHANISMEN VON IGMPV2/MLDV1 Folgendes Format wird von IGMPv2 und MLDv1 verwendet:((siehe Abbildung 7 und 8)).

3 3 Abbildung 7: IGMPv2. Abbildung 8: MLDv1. Die Mechanismen von IGMPv2/MLDv1 sind fast gleich wie IGMPv1 bzw. allgemeine Anfragen, Report und Anschluss. Aber sie geben 2 Befehle mehr als IGMPv1: Leave und Group-Specific Query. allgemeine Anfrage/gruppenspezifische Anfrage: IGMPv2 T yp = 0x11, MLDv1 T yp = 130; Mitgliedschaft anmelden/bestätigen: MLDv1 T yp = 131 IGMPv1 Mitgliedschaft anmelden/bestätigen: IGMPv2 T yp = 0x12; IGMPv2 Mitgliedschaft anmelden/bestätigen: IGMPv2 T yp = 0x16; Mitgliedschaft beenden: IGMPv2 Typ= 0x17, MLDv1 T yp = 132; MLDv1 Code = 1, als Sender, sonst Code = 0 [6]; Im Bitraum Maximale Antwortzeit können Hosts selbst die Antwortzeit nach ankommendem Query entscheiden. IGMPv2/MLDv1 können selbst den Querier bestätigen. Bei der Abbildung 5 sollen zuerst die RouterA und RouterB an alle Hosts und Router, die mit Ihm direkt verbinden, allgemeine Anfragen senden. RouterA und RouterB empfangen die Anfrage und vergleichen sie jeweils mit der IP-Adresse. Der Router, der die kleineste IP-Adresse enthält, ist der Querier. Die andere Router soll ein Timer starten; wenn sie Query vom Querier empfangen, dann starten sie den Timer neu. Sonst fangen sie noch einmal mit der Wahl an, um einen neuen Querier zu wählen. [6] Bei den IGMPv2/MLDv1 werden die Mitglieder der Multicastgruppe die Anfrage an Querier senden, wenn sie die Mitgliedschaft beenden wollen. In der Abbildung 5 finden sich die Hosts ABC. Host A hat die Leave- Reports an Querier zu senden. Wenn Querier die Anfrage erhalten hat, wird sofort die gruppenspezifische Anfrage an diese Multicastgruppe gesendet (hier ist G1). Dann empfängt HostB die Anfrage und antwortet auch sofort. Wenn Querier diese Information empfängt, hält er noch die Tabelle instand (*,G1), sonst wird (*,G1) weggelassen. Der Host kann bei den IGMPv2/MLDv1 schneller aus der die Multicastgruppe austreten und der Querier braucht nicht immer die allgemeine Anfrage zu senden um zu bestätigen. Die Belastung des Netzes und der Bitfluss werden verringert. IV. PROTOKOLLMECHANISMEN VON IGMPV3/MLDV2 IGMPv3/MLDv2 unterstützt die Funktion Source filtering und nicht nur das ASM Multicast Routing Protokoll, sonst SSM Multicast Routing Protokol. Der Host kann nämlich das Datagramm aus einem spezifischen Source bestätigen, wenn er sich für die Multicast-Source interessiert. Der Querier übergibt nur die Datagramme, die von den Hosts gewählt werden. IGMPv3/MLDv2 hat 3 verschiedene Anfragen: allgemeine Anfrage: Querier sendet die Anfrage zu /FF02::1 beim IGMPv3/MLDv2; gruppespezifische Anfrage; Source- und gruppespezifische Anfrage: Der Querier erkundigt sich durch diese Anfrage bei den Hosts, ob jemand bei einer spezifischen Gruppe die Datagramme der spezifischen Source empfangen will. Die Hosts der spezifischen Gruppe empfangen diese Anfrage und senden den Report an den Querier. Der Report enthält nicht nur die Multicastgruppe-Adresse der Hosts, sondern auch die Multicast-Source-Adressen, die von den Hosts erwartet werden. IGMPv3/MLDv2 hat die Filter- Modelle Include und Exclude, um obige Funktion zu realisieren. Der Zusammenhang von Multicastgruppen und Source-Listen lässt sich also als (G, INCLUDE, (S1,S2... )); (G, EXCLUDE, (S1,S2... )) bezeichnen. (G, INCLUDE, (S1,S2... )) bedeutet der Host kann nur die Datagramme aus den Multicast-Sourcen S1, S2 empfangen und diese Datagramme werden zu Multicastgruppe G gesendet. (G, EXCLUDE, (S1,S2... )) bedeutet der Host muss die Datagramme aus den Multicast-Sourcen S1, S2 nicht empfangen; diese Datagramme werden zu Multicastgruppe G gesendet.[4] Wenn der Zusammenhang von Multicastgruppen und Source-Listen sich verändert, werden die Veränderungen in Gruppe-Record beim Report gespeichert und an den Querier gesendet. Dann aktualisiert der Querier die Multicastsource-Liste für die Multicastgruppe. Form der Anfrage von den IGMPv3/MLDv2((siehe Abbildung 9)[5] [7]). Abbildung 9: Anfrage von den IGMPv3/MLDv2

4 4 S = 1, die non-querier werden das Datagramm ignorieren. QRV, maximale Zahl=7, die Anzahl beeinflusst die Anzahl des Timers von anderen Routern. QQIC, die Zeitintervalle von jedem Query Bei MLDv2 ist die Prüfungsnummer ICMPv6- Prüfungsnummer Multicast-Gruppenadresse: eine spezifische Multicastgruppe in dem Netz-Segment Source Adresse: welche Multicast-Source werden an die spezifische Multicastgruppe die Datagramme gesendet. Form der Anfrage von den IGMPv3/MLDv2((siehe Abbildung 10[5] [7] )). Abbildung 10: Reports von den IGMPv3/MLDv2 Form des Gruppen-Record((siehe Abbildung 11[5] [7] )). Abbildung 11: Gruppen-Record von den IGMPv3/MLDv2 Es gibt 3 unterschiedliche Record Typen: Aktueller Zustand Record: MODE_IS_INCLUDE/ MODE_IS_EXCLUDE,die Hosts in der spezifischen Multicastgruppe empfangen nur/nicht die Datagramme aus den Source-Adressen im Teil Multicast-Source-Adresse. Normalerweise antworten die Hosts durch den Typ dem Querier über ihren Zustand. Filter-Modell-Veränderung Record: CHANGE_TO_INCLUDE_MODE/ CHANGE_TO_EXCLUDE_MODE, das Filter- Modell wechselt von EXCLUDE in INCLUDE / von INCLUDE in EXCLUDE. Source-Liste- Veränderung Record: ALLOW_NEW_SOURCES: wenn die Hosts neue Multicast-Source-Adresse hinzufügen wollen, in der INCLUDE_Liste wird diese Multicast-Source-Adresse addiert, in der EXCLUDE_Liste wird diese Multicast- Source-Adresse subtrahiert. BLOCK_OLD_SOURCES : wenn die Hosts Multicast-Source-Adressen reduzieren wollen, in der INCLUDE_Liste wird diese Multicast- Source-Adresse subtrahiert, in der EXCLUDE_Liste wird diese Multicast-Source-Adresse addiert. Die Ziel Adresse des Reports von den IGMPv3 Mitgliedern ist bzw. MLDv2 ist FF02:0:0:0:0:0:0:16. Diese Adresse bedeutet alle Router im gleichen Netzsegment, die IGMPv3 oder MLDv2 Router sind. Die Hosts können an die Multicastgruppen anschließen und in der gleichen Zeit die Multicast-Source bestätigen. Wenn der Zustand sich verändert (z.b. Source-Liste Veränderung), die Applikation wird die Funktion IPMulticastListen für IGMPv3 und IPv6MulticastListen für MLDv2 aufrufen. IPMulticastListen (socket, interface, multicast-address, filter-mode, source-list ) IPv6MulticastListen (socket, interface,ipv6-multicastaddress, filter-mode, source-list ) Jeder Multicastrouter hält eine MulticastListe für jede Schnittstelle in stand, um eine Multicastgruppe durch Multicast-Adressen anzuschließen und die Multicast- Source zu bestätigen. Danach stellt er den Report her. Dann teilt er ihren Zustand dem die Multicastrouter mit. Das Wort socket kann die Application unterscheiden. Austreten:Wenn ein Host von einer Multicast austreten will, stellt er den Record Typ als CHANGE_TO_INCLUDE_MODE und Multicast- Source-Adresse leer ein. Der Querier sendet sofort die gruppenspezifische Anfrage an diese Multicastgruppe sowie IGMPv2/MLDv1. [5] [7] V. BEWERTUNG Von der obigen Analyse, können wir vier Vorteile bekommen, b.z.w. die Verstärkung der Erweiterbarkeit vom Protokoll. Beim IGMPv2/MLDv1 können die Hosts sich freiwillig in die Multicastgruppe anschließen und schnell daraus austreten und beim IGMPv3/MLDv2 können die Host die gewunschte Informationen empfängen. Sonst können sie kompatibel mit früheren Versionen sein. Die Funktionen IGMP Report Suppression, spezifische Multicast-Source zu wählen und gruppenspezifische Anfragen können den Bit-Fluss im Netz verringern. VI. ZUSAMMENFASSUNG UND AUSBLICK die IGMP/MLD verwalten die Hosts und die Multicast-Router, die den Empfang von IP-Multicast unterstützen, um IPv4- und IPv6- Multicasting im Internet zu ermöglichen. Im IPv6 gibt es kein Broadcast mehr. Das jetzige IPMulticast ist die Basis des SSM Modells und sehr weit entwickelt. Aber die Multicastrouter sollen für jede Multicastgruppe eine Zustandstabelle erstellen und in stand halten. Diese kosten für den Router sehr viel Ressourcen. In Zukunft könnten die Multicasts in der Anwendungsschicht laufen, die Endsysteme spielen dann eine Rolle wie die jetzigen Router (Routing, Data übergeben usw.).

5 5 LITERATUR [1] [2] Management_Protocol. [3] [4] fileticket=qty8ebnqx6u%3d&tabid=11210& mid=11949&language=zh-cn. [5] B Cain, S Deering, I Kouvelas, B Fenner, and A Thyagarajan. Rfc3376. Internet Group Management Protocol, Version, 3, [6] William C Fenner. Internet group management protocol, version [7] R Vida and L Costa. Rfc Multicast Listener Discovery Version, 2, 2004.