Vajon mi következhet még a BGP után?
Az OSI Inter-Domain Routing Protocol (IDRP) elnevezésû szabványa a BGP-vel azonos célt tûz ki [29]. Valójában nagyon hasonlít a BGP-re olyannyira, hogy meglehetôs konszenzus alakult ki az IETF-en belül, hogy a BGP-5 kifejlesztése helyett célszerûbb az IDRP-vel foglalkozni. Valójában IDRP és a BGP megalkotói gyakran ugyanazon személyek. Az IDRP számos továbbfejlesztést tartalmaz a BGP-hez képest, mint például több címzési rendszer használata, változó hosszúságú címek vagy az AS-ek „konföderációkba" való csoportosítása az AS-út információk lerövidítése érdekében. Nem lebecsülendô, hogy az IDRP képes lesz egyszerre kezelni az IPv4 és IPv6 címeket. Az IPv6-ról bôvebben az Internet fejezetben olvashatunk.
Azonban az IDRP alkalmazására még sokat várhatunk, a BGP-4 is alig néhány éve üzemel, s nem is mindenhol. Már most megjelentek a BGP bôvítésére vonatkozó javaslatok, melyek különbözô, új attribútumok bevezetését célozzák [30] [31], vagy az IDRP-hez hasonló konföderációk kialakítását vetik fel [32].
Az EGP protokollok továbbfejlôdésének azonban talán egyik legfontosabb iránya a policy routing, ez a kérdés ugyanis nem teljesen megoldott a BGP bevezetésével.
A policy routing célkitûzése olyan szituációk megoldása, amikor a csomagok továbbítási útvonalának meghatározásakor a nem csupán a legrövidebb út meghatározása a feladat, hanem egyéb szempontokat is figyelembe kell venni. Ilyen egyéb szempontok elsôsorban a távolsági szolgáltató vagy a megfelelô minôségû útvonal kiválasztása (ami nem feltétlen a legrövidebb). Ezek jobb megértéséhez tekintsük a következô ábrát.
Mind a 3 felhasználó és mind a 3 távolsági szolgáltató a regionális gerincre csatlakozik. Ha egy bizonyos célpont felé mind a 3 szolgáltató ismer utat, akkor a regionális gerincnek választania kell az adott cél felé egy szolgáltatót, amit a felhasználók felé terjeszt. Ez valószínûleg a legkisebb költséget reklámozó szolgáltató lesz, mondjuk a 2.
A felhasználók a nekik megfelelô szolgáltatóval állnak szerzôdésben, szeretnék, ha a célnak küldött csomagjaikat az ô szolgáltatójuk továbbítaná, hiszen ezért fizettek. Erre azonban a BGP nem képes, hiszen a regionális gerinc csak egy útvonalat terjeszt a felhasználók felé. Visszafele lehet, hogy a megfelelô szolgáltatókon jönnek a csomagok, ha az adott felhasználóhoz az adott szolgáltató hirdeti a legkisebb költségû utat.
47. ábra. Tranzit szolgáltató választás - amit a BGP lehetôvé tesz
A fenti szituáció az Internetben egyáltalán nem ritka, sok helyen hoztak létre regionális pénzbôl mindenki számára elérhetô gerinchálózatot, hogy a helyi ipart fellendítsék, a távolsági szolgáltatók természetesen szintén ehhez a gerinchez csatlakoztak, pont úgy, mint a fenti ábrán.
A problémát megoldhatjuk, ha a felhasználók és szolgáltatóik között alagutat (tunnel) építünk ki és a BGP csomagokat, valamint a cél felé küldendô adatcsomagokat ezen az alagúton át továbbítjuk. Maga az alagút úgy mûködik, hogy a rajta átküldendô csomagokat belehelyezzük egy IP csomagba, melynek cél-címe az alagút vége. Az alagút végén pedig kibontjuk és továbbítjuk az igazi címzett felé. Ez azonban jelentôs overhead-del jár, egyrészt a továbbítandó csomagok megnövekedett mérete miatt, másrészt pedig azért, mert az alagút végein a ki és becsomagolás lassú mûvelet, minthogy nem ez a router-ek fô feladata; a továbbítás így lassabb is.
Erre a kérdésre már nem található megoldás a hop-by-hop paradigma használatával, a feladónak ugyanis bele kell szólni abba, hogy csomagja merre haladjon. Erre nyújt lehetôséget az IETF Source Demand Routing Protocol-ja (SDRP) [33], mely lehetôvé teszi a feladónak, hogy leírja a továbbítási útvonalat. Erre ugyan az IP source routing opciója is képes, ott azonban kénytelenek vagyunk konkrét router-eket (IP címmel) megnevezni. Ha viszont nekünk csupán az a fontos, hogy csomagunk a HBONE, EBONE, NSFNet útvonalon haladjon, az ilyenfajta útvonalkijelölés nem megfelelô. Az SDRP lehetôvé teszi, hogy az útvonal leírás AS-eket tartalmazzon, a konkrétabb útvonalkijelölést a helyi berendezésekre hagyva. Az SDRP támogatja a szigorú és a laza source routing módszerét is, így meglehetôsen rugalmasan használható több célra is.
Az SDRP használata esetén azonban az útvonalakat manuálisan kell konfigurálnunk, ehhez segítséget csupán a BGP adatbázisból vehetünk, de onnan sem sokat, hisz az ott szereplô útvonalak az alapértelmezés szerint, a közönséges IP továbbításra használt útvonalak, míg ha SDRP-t használunk, akkor nyilván azért tesszük, mert ezektôl eltérô továbbítási utat szeretnénk kiválasztani. Az IETF másik fejlesztése az Inter Domain Policy Routing (IDPR, nem összekeverendô az OSI IDRP-vel) ezt a problémát célozza meg. [RFC1479]
Míg a BGP AS-út módszere a distance-vector protokollok természetes általánosítása, az IDPR a link-state technológiát követi. Természetesen nem az összes link-et vagy hálózatot térképezzük föl, ez lehetetlen volna, csupán az AS-ekrôl készít térképet, azok közül is csak olyanokról, melyek tranzitszolgáltatást vállalnak. A vak-AS-ek, melyek csak egy helyen csatlakoznak a hálózathoz, vagy azok, melyek ugyan több csatlakozási ponttal rendelkeznek, de nem hajlandóak más forgalmát továbbítani, nem szerepelnek a topológiai adatbázisban, csupán mint az egyes tranzit AS-eken át elérhetô célpontok.
Az AS-ek közötti számos összeköttetést egyetlen „virtuális átjáróvá" egyesítjük, amelyet mindaddig mûködôképesnek tekintünk, amíg a fizikai összeköttetések nagy része mûködik. Az AS-ekrôl számos információt tárolunk, elsôsorban azokat a forrásokat és célokat melyek forgalmát az AS hajlandó továbbítani, az ezekhez kapcsolódó idôszakokat, költségeket és különbözô minôségi paramétereket. Ezeket az információkat az OSPF-hez hasonlóan árasztásosan terjesztjük.
Az adatbázisok karbantartása azonban jóval egyszerûbb lehet mint az OSPF-ben, részben az információk megnövekedett élettartama miatt. Az AS-ekrôl szóló információk meglehetôsen állandónak tekinthetôk, egy terület nem minden nap váltogatja politikáját, az RFC1479 az élettartamra 530 órát javasol, ami több, mint három hét.
Az IDPR esetén azonban nemcsak a frissítések ritkábbak, hanem a különbözô router-ek topológiai adatbázisa is eltérô lehet, nincs olyan szigorú egyeztetési követelmény, mint az OSPF-ben. Ennek az az oka, hogy az AS-ek politikájuknak úgyis csak egy részét terjesztik (ami nyilvános), egy részét pedig csak alkalmazzák (ami titkos). Ily módon lehetetlenség azt várni, hogy akármelyik topológiai adatbázis a politikákat illetôen megfeleljen a valóságnak, akkor pedig minek a szigorú szinkron?
Ha viszont nincs szigorú szinkron, akkor a feladó AS-nek kell a továbbítási útvonalat meghatározni, hogy elkerüljük a hurkok kialakulását. Ezt az IDPR AS-ek közötti virtuális áramkörök kiépítésével oldja meg, a VC kiépítésekor minden AS leellenôrzi, hogy valóban hajlandó-e a két AS között a forgalmat lebonyolítani. Ha nem, megtagadja a VC kiépülését, ha igen, akkor továbbengedi. A feladott datagrammok ezután IDPR csomagokba csomagolva haladnak az IDPR-t értô router-ek között, mintegy alagutakban. Ha a kiépült VC mentén valamelyik router meghibásodik, egy javító folyamat indul be, melynek során új utat keres a rendszer.
A fent vázolt technikák ma még mind a tervezés fázisában vannak, csupán az IDPR jelent meg RFC, az IDRP pedig OSI szabvány formájában, a többi specifikáció még nem kidolgozott. Az IDPR 1993 júliusa óta a javasolt szabvány státuszában van, szabvánnyá válásához azonban számos pozitív alkalmazási tapasztalat kellene. Nagyon bonyolult protokoll (körülbelül mint a BGP és az OSPF együtt) és jelen pillanatban nincs akkora igény a policy routing-ra, hogy a felhasználók komoly pénzeket fektessenek bele.
Két érdekes tanulsága van ezeknek a protokolloknak. Az IDPR-ben elkülönülnek az utat kiszámoló és a csomagokat továbbító berendezések; valójában minden kortárs router belsejében megtalálható ez az elkülönülés. Nem tûnik rossz ötletnek, hogy egy nagy teljesítményû központ számítsa ki az útvonalakat, melyeket csupán közöl a csomagkapcsoló berendezésekkel, így az elosztott algoritmusok összes problémájától megszabadulunk. A másik pedig az Internet AS szintû térképének elkészítésérôl szól. Az ugyanis, hogy egy ilyen térkép elég tömör legyen a feldolgozhatóság miatt és elég részletes ahhoz, hogy belôle intelligens döntéseket lehessen hozni, nem egyértelmûen megvalósítható.
Mindez tehát további kutatást igényel, jelenleg mindössze halvány elképzelésünk lehet arról, milyen is lesz a jövô EGP protokollja. Az pedig, hogy mindez hogyan mûködik majd együtt a multicast-tal, az integrált szolgáltatásokkal és hogyan lesz mobil, roppant nagy és érdekes kérdés.