6. Monilähetysreititys Paketti lähetetl hetetään n usealle vastaanottajalle Miksi? Monet sovellukset hyötyv tyvät - ohjelmistopäivitykset ivitykset - etäopetus opetus, virtuaalikoulu - videoiden, äänitteiden nitteiden lähetys - WWW-välimuistien päivitykset - interaktiiviset pelit Mitä hyöty tyä? - Nopeus, tehokkuus 223 paketti monelle vastaanottajalle useita kaksipistelähetyksi hetyksiä: : kaikille oma paketti tulvitus multidestination routing: kohteet lueteltu paketissa, reititin kopioi kaikkiin tarpeellisiin ulosmenoihin muodostetaan virittävä puu (spanning tree) - ei silmukoita - yhteinen tai jokaiselle lähettl hettäjälle oma puu reverse path -algoritmi (kää äänteinen polku) - estimoi virittävää ää puuta 224 Page1 1
Monilähetysryhmä Monilähetys ryhmäosoite (Luokan D osoite) vastaanottajaryhmän n hallinta - ryhmien muodostus, poistaminen - vastaanottajien lisää ääminen, poistaminen Monilähetyksen reitittäminen reitittimet tietävät t ketkä kuuluvat mihinkin ryhmää ään - laskevat lyhimmät t reitit vastaanottajiin - ohjaavat reititystaulujensa avulla paketit vastaanottajille 225 Monilähetysryhmien hallinta Monilähetyksen protokollat Internet Group Management Protocol (IGMP) (RFC 2236) IGMP isänt ntäkoneen ja sen lähimml himmän n reitittimen välillv lillä - isänt ntäkone ilmoittaa itsensä jäseneksi tiettyyn ryhmää ään - isänt ntäkone poistaa itsensä ryhmäst stä monilähetysreititysalgoritmi - reitittimien välillv lillä monilähetysten koordinoimiseksi - esim. PIM (RFC 2362), DVMRP (RFC 1075), MOSPF (RFC 1584) - huom! ryhmän n isänt ntäkoneiden välillv lillä ei ole mitää ään n protokollaa * eivät t tiedä,, ketkä muut kuuluvat ryhmää ään 226 Page2 2
D-osoitteet monilähetykset D-osoitetta D käyttk yttäen - perilletoimitus best effort - 28 bittiä => yli 250 miljoonaa ryhmäosoitetta - 224.0.0.0 239.255.255.255. 224.0.0.0-224.0.0.255 reititysprotokollille yms pysyviä ryhmiä - 224.0.0.1 kaikki lähiverkossal - 224.0.0.2 kaikki reitittimet lähiverkossa - 224.0.0.5 kaikki OSPF-reitittimet lähiverkossal - 224.0.0.6 kaikki designated OSPF-reitittimet lähiverkossa tilapäisi isiä ryhmiä 227 IGMP:n toimintaperiaate Toimii suoraan IP-kerroksen päällä kysely/vastaus monilähetysreitittimet kyselevät - noin minuutin välein v kysyvät t kaikilta koneiltaan, mihin ryhmiin kuuluvat * 224.0.0.1-osoitteella koneet vastaavat - ilmoittamalla kaikkien niiden ryhmien D-osoitteet, D joihin jokin niiden sovellus on liittynyt host kysely vastaus router 228 Page3 3
IGMP-sanomat Membership query general: mihin ryhmiin kuuluvia? specific: onko tiettyyn ryhmää ään n kuuluvia? Kyselyillä maksimivastausaika Membership report kone haluaa liittyä tai on liittynyt ilmoitettuun ryhmää ään Leave group kone ilmoittaa poistuvansa ryhmäst stä vapaaehtoinen! - Jos ei vastaa kyselyihin, ei ole enää mukana * => jäsenyyden j voimassaololle aikaraja 229 IGMP-sanoma Type max. response checksum time Multicast Group Address Type = mikä sanoma kyseessä max. response time = maksimivastausaika kyselyissä Checksum = taskistussumma Multicast Group Address = monilähetysryhmän osoite 230 Page4 4
Maksimivastausaika? Optimointia varten, esim. LAN-verkoissa, joissa kaikki kuulevat kaikki sanomat reititin haluaa tietää vain onko kukaan sen LANin koneista kiinnostunut tietystä ryhmäst stä - ei sitä ketkä koneista haluavat ryhmän n jäseniksij - ei edes montako sen koneista on tietyn ryhmän jäseninä koneet vastaavat satunnaisen ajan kuluttua - jos joku muu kone jo vastannut, ei enää vastaa => vastausten määm äärä pienenee 231 Internetin monilähetyspalvelumalli Kone ilmoittaa omalle reitittimelleen haluavansa liittyvä tiettyyn ryhmää ään - IGMP:n membership_report-sanomalla sanomalla Reitittimet alkavat välittv littää koneelle tämän t n ryhmän n viestejä vastaanottajavetoinen (receiver-driven) - Lähettäjä ei pidä kirjaa ryhmän n jäsenistj senistä eikä tiedä kenelle kaikille viesti menee. Kuka tahansa voi toimia lähettl hettäjänä - eri lähettl hettäjien sanomat tulevat sekaisin Monilähetysosoitteita ei koordinoida verkkotasolla - eri ryhmille voidaan valita sama osoite 232 Page5 5
IGMP ja IPv6? IGMP käyttk yttää 32 bitin osoitetta Ei erillistä IGMP-protokollaa IPv6:lle, vaan toiminnot liitetty ICMPv6:een (RFC 2710) - Multicast Listener Query * Yleinen kysely: millä monilähetysosoitteilla on 'kuuntelijoita' * Tietyn monilähetysosoitteen kuuntelijat - Multicast Listener Report - Multicast Listener Done 233 4.2 Monilähetysreititys (multicast routing) Ongelma: Reitittimien on kyettävä rakentamaan optimaaliset reitit ryhmän n kaikille vastaanottajille - kun mikä tahansa kone voi toimia lähettl hettäjänä - ryhmää ään n voi kuulua eri mää äärä vastaanottajia * lähes kaikki isänt ntäkoneet * vain muutama isänt ntäkone - ryhmän n jäsennyys j voi olla hyvin dynaamista Tavoitteena on löytl ytää mahdollisimman optimaalinen puu,, joka yhdistää kaikki ryhmän n jäsenetj - sanomien reititys puun kaaria pitkin 234 Page6 6
A A, B, E ja F: reitittimillä ryhmän jäseniä F C E B D C ja D: reitittimillä ei ole ryhmän jäseniä 235 Monireitityspuun rakentaminen Kaksi erilaista lähestymistapaal yksi puu koko ryhmälle lle (group shared tree) - kuka tahansa toimii lähettl hettäjänä,, niin reitityksessä käytetään n samaa puuta jokaiselle lähettl hettäjälle oma puu (source-based tree) - jos ryhmäss ssä on n jäsentj sentä,, niin muodostetaan n eri puuta - jokaisen lähettl hettäjän n sanomat reititetää ään n sen oman puun avulla 236 Page7 7
Yksi puu koko ryhmälle A A, B, E ja F: reitittimillä ryhmän jäseniä F C E B D C ja D: reitittimillä ei ole ryhmän jäseniä reitityspolku 237 Eri lähettl hettäjille omat puut A A, B, E ja F :reitittimillä ryhmän jäseniä C B D C ja D: reitittimillä ei ole ryhmän jäseniä F E A:n lähettäessä B:n lähettäessä 238 Page8 8
Reititys käyttk yttäen yhtä puuta koko ryhmälle Löydettävä puu, joka yhdistää kaikki ryhmän reitittimet - mukana myös s muita reitittimiä - puun kustannus on sen linkkien kustannusten summa pienimmän n kustannuksen puu NP-täydellinen ongelma (Steiner tree problem) - suht.koht. hyviä heuristisia ratkaisuja on - ei ole käytk ytössä Internetissä * tiedettävä kaikki linkkikustannukset eli koko verkon topologia * kustannusten muuttuessa laskettava uudelleen - mieluummin jo muutenkin laskettujen kustannusten (reititystietojen) hyödynt dyntäminen 239 Pienimmän n kustannuksen monilähetyspuu 3 A 4 A, B, E ja F: reitittimillä ryhmän jäseniä F 2 C 1 2 2 E B D 1 1 C ja D: reitittimillä ei ole ryhmän jäseniä 240 Page9 9
Keskuspohjainen reititys (Center-based routing) Ryhmän n puun keskuksena on jokin solmu, johon muut myöhemmin liittyvät - ensin saadaan selville keskussolmu - muut liittyvät t siihen JOIN-sanomilla * yksilähetyksi hetyksiä (unicast) keskussolmulle * JOIN-sanoman välittävä reititin lisää ko. Verkkoliitynnän ryhmää ään ja lähettää sanoma eteenpäin in, jollei jo ole mukana ryhmäss ssä - Seurauksena virittävä puu ko. ryhmälle - Miten keskussolmu valitaan? * Optimaalinen valinta: : NP-täydellinen ongelma * Ryhmän jäsenet vaihtuvat ==> sopiva keskussolmu vaihtuu * Valitaan siten, että Keskussolmu lähellä lähettäjääää TAI Kiinteästi konfiguroitu 241 Keskuspohjainen monilähetyspuu F 2 C 1 5 A 4 3. 2 B 2. 2 D 1 E 1 G A, B, E ja F: reitittimillä ryhmän jäseniä C ja D: reitittimillä ei ole ryhmän jäseniä Ratkaisevaa on keskussolmun järkevä valinta 1. 242 Page 10 10
Jokaiselle lähettl hettäjälle oma puu Tavallisessa reitityksessä jo yleensä lasketaan pienimmän n kustannuksen puu lähettl hettäjältä muihin solmuihin Dijkstra => reititystaulu Käytetään tätä tietoa hyväksi paljon puita - N lähettäjääää => N puuta - reitityksessä käytetty puu valitaan lähettäjän mukaan Reverse path forwarding (pruning) Lisättyn ttynä karsinnalla - Älä turhaan lähetl hetä tänne 243 Reverse path forwarding -algoritmi idea tuliko paketti verkkoliitynnäst stä,, josta normaalisti lähetetään n paketin aloittaneelle solmulle? - jos tuli, paketti kopioidaan kaikkiin muihin ulosmenoihin ja talletetaan ryhmä ja lähde - jos ei tullut paketti tuhotaan kaksoiskappaleena edut - tehokas ja helppo toteuttaa - ei tarvitse tuntea virittävää ää puuta - ei ylim. yleisrasitetta (kohdelista, lisäbittej bittejä) - tulvitus pääp äättyy itsestää ään 244 Page 11 11
A lähettäjä ryhmän jäsen ei ole jäsen C B F E D pruning: Älä turhaan lähetä tänne! G 245 Monilähetysreititys Internetissä DVMRP (Distance Vector Multicast Routing Protocol) (RFC 1075) kullekin lähteelle l oma puu käyttäen reverse path forwarding -menetelm menetelmää ja karsimista (pruning) ja lisää äämistä (graft) etäisyysvektorialgoritmin avulla kukin reititin laskee lyhyimmän n polun jokaiseen mahdolliseen lähteeseen l ja tallettaa linkin (next hop) tieto puussa alavirtaan sijaitsevista reitittimistä,, jotta tiedetää ään, milloin haara voidaan kokonaan karsia - Kun kaikki reitittimet ilmoittavat, etteivät t enää ole kiinnostuneita - Ilmoituksesa ajastin karsinnan voimassaololle - Eksplisiittinen lisää ääminen 246 Page 12 12
Muita MOSPF MOSPF (Multicast Open Shortest Path First) (RFC 1584) OSPF:ää käyttävissä AS:issä linkkitilailmoituksissa myös s tieto monilähetysryhmien jäsennyydestä kaikki reitittimet tietävät, t, mihin monilähetysryhmiin muiden reittimien isänt ntäkoneita kuuluu voidaan laskea kullekin lähteellel oma ennaltakarsittu lyhyimmän n polun puu jokaiselle monilähetysryhm hetysryhmälle 247 Muita monilähetysprotokollia: CBT CBT CBT (Core-based Trees) (RFC 2201, RFC 2189) kaksisuuntainen yhteiskäytt yttöinen puu, jossa yksi keskus sanomia - JOIN_REQUEST keskussolmulle, kun haluaa liittyä ryhmää ään - JOIN_ACK keskussolmu tai lähin l jo ryhmäss ssä oleva reititin - ECHO_REQUEST vieläkö mukana ryhmäss ssä - ECHO_REPLY vielä mukana - FLUSH_TREE poistetaan ryhmäst stä 248 Page 13 13
Muita: PIM PIM PIM (Protocol Independent Multicast) (RFC 2362) dense mode ~ DVMRP - tulvita ja karsi sopii hyvin, jos vastaanottajia on tiheään sparse mode ~ CBT - JOIN-sanomia, jotka ohjataan yksilähetyksen hetyksenä keskussolmuun - polulla olevat reitittimet monilähetysmoodiin - keskussolmu lähettl hettää monilähetyksen hetyksenä muille - yksi puu <=> lähettl hettäjälle oma puu 249 Page 14 14