A forgalomirányítók felépítése

A forgalomirányító tehát a forgalomirányító tábla bejegyzései alapján az interfészei között továbbítja a csomagokat. Részletesebb felépítése látható a 5.4 ábrán. Az interfészeitportoknakis szokták nevezni. A portokat/interfészeket egy-egy csomag szempontjából feloszthatjuk bemenetiés kimenetiportra. Ha portokat pontosabban szeretnénk meghatározni, akkor ezek olyan logikai elemek melyek hálózati rétegbeli címekkel bírnak. Az interfész tehát általában fizikai (pl.:

Ethernet), míg a port jellemz˝oenlogikai (egy Ethernet interfészen két logikai cím/port). Ezen portokat megvalósító szoftver megoldások (adott esetben egy-egy processz) a bejöv˝o csomagokat egy memória területre másolják. Ezt nevezzükbemeneti portnak (input port), vagybemeneti várakozási sornak (input buffer/queue). Az itt lév˝o csomagokat a kapcsoló motor (switch matrix) segítségével átmásolja a forgalomirányító a megfelel˝o interfész megfelel˝o portjának memória területére. Ez a kimeneti port (output port) és kimeneti várakozási sor (output buffer/queue).

Kiemelt jelent˝osége van annak, hogy mind a bemeneti, mind a kimeneti memória területen több csomag is elfér. Ennek akkor van jelent˝osége, amikor több csomag érkezik mint amennyit a kapcsoló motor át tudna másolni a kimeneti sorhoz, vagy ami sokkal jellemz˝obb, több csomag érkezik be a bemen˝o porton mint amennyit továbbítani lehetne a kimeneti porton. Ekkor a memóriában várakoznak.

Fontos Amennyiben a memória megtelik, akkor a forgalomirányító adott csomagokat egyszer˝uen figyelmen kívül hagy. Ezt gyakran a csomag törlésével valósítja meg. Ez az a pont, ahol a legjobb szándék szerinti továbbítás, az Internet egyik alapelve leginkább megfigyelhet˝o.

Azt a jelenséget amikor bemeneti port várakozási sorában a csomagokat sorban dolgozza fel és épp a továbbítandó csomagot nem tudja továbbítani a célport foglaltsága miatt HOL (sor

5.3: Hálózati réteg adatsík vs. vezérl˝osík¹

5.4: várakozási sorok és HOL blokkolás¹

eleji blokkolásnak - head of line blocking)nevezzük. Ezt lehet úgy kezelni hogy a sorrendet felborítva azokat továbbítja amelyeket tudja ez anem sorrendhelyes továbbítás (out of order delivery). Látjuk, hogy fizikai hibák nélkül is felborulhat a csomagok sorrendje és elt˝unhetnek csomagok. Ezek kezelését végzi a már megismert TCP. A várakozási sorok kezeléséhez az eddigiekben aFIFO (el˝oször be, el˝oször ki - First In First Out)megoldásról beszéltünk, mint legtermészetesebb algoritmusról. Van azonban olyan eset, amikor meg szeretnénk különböztetni a forgalmat. Például a telefon hívásokat el˝onyben szeretnénk részesíteni a fájl letöltésekkel szemben.

Ezt a mai Internet architektúrában csak itt, a várakozási sor menedzsmentben tudjuk megoldani.

Ennek egyik lehetséges módja aprioritásos ütemezés (priority queueing). Ekkor több várakozási sor van és a magasabb prioritásúak vannak el˝onyben részesítve, azaz ha ott van csomag akkor azokat kezeli. Itt probléma lehet az alacsonyabb prioritású sorok kiéheztetése. Erre megoldást nyújt a WFQ súlyozott igazságos ütemezés (weighted fair queuing). Ekkor adott súlynyi darabot továbbít minden sorból. A várokozási sorok elmélete nagyon komoly múlttal és mélységgel bír a távközlésben. Egy jó kiinduló pont lehet ez a könyv a terület mélyebb megismerésére [1].

A kapcsoló motor több módon is megvalósítható. Lehet egyszer˝umemória másolás, vagyosztott memóriaa részvev˝o processzusok között. Ez a megoldás gyors, de ekkor perifériák (interfészek) is

5.5: Prioritásos és súlyozott prioritásos várakozási sorok¹

fizikailag ugyanazon az alaplapon helyezkednek el, így ennek a skálázhatósága korlátos. Lehetbusz rendszer ˝uis, amikor a perifériák már saját memóriával bírnak, ilyenkor egy elosztott rendszerünk (a perifériák képesek önálló programot futtatni, különálló kis számítógépek) van és az egyes perifériák, illetve a központ a buszon keresztül kommunikálnak egymással. Ez a megoldás már skálázhatóbb, mert a buszra újabb és újabb perifériákat köthetünk, ezeket kicserélhetjük stb., de a busz sávszélessége és az, hogy egyszerre csak egy kommunikációs viszonyt engedélyez, komoly sz˝uk keresztmetszetet okoz. A legnagyobb kapacitású forgalomirányítók teljes rács (crossbar)megoldással bírnak, amely egy adott pillanatban minden portot minden porttal a teljes port sávszélességgel tud összekötni. Itt tehát egyid˝oben az összes port adhat/vehet bármelyik másik porttal. Itt is probléma persze, ha több port akar egy porttal beszélni, ekkor az adott port várakozási sora kezeli ezt az ütközést.

5.6: Kapcsoló megoldások¹

Azt hogy a kapcsoló motor honnan tudja, hogy kit kivel kell összekötni, az mint ahogy említettük, csomagonként d˝ol el: a bemeneti várakozási sorban egy helyi vagy központi processzus kiválasztja a továbbküldend˝o csomagot és kiolvassa annak megfelel˝o mez˝ojét (ez IP csomagoknál a cím mez˝o, de mint látjuk kés˝obb a szoftverrel definiált hálózatok esetén itt több mez˝ot is figyelembe vehet).Ezt a mez˝ot vagy ezen mez˝oket összeveti a forgalomirányító vagy továbbítási táblázat a megfelel˝o mez˝ovel és megkeresi ott a pontosan (vagy legjobban) egyez˝o sort és abban a sorban megadott kimeneti portra másolja, vagy mint látni fogjuk SDN esetén adott utasításokat hajt végre. Ez a keresés, bár egyszer˝unek t˝unik, korántsem triviális feladat. Ma a gerinc forgalomirányítókon kb.: 500.000 bejegyzés van, ez még nem is olyan sok, de gondoljunk bele, hogy olyan gyakran jönnek be csomagok, hogy ezt meg kell tenni másodpercenként 1.000.000 és 10.000.000 közötti alkalommal egy 10 GBits-os vonalon csomag mérett˝ol függ˝oen. Ezt a feladatot ezért jellemz˝oen nem szoftveresen, hanem hardveresen oldják meg speciális ASIC alkalmazásspecifikus integrált áramkör (application-specific integrated circuit)segítségével,

amely egy memória ciklus alatt visszaadja az egyez˝oCAM - tartalommal címezhet˝o memória (content addressable memory)vagy a leginkább egyez˝oTCAM - hármas tartalommal címezhet˝o memória (ternary content addressable memory)bejegyzést. Az eddig leírt m˝uködésben általánosságban kezeltük a csomagokat, a következ˝oekben konkrét hálózati rétegbeli protokollokat tekintünk át.