Servicii integrate ( English Integrated services, IntServ ) - în rețelele de calculatoare , o arhitectură de gestionare a resurselor care oferă o anumită calitate a serviciului ( QoS ). Metoda utilizată de serviciile integrate necesită o arhitectură de protocol greu de scalat. Problema scalabilității este legată de principiul funcționării serviciilor integrate, timp în care se realizează rezervarea end-to-end a resurselor în toate elementele care alcătuiesc stratul de rețea al aplicației.
Creșterea remarcabilă a internetului a dus la o creștere semnificativă a traficului. Apariția de noi tipuri de aplicații, precum aplicațiile web, video în timp real, telefonia IP și multe altele, i-a forțat pe specialiști să caute noi modalități de control al traficului în rețea. Una dintre deciziile recente a fost utilizarea serviciilor integrate care să combină toate soluțiile propuse.
Protocoalele standard ale stivei TCP/IP oferă servicii în măsura posibilului și acordă aceeași prioritate tuturor solicitărilor. Atunci când transportați trafic media de streaming (VoIP, conferințe audio și video și altele) sau trafic de date cu cerințe diferite de lățime de bandă pe aceeași rețea, este necesar să puteți procesa și clasifica diferite tipuri de trafic de rețea, fie în funcție de cerințe, fie de continut. Livrarea negarantată nu a implicat nicio diferențiere a traficului și nu a oferit livrare fiabilă, capacitate garantată a canalului sau pierderi reduse de pachete.
Pentru a rezolva toate problemele de mai sus de livrare negarantată, au fost create următoarele două modele de calitate a serviciilor [1] :
Înainte de a dezvălui acest subiect, merită să definiți conceptul de flux . Vom înțelege prin „flux” traficul continuu generat de un utilizator sau aplicație și care necesită aceeași calitate a serviciului. În versiunea IPv4 , fluxul este determinat la nivelul de transport al protocolului utilizat (fie TCP , fie UDP ) prin porturile și adresele IP ale sursei și destinației. Versiunea IPv6 are și un câmp special creat pentru această funcție, care, alături de adresele sale sursă și destinație, caracterizează fluxul. Acest câmp se numește eticheta fluxului.
În cadrul modelului de servicii integrate se pot distinge următoarele subsisteme importante [1] :
După cum am menționat mai devreme, înainte de a trimite informații prin rețea, resursele sunt rezervate în conformitate cu calitatea cerută a serviciului. La deservirea unui nou flux se realizează declarația cerințelor de calitate a serviciului (prin specificația de solicitare a serviciului - RSPEC ) și se obțin caracteristicile traficului care ar trebui trimis prin rețea (prin specificația de trafic - TSPEC ). Dacă routerul nu are suficiente resurse libere pentru a deservi un nou flux, un astfel de flux va fi respins. Dacă cerințele noului flux pot fi satisfăcute, atunci ruterul instruiește planificatorul și clasificatorul de pachete să rezerve o parte din resursele lor pentru a oferi calitatea serviciului necesară pentru acest flux.
În RSPEC, se pot distinge următoarele categorii de servicii de flux:
RSPEC și TSPEC sunt furnizate de protocolul de rezervare a resurselor de rețea RSVP .
Clasificatorul de pachete identifică pachetele de flux pe routere. Fiecare pachet primit aparține unei anumite clase. Fiind împărțite în clase, pachetele primesc aceeași procesare pentru clasa lor de la planificatorul de pachete. Alegerea unei clase specifice depinde de prioritățile expeditorului și destinatarului, adresa IP și numărul portului din antetul pachetului. De regulă, firele de același tip aparțin aceleiași clase.
Planificatorul de pachete, folosind sistemul de management al cozilor, reglează trimiterea pachetelor către routere în conformitate cu clasificarea menționată mai sus și cu parametrii de calitate a serviciului specificați pentru fiecare flux. Programatorul de pachete trebuie să funcționeze în punctul în care pachetele sunt puse în coadă. Acest punct este de obicei protocoalele stratului de legătură din sistemul de operare al routerului.
Pentru a evita întreruperile în rețea, se asigură controlul congestiei. Există trei metode pentru implementarea controlului congestiei prin excluderea pachetelor:
RSVP , sau Protocolul de rezervare a resurselor, este un protocol de marcare care permite utilizatorilor să comunice rețelei cerințele de fiabilitate și eficiență. În ciuda faptului că RSVP este un protocol simplex, adică redundanța are loc într-o singură direcție, a fost conceput pentru conexiuni duplex. Pentru o conexiune duplex, cum ar fi o conferință audio sau video, în care fiecare parte este atât un expeditor, cât și un receptor, o solicitare de rezervare a resurselor către RSVP este trimisă de ambele puncte finale.
În cadrul protocolului RSVP, este utilizat conceptul de „ cale ” ( ing. PATH ). O cale este ruta pe care o parcurg pachetele prin diferite routere de la expeditor la destinație. Rezervările de resurse se fac de-a lungul acestui traseu. Toate pachetele din același flux vor urma aceeași cale. Calea este determinată atunci când expeditorul trimite un mesaj RSVP, așa-numitul mesaj cale. Conține informații despre calitatea traficului serviciului pentru un anumit flux. Deoarece RSVP nu este un protocol de rutare, folosește informații din tabelele de rutare ale fiecărui router pentru a livra mesajul de cale cât mai curând posibil [1] .
Formatul mesajului PATH este următorul (datele dintre paranteze drepte sunt opționale):
Antet comun, [Integritate], Sesiune, RSVP_Hop, Valori de timp, [Policy_Data], Sender Template, Sender_Tspec, [ADSPEC]După primirea mesajului de cale, routerele sunt gata să rezerve resurse pentru flux. Pentru a rezerva anumiți parametri QoS , receptorul trimite un mesaj RESV . Fiecare dispozitiv care acceptă protocolul RSVP știe deja adresa dispozitivului anterior de-a lungul traseului, astfel încât mesajul RESV se întoarce la expeditor și le spune ruterelor de tranzit parametrii necesari pentru rezervarea resurselor.
Formatul mesajului RESV este următorul:
Antet comun, [Integritate], Sesiune, RSVP_Hop, Valori de timp, [Reso_Confirm], [Scope], Stil, Listă de descrieri de fluxCâteva precizări:
Trebuie remarcat faptul că această metodă de rezervare a resurselor este posibilă numai dacă toate margrutizerele de-a lungul rutei acceptă protocolul RSVP. În absența suportului RSVP, un router intermediar poate îndeplini sau nu cerințele QoS, în funcție de sarcina sa. Specificația completă a protocolului RSVP este definită în RFC-2205.
Deși ideea de IntServ și RSVP era foarte promițătoare la mijlocul anilor 1990, interesul pentru această arhitectură a dispărut în timp. Motivul principal a fost problema de scalabilitate cauzată de necesitatea de a stoca și menține informațiile despre starea transmisiei în fiecare router. Această problemă, transferată la WAN-uri precum Internetul, îndepărtează RSVP de realitate. Cu toate acestea, recent se vorbește din nou despre utilizarea RSVP în MPLS sau în ingineria transporturilor, deoarece în aceste cazuri valoarea traficului este mică, ceea ce îl face mai ușor de gestionat și reduce costul echipamentelor.