TALLINNA TEHNIKAÜLIKOOL ÄRIKLIENDI ANDMESIDELAHENDUSE ÜLEVIIMINE MPLS VÕRGUTEHNOLOOGIALE

Transcription

1 TALLINNA TEHNIKAÜLIKOOL Raadio- ja sidetehnika instituut Telekommunikatsiooni õppetool Kood: IRT70LT ÄRIKLIENDI ANDMESIDELAHENDUSE ÜLEVIIMINE MPLS VÕRGUTEHNOLOOGIALE Helin Toom Töö on tehtud telekommunikatsiooni õppetooli juures Juhendaja Indrek Rokk Konsultant vanem võrguadministraator Rain Nõmm Kaitsmine toimub raadio- ja sidetehnika instituudi kaitsmiskomisjonis Autor taotleb tehnikateaduse magistri kraadi Esitatud: Kaitsmine: Tallinn 2010

2 REFERAAT Käesolev magistritöö Ärikliendi andmesidelahenduse üleviimine MPLS võrgutehnoloogiale käsitleb keskmise ärikliendi andmesidelahenduse üleviimist ATM tehnoloogialt MPLS tehnoloogiale. Töö eesmärk on, teenusepakkuja tuumikvõrgu võimalusi arvesse võttes, leida konkreetse ärikliendi jaoks parim võimalik andmesidelahendus. Selleks käsitletakse ATM tehnoloogial baseeruva kliendilahenduse kitsaskohti nii kliendi vaatest kui ka sideettevõtte vaatest ning selgitatakse välja, kuidas MPLS tehnoloogial baseeruv kliendilahendus nendest kitsaskohtadest hoiduda aitab. Töös võrreldakse ka kahe erineva tootja (Cisco Systems ja Juniper Networks) seadmete poolt võimaldatavat tsentraalset internetilahendust MPLS VPN privaatvõrku omavatele klientidele internetiteenuse pakkumiseks. Eelistatud lahenduseks osutub Juniper Networks i seadmete abil pakutav lahendus. Töö on kirjutatud eesti keeles 82 leheküljel ning sisaldab 31 joonist ja 4 tabelit. Märksõnad: ATM, MPLS, IP, L3VPN, VRF, label switching

3 ABSTRACT This master thesis Data communication solution of a medium business client based on MPLS technology explores the possibility to replace ATM technology based data communication solution with MPLS technology based data communication solution for a medium size business client. Goal of the research is to verify the best feasible data communication solution for the business client considered in the thesis. Proposal is based on analysis combining drawbacks of data communication solution based on ATM technology and advantages offered by MPLS technology from client s point of view and also from operator s point of view. The master thesis compares also centralized internet solutions offered by two different producers (Cisco Systems and Juniper Networks). Solution offered by Juniper Networks proves to be more favorable than the alternative. Thesis is written in Estonian and consists of 82 pages, including 31 figures and 4 tables. Keywords: ATM, MPLS, IP, L3VPN, VRF, label switching

4 EESSÕNA Meie igapäevane elu ja äritegevus sõltub järjest enam infotehnoloogiast. Seetõttu muutub üha olulisemaks andmesideühenduste kättesaadavus ning samuti ka nende stabiilsus. Üha kasvavad edastamist vajavad andmemahud ning majanduse surve teenuste hindadele nõuavad teenusepakkujatelt endiselt uuemate tehnoloogiate ning veelgi innovaatilisemate lahenduste kasutuselevõtmist, et pakkuda klientidele teenust neile sobiva hinnaga ning vähendada ka andmesideühenduste halduskulusid. Käesolevas töös võrreldakse ühe Eesti keskmise ärikliendi vajadustele vastavat ATM tehnoloogial baseeruvat andmesidelahendust (privaatvõrk + internet) ning MPLS tehnoloogial baseeruvat andmesidelahendust. Töö käigus selgitatakse välja ATM tehnoloogial baseeruva kliendilahenduse kitsaskohad nii teenusepakkuja kui ka kliendi vaatest ning jõutakse konkreetse kliendi jaoks parima võimaliku andmesidelahenduseni teenusepakkuja tuumikvõrgu võimalusi arvesse võttes. Töö käigus leitakse vastus ka küsimusele, kuidas pakkuda MPLS VPN võrku omavatele SME-dele (Small and Medium Enterprises) internetiteenust võimalikult soodsalt ning mugavalt. Teema valikul lähtus autor soovist omandada paremad teadmised teenuspakkuja võrgutopoloogiast kliendilahenduse vaatest lähtuvalt, mis on viimased 3 aastat olnud seotud autori igapäevaste tööülesannetega kliendilahenduste haldamisel. Töö koostamise käigus on läbi viidud muuhulgas ka mitmeid intervjuusid administraatoritega ning kasutatud teemaga haakuvate töögruppide materjale, mille avaldamiseks puudub luba, kuid mille sisu väljendub autori hinnangutes. Töö koostamisel abiks olnud toe, nõuannete ja tagasiside eest tahan siiralt tänada juhendajat Indrek Rokk i ning konsultanti ja kolleegi Rain Nõmm i. Lisaks soovin tänu avaldada kõikidele spetsialistidele, kes töö valmimisel nõuga abiks olid. Helin Toom Tallinn,

5 SISUKORD!"! ""# ### $ %"# &' (! #! &' ( "!) *! +!!!',)( ' -,".)/.(0',)1"" 2",".02,1 2, "-#5(1 &#! "#0(1 ',)&""$ $ #0)&..# )9"/ "(+":06 8) ( 6 """0.1 # ; )4 ",".0)4,1$ ',)0)<,6 1<,6 ( *! "(!(! "(! ',)<,6- => ; ',)<,6 (! ; ',)<,6-# 0."1 <"5(9"/ "( $ ',-?@,#" "" 054 ( "-541 ' " "# -05"(1 %""!! "',)<,6 0)<,6 1(

6 $ $ "" )<,6! "#!$ $ 3. $ $ # "!"("!"$ $ ) $ $ ) " $ $ A" $ $ # "!"("!"$ $ ) $ $ ) " $ $ ) $ %"# ',)( *! * " $ ) 2," * ; ),#8,(0,8,1

7 TEKSTIJOONISTE LOETELU Joonis 1. Riigid, kus on võimalik kasutada BT MPLS teenuseid (märgitud tumehalliga) [40] Joonis 2. Kliendi X Andmesidelahendus ATM tehnoloogia baasil Joonis 3. Label swapping [8]$ Joonis 4. PVC ning SVC kasutus ATM võrgus [4] Joonis 5. ATM ning GE võrgu liitmine Joonis 6. IP protokolli edastus üle ATM võrgu [6] Joonis 7. ATM rakk [2]; Joonis 8. IPv4 päis [8] Joonis 9. Alamvõrkudeks jaotamine Joonis 10. Sildi kapseldus [8] Joonis 11. MPLS domeenid, LSRid ja MPLS sõlmed [8] Joonis 12. Näide multi-protocol label switching ust [8] Joonis 13. Label switched path s [8] Joonis 14. Siltide järjekord (label stack) Joonis 15. Näide siltide järjekorra (label stack) kasutamisest [8]$ Joonis 16. Saite jagavad VPN-id [17] Joonis 17. Kliendi võrguvaade [17] Joonis 18. Teenusepakkuja võrguvaade [17] Joonis 19. Ülevaade MPLS VPN juhtimistasandi kontseptsioonist [23] Joonis 20. Ülevaade MPLS VPN-i andmetasandist [23] Joonis 21. Marsruuteri PE2 VRF-i CE-lt õpitud marsruutide lisamine [23] Joonis 22. Prefiksite unikaalseks muutmine RD abil [23]$ Joonis 23. MPLS Route Target i mehaanika [23] Joonis 24. Kliendi X privaatvõrk MPLS VPN tehnoloogia baasil$; Joonis 25. IP aadressid kliendi L3VPN võrku juurdepääsul$ Joonis 26. Cisco seadmete abil pakutav tsentraalne internetilahendus$ Joonis 27. Juniper i seadmete abil pakutav tsentraalne internetilahendus$ Joonis 28. Kliendi X MPLS VPN tehnoloogia baasil toimiv andmeside võrk Joonis 29. IP aadresside klassid [8]; Joonis 30. Kaks otsingut Egress PE LFIB-is [23] Joonis 31. Üks otsing Egress PE LFIB-ist (PHP) [23]

8 TABELITE LOETELU Tabel 1. Kliendi harukontorite loetelu ja vajalikud ribalaiused Tabel 2. FEC sissekanne igas LFIB-is Tabel 3. Sildiga seotud informatsiooniga FEC sissekanne igas LFIB-is; Tabel 4. Tsentraalse internetilahenduse CAPEX võrdlus kahe erineva tootja samaväärseid seadmeid kasutades

9 TÄHISTUSTE LOETELU 3G ASN ATM BGP BT CAPEX CE CEF CI CIDR CoS CPE CPU DLCI DSL DSLAM EBGP EIGRP ETH FEC FIB FOC FTN GE Third Generation Kolmanda generatsiooni mobiilsidevõrk Autonomous System Number Anonüümsüsteemi number Asynchronous Transfer Mode Asünkroonne ülekande tehnoloogia border gateway protocol marsruutimisprotokoll British Telecom Rahvusvaheline sideoperaator Capital Expenditure Kapitalikulu Client Edge Kliendi võrgusõlme tähistus Cisco Express Forwarding Suurtes tuumvõrkudes või internetis kasutatav kolmanda kihi kommutatsioonitehnoloogia Connection identifier Ühenduse identifikaator Classless Inter-domain Routing Klassideta domeenidevaheline marsruutimine Class-of-service 3-bitine väli ethernet protokolli päises Customer Premises Equipment Seade kliendi valdustes Central Processing Unit Keskprotsessor Data Link Connection Identifier Frame relay kaadrite päisesse lisatud ühenduse identifikaator Digital Subscriber Line Digitaalne abonendiliin Digital Subscriber Line Access Multiplexer DSL pöördusmultiplekser External Border Gateway Protocol Autonoomsete süsteemide vaheline marsruutimisprotokoll Enhanced Interior Gateway Routing Protocol Marsruutimisprotokoll Ethernet Kohtvõrgu standard Forwarding Equivalent Class Ühte ja sama prefiksit omavad IP aadressid Forwarding Information Base Edastustabel Fibre Optic Cable Fiiberoptiline kaabel Forwarding Equivalent Class to Next Hop Label Forwarding Entry map Sildijaotusprotokoll Gigabit Ethernet Kohtvõrgu standard kiirusega 1 Gb/s

10 ; IBGP Internal Border Gateway Protocol Autonoomsete süsteemide sisene marsruutimisprotokoll IETF Internet Engineering Task Force Interneti standardeid loov organisatsioon IGP Interior Gateway Protocol Siselüüsi protokoll IGW Internet Gateway Interneti lüüs IHL Internet Header Lenght 4 bitine väli, mis annab IP päise pikkuse 32-bitiste sõnadena ILM Incoming Label Map Protokoll sissetuleva sildi vastandamiseks edastustabelites olevate, sildiga seotud, sissekannetega IP Internet Protocol Internetiprotokoll IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IPX Internetwork Packet Exchange võrkudevaheline paketivahetus ITU-T International Telecommunication Union Telecommunication Standardization Sector Telekommunikatsiooni standardimisega tegelev institutsioon L2 Layer 2 OSI mudeli teine kiht L3 Layer 3 OSI mudeli kolmas kiht L3VPN Layer 3 Virtual Privat Network MPLS-i poolt võimaldatav skaleeritav privaatvõrguteenuste arhitektuur LAN Local Area Network Kohtvõrk LDP Lable Distribution Protocol Sildijaotusprotokoll LFIB Label Forward Information Base Slidi edastustabel LLC Logical Link Control Loogilise lüli reguleerimisekiht LSP Label Switched Path Virtuaalne tee andmeedastuseks MPLS võrgus LSR Label Switching Router MPLS võrgus asuv marsruuter Mb/s Megabitti sekundis MP-BGP Border Gateway Protocol-Multiprotocol Dünaamiline marsruutimisprotokoll MPLS Multiprotocol label switching Hulgiprotokoll - siltkommutatsioon MTU Maximum Transmissioon Unit Suurim edastatav andmemaht NAT Network Address Translation Võrguaadressi ümbernimetamine NAT-PE Network Address Translation Provider Edge Võrgu ääremarsruuter, kus teostatakse võrguaadresside ümbernimetamist

11 NGN Next Generation Networking Uue põlvkonna võrguarhitektuur NHLFE Next Hop Label Forwarding Entry Sissetuleva sildi kohta käiv sissekanne edastustabelites NLRI Network Layer Reachability Information Võrku jõudmise informatsioon BGP marsruutimisprotokollis OPB Optical Packet BackBone Fiiberoptiline pakettvõrgu tuumvõrk OPEX Operational Expenditure Jooksevkulu OSI Open Systems Interconnect Avatud süsteemide sidumise arhitektuur OSPF Open Shortest Path First Marsruutimisprotokoll P router Provider router Tuumikvõrgu sõlm PAT Port Address Translation Pordi numbri ümbermuutmine PE Provider Edge Tuumikvõrgu piiril asuv sõlmmarsruuter, sidumispunkt teiste võrkudega PHP Penultimate Hop Popping Meetod, mis eemaldab MPLS paketilt päise PE võrgusõlmele eelnevas võrgusõlmes PIM Protocol Independent Multicast Multiedastuse marsruutimisprotokollide perekond POP Pont of Presence Võrgupunkt PPP Point to Point Protocol Protokoll andmeedastuse juhtimiseks kanalikihil PVC Permanent Virtual Circuit Permanentne virtuaalühendus ATM võrgus QoS Quality of Service Teenusekvaliteet RAIN Rural Areas broadband Internet Network Riiklik projekt Leedus järgmise generatsiooni võrguarhitektuuri viimiseks maapiirkondadesse RD Route Distiguisher Marsruudi eristaja RFC Request for comments Internetiga seotud standardite koostamise protsess RIB Routing Information Base Marsruutimistabel RIP-2 Routing Information Protocol ver 2 Kaugusvektori marsruutimisprotokoll versioon 2 RSVP - TE Resource Reservation Protocol Traffic Engineering Ressursside reserveerimiprotokoll RT Route Target Marsruutimise lõpp-punkt SHDSL Single-Pair High-speed Digital Subscriber Line Sümmeetriline digitaalne abonendiliin SME Small and Medium Enterprises Väiksed ja keskmise suurusega ettevõtted

12 SVC TCP TTL UDP URL WAN VC VCI WIMAX VLAN VLSM VPI VPN VPN-V4 VRF Switched Virtual Connection Kommuteeritav virtuaalühendus Transmission Control Protocol Ühendusele orienteeritud andmeedastuse protokoll Time to Live IP paketi eluiga tähistav parameeter protokollipäises User Datagram Protocol Ühenduseta andmeedastuse protokoll Uniform Resource Locator Internetiaadress Wide Area Network Laivõrk Virtual Connection Virtuaalne ühendus Virtual Channel Identifier Virtuaalse kanali identifikaator Worldwide Interoperability for Microwave Access Laiaribalise traadita võrgu standard Virtual Local Area Network Virtuaalne kohtvõrk Variable-Length Subnet Masking Tehnika, mis võimaldab ühe võrgu sees kasutada erineva suurusega võrgumaskidega alamvõrke Virtual Path Identifier Virtuaalse tee identifikaator Virtual Private Network Virtuaalne privaatvõrk VPN võrgus kasutatav IPv4 aadress, millele on lisatud marsruudi eristaja (RD) Virtual Routing and Forwarding Virtuaalne marsruuter

13 1. SISSEJUHATUS Telekommunikatsioonimaailm on läbi aegade olnud pidevas kiires arengus ning see areng ei peatu ka täna. Kommunikatsioonitehnoloogia ning selle arenguteed on alati olnud ning üsna tõenäoliselt on ka edaspidi tänase tsiviliseeritud maailma üks olulisimaid, pidevat arendamist vajavaid, tehnoloogiavaldkondi. Kommunikatsioonitehnoloogia esimeseks läbimurdeks peetavast telegraafist, mis leiutati aastal 1838 ning võeti kasutusele pärast Morse koodi leiutamist 1844 aastal [32], oleme jõudnud tänapäeva andmeedastustehnoloogiateni, mille läbilaskevõimest (capacity) ei osatud tol ajal veel unistadagi. Üha kasvavad edastamist vajavad andmemahud ning hinnasurve teenustele nõuavad aga endiselt uuemate tehnoloogiate ning veelgi innovaatilisemate lahenduste kasutuselevõtmist. Suured muudatused telekommunikatsiooni valdkonnas on praegusel ajal toimumas kõikides arenenud riikides, mis tänu pidevalt kasvavale infovahetuse vajadusele avalduvad uue põlvkonna lairibavõrkude väljaehitamises (NGN Next Generation Networking). Samuti tegelevad Eesti sideettevõtjad oma tuumikvõrgus NGN-i arendamisega, kuna see tagab võrgu stabiilsuse, tõrkekindluse ning piisava mahu kõikide klientide ärateenindamiseks. Üle-Eestilist fiiberoptilistel kaablitel dubleerivate ringidena üles ehitatud magistraalvõrku omavad Eestis kaks sideettevõtjat: Elion (põhiliselt maa-alused fiiberoptilised kaablid) ja Televõrgud (kõrgepingeliinidel õhukaablid).[33] Kuna sideettevõtjad tegelevad võrgu arendamisega põhiliselt piirkondades, kus see neile majanduslikult kasulik on, siis jääksid, ainult sideettevõtjate arendustegevusele lootma jäädes, väiksemad maapiirkonnad siinkohal tähelepanuta. Meie igapäevane elu aga sõltub järjest enam infotehnoloogiast ning selleks, et infotehnoloogiliste võimaluste puudumise tõttu elu maapiirkondades välja ei sureks, loodi 11. augustil 2009 aastal Majandus- ja Kommunikatsiooniministeeriumi eestvedamisel Eesti Lairiba Arenduse Sihtasutus, mille eesmärgiks on ellu viia projekt EstWin. Projekti EstWin raames viiakse uue põlvkonna lairibaühendused, mis baseeruvad fiiberoptilistel kaablitel, kõikjale Eesti maapiirkondades. Projekti eesmärgiks on varustada aastaks 2015 kõik Eesti asulad fiiberoptilise kaablivõrguga (98% kõikidest ettevõtetest ning majapidamistest peavad võrgule asuma lähemal kui 1,5 km). Selle eesmärgi

14 saavutamiseks ehitatakse viie aasta jooksul välja üle 6000 km optilisi kaableid ning luuakse üle 1400 võrguühenduskoha.[42] Järgmise generatsiooni võrgu juures peetakse võtmetehnoloogiaks Multiprotocol label switching ut (MPLS) (hulgiprotokoll-siltkommutatsioon).[34] Cisco tegi aastal ettepaneku kaaluda siltide (label) kommuteerimise standardiseerimist. See tehnoloogia arendati Cisco poolt välja, et ühildada omavahel IP ja ATM (Asynchronous Transfer Mode) võrke ning vähem kui kümne aastaga sai MPLS tehnoloogia nime all tuntust kogunud kommuteerimis viis juhtivaks tehnoloogiaks IP põhiste teenuste osutamisel. MPLS võimaldab teenusepakkujal luua ühtse stabiilse võrgu, mis võimaldab pakkuda nii OSI (Open Systems Interconnect) mudeli teise kihi (edaspidi L2) teenused kui ka IPpõhised (OSI mudeli kolmas kiht, edaspidi L3) teenused. Enam kui 250 teenusepakkujat üle maailma on oma võrgus kasutusele võtnud MPLS tehnoloogia, et pakkuda kolmanda kihi (edaspidi L3) VPN (Virtual Private Networks) teenust, vähendada mitmete võrkude haldamisega seotud kulusid ning kasvatada tulusid uute MPLS tehnoloogia baasil pakutavate teenustega.[35] Järgnev töö keskendub keskmise ärikliendi andmesidelahendusele (privaatühendused + ligipääs avalikku võrku) ühe teenusepakkuja tuumikvõrgu võimalusi arvesse võttes. Antud teenusepakkuja tuumikvõrgus toimub NGN võrgu arendamisega seotult üleminek vananevalt ATM tehnoloogialt MPLS tehnoloogiale. Käesolev töö selgitab kliendilahenduse vaatest välja mõningad eelised, mida lõppkliendile ning sideettevõtjale pakub üleminek ATM tehnoloogialt MPLS VPN tehnoloogiale. 1.1.ÜLESANDE PÜSTITUS Antud töö võrdleb ühe Eesti keskmise ärikliendi X vajadustele vastavat ATM tehnoloogial baseeruvat andmesidelahendust (privaatvõrk + internet) ning MPLS tehnoloogial baseeruvat andmesidelahendust. Töö eesmärk on välja selgitada konkreetse kliendi jaoks parim võimalik andmesidelahendus teenusepakkuja tuumikvõrgu võimalusi arvesse võttes. Töös silmas peetud teenusepakkuja tuumikvõrgus on arendatud MPLS tehnoloogiat alates 2006 aastast ning aastaks 2010 on juba suur hulk kliendilahendusi ATM võrgult üle viidud MPLS võrgule.

15 Töö lõppeesmärgiks on uurida, kuidas MPLS VPN tehnoloogia baasil töötavat privaatvõrku omavatele lõppklientidele pakkuda interneti teenust nii, et see oleks kliendi vaatest võimalikult odav ning ettevõtte vaatest võimalikult kergesti hallatav. Siinkohal on silmas peetud eelkõige SME-sid (Small and Medium Enterprises), ehk Eesti mõistes keskmise suurusega äriettevõtteid, kellel puuduvad erilised nõuded tulemüüri reeglistike suhtes ning kellele piisab põhifunktsioonidest - nagu NAT (Network Address Translation), IP suunamine, pordi suunamine. Teenuse sihtgrupist on välja jäetud suurkliendid, kuna eesmärk on, et teenus ise ning selle tarnimine oleksid võimalikult lihtsad et teenus oleks standardiseeritav (suurklientidel on tulemüürireeglistike suhtes enamasti väga erinevad nõudmised ning seetõttu on nende lahendusi tarvis käsitleda individuaalselt).

16 2. UUE PÕLVKONNA LAIRIBAVÕRKUDE ARENDAMISEST MUJAL MAAILMAS $ Paljud arenenud riigid on alustanud juba aastate eest uue põlvkonna lairibavõrkude rajamist. Enamus neist projektidest on algatatud valitsuste eestvedamisel, kuna on aru saadud lairibaühenduste tähtsusest riigi arengule tervikuna. Strateegia ja teostus on riigiti küll erinev, kuid põhieesmärgid on olnud majanduse konkurentsivõime suurendamine ning digitaalse lõhe vähendamine maa- ja linnapiirkondade vahel. Ka on üheks eesmärgiks olnud suurendada konkurentsi telekommunikatsiooni sektoris.[33] Järgnevalt on toodud üksikud näited lairibaühenduse projektidest erinevates riikides: Leedus ehitati riikliku projekti RAIN käigus välja maapiirkondades 3357 km fiiberoptilisi kaableid ning nüüd on teostamisel jätkuprojekt RAIN II, mille käigus ehitatakse lisaks 5100 km fiiberoptilist kaablit. See tagab uue põlvkonna lairibaühenduste kättesaadavuse 98%-le elanikkonnast.[33] Soome on koostanud lairibastrateegia, mille eesmärgiks on uue põlvkonna lairibaühenduste kättesaadavaks tegemine kõikidele elanikele aastaks Soome investeerib sellesse projekti 200 miljonit EUR-i.[33] Rootsi on alustanud projektiga Ambient Sweden" eesmärgiga saada juhtivaks Interneti maaks aastaks Võrku arendades peetakse Rootsis silmas keskmise kasutaja vajadusi, milleks on 100 Mb/s nii püsiühenduste korral kui ka mobiilsete ühenduste korral. See eeldab fiiberoptilise võrgu laiendamist nii tiheasustusega piirkondades kui ka hajaasustusega piirkondades.[43] Austraalia valitsus on otsustanud investeerida 43 miljardit AUD uue põlvkonna lairibavõrkude rajamiseks. Austraalia peaminister Kevin Rudd-i sõnul on see Austraalia ajaloo kõige suurem infrastruktuuri projekt. Ta lisas, et nagu 19 sajandil ehitati raudteed tuleviku jaoks ning 20 sajandil ehitati elektriliine, esindab lairibavõrk tähtsaimat infrastruktuuri 21 sajandil.[33] Singapur on võtnud eesmärgiks, et aastaks 2012 peab optiline võrk jõudma 95% majadesse ning sellel võrgul pakutava teenuse miinimumkiiruseks on 100Mbit/s.

17 Selle sidevõrgu väljaehitamiseks korraldati riigihange ning eraldati üksteisest infrastruktuuriäri, võrguäri ning jaeäri. Singapur investeerib sellesse võrku 750 miljonit Singapuri dollarit.[33] Paljud teenusepakkujad üle maailma töötavad oma infrastruktuuride kallal, mis varasemalt on ehitatud erinevaid spetsiifilisi teenuseid pakkuma (telefon, andmeside, püsiliinid jne). Olulisteks eesmärkideks seejuures on vähendada kulusid ning võtta kasutusele uusi multimeediateenuseid. MPLS tehnoloogia kasutamine teenusepakkujate tuumikvõrgus on seejuures rohkesti populaarsust kogunud. Mõned näited nendest: Reliance Globalcom i ühendused töötavad sisemise MPLS tuumvõrgu peal, mille abil pakutakse klientidele Virtual Privat LAN teenuseid.[39] Reliance Globalcom pakub erinevaid teenuseid rohkem kui 1400-le ettevõttele, 200-le teenusepakkujale ning 1,5 miljonile jaeäri kliendile 50-es erinevas riigis. Raliance Globalcom haldab maailma suurimat merealuste kaablite süsteemi. See km pikk globaalne kaablivõrk kasutab Indias, Kesk-Idas, Aasias, Euroopas ning USA-s asuva 40-ne võtmeturu ühendamiseks MPLS-il baseeruvat IP võrku.[44] Selle stabiilse IP/MPLS võrgu peal pakub Reliance Globalcom klientidele MPLS VPN teenust. Asia-Pacific of Reliance Globalcom i president, Owen Best, on öelnud, et pakkudes ühtselt hallatavat teenust IP/MPLS-i, Etherneti kui ka rahvusvaheliste privaatliinide baasil, on nende klientidel olnud, lisaks kulude kokkuhoiule, võimalus kasutada oma võrgu suuremat funktsionaalsust.[45] Verizon kasutab oma võrgus MPLS tehnoloogiat, et võimaldada oma IP võrgus QoS-i (Quality of Service) ning tagada lisateenuste integreerimise võimalus.[37] Verizon-i laivõrguteenuste lipulaevaks on MPLS võrgul baseeruv virtuaalne privaatvõrk (VPN), mida nimetatakse Verizon Private IP.[46] 2010 aasta mai kuus tunnustas Forrester Research Inc Verizon Business-it Euroopa laivõrgu turu liidri tiitliga. Forrester hindas 58 kriteeriumi alusel 12 Euroopa suurima teenusepakkuja tugevusi ning nõrkusi. Uurimuse jaoks valiti välja Euroopa turul aktiivselt tegutsevad ettevõtted, kes kasutavad oma võrgus põhitehnoloogiana MPLS-i.[47] Verizon Business i võrgu ning kommunikatsiooni asepresident Anthony Recine on öelnud, et me usume, et see tunnustus peegeldab Verizon Business i tugevust ja Euroopas ning ka mujal maailmas asuvate klientide jaoks jätkuvat

18 kvaliteetsete lahenduste tarnimist. Ettevõtted soovivad oma ühisvõrgule turvalist ning lihtsat juurdepääsu ning meie lahendused pakuvad neile seda. Meie eesmärgiks on aidata oma klientidel moderniseerida nende globaalset äritegevust, vähendada kulusid, suurendada äritegevuse efektiivsust ning mis kõige olulisem, toetada nende üha kasvavaid ärivajadusi tänapäevases karmis konkurentsimaailmas. [47] Verizon Businesss pakub MPLS tehnoloogial baseeruvaid IP VPN ning Carrier Ethernet WAN (Wide Area Network) teenuseid üle Euroopa. Verizon i WAN teenuste lipulaevaks peetav Private IP teenus (virtuaalne privaatvõrk) võimaldab klientide erinevates asukohtades asuvatel kontoritel omavahel üle turvalise võrgu efektiivselt suhelda. See teenus on ka aluseks ettevõtete vaheliste äriprotsesside automatiseerimisele e-kaubandus ja jagatud sisevõrgud ning suhtevõrgud (intranet and extranet). MPLS tehnoloogial baseeruv Private IP pakub klientidelee skaleeritavat ning paindlikku võrguühendust.[47] BT (British Telecom) tegi väga tihedalt koostööd Cisco Systems iga, et välja arendada oma globaalne MPLS võrk ning teenused (joonisel 1 on tumehalliga välja toodud riigid, kus on võimalik kasutada BT MPLS teenuseid). MPLS võrku on integreeritud rohkem kui 90 riiki, mis hõlmavad 1100 POP-i (ponts of presence). BT IP-VPN teenus toetab missioonikriitilisi viitetundlikke rakendusi ning on samuti võimeline kandma multimeediaaplikatsioonee ja kõneliiklust.[40 ja 49] Joonis 1. Riigid, kus on võimalik kasutada BT MPLS teenuseid (märgitud tumehalliga) [40]

19 BT Group i peetakse Euroopas üheks juhtivaks andmeside teenuste pakkujaks. Ettevõte on virtuaalseid privaatvõrke (VPN) planeerinud, ehitanud ning hallanud juba 1991 aastast, pakkudes ülemaailmselt oma teenuseid erineva suurusega ettevõtetele ning olles ühtlasi ka pidevalt uute tehnoloogiate arendamise juures. Mõnda aega tagasi pidid erinevates regioonides harukontoreid omavad ettevõtted ehitama mitmeid kalleid andmeside võrgulahendusi, et ühendada ning laiendada oma korporatiivset võrku. Selleks kasutati teenusepakkuja Frame Relay või ATM tuumikvõrgu baasil töötavaid VPN teenuseid, mille puhul tuli luua püsiv virtuaalne ühendus iga asukoha ning võrgu keskseadme vahele, mille ehitamine ning haldamine on kallis ning ajamahukas. Rahvusvaheliste ettevõtete vajaduste rahuldamisele keskendunud BT Global Services tegi tugevalt koostööd Cisco Systems iga, et saada esimeseks rahvusvaheliseks teenusepakkujaks, kes võtab kasutusele Multiprotocol Label Switching (MPLS) tehnoloogia lihtsustamaks üle IP (Internet Protocol) võrkude toimivat VPN teenust.[48] 1999 aastal tuli BT välja MPLS põhise IP VPN teenusega, mida nimetatakse BT MPLS-iks, et aidata klientidel kiirelt ning soodsalt luua globaalseid andmeside võrkusid.[48] MPLS teenuste populaarsus kavas märgatavalt pärast seda kui mõned maailma suurimad ning tuntuimad ettevõtted otsustasid seda kasutama hakata. Teenus tunnustati Network Comuting Magazine i poolt parimaks rahvusvaheliseks IP teenuseks ning pälvis seetõttu ka prestiiže auhinna Well-Connected Award.[48] Telecom Italia on oma võrgus arendanud IP MPLS BackBone OPB (Optical Packet BackBone) alates aastast, et koondada ning transportida edasimüüjate ning ülejäänud klientide erinevat sorti liiklust (hääl, andmed ja multimeedia).[41] Euroopa ühe suurima telekommunikatsiooniteenuste osutajana, pakub Telecom Italia Group suures valikus erinevaid telekommunikatsiooniteenuseid alates lauatelefonist, mobiiltelefonist kuni erinevate andmeside lahendusteni. Telecom Italia l on ligi 7,7 miljonit lairibaühendust Itaalias ning 2,5 miljonit lairibaühendust Saksamaal ning Hollandis.[28] Koostöös Juniper Networks iga on Telekom Italia MPLS VPN võrku omavatele äriklientidele välja töötanud tsentraalsed võrgulahendused. Üheks selliseks lahenduseks on tsentraalne internet. Lahenduse disainimise aluseks olid klientide

20 ; vajadused: Paljudel äriklientidel on tarvis luua oma VPN võrgust turvaline ligipääs internetti, suurte ettevõtete jaoks on lisaks turvalisusele oluline ka lahenduse skaleeritavus ning väiksemad ettevõtted vajavad odavat ja lihtsasti kasutatavat lahendust.[28] Kõikide klientide vajadusi ning MPLS võrgu võimalusi arvesse võttes jõuti jagatud ressursil baseeruva tsentraalse interneti lahenduseni. Lahenduse tuumaks on Juniper Netscreen 5200, mis füüsiliselt asub PE (provider edge) ning IGW (Internet Gateway) vahel. Täidab see seade kuute funktsionaalsust: NAT (1:1, N:M)/PAT (Network Address Translation/ Port Address Translation), tulemüür, alamvõrgul baseeruv filtreerimine üle MPLS VPN-i, URL (Uniform Resource Locator) filtreerimine, antiviirus.[28]

21 3. ÄRIKLIENDI ANDMESIDELAHENDUS ATM TEHNOLOOGIA BAASIL. Käesolevas peatükis antakse ülevaade töö aluseks olevast ärikliendist X ning tema vajadustest. Tutvustatakse kliendi vajadustele vastavad ATM tehnoloogial baseeruvat andmesidelahendust ning käsitletakse selle lahenduse kitsaskohti. 3.1.ÜLEVAADE KLIENDIST JA TEMA VAJADUSTEST Kliendi peakontor asub Tallinnas ning tal on lisaks 20 üle Eesti paiknevat harukontorit, mis on tarvis ühendada omavahel ühte privaatsesse laivõrku WAN (Wide Area Network). Peakontoris asuvad kliendil serverid, mille baasil töötavad äritegevuseks vajalikud rakendused, seega on oluline, et nendele serveritele pääseks ligi kõikidest harukontoritest. Samuti on antud kliendi jaoks oluline ligipääs internetti nii harukontoritest kui ka peakontorist. Harukontoritesse ehitatavate andmesideühenduste ribalaiuse vajadus on otseselt seotud võrguühendust vajavate töökohtade arvuga vastavas kontoris. Järgnevas tabelis 1 on toodud töökohtade arv kontoris ning vajatav ribalaius. Kuna kliendi jaoks on oluline nii alla- kui üleslüli kiirus, on tabelis 1 tegemist sümmeetriliste kiirustega. Tabelis välja toodud kontorite tüübid (Kontor 1, Kontori 2, Kontor 3) on lahti seletatud antud paragrahvi keskosas. Tabel 1. Kliendi harukontorite loetelu ja vajalikud ribalaiused Nr Kontori asukoht H - Harukontor Töökohtade arv kontoris Vajalik ribalaius Kontori tüüp 1 Tallinn, H1 4 4/4 Mbps Kontor 2 2 Tallinn, H2 4 4/4 Mbps Kontor 3 3 Tallinn, H3 4 4/4 Mbps Kontor 2 4 Tartu, H1 4 4/4 Mbps Kontor 2 5 Tartu, H2 4 4/4 Mbps Kontor 3 6 Pärnu 2 2/2 Mbps Kontor 1 7 Paide 2 2/2 Mbps Kontor 1 8 Põlva 1 1/1 Mbps Kontor 4

22 9 Võru 2 2/2 Mbps Kontor 1 10 Viljandi 2 2/2 Mbps Kontor 1 11 Narva 2 2/2 Mbps Kontor 1 12 Valga 2 2/2 Mbps Kontor 1 13 Kuressaare 2 2/2 Mbps Kontor 1 14 Kärdla 1 1/1 Mbps Kontor 4 15 Haapsalu 2 2/2 Mbps Kontor 1 16 Sillamäe, 1 1/1 Mbps Kontor 4 17 Rakvere, 2 2/2 Mbps Kontor 1 18 Jõgeva, 2 2/2 Mbps Kontor 1 19 Rapla, 2 2/2 Mbps Kontor 1 20 Keila, 2 2/2 Mbps Kontor 1 Kliendi peakontor asub Tallinnas. Et probleemideta ära teenindada kõik 20 harukontorit, peaks peakontori WAN lingi ribalaius olema 50 Mb/s. Lisaks peab olema peakontorisse ehitatud ka eraldiseisev interneti link, mille kaudu saavad välisveebi külastada, lisaks peakontorile, ka kõik harukontorid. Arvestusega, et peakontoris on 10 aktiivset võrguühendust vajavat töökohta ning seda, et põhitöö toimub siiski privaatvõrgu piires, võiks peakontori interneti lingi ribalaius olla 30 Mb/s (tegu sümmeetrilise kiirusega). kogu liiklus ettevõtte sisevõrgu ja interneti vahel käib läbi tulemüüri. Vastavalt tehnoloogilisele võimalusele ning kliendi vajadustele oleks paar aastat tagasi ehitatud eelpool kirjeldatud kliendile ATM võrgul baseeruv andmeside erilahendus, mille võrgustruktuuri näete joonisel 2. Harukontorites on kohtvõrkude ühendamiseks kasutusel Cisco 800 seeria marsruuterid ning peakontoris Cisco 3725 marsruuter. Vastavalt kliendi vajadusele (tabel 1) on joonisel näha 4 tüüpi harukontoreid: 1) Kontor 1: Andmeside ühenduse ribalaius 2/2 Mb/s SHDSL (Single-Pair Highspeed Digital Subscriber Line) tehnoloogia baasil. Viimase kilomeetrina on kasutusel üks vaskkaabli paar, lisaks 1 SHDSL port teenusepakkuja jaamas ning Cisco 878 SHDSL marsruuter kliendi kontoris. 2) Kontor 2: Andmeside ühenduse ribalaius 4/4 Mb/s. Ühendus on ehitatud teenusepakkuja ärimaja kommutaatorist (kommutaator, mis asub kliendi

23 kontoriga samas hoones) kliendini cat 5 kaabli abil. Kliendi kontoris asub Cisco 881 ETH marsruuter. 3) Kontor 3: Andmeside ühenduse ribalaius 4/4 Mb/s, SHDSL tehnoloogia baasil. Viimase kilomeetrina on kasutusel kaks vaskkaabli paari, lisaks 2 SHDSL porti teenusepakkuja jaamas ning Cisco 878 SHDSL marsruuter kliendi kontoris. 4) Kontor 4: Andmeside ühenduse ribalaius 1/1 Mb/s SHDSL tehnoloogia baasil. Viimase kilomeetrina on kasutusel üks vaskkaabli paar, lisaks 1 SHDSL port teenusepakkuja jaamas ning Cisco 878 SHDSL marsruuter kliendi kontoris. Peakontorisse aga paigaldatakse Cisco 3725 marsruuter koos ATM mooduliga. Teenusepakkuja sõlmest kliendini ehitatakse ühendus üle kahe fiiberoptilise kiu. Samuti ehitataks peakontorisse ka eraldi välja interneti erilahendus koos tulemüüriga (Netscreen SSG5). Kuna interneti ribalaiuse vajadus on 30 Mb/s, on ainuke võimalus sellist kiirust kliendile tagada üle fiiberoptilise kaabli. Seega on ka interneti erilahenduse jaoks planeeritud teenusepakkuja sõlme ning kliendi peakontori vahele üks FOC (Fibre Optic Cable) kiud, kasutades etherneti konverteerimiseks üle optika meedia muundureid. Seesuguse lahenduse korral on teenusepakkuja tuumvõrk nö läbipaistev. Kõikidest harukontoritest on konfigureeritud peakontorisse punkt-punkt ühendused (ATM võrgus PVC - Permanent Virtual Circuit), millede otspunktides on omad IP aadressid ning nende vahel asub läbipaistev virtuaalne kanal. Kogu laivõrgus toimuv liiklus (internet, harukontorite omavaheline suhtlus, suhtlus serveritega) käib läbi peakontoris asuva seadme, mis teeb sellest seadmest ühtlasi kogu laivõrgu keskseadme. Seega on väga oluline antud seadme töökorras olek. Kui laivõrgu keskseadmega midagi peaks juhtuma, siis jäävad andmeside- ning internetiühenduseta ka kõik harukontorid.

24 Media Converter _ 5VDC. 1A + UP L INK LINK PWR LINK SD RX T X Joonis 2. Kliendi X Andmesidelahendus ATM tehnoloogia baasil 3.2.ATM TEHNOLOOGIAL BASEERUVA LAHENDUSE KITSASKOHAD Kliendi vaatest 1) Kallid seadmed peakontoris + kallis ühendus. Ainuüksi kliendi lõppseade koos lisade ning tarkvaraga maksab ~ kr. 2) Antud lahenduse puhul on peakontoris asuv laivõrgu keskseade ilmselgeks pudelikaelaks. Kui keskseade peaks lakkama töötamast (seadmerikke või voolukatkestuse tõttu) või ühendus teenusepakkuja sõlme ning kliendi lõppseadme vahel peaks kaduma (katkise kaabli tõttu), siis jäävad ka kõik harukontorid ilma andmesideühendusteta (lisaks kohtvõrkude ühenduse katkemisele katkeks harukontorites ka interneti kasutusvõimalus), kuna kogu laivõrgu liiklust korraldab ja kontrollib just seesama peakontoris asuv laivõrgu keskseade.

25 3) Samuti oleks kliendi jaoks peakontori ümberkolimine üks kulukas ning üsna ebameeldiv tegevus, kuna kolimise hetkel toimub ühenduse katkestus ka kõikide harukontorite töös (seetõttu teostatakse sellelaadseid töid öösiti, kuna siis kannatab kliendi äri kõige vähem). Kui pikk see katkestus on, sõltub sellest, kui palju klient on valmis teenusepakkujale antud töö teostamise eest maksma. Kliendi jaoks kindlasti valutum, aga kallim variant oleks see, kui uude asukohta paigaldataks uus CPE (Customer Premises Equipment), mis on samaväärne vanas peakontoris asuvaga. Ning kui ühendus on füüsiliselt valmis ehitatud, siis kokkulepitud ajal tõstetaks uude seadmesse ümber ka kõik harukontorid (harukontorite PVC-d). Sellisel juhul toimuksid harukontorite töös küll katkestused, aga need oleksid minimaalsed ning ei tekiks olukorda, kus terve kliendi laivõrk korraga ei tööta. See variant on kliendi jaoks kallim, kuna nii võimsaid ning kalleid seadmeid nagu meie kliendil X peakontoris on, ei ole teenusepakkujal laos seismas ning neid tellitakse vastavalt vajadusele (iga kliendi jaoks personaalselt). Odavam variant oleks füüsiliselt kolida peakontoris olemasolev seade uuele aadressile. See aga tähendaks, et kliendi laivõrk on tervenisti maas vähemalt paar tundi (olenevalt sellest kui kaugel uus peakontor asub vanast ning kas uuel aadressil on liin korralikult ette valmistatud). 4) Kallis interneti erilahendus peakontoris: Peakontorisse paigaldatav eraldi seade, mis täidab tulemüüri rolli, lisaks igakuine rendi tasu fiiberoptilise kaablikiu ning meediakonverterite kasutamise eest ja samuti port ATM kommutaatoris ei ole odav Ettevõtte vaatest 1) Uute kontorite juurde lisamine on haldamise vaatest suurem töö. Uue kontori juurde lisamiseks kliendi laivõrku, on tarvis teha palju käsitsi tööd (konfigureerida PVC (permanent virtual circuit) harukontorist peakontorisse). Samuti nõuaks palju käsitsi tööd peakontori ümberkolimine, mida tuleb keskmiste ja suuremate äriklientide puhul üsna sageli ette. Antud juhul tähendaks see, lisaks seadmete füüsilisele ümbertõstmisele, ka kõigi 20 harukontori PVC käsitsi ümberkonfigureerimist.

26 $ Tausta selgituseks: ATM võrgus identifitseeritakse ühendusi VPI (virtual path identifier) ja VCI (virtual channel identifier) kombinatsioonina. Ühendusele omistatud VPI ja VCI kombinatsiooni nimetatakse CI-ks (connection identifier). CI = {VPI, VCI}. Virtuaalne ühendus kahe kasutaja vahel koosneb traktist, mis läbib mitmeid erinevaid ATM kommutaatoreid. Iga sellel traktil asuv point-to-point ühendus on märgistatud erineva VPI/VCI-ga. See tähendab, et iga VPI/VCI on lokaalse tähendusega ja transleeritakse erinevaks VPI/VCI-ks igas kommutaatoris, mida andmepakett läbib. Seda operatsiooni vaadeldakse kui label swapping kuna ühenduse identifikaatorit tuntakse ka nime all label. Label swapping osaleb ATM kommutaatori kommutatsioonitabelis toimuvas otsingus. Sissetuleva andmepaketi VPI/VCI indekseeritakse kommutatsioonitabelisse ning omistatakse paketile uus VPI/VCI, mida see kannab oma päises väljuval lingil. Samal ajal omistatakse paketile ka väljuva pordi number, et kommutaator teaks, millisesse väljuvasse porti antud andmepakett edastada. Kommutaatorites olevaid tabeleid sisenevate ning väljuvate VPI/VCI kombinatsioonide ning vastavate portide numbritega tuleb administraatoril täita käsitsi. Näide label swapping ust on toodud joonisel 3. Joonis 3. Label swapping [8] Eelnevalt toodu oli näide sellest, kuidas ATM võrgus käib adresseerimine. Reaalselt töötab aga üle Eestilist lahendust pakkuva teenusepakkuja tuumvõrk natuke teisiti. Vaadates minu töö aluseks olnud klienti X, siis temalgi on

27 kontorid üle Eesti. Kui administraator peaks näiteks Võrust Tallinnasse konfigureerima PVC käsitsi läbi kõikide tuumikvõrgus asuvate kommutaatorite, kuluks tal ühe ühenduse tööle saamiseks terve päev. Seetõttu kasutatakse nende ühenduste loomiseks nii nimetatud soft PVC-d, mis oma loomuselt on kahe ATM võrgus kasutatava ühenduse tüübi PVC ning SVC (switched virtual connection) ristand. Seega soft PVC vähendab tunduvalt administraatorite töövaeva. Sellisel juhul tuleb ühenduse VPI/VCI kombinatsioon käsitsi määrata kuni esimese ATM kommutaatorini, seda siis LAN-to-LAN ühenduse mõlemas otsas. Ehk ühe ühenduse puhul tuleks seda Kliendi X lahenduse puhul teha järgmistes seadmetes: kliendi lõppseade -> teenusepakkuja DSLAM (Digital Subscriber Line Access Multiplexer) -> ATM kommutaator -> vahepeale jääb nö ATM pilv, kus on kasutusel SVC -> ATM kommutaator -> kliendi lõppseade. Seega kindlasti ei ole selline lahendus haldamise mõttes kõige tüütum, aga uuemad tehnoloogiad on selle veelgi mugavamaks teinud nii teenusepakkuja kui ka kliendi vaatest lähtudes. Joonis 4. PVC ning SVC kasutus ATM võrgus [4]

28 2) Lisaks tuleks kindlasti ümber kolida ka peakontoris asuv Interneti ühendus. Selle kitsaskoha võiks tegelikult paralleelselt paigutada ka kliendi vaate alla, kuna seesugune kolimine läheks kliendi jaoks maksma päris palju, sest nõuab üsna palju erinevate spetsialistide töötunde: seadme füüsiline kolimine ühelt aadressilt teisele, uuel aadressil uue liini ettevalmistamine (konfiguratsioon + krosseeringud ning vajadusel uue kaabli ehitus). Telekommunikatsiooniteenust pakkuva ettevõtte töötajate jaoks aga tähendaks see tõenäoliselt taaskord öiseid töötunde. 3) Lisaks sellele, et uue kontori juurde lisamine nõuab palju käsitsi tööd, kehtivad ka tehnoloogilised piirangud. Et uut kontorit lahendusse juurde lisada, peab konkreetsel aadressil olema kindlasti ATM tehnoloogia kasutusvõimalus, kuna soft PVC-d saab konfigureerida ainult ATM kommutaatorites.[4] On võimalik ühildada näiteks GE (Gigabit Ethernet) võrku ATM võrguga, aga see on taaskord üsna töömahukas (käsitsi töö) ettevõtmine, kuna nendes võrkudes on kasutusel erinevad ühenduse tüübid (joonis 5): ATM võrgus PVC, GE võrgus VLAN (Virtual LAN). Sellisel juhul tuleb ühes võrguseadmes teostada ATM VPI ning VCI konverteerimine VLANi sisemisteks ja välimisteks siltideks ning vastupidi.[9] Joonis 5. ATM ning GE võrgu liitmine

29 4) Rikete korral on vea lokaliseerimine üsna keeruline. Kuna teenusepakkuja tuumvõrk on antud lahenduse korral nö läbipaistev, mis piltlikult öeldes tähendab seda, et harukontori ja peakontori vahele on konfigureeritud üks L2 toru, mille mõlemas otsas asuvad marsruuterid tegelevad IP ehk L3 tasandiga, siis on vea asukoha tuvastamine (missuguses võrguseadmes või võrgu osas viga tekkis) üsna keeruline ning nõuab kindlasti kogenumate administraatorite abi. Lihtne oleks pingida IP aadresse, aga kuna antud juhul on kahe IP aadressi vahel palju erinevaid seadmeid (joonis 6), siis ei annaks see soovitud tulemust. ATM võrgus pannakse IP aadressid vastavusse ATM aadressidega ning paketi edastus tuumikvõrgus toimub ATM aadresside (VPI/VCI) alusel. Selleks, et vea asukoht tuvastada, tuleks võrguseadmetesse sisse logida ning uurida portide veateateid, mis võtab paraku rohkem aega ning nõuab rikke asukohta tuvastavalt administraatorilt suuremaid teadmisi. Joonis 6. IP protokolli edastus üle ATM võrgu [6] 5) Üks kitsaskoht on kindlast ka ATM paketi (raku) päise liiasus (overhead). ATM infoühikuteks on fikseeritud suurusega rakud, mis koosnevad 53 Baidist. Esimesed 5 Baiti sisaldavad päise informatsiooni nagu näiteks ühenduse identifikaatorit. Ülejäänud 48 Baiti sisaldavad aga kasulikku informatsiooni (joonisel 7). Seega ligi 10% kogu paketi suurusest moodustab paketi päis. Praegusel ajal on ATM põhiliselt kasutusel TCP/IP pakettide transportimiseks. Suuremad TCP/IP paketid tükeldatakse väiksemateks ATM rakkudeks, mis suurendab veelgi nö mittekasuliku informatsiooni liiasust (overhead). Kogu liiasus ATM tuumikvõrgus on tüüpiliselt 15% kuni 25%. Näiteks 155 Mb/s ühenduse korral võib efektiivne läbilaskevõime langeda 116 Mb/s-ni. See tähendab 39 Mb/s kadu.[7] ATM tehnoloogia arenduses viisid ITU-T (International Telecommunication Union Telecommunication Standardization Sector) otsuseni kasutada sellist väiksemahulist fikseeritud suurusega paketti

30 ; viidete suhtes tundlike rakenduste nagu video ning kõne transportimine.[8] Sellise suurusega paketi uuestisaatmine, võrgus tekkinud häire tõttu ebaõnnestunud edastuse korral, ei tekita väiksemate kiiruste juures märkimisväärset viidet. Kuna tänaseks on andmesideühenduste kiirused kasvanud tunduvalt võrreldes paari aasta taguse ajaga, siis ei anna sellise väiksemahulise paketi kasutamine enam video ning kõne edastamisel lisaväärtust vaid pigem pärsib andmesidekanali efektiivset kasutust. Joonis 7. ATM rakk [2]

31 4. ÜLEVAADE MPLS TEHNOLOOGIAST Käesolevas peatükis antakse ülevaade MPLS tehnoloogiast ning L3VPN (MPLS VPN) tehnoloogiast, et aidata lugejal mõista peatükkides 5-7 väljapakutud andmesidelahenduste võrgutopoloogiat. Järgnev peatükk põhineb allikatel [8], [13],[17], [23], [50] ja [51]. 4.1.MULTI-PROTOCOL LABEL SWITCHING (MPLS) ARHITEKTUUR MPLS on standardiseeritud IETF-i (Internet Engineering Task Force) poolt. MPLS võimaldab üleminekut eelmises peatükis tutvustatud, ühendusele orienteeritud, struktuurilt vastupidisele, ühendusevabale, IP võrgule. MPLS ei kasuta CPU (Central Processing Unit) põhisest tabeli otsingut, mille käigus toimub IP paketi edastuseks vajaliku järgmise hüppe määramine. Seda võib kasutada ka QoS-i juurutamiseks IP võrgus. Huvitav on tõdeda, et alates sissejuhatusest sildi kommutatsioonile (label switching) ning pärast MPLSi, arendati välja mõned tõhusad CPU põhised algoritmid, et teostada edastustabelites otsinguid. Siiski ei vähenenud seetõttu MPLSi tähtsus, kuna seda vaadeldi kui lahendust QoS-i juurutamiseks IP võrgus. Töökindlaks siltide (label) väljajagamiseks võib MPLS-is kasutada teatud hulka protseduure. MPLS ei nõua ühe kindla siltide (label) jagamise protseduuri kasutamist. Selles valguses on välja pakutud erinevaid skeeme siltide (label) jagamiseks, millest aga kõige populaarsemad on lable distribution protocol (LDP) ja resource reservation protocol traffic engineering (RSVP - TE). Antud peatükis kirjeldatakse MPLS arhitektuuri põhiomadusi. Käsitletakse põgusalt siltide (label) väljajagamise protokolli LDP-d ning MPLS VPN (L3VPN) tööpõhimõtet. Enne MPLS arhitektuuri tutvustamist aga käsitletakse IP võrgu põhikontseptsiooni. 4.2.INTERNET PROTOCOL (IP) IP on osa internetis kasutatavast TCP/IP (Transmission Control Protocol/Internet Protocol ) komplektist. TCP vastab OSI mudeli transpordi kihile (layer 4) ning IP vastab OSI mudeli võrgu kihile (L3).

32 IP pakub pakettkommutatsiooni kasutades ühendusevaba teenust. IP host saab, vastupidiselt farme relay ja ATM võrkudele, edastada adressaadile pakette ilma eelnevalt ühendust loomata. IP paketid marsruuditakse läbi IP võrgu üksteisest sõltumatult ning teoorias on võimalik, et nad jõuavad sihtkohani erinevaid teid kasutades. Praktikas aga kasutab IP võrk marsruutimise tabeleid, mis jäävad mõne aja vältel muutumatuteks. Selles valguses liiguvad IP paketid saatjast vastuvõtjani tüüpiliselt ühte teed mööda. Neid marsruutimise tabeleid uuendatakse perioodiliselt võttes arvesse ülekoormatud linke ning marsruuterite ning linkide riisvaralisi häireid. IP ei garanteeri pakettide kohalejõudmist. Kui alusvõrk hülgab mõne paketi ei ole IP sellest teadlik. Samuti nagu ATM võrgus, ei kontrolli IP paketi kasuliku info osa vigasust, kontrollitakse ainult päist. Kui IP avastab, et paketi päis on vigane, siis ta hülgab selle paketi. Kadunud või vigased andmed parandatakse vajadusel adressaadi kõrgema kihi protokolli poolt (näiteks TCP poolt). 4.3.IP PÄIS IP pakett koosneb päisest ning kasulikust infost (payload). IP päis on näidatud joonisel nr 8 ning see koosneb 20st Baidist fikseeritud osast ning muutuvast osast, millel on varieeruv pikkus. IP päises on järgmised väljad: Version: 4 bitine väli, mida kasutatakse protokolli versiooni määramiseks, Internet Header Lenght (IHL): see on 4 bitine väli, mis annab päise pikkuse 32- bitiste sõnadena. Minimaalne päise pikkus on viis 32-bitist sõna (20 Baiti), Type of service: See 8-bitine väli näitab kas saatja soovib paketti edastada mööda minimaalse viitega teed või mööda suurima läbilaskevõimega teed, Total length: 16-bitine väli näitab kogu paketi pikkuse (päis + kasulik info). Vaikimisi on määratud maksimaalseks pikkuseks 65,535 Baiti, Identification: 16-bitine väli, mida kasutatakse vastuvõtja juures, et tuvastada missuguse paketi juurde antud fragment kuulub. Ühte paketti kuuluvatel fragmentidel on sellel väljal sama väärtus, Flags: See on 3-bitine väli, aga kasutatakse ainult kahte bitti more fragments ja don t fragments. Kõikidel fragmentidel, v.a viimasel fragmendil, on more fragments bitt, See informatsioon võimaldab vastuvõtjal teada saada millal kõik

33 fragmendid on kohale toimetatud. Don t fragment bitt on kasutusel tükeldamise keelamiseks, Joonis 8. IPv4 päis [8] Fragment ofset: See 13-bitine väli sisaldab nihet, mis osutab sellele, kuhu see fragment originaalpaketis kuulub, Time to live (TTL): See 8-bitine väli näitab ära hüpetes, kui kaua on paketil võrgus lubatud eksisteerida. Maksimaalne eluiga on 255 hüpet. Iga marsruuter, mida pakett läbib, peab vähendama selle välja väärtust ühe hüppe võrra või mitme hüppe võrra, vastavalt sellele, kaua pakett kuskil seadmes järjekorras seisab. Kui TTL väli saab võrdseks nulliga, heidetakse antud pakett kõrvale, Protocol: See 8-bitine väli määrab ära järgmise tasandi protokolli (näiteks TCP või UDP), millele pakett saadetakse, Header checksum: 16-bitine väli, mida kasutatakse kindlaks tegemaks, kas IP päis on korralikult pärale jõudnud. Vastuvõtja host kalkuleerib kontrollsumma ja kui tulemus on 0, siis on päis korrektselt pärale jõudnud. Vastupidisel juhul on päis vigane ning pakett jäetakse kõrvale, Source address: 32-bitine väli, mis on varustatud saatja võrgu ja hosti numbriga, Destination address: 32-bitine väli, mis on varustatud vastuvõtja võrgu ja hosti numbriga, Options: Varieeruva pikkusega väli, mida kasutatakse kasutaja poolt küsitud valikute kodeerimiseks (näiteks turvalisus, allika marsruutimine, teekonna salvestamine), Paddyng: varieeruva pikkusega väli, mida kasutatakse selleks, et paketi päise pikkus oleks täisarv korda 32 bitti.

34 4.4. CIDR (CLASSLESS INTER-DOMAIN ROUTING) Nagu eelpool juba näha võis on IP aadresside pikkuseks 32 bitti. IP aadress on jagatud kaheks osaks: võrk ja sufiks. Võrgu osa identifitseerib füüsilise võrgu, mille külge host arvuti on ühendatud. Sufiks identifitseerib arvuti enda. Ajalooliselt olid IP aadressid jagatud klassidesse, mis fikseerisid ära kogu aadressi võrgu osa ning sufiksi osa pikkused. Täpsemalt on sellest kirjutatud lisas 1. Tänapäeval on kasutusel muutuva pikkusega adresseerimine CIDR, et IP aadresside kasutamist efektiivsemaks muuta. CDIR on IP aadresside jagamise ning IP pakettide marsruutimise abivahend, mis võimaldab kõrvale jätta IP aadresside klassid ning hoiduda seeläbi IP aadresside raiskavast kasutamisest. Selle meetodi eesmärk oli välja vahetada Internetis eelnevalt kasutusel olnud klassipõhine võrgu struktuur, et aeglustada interneti võrgus asuvates marsruuterites marsruutimistabelite kasvu ning et IPv4 aadresside kasutamist efektiivsemaks muuta. CIDR baseerub VLSM-il (variable-length subnet masking), mis võimaldab jagada võrke erineva suurusega võrgumaskidega alamvõrkudeks. See tagab alamvõrkude efektiivse kasutamise ning väldib IP aadresside raiskamist. Alamvõrkude jaotamist VLSM tehnikaga võiks kujutada tordi lõikamisena, kus vaadeldavat tükki saab ainult võrdseteks tükkideks lõigata. Kui vaadelda 128-st IP aadressist koosnevat võrku, siis selle saab jagada näiteks kaheks 64 IP aadressiga alamvõrguks, mis võivad omakorda saada jagatud kaheks 32 IP aadressist koosnevaks alamvõrguks jne, kuni on saadud sellise suurusega alamvõrgud, mida parasjagu tarvis oli (joonis 9).

35 Joonis 9. Alamvõrkudeks jaotamine IP omistab marsruuteritele mitmeid IP aadresse, kuna marsruuter on ühendatud mitme võrgu külge. Marsruuteril on iga võrgu, mille külge ta ühendatud on, jaoks üks IP aadress Alamvõrkude jaotamine (Subnetting) Eelnevalt kirjeldatud IP aadressi struktuur on kaheastmelise hierarhiaga. Esimene aste on võrgu aadress ja teine aste on hosti aadress, mida kantakse edasi sufiksis. Paljudel juhtudel ei piisa aga kaheastmelisest adresseerimisest. Näiteks kui me vaatame ühte organisatsiooni B klassi aadressiga, siis on kõik hostid organiseeritud ühte gruppi, mida kirjeldatakse võrgu aadressiga. Siiski grupeeritakse organisatsiooni sisesed hostid tavaliselt erinevate LANide (Local Area Connection) kujul. Et LANe omavahel eristada jagatakse IP aadressi sufiks alamvõrgu (subnet) osaks ja hosti osaks. Igale LAN-ile omistatakse alamvõrguaadress, mida kantakse aadressi alamvõrgu osas ja igale hostile omistatakse aadress, mida kantakse hosti osas. Tegeliku sufiksi jagamise nendeks kaheks alamväljaks dikteerib subnet mask (alamvõrgu mask). Seega jagunevad IP aadressi bitid alamvõrgustamise korral kahe osa asemel kolme ossa: võrgu osa, alamvõrgu osa ja hosti osa. Alamvõrgustamise korral võetakse alamvõrgu osasse jäävad bitid hosti osast. Seda nimetatakse laenamiseks. Mida rohkem bitte laenatakse, seda rohkem alamvõrke saab teha (2 <laenatud bitte> ) ja seda väiksemaks alamvõrgud muutuvad. Alamvõrgustamine toimub ainult antud võrgu siseselt. Väljaspool antud võrku paistab see ikka ühe suure võrguna. Seda tehnikat nimetatakse alamvõrkudeks jaotamiseks (subnetting).

36 $ 4.5.MPLS ARHITEKTUUR MPLS on IETF-i standard, mis baseerub Cisco siltkommutatsioonil. Esialgne kavatsus oli seda kasutada üheskoos erinevate võrguprotokollidega nagu IPv4, IPv6, IPX (Internetwork Packet Exchange) ja AppleTalk. Praeguseks hetkeks on MPLS arendatud ainult IP võrkude jaoks, mis teeb selle nime üldisemaks kui ta reaalselt on. Mõistmaks MPLSi põhikontseptsiooni vaadatakse kõigepealt, kuidas töötab IP marsruuter. IP marsruuter tegeleb nii juhtimis- kui ka edastuse komponentidega (control and forwarding). Juhtimiskomponent (control component) koosneb marsruutimiseprotokollidest nagu open shortest path first (OSPF), border gateway protocol (BGP),j protocol independent multicast (PIM), enhanced interior gateway routing protocol (EIGRP) ja Internal BGP (IBGP) mida kasutatakse marsruutide loomiseks ning marsruutimisinfo vahetamiseks marsruuterite vahel. Seda informatsiooni kasutatakse edastuseks vajalike marsruutimistabelite loomiseks, nimetades seda forwarding information base ks (FIB). Edastuskomponent (forwarding component) koosneb protokollidest, mida marsruuter kasutab IP paketi edastuseks vajalike otsuste tegemiseks. Näiteks unicast edastusel kasutab marsruuter adressaadi IP aadressi, et leida vajalikku sissekannet FIB-ist, kasutades selleks pikima ühtimise (longest match) algoritmi. Tabelis toimunud otsingu tulemusena saadakse teada liidese number, mis ühendab marsruuterit IP paketi jaoks järgmise hüppe marsruuteriga. Marsruuter edastab IP paketi selle prefiksi alusel. Antud marsruuteris nimetatakse aadresse, millel on sama prefiks, forwarding equivalent class (FEC). Ühte FEC-i kuuluvate IP pakettide jaoks on sama väljundliides. MPLSis omistatakse iga FEC-i jaoks erinev silt (label). Seda silti kasutatakse IP paketi väljundliidese määramiseks ilma et peaks vaatama selle aadressi FIB-i. Silt (label) on fikseeritud suurusega lühike identifikaator, millel on lokaalne tähtsus. See tähendab, et üks silt kehtib ainult kahte marsruuterit ühendava ühe hüppe jooksul. Silt (label) on sarnase funktsionaalsusega ATM võrgus kasutatava VPI/VCI kombinatsiooniga. IPv6 puhul võib sildi lisada voo (flow) sildi välja. IPv4 puhul aga ei ole IP paketi päises ruumi sellise sildi lisamiseks. Kui IP võrk töötab ATM võrgu peal, siis lisatakse silt (label) ATM raku (cell) VPI/VCI välja. Kui üle frame relay, lisatakse silt (label) DLCI (Data Link Connection Identifier) väljale. Etherneti võrgus, token ring, ja punkt-punkt

37 ühenduste puhul, mis töötavad link layer protokollil (näiteks PPP - Point to Point Protocol), kapseldatakse ja lisatakse silt (label) LLC (Logical Link Control) päise ja IP päise vahele (joonis 10). Sildi kapsli esimene väli on 20-bitine väli, mida kasutatakse sildi edastamiseks. Teine väli on 3-bitine väli, mida kasutatakse eksperimentaalsetel eesmärkidel. See võib kanda näiteks class-of-service (CoS) tunnust, mida võib kasutada määramaks järjekorda, mille alused IP pakette liidese kaudu edastatakse. S välja kasutatakse koos sildi (label) väljaga, mille olemusest kirjeldatakse paragrahvis 4.7. Viimaseks time-to-live väli (TTL), mis on sarnane IP päise TTL väljaga. Joonis 10. Sildi kapseldus [8] MPLS võrk koosneb LSR (label switching router) marsruuteritest ja MPLS sõlmedest. LSR on IP marsruuter, mille peal töötab MPLS protokoll. See võib määrata silte (label) FECidele, edastada IP pakette nende siltide (label) alusel ja kanda üle harilikke IP edastusotsuseid, viies, prefiksit kasutades, läbi tabeliotsinguid FIBis. MPLS sõlm erineb LSRist sellega, et tal ei pea olema võimet prefiksi alusel IP pakette edastada. Joonis 11. MPLS domeenid, LSRid ja MPLS sõlmed [8]

38 Joonis 12. Näide multi-protocol label switching ust [8] Üksteise kõrval asuvad MPLS sõlmed, mis asuvad ühes ja samas marsruutimis- või administratiivdomeenis moodustavad MPLS domeeni. MPLS domeeni siseselt kommuteeritakse IP pakette nende MPLS sildi alusel. MPLS domeen võib olla ühendatud sõlmega, mis asub väljaspool domeeni ja võib kuuluda mõnda teise MPLS või mitte-mpls IP domeeni (see on domeen, kus marsruuterid kasutavad harilikke prefiksi alusel tehtavaid marsruutimisotsuseid). Nagu näha joonisel 11, koosneb MPLS domeen B viiest marsruuterist, millest kaks on LSRid (LSR 1 ja LSR 2); Ülejäänud kolm võivad olla nii LSRid kui ka MPLS sõlmed. MPLS domeen B on ühendatud MPLS domeeniga A läbi LSR 1 ja läbi LSR 2 on see ühendatud mitte-mpls IP domeeniga C. LSR 1 ja 2 on vaadeldavad kui MPLSi ääresõlmed (edge node). Lihtsuse mõttes eeldame, et kõik sõlmed MPLS domeenis on LSRid. Et näha, kuidas MPLS töötab, vaadeldakse MPLS domeeni, mis koosneb viiest LSRist (A, B, C, D ja E), mis on omavahel ühendatud punkt-punkt (poin-to-point) linkidega, nagu näha joonisel 12. LSRid A ja C on vastavalt ühendatud mitte-mpls IP domeenidega 1 ja 2. Eeldame, et uus hulk hoste prefiksiga <x.0.0.0, y.0.0.0>, kus x on põhivõrgu aadress ja y on mask, on otse ühendatud E-ga. Sellise prefiksiga E ja A vaheline IP pakettide voog käib läbi B ja D. See tähendab, et selle prefiksi jaoks on A-st järgmine hüpe marsruuter B, B-st järgmine hüpe marsruuter D ja D-st järgmine marsruuter E. Samamoodi käivad ka IP pakettide vood C-st E-ni läbi D. See tähendab, et selle prefiksi jaoks on C-st järgmine hüpe marsruuter D ja D-st järgmine hüpe marsruuter E. Liidesed joonisel 12 näitavad kuidas need marsruuterid on

39 omavahel ühendatud. Näiteks A on ühendatud B-ga läbi liidese if0 ja B on ühendatud A, B ja C-ga vastavalt läbi liideste if1, if2 ja if0. Kui LSR identifitseerib FECi, mis on seotud uue prefiksiga <x.0.0.0, y.0.0.0>, valib see sildi vabade siltide (label) vahemikust ja teeb sissekande tabelisse, mida nimetatakse label forward information base (LFIB). See tabel sisaldab informatsiooni sisenevate ja väljuvate siltide (label) kohta, mis on seotud FEC-i ja väljundliidesega ehk sisaldab FEC-i järgmise hüppe marsruuterit. LSR salvestab samuti sildi oma FIBi, FECiga seotud väljale. Selle kindla FEC-iga seotud sissekanne iga LSR-i LFIBis on näidatud tabelis 2 (lihtsuse huvides on kõik lisatud ühte tabelisse). B on valinud sissetulevaks sildiks 62; D on valinud 15 ja E 60. Kuna A ja C on MPLS ääremarsruuterid ja ei oota sildiga varustatud IP pakettide sisenemist, ei ole neil valitud ka sissetulevat silti (label) selle FEC-i tarvis. Ülejäänud informatsioon iga sissekande juures annab FEC-i jaoks järgmise hüppe LSRi ja väljundliidese. Nii, et selle FEC-i jaoks on marsruuterist A järgmine hüpe B ja väljund if0. Tabel 2. FEC sissekanne igas LFIB-is LSR Sisenev silt (Incoming label) Väljuv silt (Outgoing label) Järgmine hüpe (Next hop) Väljundliides (Outgoing interface) & - - )5? B;? $ - )54 B; )54 B 4 - )5+ B + $; - )5+ B; Sissetulev silt (label) on silt, mida LSR ootab kõigilt sissetulevatelt IP pakettidelt, mis kuuluvad FEC-i. Näiteks eelneva näite korral ootab LSR B, et kõikidel prefiksiga <x.0.0.0, y.0.0.0> seotud FEC-i kuuluvatel sissetulevatel IP pakettidel on küljes silt (label) 62. Nende pakettide sildiga varustamine peab toimuma LSR-des, mis eelnevad B-le. See tähendab, et nad paiknevad sellesse FEC-i kuuluvate IP pakettide voo (flow) suhtes vastuvoolu (upstream). Selles näites ainuke LSR, mis asub B jaoks vastuvoolu on A. D jaoks asuvad vastuvoolu nii LSR-id B kui ka C.

40 ; LSR peab teavitama oma naabreid sellest, missuguse sildi ta on valinud ühe kindla FEC-i jaoks. Ülemise näite (joonis 12) varal peaks LSR B saatma oma informatsiooni A-le, D-le ja C-le. A saab aru, et see on B-lt tulnud tagasiside ja kasutab seda informatsiooni et uuendada kõnealuse FEC-i kohta käivat sissekannet oma LFIB-is. Selle FEC-i jaoks ei ole D ja C B-le vastuvoolu asetsevad marsruuterid ning nemad ei lisa seda informatsiooni oma LFIB-i. Siiski võivad nad salvestada selle informatsiooni tuleviku tarvis. Näiteks C-to-D lingi rikke korral võib B-st saada FEC-i jaoks järgmine LSR hüpe. Sellisel juhul kasutab C B poolt saadetud silti (label), et uuendada sissekannet oma LFIB-is. D saadab oma informatsiooni B-le, C-le ja E-le. Kuna B ja C asuvad mõlemad D jaoks vastuvoolu, siis kasutavad nad seda informatsiooni, et uuendada sissekandeid nende LFIB-ides. Lõpuks E saadab oma informatsiooni D-le, mis kasutab seda oma LFIB sissekande uuendamiseks. Tulemusena muudetakse kõikide LSR-ide LFIB sissekandeid (tabel 3). Tabel 3. Sildiga seotud informatsiooniga FEC sissekanne igas LFIB-is LSR Sisenev silt (Incoming label) Väljuv silt (Outgoing label) Järgmine hüpe (Next hop) Väljundliides (Outgoing interface) & - $ )5? B;? $ )54 B; 3 - )54 B 4 $; )5+ B + $; - )5+ B; LSR E jaoks on järgmine hüpe tema ise. See tähendab, et prefiksiga <x.0.0.0, y.0.0.0> seotud IP pakett edastatakse prefiksit kasutades kohalikule adressaadile üle if0-i. Kui sildid on jagatud ja LFIB-ide sissekanded parandatud, toimub prefiksiga <x.0.0.0, y.0.0.0> seotud FEC-i edastamine ainult sildi alusel. Eeldatakse, et A saab prefiksiga<x.0.0.0, y.0.0.0> IP paketi mitte-mpls IP domeenilt 1. A identifitseerib, et paketi IP aadress kuulub FEC-i ja otsib andmeid oma LFIB-ist, et saada teada sildi ning väljundliidese väärtus. Seejärel määrab ta sildi väärtuseks 62, kapseldab selle kasutades formaati, mis on näidatud joonisel 10 ning edastab selle väljundliidesele if0. Kui IP pakett jõuab LSR B-ni, võetakse selle silt (label) välja ning otsitakse üles õige

41 sissekanne B LFIB-ist. Vana silt (label) asendatakse uuega, milleks on 15, ning edastatakse see liidesele if0. LSR D järgib täpselt seda sama protseduuri. Kui see saab paketi B-lt, asendab see sissetuleva sildi väljamineva sildiga, milleks on 60, ning edastab selle liidesele if2. Lõpuks E edastab paketi kohalikule adressaadile. Täpselt sama protseduur kehtib ka prefiksiga <x.0.0.0, y.0.0.0> IP paketile, mis saabub C-sse mitte-mpls domeenist 2. Joonisel 13 on näha LSR-ide poolt jagatud sildid. Need sildid on sarnased VPI/VCI väärtustega ATM võrgus. Neil on lokaalne tähtsus, mis tähendab, et nad kehtivad ainult ühe lingi jooksul. Siltide (label) 62,15,60 järjestus moodustab tee (path), mida nimetatakse label switched path (LSP). See tee on analoogne punkt-punkt ühendustele, mida defineeritakse VPI/VCI väärtuste järjestusega. ATM ühendus on seotud kahe lõppseadmega, samas kui LSP on seotud FEC-iga. Tavaliselt on mitu LSP-d seotud ühe FEC-iga, moodustades puudiagrammi (joonis 13). Igal LSP-l on sissepääsu (ingress) LSR ja väljapääsu (egress) LSR. Näiteks joonisel 13 on LSR-ist A kuni LSR-ini E jooksva LPS jaoks LSR-id A ja E vastavalt sissepääsu ja väljapääsu LSR-id. Sarnaselt on LSR-id C ja E sissepääsu ja väljapääsu LSR-id LSR-ist C kuni LSR-ini E jooksva LSP jaoks. Joonis 13. Label switched path s [8] Sildi kommuteerimine (label switching) jätab kõrvale vajaduse teostada CPU põhises FIB tabelis otsinguid, et määrata IP paketi järgmise hüppe marsruuter. Otsing LFIB-ist ei ole nii aeganõudev, kuna see on arvestatavalt väiksem kui FIB. Kuigi pärast sildi kommuteerimise tutvustust arendati välja mitmeid CPU põhiseid algoritme, et muuta

42 otsinguid FIB-ist efektiivsemaks, ei vähendanud see sildi kommuteerimise olulisust, kuna selles nähti võimalust QoS-i juurutamiseks IP võrgus. Üks võimalus võrgus QoS kasutusele võtta oleks iga paketi sidumine prioriteediga. See prioriteet võiks olla näiteks lisatud sildi kapsli 3-bitisele eksperimenteerimise väljale (joonist 8). Prioriteete saab jagada MPLS ääresõlm. Sildiga varustatud IP pakette serveeritaks LSR-i sees vastavalt nende prioriteetidele, nagu ATM kommutaatori korral. ATM võrgus on iga VC (virtual connection) seotud QoS kategooriaga. ATM kommutaator saab sissetuleva paketi QoS taseme kätte selle VPI/VCI väärtusest ning vastavalt sellele järjestab raku õigesse QoS järjekorda. ATM kommutaator peab erinevaid QoS järjekordi iga väljundliidese jaoks. Neid järjekordi teenindatakse kasutades planeerimisalgoritmi (scheduling algoritm). Sarnast järjekorra struktuuri saab juurutada ka IP marsruuteris. IP paketid saab samuti vastavalt nende prioriteetidele järjestada väljundliidese juurde, et edastada neid vastavalt plaanuri (scheduler) poolt kehtestatud korrale. 4.6.SILDI JAOTUS SKEEMID (LABEL ALLOCATION SCHEMES) Kuna andmeliiklusele vastuvoolu (upstream) asuv LSR valib sildi ja saadab küsimata selle kohtainfo oma naabritele, nimetatakse sildi jaotusskeemi unsolicited downstrem scheme ks. Näitena vaadatakse LSR B-d jooniselt 13. LSR B annab sissetulevast FEC-i <x.0.0.0, y.0.0.0> sildist, 62, teada oma naabritele LSR-idele A, C ja D. Nendest asub LSR B jaoks vastuvoolu ainult LSR A. Selles vaates LSR A kasutab seda silti (label), et uuendada oma LFIB-i. LSR-id C ja D võivad salvestada selle info valikuliselt juhuks, kui nendest peaks saama LSR B-le vastuvoolu asuvad LSR-id. See võib juhtuda lingi või LSR-i rikke korral. Näiteks, kui link LSR-ide C ja D vahel on katki, peab LSR C oma liikluse ümber marsruutima läbi LSR B. (Vastavalt joonisel 13 toodud topoloogiale ei saa LSR D-st kunagi LSR B jaoks vastuvoolu asetsevat marsruuterit). LSR-id C ja D võivad samuti valikuliselt ignoreerida sildi kohta saadetud infot. Mitte vastuvoolu asetsev LSR salvestab või ignoreerib sildi kohta käivat infot sõltuvalt sellest kas kasutusel on conservative label retention mode või liberal retention mode. Conservative label mode i korral säilitatakse silt (label) ainult juhul kui LSR asub sildi

43 kohta infot levitava LSR-i suhtes vastuvoolu. Liberal label retention mode i puhul salvestatakse kõik sildid, hoolimata sellest, kas tegu on sildi kohta infot levitava LSR-i suhtes vastuvoolu asuva LSR-iga või mitte. MPLS võib kasutada ka downstrem on demand sildi jaotust. Sellel juhul seob iga LSR sissetuleva sildi FEC-iga ning loob korraliku sissekande oma LFIB-i. Siiski ei jagata sellisel juhul sildi kohta käivat infot kõigile oma naabritele ilma küsimata nagu unsolicited downstrem allocation skeemi korral. Selle asemel saadab vastuvoolu asetsev LSR välja küsimise, et täiendada sildi infot. 4.7.NEXT HOP LABEL FORWARDING ENTRY (NHLFE) Siiamaani eeldati, et LSR säilitab iga sissetuleva sildi jaoks ühe sissekande. Selles sissekandes seob ta sissetuleva sildi väljuva sildiga ning annab infot järgmise hüppe kohta - nagu järgmine LSR ja väljundliides. MPLS-i arhitektuur võimaldab LSR-il säilitada mitmeid sissekandeid iga sissetuleva sildi kohta. Iga sissekannet nimetatakse next hop label forwarding entry (NHLFE) ning see annab järgmist infot: paketi järgmine hüpe ja paketi sildiga teostatav operatsioon. Iga NHLFE sissekanne võib sisaldada ka täiendavat informatsiooni, mis on vajalik paketi korralikuks edasitoimetamiseks. MPLS võimaldab paketil kanda mitut silti (label), mis on organiseeritud järjekorras. Näide siltide järjekorrast (label stack) on toodud joonisel 14. Iga rida sisaldab erineva sildi kapslit. S bitt näitab, kas konkreetne sildi kapsel on viimane (S=1) või mitte (S=0). Label (20 bits) Exp (3 bits) S=0 Label (20 bits) Exp (3 bits) S=0... TTL (8 bits) TTL (8 bits) Label (20 bits) Exp (3 bits) S=1 TTL (8 bits) Joonis 14. Siltide järjekord (label stack)

44 Paketi sildiga saab teostada kolme järgnevat operatsiooni: Asenda paketi siltide järjekorras (label stack) kõige esimene silt uue sildiga, Lükka välja siltide järjekord (pop the label stack), Asenda paketi siltide järjekorras kõige esimene silt uue sildiga ning lükka üks või enam uusi silte järjekorda. Joonisel 13 on illustreeritud ainult esimene operatsioon. Kui LSR B võtab vastu paketi LSR A-lt, asendab, esimest operatsiooni kasutades, sissetuleva sildi, 62, uue, väljuva, sildiga 15. Sama juhtub ka LSR D-s. Kahte ülejäänud operatsiooni kirjeldatakse paragrahvis 4.9, kus tutvutakse siltide järjekorra kasutamisega. Juhul, kus LSR-i järgmine hüpe on LSR ise, lükkab LSR siltide järjekorrast (label stack) esimese sildi (label) välja ja edastab selle tulemusel saadud paketi. See võib endiselt jääda sildiga märgistatud paketiks või saada tavaliseks IP paketiks, mida edastatakse prefiksi alusel. Näites, joonisel 13, lükkab LSR E sildijärjekorra välja ning edastab tavalise IP paketi kasutades selleks prefiksit. Incoming label map (ILM) võrdleb sissetulevat silti selle sildiga seotud NHLFE-dega. Võib olla kasulik omada mitmeid sissekandeid iga sissetuleva paketi jaoks, kuna see võimaldab kasutada koormuse jagamiseks ja riskide hajutamiseks erinevaid teid. Viimaseks on kasutusel FEC-to-NHLFE map (FTN), mida kasutatakse FEC-i vastandamiseks NHLFE-dega. Seda kasutatakse juhul kui pakett saabub ilma sildita ja peab enne edasisaatmist saama omale sildi külge. 4.8.EXPLICIT ROUTING IP marsruuter teeb, järgmise hüppe määramiseks, marsruutimisotsuse kasutades oma FIBis olevat adressaadi IP aadressi. Kui kasutada lingipõhist protokolli nagu OSPF, õpib iga IP marsruuter selgeks oma domeeni topoloogia vahetades informatsiooni teiste marsruuteritega. Seejärel, kasutades lühima tee algoritmi, arvutab ta järgmise hüppe IP marsruuteri iga adressaadi jaoks. See järgmine hüpe salvestatakse marsruuteri FIB-is. MPLS kasutab samasugust järgmise hüppe informatsiooni, et paika panna LSP. Sellist marsruutimist tuntakse nime all hop-by-hop marsruutimine.

45 Lisaks hop-by-hop LSP-dele, lubab MPLS arhitektuur luua ka LSP-sid, mis järgivad läbi võrgu läbipaistvat teed, mis ei pruugi vastata hop-by-hop teele. Sellist tüüpi marsruutimist kutsutakse explicit routing. MPLS-is läbipaistvalt marsruuditud LSP on võrdväärne ATM võrgus oleva punkt-punkt ühendusega. Sellist tüüpi marsruutimist võidakse kasutada juhul kui on tarvis rahuldada QoS kriteeriume nagu näiteks minimiseerida viidet otspunktide vahel või maksimeerida läbilaskevõimet. Läbipaistvat marsruutimist võib kasutada ka koormuse jagamiseks võrgus, sundides osa liiklust järgima läbi võrgu teisi teid, et võrgulinkide kasutus oleks nii võrdne kui võimalik. Seda võib kasutada ka MPLS-põhiste tunnelite loomiseks ja virtual private networks (VPN) ide jaoks. Läbipaistev marsruutimine võib olla strictly explicitly routed või loosely explicitly routed. Esimesel juhul on rada sissepääsu (ingress) LSR-ist väljapääsu (egress) LSR-ini täpselt kirjeldatud. See tähendab, et kõik LSR-id, mida see tee läbib on paika pandud. Teisel juhul aga ei ole kõik LSR-id, mida tee läbib, ära kirjeldatud. Kui näiteks tee peab läbima mitut erinevat domeeni ei pruugi domeeni läbiv tegelik tee olla täpselt kirjeldatud. Sellisel juhul arvutab MPLS ääre LSR tee läbi oma domeeni. 4.9.NÄIDE SILTIDE JÄRJEKORRA (LABEL STACK) KASUTAMISEST Näide siltide järjekorra kasutamisest on toodud joonisel 15. Seal on kolm MPLS domeeni (A, B ja C) ja on loodud läbipaistev marsruut MPLS domeenis A asuva LSR 1 ja MPLS domeenis C asuva LSR 6 vahele. Siltide järjekord igal hüppel ning igas LSR-is teostatav operatsioon kogu raja vältel on samuti näidatud joonisel 15. LSR 1-st LSR 2-te liikuva paketi silt on 60. LSR 2-es teostatav operatsioon: asenda siltide järjekorras esimene silt uue sildiga ning lükka üks uus silt järjekorda. Selle operatsiooni tulemusena vahetatakse silt 60 välja 70ne vastu ning uus silt, väärtusega 40, lükatakse järjekorra etteotsa. LSR 3-st LSR 4-ja edastatakse pakett kasutades järgmist operatsiooni: Asenda paketi siltide järjekorras olev esimene silt uue sildiga. Selle tulemusena asendatakse järjekorra esimene silt kõigepealt väärtusega 22, seejärel väärtusega 54 ja lõpuks väärtusega 66. LSR 4jas kasutatakse operatsiooni: lükka välja siltide järjekord. Tulemusena eemaldatakse järjekorrast kõige esimene silt, väärtusega 66, ja edastatakse pakett LSR 5-ele, kasutades silti väärtusega 70. LSR 5 edastab paketi LSR 6-le kasutades operatsiooni: vaheta paketi siltide

46 $ järjekorras esimene silt uue sildiga. Tulemusena jõuab pakett LSR 6-te sildiga, mille väärtuseks on 30. Joonis 15. Näide siltide järjekorra (label stack) kasutamisest [8] Nagu näha, siis MPLS domeeni B siseselt edastades, on paketil kaks silti. Esimesi silte kasutatakse MPLS domeeni B siseseks kommuteerimiseks ja teisi silte kasutatakse MPLS domeene, B ja C, ühendavates ääresõlmedes LABEL DISTRIBUTION PROTOCOL (LDP) LDP-d kasutatakse FEC-iga seotud LSP-dele siltide (label) lisamiseks ja nende haldamiseks. Kahte LSR-i, mis kasutavad siltide vahetamiseks LDP-d kutsutakse LDP partneriteks. LDP poolt edastatavaid teateid klassifitseeritakse järgnevalt: Discovery messages: neid teateid kasutatakse andmaks teateid LSR-i võrgus viibimise kohta, Session messages: Et kaks LDP partnerit saaksid omavahel informatsiooni jagada, peavad nad kõigepealt looma LDP sessiooni. Neid sõnumeid kasutatakse

47 kahe LDP partnerite vahelise LDP sessiooni loomiseks, haldamiseks ja katkestamiseks, Advertisement messages: Neid sõnumeid kasutatakse, et luua, muuta ja kustutada FEC-iga seotud silte, Notification messages: Neid sõnumeid kasutatakse nõuandva informatsiooni ja signaali vigade kohta käiva informatsiooni edastamiseks. LDP töötab TCP peal, ainult discovery messages töötavad UDP peal MPLS (L3VPN) VPN TEHNOLOOGIA Üks enim poolehoidu võitnud MPLS tehnoloogia rakendustest on MPLS virtual private networks (VPN). See võimaldab teenusepakkujal või mõnel suuremal ettevõttel pakkuda L3VPN teenuseid. MPLS VPN võrk koosneb mingist arvust erinevast kliendi asukohast (edaspidi sait), mis on omavahel ühendatud teenusepakkuja MPLS tuumvõrgu kaudu. Igal saidil asub üks või rohkem CE (Client Edge seade kliendi valdustes), mis on ühendatud ühe või rohkema PE (Provide Edge) külge. PE-d kasutavad omavaheliseks dünaamiliseks suhtluseks Border Gateway Protocol-Multiprotocol i (MP-BGP). Kasutades IPv4 aadresse privaatvõrkudes, võib juhtuda, et mõned aadressid erinevates võrkudes kattuvad. MPLS VPN-i puhul ei ole see probleemiks, kuna igale aadressile lisatakse konkreetse VPNi kohta käiv prefiks, luues nõnda aadressi, mis on unikaalne.[13] Teenusepakkuja võrgus kasutatavad aadressid aga peavad olema eraldiseisvad VPN võrkudes kasutatavatest aadressidest. Iga CE peab saama adresseerida andmeid PE-le, mille külge ta ühendatud on, seetõttu ei tohi PE-de aadressid korduda üheski VPN võrgus. Virtual Private Network (VPN) on võrk, milles kliendi erinevad saidid ühendatakse omavahel kasutades jagatud infrastruktuuri kuid samu administratiivseid reeglistikke, mida privaatvõrkude korral. Kahe süsteemi vaheline tee VPN võrgus ning selle tee karakteristikud võivad samuti olla paika pandud reeglistiku poolt. Kas VPN võrgus asuv

48 süsteem võib suhelda teiste, mitte selles võrgus asuvate, süsteemidega, on samuti reeglistiku teha. Antud hulk süsteeme võivad asuda ühes või enamas VPN võrgus. Üks VPN võrk võib sisaldada ainult ühe ettevõtte süsteeme sisevõrk (intranet) või mitme erineva ettevõtte süsteeme suhtevõrk (extranet). Joonis 16. Saite jagavad VPN-id [17] MPLS-i põhine VPN luuakse L3 tasandil ning see baseerub partnerluse mudelil (peer model), mis teeb nad väga paindlikuks ning tavalisest VPN-ist kergemini ehitatavateks ja hallatavateks. Lisaks lisaväärtust andvad teenused, nagu rakenduste ja andmete hosting ja telefoniteenused, on kõnealusele MPLS VPN-ile kergesti lisatavad, kuna teenusepakkuja tuumvõrgu jaoks on kõik MPLS VPN-id turvalised, ühenduseta, IP võrgud.[17] Kliendi võrguvaade ning teenusepakkuja võrguvaade Kliendi vaatest on näha, et nende sisevõrgus asuvad seadmed suhtlevad omavahel läbi CE-de, mis on omavahel ühendatud teenusepakkuja poolt hallatava VPN võrgu kaudu. (Joonis 17). See lihtsustatud kliendi võrgu vaade on VPN-i kasutamise eeliseks: Kliendile näib, et tegemist on otsese suhtlusega oma erinevates asukohtades asuvate kontorite vahel nagu oleks tegemist nende endi isikliku privaatse laivõrguga, kuigi nende liikus käib läbi avaliku võrgu infrastruktuuri ning nad jagavad seda infrastruktuuri ka teiste ettevõtetega.

49 Joonis 17. Kliendi võrguvaade [17] Teenusepakkuja võrguvaade on loomulikult väga erinev sellest, mida võis näha joonisel 17 Joonisel 18 on kujutatud kahe erineva kliendi VPN võrgud kummalgi kliendil on ainult üks VPN võrk. Tegelikult võib ühel kliendil olla ka mitu VPN võrku. Joonis 18. Teenusepakkuja võrguvaade [17]

50 MPLS VPN-i eelised allika [17] põhjal ; Platvorm, mis võimaldab lisada kiirelt lisaväärtust andvaid IP teenuseid - nagu kõne, multimeedia, privaatsus ning turvalisus on võrdsed L2 VPN-iga, kuna VPN marsruutide kohta levitatakse infot ainult nendele marsruuteritele, mis on selle konkreetse VPN võrguga seotud. Ning edastuseks kasutataks MPLS tehnoloogiat, õmblusteta integratsioon kliendi sisevõrkudega, kasvanud skaleeritavus: ühte VPN võrku võib olla ühendatud tuhandeid saite (kliendi kontoreid), lihtne hallata ning uute kontorite võrku juurdelisamine käib väga kiirelt, skaleeritav any-to-any (kõik-kõigiga) ühenduvus mitmeid ettevõtteid haaravates, laiendatud, sisevõrkudes (intranet) või suhtevõrkudes (extranet) MPLS VPN tehnoloogia tutvustus MPLS kasutab kolme terminit, et kirjeldada marsruuteri rolli MPLS VPN-i ehitamisel: Customer edge (CE) Marsruuter, millele ei ole teadmisi MPLS protokollidest ja ei saada ka sildiga varustatud pakette, aga on otse ühendatud MPLS VPN-i LSR-i (PE) külge. Provider edge (PE) LSR, millel on otselink vähemalt ühe CE-ga, täites seejuures MPLS VPN võrgu ääre funktsiooni, hallates IBGP-d (Internal BGP ) ja VRF tabeleid. Provider (P) LSR, millel ei ole otselinki CE-ga, mis võimaldab marsruuteril ainult edastada sildiga märgistatud pakette ja ignoreerida kliendi VPN-ide marsruute. Et mõista, kuidas MPLS VPN töötab, tuleks keskenduda PE marsruuterite ja P marsruuterite vahelisele erinevusele juhtimistasandil (control plane). Nii P kui ka PE marsruuterid kasutavad LDP-d (Label Distribution Protocol) ja IGP-d (Interior Gateway Protocol), et toetada üksikedastusel IP marsruutimist. IGP jaotab marsruute ainult MPLS võrgu sisestele alamvõrkudele, kuhu ei ole lisatud kliendi marsruute. Koostöö tulemusena saavad P ja PE marsruuterid edastada sildiga märgistatud pakette sissepääsu (ingress) PE-st väljapääsu (egress) PE-ni.

51 PE-d peavad veel lisaks ära õppima klientide marsruudid ning meeles pidama, missugune marsruut missugusele kliendile kuulub. PE-d vahetavad, EBGP (External BGP), RIP-2 (Routing Information Protocol ver 2) või EIGRP (Enhanced Interior Gateway Routing Protocol) protokolle kasutades, marsruute erinevate klientide CEdega, et üles märkida, missugune marsruut missugusele kliendile kuulub. Et vältida võimalikku marsruutimisprefiksite ülekatet, ei paiguta PE marsruuterid neid marsruute tavalistesse marsruutimistabelitesse vaid eraldi kliendi-põhisesse marsruutimistabelisse, mida nimetatakse VRF-iks (VPN Routing and Forwarding). Seejärel kasutavad PE-d IBGP-d, et vahetada nende klientide marsruute teiste PE marsruuteritega, seda infot ei levitata kunagi P marsruuteritele. Joonisel 19 on näha juhtimistasandi (control plane) kontseptsioon. Joonis 19. Ülevaade MPLS VPN juhtimistasandi kontseptsioonist [23] MPLS VPN andmetasand (data plane) nõuab PE marsruuteritelt samuti natuke rohkem tööd. Tavalise üksikedastusega võrreldes, ei ole neil lisaülesandeid, peale ühe väikse erandi. Lisatöö PE jaoks on seotud sellega, et MPLS VPN andmetasand nõuab sissepääsu PE-lt kahe sildi lisamist paketile: Välimine MPLS päis (S bitt = 0); silt (label) mis võimaldab paketi toimetada kuni väljapääsu PE-ni, Sisemine MPLS päis (S bitt = 1); Võimaldab väljapääsu PE-l identifitseerida, missuguse VRF-i põhjal tuleks teha järgmine marsruutimisotsus.

52 Joonisel 20 on toodud kontseptsioon kahest sildist ning edastusprotsessist. Joonis 20 on osa joonisest 19, millelt on eemaldatud üleliigsed osad. Sellel joonisel saadab vasakul pool asuv kliendi host A paketi hostile , mis asub joonise paremal pool. Joonis 20. Ülevaade MPLS VPN-i andmetasandist [23] Joonisel 20 on näidatud järgmised sammud: 1. CE1 edastab ilma sildita paketi PE1-le, 2. PE1, võttes paketi vastu VRF-A-ga seotud liidese kaudu, võrdleb paketi adressaati ( ) VRF-A CEF (Cisco Express Forwarding) FIB-iga, mis põhineb VRF-A marsruutimistabelil. PE1 lisab 2 FIB-il põhinevat silti ja edastab paketi, 3. P1 võtab sissetuleva sildiga märgistatud paketi töötlusesse, mis toob endaga kindlasti kaasa ka sildivahetuse. P1 edastab paketi P2-le, 4. PE2-e LFIB sissekande nimekirjas on sildi 2222 jaoks kirjas ka sildi välja lükkamine, mille tõttu eemaldab PE2 paketilt välimise sildi. Sildi 3333 jaoks, kliendi A VPN-i VRF tabelile põhinedes, on samuti nimekirjas tegevuseks sildi välja lükkamine ning väljundliides. Selle tulemusena edastab PE2 ilma sildita paeti CE2-le. Praktikas erinevad sammud 3 ja 4 pisut eelpool kirjeldatust PHP (penultimate hop popping) tõttu. See näide oli mõeldud edastuspõhimõtete tutvustamiseks. PHP-ga variandist antakse ülevaade Lisas 2.

53 MPLS VPN-i juhtimistasand (control plane) MPLS VPN juhtimistasand defineerib protokollid ja mehhanismid, mille abil on võimalik üle saada klientide IP aadressruumide ülekatte probleemist, lisades mehhanisme, andmaks MPLS VPN-ile juurde rohkem L2 WAN (Wide Area Network) teenuste funktsionaalsusi. Kolm olulist kontseptsiooni, mis on loodud MPLS VPN-i jaoks: VRF-id, Route Distiguishers (RD-d), Route Targets (RT-d). Järgnevalt kirjeldatakse nimetatud kolme kontseptsiooni paragrahvi läbiva näite põhjal. Antud näide keskendub sellele, kuidas juhtimistasand õpib marsruute klientide dubleeritud alamvõrkudeni /24, mis asuvad joonise nr 19 paremal pool, kuidas lisab marsruudid PE2-es VRF-i, edastab RD-dega marsruudid PE1-le ja kuidas RT-d dikteerivad PE1-le mismoodi marsruute oma VRF-i lisada Virtual Routing and Forwarding tabelid Et pakkuda teenust mitmetele klientidele, sisaldab MPLS VPN standard virtuaalse marsruuteri kontseptsiooni. Seda vahendit, mida nimetatakse VRF-iks, saab kasutada, säilitamaks erinevate klientide marsruute üksteisest eraldi. Erinevate tabelite kasutamine aitab takistada ühe kliendi pakettide lekkimist teise kliendi võrku, mis võib juhtuda ülekattega prefiksite tõttu, kuid lubades siiski kõikidel, ühe ja sama kliendi VPN võrku kuuluvatel, saitidel omavahel vabalt suhelda. Üks VRF asub ühes MPLS-teadlikus marsruuteris. Tavaliselt on marsruuteritel vaja säilitada vähemalt üks VRF iga marsruuteri külge ühendatud kliendi kohta. Näiteks, joonisel 19 on marsruuter PE2 ühendatud CE marsruuteritega A ja B, aga mitte C-ga, seetõttu ei vaja PE2 VRF-i kliendi C jaoks. Samas PE1 on ühendatud kõigi kolme kliendi CE marsruuteritega ning PE1-s peab olema kolm erinevat VRF-i. Keerulisema ehitusega võrkude puhul võib PE-l olla tarvis mitmeid VRF-e, et pakkuda teenust ühele kliendile. Näitena kasutatakse taaskord joonist 19: PE1-e külge on ühendatud 2 kliendi A CE-d (CE-A1 ja CE-A4). Kui hostid CE-A1-e taga võiksid

54 omada juurdepääsu tsentraliseeritud jagatud teenusele ja näiteks hostidel CE-A4-ja taga ei oleks see lubatud, siis peaks PE1-es olema kliendi A jaoks kaks VRF-i. Iga VRF sisaldab kolme põhikomponenti: IP marsruutimistabel (RIB - Routing Information Base), CEF FIB, mis põhineb VRF-i RIB-il, Eraldi protsess marsruutimisprotokolli kasutamiseks, et vahetada marsruute CEdega, mida antud VRF peab teenindama. Joonis 21 näitab detailsemalt marsruuterit PE2 seadistatud VRF-idega. Sellel juhul kasutab PE2 RIP-2-te IGP-na mõlema kliendi (A ja B) puhul. Joonis 21. Marsruuteri PE2 VRF-i CE-lt õpitud marsruutide lisamine [23] Joonis 21 näitab kolme paralleelset sammu, mida sooritatakse mõlema kliendi puhul. Need sammud on järgmised: 1. CE marsruuter, millel puudub teadlikkus MPLS kohta täielikult, edastab marsruudi /2 sellel puhul RIP-2-e abil, 2. Teise sammu põhjal jõuab RIP-2 uuendus PE2-e S0/1/0, mis on märgitud kliendi A VRF-i. PE2 kasutab iga VRF-i jaoks oma RIP protsessi, nii et selle uuenduse tõlgendab VRF-A RIP protsess. Samamoodi analüüsib VRF-B RIP protsess uuendust, mis on saabunud S0/1/1-te CE-B2-lt, 3. Kolmanda sammu käigus lisab VRF-A RIP protsess /24 jaoks sissekande VRF-A RIB-i. Sarnaselt käitutakse ka kliendi B poolt saabunud andmetega.

55 Igal VRF-il on lisaks FIB, mida joonisel ei olnud näidatud. IOS (Internetwork Operating System) lisab iga RIB sissekande kohta ka sobiva FIB sissekande.[23] MP-BGP ja marsruudi eristajad (Route Distiguisher - RD) Nüüd, kui PE2 on selgeks õppinud marsruudid nii CE-A2-ni kui ka CE-B2-ni, peab ta nendest marsruutidest teada andma ka teistele PE-dele, et need teaksid ka kuidas edastada värskelt selgeks õpitud alamvõrkude pakette. MPLS VPN protokoll määrab marsruutide edastamiseks IBGP kasutuse kõik marsruudid erinevatest VRF-idest. Igatahes originaal BGP spetsifikatsioonid ei pakkunud võimalust tegeleda faktiga, et erinevad kliendid võivad kasutada samu kattuvaid prefikseid. MPLS lahendab kattuvate prefiksite probleemi sellega, et lisab ühe numbri originaal BGP NLRI (Network Layer Reachability Information) ette. Iga erinev number tähistab erinevat klienti, tehes nii NLRI väärtused unikaalseteks. Et seda teha kasutab MPLS BGP RFC-d, mida nimetatakse MP-BGP-ks (RFC 4760), mis võimaldab BGP uuendustes ümbermäärata NLRI välja. See ümbermääramine võimaldab ühe varieeruva pikkusega lisanumbri, mida kutsutakse aadresside perekonnaks (address family), lisada prefiksi ette. MPLS RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs), defineerib spetsiifilise uue aadresside perekonna, et toetada IPv4 MPLS VPN-ne neid nimetatakse marsruudi määrajateks (RD Route Distinguisher). RD-d võimaldavad BGP-l levitada eristajaid kahe dubleeritud IPv4 prefiksi puhul. Kontseptsioon on lihtne: levita iga NLRI-d (prefiks) nagu tavalist IPv4-ja prefiksit, aga lisa veel üks number (RD), mis identifitseerib marsruuti. Uus NLRI formaat, mida nimetatakse VPN-V4, sisaldab järgmist kahte osa: 64 bitine RD, 32 bitine IPv4 prefiks. Joonis 22 on loogiliseks järjeks joonisele 21: marsruuter PE2 levitab kahe IPv4 prefiksi jaoks mõeldud marsruuti /24 PE1-le - üks on pärit VRF-A-st ja teine VRF-B-st. Uuest aadresside perekonnast kasutatakse NLRI informatsiooni täiendamiseks RD 1:111 VPN-A korral ning 2:222 VPN-B korral.

56 $ Joonis 22. Prefiksite unikaalseks muutmine RD abil [23] Kui VPN-V4 NLRI üks osa ei oleks RD, siis PE1-ni oleks jõudnud kaks identset BGP prefiksit ( /24) ning ta peaks valima kahest marsruudist parima, andes niimoodi PE1-le ühenduvuse ainult ühe kliendiga kahest /24 alamvõrgust. VPN-V4 NLRI abil edastab IBGP kaks unikaalset NLRI-d 1:111: (VRF-A) ja 2:222: (VRF-B), mille tulemusena salvestab PE1 mõlemad NLRI-d oma BGP tabelisse. Joonisel 22 näidatud sammud on järgmised: 1. PE2 jagab vastavalt iga VRFi põhised marsruutimisprotokolli eksemplarid (praegusel juhul RIP -2) BGP-sse ümber, 2. Ümberjagamisprotsessi käigus võetakse RD igast vastavast VRF-ist ja lisatakse see RD igale ümberjagamisele minevale marsruudile, 3. PE2 kasutab IBGP-d, et edastada need marsruudid PE1-le. RD on 8 Baiti pikk ning sellel on omad vormistuse reeglid. Esimesed 2 Baiti määravad ära, missugune kolmest vormistusvariandist järgneb. Viimased 6 Baiti võivad vastata nendele kujudele: 2 Baiti täisarv: 4 Baiti täisarv, 4 Baiti täisarv: 2 Baiti täisarv, 4 Baiti punkteeritud kümnendarv: 2 Baiti täisarv. Kõigi kolme variandi puhul peab esimene väärtus (enne koolonit) olema kas ASN või IPv4 aadress. Teine väärtus, pärast koolonit, võib olla mis iganes.

57 Praeguseks on PE1-el /24 jaoks selgeks saanud kaks marsruuti üks VPN-A jaoks ja teine VPN-B jaoks ja need marsruudid on ka BGP tabelis. Järgmiseks kirjeldatakse seda, kuidas PE1 valib marsruudi lõpp-punkti (Route Target - RT) järgi missugusesse VRF-i need marsruudid lisada Marsruutimise lõpp-punkt (Route Target) MPLS RT-d võimaldavad MPLS-il pakkuda tuge erinevatele keerulistele VPN topoloogiatele näiteks lubada mõnel saidil olla kättesaadav mitmetele VPN-idele seda kontseptsiooni kutsutakse kattuvateks VPN-ideks. PE-d edastavad RT-sid BGP uuendustes nagu BGP Extended Community path attributes (PA). BGP extended community on 8 Baiti pikk ning väga paindlik, et kasutada seda erinevatel eesmärkidel. MPLS on määranud BGP Extended Community PA ülesandeks kodeerida ühe või enama RT väärtusi. RT väärtused järgivad RD väärtustega sama põhiformaati. Kuid kui ühel kindlal prefiksil võib olla ainult üks RD, siis samal prefiksil võib olla üks või mitu RT-d. MPLS kasutab RT-sid, et kindlaks teha, missugusesse VRF-i peab PE sisestama IBGP poolt teada saadud marsruudi. Joonis 23 on järjeks kahele eelnevale joonisele (21 ja 22), nüüd keskendutakse sellele, kuidas PE kasutab RT-d, et tuvastada missugusesse VRF-i marsruut tuleb lisada. Joonisel on näidatud export RT seadistus VRF-i konfiguratsioonis erinevate väärtustega vastavalt VRF-A ja VRF-B jaoks. PE1 näitab oma import RT-d igale VRFile taaskord seadistus VRF-i konfiguratsioonis mis aitab PE1-l valida, missuguse BGP tabeli sissekande see tõmbab iga VRF-i RIB-i.

58 Joonis 23. MPLS Route Target i mehaanika [23] Joonisel 23 kujutatud sammud: 1. PE2-e kaks VRF-i on varustatud export RT väärtusega, 2. Toimub VRF-ist BGP-sse ümberjagamine, 3. See samm märgib lihtsalt, et ekspordi protsessi käigus ümberjagamine VFRist BGP-sse lisataks õige RT väärtus PE2-e BGP tabelisse, 4. PE2 levitab marsruuti kasutades IBGP-d, 5. PE1 uurib uusi BGP tabeli sissekandeid ja võrdleb RT väärtusi konfigureeritud import RT väärtustega mille tulemusena selgub, missugused BGP tabeli sissekanded kuhu VRF-i tuleb sisestada, 6. PE1 jagab marsruudid vastavatesse VRF-idesse vastavalt sellele missugused RT-d omavahel klapivad. Kergematel VPN teostamisjuhtudel, kus igas VPNis on ainult ühe kliendi saidid, kasutatakse enamasti ühte RT väärtust igas VRF-is nii importimiseks kui ka eksportimiseks.[23]

59 5. ÄRIKLIENDI PRIVAATVÕRK MPLS VPN (L3VPN) TEHNOLOOGIA BAASIL Antud peatükis antakse ülevaade sellest, kuidas näeks välja töö aluseks olnud kliendi X Lan-to-Lan lahendus MPLS VPN (L3VPN) tehnoloogia baasil. Kliendi kõikide kontorite internetiühendusega varustamist käsitletakse peatükis 6. Toetudes töö eelmises peatükis käsitletud MPLS VPN tehnoloogia tööpõhimõtetele võib väita, et võrgu seisukohalt vaadates, kaob ära mõiste peakontor, kuna enam ei eksisteeriks ühte kogu kliendi laivõrgu toimimise eest vastutavat võrguseadet (ATM tehnoloogia baasil pakutaval lahendusel oli selleks seadmeks kliendi peakontoris asuv Cisco 3725). Harukontorite ribalaiusi kajastav tabel nr 1 on ka selle lahenduse korral endiselt päevakohane, kuna harukontorites kasutajate arv ei muutu. Samuti jäävad samadeks kliendi juurde paigaldatavad otsaseadmed: SHDSL ühenduse korral Cisco 878 ning ETH (Ethernet) ühenduse korral Cisco 881. Küll aga muutub lihtsamaks ning paindlikumaks harukontorite (sh ka peakontori) haldamine, kuna erinevalt ATM baasil ehitatud võrgust, ei ole selle lahenduse korral tarvis konfigureerida staatilist kanalit (PVC ATM võrgus) aadressilt A aadressile B. Piltlikult öeldes tuleb näiteks uue kontori juurde lisamiseks käsitsi konfigureerida ainult juurdepääs kliendi X L3VPN pilveni (joonis 24), edasi toimub juba kõik automaatselt nagu on kirjeldatud ka peatükis 4. Seetõttu puudub ka võrgu seisukohalt vaadates mõiste peakontor, kuna seda käsitletakse täpselt samamoodi nagu harukontoreid ning tal ei ole enam ülejäänud võrgu toimimise juures nõnda suurt rolli. Et peakontori rolli harukontorite töö ning korrektse toimimise jaoks veelgi vähendada, on peakontorist ära kolitud ka serverid, mis uue lahenduse järgi hakkaksid asuma teenusepakkuja A klassi serveriruumis, kus on nendele seadmetele, lisaks korralikele kliimatingimustele, tuleohutusele ning turvasüsteemile, tagatud ka varutoite olemasolu. Võrgus käsitletakse ühendust serveriteni nagu järjekordset harukontorit, mistõttu on nende serverite ümberkolimine nii kliendi kui ka teenusepakkuja jaoks üsna kerge (ATM võrgul baseeruva lahenduse korral, oleks serverite kolimisel teenusepakkuja serveriruumi tarvis kolida koos serveritega ka peakontoris asuv võrgu keskseade, MPLS tehnoloogial baseeruva lahenduse korral saab aga servereid vaadelda peakontori ühendustest eraldiseisvalt). Tuleb märkida et selle lahenduse korral ei toimi ka interneti ühendus harukontorite jaoks läbi peakontori (täpsemalt kirjeldatud peatükis 6).

60 Media Converte r _ 5VD C. 1A + U P LINK LIN K PW R LINK SD RX TX $; Kuna peakontori roll kogu võrgu vaatest on muutunud võrdäärseks mistahes harukontori rolliga, siis ei ole uue lahenduse korral enam vajadust paigaldada peakontorisse kallist seadet, piisab ~10 korda odavamast seadmest näiteks marsruuterist Cisco 881. Samuti pole tarvis reserveerida peakontori jaoks ribalaiust, mis peaks suutma ära teenindada kõik 20 harukontorit, kuna uue lahenduse korral ei käi enam kogu internetiliiklus ega ka serverite ning harukontorite vaheline liiklus läbi peakontori kanali. Seega, arvestusega, et peakontoris asub 10 aktiivset töökohta ning et iga töökoht tõenäoliselt tekitab suuremat koormust kui väiksemates harukontorites, oleks uue lahenduse korral peakontori ribalaiuseks planeeritud 20/20 Mb/s. Joonis 24. Kliendi X privaatvõrk MPLS VPN tehnoloogia baasil

61 $ Järgnevalt on lühidalt ära toodud ATM tehnoloogial baseeruva lahenduse korral esilekerkinud, peatükis 1 väljatoodud, kitsaskohad MPLS tehnoloogia vaatest (kuidas MPLS tehnoloogia need kitsaskohad kõrvaldab) Kliendi vaatest: 1) Kliendi jaoks muutuks peakontori andmeside ühendus kindlast odavamaks, kuna uue lahenduse puhul saab kogu tööga hakkama ka ~10 korda odavam seade ning pole enam tarvis kasutada kallist ATM kommutaatorit, samuti väheneb peakontori poolt kasutatav ribalaius enam kui poole võrra. 2) Harukontorite töö ei sõltu uue lahenduse korral enam peakontori tööst. Kuna nii tööks vajalikud serverid kui ka internetiühendus ei asu enam peakontoris, siis saavad harukontorid oma tööd rahulikult jätkata ka siis, kui peakontori ühendus peaks mingil põhjusel rivist väljas olema. 3) Samuti oleks peakontori ümberkolimine kergem, kuna uue lahenduse puhul puudutakse see ainult peakontorit ning ei tekitaks katkestust teiste harukontorite töös. 4) Kliendi jaoks väheneb interneti ühenduse kulu ja ülesseadmise keerukus täpsem tutvustus peatükis 6. Ettevõtte vaatest: 1) Uute kontorite võrku lisamine ning nende haldamine on uue lahenduse puhul vähem aeganõudev ning mugavam, kuna enam pole tarvis võrguadministraatoril konfigureerida tunnelit läbi võrgu. Piisab sellest, kui uuele kontorile konfigureeritakse juurdepääs kliendi X L3VPN võrku. 2) Internetilahendust käsitletakse peatükis 6. 3) Erinevalt ATM-ist on IP/MPLS tuumikvõrgu puhul ligipääs sõltumatu tehnoloogiast, selleks võib olla nii DSL (Digital Subscriber Line), Ethernet, WIMAX (Worldwide Interoperability for Microwave Access) ning tulevikus ka 3G (3rd Generation) mobiilsidevõrk. Selleks, et kontorit lisada kliendi L3VPN võrku, tuleb lihtsalt konfigureerida punkt-punkt ühendus kliendi CPE ja teenusepakkuja PE vahele, mis erinevate alustehnoloogiate korral ei tekita lisatööd. 4) Vigade lokaliseerimine on kergem ning sellega saavad hakkama ka rikete lahendamist koordineerivad väiksema kvalifikatsiooniga administraatorid. Viga

62 $ on kergem lokaliseerida, sest uue lahenduse korral asuvad IP aadressid ühenduse peal nö lõiguti (joonis 25) ning lihtne IP-aadresside pingimine võimaldab teada saada, kus lõigul viga tekkis. Selline vea lokaliseerimise võimalus kiirendab kindlasti ka rikke likvideerimist, kuna rike suunatakse parandamiseks koheselt õigesse kanalisse (ATM lahenduse korral läks see kõigepealt nö kõrgema kvalifikatsiooniga administraatorite töölauale, kes pidid välja selgitama, kus ühenduse osas viga tekkis. Selline variant on kindlasti ajamahukam). Joonis 25. IP aadressid kliendi L3VPN võrku juurdepääsul 5) Erinevalt ATM võrgust, suudab MPLS edastada erineva suurusega pakette. IP/MPLS võrgus edastatavate pakettide puhul jääb paketi päise osakaal kogu paketi suurusest 2% juurde.[25] Seetõttu kasutatakse kogu ribalaiust kasulikumalt kui ATM ühenduste puhul, kus liiasus tuumikvõrgus võib ulatuda kuni 25%-ni. MPLS võrgus on MTU (Maximum transmissioon unit) 1500 Baiti, millele lisandub veel ka paketi päis (võib samuti olla varieeruva suurusega Baiti).[25]

63 6. TSENTRAALNE INTERNETILAHENDUS L3VPN VÕRKU OMAVATELE KLIENTIDELE $ MPLS VPN loob teenusepakkujale võimaluse hakata pakkuma klientidele internetiteenust nö otse võrgust, kasutades selleks jagatud ressurssi. See tähendab, et klient ei peaks enam oma kontorite internetiühendusega varustamiseks tellima eraldiseisva füüsilise ressursi peal (eraldi seadmed + kaabel teenusepakkuja sõlmeni) toimivat internetiühendust nagu on kujutatud joonisel 1, ATM tehnoloogia baasil disainitud kliendi andmesidelahenduse korral. Piisab sellest, kui kontorisse on ehitatud MPLS VPN tehnoloogia baasil töötav kohtvõrkude ühendus ning otse võrgust pakutav internetiühendus oleks üks sellele kohtvõrkude ühendusteenusele rakendatavatest lisateenustest. Antud töös võrreldakse kahe erineva tootja (Cisco Systems ja Juniper Networks) seadmete poolt võimaldatavat lahendust võrgukeskse internetiteenuse pakkumiseks ning valitakse nendest üks, mida võiks teenusepakkuja võrgus kasutama hakata (võrdlus põhineb teenusepakkuja pool teostatud testide tulemustel). Mõlema lahenduse puhul on võimalik rakendada kolme teenusepakkujat huvitavat põhifunktsionaalsust: NAT (Network Address Translation), Pordi suunamine, IP suunamine. NAT-i rakendatakse mõlema lahenduse puhul nö seest välja. See tähendab, et privaatvõrgust avalikku võrku pääseb kogu liiklus täies mahus, aga avalikust võrgust privaatvõrku pääseb ainult see liiklus, mille jaoks parasjagu on püsti aktiivne NAT sessioon, ehk vastused privaatvõrgust tulnud päringutele. Liikluse jaoks avatud NAT sessioon suletakse niipea, kui tuleb vastuvõtjalt kinnitus, et vajalik info on kätte saadud või 2 minutit pärast sessiooni avamist (juhul kui sessiooni lõppu kinnitav pakett peaks kaduma minema). Pordi ning IP suunamist kasutatakse juhul, kui kliendil on sisevõrgus kasutusel rakendused, millele peab olema juurdepääs ka avalikust võrgust. Näiteks, kui kliendi sisevõrgus asub server, millele on tarvis ligi pääseda ka internetist. Sellisel juhul suunatakse port või portide vahemik kliendi sisevõrgus asuvale IP aadressile näiteks

64 $ tcp 21 >> , või väline IP aadress kliendi sisevõrgus asuvale IP aadressile sellisel juhul ei peaks iga pordi jaoks eraldi suunamist tegema. Lisaks on üks olulisi aspekte see, et lahendust oleks võimalik dubleerida. Oluline on, et liiklus lülituks ümber põhiseadmelt varuseadmele nii füüsilise rikke korral (kui seadme kliendi poolne liides ei tööta) kui ka marsruutimisprotokolli tasandil ettetulevate vigade korral. 6.1.CISCO LAHENDUS Joonis 26. Cisco seadmete abil pakutav tsentraalne internetilahendus Testimiseks kasutatud riistvara ning tarkvara Cisco IOS Software Release 15.0, Marsruuter Cisco 7200.

65 Lahenduse põhipunktid $ MPLS võrku on ühendatud marsruuterid (teineteist dubleerivad), mis sisaldavad nii globaalset marsruutimistabelit kui ka erinevate klientide VRF-e (ehk täidavad nii NAT-PE kui ka IGW (Internet Gateway) rolli). Kuna VRF tabelites on kasutusel privaataadressid, siis selleks, et L3VPN võrku omav klient pääseks avalikku võrku, on tarvis teostada privaataadresside transleerimine avalikeks aadressideks. Antud lahenduses tehakse seda Cisco 7200 ääremarsruuteris VRF-i lisatud staatilise marsruudi abil. VPN kliendil on registreeritud unikaalne aadressvahemik, mis on marsruuditav globaalses interneti marsruutimistabelis Lahenduse kirjeldus Antud lahenduse puhul kasutab nii seadmesse sisenev liiklus kui ka seadmest väljuv liiklus ühte liidest ning ühte kaabliressurssi. Selleks, et paketid jõuaksid internetti, tuleb NAT-PE-s konfigureerida kliendi VRF-i järgmise hüppe jaoks staatiline marsruut. Kuna aga VPN-IPv4 ning IPv4 marsruutide vahel ei toimu infovahetust (IPv4 marsruut ei jää kliendi VRF-i piiridesse), siis tuleb kasutada lisavahendeid, et saaks staatilise marsruudi lisada VRF-i ning et paketid jõuaksid ikkagi internetti. Selleks tuleb lisada staatilise marsruudi konfiguratsiooni reale võtmesõna global. Näiteks: ip route vrf customer global Võtmesõna global tagab selle, et kõik paketid, mis on internetti suunatud, marsruuditakse interneti lüüsi poole ning sealt edasi internetti. Kõikide klientide jaoks, kelle võrgus on kasutusel privaataadressid ning kes vajavad interneti ühendust, tehakse NAT võrgu ääremarsruuteris NAT-PE-s. Antud lahenduse korral on see seade ühtlasi ka interneti lüüsiks (IGW). Seega privaatvõrgust tulev pakett, millel on privaataadress, võetakse vastu lahenduses kasutatud, Cisco 7200 seeria, marsruuteri poolt ning tuvastatakse, missuguse kliendi VPN võrgust see pärit on (teostatakse otsing VRF tabelites). Seejärel eemaldatakse MPLS silt (label) paketi päisest, misjärel jääb alles tavaline IP pakett, mis pärast privaataadressi asendamist avaliku aadressiga internetti saadetakse. Kõik need tegevused toimuvad ühes seadmes.

66 $$ Kui pakett on saadetud avalikku võrku, jääb NAT sessioon püsti, et vastu võtta antud sessiooniga seotud internetist tagasi tulev liiklus. Internetist tulev pakett läbib vastupidise teekonna: Kõigepealt toimub otsing globaalses tabelis, kust vastava aktiivse NAT sessiooni korral antakse pakett üle sama seadme teisele funktsioonile, et teostada otsing VRF-ides. Misjärel transleeritakse avalik aadress tagasi privaataadressiks, varustatakse pakett siltidega ning edastatakse õiget VPN võrku kasutades õigele adressaadile. Antud lahenduse miinuseks on see, et ümberlülitumine põhiseadmelt varuseadmele toimub ainult juhul kui tegemist on füüsilise rikkega (kui põhiseade lakkab töötamast, kui seadme kliendipoolne liides on maas). Marsruutimisprotokolli tasandil ettetulevad vead ei lülita liiklust ümber teisele seadmele. Näiteks, kui on tegemist interneti poolsete häiretega, siis need ei kajastu kliendi poolel, kuna internetti pääs on antud lahenduse korral tagatud staatilise marsruudiga, mis jääb püsti ka siis, kui tegelikkuses interneti poolne dünaamiline marsruutimine ei toimi korrektselt (dünaamilise marsruutimise korral uuendatakse tabelites sedalaadi informatsiooni pidevalt). Antud lahenduse plussiks on kindlasti kerge ning lühike konfiguratsioon, mis tagab ka lahenduse kergema haldamise. Ühe kliendi juurde lisamisel piisab paarist konfiguratsiooni reast ning kuna ridu konfiguratsioonis on vähe, siis on ka konfiguratsioonivigade otsimine vähem aeganõudev kui teiste lahenduste puhul.

67 6.2.JUNIPERI LAHENDUS $ Joonis 27. Juniper i seadmete abil pakutav tsentraalne internetilahendus Testimiseks kasutatud riistvara ning tarkvara Junos 10.1 Release, Marsruuter Juniper SRX Lahenduse põhipunktid MPLS võrgu ääremarsruuterite külge on ühendatud kaks NAT seadet (teineteist dubleerivad), mis täidavad võrgus IGW (Internet Gateway) rolli. VRF tabelid asuvad selle lahenduse korral ääremarsruuterites, millest on IGW-ni iga kliendi jaoks eraldi VLAN konfigureeritud. IGW-st Internetti väljuv liiklus aga kasutab ühte kanalit, olenemata sellest, missuguse kliendi pakette edastatakse. Globaalne marsruutimistabel asub IGWle järgnevas võrgu ääreseadmes. Kuna VRF tabelites on kasutusel privaataadressid, siis selleks, et L3VPN võrku omav klient pääseks avalikku võrku, on tarvis teostada privaataadresside transleerimine avalikeks aadressideks. Antud lahenduses tehakse seda dünaamiliselt Juniper SRX seeria marsruuteris (IGW). VPN kliendil on registreeritud unikaalne aadressvahemik, mis on marsruuditav globaalses interneti marsruutimistabelis.

68 Lahenduse kirjeldus $ Antud lahenduse korral marsruuditakse VPN liiklus ja Interneti liiklus erinevate liideste kaudu. Kõikide klientide jaoks, kelle võrgus on kasutusel privaataadressid ning kes vajavad interneti ühendust, tehakse NAT Interneti lüüsis (IGW), milleks antud lahenduse korral on Juniper SRX seeria marsruuter. Seega, kui kliendi 1 VPN võrgust jõuab pakett PE3- e, teostatakse otsing VRF tabelites ning tuvastatakse, et käesolev pakett on seotud VRF1-ga. Seejärel teostatakse paketi sildiga operatsioon pop the label stack, mis eemaldab sildijärjekorras esimese sildi, kui see silt oli ühtlasi ka ainuke ning pärast operatsiooni pop the label stack jääb alles tavaline IP pakett, siis edastatakse see VLAN1-te pidi IGW-le, kus vahetatakse paketi päises asuv privaataadress avaliku aadressi vastu välja (NAT operatsioon) ning edastatakse internetiliikluse jaoks mõeldud liidese kaudu avalikku võrku. Kui pakett on saadetud avalikku võrku, jääb NAT sessioon püsti, et vastu võtta antud sessiooniga seotud internetist tagasi tulev liiklus. Internetist tulev pakett läbib vastupidise teekonna: Kõigepealt saadetakse see avalikust võrgust IGW-sse, kus paketi päises asuv avalik IP aadress vahetatakse välja privaatse aadressi vastu ning edastatakse pakett VLAN1-te pidi PE3-le, et teostada otsing VRF-ides. Misjärel varustatakse pakett siltidega (label) ning edastatakse klient 1 VPN võrku kasutades õigele adressaadile. Antud lahenduse puhul on miinuseks see, et konfiguratsioon on tunduvalt pikem (iga kliendi jaoks eraldi konfigureeritava VLAN-i tõttu) kui esimesena kirjeldatud Cisco lahenduse puhul. See tähendab rohkem tööd administraatoritele ning teeb konfiguratsioonist vigade otsingu keerulisemaks. VLAN-i, ehk virtuaalse kohtvõrgu (Virtual Local Area Connection) puhul on tegemist loogilise võrguga, mille nö paigaldamine toimub ainult tarkvaraliste vahendite abil. See võimaldab ühes füüsilises meedias kasutada mitut üksteisest lahusolevat võrku. Antud paragrahvis käsitletud lahenduse korral on ääremarsruuter ning interneti lüüs omavahel ühendatud ühe liidese kaudu (kahte seadet ühendab üks füüsiline kaabel), läbi mille jõuavad VLAN-ide abil ühest seadmest teise mitme erineva kliendi võrgud. Ehk ühes füüsilises kaablis töötab mitu erinevat virtuaalset ühendust (iga erineva kliendi jaoks üks) ääremarsruuteri ning interneti lüüsi vahel.

69 $ Selle lahenduse plussiks aga on see, ligipääs internetti on ära lahendatud dünaamiliste marsruutidega ning seetõttu ümberlülitumine põhiseadmelt varuseadmele ei toimu ainult kliendi poolse liidese füüsilise rikke korral vaid ka marsruutimisprotokolli tasandil ettetulevate vigade korral. Seega kajastuvad lahenduse kliendi poole peal ka interneti poolel ettetulevad dünaamilise marsruutimisprotokolli häired ning andmevoog suunatakse selle IGW peale, millel on õige marsruutimistabel LAHENDUSTE ANALÜÜS Mõlema lahenduse puhul on võimalik rakendada kolme põhifunktsionaalsust: NAT, Pordi suunamine, IP suunamine. Kuigi Juniper Networks i ja Cisco Systems i poolt pakutavatel seadmetel on erinevad hinnad, siis lõppkliendi jaoks teeksid mõlemad lahendused interneti tarbimise tunduvalt odavamaks. Võrdluseks võiks siinkohal tuua, et kui varasemate lahenduste korral paigaldati iga kliendi jaoks peakontorisse eraldi NAT-i tegev seade, mis ei ole sugugi odav, siis nende mõlema lahenduse puhul saab ühe seadmega ära teenindada ca 100 erinevat teenusepakkuja klienti. Kui võrrelda neid kahte lahendust, siis esimene, Cisco seadmete abil pakutav lahendus, on kindlasti tulevikus rohkem kasutustleidvam, kui Juniperi seadmete abil pakutud lahendus. Tulevikus, kui hetkel kasutuses olevad ääremarsruuterid on tarvis välja vahetada uuemate vastu, mis tõenäoliselt suudavad sel ajal juba täita ka NAT-PE rolli, oleks Cisco lahenduse baasil võimalik klientidele internetiteenust pakkuda neile lähimast PE-st. Seega oleks võimalik loobuda kahest kesksest teenust pakkuvast seadmest, mis aitaks omakorda tõsta teenuse käideldavust ning skaleeritavust. Seda aga muidugi juhul, kui väljavahetamise ajaks on väljaarendatud tarkvara, kus puudub staatilise marsruudi nõue kliendi VRF-is. Seega Cisco lahenduse käikuvõtmiseks tuleks kõrvaldada üks suurimaid puudujääke, milleks on kindlasti eelpool kirjeldatud staatiline marsruut internetti pääsemiseks. Kui see puudujääk kõrvale jätta, siis võib öelda, et Cisco lahenduse puhul on haldamise vaatest tegemist suurepärase lahendusega (lihtne konfiguratsioon ning väike töömaht

70 ; uute klientide juurdelisamisel), mis võimaldaks teenusepakkujal väiksema vaevaga ning lõppkokkuvõttes (tuleviku vaates) vähemate seadmetega pakkuda VPN klientidele interneti teenust. Vähemate seadmetega, kuna üks PE täidaks ühtlasi ka IGW rolli, kus tehakse ära NAT. Juniperi lahenduse korral on aga NAT operatsiooni teostamiseks paigaldatud eraldi IGW. Hetkel aga tuleks mõlema lahenduse installeerimiseks paigaldada 2 uut seadet, kuna praegu MPLS tuumikvõrgu ääremarsruuteritena kasutusel olevates PE-des ei ole võimalik teostada NAT operatsiooni ühest marsruutimistabelist teise (VRF-ist globaalsesse tabelisse), ehkki ka praegu on kõikides ääremarsruuterites olemas lisaks VRF-idele ka globaalsed tabelid. Tulevikus aga, kui PE-d vajavad väljavahetamist uuemate vastu võiks Cisco lahenduse baasil pakkuda klientidele internetti neile lähimast PE-st, ehk kaoksid põhimõtteliselt ära kaks keskset IGW-d, läbi mille kõik kliendid internetti pääsevad. Kuna antud hetkel ei anna kaks ühes (PE=IGW) meile eelist, sest mõlema lahenduse puhul on tarvis võrku juurde lisada kaks seadet, siis tuleb keskenduda pigem nendele eelistele ning puudustele, mis eelpool juba ka kirjeldatud on. Cisco lahenduse puhul on tarvis vähem ridu konfiguratsiooni lisada, mis teeks administraatorite töö kergemaks nii uute klientide lisandumisel kui ka konfiguratsioonist vigade otsimisel. Juniperi lahenduse puhul on konfiguratsioonis rohkem ridu, kuna selle puhul on tarvis PE-st iga kliendi jaoks eraldi VLAN konfigureerida IGW-sse. See raskendab administraatorite tööd nii klientide lisamisel kui ka vigade otsimisel. See annab Cisco lahendusele Juniperi lahenduse ees haldamise vaatest märgatava eelise. Leian aga, et olulisem punkt on siiski korrektne ümberlülitumine põhiseadmelt varuseadmele nii füüsilise rikke kui ka marsruutimisprotokolli tasandil tekkivate vigade korral, kuna see võimaldab teenusepakkujal pakkuda klientidele stabiilsemat teenust, mis omakorda tagaks klientide rahulolu teenusega. Klientide rahulolu on kindlasti teenusepakkuja jaoks väga oluline aspekt teenuste arendamisel, mistõttu oleks mõistlik nendest kahest lahendusest valida teine Juniper SRX seeria marsruuteritega pakutav teenus. Põhimõtteliselt oleks võimalik ka Cisco seadmetega teine lahendus tööle saada, aga siin tuleb arvestada kindlasti seadmete hinda, mis Juniperi seadmete puhul on sama läbilaskevõime juures odavam kui Cisco seadmetel.

71 Lahenduste installeerimise hinnavõrdluses jäetakse arvestamata jooksevkulud (OPEX Operating Expenditure), kuna mõlema lahenduse haldamisest tekkivad püsikulud on võrdsed (interneti omahind, monitooring, rikkehaldus jne). Kapitalikuludena (CAPEX Capital Expenditure) arvestatakse ühekordseid kulusid riistvara soetamisel, paigaldamisel ja konfigureerimisel. Kummagi lahenduse väljaehitamisel tekkivad ligikaudsed kapitalikulud on toodud võrdlevas tabelis 4. Arvestatud on kahe teineteist dubleeriva seadme väljaostmise (seadmete hind põhineb veebipoe, ///#C.#, andmetel, teisendatud Eesti kroonidesse arvestades USA dollari hetkekurssi - 12,9), paigaldamise ning konfigureerimisega kaasnevaid kulusid (hinnangulised kulud). Tabel 4. Tsentraalse internetilahenduse CAPEX võrdlus kahe erineva tootja samaväärseid seadmeid kasutades Tsentraalne internet Juniperi seadmetega Tsentraalne internet Cisco seadmetega CAPEX ~ kr ~ kr Eelnevalt toodu põhjal osutub valituks teine, Juniperi seadmete abil pakutav, lahendus.

72 Media Converter _ 5 VDC. _ 1 A + UP LI NK LINK PWR L INK S D RX TX 7. ÄRIKLIENDI ANDMESIDELAHENDUS MPLS TEHNOLOOGIA BAASIL Allolev joonis nr 28 kujutab töö aluseks olnud kliendi X andmeside lahendust MPLS VPN tehnoloogia baasil, millele on lisatud ka töö viimases osas kirjeldatud Juniper Networks i seadmete abil pakutav tsentraalne internetiteenus. Joonis 28. Kliendi X MPLS VPN tehnoloogia baasil toimiv andmeside võrk Töö aluseks olnud kliendi X andmesidelahendust MPLS VPN tehnoloogia baasil võib ette kujutada ühe MPLS VPN pilvena, mille ääreni on ehitatud mitmeid punkt-punkt ühendusi erinevatest kliendi harukontoritest (joonis 28). Sellise lahenduse juures puudub, peatükis 1 käsitletud lahenduses suureks kitsaskohaks olnud, peakontoris asuv võrgu keskseade ning kõik marsruutimisotsused tehakse ära tuumikvõrgu seadmete poolt. See vähendab oluliselt kontorites asuvate ühenduste sõltuvust peakontori ühendusest.

73 Et veelgi vähendada kontorites asuvate ühenduste sõltuvust peakontori ühendusest, on, MPLS tehnoloogia eeliseid ära kasutades, serverid kolitud teenusepakkuja serveriruumi, kus on neile tagatud kõik tööks vajalikud tingimused (varutoide, õige temperatuur, hapnikutase jne). Lisaks on teenusepakkujal võimalik serverite ühenduse rikke korral kiire reageerimine, kuna ligipääs serveriruumi on olemas ööpäev läbi ning ruumi sisenemiseks ei ole tarvis kulutada aega läbirääkimistele, mis enamasti kaasnevad kliendi valdustesse sisenemisel. Lisaks on joonisel 28 kujutatud ka peatükis 6 käsitletud tsentraalne internetilahendus. Uue lahenduse korral ei pea klient lisaks lan-to-lan ühendusele, interneti teenuse kasutamiseks, mitte ühtegi kontorisse sideettevõtjalt tellima eraldiseisval meedial (eraldi kaabel + eraldi seade) töötavat internetiühendust. Tsentraalse interneti lahenduse kasutamise eelduseks on MPLS VPN võrgu olemasolu internetiteenuse lisamine sellele on lihtne, kiire ning kliendi jaoks ka üle 10 korra odavam kui peatükis 1 kirjeldatud lahenduse korral. Teenusepakkuja süsteemides käsitletakse tsentraalset internetti L3VPN ühenduse lisateenusena, millel on üks konkreetne hind ning puudub kliendi jaoks fikseeritud ribalaius (kliendi jaoks lan-to-lan ühenduse ribalaius = internetiühenduse ribalaius).

74 8. KOKKUVÕTE Tänapäevases, kiiresti arenevas, tehnoloogiamaailmas on sideettevõtjate jaoks väga oluline telekommunikatsiooniturul toimuvaga kaasas käia. Klientide üha kasvavad infoedastusvajadused ning turul tihenev konkurents nõuavad pidevat arendustegevust nii teenusepakkuja tuumikvõrgus (BackBone) kui ka lõppkliendi lahenduste osas. Konkurents turul nõuab sideettevõtjatelt järjepidevalt uusi, innovaatilisi, lahendusi. Käesolevas töös võrreldi ühe Eesti keskmise ärikliendi X vajadustele vastavat ATM tehnoloogial baseeruvat andmesidelahendust (privaatvõrk + internet) ning MPLS tehnoloogial baseeruvat andmesidelahendust. Töö käigus analüüsiti vananeval ATM tehnoloogial baseeruva kliendilahenduse kitsaskohti nii sideettevõtte vaatest kui ka kliendi vaatest ning selgitati välja konkreetse kliendi jaoks parim võimalik andmesidelahendus teenusepakkuja tuumikvõrgu võimalusi arvesse võttes. Käesolevas töös anti põgus ülevaade MPLS (L3) VPN tehnoloogia tööpõhimõttest, mis aitab mõista töö käigus kliendi jaoks välja pakutud andmesidelahenduse võrgutopoloogiat. Ärikliendile X väljapakutud privaatse laivõrgu lahendus on toodud joonisel 24. MPLS VPN tehnoloogia võimaldab andmesidelahenduse disainimisel hoiduda paljude, ATM tehnoloogia baasil ehitatud, lahenduste puhul pudelikaelaks olevast võrgu keskseadmest, mis enamasti asub kliendi peakontoris. Seega töös väljapakutud lahenduse korral käsitletakse kõiki kontoreid nö harukontoritena, kuna nii internet kui ka serverid on peakontorist kolitud teenusepakkuja ruumidesse. Seetõttu ei mõjuta MPLS VPN baasil töötava lahenduse korral peakontori töö enam harukontorite tööd. Töö lõppeesmärgiks oli uurida, kuidas MPLS VPN tehnoloogia baasil töötavat privaatvõrku omavatele SME-dele pakkuda interneti teenust nii, et see oleks kliendi vaatest võimalikult odav ning ettevõtte vaatest võimalikult kergesti hallatav. Siinkohal jäeti teenuse sihtgrupist välja suurkliendid, kuna nendel on tulemüüri reeglistike suhtes enamasti väga erinevad nõudmised, millega arvestamine muudaks nii teenuse enda kui ka selle tarnimise liialt keeruliseks. Samuti pärsiks liigne paindlikkus tulemüüri reeglistike suhtes teenuse standardiseerimise protsessi. MPLS VPN tehnoloogia võimaldab pakkuda L3VPN privaatvõrku omavatele klientidele internetiteenust otse võrgust ehk tsentraalselt ning jagatud ressurssi

75 kasutades. Antud töös analüüsiti kahe erineva tootja (Cisco Systems ja Juniper Networks) seadmete poolt võimaldatavat lahendust võrgukeskse internetiteenuse pakkumiseks ning valiti nendest üks, mida võiks teenusepakkuja võrgus kasutama hakata. Käesolevas töös vaadeldud Cisco lahenduse puhul on tarvis vähem ridu konfiguratsiooni lisada kui töös vaadeldud Juniperi lahenduse korral, mis teeks administraatorite töö kergemaks nii uute klientide lisandumisel kui ka konfiguratsioonist vigade otsimisel. Samas aga, erinevalt Juniperi lahendusest, ei lülitu Cisco lahendus põhiseadmelt ümber varuseadmele marsruutimistasandil tekkivate vigade korral (VRF-i lisatud staatilise marsruudi tõttu). Kuna korrektne ümberlülitus põhiseadmelt varuseadmele on klientide rahulolu jaoks väga oluline, siis seati antud töös Juniperi lahendus esimesele kohale ning jõuti kliendi X kogu andmesidelahenduse lõppdisainini (joonis 28).

76 KASUTATUD KIRJANDUS Kõikide veebilehtede kättesaadavust kontrolliti $ [1] ATM technology [2] ATM Technology Fundamentals er09186a00800f0a49.html [3] ATM Signaling and Addressing er09186a00800f0a4b.html [4] ATM PVC, SVC, Soft-PVC, and PVP Frequently Asked Questions a901.shtml#qa11 [5] Configuring SVCs, PVCs, Soft PVCs, PVPs, and VP Tunnels a008014df6c.html#5369 [6] Layer 3 Protocols over ATM er09186a00800f0a4f.html [7] ATM versus Ethernet /1999/papers/07ATMvsEthernet/iworkpaper.html [8] Perros, H. G. Connection-oriented networks. John Wiley & Sons Ltd, 2005, 332 lk [9] Configuring ATM-to-Ethernet Interworking [10] ATM Network Interfaces er09186a00800f0a4e.html [11] Virtual Connections er09186a00800f0a4d.html [12] L2VPN Interworking xternal_docbase_0900e4b1805ddd73_4container_external_docbase_0900e4b180b23f4c.html#wp

77 [13] Layer 3 VPN Overview overview.html [14] IP/MPLS-Based VPNs [15] Demystifyng Layer 2 and Layer 3 VPNs [16] BGP Route Reflection in Layer 3 VPN Networks [17] Introduction to Cisco MPLS VPN Technology. _UG1.html [18] Multiprotocol label switching [19] MPLS VPN Services [20] MPLS Lab #3: playing with MPLS VPN [21] Layer 3 MPLS VPN Enterprise Consumer Guide Version 2 tml [22] BGP/MPLS IP Virtual Private Networks (VPNs) [23] Multiprotocol Label Switching. MPLS VPNs [24] How Ethernet Co-exists with ohter Services 0V2.ppt [25] Any Transport over MPLS [26] VPN Traffic Explorer [27] MPLS Advanced concepts and developments in MPLS aecd c.pdf

78 [28] Security Network Gateway Scalable and Centralized solutions for VPN business customers %20Centralised%20Internet%20Gateways%20for%20VPN%20customers.pdf [29] Internet Access from an MPLS VPN Using a Global Routing Table 86a fb.shtml [30] Internet Connectivity Options 81f1.shtml#wp39765 [31] Routing VPN and Internet Traffic Through Different Interfaces [32] Development of telecommunication, part 1 - History +History [33] Eesti uue põlvkonna lairibavõrgu arendusvisioon [34] The Role of MPLS Technology in Next Generation Networks [35] MPLS and Next-Generation Networks ZGVyP3htbGlkPTE1ODcyMDEyMDgveHZpaWkmaW1hZ2VwYWdlPXh2aWlp [36] Ucell NGN/MPLS Project for Uzbekistan by Probil [37] Network Evolution View from NGN Practice of Global Carriers [38] Malaysia s Global Transit Communications builds MPLS VPN int l Network with Juniper Networks [39] Managed WAN solutions [40] BT Group MPLS-Based IP VPNs Built on Cisco IOS Software Enable Streamlined and Applications-Aware Enterprise Network Services

79 [41] II Backbone IP di Telekom Italia e le Politiche di Peering [42] Eesti lairiba Arenduse Sihtasutus - Eesmärk [43] Ambient Sweden; internet Foresight How Sweden will become a leading Internet natin in [44] Reliance Globalcom Data Business scales Metro Area Network with Cartier Ethernet solutions [45] Reliance Globalcom s lobal managed Network service growing strongly [46] Verizon is a Leader in MPLS Services [47] Independent research Firm recognizes Verizon as a Leader for European WAN Services [48] BT Group MPLS-Based IP VPNs Built on Cisco IOS Software bd4.shtml [49] Spotlight on BT Products & Services: BT MPLS: New locations & reports [50] Laaneoks, E. Sissejuhatus võrgutehnoloogiasse. TÜ kirjastus, 2008, 200 lk [51] Classless inter-domain Routing

80 LISA 1. IP AADRESSIDE KLASSID ; Võrgu ja sufiksi välja suurused varieeruvad vastavalt IP aadressi klassile. Defineeritakse viite erinevat aadressklassi A, B, C, D ja E (joonis 29). Joonis 29. IP aadresside klassid [8] Klasse A, B ja C kutsutakse primaarseteks, sest need on kasutusel hostide aadressidena. Klass D on kasutusel multiedastusel; Klass E on reserveeritud tuleviku jaoks. Aadressi esimene väli määrab IP aadressi klassi, see jääb valimikku 1 bitt A klassi korral kuni 5 bitti E klassi korral. Teine väli annab võrgu aadressi ning kolmas väli on sufiks, mis annab hosti aadressi. A klassi korral on võrgu aadress 7 bitti pikk ja hosti aadress 24 bitti pikk, tulemuseks 128 võrgu aadressi ning hosti aadressi. B klassi korral on võrgu aadress 14 bitine ning hosti aadress 16 bitine, tulemuseks võrgu aadressi ning hosti aadressi. C klassi korral on võrgu aadress 21 bitine ning hosti aadress 8 bitine, tulemuseks võrgu aadressi ning 256 hosti aadressi. Võrgu aadressid kirjutatakse tavaliselt kümnendsüsteemis punkteeritud kujul. See tähendab, et iga Bait on kirjeldatud kümnendsüsteemis vahemikus 0 kuni 255. Näiteks IP aadress kirjutatakse kujul Vastavalt sellele esitusele võib öelda, et A klassi aadressid asuvad vahemikus kuni , B klassi omad vahemikus kuni ja C klassi omad kuni

81 Klass C on väga levinud, aga klass A on väga harva kasutatav kuna nii suure hostide arvuga võrke on väga vähe. IP reserveerib hosti aadressi 0, et märgistada võrgu aadress. Näiteks B klassi aadressi puhul on võrgu väli ja sufiks 0.0. See näitab võrgu aadressi Võrgus edastamise jaoks (broadcast) kasutab IP aadressi

82 LISA 2. PENULTIMATE HOP POPPING (PHP) MPLSVPN-i andmetasand töötab hästi, aga egress PE jaoks on protsess natuke ebaefektiivne. Ebaefektiivsus seisneb selles, et egress PE peab pärast kahe sildiga paketi saamist sooritama oma LFIB-is kaks otsingut. Joonisel 30 on toodud paragrahvi läbiva näite põhjal andmetasandi protsess, mille puhul PE2 peab läbi vaatama LFIB-ist kaks sissekannet. Joonis 30. Kaks otsingut Egress PE LFIB-is [23] Et vältida seda lisatööd kõige viimases LSR-is kasutab MPLS funktsiooni nimega penultimate hop popping (PHP). (Penultimate tähendab eelviimast) Seega PHP paneb eelviimase LSR-i välist silti (label) eemaldama, nii et viimane LSR (Egress PE) saab juba ainult VPN sildiga paketi. Selle ühe sildi tõttu peab egress PE tegema oma LFIB-is ainult ühe otsingu. Joonisel 31 on näha PHP toega andmetasandi andmevoogu. Joonis 31. Üks otsing Egress PE LFIB-ist (PHP) [23]