South-bound APIs 2   YANG alapú leírónyelvek és API-k YANG adatstruktúra egy leíró modell arra, hogy milyen követelményeket támasztunk a API lekérdezés vagy operáció formáját tekintve, továbbá definiáljuk a konfigurációs paraméterek struktúráját. Bizonyos szempontból nézve az SNMP OID-ok is megfelelnek ennek az adatstruktúrának, így joggal merül fel a kérdés, hogy minek vesződünk mással? A koncepció egy NET/RESTCONF kapcsán az, hogy az egyszeri - speciális hálózati szaktudással nem rendelkező - programozó is tudjon kódot írni, ugyanis a programozók otthonosabban mozognak a XML, JSON vagy YALM formátumú konfigurációkban mint az SNMP OID-ban, vagy CLI-ban. JSON formátumú konfiguráció leírást már előző postomban mutattam. Így most nem térnék ki külön a formátumra. A JSON formátumon kívül, amik még különböző automatizációs és SDN rendszerek esetén népszerűek, az XML és YALM formátum. Akit érdekelnek a különböző formátumok részletes leírása annak az alábbi forrásokat javas

South-bound APIs Déli-irányú API-k esetén nem olyan "egyszerű" a helyzet mint északi-irányban. Ugyanis még nincs - és talán sosem lesz - olyan egységes, kvázi sztenderdizált protokoll mint a REST API. Hogy miért? Hát kérdezzük meg a gyártókat! Miért nem a NETCONF, vagy a SNMPv3, vagy az OpenFlow mellett tették le a voksukat egységesen. Mint a korábbi bejegyzésemben írtam már, a gyártók az SDN megoldásaikat sokkal inkább csomagolt termékként kínálják, mint egymással együtt működő standardoknak megfelelő részegységeket. Ezért van az, hogy a déli-irányú SDN integrációt nem lehet, egy protokollal megvalósítani egy heterogén rendszerben. Déli-irányban, így gyakorlatilag bármi lehet API, amit az SDN kontroller és a hálózati eszköz is támogat... Azért próbáljunk meg néhány protokollt kiemelni, mert azokban megvan minden olyan funkcionalitás, ami alkalmassá teszi az orkesztráció megvalósítására.   YANG adatmodell RFC6020 - Yet Another Next Generation... A fenti k

Application Programming Interfaces - APIs API-król az SDx bejegyzések során már röviden beszéltem, de most tegyük nagyító alá a témát, és nézzük meg az egyes API-k működését, hogyan kapcsolódnak az egyes orkesztrációs szintekhez (kontrollerekhez). Tehát mindenkinek megvan, hogy az SDN architektúra referencia középpontja maga az SDN kontroller. Ez alapján azok az API-k amik a kontrollert alkalmazás oldalról érik el (tipikusan REST-API), észak-irányú API-nak - North-bound - amikkel pedig a kontrollerrel érjük el az infrastruktúrát azokat pedig déli-irányú API-nak - South-bound - szoktuk nevezni. A fentiek alapján, és felhasználásuk szempontjából megpróbálom leírni ezeket a protokollokat, annyi extra csavarral, hogy bevezetem az integration-API fogalmát, ami bizonyos szempontból észak-irányú API-nak is tekinthető, de szerintem ez inkább külön kategória, mert ez kontroller, vagy kontroller jellegű alkalmazások összekötését teszi lehetővé. North-bound API REST

Network Function Virtualization  Ezt a bejegyzést rövidítésjegyzékkel kezdem, hogy bátran spórolhassak a karakterekkel, ugyanis nem másra kell felkészülnünk mint, hogy az ETSI által szabványosított NFV architektúrát körvonalazzuk az alábbi sorokat követően. Joggal merül fel a kérdés, mi különbség hálózat-virtualizáció és a hálózati funkciók virtualizálása között… A másik kérdés az, hogy milyen igények mentén jutottunk oda, hogy kidobjuk a vasat, és szoftverből valósítsunk meg hálózati eszközökhöz szorosan kapcsolódó feladatokat? Hogy fenti kérdéseket megválaszoljuk, és a még több kérdés tudjunk feltenni ebben a témában, ezért tekintsünk át alapoktól az NFV architektúrát. Rövidítésjegyzék NFV – Network Function virtualization ETSI – Europian Telecomunication Standard Institute VM – virtual machine VNF – Virtual Network Function PoP – Point of Presence Virtualizáció  A virtualizációt mint fogalom már bevezettük (!!!absztrakció!!!), így most mint technológ

SDx architektúrák Tudásunk naprakészen tartása során vagy egy gyártói bemutatón és/vagy partneri rendezvényen biztosan belefutottunk valamilyen Softver Defined technológiába, ahol lelkesen magyarázták, hogy OPEX/ CAPEX csökkentés, meg hogy single pane of glass és hasonló marketing BULL…..etpointokat. A címválasztás nem véletlen, ugyanis szerintem helyre kell tenni az SDN alapú technológiák körüli túlmisztifikált marketing pontokat és nem csak egy aspektusból vizsgálni ezt a kérdéskört. Így hát nézzük meg milyen lehetőségek, adottak a sötét oldalon. Definícióm szerint az SDx esetében az x gyakorlatilag bármilyen ASCII karaktert felvehet, attól függően, hogy egy-két gyártó Marketing osztálya mit talált ki. Tehát mára a SDN egy lassan kiüresedő marketing eszközzé, brand-é vált? Az attól függ, mennyire mélyen ismerjük az eredeti SDN koncepciókat, és egyes SD-Brand-ek közül mik azok, amik az eredeti architektúrára leginkább hasonlítanak és melyek azok amik csak megk

 2019 BUÉK..., eltelt egy újabb év, és én már féléve nem jelentkeztem, ezért elnézést kérek minden kedves olvasótól, aki várta ezt a bejegyzést, de a hobbi, munka, család háromszögben nagyon nehéz, optimumot találni, úgy, hogy mind a háromra elegendő idő jusson. Ígérem a pozitív visszacsatolások, amit néhány olvasó adott a blogról, újabb lendületet adnak, és kicsit rendszeresebben fogok jelentkezni valamilyen írással. Előző bejegyzésemet úgy fejeztem be, hogy „Maradjatok velem és megmutatom milyen mély a nyúl ürege” nos, ez nem csak filmes utalás, ugyanis mind a tradicionális és virtuális hálózatok felépítése – hasonlóan a nyúl üregéhez a földben – különböző rétegeken megy keresztül. „Kicsit gondban vagyok, nem tudom, milyen messziről indítsam a téma kifejtését, ezért” vázlatosan összefoglalom a legalapvetőbb elveket és aztán meglátjuk. OSI modell OSI (Open System Interconnection) modellt ISO standardként született meg, hogy a különböző kommunikációs inte

Szakterületemből kifolyólag – ahol folyamatosan fejlődő és változó technológiákkal találkozom nap mint nap – sok technológiával ismerkedtem meg viszonylag fiatalon, ami az iskolai oktatásnak, és a munkámhoz kapcsolódó ismeretek megszerzésének is köszönhető. Eddig tapasztalataimat összegezve úgy gondolom, bizonyos technológiák halálra vannak ítélve, bizonyosak tovább fejlődnek, és vannak olyanok, amik meghatározzák a következő 10-20 év Enterprise, DataCenter, és Service Provider hálózatait. A célom ezzel a bejegyzéssel, hogy bemutassam azokat a technológiákat és megoldásokat, amik hosszútávon meg fogják határozni a telekommunikációs és informatikai hálózatokat. Az egyik ilyen fogalom a hálózat-virtualizáció. Remélem az olvasónak nem vettem el a kedvét, és témát illetően és nem sírnak fel fájdalmukban a hálózati rendszermérnökök, szakértők és architektek. Főként azért, mert a hálózat-virtualizáció egy olyan fogalom, amely nagyjából 30 éve ismert a szakmában, és ilye