Modelul de referinta OSI

Modelul OSI este prezentat in Fig. 1 (mai putin mediul fizic). Acest model se bazeaza pe o propunere dezvoltata de catre Organizatia Internationala de Standardizare (International Standards Organization - OSI) ca un prim pas spre standardizarea internationala a protocoalelor folosite de diferite niveluri (Day si Zimmermann, 1983). Modelul se numeste ISO OSI (Open Systems Interconnection - Interconectarea sistemelor deschise), pentru ca el se ocupa de conectarea sistemelor deschise - adica de sisteme deschise comunicarii cu alte sisteme. In continuare vom folosi mai ales termenul prescurtat de model OSI.

Modelul OSI cuprinde sapte niveluri. Principiile aplicate pentru a se ajunge la cele sapte niveluri sunt urmatoarele:

Un nivel trebuie creat atunci cand este nevoie de un nivel de abstractizare.

Fiecare nivel trebuie sa indeplineasca un rol bine definit.

Functia fiecarui nivel trebuie aleasa acordandu-se atentie definirii de protocoale standardizate pe plan international.

Delimitarea nivelurilor trebuie facuta astfel incat sa se minimizeze fluxul de informatii prin interfete.

Numarul de niveluri trebuie sa fie suficient de mare pentru a nu fi nevoie sa se introduca in acelasi nivel functii diferite si suficient de mic pentru ca arhitectura sa ramana functionala.

DESEN1

In continuare vom discuta fiecare nivel al modelului, incepand cu nivelul cel mai de jos. Modelul OSI nu reprezinta in sine o structura de retea, pentru ca nu specifica serviciile si protocoalele utilizate la fiecare nivel. Modelul spune numai ceea ce ar trebui sa faca fiecare nivel. ISO a produs de asemenea standarde pentru fiecare nivel, insa aceste standarde nu fac parte din modelul de referinta propriu-zis. Fiecare din standardele respective a fost publicat ca un standard international separat.

NIVELUL FIZIC

Nivelul fizic se ocupa de transmiterea bitilor printr-un canal de comunicatie. Proiectarea trebuie sa garanteze ca atunci cand unul din capete trimite un bit 1,acesta e receptat in cealalta parte ca un bit 1, nu ca bit 0. Problemele tipice se refera la cati volti trebuie utilizati pentru a reprezenta un 1 si cati pentru un 0, daca transmisia poate avea loc simultan in ambele sensuri, cum este stabilita conexiunea initiala si cum este intrerupta cand au terminat de comunicat ambele parti, cati pini are conectorul de retea si la ce foloseste fiecare pin. Aceste aspecte de proiectare au o legatura stransa cu interfetele mecanice, electrice, functionale si procedurale ,ca si cu mediul de transmisie situat sub nivelul fizic.

NIVELUL LEGATURA DE DATE

Sarcina principala a nivelului legatura de date este de a transforma un mijloc oarecare de transmisie intr-o linie care sa fie disponibila nivelului retea fara erori de transmisie nedetectate. Nivelul legatura de date realizeaza aceasta sarcina obligand emitatorul sa descompuna datele de intrare in cadre de date (in mod tipic, cateva sute sau cateva mii de octeti), sa transmita cadrele secvential si sa prelucreze cadrele de confirmare trimise inapoi de receptor. Deoarece nivelul fizic nu face decat sa accepte si sa transmita un numar de biti, fara sa se preocupe de semnificatia sau de structura lor, responsabilitatea pentru marcarea si recunoasterea delimitatorilor intre cadre ii revine nivelului legatura de date. Aceasta se poate realiza prin atasarea unor sabloane speciale de biti la inceputul si la sfarsitul cadrului. In cazul in care sabloanele respective de biti pot aparea accidental in datele propriu-zise, trebuie luate masuri speciale de precautie pentru ca aceste sabloane sa nu fie incorect interpretate ca delimitatori de cadre.

Un zgomot aparut pe linie poate distruge un cadru in intregime. In acest caz, programele nivelului legatura de date de pe masina sursa pot sa retransmita cadrul. Transmiterile multiple ale aceluiasi cadru introdu posibilitatea cadrelor duplicate. Un cadru duplica poate aparea la transmisie in situatia in care s-au pierdut cadrele de confirmare trimise de la receptor inapoi spre emitator. Rezolvarea problemelor datorate cadrelor deteriorate, pierdute sau duplicate cadre in sarcina nivelului legatura de date. Acesta poate oferi nivelului retea cateva clase de servicii diferite, fiecare de o calitate si de un pret diferit.

O alta problema care apare la nivelul legatura de date (si, de asemenea, la majoritatea nivelurilor superioare) este evitarea inundarii unui receptor lent cu date provenite de la un emitator rapid. In acest scop sunt necesare mecanisme de reglare a traficului care sa permita emitatorului sa afle cat spatiu tampon detine receptorul la momentul curent. Controlul traficului si tratarea erorilor sunt deseori integrate.

Daca linia poate fi folosita pentru a transmite date in ambele sensuri, atunci apare o noua complicatie, care trebuie rezolvata de catre programele de la nivelul legatura de date. Problema se refera la concurenta care exista pentru utilizarea liniei intre cadrele de confirmare pentru traficul de la A la B si cadrele de date din traficul de la B la A. Pentru rezolvarea ei a fost conceputa o solutie inteligenta: atasarea (piggybacking);mai tarziu vom discuta aceasta solutie in detaliu.

Retelele cu difuzare determina in nivelul legatura de date o problema suplimentara: cum sa fie controlat accesul la canalul protejat. De aceasta problema se ocupa un subnivel special al nivelului legatura de date, si anume subnivelul de acces la mediu.

NIVELUL RETEA

Nivelul retea se ocupa de controlul functionarii subretelei. O problema cheie in proiectare. Este determinarea modului in care pachetele sunt dirijate de la sursa la destinatie. Dirijarea se poate baza pe tabele statistice care sunt "cablate" intern in retea si care sunt schimbate rar. Traseele pot fi de asemenea stabilite la inceputul fiecarei conversatii, de exemplu la inceputul unei sesiuni la terminal. In sfarsit, dirijarea poate fi foarte dinamica, traseele determinandu-se pentru fiecare pachet in concordanta cu traficul curent din retea.

Daca in subretea exista prea multe pachete simultan, ele vor intra unul pe traseul celuilalt si astfel se vor produce gatuiri. Controlul unor astfel de congestii ii revine tot nivelului retea.

Deoarece operatorii subretelei pot foarte bine sa astepte o plata pentru eforturile lor, in nivelul retea exista, de obicei, inglobata o functie de taxare a traficului. Pentru a calcula suma datorata de clientii retelei, programul trebuie cel putin sa numere cate pachete, sau cate caractere, sau cati biti a trimis fiecare client. Calculul se complica atunci cand un pachet traverseaza frontiera dintre doua zone cu sisteme de preturi diferite.

Multe probleme pot aparea cand un pachet trebuie sa calatoreasca dintr-o retea in alta ca sa ajunga la destinatie. Modul de adresare folosit de a doua retea poate sa difere de cel pentru prima. A doua retea poate chiar sa nu accepte deloc pachetul pentru ca este prea mare. De asemenea, protocoalele pot fi diferite si asa mai departe. Rezolvarea acestor probleme in vederea interconectarii retelelor eterogene este sarcina nivelului retea.

In retelele cu difuzare, problema dirijarii este simpla, astfel ca nivelul retea este deseori subtire sau chiar nu exista deloc.

NIVELUL TRANSPORT

Rolul principal al nivelului transport este sa accepte date de la nivelul sesiune, sa le descompuna, daca este cazul, in unitati mai mici, sa transfere aceste unitai normale nivelul transport creeaza o conexiune de retea distincta pentru fiecare conexiune de transport ceruta de nivelul sesiune. In cazul in care conexiunea de transport necesita o productivitate mare, nivelul transport poate totusi sa creeze conexiuni de retea multiple si sa divida datele prin conexiuni de retea, astfel incat productivitatea sa creasca. Pe de alta parte, daca crearea ti intretinerea unei conexiuni de retea este costisitoare, nivelul transport ar putea reduce prin multiplexarea catorva conexiuni de transport pe aceeasi conexiune de retea. In oricare dintre cazuri , nivelul transport I se cere sa faca multiplexarea transparenta pentru nivelul sesiune.

Nivelul transport determina, de asemenea, ce tip de serviciu sa furnizeze nivelului sesiune si, in final, utilizatorilor retelei. Cel mai obisnuit tip de conexiune transport este un canal punct-la-punct fara erori care furnizeaza mesajele sau octetii in ordinea in care au fost trimisi. Alte tipuri posibile de servicii de transport sunt transportul mesajelor individuale - fara nici o garantie in privinta ordinii de livrare - si difuzarea mesajelor catre destinatii multiple. Tipul serviciului se determina cand se stabileste conexiunea.

Nivelul transport este un adevarat nivel capat-la-capat, de la sursa la destinatie. Cu alte cuvinte, un program de pe masina sursa poarta o conversatie cu un program similar de pe masina destinatie, folosind in acest scop antetele mesajelor si mesaje de control. In nivelurile inferioare protocoalele au loc intre fiecare masina si vecinii sai imediati, si nu direct intre masinile sursa si destinatie, care pot fi separate de numeroase rutere. Diferenta intre nivelurile de la 1 pana la 3, care sunt inlantuite, si nivelurile de la 4 la 7, care sunt capat-la-capat, este ilustrata in Fig. 1-16.

Numeroase gazde sunt multiprogramate, ceea ce implica existenta unor conexiuni multiple care intra si ies in fiecare gazda. Trebuie sa existe o modalitate prin care sa se poata spune care mesaje apartin carei conexiuni. Unul din locurile unde poate fi pusa aceasta informatie este antetul de transport (H 4 in Fig. 1-11).

In plus fata de multiplexarea mai multor fluxuri de mesaje pe un singur canal, nivelul transport mai trebuie sa se ocupe de stabilirea si anularea conexiunilor in retea. Pentru acest lucru este necesar un mecanism de atribuirea numelor, astfel ca un proces de pe o anumita masina sa poata descrie cu cine vrea sa converseze. Trebuie, de asemenea, sa exise un mecanism pentru reglarea fluxului de informatii, astfel incat o gazda rapida sa nu suprasolicite o gazda lenta. Un astfel de mecanism se numeste controlul fluxului si joaca un rol cheie in nivelul transport (ca si in alte niveluri). Controlul fluxului intre gazde este diferit fata de controlul fluxului intre rutere, dar vom vedea mai tarziu ca pentru amandoua se aplica principii similare.

NIVELUL SESIUNE

Nivelul sesiune permite utilizatorilor de pe masini diferite sa stabileasca intre ei sesiuni. Ca si nivelul transport, o sesiune permite transportul obisnuit de date, dar furnizeaza totodata si servicii imbunatatite , utile in anumite aplicatii. O sesiune poate fi utilizata pentru a permite unui utilizator sa se conecteze la distanta pe un sistem cu divizarea timpului sau sa transfere un fisier intre doua masini.

Unul dintre serviciile nivelului sesiune se refera la controlul dialogului. Sesiunile pot permit sa se realizeze trafic in ambele sensuri simultan , sau numai intr-un sens odata. Daca este permis traficul intr-un sens odata (analog drumurilor cu sens unic) , nivelul sesiune poate ajuta sa se tina evidenta emitatorilor carora le vine randul sa transmita.

Un serviciu sesiune inrudit este gestionarea jetonului .In unele protocoale este esential ca cele doua parti sa nu incerce sa realizeze aceeasi operatie in acelasi timp. Pentru a trata aceste situatii, nivelul sesiune dispune de jetoane care pot circula intre masini. Numai partea care detine jetonul are voie sa realizeze operatia critica.

Un alt serviciu sesiune este sincronizarea. Sa consideram problemele care pot aparea atunci cand se incearca transferarea unui fisier intre doua masini, in conditiile in care transferul dureaza 2 ore, iar intervalul mediu de cadere a legaturii este 1 ora. Dupa fiecare esec , tot transferul va trebui initiat din nou si probabil ca nu va reusi nici incercarea urmatoare. Pentru a elimina problema respectiva, nivelul sesiune prevede o modalitate de a introduce in fluxul de date puncte de control, astfel incat dupa un esec trebuie sa se reia numai transferul datelor de dupa ultimul punct de control.

NIVELUL PREZENTARE

Nivelul prezentare indeplineste cateva functii care sunt solicitate suficient de des pentru ca, in loc sa fie lasat fiecare utilizator sa rezolve problemele, sa se justifice gasirea unei solutii generale. In particular , spre deosebire de toate nivelurile inferioare , care se ocupa numai de transferul sigur al bitilor dintr-un loc in altul, nivelul prezentare se ocupa de sintaxa si semantica informatiilor transmise.

Un exemplu tipic de serviciu prezentare este codificarea datelor intr-un mod standard, prestabilit. Majoritatea programelor folosite de utilizatori nu fac schimb de siruri aleatoare de biti. Ele fac schimb de nume de persoane , adrese , date , sume de bani, anunturi. Aceste informatii sunt reprezentate prin siruri de caractere , prin intregi, prin numere reale si prin structuri de date compuse dintr-un numar de date mai simple. Diferite calculatoare au coduri pentru reprezentarea sirurilor de caractere (de ex. Ascii si Unicode), intregilor(de ex. Complementul fata de 1 si complementul fata de 2) etc. Pentru a face posibila comunicarea intre calculatoare cu reprezentari diferite, structurile de date pot fi definite intr-un mod abstract , alaturi de o codificare standardizata ce va fi utilizata "pe cablu" . Nivelul prezentare gestioneaza aceste structuri de date abstracte si le converteste din reprezentarea interna folosita in calculator in reprezentarea standardizata din retea si invers.

NIVELUL APLICATIE

Nivelul aplicatie contine o varietate de protocoale frecvent utilizate. De exemplu, in lume exista sute de tipuri de terminale incompatibile. Ganditi-va la impasul in care se afla un editor in mod ecran care trebuie sa lucreze intr-o retea cu multe tipuri diferite de terminale, fiecare cu un aspect diferit al ecranului si cu secvente ESCAPE diferite pentru introducerea si stergerea textului, mutare cursorului etc.

O modalitate de a rezolva problema este sa se defineasca un terminal virtual de retea abstract si sa se scrie editoare si alte programe care stiu sa lucreze cu acesta .Pentru a putea lucra cu orice tip de terminal, este necesar un program care sa puna in corespondenta functiile terminalului virtual de retea si terminalul real. De exemplu , atunci cand editorul muta cursorul din terminalul virtual in coltul stanga-sus al ecranului, programul trebuie sa aplice secventa potrivita de comenzi pentru terminalul real, astfel incat sa se mute si cursorul acestuia. Toate programele terminalului virtual se afla pe nivelul aplicatie.

Un alt rol al nivelului aplicatie este transferul fisierelor. Sisteme de fisiere diferite au conventii de nume diferite, moduri diferite de a reprezenta liniile de text etc. Transferul unui fisier intre doua sisteme de fisiere diferite presupune rezolvarea acestor incompatibilitati si a altora de acelasi gen. Si acest lucru cade tot inseamna nivelului aplicatie, la fel ca si posta electronica, introducerea lucrarilor la distanta, examinarea cataloagelor si diverse alte facilitati cu scop general sau particular.

TRASMITEREA DATELOR IN MODELUL OSI

Figura 1-17 prezinta un exemplu de transmitere a datelor folosind modelul OSI. Procesul emitator vrea sa trimita niste date procesului receptor. Emitatorul furnizeaza datele nivelului aplicatie, acesta le ataseaza in fata antetul aplicatie, AH (care poate fi vid) si furnizeaza obiectul rezultat nivelului prezentare.

Nivelul prezentare poate sa modifice acest obiect in diferite moduri si poate eventual sa-I adauge infata un antet, furnizand rezultatul catre un nivel sesiune .Este important de stiut ca nivelul prezentare nu cunoaste care portiune din datele primite de la nivelul aplicatie reprezinta AH ,in cazul in care acesta exista, si care portiune reprezinta datele propriu-zise ale utilizatorului.

Acest proces se repeta pana cand datele ajung la nivelul fizic, unde ele vor fi trimise efectiv catre masina receptoare. Pe respectiva masina., diversele antete sunt eliminate succesiv, pe masura ce mesajul se propaga prin niveluri in sus , pana cand ajunge in final la procesul destinatie.

Ideea de baza este ca, desi in fig.1-17 transmiterea datelor este verticala , fiecare nivel este programat ca si cum transmiterea ar fi orizontala. De exemplu, atunci cand nivelul transport emitator primeste un mesaj de la nivelul sesiune, el ii ataseaza un antet de transport si il expediaza nivelului transport destinatie. Din punctul sau de vedere, faptul ca in realitate trebuie sa paseze mesajul nivelului retea de pe masina sa proprie este un detaliu tehnologic lipsit de importanta. Analog, cand un diplomat care vorbeste limba Tagalog se adreseaza Natiunilor Unite, el se gandeste ca se adreseaza celorlalti diplomati prezenti la adunare. Faptul ca in realitate el vorbeste numai translatorului sau este de vazut ca un detaliu tehnic.

Figura 1-17.

O comparatie intre modelele de referinta OSI si TCP

Modelele de referinta OSI si TCP IP au multe lucruri in comun. Amandoua se bazeaza pe conceptul unei stive de protocoale independente. De asemenea, functionalitatea nivelurilor este in linii mari similara. De exemplu, in ambele modele, nivelurile pana la nivelul transport inclusiv sunt necesare pentru a pune la dispozitia proceselor care doresc sa comunice un serviciu de transport capat-la-capat independent de retea. Nivelurile respective formeaza furnizorul de transport. Din nou, in ambele modele, nivelurile de deasupra transportului sunt beneficiari orientati pe aplicatii ai serviciului de transport.

In pofida acestor similitudini fundamentale, intre cele doua modele exista si multe deosebiri. In aceasta sectiune ne vom concentra asupra diferentelor cheie dintre cele doua modele de referinta. Este important de subliniat ca vom compara aici modelele de referinta, nu stivele de protocoale corespunzatoare. Protocoalele propriu-zise vor fi discutate mai tarziu. Pentru o intreaga carte consacrata comparatiei si diferentelor TCP IP si OSI (Piscitello si Chapin, 1993).

Trei concepte sunt esentiale pentru modelul OSI:

Servicii

Interfete

Protocoale 

Probabil ca cea mai mare contributie a modelului OSI este ca a facut explicita diferenta intre aceste trei concepte. Fiecare nivel realizeaza niste servicii pentru nivelul situat deasupra sa. Definitia serviciului spune ce face nivelul, nu cum il folosesc entitatile de deasupra sa sau cum functioneaza nivelul.

Interfata unui nivel spune proceselor aflate deasupra sa cum sa faca accesul. Interfata precizeaza ce reprezinta parametrii si ce rezultat se obtine. Nici interfata nu spune nimic despre functionarea interna a nivelului.

In sfarsit, protocoalele pereche folosite intr-un nivel reprezinta treaba personala a nivelului. Nivelul poate folosi orice protocol doreste, cu conditia ca acesta sa functioneze (adica sa indeplineasca serviciul oferit). Nivelul poate de asemenea sa schimbe protocoalele dupa cum vrea, fara ca acest lucru sa afecteze programele din nivelele superioare.

Aceste idei se potrivesc foarte bine cu ideile moderne referitoare la programarea orientata pe obiect. Un obiect, ca si un nivel, poseda un set de metode (operatii) care pot fi invocate de catre procese din afara obiectului. Semanticele acestor metode definesc multimea de servicii pe care le ofera obiectul. Parametrii si rezultatele metodelor formeaza interfata obiectului. Codul intern al obiectului reprezinta protocolul sau si nu este vizibil sau de vreo importanta in afara obiectului.

Desi lumea a incercat ulterior sa il readapteze pentru a fi mai asemanator modelului OSI, modelul TCP IP nu facut initial o distinctie clara intre serviciu, interfata si protocol. De exemplu, singurele servicii veritabile oferite de nivelul Internet sunt SEND IP PACHET si RECEIVE IP PACHET.

In consecinta, protocoalele din nivelul OSI sunt mai bine ascunse decat in modelul TCP IP si pot fi inlocuite relativ usor pe masura ce se schimba tehnologia. Capacitatea de a face asemenea modificari reprezinta unul din scopurile principale ale organizarii protocoalelor pe nivele in modelul OSI.

Modelul de referinta OSI a fost conceput inainte sa fie inventate protocoalele. Ordinea respectiva semnifica faptul ca modelul nu a fost orientat catre un set specific de protocoale, fiind prin urmare destul de general. Reversul este ca proiectantii nu au avut multa experienta in ceea ce priveste acest subiect si nu au avut o idee coerenta despre impartirea functiilor pe niveluri.

De exemplu, nivelul legatura de date se ocupa initial numai cu retelele punct-la punct. Atunci cand au aparut retelele de difuzare, a trebuit sa fie introdus in model un subnivel nou. Cand lumea a inceput sa construiasca retele reale utilizand modelul OSI si protocoalele existente, s-a descoperit ca acestea nu se potriveau cu specificatiile serviciului cerut (minunea minunilor), astfel ca a trebuit introdusa in model convergenta subnivelurilor, ca sa existe un loc pentru a glosa pe marginea diferentelor. In sfarsit, comitetul se astepta initial ca fiecare tara sa aiba cate o retea care sa fie in custodia guvernului si sa foloseasca protocoalele OSI, asa ca nu s-a dat nici o atentie interconectarii. Pentru a nu mai lungi povestea, sa spunem doar ca lucrurile s-au petrecut altfel.

In ceea ce priveste TCP IP, lucrurile stau exact pe dos: mai intai au aparut protocoalele, iar modelul a fost de fapt doar o descriere a protocoalelor existente. Cu protocoalele respective nu era nici o problema: ele se potriveau perfect cu modelul. Singurul necaz era ca modelul nu se potrivea cu nici o alta stiva de protocoale. Prin urmare, modelul nu a fost prea util pentru a descrie alte retele non-TCP IP.

Pentru a ne intoarce de la subiectele filosofice la subiecte mai specifice, o diferenta evidenta intre cele doua modele se refera la numarul de niveluri: modelul OSI are 7 niveluri, iar TCP/IP are 4. Ambele modele au niveluri (inter-)retea, transport si aplicatie, dar restul nivelurilor sunt diferite.

O alta deosebire priveste subiectul comunicatiei fara conexiuni fata de cel al comunicatiei orientata pe conexiuni. Modelul OSI suporta ambele tipuri de comunicatie la nivelul retea, dar numai comunicatii orientate pe conexiuni in nivelul transport, unde acest fapt are importanta (pentru ca serviciul de transport este vizibil utilizatorilor). Modelul TCP IP are numai un mod (fara conexiuni) la nivelul retea, dar suporta ambele moduri la nivelul transport, ceea ce lasa utilizatorilor posibilitatea alegerii. Aceasta alegere este importanta in mod special pentru protocoalele intrebare- raspuns simple.

O critica a modelului si protocoalelor OSI

Nici modelul si protocoalele OSI si nici modelul si protocoalele TCP IP nu sunt perfecte. Asupra lor se pot formula, si s-au formulat, cateva critici. In prezenta si urmatoarea sectiune vom vedea unele dintre aceste critici. Vom incepe cu OSI, dupa care vom examina TCP IP.

La momentul cand a fost publicata a doua editie a acestei carti (1989), majoritatea expertilor in domeniu credeau ca modelul si protocoalele OSI se vor impune peste tot si vor elimina orice concurent. Acest lucru nu s-a intamplat. De ce O privire spre lectiile trecutului poate fi utila. Aceste lectii pot fi rezumate astfel

Ratarea momentului.

Tehnologii proaste.

Implementari proaste.

Politici proaste.

Ratarea momentului

Sa vedem mai intai prima problema ratarea momentului. Momentul la care se stabileste un standard este absolut critic pentru succesul acestuia. David Clark de la M.I.T. are o teorie asupra standardelor pe care o numeste Apocalipsa celor doi elefanti si care este ilustrata in Fig. 1-20.

Fig. 1-20. Apocalipsa celor doi elefanti.

Aceasta figura arata cantitatea de activitate desfasurata in jurul unui subiect nou. Cand subiectul este descoperit, are loc a activitatii de cercetare sub forma de discutii, articole si intalniri. Dupa un timp, cercetarea se reduce foarte mult, subiectul este descoperit de companii si piata primeste lovitura unui val de investitii de miliarde de dolari.

Este esential ca standardele sa fie scrise in intervalul dintre cei doi elefanti". Daca ele sunt scrise prea devreme, inainte sa se incheie cercetarea, atunci subiectul poate sa nu fie inca destul de bine inteles, ceea ce conduce la standarde proaste. Daca ele sunt scrise prea tarziu, atunci probabil ca atat de multe firme au facut deja investitii majore realizand lucrurile altfel, incat standardele sunt efectiv ignorate. Daca intervalul dintre cei doi elefanti este foarte scurt (pentru ca toata lumea arde de nerabdare sa treaca la lucru), atunci toti cei care dezvolta standardele pot fi prinsi la mijloc si striviti.

Acum se vede ca protocoalele OSI standard au fost strivite. La momentul aparitiei lor, protocoalele concurente TCP/IP erau deja folosite pe larg in universitati in cercetare. Inainte sa vina valul investitiilor de miliarde de dolari, piata in domeniul academic era destul de dezvoltata pentru ca multe firme sa inceapa, prudent, sa ofere produse TCP/IP. Cand a aparut OSI, firmele nu au mai vrut, fara sa fie fortate, sa sprijine o a doua stiva de protocoale, si, prin urmare, nu au fost nici un fel de oferte initiale in acest gen. Fiecare firma astepta sa inceapa celelalte firme, asa ca pana la urma nu a mai inceput nici o firma si fenomenul OSI nu s-a mai produs niciodata.

Tehnologii proaste

Al doilea motiv pentru care OSI nu a prins niciodata este ca atat modelul cat si protocoalele au defecte. Majoritatea discutiilor purtate in jurul modelului cu sapte niveluri dau impresia ca numarul si continutul nivelurilor alese in cele din urma erau singura solutie sau cel putin solutia evidenta. Lucrurile stau altfel. Nivelul sesiune este foarte putin folosit in majoritatea aplicatiilor, iar nivelul prezentare e aproape nul. De fapt, propunerea britanica catre ISO avea numai cinci niveluri, nu sapte. Spre deosebire de nivelurile sesiune si prezentare, nivelurile legatura de date si retea sunt atat de incarcate, incat trebuiau impartite in mai multe subniveluri, fiecare cu functii diferite.

Desi rareori admite cineva in public, motivul real pentru care modelul OSI are sapte niveluri este ca, in momentul proiectarii, IBM avea un protocol propriu cu sapte niveluri numit SNAT (Systems Network Architecture-Arhitectura sistemelor de retele). La acea vreme, IBM domina industria de calculatoare in asemenea grad, incat toti ceilalti- companii de telefoane, firme concurente de calculatoare si chiar organizatii guvernamentale importante-se temeau groaznic ca IBM isi va folosi piata pentru a forta efectiv pe toata lumea sa utilizeze SNA, pe care putea sa-l schimbe oricand vroia. Ideea pe care s-a bazat OSI a fost sa se produca o stiva de protocoale si un model de referinta compatibil IBM, care sa devina standardul international, dar care sa nu fie controlat de o singura firma, ci de o organizatie neutra, ISO.

Modelul OSI, alaturi de protocoalele si definitiile de servicii asociate, este extraordinar de complex. Atunci cand sunt puse unul peste altul, standardele tipatrite ocupa cateva zeci de centimetri buni. Standardele sunt, de asemenea, dificil de implementat si ineficiente in functionare. In acest context imi vine in minte o ghicitoare formulata de Paul Mockapetris si citata in (Rose 1993):

I: Ce obtii cand aplici un standard international unui gangster?

R: O persoana care iti face o oferta pe care nu o poti intelege.

Pe langa faptul ca este incomprehensibil, o alta problema cu OSI este ca unele functii, cum sunt adresarea controlul fluxului si controlul erorilor reapar din nou si din nou in fiecare nivel. Saltzer s.a. (1994), de exemplu, au aratat, pentru a fi eficient, controlul erorilor trebuie facut la nivelul cel mai inalt si ca repetarea sa de atatea ori in nivelurile de mai jos este adesea inutila si ineficienta.

O alta problema este ca decizia de a plasa anumite functii in anumite niveluri particulare nu este totdeauna evidenta. Pe parcursul dezvoltarii standardului, gestionarea terminalului virtual (prezenta acum in nivelul aplicatie) a fost mult timp sarcina nivelului prezentare. Aceasta a fost mutata in nivelul aplicatie, deoarece comitetul avea probleme sa decida la ce era bun nivelul prezentare. Securitatea datelor si criptarea au fost atat de controversate, incat nimeni nu a putut fi de acord cu nivelul in care sa le introduca, asa ca au fost lasate pe dinafara. De asemenea, administrarea retelei a fost omisa din model din motive similare.

O alta critica asupra standardului initial se refera la ignorarea completa a serviciilor si protocoalelor fara conexiune, in pofida faptului ca majoritatea retelelor functioneaza in acest mod. In consecinta, addenda care a urmat (cunoscuta in lumea programatorilor drept fixarea erorilor) a corectat aceasta problema.

Cea mai serioasa critica este, probabil, ca modelul reflecta o mentalitate dominata de problema comunicatiilor. Relatia dintre calcul si comunicare nu este mentionata aproape deloc, iar o parte din alegerile facute sunt total nepotrivite pentru modu in care lucreaza calculatoarele si programele. Ganditi-va, de exemplu, la primitivele OSI, listate in figura 1.14. In particular, ganditi-va atent cum ar putea cineva sa foloseasca aceste principii intr-un limbaj de programare.

Primitiva Connect.request e simpla. Ne putem imagina o procedura de biblioteca, connect, pe care programul o apeleaza ca sa stabileasca o conexiune. Acum ganditi-va la CONNECT.indication. Cand soseste un mesaj, trebuie anuntat procesul destinatie. Mai precis, trebuie sa primeasca o intrerupere - un concept rareori adecvat in programele scrise intr-un limbaj modern de nivel inalt. Desigur, la nivelul cel mai de jos trebuie sa se produca o indicatie (intrerupere).

Daca programul asteapta sa soseasca pentru el un apel, atunci ar putea sa invoce o procedura de biblioteca receive care sa il blocheze. In acest caz, de ce nu a fost receive primitiva conceputa in locul lui indication ? Receive este clar orientata spre modul de lucru al calculatoarelor, in timp ce indication este la fel de clar orintata spre modul de lucru al telefoanelor. Calculatoarele sunt diferite fata de telefoane. Telefoanele suna. Calculatoarele nu suna. Pe scurt, modelul semantic al unui sistem bazat pe intreruperi reprezinta din punct de vedere conceptual o idee proasta si in totala contradictie cu toate ideile moderne despre programarea structurata. Aceasta problema si altele similare sunt discutate de catre Langsford (1984).

Implementari proaste

Data fiind enorma complexitate a modelului si a protocoalelor, nu este nici o surpriza in faptul ca implementarile initiale erau uriase, greoaie si ineficiente. Oricine le incerca se simtea ca oparit. Nu a trecut mult si lumea a asociat "OSI" cu "calitate slaba". Odata cu trecerea timpului, produsele au devenit mai bune, dar imaginea s-a deteriorat.

Din contra, una din primele implementari de TCP/IP facea parte din Berkeley UNIX® si era destul de buna (ca sa nu mai spunem ca era si gratuita). Lumea a inceput sa o foloseasca repede, ceea ce a determinat aparitia unei comunitati largi de utilizatori, ceea ce a dus mai departe la imbunatatiri, iar aceasta a dus la o comunitate si mai numeroasa. In acest caz spirala nu cobora, ci urca.

Politici proaste

Din cauza implementarii initiale, multa lume, in special din mediul academic, a considerat TCP/IP ca o parte din UNIX; iar in anii `80 Unix-ul era pentru oamenii din lumea academica cam la fel de popular ca paternitatea (numita apoi incorect maternitate) sau ca placinta cu mere.

OSI, pe de alta parte, a fost gandit ca o creatie a ministerelor de telecomunicatii europene, apoi a Comunitatii Europene si, mai tarziu, a guvernului Statelor Unite. Aceasta viziune s-a dovedit adevarata numai in parte; dar chiar ideea in sine - un grup de birocrati guvernamentali incercand sa bage un standard inferior tehnic pe gatul bietilor cercetatori si programatori care stau in transee si dezvolta efectiv retelele de calculatoare - nu a ajutat prea mult. Unii oameni au vazut aceasta abordare in aceeasi lumina in care a fost vazuta IBM cand a anuntat in anii `60 ca PL/I era limbajul viitorului, sau DoD care a conectat IBM-ul anuntand ca de fapt limbajul respectiv era de fapt Ada®.

In pofida ca modelul si protocoalele OSI, in special PTT-urile europene care detin inca un monopol asupra telecomunicatiilor. In consecinta, a existat un mic efort pentru a imbunatatii OSI si rezultatul este un model revizuit publicat in 1994. Pentru a vedea ceea ce a fost schimbat (putin) si ceea ce ar fi trebuit schimbat (mult), a se consulta (Day, 1995).