IP multicast routing napjainkban

Jákó András
BME EISzK
Networkshop 2001., Sopron

1. IP multicast

Az adattovábbításnak négy alapvető formáját különböztethetjük meg az üzenet, az adó és a vevő(k) felállása szerint: unicast, anycast, broadcast, és multicast. Unicast esetén az adó az üzenetét egy meghatározott vevőnek küldi. Anycastról akkor beszélhetünk, ha az üzenetet az adó egy vevőnek szánja, de több lehetséges vevő van, és ezek közül valamilyen mérce szerint a legközelebbi veszi az üzenetet. A broadcast üzeneteket az adó mindenkinek küldi. Multicastról pedig akkor beszélhetünk, ha az üzenetet többen veszik, de nem mindenki, hanem csak egy meghatározott csoport.

IP multicast esetén a vevő csoportot egy IP cím azonosítja, a 224.0.0.0/4 tartományból. (A hagyományos IP címosztályok szerint ez a D osztályt jelenti.) A multicast IP csomagok fejlécében tehát a feladó IP címe szerepel forrásként, a cél mezőben pedig a multicast csoport címe, ami a fent említett tartományba esik.

A routereknek az a feladata, hogy a csomagot eljuttassák az összes olyan hosthoz, amely az adott multicast csoport tagja. Ehhez három dolog szükséges:

A multicast csomag tehát a forrástól kiindulva halad a hálózatban a csoport tagjai felé, egyre több példányban. A csomag útja során meg kell különböztetnünk két routert, az elsőt és az utolsót. A csomag a forrás hosttól a first-hop routerhez kerül, majd esetleg további routereken áthaladva egy példánya megérkezik a last-hop routerhez, amelyik továbbítja azt a vevő hostnak.

Fontos megjegyezni, hogy egy adott multicast csoportnak bárki küldhet csomagot, azaz nem szükséges, hogy az adó is a csoport tagja legyen.

1.1. Speciális IP multicast címek

A multicast címtartomány egyes részei speciális célt szolgálnak.

A 224.0.0.0/23 tartomány meghatározott alkalmazások számára van fenntartva, címeit az IANA osztja ki. Első fele (224.0.0.0/24) a link-local tartomány, azaz ezeket a multicast csomagokat a routerek nem továbbítják, pontosan úgy, mintha a TTL mezőjük 1-re lenne állítva.

A unicast címekhez hasonlóan van privát része a multicast címtartománynak is, ez a 239.0.0.0/8. Ezeket a csoportokat minden szervezet önállóan, korlátozás nélkül használhatja, de csak a saját rendszerén belül.

2. Internet Group Management Protocol

Egy host IGMP-vel közli a vele egy subneten levő last-hop routerrel, hogy melyik multicast csoportoknak a tagja, azaz hogy mely csoportok forgalmára tart igényt vevőként. Pontosabban egy subneten egy multicast csoportra csak egy host jelenti be igényét, hiszen a routernek csak annyit kell tudnia, hogy melyik interface-en melyik csoportnak vannak vevői. Az már lényegtelen, hogy egy csoportnak több vevője is van-e, illetve hogy konkrétan a subnet mely hostjai azok. A multicast routerek tehát interface-enként egy-egy listát tartanak arról, hogy az adott interface-en melyik multicast csoportnak vannak tagjai.

Az IGMP (és általában a multicast) működése szempontjából fontos tény, hogy a multicastot támogató hostok állandóan veszik a 224.0.0.1-es link-local címre (all multicast hosts) küldött csomagokat, a multicast routerek pedig minden multicast csomagot vesznek.

2.1. IGMPv1

Az IGMP alapja egy polling mechanizmus. Az IGMPv1 esetén a router periodikusan kérdést küld a 224.0.0.1 címre, hogy ki melyik multicast csoport tagja. A kérdésre a hostok a választ az adott multicast csoport címére küldik. Minden multicast csoportra csak egy válasz megy, hiszen az adott csoport összes többi tagja hallja azt, tehát tudják, hogy az ő válaszuk már felesleges lenne.

Ha egy host csatlakozni szeretne egy csoporthoz, akkor nem kell megvárnia a router következő körkérdését, hanem azonnal bejelentheti igényét. Ezt ugyanazzal az IGMP üzenettel teheti meg, mint amivel a periodikus lekérdezésre válaszolna.

Ha egy multicast csoport forgalmára már egy host sem tart igényt a subneten, akkor a router lekérdezéseire nem fog ilyen válasz érkezni, tehát néhány lekérdezési periódus után a router törölheti a csoportot az interface-hez tartozó csoportok listájából.

2.2. IGMPv2

A kettes verzió legfontosabb újdonsága a csoportból való kilépés explicit jelzése. Eddig a kilépésről a router a fent említett timeout mechanizmus segítségével szerezhetett csak tudomást, itt viszont a hostok jelezhetik, hogy nem tartanak tovább igényt egy multicast csoport forgalmára. Természetesen a timeout mechanizmus is használatban marad, hiszen előfordulhat, hogy a host meghibásodik vagy a kilépési üzenet elvész. (Ezen felül a specifikáció sajnos nem is teszi kötelezővé a kilépési üzenet használatát.) A kilépések jelzésével egy-két nagyságrenddel csökkenhet az az idő, amíg az utolsó host kilépése után feleslegesen érkezik a subnetre egy multicast csoport forgalma.

Ide kapcsolódik az IGMPv2 másik fontos újdonsága is, a csoport-specifikus lekérdezés. Míg az IGMPv1 esetében a lekérdezéseket a router mindig a 224.0.0.1 címre küldte, és az az összes multicast csoportra vonatkozott, az IGMPv2-ben a router lekérdezhet egy konkrét csoportot is, a csoport címére küldött kérdéssel. Ezt a módszert alkalmazza a router miután kilépő üzenetet kapott, hogy megtudja, van-e még más tagja az adott csoportjak a subnetben.

3. Protocol Independent Multicast – Sparse Mode

A multicast routing következő kérdése az, hogy a multicast routerek hogy tájékoztatják egymást arról, hogy melyik csoportoknak vannak tagjai a környezetükben, valamint az, hogy a multicast csomagokat hogy juttatják el az érdekelt last-hop routerekhez.

Egy lehetséges megoldás erre a PIM-SM routing protokoll alkalmazása. A PIM-SM alapvetően autonóm rendszereken belüli multicast routingra használható, bár bizonyos kisegítő protokollok használatával (MSDP, MBGP) a jelenlegi multicast forgalmi viszonyok mellett globális, azaz autonóm rendszerek közti routingot is el tud látni.

A PIM-SM elnevezés első része arra utal, hogy a PIM nem épít fel saját multicast routing táblát, hanem függetlenül attól, hogy milyen unicast routing protokollokat használ a router, az azok alapján létrejött routing táblát használja. A sparse mode pedig azt jelenti, hogy a protokoll nem feltételez mindenütt csoport tagokat (szemben pl. a PIM-DM, dense mode protokollal), ezért nem árasztja el kezdetben az egész hálózatban a multicast forgalmat, hanem csak arra küldi, ahol ténylegesen tagjai vannak a csoportnak.

3.1. Multicast fák

A PIM-SM esetében kétféle fáról beszélhetünk: SPT-ről (shortest path tree) és RPT-ről (rendezvous point tree). Ezeket a fákat a multicast routerek építik ki a hálózatban. A fák ágai hálózati összeköttetések, az elágazási pontjaik multicast routerek, a leveli pedig hostok. A multicast csomagok a fák mentén haladnak hálózatban.

3.1.1. SPT

Az SPT egy adott forráshoz és egy multicast csoporthoz tartozik. A fa gyökere a multicast forrás, a levelei pedig a vevők csoportja. Minden egyes vevő és a forrás közti legrövidebb út a fa ágai mentén halad, innen a shortest path tree elnevezés.

Az SPT-t a PIM-SM routerek építik fel. A last-hop router csatlakozási üzenetet küld a forrás irányába. Ahogy az üzenet a first-hop router felé halad, kiépülnek a fa ágai a levéltől a gyökérig. Természetesen a csatlakozási üzeneteknek nem kell feltétlenül a first-hop routerig eljutniuk, csak odáig, ahol először elérik a már létező fát.

A fákat kiépítésükhöz hasonló módon, azaz a levelektől a gyökér felé haladva metszeni is lehet. Erre akkor kerül sor, ha valamelyik ágára már nincs szükség, mert az abban az irányban elhelyezkedő hostok kiléptek a multicast csoportból.

3.1.2. RPT

Az RPT egy multicast csoporthoz tartozik, és akár az összes forrás forgalma haladhat a fa mentén a csoport tagjaihoz, azaz a fát közösen használhatja több forrás, amelyik ugyanabba a multicast csoportba küld csomagokat. Az RPT gyökere a csoporthoz tartozó rendezvous point (RP), innen az elnevezés.

Az RPT felépítési folyamata hasonló az SPT-hez, azzal a különbséggel, hogy értelemszerűen az RP felé kell a csatlakozási üzeneteket küldeni, hiszen az a fa gyökere.

3.1.3. Rendezvous point

Minden multicast csoporthoz tartozik egy RP, ami a vevőknek (azaz a csoport tagjainak) és adóinak, (azaz a forrásoknak) segít egymásra találni. A forrásoknak és a vevőknek, pontosabban a first-hop és a last-hop routereknek nem kell közvetlen információval rendelkeznie egymásról, hanem elég, ha mindegyik tudja, hogy hol van az RP.

Az RP funkciót egy PIM-SM router látja el. Egy router természetesen lehet több csoport RP-je egyszerre, sőt gyakran egy router látja el ezt a feladatot az összes multicast csoport számára.

Felmerül a kérdés, hogy a PIM-SM routerek honnan tudják meg, hogy melyikük az RP. Erre több megoldás is kínálkozik:

3.2. PIM-SM forgalomirányítás

Egy multicast forrás és a csoport tagjai közötti forgalom először az RP-n keresztül halad. A last-hop routerek kezdeményezésére a fent leírt módon kiépül az RPT-t, így csak az a kérdés, hogy a források forgalma hogy jut el az RP-hez.

Az adni kezdő források first-hop routere unicast IP csomagokba ágyazza a forrás első multicast csomagjait, és így küldi el azokat az RP-nek. Erre az RP egy SPT kiépítését kezdeményezi a forrás irányába küldött csatlakozási üzenettel. Ha kiépül az SPT az RP-től a forrás first-hop routeréig, akkor az RP jelzi a first-hop routernek, hogy a továbbiakban nincs szüksége a unicast csomagokba ágyazott multicast forgalomra, hiszen megkapja a forgalmat az SPT-n. Így tehát egy multicast forrás csomagjai először az SPT mentén eljutnak az RP-hez, majd onnan az RPT mentén a csoport tagjaihoz.

Könnyen elképzelhető olyan topológia, amelyben nagy kerülőt jelent a forrás és a csoport valamelyik tagja között az RP érintése, azaz gyakran nem ez az útvonal az ideális. Szintén problémát jelent, hogy egy csoport teljes multicast forgalma áthalad az RP-n, illetve tipikus esetben több csoport forgalma, hiszen az RP rendszerint több, akár az összes multicast csoport számára is ellátja ezt a funkciót. Ezért ha egy forrás a multicast routeren áthaladó forgalma túllép egy küszöbértéket, akkor a router kezdeményezi a csatlakozást a forrás SPT-jéhez. Ezzel egyidejűleg az RPT-t pedig olyan módon metszi meg, hogy az adott forrás forgalma azon ne érkezzen hozzá, csak a többi forrásé. Ez az átkapcsolás az SPT-re megoldja mindkét fent említett problémát.

4. Interdomain multicast

Az eddig tárgyalt módszerek jól alkalmazhatók viszonylag nagy hálózatokban is, de bizonyos korlátjaik miatt az Interneten kiegészítő megoldásokra is szükség van melléjük.

Az egyik probléma, hogy ma nem működik az Internet összes routerében a PIM-SM protokoll. Sok más routing protokollhoz hasonlóan természetéből fakadóan a PIM-SM is csak úgy képes működni, ha a hálózat egy összefüggő részén minden routeren fut. Erre a problémára kínál megoldást az MBGP.

A másik fontos probléma az, hogy a PIM-SM önmagában nem lenne skálázható az Internet méretére akkor sem, ha minden router támogatná azt. Erre a problémára, illetve ennek egy következményére ad megoldást az MSDP.

4.1. Multiprotocol BGP

Jelenleg még nem tudja az összes router kezelni a multicast forgalmat, hanem csak kisebb-nagyobb multicast "szigetek" léteznek az Interneten. Egy ilyen sziget egy vagy több szomszédos autonóm rendszerből áll. Ezeket a szigeteket egymással általában valamilyen tunnellel kötik össze. A ma leginkább elterjedt tunnel megoldás a GRE (Generic Routing Encapsulation). A multicast csomagok a tunnelben unicast csomagokba ágyazva jutnak el az egyik multicast szigettől a másikig. Ezen szigetek és az őket összekötő tunnelek alkotják az MBONE-t.

Az MBONE topológiája tehát sok esetben eltér az Internet topológiától, ezért az autonóm rendszerek között kicserélt unicast routing információ nem mindenütt használható multicast routinghoz. Erre a problémára egy lehetséges megoldás az MBGP használata az autonóm rendszerek között BGP helyett.

Az MBGP azzal egészíti ki a BGP-t, hogy bevezeti a címzési családok fogalmát. Ezáltal az MBGP szomszédok több protokollcsalád elérhetőségi információit egymástól megkülönböztetve adhatják át egymásnak. Így az interdomain multicast forgalom routolásához a PIM-SM és az MSDP a multicast topológiai információkat használhatja, míg a unicast forgalom irányítására a routerek továbbra is a unicast topológiai információkat alkalmazhatják.

4.2. Multicast Source Discovery Protocol

A PIM-SM skálázhatósági problémáit gyakorlatilag az RP okozza, vagyis az, hogy egy multicast adó forgalma az adás kezdetén mindenképp az RP-n keresztül jut el a csoport tagjaihoz. Ezért a PIM-SM használatához az Internetet kisebb domainekre kell felosztani. Praktikus okokból ezek a PIM domainek gyakran megegyeznek az autonóm rendszerekkel. Ezek a PIM domainnek önálló, komplett PIM-SM hálózatok, mindegyiknek megvan a saját RP-je minden multicast csoporthoz. Kérdés, hogy hogy lehet az ilyen PIM-SM domainek multicast forgalmát összekapcsolni egymással.

A multicast forgalom továbbításában attól a pillanattól, amikor egy forrás esetén megtörténik az átkapcsolás az SPT-re, semmi probléma nem adódik. Az SPT ugyanis gond nélkül kiterjedhet az egész Internetre több PIM domainen keresztül, ráadásul az SPT felépítése is működik a korábban leírt módon minden módosítás nélkül.

A problémát az okozza, hogy az RP – és ezáltal a domain összes vevője – csak a saját domainjében levő forrásokról szerez tudomást, hiszen minden forrás csak a saját domainjében levő RP-nek küldi el a multicast forgalmát. Az MSDP ezt a problémát úgy oldja meg, hogy az RP-k ismeretét a saját domainjük forrásairól továbbadja a többi domain RP-jének is. Így az Internet összes RP-je értesülhet minden multicast forrásról, és ha az adott multicast csoportnak vevői vannak a saját domainjében, akkor kezdeményezheti az SPT felépítését a forrásig, csakúgy, mintha a forrás a saját domainjében lenne. Ezután már minden a PIM-SM saját algoritmusai szerint zajlik.

Az MSDP kapcsolatot tipikusan szomszédos PIM domainek rendezvous pointjai között szokás felépíteni. Ez egy közönséges TCP kapcsolat két RP között, amit mindkét oldalon kézzel kell beállítani. Ilyen MSDP kapcsolatokkal lehet az RP-ket egy globális hálózattá szervezni. Az MSDP kapcsolaton minden RP bejelenti a szomszédainak, hogy milyen multicast források vannak az ő domainjében, majd ezek a bejelentések RP-től RP-ig haladva terjednek szét a hálózatban.

Ez a megoldás jól láthatóan skálázhatósági problémákhoz vezethet később, de a jelenlegi multicast forgalom kezelésére tökéletesen alkalmas.

5. A multicast routing jövője

5.1. IGMPv3

Az IGMPv3 legfontosabb újdonsága, hogy a hostok forrás címeket is megadhatnak a multicast csoportokhoz. Ilyenkor csak azokat a csomagokat kapják meg, amit az általuk kijelölt hostok küldenek a multicast csoport címére.

5.2. Source Specific Multicast

Az SSM a hagyományos multicasttól eltérően nem multicast csoportokról, hanem csatornákról beszél. Egy ilyen csatornát az adó IP címe és a cél multicast csoport címe együttesen azonosít. Az IANA a 232.0.0.0/8 címtartományt foglalta le az SSM célcímek számára.

SSM csatornák esetén csatlakozás helyett előfizetésről beszélünk. Erre a műveletre az IGMPv3 kitűnően alkalmas, hiszen az előfizetés gyakorlatilag annyiban különbözik a hagyományos csatlakozástól, hogy a multicast forrást is meg kell jelölni. A csomagok továbbítása és a routing jóval egyszerűbb, mint a hagyományos multicast esetén. A PIM-SM funkcionalitásának egy részhalmaza apróbb módosításokkal alkalmas az SSM routingra. Azáltal, hogy csatornák vannak megnevezett forrásokkal, gyakorlatilag az SPT-k elegendőek a routinghoz, nincs szükség RP-re és közös fákra sem.

Az SSM egyik előnye tehát a jóval egyszerűbb routing. A biztonság is sokkal nagyobb, mint hagyományos multicast esetén, hiszen a csatornába nem beszélhet bele bárki. A csoportcímek kiosztása sem merül fel problémaként, mert a címek elosztását csak az adott forráson belül kell koordinálni, ez pedig igen könnyű feladat.

5.3. Border Gateway Multicast Protocol

A BGMP egy potenciális jövőbeli megoldás az interdomain multicast routing skálázhatósági problémáira. A BGMP minden épp használatban levő multicast csoporthoz egy kétirányú (a forgalom nem csak a fa gyökerétől indulhat, hanem bármely pontjáról) fát épít fel a multicast domainek összekötésére, és az interdomain multicast forgalmat ezen fa mentén továbbítja.