Transport Layer

Mecanisme de QoS la nivelul transport
1.Programarea fluxului
Programatorul de flux operează în conjuncţie cu formatorul de flux pentru a asigura controlul potrivit al ratei pentru a asigura lărgimea de bandă garantată pentru flux şi să ajute la managementul fluxului.


Sistem de transport METS



Progamarea şi modelarea fluxului

Rolul programatorului de flux este de a programa cadrele de nivel aplicaţie (ALF; Application Level Frames), pe bază de cadre pe secunde. Este implementată într-o librărie a spaţiului utilizatorului şi este utilizată atât pentru transmisie cât şi pentru recepţie. În transmisie, programatorul utiilzează cronometrul standard Linux pentru a trimite cadrele de nivel aplicaţie la stadiul de modelare de flux în funcţie de termenele limită derivate din specificarea fluxului.

Un serviciu de rată de bit bariabilă este asigurat prin programarea izocronă a pachetelor de mărime variabilă la nivelele mai joase. La receptor, programatorul de flux se bazează pe fitrul de jotter pentru a asigura termenele limită ale programării.

O problemă cu implementarea programatorului de flux în mediul Linux este aceea că se bazează pe ceasul granulat Linux ce poate rezulta în drift sau alunecare (slippage). Pentru a rezolva această problemă, se utilizează o funcţie de compensare a drift-ului ce ia în considerare orice termene limită ratate. Dacă un termen limită a fost ratat, atunci programatorul fluxului permite imediat aplicaţiei să trimită sau să primească media. Durata următoarei oportunităţi de programare este atunci calculată şi ia în considerare orice drift în rata izocronă a transmiţătorului. Programatorul fluxului ţine evidenţa oricăror termene limită ratate şi informează un modul din planul de management al fluxului dacă numărul de termene limită ratate depăşeşte o limită de termene limită ratate. Gestionarea fluxului poate aborda aplicaţiile prin socket-ul de management pentru a le informa de asemenea evenimente.

Atunci când se utilizeazî fluxuri codate pe nivel, aplicaţiile QoS sunt în general destinate numai baze de transmisie a cadrelor de nivel atunci când se rateazp termenele limită în mod consistent. Atunci când congestia s-a eliberat, managementul fluxului informează aplicaţia printr-un semnal de eveniment QoS să reia rata originală. Desigur, programatorul fluxului nu înţelege semanticile fluxurilor pe nivel.[6]

2. Modelatorul de flux
Modelatorul de flux asigurp controlul deschis al fluxului buclelor pe baza unei scheme cu tocken-uri ce adaptează ritmul celulelor la interfaţa de reţea. este implementată ca o parte a driverul-ui de dispozitic de nivel kernel ATM şi se invocă la fiecare 1 ms utilizând un cronometru hardware dedicat. Schema de tocken-uri este o variantă a algoritmului găleţii ce curge. În această schemă, fluxurile acumulează credite ce reprezintă un număr de celule ATM ce poate di transmis către reţea în următorul interval. [11]

Modelatorul de flux menţine următoarele per statut de flux:

1. 
   Un buget de token, b, ce reprezintă capacitatea sau adâncimea găleţii de token
   
2. 
   Un credit de token, r, ce reprezintă creditele rămase (0
3. 
   O rată de îmbunătăţire a reîmprospătării, p, ce reprezintă rata la care găleata de token-uri este reumplută
   
4. 
   Un timp de expirare a token-ului, t, ce reprezintă numărul de tic-uri ce rămân până când expiră rata împrospătării token-ului şi se reîmprospătează creditele token-ului.
   

O schemă cu găleată de token-uri operează într-o manieră relativ simplă. Atunci când expiră cronometrul token-ului, creditul token-ului este setat să fie egal cu bugetul token-ului. Un credit reprezintă o oportunitate de transmisie pe celulă. Atunci când moelatorul de flux funcţionează, el vizitează toate cozile per flux într-o manieră round robin şi, dacă coada conţine celule şi are credite disponibile, atunci modelatorul transmite o celulă din coadă şi decrementează variabila de stare a creditului token-ului. Aceasta obşine efectul dorit de intercalare a celulelor din diferite SVC-uri în reţea.

Există două rezultate posibile la finalul unui interval de împrospătare a token-ului: fie toate celulele au fost secate sau celulele rămân în coadă. Dacă celulele rămân în coadă, atunci toate creditele au fost utilizate în timpul intervalului. Dacă nu rămân celule în coadă, atunci toate celulele din coadă au fost emise reţelei ăn timpul intervalului cu (0<=r
3. Filtru de jitter
Obiectivul filtrului de jitter este de a reda proprietăţile de timp a fluxului original de date transmise la sursă înainte ca fluxul să fie livrat la dispozitivul de redare la sistemul terminal. Este un proces direct de recuperare a temporizatorului original în sistemele de comunicaţii ce asigură un hotar greu al întârzierii (este necesar numai să se pună pachete în buffer la sistemul terminal până în momentul T+D, unde T este o etichetă de timp plasată în pachet la sursă şi D este întârzierea maximă ce va apare). Multe reţele, însă, nu pot garanta o limită de întârziere maximă. În asemenea cazuri, receptorul trebuie să formeze o estimată ce se actualizează în mod continuu a întârzierii maxime ca bază pe care se calculează timpul de buffer. În algorimtul adoptat, analiza statistică a întârziewrilor pe pachet este utilizată pentru a calcula întârzierea maximă. De exemplu: D=d+ r*s, unde d este întârzierea medie, s este deviaţia stgandard şi r este un coeficient de filtru ce este ales ca funcţie a formei curbei de distribuţie şi numărul de ratări ce pot fi acceptate.

Fiecare ratare corespunde unei întârzieri de transmisiune mai mari decât maximul estimat. Pachetele ce ajung după D sunt considerate a veni prea târziu pentru a ajuta la recontrucţia semnalului şi, în acest caz, managementul fluxului este informat de evenimentul de pachet întârziat şi pachetul este aruncat. O valoare populară pentru r este 2, ceea ce corespunde unei pierderi acceptate de 1% dacă se presupune o distribuţie Gaussiană a întârzierilor. Dintr-un punct de vedere intuitiv, termenul 2s este utilizat pentru a stabili timpul de desfăşurare pentru a fi suficient de departe de întârzierea estimată, astfel ca numai o fracţiune acceptabilă de pachete ce vin să fie pierdute datorită intervalului de timp întârziat.[7]

Filtrul de jitter estimează în mod continuu întârzierea medie şi deviaţia standard. Se bazează pe algoritmul de filtrare joasă utilizat în TCP pentru estimarea timpului de recunoaştere întârziat, şi operează după cum urmează. Când un pachet METS este primit, întârzierea de transmisiune, t, este determinată ca diferenţa dintre timpul de recepţie şi timpul de emisie. Întârzierea medie şi deviaţia standard sunt calculate după cum urmează:

d = dold + a(t - d), s = sold +b(|t - d| - s). Constantele a şi b (a, b <1) sunt coeficienţi de atenuare. Valori tipice sunt 1/8 şi 1/16, respectiv, ceea ce face calcularea lui d şi s eficientă în mod particular.

Odată determinată o metodă pentru calcularea estimatei D actualizate în mod continuu, este necesar să se decidă o granularitate de timp potrivită la care D, şi astfel timpul de rulare, ar trebui actualizată.

Atunci când un proces de aplicaţie doreşte să stabilească o conexiune cu un proces de aplicaţie la distanţă, el trebuie să specifice cu ce proces să se conecteze. Metoda este utilizată în mod normal pentru a defini adresa de transport pe care procesul trebuie să asculte pentru a afla cerinţele de conexiune. În Internet, aceste puncte terminale sunt perechi. În reţelele ATM, ele sunt AAL-SAP-uri, cunoscute cu denumirea TSAP (Transport Service Access Point). Punctele terminale analogice în nivelul reţea (adresele de nivel reţea) sunt numite NSAP-uri. Adresele IP sunt exemple de NSAP-uri.[12]

Formatul unităţii de date de protocol transport (TPDU, Transport Protocol Data Unit) este în imagine. Fiecare TPDU constă din 4 câmpuri generale: lungime (length), parametri fixaţi (fixed parameters), parametrii variabili (variable parameters) şi date (data).

• 
  Câmpul lungime ocupă primul byte şi indică numărul total de byte (fără câmpul lungime) din TPDU.
  
• 
  Câmpul parametri fixaţi conţine parametri, sau câmpuri de control ce sunt prezente în mod obişnuit în toate pachetele de nivel transport. Constă din 5 părţi: Cod, referinţa sursei, referinţa destinaţiei, numărul secvenţei şi alocarea creditului.
  
• 
  Codul identifică tipul de unitate de date, de exemplu CR pentru cererea conexiunii (connection request) sau DT pentru date (data):
  

• 
  CR: Connection Request
  
• 
  CC: Connection Confirm
  
• 
  DR: Disconnect Request
  
• 
  DC: Disconnect Confirm
  
• 
  DT: Data
  
• 
  ED: Expedited Data
  
• 
  AK: Data Acknowledge
  
• 
  EA: Expedited Data Acknowledge
  
• 
  RJ: Reject
  
• 
  ER: Error
  

• 
  Câmpurile de referinţă a sursei şi destinaţiei conţin adresele emiţătorului original şi destinaţia finală a pachetului.
  
• 
  Numărul secvenţei: o transmisiune este împărţită în pachete mai mici pentru transport. Fiecărui segment i se acordă un număr ce identifică locul său în secvenţă. Numerele de secvenţă sunt utilizate pentru confirmări, controlul fluxului şi reordonarea pachetelor la destinaţie.
  
• 
  Alocarea creditului permite unei staţii receptoare să-i transmită emiţătorului câte unităţi de date mai pot fi trimise înainte ca emiţătorul să trebuiască să aştepte o confirmare.
  
• 
  Câmpul parametrii variabili conţine parametrii ce apar frecvent. Aceste coduri de control sunt utilizaţi în special pentru management.
  
• 
  Date: câmpul poate conţine date obişnuite sau date expediate ce vin de la straturile superioare. Datele expediate constau dintr-un mesaj de prioritate mare ce trebuie manipulat în afara secvenţei. O cerere urgentă poate surclasa coada de intrare în receptor şi poate fi procesată înaintea pachetelor ce au fost primite înaintea sa.[4]
  

Un alt mod de a privi nivelul transport este de a observa funcţia sa primară de schimbare a QoS-ului asigurat de nivelul de reţea- dacă serviciul de reţea este impecabil, nivelul transport are puţin de lucru. Dacă însă serviciul de reţea este slab, nivelul transport trebuie să unifice golul dintre ceea ce doresc utilizatorii transportului şi ceea ce asigură nivelul de reţea.

Serviciul de transport poate de asemenea să permită utilizatorului să specifice valori preferate, acceptabile şi minime pentru diverşi parametrii de serviciu la momentul realizării unei conexiuni.[3]

Concluzii QoS

• 
  Întârzierea datorată stabilirii conexiunii este cantitatea de timp ce trece între realizarea cererii unei conexiuni de transport şi primirea confirmării de către utilizatorul serviciului de transport. Ea include întârzierea de procesare în entităţile de transport la distanţă. La fel ca toţi parametrii ce măsoară o întârziere, cu cât este mai mică întârzierea, cu atât este mai bun serviciul.
  
• 
  Probabilitate de nereuşită de a stabili conexiunea este şansa ca o conexiune să nu fie stabilită în intervalul maxim de întârziere de stabilire, de exemplu datorită unei congestii în reţea, a lipsei de spaţiu în tabelă undeva sau alte probleme interne.
  
• 
  Parametrul de transfer măsoară număruld e Byte de date transferate de utilizator per secundă, măsurate într-un interval de timp. Parameturl de transfer este măsurat separat pentru fiecare direcţie.
  
• 
  Întârzierea de tranzit măsoară timpul dintre trimiterea unui mesaj de către utilizatorul transportului pe o maşină sursă şi recepţionarea sa de către utilizatorul transportului la maşina destinaţie. Ca şi cu parametrul de transfer, fiecare direcţie este manevrată separat.
  
• 
  Rata de eroare reziduală măsoară numărul de mesaje pierdute sau greşite ca fracţiune din totalul trimis. În teorie, rata de eroare reziduală ar trebui să fie zero, din moment ce este datoria nivelului transport să ascundă toate erorile de nivel reţea. În practică, însă, poate avea o valoare finită.
  
• 
  Parametrul de protecţie asigură o cale pentru utilizatprul transportului să specifice interesul în a realiza asigurarea protecţiei de către nivelul transport împotriva părţilor terţe neautorizate (wire tapers), împotriva citirii sau modificării datelor transmise.
  
• 
  Parametrii de prioritate asigură o cale pentru un utilizator de tranposrt să indice că unele dintre conexiunile sale sunt mai importante decât altele. Şi în cazul unei congestii, pentru a se asigura că conexiunile de prioritate mare sunt servite înaintea celor cu prioritate joasă.
  
• 
  Parametrul de elasticitate oferă probabilitatea ca însuşi nivelul transport să termine în mod spontan o conexiune datorită unor probleme interne sau a congestiei.
  

Parametrii QoS sunt specificaţi de utilizatorul transportului atunci când este cerută o conexiune. Atât valorile dorite cât şi cele minime acceptabile pot fi oferite. În anumite cazuri, la vederea parametrilor QoS, nivelul transport poate realiuza imediat că unii dintre ei nu pot fi atinşi.

Distribuirea contribuţiilor la proiect:

6. 
   Introducere: Ştefănescu Yasmin
   
7. 
   TCP şi UDP: Popescu Razvan
   
8. 
   Servicii furnizate nivelurilor superioare: Ovidiu Guţă
   
9. 
   Alte protocoale de transport prin Internet: Laza Laura
   
10. 
    Elemente de performanţă: Lungu Mihail
    
11. 
    Calitatea serviciilor la nivel de transport - Ştefănescu Yasmin
    
12. 
    Bibliografie: Ştefănescu Yasmin
    
13. 
    Aranjare în pagină şi împărţirea pe capitole: Ştefănescu Yasmin
    

Bibliografie:

• 
  [1]http://www.computing.dcu.ie/~humphrys/Notes/Networks/transport.html
  
• 
  [2]http://www.erg.abdn.ac.uk/~gorry/course/inet-pages/transport.html
  
• 
  [3]http://classof1.com/homework_answers/computer_science/the_transport_layer/
  
• 
  [4]http://nptel.iitm.ac.in/courses/IITMADRAS/Computer_Networks/pdf/Lecture36_TransportLayer.pdf
  
• 
  [5]http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1019305
  
• 
  [6]http://www.eetimes.com/design/communications-design/4143349/Transport-Layer-QoS-standards-improve-wireless-messaging-services
  
• 
  [7]www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/.../paper.97.3.pdf
  
• 
  [8]http://regal.csep.umflint.edu/~swturner/Classes/csc336/ch06-4.pdf
  
• 
  [9]http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=564935
  
• 
  [10]http://www.scribd.com/doc/29882034/QoS-Transport-Layer
  
• 
  [11]http://en.wikipedia.org/wiki/Transport_layer
  
• 
  [12]http://mail.tools.ietf.org/html/rfc2990
  
• 
  [13]http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=318140
  
• 
  [14]"Analyzing TCP, UDP usage in Internet traffic" - ieeexplore.ieee.org 
  
• 
  [15]www.wikipedia.org
  
• 
  [16]www.cisco.com (Network Fundamentals – Transport Layer)
  
• 
  [17]www.laynetworks.com
  
• 
  [18]CLARK, D.D., LAMBERT, M., and ZHANG, L.: "NETBLT: A High Throughput Transport Protocol," Proc. SIGCOMM '87 Conf., ACM, pp. 353-359, 1987.
  
• 
  [19]FRASER, A.G.: "Towards a Universal Data Transport System," in Advances in Local Area Networks, Kummerle, K., Tobagi, F., and Limb, J.O. (Eds.), New York: IEEE Press, 1987.
  
• 
  [20]SUNSHINE, C.A., and DALAL, Y.K.: "Connection Management in Transport Protocols," Computer Networks, vol. 2, pp. 454-473, 1978.
  
• 
  [21]BALAKRISHNAN, H., SESHAN, S., and KATZ, R.H.: "Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks," Proc. ACM Mobile Computing and Networking Conf., ACM, pp. 2-11, 1995.
  
• 
  [22]http://www.tcpipguide.com
  
• 
  [23]Postel, J. (ed.), "Internet Protocol - DARPA Internet Program. Protocol Specification," RFC 791, USC/Information Sciences
  
• 
  [24]Cerf, V., "The Catenet Model for Internetworking," IEN 48, Information Processing Techniques Office, Defense Advanced
  
• 
  [25]Strazisar, V., "Gateway Routing: An Implementation Specification", IEN 30, Bolt Beranek and Newman, April 1979.
  
• 
  [26] “RTP: A Transport Protocol for Real-Time Applications”, IETF, July 2003
  
• 
  [27] “RTP Profile for Audio and Video Conferences with Minimal Control”, IETF, July 2003
  
• 
  [28] “Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences, IETF, April 2009
  
• 
  [29]Perkins, Colin (2003). RTP Addison-Wesley
  
• 
  [30]Peterson, Larry L.; Bruce S. Davie (2007) Computer Networks (4 ed.). Morgan Kaufmann
  
• 
  [31] “RTCP”. Network Protocols Handbook. Javvin Technologies. 2005
  
• 
  [32] Andrew S. Tanenbaum – Universitatea Vrijie (Amsterdam, Olanda)