|
Laborator ReţeIe de Telecomunicaţii - Lucrarea nr.1
Considerăm o arhitectură stratificată pentru reţeaua de telecomunicaţii, ceea ce permite o mai uşoară prezentare, concepţie, implementare şi întreţinere a componentelor reţelei. De asemenea, prin standardizarea funcţionalităţii fiecărui strat se pot realiza sisteme deschise care pot comunica indiferent de soluţiile de implementare alese de producători.
Într-o astfel de arhitectură sistemul este organizat în straturi funcţionale (nivele), ierarhizate, astfel încât fiecare strat interacţionează numai cu stratul superior şi cu cel inferior.
Fiecare strat îndeplineşte un anumit set de funcţii, pentru a oferi servicii stratului superior, folosind serviciile furnizate de stratul inferior.
Fiecare nivel al arhitecturii OSI interacţionează numai cu nivelele adiacente.
În sisteme mai complexe, în care există n > 1 plane arhitecturale, un nivel dintr-un plan poate interacţiona şi cu nivel omolog din alt plan.
Un nivel (N) îndeplineşte un set de funcţii precis definite, pentru a furniza (presta) nivelului (N+1) serviciul (N), folosind (şi completând) serviciul (N-1). În acest scop, entităţi (N) din sistemele implicate coopereazà, comunicând intre ele pe baza regulilor prevăzute de protocolul (N) si folosind pentru transferul informaţiei serviciul de comunicaţie oferit de nivelul (N-1).
Vom numi utilizator al serviciului (N) o entitate de nivel (N+1) si furnizor (prestator) al serviciului (N) o entitate de nivel (N).
-
Serviciu de retea
Funcţionalitatea oferită de un strat al arhitecturii stratificate a reţelei constă într-un ansamblu
de activităţi, numite servicii. Definitia in sens larga a se vedea Anexa A.
1.1 Primitive
Dialogul dintre două nivele adiacente, în vederea efectuării serviciilor, este definit prin secvenţe de interacţiuni, numite primitive. In total sunt definite 4 categorii de primitive:
-
Cerere (eng. request): primitivă prin care nivelul (N+1) solicită nivelului (N) efectuarea unui serviciu;
-
Indicaţie (eng. indication): primitivă prin care nivelul (N) semnalează nivelului (N+1) efectuarea unui serviciu (ex: livrarea unor date de la partenerul de comunicaţie).
-
Răspuns (eng. response): primitivă prin care nivelul (N+1) răspunde la o primitivă de tip indicaţie primită de la nivelul (N) (de exemplu, pentru a anunţa că acceptă o cerere de comunicaţie indicată anterior de nivelul (N)).
-
Confirmare(eng. confirm): primitivă prin care nivelul (N) confirmă efectuarea serviciului so!icitat de nivelul (N+1) printr-o primitivă cerere.
Figure 1: Interacţiuni între nivele: Cele 4 tipuri de primitive utilizabile în cursul realizării unui serviciu si relaţiile de cauzalitate dintre ele
Notaţii: N-PS = Denumirea normalizată a primitivei: Nivel-Primitivă Serviciu.
Clasificarea serviciilor
-
Relativ la modelul de comunicaţie:
Comunicaţia cu conexiune este caracterizată prin desfăşurarea succesivă a trei
faze:
-
Stabilirea conexiunii: înregistrarea comunicaţiei în entităţile implicate, negocierea calităţii şi alocarea resurselor, iniţializarea informaţiei de stare.
-
Transferul unităţilor de date ale utilizatorilor pe conexiune.
-
Eliberarea (închiderea) conexiunii: semnalizarea incheierii comunicaţiei, disponibilizarea resurselor alocate. Exista doua metode: eliberare abrupta, eliberare gradata
Acest model este utilizat atunci când realizarea comunicaţiei implică o pregătire prealabilă a entităţilor participante, în vederea alocării resurselor necesare şi a iniţializării informaţiei de stare asociate comunicaţiei. Informaţia de stare permite entităţilor participante să urmărească evoluţia comunicaţiei si să se coordoneze.Exemplu tipic: transferul fiabil al unui flux de unităţi de date, cu garantarea reconstituirii fluxului transmis la recepţie.
Comunicaţia fără conexiune nu necesită o pregătire prealabilă a entităţilor participante. Exemplu tipic: transferul de datagrame - unităţi de date izolate, fără corelare între ele.
Variante de proiectare: datagrame cu/fără confirmare (transfer unidirecţional al unei unităţi de date), tranzacţii (dialog cerere-răspuns, transfer bidirecţional, câte o unitate de date pe fiecare sens).
Comunicaţia punct-la-punct: doi participanţi;
Comunicaţia multipunct: N>2 participanţi, în diverse topologii ale fluxurilor de date.
Figure 2: Diagramele secventelor de primitive pentru serviciul generic cu conexiune
Notatii: U-S = utilizator al serviciului,
P-S = furnizorul serviciului.
Serviciul analizat, in figura de mai sus, foIoseşte în fazele de stabilire/eliberare a conexiunii şi transfer de date, următoarele primitive:
-
la stabilirea conexiunii:
- ConReq, cerere de la utilizator de stabilire a unei conexiuni.
- ConInd, indicaţie spre utilizator prin care se semnalează o cerere de stabilire a
comunicaţiei.
- ConRsp, răspunsul utilizatorului apelat la indicaţia primită anterior.
- ConCnf, confirmarea servicilui solicitat de către utilizator.
- DatReq, cerere de transfer de date de la utilizator.
- DatInd, indicaţie prin care se semnalează livrarea unor date utilizatorului, de la partenerul de comunicaţie.
- DisReq, cerere de la utilizator de desfiinţare a conecxiunii.
- DisInd, semnalează utilizatorului desfiiţarea conexiunii solicitată.
Exercitiu:
Dati exemple de servicii pentru stabilirea conexiunii cu dialog cu 2 si cu trei primitive la interfata dintre doua nivele adiacente.
2. Protocoale de comunicatie
2.1 Vocabularul
Unitatea atomica de informatie cu care un protocol functioneaza se numeste unitate de date de protocol notata PDU. Multimea tuturor unitatilor de date PDU, definite de un protocol, formeaza vocabularul acelui protocol.
Unitatea de date de protocol este structurata in mai multe campuri cu semnificatie bine precizata. (semnificatia campurilor poate fi: delimitator, adresa, lungime, date utilizator, cod detectie/control eroare).
Delimitarea unitatilor de date
Pentru protocoalele cu lungime variabila a PDU-urilor este necesara identificarea acestora. Se folosesc:
-
incadrarea fiecarui PDU intre doua flaguri
-
utilizarea unui flag de start si a unui indicator de lungime.
-
prin sincronizare pe informatia de control erori si lungime fixa a unitatilor de date
-
inserarea sistematica de flaguri de sincronizare intre cadrele de informatie
2.2 Codarea
Exista doua metode de reprezentare a unitatilor de date PDU:
-
text : la nivel octet cu caractere (ex. ASCII)
-
binar : la nivel bit
De regula campurile PDU se aliniaza la un multiplu de octet.
Atunci cand trebuie transmisa informatia reprezentata binar printr-un protocol ce utilizeaza o reprezentare text se utilizeaza o codare BASE64. (ex. transferul unui fisier wave prin serviciul de posta electronica sau tunelarea protocolului IP prin protocolul HTTP).
BASE64: codeaza 3 caractere in 4 secvente de 6 biti. Daca textul nu este multiplu de 3 se completeaza mesajul cu simboluri 0x00h. Are la baza o tabela de translatie BASE64.
Tabela de conversie BASE64. Alfabetul BASE64.
Valoare
|
Caracter
|
Valoare
|
Caracter
|
Valoare
|
Caracter
|
Valoare
|
Caracter
|
0
|
A
|
17
|
R
|
34
|
i
|
51
|
z
|
1
|
B
|
18
|
S
|
35
|
j
|
52
|
0
|
2
|
C
|
19
|
T
|
36
|
k
|
53
|
1
|
3
|
D
|
20
|
U
|
37
|
l
|
54
|
2
|
4
|
E
|
21
|
V
|
38
|
m
|
55
|
3
|
5
|
F
|
22
|
W
|
39
|
n
|
56
|
4
|
6
|
G
|
23
|
X
|
40
|
o
|
57
|
5
|
7
|
H
|
24
|
Y
|
41
|
p
|
58
|
6
|
8
|
I
|
25
|
Z
|
42
|
q
|
59
|
7
|
9
|
J
|
26
|
a
|
43
|
r
|
60
|
8
|
10
|
K
|
27
|
b
|
44
|
s
|
61
|
9
|
11
|
L
|
28
|
c
|
45
|
t
|
62
|
+
|
12
|
M
|
29
|
d
|
46
|
u
|
63
|
/
|
13
|
N
|
30
|
e
|
47
|
v
|
(pad)
|
=
|
14
|
O
|
31
|
f
|
48
|
w
|
|
|
15
|
P
|
32
|
g
|
49
|
x
|
|
|
16
|
Q
|
33
|
h
|
50
|
y
|
|
|
Exercitiu:
Text
|
Casa
|
Cod ASCII
|
|
Binar
|
|
BASE64
|
?
|
2.3 Managementul comunicatiei
2.3.1 Identificarea tranzactiilor
In cazul comunicatiilor de tip tranzactional exista posibilitatea unor confuzii in
identificarea corecta a mesajelor cerere/raspuns. Pentru a evita alterarea functionarii sistemului datorata acestor confuzii, este necesara identificarea comunicatiilor, care se defineste in faza de stabilire a conexiunii.
In Figura 3 se exemplifica cazul in care procedura de comunicatie cu confirmare
protejata prin temporizator si recuperare prin retransmitere poate conduce la livrarea unor duplicate ale mesajelor. Temporizatorul expira datorita pierderii raspunsului MR sau a evaluarii incorecte a duratei. In cele din urma operatia solicitata de client a fost efectuata de server. Se disting 2 cazuri:
-
Primirea de catre server a unui duplicat al cererii determina repetarea efectuarii operatiei fig 3.a;
-
P
rimirea de catre client a unui duplicat al raspunsului, poate perturba comunicatia urmatoare, initiata dupa primirea primei copii, prin confundarea duplicatului cu raspunsul la noua cerere. Fig 3.b
Figure 3: a) pierderea raspunsului, b) pierderea cererii
Notatii: MC = mesaj cerere,
MR = mesaj raspuns
Pentru a permite detectare duplicatelor, protocolul trebuie sa includa un mecanism de identificare care sa asigure distingerea mesajelor MC intre ele si asocierea univoca a fiecarui mesaj MR cu mesajul MC al carui raspuns este.
O solutie este un mecanis, bazat pe numerotare ce trebuie initializat inaintea inceperii comunicatiilor. Tot atunci se aloca resursele necesare, sunt create si initializate automatele care controleaza transferul, conform procedurilor prevazute de protocol.
2.3.2 Identificarea conexiunii
Se poate realiza prin adrese, un utilizator fiind asociat unui punct de acces la serviciu (SAP) care este identificat in mod univoc printr-o adresa. Se poate identifica o conexiune intre un utilizator local si alt utilizator prin perechea de adrese ale punctelor de acces. Daca pentru doua puncte de acces se poate stabili mai multe conexiuni simultan, ele pot fi distinse printr-un identificator capat de conexiune, local, ales convenabil.
In cadrul procedurii de stabilire, fiecare dintre entitatile implicate aloca noii conexiuni cate un identificator convenabil, in mod independent. Valoarea alocata trebuie sa permita identificarea neambigua a conexiunii in cadrul subsistemului respectiv. Entitatile se informeaza reciproc asupra identificatorului alocat, in cadrul dialogului de stabilire a conexiunii. Fiecare pachet transmis ulterior de o entitate poarta identificatorul de conexiune ales de cealalta.
Ansamblul resurselor de identificare, stocare si prelucrare a informatiei angajate de procesele participante pentru realizarea comunicatiei se numeste asociere sau conexiune.
Vom studia in continuare de procedurile care permit realizarea, intretinerea si terminarea unei conexiuni, care se mai numesc proceduri de control (management) al conexiunilor.
2.3.3 Proceduri pentru controlul conexiunii aceaste proceduri sunt specifice protocoalelor orientate pe conexiune (en. COP). Pentru comunicatiile cu conexiune indeplinirea cerintelor de calitate solicitate de aplicatie si utilizarea eficienta a resurselor implica realizarea unei intelegeri prealabile intre procesele care comunica.
2.3.3.1 Stabilirea (deschiderea) conexiunii este faza prealabila comunicatiei propriu-zise, in care:
-
Se verifica posibilitatea de a efectua comunicatia, sunt precizate si negociate cerintele de calitate dorite de utilizatori, sunt precizati parametrii de configurare pentru procedurile protocolului.
-
Este inregistrata comunicatia de catre functia de identificare, sunt alocate resursele necesare, sunt create si initializate automatele care vor asigura controlul transferului.
-
Sunt informati utilizatorii serviciului asupra succesului sau esecului stabilirii conexiunii si a valorilor negociate ale parametrilor de calitate.
Protocolul include o procedura de stabilire a conexiunii bazata pe comunicatii cu confirmare protejate cu temporizator, retransmitere automata la expirarea temporizatorului si limitare a numarului de retransmisii.
O procedura intr-un singur pas (eng. one way handshake): este cea mai rapida procedura de stabilire a conexiunii:
`
Figure 4: Diagramele MSC si EFSM ptr. procedura “one-way”
Problema: nu este utilizata in practica datorita vulnerabilitatii in cazul functionarii peste medii de comunicatie cu pierderi. (cazul mediilor reale). In acest caz pierderea cererii de stabilire a conexiunii poate avea ca efect blocarea protocolului in starea CONNECTED.(eng. deadlock)
Figure 5: Diagrama MSC pentru problema procedurii “one-way”
Intrebare:
Daca se utilizeaza acelasi serviciu cu 3 primitive la interfata dintre nivele, va conduce aceasta la rezolvarea problemei ?
O procedura in doi pasi (eng. two way handshake):
P
entru a obtine o procedura fiabila care sa inlature problemele de natura celor din procedura de mai sus a fost introdus principiul utilizarii unui mecanism cu temporizator T si mesaj de confirmare ACK. Aceasta procedura se spune ca este “cu confirmare simpla”.
Figure 6: Diagrama MSC ptr mai multe scenarii ale procedurii "two-way"
În cazul pierderii unui pachet CR, sau a confirmării acestuia CC, la expirarea temporizatorului se retransmite pachetul CR. Se încearcă retransmisia de un număr limitat de ori după care transmiţătorul abandonează.
Un numar de tranzitii trebuiesc adaugate ptr a trata noile evenimente luind in considerare si asincronismul caracterului cu care se produc.
Figure 7: Diagrama EFSM ptr. procedura "two-way"
Este posibila blocarea automatului EFSM care descrie comportamentul protocolului intr-o bucla (eng. livelock) !
Exercitiu
Dati un exemplu de comportament in care sistemul descris de automatul de mai sus este blocat in bucla ?
In continuare se va analiza tranzitia din stare WAIT_ACK in starea CONNECTED, marcata pe diagrama din Figura 7. U n posibil scenariu in care cele doua entitati initiaza simultan procedura de stabilire a conexiunii, din ambele capete a stat la baza introducerii acestei tranzitii.
Figure 8: Diagrama MSC ptr. solicitarea simultana a procedurii de stabilire a conexiunii
Automatul EFSM completat cu aceasta tranzitie in vederea tratarii evenimentului de receptionare a CR in starea WAIT_ACK pune noi probleme: ne putem imagina astfel un scenariu in care o cerere de stabilire (falsa sau din alta sesiune) poate determina deschideri false de conexiuni.
O procedura in trei pasi (eng. three way handshake):
Pentru a rezolva problema de mai sus se utilizeaza un mecanism cu dubla confirmare. Aceasta varianta se mai numeste si “procedura cu confirmare dubla” pentru stabilirea conexiunii (ex. TCP).
Procedura consta intr-un dialog cu trei pachete: doua pachete de control dedicate si un pachet suplimentar notat AK, prin care initiatorul confirma primirea pachetului CC. In urma acestui dialog se realizeaza inregistrarea si initializarea la ambele capete.
Pachetul AK indica entitatii apelate ca stabilirea este finalizata si la capatul initiator, in particular faptul ca pachetul CR era valid. Entitatea apelata considera stabilirea incheiata doar daca primeste AK. Dialogul CC-AK este protejat la randul sau cu temporizator si numar limitat de retransmisii.
Introducerea celei de-a doua confirmari evita deschiderea unei false conexiuni de catre un pachet CR intarziat excesiv de suportul de comunicatie.
Procedurile pot include asteptarea raspunsului utilizatorului apelat, care precizeaza acceptarea conexiunii si calitatea oferita (negociere a calitatii) sau respingerea conexiunii. Dialogul este protejat prin temporizator si retransmisie de un numar limitat de ori a pachetului CR, pentru tratarea situatiilor in care se pierd pachete sau capatul apelat nu este in functiune.
F
igure 9: Exemplu de procedura de stabilire a conexiunii cu confirmare dubla, acceptare explicita a utilizatorului apelat si negocierea calitatii (nivelul transport)
Notatile utilizate:
CR – pachet “cerere de stabilire a conexiunii”;
CC – pachet “confirmare a stabilirii conexiunii:;
id(1)/id(2) – identificatorul de conexiune alocat de entitatea initiatoare/apelata;
config(1)/config(2) – parametrii de configurare si initializare a comunicatiei
indicati de entitatea initiatoare/apelata;
calitate(1)/calitate(2) – specificatia calitatii serviciului, propusa de utilizatorul initiator, respectiv oferita de utilizatorul apelat (deci rezultatul negocierii)
Si diagrama FSM s-a completat ca in figura de mai jos:
Figure 10: Diagrama EFSM ptr procedura "three-way"
2.3.4 Proceduri de supervizare a conexiunii
Procedurile utilizate pentru transferul unui flux de date realizeaza in mod implicit o supraveghere a functionarii conexiunii prin mecanismele bazate pe temporizator, retransmisie si abandon al conexiunii la expirarea unui contor de retransmisii. Aceste mecanisme nu opereaza insa in pauzele de transmisiei de date. In paralel cu aceste mecanisme este necesara adaugarea unor mecanisme care sa permita unei entitati sa distinga intotdeauna situatiile in care conexiunea nu mai functioneaza, de cele in care nu se mai transfera date pe fluxul de intrare.
Exista doua categorii de solutii:
-
Dialog de test la expirarea unui temporizator care limiteaza durata de asteptare a receptiei unui pachet.
-
Intretinerea activitatii prin transmiterea nesolicitata a unor pachete de control.
In specificatiile analizate la laborator se va folosi prima solutie.
2.3.5 Proceduri pentru eliberarea conexiunii
Eliberarea (inchiderea) conexiunii incheie comunicatia si elibereaza resursele:
-
se asigura finalizarea transferului in conditiile de calitate solicitate (cu exceptia defectarilor nerecuperabile);
-
este inregistrata terminarea conexiunii in componentele ce asigura identificarea, sunt eliberate resursele alocate, sunt eliminate componentele (automatele) care au asigurat controlul transferului;
-
sunt informati utilizatorii serviciului ca s-a incheiat comunicatia si care este motivul terminarii sau starea finala a transferului.
Daca stabilirea conexiunii este dificila eliberarea este din punct de vedere teoretic imposibila. A se vedea problema cunoscuta cu numele: “tragedia generalilor” sau “problema celor doua armate”.
Practic sunt utilizate urmatoarele proceduri:
Procedura de “eliberare abrupta” a conexiunii (Figura 11)
Procedura de eliberare abrupta realizeaza inchiderea simultana a ambelor fluxuri de date, fara garantii privind finalizarea transferului datelor. Se utilizeaza o comunicatie cu confirmare folosind pachete de control dedicate, prin care entitatea initiatoare urmareste sa se asigure ca entitatea corespondenta este informata asupra terminarii conexiunii.
Dialogul este protejat prin temporizator si un numar limitat de retransmisii ale pachetului DR.
Eliberarea abrupta se utilizeaza atunci cand responsabilitatea finalizarii transferului ramane in sarcina utilizatorului sau acesta abandoneaza conexiunea. Unitatile de date inca netransmise in momentul primirii primitivei DISCONNECT.req sunt fie elimiate, fie transmise inaintea pachetului DR, dar nu se mai fac retransmisii si toate unitatile de date receptionate sunt ignorate.
F
igure 11: Exemplu de procedura pentru eliberarea abrupta a conexiunii
Notatii utilizate:
DR – pachet “cerere de eliberare a conexiunii”;
DC – pachet “confirmare a eliberarii conexiunii”;
id(1)/id(2) – identificatorul de conexiune alocat de entitatea initiatoare/apelata;
Procedura de “eliberare gradata” (eng. graceful) a conexiunii (Figura 12)
Aceasta procedura are ca obiectiv finalizarea transferului pe ambele fluxuri de date inaintea eliberarii conexiunii. In acest scop, se inchide separat fiecare flux de date (sens de comunicatie), folosind o comunicatie cu confirmare, cu pachete de control dedicate. Entitatea initiatoare urmareste sa se asigure ca entitatea corespondenta a primit toate unitatile de date si este informata asupra incheierii transferului.
Dialogul este protejat prin temporizator si un numar limitat de retransmisii ale pachetului GR.
In cazul eliberarii gradate, responsabilitatea finalizarii transferului revine furnizorului de serviciu. Folosind pachete GR(NS=VS), dialogul pentru inchidere poate fi initiat de indata ce se incheie transmisia.
Figure 12: Exemplu de procedura pentru inchiderea gradata (graceful) a conexiunii
Notatii utilizate:
GR – pachet “cerere de eliberare”;
GC – pachet “confirmare a eliberarii conexiunii”;
id(1)/id(2) – identificatorul de conexiune alocat de entitatea initiatoare/apelata.
2.3.6 Proceduri pentru controlul transferului unui flux de date
2.3.6.1 Controlul erorilor
Procedura cu “Oprire si Asteptare1”
Aceasta este cea mai simpla procedura prezentata pentru transferul datelor care asigură reconstituirea secvenţei de unităţi de date la recepţie, în condiţiile în care se pot pierde pachete. Este procedura cu oprire şi aşteptare cu numerotare modulo N (ex. N = 2) a unităţilor de date.
Transmiţătorul întrerupe transmisia după fiecare pachet de date transmis şi aşteaptă primirea confirmării. Este suficient, la transmitator, un buffer pentru un singur segment de date. Receptorul poate livra utilizatorului doar pachete de date numerotate în secvenţă continuă.
Figure 13: Prezintă transferul unei unităţi de date, ca parametru al interacţiunilor DatReq(sdu) şi DatInd(sdu)
În Figurile 13 si 14 sunt reprezentate mesajele transferate între entităţile de nivel: N+1 (utilizatorul serviciului), N (protocolul COP care oferă serviciul) şi N-1 (suportul de comunicaţie), în cele trei faze ale comunicaţiei pe conexiune.
Notaţiile: U1 şi U2 pentru utilizatorii serviciului N, P1 şi P2 sunt entităţile de protocol N, iar M este suportul (mediul) de comunicaţie.
In Figura 13 este prezentat transferul unei unitati de date, ca parametru al interactiunilor DatReq(sdu) si DatInd(sdu). Pachetele de date transferate intre entitati de nivel N (protocol) se numesc DT si sunt numerotate in secventa.
Figure 14: Exemplul pentru transferul unei secvenţe de unităţi de date
In Figura 14 este exemplificat transferul unei secvente de unitati de date cu numerotare modulo 2 (metoda bitului alternant) pentru unitatile de date.
Transmiţătorul foloseşte un contor VS, care memorează limita secvenţei transmise, prin numărul următorului segment de date de transmis. Acesta este incrementat modulo-2 după transmiterea fiecărui segment.
În receptor, contorul VR memorează limita secvenţei continuu receptionate, prin numărul următorului segment de date asteptat. VR avansează modulo-2 pe măsura recepţiei datelor în secvenţă.
Pentru transferul numerelor de secvenţă, pachetele de date şi de confirmare conţin următoarele câmpuri de control:
NS = înscris cu valoarea curentă a contorului VS, respectiv
NR = înscris cu valoarea curentă a contorului VR.
Receptorul foloseşte câmpul NS pentru identificarea poziţiei segmentului în fluxul de date.
Transmiţătorul interpretează câmpul NR ca o confirmare a transferului corect al segmentelor precedente şi memorează valoarea sa într-o variabilă pe care o vom nota VA.
AK confirmă datele primite în secvenţă iar câmpul NR confirmă pachetul cu număr de secvenţă mai mic decât NR.
Deoarece suportul de comunicaţie (serviciul N-1) nu garantează transferul tuturor pachetelor, trebuie folosite proceduri care să asigure recuperarea în cazul în care se pierd pachete; in acest scop se vor considera mecanisme cu confirmare (DT/ACK), protejate cu temporizator şi retransmisie la expirarea temporizatorului. Pentru cazul unei defecţiuni persistente, numărul de retransmisii este limitat iar la expirarea unui contor se declanseaza procedura de eliberare a conexiunii.
Anexa A – Structurarea pe nivele conform modelului OSI
OSI-RM (OSI Reference Model) este modelul arhitectural de referinţă pentru sisteme de interconectare deschise, elaborat de organizaţia internaţională pentru standardizare, ISO. + figura
-
Subsistem (N) = componentă a structurii ierarhizate a sistemului care nu interacţionează decât cu componenta imediat superioară si cea imediat inferioară din ierarhie.
-
Nivel (strat) (N) = subdiviziune a arhitecturii reţelei care reuneşte toate subsistemele de rang (N) din sistemele înglobate in reţea.
-
Serviciu (N) = funcţionalitatea oferită nivelului (N+l) de către nivelul (N), la interfaţa dintre ele. Serviciul constă într-un ansamblu de activităţi pe care le poate efectua nivelul (N), La solicitarea nivelului (N+1), pe baza unor reguli precis definite de dialog.
-
Interacţiunile dintre nivele asociate solicitării şi prestării unui serviciu se numesc primitive ale serviciului
-
Punct de acces la serviciul (N) (SAP(N)) = interfatà între nivelul (N) şi nivelul (N+l), prin care acesta din urmă obţine serviciul (N) (sau componente ale serviciului). Engleză: SAP = Service Access Point.Un SAP(N) este identificat în mod univoc în cadrul nivelului (N) printr-o adresă (N).
-
Entitate (N) = un element activ al unui subsistem (N). În general, un subsistem (N) are la rândul său o anumită structură, corespunzătoare unei subdivizări interne a funcţiilor pe care trebuie să le îndeplinească.
-
Protocol (N) = Vocabularul şi regulile pe bază cărora comunică entităţile (N) din sisteme diferite, în cadrul cooperării dintre ele, în scopul de a îndeplini funcţiile nivelului (N) şi de a furniza nivelului (N+1) serviciul (N).
-
Conexiune (N) = asociere logică stabilită de un nivel (N) între două sau mai multe entităţi (N) pentru transferul informaţiei între entităţi. O conexiune (N) este realizată in vederea comunicaţiei între entităţi (N+1), La solicitarea acestora (componenta a serviciului (N)).
Figure 15: Modelul de referinta OSI
Anexa B – Proiectarea si realizarea unui protocol de comunicatie cu FDT Un entitate de protocol de comunicatie realizeaza un set de functii, necesar pentru pentru completarea serviciului oferit de nivelul inferior, in vederea indeplinirii serviciului solicitat de nivelul superior. In cadrul procesului de proiectare si realizare a unui protocol intervin urmatoarele componente (fig 1.1). -
Descrierea neformala a protocolului prezinta structura pachetelor (sintaxa) si procedurile folosite de protocol in vederea indeplinirii functiilor, folosind text, tabele diagrame , etc.
-
Descrierea formala a protocolului reprezinta definitia exacta, neambigua si abstracta a sintaxei si procedurilor protocolului, bazata pe o tehnica de descriere formala. Datorita caracterului abstract, descrierea permite diferite variante de realizare .
-
Implementarea protocolului este o solutie concreta, particulara, de realizare a protocolului, care poate fi integrata intr-un sistem de comunicatie (un produs software si/sau hardware).
Figure 16: Proiectarea si realizarea unui protocol de comunicatie
Activitatea de validare consta in verificarea corectitudinii definitiei protocolului, in esenta prin verificarea indeplinirii serviciului.
Definitia protocolului se obtine printr-un proces iterativ.Erorile detectate in faza de validare conduc la revizuiri ale conceptiei protocolului si ale descrierii formale.
Testele de conformitate compara comportarea unei implementari particulare cu comportarea unei implementari de referinta(de exemplu, obtinuta prin traducerea directa a descrierii formale untr-un limbaj de programare).In acest fel, se poate atesta faptul ca o implementare corespunde specificatiei si ca poate interopera cu implementarii ale altor furnizori.
Implementarea este rezultatul unui al doilea proces iterativ; deficientele evidentiate de testele de conformitate implica reanalizarea definitiei si revizuirea corespunzatoare a solutiilor de implementare.
Protocoalele de comunicatie sunt sisteme distribuite concurente, in care un numar mare de procese interactioneaza intr-o maniera complexa.Validarea si testarea se pot realiza doar automat (si partial), pe baza unor metode formale executabile de catre calculatoare. Utilizarea unor descrieri formale este esentiala pentru activitatile de validare, implementare si testare a conformitatii.
Pentru a sustine procesul se standardizare OSI, ISO a initiat in 1979 studiul unor metode formalepentru descrierea protocoalelor. In scurt timp, s-au conturat doua orintari distincte cu privire la modelul utilizabil si, in final, s-au standardizat doua tehnici de descriere formala. Estelle (Extended State Transition Model ISO IS 9074, 1989) extinde modelul clasic de sistem cu tranzitii de stare. Lotos (ISO IS 8807, 1989) se bazeaza pe algebrele proceselor elaborate de Milner si Hoare.In paralel, UIT(ex-CCITT) a dezvoltat limbajul SDL (CCITT Z100, 1988), folosind tot sisteme cu tranziti de stare.
Obiectivele urmarite in conceperea FDT sunt sintetizate in lista urmatoare de calitati:
-
Expresivitate: abilitatea de a permite descrierea sintaxei si procedurilor serviciilor si protocoalelor.
-
Formalizare: fundamentarea descrierii pe un model matematic complet, care sa permita interpretarea neambigua a definitiei protocolului in vederea implementarii si dezvoltarea unor metode formale pentru validarea specificatiei si pentru testarea conformitatii implementarilor cu specificatia formala.
-
Structurare: capacitatea de structura descrierea pentru a modela arhitectura sistemelor.
-
Abstractizare: limitarea nivelului de detaliere, pentru a elimina detalii irelevante si a evita introducerea unor constrangeri asupra solutiilor de implementare.
Anexa C – Lansarea unei sesiuni de lucru cu sistemul XEDT
Mediul de dezvoltare EDT a fost dezvoltat pentru a rula sub sistemul de operare Linux in consecinta un minim de cunostinte despre acest sistem de operare este recomandat, totusi secventa de actiuni prezentata mai jos ar trebui sa fie suficienta pentru a efectua fara probleme toate activitatile cerute in cadrul laboratorului.
Sa incepem cu lansarea sistemului de operare. Se va porni/restarta sistemul de calcul PC, pentru ca imediat dupa efectuarea testului POST sa se tasteze :
Se mentine tasta apasata pana la aparitia promptului LILO:
boot:
In caz ca se observa ca PC-ul porneste (implicit) incarcarea sistemului Windows, se restarteaza prin apasarea butonului reset (aflat pe carcasa) si se incearca din nou.
Se cere o lista a sistemelor de operare instalate pe PC prin apasarea tastei:
Se tasteaza numele corespunzator sistemului Linux. Urmeaza incarcarea sistemului care se va incheia cu invitatia de a porni o sesiune de lucru autorizata in contul dedicat acestui laborator, in acest sens se va introduce numele contului la aparitia promptului:
login:
urmata de introducerea parolei care semnifica numarul salii. De exemplu:
a314
Se va lansa interfata grafica X-Window (daca acest lucru nu s-a efectuat automat) cu comanda:
>startx
Se lanseaza o fereastra terminal cu: Start→Terminal; si se executa comanda:
>xhost +manole
... urmata de de deschiderea unei sesiuni la distanta SSH pe calculatorul monster, astfel:
>ssh labaprt@monster
Unde x = numarul de ordine al PC-ului in sala de laborator. Se introduce parola:
sdtedt.
Se raspunde afirmativ
Y
la invitatia interpretorului de comenzi de a seta variabila DISPLAY. Dupa care la prompterul
DISPLAY=
Se precizeaza identificatorul terminalului virtual ce consta din numele sistemului PC
de la care se lucreaza astfel:
pcxx:0.0
unde xx=identificatorul hostului-100 (comanda /sbin/ifconfig, ultimul octet din adresa IP)
In continuare se schimba directorul de lucru curent, corespunzator laboratorului care se studiaza (cu numele sugestiv), de exemplu daca presupunem ca acesta este primul laborator atunci
Vom tasta comanda:
>cd aprt/l1
Se lanseaza fereastra grafica a mediului de dezvoltare XEDT cu comanda:
>xedt
Pregatirea in vederea simularii incepe prin deschiderea unei sesiuni de simulare:
→Tools → Simulator
Precizam fisierul care contine specificatia:
Simulator → FILE → mumefisier.stl → OK
In cazul in care specificatia apeleaza functii de biblioteca (acest lucru este indicat de prezenta in director a fisierului prim.c) se include fisierul care trebuie sa fie in format .obj (daca nu exista se va genera prin compilare cu comanda: gcc –c prim.c)
Options → OPTIONS → -L Object → numefisier.obj → OK
Se inchide fereastra Options.
→OK
In acest punct se pregateste (compilare si link-are) specificatia pentru simulare cu:
Simulator → RUN
Se deschide fereastra de simulare Simulator. Elementele ferestrei cu care se va lucra frecvent sunt:
-
Consola simulatorului
-
Linia de comanda a simulatorului
-
Ferestra de administrare macrouri2
-
Fereastra de administrare observatori3
-
Fereastra administrare MSC
De-alungul unei sesiuni de simulare in mod uzual se vor executa urmatoarele actiuni in fereastra Simulator:
- incarcare observatori
→ Edit Observer → nume observator → Set
- activare sau dezactivare observatori, cu:
→ Edit Observer → Enable respectiv Edit Observer → Disable
-
incarcare macro-uri sau editare, lucru care se va face cu:
→ Macro → Set respectiv Macro → Edit
-
trasarea automata a interactiunilor
→ MSC → New MSC → Overwrite it → Run
Important: deschiderea ferestrei pentru trasare automata trebuie sa preceada faza de simulare
-
restartarea simulatorului (intre simularile a doua scenarii4)
→ Restart
Anexa D – Conventii si notatii
Pentru studiul problemelor de dialog la interfata de serviciu vom utiliza diagrame MSC (eng Message Sequences Chart) dupa urmatorul model:
Figure 17: Diagrama MSC ptr studiul dialogului la interfata de serviciu
Pentru studiul problemelor de operare ale protocoalelor de comunicatie vom utiliza diagrame MSC dupa urmatorul model:
Figure 18: Diagrama MSC ptr studiul procedurilor de comunicatie ale protocoalelor
Dostları ilə paylaş: | 
