Resursreservationsprotokoll

  RSVP ( Resource Reservation Protocol) är ett transportlagerprotokoll utformat för att reservera resurser över ett nätverk med hjälp av den integrerade tjänstemodellen . RSVP fungerar över en IPv4 eller IPv6 och tillhandahåller mottagarinitierad inställning av resursreservationer för multicast- eller unicast -dataflöden. Det transporterar inte programdata men liknar ett kontrollprotokoll, som Internet Control Message Protocol (ICMP) eller Internet Group Management Protocol (IGMP). OSA beskrivs i RFC 2205 .

RSVP kan användas av värdar och routrar för att begära eller leverera specifika nivåer av tjänstekvalitet ( QoS) för applikationsdataströmmar . OSA definierar hur applikationer gör reservationer och hur de kan avstå från de reserverade resurserna när de inte längre behövs. RSVP-operationer kommer i allmänhet att resultera i att resurser reserveras i varje nod längs en väg. RSVP är inte ett routingprotokoll utan designades för att samverka med nuvarande och framtida routingprotokoll.

RSVP i sig används sällan i telekommunikationsnätverk. 2003 flyttades utvecklingsinsatsen från RSVP teletrafikteknik till RSVP - TE för . Next Steps in Signaling (NSIS) var en föreslagen ersättning för RSVP.

Internetprotokollsvit
Applikationslager
Transportlager
Internetlager
Länklager

Huvudattribut

  1. RSVP begär resurser för simplexflöden : en trafikström i endast en riktning från avsändaren till en eller flera mottagare.
  2. RSVP är inte ett routingprotokoll utan fungerar med nuvarande och framtida routingprotokoll.
  3. RSVP är mottagarorienterad genom att mottagaren av ett dataflöde initierar och upprätthåller resursreservationen för det flödet.
  4. RSVP upprätthåller mjukt tillstånd (reservationen vid varje nod behöver en periodisk uppdatering) av värdens och routrarnas resursreservationer, vilket stöder dynamisk automatisk anpassning till nätverksändringar.
  5. RSVP tillhandahåller flera reservationsstilar (en uppsättning reservationsalternativ) och tillåter framtida stilar att läggas till i protokollrevideringar för att passa olika applikationer.
  6. RSVP transporterar och underhåller trafik- och policykontrollparametrar som är ogenomskinliga för RSVP. [ ytterligare förklaring behövs ]

Historik och relaterade standarder

De grundläggande koncepten för RSVP föreslogs ursprungligen 1993.

OSA beskrivs i en serie RFC-dokument från IETF:

  • RFC 2205 : Funktionsspecifikationen för version 1 beskrevs i RFC 2205 (sept. 1997) av IETF . Version 1 beskriver gränssnittet för tillträdeskontroll (trafik) som är "endast" baserat på resurstillgänglighet. Senare RFC2750 stödet för antagningskontroll.
  • RFC 2210 definierar användningen av RSVP med RFC 2211 med kontrollerad belastning och garanterade RFC 2212 QoS-kontrolltjänster. Mer information i Integrated Services . Definierar också användningen och dataformatet för dataobjekten (som innehåller resursreservationsinformation) som definierats av RSVP i RFC 2205.
  • RFC 2211 specificerar nätverkselementbeteendet som krävs för att leverera Controlled-Load-tjänster.
  • RFC 2212 specificerar nätverkselementets beteende som krävs för att leverera garanterade QoS-tjänster.
  • RFC 2750 beskriver en föreslagen förlängning för att stödja generisk policybaserad tillträdeskontroll i RSVP. Utvidgningen innehöll en specifikation av policyobjekt och en beskrivning av hantering av policyhändelser. (januari 2000).
  • RFC 3209 , "RSVP-TE: Extensions to RSVP for LSP Tunnels" (december 2001).
  • RFC 3473 , "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions" (januari 2003).
  • RFC 3936 , "Procedurer för ändring av R esource Re S er Vation Protocol (RSVP)" (oktober 2004), beskriver nuvarande bästa praxis och specificerar procedurer för att ändra RSVP .
  • RFC 4495 , "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow" (maj 2006), utökar RSVP för att göra det möjligt att minska bandbredden för en befintlig reservation istället för att riva reservationen.
  • RFC 4558 , "Node-ID Based Resource Reservation Protocol (RSVP) Hej: A Clarification Statement" (juni 2006).

Nyckelbegrepp

De två nyckelbegreppen i RSVP-reservationsmodellen är flowspec och filterspec .

Flödesspec

OSA reserverar resurser för ett flöde. Ett flöde identifieras av destinationsadressen, protokollidentifieraren och, valfritt, destinationsporten. I multiprotocol label switching (MPLS) definieras ett flöde som en label switched path (LSP). För varje flöde identifierar RSVP också den särskilda tjänstekvalitet (QoS) som krävs av flödet. Denna QoS-information kallas en flödesspec och RSVP skickar flödesspecifikationen från applikationen till värdarna och routrarna längs vägen. Dessa system analyserar sedan flödesspecifikationen för att acceptera och reservera resurserna. En flödesspecifikation består av:

  1. Serviceklass
  2. Reservationsspecifikation - definierar QoS
  3. Trafikspecifikation - beskriver dataflödet

Filterspec

Filterspecifikationen definierar uppsättningen paket som ska påverkas av en flödesspecifikation (dvs. datapaketen för att ta emot QoS som definieras av flödesspecifikationen) . En filterspec väljer vanligtvis en delmängd av alla paket som behandlas av en nod. Valet kan bero på vilket attribut som helst för ett paket (t.ex. avsändarens IP-adress och port).

De för närvarande definierade RSVP-reservationsstilarna är:

  1. Fast filter - reserverar resurser för ett specifikt flöde.
  2. Delad explicit - reserverar resurser för flera flöden och alla delar på resurserna
  3. Jokerteckenfilter - reserverar resurser för en allmän typ av flöde utan att specificera flödet; alla flöden delar på resurserna

En RSVP reservationsbegäran består av en flödesspec och en filterspec och paret kallas en flödesbeskrivning . Flödesspecifikationen ställer in parametrarna för paketschemaläggaren vid en nod och filterspecifikationen ställer in parametrarna vid paketklassificeraren .

Meddelanden

Det finns två primära typer av meddelanden:

  • Sökvägsmeddelanden ( sökväg )
Sökvägsmeddelandet skickas från avsändarvärden längs datavägen och lagrar sökvägstillståndet i varje nod längs vägen.
Sökvägstillståndet inkluderar IP-adressen för den tidigare noden och några dataobjekt :
  1. avsändarmall för att beskriva formatet för avsändardata i form av en filterspec
  2. avsändarens tspec för att beskriva trafikegenskaperna för dataflödet
  3. adspec som bär reklamdata (se RFC 2210 för mer information).
  • Reservationsmeddelanden ( resv )
Resv - meddelandet skickas från mottagaren till avsändarvärden längs den omvända datavägen. Vid varje nod kommer IP-destinationsadressen för resv -meddelandet att ändras till adressen för nästa nod på den omvända vägen och IP-källadressen till adressen för den föregående nodadressen på den omvända vägen.
Resv - meddelandet inkluderar dataobjektet flowspec som identifierar de resurser som flödet behöver.

Dataobjekten på RSVP-meddelanden kan överföras i valfri ordning. Se RFC 2205 för den fullständiga listan över OSA-meddelanden och dataobjekt.

Drift

En RSVP-värd som behöver skicka ett dataflöde med specifik QoS kommer att sända ett RSVP- sökvägsmeddelande var 30:e sekund som kommer att färdas längs unicast- eller multicast-rutterna som är företablerade av arbetsruttprotokollet. Om sökvägsmeddelandet kommer till en router som inte förstår RSVP, vidarebefordrar den routern meddelandet utan att tolka innehållet i meddelandet och kommer inte att reservera resurser för flödet.

De som vill lyssna på dem skickar ett motsvarande resv (kort för reserv ) meddelande som sedan spårar vägen tillbaka till avsändaren. Resv - meddelandet innehåller en flödesspecifikation . Resv - meddelandet har också ett filterspec- objekt; den definierar paketen som kommer att ta emot den begärda QoS som definieras i flödesspecifikationen. En enkel filterspecifikation kan bara vara avsändarens IP-adress och eventuellt dess UDP- eller TCP-port. När en router tar emot RSVP resv -meddelandet kommer den:

  1. Gör en reservation baserat på förfrågningsparametrarna. Tillträdeskontroll bearbetar förfrågningsparametrarna och kan antingen instruera paketklassificeraren att korrekt hantera den valda delmängden av datapaket eller förhandla med det övre lagret hur pakethanteringen ska utföras. Om det inte kan stödjas skickas ett avvisande meddelande för att meddela lyssnaren.
  2. Vidarebefordra begäran uppströms (i avsändarens riktning). Vid varje nod flödesspecifikationen i resv -meddelandet modifieras av en vidarebefordringsnod (t.ex. i fallet med en multicast-flödesreservation kan reservationsbegäran slås samman).
  3. Routrarna lagrar sedan flödets natur och ställer eventuellt in polisarbete enligt flödesspecifikationen för det.

Om inget hörs under en viss tid kommer bokningen att ta slut och annulleras. Detta löser problemet om antingen avsändaren eller mottagaren kraschar eller stängs av utan att först avbryta reservationen.

Andra funktioner

Integritet
RSVP-meddelanden läggs till med en meddelandesammanfattning skapad genom att kombinera meddelandeinnehållet och en delad nyckel med hjälp av en meddelandesammanfattningsalgoritm (vanligtvis MD5 ). Nyckeln kan distribueras och bekräftas med två meddelandetyper: begäran om integritetsutmaning och svar på integritetsutmaning .
Felrapportering
När en nod upptäcker ett fel genereras ett felmeddelande med en felkod och sprids uppströms på den omvända vägen till avsändaren.
Information om RSVP-flöde
Två typer av diagnostiska meddelanden tillåter en nätoperatör att begära RSVP-statusinformation om ett specifikt flöde.
Diagnostisk facilitet
En tillägg till standarden som tillåter en användare att samla in information om RSVP-tillståndet längs en väg.

RFC:er

  •   John Evans; Clarence Filsfils (2007). Implementera IP och MPLS QoS för multiservicenätverk: teori och praktik . Morgan Kaufmann. ISBN 978-0-12-370549-5 .

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Resource_Reservation_Protocol&oldid=1130480104 "