A fejezet végén egy olyan új szállítási megoldást mutatunk be, amely egyszer az internet fontos részévé válhat. A TCP és a legtöbb szállítási protokoll mind azon a feltételezésen alapul, hogy a küldő és a fogadó között egy folyamatosan működőképes útvonal található, egyébként a protokoll hibázni fog, és nem képes adatokat célba juttatni. Bizonyos hálózatokban gyakran nincsen végponttól végpontig tartó útvonal. Jó példa az ilyen hálózatokra a LEO (Low-Earth Orbit – alacsony Föld körüli pálya) műholdakból álló űrbéli hálózat, amint a műholdak elhagyják, vagy belépnek a földi állomások hatókörébe. A földi állomással egy adott műhold csak bizonyos időintervallumokban tud kommunikálni, és két műhold soha nem tud – még földi állomáson keresztül sem – egymással kommunikálni, hiszen valamelyik műhold mindig a földi állomás hatókörén kívül tartózkodik. Más példának említhetnénk a tengeralattjárókból, autóbuszokból, mobiltelefonokból vagy egyéb, számítógéppel felszerelt eszközökből álló hálózatot, ahol vagy a mobilitás, vagy a szélsőséges körülmények miatt az eszközök között csak időszakosan létezik összeköttetés.
Ilyen időszakosan összekapcsolt hálózatokban az adatáramlás megoldható, ha az adatokat a csomópontokban tároljuk, majd működőképes adatkapcsolat esetén továbbítjuk őket. Az ilyen módszer neve üzenetkapcsolás (message switching). Az adatok végül eljutnak a célpontig. Az ilyen megközelítésen alapuló felépítést DTN-nek (Delay-Tolerant Network – késleltetéstűrő hálózat vagy Disruption-Tolerant Network – szakadástűrő hálózat) hívjuk.
A DTN-ekhez kapcsolódó munka 2002-ben kezdődött, amikor az IETF egy kutatócsoportot hozott létre e célra. Az ösztönzés a legváratlanabb helyről érkezett: csomagot küldeni az űrbe. Az űrbéli hálózatoknak időszakos kommunikációs lehetőségekkel és nagyon nagy késleltetéssel kell szembenézniük. Kevin Fall észrevette, hogy az ilyen bolygóközi internetekhez használt ötletek a földi hálózatokra is alkalmazhatók, amennyiben azokban az időszakos kapcsolat normálisnak tekinthető [Fall, 2003]. Ez a modell az internet egy hasznos általánosítását mutatja, amelyben tárolás és késleltetés is történhet a kommunikáció során. Az adattovábbítás, az útválasztókban történő csomagkapcsolással ellentétben, inkább a postai levél kézbesítésére vagy az elektronikus levelezésre hasonlít.
2002 óta a DTN felépítésén finomítottak, valamint a DTN-modell alkalmazásainak köre is nőtt. A legfontosabb alkalmazása a tudományos számítások, a médiaesemények, a webalapú szolgáltatások által létrehozott hatalmas, több terabájt méretű adathalmazoknak a világ különböző pontjain található adatközpontokba történő másolása. Az ilyen, késleltetéstűrő löketeket az operátorok legszívesebben csúcsidőn kívül szeretnék a hálózaton látni, hogy a már kifizetett, de nem használt sávszélességet kihasználják. Tekinthetjük úgy is, hogy a biztonsági másolatokat éjjel szeretnék elkészíteni, amikor más alkalmazás nem terheli le túlságosan a hálózatot. Világméretű szolgáltatások esetén a probléma ott jelentkezik, hogy a világ különböző helyein a csúcsidők máskor vannak. A Bostonban, illetve Perthben található adatközpontokban a csúcsidőn kívüli másolások között csak kevés átlapolódás képzelhető el, hiszen ha az egyik helyen éjszaka van, akkor a másik helyen éppen nappal.
A DTN-modell azonban megengedi a tárolást és a késleltetést az átvitel során. A modell segítségével lehetővé válik, hogy az adathalmazt Bostonból Amszterdamba csúcsidőn kívül juttassuk el, mivel az időzónák között 6 óra a különbség. Az adathalmazt Amszterdamban tárolják egészen addig, amíg nem áll rendelkezésre csúcsidőn kívüli sávszélesség Amszterdam és Perth között. Az adatokat végül Perthbe küldik, hogy az átvitel teljesüljön. Laoutaris és mások [2009] e modell tanulmányozása során megállapították, hogy tekintélyes kapacitást képes biztosítani kevés ráfordítással, és a DTN-modell alkalmazásával gyakran a kétszerese érhető el annak a kapacitásnak, amelyet a hagyományos végponttól végpontig típusú modell nyújt.
A következőkben az IETF DTN felépítését és protokolljait vizsgáljuk meg.
A legfőbb feltételezés az interneten, amelyet a DTN megpróbál lazítani, az, hogy a kommunikációs viszony teljes időtartama alatt létezik egy végponttól végpontig tartó útvonal a küldő és a fogadó között. Amennyiben ilyen nem létezik, a klasszikus internetprotokollok hibáznak. A DTN a végponttól végpontig terjedő összeköttetések hiányát egy, az üzenetkapcsoláson alapuló felépítéssel próbálja megkerülni, ahogy azt a 6.56. ábra mutatja. Cél továbbá az olyan adatkapcsolatok elviselése is, ahol kicsi a megbízhatóság és nagy a késleltetés. A felépítést az RFC 4838 részletezi.
A DTN terminológiájában az üzenetet kötegnek (bundle) hívjuk. A DTN-csomópontok valamilyen háttértárral vannak felszerelve, tipikusan valamilyen tartós háttértárral, mint például merevlemez vagy flash-memória. A háttértárak tárolják a kötegeket, amíg az adatkapcsolatok elérhetővé nem válnak, majd továbbítják azt. Az adatkapcsolatok időszakosan működnek. A 6.56. ábra öt ideiglenesen működésképtelen adatkapcsolatot mutat, melyek jelenleg nem működnek, valamint két működőképes adatkapcsolatot. Az éppen működő adatkapcsolatokat kontaktusnak [33] (contact) nevezzük. A 6.56. ábra mutat továbbá két DTN-csomópontot tárolt kötegekkel, amelyek kontaktusokra várnak, hogy a kötegeket továbbíthassák. A kötegek így a kontaktusokon keresztül a forrástól a végcélig továbbítódnak.
A kötegek tárolása és továbbítása a DTN-csomópontokban hasonlóan hangzik, mint a csomagok sorba állítása és továbbítása az útválasztókban, de a kettő között minőségi különbségek vannak. Az útválasztókban az interneten a sorbaállás ezredmásodpercekig, vagy legfeljebb másodpercekig tart. A DTN-csomópontokon a kötegeket órákig tárolják, amíg egy autóbusz meg nem érkezik a városba, vagy amíg egy repülő be nem fejezi repülőútját, vagy amíg egy szenzorcsomópont nem gyűjt a Napból annyi energiát, hogy képes legyen a működésre, vagy amíg egy számítógép alvó állapotából fel nem ébred és így tovább. Ezek a példák rámutatnak továbbá a másik fontos különbségre, mégpedig a csomópontok mozgására. A csomópontok ugyanis mozoghatnak (egy autóbusszal vagy repülővel), amíg adatokat tárolnak, a mozgás pedig a kézbesítés kulcskérdése is lehet. Az internet útválasztói ellenben nem mozoghatnak. A kötegek továbbításának folyamata talán a „tárol-hordoz-továbbít” hármassal jellemezhető leginkább.
Példának okáért tekintsük a 6.57. ábrán bemutatott forgatókönyvet, amely a DTN első, űrbéli alkalmazása volt [Wood és mások, 2008]. A kötegek forrása egy LEO műhold, amely a Földről készít képeket a műholdakról történő katasztrófafigyelő program (Disaster Monitoring Constellation) részeként. A képeket a gyűjtőponthoz kell továbbítani. A műhold azonban a Föld körüli pályáján a három földi állomással csak időszakosan van összeköttetésben. Mindhárom állomással felváltva hoz létre kontaktust. Mind a műholdak, mind a földi állomások, mind a gyűjtőpont egy-egy DTN-csomópontként szerepelnek. Minden kontaktus létrejöttekor egy köteget (vagy annak egy részét) küld a műhold a földi állomásnak, majd a kötegeket a földi hálózaton a gyűjtőpontnak továbbítják, hogy teljessé tegyék az átvitelt.
Ebben a példában a DTN felépítésének legfőbb előnye, hogy természetes módon illeszkedik ahhoz a tényhez, hogy a műholdon a képeket tárolni kell, hiszen a képek készítésének időpontjában nincs összeköttetés. Van két további előny is. Először is elképzelhető, hogy egy kontaktus sem elég hosszú életű a képek elküldéséhez, azonban a három földi állomással létesített kontaktusok között szétosztható az átvitel. Másodsorban, a műhold és a földi állomás közötti adatkapcsolat elkülönül a gerinchálózati adatkapcsolattól, így a műholdról történő letöltést nem korlátozza egy lassú földi hálózat. Az átvitel így teljes sebességgel végrehajtható a köteg földi állomáson való tárolásával, amíg az a megfelelő időpontban a gyűjtőpontnak nem továbbítható.
Egy fontos dolgot nem határoz meg ez a felépítés, mégpedig azt, hogy hogyan lehet a DTN-csomópontok között megtalálni a megfelelő útvonalat. A jó útvonalak az architektúra természetén múlnak, amely leírja, hogy mikor kell küldeni az adatokat és azt is, hogy melyik kontaktuson. Némely kontaktus élettartama meghatározható az időben. Jó példa erre az égitestek mozgása az űrbéli példánkban. Az űrkísérlethez tudták, hogy a kontaktusok mikor jönnek létre, ugyanis minden földi állomás feletti elhaladáskor a kontaktusok élettartama 5 és 14 perc között alakult, és a le-irányú adatkapcsolat kapacitása 8,134 Mbit/s volt. Ennek a tudásnak a birtokában a képeket hordozó kötegek átvitele időben tervezhető.
Más esetekben a kontaktusok megjósolhatók, de kisebb bizonyossággal. Például az autóbuszok viszonylag rendszeresen, a menetrendnek megfelelően létesítenek egymással kontaktusokat, ami kezelhető valamilyen szórással, valamint az ISP-hálózatokban rendelkezésre álló, csúcsidőn kívüli sávszélesség mértéke és ideje is megjósolható a korábbi adatok alapján. A másik véglet, amikor a kontaktusok esetlegesek és véletlenszerűek. Ilyen példa a felhasználók mobiltelefonjai közötti adatátvitel, ahol azon múlnak az útvonalak, hogy mely felhasználók építenek ki kontaktusokat egymás között a nap folyamán. Amikor a kontaktusok megjósolhatatlanok, akkor az egyik útválasztási stratégia az, hogy a köteg másolatait különböző útvonalakon küldik szét azt remélve, hogy legalább egy másolat megérkezik a célhoz az élettartam lejárta előtt.
Hogy a DTN-ek működését közelebbről bemutassuk, áttekintjük az IETF-protokollokat. Mivel a DTN-ek még feltörekvőben lévő hálózatok, ezért a kísérleti DTN-ek eltérő protokollokat használnak, mivel nem kötelező IETF-protokollokat használni. Mindazonáltal az IETF-protokollok kezdésnek jók, és a kulcskérdések nagy részére rávilágítanak.
A 6.58. ábrán a DTN-protokollkészletet láthatjuk. A legfontosabb protokoll a kötegprotokoll (bundle protocol), melyet az RFC 5050 tárgyal. Ez a protokoll felelős az alkalmazások felől érkező adatok fogadásáért, valamint az adatok egy vagy több kötegben történő továbbításáért „tárol-hordoz-továbbít” műveletekkel a cél-DTN-csomóponthoz. A 6.58. ábra alapján az is nyilvánvaló, hogy a köteg protokoll a TCP/IP felett fut. Más szavakkal, a DTN-csomópontok között kötegek mozgatására a kontaktusokon TCP/IP használható. A protokoll ilyen módon történő pozicionálása felveti a kérdést, hogy a kötegprotokoll szállítási vagy alkalmazási protokoll. Ahogy az RTP esetében is, itt is tartjuk azt az álláspontunkat, hogy a kötegprotokoll szállítási szolgáltatást nyújt sok különböző alkalmazás számára, annak ellenére, hogy egy szállítási protokoll felett fut. Éppen ezért a DTN-eket ebben a fejezetben tárgyaljuk.
A 6.58. ábrán láthatjuk, hogy a kötegprotokoll más protokollok felett is futhat (mint például az UDP), vagy akár másfajta internetek felett is. Például egy űrbéli hálózatban az adatkapcsolatok késleltetése nagyon nagy lehet. A körülfordulási idő a Föld és a Mars között a bolygók relatív helyzetétől függően könnyedén elérheti a 20 percet is. Képzeljük el most, hogy – különösen rövid üzenetek esetén – milyen jól működne egy ilyen adatkapcsolaton a TCP nyugtázási és újraküldési mechanizmusa. Nem valami jól. Ehelyett használhatnánk valamilyen más, hibajavító kóddal rendelkező protokollt. Vagy egy szenzorhálózatokban, amelyek erős erőforrás-korlátokkal rendelkeznek célszerűbb egy, a TCP-nél egyszerűbb protokollt használni.
Mivel a kötegprotokoll kötött, de mégis több szállítási protokoll feletti futásra szánták, egy funkcionális hézag található a protokollok között. Ennek a hézagnak köszönhetik a létüket a 6.58. ábrán látható konvergenciarétegek. A konvergenciaréteg egyfajta ragasztóréteg, amely az általa összekapcsolt rétegek interfészeit egymáshoz illeszti. Definíció szerint a különböző szállítási protokollokhoz különböző konvergenciaréteg tartozik. Konvergenciarétegeket gyakran találhatunk a szabványokban a régi és új protokollok összekapcsolására.
A kötegprotokoll üzeneteinek a felépítését a 6.59. ábra mutatja. Az üzenetek különböző mezői megmutatják a kötegprotokoll által elvégzett kulcsfeladatokat.
Minden üzenet áll egy elsődleges blokkból, amely gyakorlatilag egy fejrész, egy adatmezőblokkból, amely a felhasználói adatokat tartalmazza, és opcionálisan egy vagy több blokkból, amelyek például biztonsági feladatokat látnak el. Az elsődleges blokk egy Verzió mezővel (értéke jelenleg 6) kezdődik, amelyet a Jelzőbitek követnek. A jelzőbitek egyebek mellett a szolgáltatási osztályt határozzák meg, amely a köteghez alacsonyabb vagy magasabb prioritást rendel, vagy más feldolgozási kéréseket, mint például, hogy a köteget a célnál nyugtázni kell.
Ezután következnek a címmezők, amelyek a kialakítás három érdekes részét emelik ki. A Cél és Forrás azonosítója mellett található egy Figyelő (Custodian) azonosító is. A figyelő felel azért, hogy figyelje a köteg célba érését. Az interneten a figyelő általában a forráscsomópont, hiszen ő küldi újra az adatokat, ha azok nem érték el a végleges céljukat. A DTN esetében azonban egyáltalán nem biztos, hogy a forrás éppen a hálózatra csatlakozik, és így nem is tudja megállapítani, hogy az adatok célba értek-e vagy sem. A DTN a problémát a figyelt átvitellel (custody transfer) oldja meg, amelynek során egy másik, a célhoz közelebb eső csomópont vállalja a felelősséget az adatok biztonságos kézbesítéséért. Például, ha egy repülőgépen tárolunk egy köteget egy későbbi helyszínen és időben történő továbbításhoz, akkor a repülőgép tölti be a figyelő szerepét.
A másik érdekesség, hogy ezek az azonosítók nem IP-címek. Mivel a kötegprotokollt változatos szállítási protokollok és internetek fölötti működésre szánták, ezért saját azonosítókat definiál. Ezek az azonosítók valójában inkább hasonlítanak magas szintű nevekre, például weboldalak URL-jére, mint alacsony szintű címekre, például IP-címekre. Ezek az azonosítók a DTN-ek alkalmazás szintű útválasztásáról tesznek tanúbizonyságot, amilyen például az elektronikus levél kézbesítése vagy a szoftverfrissítések szétosztása.
A harmadik érdekesség pedig az azonosítók kódolása. Az elsődleges blokk tartalmaz egy Jelentés azonosítót is diagnosztikai üzenetek számára. Minden azonosítót úgy kódoltak, hogy az egy változó hosszúságú Szótár mezőre hivatkozzon. Ha a figyelő és a jelentést kezelő csomópontok megegyeznek a forrás- vagy a címzett csomóponttal, akkor ez a megoldás egyfajta tömörítést biztosít. Valójában az üzenetformátumok nagy részét kiterjeszthetőre és hatékonyra tervezték, a változó hosszúságú mezők tömörségének köszönhetően. Ez a tömörség nagyon fontos vezeték nélküli adatkapcsolatokon és korlátozott erőforrással rendelkező csomópontokon, mint amilyenek például a szenzorhálózatokban lévő csomópontok.
A következő mező a Keletkezés, amely a köteg keletkezésének időpontját tartalmazza a forrás által megadott, a sorba rendezéshez szükséges sorszámmal együtt. Az Élettartam mező megadja azt az időpontot, amikortól a köteg által hordozott adat már nem használható. Ezek a mezők azért kaptak helyet, mert az adatokat a DTN-csomópontok hosszú ideig tárolhatják, és az elévült adatokat valahogyan el kell távolítani a hálózatból. Az internettel ellentétben ezek a mezők megkívánják, hogy a DTN-csomópontok lazán szinkronizált órákkal rendelkezzenek.
Az elsődleges blokkot a Szótár mező zárja. Ezután következik az Adatmező blokk. Ez a blokk egy adatmezőt azonosító rövid Típus mezővel kezdődik, majd ezt követi a Jelzőbitek kisebb csoportja, amely feldolgozási információt nyújt. Ezeket a Hossz, majd az Adatok mező zárja. Legvégül állhatnak még opcionális blokkok, mint például egy biztonsági paramétereket hordozó blokk.
A DTN sok vonatkozása még kutatási téma. Jó útválasztási stratégiák a kontaktusok természetétől függnek, ahogy arról már volt szó. A hálózaton belüli adattárolás újabb kérdéseket vet fel. A torlódáskezelésnek most a csomópontok háttértárait mint másfajta, kimeríthető erőforrásnak kell tekintenie. A végponttól végpontig tartó kommunikáció hiánya súlyosbítja a biztonsági problémákat is. Mielőtt egy DTN-csomópont egy köteg figyelését elvállalja, lehet, hogy tudni szeretné, hogy a küldő jogosult-e a hálózatot használni, és hogy a címzett csomópont tényleg igényt tart-e a kötegre. A fenti problémák megoldása függ a DTN fajtájától, mivel az űrbéli hálózatok különböznek a szenzorhálózatoktól.
[33] Sajnos a magyar nyelv az adatkapcsolatra nem tartalmaz elég szinonimát, így a „contact” szó magyarban meghonosodott formáját használjuk. (A fordító megjegyzése)