Integrerede tjenester ( engelsk Integrated services, IntServ ) - i computernetværk , en ressourcestyringsarkitektur, der giver en given servicekvalitet ( QoS ). Metoden, der anvendes af integrerede tjenester, kræver en protokolarkitektur, der er svær at skalere. Problemet med skalerbarhed er relateret til princippet om drift af integrerede tjenester, hvor ende-til-ende reservation af ressourcer udføres i alle elementer, der udgør netværkslaget af applikationen.
Internettets bemærkelsesværdige vækst har ført til en betydelig stigning i trafikken. Fremkomsten af nye typer applikationer, såsom webapplikationer, video i realtid, IP-telefoni og mange andre, har tvunget specialister til at lede efter nye måder at kontrollere netværkstrafikken på. En af de seneste beslutninger var brugen af integrerede tjenester, der kombinerer alle de foreslåede løsninger.
Standardprotokollerne for TCP/IP-stakken yder service i det omfang det er muligt og giver samme prioritet til alle anmodninger. Ved transport af streaming medietrafik (VoIP, lyd- og videokonferencer m.fl.) eller datatrafik med forskellige båndbreddekrav over det samme netværk, er det nødvendigt at kunne behandle og klassificere forskellige typer netværkstrafik, enten afhængigt af kravene eller indhold. Ikke-garanteret levering indebar ingen trafikdifferentiering og gav ikke pålidelig levering, garanteret kanalkapacitet eller lavt pakketab.
For at løse alle ovennævnte problemer med ikke-garanteret levering blev følgende to kvalitetsservicemodeller [1] oprettet :
Før du afslører dette emne, er det værd at definere begrebet flow . Vi forstår ved "flow" kontinuerlig trafik genereret af en bruger eller applikation og kræver den samme servicekvalitet. I IPv4 -versionen bestemmes flowet ved transportlaget for den protokol, der bruges (enten TCP eller UDP ) gennem portene og IP-adresserne på kilden og destinationen. IPv6 - versionen har også et felt specielt oprettet til denne funktion, som sammen med dens kilde- og destinationsadresser karakteriserer flowet. Dette felt kaldes stream-etiketten.
Inden for rammerne af den integrerede servicemodel kan følgende vigtige undersystemer skelnes [1] :
Som tidligere nævnt, før information sendes gennem netværket, reserveres ressourcer i overensstemmelse med den krævede servicekvalitet. Ved servicering af et nyt flow laves erklæringen om servicekvalitetskrav (ved serviceanmodningsspecifikation - RSPEC ), og karakteristikaene for den trafik, der skal sendes gennem netværket (ved trafikspecifikation - TSPEC ), opnås. Hvis routeren ikke har nok ledige ressourcer til at servicere et nyt flow, vil et sådant flow blive afvist. Hvis kravene til det nye flow kan opfyldes, instruerer routeren skemalæggeren og pakkeklassifikatoren om at reservere en del af deres ressourcer for at levere den servicekvalitet, der kræves til dette flow.
I RSPEC kan der skelnes mellem følgende flowservicekategorier:
RSPEC og TSPEC leveres af RSVP -netværksressourcereservationsprotokollen .
Pakkeklassifikatoren identificerer flowpakker på routere. Hver indgående pakke tilhører en bestemt klasse. Da pakker er opdelt i klasser, modtager de samme behandling for deres klasse fra pakkeplanlæggeren. Valget af en specifik klasse afhænger af afsenderens og modtagerens prioriteter, IP-adressen og portnummeret i pakkehovedet. Som regel hører tråde af samme type til samme klasse.
Pakkeplanlæggeren, ved hjælp af køstyringssystemet, regulerer afsendelsen af pakker til routere i overensstemmelse med klassifikationen nævnt ovenfor og servicekvalitetsparametrene specificeret for hvert flow. Pakkeplanlæggeren skal fungere på det punkt, hvor pakker er i kø. Dette punkt er normalt linklagsprotokollerne i routerens operativsystem.
For at undgå afbrydelser i netværket er der sørget for overbelastningskontrol. Der er tre metoder til at implementere overbelastningskontrol ved at ekskludere pakker:
RSVP , eller Resource Reservation Protocol, er en mærkningsprotokol, der giver brugerne mulighed for at kommunikere deres krav til pålidelighed og effektivitet til netværket. På trods af at RSVP er en simplex-protokol, det vil sige, at redundans kun forekommer i én retning, blev den udtænkt til dupleksforbindelser. For en dupleksforbindelse, såsom lyd- eller videokonferencer, hvor hver part er både en afsender og en modtager, sendes en ressourcereservationsanmodning til RSVP af begge endepunkter.
Inden for rammerne af RSVP-protokollen anvendes begrebet " sti " ( eng. PATH ). En sti er den rute, som pakker tager gennem forskellige routere fra afsenderen til destinationen. Ressourcereservationer foretages langs denne rute. Alle pakker af den samme strøm vil følge den samme sti. Stien bestemmes, når afsenderen sender en RSVP-besked, en såkaldt stibesked. Den indeholder information om trafikkvaliteten af tjenesten for et givet flow. Fordi RSVP ikke er en routingprotokol, bruger den information fra hver routers routingtabeller til at levere stimeddelelsen så hurtigt som muligt [1] .
Formatet på PATH -meddelelsen er som følger (dataene i firkantede parenteser er valgfrie):
Common Header, [Integrity], Session, RSVP_Hop, Time Values, [Policy_Data], Sender Template, Sender_Tspec, [ADSPEC]Efter at have modtaget stimeddelelsen, er routerne klar til at reservere ressourcer til flowet. For at reservere visse QoS -parametre sender modtageren en RESV -meddelelse . Hver enhed, der understøtter RSVP-protokollen, kender allerede adressen på den forrige enhed langs ruten, så RESV-meddelelsen går tilbage til afsenderen og fortæller transit-routerne de nødvendige parametre til at reservere ressourcer.
Formatet på RESV -meddelelsen er som følger:
Fælles header, [Integritet], Session, RSVP_Hop, Tidsværdier, [Reso_Confirm], [Scope], Style, Flow Descriptor ListNogle præciseringer:
Det skal bemærkes, at denne metode til at reservere ressourcer kun er mulig, hvis alle margrutizere langs ruten understøtter RSVP-protokollen. I mangel af RSVP-understøttelse kan en mellemrouter muligvis opfylde QoS-kravene, afhængigt af dens belastning. Den komplette RSVP-protokolspecifikation er defineret i RFC-2205.
Selvom ideen om IntServ og RSVP var meget lovende i midten af 1990'erne, forsvandt interessen for denne arkitektur med tiden. Hovedårsagen var skalerbarhedsproblemet forårsaget af behovet for at gemme og vedligeholde oplysninger om transmissionstilstand i hver router. Dette problem, overført til WAN'er såsom internettet, fjerner RSVP fra virkeligheden. Men på det seneste har der været fornyet snak om at bruge RSVP i MPLS eller i transportteknik, da trafikværdien i disse tilfælde er lille, hvilket gør det mere overskueligt og reducerer omkostningerne til udstyr.