Integroidut palvelut ( englanniksi Integrated services, IntServ ) - tietokoneverkoissa resurssienhallintaarkkitehtuuri, joka tarjoaa tietyn palvelunlaadun ( QoS ). Integroitujen palveluiden käyttämä menetelmä vaatii vaikeasti skaalautuvaa protokolla-arkkitehtuuria. Skaalautuvuusongelma liittyy integroitujen palveluiden toimintaperiaatteeseen, jonka aikana resurssien end-to-end -varaus suoritetaan kaikissa elementeissä, jotka muodostavat sovelluksen verkkokerroksen.
Internetin merkittävä kasvu on johtanut liikenteen merkittävään kasvuun. Uudentyyppisten sovellusten, kuten web-sovellusten, reaaliaikaisen videon, IP-puhelimen ja monien muiden ilmaantuminen on pakottanut asiantuntijat etsimään uusia tapoja hallita verkkoliikennettä. Yksi viimeaikaisista päätöksistä oli integroitujen palveluiden käyttö, jotka yhdistävät kaikki ehdotetut ratkaisut.
TCP/IP-pinon standardiprotokollat tarjoavat palvelua siinä määrin kuin mahdollista ja antavat saman prioriteetin kaikille pyynnöille. Kun siirretään suoratoistomedialiikennettä (VoIP, ääni- ja videoneuvottelut yms.) tai dataliikennettä erilaisilla kaistanleveysvaatimuksilla saman verkon kautta, on välttämätöntä pystyä käsittelemään ja luokittelemaan erityyppistä verkkoliikennettä joko vaatimusten tai vaatimusten mukaan. sisältöä. Takaamaton toimitus ei merkinnyt liikenteen eriyttämistä eikä tarjonnut luotettavaa toimitusta, taattua kanavakapasiteettia tai pientä pakettihäviötä.
Kaikkien yllä olevien ei-takuutoimitusten ongelmien ratkaisemiseksi luotiin seuraavat kaksi palvelun laatumallia [1] :
Ennen tämän aiheen paljastamista on syytä määritellä virtauksen käsite . Ymmärrämme "virralla" jatkuvaa liikennettä, joka on käyttäjän tai sovelluksen tuottama ja joka vaatii samaa palvelun laatua. IPv4 - versiossa virtaus määritetään käytettävän protokollan siirtokerroksessa (joko TCP tai UDP ) lähteen ja kohteen porttien ja IP-osoitteiden kautta. IPv6 - versiossa on myös erityisesti tätä toimintoa varten luotu kenttä, joka lähde- ja kohdeosoitteidensa kanssa kuvaa kulkua. Tätä kenttää kutsutaan stream-tunnisteeksi.
Integroidun palvelumallin puitteissa voidaan erottaa seuraavat tärkeät osajärjestelmät [1] :
Kuten aiemmin mainittiin, ennen tiedon lähettämistä verkon kautta resurssit varataan vaaditun palvelun laadun mukaisesti. Uutta virtaa huollettaessa tehdään palvelun laatuvaatimuslausunto (palvelupyyntömäärittelyllä - RSPEC ) ja hankitaan verkon kautta lähetettävän liikenteen ominaisuudet (liikennemääritelmällä - TSPEC ). Jos reitittimellä ei ole tarpeeksi vapaita resursseja uuden vuon palvelemiseen, tällainen vuo hylätään. Jos uuden vuon vaatimukset voidaan täyttää, reititin käskee ajoittajaa ja paketiluokittajaa varaamaan osan resursseistaan tämän vuon edellyttämän palvelun laadun tuottamiseksi.
RSPEC:ssä voidaan erottaa seuraavat virtauspalveluluokat:
RSPEC :n ja TSPEC :n tarjoaa RSVP -verkkoresurssien varausprotokolla .
Paketin luokitin tunnistaa reitittimien vuopaketit. Jokainen saapuva paketti kuuluu tiettyyn luokkaan. Luokkiin jaettuna paketit saavat saman käsittelyn luokkaansa varten pakettien ajoittajalta. Tietyn luokan valinta riippuu lähettäjän ja vastaanottajan prioriteeteista, IP-osoitteesta ja portin numerosta paketin otsikossa. Pääsääntöisesti samantyyppiset säikeet kuuluvat samaan luokkaan.
Pakettien skeduleri jononhallintajärjestelmää käyttäen säätelee pakettien lähettämistä reitittimille edellä mainitun luokituksen ja kullekin vuolle määritettyjen palvelun laatuparametrien mukaisesti. Pakettien ajoittajan on toimittava kohdassa, jossa paketit ovat jonossa. Tämä kohta on yleensä linkkikerroksen protokollat reitittimen käyttöjärjestelmässä.
Verkon katkosten välttämiseksi on tarjolla ruuhkanhallinta. On kolme tapaa toteuttaa ruuhkanhallinta sulkemalla pois paketit:
RSVP eli Resource Reservation Protocol on merkintäprotokolla, jonka avulla käyttäjät voivat viestiä luotettavuus- ja tehokkuusvaatimuksistaan verkkoon. Huolimatta siitä, että RSVP on simplex-protokolla, eli redundanssia esiintyy vain yhteen suuntaan, se on suunniteltu duplex-yhteyksiä varten. Duplex-yhteydessä, kuten ääni- tai videoneuvotteluissa, joissa kumpikin osapuoli on sekä lähettäjä että vastaanottaja, molemmat päätepisteet lähettävät resurssien varauspyynnön RSVP:lle.
RSVP-protokollan puitteissa käytetään käsitettä " polku " ( eng. PATH ). Polku on reitti, jonka paketit kulkevat eri reitittimien kautta lähettäjältä määränpäähän. Resurssivarauksia tehdään tällä reitillä. Kaikki saman virran paketit seuraavat samaa polkua. Polku määritetään, kun lähettäjä lähettää RSVP-sanoman, ns. polkuviestin. Se sisältää tietoa tietyn virtauksen palvelun liikenteen laadusta. Koska RSVP ei ole reititysprotokolla, se käyttää kunkin reitittimen reititystaulukoiden tietoja toimittaakseen polkusanoman mahdollisimman pian [1] .
PATH -sanoman muoto on seuraava (hakasulkeissa olevat tiedot ovat valinnaisia):
Yhteinen otsikko, [Integrity], Istunto, RSVP_Hop, aika-arvot, [politiikan_tiedot], Lähettäjämalli, Lähettäjä_Tspec, [ADSPEC]Saatuaan polkusanoman reitittimet ovat valmiita varaamaan resursseja kulkua varten. Tiettyjen QoS -parametrien varaamiseksi vastaanotin lähettää RESV -viestin . Jokainen RSVP-protokollaa tukeva laite tietää jo reitin varrella edellisen laitteen osoitteen, joten RESV-viesti kulkee takaisin lähettäjälle ja kertoo siirtoreitittimille tarvittavat parametrit resurssien varaamiseen.
RESV -viestin muoto on seuraava:
Yhteinen otsikko, [Eheys], Istunto, RSVP_Hop, Aika-arvot, [Reso_Confirm], [Scope], Tyyli, Flow Descriptor ListMuutama selvennys:
On huomattava, että tämä resurssien varaustapa on mahdollista vain, jos kaikki reitin varrella olevat marginaalit tukevat RSVP-protokollaa. Jos RSVP-tukea ei ole, välireititin voi täyttää tai ei täyttää QoS-vaatimukset kuormituksensa mukaan. Täydellinen RSVP-protokollaspesifikaatio on määritelty RFC-2205:ssä.
Vaikka ajatus IntServistä ja RSVP:stä oli erittäin lupaava 1990-luvun puolivälissä, kiinnostus tätä arkkitehtuuria kohtaan hiipui ajan myötä. Suurin syy oli skaalautuvuusongelma, joka aiheutui tarpeesta tallentaa ja ylläpitää lähetyksen tilatietoja jokaisessa reitittimessä. Tämä ongelma, joka on siirtynyt WAN-verkkoihin, kuten Internetiin, vie RSVP:n pois todellisuudesta. Viime aikoina on kuitenkin jälleen puhuttu RSVP:n käyttämisestä MPLS :ssä tai liikennetekniikassa, koska näissä tapauksissa liikenteen arvo on pieni, mikä tekee siitä hallittavamman ja alentaa laitekustannuksia.