Performan ele re elelor de calculatoare

Cuprins
Introducere Intserv
Guaranteed Services Controlled-Load Service Resource reSerVation Protocol - RSVP Dezavantajele Intserv

3 4
4 6 6 8

Diffserv
Componentele modelului DiffServ Noduri DS de grani i noduri interioare Noduri Diffserv de intrare (ingress) i de ieire (egress) Regiunile DiffServ Clasificatorii de trafic i mecanismul de implementare Arhitectura unei re ele DiffServ multidomeniu Compara ie DiffServ - IntServ

9
10 10 10 10 11 13 14

MPLS

MPLS Trafic Engineering CR-LDP

15
15 16

Algoritmi de management al cozilor

Random Early Drop - RED Random early drop with In/Out - RIO

17
17 18

Concluzii Acronime i abrevieri Bibliografie

19 21 22

Introducere
Internetul actual const dintr-o multitudine de re ele construite folosind diferite protocoale de nivel legtur de date care se bazeaz pe IP (Internet Protocol) pentru interconectarea lor IP-ul nu pornete de la nici o premis despre stiva de protocoale aflate dedesupt i ofer un serviciu de re ea fr conexiune i fr garantarea livrrii pachetelor Pachetele pot fi pierdute, reordonate, pot sosi duplicate, toate acestea mpreun cu ntrzierile datorate ateptrii n cozile routerelor de tranzit, duc la creterea ncrcrii re elei Datorit lipsei garantrii livrrii datelor, modeul IP este de cele mai multe ori denumit i "best effort", necesitnd un protocol adi ional pe nivelul superior, aa cum este TCP (Transmission Control Protocol) pentru a oferi transportul garantat al datelor TCPul realizeaz acest lucru folosind un mecanism de retransmisie al pachetelor ceea ce mrete i mai mult ntrzierile la transferul datelor prin re ea Routerele de astzi doar dirijeaz pachetele dup o politic de tip FIFO (First-In FirstOut) Aceast arhitectur simpl are cteva avantaje evidente: Scalabilitate Deoarece singurele informa ii men inute de routere sunt informa iile de rutare, arhitectura Internetului este foarte scalabil Mai mult, agregarea adreselor IP n clase, permite routerelor s memoreze considerabil mai pu ine informa ii de rutare dect numrul de sta ii din Internet Robuste e Unul dintre principalele eluri n proiectarea IP-ului a fost robuste ea S-a dorit ca dou sta ii s poat comunica chiar n condi iile n care routerele de pe traseu se opresc sau dac legturile cad, fr a fi necesar o reconfigurare a re elei Singurul caz n care dou sta ii nu mai pot comunica este acela n care ntreaga re ea este sec ionat Faptul c informa iile de stare despre un flux oarecare sunt men inute doar de ctre sta iile terminale i nu de ctre routere, face mult mai uoar asigurarea robuste ii, deoarece oprirea unui router nu compromite starea fluxurilor Dac aceste informa ii ar fi fost stocate n routere ar fi fost necesare mecanisme complexe de replicare i restaurare a lor n cazul defectrii unui router Performan Designul simplu al routerelor permite implementarea lor eficient chiar i n cazul vitezelor foarte mari de lucru In mod curent acestea implementeaz o politic FIFO i un algoritm de aruncare al pachetelor n momentul umplerii cozilor Ambele opera ii se pot implementa ntr-un timp O(1) Pentru aplica iile tradi ionale, fr cerin e de timp real, cum ar fi FTP-ul (File Transfer Protocol) sau mail, modelul "best effort" al IP-ului nu a fost o problem, dar cu trecerea timpului tot mai multe aplica ii real-time sunt dezvoltate Aceste aplica ii sunt foarte sensibile la n rzierile din re ea, ceea ce face ca modelul "best effort" s devin neadecvat, chiar i n re ele cu ncrcare redus Dei problema a fost aplanat ntructva prin realizarea unor aplica ii care se adapteaz la condi iile re elei, rmne o nevoie tot mai mare de implementare n interiorul re elei a unor mijloace de asigurarea a calit ii serviciilor (QoS) Astfel trebuie oferite noi servicii care s se adauge tradi ionalului "best effort" pentru a oferi suport noilor aplica ii multimedia, VoIP (Voice over IP) etc Pe parcursul acestui document vom prezenta dou modele de asigurare a unor servicii diferen iate, precum i modul n care asigurarea QoS se poate face n mod natural n re elele MPLS
3

Intserv
Ca rspuns la cererea tot mai mare a unui Internet care s asigure servicii integrate, Internet Engineering Task Force (IETF) a format un grup de lucru (Integrated Services IntServ) care a definit mai multe clase de servicii (RFC 1633) Acestea, dac sunt implementate de routerele traversate de un flux de date, i pot satisface ntr-o oarecare msur cerin ele sale de QoS In contrast, un router clasic "best effort" traversat de un astfel de flux i va oferi acestuia resursele libere nelund n seam cerin ele sale speciale Parametrii QoS oferi i de aceste clase sunt programabili pentru fiecare flux, n func ie de cerin ele aplica iilor care transmit datele Aceste cereri pot fi satisfcute n dou moduri i anume: prin programare static de ctre administratori, sau folosind un protocol adi ional, aa cum este RSVP-ul (Resource Reservation Protocol) Cererile dicteaz nivelul resurselor care trebuie s fie satisfcute de-a lungul ntregii ci de tranzit a datelor, pentru a avea nivelul dorit de QoS Astfel devine crucial rolul unui mecanism de control al accesului la resursele de comunica ie (admission control) Fiecare router trebuie s verifice dac resursele sunt disponibile, dac solicitantul are dreptul s fac o rezervare i apoi s transmit un mesaj de rspuns la solicitarea de rezervare Unul dintre parametri care trebuie specifica i n momentul solicitrii unei rezervri este dimensiunea maxim a unei datagrame a fluxului de date Aceasta nu trebuie s fie mai mare dect MTU (Maximum Transmit Unit) cci n cazul n care dimensiunea este mai mare se va refuza rezervarea , deoarece modelu InServ pornete de la premisa c datagramele care vor beneficia de un nivel special de QoS nu vor fi niciodat fragmentate Dup realizarea rezervrii n interiorul fiecrui router de pe traseul datelor, aplica ia va beneficia de un acelai nivel de QoS de la un capt la altul att timp ct este timpul de via al rezervrii, sau pn la modificarea traseului pachetelor Deoarece protocolul RSVP se bazeaz pe rezervri soft, apari ia unei modificri n traseul datelor poate fi tolerat, o nou rezervare restabilind nivelul QoS fr ca aplica ia s aib prea mult de suferit Politici speciale i ac iuni de temperare al traficului se vor folosi pentru a preveni ca fluxurile de date cu comportament "neprietenos" s afecteze nivelul de QoS al celorlalte fluxuri care se comport normal Astfel, dac un flux are un comportament "neprietenos" i transmite la o rat mai mare dect rezervarea sa, punnd n pericol rezervrile celorlalte fluxuri, i se vor arunca din pachete pn la limita rezervrii Comitetul desemnat de IETF a luat n considerare mai multe clase de QoS, dar n final s-au stabilit doar dou tipuri de servicii: "Guaranteed Services" i "Controlled-Load Service"

Guaranteed Services
"Guaranteed Service" este cel mai complet tip de serviciu propus pentru a fi implementat n Internet pn n acest moment El asigur o band garantat, o ntrziere constant n transmisia pachetelor i nici o pierdere de pachete din fluxul de date In acest fel se asigur suport pentru aplica ii de timp real cum sunt VoIP sau videoconferin Fiecare router aloc pentru fiecare flux o band R i o zon din buffer B, pe care fluxul poate s le consume Fluxul de date se modeleaz ca un fluid ce curge ntre surs i
4

destina ie de-a lungul re elei Fluxul vede o band R de la un capt la altul al re elei In cazul acestui model func ionarea unui ruter se modeleaza ca un "token bucket" de rat r i capacitate b Intrzierea introdus de un astfel de router va fi b/Rcu Rr Pentru a specifica i abaterile ntrzierii de la modelul ideal se introduc doi termeni de eroare C dependent de band i una constant D, astfel c ntrzierea devine b/R +C/R +D Dar, deoarece prin garantarea serviciului se impune o rat de vrf a fluxului (peak rate) p, limitele ntrzierilor se reduc Mai mult, trebuie s se in cont i de faptul c avem de-a face cu pachete de date de dimensiune maxim (MTU) M Tinnd cont de to i aceti factori putem exprima mult mai precis ntrzierea total :
t ot = (b M)(p R) + R(p r) (M + Ct ot ) R (M + Ct ot ) R + Dt ot (dac p>Rr)

sau,
t ot =

+ Dt ot (dac Rpr)

unde Ctot i Dtot reprezint nsumarea termenilor de eroare C i D a tuturor routerelor de pe traseu p = rata de vrf a fluxului (octe i/s) b = dimensiunea gle ii (octe i) r = rata de gle i (octe i/s) M = MTU (octe i) R = banda solicitat Fiecare router trebuie s ia msuri n cazul n care rata datagramelor depete valorile negociate De obicei datagramele care depesc nivelul maxim vor trebui livrate n regim normal de "best effort" Se poate uor vedea c un astfel de serviciu este ideal pentru aplica iile de timp real Din nefericire complexitatea implementrii acestui serviciu este deosebit de mare Implementrile curente cer ca routerele s poat memora strile fluxurilor de date i de control pentru fiecare flux n parte Pe calea de date routerul trebuie s realizeze urmtoarele opera ii: flow clasification buffer management scheduling (programare) Pe calea de control routerele trebuie: s men in pentru fiecare flux informa iile de dirijare s realizeze controlul accesului pentru fiecare flux In timpul fazei de control al accesului, fiecare router de pe traseul pe care vor fi dirijate
5

pachetele trebuie s rezerve resurse prin negocierea parametrilor aminti i anterior: dimensiunea bufferelor, banda alocat i s se asigure c ntrzierea nu depsete valoarea maxim dorit

Controlled-Load Service
Pentru aplica ii care nu necesit un nivel strict al garantrii serviciului, IETF a propus o categorie mai slab de garantare a serviciilor Serviciul de ncrcare controlat (Controlled-Load Service) aproximeaz foarte bine comportarea re elei pe care o observ o aplica ie atunci cnd re eaua opereaz n condi ii de ncrcare redus Mai exact, Controlled-Load Service garanteaz c pierderile de pachete nu sunt mai mari dect rata erorilor de transmisie ale mediului i c ntrzierile pe care le sufer majoritatea pachetelor nu depesc cu mult timpul de propagare de la un capt la altul Diferen a esen ial fa de best effort este c performan ele observate de aplica ii nu se deterioreaz odat cu creterea ncrcrii re elei Serviciul de ncrcare controlat este conceput s ofere un suport mai bun pentru o ntreag clas de aplica ii de timp real, cum sunt cele de VoIP, care au fost deja dezvoltate Routerele care implementeaz acest serviciu trebuie s verifice dac comportamentul fluxurilor de date respect rezervrile in iale Orice nonconformitate a unui flux nu trebuie s afecteze nivelul QoS oferit celorlalte fluxuri sau s afecteze traficul best-effort Tinnd cont de aceste constrngeri routerele trebuie s dirijeze ct mai multe pachete ale fluxurilor neconforme dup modelul best-effort O alt op iune este aceea de a declasifica fluxurile care nu respect rezervarea si de a le livra ca trafic best-effort Dei routerele trebuie n continuare s realizeze flow clasification, buffer management i scheduling, aceste opera ii pot fi simplificate foarte mult Astfel Controlled-Load Service se poate implementa mai uor dar ofer o calitate mai sczut a serviciilor

Resource reSerVation Protocol - RSVP

Modelul IntServ folosete Resource Reservation Protocol - RSVP pentru a stabili i controla calitatea serviciului Protocolul RSVP se folosete de UDP pentru a controla toate routerele de pe calea de rezervare O cerere RSVP de rezervare a resurselor se aplic unui flux de date cu traseu prestabilit prin re ea Fiecare flux este identificat n RSVP prin adresa i portul destina ie al pachetelor Protocolul RSVP este un protocol simplex cu ini ierea de ctre destina ie Pentru aplica ii duplex cele dou terminale trebuie s trimit fiecare o cerere de rezervare Folosind semnalizarea RSVP un receptor trimite spre emi tor o cerere de rezervare ce specific QoS-ul dorit Emi torul va trimite un mesaj special numit "PATH message" spre receptor, iar fiecare router de pe traseu are obliga ia s memoreze calea pe care a venit mesajul i cerin a de trafic La primirea mesajului de PATH receptorul trimite un mesaj de efectuare a rezervrii numit "RESV message" Routerele de pe traseu pot accepta sau respinge rezervarea Dac cererea este acceptat vor rezerva banda pentru fluxul de date

Receptori
RESV

Emi tor
RESV RESV

RESV

PATH

PATH

PATH

PATH

Figura 1 Propagarea mesajelor RESV i PATH Mesajele RESV sunt generate de receptori i con in parametrii de rezervare i o parte din parametrii proveni i prin pachetele PATH: "flowspec" i "filter spec" care mpreun alctuiesc "flow descriptor" Filter spec - specific care pachete din flux trebuie s fie folosite de ctre modulul "Packet classifier" din routere; Flow spec - con ine informa ii pentru modulul "Packet scheduler" i anume descrierea calit ii serviciului dorit Protocolul este unul de tip "soft state" n sensul c rezervrile au un timp de via limitat i trebuiesc rennoite periodic de ctre terminalele receptoare Dac o rezervare nu este rennoit se consider c receptorul nu mai func ioneaz i deci fluxul de date nu mai are nevoie de rezervare Dac traseul datelor se schimb datorit evolu iei traficului n re ea, mesajul de remprosptare a rezervrii va instala automat rezervarea pe noul drum al datelor Rezervrile pot fi folosite n comun pe traseul de date pentru transmisiile multicast Intervalul de timp ntre dou opera ii de refresh este de cteva ori mai mic dect timpul pn la expirarea rezervrii Astfel, eventualele pierderi ale pachetelor pot fi tolerate, totui se recomand ca o parte din banda disponibil s fie prealocat pentru mesajele RSVP, protejndu-le astfel de eventualele congestii Rezervrile pot fi anulate n dou moduri: prin expirarea intervalului de refresh sau printr-un mesaj explicit numit "PathTear" In grupuri eterogene de multicast, receptorii pot avea capabilit i diferite i necesit nivele de QoS diferite Protocolul RSVP fiind orientat pe receptori (receiver oriented) permite tuturor receptorilor din grup s-i aleag i s-i men in o calitate a serviciului dorit (QoS), atta timp ct au nevoie Emi torul va transmite mai multe fluxuri RSVP cu calit i diferite Fiecare flux RSVP este omogen i receptorii pot alege crui flux s i se alture, sau pot s se alture mai multor fluxuri Aceast caracteristic face posibil ca diveri receptori s cear QoS-uri diferite, n func ie de propriile capabilit i

Dezavantajele Intserv
Structura intern a unui router compatibil Intserv aa cum este descris n RFC 1633 este urmtoarea:
Routing Agent Reservation Setup Agent Management Agent

Admission Control Routing Database Traffic Control Database

Classifier

Packet Scheduler

Input Driver

Internet Forwarder

Output Driver

Figura 2 Exemplu de structur a unui router INTSERV Dei serviiile asigurate de Intserv ofer o granularitate maxim a QoS aceasta are un cost destul de mare Se poate remarca complexitatea crescut a unui router Intserv n compara ie cu un router normal Un astfel de router necesit o foarte mare putere de procesare Analiznd cazul unui router care trebuie s lucreze la viteze de 10Gbps, acesta va prelucra aproximativ: 10Gbps/(8x512)24 000 000 pachete pe secund Folosind un procesor care execut 1 Gopera ii pe secund rezult c acesta va aloca aproximativ 1Go/24 000 000 = 41 opera ii Routerul trebuie s citeasc antetul pachetelor, s le clasifice, s le dirijeze ctre interfa a de ieire dorit i s ndeplineasc opera iile anexe de men inere a coeren ei bazelor de date de rutare i de control al traficului Astfel se observ c implementarea unui router Intserv care s fac fa cerin elor de trafic din backbone-urile actuale este foarte dificil Si, dei puterea de procesare crete periodic conform Legii lui Moore, la fel i traficul prin Internet crete i el O alt problem care apare la acest model este aceea a compatibilit ii cu infrastructura existent Implementarea Intserv presupune nlocuirea tuturor routerelor din Internet cu unele noi Acest lucru face ca Intserv s fie foarte costisitor de pus n practic

Diffserv
Datorit problemelor generate de Intserv, IETF a propus un nou model de asigurare a calit ii serviciilor, pornind de la cerin a fundamental de scalabilitate i implementabilitate facil DiffServ ofer o tratare diferen iat a fluxurilor agregate folosind marcarea pachetelor Marcarea pachetelor folosete bi ii din headerele pachetelor pentru asigurarea unui tratament diferen iat In IPv4 se folosesc bi ii ce formeaz octetul TOS (type of service) pentru a marca pachetele Octetul TOS const din 3 bi i numi i "de preceden ", 4 bi i ce indic cerin ele de tratare ale pachetului, respectiv ntrziere minim, debit maxim (maximum throughput), fiabilitate maxim (maximum reliability) i cost minim, rmnnd un bit nefolosit Cmpul preceden reprezint prioritatea pachetului, de la 0 (normal) pn la 7 (pachet de control al re elei) Aceti bi i ar trebui folosi i de routere pentru a lua o decizie asupra tratamentului acordat unui pachet Totui n practic aceti bi i sunt total ignora i de routere DiffServ redefinete aceti bi i sub forma unui cmp numit DS, din care ase bi i formeaz cmpul DSCP (Diferentiated Service CodePoint), iar ultimii doi bi i sunt nefolosi i Interpretarea cmpului DSCP este n curs de standardizare de ctre IETF DiffServ se folosete de DSCP pentru a decide tratamentul care i se aplic unui pachet n fiecare nod (PHB - per hop behavior) Acest tratament se poate observa extern prin compara ia cu alte pachete care au cmpul DSCP diferit Legtura dintre marcajul unui pachet DSCP i tratamentul pe care acesta l sufer n fiecare nod (PHB) nu este fix Astfel acest tratament poate fi diferit ntre domeniile DiffServ conform dorin elor i posibilit ilor fiecruia Inainte ca un pachet s intre ntr-un domeniu DiffServ acesta este marcat prin modificarea cmpului sau DSCP de ctre primul router, dup calitatea serviciului dorit i dup drepturile acestuia In interiorul unui domeniu DiffServ fiecare router va examina acest cmp nainte de a dirija pachetul Astfel nu este necesar efectuarea unor opera ii complicate de clasificare i de memorare a strii DiffServ pornete de la dou principii de proiectare Primul principiu este acela de a mpinge complexitatea spre marginea re elei, iar al doilea este acela de separare a politicii de mecanismele de implementare Marginea re elei este format din sta iile i serverele conectate la re ea i routerele de frontier Deoarece la marginea re elei numrul de fluxuri este relativ redus, opera iile de clasificare i marcare a pachetelor pot fi efectuate cu acurate e maxim fr a necesita resurse deosebite In contrast, n inima re elei numrul de fluxuri este semnificativ mai mare i de aceea aici trebuie s se efectueze doar opera ii simple a cror durat s fie ct mai mic Aceast diferen iere ntre routerele de grani i routerele din centrul re elei este vital pentru scalabilitatea modelului DiffServ Separarea dintre politica de control i mecanismele care o implementeaz permit ca acestea s evolueze independent DiffServ definete doar cteva tratamente aplicate pachetelor la nivel de nod (PHB) ca fiind crmizile asigurrii QoS, lsnd politica de control pe seama unui mecanism independent Astfel politica de control se poate schimba dup nevoi, dar PHB-urile ar trebui s rmn relativ stabile Separarea acestor dou componente este esen ial pentru flexibilitatea DiffServ Un exemplu similar este cel al rutrii n Internet Opera ia de rutare este una deosebit de simpl, dar construc ia tabelelor dup care aceasta se face este foarte complex i se pot folosi mai multe protocoale In mod asemntor tratamentul aplicat fiecrui pachet (PHB) se poate implementa
9

hardware, pe cnd stabilirea politicii de control se poate implementa software In implementrile actuale DiffServ ofer dou modele de servicii pe lng clasicul "best effort" "Premium service" garanteaz rata de vrf i este optimizat pentru trafic avnd caracteristic regulat a anvelopei, oferind o ntrziere minim a pachetelor Acest model poate asigura o calitate absolut a serviciului Un exemplu de folosire a "premium service" este folosirea sa la crearea de linii nchiriate virtuale peste o infrastructur deja existent "Assured service" este al doilea model i se bazeaz pe planificare statistic a resurselor Pachetele sunt marcate n dou clase In i Out Pachetele In au cea mai mic probabilitate de a fi eliminate, pe cnd pachetele Out sunt primele eliminate n cazul unei congestii Acest serviciu ofer un QoS relativ El se poate folosi pentru a implementa aanumitele "Olympic Service" care con in trei subcategorii: de aur, de argin i de bronz

Componentele modelului DiffServ Noduri DS de grani i noduri interioare

Un domeniu DiffServ (DS) const din noduri DS de grani i din noduri interioare Nodurile de grani interconecteaz domeniul DS cu alte domenii care pot fi DS sau nonDS, pe cnd nodurile interioare sunt conectate exclusiv cu alte noduri DS apar innd aceluiai domeniu Ambele tipuri de noduri trebuie s fie capabile s aplice tratamentul (PHB) corespunztor fiecrui pachet In plus, nodurile exterioare trebuie s fie capabile s eticheteze pachetele i s aplice tratamentul prestabilit pachetelor ce provin din domenii strine Acest tratament se specific n contractul TCA (Traffic Conditioning Agreement) ntre provideri Se admite ca nodurile interioare s fie capabile s remarcheze pachetele n caz de necesitate pentru a implementa politici mai complexe de control al traficului O sta ie conectat la un domeniu DS poate s se comporte ca un nod de grani pentru traficul generat de aplica iile pe care le ruleaz Dac sta ia nu func ioneaz ca un nod DiffServ de grani , atunci cel mai apropiat nod din domeniu va deveni nod de grani pentru sta ia respectiv

Noduri Diffserv de intrare (ingress) i de ieire (egress)

Nodurile de grani pot s se comporte ca noduri DS de intrare sau ca noduri de ieire n func ie de direc ia de deplasare a traficului Nodurile de intrare trebuie s se asigure c traficul care intr n re ea respect TCA-ul stabilit ntre domenii, iar acest lucru se face prin marcarea corespunztoare a pachetelor Un nod de ieire va aplica tratamentul negociat traficului care iese din domeniul curent spre domeniile nvecinate, n func ie de detaliile convenite n TCA-ul dintre cele dou domenii

Regiunile DiffServ
O regiune DiffServ este format dintr-un set de unul sau mai multe domenii DS contigue Regiunile DS sunt capabile s suporte servicii diferen iate de-a lungul traseelor ce le traverseaz
10

Un domeniu DS dintr-o regiune DS poate implementa intern grupuri PHB diferite i diverse etichetri ale pachetelor, dar pentru a implementa servicii care s se ntind pe mai multe domenii, domeniile DS alturate trebuie s stabileasc un SLA (Service Level Agreement) care s defineasc explicit sau implicit un TCA Acesta definete cum este tratat traficul ce tranziteaz cele dou domenii la grani a dintre ele Este posibil ca mai multe domenii DS dintr-o regiune s adopte o politic comun de alocare a resurselor i s suporte acelai set de PHB i s aib aceeai mod de etichetare a pachetelor, eliminnd necesitatea de prelucrare a pachetelor la trecerea dintre domenii

Clasificatorii de trafic i mecanismul de implementare

Serviciile diferen iate se extind peste grani ele unui domeniu DS prin stabilirea de SLAuri ntre re eaua din amonte i domeniul din aval SLA-ul poate specifica modul de clasificare al pachetelor i regulile de marcare a lor i poate, de asemenea, s specifice profile de trafic precum i ac iuni ce se ntreprind mpotriva fluxurilor ce nu se ncadreaz n aceste profile TCA-ul dintre domenii este derivat explicit sau implicit din acest contract de garantare a serviciului (SLA) Politica de clasificare identific acel subset al traficului care va beneficia de servicii diferen iate i va fi etichetat pentru a se ncadra ntr-unul din profilele agregate de trafic din domeniu Pentru a se implementa un profil de trafic se aplic opera iile de msurare, ncadrare ntrun profil (shaping) i/sau prioritizare pentru ca acesta s se ncadreze n specifica iile din TCA 1 Clasificatorii Clasificatorii de pachete aleg pachetele dintr-un flux de trafic pe baza con inutului lor sau numai a antetului Se definesc dou tipuri de clasificatori Primul tip este denumit BA (Behavior Aggregate) i clasific pachetele doar pe baza punctului de intrare n domeniu Al doilea tip de clasificator denumit MF (Multi-Field) selecteaz pachetele pe baza combina iei ntre unul sau mai multe cmpuri din antet cum ar fi adresa surs sau destina ie, port etc precum i pe baza interfe ei de intrare Clasificatorii sunt folosi i pentru a dirija opera iile ulterioare care se aplic pachetelor 2 Profilele de trafic Specific propriet ile temporare ale fluxurilor de trafic selectate de clasificator Ele ofer reguli pentru a determina dac un anumit pachet se ncadreaz n profilul dat sau nu In RFC 2475 este dat un astfel de exemplu i anume un profil poate arta ca un tuplu (codepoint X,token-bucket r,burst size b) Unde X este codul cu care se marcheaz toate pachetele ce trebuie ncadrate ntr-un token-bucket cu rata r i cu valoare de vrf (burst size) b In acest exemplu pachetele care nu se ncadreaz profilului sunt pachetele ce sosesc cnd nu mai sunt suficiente token-uri disponibile Pachetelor ce se ncadreaz sau nu ntr-un profil li se pot aplica diferite tratamente cu ajutorul mecanismelor de implementare 3 Condi ionatorii de trafic Sunt mecanismele de aplicare a politicii de trafic Ele se compun din urmtoarele elemente: sistem de msur (meter), sistem de marcare (marker) i sistem de eliminare a pachetelor (dropper) Un flux de trafic este ales de un clasificator care ndreapt pachetele ctre o intrare logic ntr-un condi ionator de trafic Un sistem de masur (meter) este folosit pentru a msura fluxul de trafic comparndu-l cu un profil predeterminat Pe baza acestei msurtori pachetul sufer un
11

anumit tratament el putnd fi ntrziat (shaping) sau eliminat (dropping) Cnd un pachet iese dintr-un nod de grani al unui DS el poate fi i remarcat In figura urmtoare se ilustreaz componentele logice ale unui astfel de sistem i interac iunile dintre ele

Meter

Shaper packets Classifier Marker

Dropper

Figura 3 Traseul datelor ntr-un sistem DiffServ

Meter = msoar propriet ile temporare ale fluxului de pachete selectate de clasificator n compara ie cu un profil de trafic specificat n TCA Acest modul transmite rezultatele msurtorilor spre celelalte module pentru a declana tratamentul corepunztor fiecrui pachet Marker = seteaz cmpul DS dintr-un pachet Cnd aceast opera ie este efectuat asupra unui pachet deja marcat de nodurile anterioare se spune c acest pachet a fost remarcat Shaper = aplic o ntrziere pachetelor dintr-un flux de trafic pentru a for a acel flux s se ncadreze n profilul de trafic desemnat Un modul shaper con ine de obicei un buffer finit de pachete i acestea pot fi eliminate dac nu este suficient spa iu de stocare a pachetelor ntrziate Dropper = elimin unele pachete sau toate pachetele dintr-un flux pentru a for a fluxul s se ncadreze ntr-un profil prestabilit Un dropper se poate implementa ca un caz special de shaper cu dimensiunea bufferului zero sau foarte mic

12

Arhitectura unei re ele DiffServ multidomeniu

Arhitectura unei re ele extinse DiffServ format din mai mult regiuni DS independente se poate observa n figura urmtoare Arhitectura este oarecum asemntoare cu rutarea Internet inter domenii n care BGP-ul servete drept protocol standard de rutare ntre sistemele autonome AS, pe cnd n interiorul unui domeniu este permis folosirea oricrui protocol local

BB
Ingress Router Egress Router

SLA

Transit Domain

SLA

BB

Egress Router

Ingress Router

BB

Source Domain

Destination Domain

Figura 4 Rolul Badwidth Broker-ului Pn acum am stabilit metodele de implementare n routere a politicii de alocare a resurselor Pentru pstrarea coeren ei politicii la nivelul unei regiuni DiffServ se folosete un mecanism de control numit "Bandwidth Broker" Acesta este o resurs logic ce aloc resursele ntr-un domeniu i reglementeaz acordurile inter-domeniu Un bandwidth broker pentru fiecare domeniu poate fi configurat conform politicii organiza iei i se constituie ntr-un punct central de luare a deciziilor (PDP policy decision point) n timp ce routerele din re ea se constituie n puncte de aplicare a politicilor (PEP policy enforcement points) Bandwidth broker-ul pentru o re ea extins are n componen a sa un server de baze de date, de politici de autorizare i de accountig Implementarea unui BB nu este perfect standardizat i poate depinde de fabricantul de echipamente Metodele prin care Bandwidth broker-ul configureaz PEP-urile nu este nici el standardizat dar metoda cea mai comun de lucru este prin folosirea extensiv a protocolului SNMP Astfel, datele de acounting sunt culese de la echipamentele de re ea prin citirea MIB-urilor fiecruia, iar configura iile sunt setate prin acleai mecanism Intre domenii, bandwidth broker-ul negociaz cu domeniile nvecinate, stabilete
13

n elegeri bilaterale (SLA) cu fiecare dintre ele i transmite parametrii de configurare corespunztori routerelor de grani Un anumit nivel de QoS de la un capt la altul se poate asigura prin concatenarea acestor SLA-uri bilaterale ntre domenii, mpreun cu alocarea adecvat a resurselor n interiorul unui domeniu

Compara ie DiffServ - IntServ

In DiffServ routerele din interiorul re elei proceseaz pachetele pe baza unui numr mic de clase de trafic Deoarece numrul de clase este foarte redus datorit numrului redus de bi i din cmpul TOS, procesarea se poate face foarte eficient i la viteze foarte mari ale traficului Fa de IntServ arhitectura unui router este i ea mult simplificat i deci implementrile pot fi mult mai ieftine Capabilit i DiffServ se pot aplica oricrui router chiar i celor de complexitate redus printr-un simplu upgrade software Acest lucru se i ntmpl, n prezent majoritatea routerelor de la cele mai simple pn la cele mai complicate incorporeaz mecanisme DiffServ de prioritizare i de control a traficului In majoritatea cazurilor configurarea parametrilor n interiorul routerelor se face folosind protocolul SNMP, ns parametrii din MIB-ul intern al echipamentelor sunt proprii fiecrui fabricant Un dezavantaj al arhitecturii DiffServ este acela c ofer protec ia fluxurilor agregate nepermi nd prioritizarea unui anumit flux n fa a celorlalte De exemplu, dac un flux de trafic ce vine de la un client con ine date destinate unei aplica ii cu cerin e de timp real, acesta nu va fi tratat diferen iat fa de celelalte pachete ce sosesc din acceai direc ie, cel mult i se poate asigura un tratament preferen ial fa de traficul celorlal i clien i Aceast tratare a problemei QoS nu este totui un impediment major, deoarece clientul i poate modela propriul trafic pentru a corespunde cerin elor sale Intr-un anumit sens DiffServ d posibilitatea definirii de re ele virtuale private cu asigurarea calit ii serviciului de ctre provider, lsnd n seama clientului aspecte privind componen a traficului i prioritizarea lui Din nefericire, providerul poate asigura QoS-ul doar n interiorul re elei proprii, capacitatea de a asigura acest lucru global fiind mult diminuat i depinznd de acordurile SLA cu re elele vecine Un aspect important al implementrii unui sistem DiffServ este cel al asigurrii securit ii n fa a unor ncercri de utilizare ilegal a resurselor unei re ele De exemplu, un client poate sa-i depeasc cota de trafic alocat prin modificarea cmpului DS din antetul pachetelor, producnd o scdere a resurselor alocate altor clien i Ducnd la limit un astfel de comportament poate provoca un atac de tip "denial of service" Pentru a prentmpina producerea unui astfel de incident routerele de grani trebuie s remarcheze obligatoriu toate pachetele ce intr n domeniul DS, n plus, chiar dac este posibil ca o sta ie dintr-un domeniu s poat deveni nod de grani , acest lucru trebuie acceptat doar dac acea sta ie este controlat de ctre provider, altfel primul router din calea traficului trebuie s se comporte ca un nod de grani

14

MPLS
Multiprotocol Label Switching (MPLS) a fost ini ial propus ca o metod de a permite comutarea pachetelor n locul rutrii tradi ionale, permi ind viteze de lucru mult mai mari, ulterior ns s-a dovedit a fi foarte util pentru asigurarea QoS Similar cu domeniile DiffServ, MPLS folosete un concept de domeniu MPLS format din routere MPLS, iar pachetele sunt etichetate la intrarea n domeniu In interiorul unui domeniu MPLS clasificarea pachetelor i dirijarea lor se face pe baza acestei etichete Etichetele sunt eliminate atunci cnd pachetul iese din domeniu Antetul unui pachet MPLS con ine o etichet de 20 de bi i, un cmp de 3 bi i pentru clasa serviciului (COS), un indicator de 3 bi i al stivei i un cmp de 8 bi i pentru TTL Cnd un pachet intr intr-un domeniu MPLS i se ataeaz o etichet MPLS care specific traseul ce-l va urma pachetul n interiorul domeniului Pe parcursul traseului n domeniu, fiecare router dirijaz pachetul pe baza acestei etichete, care este modificat la fiecare hop Cmpul COS este folosit pentru a alege coada corect de la interfa a de ieire La ieirea din domeniul MPLS eticheta este nlturat iar pachetul este rutat normal n continuare Prin folosirea acestui mecanism de etichetare se pot implementa dou metode de asigurare a calit ii serviciilor ntr-un domeniu MPLS Acestea sunt Constraint BasedLDP i RSVP-TE

MPLS Trafic Engineering

Avantajul acestei implementri const n fapptul c nu toate routerele din domeniul MPLS (LSR - Label Switch Router) trebuie s implementeze protocolul RSVP Este suficient ca routerele de grani (LER) s implementeze un subset al acestui protocol, iar n momentul definirii unui traseu comutat n re ea s contacteze toate celelalte routere de pe traseu pentru a rezerva resurse

Path message
LSR LSR Ingress LER LSR LSR LER Egress

RESV message RESVConf message

Figura 5 Exemplu de rutare explicit TE-RSVP LSPi
15

Unui LER sau LSR i trebuie doar o extensie pentru a suporta rutare explicit Rezervarea de resurse se face prin trimiterea de datagrame UDP i este de tip "soft state" n sensul c necesit o remprosptare periodic, altfel rezervarea se pierde Aceast implementare se aseamn foarte mult cu IntServ, cu avantajul c o parte din problemele IntServ sunt rezolvate implicit de mecanismul MPLS care definete n prealabil traseul pe care-l ia un pachet i asigur recuperarea automat n caz de rerutare a pachetelor In exemplul din figura anterioar LER (Ingress LER) de intrare trimite un mesaj PATH spre LER de ieire (Egress LER) prin fiecare LSR de pe traseul pachetelor Fiecare nod recep ioneaz mesajul PATH crend o sesiune PATH pentru acel flux de date Routerul de ieire va rezerva resursele prin trimiterea unui mesaj RSVP pe drumul invers spre intrare Cnd mesajul RSVP ajunge la intrare, un rspuns de confirmare se va trimite spre ieire Dup ce rezervarea a fost fcut, un mesaj de refresh trebuie trimis periodic pentru a o men ine

CR-LDP
Dac mecanismul anterior era unul cu stri "soft", mecanismul acesta de distribu ie a etichetelor pe baza unei rutri cu constrngeri se poate considera un mecanism hardware de asigurae a QoS, n compara ie cu mecanismul anterior care era de tip "soft state" CRLDP asigur un tratament preferen ial pentru fluxuri de date fiind independent de aplica iile rulate de un anumit client

Label Request
LSR LSR Ingress LER LSR LSR LER Egress

Label Mapping
Figura 6 Exemplu stabilire strict i explicit a LSP (CR-LDP LSP) Dei CR-LDP nu este la fel de matur ca RSVP-ul, implementarea lui nu necesit protocoale adi ionale El folosete structurile existente i le adaug doar nite extensii pentru a implementa mecanismul de asigurare al QoS La fel ca i TE-RSVP, CR-LDP suport rutarea explicit a LSP-urilor Avantajul acestei abordri este c pentru aplica ii tip VPN se poate predetermina traseul optim pentru fluxurile de date prin re ea Pentru descoperirea vecinilor din domeniul MPLS se folosete protocolul UDP, iar pentru controlul, managementul cererilor de etichete i procesului de mapare a lor se folosete TCP O analiz mai atent relev similarit ile dintre RSVP-TE i IntServ, iar CR-LDP este
16

practic similar cu modelul DiffServ Acest lucru nu este ntmpltor, ambele ini iative de asigurare a calit ii serviciilor MPLS fiind de fapt adaptri la noul context Aceaste adaptri in cont de propunerile de modificare care au aprut de la publicarea recomandrilor DiffServ i IntServ, iar n plus folosesc ntr-un mod avantajos infrastrucura de stabilire a cilor i de comutare bazat pe etichete

Algoritmi de management al cozilor

Principalul scop al asigurrii QoS este acela al controlrii pierderilor de pachete Aceasta se realizeaz printr-un management adecvat al cozilor Pachetele sunt pierdute din dou motive: datorit erorilor de transmisie (fenomen relativ rar ), sau datorit congestiilor din re ea Pentru a controla i a evita congestiile din re ea trebuie implementate unele mecanisme n punctele de acces i n routerele intermediare La capetele re elei se afl TCP-ul sau aplica iile client care trebuie s implementeze un mecanism de adaptare la condi iile re elei In interiorul re elei routerele sunt cele care asigur, pe baza cozilor, un management al traficului Cozile din arhitectura routerelor sunt gndite s absoarb vrfurile de trafic Limitnd dimensiunile cozilor scad i ntrzierile pachetelor prin re ea Din nefericire atunci cnd cozile sunt pline, pachetele sunt eliminate Eliminarea pachetelor se poate face fie de la nceputul cozii (front drop), fie de la sfritul cozii (tail drop), fie alegnd aleator, un pachet din coad Acest proces de eliminare a pachetelor atunci cnd coada este plin, are dou consecin e nefaste O prim consecin apare cnd una sau cteva conexiuni monopolizeaz ntreaga coad i, datorit modului de eliminare al pachetelor combinat cu mecanismul de "slow start" al TCP, nu vor permite altor conexiuni s accead la resurse O a doua problem care apare este aceea c vom avea cozile ocupate pentru perioade mai lungi de timp, ceea ce va duce la creterea ntrzierilor prin re ea

Random Early Drop - RED

Pentru a contracara aceste fenomene este necesar implementarea unui mecanism care s elimine pachetele nainte ca lungimea cozilor s devin maxim Un astfel de algoritm este algoritmul RED (Random Early Detection) RED msoar dimensiunea medie a cozilor dup o lege exponen ial de timp i elimin probabilistic pachetele care sosesc Probabilitatea de eliminare crete liniar cu creterea dimensiunii cozilor Ca urmare, congestiile sunt detectate i controlate nainte ca lungimea cozilor s ajung la maxim Un router RED primete la configurare urmtorii parametrii: Min , Max i Pmax Modul de functionare este ilustrat n figura alturat pe abcis fiind reprezentat dimensiunea cozii, iar pe ordonat probabilitatea de eliminare a unui pachet Aa cum se observ i n figur, exist trei faze n func ionarea algoritmului RED i anume [0,Min), [Min , Max) i [Max,) Prima faz corespunde operrii normale, cnd lungimea cozilor este sub Minth , i nici un pachet nu este eliminat Cnd lungimea cozii este ntre cele dou limite, routerul func ioneaz n faza de evitare a congestiilor i elimin pachete pentru a semnala sta iilor care transmit date s-i reduc rata de emisie Conform algoritmului de "slow start" implementat de TCP, orice pachet pierdut este perceput ca o congestie ceea ce duce la
17

scderea vitezei de transmisie Nivelul pachetelor eliminate este de obicei mic i nu va duce la ntreruperea conexiunilor n curs In faza a treia cnd lungimea cozii a depit Max, routerul opereaz n faza de congestie i fiecare pachet nou sosit este eliminat
P(drop) 1

Pmax Min Max avg

Figura 7 Algoritmul RED de management al cozilor Dei algorimul RED ndeplinete condi ia necesar, aceea de reducere a probabilit ii de congestie, are totui un neajuns important i anume acela c nu face distinc ie ntre fluxurile de trafic normale i fluxurile agresive care n caz de congestie au tendin a s acapareze toate resursele disponibile

Random early drop with In/Out - RIO

Algoritmul RIO este o variant modificat a lui RED n sensul c folosete dou cozi, una numit Out i una numit In
P(drop In) P(drop Out)

1 Pmax_o ut Pmax_in Min_in Max_in avg_in Min_out Max_out avg_total

Figura 8 Algoritmul RIO pentru cele dou cozi In i Out La sosirea unui pachet ntr-un router RIO acesta este clasificat dup ncadrarea n clasa de trafic asociat Pachetele care apar in unui flux ce se ncadreaz n parametrii sunt trimise n coada numit In i au o probabilitate de eliminare mai mic Pachetele ce apar in unor fluxuri mai "dezordonate" i nu se ncadreaz n profilul de trafic asociat sunt trimise n coada Out
18

Probabilitatea de eliminare a pachetelor din coada In depinde de avg in, iar probabilitatea de eliminare a pachetelor depinde de avg total care reprezint dimensiunea total a cozilor Dup cum se observ i n figur, algoritmul RIO elimin mai agresiv pachetele din coada Out n cele trei faze de func ionare Mai nti pachetele Out sunt eliminate mult mai repede dect pachetele din coada In prin alegerea parametrului Max out mai mic dect Max in In al doile rnd, n faza de evitare a congestiei, probabilitatea de eliminare este mai mare, stabilit prin valoarea parametrului Pmax out mai mare dect Pmax in In a treia faz, atunci cnd congestia s-a produs prin alegerea lui Max out mai mic dect Max in In esen , algoritmul RIO elimin pachetele Out mult mai devreme dect RED cnd detecteaz o congestie, elimin toate Out cnd o congestie s-a produs i doar n ultim instan elimin i pachete din coada In, n speran a controlrii congestiei Intr-o re ea, eliminarea frecvent de pachete din coada In, este un semn c trebuie alocate mai multe resurse

Concluzii
Necesitatea de asigurare a calita ii serviciilor n re elele IP a impus cutarea unor solu ii la aceast problem care devine tot mai acut Dac n decada anterioar priorit ile erau de simpl conectare a sistemelor, acum noile aplica ii de VoIP i video over IP mecesit din ce n ce mai mult implementarea unor mecanisme de garantare a l imii de band Printre primele solu ii propuse se numr i IntServ care i-a propus implementarea unui mecanism de asigurare a QoS de la un cap la cellalt al re elei, folosindu-se de RSVP ca mijloc de rezervare a l imii de band Din nefericire, pentru a implementa IntServ, complexitatea routerelor trebuie s creasc semnificativ, devenind deosebit de dificil de construit routere de mare vitez care s satisfac specifica iile IntServ Mai mult, pentru ca IntServ s func ioneze ar trebui ca toate routerele din Internet s fie transformate n routere IntServ, lucru pu in probabil a se ntmpla vreodat Deocamdat unele routere au suport RSVP implementat, dar mai mult cu titlu experimental, pentru construirea unor re ele de mici dimensiuni Experien a modelului IntServ a scos n eviden necesitatea ca mecanismele de asigurare a QoS s fie implementate cu predilec ie spre marginea re elei, unde fluxurile de date sunt mai pu ine i unde se pot implementa algoritmi mai sofistica i, lsnd pe ct posibil centrul re elei neschimbat Un mecanism mai nou aprut, i anume DiffServ, ine cont de aceste necesit i i ofer posibilitatea de a garanta calitatea serviciilor pentru fluxuri agregate de date, lucru mai uor de realizat dect garantarea QoS pentru fiecare flux individual, dar nu la fel de eficace DiffServ aprut mai recent, primele secifica ii datnd din 1998 (RFC 2430), este deja implementat n re elele majorit ii providerilor de Internet i suportat mai de toate routerele actuale Din nefericire, DiffServ este mai mult un pas nainte, dar limitele sale l fac inapt pentru a fi o solu ie comlplet a acestei probleme In momentul scrierii acestui material cele mai mari anse de succes n viitor se pare c le are MPLS Acesta, din concep ie, ofer protec ia fiecrui flux de date fr a crete numrul de overhead-ul de prelucrare al routerelor Ba chiar mai mult, un switch MPLS se poate implementa direct n siliciu permi nd lucrul la viteze cu un ordin de mrime mai mari dect al unui router
19

Fluxurile de date printr-o re ea MPLS sunt n mod natural separate, un mecanism de tipul IntServ poate fi realizat n mod natural i mult mai eficient dect o implementare ntr-un router IP Faptul ca MPLS este vzut ca tehnologia de re ea a noului deceniu permite ca toate mecanismele importante de asigurare a QoS s fie deja opera ionale n noile echipamente MPLS la momentul instalrii lor n teren Indiferent ce metod de asigurare a QoS este sau va fi implementat n re elele IP, o problem acut trebuie rezolvat cu acest prilej i anume trebuie s se asigure eficient un mecanism de securitate pentru a preveni apari ia unor atacuri de tip DoS prin rezervarea de resurse peste capacitatea re elei Mai mult, un client i poate depi n mod fraudulos resursele la care are dreptul, ceea ce trebuie de asemeni prentmpinat

20

Acronime i abrevieri
AS BB COS CR-LDP DoS DS DSCP FIFO FTP IETF LER LSR MIB MPLS MTU PDP PEP PHB RED QoS RIO RSVP RSVP-TE VoIP SNMP SLA TCA TOS TTL Autonomous System (Sistem Autonom) Bandwidth Broker Class of Service Constraint Routing by Label Distribution Protocol Denial of Services Differentiated Service Differentiated Service CodePoint First-In First-Out File Transfer Protocol Internet Engineering Task Force Label Edge Router Label Switch Router Management Interface Database Multiprotocol Label Switching Maximum Transmit Unit Policy Decision Point Policy Enforcement Point Per Hop Behavior Random Early Drop Quality of Services RED with In/Out Resource Reservation Protocol Resource reSerVation Protocol Traffic Engineering Voice over IP Simple Network Management Protocol Service Level Agreement Traffic Conditioning Agreement Type Of Service Time To Live

21

Bibliografie
1 "Stateless Core: A Scalable Approach for Quality of Service in the Internet" - Ion Stoica, Carnegie Mellon University, decembie 2000 2 "Re ele de calculatoare: o abordare sistemic" - Larry L Peterson, Bruce S Davie, ed ALL Bucureti 2001 3 "Random Early Detection Gateways for Congestion Avoidance" - Sally Floyd and Van Jacobson, IEEE/ACM August 1993 4 "RSVP and Integrated Services in the Internet: A Tutorial" - Paul P White, IEEE Communications Magazine May 1997 5 "Vendor - Independent Bandwidth Broker Architecture for DiffServ Networks" Octavian Pop, Tamas Mahr, Timea Dreilinger, Robert Szabo, IEEE/ICT 2000 6 "Internet Quality of Service: an Overview" - Weibin Zhao, David Olshefski, Henning Schulzrinne, Columbia University 7 "The Integrated Services in the Internet: State of the Art" - Paul P White, Jon Crowcroft 8 "QoS/Policy/Constraint Based Routing" - Wei Sun 9 RFC 1633 - Integrated Services in the Internet Architecture: an Overview 10 RFC 2205 - Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification 11 RFC 2208 - Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment 12 RFC 2209 - Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing 13 RFC 2210 - The Use of RSVP with IETF Integrated Services 14 RFC 2215 - General Characterization Parameters for Integrated Service Network Elements 15 RFC 2430 - A Provider Architecture for Differentiated Services and Traffic Engineering 16 RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers 17 RFC 2475 - An Architecture for Differentiated Services 18 RFC 2963 - A Rate Adaptive Shaper for Differentiated Services 19 RFC 2983 - Differentiated Services and Tunnels 20 RFC 2998 - A Framework for Integrated Services Operation over Diffserv Networks 21 RFC 3086 - Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification 22 "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment" Internet2 Qbone BB Advisory Council 23 "Explicit Allocation of Best Effort Packet Delivery Service" - David D Clark, Wenjia Fang 24 "A Comparison Of MPLS Traffic Engineering Initiatives" - Robert Pulley, Peter Christensen, Netplane System Inc 2000 25 "TCP/IP Tutorial and Technical Overview" - Martin W Murhammer, Orcun Atakan, Stefan Bretz, Larry R Pugh, Kazunari Suzuki, David H Wood, IBM Corporation, octombrie 1998

22