Routing i Taktiskt Internet

Transkript

1 UPTEC IT Examensarbete 20 p November 2006 Routing i Taktiskt Internet Modellering och simulering av försvarets taktiska kommunikationssystem Marcus Grehag

2

3 Abstract Routing i Taktiskt Internet Routing in Taktiskt Internet Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box Uppsala Telefon: Telefax: Hemsida: Marcus Grehag The network based defense of the future aims at creating a common picture of the current state of all communication systems in use. Using modelling and simulation the complexity of each system involved can be reduced, thus making them easier to analyze. Taktiskt Internet is a development from Telesystem 9000, a tactical mobile telecommunication system used by the Swedish army. Since 2001 simulation models have been developed for Taktiskt Internet using the tool OPNET Modeler. During the work on this thesis, a large network has been built up with these models, where the routing has been analyzed with respect to topology changes and traffic loads. It has also been tested whether routing-storms can be created in the model itself, since such storms have occurred in reality in tests with existing big networks. These results target some limitations in the models concerned, such as the recovery of broken links during simulation and the infinite memory capacity of the routers in the network. This implies the limitation to the making of models wherein nodes lose and regain contact with each other. In addition, due to the infinite memory capacity of the routers no packets need be discarded when overloaded, a condition resulting in abnormal traffic flows. The conclusion is that routing-storms cannot develop in models without changing and correcting the shown limitations. Handledare: Marcus Schön, Jakob Näslund Ämnesgranskare: Arnold Pears Examinator: Anders Jansson ISSN: , UPTEC IT06 040

4

5 Sammanfattning Framtidens nätverksbaserade försvar har som mål att skapa en gemensam aktuell lägesbild för alla inblandade kommunikationssystem. Genom att använda modellering och simulering kan man reducera komplexiteten hos de inblandade kommunikationssystemen och lättare analysera dem. Taktiskt Internet är en vidareutveckling av Telesystem 9000 som är ett taktiskt mobilt telekommunikationssystem som används av det svenska försvarets armé. Sedan 2001 har simuleringsmodeller utvecklats för Taktiskt Internet i verktyget OPNET Modeler. Under detta examensarbete har ett stort nätverk byggs upp med hjälp av dessa modeller, där routing har analyserats med avseende på faktorerna topologiförändringar och trafikbelastning. Det har även undersökts huruvida routingstormar kan uppstå i modellen eftersom dessa har påträffats i verkliga tester av större nätverk. Resultaten visar på ett par begränsningar i modellerna: dels kan brutna länkar inte repareras under simuleringens gång och dels har routrarna i nätverket obegränsat med minne. Detta medför att man inte kan modellera noder som tappar och sedan återfår kontakten med varandra. Dessutom gör routrarnas obegränsade minne att inga paket behöver kastas vid överbelastning, vilket bidrar till onormala trafikflöden. Slutsatsen är att routingstormar inte kan uppstå i de utvecklade modellerna utan att de påvisade begränsningarna åtgärdas.

6

7 Abstract...3 Sammanfattning Inledning Bakgrund Syfte Problemformulering Avgränsning Metod Telesystem Taktiskt Internet Kretsar OPNET Modeler Användningsområden Utvecklingsprocess Struktur Trafikmodellering Statistikinsamling Routing Adressering Adressformat Adresstyper Nätverkstyper Point-to-Point Broadcast Non-Broadcast Multiple Access Point-to-Multipoint Link State Routing Dijkstras algoritm OSPF Helloprotokollet Databasutbyten Tillförlitlig kommunikation Hierarkier

8 4.4.5 LSA-livscykel LSA-stormar Distance Vector Routing RIP Redistribution Routinglösningar i TS/TI Modellering och simulering Nätverksmodellen Statistikförklaring Scenario Topologiförändringar Routingreaktioner Modellering av förändringar Resultat Scenario Resultat Scenario Diskussion och slutsatser Scenario Scenario Scenario Rekommendationer Referenser Appendix A

9 1 Inledning Framtidens nätverksbaserade försvar har som mål att skapa en gemensam aktuell lägesbild för alla inblandade kommunikationssystem. Många olika slags system måste samverka, samtidigt som komplexiteten hos de individuella systemen ökar. Genom att använda modellering och simulering kan man reducera komplexiteten och lättare analysera och värdera olika kommunikationsnätverk. Därigenom kan man få svar på frågor angående prestanda, skalbarhet, mobilitet etcetera. Modellering och simulering möjliggör både analys av enskilda system såväl som totala nätlösningar bestående av flera system. Generic Systems, dotterbolag till Generic, är ett konsultföretag inom IT-branschen som grundades Företaget arbetar med verksamhetsoch teknikutveckling inom tjänsteområdet ledningssystem och dess största kunder finns inom försvaret. Rapportens författare kom våren 2006 i kontakt med företaget och fick därmed en första inblick i arbetet med utveckling av modeller för svenska försvarets taktiska kommunikationssystem Telesystem 9000 (TS 9000). Systemets används i dagsläget och dess aktualitet tillsammans med dess viktiga uppgift som en del i det fredsbevarande försvaret gör att författaren anser det av stort intresse att fördjupa sig i området. De modeller som utvecklats för Telesystem 9000 används till att bygga specifika nätverk och konfigurera dem med lämplig trafik. Därefter kan simuleringar göras och man kan mäta olika egenskaper som exempelvis fördröjningar och belastningar i nätverket. Modellerna kan också användas för att undersöka olika scenarier och identifiera problem som kan uppstå i systemet. I detta examensarbete undersöks routingen i stora nätverk byggda med hjälp av dessa modeller. 1.1 Bakgrund Arbetet med att ta fram simuleringsmodeller för försvarets TS 9000 startade 2001 och har sedan dess pågått under flera olika faser som beskrivs i dokumenten [8][9][10]. Initialt hade man problem med att hitta ett lämpligt verktyg som kunde simulera TS 9000 på ett tillfredställande sätt. Den första utvecklingsfasen syftade därför till att ta fram simuleringsmodeller i programmet OPNET Modeler och att undersöka om detta var ett lämpligt simuleringsverktyg. Under denna fas togs OPNETmodeller med grundläggande funktionalitet fram och verifierades mot det verkliga systemet. Detta gjordes genom att testa de framtagna modellerna mot mätningar i ett speciellt TS 9000-labb där motsvarande nätverk byggts upp. Simuleringarna överensstämde mycket väl med de uppmätta resultaten OPNET Modeler var alltså ett passande simuleringsverktyg. Under fas två gjordes en viss vidareutveckling av modellerna och funktionalitet som tidigare saknats lades till. Modellerna förbättrades även visuellt med nya ikoner. 9

10 Fas tre innebar nya relativt stora förändringar och blev klar i slutet av I dessa modellutvecklingar har man implementerat stöd för s.k. Taktiskt Internet (TI), en vidareutveckling som skett av TS Fler trafikprofiler har även tillkommit för att kunna genomföra relevanta trafiksimuleringar i telenäten. Det finns inga rapporter som publicerats specifikt om TS/TI-nätverk, däremot finns det flertalet företagsdokument och militära dokument som beskriver systemet och dess modeller. De routingprotokoll som används inom TS/TI, RIP och OSPF, har det däremot forskats mycket om. 1.2 Syfte Syftet med detta examensarbete är att undersöka routingen i stora TS/TInätverk med avseende på faktorerna trafikbelastning och topologiförändringar, samt att slutligen utreda om så kallade routingstormar kan uppstå i modellerna. För att uppnå detta är det viktigt att skapa en grundläggande bred förståelse som bidrar till att kunna placera in TS/TI-specifika lösningar i sitt sammanhang. Till att börja med presenteras en redogörelse för vad Telesystem 9000 och Taktiskt Internet är och hur de fungerar. För det andra beskrivs det verktyg, OPNET Modeler, som använts för att skapa modeller av TS/TI. För det tredje behandlas grundläggande koncept inom routing för att kunna förklara de båda routingprotokollen OSPF och RIP samt de tekniker de tillämpar. Fokus ligger till stor del på OSPF som spelar en central roll i TS/TI-modellerna. För det fjärde beskrivs den nätverksmodell med tillhörande scenarier och resultat som skapats under detta examensarbete. Slutligen diskuteras resultaten och slutsatser dras. 1.3 Problemformulering Det har tidigare uppmätts olika begränsningar i verkliga uppsättningar av TS/TI-nätverk. Begränsningarna innebär att routingtrafiken i nätverken blir överväldigande och routingstormar uppstår när man har för många noder inom vissa områden. I [7] anges att detta kan uppstå då stamnätet i TS/TI innehåller ca 30 noder eller fler. Man har i de befintliga modellerna av systemet aldrig försökt framkalla situationer där dessa begräsningar kan påvisas. Man har aldrig modellerat några större TS/TI-nätverk och man vet heller inte huruvida fenomenet kan uppstå i modellerna. Det är därför intressant att allmänt undersöka hur routingen i modeller av stora TS/TInätverk reagerar med avseende på olika parametrar. Följande frågeformuleringar ligger i fokus: Hur fungerar routingen i stora TS/TInätverk med avseende på parametrarna trafikbelastning och topologiförändringar? Hur reagerar routingprotokollet OSPF på detta? Kan routingstormar uppstå i modellen på samma sätt som i verkligheten? 10

11 1.4 Avgränsning Modellerna för TS/TI är redan utvecklade och inga nya modeller kommer att skapas inom ramen för detta examensarbete. Modellerna inkluderar alla nödvändiga egenutvecklade modeller samt de modifieringar av standardmodeller som gjorts. Dessa modeller ska dock uppdateras för att kunna användas i den aktuella versionen av OPNET Modeler (11.5), samt förses med funktioner som genererar passande statistik under simuleringarna. Med dessa modeller som grund ska ett stort TS/TI-nätverk byggas och konfigureras för att undersöka lämpliga scenarier med fokus på routing. Eventuella begränsningar och tillkortakommanden i modellerna som uppmärksammas under modellerings- och simuleringsarbetet, ska inte lösas eller utvecklas. Dessa ska endast uppmärksammas, diskuteras och rekommenderas för fortsatt arbete. 1.5 Metod Varje år kommer det ut nya versioner av OPNET Modeler. Dessa innehåller förbättringar och uppgraderingar av programmet. Vissa ändringar är därmed ofta gjorda i de standardmodeller som finns i modellbiblioteket. Egenutvecklade modeller använder sig ofta av standardmodeller eller är i grunden utvecklade efter dem. Eftersom de egenutvecklade delarna måste interagera med de fördefinierade modellerna krävs ofta justeringar. De egenutvecklade modellerna måste därför också uppdateras för att de ska fungerar som det är tänkt med de nya modellversionerna. Detta uppdateringsarbete består i att på låg nivå identifiera skillnader och fel i modellkoden och ändra dessa så att modellen även fungerar i den nya versionen. Detta har skett i stort sett uteslutande genom att implementera ändringarna i OPNET:s egenutvecklade C-språk PROTO-C. Genom flertalet simuleringar och felsökningar har modellerna uppdaterats för den nya programversionen. För detta programmeringsarbete användes [4] som stöd. Efter uppdateringen gjordes en verifiering mot routingtabeller framtagna i ett specifikt nätverk innan versionsändringen. Samma nätverksmodell användes, varpå routingen borde ske på samma vis. Dessa tabeller stämde överens och uppdateringen var därmed utförd på ett riktigt sätt och modellerna fungerade korrekt. 11

12 Genom att bygga en lämplig nätverksmodell och skapa olika scenarier i modellen får man en grundläggande arbetsmiljö för vidare undersökningar. Nästa steg var att bygga ett stort TS 9000/TI-nätverk som överskrider den storleksbegränsning som beskrevs tidigare. Ett nätverk med 42 noder (varav 35 stycken är i stamnätet) byggdes och blev därmed större än tidigare byggda TS/TI-nätverk. Nätverkets topologi grundas på ett antal antaganden om hur ett vanligt TS 9000/TI-nät ofta ser ut. Eftersom de kan variera kraftigt i utseende är det viktigt att bygga så allmänt som möjligt. Nätverket konfigurerades för de tre olika scenarier som skulle utföras. Den metod som användes för att utveckla respektive scenario beskrivs mer utförligt i kapitel 5. I varje scenario kördes olika simuleringar som samlade in angiven statistik. Den statistik som används har delvis valts med hjälp av användargränssnittet i OPNET Modeler, mer detaljerad statistik har implementerats (se kapitel 3.5). Statistik som skapats på egen hand handlar uteslutande om att registrera OSPF-interna händelser. All fokus har lagts på OSPF eftersom det används inom näten i TS/TI och det är i detta protokoll som LSA-stormar (se 4.4.6) kan uppstå (kan ej inträffa i RIP). Händelser som generar statistik är antalet skickade paket av varje pakettyp i OSPF, antalet LSAer och LSA-headrar i dessa paket samt antalet bekräftade LSAer. Statistiken skiljer även på hur paketen har sänts, dvs. multicast eller unicast. Slutligen har statistik för antalet skapade grannpar samt uppbrutna grannpar skapats. Utöver detta har stora mängder statistik valts i OPNET Modeler men endast den allra viktigaste statistiken har varit möjligt att ta med under resultat. Slutligen har statistiken analyserats, grafer ritats och slutsatser har dragits av mätvärdena. En detaljerad bild av routing i nätverket har på så vis skapats. 12

13 2 Telesystem 9000 Telesystem 9000 (TS 9000) är ett taktiskt mobilt telekommunikationsnät som har används sedan 1997 av det svenska försvaret. Ledningssystemets funktion är att ge befälhavare bra förutsättningar för att leda armén i strid. Det är utformat för att ge chefen goda möjligheter att samordna eld och rörelse i hela stridsområdet [1]. TS 9000 är ett helt oberoende nätverk som tillhandahåller ungefär samma tjänster som civila operatörer förmedling av telefoni och data. Abonnenter i TS 9000, dvs. förbanden och deras befälhavare, har alltid samma telefonnummer oavsett var i nätet som de ansluter sig. Data skickas med paketförmedling och tal via kretsförmedling. Vid höga krav på realtidskommunikation används kretsförmedling, då paketförmedling ger en viss fördröjning. Utöver detta har ledningssystemet bl.a. skydd för avsiktlig störning i form av telekrigsföring, samt skydd mot avlyssning genom att all trafik krypteras. För att använda TS 9000 måste man först fastställa var förbanden har sina stridsuppgifter under tidens gång. I anslutning till förbanden anordnas sedan s.k. anslutningspunkter (AP). Inom hela stridområdet förekommer ett stort antal AP och dessa kan ansluta sig till varandra trådlöst och bilda s.k. abonnentnät. Förband som är ute i strid eller är under flyttning ansluter sig till respektive AP via radio och övriga stationära förband ansluter sig till AP via kabelanslutning. Anslutningspunkternas placering i närheten av striden ger soldaterna full mobilitet då de kan ansluta sig via radio. En AP består i huvudsak utav ett fordon och en teleskopmast med tillhörande antenner. Fordonet innehåller bl.a. en radiolänkstation, fyra radioanslutningspunkter och en televäxel som förmedlar trafiken. Till televäxeln kan 30 anslutningar kopplas, och normalt används fyra av dessa för radiokommunikation och ett par stycken till anslutning via kabel. 13

14 Det finns flera utökade varianter av AP för olika ändamål. Utöver de vanliga AP finns även APN (Anslutningspunkt Nät), APS (Anslutningspunkt Stab) och APF (Anslutningspunkt Främre ledningsplats). APN har som funktion att ansluta telesystemet inom divisionsområdet till allmänna telenät och försvarets egna telenät. Kommunikationen med det allmänna telenätet är väldigt viktig för samarbeten med civila myndigheter. APS sammankopplar stabsdelarna med varandra och telesystemet, och är därför bl.a. utrustad med en högre och bättre antenn. Från APF leder divisions-/brigadchefen striden och denna består av ett splitterskyddat fordon med automatisk mastresningsanordning. I övrigt är utrustning i stort sett den samma som i vanliga AP. APF positioneras lämpligast i nära anslutning till de stridande förbanden för att möjliggöra personkontakter. De tidigare nämnda abonnentnäten, bestående av flertalet AP, ansluts till ett stamnät. Stamnätet är uppbyggt av ett stort antal s.k. knutpunkter (KP) som är sammankopplade med varandra via radiolänkar. Detta är själva kärnan i TS 9000 och skapar ett stort yttäckande nätverk. Knutpunkterna måste precis som anslutningspunkterna förflyttas med striden för att alltid kunna behålla denna täckning över det aktuella området. Anslutningspunkterna är placerade på lämpliga positioner ur stridsynpunkt, samtidigt som de bör ligga inom stamnätets räckvidd. Rörelserna i nätverket sker inte kontinuerligt utan i omgångar med stationära perioder emellanåt. Både knutpunkter och anslutningspunkter är mindre eller större läger som monteras ner och sätts upp varje gång de ska förflytta sig. En KP består av tre stycken fordon varav det ena har liknande utrustning som en AP och de övriga två fungerar som transmissionsfordon och innehåller två radiostationer vardera. Knutpunktens främsta uppgift är att koppla samman hela radiolänknätet och skapa yttäckande samband mellan alla enheter. Dessa sprids därför ut över hela området på utvalda platser. För att varje KP ska kunna kommunicera med minst två andra KP samt ev. en eller flera AP, krävs det vanligtvis att dessa placeras på dominerande höjder i området. Utöver detta kan KP även fungera som en AP lokalt och ta emot abonnenter via radio eller tråd samt ansluta till de fasta telenäten. På grund av knutpunkternas essentiella funktion i nätverket har dessa egen skydds- och bevakningspersonal. 2.1 Taktiskt Internet Taktiskt Internet är det senaste tillägget i TS 9000-modellerna och syftar till att utvidga telenätet till att kunna förmedla TCP/IP-trafik. Detta möjliggörs genom att samtliga televäxlar kopplas till varsin IP-router enligt Figur 1. Därigenom blir TS 9000 även tillgängligt för vanliga klienter utanför nätet som kan använda standardapplikationer som t.ex. mail, HTTP och FTP. 14

15 Figur 1: TS 9000 med Taktiskt Internet. Stamnätet byggs upp av Knutpunkter som abonnentnäten ansluter sig till via anslutningspunkter. Alla televäxlar har bestyckats med routrar vilket medger TCP/IP-trafik. 2.2 Kretsar TS/TI-nätverk använder standarden X.25 som beskriver kommunikationen i de tre lägsta lagren i protokollstacken. Standarden innefattar olika protokoll som sköter respektive protokollnivå och fungerar som ett sammanfattande begrepp. Ibland benämns även själva nätverkslagret i standarden för X.25. X.25 använder kretskopplad paketförmedling och reserverar därmed bandbredd för olika kanaler genom nätet. I TI används permanent virtual circuits (PVC) som är permanenta kretsar som kopplas mellan två noder. Dessa etableras automatiskt mellan varje televäxel och dess tillhörande router. Processen består av följande tre steg [9]: Televäxeln i varje nod kontrollerar vilken abonnentprofil den har. Har den profilen för mobil AP eller KP skickar den ut en förfrågan på alla sina trunkgränssnitt till grannarna för att ta reda på deras profil. Om en granne också har profilen för mobil AP eller KP svarar den genom att skicka över sitt abonnentnummer samt ett kanalnummer, som används för att koppla upp PVC:n. För varje mottaget svar som den initierande noden får, sätter televäxeln upp en PVC enligt mottagna angivelser. En permanent krets sätts upp mellan routern och televäxeln, medan televäxlarna kopplas ihop med en dynamisk krets. 15

16 Trafiken som skickas i X.25 är tillförlitlig och den bekräftas kontinuerligt genom s.k. acknowledgements (acks). Paketen bekräftas dock inte mellan källa och destination, utan mellan varje point-to-point-länk (se 4.2.1) under transporten gång. X.25 väntar på ack från tidigare skickad trafik innan mer trafik tillåts att skickas på länken. 16

17 3 OPNET Modeler I detta kapitel beskrivs OPNET Modeler, ett omfattande verktyg som används för att simulera och modellera nätverk med dess enheter och protokoll. På grund av verktygets komplexitet kommer vissa moment att generaliseras och endast de väsentligaste funktionerna tas upp. Mjukvarupaketet OPNET Modeler är ett kommersiellt program som har en stor marknadsandel inom sitt område och är en av få utvecklingsmiljöer som erbjuder ett relativt komplett stöd för nätverksmodellering och simulering. Det går också att bygga ut programmet med diverse separata mjukvarumoduler som ger extra funktionalitet. Nedan beskrivs OPNET Modeler version 11.5 utan några extra moduler så som det använts under detta examensarbete. 3.1 Användningsområden OPNET Modeler kan användas för olika typer av ändamål. Man vill ofta lösa ett tekniskt problem eller få svar på frågor och förutse olika systems beteenden. Det finns generellt sett två stycken användargrupper. Den första gruppen är systemdesignare som använder sig av redan befintliga kommersiella nätverksprodukter och färdigutvecklade modeller. De arbetar på en högre nivå och bygger och konfigurerar nätverk. De vill ofta genomföra prestandamätningar och göra beteendeanalyser av nätverk och dess noder. Genom att köra simuleringar av nätverksmodeller kan man samla in diverse statistik om exempelvis trafik och fördröjningar. Detta kan ge svar på frågor som t.ex.: Hur påverkas vårt kontorsnätverk om vi bygger ihop våra två avdelningar? Vilka länkar får ökad belastning? Hur lång blir den genomsnittliga fördröjningen i nätet? 17

18 Den andra användargruppen av Modeler är utvecklare och forskare som skapar egna modeller på en djupare teknisk nivå. De undersöker och skapar nya nätverksenheter och protokoll mm. Detta görs med hjälp av OPNET Modeler på en lägre nivå och utvecklarna kan även använda sig av OPNET:s egna version av programmeringsspråket C. Därigenom kan man skapa realistiska noggranna modeller för kommunikationsprotokoll, algoritmer och överföringstekniker. 3.2 Utvecklingsprocess I kapitel 3.1 redogjordes för vilka uppgifter som OPNET Modeler kan användas för att lösa. Dessa arbetsuppgifter kräver alla olika tillvägagångssätt, men de följer ändå samma grundläggande moment. När det gäller klassisk modellutveckling och simulering ser arbetsförloppet ut som Figur 2 visar. 1. Frågeställningar 2. Modellering 3. Validering 4. Simulering & Analys Figur 2: Utvecklingsprocessen för modellering & simulering. Processen innehåller ett iterativt steg då modellen förfinas tills den når förväntat resultat. Det allra första momentet är att ta fram de viktigaste frågeställningarna. Man gör en lista med frågor man vill att modellen ska kunna besvara. I steg 2 skapar man en första preliminär modell som kan besvara i alla fall några av de frågor man ställde sig i första steget. För att göra detta försöker man modellera de aspekter av systemet som man tror kommer att ha störst inverkan på frågeställningarna. 18

19 Steg 3 innebär validering att jämföra de modellerade egenskaperna mot det verkliga systemet och säkerhetsställa att de stämmer överens. Ett sätt att kontrollera detta är att göra enskilda simuleringar i modellen. För varje avvikelse som hittas tar man ett beslut huruvida avvikelsen är relevant eller inte. Det är omöjligt att bygga en exakt modellkopia av verkligheten och man måste därför bedöma varje enskilt problem och dess påverkan på slutresultatet. Om det inte är relevant för frågeställningen och resultatet kan det eventuellt ignoreras. För de avvikelser som måste korrigeras försöker man hitta källan till problemet. Därefter återgår man till steg 2 och förbättrar modellen genom modellering. Detta är en iterativ process som fortgår tills man når förväntat resultat. Om man har svårt att uppnå riktiga resultat kan man behöva börja om från början och skapa en helt ny preliminär modell. Detta betyder att den tidigare modellen var alltför felaktig för att kunna förfinas och man måste då bygga om från grunden. När man är nöjd med sin modell går man till steg 4 och den kan då användas för att analysera de fall och frågeställningar som man tidigare ville få svar på. I OPNET Modeler görs detta genom simulering och därefter analyseras resultatet noggrant. Eventuella oförklarliga resultat granskas vidare. Fungerar allt korrekt är utvecklingsprocessen klar och modellen är färdig [5]. 3.3 Struktur OPNET Modeler är, precis som riktiga nätverk, hierarkiskt uppbyggt. För respektive nivå i hierarkin finns det en enskild editor som är gjord för att man ska kunna skapa modeller på just den nivån. Dessa editorer har ett grafiskt gränssnitt vilket underlättar då man kan arbeta med sin uppgift på en högre abstraktionsnivå. Vidare består alla system i Modeler, på alla hierarkinivåer, av objekt med konfigurerbara uppsättningar attribut. Objekten tillhör klasser som på en generell nivå beskriver deras egenskaper i form av beteende och kapacitet. Klasser kan ärvas från andra klasser eller specialiseras för att passa särskilda ändamål. OPNET Modeler har stöd för återvinning av modeller vilket innebär att de som skapas i verktyget ofta bygger på tidigare utvecklade grundmodeller som finns sparade i ett modellbibliotek. Även om man kan utnyttja dessa modeller behövs det flera verktyg för att utföra alla arbetsuppgifter i utvecklingen av nya specifika modeller. Dessa verktyg är de tidigare nämnda editorerna som det finns ett antal av i Modeler. Av alla editorer finns tre stycken som har mer centrala funktioner än andra (se Figur 3): Projekt-, Nod- och Processeditorn. Övriga editorer används för att definiera olika datamodeller, oftast tabeller med värden, som nod- och processmodeller sedan refererar till. 19

20 Överst i hierarkin av verktyg kommer projekteditorn, där man grafiskt bygger upp sina nätverk genom att placera ut olika noder (routrar, arbetsstationer, subnät etc.) och binder samman dem med lämpliga länkar. Trafikflöden kan ställas in med hjälp av användarprofiler och applikationer som görs i separata editorer. Nätverksmodellen skapar ett geografiskt kontext genom att man kan bygga sitt nätverk på en karta med lämplig skala. När nätverket är färdigt sparas det som ett visst scenario i projektet. Varje projekt kan innehålla flera scenarier som beskriver olika nätbilder som är relevanta för projektet. Projekteditorn har även grundläggande stöd för simulering och analys. För noggrannare simuleringar och utvärderingar finns det andra lämpligare verktyg. Nodeditor Projekteditor Processeditor Figur 3: De tre huvudsakliga editorerna som används i OPNET Modeler. Projekteditorn visar ett nätverk, nodeditorn visar en nodmodell och processeditorn visar en automat. Inom nätverksmodellerna råder också en viss intern hierarki i form av nätverksstruktur. Nätverken kan nämligen bestå av olika subnät som i sin tur består av fler subnät och nätverk. Detta skapar en trädliknande struktur som gör att man kan arbeta med nätverken på olika abstraktionsnivåer (se Figur 4). Genom att klicka på en subnätsikon öppnas det lokala nätet som döljer sig ett steg ner i hierarkin. Här kan man modellera dess innehåll och ev. stega vidare ner i fler subnätverk. 20

21 Figur 4: Nätverken byggs upp av subnät som symboliseras av de röda ikonerna. Detta nätverk innehåller flera subnät, vara det ena i sin tur slutligen innehåller ett konkret nätverk. Noderna som används i nätverksmodellen är uppbyggda i den s.k. nodeditorn. Här konstruerar och modifierar man nätverksenheter som t.ex. routrar och hubbar. Man använder sig av några få grundläggande moduler: processorer, köer och några olika sändare och mottagare. Dessa kopplas samman med hjälp av paketströmmar, statistikkopplingar och logiska kopplingar. I nodeditorn modellerar man hur paketen förmedlas mellan de olika protokollen i protokollstacken samt hur de tas emot och skickas på enhetens gränssnitt. Figur 5 visar ett exempel på en nodmodell. 21

22 Paketström Statistikkoppling Logikkoppling Figur 5: Denna nodmodell innehåller alla typer av moduler och kopplingar samt paketströmmar. Den har två buss-gränssnitt, paketgenerator och paketförstörare m.m. De två moduler som tidigare nämnts, processorer och köer, kan i sin tur modelleras i processeditorn. I denna kan man beskriva de processer som ska pågå inne i modulen. Processerna är ett naturligt sätt att beskriva protokoll på och de implementeras i form av s.k. finita automater. Dessa beskrivs noggrannare i [3] och är en viss gren av matematiken som kallas automatateori. I automaterna, även kallade grafer, utgör cirklar tillstånden och emellan dem går tillståndsöverföringar i form av pilar. Överföringarna kan ha en eller flera villkor som måste uppfyllas för att kunna komma över till nästa tillstånd. Dessa automater beskriver processer genom att utgå från ett initieringstillstånd och sedan följa grafens pilar allteftersom olika villkor uppfylls. Villkoren beror av olika simuleringshädelser och interrupts som genereras i modellerna. I processeditorn kan man gå ner ett steg i hierarkin och se det som döljer sig under varje tillstånd och överföringarna med dess villkor. Allt detta implementeras slutligen i OPNET:s egenutvecklade typ av C-språk som kallas PROTO-C. Språket fungerar egentligen precis som C med den skillnaden att ett extra funktionsbibliotek lagts till med OPNET-specifika funktioner. Varje processmodell som skapas genererar automatiskt en lång sådan kodfil. Man programmerar dock inte i denna fil direkt eftersom den är relativt oöverskådlig, utan man kommer åt utvalda delar av programkoden genom processeditorn. Den process man konstruerat skapar alltså ett sorts kodramverk som man sedan lägger till sin kod i. Genom att klicka på tillstånden kan man lägga till kod som ska köras i respektive tillstånd. Man kan även programmera in andra viktiga variabler som överföringsvillkor mm. genom att använda editorns funktioner. 22

23 3.4 Trafikmodellering När man kör simuleringar i sina modeller vill man oftast minimera simuleringstiden för att påskynda arbetet. Allting som ska simuleras läggs till den totala simuleringstiden och det är därför viktigt att modellera rätt saker. Trafikmodellering är en faktor som kan kräva relativt mycket datorkraft beroende på hur detaljerad information man behöver. När man ska modellera trafik bör man därför noga tänka igenom vilken detaljgrad som behövs för att besvara sina frågor. OPNET Modeler har stöd för två typer av trafikmodellering: bakgrundstrafik och explicit trafik. Explicit innebär att varje enskilt paket modelleras i trafikflödet, dvs. paketen genereras, behandlas genom hela protokollstacken, transporteras genom olika medium, köas och fördröjs mm. Processen är ganska omfattande och tar betydligt längre tid att simulera än bakgrundstrafik, men i gengäld får man större noggrannhet. Denna typ av trafik lämpar sig för att undersöka trafikegenskaper som responstider och fördröjningar mm. För att skapa sin explicita trafik skapar man olika trafikprofiler som beskriver hur användargrupper använder diverse applikationer med avseende på tiden. Applikationerna består i sin tur av ett antal uppgifter som görs i ett visst mönster. Ett exempel på en trafikprofil kan vara Marknadsföring som använder sig av applikationerna Mail och Surfning som i sin tur består av uppgifterna Skicka mail och Ladda ner sida m.fl. Trafikprofilerna används genom att specificera lämpliga klienter och servrar som trafiken ska gå emellan. Bakgrundstrafik är analytisk i sin natur och passar bra om man inte behöver modellera trafiken i detalj. Inga paket modelleras alls utan istället beräknas köer och fördröjningar genom nätet utan att ta hänsyn till hur paketen egentligen bygger upp motsvarande trafik. Trafiken beskrivs på ett ganska okomplicerat sätt genom antal paket och bitar per sekund mellan olika tidpunkter. Bakgrundstrafik kan skapas antingen genom s.k. flöden eller olika länkbelastningar. Flöden definieras från en eller flera källor till en eller flera destinationer. Den analytiska trafiken routas därefter på lämpligt vis genom nätet och beräknar uppbyggandet av köer och fördröjningar efter vägen. Den andra typen av bakgrundstrafik länkbelastningar används för att ställa in trafiken över en viss länk. Länken belastas då lokalt med angiven trafikprofil vilket påverkar annan genomflytande trafik. Flöden har den speciella egenskapen att man kan ställa in om de ska vara explicita eller bakgrundstrafik. Oftast används de dock till bakgrundstrafik eftersom de saknar den detaljerade trafikbeskrivning som trafikprofiler erbjuder. Man kan även blanda små delar explicit trafik med analytisk trafik i ett och samma flöde, en s.k. hybrid simulering. Detta kan vara lämpligt om man vill komma åt vissa egenskaper i trafiken men ändå inte vill modellera den helt explicit. 23

24 3.5 Statistikinsamling Målet med att köra simuleringar i sina modeller är att få fram resultat och statistik från simuleringarna. När man har genererat den statistik man är intresserad av kan man slutligen analysera informationen och dra slutsatser. För att generera statistik måste man först samla in data att basera den på. I OPNET Modeler kan man enkelt välja den statistik man är intresserad av genom att kryssa för respektive statistik i ett speciellt fönster. Det kan vara t.ex. information om antalet paket som skickats per sekund i nätverket, CPU-användningen hos en viss nod etc. Verktyget har då på förhand skapat och initierat en s.k. statistikprob för respektive statistik som samlar in just den valda informationen vid rätt tillfällen. Detta sker på låg nivå i modellkoden där man använder en funktion som skriver önskat värde till statistikproben. Det underlättar att OPNET Modeler har lagt in stora mängder valbar statistik som man därmed inte behöver implementera själv. Ibland behöver man dock ännu mer detaljerad information och man kanske är intresserad av något som bara finns i just sina egenutvecklade modeller. I dessa fall måste man själv samla in data att basera statistiken på. Ur programmeringsperspektiv rör det sig endast om några rader kod per statistik, det är dock direkt avgörande var i modellkoden som statistiken skrivs. Eftersom man ofta använder sig av relativt omfattande standardmodeller i grunden, kräver det stor förståelse för den aktuella modellen. Man samlar lätt in väldigt mycket information vilket är krävande att hantera. Därför finns det insamlingsmetoder som sållar informationen och inte sparar allt. Några sådana metoder är hink- och stickprovsmetoden. Stickprov innebär att man bara tar vissa värden, t.ex. var 10:e värde eller ett värde var 5:e sekund. Med hinkmetoden klumpar man ihop värdena och tar ett antal värden, applicerar ett filter på dem och sparar dem som ett enda värde. Exempelvis kan man ta 10 värden och spara summan eller medelvärdet av dem. Statistik kan samlas in på olika nivåer: global-, nod- och länknivå. Statistiken som skrivs kan sparas på olika sätt. Det vanligaste formatet är en vektor där värden sparas parvis, t.ex. (tid, värde). På så vis kan man enkelt presentera en kurva med värden som beror av tiden. När man väl ska titta på sina data kan man använda olika filter för hur den ska presenteras. Vanliga filter är medelvärde, summa m.fl. 24

25 4 Routing Det här kapitlet inleds med att förklara elementära koncept och terminologi för nätverk och routing. Med detta som bas beskrivs de två huvudsakliga routingteknikerna: link state- och distance vector-routing. Teknikerna exemplifieras även genom en beskrivning av de vanligaste implementationerna, routingprotokollen OSPF och RIP. Avslutningsvis behandlas hur olika routingprotokoll kan interagera med varandra. Internet är ett gigantiskt nätverk och inget ensamt protokoll kan sköta routingen inom hela nätet. Varje routingprotokoll har istället olika egenskaper och användningsområden. Genom att dela upp Internet i mängder av mindre subnätverk kan man nyttja olika routingprotokoll på de respektive avgränsade delarna. Vidare finns det tekniker vars uppgift är att sammanfoga dessa mindre nät och förmedla routinginformation mellan dem. En vanlig avgränsning av Internet är s.k. autonoma system (AS). Ursprungsdefinitionen av AS är en samling nätverk, routrar och datorer som alla administreras av en enskild enhet. Exempel på sådana enheter kan vara institutioner, stora företag eller teleoperatörer. Denna enhet ansvarar för utrustningen och väljer även vilket routingprotokoll som ska användas inom systemet. Definitionen har dock luckrats upp något och nu för tiden kan t.ex. teleoperatörer administrera flera AS som indexeras med hjälp av speciella AS-nummer. Med hjälp av definitionen av ett AS kan man dela in routingprotokoll i två grupper man talar om interna och externa gateway-protokoll. Interna gateway-portokoll används endast inom AS och externa används mellan olika AS. Ordet gateway är en äldre benämning på de routrar som kopplar samman ett AS med ett annat, dvs. befinner sig på gränsen mellan systemen. Dessa routrar kallas även för gränsroutrar och de använder sig av ett visst routingprotokoll för att förmedla paket inom AS och ett annat protokoll för att kommunicera med externa system. Den informationen som routrarna får från externa system kan spridas in i det interna nätverket och vice versa. De routrar och datorer som bygger upp nätverk refereras ofta till som noder i denna rapport. 25

26 4.1 Adressering Alla nätverk har ett grundläggande behov av att kunna identifiera sina noder. De kommunikationstjänster som används på Internet idag är alla beroende av en entydig adressering. För att möjliggöra kommunikation med rätt part måste övriga parter i nätverket känna till dess identitet. IP-protokollet ansvarar för adresseringen av noder på Internet och det skiljer sig något från andra nätverksarkitekturer. Alla noder har nämligen inte en unik adress utan IP identifierar istället s.k. gränssnitt. Det är alltså varje gränssnitt som har en unik IP-adress. Oftast har noderna endast ett gränssnitt, vilket är fallet för de flesta vanliga arbetsstationer som är anslutna till nätet. Informellt säger man därför ofta att en nod har en viss IP-adress eftersom de vanligen bara har en. Routrar å andra sidan kan ha flera gränssnitt som alla motsvarar en IP-adress. Paket som skickas till ett visst gränssnitt på routern anländer till just detta gränssnitt, medan paket för andra adresser anländer till andra gränssnitt. Man kan alltså skicka paket till olika ställen på en och samma router och de kommer då in till respektive gränssnitt på tillhörande länk. Ibland kan denna distinktion vara onödig eftersom paket ändå kommer till samma router, men det är trots allt viktigt att notera skillnaden ur ett routingperspektiv. Gränssnitten kan nämligen vara kopplade till olika nätverkstyper (se 4.2) vilket påverkar hur vissa routingprotokoll agerar Adressformat Adressformatet i IP-protokollet består av 32 bitar (4 bytes) och är arrangerat enligt ett speciellt sätt. Varje byte representeras decimalt som ett tal mellan 0 och 255, och de åtskiljs av en punkt. Adresserna består av två delar: ett nätverksprefix och en värdidentifierare. Nätverksadressen definierar ett nätverk eller en grupp av nätverk. Värdidentifierare adresserar den enskilda värden (noden) i det aktuella nätverket. Nätverksprefixet kan vara olika långt och dess längd anges av ett snedstreck följt av en siffra som markerar längden i antalet bitar (se Figur 6). Det finns även ett äldre sätt att ange vilken del av adressen som är nätverksprefix och vilken som anger själva noden nätmasker. Dessa har samma form som en IP-adress och dess syfte är att markera den del av IPadressen som är nätverksprefix. Gör man om dem i binär form ser man att en etta markerar nätverksprefix och en nolla markerar att det inte är nätverksprefix. Exempelvis nätmasken anger att de första 16 bitarna är nätverksprefix eftersom dessa är ettor i binär form. Man delar in adresserna i olika klasser beroende på hur långa nätverksprefix de har. Klass A-nätverk har 8 bitars prefix, klass B-nätverk 16 bitar och klass C-nätverk 24 bitars prefix. Ju större prefix desto färre noder kan nätverket innehålla, vilket betyder att A-nät är störst och C-nät minst. 26

27 / Nätverksprefix Värdidentifierare Figur 6: Adressformatet för IP består av 4 stycken bytes (8 bitar vardera) separerade av punkter. Siffran efter snedstrecket indikerar att de första 8 bitarna är nätverksprefix och resten är värdidentifierare Adresstyper IP-arkitekturen stödjer tre olika typer av nätverksadresser: unicast, multicast och broadcast. Unicast är den enklaste varianten som refererar till ett unikt gränssnitt. Paket som skickas till en sådan adress förmedlas genom nätverket till motsvarande gränssnitt. Multicast beskriver grupper av adresser. En grupp inkluderar flera gränssnitt som oftast tillhör olika noder. När ett paket har en multicastdestination förmedlar nätverket detta till alla gränssnitt i gruppen. Broadcast-adresser är ett specialfall av multicast-adresser där man skickar till alla gränssnitt i hela nätverket. Dessa bör endast användas i väl valda situationer eftersom multicast annars är mer välriktad [1]. Exempel på dessa adresstyper visas i Tabell 1. Tabell 1: Exempel på de tre olika adresstyperna och dess omfång Adresstyp Adress Omfång Broadcast Alla noder på det lokala nätverket x.x Alla noder på nätverket x.x.0.0/16 Ex: /16 Multicast Alla noder på det här subnätverket Alla routrar på det här subnätverket Alla OSPF-routrar Unicast x.x.x.x Endast till x.x.x.x Ex:

28 4.2 Nätverkstyper Det finns fyra olika sorters nätverkstyper: Point-to-Point, Broadcast, Non- Broadcast Multiple Access och Point-to-Multipoint. Dessa beskrivs nedan Point-to-Point En point-to-point-länk består av en ensam sändare i ena änden av länken och en ensam mottagare i andra änden [1]. Det finns många olika länklager-protokoll som har designats för detta ändamål, exempelvis PPP (Point-to-Point Protocol). Motsatsen till point-to-point-länkar är broadcastlänkar där alla noder kan kommunicera med varandra via samma delade länk. Notera att det även i dessa nätverk går att kommunicera point-topoint genom att ange en specifik destination för paketen. Faktum är ett av de vanligaste länklager-protokollen för broadcast Ethernet idag ofta används för point-to-point-länkar. Point-to-Point-kommunikation innebär kommunikation över en direkt länk som exempelvis en point-to-point-länk. Det kan även vara en virtuell krets som reserverats mellan två noder. I kretskopplade nätverk som ATM och Frame relay kopplas virtuella kretsar mellan noderna som på så vis bygger upp virtuella länkar mellan sig och utför point-to-pointkommunikation. Kretsarna består i sin tur av ett antal fördefinierade fysiska point-to-point-länkar. Nätverk som består av endast Point-to-Point-länkar kallas för Point-to- Point-nätverk Broadcast I broadcast-nätverk är flertalet datorer och enheter sammankopplade via ett delat medium en broadcast-länk. Protokoll på länklagernivån sköter kommunikationen och det absolut vanligaste protokollet är Ethernet. När en dator skickar paket lyssnar alla andra noder i nätverket på länken därav namnet broadcast. Endast den noden som informationen verkligen är adresserad till kan ta emot den. Det är dock fullt möjligt att skicka paket till fördefinierade broadcast-adresser (se kapitel 4.1.2), vilket gör att samtliga noder i nätverket att ta emot dem Non-Broadcast Multiple Access Nätverk av typen NBMA (Non-Broadcast Multiple Access) skiljer sig från Broadcast-nätverk, där alla noder är kopplade till ett delat medium. I NBMA-nätverk kan alla noder kommunicera direkt med varandra men informationen broadcastas inte. Istället skapas virtuella kretsar mellan alla möjliga nodpar [2]. NBMA-nätverken använder ofta teknikerna Frame Relay, ATM och X

29 4.2.4 Point-to-Multipoint I Point-to-multipoint-nätverk kan inte alla noder kommunicera direkt med varandra, däremot kan varje nod kommunicera med flera andra. ATM-, Frame Relay- och X.25-nätverk är ofta NBMA-nätverk. Det är dock inget krav för dessa nätverk att alla noder måste kunna kommunicera direkt med varandra. Ju större nätverken blir desto dyrare blir det att skapa virtuella kretsar mellan alla möjliga par av noder. En alternativ topologi är point-to-multipoint-nätverk där bara några av noderna är kretskopplade till varandra [2]. Point-to-multipoint-kommunikation liknar point-to-point fastän en nod kommunicerar med flertalet andra noder. Den enskilda noden skickar inte informationen till alla andra via multicast, utan behandlar var och en som en separat point-to-point-länk. 4.3 Link State Routing Link state-protokoll är en viss typ av routingprotokoll som alla bygger på samma grundläggande principer. Dessa kan verka relativt invecklade när man läser protokollspecifikationer, men det beror oftast på att beskrivningarna är väldigt detaljerade och att protokollen vidareutvecklat den grundläggande algoritmen. I själva verket består de av tre elementära steg. Precis som andra routing protokoll vill Link State-protokoll åstadkomma en gemensam karta över nätverket. Det första steget för varje nod är att hitta sina egna grannar. Detta görs helt enkelt genom att varje nod i nätverket skickar ut ett s.k. hellopaket på alla sina länkar. Noderna tar också emot hellopaketen från sina närmaste grannar och får därmed reda på deras identitet samt kostnaden för länkarna till dem. Nu när noderna känner till sina grannar, är nästa steg att dela med sig av informationen till resten av nätverket. Varje nod skapar ett uppdateringspaket (LSU) som innehåller ett antal s.k. Link State Advertisements (LSAer) med granninformation. Därefter skickas paketet med alla LSAer till alla andra noder i nätet. Det vanligaste sättet att sprida LSAer är att genom s.k. flooding. När en nod deltar i denna process tolkar den inkommande LSAer som objekt som ska spridas vidare till alla grannar. Den sparar dock dess identiteter för att kunna jämföra dem mot nya LSAer. Kommer det in ett paket som noden tidigare har tagit emot, har detta paket redan spridits och kan därför kastas. Kommer det ett nytt paket skickas det ut på samtliga länkar förutom den länken det anlände ifrån. Denna mekanism förmedlar alla noders LSAer till varandra och de kan därigenom sammanställa en link state database. Efter att alla noder har skapat sig en identisk uppdaterad databas börjar den slutliga fasen av link state-routing beräkningen av vägar. Hittills har noderna bara samlat in information om nätverkstopologin. När det gäller att beräkna de kortaste vägarna genom nätverket finns det många olika algoritmer att använda. Den absolut populäraste av dessa är Dijkstras algoritm som beskriv i kapitel Varje enskild nod måste utföra dessa beräkningar för att hitta sina egna kortaste vägar genom nätet. 29

30 De tre stegen i link state-routing beskriver en bra initiering av ett statiskt nätverk. Faktum är dock att samma regler fungerar utmärkt för dynamiska nätverk också, men då sker dessa steg parallellt. Noderna skickar regelbundet ut nya hellopaket, uppdaterar statusen för sina grannkopplingar och meddelar ändringar till de andra noderna i nätet. Noderna beräknar om sina kortaste vägar och processen fortgår kontinuerligt Dijkstras algoritm Dijkstras algoritm kallas ofta för shorest path first-algoritmen och är grundläggande inom grafteori. Algoritmen beräknar de kortaste vägarna genom ett nätverk utifrån varje enskild nod med avseende på länkarnas kostnader. Detta görs genom att representera nätverk som träd där man utgår från trädets rotnod. Trädet beskriver sedan de kortaste vägarna från rotnoden till övriga noder i nätverket. Varje nod måste alltså beräkna trädet utifrån sig själva för att få reda på sina egna optimala vägar genom nätet. Algoritmen består av följande tre steg [2]: 1. Börja bygg trädet genom att välja trädets rot dvs. den lokala noden. Avståndet till denna nod är Undersök link state databasen för noden som precis lades till i nätverket. Räkna ut avståndet till dess ev. grannar genom att summera avståndet till den precis tillagda noden med avståndet från noden till dess respektive granne. Om summan är mindre än någon annan väg till noden, lägg till vägen temporärt i trädet. 3. Sök igenom trädet efter närmaste nod som inte har prövats. Lägg till noden med dess väg till trädet permanent och fortsätt till punk 2. Om det inte finns några fler noder att pröva är beräkningarna klara. 4.4 OSPF OSPF (Open Shortest Path First) är idag det vanligaste routingprotokollet för TCP/IP-nätverk och är av typen link state. Namnet har det fått från sina två huvudegenskaper: det är öppet, dvs. specifikationen är öppen för allmänheten, och det använder sig av algoritmen Shortest Path First (Dijkstras algoritm). Nedan beskrivs funktionalitet i OSPF som saknas eller inte beskrevs för allmänna link state-protokoll. Exempel på detta är OSPF:s stöd för hierarkier, dess tillförlitliga kommunikation och nodernas databasutbyten. 30

31 4.4.1 Helloprotokollet Helloprotokollet används vid den initiala fasen då grannarna träffar varandra. De utbyter då hellopaket med varandra på ett speciellt sätt. Först skickar noderna ut ett hellopaket på alla sina gränssnitt. De grannar som tar emot paketen svarar genom att skicka tillbaka ett hellopaket med ursprungsnoden listad som granne. När ursprungsnoden får tillbaka paketet med sig själv listat i det, fastslår den att grannen verkligen finns. Den skickar då själv tillbaka ett paket med grannen listad i, och den reagerar på samma sätt. På så vis skapas det som i denna rapport kallas ett grannpar eller en grannkoppling (eng. adjacencies). Nästa steg är databasutbytet. Helloprotokollet har dock ytterliggare en funktion, noderna håller regelbundet kontakten med sina grannar genom att med ett visst intervall skicka hellopaket. Den tar också emot dessa paket från sina grannar. Uteblir ett sådant paket från en granne startas ett s.k. router dead-intervall hos noden. När detta tajmas ut förklaras grannen död och grannkopplingen bryts Databasutbyten När två routrar har hittat varandra med hjälp av helloprotokollet och bildat ett grannpar, sker ett utbyte av deras LS-databaser. För att möjliggöra detta tar den ena noden rollen som master och den andra slave i kommunikationen. Noderna skickar sedan s.k. database descriptions (DBD) till varandra som innehåller headrar för samtliga LSA i databasen. Dessa behöver ofta flera paket och varje skickat paket bekräftas hos mottagaren genom att svara med ett DBD-paket innehållandes sina egna LSA-headrar, med samma sekvensnummer. Noderna mottar paketen och jämför sedan LSA-headrarna i paketen med de som finns sparade i deras egen databas. De LSAer som saknas efterfrågas av grannen med hjälp av ett s.k. link state request-paket som specificerar de saknade LSAerna. Grannen svarar med att skicka tillbaka de efterfrågade LSAerna i komplett form. Uteblivna DBD-paket återsänds med jämna intervall och det är endast noden med master status som kan göra detta [11]. Nät två noder har synkroniserat sina databaser har de skapat ett grannpar och kan därmed delta i spridningen av routinginformation. Endast de noder som är helt synkroniserade och har bildat ett grannpar kan förmedla routinginformation i OSPF. 31

32 4.4.3 Tillförlitlig kommunikation Kommunikationen i OSPF är tillförlitlig och för de flesta pakettyperna bekräftas paketen när de mottagits av destinationsnoden. Detta är en viktig funktion, eftersom OSPF körs direkt över IP och därför inte använder TCP och dess tillförlitlighet. För LSU-paket bekräftas de innehållande LSAerna med s.k. LS Ack-paket. DBD-paket bekräftas under utbytet genom att varje nytt paket skickas tillbaka med samma sekvensnummer. Även LSR-paket som skickas bekräftas genom att efterfrågade LSAer anländer i ett LSUpaket. LS Ack-paketen bekräftas däremot inte, vilken i grunden är relativt logiskt. Om Ack-paket skulle behöva bekräfta sig själva skulle kedjan av bekräftelser aldrig sluta. Hellopaketen bekräftas dock inte, men uteblivna hellopaket gör att router dead-intervallet tajmas ut. Dessutom använder helloprotokollet en sorts bekräftelse vid initialfasen då grannarna möts. Vad händer då när dessa paket som kräver olika former av bekräftelser inte får några sådana? De läggs då till i en återskickningslista där alla typer av paket som behöver återskickas placeras. Alla paket i listan skickas sedan med jämna mellanrum till sina destinationer enligt ett specifikt återskickningsintervall (oftast 5 sekunder). När något av paketen blir bekräftade tas de bort från listan och återskickas därför inte vid nästa sändning Hierarkier Som tidigare nämnts är OSPF ett internt gateway-protokoll vars interaktion begränsas inom AS. Ibland kan dock även AS bli för stora och tröghanterliga och OSPF har därför stöd för olika hierarkier inom AS: Areas, Backbone, Stub Areas och Not So Stubby Areas. Dessa hierarkier avgränsar systemen i mindre delar, vilket minskar protokollets utnyttjande av minne, processorresurser och bandbredd. Varje hierarki har egna typer av LSAer som alla beskriver delar av routingdomänen på olika sätt. Dessa delar är: området runt en router, området runt ett transitnätverk, en interarea rutt eller en extern rutt [2]. Ett område (area) är en godtycklig samling nätverk, routrar och datorer vars enda krav är att alla noder i området måste vara sammankopplade. De routrar som kopplar samman olika områden (jämför AS och gränsroutrar) kallas områdesgränsroutrar. Inom ett område fungerar OSPF precis som vanligt och noderna bygger upp en gemensam nätverksbild lokalt. Mellan områdesgränserna skickar OSPF dock inga vanliga LSAer utan områdesgränsroutrarna skapar istället speciella LSAer som sammanfattar inomformationen inom området. Denna sammanfattade LSA sprids sedan i det angränsande området med hjälp av flooding. 32

33 Backbone är ett speciellt område som fungerar som en central transportväg som alla andra områden måste vara kopplade till. Övriga områden kan fortfarande vara kopplande direkt till varandra, men de måste även ha en koppling till backbonet. Routrar inom detta område kallas för backboneroutrar och kan precis som i andra områden även i sin tur agera som områdesgränsroutrar beroende av position. På grund av Backbonets vitala funktion i AS tillhandahåller OSPF extra funktionalitet för att hantera eventuella brutna länkar inom backbonet. En sådan situation kan nämligen bara repareras manuellt av nätverksadministratorn som då skapar en virtuell länk mellan backbonets två halvor. Denna länk väljs genom det vanliga nätet och kan därför inkludera diverse smalbandslänkar. Därigenom uppmärksammar administratorn garanterat problemet och blir varse effektivitetsminskningen som en sådan lagning innebär. OSPF använder externa LSAer för att inhämta information utifrån det autonoma systemet samt sammanfattade LASer för att beskriva områden. Dessa LSAer redogör egentligen bara vilka noder som går att nå utanför AS respektive området, inte vilken väg man tar sig dit. Eftersom resten av hela Internet ligger utanför respektive AS kräver dessa kortfattade LSAer trots allt en betydande bandbredd. För att undkomma det har man infört s.k. Stub Areas som är områden med endast en områdesgränsrouter. Inom området förmedlas inga LSAer och de behövs heller inte. Istället lär sig alla routrar bara vägen till områdets enda utgång områdesgränsroutern. Alla paket som är destinerade utanför området skickas till denna router, som även fungerar som defaultrouter för övriga paket som inte har någonstans att ta vägen. Stub Areas har två naturliga begränsningar: virtuella länkar kan inte passera igenom området och området får inte innehålla en AS gränsrouter. Vidare sprids heller inga externa LSAer inom området. Ibland är begränsningarna för ett Stubby Area för hårda vilket gör det svårt att samarbeta med ett annat routingprotokoll inom området. Not So Stubby Areas (NSSA) är en kompromiss mellan ett Stubby Area och ett vanligt OSPF Area. Externa LSAer sprids inte inom en NSSA utan istället har dessa egna NSSA LSAer som sprids inom området. 33

34 4.4.5 LSA-livscykel Alla LSAer har en ålder som startar från 0 och ökas med 1 för varje sekund de befinner sig i link state-databasen samt för varje hopp LSU-paketen gör. Åldern ökas upp till en fördefinierad maxålder (oftast 1 timme) och betraktas sedan som för gamla. För att förhindra att de blir för gamla förnyar man kontinuerligt LSAerna i routrarnas databaser genom att flooda en LSA-uppdatering med ett nytt sekvensnummer och åldern satt till 0. Det är den router som själv skapade LSAn som initierar uppdatering och den sker vanligtvis varje halvtimme. Genom att göra detta uppdateras LSAn simultant i alla routrar vilket gör dem synkroniserade. Teoretiskt sätt borde LSAn gå ut samtidigt i alla routrar, men i verkligheten går routrarnas klockor olika fort och man använder därför flooding för att synkronisera dem. Under denna process tar routrarna emot den nya LSAn och uppdaterar åldern på sina egen, därefter beslutar den om den ska flooda den vidare eller inte. Är ålderskillnaden tillräckligt stor, dvs. större än ett definierat värde (oftast 15 min), ska den floodas LSA-stormar Stora nätverk som använder OSPF måste emellanåt hantera en mer eller mindre simultan uppdatering av ett stort antal LSAer. Denna händelse då nätverket måste hantera en överdos av LSAer kallas för en LSA-storm eller allmänt för en routingstorm. Den kan startas av ett oplanerat fel eller av ett schemalagt underhållsarbete. I [12] presenteras följande konkreta exempel: Länkfel: trasiga, glappiga kablar eller trådlösa länkar. Routerfel: en eller flera routrar som kraschar samtidigt pga. problem med strömförsörjningen. Länk/router-flapping: en router växlar mellan flera rutter till samma destination. Mjuk-/hårdvaruuppgraderingar: en administrator behöver ta ner flera routrar och sedan sätta upp dem igen. Uppdatering av LSAer: antingen genom det periodiska sekundersintervallet eller vid byte av mjukvaruversion. Externa LSAer: importering av ett stort antal externa LSAer pga. av att de LSAer som finns i nätet är felaktiga. Ändring av router-id: ett stort antal LSAer måste återskapas. 34

35 Dessa mer eller mindre synkrona uppdateringar av LSAer är arbetsamma för routrarna som måste använda mycket processorkraft och minne för att hantera dem. Beroende på orsaken måste LSAer eventuellt genereras, floodas i nätet samt uppdateras i den interna databasen. Ändringar i databasen kräver nya beräkningar av rutter med hjälp av Dijkstras algoritm. Detta belastar CPUn och medför att inkommande paket blir fördröjda eller t.o.m. bortkastade. Försenade eller bortkastade ack (längre än återsändningsintervallet) gör att LSAerna måste återskickas. Försenade hellopaket (längre än router dead-intervallet) resulterar i att routrar förklaras döda. Ytterliggare LSAer måste skapas och detta tillsammans med diverse återsändningar kräver ännu mer processorkraft och minne. En negativ spiral har skapats som kan tenderar att eskalera och i värsta fall göra nätverket instabilt. 4.5 Distance Vector Routing Distance vector-routing använder sig utav en annan metod än link staterouting för att bygga upp routrarnas nätverkskartor. I link state-algoritmer sprider routrarna endast dess grannars identitet, men de skickar dem till alla noder i nätverket. Distance vector-algoritmer fungerar tvärt om. Routrarna delar bara information med sina grannar, men de skickar istället hela dess bild av nätverket. När en router lär sig något av en granne sparas informationen och vart den har lärt sig det ifrån, för att i sin tur förmedlas vidare till nästa granne. Eftersom det som förmedlas hela tiden är varje routers kompletta nätverksbild, propagerar informationen långsamt genom hela nätverket. Links state-routing använder hellopaket för att lära känna sina grannars identitet. Distance vector-algoritmer behöver inte detta utan nöjer sig med att känna till dess grannars nätverksprefix. Eftersom grannar per definition måste dela en länk emellan sig, delar de även ett nätverksprefix. Det första steget i algoritmen är att alla noder simultant skickar ut sin routinginformation till sina grannar. Till en början består detta av dess länkars IP-prefix samt kostnaden för att passera länkarna. De flesta distance vector-protokoll mäter kostnad genom antalet hopp som krävs från källa till destination. För att nå sina egna länkar är alltså kostnaden 1. När noderna sedan får informationen från sina grannar kan de utnyttja dessa för att hitta nya destinationer i nätet. Om en nods direkta granne kan nå en viss destination på n stycken hopp, kan följaktligen noden nå samma destination på n+1 hopp genom att förmedla paketen via denna granne. Grannen läggs till i routingtabellen som ett s.k. next hop för att kunna nå destinationen. En nod kan genom sina grannar få förslag på flera rutter till samma destination och väljer då att spara den rutt med lägst kostnad. 35

36 Distance vector-protokoll använder periodiska uppdateringar då noderna regelbundet skickar sin information till grannarna. Noder kommer alltså återigen att utbyta information om rutter och lära sig nya vägar genom nätet. För att nå destinationer längre bort än sina grannar, kommer man alltid att använda sitt nästa hopp i routingtabellen. Noderna länkas på så vis tillsammans och en rutt byggs upp genom att följa nästa hopp tills man är framme vid destinationen. Långsamt byggs en bild upp av nätet och slutligen kan alla destinationer hittas. Distance vector-routing reagerar relativt långsamt på förändringar i nätverket. Detta beror på att man inte utbyter hellopaket (vilket görs i t.ex. OSPF) för att kontrollera hälsan på sina grannar. Istället får vanliga routinguppdateringar sköta den uppgiften. När noder skickar uppdateringar till varandra i distance vector-protokoll är dessa bara giltiga en begränsad tid. De måste hela tiden bekräfta för varandra att informationen är giltig och det är därför man använder periodiska uppdateringar. Om en router slutar fungera och inte skickar ut några uppdateringar kommer den att tajmas ut av grannarna. De räknar då om sina rutter baserat på den information de har och väljer vägar runt den trasiga routern. För att slippa vänta ut icke-fungerande noder och länkar använder man s.k. triggade uppdateringar. Om en länk går ner skickar angränsande noder genast ut information om detta på sina fungerande länkar. Detta görs genom att sätta antalet hopp för att nå länken till oändligt. Alla länkar som nås via den trasiga länken sätt också till oändligheten. Den största begränsningen med distance vector-protokoll är problemet med det s.k. counting to infinity. Problemet kan uppstå när en router slutat fungera och två andra noder inte har uppfattat förändringen. Routrarna uppdaterar varandra med felaktig information och tror hela tiden att de kan nå den trasiga routern via sin granne. Kostnaden för vägen dit ökar hela tiden med 1 tills oändligheten. Detta medför att oändligheten måste väljas till ett lågt nummer (16 för RIP) för att man inte ska behöva vänta för länge. Ingen ruttkostnad i nätet får därför överstiga denna siffra vilket kraftigt begränsar nätets maximala storlek [2]. 4.6 RIP RIP (Routing Information Protocol) är ett gammalt protokoll vars algoritm dateras tillbaka till 1960-talet. Trots detta används RIP än idag och är ett utmärkt exempel på ett protokoll av typen distance vector. Denna teknik har beskrivits relativt uttömmande i föregående kapitel och därför nämns endast specifik funktionalitet för RIP här. För att undvika problemet med counting to infinity använder RIP en teknik som kallas split horizon. Denna gör att routrar är mer noggranna med vilka de skickar sina uppdateringar till. Den regel som används är ganska enkel: om en nod lär sig en rutt från en uppdatering mottagen på ett visst gränssnitt, skickar den inte tillbaks denna rutt i sina uppdateringar på samma gränssnitt. 36

37 4.7 Redistribution Efter att man har studerat de olika routingprotokollen och dess tekniker borde man kunna dra några slutsatser om vilket protokoll som är bäst? Vissa protokoll börja bli gamla och nya förfinade versioner har dykt upp. Algoritmerna och teknikerna har förbättrats för att kompensera tidigare brister etc. Trots detta kan man inte utse någon konkret vinnare. De moderna routingprotokollen (t.ex. OSPF och EIGRP) är mer sofistikerade och moderna än tidigare enkla protokoll som exempelvis RIP. Det medför även att protokollen får olika användningsområden. Ibland har man ett okomplicerat nät som ska vara lätt att konfigurera, vars topologi är enkel och förblir relativt oförändrad. I andra fall behöver man allt det stöd som finns för att hantera föränderliga stora nät med policies m.m. Olika routingprotokoll används alltså för olika typer av nätverk och användningsområden. Utöver detta stödjer routrar från olika tillverkare olika protokoll. De autonoma systemen som Internet är uppdelat i nyttjar således flera protokoll. För alla miljöer med multipla routingprotokoll används s.k. redistribution för att de inblandade protokollen ska kunna kommunicera med varandra. Redistribution innebär att ett routingprotokoll förmedlar vidare rutter internt som det lärt sig utifrån, oftast från ett annat routingprotokoll eller från statiska och direktkopplade rutter. Det största problemet när två routingprotokoll ska kommunicera med varandra är hur de ska jämföra sina vikter (metrics) för de olika rutterna. Problemet dyker upp då båda protokollen har en hittat en väg till samma destination och den bästa ska väljas. Vissa protokoll mäter antalet hopp från källa till destination, andra väger ihop information om bandbredd, fördröjning mm. Dessa mätvärden är helt inkompatibla och man tar därför hjälp av s.k. administrativa avstånd [15]. Funktionen med administrativa avstånd är att definiera trovärdigheten hos ett routingprotokoll. Varje protokoll är prioriterat enligt en viss ordning från mest till minst trovärdigt med hjälp av administrativa avståndsvärden. Det finns fördefinierade sådana värden för de flesta protokoll. Om två protokoll hittar till samma nod används rutten från det protokoll som har lägst administrativt avståndsvärde och därmed är trovärdigast [16]. Denna rutt läggs då in i IP-forwardingtabellen och blir den slutliga rutten till destinationen. 4.8 Routinglösningar i TS/TI Tack vare den nya IP-strukturen som Taktiskt Internet medfört, kan routingen i nätet ske med de två vanligt förekommande protokollen OSPF och RIP. Routing måste konfigureras och anpassas till det aktuella nätet och i detta fall har nätverket flera relativt speciella egenskaper. Några viktiga punkter är: Semimobilt 37

38 Varierande topologier Trådlös kommunikation Begränsad bandbredd Stora nät förekommer Ett nätverks storlek är ofta en avgörande faktor för hur väl ett routingprotokoll fungerar. I TS/TI-nät kan relativt stora nät förekomma vilket ställer högra krav på routingen. OSPF har ett bra stöd för att dela in större nät i olika hierarkier vilket underlättar arbetet. Anledningen till att man inte endast använder OSPF i TS/TI-nätverk och på så vis delar in nätet, är att de inte fullt ut uppfyller de krav som OSPF ställer. I Cisco-implementationerna av OSPF måste samtliga områden vara sammankopplade med ett backbone på något vis. I TS/TI-nät skulle man kunna tänka sig stamnätet som ett backbone och abonnentnäten som olika områden kopplade till stamnätet. Skillnaden är dock att man vill kunna koppla ihop två eller flera abonnentnät även om dessa har förlorat täckningen till stamnätet. De har fortfarande behov att kommunicera med varandra. Detta går inte att lösa med OSPF och man har därför tagit hjälp av RIP. Man låter alla abonnentnät och stamnätet vara enskilda OSPFbackbonenät som fungerar som helt separata nät. Abonnentnäten kopplar sig till stamnätet via RIP, dvs. RIP sköter kommunikationen endast mellan gränsroutrarna. Routinginformationen redistribueras sedan mellan de två protokollen vilket gör att en helhetslösning kan skapas. Noderna i abonnentnäten har ingen information om stamnätet utan når bara dit via en förvald rutt. Noderna i stamnätet bygger dock upp routingtabeller till samtliga noder i alla nät. Eftersom man på förhand inte kan säga vilka noder som kommer att behöva agera som gränsroutrar, måste samtliga noder kunna använda både RIP och OSPF på sina gränssnitt [7]. 38

39 För att få en avgränsad nätstruktur måste man göra flera speciallösningar. Eftersom de separata OSPF-näten trots allt kopplas ihop via gränsroutrarna, finns det inget som begränsar dem att direkt kommunicera med varandra. De är alla av samma typ backbonenät vilket gör att de faktiskt kommer att kommunicera med varandra som om det var ett enda stort backbonenät. Den ursprungliga uppdelningen av nätverket går förlorad och man får ett alldeles för stort sammanslaget nät precis som från början. För att lösa problemet används OSPF:s inbyggda lösenordsskydd. Det är nämligen möjligt att sätta ett lösenord på all routinginformation som därigenom bara kan användas av routrar som kan motsvarande lösenord. Funktionen har skapats för att öka säkerheten och göra det svårt för utomstående obehöriga routrar att kommunicera i nätet. De kan inte läsa den skyddade informationen och de tillbehöriga routrarna lyssnar inte heller på information som inte kommer med rätt lösenord. Resultatet blir att routrarna inte alls kommunicerar med varandra. I TS/TInätverk är detta precis vad man vill uppnå med OSPF-kommunikationen mellan abonnentnät och stamnät. Man vill inte att gränsroutrarna ska tala med varandra utan låter istället RIP sköta den kommunikationen. Därför har man låtit lösenordskydda det ena nätet med det symboliska lösenordet abc, inte utav säkerhetsskäl utan för att möjliggöra en avgränsning av näten. 39

40 5 Modellering och simulering Detta kapitel redogör för den nätverksmodell som byggts under examensarbetet, dess scenarier och tillhörande simuleringar och resultat. 5.1 Nätverksmodellen Det modellerade nätverket består av ett stamnät med tre tillkopplade abonnentnät. Stamnätet består av 35 routrar med tillhörande televäxlar och abonnentnäten består av sammanlagt 7 routrar med televäxlar. Alla abonnentroutrar är kopplade till varsitt LAN. Av de 35 routrarna i stamnätet är 14 stycken kopplade till varsitt LAN. Hela nätverket visas i Appendix A. Nätverket är av typen Point-to-Multipoint och routrarna kretskopplas till alla sina grannar med hjälp av PVC:er. Eftersom alla noder i nätverket inte är direkt kopplade till varandra kan OSPF inte använda designated router-konceptet. Alla LSAer som skapas i nätverket blir därmed av typen router LSAer eller externa LSAer som redistribuerats in från abonnentnät. Router links LSAerna innehåller länkar av typen point-to-point, som går över PVC:erna till respektive grannroutrar, och dessutom länkar av typen stub network till sig själva och till ett eventuellt tillkopplat LAN. Tabell 2 visar de värden som använts för de olika OSPF-intervallen under simuleringarna. Dessa är alla satta till de vanliga standardvärdena. Tabell 2: Inställningar som använts för OSPF-intervall OSPF-intervall Tid (s) Hello 10 Router dead 40 Retransmition 5 LS refresh 1800 LS max age 3600 LS max age diff. 900 Transmission delay 1 40

41 Det finns ett antal olika länktyper modellerade för TS/TI och de vanligaste visas i Tabell 3. Mellan routrarna och dess televäxlar används ett seriellt v.36-gränssnitt med två olika hastigheter beroende på om det kopplas till en KP eller AP. De routrarna som har ett tillkopplat LAN använder Ethernet med Tbase10-länkar. Slutligen används seriella trunklänkar mellan televäxlarna. De finns i tre olika hastigheter. I nätverksmodellen används endast hastigheterna 76,8 kbit/s för trunklänkar i de olika näten samt 307,2 kbit/s för gränsteleväxlar mellan näten. Samma hastighet på länkarna har valts för att göra det lättare att tyda grafen i Appendix A över nätverkets belastning. De snabbare länkarna mellan näten har valts för att motverka flaskhalsar. Både trunk-, v.36- och Ethernetlänkarna är full duplex, vilket gör det möjligt att skicka data i båda riktningar med angiven hastighet. Det är viktigt att notera att trunklänkarna är flaskhalsar i nätverksmodellen. Tabell 3: De vanligaste länktyperna i TS/TI och deras överföringshastigheter Gränssnitt Trunk Hastighet (kbit/s) 307,2 153,6 76,8 Ethernet v (KP+SPL) 256 (AP) Statistikförklaring Egenutvecklade statistiktyper har alla samlats in enligt samma metod och handlar om OSPF-interna händelser. De presenterar alltid ett antal av ett visst mätvärde mot tiden och är generellt sett diskreta. Värdena adderas till respektive statistik under simuleringens gång, vilket gör att dessa mätvärden hela tiden är den totala summan hittills vid en viss tidpunkt. Man kan därmed läsa av det totala antalet mot y-axeln vid angiven tid på x-axeln. För att kunna bedöma eventuella ökningar eller minskningar måste man beakta linjens (eller punkternas) lutning. Ökad lutning innebär en förhöjd insamlingstakt av statistikdata. 41

42 5.2 Scenario Topologiförändringar TS/TI-nätverk är semimobila och förändrar sin topologi efter stridens eller övningens gång. Anslutningspunkter och Knutpunkter förflyttar sig vartefter till nya platser. I och med dessa återkommande förändringar i nätverkstopologin påverkas även konnektiviteten. Noder kommer utom räckvidd för varandra och tappar kontakten, återfinner varandra igen eller omgrupperar sig. Den trådlösa kommunikationen har sina begränsningar och dessa varierar med miljön den används i. Räckvidden beror bl.a. av vilken höjd sändare/mottagare är placerade på samt vad som befinner sig emellan dem. Förutsättningarna varierar från gång till gång vilket gör dem svåra att förutspå Routingreaktioner Både abonnentnäten och stamnätet använder OSPF som routingprotokoll. Frågan är hur OSPF reagerar när routrar förlorar kontakten med varandra? I vanliga fall skulle OSPF känna av huruvida en grannrouter verkligen är död, dvs. ur funktion, eller om den bara förlorat kontakten med den. Att förlora kontakten innebär att den trådlösa länken mellan dem bryts. Om en länk felar förstår protokollet att det inte kan nå andra sidan och dödsförklarar inte själva grannroutern. I TS/TI-fallet är routrarna inte direkt kopplade till varandra utan de kretskopplas via televäxlar. Televäxlarna finns i KP och AP och kopplar ihop läger trådlöst, routrarna däremot är anslutna lokalt till televäxlarna via kabel. Det är inte routrarna som rör sig utom räckhåll utan knutpunkter och anslutningspunkter med deras televäxlar som måste förflyttas efter hand. Eftersom det är länkarna mellan dem som felar känner inte routrarna av det på sina gränssnitt, eftersom deras egen länk till televäxeln är intakt. På så vis dödförklaras alltid icke-nåbara routrar inom TS/TI-nät. Gränsroutrarna mellan abonnentnät och stamnät reagerar annorlunda om deras länk går ner. Dessa använder RIP som inte bildar några grannpar och därför förekommer heller inga dödförklaringar av routrarna Modellering av förändringar I de framarbetade modellerna av TS/TI används vanliga kabellänkar för att simulera de trådlösa länkarna mellan noderna. Man har nämligen inget behov av att modellera de relativt komplicerade egenskaperna hos trådlösa länkar. Dessa länkar har i verkligheten en adaptiv signalstyrka som kompenserar för diverse störningar i omgivningen. Inom signalens räckvidd har man alltså en mer eller mindre konstant mottagning tack vare att sändaren anpassar sig. På så vis får man tillgång till en konstant bandbredd och det är därför som vanliga länkar går att använda i modellen [8]. 42

43 För att simulera rörelserna i TS/TI-nätverken måste man skapa sig en uppfattning om hur noderna rör sig. Nätet kan användas i helt olika miljöer, på olika platser och vid olika situationer. Det är upp till ledaren att använda ledningssystemet på bästa sätt från gång till gång. Det har därför varit svårt att förutse rörelsemönstret för ett helt generellt användningstillfälle. Följande antaganden har gjorts: Noderna rör sig och pausar om vartannat. Pauserna är minst ca ett dygn, förflyttningen minst några timmar. Noderna grupperar sig för att kunna kommunicera. Antagandena bygger på att noderna ofta förflyttar sig under strid, det tar tid att packa ner/upp och att flytta sig samt att noderna vill befinna sig tillräckligt nära varandra för att kunna kommunicera. Det antas att man minst stannar ett dygn, säkerligen längre, och att det tar minst några timmar att förflytta sig. Detta ger en vag bild av hur ofta noder kan tappa kontakt med varandra, men därtill kommer ytterliggare en avgörande möjlighet. Om en nod befinner sig på gränsen för en signals räckvidd, kan man tänka sig att mottagning varierar något, vilket gör att noden hela tiden kopplas på/av. Sett ur detta perspektiv kan länkfel uppstå ofta och nodernas allmänna rörelsemönster får mindre betydelse. Att simulera rörelserna i ett TS/TInätverk genom att flytta noderna enligt ett rörelseschema skulle innebära mycket arbete. Utan ett givet verkligt rörelseschema anses detta onödigt eftersom resultaten ändå bygger på approximationer. OPNET Modeler har en inbyggd funktion för att stänga av/återhämta länkar. Denna har använts för att modellera förändringarna i topologin. Genom att stänga av en televäxels länkar till sina grannar kan man simulera att televäxeln har tappat kontakten med dem. Återhämtar man länken simulerar det i sin tur att man fått kontakt igen. Under simuleringsperioden har 10 godtyckligt utvalda länkar valts att stängas av och återhämtas för att efterlikna verklighetens täckningsproblem. Ett avstängningsintervall på 50 har valts för samtliga trunklänkar, innan de åter sätts i bruk. Detta är tillräckligt för att generera router dead vilket påverkar protokollets interna funktioner. 43

44 5.2.4 Resultat Figur 7: Statistik över hur OSPF reagerar internt på topologiförändringar. 44

45 Figur 8: Specificerade tider för avstängning och påsättning av länkar. Varje rad beskriver en länk och dess status fr.o.m. angiven tid. Figur 9: Konvergensaktivitet för OSPF som beror av den förändrade topologin. 1 visar på aktivitet och 0 betyder att protokollet har konvergerat. 45

46 5.3 Scenario 2 I scenario 2 undersöks hur routingen påverkas i nätverket när det belastas av trafik. Genom att köra tre simuleringar med olika mycket trafikbelastning kan man se olika tendenser i och med trafikökningen. Trafiken som ska modelleras behöver ingen specifik karaktär, utan den ska bara ha funktionen som en belastning. Bakgrundstrafik borde därför vara lämpligt att använda eftersom den också går snabbare att simulera. Tyvärr fungerar inte bakgrundstrafik för den här typen av kretskopplad trafik och den interagerar heller inte med routingtrafiken. Därför har trafiken trots allt modellerats helt explicit för att noggrant få med alla steg på alla nivåer i protokollstacken. Trafikprofilen är ett konstant dataflöde på 100 kbit/s, som startar efter 260 sekunder och fortsätter till simuleringens slut. Datamängden är vald så att den understiger länkarnas hastigheter med marginal, samtidigt som den kan skapa trafikstockningar vid trafikerade länkar. 5 stycken par av noder har valts ut och inom paren skickar båda noderna trafik till varandra med den angivna profilen. Nodparen är utvalda för att trafiken ska belasta så stora delar av nätverket som möjligt. Trafiken går därför mellan olika LAN tvärs genom hela stamnätet och varje abonnentnät har minst ett sådant LAN. Därigenom belastas större delen av nätet och interaktionen mellan subnät sätts också på prov. Trafikflöden mellan nodpar visas som ljusgrå pilar tvär över nätverket i Appendix A. Tre simuleringar har gjorts med exakt samma förutsättningar så när som på mängden trafik. Samma källor och destinationer har används, men trafiken har skalats upp vartefter. Första simuleringen använder trafikprofilens grundläge kbit/s, andra simuleringen använder 150 kbit/s och tredje 200 kbit/s. En ökning på 50 respektive 100 procent undersöks alltså för att kunna se eventuella tendenser. 46

47 5.3.1 Resultat Figur 10: Förändringar i grannpar för respektive trafikbelastning. Figur 11: Antalet återskickningar för olika trafikbelastningar. 47

48 Figur 12: Konvergensaktivitet för OSPF för respektive trafikprofil. 1 visar på aktivitet och 0 betyder att protokollet har konvergerat. Tabell 4: End-to-End-delay för trafik mellan nodpar för olika trafiktyper Trafiktyp End-to-End-delay (s) Grundtrafik % ökning % ökning Scenario 3 I detta scenario ska vi undersöka om modellerna kan frambringa LSAstormar. Tanken var att skapa ett worst case -scenario med avseende på länkförändringar och trafikflöden som undersökts i tidigare scenarier. Dessa är två betydande faktorer för att LSA-stormar ska uppstå i TS/TInätverk, men det finns givetvis andra faktorer som också påverkar som t.ex. nätets storlek. Detta scenario skulle i alla fall ge indikation på om det i TS/TI-modellerna kan uppstå sådana stormar i nätverk av den här storleken. Om de inte uppstår under ett worst case -förhållande, bör de inte kunna uppstå alls. Resultaten från simuleringarna i scenario 1 och 2 gav dock resultat som redan på förhand bekräftar att det i TS/TI-modellen inte kan uppstå LSA-stormar. Fler simuleringar är därför överflödiga. 48