SE524696C2 - Metod, datorprogramprodukt och arrangemang för att allokera nätresurser inuti ett IP-nät - Google Patents

Description

IO 15 20 25 30 524 695 . « . « ; . . v.

Dessa typer av applikationer kräver en mer tillförlitlig resursallokering än vad best-effort kan erbjuda.

Följaktligen finns det starka kommersiella skäl för nätoperatörer och för de som tillhandahåller mätutrustning att erbjuda tjänstekvalitets (Quality-of-Service (QoSn-differentiering i IP nät. D.v.s. användarna inuti ett nät delas upp i olika grupper beroende på deras prioritet, t.ex. erbjuds högt prioriterade användare fler tillgängliga resurser (t.ex. hastighet, fördröjning, gitter, paketstorlek, token bucket parametrar etc.) än användare med lägre prioriteter. RSVP (Resource Reservation Protocol) är ett signaleringsprotokoll standardiserat för att sätta upp tjänstekvalitet per flöde i routrar som stödjer IntServ (Integrated Services definierat i Braden et Al, Integrated Services in the Internet Architecture: an Overview, IETF, RFCl633) längs banan. I RSVP signalleras all resursbegäran från ändpunkt till ändpunkt vilket resulterar i en stor mängd signallering.

Skalbarhetsproblemen med tjänstekvalitetshantering per flöde i routrar har resulterat i arkitekturen för differentierande tjänster som definierats i Blake et Al, An architecture for Differentiated Services, IETF, RFC2475. Syftet är att tillhandahålla skalbart QOS stöd genom att undvika tillstånd per flöde i routrar.

Den grundläggande idén är att IP pakethuvuden inkluderar ett fält (känt som diffservfältet) som identifierar behandlingen som paketen bör ges av routrarna per hopp. Standardmodellen är emellertid begränsad till att differentiera vidarebefordring i routrar och därför ligger utmaningen i att tillhandahålla förutsägbara tjänster till slutanvändare. Enheten som utför dynamisk tillträdeskontroll kallas här en resurshanterare och är vidare beskriven i Wolf, L.C., Delgrossi, L., Steinmetz, R., Schaller, S., Wittig, H., ”Issues of Reserving Resources in Advance”, IBM European Network Center Heidelberg, TR 439503, 1995. Resurshanteraren håller reda på tillgängliga transmissionsresurser, t.ex. bandbredd, fördröjning, gitterpaketstorlek, token bucket parametrar etc. och utför tillträdeskontroll på inkommande begäran för resurser från klienter.

Resurshanteraren hanterar resurser inuti en domän. Föra att utföra tillträdeskontroll lagrar även resurshanteraren en historik med tidigare tillåtna resursreservationer. Resurshanteraren tar beslut för att tillåta nya 10 15 20 25 30 (fl f J .[":>.

Cï\ xß (fx resursanspråk baserat på den totala mängden tillgängliga resurser, den nuvarande mängden reserverade resurser genom tidigare reservationer och resursmängden som begärts. Resurserna behöver inte vara schemalagda över tiden, men kan vara det. En begäran kan innefatta tillträdeskontroll till multipla resursförråd som kan bestå av olika resurstyper. Den mest vanliga resurstypen som hanteras är bandbredd.

Det finns specifika krav för resurshanteringsmekanismer. För att tillhandahålla en tjänst till slutanvändare måste mekanismerna vara medvetna om nätverksresurser och de kan schemalägga resurserna för den utlovade tjänsten med vilken granularitet som helst (t.ex. portintervall, aggregerad trafik mellan subnätpar etc.).

Mekanismerna bör tillhandahålla korrekt resursstyrning både i lövdomäner och i kärndomäner. I lövdomäner kan det finnas krav på mycket fin granulär resursstyrning (t.ex. per applikationsdataström), speciellt i licensierade band med trådlös access där bandbredden är så styrbar att hög utnyttjandegrad av spektrumet är det totala målet. Prestandan mäste även vara tillräcklig för att hantera mobilitet och frekventa handover. I kärndomäner kan dynamisk aggregerad resurshantering (t.ex. per destinationsdomän, per portintervall för IP telefoni etc.) tillhandahållas för skalbarhetssyften. ISP:er behöver stöd för att förhandla bulkbandbredder med varandra genom att använda reservationer som görs i förväg och tidsberoende kontrakt (t.ex. tidpunkt, veckodag etc.). I företagsnät, finns det ofta välutrustade LAN och hyrda stamledningar för att sammanbinda platser. De behöver stöd för att möjliggöra nya interna tjänster (t.ex. multimediakonferens) som kräver en viss mängd resurser, och dessa tillämpningar måste även styras för att undvika onödig negativ påverkan på annan trafik.

I den internationella patentansökningen PCT/ SEO2 / 00618 inlämnad den 28 mars 2002 visas hur en resurshanterare hanterar en blandning av omedelbara öppna begäran (där sessionens varaktighet är okänd då resursen begärs) och resursbegäran av förallokeringar av resurser. 10 15 20 25 30 (_51 IND -!>- C:'\ \f_\ (j\ För att öka den statistiska vinsten med förallokeringar, kan fler destinationer aggregeras till ett större destínationsprefix och trattkonceptet (funnel concept) som introducerades i Olov Scheléns doktorsavhandling, Quality of Service Agents in the Internet, utgiven av avdelningen för datavetenskap och elektronik, avdelningen för datorkommunikation, Luleå Tekniska Universitet, Luleå 1998, kan användas.

Idén med trattmodellen är att resurshanterare kan efterfråga resurser från andra resurshanterare. Reservationer från olika källor till samma destination aggregeras varvid de slås ihop längs banan så att varje resurshanterare har som mest en reservation per destinationsdomän med dess grannar. En ytterligare förbättring av trattkonceptet beskrivs i den svenska patentansökan 0102929-7 inlämnad den 4 september 2001.

Teknikens ståndpunkt Det finns för närvarande mycket få kända specifikationer och implementatíoner av resurshanterare och till och med färre som hanterar reservationer som innefattar multipla resurshanterare, hänvisade till som interdomänreservationer om de involverade resurshanterarna hanterar resurser som tillhör olika domäner. Trattkonceptet som beskrivits ovan beskriver en metod med överallokering av resurser i varje interdomänhopp men inte en metod för att förallokera resurser baserat på användarstatistik. I P. Pan, E, Hahne och H.

Schulzrinne, ”BGRPz A Tree-Based Aggreation Protocol for Inter-domain Reservations”, Journal of Communications and Networks, Vol. 2, nr. 2, juni 2000, sid 157-167 är ett protokoll som kallas Border Gateway Resoruce Protocol (BGRP) utvecklat för att hantera interdomänskalbarhetsproblem med RSVP som berör tillstånd och signalering. De aggregerar reservationer med samma destination i kantroutern (en router som är placerad nära domänens kant) i källdomänen. För att minska signaleringen föreslår de två utökningar: - Överreservation, Kvantisering och Hysteres 10 15 20 25 30 - Quiet Grafting and CIDR märkning Vid överreservation överallokerar käll-lövdomänen resurser så att den inte behöver sígnalera för varje individuella begäran i domänen. Quiet Grafting betyder att det är en av de mellanliggande routrarna som överallokerar resurser till en ”populär” destination. Problem med dessa utökningar diskuteras nedan.

Arbetsgruppen QBone Signaling workgroup har börjat att specificera ett protokoll för interdomän QOS signalering som kallas SIBBS. Dessa koncept involverar inte förallokering av resurser till destinationer utan tillförlitar sig istället på att signalera varje reservationsbegäran per hopp. I Ibrahim Khalil, Torsten Braun, ”Implementation of a Bandwidth Broker for Dynaniic End-to- End Resource Reservation in Outsourced Virtual Private Networks”, Berns Universitet, Schweiz, diskuteras tillträdeskontroll ändpunkt till ändpunkt men algoritmer för förallokering av resurser till andra domäner presenteras ej. I V.

Sander et al, ”End-to-End Provision of Policy Information for Network QoS”, the University of Chicago, Chicago diskuteras inter-domain reservationer och signalering mellan olika resurshanterare och två modeller för signalering diskuteras primärt. Förallokering av resurser för att reducera signalering är emellertid inte diskuterat.

Den vanligaste typen av förallokering är att manuellt konfigurera en statisk mängd resurser mellan angränsande resurshanterare. Detta är ofta en del av en tjänsteniväöverenskommelse mellan två angränsande resurshanterare. Överallokering och aggregering av många reservationer till en löser prestanda- och skalproblem eftersom tillträdesbeslut lokaliseras. Alternativet som innefattar multipla resurshanterare för varje tíllträdesbeslut, reducerar prestandan, ökar fördröjningen och kan även introducera tillstånd per reservation i alla involverade resurshanterare.

Ett problem med alla metoder som använder överallokering av resurser per hopp är att reservationerna som sträcker sig över många resurshanterarhopp är överallokerade för varje hopp och kommer följaktligen öka överallokeringen för 10 15 20 25 30 (fl PO 4> CN V) (fi. varje hopp. Om t.ex. en överallokeringsalgoritm används som reserverar dubbelt så mycket som önskas kommer den totala reserverade mängden längs banan att öka exponentiellt med antalet hopp d.v.s. redan överallokerade begäran överallokeras igen och igen. Figur 2 illustrerar en första domän 200 som innefattar en klient och andra domän 204 som innefattar en resurshanterare RM4. Klienten begär resurser till den andra domänen 204 via resurshanterare RMl, RM2 och RMS placerade i respektive mellanliggande domäner 201, 202, 203. Figur 2 illustrerar följaktligen att överreservationerna ökar exponentiellt med antalet hopp.

Dessutom kan signalering över många hopp leda till långa svarsfördröjningar för klienten.

Nätanvändning är ofta periodisk under tiden på dagen, veckan och så vidare enligt S. Uhlig, O. Bonaventure, ”IST Project ATRIUM Report 14.2 - Analysis of Interdomain Traffic”, Technical Report 2001, speciellt om klienterna har någon geografisk placering. Den typiska användningen för en tjänst kan t.ex. likna användningen som visas i diagrammet i Figur 3. För att manuellt allokera en statisk mängd resurser för att täcka användningen i Figur 3, måste en nivå som är lika stor som vid användningens topp allokeras. För att i detta fall vara säker på att variationer och tillfälliga toppar i användningen täcks av en statisk nivä måste mer resurser allokeras. Notera att i perioderna med mindre användning (t.ex. under natten i det här exemplet), skulle sådan statisk överallokering leda till en stor mängd outnyttjade resurser, d.v.s. låg utnyttjandegrad.

Ett sätt att öka utnyttjandegraden är att manuellt modifiera den ”statiska” nivån av allokerade resurser varje timme men detta skulle bli mycket tidskrävande. Att modifiera nivån då resurser krävs skulle också kunna göras automatiskt men det är emellertid riskfyllt eftersom det inte finns någon garanti att de behövda resurserna finns tillgängliga. Det skulle följaktligen vara föredraget att kunna förallokera resurser i förväg. I detta exempel skulle företrädesvis hela dagen med olika nivåer för olika timmar förallokeras i förväg baserat på tidigare användarhistorik, om sådan användarhistorik är tillgänglig. 10 15 20 25 30 524 6913 Figur 4 visar ett exempel med användarhistorik för en dag bakåt till vänster och de aktuella reserverade resurserna till höger. I detta exempel finns det en stor mängd kortsiktiga omedelbara reservationer, t.ex. från IP-telefoniapplikationer, och även några reservationer gjorda i förväg, t.ex. för flerpartskonferenser. Anta att de omedelbara reservationerna kan vara ganska korta (omkring minuter) skulle det vara svårt att förutsäga de resurser som krävs i förväg genom att endast titta på de nuvarande reservationerna (till höger i figuren).

Genom att endast titta bakåt i tiden är det möjligt att se hur många resurser som verkligen är reserverade för varje timme. Användarhistorik är följaktligen viktig för att kunna allokera resurser i förväg. Även om det finns en stor mängd reservationer orda i förväg skulle det vara svårt att prediktera de krävda resurserna eftersom klienter tenderar att reservera mer i den nära framtiden än längre bort.

I exemplet i Figur 4 skulle resurserna som krävs för nästa dag kunna förallokeras baserat på användarhistoriken för tidigare dagar såsom visas i Figur 5. Pilarna i Figur 5 indikerar var resursbehov har predikterats baserat på användarhistorik. I det här exemplet har de förallokerade resurserna för varje timme baserats på användarhistorik för motsvarande timmar under tidigare dagar. Denna typ av förallokering som endast är baserad på historik ger bättre utnyttjandegrad än statisk allokering men den kan inte hantera sporadiska toppar och variationer i användarmönstret på ett bra sätt, eftersom användarhistoriken inte kan anpassas till en förändring i användarmönstret.

T.ex. om en klient begär en resursreservering som inte motsvarar den tillgängliga användarhistorikstatistiken, kommer inte begäran att tillåtas och ingen uppdatering av tillgänglig statistik utförs om inte statistiken är baserad på begäran. Ett annat exempel är då det inte finns någon användarhistorikstatistik tillgänglig i början. Följaktligen kommer inga resurser att allokeras baserat på tidigare användarstatistik vilket betyder att endast möjlig tillgänglig användarstatistik baseras på begäran. Användarhistorik som emellertid inte är baserad på verkliga tillåtna och använda resurser utan endast v Q . - | | u f. 10 15 20 25 30 524 6323 8 på begärda resurser är ofta missledande eftersom en klient kan göra många begäran för samma resurs tills den tillåts 'av resurshanteraren.

EP 1035666 A2 visar en apparat för att reservera resurser. Apparaten övervakar en aktiv session och justerar reservationen baserat på predikterade förändringar i en nära framtid. En nackdel med EP 1035666 är att den inte kan reservera resurser i förväg, dvs. för en session har börjat, t ex. en dag i förväg mellan kl. 7-8 på kvällen.

Ett syfte med föreliggande uppfinning är följaktligen att tillhandahålla en resurshanterare och en metod som allokerar nätresurser i förväg som är automatiskt anpassad för varierande användarmönster med minimal signalering och som fortfarande producerar en högre utnyttjandegrad.

SAMMANFATTNING Det ovannämnda syftet uppnås av en resurshanterare, en metod och en dataprogramprodukt som definieras av den kännetecknande delen av de självständiga patentkraven.

Föredragna utföringsformer definieras av de beroende patentkraven.

En fördel med föreliggande uppfinning är att den gör det möjligt att reservera resurser i förväg, då en första resurshanterare allokerar reserverade nätresurser kontrollerade av åtminstone en andra resurshanterare, genom att använda algoritm 1, dvs före en session som den reserverar resurser för, har startat.

Dessutom är det möjligt att reservera resurser avsedda för Sessioner t ex en dag i förväg t. ex. mellan kl. 7-8 på kvällen. Den valda mängden reserverade resurser baseras på användarstatistik för den tidsperioden. Följaktligen kan en större del av alla resursreservationer hanteras på detta sätt. Det finns emellertid situationer då förändringar i nätanvändandet förekommer, t. ex sporadiska toppvärden. Därför har algoritm 2 introducerats som kan hantera sådana förändringar. Algoritmerna 1 och 2 arbetar därför simultant och parallellt, varvid algoritm 1 baseras på 10 15 20 25 30 (_31 I* J -Fë- ('}\ Ö f' J' V) användarhistorik och algoritm 2 på aktuellt resurskrav och på framtida resurskrav.

En annan fördel med föreliggande uppfinning är att de kombinerade algoritmerna 1 och 2 enligt föreliggande uppfinning reducerar signaleringen från ändpunkt till ändpunkt mellan resurshanterare och följaktligen ökar hastigheten för tillträdelsekontroll genom att ta lokala beslut. Detta reducerar även medelfördröjningen frän begäran till svar för klienten. Vid normal drift kan många tusen interdomänreservationsbegäran aggregeras till en enda interdomän för allokerad resurs. Detta kommer även reducera tillstånden som behövs lagras i andra resurshanterare längs banan.

En ytterligare fördel med föreliggande uppfinning är att lösningen även ökar utnyttjandegraden genom att anpassa sig till alla periodiska användarmönster och ökar tillgängligheten av tjänsten genom att förallokera resurser i förväg så att resurser finns tillgängliga då de behövs.

KORT BESKRIVNING AV RITNINGARNA Figur 1 illustrerar ett IP nät schematiskt där föreliggande uppfinning kan implementeras.

Figur 2 illustrerar schematiskt överallokering vid varje hopp i ett nät.

Figur 3 är en graf som visar ett typiskt användarmönster under en dag.

Figur 4 är en graf som visar användarhistorik till vänster och aktuella reserverade resurser till höger.

Figur 5 är en graf som visar förallokering en dag av resurser baserade på tidigare användarhistorik.

Figur 6 är en graf som visar resursmängden som är allokerad av två algoritmer i enlighet med föreliggande uppfinning.

Figur 7 är ett blockdiagram som visar en resurshanterare enligt föreliggande uppfinning.

Figur 8 är ett flödesschema av metoden i enlighet med föreliggande uppfinning. « ø . « . | . n 10 15 20 25 30 . » n c - - . n 10 DETALJERAD BESKRIVNING AV F ÖREDRAGNA UTFÖRINGSFORMER Figur 1 illustrerar ett IP nät 100 där föreliggande uppfinning kan implementeras. Nätet 100 innefattar åtminstone en nätdomän A; B; C åtminstone två resurshanterare a; b; c; d varvid nämnda resurshanterare a; b; c; d är placerade inuti samma nätdomän eller i olika nätdomäner. Varje nätdomän kan innefatta ett flertal routrar, ändpunkter (t.ex. pc, IP telefoner etc.) och servrar anslutna till varandra (ej visad i figur 1).

Varje domän innefattar emellertid åtminstone en resurshanterare a; b; c; d som är implementerad inuti en av ett flertal servrar eller routrar. Resurshanterarna är anordnade att kommunicera 109-114 med varandra.

En lösning till problemet att förallokera resurser som automatiskt anpassas till varierande användarmönster med minimal signalering och som fortfarande producerar en hög utnyttjandegrad är enligt föreliggande uppfinning att kombinera en första algoritm och en andra algoritm som arbetar parallellt.

Algoritmerna används av en första resurshanterare, som mottar en resursreservatíonsbegåran från en klient, eller en andra resurshanterare, och begär resurser vidare från en tredje resurshanterare. Det är även möjligt att den första resurshanteraren kräver de begärda resurserna själv. Den första resurshanteraren allokerar följaktligen resurser till den begärande enheten, d.v.s. till klienten, den andra resurshanteraren eller den första resurshanteraren själv, om de begärda resurserna är godkända.

I korthet så tittar den första algoritmen bakåt i tiden och den andra algoritmen framåt i tiden. D.v.s. den första algoritmen, algoritm 1, använder historikstatistik av resursanvändning. Denna statistik beskriver när och hur många resursbegäran som i verkligheten har blivit godkända och reserverade och vidare predikterar det framtida behovet och förallokerar de predikterade resursbehoven i förväg. Den första algoritmen används för att reservera resurser i förväg före session, som kommer använda nämnda resurser, har startat. 10 15 20 25 30 . - . - - ; o n ll Den andra algoritmen, algoritm 2, allokerar nätresurser individuellt för varje resursreservation där tillgänglig användarhistorikstatistik inte är möjlig att använda och följaktligen inte passar in i de förallokerade resurserna som allokerats av algoritm 1. Dessutom uppdaterar algoritm 2 nämnda användarhistorikstatistik som används i algoritm 1 baserat på de individuella allokerade resurserna. Om det inte finns någon tillgänglig tidigare användarstatistik, antingen p. g.a. en tidigare oanvänd destination som börjar att användas eller om systemet startats utan någon användarhistorik, kommer inte algoritm 1 att förallokera några resurser och algoritm 2 kommer följaktligen att behöva signalera för varje mottagen reservationsbegäran. Resultaten från resursallokeringarna av algoritm 2 samlas emellertid för användarhistorikstatistiken för algoritm 1. Med tiden kommer mängden användarstatistik att ökas så att algoritm 1 kan börja förallokera resurser så att algoritm 1 kan börja förallokera resurser till destinationen som används (en destination är tex. en applikation, en värd, ett nätprefix, ett helt Autonomt System (AS) och kan även bero på nättjänst om flera tjänster stöds). Efter en tid kommer fler och fler resurser att förallokeras av algoritm 1 och färre resurser behöver allokeras av algoritm 2 tills endast ovanliga sporadiska toppar i användning hanteras av algoritm 2.

Grafen i Figur 6 visar hur mer och mer av den totala mängden begärda resurser allokeras av algoritm 1 (kurvan 602) då statistiken byggs upp. Utan algoritm 2 (kurvan 604), skulle algoritm 1 behöva basera sin statistik på begärda resurser och inte tillåtna och använda resurser och detta kan vara missledande eftersom en klient kan försöka och begära samma behövda resurs flera gånger. Det beror på såsom beskrivits ovan att ingen statistik finns tillgänglig vid början och utan algoritm 2 kommer ingen statistik att samlas vilket betyder att begärda resurser skulle vara den enda tillgängliga datan. Resursallokeringsfrekvensen för algoritm 1 ökas 602 p. g.a. att algoritm 2 även använder 604 för att bygga upp användarstatistik som kan användas av algoritmen 1.

Stora förändringar i anvåndarmönster eller som det tidigare exemplet med att starta upp utan statistik alls kan innefatta en stor mängd signalering av 10 15 20 25 30 (Il FO -lä- CSN xí) _ (]\ 12 algoritm 2. I detta fall kan en manuell justering eller initiering av statistik vara önskvärd för att öka anpassningsgraden av algoritm l. Tex. kan algoritm 1 konfigureras med konstruerad statistik och det är då möjligt för algoritm 1 att börja allokera resurser utan att riktig statistik redan har tillhandahällits.

Förallokering av resurser i förväg mellan resurshanterare resulterar i att signalering som innefattar alla resurshanterare inte krävs för varje klientreservation. I t.ex. IP-telefonisystem kan det finnas många tusen begäran till en destination under en timme som kan förallokeras av resurshanteraren för hela timmen i förväg genom att endast använda en begäran. Notera att statistiken företrädesvis är baserad på resursanvändning per destination. Om multipla resurshanterare involveras, måste de mellanliggande resurshanterarna veta trafikens destination för att kunna förallokera resurser till de önskade destinationerna. Det är inte tillräckligt att endast justera tj änsteniväöverenskommelsen mellan två olika resurshanterare för att anpassa de begärda resurserna från klienterna, eftersom signalering skulle ändå behövas till alla involverade resurshanterare för varj e reservation som ska sättas upp. Genom att ha förallokerade resurser lokalt i en specifik resurshanterare, kan resurshanteraren i enlighet med föreliggande uppfinning fatta ett lokalt beslut för att acceptera eller förneka en ny reservationsbegäran utan signalering till alla involverade resurshanterare. Detta kommer öka tillträdesstyrningshastigheten och reducera fördröjningen för klientbegäran.

Algoritm l kan förallokera en timme, en dag, en hel vecka etc. i förväg beroende pä t.ex. användarhistorikstatistikens periodicítet. I det tidigare exemplet; skulle algoritm l företrädesvis kunna allokera en dag i förväg och allokera i block av en timme för varje signalering mellan resurshanterare. I en annan utföringsform, signalerar resurshanteraren en gång per timme eller i en ytterligare utföringsform allokerar resurshanteraren alla resurser pä en gång.

Eftersom algoritm 2 allokerar resurser per resursreservationstillfälle, kan åtskilliga (tusentals) signaler förekomma för varje destination per timme beroende på applikationer och användarmönster, det är därför önskvärt att algoritm 1 täcker så mycket av resurserna som möjligt.

IO 15 20 25 30 696 . » » o q | ø u 13 Eftersom algoritm 2 reserverar resurser per reservationstillfälle och inte överallokerar resurser undviks problemet med överallokering per hopp som diskuterats tidigare och visats i Figur 2.

Algoritm 1 förallokerar resurser per destination. Tidsintervallet mellan varje allokeringstillfälle kan antingen vara lika för alla destinationer eller skilja mellan destinationerna. Om det finns flera tjänster eller trafikkrav för en destination, kan statistik för individuella tjänster användas för att förallokera resurser som även beror på den begärda tjänsten.

Statistiken som lagras från tidigare användning kan innefatta toppvärde, medelvärde, varians etc. och det bör vara möjligt att konfigurera algoritrnen för att förallokera resurser baserat på dessa parametrar (t.ex. medel + 2*sqrt (varians)). Mängden av förallokera är en avvägning mellan överallokering och mängden signalering som måste utföras av algoritm 2. Det är även önskvärt att kunna konfigurera tiden i förväg, som resurserna bör allokeras och granulariteten av förallokeringen och statistiken, t.ex. ett värde per parameter för varje timme i exemplet. För att reducera statistikhistorikdatan som lagras för varje destination kan tidigare värden viktas till nya värden. Ett exempel är att använda O,5*tidigare värde + O,5*det nya värdet för varje ny dag och timme. På det här sättet kommer algoritmen att anpassas långsammare till tillfälliga ändringar i användning än om endast en dag tittas tillbaka på. En annat exempel är att använda 0,9*tidigare värde + O, l*det nya värdet som kommer att anpassas mycket långsamt.

Metoden för allokering i ett IP nät i enlighet med föreliggande uppfinning beskrivs nedan och i en generell mod och illustreras i flödesschemat i Figur 8.

Metoden innefattar stegen: 801. Allokera reserverade resurser baserat på användarhistorikstatistik då tillgänglig användarhistorikstatistik är tillämpbar på nämnda resursreservatíonsbegäran. 801. Allokera resurser individuellt för nämnda begärda resursreservation då tillämpbar användarhistorikstatistik inte finns tillgänglig. 10 15 20 25 G1 TO -Iš- O\ xD (_) \ 14 803. Uppdatera nämnda historikstatístik baserat på ett resultat av nämnda individuellt allokerade resurser.

Metoden är i enlighet med en utföringsform av föreliggande uppfinning utförd av en resurshanterare varvid resurshanteraren är placerad inuti en router eller en server inuti i ett IP nät. Resurshanteraren innefattar medel 702 för att allokera reserverade nätresurser i förväg baserat på användarhistorikstatistik 708 då tillgänglig användarhistorikstatistik 708 är tillämpbar till nämnda nätresursreservationbegäran, medel 704 för att allokera nätresurser individuellt för nämnda begärda nätresursreservation då tillämpbar användarhistorikstatistik 108 inte är tillgänglig, och medel 706 för att uppdatera nämnda användarhistorikstatistik 708 baserat på. nämnda individuella allokerade nätresurser.

Metoden kan implementeras med hjälp av en datorprogramprodukt innefattande mjukvarukodmedel för att utföra metodens steg.

Datorprogramprodukten körs på processmedel inuti en router och/ eller en server. Datorprogramprodukten är nedladdad direkt eller från ett datoranvändbart medium.

Föreliggande uppfinning är inte begränsad till de ovan beskrivna föredragna utföringsformerna. Olika alternativ, modifikationer och ekvivalenter kan användas. Därför bör inte de ovan beskrivna utföringsformerna ses som att begränsa föreliggande uppfinning vilken är definierad av de bifogade patentkraven.

Claims (18)

Patentkrav

1. l. Metod för att allokera nätresurser inuti ett IP nät, metoden är kännetecknad av att den innefattar stegen: - i förväg vid en första resurshanterare allokera (801) reserverade nätresurser kontrollerade av åtminstone en andra resurshanterare före en session, som kommer använda nämnda resurser, har startat baserat på användarhistorikstatistik om tillgänglig användarhistorikstatistik är tillåmpbar på nämnda nätresursreservationbegäran, - allokera (802) nätresurser individuellt för nämnda begärda nätresursreservation om tillgänglig användarhistorikstatistik inte år tillgänglig, och - uppdatera (803) nämnda användarhistorikstatistik baserat på nämnda individuellt allokerade nätresurser.

2. Metod enligt patentkrav 1, varvid metoden innefattar det ytterligare steget: - manuellt justera användarhistorikstatistik.

3. Metod enligt något av patentkrav 1-2, varvid nämnda individuellt allokerade nätresurser allokeras per reservationstillfälle.

4. Metod enligt något av patentkrav 1-3, varvid nämnda allokerade reserverade nätresurser allokeras baserat på användarhistorikstatistik per destination.

5. Metod enligt patentkrav 4, varvid tidsintervallet mellan varje tillfälle, som nätresurser allokeras baserat på användarhistorikstatistik, antingen kan vara lika för alla destinationer eller skilja sig mellan destinationerna.

6. Metod enligt patentkrav 4, varvid nämnda allokering av reserverade nätresurser vidare baseras på statistik för individuella tjänster. /6

7. Metod enligt något av patentkrav l-6, varvid användarhistorikstatistiken innefattar någon av parametrarna ett toppvärde, ett medelvärde eller en varians.

8. Metod enligt något av patentkrav l-7, varvid nämnda resurshanterare är implementerad inuti en server eller en router i nämnda IP nät.

9. En datorprogramprodukt direkt nedladdningsbar i en server och / eller router inuti i ett IP nät innefattande mjukvarukoddelar för att utföra stegen enligt något av patentkrav 1-8.

10. En datorprogramprodukt lagrad på ett datoranvändbart medium, innefattande läsbart program för att förorsaka ett processormedel inuti en server och /eller router inuti ett IP nät att styra exekveringen för stegen enligt något av patentkrav 1-8.

11. l 1. En första resurshanterare i ett IP nät kännetecknar! av att den innefattar medel för att allokera nätresurser kontrollerade av åtminstone en andra resurshanterare inuti IP nätet, nämnda första resurshanterare innefattar: - medel (702) för att i förväg allokera reserverade nåtresurser före en session, som kommer använda nämnda resurser, har startat baserat på användarhistorikstatistik (708) då tillgänglig användarhistorikstatistik är tillämpbar på nämnda nätresursreservationsbegäran, resurshanteraren innefattar: - medel (704) för att allokera nätresurser individuellt för nämnda begärda nätresursreservation då tillämpbar användarhistorikstatistik (708) inte är tillgänglig, och - medel (706) för att uppdatera nämnda användarhistorikstatistik (708) baserat på nämnda individuellt allokerade nätresurser. f var 0 ::::: :.::. :: s /7

12. Första resurshanterare enligt patentkrav 1 1, varvid nämnda första resurshanterare innefattar medel för att manuellt justera användarhistorikstatistik.

13. Första resurshanterare enligt patentkrav 1 l- 12, varvid första resurshanteraren innefattar medel för att allokera nämnda individuellt allokerade nätresurser per reservationstillfälle.

14. Första resurshanterare enligt patentkrav 11-13, varvid första resurshanteraren innefattar medel för att allokera nämnda allokerade reserverade nätresurser baserat på användarhistorikstatistik per destination.

15. Första resurshanterare enligt patentkrav 14, varvid tidsintervallet mellan varje tillfälle, som nätresurser är allokerade baserat på användarhistorikstatistik antingen kan vara lika för alla destinationer eller skilja sig mellan destinationerna.

16. Första resurshanterare enligt patentkrav 14, varvid nämnda medel för att allokera nätresurser ytterligare innefattar medel för att använda statistik för individuella tjänster för nämnda allokering av nätresursreservationer.

17. Första resurshanterare enligt patentkrav 11-16, varvid användarhistorikstatistiken innefattar någon av parametrarna ett toppvärde, ett medelvärde eller en varians.

18. Första resurshanterare enligt patentkrav 1 1-17, varvid nämnda första resurshanterare är implementerad inuti en server eller en router i nämnda IP nät.