Protocol generic pentru comunicatii orientate pe conexiune

Protocol generic pentru comunicatii orientate pe conexiune

1. Introducere

În aceasta lucrare este prezentat un exemplu de protocol care ofera serviciile pentru comunicatii cu conexiune analizate în lucrarea nr.1

Am numit acest protocol “COP”= protocol orientat pe conexiune (“Connection Oriented Protocol”).

2.      Descrierea protocolului

Descrierea neformala a protocolului este prezentata cu diagrame de mesaje si grafuri tranzitiilor de stari.

Primitivele de serviciu transferate intre utilizatorul serviciului si protocol sunt:

pentru serviciul de stabilire a conexiunii:

CONNECT.request, cerere de stabilire de conexiune,

CONNECT.indication, indicare a unei cereri de stabilire a conexiunii,

CONNECT.response, raspuns la o cerere de stabilire a unei conexiuni,

CONNECT.confirm, confirmarea stabilirii conexiunii.

În specificatie folosim notatiile prescurtate ConReq, ConInd, ConRsp si ConCnf.

pentru transferul de date:

DATA.request (sdu) este cerere de transfer al unei unitati de date de serviciu,

DATA.indication (sdu) livreaza unitatea de date (sdu) la utilizator.

Notatiile folosite în specificatie sunt DatReq(sdu) si DatInd(sdu).

la eliberarea conexiunii:

DISCONNECT.request, cerere de deconectare,

DISCONNECT.indication, indicatia unei cereri de deconectare.

Notatiile folosite în specificatie sunt DisReq si DisInd.

Formatele de pachete transferate între entitatile protocol “cop” sunt:

CR - cerere de stabilire a unei conexiuni,

CC – confirmare a stabilirii conexiunii,

DR – cerere de eliberare a conexiunii,

DC – confirmare a eliberarii conexiunii,

DT(ns,dt) = unitate de date de protocol (pdu) care contine date cu numarul de secventa ns.

AK(nr) = pdu de confirmare, valoarea nr. indica numarul urmatoarei unitati de date asteptate la receptie si confirma primirea unitatilor de date precedente.

Protocolul ofera serviciul pentru comunicatii cu conexiune folosind un serviciu de nivel inferior fara conexiune si fara confirmare. Aceasta constituie suportul sau mediul de comunicatie. Mesajele se pot pierde în mediul si aceasta se datoreaza fie alterarii continutului lor fie depasirii capacitatii cozilor de mesaje care intervin pe traseul de transport al mesajelor.

Primitivele transferate între protocol si suportul de comunicatie sunt:

P_DATA.request(pdu) si

P_DATA.indication(pdu).

Notatiile prescurtate din specificatie sunt: P_DatReq(pdu) si P_DatInd(pdu), iar unitatea de date de protocol transferata pdu, poate fi unul dintre pachetele: CR/CC, DR/DC sau DT/AK.

În fig. 2.1, 2.2 si 2.3 sunt reprezentate mesajele transferate între entitatile de nivele: N+1 (utilizatorul serviciului), N (protocolul ”cop” care ofera serviciul) si N-1 (suportul de comunicatie), în cele trei faze ale comunicatiei pe conexiune. Notatiile sunt:U1 si U2 pentru utilizatorii serviciului N, P1 si P2 sunt entitatile de protocol N, iar M este suportul (mediul) de comunicatie. Deoarece suportul de comunicatie (serviciul N-1) nu garanteaza transferul pachetelor, la stabilire/eliberare trebuie folosite proceduri care sa asigure recuperarea în cazul în care se pierd pachete, si anume proceduri cu confirmare (CR/CC, DR/DC), protejate cu temporizator si retransmisie la expirarea temporizatorului.          Pentru cazul unei defectiuni persistente, numarul de retransmisii este limitat iar la expirarea unui contor stabilirea/eliberarea se abandoneaza.

Fig.2.2.Stabilirea conexiunii

În cazul pierderii unui pachet CR, sau a confirmarii acestuia CC, la expirarea temporizatorului se retransmite pachetul CR. Se încearca retransmisia de un numar limitat de ori dupa care transmitatorul abandoneaza.

Fig.2.2. Eliberarea conexiunii pentru cazul în care se pierde în mediu pachetul DR si este retransmis la expirarea temporizarii

Pentru transferul de date se foloseste o procedura simpla care asigura reconstituirea secventei de unitati de date la receptie, în conditiile în care se pot pierde pachete. Este procedura cu oprire si asteptare si numerotare modulo 2 a  unitatilor de date.

Transmitatorul întrerupe transmisia dupa fiecare pachet de date transmis si asteapta primirea confirmarii. Este suficient un buffer pentru un singur segment de date. Receptorul poate livra utilizatorului doar pachete de date numerotate în secventa continua.

Fig.2.3.a.Prezinta transferul unei unitati de date, ca parametru al interactiunilor DatReq(sdu) si DatInd(sdu). Pachetele de date transferate între entitatile protocol se numesc DT si sunt numerotate.

Fig.2.3.b. Exemplul pentru transferul unei secvente de unitati de date.

În figura 2.4 este descrisa comportarea protocolului cu ajutorul grafului de stari:

Sunt reprezentate doar tranzitiile relevate pentru functionarea protocolului.

Notatiile sunt:

xt semnifica expirarea temporizatorului, notat cu retry_cnt în specificatia Estelle,

Max este valoarea maxima a temporizarii (max_retry în specificatie).

Sunt detaliate transmisia si receptia datelor în starea “Open”.

Transmitatorul foloseste un contor vs, care memoreaza limitasecventei transmise, prin numarul urmatorului segment de date transmis. Acesta este incrementat modulo-2 dupa transmiterea fiecarui segment.

În receptor, contorul vr memoreaza limita secventei transmise, prin numarul urmatorului segmenr de dare transmis, prin numarul urmatorului segment asteptat. Avanseaza modulo-2 pe masura receptiei datelor în secventa.

Pentru transferul numerelor de secventa, pachetele de date si de confirmare contin urmatoarele câmpuri de control:

ns = înscris cu valoarea curenta a contorului vs,

nr = înscris cu valoarea curenta a contorului vr.

Receptorul foloseste câmpul ns pentru identificarea pozitiei segmentului în fluxul de date.

Transmitatorul interpreteaza câmpul nr ca o confirmare a transferului corect al segmentelor precedente si memoreaza valoarea sa într-o variabila pe care o vom nota va.

AK confirma datele primite în secventa iar câmpul nr confirma pachetul cu numar de secventa mai mic decât nr.

3.      Structura sistemului simulat

Configuratia sistemului simulat este prezentata în fig. 3.1. si include :

Entitatile user1 si user2, de nivel N+1 sunt modele ale utilizatorului serviciului de comunicatie cu conexiune iar entitatile icop1 si icop2 sunt instante ale modulului protocol care realizeaza acest serviciu. Entitatea mediu este un model pentru suportul de comunicatie.

Entitatile protocol sunt structurate în doua submodule: clif si cop, clif constituind interfata cu mediul de comunicatie care ofera un serviciufara conexiune, nefiabil, iar cop este protocolul propriu-zis. Entitatea clif realizeaza transferul spre mediu al pachetelor transmise de catre protocol, într-o interactiune de tip P_Dat_req(pdu) si de la mediu la protocol în interactiunea P_Dat_ind(pdu).

Sunt reprezentate primitivele transferate între nivelele utilizator al serviciului si protocol pe canalul de comunicatie dintre cele doua nivele (sap este un punct de acces la serviciu). Deasemeni sunt reprezentate pachetele transferate între entitatile de nivel N.

4.  Desfasurarea lucrarii

1.       Se va analiza descrierea formala realizata cu limbajul Estelle pentru modulul protocol de comunicatie cu conexiune, comparând cu descrierea neformala din sectiunea 2.

2.       Se va studia prin simulare functionarea protocolului COP, folosind descriera Estelle din fisierul 12v1.st1. În acest scop, se executa comanda .12v1.edb –n. Programul 12v1.edb –n este un executabil pentru simulare construit pe baza specificatiei Estelle, obtinut astfel:

mai întâi compilatorul EC, care are 2 componente: translator (1) + generator (2) realizeaza:

(1)    face analiza sintactica si semantica (statica) a specificatiei Estelle 12v1.stl si creaza forma intermediara 12v1.if (reprezentare în tip format “masina a specificatiei);

(2)    genereaza pe baza “12v1.if” cod C (functii corespunzatoare tranzitiilor, etc.) si un fisier ‘make’ care descrie cum se construieste executabilul.

apoi se foloseste procedura obisnuita de obtinere a executabilului, un compilator C (fie CC, fie GNU) compileaza fisierele C generate de Ec iar editorul de legaturileaga fisierele obiect rezultate, împreuna cu biblioteca de simulare Ebdlaunch.o; rezulta 12v1.edb. Acesta este un fisier mare pentru ca încorporeaza toate comenzile de simulare, functiile predefinite, interpretorul de comenzi.

Se încarca apoi fisierul S1v3() ce contine scenariile de simulare.

Se vor executa scenariile:

isc1 pentru stabilire cu succes,

isc2 în cazul refuzului stabilirii conexiunii de catre utilizatorul apelat,

isc3 pentru cazul refuzului unei conexiuni de catre furnizorul serviciului (cop),

isc4 pentru abandon al comunicatiei de catre initiator si

isc5 în cazul tentativei de stabilire simultana de catre ambii utilizatori, urmarind evolutia proceselor care comunica în vederea realizarii serviciului solicitat.

Pentru început se executa implicit scenariul isc1.

Reluarea executiei pentru o alta evolutie a sistemului se face cu comenzile: start () urmata de isc_nr().

3.       Se va relua simularea pentru fiecare scenariu în situatiile în care se pierd pachete în mediul de comunicatie.

Pentru pierderi de pachete se vor folosi macrodefinitiile mp1() sau mp2().

Cu mp1() se poate pierde un pachet care ajunge în punctul sap[1] de intrare al mediului, iar cu mp2() se pierde pachetul sosit în mp[2].

Aplicatie

Se vor desena pentru fiecare caz în parte diagramele de mesaje complete, cu starile proceselor si tranzitiile executate de catre acestea. Pe parcursul simularii se pot vizualiza atât starile proceselor, cu comanda d $h, cât si identitatea tranzitiilor executate, folosind comanda d $1trid.

Deasemeni, se va folosi macrodefinitia dst() care afiseaza starile modulelor protocol precum si variabilele de stare utilizate de catre acestea: va, vs, vr.