SE515815C2 - Anordning vid ATM-nät - Google Patents
Anordning vid ATM-nätInfo
- Publication number
- SE515815C2 SE515815C2 SE9402986A SE9402986A SE515815C2 SE 515815 C2 SE515815 C2 SE 515815C2 SE 9402986 A SE9402986 A SE 9402986A SE 9402986 A SE9402986 A SE 9402986A SE 515815 C2 SE515815 C2 SE 515815C2
- Authority
- SE
- Sweden
- Prior art keywords
- lan
- network
- traffic
- data communication
- atm
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5614—User Network Interface
- H04L2012/5615—Network termination, e.g. NT1, NT2, PBX
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5645—Connectionless
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
kommunikation från LAN för att tillåta kommunikation mellan näten.
Den amerikanska patentskriften 5 280 481 hänför sig till en metod och en apparat för att kunna använda tex MAC (Media Access Control)- protokoll för att kommunicera med ett ISDN-nät. Detta åstadkommes genom att ISDN-nätet emulerar ett LAN genom att konvertera det med hjälp av det angivna.
REDOGÖRELSE FÖR UPPFINNINGEN TEKNISKT PROBLEM Det föreligger önskemål om att man på ett långtgående sätt kan realisera system som handhar både publika och privata datakommu- nikationstjänster över ATM. Systemen har även det kravet på sig att de skall kräva mycket små resurser. Uppfinningen har till ändamål att lösa bland annat detta problem.
Tidigare lösningar har bland annat varit beroende av att LAN-trafik först analyseras av vissa noder i ATM-nätet. Denna analys är tids- krävande så tillvída att den resulterar i en adressupplösning, vars resultat måste sändas tillbaka till kunderna, varvid dessa själva etablerar kanaler till adressater. De kända utrustningarna har således endast fungerat såsom en katalog för adressupplösning. En helhetssyn på ifrågavarande har således saknats. Uppfinningen löser även detta problem.
Ifrågavarande produkter som utnyttjar uppfinningen skall kunna ingå i konventionella tele- och datakommunikationsutrustningar/växlar som är installerade för att kunna handha datakommunikationstjänster över ATM. Det föreligger därvid krav på att handhavandet av data- kommunikationstjänster i t ex bredbandsnät skall kunna göras enklare 515 815 Ö för kunder och operatörer än vad som är fallet med hitintills före- slagna lösningar. Uppfinningen löser bland annat detta problem.
Storlekarna på de koder som utnyttjas i anslutning till ovanstående skall kunna vara förhållandevis små. Uppfinningen löser även detta problem.
LösNINGEN Det som huvudsakligen kan anses vara kännetecknande för uppfin- ningen framgår av de efterföljande patentkraven.
FÖRDELAR Genom det i patentkraven föreslagna kan man på ett effektivt sätt åstadkomma att den privata sidan av LAN-emuleríngen blir obero- ende av den publika, vilket möjliggör att de med uppfinningen för- knippade lösningarna är enklare att utnyttja i den privata LAN- världen. Den privata sidan kan dessutom åta sig större ansvar för hanteringen av skuraktig LAN-trafik. Den nya lösningen kan arbeta med "blind" funktion än vad som hitintills varit möjligt. De nya lösningarna blir mycket billigare och enklare att realisera jämfört med tidigare.
I enlighet med uppfinningen kan noderna som tar emot LAN-trafiken agera både som reläer och adressupplösare. Adressupplösningen utgör en sidoeffekt av reläernas operation och funktion. Genom dessa särdrag kan de nya systemen snabbt föra fram eller avveckla LAN- trafiken genom nätet samtidigt som kunderna kan få klart för sig hur de kan välja alternativa signalerade vägar över ATM-nätet för framtida trafik.
FIGURFÖRTECKNING En för närvarande föreslagen utföringsform av en anordning som uppvisar de för uppfinningen signifikativa kännetecknen skall beskrivas i nedanstående under samtidig hänvisning till bifogade ritningar där figur 1 i principschemaform visar en BDS-server, figur 2 i principschemaform visar en LAN-emulering, figur 3 i blockschemaform visar relationer mellan BDS- och LAN- adresskontexter, figur 4 i diagramform visar BDS- och LAN-relaterade protokoll och PDU (BOM), figur 5 i principschemaform visar en fysisk topologi för ett BDS-nät, figur 6 i tabellform visar FBDS-PDUn, och figur 7 visar en vägvalstabell som den skulle kunna se ut för server A i figur 5.
DETALJERAD UrFömNGsFoRM Här specificeras och implementeras en enkel och robust mekanism för konfigurationshantering av en publik bredbandstjänst för datakom- munikation över ATM. Konfigureringshanteringen relaterar vidare LAN- till E.164-adresser varvid virtuella LAN över ett publikt nät kan implementeras.
Det är känt att implementera en bredbandstjänst över ATM (BDS, Broadband Data Service). En naturlig fortsättning på specifikations- och implementationsarbetet med BDS var att relatera en känd publik E.164-baserade tjänst till aktiviteter som berör ATM-nät.
Det svåra med en sådan tjänst över ett publikt BDS-nät ligger i eta- bleringen och hanteringen av relationen mellan adressrymder. I LAN används IEEE MAC adresser medan man i BDS talar om E.164- adresser.
I ATM-sammanhang åsyftar begreppet LAN-emulering metoder för skapandet av virtuella LAN över B-ISDN. På dessa virtuella LAN kan sedan LAN-stationer förbindas med varandra på ett emot det under- liggande publika nätets topologi transparent sätt. Detta förutsätter en mycket dynamisk koppling mellan adresserbara LAN-noder och ATM- noder, eftersom de förra, i princip hur som helst i tid och rymd, skall kunna projiceras på de senare.
Tjänsten som LAN-emuleringen skall resultera i måste överens- stämma med traditionella LAN-gränssnitt som erbjuds dvs: MAC_UNITDATA. request och MAC_UNITDATA.indication. Den måste vidare kunna användas i följande typer av associationer (där beteckningen "station" avser traditionella LAN-stationer eller bryggor, medan "terminal" avser stationer och bryggor med ATM-gränssnitt)z Station till station över ett virtuellt LAN eller brygga (t ex. S3 till S4 i Fig. 1); station till terminal över en virtuell eller verklig brygga (t ex. S2 till 53); Terminal till terminal möjligen över en virtuell brygga (t ex. S1 till S2). Från användarsynpunkt måste LAN-emuleringstjänsten res- pektera MAC-tjänsters syntax och semantik och därför kunna hantera befintliga LAN-applikationer.
Vid utformningen av ett virtuellt LAN över ATM måste hänsyn tas till ytterligare designprinciper, förutom de i föregående paragraf, som har med emulatorns interna operation att göra. För det första bör AAL5 användas som underliggande teknologi eftersom denna kommer att dominera marknaden. Vidare bör LAN-emuleringen specificeras så att den respekterar en fundamental egenskap i ATM-nät, (fl _» 0": OC ...i (I: nämligen integritet i leveransordningen av paket mellan två till varandra direkt förbundna noder. Denna egenskap återfinns för övrigt också i de flesta LAN tekniker idag, tex Ethernet. LAN-emuleringen måste också kunna hantera såväl grupp- som individuella adresser och får inte förutsätta att paket som adresseras till en specifik nod alltid kan skickas (broadcast) till en grupp av noder. Slutligen skall det virtuella LAN:et tillåta att en station kan vara registrerad i flera virtuella LAN samtidigt.
I en MAC-kontext motsvarar enheter i Fig. 3 bryggor och LAN- stationer (t ex. arbetsstationer). I en BDS-kontext motsvarar de (BDS) serverzar och (BDS) terminaler. En LAN-station eller brygga som är för- sedd med ett ATM-gränssnitt kan också agera BDS-terminal, under för- utsättning att den har förmågan att hantera E.164 SNPA:n (Subnetwork Points of Attachment). Sådana LAN-stationer eller bryggor är därför intressanta att studera ifrån bägge adresseringskontexter.
Relationen mellan LAN och BDS kan gestaltas enligt Fig. 3, där adress- struktureringskoncept ifrån ANSA används. Enheter identifieras via MAC-adresser, E.164-adresser, eller bägge. I det sistnämnda fallet kan därför den ena typen av adresser ses som alias till den andra. I Fig. 3 låter vi också MAC / E.164 kontexter representera logiska eller fysiska grupperingar av enheter, tex ett fysiskt eller virtuellt LAN .
En LAN-emuleringsgrupp (LEG) definierar en MAC-adresskontext. Det framgår inte av Fig. 3 men är underförstått att en MAC-adress kan tillhöra flera olika MAC-adresskontexter, dvs flera olika LEG:n. För terminaler kan det vidare finnas flera MAC-alias till en och samma 13.164.
Till exempel kan en terminal som representerar en LAN-brygga åter- speglas i flera entiteter i en MAC-kontext, trots att den endast har en E.164-adress (t ex MACd, MACe och MACf på E.164d). Denna relation är beroende av utsträckningen i vilken bryggan låter MAC-adresser på sin MAC / LAN-sida, tex. Ethernet, bli "kända" för E.164-sidan.
En del av enheterna som identifieras i E.164-kontexten är inte "syn- liga" ifrån någon MAC-kontext (t ex E.164° och E.164f). Dessa enheter kan exempelvis vara BDS-terminaler eller serverzar som inte deltar i ett virtuellt LAN.
I föreliggande metod betraktas tuppeln som alias till en E.164-adress. En E.164-adress kan inneha flera alias, men alias kan bara relateras till en specifik E.164-adress (till en BDS-server eller BDS- terminal). Detta betyder att en LAN-enhet kan registrera sig mot flera BDS-serverzar, men att den inte får registrera samma - tuppel på i olika serverzar. I annat fall riskerar kommunikationen att bli inkonsistent, eftersom integritet i paketens sekvensordning då inte kan garanteras.
I den ursprungliga BDS baserades Vägvalet på en ideell abstraktion som fastslog att alla serverzar hade en direkt VP till alla andra (full mesh). Vägval (routing) bestämdes av värdet på tuppeln av-sändare, E.164-adress mottagare>. För mer generella topologier har använts en "kortaste-vägen"-algoritm (shortest-path) som kan här- ledas ifrån en algoritm-klass utvecklad av LR Ford och D.R Fulkerson och som enkelt kan användas som grund för decentraliserat vägval.
Det är en avståndsvektor-algoritm i vilken varje nod i nätet innehåller en databas som beskriver avståndet till varje annan nod.
Grovt sett kombineras minimalistiska algoritm avståndstabeller med vägvalstabeller, något som är ganska enkelt att göra eftersom i varje enskilt ögonblick endast en väg underhålls mellan varje nodpar.
En annan algoritm, som också resulterar i etableringen av kortaste vägar mellan noder i ett nät, är den som först specificerades av W. Dijkstra, i vilken nodernas vägvalstabell bygger upp en global O' l ...s 0": K _: (I: topologisk kunskap med information om avståndet till varje nod och varje länks kostnad.
Med W. Dijkstras algoritm krävs emellertid större databaser i varje nod, särskilt om den skall decentraliseras. Den är dock fördelaktigare än den enklare varianten som valdes att implementera eftersom den möjliggör både en bättre fördelning av trafiken i nätet (i detta fall datakommunikationstrafiken) samt flervägsval.
Vägvalsstrategin som används är decentraliserad och statisk. Med statisk menas att den etablerar nya vägar endast som en följd av topo- logiska förändringar i nätet. Den reagerar sålunda inte för tillfälliga förstoppningar i nätet. För att komma runt detta introduceras metoder att använda alternativa vägar mellan nodpar samt okonventionella mekanismer för åtgärda förstoppningar.
Ett viktigt mål med metoden har varit att specificera vägval i BDS- nätet på ett sådant sätt att LAN-stationer och bryggor kan operera så självständigt som möjligt ifrån nätet. Ett sådant mål kan tyckas konstigt, speciellt om det föreslås av en nätverksoperatör, men syftet är egentligen att förespråka en federation som ur LAN-synpunkt lik- ställer det publika med det privata. Genom detta kan presenteras en metod som ålägger LAN-administrationer ett stort ansvar i hanteringen av dessa källors beteende.
I vägvalsmetoden användes alltså de ursprungliga vägvalstabellerna i BDS serverzarna med vissa små justeringar för hanteringen av alias- adresser enligt ovan. Detta medför att BDS-enheter (terminaler och server:ar) kan välja väg på basis av såväl E.164- som MAC-adresser.
Här kombineras bruket av PVC:n (Permanent Virtual Circuits) och SVCzn (Switched Virtual Circuits) för datatjänster över ATM.
Detaljerna för SVC:n lämnas dock utanför specífikationen. En LAN- station eller brygga kan sända datapaket igenom BDS-nätet eller använda SVC:n direkt till mottagaren. Tex kan S1 och S2 (Pig. 5) 0"! ...L 0"! 03 O' I w kommunicera antingen via det virtuella LAN:et (dvs igenom BDS- nätet) eller också etablera en direkt kanal sinsemellan. Möjligheten att använda SVC:er kan utnyttjas av BDS-nätet för att minska en viss källas belastning på nätet. En terminal som etablerar en SVC direkt till en annan, måste dock trots detta fortfarande lyssna på meddelanden ifrån BDS-nätet bland annat för att få information om hur det står till med andra LAN-stationer tillhörande samma virtuella LAN.
Om LAN-trafiken sker över BDS-nätet, på basis av MAC-adresser, kommer nätet att vid varje adressupplösning meddela trafikkällan om vad denna MAC-adress motsvaras av för E.164-adress. Notera dock att BDS-nätet, genom registreringen av alias-adresser, visst kan välja väg genom att endast titta på MAC-adressen. Exempel (Fig. 5): Om S1 adresserar S2 genom en MAC-adress kommer det virtuella LAN:et att informera S1 orn Szzs E.164-adress, under förutsättning att S1 har abonnerat på sådan information ifrån BDS-nätet. S1 kan därefter bestämma huruvida en SVC till S2 skall etableras eller ej. I vissa fall kan dessutom BDS-nätet (virtuella LAN:et) självt begära att en sådan direkt förbindelse skall etableras, tex som ett sätt att komma ifrån en turbulens i nätet. Sammanfattningsvis fungerar BDS-servern som E.164- och MAC-"router" eller brygga, som en SVC adresserver och som primitiv trafikkontroll.
BDS måste alltså revideras så att den kan hantera MAC-adresser i den första ATM-cellen. För att möjliggöra detta användes en kodning för E.164 som standarderna inte har reserverat. Det specifika mönstret för de första 4 bitarna i denna E.164-adress är inte viktigt för det i nedan angivna. Därför refereras det till som MAC_BDS. BDS-terminalen registrerar sin egen adress tillsammans med sin MAC-adress (eller flera MAC-adresser eftersom en BDS-terminal kan fungera som LAN- brygga). För varje MAC-adress förväntas terminalen vidare specificera vilken LEG (LAN Emulation Group, dvs virtuellt LAN) denna MAC- adress skall tillhöra. Till exempel kan S1 (Fig. 2) registrera samma MAC-adress i två grupper, a och b. Om registreringen går igenom resulterar den i en konfirmering ifrån BDS-nätet. Terminaler m -pà QÜI c-:t nå.
U' l /0 förväntas vidare kontinuerligt sända Hallå-meddelanden (System Hellos) till BDS-nätet.
Här specificeras två adresskodningsmetoder i samband med adress- familjen MAC_BDS. För registrering av individuella MAC-adresser är återstående bitar i E.164-adressens första oktett lika med noll. Ett alternativ är då bitmönstret representerar en TROIANSK MAC-adress (liksom för MAC_BDS, är detta bitmönsters specifika utseende inte relevant för diskussionerna i detta dokument).
Exempelvis skulle en till brygga konfigurerad BDS-terminal kunna vara medveten om att dess Ethernet-sida inkluderar dolda stationer (hidden stations). I detta fall kan bryggan registrera sin egen MAC- adress som MAC_BDS+TROIAN som ett sätt att tala om för BDS-nätet att MAC-adresser som inte är kända för (registrerade i) i BDS-nätet skall skickas till denna terminal/ brygga. Genom detta förfarande löser man problem med dolda stationer i ett virtuellt LAN. Denna lösning kräver dock ytterligare en manipulering av adresser enligt följande: Den okända MAC-adressen (som förhoppningsvis tillhör en dold LAN-station) enkapsuleras i BOM-PDU:n och ersätts med de MAC- adresser till bryggor som har registrerat sig själva som TROIANSKA.
En i nätet olöst MAC-adress enkapsuleras endast med de bryggors adresser som ingår i samma virtuella LAN . När en brygga får ett paket med sin egen adress men med bitmönstret markerandes TROIANSK, reverserar den enkapsuleringen och skickar paketet vidare, exempelvis igenom sin Ethernet-port.
I föreliggande lösning förutsätts att adressinlärning sker uttalat, dvs inte integrerad med kommunikationen. Framtida versioner bör inte- grera inlärning med vanlig trafik, exempelvis behöver inte Hallå- meddelanden skickas över en kanal genom vilken vanlig datatrafik redan går. u- ïå. u-i 02 __! o 1 /I Vi definierar en gräddfil (Fast Lane) som en temporär väg igenom BDS-nätet mellan två serverzar i utkanterna av nätet. Syftet med gräddfilen är att direkt förbinda två LAN-enheter som genererar mycket trafik sinsemellan och på det sättet avlasta inre BDS-server:ar ifrån denna trafik. En gräddfil är därför analog till SVC:n med skill- naden att gräddfilen etableras innanför nätet medan SVC:n etableras utanför.
En annan analogi ligger i det att gräddfilen aldrig registreras i vägvals- tabellerna eftersom den är temporär. Gräddfilen liknar mycket den mekanism som har föreslagits för SMDS (short-cut routing). Exempel: BDS-serverzarna A och B i Fig. 5 etablerar en gräddfil emellan sig och avlastar därmed server E ifrån trafiken mellan S1 och S2.
I den första BDS-lösningen gjordes statiska antaganden om konnek- tivitet och vägvalsmekanismer serverzar och terminaler emellan.
Vidare föreslogs att man skulle anpassa ISO-protokollen 1509542 och 15010589 till ATM och använda dem för hantering av konfigurering och vägval i BDS.
Fördelarna med ovanstående protokoll är au de är standardiserade och väl beprövade och au de använder sig av W. Dijkstras länkstatus- algoritm enligt ovan. Vidare har IS010589 redan ett fönster emot CMIP (Common Management Information Protocol) och kan därför enkelt relateras till befintliga managementsystem. Som vi klargjorde ovan tittar vi på denna lösning parallellt med den som vi redogör för här.
Grunden för vägval och hantering av konfigurationer utgörs av VPlzn som tjänar som portar för avståndsvektor-algoritmen. Denna algoritm har används mycket i datakommunikatíonssammanhang. Den är väldigt enkel men lämpar sig endast för datagram-kommunikation eftersom den normalt sett inte kan garantera att sekvensordningen bibehålls genom nätet. Detta kan åtgärdas genom att kontrollera tiden vid vilken en registrerad väg skall få ha med vägval att göra. (fl ...x ul CC- .A (fl /2 I BDS-nätet förutsättes symmetriska VPI:n mellan förbundna nodpar. Över dessa VPI:n finner vi två typer av trafik: Data och management.
Datatrafiken sker medelst BDS, medan management-trafiken kan jämföras med F-flöden som definierats för ATM. Detta benämns management för BDS till FBDS.
FBDS-entiteter i BDS-serverzar, vars PDU-struktur åskâdliggörs i Fig. 6, interagerar sålunda direkt med AAL5. Tídsrelaterade oktetter tjänar till att utbyta information om frekvens och aktualitet i meddelande- utbytet. NET (Network Entity Title) betecknar enhetens (servercn eller terminalen) verkliga namn i systemet. I praktiken åsyftas en E.l64- adress men principiellt är det inget som förbjuder användandet av MAC-adresser som NET.
Gör man det bör man dock vara medveten om att NETzen inte kan användas som underlag för signalering. Kostnadsfältet specificerar av- ståndet, i antal hopp, till den genom NET åsyftade stationen. Options- fältet används inte i denna version av FBDS.
Etableringen av associationer mellan stationer (terminaler eller ser- verzar) utgör inte en integrerad del av algoritmen. En station bör känna till sin egen E.164-adress (NET) och i fallet terminal också eventuella egna alias. Vid initieringen laddas denna adressinformation i kon-figureringsdatabasen på VPI=NOLL (som är en makro refererandes till det egna systemet).
Alla element i databasen som refererar till VPI=NOLL tilldelas automatiskt kostnaden 0 (noll) och för varje används också en bitkarta (bitmap) genom vilken man kan hålla reda på vilka andra stationer som har registrerat den. Till varje element i databasen som har kostnad O associeras vidare en klocka som håller reda på frekvensen med vilken den egna informationen skall sändas på andra VPI:n (dvs till alla direkta grannar).
U'l C51 OC: E51 /å Ytterligare resurser som måste initieras är buffertar för inkommande och utgående data, det maximala antalet hopp som stationen accepterar att registrera m.m. Initieringsfasen efterföljs av en operativ fas i vilken en station kan börja gå igenom elementen i sin databas och samspela med sin omgivning enligt det som beskrivs nu.
FBDS-entiteten går igenom elementen i sin databas, inklusive de egna adresserna på VPI=NOLL. Alla element som registreras i en server eller terminal är kopplade till en VPI som anvisar varifrån infor- mationen i elementet härrör (se figur 7). Om ett element har registrerat en kostnad som överstiger ett maximalt tillåtet värde på accepterade antal hopp (enligt ovan) tas den bort ur tabellen.
Här tillåtes registrering av ogiltiga element, dvs sådana med egentligen för höga kostnader, för att kunna åtgärda situationer i vilka stationer felaktigt informerar varandra om andra stationer som egentligen inte finns i nätet. Exempel (Fig. 5): Server Czs förbindelse med A blir ogiltig av någon anledning, varvid server A informerar serverzarna E och D om detta. På grund av asynkronin i nätet resulterar det i att D regi- strerar en ny väg till C via E, och informerar A om detta, som i sin tur informerar E om detta osv. Den felaktiga informationen cirkulerar i nätet till dess att kostnaderna överskrider ett maximalt värde varvid de tas bort och nätet stabiliseras.
Ett element i databasen kan vara registrerat som GILTIGT eller OGILTIGT. Den ogiltiga varianten syftar till två saker. Det första är att ge direkta grannar tillräckligt med tid för att registrera utsänd kon- figureringsinformation. Exempel (Fig. 5): Server A väljer väg för BDS- paket till server C, för Bzs räkning. A förlorar så plötsligt kontakten med C och registrerar därför alla adresser som är förbundna med VPI=C som OGILTIGA. Därefter ser den till att denna ogiltighet regis- treras av B. När ogiltigheten i C-adresser har konfirmerats av B till A kan A ta bort alla C-element ifrån sin egen databas.
Det andra syftet med ogiltiga adresser är att ge direkta grannar tillräckligt med tid för att svara på en ogiltig adress med en alternativ väg. Om (Fig. 5) server D förlorar sin förbindelse till E, kommer detta att möjliggöra för A att tala om för D att den kan ta hand om trafik emellan D och E. Genom detta förfarande kan konfigurerings- hanteringen effektiviseras avsevärt.
Varje element i databasen, för vilket en klocka har passerat ett givet maximalt värde, tas bort ur tabellen. Om samma klocka når ett givet värde mindre än det maximala ändras dess status till OGILTIGT. Detta beskrivs mer detaljerat i nedan.
Varje gång ett nytt element registreras i databasen, eller ett redan registrerat element får sin status förändrad (GILTIGT till OGILTIGT eller vice versa), skickas denna nya information till alla direkta grannar (dvs på alla BDS-VPI:n). Dock skickas informationen inte över den VPI från vilken information har erhållits.
Ett nyregistrerat element som motsvarar en direkt enhet (t ex E.164 C över VPI=A-C i Figur 7) får på motsvarande sätt all information skickat till sig, via den VPI från vilken det nya elementet kom (dvs all information i tabellen (fig. 7) skickas över VPI=A-C, förutom den information som redan har registrerats på A-C). Notera också att ett element alltid måste ha samma status som det (eller de) NET som har registrerats över samma VPI (dvs status för E.l64 brygga och MAC S3 måste motsvara status för E. 164 C eftersom detta element representerar NET för VPI A-C).
Enligt ovan sänds all information i databaserna till direkta grannar. Ett undantag till detta görs om grannen är en terminal. I detta fall kan man filtrera bort information som enbart har med serverzar att göra och bara skicka information om andra terminaler som tillhör samma LEG. Ett liknande filter kan också användas serverzar emellan på det att en server bara sprider information till de som har registrerat samma LEG som informationen. Denna mekanism måste dock 0"! ...a U' l av ...m (fl /5 användas med stor försiktighet så att isolerade öar av serverzar, som egentligen betjänar samma LEG:n, inte uppstår.
Inkommande PDU:n kan vara antingen positiva eller negativa. De senare, som vi väljer att kalla "antimeddelanden" (antimessages), an- vänds för att explecit avregistrera element i en databas. Detta förklaras i detalj nedan.
Positiva meddelanden bekräftas omedelbart, varefter deras innehåll analyseras. Detta innehåll kan medföra att ett nytt element registreras i databasen, eller att ett gammalt elements status eller VPI förändras, eller att den inte påverkar databasen alls. Det sistnämnda fallet in- träffar oftast som en följd av att kostnaden för elementet är för hög.
Om informationen i FBDS-PDU:n medför att ett nytt element läggs in i databasen tas denna förändring om hand enligt ovan, dvs nyregis- treringen sprids till alla. Om det nya elementet representerar en direkt granne sprids dessutom all information till den.
Om informationen i PDU:n representerar ett element som redan registrerats kan två saker hända. Om detta element pekar på en billigare väg behandlas den som om den vore ny. Om inte, medför den inga förändringar i databasen. Databasen innehåller ett bitfält genom vilket en server kan hålla reda på vilka meddelanden som har be- kräftats av andra direkta serverzar, dvs allt FBDS informationsutbyte bekräftas (acknowledgement).
Om det inkommande FBDS-meddelandet betecknar ett antimed- delande kan återigen flera saker inträffa. En är då exempelvis server A får ett antimeddelande ifrån server B om server A (dvs server B ber sina grannar att ta bort server A ifrån sina databaser)! Ett sådant meddelande kan bli följden av att B inte har fått Hallå-meddelanden ifrån A på ett tag och därför ändrar status för A ifrån GILTIGT till OGILTIGT. Det omedelbara svaret från A blir då att skicka ett Hallå- FBDS-PDU och därefter förslagsvis meddela något managementsystem /ó om att systemparametrarna (klockor) bör modifieras eller att något annat i BDS-nätet är galet.
En annan följd av antimeddelanden är då det gäller en direkt granne. I detta fall ändras status för alla andra element över samma VPI.
Ytterligare ett fall är då antimeddelandet refererar till ett element som mottagaren har registrerat på en annan VPI. Exempel (Fig. 5): Server D tappar förbindelsen till server E och skickar information om detta till sina grannar som i detta fall är server A. Meddelandet är ett sätt för D att tala om för sin omgivning att den inte längre klarar av att ta hand om trafik till E. A svarar på detta antimeddelande genom att tala om för D att den vet hur man när E, och D kan registrera detta i sin databas.
För alla element med kostnad 1 eller O används klockor. Om elementet är registrerat på VPI=NOLL, tolkas en klocksignal (time-out) som att det är dags att skicka ett hallå-FBDS-PDU till alla andra VPI:n. Om inte, och klocksignalen anger ett givet värde (time-retry) mindre än time- out, ändras status i elementet till OGILTIGT. Hinner klockan inte återställas innan den når time-out tas elementet bort ifrån tabellen.
FBDS implementerades i C på samma plattformar som användes för BDS. Irnplementationen bygger på användningen av asynkrona gräns- snitt genom vilka en FBDS-process metodiskt går igenom sin egen databas och informerar sin omgivning om eventuella förändringar.
När ett meddelande kommer in ifrån någon annan FBDS-process på en annan server/ terminal, avbryts övervakningen av den egna data- basen för att åtgärda detta meddelande, varefter övervakningen återupptas.
Flera FBDS-processer kan exekveras på samma arbetsstation. Tester innefattande 9 server:ar och 8 terminaler har utförts och alla konfigu- rationsändringar tas väl om hand av FBDS-processerna. Notera att samma FBDS-kod används såväl för terminal som för server. Den enda skillnaden återfinns i hanteringen av informationsspridning 515 815 /? eftersom terminaler endast får information om andra terminaler som tillhör samma LEG, medan serverzar erhåller all information om nätets tillstånd.
Det finns en hel del kriterier utifrån vilka vägvalsalgorítmer kan analyseras, även om man skall vara medveten om att analysresultat är starkt beroende av den specifika konfigurationen som man har valt att studera: ° Snabbheten med vilken databaserna i nätet registrerar en konfigu- rationsändring.
° Antal kontrollpaket som behövs för att uppnå en stabilisering av nätet under och efter en konfigurationsändring. 0 Storleken på kontrollpaketen.
° Kontrollprocessernas komplexitet.
° Buffertutrymme som behövs för kontroll. ° m.fl.
Ovanstående visar på: kontrollpaketens (FBDS-PDU) storlek som ryms i en ATM cell (AAL5 SAR PDU), små behov av buffertar och enkla kontrollprocesser.
Emellertid kan loopar uppstå i BDS-nätet innan det hinner stabilisera sig kring en given topologi. Detta är en av anledningarna till att ARPA övergav algoritmen (även om det dock bör påpekas att deras metod byggde på kostnader i form av bandbredd och inte i form av antal hopp som i vårt fall). Detta kan man dock motverka genom att bibehålla en någorlunda stabil topologí mellan serverzarna. Stabilitet kan å andra sidan vara ytterligare ett argument för länkstatus-algoritmen. Stabilitet för avståndsvektoralgoritmen kan dock uppnås genom att utarbeta en (F: ...à (fl gg nå.
(I: något begränsad policy vad gäller tilldelningen av LAN-grupper till serverzar, och därmed också LAN-stationer till LAN-grupper.
Grundalgoritmen, i synnerhet då kostnaderna är i form av antal hopp, kräver ett informationsutbyte av storleken O(n3) där n står för antalet serverzar i nätet (och i viss mån också terminaler, men dessa är i sanningens namn hårt sammankopplade till vissa serverzar i ytter- kanterna av BDS-nätet). Detta stora informationsutbyte beror i första hand på algoritmens grundläggande blindhet som medför att alla meddelanden skickas till alla grannar. Man kan dock förbättra den genom att göra den intelligentare. Genom våra förbättringar kommer man ner till ett informationsutbyte av storleken O(n2). Algoritmen mår också bäst av en liten diameter på nätet, dvs konnektiviteten bör vara hög.
Uppfinningen är inte begränsad till den i ovan så som exempel visade utföringsformen utan kan underkastas modifikationer inom ramen för efterföljande patentkrav och uppfinningstanke.
Claims (11)
1. Anordning vid ATM-kommunikationsnät som innefattar serverorgan som omhändertar förbindelselös datakommunika tionstrafik och tillser att respektive ur denna trafik upp kommande datapaket når sina destinationer, varvid serverorganen hanterar publik datakommunikation, kännetecknad därav att serverorganen även hanterar från LAN-nät uppkommande privat datakommunikation med hjälp av en LAN-emule ringsfunktion, vilken LAN- emuleringsfunktion ingår för att skapa virtuella LAN över B-ISDN, på vilka virtuella LAN-stationer är förbundna med varandra på ett mot underliggande publika näts topologi transparent sätt, vilket förutsätter en dynamisk koppling mellan adresserbara LAN-noder och ATM-noder eftersom de förra skall vara projicerbara på de senare, och att nämnda noder är anordnade att ta emot LAN- trafiken både som reläer och adressupplösare medförande att LAN-trafiken genom nätet blir snabbt avverkningsbar sam tidigt som systemet kan meddela kunderna hur dessa skall välja alternativa signalerade vägar över ATM-nätet för framtida trafik.
2. Anordning enligt patentkrav 1, kännetecknad därav att LAN-tjänsten är federativ, varmed menas att den privata sidan av LAN-emuleringen är oberoende av den publika data kommunikationstrafiken.
3. Anordning enligt pa tentkrav 1 eller 2, kännetecknad därav att organ är anordnade att ålägga den privata sidan större ansvar för hantering av skuraktig LAN -trafik.
4. Anordning enigt något av föregående patentkrav, kännetecknad därav att en förändring i nätet tar förhållandevis lång tid att stabilisera.
5. Anordning enligt något av föregående patentkrav, kännetecknad därav att den ingår i tele- och datakommunika tionsutrustningar, t.ex. växlar som är installerade för att kunna handha datakommunikationstjänster över ATM.
6. Anordning enligt något av föregående patentkrav, kännetecknad därav att handhavandet av datakommunikationstjänster i bredbandsnät blir förenklad genom att storleken på utnyttjad kod är förhållandevis liten.
7. Anordning enligt något av föregående patentkrav, kännetecknad därav att vid publik bredbandstjänst för datakommunikation via ATM konfigurationshantering är relaterad till LAN- till E.164-adresser, varvid 10 15 20 fl 815 i '- (Ill ...J 20 virtuella LAN över ett publikt nät är implementerbart.
8. Anordning enligt något av föregående patentkrav, kännetecknad därav att LAN-emuleringen överensstämmer med traditionella LAN-gränssnitt och att från användarsynpunkt LAN-emuleringstjänsten respekterar MAC-tjänsters syntax och semantik och därför kan hantera befintliga LAN-applika tioner.
9. Anordning enligt något av föregående patentkrav, kännetecknad därav att LAN -emuleringen respekterar en egenskap i ATM-nätet i form av integritet i leveransordningen av paket mellan två till varandra direkt förbundna noder, och att LAN-emuleringen hanterar såväl grupp- som individuella adresser och inte förutsätter att paket som är adresserade till en specifik nod alltid kan skickas till en grupp av noder, varjämte den virtuella LAN-enheten tillåter att en station är registrerad i flera virtuella LAN sam tidigt.
10. Anordning enligt något av föregående patentkrav, kännetecknad därav att Vägvalet är baserat på en "kortaste-vägen"-algoritm av i och för sig känt slag, varvid en av ståndsvektor-algoritrn i respektive not i nätet innehåller en databas som beskriver avståndet till varje annan nod, och att kombination föreligger av nämnda minimalistiska algoritm-avståndstabeller med vägvalstabeller.
11. Anordning enligt patentkrav 10, kännetecknad därav att för eliminering av tillfälliga förstoppningar i nätet alternativa vägar mellan nodpar är upprättningsbara. wav. -Hø
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SE9402986A SE515815C2 (sv) | 1994-09-08 | 1994-09-08 | Anordning vid ATM-nät |
PCT/SE1995/000989 WO1996008099A2 (en) | 1994-09-08 | 1995-09-04 | Device at atm-network |
DE69534446T DE69534446D1 (de) | 1994-09-08 | 1995-09-04 | Vorrichtung an einem atm-netz |
EP95931484A EP0780041B1 (en) | 1994-09-08 | 1995-09-04 | Device at atm-network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SE9402986A SE515815C2 (sv) | 1994-09-08 | 1994-09-08 | Anordning vid ATM-nät |
Publications (3)
Publication Number | Publication Date |
---|---|
SE9402986D0 SE9402986D0 (sv) | 1994-09-08 |
SE9402986L SE9402986L (sv) | 1996-03-09 |
SE515815C2 true SE515815C2 (sv) | 2001-10-15 |
Family
ID=20395160
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
SE9402986A SE515815C2 (sv) | 1994-09-08 | 1994-09-08 | Anordning vid ATM-nät |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP0780041B1 (sv) |
DE (1) | DE69534446D1 (sv) |
SE (1) | SE515815C2 (sv) |
WO (1) | WO1996008099A2 (sv) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7149815B1 (en) | 1996-12-06 | 2006-12-12 | The Distribution Systems Research Institute | Integrated information communication system using internet protocol |
SG79949A1 (en) | 1996-12-06 | 2001-04-17 | Distribution Systems Res Inst | Integrated information communication system |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH04107029A (ja) * | 1990-08-27 | 1992-04-08 | Mitsubishi Electric Corp | ローカルエリアネットワーク間接続方式 |
WO1992014321A1 (en) * | 1991-01-31 | 1992-08-20 | Fujitsu Limited | Connectionless communication system |
US5280481A (en) * | 1991-09-20 | 1994-01-18 | Extension Technology Corp. | Local area network transmission emulator |
US5457681A (en) * | 1992-06-05 | 1995-10-10 | Washington University | ATM-Ethernet portal/concentrator |
-
1994
- 1994-09-08 SE SE9402986A patent/SE515815C2/sv not_active IP Right Cessation
-
1995
- 1995-09-04 EP EP95931484A patent/EP0780041B1/en not_active Expired - Lifetime
- 1995-09-04 DE DE69534446T patent/DE69534446D1/de not_active Expired - Lifetime
- 1995-09-04 WO PCT/SE1995/000989 patent/WO1996008099A2/en active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
EP0780041B1 (en) | 2005-09-14 |
WO1996008099A2 (en) | 1996-03-14 |
SE9402986L (sv) | 1996-03-09 |
WO1996008099A3 (en) | 1996-05-02 |
SE9402986D0 (sv) | 1994-09-08 |
EP0780041A2 (en) | 1997-06-25 |
DE69534446D1 (de) | 2005-10-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6208649B1 (en) | Derived VLAN mapping technique | |
US5940396A (en) | Method of routing in an asynchronous transfer mode network | |
US6553028B1 (en) | Method and apparatus for multicast switching using a centralized switching engine | |
CA2231758C (en) | Improved system for routing packet switched traffic | |
US8077732B2 (en) | Techniques for inserting internet protocol services in a broadband access network | |
US6775706B1 (en) | Multi-protocol switching system, line interface and multi-protocol processing device | |
Truong et al. | LAN Emulation on an ATM Network | |
US6608817B1 (en) | Method and apparatus for connection-oriented multiplexing and switching network analysis, management, and troubleshooting | |
SE504766C2 (sv) | Arrangemang för att tillhandahålla lokalnätsemuleringstjänst över publikt förbindelselöst ATM-nät | |
US6885677B1 (en) | Multiprotocol label switching routers | |
US6189041B1 (en) | Next hop resolution protocol cut-through to LANs | |
GB2269724A (en) | ATM Network addressing | |
SE515815C2 (sv) | Anordning vid ATM-nät | |
Cisco | ||
Cisco | ||
Cisco | ||
Cisco | ||
Cisco | ||
Cisco | ||
Cisco | ||
US20040062251A1 (en) | Method and apparatus for forwarding of telecommunications traffic | |
Cisco | Configuring Transparent Bridging | |
Cisco | Advanced Cisco Router Configuration Internetwork Operating System Release 10.2 | |
Cisco | Overview of Bridging | |
Cisco | I |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
NUG | Patent has lapsed |