Önálló laboratórium beszámoló

Átírás

1 Önálló laboratórium beszámoló BME-TTT Készítette: Hegyi Péter cím: Neptun-kód: OLU8OK Konzulens(ek): Cinkler Tibor, Maliosz Markosz címe(k): Tanév: 2003/ félév Téma címe: VPN tervezés heurisztikus módszerekkel Feladat: a félévi feladat az volt, hogy elkészüljön egy olyan rendszer, mely Virtuális Magánhálózat tervezésére alkalmas. A program több szempont szerint tud optimális megoldást nyújtani /06/2004

2 1. A laboratóriumi munka környezetének ismertetése, a munka elõzményei és kiindulási állapota Bevezetõ/elméleti összefoglaló Virtuális Magánhálózatok A mai, több telephellyel rendelkező cégek számára létfontosságú egy integrált infokummunikációs hálózat, hogy az egyes egységek között megvalósulhasson a gördülékeny együttműködés. Ha egy ilyen cég szeretne telephelyei közé egy saját hálózatot, akkor két lehetőség adódik. Az egyik, hogy a hálózatot maga építi ki, saját költségén. Ennek a megoldásnak azonnal szembetűnő hátránya a magas kiépítési és üzemeltetési költség: a cégnek kell beszerezni a hálózati elemeket, a kábeleket, neki kell a hálózatot kiépíteni, valamint karbantartani. Ezek feladatok mindegyike külön-külön is olyan költséget jelent, amit egy átlagos cég nem képes elvállalni. Így egy másik megoldás válik egyre népszerűbbé. Ennek a lényege, hogy a cég a magánhálózatot egy, vagy több szolgáltató már kiépített hálózatán valósítja meg [1], azaz bérel a szolgáltató hálózati erőforrásaiból. Például adott összeköttetésen lefoglal egy bizonyos sávszélességet, amit a szolgáltató fenntart a cég számára. Ezt a megoldást nevezik Virtuális magánhálózatnak (Virtual Private Network, VPN). Egy VPN tulajdonképpen hálózat a hálózatban. A szolgáltatótól bérelt termék látszólagosan egy magánhálózat virtual. Mivel a szolgáltató hálózata általában nyilvános, ezért, hogy az adatok kívülről ne legyenek hozzáférhetők idegenek számára, a forgalmat titkosítani kell private, továbbá egy hálózat, amely összeköti a telephelyeket, és adatok továbbítására használható network. Természetesen nem csak a számítógéphálózatok világában létezhetnek VPN-ek. Elképzelhetőek például telefonszolgáltatóknál is: egy több telephelyű cég kibérelhet telefonvonalakat, melyek után egy szerződés értelmében éves díjat fizet, függetlenül a tényleges forgalomtól (nem percdíjas számlázás). A VPN független mindenféle implementációtól, bármilyen technológia felhasználásával megvalósítható. A lényeg, hogy a VPN csomópontjai közé útvonalakat tervezzünk az őt hordozó hálózaton. Tekintsük át a napjainkban használt VPN technikákat, amelyeket az ISO-OSI modell több rétegén is létrehozhatunk [1]. A fizikai rétegben a bérelt vonalas szolgáltatás igénybevételével lehet VPN-t definiálni. Ekkor gyakorlatilag fizikai szintű eszközöket bérlünk. Ilyen lehet például egy telefonvonal, vagy egy kábelköteg egyik vezetéke. Az adatkapcsolati rétegben megvalósítottnak tekintjük azokat a VPN-eket, amiket második rétegbeli protokollok valósítanak meg. Beszélhetünk tehát MPLS, ATM, illetve Frame Relay alapú VPN-ekről. A hálózati rétegen létrehozott VPN-ek alagutazáson alapulnak. Ez azt jelenti, hogy virtuális alagutakat hozunk létre a VPN csomópontjai között, amit ennek a rétegnek a /06/2004

3 segítségével tehetünk meg. Ebben a VR, IPSec, illetve a BGP/MPLS protokoll lehet segítségünkre. Alagutazás megvalósítására két alapvető modell létezik. Az egyik az úgynevezett Ügyfél Telepítésű VPN (Customer Premises Equipment - CPE), a másik pedig a hálózat alapú VPN. Az első megoldás esetén minden VPN funkciót (például titkosítás, azonosítás) a felhasználó telephelyén implementálnak. A szolgáltató hálózata nem is tud arról, hogy egy VPN forgalma halad át rajta, mert a felhasználó által generált IP csomagok semmiben sem különböznek más, egyéb forgalomhoz tartozó IP csomagoktól. Ennek hátránya, hogy az, hogy a VPN tulajdonos részéről jólképzett szakértőket igényel az üzemeltetése. Manapság inkább a hálózat alapú megoldások terjednek. Ezek lényegében ellentétük a CPE alapú VPN-eknek. Egy VPN üzemeltetéséhez speciális hardver és szoftver eszközök szükségesek. Ezekre együttesen a továbbiakban, mint a VPN üzemeltetéséhez szükséges intelligenciára fogunk hivatkozni. Hálózat alapú magánhálózat esetén a VPN-t üzemeltető intelligencia nem a telephelyeken található, hanem a szolgáltató hálózatában. Az intelligencia megvalósításának is két módja van. Az egyik Virtuális Útvonalválasztókat (Virtual Router - VR) használ. Ezek tulajdonképpen programok, melyek a határcsomópontokon futnak. Úgy működnek, hogy a másik telephelyre küldendő adatokból új csomagokat formálnak. Ismerik a VPN belső címzését, így átfordítják azt a gerinchálózaton értelmezhető címekre, és elküldik a másik telephelyhez tartozó határcsomópontnak. Az új csomagba belekerül, hogy a másik telephelyen belül milyen címre küldték az adatot. Így a cél telephelyet csatoló határcsomópont az érkező csomagokkal ugyanezt visszafele is el tudja végezni, azaz miután a csomag megérkezett, akkor előkerül belőle a célgép belső VPN címe, ahová küldték, és a csomag folytathatja útját. A másik megoldás a VPN-t vezérlő intelligencia létrehozására, hogy alagutakat definiálunk a határcsomópontok közé. Ekkor az egyes VPN csomópontok között valamilyen elven előre meghatározott útvonalakon szállítja a hálózat az adatokat. A félévben ezzel a megoldással foglalkoztam. Védelem Egy hálózatban az összeköttetések megszakadhatnak, a hálózati csomópontok leállhatnak, ezért ahhoz, hogy a szolgáltató megbízható, hibatűrő szolgáltatást nyújthasson, a VPN útvonalait védeni is kell. Védelem biztosítására különféle módszerek vannak. Az alapgondolat az, hogy védelmi utakat definiálunk, ami azt jelenti, hogy ha megsérül egy összeköttetés, és nem tudja ellátni feladatát, akkor az azon haladó igényeket eltereljük más útvonalra, hogy a forgalom ne álljon le és a szolgáltatás folyamatos legyen. Védelmi útvonalakat definiálhatunk szakasz, szegmens, illetve egész útvonalak megsérülése esetére [2][3]. A félévben útvonalvédelemmel foglalkoztam. Tehát az igényeknek egy elsődleges, üzemi útvonalat, és egy másodlagos, védelmi útvonalat kerestünk /06/2004

4 Egy másik alapvető kérdés az, hogy mikor határozzuk meg egy igény elvezetését [4]. Online módszereknek hívjuk azokat a metódusokat, melyek az igénnyel annak megjelenése pillanatában foglalkoznak. A módszer hátránya, hogy mivel a tervező módszerek futási ideje limitált (például kevesebb, mint 1 másodperc [5]), ezért alacsony komplexitású algoritmusokat lehet csak alkalmazni. Emiatt általában nem az optimális védelmi útvonalat találjuk meg, és hamar elpazaroljuk az erőforrásokat. Ezzel szemben az offline (proaktív) módszerek központi erőforrásokat használnak, és tervezés után állítják be a különböző útvonalválasztókat [6][7]. Ebben az esetben lehetőség van bonyolultabb algoritmusok futtatására is, ugyanis nincs olyan szoros időkorlát, mint online esetben. Emiatt lehetőség nyílik ésszerűbben elvezetett védelmet, előrelátóbb erőforrás-felhasználást tervezni. Ugyanakkor ennek a módszernek is megvan a maga hátránya: a tervezett hálózat nem dinamikus. Online módszereket akkor használunk, mikor tudjuk, hogy az igények időben rövidtávúak, és hamar várható helyettük más igény felbukkanása. Offline módszereket akkor alkalmazunk, mikor hosszútávra tervezünk, és nem számítunk az igények megváltozására. Ez az eset áll fenn VPN-ek tervezésekor is, hiszen azok topológiájára nem jellemző, hogy változnának, mert egy cég nem váltogatja sűrűn a telephelyeit [8]. Emiatt a félév során az úgynevezett offline módszerekkel foglalkoztam. Megosztott védelem A védelmi útvonalak megtervezése során dolgozhatunk úgy, mintha a védelmi útvonalak csak másodlagos üzemi útvonalak lennének. Ez azt jelenti, hogy amerre a védelmi útvonal halad, ott lefoglalunk az igénynek megfelelő sávszélességet. Ezt a megoldást, mikor a védelmi útnak az előzményektől függetlenül minden élen teljes egészében lefoglaljuk a kapacitást, hozzárendelt védelemnek hívjuk. Mivel a meghibásodások meglehetősen ritkák, ez a megoldás pazarló. Feltételezhetjük, hogy két meghibásodás között eltelik annyi idő, amennyi alatt a korábbi meghibásodást kijavítjuk. Ezt a védelem tervezésekor felhasználhatjuk, hiszen ez azt jelenti, hogy számolhatunk úgy is, hogy a hálózatban egyszerre csak egy hiba van jelen. Hozzárendelt védelem esetén két igény védelmi útvonalainak közös élein az igények kapacitásának összegét foglaltuk le. A fenti, a hibák gyakoriságára vonatkozó feltétel szerint, sosincs kihasználva teljesen a védelemre foglalt kapacitás olyan éleken, ahol több igény védelmi útvonala áthalad. Ezért ilyenkor jobban járunk, ha megosztott védelmet használunk. A megosztott védelem azt jelenti, hogy megengedjük az ilyen esetekben, hogy a védelmi útvonalak megosszanak egymás közt valamennyi védelemre lefoglalt kapacitást [9]. Így nem kell a védett igények kapacitásának összegét lefoglalni védelemre. Ha két igény üzemi útvonalában nincsen közös él, akkor mivel egyszerre csak egy hibát feltételeztünk a hálózatban a két üzemi útvonal nem hibásodhat meg egyszerre, azaz egyszerre csak az egyik igénynek lehet szüksége a védelmi útvonalára. Így elég, ha csak a legnagyobb védett igénynek elegendő kapacitást foglaljuk le egy-egy védelmi élen. [10] /06/2004

5 Előfordul, hogy több igény üzemi útvonala ugyanazon élen halad. Az is előfordulhat, hogy ezek közül az igények közül néhánynak a védelmi útvonalában is előfordul közös él. Ha pont a közös üzemi él esik ki, akkor a közös védelmi élen nem elég csupán ezen igények közül a legnagyobbiknak elegendő kapacitást lefoglalni, mert még más igények is szeretnék használni azt az élet, hiszen az ő üzemi útvonaluk is sérült. Ilyenkor a közös védelmi élen a közös üzemi útvonalat használó igények kapacitásösszegét kell figyelembe venni. Modell A telephelyek, felhasználók határcsomópontokon keresztül csatlakoznak a hálózathoz. Továbbá feltételezzük, hogy a határcsomópontok pont-pont közötti összeköttetéseken keresztül kommunikálnak egymással. A fenti modell miatt a hálózatot gráffal írtuk le. A forgalom leírására Pipe-modellt alkalmaztuk. Ennek használatakor azt tudjuk, hogy az egyes csomópont-párok között mekkora az igényelt sávszélesség. Ezért a forgalmat, azaz a magánhálózat összeköttetés igényeit leírhatjuk úgy, mint egy hálózatot, melyet egy másik gráffal jeleníthetünk meg. A munka állapota, készültségi foka a félév elején A félév elején készen volt egy program, mely adott igény üzemi, illetve védelmi útvonalát el tudta vezetni. Ehhez a Dijkstra algoritmust használta. A Dijkstra algoritmus futásához szükséges élsúlyok minden élhez egyformák voltak, így a legkisebb ugrásszámú megoldást adta számunkra a program. Tételesen felsorolva: Dijkstra algoritmust használó üzemi, illetve védelmi útvonalválasztó program /06/2004

6 2. Az elvégzett munka és eredmények ismertetése Az általam konkrétan elvégzett munka bemutatása A félév során vizsgáltam, hogy a félév elejére már elkészült tervezőrendszert hogyan lehet úgy módosítani, hogy az eddigieknél jobb eredményt kapjak. A kapott eredmény jóságát annak árával jellemeztem. Egy átlagos szolgáltatónak az összeköttetések kiépítésekor általában kétféle költsége merül fel: egy fix és egy sávszélességtől függő tag. A rögzített költségek több tényezőből adódnak. A hálózatban az összeköttetéseket ki kell építeni, valamint karban kell tartani, stb. Ha kevesebb összeköttetést vesz igénybe a megrendelő, akkor természetesen a felmerülő fix költségek is csökkennek. Ugyanakkor a szolgáltatónak van egy terméke, amit el szeretne adni. A kockázat az, hogy az áru megmarad, ezért jutalmazza, ha a megrendelő nagy tételben vásárol. Ekkor csökken annak kockázata, hogy a terméket nem tudja eladni. Továbbá az is igaz, hogy a szolgáltatónak jobb, ha egyben el tudja adni a kapacitásokat az éleken, mert így könnyebben tervezhető marad a hálózat. Ezzel csökkenti annak esélyét, hogy sokáig adogat el kisebb darabokat egy-egy összeköttetés sávszélességéből, majd jön egy vevő, akinek egy helyen kéne nagy kapacitás, és őt már nem tudja kiszolgálni. Ezért a szolgáltató a bérelt sávszélességtől függően kedvezményt ad. Az előbbiekből következik, hogy kevesebb összeköttetés felhasználása esetén kevesebb rögzített költség hárul a megrendelőre. Ráadásul, mivel a szolgáltatók nagyobb sávszélességek bérlésekor további kedvezményeket adnak, ezért érdemesebb az igények egy csoportját úgy elvezetni, hogy azok a lehető legkevesebb élet használják fel. Ezáltal egy élet sok igény használ, több sávszélességet foglal le, így a megrendelő költségei tovább csökkenthetőek. A fentiek alapján meghatároztunk egy költségfüggvényt, mellyel egy-egy megoldást tudunk jellemezni. A költséget élenként számoljuk. Az egy élre fizetendő költséget (1), és azábra 1. ábra mutatja. Cél tehát, hogy egy összeköttetést minél több igény használjon útvonalában, azaz az igényeket tereljük a lehető legkevesebb élre. A terelés megvalósítása a Dijkstra algoritmus által használt élsúlyokon alapszik. (1) Algoritmusok Távolság Alapú Algoritmus (TA) Ábra 1 Kapacitás-ár függvény /06/2004

7 A TA algoritmus a védelmi útvonalak (a felhasznált összeköttetések számával mért) hosszát igyekszik minimalizálni, ezért az alap súly 1, és a büntető súly C. Így a nem büntetett élek súlya 1, a büntetetteké pedig C+1. A TA algoritmus végzi a legegyszerűbb módon a forgalom összefogást, mert figyelmen kívül hagyja a védelmi kapacitások megoszthatóságát, és a felhasznált élek egyéb jellemzőit is. Ez az algoritmus volt adott a félév elején. Kapacitás Alapú Algoritmus (KA) A KA algoritmus esetében egy él alap súlya az a kapacitás mennyiség, amit rajta a jelenleg lefoglalt kapacitáson felül le kell foglalni abban az esetben, ha az elvezetendő igény védelmi útvonala használni fogja az adott élet. Így a legkisebb járulékos kapacitásfoglalást igénylő útvonalon vezetjük el az igényeket. A büntető súly C-szer az átlagos igény sávszélesség, ami megmutatja, hogy mekkora kerülőutat preferálunk egy új foglalandó éllel szemben. Módosított Kapacitás Alapú Algoritmus (MKA) A MKA algoritmus esetében a büntető súly ugyanaz, mint a KA esetében. Az alap súly azonban meg van szorozva az alábbi függvény (f(x)) értékével. A függvényben x az él felhasználási gyakorisága, azaz hogy hány igény védelmi útvonala használja az adott élet. A függvény értéke 1-nél 1, majd monoton csökken (y=a az aszimptótája). Ezáltal a már használt élek között is tesz különbséget, aszerint, hogy hány igény védelmi útvonala használja azt. (2) Így a MKA algoritmus előnyben részesíti a gyakran használt éleket, annak reményében, hogy jobban ki tudja használni a védelmi kapacitások megoszthatóságát. Terelési módok A Modell fejezetben leírtak szerint egy VPN tervezésekor a hálózati forgalmat érdemes minél kevesebb élre terelni. Felmerül a kérdés, hogy érdemes-e a forgalmat VPN-enként összeterelni nem foglalunk-e le több erőforrást az összes forgalom egybetereléséhez képest. A válasz az, hogy előfordul, hogy több kapacitást foglalunk le VPN-enkénti terelés esetén. Ha lokális optimumokra törekszünk, vagyis az a cél, hogy egy-egy VPN a lehető legkevesebb erőforrást használja, az nem jelenti azt, hogy akkor a hálózatban összességében is a legkevesebb erőforrást foglaltuk le. Az, hogy több erőforrást foglalunk le a hálózatban, nem feltétlen jelenti azt, hogy a VPN-enkénti terelés gondolatát el kell vetnünk. Ugyanis ha a szolgáltatás árát a foglalt erőforrások mennyisége alapján határozzuk meg, akkor ebben az esetben az egyes VPNek kevesebb erőforrást használnak, olcsóbban eladhatóak, és így többen megengedhetik, többen veszik igénybe szolgáltatásunkat, ami hosszútávon nyereséges lehet számunkra /06/2004

8 Ezért a következő tervezési módokkal foglalkozunk a továbbiakban. A. Az üzemi, és a védelmi útvonalak után fizetendő árat egyaránt a foglalt erőforrás alapján határozzuk meg. Ezért mind az üzemi útvonalakat, mind a védelmi útvonalakat VPN-enként tereljük egybe, ami azt jelenti, hogy arra törekszünk, hogy egy VPN a lehető legkevesebb üzemi, illetve a lehető legkevesebb védelmi élet használja fel útvonalaiban. A különböző VPN-ek nem oszthatják meg egymás közt a lefoglalt védelmi sávszélességeket, mert mindegyik megrendelő kifizette a VPN-je által használt sávszélességet, amit használhat akár egy meghibásodás bekövetkeztéig alacsonyabb rendű forgalom szállítására is. B. Az üzemi útvonalakat VPN-enként tereljük egybe, és ebben az esetben is a használt erőforrások alapján számoljuk ki a szolgáltatás árát. A védelem számlázása azonban nem erőforrás alapú, ezért igyekszünk az összes védelmi útvonalat egybeterelni. A szolgáltató minimalizálni tudja a hálózaton védelemre fordított erőforrásokat, mert az összes VPN védelmét megoszthatja, és egybeterelheti a védelmi forgalmakat, így biztosítva a közös védelmet az összes VPN-nek. Továbbá ebben az esetben a szolgáltató alacsonyabb rendű forgalmat terelhet a védelmi VPNre, amíg meghibásodás nem következik be. C. Ebben az esetben az üzemi útvonalakat sem VPN-enként tereljük, hanem egybe. Eddig azt mondtuk, hogy a VPN-ek árait tartsuk minél alacsonyabban, hogy a piaci versenyben megfelelően alacsony árakkal szerepelhessünk. A most bemutatandó módszer a monopolhelyzetben levő cégek érdekeit írják le, vagy olyanokét, akik számára biztosított az elegendően sok megrendelő. Ekkor ugyanis az olcsó VPN szolgáltatásnál sokkal fontosabb, hogy a hálózatból ne foglaljanak le túl sok erőforrást a VPN-ek. Ezért a szolgáltató mind az üzemi, mind a védelmi útvonalakat egybetereli. Ez természetesen nem jelenti azt, hogy a VPN-ek ára emelkedni fog. Ha sok a megrendelő, akkor a forgalmat jobban lehet terelni, egy összeköttetést többen fognak használni. Ezzel a szolgáltató jobban kihasználja egyes összeköttetéseit, míg másokat kevésbé vesz igénybe. Ennek eredménye, hogy bár több felhasználót szolgál ki, költségei mégsem nőnek, és erőforrásai nem csökkennek a felhasználótábor növekedésének ütemében. Így szolgáltathat ő is olcsón, ha az egyes megrendelőknek nem az általuk foglalt erőforrás alapján számítja az árat. D. Ez a tervezési mód a VPN tervezés és az általános útválasztási eljárások összehasonlításához nyújt alapot. Itt nem tereljük sem a védelmi, sem az üzemi útvonalakat, hanem hagyjuk, hogy az útkereső megtalálja a legrövidebb útvonalat a csomópontok között. Szimuláció A szimulációkhoz a hálózatot a BRITE nevű programmal generáltam [11]. Ez a program többféle algoritmus alapján is tud topológiákat generálni, ezek közül a Barabási Albert módszert használtam. Az élek kapacitása a hálózatban állandó (1024) volt. Az átlagos fokszám a hálózatban , a csomópontszám pedig /06/2004

9 A forgalmakat saját programmal állítottam elő. 30 darab VPN-t definiáltam. A VPNek öt csomópontból álltak. Egy VPN-en belül minden csomópontból megy igény minden másikba (full mesh). Tehát egy VPN 20 forgalmi igényt jelent. Az igények sávszélességét 45 és 55 között egyenletes eloszlással generáltam. Eredmények A következőkben részletezett eredményeket az 2. Ábraán látható diagramokon ábrázoltam. Tervezési módok Mikor lokális optimumra törekedtünk mind üzemi, mind védelmi útvonaltervezésnél, a foglalt kapacitás szempontjából is, és a lefoglalt élek számát tekintve is összességében a legdrágább megoldást kaptuk. A tervezési mód mégis beváltja a hozzá fűzött reményeket, hiszen a VPN-enkénti élszám, illetve foglalt kapacitás ebben az esetben a legkisebb. Mikor a védelmi útvonalak esetén globális optimumot keresünk, akkor mindkét esetben (üzemi útvonalak globális/lokális optimuma) több kapacitást foglaltunk le, mint akkor, mikor nem használtunk terelést. Ennek oka a kerülőutakban keresendő, melyet a terelés okoz. A lefoglalt élek számát tekintve azonban mindkét globális terelést alkalmazó mód jobbnak bizonyult a terelés nélküli módnál. Algoritmusok A különböző algoritmusok használata nem jelentett drasztikus különbséget a mérési eredményekben. A Távolság Alapú algoritmus kevesebb üzemi kapacitást foglal le, mint a Kapacitás Alapú algoritmusok. Ennek oka, hogy nem kényszerül kerülőutakra. A lefoglalt védelmi kapacitásban gyakorlatilag nem volt különbség. Az összesen lefoglalt élek száma körülbelül ugyanannyi, de a Távolság Alapú algoritmus esetében jóval több azon élek száma, melyek mind üzemi, mind védelmi útvonalakban szerepelnek, míg a csak üzemi élek száma kevesebb. Összefoglalás A félév során a következő pontokat hajtottam végre elolvastam az irodalomjegyzékben található dokumentumokat az eddiginél eredményesebb útválasztó algoritmusokat fejlesztettem az algoritmusokat teszteltem és összehasonlítottam /06/2004

10 2. Ábra Diagramok a kapott eredményeket publikáltam Shared Protection of Virtual Private Networks with Heursitic Methods; Polish-Hungarian-Czech Workshop on Circuit Theory, Signal Processing, and Applications; Hegyi Péter, Ladányi Ákos, Maliosz Markosz, Cinkler Tibor szeptember , Prága Heuristic Algorithms for Shared Protection of VPNs; 9 th EUNICE Open European Summer School and IFIP WG6.3 Workshop on Next Generation Networks; Hegyi Péter, Ladányi Ákos, Maliosz Markosz, Cinkler Tibor szeptember Balatonfüred Shared Protection of VPNs withttraffic Concentration; DRCN 2003 the 4 th International Workshop on Design of Reliable Communication Networks; Hegyi Péter, Ladányi Ákos, Maliosz Markosz, Cinkler Tibor október , Kanada, Banff VPN tervezés heurisztikus módszerekkel; TDK, 1. helyezett; Hegyi Péter, Ladányi Ákos, Maliosz Markosz, Cinkler Tibor november 11. Budapest VPN Design with traffic concentration; őszi HSN WorkShop; november Irodalom, és csatlakozó dokumentumok jegyzéke A tanulmányozott irodalom jegyzéke: [1] Jeremy De Clercq, Olivier Paridaens, Scalability Implications of Virtual Private Networks, IEEE Communications Magazine, május. [2] Pin Han Ho and H.T. Mouftah, A Framework for Service-Guaranteed Shared Protection in WDM Mesh Networks, IEEE Communications Magazine, pp , február. [3] Pin Han Ho and H.T. Mouftah, Allocation of Protection Domains in Dynamic WDM Mesh Networks, 10th IEEE International Conference on Network Protocols (ICNP 2002), Proceedings pp , Párizs, Franciaország, november /06/2004

11 [4] M. Kodaliam and T. Lakshman, Dynamic Routing of Bandwidth Guaranteed Tunnels with Restoration, IEEE Infocom [5] Józsa Balázs Gábor, Orincsay Dániel, Kern András, Surviving Multiple Network Failures Using Shared Backup Path Protection, International Symposium on Computers and Communications (ISCC 2003), Kemer, Törökország, tavasz. [6] B. Józsa, D. Orincsay, Shared Backup Path Optimisation in Telecommunication Networks, Design Of Reliable Communication Networks, DRCN 2001, Budapest, Magyaroroszág. [7] Al-Rumaih, D. Tipper, Y. Liu and B.A. Norman, Spare Capacity Planning for Survivable Mesh Networks, Proceedings IFIP-TC6 Networking, Párizs, Franciaország, május [8] Cinkler Tibor, Maliosz. Markosz, Configuration of Protected Virtual Private Networks, Design Of Reliable Communication Networks, DRCN 2001, Magyarország, Budapest, 2001, [9] V. Subramani, A Heuristic Routing Algorithm for Shared Protection Optical Network, Project report, CSE990 - Optical Communication Systems/Networks, University of Nebraska, Lincoln. [10] Shengli Yuan, Jason P. Jue, Shared Protection Routing Algorithm for Optical Networks, Optical Networks Magazine, vol. 3, no. 3, pp , május/június. [11] A.Medina, A. Lakhina, I. Matta and J. Byers, BRITE: Universal Topology Generation from a User's Perspective (User Manual) BU-CS-TR Computer Science Department, Boston University, április 5. Csatlakozó egyéb elkészült dokumentációk / fájlok / stb. jegyzéke: az elkészült program, a szimulációk és az egyes konferenciacikkek az opt.tmit.bme.hu kiszolgálón találhatóak, a VPN nevű repository-ban. Megtekintéséhez hozzáférés szükséges, és VPN csoporttagság /06/2004