1. fejezet

A hálózat mint platform

„Think of it as a general languageor an instruction set that lets mewrite a control program for thenetwork rather than having torewrite all of code on eachindividual router.”

— Scott Shenker, Berkeley

Kivonat – A 2000-es évek vége óta a számítógéphálózatok világábanvírusszerűen terjed a szoftveresen vezérelhető hálózatok (SoftwareDefined Networking SDN) paradigmája, ami a szoftvervilágra jel-lemző architekturális elemekre épül. Az SDN-ben a hálózat kapcso-lóit és összeköttetéseit együttesen tekintjük a hardvernek, melyekhezhálózati operációs rendszeren (Network Operating System NOS) ke-resztül lehet hozzáférni. A operációs rendszer felett alkalmazásokfuttathatók, amelyek a hálózat funkcionalitását a kapcsolóeszközökprogramozásán keresztül megadják. Hasonló ez ahhoz, hogy az okos-telefon hardverén fut az operációs rendszer (IOS, Android stb.), amifelett alkalmazások futtathatók. Az SDN hálózatok villámgyors elő-retörése és terjedése azt is magával hozta, hogy ezek ismerete nemhiányozhat egy magára valamit is adó B.Sc.-s informatikus kelléktá-rából.

Mielőtt az SDN tárgyalására rátérnénk idézzük fel a hagyományos hálózatiarchitektúra néhány jellemvonását, hogy aztán minél jobban érezhessük az SDNparadigmaváltás újszerűségét.

1

2 1. FEJEZET. A HÁLÓZAT MINT PLATFORM

VERSION 2.01 4

Fig. 3. Layered view of networking functionality.

However, the outcome is a very complex and relativelystatic architecture, as has been often reported in the networkingliterature (e.g., [1], [3], [2], [6], [19]). It is also the fundamentalreason why traditional networks are rigid, and complex tomanage and control. These two characteristics are largely re-sponsible for a vertically-integrated industry where innovationis difficult.

Network misconfigurations and related errors are extremelycommon in today’s networks. For instance, more than 1000configuration errors have been observed in BGP routers [20].From a single misconfigured device may result very undesirednetwork behavior (including, among others, packet losses,forwarding loops, setting up of unintended paths, or servicecontract violations). Indeed, while rare, a single misconfiguredrouter is able to compromise the correct operation of the wholeInternet for hours [21], [22].

To support network management, a small number of vendorsoffer proprietary solutions of specialized hardware, operatingsystems, and control programs (network applications). Net-work operators have to acquire and maintain different man-agement solutions and the corresponding specialized teams.The capital and operational cost of building and maintaininga networking infrastructure is significant, with long return oninvestment cycles, which hamper innovation and addition ofnew features and services (for instance access control, loadbalancing, energy efficiency, traffic engineering). To alleviatethe lack of in-path functionalities within the network, a myriadof specialized components and middleboxes, such as firewalls,intrusion detection systems and deep packet inspection en-gines, proliferate in current networks. A recent survey of 57enterprise networks shows that the number of middleboxesis already on par with the number of routers in currentnetworks [23]. Despite helping in-path functionalities, thenet effect of middleboxes has been increased complexity ofnetwork design and its operation.

III. WHAT IS SOFTWARE-DEFINED NETWORKING?The term SDN (Software-Defined Networking) was origi-

nally coined to represent the ideas and work around OpenFlowat Stanford University [24]. As originally defined, SDN refersto a network architecture where the forwarding state in the dataplane is managed by a remote control plane decoupled fromthe former. The networking industry has on many occasions

shifted from this original view of SDN, by referring toanything that involves software as being SDN. We thereforeattempt, in this section, to provide a much less ambiguousdefinition of software-defined networking.

We define an SDN as a network architecture with fourpillars:

1) The control and data planes are decoupled. Controlfunctionality is removed from network devices that willbecome simple (packet) forwarding elements.

2) Forwarding decisions are flow-based, instead of destina-tion-based. A flow is broadly defined by a set of packetfield values acting as a match (filter) criterion and a setof actions (instructions). In the SDN/OpenFlow context,a flow is a sequence of packets between a source anda destination. All packets of a flow receive identicalservice policies at the forwarding devices [25], [26]. Theflow abstraction allows unifying the behavior of differenttypes of network devices, including routers, switches,firewalls, and middleboxes [27]. Flow programmingenables unprecedented flexibility, limited only to thecapabilities of the implemented flow tables [9].

3) Control logic is moved to an external entity, the so-called SDN controller or Network Operating System(NOS). The NOS is a software platform that runs oncommodity server technology and provides the essentialresources and abstractions to facilitate the programmingof forwarding devices based on a logically centralized,abstract network view. Its purpose is therefore similar tothat of a traditional operating system.

4) The network is programmable through software appli-cations running on top of the NOS that interacts withthe underlying data plane devices. This is a fundamentalcharacteristic of SDN, considered as its main valueproposition.

Note that the logical centralization of the control logic, inparticular, offers several additional benefits. First, it is simplerand less error-prone to modify network policies through high-level languages and software components, compared with low-level device specific configurations. Second, a control programcan automatically react to spurious changes of the networkstate and thus maintain the high-level policies intact. Third, thecentralization of the control logic in a controller with globalknowledge of the network state simplifies the development ofmore sophisticated networking functions, services and appli-cations.

Following the SDN concept introduced in [5], an SDN canbe defined by three fundamental abstractions: (i) forwarding,(ii) distribution, and (iii) specification. In fact, abstractions areessential tools of research in computer science and informationtechnology, being already an ubiquitous feature of manycomputer architectures and systems [28].

Ideally, the forwarding abstraction should allow any for-warding behavior desired by the network application (the con-trol program) while hiding details of the underlying hardware.OpenFlow is one realization of such abstraction, which canbe seen as the equivalent to a “device driver” in an operatingsystem.

1.1. ábra. A hálózatok síkjai

1.1. A hagyományos hálózati architektúra

A számítógép hálózatok három jól elkülöníthető funkcionalitású síkra osztha-tók, az adat, vezérlő és menedzsment síkok (ábra). Az adatsík gyakorlatilaga hálózati (kapcsoló) eszközöket tartalmazza, amelyek feladata nem más, minta csomagok hatékony továbbítása. A vezérlő sík különböző protokolljai oldjákmeg, hogy a kapcsolóeszközökben levő kapcsolási táblázatok megfelelően kitöl-tődjenek, míg a menedzsment síkban lehet megadni és nyomon követni a kívánthálózati funkcionalitást. Tehát a menedzsment sík definiálja, a vezérlő sík ki-kényszeríti, az adatsík pedig végrehajtja a kívánt működést. A konkrét példakedvéért vegyük azt, hogy a hálózatunkon legrövidebb útválasztást szeretnénkmegvalósítani. Ezzel a menedzsment síkban annyi a teendőnk, hogy mindeneszközön OSPF1 (Open Shortest Path First) modulokat indítunk el. Az OSPFmint vezérlési protokoll elosztott módon kiszámolja a legrövidebb utakat és beál-lítja az útválasztási táblákat az eszközökben, amelyek végül az adatsíkon ennekmegfelelően irányítják a csomagokat.

A hagyományos IP hálózatokban a vezérlő és az adat síkok szinte mindenesetben egy fizikai eszközben kerülnek megvalósításra (tehát a fenti példában azOSPF protokoll a routerben van megvalósítva) és az architektúra nagy mérték-ben elosztott (vagyis az OSPF egy-egy példánya minden routeren fut). Ennekoka elsősorban az, hogy a számítógéphálózatok korai szakaszában a hibatűréselsődleges szempont volt, és extrém jó hibatűrést elosztott viselkedéssel lehetmegvalósítani.

1Mi az OSPF

1.2. AZ SDN DEFINÍCIÓJA, SÍKJAI ÉS RÉTEGEI 3

A hagyományos rendszerek, amennyire hibatűrőek, annyira bonyolultak ésstatikusak. A bonyolultságot a fenti OSPF-es példán illusztrálhatjuk. Ahhoz,hogy a világ legegyszerűbb útválasztási algoritmusát implementáljuk egy teljeselosztott protokollt kell tervezni. Természetesen a tervezés nagy része nem ma-gának az útválasztásnak az implementálására megy (ami kb. öt perc), hanemarra, hogy az elosztott hálózati protokoll valami egységes viselkedés felé konver-gáljon. A statikusság egész egyszerűen az, hogy gyakorlatilag lehetetlen a gyorsinnováció egy hagyományos hálózatban, hiszen minden egyes új szolgáltatáshoz,egy új elosztott protokollt kell megvalósítani és a routerekbe feltölteni. Ráadá-sul mivel a vezérlő és az adatsík is a kapcsolóeszközökben van implementálva,gyakorlatilag az eszközgyártók határozzák meg, hogy mire lehet egy hálózatotegyáltalán használni.

Ezen felül a hálózat menedzsmentje is elképesztően problémás. Ezt jól il-lusztrálja az, hogy a hibás hálózati beállításokból eredő helytelen működés ezegyik legelterjedtebb hibajelenség ma a hálózatok körében. Egy rosszul beállí-tott eszköz természetesen hat a környezetére is, ami sokféle nehezen felderíthetőhibajelenséget produkálhat (pl. csomagvesztés, továbbítási hurkok, hibás út-vonalak). Bár szerencsére ritka, de egyetlen rosszul beállított router órákigmegzavarhatja a teljes Internet viselkedését.

Jelenleg a hálózati eszközök menedzsmentjére minden nagyobb gyártónak(CISCO, Juniper stb.) saját zárt megoldása van egy adott hardver-szoftver kon-figurációval rendelkező eszközre. Magyarul, egy heterogén eszközökből felépítetthálózati infrastruktúra menedzsmentjéhez speciális szakértő csapatok kellenek,amelyek az egyes gyártók menedzsment termékeivel tisztában vannak (és akkormég nem is beszéltünk a különböző gyártók eszközeinek inkompatibilitásábóladódó problémákról). Ez rettenetesen drága és felesleges. Egy hálózat beru-házási és működtetési költsége rendkívül magas lett, hosszú megtérülési időkkelami szintén az innováció ellen hat, tovább növelve a rendszer statikusságát. Ahálózati eszközök rugalmatlansága oda vezetett, hogy az innovatív megoldásokat(pl. terheléskiegyenlítés, energiahatékonyság, biztonság stb. ) külön eszközökbe(middlebox) kezdték el telepíteni (pl. tűzfalak, behatolásérzékelők, csomagana-lizátorok). Mára ott tartunk, hogy az hálózatba csatolt middlebox-ok számagyakran nagyobb mint a kapcsolóeszközök száma [23]. Arról ne is beszéljünk,hogy a middlebox-okat szintén menedzselni kell ...

1.2. Az SDN definíciója, síkjai és rétegeiAz SDN paradigma alapjaiban alakítja át azt a képet, ahogyan a számítógéphálózatokról gondolkodunk. Az SDN hálózatokat a következő négy alapelv se-gítségével definiáljuk:

1. Definíció (Software Defined Networking (SDN)).

• A vezérlő és adatsíkok szétválasztása. A vezérlési funkciókat kivesszüka kapcsolóeszközökből, amik ezek után egyszerű csomagtovábbító elemekké

4 1. FEJEZET. A HÁLÓZAT MINT PLATFORM

válnak mindenféle intelligencia nélkül.

• A kapcsolási döntéseket nem csomag, hanem folyamszinten hozzuk meg.Egy folyam azonosítása elég szabadon, a csomagfejléc mezők illesztéséveltörténik. Az illesztés egy rendkívül gyors folyamat (nagyjából egy általá-nosított logikai ÉS művelet), amiben egy ún. folyamtáblában megnézzük,hogy az éppen feldolgozott csomagra van-e a táblában érvényes bejegyzés.Például definiálhatunk egy folyamot a forrás IP, cél IP párossal, de akárportszámok vagy hardvercím alapján is. Egy folyamhoz aztán a folyamtáb-lában megadjuk, hogy egy adott kapcsolóeszközben milyen művelet hajtódjonvégre a folyamhoz tartozó csomagokon. Ugyanahhoz a folyamhoz tartozócsomagokon értelemszerűen ugyanazokat a műveleteket hajtjuk végre [25],[26]. A folyamszintű kapcsolás lehetővé teszi, hogy eddig különféle hálóza-ti eszközöket (router, switch, tűzfal és egyéb middlebox-ok) közös keretbenvalósítsunk meg [27]. Például egy tűzfal megvalósítása történhet úgy, hogyegy SDN kapcsolóban egy adott tiltani kívánt folyam csomagjaira az eldo-bás (DROP) műveletet hajtjuk végre. A folyamszintű kapcsolás rendkívülflexibilis és a képzeletnek szinte csak a folyamtáblák (általában tartalomcí-mezhető tárban tárolt táblázatok) mérete szab korlátot [9].

• A vezérlési logikát (ami hagyományos IP hálózatokban a kapcsolókban van)egy külső entitásba, a kontrollerbe más nevén a hálózati operációs rendszer-be (Network Operating System (NOS)) költöztetjük. A NOS egy szoftverplatform (mint pl. az Android) ami teljesen szokványos olcsó hardveren(akár egy mezei laptop) is képes futni és azokat az alapfunkciókat tartal-mazza, melyeket a kapcsolóeszközök folyamtábláit fel lehet programozni,akár dinamikusan is. A programozáshoz a NOS a hálózatról alkotott lo-gikailag központosított képpel rendelkezik. Ez azt jelenti, hogy a NOS-nakrendelkezésére áll minden releváns információ a hálózatba csatolt eszkö-zökről és összeköttetésekről, de pl. nem lényeges számára, hogy egy adottkapcsolóeszköz milyen gyártó által került legyártásra. A NOS ilyen érte-lemben nagyon hasonlít a hagyományos operációs rendszerekre, amely agyártók által kiadott vezérlőszoftverek (driver) segítségével absztrakt mó-don tud kezelni egy csomó eszközt. A logikailag központosított azt jelenti,hogy nem feltétlenül vannak egy helyen ezek az adatok,

• A hálózat programozható a NOS felett futó alkalmazások segítségével. Azalkalmazások kommunikálhatnak a kapcsolóeszközökkel és dinamikusan vál-toztathatják azok viselkedését. Ez a lehetőség az SDN legnagyobb ígérete.

A fenti négy alapelvből nagyon sok minden következik. Először is a vezérléslogikai központosítása miatt nem kell elosztott algoritmusokat implementálni(gondoljunk csak bele, mennyivel egyszerűbb egy adott gráf felett a legrövi-debb útválasztást leprogramozni). Másrészről a NOS felett futó alkalmazásokmagas szintű nyelveket is használhatnak ezzel, az alkalmazásfejlesztők sokkalinkább a funkcionalitásra (én nem arra, hogy hogyan fordítsák az adott funk-ciót egy adott eszköz alacsony szintű nyelvére) koncentrálhatnak. Ráadásul a

1.2. AZ SDN DEFINÍCIÓJA, SÍKJAI ÉS RÉTEGEI 5

vezérlőprogram automatikusan reagálhat a hálózat állapotváltozásaira, miköz-ben a hálózat alapvető működésmódján (pl. legrövidebb útválasztás) nem kellváltoztatni. Végül, a kontrollerben összegyűjtött és az alkalmazások számáraelérhetővé tett információ, sokkal kifinomultabb alkalmazások és szolgáltatásokmegvalósítását teszi lehetővé.

1.2.1. Az SDN síkjai

A hagyományos számítógép hálózatokhoz hasonlóan az SDN koncepciót háromsíkra (adat, vezérlési és menedzsment) oszthatjuk, melyek egyben absztrakciósszintek is. Az absztrakciós szintben azt absztrakciós azt jelenti, hogy az alattalevő dolgokat nem teljes részletességükben és bonyolultságában látjuk, hanemcsak egy egyszerűsített „absztrakt” nézetben. Hasonló ez ahhoz, hogy a Li-nuxnak nem kell azt tudnia, hogy egy adott gyármányú merevlemezre íráshozpontosan hogyan kell mozgatni a lemezfejeket, hanem a Linux absztrakt szintjénelég azt tudni, hogy egy blokkos eszközről van szó.

Az SDN adatsíkja a kapcsolóeszközökből és a közöttük levő összeköttetések-ből áll. Az SDN adatsík lehetővé teszi, hogy a hálózati alkalmazások tetszőlege-sen felprogramozhassák a kapcsolóeszközöket, miközben elrejti az eszközök hard-veres részleteit. Az alkalmazások szempontjából nézve ugyanis teljesen mindegy,hogy egy adott SDN kapcsolóban a folyamtáblák hogyan vannak megvalósítva,elég az, hogy egy megfelelően specifikált interfészen keresztül a folyamtáblákállítgathatók. Az OpenFlow pl. egy lehetséges protokoll, amely megvalósítjaa kapcsolók absztrakcióját a vezérlősík felé, melynek működése ezért teljesenanalóg az eszköz meghajtókéval (device driver) a klasszikus operációs rendsze-rekben.

A vezérlősík feladata, hogy elrejtse az alkalmazások elől a hálózatok el-osztottságának bonyolult részleteit. Mindez úgy történik, hogy a hálózatokalapvetően elosztott működését egy logikailag központosított absztrakt nézetbetranszformáljuk. A vezérlősík egyrészt megoldja a kapcsolási logika elosztásáta kapcsolóeszközök között, illetve folyamatosan monitorozza az adatsík topo-lógiáját és viselkedését (pl. számlálókkal) és ezt az információt egy megfelelőinterfészen keresztül elérhetővé teszi a hálózati alkalmazások számára.

Az SDN menedzsment síkja gyakorlatilag nem más mint a megvalósított há-lózati alkalmazások (pl. tűzfal, útválasztás, terheléselosztás), amelyek a hálózattopológiájához és a kapcsolóeszközökhöz a vezérlősík által felkínált absztraktinterfészen keresztül hozzáférnek.

Ezen a ponton illik az SDN síkjairól összehordott általánosságokat példávalillusztrálni. Vegyük ismét a legrövidebb útválasztást mint hálózati alkalmazást.Ennek futtatása SDN-ben kb. a következőképpen történik. A kapcsolóeszközökmegfelelő SDN protokoll (pl. OpenFlow) használatával a dedikált kontrollhá-lózaton keresztül bejelentkeznek a vezérlősíkban levő kontrollerhez, amely re-gisztrálja a csatlakozott eszközöket. Ezt az információt egy API-n keresztül azalkalmazás lekérdezi és az összeköttetések felderítésével gráfot épít belőle. A gráffelett egy bármilyen nyelven megírt gráfos API-val (pl. python-igraph) kiszá-moljuk a legrövidebb utakat és visszaadjuk a kontrollernek, hogy az útvonalon

6 1. FEJEZET. A HÁLÓZAT MINT PLATFORMVERSION 2.01 5

Network Infrastructure Forwarding Devices

Open southbound API

Network(Opera,ng(System((SDN(controllers)(

Network(Abstrac,ons((e.g.,(topology(abstrac,on)(

Open northbound API

Net(App(1( Net(App(2( Net(App(n"

Global network view

Abstract network views

Con

trol

pla

ne

Dat

a Pl

ane

Fig. 4. SDN architecture and its fundamental abstractions.

The distribution abstraction should shield SDN applicationsfrom the vagaries of distributed state, making the distributedcontrol problem a logically centralized one. Its realizationrequires a common distribution layer, which in SDN residesin the NOS. This layer has two essential functions. First,it is responsible for installing the control commands on theforwarding devices. Second, it collects status informationabout the forwarding layer (network devices and links), to offera global network view to network applications.

The last abstraction is specification, which should allow anetwork application to express the desired network behaviorwithout being responsible for implementing that behavioritself. This can be achieved through virtualization solutions,as well as network programming languages. These approachesmap the abstract configurations that the applications expressbased on a simplified, abstract model of the network, into aphysical configuration for the global network view exposedby the SDN controller. Figure 4 depicts the SDN architecture,concepts and building blocks.

As previously mentioned, the strong coupling betweencontrol and data planes has made it difficult to add newfunctionality to traditional networks, a fact illustrated inFigure 5. The coupling of the control and data planes (andits physical embedding in the network elements) makes thedevelopment and deployment of new networking features(e.g., routing algorithms) very hard since it would imply amodification of the control plane of all network devices –through the installation of new firmware and, in some cases,hardware upgrades. Hence, the new networking features arecommonly introduced via expensive, specialized and hard-to-configure equipment (aka middleboxes) such as load balancers,intrusion detection systems (IDS), and firewalls, among others.These middleboxes need to be placed strategically in thenetwork, making it even harder to later change the networktopology, configuration, and functionality.

In contrast, SDN decouples the control plane from thenetwork devices and becomes an external entity: the network

SDN$controller$

Network$Applica2ons$

MAC$Learning$

Rou2ng$Algorithms$

Intrusion$Detec2on$System$

Load$Balancer$

Sof

twar

e-D

efin

ed N

etw

orki

ng

Con

vent

iona

l Net

wor

king

Fig. 5. Traditional networking versus Software-Defined Networking (SDN).With SDN, management becomes simpler and middleboxes services can bedelivered as SDN controller applications.

operating system or SDN controller. This approach has severaladvantages:

• It becomes easier to program these applications since theabstractions provided by the control platform and/or thenetwork programming languages can be shared.

• All applications can take advantage of the same networkinformation (the global network view), leading (arguably)to more consistent and effective policy decisions whilere-using control plane software modules.

• These applications can take actions (i.e., reconfigureforwarding devices) from any part of the network. Thereis therefore no need to devise a precise strategy about thelocation of the new functionality.

• The integration of different applications becomes morestraightforward [29]. For instance, load balancing androuting applications can be combined sequentially, withload balancing decisions having precedence over routingpolicies.

A. Terminology

To identify the different elements of an SDN as unequiv-ocally as possible, we now present the essential terminologyused throughout this work.Forwarding Devices (FD): Hardware- or software-based dataplane devices that perform a set of elementary operations. Theforwarding devices have well-defined instruction sets (e.g.,flow rules) used to take actions on the incoming packets(e.g., forward to specific ports, drop, forward to the controller,rewrite some header). These instructions are defined by south-bound interfaces (e.g., OpenFlow [9], ForCES [30], Protocol-Oblivious Forwarding (POF) [31]) and are installed in the

1.2. ábra. A hálózat mint platform

levő kapcsolókat állítsa be. A kontroller lefordítja a beállításokat és a kapcso-lóeszközökön futó SDN protokoll (pl. OpenFlow) segítségével felkonfigurálja aőket. Az 1.2 ábráról vizuálisan is érzékelhetjük, hogy az SDN azért nagyon másmint a hagyományos megközelítés.

1.2.2. Az adat és vezérlősík szétválasztásából adódó elő-nyök

A hagyományos hálózatok esetében a vezérlő és adatsíkok ugyanabban az esz-közben történő megvalósítása nagyon megnehezíti a hálózat funkcionalitásánakbővítését, erről korábban már beszéltünk. Egyszerűen mondva, ha a teljes há-lózat vezérlésén változtatni szeretnénk, akkor az összes eszköz vezérlősíkjábanegyszerre módosításokat kell végrehajtani. Ez rendkívül nehézkes és drága, hi-szen ezt legalább firmvare, rosszabb esetben hardver frissítésekkel kell megoldni,ráadásul teljes mértékben eszközre szabottan. Nem meglepő, hogy ezek utánaz innovatív hálózati megoldások nem a hálózati elemekbe, hanem plusz egysé-gekbe ún. middlebox-okba költöztek. Ezek aztán még rugalmatlanabbá teszika hálózat struktúráját.

Ezzel szemben az SDN a vezérlősíkot kiveszi az eszközökből és egy külsőelembe, a hálózati operációs rendszerbe, vagy kontrollerbe teszi át. Ennek szá-mos előnye van:

• Sokkal könnyebb a hálózatot új funkciókkal bővíteni, hiszen egy SDN al-

1.2. AZ SDN DEFINÍCIÓJA, SÍKJAI ÉS RÉTEGEI 7

kalmazás egyszerre használhatja, a kontroller által nyújtott információkatés a magas szintű programozási nyelveket.

• Minden alkalmazás használhatja a hálózatról rendelkezésre álló informá-ciókat ezért sokkal hatékonyabb szolgáltatások készíthetők és a vezérlősíkszoftvermoduljai több modulnál is újrahasznosíthatók.

• Az alkalmazások nagyon könnyen újrakonfigurálhatják a hálózat bármelyrészében levő kapcsolókat, ezért nincs szükség előre eldönteni, hogy hovahelyezzük az egyes funkciókat (pl. terheléselosztó, tűzfal)

• A szolgáltatások integrációja sokkal egyszerűbb. Pl. egyszerűen megad-hatjuk, hogy a terheléselosztó alkalmazásnak nagyobb prioritása legyen arouting alkalmazásnál.

1.2.3. Analógia a szoftver platformok és az SDN közöttMár többször érzékeltettük az analógiát a hardver-szoftver platformok és azSDN mint hálózati platform között, most dolgozzuk ezt ki teljesen. Az egy-szerűség kedvéért tekintsük az okostelefont, mint platformot. Azt valószínűlegmindenki érzi, hogy az okostelefon egy elképesztően sikeres platform, hiszenokostelefonra alkalmazások milliói érhetők el. Milyen architektúra van emögötta sikeres platform mögött. Legalul ott van a hardver (pl. processzor), amit egyadott hardvergyártó cég legyárt. Ezek a hardverek vezérelhetőek egy nyílt, min-denki számára elérhető interfészen keresztül. Ez azt jelenti, hogy a hardver föléa nyílt interfész ismeretében bárki írhat operációs rendszert. Ezért a hardver ésa operációs rendszerek fejlesztése, innovációja teljesen függetlenül végbemehet,amíg ez az interfész változatlan. Az operációs rendszerek ezt a logikát alkal-mazzák felfelé, vagyis egy nyílt interfész biztosítanak az alkalmazások számára,amin keresztül szabályozott keretben hozzáférhetnek a hardver erőforrásokhoz.A nyílt interfész ismeretében (pl. Android SDK) bárki írhat alkalmazásokataz operációs rendszer fölé. Az innováció és a fejlesztések így mind a hardver,mind az operációs rendszer és mind az alkalmazások szintjén párhuzamosan me-hetnek, nem meglepő, hogy a szoftveripar elképesztő növekedést produkált azelmúlt pár évtizedben.

A számítógéphálózatok szegmenségben erre a struktúrára való átállás mostzajlik le. Hogy miről is kell átállni, az a 1.3 ábrán a hálózatok rész pirossalszínezett részében látható. A hagyományos architektúrára az a jellemző ugyan-is, hogy mind a hardver, mind az operációs rendszer (vezérlés), mind pedig azalkalmazások fejlesztését egy adott gyártó tudja csak elvégezni, hiszen a rétegekközött zárt interfészek vannak, így harmadik fél számára lehetetlen a struktú-rába való beavatkozás. Ez nagyon jó az eszközgyártóknak (monopolhelyzet ésdől a lé), de nagyon betesz az innovációnak, hiszen minden új megoldásra azeszközgyártók fejlesztőmérnökeinek bólintania kell. A több éves innovációs cik-lus pl. az adatközpontok esetében elképesztően hosszú, így nem véletlen, hogypl. a Google az első között volt aki az SDN mellé állt, sőt a Google adat-központjainak egy része ma már SDN alapokon működik. Az SDN hasonlóan

8 1. FEJEZET. A HÁLÓZAT MINT PLATFORM

a hardver-szoftver architektúrákhoz nyílt interfészeket használ mind a hálózatihardver és a operációs rendszer, mind pedig az operációs rendszer és az alkal-mazások között. Bár az SDN architektúra még az elterjedés kezdeti fázisábanvan, már most sokkal több alkalmazás elérhető SDN platformra, mint ami ahagyományos architektúrán valaha is rendelkezésre állt.

| 2012. október 10-11. | Infokom2012, Mátraháza1

Overhead-free routing with OpenFlow Gulyás András, Németh Felicián BME-TMIT

Hálózatok

Zárt

Szoftver

Alkalmazások

Nyílt interfészek Gyors innováció

Óriási ipar

Mikroprocesszor

Windows Linux Mac OS

Zárt védett interfészek

Lassú innováció

Speciális hardver

Speciális control

Speciális alkalmazásokNyílt interfész

Nyílt interfész

Alkalmazások

Speciális kapcsoló chipek

Control Control

Nyílt interfész

Nyílt interfész

1.3. ábra. A hálózat mint platform

1.3. Kicsit mélyebben: Az SDN rétegei

Az SDN architektúra a síkok alatt tovább bontható az SDN rétegekre. Azértérdemes egy szinttel lejjebb menni, mert a konkrét funkciók, megoldások és ér-dekességek ezen a szinten mesélhetők el. Hasonlóan más rétegesen elképzelhetőarchitektúrákhoz (mint pl. az emberi hallás) a rétegek és az őket elválasztóinterfészek szerepe az, hogy az interfészek rögzítésével az egyes rétegekben azinnováció (vagy az evolúció) párhuzamosan történhetnek ezzel a fejlődés ütemesokkal gyorsabb lesz. Az SDN rétegeit az 1.4 ábrán a (b) panel mutatja. Ugyan-ezen az ábrán az (a) és (c) panelek rendre az SDN síkokat és az SDN rendszerlogikai felépítését mutatják párhuzamosan. Aki ezt az ábrát megérti mindenttud az SDN koncepcióról.

A továbbiakban alulról felfelé haladva minden rétegnek szentelünk egy rövidszakaszt, ahol legfontosabb funkciókat és technológiákat ismertetjük. Már mostmegjegyezzük, hogy a legfontosabb rétegek, mint a déli interfész, a NOS, azészaki interfész és az alkalmazások minden valós SDN hálózatban megtalálható-ak, míg pl. a hálózati hypervisor nem kötelezően van jelen, csak ha a hálózatbanvirtualizációt is megvalósítunk.

1.3. KICSIT MÉLYEBBEN: AZ SDN RÉTEGEI 9VERSION 2.01 10

Net$App$Net$App$Net$App$Net$App$Net$App$

Net$App$

Network$Infrastructure$

Southbound$Interface$

Network$Opera7ng$System$

Northbound$Interface$

Language<based$Virtualiza7on$

Programming$Languages$

Network$Applica7ons$ Debugging,$Tes7ng$&$Sim

ula7on$

Network$Opera7ng$System$(NOS)$and$

Network$Hypervisors$

Network$Applica7ons$

Rou7

ng$

Access$

Control$

Load

$ba

lancer$

Control plane

Data plane

Management plane

(a)$ (b)$ (c)$

Network$Hypervisor$

Fig. 6. Software-Defined Networks in (a) planes, (b) layers, and (c) system design architecture

A. Layer I: Infrastructure

An SDN infrastructure, similarly to a traditional network, iscomposed of a set of networking equipment (switches, routersand middlebox appliances). The main difference resides in thefact that those traditional physical devices are now simpleforwarding elements without embedded control or softwareto take autonomous decisions. The network intelligence isremoved from the data plane devices to a logically-centralizedcontrol system, i.e., the network operating system and ap-plications, as shown in Figure 6 (c). More importantly,these new networks are built (conceptually) on top of openand standard interfaces (e.g., OpenFlow), a crucial approachfor ensuring configuration and communication compatibilityand interoperability among different data and control planedevices. In other words, these open interfaces enable controllerentities to dynamically program heterogeneous forwardingdevices, something difficult in traditional networks, due tothe large variety of proprietary and closed interfaces and thedistributed nature of the control plane.

In an SDN/OpenFlow architecture, there are two mainelements, the controllers and the forwarding devices, as shownin Figure 7. A data plane device is a hardware or softwareelement specialized in packet forwarding, while a controlleris a software stack (the “network brain”) running on a com-modity hardware platform. An OpenFlow-enabled forwardingdevice is based on a pipeline of flow tables where each entryof a flow table has three parts: (1) a matching rule, (2)actions to be executed on matching packets, and (3) countersthat keep statistics of matching packets. This high-level andsimplified model derived from OpenFlow is currently the mostwidespread design of SDN data plane devices. Nevertheless,other specifications of SDN-enabled forwarding devices arebeing pursued, including POF [31], [120] and the NegotiableDatapath Models (NDMs) from the ONF Forwarding Abstrac-tions Working Group (FAWG) [121].

Inside an OpenFlow device, a path through a sequence offlow tables defines how packets should be handled. When a

new packet arrives, the lookup process starts in the first tableand ends either with a match in one of the tables of the pipelineor with a miss (when no rule is found for that packet). A flowrule can be defined by combining different matching fields, asillustrated in Figure 7. If there is no default rule, the packetwill be discarded. However, the common case is to installa default rule which tells the switch to send the packet tothe controller (or to the normal non-OpenFlow pipeline of theswitch). The priority of the rules follows the natural sequencenumber of the tables and the row order in a flow table. Possibleactions include (1) forward the packet to outgoing port(s), (2)encapsulate it and forward it to the controller, (3) drop it, (4)send it to the normal processing pipeline, (5) send it to thenext flow table or to special tables, such as group or meteringtables introduced in the latest OpenFlow protocol.

As detailed in Table III, each version of the OpenFlowspecification introduced new match fields including Ethernet,IPv4/v6, MPLS, TCP/UDP, etc. However, only a subset ofthose matching fields are mandatory to be compliant to a givenprotocol version. Similarly, many actions and port types areoptional features. Flow match rules can be based on almostarbitrary combinations of bits of the different packet headersusing bit masks for each field. Adding new matching fieldshas been eased with the extensibility capabilities introducedin OpenFlow version 1.2 through an OpenFlow ExtensibleMatch (OXM) based on type-length-value (TLV) structures.To improve the overall protocol extensibility, with OpenFlowversion 1.4 TLV structures have been also added to ports, ta-bles, and queues in replacement of the hard-coded counterpartsof earlier protocol versions.

Overview of available OpenFlow devicesSeveral OpenFlow-enabled forwarding devices are available

on the market, both as commercial and open source products(see Table IV). There are many off-the-shelf, ready to deploy,OpenFlow switches and routers, among other appliances. Mostof the switches available on the market have relatively smallTernary Content-Addressable Memory (TCAMs), with up to

1.4. ábra. Az SDN síkjai, rétegei és rendszerarchitektúrája

1.3.1. 1. Réteg: Infrastruktúra

Az SDN infrastruktúra a hagyományos hálózatokhoz hasonlóan hálózati eszkö-zökből (switch-ek, routerek és egyéb berendezések) áll. Nagy különbség azon-ban, hogy az SDN eszközök nagyon egyszerű kapcsolóelemek mindenféle beágya-zott vezérlőszoftver és egyéb intelligencia nélkül. Az SDN koncepció ugyanisminden intelligenciát a NOS-ba helyez. A kapcsolóeszközökkel szemben egyet-len lényeges kritérium van: az eszközben levő kapcsolási logikát ki kell nyitniés dinamikusan programozhatóvá kell tenni a NOS számára. Az, hogy a kap-csolási logikát ezek után milyen módon oldja meg (pl. általános célú hardverfelett szoftverben, vagy speciális hardverrel pl. tartalomcímezhető memóriával)a kapcsolóeszköz az lényegtelen. Sőt ez ad teret az innovációnak hiszen innentőlkezdve bárki csinálhat SDN kapcsolót bármilyen alapon ha a kapcsolási logika aNOS előtt nyitva áll. Fontos lépés ez a hagyományos hálózatokhoz képes, hiszenegyetlen NOS segítségével elképesztő heterogenitású eszközparkot (pl. vegyesenHP, CISCO, Juniper switch-ek és egyéb szoftver switch-ek pl. extreme) képeseklehetünk egyszerűen irányítani.

Bár nem az egyetlen de az első gyakorlatban is alkalmazható SDN architek-túra az OpenFlow. A OpenFlow kapcsolók logikai működése nagy vonalakbana következő (1.5 ábra). A kapcsolóeszközben egy (vagy több) programozha-tó táblázat, ú.n. folyamtábla van. Minden bejegyzés a folyamtáblában háromrészből áll: (1) illesztési szabály, (2) akciólista és (3) számlálók. Az illesztésiszabály megmondja, hogy az utána következő akciólista mely (pl. Forrás és célIP és port-okkal adott ) folyamokra fusson le. Az akció lehet pl. továbbítás,eldobás stb. A számlálók pedig monitorozzák, hogy a bejegyzésre hány csomagilleszkedett. A folyamtáblába a kontroller (NOS) szabadon hozzáadhat illetvetörölhet bejegyzéseket ezzel megadja a hálózat működését. A folyamtáblák ke-zelése és egyéb infrastruktúrával kapcsolatos adatok áramoltatása a kapcsolókés a kontroller között a déli interfészen keresztül történik.

10 1. FEJEZET. A HÁLÓZAT MINT PLATFORMVERSION 2.01 11

SDN$DEVICE$

SDN$CONTROLLER$

Network$$Opera5ng$$System$ Co

ntrol$

Commun

ica5

ons$

Net$App$Net$App$Net$App$

Net$App$Net$App$Net$App$

FLOW$TABLES$

Control$

Commun

ica5

ons$

RULE% STATS%ACTION%

Packet%+%counters%

1.  Forward%packet%to%port(s)%2.  Encapsulate%and%forward%to%controller%3.  Drop%packet%4.  Send%to%normal%processing%pipeline%

Switch%port%

MAC%src%

MAC%dst%

VLAN%ID%

IP%%src%

TCP%psrc%

TCP%pdst%

IP%%dst%

Eth%type%

FLOW%TABLE%

Fig. 7. OpenFlow-enabled SDN devices

TABLE IIIDIFFERENT MATCH FIELDS, STATISTICS AND CAPABILITIES HAVE BEEN ADDED ON EACH OPENFLOW PROTOCOL REVISION. THE NUMBER OF REQUIRED

(REQ) AND OPTIONAL (OPT) CAPABILITIES HAS GROWN CONSIDERABLY.

OpenFlow Version Match fields Statistics# Matches # Instructions # Actions # PortsReq Opt Req Opt Req Opt Req Opt

v 1.0

Ingress Port Per table statistics

18 2 1 0 2 11 6 2Ethernet: src, dst, type, VLAN Per flow statistics

IPv4: src, dst, proto, ToS Per port statistics

TCP/UDP: src port, dst port Per queue statistics

v 1.1Metadata, SCTP, VLAN tagging Group statistics

23 2 0 0 3 28 5 3MPLS: label, traffic class Action bucket statistics

v 1.2OpenFlow Extensible Match (OXM)

14 18 2 3 2 49 5 3IPv6: src, dst, flow label, ICMPv6

v 1.3 PBB, IPv6 Extension HeadersPer-flow meter

14 26 2 4 2 56 5 3Per-flow meter band

v 1.4 ——

14 27 2 4 2 57 5 3Optical port properties

8K entries. Nonetheless, this is changing at a fast pace. Someof the latest devices released in the market go far beyondthat figure. Gigabit Ethernet (GbE) switches for commonbusiness purposes are already supporting up to 32K L2+L3 or64K L2/L3 exact match flows [122]. Enterprise class 10GbEswitches are being delivered with more than 80K Layer 2 flowentries [123]. Other switching devices using high performancechips (e.g., EZchip NP-4) provide optimized TCAM memorythat supports from 125K up to 1000K flow table entries [124].This is a clear sign that the size of the flow tables is growing ata pace aiming to meet the needs of future SDN deployments.

Networking hardware manufacturers have produced variouskinds of OpenFlow-enabled devices, as is shown in Table IV.These devices range from equipment for small businesses(e.g., GbE switches) to high-class data center equipment (e.g.,high-density switch chassis with up to 100GbE connectivityfor edge-to-core applications, with tens of Tbps of switchingcapacity).

Software switches are emerging as one of the most promis-ing solutions for data centers and virtualized network in-frastructures [147], [148], [149]. Examples of software-basedOpenFlow switch implementations include Switch Light [145],

ofsoftswitch13 [141], Open vSwitch [142], OpenFlow Ref-erence [143], Pica8 [150], Pantou [146], and XorPlus [46].Recent reports show that the number of virtual access ports isalready larger than physical access ports on data centers [149].Network virtualization has been one of the drivers behind thistrend. Software switches such as Open vSwitch have beenused for moving network functions to the edge (with the coreperforming traditional IP forwarding), thus enabling networkvirtualization [112].

An interesting observation is the number of small, start-up enterprises devoted to SDN, such as Big Switch, Pica8,Cyan, Plexxi, and NoviFlow. This seems to imply that SDN isspringing a more competitive and open networking market, oneof its original goals. Other effects of this openness triggered bySDN include the emergence of so-called “bare metal switches”or “whitebox switches”, where the software and hardware aresold separately and the end-user is free to load an operatingsystem of its choice [151].

B. Layer II: Southbound InterfacesSouthbound interfaces (or southbound APIs) are the con-

necting bridges between control and forwarding elements, thus

1.5. ábra. OpenFlow-képes eszköz logikai felépítése

1.3.2. 2. Réteg: Déli interfész

A déli interfész specifikálja a kontroller és a kapcsolóeszközök közötti kommu-nikáció módját. A déli interfész megfelelő részeit ezért mind a kapcsolóeszkö-zökben, mind a kontrollerben implementálni kell. A hagyományos hálózatokbana vezérlősík és az adatsík kommunikációját a kapcsolóeszközök fizikai felépítésealapvetően befolyásolja ezért van az, hogy ahány különböző gyártó és eszközannyi különféle kontrollfelület. Az SDN koncepció zászlóshajója az OpenFlownagy dobása az volt, hogy először definiált olyan déli interfészt, amely a kap-csolóeszközök fizikai felépítésétől függetlenül le tudta írni a logikai viselkedést.Az OpenFlow hatékonyságát és népszerűségét jelzi, hogy szinte minden fon-tosabb hálózati eszközgyártó (CISCO, Juniper stb.) palettáján megtalálhatókOpenFlow-kompatibilis eszközök. Az OpenFlow egy olyan közös platform, amifelett gyártófüggetlen módon lehet a hálózat funkcionalitását manipulálni.

Az OpenFlow lelke az OpenFlow protokoll, amely a kapcsolóelemek és akontroller (még mindig NOS) közötti üzeneteket definiálja. Alapvetően három-féle üzenetcsoport van. Az első csoport eseményvezérelt üzeneteket tartalmaz,melyeken keresztül a kapcsolóeszköz jelezni tudja, ha valami történt a fizikai kör-nyezetében (megszakadt egy link, lement egy port stb.) A második csoport ahálózatban menő forgalomról tájékoztatja a kontrollert (pl. a folyamtábla szám-lálóinak lekérdezése). Az utolsó csoport pedig a kapcsoló logikai működésénekmegadására szolgát. Ezeken keresztül értesülhet a kontroller, ha egy kapcso-ló nem tudja mihez kezdjen egy adott csomaggal és egy megfelelő folyamtáblabejegyzéssel megadhatja a kívánt működést.

1.3.3. 3. Réteg: Hálózati hypervisor

A virtualizáció – melynek alapeleme az ú.n. hypervisor, ami a fizikai eszköz felettvirtualizálja a virtuális rendszerek számára szükséges erőforrásokat – rendkívülelterjedt technológia a számítógépes rendszerek világában. Mindezt jól mutat-ja, hogy a virtuális szerverek száma a különböző adatközpontokban ma mármeghaladja a valós fizikai szerverekét. Miért ez a nagy siker?

Először is azért, mert a virtualizáció lehetővé teszi, hogy ugyanazt a fizikairendszert (számítógépet) több egymástól független virtuális rendszer egy időben

1.3. KICSIT MÉLYEBBEN: AZ SDN RÉTEGEI 11

használja. A virtualizáció jelentette az alapját a felő számítástechnikának (cloudcomputing), ahol a felhasználók rugalmasan foglalhatnak erőforrásokat (CPU,memória, háttértár) egy hatalmas erőforrás silóból sokkal olcsóbban minthamegvásárolnák a számukra szükséges fizikai eszközöket. Ennek oka, hogy afelhő szolgáltató sokkal jobb kihasználtsággal tudja üzemeltetni a rendszerét,amely így sokkal gazdaságosabban működik (az, hogy egy felhasználó a gépétszáz százalékban ki tudja használni olyan ritka mint a fehér holló).

Másodszor a virtualizáció azt is lehetővé teszi, hogy a virtualizált rendsze-reket/szolgáltatásokat elmozgassuk (pl. közelebb a felhasználóhoz), fel - vagyéppen leskálázzuk (ha nagyobb az érdeklődés a szolgáltatásra több szervert in-dítunk, ha kisebb akkor lekapcsoljuk ami nem szükséges).

A virtualizáció hulláma most éri el a számítógéphálózatok világát. Első hal-lásra talán meredeknek hangzik, hogy hálózatokat virtualizáljunk. A hálózatokvilágában megőszült mérnökök közül sokan csak legyintenek amikor ezt meg-hallják. Pedig a hálózatvirtualizációnak, amennyiben a hálózatot erőforrásnak(és miért ne tekintenénk annak) tekintjük teljesen ugyanaz a logikája és leg-alább olyan erős a létjogosultsága mint a számítógépek virtualizációjának. Egyhálózat üzemeltetőjének elemi érdeke, hogy a hálózat kihasználtsága minél job-ban közelítse a száz százalékot. Amennyiben ezt nem tudja saját felhasználóivalbiztosítani, úgy a hálózat kihasználatlansága gyakorlatilag veszteség. Ilyenkorérdemes a hálózatot más (virtuális) szolgáltatók felé megnyitni és ugyanazon afizikai hálózati infrastruktúrán több virtuális hálózatot párhuzamosan üzemel-tetni. A hálózatvirtualizáció még fontosabb adatközpontokban, ahol az üzletipartnerek nemcsak a szervereket, de az őket összekötő hálózati megoldásaikat isszeretnék egyre inkább a felhőbe tolni. Márpedig ez a hagyományos technológi-ával vagy egyáltalán nem, vagy csak hosszú idő alatt megoldható feladat.

Az SDN kulcsfontosságú vívmánya, hogy a hálózatvirtualizáció elképesztő-en egyszerűen megoldható. A legegyszerűbb megoldás, ha a kapcsolóelemek ésa kontroller(ek) közé egy proxy-t iktatunk be, ami pl. bizonyos kapcsolóktólvaló üzeneteket csak a megadott kontrollereknek továbbít. Vagy pl. külön-böző folyamtereket különböző kontrollerekhez lehet irányítani (így pl. IP címtartományokkal különíthetünk el virtuális hálózatokat). Ezt az elvet használjapl. a FlowVisor nevű alap SDN virtualizációs technika. Ma már ennél sokkalfejlettebb hálózatvirtualizációs megoldások is vannak.

1.3.4. 4. Réteg: Hálózati operációs rendszerek / kontrolle-rek

A operációs rendszerekkel analóg módon a hálózati operációs rendszer (NetworkOperating System NOS) egy logikailag központosított nézetbe transzformálja ahálózat erőforrásait és magas szintű API-t valamint alapvető szolgáltatásokatad a fejlesztők kezébe, hogy a hálózat erőforrásait alkalmazásokon keresztülvezéreljék. Alap szolgáltatások pl. az eszközök és a topológia felderítése, esz-közök konfigurációja és monitorozása. A NOS segítségével a fejlesztőknek márnem kell elosztott protokollokban gondolkodniuk, egyszerűen megírhatják az al-kalmazást, a NOS pedig gondoskodik az eszközök megfelelő beállításáról. Ez

12 1. FEJEZET. A HÁLÓZAT MINT PLATFORM

természetesen csökkenti a hibalehetőségeket és nagy mértékben elősegíti az in-novációt. Ne feledkezzünk meg azért arról, hogy ez alapvetően a NOS és azeszközök közötti dedikált kontrollhálózat miatt tehető meg.

Az utóbbi években szinte minden fontosabb programnyelven (c/c++, py-thon, java, ruby) írtak NOS-t az OpenFlow architektúrához. Ezek általában jólstrukturált API-t adnak a fejlesztők kezébe a megfelelő programnyelven. Ígyviszont némi bábeli zűrzavar alakult ki a NOS és az alkalmazások kommuniká-ciójában. Például egy pythonban írt hálózati alkalmazás nem képes akármelyikNOS felett futni. Erre a problémára jelenthet majd megoldást a NOS és azalkalmazások közötti ú.n. északi interfész szabványosítása. Jöjjön tehát mostez.

1.3.5. 5. Réteg: Északi interfész

A déli és az északi interfész az SDN két kulcsfontosságú absztrakcióját valósítjameg. Mint már említettük, a déli interfész egy kapcsolóelemet absztrakciójátvalósítja meg (aki még mindig nem érti mi az az absztrakció előadás alatt, vagyután feltétlen kérdezzen), vagyis lehetővé teszi, hogy egységes módon megadjuka kapcsolóeszköz logikáját a fizikai felépítéstől teljesen függetlenül. Az északiinterfész a teljes hálózat absztrakcióját valósítja meg, így az északi interfészthasználó elemek nem egy való hálózatot látnak, hanem pl. egy gráfot. A déliinterfészre már van széles körben elfogadott javaslat (az OpenFlow protokoll),az északi interfészre jelen pillanatban nincs elfogadott protokoll de a fejlesztéskutatás nagyban folyik. Az északi interfész egy teljesen szoftveres interfész, míga déli inkább hardver közeli. A szoftveres interfészek kialakulásában, elfogadá-sában a tapasztalat szerint inkább az implementáció szokott döntő lenni. Ezérta közeljövőben várható számos javaslat és elérhető megvalósítás, amelyek közülvalamelyik minden bizonnyal de facto szabvánnyá fog válni.

A standard északi interfész kialakulása elengedhetetlen ahhoz, hogy a külön-féle platformon fejlesztett NOS-os és alkalmazások együtt tudjanak működni.Az északi interfész számos analógiát mutat a POSIX szabvánnyal, amely gya-korlatilag megszabja azt, hogy hogyan kell olyan szoftvert írni, amely bármilyenUnix-szerű operációs rendszeren képes futni. Az hordozhatóság tehát biztosí-tott a POSIX-ot implementáló operációs rendszerek között. (Érdekes dolog,hogy egy időben még a Microsoft is implementálta a POSIX szabvány bizonyosrészeit, de mára teljesen felhagyott vele.)

1.3.6. 6-7. Réteg: Programozási nyelvek

A programozási nyelvek evolúciója talán mindenki számára ismert. A hardverjelentette platformra először a hardver közeli nyelvek (pl. assembly) fejlődtekki. As assembly már absztrakt formában kezeli a gép bizonyos részeit, így egy újplatformot hoz létre, melyen új nyelvek evolúciója kezdődhet meg. Így jutunk elszépen egyre feljebb és feljebb a C/C++-on keresztül a magas szintű nyelvekig(pl. Python és Java).

1.3. KICSIT MÉLYEBBEN: AZ SDN RÉTEGEI 13

Ehhez nagyon hasonló amit az SDN programozásánál látunk. Az SDN leg-elterjedtebb alacsony szintű nyelve maga az OpenFlow protokoll. Ha tisztánaz OpenFlow üzeneteivel akarnánk egy hálózatot vezérelni, az nagyon bonyo-lult lenne, hiszen csomó hardver közeli apróságra kellene figyelni (hasonlóan azassembly-hez), mint pl. konkurens folyamtábla-szerkesztés, átfedő folyamtáblabejegyzések, dinamikus működésből adódó inkonzisztens állapotok stb. Ráadá-sul ilyen alacsony szintű nyelven nehéz jól strukturált újrafelhasználható kódotírni.

Ezen hivatottak segíteni a magasabb szintű nyelvek. A fő céljuk ezekneka nyelveknek az, hogy a fejlesztőknek ne kelljen annyit a hálózat megvalósítá-sával foglalkozniuk, ehelyett a konkrét megoldandó feladatra (logikai működés)tudjanak fókuszálni. A magasabb szintű nyelvek használatának legfontosabbelőnyei:

• A hálózat magas szintű absztrakciója, melyen keresztül a hálózat funk-cionalitása (pl. legrövidebb útválasztás) könnyen megadható. A fordítómechanizmusok feladata ezután, hogy a magas szinten megadott leírástvégül konkrét OpenFlow üzenetekké transzformálják.

• Produktív, problémaközpontú környezet kialakítása, a fejlesztés és inno-váció gyorsítása, hibalehetőségek minimalizálása.

• Moduláris, újrahasznosítható kód létrehozása.

• Nyelv alapú hálózati virtualizáció. Ez kb. azt jelenti, hogy a hálózat ele-meihez virtuális objektumokat rendelhetünk (egy kapcsolóhoz akár többetis), így magán a hálózati alkalmazáson belül hálózatvirtualizációt valósít-hatunk meg.

1.3.7. 8. Réteg: Alkalmazások

Az SDN architektúra (SDN stack) tetején ülnek az alkalmazások. Ezek ad-ják meg a hálózat funkcióját, működési logikáját. A legegyszerűbb funkció pl.a routing. Egy végletekig leegyszerűsített routing alkalmazás pl. hogy A ésB hosztok tudjanak egymással kommunikálni. Ehhez tulajdonképpen azt kellmegvalósítani, hogy a NOS-tól lekérjük a hálózat topológiáját, útvonalat szá-mítunk rajta a hosztok között és utasítjuk a NOS-t, hogy állítsa be a megfelelőkapcsolókat az útvonalon.

Az alap útválasztáson kívül, nagyon sokféle SDN alkalmazást fejlesztettekaz elmúlt években. A hagyományos alkalmazások közé tartozik, a routing-on kí-vül a terheléselosztás és biztonság. Ezeken felül van alkalmazás, mely a hálózathibatűrését növel, energiafogyasztását minimalizálja, virtualizációt valósít meg,szolgáltatásminőséget biztosít (QoS), mobil eszközöket kezel, adatközpont há-lózatot optimalizál vagy éppen hálózati kódolást valósít meg. Ráadásul ezeketaz alkalmazásokat egymással kombinálni is lehet, ami elképesztő testre szabha-tóságot nyújt a hálózatok világában.

14 1. FEJEZET. A HÁLÓZAT MINT PLATFORM

1.4. NFVAz NFV nem más, mint a hardveres middlebox-ok virtualizált verziója. Ilye-nekbe általában olyan funkcionalitást szoktak tenni, ami a kapcsolókban nemvalósítható meg (pl. részletes csomagvizsgálat, forgalomanalízis, hálózati kódo-lás, behatolás detektálás stb.). A middlebox-ok virtualizációja kényelmessé teszihasználatukat, könnyen menedzselhetővé varázsolja őket, a virtualizált verziókatkönnyű áthelyezni, frissíteni vagy éppen kivonni a forgalomból.

1.5. Ellenőrző kérdések• Melyek a hagyományos hálózatok legfontosabb jellemzői, előnyei és hátrá-

nyai!

• Ismertesse a hagyományos hálózatok és az SDN hálózatok közötti legfon-tosabb architekturális különbségeket!

• Ismertesse a NOS szerepét és funkcióit az SDN architektúrában!

• Soroljon fel néhány SDN alkalmazást!

• Érveljen a hálózatvirtualizáció mellett!

• Miben hatékonyak a magas szintű programozási nyelvek az SDN architek-túrában?

• Mit jelent az absztrakció és mi a jelentősége?

1.6. Ajánlott irodalom