NO325923B1 - ATM-nettverk - Google Patents

Description

Foreliggende oppfinnelse vedrører ATM-nettverk, spesielt IPATM-nettverk tilpasset til å frembringe multipunkt-til-multipunkt multi-casting og en fremgangsmåte vedrørende multipunkt-til-multipunkt multi-casting i et IPATM-nettverk, så som nærmere definert i ingressene av de uavhengige kravene 1 og 18.

En av hovedkarakteristikkene til multi-casting i internett er at, se S.E. Deering, " Multi- cast Routing in Internetworks and Extended LANs," in Proe. ACM SIGCOMM '88, August 1988, dens innebyggede multipunkt-til-multipunkt (mpt-til-mpt). Imidlertid støtter ikke ATM direkte mpt-til-mpt. Dette betyr at hvis ATM skal anvendes som en underliggende teknologi for transport av IP multi-cast pakker, er effektiv støtte for mpt-til-mpt kommunikasjon en nødvendighet. Dette kan oppnås på de følgende måter: (1) sette opp en virtuell krets mellom hver sender og mottaker; (2) sette opp N punkt-til-multipunktforbindelser; eller (3) alternativt, ved å frembringe mpt-til-mpt forbindelser på ATM-nivået, som foreslått ved

.foreliggende forbindelse.

Opsjon (1) er ikke akseptabel pga. at den krever 0 (n2)forbindelser (VCer).

Opsjon (2) er mye bedre enn opsjon (1) pga. at den reduserer antallet VCer til 0(n). Imidlertid krever den en komplisert overlagsstruktur for å løse og overvåke IP gruppeadresser og deres korresponderende ATM-adresser.

Med opsjon (3) anvendes kun en VC pr. gruppe og der er ikke noe behov for et lagringssted for adresser. For detaljer vedrørende ulemper som finnes i nåværende løsninger for multi-casting i IPATM-nettverk, se:

L. Moy, " Multi- cast Extensions to OSPF",

in Request For Comments 1584, March 1994;

G.J. Armitage, " Multi- cast and Multiprotocol Support for ATM based Internets", ACM Sigcomm Computer Communication Rev., vol. 25, April 1995;

T. Ballardie, " Core Based Tree", SIGCOMM '93,

pg. 85-95; og

D. Estrin, D. Farinacci, A. Helmy, V. Jacobson and L. Wet " Protocol Independent Multi- cast-Dense Mode" (PIM-DM): Proposed experimental RFC, Sept. 1996.

Ulempene med nåværende løsninger for multi-casting i IPATM systemer kan sammenfattes som følger: For kilderutet pt-til-mpt konfigurasjoner (VC nett);

0(n<2>) forbindelser er nødvendig, som ikke

skalerer for store nettverk;

sendere må være klar over alle mulige mottakere slik at de kan slutte seg til gruppen som inklu-derer mottakerne;

mottakerne må være klar over nåværende sendere;

en betydelig tidsperiode er nødvendig for å spre endringer når sendere, eller mottakere, slutter seg til eller forlater en gruppe;

det er vanskelig å opprettholde sammenhengende og

bestående gruppeadresser til medlemskapslister; og

der er høye signallaster for å slutte seg til

eller forlate en gruppe.

For serverbaserte modeller:

antallet VCer reduseres på bekostning av økte

forsinkelser;

der er et enkelt feilpunkt;

trafikk er konsentrert;

problemer vedrørende pakkerefleksjon oppstår; og det er vanskelig å opprettholde sammenhengende

og vedvarende gruppeadresser for medlemskapslister.

I Sridhar Komandur et al.: "SPAM: A data forwarding modell for multipoint-to-mulitpoint connection support in ATM networks" COMPUTER COMMUNICATION AND NETWORKS, 1997, sider 383-388, omtales det en datavidereføringsmodell for multipunkt-til-multipunkt-forbindelse i et ATM-nettverk.

Mohammed Arozullah et al.: "A scalable multicast routing algorithm for IP-ATM-IP networks", IEEE, MILCOM 96 CONFERENCE PROCEDDINGS, Vol. 2, Oktober 1996, sider 478-482, beskriver en algoritme for skalerbar multi-cast ruting for et IP-ATM-IP nettverk.

EP 0 800 329 viser til et system samt en metode for hierarkisk multi-cast ruting i et ATM-nettverk.

SSAM (enkel og skalerbar IPATM Multicast) nettverks-strukturen som foreslås for foreliggende oppfinnelse, anvender et enkelt delt tre for alle sendere og mottakere. Treet har roten i en kjerne. Forespørsler for å slutte seg til fra mottakere og sendere spres mot kjernen. En nettverkstjeneste, MNS (multi-cast nettverkstjenester) frembringer ATM-adressen til kjernen, gitt en IP multi-cast adresse. Andre viktige trekk med denne mekanismen, er at den frembringer en løsning for VC-innfellings-problemer.

I en ATM svitsj, når multiple innkommende VCer på ulike svitsjporter må rutes til en enkelt utgående VC, er der en potensiell konflikt som leder til pakkekonflikt som igjen kan resultere i pakkekorrupsjon. Algoritmen som anvendes av foreliggende oppfinnelse gjør at en ATM svitsj oppfører seg som en lagre- og formidlerenhet, dvs. en AAL5 formidler, eller en IP ruter, ved tilstedeværelse av konflikt, og en cellesvitsj ved fravær av konflikt.

I multi-cast ruterprotokoller som anvender kjernebaserte trær (CBT), f.eks. PIM (Protocol Independent Multi-casting-Sparse Mode), er spredning av plassering av kjernen til hver multi-cast ruter, et uløst problem. Eksisterende løsninger er verken tilstrekkelig skalerbare eller tilstrekkelig fleksible.

Foreliggende oppfinnelse anvender en ny multipunkt-til-multipunkt multi-cast struktur i et IPATM-nettverk. Mekanismen ifølge foreliggende oppfinnelse er betydelig enklere og skalerer bedre enn eksisterende løsninger pga. den ikke trenger en adresseresolusjonsstruktur og at den krever betydelig færre ressurser uttrykt ved virtuelle kretser (VC), CPU kraft og minnelager.

Hovedkarakteristikkene til SSAM ifølge foreliggende oppfinnelse, er at både sender og mottaker ligger på samme leveringstre og kun en VC anvendes for å sende data over det treet. Leveringstreet er et spredetre og pakkene blir duplisert kun på grenene når de trengs. Dette oppnås ved en algoritme hvori svitsjene overvåker grenene til treet hvor det er gruppemedlemmer. Innfellingen av ATM-celler motvirkes av en VC flettemekanisme. En kjerneutvalgs-mekanisme er frembrakt som optimaliserer formen til trestrukturen.

Ifølge et første aspekt ved foreliggende oppfinnelse er det frembrakt et Internet Protokoll Asynchronous Transfer Mode, IPATM, overføringsnettverk omfattende et antall noder og et antall sluttpunkter tilpasset til å virke som datasendere, eller mottakere, hvor nodene og sluttpunktene er forbundet ved Asynchronous Transfer Mode, ATM, og hvor IPATM overføringsnettverket er tilpasset til å støtte multipunkt-til-multipunkt multi-casting mellom en gruppe sluttpunkter, og en gruppe omfattende medlemmer nært lokalisert til hverandre, anvender en multi-cast gruppeadresse, hvori minst en sender og alle mottakere, som tilhører en multi-cast gruppe av sluttpunkter, er lokalisert på et enkelt spredeleverings-tre, og at kun en Virtual Circuit, VC, anvendes for å overføre data over det enkle spredeleveringstreet, som er kjennetegnet ved at en Multi-cast Network Service, MNS, er anordnet for å holde nevnte multi-cast gruppeadresse og ved at en vert er anordnet for å forespørre sin lokale

MNS-serverfor en ny multi-cast gruppeadresse,

nevnte lokale MNS-serveren er tilpasset til å

forsyne en multi-cast adresse fra sine egne adresser, eller

hvis nevnte lokale MNS-serveren ikke har noen ubrukte adresser, den nevnte lokale MNS er tilpasset til å forsyne en adresse for en nærmest lokalisert annen MNS-server, ved at det enkle spredeleveringstreet er en Core Based Tree, CBT, med rot i en kjernenode, og ved at relokaliseringsmidler er frembrakt for relokalisering av kjernen.

Nevnte CBT kan være bygget på ATM nivået.

IPATM overføringsnettverket kan være tilpasset til å ha mer enn en aktiv kjerne, hvor kjernene er geografisk adskilt fra hverandre.

Det kan frembringes formidlingsmidler tilpasset til å formidle trafikk kun til de grenene av det enkle sprede-leveringstreet hvor trafikken er nødvendig.

Formidlingsmidlene kan være tilpasset til å bli operert uavhengig av kjernelokalisering.

IPATM overføringsnettverket kan omfatte MNS midler tilpasset til å frembringe en ATM-adresse for kjernen, ved mottak av en IP multi-cast adresse.

MNS midlene kan være tilpasset til å frembringe kjernepunktsstyring og multi-cast gruppestyring.

MNS midlene kan omfatte et hierarki av MNS-servere.

IPATM overføringsnettverket kan ha kun en MNS-server, og den kun ene MNS-serveren kan være ansvarlig for alle multi-cast gruppeadresser.

MNS midlene kan omfatte grenserutere tilpasset til å omforme mellom protokoller for dermed å muliggjøre at MNS midlene kan sameksistere ved andre multi-cast protokoller.

Midlene kan være innrettet til å tillate greninitiert tilslutning.

Midlene kan være innrettet til å lette at et sluttpunkt svitsjer fra å virke som en sender, til å virke som en mottaker.

Midlene kan være innrettet til å lette at et sluttpunkt svitsjer fra å virke som en mottaker, til å virke som en sender.

Midlene kan være innrettet til å muliggjøre at et nytt medlem slutter seg til en gruppe, hvor midlene er tilpasset til å forårsake at en tilslutningsmelding spres mot gruppens kjerne.

Multipunkt-til-multipunkt forbindelser kan frembringes på ATM nivået.

ATM svitsjer i IPATM overføringsnettverket kan være tilpasset til å virke som oppbevaring og formidlingsenheter ved konflikter, og som cellesvitsjer ved fravær av konflikter.

VC flettemidler kan frembringes for å motvirke innfelling av ATM-celler, og kjerneutvalgsmidler kan frembringes for å optimalisere formen til et spredeleveringstre sin struktur.

Ifølge et andre aspekt med foreliggende oppfinnelse er det frembrakt en fremgangsmåte for multipunkt-til-multipunkt multi-casting for anvendelse i et Internet Protocol Asynchronus Transfer Mode, IPATM, overførings-nettverk omfattende et antall noder, og et antall sluttpunkter tilpasset til å virke som datasendere, eller mottakere, hvor nodene og sluttpunktene er forbundet ved Asynchronus Transfer Mode, ATM, hvor fremgangsmåten omfatter å bygge et enkelt spredeleveringstre mellom minst en sender og alle mottakerne, som tilhører en multi-cast gruppe av sluttpunkter, og ved å anvende kun en Virtual Circuit, VC, for å overføre data over det enkle spredeleveringstreet, og omfattende en Multi-cast Network Service, MNS, som er kjennetegnet ved at nevnte MNS frembringer en ATM-adresse for kjernen når gitt en multi-cast IP adresse;

å konfigurere en vert som ønsker å anvende

MNS med en ATM-adresse for en lokal MNS-server;

verten, når den ønsker å bli et medlem

av en multi-cast gruppe, overfører en fore-spørsel til en lokal MNS-server for en adresse for kjernen til multi-cast gruppen;

den lokale MNS-serveren, hvis den er ansvarlig for gruppen, svarer med en ATM-adresse for kjernen;

hvis den lokale MNS ikke er ansvarlig for gruppen, å sende videre forespørselen mellom MNS-serverne, i et MNS hierarki, inntil den når en MNS-server som er ansvarlig for nevnte gruppe og hvor den ansvarlige MNS-serveren svarer den forespørrende verten;

MNS hierarkiet starter med en rot MNS-server som vet, til det neste nivået, hvilken server som er ansvarlig for hvilke intervaller av multi-cast adresseområdet;

andre nivås MNS-servere som vet hvordan et adresseområde som de er ansvarlige for,

er oppdelt i mindre adresseintervaller og hvilke tredje nivås MNS-servere som er ansvarlige for hvilke adresseintervaller; og

å sende forespørsler gjennom MNS-server hierarkiet, inntil MNS-serveren, som oppbevarer

tabellene for gruppene den er ansvarlig for, nås.

Det enkle sprede-leveringstreet kan være en Core Based Tree, CBT, rotfestet i en kjernenode.

Kjernen kan relokaliseres for å optimalisere spredeleveringstreets struktur.

Trafikk kan formidles kun til de grenene av det enkle spredeleveringstreet hvor trafikken er nødvendig.

Tilslutningsmeldinger, fra mottakere og sendere, kan spres mot kjernen.

Pakker kan dupliseres kun på grener av sprede-leveringstreet hvor de er nødvendige.

MNS-server kan starte med en tom tabell, innføringer kan dannes dynamisk deri.

Forespørselsforsendelser kan realiseres på to ulike måter, nemlig: hvis MNS-server ikke er ansvarlig for en gruppe,

videreformidle en forespørsel til en rot MNS server, som formidler den videre, eller

formidle en forespørsel kun ett nivå opp i MNS

hierarkiet, og ikke direkte til rot MNS-server.

Kjernenoden for en multi-cast gruppe kan registreres med MNS-serveren ansvarlig for gruppen og, hvis en forespørsel kommer frem til en MNS-server om en gruppe og ingen kjerne er spesifisert for den gruppen, ved å velge svitsjen som sendte forespørselen som kjernen, og ved at svitsjen er i stand til å avslå nominasjonen som kjernen og, hvis svitsjen ikke aksepterer nominasjonen som kjernen, ved å ikke etablere et spredeleveringstre.

En gruppe som har medlemmer nært lokalisert hverandre, kan anvende en multi-cast gruppeadresse som oppbevares av en MNS-server lokalisert nært til gruppemedlemmene, og en MNS-server lokalisert nært tir gruppemedlemmene kan velges ved hjelp av de følgende trinnene:

en vert forespør sin lokale MNS-server for en

ny multi-cast gruppeadresse,

den lokale MNS-serveren blir deretter ansvarlig for å forsyne en multi-cast adresse fra sine egne adresser, eller

hvis den lokale MNS-serveren ikke har noen ubrukte adresser, forsyner den lokale MNS

en adresse til den nærmest lokaliserte andre MNS-server til den lokale MNS-serveren.

Det kan forårsakes at en tilslutningsmelding spres mot gruppens kjerne når et nytt medlem indikerer et ønske om å tilslutte seg en gruppe.

En forlatemelding kan overføres over spredeleveringstreet forbundet med gruppen mot gruppens kjerne når et medlem av gruppen indikerer et ønske om å forlate gruppen, ved at forlatemeldingen kan forflyttes inntil den når et første knutepunkt til spredeleveringstreet, og ved at den delen av spredeleveringstreet over hvor meldingen har forflyttet seg, kan fjernes.

Gruppemedlemmene kan periodevis sende en "jeg er i live" melding til nabonoder, eller sluttpunkter.

Det beskrives også et telekommunikasjonssystem, som omfatter et IPATM overføringsnettverk i samsvar med ett av de foregående avsnittene, eller opererer som en fremgangsmåte i samsvar med ett av de foregående avsnittene.

Utførelser av oppfinnelsen skal nå beskrives, som eksempel, med henvisning til de vedlagte tegningene, hvori: Fig. 1 viser en optimal kjerneplassering i et IPATM-nettverk ifølge foreliggende oppfinnelse. Fig. 2 viser en uriktig plassert kjerne i et IPATM-nettverk ifølge foreliggende oppfinnelse. Fig. 3 viser et IPATM-nettverk, ifølge foreliggende oppfinnelse, omfattende et antall kjerner. Fig. 4 viser et optimalt dataformidlingsopplegg i et ATM nettverk ifølge foreliggende oppfinnelse. Fig. 5 viser tilstandsinformasjon lagret i et IPATM-nettverkstre. Fig. 6 viser prosessen ved et nettverks sluttpunkt som konverterer fra datasender til datamottaker. Fig. 7 viser prosessen til et nettverkssluttpunkt som konverterer fra datamottaker til datasender. Fig. 8 illustrerer prosessen ved å legge til en ny gren til et IPATM-nettverkstre. Fig. 9 viser prosessen med å fjerne en gren fra et IPATM-nettverkstre.

Fig. 10 viser prosessen med VC fletting.

For å lette forståelsen av denne patentbeskrivelsen, er en ordliste for noen av forkortelsene som anvendes heri, vist nedenfor:

AAL5: ATM Adaption Layer 5

ATM: Asynchronous Transfer Mode

CBT: Core Based Tree

CPU: Central Processor Unit

DNS: Domain Name Service

DVMRP: Distance Vector Multi-cast Routing Protocol EOP: End of Packet

IP: Internet Protocol

IPATM: Internet Protocol Asynchronous Transfer Mode MNS: Multi-cast Network Service

PIM: Protocol Independent Multi-casting

Sparse Mode

SAAM: Simple and Scalable IPATM Multi-cast

VC: Virtual Circuit

Som tidligere omtalt i multi-cast ruterprotokoller som anvender kjernebaserte trær (CBT), f.eks. PIM (Protocol Independent Multi-casting Sparse Mode), er spredning av lokaliseringen til kjernen til hver multi-cast ruter et stort uløst problem. Eksisterende løsninger er ikke tilstrekkelig skalerbare, eller fleksible.

Et forslag til en protokoll, som er konstruert for å distribuere adressene til kjernen for en gitt multi-cast gruppe, skal nå beskrives. Denne protokollen er konstruert til å samvirke med SAAM, men kan anvendes i andre protokoller ved anvendelse av paradigmen for det kjernebaserte treet. Dens hovedfunksjon er kjernepunktsstyring, men den kan anvendes for multi-cast gruppestyring så vel. Den kan enkelt utvides til å svare på spørsmål så som »gi meg en ubrukt IP multi-cast adresse». Navnet til den foreslåtte protokollen, er Multi-cast Nettverkstjenester, eller MNS.

MNS kan betraktes til å være analog til en multi-cast forlengelse av den velkjente domenenavntjenesten (MNS). Et hierarki av multi-cast navntjenesteservere (MNS-servere) kan gjøres ansvarlig for å løse problemene som henvist til ovenfor. Akkurat som ved MNS, virker MNS-serverne ved å formidle forespørsler mellom hverandre. Ulikt MNS er imidlertid dette systemet dynamisk.

Måten hvori MNS drives, skal nå beskrives. For det første, hver vert som ønsker å anvende tjenestene til MNS, må konfigureres med ATM-adressen til den lokale MNS-server. Når denne verten ønsker å bli et medlem av en multi-cast gruppe, forespørres den lokale MNS server for adressen for kjernen til den gruppen. Hvis den lokale MNS er ansvarlig for den bestemte gruppeadressen (i IPv4 er det en klasse D adresse), deretter svarer den med ATM-adressen til kjernen. Hvis den lokale MNS ikke er ansvarlig for den bestemte gruppeadressen, blir forespørselen formidlet mellom MNS-serverne inntil den når den serveren som er ansvarlig for gruppen, og deretter vil denne serveren besvare den fore-spørrende verten. MNS hierarkiet starter med en rot MNS-server som vet, til neste nivå, hvilken server som er ansvarlig for hvilke intervaller til multi-cast (klasse D) adresseområder. Tilsvarende vil andre nivås servere vite hvordan området, hvortil de er ansvarlige, er oppdelt i mindre intervaller og hvilke tredje nivås servere som er ansvarlige for hvilket intervall. Dette hierarkiet repeteres inntil serveren som oppbevarer tabellene for gruppene den er ansvarlig for, nås.

For feiltoleranse og ytelsesgrunner, krever et større nettverk et antall MNS-servere for å være ansvarlig for det samme området av adresser. I dette tilfellet må også serversynkronisering håndteres. Hver MNS-server starter med en tom tabell, og innføringer dannes dynamisk. Dette gjør det mulig å ha et lite nettverk med kun en MNS-server, som da er ansvarlig for alle multi-cast gruppeadresser.

Forespørselsformidling utføres på to ulike måter, nemlig: hvis en MNS-server ikke er ansvarlig for en gruppe, blir forespørselen formidlet til rot MNS server, som formidler den videre;

forespørselen formidles kun ett nivå opp

hierarkiet, og ikke direkte til rot.

Begge løsningene har deres fordeler og ulemper. Hvis den ansvarlige MNS-serveren for den forespurte gruppen og

MNS-serveren som mottar forespørselen, er på ulike grener til MNS hierarkiet, er da den førstnevnte fremgangsmåten bedre. På den andre side, hvis den ansvarlige serveren og den forespurte serveren er nært hverandre i hierarkiet,

gir da den sistnevnte fremgangsmåten det beste resultatet. Hvis svaret til forespørslene som ankommer ved en MNS server er likt fordelt mellom alle MNS serverne, gir da den første algoritmen en hurtigere responstid, men den algoritmen frembringer en tyngre last på rotserveren, siden hver forespørsel som ikke svares av serveren som først ble spurt, må gå gjennom rotserveren eller en av rotserverne.

Som en første tilnærming, en MNS innføring lagrer multi-cast gruppeadressene som nøkkel og ATM-adressen til den korresponderende kjernen, hvis den har en. Hvis der ikke er noen kjerne, betyr det at intet tre er blitt etablert for den bestemte multi-cast gruppen. Andre felt kan også inkluderes, f.eks. en referanse for å identifisere brukerne av gruppeadressen. Filen kan inneholde adressen til opphavet, eller en tjenestenavnestreng, eller lignende.

Kjernepunktet for en multi-cast gruppe må registreres med MNS-serveren ansvarlig for den gruppen. Som en første tilnærming, hvis en forespørsel mottas med en MNS-server om en gruppe og ingen kjerne er spesifisert for den gruppen, vil svitsjen som sendte forespørselen bli valgt som kjerne. Denne svitsjen kan, eller trenger ikke, akseptere nominasjonen som kjerne. I det sistnevnte tilfellet vil treet ikke settes opp og ingen kommunikasjon vil være tilgjengelig inntil en svitsj har akseptert kjernerollen. Det er kjernen som er ansvarlig for å ødelegge treet når det ikke lenger anvendes. Detaljene vedrørende bestemmelsesprosessen relatert til ødeleggelse av et tre, er utenfor omfanget av foreliggende oppfinnelse og vil ikke bli beskrevet i denne beskrivelsen. Etter ødeleggelse av treet, sender kjernen en notifikasjon vedrørende tre-ødeleggelsen til den ansvarlige MNS-serveren slik at den kan slette den korresponderende innføringen fra sin tabell.

Siden MNS-serverne vil være spredt rundt om i verden, er det berettiget for en gruppe, som har medlemmer nært lokalisert hverandre, å anvende en multi-cast gruppeadresse som oppbevares av en MNS-server lokalisert nært til den. Det er lett å oppnå dette med den følgende algoritme;

når en vert trenger en ny multi-cast gruppeadresse, spør den sin lokale MNS-server for den;

MNS-serveren er deretter ansvarlig for å frembringe en multi-cast adresse fra sine egne adresser; eller hvis MNS-serveren ikke har noen ubrukte adresser;

frembringer MNS-serveren en adresse for den

nærmeste MNS-server.

MNS systemet må være i stand til å eksistere sammen med andre multi-cast protokoller, f.eks. Ethernet, eller Token-ring baserte systemer, så som DVMRP (Distance Vector Multi-cast Routing Protocol), eller PIM (Protocol Independent Multi-casting). Sameksistens kan oppnås ved å anvende grenserutere som har begge protokollene og som kan omforme mellom dem. De vanlige problemene, så som sløyfer, som kan oppstå ettersom MNS-dekket kortslutter to grener av et DVMRP tre, kan løses så vel. Detaljene vedrørende tilkoblingsspørsmålene er utenfor rammene av foreliggende oppfinnelse og vil ikke bli beskrevet i denne patentbeskrivelsen. MNS er ment å være et globalt system, og vil selvfølgelig ikke, umiddelbart etter realisering, umiddelbart spres rundt i verden. I den første fasen er det forventet at separate MNS undernettverk vil bli sammenkoblet ved konvensjonelle multi-cast ruterprotokoller. I dette tilfellet vil hvert MNS undernettverk ha sitt eget serverhierarki. Hvis to MNS undernettverk sammensmeltes, må følgelig serverhierarkiet bli rekonfigurert.

En liste av MNS meldinger er vist nedenfor.

(1) Query <Multi-cast address>: Sendt fra en svitsj til dens lokale MNS-server. Adressen til kjernen for den gitte multi-cast adressen er nødvendig. Svitsjen vil ikke akseptere nominasjonen som kjerne for gruppen

hvis en kjerne ikke eksisterer.

(2) QueryAssign <Multi-cast address>: Sendt fra en svitsj til dens lokale MNS-server. Adressen til kjernen på den gitte multi-cast adressen er forespurt. Svitsjen vil ikke akseptere nominasjon som kjernen for gruppen

hvis en kjerne ikke allerede eksisterer.

(3) NegResp <Multi-cast address>: Negativ respons. Sendt fra MNS-serveren til den forespørrende svitsjen. Forespørselen ble mottatt, men kjernen for den spesifiserte gruppen ble ikke funnet. (4) Resp <Multi-cast address ATM address of the core>: Positiv respons. Sendt fra MNS-serveren til den forespørrende svitsjen, inneholder ATM-adressen til kjernen. Kjernen for den spesifiserte gruppen ble funnet, eller den ble ikke funnet, men QueryAssign ble sendt. I det sistnevnte tilfellet vil den forespørrende svitsjen bli tildelt rollen som kjerne,

slik at dens ATM-adresse rommes i meldingen.

(5) MNSResp <Multi-cast address, NetMask, MNS-servers ATM address>: Sendt fra en MNS-server til den forespørrende svitsjen. Indikerer hvilken MNS-server som er ansvarlig for multi-cast gruppene, spesifisert

av multi-cast adressen og nettmasken.

(7) CoreDel <Multi-cast address>: Sendt av kjernen til MNS-serveren ansvarlig for multi-cast adressen, muligens den lokale MNS-server. Foreslår sletting av

den spesifiserte multi-cast gruppen fra databasen.

(8) ReqNew <>: Sendt av en svitsj til dens lokale MNS server. Forespør en ubrukt multi-cast gruppeadresse. (9) NewResp <Multi-cast address>: Sendt fra en MNS-server til den forespørrende svitsjen. Frembringer en ubrukt multi-cast gruppeadresse.

Trestyring skal nå beskrives. Som omtalt ovenfor har

SSAM mange fordeler i forhold til andre løsninger. Den har alle fordelene til CBT algoritmene, siden SSAM anvender CBT paradigmet på ATM nivå. Det er tre faktorer som må tas med i betraktningen ved vurdering av trestyring, nemlig: det er ingen sentralisert database av gruppe medlemmene, dette muliggjør for enkel skaler-barhet;

SAAM krever lite statusinformasjon for å holdes

i ruterne, siden det er ett felles spredetre for en gruppe, ulik i mange andre tilfeller, hvor det er ett tre pr. kilde; og

greninitiert tilkobling er mulig, som er nyttig

for skalerbarheten og for enkelthet ved bruk.

I tillegg til dette, er SSAM hurtig, siden det kjernebaserte treet er bygget på et lavnivå som, ifølge foreliggende oppfinnelse, er ATM i stedet for IP nivå.

Selvfølgelig er det noen ulemper forbundet med SSAM. F.eks. krever SSAM at modifikasjoner utføres på eksisterende algoritmer og produkter, f.eks.:

ATM nivå signalering må modifiseres; og

ATM svitsjer må også modifiseres.

En av de viktigste sakene vedrørende SSAM er det med kjerneutvelgelse. Lokalisering av kjernen til treet er avgjørende, siden hele treet vil bli organisert rundt kjernen, er dens lokalisering den eneste faktoren som bestemmer optimaliteten til treet. En annen viktig sak er det med kjernestyring. Dette uttrykket omfatter to hovedfunksjonaliteter, nemlig:

relokalisering av kjernen; og

duplisering av kjernen for feiltoleransegrunner.

Relokalisering av kjernen kan være nødvendig

når kjernen ikke er plassert ved eller nær senteret av treet. Dette er illustrert i figurene 1 og 2, hvor fig. 1 viser et tre med en optimalisert lokalisert kjerne, og fig. 2 viser et tre med en dårlig plassert kjerne som virkelig krever relokalisering.

Det er viktig å understreke at uriktig kjerneplassering ikke betyr at protokollen ikke vil virke. I tilfellet med SSAM, betyr det til og med ikke at alle data vil bli videreformidlet til kjernen, som er fjerntliggende. Det betyr ganske enkelt at spredetreet vil ha en under-optimal form og signaleringsmeldingene må sendes over lengre distanser til kjernen, som er lengre borte, enn nødvendig.

Relokalisering av kjernen frembringer mange spørsmål, f.eks.: "Når bør kjernen flyttes?" For å svare på det spørsmålet, er det nødvendig å bestemme hvor kjernen bør relokaliseres. Algoritmer som anvendes for å bestemme et relokaliseringssted for kjernen, trenger ikke være den samme som algoritmen som anvendes for å bestemme den initielle lokaliseringen til kjernen, pga. at mer informasjon om gruppemedlemmene vil være tilgjengelig ved tidspunktet for relokalisering, enn det som var tilgjengelig ved tidspunktet for den initielle kjerne-lokaliseringen. Etter flytting av kjernen, må treet kanskje dannes på nytt. Rekonstruksjonen av treet er utenfor omfanget av foreliggende oppfinnelse.

Duplikasjon av kjernen er nødvendig for at protokollen skal være robust. Multiple aktive kjerner er interessante pga. at de muliggjør for deltakere å være organisert rundt kjerner som er fjerntliggende fra hverandre. Det er praktisk når f.eks. seks medlemmer er i en konferanse, tre på et første sted, og tre på et annet sted, fjernt fra det første stedet, og har to kjerner, en lokalisert på hvert av de to stedene. Dette scenariet er illustrert i fig. 3. Denne strukturen muliggjør for nye medlemmer å effektivt slutte seg til gruppen på begge steder, for således å unngå problemene som nevnt ovenfor, forbundet med dårlig plasserte kjerner.

Til slutt er en algoritme nødvendig for å muliggjøre at potensielle gruppemedlemmer, eller deres svitsjer, ruter fra multi-cast gruppe IP adresse, til ATM-adressen til kjernen. Denne prosessen vil bli beskrevet mer detaljert nedenfor.

Type statusinformasjon som lagres i nodene til treet for å muliggjøre effektiv arbeid, vil nå bli beskrevet. En algoritme for å styre treet og for å håndtere medlemskapsendringer, på en måte som ivaretar integriteten til treet, skal også beskrives. Formålet er å danne en optimal dataformidlingsalgoritme i et gitt tre, som betyr at sendere og mottakere i en multi-cast gruppe begge er parter av det samme treet. Formålet er å ha en algoritme som formidler trafikken kun til de grenene av dette treet, hvor trafikken er nødvendig. Dette betyr at ingen data vil bli videreformidlet til en gren, hvor det kun er sendere. Dette impliserer også at algoritmen ikke må være avhengig av lokaliseringen av kjernen. Fig. 4 viser et eksempel, hvor den eneste aktive senderen er sender 2, og den nødvendige databanen er merket med en pil.

Først betraktes hvilken informasjon som må lagres i hver node til treet, slik at optimale databaner kan etableres i treet. Som det enkelt kan ses på fig. 5, er kun to bits pr. link nødvendig for dette formålet. Et "ett-tall" ved enden av en link viser at trafikken skal sendes over den linken i den retningen, pga. at det er minst en mottaker på den andre siden av linken, et "null" indikerer at det ikke er noen mottakere på den andre siden av linken, slik at trafikk ikke skal sendes i den retningen. Dette kan klart ses ved å sammenligne fig. 4 og 5. Det skal bemerkes at en mottaker også kan være en sender.

Måten hvori medlemskapsendringer håndteres for å korrekt å ivareta status bits, skal nå beskrives.

Fig. 6 viser en situasjon hvori et sluttpunkt, svitsjes fra å være en sender til å være en mottaker. Siden sluttpunktet V nå er en mottaker, må verdien til 'e' endres fra '0' til '1'. På grunn av dette, må også 'b', 'c' og 'd' settes til '1'. Hvis en av 'b', ' c' eller 'd' er '0' foran svitsjen, må deretter algoritmen igjen kjøres på nytt i korresponderende W, X og Y noder. Dette betyr at når f.eks. algoritmen kjøres på nytt i node W, kan nodene V, X og Y midlertidig ignoreres og kjøring av algoritmen i node Z, en tidligere sender, omformer node Z til mottaker i forhold til node W. Denne enkle algoritmen bør ikke kreve videre forklaring for en fagmann. Selv-følgelig kan topologien til treet nær sluttpunktet V skille seg fra det som er illustrert i fig. 6. Det må være klart for en fagmann, hvordan algoritmen konstrueres for topologier andre enn den som er vist i fig. 6, fra den ovenfor nevnte beskrivelsen.

Ved å betrakte nå den motsatte situasjon, dvs. en mottaker blir en sender. Denne prosessen er illustrert i fig. 7. I dette tilfellet, siden V er blitt en sender, endres ' e' fra en til null. Før endringen, 'a' = 'f' OR ' q' OR 'h', hvor "OR" betyr den binære "OR" funksjonen. Etter endringen blir verdien til 'a' naturligvis værende den samme, ettersom 'f, ' q' og 'h' er uendret. Før endringen av verdiene til 'b', ' c' og 'd' var alle '1' og kan endres, ifølge den følgende algoritmen.

(1) Hvis der er minst to 'l'ere blant 'f, ' q' og

'h', trengs intet mer å bli endres, siden all trafikk må gå igjennom noden Z.

(2) Hvis der er nøyaktig en '1' blant ' f, ' q' og

'h', f.eks. 'f'=l, 'g'='h' = '0', må all trafikk som kommer fra nodene V, X og Y gå gjennom Z, slik at verdien til 'a', ' c' og 'd' ikke trengs å endres. Verdien til 'b', må imidlertid endres til '0' fra '1', siden data som kommer fra W ikke lenger må forflytte seg mot Z. På grunn av at verdien til 'b' er blitt endret, må denne algoritmen kjøres på nytt på noden W så vel, som omtalt i den foregående underseksjonen.

(3) Hvis 'f'='g'='h'='0' før endringene, for grunnene

beskrevet ovenfor, må 'b', ' c' og 'd' bli '0', og algoritmen må kjøres på nytt i nodene W, X og Y.

Hittil har prosessene involvert ved konvertering av en mottaker til en sender, og omvendt blitt omtalt. Prosessen forbundet med at et nytt medlem slutter seg til treet, se fig. 8 skal nå beskrives.

Viser til fig. 8, hvis endepunktet T ønsker å koble seg til treet, må det sende en tilkoblingsmelding mot kjernen. Denne meldingen beveger seg hopp-for-hopp inntil den treffer en gren av treet. I eksemplet vist i fig. 8, er et ganske vanlig tilfelle av en tilkoblingsmelding som treffer et eksisterende tre i midten av treet vist. Noden W har tre utgående linker i treet. Viser nå hvordan status bits'en skal modifiseres i dette tilfellet. For det første, må det være intuitivt klart at verdiene til 'a'ene, vist i fig. 8, må være de samme. Det samme gjelder for verdiene til 'b'ene. Det er også enkelt å vist at 'a'='c' OR 'd' OR 'e'. Videre, hvis endepunktet T slutter seg til som en mottaker, blir 'b'='l', ellers 'b'='a'. Alt som gjenstår, er at hvis T er en mottaker, må "sender blir en mottaker" algoritmen kjøres på node W, som om V var del av treet før tilslutning, men er nå endret fra å være en sender, til å være en mottaker.

Når et medlem bestemmer seg for å forlate gruppen, må den sende en forlatemelding, i treet, mot kjernen. Denne meldingen beveger seg inntil den når det første knute-punktet til treet. Den delen av treet blir deretter fjernet, som vist i fig. 9.

Som vist i fig. 9, ønsker T å forlate treet, og T-U-V grenen vil bli fjernet. Etter fjerning fra treet, hvis T var mottaker, må algoritmen "mottaker blir en sender" kjøres på W, som om V ble en sender fra en mottaker.

En algoritme for å opprettholde integriteten til treet når gruppemedlemskap endres, er blitt omtalt ovenfor. Andre spørsmål vedrørende trestyring omfatter:

ødeleggelse av treet, når en gruppe opphører

å eksistere; og

beskyttelse av treet mot link eller nodefeil,

som kan f.eks. resultere i at et medlem ikke forlater treet og således motvirker at treet noen gang blir ødelagt.

En mulig løsning til det sistnevnte problemet, er for gruppemedlemmer å periodisk sende "jeg er i live" melding til naboer. Dette frembringer informasjon om utstyrsfeil.

VP/VC sammensmelting skal nå beskrives. Celler som tilhører en AAL ramme kan ikke blandes, siden de er adskilt kun ved deres orden.. Hovedproblemet med VC-sammensmelting er at når to rammer fra to innkommende VCer må sammenflettes inn i en utgående VC, må alle cellene til den første rammen sendes ut først, fulgt av alle cellene i den andre rammen.

Algoritmen for SSAM virker med AAL5 rammer. Sammensetning av celler av AAL rammer, sammenstilling av dem og deretter repartisjonering av dem inn i rammer, på en tilsvarende måte som en ruter, vil være for sakte. Derfor må svitsjen sammenstille på cellenivå. Dette oppnås ved å dra fordel av det faktum at AAL5 identifikatorbit for slutt-på-pakke er del av tittelen til ATM cellen, slik at svitsjene enkelt kan identifisere den siste cellen til en ramme. En mulig forbedring til algoritmen, hvoretter det kan beskrives som oppsnitting-formidling, er at den første rammen som når svitsjen, ikke må settes i kø. Dette kan gjøre formidlingen jevnere, men kan gjøre situasjonen verre når den siste cellen til den første rammen ankommer senere enn de siste cellene til de andre rammene. I dette tilfellet anvendes en tidtaker for å motvirke en udefinert tilstand. Også tap av den siste cellen kan forårsake problemer. Løsningen som frembringes av foreliggende oppfinnelse, er at en ny EOP celle innføres for å motvirke netthopp som avgir celler/pakker pga. mangel på en EOP bit-celle, som vist i fig. 10.

Claims (30)

1. Internet Protokoll Asynchronous Transfer Mode, IPATM, overføringsnettverk omfattende et antall noder og et antall sluttpunkter tilpasset til å virke som datasendere, eller mottakere, hvor nodene og sluttpunktene er forbundet ved Asynchronous Transfer Mode, ATM, og hvor IPATM overførings-nettverket er tilpasset til å støtte multipunkt-til-multipunkt multi-casting mellom en gruppe sluttpunkter, og en gruppe omfattende medlemmer nært lokalisert til hverandre, anvender en multi-cast gruppeadresse, hvori minst en sender og alle mottakere, som tilhører en multi-cast gruppe av sluttpunkter, er lokalisert på et enkelt spredeleverings-tre, og at kun en Virtual Circuit, VC, anvendes for å overføre data over det enkle sprede-leveringstreet, karakterisert ved at en Multi-cast Network Service, MNS, er anordnet for å holde nevnte multi-cast gruppeadresse og ved at en vert er anordnet for å forespørre sin lokale MNS-serverfor en ny multi-cast gruppeadresse, nevnte lokale MNS-serveren er tilpasset til å forsyne en multi-cast adresse fra sine egne adresser, eller hvis nevnte lokale MNS-serveren ikke har noen ubrukte adresser, den nevnte lokale MNS er tilpasset til å forsyne en adresse for en nærmest lokalisert annen MNS-server, ved at det enkle spredeleveringstreet er en Core Based Tree, CBT, med rot i en kjernenode, og ved at relokaliseringsmidler er frembrakt for relokalisering av kjernen.

2. IPATM overføringsnettverk i samsvar med krav 1, karakterisert ved at nevnte CBT er bygget på ATM nivået.

3. IPATM overføringsnettverk i samsvar med krav 1 eller 2, karakterisert ved at IPATM overføringsnettverket er tilpasset til å ha mer enn en aktiv kjerne, hvor kjernene er geografisk adskilt fra hverandre.

4. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at det frembringes formidlingsmidler tilpasset til å formidle trafikk kun til de grenene av det enkle spredeleveringstreet hvor trafikken er nødvendig.

5. IPATM overføringsnettverk i samsvar med krav 4, karakterisert ved at formidlingsmidlene er tilpasset til å bli operert uavhengig av kjernelokalisering.

6. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at IPATM overførings-nettverket omfatter MNS midler tilpasset til å frembringe en ATM-adresse for kjernen, ved mottak av en IP multi-cast adresse.

7. IPATM overføringsnettverk i samsvar med krav 6, karakterisert ved at MNS midlene er tilpasset til å frembringe kjernepunktsstyring og multi-cast gruppestyring.

8. IPATM overføringsnettverk i samsvar med enten krav 6 eller 7, karakterisert ved at MNS midlene omfatter et hierarki av MNS-servere.

9. IPATM overføringsnettverk i samsvar med et av kravene 6 til 8, karakterisert ved at IPATM overføringsnettverket har kun en MNS-server, og ved at den kun ene MNS-serveren er ansvarlig for alle multi-cast gruppeadresser.

10. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at MNS midlene omfatter grenserutere tilpasset til å omforme mellom protokoller for dermed å muliggjøre at MNS midlene kan sameksistere ved andre multi-cast protokoller.

11. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at midlene er innrettet til å tillate greninitiert tilslutning.

12. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at midlene er innrettet til å lette at et sluttpunkt svitsjer fra å virke som en sender, til å virke som en mottaker.

13. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at midlene er innrettet til å lette at et sluttpunkt svitsjer fra å virke som en mottaker, til å virke som en sender.

14. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at midlene er innrettet til å muliggjøre at et nytt medlem slutter seg til en gruppe, hvor midlene er tilpasset til å forårsake at en tilslutningsmelding spres mot gruppens kjerne.

15. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at multipunkt-til-multipunkt forbindelser er frembrakt på ATM nivået.

16. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at ATM svitsjer i IPATM overføringsnettverket er tilpasset til å virke som oppbevaring og formidlingsenheter ved konflikter, og som cellesvitsjer ved fravær av konflikter.

17. IPATM overføringsnettverk i samsvar med et av de foregående kravene, karakterisert ved at VC flettemidler er frembrakt for å motvirke innfelling av ATM-celler, og ved at kjerneutvalgsmidler er frembrakt for å optimalisere formen til et spredeleveringstre sin struktur.

18. Fremgangsmåte for multipunkt-til-multipunkt multi-casting for anvendelse i et Internet Protocol Asynchronus Transfer Mode, IPATM, overføringsnettverk omfattende et antall noder, og et antall sluttpunkter tilpasset til å virke som datasendere, eller mottakere, hvor nodene og sluttpunktene er forbundet ved Asynchronus Transfer Mode, ATM, hvor fremgangsmåten omfatter å bygge et enkelt spredeleveringstre mellom minst en sender og alle mottakerne, som tilhører en multi-cast gruppe av sluttpunkter, og ved å anvende kun en Virtual Circuit, VC, for å overføre data over det enkle spredeleveringstreet, og omfattende en Multi-cast Network Service, MNS, k a r a k terisert ved at nevnte MNS frembringer en ATM-adresse for kjernen når gitt en multi-cast IP adresse; å konfigurere en vert som ønsker å anvende MNS med en ATM-adresse for en lokal MNS-server; verten, når den ønsker å bli et medlem av en multi-cast gruppe, overfører en fore-spørsel til en lokal MNS-server for en adresse for kjernen til multi-cast gruppen; den lokale MNS-serveren, hvis den er ansvarlig for gruppen, svarer med en ATM-adresse for kjernen; hvis den lokale MNS ikke er ansvarlig for gruppen, å sende videre forespørselen mellom MNS-serverne, i et MNS hierarki, inntil den når en MNS-server som er ansvarlig for nevnte gruppe og hvor den ansvarlige MNS-serveren svarer den forespørrende verten; MNS hierarkiet starter med en rot MNS-server som vet, til det neste nivået, hvilken server som er ansvarlig for hvilke intervaller av multi-cast adresseområdet; andre nivås MNS-servere som vet hvordan et adresseområde som de er ansvarlige for, er oppdelt i mindre adresseintervaller og hvilke tredje nivås MNS-servere som er ansvarlige for hvilke adresseintervaller; og å sende forespørsler gjennom MNS-server hierarkiet, inntil MNS-serveren, som oppbevarer tabellene for gruppene den er ansvarlig for, nås.

19. Fremgangsmåte i samsvar med krav 18, karakterisert ved at det enkle sprede-leveringstreet er en Core Based Tree, CBT, rotfestet i en kjernenode.

20. Fremgangsmåte i samsvar med 18 eller 19, karakterisert ved relokalisering av kjernen for å optimalisere spredeleveringstreets struktur.

21. Fremgangsmåte i samsvar med et av kravene 18-20, karakterisert vedå formidle trafikk kun til de grenene av det enkle spredeleveringstreet hvor trafikken er nødvendig.

22. Fremgangsmåte i samsvar med et av kravene 18-21, karakterisert ved at tilslutningsmeldinger, fra mottakere og sendere, spres mot kjernen.

23. Fremgangsmåte i samsvar med et av kravene 18-22, karakterisert vedå duplisere pakker kun på grener av spredeleveringstreet hvor de er nødvendige.

24. Fremgangsmåte i samsvar med et av kravene 18-23, karakterisert ved at hver MNS-server starter med en tom tabell, og ved å dynamisk danne innføringer deri.

25. Fremgangsmåte i samsvar med et av kravene 18-24, kar akterisert vedå realisere forespørsels-forsendelser på to ulike måter, nemlig: hvis MNS-server ikke er ansvarlig for en gruppe, videreformidle en forespørsel til en rot MNS server, som formidler den videre, eller formidle en forespørsel kun ett nivå opp i MNS hierarkiet, og ikke direkte til rot MNS-server.

26. Fremgangsmåte i samsvar med et av kravene 18-25, karakterisert vedå registrere kjernenoden for en multi-cast gruppe med MNS-serveren ansvarlig for gruppen og, hvis en forespørsel kommer frem til en MNS-server om en gruppe og ingen kjerne er spesifisert for den gruppen, ved å velge svitsjen som sendte forespørselen som kjernen, og ved at svitsjen er i stand til å avslå nominasjonen som kjernen og, hvis svitsjen ikke aksepterer nominasjonen som kjernen, ved å ikke etablere et spredeleveringstre.

27. Fremgangsmåte i samsvar med et av kravene 18-26, hvori en gruppe som har medlemmer nært lokalisert hverandre, anvender en multi-cast gruppeadresse som oppbevares av en MNS-server lokalisert nært til gruppemedlemmene, karakterisert vedå velge en MNS-server lokalisert nært til gruppemedlemmene ved hjelp av de følgende trinnene: en vert forespør sin lokale MNS-server for en ny multi-cast gruppeadresse, den lokale MNS-serveren blir deretter ansvarlig for å forsyne en multi-cast adresse fra sine egne adresser, eller hvis den lokale MNS-serveren ikke har noen ubrukte adresser, forsyner den lokale MNS en adresse til den nærmest lokaliserte andre MNS-server til den lokale MNS-serveren.

28. Fremgangsmåte i samsvar med et av kravene 18-27, karakterisert vedå forårsake at en tilslutningsmelding spres mot gruppens kjerne når et nytt medlem indikerer et ønske om å tilslutte seg en gruppe.

29. Fremgangsmåte i samsvar med et av kravene 18-28, karakterisert vedå overføre en forlatemelding over spredeleveringstreet forbundet med gruppen mot gruppens kjerne når et medlem av gruppen indikerer et ønske om å forlate gruppen, ved at forlatemeldingen forflyttes inntil den når et første knutepunkt til spredeleveringstreet, og ved å fjerne den delen av spredeleveringstreet over hvor meldingen har forflyttet seg.

30. Fremgangsmåte i samsvar med et av kravene 18-29, karakterisert ved at gruppemedlemmene periodevis sender en "jeg er i live" melding til nabonoder, eller sluttpunkter.