byte lesz. Becsült értékeket
tartalmaz a következô táblázat [RFC1265]:Ahogy az Internet nôtt, az EGP hierarchikus hálózatmodellje tarthatatlanná vált. Elsôsorban ezért volt szükség új protokoll kifejlesztésére. A BGP elsô verziója 1989 júniusában jelent meg [RFC1105], a második 1990-ben [RFC1163], a harmadik 1991-ben [RFC1267]. Ez a harmadik verzió mûködött az Internetben 1991-tôl 1994-ig. A BGP negyedik verziója is elkészült 1995 márciusában [RFC1771], legfôbb újítása a CIDR. Elôször a BGP alapelvét tekintjük át, mely a BGP-3-ban ölt testet, majd megvizsgáljuk, hogy a CIDR bevezetése milyen változtatásokat tett szükségessé.
Ha meg kívánjuk szüntetni az EGP megszorításait és tetszôleges topológiákat támogatni szeretnénk, gondoskodni kell a hurokmentességrôl. A distance-vector módszer itt azért nem igazából használható, mert nem mindig a legolcsóbb útvonal a kívánatos. Ha a költségeket tetszôlegesen lehet módosítani, ahogy az EGP-nél, a Bellman-Ford algoritmus egyáltalán nem biztos, hogy konvergál. A link-state módszer pedig azért használhatatlan, mert az egész Internet topológiáját tárolni kellene, ami még az AS szinten is túl sok. 1996 elején mintegy 2-3000 AS volt az Internetben egy OSPF terület javasolt maximális mérete pedig csupán 200 link. Az IETF kitalált tehát egy közbülsô, új megoldást, az út-vektorokat (path vectors).
A módszer az, hogy minden terjesztett útvonalban a célpontig
vezetô teljes útvonalat leírjuk. Így a
hurokmentességet minden router könnyen ellenôrizheti: ha
egy kapott útvonalban már szerepel, nem foglalkozik vele
tovább. Ezenfelül nincs szükség valamilyen, az
egész Internetben egységes költség
definiálására, mindenki a teljes útvonalat
saját szempontjai szerint pontozza. Az eljárás
hátulütôje a nagy memóriaigény. Ha az
útvonal a célpontig vezetô AS-ek listája, akkor
az átlagos útvonalhossz az Internet „sugara",
nagyjából a definiált AS-ek számának
logaritmusa. Természetesen az egy AS-en belüli célpontokhoz
ugyanaz az útvonal vezet, így tulajdonképpen nem minden
célponthoz, hanem minden AS-hez tartozik egy útvonal és
minden útvonalhoz felsoroljuk, hogy milyen célpontokhoz vezet.
Ha tehát A az AS-ek száma, N a célpontok
(hálózatok) száma és egy AS illetve
hálózat leírásához x illetve
y byte szükséges, a BGP táblázat mérete
a byte lesz. Becsült értékeket
tartalmaz a következô táblázat [RFC1265]:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A router-ekben szükséges memóriaméret jócskán meghaladja majd ezeket az adatokat, hiszen minden szomszédunkhoz tárolni kell ezeket az információkat, ráadásul gyorsan visszakereshetô (például indexelt) formában. A táblázat elsô sora az RFC1265 idôpontját tükrözi, 1991 novemberét. 1994 februárjában már 25.000 célpont létezett és a növekedés továbbra is exponenciális. A fô memóriaigény nem annyira az út-vektorok letárolásából adódik, mint inkább abból, hogy minden célpontot föl kell sorolni. Ezen csak a CIDR segíthet.
Minden út-vektor AS-ek egy listája, különbözô attribútumokkal együtt. Nem minden attribútumot kötelezô felismernie a BGP implementációknak, vannak opcionálisak. Léteznek ezenkívül tranzitív attribútumok, melyeket az út-vektor továbbadásakor is tovább kell adni még akkor is, ha mi nem ismertük fel. Ilyenkor azonban egy bit beállításával jelezhetjük, hogy valaki az útvonal mentén nem értette meg az attribútumot, így annak értékét ha esetleg kellett is nem aktualizálta. A BGP-3 5 attribútumot definiált:
A BGP router-ek nem csupán a szomszédos AS-ben levô BGP router-ekkel építenek ki kapcsolatot, hanem a saját AS-ükben lévôkkel is. Az elôbbieket külsô, az utóbbiakat belsô partnereknek nevezzük (external peer, internal peer). A belsô kapcsolatra azért van szükség, mert ha a B router X-bôl kap egy sereg út-vektort, akkor azokat el kell juttatnia Z összes többi BGP router-éhez, hogy azok továbbadhassák. Erre az EGP esetén is szükség volt, hisz a kapott célpontokat költségükkel együtt el kellett juttatni az AS többi EGP router-éhez. Ezt azonban az EGP úgy oldotta meg, hogy külsô utakként beinjektálta az IGP protokollba a kapott információt, amit aztán az IGP el is terjesztett az egész AS-en belül. A legtöbb IGP lehetôséget ad arra, hogy a külsô utak mellé rövid „megjegyzést" fûzzenek az EGP router-ek. (A RIPv2-ben 16 bit, az OSPF-ben és EIGRP-ben 32 bit.) Ez elegendô a költségek továbbítására, azonban a teljes út-vektor átadására külön kapcsolatot kell kiépíteni. Természetesen a BGP is átadja az elérhetôségi információt az IGP-nek, hogy az IGP router-ek is tudjanak a külsô célpontokról, de az út-vektorok átadása a BGP kapcsolaton zajlik. Ezen keresztül egyeznek meg a BGP router-ek abban is, hogy több lehetséges külsô útvonal közül melyiket használja az AS (ezt adják át az IGP-nek) és hogy mit terjesszenek kifelé. Szigorú harmóniának kell uralkodnia ugyanis abban, hogy milyen útvonalat adnak át az IGP-nek és milyen hálózatok elérhetôségét terjesztik kifelé, hiszen a kintrôl érkezô csomagokat a belépô router-tôl az AS-en keresztül az IGP fogja eljuttatni a kilépô BGP router-hez.
Természetesen nincs szükség az AS minden BGP router-e között belsô kapcsolatra, csupán arról kell meggyôzôdni, hogy a kapcsolatok teljes konnektivitást eredményeznek a BGP router-ek között.
Maga a BGP kapcsolat TCP fölött épül ki. Ezzel elsôsorban a protokoll vált egyszerûbbé, mert nincs szükség annak figyelésére, hogy elküldött üzenetünket nyugtázta-e már a vevô fél. Hátránya viszont, hogy így a titkosítás megoldhatatlan a TCP titkosítása nélkül, hiszen elég egy a TCP kapcsolat bontására szolgáló csomagot küldeni az egyik oldalnak és a kapcsolat lebomlik. Így könnyû zavart okozni. Másik hátrány, hogy a TCP meglehetôsen érzékeny a torlódásokra (sok újraküldés), ám ez okos TCP implementációkkal kivédhetô. Minthogy a TCP byte-stream jellegû kommunikációt tesz lehetôvé, a BGP pedig üzenetekben kommunikál, minden üzenet elején 16 byte szolgál az üzenet elejének azonosítására és a jövendôbeli hitelesítésre. Ezen felül az üzenet tartalmazza saját hosszát, így a vevônek nincs más dolga, mint bevárni a megadott számú byte-ot, utána rögtön a következô üzenet eleje jön majd.
A BGP router-ek a TCP kapcsolat kiépítése után egy OPEN üzenetet küldenek el, melyben megegyeznek a BGP használt verziójáról, közlik, saját AS-ük számát, saját azonosítójukat és azt, hogy ôk milyen gyakran küldenek majd KEEPALIVE üzenetet. Ha mind a két router egyidôben épített ki TCP kapcsolatot (ütközés), akkor a kisebbik azonosítójú által létrehozottat törlik. A kapcsolat véglegesítése elôtt mindkét fél leellenôrzi, hogy az adminisztráció engedélyezte-e a másikkal való kapcsolattartást. Ha nem, bontják a kapcsolatot.
Ha a kapcsolat kiépült, a BGP router-ek a terjesztésre szánt összes útvonalukat közlik egymással, minden útvonalat külön frissítô (UPDATE) üzenetben. Miután ez megtörtént, már csak a változásokról értesítik egymást. A hibákról (például helytelen szintaktikájú üzenet, rossz BGP verziószám, stb.) egy harmadik fajta üzenetben értesítik egymást (NOTIFICATION).
A TCP használata miatt a pároknak nincs lehetôségük a kapcsolat meglétének tesztelésére, hisz ha nincs átküldendô adat, a TCP nem bocsát ki IP csomagokat. Ennek érdekében, ha már egy jó ideje se UPDATE, se NOTIFICATION üzenet elküldésére nem volt szükség, akkor egy rövid KEEPAILVE üzenetet küldenek egymásnak, a kapcsolat kiépítésekor megállapított idôközönként. Ha ez alatt az idô alatt semmiféle üzenet nem jön, vagy a TCP a kapcsolat megszakadásáról számol be, akkor a BGP elérhetetlennek tekinti partnerét.
A BGP 3 listát (Route Information Base, RIB) tart nyilván, egyben azokat az utakat tárolja, melyeket szomszédaitól hallott (RIB-In), a másikban azokat, melyeket terjeszt (RIB-Out), a harmadikban azokat, melyeket az AS használ (local-RIB). Az elsô két listából minden szomszédos AS-hez tartozik egy-egy, azoknak az utaknak amit onnan hallott és oda terjeszt. A BGP döntési folyamat a következô:
A BGP-4 legfontosabb változtatása az, hogy a célpontok immáron prefixek. A BGP implementáció nem IP cím + maszk párosával írja le a prefixeket, hanem egy 1 byte hosszúságú hossz mezôvel, mely a prefix bitben mért hosszát adja meg és magának a prefixnek érékes bitjeivel. Tekintsük az alábbi szituációt.
Z Q felé összesen 3 út-vektort hirdethet:
Útvonal: Z, célpont: 152.64.0.0 /15 Útvonal: Z, X, célpont: 152.66.0.0 /16 Útvonal: Z,Y, célpont: 153.66.0.0 /16
Az CIDR logika ilyenkor aggregálást követel, hiszen ez a címtér egyetlen egy prefixbe is összefogható, nevezetesen a 152.64.0.0 /14-be. Felmerül azonban a kérdés, hogy mely AS-ek szerepeljenek az út-vektorban? Csak Z-t feltüntetni veszélyes, hiszen így kihagynánk X-t és Y-t, ami a hurkok észlelésénél lenne nagy hiányosság. Erre azt a megoldást vezették be, hogy az út-vektorok egyes szakaszai AS-ek sorozatát, mások pedig halmazát írják le. A sorozat egymás után következô AS-eket sorol fel, melyek mindegyikén keresztülhalad a csomag a célpont felé. A halmaz viszont azt jelenti, hogy a felsorolt AS-ek egyikén-másikán halad csak végig a csomag. A Q felé küldött hirdetmény tehát:
Útvonal: sorozat(Z), halmaz(X,Y), célpont 152.64.0.0 /14
Ehhez Q a következôképp fûzi magát hozzá:
Útvonal: sorozat(Q, Z), halmaz(X, Y).
Maga a BGP-4 egy üzenetben szintén egy út-vektort ír le, de kétféle célpontot sorol fel, az egyik melynek elérhetôségét hirdeti, a másik, melyeknek elérhetetlenségét. Ily módon nincs szükség a BGP-3 elérhetetlenséget jelzô attribútumára, valamint egy hirdetménnyel vissza is vonhatunk célpontokat és újakat is közölhetünk.
Két új attribútum került bevezetésre, az egyik az „aggregator", amit az az AS helyez el, amelyik aggregációt hajtott végre, leírva benne az aggregációt végzô router-t és az AS számát. Ez fôként hibák felderítésére használatos. A másik az „atomic aggregate", melyet akkor illesztünk az út-vektorhoz, ha a megadott célpontoknál hosszabb, azaz pontosabb prefixek is léteznek, de az üzenet méretének csökkentése érdekében ezeket egy, rövidebb prefixbe fogta össze valamelyik AS.
Mint a CIDR áttekintésében láttuk, fontos, hogy mindig a hosszabb prefixû, vagyis a jobban illeszkedô útvonalon továbbítsuk a csomagot, mert igazából az garantálja a csomag célbaérkezését. A rövidebb prefixrôl nem állíthatjuk, hogy az útvonal arra elérhetetlen, mindössze annyit, hogy a hosszabb prefixben inkább bízhatunk. A jobban illeszkedô prefix útvonala azonban nem mindig a rövidebb, azaz optimális útvonal. A fenti ábrán Q a következô két hirdetményt kapja rendre Z-tôl és W-tôl:
Z: Útvonal: sorozat(Z), halmaz (X, Y), célpont: 152.64.0.0 /14 W: Útvonal: sorozat (W, V, Y), célpont: 152.67.0.0 /16
Q-nak tehát döntenie kell, melyiket használja, ha a 152.67.0.0/16-ra kíván csomagot küldeni. Ez merôben egy lokális kérdés, Q bízhat a Z által terjesztett rövidebb prefixben is, vagy választhatja a hosszabb, de „biztosabb" utat is. Ez utóbbi esetben a Q-n belül mûködô IGP táblázataiba két prefixet kell beinjektálni, egyet-egyet a hosszabb és a rövidebb prefixszel. Sajnos ilyen „egymást fedô" bejegyzéseket jelenleg még azok az IGP protokollok sem képesek kezelni, amelyek egyáltalán lehetôvé teszik a prefixek használatát. Így ha W pontosabb útját is terjeszteni akarjuk, fel kell bontanunk a Z által terjesztett rövidebb prefixet, hogy ne tartalmazza a 152.67.0.0 /16-t, ami felé a forgalmat W-be irányítjuk. Úgy teszünk tehát, mintha az alábbi két hirdetményt kaptuk volna.
Útvonal: sorozat(Z), halmaz (X, Y), célpont: 152.64.0.0 /15 és 152.66.0.0 /16 Útvonal: sorozat (W, V, Y), célpont: 152.67.0.0 /16
Ez azonban hatással lesz arra, amit Q kifelé hirdetni fog. Vagy a de-aggregált utakat külön-külön terjeszti, vagy újra-aggregálja ôket, az alábbiak szerint.
Útvonal: sorozat (Q), halmaz (X, Y, V, W, Z) célpont: 152.65.0.0 /14
Ekkor azonban Q egy „láthatatlan" aggregációt hajtott végre, amit az „atomic aggregate" attribútum beállításával jelez. Ez mutatja, hogy a célpont egyes részeihez voltak pontosabban illeszkedô útvonalak, amiket azonban aggregálással eltüntettünk (és egy halmazba zsúfoltunk).