FI104602B - Vuonohjaus tietoliikenneverkossa - Google Patents

Vuonohjaus tietoliikenneverkossa Download PDF

Info

Publication number
FI104602B
FI104602B FI973746A FI973746A FI104602B FI 104602 B FI104602 B FI 104602B FI 973746 A FI973746 A FI 973746A FI 973746 A FI973746 A FI 973746A FI 104602 B FI104602 B FI 104602B
Authority
FI
Finland
Prior art keywords
network
node
traffic
packet
tcp
Prior art date
Application number
FI973746A
Other languages
English (en)
Swedish (sv)
Other versions
FI973746L (fi
FI973746A0 (fi
Inventor
Jian Ma
Original Assignee
Nokia Networks Oy
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
Priority claimed from FI972981A external-priority patent/FI972981A7/fi
Publication of FI973746A0 publication Critical patent/FI973746A0/fi
Priority to FI973746A priority Critical patent/FI104602B/fi
Application filed by Nokia Networks Oy filed Critical Nokia Networks Oy
Priority to PCT/FI1998/000591 priority patent/WO1999004536A2/en
Priority to CN98808150.4A priority patent/CN1267419A/zh
Priority to JP2000503633A priority patent/JP2001510957A/ja
Priority to AU84434/98A priority patent/AU745204B2/en
Priority to EP98935050A priority patent/EP0997020A2/en
Publication of FI973746L publication Critical patent/FI973746L/fi
Priority to NO20000171A priority patent/NO20000171L/no
Publication of FI104602B publication Critical patent/FI104602B/fi
Application granted granted Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

1 104602
Vuon ohjaus tietoliikenneverkossa
Keksinnön ala
Keksintö liittyy yleisesti vuon ohjaukseen tietoliikenneverkossa. Tar-5 kemmin sanottuna, keksintö liittyy ruuhkan valvontaan pakettikytkentäisessä tietoliikenneverkossa, erityisesti verkossa, jossa TCP (Transmission Control Protocol) on käytössä kuljetuskerroksen protokollana.
Keksinnön tausta 10 Kuten yleisesti tunnettua, TCP on suosituin kuljetuskerroksella tie donsiirtoon käytettävä protokolla. Se tarjoaa luotettavaa yhteydellistä tiedonsiirtoa kahden isäntäkoneen välillä. (Isäntäkone viittaa verkkoon kytkettyyn tietokoneeseen tai mihin tahansa järjestelmään, joka voidaan kytkeä verkkoon palvelujen tarjoamiseksi toiselle samaan verkkoon kytketylle isäntäkoneelle.) 15 TCP käyttää useita menettelytapoja siirtoyhteyden suorituskyvyn maksimoimiseksi monitoroimalla eri muuttujia, jotka liittyvät siirtoyhteyteen. TCP sisältää esim. sisäisen algoritmin ruuhkan välttämiseksi.
ATM (Asynchronous Transfer Mode) on puolestaan (uudempi) yhteydellinen paketinvälitystekniikka, joka kansainvälinen tietoliikennealan standar-20 dointijärjestö ITU-T on valinnut laajakaistaisen digitaalisen monipalveluverkon (B-ISDN) perusratkaisuksi. ATM-verkossa on perinteisten pakettiverkkojen ongelmia eliminoitu käyttämällä lyhyitä, kiinteän pituisia (53 tavua) paketteja, joita kutsutaan soluiksi. ATM-verkkoja ollaan nopeasti ottamassa runkoverkoiksi TCP/IP-verkkojen (kuten Internetin) eri osissa.
25 Vaikka ATM on suunniteltu tarjoamaan päästä päähän ulottuvaa kuljetuskerrostason palvelua, on hyvin todennäköistä, että tulevaisuudessa verkot tullaan toteuttamaan siten, että (a) TCP/IP pysyy verkkojen de-facto-standardina ja (b) vain osa päästä päähän ulottuvasta yhteydestä on toteutettu ATM:n avulla. Vaikka siis ATM:n hyödyntämistä jatketaan, TCP:tä tullaan silti 7 : 30 tarvitsemaan päästä päähän ulottuvien siirtopalvelujen tarjoamiseksi.
ATM:n käyttöönotto merkitsee myös sitä, että toteutusten on pystyttävä tukemaan suurta joukkoa sellaisia olemassa olevia datasovelluksia, joissa TCP:tä käytetään yleisesti kuljetuskerroksen protokollana. Aikaisemmin on kehitelty useita lähestymistapoja ATM-verkkojen ruuhkan hallintaa varten 35 ylempien kerrosten olemassa olevien protokollien siirtämiseksi ATM-verkkoihin.
2 104602
Ruuhkan valvonta liittyy yleiseen ongelmaan, joka koskee pakettiverkkojen liikenteen hallintaa. Ruuhka (congestion) tarkoittaa tilannetta, jossa siirtopyyntöjen lukumäärä tietyllä ajanhetkellä ylittää verkon tietyn pisteen (jota kutsutaan pullonkaularesurssiksi) kapasiteetin. Ruuhka johtaa yleensä yli-5 kuormitustilanteeseen. Tämän seurauksena esim. puskurit vuotavat yli, jolloin joko verkko tai tilaaja lähettää paketteja uudelleen. Yleisesti ottaen ruuhka syntyy, kun tietylle linkille tulevan liikenteen määrä ylittää linkin lähtökapasitee-tin. Ruuhkan valvonnan pääasiallisin funktio on varmistaa hyvä suorituskyky läpimenon ja viiveen suhteen sekä ylläpitää samalla verkkoresurssien oikeu-10 denmukainen jako käyttäjille. TCP-liikenteelle, jonka liikennemallit ovat usein purskeisia, ruuhkan valvonta asettaa haastavan ongelman. On tunnettua, että pakettien menettämiset johtavat merkittävään TCP-läpimenon heikkenemiseen. Näin ollen, parhaan mahdollisen läpimenon kannalta pitäisi menetettyjen pakettien lukumäärän olla minimissään.
15 Esillä oleva keksintö liittyy pakettiverkoissa suoritettavaan ruuhkan hallintaan. Edellä mainituista syistä useimmat tällaiset verkot ovat, ja tulevat ennustettavissa olevassa tulevaisuudessa olemaan, TCP-verkkoja tai TCP/ATM-verkkoja (eli verkkoja, joissa TCP tarjoaa päästä päähän ulottuvat siirtopalvelut ja ATM tarjoaa alla olevat “bittiputket”). Seuraavassa kuvataan 20 lyhyesti näiden verkkojen ruuhkanvalvontamekanismeja.
ATM Forum on määritellyt viisi eri palveluluokkaa, jotka liittävät liikenteen ominaisuudet ja palvelun laatuvaatimukset (QoS, Quality of Service) verkon käyttäytymiseen. Nämä palveluluokat ovat: vakio bittinopeus (CBR, Constant Bit Rate), reaaliaikainen, muuttuva bittinopeus (rt-VBR, real-time 25 Variable Bit Rate), käytettävissä oleva bittinopeus (ABR, Available Bit Rate) ja määrittelemätön bittinopeus (UBR, unspecified Bit Rate). Nämä palveluluokat jakavat liikenteen taattuun liikenteeseen ja ns. “best effort" -liikenteeseen, joka on sitä liikennettä, joka täyttää jäljellä olevan kaistanleveyden sen jälkeen, kun taatulle liikenteelle on tarjottu palvelua.
’·' 30 Eräs mahdollinen ratkaisu “best effort" -liikennettä varten on käyttää ABR-vuonohjausta. Pääajatus ABR-vuonohjauksessa on käyttää erityisiä soluja, ns. RM-soluja (Resource Management) säätämään lähteiden nopeuksia. ABR-lähteet tunnustelevat säännöllisesti verkon tilaa (sellaisia tekijöitä kuin käytettävissä oleva kaistanleveys, ruuhkan tila ja lähestyvä ruuhka) lä-35 hettämällä RM-soluja datasolujen sekaan. RM-solut käännetään takaisin kohteessa ja lähetetään takaisin lähteelle. Matkan varrella ATM-kytkimet voivat 3 104602 kirjoittaa ruuhkainformaatiota näihin RM-soluihin. Vastaanottaessaan palautetut RM-solut lähde voi lisätä tai vähentää nopeuttaan tai ylläpitää sen hetkisen nopeutensa, sen mukaan, millaista solujen tuoma informaatio on.
TCP/ATM-verkoissa lähde ja kohde ovat yhteydessä toisiinsa 5 IP/ATM/IP-aliverkon kautta. Kuvio 1 havainnollistaa TCP-lähteen A ja TCP-kohteen B välistä yhteyttä verkossa, jossa yhteysreitti kulkee ABR-vuonohjausta käyttävän ATM-verkon läpi. Kun ATM-verkossa havaitaan ruuhkaa, ABR-nopeusvalvonta alkaa vaikuttaa pakottaen reunareitittimen R1 vähentämään lähetysnopeuttaan ATM-verkon suuntaan. ABR-10 valvontasilmukan tarkoituksena on siis komentaa verkon ATM-lähteitä vähentämään lähetysnopeuttaan. Mikäli ruuhka ei hellitä, reitittimen puskuri saavuttaa maksimikapasiteettinsa. Tämän seurauksena reititin alkaa hylätä paketteja, mikä johtaa TCP-ruuhkaikkunan pienenemiseen (ruuhkaikkunakäsitettä selostetaan tarkemmin jäljempänä.) 15 Ruuhkanvalvonnan kannalta kuvion 1 verkko käsittää kaksi itsenäistä valvontasilmukkaa: ABR-valvontasilmukan ja TCP-valvontasilmukan. Tällaisella ruuhkanvalvonnalla, joka perustuu kahteen ruuhkanhallintajärjestelmään, jotka ovat eri protokollakerroksilla, voi kuitenkin olla odottamaton ja ei-toivottu vaikutus verkon suorituskykyyn. Tarkemmin sanottuna, sisempi valvontasil-20 mukka (ABR-silmukka) voi aiheuttaa odottamattomia viiveitä ulommassa valvontasilmukassa (TCP-silmukka).
Vaihtoehtoinen lähestymistapa “best effort” -liikennettä varten on käyttää UBR-palvelua riittävän suurien puskurien kanssa ja antaa ylempien , kerrosten protokollien, kuten TCP:n hoitaa ylikuorma- tai ruuhkatilanteet. Kuvio 25 2 havainnollistaa tällaista verkkoa eli TCP/UBR-verkkoa. Tällaisen verkon solmut käsittävät pakettien hylkäysmekanismeja, jotka hylkäävät paketteja tai soluja, kun ruuhka syntyy. Kun paketti hylätään jossakin päin verkkoa, vastaava TCP-lähde ei vastaanota kuittausta. Tämän seurauksena TCP-lähde pienentää lähetysnopeuttaan.
30 UBR-palvelu ei käytä vuonvalvontaa eikä se taijoa numeerisia takuita palvelun laadulle; tämän takia se on myös halvin tarjottava palvelu. Yksinkertaisuutensa takia pelkkä UBR ilman riittävää puskurikokoa antaa kuitenkin huonon suorituskyvyn ruuhkaisissa verkoissa.
Tämän epäkohdan eliminoimiseksi on ehdotettu monimutkaisempia 35 ruuhkanvalvontamekanismeja. Eräs tällainen on EPD-jäijestelmä (early packet discard). EPD-järjestelmässä ATM-kytkin tuhoaa kokonaisia paketteja ennen 4 104602 puskurin ylivuotoa. Tällä tavoin TCP/ATM-verkon läpäisykykyä voidaan parantaa merkittävästi, koska ATM-kytkimien ei tarvitse lähettää korruptoituneita soluja sisältävän paketin soluja, eli soluja, jotka kuuluvat paketteihin, joista ainakin yksi solu on hylätty (nämä paketit hylättäisiin joka tapauksessa paketti-5 en uudelleen muodostuksen yhteydessä): EPD-järjestelmän toinen etu on se, että se on suhteellisen halpa toteuttaa ATM-kytkimessä. Ne, jotka ovat kiinnostuneita aiheesta, löytävät EPD-menetelmän yksityiskohtaisen kuvauksen esim. artikkelista A. Romanow and S. Floyd, Dynamics of TCP Traffic over ATM Networks, Proc. ACM SIGCOMM ’94, pp. 79-88, August 1994.
10 EPD-menetelmä kohtelee käyttäjiä kuitenkin epäoikeudenmukaisesti.
Tämä johtuu siitä, että EPD tuhoaa kokonaisia paketteja kaikilta yhteyksiltä, ottamatta huomioon niiden sen hetkisiä nopeuksia tai niiden suhteellisia osuuksia puskurissa, eli ottamatta huomioon niiden suhteellista vaikutusta ylikuormitustilanteeseen. Tämän epäkohdan korjaamiseksi on ehdotettu useita 15 muunnelmia pakettien selektiivistä hylkäystä varten. Yksi näistä on kuvattu artikkelissa Röhit Goyal, Perfomnance of TCP/IP over UBR+, ATM_Forum/96-1269. Tämä menetelmä käyttää FIFO-puskuria kytkimessä ja se suorittaa virtuaaliyhteyskohtaista kirjanpitoa pitääkseen kirjaa kunkin virtuaaliyhteyden osuudesta puskurissa. Tällä tavoin voidaan hylätä vain ylikuormittavien yhte-20 yksien soluja, kun taas alikuormittavat yhteydet voivat lisätä läpäisykykyään.
Kaikista edellä esitetyistä parannuksista huolimatta tunnetun tekniikan mukaisilla ruuhkanvalvontamenetelmillä on edelleenkin se epäkohta, että liikennelähteelle ei pystytä antamaan aikaista varoitusta silloin, kun verkossa havaitaan liiallista kuormaa. Toisin sanoen, liikennelähdettä ei informoida 25 nopeasti ylikuormasta, jotta lähde pystyisi vähentämään lähetysnopeuttaan.
Keksinnön lyhyt yhteenveto
Keksinnön tarkoituksena on eliminoida edellä mainittu epäkohta ja luoda menetelmä, jonka avulla on mahdollista, käyttäen yksinkertaista toteu-; 30 tusta, informoida liikennelähdettä hyvin aikaisessa vaiheessa siitä, että verkko • on tulossa ylikuormitetuksi ja pyytää lähdettä vähentämään lähetysnopeuttaan.
Tarkoituksena on myös, että menetelmä sallii TCP- ja ATM-vuonohjausmekanismien tehokkaan yhteistoiminnan.
Tämä päämäärä on saavutettavissa käyttämällä itsenäisissä vaati-35 muksissa esitettyä ratkaisua.
5 104602
Keksinnön perusajatuksena on viivästyttää niitä kuittauksia, joita ollaan siirtämässä kohteesta kohti lähettäjää. Tämä voidaan tehdä verkon samassa pisteessä, jossa ruuhkaa on havaittu tai vaihtoehtoisesti se verkon piste, joka havaitsee ruuhkaa tai ylikuormaa voi ohjata verkon toista pistettä 5 viivästämään kuittauksia. Keksinnössä suoritetaan siis ruuhkan ohjausta yhteyden paluureitillä, kun taas tunnetut järjestelmät ohjaavat liikennettä me-noreitillä. Sen sijaan, että keksinnön mukainen verkko hylkäisi paketteja tai soluja menoreitillä, se viivästää kuittauksia paluureitillä ja saa siten aikaan sen, että TCP-lähde vähentää lähetysnopeuttaan.
10 Keksintö tarjoaa halvan ratkaisun aikaisen varoituksen antamiseksi TCP-lähteelle siitä, että ylikuormitus tai ruuhka on uhkaamassa verkkoa. On myös tärkeää huomata, että TCP-protokollaa ei tarvitse muuttaa mitenkään. Keksinnön käyttöönottamiseksi verkkoon on tuotava ruuhkanvalvonta-algoritmi, mutta tähän tarkoitukseen voidaan käyttää monia olemassa olevia, 15 TCP/UBR-verkkoihin liittyviä algoritmeja vain vähäisin muutoksin.
Esillä olevan keksinnön avulla voidaan lisäksi tasoittaa TCP-lähteen ulostulonopeutta, mikä puolestaan johtaa tehokkaampaan kaistanleveyden hyödyntämiseen. Lisäksi puskurikapasiteettivaatimukset pienenevät, koska (nopeus)vaihtelun määrä vähenee.
20 Keksinnön erään edullisen toteutustavan mukaisesti kuormitus- tasoinformaatiota lähetetään ATM-verkon pisteestä RM-soluissa solmuun, joka tarjoaa liittymän ATM-verkkoon ja kuittauksia viivästetään mainitussa liitty-mäsolmussa RM*solujen sisältämän informaation perusteella. Tällä tavoin TCP- ja ATM-vuonohjausmekanismit voidaan tehdä toisistaan riippuvaisiksi 25 niin, että toimivat tehokkaasti yhdessä.
Keksinnön avulla yhteyksien suorituskykyä voidaan parantaa merkittävästi, erityisesti suurissa viiveellisissä verkoissa.
Kuvioluettelo , ; 30 Kuvio 1 havainnollistaa ABR-pohjaisen ATM-aliverkon kautta kulke- vaa TCP-yhteysreittiä, kuvio 2 havainnollistaa UBR-pohjaisen ATM-aliverkon kautta kulkevaa TCP-yhteysreittiä, kuvio 3 havainnollistaa keksinnön mukaista vuonohjaussilmukkaa 35 TCP/ATM-verkossa, 6 104602 kuvio 4a havainnollistaa uuden menetelmän yhtä mahdollista toteutustapaa IP-kytkimessä, kuvio 4b on aikadiagrammi, joka esittää kuvion 4a mukaisen toteutuksen merkitseviä ajanhetkiä, 5 kuvio 5 on vuokaavio, joka havainnollistaa menetelmää viivearvojen määrittämiseksi, kuvio 6a havainnollistaa kuittausten viivästämisen toista mahdollista toteutustapaa kytkimessä, kuvio 6b havainnollistaa kuittauspuskureiden vaihtoehtoista käyttöta- 10 paa, kuvio 7a havainnollistaa menetelmän erästä sovellustapaa IP-verkossa, kuvio 7b havainnollistaa menetelmän erästä toista sovellustapaa IP-verkossa, 15 kuvio 8a havainnollistaa menetelmän erästä sovellustapaa ATM- verkossa, kuvio 8b havainnollistaa menetelmän erästä toista sovellustapaa ATM-verkossa, kuvio 9 havainnollistaa keksinnön edullisen toteutustavan mukaista 20 TCP- ja ATM-vuonohjaussilmukoiden yhteistoimintaa, kuvio 10 havainnollistaa esimerkkiä pakettien siirrosta liikennelähteen ja -kohteen välillä tunnetussa TCP-verkossa, ja kuvio 11 havainnollistaa esimerkkiä pakettien siirrosta liikennelähteen ja -kohteen välillä TCP-verkossa, joka käyttää keksinnön mukaista menetel-25 mää.
Keksinnön yksityiskohtainen kuvaus
Kuvio 3 havainnollistaa keksinnön perusperiaatetta esittämällä kahden käyttäjäpäätelaitteen (A ja B) välistä yhteyttä TCP/ATM-verkossa, jossa ; 30 päätelaitteet käyttävät TCP:tä kuljetuskerroksen protokollana. Päätelaitteiden liittymäsolmujen (AN1 ja AN2) lisäksi kuviossa on esitetty vain yksi välisolmu (N1) ja solmuja yhdistävät siirtojohdot (TL1 ja TL2).
Isäntäkoneiden A ja B välinen yhteys alkaa, samoin kuin mikä tahansa muu TCP-yhteys, isäntäkoneiden välisellä neuvottelulla yhteyden avaami-35 seksi. Alkuneuvottelua kutsutaan kolmivaiheiseksi kättelyksi, koska tämän kättelyvaiheen aikana siirretään kolme avaussegmenttiä. Termi "segmentti” 7 104602 viittaa TCP:n IP:lle (IP, Internet Protocol) välittämään informaatioyksikköön. IP-otsikot yhdistetään näihin TCP-segmentteihin IP-tietosähkeiden muodostamiseksi eli TCP-segmentit siirretään vastaanottimeen IP-tietosähkeiden sisällä, jotka ovat IP:n käyttämiä tietoyksiköitä. Alkukättelyprosessin aikana isäntäko-5 neet informoivat toisiaan esim. suurimmasta segmenttikoosta, jonka ne hyväksyvät. Tämä tehdään, jotta vältettäisiin TCP-segmenttien pirstoutuminen, koska se heikentäisi merkittävästi TCP-yhteyden suorituskykyä.
Sen jälkeen, kun alkukättely on käyty loppuun, isäntäkoneet alkavat lähettää dataa TCP-segmenttien avulla. Jokainen virheetön TCP-segmentti 10 kuitataan, mukaan lukien kättelysegmentit. Keksinnön perusajatuksen havainnollistamiseksi olettakaamme, että isäntäkone A lähettää yhden TCP-segmentin isäntäkoneelle B, Verkkokerroksella isäntäkone A lisää tähän TCP-segmenttiin IP-otsikon IP-tietosähkeen muodostamiseksi. Tietosähke muutetaan standardeiksi ATM-soluiksi liittymäsolmussa AN1, joka sijaitsee ATM-15 verkon ANW reunalla. Tietosähkeen solut reititetään sen jälkeen ATM-verkon läpi isäntäkoneen B liittymäsolmulle AN2. Tämä liittymäsolmu rekonstruoi alkuperäisen IP-tietosähkeen saapuvista soluista ja lähettää sen isäntäkoneelle B. Isäntäkone B poistaa IP-otsikon saadakseen TCP-segmentin esille. Jos segmentti vastaanotetaan oikein, isäntäkone B lähettää kuittaavan TCP-20 segmentin ACK1 takaisin isäntäkoneelle A. Tähän asti verkko on toiminut tunnetulla tavalla.
Verkon kuormaa valvotaan liittymäsolmussa AN1 esim. valvomalla yhden tai useamman sellaisen puskurin täyttöastetta, joka puskuroi liikennettä ATM-verkkoon. Jos ylikuormaa havaitaan, eli jos puskurin täyttöaste ylittää 25 ennalta määritetyn rajan, lähetetään solmun sisällä ruuhkailmoitus CM niiden kuittausten viivästämiseksi, jotka sillä hetkellä kulkevat kytkimen läpi kohti liikennelähteitä. Näin ollen myös esimerkkinä käyttämäämme kuittausta (ACK1) viivästetään, kun se kulkee liittymäsolmun AN1 kautta, edellyttäen, että solmussa AN1 on ylikuormaa juuri kyseisen ajanjakson aikana.
·: 30 TCP on yksi harvoista kuljetusprotokollista, joilla on sisäisesti ruuhkan valvontamekanismi. Keksinnön mukainen ratkaisu on riippuvainen tästä tunnetusta TCP-valvontamekanismista, muita valvontamekanismeja ei tarvita lähteessä eikä kohteessa. Seuraavassa tätä mekanismia kuvataan lyhyesti.
TCP-ruuhkanvalvonta perustuu kahteen muuttujaan: vastaanottimen 35 ilmoitettuun ikkunaan (Wrcvr) ja ruuhkaikkunaan (CNWD). Vastaanottimen ilmoitettua ikkunaa (advertised window) ylläpidetään vastaanottimessa vas- 8 104602 taanottimen puskurointikapasiteetin mittana ja ruuhkaikkunaa (congestion window) ylläpidetään lähetyspäässä verkon kapasiteetin mittana. TCP-lähde ei voi koskaan lähettää enempää segmenttejä kuin mikä on minimi vastaanottimen ilmoitetusta ikkunasta ja ruuhkaikkunasta.
5 TCP-ruuhkanvalvontamenetelmä käsittää kaksi vaihetta: hitaan aloi tuksen (slow start) ja ruuhkan eston (congestion avoidance). Muuttujaa SSTHRES (slow start threshold) pidetään yllä lähteessä, jotta erotettaisiin nämä kaksi vaihetta. Lähde aloittaa lähettämisen hitaan aloituksen mukaisesti lähettämällä yhden TCP-segmentin, eli CWND:n arvo asetetaan ykköseksi 10 alussa. Kun lähde vastaanottaa kuittauksen, se kasvattaa CWND:tä yhdellä ja lähettää sen seurauksena kaksi segmenttiä. Tällä tavoin CWND:n arvo kaksinkertaistuu hitaan aloituksen vaiheessa jokaisen edestakaista kulkuaikaa vastaavan ajanjakson aikana, koska kohdepäätelaite kuittaa jokaisen segmentin. Hitaan aloituksen vaihe päättyy ja ruuhkanestovaihe alkaa, kun CWND 15 saavuttaa muuttujan SSTHRES arvon.
Jos paketti menetetään TCP-yhteydellä, lähde ei vastaanota kuittausta ja sen aikavalvonta laukeaa. Lähde asettaa muuttujan SSTHRES arvoon, joka on puolet muuttujan CWND arvosta paketin menettämishetkellä. Tarkemmin sanottuna, SSTHRES asetetaan arvoon max{2, min{CWND/2, 20 Wrcvr}} ja CWND asetetaan arvoon yksi. Tämän seurauksena lähde siirtyy ruuhkanestovaiheeseen, jonka aikana se kasvattaa CWND:tä arvolla 1/CWND joka kerta, kun segmentti kuitataan.
Koska keksintö ei millään tavalla muuta edellä kuvattua tunnettua TCP-ruuhkanvalvontamekanisimia, sitä ei kuvata tässä yhteydessä tarkemmin. 25 Asiasta kiinnostunut voi löytää yksityiskohtaisempaa tietoa useista alan kirjoista. (Katso esim. W. Richard Stevens, TCP/IP Illustrated Volume 1, The protocols, Addison-Wesley, 1994, ISBN 0-201-63346-9).
Keksinnön mukaisesti viivästetään yhtä tai useampaa kuittausta, kun ylikuormaa tai ruuhkaa havaitaan verkon pisteessä. Tällä tavoin TCP-lähde, ·: 30 joka toimii edellä kuvatulla tavalla, alkaa automaattisesti vähentää lähetysno peuttaan tai ainakaan se ei kasvata lähetysnopeuttaan yhtä nopeasti kuin se muuten kasvattaisi. Tämä johtuu siitä, että viive pienentää nopeutta, jolla lähde kasvattaa ruuhkaikkunansa kokoa.
Kuvio 4a havainnollistaa tätä periaatetta esittämällä esimerkin, jossa 35 kuittauksia viivästetään IP-kytkimen lähtöportissa OP. Kuormanmittausyksikkö LMU mittaa kytkimen kuormitustasoa mittaamalla niiden puskureiden täyttö- 9 104602 asteita, jotka puskuroivat kytkimen läpi menosuunnassa menevää liikennettä. Huomattakoon, että kuormitustaso voidaan kuitenkin määrittää millä tahansa tunnetulla tavalla.
IP-tietosähkeet, jotka kulkevat kytkimen läpi paluusuunnassa reitite-5 tään ensin oikeaan lähtöporttiin. Tässä portissa vastaanotetut tietosähkeet talletetaan FIFO-tyyppiseen lähtöpuskuriin OB.
Liikenteen haaroitin TS lukee talletetut puskurit lähtöpuskurista, paketti kerrallaan puskurin ensimmäisestä muistipaikasta ML1. Liikenteen haaroitin toimii seuraavalla tavalla.
10 Jos kuormanmittausyksiköltä tuleva ruuhkasignaali CS osoittaa, että kytkimen kuorma on alle ennalta määritetyn tason, liikenteen haaroitin välittää kaikki tietosähkeet (paketit) suoraan lähtevälle siirtoyhteydelle OL, riippumatta siitä, sisältävätkö ne kuittauksia vai eivät.
Toisaalta, jos ruuhkasignaali CS osoittaa, että kuormitustaso on 15 saavuttanut ennalta määritetyn tason, liikenteen haaroitin alkaa lukea jokaisen IP-tietosähkeen sisällä olevan TCP-otsikon kuittausbitin. Jos tämä bitti on voimassa, eli jos tietosähke sisältää kuittauksen, liikenteen haaroitin välittää paketin kuittauspuskurille AB. Jos bitti ei ole voimassa, liikenteen haaroitin välittää paketin suoraan lähtevälle siirtoyhteydelle OL. Vain siis kuittauksen 20 sisältäviä paketteja viivästetään.
Kuittauspuskurissa jokaista tietosähkettä viivästetään tietyn ajanjakson verran. Ajanjakson pituus on edullisesti suoraan verrannollinen yksikön LMU mittaamaan sen hetkiseen kuormitustasoon. Kun jokaisen lähtevän . kuittauspaketin viiveaika on kulunut, paketti lähetetään lähtevälle siirtoyhtey- 25 delle.
Jos ACKTi kuvaa sitä ajanhetkeä, jolloin kuittauksen sisältävä paketti siirretään liikenteen haaroittimelta kuittauspuskuriin ja jos ACKTo kuvaa sitä ajanhetkeä, jolloin paketti siirretään kuittauspuskurista siirtoyhteydelle, ACKTo voidaan esittää seuraavasti: . j 30 ACKTo(j) = ACKTi(j) + dj( j=1,2,...
missä j on paketin järjestysnumero ja dj on järjestysnumeron j omaavaan pakettiin liittyvän viiveen arvo.
Kuvio 4b havainnollistaa niitä hetkiä, jolloin paketit lähtevät liikenteen haaroittimesta ja kuittauspuskurista. Oletetaan, että liiallista kuormaa havai-35 taan hetken ACKTo(7) jälkeen (tätä ennen kuittauksia ei ole viivästetty). Jos viiveensäätöyksikön DCU vastaanottama ruuhkasignaali osoittaa, että kuor- 10 104602 mitustaso on ylittänyt ennalta määritetyn arvon, viiveen säätöyksikkö suorittaa algoritmin, joka määrittää, kuinka kauan seuraavaa siirtoyhteydelle siirrettävää pakettia tulisi viivästää. Laskettu arvo voi riippua yhdestä tai useammasta parametristä, kuten sen hetkisestä liikennenopeudesta, sen hetkisestä pusku-5 rien täyttöasteesta tai viiveen edellisestä arvosta (dj.,). Kuten kuviosta 4b havaitaan, viiveen arvo voi vaihdella paketista toiseen.
Kuvio 5 on vuokaavio, joka havainnollistaa esimerkkiä algoritmista, jonka viiveen säätöyksikkö suorittaa jokaiselle paketille, joka luetaan ulos kuittauspuskurista AB.
10 Jos ruuhkaa havaitaan, lasketaan kuittauspuskurista sillä hetkellä ulos luettavan paketin viivearvo dj (eli aika, jonka verran sen hetkistä pakettia viivästetään puskurissa) seuraavalla kaavalla: dj = adH + (1-a)dM (1) missä dj., on edellisen paketin viivearvo, dM on mitattu viivearvo ja a 15 on tasoituskerroin (edullisesti a<0,5<1). Mitattu viive on todellinen viive, joka mitataan siitä hetkestä, jolloin paketti vastaanotetaan kuittauspuskuriin siihen hetkeen, jolloin paketti luetaan ulos kuittauspuskurista. Tämä viive voidaan mitata keskiarvona tietyn ajanjakson yli tai keskiarvona tietystä määrästä paketteja. Viiveensäätöyksikkö voi suorittaa tämän mittauksen.
20 Jos ruuhkaa havaitaan ja jos dj.,=0 ja dM=0, eli jos edellistä pakettia ei viivästetty ja jos tietyn ennalta määrätyn edeltävän ajanjakson aikana kuittaus-puskurissa AB ei ole ollut paketteja, sen hetkisen paketin viivearvo dj saa ennalta määritetyn viiveparametrin dinita| arvon, eli df = djnffia,.
Kun kytkin palautuu ruuhka- tai ylikuormatilanteesta, viiveensäätöyk- ' 9 25 sikkö laskee viivearvon dj kaavalla: dj = adj., - (1-a)dM (2).
Toisen termin tarkoituksena on kaavassa (1) tasaisesti lisätä viivettä, kun ruuhkaa havaitaan, ja kaavassa (2) tasaisesti vähentää viivettä, kun verkko palautuu ruuhkasta.
·: 30 Kuvio 6a esittää kuvion 4a mukaista ratkaisua jaettua puskuria käyt tävässä kytkinarkkitehtuurissa. Kuvion 6a toteutustavassa puskuroidaan kaikki paketit jaetussa puskurissa SB ennen kuin kukin paketti reititetään kytkimen oikeaan lähtöporttiin OP;. Muussa suhteessa kuvion 6a toteutustapa vastaa kuvion 4a toteutustapaa. Liikenteen haaroittimet TS; (i=1...n) voivat myös 35 muodostaa yhden yksikön, joka lukee paketin kerrallaan jaetusta puskurista ja 11 104602 toimittaa paketin oikeaan porttiin. Viiveen säätöyksikkö DCU (ei esitetty kuviossa 6a) voidaan myös toteuttaa kaikille lähtöporteille yhteisenä yksikkönä.
Kuvioiden 4a ja 6a toteutustavoissa kuittauspuskuri sisältää useiden yhteyksien paketteja ja kaikkia paketteja viivästetään saman viivästysalgorit-5 min mukaisesti. Vaihtoehtoisesti paketit voidaan tallettaa kussakin lähtöportis-sa yhteyskohtaisesti, eli kunkin IP-yhteyden (tai TCP-yhteyden) datapaketit voidaan tallettaa erilliseen puskuriin. Näissä tapauksissa jokainen puskuri voi olla FIFO-tyyppinen puskuri, koska yksittäisen jonon paketteja ei tarvitse järjestää uudelleen vaikka eri yhteyksiä viivästettäisiin eri tavalla. Kunkin 10 yhteyden suhteellinen osuus menosuunnan puskurissa voidaan myös määrittää kuormitustason mittauksen avulla ja yhteyksiä voidaan viivästää mitattujen arvojen perusteella. Tällä tavoin voidaan viivästää enemmän niiden yhteyksien kuittauksia, jotka kuormittavat verkkoa voimakkaammin. Kuvio 6b havainnollistaa tätä vaihtoehtoista toteutustapaa, jossa lähtöportissa on puskuriyksikkö 15 BFU, joka sisältää erilliset jonot ainakin joillekin yhteyksistä.
Jos yhteyskohtaisia puskureita ei käytetä ja jos eri yhteyksiä viivästetään eri tavalla, puskurit voivat olla esim. siirtorekisterityyppisiä muisteja, jotka sallivat pakettien uudelleenjärjestelyn siten, että vähemmän kuormittavien yhteyksien paketit voivat ohittaa ylikuormittavien yhteyksien paketteja.
20 Kuten aiemmin mainittiin, keksinnön mukaista ruuhkanvalvontame- netelmää voidaan hyödyntää pakettiverkoissa. Tämä tarkoittaa sitä, että verkossa on käyttäjien päätelaitteita, verkkoliittymäpisteitä, jotka taijoavat liittymän verkkoon, ja kytkimiä.
Käyttäjien päätelaitteet toimivat liikennelähteinä -kohteina eli pisteinä, 25 jotka lähettävät ja vastaanottavat dataa. Kytkimet voivat olla pakettikytkimiä tai ATM-kytkimiä. Liittymäpiste voi olla esim. reititin tai liittymäpiste voi suorittaa pakettien kokoamista/uudelleenkokoamista, reititystä tai kytkentää. Kuittaavien pakettien viivästämistä suoritetaan edullisesti liittymäpisteissä, mutta sitä voidaan suorittaa myös verkossa olevissa kytkimissä, kuten myöhemmin . " 30 kuvataan.
Kuviot 7a ja 7b esittävät keksinnön kahta eri toteutustapaa IP-verkossa. Kuvion 7a toteutustavassa suoritetaan ruuhkan ilmaisu sekä kuittausten viivästäminen liittymäkytkimessä IPS1, joka tarjoaa liittymän IP-verkkoon. Kuvion 7b toteutustavassa ruuhkan ilmaisu suoritetaan liittymäsol-35 mussa, kun sen sijaan kuittausten viivästäminen toteutetaan käyttäjän päätelaitteen UT TCP/IP-protokollapinossa. Ruuhkailmoitukset CS lähetetään käyt- 12 104602 täjän päätelaitteelle, jossa kuittauksia sisältäviä paketteja viivästetään yllä kuvatulla tavalla ennen kuin ne lähetetään TCP-lähteelle.
Kuviot 8a ja 8b esittävät keksinnön kahta eri toteutustapaa ATM-verkon yhteydessä. Kuvion 8a toteutustavassa ruuhkan ilmaisu ja kuittausten 5 viivästäminen suoritetaan liittymäsolmussa AN. Liittymäsolmu voidaan jakaa liitäntäkorttiyksikköön ICU ja ATM-kytkimeen ASW. Liitäntäkorttiyksikkö sisältää ATM-sovituskerroksen (AAL) toiminnot IP-tietosähkeiden pilkkomista ja uudelleenkokoamista varten. Ruuhkaa valvotaan solmun ATM-kytkimen puoleisessa osassa esim. valvomalla niiden puskureiden täyttöasteita, jotka pus-10 kuroivat tilaajalta verkkoon päin menevää liikennettä. Ruuhkailmoitukset siirretään liitäntäkorttiyksikölle, jossa uudelleen koottuja IP-paketteja viivästetään edellä kuvatulla tavalla. Kuvion 8b toteutustavassa ruuhkaa valvotaan kytkimessä ASW, kuittaavia paketteja viivästetään sen sijaan käyttäjän päätelaitteen TCP/IP-protokollapinossa.
15 Kuvioiden 7a ja 8a toteutustavat ovat edullisemmat, koska on paljon taloudellisempaa toteuttaa kuittausten viivästäminen yhdessä liittymäsolmussa kuin useissa päätelaitteissa, jotka sijaitsevat käyttäjien tiloissa. Lisäksi on luonnollisestikin edullisempaa, että käyttäjien päätelaitteita ei tarvitse muuttaa mitenkään otettaessa keksintö käyttöön.
20 Kuten aiemmin mainittiin, yksi yhteysreitillä oleva verkkoelementti voi komentaa toista samalla reitillä olevaa verkkoelementtiä suorittamaan viivästämisen. Kuvio 9 havainnollistaa tätä periaatetta TCP/ATM-verkossa esittämällä kahden päätelaitteen (A ja B) välistä yhteyttä, jolla käytetään TCP:tä kuljetuskerroksen protokollana. Käyttäjän päätelaitteiden liittymäsolmujen 25 (ANS ja AND) lisäksi kuviossa on esitetty vain yksi välissä oleva ATM-solmu (N1) ja solmuja yhdistävät siirtojohdot. Oletetaan, että verkkosolmuissa on kanavia kahteen suuntaan; menosuunnan kanava ja paluusuunnan kanava. Kuvauksen yksinkertaistamiseksi oletamme, että datapaketit lähetetään päätelaitteesta A päätelaitteeseen B liittymäsolmun ANS, yhden tai useamman 30 ATM-kytkimen ja liittymäsolmun AND kautta (menosuunta) ja kuittaukset palautetaan päätelaitteelta B päätelaitteelle A liittymäsolmun AND, yhden tai useamman ATM-kytkimen ja liittymäsolmun ANS kautta (paluusuunta). Kuten edellä mainittiin, liittymäsolmut voidaan jakaa liitäntäkorttiyksikköön ICU ja ATM-kytkimeen ASW. Liitäntäkorttiyksikkö sisältää ATM-sovituskerroksen 35 (AAL) toiminnot IP-tietosähkeiden pilkkomiseksi ja uudelleenmuodostamiseksi. Kuten kuvion 8a esimerkissä, kuittausten viivästäminen suoritetaan liitäntä- „ 104602 I o korttiyksikössä. Tässä tapauksessa ruuhkaa ei kuitenkaan valvota liittymäsol-mun ATM-kytkinosassa, vaan ATM-verkossa kauempana sijaitsevassa ATM-kytkimessä. Kuviossa 9 mainittu ATM-kytkin, joka antaa iiittymäsolmulle käskyt viivästää kuittauksia, on solmu N1.
5 Kuvion 9 mukaisessa verkossa on ABR-vuonohjaus lähettävän ääri- järjestelmän (ANS) ja vastaanottavan äärijärjestelmän (AND) välillä. Mitä tulee RM-soluvirtaan tällä kaksisuuntaisella yhteydellä, kukin päätepiste on sekä lähettävä että vastaanottava äärijäijestelmä. Kuten kuviossa 9 esitetään menosuunnan informaatiovirran osalta liittymäsolmusta ANS liittymäsolmuun 10 AND, valvontasilmukka koostuu kahdesta RM-soluvirrasta, yhdestä me-nosuuntaisesta ja toisesta paluusuuntaisesta. Liittymäsolmu ANS generoi menosuuntaisia RM-soluja, jotka liittymäsolmu AND kääntää ympäri ja jotka lähetetään takaisin Iiittymäsolmulle ANS paluusuunnan RM-soluina. Nämä paluusuunnan RM-solut kuljettavat verkkosolmujen ja/tai liittymäsolmun AND 15 antamaa takaisinkytkentäinformaatiota. ATM-verkossa oleva verkkosolmu, kuten solmu N1, voi: - lisätä takaisinkytkentäinformaatiota suoraan RM-soluihin, kun ne kulkevat solmun kautta meno- tai paluusuunnassa, - informoida lähdettä epäsuorasti ruuhkasta asettamalla EFCI-brtin 20 (Explicit Forward Congestion Indication) niiden datasolujen (käyttäjäsolujen) otsikoissa, jotka kulkevat menosuunnassa. Tässä tapauksessa liittymäsolmu AND päivittää paluusuunnan RM-solut tämän ruuhkainformaation mukaisesti, - generoida paluusuuntaisia RM-soluja.
Näin ollen on ainakin kolme erilaista tapaa ohjata liittymäsolmussa 25 tapahtuvaa kuittausten viivästämistä verkosta päin.
RM-soluissa ruuhkainformaatio voidaan lisätä esim. 45 oktetin pituiseen kenttään “Function Specific Fields” tai sitä seuraavaaan varattu-osaan (Reserved), joka on 6 bitin pituinen. ABR-kykyiselle käyttäjälle RM-soluissa välitettäviä liikenneparametrejä kuvataan ITU-T:n spesifikaation 1.371 kohdas-30 sa 5.5.6.3 ja RM-solun rakennetta saman spesifikaation kohdassa 7.1, joista kiinnostunut lukija voi löytää yksityiskohtaisempaa kuvausta RM-soluista.
EFCI-bitti on puolestaan keskimmäisin bitti ATM-solun otsikon 3-bittisessä PTI-kentässä (Payload Type Indicator).
Keksinnön tämän edullisen toteutustavan mukaisesti vastaava liitty-35 mäsolmu vastaanottaa ruuhkainformaatiota sisältäviä paluusuuntaisia RM-soluja, kun ATM-verkon solmussa havaitaan ylikuormaa tai ruuhkaa. Tämän 14 104602 informaation perusteella liittymäsolmun ATM-kytkinosa säätää lähetysnopeuttaan ATM-verkon suuntaan ja vuonohjausmekanismi viivästää paluusuuntai-sella kanavalla kohti liikennelähdettä kulkevia kuittauksia. Tällä tavoin TCP-lähde alkaa automaattisesti pienentää lähetysnopeuttaan tai ainakaan se ei 5 lisää lähetysnopeuttaan niin nopeasti kuin se muuten tekisi. Kuten aiemmin mainittiin, tämä johtuu siitä, että viive pienentää nopeutta, jolla lähde kasvattaa ruuhkaikkunansa kokoa.
Yllä kuvatulla tavalla voidaan suorittaa päästä päähän ulottuva ABR-vuonohjaus muuttamatta yhteistoiminnassa olevaa TCP-protokollaa. Toisin 10 sanoen, ATM- ja TCP-vuonohjaussilmukat voidaan toteuttaa taloudellisesti edullisella tavalla.
Kuviot 10 ja 11 ovat aikajanoja, jotka havainnollistavat segmenttien vaihtoa TCP-lähteen ja TCP-kohteen välillä. Lähde on esitetty vasemmalla puolella ja kohde oikealla puolella. Lähetys- ja vastaanottotapahtumia on 15 merkitty numeroilla, jotka alkavat kolmosesta.
Kuvio 10 on esimerkki siitä, kuinka lähde ja kohde käyttäytyvät konventionaalisessa verkossa eli verkossa, jossa ei käytetä keksinnön mukaista menetelmää yhteyden paluureitillä. Aluksi lähde on hitaan aloituksen vaiheessa. Olettakaamme, että verkon kuorma kasvaa vähitellen, minkä seurauksena 20 lopulta menetetään verkon ylikuormittuneessa pisteessä paketti P10, joka lähetetään numeron 21 kohdalla. Tämän jälkeen lähde lähettää yhä paketteja, koska sen vastaanottamat kuittaukset ovat järjestyksessä. Numeron 37 kohdalla lähde huomaa viimein, että vastaanotettu kuittausnumero ei ollut oikean järjestyksen mukainen, jolloin se lopettaa lähettämisen.
? 25 Numeron 41 kohdalla ajastin laukeaa ja lähde suorittaa paketin P10 uudelleenlähetyksen. Samalla lähde siirtyy ruuhkanestovaiheeseen.
Kuvio 11 esittää esimerkin tietojen vaihdosta, kun verkko käyttää esillä olevaa keksintöä. Tässä tapauksessa havaitaan ylikuormaa sen jälkeen, kun kohde on lähettänyt seitsemännen kuittauksen (ACK7). Tämän seurauk-,* 30 sena tätä kuittausta ja sitä seuraavia kuittauksia (ACK8...ACK11) viivästetään verkossa.
Kuten kuviosta voidaan havaita, lähde alkaa vähentää lähetysnopeuttaan jo numeron 24 kohdalla jatkaen hitaan aloituksen vaiheessa. Kuten kuvioissa on esitetty, perinteinen verkko käyttäytyy epätasaisemmin; ensin 35 lähde lähettää paljon paketteja ja kun ruuhkaa havaitaan, paketteja ei lähetetä lainkaan. Keksintöä käyttävä verkko käyttäytyy sen sijaan paljon vakaammin, 15 104602 koska kuittausten viivästäminen estää lähdettä kasvattamasta ruuhkaik-kunaansa yhtä nopeasti kuin tunnetussa verkossa. Tämän ansiosta voidaan liittymäverkon puskurointikapasiteettia pienentää.
Vaikka keksintöä on edellä kuvattu viitaten oheisten kuvioiden mukai-5 siin esimerkkeihin, on selvää, että keksintö ei ole rajoittunut niihin, vaan sitä voidaan muunnella monin tavoin oheisten patenttivaatimusten puitteissa. Seuraavassa kuvataan lyhyesti joitakin muuntelumahdollisuuksia.
Kuten edellä esitettiin, käyttäjän päätelaitteelle asetettava edellytys on, että se kuittaa oikein vastaanotetut (virheettömät) tietoyksiköt. Tämän takia 10 ajatusta voidaan periaatteessa käyttää minkä tahansa muun protokollan yhteydessä, joka lähettää kuittauksia ja vähentää lähetysnopeuttaan, jos kuittaukset viivästyvät. Kaava, jota käytetään viiveen absoluuttisen arvon laskemiseen voi myös vaihdella monin tavoin. Mittausyksikkö voi informoida kuormitustasosta monin tavoin; ON/OFF-tyyppisenä informaationa tai mitatun kuor-15 man arvon osoittamiseen voidaan käyttää useampaa kuin yhtä bittiä. Signaali (CS), joka informoi kuormitustasosta voi myös sisältää informaatiota niistä yhteyksistä, joita kuittausten viivästäminen koskee. Käyttäjien päätelaitteilla voi olla myös langaton liittymä verkkoon.
«
• I

Claims (15)

104602
1. Menetelmä ylikuormituksen valvomiseksi pakettivälitteisessä verkossa, joka käsittää liikennelähteitä (A), liikennekohteita (B) ja verkkosolmuja (AN, N1), jonka menetelmän mukaisesti 5. lähetetään tietoyksikköjä liikennelähteestä liikennekohteeseen, - lähetetään kuittaus kohteesta lähteelle, jos tietoyksikkö vastaanotetaan oikein kohteessa, ja - mitataan kuormitustasoa verkon ainakin yhdessä solmussa, tunnettu siitä, että 10 lähdettä kohti kulkevia kuittauksia viivästetään, mikäli mitattu kuormi tustaso ylittää ennalta määrätyn arvon.
2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että kuittauksia viivästetään verkon samassa solmussa, jossa kuormitustasoa mitataan.
3. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että kuittauksia viivästetään verkon eri solmussa kuin se, jossa kuormitustasoa mitataan.
4. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, että kuittauksia viivästetään liittymäsolmussa (AN, ANS, AND), joka tarjoaa 20 liikennelähteille ja -kohteille pääsyn verkkoon, ja kuormitustasoa mitataan ainakin yhdessä verkon keskellä sijaitsevassa solmussa (N1).
5. Patenttivaatimuksen 4 mukainen menetelmä, jossa liittymäsolmu-jen välinen verkko on ATM-verkko, tunnettu siitä, että - kuormitustasotietoa kuljetetaan liittymäsolmulle RM-soluissa, ja 25. kuittauksia viivästetään RM-solujen sisältämän informaation perus teella.
6. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että kuittauksia viivästetään verkon ainakin yhdessä solmussa siten, että - talletetaan ainakin osa solmun läpi ensimmäisessä suunnassa ·:* 30 kulkevista datapaketeista ensimmäiseen puskuriin, - luetaan datapaketit ulos ensimmäisestä puskurista siten, että (a) paketit, jotka sisältävät kuittauksen siirretään toiseen puskuriin, ja (b) paketit, joissa ei ole kuittausta siirretään suoraan lähtevälle siirtoyhteydelle (OL), - määritetään jokaiselle toisessa puskurissa olevalle paketille viivear- 35 vo, ja • · 17 104602 - luetaan toisesta puskurista paketti lähtevälle siirtoyhteydelle (OL), kun mainitulle paketille määritetty viive on kulunut.
7. Patenttivaatimuksen 6 mukainen menetelmä, tunnettu siitä, että ensimmäisiä ja toisia puskureita käytetään ensimmäisen suunnan jokai- 5 sessa lähtöportissa.
8. Patenttivaatimuksen 6 mukainen menetelmä, tunnettu siitä, että viivearvo määritetään käyttäen samaa määrityssääntöä kaikille toisessa puskurissa oleville paketeille.
9. Patenttivaatimuksen 8 mukainen menetelmä, tunnettu siitä, 10 että paketin viivearvo määritetään edeltävän paketin viivearvon ja tietyn edeltävän jakson yli mitatun viivearvon perusteella.
10. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että vain valituille yhteyksille kuuluvia kuittauksia viivästetään, jos mitattu kuormitustaso ylittää ennalta määrätyn arvon.
11. Pakettivälitteinen tietoliikenneverkko, joka käsittää - solmuja, jotka on kytketty toisiinsa siirtoyhteyksillä (TL1, TL2), - käyttäjien päätelaitteita (UT), jotka on kytketty solmuihin, jotka päätelaitteet toimivat liikennelähteinä, jotka lähettävät datapaketteja ja liikenne-kohteina, jotka vastaanottavat datapaketteja, ja 20. mittauselimet (LMU) vallitsevan kuormitustason mittaamiseksi sol mussa, tunnettu siitä, että verkko käsittää lisäksi - viivästyselimet (AB, DCU), jotka on toiminnallisesti kytketty mittaus-elimille (LCU) sellaisten datapakettien viivästämiseksi, jotka kuljettavat koh- 25 teestä lähteelle meneviä kuittauksia.
12. Patenttivaatimuksen 11 mukainen verkko, tunnettu siitä, että verkon yksi solmu käsittää sekä mittauselimet että viivästyselimet.
13. Patenttivaatimuksen 12 mukainen verkko, tunnettu siitä, että ainakin yksi solmu on liittymäsolmu, joka yhdistää ainakin yhden käyttäjäpää- . : 30 telaitteen verkkoon.
14. Patenttivaatimuksen 12 mukainen IP-verkko, jossa verkon solmut välittävät IP-paketteja, tunnettu siitä, että mainittu ainakin yksi solmu voi olla mikä tahansa yksi tai useampi verkkosolmu.
15. Patenttivaatimuksen 11 mukainen TCP/ATM-verkko, tunnettu 35 siitä, että viivästyselimet on kytketty mittauselimille RM-soluvirran avulla, jotka ... RM-solut kuljettavat kuormitustasoinformaatiota. 104602
FI973746A 1997-07-14 1997-09-22 Vuonohjaus tietoliikenneverkossa FI104602B (fi)

Priority Applications (7)

Application Number Priority Date Filing Date Title
FI973746A FI104602B (fi) 1997-07-14 1997-09-22 Vuonohjaus tietoliikenneverkossa
PCT/FI1998/000591 WO1999004536A2 (en) 1997-07-14 1998-07-14 Flow control in a telecommunications network
EP98935050A EP0997020A2 (en) 1997-07-14 1998-07-14 Flow control in a telecommunications network
CN98808150.4A CN1267419A (zh) 1997-07-14 1998-07-14 电信网中的信息流控制
JP2000503633A JP2001510957A (ja) 1997-07-14 1998-07-14 テレコミュニケーションネットワークの流れ制御
AU84434/98A AU745204B2 (en) 1997-07-14 1998-07-14 Flow control in a telecommunications network
NO20000171A NO20000171L (no) 1997-07-14 2000-01-13 Flytkontroll i et telekommunikasjonsnettverk

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FI972981A FI972981A7 (fi) 1997-07-14 1997-07-14 Vuonohjaus tietoliikenneverkossa
FI973746A FI104602B (fi) 1997-07-14 1997-09-22 Vuonohjaus tietoliikenneverkossa
FI973746 1998-04-09
FI972981 1998-04-09

Publications (3)

Publication Number Publication Date
FI973746A0 FI973746A0 (fi) 1997-09-22
FI973746L FI973746L (fi) 1999-01-15
FI104602B true FI104602B (fi) 2000-02-29

Family

ID=26160424

Family Applications (1)

Application Number Title Priority Date Filing Date
FI973746A FI104602B (fi) 1997-07-14 1997-09-22 Vuonohjaus tietoliikenneverkossa

Country Status (1)

Country Link
FI (1) FI104602B (fi)

Also Published As

Publication number Publication date
FI973746L (fi) 1999-01-15
FI973746A0 (fi) 1997-09-22

Similar Documents

Publication Publication Date Title
US6882624B1 (en) Congestion and overload control in a packet switched network
AU745204B2 (en) Flow control in a telecommunications network
US4769810A (en) Packet switching system arranged for congestion control through bandwidth management
JP4436981B2 (ja) ハイブリッドip−atmネットワーク内で混雑状態を管理するためのecnベースの方法
CA1279392C (en) Packet switching system arranged for congestion control
US5787071A (en) Hop-by-hop flow control in an ATM network
AU703410B2 (en) Traffic management and congestion control for ATM
US6490251B2 (en) Method and apparatus for communicating congestion information among different protocol layers between networks
EP0920235A2 (en) Congestion management in a multi-port shared memory switch
US6587437B1 (en) ER information acceleration in ABR traffic
US20050147032A1 (en) Apportionment of traffic management functions between devices in packet-based communication networks
US5978357A (en) Phantom flow control method and apparatus with improved stability
US7218608B1 (en) Random early detection algorithm using an indicator bit to detect congestion in a computer network
FI104602B (fi) Vuonohjaus tietoliikenneverkossa
EP1068766B1 (en) Congestion control in a telecommunications network
WO1999053655A2 (en) Congestion control in a telecommunications network
EP1381192A1 (en) Improved phantom flow control method and apparatus
JP3097549B2 (ja) Atmスイッチ
Shionozaki et al. Integrating resource reservation with rate-based transport protocols in AMInet
Iliadis Performance of TCP traffic and ATM feedback congestion control mechanisms
Ren et al. Performance of TCP in IP/ATM internetworks
KR100198443B1 (ko) Atm망에서 비연결형 데이터 서비스를 위한 폭주 제어방법
WO1998043395A9 (en) Improved phantom flow control method and apparatus
Zervanos et al. Design and implementation of an ABR server in a shared-bus ATM switch
Rogers et al. Matching differentiated services PHBs to ATM service categories-the AF to VBR case