TLT-2600 Verkkotekniikan jatkokurssi Multicast Prof. Jarmo Harju, TTY Verkkotekniikan jatkokurssi 1
Multicast-sovellukset Resurssien haku esim. naapurireitittimet, DHCP -palvelin käytetään yleensä vain paikallisesti yhdessä IP-aliverkossa Etäopetussovellukset Virtuaaliyliopisto, FUNET-TV Suosittujen tiedostojen siirto Viihde Peer-to-peer vahvasti kuvassa mukana Konferenssisovellukset, konsertit, katastrofien uutisointi IETF:n kokoukset Live-esitykset 09/11 2001 Internet-radio ja TV esimerkkejä tulevista tarpeista Verkkotekniikan jatkokurssi 2
Multicastin hyödyt Verkkotekniikan jatkokurssi 3
Onko tässä jokin reititysongelma? Multicast-lähetyksissä kohdeosoitteena on D-luokan Internet-osoite, joka on muotoa 1110 xxxx xxxx xxxx xxxx xxxx xxxx xxxx eli välillä 224.0.0.0-239.255.255.255 olevat osoitteet Tämä ei oikeastaan ole mikään osoite, vaan multicastlähetyksen tunnistenumero, jonka tulee yksikäsitteisesti identifioida lähetys. Tunniste voi siis olla 28 bittiä pitkä, joten arvoja on runsaasti. Mitkään reititystaulut eivät eivät tunnista multicastosoitteita, joten multicast-reititys ei voi perustua samanlaisiin menetelmiin kuin tavallinen reititys Verkkotekniikan jatkokurssi 4
Mahdollisia tekniikoita Broadcastin käyttö linkkitasolla MAC-osoitteita käyttäen Broadcastin rajoitettu käyttö IP-tasolla (flooding) TTL-arvon rajoittaminen Flooding rajoitettuna virittävään puuhun (ns. Core-based tree) Flooding & RPF - reverse-path forwarding (ns. Source-based tree) Tilaajien huomioonotto: Flood and prune Tilaukseen perustuva multicast Yhden tai useamman kohtauspisteen (rendezvous point) käyttö lähdespesifinen multicast Verkkotekniikan jatkokurssi 5
Flooding Flooding tuottaa valtavan määrän duplikaatteja ja tuhlaa siten runsaasti verkon resursseja Haitallisia vaikutuksia voidaan vähentää esim.: sovellustasolla käytetään sekvenssinumeroita sovellusprotokollan headerissa pidetään kirjaa paketin kulkemasta reitistä IP-tasolla TTL:n käyttö IP-otsakkeen identifier-kentän käyttö topologiatiedon hyväksikäyttö (virittävät puut) Vaativat paljon prosessointia Verkkotekniikan jatkokurssi 6
Flooding topologiatietoa hyväksikäyttäen Toimii samaan tapaan kuin spanning tree -protokolla siltaverkoissa MAC-tasolla eli eliminoi tiettyjen interfacejen käytön silmukoiden ehkäisemiseksi Voidaan toteuttaa esim. valitsemalla yksi solmu AS:n sisältä juurisolmuksi ja laskemalla siitä lyhimmät polut kaikkiin muihin solmuihin (Core-based tree) Heikkouksia ei ota huomioon tilaajien sijoittumista verkkoon kuormittaa runsaasti aina samoja linkkejä Verkkotekniikan jatkokurssi 7
Reverse-Path Forwarding - RPF Source-based tree: Luodaan erillinen virittävä puu jokaiselle lähteelle Kun multicast-paketti saapuu reitittimelle (R) interfacesta (I), R suorittaa ns. RPF-testin: R poimii talteen paketin lähdeosoitteen (S) käyttäen (unicast) reititystaulun tietoja R tarkistaa onko I se interface, josta lähtee lyhin polku R:stä S:ään jos on, niin sisääntuleva paketti läpäisi RPF-testin, ja se monistetaan kaikkiin muihin ulosmeneviin portteihin jos ei, niin paketti ei läpäise testiä, ja se hylätän Verkkotekniikan jatkokurssi 8
RPF-testi Verkkotekniikan jatkokurssi 9
RPF:N HYVIÄ JA HUONOJA PUOLIA + nopein mahdollinen pakettien jakelu (rajoittamatonta floodingia lukuunottamatta), koska käytetään lyhimpiä polkuja + verkko tulee tasaisemmin kuormitetuksi kuin vain yhtä virittävää puuta käytettäessä, koska jokaiselle lähteelle S puu määräytyy eri tavalla - ryhmään kuulumista ei oteta huomioon, vaan paketit levitetään kaikkialle minne TTL antaa myöten Verkkotekniikan jatkokurssi 10
RPF : Flood & prune Multicast-ryhmän 1. paketti jaetaan kaikille reitittimille (TTL:n sallimissa rajoissa) Lehtireitittimet, joiden aliverkoissa ei ole yhtään ryhmän lähetystä kuuntelevaa tilaajaa, kieltävät seuraavat lähetykset Jos kielto tulee kaikilta lehtireitittimiltä, myös välittävä reititin voi kieltää lähetykset itselleen Reitittimien pidettävä yllä tilatietoa (source, group) -pareista Säännöllisin välein voidaan ryhmän paketti päästää läpi lehtiin asti. Jos nytkään ei ole tilaajia, kiellot toistetaan. Jos joku on ilmoittautunut IGMP:llä, se pääsee nyt (tietyllä viiveellä) mukaan lähetysten vastaanottajaksi Verkkotekniikan jatkokurssi 11
Unicast-reititysprotokollien rooli RPF:ssä Reititystauluja tarvitaan, jotta löydettäisiin lyhimmät polut Unicast-reititystaulusta löytyvä polku on lyhin polku R:stä S:ään, kun itse asiassa tarvittaisiin lyhin polku S:stä R:ään Tältä kannalta katsottuna voisi olla eduksi käyttää erillistä reititystaulua multicastia (eli RPF-testiä) varten DVMRP (Distance Vector Multicast Routing Protocol) oli ensimmäinen menetelmä multicast-reititystaulun muodostamiseen (mrouted) MOSPF tekee saman käyttäen OSPF:ää ja erityisiä multicastreiteille tarkoitettuja LSA:ita Verkkotekniikan jatkokurssi 12
PIM - Protocol Independent Multicast jaottelu tiheisiin (dense) ja harvoihin (sparse) multicast-lähetyksiin tiheässä esim. kymmeniätuhansia tilaajia harvassa esim. vain muutamia tilaajia tiheät tapaukset voidaan hoitaa RPF:llä (+prune) harvoja varten otettava käyttöön vähemmän resursseja kuluttava menetelmä Verkkotekniikan jatkokurssi 13
PIM-SPARSE multicast-menetelmä silloin, kun osallistujia on vähän: ei floodingia! osallistujien tiedettävä RP:n (= rendezvous point) osoite tilaus (join) lähetetään RP:hen, joilloin matkan varrella olevat reitittimet kirjaavat ryhmään osallistumisen näin muodostuu ryhmäkohtainen shared tree Shared tree voi olla jakelun kannalta epäoptimaalinen. PIM-SM sallii jakelupuun uudelleen muotoilun lähdekohtaiseksi lyhimpien polkujen puuksi (Source-based shortest path tree, SPT) Toisin kuin PIM-DM:n tapauksessa, SPT muodostuu nyt vastaanottajista kohti lähdettä, joten flood & prune -menetelmää ei nyt tarvita. Verkkotekniikan jatkokurssi 14
Työasemien rooli multicastissa Tyypillisesti työasemat ovat kiinni Ethernet-verkossa yhden lehtireitittimen kautta yksi multicast-mac -osoitteella varustettu paketti riittää toimittamaan halutun tiedon kaikille tilaajille yhden broadcast-domainin (aliverkon) alueella lehtireitittimen pitää olla selvillä siitä minkä multicastryhmien tilaajia aliverkossa kulloinkin on työasemat käyttävät IGMP-protokollaa tiedottaakseen reitittimelle halukkuudestaan liittyä ryhmään tai poistua siitä Verkkotekniikan jatkokurssi 15
Multicast Ethernetissä Multicast-IP-osoite on muutettava sellaiseksi MAC-tason osoitteeksi, josta lähetyksen tilaajat tunnistavat ryhmälle kuuluvan paketin MAC-osoite, jonka ensimmäisen tavun vähiten merkitsevä bitti on 1, tarkoittaa multicast-lähetystä (esim. 01:00:5e:7f:ab:cd) Erityisesti osoitteet 01:00:05:00:00:00-01:00:05:7f:ff:ff on varattu IPmulticastaukseen Käytettävissä oleviin 23 bittiin sijoitetaan D-luokan IP-osoitteen 23 vähiten merkitsevää bittiä Aliverkossa kuljetettavilla multicast-lähetyksillä on siis oltava tunnisteet, jotka eroavat toisistaan näiden bittien osalta Kun reititin lähettää multicast-paketin aliverkkoon, se ei käytä ARPprotokollaa, vaan kosnstruoi MAC-osoitteen edellä mainitulla tavalla Verkkotekniikan jatkokurssi 16
IP:n multicast-osoitteiden kuvaus Ethernetin multicast-osoitteiksi MAC-osoitteissa on tietty alue varattu IP-multicastiin: osoitteet 01 00 5E 00 00 00 /25, josta jää 23 bittiä (25+23=48) otettavaksi IP-multicast -osoitteesta Verkkotekniikan jatkokurssi 17
IGMP - Internet Group Membership Protocol Reitittimen käynnistämä request - response -protokolla aliverkossa olevien multicast-lähetysten vastaanottajien selvillesaamiseksi Kysely (query) all systems -multicast-osoitteeseen 224.0.0.1 arvolla TTL=1 Mikäli asema kuuluu johonkin ryhmään, se vastaa lyhyen satunnaisen odotusajan jälkeen ilmoittamalla ryhmän numeron response-paketissa. Response lähetetään ko. ryhmän multicast-osoitteeseen, jolloin kaikki aliverkossa tähän ryhmään kuuluvat kuulevat vastauksen Vain yksi vastaus per ryhmä tarvitaan - muut peruuttavat lähetyksensä IGMPv1:ssä ei ole keinoja eksplisiittisesti erota ryhmästä, eikä menetelmää valita vain tiettyä lähdettä Verkkotekniikan jatkokurssi 18
IGMP - Internet Group Membership Protocol Verkkotekniikan jatkokurssi 19
IGMPv1 pakettiformaatti Verkkotekniikan jatkokurssi 20
IGMP:n kentät Versio 1 Tyyppi 1 - query sent by router O - report sent by host Tarkistusumma Multicast-ryhmän osoite Nolla kyselyviestissä Haluttu multicast-osoite vastausviestissä Verkkotekniikan jatkokurssi 21
IGMPv2 ja v3 Versio 2 on edelleen yleinen Useita uusia piirteitä Kyselijäreitittimen valintaprosessi Satunnaisen odotteluajan odotusarvoa voidaan säädellä parametrilla käyttää versio 1:n käyttämättä jääneitä bittejä Ryhmäspesifiset kyselyt mahdollisia Poistumisviestit mahdollisia Vasta versio 3 mahdollistaa tietyn lähteen lähettämän multicast-datan tilaamisen Verkkotekniikan jatkokurssi 22
IGMP versio 3 Verkkotekniikan jatkokurssi 23
MBONE (Multicast backbone) Aluksi multicast-reititykseen pystyvien solmujen varaan rakennettu kokeiluverkko, jossa lähetykset jaeltiin floodausta käyttäen kaikille solmuille Ensimmäiset laajemmat lähetykset v. 1992, jolloin RPF-tekniikka ja mrouted-ohjelmisto UNIXille julkistettiin Sisältönä eri tavoin koodattua audio- ja videodataa, jonka koodaukseen ja dekoodaukseen tarvittavat ohjelmat (esim. vic, vat, rat) vapaasti saatavilla. Löytyy myös muita sovelluksia, mm. whiteboard interaktiiviseen työskentelyyn Erilaisia protokollia tarvitaan mm. sisällön kuvaamiseen (SDP), lähetysten mainostamiseen (SAP) ja osallistujien kutsumiseen (SIP) Multicast-tuki vakiona reitittimissä ja hosteissa enää ei puhuta erillisistä saarekkeista Verkkotekniikan jatkokurssi 24
Mbonen ohjelmalista Saatavilla olevien ohjelmien listaa voi selailla, ja kiinnostaviin lähetyksiin voi liittyä esim. sdr-sovellusohjelmalla. Verkkotekniikan jatkokurssi 25
Multicast-lähetysten vastaanotto jos tiedät lähetyksen multicast-osoitteen, porttinumeron ja sovellusdatan koodauksen, käynnistä sovellusohjelma kuuntelemaan ko. osoitetta ja porttia. edellisen perusteella asema vastaa reitittimen IGMP-kyselyyn, ja ilmoittaa halukkuuden vastaanottaa tiettyä lähetystä MBONEssa on erikseen lähetyshakemisto, josta voi hakea sinne rekisteröityneiden lähetysten tiedot. sdr-ohjelma hakee lähetystiedot ja toimii samalla käyttöliittymänä eri lähetysten vastaanottamiseen käynnistäen tarvittavat sovellusohjelmat Verkkotekniikan jatkokurssi 26
Yhteenveto Internetin verkkorakenne mahdollistaa multicastista hyötymisen Pakettien monistaminen tehdään mahdollisimman lähellä vastaanottajia Reitittimet eivät voi toteuttaa multicast-jakelua tavanomaisen (eli unicast-) reitityksen menetelmillä Asiakkaat tiedottavat kuunteluhaluistaan IGMP:llä Reitittimet rakentavat ns. jakelupuun Oman AS:n ulkopuolelta tuleviin multicasteihin tarvitaan Aina oma RP (rendezvous point), RP:eiden välinen protokolla (MSDP) laajennettu BGP (MBGP) AS:ien rajat ylittävien jakelupuiden luontia varten Multicastin avulla voidaan toteuttaa mm. radio- ja TV-ohjelmien jakelua Internetissä Verkkotekniikan jatkokurssi 27