Ursprunget till RSVP-protokollet kan spåras b a c k t o 1991, w h e n a t e m av n e t w o r k forskare, inklusive mig själv, började spela med en n u m b e r av paket schemaläggningsalgoritmer på D A R T N E T (DARPA Testbed NETwork), en nätverksprovbädd gjord av o p e n källa, arbetsstationsbaserade routrar. Eftersom schemaläggningsalgoritmer helt enkelt blandar pakethanteringsorder enligt vissa fastställda hastigheter eller prioriteringar för olika dataflöden, för att testa en schemaläggningsalgoritm krävs att man ställer in u p t h e lämplig kontroll s t a t e a t varje r o u t e r längs dataflödesvägarna. Jag utmanades att utforma ett set-up protokoll som kunde stödja både unicast en n d många-till-många multi-cast program. Detta arbete ledde till att RSVP föddes. Som ett signalprotokoll speciellt utformat för att köra över IP, skiljer RSVP sig från tidigare signalprotokoll på flera grundläggande sätt. De mest djupgående inkluderar en soft-state strategi, tvåvägs signalerande meddelandeutbyten, mottagare-baserad resursreservation, och att vara oberoende från alla andra relaterade komponenter i en QOS-stödarkitektur, såsom flödesspecifikation, inträdeskontroll, schemaläggning algoritm, och routing. Som anges i artikeln, "RSVP är främst ett fordon som används av applikationer för att kommunicera sina krav till nätet på ett robust och effektivt sätt, oberoende av de specifika kraven." Det har gått mer än 10 år sedan den ursprungliga idén först utformades. Under denna tidsperiod bidrog många människor till den ansträngning som har utvecklats RSVP från en labbleksak till ett föreslaget Internet Standard Protocol. Andra nyare protokollutvecklingar, såsom MPLS (Multi-Protocol Label Switching), VPN (Virtual Private Network) och OTN (Optic Transport Network), för att nämna några, har antagit eller övervägt RSVP för sin egen signalanvändning. Jag blev förbluffad av RSVP:s snabba antagande och utveckling av användningen. Protokollet har gått vidare med sitt eget liv. Jag har lärt mig mycket av att observera vilka drag i den ursprungliga designen som fungerade och som inte gjorde det. Bland dessa lärdomar märkte jag att förslaget om att stödja flexibla resursreservationer från enskilda användare ännu inte är användbart, och att beslutet att göra RSVP till en generisk budbärare, som helt enkelt bär "en påse bits" för att passera till routers längs vägen, har visat sig vara rätt, vilket främjade antagandet av RSVP för olika ändamål än QOS stöd. Den ansträngning som startade RSVP design är men det första steget i att utveckla signaleringsprotokoll för t h e I n t e r n e t. Även om debatten om vilka typer av QOS stöd Internet skulle behöva fortsätta, olika signalering behov kräver ett generiskt signaleringsprotokoll. Oberoende av om RSVP skulle vara den varaktiga o n e t o uppfyller denna viktiga roll, tror jag att de grundläggande principer och lärdomar vi har fått från RSVP-utvecklingen kommer att sträcka sig bortom själva protokollet till nya protokolldesigner för det framtida Internet.
Som ett signalprotokoll för nät bandbredd reservation, Resurs ReserVation Protocol (RSVP) är ett populärt exempel REF.
RSVP: a new resource reservation protocol
{'venue': 'IEEE Communications Magazine', 'journal': 'IEEE Communications Magazine', 'mag_field_of_study': ['Computer Science']}