SE521463C2 - Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte - Google Patents

Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte

Info

Publication number
SE521463C2
SE521463C2 SE9903390A SE9903390A SE521463C2 SE 521463 C2 SE521463 C2 SE 521463C2 SE 9903390 A SE9903390 A SE 9903390A SE 9903390 A SE9903390 A SE 9903390A SE 521463 C2 SE521463 C2 SE 521463C2
Authority
SE
Sweden
Prior art keywords
flow
real
time
node
classifier
Prior art date
Application number
SE9903390A
Other languages
English (en)
Other versions
SE9903390L (sv
SE9903390D0 (sv
Inventor
Harald Brandt
Zsolt Haraszti
Rui Castro
Original Assignee
Ericsson Telefon Ab L M
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ericsson Telefon Ab L M filed Critical Ericsson Telefon Ab L M
Priority to SE9903390A priority Critical patent/SE521463C2/sv
Publication of SE9903390D0 publication Critical patent/SE9903390D0/sv
Priority to PCT/SE2000/001712 priority patent/WO2001022666A1/en
Priority to AU75657/00A priority patent/AU7565700A/en
Priority to US09/664,915 priority patent/US6801530B1/en
Publication of SE9903390L publication Critical patent/SE9903390L/sv
Publication of SE521463C2 publication Critical patent/SE521463C2/sv

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/087—Jitter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/43—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR]
    • H04L47/431—Assembling or disassembling of packets, e.g. segmentation and reassembly [SAR] using padding or de-padding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

521 lš-afšfš rf-w.. -..~ .n tiden då datapaketen kommer fram, såsom ljud och video. RTP används vanligtvis över UDP. När realtidsdata överförs över ett IP-nätverk och RTP- och UDP-protokoll används, är realtidsdatan uppbruten i ramar. För att hålla ordning på detaljerna, såsom ramsekvens och timing, sätter RTP en s.k. header på varje ram och lämnar över den resulterande RTP-ramen (RTP header + ram) till UDP. UDP lägger sedan till sin egen header till RTP-ramen = UDP-datagram och lämnar över den till IP. IP lägger sedan till sin egen header till UDP-datagrammet = IP-datagram. Det resulterande paketet av data blir då realtidsdata + RTP-header + UDP-header + IP-header.
Specifikationsdokumenteti Internet protokoll-serien, såsom definierats av IETF (Internet Engineering Task Force) och dess styrgrupp (IESG), är publicerat som RFCar (Requests for Comments).
I konventionella IP-nätverk opererar protokollskikt på ett ganska isolerat sätt. Tex. transportskiktet ger samma service till alla tillämpningar. Vice versa opererar tillämpningarna oberoende av karaktären i det underliggande transportnätverket såsom t.ex. bandvidd och pakettappníngshastighet.
Ett problem är att alltför lång tidsfördröjning i situationer av tillfällig överbelastning i en nod gör realtidsdata, såsom ljud eller video, oanvändbara men orsakar inte samma skadegörelse på andra typer av data. Detta problem skulle mildas om realtidsdata prioriterades över icke-realtidsdata. I detta fall och andra fall där skillnaden på service är kritisk, finns ett behov av att server-enheten kan skilja mellan paket med olika typer av servicebehov. En typ av differentiering som flödet anvander är tillämpnings- (applikations) kategori och/ eller olika protokollformat som används. Detta förutsätter att noden för att kunna skilja mellan paket med olika servicebehov måste veta typen av tillämpning och/eller protokoll. T.ex. användningen av RTP-protokoll talar om att flödet är ett realtídsflöde och skall vid tillfällig överbelastning prioriteras över icke-realtídsflöde.
Andra exempel där servicedifferentiering behöxfs baserat på huruvida realtidsdata eller andra typer av data skickas är: - När en utgående länk från en nod är en radiolänk där allokeringen av radioresurser beror på om Överförd data är rcaltidsdata eller icke-realtidsdata, 521 4623 - Beordra länkskiktet om fel korrigering, vilket inte behövs för realtidsdata men för andra typer av data, och - Access till en server eller till ett nätverk.
När protokollenheter är inkapslade i andra lägreskiktprotokollenheter, är ett enkelt sätt att identifiera typen av det inkapslade protokollet att använda ett explicit fält i headern hos det inkapslade lägreskikt (tex. IP)-prokollet. Detta är implementerat i IP-version 4 och IP-version 6. Detta explicita fält är ett s.k. TOS (Type Of Service)-falt och nätverksnoderna som implementerat de differentierade serviceförbättringarna till IP använder en kodpunkt i IP-headern för att välja ett PHB (Per-Hop Behaviour) som den specifika vídareskickningsbehandlingen för detta paket. Detta är beskrivet i RFC 2598.
Således, genom att läsa detta fält kan vilken enhet som helst som processar paketflödet lätt läsa ut typen av det inkapslade protokollet. Twärr är inte denna explicíta information vanlig.
UDP-headern och TCP-headern bär inte någon explicit information som kan tala om för en mottagande nod att dess nyttodata innehåller realtidsdata.
Amerikanska patentet nr. 5 903 735 beskriver en metod och en apparat för att överföra tidskrítiska meddelanden över en nätverksväg som har ett flertal noder. Datan är klassificerad som minimal bandbreddsdata i den första noden och prioriteras över annan data utan minimalt bandbreddsbehov när den skickas. Den högre prioriteten underhålls av noderna längs vägen.
Problemet löses med bandbreddsreservation längs vägen. Detta är förstås ett slöseri med bandbredd under de perioder när mindre än full bandbredd utnyttjas.
Därför, vad som ytterligare behövs är en mekanism för klassificering av ett flöde såsom varande realtidsflöde eller inte utan explicit protokollformatidentifierare, utan explicit flödesbeskrivningsmeddelanden och utan onödigt slöseri med bandbredd.
SAMMANFATTNING AV UPPFINNINGEN Föreliggande iippfinning rör behoxfet av differentierad serifice till realtidspaket och andra typer av paket i ett IP-nätverk. Mer speciellt rör det problemet med Oacceptabel försening i nätverket vilket resulterar i att realtidspaket blir oanvändbara för mottagaren.
Ett problem för en nod ar att veta huruvida ett mottaget datagram innehåller realtidsdata eller inte.
Därför är syftet med uppfinningen att undanröja ovanstående problem.
De ovan nämnda problemen löses genom ett IP-natverk i vilket en serie undersökningar av headrarna hos ett flöde klassificerar flödet såsom varande realtidsflöde eller icke- realtidsflöde.
Följande scenario av klassificering av ett flöde beskriver uppfinningskonceptet hos föreliggande uppfinning.
Ett aggregerat flöde i ett lP-natverk passerar genom en flödesklassificerare innan flödet kommer fram till noden. Flödesklassificeraren delar upp det aggregerade flödet i olika set av flöden, där varje set motsvarar en enkelriktad paketström från en enda session.
Flödesklassificeraren genomför åtminstone en av följande undersökningar av varje flöde: - Undersökning av nyttolaststorleken, - undersökning av statiskt uppförande i headerfalt som ar förutsägbart konstanta om flödet är ett realtidsflöde eller - undersökning av vissa lieaderfalt om de uppför sig inkrementellt, dessa ökar förutsägbart om flödet är ett realtidsflöde.
Baserat på dessa undersökningar beslutar flödesklassificeraren om flödet är ett realtidsflöde eller icke-realtidsflöde.
En fördel med föreliggande uppfinning är att realtidsflödet kan överföras snabbare över nätverket.
En annan fördel med föreliggande uppfinning ar att natverksresurserna kommer att användas mer effektivt. 521 ll-ifiš Ytterligare en fördel med föreliggande uppfinning är att realtidsdata kan identifieras oberoende av om explicit beskrivning (tex. genom sígnalering) av realtidsdataflöde är tillgänglig eller inte.
Ytterligare en fördel med föreliggande uppfinning år att när den används i radioaccess- nätverk för att upptäcka lP-paketflöden med realtidsbehov, kan resursallokeringen optimeras. Detta förbättrar nätverksanvändningen och servicekvaliteten som användaren kommer att märka.
Ytterligare användningsområden för föreliggande uppfinning är uppenbara genom den detaljerade beskrivningen nedan. Det skall dock förstås att specifika exempel i samband med den detaljerade beskrivningen av föredragna utföringsformer är rent illustrativa, eftersom en mängd förändringar och anpassningar faller inom uppfinningens omfång och andemening, vilket är uppenbart för en fackman på området.
KORT RITNINGSBESKRIVNING Figur 1 visar en RTP-header.
Figur 2 visar en översikt över ett lP-nätverk enligt uppfinningen.
Figur 3 visar ett flödesschema av den generella metoden enligt uppfinningen.
BESKRIVNING AV FÖREDRAGNA UTFÖRINGSFORMER En RTP-header kommer nu att beskrivas enligt RFC 1889 sektion 5, för att underlätta förståelsen av föredragna utföringsformer. RTP-enhetheadern har några förutsägbara egenskaper som gör det möjligt att testa ett UDP-flöde och tala om det innehåller RTP- ramar eller inte. Uppfinningen är dock inte enbart applicerbar på RTP-flöden, den är applicerbar på andra protokollformat som har liknande förutsägbara headeruppföranden.
Formatet av RTP-headern visas i figur 1. Fälten har följande betydelse: 10 20 Version V: 2 bitar Detta falt identifierar versionen av RTP Versionen definierad av denna specifikation är två (2).
Utfyllnad (Padding) P: 1 bit Om utfyllnadsbiten är inställd innehåller paketet en eller flera ytterligare utfyllnadsoktetter och vid slutet, vilket inte är en del av nyttolasten. Den sista oktetten av utfyllnad innehåller en beräkning av hur många utfyllnadsoktetter som skall ignoreras. Utfyllnad kan behövas av några krypteringsalgoritrner med fixerade blockstorlekar eller för att bara ett antal RTP-paket i en lägre-skikts-protokolldataenhet Utbyggnad (Extension) X: 1 bit Om utbyggnadsbiten är inställd följs den fasta headern av exakt en header-utökning med ett format definierat i sektion 5.3.1 i den RFC som nämnts ovan.
CSRC räknare CC: 4 bitar CSRC (synchronisation source)-räknaren innehåller antalet CSRC-identifierare som följer den fasta headern.
Markerare (Marker) M: 1 bit Tolkningen av markeraren ar definierad av en profil. Det är avsett att tillåta signifikanta händelser såsom ramgränsytor att markeras i paketströmmen. En profil kan definiera ytterligare markeringsbitar eller specificera att det inte finns någon markerarbit genom att andra antalet bitar i nyttolastens typfalt. Detta beskrivs ytterligare i sektion 5.3 i den ovan nämnda RFCn.
Typ av nyttolast (Payload type) PT: 7 bitar Detta falt identifierar formatet av RTP-nyfttolasten och bestämmer dess tolkning av tillämpningen. En profil specificerar normal statisk mappning av nyttolasttypkoder för nyttolastformat. Ytterligare nyttolasttypkoder kan definieras dynamiskt genom icke-Rif- medel, vilket är 'ytterligare beskrivet i sektion 3 i RFCzn nämnd ovan. En inledande inställning av standardtnappningar för ljud och video är specificerad i profilen Internet- Draft draft-ietf-avt-profile, och kan utökas i framtida utgivningar av Assigned Numbers 10 l5 20 25 521 41-633 RFC. En RTP-sändare sänder ut en RTP-nyttolasttyp vid vilken som helst tidpunkt. Detta fält är inte avsett för multiplexing av separata mediaströmmar.
Sekvensnummer (Sequence number) SN: 16 bitar Sekvensnumret ökar med ett för varje datapaket som skickas, och kan användas av mottagaren för att upptäcka paket som har försvunnit och för att återspara paketselwenser. Det första värdet av sekvensnumret är slumpmässigt (oförutsägbart) för att göra attacker på kryptering svårare, även om källan i sig själv inte är krypterad eftersom paketen kan flöda genom en översättare som gör det.
Tidstämpel (Timestamp) TS: 32 bitar Tidstämpeln reflekterar samplingstidpunkten i den första oktetten i ett RTP-datapaket.
Samplingstidpunkten måste härledas från en klocka som ökar monotont och linjärt i tiden för att tillåta synkronisering och jitterkalkyleringar (se ytterligare i sektion 6.3.1 i RFCzn som nämnts ovan). Klockans noggrannhet mäste vara tillräcklig för den önskade synkroniseringsexaktheten och för mätning av paketankomstjitter (ett tick per video är vanligen inte tillräckligt). Klockfrekvensen beror pa formatet hos den data som bärs som nyttolast och är statiskt specificerad i profilen eller nyttolastformatspecifikationen som definierar formatet eller kan specificeras dynamiskt för nyttolastformat definierade genom icke-RTP-medel. Om RTP-paket samplingstidspunkten som bestäms frän samplingsklockan användas, inte en läsning av genereras periodiskt mäste den nominella systemklockan. Som ett exempel för konstant-hastighets-ljud ökar tidstämpelklockan med ett för varje samplingsperiod. Om en ljudapplikation läser block täckande 160 samplingsperioder från inmatningsanordningen ökar tidstämpelklockan med 160 för varje sådant block oavsett om blocket sänds i ett paket eller droppas som tyst.
Synkroniseringskälla (Synchronisation source) SSRC: 32 bitar SSRC-fälet identifierar synkroniseringskällan. Denna identifierare är vald slumpvist med syftet att ingen tväsynkronisationskällzi inom samma RTP-session kommer att ha samma SSRC-identifierare. Ett algoritm-exempel för att generera en slumpvis identifierare är _ . 1: \_ _, \ /t -~ 1, nrnf* '_\' Y_ 'fiimi- 1 x I v n i |_--n PICSCIIÜIIdU 1 [XPPCII L\ [LU 1 UVålflfldnlnLld RTL.. iX\ CH Ofn pdlllllgnfiffin ZIY CÉÉ flertal hflUOf väljande samma identifierare är låg måste alla RTP-implcmentationer prepareras för att 20 25 30 521 11-623 upptäcka och upplösa kollisioner. Om en källa ändrar dess källtransportadress måste också en ny SSRC-identifierare väljas för att undvika att bli tolkad som en loopad källa.
Bidragande källa (Contributing source) CSRC-lista: 0-15 stycken, 32 bitar i varje CSRC-listan idenfierar de bidragande källorna för nyttolasten som ingår i detta paket.
Antalet identifierare ges av CC-fältet. Om det är mer än 15 bidragande källor kan endast 15 identifieras. CSRC-identifieraren insätts av mixare med användning av SSRC- identifierare från bidragande källor. Tex. för ljudpaket är SSRC-identifierarna från alla källor mixade tillsammans för att bilda en paketarea som listas, vilket tillåter korrekt talarindikation vid mottagaren.
I figur 2 visas den föredragna utföringsformen av ett lP-nätverk 200, i vilket olika service är differentierad baserat pä om det överförda flödet 201, 202, 203 är realtidsflöde eller inte. IP-nätverket 200 innefattar sammankopplade noder 204 representerande t.ex. växlare, routrar och värdar. Ett aggregerat flöde är definierat som en mix av alla olika flöden som sänds över en punkt i IP-nätverket 200, varje flöde motsvarar en enkelriktad paketström av lP-datagram från en enda session. Aggregerade flöden sänds i lP-nätverket 200 mellan noderna 204. lP-nätverket 200 innefattar också en flödesklassificerare 205 genom vilka ett aggregerat flöde 201, 202 passerar innan de kommer in i noden 204. En flödesklassificerare kan också vara samlokaliserad i en nod 204.
Flödesklassificeraren 205 har medel 206 för att dela upp de inkommande aggregerade flödet 201 i olika set av flöden, varje flöde korresponderande till en enkelriktad paketström av lP-datagram frän en enda session. Denna uppdelning gör det möjligt för flödesklassificeraren 205 att titta på ett flöde från en enda session i taget.
Flödesklassificeraren 205 har också medel 207 för att undersöka nyttolaststorleken hos transportskiktdatagrammet av ett paket i ett flöde tillhörande en specifik session och också medel 213 för att undersöka om nyttolaststorleken av transportskiktdatagrammet är större än det minsta möli a data ram av en s ecifik session innehållande realtidsdata. Om l g g P Cl. det är sa kan det vara ett realtidsflöde men om det inte är så är et inte ett realtidsnöde.
T.ex. undersöka om UDP-nyttolasten är större än minsta möjligt RTP-ram. 15 20 521 4-65 9 Flödesklassificeraren 205 har också medel 208 för att titta på ett antal konsekutiva datapaket i flödet hos den specifika sessionen och undersöka genom att kolla det statiska uppförandet i headerfalten, vilka är förutsägbart konstanta om flödet hos den specifika sessionen är ett realtidsflöde. T.ex. undersök om headerfälten, som är menade att vara konstanta i konsekutiva RTP-ramar i en session är konstanta i det undersökta flödet.
Exempel på konstanta RTP-headerfält är version V-faltet och nyttolast PT-fältet.
Nyttolasttyp PT-faltet talar om vad som är inuti RTP, såsom om det är GSM-codec, om det är tal eller någonting annat. Dessa är konstanta under sessionen om det är ett realtidsflöde. Om dessa headerfälti det undersökta flödet inte är konstanta är det ett icke- realtidsflöde.
Flödesklassificeraren 205 har ocksa medel 209 för att titta pa ett antal konsekutiva datapaket i flödet hos en specifik session och undersöka inkrementellt (öknings) uppförande i headerfälten, vilket fält förutsägbart ökar om flödet av den specifika sessionen är ett realtidsflöde. T.ex. undersöka i den möjliga RTP-headern (man vill fastställa om det verkligen är en RTP header eftersom att då vet man att det är ett realtidsflöde) om fälten som förväntas öka, enligt ovan nämnda RFC 1889, ökar. Exempel på ökande RTP-headerfält är sekvensnummer SN-fzíltet och tidstämpel TS-faltet. Om dessa headerfält som förväntas öka i det undersökta flödet inte ökar är det ett icke- realtidsflöde.
Flödesklassificeraren 205 har ytterligare medel 212 för att undersöka om värdet av headerfälten i ett tillämpningsdatagram uppfyller begränsningsrestriktioner av headern i ett tillämpningsdatagram innefattande realtidsclata, t.ex. en RTP-ram. Om begränsningsrestriktionerna inte är uppfyllda i det undersökta flödet, är det inte ett realtidsflöde.
Flödesklassificeraren 205 har ytterligare medel 210 för att besluta om flödet är ett realtidsflöde eller inte, baserat pä föregående undersökningar. När man tittar pä ett antal konsekutiva datapaket i ett flöde måste man ta hänsyn till att något eller nägra paket kan saknas.
Flödesklassificeraren 205 har medel 211 för att rapportera beslutet om huruvida flödet är ett realtidsflöde eller inte till noden 204. 10 20 25 30 10 Vid en utföringsform av föreliggande uppfinning utgör en utgående länk 203 från noden 204 en radiolank och noden 204 har medel 214 för att allokera radioresurser grundat på om flödet är ett realtidsflöde eller inte.
Vid en annan utföringsform har noden 204 medel 215 för att göra en förfrågan till länkskiktet för att felskydda om flödet är ett icke-realtidsflöde eller inte felskydda om flödet är ett realtidsflöde. Det finns inget behov av att felkorrigera när realtidsdata sänds.
Vid tterli are en utförín sform ut ör noden 204 en växel. Växeln har medel 216 för att Y g g g prioritera ett realtidsflöde över ett icke-realtidsflöde vid växling, t.ex. i situationer av tillfällig överbelastning.
Vid ytterligare en utföringsform utgörs noden 204 av en router. Routern har medel 216 för att prioritera realtidsflöde över icke-realtidsflöde vid routning, t.ex. i situationer av tillfallig överbelastning.
Figur 3 visar ett flödesschema av ett möjligt scenario för att särskilja realtidsflöde från andra typer av flöden i en ström av IP-datapaket i ett lP-natverk 200.
IP-nätverket 200 innefattar sammankopplade noder 204. Aggregerade flöden skickas i IP- nätverket 200 mellan noderna 204. Nöden 204 har ett inkommande aggregerat flöde av IP-datagram. Det inkommande aggregerade flödet delas upp 300 i olika set av flöden, där vart och ett av flödena motsvarar en enkelriktad paketström från en enda session. Detta ör det möli tatt titta å ett flöde från en enda session åt ån en. g J g P g g Metoden innefattar åtminstone en av följande undersökningar: - Undersökning av nyttolaststorleken 301 av transportskiktdatagrarnmet hos ett paket i ett flöde tillhörande en specifik session. Vid en utföringsform är det också möjligt att undersöka om nyttolaststorlekfen hos nansportsliktcatagrammet ar större än det rninsta möjliga datagrammet hos en specifik session innehållande realtidsdata, t.ex. undersökande 10 15 20 25 11 om UDP-nyttolaststorleken är större än den minsta möjliga RTP-ramen. Om det är så är det inte ett realtidsflöde.
- Undersökning av headerfälten hos ett applikationsdatagram, om värdet av fälten uppfyller begränsningsrestriktioner 302 i heaclern hos ett applikationsdatagram innefattande realtidsdata, tex. en RTP-ram. Om begränsningsrestriktionerna inte är uppfyllda i det undersökta flödet är det icke ett realtidsflöde.
- Ett antal konsekutiva datapaketi flödet hos en specifik session tittas pä, där det statiska uppförandet 303 i headerfältet undersöks, vilka fält är förutsägbart konstanta om flödet hos den specifika sessionen är ett realtidsflöde. T.ex. undersöks om headerfälten, som förväntas vara konstanta i konsekutiva RTP-ramar i en specifik session, är konstanta i det undresökta flödet. Exempel pä konstant RTP-headerfält är version V-fält och nyttolast PT-fält. Nyttolasttyp PT-fält talar om vad som är inuti RTP ssä att om det är frän en GSM-kodare, om det är röst eller någonting annat. Dessa är konstanta under sessionen om det är realtid. Om dessa headerfält i det undersökta flödet inte är konstanta är det inte ett realtidsflöde.
- Ett antal konsekutiva datapaket i flödet av en specifik session tittas på, där det inkrementella uppförandet 304 av headerfalt undersöks, detta är förutsägbart ökande i ett flöde hos en specifik session är ett realtidsflöde. T.ex. undersökning av den möjligt RTP- headern, om fälten som är förväntade att vara ökande, enligt ovannämnda RFC 1889, ökar. Exempel pä ökande RTP-headerfält är sekvensnummer SN-fält och tidstämpel TS- fält. Om dessa headerfält som förväntas öka i det undersökta flödet inte ökar är det inte ett realtidsflöde.
Metoden innefattar ytterligare steget av att besluta 305 huruvida flödet är ett realtidsflöde eller inte, baserat pä ovan nämnda undersökningar.
De utförda undersökningarna är var och en resulterande i antingen icke-realtidsflöde eller möjligt realtiegflöde. Om någon av undersökningsstcgen owe-an 'visar att det är icke- realtidsdata, behöver inga fler undersökningar göras. Ett exempel pä hur dessa undersökningar kan ga till kommer nu att beskrivas: 10 20 25 521 lï-tf-š 12 Först undersöks om nyttolaststorleken hos UDP-nyfttolasten är större än den rninsta möjliga RTP-ramen. Om det inte är så klassificeras flödet såsom icke-realtidsflöde. Om det är så kan det vara ett realtidsflöde och ytterligare undersökningar måste göras.
Om ytterligare undersökningar måste göras följer en undersökning av värdet hos headerfalten i ett tillämpningsdatagram uppfyller begränsningsrestriktionerna 302 i en RTP-header. Om begränsningsrestriktionerna inte är uppfyllda i det undersökta flödet klassificeras flödet som icke-realtidsflöde. Om de är uppfyllda kan det vara ett realtidsflöde och ytterligare undersökningar är nödvändiga. I detta exempel är nästa steg att undersöka om headerfalten, som är förväntade vara konstanta i konsekutiva RTP- ramar i en session, är konstanta i det undersökta flödet. Om de inte är konstanta, klassificeras flödet som ett icke-realtidsflöde. Om de är konstanta är det ett möjligt realtidsflöde och ytterligare undersökningar behövs.
I så fall undersöks den möjliga RTP-headern om fälten, som är förväntade att öka i konsekutiva RTP-ramar enligt ovannämnda RFC 1889, ökar. (Dvs. inkrementellt uppförande.) Om dessa headerfalt är icke-ökande är flödet klassat som ett icke- realtidsflöde. Å andra sidan, om dessa headerfalt ökar klassas flödet som ett realtidsflöde.
När man tittar på ett antal konsekutiva datapaket i ett flöde och undersöker uppförandet i ökningen måste hänsyn tas till att något eller några paket kan saknas.
Vid en utföringsform innefattar metoden ett steg som rapporterar beslutet huruvida flödet är ett realtidsflöde eller inte, till noden 204.

Claims (23)

10 15 20 25 521 462; /3 PATENT KRAV
1. IP-nätverk (200) innefattande servicedifferentiering baserad på huruvida ett flöde (201, 202, 203) som överförs är ett realtidsflöde eller inte, lP-nätverket (200) innefattar en nod (204) som tar emot ett inkommande aggregerat flöde (201) av lP-datagram via en flödesklassificerare (205), k ä n n e t e ck n a fav att flödesklassificeraren (205) innefattar; - medel (206) för att dela upp det aggregerade flödet i åtminstone ett set av flöden, vart och ett av flödena motsvarande en enkelriktad paketström från en specifik session, och flödeklassificeraren (205) innefattar åtminstone en av följande medel; - medel (207) för att undersöka nyttolaststorleken på transportlagerdatagrammet hos ett paket i ett flöde från en specifik session; - medel (208) för att undersöka det statiska uppförandet i headerfalten, hos ett antal konsekutiva datapaket i flödet fran den specifika sessionen; eller - medel (209) för att undersöka inkrementellt uppförande i headerfälten hos ett antal konsekutiva datapaket i flödet fran den specifika sessionen; och flödeklassificeraren (205) innefattar även; - medel för att genomföra en av sagda undersökningar; - medel för att genomföra ytterligare en av sagda undersökningar som inte redan genomförts, om den genomförda första undersökning resulterar i att flödet kan vara ett realtidsflöde; - medel för att genomföra ännu en ytterligare undersökning av de ännu icke genomförda sagda undersökningar och så vidare till alla undersökningar är genomförda; att flödet är ett realtidsflöde, om det sista - medel för att besluta undersökningsresultatet visar att flödet kan vara ett realtidsflöde.
2. IP-nätverk (200) enligt patentkravet 1, k ä n n e t e c k n a t av att flödesklassificeraren (205) innefattar medel (211) för att rapportera till noden (204) huruvida flödet är ett realtidsflöde eller inte.
3. IP-nätverk (200) enligt något av patentkraven 1-2, k ä n n e t e c k n a t av att flödesklassificeraren (205) innefattar medel (212) för att undersöka om värdet i headerfalten hos ett applikationsdatagram i flödet från en specifik session uppfyller 10 15 20 25 . . . ,,. . -v -2 ' ,. ° ';. ut -. v -f *', 1 .l - »v ä' ' “ , . . ,-.. > ~ -- -- ; , i Ö_!} _ _... x -fvv _; , .,.. ifds. H 521 begränsningsrestriktionerna för en header hos ett applikationsdatagram innefattande realtidsdata.
4. IP-nätverk (200) enligt något av patentkraven 1-3, k ä n n e t e c k n a t av att flödesklassificeraren (205) innefattar medel (213) för att undersöka om nyttolaststorleken hos transportlagerdatagrammet är åtminstone så stort som det minsta möjliga datagrammet hos någon session innefattande realtidsdata.
5. IP-nätverk (200) enligt något av patentkraxfen 1-4, i vilket en utgående länk (203) från noden (204) är en radiolänk, k ä n n e t e c k n a t av att noden (204) har medel (214) för att allokera åtminstone en radioresurs baserat på om flödet är ett realtidsflöde eller inte.
6. IP-nätverk (200) enligt något av patentkraven 1-5, k ä n n e t e c k n a t av att noden (204) har medel (215) för att begära hos länkskiktet felskydd av flödet om flödet är ett icke-realtidsflöde.
7. lP-nätverk (200) enligt något av patentkraven 1-5, k ä n n e t e c k n a t av att noden (204) har medel (215) för att begära hos länkskiktet att inte felskydda flödet om flödet är ett realtidsflöde.
8. IP-nätverk (200) enligt något av patentkraven 1-4, där noden (204) är en växel, k ä n n e t e c k n a t av att växeln har medel (216) för att prioritera ett realtidsflöde över att icke- realtidsflöde vid växling.
9. IP-nätverk (200) enligt något av patentkraven 1-4, där noden (204) är en router, k ä n n e t e c k n a t av att routern har medel (216) för att prioritera ett realtidsflöde över ett icke- realtidsflöde vid routning.
10. IP-nätverk (200) enligt något av patentkraven 1-9, k ä n n e t e c k n a t av att realtidsflödet bär RTP (Real-time Transfer ProtocoD-ramar och flödet är ett UDP (User Datagram Protocol)-flöde. 10 15 20 25 30
11. Flödesklassificerare (205) för klassificering av huruvida ett flöde som överförs är ett realtidflöde eller inte dar flödet innefattar datagram i ett IP-natverk (200), flödesklassificeraren (205) mottar ett inkommande aggregerat flöde (201) av IP-paket, k ä n n e t e c k n a d av att flödesklassificeraren (205) innefattar; - medel (206) för att urskilja åtminstone ett set av flöden i ett aggregerat flöde, varje flöde motsvarande en enkelriktad paketström från en enda session; flödesklassificeraren (205) innefattande åtminstone ett av följande medel; - medel (207) för att undersöka nyttolaststorleken av ett transportskiktdatagram i ett paket i ett flöde från en specifik session; - medel (208) för att undersökta det statiska uppförandet i headerfalten hos ett antal konsekutiva datapaket i ett flöde fran den specifika scssionen; - medel (209) för att undersöka det inkrementella uppförandet hos headerfalten, hos ett antal konsekutiva datapaketi ett flöde från den specifika sessionen; flödesklassificeraren (205) innefattar också; - medel för att genomföra en av sagda undersökningar; - medel för att genomföra ytterligare en av sagda undersökningar som inte redan genomförts, om den genomförda första undersökning resulterar i att flödet kan vara ett realtidsflöde; - medel för att genomföra annu en ytterligare undersökning av de annu icke genomförda sagda undersökningar och så vidare till alla undersökningar är genomförda; att flödet är ett realtidsflöde, om det sista - medel för att besluta undersökningsresultatet visar att flödet kan vara ett realtidsflöde.
12. Flödesklassificerare (205) enligt patentkravet 11, k a n n e t e c k n a d av att flödesklassificeraren (205) innefattar medel (212) för att undersöka om värdet av headerfalten hos ett applikationsdatagram i ett flöde från en specifik session, uppfyller begransningsrestriktioner hos en header från ett tillampningsdatagram innefattande realtidsdata. 1 nn Illb- 2) »-
13. Flödesklassificerare (205) enligt något av patentkraven 11-12, k t e c k n a d av att flödesklassificeraren (205) innefattar medel (213) för att undersöka om nyttolaststorleken hos transportlagerdatagrammet i ett flöde från en specifik session ar 10 20 25 30 (n KO ...A fx cr Lx' /6 åtminstone så stor som minsta möjliga datagram från någon applikation innefattande realtidsdata.
14. Flödesklassificerare (205) enligt något av patentkraven 11-13, k ä n n e - t e c k n a d av att realtidsflödet bär RTP (Real-time Transfer Protocol)-ramar och flödet är ett UDP (User Datagram Protocol)-flöde.
15. Metod för att särskilja ett realtidsflöde från ett icke-realtidsflöde i en ström av IP- paket i ett IP-nätverk (200), IP-nätverket (200) innefattar en nod (204) mottagande ett inkommande aggregerat flöde av Illdatagram, vilken innefattar stegen av: - åtminstone ett flödes-set från det inkommande aggregerade flödet z/rfëzßèi' (300) där varje urskiljt flöde motsvarar en enkelriktad paketström från en enda session; ett av följande steg genomförs: - nyttolaststorleken hos transportlagerdatagrarnmet i ett paket i ett flöde fran en specifik session z/míerràki' (301); - vardena i headerfalten hos ett applikationsdatagram i flödet från den specifika session underföêi' (302) huruvida de uppfyller begränsningsrestriktionerna hos en header från ett applikationsdatagram innefattande realtidsdata; - det statiska uppförandet i headerfalt hos ett antal konsekutiva datapaket från den specfika session mzdenráki' (303); - inkrementellt uppförande hos headerfalten i ett antal konsekutiva datapaket från den specifika session z/nz/erràki' (304); om sagda genomförda undersökning resulterar i att flödet kan vara ett realtidsflöde, - genomföra ytterligare en av sagda undersökningar som inte redan genomförts, om sagda ytterligare genomförda undersökning resulterar i att flödet kan vara ett realtidsflöde, - genomföra ytterligare en av sagda undersökningar som inte redan genomförts, och så vidare tills alla undersökningssteg är genomförda; om det sista undersökningssteget resulterar i att flödet kan vara ett realtidsflöde, - besluta att flödet är ett realtidsflöde.
16. Metoden enligt patentkravet 15, innefattande det ytterligare steget att beslutet rapporteras (305) till nöden (204). 10 15 20 25 30 521 4623 HL
17. Metoden enligt något av patentkraven 15 och 16, där steget att undersöka (301) hos nyttolaststorleken hos datagrammet från transportsl-:iktet undersöks om det är åtminstone nyttolaststorleken datagrammet från transportskiktet innefattar så stort som det rninsta möjliga datagrammet från någon session innefattande realtidsdata.
18. Metoden enligt något av patentkraven 16-17, där en utgående länk (203) från noden (204) är en radiolänk, innefattande det ytterligare steget att tas efter rapportering av beslutet till noden (204): åtminstone en radioresurs allokeras på basis av huruvida flödet är ett realtidsflöde eller inte.
19. Metoden enligt något av patentkraven 16418, innefattande ytterligare steg att tas efter rapportering av beslutet till noden (204): felskydd begärs hos länkskiktet om flödet är ett icke-realtídsflöde.
20. Metoden enligt något av patentkraven 16-18, innefattande det ytterligare steget att tas efter rapportering av beslutet till noden (204): att inte felskydda begärs hos länkskiktet om flödet är ett realtidsflöde.
21. Metoden enligt något av patentkraven 16-17, innefattande det ytterligare steget att tas efter rapportring av beslutet till noden (204), där noden (204) är en växel: realtidsflöde prioriteras över icke-realtidsflöde vid växling.
22. Metoden enligt något av patentkraven 16-17, innefattande det ytterligare steget att tas efter rapportering till noden (204) där noden (204) är en router: realtidsflöde prioriteras över icke-realtidsflöde vid routning.
23. Metoden enligt något av patentkraven 15-22, där realtidsflödet bär RTP (Real-time Transfer ProtocoD-ramar och där flödet är ett UDP (User Datagram ProtocoD-flöde.
SE9903390A 1999-09-20 1999-09-20 Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte SE521463C2 (sv)

Priority Applications (4)

Application Number Priority Date Filing Date Title
SE9903390A SE521463C2 (sv) 1999-09-20 1999-09-20 Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte
PCT/SE2000/001712 WO2001022666A1 (en) 1999-09-20 2000-09-06 Ip flow classifier for distinguishing real-time flows from non-real-time flows
AU75657/00A AU7565700A (en) 1999-09-20 2000-09-06 Ip flow classifier for distinguishing real-time flows from non-real-time flows
US09/664,915 US6801530B1 (en) 1999-09-20 2000-09-18 Communication system and method in a communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
SE9903390A SE521463C2 (sv) 1999-09-20 1999-09-20 Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte

Publications (3)

Publication Number Publication Date
SE9903390D0 SE9903390D0 (sv) 1999-09-20
SE9903390L SE9903390L (sv) 2001-03-21
SE521463C2 true SE521463C2 (sv) 2003-11-04

Family

ID=20417078

Family Applications (1)

Application Number Title Priority Date Filing Date
SE9903390A SE521463C2 (sv) 1999-09-20 1999-09-20 Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte

Country Status (4)

Country Link
US (1) US6801530B1 (sv)
AU (1) AU7565700A (sv)
SE (1) SE521463C2 (sv)
WO (1) WO2001022666A1 (sv)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002091202A1 (en) * 2001-05-04 2002-11-14 Globespan Virata Incorporated System and method for distributed processing of packet data containing audio information
US20020188732A1 (en) * 2001-06-06 2002-12-12 Buckman Charles R. System and method for allocating bandwidth across a network
US7095715B2 (en) * 2001-07-02 2006-08-22 3Com Corporation System and method for processing network packet flows
US20030033519A1 (en) * 2001-08-13 2003-02-13 Tippingpoint Technologies,Inc. System and method for programming network nodes
US7124195B2 (en) * 2001-10-17 2006-10-17 Velcero Broadband Applications, Llc Broadband network system configured to transport audio or video at the transport layer, and associated method
US20030095567A1 (en) * 2001-11-20 2003-05-22 Lo Man Kuk Real time protocol packet handler
US7239639B2 (en) 2001-12-27 2007-07-03 3Com Corporation System and method for dynamically constructing packet classification rules
ATE323360T1 (de) * 2002-04-03 2006-04-15 Cit Alcatel Verfahren und vorrichtungen zur umordnung von paketen in einem netzwerkprozessor
US7706402B2 (en) * 2002-05-06 2010-04-27 Ikanos Communications, Inc. System and method for distributed processing of packet data containing audio information
DE60220267T2 (de) * 2002-07-08 2008-01-17 Sony Deutschland Gmbh Konvergenzschichten für Netzwerkgeräte und Verfahren zur Datenverkehrübertragung
CN1531282A (zh) * 2003-03-12 2004-09-22 ���µ�����ҵ��ʽ���� 分组中继装置
US8717868B2 (en) * 2003-12-19 2014-05-06 Rockstar Consortium Us Lp Selective processing of damaged packets
IL163092A (en) * 2004-07-19 2010-11-30 Veraz Networks Ltd Processing of packets forwarded in communication networks
ATE520227T1 (de) * 2004-11-19 2011-08-15 Northrop Grumman Systems Corp System und verfahren zur paketverarbeitung in echtzeit
US7506156B2 (en) * 2005-02-01 2009-03-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for prioritizing encrypted traffic at an intermediate node in a communications network
US20060262789A1 (en) * 2005-05-20 2006-11-23 Go Networks Inc. Method and corresponding device for packets classification
CN100417140C (zh) * 2005-10-24 2008-09-03 华为技术有限公司 一种流分类装置和方法以及采用该流分类装置的基站
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
CN101106490B (zh) * 2006-07-11 2012-01-04 华为技术有限公司 预置流分类器的建立方法及其系统和用户终端
US8014322B2 (en) * 2007-02-26 2011-09-06 Cisco, Technology, Inc. Diagnostic tool for troubleshooting multimedia streaming applications
US9019830B2 (en) 2007-05-15 2015-04-28 Imagine Communications Corp. Content-based routing of information content
US8811294B2 (en) 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US9264248B2 (en) 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9582239B2 (en) 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
US9942161B1 (en) 2012-09-29 2018-04-10 Western Digital Technologies, Inc. Methods and systems for configuring and updating session-based quality of service for multimedia traffic in a local area network
US9559975B1 (en) 2012-09-29 2017-01-31 Western Digital Technologies, Inc. Real-time analysis of quality of service for multimedia traffic in a local area network
US9774533B2 (en) * 2014-08-06 2017-09-26 Futurewei Technologies, Inc. Mechanisms to support service chain graphs in a communication network
CN106341344B (zh) * 2016-09-21 2019-10-11 杭州迪普科技股份有限公司 一种多通道流程的流分类方法和装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR970000668B1 (ko) * 1994-02-21 1997-01-16 재단법인 한국전자통신연구소 비동기 전달 모드(atm) 망에서의 폭주를 예방하기 위한 트래픽 출력 억제 장치 및 방법
US5790534A (en) 1996-09-20 1998-08-04 Nokia Mobile Phones Limited Load control method and apparatus for CDMA cellular system having circuit and packet switched terminals
US6028842A (en) * 1996-12-23 2000-02-22 Nortel Networks Corporation Dynamic traffic conditioning
US6594268B1 (en) * 1999-03-11 2003-07-15 Lucent Technologies Inc. Adaptive routing system and method for QOS packet networks
CN1293478C (zh) * 1999-06-30 2007-01-03 倾向探测公司 用于监控网络流量的方法和设备
US6633540B1 (en) * 1999-07-02 2003-10-14 Nokia Internet Communications, Inc. Real-time traffic shaper with keep-alive property for best-effort traffic

Also Published As

Publication number Publication date
SE9903390L (sv) 2001-03-21
AU7565700A (en) 2001-04-24
SE9903390D0 (sv) 1999-09-20
WO2001022666A1 (en) 2001-03-29
US6801530B1 (en) 2004-10-05

Similar Documents

Publication Publication Date Title
SE521463C2 (sv) Klassificerare i ett IP nätverk med medel för att avgöra huruvida ett transmitterat flöde är ett realtidsflöde eller inte
US6515963B1 (en) Per-flow dynamic buffer management
US6724721B1 (en) Approximated per-flow rate limiting
US7200116B2 (en) Communication device and method, and system
US8045454B2 (en) Multimedia data flow dropping
US7746781B1 (en) Method and apparatus for preserving data in a system implementing Diffserv and IPsec protocol
US8284665B1 (en) Flow-based rate limiting
US7215641B1 (en) Per-flow dynamic buffer management
US7787442B2 (en) Communication statistic information collection apparatus
US20070183332A1 (en) System and method for backward congestion notification in network
SE518720C2 (sv) Anordning och förfarande relaterande till trafikstyrning
CN101692657A (zh) 分级服务核心路由器及其数据转发方法
JP2003078549A (ja) パケット転送方法およびその装置
CN102132535A (zh) 在通信网中传输数据分组的方法和交换装置
KR20090079945A (ko) 플로우 정보 제한장치 및 방법
CN101552726A (zh) 一种分级服务边缘路由器
Bless A lower-effort per-hop behavior (LE PHB) for differentiated services
Jamali et al. An improvement over random early detection algorithm: a self-tuning approach
CN113169832B (zh) 分组交换通信网络中的性能测量
Irawan et al. Performance evaluation of queue algorithms for video-on-demand application
Magalhaes et al. A new QoS mapping for streamed MPEG video over a DiffServ domain
Engan et al. Selective truncating internetwork protocol: experiments with explicit framing
US7593334B1 (en) Method of policing network traffic
US11283722B2 (en) Packet prioritization for frame generation
Bless RFC 8622: A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services

Legal Events

Date Code Title Description
NUG Patent has lapsed