Modelarea Retelelor de Comunicatii Prin Simulare. Analiza Statistica a Rezultatelor Simularii

CAPITOLUL I

INTRODUCERE ÎN MODELAREA REȚELELOR DE COMUNICAȚII

1.1. Considerații tehnico – tactice

Se poate observa pe zi ce trece, o dependență tot mai mare a tuturor tipurilor de companii, de sistemele de calcul și de rețelele de comunicații. Pe măsură ce aceste rețele devin mai mari și mai complexe, proiectarea și managementul acestora devine o sarcină tot mai provocatoare. Calculul pe hârtie, cu creionul nu mai reprezintă o bază pentru validarea proiectării unei rețele de milioane de dolari. Tabelele de calcul atent elaborate nu mai fac față din cauza naturii stocastice a traficului și a complexității sistemului în ansamblu. Sunt introduse permanent noi tehnologii și sunt explorate în mod constant noi aplicații pentru rețelele de calcul și comunicații.

Cum decid organizațiile ce combinații de tehnologii și aplicații sunt potrivite pentru ele? Pe măsură ce cresc nevoile, cresc și investițiile și costurile de funcționare necesare. Pe măsură ce organizațiile se bazează tot mai mult pe propriile rețele să suporte operațiile vitale afacerilor, riscul defectării din cauza performanțelor deficitare ale rețelei poate avea repercusiuni grave. Cum pot fi estimate aceste alternative într-un stadiu incipient și cum poate fi adaptată proiectarea rețelei astfel încât să se minimizeze riscul?

Proiectanții de sisteme și planificatorii de rețele caută tot mai des instrumente ajutătoare pentru a-i sprijini în decizia asupra sistemului optim. Ei se folosesc de aceste instrumente pentru a-și susține cauza în fața clienților și a managerilor.

Studiul sistemelor de comunicații nu este posibil în condiții reale de funcționare decât în foarte rare ocazii, chiar și dacă sistemele există. Același fenomen se prezintă identic pentru oricare altă categorie de sisteme. De aceea este absolut necesară reprezentarea funcționării sistemelor prin mijloace matematice sau descriptive, mijloace care să permită aproximarea cât mai corectă a realității. Se realizează astfel un model al sistemului, într-un proces de modelare atât a caracteristicilor fizice, cât și a operațiilor pe care le execută.

Cum majoritatea sistemelor ce compun rețelele actuale de comunicații sunt deosebit de complexe, modelarea lor globală este de-a dreptul imposibil de realizat. Se recurge în consecință la descompunerea sistemelor în blocuri componente (subsisteme), entități bine determinate funcțional care sunt modelate prin mijloace cunoscute, fiind mult mai simple decât sistemul global.

Modelarea poate fi utilizată pentru sistemele existente, deci în faza de exploatare operațională, pentru evaluarea și eventual îmbunătățirea performanțelor acestora, dar și în faza de concepție a unor sisteme noi. Modelul folosit este întotdeauna o reprezentare simbolică, o abstractizare a sistemului în cauză. Abstractizarea se realizează într-un mod convenabil prin raportarea la anumiți parametri și/sau anumite caracteristici funcționale ale sistemului.

Firme specializate furnizează instrumente de modelare și analiză tocmai pentru aceste scopuri. Un model poate fi folosit pentru estimarea diferitelor alternative de proiectare sau de operare. Analistul poate explora comportamentul unui sistem dat, practic fără să-l construiască. Ar fi total nepractic, costisitor sau chiar imposibil să construiești trei alternative, să o alegi pe cea mai bună iar pe celelalte să le arunci. Alternativ, modificările planificate pentru un sistem existent pot fi testate prin simulare fără perturbarea rețelei actuale.

1.2. Procesul de modelare. Generalități.

În procesul de modelare a oricărui sistem se parcurg obligatoriu următoarele etape succesive:

1. Stabilirea modelului care să înlocuiască sistemul real sau cel ce urmează a fi proiectat. Modelul unui sistem este o abstractizare pentru care sunt reținute cele mai reprezentative caracteristici al sale, aprecierea făcându-se în raport cu scopul urmărit. Orice model este realizat ca un ansamblu de resurse materiale și logice, abordabile prin funcțiile ce le revin. Cum resursele sunt întotdeauna în număr finit, accesul clienților la ele implică probleme de concurență, ce pot fi eventual rezolvate prin utilizarea șirurilor de așteptare.

2. Rezolvarea modelului cu ajutorul unor metode analitice sau prin simularea funcționării, în vederea estimării performanțelor sistemului. Urmând de exemplu procedurile clasice ale șirurilor de așteptare pot fi evaluate mărimile parametrilor pentru modelul ales: rata de utilizare a resurselor, timpul de așteptare în șir, lungimea șirului de așteptare, timpul total de staționare în sistem, etc. În această etapă, pentru ușurarea calculelor, se pot considera unele ipoteze simplificatoare. O asemenea ipoteză este de exemplu independența resurselor componente ale unui sistem, dar ea nu este perfect conformă cu realitatea, mai ales dacă ne gândim la sincronismul funcționării unor componente informatice. Simularea se impune a fi folosită ca metodă de rezolvare a modelului, deoarece metodele matematice curente nu pot considera prin mijloace obișnuite orice problemă. Tehnica modernă face posibilă astăzi utilizarea simulării în condiții de cost suficient de avantajoase.

3. Analiza rezultatelor obținute. Dimensionarea sistemului se face utilizând rezultatele măsurătorilor efectuate prin intermediul diferitelor scenarii și modificând apoi după necesități, anumite elemente ale modelului. În această fază de studiu se pot identifica diferiți factori deosebit de sensibili, care afectează în mod hotărâtor comportamentul sistemului. Asupra lor va trebui să se intervină în primul rând pentru a se dirija în sensul dorit comportamentul sistemului.

În funcție de evaluarea ce se urmărește a fi realizată trebuie să se utilizeze procese diferite de optimizare, astfel încât să se obțină parametrii de intrare ai sistemului care dau cele mai bune performanțe, în limitele restricțiilor impuse. Este evident că validarea modelului este indispensabilă și cere uneori revizuirea modelului însuși sau chiar modificarea ipotezelor de funcționare a sistemului în ansamblul său.

Etapele succesive în care se derulează un proces de modelare sunt prezentate sintetic în Fig.1.1.

Este evident că evaluarea globală descrisă conduce la observații aproximative ale comportamentului sistemului, datorită faptului că în fiecare fază a procesului este introdusă o eroare. Se pare că până în prezent nu există vreo metodologie care să permită trecerea directă de la sistem la model. Eroarea E1 ce apare în prima fază este greu de măsurat și depinde de gradul de detaliere al modelului. Se poate afirma că absența mecanismelor de descriere nu poate decât să accentueze această eroare. Eroarea E2 introdusă în faza de rezolvare a modelului depinde de tehnicile folosite la rezolvare: ea este nulă în cazul folosirii metodelor exacte și variabilă în cazul simulărilor, cu valori ce pot fi neglijabile sau foarte importante, în raport cu gradul de aproximare utilizat.

1.3. Desfășurarea unui studiu de modelare.

1.3.1. Avantajele modelării cu șiruri de așteptare

Modelele în general și modelele cu șiruri de așteptare (mai pe scurt, modele cu așteptare) în particular au devenit instrumente importante în proiectarea și analiza sistemelor de comunicații. Aceasta se datorează faptului că pentru multe aplicații, modelele cu așteptare reușesc să realizeze un compromis între acuratețe și eficiență.

În privința acurateții, din numeroasele experiențe în domeniu, s-a constatat că de la modelele cu așteptare se poate obține o acuratețe de 5-10% pentru utilizarea resurselor și trafic și 10-30% pentru timpii de răspuns. Nivelul de acuratețe răspunde cerințelor unei game largi de aplicații de proiectare și analiză.

În ceea ce privește eficiența, modelele cu așteptare se pot defini, parametriza și evalua cu un cost relativ scăzut. Definirea este ușurată de corespondența strânsă între atributele modelelor cu așteptare și atributele sistemelor de comunicații. Parametrizarea este de asemenea ușurată de numărul mic de parametri de nivel relativ înalt.

1.3.2. Principiile desfășurării unui studiu de modelare.

În această secțiune este prezentat modul de aplicare al metodologiei generale a modelării cu șiruri de așteptare.

Succesul acestui tip de abordare se bazează pe faptul că detaliile de profunzime ale unui sistem sunt într-o mare măsură irelevante pentru caracteristicile generale de performanță ale sistemului. Filozofia de bază este de a începe cu identificarea principalelor componente ale unui sistem și modul în care ele interacționează și apoi furnizarea acelor detalii ce se dovedesc necesare. Această filozofie înseamnă că vor fi introduse și estimate numeroase presupuneri în procesul de conducere a unui studiu de modelare. Aceste presupuneri sunt motivate de trei considerații principale:

Simplitate

Prima grijă este eliminarea detaliilor irelevante. De fapt, este adoptată o definiție mai degrabă liberală a termenului "irelevant" în acest context, incluzând în general orice caracteristică a sistemului care nu va avea un "efect principal (primar)" asupra rezultatelor studiului. De exemplu, deși un sistem poate avea un număr mare de surse de încărcare identificabile, putem fi interesați de performanțele numai ale unora dintre ele. Putem alege în această situație construirea unui model cu două clase de încărcare, una reprezentând componenta de încărcare de interes iar cealaltă efectul agregat al tuturor celorlalte componente.

Suficiența măsurătorilor

Instrumentele de măsurare disponibile pentru sistemele de comunicații nu oferă întotdeauna direct cantitățile necesare parametrizării modelului care necesită un număr redus de parametri de intrare aleși cu grijă. Instrumentele de măsurare furnizează un volum mare de date care necesită o interpretare atentă din partea analistului. De exemplu, un procent semnificativ a activității procesorului nu este atribuită unor componente de încărcare specifice. Din moment ce procesorul tinde să fie o resursă intens utilizată, atribuirea corectă a folosirii sale este importantă pentru acuratețea unui model cu clase multiple de utilizatori.

Ușurința evaluării

Este necesară limitarea la un set de parametri ce pot fi evaluați eficient. Pentru a ne menține în acest set trebuie făcute anumite compromisuri în reprezentarea anumitor caracteristici ale sistemului.

Cheia realizării cu succes a unui studiu de modelare este priceperea în introducerea și evaluarea presupunerilor. În general, este importantă explicitarea acestora, motivația pentru introducerea lor și argumentele pentru care pot fi considerate plauzibile. Aceasta permite examinarea raționamentului analistului și facilitează evaluarea sensibilității rezulatelor la presupunerile făcute.

1.4. Algoritm de modelare. Schemă de modelare

Cea mai utilizată aplicație este evaluarea efectului schimbării în încărcarea sau configurația unui sistem asupra performanțelor acestuia. Asemenea studiu presupune trei etape. În etapa de validare, este construit un model de bază al sistemului existent și este stabilită suficiența acestuia. În etapa de evaluare, acest model este folosit pentru predicția efectului modificărilor anticipate asupra performanțelor. În etapa de verificare, performanța reală a sistemului este comparată cu evaluările modelului. Luate împreună, aceste trei etape sunt denumite algoritmul (ciclul) de modelare a cărui schemă este ilustrată în Fig. 1.2.

Faza de validare începe cu definirea modelului, care include selectarea acelor resurse ale sistemului și componente de încărcare care vor fi reprezentate, identificarea oricăror caracteristici ale sistemului ce pot necesita o atenție specială, alegerea structurii modelului și procedurile de obținere a parametrilor necesari din datele disponibile din măsurători. Apoi, sistemul este măsurat pentru a se obține măsurători de încărcare, din care se vor calcula datele de intrare ale modelului și măsurători de performanță, care vor fi comparate cu datele de ieșire ale modelului.

Măsurătorile de îneșire ale modelului.

Măsurătorile de încărcare sunt folosite apoi pentru parametrizarea modelului, un pas ce poate necesita diferite transformări. Modelul este evaluat, rezultând datele de ieșire. Acestea sunt comparate cu măsurătorile de performanță ale sistemului. Discrepanțele indică fisuri ale procesului precum caracteristici ce au fost ignorate sau reprezentate inadecvat sau date de intrare ale modelului ale căror valori au fost stabilite incorect. Din nefericire, absența discrepanțelor nu garantează că modelul va prezice corect efectul modificărilor de încărcare sau de structură ale sistemului.

Încrederea în capacitățile predictive ale modelului ar trebui să vină din două surse. Prima este validarea repetată pentru un număr de intervale de măsurare, incluzând modificările selectate. De exemplu, dacă obiectivul modelării este evaluarea efectelor unei memorii suplimentare, poate fi posibilă repetarea fazei de validare în timp ce diferite volume de memorie existentă sunt dezactivate. A doua sursă de stabilire a încrederii este finalizarea fazei de validare.

În faza de evaluare, datele de intrare ale modelului sunt modificate pentru a reflecta schimbările anticipate ale structurii sau încărcării sistemului. Acesta este un proces complex care necesită o atenție considerabilă. Modelul este apoi evaluat. Diferența dintre datele de ieșire ale modelului modificat și cele ale modelului original este proiecția efectului modificării.

În final, în faza de verificare, sistemul modificat este măsurat și sunt efectuate două comparații. În prima, măsurătorile sale de performanță sunt comparate cu datele de ieșire ale modelului. În a doua, măsurătorile de încărcare sunt comparate cu datele de intrare ale modelului. Discrepanțele dintre proiecțiile modelului și performanțele sistemului pot proveni din două surse: omiterea sau reprezentarea greșită a unor caracteristici semnificative ale sistemului și evoluția sistemului într-o direcție diferită de cea anticipată.

Înțelegerea și evaluarea acestor surse de discrepanță este crucială pentru câștigarea încrederii în modelare ca o tehnică de analiză a sistemelor de comunicații.

Acuratețea proiecțiilor de performanță ale modelului nu poate fi mai mare decât cea a datelor de intrare furnizate de măsurătorile de încărcare.

1.5. Modelarea cantitativă

Modelarea cantitativă începe întotdeauna cu stabilirea parametrilor care să permită măsurarea performanțelor sistemelor (debit de informații, timp de răspuns, număr mediu de resurse ocupate, rată de utilizare a resurselor)

Metodele de evaluare cantitativă se împart în trei categorii:

Măsurarea se execută pentru anumiți parametri ai sistemului. Există tehnici complexe de măsură, dar unele dintre ele conduc la o optimizare deosebit de dificilă.

Metodele analitice sunt foarte eficiente în vederea optimizării, în măsura în care pot fi scrise și rezolvate ecuațiile matematice. De asemenea, în aceste condiții calculele pentru aflarea valorilor parametrilor sunt foarte rapide. Inconvenientele rezidă în numărul foarte mic de modele care au o soluție matematică exactă. Metodele matematice provin din teoria șirurilor de așteptare.

Simularea permite a se intra mai mult în detaliu, de a descrie mai precis modelul cu restricțiile sale. Soluția este aproximativă dar se poate cunoaște cu precizie de 90-95% intervalul în care se situează rezultatul exact.

1.6. Modelarea calitativă

Complexitatea crescândă a sistemelor, precum și aplicațiile executate prin intermediul acestora, necesită utilizarea unor metode capabile să controleze comportamentul logic al operațiilor puse în joc. Rezultă deci necesitatea metodelor formale de validare

1.7. Modelarea prin simulare

Simularea reprezintă un ansamblu de tehnici și proceduri, care permit să se aproximeze comportamentul unui sistem, mai ales al sistemelor foarte complexe pentru care tehnicile modelării analitice nu pot face față. Este totdeauna o metodă stocastică, nedeterministă, deoarece măsura sau simulatorul se bazează pe exploatarea unor variabile aleatoare. Astfel, comportamentul studiat este stocastic și dinamic, căci el conține evenimente care apar aleatoriu în decursul timpului.

Prin simulare se obține o descriere detaliată a sistemului, dar cu un cost de calcul foarte ridicat, compensat însă de evoluția tehnologiilor în domeniul tehnicii de calcul. Nivelul de detaliere depinde însă de opțiunea personală a celui ce execută simularea.

În plus, simularea rezolvă problema evaluării comportamentului tranzitoriu al sistemelor, în timp ce modelele analitice sunt în general utilizate pentru studiul comportamentului lor staționar.

1.7.1. Simulatorul

Simulatorul este programul care conține algoritmul utilizat pentru a simula sistemul studiat. Inițial, se determină mediul de simulare: datele furnizate simulatorului, măsurătorile efectuate, controlul lor și validarea simulării în ansamblul său.

Un simulator este format dintr-un ansamblu de entități care descriu o componentă a sistemului real. Fiecare dintre ele este descrisă cantitativ prin atribute ce permit reprezentarea stării sale. Aceste atribute pot depinde de timp și sunt în general identificate prin variabile aleatoare.

Starea S a sistemului global este definită prin ansamblul complet al atributelor fiecărei entități. Ea va fi reprezentată printr-un vector de variabile aleatoare. Astfel, o perioadă T de observație pentru simularea sistemului va fi caracterizată de ansamblul S(t) al valorilor vectorilor de stare a sistemului pentru tT ; fiecare dintre stările succesive obținute în decursul perioadei de observație va evolua doar în cazul apariției unui eveniment.

Simulatoarele pot fi împărțite în trei categorii principale și anume:

Simulatoare în timp continuu

Un sistem este continuu dacă vectorul său de stare se schimbă în permanență în raport cu timpul. Simulatorul este în general formulat sub forma unor ecuații diferențiale, adesea neadecvate pentru a descrie comportamentul unui sistem discret. Totuși, în această manieră pot fi obținute informațiile asupra comportamentului tranzitoriu al sistemului.

Simulatoare în timp discret

Un simulator în timp discret definește starea sistemului la momente numărabile în decursul perioadei de observație T = {t(i), iN}. Astfel, secvența stărilor observate în decursul intervalului T este determinată prin succesiunea {S(t(i)), iN}. Un sistem continuu poate deci fi complet identificat prin secvența de stări S(t(i)), ce corespund momentelor de observație.

Simulatoare în timp continuu cu evenimente discrete

Aici, secvența momentelor de observație este definită prin momentele de apariție a evenimentelor. Principala metodă folosită pentru evaluarea performanțelor sistemelor informaționale o constituie simulatoarele cu timp/eveniment discret. Durata de incrementare temporală poate fi atunci fixă (simulare în timp discret) sau variabilă (simulare cu evenimente discrete). Simularea cu evenimente discrete este foarte convenabilă studiilor generale referitoare la rețele sau protocoale de comunicație. Simularea cu evenimente discrete constituie o reprezentare statistică a evenimentelor, ce obligă la o interpretare judicioasă a rezultatelor obținute. Simularea evenimentelor discrete este guvernată prin secvențe de numere pseudo-aleatoare generate pe calculator, iar distribuția acestor secvențe trebuie să fie de asemenea specificată în structura modelului.

Pachetul de programe COMNET III folosește simularea prin metoda evenimentelor discrete, furnizând cu acuratețe rezultate realiste. Alternativa la modelarea bazată pe evenimente discrete, este folosirea metodelor matematice tradiționale de analiză care nu pot face față efectelor variației aleatoare. Ipotezele simplificatoare cerute de metodele analitice ignoră efectele așteptării, independenței evenimentelor și variației aleatoare în analiza rețelelor complexe de comunicații.

1.7.2. Tehnici de simulare

În cazul simulărilor pentru evenimente discrete poate fi folosită una dintre tehnicile următoare:

Aproximarea orientată pe eveniment – se bazează pe inventarierea și ordonarea tuturor evenimentelor într-un registru de scadențe funcționând sub un ceas logic. Manipularea evenimentelor este efectuată prin programul de simulare. Apariția fiecărui eveniment declanșează execuția unei operații specifice. Este deci necesară recenzarea ansamblului evenimentelor posibile ca și al consecințelor (în raport cu contextul, adică starea în care ele intervin).

Aproximarea orientată pe activitate – modelul este descompus în activități de bază, fiecare acoperind mai mult de un eveniment. Fiecărui activități i se asociază o acțiune și un cod numeric, în relație cu ceasul de simulare și cu starea globală a sistemului. La apariția unui eveniment sunt cercetate toate activitățile și sunt executate acelea care verifică condițiile. Aici este deci o ordonare automată a evenimentelor, ceea ce nu necesită generarea unei liste a acestora.

Aproximarea orientată pe proces – un proces este definit ca o sumă de activități ce se exclud mutual. Comportamentul simulatorului traduce acțiunile și interacțiunile diverselor procese. Este posibilă modelarea simultaneității mai multor procese, utilizându-se mecanisme de sincronizare de tip fanion (flag).

Simularea furnizează o posibilitate de validare ce rămâne foarte superficială în măsura în care nu integrează toate posibilitățile sistemului; pot fi însă descoperite anumite erori printr-o alegere corespunzătoare a datelor și distribuțiilor.

Simularea interactivă permite proiectantului să-și definească scenarii proprii sau poate observa dacă anumite secvențe de evenimente sunt susceptibile să pună protocolul în eșec. De asemenea, un protocol deja validat prin metode de specificare formală poate fi considerat prea lent după efectuarea simulării.

În evaluarea performanțelor este foarte larg folosită modelarea în domeniul rețelelor și protocoalelor de comunicații. În consecință s-a reușit să se stabilească ecuații matematice, care pot fi rezolvate și care să modeleze, în limita unor ipoteze simplificatoare, protocoale și anumite rețele de comunicații.

Modelarea rețelelor prin simulare este un subiect interdisciplinar foarte dificil. Necesită nu numai elemente de teoria simulării propriu-zisă, dar și cunoștințe considerabile de statistică precum și de teoria ce stă la baza rețelei respective. Ideea principală din spatele modelării prin simulare este reprezentarea topologiei și funcțiilor rețelei în cadrul unui model pentru a obține rezultate statistice ale performanțelor rețelei.

În orice caz, trebuie făcută distincția între simulare și emulare:

– emularea are ca scop mimarea funcției sau rețelei originale, reprezentând-o deci în cel mai mic detaliu.

– simularea urmărește obținerea de rezultate statistice ce descriu operațiile rețelei sau funcției.

Aceste deosebiri implică faptul că în simulare, nu trebuie reprezentată fiecare funcție, ci numai acele detalii ale rețelei sau arhitecturii în cauză care sunt cele mai reprezentative pentru statisticile ce se doresc obținute prin simulare. Din punct de vedere practic, este imposibil să încorporăm fiecare funcție realizată de oricare dispozitiv al rețelei și să ne așteptăm ca un singur computer, în general un PC, să simuleze/emuleze un asemenea model.

Este dificilă alegerea acelor funcții, din nenumăratele ale rețelei, care să fie modelate în simulare. Acesta este unul din motive pentru care simularea nu poate fi considerată o sarcină ușoară, la îndemâna oricui. Cheia este încorporarea acelor detalii semnificative ce răspund problemei în cauză. Aceasta presupune că cel care efectuează simularea cunoaște clar substratul problemei, știind cu precizie ce statistici vrea să obțină. Cu alte cuvinte trebuie definit un scop al simulării, scop ce va defini detaliile ce trebuie simulate. Această cerință a modelării rețelei implică de asemenea că aceeași rețea poate produce mai multe modele pentru simulare datorită diferențelor între scopurile stabilite. De exemplu, un studiu se poate focaliza pe semnalizare. Legăturile pot reprezenta numai banda disponibilă pentru semnalizare, fiind reprezentat numai traficul aferent acesteia. Un alt studiu al aceleiași rețele se poate opri asupra performanțelor în condițiile traficului de vârf. În acest caz, traficul semnalizărilor poate fi omis.

O întrebare fundamentală este dacă se dorește modelarea arhitecturii interne a unui switch sau întreaga rețea? În primul caz, ar trebui introduse detalii despre structura internă a switch-ului, ca de exemplu viteze posibile ale bus-ului, caracteristicile și funcțiile buffer-elor, ca și interacțiunea dintre diferite componente ale switch-ului. Dacă se decide modelarea unei rețele, nu se reprezintă în mod obișnuit componentele la un asemenea nivel de detaliu. Argumentul este că funcțiile detaliate îndeplinite de switch nu contribuie în mod semnificativ la rezultatele simulării rețelei în ansamblu. Adăugarea de amănunte pentru modelarea întârzierilor în scopul obținerii unei rezoluții de ordinul nanosecundelor – de exemplu prin modelarea întârzierilor individuale de procesare din cadrul unui switch – nu va contribui semnificativ la rezultatele finale legate de întârzieri ce pot fi de ordinul secundelor. Precizia câștigată prin modelarea la un nivel detaliat, nu compensează nici pe departe costul și efortul necesar pentru încorporarea detaliilor. Mai mult, computerul ce rulează simularea trebuie să muncească din greu pentru a ține evidența tuturor evenimentelor nesemnificative.

1.7.3. Analiza statistică a rezultatelor simulării

Simularea este inițiată prin secvențe aleatorii de intrare (reprezentând de exemplu timpi de serviciu). Ea produce apoi secvențe de ieșire, tot aleatorii (cum ar fi de exemplu timpi de răspuns). Pot fi deduse în final distribuțiile caracteristice pentru parametrii de ieșire.

Dacă simularea se repetă în aceleași condiții, dar plecând de la o altă secvență de intrare, statistic independentă de prima, rezultatele vor fi diferite, ceea ce implică o analiză statistică. Dacă perioada de simulare crește, atunci estimările vor fi mai precise. Trebuie întotdeauna considerat un interval de încredere.

Fie caracteristica necunoscută de ieșire a modelului care se estimează în cadrul procesului. Un interval (L,U) cu extremități aleatorii L și U este interval de încredere la 100(1-)% pentru , dacă prob {L U} = 1-. Pentru 1- aproape de 1 există o foarte mare probabilitate ca parametrul să fie cuprins între L și U. Intervalul de încredere este astfel ales încât estimarea 0 a lui să fie cuprinsă în același interval. Altfel spus, lărgimea U – L a intervalului determină măsura preciziei lui 0; cu cât intervalul este mai îngust, cu cât încrederea este mai mare.

Au fost creați algoritmi de control al duratei de simulare care permite executarea unui model până la obținerea unui interval de încredere de precizie datorită timpului mare de simulare.

Fie X1,…, XN o secvență generată prin simulare pentru timpul de răspuns al unui sistem; se dorește estimarea valorii medii în regim staționar a timpului de răspuns . Estimarea clasică pentru media elementului este [1]:

(1.1)

Problema de nestaționaritate rezidă din inegalitatea E[Xn] la n mic, pentru că starea inițială este diferită evident de starea staționară. Aceasta implică și faptul că E[0] .

Aproximarea clasică pentru studiul acestei probleme, numită problema regimului tranzitoriu, constă în a determina N0 astfel ca E[Xn] = pentru n N0. Se elimină informațiile anterioare lui N0 și se estimează cu relația [1]:

(1.2)

O altă problemă o reprezintă autocorelația. Fie că a fost obținut un N0 satisfăcător, astfel că {Xn, n N0} este aproximativ o secvență staționară. Teorema limitei centrale precizează că, pentru un N mare, elementul (0 – )/[0] este aproximativ distribuit după o lege normală (0,1), în care 2[0] este varianța lui 0. Dacă valorile Xn sunt independent și uniform distribuite, atunci 2[0]= 2[Xn]/(N-N0), unde 2[Xn] este varianța lui Xn. în cazul unor simulări lungi se poate folosi pentru varianța observațiilor corelate o expresie mai precisă, anume [1]:

(1.3)

unde k este autocorelația între Xn și Xn+k. astfel varianța unei secvențe corelate este egală cu varianța unei secvențe independente multiplicată printr-un factor ce măsoară corelația secvenței. Factorul de multiplicare se identifică prin suma funcțiilor de autocorelație. În general, în simulările rețelelor cu șiruri de așteptare el este pozitiv și eventual supraunitar.

Având în vedere că sistemele actuale devin din ce în ce mai complexe, modelarea analitică va fi tot mai dificilă, iar simularea va juca un rol decisiv în domeniul evaluării performanțelor. Tehnici de calcul tot mai puternice vor trebui să fie aplicate pentru simularea sistemelor complexe.

Metodele de modelare hibridă, conținând pe de o parte o procedură analitică și pe de altă parte un proces de simulare, se constituie astăzi ca o procedură importantă și de viitor.

CAPITOLUL II

PRINCIPIILE MODELĂRII SOFT A REȚELELOR DE COMUNICAȚII

2.1. Asamblarea soft a nodului de comunicații

Prin noțiunea de "rețea" se înțelege o grupare de terminale autonome care sunt interconectate pentru a putea face schimb de informații între ele. Rețelele moderne de bandă largă (B-ISDN) oferă suport universal pentru o multitudine de tipuri de servicii (voce/date/text/imagini). Din acest motiv, noțiunea de "terminal" poate avea accepțiuni foarte diverse, plecând de la un telefon și ajungând la o sursă de semnal de televiziune de înaltă definiție. Elementul caracteristic pentru toate aceste tipuri de terminale este faptul că ele sunt autonome, nici unul dintre ele nu are funcții de control asupra celorlalte. Toate categoriile de rețele (LAN, MAN, WAN) respectă o structură asemănătoare: există o serie de terminale interconectate cu ajutorul unor comutatoare ce asigură îndrumarea mesajului de la sursă la destinație.

Rețeaua de comunicații este formată din două părți distincte: liniile de transmisie și elementele de comutație. Elementele de comutație sunt calculatoare specializate pentru a îndruma traficul între o linie de intrare în comutator și o linie de ieșire. Aceste comutatoare se numesc "noduri de comunicație".

Comunicațiile într-o rețea se pot face în două moduri:

– punct-la-punct.

– cu difuzare.

În primul caz, informația de la terminalul sursă la terminalul destinație este dirijată de către nodurile de comunicație pentru a străbate liniile care unesc sursa și destinația. Pachetul de date este preluat de fiecare nod de pe parcurs și reexpediat pe următorul tronson al legăturii. Celelalte terminale nu au acces la datele transmise, întreaga responsabilitate pentru corecta rutare revenind nodurilor.

Sistemul cu difuzare presupune existența unui mediu comun pentru toate terminalele. Acestea au responsabilitatea de a "extrage" pachetele ce le sunt destinate. Cea mai mare parte a rețelelor locale (de tip token-ring, token-bus) sunt de acest tip.

2.1.1. Structura unui nod de comunicații

Nodul de comunicații este realizat cu ajutorul a cinci tipuri de module: hub, generator, sink, receptor și transmițător. De exemplu, structura unui nod cu trei transmițătoare și trei receptoare este prezentată în Fig. 2.3.

2.1.2. Realizarea fișierelor NODE_XY.CPP

Funcțiile care simulează procesele din modulele unui nod sunt introduse într-un fișier numit NODE_XY.CPP care va conține la început directiva de procesare # include "local.h", după care câte o copie a funcțiilor: generator "gen_xyz ( )" din fișierul GEN_XYZ.MDL, sink "sink_xyz ( )" din fișierul SINK_XYZ.MDL, hub "hub_xyz ( )" din fișierul HUB_XYZ.MDL, receptor "rx_xyz ( )" din fișierul REC_XYZ.MDL și transmițător "tx_xyz ( )" din fișierul TRNS_XYZ.MDL.

Deoarece în nod există de obicei, mai multe transmițătoare și mai multe receptoare, funcțiile receptor "rx_xyz ( )", respectiv transmițător "tx_xyz ( )" vor fi multiplicate astfel încât să existe câte o funcție receptor pentru fiecare modul receptor din nod și câte o funcție transmițător pentru fiecare modul transmițător din nod.

Se multiplică fișierul NODE_XY.CPP pentru fiecare nod din rețea, înlocuind pe X și Y cu identitatea subrețelei de care aparține nodul respectiv cu numărul nodului în cadrul subrețelei. Astfel, pentru o rețea cu o subrețea având patru noduri, vor fi realizate fișierele NODE_00.CPP, NODE_01.CPP, NODE_02.CPP și NODE_03.CPP. Fiecare dintre aceste noduri trebuie apoi modificat pentru a stabili identitățile funcțiilor aflate în fișiere.

Funcțiile care simulează nodul sunt de tipul:

Void functie_xyz()

{

………………….

stack_insert ("functie_xyz()");

………………….

}

Modificările ce trebuie făcute sunt următoarele:

– în locul lui x se trece identitatea (numărul) subrețelei;

– în locul lui y se trece identitatea (numărul) nodului în subrețea;

– în locul lui z se trece identitatea (numărul) modulului de tip "funcție" în nod;

De exemplu, dacă în nodul 5 al subrețelei 0 există trei receptoare, atunci fișierul NODE_05.CPP trebuie să conțină funcțiile receptor: rx_050, rx_051 și rx_052.

Aceleași modificări se fac și în linia "stack_insert ("functie_xyz")".

Exemplu: Unicul modul generator al nodului 3 din subrețeaua 0 va conține declarațiile:

Void gen_030()

{

………………….

stack_insert ("gen_030()");

………………….

}

2.1.3. Modelarea soft a modulului "generator de pachete"

Modulul "gen" are trei stări: INIT, IDLE și PK_GEN. Starea IDLE este neforțată.

Starea INIT (stare forțată): procesul intră în această stare în situația inițială, când primește prima întrerupere, de obicei "BEGIN_SIM". În această stare se încarcă variabilele "length_mean" și "interarrival_mean". Singura tranziție posibilă este către starea IDLE, unde procesul așteaptă în continuare întreruperea "SELF_INTRPT".

Starea IDLE (stare neforțată): este starea în care se așteaptă o nouă întrerupere "SELF_INTRPT". Tranziția unică este către starea PKT_GEN.

Starea PK_GEN (stare forțată): în această stare se intră atunci când se generează un nou pachet. Această generare presupune crearea unei noi structuri de tip "Pachet". Tranziția face ca procesul să treacă în starea IDLE până la apariția unei noi întreruperi "SELF_INTRPT".

Calculul numărului mediu de clienți aflați în sistem (E[N]) este realizat cu ajutorul funcțiilor "add_value (int operation, float time_value)" și "pks_no_mean()". Programul generează o listă înlănțuită, structura (nodul) listei cu numărul k memorând timpii cât în sistem au fost k clienți. Ori de câte ori este generat un client în sistem (au fost k clienți, acum sunt k+1), funcția "add_value (operation, time_value)" găsește structura cu numărul k și înscrie în ea timpul cât în sistem au fost k clienți. Acest timp este momentul când au apărut în sistem k+1 clienți minus timpul cât în sistem au fost k clienți. Lucrurile se petrec asemănător și atunci când dispare un client din sistem (k → k-1). Către structura curentă există un pointer. Acest pointer va indica înspre structura k+1 dacă s-a mărit numărul de clienți în sistem (valoarea parametrului "operation" este MORE) sau va indica înspre structura k-1 dacă s-a micșorat numărul de clienți în sistem (valoarea parametrului "operation" este LESS). Funcția "pks_no_mean ()" parcurge toată această listă și calculează E[N] după formula:

Indicații de construire a funcției proces:

……………………………………………………………………………………………

Static and extern variables

//…

……………………………………………………………………………………………

Temporary variables

//…

State INIT (FORCED)

// exec

// Se cere media lungimii pachetelor create ("length_mean").

// Valoarea acestei variabile este încărcată cu ajutorul funcției "data()"

//…

// Se cere media duratei dintre două generări succesive ("interarrival mean")

// Valoarea acestei variabile este încărcată cu ajutorul funcției "data()"

//…

……………………………………………………………………………………………

// tranzition

// se specifică starea în care va trece procesul

//…

……………………………………………………………………………………………

State IDLE (UNFORCED)

// enter exec

// se creează evenimentul intern ulterior ce va avea loc la momentul "next_time"

// acest moment este egal cu timpul curent al simulării plus un timp generat aleator de funcția "exp_dist(interarrival_mean)"

//…

// "auto-programarea" la întrerupere se face cu "schedule_self_intrpt(next_time,0)"

//…

……………………………………………………………………………………………

// exit exec

……………………………………………………………………………………………

// transition

// se specifică starea în care va trece procesul

//…

……………………………………………………………………………………………

State PK_GEN (FORCED)

// exec

// se alege aleator lungimea pachetului cu funcția "(int)exp_dist(length_mean)"

//…

// se generează pachetul (de fapt, pointerul "pk_ptr" către pachet) cu ajutorul funcției "pk_create(lungime_pachet)"

//…

// trimite pachetul la stream-ul conectat (generatorul are o singură ieșire: 0) cu ajutorul funcției pk_send_forced(0, pk_ptr)

//…

// deoarece a fost introdus un nou client în sistem, se actualizează calculele pentru E[N] folosind funcția "add_value(MORE,sim_time()-new_pks_time)"

//…

// se reactualizează și "new_pks_time" (în acest moment a fost schimbat numărul de clienți în sistem)

//…

……………………………………………………………………………………………

// tranzition

// se specifică starea în care va trece procesul

//…

2.1.4. Modelarea soft a modulului "SINK"

Modulul "sink" are trei stări: INIT, IDLE și ARRIVAL. Starea IDLE este neforțată.

Starea INIT (stare neforțată): procesul intră în această stare în situația inițială, când primește prima întrerupere, de obicei "BEGIN_SIM". Singura tranziție posibilă este către starea IDLE, unde procesul așteaptă în continuare în continuare întreruperea "STREAM_INTRPT".

Starea IDLE (stare neforțată): este starea în care se așteaptă o nouă întrerupere "STREAM_INTRPT". Tranziția unică este către starea ARRIVAL.

Starea ARRIVAL (stare forțată): în această stare se intră atunci când trebuie distrus un pachet. Distrugerea se face prin ștergerea structurii de tip pointer din memoria calculatorului. Tranziția face ca procesul să treacă în starea IDLE până la apariția unei noi întreruperi "STREAM_INTRPT".

Indicații de construire a funcției proces:

……………………………………………………………………………………………

Static and extern variables

//…

……………………………………………………………………………………………

Temporary variables

//…

……………………………………………………………………………………………

State INIT (FORCED)

// exec

// nimic de făcut

……………………………………………………………………………………………

// tranzition

// se specifică starea în care va trece procesul

//…

……………………………………………………………………………………………

State IDLE (UNFORCED)

// enter exec

// nimic de făcut

……………………………………………………………………………………………

// exit exec

……………………………………………………………………………………………

// transition

// se specifică starea în care va trece procesul

//…

……………………………………………………………………………………………

State ARRIVAL (FORCED)

// exec

// se determină indicele intrării ("in_index") pe care a sosit pachetul folosind funcția "intrpt_in()"

//…

// se extrage pachetul din stream-ul de identitate "in_index" folosind funcția "pk_get(in_index)"

//…

// se incrementează numărul de pachete sosite la destinație ("witness")

//…

// se calculează timpul petrecut de acest pachet în rețea ("ete_delay")

//…

// se calculează timpul mediu ("ete_delay") în rețea al unui pachet după formula

// ete_m_delay = ete_delay/(float)witness

//…

// ajuns la destinație, pachetul este distrus folosind funcția "free(pk_ptr)"

//…

// deoarece se elimină un client din sistem, se actualizează lista înlănțuită folosită la calculul lui E[N]

// "add_value(LESS, new_pks_time)"

//…

// se reactualizează new_pks_time

//…

……………………………………………………………………………………………

// tranzition

// se specifică starea în care va trece procesul

2.1.5. Modelarea soft a modulului "COMUTATOR DE PACHETE"

În cadrul rutării fixe, tabela de rutare este stabilită la începutul programului și nu mai este modificată în timpul funcționării rețelei.

Modulul "HUB" are trei stări: INIT, IDLE și ROUTE_PK. Starea IDLE este neforțată.

Starea INIT (stare neforțată): procesul intră în această stare în situația inițială, când primește prima întrerupere, de obicei "BEGIN_SIM". Singura tranziție posibilă este către starea IDLE, unde procesul așteaptă în continuare în continuare întreruperea "STREAM_INTRPT".

Starea IDLE (stare neforțată): este starea în care se așteaptă o nouă întrerupere "STREAM_INTRPT" indicând sosirea spre rutare a unui nou pachet.. Tranziția unică este către starea ROUTE_PK.

Starea ROUTE_PK (stare forțată): în această stare se intră atunci când trebuie rutat un pachet. Rutarea se face către ieșirea din nod corespunzătoare destinației. Adresa de destinație este citită din câmpul "dest_add" al pachetului. Ieșirea este selectată datorită corespondenței stabilite în tabelul de rutare între destinații și ieșirile corespunzătoare. În continuare, rutarea corectă este asigurată de unicitatea intrărilor și ieșirilor transmițătoarelor și receptoarelor prin care va tranzita pachetul. Din modulul "HUB" pachetul va fi transmis unui transmițător, în mod forțat. Tranziția face ca procesul să treacă în starea IDLE până la apariția unui nou eveniment de rutare.

Indicații de construire a funcției proces:

……………………………………………………………………………………………

Static and extern variables

//…

……………………………………………………………………………………………

Temporary variables

//…

……………………………………………………………………………………………

State INIT (FORCED)

// exec

// se citește numărul de linii al tabelei de rutare cu ajutorul funcției "data()"

//…

// se generează dinamic ("(int)malloc(…)") tabela de rutare

// de dimensiune "nr_linii*sizeof(int)"

//…

// se încarcă tabela de rutare cu informații din fișierul DATA.DAT

// se folosește funcția "data()" pentru fiecare linie a tabelului (ciclu "for()")

//…

……………………………………………………………………………………………

// tranzition

// se specifică starea în care va trece procesul

//…

……………………………………………………………………………………………

State IDLE (UNFORCED)

// enter exec

// nimic de făcut

……………………………………………………………………………………………

// exit exec

// nimic de făcut

……………………………………………………………………………………………

// transition

// se specifică starea în care va trece procesul

//…

……………………………………………………………………………………………

State ROUTE_PK (FORCED)

// exec

// se determină indicele intrării ("in_index") de la care a sosit pachetul folosind funcția "intrpt_in()"

//…

// se obține adresa de bază a pachetului folosind funcția "pk_get(in_index)"

// se determină adresa nodului destinație

//…

// se află numărul ieșirii pe care va fi scos pachetul folosind tabela de rutare

// se trimite pachetul pe stream folosind funcția "pk_send_forced(out_index, pk_ptr)"

//…

……………………………………………………………………………………………

// tranzition

// se specifică starea în care va trece procesul

2.2. Asamblarea soft a subrețelei de comunicații

2.2.1. Descrierea ierarhică a subrețelei

La început se "construiește" rețeaua, comunicând programului felul în care sunt legate modulele în cadrul fiecărui nod, ca și legăturile dintre noduri. După realizarea rețelei, programul inițializează toate modulele din noduri în cadrul stării INIT a modulului. Datele necesare acestor inițializări sunt citite din fișierul "DATA.DAT" cu ajutorul funcției "data()". Aceasta citește ceea ce se află în fișier după semnul ":" și convertește acea valoare într-un număr de tip float. La următoarea citire va fi preluat numărul aflat după următorul semn ":", ș.a.m.d. Pentru a încărca rețeaua corect, este absolut necesar ca datele să fie trecute în fișierul "DATA:DAT" exact în ordinea în care acestea vor fi cerute de către program.

Primele date cerute se referă la numărul de subrețele, identificatorii subrețelelor și numărul de noduri.

Exemplu:

subnets_no: 1 // există doar o subrețea

subnet_id: 0 // având identificatorul 0

nodes_no:6 // și conținând șase noduri (nod 0 – nod 5)

Considerând că nodurile subrețelei sunt de tipul celui prezentat în Fig. 1 și că legăturile între noduri se fac în conformitate cu Fig. 4, descrierea rețelei continuă astfel:

node_id:0 // descrierea nodului 0

modules_no:3

module_id:0 // modulul generator

outs_no:1 // are o ieșire

out_stream_id:0 //conectată la streamul 0

ins_no:0 //nu are intrări

stats_outs_no:0 //nu are ieșiri și intrări statistice

stats_ins_no:0

module_id:200 //modulul sink

outs_no:0 // nu are ieșiri

ins_no:1 // are o intrare

in_stream_id:7 //conectată la streamul 7

stats_outs_no:0

stats_ins_no:0

module_id:500 //modulul hub

outs_no:4 // are patru ieșiri

out_stream_id:4 //prima ieșire este conectată la streamul 4

out_stream_id:5 //a doua ieșire este conectată la streamul 5

out_stream_id:6 //a treia ieșire este conectată la streamul 6

out_stream_id:7 //a patra ieșire este conectată la streamul 7

ins_no:4 // are 4 intrări

in_stream_id:3 //prima ieșire este conectată la streamul 3

in_stream_id:2 //a doua ieșire este conectată la streamul 2

in_stream_id:1 //a treia ieșire este conectată la streamul 1

in_stream_id:0 //a patra ieșire este conectată la streamul 0

stats_outs_no:0

stats_ins_no:0

tx_modules_no:3 //nodul are trei transmițătoare

tx_module_id:300 //primul modul transmițător

outs_no:1 //are o ieșire

out_channel_id:0 //conectată la canalul 0

ins_no:1 //are o intrare

in_stream_id:4 //conectată la streamul 4

stats_outs_no:0

stats_ins_no:0

// analog cu modulul 300 se inițializează și celelalte transmițătoare

rx_modules_no:3 //nodul are trei transmițătoare

rx_module_id:400 //primul modul receptor

outs_no:1 //are o ieșire

out_channel_id:1 //conectată la streamul 1

ins_no:1 //are o intrare

in_stream_id:4 //conectată la canalul 1

stats_outs_no:0

stats_ins_no:0

// analog cu modulul 400 se inițializează și celelalte receptoare

Urmează, asemănător cu nodul 0, descrierea nodului 1, a nodului 2, până la ultimul nod al subrețelei.

De exemplu, fie o rețea cu nodurile 0..n. Datorită faptului că listele înlănțuite create de program pentru a memora aceste informații sunt create de sus în jos, trecerea prin starea INIT se face în ordine inversă.

Urmează declarațiile pentru inițializarea canalelor care leagă nodurile între ele. Canalele sunt caracterizate prin două mărimi: length (lungimea) și prop_delay (întârzierea de propagare pe canal).

Ordinea de inițializare este următoarea: se inițializează canalele în ordine inversă prezentării nodurilor la care sunt conectate și în același timp în ordine inversă de prezentare a numerelor modulelor transmițătoare la care se leagă.

Pentru rețeaua din Fig. 2.6., inițializările vor fi:

channel[11]length (km):100 //nodul 5

channel[11]prop_delay (microsec/km): 2

channel[14]length (km):100

channel[14]prop_delay (microsec/km): 2

channel[8]length (km):100

channel[8]prop_delay (microsec/km): 2

channel[7]length (km):100 //nodul 4

channel[7]prop_delay (microsec/km): 2

channel[9]length (km):100

channel[9]prop_delay (microsec/km): 2

channel[0]length (km):100

channel[0]prop_delay (microsec/km): 2

Se inițializează apoi generatorul de numere aleatoare (cu valorile ix, iy, iz), se stabilește durata simulării și perioada la care se va afișa pe ecran avansarea timpului.

ix: 23

iy: 456

iz: 789

end_sim_time (sec): 10

up_date_interval (sec): 1

Astfel, pentru rețeaua din Fig.4. inițializările pentru nodurile 5 și 4 vor fi următoarele:

node[5]

module[500] // modulul hub al nodului 5

nr_1: 6 // câte noduri sunt rețea

rout_tbl[0]: // se trece indexul ieșirii din hub conectate la

rout_tbl[1]: // tx_ul corespunzător rutării

rout_tbl[2]:

rout_tbl[3]:

rout_tbl[4]:

rout_tbl[5]:

module[0] // modulul generator al nodului 5

pk_len: 9600 // lungimea medie a unui pachet [biți]

interarrival_mean: 2.0 // intervalul mediu dintre 2 generări //succesive [sec]

module [302] // modulul transmițător al nodului 5

tx_drate: 9600 // numărul de biți serviți într-o secundă

queue_lnt:100 // lungimea tamponului cozii

module [301]

tx_drate: 9600

queue_lnt:100

module [300]

tx_drate: 9600

queue_lnt:100

node[4]

module[500]

nr_1: 6

rout_tbl[0]: // se trece indexul ieșirii din hub conectate la

rout_tbl[1]: // tx_ul corespunzător rutării

rout_tbl[2]:

rout_tbl[3]:

rout_tbl[4]:

rout_tbl[5]:

module[0]

pk_len: 9600

interarrival_mean: 2.0

module [302]

tx_drate: 9600

queue_lnt:100

module [301]

tx_drate: 9600

queue_lnt:100

module [300] // deoarece nodul are doar două transmițătoare,

tx_drate // valorile corespunzătoare celui de al treilea

queue_lnt // transmițător ("inactiv" pe durata simulării) nu se

// completează

// se inițializează analog și restul de noduri din subrețea

//…

2.2.2. Completări realizate în fișierul MAIN.CPP

Fișierul "MAIN.CPP" conține o cascadă de instrucțiuni de tip "switch" care au rolul de a lansa în execuție procesul care se găsește în capul listei de evenimente. pentru ca programul să treacă prin toate funcțiile care simulează funcționarea modulelor în noduri, trebuie ca aceste funcții să fie trecute în cadrul subrețelei și nodului de care aparțin.

Exemplu:

switch(head_ev_list_ptr->subnet_id)

{

case SUBNET_0: // procesele din subrețeaua 0

switch(head_ev_list_ptr->node_id)

{

case NOD_0: //funcțiile definite în nodul 0-NODE_00.CPP

{

case GEN_0:

gen_000();

break;

case SINK_0:

sink_000();

break;

case HUB_0:

hub_000();

break;

case TX_0:

tx_000();

break;

case RX_0:

rx_000();

break;

case TX_1:

tx_001();

break;

case RX_1:

rx_001();

break;

case TX_2:

tx_002();

break;

case RX_2:

rx_002();

break;

}

break;

case NOD_1:

// se completează analog cu nodul 0

//…

// la fel pentru toate nodurile rețelei

//…

}

case SUBNET_1:

// în acest caz nu există

break;

};

2.2.3. Fișierul LOCAL.H

Fișierul LOCAL.H conține definiții pentru toate constantele simbolice folosite în program. Includerea acestui fișier la compilarea tuturor celorlalte fișiere datorită directivei # include "local.h" face ca definirile realizate în LOCAL.H să fie vizibile în tot programul.

Aici se definesc toate constantele de tipul SUBNET_x, NOD_x, MODUL_x.

Exemplu:

#define SUBNET_0 0

#define NOD_0 0

#define NOD_1 1

#define TX_0 300

#define TX_1 301

#define RX_0 400

#define RX_2 402

#define GEN_0 0

#define SINK_0 200

#define HUB_0 500

În LOCAL.H se află antetele tuturor funcțiilor folosite în proiect. Dacă o funcție este declarată într-un fișier și este folosită în altul, dar antetul funcției nu se află în LOCAL.H, vor exista erori. De aceea, trebuie trecute aici antetele funcțiilor care au fost definite în fișierele NODE_XY.CPP (așa numitele "funcții proces").

Exemplu:

void gen_020(); //antetele funcțiilor proces din nodul 2

void sink_020();

void hub_020();

void tx_020();

void tx_021();

void tx_022();

void rx_020();

void rx_021();

void rx_022();

Fișierul LOCAL.H mai conține o serie de structuri, declarații de funcții definite în NETCONF.CPP, QPKF.CPP, PACKF.CPP și SENDF.CPP precum și eventual, alt funcții definite de către utilizator.

2.3. Programul ROUT97

În catedra Comunicații din cadrul Facultatății de Electronică și Telecomunicații a Universității Politehnica din București, a fost conceput, ca urmare a aplicațiilor la cursul de "Planificarea rețelelor", un program bazat pe principiile modelării soft a rețelelor de comunicații prezentate în acest capitol, la punctele anterioare.

Aceste principii au fost predate la cursul menționat mai sus, aplicațiile fiind concretizate în câteva îndrumare de laborator, foarte utile atât studenților cât și inginerilor din domeniu (v. Bibliografia: [3], [4], [5])

Programul Rout97 ilustrează într-adevăr modelarea soft a rețelelor de comunicații, dar este inflexibil prin faptul că rețelele trebuie asamblate element cu element prin descrierea acestora, așa cum s-a arătat la punctul 2.2. Nu pot fi încercate variante ale aceluiași sistem fără un volum mare de muncă de introducere a datelor rețelei. În plus are posibilități limitate în sensul parametrilor unei rețele ce pot fi măsurați, principalii doi fiind Timpul mediu de staționare în sistem și Numărul mediu de utilizatori în sistem.

Deși este didactic, programul nu poate fi considerat un instrument de modelare a rețelelor de comunicații, decât din punct de vedere al principiilor soft.

Rezultatele pot fi generate în format text, sub forma unor liste de valori, cât și sub forma unor reprezentări grafice, bazate pe valorile mai sus menționate.

Iată câteva exemple de rezultate, obținute pentru subrețeaua din Fig. 2.6.

CAPITOLUL III

PREZENTAREA UNOR PROGRAME DE FIRMĂ:

"COMNET III v. 2.1"

COMNET III este un pachet de programe comerciale care permite analiza și predicția performanțelor rețelelor, pornind de la simple LAN-uri până la WAN-uri extinse. Produsul se bazează pe experiența de mai mult de treizeci de ani în tehnologia simulării a celor de la CACI.

COMNET III folosește o abordare bazată pe "obiecte" (blocuri) care au corespondent în lumea reală. Un obiect din biblioteca COMNET III modelează cât mai realist unul sau mai multe obiecte reale, ai cărui parametri sunt ușor ajustabili pentru a corespunde cât mai fidel realității.

Mediul orientat pe obiecte al COMNET III oferă flexibilitatea de a încerca un număr nelimitat de scenarii de tipul "ce se întâmplă dacă…".

3.1. Descriere

COMNET III este un instrument de modelare și analiză a performațelor rețelelor de comunicații și calculatoare. Bazându-se pe descrierea rețelei, pe algoritmii săi de control și încărcare, COMNET III simulează funcționarea rețelei și furnizează măsuri ale performanței sale.

3.2. Aplicabilitate

COMNET III poate fi folosit pentru modelarea atât a WAN cât și a LAN. Modelele pot integra simultan și ambele tipuri. COMNET III poate asigura modelarea detaliată a logicii nodului de rețea. Calculatoarele unui nod, subsistemele sale de intrare ieșire, bazele de date și aplicațiile care rulează pe calculatoare pot fi toate modelate.

Folosind simularea prin metoda evenimentelor discrete, COMNET III furnizează cu acuratețe rezultate realiste. Alternativa la modelarea bazată pe evenimente discrete, este folosirea metodelor matematice tradiționale de analiză care nu pot face față efectelor variației aleatoare. Ipotezele simplificatoare cerute de metodele analitice ignoră efectele așteptării, independenței evenimentelor și variației aleatoare în analiza rețelelor complexe de comunicații.

Abordarea modelării rețelelor folosită de COMNET III este proiectată pentru a cuprinde o varietate largă de topologii de rețea și algoritmi de rutare și anume:

LAN, WAN și sisteme de interconectare a rețelelor (internetworking systems).

Rețele cu comutare de circuite, pachete și mesaje.

Trafic orientat pe conexiune și trafic fără conexiune (cu difuzare).

Algoritmi de rutare statici, adaptivi și definiți de utilizator.

O facilitate importantă a COMNET III este posibilitatea de a abstractiza porțiuni din modelul unei rețele și de a le trata ca pe componente modulare. Această facilitate derivă din natura orientată pe obiecte a COMNET III. Această facilitate permite de asemenea construirea unei biblioteci de dispozitive de rețea ce pot fi "conectate" și schimbate după plac.

3.3. Abordare generală

COMNET III este proiectat cu acuratețe pentru a estima caracteristicile de performanță ale rețelelor de calculatoare și comunicații. Estimarea înseamnă că rețeaua în studiu este descrisă printr-un set de date. COMNET III execută apoi o simulare dinamică a rețelei construind astfel o reprezentare a rețelei și rutează trafic simulat. Rapoartele sunt generate pentru performanțele măsurate ale diferitelor elemente ale modelului precum și ale caracteristicilor de ansamblu ale rețelei și sunt prezentate ca estimări ale performanțelor rețelei.

Datele folosite la descrierea rețelei sunt introduse cu ajutorul unei interfețe grafice cu utilizatorul și descriu:

Topologia rețelei: noduri, centre de calculatoare, conectivitate, etc.

Încărcarea plasată în rețea. Aceasta include aplicații care rulează pe sistemele terminale și traficul ce trebuie furnizat în rețea. Frecvența și mărimea diferitelor sarcini și operații pot fi descrise statistic.

Protocoalele și regulile de programare a aplicațiilor și de rutare a traficului.

Rapoartele generate sunt o estimare a performanțelor așteptate pentru rețeaua reală. Acuratețea lor depinde de datele introduse pentru descrierea rețelei. Una din întrebările majore este "Care este acuratețea datelor?" și implicit "Care este acuratețea estimării performanțelor?".

Un alt factor care determină acuratețea rezultatelor este durata simulării modelului. Aceasta determină câte evenimente aleatoare sunt folosite pentru a determina traficul generat statistic.

Având durata simulării stabilită, acuratețea rezultatelor este de obicei într-un interval de încredere.

COMNET III poate rula copii multiple, independente ale aceleiași simulări și poate calcula deviații medii, maxime, minime și standard precum și grafice și histograme ale performanțelor sistemului.

Odată ce este elaborat un model care estimează cu acuratețe performanțele rețelei reale ce trebuie studiate, pot fi încercate apoi tot felul de scenarii de tipul "Ce se întâmplă dacă…".

3.4. Tipuri de rețele modelate

O rețea este interpretată ca o interconectare arbitrară a dispozitivelor de calcul și comunicații pentru voce, date, video sau alte tipuri de trafic. Aceste dispozitive pot include terminale, stații de lucru, servere, interfețe, medii de conectare (de. ex. cablu torsadat, fibră optică), repetoare, punți, porți, routere, procesoare, hub-uri, comutatoare de pachete, legături de satelit, linii închiriate și multe altele.

Scopul COMNET III este de a furniza capacitatea de a include în simulare orice echipament de rețea. Interfața cu utilizatorul asigură o interconectare flexibilă pentru a putea descrie componentele rețelei. COMNET III nu furnizează o listă cu toate echipamentele posibile construite și folosite în rețele, ceea ce ar fi pe cât de imposibil pe atât de absurd. Folosește mai degrabă blocuri generice ce pot fi parametrizate pentru a reprezenta dispozitivele ce se doresc a fi modelate. De exemplu, dacă se dorește un server de tipărire, pentru care nu se găsește un obiect specific însă poate fi reprezentat cu ajutorul Nodului de Comunicații ce poate fi folosit pentru prelucrarea sarcinilor de tipărire.

O rețea de calcul este un sistem ca o rețea locală sau un centru de calculatoare. Există o populație de utilizatori conectată la ea, care cer rularea de aplicații fie local pe stațiile de lucru, fie distant pe un server, fie pe un calculator central (mainframe).

O rețea de telecomunicații este în general un sistem purtător sau de transport precum o rețea "backbone" sau o rețea de servicii publice, de exemplu un sistem X.25. Poate fi privată sau poate transporta traficul unei terțe părți, ca în rețeaua publică de telecomunicații, sau poate fi un sistem comercial. Ca și în cazul unui sistem de calcul, sunt conectați utilizatori la rețea, dar din punctul de vedere al operatorului de rețea se știe foarte puțin despre sistemele terminale care sunt servite. De exemplu un furnizor de X.25 nu știe că folosești un calculator personal sau o stație de lucru sau ce aplicație software folosești pentru a trimite mesaje prin rețea și nici ce va face receptorul cu mesajele primite. Ceea ce furnizorul de servicii vede este o simplă cerere de trafic de la o sursă la o destinație. El vrea să satisfacă această cerere cât mai rapid și cât mai eficient cu putință. În această categorie intră WAN și MAN.

3.5. Alegerea nivelului corect de detaliere a modelului

Oricare ar fi tipul de rețea modelat, trebuie ales nivelul de detaliere necesar pentru a răspunde la problemele supuse studiului. Uneori este folosit termenul de granularitate a modelului. Acest aspect al modelării trebuie gândit cu atenție deoarece are o mare influență asupra gradului de succes al simulării.

O lipsă a detaliilor poate duce la omiterea unor aspecte importante ale comportării sistemului. Prea multe detalii și poți sfârși cu un model mult mai mare decât este necesar și care necesită un timp mult prea mare pentru efectuarea unui experiment.

Modelarea mai multor detalii ale sistemelor terminale este obținută prin modelarea mai multor caracteristici ale acestora, împreună cu sarcina software ce le este repartizată. Este cazul des întâlnit al performanțelor slabe al serverelor datorită faptului că mulți utilizatori efectuează cereri de procesare concurente sau transfer de date de pe server. Dacă se dorește, COMNET III poate modela performanțele serverului la un nivel de detaliu considerabil și anume viteza procesorului, timpii de acces ai hard-disk-ului precum și secvențele de acțiuni software pe care serverul le întreprinde ca răspuns la fiecare cerere particulară. Pentru fiecare acțiune software dintr-o secvență, poate fi specificată încărcarea produsă în sistem (în termeni de cicluri ale procesorului).

COMNET III poate modela o subrutină specifică rulată pe un anume calculator dintr-o rețea mondială sau înglobarea capacității de trafic a unei rețele ca număr de tranzacții pe secundă.

3.6. Cele mai uzuale aplicații

Aplicațiile tipice COMNET III includ:

Studii ale vârfurilor de trafic (încărcare)

În general, o rețea este subiectul unor nivele critice de trafic în perioade diferite ale zilei, lunii sau anului. Dacă proiectarea rețelei poate face față acestor perioade, atunci poate face față oricăror situații. Folosirea tipică a COMNET III este deci modelarea acestor perioade de vârf pentru a înțelege aceste puncte de tensiune ale rețelei.

Dimensionarea rețelei în stadiul de proiectare

La proiectarea unei rețele trebuie luată în considerare o eventuală extindere. COMNET III poate fi folosit pentru a estima dacă proiectul face față diferitelor nivele de trafic și pentru a vedea ce loc mai rămâne pentru o eventuală creștere.

Introducerea unor noi utilizatori / aplicații

Noi utilizatori / aplicații vor aduce un plus de încărcare a rețelei. Este utilă încercarea predicției impactului acestora înainte de introducerea lor putând fi astfel detectate și rezolvate potențialele blocaje înaintea apariției unei probleme majore.

Studiul situațiilor de defectare și a capacităților de revenire

Este adesea important de știut că un proiect de rețea are suficientă capacitate de revenire pentru a oferi un nivel satisfăcător de performanță în cazul diferitelor scenarii de defectare. Nodurile și elemetele de legătură pot fi intenționat defectate și recuperate la momente diferite pentru a încerca diferite scenarii care nu sunt testabile în sistemele reale.

Evaluarea opțiunilor de îmbunătățire a performanței

Multe rețele au creșteri de trafic de la an la an. Acest fenomen duce la deteriorarea performanțelor până când rețeaua suportă un upgrade într-un fel sau altul. Numeroasele opțiuni de upgrade pot fi investigate în COMNET III ca o parte a unui studiu cost / profit.

Evaluarea contractelor de servicii

Devine o practică din ce în ce mai răspândită negocierea contractelor pentru nivelul serviciilor între utilizatorul și furnizorul de rețea chiar dacă fac parte din aceeași organizație. COMNET III poate fi folosit să analizeze nivelele de performanță ale serviciilor ce pot fi obținute în timpul negocierii contractului și pentru a prezice zonele potențiale de probleme pe măsură ce schema de folosire o rețelei se schimbă cu timpul.

CAPITOLUL

IV

ETAPELE MODELĂRII ȘI SIMULĂRII UNEI REȚELE DE

COMUNICAȚII FOLOSIND COMNET III

4.1. Generalități

Această secțiune descrie cele etapele modelării și simulării unei rețele de comunicații folosind pachetul de programe COMNET III.

Etape principale:

Construirea topologiei rețelei(v. 4.2.)

Adăugarea traficului și încărcării rețelei (v. 4.3.)

Definirea algoritmilor de rutare și a protocoalelor de transport (v. 4.4.)

Controlul simulării (v. 4.5.)

Generarea rapoartelor statistice (v. 4.6.)

Anexe:

Distribuții statistice definite de utilizator (v. 4.7.)

Biblioteci (v. 4.8.)

Fișierele modelului (v. 4.9.)

Aceste subsecțiuni corespund diferiților pași de urmat în construirea unui model COMNET III. În mod tipic, prima este construită topologia rețelei, urmată de adăugarea surselor de trafic și încărcare și ulterior de setarea parametrilor pentru operarea (funcționarea) rețelei. Parametrii necesari controlului simulării setează experimentul și rularea simulării. Înaintea rulării simulării trebuie solicitate diferite rapoarte statistice pentru vizualizarea rezultatelor în timpul și după simulare. Distribuții ale utilizatorului sunt disponibile pentru folosirea unor distribuții tabelare sau predefinite pentru a reprezenta o parametrizare specifică a unei distribuții incluse în bibliotecă. Pe măsură ce modelul este construit, COMNET III menține câteva biblioteci pentru folosire și refolosire în cadrul acestuia. Este disponibilă o bibliotecă arhivă ce permite refolosirea obiectelor în cadrul altor modele. Astfel, modelul este portabil către alte calculatoare pe care rulează COMNET III.

4.2. Construirea topologiei rețelei

Topologia rețelei descrie structura și resursele care modelează rețeaua locală. Topologia este definită de trei componente de bază: noduri (nodes) pentru hardware (calculatoare și switch-uri), link- uri pentru a transporta trafic între noduri și conectori (arcs) pentru asocierea nodurilor la link-uri. Conectorii arată care noduri folosesc legături și în particular, modelează conectarea portului nodului la legătură (link).

Pe lângă noduri și legături, mai există trei componente care au topologii interne: Subrețeaua (Subnet) și Rețeaua de tranzit (Transit Net) pentru modelarea domeniilor independente de rutare și topologiilor ierarhizate, precum și Norul WAN (WAN Cloud) pentru modelarea de servicii WAN. În fiecare din cazuri, obiectele reprezentate prin iconuri sunt similare cu nodurile și legăturile în privința setării parametrilor generali dar au și o topologie internă pentru o modelare mai detaliată. Punctele de acces (Acces points) sunt folosite pentru interfața dintre conectori, între topologiile externe și cele interne.

4.2.1. Noduri

COMNET III are trei tipuri principale de noduri: nod de procesare (processing node), grup de calculatoare (computer group node) și dispozitiv de rețea (network device node). Un al patrulea tip de noduri, care nu este disponibil direct din paleta de obiecte din interfața grafică este switch-ul cu blocare – cap de linie (Head Of Line Blocking Switch). Acesta poate fi introdus din meniul Library selectând Bring Into Model / Nodes / HOL Blocking Switch.

Nodurile de procesare și grupurile de calculatoare modelează calculatoare. Aceste noduri pot genera și recepționa trafic și pot modela aplicații mai complexe privind utilizarea procesorului și stocarea internă. Nodurile de procesare pot de asemenea modela punți (bridges), porți (gateways) și comutatoare (switches) pentru că pot ruta trafic prin ele însele. În contrast, grupurile de calculatoare sunt restricționate la modelarea sistemelor terminale pentru că nu pot fi decât surse sau destinații (sinks) de trafic.

Dispozitivele de rețea modelează hardware folosit pentru rutarea traficului, inclusiv routere, hub-uri și switch-uri. Dispozitivul de rețea este similar nodului de procesare prin faptul că poate fi sursă sau destinație (bazin) de trafic și poate rula aplicații ce utilizează procesorul intern și stocarea internă. În orice caz, adaugă un model pentru o structură de magistrală internă pentru a transporta trafic între porturi de intrare și ieșire.

Cele trei tipuri de noduri descrise mai sus pot fi surse de trafic și resurse pentru încărcare. Aceasta înseamnă că pot accepta surse de trafic și aplicații descrise în paragraful Trafic și Încărcare în Rețea. Pentru a modela aplicații, aceste noduri includ un repertoar de comenzi și un set de parametri. Modelarea aplicațiilor este descrisă în paragraful Aplicații.

În plus față de nodurile de procesare și dispozitivul de rețea, pentru rutarea traficului mai există și HOL blocking switch destinat exclusiv rutării. Modelează o matrice de rutare care este ilustrativă pentru multe switch-uri care necesită foarte puțin timp pentru a transporta un pachet dintr-un buffer de intrare într-un buffer de ieșire. Acest nod poate manevra pachete de orice mărime și spre deosebire de tipurile de mai sus, acest nod nu poate fi o sursă sau un bazin de trafic, astfel că nu i se poate atașa nici o sursă.

Nodul de procesare, dispozitivul de rețea și switch-ul cap de linie cu blocare sunt capabile de asemenea a modela noduri într-o rețea de apeluri cu comutare de circuite.

4.2.2. Legături (links)

În COMNET III sunt disponibile două clase de modele de legături: legături punct-la-punct (point-to-point link) pentru a reprezenta un canal între numai două noduri și legături multiacces (multiaccess links) pentru rețele locale și alte situații în care două sau mai multe noduri împart aceleași mediu de comunicații.

Legăturile punct-la-punct modelează canale de comunicații între două noduri. În mod obișnuit, aceste conexiuni sunt dedicate, precum o linie serială, în particular între routere în cadrul WAN sau în cadrul rețelelor multisalt (mulithop networks).

Modelul norului WAN furnizează legături de acces la serviciile WAN folosind o variantă a unei legături punct-la-punct disponibilă în interiorul norului (vezi paragraful Norul WAN).

Legăturile multiacces disponibile în COMNET III modelează numeroase protocoale pentru folosirea unui singur mediu cu noduri multiple. Protocoalele de acces multiplu includ CSMA/CD (Carrier-Sense Multiple-Access with Carrier Detection sau Ethernet), CSMA, Aloha, Token Passing (token ring, FDDI, token bus), Polling, FDDI, Priority Token Ring, CSMA/CA, Demand Assigned Multiple Access (DAMA), STK (Satelite Telcommunication Kit) pentru modelarea legăturilor prin satelit, Link Group pentru modelarea Ethernet comutat și seturi de parametri ISDN și SONET.

4.2.3. Subrețele

Obiectul Subrețea din COMNET III este folosit pentru modelarea ierarhică a unei rețele astfel că subrețelele separate au algoritmi de rutare independenți și separați de rețeaua de bază (backbone). Iconul Subrețea este asemănător unui nod prin faptul că se poate conecta numai la legături. În interiorul subrețelei, topologia este asemănătoare nivelului superior (nivelul de bază). Este posibilă plasarea de subrețele în interiorul altei subrețele.

Conexiunile între topologia internă a subrețelei și topologia structurii de bază se face prin puncte de acces (access points ). Pot fi oricâte puncte de acces într-o rețea. A se nota însă că traficul va fi rutat în subrețea conform algoritmului de rutare al nivelului superior. Aceasta înseamnă că dacă ruta din rețeaua de bază, aleasă în subrețea, nu este conectată la destinație, traficul va fi blocat.

În interiorul subrețelei, se atașează un nod la punctul de acces și acel nod devine un gateway, care poate ruta pachete către rețeaua de bază, către subrețele, cât și între acestea. În afara subrețelei, punctul de acces poate fi editat să acceseze gateway-ul însă din punctul de vedere al rețelei de bază.

Subrețeaua este folosită în principal pentru modelarea interconectării subrețelelor cu algoritmi de rutare independenți. Poate fi folosită de asemenea pentru construirea ierarhică a unei rețele complexe pentru a ascunde detaliile la o privire de ansamblu. Mai mult, algoritmii de rutare independenți ai subrețelei intră adesea în conflict cu cerința de a avea o rețea complexă care să fie guvernată de același algoritm de rutare. În cazul când rețele mari trebuie modelate într-un singur domeniu de rutare, topologia ar trebui plasată în întregime în rețeaua de bază.

4.2.4. Rețele de tranzit

Rețelele de tranzit pot fi privite ca rețele intermediare care modelează traficul ce trece prin ele. O rețea de tranzit se poate comporta atât ca subrețea cât și ca legătură. Este o abstractizare a unei legături care transmite pachete de la buffer-ul de ieșire al unui nod conectat la rețea către buffer-ul de intrare al altui nod conectat la ea. În interior, rețeaua de tranzit se comportă ca o subrețea și introduce un nivel de protocol suplimentar la limitele sale. Ca și în cazul subrețelelor, algoritmul de rutare independent intră adesea în conflict cu cerința de a avea o rețea complexă care să fie guvernată de același algoritm.

4.2.5. Nori WAN

Norul WAN este disponibil pentru a modela abstract servicii WAN, în termeni de legături de acces (access links) și circuite virtuale (virtual circuits). Un model abstract este folositor când detaliile suplimentare ale unui model mai explicit al serviciului nu sunt fie necesare, fie disponibile.

Topologic, un nor WAN este similar unei legături prin faptul că se nu se poate conecta decât la noduri. Norul WAN are o topologie internă constând numai în legături de acces și circuite virtuale. Circuitele virtuale sunt modele abstracte ale unor seturi de switch-uri și legături și se conectează numai la legături de acces: arcul de conectare la acestea apare sub formă de linie punctată pentru a distinge această legătură abstractă de conexiunile fizice folosite în rețeaua de bază. Legătura de acces este un caz particular de legătură punct la punct ce funcționează numai în interiorul unui nor WAN.

În afara norului WAN, conexiunea între un nod și nor se face printr-un punct de acces. La punctul de acces într-un nor WAN se poate conecta doar un singur nod de procesare, iar în interior se poate conecta doar o legătură de acces.

Circuitele virtuale pot fi dispuse între oricare legături de acces sursă și destinație. Pentru fiecare pereche de aceste legături de acces sursă/destinație, poate exista cel mult un circuit virtual. Modelele circuitelor virtuale sunt direcționale, cu sensul reprezentat de săgețile figurate pe arcele punctate ce le conectează de legăturile de acces. Circuitele virtuale sunt opționale în interiorul norilor WAN: dacă un circuit virtual lipsește între sursa și destinația unui frame, acel frame va fi rutat prin nor dacă este activă opțiunea "assume a direct unconstrained VC" (se presupune un circuit virtual direct nerestricționat).

4.2.6. Arce și porturi

În topologiile rețelelor de bază și ale subrețelelor, arcele ce conectează legăturile la noduri reprezintă interfața nodului cu mediul legăturii. Proprietățile arcelor sunt editabile pentru a seta parametrii portului (întârziere, buffere) și ai legăturii (tabele de penalizare pentru rutare).

4.3. Adăugarea traficului și încărcării rețelei

Sursele de trafic și încărcare adaugă stimulul necesar topologiei rețelei pentru funcționarea simulării. Traficul rețelei se referă la mesajele care sunt trimise între nodurile topologiei, iar încărcarea rețelei se referă la activitățile interne ale procesoarelor și magistralelor nodului.

În COMNET III sunt disponibile mai multe surse de trafic:

– sursa de aplicații : execută comenzi care introduc fie trafic în rețea, fie încărcare în interiorul nodurilor.

– sursele de mesaje , de răspuns , de sesiune și de apel sunt surse simple care generează trafic între noduri.

Deoarece nodurile pot avea cerințe de procesare pentru traficul care circulă între ele, comenzile și sursele de trafic vor introduce implicit și încărcare în noduri. Prin contrast, comenzile de încărcare, pot numai întârzia traficul prin utilizarea procesorului când traficul are nevoie de el.

În timpul simulării, COMNET III poate anima traficul sub formă de jetoane reprezentând frame-uri și pachete ce intră și ies din legături. Animația poate fi observată de-a lungul arcelor ce reprezintă porturi sau conexiuni la legături.

4.3.1. Programarea (temporizarea) surselor

Există trei metode prin care funcționarea surselor poate fi programată: prin timpi iterativi, prin textele unor mesaje recepționate sau printr-un declanșator (trigger).

La un nod se pot atașa oricâte surse este necesar. Sursele conectate la un nod pot avea metode diferite sau identice de programare. Dacă mai multe surse sunt declanșate simultan, atunci comenzile vor intra într-un șir de așteptare pentru a fi servite succesiv de procesor.

Iterația, sau programarea temporală permite surselor să fie declanșate conform unui interval scurs de la o sosire anterioară. Există opțiuni pentru pornirea și oprirea sursei în anumite momente ale simulării. Într-un model, trebuie să fie programată cel puțin o sursă pentru ca simularea să funcționeze. Timpii de pauză ai surselor dintr-o rețea de bază sau o subrețea pot fi scalați de parametrul Traffic Time Scale.

Programarea de către textul unui mesaj recepționat furnizează o metodă de declanșare a surselor dependentă de anumite mesaje recepționate la nod. Textul mesajului este o etichetă atașată acestuia de către sursa sau comanda care îl trimite. Scopul acestui text este de a declanșa sursa dorită aflată la destinație. Textul mesajului nu reprezintă de obicei conținutul acestuia. Sursa declanșată de textul mesajului poate necesita mai multe mesaje diferite sau mai multe copii ale aceluiași mesaj. Este disponibil și un identificator pentru a permite declanșarea de clase de mesaje.

La nodul destinație, pot exista câteva surse ce așteaptă același text al unui mesaj. În acest caz, va fi activă o singură sursă care va primi următoarea copie a mesajului. După ce este declanșată, următoarele copii ale mesajului vor fi folosite pentru a declanșa celelalte surse într-o ordine circulară. În general, o singură sursă așteaptă un anume mesaj.

4.3.2. Aplicații

Aplicațiile reprezintă un mijloc flexibil de generare atât de trafic cât și de încărcare într-un anume nod. Aplicația este alcătuită din trei părți: parametrii nodului pentru specificarea vitezelor procesoarelor și dispozitivelor de stocare, repertoriul de comenzi pentru specificarea diferitelor acțiuni ce pot avea loc într-un nod și sursa de aplicații pentru a programa o secvență de comenzi.

Încărcarea într-un nod este controlată de parametrii fizici pentru timpii de procesare și de stocare. Implicit acești timpi sunt zero, reprezentând procesoare infinit de rapide și stocare infinită. Pentru a obține încărcare într-un nod, parametrii trebuie setați nenuli. Sunt disponibili parametri pentru timpul de procesare per ciclu, utilizat de comanda de proces, parametri de stocare pentru comenzile de citire și scriere și timpi de procesare pentru traficul ce are ca sursă ori destinație acest nod sau îl tranzitează.

Comenzile de trafic includ: Transport Message, Setup Session, Answer Message, Wait For, Macro, Assign Variable.

Comanda Transport Message trimite un singur mesaj unei singure destinații sau unui set de destinații. Mesajele generate de această comandă sunt întotdeauna trimise sub forma datagram în care fiecare pachet al mesajului este rutat independent.

Comanda Setup trimite un pachet de inițializare și recepționează un pachet de confirmare. După ce se stabilește sesiunea de lucru, în timpul acesteia se pot trimite pachetele mesajelor. Aceste mesaje trimise în timpul unei sesiuni pot fi rutate ce datagram sau ca circuit virtual în funcție de algoritmul de rutare al rețelei de bază sau al subrețelei conținând nodul ce execută comanda.

Comanda Answer Message este o comandă specială care trimite mesajul înapoi la sursa care l-a trimis și care a declanșat aplicația. Această comandă poate fi folosită numai pentru surse care sunt declanșate de un mesaj recepționat. Mesajul de răspuns este rutat prin aceeași metodă folosită de mesajul declanșator.

Comanda Wait For produce suspendarea de către nod a tuturor operațiilor până la recepționarea unui mesaj cu o etichetă corespunzătoare care este definită în parametrii acestei comenzi. Odată ce mesajul așteptat este recepționat, suspendarea este terminată și nodul reia execuția următoarei comenzi a sursei de aplicații.

Încărcarea este introdusă implicit de trafic în nod prin parametrii de procesare a pachetelor. În plus, există trei comenzi specifice pentru încărcare.

Comanda Process este destinată modelării calculelor interne. Ocupă procesorul nodului pentru o anumită durată de timp.

Comenzile Read și Write ocupă de asemenea procesorul, dar în contextul citirii și scrierii fișierelor. Pe lângă ocuparea procesorului, comenzile write și read vor modifica și spațiul de stocare.

Comanda Macro reprezintă o metodă de a organiza comenzi care sunt folosite frecvent împreună. O comandă Macro conține o secvență de comenzi la fel ca o sursă de aplicații.

Comanda Assign Variable este folosită pentru ințializarea unei variabile definite.

4.4. Definirea algoritmilor de rutare și a protocoalelor de transport

Operarea rețelei specifică metoda de rutare a mesajelor printr-un Algoritm de Rutare și metoda de transmitere printr-un Protocol de Transport.

4.4.1. Algoritmi de rutare

Fiecare subrețea, rețea de tranzit și rețeaua de bază au algoritmi de rutare independenți care sunt specificați în ferestrele de dialog corespunzătoare. În plus se pot alege metode diferite pentru comutarea de pachete și pentru cea de circuite care sunt manevrate independent de COMNET III. Detaliile algoritmului de rutare includ de asemenea o opțiune pentru Rutare orientată pe conexiune pentru sesiuni (Connection- Oriented Routing) în scopul folosirii circuitelor virtuale pentru traficul de date, sau o opțiune de Preemption pentru a oferi această facilitate traficului de apeluri.

În COMNET III sunt disponibili mai mulți algoritmi de rutare. Există algoritmi statici care calculează tabelele de rutare chiar la începutul simulării sau ori de câte ori se defectează (sau se repară) o legătură sau un nod. Există de asemenea algoritmi dinamici care actualizează periodic tabelele de rutare bazate pe măsurători dinamice care sunt monitorizate în intervale specificate. În plus, unele protocoale de rutare pot necesita Tabele de Penalizare pentru a fi aplicate fiecărui arc (conexiunea între un nod și o legătură) în scopul asocierii de penalizări pentru fiecare de direcție de trafic prin legătură. COMNET III folosește o convenție de tip "de la nod la legătură" pentru a stabili direcția traficului pentru tabelele de penalizare. Pentru fiecare Clasă de rutare, tabelele de penalizare specifică diferite valori ale penalizării pe care o anume clasă le primește la trecerea printr-un anume arc specificat în tabelul de rutare. Tabelele de penalizare implicite asociate legăturilor, au o penalizare de 1 punct pentru fiecare salt (între două noduri alăturate), forțând astfel orice algoritm bazat pe tabelele de penalizare să se transforme în rutare de tip Număr minim de salturi (minimum hop) în cazul în care nu sunt specificate tabele suplimentare.

Tabelele de rutare sunt create și actualizate pe acea rută sau set de rute care au cea mai mică penalizare. Diferența între algoritmii de rutare constă în modul de calcul al penalizărilor. Tabelele de rutare conțin o rută sau un set de rute pentru fiecare triplet nod sursă, nod destinație și clasă de rutare. Fiecare mesaj are o clasă de rutare asociată de către comanda sau sursa acestuia. Clasa de Rutare specifică aceleași proprietăți de rutare pentru o anume clasă de mesaje.

Implicit, algoritmii de rutare vor alege o singură rută pentru fiecare triplet sursă-destinație-clasă de rutare, chiar dacă sunt disponibile rute multiple cu penalizare minimă identică (caz în care COMNET III va direcționa traficul pe prima rută găsită). Este disponibilă de asemenea echilibrarea penalizărilor pentru mai multe căi minime prin intermediul valorii Deviation % for multiple shortest paths disponibilă în fereastra de dialog a algoritmului de rutare. Dacă această valoare este nulă, atunci tot traficul va fi rutat pe primul traseu găsit cu penalizare minimă.

Pentru traficul cu comutare de pachete (date) sunt diponibili șase algoritmi de rutare:

Algoritmul RIP Minimum Hop (număr minim de salturi) alocă 1 punct de penalizare pentru fiecare salt și selectează astfel ruta cu număr minim de salturi. Acesta este un algoritm static care nu utilizează tabelele de penalizări ale legăturilor.

Shortest Measured Delay (cea mai mică întârziere măsurată) alocă legăturilor penalizări bazate pe întârzierea măsurată care este suma întârzierilor datorate buffer-ului de ieșire, transmisiei și pachetelor pentru fiecare legătură din cale.

Link-State Shortest Path First (cea mai scurtă cale în funcție de starea legăturii) folosește tabelele de penalizare asociate diferitelor legături. Este un algoritm static dar necesită definirea tabelelor de penalizare pentru fiecare legătură.

Minimum Penalty (penalizare minimă) folosește tabelele de penalizare care pot avea diferite valori ale penalizării pentru diferite nivele de congestie (măsurate ca întârzieri sau utilizare). Datorită pragurilor de congestie, acesta este un algoritm dinamic și are un interval de actualizare a rutării.

IGRP și Extended IGRP folosește o penalizare totală care este suma diferitelor penalizări pentru banda disponibilă, utilizare și întârziere disponibile în tabel. Acest algoritm este dinamic.

OSPF Standard modelează strategia de rutare OSPF unde toate porturile au caracteristici implicite definite de în funcție de lărgimea de bandă a legăturii.

Tabele de rutare definite de utilizator permit specificarea de rute arbitrare în interiorul rețelei cu selectarea de către utilizator a metodelor de alegere între diferite alternative disponibile.

Pentru traficul cu comutare de circuite (apeluri) sunt disponibili trei algoritmi de rutare:

Algoritmul Minimum Hop (salt minim) alocă un singur punct de penalizare pentru fiecare salt și selectează astfel ruta care necesită cel mai mic număr de salturi. Acesta este un algoritm static și nu folosește tabelele de penalizare disponibile la legături.

Algoritmul Minimum Penalty (penalizare minimă) folosește tabelele de penalizare care pot avea diferite valori pentru diferite nivele ale utilizării legăturii. Datorită pragurilor de congestie, acest algoritm este dinamic și are un interval de actualizare a rutării.

Tabelele de rutare definite utilizator permit specificarea de rute arbitrare în interiorul rețelei cu selectarea de către utilizator a metodelor de alegere între diferite alternative disponibile.

4.4.2. Protocoale de transport

Protocolul de transport controlează modul în care rețeaua livrează un mesaj de la sursă la destinație. La nodul sursă, un mesaj va avea un anumit protocol de transport. Acesta va stabili mărimea pachetelor mesajului, overhead-ul in pachet, tipul controlului de flux folosit și când se retransmit pachetele blocate. Rețeaua rutează apoi fiecare pachet de la nod la nod până când ajunge la destinație.

Protocoalele de transport ale COMNET III modelează protocoale de nivel Transport (din modelul OSI) în termeni de identificator de protocol, mărimea pachetului, metoda de control al fluxului și un interval de retransmisie pentru pachete pierdute sau eronate. COMNET III deține și menține o listă a protocoalelor de transport, fiecare dintre acestea fiind o combinație a parametrilor nivelului transport. Pentru a modela diferite suite de protocoale precum TCP/IP, IPX, DECNet, SNA, etc., lista protocoalelor de transport poate fi construită astfel încât să includă diferite componente (articole ale listei) care să ilustreze diferite situații.

Identificatorul de protocol este un nume care clasifică o suită sau o clasă de protocoale care vor produce efecte asemănătoare, de exemplu întârzieri în routere. De exemplu, pachetele IP vor avea cerințe similare de procesare la routere chiar dacă ceilalți parametri ai protocolului de transport pot varia în funcție de numeroase condiții. Nodul de rutare folosește atunci identificatorul de protocol pentru a determina viteza de procesare a pachetului. Multe articole din listă pot avea același identificator. Acest câmp de identificare este important în special pentru modelarea routerelor multiprotocol care vor necesita diferite volume de procesare în funcție de fiecare protocol. În realitate, diferitele protocoale necesită diferite procesări la nodurile de rutare și aceasta poate fi modelată în COMNET III cu identificatorul de protocol, folosit pentru a selecta diferite întârzieri în noduri.

Pachetul end-to-end creat de protocolul de transport determină volumul maxim de date ce poate fi transportat de un singur pachet. Pachetul transmis va primi în plus un overhead care reprezintă octeții header-ului și trailer-ului, cu alte cuvinte toții octeții unui pachet care nu fac parte din mesajul propriu-zis.

Pachetele vor fi trimise conform unei metode de control a fluxului. COMNET III asigură metodele fereastră fixă (fixed window), fereastră culisantă (sliding window), fereastră secvențială SNA (SNA-pacing window) precum și varianta lipsei controlului de flux. Există de asemenea modele îmbunătățite ale acestor algoritmi plus un algoritm specific ferestrei de congestie a TCP/IP. Protocoalele rețelelor X.25 și LAN folosesc de obicei fereastra fixă în timp ce multe alte protocoale precum TCP/IP folosesc fereastra culisantă.

Pentru modelarea serviciilor bazate pe frame (precum frame-relay sau ATM), protocoalele au doi algoritmi suplimentari: unul de politică a traficului și unul de formare a traficului sau de control al ratei.

4.5. Setarea parametrilor simulării

După ce un model este gata pentru simulare, comenzile din meniul Simulate pot fi folosite pentru controlul simulării.

Comanda Verify Model testează corectitudinea modelului și dacă e complet pentru a rula simularea. Această comandă este executată automat înaintea pornirii simulării însă poate fi dată și separat fără a porni simularea, pentru verificări intermediare.

Rubrica Run Parameters folosește la definirea experimentului de simulat. Include numărul de repetări ale simulării pentru colectarea rezultatelor statistice, perioada de inițializare (încălzire) în care nu se adună rezultate și numărul de repetări pentru numărul rapoartelor.

Înaintea sau în timpul simulării, sunt disponibile meniurile Animate… și Trace… pentru a seta parametrii animației sau urmăririi.

4.6. Generarea rezultatelor

Rapoartele COMNET III prezintă statistici pe un anume subiect și pentru obiectele selectate. Meniul Report/Select Reports afișează diferitele rapoarte ce pot fi activate pentru diferite obiecte ale modelului. Browse Reports invocă un editor de text pentru a deschide fișierul modelului în scopul vizualizării rezultatelor. Raportul curent este păstrat într-un fișier ASCII în subdirectorul cu același nume ca al modelului și în fișierele Statn.rpt, unde n este numărul repetării simulării.

Pe lângă rapoarte, sunt disponibile rezultate colectate pentru anumite obiecte. Acestea sunt disponibile prin butonul Statistics… pentru noduri, legături, surse de trafic și circuite virtuale. În funcție de tipul obiectului sunt puse la dispoziție diferite tipuri de parametri și pentru fiecare există opțiunea de a colecta valori de bază (minim, maxim, mediu și deviația standard) sau observații pentru reprezentări grafice și analiză după încheierea simulării, caz în care sunt disponibile histograme și procente. Sunt de asemenea disponibile monitorizări în timp real pentru reprezentarea grafică a unei variabile în timpul simulării.

4.7. Distribuții statistice definite de utilizator

COMNET III pune la dispoziție câteva distribuții analitice pentru parametrii care sunt variabile aleatoare. Lista predefinită poate fi extinsă prin introducerea de noi distribuții cu ajutorul Tabelelor de Distribuție sau prin modificarea parametrilor unei anume distribuții analitice.

O distribuție utilizator este o distribuție cu o etichetă și un set specifice de parametri pentru o distribuție analitică particulară și este folositoare în modelele complexe deoarece toate distribuțiile sunt disponibile din meniul User Distributions și pot fi folosite în mai multe locuri.

O distribuție tabulară este de asemenea identificată printr-un nume dar constă într-un tabel de valori cu probabilitățile corespunzătoare pentru a reprezenta distribuții continue sau discrete.

4.8. Biblioteci de obiecte

COMNET III menține o bibliotecă de obiecte. Aceasta include seturi de parametri pentru noduri și legături, clase de rutare și protocoale de transport pentru mesaje, tabele de penalizare pentru algoritmii de rutare și distribuții definite și tabele de distribuții. Pe măsură ce sunt create noi articole, ele sunt introduse în bibliotecă fiind disponibile pentru refolosire în cadrul modelului.

4.9. Fișierele modelului

Fișierele modelelor create în COMNET III au extensia .c3. Va exista de asemenea un subdirector cu același nume ca al modelului în care se vor afla fișierele cu rezultatele solicitate și colectate.

CAPITOLUL V

DESCRIEREA MODELĂRII ORIENTATE PE OBIECTE

5.1. Descriere generală

Pachetul de programe COMNET III furnizează o bibliotecă vastă de obiecte care oferă o flexibilitate excelentă pentru modelarea unor rețele de comunicații și subansamble ale acestora ce pot acoperi aproape întregul spectru al telecomunicațiilor astfel că nu s-ar justifica în această lucrare un studiu și o prezentare a tuturor obiectelor COMNET III, atât din punct de vedere al timpului și volumului lucrării cât și din punct de vedere al rezultatelor ce se urmăresc a se obține în urma aplicațiilor prezentate în acest material. Aceste aplicații sunt orientate în principal pe modelarea rețelelor de comunicații orientate pe comutare de circuite. În consecință vor fi prezentate obiectele din biblioteca COMNET III care folosesc acestui scop.

COMNET III poate fi folosit pentru modelarea rețelelor cu comutare de circuite ce transportă voce, fax, video sau tipuri de date specifice comutării de circuite. Acest tip de trafic este definit de parametri ca timpul între apeluri, timpul de menținere și banda necesară pentru conexiunea cap-la-cap.

După generarea apelului, este luată o decizie de rutare pentru atingerea destinației. Dacă ruta este disponibilă, se rezervă bandă de-a lungul ei pe durata apelului. Dacă nu este disponibilă nici o rută (fie din cauza defectării nodului sau legăturii, fie din cauza congestiei), apelul este blocat și opțional va reîncerca peste un anumit timp.

Un model cu comutare de circuite este construit folosind noduri de procesare ca origini/destinații de trafic, și switch-uri. Conectarea este implementată folosind legături punct-la-punct, DAMA sau legături STK. Pentru generare de trafic sunt folosite surse de apeluri, a căror bandă este definită de clasa de rutare. Traficul cu comutare de circuite poate fi generat numai în noduri de procesare și poate fi transportat numai de legături punct-la-punct, DAMA sau STK. Pentru comutare pot fi folosite de asemenea dispozitive de rețea și comutatoare cu blocare (HOL Blocking Switch).

Când se efectuează un apel, trebuie luată o decizie de rutare pentru stabilirea căii. Într-un sistem real, această procedură va necesita un interval scurt de timp, după care este disponibil un circuit cap-la-cap pentru traficul cu comutare de circuite. Durata traficului (de ex. un apel de voce) este de obicei mult mai mare decât întârzierea datorată stabilirii rutei.

În COMNET III, întârzierile datorate setării (stabilirii apelului) sunt ignorate. Când este generat un apel, se ia instantaneu o decizie de rutare prin inspectarea tabelelor de rutare curente. Dacă o rută este disponibilă și dispune de banda necesară în toate legăturile și comutatoarele de-a lungul căii, aceasta va fi instantaneu alocată și apelul va ti tratat ca rutat.

Dacă apelul este blocat, în funcție de setările utilizatorului, poate fi anulat, reîncercat ulterior sau se poate executa o procedură de pregolire (preemtion) asupra traficului cu prioritate mai mică.

Pot fi generate următoarele rapoarte:

Blocked Call Report (apeluri blocate)

Disconnected Call Report (apeluri deconectate)

Preempted Call Report (apeluri pregolite)

Calls by node (apeluri prin nod)

Calls by link (apeluri prin legătură)

Utilization by node (utilizarea nodului)

Utilization by link (utilizarea legăturii)

5.2. Biblioteca de obiecte

5.2.1. Sursa de apeluri

O sursă de apeluri este folosită pentru generarea de trafic cu comutare de circuite. Pot fi folosite surse separate de apeluri, în aceeași origine, de exemplu una pentru trafic de voce, una pentru date și una pentru fax. Sursa de apeluri specifică volumul unui tip particular de apel ce urmează a fi generat. Rutarea fiecărei secvențe de apel este rutată de Protocolul de rutare a apelurilor (Call Routing Protocol).

O sursă de apeluri poate fi conectată numai la un nod de procesare. Banda necesară apelului este un parametru al clasei de rutare.

Sursa de apeluri poate fi privită ca un prototip care va crea periodic secvențe de apel pentru a fi rutate de model. Este sarcina prototipului să verifice dacă s-au îndeplinit condițiile de temporizare pentru un nou apel și să-l genereze. Singura metodă de temporizare disponibilă este Iteration Time (timpul de iterație) ce reprezintă intervalul de timp între momentele generării a două apeluri consecutive (bineînțeles de către aceeași sursă). O dată ce o secvență de apel a fost inițiată, este treaba protocolului de rutare să transporte apelul la destinație.

Pot fi generate următoarele rapoarte:

Calls: Blocked

Calls: Disconnected

Calls: Preempted

Calls: By Node

Calls: By Link

Calls: Utilization by Node

Calls: Utilization by Link

Parametrii sursei de apel:

Name:

Un câmp alfa-numeric pentru identificarea sursei de apel.

Icon:

Numele iconului folosit pentru reprezentarea sursei de apel.

Schedule by:

Secvențele de apel pot fi temporizate prin Iteration Time (timpul de iterație) care folosește timpii dați ca interval între momentele de inițiere a două apeluri consecutive.

Folosind această metodă de temporizare se pot suprapune mai multe apeluri folosind aceeași sursă.

Interarrival Time Distiribution:

Folosește pentru alegerea unei valori statistice a intervalului de timp între generările apelurilor.

Uzual, Interarrival Time se bazează pe o distribuție exponențială, ce are ca rezultat o generare a apelului conform unui proces Poisson.

First arrival:

Este momentul generării primului apel. Dacă este lăsat cu valoarea none, primul apel va fi generat după un timp ales aleator între 0 și media valorii distribuției alese pentru Interarrival Time.

Last arrival:

Reprezintă momentul de timp când va fi generat ultimul apel. Dacă este lăsat pe none apelurile vor fi generate pe toată durata simulării.

Duration:

Durata apelului. Poate fi folosită orice distribuție existentă în COMNET III. O secvență de apel este o cerere de menținere a unei anumite lărgimi de bandă între origine și destinație, pentru o perioadă dată de timp.

Se obișnuiește măsurarea traficului de voce în Erlang. Încărcarea în Erlang nu este direct introdusă în COMNET III, dar poate fi calculată cu ajutorul valorilor Interarrival Time și Duration, astfel:

Timpul de menținere și timpul între generări (sosiri) trebuie introduși în aceleași unități de timp.

Nu trebuie făcută confuzie între Încărcarea Erlang și Distribuiția Erlang deoarece sunt lucruri complet diferite.

Durata apelului respectă de obicei o distribuție normală.

Priority:

Câmpul Priority este folosit pentru stabilirea priorității fiecărui apel. În modelul cu comutare de circuite, prioritatea este folosită numai cu activarea opțiunii de pregolire (preemtion). Aceasta permite apelurilor cu prioritate mai mare care nu găsesc o rută liberă să elibereze apeluri cu prioritate inferioară, pentru a putea fi rutate. În funcție de setările clasei de rutare, apelul cu prioritate mică poate fi reîncercat. Apelul eliberator nu trebuie să aibă obligatoriu aceeași origine și destinație cu apelul eliberat. Singura cerință este ca cele două apeluri să necesite aceeași bandă. Valori mai mari ale priorității reflectă priorități superioare (valoarea minimă este 1).

Destination Type:

Definește destinația apelului care nu poate fi decât un nod de procesare. La un moment dat, un apel poate avea o singură destinație. Tipul de destinație poate fi ales din următoarele variante:

Random List: reprezintă o listă de nume de destinații din care în momentul solicitării se alege una în mod aleator. Toate destinațiile din cadrul listei au probabilități egale.

Random Neighbor: este o listă construită automat de COMNET III pentru nodul de origine și include toate nodurile disponibile dintr-un singur salt, în aceeași subrețea. Toate destinațiile au probabilități egale și sunt alese aleator în momentul solicitării.

Round Robin List: formează o secvență ordonată de destinații. La prima solicitare, va fi aleasă prima destinație din listă, apoi a doua, ș.a.m.d. După ce ultima destinație a fost aleasă, la următoarea solicitare se va reveni la prima destinație din listă. Ordinea destinațiilor în listă este aceea în care au fost adăugate și poate fi schimbată cu butonul Set Order.

Weighted List: este o listă de destinații din care sunt alese în funcție de probabilitățile introduse de utilizator și a căror sumă trebuie să fie 1.

Edit Destination List:

Acest buton permite selectarea unei destinații sau a unui grup de destinații pentru fiecare tip specificat mai sus, cu excepția Random Neighbor.

Triggered Scrs…:

Este folosită pentru modelarea schimbărilor semnificative ale stării sursei de trafic. Schimbările de stare modelate sunt: upon alarm clear (după oprirea alarmei), upon alarm first sounding (după prima declanșare a alarmei), upon link failure (după defectarea legăturii) și upon link recovery (după repararea legăturii). Odată ce o Sursă declanșată (triggered source) este activată, datorită schimbărilor de stare mai sus menționate, o sursă de trafic, oriunde în sistem poate fi declanșată.

5.2.2 Legătura punct-la-punct

Legăturile punct-la-punct conectează două noduri și sunt folosite pentru modelarea liniilor închiriate, liniilor seriale, circuitelor de trunchi și pentru generalizarea unei căi de date WAN (legături transatlantice sau legături satelit) stabilită între două puncte.

Pentru comunicații de date, legătura punct-la-punct este o cale bidirecțională, full duplex caracterizată prin bandă și număr de canale. Pentru voce sau trafic cu comutare de circuite, pot fi definite canale și/sau bandă separată. Numai legăturile punct-la-punct pot transporta trafic cu comutare de circuite. Așa cum am menționat nu se pot conecta decât două noduri printr-o legătură punct-la-punct. Un grup de calculatoare nu este acceptat.

Comutarea de circuite:

O legătură punct-la-punct poate avea definită atât o bandă pentru comutare de circuite cât și o bandă pentru comutare de pachete și sunt complet independente. Banda pentru comutare de circuite poate fi utilizată numai de traficul generat de sursele de apel.

În momentul generării unui apel cu comutare de circuite, este luată o decizie de rutare ce poate avea ca rezultat selectarea a zero, una sau mai multe rute pentru transportul apelului. Decizia de rutare este instantanee și verifică (printre altele ca limita de salturi, disponibilitate) dacă este suficientă bandă pentru a satisface cerințele apelului. Această bandă este apoi solicitată legăturii și menținută pe durata apelului, iar după ce acesta este încheiat, banda este cedată înapoi legăturii.

Un apel într-o legătură se poate încheia prematur din două motive.

Legătura (sau alt nod sau legătură din rută) se poate defecta ceea ce va însemna că apelul este deconectat, eliberând banda ocupată în toate nodurile și legăturile care alcătuiau calea de comunicație.

Dacă este activată opțiunea de pregolire (preemption), un apel cu prioritate superioară îl poate elibera pe cel în curs odată cu banda ocupată pe întreaga rută.

Parametrii legăturii punct-la-punct

Type:

Tipul legăturii. (Point-to-point, Aloha, CSMA/CA, CSMA/CD, DAMA, Dial-up, FDM/FDMA, FDDI, Link Group, Modem Pool, Priority FDDI, Polling, Satellite (STK), TDM/TDMA, Token Passing, Virtual Circuit și WAN.

Parameters:

Parametrii pentru tipul legăturii. Parametrii pot include numărul de circuite,

bandă/circuit, limita sesiunii, mărimea frame-ului, parametrii de reîncercare, etc.

Control Node:

Numele nodului de control al legăturii. Acest nod are un canal independent, fără concurență pentru a comunica cu celelalte noduri ale legăturii. Nodul de control este inactiv dacă nu este bifată opțiunea Control Channel în rubrica Physical din proprietățile legăturii.

Connections…

Butonul permite specificarea ordonarea nodurilor conectate la o anumită legătură. Această ordine determină de exemplu circulația jetonului într-un token ring. Pentru legături punct-la-punct cu rate diferite în fiecare direcție, ordinea determină, ordinea determină care dintre ele se aplică fiecărui nod.

More…

Acest buton activează fereastra de dialog pentru proprietățile specifice ale legăturii.

Propagation Delay (ms):

Timpul fizic de transmisie de-a lungul legăturii. În general acesta este semnificativ numai pentru legăturile prin satelit (270 – 300 ms) sau pentru legăturile la mare distanță prin cablu (1 – 150 km).

Error probability:

Când este folosită împreună cu frame error rate, este acea probabilitate ca un frame de mărime maximă să sosească eronat și să necesite retransmisie. Dacă se ia această decizie, linia va fi ocupată pentru retransmisia frame-ului.

Dacă este folosită cu bit error rate, probabilitatea eronării unui frame este probabilitatea ca cel puțin un bit mai mult decât numărul de biți corectabili să fie eronat în cadrul frame-ului.

Frame error rate:

Poate fi selectată eroarea de frame sau de bit.

Correctable Bits:

Numărul de biți corectabili într-un frame. Acest câmp este activ numai este selectată eroarea de bit în câmpul Type of error rate.

Time to failure:

Legăturile pot fi defectate la un moment determinat de o distribuție probabilistică.

Reroute time before fail (sec):

Un interval de timp în secunde care este folosit pentru rerutarea traficului înainte de defectare. Respectă de asemenea o distribuție probabilistică.

Time to repair:

Timpul necesar restabilirii legăturii de asemenea după o distribuție probabilistică.

Time of next state change:

Durata după care se schimba starea legăturii: dacă este funcțională va fi defectată și invers. Timpul este dat în termenii timpului de simulare.

Current state:

Menționează dacă legătura este defectă sau funcționează. Această valoare poate fi schimbată și în timpul simulării.

Triggered Scrs…:

Este folosită pentru modelarea schimbărilor semnificative ale stării sursei de trafic. Schimbările de stare modelate sunt: upon alarm clear (după oprirea alarmei), upon alarm first sounding (după prima declanșare a alarmei), upon link failure (după defectarea legăturii) și upon link recovery (după repararea legăturii). Odată ce o Sursă declanșată (triggered source) este activată, datorită schimbărilor de stare mai sus menționate, o sursă de trafic, oriunde în sistem poate fi declanșată.

Number of circuits:

Numărul de circuite identice disponibile pentru transportul traficului cu comutare de pachete.

Bandwidth/Circuit (kbps):

Rata de transmisie în fiecare direcție a fiecărui circuit în kbps.

Propagation (ms):

Timpul de propagare al unui semnal de-a lungul liniei. Acesta este în general nesemnificativ pentru legăturile radio terestre. Pentru legături cu sateliți geostaționari întârzierea de propagare este de ordinul 270 – 300 ms. Această întârziere nu afectează statisticile privitoare la utilizarea legăturilor.

Frame error probability:

Este acea probabilitate ca un frame de mărime maximă să sosească eronat și să necesite retransmisie. Dacă se ia această decizie, linia va fi ocupată pentru retransmisia frame-ului.

Acest parametru intenționează să modeleze linii cu erori mai puțin frecvente unde retransmisia poate impune încărcare crescută sau o creștere a întârzierii frame-ului prin legătură.

Automatically Retransmit Frame Errors:

Corectarea erorilor de frame poate fi opțional ignorată la nivelul legătură de date. Dacă are loc eronarea unui frame, pachetul transportat de frame este tratat ca blocat, producând fie retransmisia acestuia de către protocol, fie anularea lui și eșuarea reconstruirii mesajului la destinație.

Number of circuits:

Numărul de circuite identice de trunchi, disponibile pentru transportul traficului cu comutare de circuite.

Bandwidth/Circuit (kbps):

Lărgimea de bandă a unui circuit. Capacitatea totală de transport a traficului cu comutare de circuite este produsul dintre numărul de circuite și banda circuitului. Un trunchi poate fi descris deci, fie ca un circuit de 1920 Kb/s sau 30 de circuite de 64Kb/s. Când un apel este rutat printr-o legătură, apelul solicită o anumită bandă. În cazul în care capacitatea liberă a legăturii este mai mare decât solicitarea apelului, acesta poate fi transportat, capacitatea liberă fiind redusă cu banda necesară apelului, pe durata acestuia.

Spare Call Channel Usage:

Această opțiune permite asocierea apelurilor la canale în funcție de cerințele de bandă ale acestora și de ce tipuri de apel ocupă deja canalele. În mod obișnuit, un apel va ocupa un întreg canal al unui circuit comutat, deoarece fiecare apel va necesita aceeași bandă cu a canalului. Dacă se solicită mai multă bandă, atunci sunt combinate mai multe canale pentru transportul apelului. Noile tehnologii pot comprima apelul (vocea) astfel că acesta nu ocupă un întreg canal și se numește subcanal (subchannel) sau, așa cum se întâmplă cu apelul video care necesită o bandă continuă, poate ocupa mai mult decât un canal dar nu neapărat un număr întreg de canale și este numit supercanal (superchannel).

Bandwidth Reserved For 1-Hop Calls:

Este ceva obișnuit pentru traficul cu rutare directă într-o rețea de servicii vocale să aibă rezervată bandă într-un trunchi. Poate fi specificată mărimea acesteia pentru apelurile între două noduri alăturate (one-hop calls) care pot fi generate la oricare dintre cele două noduri. Această bandă rezervată nu este niciodată disponibilă apelurilor cu rute alternative.

Packets and calls share the same channel:

Dacă este bifată, această opțiune permite utilizarea aceluiași canal atât de apeluri cât și de pachete.

Call overhead (kbps):

Acest parametru permite modelarea cazurilor în care fiecare apel necesită o bandă suplimentară pe legătura fizică pentru apelul în desfășurare pe un canal.

Transmit on a partial call circuit:

Oferă posibilitatea ca pachetele să folosească un canal de apeluri care este parțial ocupat de un apel. Unele sisteme necesită rezervarea întregului canal chiar dacă este numai parțial ocupat de un apel.

Transmit on a partial packet circuit:

Această opțiune permite folosirea de către pachete a unui canal de pachete, chiar dacă acesta este parțial ocupat de un apel. Dacă există mai multe canale de pachete disponibile, sunt folosite mai întâi cele libere iar cel parțial ocupat este lăsat ca ultimă resursă, dar numai dacă este activă opțiunea.

Transmiterea unui pachet pe un canal parțial ocupat de un apel necesită un algoritm pentru întârzierea pe care o suferă pachetul de-a lungul legăturii. Sunt disponibili doi algoritmi: Cycle Time (ms) și Model cycles.

Cycle Time (ms):

Acest algoritm calculează un timp de transmisie pentru pachet, bazat pe banda disponibilă la începutul transmisiei acestuia. Acest algoritm simulează eficient dar poate introduce erori dacă pachetul profită de banda eliberată (sau este penalizat dacă se mai ocupă din bandă) de apeluri pe timpul transmisiei pachetului.

Model cycles:

Acest algoritm secționează transmisia pachetului în "cicluri" și calculează numărul de biți transmiși prin canal pe durata unui ciclu. Astfel, dacă sunt inițiate sau terminate apeluri, numărul de biți ai unui pachet ce sunt transmiși pe durata unui ciclu, se poate schimba. Acest algoritm modelează banda disponibilă ce variază pe timpul transmisiei pachetului și folosește timpul de ciclu specificat în câmpul Cycle Time (ms). O valoare potrivită pentru multe tipuri de legături este 0.125 ms, reprezentând perioada de eșantionare a semnalului vocal. Lista de opțiuni a rubricii Model Cycle permite selecția algoritmului ce va fi folosit. Opțiunea Scale entire frame once selectează primul algoritm iar opțiunea Always selectează a doua variantă. Există o a treia alternativă Call utilization > 0.0, care folosește primul algoritm dacă utilizarea apelurilor este 0 și al doilea algoritm dacă este pozitivă. Această variantă crește eficiența simulării presupunând că pachetele se transmit atât de rapid când au la dispoziție întreaga bandă încât nu mai este nevoie de modelarea ciclurilor.

5.2.3. Nodul de procesare

Nodul de procesare "generic" poate reprezenta sisteme terminale, comutatoare de pachete și componente generale de rețea. Nodul de procesare poate genera toate tipurile de trafic, poate ruta atât pachete cât și circuite și de asemenea poate executa aplicații.

Pentru traficul cu comutare de circuite, apelurile pot fi asociate canalelor în funcție de banda necesară și de ce tipuri de apeluri ocupă deja canalele. În mod tipic, un apel va ocupa un întreg canal al unui circuit comutat, având aceeași bandă. Dacă însă este solicitată o lățime de bandă mai mare, sunt combinate mai multe canale pentru susținerea apelului. Tehnologiile mai noi, apelurile (vocale) pot fi comprimate astfel încât să nu ocupe un întreg canal, iar apelurile video pot necesita o bandă continuă de mai mult de un canal, dar nu neapărat un număr întreg de canale. Aceste cazuri au mai fost menționate și sunt cunoscute drept subcanal și supercanal. Setările pentru ele se fac în meniul Calls din proprietățile nodului de procesare. Capacitatea totală de apeluri este definită în termeni de număr de circuite (canale) și o bandă egală pentru fiecare dintre ele. Flexibilitatea constă în modul de folosire al acestora. Un canal fără trafic poate accepta orice tip de apel, dar odată ocupat, poate restricționa apelurile suplimentare ce îi pot fi asociate. Apelurile pot fi de trei tipuri: full-channel, sub-channel și superchannel. Când un apel ocupă un canal liber, acesta este restricționat de acest prim apel.

Aplicațiile sunt folosite pentru a reprezenta un program sau o subrutină ce rulează pe dispozitivul modelat. O aplicație specifică cere nodului să execute o secvență definită de utilizator de comenzi de citire, scriere, proces, transport, setare sau răspuns.

Nodul de procesare este reprezentat în model ca fiind compus din:

Un buffer de intrare pentru fiecare legătură ce transmite pachete prin nod.

Un procesor pentru a executa comenzi și a procesa pachete.

Un buffer de ieșire pentru fiecare legătură prin care poate ruta pachete.

O capacitate locală de stocare pe disc, pentru modelarea comenzilor de citire/scriere.

O listă de comenzi care detaliază felul în care sunt executate anumite comenzi.

O listă de așteptare cu aplicațiile programate curent.

O listă de aplicații prototip cu aplicațiile disponibile în nod.

O listă de mesaje recepționate pentru memorarea acestora până la folosire.

O listă de fișiere ce pot rezida în capacitatea de memorare locală.

La nodul de procesare pot fi conectate toate tipurile de legături și în orice număr. Pentru fiecare legătură conectată la nod există un buffer al portului de intrare și un buffer al celui de ieșire. Detaliile acestor buffere pot fi accesat prin dublu-clic pe arcele ce conectează nodul cu legătura.

Traficul cu comutare de circuite poate fi rutat prin noduri dar numai folosind legături punct-la-punct, DAMA sau STK.

Un nod de procesare poate genera, comuta și recepționa apeluri cu comutare de circuite. Dacă nodul generează un apel, destinația poate fi chiar și același nod. Această posibilitate poate fi folosită pentru modelarea unui switch local. Traficul cu comutare de circuite este independent de cel cu comutare de pachete. Generarea, rutarea sau recepționarea traficului cu comutare de circuite nu are nici un efect asupra buffer-elor porturilor de intrare și ieșire. Resursele nodului sunt specificate separat pentru pachete și circuite.

Când este generat un apel, în mod obișnuit este necesară o secvență de decizii de rutare, în funcție de numărul de rute ce compun calea și de numărul de salturi pe fiecare rută. Nodurile și legăturile de-a lungul unei anumite rute sunt inspectate pentru a determina dacă ruta completă are capacitatea de a transporta apelul. Din punctul de vedere al nodului, acesta dispune de maximul de bandă posibilă pentru a comuta simultan toate apelurile direcționate prin el. Pe măsură ce un apel este rutat prin nod, banda disponibilă care rămâne este redusă. Când apelul este terminat, banda este restituită. În consecință, un nod de procesare este disponibil pentru transportul unui anume apel dacă în momentul luării deciziei de rutare, banda liberă din nod este egală sau mai mare decât banda necesară apelului (definită în Routing Class).

Banda este rezervată numai când s-a constatat că există bandă liberă pe întreaga rută. Trebuie menționat că aceasta este o decizie instantanee. Dacă nodul de procesare este un punct de congestie pentru traficul cu comutare de circuite (adică este un punct unde nu există suficientă bandă disponibilă), protocolul de rutare va verifica întâi toate celelalte rute pentru a constata dacă este vreuna disponibilă. Dacă nu este găsită nici una, protocolul poate re-inspecta nodul congestionat pentru a testa dacă poate fi eliberat vreunul din apelurile în desfășurare pentru a elibera suficientă bandă pentru rutarea apelului solicitant. Mecanismul de pregolire (preemption) este controlat de prioritatea apelului, setată în fereastra de dialog a sursei de apel. Această opțiune trebuie de asemenea activată fereastra de dialog a protocolului de rutare a apelurilor.

Un nod poate fi origine și destinație de trafic. Se poate comporta de asemenea ca un punct de comutare.

Proprietățile nodului de procesare:

Fereastra inițială de dialog conține meniuri asemănătoare cu cele descrise la legătura punct-la-punct (v. Fig. 5.3, 5.6., 5.7.)

Type:

Tipul nodului: Processing Node, Computer Group, Network Device, Head Of Line Blocking sau altul definit de utilizator.

Parameters:

Parametrii pentru tipul respectiv de nod. Parametrii pot include specificații pentru procesare de aplicații, de pachete, procesare de port, comutare de circuite și stocare pe disc, specificații dependente de tipul de nod.

Meniul State este identic cu cel al legăturii punct-la-punct (v. Fig. 5.6).

Meniul Advanced este identic cu cel al legăturii punct-la-punct (v. Fig. 5.7).

Commands…

Deschide fereastra de dialog Command Repertoire Aici pot fi adăugate sau șterse din repertoriul nodului.

Variables…

Deschide fereastra de dialog. Aici pot fi definite variabile pentru a fi folosite în comenzi de tip Assign sau în alte expresii.

Protocol Dependent Processing Times…

După ce un pachet este creat sau părăsește bufferul de intrare, procesorul nodului este ocupat în intervalul Processing Time/Packet a cărui durată depinde de protocolul de rutare al nivelului transport, care a creat pachetul. De exemplu, dacă un nod modelează un switch cu viteza de comutare de 100 pachete/sec, această performanță poate fi ilustrată prin introducerea unui timp de procesare/pachet de 10 ms ca valoare implicită pentru acest protocol particular. Processing Time/Packet este o întârziere aplicată fiecărui pachet la rutarea prin nod, în plus față de întârzierea de așteptare sau de procesare din buffer. După ce suferă o întârziere de împachetare, apoi una de procesare, pachetul creat în nod va fi inserat într-un buffer al portului de ieșire. Pachetele destinate nodului vor suferi mai întâi niște întârzieri de comutare și așteptare în buffer-ul de intrare urmate de întârzieri de procesare datorate protocolului de rutare, abia apoi fiind numărat ca sosit. Timpul de procesare al pachetului într-un nod poate varia în funcție de protocolul de rutare, determinat la rândul lui de protocolul de transport folosit de pachet. Protocolul de transport are un câmp nou ce definește protocolul său de rutare, al cărui nume poate fi ales dintr-o listă predefintă sau poate fi introdus de utilizator. Când un pachet este gata pentru a fi procesat într-un nod, timpul său de prelucrare este determinat din lista timpilor de procesare a pachetelor, căutând un protocol de rutare care să se potrivească cu cel al pachetului. Dacă nu este găsită nici o potrivire, este folosit timpul de procesare denumit Default. Timpul total de procesare pentru un pachet este dat de timpul de procesare dependent de protocol, descris mai devreme. Plus un factor separat care variază liniar în funcție de mărimea pachetului. Acest factor este dat de valoarea introdusă în câmpul Processing time per kilobyte. Pachetele surselor de tip Sesiune sunt tratate separat și au un timp de procesare al pachetului dat de câmpul Processing time per setup packet.

Additional Processing / kbyte (ms):

Unele dispozitive necesită un timp mai mare pentru comutarea pachetelor mai mari față de cele mai mici. Nodul de procesare permite această situație prin câmpul Processing Time / kbyte.

Timpul de comutare pentru un pachet este atunci calculat folosind formula:

Timpul de comutare = Ax + B

Unde

A = Processing Time/kbyte

x = Mărimea pachetului în KB

B = Processing Time/Packet (detaliat anterior)

Packet processing uses procesor:

Parametrii de procesare ai pachetului (pentru modelarea în nod a procesărilor la nivelul Rețea) pot utiliza opțional procesorul. Această opțiune există de asemenea în parametrii procesorului, ce fac parte din parametrii nodului. Este folositoare pentru modelarea matricilor complexe multiprocesor sau de comutare care permit majorității întârzierilor să aibă loc simultan.

Processing For Session Setup (ms):

La stabilirea unei sesiuni în rețea, pachetul de stabilire a sesiunii trebuie rutat la fiecare nod. Presupunând rutare orientată pe conexiune, pachetele de date ce urmează pachetului explorator (de stabilire a sesiunii) nu au același overhead de rutare la nod, deoarece ruta a fost deja stabilită. Astfel, procesarea pentru pachetul explorator poate fi substanțial mai lungă decât a pachetelor ce urmează în desfășurarea sesiunii.

În consecință, COMNET III furnizează introducerea valorii Processing Time/Setup Packet pentru întârzierea în nod a pachetului de stabilire a sesiunii. Întârzierea Packet Processing Time/Packet delay va fi folosită pentru pachetele de date următoare.

Notă: Processing for Session Setup este timpul de procesare necesar pentru determinarea rutei de urmat de către toate pachetele ulterioare ale unei conexiuni sau sesiuni. Se aplică numai rutării orientate pe conexiune și este important numai acolo unde timpul necesar stabilirii sesiunii sau conexiunii este mult mai mare decât timpul necesar pachetelor de date asociate.

Session Limit:

Numărul maxim de sesiuni ce poate fi rutat la un moment dat prin nodul de procesare. Se aplică numai rutării orientate pe conexiune și este important numai dacă blocarea conexiunii este importantă. Nu reprezintă o problemă de exemplu pentru rețele ce operează pe baza IP.

La luarea unei decizii de rutare a sesiunii de către pachetul explorator, nodurile de procesare care au deja în desfășurare un număr de sesiuni egal cu Session Limit nu sunt disponibile pentru rutarea acestui pachet.

Source Or Sink Only:

Acest fanion indică dacă nodul este disponibil pentru rutarea traficului. Dacă această căsuță este bifată, nodul nu poate fi decât origine sau destinație pentru trafic.

Virtual cut-trough:

Operația Virtual cut-through permite la sosirea unui pachet ca acesta să înceapă transmisia pe o legătură de ieșire chiar dacă biții continuă să sosească pe o legătură de intrare.

Când această opțiune este activată, nodul trebuie să fie conectat la cel puțin două legături și toate legăturile trebuie să fie punct-la-punct, să aibă aceeași rată și să fie configurate pentru aceeași dimensiune a pachetului și frame-ului. Când un pachet începe transmisia printr-un nod "cut-through" , este recepționat header-ul pentru a stabili legătura pe care vor pleca datele, iar dacă aceasta este disponibilă, pachetul începe imediat transmisia, înainte de sosirea restului pachetului. Astfel, pentru un pachet ce pleacă din A în C și trece printr-un nod cut-through B, întârzierile așteptate între A și B și Între B și C se vor suprapune în timp, reducând astfel întârzierea totală. Nu există nici un control al fluxului la nivel legătură sau verificarea erorilor pe legăturile conectate prin astfel de noduri. Virtual cut-through" nu afectează utilizarea, dar poate reduce semnificativ întârzierile cap-la-cap deoarece nu trebuie recepționat un întreg pachet înainte de a începe transmiterea lui mai departe.

Special Case Port Processing Times…:

Timpii de procesare la port pot varia în funcție de protocolul de rutare al pachetului și de tipul de legătură conectată la port. Pentru a determina timpul de procesare la port pentru un pachet ce tocmai a sosit la un buffer de intrare sau ieșire, modelul verifică mai întâi Special Case Port Processing Times. Caută în lista cu cazuri speciale pentru găsi unul cu același protocol de rutare și tip de legătură, iar în cazul unui rezultat pozitiv folosește timpul de procesare la port dat pentru acest caz special. În cazul în care căutarea nu are nici un rezultat, folosește timpul de procesare stabilit pentru port, care este setat la arcul ce conectează nodul de legătură. Când nodul este conectat inițial la legătură, timpul de procesare setat pentru port are valoarea implicită luată din parametri nodului. Această valoare poate fi schimbată ulterior, modificând parametrii arcului dintre nod și legătură.

Notă: Timpul de procesare la port este important numai dacă este un factor limitator în dispozitivul de rețea. În general, într-o arhitectură distribuită, factorii limitatori sunt mai degrabă resursele folosite în comun (de ex. magistrale), decât porturile.

Input Port Delay (ms):

Este o întârziere în ms care poate fi aplicată la fiecare port de intrare al HOL Blocking Switch.

Output Port Delay (ms):

Este o întârziere în ms care poate fi aplicată la fiecare port de ieșire al HOL Blocking Switch.

Input Port Number of Processors:

Numărul de procesoare disponibile la fiecare port ieșire, pentru procesarea datelor.

Notă: Acest parametru este important numai procesarea la port este un factor limitator în dispozitivul de rețea. În general, într-o arhitectură distribuită, factorii limitatori sunt mai degrabă resursele folosite în comun (de ex. magistrale), decât porturile.

Input Pooled Buffer Space Maximum:

Reprezintă utilizarea maximă permisă a buffer-elor la toate porturile de intrare conectate la nod. Când sosește un pachet, este efectuat mai întâi un test pentru a verifica dacă este spațiu în buffer-ul portului și apoi un test pentru a verifica dacă acceptarea pachetului ar produce depășirea limitei de utilizare menționate de acest parametru.

Mărimea buffer-ului de intrare este definită la arcul care conectează o anume legătură de nodul în cauză.

Dacă spațiul este insuficient pentru acceptarea pachetului, atunci acesta este blocat și opțional, în funcție de setările protocolului de transport, retransmis ulterior.

Output Pooled Buffer Space Maximum:

Reprezintă utilizarea maximă permisă a buffer-elor la toate porturile de ieșire conectate la nod. Când un pachet este comutat către un port de ieșire, este efectuat mai întâi un test pentru a se verifica dacă este spațiu în buffer și apoi încă un test pentru a se verifica dacă acceptarea pachetului ar produce depășirea limitei de utilizare menționate de acest parametru.

Mărimea buffer-ului de intrare este definită la arcul care conectează o anume legătură de nodul în cauză.

Dacă spațiul este insuficient pentru acceptarea pachetului, atunci acesta este blocat și opțional, în funcție de setările protocolului de transport, retransmis ulterior din origine.

Pooled Buffer Space Units:

Unitatea de măsură a buffer-ului (octeți sau pachete).

Number of circuits

Bandwidth/Circuit (kbps)

Spare channel usage:

Subchannel

Superchannel

Utilizarea procesorului:

COMNET III face din utilizarea procesorului o opțiune pentru multe din întârzierile disponibile. Dacă întârzierea este modelată cu utilizarea procesorului, atunci pachetele vor trebui să aștepte un procesor liber și să fie procesate secvențial. Evitarea folosirii procesorului permite simultaneitatea mai multor întârzieri și un lucru la fel de important, fără să afecteze utilizarea nodului. O întârziere fără utilizarea procesorului este folositoare în modelarea în resurse a întârzierilor care nu fac parte din model (precum cele datorate factorului uman sau procesoarelor care nu fac parte din sistem), sau pot fi folosite pentru întârzieri de așteptare care nu au legătură cu nici un procesor secvențial.

Number of processors:

Toate tipurile de noduri, au ca parte a setului de parametri, un număr de procesoare a cărui valoare implicită este 1. Acest câmp specifică numărul de procesoare disponibile pentru realizarea de sarcini ce necesită rezervarea de timp la procesor, precum întârzierea de împachetare sau secvența de comenzi a unei surse de aplicații. Comportamentul nodurilor cu mai mult de un procesor va depinde de setările opțiunii Time Slice.

Arhitectura unității de procesare include procesorul propriu zis și două șiruri de așteptare de lucru. Unul menține sarcini ce pot fi executate imediat ce procesorul este disponibil, iar celălalt menține sarcini suspendate până la îndeplinirea unei anumite condiții, precum sosirea unui mesaj ce satisface comanda Wait For. În plus, setul de unități de procesare împarte aceeași pereche de șiruri de așteptare asemănătoare ca scop cu cele asociate fiecărei unități în parte, cu deosebirea că aceste cozi mențin sarcini care nu au fost încă asociate unei unități de procesare.

Un aspect cheie al modelului cu multiprocesor este acela că odată ce o sarcină a fost asociată unei unități de procesare (fie procesorului însuși sau uneia din cozile de așteptare) rămâne acolo până este dusă la îndeplinire.

Când este activă opțiunea Time Slicing (secționare în timp), la începutul fiecărei Time Slice (secțiuni, intervale de timp), sarcinile care nu au fost asociate încă unei unități de procesare, sunt selectate și le sunt repartizate o unitate de procesare și un timp la procesor. Când nu există nici o sarcină neasociată, timpul procesorului este împărțit între sarcinile existente în aceeași ordine circulară.

Când opțiunea Time Slicing nu este activată, sarcinile sunt distribuite procesoarelor disponibile până când fiecare are o sarcină activă, punct în care procesoarele continuă să proceseze sarcinile până le duc la bun sfârșit. Când un procesor devine disponibil pentru că sarcina sa este fie executată, fie suspendată își selectează alta din șirurile de așteptare comune folosind același algoritm ca pentru șirurile locale.

Processing/Cycle (mic):

Timpii de execuție a unei comenzi de proces sunt dimensionați în cicluri de microsecunde. Durata propriu-zisă a unei comenzi de proces este numărul de cicluri înmulțit cu timpul de procesare pe ciclu al nodului.

Time Slice (mic):

Dacă nu este introdusă nici o valoare, programul nu consideră acest tip de operație pentru nod. Dacă este introdusă o valoare în microsecunde, atunci, o singură comandă poate utiliza procesorul pe această durată, apoi trebuind să cedeze procesorul altei comenzi.

Selection Rules:

Procesorul nodului are opțiuni referitoare la modul de alegere a următoarei aplicații sau pachet după terminarea procesării pachetului sau aplicației curente. Aceste opțiuni sunt importante în modelarea procesoarelor puternic congestionate care au frecvent multe variante în alegerea următoarei aplicații. Regulile pentru alegerea următoarei sarcini are un efect semnificativ asupra întârzierilor aplicațiilor sau mesajelor.

Between aplications:

Există următoarele opțiuni de selecție atunci când procesorul selectează o aplicație dintre multe altele, aflate în șirul de așteptare:

First App Available:

Această opțiune selectează prima aplicație gata de procesare pe care o extrage din șirul de așteptare. După ce procesarea acesteia s-a încheiat, aplicația este pusă înapoi la coada șirului pentru a construi o ordine circulară a aplicațiilor pregătite pentru procesare.

App Ready The Longest:

Opțiunea caută întreaga coadă de așteptare și selectează aplicația pregătită pentru procesare care a așteptat cel mai mult.

Between Apps and Packets:

Procesorul are diferite criterii de a alege între pachetele ce așteaptă în buffer-ul de intrare și aplicațiile din coada de așteptare. Opțiunile sunt următoarele:

Pkts Have Priority:

Pentru această opțiune, procesorul va prelucra orice pachet din buffer, înaintea oricărei aplicații din coadă. Acest tip de selecție pune mai mult accent pe rutare decât pe procesare și poate fi folosită pentru modelarea dispozitivelor de rețea. Poate fi de asemenea utilă pentru modelarea cazurilor în care sosirea unui pachet declanșează o întrerupere care forțează procesorul să prelucreze pachetul sosit imediat după terminarea sarcinii curente.

Apps Have Priority:

Procesorul va prelucra orice aplicație în așteptare înaintea oricărui pachet din buffer. Această opțiune poate fi folositoare pentru modelarea dispozitivelor mai simple care nu verifică frecvent sosirea unor noi pachete și nici nu folosesc întreruperi pentru pachete. Pot fi de asemenea modelate scenarii complexe în care noile pachete vor da noi sarcini procesorului și este de dorit ca acesta să o termine pe cea curentă înainte să accepte una nouă.

Earliest Arrival:

Această opțiune aplică regula primului venit. Pachetele sosesc la nod când intră în buffer-ul de intrare. Aplicațiile sosesc atunci când sunt generate sau declanșate.

Notă: O aplicație sau un pachet nu sunt neapărat gata de a fi prelucrate imediat cum ajung la nod: aplicația poate aștepta îndeplinirea unui număr de condiții iar pachetul poate necesita prelucrare la port înaintea prelucrării de către nod. În fiecare din cazuri, aplicația sau pachetul nu vor fi prelucrate până nu sunt pregătite, însă după aceea vor fi selectate după regula primului venit.

Ready The Longest:

Această opțiune este asemănătoare cu cea anterioară, cu excepția faptului că timpul de când aplicația este pregătită este comparat cu timpul de când pachetul a intrat în buffer pentru că timpul de când aplicația este gata de procesare ar putea fi mult mai mic decât perioada de când a sosit în coada de așteptare.

Between pkt buffers:

Există următoarele opțiuni de selecție când procesorul trebuie să aleagă între pachetele aflate în mai multe buffere de intrare.

Earliest Arrival:

Aplică regula primului venit.

Packet Priority:

Această opțiune ia în considerare numai primele pachete din buffere, conservând astfel ordinea de sortare a acestora. Dacă mai multe buffere au pachete în așteptare, va fi selectat pachetul cu prioritatea cea mai mare, iar dacă sunt mai multe cu aceeași prioritate, va fi selectat primul sosit.

Disk Size:

Dacă sunt necesare la nod comenzi de citire și scriere, trebuie specificată capacitatea discului conectat la nod. Valoarea este introdusă în MB.

Disk Sector Size:

Capacitatea unui sector al discului, dată în KB.

Xfer (ms):

Timpul de citire a unui sector.

Seek (mic):

Timpul suplimentar de căutare a unui anumit sector de pe disc.

Durata unui transfer este calculată astfel:

Timpul de transfer = Numărul de sectoare * (Timpul de transfer+ Timpul de căutare)

Read/write commands use central processor:

Întârzierea de stocare poate utiliza opțional procesorul central. Intenția este de a modela separat controlerul discului pentru a efectua principalele operații legate de stocarea datelor fără a utiliza procesorul permițându-i acestuia să efectueze alte sarcini.

5.2.4. Dispozitivul de rețea

Face parte din categoria nodurilor și folosește pentru modelarea dispozitivelor de rețea de tip router, switch, etc. Premiza de la care se pleacă este aceea că proprietățile acestor dispozitive pot fi conturate de caracteristicile buffer-elor de intrare și de ieșire precum și de rata internă de comutare. Caracteristicile de performanță provenind din proiectarea arhitecturii interne, variante software îmbunătățite, ș.a, pot fi înglobate în parametrii vitezei de comutare.

În consecință, în COMNET III, dispozitivul de rețea are porturi de intrare și ieșire ce au asociate buffere și timpuri de procesare și magistrale interne ce transportă pachete de la un port la altul. Poate fi definită interfața de linie (Line card) care va detemina dacă este necesară sau nu o întârziere pe magistrală. În plus, dispozitivul de rețea are aceleași posibilități de modelare a procesării ca și nodul de procesare. Prelucrarea de către procesorul central este modelată după ce pachetul părăsește bufferul, înainte să traverseze magistrala (dacă se cere).

Structura dispozitivului de rețea este ilustrată în Fig. 5.19.

Dispozitivul de rețea poate genera orice tip de trafic, poate ruta atât trafic de pachete cât și de circuite și poate executa aplicații.

Pentru traficul cu comutare de circuite, apelurile pot fi asociate canalelor, în funcție de banda ocupată, după aceeași politică descrisă la nodul de procesare (v. 5.2.3.).

Pentru comutarea de circuite, comportarea este aceeași cu a nodului de procesare (v. 5.2.3.).

În cazul comutării de pachete, se consideră sosit la nod, un pachet pentru care au fost livrate de către protocolul de transport, toate frame-urile componente. Pachetul este reasamblat din acestea și se încearcă inserarea sa în buffer-ul de intrare care deservește legătura. Este efectuat un test pentru a se constata dacă există suficient spațiu în buffer pentru a primi pachetul. Dacă rezultatul este pozitiv, se mai efectuează un test pentru a verifica de această dată dacă nu este depășită capacitatea totală a buffer-elor de intrare. Dacă sunt trecute ambele teste, pachetul este introdus în buffer-ul de intrare aferent legăturii. Dacă oricare din teste este picat, pachetul este considerat blocat și se poate încerca retransmiterea lui din origine, în funcție de setările protocolului de transport.

Pachetul ocupă spațiu în buffer așteptându-și rândul pentru procesare la port. După încheierea acestei procesări, ocupă în continuare spațiu în buffer-ul de intrare, așteptându-și rândul la procesor. După ce s-a încheiat prelucrarea la nod, este luată o decizie de rutare pentru a stabili ce port de ieșire ar trebui folosit (presupunând că pachetul nu a ajuns la destinație).

Pachetele din buffer sunt ordonate în ordinea descrescătoare a priorităților corelată cu ordinea FIFO. Odată în buffer-ul de intrare, pachetul poate suporta o întârziere de procesare în buffer, care este modelat ca deținând o singură resursă de întârziere folosită pentru pachete, câte unul pe rând. Pachetele cărora li s-a aplicat întârzierea sunt încă în buffer-ul de intrare, dar sunt gata pentru comutare. Dacă parametrul Line Card ID al portului de ieșire este diferit de cel al portului de intrare, sau nu este specificat acest parametru, se presupune necesară transmiterea prin intermediul magistralei, fapt ce va presupune o întârziere dată de mărimea pachetului și viteza magistralei. Dacă nu este necesară folosirea magistralei, pachetul este trecut din buffer-ul de intrare direct în cel de ieșire.

În ambele cazuri, încercarea de a insera pachetul în buffer-ul de ieșire poate eșua, din cauza lipsei de spațiu. Întârzierile la portul de ieșire sunt similare celor de la intrare.

Singurii parametri suplimentari față de nodul de procesare, sunt cei referitori la magistrală.

Bus Rate:

Viteza datelor pe magistrala internă. Pachetele care sunt transmise între porturi cu identificatori (Line Card ID) diferiți și trebuie să traverseze magistrala suferă o întârziere dată de viteza acesteia și de mărimea pachetelor. O magistrală nu poate transmite decât un singur pachet la un moment dat.

Bus Count:

Dispozitivele de rețea capabile să comute un anumit număr de pachete simultan, au specificat acest număr în acest câmp.

Notă: Comutatoarele fără blocare (vezi cazul STAR), trebuie modelate ca având numărul de magistrale cel puțin egal cu numărul de legături conectate.

5.3. Clase de rutare (Apeluri)

Clasa de rutare este o etichetă aplicată sursei de apel. Poate fi privită ca o descriere a tipului apelului care îi atribuie acestuia diverse caracteristici și valori de parametri.

Pot fi definite oricâte clase de rutare în cadrul modelului și aplicate oricâtor surse de apel.

Clasele de rutare sunt folositoare atât pentru definirea unor parametri (cerințe de bandă) simultan pentru toate sursele care se încadrează într-o anumită clasă, dar mai ales pentru definirea protocoalelor de rutare. Pot fi definite rute separate pentru diferite tipuri de trafic în cazul folosirii rutării statice pe bază de tabele sau penalizări diferențiate pe tipuri de trafic (clase de rutare) în cazul rutării dinamice de tip "Penalizare minimă". De exemplu pot fi definite clase de rutare de tipul "Voce" sau "Fax".

Fiecare clasă de rutare are asociată un tabel complet de rutare.

Hop Limit:

Când un apel este creat, se încearcă rutarea lui, folosind protocolul de rutare aferent. Acest parametru stabilește o limită superioară a numărului de salturi ce pot fi folosite pe o rută selectată, înainte ca apelul să fie blocat. Valoarea se aplică tuturor protocoalelor de rutare. Clase de rutare diferite pot avea Hop Limit diferit.

Bandwidth Required:

Când un apel este creat și rutat prin rețea, acesta necesită ocuparea și menținerea unei anumite lățimi de bandă, între sursă și destinație, pentru o anumită perioadă de timp.

Call Retry Interval:

Dacă un apel este blocat, valoarea acestui parametru determină dacă apelul va fi reluat ulterior. Dacă valoarea este None, nu se va mai face nici o încercare.

Reroute Connections:

Apelurile se desfășoară între sursă și destinație, prin nodurile și legăturile intermediare. Dacă un nod sau o legătură se defectează, atunci trebuie luată o decizie dacă să se restabilească sau nu legătura. Dacă această opțiune este activă, în cazul unei defectări, tabelele de rutare sunt recalculate se va efectua o nouă încercare de a ruta apelul, alegându-se în mod evident un alt traseu pentru acesta. Dacă opțiunea este inactivă, tabelele de rutare sunt oricum recalculate pentru apelurile ulterioare, însă nu se mai încearcă restabilirea legăturii pentru apelurile curente.

5.4. Algoritmi de rutare a apelurilor

Pe măsură ce traficul de apeluri este generat în COMNET III, trebuie aleasă o rută alcătuită dintr-o succesiune de noduri și legături astfel încât apelul să-și atingă destinația.

Într-o rețea reală, această funcție poate fi realizată în mai multe feluri. De exemplu, printr-un controler centralizat, prin tabele distribuite menținute în fiecare switch sau prin tranzacții separate de rutare a pachetelor. COMNET III nu imită exact logica și etapele acestor decizii. Scopul este mai degrabă modelarea efectului mecanismului real de rutare și asigurarea în simulare a unui protocol de rutare care ajunge la aceleași rezultate.

De exemplu, rezultatul final al multor decizii de rutare în multe rețele este de a stabili drumul minim (cu cele mai puține salturi) prin rețea, între două puncte. Pentru aceasta, în COMNET III există un algoritm al saltului minim: Minimum Hop, care are aceeași finalitate.

Când se defectează un nod sau o legătură, tabelele de rutare cu drumurile minime sunt recalculate instantaneu (relativ la timpul simulării), fiind disponibile în același moment pentru toate apelurile ce solicită o decizie de rutare. Nu este la fel ca în rețelele reale dar abordarea COMNET III este validă în planificarea capacității globale a rețelelor. Dacă scopul utilizatorului este acela de a stabili pașii detaliați ai recalculării tabelelor de rutare în cazul unei defectări, mediul standard de simulare COMNET III, nu furnizează suficiente detalii.

Protocoalele de rutare sunt incluse în COMNET III (v. 4.4.). Pentru traficul de apeluri, sunt disponibile următoarele trei variante :

Minimum Hop (saltul minim)

Mininum Penalty (penalizare minimă)

User Defined Routing Tables (tabele definite de utilizator)

Dacă este folosită rutarea cu penalizare minimă, trebuie definite tabele de penalizare și aplicate arcelor ce conectează nodurile și legăturile. La fel și în cazul tabelelor definite de utilizator.

Câte un protocol de rutare este aplicat rețelei de bază (backbone network) și fiecărei subrețele. Dacă un apel este generat într-o subrețea și are ca destinație altă subrețea, sunt necesare trei protocoale de rutare: unul pentru fiecare subrețea și unul pentru rețeaua de bază.

O rută trece limita între subrețea și rețeaua de bază numai printr-un punct de acces. Până la acesta acționează protocoalele de rutare, atât cel din rețeaua de bază către subrețea cât și invers.

5.4.1. Drumul minim (Minimum Hop)

Când este pornită simularea, fiecare nod calculează toate rutele posibile către celelalte noduri din model. În fiecare nod este memorat un tabel care conține perechea "legătura următoare/nodul următor" pentru fiecare rută către o anumită destinație. Aceste perechi sunt ordonate crescător după numărul de salturi al rutei căreia aparțin. Prima legătură din tabel aparține rutei cu cel mai mic număr de salturi, iar ultima rutei cu cel mai mare număr de salturi. Legăturile pentru rutele cu număr egal de salturi sunt ordonate arbitrar.

Când un apel solicită rutare, este cercetată prima pereche din tabel. Legătura trebuie să treacă următoarele teste:

să se încadreze în limita de salturi pentru clasa de rutare

să aibă suficientă bandă disponibilă

nodul de la celălalt capăt trebuie de asemenea să aibă suficientă bandă

să nu fie conectată la un nod deja cercetat

Dacă sunt trecute toate testele, apelul poate folosi legătura (și celălalt nod) iar decizia de rutare trece la următorul nod unde este găsită altă legătură către destinație. Prin repetarea procesului, ruta este construită legătură cu legătură și banda este rezervată până la atingerea destinației, după care va fi menținută pe durata apelului. Acest proces este instantaneu relativ la timpul simulării.

Dacă perechea "legătură/nod" din tabel nu trece testele, este cercetată următoarea și așa mai departe până este găsită o legătură validă.

Dacă nu este găsită nici o rută, este activat indicatorul de preemption și protocolul de rutare o va lua de la capăt la primul nod și va reîncerca rutarea apelului, testând nod cu nod pentru a testa dacă poate fi eliberată suficientă bandă. Dacă poate fi găsită suficientă, atunci apelurile cu prioritate mică sunt eliberate, banda rezervată și apelul rutat.

Dacă nu se reușește stabilirea rutei normal sau cu preemption, apelul va fi blocat și reîncercat opțional, în funcție de caracteristicile clasei de rutare.

Dacă existe mai multe rute cu același număr de salturi, între sursă și destinație, ordonarea perechilor legătură/nod pentru aceste rute este arbitrară. Una dintre ele va fi în fruntea listei și va fi aleasă prima de protocolul de rutare. Când aceasta eșuează în rutarea unui apel (din lipsă de bandă de exemplu), va fi luată în considerare următoarea pereche din tabel, pentru o rută cu același număr de salturi și va fi mutată în fruntea listei, devenind preferată, până când devine complet ocupată.

Ca să nu se aștepte ocuparea completă a unei legături înainte de a fi luate în considerare și altele, pe rute cu același număr de salturi, este furnizat parametrul Deviation Percent. Dacă are valoarea 0, operațiile se desfășoară cum a fost descris anterior. Dacă deviația este pozitivă, legăturile rutelor a căror lungime se încadrează în deviația dată față de ruta minimă, sunt considerate echivalente și utilizate în ordine circulară. De exemplu, o rute cu 4 sau 5 salturi pot fi considerate echivalente dacă deviația este 25% sau mai mult. Destinația unei rute poate fi un punct de acces într-o subrețea și algoritmul este executat numai până acolo, în continuare acționând protocolul subrețelei. Rutele care conțin elemente defecte sunt considerate invalide și perechile legătură/nod corespunzătoare sunt eliminate din tabelele de rutare de la noduri, urmând ca la repararea componentelor, sunt recalculate din nou rutele și perechile legătură/nod sunt introduse din nou în tabele.

Dacă decizia de rutare este luată la un nod intermediar, este posibil ca perechea legătură/nod ce corespunde ieșirii către ruta de lungime minimă să nu aibă capacitatea de a transporta apelul. În acest caz este testată următoarea pereche, ș.a.m.d. până când este găsită o legătură disponibilă sau apelul este blocat. Presupunând că există o pereche liberă, aceasta va reflecta ruta minimă la acel moment între nodul curent și cel destinație. S-ar putea ca aceasta să nu fie însă ruta optimă ci să existe o alta dacă s-ar fi luat o decizie diferită la un nod anterior. COMNET III nu se întoarce la nodurile anterioare pentru a găsi o altă rută mai bună. Furnizează însă un interval de actualizare a tabelelor de rutare, care forțează recalcularea periodică a acestora. Aceasta înseamnă ca la momentul actualizării, este efectuată o analiză completă pentru a stabili rutele optime. În consecință, ar putea avea loc alegerea unei rute defavorabile între momentul saturării unui nod și cel al actualizării tabelelor de rutare. Pentru a minimiza acest comportament, intervalul de actualizare ar trebui să aibă o valoare cât mai mică, ceea ce va încetini însă simularea.

5.4.2. Penalizare minimă. Tabele de penalizare.

Algoritmul de rutare cu penalizare minimă, găsește ruta cu cele mai puține puncte de penalizare, între origine și destinație. Penalizările (punctele de penalizare) sunt valori întregi, aplicate legăturilor în cazul folosirii tabelelor de penalizare. Ele pot fi folosite pentru a reprezenta distanța (cu cât este mai mare distanța, cu atât este mai mare penalizarea), costul sau orice caracteristică se dorește. De exemplu, pentru pachete, penalizările pot reprezenta utilizarea legăturii (în procente) sau întârzierea introdusă de o legături (în secunde). Un tabel este aplicat unei anumite legături pentru a defini penalizările pentru acea legătură, ce se vor aplica diferitelor clase de rutare. Tabelul este definit de fapt pe arcul (reprezentând portul) ce conectează legătura de nod și reprezintă penalizările pentru traficul ce intră în legătură din acel nod, astfel că penalizările pe o legătură pot fi diferite pe fiecare direcție, legătura fiind conectată la cele două noduri cu arce separate.

Valorile penalizărilor pot fi variabile, de asemenea, în funcție de utilizarea legăturii. Pe măsură ce utilizarea legăturii crește, valoarea penalizării crește astfel că ruta nu mai este selectată ca având cea mai mică penalizare. Aceasta este o strategie de rutare adaptivă. De exemplu, penalizarea poate avea valoarea 1 pentru o utilizare a legăturii între 0 și 25 % și valoarea 5 pentru utilizare peste 25% (v. Fig. 5.20).

Pentru mai multe clase de rutare se pot aplica penalizări separate, prin crearea mai multor coloane în tabel.

Un singur tabel poate fi aplicat mai multor legături, astfel că actualizarea tabelelor de penalizare poate consta în actualizarea unuia singur.

Trebuie create tabele separate pentru traficul de pachete și cel de apeluri.

Notă: O penalizare negativă interzice unei clase de rutare să folosească o anumită direcție a legăturii.

Dacă penalizarea pentru fiecare legătură este 1, algoritmul drumului minim și cel al penalizării minime sunt identici.

Algoritmul se desfășoară absolut identic cu cel al drumului minim, cu excepția faptului că nu se contorizează suma salturilor ci suma penalizărilor.

5.4.3. Tabele de rutare definite de utilizator

Protocolul de rutare bazate pe tabelele definite de utilizator selectează o rută din 1 sau mai multe rute alternative, introduse manual de utilizator. Pot fi introduse de asemenea rute parțiale, care transportă apelul la noduri intermediare unde trebuie să fie obligatoriu disponibile una sau mai multe rute pentru transportul apelului până la destinație.

Când este introdus un număr de rute posibile, trebuie ales și un criteriu de selectare. Variantele posibile sunt:

Dynamic Alternate

First Available

Max Idle Bandwidth

Round Robin

O rută este implementată prin definirea tabelelor la fiecare nod. Fiecare tabel conține fie o variantă de alegere între legături singulare până la nodul următor, fie o listă de câteva legături pentru a ruta apelul până la destinație. Aceste variante pot fi privite ca implementarea rutării nod-cu-nod, respectiv rutarea de tip nod sursă. În plus, sunt permise rute parțiale ce fac parte din drumul până la destinație.

În tabele pot fi definite atât rute primare cât și secundare. La executarea unei decizii de rutare, sunt inspectate mai întâi cel primare pentru stabilirea unei rute. Dacă încercarea eșuează, urmează cercetarea rutelor secundare. Dacă și pe acestea rezultatul este negativ apelul este considerat blocat, cu excepția situației când este activată opțiunea de pregolire (preemption).

Opțiunea Avoid Backtracking nu are nici o influență asupra execuției modelului. La definirea unei rute, cu această opțiune activată, legăturile care se întorc la un nod aflat deja în rută, nu vor apare în rubrica Possible Next Hops. Buclarea (backtracking), poate fi folositoare pentru anumite dispozitive de rețea sau echipamente.

CAPITOLUL VI

APLICAȚIE PRACTICĂ REALIZATĂ CU PROGRAMUL COMNET III

6.1. Premize

În acest capitol a fost realizată o aplicație practică, pentru concretizarea unui studiu de modelare, folosind pachetul de programe COMNET III.

Trebuie menționat de la bun început că acesta este un studiu didactic, o primă încercare mai elaborată, cu ocazia acestui proiect de diplomă, de a explora posibilitățile programului COMNET III, nou achiziționat, ale cărui resurse și posibilități nu sunt pe deplin cunoscute pentru a fi exploatate la adevărata lor capacitate. Tocmai din acest motiv am încercat să deschid o fereastră către cunoașterea mai amănunțită a acestui puternic instrument de modelare, simulare și analiză a sistemelor de comunicații.

COMNET III este foarte folositor și interesul pentru aplicabilitatea sa ar trebui să crească, mai ales datorită faptului că transmisiunile Armatei Române fac primii pași în era digitală prin construirea S.T.A.R.

Așa cum am arătat în capitolele anterioare ale lucrării, COMNET III poate fi folosit în toate fazele construirii și funcționării unui sistem de comunicații: atât în cea de proiectare, pentru evaluarea performanțelor și optimizarea viitoarei structuri și configurări a sistemului, cât și în faza de exploatare pentru predicția efectului anumitor schimbări destinate îmbunătățirii performanțelor sau pentru studiul necesar rezolvării anumitor neajunsuri sau alterări ale performanței apărute pe parcurs.

Copia programului aflată în posesia Academiei Tehnice Militare este cea destinată mediului universitar, viitorilor specialiști în domeniul telecomunicațiilor, care odată ajunși la locul de muncă și confruntați cu diferite dificultăți ale sistemelor pe care le proiectează sau le exploatează, să știe că au la îndemână un instrument puternic care îi poate ajuta în numeroase situații, din cele mai diverse. Varianta universitară nu include o serie de opțiuni și facilități, de exemplu modulul Base Liner, folosit pentru importul unor baze de date ce conțin informații și măsurători ale unor rețele reale, date concrete ce pot fi folosite ca intrări ale modelului, cu ajutorul cărora se poate spune că se realizează cu adevărat un studiu concret, al unui sistem real.

Pentru aceasta ar trebui bineînțeles să existe interesul și nevoia pentru studiul sistemului, de acum actual, de transmisiuni al armatei. Această nevoie va exista cu siguranță și este bine de știut că există un instrument la care s-ar putea apela și care la nevoie ar putea rezolva diverse probleme.

În mod evident, sistemul (S.T.A.R.) a fost proiectat de numeroși specialiști, cu vastă și îndelungată experiență în domeniu și datorită faptului că este un sistem militar, au fost luate în considerare numeroase și stricte cerințe de proiectare, pe care la nivel global, sistemul le îndeplinește și nu are probleme majore. Dar în mod evident nu au putut fi prevăzute absolut toate problemele posibile și mai ales datorită faptului că asamblarea și configurarea sistemului nu decurge chiar conform planului, la nivel local, problemele pot fi numeroase și variate, iar unele dintre ele pot fi rezolvate, de ce nu, cu COMNET III.

Lucrarea de față, nu are în vedere acest lucru, anume rezolvarea unei probleme concrete a sistemului, ci ilustrarea posibilităților programului în studiile de modelare și a faptului că flexibilitatea lui permite reprezentarea cu un grad crescut de realism a componentelor și caracteristicilor de funcționare ale S.T.A.R.

Așa cum am prezentat și în partea teoretică (v. 1.7.2), trebuie menționată clar diferența între simulare și emulare. Aplicația și în general programul COMNET III, nu-și propune să reprezinte structura și funcționarea sistemelor de comunicații și a componentelor acestora în cel mai mic amănunt, ci numai caracteristicile importante și care reprezintă interes pentru problema de studiat, fără a se îndepărta totuși de funcționarea corectă și reală a sistemului.

Aplicația de față își propune modelarea, simularea și analiza unei structuri din componența S.T.A.R., mai concret Centrul de Transmisiuni de Instrucție din laboratoarele Catedrei de Transmisiuni din Academia Tehnică Militară.

Așa cum am precizat anterior, scopul nu este reprezentarea amănunțită a funcționării componentelor S.T.A.R. COMNET III nu deține de exemplu parametri pentru modulația Delta sau pentru implementarea standardului EUROCOM ce stă la baza funcționării sistemului.

Poate modela în schimb toate tipurile de trafic, fie cu comutare de pachete, fie de circuite (voce, fax, telex, video, date), caracteristicile canalelor de comunicație (bandă, întârzieri, rata erorilor, etc.), caracteristicile echipamentelor de comunicație (întârzieri de procesare, timpi de răspuns, procesoare și caracteristicile acestora: număr, perioadă de tact, întârzieri de procesoare, memorii tampon; caracteristicile dispozitivelor de stocare: capacitatea discului, timpi de acces, timpi de scriere/citire, etc; ) și multe altele. Cu alte cuvinte există numeroase seturi de parametri și de opțiuni ce fac posibilă reprezentarea cu un grad ridicat de realism a majorității sistemelor de comunicații.

Lucrarea de față nu își propune de asemenea o descriere a funcționării echipamentelor S.T.A.R., ci numai modul lor de reprezentare cu COMNET III, mai ales că se urmărește studiul unor caracteristici generale de funcționare și de trafic, presupuse în general cunoscute.

Aplicația își propune să urmeze cât mai îndeaproape pașii desfășurării unui proces de modelare (v. 1.3 și 1.4), dar așa cum am menționat, lipsa rezultatelor unor măsurători reale ale sistemului, de natură mai mult sau mai puțin statistică, care să fie folosite ca parametri de intrare ai modelului și care să stea la baza setării parametrilor puși la dispoziție de COMNET III, a dus la dificultatea adăugării notei de realism din punct de vedere al rezultatelor, ci numai din punct de vedere al structurii și caracteristicilor funcționale.

Interpretarea rezultatelor se va face deci sub amendamentul valorilor teoretice ale datelor de ieșire ale modelului.

Construirea modelului va avea la bază etapele construirii și simulării modelelor cu COMNET III, descrise în capitolul IV.

6.2. Construirea modelului

Așa cum am menționat, aplicația își propune modelarea și simularea Centrului de Transmisiuni de Instrucție montat în cele trei laboratoare din Catedra de Transmisiuni. Schema de principiu care stă la baza modelului este ilustrată în Fig. 6.1., o reprezentare mai amănunțită găsindu-se în Anexa 1.

Așa cum am menționat anterior, nu interesează amănuntele conexiunilor fizice ale echipamentelor, grupurile de alimentare, etc. ci numai caracteristicile funcționale și de trafic ale principalelor componente: multiplexoare, comutatoare, linii de legătură și abonați.

În cele ce urmează, vor fi urmărite etapele construirii și simulării unui model, prezentate în Capitolul IV, respectând în linii mari, în același timp și algoritmul de modelare descris în subcapitolul 1.4.

6.2.1. Topologia rețelei

Aceasta este faza de validare a modelului în care sunt selectate acele resurse ce vor fi reprezentate și identificate caracteristicile sistemului ce pot necesita o atenție specială, precum și stabilirea structurii modelului.

Topologia generală a rețelei va include cele trei noduri de comunicație, care vor transporta trafic atât cu comutare de circuite, prin cei câțiva abonați telefonici, cât și cu comutare de pachete prin trei sesiuni de lucru între calculatoare personale.

Din structura centrului vor fi reprezentate și modelate numai multiplexoarele și comutatoarele, deoarece caracteristicile sistemului ce se urmăresc a fi studiate sunt date de aceste componente. Nu sunt reprezentate individual radioreleele, deoarece studiul nu vizează parametrii acestora și nici ai legăturilor radio ca suport de transmitere a datelor. Ele vor fi înlocuite cu legături punct-la-punct ce transportă fluxuri de 2Mb/s (MH 344) și respectiv 34 Mb/s (MH 88).

Abonații telefonici vor fi modelați cu surse de apel, furnizate de COMNET III special pentru traficul cu comutare de circuite. De menționat că abonații pot avea și alte forme (fax, telex), însă vor fi modelați tot cu surse de apel, modificându-se eventual anumiți parametri.

Calculatoarele ce stabilesc legături de date, vor fi reprezentate cu surse de sesiune, care modelează în COMNET III trafic cu comutare de pachete orientat pe conexiune, de tip circuit virtual.

Comutatoarele și multiplexoarele vor fi modelate separat, însă cu aceeași categorie de obiecte COMNET III, anume noduri. Prin seturile complexe de parametri acestea pot reprezenta majoritatea dispozitivelor de rețea existente. De exemplu în cadrul modelului, numai multiplexoarele pot fi surse și destinații de trafic, comutatoarele fiind restricționate numai la îndeplinirea funcțiilor de comutare, neputându-li-se atașa surse de trafic (de apel sau de pachete).

Legătura internă dintre comutator și multiplexor este modelată cu o legătură punct-la-punct de 2Mb/s. Atât legăturile prin fir de 2Mb/s, cât și legăturile radioreleu sunt modelate cu legături punct-la-punct. Așa cum am precizat la punctul 6.1, nu s-a putut și nici nu s-a urmărit reprezentarea exactă a structurii cadrului Delta (cu time-slot-uri). O legătură punct-la-punct are de exemplu o bandă de 2 Mb/s, împărțită în 64 de canale de 32 Kb/s, folosite în comun atât de apeluri cât și de pachete, așa cum va fi descris mai târziu.

În consecință, structura unui model COMNET III al topologiei ilustrate în Fig. 6.2, va avea o structură ca cea din figura următoare (v. Anexa 2):

Descrierea obiectelor modelului:

O observație valabilă pentru toate componentele modelului este aceea că parametrii care nu au semnificație pentru studiul de față, au fost lăsați cu valorile implicite, neavând nici o influență asupra funcționării modelului.

De asemenea, există anumiți parametri care sunt luați în considerare în cadrul simulării dar pentru care nu am dispus de valori reale, măsurate la echipamentele sistemului și au fost lăsați cu valori implicite, însă în majoritatea cazurilor, li s-au atribuit valori intuitive sau recomandate de COMNET III.

Valorile implicite ale parametrilor duc la comportamente ideale. De exemplu: întârzieri de procesare 0 sau capacități de memorare infinite sau foarte mari.

Acolo unde programul solicită în mod obligatoriu valori ale parametrilor, au fost introduse cele recomandate de realizatorii programului sau pur și simplu valori intuitive, fără o anume argumentație. De exemplu, proiectanții COMNET III recomandă pentru frecvența de generare a apelurilor o distribuție exponențială și pentru durata acestora o distribuție normală (vezi Anexa 3).

Multiplexoarele:

MUX1 (MT441), MUX2 (MT441), MUX3 (MT441), MUX21 (MD321) și MUX31 (MD321).

Sunt modelate cu noduri de procesare pentru care a fost definite seturi specifice de parametri numite "Multiplexor MT441" sau "Multiplexor MD321" (v. 5.2.3.).

Nodurile sunt de tip "Source or sink only", ceea ce înseamnă că pot fi numai sursă și destinație de trafic și nu pot îndeplini sarcini de comutare, deoarece nu este nevoie, el având numai funcția de construire a cadrului EUROCOM, cu alte cuvinte, de a construi fluxul de 2Mb/s.

Notă:

În acest stadiu al modelării, de setare a parametrilor obiectelor de modelare, sunt necesare date reale, măsurate la echipamentele sistemului. De exemplu:

întârzieri la porturile de intrare și ieșire

capacitatea totală a bufferelor de intrare și ieșire

Neavând la dispoziție date provenite din măsurători în rețea, am apelat la documentația echipamentelor STAR și la datele disponibile de la consola LLNM (Low Level Network Manager). Am extras câteva valori concrete care să poată fi folosite în setarea parametrilor COMNET III.

întârzierea de comutare a CD141: 26 s

limita expirării încercării de stabilire a legăturii: 20 sec

capacitățile bufferelor comutatoarelor sunt multipli de mărimea cadrului (64 canale = 64 biți) și au fost alese 256/ 512 biți (cu rezerva unor modificări ulterioare).

prin analogie a considerat întârzierea multiplexorului: 10 s

au mai fost stabilite și valori ale întârzierilor de propagare pe legăturile punct-la-punct de ordinul milisecundelor.

Parametrii cei mai semnificativi sunt cei referitori la apeluri și au fost setați cu următoarele valori (v. 5.2.3.):

Number of circuits: 64 (1024 pentru MD321)

Bandwidth/circuit (kbps): 32

Subchannel: None

Subchannel: None.

Restul parametrilor, referitori la ciclul procesorului, numărul de procesoare, fereastra de timp (time slice) pentru reactualizarea sarcinilor la procesor, prioritățile de acces la procesor, capacitățile de stocare, au fost lăsate pe valorile implicite.

OBSERVAȚIE: Am considerat atât pentru legături cât și pentru celelalte echipamente că numărul de canale utile este de 64 (cu o viteză de 32Kb/s), înglobând și primele două canale (de sincronizare și semnalizare ale cadrului EUROCOM). Motivul nu a fost altul decât acela de a lucra cu valori cunoscute pentru unitățile de măsură ale benzii și cu multipli consacrați ai acestora (2,048 Mb/s, etc.)

Comutatoarele:

COM1 (CD141), COM2 (CD141) și COM3 (CD141)

Au fost modelate cu dispozitive de rețea, care fac parte tot din categoria noduri însă au o altă structură internă (v. 5.2.4.). Pentru ele a fost definit un set personalizat de parametri numit "Comutator CD141". Cu această categorie de obiecte se pot modela routere, switch-uri, ș.a. Față de nodul de procesare, care are o structură bazată pe procesor, porturi cu buffere, șiruri de așteptare pentru aplicații în execuție și dispozitive de stocare (v. Fig. 5.11), dispozitivul de rețea are o structură compusă dintr-o parte comună nodurilor – procesor și porturi cu buffere – și o parte specifică bazată pe magistrale de comutație (v. Fig. 5.19). Ceilalți parametri sunt comuni nodului de procesare, mai puțin cei referitori la magistrale (v. 5.2.4.) care au fost setați după cum urmează:

Bus Rate: a fost setat cu valoarea 100 Mb/s.

Bus Count: 4(5) Datorită faptului că echipamentele CD141 sunt comutatoare fără blocare, pentru îndeplinirea acestei condiții, valoarea acestui parametru trebuie să fie cel puțin egală cu numărul de legături conectate la comutator (în cazul nostru 4 sau 5).

Pachetele sunt obligate să folosească procesorul pentru a scoate în evidență întârzierile de comutare, datorate procesării în dispozitivul de rețea. Întârzierile mai pot fi datorate și așteptării în bufferele porturilor de intrare și ieșire. Am setat aceste întârzieri astfel încât în total să dea 26 s (întârzierea de comutare a CD141).

Parametrii referitori la apeluri (circuitele comutate), au fost setați astfel:

Number of circuits: 256 (pentru a acoperi toate legăturile conectate).

Bandwidth/circuit (kbps): 32

Subchannel: None

Subchannel: None.

Legăturile:

2Mb/s, fir: Legătura 1, Legătura 2, Legătura 3, Legătura 12,

Legătura 13, Legătura 23, Legătura 231, Legătura 232.

2Mb, radio: MH 344

34Mb, radio: MH 88

Legăturile, fie cele prin fir, fie cele prin radioreleu au fost modelate cu legături punct-la-punct de 2 Mb/s și 34 Mb/s. Legăturile punct-la-punct sunt specifice în COMNET III traficului cu comutare de circuite și sunt cele mai potrivite pentru modelarea fluxurilor între echipamentele STAR. Ele suportă bineînțeles și trafic cu comutare de pachete.

Conectarea fizică, prin fir, cu 2Mb/s, a două echipamente din cadrul STAR (de exemplu (MT 441 și CD 141), se face pe 4 fire, două de emisie și două de recepție, pe fiecare pereche putând exista un flux de 2Mb/s. Când este inițiat un apel și acesta își rezervă o bandă de 32kbps, de-a lungul întregii rute, ocupă un canal atât pe calea de emisie cât și pe calea de recepție. Cu alte cuvinte, pentru fiecare legătură de 2Mb/s avem două perechi de fire cu proprietăți identice și trafic simetric. Nu contează de la care nod (dintre cele două conectate) sosește apelul, el va ocupa câte 32kbps pe fiecare pereche de fire. În consecință, în modelul COMNET III a fost reprezentată numai una din cele două perechi, cealaltă fiind subînțeleasă.

Legăturile de tip punct-la-punct au fost configurate astfel încât între fiecare două centre să existe un canal de 32 kbps disponibil pentru transmsii de date (trafic de pachete) între calculatoare și restul de canale (63) să fie disponibile pentru apeluri. A fost dezactivată opțiunea Packets and calls share the same channel care ar fi însemnat ca pachetele să folosească orice bandă disponibilă, neocupată de apeluri, ceea ce nu se întâmplă în realitate unde sesiunile de lucru între calculatoare ocupă canale separate, ca și apelurile.

Întârzierea de propagare (Propagation (ms)) a fost setată cu valoarea 10 ms.

Parametrii referitori la controlul erorilor la nivel legătură de date (Frame error probab și setul de parametri Framing) au fost lăsați cu valori implicite.

Parametrii pentru pachete sunt:

Number of circuits: 1

Bandwidth/circuit (kbps) – from node X: 32

Bandwidth/circuit (kbps) – from node Y: 32

Parametrii pentru apeluri sunt:

Number of circuits: 63

Bandwidth/circuit (kbps): 32

Opțiunile referitoare la Subchannel și Superchannel (v. 5.2.2.) au fost anulate, pentru că nu există posibilitatea folosirii de către două apeluri a aceluiași canal sau de un apel a mai multor canale.

6.2.2. Adăugarea traficului în rețea

În construirea modelului au fost folosite două tipuri de surse de trafic: apeluri (Call Source) și sesiuni de lucru (Session Source). Sursele de apel au fost folosite pentru modelarea traficului de voce (eventual fax sau telex, dar nu în acest caz), iar sesiunile de lucru au fost folosite pentru modelarea traficului de pachete între calculatoare. S-a ales varianta sesiunilor de lucru deoarece corespunde cel mai bine funcționării STAR și anume trafic de pachete orientat pe conexiune, de tip circuit virtual.

Sursele de apel:

De menționat că destinația unui apel generat cu obiectul Call Source este un nod și nu o altă sursă de apel, inițierea unui apel considerând ca implicită prezența unui interlocutor conectat la nodul destinație.

Parametrii surselor de apel sunt următorii:

Schedule by: Iteration time (apelurile sunt generate în funcție de parametrii de timp enumerați mai jos).

Interarrival (sec): Exp(120) (Perioada funcției de generare a apelurilor respectă o distribuție exponențială cu media 120 secunde, v. Anexa 3)

First arrival: none (primul apel este generat la un moment între secunda 0 și media distribuției frecvenței de generare – 0 și 120).

Last arrival: none (apelurile sunt generate pe întreaga durată a simulării, până la sfârșitul acesteia).

Duration: Norm(3,0.2) (durata apelurilor respectă o distribuție normală cu media 3 minute și deviația standard 0.2 minute, v.Anexa 3).

Routing Class: Voce = clasa de rutare, cu următorii parametri

Hop limit: 4 (numărul maxim de salturi suportat pentru stabilirea rutei).

Bandwidth required (bps): 32000 (banda necesară unui apel).

Call retry interval: none (nu se reîncearcă reluarea apelului în caz de eșec).

Reroute connections: DA (se încearcă stabilirea legăturii pe altă rută, în caz de congestie sau de deconectare).

Priority: 1, 2 sau 3 (au fost modelate surse de apel cu diferite priorități).

Destinations: Random list (apelurile își aleg aleator destinația dintr-o listă conținând mai multe destinații, în acest caz, celelalte două multiplexoare primare MT 441).

Sesiunile de lucru

Trebuie făcută aceeași mențiune ca și la sursele de apel și anume că sursele de sesiune au ca destinație un nod, nu o altă sursă de sesiune. Calculatorul pereche de la celălalt capăt este de la sine înțeles. Importantă este ocuparea canalului, nu din ce sens se transmite. Sursa poate fi setată să transmită orice volum de date. Sesiunea de lucru este împărțită în mesaje, fiecare mesaj având o anumită dimensiune, dată în octeți sau număr de pachete. Numărul de mesaje într-o sesiune, precum și mărimea acestora, au o valoare fixă. Ceea ce variază sunt parametrii temporali, care pot respecta distribuții statistice, ca și la sursele de apeluri.

Pentru a modela tranzacții sincrone, sursa poate fi setată să aștepte răspuns la fiecare mesaj, eventual cu o anumită întârziere, prin activarea opțiunii Time measured after receiving response. Este prevăzut și un timp de expirare a legăturii dacă nu se primește răspuns într-un anumit interval de timp, datorită congestiilor sau defectărilor componentelor rețelei.

În modelul de față sunt definite trei sesiuni de lucru, câte una între fiecare două centre. Sesiunile sunt identificate de legături și noduri drept "Aplicația 12" (între MUX1 și MUX2), "Aplicația 23" (între MUX 2 și MUX 3) și "Aplicația 31" (între MUX 3 și MUX 1). Fiecare sesiune de lucru este programată să aibă loc o dată la 5 minute, să transmită un număr de aproximativ 100 de mesaje (după o distribuție normală), la un interval de aproximativ 2 secunde și să conțină 100 de pachete (fiecare mesaj). Timpul limită de așteptare a răspunsului este de 20 sec. Mărimea pachetului explorator, de stabilire a sesiunii este lăsată cu valoarea implicită (5 octeți). Parametrii referitori la timpul de împachetare au fost lăsați cu valoarea implicită 0.

Parametrii surselor de sesiune sunt:

Interarrival: 300

First arrival: none.

Session Setup Packets

Setup (bytes): 100

Confirm (bytes): 100

Messages

Msgs/session: Norm(100, 1) = numărul de mesaje într-o sesiune. Respectă o distribuție normală (v.Anexa 3)

Msg IAT (sec): Exp(2) = Message Interarrival Time = intervalul de timp între mesaje. Respectă o distribuție exponențială (v. Anexa 3).

Timeout (sec): 20 = timpul limită de așteptare a răspunsului

Message size (packets): 100

Toate sursele de sesiune au fost încadrate în aceeași clasă de rutare numită "Sesiune", cu următorii parametri:

Hop limit: 6 = numărul maxim de salturi permis pentru o rută

Session retry interval: none = nu se reîncearcă restabilirea sesiunii

Reroute connections: DA

Restul parametrilor au fost lăsați cu valori implicite, neavând semnificație.

6.2.3. Definirea algoritmilor de rutare

Atât pentru pachete cât și pentru apeluri au fost folosiți algoritmii de rutare cu penalizare minimă (v. 5.4.2.). S-au definit tabele cu penalizări pe nivele de utilizare a legăturii.

Tabelul de penalizare pentru apeluri este identic și ambele categorii au fost aplicate tuturor legăturilor, mai puțin celor care alcătuiesc legătura de 34 Mb/s între COM2 și COM3, deoarece capacitatea legăturii este oricum prea mare pentru nevoile rețelei și pragurile de utilizare nu sunt atinse niciodată, în orice caz, nu toate.

Pentru pachete în cazul algoritmului de rutare Minimum Penalty a fost activată opțiunea Connection-oriented routing for sessions, opțiune deosebit de importantă pentru adăugarea realismului necesar modelului, deoarece asigură o rutare a pachetelor sesiunii de tip "circuit virtual comutat".

Pentru apeluri, la același algoritm, a fost activată opțiunea Preemption care asigură eliberarea apelurilor cu prioritate mică de către cele cu priorități superioare, în cazul congestiei.

Pentru ambele categorii de trafic s-a stabilit un interval de actualizare a tabelelor de rutare de 60 secunde, pentru a nu îngreuna foarte mult simularea.

De asemenea a fost stabilit un interval de toleranță de 25% pentru valoarea penalizării rutei minime (v. 5.4.2. – Deviation Percent).

6.2.4. Setarea parametrilor simulării

Durata simulării a fost stabilită la 1 oră (în timpi de simulare), fără nici un interval de încălzire, ceea ce înseamnă că rezultatele statistice vor fi colectate din prima secundă. Nu au fost activate nici una din opțiunile de animație (de animare a pachetelor sau de urmărire a apelurilor) pentru că pentru o vizualizare destul perceptibilă pentru ochi (pe viteză minimă) pentru a putea face observații, timpul de simulare s-ar transpune aproape în timp real. Animația va putea fi activată oricând pentru observații deoarece nu influențează rezultatul simulării ci numai îi prelungește durata.

6.2.5. Generarea rezultatelor

Rezultatele simulării în COMNET III pot fi generate sub mai multe forme:

Monitorizări

Grafice în timp real

Rapoarte statistice

Rapoartele statistice sunt o formă centralizată de colectare a rezultatelor simulării și sunt generate sub formă de fișiere text ce conțin tabele cu date statistice (procente, rezultate ale unor numărători) colectate pentru diferiți parametri ai sistemului. Rapoartele pot fi selectate dintr-o listă extinsă de posibilități și restrânse la colectarea de date pentru anumite componente ale sistemului și parametri ai acestora (v. Anexa 4). Rapoartele statistice sunt generate numai sub formă de valori finale, neavând posibilitatea reprezentării grafice.

Monitorizările și graficele în timp real sunt metode de urmărire individuală a diferitelor componente ale sistemului, prin solicitarea colectării de date pentru anumite variabile ale acestora. Monitorizările și reprezentările în timp real sunt solicitate separat la fiecare componentă a sistemului, fiind selectate dintr-o listă de opțiuni, disponibilă pentru fiecare categorie de obiecte. Monitorizările, spre deosebire de rapoartele statistice, au posibilitatea reprezentării grafice a valorilor parametri pe toată durata simulării, în diferite formate (valori observate, histograme, etc.), cu diverse opțiuni (alegerea intervalului de reprezentare, numărul de puncte în care se face reprezentarea, etc). Există de asemenea posibilitatea simplificării monitorizării prin furnizarea pe intervale de timp specificate numai a valorilor medii sau a extremelor. Graficele în timp real pot fi generate pe intervale de timp definite de utilizator și afișează valoarea în timp real a unui anumit parametru precum și valoarea medie.

Monitorizări solicitate pentru aplicația curentă:

Noduri:

Busy processors: numărul de procesoare ocupate. Pentru un singur procesor, ca în cazul de față, rezultatul este utilizarea procesorului.

Input Buffer Level: măsoară nivelul buffer-ului de intrare al nodului.

Output Buffer Level: măsoară nivelul buffer-ului de ieșire al nodului.

Call Bandwidth Level: banda totală alocată de nod apelurilor.

Calls In Progress: numărul de apeluri în desfășurare la un moment dat

Channels In Use: numărul de canale utilizate la un moment dat.

Busy Buses: (numai pentru comutatoare) numărul de magistrale ocupate cu comutarea pachetelor, la un moment dat.

Legături:

Busy Channels From 1st Node: numărul de canale utilizate de primul nod

Busy Channels From 1st Node: numărul de canale utilizate de al doilea nod

Call Utilization: banda legăturii utilizată de apeluri la un moment dat

Channels in Use: numărul de canale în folosință la un moment dat

Sessions In Progress: Numărul de sesiuni în desfășurare pe legătură.

Surse de sesiune:

Msg. Delivered Delay: măsoară întârzierea de livrare a unui mesaj, înainte ca mesajul să fie reasamblat la destinație.

Messages In Transit: numărul de mesaje în tranzit.

Rapoarte statistice solicitate pentru aplicația curentă:

Noduri:

Node Full Utilization: un sumar al nivelului de utilizare al procesoarelor și porturilor la fiecare nod

Session Level: numărul de sesiuni desfășurate (transportate) la fiecare nod.

Call Counts: un sumar al numărului de apeluri încercate, transportate, blocate, deconectate sau eliberate de un nod.

Call Level: o evidență a benzii ocupate de apeluri.

Input Buffer Totals: o evidență a utilizării buffer-ului de intrare al nodului, care reprezintă suma capacității tuturor bufferelor porturilor de intrare ce conectează nodul la legături.

Output Buffer Totals: o evidență a utilizării buffer-ului de ieșire al nodului, care reprezintă suma capacității tuturor bufferelor porturilor de intrare ce conectează nodul la legături.

Input Buffer Use By Port: o evidență a utilizării bufferelor porturilor de intrare.

Legături:

Utilization By Aplication: utilizarea legăturii de aplicațiile definite de sursele de sesiune (Aplicația 12, Aplicația 23, Aplicația 31).

Utilization By Protocol: o evidență a utilizării legăturii de către protocolul de transport, denumit generic EUROCOM, a cărui singură caracteristică definită este mărimea pachetului de date (100 octeți).

Session Level: numărul de sesiuni de lucru stabilite pe fiecare legătură.

Call Counts: un sumar al numărului de apeluri încercate, transportate, blocate, deconectate sau eliberate de o legătură.

Call Level: rezultate privind rata de utilizare și alte statistici privind traficul cu comutare de circuite.

Surse de apel:

Blocked Call Counts: detalii despre numărul de apeluri încercate, blocate, destinațiile și numărul de salturi necesare pentru transportul apelului.

Disconnected Call Counts: detalii despre numărul de apeluri încercate, deconectate, destinațiile și numărul de salturi necesare pentru transportul apelului.

Preempted Call Counts: detalii despre numărul de apeluri încercate, eliberate, destinațiile și numărul de salturi necesare pentru transportul apelului.

Surse de sesiune:

Message Delay: Statistici privitoare la întârzierea mesajelor unei surse de sesiune. Întârzierea unui mesaj este timpul scurs de la creerea pachetului de către nodul de origine, până în momentul când nodul care l-a generat este anunțat că mesajul a fost asamblat la destinație. Aceasta este întârzierea sesizată de expeditorul pachetului.

Message Delivered: Timpul scurs de la generarea primului pachet la origine și recepționarea ultimului pachet al mesajului la destinație.

Packet Delay Report: un sumar al numărului de pachete create, livrate, retrimise sau anulate. Este afișată de asemenea o întârziere medie și maximă.

Setup Delay: statistică referitoare la timpul necesar stabilirii sesiunii de lucru între origine și destinație și la numărul de sesiuni. Întârzierea de stabilire a sesiunii este timpul scurs de la generarea pachetului explorator până la recepționarea celui de confirmare.

Session Length: o statistică pentru sursele de sesiune, referitoare la durata unei sesiuni stabilite între sursă și destinație.

Setup Counts: numărul de încercări de setare a unei sesiuni, numărul de încercări reușite, numărul de reîncercări, deconectări și rerutări.

6.3. Interpretarea rezultatelor

Pentru modelul de față ar fi mai potrivită pentru început terminologia "observarea rezultatelor". Pentru aceasta ar trebui să dispunem, așa cum am menționat și la începutul capitolului, de rezultate concrete ale măsurătorilor efectuate în sistem, pentru a putea compara rezultatele simulării cu cele reale, în scopul validării modelului construit, pentru a avea certitudinea că funcționează și că modelează într-adevăr rețeaua propusă spre studiu. Abia apoi, pentru a da cu adevărat o utilitate modelării și simulării cu programul COMNET III, ar putea fi încercate diferite scenarii ale configurării sistemului și interpretate rezultatele obținute. Modelul inițial intenționează să simuleze cât mai bine comportamentul sistemului, un sistem care dealtfel funcționează perfect, fără congestii, fără defectări ale componentelor.

În aplicația de față, pentru a putea merge mai departe, este necesar să considerăm valide rezultatele obținute, pentru a încerca alte scenarii.

Cu aceste ipoteze formulate, am propus alte trei variante de configurare și de trafic în sistem, precum și combinații ale acestora. Scenariile propuse au corespondent real și pot fi aplicate oricând sistemului, una dintre ele (modificarea numărului de canale), fiind deja cunoscută și experimentată în Centrul de Transmisiuni de Instrucție:

6.3.1. Micșorarea numărului de canale

Nevoia crescută de bandă pe unele canale (de exemplu pentru transmisii de date de viteză mare), poate duce la micșorarea numărului de canale, prin alocarea mai multor time-slot-uri aceluiași abonat, ceea ce duce automat la alocarea aceluiași număr de canale pentru toți aboonații.

Pentru a ilustra efectele acestei schimbări, am micșorat numărul de canale pe legături și la noduri, de la 64 x 32 Kb/s la 16 x 128 Kb/s și am comparat rezultatele. Concluzia a fost că se îmbunătățesc performanțele sesiunii de lucru între calculatoare dar se înrăutățesc condițiile pentru transportul apelurilor, care au la dispoziție canale mai puține și nu contează dacă sunt de 128 Kb/s, pentru că mai multe apeluri nu pot folosi același canal.

Valorile de mai sus reprezintă fragmentul din raport ce contorizează apelurile pe legăturile punct-la-punct în cazul modelului inițial, cu funcționare normală (fișierul Centrul de transmisiuni.c3).

Mai jos sunt ilustrate valorile în cazul micșorării numărului de canale (fișierul Centrul de transmisiuni_număr mic de canale.c3).

Se observă că apelurile încep să fie rutate pe legătura radioreleu de 34Mb/s (MH88, Legătura 231 și Legătura 232), dar totuși nu este de ajuns și pe legăturile prin fir (Legătura 1, Legătura 2 și Legătura 3) există apeluri blocate și apeluri deconectate de altele cu prioritate superioară. Soluția ar fi de exemplu, dublarea legăturii de 2Mb/s.

6.3.2. Defectarea componentelor rețelei

Un alt scenariu deosebit de ușor de realizat în COMNET III este defectarea intenționată în timpul simulării a uneia din componentele sistemului (nod, legătură). Defectarea unei legături ar avea ca efect rutarea apelurilor pe celelalte, în limita capacității, bineînțeles. Defectarea unui nod, ar avea consecințe mult mai grave asupra traficului în rețea, eliminându-se posibilitatea rerutării.

În tabelele de mai jos sunt ilustrate două situații. Mai întâi o contorizare a apelurilor deconectate din cauza defectării unei componente, care în cazul unei funcționări normale este 0, apoi același fragment de raport în cazul în care în timpul simulării a fost defectată legătura directă, prin fir, între comutatorul nr.1 și comutatorul nr.2. Vor putea fi observate cele câteva apeluri deconectate și apoi rerutate pe celelalte legături. Sunt figurate în raport numai apelurile inițiate de 3 dintre cei 10 abonați ai centrului nr.1

Funcționare normală:

Defectarea legăturii:

O a doua situație ilustrată ar fi defectarea unui nod (MUX1).

Funcționare normală:

Defectarea MUX1:

Se poate observa din ultimul fragment de raport că nu numai că au fost deconectate apeluri, dar abonații au făcut încercări repetate de a iniția apeluri, ce s-au soldat cu eșec. De exemplu, abonatul 11 (Ab 11), din 20 de apeluri către centrul nr. 2 (MUX2) a reușit decât un apel și din 16 apeluri către centrul nr. 3 (MUX3), a reușit 6 dar unul a fost deconectat de defectarea nodului, finalizând decât 5.

6.3.3. Creșterea traficului

COMNET III are posibilitatea creșterii traficului cu un anumit factor (Traffic Scale), fără a modifica structura modelului și parametrii surselor și echipamentelor.

Iată de exemplu un fragment din raportul funcționării normale a rețelei, ilustrând utilizarea nodurilor:

Mai jos este ilustrat același fragment de raport în cazul multiplicării de 4 ori a traficului în rețea.

Se observă o creștere evidentă, accentuată, a utilizării nodurilor rețelei. Sunt utilizate și nodurile MUX21 și MUX 31 (multiplexoarele de ordin secundar ale legăturii de 34 Mb/s) care în cazul traficului normal aveau utilizare 0.

Trebuie menționat că aceste schimbări efectuate asupra sistemului nu au avut la bază concepții reale, însă au fost intuitive pentru evidențierea unor aspecte ce pot fi studiate cu COMNET III.

Datele conținute de rapoartele statistice, sunt date centralizate, fără referință de timp. Sunt contorizări efectuate pe toată durata simulării. Pentru reprezentarea în timp a anumitor parametri, trebuie activate monitorizările componentelor rețelei. Pentru mai multe exemple de monitorizări reprezentate în timp, v. Anexa 5 și pentru un raport statistic complet, v. Anexa 4.

Iată două exemple pentru evidențierea pe axa timpului a defectării unei legături. În Fig. 6.5. este reprezentată utilizarea canalelor pe Legătura 12 în cazul funcționării normale, iar în Fig. 6.6., evidențierea defectării temporare (20 min) a acesteia.

CAPITOLUL VII

OBSERVAȚII ȘI CONCLUZII

Modelarea rețelelor de comunicații prin simulare este în general

un subiect interdisciplinar foarte dificil. Necesită nu numai elemente de teoria simulării propriu-zisă, dar și cunoștințe considerabile de statistică precum și de teoria ce stă la baza rețelei respective. Performanțele se obțin după o îndelungată experiență și necesită aptitudini ce nu pot fi asimilate pasiv.

Lucrarea de față, își propune elaborarea unui studiu de modelare folosind instrumente software, cu alte cuvinte, modelarea prin simulare. Acest studiu respectă în mare parte etapele unui proces de modelare dar nu în totalitate, din lipsa unor date și parametri care ar fi trebuit obținute din măsurători în rețeaua existentă și din studii statistice efectuate în rețea o perioadă mai îndelungată de timp. Dat fiind că rețeaua modelată este una de instrucție (de învățământ) și nu una aflată în exploatare de mai mult timp, aceste studii lipsesc.

Cu alte cuvinte, esența acestei lucrări este ilustrarea folosirii unor instrumente software pentru studierea și înțelegerea caracteristicilor și performanțelor unei rețele de comunicații.

Cum rețelele de comunicații moderne sunt din ce în ce mai complexe, exploatarea, managementul și cu atât mai mult proiectarea lor, devine de asemenea o sarcină din ce în ce mai complexă, care nu mai poate fi realizată prin metode analitice, simple, pe hârtie. Din acest motiv, instrumentele folosite în studierea rețelelor trebuie să facă față complexității și flexibilității acestora. În consecință, abordarea inițială a lucrării, de a construi tocmai un astfel de instrument software, a fost oprită în faza de principii și structură de bază (v. Capitolul II). Ulterior conceperii temei lucrării, Academia Tehnică Militară a intrat în posesia unui program (COMNET III) dedicat tocmai acestor preocupări, superior oricărei încercări modeste în domeniu.

Esența lucrării, elaborată în cadrul catedrei de Transmsiuni, nu erau metodele de programare, limbajul de nivel înalt folosit și algoritmii aplicați în construirea unui instrument software pentru modelarea rețelelor de comunicații, ci folosirea acestuia pentru studierea caracteristicilor acestora. Astfel, folosirea programului COMNET III deschidea noi perspective și făcea posibilă desfășurarea studiului de modelare la un nivel mult mai înalt. La fel cum în orice domeniu tehnic, cel care realizează un proiect nu își construiește mai întâi instrumentele de măsură, ci folosește unele performante, realizate de cineva specializat, care să îi permită obținerea unor rezultate superioare, în cazul de față am considerat oportună folosirea acestui instrument software (COMNET III), mai ales că este ceva nou, iar posibilitățile sale abia încep să fie cunoscute. Pentru a compensa trecerea de la un instrument primar, cu care să modelez o rețea fictivă, mai puțin complexă, cu rezultate restrânse, am abordat o rețea reală, tot de mici dimensiuni, dar care reprezintă un interes real și de actualitate.

Cadrul unei lucrări de diplomă nu permite, cel puțin în acest domeniu, atât în ce privește cunoștințele acumulate, cât și volumul materialului redactat, un studiu aprofundat, cu rezultate concrete și directă aplicabilitate în practică.

Ceea ce am dorit în cadrul acestui proiect, a fost elaborarea unui studiu de modelare care să fie caracterizat de o notă crescută de realism, atât din punct de vedere al topologiei de rețea abordate, cât și într-o anumită măsură din punct de vedere al rezultatelor obținute.

Acest proiect, fiind prima încercare de acest gen, consider că poate fi continuat și aprofundat și de alți studenți, cu alte ocazii. De asemenea, poate fi folosit în scop didactic, în laboratoarele Catedrei de Transmisiuni pentru studiul echipamentelor STAR și în general al rețelelor de comunicații, în scopul încercării unor scenarii ale configurației sistemelor, care nu pot fi realizate din punct de vedere practic.

bibliografie: