A MAGYAR HONVÉDSÉG STACIONER HÁLÓZATI FORGALMI VISZONYAINAK VIZSGÁLATA TRAFFIC ANALYSIS OF THE FIXED NETWORK OF THE HUNGARIAN ARMY

Átírás

1 VÉDELMI INFOKOMMUNIKÁCIÓ BLEIER ATTILA DR. RAJNAI ZOLTÁN A MAGYAR HONVÉDSÉG STACIONER HÁLÓZATI FORGALMI VISZONYAINAK VIZSGÁLATA TRAFFIC ANALYSIS OF THE FIXED NETWORK OF THE HUNGARIAN ARMY In this paper the authors provide a new method for traffic engineering, using software based modelling for the traffic patterns that might occur in the fixed network of the Hungarian Army. The authors are modelling the traffic patterns for 3 different scenarios, in order to point out the potential capacity problems in the fixed network. Ebben a cikkben a szerzők azt vizsgálták meg, hogy a Magyar Honvédség stacioner hálózata mennyire felel meg azoknak a sávszélesség követelményeknek, amiket a modern katonai informatikai alkalmazások támasztanak. A cikkben azt vizsgálom, hogy három forgalmi esetben a Magyar Honvédség stacioner hálózatán miként alakulnak a forgalmi viszonyok. Forgalmi esetek szimulációja A Magyar Honvédség stacioner hálózatának forgalmi viszonyait 3 forgalmi esetet figyelembe véve tanulmányoztam, a projekt kapcsán felhasználtam tapasztalatokat a korábbi forgalomelméleti projektekből (1). Az egyes forgalmi esetek megfelelnek a 90-es, a 2000-es és 2010-es évek várható forgalmának. A forgalmi viszonyok vizsgálatához a TOTEM Forgalmi szimulátort használtam (2). A forgalmi szimulátor egy HP Proliant ML 150G2-s szerveren futott, 80GB-os mirroring RAID-be szervezett merevlemezekkel, 1 GB-nyi memóriával, generic SMP kernellel Ubuntu linux es operációs rendszer alatt. A telepítési környezet megkívánta az ANT alkalmazásszerver bizonyos komponenseinek a telepítését, ill. TOTEM alkalmazást. Ezt a környezetet gyakorlatilag bármilyen forgalomban kapható számítógépen előállíthatjuk. A használt szoftverek licensz GPL tehát 185

2 szabadon felhasználható kutatási, bizonyos feltételek teljesítése mellett pedig kereskedelmi célokra is. A szoftveren konfigurációs módosításokat végeztem, magyarítottam, ill. speciális konfigurációs szoftvereket fejlesztettem hozzá azért, hogy a hálózatelemek felé történő automatizálást megkönnyítsem. A szoftver részletesebb dokumentációja megtalálható a [(3)]-ben szereplő oldalon. A szoftver alkalmas arra, hogy a hálózaton a topológia megváltozásakor bekövetkező eseményeket szimuláljuk, akár él, akár csomópontkiesés esetén. A szoftver képes forgalmi eseteket szimulálni, számtalan útválasztó algoritmust ismer, a leggyakrabban használt Dijkstra (SPF) algoritmustól kezdve, a CSPF algoritmuson át számtalan egyéb, jelenleg kutatási célokra használt algoritmuson át ilyen pl. DAMOTE. Képes előre lefoglalt utak kezelésére, és a különböző tartalékolási technikák szimulálására. A forgalmi szimulációs szoftverbe a forgalmi viszonyokat, valamint a hálózati topológiát a szoftver topológia szerkesztőjével vittem be. Bizonyos típusú hálózatelemekre, a topológia automatizált beolvasására egy automatizált megoldást dolgoztam ki, ezt azonban ebben az esetben nem használtam. A használt metodika nagyon hasonló a (4)-ben publikáltakhoz, azonban a hálózat átviteltechnikai jellege miatt bizonyos korlátokat kellett figyelembe vennünk az IP/MPLS forgalmi modellezéssel szemben. A topológia bevitelekor a végponti telephelyek kivételével az összes stacioner telephely elnevezését megváltoztattam. Az egyes végponti helyszínek mindegyik példában megfelelnek a Magyar Honvédség digitális távbeszélő központokkal rendelkező állomásainak. Az ábrákon, színkódokkal jelöltem, a hálózat éleinek a leterheltségét, a leterheltségeknek megfelelő színkódok a következőek: 0-30 % telítettségig zöld; a 30-60%-os telítettségig sárga; a %-os telítettségig piros. 186 Forgalmi esetek, forgalmi minták Három hálózatszintű forgalmi esetet vettem figyelembe, 100 Kbps, 1 Mbps és 10 Mbps értékekkel. A sávszélesség igények eloszlása az egyes végpontokon nem egyenletes, hanem normál, vagy Poisson eloszlású. Ennek

3 VÉDELMI INFOKOMMUNIKÁCIÓ az az oka, hogy így a forgalmi viszonyok jobban fedik a valós, nem egyenletes forgalmi viszonyokat. Ezzel párhuzamosan teljesen szövevényes csomóponti kapcsolatokat alakítottam ki az EDGE-el jelölt csomópontok között (tehát a digitális távbeszélő-állomásokkal rendelkező telephelyek között. A valós forgalmi minták természetesen nem pontosan ilyenek, a forgalom eloszlása, alkalmazás és helyszínfüggő, ezért az egyes forgalmi minták, az egyes alkalmazások igényeire jobban alakíthatóak. Az egyes helyszínek forgalma is jelentősen különbözik, azonban egy forgalom jellegének meghatározásához a cikkben taglaltak megfelelő modellt jelentenek. Kis sávszélességű adat, és hangforgalom szimulációja Az első esetben példaforgalomként 1 Mbit/s körüli forgalmakat szimuláltam, az egyes végponti helyszínek forgalmát véletlen számgenerátorral generáltam. A véletlen szám generátor normál eloszlású véletlen számokat generált a végpontokra, 1 Mbit/s-os középértékkel és 0,5 Mbit/s-os szórással. Ezek a forgalmak minden végponti telephelyről, minden végponti telephelyre mennek. Ez a forgalommennyiség, és eloszlás egy első generációs IP alapú hálózatra jellemző, a környéki állapotot jellemzi, azonban a mai igényeket már nem fedi le. Ez a forgalmi minta megfelel egy vegyes közepes méretű laktanya forgalmának, megfelel 16 db PCM kódolású hangcsatornának, ill. vegyes adat és hangforgalomnak, amely nem tartalmaz valós idejű képátvitelt. A szoftver által mutatott forgalmi viszonyokat az 1. ábra mutatja. Az ábrán jól követhető, hogy ilyen forgalmi helyzet esetén a Debrecen- Hajdúhadház-Bánkút viszonylat, ill. a Budapest-Szentendre-Nagytarcsa- Székesfehérvár viszonylatokon az élek terheltsége meghaladja a 90%-ot, tehát az élek közel teljesen telítettek. A fenti esetet vizsgálva az állapítható meg, hogy a Bánkút, Hajdúhadház, Debrecen, ill. Bp. és Bp. környéki csomópontok körüli élek leterheltsége közelíti a 100%-ot. Ez ilyen forgalmi viszonyok esetén azt jelentené, hogy gyakorlatilag bizonyos viszonylatokban lehetetlenné vált a kommunikáció a végpontok között. 187

4 1. ábra Az élek telítettségét a mellékletben szereplő táblázat tartalmazza részletesebben. Az alábbi táblázatban összegyűjtöttem a legtelítettebb 10 élt ebben az esetben: Élazonosító Indulócsomópont Végcsomópont Sávszélesség Fenntartott sávszélesség Fenntartható sávszélesség Telítettség (%) GYOR-V1 GYOR V V1-V5 V1 V V2-V3 V2 V V3-V4 V3 V V4-V3 V4 V TARCSA-P3 TARCSA P

5 VÉDELMI INFOKOMMUNIKÁCIÓ Élazonosító Indulócsomópont Végcsomópont Sávszélesség Fenntartott sávszélesség Fenntartható sávszélesség Telítettség (%) P3-P2 P3 P NAGYHARS-N2 KAL N N2-EGER N2 EGER N3-N2 BANKUT N BANKUT-BAZ2 BANKUT BAZ BAZ2-BAZ1 BAZ2 BAZ BAZ1- HAJDUHADHAZ BAZ1 HAJDU- HADHAZ BK2- KISKUNHALAS BK2 KISKUN- HALAS FURJE-BE2 FURJE BE táblázat Mint a táblázatból látható, az élek jelentős része telítetté vált, pedig pusztán 1 Mbit/s-os végpont-végpont közti forgalmat szimuláltam (igaz, valószínűleg a végpontok közti forgalom nem egyenletes, de ezt a forgalmi mátrix normál eloszlása szimulálja). Összegyűjtöttem a 10 legtöbb sávszélességet foglaló út listáját is. Az alábbi táblázatban tűntettem fel őket (a melléklet tartalmazza az útvonalak részletes leírását is, amelyben végigkövethető, hogy a szimulált algoritmus, hogyan választotta ki a legrövidebb utat). 189

6 SÁV- ÚTVONAL INDULÓ VÉGZŐDŐ SZÉLESSÉG AZONOSÍTÓ CSOMÓPONT CSOMÓPONT [MBIT/S] LSP Bánkút Szolnok 4.12 LSP Szentes Varpalota 3.91 LSP Papa Fürje 3.77 LSP Városföld Székes-fehérvár 3.75 LSP Szentes Zengővár 3.73 LSP Nagytarcsa Budapest 3.73 LSP Szentes Veszprém 3.72 LSP Budapest Bánkút 3.49 LSP Hódmező-vásárhely Pécskórház 3.41 LSP Székesfehérvár Hévíz táblázat A táblázatból jól látható, hogy sok esetben néhány nagyobb, az országot átszelő forgalmú útvonal lefoglalja a hálózati erőforrásokat (a példában az LSP , ill. LSP azonosítójú viszonylatok). A technológia helyes megválasztásával, a hálózati eszközök pontos konfigurációjával elérhető, hogy az ilyen jellegű forgalmak a lehető legkevésbé terheljék a gyakrabban használt éleket. Ezt a jelenlegi statikus ill. pusztán a legrövidebb út algoritmusokon alapuló tervezés nem teszi lehetővé. 190 Alacsony sávszélességű hangforgalom szimulációja A második esetben, tisztán hangalapú forgalommennyiséget szimuláltam. Példaforgalomként 128 Kbit/s körüli forgalmakat szimuláltam, ahol az egyes végponti helyszínek forgalmát véletlen szám generátorral generáltam. (A forgalmi mátrix megtalálható a mellékletben). A véletlen szám generátor normál eloszlású véletlen számokat generált a végpontokra, 128 Kbit/s-os középértékkel és 20 kbit/s-os szórással. Ezek a forgalmak minden végponti telephelyről, minden végponti telephelyre mennek. Ez a forgalmi minta megfelel a múlt század 90-enes éveinek megfelelő for-

7 VÉDELMI INFOKOMMUNIKÁCIÓ galmaknak. Átlagosan két darab PCM kódolású hangcsatornának, vagy 4 db ADPCM kódolású hangcsatornának. A második ábra ezt az esetet mutatja, a korábban már ismertetett színkódokkal. 2. ábra Élazonosító Indulócsomópont Végcsomópont Sávszélesség Fenntartott sávszélesség Fenntartható sávszélesség T2-JUTA T2 JUTA % Jól látható, hogy ebben az esetben a hálózat telítettsége jelentősen csökkent, a hálózatban, ebben az esetben gyakorlatilag nincsenek 90% feletti telítettségű élek. A 80%-os terheltség feletti éleket az alábbi táblázat mutatja: B1- PECSKO RHAZ B1 PECS- KORHAZ Telítettség % BK2-F9 BK2 F % 191

8 Élazonosító Indulócsomópont Végcsomópont Sávszélesség Fenntartott sávszélesség Fenntartható sávszélesség Telítettség BK2-BK1 BK2 BK % BK1-BK2 BK1 BK % BK1- MEDINA BK1 MEDINA % BUDA- PEST-P2 BUDA- PEST P % TARCSA- PUSZTA VACS TARCSA PUSZTA- VACS % N2- HARS N2 KAL % BK2- KISKUN- HALAS BK2 KIS- KUNHA- LAS % BK2-BK4 BK2 BK % BTKK- SZOL- NOK BTKK SZOL- NOK % 3. táblázat Jól látható, hogy ebben az esetben a BK1-BK2, Bács-Kiskun megyei csomópontok között alakulhat ki ebben az esetben 90% feletti leterheltség. Megállapítható, hogy a hálózat az ilyen jellegű forgalmakat megfelelő mértékben képes kielégíteni. A 10 legnagyobb forgalmú útvonal listája ebben a mintaesetben a következő: 192

9 VÉDELMI INFOKOMMUNIKÁCIÓ Útvonal azonosító Induló csomópont Végződő csomópont Sávszélesség LSP Táborfalva Kiskunhalas 0.19 LSP Szolnok Varpalota 0.19 LSP Eger Hajdúhadház 0.18 LSP Hódmezővásárhely Városföld 0.18 LSP Táborfalva Nagytarcsa 0.18 LSP Varpalota Táborfalva 0.18 LSP Papa Budapest 0.18 LSP Veszprém Debrecen reptér 0.17 LSP Budapest Táborfalva 0.17 LSP Szekesfehervar Kiskunhalas táblázat Itt is megállapítható, hogy sok esetben egy hosszabb út, mint például az LSP es lefoglalja a hálózati erőforrások egy jelentős részét. Ezen megfelelő útvonal irányítással (ún. Traffic Engineering útvonalak bevezetésével) megfelelően szabályozható. Katonai informatikai alkalmazás szimulációja A harmadik esetben, nagyobb adatforgalom mennyiséget szimuláltam. Példaforgalomként 10 Mbit/s körüli forgalmakat szimuláltam, ahol az egyes végponti helyszínek forgalmát véletlen szám generátorral generáltam. A véletlen szám generátor Poisson eloszlású véletlen számokat generált a végpontokra, 10 Mbit/s-os középértékkel. Ezek a forgalmak minden végponti telephelyről, minden végponti telephelyre mennek. Ez a forgalmi jelleg megfelel a mai katonai informatikai alkalmazások követelményeinek, lehetővé teszi a valós idejű, nagy sávszélességű adatforgalmat, a valósidejű képátvitelt és az elosztottan működő hálózati architektúrát, amely a nagy rendelkezésre állással rendelkező hálózati alkalmazásokhoz szükséges. A harmadik ábra a forgalmi viszonyokat mutatja ebben az esetben: 193

10 3. ábra Az előző két forgalmi esethez hasonlóan összegyűjtöttem a 90% feletti telítettségű éleket a hálózatban. Megállapítható, hogy a forgalmi viszonyok nagyon hasonlóan alakulnak az 1 Mbit-s esethez, tehát ugyanazokban a hálózati viszonylatokban (Kelet-Magyarország, ill. Budapest környéke) alakul ki torlódás. Ez a modell pusztán elméleti jelentőséggel bír, mert részletesebben elemezve a forgalmi viszonyokat, az útvonallistából látható, hogy a hálózatot néhány viszonylat kielégítése közel 100 %-ra terheli le. Élazonosító Indulócsomópont Végcsomópont Sávszélesség Fenntartott sávszélesség Fenntartható sávszélesség Telítettség (%) Papa-V5 PAPA V VARPA- VARPA- LOTA-V6 LOTA V SZEKES- SZFVAR-F5 FEHER- VAR F

11 VÉDELMI INFOKOMMUNIKÁCIÓ Élazonosító Indulócsomópont Végcsomópont Sávszélesség Fenntartott sávszélesség Fenntartható sávszélesség Telítettség (%) F2- BUDA- F2 BUDAPEST PEST BUDAPEST- BUDA- F2 PEST F BUDAPEST- BUDA- SZENT- SZENT- PEST ENDRE ENDRE BUDAPEST- BUDA- PEST TARCSA TARCSA BUDA- TARCSA- TARCSA PEST BUDAPEST TARCSA- PUSZTA- TARCSA PUSZTA- VACS VACS BUDAPEST- BUDA- P3 PEST P HAJDU- HADHAZ- HAJDU- HAD- BAZ BAZ1 HAZ KECSKE- KECS- MET-BK4 KEMET BK DEBRECEN- DEBRE- JNSZ2 CEN HB SZOLNOK- SZOL- BTKK NOK BTKK BE2-BE1 BE2 BE BE1- SZOLNOK BE1 SZOLNOK SZENTES- HODME- HODMEZO SZEN- ZOVASAR VASAR- TES HELY HELY táblázat 195

12 A 3. ábrát, valamint a 3. táblázatot megvizsgálva, jól látható, hogy gyakorlatilag az 1. és a 3. ábra, valamint az 1. és 3. táblázat megfelel egymásnak. Ez azt mutatja, hogy a hálózatban nem vezethető el átlagosan az összes végpont felé már 1 Mbit/s-nek megfelelő forgalom, a mai katonai alkalmazások 10 Mbit/s-es igényeit pedig a stacioner hálózat nem képes kielégíteni. Az alábbi útvonallista tartalmazza ebben a mintaesetben a hálózati viszonyokon fellépő 10 legnagyobb forgalmat: ÚTVONAL AZONOSÍTÓ INDULÓ CSOMÓPONT VÉGZŐDŐ CSOMÓPONT SÁVSZÉLESSÉG [MBIT/S] LSP Bankút Debrecen LSP Szekesfehervar Budapest LSP Budapest Veszprém LSP Városföld Bankút LSP Táborfalva Pusztavacs LSP Veszprém Zengővár LSP Tata Veszprém LSP Papa Szentendre LSP Varpalota Veszprém LSP Szolnok Debrecen táblázat Hasonlóan a korábbi két forgalmi esetben megállapítotthoz, látható, hogy néhány nagyobb forgalmú, országot átszelő út leterhelheti a teljes hálózatot (a fenti példában az LSP , ill. LSP útvonal azonosítójú viszonylatok). Az útvonallista részletesebb elemzéséből kiderül, hogy a hálózati útvonalak jelentős része nem volt kialakítható a hálózaton, tehát ilyen forgalmi mennyiség átvitelére a Magyar Honvédség stacioner hálózata nem alkalmas. A technológia helyes megválasztásával, a hálózati eszközök pontos konfigurációjával elérhető, hogy az ilyen jellegű forgalmak a lehető legkevésbé terheljék a gyakrabban használt éleket. Ezt a jelenlegi statikus ill. pusztán a legrövidebb út algoritmusokon alapuló tervezés nem teszi lehetővé.

13 VÉDELMI INFOKOMMUNIKÁCIÓ Összegzés A fenti három forgalmi eset szimulálja a infokommunikációs, ill. katonai informatikai rendszerek három fejlődési szakaszát. Az első szakasz megfelel a második forgalmi esetben leírtaknak, gyakorlatilag a 90-es évek első felének infokommunikációs technológiai színvonalát képviseli a civil szférában, a hangforgalmak átvitelére alkalmas a csomópontok között. Megállapítható, hogy a stacioner hálózat az ilyen jellegű forgalom kielégítésére teljes mértékben alkalmas. A második fejlődési szakasz, az adathálózatok kialakulásának a szakasza, ez a civil szférában a es időszak, amikor az első adathálózatok megjelentek, és az IP szélesebb teret nyert. Ezt az időszakot vegyes hang és adatforgalmú alkalmazások jelzik, és központosított jelleg. A fejezetben megállapítom, hogy a hálózat az ilyen jellegű forgalmak kielégítésére korlátozásokkal alkalmas, ezt Fekete Károly is vizsgálta korábban a cikkében (5). A harmadik fejlődési szakasz, a nagy sávszélességű adathálózatok kialakulásának szakasza. Ez a szakasz az erősen elosztott, és hálózati alkalmazások széleskörű elterjedése jellemzi, a civil szférában ez kb től folyamatosan történik meg. Megjelennek a valósidejű képátviteli forgalmak, az üzenetküldő rendszerek, a forgalom pedig ma már kizárólag adat, amelynek a jellege lehet valósidejű hang vagy egyéb adat. A fenti fejezetben megállapítom, hogy a stacioner hálózat az ilyen jellegű forgalmak kielégítésére alkalmatlan, nem rendelkezik a megfelelő technológiai és kapacitási viszonyokkal. Az is egyértelműen megállapítható, hogy miután a katonai informatikai alkalmazások használata a Magyar Honvédség alapvető érdeke, ezért a stacioner hálózat fejlesztése szükséges. 197

14 Rövidítésjegyzék 198 RÖVIDÍTÉS / ACRONYM IP ATM QoS SLA BER RTT MPLS ZMNE IETF IEEE ITU ETSI STANAG NATO AARMS SDH PDH TDM EU O&M IT IPv6 SPF C4ISR PCM ADPCM SPF CSPF DAMOTE MAGYAR MEGFELELŐ / MAGYARÁZAT Internet Protokoll (általában 4-es verzió) Aszinkron átviteli mód Szolgáltatásminőség szolgáltatási szint szerződés Bithibaarány Round trip time Többprotokollos címkekapcsolás Zrínyi Miklós Nemzetvédelmi Egyetem Internet szabványügyi szervezete nemzetközi villamosmérnöki szabványügyi szervezet nemzetközi távközlési szabványügyi szervezet szabványügyi szervezet NATO szabványok Nemzetközi politikai-katonai szövetség Academic and Applied Research in Military Science Szinkron digitális hierarchia Pleziokron digitális hierarchia Időmultiplex Európai Unió Üzemeltetés és Fenntartás Információtechnológia Internet Protokoll 6.-s verzió legrövidebb út algoritmus modulációs mód modulációs mód Shortest Path First - legrövidebb út algoritmus Constrained Shortest Path First - korlátos legrövidebb út algoritmus Módosított gráfelméleti algoritmus, kapacitások jobb kihasználtságára

15 VÉDELMI INFOKOMMUNIKÁCIÓ Felhasznált irodalom 1. Traffic Optimization in a backbone. Attila Bleier, dr. Rajnai Zoltán , Budapest : Zrínyi Miklós Nemzetvédelmi Egyetem Publishing Office, 2008., 7/2. kötet. ISSN Université de Liége. TOTEM project - A TOolbox of Traffic Engineering Methods. Research unit in Networking Université de Liége. [Online] [Hivatkozva: ] php?project=totem. 3. Liége, Université de. Overview. E-next - Totem Project - Toolbox for Traffic Engineering Methods. [Online] [Hivatkozva: ] 4. Traffic Engineering an Operational Network with the TOTEM Toolbox. Balon, S., és mtsai , Geneve : IEEE, 2007., 4/1. kötet. ISSN: Károly, dr. Fekete. A Magyar Honvédség állandó telepítésű kommunikációs rendszere továbbfejlesztésének technikai lehetőségei. Phd. értekezés. Budapest : ZMNE, Sándor, Dr. Munk. Katonai informatika a XXI. század elején. Budapest : Zrínyi kiadó, ISBN: Új generációs hálózati megoldások alkalmazása a Magyar Honvédség hálózatának modernizációjában. Attila, Bleier. Budapest, ZMNE, 2009, Hadmérnök, IV./2. kötet, old.: ISSN

16 200