Resursu rezervēšanas protokols

Resursu rezervēšanas protokols (RSVP) ir transporta slāņa protokols, kas izstrādāts, lai rezervētu resursus tīklā, izmantojot integrēto pakalpojumu modeli. RSVP darbojas, izmantojot IPv4 vai IPv6, un nodrošina uztvērēja iniciētu resursu rezervāciju iestatīšanu multiraides vai vienraides datu plūsmām. Tas netransportē lietojumprogrammas datus, bet ir līdzīgs vadības protokolam, piemēram, interneta vadības ziņojumu protokols (ICMP) vai interneta grupas pārvaldības protokols (IGMP). RSVP ir aprakstīta RFC 2205.

RSVP var izmantot resursdatoru un maršrutētāju, lai pieprasītu vai sniegtu noteiktus pakalpojumu kvalitātes (QoS) līmeņus lietojumprogrammu datu straumēm. RSVP nosaka, kā lietojumprogrammas veic rezervāciju un kā tās var atteikties no rezervētajiem resursiem, kad tie vairs nav nepieciešami. Veicot RSVP operācijas, resursi parasti tiek rezervēti katrā ceļa mezglā. RSVP nav maršrutēšanas protokols, bet tika izveidots, lai sadarbotos ar pašreizējiem un turpmākajiem maršrutēšanas protokoliem.

RSVP pati par sevi reti tiek izvietota telekomunikāciju tīklos. 2003. gadā attīstība tika novirzīta no RSVP uz RSVP-TE teletraffic inženierijai. Nākamais solis signalizēšanā (NSIS) bija ierosināts RSVP aizstājējs.

Galvenie atribūti

1. RSVP pieprasa līdzekļus vienkāršajām plūsmām: satiksmes plūsma tikai vienā virzienā no sūtītāja uz vienu vai vairākiem uztvērējiem.
2. RSVP nav maršrutēšanas protokols, bet strādā ar pašreizējiem un turpmākajiem maršrutēšanas protokoliem.
3. RSVP ir orientēts uz uztvērēju, jo datu plūsmas saņēmējs sāk un uztur resursu rezervāciju šai plūsmai.
4. RSVP uztur neelastīgu stāvokli (rezervācijai katrā mezglā nepieciešama periodiska atsvaidzināšana) resursdatora un maršrutētāju resursu rezervēšanai, tādējādi atbalstot dinamisku automātisku pielāgošanos tīkla izmaiņām.
5. RSVP nodrošina vairākus rezervācijas stilus (rezervācijas opciju kopu) un ļauj protokola pārskatījumos pievienot nākotnes stilus, lai tie ietilptu dažādās lietojumprogrammās.
6. RSVP transportē un uztur satiksmes un politikas kontroles parametrus, kas ir necaurspīdīgi RSVP

Vēsture un saistītie standarti

RSVP pamatjēdzieni sākotnēji tika ierosināti [RSVP93] (Zhang, L., Deering, S., Estrin, D., Shenker, S., un D. Zterrible, “RSVP: A New Resource ReSerVation Protocol”, IEEE Network, celebrating 1993).

RSVP ir aprakstīta RFC dokumentu sērijā no IETF :

• RFC 2205: 1. versijas funkcionālā specifikācija aprakstīta RFC 2205 (Sept. 1997) pēc IETF. 1. versijā aprakstīta uzņemšanas (trafika) vadīklas saskarne, kuras pamatā ir “tikai” resursu pieejamība. Vēlāk RFC2750 pagarināja uzņemšanas kontroles atbalstu.
• RFC 2210 definē RSVP izmantošanu ar vadāmas slodzes RFC 2211 un garantētiem RFC 2212 QoS kontroles pakalpojumiem. Detalizētāka informācija integrētajos pakalpojumos. Definē arī RSVP RFC 2205 definēto datu objektu lietojumu un datu formātu (kas satur resursu rezervēšanas informāciju).
• RFC 2211 norāda tīkla elementu darbību, kas nepieciešama, lai nodrošinātu vadāmas slodzes pakalpojumus.
• RFC 2212 norāda tīkla elementu darbību, kas nepieciešama garantēto QoS pakalpojumu sniegšanai.
• RFC 2750 apraksta ierosināto pagarinājumu vispārējai uz politiku balstītai uzņemšanas kontrolei RSVP. Paplašinājums ietvēra politikas objektu specifikāciju un aprakstu par politikas notikumu apstrādi. (2000. gada janvāris).
• RFC 3209, “RSVP-TE: RSVP pagarinājumi LSP tuneļiem” (2001. gada decembris).
• RFC 3473, “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions” (2003. gada janvāris).
• RFC 3936 “Workers reSerVation Protocol (RSVP) izmaiņu kārtība” (2004. gada oktobris) apraksta pašreizējo paraugpraksi un nosaka RSVP modificēšanas procedūras.
• RFC 4495, “RESURSU rezervēšanas protokola (RSVP) paplašinājums rezervēšanas plūsmas joslas platuma samazināšanai” (2006. gada maijs), paplašina RSVP, lai ļautu samazināt esošās rezervācijas joslas platumu, nevis samazināt rezervāciju.
• RFC 4558, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement" (June 2006).

Galvenie jēdzieni

Divi galvenie RSVP rezervācijas modeļa jēdzieni ir plūsmas specifika un filtru specifika:

Plūsmas specifika

RSVP patur resursus plūsmai. Plūsmu identificē mērķa adrese, protokola identifikators un, pēc izvēles, galamērķa ports. Vairāku protokolu etiķešu komutācijā (MPLS) plūsma tiek definēta kā iezīmes pārslēgšanās ceļš (LSP). Attiecībā uz katru plūsmu RSVP norāda arī konkrēto plūsmas nepieciešamo pakalpojuma kvalitāti, lai gan tā nesaprot plūsmas QoS īpašo informāciju. Šī QoS specifiskā informācija tiek saukta par plūsmas specifikāciju, un RSVP nodod plūsmas specifikācijas no lietojumprogrammas uz resursdatoriem un maršrutētājiem pa ceļu. Šīs sistēmas pēc tam analizē plūsmas specifikācijas, lai pieņemtu un rezervētu resursus. Plūsmas specifikācijas sastāv no:

1. Servisa klase
2. Rezervācijas specifikācija — definē QoS
3. Trafika specifikācija — apraksta datu plūsmu

Filtru specifika

Filterspeci nosaka pakešu kopumu, ko ietekmē plūsmas specifikācija (t. i., datu paketes, lai saņemtu QoS, ko nosaka plūsmas specifikācija). Filtru specifikācija parasti atlasa visu mezgla apstrādāto pakešu apakškopu. Atlase var būt atkarīga no jebkura pakešu atribūta (piemēram, sūtītāja IP adreses un porta).

Pašlaik definētie RSVP rezervācijas stili ir:

1. Fiksēts filtrs — rezervē resursus konkrētai plūsmai.
2. Dalīti skaidri — rezervē resursus vairākām plūsmām un visiem dala resursus
3. Savvaļas kartes filtrs — rezervē resursus vispārējam plūsmas tipam, nenorādot plūsmu; visas plūsmas dala resursus

RSVP rezervācijas pieprasījums sastāv no plūsmas specifikācijas un filtru specifikācijas, un abi tiek saukti par flowdescriptor. Katras specifikācijas mezgla efekti ir tādi, ka, kamēr plūsmas specifikācija iestata pakešu plānotāja parametrus mezglā, filterspeci iestata parametrus pakešu klasifikatorā.

Ziņojumi

Ir divi primārie ziņojumu tipi:

• Ceļa ziņojumi (ceļš)

Ceļa ziņojums tiek nosūtīts no sūtītāja resursdatora pa datu ceļu un saglabā ceļa stāvokli katrā ceļa mezglā. Ceļa stāvoklis ietver iepriekšējā mezgla IP adresi un dažus datu objektus:

1. sūtītāja veidne sūtītāja datu formāta aprakstīšanai Filterspeca formā
2. sūtītāja tspec, lai aprakstītu datu plūsmas datplūsmas raksturlielumus
3. adspec, kas satur reklāmas datus (sīkāku informāciju skatīt RFC 2210).

• Rezervēšanas ziņojumi (Rezerv)

Rezervēšanas ziņojums tiek nosūtīts no saņēmēja uz sūtītāja resursdatoru pa apgriezto datu ceļu. Katrā zarā rezervēšanas ziņojuma IP galamērķa adrese tiek mainīta uz pretēja ceļa nākamā mezgla adresi un IP avota adresi uz apgrieztā ceļa iepriekšējās mezgla adreses adresi.

Rezervēšanas ziņojumā ir iekļauts plūsmas specifikas datu objekts, kas identificē plūsmas nepieciešamos resursus.

Darbība

RSVP resursdators, kuram jāsūta datu plūsma ar konkrētu QoS, pārraidīs RSVP ceļa ziņojumu ik pēc 30 sekundēm, kas pārvietosies pa viena vai vairāku maršrutu maršrutiem, kas iepriekš noteikti darba maršrutēšanas protokolā. Ja ceļa ziņojums nonāk pie maršrutētāja, kas nesaprot RSVP, šis maršrutētājs pārsūta ziņojumu, neinterpretējot ziņojuma saturu, un nerezervēs resursus plūsmai.

Tie, kas vēlas tos noklausīties, nosūta atbilstošu (“Rezervēt”) ziņojumu, kas pēc tam izseko ceļu atpakaļ sūtītājam. Rezv ziņojumā ir plūsmas spektri. Kad maršrutētājs saņem RSVP rezv ziņojumu, tas:

1. Veiciet rezervāciju, pamatojoties uz pieprasījuma parametriem. Šim nolūkam ievades kontrole un politikas kontrole apstrādā pieprasījuma parametrus un var likt pakešu klasifikatoram pareizi apstrādāt atlasīto datu pakešu apakškopu vai vienoties ar augšējo slāni par to, kā jāveic pakešu apstrāde. Ja viņi nevar atbalstīt pieprasīto rezervāciju, viņi nosūta noraidījuma ziņojumu, lai klausītājs par to zinātu.
2. Pārsūtiet pieprasījumu uz augšu (sūtītāja virzienā). Katrā mezglā pārsūtīšanas ziņojuma plūsmas specifikāciju var modificēt ar pārsūtīšanas mezglu (piemēram, multiraides plūsmas rezervācijas gadījumā rezervācijas pieprasījumus var sapludināt).
3. Tad maršrutētāji noglabā plūsmas veidu un arī to uztic policijai. Tas viss tiek darīts mīkstā stāvoklī, tāpēc, ja noteiktu laiku nekas netiek dzirdēts, tad lasītājam laiks beigsies un rezervācija tiks atcelta. Tas novērš problēmu, ja vai nu sūtītājs, vai uztvērējs sabrūk, vai tiek izslēgts nepareizi, iepriekš neatceļot rezervāciju. Individuālie maršrutētāji pēc savas izvēles var pārbaudīt datplūsmu, lai pārbaudītu, vai tā atbilst plūsmas instrukcijām.

Rezv ziņojumam ir arī FilterSpec objekts; tas definē paketes, kas saņems pieprasīto QoS, kas definēts plūsmas specifikācijā. Vienkārša filtra specifikācija var būt tikai sūtītāja IP adrese un pēc izvēles tā UDP vai TCP ports.

Citi līdzekļi

• Integritāte — RSVP ziņojumiem tiek pievienots ziņojuma īssavilkums, kas izveidots, apvienojot ziņojuma saturu un koplietojamo atslēgu, izmantojot ziņojuma īssavilkuma algoritmu (parasti Saites MD5). Atslēgu var izplatīt un apstiprināt, izmantojot 2 ziņojumu veidus: integritātes apstrīdēšanas pieprasījumu un integritātes problēmu atbildi.
• Kļūdas uzrādīšana — kad mezgls konstatē kļūdu, kļūdas ziņojums tiek ģenerēts ar kļūdas kodu un tiek izplatīts atpakaļ pa straumi atpakaļgaitā uz sūtītāju.
• Informācija par RSVP plūsmu — divu veidu diagnostikas ziņojumi ļauj tīkla operatoram pieprasīt RSVP stāvokļa informāciju par noteiktu plūsmu.
• Diagnostikas iekārta — standarta paplašinājums, kas ļauj lietotājam iegūt informāciju par RSVP stāvokli ceļā. RFC2745 — RSVP diagnostikas ziņas

Atsauces

• John Evans, Clarence Filsfils. Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Morgan Kaufmann, 2007. ISBN 978-0-12-370549-5.

Ārējās saites

• "Resursu rezervēšanas protokols". Cisco. Retrieved 2011-02-16.
• RFC 2205
• RFC 2210
• RFC 2211
• RFC 2212
• RFC 2750
• RFC 3209
• RFC 3473
• RFC 3936
• RFC 4495
• RFC 4558