CAP.

1 ARHITECTURI DE REŢELE DE COMUNICAŢII ŞI

ARHITECTURA INTERNET

1.1 TRANSMISIUNI DE DATE. COMUNICAŢII DE DATE

Transmisiuni de date înseamnă transferul datelor dintr-un punct către unul sau
mai multe puncte prin mijloace de telecomunicaţii.
Comunicaţii de date înseamnă transferul datelor între unităţi funcţionale, efectuat
conform unui ansamblu de reguli privind transmisiunea datelor şi coordonarea
schimbului de date.
Comunicaţiile de date au un înţeles mai larg decât transmisiunile de date,
incluzând nu numai transmisia electrică ci şi mulţi alţi factori implicaţi în controlul,
verificarea şi coordonarea transmiterii informaţiei într-un sistem de calcul bazat pe
comunicaţii. Ele includ, spre exemplu:
- reţele, sisteme şi circuite de transmisiune;
- componente hardware şi software necesare pentru realizarea funcţiunilor pentru
comunicaţii de date;
- standarde pentru interfaţarea echipamentului de utilizator la reţeaua de transmisiune;
- o diversitate de reguli şi proceduri (protocol de comunicaţie) pentru a asigura un schimb
disciplinat al informaţiei.
Unităţile funcţionale între care se face transferul datelor mai sunt numite generic şi
staţii de date. O staţie de date furnizează date pentru transmisiune, este deci sursă de date,
acceptă datele transmise de o altă staţie de date, este deci şi colector de date şi realizează
toate funcţiunile pentru comunicaţia cu o altă staţie de date.
În figura 1.1 este prezentată schematic o legătură de date – ansamblu compus din
elementele a două echipamente terminale de date (DTE – Data Terminal Equipment) care
sunt controlate de un protocol şi care, prin intermediul circuitului de date ce le
interconectează, permit împreună transferul datelor. Echipamentul terminal de date este
acea parte a unei staţii de date care serveşte ca sursă de date, ori colector de date, sau şi
una şi alta. Echipamentul de terminaţie a circuitului de date (DCE – Data Circuit-
terminating Equipment) este o parte a staţiei de date care asigură conversia şi codarea
semnalelor între DTE şi linie. El poate fi un echipament separat sau poate fi integrat în
DTE sau într-un echipament intermediar. În multe aplicaţii acest echipament este numit
modem, după numele a două funcţiuni pe care le realizează, modulare şi demodulare.

Staţie de date Interfaţa

DCE-DTE

DTE DCE DCE DTE

Circuit de date
Legătură de date

Fig. 1.1 Legătura de date

1
1.2 COOPERAREA ŞI SCHIMBUL DE DATE ÎNTRE CALCULATOARE
Prin cooperarea între procese de aplicaţie care rulează în două sau mai multe
calculatoare sunt oferite diferite servicii utilizatorilor. Astfel se poate realiza transferul
unui fişier de la un calculator la altul, se poate accesa de la distanţă o bază de date, se pot
transmite mesaje, se pot utiliza resursele hardware şi software ale unui supercalculator, se
poate partaja utilizarea unor periferice costisitoare, etc.
Schema simplificată a comunicaţiei între două sisteme de calcul este prezentată în
figura 1.2. Două procese de aplicaţii, ce se desfăşoară în două calculatoare, cooperează şi
comunică între ele prin intermediul subsistemelor de comunicaţii, având componente
hardware şi software, instalate în aceste calculatoare. La rândul lor, subsistemele de
comunicaţii comunică între ele prin intermediul unei reţele de comunicaţii de date.

Calculator A Calculator B

Comunicaţie
PA PA
utilizator - utilizator

Subsistem de Comunicaţie Subsistem de

comunicaţii calculator-calculator comunicaţii

Comunicaţie calculator-reţea
Reţea pentru comunicaţii de date

PA - Proces de aplicaţie

Fig. 1.2 Schema comunicaţiei între două calculatoare

Subsistemele de comunicaţii permit schimbul de date între procesele de aplicaţie

care se execută în calculatoare. Există o gamă largă de echipamente de comunicaţii ce
pot fi utilizate, fiecare fiind destinat unei aplicaţii specifice. Spre exemplu, dacă se
transferă un fişier dintr-un calculator în altul similar, aflat în aceeaşi încăpere, mijloacele
de comunicaţie utilizate vor fi mult mai simple decât cele necesare în cazul transferului
între calculatoare diferite plasate în locuri distante. Indiferent însă de tipul mijloacelor de
comunicaţie utilizate, în cele mai multe aplicaţii datele sunt transmise între calculatoare
în modul serial (bit cu bit). Cum în interiorul calculatorului datele sunt transferate, între
subsistemele acestuia, în modul paralel (simultan toţi biţii unui cuvânt) este necesară
conversia paralel-serie înainte de transmiterea datelor de la calculator şi conversia serie-
paralel înainte de recepţia datelor de către calculator. De asemenea, modul de
transmisiune şi circuitul de date necesar depind de separarea fizică a calculatoarelor şi de
debitul datelor.
În transmiterea datelor pe mediul de transmisiune este posibil să apară erori. Este

2
necesar, prin urmare, să se realizeze o funcţie de control al erorii pentru a detecta şi a
corecta erorile apărute. O altă funcţie, de control al fluxului, este utilizată pentru a regla
ritmul în care sunt transferate datele. Dacă între cele două calculatoare comunicaţia
urmează a se stabili prin intermediul unei reţele de date va fi necesară o funcţie de rutare
pentru a alege o rută prin care să se transfere datele.
În unele aplicaţii calculatoarele care sunt în comunicaţie pot fi de tipuri diferite, cu
reprezentări diferite pentru caractere şi valori numerice. Va fi nevoie în aceste cazuri de o
funcţie care să asigure că datele transferate sunt interpretate în acelaşi fel în fiecare
calculator. De asemenea, calculatoarele pot utiliza sisteme de operare diferite, ceea ce
înseamnă că interfeţele între programele de aplicaţie (de utilizator) şi serviciile de
comunicaţie calculator-calculator vor fi diferite. Este evident că şi astfel de aspecte
trebuie avute în vedere pentru realizarea comunicaţiiloe între calculatoare.

1.3 REŢELE PENTRU COMUNICAŢII DE DATE

1.3.1. Introducere în reţelele de date
Configuraţiile reţelelor utilizate pentru comunicaţiile de date depind de natura
aplicaţiei (legătură punct-la-punct, legătură multipunct), numărul calculatoarelor
implicate, distanţa între calculatoare, etc. În cele ce urmează vor fi prezentate câteva
situaţii tipice.
Pentru comunicaţia între două calculatoare, mereu aceleaşi, situate la mică
distanţă unul de altul (în aceeaşi cameră) se utilizează o legătură simplă, punct-la-punct,
prin fire (Fig. 1.3, a). Dacă ele sunt distanţate se utilizează suport de transmisiune oferit
de reţeaua de telecomunicaţii. Frecvent este utilizată în acest scop reţeaua telefonică
publică cu comutaţie (PSTN – Public Switched Telephone Network) şi este nevoie de un
echipament, numit modem, pentru a adapta semnalele ce reprezintă datele la
caracteristicile liniei de transmisiune (Fig. 1.3, b).
Calculator Calculator Calculator Calculator

PA PA PA PA

Subsistem de Subsistem de
Subsistem Subsistem comunicaţii comunicaţii
de de
Modem PST Modem

a) b)

3
 LAN 2

P
LAN 1

P Artera principală P
(backbone)
P - Pod
LAN 3
c)

Fig. 1.3 Scheme de comunicaţie între calculatoare:

(a) legătură punct la punct directă;
(b) legătură prin PSTN şi modemuri;
(c) reţele LAN interconectate.

Dacă într-o aplicaţie sunt implicate mai multe calculatoare se va utiliza o reţea
care să permită tuturor calculatoarelor să comunice unul cu altul. Dacă aceste
calculatoare sunt distribuite într-o zonă relativ restrânsă, într-o clădire sau în mai multe
clădiri apropiate, se poate instala o reţea proprie (Fig. 1.3, c) - LAN (Local Area
Network). Reţelele locale situate la distanţe mari una de alta pot fi interconectate folosind
canale de comunicaţii oferite de reţeaua de telecomunicaţii publică, rezultând o reţea ce
acoperă o arie mare (WAN – Wide Area Network). O astfel de soluţie este recomandabilă
în cazurile în care traficul între reţelele interconectate este mare.
Reţelele de date s-au dezvoltat ca urmare a aplicaţiilor economice scrise pentru
microcomputer. La acea vreme microcomputerele nu erau conectate, aşa că nu exista o
cale eficientă pentru împărtăşirea datelor peste o mulţime de microcomputere.
Împărtăşirea datelor cu ajutorul floppy diskurilor era o manieră ineficientă, mai ales în
mediul economic. Fiecare dintre cei care modificau un fişier trebuia să îl distribuie
tuturor celorlalţi. Dacă două persoane modificau acelaşi fişier, una dintre variante se
pierdea. Mediul economic necesita o soluţie care să îndeplinească trei deziderate:
- Să împiedice duplicarea resurselor,
- Să comunice efficient,
- Să pună în funcţiune şi să administreze o reţea.
La începutul anilor 80 s-au dezvoltat reţele de calculatoare, dar într-un mod
dezorganizat, fiecare companie realizând propria reţea. Fiecare companie de hard sau soft
realiza propriile produse, după propriile standarde. Aceste standarde individuale se
dezvoltau ca urmare a competiţiei între companii. Ca o consecinţă, multe dintre
specificaţii nu erau compatibile unele cu altele. A devenit dificil ca reţelele diferite să
comunice între ele. Prima soluţie a fost crearea unor standarde pentru reţele locale.
Deoarece aceste standarde permiteau un ghid deschis de urmat în crearea de produse hard
şi soft, echipamentele diferitelor companii au început să devină compatibile. S-a ajuns
astfel la o stabilitate în implementarea LAN-urilor.

4
 Într-un sistem LAN, fiecare departament este un fel de insulă electronică. Întrucât
utilizarea computerelor a cunoscut o creştere importantă, a devenit evident că LAN-urile
nu erau suficiente. A devenit necesar ca informaţia să se deplaseze eficient şi rapid nu
numai în interiorul companiei, ci şi între companii. Soluţia a constituit-o crearea de reţele
metropolitane (metropolitan-area networks (MANs)) şi de reţele întinse wide-area
networks (WANs).
O prezentare a tipurilor de reţele şi a dimensiunilor lor este prezentată în figura 1.4

Fig. 1.4 Tipuri de rețele

1.3.2. Foarte scurt istoric al reţelelor:

-1957. Departamentul Apărării SUA a creat prima reţea de calculatoare ARPA
-1962 primele preocupări privind comutarea de pachete
-1969 la ARPANET se conectează primele patru universităţi americane
-1973 se lucrează la ceea ce apoi va fi TCP/IP; ARPANET devine internaţională
prin conectarea la ea a unei universităţi din Londra şi a uneia din Oslo.
-1974 prima versiune comercială a ARPANET
-1981 apare termenul Internet pentru conectarea unui set de reţele
-1983 TCP/IP devine limbaj universal pentru Internet
-1984 se fondează CISCO Szstems- apar primele gateway-uri şi rutereş Internetul
avea 1000 hosturi
-1987 Internetul avea 10.000 hosturi.
-1989 Internetul avea 100.000 hosturi.
-1990 ARPANET devine Internet
-1991 apare World Wide Web (www).
-1992 Internetul are 1.000.000. hosturi
-1994 apare Netscape Navigator

5
 -1996 peste 10.000.000 utilizatori Internet
-2001 peste 110.000.000 utilizatori Internet
-De atunci are loc o creștere exponențială – numărul utilizatorilor se dublează la
fiecare 6 luni

1.3.3. Echipamente de rețea.

Echipamentele care asigură conectarea directă la un segment de rețea sunt referite
ca dispozitive (device). Aceste dispozitive sunt împărțite în două clase. Prima clasă
presupune dispozitive de capăt (end-user devices) . Acestea includ computere,
imprimante, scannere, și alte dispozitive care permit conectarea directă. A doua clasă este
cea a dispozitivelor de rețea, incluzând toate dispozitivele care conecteză dispozitivele de
capăt care le permite acestora să comunice.
Dispozitivele de capăt care permit utilizatorului conectarea la rețea sunt referite ca
hosturi (gazde). Aceste dispozitive permit utilizatorilor să împărtășească, creeze, și obține
informații. Hosturile pot exista și în afara rețelei, dar capabilitățile lor scad semnificativ.
Hosturile sunt conectate la rețea printr-un card de interfață cu rețeaua (network interface
card (NIC)). NIC este un cablaj imprimat care se fixează într-un slot al plăcii de bază a
computerului. Fiecare NIC are propriul cod, numit adresă Media Acces Control (MAC).
Așa cum arată numele, NIC controlează accesul hostului la mediu.
Nu există simboluri standardizate pentru echipamentele de capăt. Reprezentarea
lor se face printr-un desen similar dispozitivului real, permițând o recunoaștere rapidă.
Dispozitivele de rețea permit transportul datelor care trebuie transferate între
hosturi. Dispozitivele de rețea furnizează extensia conexiunilor prin cablu, concentrarea
conexiunilor, conversia formatelor de date, managementul transferului de date.
Aceste dispozitive sunt prezentate în figura 1.5.

Fig. 1.5 Dispozitive utilizate în rețele

6
 - Repetorul: dispozitiv utilizat pentru regenerarea semnalului. Repetoarele
regenerează semnale analogice sau digitale distorsionate datorită atenuării mediului de
transmisiune. Repetorul nu poate face o rutare inteligentă.
- Hub-urile concentreză conexiunile. Ele grupează hosturile și permit rețelei să le
vadă ca pe un singur dispozitiv. Acțiunea se realizează în mod pasiv, fără nici un efect în
transmisia datelor. Există și hub-uri active, care, pe lângă concentrarea conexiunilor
realizează și regenerarea semnalului.
- Bridge-urile fac conversii ale formatelor de date, realizând și management de bază
al transmisiei datelor. Așa cum le spune și numele, acestea realizează conectarea între
LAN-uri. Bridge-urile realizează o v erificare a datelor transmise, pentru a vedea dacă
permit trecerea dintr-un LAN în altul. Ca urmare, părțile rețelei devin mai eficiente.
- Switch-urile aduc un plus de inteligență în managementul transferului datelor. Ele
nu numai că determină dacă datele rămân sau nu într-un LAN, dar ele pot transfera datele
numai pe conexiunea dorită. Altă diferență față de bridge este aceea că switch-ul nu poate
face conversie de format.
- Ruterele au toate capabilitățile enumerate până acum. Pot regenera semnale,
concentra conexiuni multiple, realiza conversia formatelor datelor, manageria transferul
de date. Ele se pot conecta și la WAN-uri, permițând legături între LAN-uri aflate la
distanțe geografice mari. Nici un alt dispozitiv nu poate furniza acest tip de conexiune.
Pe de altă parte, pentru aplicaţiile în care sunt implicate calculatoare aflate la
distanţe mari unele de altele se pot utiliza reţelele publice de date, elaborate special
pentru a transmite date. Pentru astfel de reţele sunt standardizate interfeţele utilizator-
reţea (figura 1.6).

Calculator Calculator Calculator

SC SC SC

interfață utilizator-rețea
PSDN
SC – subsistem de comunicaţie

Fig. 1.6 Reţea publică de date

Prin digitalizarea completă a reţelei telefonice, nu numai a comutaţiei în centralele

telefonice şi a transmisiunii pe liniile de interconexiune şi de mare distanţă, ci şi a
transmisiunii pe liniile de abonat, va fi posibilă transmiterea semnalelor ce reprezintă
voce, date, imagini utilizând acelaşi tip de echipamente. O astfel de reţea, care
funcţionează complet digital, este numită reţea digitală cu integrarea serviciilor (ISDN –
Integrated Services Digital Network).
Desigur, sunt cazuri în care nu toate calculatoarele implicate într-o aplicaţie sunt
conectate la aceeaşi reţea, ci la reţele diferite: LAN, WAN, reţele publice de date, ISDN.

7
1.4 MODELUL DE REFERINŢĂ AL INTERCONECTĂRII SISTEMELOR
DESCHISE (OSI-RM)

Compatibilitatea între sistemele eterogene dintr-o reţea de comunicaţii poate fi

asigurată numai prin definirea unor norme de interconexiune pe care trebuie să le
respecte fiecare sistem.
Pentru compatibilitate maximă, minimizând in acelaşi timp constângerile impuse
fiecărui sistem, ISO (International Organization for Standardization) şi ITU-T
(International Telecommunications Union – Telecommunications Standardization Sector,
fost CCITT) au stabilit un model de referinţă (RM-Reference Model) al interconectării
sistemelor deschise (OSI-Open Systems Interconnection). Acest model de referinţă
constituie o bază comună pentru coordonarea elaborării standardelor privind
interconectarea sistemelor.
Sistemele de comunicaţii care folosesc metodele şi procedurile de comunicaţii
normalizate, derivând din modelul de referinţă, sunt numite uneori sisteme deschise
deoarece, respectând aceleaşi reguli pentru schimbul de informaţii între ele, sunt deschise
unul faţă de altul, este posibilă comunicaţia între ele.
Un sistem deschis este reprezentarea, în cadrul modelului de referinţă, a acelor aspecte
ale unui sistem deschis real care corespund standardelor OSI.
OSI are în vedere numai interconectarea sistemelor deschise nu şi funcţionarea internă
a fiecărui sistem deschis real. Interconectarea sistemelor deschise priveşte transferul
informaţiei între sisteme şi capacitatea acestora de a coopera pentru a îndeplini o sarcină
comună.
Sunt foarte dificile elaborarea şi implementarea unui singur protocol care să includă
toate funcţiunile necesare într-o reţea de comunicaţii între calculatoare. Dar, din punct de
vedere logic, ansamblul acestor funcţiuni poate fi împărţit în două categorii,
corespunzând celor două sarcini principale pe care trebuie să le asigure reţeaua: transferul
informaţiei şi prelucrarea informaţiei.
Soluţionarea acestor probleme poate fi uşurată prin ordonarea lor pe baza principiilor
de ierarhizare şi descentralizare. Organizarea ierarhică şi descentralizată facilitează
studiul şi realizarea reţelelor, simplifică funcţionarea lor prin utilizarea unor reguli
formale, îmbunătăţeşte fiabilitatea prin compartimentarea strictă a funcţiunilor şi asigură,
datorită modularităţii create, facilităţi de extensie.
Toate aceste considerente au condus la definirea unei arhitecturi de reţea care nu este
nici un produs hardware, nici un produs software, ci un concept de organizare hardware şi
software cu ajutorul unei structuri ierarhizate stratificate (figura 1.7).
Subsistemul de comunicaţie este considerat ca un ansamblu format din mai multe
nivele (straturi), fiecare nivel realizând funcţiuni bine definite. Fiecare nivel dintr-un
subsistem de comunicaţii realizează funcţiunile sale în cooperare cu nivelul omolog din
sistemul corespondent. Cooperarea se realizează prin schimbul de mesaje între cele două
nivele omoloage, schimb de mesaje efectuat conform unor reguli ce constituie un
protocol de comunicaţie. Acest schimb de mesaje se face prin intermediul serviciului
oferit de nivelul imediat inferior.

8
 Serviciul N
N+1 Protocol N N+1
N N
N−1 N−1
Serviciul (N−1)

Mediul de transmisiune

Fig. 1.7 Relaţia între nivele în cazul unei structuri stratificate

Relaţia între nivelurile adiacente şi cu nivelul omolog din sistemul corespondent se
poate vedea în figura 1.7. Această relaţie este o relaţie logică, nu fizică. Nivelul (N−1)
oferă un serviciu nivelului N. Nivelul N, la rândul său, oferă, în colaborare cu nivelul
omolog din sistemul corespondent, un serviciu mai amplu nivelului (N+1), incluzând
serviciul oferit de nivelul (N−1). Modul în care nivelele adiacente comunică determină
interfaţa între aceste niveluri.
Serviciul furnizat de nivelul cel mai jos constă în transmiterea fizică prin reţea a
elementelor binare. Avansând spre nivelele superioare fiecare nivel adaugă funcţiuni noi
serviciului oferit de nivelele inferioare, aşa încât ultimul nivel, cel de sus în această
structură stratificată, permite proceselor de aplicaţie să coopereze, realizând sarcini de
prelucrare distribuită a informaţiei, indiferent de tipul calculatoarelor în care se
desfăşoară aceste procese.
Standardele relative la un astfel de model care are în vedere o arhitectură stratificată a
interconectării se referă la comportarea exterioară a elementelor din model şi nu la
structura lor internă; standardele specifică serviciile furnizate, definesc formatele
protocoalelor şi factorii ce permit interpretarea corectă a informaţiei transmise în cadrul
protocoalelor, dar nu impun modul în care acestea vor fi implementate într-un sistem
oarecare.
Arhitectura definită de modelul de referinţă OSI este constituită din suprapunerea a
şapte niveluri (figura 1.8), după principiul prezentat mai sus, numerotate de jos în sus şi
numite: fizic, legătură de date, reţea, transport, sesiune, prezentare, aplicaţie.
Aplicaţie 7 7
Prezentare 6 6
Sesiune 5 5
Protocol transport
Transport 4 4
Reţea 3 3 3 3
Legătură de date 2 2 2 2
Fizic 1 1 1 1

Suport fizic
Sisteme intermediare

Sisteme de extremitate
Fig. 1.8 Modelul de referinţă OSI

9
 Primele trei niveluri de jos sunt dependente de reţea şi protocoalele corespunzătoare
acestor nivele operează între sisteme adiacente. Este posibil ca între sistemele de
extremitate, cele în care rulează programele de aplicaţie a căror cooperare este asigurată
prin subsistemele de comunicaţie interconectate, să existe sisteme intermediare care
acţionează ca relee pentru datele transmise, dirijând datele de la un sistem la altul.
Nivelul cel mai înalt care poate participa la relizarea acestei funcţii de releu este nivelul 3
(reţea).
În determinarea celor şapte niveluri ale modelului de referinţă s-au avut în vedere mai
multe principii, ca de exemplu:
- să se creeze o frontieră (între două nivele) acolo unde descrierea serviciilor poate fi
concisă şi numărul interacţiunilor la traversarea acestei frontiere este minim;
- să se creeze nivele separate pentru funcţiuni care diferă prin prelucrarea efectuată sau
prin tehnologia utilizată;
- să se regrupeze funcţiuni similare în acelaşi nivel;
- să se creeze un nivel acolo unde este nevoie să se distingă o modalitate de
administrare a datelor (morfologică, sintactică, semantică);
- să fie posibilă efectuarea de modificări ale funcţiilor sau protocoalelor fără a afecta
alte nivele;
- pentru fiecare nivel să se creeze frontiere numai cu nivelele imediat inferior şi
superior.
Totodată s-a ţinut seama şi de următoarele considerente:
a) Este esenţial ca arhitectura să permită utilizarea unei varietăţi realiste de medii fizice
de interconexiune, asociate cu diferite proceduri de control. De aceea s-a ales nivelul fizic
ca nivelul cel mai de jos al arhitecturii.
b) Unele suporturi fizice de comunicaţii (spre exemplu liniile telefonice) necesită
folosirea de tehnici particulare pentru a transmite datele între sisteme, deoarece prezintă
un procent de erori mare, inacceptabil pentru majoritatea aplicaţiilor. Aceste tehnici
particulare sunt utilizate în procedurile de control al legăturii de date, care au fost deja
studiate şi normalizate. Trebuie, de asemenea, să se ţină seama că noile suporturi fizice
de comunicaţii, cum ar fi fibrele optice, vor necesita alte proceduri pentru controlul
legăturii. Aceste considerente au condus la identificarea unui nivel legătură de date,
deasupra nivelului fizic al arhitecturii.
c) Nivelul legătură de date asigură o conexiune numai între noduri adiacente ale reţelei;
pentru a stabili o conexiune cap-la-cap între terminale este nevoie de nivelul reţea care să
grupeze protocoalele de rutare. Nivelul reţea furnizează astfel o conexiune între entităţi
de transport, incluzând cazurile când intervin şi noduri intermediare.
d) Controlul trasportului datelor de la un sistem de extremitate, sursă, la un sistem de
extremitate, destinaţie, control care nu se face în nodurile intermediare, este ultima
funcţiune care trebuie realizată pentru a furniza integral serviciul transport. Nivelul cel
mai de sus al părţii care asigură serviciul de transport al arhitecturii este deci nivelul
transport, situat deasupra nivelului reţea. Acest nivel transport eliberează entităţile
nivelelor superioare de orice problemă privind transportul datelor între ele.
e) Deşi nivelul transport poate furniza o conexiune cap-la-cap fără erori (virtual),
asigurând retransmiterea informaţiei eronate sau pierdute, informaţia poate fi pierdută în
terminale datorită suprasaturării memoriilor. Mai mult, unele aplicaţii pot necesita ca
fluxul de informaţie între terminale să fie unidirecţional, bidirecţional alternant sau

10
bidirecţional simultan. Nivelul sesiune va furniza această funcţionalitate prin utilizarea
punctelor de sincronizare şi a jetoanelor. Punctele de sincronizare sunt înserate în fluxul
informaţiei la cererea entităţilor de aplicaţie şi, dacă este necesar, fluxul informaţiei poate
fi reluat de la un punct de sincronizare anterior.
f) Funcţiunile privind reprezentarea şi manipularea datelor structurate pentru scopul
programelor de aplicaţie au fost incluse în nivelul prezentare, aflat deasupra nivelului
sesiune.
g) Nivelul aplicaţie, cel mai de sus al arhitecturii, constituind unul din aspectele
proceselor de aplicaţie, conţine protocoalele care le servesc pentru a comunica.
Având în vedere cele de mai sus, funcţiunile celor şapte niveluri ale modelului de
referinţă OSI pot fi prezentate după cum urmează.
Nivelul cel mai de sus, aplicaţie (7), conţine entităţile de aplicaţie prin a căror
cooperare se asigură proceselor de aplicaţie mijloacele pentru accesul la mediul OSI.
Fiecare proces de aplicaţie este reprezentat pentru perechea sa printr-o entitate de
aplicaţie. Nivelurile inferioare furnizează serviciile prin intermediul cărora cooperează
entităţile de aplicaţie. Schimburile de informaţie între procesele de aplicaţie se realizeză
prin intermediul entităţilor de aplicaţie, al protocoalelor de aplicaţie şi al serviciilor
nivelului imediat inferior. Procesele de aplicaţie pot comunica după ce, în prealabil, prin
intermediul serviciilor oferite de nivelele inferioare, s-a stabilit o asociere (conexiune)
între entităţile de aplicaţie corespunzătoare.
Nivelul prezentare (6) se ocupă de reprezentarea informaţiei transferate între entităţile
de aplicaţie. Reprezentarea datelor poate diferi de la un calculator la altul. Numerele, spre
exemplu, sunt reprezentate prin cuvinte de 16 biţi sau 32 biţi, în complement de 1 sau de
2. Calculatoarele IBM folosesc codul EBCDIC pentru reprezentarea caracterelor, în timp
ce, practic, toate celelalte calculatoare folosesc codul ISO-7 (ASCII). Nivelele 1-5 au
sarcina de a oferi o transmisiune fiabilă a octeţilor, dar un acelaşi octet are semnificaţii
diferite de la un calculator la altul. Nivelul prezentare asigură o reprezentare comună a
datelor transferate între entităţile de aplicaţie. Acestea pot folosi orice sintaxă în
reprezentarea datelor, iar nivelul prezentare asigură transformarea dintre aceste sintaxe şi
sintaxa comună de transfer.
Prin urmare, există trei versiuni sintactice ale datelor: sintaxa utilizată de entitatea de
aplicaţie transmiţătoare, sintaxa utilizată de entitatea de aplicaţie receptoare şi sintaxa
utilizată între entităţile de prezentare (sintaxa de transfer). Nivelul prezentare posedă
funcţiunile necesare pentru a realiza transformarea între sintaxa de transfer şi sintaxa
utilizată de entitatea de aplicaţie.
Nu există o sintaxă de transfer unică, predeterminată. Sintaxa de transfer ce va fi
utilizată într-o conexiune prezentare este negociată între entităţile de prezentare
corespondente.
O altă funcţie a nivelului prezentare este legată de securitatea datelor. În unele
aplicaţii, datele transmise de o entitate aplicaţie sunt mai întâi criptate (cifrate), utilizând
o cheie şi sunt decriptate de entitatea prezentare corespondentă.
Nivelul sesiune (5) asigură mijloacele necesare pentru organizarea şi sincronizarea
dialogului dintre entităţile de prezentare cooperante, precum şi pentru administrarea
schimburilor de date dintre ele. Pentru a permite transferul datelor între entităţile de
prezentare se stabileşte o conexiune sesiune la cererea uneia dintre aceste entităţi. Nivelul
sesiune defineşte trei tipuri de dialoguri: bidirecţional simultan, bidirecţional alternant şi

11
unidirecţional. Serviciile nivelului sesiune includ stabilirea unor puncte de sincronizare în
cadrul dialogului, permiţând întreruperea unui dialog şi reluarea lui de la un punct de
sincronizare.
Procesul de aplicaţie (utilizator)

Servicii de informaţie distribuită

Transfer fişiere, acces şi administrare, schimb de mesaje 7. Nivelul

aplicaţie

Serviciul de schimb de mesaje independent de

sintaxă

Negocierea sintaxei de transfer, transformările de 6. Nivelul

reprezentare a datelor prezentare

Sincronizarea dialogului între entităţile de aplica\ie 5. Nivelul

sesiune

Serviciul de schimb de mesaje independent de reţea

Transferul mesajului cap-la-cap (administrarea 4. Nivelul

conexiunii,controlul erorii,fragmentarea, controlul fluxului) transport

Rutarea şi adresarea în reţea, stabilirea şi eliberarea 3. Nivelul

conexiunii reţea

Controlul legăturii de date (structurarea în cadre, 2. Nivelul

transparenţa datelor, controlul erorii) legătură de date

Definirea caracteristicilor mecanice şi electrice ale interfeţei 1. Nivelul

cu reţeaua fizic

Conexiunea fizică la echipamentul de terminaţie al

reţelei

Reţeaua de comunicaţii de date

Fig. 1.9 Funcţiunile nivelurilor din modelul de referinţă

Nivelul transport (4) asigură transferul transparent al datelor între entităţile de

sesiune. El optimizează utilizarea serviciului reţea disponibil, pentru a asigura, cu un cost
minim, performanţa cerută de fiecare entitate sesiune. Toate protocoalele definite la
nivelul transport au o semnificaţie cap la cap, indiferent de releele intermediare pe care,
eventual, datele le traversează. Pentru nivelele inferioare protocoalele acţionează între
sisteme vecine şi nu între sistemele de extremitate.

12
 Calitatea serviciului conexiunii transport este negociată între entităţile de sesiune şi
serviciul transport. În momentul stabilirii unei conexiuni transport se poate selecta, dintr-
un ansamblu definit de clase de serviciu disponibile, clasa serviciului de transport ce
urmează a fi furnizat.
Conexiunea tipică de transport constă într-o legătură punct la punct, asigurând la
destinaţie mesajele în ordinea în care au fost emise. Alte tipuri de servicii posibile permit
transportul de mesaje izolate, fără a garanta ordinea lor la recepţie şi difuzarea mesajelor
către mai mulţi destinatari. Tot la nivelul transport se poate asigura un control al erorii
cap la cap.
Nivelul reţea (3) furnizează, pe de o parte, mijloacele pentru a stabili, a menţine şi a
elibera conexiunile reţea între sisteme deschise conţinând entităţi de aplicaţie ce trebuie
să comunice, precum şi, pe de altă parte, mijloacele funcţionale şi procedurale pentru
schimbul unităţilor de date ale serviciului reţea, pe conexiuni reţea, între entităţi de
transport. Nivelul reţea asigură entităţilor de transport independenţa faţă de problemele de
rutare şi de releu legate de stabilirea şi funcţionarea oricărei conexiuni de reţea, inclusiv
în cazul în care sunt utilizate în tandem mai multe subreţele. El conţine funcţiunile
necesare pentru a masca, pentru nivelul tansport, diferenţele dintre caracteristicile
diferitelor tehnologii de transmisiune şi de subreţele, asigurând un serviciu de reţea
coerent. Entităţile de transport se identifică prin adresele de reţea care, în fapt, identifică
în mod unic fiecare sistem de extremitate (reprezentate prin entităţi de transport).
Nivelul legătură de date (2) furnizează mijloacele funcţionale şi procedurile necesare
pentru stabilirea, menţinerea şi eliberarea conexiunilor legătură de date între entităţi de
reţea, precum şi pentru transferul unităţilor de date ale serviciului legătură de date. O
conexiune legătură de date este realizată cu ajutorul uneia sau al mai multor conexiuni
fizice. Sarcina principală a nivelului legătură de date este de a prelua un mijloc de
transmisiune “brut” (cel fizic) şi a-l transforma într-o cale de comunicaţie ce pare, pentru
nivelul reţea, scutită de erori. El realizează această funcţiune prin formatarea datelor de
transmis în cadre (de câteva sute de octeţi), transmiterea cadrelor în succesiune şi
administrarea cadrelor de confirmare transmise de receptor. Dacă un cadru este perturbat
în transmisiunea sa el trebuie retransmis.
Transmisiunile repetate ale aceluiaşi cadru pot provoca duplicate (spre exemplu, dacă
nu este recepţionat un cadru de confirmare). Problemele privind cadrele eronate, pierdute
sau duplicate sunt rezolvate de nivelul legătură de date. Mecanismul prin care se rezolvă
aceste probleme este asfel conceput încât, simultan, cu ajutorul lui, se face şi un control al
fluxului pentru a evita saturarea unui receptor lent de către un emiţător mai rapid.
Nivelul fizic (1) furnizează mijloacele mecanice, electrice, funcţionale şi procedurale
necesare activării, menţinerii şi dezactivării conexiunilor fizice destinate transmiterii
biţilor între entităţi ale legăturii de date. O conexiune fizică poate implica mai multe
sisteme deschise intermediare, fiecare constituind un releu pentru transmiterea biţilor în
cadrul nivelului fizic. Nivelul fizic trebuie astfel conceput încât biţii transmişi de la un
capăt al conexiunii fizice să fie recunoscuţi ca atare la celălalt capăt. La acest nivel se pun
deci probleme de genul următor: cum se reprezintă biţii, durata fiecărui bit, posibilitatea
de a transmite în cele două sensuri simultan, iniţializarea conexiunii şi eliberarea ei când
cele două părţi au terminat, tipul conectorilor utilizaţi, suportul fizic utilizat etc.

13
 Calea de comunicaţie în mediul fizic pentru OSI, între două entităţi fizice, împreună
cu facilităţile necesare în nivelul fizic pentru transmiterea biţilor pe această cale, se
numeşte circuit de date .

1.5 ARHITECTURA TCP/IP (INTERNET)

Stivele de protocoale sunt colecții de protocoale care validează comunicarea prin rețea
de la un host la altul. Un protocol este o descriere formală a unui set de reguli și convenții
care guvernează un aspect particular al modului în care comunică dispozitivele.
Protocoalele determină formatul, limitele de timp, secvențarea, controlul erorilor în
comunicațiile de date. Fără protocoale, computerele nu ar fi capabile să reconstituie în
formatul original șirurile de biți venind de la un alt computer .
Protocoalele controlează toate aspectele comunicației de date, incluzând:
- Cum se construiește fizic o rețea,
- Cum se conectează computerele la rețea,
- Cum se formatează datele în vederea transmiterii,
- Cum sunt transmise datele,
- Cum sunt prelucrate datele.
Aceste reguli de realizare a rețelelor sunt create și administrate de mai multe
organizații și comitete diferite. Dintre acestea, Institute of Electrical and Electronic
Engineers (IEEE), American National Standards Institute (ANSI), Telecommunications
Industry Association (TIA), Electronic Industries Alliance (EIA) and the International
Telecommunications Union (ITU), formerly known as the Comité Consultatif
International Téléphonique et Télégraphique (CCITT).
Arhitectura stratificată a unei reţele TCP/IP este prezentată, prin comparaţie cu
modelul OSI, în figura 1.10.

7 Aplicaţie
Aplicaţie Servicii şi protocoale de
6 Prezentare aplicaţii
5 Sesiune
4 Transport Transport TCP UDP
3 Reţea Internet IP ICMP ARP RARP Pr.rut.
2 Legătură de date Interfaţă reţea Driver reţea
Placa interfaţă reţea (NIC)
1 Fizic Hardware

Model OSI Arhitectura Protocoale şi componente TCP/IP

stratificată TCP/IP
TCP - Transmission Control Protocol ICMP - Internet Control Message Protocol
UDP - User Datagram Protocol ARP - Address Resolution Protocol
IP - Internet Protocol RARP - Reverse Address Resolution Protocol

Fig. 1.10 Arhitectura TCP/IP

14
 Nivelul interfaţă reţea acceptă mesajele de la nivelul internet şi le pregăteşte pentru
transmiterea pe un anumit tip de legătură de date (reţea fizică). Pe de altă parte nivelul
interfaţă reţea analizează fiecare cadru recepţionat de placa NIC şi determină, după biţii
de control ai cadrului, care este protocolul de nivel internet căruia trebuie să i se transmită
datele din cadrul recepţionat.
Nivelul internet realizează funcţiunile de rutare şi de releu pentru transmiterea
pachetelor de la sistemul sursă la sistemul destinaţie. La acest nivel se utilizează mai
multe protocoale, dintre care se remarcă potocolul Internet (Internet Protocol - IP) care
asigură un serviciu de transmitere a datelor fără conexiune. IP asigură transmiterea de
blocuri de date între calculatoare identificate prin adresa de lungime fixă.
Protocolul ICMP (Internet Control Message Protocol) este protocolul pentru
transferul mesajelor de control într-o rețea. Acesta foloseşte serviciile IP (mesajul ICMP
ocupă câmpul de date al IP) asigurând un mecanism prin care ruterele şi sistemele din
reţea comunică informaţii privind situaţiile de funcţionare anormală. Asigură un număr
de funcții de diagnosticare și poate transmite pachete de anunțare a diferitelor evenimente
cum ar fi modificarea rutării în rețea, echilibrarea vitezei de transmisie între două hosturi
de capacități diferite, etc.
Protocolul ARP (Address Resolution Protocol) este folosit doar pentru rețele Ethernet
şi permite unui sistem să determine adresa fizică (MAC) a unui alt sistem din aceeaşi
reţea fizică cunoscând adresa IP (de nivel reţea) a acestuia.
Protocolul RARP (Reverse Address Resolution Protocol) permite unui sistem să-şi
obţină, atunci când n-o cunoaşte, adresa IP proprie.
Nivelul transport asigură comunicaţia între programele de aplicaţie. O astfel de
comunicaţie este numită adesea comunicaţie cap - la - cap. Nivelul transport poate regla
fluxul datelor, poate asigura livrarea datelor fără erori şi în secvenţă. La nivelul transport
fluxul datelor ce trebuie transmise se împarte în pachete şi fiecare pachet este trecut,
împreună cu adresa de destinaţie, către nivelul internet pentru transmisiune. Când mai
multe programe de aplicaţie beneficiază, în acelaşi sistem, de serviciile reţelei, nivelul
transport trebuie să accepte datele de la acestea şi să le treacă spre nivelul inferior,
adăugând fiecărui mesaj informaţia necesară pentru identificarea programelor de
aplicaţie.
Sunt folosite două protocoale de transport: UDP (User Datagram Protocol) şi TCP
(Transmission Control Protocol). Protocolul UDP asigură un serviciu fără conexiune
folosind IP pentru transportul mesajelor. Acest protocol, mai simplu decât TCP, nu
garantează livrarea mesajului la recepţie fără erori, fără pierderi, fără duplicate, în ordinea
în care au fost emise. Programele de aplicaţie care utilizează UDP ar trebui să-şi asume
responsabilitatea deplină pentru soluţionarea acestor aspecte ale transmisiunii.
Protocolul TCP asigură un serviciu cu conexiune, asigurind un transfer fiabil, fără
erori, in secventa si cu eliminarea pachetelor duplicate.
La elaborarea unui program de aplicaţie se alege protocolul de transport în funcţie de
necesităţile impuse de aplicaţie.
Nivelul aplicaţie asigură utilizatorilor reţelei, prin intermediul programelor de
aplicaţie, o gamă largă de servicii. Dintre acestea cele mai frecvent folosite sunt SMTP
(Simple Mail Transfer Protocol), FTP (File Transfer Protocol), Telnet Remote Login,
SNMP (Simple Network Management Protocol), DNS (Domain Name System - sistemul

15
numelor pentru domenii), PING (Packet InterNet Groper), HTTP (HyperText Transfer
Protocol).
Protocolul SMTP este folosit pentru transferul mesajelor de poştă electronică. Este
folosit pentru a trimite, recepționa și ruta mesajele (scrisorile) în cadrul rețelelor oricât de
mari, ajungând să fie protocolul (de facto) pentru e-mail-ul din Internet.
Protocolul FTP permite utilizatorilor transferul de fişiere, în ambele sensuri, între un
sistem local şi unul distant. Fişierele pot conţine fie texte (caractere ASCII sau EBCDIC),
fie date pur binare.
Protocolul Telnet permite unui utilizator să se identifice într-un sistem distant prin
intermediul sistemului local. Acest protocol stabileşte o relaţie client - server între
sistemul local (client) şi aplicaţia Telnet distantă (server), permiţând deci funcţionarea
unui sistem local în regim de terminal virtual conectat la un sistem distant.
Protocolul SSH (Secure SHell) ofera servicii similare cu Telnet, și servicii în plus.
Chiar dacă în esență el este o "dezvoltare" a altui protocol (RSH - Remote Shell), practic
însă este folosit mai ales ca înlocuitor al lui Telnet pentru că oferă o autentificare mult
îmbunătățită și, în plus, criptarea datelor.
Protocolul SNMP este folosit pentru administrarea de la distanţă a echipamentelor de
interconectare a reţelelor.
Protocolul DNS asigură serviciul director care menţine corespondenţa şi face
translatarea între numele date de utilizatori sistemelor lor conectate la reţea şi adresele de
reţea (IP) ale acestora.
Protocolul SNMP asigură un serviciu care permite realizarea unor funcţiuni de
administrare a reţelei.
Protocolul HTTP asigură un serviciu de transfer al informaţiei în reţeaua globală
(WWW – World Wide Web) reprezentată într-un limbaj specific, HTML (HyperText
Markup Language). Aplicaţia deservită de acest protocol este de tip client – server, iar
paginile serverelor de Web sunt identificate după o schemă specială de adresare numită
URL (Uniform Resource Locator).
Protocolul PING asigură serviciul care poate fi utilzat pentru a testa conectivitatea
între două sisteme.

1.6 REŢELE ZONALE (AREA NETWORK)

Din punctul de vedere al producǎtorilor de echipamente, toate reţelele se încadreazǎ în
terminologia generalǎ de “reţea zonalǎ” sau “area network”. În aceastǎ categorie de
structuri hardware-software se pot identifica – prin anumite caracteristici comune -
urmǎtoarele tipuri de “reţele de calculatoare” cu denumirea consacrată în limba engleză:
• Personal Area Network (PAN)
• Local Area Network (LAN)
• Metropolitan Area Network (MAN)
• Wide Area Network (WAN)
În acest context general, Internetul este cea mai complexă materializare a noţiunii de
“reţea de calculatoare” prin care sunt conectate între ele miliarde de calculatoare din
întreaga lume (cea mai complexă reţea WAN).
Într-o caracterizare globală şi simplificată a tipurilor de reţele de calculatoare
distingem două categorii:
• Reţele locale de calculatoare (LAN- Local Area Network) şi

16
 • Reţele de mare suprafaţă (WAN-Wide Area Network).
Într-o comparaţie superficială, LAN-urile sunt mai performante decât WAN-urile în
ceea ce priveşte viteza de transfer a datelor, securitatea transferului şi robusteţea
comunicaţiei.
Progresele contemporane înregistrate în domeniul tehnologiei reţelelor de calculatoare
pe cele două componente-hardware şi software complică procesul de evaluare şi
diferenţiere între reţelele LAN şi WAN. Cablurile de fibră optică au permis tehnologiilor
LAN să conecteze echipamente aflate la zeci de kilometri depărtare (distanţe specifice
WAN-urilor) în timp ce s-a mărit considerabil viteza şi siguranţa în comunicaţie pentru
reţelele WAN.

1.6.1. Tipuri de reţele zonale

1.6.1.1. Local Area Network (LAN)
LAN-urile sunt, de obicei, localizate într-un spaţiu corespunzător unei clădiri sau
campus universitar şi mai general, la nivelul unei organizaţii.
Ca dimensiune LAN-urile pot fi mici, formate, de exemplu din trei calculatoare, sau
pot cuprinde prin legături între ele, sute de calculatoare; în afară de faptul că operează
într-un spaţiu limitat, LAN-urile sunt în general proprietatea unei singure persoane sau
organizaţii şi sunt administrate exclusiv de proprietar.
Un LAN este realizat din următoarele componente:
- Computere,
- Plăci de rețea,
- Dispozitive periferice,
- Mediul de rețea,
- Dispozitive de rețea.
LAN-urile sunt proiectate să:
- Opereze într-o arie geografică limitată,
- Să permită multi-accesul la un mediu de bandă largă,
- Să asigure un control al intimității sub o administrare locală,
- Să furnizeze o conectivitate permanentă la serviciile locale,
- Să conecteze fizic dispozitive alăturate.
Tehnologii utilizate de către LAN-uri: Ethernet, Token Ring, FDDI

1.6.1.2. Wide Area Network

WAN interconectează LAN-uri care apoi oferă acces la computere sau servere din alte
locații. Ele oferă comunicații instantanee peste arii geografice largi. Această abilitate de a
transmite mesaje instantanee cuiva de oriunde în lume asigură aceleași capabilități de
comunicare ca și când persoanele ar fi în aceeași locație fizică. Produsele software
furnizează accesul la informații și resurse în timp real, permițând întâlniri la distanță.
WAN-urile au creat un nou tip de lucrător numit telecommuter , persoană care nu își
păresește domiciliul pentru a se duce la serviciu.
WAN au fost proiectate să:
- Opereze peste arii geografice întinse,
- Să permită utilizatorilor comunicații de timp real,
- Să furnizeze permanent conectarea resurselor distante la servicii locale,

17
 - Să furnizeze servicii e-mail, www, transfer de fișiere, e-comerț.
Tehnologii utilizate de către WAN:
Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), Frame
Relay.

1.6.1.3. Metropolitan Area Network(MAN)

MAN este o rețea care acoperă o arie metroplolitană cum ar fi un oraș sau o suburbie.
În mod uzual, constă din două sau mai multe LAN-uri situate într-o arie geografică
comună. De exemplu, o bancă cu mai multe sucursale poate utiliza un MAN. Tipic,
pentru conectarea a două sau mai multe LAN-uri se utilizeză un furnizor de servicii care
oferă linii de comunicație private sau servicii optice. Un MAN poate fi creat utilizând și
legături wireless peste o arie publică.

1.6.1.4. Storage Area Network (SAN)

Un SAN este o rețea dedicată, de mare performanță, utilizată pentru schimbul de date
între servere și resurse de inmagazinare. Deoarece este o rețea dedicată, evită orice
conflict de trafic între clienți și servere.
Tehnologiile SAN oferă legături de mare viteză server-to-storage, storage-to-storage,
sau server-to-server. Se utilizează o infrastructură de rețea separată care evită orice
problemă asociată conectării la rețelele existente.

Fig. 1.11 Storage Area Network (SAN)

18
 SAN oferă:
- Performanță - permite accesul curent la matricele de discuri sau benzi
pentru două sau mai multe servere la viteze înalte, oferind sistemului o performanță
ridicată,
- Disponibilitate – SAN sunt construite cu toleranță la dezastre, deoarece
datele pot fi dublate utilizând SAN până la distanțe de 10 km.
- Scalabilitate – Ca și LAN sau WAN, utilizează o varietate de tehnologii.
Acestea permit o relocare a datelor backup , operații, migrare de fișiere și replici de date
între sisteme.

1.6.1.5. Virtual private network (VPN)

VPN este o rețea privată construită în interiorul infrastructurii unei rețele publice cum
ar fi Internetul. Utilizând VPN, un telecommuter poate accesa rețeaua companiei prin
construirea unui tunel securizat între PC-ul său și un ruter lal VPN din sediul central.

Fig. 1.12 Virtual private network (VPN)

VPN este un serviciu care oferă securitate, conectivitate privată peste o infrastructură
publică. Menține aceeași politică de securitate și management ca și o rețea privată. VPN
sunt cele mai eficiente (din punct de vedere al costurilor) metode de stabilire a unor
legături punct-la-punct între utilizatori distanți și o rețea de întreprindere.
Există trei tipuri de VPN:
1. VPN de acces. Permit accesul distant unui lucrător mobil sau a unei rețele
de domiciliu de mică dimensiune la sediul central al unei rețele. VPN de acces utilizează
tehnologii analogice, telefonice, ISDN, DSL, mobile IP pentru a asigura o conexiune
sigură între utilizatori mobili, telecommuteri și sucursale.
2. VPN Intranet. Leagă oficii regionale și distante la sediul central al unei
rețele interne peste o infrastructură publică utilizând conexiuni dedicate. Intranet diferă
de extranet prin aceea că permite accesul numai angajaților întreprinderii.

19
 3. VPN Extranet. Oferă o legătură la sediul central al rețelei, peste o
infrastructură publică, partenerilor întreprinderii urilizând conexiuni dedicate. Spre
deosebire de Intranet, oferă acces utilizatorilor din afara întreprinderii.

1.7 TOPOLOGII UTILIZATE ÎN REŢELELE LOCALE

Termenul de topologie de reţea se referă la dispunerea fizică în teren a elementelor
care compun reţeaua de comunicaţie sau reţeaua de calculatoare. Topologia este termenul
standard folosit când se fac referiri la configuraţia spaţială a reţelei.
Topologia unei reţele afectează direct performanţele acesteia. Alegerea unei topologii
în detrimentul alteia influenţează tipul de echipament necesar, caracteristicile
echipamentului, extinderea reţelei, modul în care este administrată reţeaua. Topologiile
diferite necesită metode de comunicaţie diferite iar aceste metode au o mare influenţă în
reţea.
Principial există patru tipuri de topologii pentru LAN-uri:
• Topologia magistrală;
• Topologia inel;
• Topologia stea;
• Topologia arbore.

1.7.1 Topologia magistrală (bus topology).

Reţelele locale cu topologie liniară (magistrală sau “bus”) funcţionează ca o linie de
comunicaţie multipunct pentru care fiecare racord corespunde unui sistem ce reprezintă
fie o resursă comună partajabilă de către alte sisteme, fie un utilizator al reţelei (figura
1.13). Această topologie a fost folosită în reţelele Ethernet (în prezent din ce în ce mai
rar).
În ciuda dificultăţilor cauzate de conflictele de acces la suportul de transmisiune,
avantajele topologiei liniare, legate de omogenitatea reţelei, facilităţile de reconfigurare,
costul redus al suportului şi al dispozitivelor de cuplare la suport au condus la o utilizare
frecventă a acesteia. Ca dezavantaj este menţionat faptul că o întrerupere oriunde în cablu
va cauza inoperabilitatea întregului segment.

T T T

T T T T

Fig. 1.13 Topologie de tip magistrală.

Informaţia transmisă prin magistrală este etichetată cu adresele sursei şi destinaţiei.

Funcţia de comutare a fost transferată terminalelor care posedă inteligenţa necesară
pentru a elabora şi analiza mesajele cu adresă. Pe baza adresei conţinută în fiecare mesaj
– pachet de informaţie, acesta este recepţionat şi identificat de către unul sau mai mulţi
destinatari.

20
1.7.2 Topologia inel (Ring)
Într-o configuraţie de tip inel toate sistemele sunt legate succesiv între ele, două câte
două, ultimul sistem fiind conectat la primul sistem (figura 1.14).
Fiecare sistem recepţionează semnalul transmis pe buclă şi-l retransmite mai departe,
copiind mesajul dacă îi este destinat. Mesajul emis de un sistem (sursă) va fi retras din
buclă de către acelaşi sistem atunci când îi va reveni după parcurgerea buclei. Staţia care
transmite următoarea este cea care deţine permisul de a transmite, numit jeton (token). O
astfel de reţea este cea denumită Inel cu jeton (Token – ring).
Pentru ca defectarea unui sistem să nu provoace întreruperea buclei, fiecare sistem este
prevăzut cu un mecanism pasiv de şuntare.

Mecanism
de şuntare

Fig. 1.14 Topologie inel

În general, bucla este unidirecţională. Inelul unidirecţional din figura 1.9 rezultă
tot dintr-o configuraţie stea cu un nivel, el este un suport comun pentru transmisia
unidirecţională a mesajelor, fiind echivalat topologic cu centrul stelei. Există şi bucle
duble, a doua cale servind pentru a creşte fiabilitatea buclei. Frecvent, în cazul buclelor
duble, semnalele circulă în sensuri contrare pe cele două căi.
Structurile prezentate anterior (bus comun, inel cu jeton sau reţea satelit) presupun
rezolvarea accesului la suport de către terminalele T. Această problemă se rezolvă de
obicei prin diviziunea în timp cu alocare statică/dinamică a intervalelor de timp (canale
temporale). În practică se foloseşte structura cu două inele bidirecţionale care elimină
dezavantajul fiabilităţii reduse a inelului monodirecţional (figura 1.15), prin oportunitatea
de reconfigurare în inelul unidirecţional (exemplu: FDDI-Fiber Distribution Data
Interface).

21
 Fig. 1.15 Topologie dublu inel cu varianta de reconfigurare în inel unidirecţional.

1.7.3 Topologia Stea

Toate echipamentele sunt conectate la un punct sau echipament central care poate fi un
hub propriu-zis sau un comutator “switch” (figura 1.16). Echipamentele se conecteazǎ de
obicei la hub prin cablu UTP (Unshilded Twisted Pair) Ethernet.
În această configuraţie sistemele sunt conectate la un nod central care joacă un rol
particular în funcţionarea reţelei. Orice comunicaţie între două sisteme trece prin nodul
central, care se comportă ca un comutator faţă de ansamblul reţelei (figura 1.16).
Transferul informaţiei se face punct-la-punct dar, cu ultimele tipuri de comutatoare, este
posibil şi un transfer în legătură multipunct. Această topologie prezintă avantajul că poate
folosi în mare parte cablajul telefonic vechi existent într-o întreprindere. De asemenea, în
mare parte software-ul este concentrat în nodul central, pentru sisteme fiind necesar un
software simplu. Reţelele Stea sunt relativ uşor de instalat şi administrat, dar cunosc
fenomenul de congestie sau gâtuire (bottleneck) în cazul unui trafic intens, deoarece toate
datele trec prin hub. Fiabilitatea reţelei depinde foarte mult de nodul central, o defectare a
acestuia conducând la căderea reţelei; este necesar un suport fizic de comunicaţie
individual pentru fiecare sistem; extensia reţelei este limitată la capacitatea nodului
central.

Fig. 1.16 Exemplu de topologia Stea

22
 Comparativ cu tehnologia magistralǎ, o reţea stea necesitǎ în general mai mult cablu;
o defecţiune undeva în cablu sau echipament, scoate din funcţiune un singur calculator,
dar reţeaua localǎ rǎmâne operaţionalǎ; dacǎ hub-ul se defecteazǎ, întreaga reţea devine
ne-operaţionalǎ.
Reţelele 10BASE-T Ethernet, Fast Ehernet şi Gigabit Ehernet implementează o
topologie stea, în care accesul în reţea şi comunicaţia dintre staţii sunt controlate de un
echipament central.

1.7.4 Topologia arbore

Aceasta combină caracteristicile topologiilor magistrală liniară şi stea, fiind o reuniune
de grupuri fiecare configurat ca o reţea locală stea (figura 1.17) şi toate grupurile sunt
conectate la un cablu magistrală liniară numit backbone.
În forma cea mai simplǎ de reţea Stea, numai echipamentele hub se conecteazǎ direct
la magistrala arborelui şi fiecare hub funcţioneazǎ ca rǎdǎcinǎ (‘root’) a unui arbore de
echipamente; aceasta structurǎ hibridǎ magistralǎ-stea permite extensii viitoare comode:
• mult mai uşor decât topologia magistralǎ (limitatǎ ca numǎr de
echipamente datoritǎ traficului de tip difuzare pe care îl implicǎ) sau
• mult mai uşor decât o singurǎ reţea stea, datoritǎ numǎrului limitat de
porturi dintr-un hub.

Hub
Servere

Hub

Hub

Staţii de lucru

Fig. 1.17 Exemplu de topologie arbore .

1.7.5 Reţele cu topologie mixtă

Topologiile menţionate mai sus pot fi la rândul lor combinate şi rezultă sisteme
deosebit de complexe aşa cum este cazul reţelei Internet, care este “o reţea de reţele”;
aceste reţele complexe sunt denumite “reţele mixte”. Aceste reţele sunt distribuite pe arii
geografice mari. Structurile au rezultat din diverse considerente, altele decât cele strict
tehnice (economice, de trafic, politice, militare, etc.). O reţea mixtă este compusă din mai
multe reţele de topologii diferite interconectate din necesitatea de a acoperi o arie mai
mare. Se pleacă de la o reţea miez (core, backbone) care de cele mai multe ori are o
topologie mesh şi apoi se extinde acest miez cu diverse alte reţele.

23
1.7.6 Reţele cu interconectare totală (de tip plasă - mesh)
Topologia mesh (plasă) implementeazǎ conceptul de rute, încât mesajele trimise într-o
reţea mesh pot urma oricare din mai multe cǎi posibile care leagǎ sursa de destinaţie. Cel
mai bun exemplu de reţea mesh este Internetul, care utilizează tehnici de rutare complexe
dar de acest tip (mesh). Se prezintă în figura 1.18 un asemenea tip de reţea.
Avantaje:
- număr mare de joncţiuni:
- rute de rezervă multiple.
Dezavantaje: cost ridicat.

Fig. 1.18 Reţea cu interconectare totală.

24
 CAP 2. NIVELUL REŢEA

În cadrul acestui capitol se trec în revistă cele mai importante protocoale asociate nivelului
reţea din stiva de protocoale TCP/IP. Protocoalele analizate sunt următoarele:
¾ Protocolul Internet – IP (Internet Protocol),
¾ Protocoale de rutare – RIP (Routing Information Protocol), IGRP (Inter-
Gateway Routing Protocol),
¾ Protocolul de rezoluţie a adreselor – ARP (Address Resolution Protocol),
¾ Protocolul de configurare dinamică a hosturilor – DHCP (Dynamic Host
Configuration Protocol),
¾ Protocolul de mesaje de control pentru Internet – ICMP (Internet Control
Message Protocol).

Aceste protocoale care operează la nivelul reţea (cunoscut de asemenea sub numele de nivel
internet) oferă servicii protocoalelor de nivel transport, implementând funcţii, cum ar fi:
¾ Rutarea şi livrarea pachetelor (datagrame) în cadrul reţelelor de
comunicaţii care formează Internetul,
¾ Adresarea datagramelor,
¾ Configurarea dinamică a adreselor,
¾ Stabilirea corespondenţei dintre adresele de nivel reţea şi adresele de
nivel interfaţă reţea (corespunzător nivelului legătură de date).

2.1 PROTOCOLUL INTERNET (IP)

Cel mai important dintre protocoalele de nivel trei este protocolul Internet (IP – Internet
Protocol). IP are rolul de a ascunde detaliile de implementare a reţelelor fizice de nivel
inferior prin crearea unei reţele virtuale care operează la o scală mult mai mare.
IP este un protocol nefiabil, fără a însemna însă o calitate scăzută a acestuia, de tipul “best
effort”, iar livrarea pachetelor se realizează într-un mod fără conexiune. Apelativul “best
effort” se referă la faptul că pachetele transmise de către IP pot fi pierdute, pot sosi în altă
ordine decât cea de la transmisie sau chiar pot fi recepţionate de mai multe ori. De asemenea,
se presupune că protocoalele de nivel superior vor rezolva toate aceste probleme. Unul dintre
motivele pentru care s-a utilizat un protocol fără conexiune la vivelul reţea este pentru a
minimiza dependenţa de anumite centre de calcul utilizate în reţelele ierarhice orientate pe
conexiune. Departamentul de apărare al Statelor Unite (DOD – Department of Defense) a
creat în anii ‘70 o reţea (ARPANET) capabilă să funcţioneze chiar şi în cazul în care anumite
zone ale sale au fost distruse. Această soluţie s-a dovedit a fi validă şi pentru Internet.
IP este un protocol rutat, ceea ce înseamnă că alte protocoale de nivel reţea vor efectua
rutarea pachetelor IP. IP implementează funcţii, cum ar fi: adresarea utilizatorilor (adrese IP),
segmentarea pachetelor şi respectiv, reasamblarea pachetelor. Pentru operarea de rutare se
utilizează adresele din cadrul pachetului IP. Fiecare pachet este tratat ca o entitate
independentă, fără a se stabili vreo relaţie cu alte pachete. Segmentarea pachetelor de către
sursă, precum şi reasamblarea acestora la destinaţie sunt operaţii necesare pentru a respecta
dimensiunea cadrului impusă de către protocolul utilizat la nivelul legătură de date, specific
fiecărui tip de reţea fizică.
 2 2. Nivelul Reţea

2.1.1 Pachetul IP
Formatul pachetelor IP este prezentat în figura 2.1.

Fig. 2.1 Formatul pachetului IP.

Structura pachetelor se bazează pe cuvinte de 32 biţi, lungime corespunzătoare procesoarelor

ARPANET iniţiale. În continuare se va prezenta semnificaţia câmpurilor unui pachet.
- Versiune - Identifică versiunea protocolului IP care generează pachetul. În prezent este
utilizată versiunea 4 a protocolului (IPv4), versiunea 5 este o versiune experimentală şi s-au
definit standarde pentru versiunea 6 (Ipv6).
- Lungimea antetului - Indică lungimea antetului măsurată în cuvinte de 32 biţi. Lungimea
minimă a antetului corespunde cazului când acesta nu conţine câmpul opţiuni şi este 5 (20
octeţi).
- Tipul serviciului - Arată calitatea serviciului cerut pentru transportul pachetului în reţea.
Calitatea serviciului este exprimată prin intermediul a patru parametri: prioritate (precedence),
întârziere, eficienţă în transmisiune (referitor la debit - throughput) şi fiabilitate. Acest câmp
poate influenţa ruterele în alegerea unei căi spre destinaţie dar, aşa cum s-a mai menţionat,
protocolul IP nu garantează calitatea cerută pentru transportul datelor.
- Lungimea totală - Acest câmp specifică lungimea totală a pachetului, măsurată în octeţi,
incluzând atât antetul cât şi datele.
- Identificare, Fanioane şi Decalajul fragmentului - Controlează fragmentarea şi
reasamblarea pachetelor. Desigur, transmisiunea pachetelor ar fi eficientă dacă fiecare pachet
generat de o sursă ar putea fi inclus în întregime într-un cadru pentru a traversa reţeaua spre
destinaţie. Dar fiecare tip de reţea impune o anumită limită superioară pentru lungimea
cadrului. Spre exemplu, reţeaua Ethernet limitează cadrul la 1500 octeţi de date, unele reţele
publice de date limitează cadrul la 128 octeţi etc. Limitarea dimensiunii pachetelor la cea mai
mică limită superioară admisă în reţea ar face transmisiunea ineficientă. Din această cauză
protocolul IP lasă sursei latitudinea să aleagă dimensiunea pachetului corespunzător
constrângerilor impuse de legătura de date la care ea este conectată, iar o divizare a fiecărui
pachet în fragmente se realizează în ruter atunci când urmează să traverseze o reţea care
admite dimensiuni mai mici. Reasamblarea pachetelor se face la destinaţie. Fiecare fragment
are acelaşi format ca şi un pachet complet.
Câmpul "Identificare" conţine un număr care identifică pachetul. Când un ruter
fragmentează un pachet câmpul Identificare trebuie copiat în antetul fiecărui fragment. În
felul acesta la destinaţie se poate şti, ţinând seama şi de adresa sursei, cărui pachet aparţine
fiecare fragment.
Câmpul "Decalajul fragmentului" (“Fragment offset”) indică, pentru fiecare fragment,
numărul grupurilor de cîte 8 octeţi (octeţii din antet nu sunt consideraţi) conţinuţi în
 Arhitectura Reţelelor şi Internet 3

fragmentele deja transmise, din cadrul pachetului curent. Dacă fragmentul în cauză este
primul sau singurul, acest câmp ia valoarea 0.
Prin cei trei biţi din câmpul "Fanioane" (Flags) se poate semnala interdicţia de
fragmentare a pachetului (când sursa impune această restricţie) şi dacă, în cazul unui
fragment, este sau nu ultimul din pachet. Acest câmp conţine 3 biţi – fanioane de control,
prezentaţi în figura 2.2.

Fig. 2.2 Fanioanele pachetului IP.

Cei trei biţi au urmatoarele semnificaţii:

– 0: Rezervat. Ia întotdeauna valoarea 0.
– Indicator al posibilităţii de fragmentare – DF (Do not Fragment): dacă ia valoarea 0 se
poate face fragmentare, iar pentru 1 înseamnă că fragmentarea nu este permisă.
– Indicator al continuităţii fragmentării – MF (More Fragments): dacă ia valoarea 0
înseamnă că fragmentul curent este ultimul din pachet, iar pentru 1 înseamnă că alte
fragmente vor urma.
- Lungimea totală indică, în cazul unui fragment, lungimea fragmentului şi nu a pachetului
din care face parte.
- Durata menţinerii în viaţă (TTL – Time to live) arată cât timp, în secunde, i se permite unui
pachet să rămână în reţea. Teoretic, fiecare ruter care prelucrează acest pachet ar trebui să
scadă timpul său de prelucrare din valoarea conţinută în acest câmp. În practică, un ruter
prelucrează fiecare datagramă în mai puţin de o secundă. Astfel, echipamentele de
interconectare (ruterele) scad valoare acestui câmp cu o unitate atunci când redirectează
pachetul. Prin urmare, câmpul TTL devine mai mult un contor al nodurilor intermediare decât
o metrică de timp. În plus, în cazurile în care ruterele sunt suprasolicitaţi şi prelucrează cu
întârziere pachetele, se face o decrementare suplimentară corespunzătoare timpului de
aşteptare. Când mărimea înscrisă în acest câmp ajunge la zero ruterul elimină pachetul şi
transmite către sursă un mesaj de eroare. Limitarea timpului de supravieţuire în reţea evită
circulaţia la nesfârşit a pachetelor (cauzată de obicei de existenţa unei bucle în cadrul reţelei).
Valoarea iniţială trebuie stabilită de către protocolul de nivel superior care generează
conţinutul datagramei.
- Protocol - Identifică protocolul de nivel superior (transport: TCP sau UDP) asociat
pachetului. Pentru protocolul TCP identificatorul este 6 iar pentru UDP este 17.
- Secvenţa de verificare a antetului - Permite verificarea corectitudinii (integrităţii) valorilor
din antet. Acest câmp este determinat prin prelucrarea antetului, considerat ca o succesiune de
întregi, fiecare alcătuit din 16 biţi. Fiecare ruter calculează secvenţa de verificare şi o compară
cu cea din antet. Dacă valoarea sumei de verificare din antet nu corespunde cu conţinutul
datagramei, atunci aceasta este eliminată din reţea.
- Câmpurile de adrese - Conţin adresele de reţea (IP) de câte 32 biţi fiecare, a sistemului
sursă şi a sistemului destinaţie. Aceste câmpuri nu sunt modificate la trecerea pachetelor prin
rutere.
- Opţiuni - Are o lungime variabilă (maximum 40 octeţi) şi este rezervat pentru a introduce
unele funcţiuni de control privind rutarea, securitatea reţelei şi altele. În acest câmp pot fi
introduse mai multe opţiuni. Fiecare opţiune este specificată printr-un cod de opt biţi ce poate
fi urmat de un octet care indică lungimea şi de mai mulţi octeţi de date pentru respectiva
opţiune. Pentru ca acest câmp să aibă dimensiunea egală cu un multiplu de 4 octeţi se folosesc
biţi de completare.
 4 2. Nivelul Reţea

- Câmpul datelor - Are o lungime variabilă, dar un număr întreg de octeţi. Limitele pentru
dimensiunea unui pachet, inclusiv antetul, sunt 576 octeţi minimum şi 65.535 octeţi
maximum.

2.1.2 Adresarea IP (versiunea 4 a protocolului IP - IPv4)

Adresele IP constau în valori fără semn reprezentate cu 32 de biţi folosite pentru
identificarea unui singur sistem în Internet. Mai exact, o adresă IP identifică o interfaţă
capabilă să trensmită şi să recepţioneze datagrame IP. Cei 32 de biti ai adresei IP se scriu sub
forma a 4 octeţi, fiecare dintre octeţi putând fi scris sub forma unui număr zecimal luând
valori intre 0 si 255, in forma p.q.r.s. Un exemplu de adresă scrisă în forma zecimală este
141.85.254.53. Aceasta notatie se numeste dotted quad. Formatul general al adresei IPv4 de
32 de biţi este reprezentat în figura 2.3.

Fig. 2.3 Formatul general al adresei IPv4.

În funcţie de domeniul în care se află primul octet (p), mai exact primii 4 biţi, există mai
multe clase de adrese, notate A, B, C, D, etc. Aceşti biţi specifică delimitarea câmpurilor
identificatorilor de reţea şi de sistem (host). Identificatorul de reţea specifică reţeaua din care
face parte sistemul (sursă sau destinaţie), iar identificatorul de sistem specifică un sistem
particular din această reţea. Clasele se diferenţiază prin dimensiunea părţilor din adresă care
specifică reţeaua şi hostul şi sunt prezentate în tabelul 2.1.
Clasa Primul Tip adresă Reţea Host Nr. max. Masca implicită
octet (primii de hosturi
biţi)
A 1 – 126 0 p q.r.s 16777214 255.0.0.0
B 128 – 191 10 p.q r.s 65534 255.255.0.0
C 192 – 223 110 p.q.r s 254 255.255.255.0
D 224 – 239 1110 p.q.r.s – – –
E 240 – 247 11110 p.q.r.s – – –

Tab. 2.1. Clasele de adrese IPv4.

La adresele de clasa A primul octet specifică reţeaua, şi restul de trei octeţi specifică
sistemul. De aici rezultă că pot exista doar 126 de reţele (nu se utilizează reţelele cu primul
octet 0 şi 127) cu adresa de clasa A, iar aceste reţele pot avea fiecare 224 – 2= 16.777.214
sisteme (24 de biţi pentru identificatorul de sistem). Numărul total de sisteme din toate
reţelele de clasă A este de peste 2 miliarde. Deci, adresele de clasa A nu se aloca decât pentru
retele foarte mari.
Adresele din clasa B au primii doi biţi 10 şi dintre ceilalţi, 14 biţi sunt ai identificatorului
de reţea, iar 16 biţi ai identificatorului de sistem. În concluzie, pot exista până la 214 (16.384)
reţele, fiecare cu până la 216 – 2 (65.534) sisteme, cu un total de peste 1 miliard de adrese.
Adresele din clasa C au primii trei biţi 110 şi dintre ceilalţi, 21 biţi sunt ai identificatorului
de reţea, iar 8 biţi ai identificatorului de sistem. În concluzie, pot exista până la 221
(2.097.152) reţele, fiecare cu până la 28 – 2 = 254 sisteme, cu un total de peste jumătate de
miliard de adrese.
Adresele din clasa D au primii patru biţi 1110 şi sunt utilizate pentru difuzarea mesajelor
de la un sistem către un grup de sisteme din reţeaua globală (numai către sisteme care
 Arhitectura Reţelelor şi Internet 5

utilizează aceeaşi adresă de clasă D). Din acest motiv, adresele din clasa D se mai numesc şi
adrese de grup (multicast) şi sunt folosite de unele protocoale de rutare şi de firmă pentru
comunicarea dintre echipamente ale aceluiaşi producător (vezi ruterele şi switch-urile
CISCO).
Adresele de clasă E sunt rezervate pentru viitoare modificări sau pentru scopuri
experimentale.
O adresă de clasă A este potrivită pentru reţele cu un număr extrem de mare de sisteme, iar
la polul opus adresele de clasă C sunt indicate pentru reţele cu număr mic de sisteme. Prin
urmare, reţelele de dimensiuni medii (cele cu mai mult de 254 de sisteme sau cele pentru care
se aşteaptă să depăşească 254 de staţii) trebuie să se utilizeze adrese de clasă B.

2.1.2.1 Adresele IP rezervate

Pentru toate aceste clase, se elimină întotdeauna, atât la identificatorul de reţea cât şi la
identificatorul de sistem, secvenţa cu toţi biţii 1 şi cea cu toţi biţii 0 (de aceea se scade 2 din
numărul maxim de valori zecimale ale secvenţei de n biţi, 2n). Aceste două secvenţe au o
semnificaţie aparte şi nu sunt folosite pentru a defini adrese de sisteme, ci după cum se va
arăta ulterior, ele desemnează masca, respectiv adresa întregii reţele din clasa respectivă.
Un alt tip de adresă utilizată pentru o funcţie specială este adresa de buclă locală (loopback).
Spre exemplu, reţeaua de clasă A 127.0.0.0 este definită ca adresă de reţea pentru bucle
locale. Adresele din cadrul acestei reţele sunt alocate interfeţelor care prelucrează date în
interiorul sistemului local. Aceste interfeţe pentru bucle locale nu permit accesul în reţeaua
fizică.
Masca unei reţele este acea secvenţă de 32 biţi (de aceeaşi lungime cu adresele) care are
biţi cu valoarea 1 pe toate poziţiile corespunzătoare identificatorului de reţea şi biţi cu
valoarea 0 pe toate poziţiile corespunzătoare identificatorului de sistem. Măştile implicite
corespunzătoare claselor de adrese A, B şi C sunt prezentate în tabelul 2.1. O formă
simplificată de scriere a măştii reţelei este cea prin care se specifică numărul de biţi 1 din
componenţa acesteia. Spre examplu, masca implicită a clasei B se poate nota ca ‘/16’
deoarece aceasta conţine biţi 1 pentru selectarea primilor doi octeţi ai adreselor. Formele
simplificate ale măştilor implicite sunt de asemenea prezentate în tabelul 2.1. Măştile sunt
utilizate în fiecare ruter pentru luarea deciziei asupra interfeţei de reţea a ruterului pe care se
va redirecta datagrama IP ce conţine adresa destinaţie. Masca permite selectarea
identificatorului de reţea dintr-o anumită adresă. Identificarea reţelei pentru rutarea unei
datagramei se va face pe baza operaţiei binare ŞI (AND) la nivelul biţilor de pe o anumită
poziţie a adresei IP citită din datagramă şi poziţia corespunzătoare din mască. Un exemplu de
utilizare a măştii pentru o adresă de clasă B este prezentat mai jos, în exemplul 2.1.
Adresele de difuzare (broadcast) pentru o anumită reţea sunt acele adrese care au biţi cu
valoarea 1 pe toate poziţiile corespunzătoare identificatorului de sistem, iar identificatorul de
reţea specifică domeniul în care se va face difuzarea. Adresa de broadcast care are toţi biţii 1
(deci şi cei ai identificatorului de reţea) este adresa globală de broadcast în Internet,
255.255.255.255. Exemplul 2.1 ilustrează modul creare a adresei de difuzare pentru o reţea de
clasă B.
 6 2. Nivelul Reţea

Exempul 2.1. Exemplu de utilizare a măştii şi adresele de difuzare. Se consideră adresa de

clasă B, 141.85.58.3 care are masca de reţea implicită 255.255.0.0. Atunci operaţia de
mascare a adresei este următoarea prezentată în figura 2.4.

Fig. 2.4 Examplu de utilizare a măştii şi de obţinere a adresei de difuzare pentru o reţea de
clasă B.

2.1.2.2 Crearea de subreţele (subneting)

Datorită creşterii explozive a Internet-ului, principiul de alocare a adreselor IP a devenit
prea inflexibil pentru a permite modificări facile ale configuraţiilor reţelelor locale. Aceste
modificări pot surveni în următoarele situaţii: când se instalează într-o anumită locaţie o nouă
reţea fizică, când creşterea numărului de staţii impune divizarea reţelei locale în două sau mai
multe reţele distincte sau atunci când creşterea distanţei necesită divizarea unei reţele în mai
multe reţele de arie mai mică separate cu rutere.
Pentru a evita utilizarea unor adrese IP suplimentare s-a introdus o nouă formă de divizare
a reţelelor din fiecare clasă în subreţele (IP subnetting). Alocarea subreţelelor este efectuată
local. Totuşi, întreaga reţea este văzută din exterior ca o singură reţea IP.
Există două metode de divizare în subreţele: static şi de dimensiune variabilă. Evident,
divizarea în subreţele de dimensiuni variabile oferă o flexibilitate mai mare în gestionarea
spaţiului de adrese.
O subreţea a unei reţele se construieşte prin împrumutarea unei secvenţe de biţi din
identificatorul de sistem, obţinându-se astfel un identificator suplimentar al subreţelei. Deci,
un sistem face parte dintr-o subreţea, care la rândul ei face parte dintr-o reţea (fiecare dintre
cele trei având identificatorul său). Formatul adresei de reţea divizată în subreţele este
reprezentat în figura 2.5.

Fig. 2.5 Divizarea reţelei în subreţele.

Deoarece o subreţea se obţine prin împrumutarea unui număr de biţi din câmpul
identificatorului de sistem, atunci preţul plătit pentru crearea subreţelei este reducerea
identificatorului de sistem (deci şi a numărului maxim de sisteme din fiecare subreţea). Spre
exemplu, dacă se împrumută a biţi pentru subreţele atunci numărul de subreţele create este de
2a – 2 (se scad cele două: adresa reţelei şi masca), iar numărul de sisteme din fiecare subreţea
este de 2Id. sistem – a – 2. Masca subreţelei şi adresele de difuzare în subreţele au acelaşi rol ca şi
în cazul reţelelor clasificate.
 Arhitectura Reţelelor şi Internet 7

2.1.2.2.1 Divizarea statică în subreţele

Divizarea statică presupune ca toate subreţelele obţinute prin divizarea unei reţele să
utilizeze aceeaşi mască de subreţea. Deşi această metodă este simplu de implementat şi
administrat, prezintă dezavantajul irosirii unui spaţiu de adrese considerabil, mai ales in cazul
divizării unei reţele mici. În continuare se prezintă un exemplu de divizare a unei reţea de
clasă B în subreţele (prin împrumutarea a 4 biţi din câmpul de identificare a sistemului), cu
adresele de difuzare şi măştile subreţelelor corespunzătoare.

Exemplul 2.2. Divizarea în subreţele a unei reţele de clasă B. Se consideră reţeaua de clasă
B, 141.85.0.0 care are masca de reţea implicită 255.255.0.0. Operaţia de divizare a reţelei în
subreţele, prin împrumutarea a 4 biţi din câmpul de identificare a sistemului este ilustrată în
figura 2.6.

Fig. 2.6 Exemplu de divizare în subreţele a unei reţele de clasă B.

În concluzie, prin divizarea de mai sus s-au obţinut 24 – 2 = 14 subreţele, fiecare având un
număr maxim de 212 – 2 = 4094 sisteme. Dacă se consideră o subreţea cu un efectiv de numai
4 sisteme se vor pierde 4090 de adrese IP.

2.1.2.2.2 Divizarea în subreţele de dimensiuni variabile

Dacă se utilizează divizarea în subreţele de dimensiuni variabile sau cu măşti de subreţea
de lungime diferită, VLSM (variable length subnet masks), atunci subreţelele obţinute prin
divizarea unei reţele pot utiliza măşti diferite. O subreţea mică cu numai câteva sisteme poate
utiliza o mască aleasă convenabil. O subreţea cu multe staţii necesită o mască diferită de cea a
subreţelei mici. Posibilitatea alocării măştilor subreţelelor în funcţie de necesităţile acestora
permite conservarea spaţiului de adrese de reţea. Cu VLSM se divide reţeaua astfel încât
fiecare subreţea să conţină un număr suficient de adrese pentru deservirea staţiilor din
componenţă. O subreţea existentă poate fi divizată mai departe în două părţi prin adăugarea
unui nou bit la masca subreţelei. Celelalte subreţele din reţea nu vor fi afectate de această
schimbare. Exemplul 2.3 prezintă procedura de divizare în subreţele de dimensiuni variabile
pentru o reţea de clasă B.

Exemplul 2.3. Divizarea în subreţele de dimensiuni variabile pentru o reţea de clasă B.

Să considerăm o firmă căreia i s-a alocat reţeaua de clasă B 141.85.0.0/16. Din anumite
considerente, în cadrul firmei este necesară divizarea spaţiului de adrese alocat în cinci reţele
separate, fiecare cu următorul efectiv de sisteme: subreţelele 1, 2, 3, 4 şi 5 - 6000 de staţii
fiecare, iar subreţelele 6 şi 7 - 4000 de staţii fiecare. Aceste cerinţe nu pot fi satisfăcute printr-
o divizare statică. Spre exemplu, cu o divizare statică se pot obţine 6 subreţele cu 8190 staţii
fiecare sau 14 subreţele cu 4094 staţii fiecare. Nici una dintre cele două soluţii menţionate
anterior nu satisface cerinţele iniţiale. Pentru a diviza reţeaua în şapte subreţele este necesară
definirea unor măşti multiple. Utilizarea măştii 255.255.224.0 (sau ‘/19’) permite divizarea
 8 2. Nivelul Reţea

reţelei în 6 subreţele de 8190 staţii fiecare. Cea de a şasea subreţea poate fi divizată mai
departe în două subreţele cu 4094 staţii fiecare prin utilizarea măştii 255.255.240.0 (sau
‘/19’). Astfel, rezultă cinci subreţele cu 8190 staţii fiecare şi două subreţele cu 4094 staţii
fiecare. Această soluţie satisface cerinţele impuse şi elimină posibilitatea existenţei unui
număr mare de adrese irosite. Subreţelele rezultate în urma acestei divizări sunt prezentate în
figure 2.7.

Fig. 2.7 Exemplu de divizare a unei reţele de clasă B în subreţele de dimensiuni variabile.

2.1.3 Intrareţele: Adrese IP private

O procedură utilizată pentru a conserva spaţiul de adrese este de a relaxa regula conform
căreia adresele IP trebuie să fie unice la nivel global. Astfel, o parte din spaţiul de adrese
global este rezervată pentru reţele care nu sunt conectate la Internet. De obicei, aceste reţele
sunt administrate de o singură organizaţie. Trei mulţimi de adrese au fost rezervate pentru
acest scop:
- 10.0.0.0: o singură reţea de clasă A,
- de la 172.16.0.0 la 172.31.0.0: 16 reţele consecutive de clasă B,
- de la 192.168.0.0 la 192.168.255.0: 256 reţele consecutive de clasă C.
Orice organizaţie poate folosi oricare adresă din aceste trei mulţimi. Totuşi, deoarece
aceste adrese nu sunt unice la nivel global, nu sunt definite la nici unul dintre ruterele externe.
Ruterele din reţelele care nu utilizează adrese private, în particular, cele operate de furnizori
de servicii Internet, vor elimina tacit (fără mesaje ICMP) toată informaţia de rutare cu privire
la aceste adrese.
Ruterele din cadrul domeniului unei organizaţii care foloseşte adrese private vor limita
accesul referinţelor la adresele private la nivelul unor legături interne. De asemenea, aceştia
nu vor anunţa în exterior rute către adrese private şi nici nu vor redirecta datagrame IP
conţinând adrese private către ruterele externe.
Staţiile care au doar o adresă IP privată nu vor avea acces direct, prin intermediul nivelului
IP, la Internet. Toate legăturile cu sistemele externe din Internet se pot oferi numai prin
intermediul unor pasarele de nivel aplicaţie (application gateways). Un exemplu de astfel de
pasarele este prezentat în paragraful următor dedicat translatării adreselor de reţea NAT
(Network Address Translation).
 Arhitectura Reţelelor şi Internet 9

2.1.4 Translatarea adreselor de reţea (NAT)

În cadrul acestei secţiuni se prezintă metoda tradiţională de translatare a adreselor de
reţea NAT (Network Address Translation), NAT de bază (basic NAT), precum şi metoda de
translatare a adreselor de reţea şi a porturilor NAPT (Network Address Port Translation).
NAT mai este cunoscut şi sub numele de IP masquerading.
NAT realizează o corespondenţă între adresele IP interne şi adresele externe alocate
oficial. Iniţial, NAT a fost propusă ca o soluţie temporară la problema epuizării adreselor IP.
De asemenea, multe organizaţii au utilizat până la acel moment adrese IP alocate local, fără a
avea nevoie de o conexiune la Internet.
Există două versiuni ale NAT tradiţională: NAT de bază şi NAPT, care sunt prezentate în
paragrafele următoare.

2.1.4.1 NAT Tradiţională

Ideea metodei NAT tradiţionale (notată în continuare, simplu, NAT) se bazează pe ideea că
numai un număr mic de staţii dintr-o reţea privată necesită să comunice cu exteriorul reţelei.
Dacă fiecărei staţii i se alocă o adresă IP dintr-o listă oficială de adrese disponibile (în
engleză, adress pool) numai atunci când staţia solicită accesul în exterior, atunci este necesar
numai un număr relativ mic de adrese oficiale. NAT pare să fie o soluţie fiabilă pentru reţele
care deţin câteva intervale de adrese private sau neoficiale şi solicită stabilirea unei
comunicaţii cu sisteme din Internet. Atunci când nu sunt disponibile sau nu îndeplinesc
cerinţele specifice, soluţii gen server proxy, server SOCKS sau firewall, NAT poate fi
utilizată pentru a administra traficul dintre reţeaua internă şi cea externă fără a anunţa în
exterior adresele staţiilor din interiorul reţelei.

2.1.4.2 NAT de bază

Să considerăm o reţea internă bazată pe un spaţiu de adrese IP private, iar utilizatorii
solicită folosirea unui protocol aplicaţie pentru care nu există o pasarelă de nivel aplicaţie
disponibilă. În acest caz, singura opţiune disponibilă este să se stabilească o conectivitate de
nivel IP între sistemele din reţeaua internă şi sistemele din Internet.

Fig. 2.8 Translatarea de bază adreselor de reţea (basic NAT).

 10 2. Nivelul Reţea

Datorită faptului că ruterele din Internet nu vor cunoaşte cum să ruteze pachetele IP înapoi
la o adresă IP privată, este inutilă transmiterea pachetelor IP, cu câmpul de adresă sursă
specificând o adresă privată, printr-un ruter în Internet. Aşa cum este ilustrat în figura 2.8,
NAT de bază schimbă în mod dinamic adresa IP dintr-un pachet care iese din reţeaua internă
cu o adresă globală alocată oficial. Pentru pachetele care se propagă pe sensul de intrare în
reţeaua internă NAT de bază translatează adresa alocată oficial într-o adresă internă.
Din punctul de vedere al celor două sisteme care schimbă pachete IP între ele, unul aflat în
reţeaua internă şi celălalt aflat în reţeaua externă, NAT este transparent.

2.1.4.2.1 Mecanismul de translatare NAT de bază

Pentru fiecare pachet care iese din reţeaua internă, adresa sursă este verificată conform
regulilor de configurare NAT. Dacă una dintre reguli se aplică pentru adresa sursă, atunci
adresa este translatată într-o adresă globală din lista de adrese disponibile. Lista de adrese
predefinite conţine adresele pe care NAT le poate utiliza pentru translatare. Pe de altă parte,
pentru fiecare pachet de intrare în reţeaua internă, adresa destinaţie este verificată pentru o
eventuală utilizare de către NAT. Dacă se găseşte o corespondenţă NAT atunci adresa
destinaţie este schimbată cu adresa internă originală.
Adresele alocate trebuie rezervate prin scrierea într-o listă în vederea utilizării lor după
necesităţi. În cazul în care se iniţiază o transmisie din reţeaua internă, atunci NAT doar
selectează următoarea adresă publică disponibilă din tabela NAT şi o asociază sistemului
intern emitent. Serviciul NAT urmăreşte continuu asocierile făcute între adresele IP interne şi
adresele IP externe, astfel încât în cazul în care este nevoie să poată stabili o corespondenţă
între un răspuns recepţionat din reţeaua externă şi adresa IP internă corespunzătoare (vezi
figura 2.8).
Atunci când serviciul NAT alocă adresele IP la cerere, acesta trebuie să identifice
momentul în care poate returna adresa IP externă în tabela adreselor IP disponibile. În cadrul
protocolului IP nu este prevăzut nici un mecanism prin care serviciul NAT să poată determina
momentul în care asocierea făcută între adresa IP internă şi o adresă NAT externă nu mai este
necesară. Deoarece TCP este un protocol orientat pe conexiune, este posibil să se obţină din
antetul TCP un raport asupra stării conexiunii (cel puţin dacă conexiunea s-a încheiat sau nu),
în timp ce UDP nu poate furniza o astfel de informaţie. Prin urmare, în acest caz este necesară
configurarea unui interval de timp maxim în care NAT să menţină o asociere de adrese înainte
de a returna adresa IP externă listei NAT de adrese disponibile. În general, valoarea implicită
a acestui contor este de 15 minute.
De asemenea, administratorii reţelei trebuie să specifice NAT dacă toate staţiile interne au
dreptul de a utiliza NAT sau nu. Acest lucru se realizează prin configurarea corespunzătoare a
NAT. Dacă sistemele din reţeaua externă iniţiază o transmisie către sisteme din reţeaua
internă, atunci NAT trebuie configurată în prealabil astfel încât să cunoască care dintre
adresele NAT externe poate fi asociată unei anumite adrese IP interne. Astfel, ar trebui
definită o asociere statică pentru a permite legături din reţelele externe către un anumit sistem
din reţeaua internă. Trebuie menţionat faptul că adresele NAT externe fiind asociate static
unor adrese IP interne nu se pot suprapune cu adresele specificate în lista de adrese externe
disponibile, pe care NAT le asociază la cerere. Spre exemplu, serverul de nume extern poate
conţine o corespondenţă de nume pentru un server de poştă electronică care rulează pe o
maşină din reţeaua internă. În acest caz, serverul extern de nume rezolvă numele sistemului
public al serverului intern de poştă electronică cu o adresă asociată static (adresa externă), iar
serverul extern de poştă va trimite cererea de conexiune către acestă adresă IP. Atunci când
cererea ajunge la serviciul NAT pe interfaţa externă, acesta citeşte lista de reguli de asociere
pentru a decide dacă conţine o asociere statică între adresa publică IP externă specificată şi o
 Arhitectura Reţelelor şi Internet 11

adresă IP internă. Dacă există o astfel de asociere, atunci NAT translatează adresa IP şi
redirectează pachetul IP în reţeaua internă către serverul de poştă electronică.

2.1.4.3 Translatarea adreselor de reţea şi a porturilor NAPT

Diferenţa dintre NAT de bază şi NAPT este că NAT de bază se limitează doar la
translatarea adreselor IP, în timp ce NAPT este extins pentru a include adresele IP, precum şi
identificatorii de nivel transport (cum ar fi porturile TCP/UDP sau identificatorii cererilor
ICMP). Aşa cum este ilustrat în figura 2.9, NAPT poate translata mai multe adrese de reţea şi
identificatorii lor de nivel transport într-o singură adresă de reţea cu mai mulţi identificatori
de nivel transport (cu mai multe porturi).

Fig. 2.9 Translatarea adreselor de reţea şi a porturilor NAPT.

NAPT poate asocia mai multe adrese private unei singure adrese globale. Astfel, se
realizează o legătură între adresa privată cu portul privat şi adresa externă şi portul extern,
asociate.
NAPT permite mai multor noduri dintr-o reţea locală să acceseze simultan reţele externe
folosind o singură adresă IP asociată ruterului acestora.

2.1.5.4 Limitările NAT

S-a constatat că NAT funcţionează bine pentru adresele IP aflate în antetul datagramelor
IP. Unele protocoale de nivel aplicaţie îşi transmit între ele informaţia legată de adresele IP în
câmpul de date al pachetelor IP, iar NAT în general nu este capabil să efectueze translatarea
adreselor IP utilizate de protocolul aplicaţie. Trebuie menţionat că implementarea NAT pentru
o anumită aplicaţie care utilizează informaţia IP în datele de aplicaţie este mult mai
complicată decât implementările NAT standard.
NAT utilizează foarte multe resurse pentru calcul chiar şi în cazul în care este ajutat de un
algoritm de calcul al sumei de verificare, deoarece fiecare pachet este prelucrat de algoritmii
de asociere cu lista de adrese oficiale şi de modificare corespunzătoare a adreselor.

2.1.6 Rutarea intre domenii fără clase (CIDR)

Rutarea IP clasică utilizează numai adresele de reţea din clasele A, B şi C. În fiecare dintre
aceste reţele se poate utiliza divizarea în subreţele pentru o mai bună granularitate. Totuşi, nu
există nici o posibilitate de a stabili o anumită relaţie între mai multe reţele de clasă C, spre
exemplu. Consecinţa acestor neajunsuri poartă numele de problemă a explodării tabelei de
rutare. Spre exemplu, o reţea de clasă B de 3000 de sisteme necesită o singură intrare în
tabela de rutare la fiecare dintre ruterele de magistrală (backbone routers). Dacă acelaşi
domeniu este adresat ca o mulţime de reţele de clasă C, atunci este nevoie de 16 intrări în
 12 2. Nivelul Reţea

tabela de rutare. Soluţia la această problemă este rutarea între domenii fără clase de adrese
CIDR (Classless Inter-Domain Routing).
CIDR nu efectuează rutarea după clasa din care face parte reţeaua (de aceea se numeşte
fără clase). Această metodă se bazează numai pe biţii cei mai semnificativi ai adresei de reţea,
care constituie prefixul IP.
Fiecare locaţie din tabela de rutare CIDR conţine o adresă de 32 de biţi şi o mască de reţea
de 32 de biţi, care împreună permit identificarea lungimii şi a valorii prefixului IP. Această
locaţie este reprezentată ca o structură <adresă_IP mască_reţea>. Spre exemplu, pentru a
adresa un grup de 8 adrese de clasă C cu o singură locaţie în tabela de rutare este suficientă
următoarea reprezentare: <192.32.136.0 255.255.248.0>. Această informaţie face referire la
domeniul de reţele de clasă C, în ordine, de la 192.32.136.0 până la 192.32.143.0, care este
văzut ca o singură reţea. Acest exemplu este ilustrat în figura 2.10.

Fig. 2.10 Exemplu de rutare între domenii fără clase, CIDR.

Această metodă de combinare a mai multor reţele într-o singură structură de rutare poartă
numele de super-divizare în subreţele (supernetting). Rutarea CIDR se efectuează pe baza
unor măşti de reţea care sunt mai scurte decât măştile de reţea obişnuite pentru o adresă IP.
Această metodă este total opusă divizării în subreţele.

2.2 PROTOCOLUL DE MESAJE DE CONTROL PENTRU INTERNET (ICMP)

Aşa cum s-a menţionat, protocolul IP furnizează un serviciu fără conexiune. Fiecare pachet
trece din ruter în ruter pentru a ajunge de la sistemul sursă la sistemul destinaţie. Protocolul IP
nu garantează livrarea fiecărui pachet la destinaţie dar utilizează un mecanism (protocol) care
permite oricărui ruter să semnaleze sistemului sursă o situaţie anormală apărută în rutarea
unui pachet. Acelaşi mecanism poate fi folosit de un sistem pentru a testa dacă un alt sistem
este accesibil, adică dacă există o rută în funcţionare normală până la acel sistem şi dacă
sistemul este capabil să recepţioneze pachete. Acest mecanism este reprezentat de protocolul
ICMP (Internet Control Message Protocol).
Protocolul ICMP permite ruterilor să transmită altor ruteri sau sistemelor mesaje de eroare
sau de control. De asemenea ICMP permite comunicaţia între software-ul IP de pe un sistem
şi software-ul IP de pe un alt sistem.
ICMP este utilizat pentru a raporta erorile şi nu pentru a face protocolul IP mai fiabil. În
continuare, se poate întâmpla ca datagramele să nu fie livrate la destinaţie şi să nu se raporteze
pierderea acestora. Fiabilitatea transmisiunii se poate creşte numai prin implementarea unor
funcţii adecvate în protocoalele de nivel superior, care folosesc serviciile IP.
Pentru datagrame fragmentate, mesajele ICMP sunt transmise numai pentru eventuale erori
produse în cazul primului fragment. Astfel, mesajele ICMP nu vor face niciodată referire la o
datagramă IP cu o valoare nenulă a câmpului IP care specifică decalajul de fragment.
 Arhitectura Reţelelor şi Internet 13

Mesajele ICMP nu sunt transmise ca răspuns la o problemă legată de o datagramă care nu

are adresa sursă ce desemnează un sistem unic (unicast). Astfel, adresa sursă nu poate fi zero,
o adresă de transmisie în buclă (loopback), o adresă de difuzare (broadcast) sau o adresă de
grup (multicast).
Fiecare mesaj ICMP este inclus în câmpul de date al unui pachet (figura 2.11) care, la
rândul său, este inclus în câmpul de date al unui cadru. În antetul IP numărul de protocol ia
valoarea 1 pentru ICMP, iar tipul de serviciu ia valoarea zero, ceea ce desemnează o rutină.

Fig. 2.11. Încapsularea mesajului ICMP.

Pachetele care poartă mesaje ICMP sunt rutate la fel ca şi cele care transportă datele
utilizatorului doar că, dacă apar erori în transmiterea acestor pachete ele nu generează alte
mesaje ICMP. Există mai multe tipuri de mesaje ICMP, fiecare având formatul său propriu.
Câmpul de date din pachetul IP care conţine un mesaj ICMP este ilustrat în figura 2.12.

Fig. 2.12 Formatul mesajului ICMP.

Indiferent însă de tipul mesajului fiecare format începe cu aceleaşi trei câmpuri în antet:

- Tipul mesajului – Acest câmp poate lua una dintre următoarele valori (8 biţi), în
funcţie de tipul mesajului:
o 0 - Răspuns ecou (Echo reply),
o 3 - Destinaţie inaccesibilă (Destination unreachable),
o 4 - Oprirea sursei (Source quench),
o 5 - Redirectare,
o 8 - Cerere ecou,
o 9 - Anunţarea unui ruter,
o 10 - Solicitarea unui ruter,
o 11 - Depăşire timp,
o 12 - Problemă legată de un parametru,
o 13 - Cerere etichetă de timp,
o 14 - Răspuns etichetă de timp,
o 17 - Cerere mască de adrese,
o 18 - Răspuns mască de adrese,
o 30 - Descoperire rută (Traceroute),
o 37 - Cerere nume domeniu,
o 38 - Răspuns nume domeniu.
 14 2. Nivelul Reţea

- Cod - Conţine codul erorii pentru datagrama raportată de acest mesaj ICMP.
Interpretarea acestui câmp depinde de tipul mesajului. Acest câmp este format din 8
biţi şi furnizează informaţii suplimentare despre tipul mesajului.
- Suma de verificare - Conţine suma de verificare (16 biţi), folosind acelaşi algoritm ca
şi IP dar verificând numai mesajul ICMP, începând cu câmpul dedicat tipului
mesajului. Dacă valoarea sumei nu coincide cu valoarea calculată la recepţie pe baza
conţinutului recepţionat, atunci datagrama este eliminată.

Câmpul de date al mesajului conţine informaţia corespunzătoare mesajului ICMP curent.

De cele mai multe ori, acest câmp conţine o porţiune din pachetul IP original, cel pentru care
a fost generat mesajul ICMP curent.
Două dintre mesajele ICMP, foarte utilizate de administratori de reţele şi de către
utilizatori pentru a verifica existenţa unei rute funcţionale spre o anumită destinaţie, sunt
mesajele de cerere ecou (echo request) şi răspuns ecou (echo replay). Un sistem de
extremitate sau un ruter poate transmite un mesaj cerere ecou către o anumită destinaţie.
Sistemul sau ruterul de destinaţie care recepţionează acest mesaj răspunde prin mesajul
răspuns ecou transmis către sursă. Cererea conţine un câmp de date opţionale. Răspunsul va
conţine o copie a acestor date. În felul acesta se poate verifica dacă o anumită destinaţie este
accesibilă şi răspunde. Totodată este verificată şi o parte din reţea.
Un alt tip de mesaj ICMP, numit destinaţie inaccesibilă (destination unreachable) este
transmis de un ruter către sursă atunci când acesta nu poate trece mai departe un pachet, spre
un alt ruter sau direct spre sistemul de destinaţie. Dacă acest mesaj este recepţionat de către
sistemul destinaţie înseamnă fie că protocolul specificat în câmpul de număr de protocol al
datagramei originale nu este activ, fie că protul specificat este inactiv.
Mesajul de oprire a sursei (Source quench) este utilizat pentru a semnala înapoi la sursă o
supraîncărcare a receptorului sau a sistemelor intermediare. Dacă acest mesaj este recepţionat
de la un ruter intermediar, înseamnă că ruterul nu a mai avut spaţiu de memorie disponibil
pentru a salva datagrama. Dacă acest mesaj e recepţionat de la sistemul destinatar înseamnă că
datagramele recepţionate de acesta sosesc cu o viteză mult prea mare pentru a fi procesate în
timp real.
Mesajul de redirectare este utilizat pentru a anunţa sursa să redirecteze pachetele pe o rută
mai bună. Dacă acest mesaj e recepţionat de la un ruter intermediar înseamnă că sistemul
sursă ar trebui să trimită următoarele datagrame către ruterul a cărui adresă IP este specificată
în mesajul ICMP. Acest ruter preferat va fi întotdeauna aflat în aceeaşi subreţea cu sistemul
emitent al datagramei şi ruterul care a returnat datagrama. Ruterul redirectează datagrama
către următorul ruter spre destinaţie. Mesajul nu va fi transmis dacă datagrama IP conţine o
rută către sursă (pentru rutarea prin sursă).
Mesajele Anunţare ruter şi Cerere ruter sunt utilizate numai dacă un sistem sau un ruter
suportă un protocol de descoperire a ruterilor. Ruterii anunţă periodic adresele lor IP în toate
subreţelele pentru care lucrează. Aceste anunţuri se transmit cu adresa de destinaţie multicast
(224.0.0.1) sau cu adresa de difuzare limitată (255.255.255.255). Funcţionarea implicită
presupune transmiterea anunţurilor la fiecare 10 minute cu o valoare a TTL de 1800 (30
minute). Mesajele ICMP Anunţare ruter şi Cerere ruter conţin un câmp TTL care este diferit
de câmpul TTL din pachetul IP. Alţi ruteri vor răspunde mesajelor de solicitare pe care le
primesc. Aceştia pot răspunde direct staţiei solicitante sau pot aştepta un scurt interval aleator
de timp şi să răspundă prin multicast.
Sistemele pot trimite, la rândul lor, mesaje de solicitare. Mesajele de solicitare sunt
transmise tuturor ruterilor cu adresa multicast (224.0.0.2) sau cu adresa de difuzare limitată
(255.255.255.255). Uzual, se transmit trei mesaje de solicitare la fiecare interval de 3 secunde.
De asemenea, un sistem poate aştepta anunţuri periodice din reţea. Sistemul fixează valoarea
 Arhitectura Reţelelor şi Internet 15

temporizatorului TTL pentru actualizare cu valoarea din anunţ. Atunci când primeşte un anunţ
nou de la ruterul implicit, sistemul actualizează valoarea TTL cu cea din noul anunţ. De
asemenea, acest mecanism permite ruterilor să se declare indisponibili. Aceştia trimit anunţuri
cu o valoare zero pentru TTL.
Un alt mesaj ICMP este cel de Expirare timp. Dacă acest mesaj este recepţionat de la un
ruter intermediar înseamnă că valoarea din câmpul TTL a unui pachet IP a ajuns la zero. Dacă
mesajul este recepţionat de la un sistem de destinaţie înseamnă că timpul TTL dintr-un
fragment IP a expirat în timpul reasamblării, datorită întârzierii unui fragment.
Mesajul Problemă cu parametrii indică producerea unei erori în timpul prelucrării
parametrilor din antetul IP. Acest mesaj conţine un pointer care indică octetul din pachetul IP
original unde s-a produs problema.
Mesajele Cerere etichetă de timp şi Răspuns etichetă de timp sunt utilizate pentru depanare
şi măsurare a performanţelor. Acestea nu sunt utilizate pentru sincronizarea de ceas.
Transmiţătorul iniţializeză identificatorul şi numărul de secvenţă (care se utilizează în cazul în
care sunt transmite mai multe etichete de timp), stabileşte eticheta iniţială de timp şi transmite
pachetul către destinaţie. Staţie destinaţie actualizează etichetele de timp asociate recepţiei şi
transmisiei, modifică tipul etichetei de timp din cerere în răspuns şi o returnează staţiei sursă.
Pachetul conţine două etichete de timp dacă există o diferenţă semnificativă de timp între
timpul de recepţie şi timpul de emisie. În practică, cele mai multe implementări efectuează
ambele operaţii (recepţia şi răspunsul) într-un singur pas. În acest caz ambele etichete de timp
sunt setate cu aceeaşi valoare.
Mesajele Cerere de mască de adrese şi Răspuns cu mască de adrese. Cererea de mască de
adrese este utilizată de către un sistem pentru a determina masca subreţelei folosită în cadrul
unei reţele asociate. Cele mai multe sisteme sunt configurate cu masca (sau măştile) de
subreţea asociată. Totuşi, unele sisteme, cum ar fi staţiile de lucru fără disc, trebuie să obţină
această informaţie de la server. Un sistem foloseşte protocolul RARP (Reverse Address
Resolution Protocol) pentru a obţine adresa sa IP. Pentru a obţine masca de subreţea, sistemul
transmite prin difuzare cererea de mască de adresă. Oricare sistem din reţea care a fost
configurat să răspundă la cererile de mască a adreselor va completa în cerere masca de
subreţea, va converti pachetul într-un răspuns cu masca de adrese şi îl va returna staţiei
solicitante.
Mai există şi alte mesaje ICMP pentru semnalizarea unor situaţii de congestie (atunci când
un ruter este prea încărcat pentru a prelucra un nou pachet, care din acest motiv va fi pierdut),
semnalizarea unei rutări ciclice (o rută infinită, propagare în buclă), etc.

2.4 PROTOCOLUL DE REZOLUŢIE A ADRESELOR (ARP)

Protocoalele de rutare sunt responsabile pentru modul în care o datagramă IP ajunge în
reţeaua fizică căreia îi este destinată, dar o altă procedură este necesară pentru modul în care o
datagramă ajunge la sistemul sau ruterul din acea reţea.
Principala problemă o constituie faptul că datagramele IP conţin adrese globale logice, de
nivel trei, dar interfaţa fizică hardware aflată în sistemul destinaţie sau în ruterul destinaţie nu
utilizează decât schema de adresare locală a acelei reţele. Astfel, este nevoie să se efectueze
translatarea adresei IP într-o adresă de nivel legătură de date care este înţeleasă de interfeţele
din această reţea.
O modalitate simplă de a mapa o adresă IP pe o adresă fizică este aceea de a coda adresa fizică
a sistemului în adresa IP a sistemului. De exemplu, un sistem cu o adresă fizică
0001000100101001 (care în zecimal înseamnă 33 pentru primul octet şi 81 pentru ultimul) poate
avea adresa IP 128.96.33.81. Deşi această soluţie a fost adoptată pentru unele reţele, ea prezintă
totuşi limitări din cauza faptului că adresa fizică nu poate fi mai mare de 16 biţi în acest exemplu
(clasa B); pentru reţelele de clasă C nu poate depăşi 8 biţi. Această metodă nu funcţionează pentru
 16 2. Nivelul Reţea

adresele Ethernet pe 48 de biţi. O soluţie mai generală poate fi aceea ca fiecare sistem să menţină
o tabelă de perechi de adrese, care să mapeze adresele IP pe cele fizice. Această tabelă poate fi
menţinută de un administrator de sistem şi trimisă fiecărui sistem din reţea sau poate fi o tabelă
dinamică instalată pe fiecare sistem care să fie actualizată din reţea.
Toate aceste probleme se pot rezolva cu ajutorul protocolului ARP (Address Resoludon Pro-
tocol). Scopul acestui protocol este acela de a permite fiecărui sistem din reţea să-şi constru-
iască o tabelă de mapări între adresele de IP şi cele fizice. Acest set de mapări este cunoscut
sub numele de ARP cache sau tabelă ARP.
ARP are avantajul că multe tehologii de nivel legăturii de date, cum sunt Ethernet sau FDDI,
suportă difuzarea pentru transmiterea datelor. Dacă un sistem doreşte să transmită o datagramă IP
către un alt sistem aflat în aceeaşi reţea, acesta va verifica în primul rând tabela ARP. Dacă nu
este găsită maparea dorită, sistemul va trebui să invoce protocolul ARP prin reţea şi va face acest
lucru prin transmiterea unei cereri ARP prin reţea. Această cerere conţine adresa IP dorită. Fiecare
sistem recepţionează această cerere şi verifică dacă se potriveşte cu propria adresă IP. Dacă se
potriveşte, sistemul implicat va trimite un mesaj de răspuns care conţine adresa de nivel legătură
de date. Sursa cererii va adăuga şi această informaţie în propria tabelă ARP. Mesajul de cerere
mai include şi adresa de nivel legătură de date şi cea IP ale sursei cererii. Astfel, atunci când
un sistem trimite un astfel de mesaj de difuzare, fiecare sistem din reţea îl poate adăuga în
propria tabelă ARP. Totuşi, nu fiecare sistem realizează acest lucru. Dacă sistemul are deja
adresa în tabela ARP, acesta va reactualiza această informaţie, adică va reseta contorul aferent
ei. Sistemul care este destinaţia mesajului, va adăuga această informaţie în propria tabelă dacă nu
o are deja. Motivul acestui lucru este faptul că există o şansă foarte mare ca sistemul sursă să
înceapă să transmită mesaje de nivel aplicaţie la care vor trebui trimise pachete de răspuns. Dacă un
sistem nu este destinatar şi nici nu are această informaţie în propria tabelă, el nu trebuie neapărat
să o introducă în tabelă. Motivul îl reprezintă faptul că există posibilitatea ca acest sistem să nu
fie niciodată destinatar. Figura 2.13 prezintă formatul pachetului ARP utilizat pentru maparea
adreselor IP-către-Ethernet. De fapt, ARP poate fi utilizat pentru multe tipuri de mapări - diferenţa
majoră fiind numai în dimensiunea adresei. Pe lângă adresele IP şi cele de nivel legătură de
date ale sursei şi destinaţiei, pachetul mai conţine:
• un câmp HardwareType, care specifică tipul reţelei fizice (exemplu, Etliernet);
• un câmp ProtocolType, care specifică protocolul de nivel superior;
• două câmpuri HLEN şi PLEN, care specifică lungimea adresei de nivel legătură de date
şi respectiv, pe cea a protocolului de nivel superior;
• un câmp Operation, care specifică dacă acest pachet este de tip cerere sau răspuns;
• adresele hardware şi de protocol pentru sursă şi destinaţie.

Fig. 2.13. Formatul pachetului ARP.

 Arhitectura Reţelelor şi Internet 17

Pentru exemplificare vom presupune ca tehnologia de nivel legătură de date utilzată este
Ethernet. Suportul fizic Ethernet poate să distingă numai formatul propriilor adrese MAC de
48 biţi. Astfel, sistemul sursă trebuie să cunoască adresa de destinaţie MAC dacă doreşte ca
pachetul care urmeazş să să ajungă cu succes la desţinatie. O solutie de a găsi adresa de
destinaţie MAC este aceea de a folosi protocolul rezolutiei adresei ARP. Ideea de baza este
ilustrată în figura 2.14:

Fig. 2.14. Exemplu de utilizare a ARP.

Presupunem ca sistemul H1 doreşte să transmită un pachet IP către H3, dar nu cunoaşte

adresa MAC a lui H3. H1 transmite mai întâi un pachet de cerere ARP, cerând informaţii
despre sistemul de destinaţie identificat cu adresa de destinaţie IP-H3, aşteptând totodata şi
răspunsul. Toate sistemele din reţea vor primi pachetul, dar unul singur îi va răspunde şi
anume, sistemul H3. Pachetul de răspuns ARP conţine adresa MAC şi adresa IP a lui H3.
Acum H1 ştie cum să trimită pachetul către H3. Pentru a evita trimiterea de fiecare data a
unui pachet ARP către H3, H1 memorează în propria tabelă ARP atât adresa IP, cât şi adresa
MAC ale lui H3, astfel fiind foarte uşor pentru H1 să trimită un pachet către H3 data viitoare.
Fiecare intrare în tabelul ARP devine la un moment dat veche, astfel conţinutul ei este golit
după o anumita perioadă de timp. Uzual, se alege o perioadă cuprinsă între 5 şi 30 minute.
Această procedură permite reactualizarea adreselor MAC în sistemul sursa. Adresa MAC se
poate schimba, spre exemplu când un card Ethernet este defect sau este înlocuit cu unul nou.

2.3 PROTOCOLUL DE REZOLUŢIE INVERSĂ A ADRESELOR (RARP)

În această situaţie sistemul cunoaşte adresa MAC, dar nu cunoaşte adresa IP pentru un
anumit sistem. De exemplu, la instalarea unui sistem de operare se poate citi adresa MAC de
pe cartela Ethernet, dar nu poate şti adresa IP. Aceasta este ţinută separat pe un disc local sau
al unui server.
Problema determinării unei adrese IP pe baza unei adrese MAC poate fi rezolvată cu
ajutorul protocolului de rezoluţie inversă a adreselor (RARP - Reverse Address Resolution
Protocol), care lucrează într-un mod asemănător cu ARP. Pentru a obţine adresa IP, sistemul
trebuie să emită în reţea un pachet de cerere RARP, care să conţină propria adresă MAC.
Toate sistemele din reţea vor primi pachetul, dar numai unul, serverul va răspunde
transmiţând către sistemul sursă un pachet RARP care conţine adresa MAC şi adresa IP. O
limitare pentru RARP ar fi dacă sistemul sursă s-ar afla într-o reţea diferită de cea a
serverului.
 18 2. Nivelul Reţea

2.4 PROTOCOLUL BOOTSTRAP (BOOTP)

Protocolul de iniţializare BOOTP (Bootstrap Protocol) permite unui staţii client să
pornească (iniţializare) cu o stivă de protocoale IP minimală şi să solicite o adresă IP, o adresă
a ruterului de ieşire (gateway) şi adresa unui server de nume, toate acestea fiind obţinute de la
un server BOOTP. De obicei, serverul şi clientul BOOTP se află pe acelaşi segment de reţea
fizică LAN. BOOTP se poate utiliza numai pe segmente interconectate cu punţi sau
comutatoare cu rutare prin sursă sau în subreţele, dacă ruterul este capabil să efectueze
redirectare de tip BOOTP.
Protocolul BOOTP a fost dezvoltat iniţial pentru a permite sistemelor fără disc dur să fie
iniţializate de la distanţă într-o reţea, cu diverse funcţii ca staţii de lucru, rutere, etc. Acesta
permite unei stive de protocoale IP simplificate, fără informaţie de configurare să obţină
suficiente informaţii pentru a porni descărcarea codului necesar de iniţializare. BOOTP nu
defineşte cum se realizează această descărcare a codului, dar de obicei aceasta se realizează cu
protocolul TFTP (Trivial File Transfer Protocol)
Deşi încă mai este utilizat intens pentru acest scop al sistemelor fără disc, BOOTP este de
asemenea utilizat ca un mecanism de livrare a informaţiei de configurare unui client care nu a
a fost configurat manual.
Procesul BOOTP implică următorii paşi:
1. Clientul determină adresa fizică proprie; aceasta se află de obicei salvată într-o
memorie ROM.
2. Un client BOOTP transmite adresa sa fizică într-un segment UDP către server. Figura
2.14 ilustrează conţinutul acestui segment. Dacă un client cunoaşte propria adresă IP
sau adresa serverului, atunci le va utiliza, dar de cele mai multe ori clienţii BOOTP nu
au deloc date de configurare IP. Dacă un client nu îşi cunoaşte adresa IP, atunci acesta
va utiliza adresa 0.0.0.0. Dacă un client nu cunoaşte adresa IP a serverului, atunci
acesta utilizează adresa de difuzare limitată (255.255.255.255).
3. Serverul primeşte segmementul UDP şi analizează adresa fizică a clientului pe care o
caută în fişierul său de configurare, care conţine şi adresa IP a clientului. Serverul
completează câmpurile celelalte din segmentul UDP şi îl returnează clientului folosind
un port UDP diferit. Pentru returnarea segmentului UDP se pot utiliza mai multe
metode:
a. În cazul în care clientul îşi cunoaşte adresa IP (şi a fost inclusă în cererea
BOOTP), serverul returnează segmentul direct către această adresă. Este foarte
probabil ca lista ARP să nu conţină adresa fizică corespunzătoare adresei IP. În
acest caz se va utiliza protocolul ARP, ca într-o situaţie normală.
b. În cazul în care clientul nu îşi cunoaşte adresa IP (a fost 0.0.0.0 în cererea
BOOTP), serverul trebuie să rezolve singur cererea consultând propria listă
ARP.
c. ARP de la server nu poate fi utilizat pentru a găsi adresa fizică a clientului
deoarece clientul nu îşi cunoaşte adresa IP şi astfel, nu se poate răspunde unei
cereri ARP. Această problemă este cunoscută sub numele de “găina şi oul”.
Există două posibile soluţii:
i. Dacă serverul are un mecanism pentru a actualiza direct propria listă
ARP fără să folosească protocolul ARP, atunci serverul îl utilizează şi
apoi trimite segmentul direct.
ii. Dacă serverul nu poate actualiza propria listă ARP, atunci trebuie să
trimită un răspuns prin difuzare.
4. Atunci când primeşte un răspuns, clientul BOOTP va salva propria adresă IP (care îi
va permite să răspundă la cererile ARP) şi să înceapă procesul de iniţializare.
 Arhitectura Reţelelor şi Internet 19

În figura 2.15 se ilustrează formatul mesajului BOOTP.

Fig. 2.15. Formatul mesajului BOOTP.

Câmpurile din mesajul BOOTP au următoarele semnificaţii:

Cod - Indică tipul mesajului, dacă este o cerere sau un răspuns:
1 – Cerere;
2 – Răspuns.
Tip hardware - Indică tipul de reţea fizică, spre examplu:
1 – Ethernet;
6 – IEEE 802 Networks.
Lungime – Specifică lungimea adresei fizice, în octeţi. Ethernet şi Token ring utilizează
ambele lungimea 6.
Hop-uri – Clientul setează valoarea acestui câmp la 0. Această valoare este incrementată
de către un ruter care retransmite cererea unui alt server şi este utilizată pentru a identifica
buclele.
Identificatorul tranzacţiei – Un număr aleator generat pentru a fi utilizat pentru a
identifica această cerere cu răspunsul primit.
Secunde – Fixat de client. Acesta reprezintă timpul în secunde consumat din momentul în
care clientul a demarat procesul de iniţializare.
Fanioane – bitul cel mai semnificativ al acestui câmp este utilizat ca fanion de difuzare.
Toţi ceilalţi biţi trebuie setaţi cu valoarea zero, fiind rezervaţi pentru utilizări ulterioare. În
mod normal, serverele BOOTP încearcă să livreze mesajele BOOTP de răspuns direct unui
client folosind adresa de destinaţie unică. Adresa destinaţie din cadrul antetului IP este fixată
cu valoarea adresei IP proprie BOOTP, iar adresa MAC este fixată cu valoarea adresei fizice
– client BOOTP. Dacă un sistem nu este capabil să primească un pachet IP cu destinaţie unică
înainte de a-şi afla adresa sa IP, acest bit de difuzare trebuie fixat cu valoarea 1 pentru a indica
serverului că răspunsul BOOTP trebuie transmis sub formă de difuzare la nivel IP şi MAC. În
caz contrar, acest bit va avea valoarea 0.
Adresa IP client – Fixat de client, fie cu valoarea adresei IP proprii (pe care o cunoaşte)
sau cu 0.0.0.0.
 20 2. Nivelul Reţea

Adresa IP proprie – Fixat de server dacă câmpul de adresă IP client are valoarea 0.0.0.0.
Adresa IP server – Fixat de server.
Adresa IP ruter – Aceasta este adrea unui agent de redirectare BOOTP, care nu este un
ruter IP obişnuit şi va fi utilizată de către client.
Adresa fizică client – Fixat de către client şi utilizat de server pentru a identifica clientul
înregistrat care a demarat iniţializarea.
Numele server-ului – Numele opţional al serverului, care se termină cu X'00'.
Numele fişierului de iniţializare – Clientul fie lasă acest câmp cu valoarea nulă, fie
specifică un anumit nume, astfel încât să indice tipul de iniţializare care trebuie demarată.
Serverul va returna numele fişierului de iniţializare, care este cel potrivit pentru cererea
clientului.
Identificatorul producătorului – câmp opţional. Aceste opţiuni pot fi furnizate clientului
la momentul iniţializării împreună cu adresa sa IP. Spre exemplu, clientul poate recepţiona în
plus, adresa unui ruter implicit, adresa serverului de nume de domeniu şi masca subreţelei.
După ce clientul BOOTP a procesat răspunsul, acesta poate demara transferul fişierului de
iniţializare şi să execute procesele de iniţializare. În cazul unui sistem fără disc, întregul
proces de iniţializare va înlocui, în mod normal, stiva minimală de protocoale IP încărcată din
ROM cu o stivă IP normală transferată ca o parte a fişierului de iniţializare şi care conţine
configuraţia corectă a clientului.

2.5 Dynamic Host Configuration Protocol (DHCP)

Protocolul de configurare dinamică a hosuturilor oferă un cadru pentru transferul
informațiilor de configurare către hosturi într-o rețea TCP/IP. DHCP se bazează pe protocolul
BOOTP, adăugând capabilitatea de a aloca automat o adresă de rețea și opțiuni de configurare
suplimentare. Mesajele DHCP utilizează portul UDP 67, port pentru servere BOOTP și portul
UDP 68, port pentru clienți BOOTP.
DHCP constă din două componente:
- Un protocol care livrează parametrii pentru o configurație specifică hostului de la un
server DHCP către un host.
- Un mecanism de alocare temporară sau permanentp a unei adrese de rețea unui host.
IP cere setarea multor parametri în implementarea software a protocolului. Deoarece IP
poate utiliza multe tipuri diferite de hardware de rețea, valorile acestor parametri sunt greu de
presupus că vor fi corecte implicit. Utilizarea unei scheme de alocare distribuită de adrese, a
unui mecanism de descoperire a adreselor de rețea aflate deja în folosință nu pot garanta
unicitatea adresei de rețea, deoarece hosturile pot fi la un moment dat în imposibilitatea de a-
și “apăra” propia adresă.
DHCP suportă trei mecanisme de alocare a adresei IP:
- Alocare automată: DHCP atribuie permanent o adresă IP unui host.
- Alocare dinamică: DHCP atribuie temporar o adresă IP. O astfel de adresă este numită
lease. Acesta este unicul mecanism care permite utilizarea automată a unei adrese care
nu mai este necesară hostului căruia îi fusese atribuită.
- Alocare manuală: Adresa hostului este atribuită manual de către un administrator de
rețea.

2.5.1 Formatul mesajului DHCP

Formatul mesajului DHCP este dat în Figura 2.16.
Semnificația câmpurilor este următoarea:
 Arhitectura Reţelelor şi Internet 21

Code Indică o cerere sau un răspuns:

1 Cerere
2 Răspuns

HWtype Tipul hardware, de exemplu:

1 Ethernet
6 Rețele IEEE 802

Figura 2.16: Formatul mesajului DHCP

Length Lungimea adresei hardware, în octeți

Hops Clientul setează câmpul la valoarea 0. Valoareqa este incrementată de
un ruter care retransmite cererea către un alt server și este utilizată pentru a identifica bucle.
Valoarea 3 indică o buclă. (Valoare sugerată de RFC 951)
Transaction ID Un număr aleator utilizat pentru a marca întrebarea și răspunsul generat
pentru aceasta.
Seconds Setat de client. Reprezintă timpul în secunde de când clientul a pornit pricesul
de bootare.
Flags field Cel mai semnificativ bit este utilizat ca indicator de broadcast. Toți ceilalți biți
sunt rezervați pentru urtilizări ulterioare și trebuie setați în 0. În mod normal, serverele DHCP
livrează mesajele DHCP utilizând transmisia unicast. Adresa destinație din antetul pachetului
IP este setată la DHCP your IP addres, iar adresa MAC la DHCP client hardware address.
Dacă un host nu este capabil să recepționeze o datagramă IP până nu își cunoaște adresa IP,
acest bit de broadcast trebuie setat pentru a indica serverului că trebuie să răspundă printr-o
transmisie broadcast. Altfel, bitul trebuie trecut în zero.
Client IP address Setată de client. Dacă o cunoaște, adresa IP, sau altfel 0.0.0.0.
 22 2. Nivelul Reţea

Your IP address Setată de server dacă a recepționat un câmp client IP address ca 0.0.0.0.
Server IP address Setată de către server.
Router IP address Aceasta este adresa unui agent BOOTP, nu a unui ruter obișnuit. Este
setată de un agent transmițător.
Client hardware address Setată de client. DHCP definește un identificator opțional
pentru client, utilizat pentru identificarea clientului. Dacă această opțiune nu este utilizată,
clientul va fi identificat după adresa MAC.
Server host name Opțional, un nume de host pentru server, terminat în X’00’
Boot file name Clientul fie lasă acest câmp necompletat, fie specifică un nume generic,
indicând tipul fișierului boot care să fie utilizat. Într-o cerere DHCPDISCOVER, este setat în
zero. Serverul returnează numele complet pentru o cale de directoare în cererea
DHCPOFFER. Valoarea este terminată în X’00’.
Options Primii patru octeți conțin 99.130.83.99. Cei rămași indică parametrii doriți.

2.5.2 Tipuri de mesaje DHCP

Mesajele DHCP formează următoarele categorii:
- DHCPDISCOVER: Transmis broadcast de către un client pentru a găsi un server
DHCP disponibil
- DHCPOFFER: Răspunsul unui server la DHCPDISCOVER și oferirea unui adrese IP
și a altor parametri
- DHCPREQUEST: Mesaj de la un client către server având una dintre semnificațiile:
o Cerere de parametri oferiți de unul dintre servere, declinând orice altă ofertă
o Verifică o adresă alocată anterior după ce are loc o modificare de sistem sau
rețea
o Cere prelungirea termenului pentru o adresă temporară.
- DHCPACK: Confirmare de la un server către un client, conținând parametri, inclusiv
adresă IP.
- DHCPNACK: Confirmare negativă de la server la client, indicând faptul că adresa
temporară a clientului a expirat sau că cererea de adresă IP este incorectă.
- DHCPDECLINE: Mesaj de la client spre server indicând că adresa oferită este deja în
utilizare.
- DHCPRELEASE: Mesaj de la client către server prin care se cere înlocuirea unei
adrese temporare cu una permanentă.
- DHCPINFORM: Mesaj de la un client care are adresă IP (configurată eventual
manual), dar care dorește parametri de configurare de la un derver DHCP

2.5.3 Alocarea unei adrese de rețea

În continuare este prezentată interacțiunea client-server, situația în care clientul nu își
cunoaște adresa. Presupunem că serverul DHCP are un bloc de adrese de rețea din care poate
satisface cereri de noi adrese. Fiecare server menține o bază de date a adreselor alocate
(permanent sau temporar) în memoria locală.
Procedura următoare descrie pașii din Figura 2.17.
1. Clientul transmite broadcast un mesaj DHCPDISCOVER în subrețeaua fizică locală.
În acest punct clientul se găsește în starea INIT. Mesajul DHCPDISCOVER poate
include câteva opțiuni cum ar fi sugestii privind adresa de rețea sau durata unei adrese
temporare (lease).
Arhitectura Reţelelor şi Internet 23

Figura 2.17: Interacțiunea dintre client DHCP și server DHCP

2. Fiecare server răspunde cu un mesaj DHCPOFFER care include o adresă de rețea
disponibilă (your IP address) și alte opțiuni de configurare. Serverul memorează
adresa oferită clientului pentru a preveni oferirea aceleași adrese unui client care
transmite un mesaj DHCPDISCOVER înainte ca primul client să-și încheie
configurarea.
3. Clientul recepționează unul sau mai multe mesaje DHCPOFFER de la unul sau mai
multe servere. Clientul alege unul, bazându-se pe parametrii de configurare oferiți și
transmite broadcast mesajul DHCPREQUEST care include identificatorul serverului
al cărui mesaj a fost ales și adresa IP luată din câmpul your IP address.
4. În cazul în care nu este recepționată nici o ofertă, dacă clientul cunoaște o adresă de
rețea anterioară, va utiliza acea adresă dacă este încă validă până când va expira (este
vorba despre o adresă lease).
5. Serverele recepționează mesajul broadcast DHCPREQUEST. Acele servere care nu au
fost selectate prin mesajul DHCPREQUEST utilizează mesajul pentru a notifica faptul
că oferta lor a fost declinată de către client. Serverul selectat în DHCPREQUEST
marchează clientul ca fiind stabil, menține datele corespunzătoare în memorie și
răspunde cu un mesaj DHCPACK conținând parametrii de configurare ceruți de către
client. Combinația dintre hardware-ul clientului și adresa de rețea atribuită constituie
un identificator unic pentru adresa temporară (lease) a clientului și este utilizat atât de
către client, cât și de către server pentru a identifica o referire la lease în orice mesaj
DHCP. Câmpul your IP address din mesajul DHCPACK va fi umplut cu adresa de
rețea selectată.
6. Clientul recepționează mesajul DHCPACK cu parametrii de configurare. Clientul
realizează o verificare finală a parametrilor, de exemplu cu ARP pentru adresa de rețea
24 2. Nivelul Reţea

alocată, și notează durata de valabilitate a adresei și identificatorul adresei din mesajul

DHCPACK. În acest moment clientul s-a configurat.
7. Dacă detectează o problemă cu parametrii din mesajul DHCPACK (adresa se află deja
în folosință în rețea), clientul va transmite către server un mesaj DHCPDECLINE și
repornește procesul de configurare. Clientul va aștepta minimum zece secunde pentru
a reporni procesul de configurare pentru a evita un trafic de rețea excesiv în ncazul
unei bucle. La recepția unui mesaj DHCPDECLINE serverul trebuie să marcheze
faptul că adresa oferită nu este disponibilă (și eventual informează administratorul de
sistem că există o problemă de configurare).
8. În cazul în care clientul recepționează un mesaj DHCPNACK, va reporni procesul de
configurare.
9. Clientul poate alege să-și elibereze adresa temporară (lease) prin transmiterea unui
mesaj DHCPRELEASE către server. Clientul identifică adresa lease care o vrea
eliberată prin includerea în mesaj a adresei de rețea și a adresei hardware.
 3. Rutarea în reţelele cu comutare de pachete

Funcţia principală a nivelului reţea o constituie rutarea pachetelor de la maşina

sursă către maşina destinaţie. Algoritmii care sunt utilizaţi pentru alegerea rutelor şi a
structurii datelor sunt părţile principale care determină realizarea nivelului reţea.
Algoritmii de rutare sunt acea parte din zona logică a nivelului reţea care are
responsabilitatea de a decide pe care linie de ieşire va fi transmis un pachet care tocmai
a sosit. Dacă reţeaua utilizează în interior datagrame, această decizie va fi luată pentru
fiecare pachet în parte. Dacă în interior reţeaua utilizează circuite virtuale, decizia de
rutare se va lua numai în faza de iniţializare a circuitului. Prin urmare pachetele care
transportă informaţia vor urma apoi aceeaşi cale. O comparaţie între cele două moduri
de funcţionare a reţelei este făcută în tabelul următor.

Subiect Reţea datagrame Reţea circuit virtual

Adresare Fiecare pachet deţine Fiecare pachet conţine
adresa completă a numărul circuitului virtual
destinatarului şi a sursei
Informaţii de rutare Reţeaua nu păstrează nici o Fiecare circuit virtual
informaţie stabilit este trecut într-un
tabel de rutare
Rutarea Fiecare pachet are o dirijare Dirijarea este stabilită
independentă numai la iniţializare şi apoi
se urmează aceeaşi cale
Consecinţa defectării unui Se pierd toate pachetele Toate circuitele virtuale
nod din nodul respectiv care trec prin nodul
respectiv sunt distruse.
Controlul congestiei Dificil Uşor de realizat dacă la
iniţializarea circuitului se
prevăd memorii tampon.
Complexitatea La nivelul transport La nivelul reţea
Adaptat la Servicii cu sau fără Servicii cu conexiune
conexiune

Algoritmii de rutare pot fi împărţiţi în două mare clase: algoritmi adaptivi şi

algoritmi neadaptivi. Algoritmii neadaptivi nu îşi fondează decizia de dirijare pe
măsurători sau estimări ale traficului în timp real, ţinând seama de topologia reţelei.
Din contră, alegerea unei rute pentru a ajunge de la un nod la altul este calculată

1
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
dinainte şi introdusă la iniţializarea reţelei în fiecare nod, sub forma unor tabele de
rutare. Această procedură poartă numele de rutare fixă sau statică.
Spre deosebire de algoritmii de rutare fixă, cei adaptivi îşi modifică deciziile de
rutare pentru a se pune în acord cu schimbările de trafic sau de topologie care au loc pe
parcurs. Există trei familii de algoritmi adaptivi care diferă prin maniera în care sunt
utilizate datele. Există algoritmi globali care utilizează date culese din întreaga reţea
pentru a lua cele mai bune decizii. Aceştia sunt algoritmii centralizaţi. Mai există
algoritmii locali care se execută separat în fiecare nod al reţelei şi nu utilizează decât
informaţiile care sunt disponibile la nivelul nodului (spre exemplu lungimea firelor de
aşteptare). Aceştia sunt numiţi algoritmi izolaţi sau locali. A treia clasă de algoritmi
adaptivi utilizează un amestec între informaţii locale şi cele globale. Dacă un algoritm
adaptiv se adaptează bine la trafic, atunci el este mai bun decât un algoritm care nu ţine
seama de ceea ce se întâmplă în reţea.
Funcţionarea unei reţele de comunicaţii este dependentă de asigurarea unui
algoritm de dirijare adecvat. Într-o reţea cu comutare de circuite, algoritmul
funcţionează în timpul stabilirii circuitului atunci când se selectează o rută. Într-o reţea
cu comutare de pachete algoritmul poate fie să determine ruta în mod individual pentru
fiecare pachet, fie să stabilească o rută care va fi urmată de către o secvenţă de pachete.
Dificultatea dirijării în orice reţea este dată de topologia reţelei.
Pentru reţele foarte simple, dirijarea nu constituie o problemă. Astfel, pentru o
reţea în stea cu linii duplex, fiecare nod din reţea care acceptă şi livrează trafic
utilizatorilor este conectat la un singur nod, nodul central. Prin nodul central trebuie să
treacă tot traficul. Nodul central posedă informaţiile care definesc topologia reţelei.
Fiecare nod destinatar este conectat la nodul central printr-o linie distinctă, iar tabela de
dirijare a nodului central indică pentru fiecare destinaţie linia de ieşire corespunzătoare.
Rezultă un algoritm de dirijare dintre cele mai simple.

1 4
C

2 3

Figura 3.1: Topologie de reţea în stea

O a doua structură foarte simplă de reţea o constituie reţeaua în care nodurile
sunt conectate în inel. Dacă liniile sunt duplex, traficul poate ajunge la orice destinaţie
de la orice sursă, în orice direcţie, parcurgând traseul în inel. Şi în acest caz rezultă un

2
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
algoritm foarte simplu în care nu este nevoie nici măcar de o tabelă de dirijare, lucru
care constituie o caracteristică esenţială a acestui tip de reţea. Se poate pune însă o
problemă: în majoritatea cazurilor ruta pe o direcţie este mult mai scurtă decât în
cealaltă direcţie. În acest caz se poate prevedea o tabelă de dirijare în fiecare nod care să
indice calea cea mai scurtă către fiecare destinaţie. O altă soluţie ar fi aceea ca fiecare
nod să calculeze, pe baza sistemului de numerotare a nodurilor, care este calea cea mai
scurtă şi să ia o decizie de direcţie.
1

2 5

3 4

Figura 3.2: Topologie de reţea în inel

O altă structură care poate utiliza sistemul de numerotare a nodurilor în

algoritmul de dirijare este cea sub formă de matrice rectangulară regulată, caz în care
există de regulă cel puţin două căi egale de cea mai mică lungime între o sursă şi o
destinaţie. Excepţia o constituie nodurile vecine. Într-o astfel de topologie numerotarea
nodurilor se face astfel încât să indice linia şi coloana ocupate de către fiecare nod în
matrice. Rezultă necesitatea ca fiecare nod să cunoască cum trebuie să direcţioneze
traficul spre nodurile de pe liniile şi coloanele cu numere mai mari sau mai mici. Aceste
informaţii pot fi inserate în fiecare nod sub forma unor tabele de dirijare rudimentare.

11 12 13

21 22 23

31 32 33
Figura 3.3: Reţea sub formă de matrice rectangulară regulată

Un al patrulea tip de structură de reţea care necesită algoritmi de dirijare foarte

simpli este reţeaua arborescentă, la care sistemul de adresare poate fi proiectat pentru a
specifica în mod unic calea de urmat de la un nod la altul. Într-o astfel de reţea există un

3
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
singur drum de la un nod sursă la un nod destinaţie. La acest tip de reţea informaţiile de
dirijare pot fi conţinute în adresă. Nu mai sunt necesare tabele de dirijare în noduri, ci
numai o indicaţie privind modul în care se va parcurge arborele: în sus sau în jos.

11 12

111 112 121 122

Figura 3.4: Structură de reţea arborescentă

Un ultim tip de reţea care utilizează algoritmi de dirijare simpli este reţeaua
conectată total. În acest caz fiecare nod are o linie directă cu toate celelalte noduri şi
deţine o tabelă de dirijare în care se defineşte linia unică de utilizat pentru a ajunge la
destinaţie.

1 4

2 3

Figura 3.5: Reţea total conectată

Aceste topologii care conduc la algoritmi de dirijare simpli se întâlnesc în

practică, dar destul de rar, majoritatea reţelelor reale având topologii mult mai
complexe, cu configuraţii parţial conectate. Localizarea nodurilor reţelei este dictată în
general de cerinţele utilizatorilor. Liniile ce unesc nodurile depind de disponibilitatea
rutei şi lăţimii de bandă, consideraţiile privind costul având un rol determinant.
Pentru o reţea cu comutare de pachete parţial conectată se poate decide
neutilizarea unui algoritm sistematic de dirijare pentru cazul în care topologia reţelei nu
este suficient de bine cunoscută în fiecare nod, sau pentru o topologie în continuă
transformare. În acest caz pachetele pot fi transmise fie prin dirijare prin inundare (copii
ale unui pachet sunt transmise pe toate liniile de ieşire dintr-un nod), fie prin dirijare

4
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
aleatoare (o singură copie a unui pachet este transmisă de un nod pe o linie aleasă la
întâmplare).
În reţelele moderne cu comutaţie de pachete sunt mult mai folosite tehnici de
dirijare care asigură o înaintare sistematică a fiecărui pachet de la sursă la destinaţie.
Acest lucru se realizează printr-un proces de dirijare care în fiecare nod caută să
selecteze pentru fiecare pachet linia de ieşire cea mai adecvată pe care să transmită
pachetul. Adresa conţinută în antetul pachetului trebuie să conţină adresa destinatară,
sau adresele destinatarilor în cazul destinaţiilor multiple. Folosind adresa destinatarului
extrasă din antet, procesul de dirijare caută într-o tabelă de dirijare informaţiile necesare
pentru a determina linia de ieşire optimă după un anumit criteriu. Criteriul de alegere a
liniei de ieşire poate fi simplu, alegând calea de lungime minimă, sau poate fi complicat
prin încercarea de a lua în consideraţie măsuri locale şi/sau globale ale încărcării
componentelor reţelei (ale nodurilor şi ale liniilor).
Nodul trebuie să fie capabil să recunoască destinaţia fiecărui pachet şi să
folosească această destinaţie pentru accesul în tabela de dirijare care va indica linia
unică din nod pe care trebuie transmis fiecare pachet. Dificultatea constă în calcularea
tabelelor de dirijare pentru fiecare nod din reţea. Calculul cel mai simplu este pentru
cazul în care se doresc tabele care să furnizeze calea cea mai scurtă între fiecare sursă şi
destinaţie. Urmând această cale, se defineşte un arbore pentru fiecare nod destinaţie din
reţea, cu vârful în acel nod. Arborele astfel format va defini un set de căi, una de la
fiecare nod sursă din reţea către nodul destinaţie.

Figura 3.6: Reţea distribuită parţial conectată

Fie reţeaua din figura 3.6 reprezentând o reţea distribuită parţial conectată.
Arborele care defineşte setul format din cele mai scurte căi pentru un nod destinatar
notat D este prezentat în figura 3.7. Calea cea mai scurtă de la un nod la o destinaţie are
caracter markovian. Aceasta înseamnă că istoria circulaţiei pachetului (nodul de

5
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
origine, noduri vizitate, linii traversate) nu influenţează desemnarea căii celei mai
scurte între două noduri particulare. Dacă matricea de încărcare cu trafic, reprezentând
fluxurile între fiecare pereche sursă - destinaţie, este cunoscută şi nu variază în timp,
atunci tabelele de dirijare fixă pe calea cea mai scurtă pot fi modificate pentru a utiliza
surplusul de capacitate din anumite părţi ale reţelei (tabelele de dirijare pe calea cea mai
scurtă pot duce la concentraţii nedorite de trafic, lucru care poate fi înlăturat prin
modificarea tabelelor). În figura 3.7 s-a presupus că traficul de la toate nodurile la nodul
D este acelaşi. Se observă că prin dirijarea pe calea cea mai scurtă se încarcă foarte
mult nodul A şi linia dintre nodurile A şi D.

A D

Figura 3.7: Arborele de dirijare către nodul D

Prin modificarea ilustrată în figura 3.8 situaţia este îmbunătăţită, deşi în mod
evident alte elemente ale reţelei vor suporta o încărcare mai mare.

A D

Figura 3.8: Modificarea dirijării pentru distribuirea încărcării cu trafic

O variantă care încearcă să distribuie traficul cât mai uniform în reţea este aceea
a luării deciziei de dirijare spre o destinaţie în funcţie de sursa de la care vine pachetul,
prevăzând o intrare separată în tabelul de dirijare în care este precizată sursa. Această

6
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
variantă poate fi văzută în figura 3.9 în care se observă cum fluxul de date este despicat
pe mai multe căi în funcţie de sursa pachetelor individuale.

Figura 3.9: Dirijare cu bifurcare în funcţie de sursa pachetelor

3.1. Tehnici simple de rutare

Tehnicile simple de dirijare nu necesită tabele de dirijare, nu necesită nici un fel

de cunoştinţă privind topologia reţelei. Ele sunt recomandate pentru reţele slab
încărcate cu trafic şi la care se cere să aibă capacitatea de a continua să funcţioneze în
cazul defectării unor componente ale reţelei şi în condiţii dificile, cum ar fi un atac
militar.

3.1.1. Rutarea aleatoare.

Nodul funcţionând pe acest principiu, după ce a stabilit că un pachet trebuie

transmis (adică nu este adresat unui utilizator local conectat la acel nod), alege printr-un
proces aleator linia de ieşire pe care să transmită pachetul. În general, este logic ca
pachetul să nu fie transmis pe linia pe care a venit, aşa că această linie este exclusă din
procesul de selecţie. Există două variante de a alege linia pe care va fi transmis
pachetul:
a. se utilizează un generator de numere aleatoare care să desemnează numărul
liniei pe care se va ieşi;
b. se utilizează liniile de ieşire prin rotaţie, schimbând linia la fiecare pachet
care iese din nod, punându-se restricţia ca nici un pachet să nu se transmită pe linia pe
care a venit. Această a doua variantă are avantajul că nu ocupă nici timpul de lucru al
procesorului din nod, nici spaţiul de memorie cu programe de prelucrare.
Pachetele transportate în acest mod prin reţea circulă pe căi aleatoare şi nu
avansează în mod sistematic spre destinaţia cerută. Pentru o reţea dată, trebuie să fie
posibil să se calculeze distribuţia de probabilitate a lungimii căilor posibile (în funcţie
de numărul de linii traversate) necesare pentru a ajunge la destinaţie. Ca urmare se va

7
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
ataşa fiecărui pachet un contor de linii traversate, urmând ca pachetele al căror contor
de linii traversate depăşeşte un număr prestabilit să fie eliminate. Prevederea unui
număr maxim pentru contorul de linii traversate este un mod eficient de a evita căile
infinite care pot apare atunci când nu se poate ajunge la destinaţie din diferite motive
(unul ar fi cazul în care reţeaua este divizată în două părţi deconectate din cauza
defectării unui număr de linii).
Această metodă are dezavantajul că nu este garantată livrarea pachetului la
destinaţie.
Avantajul metodei îl constituie simplitatea şi completa independenţă de
topologia reţelei.

3.1.2. Rutarea prin inundare

Nici acest proces simplu de dirijare nu necesită cunoştinţe despre topologia

reţelei. Nodul care trebuie să expedieze un pachet (cu aceeaşi restricţie de a verifica
dacă pachetul nu este destinat unui utilizator local) face atâtea copii câte linii de ieşire
există, mai puţin cu unu. Câte o copie este transmisă pe toate liniile cu excepţia liniei pe
care a sosit. Numărul de linii traversate este din nou folosit pentru a limita numărul de
expedieri succesive. Limita contorului de linii traversate trebuie stabilită astfel încât să
depăşească cu unu distanţa pe cea mai scurtă cale între cea mai îndepărtată pereche
sursă - destinaţie. Când contorul de linii traversate al unui pachet a atins această limită
(în cazul în care se face incrementare la fiecare pas, respectiv a ajuns la zero în cazul
decrementării), pachetul nu mai este expediat, iar copia lui este distrusă.
Pentru eliminarea pachetelor multiplicate în mod excesiv în reţea se pot adopta
mai multe variante de acţiune:
Varianta 1: se introduce în pachet un câmp ce reprezintă numărul de salturi (de noduri
traversate) efectuate în reţea. Acest contor este decrementat la fiecare salt. Când
conţinutul său devine nul, pachetul corespunzător este distrus. Valoarea iniţială cu care
este încărcat contorul se determină pe baza numărului de salturi de la sursă la destinaţie
(sau al numărului maxim de salturi între oricare două puncte ale reţelei) care este
majorat pentru a preîntâmpina situaţiile critice (o parte a reţelei scoasă din funcţiune).
La destinaţie este necesară ţinerea unei evidenţe a pachetelor recepţionate pentru a
putea elimina copiile.
Varianta 2: fiecare sursă numerotează secvenţial pachetele pe care le introduce în reţea.
Fiecare nod deţine un set de liste, câte o listă pentru fiecare sursă, în care sunt înscrişi
identificatorii pachetelor care au fost deja recepţionate. Pentru a limita creşterea acestei
liste se ataşează un contor a cărui valoare k indică faptul că toate pachetele având

8
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
indicativ mai mic decât k au fost recepţionate. Pachetele copii sunt detectate
comparându-le identitatea cu conţinutul contorului sau cu lista corespunzătoare.
Varianta 3 (inundare selectivă): nodul de tranzit multiplică pachetele doar în direcţia
aproximativ bună (utilă doar în cazul reţelelor cu structura regulată).
Meritul acestui tip de rutare este că cel puţin o copie a pachetului va ajunge la
destinaţie pe calea cea mai scurtă şi prin urmare în timpul cel mai scurt.
Apare însă o încărcare considerabilă a reţelei: un număr mare de pachete
duplicate şi de tranzacţii de anulare a unor pachete; nodurile destinatare trebuie să
verifice sosirea pachetelor duplicate şi să le distrugă.
Spre deosebire de rutarea aleatoare, rutarea prin inundare garantează livrarea
fiecărui pachet cu condiţia să se poată ajunge la destinaţie.

3.2. Rutarea fixă

Este cea mai simplă şi cea mai evidentă metodă de dirijare. Sunt folosite tabele
de dirijare în fiecare nod al reţelei. În forma lor cea mai simplă, tabelele de dirijare fixă
specifică o anumită linie din fiecare nod pentru a fi folosită în drumul către fiecare
destinaţie. Se observă că nu există nici un mecanism de alegere implicat în luarea
deciziilor de dirijare.

3.2.1. Rutarea pe calea cea mai scurtă

Tabelele de dirijare specifică în acest caz cele mai scurte căi pentru fiecare
pereche sursă - destinaţie. Criteriul după care se alege calea cea mai scurtă poate lua în
considerare mai multe caracteristici ale reţelei, fie ţinând seama de topologia ei, fie de
comportarea în timp a traficului. Se poate alege astfel calea cea mai scurtă din punct de
vedere al distanţei geografice, al numărului de salturi necesar pentru a atinge o anumită
destinaţie, capacitatea de transport a liniilor, traficul mediu pe linii, lungimea cozilor de
aşteptare, întârzierea medie.
Pentru o reţea slab încărcată acest mod de rutare realizează performanţe
satisfăcătoare, cu timpi de tranzit minimi. În cazul în care traficul creşte, performanţele
scad rapid. Aceasta se datorează faptului că setul de tabele de dirijare pe calea cea mai
scurtă nu distribuie în mod necesar traficul în mod egal în toată reţeaua, rezultând unele
linii supraîncărcate în timp ce altele sunt libere. Dacă traficul nu suportă schimbări
majore, atunci este posibil să se calculeze tabele de dirijare care să echilibreze reţeaua.
Un fapt care ar duce la imposibilitatea utilizării acestei metode de rutare este
căderea unei linii de legătură între două noduri. Există şi în acest caz mai multe variante
de înlăturare a acestui neajuns.

9
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
O modalitate ar fi aceea de a memora în fiecare nod un set complet de tabele de
dirijare de substituţie, un tabel pentru fiecare cădere posibilă din reţea. Dacă este posibil
se pot face tabele care să ţină seama de mai multe căderi din reţea. În momentul în care
se întrerupe o linie, nodurile de la capetele liniei defecte transmit pachete de control la
toate nodurile din reţea, înştiinţându-le despre identitatea liniei întrerupte. În urma
recepţionării pachetelor de control, nodurile îşi vor actualiza tabelele de dirijare în mod
corespunzător. Pentru a realiza un transfer rapid de informaţii, aceste pachete de control
au prioritate ridicată faţă de celelalte categorii de trafic.
O altă variantă este aceea în care un centru de control al reţelei primeşte
rapoartele de la noduri, descoperă întreruperea unor linii şi emite comenzi către noduri
să-şi modifice tabelele de dirijare pentru a ţine seama de aceste întreruperi. Când s-a
reparat o componentă a reţelei, centrul de control va emite comenzi pentru restaurarea
rutelor utilizate anterior.

3.2.2. Rutarea multiplă (multicale)

În cazul în care între două noduri există mai multe căi de valori aproximativ
egale, traficul între aceste două noduri poate fi partajat pe aceste rute .
Rutarea multicale este posibilă atât pentru reţelele utilizând datagrame cât şi
pentru cele de tip circuit virtual. În cazul datagramelor când un pachet soseşte pentru a
fi retransmis, se va face a alegere între diferitele căi posibile pentru acel pachet, alegere
independentă de alegerile anterioare pentru pachetele având aceeaşi destinaţie. În cazul
circuitelor virtuale, dacă un circuit este în curs de stabilire, se va alege o rută, urmând
ca pachetele având aceeaşi destinaţie să urmeze toate această rută. Circuitele virtuale
diferite vor fi dirijate independent unul de celălalt.
Fiecare nod ţine la zi un tabel cu toate destinaţiile posibil de atins. Pentru
fiecare destinaţie sunt înscrise diferite linii de ieşire, în ordine descrescătoare (de la cel
mai favorabil traseu până la cel mai puţin favorabil). Înainte de a expedia un pachet,
nodul generează un număr aleator şi alege cu ajutorul lui între diferitele posibilităţi,
utilizând ponderile asociate fiecărei variante de ieşire ca fiind probabilităţi. Tabelele
sunt create manual de către administratorul reţelei, sunt încărcate în fiecare nod înainte
de pornirea reţelei şi apoi nu mai sunt modificate.
În cadrul fiecărei interfeţe există un tabel cu diferitele linii posibile de ieşire
pentru fiecare destinaţie în parte. Identităţile ieşirilor sunt scrise în ordinea crescătoare a
valorilor asociate traseelor corespunzătoare. Alături de ele se scriu ponderile relative.
Exemplu: Fie patru ieşiri având ponderile p1, p2, p3 şi p4, cu p1 + p2 + p3 + p4 = 1.
Se generează un număr aleator în intervalul (0,1) şi se alege ieşirea având ponderea cea
mai apropiată de numărul generat.

10
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
Rutarea multicale prezintă ca avantaje:
• creşterea fiabilităţii reţelei (în caz de defectare a unui link, el poate fi "ocolit" pe
una din rutele echivalente),
• alegerea în funcţie de debitul informaţiei a unei rutări optime ca viteză de
transmisie.
Ca exemplu, fie reţeaua din figura 3.10, discuţia făcându-se pentru nodul J.

nodul A nodul B nodul C nodul D

nodul E nodul H
nodul F nodul G

nodul I nodul J nodul K nodul L

Figura 3.10. Reţea în care se exemplifică rutarea multicale

Tabela de rutare pentru nodul J se prezintă astfel:

Destinaţia Prima alegere A doua alegere A treia alegere

A A - 0.63 I - 0.21 H - 0.16
B A - 0.46 H - 0.31 I - 0.23
C A - 0.34 I - 0.33 H - 0.33
D H - 0.50 A - 0.25 I - 0.25
E A - 0.40 I - 0.40 H - 0.20
F A - 0.34 H - 0.33 I - 0.33
G H - 0.46 A - 0.31 K - 0.23
H H - 0.63 K - 0.21 A - 0.16
I I - 0.65 A - 0.22 H - 0.13
J -- -- -- -- -- --
K K - 0,67 H - 0.22 A - 0.11
L L - 0.42 H - 0.42 A - 0.16

Dacă J primeşte un pachet destinat nodului A, el va accesa tabelul de rutare

citind informaţiile de la adresa A. Va găsi trei variante. Linia directă către nodul A este
cea de primă alegere, urmată de liniile de ieşire înspre nodurile I şi H. Pentru a se
decide, J generează un număr aleator cuprins între 0,00 şi 0,99. Dacă numărul este

11
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
inferior lui 0,63 atunci este aleasă linia A. Dacă numărul este cuprins între 0,63 şi 0,83,
atunci este utilizată linia I; altfel, se va alege linia H.

3.3. Rutarea adaptivă

Acest mod de dirijare a apărut în momentul în care s-a realizat cât de mari sunt
avantajele pe care le aduce un sistem capabil să se adapteze rapid la condiţiile curente,
permiţând utilizarea unor rute multiple, luând în considerare întreruperile şi restabilirile
liniilor şi nodurilor reţelei, acceptând cu uşurinţă adăugarea de noi noduri sau
înlăturarea celor existente.
Apare din acest punct de vedere foarte tentantă ideea disponibilităţii instantanee
a informaţiilor de dirijare în toată reţeaua. De la această idee s-a plecat atunci când a
fost simulată o tehnică de dirijare numită:
Tehnica magică ( observator ideal)
În această tehnică fiecare nod din reţea care ia o decizie de rutare are o privire
instantanee completă asupra restului reţelei. Algoritmul de rutare, cunoscând lungimea
firelor de aşteptare în toate celelalte noduri şi numărul de pachete în tranzit pe fiecare
linie, calculează optimul pentru următoarea linie pe care să transmită pachetul pentru a
ajunge la destinaţie cu timp minim de întârziere. Rezultatul neaşteptat al
experimentului de simulare a arătat că timpii medii de întârziere obţinuţi nu erau
semnificativ mai mici decât cei observaţi în cazul folosirii în aceeaşi reţea a unei tehnici
de dirijare fixă indicând calea cea mai scurtă pentru tot traficul. S-a ajuns la concluzia
că deşi dirijarea magică s-a făcut pe baza celor mai bune informaţii disponibile,
variaţiile de trafic au făcut ca rutele, care erau optime în momentul luării deciziei, să
devină suboptime înainte ca pachetele în cauză să ajungă la destinaţie. Este posibil ca în
această metodă mai multe noduri să observe o secţiune de reţea slab încărcată şi toate să
încerce să transmită trafic în această secţiune, rezultând congestionarea zonei.
Tehnicile de dirijare adaptivă trebuie să utilizeze cât mai mult din informaţiile
pe care le obţin fie pe plan local, fie ca urmare a unor mesaje care circulă prin reţea.
Dacă nodurile sunt capabile să creeze ele însele informaţii de rutare pe care apoi le
utilizează împreună cu nodurile vecine, atunci se poate vorbi de o rutare adaptivă
distribuită. Mai există o formă de rutare, cunoscută ca fiind rutarea centralizată, în care
nodurile transmit rapoarte de stare la un centru de dirijare care, la rândul său, emite
instrucţiuni de dirijare către nodurile din reţea.
Apar câteva probleme specifice rutării adaptive.
Una ţine de secvenţialitatea pachetelor. Dacă livrarea pachetelor în secvenţa în
care au intrat în reţea este importantă pentru utilizatori, atunci o rutare fixă îmbinată cu

12
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
un control de flux pot garanta faptul că pachetele nu se vor depăşi unele pe altele şi se
va face livrarea în ordinea dorită. Dacă, în schimb, metoda de rutare conţine şi elemente
de adaptare la condiţiile mereu în schimbare în care funcţionează reţeaua, atunci
pachetele între aceeaşi pereche sursă - destinaţie pot urma rute diferite şi pot avea
nevoie de timpi diferiţi pentru a ajunge la nodul destinatar. Rezultatul este acela că nu
mai este garantată livrarea în ordinea în care au fost acceptate de la sursă. În unele
cazuri, ordinea de livrare a pachetelor de către reţea nu este vitală, reordonarea
făcându-se pe calculatorul gazdă. Protocoalele pentru reţelele datagram nu cer o
succesiune absolută a pachetelor livrate, dirijarea adaptivă putând fi folosită cu avantaje
depline. În schimb, protocoalele de circuit virtual cer în primul rând o secvenţă corectă
a pachetelor, în acest caz dirijarea adaptivă fiind mai puţin interesantă (excepţie o
constituie cazul în care pachetele sunt reordonate de nodul destinatar înainte de livrare).
Se poate totuşi utiliza o metodă de dirijare adaptivă şi în cazul circuitelor
virtuale, în momentul stabilirii rutei, când s-a cerut realizarea unei conexiuni. Se poate
încerca optimizarea traficului prin alegerea celei mai bune rute pentru fiecare apel.
O altă variantă este aceea în care reţeaua asigură o interfaţă de circuit virtual
numai la nivelul nodurilor sursă şi destinaţie, reţeaua în sine funcţionând pe principiul
datagram.
Algoritmii de dirijare adaptivă pot fi complicaţi, astfel încât tipuri diferite de
pachete să folosească tipuri diferite de rute. În cazul unei reţele hibride, în care există
mijloace de transmisie atât terestre cât şi prin sateliţi, canalele prin sateliţi oferă bandă
largă, dar cu timpi de propagare ridicaţi, iar canalele terestre oferă bandă îngustă, dar
timpi de propagare scăzuţi. Primul tip de canale este ideal pentru transfer de fişiere
mari, al doilea pentru fişiere de dimensiuni scăzute şi pentru un mod de lucru interactiv
care necesită un timp de răspuns rapid.

3.3.1. Rutarea adaptivă izolată

Este cea mai simplă dintre metodele de dirijare adaptive, deciziile de dirijare
luându-se numai pe baza informaţiilor disponibile la nivel local în fiecare nod.
În cazul acestui tip de algoritmi, deciziile se iau de către fiecare nod în parte pe
baza informaţiilor culese local. Nu există un arbitru care să supravegheze activitatea
nodurilor pentru a asigura luarea unor decizii de rutare optime pentru întreaga reţea.
Datorită acestui fapt, e posibil ca deciziile nodurilor să ducă la situaţii în care varianta
care este aleasă ca cea mai bună pentru un nod să fie dezavantajoasă pentru un altul.
Varianta cea mai simplă de rutare locală este situaţia în care fiecare nod ia deciziile
referitoare la tabele sale de rutare numai pe baza datelor proprii, fără să cunoască ceva

13
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
despre situaţia restului reţelei. Acest gen de algoritmi se numesc "algoritmi de rutare
adaptivă locală". Exemple de astfel de algoritmi sunt cei care urmează.

3.3.1.1. Învăţare prin observare anterioară

Este o tehnică care iniţial ignoră topologia reţelei, obţinând cunoştinţe despre
aceasta pe parcurs, prin prelucrarea pachetelor succesive. Pentru aceasta, pachetele
trebuie să transporte, pe lângă adresa de destinaţie şi adresa sursei de unde vin şi un
contor de linii traversate. Într-o primă fază dirijarea se face aleatoriu, dar nodurile sunt
programate să ţină seama de contorul de linii traversate şi de adresa sursă a fiecărui
pachet prelucrat. Un pachet cu un contor de linii traversate egal cu unu vine în mod
evident de la un nod vecin conectat direct. În acest fel se identifică imediat nodurile
vecine şi liniile prin care sunt conectate, ceea ce reprezintă primele intrări într-o tabelă
de dirijare rudimentară. Un pachet cu un contor de linii traversate egal cu doi a venit de
la o sursă aflată la o depărtare de două linii intermediare, măsurată pe linia pe care a
sosit. Procesul continuă cu compararea contorului de linii traversate, pentru o anumită
adresă sursă, cu cel mai mic contor înregistrat deja; dacă cel nou este mai mic, atunci
este substituit în locul celui vechi şi linia corespunzătoare este marcată ca fiind linia de
pe cea mai scurtă cale cunoscută către un anumit nod din reţea.
Astfel, dacă un nod primeşte pe linia k un pachet provenind de la H, pachet
având contorul de salturi cu valoarea q, înseamnă că nodul H se află la cel mult q salturi
pe linia k. Dacă ruta anterioară optimă până la nodul H avea mai mult de q salturi,
tabele de rutare se modifică astfel încât toate pachetele cu destinaţia H vor fi rutate pe
linia k. După un anumit timp, toate nodurile reuşesc să descopere rutele optime către
celelalte noduri ale reţelei. Apar probleme dacă se defectează un nod sau o linie.
Deoarece nu sunt luate în calcul, la modificările tabelelor de rutare, decât variantele
cele mai bune, nu se poate sesiza o astfel de defecţiune (dacă am presupune că un
pachet a ajuns pe o rută ocolitoare, evitând nodul defect, el va conţine un contor de
linii traversate mai mare decât optimul înscris în tabela de rutare). Pentru aceasta,
periodic, toate nodurile trebuie să reînceapă activitatea de căutare a rutelor optime ca la
iniţializarea reţelei. În timpul acestor căutări, rutarea este suboptimală. Dacă perioada
este prea mare, reţeaua nu se poate adapta rapid modificărilor apărute. Dacă reluările
sunt prea dese, timpul de convergenţă al algoritmului riscă să nu mai fie atins, rutarea
fiind continuu suboptimală.

14
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
3.3.1.2. Tehnica "cartofului fierbinte"

Atunci când un pachet intră în nod, algoritmul asigură scoaterea pachetului cât
mai repede spre ieşire. Nodul consideră liniile sale de ieşire în ordinea descrescătoare a
disponibilităţii de a se ajunge la fiecare destinaţie din reţea. Pentru a se asigura acest
deziderat, se utilizează învăţarea din observare anterioară, care asigură tabelele de
dirijare pentru această metodă. Aceste tabele conţin liniile de ieşire din nod, ordonate,
pentru fiecare destinaţie.
Există câteva variante de realizare a acestei metode.
O primă variantă presupune ca procesul de expediere din nod să transmită un
pachet pe linia liberă pentru transmitere, în momentul luării deciziei de dirijare, cu cel
mai mare grad de disponibilitate. Dacă nu este liberă nici o linie corespunzătoare,
atunci pachetul trebuie să aştepte şi va părăsi nodul pe prima dintre aceste linii care va
deveni liberă.
O a doua variantă a cartofului fierbinte presupune că se acceptă fire scurte de
aşteptare pentru fiecare linie de ieşire, stabilind o limită a numărului de pachete care pot
fi în aşteptare pentru fiecare linie de ieşire. În acest caz procesul de dirijare va selecta
firul de aşteptare cu cel mai mare grad de disponibilitate care are spaţiu disponibil.
Mai există şi o variantă care nu ţine seama de preferinţa unei linii spre o
anumită destinaţie şi care trimite pachetul pe prima linie liberă găsită. Această din urmă
variantă este însă cea mai dezavantajoasă, ea neducând la o înaintare sistematică a
pachetelor.
De altfel toate metodele pot conduce la situaţii în care se aleg linii
necorespunzătoare pentru trafic, cu rute lungi şi întortocheate şi asta numai din cauză că
ruta cea mai bună poate fi momentan ocupată în întregime în momentul luării deciziei.
Graba foarte mare a procesului de dirijare după metoda cartofului fierbinte este o
caracteristică negativă a acestei metode.
Metoda cartofului fierbinte poate fi privită însă şi dintr-un punct de vedere care
să scoată în evidenţă un avantaj care poate fi luat în calcul când se face aprecierea
eficienţei: poate face faţă cu succes unei supraîncărcări de trafic în reţea prin plasarea
unui pachet sosit în oricare fir de aşteptare, oricât de necorespunzătoare ar fi ruta aleasă.
O încărcare excesivă duce însă la blocarea reţelei.
Au rezultat două îmbunătăţiri ale metodei :
a). Pentru a evita acceptarea unui număr excesiv de pachete şi deci
congestionarea reţelei, folosirea cartofului fierbinte se face împreună cu un control
simplu al fluxului care presupune refuzul de a accepta noi pachete de la utilizatorii
sursă dacă lungimea unui fir de aşteptare (oricare) din nod a atins o anumită valoare.

15
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
Când lungimea firului de aşteptare scade sub aceasta valoare, se reia acceptarea
traficului de la utilizatori.
b). Se interzice dirijarea după metoda cartofului fierbinte a pachetelor care au
ajuns în penultimul nod al drumului lor către destinaţie. Traficul ajuns în penultimul
nod nu trebuie dirijat decât pe linia către nodul destinatar. Dacă ultima linie este
congestionată, traficul este pus în aşteptare până când aceasta devine disponibilă.

3.3.1.3. Cel mai scurt şir de aşteptare plus preferinţă

Există trei tipuri de informaţii locale necesare pentru o bună dirijare a

pachetelor prin reţea: o tabelă de dirijare prestabilită, starea curentă a liniilor de ieşire
(funcţională sau nu) şi lungimea şirurilor de aşteptare pentru fiecare linie de ieşire. În
această metodă de rutare nodul nu are nevoie de informaţii despre starea celorlalte
componente ale reţelei. Algoritmul de dirijare este programat să facă o selecţie între
rutele alternative indicate în tabela de rutare, prin calcule bazate pe lungimea şirurilor
de aşteptare şi cunoştinţe despre topologia reţelei, exprimate ca o preferinţă pentru ca
cele mai bune linii să fie utilizate pentru a ajunge la fiecare destinaţie. Acest proces
poartă numele de "cel mai scurt şir de aşteptare plus preferinţă".
Alegerea unei valori corecte pentru preferinţă este critică pentru succesul
algoritmului.
Dacă preferinţa este zero, atunci modul în care se ia decizia este similar cu
metoda cartofului fierbinte (decizia de dirijare se ia după cel mai scurt fir de aşteptare).
Dacă preferinţa este de valoare mică, există tendinţa de a se folosi linia cu cel
mai scăzut şir de aşteptare, ceea ce poate face ca acea rută să nu fie cea mai adecvată
pentru destinaţia dorită.
Dacă preferinţa este foarte mare, ea va domina procesul de selecţie a rutei şi, ca
urmare, ruta către fiecare destinaţie va fi fixă, luând foarte puţin în consideraţie
condiţiile de trafic curent.
Din aceste considerente rezultă că este de dorit alegerea unei valori intermediare
pentru preferinţă pentru ca algoritmul să dirijeze traficul în mod eficient şi să se
adapteze la schimbările fluxului de date.
O altă metodă de dirijare adaptivă locală presupune existenţa unor tabele de
dirijare preîncărcate în fiecare nod în care este indicată calea cea mai scurtă către
fiecare destinaţie. Aceste rute au fost desemnate ca fiind rute primare. Dacă există o a
doua rută (care părăseşte nodul pe o altă linie, dar nu neapărat disjunctă de prima), ce
are aceeaşi lungime cu ruta primară în ceea ce priveşte numărul de linii tranzitate, dar
mai lungă ca distanţă, această rută este desemnată ca fiind rută secundară de tip A. Dacă
nu există nici o rută secundară de tip A, atunci se va căuta o rută care are o linie în plus

16
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
şi care va fi desemnată ca rută secundară de tip B. Dacă nu există nici o rută secundară
de tip B, atunci nu se va desemna nici o rută secundară. Ponderile numerice sunt alocate
fiecărui tip de rută, 3 pentru rutele primare, 2 pentru rutele secundare de tip A şi 1
pentru rutele secundare de tip B. Făcând un calcul simplu de acest fel se observă o
distribuire a traficului ca în figura 3.11.
60%
A B

40%

Figura 3.11: Distribuirea traficului între o rută primară şi una secundară

În momentul în care se ţine seama de ponderile numerice, dar şi de lungimea

firelor de aşteptare ale pachetelor pentru transmisie pe fiecare linie, apare o etapă
suplimentară în care se face combinarea acestora două. În procesul de selecţie numărul
de locuri libere din şirul de aşteptare este adunat la ponderea rutei .
Se consideră un exemplu în care şirul de aşteptare este limitat la un număr de
cinci pachete, ilustrat în figura 3.12.

Ruta primara
ponderea 3

Zone tampon Proces de Zone tampon

de intrare Siruri de asteptare de iesire
dirijare
Ruta secundara
ponderea 1

Figura 3.12: Distribuirea traficului luând în calcul preferinţele şi lungimile şirurilor de

aşteptare
Se consideră un nod în care un pachet este dirijat spre destinaţie. Sunt
disponibile o rută primară şi una secundară de tip B. Numărul de locuri libere în şirurile
de aşteptare la momentul exemplificat este doi pentru ruta primară şi patru pentru ruta
secundară. În aceste condiţii, procesul de dirijare va face o selecţie între ruta primară şi
cea secundară folosind un generator de numere aleatoare. Raportul de probabilităţi

17
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
pentru cele două rute este 3+2, respectiv 1+4, adică 5:5. Datorită acestui rezultat avem
o probabilitate egală de utilizare a fiecărei rute.
Luând în discuţie varianta în care numărul de locuri libere este 4 şi respectiv 1,
atunci raportul de probabilităţi este 3+4 la 1+1, adică 7 la 2 rezultând o preferinţă către
ruta primară.
Dacă unul din şirurile de aşteptare este plin, atunci pachetul este pus în celălalt
şir, indiferent de numărul de locuri libere. Dacă ambele şiruri de aşteptare sunt pline,
atunci pachetul este neglijat şi va fi recepţionat mai târziu prin retransmitere de la nodul
precedent.

3.3.1.4. Rutare prin încărcare la maximum.

Mai există o modalitate de a face dirijarea utilizând informaţiile locale, numită

dirijare prin încărcare la maximum. În acest caz ruta primară este folosită întotdeauna,
excepţie făcând cazul în care şirul de aşteptare este plin. În această situaţie se caută
spaţiu în şirul de aşteptare pe ruta secundară (dacă există).
Metodele de dirijare adaptivă izolată prezintă unele neajunsuri, printre care
acela că se adaptează încet la evenimente îndepărtate (întreruperi de linii sau acumulări
de trafic). În aceste situaţii se formează un lanţ de şiruri de aşteptare pline din punctul
de congestie până la un nod în care are loc o dirijare utilă sau până înapoi la sursă. Abia
la completarea lanţului se va opri fluxul de date. Procesul reprezintă un mijloc încet şi
incomod de control de flux şi de dirijare a traficului pe rute alternative.

3.3.2. Rutarea adaptivă distribuită

Este cea mai populară tehnică implementată până acum în reţelele existente.
Scopul algoritmului este de a găsi căi cu cel mai mic timp de întârziere. Pentru aceasta,
fiecare nod menţine un tabel cu rutele optime pentru fiecare destinaţie, indicând pentru
fiecare destinaţie cea mai bună estimare curentă a timpului necesar pentru transport. În
momentul punerii în funcţiune a reţelei, timpii sunt estimaţi având la bază topologia
reţelei. Odată cu livrarea traficului, estimarea timpilor are la bază măsurători efectuate
asupra timpului real de tranzit în reţea.

3.3.2.1. Rutarea în reţeaua ARPANET

O primă formă a algoritmului prevede transmiterea cu regularitate a tabelelor cu

timpii de întârziere între nodurile vecine. După recepţia tabelelor cu timpii de
întârziere, fiecare nod intră într-o fază de recalculare a timpilor de întârziere, pe baza

18
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
lungimii şirului de aşteptare pentru linia de ieşire din acel nod şi a timpilor de întârziere
recepţionaţi de la nodurile vecine.
Figura 3.13 ilustrează recepţia tabelelor cu timpii minimi de întârziere la un nod
şi recalcularea timpilor de întârziere locali şi a tabelelor de dirijare. Figura, pentru
simplificare, nu prezintă decât o zonă din reţea care se presupune că mai cuprinde şi
alte noduri.
Schimbul reciproc de tabele cu timpi de întârziere între nodurile vecine necesită
un volum considerabil de trafic de pachete de control, rezultând o încărcare substanţială
a reţelei. S-a constatat că pentru o actualizare la 2/3 secunde traficul de pachete de
control reprezintă aproximativ 50% din trafic. Examinând conţinutul pachetelor se
constată că foarte des tabela de timpi de întârziere conţine aceleaşi informaţii ca şi
tabela precedentă. De aceea, o modalitate mai economică o constituie schimbul
neperiodic de informaţii. Tabelele de timp se transmit numai de către nodurile care au
detectat o schimbare semnificativă fie în intensitatea traficului, fie în funcţionarea
componentelor.

Tabele cu timpii minimi Timpii de intirziere

de intarziere ce sosesc estimati la nodul 3
la nodul 3
1 2 De la nodul
1 2 4
1 2
1 0 9 7
2 3
3 2 7 0 8 Catre
Destinatie nodul 3 -
3 4 3 5
4 6
4 2 6 0

4 Tabele noi cu timpii minimi

Tabele cu timpii de
de intarziere din nodul 3
intarziere modificati
Timpul de intarziere Ruta via nodul
estimati in nodul3
Via nodul
1 2 1
1 2 12 13
Catre Catre 2 3 2
2 9 3 14
nodul nodul 3 0 -
3 0 0 0
4 4 1
4 4 9 6

Figura 3.13: Recalcularea tabelelor de întârziere şi a tabelelor de dirijare

Revizuirea tabelelor se face numai în cazul sesizării unei modificări

semnificative locale sau în urma recepţionării unei tabele cu timpii de întârziere
revizuită de un nod vecin. În acest din urmă caz este posibil ca noile informaţii să nu

19
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
producă schimbări în timpul minim de întârziere calculat anterior şi deci să nu fie
necesară transmiterea noilor tabele cu timpii de întârziere.
În cazul actualizării sincrone, viteza de adaptare la evenimente îndepărtate este
mică. Informaţiile de dirijare circulă de-a lungul unui lanţ de noduri, rezultând timpi de
propagare mari în cazul unei reţele întinse. Înştiinţarea despre defectarea unei
componente a reţelei în scopul redirijării traficului soseşte cu întârziere. În acest
interval traficul continuă să circule pe rutele existente ducând la congestionarea rutelor
din apropierea defectului. Acesta ar fi un argument în plus pentru actualizarea
asincronă.
Controlul dirijării prin transmiterea tabelelor cu timpi minimi de întârziere între
noduri are capacitatea de a se adapta rapid la reducerea timpilor de întârziere şi lent la
creşterea acestora. Cu alte cuvinte, se adaptează rapid la veştile bune şi lent la veştile
rele. Această proprietate a algoritmului este ilustrată în exemplul următor (figura 3.14).
Fie un lanţ de patru noduri. Se presupune că timpul necesar pentru transferul
unui pachet de la un nod la următorul nod este egal cu o unitate de timp. Astfel,
transferul de la nodul 4 la nodul 1 durează trei unităţi de timp. Timpul este introdus în
tabela cu timpi minimi de întârziere pentru fiecare nod în parte. Setul complet al
tabelelor pentru cele patru noduri este prezentat în figură.

1 2 3 4

Nodul Cel mai mic timp de
Întârziere către nodul 1
2 1 (direct)
3 2 ( via nodul 2)
4 3 ( via nodul 3 )
Nodul Cel mai mic timp de
Întârziere către nodul 1
2 3 (via nodul 3)
3 4 ( via nodul 4 )
4 3 ( via nodul 3 )

Prima stare A doua stare

Figura 3.14: Actualizarea tabelelor de dirijare

Presupunem că are loc o perturbare a traficului având ca rezultat un trafic

suplimentar de la nodul 1 la nodul 2. Ca urmare a acestei creşteri, putem considera că
timpul de transfer al pachetelor creşte de la o unitate la cinci unităţi. Soseşte momentul
de transmitere a tabelelor cu timpii minimi de întârziere: nodul 2 înştiinţează nodul 3 că
timpul său minim către nodul 1 este acum de 5 unităţi; nodul 3 înştiinţează nodul 2 că

20
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
timpul său minim către nodul 1 este de 2 unităţi. Aceasta are loc deoarece nodul 3 nu a
luat încă cunoştinţă de informaţiile date de nodul 2 şi nu a făcut modificările necesare.
Rezultatul acestei transmisii este unul care generează pentru un timp haos. Nodul 2
calculează că ruta cu timp minim de întârziere către nodul 1 este cea care trece prin
nodul 3, durând numai 3 unităţi de timp pentru tranzit. Nodul 3, primind timpul de
întârziere de 5 unităţi până la nodul 1 şi numai 3 unităţi către nodul 1 prin nodul 4,
calculează că ruta cu cel mai mic timp de întârziere către nodul 1 trece prin nodul 4,
durând numai 4 unităţi de timp. În acest fel traficul este direcţionat greşit prin nodurile
3 şi 4 şi, eventual, trebuie să se întoarcă înapoi pe lanţ, dacă nu cumva lanţul face parte
dintr-o reţea mai mare şi atunci traficul pentru nodul 1 poate ajunge la destinaţie
urmând o rută foarte ocolitoare.
Pentru a se elimina această situaţie neplăcută se aplică o tehnică numită de
încetinire, în care un nod, care a detectat o creştere a timpului de întârziere pe ruta care
anterior era ruta cu timp de întârziere minim către o destinaţie, continuă să folosească
calea existentă un interval de timp până când vecinii au fost informaţi despre această
creştere şi au avut posibilitatea să-şi recalculeze tabelele cu timpii de întârziere. Efectul
acestei modificări este distribuirea deciziei de dirijare între un grup de noduri vecine.
Se evită astfel dirijarea greşită prin acceptarea ca nodurile în cauză să se adapteze în
mod colectiv înainte ca înştiinţarea despre creşterea timpului de întârziere să afecteze
dirijarea.
Această metodă de rutare nu duce la ceea ce s-ar aştepta de la o dirijare
adaptivă, şi anume distribuirea traficului care circulă între perechi anumite sursă -
destinaţie pe mai multe rute. Între momentele de actualizare a tabelelor cu timpi de
întârziere rutarea este fixă. În momentul actualizării ruta se poate schimba, fluxul de
date este deviat, dar nu are loc o folosire simultană a mai multor rute pentru un flux
anumit de date.

3.3.2.2. Cel mai scurt şir de aşteptare + preferinţă + actualizare periodică

O altă modalitate de realizare a unei rutări adaptive distribuite ar fi tehnica

numită "cel mai scurt şir de aşteptare + preferinţă + actualizare periodică ". În această
tehnică tabelele cu timpii de întârziere sunt schimbate periodic între nodurile vecine,
dar fiecare nod are libertatea de a utiliza o combinaţie a lungimii şirurilor de aşteptare,
a unei valori de preferinţă şi a informaţiilor de actualizare periodică a tabelelor cu
timpii de întârziere, pentru a calcula cea mai bună rută către destinaţie în momentul în
care se ia decizia. Această metodă are capacitatea potenţială de a distribui traficul pe
mai multe rute, dar are dezavantajul de a încărca sistemul de calcul din nod cu un
volum mare de calcule.

21
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
3.3.2.3. Metoda excesului de capacitate

Aceasta este o altă tehnică de dirijare adaptivă distribuită. În această tehnică se

utilizează căile multiple într-un mod eficient, chiar şi în cazul unei încărcări cu un
volum mare de trafic. Pachetele sunt dirijate pe calea cea mai scurtă ce are un surplus
de capacitate disponibilă. În acest fel mai multe căi de la un nod către o anumită
destinaţie pot fi utilizate simultan.

3.3.2.4. Algoritmul de "rutare optimală"

Chiar fără a cunoaşte în detaliu topologia reţelei şi caracteristicile traficului, pot

fi enunţate câteva principii generale numite "principii de optimizare". Dacă se constată
că nodul J este pe calea optimă care vine de la I la K, calea optimă de la J către K
urmează aceeaşi rută. Consecinţa directă a acestui principiu este că mulţimea căilor
optime de la un nod către toate celelalte noduri este un arbore cu rădăcina în nodul
destinaţie. Fiecare nod conţine o tabelă de costuri în care coloanele corespund nodurilor
vecine iar liniile nodurilor destinaţie. Conţinutul fiecărei locaţii din tablou reprezintă
costul către destinaţie "via" arborele colector care conţine nodul vecin corespunzător.
De exemplu, pentru nodul 4, tabelul costurilor şi tabelul de rutare vor fi:

Nodul vecin
Nod destinaţie 1 2 3 Nod destinaţie Nodul vecin
1 [1] 4 -1 1 1
2 3 [2] -1 2 2
3 -1 5 [2] 3 5
4 -- -- -- 4 --
5 -1 -1 [1] 5 5
6 -1 -1 [3] 6 5

S-a notat cu -1 faptul că nodul vecin este în amonte pe arborele colector. Tabela
de rutare se completează alegând (exceptând valorile negative) ieşirea de cost minim
(încadrată în paranteze drepte). În situaţia întreruperii unei linii de legătură, nodurile
implicate modifică coloana respectivă (de exemplu, completând cu valoarea -2) şi se
trece la reactualizarea tabelelor de rutare. În cazul în care în tabela de costuri se obţin
linii care conţin doar valori negative, nodul respectiv dialoghează cu vecinii săi din
amonte pentru a determina noii arbori colectori ai reţelei. Ca exemplu, fie reţeaua din

22
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
figura 3.15, pentru care sunt prezentaţi mai apoi arborii colectori corespunzători
fiecărui nod. Pentru fiecare arbore nodurile rădăcină sunt haşurate.

3
2 3 2 3
2 5 2
5
1 2 1 6 1 6
1

1 1 2 2
4 5 1 1
4 5
Reteaua initiala Pasul 1

3
2 3 3
2 2 3

1 2 6 1 6
1

1 2 2
4 5 1 1
4 5
Pasul 2 Pasul 3

2 3 2 3

1 2 1 6 1 6
1

1 1 2 2
4 5 1 1
4 5
Pasul 4 Pasul 5

2 3

1 2 1 6

1 1 2
4 5
Pasul 6
Figura 3.15: Reţea şi arborii colectori corespunzând fiecărui nod

23
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__

Până la întreruperea legăturii 4-5, nodurile din amonte faţă de nodul 4 aveau tabelele:
NOD 1 Nodul vecin NOD 2 Nodul vecin
Nod destinaţie 2 4 Nod destinaţie 1 4 3
1 -- -- 1 [2] 3 6
2 [2] 3 2 -- -- --
3 5 [3] 3 5 4 [3]
4 4 1 4 3 [2] 5
5 5 [2] 5 4 [3] 4
6 7 [6] 6 6 [5] 6
După primirea pachetului de control ce corespunde tăierii legăturii 4 - 5 şi
efectuarea modificărilor aferente, situaţia se prezintă astfel:
NOD 1 (3,5,6) Nodul vecin NOD 2 (5,6...) Nodul vecin
Nod destinaţie 2 4 Nod destinaţie 1 4 3
1 -- -- 1 [2] 3 6
2 [2] 3 2 -- -- --
3 [5] -1 3 5 4 [3]
4 [4] -1 4 3 [2] 4
5 [5] -1 5 [4] -1 4
6 [7] -1 6 [6] -1 [6]

NOD 4 Nodul vecin

Nod destinaţie 1 2 5
1 [1] 4 -2
2 3 [2] -2
3 6 4 -2
4 -- -- --
5 7 [6] -2
6 9 [8] -2
Pe baza reactualizării tabelei de costuri, tabela de rutare a nodului 4 devine:
NOD 4
Nod destinaţie Nodul vecin
1 1
2 2
3 2
4 --
5 2
6 2

24
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__

3.3.3. Rutarea adaptivă centralizată.

Întrucât algoritmii de rutare adaptivă distribuită sau locală se adaptează lent la

evenimentele care au loc la distanţă, s-a pus problema găsirii unor metode care să se
bazeze pe o supraveghere mai largă a reţelei. O metodă prin care se realizează o
supraveghere a reţelei este stabilirea unui centru de dirijare a reţelei, caz în care
dirijarea adaptivă centralizată devine algoritmul operativ.
În cadrul rutării centralizate, există un nod (numit "nod central") care ia toate
deciziile referitoare la rutare. Periodic, fiecare nod din reţea generează rapoarte de stare
care conţin informaţii către nodul central. Aceste informaţii se referă la felul în care
funcţionează nodul, la variaţiile de trafic survenite de la ultimul raport, la numărul de
pachete din memoriile tampon, la eventuale situaţii de blocare a reţelei. Nodul central
recepţionează rapoartele şi, pe baza acestora, având o imagine de ansamblu asupra
reţelei, decide care sunt noile tabele de rutare pentru nodurile subordonate. Nodul
central actualizează aceste tabele şi le distribuie tuturor nodurilor din reţea. Unul din
avantajele acestui tip de rutare constă în faptul că deciziile se iau pe baza unor
informaţii complete despre reţea. În plus, complexitatea nodurilor subordonate este
mult redusă datorită faptului că nu iau decizii referitoare la modificările tabelelor de
rutare. Din nefericire, există şi multe dezavantaje. Dacă reţeaua este de mari dimensiuni
şi tabelele se modifică frecvent, volumul de calcule pe care trebuie să le facă nodul
central este ridicat. O problemă este şi vulnerabilitatea nodului central. Dacă acest nod
se defectează, întreaga reţea nu mai funcţionează. De asemenea, vulnerabile sunt şi
liniile conectate la nodul central, linii pe care se transferă toate pachetele cu funcţii de
rutare. Liniile care servesc nodul central sunt mult solicitate, existând pericolul să intre
în congestie blocând nodul central. O imagine sugestivă a acestui lucru este dată de
figura 3.16.

Figura 3.16: Încărcarea liniilor de la noduri înspre centrul de control al rutării

25
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
Pentru o reţea mare, trimiterea datelor către nodul central şi distribuţia tabelelor
de rutare pentru nodurile subordonate poate dura mult timp, astfel încât noile rute
calculate drept optime nu mai corespund situaţiei din reţea. Apare o întârziere între
transmiterea iniţială a fiecărui raport şi recepţia sa de către centrul de control. Pentru
nodurile îndepărtate această întârziere poate fi semnificativă. În celălalt sens, după ce
centrul a efectuat calculele de dirijare, care ele însele pot dura un interval de timp,
timpul necesar pentru recepţionarea de către toate nodurile a tabelelor de dirijare
revizuite poate fi în egală măsură la fel de semnificativ. În acest fel centrul lucrează cu
informaţii parţial învechite şi distribuie către noduri tabele de dirijare care vor fi şi mai
învechite în momentul recepţiei. Într-o reţea în care traficul prezintă schimbări rapide
este greu ca un astfel de algoritm să funcţioneze eficient. Se poate spune că aceşti
algoritmi sunt potriviţi pentru reţele cu topologie stabilă şi trafic relativ constant. Rolul
major al acestor algoritmi este acela de a adapta îndrumarea traficului la modificările
topologice ale reţelei.
În concluzie, se poate spune că algoritmii adaptivi globali au avantaje precum:
• deciziile luate tind către ideal;
• eliberează interfeţele de calculele suplimentare.
Au însă şi numeroase dezavantaje:
• vulnerabilitatea reţelei datorită defectării Unităţii Centrale (UC) a Centrului de
Control al Rutării (RCC) sau întreruperii legăturilor RCC cu reţeaua. Soluţia
acestei probleme este duplicarea UC, existând însă şi în acest caz dezavantaje
(costul reţelei creşte, apare necesitatea existenţei unui arbitru care să arbitreze
posibilele conflicte între cele două UC);
• informaţia referitoare la rutare se poate propaga cu întârzieri mari până la
nodurile cele mai îndepărtate din reţea, astfel încât nodurile îşi schimbă tabelele
de rutare la momente diferite de timp. Se poate ajunge astfel la situaţii de
inconsistenţă a reţelei, pachetele fiind întârziate exagerat, printre ele fiind şi
pachetele de rutare. Rezultă un fenomen de cerc vicios.

3.3.4. Rutarea adaptivă hibridă

Datorită dezavantajelor pe care le prezintă rutările adaptive izolată şi distribuită

(fie că nu sunt informate despre evenimentele îndepărtate, fie că sunt informate prea
încet) precum şi cea centralizată ( informarea privind evenimentele din reţea soseşte cu
întârziere, control instabil care poate duce la o pendulare a algoritmului în funcţie de
modificările din trafic), s-a încercat găsirea unui sistem de dirijare care să combine
avantajele tehnicilor mai sus menţionate, evitând dezavantajele lor.

26
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
3.3.4.1. Algoritmul de rutare "delta"

Acest algoritm este un hibrid între rutarea centralizată şi rutarea locală.

În dirijarea delta se stabileşte un controlor al dirijării centralizate în reţea.
Nodurile măsoară "costul" fiecarei linii şi trimit periodic către nodul central un pachet
cu datele citite. Costul unei linii poate fi dat de întârzierea pe linie, de lungimea cozilor
de aşteptare, de debitul pe linie... Pe baza acestor informaţii, nodul central calculează
cele mai bune k trasee pentru a ajunge de la nodul i la nodul j, pentru toate nodurile din
reţea. Fie C1ij costul celui mai bun drum, C2ij costul următorului ş.a.m.d. Dacă Cijn - C1ij <
δ, drumul n este considerat aproape echivalent cu drumul 1, deoarece costurile lor
diferă puţin. Atunci când se termină aceste calcule, nodul central trimite către celelalte
noduri lista tuturor căilor echivalente posibile către orice destinaţie. Nodurile pot alege
oricare dintre drumurile echivalente. Alegerea se face în strânsă legătură cu lungimea
şirurilor de aşteptare locale. Dacă există mai multe căi de la un nod la o anumită
destinaţie, atunci algoritmul de dirijare lasă ca situaţia locală să determine care rută este
folosită pentru fiecare pachet. Dacă tabelele globale indică faptul că o anumită rută este
mai bună, atunci deciziile de dirijare în nod sunt constrânse să utilizeze acea cale. În
acest fel, este ales drumul cel mai scurt, dar şi cel mai fiabil. Când δ tinde la 0, toate
drumurile sunt judecate ca fiind inferioare drumului cel mai bun şi nodul central ia
toate deciziile. Din contră, dacă δ tinde la infinit, toate drumurile sunt judecate ca fiind
echivalente şi deciziile de rutare se iau la nivelul fiecărui nod, pe baza informaţiilor
locale. Prin alegerea parametrului δ, se poate împărţi responsabilitatea luării deciziei de
rutare între nodul central şi nodurile subordonate.
Decizia de dirijare într-un nod (A) pentru traficul destinat altui nod (B) este
ilustrată în figura 3.17.

A 2 B

Figura 3.17: Dirijare delta

27
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__

Compararea timpului la centrul de dirijare al Tabela de dirijare transmisă la

reţelei nodul A
(Traficul A → B )
Primară Secundară
Timpul (A→B) via 1<Timpul (A→B) via 3 - δ via 1 -
Timpul (A→B) via 3<Timpul (A→B) via 1 - δ via 3 -
|Timpul (A→B) via 1-Timpul (A→B) via 3| ≤ δ via 1 via 3

Rutele alternative specificate sunt via nodul 1 şi nodul 3. Dacă diferenţa între
timpii prin nodurile 1 şi 3 este mai mare decât valoarea "delta", specificată în mod
individual pentru această decizie de dirijare de către controlorul central, atunci traficul
de la A la B este transmis pe ruta cea mai rapidă. Dacă diferenţa este mai mică decât
"delta", atunci traficul este distribuit pe cele două rute.
Unele simulări în care s-au comparat performanţele dirijării delta cu alte metode
de dirijare implicând tehnici de dirijare distribuite şi centralizate, au arătat că algoritmul
delta are cel mai mare succes în ceea ce priveşte utilizarea maximă a capacităţii reţelei
şi cei mai mici timpi de întârziere.
Un alt avantaj al acestei metode este acela că dacă se defectează sau rămâne
izolat controlorul central nodurile pot, cel puţin pentru un interval de timp, să-şi
continue funcţionarea pe baza tabelelor existente, controlând dirijarea pachetelor
individuale. În acest caz nodurile se comportă ca şi cum s-ar folosi dirijarea adaptivă
izolată. Reluarea controlului de către nodul central poate avea loc foarte simplu în
momentul restabilirii comunicaţiilor.
O altă tehnică hibridă este aceea în care există un sistem ierarhic de dirijare şi
control al fluxului. În acest sistem reţeaua este divizată în noduri strâns legate. Fiecărei
zone i se alocă un controlor local al dirijării, care recepţionează rapoartele de stare de la
nodurile sale locale. Fiecare controlor calculează rutele în propria sa zonă şi schimbă
informaţii de dirijare cu ceilalţi controlori folosind pachete de control de prioritate
mare. Această tehnică are scopul de a reduce întârzierea de timp între generarea
rapoartelor de stare şi recepţia instrucţiunilor de dirijare, prin existenţa controlorilor
locali. Privirea generală asupra reţelei se obţine prin mai mulţi controlori care comunică
între ei.

28
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__

3.5. Rutarea în reţele mari

Creşterea dimensiunilor reţelelor pune probleme noi în ceea ce priveşte

algoritmii de rutare. Creşterea unei reţele poate fi făcută fie prin propria extindere, fie
prin interconectarea cu alte reţele deja existente. Nu se va face aici referire la modul în
care se poate realiza interconectarea reţelelor, problema dirijării fiind în mare aceeaşi.
Nodurile de interconectare a reţelelor sunt denumite în mod obişnuit porţi. În
mod conceptual, un set de reţele interconectate prin porţi pot fi privite ca o singură
reţea cu canale de comunicaţie ce conectează nodurile poartă. Tratând problema ca pe
una de dirijare de la o poartă la altă poartă, se poate simplifica procesul de dirijare.
Un prim lucru esenţial este stabilirea unui sistem de adresare global. Acesta se
poate realiza prin realizarea unei adrese cu două niveluri, fiecare nod fiind desemnat
prin adresa sa din reţeaua din care face parte, iar fiecare reţea separată este desemnată
de identificatorul său unic. În cazul în care numărul de reţele separate interconectate
devine foarte mare se poate apela la un sistem ierarhic cu mai multe niveluri. În acest
caz se pot stabili grupuri de reţele, comunicaţia între grupuri putându-se face prin
intermediul unor superporţi.
Principiul de poartă înlătură necesitatea de a prevedea în fiecare nod din reţea
tabele de dirijare complete care să specifice în mod precis ruta către fiecare nod din
fiecare reţea. Tot ceea ce este necesar este ca fiecare nod să aibă tabele de dirijare ce
indică poarta corespunzătoare pentru reţeaua destinatară. În interiorul unei reţele
individuale pachetele pot fi încadrate temporar într-un format cerut de protocolul local.
Singura adresă necesară în format este adresa locală a următorului nod poartă prin care
se va trece.
Una dintre cele mai importante probleme care pot apare în determinarea căii în
reţelele interconectate este aceea a diferenţei de standarde între reţele. Cea mai
importantă problemă din acest punct de vedere este aceea a dimensiunii pachetelor. Se
poate întâmpla ca un pachet mare sosit într-o reţea să fie nevoie să fie divizat în mai
multe pachete. În acest moment apare problema dificilă a reasamblării pachetului la
ieşirea din acea reţea. Dacă în reţeaua respectivă s-a adoptat ca tehnică de dirijare o
rutare fixă, atunci secvenţialitatea pachetelor a fost păstrată, deci nu sunt probleme la
reasamblare. Dacă însă tehnica a fost aceea a unei dirijări adaptive, nu mai poate fi
garantată secvenţialitatea pachetelor şi aici apare dificultatea reasamblării.
De aceea se pot utiliza tehnici care să evite divizarea pachetelor, prin alegerea
unor rute care să nu implică divizarea. Se pot concepe metode de dirijare globală care
să evite reţelele cu limite de lungime a pachetelor. În acest fel se creează o discriminare

29
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
a pachetelor mari care sunt nevoite să ocolească unele reţele în timp ce pachetele mici
vor fi libere să le utilizeze şi pe acestea.

3.5.1. Rutarea ierarhizată

În cazul reţelelor mari, folosind algoritmii "clasici", tabelele de dirijare ar

deveni foarte mari dacă trebuie să ţină seama de fiecare detaliu privind rutele către toate
nodurile posibil destinatare din reţea. Pentru a se obţine economii în ceea ce priveşte
dimensiunea tabelei de adresare dintr-un nod se poate folosi un sistem de adresare pe
arii sau ierarhizat.
Într-un astfel de sistem mai multe noduri vecine sunt desemnate ca făcând parte
dintr-un grup de noduri. Pentru a circula de la o sursă la o destinaţie din alt grup de
noduri, ruta specificată în tabelele de dirijare din noduri va indica liniile de traversat
pentru a ajunge la grupul destinatar. Numai după intrarea în grupul destinatar tabelele
de dirijare vor specifica calea către nodul destinatar. În felul acesta, tabelele de dirijare
din fiecare nod adresează toate nodurile care fac parte din grup cu rutele de utilizat
pentru a ajunge la ele. Toate celelalte noduri, care fac parte din alte grupuri, vor fi
reprezentate în tabele prin grupul din care fac parte. De exemplu, pentru o reţea cu 100
de noduri, conţinând 5 grupuri a câte 20 de noduri, fiecare tabelă de dirijare dintr-un
nod va avea 23 poziţii (19 noduri locale făcând parte din acelaşi grup cu nodul respectiv
şi 4 grupuri străine), în comparaţie cu 99 de poziţii în cazul în care reţeaua nu ar fi
ierarhizată. Câmpul de adresă din antetul pachetelor poarte fi divizat în două zone, o
zonă de grup şi una de nod.
În figura 3.18 este prezentat un exemplu de rutare ierarhică pe două niveluri
având cinci regiuni. Este prezentat tabelul de rutare în cazul în care s-ar face o rutare
neierarhică, având 17 intrări, precum şi tabelul în cazul utilizării rutării ierarhice, caz în
care este câte o intrare pentru fiecare nod aparţinând grupului şi câte o intrare pentru
fiecare dintre celelalte grupuri. Dirijarea ierarhică a redus dimensiunea tabelelor de la
17 la 7. Aşa cum am prezentat anterior, pentru un număr mai mare de regiuni
dimensiunea tabelelor este redusă proporţional. Există însă şi dezavantaje ale acestei
metode. Se poate întâmpla ca drumul cel mai scurt între două noduri arbitrare să nu fie
cel desemnat prin aceste tabele (în exemplul prezentat în figura 3.27 este cazul
particular al drumului între nodurile 1A şi 5C, pentru care drumul cel mai scurt trece
prin regiunea 2, dar prin rutarea ierarhică tot traficul dintre zona 1 şi zona 5 este dirijat
prin zona 3).

30
 Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
destinatie linie numar destinatie numar
1B 2A 2B de salturi linie de salturi

1C 2D 2C 1A - - 1A - -
1A
1B 1B 1 1B 1B 1
1C 1C 1 1C 1C 1
5C
5B 5D 2A 1B 2 2 1B 2
2B 1B 3 3 1C 2
3A 5A 5E 2C 1B 3 4 1C 3
3B
4A 2D 1B 4 5 1C 4
3A 1C 3
3B 1C 2 Tabela in cazul
4B 4C 5 dirijarii ierarhice
4A 1C 3
pentru nodul 1A
4B 1C 4
4C 1C 4
5A 1C 4
5B 1C 5
5C 1B
5 5
5D 1C 6
5E 1C 5

Tabela comleta
pentru nodul 1A
Figura 3.18: Rutare ierarhică

Dezvoltând ideea ierarhizării s-a creat o structură ierarhizată care nu este

conectată complet şi în care nodurile sunt grupate pe zone, iar dintre aceste noduri se
desemnează unul ca fiind supernod (sau nod regional). Nodul regional poate fi un
echipament mai puternic în comparaţie cu nodurile locale din regiune. Fiecare nod local
dintr-un grup este conectat la nodul regional fie prin linie directă, fie prin cel mult alte
două noduri. Într-o ierarhie cu două niveluri, nodurile regionale vor fi interconectate
prin linii de viteză mai mare decât liniile interne din regiuni. În funcţie de numărul de
noduri din regiune se poate ca acestea să fie total conectate. Pentru reţelele foarte mari
se poate crea un al treilea nivel ierarhic. În aceste reţele grupuri de noduri vor fi servite
de hipernoduri. În principiu hipernodurile vor fi total conectate prin linii de mare
viteză.
S-a făcut un studiu asupra unei reţele ierarhizate cu două niveluri ierarhice
conţinând cinci regiuni locale, fiecare compusă din nouă noduri ordinare şi un
supernod. Topologia reţelei este arătată în figura 3.19.

31
Rutarea în reţelele cu comutare de pachete
__________________________________________________________________________
__
Zona locala

Zona locala

Zona locala Retea de nivel

inalt

Zona locala Zona locala

Linii de nivel inalt

Linii intre nivele
Linii de conectare
intre zone
Figura 3.19: Reţea asupra căreia s-a făcut un studiu privind dirijarea ierarhizată

Cele cinci regiuni locale au fost conectate în inel prin linii de conexiuni în inel.
Cele cinci supernoduri au fost conectate prin linii de bandă largă. Metoda de dirijare
urmărea ca traficul între regiunile neadiacente să treacă întotdeauna prin nivelul
superior. Traficul în interiorul unei regiuni nu circulă prin nivelul superior. Traficul
între regiuni locale alăturate se desfăşoară în două variante: fie este transportat de
nivelul superior, fie sunt folosite liniile dintre regiuni. În realizarea metodei s-a avut
drept model telefonia cu comutaţie de circuite. Rutele de pe nivel inferior au fost
desemnate ca rute primare între nodurile din jurul graniţei dintre regiuni. Rutele
secundare au fost desemnate cele prin nivelul superior. Un nod care găsea o rută
primară ocupată transmitea un pachet către cel mai apropiat nod de pe nivelul superior,
în majoritatea cazurilor trecând prin cel puţin un nod inferior. Pentru a se asigura că
pachetul a fost direcţionat spre nodul de nivel superior şi nu a fost deviat spre interior
de către un nod intermediar, s-a luat măsura ca nodul care decidea utilizarea nivelului
superior să marcheze corespunzător pachetul. Nodurile intermediare observau marcajul
de rută de nivel superior şi transmiteau pachetul în consecinţă. Performanţele reţelei
lucrând cu o astfel de metodă s-au dovedit inferioare celor în care s-a folosit o metodă
de dirijare mai simplă.

32
 CAPITOLUL 6

MOBILITATE IP

6.1 Privire de ansamblu, istorie, motivatie

Problema mobilităţii a cunoscut o creştere considerabilă a popularitaţii în ultimii ani datorită

dezvoltării miniaturizării. Astăzi putem deţine într-un notebook puterea care era altădată cerută de o
maşină de calcul enormă. De asemenea avem la dispoziţie reţele LAN wirelesscare permit deplasarea cu
uşurinţă a unui dispozitiv dintr-un loc în altul, menţinând conectivitatea la nivelul legăturii de date. Din
păcate, Internetul s-a dezvoltat fără o majoră preocupare privind deplasarea computerelor. Pentru a
înţelege de ce IP (Internet Protocol) nu lucrează bine îmtr-un mediu mobil, trebuie să aruncăm o privire
înapoi pentru a urmări funcţionarea adresării IP şi a rutării.

6.1.1. Problema nodurilor mobile în TCP/IP

Aşa cum s-a văzut anterior, adresele IP sunt divizate fundamental în două zone: un identificator al
reţelei şi un identificator al gazdei. Identificatorul reţelei specifică reţeaua căreia îi aparţine gazda, iar
identificatorul gazdei specifică în mod unic identitatea gazdei în interiorul reţelei. Această structură este
fundamentală pentru o rutare de tip datagramă, deoarece dispozitivele de pe traseu utilizează porţiunea
de reţea a adresei destinaţie a pachetului pentru a determina dacă destinaţia aparţine reţelei locale sau
uneia distante, caz în care ruterele o utilizează pentru a determina modul în care vor dirija pachetul.
Acest mod de funcţionare are o deficienţă majoră: adresa IP este legată strâns de reţeaua în care
dispozitivul este localizat. Majoritatea dispozitivelor nu îşi modifică niciodată punctul prin care sunt
ataşate la reţea, deci nu este o problemă pentru acestea, dar devine o problemă pentru dispositive mobile.
Atunci când un dispozitiv mobil părăseşte locaţia de origine (home location), sistemul de rutare pe baza
adresei IP eşuează. Acest lucru este ilustrat în figura 6.1. În acest exemplu, un dispozitiv mobil
(notebook) s-a mutat din reţeaua sa din Londra în altă reţea din Tokyo. Un client distant (cel din stânga
sus) decide să trimită o datagramă dispozitivului mobil. El nu ştie faptul că dispozitivul s-a mutat.
Întrucât el transmite utilizând adresa de acasa a nodului mobil, 71.13.204.20, cererea sa este dirijată
către ruterul responsabil de acea reţea, care este în Londra. Bineînţeles că dispozitivul mobil nu este
acolo, deci ruterul nu poate livra datagrama. Mobile IP rezolvă această situaţie oferind ruterului şi
dispozitivului mobil capacitatea de a transmite datagrame dintr-o locaţie în alta.

1 
 
 Figura 6.1

6.1.2. Dificultăţi întâmpinate cu vechile soluţii privind nodurile mobile

Legătura strânsă dintre identificatorul de reţea şi adresa IP a gazdei oferă numai două opţiuni reale
în situaţia IP convenţională când un dispozitiv mobil se deplasează dintr-o reţea în alta:
- Schimbarea adresei IP: Putem schimba adresa IP a gazdei într-o adresă nouă care să includă
identitatea reţelei în care s-a deplasat dispozitivul.
- Decuplarea dirijării (rutării) IP de adresă: Putem face ca rutarea să se realizeze pentru dispozitiv,
astfel încât ruterele, în loc să trimita datagrama către dispozitiv bazându-se pe identitatea reţelei, să facă
rutarea pe baza întregii adrese.

Ambele opţiuni par viabile la o primă vedere şi dacă s-ar încerca soluţiile pentru un număr redus
de dispozitive, ar putea funcţiona. Din păcate ambele sunt ineficiente, chiar nepractice şi nici scalabile,
ceea ce înseamnă că, în cazul în care milioane de dispozitive ar încerca aceste soluţii am avea:

- Schimbând adresa IP de fiecare dată când un dispozitiv se deplasează, avem un consum de timp
şi în mod normal este necesară o intervenţie manuală. În plus, întreaga stivă TCP/IP trebuie repornită,
întrerupând orice legătură existentă.

2 
 
 - Dacă modificăm adresa IP a dispozitivului, cum vom comunica schimbarea adresei altor
dispozitive din Internet? Aceste dispozitive nu vor avea decât adresa de domiciliu a nodului mobil, ceea
ce înseamnă că nu vor fi capabile să-l localizeze chiar dacă îi dăm o altă adresă marcând noua locaţie.
- Rutarea bazată pe întreaga adresă a gazdei implică faptul că întregul Internet va fi inundat cu
informaţii de rutare pentru fiecare dispozitiv mobil. Luând în considerare efortul imens depus pentru
dezoltarea tehnologiilor de adresare (clase de adrese) având ca scop reducerea dimensiunilor tabelelor de
rutare, este evident că nimeni nu va dori o astfel de evoluţie.

6.1.3. O soluţie superioară: Mobile IP

Soluţia acestor dificultăţi este definirea unui nou protocol special pentru a suporta dispozitive
mobile, care să se adauge Protocolului Internet original. Acest protocol, numit IP Mobility Support for
IPv4, a fost definit iniţial în RFC 2002, dezvoltat în RFC 3220 şi acum este descries în RFC 3344.
Numele formal aşa cum este dat în titlul documentului fiind prea lung, tehnologia este numită uzual
Mobile IP atât în document, cât şi de către “reţelişti”.

Pentru a-i asigura succesul, proiectanţii Mobile IP au trebuit să vină în întâmpinarea mai multor
obiective. Protocolul rezultat a avut următoarele atribute şi facilităţi cheie:

- Întreaga mobilitate a dispozitivului utilizând adresa existentă a dispozitivului: Dispozitivele

mobile îşi pot schimba ataşamentul fizic la reţea şi locaţia, continuând să utilizeze adresa IP existentă.
- Fără cerinţe noi privind adresarea şi rutarea: Este menţinută întreaga schemă de adresare şi rutare
existentă în IP obişnuit. Adresele IP sunt atribuite în continuare într-un mod convenţional, de către
proprietarul fiecărui dispozitiv. Nu vor fi plasate în reţea cerinţe noi privind rutarea, cum ar fi rute
specifice unei gazde.
- Interoperabilitatea: Dispozitivele Mobile IP pot transmite şi recepţiona mesaje către/de la
dispozitive care nu ştiu cum funcţionează Mobile IP şi vice-versa.
- Transparenţa nivelului: Schimbările efectuate de către Mobile IP sunt restrânse la nivelul reţea.
Protocoalele nivelului transport şi nivelurilor superioare, precum şi aplicaţiile vor continua să
funcţioneze ca şi în cazul IPv4 obişnuit şi conexiunile existente vor putea fi menţinute şi în cazul unei
deplasări.
- Schimbări limitate de hardware: Schimbările cerute se vor realiza la nivel software în
dispozitivele mobile şi în ruterele direct conectate la acestea. Alte dispozitive, inclusiv ruterele dintre
reţeaua de domiciliu şi cea vizitată nu vor necesita schimbări.
- Scalabilitatea: Mobile IP permite unui dispozitiv să se deplaseze dintr-o reţea în alta, suportând
acest fapt pentru un număr arbitrar de dispozitive. Scopul schimbării conexiunii este global; poţi detaşa
un notebook dintr-un birou din Bucureşti şi să îl reconectezi în Argentina, el funcţionând ca şi când l-ai
reconectat în biroul alăturat.
- Securitatea: Mobile IP lucrează prin redirecţionarea mesajelor, incluzând proceduri de
autentificare pentru a preveni situaţii create de dispositive neautorizate.

Mobile IP completează aceste obiective prin implementarea unui sistem de transmitere pentru
dispozitivele mobile. Când un dispozitiv mobil se găseşte în reţeaua de domiciliu (“home”) va funcţiona
normal. Când se va deplasa într-o reţea diferită, datagramele vor fi trimise din reţeaua sa de domiciliu
către noua locaţie. Aceasta permite dispozitivelor normale şi ruterelor care nu cunosc Mobile IP să
continue să opereze ca şi când dispozitivul mobil nu s-a deplasat. Sunt necesare servicii suport speciale

3 
 
pentru a implementa Mobile IP, pentru a permite activităţi cum ar fi posibilitatea ca dispozitivul mobil
să îşi determine poziţia, să poată spune reţelei de domiciliu unde să îi transmit mesajele, şi altele.

6.1.4. Limitările Mobile IP

Mobile IP are limitări certe într-un mediu wireless. A fost proiectat pentru a manevra mobilitatea
dispozitivelor, dar numai o mobilitate relativ rară, din cauza volumului de operaţii implicate pentru
fiecare schimbare. Această încărcare nu reprezintă mare lucru dacă computerul se mută la o săptămână,
sau o dată pe zi, sau o dată pe oră. Mobile IP a fost proiectat sub ipoteza că punctul de ataşare la reţea nu
se modifică mai mult de o dată pe secundă.

De asemenea, Mobile IP a fost prevăzut să fie utilizat cu dispozitive care menţin o configuraţie IP
statică. Întrucât este necesar ca dispozitivele să-şi cunoască întotdeanuna identitatea propriei reţele şi
adresa IP, este mult mai dificil de utilizat cu un dispozitiv care obţine o adresă IP dinamic, utilizând un
protocol ca DHCP.

Dynamic Host Configuration Protocol (DHCP) este un protocol pentru configurarea gazdelor,
utilizat curent în reţelele TCP/IP moderne. DHCP constă în două component majore: un mechanism de
alocare a adresei şi un protocol care permite clienţilor să ceară şi serverelor să furnizeze informaţii de
configurare.

6.2. Concepte Mobile IP

Pentru a înţelege cu uşurinţă problema dispozitivelor mobile într-o inter-reţea IP, putem cu
uşurinţă compara cu problema din viaţa reală în care trebuie livrat un mesaj unei persoane care
călătoreşte. Să presupunem că este vorba despre un consultant pentru o corporaţie extinsă care are o
mulţime de birouri. Biroul de bază este la Londra, unde îşi petrece cam jumătate din timp. Cealaltă
jumătate din timp este împărţita între birourile din Roma, Tokyo, New York. De asemenea vizitează o
mulţime de clienţi, aşa că se poate afla oriunde pe glob.
Problema care apare este următoarea: cum se poate aranja ca acest consultant să-şi primească
corespondenţa indiferent de locaţie? Este aceeaşi problemă pe care o are IP-ul obişnuit cu dispozitivele
mobile, având cele două opţiuni nesatisfăcătoare de rezolvare: modificarea adresei şi decuplarea rutării
de adresă. Consultantul nu poate schimba adresa de fiecare dată când se mută, deoarece ar schimba-o în
permanenţă. Până când va spune tuturor care este noua adresă, va trebui să o schimbe din nou. Nici nu se
poate pune problema decuplării rutării de adresă, cu excepţia creerii propriului sistem de livrare.
Soluţia problemei o constituie mecanismul de transmitere al mesajului. Să presupunem că acest
comisionar părăseşte Londra pentru două luni. El va anunţa oficiul poştal din Londra că se va afla la
Tokyo. Cei de la oficiul poştal vor intercepta mesajele având ca antet adresa normală din Londra, le vor
reeticheta şi le vor redirecţiona către Tokyo. Dacă părăseşte Tokyo pentru un alt oraş, este suficient să
anunţe oficiului din Londra noua locaţie. Atunci când revine acasă, va renunţa la serviciul de
redirecţionare şi va primi mesajele în mod obişnuit.
Avantajele unui astfel de sistem sunt numeroase. Este simplu se înţeles şi de implementat. Este
transparent pentru oricine transmite un mesaj; mesajul se transmite întotdeauna către adresa de acasă,
indiferent unde va fi apoi eventual retransmis. Mecanismul de redirecţionare va fi aplicat numai la
oficiul la care este arondat domiciliul, restul sistemului nefiind cu nimic implicat.

4 
 
 Apar şi câteva dezavantaje. Oficiul de domiciliu va solicita o plată pentru serviciul oferit. Este
necesar şi un aranjament special în oraşul în care te deplasezi. De fiecare dată când te deplasezi trebuie
să iei legătura cu oficiul de domiciliu. Şi poate cel mai important fapt, fiecare mesaj este transmis de
două ori, o dată către adresa de domiciliu şi a doua oară către adresa în care te-ai deplasat.
Mobile IP lucrează similar cu serviciul poştal. Consultantul în discuţie este un dispozitiv mobil
care se deplasează dintr-o reţea în alta. Fiecare reţea poate fi considerată ca fiind un alt oraş, iar inter-
reţeaua de rutere poate fi privită ca sistemul poştal. Ruterul care conectează o reţea la Internet este un fel
de oficiu poştal pentru acea reţea, din perspective IP.

Figura 6.2: General Operation of the Mobile IP Protocol

Nodul mobil este rezident în mod normal în reţeaua de domiciliu (home network), care este cea
indicată de identificatorul de reţea (network ID) din adresa IP. Dispozitivele din inter-reţea dirijează
întotdeauna conform adresei IP, astfel că datagramele ajung întotdeauna la un ruter al domiciliului
dispozitivului. Când dispozitivul se deplasează într-o altă reţea, ruterul de domiciliu (home router)
interceptează aceste datagrame şi le transmite pe adresa curentă a dispozitivului. Poate să le trimită
direct către dispozitiv folosind eventual o adresă temporară, sau poate să trimita unui ruter ataşat reţelei
în care se află dispozitivul în vederea unei distribuiri finale.

Modul cum operează Mobile IP poate fi ilustrat de figura 6.2. Diagrama din figura 6.2 este
similară celei din figura 6.1, dar are implemetat Mobile IP. Ruterul de domiciliu al nodului mobil are rol
de agent de domiciliu (home agent), iar ruterul din Tokyo are rol de agent extern (foreign agent).
Mobilul are asociată temporar o adesă “care-of” care va fi utilizată cât timp se află la Tokyo. În pasul
#1, clientul distant transmite o datagramă către dispozitivul mobil utilizând adresa sa de domiciliu, ca şi

5 
 
înainte. Aceasta ajunge, ca de obicei, la Londra. În pasul #2, agentul de domiciliu încapsulează
datagrama în una nouă şi o transmite dispozitivului mobil la Tokyo.

6.2.1. Rolurile dispozitivelor Mobile IP.

După cum s-a observant, Mobile IP a avut nevoie de ajutorul a două rutere. De fapt, există trei
jucători principali care implementează protocolul :

- Nodul mobil (Mobile Node): Este dispozitivul mobil, cel care se deplasează prin inter-reţea.
- Agentul de domiciliu (Home Agent): Acesta este un ruter din reţeaua de domiciliu (home
network) care este responsabil de interceptarea datagramelor destinate nodului mobil şi transmiterea lor
către acesta când se deplasează. De asemenea implementează alte funcţii support necesare funcţionării
protocolului.
- Agentul extern (Foreign Agent): Este un ruter din reţeaua în care a ajuns dispozitivul mobil. El
funcţionază ca o altă casă pentru nodul mobil. În funcţie de modul de operare, el poate recepţiona
datagramele transmise de către agentul de domiciliu şi le poate transmite către nodul mobil. De
asemenea va distribui informaţii de mobilitate pentru a face operaţional Mobile IP. Este posibil ca în
unele implementări ale Mobile IP agentul extern să nu fie necesar, dar uzual este considerat parte
integrantă a protocolului.

Terminologie
Anunţ din partea agentului (Agent Advertisement): este un mesaj trensmis de către ruter pentru a-
şi anunţa prezenţa.
Autentificare (Authentication): process de verificare (utilizând tehnici de criptare) a identităţii
sursei mesajului.
Adresa care-of: punctul terminal al tunelului care ajunge la nodul mobil. Protocolul utilizează
două tipuri de astfel de adrese:
- adresă care-of a agentului extern ("foreign agent care-of address"): adresa agentului extern la
care nodul mobil este înregistrat
- "co-located care-of address": o adresă locală obţinută extern cu care este asociat nodul mobil.
Nodul corespondent (Correspondent Node): perechea cu care nodul mobil corespondează. Nodul
corespondent poate fi mobil sau staţionar.
Reţeaua străină (Foreign Network): orice altă reţea diferită de reţeaua de domiciliu a nodului
mobil.
Adresa de domiciliu (Home Address): o adresă IP asociată dispozitivului pe o perioadă lungă de
timp. Ea rămâne neschimbată cât timp nodul este conectat la Internet.
Reţeaua de domiciliu (Home Network): O reţea, posibil virtuală, care se găseşte înscrisă în adresa
de domiciliu a nodului mobil. Mecanismele de rutare IP standard vor livra datagramele destinate adresei
de domiciliu a nodului mobil reţelei de domiciliu a nodului mobil.
Legătură (Link): o facilitate, un mediu prin care nodurile pot comunica. O legătură se găseşte sub
nivelul reţea.
Adresă la nivel legătură de date (Link-Layer Address): adresa utilizată pentru a identifica punctul
final al unei comunicaţii peste o legătură fizică. Tipic, o astfel de adresă este adresa MAC (Media
Access Control)
Agent de mobilitate (Mobility Agent): atât un agent de domiciliu, cât şi un agent extern.

6 
 
 Conexiunea mobilităţii (Mobility Binding): asocierea dintre o adresă de domiciliu şi o adresă care-
of realizată pe o anumită perioadă de timp.
Asociere mobilă securizată (Mobility Security Association): o colecţie de contexte de securitate
între o pereche de noduri care se aplică protocolului Mobile IP de schimb de mesaje. Fiecare context
indică un anumit mod şi algoritm de autentificare, o secretizare (cheie publică, cheie privată) şi un stil de
protecţie a răspunsului.
Nod (Node): o gazdă sau un ruter.
Tunel (Tunnel): o cale urmată de datagrame încapsulate. O datagramă încapsulată este transmisă
spre un agent cunoscut capabil să decapsuleze, care decapsulează datagramele şi le livrează corect
destinaţiei finale.
Reţea vizitată (Visited Network): altă reţea decât reţeaua de domiciliu, la care nodul mobil este
conectat curent.
Lista vizitatorilor (Visitor List): o listă a nodurilor mobile care vizitează un agent extern.

6.2.2. Funcţiile Mobile IP

Presupunem că dispozitivul mobil s-a deplasat într-o reţea străină. La prima pornire şi conectare la
reţea, nu se poate conecta. Nu ştie că se găseşte într-o altă reţea. Va trebui să găsească un agent extern în
acea reţea. Va trebui să ştie ce adresă poate utiliza în acea reţea. Va trebui să comunice cu agentul de
domiciliu să îl anunţe în ce reţea se găseşte pentru ca acesta să îi poată redirecţiona mesajele.
Pentru toate acestea, Mobile IP utilizează un set de funcţii. Pentru a vedea cum acţionează aceste
funcţii, vom evidenţia câţiva paşi din operarea generală a Mobile IP.
1. Agenţii de mobilitate (externi sau de domiciliu) anunţă prezenţa lor printr-un mesaj “Agent
Advertisement”. Un nod mobil poate. Opţional, solicita un mesaj de anunţ al agentului de la oricare
dintre agenţii de mobilitate ataşaţi reţelei în care se află prin transmiterea unui mesaj de solicitare
“Agent Solicitation”.
2. Nodul mobil primeşte anunţul agentului şi pe baza lui determină dacă se găseşte în reţeaua de
domiciliu sau în reţea străină.
3. Dacă nodul mobil decide că se găseşte în reţeaua de domiciliu, va opera fără servicii de
mobilitate. Dacă s-a reîntors în reţeaua de domiciliu în care este înregistrat ca fiind într-o reţea străină,
nodul mobil se va dezînregistra la agentul de domiciliu printr-un schimb de mesaje “Registration
Request” şi “Registration Reply”.
4. Când un nod mobil detectează că s-a mutat într-o reţea străină, va obţine de la agentul extern o
adresă care-of. Această adresă poate fi determinată din anunţurile agentului extern (adresa care-of a
agentului extern), sau printr-un mecanism extern ca DHCP, caz în care obţine o adresă colocated care-
of.
5. După obţinerea adresei care-of, nodul mobil se va înregistra la agentul de domiciliu cu această
nouă adresă printr-un schimb de mesaje “Registration Request” şi “Registration Reply”.
6. Datagramele trimise către adresa de domiciliu a nodului mobil vor fi interceptate de către
agentul de domiciliu, tunelate de către acesta către adresa care-of a nodului mobil, recepţionate în
punctul terminus al tunelului (care este fie agentul extern, fie nodul mobil însuşi) şi în final livrate
nodului mobil.
7. În sensul invers, datagramele transmise de către nodul mobil sunt în general livrate utilizând
mecanismele de rutare IP standard, nefiind necesar să treacă pe la agentul de domiciliu.

7 
 
 6.3. Adresarea Mobile IP

Un dispozitiv mobil va deţine două adrese:

- Adresa de domiciliu (home adress) : adresa “normală”, adresa IP asociată permanent nodului
mobil. Este adresa utilizată de dispozitiv în reţeaua sa de domiciliu şi totodată adresa către care vor fi
transmise datagramele destinate nodului mobil.
- Adresa care-of: o adresă secundară, temporară, utilizată de un nod mobil când se deplasează în
afara reţelei sale.
Tipurile adreselor care-of.
Există două tipuri, după cele două metode distincte de transmitere a datagramelor de către agentul
de domiciliu.
Foreign Agent Care-Of Address Este o adresă care–of furnizată de către agentul extern în
mesajele sale de anunţ Agent Advertisement. Este de fapt adresa agentului extern. Când este utilizat acest
tip de adresă, toate datagramele capturate de catre agentul de domiciliu sunt direcţionate către nodul
mobil prin intermediul agentului extern care este responsabil, în final, de livrarea acestora. Întrucât în
această situaţie nodul mobil nu are o adresă IP distinctă validă în reţeaua străină, livrarea se va face tipic
utilizând tehnologii de nivel 2 (legătură de date), respectiv adresa MAC.
Co-Located Care-Of Address Este o adresă care-of asociată direct nodului mobil. Ea poate fi
asociată fie manual în reţeaua străină, fie automat utilizând DHCP. În această situaţie adresa care-of este
utilizată pentru a transmite traficul de la agentul de domiciliu direct nodului mobil.

 
FigurA 6.3: Operarea Mobile IP cu o adresă Foreign Agent “Care-Of”

8 
 
 Diagrama este similară cu Figura 6.2, exceptând faptul că faptul că, în loc de o adresa co-located,
aici se utilizează o adresă foreign agent care-of. Aceasta înseamnă că adresa care-of actuală este cea a
agentului extern. Pasul #1 este acelaşi ca şi în cazul figurii 6.2, dar în pasul #2 agentul de domiciliu nu
va mai trimite direct nodului mobil, ci agentului extern. În pasul #3 agentul extern va desface pachetul
primit de la agentul de domiciliu şi va livra datagrama originală nodului mobil. Tipic, această acţiune se
realizează la nivel doi.

Avantajele şi dezavantajele tipurior de adrese care-of

Adresa foreign agent care-of este considerată ca fiind tipul utilizat în Mobile IP classic, în care
există atât agent de domiciliu, cât şi agent extern. Cu toate că pare mai puţin eficient decât co-located
care-of, oferă totuşi câteva avantaje imortante. Unul este acela că o adresă foreign agent care-of poate fi
utilizată de către mai multe noduri mobile care se află în vizită în acea reţea. Datagramele tuturor
nodurilor mobile vor fi transmise agentului extern care va asigura livrarea individuală către fiecare nod.
Întrucât nodurile mobile utilizează aceeaşi adresă, nu vor fi necesare adrese suplimentare, nu se va
depune un efort suplimentar pentru fiecare nod mobil.
Adresa co-located care-of are avantajul că traficul va fi dirijat direct de la agentul de domiciliu
către nodul mobil. În acest tip de aranjament este posibil ca un nod mobil să se deplaseze într-o reţea în
care agentul extern să lipsească. Acest fapt implică implementarea tuturor funcţiilor de comunicare
realizate în mod normal de către agentul extern la nivelul agentului de domiciliu.
În cazul adresei co-located se mai pune problema obţinerii adresei temporare. În majoritatea
reţelelor străine este posibilă obţinerea automată a unei adrese IP utilizând un protocol ca DHCP, dar,
dacă nu, trebuie totuşi asociată o adresă temporară. Oricum, o parte din spaţiul limitat de adrese IP al
reţelei vizitate trebuie rezervat pentru noduri mobile, fiecare dintre acestea utilizând o astfel de adresă pe
intervalul cât sunt prezente în reţea.
Adresa foreign agent care-of este preferată datorită naturii sale mult mai automate, datorită
prezenţei unui agent extern în reţea. Considerând că toate datagramele vor fi dirijate către un singur ruter
în reţeaua vizitată, se salvează o mulţime de adrese IP. Adresele co-located vor fi utilizate atunci când
nu există agent extern, sau, chiar în prezenţa agentului extern, când conexiunea se realizează pe termen
lung.

6.4. Procesul de descoperire a agentului Mobile IP

Când un nod mobil este pornit pentru prima dată, nu poate presupune, ca un dispozitiv normal IP,
că se găseşte în propria reţea. Mai întâi trebuie să determine poziţia sa şi, dacă decide că nu este în
reţeaua de domiciliu, trebuie să iniţieze un proces de transmitere de datagrame către reţeaua sa. Acest
proces este însoţit de comunicarea cu un ruter local cu rol de agent, întregul proces fiind numit
descoperirea agentului (“agent discovery”).
Descoperirea agentului este o metodă prin care un nod mobil determină dacă este conectat la
propria reţea, sau la o reţea străină şi totodată poate determina dacă este deplasat dintr-o reţea în alta.
Dacă este conectat la o reţea străină, metodele specifice ale procesului vor permite nodului mobil să
determine adresa care-of pusă la dispoziţie de către agentul extern al reţelei respective.
Principalele scopuri ale procesului sunt:

9 
 
 - Comunicarea agent-nod (Agent/Node Communication): primul pas îl constituie stabilirea
contactului cu un agent al reţelei la care este conectat nodul mobil. Sunt transmise mesaje din partea
agentului către nod conţinând informaţii importante despre agent; este posibil să existe şi un mesaj de la
nod către agent, mesaj prin care nodul solicită informaţii.
- Orientarea (Orientation): Nodul utilizează procesul de descoperire a agentului pentru a
determina unde se găseşte. El va determina dacă se găseşte în propria reţea sau într-o reţea străină prin
identificarea agentului care îi transmite mesaje.
- Asocierea cu o adresă care-of (Care-Of Address Assignment): Această metodă îi spune nodului
ce adresă care-of poate utiliza, în cazul în care este utilizată adresarea “foreign agent care-of”.

Agenţii IP mobili sunt rutere cărora li s-au adăugat programe suplimentare pentru a fi capabili să
asigure funcţii de Mobile IP. În principiu, comunicaţia dintre nodul mobil şi agentul din reţeaua la care
este conectat este similară cu cea dintre un dispozitiv din reţea şi ruterul său local, excepţie fiind
informaţia suplimentară necesar a fi transmisă în situaţia în care ruterul are rol de agent.

6.4.1. Mesajele Agent Advertisement şi Agent Solicitation

Internet Control Message Protocol (protocol prin care dispozitivele pot fi anunţate dacă a apărut
o disfuncţionalitate în reţea sau prin care dispozitivele testează posibilitatea de a atinge o anumită
destinaţie).
Preocuparea în ceea ce priveşte schimbul de mesaje între un ruter şi un nod există sub forma
mesajelor ICMP care sunt utilizate în procesul de descoperire a ruterelor. În acest scop sunt folosite
două mesaje: Router Advertisement prin care ruterele anunţă nodurilor existenţa lor şi capabilităţile lor
şi Router Solicitation prin care un nod cere unui ruter să-i transmită capabilităţile sale.
Plecând de la similaritatea acestui proces cu cel de descoperire a agentului, s-a decis o modificare
a procesului existent în locul creerii unui nou proces. Mesajele utilizate în procesul de descoperire a
agentului vor fi:

o Agent Advertisement: Mesaj transmis regulat de către un ruter care funcţionează ca agent
Mobile IP. El constă dintr-un mesaj obişnuit Router Advertisement care are una sau mai multe extensii
pentru a conţine informaţii Mobile IP specifice pentru nodurile mobile.

o Agent Solicitation: Acest mesaj poate fi transmis de către un dispozitiv IP mobil pentru a solicita
unui agent transmiterea unui mesaj Agent Advertisement.

Agenţii sunt configuraţi astfel încât să transmită mesajele Agent Advertisement cu o rată
rezonabilă pentru a asigura un contact rapid fără o încărcare excesivă a lărgimii de bandă. Ei trebuie să
răspundă imediat oricărui mesaj Agent Solicitation recepţionat cu un mesaj Agent Advertisement. Este
posibil ca unii agenţi să fie configuraţi astfel încât să transmită mesajul Agent Advertisement numai în
urma recepţionării unei solicitări.
Nodurile mobile trebuie să fie capabile să recepţioneze şi să prelucreze mesajele Agent
Advertisement. Ele vor face diferenţa dintre un astfel de mesaj şi un mesaj Router Advertisement prin
evaluarea lungimii mesajului. Ele vor analiza apoi extensia mesajului pentru a lua la cunoştinţă
capabilităţile agentului local. Ele determină astfel dacă se află în propria reţea sau într-o reţea străină, iar
în cazul unui agent străin, cum poate fi folosit acesta. De asemenea, nodurile mobile trebuie să fie

10 
 
capabile să determine, pe baza mesajului Agent Advertisement dacă s-au deplasat din reţeaua anterioară
şi, de asemenea, când s-au reîntors în propria reţea. Nodurile mobile trebuie să fie capabile să transmită
un mesaj de solicitare dacă nu au primit nici un anunţ într-un interval de timp prestabilit.

6.4.1.1. Formatul mesajului de solicitatre a agentului Agent Solicitation

Vom începe cu acest format întrucât mesajul Agent Solicitation este mult mai simplu. De fapt, nu
este definit nici un format nou pentru acest mesaj! El este identic cu formatul mesajului Router
Solicitation. Motivul pentru care nu este necesar un tip nou de mesaj este acela că este necesar un mesaj
extrem de simplu: “Hei, dacă este vreun ruter pe aici, te rog spune-mi cine eşti şi de ce eşti capabil!” Nu
este necesară nici o informaţie suplimentară Mobile IP. Atunci când un ruter obişnuit recepţionează un
mesaj Router Solicitation el va transmite un Router Advertisement; în cazul unui ruter Mobile IP va
transmite automat un mesaj mai lung, de tip Agent Advertisement fără o solicitare suplimentară, chiar
dacă solicitarea vine de la un nod Mobile IP sau de la un dispozitiv obişnuit.

6.4.1.2. Formatul mesajului Agent Advertisement

Agent Advertisement începe cu câmpurile normale ale unui mesaj ICMP Router Advertisement.
Destinaţia mesajului este fie o adresă multicast “toate dispozitivele” (224.0.0.1) dacă este furnizat
serviciul multicast, fie o adresă broadcast (255.255.255.255). Câmpurile de adresă ale ruterului vor fi
completate cu adresele agentului.

6.4.1.3. Extensia Mobility Agent Advertisement

Este principala extensie utilizată pentru a transmite capabilităţile Mobile IP ale agentului către
nodurile mobile din reţeaua locală.

Structura Mobility Agent Advertisement Extension este descrisă în tabelul 6.1 şi ilustrată grafic în
figura 6.4.

Tabel 6.1: Formatul Mobile IP Mobility Agent Advertisement Extension

Nume Mărime
Descriere
câmp (bytes)
Tipul Extensiei: Identifică tipul extensiei Agent Advertisement. Pentru Mobility
Type 1
Agent Advertisement Extension, este setat la 16.
Lungime: Lungimea extensiei in octeţi, excluzând câmpurile Tip şi Lungime.
Length 1
Astfel, este egal cu 6 plus 4 pentru fiecare adresă care-of din mesaj.
Sequence Număr secvenţă: Un contor secvenţial setat la zero când ruterul se iniţializează
2
Number şi apoi este incrementat la fiecare avertisment transmis.
Registration 2 Timpul de viaţă al înregistrării: Intervalul maxim de timp, în secunde, în care

11 
 
Lifetime agentul este dispus să primească cereri de înregistrare. O valoare 65,535 (toţi
biţii 1) reprezintă “infinit”. Acest câmp are semnificaţie numai pentru
înregistrare şi nu are nicio legătură cu câmpul Lifetime obişnuit al unui mesaj
Router Advertisement obişnuit.

Flags 1

Reserved 1 Rezervat: Transmis ca zero şi ignorat de destinatar.

Care-Of Addresses: Zero sau mai multe adrese furnizate de un agent extern
Variabil
Care-Of pentru un nod mobil şi utilizate ca adrese foreign agent care-of. Un agent extern
(4 per
Addresses trebuie să furnizeze cel puţin o adresă în anunţul său; un ruter care nu
adresă)
acţionează ca agent extern va omite acest câmp.

12 
 
 Figura 6.4: Mobile IP Mobility Agent Advertisement Extension Format

Această extensie este poziţionată după câmpurile normale ale unui mesaj Router Advertisement

ICMPv4 Router Advertisement Message Format

Tabel 6.2: Formatul mesajului Router Advertisement ICMPv4

Nume Mărime
Descriere
câmp (bytes)
Tipul : Identifică tipul mesajului ICMP. Pentru un mesaj Router
Type 1
Advertisement valoarea este 9.
Cod: Normal este setat la 0. Atunci când un agent Mobile IP transmite
un Router Advertisement cu o extensie Agent Advertisement, el va fi
Code 1
setat la valoarea 16 numai dacă este un agent mobil şi nu are intenţia de
a prelucra trafic normal.
Checksum 2 Sumă de verificare: Un câmp de 16 biţi pentru antetul (header-ul) ICMP
Num Numărul adreselor: Numărul adreselor asociate cu acest ruter care sunt
1
Addrs incluse în acest anunţ.

13 
 
 Address Entry Size: Numărul de cuvinte de 32 de biţi care revin pentru
Addr Entry fiecare adresă. Deoarece pentru acest format de mesaj fiecare adresă de
1
Size ruter are o adresă de 32 de biţi şi un nivel de preferinţă de 32 de biţi,
această valoare este fixată la 2.
Timp de viaţă: Numărul de secunde cât un host va considera acest nesaj
Lifetime 2
valid.

Router 8*Valoarea
Address câmpului
Entries Num Addrs

Figura 6.5: ICMPv4 Router Advertisement Message Format

14 
 
 6.4.1.4. Extensia Prefix-Lengths

Este o extensie opţională care spune nodului mobil care este lungimea prefixului adresei ruterului
conţinută în câmpul Router Address al mesajului Agent Advertisement. Lungimea prefixului este un alt
termen prin care se specifică numărul de biţi din adresa IP care reprezintă identitatea reţelei. Astfel se
specifică identitatea reţelei pentru fiecare dintre adresele ruterului.

Formatul Prefix-Lengths Extension este descris în Tabelul 6.3 şi în Figura 6.6.

Tabel 6.3: Formatul Prefix-Lengths Extension Mobile IP

Nume Mărime
Descriere
câmp (bytes)
Tipul extensiei: Identifică tipul extensiei Agent Advertisement. Pentru
Type 1
Prefix-Lengths Extension, este setat la 19.
Lungime: Lungimea extensiei în octeţi, excluzând câmpurile Tzpe şi
Length 1 Length. Astfel, rezultă un număr egal cu numărul de lungimi de prefixe
(deoarece fiecare ocupă un octet).
Prefix Variable (1 Prefix Lengths: Câte un număr de lungime a prefixului pentru fiecare
Lengths per length) adresă de ruter din zona Router Advertisement a Agent Advertisement.

Figura 6.6: Mobile IP Prefix-Lengths Extension Format

Această extensie este poziţionată după câmpurile normale ale unui mesaj Router Advertisement
din Figura 6.5.

6.4.1.5. Extensia de completare “One-Byte Padding”

Unele implementări cer ca mesajele ICMP să conţină un număr par de octeţi, astfel că este
posibil să fie necesar un octet de umplutură. Acest octet va avea toţi biţii zero.

15 
 
 6.5. Procesul de înregistrare
Odată ce un nod mobil a încheiat procesul de descoperire a agentului, el ştie dacă se află în reţeaua
de domiciliu sau într-o reţea străină. Dacă se găseşte în propria reţea, va comunica ca orice dispozitiv IP
obişnuit. Dacă se află într-o reţea străină, va trebui să adopte un comportament Mobile IP. Acesta
presupune comunicaţia cu agentul de domiciliu astfel încât să poată fi schimbate între ei informaţii şi
instrucţiuni. Acest proces este numit înregistrarea la agentul de domiciliu “home agent registration” sau,
mai simplu, înregistrare. Scopul principal al înregistrării îl constituie lansarea activităţii Mobile IP.
Nodul mobil trebuie să contacteze agentul de domiciliu, să îl anunţe că se găseşte într-o reţea străină şi
să solicite pornirea procedurii de expediere a datagramelor. Pentru aceasta va lăsa agentului de domiciliu
adresa sa care-of, astfel încât agentul de domiciliu să ştie unde trebuie să transmită datagramele. Agentul
de domiciliu trebuie, la rândul său, să comunice nodului mobil o serie de informaţii atunci când se
realizează înregistrarea. În tot acest proces, agentul extern nu este implicat, cel mult având rolul de a
retransmite mesajele.

6.5.1. Evenimentele înregistrării nodului mobil

Înregistrarea cu succes stabileşte ceea ce se numeşte legătura mobilă “mobility binding” între
agentul de domiciliu şi nodul mobil. Pentru toată durata înregistrării adresa IP de domiciliu a nodului
mobil este asociată cu adresa curentă care-of şi agentul de domiciliu va încapsula şi va expedia
datagramele adresate adresei de domiciliu către adresa care-of. Se presupune că nodul mobil îşi
administrează înregistrarea şi manevrează diferitele evenimente utilizând câteva acţiuni:

- Înregistrarea (Registration): Nodul mobil iniţiază o înregistrare atunci când detectează pentru
prima oară că a fost deplasat din reţeaua de domiciliu într-o reţea străină.
- Dezînregistrarea (Deregistration): Atunci când nodul mobil se întoarce în reţeaua de domiciliu,
el trebuie să anunţe agentul de domiciliu să înceteze expedierea datagramelor către adresa care-of.
- Reînregistrarea (Reregistration): Dacă un nod mobil se mută dintr-o reţea străină într-o altă
reţea străină, sau dacă adresa sa care-of se modifică, el trebuie să-şi actualizeze înregistrarea la agentul
de domiciliu. Trebuie să execute această acţiune şi în situaţia în care îi expiră înregistrarea, chiar dacă
rămâne staţionar în aceeaşi reţea străină.

Fiecare înregistrare este stabilită pentru un interval de timp bine stabilit, de aceea este necesară
reînregistrarea chiar dacă dispozitivul se deplasează sau nu. Înregistrările au o durată limitată pentru a se
evita expirarea lor. De exemplu, dacă un nod uită să se dezînregistreze atunci când se întoarce acasă,
expedierea datagramelor către adresa care-of va înceta la expirarea înregistrării.

6.5.2. Mesajele de Cerere a Înregistrări (Registration Request) şi Răspuns la

Înregistrare (Registration Reply)

Pentru a realiza înregistrarea au fost definite două mesaje noi în Mobile IP: Cerere a Înregistrării
(Registration Request) şi Răspuns la Înregistrare (Registration Reply). Acestea nu sunt mesaje ICMP ca

16 
 
alte mesaje folosite în procesul de descoperire a agentului; ele sunt mesaje UDP (User Datagram
Protocol). De aceea, tehnic vorbind, înregistrarea este realizată la un nivel mai înalt decât restul
comunicațiilor Mobile IP. Agenții primesc Cererea de Înregistrare (Registration Requests) pe portul
UDP #434, şi răspund nodurilor mobile utilizând unul din porturile de transmitere de mesaje.

6.5.2.1. Procedurile de înregistrare

Există două proceduri diferite pentru înregistrare, funcție de tipul adreselor care-of utilizate de
către nodul mobil şi alte specificații pe care le vom trata pe scurt. Prima metodă este înregistrarea
directă, care presupune numai doi paşi:

1. Nodul mobil transmite agentului de domiciliu Cererea de Înregistrare (Registration

Request)
2. Agentul de domiciliu returnează nodului mobil Răspunsul la Înregistrare (Registration
Replay)

În unele cazuri este cerut un proces puțin mai complex, în care agentul extern este implicat în
schimbul de mesaje dintre agentul de domiciliu şi nodul mobil. În această situație sunt necesari patru
paşi:

1. Nodul mobil trimite agentului extern Cererea de Inregistrare (Registration Request)

2. Agentul extern procesează cererea şi o expediază agentului de domiciliu

3. Agentul de domiciliu transmite Răspunsul la Înregistrare (Registration Reply) agentului

extern

4. Agentul extern procesează răspunsul şi îl transmite nodului mobil.

Prima metodă, mai simplă, este utilizată atunci când nodul mobil utilizează o adresă co-located
care-of. În această situație poate comunica uşor cu agentul de domiciliu şi este capabil să recepționeze
direct datagramele de la agentul de domiciliu. Acolo unde nu este prezent un agent extern, este evident
că aceasta este metoda care trebuie utilizată. Tot această metodă este utilizată şi în situația
dezînregistrării la agentul de domiciliu în urma revenirii în rețeaua de domiciliu.

A doua metodă este utilizată atunci când nodul mobil utilizează o adresa care-of. Reamintim că
aceasta este situația în care nodul mobil nu are propria adresă IP; el utilizează o adresă comună cu cea a
agentului extern, ceea ce împiedică comunicarea directă între nodul mobil şi agentul său de domiciliu.
De asemenea, atunci când nodul mobil recepționează un mesaj Agent Advertisement cu flag-ul “R” flag
setat,el trebuie să ia legătura cu agentul extern chiar dacă deține o adresă co-located care-of. Ca o
observație, agentul străin nu este altceva decât un mijlocitor, schimbul de mesaje având loc între agentul
de domiciliu şi nodul mobil. Totuşi, agentul extern poate invalida înregistrarea dacă cererea violează
regulule stabilite în rețeaua străină. Acesta este motivul pentru care unii agenți externi cer să fie
implicați în înregistrare chiar dacă nodul mobil deține o adresă co-located care-of. Se înțelege că în
situația în care agentul extern nu poate contacta agentul de domiciliu înregistrarea nu poate fi realizată.

17 
 
 6.5.2.2. Formatul mesajului Registration Request

Mesajele Registration Request au formatul arătat în Tabelul 6.4 şi Figura 6.7.

Figura 6.7: Formatul mesajului Mobile IP Registration Request

Acest mesaj este transportat în zona payload a mesajului UDP,contribuția acestuia nefiind
ilustrată.

18 
 
 Tabel 6.4: Formatul mesajului Mobile IP Registration Request
Mărime
Nume câmp Descriere
(bytes)
Tip: Identifică tipul mesajului de înregistrare. Pentru o cerere, acest câmp
Type 1
este 1.

Flags 1

Timp de viață: Durata, în secunde, pe care nodul mobil o cere agentului de

Lifetime 2
domiciliu pentru această înregistrare
Adresa de domiciliu: Adresa IP pe care o are nodul mobil atunci când se
Home
4 găseşte în rețeaua proprie. Prin această adresă dispozitivul este identificat
Address
indiferent de modul în care ajunge cererea la agentul de domiciliu.
Agentul de domiciliu: Adresa IP a dispozitivului care acționează ca agent de
Home Agent 4
domiciliu.

19 
 
Care-Of
4 Adresa Care-Of: Adresa IP utilizată de nodul mobil ca adresă care-of.
Address
Identificator: Un număr format din 64 de biți care identifică în mod unic
Cererea de Înregistrare(Registration Request) şi care este utilizat pentru a
Identification 8
marca cererile în vederea răspunsurilor. Are şi rol de protecție împotriva
atacurilor.
Extensii: Câmpurile extensie sunt incluse în această zona pentru a autentifica
Extensions Variabil
cererea.

6.5.2.3. Formatul mesajului Registration Replay

Formatul mesajului Registration Reply este cel din Tabelul 6.5 şi Figura 6.8

Tabel 6.5: Formatul mesajului Mobile IP Registration Reply

Mărime
Nume câmp Descriere
(bytes)
Tip: Identifică tipul mesajului de înregistrare. Pentru un răspuns, acest
Type 1
câmp este 3.
Cod: Indică rezultatul înregistrării. Acest câmp este setat în 0 dacă
ânregistrarea a fost acceptată, în 1 dacă a fost acceptată, dar au fost cerute
servicii care nu pot fi oferite. Dacă înregistrarea a fost respinsă, diferitele
Code 1
coduri care apar vor indica motivul acestei respingeri. Se poate identifica
dacă respingerea a fost decisă de către agentul de domiciliu sau de către
agentul extern.
Timpul de viață: Dacă înregistrarea a fost acceptată, acesta indică
Lifetime 2 intevalul de timp cât această inregistrare este validă. Poate fi o valoare
diferită funcție de cererile nodului mobil.
Adresa de domiciliu: Adresa IP pe care nodul mobil o deține în rețeaua
Home proprie. Ea identifică în mod unic dispozitivul, astfel încât mesajele pot fi
4
Address livrate acestuia chiar dacă acelaşi agent extern serveşte mai multe noduri
mobile.
Agentul de domiciliu: Adresa IP a dispozitivului care acționează ca agent
Home Agent 4
de domiciliu.
Identificator: Un număr de 64 de biți care identifică în mod unic
Identification 8 Registration Reply şi este acelaşi cu identificatorul cererii al cărei răspuns
este.

20 
 
 Extensii: Câmpurile extensie sunt incluse cu scopul autentificării
Extensions Variabil
răspunsului. Pot fi incluse şi alte eztensii.

Figura 6.8. Formatul mesajului Mobile IP Registration Replay

6.6. Încapsularea datelor şi tunelarea Mobile IP

În momentul în care nodul mobil aflat într-o rețea străină a încheiat cu success procesul de
înregistrare la agentul de domiciliu, procesul Mobile IP de transmitere a datagramelor este activat.
Agentul de domiciliu va intercepta datagramele destinate nodului mobil care sosesc în rețeaua de

21 
 
domiciliu şi le expediază acestuia. Acest lucru se realizează prin încapsularea datelor şi transmiterea lor
către nodul mobil pe adresa care-of.

6.6.1. Tehnici Mobile IP de încapsulare a datelor

Această încapsulare este necesară deoarece fiecare datagramă interceptată trebuie retransmisă prin
rețea către adresa care-of. În teorie acest lucru ar fi foarte simplu: agentul de domiciliu schimbă adresa
de destinație a datagramei şi o retransmite. În practică această acțiune implică diferite complicații care o
fac neviabilă. De aceea retransmiterea se va face preluând datagrama şi introducând-o între un nou set
de antete înainte de a fi expediată. În analogia de început cu o scrisoare, aceasta implică introducerea
scrisorii primite într-un nou plic, trecerea pe acesta a noii adrese a destinatarului si retransmiterea noului
plic (varianta ar fi fost ştergerea de pe plicul primit a adresei şi scrierea noii adrese).
Procesul implicit de încapsulare utilizat în Mobile Ip este numit Încapsulare IP în IP (IP
Encapsulation Within IP) şi este abreviat în mod obişnuit ca: IP-in-IP. Este o metodă simplă, prin care o
datagramă IP devine payload-ul unei alte datagrame IP. În Mobile IP antetele noi specificăcum se va
transmite datagrama încapsulată către adresa care-of a nodului mobil.
În plus față de IP in IP, pot fi opțional utilizate şi alte două metode de încapsulare: Încapsulare
minimă în IP (Minimal Encapsulation Within IP) şi Încapsulare rutată generic (Generic Routing
Encapsulation (GRE)). Pentru a utilize oricare dintre acestea două, nodul mobil trebuie să apeleze o
metodă potrivită în cererea sa de înregistrare, iar agentul de domiciliu trebuie să fie de accord cu aceasta.
Dacă este folosit un agent extern şi acesta trebuie să fie capabil să suporte metoda dorită.

6.6.2. Tunelul Mobile IP de livrare a datelor

Procesul de încapsulare creează o construcție logică numită tunel între dispozitivul care
încapsulează şi un altul care decapsulează. Tunelul reprezintă o conductă prin care datagramele sunt
expediate peste o rețea arbitrară, cu detaliile datagramei încapsulate temporar ascunse.
În Mobile IP punctual de pornire al tunelului este agentul de domiciliu, care încapsulează
datagramele. Sfârşitul tunelului depinde de tipul de adresă care-of utilizată:

o Adresă Foreign Agent Care-Of: În acest caz finalul tunelului este agentul extern. El
recepționează mesajele încapsulate de către agentul de domiciliu, elimină antetele suplimentare şi
livrează datagrama nodului mobil. Această acțiune are loc de obicei la nivel doi, deoarece nodul mobil
şi agentul extern sunt poziționați în aceeaşi rețea locală şi, de asemenea, nodul mobil nu dispune de
propria adresă IP în acea rețea (el o utilizează pe cea a agentului extern).

o Adresă Co-Located Care-Of: În această situație nodul mobil este capătul tunelului şi elimină
antetele suplimentare.

6.6.2.1. Tunelarea convențională Mobile IP

În mod normal, tunelul descris anterior este utilizat numai pentru datagramele transmise către
nodul mobil şi capturate de către agentul de domiciliu. Atunci când un nod mobil doreşte să transmită o
datagramă nu există un tunel invers către agentul de domiciliu, acesta nefiind efficient. Datagrama va fi
transmisă direct utilizând orice ruter găsit în rețeaua curentă, care poate fi sau nu un agent extern. Când
face acest lucru, el utilizează propria adresă IP (de domiciliu) ca adresă sursă pentru orice cerere

22 
 
lansează. Ca urmare, orice răspuns la aceste cereri va fi transmis către rețeaua de domiciliu. Se creează
astfel un triunghi de astfel de tranzacții:

1. Nodul mobil transmite o cerere din rețeaua străină către o a treia parte (dispozitiv) aflată
undeva în Internet.
2. Acest dispozitiv răspunde nodului mobil. Întrucât a primit ca adresă sursă a cererii adresa
de domiciliu a nodului mobil, răspunsul la cerere va fi transmis pe această adresă în rețeaua de domiciliu
a nodului mobil.
3. Agentul de domiciliu interceptează răspunsul în rețeaua de domiciliu şi îl transmite prin
tunel către nodul mobil.

Acest process este ilustrat în Figura 6.9. Acelaşi triunghi se formează şi în cazul în care partea a
treia (situată undeva în Internet) lansează o cerere către nodul mobil. Cererea va fi recepționată şi apoi
expediată de către agentul de domiciliu. Dacă nodul mobil doreşte să răspundă, va trimite acest răspuns
direct dispozitivului din Internet.

Figura 6.9: Tunelarea şi Încapsularea Mobile IP

Acest exemplu ilustrează cum un schimb tipic de mesaje cerere/răspuns în Mobile IP creează un

23 
 
triunghi de comunicație. În pasul #1 nodul mobil transmite o cerere către un server distant aflat undeva
în Internet. Nodul mobil utilizează adresa de domiciliu ca sursă a acestei cereri, astfel că, în pasul #2
răspunsul ajunge la agentul de domiciliu. În pasul #3 agentul de domiciliu transmite prin tunelare
răspunsul nodului mobil.

6.6.2.2. Tunelarea inversă Mobile IP

Pot exista situații în care nu este nici fezabil, nici de dorit ca nodul mobil să transmită direct
datagramele prin intermediul unui ruter găsit în rețeaua străină. În acest caz poate fi dezvoltată o
facilitate opțională numită tunelare inversă (reverse tunneling). Este posibil de realizat numai dacă este
suportată atât de către nodul mobil, agentul de domiciliu cât şi de agentul extern dacă acesta este
implicat.
Când facilitatea este utilizată, se crează un tunel invers, complementar celui normal, între nodul
mobil şi agentul de domiciliu, sau între agentul extern şi agentul de domiciliu, funcție de tipul adresei
care-of. Toate transmisiile provenite de la nodul mobil sunt tunelate către rețeaua de domiciliu unde
agentul de domiciliu le transmite peste Internet rezultând o operație mai simetrică decât în cazul
triunghiului. Este mai puțin eficientă deoarece fiecare comunicație necesită patru paşi. De aceea, această
metodă este utilizată numai dacă este necesar.
O situație în care ar fi necesar un tunel invers este aceea în care rețeaua străină în care se află
nodul mobil are implementate măsuri de securitate care împiedică nodul să transmită datagrame
utilizând adresa sa de domiciliu. În particular, rețeaua poate fi setată să nu permită ieşirea datagramelor
care în adresa sursă nu au prefixul adresei rețelei respective. Acțiunea are ca scop prevenirea “glumelor”
(adrese IP nepersonalizate).

6.7. Modul de operare al Protocolului de Rezoluție a Adresei (Address

Resolution Protocol (ARP)) în Mobile IP

Mobile IP este un protocol care permite implementarea unei funcții foarte dificile şi anume
permite în mod transparent deplasarea unui dispozitiv într-o rețea străină. Din păcate, de câte ori un
protocol încearcă să modifice modul de funcționare al IP avem ceea ce se numeşte “un caz special”.
Fiind vorba despre un agent de domiciliu care interceptează datagrame şi le expediază apoi prin tunel
către nodul mobil, acesta lucrează în general fără problem, dar există situații în care sunt necesare
acțiuni suplimentare. Una dintre acestea este utilizarea ARP, care, fără câteva precauții nu va funcționa
corect.

6.7.1. Probleme apărute la nivelul ARP în Mobile IP

Pentru a înțelege problema care apare în utilizarea ARP, considerăm un nod mobil care se află
într-o rețea străină şi care s-a înregistrat cu succes la agentul de domicilui. Agentul de domiciliu va
intercepta datagramele sosite în rețeaua de domiciliu destinate nodului mobil, le va încapsula şi expedia.
Pentru a realiza aceasta, agentul de domiciliu trebuie să analizeze datagrama, acțiune care are loc în mod
normal numai pentru datagramele care sosesc din exteriorul rețelei şi care sunt procesate la nivelul
ruterului.

24 
 
 Ce se întâmplă în situația în care datagrama este transmisă de un nod din rețeaua de domiciliu şi
este destinată nodului mobil aflat într-o altă rețea? Trebuie avut în vedere că acrst nod nu este necesar un
nod mobil şi este posibil să nu dețină capabilităşi Mobile IP. El va urma procedura standard: compară
identitatea rețelei nodului mobil cu identitatea propriei rețele, constată că este vorba despre aceeaşi
rețea, deci poate face expedierea direct, nefiind necesară o rutare. Pentru aceasta va utiliza ARP în
vederea identificării adresei MAC a nodului mobil pentru a-i trimite datagrama. Va începe prin a se uita
în propriul cache ARP şi dacă găseşte aici adresa de nivel doi o va utiliza pentru expedierea pe nivel doi.
Nodul mobil nu se află în rețeaua de domiciliu, în consecință nu va recepționa acest mesaj. Dacă nodul
mobil nu se află în tabelul ARP propriu nodului inițiator de mesaj, acesta va transmite în rețeaua de
domiciliu o cerere ARP Request către nodul mobil pentru a-i determina adresa de nivel doi. Din nou,
nodul mobil fiind plecat din rețea, cererea va rămâne fără răspuns.

6.7.2. Facilități suplimentare introduse la nivelul Agentului de Domiciliu pentru

a lucra cu ARP

Rezolvarea problemelor enumerate anterior presupune intervenția la nivelul agentului de

domiciliu. Acesta va trebui să realizeze două sarcini pentru ca hosturile locale să poată transmite către
nodul mobil:

o ARP Proxying (ARP Delegat): Agentul de domiciliu trebuie să asculte orice ARP Request
transmis de nodurile din aceeaşi rețea cu orice nod mobil care este înregistrat la el. Atunci când aude
una, va răspunde în locul nodului mobil specificând propria adresă MAC ca fiind asociată adresei IP a
nodului mobil. Ca urmare, toate hosturile din rețeaua de domiciliu vor transmite datagramele destinate
nodului mobil către agentul de domiciliu care le va expedia. Procesul este ilustrat în Figura 6.10.

25 
 
 Figura 6.10: Agent de domiciliu cu rol de ARP Proxying

Agentul de domiciliu trebuie să efectueze câțiva paşi speciali pentru a permite

comunicarea între dispozitive din rețeaua de domiciliu şi nodul mobil. În acest exemplu, în care ,
pentru simplitate, sunt utilizate adrese MAC simplificate, adresa MAC a nodului mobil este #48
şi cea a agentului de domiciliu #63. Un client local având adresa MAC #97 transmite o cerere
ARP Request pentru a găsi adresa MAC a nodului mobil. Agentul de domiciliu răspunde în locul
nodului mobil, specificând nu adresa acestuia #48, ci adresa proprie #63. Clientul va transmite
agentului de domiciliu, care apoi va expedia datagrama către nodul mobil aflat într-o rețea
străină.
o “Gratuitous” ARP (ARP Voluntar): Delegarea ajută în situația cereriloe ARP Request, dar ce
se întâmplă cu dispozitivele care au în cache-ul lor etichetă cu nodul mobil? Imediat ce nodul mobil
părăseşte rețeaua de domiciliu, eticheta devine expirată. Pentru a o corecta, agentul de domiciliu va
transmite din proprie inițiativă un mesaj gratuitous ARP care va spune tuturor dispozitivelor din rețeaua
locală să asocieze adresa IP a nodului mobil cu adresa legătură de date a agentului de domiciliu. Acest
mesaj poate fi transmis de mai multe ori pentru a se asigura că toate dispozitivele au luat la cunoştință
de această schimbare.
Odată introduse aceste funcții, ARP va funcționa corect în rețeaua de domiciliu. După ce nodul
mobil se reîntoarce în propria rețea, procesul trebuie inversat. După dezînregistrarea la agentul de
domiciliu, acesta nu va mai funcționa ca delegat pentru nodul mobil. Atât nodul mobil, cât şi agentul de
domiciliu vor transmite broadcast mesaje ARP pentru ca dispozitivele din rețea să-şi actualizeze cache-

26 
 
urile, asociind din nou adresa IP a nodului mobil cu adresa sa MAC şi nu cu cea a agentului de
domiciliu.

6.8. Eficiența Mobile IP

Un agent de domiciliu care transmite toate datagramele destinate nodului mobil oriunde s-ar afla
acesta este o suluție convenabilă pentru mobilitate, dar nu şi eficientă. Deoarece fiecare datagramă este
transmisă mai întâi către agentul de domiciliu şi apoi expediată nodului mobil, datagramele vor parcurge
o porțiune din rețea de două ori. Gradul de ineficiență al acestei retransmisii poate fi semnificativ şi
poate conduce la probleme în cazul unor aplicații.
Ca exemplu, vom considera un nod mobil M şi un dispozitiv obişnuit care vrea să transmită către
acesta, A. Gradul de ineficiență a Mobile IP este funcție de distanța în interrețea dintre A şi rețeaua de
domiciliu a lui M comparată cu distanța dintre dispozitivul A şi rețeaua curentă a lui M. Considerăm
cazul în care nodul mobil M se află într-o rețea străină foarte departe de cea de domiciliu, iar
dispozitivul care doreşte să-i transmită o datagramă utilizează adresa IP de domiciliu a lui M.
Presupunem că rețeaua de domiciliu este în Londra, iar nodul mobil s-a deplasat la Tokyo. Situațiile
următoare sunt enumerate în ordinea crescătoare a ineficienței Mobile IP în comparație cu situația în
care nodul mobil ar avea o adresă temporară în rețeaua străină şi nu ar folosi Mobile IP.

o Dispozitivul emițător se află în rețeaua de domiciliu: În această situație dispozitivul A va

transmite o datagramă care va fi imediat interceptată de către agentul de domiciliu în rețeaua de
domiciliu şi va fi expediată nodului mobil. Aici nu este nici o ineficiență (cu excepția implicațiilor
încapsulării) deoarece chiar dacă A ar transmite direct către nodul mobil folosind o adresă externă,
datagrama ar fi probabil rutată prin agentul de domiciliu care este un ruter.

o Dispozitivul emițător se află într-o rețea apropiată de rețeaua de domiciliu: Să presupunem

că dispozitivul A se află la Paris. Datagrama va parcurge drumul Paris-Londra-Tokyo. Comparativ cu
distanța pâna la Tokyo, nici aici eficiența nu este scăzută.

o Dispozitivul emițător se află într-o rețea apropiată de rețeaua străină: Presupunem că

dispozitivul A se află în Taipei, Taiwan. În această situație Mobile IP devine foarte ineficient.
Datagrama va parcurge drumul Taipei- Londra şi înapoi până la Tokyo.

o Dispozitivul emițător se află rețeaua străină: Cea mai mare ineficiență se întâlneşte în această
situație, în care dispozitivul emițător se găseşte în aceeaşi rețea (străină) cu nodul mobil. Dispozitivul A
localizat în Tokyo trebuie să transmită datagrama la Londra de unde este expediată înapoi la Tokyo.
Fără Mobile IP, utilizarea ARP ar permite livrarea imediată, fără nici o rutare. Acest ultim scenariu, cel
mai defavorabil, este ilustrat in Figura 6.11.

27 
 
 Figura 6.11: Ineficiența Mobile IP În situația cea mai defavorabilă

Diagrama ilustrează cel mai prost caz posibil de ineficiență a Mobile IP: situația în care un
dispozitiv din rețeaua străină în care este localizat nodul mobil doreşte să îi transmită o
datagramă. Sursa, în cazul de față 210.4.79.11, utilizează adresa de domiciliu a nodului mobil,
astfel transmisia fiind dirijată înapoi spre Londra şi apoi returnată în Tokyo, chiar dacă cele două
dispozitive se găsesc pe acelaşi birou.

Din păcate acest ultim scenariu apare destul de des. Sunt frecvente situațiile în care dispozitivul
mobil conectat la o rețea străină comunică în special cu hosturi din acea rețea.

Implicațiile tunelării inverse

Pentru a vedea că se poate şi mai rău, putem considera cazul utilizării tunelării inverse. În această
situație avem un tunel nu numai pentru datagramele transmise către nodul mobil, ci şi de la acesta. În
cazul cel mai defavorabil o pereche de mesaje cerere/răspuns transmisă între un nod mobil şi un alt
dispozitiv aflate ambele în rețeaua străină, necesită două drumuri complete Londra – Tokyo, dus-întors.

Ineficiența este parte inerentă a Mobile IP. Nu există nicio soluție în interiorul Mobile IP, fiind o
consecință a modului de operare a protocolului. Singura modalitate de a îmbunătăți lucrurile este aceea
de a încropi o soluție care în ultimă instanță se reduce la una din cele două opțiuni pe care le avem

28 
 
atunci când nu se utilizează suportul mobilității: fie decidem să acordăm dispozitivului mobil aflat într-o
rețea străină o adresă IP temporară în acea rețea, fie utilizăm o rutare specifică pentru acest dispozitiv
cât timp se află în rețeaua străină. Aici intrăm într-o buclă: am văzut că şi aceste soluții ridică probleme,
acesta fiind motivul principal pentru care a fost creat Mobile IP. Pot exista însă situații în care eficiența
este mult mai importantă decât portabilitatea transparentă oferită de Mobile IP. Pentru o staționare
îndelungată într-o rețea străină depărtată de rețeaua de domiciliu, sau pentru aplicațiile în care eficiența
este esențială, poate avea sens angajarea uneia din aceste tehnici. De exemplu, o corporație care are un
număr mic de oficii în diferite oraşe, conectate prin intermediul Internetului, poate seta o rutare specială
care să permită unui dispozitiv mobil aflat în vizită la un oficiu din alt oraş decât cel de domiciliu să
comunice direct cu nodurile locale ale rețelei străine fără să mai fie rutat prin Internet.

6.9. Considerații privind securitatea Mobile

Securitatea este o preocupare continuă în orice mediu de rețea, fiind esențial în Mobile IP. Există
un număr de motive pentru a justifica această afirmație şi le vom prezenta împreună cu modul în care
este utilizat protocolul şi mecanismele specifice prin care este implementată securitatea.

Securitatea a fost avută în vedere în permanență în timpul dezvoltării Mobile IP ținând seama de
faptul că cel mai adesea dispozitivele mobile utilizează o tehnologie de rețea fără fir (wireless).
Comunicațiile wireless sunt inerent mai puțin sigure decât comunicațiile prin fir , deoarece transmisiile
de realizează într-un mediu deschis putând fi interceptate. Este de asemenea mult mai uşor pentru
utilizatorii răutăcioşi să perturbeze funcționarea dispozitivelor wireless decât în situația în care
conexiunea s-ar face prin fir.

Din punct de vedere al operării, Mobile IP prezintă un număr de riscuri datorate utilizării unui
sistem de înregistrare şi transmiterii datagramelor peste o rețea nesecurizată. Un dispozitiv malițios
poate interveni în procesul de înregistrare provocând deturnarea datagramelor destinate dispozitivului
mobil. Un intrus poate interveni şi în procesul de expediere a datelor prin încapsularea unei datagrame
false pentru a înşela dispozitivul mobil făcându-l să creadă că a fost transmisă o datagramă care nu va fi
transmisă.

6.9.1. Măsuri de securitate Mobile IP

Din aceste motive, standardul Mobile IP include un număr limitat de măsuri explicite de protecție
împotriva riscurilor de securitate. O măsură de securitate considerată suficient de importantă a fost
realizată direct în standardul Mobile IP: autentificarea mesajelor Registration Request şi Registration
Replay. Procesul de autentificare este realizat într-o manieră oarecum similară modului de operare a
antetului de autentificare din IPSec. Scopul său este de a preveni interceptarea traficului de către
dispozitive neautorizate prin înşelarea unui agent care să realizeze în mod eronat fie o înregistrare, fie o
dezînregistrare.
Toate dispozitivele mobile trebuie să accepte autentificarea. Nodurile trebuie să o utilizeze pentru
cereri, iar agenții pentru răspunsuri. Cheile de securitate trebuie asociate manual acolo unde nu există un
sistem automat de distribuire a cheilor de securitate. Metoda implicită de autentificare este HMAC-MD5,
fiind unul dintre algoritmii utilizați în IPSec.

29 
 
 Protecția împotriva atacurilor de tip Replay

În acest tip de atac, o a treia parte interceptează o datagramă, o reține o anumită perioadă şi apoi o
retransmite. Ar părea destul de inofensiv dacă nu este important factorul timp. Putem considera situația
în care un nod mobil se înregistrează la agentul de domiciliu, mai târziu se reîntoarce acasă şi se
dezînregistrează. Dacă un dispozitiv malițios capturează o copie a unei cereri de înregistrare
(Registration Request) şi o retransmite, agentul de domiciliu va decide că nodul mobil s-a deplasat din
nou şi va intercepta datagramele destinate nodului mobil.
Pentru a preveni un astfel de atac, în mesajele Registration Request şi Registration Reply este
utilizat câmpul Identificare (Identification). Fiecare cerere are un număr diferit de identificare, astfel
încât nodurile şi agenții pot deosebi mesajele originale de copii şi pot elimina orice datagramă
recepționată care repetă un număr de identificare deja întâlnit.

Limitările autentificării Mobile IP

Mobile IP include măsuri de autentificare numai pentru mesajele de înregistrare. El nu se preocupă

de autentificarea datagramelor încapsulate expediate de către agentul de domiciliu nodului mobil. Nu
este prevăzută nici criptarea şi nici o altă metodă de păstrare a intimității mesajelor de control sau
datagramelor expediate. Soluția evidentă pentru situațiile care necesită asigurarea securității este
utilizarea protocoalelor IPSec Authentication Header (AH) şi/sau Encapsulating Security Payload
(ESP).

30 
 
 Capitolul 6
Protocolul Internet versiunea 6 – IPv6
Creşterea explozivă a Internetului a făcut ca IETF (Internet Engineering Task
Force) să ia în vedere, înca din anii ’90 o nouă versiune a Protocolului Internet care
să permită un număr ”nelimitat” de adrese chiar dacă s-ar face o alocare ineficientă
a spaţiului de adrese, să să micşoreze sau cel puţin să limiteze dimensiunea
tablelelor de rutare, să simplifice protocolul pentru a permite o procesare mai
rapidă a datagramelor, să acorde o importanţă mărită tipului serviciului, să permită
o mobilitate a hosturilor fără a impune o schimbare a adresei IP şi, nu în ultimul
rând să permită o coexistenţă cu vechiul protocol IPv4.
Pornind de la aceste obiective, IPv6 oferă următoarele facilităţi semnificative:
- un spaţiu de adrese imens, care se prevede a fi suficient, în condiţiile
existente de dezvoltare a Internetului, pentru cel puţin 30 de ani;
- adresare ierarhică şi unicitate globală a adresei bazată pe prefix şi nu pe
clase de adrese;
- un mecanism de autoconfigurare a interfeţelor de reţea;
- posibilitatea încapsulării proprii, precum şi a altor protocoale;
- clase de servicii care să facă distincţie între tipuri de date;
- dezvoltarea suportului de rutare multicast (preferat broadcastului);
- prezenţa unui mecanism de criptare şi autentificare;
- metode de tranziţie care să permită migrarea de la IPv4 la IPv6;
- metode de compatibilizare care să permită coexistenţa şi comunicarea cu
IPv4.
În IPv6, formal, sunt preferaţi termenii pachet în detrimentul datagramă şi
nod care semnifică orice sistem care rulează IPv6, fie că este host sau ruter.
Pentru îndeplinirea acestor deziderate, IETF a propus o serie de tehnici de
tranziţie până la implementarea noului protocol, a cărui adoptare s-a lovit, încă de
la început de inerţia şi împotrivirea proprietarilor de reţele care investiseră deja în
echipamente IPv4 şi nu au dorit o nouă investiţie masivă în noi echipamente.
Ca elemente de tranziţie, cele mai importante sunt stiva duală şi tunelarea.

Stiva duală “Dual stack”

Această tehnică permite unui sistem să poată funcţiona atât cu protocolul
IPv4, cât şi cu protocolul IPv6. Ca urmare, hostul va fi capabil să comunice cu
hosturi capabile IPv4 prin IPv4, iar cu hosturi capabile IPv6 prin IPv6.
2 ARHITECTURI DE REŢELE ŞI INTERNET

Figura 6.1: Funcţionarea sistemelor în perioada de tranziţie

Tunelarea “Tunneling”
Tunelarea este procedeul prin care, în momentul în care un pachet IPv6
ajunge, pe calea spre destinaţie, la o reţea care nu poate utiliza acest protocol, este
încapsulat într-un pachet IPv4, tranzitează reţeaua IPv4, iar la ieşirea din aceasta
este decapsulat şi îşi urmează drumul în forma originară. Dacă în urma încapsulării
se depăşeşte dimensiunea maximă acceptată de reţeaua accesată, nodul care ia
decizia încapsulării va trebui să realizeze şi fragmentarea noii datagrame.

Figura 6.2: Tunelarea unei datagrame IPv6

Protocolul Internet versiunea 6 – IPv6 3

Formatul pachetelor IPv6

Antetul pachetului de date a fost simplificat faţă de IPv4. Ca structură s-a
redus numărul de câmpuri, dar dimensiunea antetului a crescut de la 20 de octeţi la
40 de octeţi. Reducerea informaţiilor de control şi a opţiunilor din antetul
pachetului a avut ca scop reducerea timpului de procesare a unui pachet la nivelul
nodurilor. Aceste câmpuri prezente în antetul IPv4, dar utilizate rar, au fost mutate
în extensii opţionale de antete, care vor fi prezente numai atunci când este necesar.

Versiune Clasa de trafic Etichetă flux

Lungime încărcătură utilă Antet următor Limită de salturi

Adresa sursă

Adresa  destinaţie

32 biţi

Figura 6.3: Antetul pachetului IPv6

Semnificaţia câmpurilor din antetul pachetului IPv6 (Figura 6.3) este:

- Versiune: câmp de 4 biţi reprezentând numărul versiunii Protocolului
Internet, în acest caz 6.
- Clasa de tarfic: o valoare pe 8 biţi. Primii 6 biţi mai semnificativi
(Differentiated Services Code Point - DSCP) conţin un cod pentru a marca
cerinţa de comportament pentru un pachet aparţinând unei anumite clase
de serviciu, iar ultimii doi (Explicit Congestion Notification – ECN)
permit nodului să seteze indicaţii de congestie.
- Etichetă de flux: o serie de pachete provenite de la aceeaşi sursă, către o
aceeaşi destinaţie, având aceleaşi cerinţe de servire vor constitui un flux şi
vor primi o aceeaşi etichetă.
- Lungime încărcătură utilă: lungimea pachetului în octeţi (excluzând
antetul). Dacă lungimea este mai mare de 64 kocteţi, acest câmp va fi setat
în 0 şi se va adăuga un antet opţional (Jumbo Payload) care să ofere
lungimea reală.
- Antet următor: indică tipul antetului care urmează imediat după antetul de
bază. Poate indica atât un antet opţional IP cât şi un protocol de nivel
4 ARHITECTURI DE REŢELE ŞI INTERNET

superior. Mai este utilizat şi pentru a indica prezenţa unor extensii de antet
care ajută la furnizarea de informaţii suplimentare. Câteva valori posibile
şi semnificaţiile lor:
o 0 Antet cu opţiuni salt-cu-salt *
o 41 Antet
o 43 Antet de rutare IPv6 *
o 44 Antet de fragment IPv6 *
o 45 Protocol de Rutare Interdomenii
o 46 Protocol de Rezervare a Resurselor
o 50 Antet Încapsulare de securitate a încărcăturii utile *
o 51 Antet de autentificare IPv6 *
o 58 Pachet ICMPv6
o 59 Nu există antet următor *
o 60 Antet cu opţiuni destinaţie *
Valorile notate cu * corespund unor extensii de antete.
- Limită de salturi: este similar timpului de viaţă (TTL) al IPv4, dar acum se
măsoară în salturi, nu în secunde.
- Adresa sursă: un câmp de 128 biţi specificând adresa IPv6 a sursei.
- Adresa destinaţie: un câmp de 128 biţi specificând adresa IPv6 a
destinatiei.

Extensia antetelor

Orice pachet IPv6 porneşte cu antetul de bază care, de cele mai multe ori, este
singurul necesar pentru a face o livrare corectă a pachetului la destinaţie. Dacă sunt
necesare şi opţiuni suplimentare, se vor utiliza extensii de antete. Fiecare dintre
aceste extensii va avea primul octet ca identificator al tipului următorului antet.
Există anumite reguli după care se ataşează extensiile de antete:
- Lungimea unui antet variază, funcţie de tipul său, dar întotdeauna va fi
multiplu de 8 octeţi.
- Un tip de antet va fi prezent o singură dată în structura unui pachet.
- Extensiile se plasează într-o ordine specificată, fapt important pentru o
procesare eficientă. Ordinea în care apar este următoarea: IPv6 header,
Hop-by-Hop Options, Routing, Fragment, Authentication, Encapsulating
Security Payload, Destination Options, Upper layer. Nodurile
intermediare sunt interesate numai de informaţiile prezente în opţiunile
salt-cu-salt şi antetul de rutare. Odată obţinute aceste informaţii, nodurile
expediază mai departe pachetele. Pentru o prelucrare facilă, aceste extensii
urmează antetului de bază.
- Atunci când câmpul antet următor conţine o valoare care nu corespunde
unei extensii de antet se consideră terminate antetele IPv6 şi urmează
datele protocolului de nivel superior.
Există următoarele tipuri de extensii de antete:
Protocolul Internet versiunea 6 – IPv6 5

- salt-cu-salt: conţine informaţii care trebuie examinate de fiecare nod de pe

calea spre destinaţie.
- rutare: permite sursei să anunţe că preferă o anumită cale spre destinaţie,
sub forma unei liste de noduri preferate.
- fragment: controlează fragmentarea unui pachet pentru a îndeplini
cerinţele de dimensiune maximă a unităţilor de date
- autentificare: utilizat pentru a asigura faptul că pachetul recepţionat nu a
fost alterat pe traseu;
- încapsulare de securitate a încărcăturii utile: pentru o comunicaţie sigură,
datele sunt criptate;
- opţiuni destinaţie: fiind adresat numai nodului destinaţie, acest antet se va
afla întotdeauna înaintea antetului de nivel superior.

Adresarea IPv6
IPv6 utilizează adrese cu lungimea de 128 biţi, ceea ce duce la un număr
imens de adrese disponibile (o valoare al cărei sens poate fi înţeles este 50.000 de
adrese pe metrul pătrat din suprafaţa Pământului).
Sintaxa adresei IPv6 consideră cei 128 biţi (16 octeţi) ca fiind 8 numere
întregi fără semn, fiecare număr fiind scris cu 4 cifre hexazecimale; fiecare dintre
numere este separat de celelalte prin utilizarea a două puncte (:).
O adresă IPv6 poate fi:

FDE2:23ED:100E:11AC:1274:1A00:BC01:1234

A astfel de adresă este greu de manevrat. De aceea s-au gândit moduri de

simplificare a reprezentării adreselor. În mod normal, o adresă va arăta de forma

FEC0:0000:0000:0000:0011:0000:0C12:3456

adică mai multe câmpuri cu valoarea 0 (este normal ca la alocarea de adrese să se

înceapă de la valori mici). Pentru o astfel de adresă se poate ajunge la o
reprezentare compactată dacă pentru 0000 vom scrie 0, pentru 0001 vom scrie 1,
pentru 0011 vom scrie 11 şi pentru 0C12 vom scrie C12. Se va ajunge astfel la:

FFC0:0:0:0:11:0:C12:3456

O simplificare suplimentară este reprezentată de simbolul ::, care va înlocui o

serie de zerouri. Cu această nouă simplificare, adresa devine:

FFC0::11:0:C12:3456

O simplificare relevantă este scrierea adresei

6 ARHITECTURI DE REŢELE ŞI INTERNET

0000:0000:0000:0000:0000:0000:00AB:0001 care devine ::AB:1

O adresă IPv6 va avea două zone: un prefix şi un identificator de interfaţă,

ambele de câte 64 biţi. Prefixul este similar cu prefixul adreselor IPv4 utilizate în
Rutarea Inter-Domanii Fără Clase (Classless Inter-Domain Routing CIDR). Pe
baza lui se poate găsi, într-o structură arborescentă, oriunde pe glob, orice interfaţă
de nod.
În acest moment sunt stabilite următoarele prefixe (Tabelul 6.1):
Tabelul 6.1
Prefixe IPv6 alocate

Parte din
Prefix Adresa de Lungimea
Alocare spaţiul de
(în binar) început măştii (biţi)
adrese
Rezervat 0000 0000 0::/8 8 1/256
Rezervat NSAP 0000 001 200::/7 7 1/128
Rezervat IPX 0000 010 400::/7 7 1/128
Adrese unicast globale 001 2000::/3 3 1/8
Adrese unicast link-local 1111 1110 10 FE80::/10 10 1/1024
Adrese unicast site-local 1111 1110 11 FEC0::/10 10 1/1024
Multicast 1111 1111 FF00::/8 8 1/256
Alocare totală 15%

Identificatorul de interfaţă se construieşte pe baza adresei MAC a interfeţei.

Aceasta este formată din 48 biţi (6 octeţi). Între cei 48 biţi ai adresei MAC, după al
treilea octet, se intercalează o valoare fixă FFFE, după care urmează ultimii trei
octeţi ai adresei MAC. Construcţia identificatorului este încheiată prin setarea celui
de al doilea bit al octetului cel mai semnificativ (U/L - universal/local) din 0 în 1.

8 biţi 8 biţi 8 biţi 8 biţi 8 biţi 8 biţi

D1 A9 D5 35 C7 D0
1 11010001 10101001 11010101 110101 11000111 11010000

2 11010001 10101001 11010101 110101 11000111 11010000

3 11010001 10101001 11010101 11111111 11111110 110101 11000111 11010000
4 11010011 10101001 11010101 11111111 11111110 110101 11000111 11010000
5 D3 A9 D5 FF FE 35 C7 D0
6 D 3A9:D 5FF:FE 35:C 7D 0

Figura 6.4: Formarea identificatorului de interfaţă din adresa MAC

În Figura 6.4 sunt prezentate etapele realizării identificatorului de interfaţă:

Protocolul Internet versiunea 6 – IPv6 7

1. Adresa MAC de 48 biţi

2. Adresa MAC despicată în două grupe de câte trei octeţi
3. Adăugarea şablonului de 16 biţi FFFE între cele două grupe
4. Schimbarea bitului al doilea din primul octet
5. Identificatorul interfeţei exprimat în hexazecimal
6. Identificatorul interfeţei în format IPv6

Modelul de adresare IPv6

În principiu, trebuie reţinut că o adresă se atribuie unei interfeţe, nu unui nod.

Un nod poate fi identificat prin oricare dintre adresele unicast ale oricărei
interfeţe. O adresă unicast identifică în mod unic o interfaţă, dar o interfaţă poate
avea una sau mai multe adrese de acelaşi tip sau de tipuri diferite (unicast,
multicast, anycast). Există două excepţii:
- o adresă IPv6 poate fi atribuită unui grup de interfeţe ale aceluiaşi nod
dacă acel grup este tratat ca o singură interfaţă; este cazul în care se
doreşte o reţea mai robustă, mai multe căi de a ajunge la destinaţie (prin
mai multe interfeţe);
- nodurile pot avea interfeţe fără adrese; este cazul legăturilor punct-la-
punct care pot funcţiona şi fără o adresă specificată.
În concepţia IPv6 o subreţea, este asociată cu o legătură; mai multe subreţele
pot fi asociate cu o legătură, dar o subreţea nu poate fi asociată cu mai multe
legături.

Adrese unicast

Adresele unicast sunt adrese care identifică o singură interfaţă. Pachetele

având ca destinaţie acea adresă vor fi livrate acelei interfeţe. Sun definite câteva
adrese unicast având o destinaţie specială:
- adresa loopback (::1) – este atribuită unei intefeţe virtuale prin care se pot
trimite pachete numai spre nodul însuşi; este utilă pentru verificarea
funcţionării transmisiei şi recepţiei de pachete prin simularea unei
comunicaţii; este similară cu adresa IPv4 127.0.0.1;
- adresa nespecificată (::) – această adresă este utilizată de noduri când
rulează procesul de autoconfigurare; este echivalentă cu adresa
nespecificată IPv4 0.0.0.0;
- adresă compatibilă IPv4 (::<adresă IPv4>) – este utilizată în procesul de
tunelare de către pachete IPv6 a unor reţele IPv4. adresa compatibilă se
formează prin plasarea a 96 de zerouri în faţa adresei IPv4;
- adrese mapate IPv4 (::FFFF: <adresă IPv4>) – sunt utilizate în
comunicaţii între un nod capabil IPv6 şi unul capabil IPv4;
- adresă link-local – poate fi utilizată numai în reţeaua fizică la care este
conectată interfaţa;
8 ARHITECTURI DE REŢELE ŞI INTERNET

- adresă site-local – adrese care nu pot fi rutare în Internet, similare cu

adresele private din IPv4 (10.0.0.0, 172.16.0.0-172.31.0.0, 192.168.0.0-
192.168.255.0).

Adrese unicast globale agregabile

Adrese unicast globale agregabile reprezintă un identificator unic al unei

interfeţe, o adresă cu domeniul de aplicare nelimitat. Un pachet care are ca adresă
destinaţie o astfel de adresă este transmis către interfaţa care este identificată în
mod unic. Pentru toate adresele unicast globale, cu excepţia celor care au ca prefix
000, identificatorul de reţea trebuie să fie format din 64 biţi. Adresele unicast
globale care încep cu “000” sunt adresele IPv4 mapate în IPv6.
Adresele unicast globale au prefixul “001”(2000::/3). Câmpul identificator
reţea ID are 16 biţi şi este utilizat de organizaţii pentru a crea propria ierarhie
locală de adrese şi pentru a identifica subreţelele.

Formatul unei adrese globale este cel din Figura 6.5:

48 16 64
Prefix pentru rutare globală Reţea ID Identificator interfaţă

Figura 6.5: Formatul unei adrese unicast globale

Prefixul pentru rutare globală are o structură bine determinată, permiţând

realizarea de structuri ierarhice (arborescente) pe mai multe niveluri. Formatul
detaliat al adresei unicast este prezentat în Figura 6.6.

3 13 32 16 64
001 TLA ID NLA ID SLS ID Identificator Interfaţă

Figura 6.6: Forma detaliată a adresei unicast globale

Se observă următoarea compoziţie a adresei unicast globale:

- 3 biţi prefixul de adresă unicast globală,
- 13 biţi reprezentând Identificatorul de Agregare de Nivel de Vârf (Top-
Level Aggregation IDentifier -TLA ID), câmp alocat unei organizaţii care
oferă o reţea de tranzit publică,
- 32 biţi reprezentând Identificatorul de Agregare de Nivel Următor (Next-
Level Aggregation IDentifier - NLA ID), câmp utilizat de organizaţii care
au primit un TLA ID pentru a-şi crea propriile ierarhii de adresare,
- 16 biţi reprezentând Identificatorul de Agregare de Nivel Site Site-Level
Aggregation IDentifier - SLA ID), câmp folosit de administratorii de
siteuri pentru a crea propria ierarhie în interiorul siteului.
Protocolul Internet versiunea 6 – IPv6 9

Adrese link local

Acest tip de adrese, având prefixul 1111 1110 10, sunt destinate utilizării
pe o legătură pentru funcţii de autoconfigurare a adresei şi descoperirea vecinilor.
Presupunând că este cazul unei reţele de mici dimensiuni, realizată din câteva
sisteme şi fără niciun ruter, pentru o bună funcţionare sunt suficiente adrese de tip
link local. Formatul unei astfel de adrese este prezentat în Figura 6.7.

10 biţi 54 biţi 64 biţi

1111 1110 10 000....................000 Identificator Interfaţă

Figura 6.7: Formatul adresei Link-Local

În figura 6.7 s-au pus în evidenţă prefixul acestui tip de date şi faptul că toţi
ceilalţi biţi până la identificatorul de interfaţă sunt poziţionaţi în zero.
Ca exemplu, un sistem care are o interfaţă cu adresa MAC
00:FC:02:CD:12:34,
va avea ca identificator de interfaţă
00FC:02FF:FECD:1234
rezultând adresa link local
FE80:0000:0000:0000: 00FC:02FF:FECD:1234
care scrisă sub formă condensată ia forma:
FE80:: FC:2FF:FECD:1234

Adrese site local

Acest tip de adrese sunt menite să înlocuiască adresele private din IPv4
utilizate în reţele interne. Acestea pot fi deci utilizate în reţele care nu sunt
conectate la Internet, nefiind necesară înregistrarea lor la niciun for, având un
format care oferă o modalitate facilă de substituire a lor cu adrese unicast globale
în situaţia în care se doreşte conectarea la Internet.
Formatul acestui tip de adrese este prezentat în Figura 6.8.
După cum se observă, dimensiunea câmpului de subreţea este de 16 biţi, ceea
ce face ca numărul posibil de subreţele care pot fi create de către o organizaţie
neconectată la Internet în cadrul reţelei proprii este de peste 64.000.
Ca şi în situaţia adreselor private din IPv4, un ruter al reţelei interne conectat
la Internet nu va permite ieşirea de pachete având ca adresă sursă o adresă de tip
site local. Va fi permisă numai retransmiterea pachetelor între subreţele ale reţelei
interne.
10 ARHITECTURI DE REŢELE ŞI INTERNET

10 biţi 38 biţi 16 biţi 64 biţi

1111 1110 11 000.............000 Identificator reţea Identificator Interfaţă

Figura 6.8: Formatul adresei Site-Local

Ca exemplu, un sistem care are o interfaţă cu adresa MAC

00:FC:02:CD:12:34,
va avea ca identificator de interfaţă
00FC:02FF:FECD:1234
rezultând adresa site local
FEC0:0000:0000:0000: 00FC:02FF:FECD:1234
care scrisă sub formă condensată ia forma:
FEC0:: FC:2FF:FECD:1234

Adresa nespecificată

Adresa 0000:0000:0000:0000:0000:0000:0000:0000 scrisă în forma

condensată ::, nu va fi niciodată atribuită unei interfeţe deoarece indică tocmai lipsa
unei adrese IPv6. Ea va fi utilizată în faza de configurare a unui nod, când acesta,
prin emiterea unui pachet având trecută în câmpul sursă adresa ::, caută să îşi
descopere propria adresă IPv6. De asemenea, această adresă nu poate fi utilizată
niciodată ca adresă de destinaţie.

Adrese multicast

O adresă multicast reprezintă un identificator pentru un grup de interfeţe ale

mai multor noduri. Un pachet care va avea ca adresă de destinaţie o adresă
multicast va fi livrat tuturor interfeţelor care au acea adresă. Transmisia multicast
înlocuieşte transmisia broadcast pentru care, în IPv6, nu mai există adrese stabilite.
Folosirea comunicaţiei multicast sporeşte eficienţa reţelei economisind lăţimea de
bandă, fiind transmis un singur pachet pentru întreg grupul, în loc de câte un pachet
pentru fiecare membru al grupului (situaţie în cazul unei comunicaţii unicast).
Formatul unei adrese multicast este prezentat în Figura 6.9:

8 4 4 112
Prefix Flaguri Scop Identificator Grup

Figura 6.9: Formatul adresei multicast

Adresa multicast are următoarea structură:

- Prefix: 1111 1111
- Flaguri: Format din 4 biţi, dintre care numai cel mai puţin semnificativ
este utilizat, ceilalţi fiind poziţionaţi în zero. Vor rezulta două valori:
Protocolul Internet versiunea 6 – IPv6 11

o 0000 având semnificaţie de adresă permanentă atribuită de o

autoritate
o 0001 reprezentând o adresă temporară. Ea poate fi stabilită de o
aplicaţie atunci când este nevoie. Când aplicaţia se încheie, adresa
va fi eliberată şi va putea fi reutilizată.
- Scop: 4 biţi care indică scopul multicastului. Valori posibile:
o 0 – rezervat
o 1 – limitată la interfeţe pe nodul local
o 2 – limitată la noduri pe legătura locală
o 5 – limitată la siteul local
o 8 – limitate la organizaţia respectivă
o E – scop global
o F – rezervat
o toate celelalte valori posibile sunt neatribuite
- Identificator Grup: identifică grupul multicast, permanent sau temporar
având un scop comun. Asta înseamnă că pot exista simultan în reţea mai
multe grupuri cu acelaşi identificator de grup, dar cu scopuri diferite.
Ca exemplu de adrese multicast cu acelaşi identificator de grup, dar cu scopuri
diferite, considerăm grupul 43 care este alocat permanent grupului de servere de
timp care furnizează informaţii de timp sincronizate pentru nodurile din reţea
(servere NTP – Network Time Protocol). Se pot obţine următoarele adrese
multicast cu semnificaţiile respective:
FF01::43 toate serverele NTP de pe acelaşi nod cu sursa
FF02::43 toate serverele NTP de pe aceeaşi legătură cu sursa
FF03::43 toate serverele NTP de pe acelaşi site cu sursa
FF04::43 toate serverele NTP prezente în reţea.
La momentul actual există mai multe adrese multicast predefinite, dintre care
putem menţiona:
FF01::1 Toate interfeţele nodului local
FF02::1 Toate nodurile de pe legătura locală
FF01::2 Toate ruterele nodului local
FF02::2 Toate ruterele legăturii locale
FF05::2 Toate ruterele siteului local
FF02::9 Toate ruterele RIP de pe legătura locală
FF02::A Toate ruterele EIGRP de pe legătura locală
FF02::B Toţi agenţii mobili de pe legătura locală
FF02::1:2 Toţi agenţii DHCP de pe legătura locală
FF05::1:3 Toate serverele DHCP din siteul local

Adresa anycast

Adresarea anycast reprezintă un concept între adresarea unicast şi cea

multicast. Adresa anycast este un identificator pentru un set de interfeţe care
aparţin unor noduri diferite. Un pachet care are ca destinaţie o adresă anycast este
12 ARHITECTURI DE REŢELE ŞI INTERNET

trimis la cea mai apropiată interfaţă (distanţa fiind interpretată de către protocolul
de rutare funcţie de metrica utilizată).
O adresă anycast se găseşte în acelaşi spaţiu de adrese cu al adreselor unicast.
Cele două tipuri de adrese nu pot fi deosebite, având acelaşi format. De aceea,
trebuie avute în vedere câteva restricţii atunci când facem o configurare anycast:
- când se atribuie o adresă anycast unei interfeţe, adresa trebuie configurată
explicit ca o adresă anycast;
- o adresă anycast nu poate fi atribuită unui host, ci numai unui ruter.
- o adresă anycast nu poate fi adresa sursa într-un pachet.
Scopul adresei de tip anycast este de a asigura flexibilitate acolo unde e
necesar un anume serviciu ce poate fi asigurat de mai multe servere, fără a avea
importanţă care din ele va răspunde cererii.

Protocolul de Mesaje de Control Internet versiunea

6 (ICMPv6)
Ca şi în cazul IPv4, pentru ca Protocolul Internet să îşi realizeze sarcinile cu
succes, sunt funcţii care trebuie asigurate de către ICMP. ICMPv6 a preluat
funcţiile lui ICMPv4 (interogări, raportări de erori, descoperiri de rute, diagnoze),
dar, în plus, a preluat şi sarcini privind informaţiile de grup multicast asigurate în
versiunea 4 de către Protocolul de Management de Grup Internet (Internet Group
Management Protocol - IGMP) şi rezoluţia adresei furnizată anterior de către
Protocolul de Rezoluţie a Adresei (Address Resolution Protocol – ARP).
Mesajele ICMPv6 sunt trensportate în pachete IPv6 în care pot fi prezente şi
extensii de antete. Mesajul ICMPv6 va fi identificat prin valoarea 58 în câmpul
Antet Următor din antetul IPv6 sau din antetul precedent.
Dintre tipurile de mesaje nou apărute oferind informaţii despre grupuri
multicast şi rezoluţia adresei:
130 Interogare de apartenenţă la grup multicast
131 Raportare apartenenţă la grup multicast
132 Declinare de apartenenţă la grup multicast
135 Solicitare vecin - prin care se cere adresa MAC
136 Anunţ vecin – prin care se obţine adresa MAC solicitată
Arhitecturi de Reţea şi Internet 1

CAP. 3 NIVELUL TRANSPORT

Protocoalele de transport furnizează proceselor de aplicaţii servicii de transfer date cap

la cap. Sunt definite două protocoale la acest nivel: TCP (Transmission Control Protocol) şi
UDP (User Datagram Protocol).

3.1 PORTURI ŞI SOCKET-URI

În cadrul acestui paragraf se introduc noţiunile de port şi socket, necesare pentru
identificarea procesului local, care rulează într-un anumit sistem, precum şi pentru
identificarea procesului corespondent, din sistemul distant, care comunică cu primul prin
intermediul unui anumit protocol. Toate aceste elemente implicate în comunicaţie, sistemele
local şi distant, procesele care lucrează local şi distant, precum şi protocolul de comunicaţie
trebuie identificate prin intermediul acestor mecanisme, după cum urmează:
- Unui proces de aplicaţie i se asociază un număr de identificare (ID proces), care este
de preferat să fie diferit pentru fiecare iniţializare a procesului;
- ID-urile de proces diferă pentru sisteme de operare diferite. Prin urmare, aceşti
identificare nu este uniformă;
- Un proces server poate avea conexiuni multiple cu mai mulţi clienţi în acelaşi timp.
Prin urmare, identificatorii de conexiune nu sunt unici.

Conceptul utilizării de porturi şi socket-uri oferă posibilitatea identificării în mod

uniform şi unic a conexiunilor, programelor şi sistemelor implicate în comunicaţie,
independent de identificatorii proceselor respective.

3.1.1 Porturi
Fiecare proces care necesită comunicarea cu un alt proces se identifică în cadrul unei
stive TCP/IP printr-un port sau mai multe. Un ID port este un număr reprezentat pe 16 biţi
utilizat de către un protocol capăt la capăt pentru a identifica cărui protocol de nivel superior
sau program (proces) de aplicaţie trebuie să-i livreze mesajele recepţionate. Există două tipuri
de porturi:
- Porturi consacrate: aceste porturi aparţin unor servere standard, cum ar fi serverul
Telnet care foloseşte portul 23. Numerele asociate porturilor consacrate aparţin
intervalului de la 1 la 1023. De obicei, numerele porturilor consacrate sunt impare,
deoarece în sistemele iniţiale, când s-au introdus aceste porturi, se impunea utilizarea
unei perechi număr impar-număr par pentru porturile implicate în transferuri
bidirecţionale. Cele mai multe servere necesită numai un singur port. Excepţie fac
serverul BOOTP, care foloseşte două porturi (67 şi 68) şi serverul FTP, care foloseşte
două porturi (20 şi 21). Porturile consacrate sunt controlate şi alocate de către
Autoritatea de Asociere a Numerelor în Internet, IANA (Internet Assigned Number
Authority) şi în cele mai multe sisteme nu pot fi alocate decât proceselor sistem sau
programelor executate de utilizatorii cu drepturi speciale. Porturile consacrate permit
clienţilor să găsească serverele fără a necesita informaţii de configurare suplimentare.

- Porturi temporare: unii clienţi nu necesită numere de porturi consacrate deoarece

aceştia iniţiază comunicaţiile cu serverele, iar numărul portului utilizat de fiecare
2 3. Nivelul Transport

dintre clienţi este conţinut în mesajul UDP/TCP transmis către server. Fiecărui proces
client i se asociază un număr de port, de către sistemul pe care acesta rulează, pentru
un interval de timp nedefinit, cât necesită procesul client să transfere datele. Numerele
porturilor temporare au valori mai mari decât 1023, uzual fiind în intervalul de la 1024
la 65535. Porturile temporare nu sunt controlate de IANA şi pot fi utilizate în oricare
sistem, de către orice program dezvoltat de către utilizator. Confuziile posibile care
pot apare atunci când două aplicaţii diferite încearcă să utilizeze aceleaşi numere de
porturi, într-un acelaşi sistem, se pot evita prin configurarea acelor aplicaţii să solicite
un port disponibil în stiva locală TCP/IP. Deoarece numărul de port este alocat
dinamic, acesta poate fi diferit de la o cerere la alta a aplicaţiei. Protocoalele de nivel
transport UDP, TCP şi ISO TP-4 utilizează acelaşi principiu de identificare a
porturilor. Aproximativ aceleaşi numere de porturi sunt utilizate pentru identificarea
aplicaţiilor care oferă aceleaşi servicii în stivele cu UDP, TCP şi ISO TP-4.

Observaţie: În mod uzual, un server foloseşte fie TCP, fie UDP, dar există şi excepţii. Spre
exemplu, aplicaţia sistem de nume pentru domenii, DNS (Domain Name System) utilizează
atât portul 53 al UDP, cât şi portul 53 al TCP.

3.1.2 Socket-uri
Interfaţa de tip socket reprezintă una dintre interfeţele de programare a aplicaţiei, API
(Application Programming Interfaces) cu protocoalele de comunicaţie. Destinate pentru a
reprezenta interfeţele de programare pentru comunicaţii, socketurile API au fost introduse
pentru prima data în versiunea Unix BSD 4.2 (Berkeley Software Distribution). Deşi nu sunt
standardizate socketurile API BSD au devenit un standard implicit pentru implementarea
socketurilor reţelelor TCP/IP.
Se definesc următorii termeni:
- Un socket reprezintă un tip special de identificator de fişier, care este utilizat de un
proces pentru a solicita serviciile de reţea de la un sistem de operare;
- Adresa unui socket este reprezentată de tripletul: <protocol, adresă locală, port local>.
Spre exemplu, în versiunea 4 a stivei TCP/IP se utilizează următoarea adresă a
socketului: <tcp, 192.168.14.234, 8080>;
- O conversaţie reprezintă o legătură de comunicaţie dintre două procese;
- O asociere reprezintă cvintetul care specifică complet cele două procese ce realizează
o conexiune: <protocol, adresă locală, port local, adresă distantă, port distant>. Spre
exemplu, în versiunea 4 a stivei TCP/IP se utilizează următoarea asociere: <tcp,
192.168.14.234, 1500, 192.168.44, 22>;
- O semiasociere reprezintă una dintre următoarele două triplete, care specifică numai
jumătate de conexiune: <protocol, adresă locală, port local> sau <protocol, adresă
distantă, port distant>. Semiasocierea este deasemenea numită socket sau adresă de
transport. Prin urmare un socket este un capăt al conexiunii de comunicaţie, care poate
fi denumit sau adresat într-o reţea.

Două procese comunică prin socketuri TCP. Modelul de socket oferă unui proces o
conexiune duplex-simultan sub formă de flux de octeţi, cu un alt proces. Aplicaţia nu trebuie
să se ocupe cu administrarea acestui flux de octeţi, deoarece aceste facilităţi sunt furnizate de
TCP.
TCP utilizează acelaşi principiu de administrare a porturilor ca şi UDP pentru a realiza
multiplexarea de fluxuri. Ca şi UDP, TCP utilizează porturile consacrate şi temporare. Fiecare
capăt al unei conexiuni TCP are un socket care poate fi identificat prin tripletul <TCP, adresă
IP, număr port>. Dacă două procese comunică peste TCP, atunci acestea au la dispoziţie o
Arhitecturi de Reţea şi Internet 3

conexiune logică care este identificată unic de către cele două socketuri implicate, mai exact
de combinaţia <TCP, adresă IP locală, port local, adresă IP distantă, port distant>. Procesele
de tip server pot controla mai multe conexiuni simultane prin intermediul aceluiaşi port.

3.2 PROTOCOLUL UDP

Este un protocol simplu care, folosind IP pentru transportul pachetelor, permite
identificarea nu numai a sistemelor sursă şi destinaţie, prin adresele lor de reţea, ci şi a
programelor de aplicaţie între care se realizează transferul de informaţie. Sistemele de operare
ale majorităţii calculatoarelor permit executarea simultană a mai multor programe de aplicaţie
aşa încât, în fapt, destinatarul final pentru un mesaj transmis prin reţea este un anumit proces
(program de aplicaţie) dintre toate cele care se execută simultan pe un sistem de calcul.
Pentru a se face distincţie între multiplele programe ce se execută pe un acelaşi sistem,
UDP utilizează porturi de protocol, fiecare port fiind identificat printr-un număr, aşa a fost
ilustrat în paragraful anterior.
Serviciul furnizat de UDP este un serviciu fără conexiune, nefiabil, utilizatorii acestui
serviciu (programele de aplicaţie) trebuind să aibă în vedere că pot avea loc pierderi de
mesaje, duplicări, livrarea mesajelor la destinaţie într-o ordine diferită de cea în care au fost
emise. Dacă este necesar, aceste funcţii de creştere a calităţii serviciilor vor fi implementate la
nivelul aplicaţie. UDP apare în aproximativ toate implementările stivei Internet şi este dedicat
transferului de unităţi de date pentru aplicaţii care pot admite pierderea unei cantităţi mici de
date (cum ar fi fluxurile multimedia).
UDP este doar o interfaţă de aplicaţie pentru IP şi nu serveşte decât pentru
multiplexarea/demultiplexarea fluxurilor de aplicaţie, transmiterea şi recepţionarea
datagramelor, utilizarea porturilor pentru redirectarea datagramelor. În figura 3.1 este ilustrat
mecanismul de multiplexare/demultiplexare pe bază de porturi, folosit de UDP.

Fig. 3.1 Demultiplexarea UDP pe bază de porturi.

Aplicaţiile care transmit datagrame către un sistem trebuie să identifice o destinaţie

care nu este specificată numai de adresa IP, deoarece datagramele sunt transmise către un
anumit proces care rulează într-un sistem şi nu întregului sistem. UDP permite acest lucru prin
intermediul porturilor.
4 3. Nivelul Transport

3.2.1. Formatul datagramei UDP

Fiecare mesaj UDP este numit pachet de utilizator (user datagram) pentru a-l distinge
de pachetul IP (IP datagram). Formatul mesajului UDP este prezentat în figura 3.2. Mesajul
UDP se compune dintr-un antet relativ redus (8 octeţi) şi câmpul de date. Antetul precizează
porturile de protocol ale sursei şi destinaţiei între care se face transferul mesajului, lungimea
totală a mesajului UDP (inclusiv antetul) măsurată în octeţi.
Fiecare datagramă UDP este transmisă într-o singură datagramă IP. Totuşi, datagrama
IP poate fi fragmentată pe durata transmisiunii, dar la recepţie nivelul IP va reasambla
datagramele IP înainte de a oferi datele nivelului UDP. Toate implementările IP acceptă
datagrame IP de 576 octeţi, ceea ce înseamnă că dacă se consideră dimensiunea maximă a
antetului IP, de 60 de octeţi, atunci rezultă o datagramă UDP de 516 octeţi. Multe
implementări acceptă datagrame de dimensiuni mai mari, dar acest lucru nu este garantat.

Fig. 3.2 Formatul mesajului UDP.

Specificarea portului sursă este opţională. Acest port va fi utilizat ca port destinaţie
pentru datagramele de răspuns. Dacă nu se specifică acest port câmpul respectiv din antet se
completează cu biţi 0. Este opţională, de asemenea, şi utilizarea secvenţei de verificare care,
în caz că se foloseşte, ia în considerare nu numai antetul (ca la IP) ci şi câmpul de date.
Lungimea mesajului UDP este calculată în număr de octeţi şi include antetul.
Secvenţa de verificare se calculează pe un câmp mai mare decât cel ce corespunde
mesajului UDP. Pentru a crea posibilitatea de a verifica la recepţie că mesajul UDP a ajuns la
destinaţia corectă, secvenţa de verificare se calculează pentru un ansamblu format din mesajul
UDP şi antetul său precedate de un pseudoantet care conţine adresele de reţea ale sursei şi
destinaţiei, protocolul şi lungimea mesajului UDP. Acest pseudoantet nu se transmite dar la
recepţie protocolul UDP calculează secvenţa de verificare pe baza mesajului UDP recepţionat
şi a adreselor sursă şi destinaţie, disponibile în antetul pachetului IP care a transportat mesajul
respectiv. Dacă secvenţa asfel calculată coincide cu cea din mesajul UDP rezultă că mesajul a
ajuns la destinaţia (sistem şi port) desemnată de sursă. Formatul pseudoantetului IP este
ilustrat în figura 3.3.

Fig. 3.3 Formatul pseudoantetului IP.

Arhitecturi de Reţea şi Internet 5

Pseudoantetul IP este utilizat pentru a extinde calculul sumei de verificare pentru a

include şi datagrama IP originală (nefragmentată).
Figura 3.4 prezintă poziţia mesajului UDP în pachetul IP. Secvenţa de verificare este
calculată pe 16 biţi în complement faţă de 1.

Fig. 3.4 Poziţia mesajului UDP în pachetul IP.

3.2.2 Interfaţa de programare a aplicaţiei oferită de UDP

Interfaţa de aplicaţie oferită de UDP permite următoarele operaţii:
- Crearea de porturi noi pentru recepţie;
- Operaţia de recepţie care asigură livrarea unităţilor de date de aplicaţie, indicarea
portului sursă şi a adresei IP sursă;
- Operaţia de emisie, care are ca parametri datele, porturile sursă şi destinaţie şi adresele
IP;

Modul în care se implementează această interfaţă este lăsat la latitudinea fiecărui

producător.
Aplicaţiile standard care utilizează UDP sunt următoarele:
- Protocolul de transfer de fişiere simplificat, TFTP (Trivial File Transfer Protocol);
- Serverul de nume pentru sistemul de nume pentru domenii, DNS (Domain Name
System);
- Procedura de apelare la distanţă, RPC (Remote Procedure Call), folosită de sistemul
de fişiere pentru reţea, NFS (Network File System);
- Protocolul de administrare simplă a reţelei, SNMP (Simple Network Management
Protocol);

3.3 PROTOCOLUL TCP

Protocolul TCP, operând la nivelul transport, asigură un serviciu cu conexiune fiabil,
cu livrarea mesajelor la recepţie în ordinea în care au fost emise. Cele mai multe protocoale
de aplicaţie utilizează TCP, cum ar fi Telnet sau FTP. Cele două procese comunică prin
intermediul unei conexiuni TCP denumită conexiune de comunicare între procese, IPC
(InterProcess Communication) aşa cum se ilustrează în figura 3.5. În acest exemplu din figura
3.5, procesele 1 şi 2 comunică prin intermediul unei conexiuni TCP “purtată” de datagrame
IP.
6 3. Nivelul Transport

Fig. 3.5 Comunicaţia TCP bazată pe conexiune.

3.3.1 Formatul segmentului TCP

Mesajele transferate la nivelul transport între două sisteme prin protocolul TCP, se
numesc segmente. Formatul unui segment este prezentat în figura 3.6. Fiecare segment se
compune dintr-un antet urmat de date. Antetul conţine informaţie de identificare şi informaţie
de control. Primele două câmpuri, port sursă şi port destinaţie, conţin numerele porturilor TCP
ce identifică cele două programe de aplicaţie de la capetele conexiunii.
Numărul de secvenţă reprezintă numărul de ordine, în secvenţă, al primului octet din
câmpul de date. Dacă bitul de control SYN este fixat la valoarea 1, atunci numărul de
secvenţă reprezintă numărul iniţial de secvenţă (n), iar primul octet de date este n+1.
Numărul confirmat reprezintă numărul de secvenţă al octetului de date ce se aşteaptă a
fi recepţionat. Dacă bitul de control ACK este fixat la valoarea 1, acest câmp conţine valoarea
numărului de secvenţă următor care se aşteaptă a fi recepţionat.
Trebuie remarcat că numărul de secvenţă se referă la fluxul datelor ce se transmit în
acelaşi sens cu segmentul respectiv, iar numărul confirmat se referă la fluxul datelor transmise
în sens invers.
Lungimea antetului se exprimă printr-un întreg care reprezintă numărul cuvintelor de
32 biţi din care este constituit antetul. Este necesar să se indice lungimea antetului deoarece
lungimea câmpului rezervat pentru specificarea opţiunilor este variabilă.

Fig. 3.6 Formatul unui segment TCP.

Arhitecturi de Reţea şi Internet 7

Există mai multe tipuri de segmente, funcţie de scopul în care sunt folosite: transfer
date, stabilire conexiune, eliberare conexiune, numai pentru confirmări (fără transfer date),
transfer date în regim de urgenţă etc. Specificarea tipului de segment se face prin biţii notaţi
U, A, P, R, S şi F. Aceşti biţi au următoarele semnificaţii:
- U (URG) – specifică semnificaţia importantă a câmpului de pointer urgent în cadrul
acestui segment;
- A (ACK) – specifică semnificaţia importantă a câmpului de confirmare în cadrul
acestui segment;
- P (PSH) – Funcţia de forţare (push) a segmentelor. În unele situaţii, o aplicaţie trebuie
să fie informată că toate datele transferate la nivelul TCP au fost transmise către
destinaţie. Din acest motiv s-a introdus funcţia de forţare a transmisiei segmentelor
TCP rămase încă în unităţile de memorie, către sistemul destinaţie. Închiderea normală
a conexiunii va determina deasemenea forţarea datelor către destinaţie;
- R (RST) – Resetarea conexiunii;
- S (SYN) – Sincronizează numerele de secvenţă;
- F (FIN) – Oprirea transferului de date de la emiţător.

Câmpul “pointer urgent” indică poziţia datelor care se transmit în regim de urgenţă în
fluxul general al datelor.
În câmpul “fereastră” se specifică numărul de octeţi, începând cu cel menţionat în
câmpul de confirmare, pe care transmiţătorul îi poate accepta (pe sensul invers de
transmisiune).
Secvenţa de verificare este folosită pentru a verifica integritatea întregului segment
(antet şi date) dar, ca şi în cazul protocolului UDP, pentru a da posibilitatea receptorului să
verifice că segmentul a ajuns la adresa de destinaţie corectă, se utilizează şi un pseudoantet
având formatul din figura 3.7. Pseudoantetul nu se transmite, nu face deci parte din segment,
dar se ataşează segmentului numai pentru calculul secvenţei de verificare. El conţine adresele
de reţea (IP) ale sursei şi destinaţiei, identificatorul protocolului şi lungimea totală a
segmentului TCP, inclusiv antetul TCP. Identificatorul protocolului este reprezentat de
valoarea trecută în câmpul rezervat tipului de protocol din formatul utilizat de nivelul imediat
inferior. Pentru pachetele IP care transportă segmente TCP această valoare este 6.

Fig. 3.7. Formatul pseudoantetului.

Protocolul TCP foloseşte câmpul “opţiuni” pentru negocieri între cele două capete ale
conexiunii. Printre altele, prin aceste negocieri i se permite receptorului să specifice
dimensiunea maximă a segmentelor pe care el o poate suporta, aspect foarte important, spre
exemplu, atunci când un mic calculator personal, cu o capacitate a memoriei tampon de
câteva sute de octeţi, este conectat la un supercalculator.
Ca şi în cazul opţiunilor datagramelor IP, opţiunile pentru segmentul TCP pot fi
specificate prin una din metodele:
- un singur octet care conţine numărul opţiunii;
8 3. Nivelul Transport

- opţiuni de lungime variabilă cu formatul din figura 3.8.

Fig. 3.8. Formatul opţiunilor TCP de lungime variabilă.

Există şapte opţiuni posibile pentru segmentele TCP, care sunt prezentate în tabelul 3.1:

Tip opţiune Lungime (octeţi) Semnificaţie

0 - Sfârşitul listei de opţiuni
1 - Fără operaţii
2 4 Dimensiunea maximă a
segmentului
3 3 Ajustarea ferestrei
4 2 Permiterea SACK.
5 X SACK
8 10 Etichete temporale

Tab. 3.1. Opţiunile segmentului TCP

Aceste opţiuni vor fi descrise în continuare.

Opţiunea de specificare a dimensiunii maxime a segmentului. Această opţiune este

utilizată numai pe durata stabilirii conexiunii (bitul de control SYN fiind setat) şi cererea este
transmisă de către capătul care urmează să recepţioneze datele, pentru a indica lungimea
maximă a segmentului pe care acest sistem o poate suporta. Dacă această opţiune nu este
utilizată atunci este permisă orice dimensiune a segmentului.

În ceea ce priveşte dimensiunea segmentelor, teoretic valoarea optimă a acesteia este

determinată de dimensiunea maximă admisă de reţea pentru pachetele IP, pe calea de la sursă
la destinaţie, aşa încât să nu fie necesară fragmentarea segmentelor. Fragmentarea
segmentelor conduce la formarea de pachete ce corespund aceluiaşi segment dar care sunt în
mod independent tratate de reţea. Toate fragmentele trebuie să ajungă la destinaţie, altfel
trebuie să se retransmită întreg segmentul. Deoarece probabilitatea de pierdere (şi rejectare) a
unui fragment (pachet IP) nu este zero, creşterea dimensiunii segmentului peste pragul de
fragmentare conduce la multiplicarea situaţiilor în care este necesară retransmiterea
segmentelor. Desigur, segmentele retransmise pot avea dimensiuni diferite în raport cu cele
iniţiale, acesta fiind un motiv suplimentar pentru care în TCP confirmarea se face nu la nivel
de segment ci la nivel de octet.

Opţiunea de ajustare a ferestrei. Ambele capete ale conexiunii trebuie să transmită opţiunea
de scalare a ferestrei în cadrul segmentelor SYN pentru a permite ajustarea dimensiunii
ferestrei în sensul de transmisie. Transmiterea acestei opţiuni extinde dimensiunea ferestrei
TCP la o reprezentare pe 32 de biţi. Dimensiunea ferestrei reprezentată pe 32 de biţi este
definită prin intermediul unui factor de scalare (transmis în segmentul SYN) faţă de fereastra
standard reprezentată pe 16 biţi. Receptorul acestui mesaj modifică dimensiunea ferestrei de
la valoarea standard pe 16 biţi prin adăugarea factorului de scalare. Această opţiune poate fi
utilizată numai în faza de iniţializare a conexiunii. Astfel, dimensiunea ferestrei nu se mai
poate schimba pe toată durata menţinerii conexiunii.
Arhitecturi de Reţea şi Internet 9

Opţiunea de permitere a SACK. Această opţiune este introdusă numai atunci când pe
conexiunea TCP respectivă se utilizează confirmări selective (SACK – Selective
ACKnowledgement). Pentru această opţiune câmpul de date opţiune nu este utilizat (se
transmit numai tipul opţiunii şi lungimea)

Opţiunea SACK. Confirmarea selectivă SACK permite receptorului să informeze

transmiţătorul asupra tuturor segmentelor recepţionate corect. Astfel, transmiţătorul va
retransmite numai segmentele pierdute. În cazul în care numărul de segmente pierdute,
înregistrat de la ultimul SACK transmis, este foarte mare atunci şi dimensiunea opţiunilor
SACK va fi foarte mare. Din acest motiv numărul de blocuri de segmente care pot fi raportate
de către o opţiune SACK este limitat la patru. În figura 3.9 este ilustrat formatul opţiunii
SACK.

Fig. 3.9. Formatul opţiunii SACK.

Opţiunea etichetelor temporale (TS). Această opţiune transmite o valoare a etichetei

temporale TS (Time Stamp) care specifică valoarea curentă a timpului indicat de ceasul local
de la transmiţător. Valoarea “TS ecou” este utilizată dacă bitul ACK este setat cu 1 logic în
antetul TCP. În figura 3.10 este ilustrat formatul opţiunii TS.

Fig. 3.10. Formatul opţiunii etichetă temporală.

3.3.2 Stabilirea conexiunilor TCP

Înainte de a începe transferul datelor între cele două procese de utilizator (programe de
aplicaţie) se stabileşte, prin intermediul reţelei, o conexiune logică numită circuit virtual. În
acest scop programele de aplicaţie transmiţător şi receptor interacţionează cu sistemele de
operare reţea din sistemele respective. Un program aplicaţie realizează un apel, care trebuie să
fie acceptat de către celălalt program aplicaţie. Cele două sisteme de operare, prin modulele
destinate protocolului de comunicaţie, îşi transmit mesaje prin reţea pentru a verifica dacă
10 3. Nivelul Transport

transferul este autorizat (acceptat) şi dacă ambele părţi sunt gata pentru acest transfer.
Conexiunea fiind stabilită, cele două programe de aplicaţie sunt informate că transferul
datelor poate să înceapă. Programul de aplicaţie transmiţător transferă datele spre nivelul
transport sub forma unui flux de biţi, împărţit în octeţi. Acelaşi flux, în aceeaşi ordine a
octeţilor, este primit de programul de aplicaţie în sistemul de destinaţie.
La nivelul transport fluxul octeţilor primiţi de la programe de aplicaţie este împărţit în
segmente, care sunt apoi transmise în reţea spre destinaţie. Fiecare segment, format dintr-un
număr oarecare de octeţi, este transportat în reţea de un pachet IP. Conexiunile asigurate de
TCP/IP la acest nivel sunt conexiuni duplex, ceea ce înseamnă că cele două procese îşi pot
transmite date simultan unul către celălalt. Un avantaj al acestei conexiuni duplex constă în
faptul că se poate transmite informaţia de control (al erorii, al fluxului) înapoi către sursă în
pachete ce transferă datele în sens opus, reducându-se astfel traficul în reţea (metoda piggy-
back). Pentru controlul fluxului şi al erorii se utilizează temporizatoare la emisie şi confirmări
pozitive la recepţie, ACK (Positive acknowledgement). Atunci când se transmite un segment
cu un anumit număr de secvenţă se porneşte la emisie un temporizator. Dacă până expiră
temporizatorul nu soseşte o confirmare ACK, atunci segmentul este retransmis automat.
Deoarece protocolul TCP oferă un serviciu cu conexiune, conexiunea ce se stabileşte
pentru transferul datelor este identificată printr-o pereche de puncte de capăt (porturi de
protocol). În felul acesta, acelaşi port de protocol poate fi simultan capăt al mai multor
conexiuni. Spre exemplu, un sistem poate permite accesul concurenţial la serviciul său de
poştă electronică, acceptând pe un acelaşi port de protocol mesajele transmise simultan de la
mai multe calculatoare, cu fiecare dintre acestea având stabilită o altă conexiune, identificată
distinct de celelalte. Protocolul TCP realizează multiplexarea conexiunilor pe baza numerelor
porturilor, aşa cum se realizează şi la UDP.
Pentru stabilirea conexiunii, un proces (serverul, de obicei) transmite o cerere de
deschidere pasivă a conexiunii (passive OPEN), iar celălalt proces transmite o cerere activă
(active OPEN). Cererea pasivă nu este luată în considerare până când celălalt proces nu
încearcă să se conecteze la primul printr-o cerere activă. În figura 3.11 este ilustrat faptul că
pentru stabilirea conexiunii este necesar să se facă un schimb de trei segmente TCP între cele
două procese.

Fig. 3.11. Stabilirea conexiunii TCP.

Această procedură de stabilire a conexiunii este cunoscută sub numele de “three-way

handshake”. Se poate observa din figura 3.11 că segmentele TCP schimbate la stabilirea
conexiunii include şi valorile iniţiale ale numerelor de secvenţă de la ambele capete, care vor
fi utilizate pentru următoarele transmisii de date. Astfel, sincronizarea numerelor de secvenţă
se realizează odată cu stabilirea conexiunii.
Închiderea unei conexiuni se realizează prin transmiterea unui segment TCP care are
bitul FIN (nu mai urmează alte date) setat cu 1. Deoarece conexiunea este bidirecţională
simultan (full-duplex) atunci segmentul FIN încheie transmisiunea datelor numai pentru un
sens al conexiunii. Celălalt proces va transmite datele rămase şi va încheia transmisiunea la
Arhitecturi de Reţea şi Internet 11

rândul său cu un segment TCP care are bitul FIN setat cu 1. O conexiune se consideră a fi
închisă numai atunci se încheie transmisiunea în ambele sensuri.
Diferitele stări ale unei conexiuni TCP sunt enumerate în continuare:
- LISTEN: Aşteptarea unei cereri de conexiune de la un alt nivel TCP;
- SYN-SENT: S-a transmis un segment de sincronizare SYN, iar TCP aşteaptă un
segment SYN de răspuns;
- SYN-RECEIVED: S-a recepţionat un segment SYN, s-a transmis un segment SYN,
iar TCP aşteaptă un segment de confirmare ACK;
- ESTABLISHED: Schimbul celor trei mesaje de stabilire a conexiunii s-a încheiat;
- FIN-WAIT-1: Aplicaţia locală a emis o cerere de închidere CLOSE. TCP a transmis
FIN şi aşteaptă un ACK sau un FIN;
- FIN-WAIT-2: S-a transmis un FIN şi s-a recepţionat un ACK. TCP aşteaptă un FIN de
la nivelul TCP corespondent;
- CLOSE-WAIT: TCP a recepţionat un FIN şi a transmis un ACK. Nivelul TCP
aşteaptă o cerere ce închidere de la aplicaţia locală înainte de a transmite FIN;
- CLOSING: S-a transmis un FIN, s-a recepţionat un FIN şi s-a transmis un ACK. TCP
aşteaptă un ACK pentru segmentul FIN pe care l-a transmis;
- LAST-ACK: S-a recepţionat un FIN şi un ACK, iar un segment FIN a fost transmis.
TCP aşteaptă un ACK;
- TIME-WAIT: FIN a fost recepţionat şi confirmat cu ACK, iar TCP aşteaptă două
MSL pentru a şterge conexiunea din tabelă;
- CLOSED: Indică faptul că o conexiune a fost eliminată din tabela de conexiuni.

3.3.3 Controlul fluxului şi al erorii cu fereastra glisantă

Livrarea la destinaţie a fluxului de octeţi în ordinea în care aceştia au fost emişi, fără
pierderi şi fără duplicate, se asigură prin folosirea unei tehnici de confirmare pozitivă cu
retransmitere, combinată cu fereastră glisantă. Mecanismul ferestrei glisante utilizat de TCP,
operând la nivelul octeţilor şi nu al segmentelor, permite atât o transmisiune eficientă, cât şi
un control al fluxului.
Octeţii din fluxul datelor primite de la programul aplicaţie sunt numerotaţi în ordine.
Transmiţătorul, să-l notăm A, emite continuu segmente, formate cu aceşti octeţi, către celălalt
capăt al conexiunii, să-l notăm B, urmărind în acelaşi timp confirmările venite în sens invers
în chiar segmentele de date transmise de B către A. O confirmare venită de la capătul B
specifică numărul de ordine (de secvenţă) al primului octet din segmentul pe care acesta
(capătul B) îl aşteaptă, ceea ce înseamnă, implicit, o confirmare pentru recepţia tuturor
octeţilor anteriori transmişi de A. Numerele de ordine ale octeţilor pe care îi poate emite
transmiţătorul fără a avea confirmarea de recepţie a lor sunt specificate de fereastra glisantă
(figura 3.12).

Fig. 3.12 Fereastră glisantă.

Pentru o conexiune transmiţătorul alocă trei numărătoare (N1, N2, N3) care vor preciza
în orice moment poziţia ferestrei glisante. Numărătorul N1 marchează începutul ferestrei
glisante (limita inferioară), separând octeţii emişi şi pentru care s-au primit confirmările de
12 3. Nivelul Transport

recepţie de cei pentru care nu s-au primit confirmări. Numărătorul N3 indică sfârşitul ferestrei
(limita superioară), adică numărul de ordine al ultimului octet ce poate fi inclus într-un
segment ce urmează a fi transmis fără să mai vină vreo confirmare de recepţie. Numărătorul
N2 marchează în interiorul ferestrei limita ce separă octeţii deja transmişi de cei încă
netransmişi.
Deasemenea, receptorul va folosi o fereastră asemănătoare pentru a reconstitui fluxul
octeţilor emişi. În acelaşi timp, având în vedere că protocolul TCP stabileşte conexiuni duplex
şi că pe fiecare sens de transmisiune se utilizează câte o fereastră de emisie şi una de recepţie,
rezultă că în fiecare capăt al conexiunii vor exista două ferestre, una glisând pe fluxul datelor
ce se emit iar cealaltă pe fluxul datelor ce se recepţionează.
Protocolul TCP permite modificarea dimensiunii ferestrei glisante pentru a reliza un
control al fluxului. Fiecare confirmare, pe lângă specificarea numărului de octeţi recepţionaţi
(în ordine), conţine şi o indicaţie privind numărul de octeţi pe care receptorul îi poate accepta,
dependent de mărimea spaţiului liber din memoria tampon a acestuia. Transmiţătorul îşi va
modifica dimensiunea ferestrei de emisie corespunzător acestei indicaţii a receptorului, ceea
ce va conduce şi la creşterea eficienţei transmisiei prin reducerea simţitoare a numărului
pachetelor pierdute, rejectate de receptor şi, în consecinţă, reducerea şi a numărului
retransmiterilor.
În figura 3.13 se ilustrează un exemplu de transmisie TCP unde dimensiunea ferestrei
este de 1500 octeţi şi se utilizează segmente de 500 de octeţi. În acest exemplu, apare o
problemă deoarece transmiţătorul a aflat că segmentul 2 s-a pierdut sau s-a recepţionat cu
erori, dar nu ştie nimic despre segmentele 3 şi 4. Transmiţătorul ar trebui să retransmită
segmentele 3 şi 4, deoarece acestea se află încă în fereastra curentă. Referitor la această
situaţie, există două scenarii posibile:
- segmentul 3 a fost recepţionat corect şi din acest moment nu se cunoaşte starea
recepţiei segmentului 4. Este posibil ca şi acesta să fi fost recepţionat corect, dar
confirmarea ACK nu a ajuns încă sau ACK s-a pierdut;
- segmentul 3 s-a pierdut şi se transmiţătorul primeşte confirmarea ACK 1500 după
transmiterea segmentului 4.

Fiecare implementare a TCP poate utiliza temporizatoare pentru a determina timpul

după care se retransmite un segment, în cazul în care nu a sosit confirmarea. Dacă în exemplul
din figura 3.13 se utilizează temporizator la emisie, atunci la expirarea timpului de aşteptare a
confirmării segmentului 2, în primul scenariu se retransmite numai segmentul 2, dar în cel de-
al doilea scenariu se va aştepta din nou expirarea temporizatorului pentru segmentul 3.
Indiferent de alegerea făcută eficienţa maximă a protocolului este pierdută deoarece
confirmarea nu conţine un al doilea număr de secvenţă care să indice numărul segmentului
recepţionat în momentul respectiv.
Timpul de aşteptare a confirmărilor pentru octeţii conţinuţi într-un segment emis este
limitat. Când acest timp expiră fără a se primi confirmarea de recepţie, se presupune că
segmentul a fost eronat sau pierdut şi se retransmite. Este evident că timpul de aşteptare
trebuie să depindă de timpul necesar unui pachet să ajungă la destinaţie şi de timpul necesar
pentru întoarcerea confirmării. Aceşti timpi depind de legăturile de date parcurse (debit), de
întârzierea cu care sunt prelucrate pachetele în fiecare ruter, deci şi de trafic şi, prin urmare,
sunt variabili, pentru o aceeaşi conexiune, de la un moment la altul. Pentru a se adapta la
aceste întârzieri variabile introduse de reţea, protocolul TCP foloseşte un algoritm de
retransmitere adaptiv prin care se reglează permanent limita timpului de aşteptare a
confirmărilor. Pentru a realiza acest lucru, TCP înregistrează momentul transmiterii unui
anumit segment şi momentul sosirii confirmării pentru acesta. Se estimează o valoare medie a
acestui timp de propagare dus-întors (round trip time) pentru mai multe segmente transmise,
Arhitecturi de Reţea şi Internet 13

care este utilizată pentru valoarea temporizatorului atunci când se transmite următorul
segment.

Fig. 3.13 Exemplu de transmisie TCP cu confirmări şi retransmisii.

3.3.4. Algoritmi de control al congestiei în TCP

O diferenţă esenţială dintre UDP şi TCP este că TCP utilizează un algoritm de control
al congestiei. Algoritmul de control al congestiei în TCP previne situaţia în care
transmiţătorul ar depăşi capacitatea de prelucrare a reţelei (spre exemplu, în cazul unor reţele
WAN lente). Astfel, TCP poate adapta debitul transmiţătorului în funcţie de capacitatea
reţelei, astfel încât să se evite posibilele situaţii de congestie şi deci, pierderea segmentelor.
Dealungul timpului s-au adăugat şi s-au propus mai multe îmbunătăţiri ale TCP cu scopul de a
controla congestiile. Această căutare de algoritmi de evitare a congestiilor este încă o direcţie
de cercetare deschisă, dar implementările moderne ale TCP conţin patru algoritmi de bază
pentru Internet (de obicei utilizându-se variante combinate ale acestora):

- iniţializare lentă;
- evitarea congestiei;
- retransmisie rapidă;
- recuperare rapidă.
În continuare se descriu pe scurt aceşti patru algoritmi.

Iniţializarea lentă (Slow start). Implementările TCP mai vechi deschide o conexiune prin
introducerea de la transmiţător a mai multor segmente în reţea, până când se atinge
dimensiunea ferestrei anunţate de receptor. Deşi totul este în regulă atunci când sistemele se
află în acelaşi LAN, atunci când există ruteri între cele două sisteme şi se utilizează legături
lente atunci pot apărea probleme. Unii ruteri intermediari nu pot face faţă situaţiei şi atunci
14 3. Nivelul Transport

pachetele se pierd, ceea ce determină apariţia retransmisiilor şi deci, reducerea

performanţelor. Algoritmul utilizat pentru evitarea acestei situaţii poartă numele de
iniţializare lentă. Acesta operează prin observarea faptului că rata cu care se introduc noi
pachete în reţea ar trebui să fie egală cu rata sosirii confirmărilor de pe celălalt sens.
Iniţializarea lentă mai adaugă o fereastră la nivelul TCP transmiţător: fereastra de congestie.
Atunci când se stabileşte o nouă conexiune cu un sistem dintr-o altă reţea se iniţializează
fereastra de congestie cu dimensiunea de un segment (spre exemplu, dimensiunea
segmentului anunţată de celălalt capăt sau implicit cu o valoare tipică de 536 sau 512). De
fiecare dată când se recepţionează un segment ACK dimensiunea ferestrei de congestie creşte
cu un segment. Transmiţatorul poate transmite cea mai mică dimensiune a ferestrei de
congestie sau pe cea anunţată. Fereastra de congestie este impusă de controlul de flux de la
transmiţător, în timp ce fereastra anunţată este impusă de controlul de flux de la receptor.
Prima dintre acestea două se bazează pe evaluarea făcută de către transmiţător a congestiei
percepute în reţea, iar a doua este legată de numărul de locaţii libere ale cozilor de aşteptare
de la recepţie, pentru această conexiune.
Transmiţătorul începe prin a transmite un segment şi apoi aşteaptă confirmarea ACK pentru
acesta. Atunci când soseşte confirmarea dimensiunea ferestrei de congestie este incrementată
de la unu la doi, iar apoi se pot transmite două segmente. Atunci când ambele segmente sunt
confirmate, dimensiunea ferestrei de congestie se va incrementa la patru. Acest mecanism
determină o creştere exponenţială a traficului, deşi această creştere nu este tocmai
exponenţială deoarece receptorul trebuie să întârzie confirmările sale, în mod uzual, prin
transmiterea unei ACK pentru fiecare două segmente pe care le recepţionează. La un anumit
moment dat, capacitatea reţelei IP este atinsă, iar ruterul intermediar va începe să arunce
pachete. Acest lucru va specifica transmiţătorului că fereastra sa de congestie a devenit prea
mare. În figura 3.14 se ilustrează algoritmul de iniţializare lentă.

Fig. 3.14 Exemplu de iniţializare lentă pentru controlul congestiilor.

Arhitecturi de Reţea şi Internet 15

Evitarea congestiei. Presupunerea care se face în cazul acestui algoritm este că pierderea
pachetelor cauzată de reţea este foarte mică (mult mai mică de 1%). Astfel, pierderea unui
pachet va determina semnalizarea congestiei undeva în reţea, între sursă şi destinaţie. Există
două indicatoare ale pierderii unui pachet:
- expirarea unui temporizator;
- recepţionarea unor confirmări ACK duplicat.

Evitarea congestiei şi deschiderea lentă sunt algortimi independenţi, care au obiective diferite.
Totuşi, atunci când se produce o congestie, TCP va trebui să scadă rata de transmisiune în
reţea a segmentelor şi să utilizeze iniţializarea lentă pentru a reporni transmisiunea. În practică
aceşti doi algoritmi sunt implementaţi împreună.
Evitarea congestiei şi iniţializarea lentă necesită menţinerea a două variabile pentru fiecare
conexiune:
- o fereastră de congestie, notată cu cwnd;
- un prag de iniţializare lentă, notat cu ssthresh.

Algoritmul rezultat prin combinarea celor doi algoritmi de mai sus funcţionează astfel:
1. Iniţializarea unei anumite conexiuni presupune setarea cwnd cu valoarea de un
segment şi ssthresh cu valoarea 65535 octeţi;
2. Rutina TCP de ieşire nu transmite niciodată mai mult decât valoarea cea mai mică
dintre cwnd şi fereastra anunţată de receptor;
3. Atunci când se produce o congestie (expirare timp sau ACK duplicat), jumătate din
dimensiunea ferestrei curente este salvată în ssthresh. În plus, dacă aceeaşi congestie e
indicată de expirarea timpului, cwnd este setat la un segment;
4. Atunci când datele noi sunt confirmate de către celălalt capăt se creşte cwnd, dar
valoarea cu care creşte aceasta depinde dacă TCP realizează o iniţializare lentă sau
evitarea congestiei. Dacă cwnd este mai mic sau egal cu ssthresh, atunci TCP lucrează
cu iniţializarea lentă; în caz contrar, TCP rulează cu evitarea congestiei.
Se utilizează iniţializarea lentă până când se ajunge la jumătate din valoarea la care
ajunsese când s-a produs congestia (deoarece a memorat jumătate din dimensiunea
ferestrei care a cauzat problema, în pasul 3), iar apoi se comută pe modul de evitare a
congestiei. Iniţializarea lentă începe cu cwnd având valoarea de un segment, iar apoi se
incrementează cu un segment la recepţionarea fiecărei ACK. Aşa cum s-a menţionat
anterior, fereastra creşte exponenţial: se trimite un segment, apoi două, apoi patru, etc.
Evitarea congestiei stabileşte ca cwnd să fie incrementată cu dim_segm* dim_segm /cwnd
de fiecare dată când se recepţionează o ACK, unde dim_segm reprezintă dimensiunea
segmentului, iar cwnd se măsoară în octeţi. Aceasta este o creştere liniară a cwnd, prin
comparaţie cu creşterea exponenţială în cazul iniţializării lente. Creşterea cwnd ar trebui
să fie cel mult cu un segment pentru fiecare interval de propagare dus-întors (indiferent
câte ACK sunt recepţionate în acest interval), în timp ce iniţializarea lentă incrementează
cwnd cu numărul de ACK recepţionare în acest interval de propagare dus-întors.

În figura 3.15 se ilustrează cum lucrează împreună algoritmul de iniţializare lentă şi cel de
evitare a congestiei.
16 3. Nivelul Transport

Fig. 3.15 Exemplu de iniţializare lentă pentru controlul congestiilor.

Retransmisie rapidă. Algoritmul de retransmisie rapidă evită ca TCP să aştepte expirarea

unui temporizator pentru a retransmite segmentele pierdute. În 1990 s-au propus nişte
modificări pentru algoritmul de evitare a congestiei. Înainte de a descrie modificările făcute
trebuie făcută observaţia că TCP poate genera imediat o confirmare ACK duplicat atunci când
se recepţionează un segment care nu respectă ordinea în secvenţă. Această ACK duplicat nu
ar trebui întârziată. Scopul acestei ACK duplicat este de a informa celălalt capăt asupra
factului că un segment a fost recepţionat în afara ordinii din secvenţă şi să specifice care este
numărul de secvenţă aşteptat.

Fig. 3.16 Exemplu de retransmisie rapidă pentru controlul congestiilor.

Deoarece TCP nu poate identifica dacă o ACK duplicat este cauzată de pierderea unui
segment sau doar de o reordonare a segmentelor, acesta se va aştepta să recepţioneze un
număr redus de confirmări ACK duplicate. Se presupune că dacă este doar cazul unei
Arhitecturi de Reţea şi Internet 17

reordonări a segmentelor, atunci se vor produce una sau două ACK duplicate până când va fi
procesat segmentul reordonat, care va genera şi el o nouă ACK. Dacă se recepţionează trei sau
mai multe ACK duplicate în ordine, aceasta înseamnă că un segent a fost pierdut. Atunci,
TCP va retransmite segmentele ce par să lipsească, fără a mai aştepta expirarea
temporizatorului de retransmisie. În figura 3.16 se ilustrează algoritmul de retransmisie
rapidă.

Recuperare rapidă. După ce algoritmul de retransmisie rapidă decide transmiterea

segmentului care aparent lipseşte, se utilizează algoritmul de evitare a congestiei; în nici un
caz, nu se va utiliza iniţializarea lentă. Acesta este algoritmul cu numele de recuperare
rapidă. Acesta determină o îmbunătăţire a performanţelor deoarece permite un debit mare în
condiţii de congestii moderate, în special pentru ferestre mari.
Motivul pentru care nu se utilizează algoritmul de iniţializare lentă în acest caz este acela că
recepţia unor ACK duplicate informează TCP mai mult decât pierderea unui segment.
Deoarece receptorul poate genera un ACK duplicat numai dacă un alt segment este
recepţionat, acel segment a fost scos din reţea şi se află în registrul receptorului. Astfel, în
acest moment mai există date se ce propagă între cele două capete şi este de dorit ca TCP să
nu reducă viteza brusc prin utilizarea iniţializării rapide. Algoritmii de retransmisie rapidă şi
recuperare rapidă sunt de obicei implementaţi împreună, după cum urmează:
1. Atunci când un al treilea ACK duplicat este recepţionat la rând se va seta ssthresh la
jumătate din fereastra curentă de congestie, cwnd, dar nu mai puţin de două segmente.
În continuare se va retransmite segmentul lipsă. Se setează cwnd cu valoarea din
ssthresh plus de trei ori dimensiunea segmentului. Această procedură conduce la
creşterea ferestrei de congestie cu numărul de segmente care au fost scoase din reţea,
fiind memorate la celălalt capăt (în etapa 3).
2. De fiecare dată când soseşte un ACK duplicat se incrementează cwnd cu dimensiunea
segmentului. Această procedură conduce la creşterea ferestrei de congestie cu
dimensiunea segmentului care a fost scos din reţea. Se transmite un segment dacă
acest lucru este permis de noua valoare din cwnd.
3. Atunci când soseşte noua ACK care confirmă noile date, se setează cwnd cu valoarea
din ssthresh (valoarea setată în etapa 1). Această ACK este confirmarea pentru
retransmisia din etapa 1, care soseşte după un timp de propagare dus-întors de la acea
retransmisie. În plus, această ACK confirmă toate segmentele transmise între timp,
între momentul pierderii segmentului şi recepţia primei ACK duplicat. În această etapă
se utilizează evitarea congestiei, deoarece TCP a scăzut viteza la jumătate faţă de
valoarea pe care o avea în momentul pierderii segmentului.
 9. Protocoale pentru nume si directoare
9.1. Introducere în sisteme de nume
O problemă în a face disponibile resursele într-o retea este crearea unei căi usoare de
acces la acestea. Pentru retele de mică dimensiune poate fi usor de retinut, sau poate fi notat
locul în care se găsesc resursele, dar aceasta nu mai este o solutie pentru retele în dezvoltare
sau de dimensiuni mari. Problema devine tot mai complexă pe măsură ce creste numărul
resurselor care devin disponibile în afara retelelor individuale. Problema o constituie atât
multitudinea de retele, cât si multitudinea de platforme si variante hardware pe care se găsesc
aceste resurse. Pentru a veni în întâmpinarea acestei situatii, metodele de numire si manevrare
a directoarelor au fost divizate pentru a oferi o metodă uniformă de obtinere a informatiilor
necesare pentru a accesa o resursă de retea. Patru dintre aceste metode sunt:
Domain Name System (DNS)
Dynamic Domain Name System (DDNS)
Network Information System (NIS)
Lightweight Directory Access Protocol (LDAP)
Înainte de a analiza un sistem de nume specific, vom discuta despre actiunea lor în
general. Astfel vom întelege de ce aceste sisteme sunt importante si conceptele care stau la
baza tuturor sistemelor de numire, fără a presupune o implementare anume. Vom discuta
pornind de la o privire de ansamblu asupra sistemelor de nume si vom vedea de ce au fost
create. Apoi vom parcurge principalele functii ale unui sistem de nume: spatiul numelor,
înregistrarea numelui si rezolutia numelui. Apoi vom vedea cum functionează spatiul numelor
si arhitecturile, ceea ce se află în spatele înregistrării numelui si al administrării si, în final,
tehnici de rezolutie a numelui si elemente practice ale procesului de rezolutie.

9.1.1. Nume simbolice pentru adresare

Pentru un computer nu este deloc o problemă să asocieze un număr pentru fiecare
dispozitiv din retea, si apoi să utilizeze acest număr pentru a schimba informatii. Computerul
nu are nimic împotrivă să îi asociezi un număr lui (de exemplu 123.45.67.89) si tuturor
dispozitivelor din retea, apoi să primească o comandă de felul “transmite acest fisier
dispozitivului 135.79.24.68.”. Totusi, pentru utilizatorii umani acest mod de adresare este de
neutilizat tinând seama de faptul că aceste nume nu au nici o semnificatie. Omul preferă să
spună “trimite acest fisier computerului lui Ion”. Acesta este motivul care a dus la dezvoltarea
sistemelor de nume. Aceste tehnologii permit computerelor dintr-o retea să primească atât o
adresă numerică conventională, cât si un nume mult mai prietenos, citibil. Acest nume este
compus din litere, cifre si alte simboluri speciale, si uneori este numit nume simbolic. El
poate fi utilizat ca o formă alternativă de adresare a dispozitivului. Sistemul de nume dispune
de functiile necesare administrării sale, incluzând masuri de asigurare a unicitătii numelui, de
translatarea numelui în număr, de administrare a listelor de nume si numere.
Ceea ce este interesant în ceea ce priveste existenta sistemelor de nume este faptul că
sunt foarte importante pentru retele, dar nu sunt necesare pentru ca o retea să opereze. Aceasta
deoarece computerele au nevoie doar de o schemă numerică de adresare, nu de nume asociate
lor. Computerele si reteaua vor lucra, dar va fi mult mai greu factorului uman să le utilizeze.

Page 1 of 29
Să analizăm un exemplu care să ilustraze importanta sistemului de nume pentru utilizatorul
uman. Dacă presupunem că a apărut o disfunctionalitate în sistemul de nume ( nu
functionează o parte din Domain Name System (DNS)) care furnizează serviciul de nume în
Internet. Tehnic, DNS nu este necesar pentru Internet, deoarece toate comunicatiile utilizează
adresarea IP. Aceasta înseamnă că, desi ti se pare normal să accesezi site-ul CNN ca un site
web www.cnn.com, poti utiliza si adresa IP 64.236.16.20 dacă DNS nu functionează.
Problema care apare este aceea că probabil nu stii care este adresa IP a site-ului web CNN,
asa cum nu o stiu majoritatea celor care accesează site-ul. Este posibil să doresti informatii nu
numai de pe site-ul CNN, dar si de pe alte site-uri. Apare dificultatea retinerii adreselor
numerice chiar si pentru un număr mic din imensul număr de site-uri din Internet. De fiecare
dată când vei dori să accesezi o resursă va trebui să cauti personal (manual) adresa sa, asa
cum se vede în Figura 9.1.

Figura 9.1: Accesul în inter-retea în lipsa unui sistem de nume

Când nu există nici un sistem de nume, utilizatorul trebuie să cunoască adresa oricărui
dispozitiv pe care doreste să îl acceseze în inter-retea. Deoarece majoritatea dintre utilizatori
au o memorie a numerelor limitată, va trebui, de fiecare dată să apeleze la o căutare manulă,
ineficientă, de adresă

Page 2 of 29
 Este mult mai usor de reamintit numele unei resurse; dacă există un sistem de nume
functional, va trebui ca utilizatorul să introducă numele dispozitivului si sistemul de nume va
converti numele într-o adresă , ca în Figura 9.2.

Figura 9.2: Accesul în cazul unui sistem de nume

Când o inter-retea este dotată cu un sistem de nume, utilizatorul nu mai trebuie să cunoască
adresa IP a dispozitivului pentru a îl accesa. Trebuie introduc numai nemele, acesta este
convertit automat de către sistemul de nume în adresă.Sistemul va oferi adresa software-ului
client care o va folosi pentru a accesa resursa cerută ca si când utilizatorul ar fi introdus-o
direct

Importanta sistemului de nume depinde de caracteristicile retelei în care este utilizat.

Principalele trei motive care determină utilizarea unui sistem de nume sunt:
- Dimensiunea retelei. Dacă este vorba despre o retea mică, cu doar câteva computere, îti poti
aminti adresele lor si le poti folosi, chiar dacă acest lucru nu este ideal. În teorie, o retea de

Page 3 of 29
domiciliu cu două-trei computere nu are nevoie de un sistem de nume. Acesta devine esential
pentru mii de dispozitive.
- Complexitatea si mărimea adresei. Cu cât este mai complexă schema de adresare, sau cu cât
sunt mai extinse numerele utilizat, cu atât devin numerele mai greu de retinut.
- Priceperea utilizatorului. La începuturile retelisticii era un număr mic de ingineri bine
pregătiti si acestia pur si simplu memorau numerele masinilor cu care lucrau zilnic. În zilele
noastre cu milioane de utilizatori profani, nu este rezonabil să presupui că acestia vor retine
adrese de dispozitive.
Privind aceste trei motive se poate observa că tendinta în retele este de a creste
importanta sistemelor de nume. Retelele, fie că sunt private sau publice, devin tot mai întinse,
apar tot mai multi utilizatori, inclusiv persoane fără o pregătire tehnică. De asemenea, există
tendinta de a trece de la adrese mici la altele mai mare. Cel mai bun exemplu îl constituie
tendinta de evolutie a Protocolului Internet. Cât de important este DNS pentru adresele de 32
de biti din Ipv4, cu atât mai mult va fi important atunci când vor fi utilizate adresele de 128 de
biti din Ipv6.

9.1.2. Functiile sistemului de nume

Cu toate că diferenta dintre adresarea numerică si numele simbolice este semnificativă
pentru utilizatori, este important de retinut că ambele au acelasi scop: identificarea
dispozitivului. Chiar dacă vom utiliza un sistem de nume pentru a face mai usor accesul la
dispozitive, computerele vor continua să functioneze normal pe baza identificatorului
numeric. Concluzionând, fiecare dispozitiv va dispune de doi identificatori: un număr si un
nume.
Această situatie permite atât oamenilor, cât si masinilor să utilizeze metoda de identificare pe
care o preferă. Aceasta implică existenta unei administrări a atribuirilor de nume
dispozitivelor si a conversiei dintre nume si numere. Sistemul de nume va fi un sistem coplet
care permite numelor să fie utilizate de către oameni, iar numerele să fie utilizate în
continuare de către dispozitive.
Sistemul de nume are următoarele functii de bază:
- Spatiul numelor (Name Space). Sistemul de nume defineste un spatiu al numelor (name
space) pentru reteaua în care lucrează. Spatiul numelor, numit uneori si arhitectura numelor
(name architecture), descrie regulile după care sunt structurate si utilizate numele. De
asemenea defineste modul în care numele unui dispozitiv este înrudit cu numele altui
dispozitiv din sistem si cum se asigură eviatrea atribuirii de nume invalide care să provoace
probleme în functionarea sistemului.
- Înregistrarea numelui (Name Registration). Pentru a implementa un sistem de nume,
trebuie asociat un nume fiecărui dispozitiv din retea. Ca orice sistem de adresare, sistemul de
nume nu poate functiona corect dacă nu este asigurată unicitatea numelui în sistem. Procesul
de legare a unui nume de un dispozitiv poartă numele de înregistrarea numelui.
Rezolutia numelui (Name Resolution). Asa cum am mentionat anterior, cu toate că oamenii
preferă numele simbolice, computerele le utilizează foarte rar. Este necesară definirea unui
mecanism prin care numele simbolic al unui dispozitiv să fie translatat într-o adresă numerică.
Acest proces este numit uzual rezolutia numelui.

Page 4 of 29
9.1.3. Relatiile dintre functiile sistemului de nume
Spatiul numelor este mai mult decât o functie descriptivă; este o definire a modului în
care lucrează numele în sistem. Inregistrarea numelui si rezolutia sunt functii mai active,
fiecare sistem de nume incluzând una sau mai multe proceduri specifice pentru a le realiza.
Înregistrarea si rezolutia numelui sunt oarecum complementare, tehnicile de înregistrare fiind
asociate cu metode particulare de rezolutie. Ambele metode depind de spatiul numelor si în
particular de arhitectura sa. Aceste relatii sunt ilustrate simplificat în Figura 9.3.
Procesele de înregistrare si rezolutie pot fi mai simple sau mai complicate, functie de
sistemul de nume utilizat. Sisteme de nume simple sunt operate în general manual, sunt usor
de utilizat si de înteles si cel mai bine utilizate în retelele mici. Retelele mari, mai complexe,
inter-retelele cer un sistem de nume mai sofisticat, care să lucreze mai putin cu interventia
administratorului si să fie scalabil (expandabil) pe masură ce sunt introduse masini noi în
retea.

Figura 9.3: Functiile sistemului de nume

Spatiul numelor defineste structura sistemului si regulile de creare a acestora. Spatiul numelor
este utilizat ca bază pentru înregistrarea numelui care defineste modul de mapare (cartare)
dintre nume si adrese. Atunci când un utilizator accesează un dispozitiv prin nume, metoda
rezolutia numelui va fi utilizată pentru a consulta spatiul numelor, a determina adresa asociată
cu numele si apoi pentru a converi numele în adresă.

Page 5 of 29
9.1.4. Spatiul numelor arhitectura numelor

Ideea principală a unui sistem de nume este de a oferi un mod de accesare a

dispozitivelor utilizând nume simbolice. Ca orice mecanism de identificare, înainte de a
utiliza sistemul trebuie definită o cale de realizare a identificării. Schemele de adresare
numerice (ex. adresarea IP) au reguli de creare a adreselor si de asociere a unei adrese din
spatiul de adrese fiecărui dispozitiv. În mod similar, dispozitivele primesc nume din spatiul
numelor.

9.1.4.1. Functiile spatiului nume

Dintre cele trei componente functionale ale sistemului de nume spatiul nume este cel mai
abstract. Este de asemenea partea fundamentală a sistemului, deoarece descrie modul de
creare a numelor. Câteva dintre aspectele definite de către spatiul numelor în sistemul de
nume sunt:
- Dimensiunea numelui si numărul maxim de nume: Spatiul numelor specifică numărul
de caractere (simboluri) care compun un nume. De asemenea defineste numărul
maxim de nume care pot apărea în sistem.
- Reguli de nume si sintaxa numelui: Spatiul numelor specifică ce caractere sau
simboluri sunt permise într-un nume. Este utilizat pentru a permite alegerea de nume
valide pentru toate dispozitivele.
- Arhitectura numelui si semantica: Fiecare spatiu de nume utilizează o arhitectură sau
structură specifică care descrie cum au fost construite numele si cum vor fi
interpretate.

9.1.4.1.1. Arhitecturile numelui

Cea mai importantă caracteristică a spatiului numelor este arhitectura numelui, motiv
pentru care uneori spatiul numelor este numit si arhitectura numelui. Arhitectura spatiului
numelor determină dacă numele atribuite si utilizate sunt un simplu set de simboluri
nestructurat, sau dacă au o structură internă mai complexă. În ultimul caz spatiul numelor
trebuie să definească cum relationează elementele unui nume particular.
Teoretic, sunt posibile mai multe arhitecturi de nume diferite. În practică se aplică una
din două arhitecturi: plată sau ierarhică.

Arhitectura de nume plată (Flat Name Architecture (Flat Name Space))

Numele sunt atribuite ca o secventă de simboluri care sunt interpretate ca o etichetă
fără nici o structură internă. Nu poate fi distinsă nicio relatie între un nume si orice alt nume.
Un exemplu de astfel de arhitectură este cel din Figura 9.4

Page 6 of 29
 Figure 9.4: Flat Name Architecture (Flat Name Space)
Nu există nici o structură care să organizeze numele sau care să dicteze cum să fie construite.
Din punct de vedere logic, fiecare dispozitiv este egalul oricărui altuia.

Arhitectura de nume ierarhică

În această arhitectură numele constau într-o secventă de simboluri, aceste simboluri

fiind atribuite utilizând o structură specifică si clară. Numele este compus din elemente
discrete care se află într-o relatie unele cu altele utilizând uzual o semantică iererhică părinte-
fiu. Sunt multe arhitecturi de nume în diferite contexte care utilizează acest tip de structură
ierarhică. De exemplu, o companie mare va realiza o hartă a organizatiei si va da nume
componentelor executive ale organizatiei. Un exemplu ipotetic al unei arhitecturi de nume
ierarhice este dat în Figura 9.5

Figura 9.5: Hierarchical Name Architecture (Structured Name Space)

Diagrama contine aceleasi dispozitive ca si Figura 9.4, dar acestea au fost aranjate utilizând o
arhitectură structurată, ierarhică. În acest caz organizatia a ales să structureze numele
dispozitivelor sale mai întâi după locatie, apoi după numele departamentului. Astfel se asigură
evitarea conflictelor de nume. Masina lui John din departamentul vânzări SUA va primi ca
prefix “US-Sales” si se va putea numi “US-Sales-John”, fără a intra în conflict cu masina lui
John care lucrează în zona europeană si, ca atare, se va numi (“EU-Sales-John”.) Acest fel de
numire va oferi posibilitatea localizării imediate a unui dispozitiv în interiorul organizatiei.
Cel mai cunoscut exemplu de spatiu numelor ierarhic este cel al TCP/IP, Domain Name
Space, care utilizează etichete text separate prin puncte pentru a forma o structură internă.
Page 7 of 29
9.1.4.1.2. Comparatie între arhitecturile de nume.
Arhitectura paltă cere prezenta unei autorităti centrale care să sorteze si atribuie nume
tuturor dispozitivelor si să asigure unicitatea numelor din sistem. O arhitectură ierarhică este
ideală pentru o schemă de înregistrare distribuită care să permită mai multor autărităti să-si
împartă procesele administrative.
Spatiile plate au avantajul simplitătii si al abilitătii de a crea nume simple si usor de
retinut, ca în Figura 9.4. Totusi, arhitectura nu este scalabilă pentru sisteme de nume cu mii de
masini datorită dificultătii de a mentine unicitatea numelui. De exemplu, dacă sunt patru
utilizatori cu numele John si toti vor să-si numească masina “John’s PC”? Este necesară o
încărcare suplimentară pentru a administra aceste nume.
Arhitectura ierarhizată este mult mai sofisticată, dar mai flexibilă, deoarece permita
numelor să fie atribuite folosind o structură logică. Putem numi masina noastră pornind de la
o ierarhie care reflectă structura organizatiei din care facem parte, dând autoritate diferitelor
departamente ale organizatiei să administreze părti ale spatiului numelor. Cât timp fiecare
departament are un nume unic, si acest nume unic este parte a numelui fiecărei masini din
departamant, nu trebuie să ne facem griji privind atribuirea de nume unice la nivelul întregii
organizatii, ci numai la nivelul departamentului respectiv. Putem avea în interiorul
organizatiei patru masini diferite numite după numele departamentului lor si ”John”, asa cum
se vede în Figura 9.5 . Pretul plătit pentru această flexibilitate este nesecitatea unor nume mai
lungi si înregistrări si rezolutii mai comlexe.

9.1.5. Metode de înregistrare a numelui, administrare si autorităti

Este evident că pentru a implementa propriul sistem de nume avem nevoie de metode
de atribuire a numelor pentru fiecare dispozitiv pe care îl folosim în sistem. Com sistemul de
nume are un spatiu numelor care este comparabil cu ceea ce reprezintă spatiul adreselor într-
un sistem de adresare, va trebui implementat un set de reguli si proceduri pentru atribuirea de
nume, la fel cum un sistem de adresare atribuie adrese.

9.1.5.1. Functiile înregistrării numelui

În general, înregistrarea numelui presupune următoarele concepte si actiuni:
- Atribuirea de nume si garantarea unicitătii: Sarcina principală a procesului de
înregistrare a numelui este atribuirea de nume dispozitivelor. Ca toate schemele de
identificare, o cerintă cheie a înregistrării numelui o constituie asigurarea unicitătii
fiecărui nume. Numele duplicate creează ambiguităti si fac imposibilă rezolutia
numelui.
- Desemnarea unei autorităti centrale de înregistrare: Asigurarea unicitătii numelui
presupune încărcarea cuiva cu sarcina procesului se atribuire a numelui. Această
autoritate centrală poate fi una individuală care să mentină fisierele continând numele,
sau o organizatie care să fie responsabilă de întregul proces de înregistrare. Această
autoritate este chemată să rezolve problemele si conflictele care pot apărea în procesul
de înregistrare.
- Delegarea autoritătii înregistrării: În sistemele numelor mici o autoritate centrală poate
fi responsabilă de procesul de înregistrare pentru toate dispozitivele. Într-un sistem al
numelor mare, ierarhizat, nu este practic să avem acest proces centraizat. De aceea,
autoritatea centrală de înregistrare va diviza spatiul numelor si va delega autoritatea de
înregistrare a numelor diferitelor organizatii subordonate. Este necesară dezvoltarea si
implementarea unei politici de delegare.
- Definirea structurii ierarhice: Când este utilizat un spatiu al numelor ierarhizat,
autoritatea centrală este responsabilă de modul în care va arăta structura. Ea va

Page 8 of 29
 dispune cum vor fi înregistrate numele în diferite părti ale ierarhiei, si cum va fi
delegată autoritatea.

9.1.5.2. Impactul arhitecturii spatiului numelor asupra înregistrării numelui

Complexitatea procesului de înregistrare a numelui depinde de cât de extins si de
complex este sistemul numelor, în particular de arhitectura spatiului numelor. Într-un sistem
simplu, plat, înregistrarea se face de regulă sub o singură autoritate. Nu există nici o structură,
deci nici o delegare de autoritate.
Pentru sisteme ale numelui ierarhizate, înregistrarea numelui este legată de ierarhia de
nume utilizată. Autoritatea centrală defineste structura ierarhiei, decide cum se partitionează
această ierarhie în subseturi care pot fi administrate individual de către alte autorităti
(delegate). Aceste autorităti pot la rândul lor să delege alte subseturi ale propriului spatiu al
numelor, rezultând un sistem flexibil si extensibil.
Această delegare de autoritate este unul dintre beneficiile majore ale spatiului numelor
ierarhizat. De exemplu, în TCP/IP DNS, există o autoritate centrală care înregistrează numele.
Ea are sarcina de a decide care sunt domeniile de nivel înalt care pot exista, de exemplu
“.com”, “.edu”, “.info” si “.uk” . Autoritatea de a administra fiecare din aceste domenii este
apoi delegată altor organizatii. Aceste organizatii continuă divizarea ierarhiei. Eventual
fiecare organizatie poate decide cum se vor numi fiecare dintre sistemele interne
independente.

9.1.5.3. Metode de înregistrare a numelui

Există câteva metode comune prin care se realizează procesul de ânregistrare. Fiecare
dintre acestea are punctele sale tari si slabe, unele fiind potrivite pentru un spatiu al numelor
plat, altele pentru unul ierarhizat.

Înregistrarea numelui în tabel

În această tehnică atribuirea numelor este păstrată de către administratot într-un tabel.
Când trebuie adăugat, sters sau modificat un nume, se editează tabelul.
Această tehnică este asociată uzual cu spatii ale numelor mici, plate si are aceleasi
beneficii si neajunsuri ca si arhitectura plată: este simplu si usor de implementat, dar nu poate
fi extins la sisteme mari. Metoda nu poate fi utilizată în sisteme ierarhizate cu mai multe
autorităti, deoarece tabelul trebuie tinut într-un singur loc. În retelele mari tabelele pot fi o
tehnică de rezervă pentru una dintre tehnicile mai sofisticate care urmează.

Înregistrarea numelui prin broadcast

Un dispozitiv care doreste să utilizeze un nume particular trimite un mesaj către toate
celelalte dispozitive din retea întrebându-le dacă este cineva care utilizează acel nume. Dacă
da, îsi va alege alt nume. Dacă nu, numele se consideră înregistrat si va putea fi utilizat.
Tehnica este mai complicată decât utilizarea tabelului, dar rămâne limitată la utilizarea
în retele relativ mici. Nu este practică folosirea broadcastului către mii de sisteme, această
metodă neputând fi utilizată în Internet, neexistând o cale de a transmite broadcast către
fiecare dispozitiv din toate interretelele.

Înregistrarea într-o bază de date.

În această metodă este mentinută o bază de date a atribuirilor de nume. Pentru a
înregistra un nume, trebuie înaintată o cerere pentru ca atribuirea de nume să fie înscrisă în
baza de date. Dacă autoritatea sistemului de nume este cetralizată, atunci baza de date este
centralizată si mentinută de acea autoritate. Dacă sunt delegate autorităti pe portiuni ale

Page 9 of 29
ierarhiei, atunci va fi utilizată pentru înregistrare o baza de date distribuită, fiecare autoritate
delegată având sub administrare propria bază de date care descrie sectiunea sa din ierarhie.
Aceasta este cea mai sofisticată tehnică, si este normal asociată cu sisteme de nume ierarhice,
ca DSN. Printre avantajele ei pot fi enumerate flexibilitatea, fiabilitatea si distribuirea
efortului de administrare a bazelor de date. Principalul punct negativ îl reprezintă
complexitatea.

9.1.6. Tehnici de rezolutie a numelui si elemente functionale ale unui sistem de rezolutie
a numelor.
Utilizarea unui sistem de nume crează două sisteme de identificare paralele pentru
computere: numerele utilizate de masini si numele utilizate de oameni. Sarcina unui sistem de
nume este de a integra cele două scheme. Întegistrarea numelui permite oamenilor să specifice
ce masină utilizează un anumit nume. Acesta este numai jumătate din procesul care are loc;
avem nevoie de o cale prin care masinile să utilizeze numele dat de om si să îl translateze într-
o adresă reală care poate fi utilizată în comunicatii. Această a doua parte este numită rezolutia
numelui.
Rezolutia numelui, numită uneori si translatarea numelui, mapare, legare, este cel mai
cunoscut aspect al sistemelor de nume. Spatiul numelui este în general setat o singură dată, iar
înregistrarea numelui apare rar, numai atunci când trebuie create sau schimbate nume. În
opozitie, fiecare utilizator al unui sistem de nume impune masinii pe care lucrează să realizeze
rezolutia numelui poate de sute sau mii de ori pe zi.

9.1.6.1. Metode ale rezolutiei numelui

Există câteva tehnici diferite care sunt utilizate pentru rezolutia numelui. Modul în
care acestea functionează depinde în mare măsură de alte două functii ale sistemului de nume,
spatiul numelor si înregistrarea numelor. Asa cum se poate usor intui, un spatiu simplu si o
înregistrare simplă vor presupune si o rezolutie simplă. Sistemele ierarhizate complexe cu
baze de date distribuite vor cere o rezolvare a numelor mult mai sofisticată. Există trei metode
de rezolutie obisnuite.

Rezolutia numelui cu ajutorul tabelelor

Tabelul utilizat în înregistrarea numelui pe bază de tabel este consultat de fiecare
dispozitiv care realizează procesul de rezolutie. Tabelul spune dispozitivului cum transformă
numele masinii care trebuie contactată într-o adresă.
Această tehnică corespunde evident întregistrării numelui cu ajutorul tabelului; este
cea mai simplă dintre cele trei metode. Metoda este utilizabilă numai în sisteme de nume
foarte mici, dar poate fi întregită de alte metode.

Rezolutia numelui prin broadcast

Când un dispozitiv trebuie să rezolve un nume, el transmite broadcast un mesaj care
vrea să spună “trebuie să iau legătura cu un dispozitiv cu numele X, cine este acesta?”.
Dispozitivul cu numele X va răspunde spunând ”Sunt X si adresa mea numerică este N”.
Această tehnică este complementul înregistrării prin broadcast. De asemenea este utilizabilă
numai în sisteme de mici dimensiuni în care dispozitivele pot receptiona mesajele broadcast.

Rezolutia numelui de tip client/server

Există servere care sunt programate anume pentru a putea răspunde unei cereri de
rezolutie de nume din partea unui client. Aceste servere extrag numele din cerere, îl asociază
cu un identificator numeric într-o bază de date si îl trimit într-un răspuns.

Page 10 of 29
 Această tehnică este utilizată în general în conjunctie cu înregistrarea în baza de date.
Este cea mai complexă metodă de rezolutie, dar este si cea mai eficientă si singura care poate
functiona corespunzător într-un sistem de nume larg, distribuit, ierarhizat.

9.1.7. Istoricul sistemelor de nume TCP/IP

La sârsitul anilor 1960 când a fost dezvoltat predecesorul Internetului (ARPANET),
acesta utiliza protocoale având functii similare TCP/IP-ului de azi. ARPANET era foarte mică
după standardele de astăzi, continând câteva masini numite, ca si azi, hosturi. Schema de
adresare era foarte simplă, fiind o combinatie dintre un număr al computerului si un număr de
port pentru fiecare host. Pentru o mână de computere era usor de retinut adresele, dar atunci
când ARPANET a crescut, tehnica a devenit neutilizabilă. La începutul anulir ’70 inginerii
ARPA au dezvoltat un sistem de nume care era mai usor de utilizat decât adresele numerice.
S-a pornit cu atribuirea unui nume fiecărui dispozitiv din retea. Fiecare zonă din retea trebuia
să administreze propriul tabel de hosturi care continea corespondenta nume-adresă.
Primul sistem de nume ARPANET: Liste de nume.Imediat, inginerii ARPA si-au dat
seama de pericolul inconsistentei numelui generat de faptul fiecare zonă administra propriul
tabel de nume. De aceea, au stabilit (standardizat) în 1971 modul în care se vor atribui numele
în retea. S-a publicat o listă cu toate numele si adresele corespunzătoare existente în retea.
Acest sistem de nume era unul manual. De fiecare dată când de modifica un nume, sau apărea
unul nou, publica o nouă listă si fiecare administrator de zonă trebuia să-si actualizeze propria
listă. În această perioadă nu intra în discutie structura numelui, fiecare zonă având libertatea
de a da nume hosturilor sale. Au apărut imediat problemele: schema lucra foarte greu în ceea
ce priveste actualizarea situatiei retelei: schimbările se introduceau după ce se publica o nouă
listă. Chiar si cu o listă centralizată lucrurile nu mergeau mai bine, existând pericolul ca un
administrator să uite să actualizeze tabelele, sau să facă o modificare gresită.
Pasul următor l-a constituit memorarea numelor într-un fisier tabel de hosturi. S-a
creat un fisier text care era administrat central si care putea fi descărcat utilizând protocoale
de retea gen FTP. Fisierul era localizat la Network Information Center (NIC) din Stanford
University. Sistemul a fost mentinut si după aparitia TCP/IP, făcându-se maparea numelor cu
adresele IP de 32 de biti. Noua definire a tabelelor de hosturi (maparea cu adrese IP) a avut
loc în 1982.
Devenea tot mai evident faptul că acest sistem de nume bazat pe tabel va fi în curând
inutilizabil. Pentru o retea în continuă expansiune, mentinerea centralizată a unui tabel nu mai
era o solutie. Ideea trecerii pe un sistem de nume ierarhizat apăruse încă din 1981. Conceptul
era bazat pe domenii. Au fost multe discutii(1981-1983) până când conceptul a fost pus în
practică si s-a migrat de la sistemul de nume plat, bazat pe tabel la noul sistem Domain Name
System (DNS).

9.2 Domain Name System (DNS)

Cele trei funcţii de bază ale sistemului de nume, implementate de DNS sunt:

Page 11 of 29
 Figura 9.6: Funcţiile DNS

DNS utilizează un spaţiu al numelor ierarhizat constituit dintr-o singură structură

complexă, multinivel. Spaţiul numelor este organizat pornind de la o rădăcină în care sunt
plasate domeniile. Fiecare dintre ele poate conţine nume individuale de dispozitive sau sub-
domenii. Întreaga structură este asemănătoare sistemului de directoare în care este organizat
un calculator. Pentru a defini numele este utilizată o sintaxă specifică, iar pentru a descrie
părţi ale structurii şi a identifica numele domeniilor este utilizată o terminologie specială,
pornind de la rădăcină în jos până la nivelul dispozitivului.

Înregistrarea numelui
Înregistrarea numelui este utilizată pentru a introduce nume individuale într-o bază de
date DNS distribuită. DNS utilizează un aranjament ierarhizat al autorităţii, complementar
spaţiului ierarhizat al numelor. O autoritate centrală determină întreaga structură a spaţiului
numelor şi administrează înregistrarea numelor la nivel înalt. Autoritatea este apoi delegată la
diferite organizaţii pentru a administra diferite părţi ale spaţiului numelor. Procesul de
înregistrare, problemele şi conflictele sunt controlate de către un set universal de politici.

Rezoluţia numelui
DNS utilizează un mecanism de rezoluţie a numelui puternic, distribuit, de tip client-
server. Procesul de rezoluţie este implementat utilizând două elemente software de bază, care
joacă rolul de serever şi client, numite servere şi name resolvers.
Name servers
DNS name servers sunt programe speciale care rulează pe servere hardware care sunt
esenţa DNS. Serverele sunt menţinute de organizaţii care au un control administrativ asupra
unor părţi din spaţiul numelor şi conţin înregistrări de resurse (resource records) care descriu
nume, adrese şi alte caracteristici ale acelor porţiuni ale spaţiului numelor. Ca urmare,
serverele sunt organizate într-o ierarhie analoagă celei a spaţiului numelor. Principala sarcină

Page 12 of 29
a serverelor de nume este de a recepţiona cereri pentru rezoliţia numelor şi de a răspunde cu
datele cerute unei baye de date, sau cu numele unui alt server de nume care va conduce către
informaţia cerută. Serverele de nume sunt responsabile şi de datele din cache sau alte sarcini
administrative care asigură o operare eficientă a sistemului.
Name resolvers
Name resolvers sunt în mod uzual clienţi în procesul de rezoluţie a numelui. Când un
utilizator face referinţă la un nume într-o aplicaţie de reţea, numele este pasat resolverului
care va înainta o cerere către server. Funcţie de configurare, pot fi necesare mai multe cereri şi
vor fi combinate mai multe procese de rezoluţie diferite pentru a găsi informaţia dorită.

9.2.1. Arhitectura ierarhizată a numelor DNS

Conceptul esenţial al spaţiului numelor DNS este domeniul. Domeniul este înţeles ca
fiind o sferă de influenţă, o arie de control. O sferă de influenţă poate la rândul său să conţină
alte sfere mai mici, care la rândul lor pot conţine altele, şi aşa mai departe.
Aceasta arată faptul că domeniile sunt, în mod natural, organizate ierarhic,
arborescent. Comparaţia între elementele structurate şi arbori este uzuală în reţelistică.
Principala diferenţă dintre terminologia tehnică şi cea biologică este aceea că arborii DNS
cresc de sus în jos. Analogia cu arborii conduce la o terminologie specifică.
Rădăcină (Root): Acesta este conceptual vârful structurii nume DNS. Domeniul rădăcină în
DNS conţine întreaga structură. Perin definiţie, nu are un nume; este NULL.
Ramură (Branch): Braţul, ramura, reprezintă orice porţiune continuă din ierarhia DNS. El
constă dintr-un domeniu şi toate domeniile şi obiectele incluse în acesta. Toate ramurile sunt
conectate în rădăcină.
Frunză (Leaf): este un obiect de capăt, terminal în structură, care poate fi un domeniu care nu
mai are nimic sub el.
Nu există termen specific pentru domenii care nu sunt frunze. Uneori acestea sunt numite
noduri de interior, arătând că se află în mijlocul structurii. Un nod este termen generic pentru
un obiect dintr-o topologie sau structură. În DNS fiecare domeniu este un nod, care poate fi
fie de interior care conţine domenii sau –şi obiecte adiţionale, fie frunză fiind un nume de
dispozitiv.

9.2.1.1. Terminologia utilizată pentru a distinge domeniile în structura ierarhizată

A. Terminologie legată de noţiunea de arbore
Alţi termeni utilizaţi pentru a referi domenii din diferite niveluri ale ierarhiei:
Root Domain: este rădăcina arborelui
Top-Level Domains (TDLs): Sunt domenii de pe nivelul cel mai de sus, direct conectate la
rădăcină. Sunt numite uneori ca first-level domains.
Second-Level Domains: Sunt domenii localizate imediat sub domeniile de vîrf.
Subdomenii: În anumite contexte ele reprezintă domenii localizate direct sub domeniile de
nivel secund.

Page 13 of 29
 Figura 9.7: Arborele spatiului numelor DNS si terminologia folosită

Vîrful spaţiului numelor DNS este rădăcina şi nu are un nume. Zona colorată reprezintă o
ramură. Ramura conţine mai multe subramuri. Nodurile verzi reprezintă noduri frunză.

B. Terminologie legată de noţiunea de familie

Alt set de terminologie compară structura ierarhizată a DNS cu arborele familiei. Astfel sunt
descrise relaţiile dintre domenii.
Domeniul părinte: Este domeniul care se găseşte deasupra în ierarhie. De exemplu, rădăcina
arborelui este părintele tuturor domeniilor de vârf.
Copil: Domeniu aflat sub primul din ierarhie; Astfel TLD-urile sunt copii ai rădăcinii.
Fraţi (sibling): Egalul unui anumit nivel, având acelaşi părinte. Astfel domeniile de vârf sunt
fraţi având rădăcina drept părinte; toate domeniile de nivel secund dintr-un TDL particular
sunt fraţi.

Page 14 of 29
 Figura 9.8: DNS Name Space “Family Tree”
Diagrama este similară celei din Figura 9.7, dar nodurile sunt reprezentate prin terminologia
orientată pe familie.

9.2.1.2. Restricţii în structura arborelui DNS

Orice domeniu are un singur părinte (cu excepţia rădăcinii); fiecare ramură a arborelui
este conectată la un singur membru. Ca urmare, nu pot apărea bucle, nu pot apărea domenii
care al căror copil este şi părintele său. Trebuie înţeles că ierarhia de nume reprezintă o
structură logică, nefiind necesară o corespondenţă cu locaţia fizică a dispozitivelor. Un
domeniu cu zece copii poate reprezenta 11 dispozitive aflate în 11 ţări diferite.

9.2.1.3. DNS Etichete, nume şi reguli sintactice

Ierarhia spaţiului numelor DNS permite aranjarea domeniilor într-un arbore virtual
care reflectă caracteristicile după care dispozitivele sunt organizate. Numirea în DNS porneşte
de la atribuirea fiecărui domeniu câte unei etichete text în spaţiul numelor DNS. Eticheta
identifică domemiul în cadrul structurii şi trebuie să îndeplinească următoarele reguli
sintactice:
Lungimea: Teoretic, fiecare etichetă poate avea între 0 şi 63 caractere. În practică, lungimea
este între 1 şi 20, cu excepţia etichetei atribuită rădăcinii.
Simboluri: Sunt permise litere şi numere, precum şi simbolul liniuţă de unire(“-“). Nu este
permis nuci un semn de punctuaţie, inclusiv underscore (“_”).
Caz: Etichetele nu sunt case-sensitive.
Fiecare etichetă trebuie să fie unică în domeniul său părinte. De exemplu, dacă avem un
părinte rocă, nu putem avea decât un singur copil cristal. Datorită insensibilităţii cazului, în
interiorul rocii nu putem avea CRISTAL şi cristal, ele fiind considerate unul şi acelaşi
domeniu. Conceptul unicităţii locale la nivelul unui părinte asigură unicitatea numelui. Astfel,
Page 15 of 29
dacă avem un domeniu sticlă, putem crea în interiorul lui un subdomeniu cristal, neexistând
conflict deoarece domeniile rocă şi sticlă sunt separate.

9.2.1.4. Construirea numelor domeniilor pornind de la etichetele domeniilor.

Numele rădăcinii este un nume de lungime zero, implicit null. Eticheta rădăcinii
există, dar este vidă. Ca o justificare este faptul că rădăcina este parte a fiecărui domeniu de
nume. Ea trebuie inclusă în fiecare nume de domeniu. Includerea unui nume pentru rădăcină
nu ar avea alt efect decât lungirea numelui, neaducând nici o informaţie suplimentară.
Luând exemplul anterior, un TLD numit “rocă” cu un nivel secund “cristal”. Numele
domeniului “rocă” este “rocă.”, cu un punct separând “rocă” şi “ ” (spaţiul null pentru
rădăcină). În practică punctul de sfârşit se omite, astfel că numele domeniului ”rocă” este
considerat simplu ”rocă”. Subdomeniul ”cristal” din ”rocă” va avea numele de domeniu
”cristal.rocă”. Dacă avem un dispozitiv numit ”sare” în domeniul ”cristal.rocă”, acesta se va
numi ”sare.cristal.rocă”.

Figura 9.9: Construirea Etichetelor DNS şi a Domeniului Numelor

Fiecare nod are o etichetă în spaţiul numelor DNS (cu excepţia rădăcinii, care are eticheta
null). Domeniul numelui pentru un nod se construieşte prin simpla punere în ordine a
etichetelor de la vârful arborelui în jos înspre domeniul individual, mergând de la dreapta la
stânga, separând fiecare etichetă prin punct.

Page 16 of 29
9.2.1.5. Fully qualified domain names (FQDNs)

Considerăm o structură internă tipică a unei organizatii mari. Deoarece seful executiv nu
poate face singur totul, organizatia este partitionată în divizii, fiecare dintre acestea având
autonomie în anumite limite. eful diviziei este împuternicit cu autoritatea de a lua direct
decizii fără a cere permisiunea sefului executiv. Numele domeniului este format într-un mod
similar si reflectă delegarea ierarhică a autoritătii în repartizarea lor. De exemplu, considerăm
numele myHost.myDept.myDiv.myCorp.com.

Fie următoarea ierarhie de domenii:

Figura 9.10: Exemplu de ierarhie de nume

Atunci când lucrăm cu un sistem de nume, în mod obisnuit utilizăm numai o parte din
ierarhia de domenii, de exemplu myDivision.myCorp.com. DNS oferă o metodă simplă de a
minimiza introducerea de date necesare în acest caz. Dacă numele domeniului se termină în
punct, de exemplu myDept.myDiv.myCorp.com., se presupune că este complet. Acesta se
numeste fully qualified domain name (FQDN) sau absolute domain name. Dacă nu se termină
cu un punct, de exemplu myDept.myDiv, numele este incomplet, iar resolverul DNS va trebui

Page 17 of 29
să îl completeze prin alipirea unui sufix .myCorp.com la numele domeniului. Regulile după
care se face acest lucru sunt functie de implementare si de configurarea locală.

9.2.1.6. Domenii generice

Numele de nivel de vârf (TLD) au o lungime de 3 sau mai multe caractere. Câteva
dintre numele generice de domenii utilizate în Internet sunt:

Tabelul 9.1: Nume generice de domenii

9.2.1.7. Domenii de tară

Tot de nivel de vârf sunt domeniile notate cu câte două litere, conform codurilor de
tară prezente în ISO 3166. Acestea se numesc domenii de tară (country domains) sau domenii
geografice (geographical domains). Multe tări au propriul nivel secund, în paralel cu

Page 18 of 29
domeniile nivelului de vârf generic. De exemplu, în Marea Britanie domeniile echivalente
domeniilor generice .com si .edu sunt .co.uk si .ac.uk, ac fiind o abreviere de la academic.

9.2.2. Rezolutia numelui DNS

Procesul de rezolutie poate fi descris pe scurt prin următorii pasi:

1. Un program al utilizatorului înaintează o cerere (către sistem) de tip gethostbyname(),

prin care cere adresa IP dând numele, sau gethostname(), prin care cere numele unui
dispozitiv oferind adresa IP.
2. Resolver-ul formulează o cerere către name server. Există full resolver-i care mai întâi
consultă o memorie cache locală.
3. Name server-ul verifică dacă răspunsul este în baza sa de date; dacă da, oferă
răspunsul clientului. Dacă nu poate oferi informatia, interoghează alte servere de
nume, mergând pe arborele DNS.
4. Programului utilizator i se oferă adresa IP (sau numele) cerută sau un mesaj de eroare
dacă cererea nu a putut fi solutionată.

Rezolutia numelui este un proces client/server. Functia client (numită resolver sau name
resolver) este transparentă pentru utilizator si este apelată printr-o aplicatie pentru a translata
nume simbolice de nivel înalt în adrese IP si invers. Name server (numit si domain name
server) este o aplicatie server care furnizează translatarea dintre numele de nivel înalt si
adrese IP. Mesajele cerere/răspuns pot fi transportate fie de UDP, fie de TCP.

9.2.2.1. Domain name full resolver

Programul numit full resolver, distinct de programul utilizatorului, transmite toate
cererile către serverul de nume pentru a fi procesate. Răspunsurile sunt înscrise de către server
în cache pentru a fi utilizate si mai târziu. i resolver-ul înscrie răspunsul într-un cache
propriu.

Figura 9.11: Modul de actiune al unui domain name full resolver

Page 19 of 29
9.2.2.2. Domain name stub resolver
Este o rutină care este conectată la programul utilizatorului, care transmite cererile
către serverul de nume pentru a fi procesată. Răspunsurile sunt memorate de către server în
csche, dar nu si de resolver. În majoritatea platformelor, stub resolver-ul este implementat de
două functii: gethostbyname() si gethostbyaddr(). Acestea sunt utilizate pentru a converti
numele în adrese IP si invers. Stub resolvers sunt mult mai obisnuiti decât full resolvers.

Figura 9.12: Modul de actiune al unui domain name stub resolver

9.2.2.3. Modul de operare a resolver-ului

O cerere de nume poate fi de două tipuri: recursive sau iterative (non-recursive). Un
bit indicator din cererea de nume specifică dacă clientul doreste o interogare recursivă, iar un
bit indicator din răspuns specifică dacă serverul suportă interogări recursive. Diferenta dintre
interogare recursivă si iterativă apare când serverul primeste o cerere pentru care nu poate
oferi un răspuns complet. O cerere recursivă impune serverului să înainteze la rândul său o
cerere mai departe pe arborele DNS pentru a obtine informatia si returnează răspunsul
complet clientului. Dacă cererea este iterativă, serverul returnează informatia care îi este
disponibilă si o lista cu servere pe care clientul le poate apela pentru a-si completa informatia.
Răspunsurile pot fi de două feluri: autorizat si non-autorizat. Un bit indicator din răspuns
indică ce fel de răspuns este. Când un server primeste o cerere pentru un domeniu situat în
zona sa de autoritate, el returnează un răspuns autorizat. Când primeste o cerere pentru un
domeniu peste care nu are autoritate, va opera functie de setarea bitului de recursivitate din
cerere:
- Dacă se cere recursivitate si serverul suportă recursivitate, el va interoga direct un alt
server. Acesta poate fi chiar un server care are autoritate asupra domeniului din cerere,
sau un server rădăcină. Dacă al doilea server nu poate da un răspuns autorizat,
procesul se repetă.
- Când un server (sau un program full resolver) receptionează un răspuns, îl va înscrie în
cache pentru a îmbunătăti performantele sistemului la cereri repetate. Informatia

Page 20 of 29
 memorată în cache este mentinută un interval de timp specificat în răspuns printr-un
câmp de 32 de biti, numit timp de viată (time-to-live-TTL); Tipic acest câmp este setat
la valoarea 86.400 secunde (o zi).
- Dacă nu se cere recursivitate sau dacă serverul nu este capabil să servească cereri
recursive, el va returna informatia disponibilă în cache, precum si o listă cu servere
care pot da informatii autorizate.

9.2.2.4. Modul de operare a serverelor de nume.

Fiecare server de nume are autoritate pentru zero sau mai multe zone. Sunt trei tipuri
de servere:
Primar: Este un server care are informatiile privind zona pe un disc si are bautoritate asupra
acelei zone.
Secundar: Un server secundar are autoritate asupra unei zone, dar obtine informatii despre
aceasta de la un server primar prin procesul numit zone transfer. Pentru a se sincroniza,
serverele secundare interoghează serverele primare în mod regulat (de regulă la trei ore) si
reexecută transferul zonal dacă serverul primar a fost actualizat. Un server poate functiona ca
primar sau secundar pentru mai multe domenii, sau primar pentru unele si secundar pentru
altele. Un server primar sau secundar realizează toate functiile unui server de tip caching-
only.
Caching-only: Este un server care nu are autoritate asupra nici unei zone. El obtine toate
datele de la servere primare sau secundare. El trebuie să detină cel putin adresa unui server de
nume de la care să poată obtine o informatie initială.

9.2.2.5. Memorarea de resurse DNS

Baza de date distribuită a DNS este compusă din înregistrări de resurse (resource
records), care sunt divizate în clase pentru diferite tipuri de retele. Discitia o vom face numai
pentru clasa Internet. Resursele înregistrate oferă o mapare între domeniile de nume si
obiectele din retea. Cel mai adesea, obiectele sunt adrese ale hosturilor, dar DNS a fost
proiectat să dispună de o largo varietate de obiecte.
O zonă constă dintr-un grup de resurse înregistrate, pornind cu înregistrare Start of
Authority (SOA). SOA identifică numele de domeniu al zonei. Mai există si un nume de
server al unui server primar pentru acea zonă. Pot exista si nume de servere secundare. Aceste
nume de servere sunt utilizate pentru a identifica serverele care sunt autorizate. După aceste
înregistrări sunt înregistrările de resurse care vor asocia adrese IP numelor de obiecte.
Formatul unui înregistrări de resurse este următorul:

Page 21 of 29
 Figura 9.13: Formatul unui înregistrări de resurse

Unde:
Nume: numele domeniului care trebuie definit.
Tipul: tipul resursei din această înregistrare. Sunt numeroase valori posibile (nume de host,
nume de server autorizat, membru al unui grup de mail, resursă ISDN, resursă X.25, cheie de
codare, etc).

Tabelul 9.2: Câteva tipuri posibile de înregistrări de resurse

Page 22 of 29
Clasa: Identifică familia de protocoale. În mod normal valoarea utilizată este IN (sistem
Internet).
TTL: Timpul de viată în secunde cât înregistrarea este validă în memoria cache. Este o
valoare de 32 de biti fără semn, tipic setată la 86.400, adică o zi.
RDlength: un întreg de 16 biti fără semn care specifică lungimea în octeti a câmpului Rdata.
RData: Un sir de octeti de lungime variabilă care descrie resursa.

9.2.2.6. Mesaje DNS

Toate mesajele protocolului DNS utilizează un singur format. Acest format este dat în
Figura 9.14. Acest cadru este transmis de către resolver către serverul de nume. Numai antetul
si sectiunea de interogare sunt utilizate pentru a forma o cerere. Răspunsurile si transmiterea
mai departe a cererii utilizează aceeasi formă, dar completează mai multe sectiuni
(răspuns/autoritate/sectiuni aditionale).

Page 23 of 29
 Figura 9.14: Formatul mesajelor protocolului DNS

Formatul antetului
Antetul este sectiunea întotdeauna prezentă si are o lungime fixă de 12 octeti. Alte sectiuni
sunt de lungime variabilă.
ID: un identificator de 16 biti atribuit de program. Acest identificator este copiat în răspunsul
corespunzător dat de serverul de nume si poate fi utilizat pentru a face diferenta dintre
răspunsurile la mai multe cereri aflate în rezolvare.
Parametrii: o valoare de 16 biti având următorul format:

Unde:
QR: Flag identificator pentru cerere (0) sau răspuns (1).
Op code: câmp de 4 biti care specifică tipul cererii:
0 cerere standard(QUERY)
1 cerere inversă (IQUERY)
2 interogare a stării serverului (STATUS)
AA: Indicator de răspuns autorizat. Dacă este 1 atunci semnifică faptul că serverul care a
transmis răspunsul este autorizat pentru domeniul din cerere.
TC: indicator de trunchiere. 1 dacă mesajul este mai lung decât permite canalul fizic.
RD: Indicator de recursivitate. Acest bit semnalează serverului că se cere o rezolutie
recursivă. Acest bit se va copia în răspuns.
RA: Indicator de disponibilitate a recursivitătii. Indică dacă serverul suportă sau nu
recursivitatea.

Page 24 of 29
Zero: 3 biti rezervati pentru utilizări ulterioare. Sunt pozitionati în 0.
Rcode: cod de răspuns de 4 biti. Valori posibile:
0 fără erori
1 eroare de format; serverul nu a fost capabil să interpreteze mesajul.
2 Defectiune de server. Mesajul nu a fost procesat din cauza unei probleme de
server.
3 Eroare de nume. Numele domeniului din cerere nu există. Este valid numai
dacă bitul AA este setat în răspuns.
4 Nu este implementat. Tipul cerut în cerere nu este implementat în serverul de
nume.
5 Refuz. Serverul refuză să răspundă dun motive de politică. Alte valori sunt
rezervate pentru folosintă ulterioară.
QDcount: un întreg fără semn de 16 biti specificând numărul intrării din sectiunea întrebare.
ANcount: un întreg fără semn de 16 biti specificând numărul RR în sectiunea răspuns.
NScount: un întreg fără semn de 16 biti specificând numărul serverului RR în sectiunea
autoritate.
ARcount: un întreg fără semn de 16 biti specificând numărul RR în câmpul înregistrări
aditionale.

Sectiunea întrebare
Următoarea sectiune contine cererile către serverul de nume. Ea contine QDcount
(uzual 1) intrări, fiecare în formatul arătat în Figura 9.15

Figura 9.15: Formatul sectiunii întrebare

Unde:
Lungime Un octet care specifică lungimea etichetei următoare.
Eticheta Un element din caracterele numelui domeniului (de exemplu ibm din
ral.ibm.com). Numele domeniului referit în cerere este memorat ca o serie de astfel de
etichete de lungimi variabile, fiecare precedat de un octet lungime.
00 X’00’ indică sfârsitul numelui de domeniu si reprezintă eticheta null a domeniului
rădăcină.

Page 25 of 29
Tip 2 octeti specificând tipul cererii. Poate avea orice valoare din câmpul Type al unei
înregistrări de resursă.
Clasa 2 octeti specificând clasa cererii. Pentru cerere Internet, va fi IN.

De exemplu, numele de domeniu mydiv.mycorp.com este codificat cu următoarele

câmpuri:
X'05' "mydiv" X'06' "mycorp" X'03' "com" X'00'
Astfel, intrarea din sectiunea întrebare pentru mydiv.mycorp.com necesită 22 octeti, 18
pentru a stoca numele domeniului si câte 2 pentru câmpurile Qtype si Qclass.

Sectiunile răspuns, autoritate si resurse aditionale.

Aceste trei sectiuni contin un număr variabil de înregistrări de resurse. Numărul este
specificat în câmpul corespunzător din antet. Înregistrările de resurse au următorul format
(Figura 9.16):

Figura 9.16: Formatul înregistrărilor de resurse DNS

Unde câmpurile din fata câmpului TTL au aceeasi semnificatie ca si pentru o interogare, iar:
TTL O valoare de 32 de biti reprezentând durata de viată a înregistrării. Definiste durata cât
această înregistrare poate fi privită ca validă.
RDlength Lungime pe 16 biti a câmpului Rdata.
Rdata Un sir de lungime variabilă a cărui interpretare depinde de câmpul Type.

9.2.3. Transportul
Mesajele DNS sunt transmise fie ca datagrame (UDP), fie ca stream-uri (TCP):
- UDP: utilizează server port 53. Mesajele transportate prin UDP sunt limitate la 521
octeti. Mesajele mai lungi sunt trunchiate, iar bitul de trunchiere TC din antet se
setează. Deoarece cadrele UDP pot fi pierdute, este necesară o strategie de
retransmisie.

Page 26 of 29
 - TCP: utilizează server port 53. În acest caz mesajul este precedat de un câmp de 2
octeti indicând lungimea totală a mesajului.

X.3 Dynamic Domain Name System

DNS este o implementare statică, fără nici o preocupare privind securitatea. Pentru a
implementa DNS dinamic, luând avantajele DHCP si mentinând posibilitatea de localizare a
oricărui host cu ajutorul unei etichete, sunt necesare următoarele extensii ale DNS:
- O metodă prin care un nume de host să impună ca o intrare a unui client (reprezentând
o mapare nume-adresă) din serverul de nume de domenii să fie actualizată după ce
clientul obtine o adresă de la un server DHCP.
- O metodă prin care se face o mapare adresă-nume host după ce un client a obtinut
adresa.
- Actualizările DNS să fie imediate, fără a fi necesară interventia unui administrator.
- Actualizările DNS să fie autentificate, pentru a împiedica hosturi neautorizate să
acceseze reteaua si pentru a împiedica impostorii să utilizeze nume de hosturi
existente pentru a le mapa la propria adresă
- O metodă prin care serverele primare si secundare să transmită si să receptioneze rapid
intrările modificate ca urmare a actualizării dinamice de către clienti.

Implementarea DDNS poate introduce probleme în cazul în care mediul nu este sigur. O
metodă de securitate utilizată de DDNS este utilizarea Secret Key Transaction Authentication
(TSIG). Aceasta poate fi utilizată pentru a autentifica actualizările dinamice de la clienti, sau
pentru a autentifica răspunsurile recursive provenite de la server. În plus, mesajele pot fi
protejate pentru integritate si confidentialitate utilizând TSIG peste Generic Security service
(GSS-TSIG).

9.3.1. Actualizarea dinamică în DDNS

Formatul mesajului DNS (Figura ...anterioara) a fost proiectat pentru interogarea statică
a unei baze de date. Au fost făcute modificări pentru a face actualizări, rezultând mesaje
numite UPDATE DNS, ilustrate în Figura 9.y. Aceste mesaje adaugă sau elimină înregistrări
de resurse DNS, permit actualizărilor să devină efective fără a fi necesară o reîncărcare a
DNS.

Page 27 of 29
 Figura 9.17: Formatul mesajului DDNS UPDATE

Sectiunea antet este întotdeauna prezentă si are o lungime fixă de 12 octeti. Celelalte
sectiuni au lungime variabilă. Ele sunt:
Identificare Identificator de 16 biti atribuit de către program. Este copiat în
răspunsul corespunzător al serverului de nume si poate fi utilizat pentru a distinge între
mai multe răspunsuri care sunt asteptate la un moment dat.
Q Indicator de cerere de actualizare (0) sau răspuns (1)
Op Opcode. Valoarea 5 indică un mesaj update.
z Câmp de 7 biti setat în 0 si rezervat pentru utilizări ulterioare.
R Codul răspunsului (nedefinit în cererile de actualizare). Posibile valori:
0 nu sunt erori
1 Eroare de format. Serverul nu a fost capabil să interpreteze mesajul.
2 Defectiune la nivelul serverului. Mesajul nu a fost procesat din cauza
unei probleme la nivelul serverului.
3 Eroare de nume. Numele specificat nu există.
4 Nu este implementat. Tipul mesajului specificat în Opcode nu este
suportat de acest server.
5 Refuz. Serverul refuză să facă actualizarea din motive de politică de
securitate.
6 Eroare de nume. Numele există si nu ar trebui să existe.
7 Eroare RRset. Setarea unei inregistrări de resursă (resource record set)
specificate care există si nu ar trebui.
8 Eroare RRset. Setarea unei inregistrări de resursă (resource record set)
specificate care nu există.
9 Eroare de zonă de autoritate. Serverul nu este autorizat pentru o anumită
zonă.
10 Eroare de zonă. Numele specificat în cererea de actualizare nu face
parte din acea zonă.
ZO count Numărul RRs (înregistrărilor de resurse) în sectiunea Zone.
PR count Numărul RRs (înregistrărilor de resurse) în sectiunea Prerequisite.
UP count Numărul RRs (înregistrărilor de resurse) în sectiuneaUpdate.
AD count Numărul RRs (înregistrărilor de resurse) în sectiunea informatii
suplimentare (Additional information).
Zone Această sectiune este utilizată pentru a indica zona înregistrărilor care
trebuie actualizate. Cum toate înregistrările care trebuie actualizate trebuie să apartină
aceleeasi zone, sectiunea zonă are o singură intrare specificând numele zonei, tipul zonei
si clasa zonei.
Prerequisite Această sectiune contine RRs sau RRsets care fie trebuie, fie nu trebuie
să existe, functie de tipul actualizării.
Update Sectiunea contine RRs, RRsets, sau ambele, care trebuie fie adăugate,
fie eliminate din zonă.
Additional information Sectiunea poate fi utilizată pentru a introduce RRs suplimentare
într-un proces de actualizare aflat în desfăsurare.

9.3.2. Transferul incremental de zonă în DDNS

A fost introdus un tip de mesaj IXFR DNS care permite transferuri incrementale ale
datelor de zonă DNS între servere primare si secundare.Cu alte cuvinte, când are loc o

Page 28 of 29
 actualizare în datele unei zone, numai acele modificări vor fi copiate în alte servere DNS
care mentin o copie a datelor zonei, nu se va copia întreaga bază de date (asa cum se
întâmpla în cazul unui mesaj de tip AXFR DNS.
Formatul unei cereri IXFR este exact acelasi cu cel al unei cereri DNS obisnuite, dar cu
tipul cererii setat IXFR. Sectiunea answer a răspunsului va fi compusă din secvente
diferentă (difference sequences).
Fiecare listă de secvente diferentă este precedată de versiunea curentă a SOA a serverului
si reprezintă o actualizare a zonei. Similar, fiecare secventă diferentă este precedată de o
versiune SOA (indicând în ce versiune se face actualizarea), secventele diferentă fiind
ordonate de la cea mai veche la cea mai nouă. După receptionarea mesajului, serverul
poate face actualizarea urmărind istoria versiunii listată în sectiunea answer a IFXR.
De exemplu, presupunem că un server are următoarea zonă:

MYZONE.MYDIV.MYCORP IN SOA MYHOST.MYDIV.MYCORP

(1 600 600 3600000 614800)
IN NS MYHOST.MYDIV.MYCORP
MYHOST.MYDIV.MYCORP IN A 10.1.2.3
OTHERHOST.MYDIV.MYCORP IN A 10.2.3.4

Otherhost.mydiv.mycorp este îndepărtat, si în versiunea 2, thishost.mydiv.mycorp este

adăugat,lăsând zona de forma:

MYZONE.MYDIV.MYCORP IN SOA MYHOST.MYDIV.MYCORP

(2 600 600 3600000 614800)
IN NS MYHOST.MYDIV.MYCORP
MYHOST.MYDIV.MYCORP IN A 10.1.2.3
THISHOST.MYDIV.MYCORP IN A 10.2.3.5

Dacă serverul primeste o cerere IXFR, va trimite ca răspuns următoarea sectiune answer:

MYZONE.MYDIV.MYCORP IN SOA serial=2

MYZONE.MYDIV.MYCORP IN SOA serial=1
OTHERHOST.MYDIV.MYCORP IN A 10.1.2.4
MYZONE.MYDIV.MYCORP IN SOA serial=2
THISHOST.MYDIV.MYCORP IN A 10.2.3.5
MYZONE.MYDIV.MYCORP IN SOA serial=2

Page 29 of 29
 CURS 11
Protocoale referitoare la fişiere
Suita de protocoale TCP/IP oferă un număr de protocoale pentru manipularea fişierelor. În
general sunt două mecanisme diferite pentru accesarea la distanţp a fişierelor. Cel mai simplu
mecanism este transferarea unui fişier pe o maşină locală. În acest caz vor exista mai multe
copii ale aceluiaşi fişier. Pentru distribuirea fişierelor se vor folosi mecanismele File Transfer
Protocol (FTP), Trivial File Transfer Protocol (TFTP), Secure Copy Protocol (SCP).

Alternativa acestor metode este utilizarea unui sistem de fişiere. În acest caz, maşina locală
oferă toate funcţiile necesare accesării fişierului pe maşina distantă. Userul şi aplicaţia de pe
maşina locală nu simt că fişierul este rezident pe o maşină distantă; ei citesc şi scriu fişierul ca
şi când acesta ar fi local. În acest caz există o singură copie a fişierului, iar sistemul de fişiere
este responsabul de coordonarea actualizării lui. Acest tip de funcţionalitate este furnizat de
Network File System (NFS), Andrew File System (AFS) şi Common Internet File System
(CIFS).

11.1 File Transfer Protocol (FTP)

Transferarea datelor de la un host la altul este una dintre cele mai frecvente operaţii. Atât
necesitatea de a actualiza datele (transmiterea datelor de la un client la un server), cât şi de a
descărca date (recepţionarea datelor de la un server către un client) sunt realizate cu ajutprul
FTP. Suplimentar, FTP poate oferi măsuri de securitate şi autentificare pentru a preveni
accesul neautorizat la date.

11.1.1. Privire de ansamblu asupra FTP

FTP utilizează protocolul de transport TCP pentru a furniza conexiuni cap-la-cap de încredere
şi implementează două tipuri de conexiuni în administrarea transferului de date. Clientul FTP
iniţiază prima conexiune, referită drept conexiune de control, către portul 21. Acesta este
portul pe care serverele FTP aşteaptă şi acceptă conexiuni noi. Conexiunea de control este
utilizată pentru toate comenzile pe care le lansează clientul cu scopul de a se conecta la server,
de a manipula fişiere şi de a încheia sesiunea. Tot pe această conexiune serverul va transmite
mesaje de răspuns pentru comenzile de control.

A doua conexiune utilizată de FTP se referă la conexiunea de date. Tipic, conexiunea de date
se stabileşte pe portul 20, dar, funcţie de cum se stabileşte conexiunea, atât clientul, cât şi
serverul, pot folosi alte porturi. FTP deschide conexiunea se date numai în cazul în care
clientul doreşte să descarce un fişier sau doreşte o listă a fişierelor disponibile. Este totuşi
posibil ca o sesiune FTP să înceapă şi să se încheie fără a deschide vreodată o conexiune de
date. Spre deosebire de conexiunea de control, în care comenzile şi răspunsurile merg de la
client la server şi invers, conexiunea de date este unidirecţională. FTP poate transfera date
numai de la client la server, sau numai de la server la client. Conexiunea de date, spre
deosebire de conexiunea de control, poate fi iniţiată fie de client, fie de server. Dacă este
iniţiată de client este pasivă, iar dacă este iniţiată de server este activă.

Page 1 of 12
Aplicaţia client FTP este construită cu un interpretor de protocol (protocol interpreter-PI), un
proces de transfer de date (data transfer process-DTP) şi o interfaţă utilizator. Aplicaţia server
FTP constă în mod tipic numai din PI şi DTP Figura 11.1).

Figura 11.1: Modelul FTP

Interfaţa utilizator a clientului comunică cu interpretorul de protocol, care administrează

conexiunea de control. Interpretorul de protocol translatează orice comandă specifică
aplicaţiei la o comandă FTP şi apoi comunică comenzile de control serverului FTP.

Interpretorul de protocol al serverului FTP recepţionează aceste comenzi şi iniţiază procesul

de servire a cererilor clientului. Dacă cererile implică un transfer de date, administrarea
datelor se va realiza de către DTP-urile aplicaţiile client şi server. După terminarea
transferului de date, conexiunea de date este închisă şi controlul este preluat de către PI-urile
client şi server.

Important: Pe fiecare conexiune de date nu se poate face decât un singur transfer de date.
Pentru transferuri multiple de date, cerute într-o singură sesiune FTP, se va deschide câte o
conexiune de control distinctă pentru fiecare transfer.

11.1.2 Operaţiile FTP

Când foloseşte FTP, utilizatorul realizează unele sau toate dintre următoarele operaţii:

- conectare la un host distant,

- navigare şi manipulare printr-o structură de directoare,
- listează fişierele disponibile pentru transfer,
- defineşte modul de transfer, tipul transferului şi structura de date,
- transferă date la şi de la un host distant,
- deconectare de la hostul distant.

Conectarea la un host distant

Page 2 of 12
 Pentru a executa un transfer de fişier, utilizatorul începe prin a accesa un host distant.
Aceasta este o metodă primară prin care este implementată securitatea în modelul FTP. Pasul
de autentificare poate fi evitat utilizând anonymous FTP.

Se pot utiliza patru comenzi:

open Selectează hostul distant şi iniţiază sesiunea de conectare (login sesion).

User Identifică utilizatorul distant.

Pass Autentifică utilizatorul.

Site Transmite informaţii către hostul extern, necesare pentru a furniza serviciile
specifice hostului respectiv.

Navigarea prin structura de directoare

După ce utilizatorul a fost autentificat şi s-a conectat la server, el poate naviga prin structura
de directoare a hostului distant în scopul localizării fişierului dorit, sau pentru a localiza
directorul în care va fi transferat un fişier local. Utilizatorul poate naviga şi în structura de
directoare a clientului. După ce au fost accesate directoarele locale şi distante, utilizatorul
poate vizualiza conţinutul directoarelor. Subcomenzile care realizează aceste funcţii sunt:

cd Schimbă directorul pe hostul distant. Poate fi specificată o cale care trebuie

însă să fie conformă cu structura de directoare a hostului distant. În cele mai multe
implementări cd.. va accesa un director aflat pe nivelul superior în structura de directoare.

Lcd Schimbă directorul pe hostul local. Similar cu cd, poate fi specificată o cale
care trebuie însă să fie conformă cu structura de directoare a hostului local.

Ls Listează conţinutul directorului distant. Lista generată de această comandă este

tratată ca “date”, de aceea această comandă cere utilizarea unei conexiuni de date. Această
comandă are intenţia de a crea un rezultat “citibil” de operatorul uman.

Dir Listează conţinutul directorului distant. Ca şi pentru comanda ls, lista generată
de această comandă este tratată ca “date”, de aceea cere utilizarea unei conexiuni de date.
Această comandă are intenţia de a crea un rezultat “citibil” de programe.

Controlul transferului de date

Transferul datelor între sisteme necesită uneori transformări ale datelor ca parte a procesului
de transfer. Utilizatorul poate decide în trei aspecte în ceea ce priveşte manevrarea datelor:

- Calea prin care vor fi mutaţi biţii dintr-un loc în altul.

- Reprezentări diferite ale datelor în arhitectura sistemului.
- Structura fişierului în care vor fi memorate datele.

Fiecare dintre aceste aspecte este controlat de o subcomandă:

mode Specifică dacă fişierul este tratat ca având o structură într-un flux de octeţi:

Page 3 of 12
 B Specifică faptul că va fi utilizat un bloc. Indică faptul că frontierele logice
ale înregistrării fişierului sunt păstrate.

S Specifică faptul că este utilizat modul flux (stream), adică fişierul este tratat
ca un flux de octeţi. Acest mod este implicit şi oferă cel mai eficient
transfer, dar poate să nu producă rezultatele dorite când se lucrează cu un
sistem de fişiere structurat (record-based).

Type Specifică seturile de caractere utilizate în translatarea şi reprezentarea datelor:

A Indică faptul că ambele hosturi se bazează pe reprezentare ASCII, sau dacă

unul se bazează pe codul ASCII şi altul pe codul EBCDIC, se va realiza
translaţia ASCII-EBCDIC. În multe implementări comanda poate fi
invocată folosind comanda ASCII, care va fi transformată de către PI în
comanda type A.

E Indică faptul că ambele hosturi utilizează codul EBCDIC de reprezentare a

datelor. În multe implementări comanda poate fi invocată folosind comanda
EBCDIC, care va fi transformată de către PI în comanda type E.

I Indică faptul că nu se va face nici o translaţie asupra datelor. În multe

implementări modul poate fi invocat cu ajutorul comenzii BINARY care va
fi tradusă de către PI în comanda type I.

Structure Specifică structura fişierului care va fi transferat:

file Indică faptul că fişierul nu are o structură internă şi este considerat ca fiind o
secvenţă continuă de octeţi.

Record Indică faptul că fişierul este realizat dintr-o succesiune de înregistrări.

Page Indică faprul că fiţierul conţine pagini independente indexate.

Transferul fişierelor

Pentru a copia fişiere între clienţi şi servere FTP, se utilizează următoarele comenzi:

get Copiază un fişier de pe un host distant pe unul local. PI translatează comanda get
în comanda RETR.
Mget Copiază mai multe fişiere de pe un host distant pe cel local. PI translatează
comanda mget în mai multe comenzi RETR.
Put Copiază un fişier de pe hostul local pe hostul distant. PI translatează put în
comanda STOR.
Mput Copiază mai multe fişiere de pe hostul local pe hostul distant. PI translatează
mput într-o serie de comenzi STOR.

Încheierea unei sesiuni FTP

Pentru a încheia sesiunea FTP se utilizează comenzile:

Page 4 of 12
 quit Se deconectează de la hostul distant şi termină FTP. Unele implementări
utilizează subcomanda BYE.

CloseDeconectează de la hostul distant, dar lasă clientul FTP pornit. O comandă open
va stabili o nouă conexiune de control.

Un exemplu de scenariu FTP

Un utilizator LAN are de transferat date de pe o staţie workstation pe un host distant remote
host. Datele sunt binare şi există într-un fişier numit mydata din directorul de pe workstation
/localfolder. Utilizatorul doreşte să transfere datele utilizând modul stream (flux) în directorul
de pe hostul distant numit /tmp, dorind ca noul fişier să se numească yourdata. Procesul care
are loc pentru a realiza aceste obiective este ilustrat în Figura 11.2.

Figura 11.2: Exemplu de transfer FTP.

11.1.3 Transferul activ de date

Când se utilizează comenzile get, put, mget, mput, ls sau dir, FTP deschide o conexiune de
date prin care vor fi transferate datele. Majoritatea implementărilor folosesc transferul activ ca
variantă implicită în cazul în care nu este specificat că se doreşte un transfer pasiv. În
transferul activ clientul transmite serverului o comandă PORT, indicând adresa IP şi numărul
portului pe care clientul va aştepta conexiunea. După acceptarea comenzii PORT, serverul
FTP iniţiază o conexiune inversă către client folosind adresa IP şi portul indicate. După ce s-a
stabilit conexiunea, datele o vor parcurge, fie de la client spre server (pentru comenzile put

Page 5 of 12
sau mput), fie de la server la client (pentru comenzile get, mget, ls şi dir). Un exemplu de
astfel de secvenţă este prezentat în Figura 11.3.

Figura 11.3 Conexiune de date activă

11.1.4 Transferul pasiv de date

Spre deosebire de conexiunea activă de date, transferul pasiv de date inversează direcţia de
stabilire a conexiunii de date. Clientul va trimite, în loc de comanda PORT, comanda PASV
care nu are parametri. La primirea acestei comenzi, serverul FTP răspunde transmiţând o
adresă IP şi un număr de port. Clientul iniţiază conexiunea către server spre adresa IP şi portul
indicate. Un exemplu de secvenţă este ilustrat în Figura 11.4.

Unul dintre motivele pentru care se utilizează transferul pasiv de date este trecerea peste
configuraţia firewall-ului care blochează conexiunile active de date. Din acest motiv
transferul pasiv mai este numit şi “firewall friendly mode”. În cazul în care clientul are activat
un firewall configurat să blocheze orice încercare de deschidere din exterior a unei conexiuni,
un server FTP care răspunde unei comenzi PORT va primi un mesaj de eroare când va încerca
să stabilească o conexiune către adresa IP şi portul indicate. În modul pasiv, deoarece clientul
iniţiază conexiunea din interiorul sistemului protejat, firewall-ul va permite stabilirea legăturii
şi transferul de date va putea fi realizat.

Page 6 of 12
 Figura 11.4 Conexiune pasivă de date

11.1.5 Utilizarea transferului proxy

FTP oferă posibilitatea unui client de a transfera date de pe un server FTP pe un alt server
FTP. Câteva dintre justificările unui astfel de transfer sunt:

- Transferul datelor de pe un host pe un alt host când nu este posibil accesul direct la
cele două hosturi.
- Trecerea peste o conexiune client lentă.
- Trecerea peste restricţii firewall.
- Reducerea traficului în interiorul reţelei clientului.

Procesul de setare a unui transfer proxi începe cu utilizarea comenzii proxy open. Poate fi
transmisă către serverul proxy orice comandă FTP, precedată de prefixul proxy. De exemplu,
execuţia comenzii dir va lista fişierele de pe serverul FTP primar. Executând comanda proxy
dir, se vor lista fişierele de pe serverul proxy. Pentru a realiza transferul între cele două
servere se pot utiliza comenzile proxy get şi proxy put. Procesul este ilustrat în Figura 11.5.

Page 7 of 12
 Figura 11.5: Transfer proxy FTP printr-un firewall

În Figura 11.5:

1. Clientul FTP deschide o conexiune şi se leagă la serverul FTP A.

2. Clientul FTP lansează comanda proxy open şi se va stabili o conexiune nouă către
serverul FTP B.
3. Clientul FTP lansează comanda proxy get sau proxy put.
4. Este stabilită conexiunea de date între serverul A şi serverul B. Urmând conexiunea, se
va face transferul de date între servere.

11.1.6. Coduri de răspuns

În scopul de administra aceste operaţii, clientul şi serverul realizează un dialog utilizând

convenţii Telnet. Clientul lansează comenzi, iar serverul răspunde cu coduri răspuns.
Răspunsul conţine şi comentarii care sunt în folosul utilizatorului, dar aplicaţia client
utilizează numai codurile. Codurile răspuns dunt valori de trei cifre, cu primele două având
semnificaţii precise. Tabelele 11.1 şi 11.2 descriu aceste coduri.

Tabelul 11.1 Prima cifră a codului şi semnificaţia ei

Prima cifră Descriere
1yz Răspuns pozitiv preliminar. Aceste mesaje sunt în mod normal
informaţionale şi tipic sunt nurmate de un alt mesaj cu un cod răspuns
diferit
2yz Răspuns pozitiv de completare. Indică faptul că ultima comandă a
clientului a fost încheiată cu succes.
3yz Răspuns pozitiv intermediar. Indică faptul că a fost acceptată ultima

Page 8 of 12
 comandă a clientului, dar sunt necesare informaţii suplimentare din
partea clientului pentru a completa comanda.
4yz Răspuns de completare negativ temporar. Indică faptul că a eşuat
prelucrarea comenzii, dar o retransmitere a acesteia s-ar putea încheia cu
succes.
5yz Răspuns de completare negativ permanent. Comanda a eşuat, iar o
retransmitere a ei nu va avea succes.
6yz Răspuns protejat. Replica conţine informaţii referitoare la securitate.

Tabelul 11.2 A doua cifră a codului şi semnificaţia ei

A doua cifră Descriere
x0z Eroare de sintaxă în comanda clientului.
x1z Cerere de informaţii. Mesajul conţine informaţii cerute de la client.
x2z Informaţii privind conexiunea. Răspunsul conţine informaţii privind
conexiunile de control şi date.
x3z Autentificare. Răspunsul este parte a unui mesaj de conectare sau a unei
secvenţe de autentificare.
x4z Nu este în uz.
x5z Informaţii privind sistemul de fişiere. Răspunsul conţine informaţii privind
sistemul de fişiere, relevante pentru ultima comandă recepţionată de la
client.

Pentru fiecare comandă a clientului, figurată cu scriere bold, serverul FTP răspunde cu un cod
de trei cifre şi un mesaj, ilustrat cu scriere italică:

220 service ready

USERNAME cms01
331 user name okay
PASSWORD xyxyx
230 user logged in
TYPE Image
200 command okay

11.1.7. Anonymous FTP

Multe site-uri TCP/IP au implementat ceea ce se numeşte anonymous FTP, ceea ce înseamnă
că site-ul permite accesul public la anumite directoare. Utilizatorul distant va fi nevoit să
utilizeze numele de logare anonymous şi parola guest sau o alta specificată de sistem în
momentul în care se iniţiază conectarea. Deoarece metoda de conectare este disponibilă
tuturor celor care sunt conectaţi la Internet, hosturile restricţionează fişierele accesibile
utilizatorilor anonimi.

11.1.8. Utilizarea FTP cu Ipv6

Utilizarea în creştere a Ipv6 în reţele a avut un efect minor asupra implementărilor FTP,
deoarece adresarea Ipv6 este administrată de nivelul IP. Totuşi, apare o problemă cu
arhitectura comenzii PORT. Pentru a o înţelege, va trebui discutată în detaliu comanda PORT.

Page 9 of 12
Aşa cum s-a arătat în secţiunea 11.1.3. (transferul activ de date), clientul FTP utilizează
comanda PORT pentru a informa serverul pe ce port şi la ce adresă IP aşteaptă (clientul) să fie
deschisă o conexiune de date. Sintaxa acestei comenzi este:

PORT h1, h2, h3, h4, p1, p2

În această sintaxă, h1 până la h4 reprezintă cei patru octeţi ai adresei IPv4, p1 reprezintă un
număr care va fi înmulţit cu 256 şi apoi adunat cu p2 pentru a obţine numărul portului. De
exemplu, să presupunem că un client FTP transmite următoarea comandă către serverul FTP:

PORT 10,1,200,201,9,8

Această comandă spune serverului FTP să deschidă o conexiune către adresa IP 10.1.200.201,
pe portul (9 11 256) + 8 = 2312.

Prin această definire a comenzii PORT este clar că aceasta a fost destinată utilizării adreselor
Ipv4, deoarece pentru adrese IPv6 sunt mult nmai multe câmpuri de precizat. Aceeaşi
problemă apare şi la utilizarea comenzii PASV, care , chiar dacă este lansată fără parametri,
va primi un răspuns din partea serverului FTP de forma:

227 Entering Passive Mode. (h1,h2,h3,h4,p1,p2)

în care semnificaţia h1-h4, p1, p2 este aceeaşi cu cea de mai sus. Rezultă astfel că şi la PASV
apar aceleaşi restricţii ca şi la PORT.

Pentru a acoperi aceste limite au fost create alte două comenzi care înlocuiesc comenzile
PORT şi PASV: EPRT, respectiv EPSV.

Comanda EPRT este procesată similar ccomenzii PORT, dar formatul ei este:

EPRT <d>protocol<d>address<d>port<d>

<d> reprezintă un delimitator ales din plaja 33-126 a caracterelor ASCII. Se recomandă
folosirea caracterului ASCII 124 ” | ”.

protocol Familia de adrese în care clientul cere conexiunea. Dacă valoarea este 1, atunci
se cere pe o adresă IPv4, iar o valoare 2 indică o adresă IPv6.

address Este adresa corespunzătoare (IPv4 sau IPv6) la care se va deschide conexiunea.

port Este portul pe care se va deschide conexiunea.

Urmează două exemple de utilizare a comenzii EPRT, în care adresa IPv4 10.1.200.201 a fost
convertită în notaţie IPv6:

IPv4: EPRT |1|10.1.200.201|2312|

IPv6: EPRT |2|::0A01:C8C9|2312|

Similar comenzii PASV, comanda EPSV poate fi lansată fără parametri. Răspunsul serverului
la comanda EPSV este:

Page 10 of 12
229 <text> (<d><d><d>port<d>)

Textul este opţional şi indică utilizatorului că este conctat în modul pasiv. Câmpul dintre
delimitatori trebuie să fie gol deoarece comanda EPSV presupune că iniţierea conexiunii de
date de către client se va face la aceeaşi adresă Ip ca şi conexiunea de control stabilită. Un
exemplu de răspuns al serverului la o comandă EPSV este:

229 Entering Passive Mode (|||2312|)

După recepţionarea acestui răspuns, clientul va deschide o conexiune de date la portul 2312
pe aceeaşi adresă IP pe care este activă conexiunea de control. Comanda EPSV este utilă când
se stabileşte o conexiune FTP securizată peste un firewall care implementează NAT (Network
Address Translation). NAT cere translatarea adresei IP specificate în comanda client PORT
sau în răspunsul PASV al serverului. Translatarea va permmite rutarea mesajelor în afara
subreţelei clientului sau serverului. Dacă conexiunea de control a fost criptată, NAT nu are
acces la aceste adrese şi, ca urmare, aplicaţiile FTP nu vor putea stabili conexiunea de date.
Folisind comanda EPSV, serverul FTP cunoaşte deja adresa IP utilizată şi procedura de
stabilire a conexiunii de date poate demara fără intervenţia NAT.

11.1.9. Securizarea sesiunilor FTP

Deşi FTP oferă securitate, cerând utilizatorilor să se conecteze utilizând un nume de utilizator
şi o parolă, această acţiune nu face altceva decât evită accesul neautorizat la sistem. Când se
transferă date de la un host la altul, datele din pachete (atât din conexiunea de control, cât şi
din cvea de date) sunt transmise în clar. De aceea, dispozitive din reţea pot captura aceste
pachete şi obţine acces la datele transferate. Mai mult, pot fi capturate chiar şi identificatorul
şi parola utilizatorului dând posibilitatea unui acces fraudulos la reţea.

Pentru a evita această problemă, FTP apelează la Transport Layer Security (TLS). TLS
reprezintă un standard de criptare a datelor între două hosturi. Aşa cum spune şi numele, el
este implementat la nivelul transport şi de aceea modul în care acţionează este transparent
pentru aplicaţiile care îl utilizează. Acestea nu trebuie să ştie decât cum să îl invoce.

Configurarea şi implementarea TLS variază funcţie de platforma pe care se găseşte.

Următoarele comenzi sunt independente de platformă:

AUTH Specifică metoda de autentificare care va fi utilizată pentru conectarea FTP.

ADAT Trece datele codate (Base64) utilizate în negocierea securităţii între client şi
server, specific mecanismului menţionat în comanda AUTH.

PBSZ Specifică dimensiunea maximă a buffer-ului prin care datele criptate vor fi
trecute de la client la server.

PROT Specifică nivelul de protecţie a canalului. Argumentul trebuie să fie unul din
următorii:

C Clear: nu se utilizează nici o autentificare şi nici o criptare

Page 11 of 12
 S Safe: se realizează autentificarea, dar nu este implementată criptarea.

E Confidential: se realizează criptarea, dar nu şi autentificarea.

P Private: sunt realizate atât autentificarea cât şi criptarea.

MIC Furnizează mesaje codate Base64 utilizate pentru a asigura integritatea

comenzilor transmise pe conexiunea de control.

CONF Furnizează mesaje codate Base64 utilizate pentru a asigura confidenţialitatea

comenzilor transmise pe conexiunea de control.

ENC Furnizează mesaje codate Base64 utilizate pentru a asigura intimitetea

comenzilor transmise pe conexiunea de control.

CCC Anunţă serverul FTP că nu mai sunt cerute comenzi protejate pentru sesiunea
FTP.

Figura 11.6: Exemplu de procesare FTP TLS.

Un exemplu de negociere a securităţii este prezentat în Figura 11.6.

Page 12 of 12