TECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER ELEKTROTECHNIEK

TECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER ELEKTROTECHNIEK VAKGROEP Digitale Systemen LAN-interconnectie door middel van de ISDN frame-relaying bearer service, door A.J.F. van Halderen. Verslag van een afstudeerproject dat uitgevoerd is bij het PTr Research Neher Laboratriwn in Leidschendam, in de periode juli 1989 tot april 1990. Afstudeerhoogleraar: Begeleiders: prof. ir. M.P.J. Stevens. ir. M.J.M. van Weert (TUB), ir. J. Konuner (RNL). Leidschendam, 3 mei 1990. De faculteit Elektrotecbniek van de Techniscbe Universiteit Eindhoven aanvaardt geen aansprakelijkbeid voor de inboud van stage- en afstudeerverslagen.

Samenvatting Samenvatting _ Inhet kader van een afstudeeropdracht over modellen voor netwerkinterworking heeft een studie plaatsgevonden naar interconnectie van IEEE 802 type LAN's met behulp van de nieuwe in het ISDN onder te brengen frame-relay service. De frame-relaying bearer service is een aanvulling op de reeds bestaande circuit-switcheden packet-switched-bearer services in het ISDN. De frame-relaying techniek zorgt voor het transporteren van laag 2 frames met zo min mogelijk overhead binnen het ISDN: functies ten behoeve van bijvoorbeeld fout-herstel en flow control zijn hierbij vanuit het ISDN naar de eindgebruikers verschoven. De benodigde verbinding kan op elk, van de in het ISDN gedefmieerde kanalen gerealiseerd worden. Om dit alles mogelijk te maken heeft men op de ISDN laag 2 en 3 protocollen (resp. Q.921 en Q.931) een uitbreiding gemaakt; resp. Q.922 en Q.93X. De interconnectie van IEEE 802 LAN's met de ISDN frame-relaying service is aan de hand van drie verschillende scenario's bestudeerd. In de scenario's vindt de daadwerkelijke LAN/ISDN koppeling plaats met behulp van verschillende router!bridge combinaties. Modelmatig ontmoet men bij de genoemde koppeling twee fundamentele spanningsvelden, namelijk een CO/CL-barriere en het feit er in het ISDN, in tegenstelling tot LAN's, een strikte scheiding bestaat in besturing- en datatransfer-functies (en protocollen). Voor beide problemen worden oplossingen aangedragen. De in elit verslag uitgewerkte scenario's tonen aan dat LAN-interconneetie d.m.v. framerelaying technisch goed mogelijk is. Frame relaying is een universele en snelle techniek voor de overdracht van data. Verder is geconcludeerd dat frame-relaying beter past in de structuur van het ISDN dan X.25-services.

Inhoudsopgave III Inhoudso~_av_e _ 1 Inleiding 1 2 Interworking van netwerken 3 2.1 CO (Connection Oriented): WAN's 3 2.1.1 Toepassingen 4 2.1.2 co: protocol-stack 4 2.1.3 Transportklasse 5 2.2 CL (Connection-less): LAN's 5 2.2.1 CL: protocol-stack 6 2.2.2 Transportklasse 6 2.3 Uitzondering: CO-lAN's 7 2.4 Transportklasse; een secundaire hindernis 7 2.5 Netwerk koppelingen 7 2.5.1 LAN WAN LAN, de in te vullen interworking case 8 2.5.2 LAN WAN, een variant 8 2.5.3 Meer complexe configuraties 9 2.6 Interworkings-mogelijkheden in OSI 9 2.6.1 Repeater: IWU op laag 1 9 2.6.2 Bridge: IWU op laag 2 10 2.6.3 Router: IWU op laag 3 11 2.6.4 Gateway: IWU op laag 7 12 2.7 Interworking in de LAN-WAN-LAN-configuratie 13 2.7.1 Methode 1:.en verbinding per datagram 14 2.7.2 Methode 2: timers 15 2.7.3 Methode 3: convergence-protocollen 16 2.7.4 Methode 4: toepassen van laag 4 informatie 16 2.8 Call Control: BinneniBuiten de Band 17 2.9 LAN-interconnectie m.b.v. frame-relaying 18 3 Introductie 19 3.1 Frame-relaying in ISDN 19 3.1.1 Data Transfer bij frame-relaying: het user-plane 19 3.12 Call Control: de gebruikte protocollen 21 3.1.3 Netwerk configuratie: CASE A & CASE B 22

Iv Inhoudsopgave 3.2 LAN's 24 3.2.1 LAN-interconnectie m.b.v. frame-relay 24 3.2.2 Call Control bij het LAN 25 3.3 Een concrete interworking-situatie 26 3.3.1 Model-matige aspecten 26 3.32 Protocol-stacks 27 3.3.3 Afspraak 28 3.4 Uitwerking 29 4 De protocollen binnen het LAN 31 4.1 De relatie tussen POU's, SOU's etc. 31 4.2 CL-netwerk protocol ISO 8473 31 4.2.1 Globale beschrijving van het 8473 protocol 32 4.2.2 De communicatie met de andere lagen 37 4.2.3 Structuur van N PDU's 38 4.2.4 Sub Network service 39 4.3 Logical Link Control (LLC) 40 4.3.1 llc-typen: llc 1 3 40 4.3.2 llc 1 41 4.3.3 POU-structuur 43 4.3.4 LLC 2 & 3 45 5 ISDN-protocollen 47 5.1 ISDN laag-3 protocol(len): 0.931 & 0.93X 47 5.1.1 0.931 47 5.1.2 Enkele kenmerken 48 5.1.3 0.93X: een variant t.b.v. frame-relaying 52 5.2 ISDN Laag-2 protoco/(ien): 0.921 & 0.922 53 5.2.1 LAPO; globale beschrijving 54 5.2.2 De geboden service 56 5.2.3 Frame-structuur 56 5.2.4 0.922 57 6 Frame relay connecties via een ISDN B-kanaal 59 6.1 De signaleringsweg 59 6.1.1 Message-flow van O.93X messages 60 6.2 Opzetten van een Frame-relay connectie 62 6.3 Setup procedure aan de A-zijde 64 6.3.1 Het 0.931 SETUP bericht 64 6.32 Reaelie op het SETUP-bericht 78 6.3.3 CAll-PROCEEDING aan A-zijde 80 6.3.4 CONNECT, aan A-zijde 81 6.4 Data Transfer fase 83

Inhoudsopgave v 6.5 Setup-procedure aan de B-zijde 84 6.5.1 Het SETUP-bericht aan de B-zijde 84 6.5.2 Reactie aan B-zijde op het SETUP-bericht 87 6.5.3 CALL PROCEEDING aan B-zijde 88 6.5.4 CONNECT aan B-zijde 89 6.6 Release procedure aan A- en B-zijde 90 7 Interworking scenario's 91 7.1 Aigemeen 91 7.1.1 Interworking symboliek 91 7.1.2 PDU's t Frames/Packets 92 7.1.3 Afmetingen van Datavelden 92 7.1.4 Adressering binnen het LAN 96 7.1.5 CO/CL - barriere 98 7.1.6 Signalering in het ISDN 99 7.2 Scenario 1 99 7.2.1 Algemene aspecten van scenario 1 100 7.2.2 Verwerking van uitgaande frames 103 7.2.3 Verwerking van inkomende berichten 106 7.3 Scenario 2 109 7.3.1 Globale werking van scenario 2 109 7.3.2 Actieve toestand: in- en uitgaande frames 112 7.3.3 Rust toestand 114 7.4 Scenario 3 115 7.4.1 Globale werking van scenario 3 116 7.4.2 Actieve toestand 119 7.4.3 Rust toestand 123 7.5 Resume van de algemene kenmerken 125 7.5.1 Tabel. en het filtermechanisme 125 7.5.2 Adressering 125 7.5.3 Flow-control 126 7.5.4 Transport protocol 126 7.5.5 CO/CL-probleem 126 7.5.6 Signalering: Binnen- of Buiten de Band 127 7.5.7 Frame-size 127 8 Conclusies 129 8.1 Mechanismen van interworking 129 8.1.1 (Netwerk)-adressen: Liefst universeel, b.v. NSAP-adressen 129 8.1.2 Frame-Iengte 129 8.1.3 Flow-control: bij CL-netten moeilijk of zelfs onmogelijk 130 8.1.4 Elnd- & Intermediatie systemen 130 8.1.5 CO/CL-interworkingsprobleem: Goed oplosbaar 131 8.2 Modelmatige samenwerking (LAN-ISDN) 131

vi Inhoudsopgave 8.3 Beoordeling van de scenario's 131 8.3.1 Aigemeen; voor aile scenario's 132 8.3.2 Voor- en nadelen maken de scenario's situatiespecifiek 133 8.4 ISDN frame-relaying 134 Literatuurlijst Afkortingen 135 139 ~endices A De ISO CO/CL "IFU" A.1 A.2 A.3 A.4 A.5 A.6 A.7 IFU werkingsmodi A.1.1 Aktieve Transport Laag Relay (ATLR) A.1.2 A.1.3 Passieve Transport Laag Relay (PTLR) Network Layer Relay (NLR) De IFU in de OSI Netwerk omgeving A.2.1 Adressering: NSAP en TSAP adressen A.2.2 A.2.3 Selectie van de werkingsmode Het gebruik van Netwerk adressen Netwerk-configuratie en routering A.3.1 Adressering bij systemen met meerdere IFU's A.3.2 A.3.3 A.3.4 Data Unit Identifiers Transport references Voorkeur voor de te gebruiken IFU Aktieve Transport Laag Relay A.4.1 A.4.2 A.4.3 De opbouw van de ATLR Functies binnen de IFU-netwerklaag Functies binnen de IFU-transportlaag Passieve Transport Laag Relay A.5.1 De opbouw van de PTLR A.52 De netwerklaag van een PTLR A.5.3 Het Transport Relay Part Werkingsmode selectie A.6.1 A.6.2 Security Selectie, ontvangst van pakketten uit CL-zijde Selectie, bij pakketten vanuit de CO-zijde A.7.1 Totale encryptie van TPDU's A.72 Gedeeltelijke encryptie van TPDU's B Transport "Classes" B.1 Class 0: "Simple Class" B.2 Class 1: "Basic Error Recovery Class" B.3 Class 2: "Multiplexing Class" 143 144 144 144 145 145 145 146 146 147 147 147 148 148 149 149 150 150 155 155 156 157 160 160 161 163 163 163 165 165 165 166

Inhoudsopgave vii B.4 Class 3: "Error Recovery and Multiplexing" B.5 Class 4: "Error Detection and Recovery Class" B.6 Overzicht van TPO tim TP4 C OSI Netwerklaag C.1 "Sublayers" C.2 Toepassing D Protocollen binnen OSI E Appendix bij ISO 8473 E.1 Structuur en encoding van de PDU's E.1.1 E.1.2 E.1.3 E.1.4 E.1.5 E.1.6 E.1.7 E.1.8 Fixed part Address part Segmentation part Options part Data part Data (DT) PDU Error Report PDU Inactive Network Layer Protocol 166 166 167 169 169 169 171 173 173 174 176 177 177 181 181 181 182

Inleiding 1 Irlleiding In het kader van een afstudeeropdracht over modellen voor netwerk-intelworking is aan de hand van een fictieve LAN-WAN interconnectiesituatie onderzoek gedaan naar samenwerking van zeer verschillende architecturen. Deze verschillen veroorzaken een aantal hindernissen die interconnectie bemoeilijken. Een van die hindernissen is het zogenaamde Connection Oriented/Connection-Less interworkingprobleem. Wide Area Networks (zoals het in ontwikkeling zijnde ISDN) zijn over het algemeen Connection Oriented, terwijl LAN's vrijwel altijd Connectionless zijn. De uitwerking van de afstudeeropdracht is o.a. gestart met het bestuderen van algemene, binnen het OSI-model toelaatbare, koppelingsmogelijkheden van netwerken. Verder is aandacht besteed aan het eerder genoemde CO/CL-intelWorkingsprobleem, en aantal mogelijke oplossingen daarvoor. Deze studie heeft geleid tot een publicatie in de vonn van een RNL-rapport, waarin naast het bovenstaande tevens een beschrijving is opgenomen van een universele IntelWorkings Unit die binnen ISO in ontwikkeling is. [Rapport 842 RNL/89] Een bewerking van de inhoud van dat rapport is in dit verslag opgenomen (zie hoofdstuk 2 en de appendices A tim D). Het vervolg van het onderzoek heeft plaats gevonden aan de hand van de eerder genoemde fictieve LAN-WAN interconnectie situatie, waarbij twee gelijksoortige Local Area Networks met elkaar gekoppeld worden d.m.v. van de in ontwikkeling zijnde frame-relaying techniek in ISDN. Frame-relaying is gebaseerd op het met zo minmogelijke functionaliteit in het transmissienetwerk transporteren van laag-2 frames, waardoor het universeel en snel is. Deze intelwoikingssituatie is aan de hand vaneendrietalmogelijke oplossingen(scenario's genoemd) nader uitgewerkt. Deze scenario's onderscheiden zich door verschillen in de toepassing van algemene intelworkingsprincipes zoals die in hoofdstuk 2 van dit verslag beschreven worden. Ben "nieuw" probleem daarbij is het feit dat het ISDN, in tegenstelling tot LAN's van gescheiden transmissiewegen en protocol-functionaliteiten gebruik maakt voor user-data en signalering (control). Dit fenomeen wordt aangeduid als resp. "Buiten de Band" en "Binnen de Band" call control.

2 /n/eiding In dit verslag voigt een beschrijving van de eerder genoemde scenario's voor LAN-intercormectie. Verder wordt ingegaan op de nieuwe frame-relaying techniek, en de wijzigingen/aanvullingen die daarvoor in de bestaande ISDN laag 2 en 3 protocollen noodzakelijk zijn. Ook wordt de opbouw van de LAN's waarvan de intercormectie bestudeerd is beschreven.

CO (Connection Oriented): WAN's 3 Interworking van netwerken Tegenwoordig bestaan er in de wereld twee verschillende groepen dataconununicatie netwerken. Een daarvan is ontstaan uit de telecommunicatie wereid en bestaat uit diverse openbare netten voor spraak- en data-overdracht, welke veelal door nationale PTT's beheerd worden. Vanwege de omvang van ervan worden deze netten vaak als "Wide Area Networks" (WAN's) aangeduid, een voorbeeld is het ISDN. De andere groep, die ontstaan is uit de computerwereld, bestaat uit de datacommunicatienetten die toegepast worden in bedrijven voor communicatie tussen computer-apparatuur): LAN's (Local Area Networks). Zoals de term LAN reeds aangeeft heeft dit type netwerk slechts een lokale omvang. Bij het koppelen van netwerken uit deze twee groepen stuit op een aantal problemen die hun oorsprong vinden in de afwijkende protocol-architecturen van LAN's en WAN's. Protocollen van een WAN zijn (over het algemeen) Connection Oriented, terwijl in LAN's meestal van Connection Less protocollen gebruik gemaakt wordt. 2.1 CO (Connection Oriented): WAN's De conununicatie-protocollen binnen een connection-oriented netwerk hebben als gemeenschappelijke eigenschap dat er eerst een connectie moet worden opgebouwd met de opponent voordat er sprake kan zijn van dataoverdracht. Zo'n connection is in pakketnetwerken op basis van X.25 geen fysieke (vaste) verbinding, maar een vinuele verbinding. 1 Bij X.25 netwerken wordt aan beide zijden van een verbinding een kenmerk (= nummer v/d vinuele verbinding) gereserveerd dat in elk bijbehorend pakket wordt opgenomen. Het proces van dataoverdracht in connection-oriented netwerken vindt in vier fasen plaats. Vanuit de rusnoestand, Idle, komt het oproepende systeem in de establishment phase. In die fase zet het systeem een vinuele verbinding op met het bestemmings eind-systeem. Vervolgens kan de uiteindelijke datauitwisseling aanvangen in de data exchange phase. Tenslotte komen beide betrokken eind-systemen na de release phase weer in de rusnoestand (=idle). 1 Zowel ISO als CCITI bebben een CO OSI-netwerkservice gespecificeerd.

4 Interworlcing van netwerken Hoofdstuk2 Infeite kent zo'n systeemtwee verschillende (stabiele) toestanden waarin het kan verkeren, namelijk een rusttoestand (idle) en de data-overdracht toestand (data exchange phase). Tussen die twee toestanden zijn de eerder genoemde overgangen mogelijk; het opbouwen van een colulectie (establishment phase), enhet weerverbreken ervan (release phase). De uiteindelijke dataoverdracht vindt plaats vanuit dedata Exchange toestand. Zie figuur 2.1 1dI. Figuur 2.1: Toestandsdiagram van CO-systemen 2.1.1 Toepassingen CO-protocollen vinden binnen het OSI-model hun toepassing in de openbare netten (laag 1 tim 3) zoals het PSPDN (Packet Switched Public Data Network), CSPDN (Circuit Switched Public Data Network) en het ISDN (Integrated Services Digital Network). De transportlaag (laag 4) biedt aan zijn gebruikers altijd een CO-transportservice (Er is in het OSI-model ook een CL-transportservice gedefmieerd, hiervan wordt tot nu toe echter door geen enkele laag 5 entiteit gebruik gemaakt). De huidige invullingen van de lagen 5 tim 7 zijn alle CO. 2.1.2 CO: protocol-stack De ISDN laag 2 en 3 protocollen zijn Connection Oriented. Een ander voorbeeld van een CO-protocol is het X.25 PLP (Packet Level Protocol). Men komt dit tegen in het PSPDN (b.v.: DATANET-l), en als bearer-service in ISDN. In deze gevallen zijn de onderste 4 lagen van bet OSI-model op onderstaande wijze ingevuld. 4 3.. X.ZZ4 ISO 11073 x.a Pl.P 1S01lZ08 X.ZZ4. ISO 1073 x.a x.a 1 PLP PLP 1.451 2 x.a LAPS X.Z5 1.441 LAPS 1 PSPDN X.Zl X.Zl,. ISDN 1.430 Figuur 2.2: Protocol-stack voor Co-omgeving

CL (Connection-less): LAN's Transportklasse 5 Hierin valt op dat het laag-4 protocol zowel voor PSPDN als voor ISDN hetzelfde is (X.224=ISO 8073). Verder blijkt dat er op laag 3 verschillende protocollen gebruikt worden, echter binnen ISDN wordt X.25 PLP als bearer-service ondersteund. Hierdoor kan de netwerkservice van het PSPDN en het ISDN in de praktijk als gelijkwaardig worden beschouwd. 2.1.3 Transportklasse Het is van belang om te weten dat er een aantal varianten bestaan van het transportlaag protocol zoals dat gedefmieerd is in ISO 8073 = X.224. Dit protocol is in staat om 5 verschillende services te verlenen, deze worden transportklassen genoemd (TPO timtp4). 2 In de CO-omgeving worden de volgende transportklassen toegepast: TPO en TP2. Het gebruik van de overige transportklassen is bier ook mogelijk, maar ligt niet erg voor de hand: X.25 is dusdanig betrouwbaar dat meer transportfunctionaliteit onnodig is. 2.2 CL (Connection-less): LAN's Connection-less netwerkprotocollen, zoals binnen LAN's gebruikt worden, hebben als gemeenschappelijk kenmerk dat het voor het overdragen van data niet nodig is om eerst een verbinding (connectie) op te opbouwen tussen de betreffende systemen. Bij CL-systemen wordt de over te dragen informatie in de vorm van afzonderlijke berichten (pakketten), die allemaal voorzien zijn van het adres van de gewenste bestemming, het netwerk "opgestuurd" zonder dat er eerst een verbinding is opgebouwd. Het CL-netwerk zorgt dan vervolgens zelf voor het afleveren van die berichten bij de ontvanger, waarbij voor elk pakket opnieuw een (eventueel andere) route bepaald wordt (doorhet netwerk). Daarnaast is het in principe voor een zender niet bekend of de verzonden pakketten ook werkelijk aankomen, al dan niet in de juiste volgorde. Deze problemen moeten, indien gewenst, door het transportprotocol worden opgelost. In feite kent een CL-systeem 3 slechts ~~n toestand, namelijk idle (mits men het wel- ofniet bestaan van een vaste (eventueel virtuele) connectie daarvoor als criterium neemt). Het verzenden, ofontvangen vaneenpakket vindt dan in de (niet-stabiele) data exchangephase plaats. Zie figuur 23.. 2 Zie voor meer informatie over bet begrip transportklasse Appendix F 3 AIleen ISO beeft een CL-netwerkservice gespecificeerd. Waarschijnlijk zal CCI1T in de buidige studieperiode deze CL-netwerkselVice ovememen.

6 Interworking van netwerken Hoofdstuk2 Idle Data Exchange Figuur 2.3: Toestanden binnen een CL-systeem 2.2.1 CL: protocol-stack Wat betreft protocol-stack's van CL-systemen zijn die van LAN's het bekenste. Er zijn een aantal varianten, die onderling een vrij grote mate van overeenkomst hebben. Zo is bijvoorbeeld het binnen OSI gestandaardiseerde CL-netwerkprotocol ISO 8473 gebaseerd op het zogenaamde Internet Protocol (IP). 4 rcp ISO B073/AD2 (CLASS 4) 3 IP IsOIU73 2 LiC' & MAC LiC' & MAC niet OSI OS/ Figuur 2.4: Protocol-stack voor CL-omgeving LLC (Logical Link Control) & MAC (Medium Access Control) zijn beschreven in de groep IEEE 802 Local Area Network specificaties, die door ISO zijn overgenomen in de ISO 8802 serie. Hierin geeft ISO 8802/2 onder meer de definitie voor het LLC 1, en wordt hetmacgedeelte in ISO 8802/3 tim ISO 8802/6 gespecificeerd (Deze staan respectievelijk voor "CSMA/CD", "Token Bus", "Token Ring" en recentelijk "DQDB"). 2.2.2 Transportklasse In verband met de geringere betrouwbaarheid van de CL-netwerkprotocollen dient er op de transponlaag in CL-systemen gebruik gemaakt te worden van transportklasse 4, welke als enige transport-protocol variant uitgebreide fout-deteetie en herstel faciliteiten in zich herbergt.

Uitzondering: CO-LAN's Transportklasse 7 2.3 Uitzondering_:...:...C_O_ L_A_N_'...:..,.s _ Het is mogelijk omhet X.25 PLPbinnen een LAN toe te passen opde netwerklaag (volgens ISO 8881) waardoor ereen CO-netwerkservice geboden wordt opeen LAN, zie figuur 2.5. 4 150'073 3 2 X.25PLP -.J:Q./. LLC & MAC Figuur 2.5: Protocol-stack voor CO-LAN (met X.25 PLP) 2.4 Transportklasse; een secundaire hindernis Naast het eerder genoemde CO/CL-interworking probleem (dat zich met name op de netwerklaag binnen de structuur van het OSI-model voordoet) bestaat er in de praktijk nog een tweede hindernis bij koppeling van netwerken, welke (zoals later zal blijken) min of meer gerelateerd is aan het CO/CL-probleem. Op de Transportlaag is inuners een Transport-protocol in gebruik dat een aantal varianten kent die niet compatibel zijn met elkaar: de zogenaamde transportklasse (Zie Appendix B). Indien er binnen een systeemtransponklasse 4 (TP4) gei:mplementeerd is, dan behoren ook TP2 en TPO ondersteund te worden. Hetzelfde geldt vooreen systeem dattp2gebruikt; dit dient ook met TPO te kunnen werken. Hieruit zou men kunnen concluderen dat er bij koppe1ing van "TP4-systemen" (LAN's) met "TPO-systemen" (WAN's) geen prob1emen zijn want de LAN'skunnen ooktpo ondersteunenzodat samenwerkingop basis vantpo mogelijk lijkt. Echter de binnen LAN's gebruikte CL-netwerkservices vereisen toepassing van een betrouwbare transportservice, welke alleen met behulp van transportklasse 4 geboden kan worden, zodat het degraderen van TP4 naar TPO geen goede oplossing is. Het is dus mogelijk, dat naoplossing van het CO/CL-interworkings probleem, ernog steeds geen communicatie mogelijk blijkt tussen de twee betrokken systemen als gevolg van het gebruik van verschillende transportklassen. De Interworking Unit (IWU) die het CO/CL probleem oplost zal dus tevens, indien nodig, een conversie faciliteit moeten bieden voor het converteren tussen de verschillende transportklassen. Zie Appendix A. 2.5 Netwerk ko~_e_li_n.ae_ge_n _ Bij koppeling van LAN's (CL) en met WAN's (CO) stuit men op een CO/CL-interworkingsprobleem. Het overwinnen daarvan is mogelijk door het inzetten van interworkingunits (IWU's) die voor de nodige conversie kunnen zorgen tussen CO- en CL-protocollen.

8 Interworking van netwerken Hoofdstuk2 Daarnaast kan een IWU, indien noodzakelijk, tevens zorgen voor conversie van adresseringsinfonnatie. Afhankelijk van de gewenste interworking tussen CO- en CL-netwerken (zoals LAN's en WAN's) zijn een aantal configuraties mogelijk. In deze paragraaf worden daarvan twee voorbeelden gegeven. 2.5.1 LAN-WAN-LAN, de in te vullen interworking case Bij de LAN-WAN-LAN configuratie, waarin twee gescheiden LAN's met elkaar gekoppeld worden via een openbare (data)net, is sprake van interworking tussen drie afzonderlijke netwerken (2 LAN's en een openbaar (data)net). Voor de realisatie daarvan zijn, zoals duidelijk zal zijn, twee Interworking-Units (IWU's) noodzakelijk, zie figuur 2.7. A -EJ_ --~_'" r_.ej-.--f B Figuur 2.7: LAN-WAN-LAN interworking Een specifieke koppelingsituatie, en de functionaliteiten die daarvoor in de IWU's noodzakeiijk zijn, is door bovenstaande figuur nog niet eenduidig bepaald. Van invioed is name;uijk het feit ofde beide LAN's wei ofniet van hetzelfde type zijn. In het eerste geval is de functionaliteit van de IWU's beperkt tot de conversie van het LAN naar het WAN, en omgekeerd, terwiji er in het tweede geval tevens een conversie tussen de twee LAN-types moet plaats vinden. De eerste situatie (twee identieke LAN's) wordt in het kader van dit verslag verder ingevuld, en vervolgens bestudeerd. 2.5.2 LAN-WAN, een variant Eenvoudiger lijkt het als erslechts een koppeling gewenst is tussen een LAN en een WAN; eris dan inuners slechts een interworking unit nodig. -EJ---...-1' Figuur 2.6: LAN-WAN interworking

Interworkings-mogelijkheden in OSI Meer complexe configuraties 9 Dit kan bijvoorbeeld bet gevai zijn voor bet raadplegen van gegevens uit een databank welke gerntegreerd is binnen bet WAN; zoais een "008" databank. Daar staat echter tegenover dat er bij zo'n configuratie een conversie van alle functionaliteiten tussen het LAN en WAN noodzaklijk is, hetgeen over het algemeen een complexe IWU vereist. 2.5.3 Meer complexe configuraties Tenslotte zijn er meer complexe configuraties denkbaar met vele koppelingen van LAN's met WAN's, waarbij zich dan telkens het CO/CL-interworkingsprobleem voordoet, hetgeen zalleiden tot het in serie- ofparallel schakelen van een bepaald aantal IWU's. Bij het ontwerpen van Interworking Units zal hiermee dus rekening gehouden moeten worden. In het kader van de afstudeeropdracht wordt echter de configuratie in figuur 2.7 als uitgangspunt genomen. is 2.6 Interworkings-mogelijkheden in 081 Binnen de structuur van het OSI-model heeft men een aantal mogelijkheden voor interworking (tussen OSI-systemen) gedefmieerd. Een belangrijke voorwaarde daarbij is dat communicatie tussen OSI-eind-systemen op het niveau van de transportlaag altijd "endto-end" moet zijn. Dit betekent dat er op de weg tussen twee eind-systemen op de transportlaag geen interworking units (IWU) mogen voorkomen. Het gevolg daarvan is dat men interworking toestaat op de onderste drie lagen van het model, voor de hogere lagen wordt interworking slechts op laag 7 (applicatie-laag) toegestaan. Hieronder voigt een kort overzicht van de mogelijkheden voor interworking (door middel van IWU's) tussen netwerken in het algemeen binnen de structuur van het OSI-model. Hierbij komt men 4 verschillende oplossingen tegen: Repeater, Bridge, Router en een Gateway. 2.6.1 Repeater: IWU op laag 1 Ben repeater is een apparaat dat signalen ontvangt en deze vervolgens versterkt/hersteld doorgeeft. Het kan bijvoorbeeld gebruikt worden voor het koppelen van LAN's van hetzelfde type op het niveau van de fysieke laag, en voor het verlengen van kabels. De werking ervan behoort volledig transparant te zijn: een repeater relayeert signalen zonder naar de inhoud te kijken. Het zal duidelijk zijn dat een repeater geen oplossing voor het CO/CL-probleem kan bieden; dit speelt zich immers o.a. op laag 3 af.

10 Interworl<ing van netwerken Hoofdstuk2 Applicatie Presentatie Sessie Transport N9tw9rlc -~- I- Applicatie Presentatie Sessie Transport Nfltwerlc Data Link Data Link FysifJl< IFy~9p9B~fJI< I FysifJl< r r r r Figuur 2.8: Koppeling door middel van een repeater 2.6.2 Bridge: IWU op laag 2 Bridges zijn in staat om LAN's met elkaar te verbinden op het niveau van de data link laag. Een bridge 4 observeert aile verkeer op de twee netten welke hij met elkaar verbindt. Applicatie PrflSentatie SflSsie Transport N9twerlc Applicatie Presentatie Sessie Transport Netwerlc Data Link ~ridg~ Data Link D.Link D.Unk FysifJl< FysifJl< I FysifJl< FysifJl< r r r r Figuur 2.9: Koppeling door middel van een bridge Aan de hand van de MAC-adressen (source en destination) in de ontvangen pakketten, en een eigen lookup-table, kan een bridge bepalen van welk subnet een bepaald pakket atkomstig is, en voor welk: subnet het bedoeld is. AIle pakketten die hun bestemming op hetzelfde subnetwerk (= het subnetwerk waarvan het afkomstig was) vinden worden door 4 NB.: Ret betreft bier een zogenaamde transparante bridge of "spanning tree bridge". Oit type heeft voor bet routeren van pakketten geen speciale routeringsinfonnatie nodig (naast de nonnale MAC-adressen). Dit in tegenstelling tot de "Source Routing Bridge", welke voor bet routeren gebruik maaktvanin de pakkettenaangegevenroutes. Zievoormeerinfonnatie: Verslag27 RNU89, H.5.3.3.

Interworkings-mogelijkheden in OSI Router: IWU op Issg 3 11 de bridge niet doorgegeven naar het andere netwerk (het betreffende pakket kan irnmers zonder tussenkomst van een bridge zijn bestemming bereiken).5 De overige pakkenen worden wei doorgegeven aan het andere subnetwerk waardoor ze de gewenste bestemming binnen dat subnetwerk kunnen bereiken, of eventueel een bestemming op een ander subnetwerk, na te zijn doorgegeven door een tweede bridge. Het is dus mogelijk om een aantal LAN'smet elkaarte verbindenmetbehulp vanmeerdere bridges, waarbij menechter wei met speciale protocolaire maatregelen moet waken voor eventuele Iussen in de configuratie, waardoor pakkenen langdurig zouden kunnen rondcirkelen (zonder ooit bij zijn bestemming te arriveren). Aan de hand van de adresseringsinformatie in de pakkenen zijn bridges bovendien in staat omzelfstandig deeerder genoemde lookup-table inte vullen, waardoor ze zich automatisch aanpassen aan wijzigingen in de aangesloten subnetwerken. Samenvanendkan men het bovenstaande proces omschrijven als het selectiefdoorgegeven van pakkenen: na fjltering van pakkenen die zich reeds op het bestemmingssubnetwerk bevinden wordt de rest doorgegeven. Naast het selectiefdoorgegeven van pakkenen zijn bridges in staat om subnetwerken met verschillende laag 1 en laag 2 invullingen, of met verschillende MAC-laag, met elkaar te laten samenwerken. Ben bridge zorgt dan voor de nodige conversie zoals het conveneren van bijvoorbeeld een Ethernet- naar een Token-ring pakket, en omgekeerd. Aangezien bridges slechts tot op laag 2 actief zijn maakt het voor het gebruik ervan niet uit welke protocollen erop laag 3 tim 7 gebruikt worden. Dit houdt o.a. in dat ze niet instaat zijn om het CO/CL-probleem dat zich op de netwerklaag voordoet op te lossen. Tenslone dient nog vermeldt te worden dat er naast "gewone" bridges voor het direct' koppelen van LAN's ook bridges bestaan voor het koppelen van twee LAN's die zich op enige afstand van elkaar bevinden. Indat geval neemt men in beide LAN'seen zogenaamde remote bridge op, welke via een verbindingskabel met elkaar verbonden worden. (Die verbindingskabel zou eventueel ook een X.25 Permanent Virtual Circuit, of een huurlijn in het algemeen, kunnen zijn). Note: Merk op dat bij bridges al in grote mate sprake is van networking functionaliteit (In de zin van routering/adresserings-functies). 2.6.3 Router: IWU op laag 3 Ben router (wordt soms ook wei aangeduid als "relay") verbindt twee subnetwerken met elkaar op bet niveau van de netwerklaag. De netwerklaag is speciaal voor netwerking ontworpen, zodat daarbinnen "automatisch" informatie voor routering en flowcontrol heschikbaar is. Dit geeft een router de mogelijkheid om mede de heste route te bepalen voor pakketten. Daarnaast kunnen netwerken met afwijkende nummer-domeinen met bebulp van een router met elkaar gekoppeld worden. 5 In ringvonnige LAN's (bv. token-ring LAN's) worden deze pakketten uiteraard door de bridge op de oorspronkelijke ring doorgegeven.

12 Interworking van netwer#<en Hoofdstuk2 Applicatie Presentatie f---~---- -- Sessie Transport Applicstie Presentstie Sessie Transport Nfllwerl< ~ut~ Netwerl< NfltWerl< NfltWerl< DatB Link -- Data Link Data Link Data Link Fysiel< Fysiek Fysiek Fysiek r r r r Figuur 2.10: Koppeling door middel van een router Een andere belangrijke mogelijkheid die een router, in tegenstelling tot een bridge of repeater, heeft is het segmenteren van pakketten, waardoor bijvoorbeeld LAN's met afwijkende maximale pakket afmetingen toch data kunnen uitwisselen. De afmetingen van MAC-laag-pakketten zijn narnenlijk gelimiteerd, en per type LAN verschillend. Ben LAN-station is niet in staat om pakketten te verwerken waarvan de afmeting groter is dan de limiet. Segmentering van pakketten zorgt ervoor dat deze maximale afmetingen niet overschreden worden wanneer er te lange pakketten vanuit een ander LAN aankomen, zodat interworking toch mogelijk is. Aangezien het CO/CL-interworkings probleem zich voordoet binnen de netwerklaag zou een router in staat moeten worden geacht om dit probleem op te lossen. In de volgende paragraaf zal echter blijken dat dit niet altijd zo is; soms is informatie uit de transportlaag noodzakelijk om CO/CL-interwoI'k.ing mogelijk te maken. 2.6.4 Gateway: IWU Op laag 7 De meest geavanceerde vorm van interworking die binnen het OSI-model toegestaan is, vindt plaats door rniddel van een gateway. Met de term gateway wordt hiereen interworking unit aangeduid die opereert ophet niveau van de applicatielaag (ofdaarboven). In feite fungeert het operatieve deel van een gateway (de eigenlijke "koppelaar" birmen laag 7) als een tolk tussen twee computer(applicaties) die verschillende "talen spreken". Een gateway is dan ook (in principe) in staat om twee zeer verschillende netwerken te laten samenwerken. Zo kan men bijvoorbeeld denken aan koppeling van een OSI-netwerk met een SNA-netwerk. Doordat eengateway verschillende applicaties met elkaartracht te laten samenwerken mag geconcludeerd worden dat het zeker het CO/CL-probleem (op de netwerk-laag) kan oplossen. Het zal duidelijk zijn dat dit wei een erg ingewikkelde oplossing is voor een probleem dat zich op laag 3 voordoet.

Interworking in de LAN-WAN-LAN-configuratie Gateway: IWU op lsag 7 13 Applicstie Presentatie Sessie APP~~i~ Presentatie Presentatie Sessie Sessie - Applicstie Presentatie Sessie Tf7Insport Netwerk Data Link Tf7Insport Netwerk Data Link Tf7Insport Netwerk Data Link -- f---- Tf7Insport Netwerk Data Link Fysiek L~ Fysiek J Fysiek L Fysiek ~_~J Figuur 2.11 : Koppeling door middel van een gateway 2.7 Interworking in de LAN-WAN-LAN-configuratie Zoals reeds in het voorgaande werd gesignaleerd, is interworking op netwerk niveau binnen de in figuur 2.7 gegeven configuratie niet zonder meer mogelijk vanwege de CO/CL-barriere die bestaat tussen LAN's en WAN's (op het niveau van laag 3). Oit probleem kan worden sarnengevat in figuur 3.7 (voor een WAN-LAN-koppelvlak), waarin aangegeven is dat het koppelen van een CO- met een CL-systeem neer komt op het "koppelen/converteren" van de afwijkende toestanden in de toestands-diagranunen. Belangrijk daarbij is het bepalen hoe de toestanden in het ene netwerk-type "gemapt" kunnen worden op mogelijke toestanden in het andere type. Voor het overdragen van een ofmeerdere pakketten tussen 2 LAN's (CL) via een WAN (CO) moet een verbinding worden opgebouwd binnen het WAN tussen de 2 betrokken IWU's. Een belangrijk probleem daarbij is de keuze van het tijdstip waarop die verbinding weer verbroken wordt, met andere worden; hoe kunnen de IWU's bepalen of er binnen zekere tijd nog meer pakketten zullen worden uitgewisseld zodat het wellicht verstandig kan zijn om een bepaalde tijd te wachten alvorens de verbinding te verbreken. Hieronder komen een aantal mogelijke oplossingen voor dat probleem aan de orde. Oeze zullen worden behandeld aan de hand van de eerder gegeven protocol-stacks en de configuratie in figuur 2.7 (LAN-WAN-LAN).

14 Interworking van netwerken Hoofdstuk2 Idle Figuur 2.12: Toestandsdiagrammen, interworking 2.7.1 Methode 1: een verbinding per datagram Een voor de hand liggende methode voor oplossing van CO/CL-probleem is het telkens opbouwen en weer verbreken van een verbinding tussen de twee IWU's via het WAN (CO-gedeelte), voor de overdracht van een datagram. 6 Een IWU dat een datagram ontvangt dat moet worden overgedragen naar het andere LAN zal dus een verbinding trachten op te bouwen via een WAN met een (remote) IWU die verbonden is met dat andere LAN, waarna het datagram naar die tweede IWU wordt verzonden, die het vervolgens zal doorgeven aan het gewenste LAN-station. Daarna verbreekt de eerste IWU de verbinding. Het ontstaan van de (instabiele) toestand Data Exchange binnen het eerste LAN (CL) leidt dus hier tot een reeks toestandsovergangen in het WAN (CO): vanuit Idle via de Establishment phase naar de (stabiele) toestand Data Exchange. Vanuit die situatie vindt overdracht van het betreffende datagram plaats naar de bestemming in het tweede LAN, dat daarvoor even in de (instabiele) Data Exchange-toestand komt. Na afloop van de dataoverdracht bevinden beide LAN's zich weer in de toestand Idle, en wordt het WAN ook in die toestand gebracht door de IWU's via een Release phase. Binnen X.25 is er een faciliteit aanwezig die het bovenstaande op eenvoudige wijze mogelijk maakt (mits de datagrammen niet te groot zijn): "Fast select with immediate clear". In pakketten die behoren bij een Fast Select procedure kan naast de gebruikelijke infonnatie die nodig is voor het opbouwen van een verbinding tevens maximaal 128 bytes aan user-dataworden ondergebracht. Zodat reeds tijdens de verbindingsopbouw in beperkte mate data-uitwisseling mogelijk is. Daarnaast is er een mogelijkheid om reeds in het 6 Bij CL-netwerken worden afzonderlijke pakketten vaak aangeduid met de term datagram. Aangezien er biereigenlijk sprake is van overdracht van pakketten atkomstig van een CL-netwerk wordt de term datagram bier oak in de CO-omgeving gebnlikt om aan te geven dat bet om dezelfde pakketten gaat.

Interworking in de LAN-WAN-LAN-configuratie Methode 2: timers 15 Call Request pakket van een Fast Select procedure aan te geven dat geen echte verbindingsopbouw gewenst is, maar dat deze direct weer verbroken moet worden. Dit laatste gebeurt dan door de ontvanger, die na ontvangst van het FS Incomming Call pakket een FS Clear Request pakket terug zendt (Bij een gewone FS-procedure, zonder immediate clear, antwoord de ontvanger met het zenden van een FS Call Accepted). 2.7.2 Methode 2: timers In de meeste praktijk gevallen zal het ongewenst zijn dat er voor elk transport van een datagram telkens een verbinding via het WAN wordt opgebouwd en vervolgens weer verbroken. Vooral indien er kort na elkaar meerdere datagrammen overgedragen moeten worden is het beter om een eenmaal opgebouwde verbinding (via het WAN) niet onrniddellijk weer te verbreken, maar te gebruiken voor het transport van een aantal opvolgende datagrammen. Het besluit tot het verbreken van de verbinding (door de IWU's) kan in zo 'n situatie genomen worden aan de hand van de tijd die verloopt na het laatst verzonden datagram. Pas na het overschrijden van een bepaalde maximale tijdsduur, gemeten door timers in de IWU's, zal de bestaande verbinding verbroken worden. Door het observeren van de feitelijke dataoverdracht zou een IWU, die bovenstaand principe hanteert, de zogenaamde drempeltijd kunnen optimaliseren, en aanpassen aan de momentane situatie. Het aantal keren dat een eenmaal opgebouwde verbinding verbroken wordt vlak voordat er zich een volgend datagram aandient (welke verzonden had kunnen worden via de zojuist verbroken verbinding) kan daarmee procentueel zo klein mogelijk gemaakt worden. Het zal duidelijk zijn dat het bovenstaande vereist dat een IWU kennis heeft over de geschiedenis van voorgaande connecties tussen de betrokken eind-systemen. Een IWU kan bijvoorbeeld een database aanleggen met statistische gegevens over oude connecties. Met het oog op de eerder gegeven toestandsdiagrammen betekent de bovenstaande oplossing dat er zich een aantal cycli (Idle en de instabiele toestand Data Exchange) voordoen binnen de LAN's alvorens het WAN van de (stabiele) toestand Data Exchange naar Idle over gaat: verbreken van de verbinding via het WAN (zie de toestands-overgangen in de vorige paragraaf). Ben mogelijke oplossing die veel gelijkenis vertoont met de vorige is het "opsparen" van een aantal over te dragen datagranunen in geheugens van IWU 1 alvorens deze daadwerkelijk, met behulp van een op te bouwen verbinding, via het WAN aan IWU 2 over te dragen. Het zal duidelijk zijn dat er bij zo'n methode wachnijden zullen ontstaan. hetgeen wellicht ongewenst is (of zelfs ontoelaatbaar voor de werking van de protocollen in de hogere lagen). Samenvanend kan men stellen dat de hierboven beschreven oplossingen. in vergelijking met die in de vorige paragraaf. als voordeel hebben dat het aantal malen dat een verbinding van het WAN wordt opgebouwd en verbroken sterk gereduceerd kan worden. hetgeen efficient gebruik: van WAN's ten goede komt. Ben nadeel is het feit dat de perfonnance wat betreft overdrachtstijd (of transmissie-delay) van pakkenen binnen het geheel van

16 Interworking van netwerken Hoofdstuk2 samenwerkende netwerken niet (exact) voorspelbaar is: opeenvolgende reeksen van pakketten kunnen gemiddeldperpakket snellergetransporteerd worden dan"losse"pakkenen. 2.7.3 Methode 3: convergence-protocollen Door gebruik te maken van convergence 7 protocollen is eveneens interworking mogelijk tussen LAN's en WAN's (zoals in de configuratie in figuur 2.7 ). Hierbij wordt gebruik gemaakt vande opdeling van de netwerklaag in drie sublagen, waarbij de bovenste sublaag met het betreffende convergence protocol gevuld is. Theoretisch kan men bijvoorbeeld denken aan het toepassen van het CL-netwerkprotocol ISO 8473 binnen het WAN, in de vorm van een Subnetwork Independent Convergence Protocol (SNlCP), waardoor koppeling met LAN's (die reeds ISO 8473 toepassen) mogelijk wordt door middel van een normaal intermediate systeem (relay) zoals aangegeven in ISO DP 10028. Een soortgelijke oplossing is het aanpassen van de LAN's op het WAN door het gebruik van het X.25 PLP op de netwerklaag binnen de betrokken LAN's (volgens ISO 8881). Zodat koppeling door middel van X.25 interworking units mogelijk is. De bovenstaande oplossingen hebben als belangrijk nadeel dat ze aanpassingen vereisen binnen de betrokken netwerken, hetgeen in de praktijk wellicht niet gewenst, of mogelijk is. Zie appendix A (biz. 147 & 160 Vm 162) voor praktijkvoorbeelden van toepassing van convergence-protocollen bij het oplossen van de CO/CL-interworking problematiek. 2.7.4 Methode 4: toepassen van laag 4 informatie Door gebruik te maken van informatie uit de transportlaag, zoals informatie over het opbouwen- en verbreken van een transportconnectie, kunnen IWU's bepalen ofbestaande netwerkconnecties (via het WAN) nog in stand gehouden moeten worden. Transportconnecties zijn altijd connection-oriented (althans tot nu toe), en bovendien end-to-end (bier tussen LAN-stations van resp. LAN I en LAN 2), zooat op alle "relay" puntenop de transmissieweg informatie over het wei ofniet bestaan van een transportconnectie beschikbaar is binnen laag 4. Een interworking unit die toegang heeft tot die (laag 4) informatie kan daarmee eenvoudig bepalen ofhet opbouwen- ofverbreken van een netwerk-conneetie via het WAN gewenst is. Hiermee is eenelegante oplossing voorhet laag 3 CO/CL-probleemmogelijk. Uiteraard is interworking op de bier beschreven manier alleen mogelijk indien alle gebruikte transport-laag protocollen identiek zijn, met inbegrip van de transport-klasse (bij afwijkin- 7 Ben convergenceprotocolis eenprotocol dat een bepaald sub-netwerk opwaardeert/omvonnttot een ander protocol zodat ~n bomogeen netwerk ontstaat. Het wordt over bet a1gemeen bovenop een bestaande protocol structuur geplaatst.

Call Control: Binnen/Buiten de Band Methode 4: toepassen van laag 4 informatie 17 gen daaivan zijn er "echte" bewerkingen op het niveau van de transportlaag noodzakelijk, zie verder). Het gebruik van de transportlaag voor het realiseren van interworking (op het niveau van de netwerklaag) is binnen het OSI-model niet toegestaan, omdat daardoor (in principe) het end-to-end karakter van een transponconnectie verstoord wordt. Indien men echter toch gebruik wenst te maken van de transportlaag in IWU's, zoals in dit geval, moet men ervoor zorgen dat de eind-systemen de laag 4 entiteiten van de IWU's niet "zien". Binnen ISO is men zich bewust van het feit dat een IWU waarbinnen transportlaag-functionaliteiten zijn ondergebracht strikt genomen geeninterworking Unit genoemd mag worden; men gebruikt hiervoor dan ook liever de term Inter Functional Unit (IFU). De transportlaag van een IFU is voor de eind-systemen "onzichtbaar" als de transportlaag-entiteiten ervan alle TPDU's (Transpon Protocol Data Unit) in beide richtingen transparant doorgeeft. Deze transponlaag entiteiten hebben dus geen eigen transport-adres. In het geval dat de gebruikte transpon-protocollen niet aan elkaar gelijk zijn moeten er binnenlaag 4 van een IFU ook interworking-faciliteiten ondergebracht worden, die kunnen zorgen voor de nodige conversie. In de eerder gegeven LAN- en WAN-protocolstacks vindt men bijvoorbeeld (in bijna alle gevallen) als transponlaag protocol ISO 8073, waarvan echter binnen LAN's transponklasse 4 toegepast wordt en binnen WAN's transponklasse 0 of2. Interworking zal in zo'n geval tot gevolg hebben dat er afzonderlijke transportconnecties opgezet worden tussen de verschillende actieve-punten waaruit de totale verbinding is opgebouwd, zoals tussen LAN-stations en IFU's, en tussen IFU's onderling. De IFU's zorgen hierbij voor het koppelen van die transpon-connecties. Daamaastprobeenmen het end-to-endkaraktervan de oorspronkelijke transpon-connectie tussen de twee LAN-stations te behouden. Dit wordt bereikt door het simuleren van de "tegenpanij" inclusief het bijbehorende subnetwerk binnen een IFU, zodat het voor de LAN-stations lijkt dat de IFU niet bestaat. In het kader van de eerderbesproken toestandsdiagrarnmen voor CO- en CL-systemen kan de hier beschreven oplossing als voigt samengevat worden: De toestandsinformatie in de transportlaag (CO) wordt gebruikt voor het besturen van de toestanden binnen de netwerklaag van het "WAN" (hier: WAN inclusief de bijbehorende onderdelen van de IFU's). Zie Appendix A voor praktijkvoorbeelden van het toepassen van informatie uit de transportlaag voor oplossing van de CO/CL-interworking problematiek. 2.8 Call Control: Binnen/Buiten de Band Naast de voorgaande problemen zoals het CO/CL-interworkingsprobleem en de eventuele verschillen in transponklasse kan er nog een derde hindernis bestaan bij het koppelen van netwerken, zoals LAN-interconnectie d.m.v. een ISDN.

18 Interworking van netwerken Hoofdstuk 2 Zo vindt binnen een LAN uitwisseling (en vervolgens verwerking) van data- en controlinfonnatie via het zelfde kanaal plaats: Binnen de Band. Dit in tegenstelling tot het ISDN waar men een gescheiden transpon en verwerking van user- en control-data aantreft (In de vonn van BIH-kanalen voor het transpon van user-data, en D-kanalen voor signalering. De verwerking van de informatie vindt in resp. het user- en control-plane plaats). Deze gescheiden verwerking van signalering wordt ook wei aangeduid als Buiten de Band signalering. Meer over deze "derde" hindemis voor netwerk-koppeling in hoofdstuk 3. 2.9 LAN-interconnectie m.b.v. 'frame-rela}1!!9 Het tweede deel van de afstudeeropdracht behelst het beschrijven van een situatie voor intercormectie van LAN's met behulpvan de birmen ISDN geboden frame-relaying bearer service. Daarbij is de protocol-structuur van het betreffende LAN gegeven: op laag 3 ISO 8473, het bovenste gedeelte van laag 2 bevat LLC-l. De rest van laag 2 is ingevuld met een van de gebruikelijke MAC-protocollen (token-ring, token-bus etc.), die op hun beun gebruik maken van een specifieke, bij het betreffende MAC-protocol behorende, fysieke laag. De invulling van laag 4 is in het kader van dit deei van de opdracht ruet nader gespecificeerd. Verder is gesteld dat er voor een frame-relay-cormectie geen gebruik gemaakt wordt van het D-kanaal, maar van een B- of H-kanaal (Frame-relaying in het D-kanaal is ook mogelijk, maar de haalbare throughput is beperkt). Kanaal tvde O-kanaal Tabel 2.1: Bitsnelheden in ISDN-kanalen Blts-snelheld(kb-It/s} 16 Ibli Bule Rat. Acc- ) B-kanaal 64 H-kanaal I HO 384 I H12 1920 In het volgende hoofdstuk wordt een introductie gegeven over de frame-relaying techniek in het algemeen, en de toepassing ervan voor LAN-intercormectie in het bijzonder. Daarbij zullen zowel het CO/CL-interworkingsprobleem als de "Binnen de Band" en "Buiten de Band" tegenstelling aan de orde komen.

Frame-relaying in ISDN Data Transfer bij frame-relaying: het user-plane 19 LAN-Interconnectie d.m.v. frame-relaying ISDN kan in de nabije toekomst high-speed data transmissiediensten op basis van o.a. frame-switching en frame-relaying bieden, die geschikt zijn voor het onderling koppelen van LAN's. Frame-switching en frame-relaying staan bekend onder de verzamelnaam Frame Mode Bearer Services (voorheen: Additional Packet Mode Bearer Services). In dit hoofdstuk wordt de frame-relaying-techniek in het algemeen, en de specifieke situaties waarin deze toegepast worden voor LAN-interconnectie inhet bijzonder, gemtroduceerd (Waarbij bovendien aandacht besteed wordt aan enkele kerunerkende verschillen tussen LAN's en het ISDN die voor interconnectie van belang zijn). Deze "situaties" zullen in de volgende hoofdstukken (met name in hoofdstuk 7) uitgewerkt worden in de vorm van drie scenario's: De scenario's worden aan het eind van dit hoofdstuk kort gepresenteerd, en zullen vervolgens in dit verslag als referentie worden gebruikt. 3.1 Frame-rela\1!!9_i_n_IS_D_N _ In het ISDN-model treft men een strikte scheiding aan tussen de funeties voor user-datatransport en signalering; in de vorm van respectievelijk een "user-plane" en een "controlplane". Met name de functies van, en de protocollen in het user-plane zijn bepalend voor de geboden transmissie-service. 3.1.1 Data Transfer bij 'frame-relaying: het user-plane De Frame-relaying techniek is gebaseerd op het relayeren van laag-2 frames tussen knooppunten van het ISDN-netwerk (centrales) en "terminals" met zo min mogelijk overhead.

20 LAN-/nterconneetie d.m.v. frame-relaying Hoofdstuk 3 Hierbij bevat het transmissie-netwerk slechts een beperkte laag-2 functionaliteit: uitsluitend een aantal basis-functies uit het ISDN D-kanaal data-link protocol LAPD, te weten: frame delimiting, alignment en transparency, 1 frame multiplexing/demultiplexing op basis een DLCI (Data Link Connection Identifier), een linkadres, controle of frames uit een geheel aantal bytes bestaan (rekening houdend met eventuele "zero-bit insertion"; waarmee het voorkomen van 4<flags" in user-data wordt venneden), bewaking van maximaal toegestane frame-iengte en detectie van transmissie-fouten. Dit uit basis-funeties, ook wei "Core-functions" genoemd, bestaande protocol wordt aangeduid met: Q.922 core, ofwel 1.441 +.2 Q.922 Q.922 is een extensie van het Q.921 LAPD protocol, en biedt faciliteiten voor de ondersteuning van zogenaamde extended ISDN applications op elk ISDN-kanaal (en toepassing ervan is dus niet beperkt tot het D-kanaal, zoals bij Q.921). Een belangrijke eigenschap van Q.922 is dat het de "core aspects" van het LAPD protocol biedt (zoals ini.122 gespecificeerd is), welke een basis vonnen vooro.a. de frame-relaying techniek. Het transport van de LAPD-infonnatie frames vindt, net als bij Q.921, plaats via datalinkconnecties. LAPD-frames welke behoren tot eenen dezelfde datalink worden geydentificeerd met een Data Link Connection Identifier (DLCI)-waarde welke slechts een lokale betekenis heeft (Dat wil zeggen: tussen twee knooppunten van het netwerk die de core functies uitvoeren). Deze DLCI wordt gebruikt voor het multiplexen van meerdere frame-relay verbindingen op een fysiek kanaal. In feite worden er voor de frame-relay service Virtual Calls (VCs) op het niveau van laag 2 toegepast. Foutherstel- en flowcontrol functies In Q.922 core is niet voorzien in functies voor het herstellen van optredende (transmissie) fouten (wei voor het deteeteren daarvan). Dit is niet nodig omdat de bitfouten-kans van ISDN-bearerservices vrij klein is, in sommige gevallen I : 10 6. 1 Bedoeld wordt bet cre!ren. en in stand houden van een bepaalde frame-str\jctuur. 2 In oudere publikaties word! dit protocol aangeduid met Q.92X core.

Frame-relaying in ISDN Cal/ Control: de gebruikte protocol/en 21 Users kunnen, indien gewenst, een hoogwaardiger service creeren door end-to-end foutcorrectie-faciliteiten aan te brengen. Evenals foutherstelprocedures behoren ook flowcontrol faciliteiten niet tot de Q.922 core functies, maar dienen door de users in de end-systemen onder gebracht te worden. Het weglaten van foutcorrectie- en flowcontrol-procedures binnen het netwerk, en het optioneel verplaatsen daarvan naar de end-systemen van de gebruikers, heeft als voordeel dat de benodigde "processing" door netwerk-onderdelen beperkt wordt. Dit maakt efficienter gebruik van netwerk-middelen mogelijk, hetgeen ten goede komt aan de bereikbare transmissie-snelheden. Lug I I I 3 7 T--------- ----..----- ----I 3 7 - -----~-- LIIIlg 2 proc I I I I. I I I Lug LII8ll 2 proc Frame..L Frame Frame..L Frame I Fy8iel< T Fy81e1< FY8iel< T I Fy8lel< User SIT Netwerk SIT User Figuur 3.1 : Protocol-structuur bij frame-relaying (van het "User-plane"). Frame-relaying biedt een universeel data-transportmiddel, waarbij de gebruikers een grote mate van vrijheid hebben in end-to-end toe te passen protocollen op laag-3 en het bovenste gedeelte van laag-2 (Het onderste gedeelte van laag-2 wordt bezet door de core-functies vanq.922). VooIbeelden van (end-to-end) toe te passen laag 2 protocouen zijn O.a. betieee 802 LAN datalink-protocol LLC en bet, ineerste instantie voor ISDN gedefinieerde, LAPD+.protocol (Q.922). 3.1.2 Call Control: de gebruikte protocollen Call Control wordt in ISDN verzorgt door funeties in het control-plane. Het binnen het control-plane gebruikte laag-3 protocol, Q.931, biedt uiterst universele mogelijkheden voorhet realiseren van een groot aantal verschillende circuit-mode- enpacket-mode bearer services.