Internet-ryhmänhallintaprotokolla

Internet Group Management Protocol ( IGMP ) on protokolla, jonka avulla IP- reitittimet voivat määrittää dynaamisesti,mitkä ryhmälähetysryhmät ovat asiakkaita aliverkossa .

IGMP: n käyttö

IGMP on epäsymmetrinen protokolla siinä mielessä, että isännöille määritetty käyttäytyminen eroaa monilähetysreitittimistä. Koska monilähetysreititin voi kuitenkin tilata ryhmälähetysryhmän aivan kuten isäntä, monilähetysreitittimien on suoritettava protokollan molemmat osat.

IGMP on protokolla, joka suoritetaan saman aliverkon isäntäkoneiden ja tämän aliverkon monilähetysreitittimien välillä. Sen avulla isäntäkone voi ilmoittaa yhdelle näistä ryhmälähetysreitittimistä nykyisistä ryhmälähetysryhmien tilauksista . Reitittimet ylläpitävät luetteloa ryhmälähetysryhmistä, joille isäntäkoneet ovat ilmoittaneet heille tilauksensa. Tällaista luetteloa ylläpidetään jokaiselle aliverkolle, jotka monilähetysreititin yhdistää, ja antaa reitittimen määrittää monilähetys-IP-paketit välittää näille aliverkoille. Monilähetys-IP-paketti välitetään aliverkkoon, jos tämän paketin kohdeosoite on jonkin tähän aliverkkoon liittyvän monilähetysryhmän osoite .

In IPv6 , toiminnot IGMP on ottanut haltuunsa Multicast Listener Discovery (MLD) -protokollaa, joka on yksi osa-protokollien ICMPv6 . Toiminnallisesti MLDv1 vastaa IGMPv2: ta ja MLDv2 on samanlainen kuin IGMPv3.

Monilähetysliikenteen lähde ei välttämättä ole ryhmän jäsen, joten se voi lähettää vuon ryhmälle ilman ennakko signalointia ja ilman IGMP: tä. Rajapinnalla reitittimet voivat pakottaa myös tyypin (*, G) tilauksen, toisin sanoen lähteestä riippumattoman, tai jopa minkä tahansa lähteen ryhmälähetyksen (ASM) tai (S, G) ( lähdekohtainen monilähetys , SSM) .

Kuinka IGMP toimii

IGMP: stä on useita versioita, jotka eroavat toisistaan ​​toiminnallisuudessa. Ainoa versio 3 on SSM-tyyppi.

Kaikki IGMP-versiot käyttävät IP-protokollanumeroa 2 ja asettavat Time to Live -kentän paketeiksi 1, mikä estää niiden leviämisen niiden aliverkon ulkopuolella, joita ne koskevat. Nykyiset versiot ovat versiot 2 ja 3.

IGMP v0

IGMPv0 on määritelty RFC  988: ssa, tätä versiota pidetään vanhentuneena.

IGMP v1

IGMPv1 on kuvattu standardissa RFC  1112.

On olemassa kahdenlaisia viestejä IGMPv1: jäsenyys kyselyn ja jäsenraportti .

Reititin, joka varmistaa monilähetyspakettien lähetyksen, toimii pyynnön tekijänä ( kyselylomakkeena ), toisin sanoen se lähettää pyyntöjä säännöllisin väliajoin (oletusarvoisesti 60 sekunnin välein).

Isännät vastaavat ilmoittamalla tilaamansa ryhmät raporttiin. Samanaikaisten vastausten tulvan välttämiseksi raportit lähetetään satunnaisella viiveellä (oletusarvoisesti 0-10 sekuntia). Jos isäntä saa tänä aikana toisen isännän raportin kyseisestä ryhmästä, sen tilausviesti poistetaan.

Ryhmää 224.0.0.1 ( kaikki isännät ) ei lähetetä .

Versio on 1. Tyyppi on 1 kyselylle ja 2 raportille.

Pyyntöjä varten kohdeosoite on 224.0.0.1 ( kaikki isännät ). Raporttien kohdekohteen IP-osoite on sama kuin sen ryhmän osoite.

Isäntä, joka haluaa liittyä ryhmään, lähettää raportin odottamatta pyyntöä.

IGMPv1: n rajoitukset

• Mikään viesti ei salli isännän ilmoittaa poistuvan ryhmästä. Pyynnön esittäjä voi siis määrittää, että ryhmällä ei ole enää jäseniä segmentissä, ennen kuin on kulunut aika, joka yleensä asetetaan kolminkertaiseksi pyyntöjen väliin (eli kolme minuuttia) ja jonka aikana tätä ryhmää koskevia raportteja ei vastaanoteta. Tämä voi aiheuttaa ongelmia nopeille monilähetysvirroille, mikä voi aiheuttaa aliverkon pääsyn ruuhkia, jos asiakas siirtyy nopeasti ryhmästä toiseen.
• RFC ei kerro, kuinka pyynnön tekijä valitaan, jos aliverkossa on useita ryhmälähetysreitittimiä.

IGMP v2

RFC  2236 kuvaa IGMP: n version 2. Tämä on IGMP: n suosituin versio yleisten käyttöjärjestelmien joukossa, ja sitä tukevat erityisesti Windows 98 ja Linux 2.4 -ydin .

Tämä korjaa joitain version 1 rajoituksia, lisätään:

• ryhmää koskeva pyyntö,
• mekanismi hakijan valitsemiseksi,
• vastauksen enimmäisviive ilmoitetaan pyynnössä,
• viestin poistua ryhmästä.

Tyyppi- kenttä sisältää IGMPv1- version kentän ja sallii tietyn tason taaksepäin yhteensopivuuden version 1 kanssa.

• Isäntä, joka tukee vain versiota 1, tulkitsee yleisen pyynnön, jonka tyyppi- arvo on 0x11, pyyntöviestinä. Ryhmäkohtainen pyyntö sisältää ryhmän osoitteen.
• Arvo tyyppi 0x12 käytetään taaksepäin yhteensopivuus, se on itse asiassa isäntä verrattuna version 1.
• Arvo 0x16 on raportti versiossa 2.
• Arvoa 0x17 ( loma ) käytetään ryhmästä poistumiseen.

Max Resp Time -kenttä ilmoittaa isännän vastaamisen enimmäisajan kymmenesekunnissa. Isännät käyttävät vastauksessa satunnaisviivettä tämän rajan alapuolella ja valinnaisesti poistavat raportit version 1 mukaisesti. Suurin viive on 100 (10 sekuntia) yleiselle pyynnölle ja 10 (1 sekunti) ryhmäkohtaiselle pyynnölle.

RFC: n mukaan isännän "  pitäisi  " lähettää lopetusviesti poistuttaessa ryhmästä, mikä tarkoittaa, että tämä viesti ei ole pakollinen. Tämä vaikeuttaa optimointia, kuten IGMP: n harhauttamista . Protokollatoteutuksissa käytetään kuitenkin aina tätä viestiä.

Ryhmästä poistumisen prosessi

Ryhmästä poistumisviesti ohjataan osoitteeseen 224.0.0.2 ( kaikki reitittimet ). Kun pyytävä reititin vastaanottaa tämän viestin, se lähettää vasemman ryhmän erityisen kyselysanoman vastauksena sen selvittämiseksi, pysyykö ryhmän isäntäjäsen aliverkossa. Jos vastausta ei vastaanoteta, reititin katsoo, että ryhmään ei ole enää tilaajia. Tämä viesti toistetaan yleensä, joten ryhmän viive segmentin poistumiselle on oletusarvoisesti 2-3 sekuntia.

Hakijan valinta

Kun reititin vastaanottaa pyynnön toiselta reitittimeltä, se vertaa lähteen IP-osoitetta omaansa. Reititin, jolla on pienin osoite, valitaan segmentin kyselyyn. Kun reititin vastaanottaa tällaisen korkeamman pyynnön, se käynnistää 250 sekunnin laskurin, jonka aikana se ei lähetä pyyntöjä. Jos tänä aikana ei vastaanoteta viestiä pyytäjältä, jolla on pienempi IP-osoite, pyynnöt lähetetään uudelleen.

Yhteentoimivuus IGMP v1: n kanssa

• Jos isäntä havaitsee v1-pyynnön tekijän, se käyttäytyy IGMPv1-isäntänä ja raportoi v1-muodossa vähintään 400 sekunnin ajan. Isäntä voi määrittää, että tämä on v1-pyyntö, tutkimalla Max Resp Time -kentän sisältöä , jos se on 0, se on itse asiassa v1: n käyttämätön kenttä .
• V1-isäntä vastaa v2-pyyntöihin, mutta v1-isännät eivät tulkitse v2-raportteja oikein, joten v1-isännät jättävät ne huomioimatta. Siksi v2- ja v1-isäntien seoksen läsnä ollessa tukahduttamisen ilmoittaminen ei ole täysin tehokasta. Toisaalta pyynnön tekijän tulisi jättää huomiotta ryhmän poistumisviestit , jos se havaitsee v1-isännän ryhmässä.

IGMPv2: n rajoitukset

Ainoat mahdolliset tilat ovat tyypin (*, G), ts. Isäntä ei voi ilmoittaa haluavansa vastaanottaa ryhmää vain tietystä lähteestä, eikä sulkea pois tiettyä lähdettä.

IGMP v3

Versio 3 ( RFC  3376) lisää mahdollisuuden määrittää ryhmätilaus tietylle lähteelle tai sulkea pois tietyt lähteet. RFC määrittää, että IP-paketin ToS-kentäksi on asetettu 0xc0 ( Internetwork Control ) ja että Reitittimen hälytys -vaihtoehtoa ( RFC  2113) käytetään.

IGMPv3: ta tukevat Linux versiosta 2.6.7, Windows XP, Cisco IOS 12.1 (5) T ja FreeBSD 8.0.

Raporttien poistaminen, joiden tuki on pakollista versioille 1 ja 2, poistetaan tästä julkaisusta. Tämä helpottaa IGMP Snoopingin toimintaa ja vähentää latenssia, kun viimeinen jäsen lähtee ryhmästä ( nopea poistuminen ).

IGMPv3-viestejä on kahdenlaisia:

• Tyyppi = 0x11: Pyyntö
• Tyyppi = 0x22: Ilmoita v3

Tyyppikentät 0x12 (raportti v1), 0x16 (raportti v2) ja 0x17 (poistuminen v2) on tuettava IGMP v3: n toteutuksella taaksepäin yhteensopivuuden takaamiseksi.

Kyselyt

Kyselyjä on kolmenlaisia:

• yleinen pyyntö: ryhmän osoite jätetään tyhjäksi ja N = 0
• ryhmäkohtainen pyyntö: ilmoitetaan ryhmän osoite ja N = 0
• ryhmää ja lähteitä koskeva pyyntö: ilmoitetaan ryhmän osoite, N ≠ 0 ja luettelo lähteistä.

Yleinen pyyntö lähetetään osoitteeseen 224.0.0.1 ( kaikki isännät ), kun taas pyyntöjä ryhmille lähetetään kyseisen ryhmän osoitteeseen.

Max Resp Code -kenttä on koodattu seuraavasti:

• jos se vastaa alle 128 olevaa lukua, sillä on sama merkitys kuin kohdassa v2, ts. kymmenesosaa sekunnista,
• jos ensimmäinen bitti on 1, seuraavat kolme bittiä ovat eksponenttibittejä, kun taas seuraavat 4 bittiä toimivat mantissana , mikä sallii suurempien arvojen ilmaisemisen tietäen, että yhtälö on (mant | 0x10) << (exp + 3), enimmäisarvo on 111110000000000b binaarissa, tai 31 × 2 (7 + 3) = 31744 kymmenesosaa sekuntia tai hieman alle 53 minuuttia, mikä auttaa rajoittamaan vastausten kulkua, jossa on suuri määrä jäseniä aliverkko.

Kun S-kenttä on asetettu arvoon 1, käsketään muita reitittimiä ohittamaan tämä viesti ajastinta päivitettäessä.

QQIC ( Querier's Query Interval Code ) -kenttä edustaa kyselyjen välistä aikaa. Reitittimet, jotka eivät pyydä, vastaavat tätä arvoa.

QRV ( Querier's Robustness Variable ) -kenttä on osoitus aliverkon lähetyksen luotettavuudesta. Raportit ja kyselyt välitetään tämän kentän arvon perusteella.

Raportit

Raportit näyttävät ryhmät ja valinnaisesti lähteet, joihin isännät tilaavat. Ne lähetetään osoitteeseen 224.0.0.22, joka on tarkoitettu IGMP v3: lle. Kaksi tilaa on mahdollista:

• inkluusiotila, jossa kaikki halutut lähteet ilmoitetaan,
• poissulkemistila, jossa kaikki lähteet ovat toivottuja, paitsi ilmoitetut. Poissuljettujen lähteiden luettelo on mahdollisesti nolla, mikä tarkoittaa, että isäntä tilaa kaikki lähteet.

Käsitteellisesti reitittimet ylläpitää taulukko koostuu tuplat seuraavassa muodossa:

(monilähetysosoite, ryhmäajastin, suodatustila, (lähdeluettelo))

Jokainen lähde on seuraavassa muodossa:

(lähdeosoite, lähdeajastin)

IGMP-viestit

Tässä on luettelo IGMP-viesteistä sekä niiden kohdeosoite.

G edustaa kyseisen ryhmän osoitetta.

IGMP-versio	Viestityyppi	Versio / tyyppi	Määränpään osoite
1	pyyntö	0x11	224.0.0.1
	raportti	0x12	G
2	pyyntö	0x11	224.0.0.1
	pyydä G	0x11	G
	raportti	0x16	G
	lähteä	0x17	224.0.0.2
3	pyyntö	0x11	224.0.0.1
	pyydä G	0x11	G
	raportti	0x22	224.0.0.22

• Raportti v2

• Raportti v3

IGMP-nuuskaaminen

IGMP Snooping -tekniikka koostuu ethernet-kytkimelle monilähetyskehysten lähettämisen optimoimisesta tarkkailemalla IGMP-liikennettä.

Huomautuksia ja viitteitä

1. (in) Steve Deering "  Isännät laajennukset IP multicast  " Kommenttipyyntö n o  988,Heinäkuu 1986.
2. (in) Steve Deering , "  Host Extensions for IP multicast  " Kommenttipyyntö n o  1112,Elokuu 1989.
3. (in) William Fenner, "  Internet Group Management Protocol, versio 2  " Kommenttipyyntö n o  2236Marraskuu 1997.
4. Network Magic: Monilähetys, UDP ja IGMP
5. (in) "  Internet Group Management Protocol, versio 3  ," Kommenttipyyntö n o  3376,Lokakuu 2002.
6. (in) D. Katz, "  IP Router Alert vaihtoehto  " Kommenttipyyntö n o  2113Helmikuu 1997.

Ulkoiset linkit

Beau Williamson, IP-monilähetysverkkojen kehittäminen , Cisco Press,1999, 568  Sivumäärä ( ISBN  1-57870-077-9 , lue verkossa )