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:

prof. ir. M.P.J. Stevens.

Begeleiders:

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

_

In het 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.

III

Inhoudsopgave

_

Inhoudso~_av_e

1 Inleiding

1

2 Interworking van netwerken 2.1 CO (Connection Oriented): WAN's

3

2.1.1 2.1.2 2.1.3

2.2

LAN·WAN·LAN, de in te vullen interworking case LAN·WAN, een variant Meer complexe configuraties Repeater: IWU op laag 1 Bridge: IWU op laag 2 Router: IWU op laag 3 Gateway: IWU op laag 7

Interworking in de LAN-WAN-LAN-configuratie 2.7.1 2.7.2 2.7.3 2.7.4

2.8 2.9

Transportklasse

Interworkings-mogelijkheden in OSI 2.6.1 2.6.2 2.6.3 2.6.4

2.7

CL: protocol-stack

Uitzondering: CO-lAN's Transportklasse; een secundaire hindernis Netwerk koppelingen 2.5.1 2.5.2 2.5.3

2.6

co: protocol-stack Transportklasse

CL (Connection-less): LAN's 2.2.1 2.2.2

2.3 2.4 2.5

Toepassingen

Methode 1: .en verbinding per datagram Methode 2: timers Methode 3: convergence-protocollen Methode 4: toepassen van laag 4 informatie

Call Control: BinneniBuiten de Band LAN-interconnectie m.b.v. frame-relaying

3 Introductie 3.1

Frame-relaying in ISDN 3.1.1 3.12 3.1.3

Data Transfer bij frame-relaying: het user-plane Call Control: de gebruikte protocollen Netwerk configuratie: CASE A & CASE B

3 4 4 5 5 6 6 7 7 7 8 8 9 9

9 10 11 12 13 14 15 16 16 17 18

19 19 19 21 22

Iv

Inhoudsopgave

3.2

LAN's 3.2.1 3.2.2

3.3

3.4

LAN-interconnectie m.b.v. frame-relay Call Control bij het LAN

Een concrete interworking-situatie 3.3.1 3.32

Model-matige aspecten Protocol-stacks

3.3.3

Afspraak

Uitwerking

4 De protocollen binnen het LAN 4.1 4.2

De relatie tussen POU's, SOU's etc. CL-netwerk protocol ISO 8473 4.2.1 4.2.2 4.2.3 4.2.4

4.3

Globale beschrijving van het 8473 protocol De communicatie met de andere lagen Structuur van N·PDU's Sub·Network service

Logical Link Control (LLC) 4.3.1 4.3.2 4.3.3

llC-typen: lLC 1 3 llC 1 POU-structuur

4.3.4

LLC·2 & 3

5 ISDN-protocollen 5.1

ISDN laag-3 protocol(len): 0.931 & 0.93X 5.1.1 5.1.2 5.1.3

5.2

0.931 Enkele kenmerken 0.93X: een variant t.b.v. frame-relaying

ISDN Laag-2 protoco/(Ien): 0.921 & 0.922 5.2.1 5.2.2

LAPO; globale beschrijving De geboden service

5.2.3 5.2.4

Frame-structuur 0.922

6 Frame relay connecties via een ISDN B-kanaal 6.1

De signaleringsweg 6.1.1

6.2 6.3

6.4

Message-flow van O.93X messages

Opzetten van een Frame-relay connectie Setup procedure aan de A-zijde 6.3.1

Het 0.931 SETUP bericht

6.32

Reaelie op het SETUP-bericht

6.3.3 6.3.4

CAll-PROCEEDING aan A-zijde CONNECT, aan A-zijde

Data Transfer fase

24 24 25 26 26 27 28 29

31 31 31 32 37 38 39 40 40 41 43 45

47 47 47 48 52 53 54 56 56 57

59 59 60 62 64 64 78 80 81 83

v

Inhoudsopgave

6.5

Setup-procedure aan de B-zijde 6.5.1

6.6

Het SETUP-bericht aan de B-zijde

6.5.2

Reactie aan B-zijde op het SETUP-bericht

6.5.3

CALL PROCEEDING aan B-zijde

6.5.4

CONNECT aan B-zijde

Release procedure aan A- en B-zijde

7 Interworking scenario's 7.1

Aigemeen 7.1.1 7.1.2 7.1.3

7.2

7.3

7.4

7.5

Interworking symboliek PDU's t Frames/Packets Afmetingen van Datavelden

7.1.4

Adressering binnen het LAN

7.1.5 7.1.6

CO/CL - barriere Signalering in het ISDN

Scenario 1 7.2.1 7.2.2

Algemene aspecten van scenario 1 Verwerking van uitgaande frames

7.2.3

Verwerking van inkomende berichten

Scenario 2 7.3.1 7.3.2

Globale werking van scenario 2 Actieve toestand: inen uitgaande frames

7.3.3

Rust toestand

Scenario 3 7.4.1 7.4.2

Globale werking van scenario 3 Actieve toestand

7.4.3

Rust toestand

Resume van de algemene kenmerken 7.5.1

Tabel. en het filtermechanisme

7.5.2

Adressering

7.5.3 7.5.4

Flow-control Transport protocol

7.5.5

CO/CL-probleem

7.5.6 7.5.7

Signalering: Binnen- of Buiten de Band Frame-size

8 Conclusies 8.1

Mechanismen van interworking 8.1.1

8.2

(Netwerk)-adressen: Liefst universeel, b.v. NSAP-adressen

8.1.2

Frame-Iengte

8.1.3 8.1.4

Flow-control: bij CL-netten moeilijk of zelfs onmogelijk

8.1.5

CO/CL-interworkingsprobleem: Goed oplosbaar

Elnd- & Intermediatie systemen

Modelmatige samenwerking (LAN-ISDN)

84 84 87 88 89 90

91 91 91 92 92 96 98 99 99 100 103 106 109 109 112 114 115 116 119 123 125 125 125 126 126 126 127 127

129 129 129 129 130 130 131 131

Inhoudsopgave

vi

8.3

Beoordeling van de scenario's 8.3.1 8.3.2

8.4

Aigemeen; voor aile scenario's Voor- en nadelen maken de scenario's situatiespecifiek

ISDN frame-relaying

131 132 133 134

Literatuurlijst

135

Afkortingen

139

~endices A De ISO CO/CL "IFU" A.1

IFU werkingsmodi A.1.1 A.1.2 A.1.3

A.2

De IFU in de OSI Netwerk omgeving A.2.1 A.2.2 A.2.3

A.3

De opbouw van de PTLR De netwerklaag van een PTLR Het Transport Relay Part

Werkingsmode selectie A.6.1 A.6.2

A.7

De opbouw van de ATLR Functies binnen de IFU-netwerklaag Functies binnen de IFU-transportlaag

Passieve Transport Laag Relay A.5.1 A.52 A.5.3

A.6

Adressering bij systemen met meerdere IFU's Data Unit Identifiers Transport references Voorkeur voor de te gebruiken IFU

Aktieve Transport Laag Relay A.4.1 A.4.2 A.4.3

A.5

Adressering: NSAP· en TSAP adressen Selectie van de werkingsmode Het gebruik van Netwerk adressen

Netwerk-configuratie en routering A.3.1 A.3.2 A.3.3 A.3.4

A.4

Aktieve Transport Laag Relay (ATLR) Passieve Transport Laag Relay (PTLR) Network Layer Relay (NLR)

Selectie, ontvangst van pakketten uit CL-zijde Selectie, bij pakketten vanuit de CO-zijde

Security A.7.1 A.72

Totale encryptie van TPDU's Gedeeltelijke encryptie van TPDU's

B Transport "Classes" B.1 B.2 B.3

Class 0: "Simple Class" Class 1: "Basic Error Recovery Class" 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

vII

Inhoudsopgave

B.4 B.5 B.6

Class 3: "Error Recovery and Multiplexing" Class 4: "Error Detection and Recovery Class" Overzicht van TPO tim TP4

C OSI Netwerklaag C.1 C.2

"Sublayers" Toepassing

166 166 167

169 169 169

D Protocollen binnen OSI

171

E Appendix bij ISO 8473

173

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

Fixed part Address part Segmentation part Options part Data part Data (DT) PDU

E.1.7 E.1.8

Error Report PDU Inactive Network Layer Protocol

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 IntelWorkingsUnit 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 min mogelijke functionaliteit in het transmissienetwerk transporteren van laag-2 frames, waardoor het universeel en snel is. Deze intelWoIkingssituatie is aan de hand van een drietal mogelijke 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

In feite kent zo 'n systeem twee 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), en het weer verbreken ervan (release phase). De uiteindelijke dataoverdracht vindt plaats vanuit de Data 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

. x.a .

X.ZZ4

ISO 11073

ISO 1073

Pl.P

3

1S01lZ08

2 1

.

X.ZZ4

x.a

LAPS

x.a PLP

X.Z5

LAPS

X.Zl X.Zl,.

PSPDN

Figuur 2.2: Protocol-stack voor Co-omgeving

x.a PLP

1

1.441

1.430

ISDN

1.451

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 2 verschillende services te verlenen, deze worden transportklassen genoemd (TPO tim TP4). 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-systeem3 slechts ~~n toestand, namelijk idle (mits men het wel- ofniet bestaan van een vaste (eventueel virtuele) connectie daarvoor als criterium neemt). Het verzenden, of ontvangen van een pakket vindt dan in de (niet-stabiele) data exchange phase plaats. Zie figuur 23..

2 3

Zie voor meer informatie over bet begrip transportklasse Appendix F AIleen ISO beeft een CL-netwerkservice gespecificeerd. Waarschijnlijk zal CCI1T in de buidige studieperiode deze CL-netwerkselVice ovememen.

6 Interworking van netwerken

Idle

Hoofdstuk2

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' &

LiC' & MAC

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 hetMAC gedeelte 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 om het X.25 PLP binnen een LAN toe te passen op de netwerklaag (volgens ISO 8881) waardoor er een CO-netwerkservice geboden wordt op een LAN, zie figuur 2.5. 4

150'073

3

X.25PLP

-.J:Q./.

2

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 systeem Transponklasse 4 (TP4) gei:mplementeerd is, dan behoren ook TP2 en TPO ondersteund te worden. Hetzelfde geldt voor een systeem dat TP2 gebruikt; 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's kunnen ook TPO ondersteunen zodat samenwerking op basis van TPO 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 na oplossing van het CO/CL-interworkings probleem, er nog 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.


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 of de beide LAN's weI of niet 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 er slechts een koppeling gewenst is tussen een LAN en een WAN; er is 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- of parallel 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
Hoofdstuk2

Applicatie

Applicatie

Presentatie

Presentatie

Sessie

Sessie

Transport

Transport

-~-

I-

N9tw9rlc

Nfltwerlc

Data Link

Data Link

FysifJl<

r

IFy~9p9B~fJI<

r

r

I

FysifJl<

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. 4 Een bridge observeert aile verkeer op de twee netten welke hij met elkaar verbindt. Applicatie

Applicatie

PrflSentatie

Presentatie

SflSsie

Sessie

Transport

Transport

N9twerlc

Netwerlc

Data Link FysifJl<

r

~ridg~ D.Link D.Unk FysifJl<

r

I

FysifJl<

r

Data Link FysifJl<

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 maakt van in de pakketten aangegeven routes. Zie voor meer infonnatie: Verslag 27 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's met elkaar te verbinden met behulp van meerdere bridges, waarbij men echter 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 om zelfstandig de eerder genoemde lookup-table in te vullen, waardoor ze zich automatisch aanpassen aan wijzigingen in de aangesloten subnetwerken. Samenvanend kan 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. N aast het selectief doorgegeven 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 er op 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. In dat geval neemt men in beide LAN's een 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

Applicstie

Presentatie f---~----

Presentstie --

Sessie

Sessie

Transport

Transport

Nfllwerl< DatB Link --

Fysiel<

r

~ut~ NfltWerl< NfltWerl<

Netwerl<

Data Link

Data Link

Data Link

Fysiek

Fysiek

Fysiek

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 hier een interworking unit aangeduid die opereert op het niveau van de applicatielaag (of daarboven). 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 een gateway verschillende applicaties met elkaar tracht 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.

Gateway: IWU op lsag 7 13

Interworking in de LAN-WAN-LAN-configuratie

Applicstie Presentatie

APP~~i~ Presentatie

Presentatie

Sessie

Sessie

Sessie

Tf7Insport

Tf7Insport

Tf7Insport

Applicstie Presentatie -

Sessie Tf7Insport --

Netwerk

Netwerk

Netwerk

Netwerk f----

Data Link

Data Link

Data Link

Data Link

Fysiek

Fysiek

Fysiek

Fysiek

L~

___J

L ___

~_~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).


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-data worden 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 bier eigenlijk 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


Hoofdstuk2

samenwerkende netwerken niet (exact) voorspelbaar is: opeenvolgende reeksen van pakketten kunnen gemiddeld perpakket sneller getransporteerd 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 van de 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"punten op 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 of het opbouwen- of verbreken van een netwerk-conneetie via het WAN gewenst is. Hiermee is een elegante oplossing voor het laag 3 CO/CL-probleem mogelijk. 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 convergence protocol is een protocol dat een bepaald sub-netwerk opwaardeert/omvonnt tot 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 geen Interworking 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 binnen laag 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. Daamaast probeen men het end-to-end karakter van 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 eerder besproken 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.


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). Tabel 2.1: Bitsnelheden in ISDN-kanalen Blts-snel held (kb-It/s}

Kanaal·tvDe O-kanaal B-kanaal H-kanaal

16 Ibli Bule Rat. Acc-••)

I

HO

64 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
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 een en 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 : 106 .

1 2

Bedoeld wordt bet cre!ren. en in stand houden van een bepaalde frame-str\Jctuur. In oudere publikaties word! dit protocol aangeduid met Q.92X core.


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.

I I I

I

I Lug

3·7

I

T--------- ----..-----

----I

I -

Frame

•I

..L

Frame

I Fy8iel<

T

User

SIT

3·7

I

I.

-----~--

LIIIlg 2 proc

Lug

Fy81e1<

•

•

•

•

Frame

LII8ll 2 proc

..L

Frame

I FY8iel<

Netwerk

T

Fy8lel<

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. bet IEEE 802 LAN datalink-protocol LLC en bet, in eerste 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 voor het realiseren van een groot aantal verschillende circuit-mode- en packet-mode bearer services.

22 LAN·/nterconneetie d.m. v. frame-relaying

Hoofdstuk3

Q.93X Frame mode bearer services waanoe o.a. frame-relaying behoort zijn nieuwe, in ontwikkeling zijnde services binnen het ISDN waarin het standaard ISDN-signaleringsprotocol Q.931 niet voorziet, er ontbreken bijvoorbeeld bepaalde "infonnation elements". Met behulp van het van Q.931 afgeleide Q.93X-protocol kan de extra benodigde functionaliteit (voor o.a. frame-relaying) weI geboden worden. De uitwisseling van Q.93X-berichten vindt, net als berichten van Q.931, plaats via data-links birmen het D-kanaal. Hiervoor is het Q.921-protocol in gebruik.

"Out-band Call-Control" De birmen ISDN toegepaste methode van gescheiden transport van user-data en signalering-data wordt aangeduid met: "buiten de band call-control".

3.1.3 Netwerk configuratie: CASE A & CASE B Tot besluit van deze paragraaf over de frame-relaying techniek in het ISDN nog iets over fysieke lokatie van de Frame Handler (FH) in het netwerk. De FH is de functie in het ISDN die de frame mode bearer services, waaronder frame-relaying, kan bieden aan de gebruikers. Er zijn een tweetal situaties te onderscheiden: In de eerste situatie, CASE A genoemd, bevindt de FH zich niet in de lokale ISDN-centrale waar de abonnee aan gekoppeld is, maar ergens "dieper" in het net. In CASE B heeft de abonnee rechtstreeks toegang tot de benodigde FH, omdat deze in de 10kale ISDN-centrale gei'ntegreerd is. De twee situaties zijn weergegeven in figuur 3.2 en 3.3. CASE A In CASE A ondersteunt de lokale centrale slechts circuit geschakelde bearer services, en is Q.931 gei:mplementeerd. De PH bevindt zich dus niet in de lokale centrale, zodat de abonnee eerst een circuit switched verbinding (B-kanaal) met een remote FH opzet, en vervolgens met behulp van Q.93X de frame-service aanvraagt.


Netwerk configuratie: CASE

A & CASE B

23

Circuitswitched ISDN

Frame Relay ISDN

./ ./ Circ-uit-Switched

Frame h4m/ler

Terminal

Figuur 3.2: CASE A: Remote Frame Handlers

Dit scenario heeft voor de abonnee twee nadelen: 1. Het is niet mogelijk om een Frame Mode Bearer Service (FMBS) op het D-kanaal op te zetten; dit is voor onze doelgroep (LAN-LAN interconnectie) van minder belang: in het algemeen zal een grotere throughput gewenst zijn. 2. Voor het opzetten van een FMBS verbinding dient tweemaal een verbinding aangevraagd te worden: Berst een circuit-geschakelde verbinding naar de FH, en vervolgens een frame-geschakelde verbinding naar de B-abonnee (eindbestemming) Tevens dient de interworking unit in dit geval zowel Q.931 als Q.93X te ondersteunen, hetgeen natuurlijk niet aantrekkelijk is. Ben bijkomend nadeel is nog dat het B-kanaal tussen abonnee en FH in CASE A belast wordt met de Q.93X berichten stroom. Aangezien deze berichtenstroom tijdens de data transfer phase zeer beperkt zal zijn, wordt dit niet als een belangrijk nadeel gezien.

CASEB In CASE B ondersteunt de lokale centrale weI de frame mode bearer services en is daarvoor ook Q.93X gelmplementeerd. De abonnee kan dan direct de frame-geschakelde verbinding naar de eindbestemming opzetten. Tevens hoeft men in de interworking unit in dit geval niet Q.931 te implementeren, maar slechts Q.93X.

24 LAN-Interconnectie d.m. v. frame-relaying

Frame Relay ISDN

Hoofdstuk3

Frame Handlu

TermiflQ/

Figuur 3.3: CASE B: Rechtstreeks t08gang tot Frame Handler

Het bijkomende nadeel dat bij CASE A genoemd is, is hier uiteraard niet van toepassing.

De afstudeeropdracht: CASE 8 In het kader van de afstudeeropdracht is gekozen voor de CASE B situatie: De lokale ISDN-centrale bevat een Frame Handler met frame-relay faciliteiten voor het rechtstreeks bieden van de frame-relay service. Aan de genoemde CASE A mogelijkheden zal in dit verslag verder geen aandacht worden geschonken.

3.2 LAN's Local Area Networks (LAN's) bieden aan de aangesloten stations een snelle en betrouwbare data-cornmunicatie weg met bitsnelheden die liggen in de orde van enkele tot tientallen Mbit/s (zelfs 100 Mbit/s bij FDDI). De fysieke omvang van zo'n LAN is beperkt tot een enkele vestiging van een bedrijf, ofzelfs tot een afdeling binnen zo'n vestiging. Om een aantal redenen kan bet gewenst zijn om verschillende LAN's met elkaar te koppelen, waardoor er een groot communicatie-netwerk ontstaat. De frame-relay techniek is voor het realiseren van LAN-interconnecties via het ISDN (met hoge transmissie-snelheden) zeer geschikt.

3.2.1 LAN-interconnectie m.b.v. frame-relay Voor de afstudeeropdracht wordt verondersteld dat de interconnectie van LAN's met bebulp van frame-relaying plaatsvindt op bet niveau van de datalink- of netwerklaag, waarbij er op datalink-niveau onderscbeid gemaakt kan worden tussen relayeren op MACof LLC-niveau. Ben drietal mogelijkheden worden in de vonn van scenario's in dit verslag besproken.

LAN's

Call Control bij het LAN 25

Het LLC-protocol kent drie varianten: LLC-l tim LLC 3. LLC-l biedt een ConnectionLess unacknowledged (CL) service, terwijl LLC-2 en LLC-3 resp. Connection-Oriented (CO) en acknowledged-CL zijn. De MAC-laag biedt aan de LLC-laag de zogenaamde MAC-service aan. AIle MAC-protocollen bieden dezelfde MAC-service, waarvan de quality of service weI verschillend kan zijn. Op bet niveau van laag 3 zijn er binnen LAN's een aantal mogelijkheden. Een bekende standaard is ISO 8473: een CL-netwerk protocol voor toepassing binnen LAN's.

Opdracht: de LAN-protocol-stack In bet kader van de afstudeeropdracbt is sprake van een LAN waarvan de protocol-stack opgebouwd is uit: ISO 8473 op laag 3, en LLC-l en MAC op laag 2 (op resp. de bovensteen onderste helft van laag 2). De invulling van laag 1 wordt bepaald door het gebruikte MAC-protocol, welke in het kader van frame-relaying niet van belang is: alle MAC-protocollen zijn geschikt.

lug'

Transport

lug 3

ISO 8473 LLC-1

lug 2

..au

MAC _.X IX:S..')

.... '

PHY

Figuur 3.4: IEEE 802 LAN protocol-stack

Het Transport-laag protocol is bier niet nader gespecificeerd.

3.2.2 Call Control bij het LAN Zowel op laag 3 als laag 2 is er in bet kader van bet eerder omschreven LAN sprake van uitsluitend Connection-Less protocollen. Ben eigenscbap van zulke protocollen is dat signalering-infonnatie (zoals source- en destination-adressen) samen met user-data in ~n pakket/frame ondergebracbt worden.

"In-band Call-Control" De call-control vindt dus bij bet LAN binnen de band plaats (zelfs "binnen bet frame").

26 LAN-Interconnectie d.m. v. frame-relaying

Hoofdstuk3

3.3 Een concrete interworkin9'---s_i_tu_a_t_ie

_

3.3.1 Model-matige aspecten Bij de interworking van het LAN (met eigenschappen zoals hierboven beschreven) met het ISDN komt men een aantal problemen tegen die het gevolg zijn van verschillen in de LAN- en ISDN-modellen. Een aantal direct in het oog springende verschillen worden hieronder genoemd: meer gedetailleerde informatie voIgt in de rest van dit verslag.

Call Control Een van de belangrijkste verschillen tussen een LAN en het ISDN is de scheiding van functionaliteiten in een user-plane en control-plane in het ISDN. Een soortgelijke scheiding van functionaliteiten, en als gevolg daarvan ook van de transmissie-kanalen, komt bij LAN's niet voor. In de ISDN-situatie ziet men dat signalering buiten het transmissiekanaal voor user-informatie plaatsvindt, ook weI "Buiten de band" signalering genoemd. Bij LAN's is er geen fysieke scheiding tussen de twee genoemde (functioneel verschillende) informatie stromen, en vindt signalering dan ook "binnen de band" plaats. Ben situatie die te vergelijken is met betgeen in bet analoge telefonie-net op bet koppelvlak. met de abonoee plaats vindt: dezelfde gelijkstroomlus wordt zowel toegepast voor signalering (baak-signalen, kiesinformatie, etc.) als voor bet realiseren van spraak-overdracbt.

Interworking; de keuze router of bridge? Een logisch gevolg van de genoemde model-matige verschillen tussen ISDN en LAN's is dat interworking beter met behulp van een router kan geschieden dan met een bridge. Binnen een router is er, in tegenstelling tot een bridge, immers van nature signaleringsinformatie aanwezig. Frame-relaying is echter een typische laag-2 service waardoor het gebruik van een bridge meer voor de hand zou liggen. Wellicht kan een goed compromis bereikt worden door een combinatie van beide technieken, waarbij signaleringsinformatie op "router"-achtige wijze, en userdata op "bridge"achtige manier behandeld wordt.

Het Co-CL probleem Een tweede verschil tussen ISDN en LAN's is dat het ISDN gebruik maakt van CO-protocollen, zoals Q.922, en LAN's overwegend CL·georienteerd zijn (zoals LLC-l). Binnen de interworking-unit zal dan ook veel moeite gedaan moeten worden om deze CO-CL-barrib'e te overwinnen.

Een concrete interworking-situatie

Protocol-stacks 27

Er is in de opdracht geen specifiek transpon-protocol voorgeschreven zodat er geen gebruik gemaakt kan worden van laag-4 informatie voor het oplossen van het CO-CL-probleem (zoals in het vorige hoofdstuk beschreven is).

3.3.2 Protocol-stacks Conform de hierboven beschreven protocol-structuur zijn een drietal protocol-stacks birmen de interworking-unit mogelijk. Ben oplossing welke gebaseerd is op een gecombineerde router-bridge vindt men in scenario 1. In deze variant wordt getracht om de data-inhoud van laag 2 user-frames te relayeren met behulp van het Q.922 protocol. Hierbij is echter ook op laag-3 birmen de interworkingunit samenwerking noodzakelijk tussen het control- en user-plane, omdat de noodzakelijke frame relaying-bearer-service in het ISDN uitsluitend met behulp van het op laag 3 opererende Q.93X protocol kan worden aangevraagd. Deze koppelingsvorm wordt in literatuur vaak "brouter" genoemd (gecombineerde bridge & router).

1508473

150 8473

LLC 1

LLC 1

MAC

\/

\/

0.93X

0.922cor9

0.921

MAC

----

18D1H-..

(8802.X)

I

I

n

1.4301/.431

~--

(8802.X)

I

I

-

0_

I

I

Figuur 3.5: Scenario 1: "Srouter A"

Ben andere combinatie van router & bridge is in scenario 2 gepresenteerd.

1508473

1508473

LLC 1

LLC 1

MA~ / / 0.922 core

MAC ~---

----

(BB02.X)

(8802.X)

I

~/

I /.AN

Figuur 3.6: Scenario 2: "Srouter S"

0.93X

I

I

0.921

I

- .....

n

1.43011.431

1lVT_

I I

I

28 LAN-Interconnectie d.m.v. frame-relaying

Hoofdstuk3

In dit scenario wordt getracht reeds op het niveau van de "MAC-laag" frames uit te filteren waarvoor er al een frame-relay connectie bestaat met de gewenste eindbestemming. De LLC-frames die in de MAC-frames zijn ondergebracht worden daarbij "ingepakt" in Q .922 core frames. Kopieen van "onbekende" frames gaan door naar de "LLC-I laag" en de netwerk-laag: daar veroorzaken ze het creeren van een nieuwe frame-relay connectie in het ISDN. Deze nieuwe verbinding wordt vervolgens gebruikte om het "onbekende" frame alsnog te verzenden.

Scenario 3 wordt gevormd door een soon router waarbij er op laag 3 vanuit het user-plane infonnatie uitwisseling plaats moet vinden met het control-plane om de vereiste bearerservice in het ISDN op te zetten.

ISO 8473 -

._-~

-

---

.--

/S08473

LLC 1

f-- ------

LLC 1

MAC

t--------

0.922

0.921

f-----

(8802.X)

(8802.X)

I

I

I

111_-"

MAC

---I

---

0.93X

-,

/.4301/.431

(; 0_

I I

Figuur 3.7: Scenario 3: "Router"

3.3.3 Afspraak Bij de bespreking van de drie scenario's (in hoofdstuk 7) zal er verondersteld worden dat alle met behulp van ISDN frame-relay-bearers te koppelen LAN's slechts uit een fysiek Local Area Network bestaan, ofzodanig zijn geconfigureerd dat ze als een fysiek LAN te beschouwen zijn. Verder wordt aangenomen dat de enige gateway naar de "buitenwereld" de in boofdstuk 7 te beschrijven interworkingunit is.

"Remote" (LAN-station) Met een remote LAN-station wordt in dit verslag een LAN-station aangeduid dat zich niet op bet eigen fysieke LAN bevindt, maar op een LAN dat met behulp van een frame-relayverbinding bereikt kan worden.

Uitwerking

3.4 Uitwerking"---

Afspraak 29

_

Alvorens daadwerkelijk de hierboven gemtroduceerde interconnectie-scenario's te beschrijven volgen er eerst een aantal voorbereidende hoofdstukken waarin o.a. de belangrijkste aspecten van de aan de orde zijnde protocollen aangegeven worden (hoofdstuk 4 en 5). Verder worden in hoofdstuk 6 de procedures besproken die in het ISDN uitgevoerd worden voor het opzetten en verbreken van de benodigde frame-relay connecties. De uiteindelijke behandeling van de drie intercOImectie-scenario's is het onderwerp van hoofdstuk 7. Conclusies en aanbevelingen over de in dit rappon besproken LAN-WAN-koppeling met behulp van frame-relaying volgen tenslotte in hoofdstuk 8.

De relatie tussen PDU's, SDU's etc.

31

De protocollen binnen het LAN

In dit hoofdstuk worden de LAN-protocollen behandeld die in het kader van de afstudeeropdracht een rol spelen, te weten het Connection-less netwerkprotocol ISO 8473 en het Logical Link Control type 1 (LLC-l). Alvorens de bespreking van de genoemde protocollen te starten eerst iets over de relatie tussen PDU's, SDU's, primitieven etc.

4.1 De relatie tussen PDU's, SDU's etc. Zoals bekend is een protocol stack opgebouwd in een aantallagen (bij het OSI model: 7 lagen) die ieder een aparte functie vervullen in het communicatie-proces. Elk laag bevat een protocol. Gelijkwaardige protocollen in verschillende eind-systemen communiceren met elkaar (binnen het niveau van een laag) door het uitwisselen van Protocol Data Units (PDU's). Binnen een eind-systeem wordt tussen aangrenzende lagen infonnatie uitgewisseld met behulp van primitieven: deze bestaan uit een combinatie van Interface Data Units (IDU) en Interface Control Infonnation (ICI), waarbij de laatste zorgt voor het nemen van de barriere tussen de twee lagen. "User-data" die van een hogere laag ontvangen wordt noemt men Service Data Units (SDU's). Samen met de door het betreffende protocol toegevoegde Protocol Control Infonnation (PCI) vonnen deze de te transporteren PDU's (deze komen in de onderliggende laag weer terecht als SDU's). Zie figuur 4.1.

Opmerking: Voor alie duidelijkheid: bier wordt alleen het "zend-proces" besproken is: het "ontvangst-proces" is identiek, maar "loopt" echter van onder naar boven.

4.2 CL-netwerk p_ro_to_c_o_I_IS_O_8_4_7_3

_

ISO 8473 is tot nu toe het enige in ISO gestandaardiseerde CL-netwerklaag-protocol dat toegepast kan worden om een CL-netwerkservice te bieden. Men heeft dit protocol zo universeel mogelijk gedefmieerd: met specifieke eigenschappen van het gebruikte onderliggende subnetwerk (zoals bijvoorbeeld X.25 WAN's ofIEEE802

32 De protocol/en binnen het LAN

Hoofdstuk4

LAAG N+1

LAAGN

(N-1)-/DU

LAAG N·1 (N-1)-SAP

(N·1)·SDU

Figuur 4.1: De relatie tussen PDU's. SOU's, etc.

LAN's) is binnen het protocol zelf geen rekening gehouden. Conversiejmapping tussen ISO 8473 en het onderliggende netwerk vindt plaats door een zogenaamde "underlaying service", waarvan het bijbehorende protocol tussen de "ISO 8473 laag" en laag 2 is gesitueerd. De officiele term van zo 'n functie is: Subnetwork Dependent Convergence Function (SNDCF). ISO 8473 zelf is een Subnetwork Independent Convergence Protocol: het is immers in hoge mate onafhankelijk van het gebruikte subnetwerk. Allereerst voIgt er een bespreking van het ISO 8473 protocol, vervolgens zal ingegaan worden op het noodzakelijke Subnetwork Dependent Convergence Protocol (dat de SNDCF verzorgt).

4.2.1 Globale beschrijving van het 8473 protocol Het ISO 8473 protocol omvat procedures voor de Connectionless transmissie van user-data en control-infonnatie tussen netwerk-laag entiteiten. Naast het ondersteunen van het volledige protocol is er voorzien in twee zogenaamde subsets die in bepaalde, hieronder nader te noemen, gevallen toegepast kunnen worden. Daarbij wordt gebruik gemaakt van specifieke netwerk-karakteristieken die binnen net-

CL-netwerk protocol ISO 8473

Globale beschryving van het 8473 protocol 33

werklaag-entiteiten aanwezig kunnen zijn, met als gevolg dat zo 'n protocol-subset niet volledig "network-independent" is (in tegenstelling tot het "complete" 8473 protocol). Subset 1: "Inactive Network Layer Protocol"

Het Inactive Network Layer Protocol, een ISO 8473 subset, is in feite een zogenaamd "null-function" protocol. Het kan toegepast worden als bekend is dat de source- en destination-end-systemen zich binnen hetzelfde subnetwerk bevinden. Subset 2: "Non-segmenting"

De non-segmenting subset kan worden toegepast als bekend is dat de afmetingen van de Subnetwork Service Data Units (SN-SDU) van het gebruikte subnetwerk voldoende groot zijn om alle voorkomende N-PDU's te kunnen bevatten. Ben gevolg is onder andere een eenvoudigere header in de N-PDU 's: infonnatie betreffende segrnentering (zoals Data Unit Identifiers) kan daaruit weggelaten worden.

Door het protocol uitgevoerde functies Hieronder zal een globaal overzicht gegeven worden van de functies die door het ISO 8473 Connection Less Netwerk Protocol (CLNP) uitgevoerd (kunnen) worden: niet alle genoemde functies behoeven binnen een specifieke implementatie vertegenwoordigd te zijn. Composltle- en Decomposltle van PDU's

De belangrijkste functie die het ISO 8473 protocol bevat is die voor het "in elkaar zetten" en "uitpakken" van Protocol Data Units (PDU's): resp. compositie en decompositie, zie de onderstaande figuur.

compoeltle

I

1---(N)·PDU

Figuur 4.2: Compositia an dacompositia van PDU's

Compositie: Bij compositie moet men denken aan het construeren van NetweIk PDU's (N-PDU's) met daarin laag-4 userdata en infonnatie voor het correct transporteren van de

34 De protocollen binnen het LAN

Hoofdstuk4

PDU naar zijn eindbestemming. Deze infonnatie 1 kan afkomstig zijn uit de netwerklaag zelf, maar zal voor het overgrote deel in de vonn van laag-3 primitieven aangereikt worden.

Decompositie: Deze functie verzorgt het verwijderen van de PCI uit de (correct) ontvangen N-PDU's, waarnade userdata(NS_Userdata2 ) overblijftdie aanlaag 4 doorgegeven wordt. Header analyse en foutdetectle

De header van een binnenkomende netwerk PDU wordt d.m.v. een zich daarin bevindende checksum gecontroleerd op fouten, zodat onterechte ontvangst of onjuiste relayering van N-PDU's voorkomen kan worden. Daamaast vindt er een analyse plaats van de Network Layer Protocol Identifier- en adres-velden. Aan de hand daarvan is de selectie van de eventueel gebruikte protocol-subset (non-segmenting of passieve-subset) en de daarbij behorende speciale procedures binnen een ontvangende netwerk-entiteit mogelijk. Het zal duidelijk zijn dat de adresseringsinforrnatie benut wordt om te bepalen of een bepaalde PDU al ofniet zijn eindbestemming bereikt heeft. In het laatste geval zal getracht worden om de betreffende PDU in een zodanige richting door te zenden dat deze zijn eindbestemming kan bereiken. Lifetime

Binnen het protocol is er voor gezorgd dat eenmaal verzonden PDU's niet oneindig lang binnen netwerken blijven "ronddwalen" zonder ooit bij de gewenste bestemming te arriveren. Elke PDU heeft een door het initiele eind-systeem te bepalen levensduur (lifetime): PDU's waarvan de levensduur verstreken is worden "weggegooid". Segmenting/Reassembly

De maximale afmetingen van netwerk PDU's wordt bepaald door de capaciteiten van het gebruikte subnetwerk. Daarvan wordt geeist dat als het gebruikt wordt in combinatie met het ISO 8473 protocol, N-PDU's met een lengte van minimaal512 bytes kan verwerken. Indien er tijdens de compositie N-PDU's dreigen te ontstaan die te groot zijn voor verwerldng door het gebruikte subnetwerk (de N-PDU mag niet groter zijn dan de SN-SDU) vindt er segmentatie plaats: Het datagedeelte (van de "initiele" N-PDU) wordt in kleinere stukken opgesplitst en voorzien van een header waarin aangegeven is dat de verschillende afgeleide (segment) N-PDU's data-blokken bevatten die samen aan de transportlaag doorgegeven moeten worden (na ontvangst van deze PDU's). Dit proces kan ook plaatsvinden in zogenaamde intermediate systems (relay's) als de gebroikte subnetwerken andere eisen stellen aan de N-PDU afmetingen. Zie figuur 4.3

1 2

Protocol Control Infonnation (PC!) NS_Userdata is de parameter beborende bij de NS_UNITDATA Request en Indication. Deze parameter bevat de userdata (Transportlaag-PDU) die uitgewisseld wordt tussen de nelWeIk- en transportlaag.


Globale beschrijving van het 8473 protocol 35

~,---

-- j

~

D_AT_A

---,

]-DATA·SEGMENT,

~

DATA·SEGMENT 2

~

DATA·SEGMENT 3

Figuur 4.3: Segmentation en reassembly van (N)-PDU's

In deze figuur is aangenomen dat de betreffende POU's geen Options-part bevatten. Het header gedeelte dat in elk segment-POU (identiek) voorkomt is met H gekenmerkt, en bet Segment-part met Sx, zie voor meer infonnatie over de struetuur van de POU's figuur 4.4.

Het segmenteren vindt op een zodanige wijze plaats dat de nieuw ontstane PDU's een lengte hebben die gelijk is aan een veelvoud van 8 bytes. Behalve uiteraard het laatste afgeleide PDU, deze mag een afwijkende lengte hebben (er wordt hiervoor geen vorm van padding toegepast). De van een initiele PDU afgeleide PDU's zijn herkenbaar aan het feit dat ze allemaal hetzelfde source- en destination-adres en Data Unit Identifier bevanen in de PDU-header. Andere velden die voor de segmentation-functie van belang zijn worden hieronder opgesomd: Segment Offset - geeft de oorspronkelijke plaats van het betreffende segment in het initiele PDU aan, Segment Length - geeft de totale lengte van de afgeleide PDU aan (header + data), More Segments Flag - is bedoeld om aan te geven of het betreffende segment het laatste octet van de oorspronkelijke PDU bevat, Total Length - deze specificeert tenslone de totale lengte van het initiele PDU (header + data). Tenslotte client nog opgemerkt te worden dat in de header aangegeven kan worden dat segmenting van een PDU bij o.a. relayering niet toelaatbaar is (Segmentation Permitted flag). Dit kan bij samenwerlcing tussen het volleclige ISO 8473 protocol en de Non-segmenting subset van belang zijn. Aan de ontvangstzijde worden de verschillende segmenten verzameld, hierna vindt reassembly en vervolgens decompositie plaats en wordt het complete initiele datablok (DATA in figuur 4.3) aan de transportlaag doorgegeven.


Hoofdstuk4

Ouallty of ServIce (005)

Een belangrijk deel van de door de netwerkservice gebruiker verlangde Quality of Service wordt in het ISO 8473 netwerkprotocol ondergebracht in de POU-header. Oit stelt een intennediate eind-systeem in staat om POU's te routeren langs subnetwerken die voldoen aan door een gebruiker gewenste transmissie-delay, kosten en foutenkans. Het intennediate system zal deze keuze maken op grond van in de header (in het Options-part) van de POU opgenomen infonnatie, welke de prioriteits-volgorde van de drie kwaliteiten aangeeft. Oe zender van het POU ontvangt geen melding van het intennediate system welke keuze is gemaakt, en of daarbij volledig is voldaan aan de gestelde kwaliteitseisen. Ben eind-systeem is er dus met zeker van of de gevraagde QOS daadwerkelijk geleverd wordt. CongestIe-melding

Om ervoor te zorgen dat Netwerk Service gebruikers maatregelen kunnen nemen bij optredende congestie binnen het netwerk is er in het ISO 8473 protocol voorzien in een congestie-meldings functie. Een intennediate-system kan het bestemrnings-eind systeem door middel van een flag in de header (Options part) van een POU melden dat er sprake is van een congestiesituatie. Afhandeling van zo'n situatie komt niet voor rekening van laag 3 (met ISO 8473), maar dient op Iaag 4 of hoger plaats te vinden. Routering

Binnen een POU-header wordt zowel het bestemmings- (destination) en bron-(source) netwerk-adres venneid in de vonn van NSAP-adressen. Samen met de eerder genoemde Quality of Service zijn intennediate eind-systemen daarmee in staat om een geschikte route naar de eindbestenuning te selecteren. Bovendien biedt het aanwezig zijn van een sourceadres de mogelijkheid om tijdens transmissie optredende fouten terug te melden aan het initierende eind-systeem (meer hierover in Appendix E), verder wi! een gebruiker gewoon weten waar het pakket vandaan komt. Naast de hierboven beschreven routerings-methode is er voorzien in "source-routing". Hierbij wordt door het initierende eind-systeem reeds in de POU-header (in het Optionspart) de te volgen route aangegeven. Oeze methode wordt "complete source routing" genoemd. Ben andere mogelijke source routing variant is de "partial source routing". Hierbij worden slechts een aantal tussen-liggende eind-systemen aangegeven; de overige moeten door het netwerk zelf bepaald worden. Ten behoeve van het opsporen van transmissie problemen is er voorzien in een mogelijkheid om een gevoIgde route, tijdens de transmissie van een POU, te laten vastleggen in de header van elke POU: "Record Route" functie.


De communicatie met de andere lagen

37

Discarding van PDU's

In het geval van o.a. protocolfouten, overbelasting, transmissie fouten etc. zijn netwerkentiteiten gerechtigd om ontvangen PDU's "weg te gooien". Bij de zogenaamde nontransient gevallen kan er dan indien gewenst een terugmelding plaatsvinden, deze wens wordt aangegeven m.b.v. een flag in de PDU-header (zie voor meer informatie Appendix E).

Ben geldige reden voor het "weggooien" van PDU's is bijvoorbeeld: overtreding van prorocol-regels, checksum-errors, congestie, een foutieve header, segmentering niet mogelijk/toegestaan terwijl dit voor verder transpon weI noodzakelijk is, destination-address onbereikbaar/onbekend, onjuiste source-routing, lifetirne-verstreken of het gebruik van een niet ondersteunde optie. Error reporting

Bij de hierboven cursief gedrukte oorzaken kan er een Error Reponing PDU (ER-PDU) worden teruggezonden naar het initiele eind-systeem. In een ER-PDU wordt naast een foutcode ook aangegeven op welke positie binnen het DT-PDU de betreffende fout opgetreden is. Daartoe wordt een gedeelte van dat DT-PDU gekopieerd in het data-veld van de ER-PDU. Opmerking: Het optreden van een fout tijdens de transmissie van een ER-TPU kan nooit aanleiding zijn voor het genereren van een (andere) ER-PDU. Tenslone is nog vermeldenswaardig dat het genereren van ER-PDU's verhinderd kan worden door het zetten van de error-reponing flag in de PDU-header. Padding

Indien gewenst kunnen er aan de PDU-header een aantallege bytes toegevoegd worden (padding). Daarmee kan bereikt worden dat de in de PDU opgeslagen data "handig" aansluit op de woordbreedte van een ontvangen eind-systeem (computer b.v.).

4.2.2 De communicatie met de andere lagen Zoals gebruikelijk binnen het OSI-model wordt er tussen de verschillende lagen gecommuniceerd door middel van prirnitieven. De door het ISO 8473 protocol gebruikte primitieven komen in de volgende paragrafen aan de orde.

Door de netwerklaag verleende service Het ISO 8473 protocol biedt een Connectionless Netwerk service, zoals beschreven in ISO 8348/AD1 (Addendum to the Network Service Definition Covering Connectionless-mode Transmission). De hierbij betrokken prirnitieven zijn opgesomd in tabeI4.1, samen met de bijbehorende parameters.


Hoofdstuk4

TabeI4.1: Netwerk service primitieven Primitive:

Parameters: Request Inc:lication

NS_Destination_Address NS_Source_Address NS_QualitLo'-5ervice NS Userdata

Opmerking: Confonn de bepalingen in ISO 8348/AD1 is de maximale afmeting van een COlUlectionless N-SDU, en daannee de NS_Userdata parameter, beperkt tot 64512 bytes.

Van het subnetwerk verwachte service Een subnetwerk-protocol dat geschikt is voor het ondersteunen van het ISO 8374 Connectionless Netwerk Protocol (CLNP) dient de in de volgende tabel vennelde primitieven te kunnen verwerken. Tabel 4.2: Subnetwerk service primitieven Primitive: SN_UNITDATA

Parameters: Request Inc:lication

SN_Destination_Address SN_Source_Address SN_Quality_ Service SN Userdata

0'-

Opmerking: De afmeting van de SN_Userdata-parameter dient minimaal groot genoeg te zijn om een netwerk POU (N-POU) onder te brengen met een lengte van 512 bytes.

4.2.3 Structuur van N-PDU's AIle ISO 8473 PDU's moeten opgebouwd zijn uit een geheel aantal bytes. Ze bestaan uit een header en een data-veld. De header is verder nog verdeeld in een zogenaamd fixed part, address part, segmentation part en een options part. De laatste twee, het segmentation- en options part zijn niet in alle POU-headers aanwezig. De stIuctuur van een ISO 8473 POU is in onderstaande figuur schematisch afgebeeld.

-

.. Fixed Part

Address Part

Figuur 4.4: PDU-struetuur

Segmentation Part

Options Part

Data


Sub-Network service

39

De bytes in een PDU zijn oplopend genurnmerd in de volgorde waarin ze in een SN-SDU geplaatst worden. Zie voor gedetailleerde infonnatie over de inhoud (v.d. header) van de PDU's appendix E.

4.2.4 Sub-Network service De OSI-netwerklaag is onderverdeeld in drie sublagen die ieder een aparte, elkaar aanvullende functie vervullen. De bovenste sublaag voert de Sub-Network Independent Convergence Functie (SNlCF) uit: deze biedt de OSI-netwerkservice op basis van een aantal verschillende subnetwerken zoals bijvoorbeeld IEEE 802 LAN's, X.25 etc (ISO 8473 is een SNlCP). De onderste sublaag wordt ingevuld met een Subnetwork Access protocol (SNACP). De link tussen deze twee sublagen wordt gevonnd door een Subnetwork Dependent Convergence Protocol (SNDCP), welke de reeds eerder genoemde, en door het ISO 8473 protocol verwachtte, subnetwork-service biedt (SNlCF).

Subnetwork-service In ISO 8473 wordt de verzorging van de door het protocol verwachtte subnetwork service beschreven voor zowel IEEE 802 LAN's en X.25 netwerken. Bij de LAN's veronderstelt men dat het bovenste deel van de datalink-laag gevuld is met het LLC klasse I of klasse IT protocol, welke beide de unacknowledged CL-datalink service kunnen bieden. Deze datalink-service, LLC type I, wordt in ISO 8473 zelfs verplicht geste1d. In het kader van de afstudeeropdracht werd gekozen voor het gebruik van LLC type I in de te koppelen LAN's; dit blijkt in combinatie met ISO 8473 geen beperking te zijn, omdat bij dat protocol uitvoering van de unacknowledged LLC functies (LLC I) verplicht is. Ook als LLC-type 2 in gebruik zou zijn. LLC type 1 sIs subnetwerk

In het geval van LLC type I is de mapping tussen de SN_UNITDATA primitieven, afkomstig van het ISO 8473 protocol, en de DL_UNITDATA primitieven zeer eenvoudig. Deze mapping is nagenoeg "een-op-een". Behalve voor de Quality of Service parameter in de ISO 8473 primitieven. TabeI4.3: ISO 8802-2 LLG-1 Service primtieven Prlmttlve: DL_UNITDATA

Parameters: Request

Indication

DL_Destination_Address DL_Source_Address DL_Priority DL Data

Voor aile duidelijkheid, SN_UNITDATA primitieven zijn in gebruik op het koppelvlak tussen het ISO 8473 protocol en het SNDCP. Infonnatie uitwisseling tussen dit SNDCP

Hoofdstuk4


(die de underlaying service biedt aan ISO 8473) en de "LLC-Iaag" vindt plaats met behulp van DL_UNITDATA primitieven.

4.3 Logical Link Control (LLC) Binnen de reeks aanbevelingen voor Local Area Networks (ISO 8802.X) speelt het Logical Link Control protocol (LLC: ISO 8802-2) een sleutelrol. LLC vormt de "interface" tussen het Medium Access Control (MAC) en de netwerklaag. Globaal vonnen MAC en LLC gezamenlijk de data-link laag binnen een LAN, waarbij MAC de onderste sublaag vormt en LLC de bovenste. De MAC-sublayer is in tegenstelling tot de LLC-sublayer afuankelijk van de specifieke invulling van de fysieke laag binnen het LAN. Dit verklaart ook dat er een aantal verschillende MAC-standaarden bestaan, maar slechts 1 LLC-standaard (met echter een aanta! varianten).

4.3.1 LLC-typen: LLC 1 tim 3 Het Logical Link Protocol voorziet in zoweI een Connection-Less (CL) als een Connection-Oriented (CO) data-link: service. De CL-service is beschikbaar als een Unacknowledged versie in de vorm van LLC 1, en een Acknowledged versie als LLC 3. Tenslotte: de Connection Oriented versie wordt als LLC 2 aangeduid. LLC 1 wordt het meest toegepast, echter o.a. in Engeland is LLC 2 populair, terwijl LLC 3 voldoet aan de specifieke eisen van de PROWAY IEC standards group (IEC SC65C/WG6). De hierboven genoemde LLC-typen worden in de LLC-standaard (ISO 8802-2) in een viertal klassen ondergebracht, te weten: LLC-I!/m LLC IV. Alle klassen bevatten de Connection Less variant (LLC 1). De klassen IT en ill zijn daamaast uitgebreid met resp. LLC 2 en LLC 3. Tenslotte omvat LLC-klasse IV alle LLC-varianten (dus LLC 1 tim LLC 3). Tabel 4.4: LLC-typen

I· ·\~1:

•. . .

·.....::~-=----+-i_.-_· .:. :.;- -+- _· · . :. : ~- · ·-41-· ·_· ·_· _· · · . . .: ·~.:. .· _.- -

il-·····__

Vit het bovenstaande zal het duidelijk zijn dat alle volgens de LLC-standaard werkende systemen te allen tijde met elkaar kunnen samenwerken d.m.v. LLC 1.

Logical Link Control (LLC)

LLC 1 41

Structuur van de LLC-Iaag Naast een entiteit voor het daadwerkelijk bieden en verzorgen van een data-link service bevat de LLC-laag ook een management-entiteit: het Layer Management (LM). De precieze invulling daarvan is nog in studie, en wordt dus nog niet in de huidige LLC-standaard beschreven.

Informatie-uitwisseling De LLC-datalink entiteit wisselt op 4 "fronten" informatie uit. Twee daarvan worden gevormd door primitieven-uitwisseling met de netwerk-laag en de MAC-sublaag. Daarnaast is er (ook door middel van primitieven) contact tussen de LLC-datalink entiteit en het Layer Management. Tenslone onderhoudt een specifieke LLC-datalink entiteit (uiteraard) contact met een peer-entiteit d.m.v. (Data Link) Protocol Data Units (L-PDU's).

Datalink-typen Een LLC-datalink is in principe point-to-point georienteerd, alleen in het geval van LLC 1 (Non-Acknowledged Connection Less) zijn bovendien multicast- of broadcast "verbindingen" mogelijk. De keuze daartussen wordt bepaald aan de hand van primitieven uit de netwerklaag, en vervolgens in de L-PDU's aangegeven in het adres-veld.

4.3.2 LLC 1 LLC 1biedt een CL-datalink (Unacknowledged) service aan netwerklaag-entiteiten binnen een IEEE 802 LAN. Deze service zorgt met een minimum aan protocol-complexiteit voor de overdracht van LLC-data-units, zonder garantie dat de verzonden informatie altijd correct en in de juiste volgorde bij de bestemming zal arriveren. Hieronder zal nader ingegaan worden op het LLC 1 protocol: alleen deze LLC-variant is in het kader van dit verslag (en de afstudeeropdracht) van belang.

De geboden service aan de netwerklaag Voor de uitwisseling van informatie tussen LLC-l- en de netwerk-Iaag zijn twee primitieven beschikbaar: DL-UNITDATA-request en DL-UNITDATA-indication. Deze omvatten de volgende parameters: source- en destination-adressen, data en priority.


Hoofdstuk4

Adresserlng

De adres-parameters van de DL-UNITDATA primitieven bevanen 7-bytes lange LANadressen (volgens ISO 8802). Deze bestaan uit een combinatie van een 6-byte MAC-adres en een 1 byte LLC-adres, resp. SA/DA- en SSAP/DSAP-adressen (SA en SSAP geven source-adressen aan, en DA en DSAP destination-adressen)3. De combinatie van adressen van verschillende (sub)lagen is een unieke situatie binnen ISO-standaarden, en lijkt tegen de regels van het OSI-model. Het DSAP-LLC adres kan een individueel-, groep- of broadcast adres zijn (het individuele adres kan bovendien een lokaal-adres zijn). De overlge parameters

Naast de hierboven besproken adres-parameters bevanen DL-UNITDATA primitieven nog een data- en priority-parameter De dataparameter is bedoeld voor het onderbrengen van user-data welke afkomstig is van de netwerklaag. Deze data wordt in de vorm van N-PDU's aangeboden, en heeft binnen de "LLC-laag" de status van LLC-SDU. De lengte van het dataveld wordt niet in de LLC-standaard bepaald, maar is volledig afhankelijk van de eigenschappen van de MAClaag. Tenslotte kan eventue1e prioriteits-informatie vanuit laag 3 door middel van de pnontyparameter aan de LLC-laag aangeboden worden. Deze gegevens zullen uiteindelijk transparant door de MAC-service doorgegeven worden aan de peer-LLC 1 entiteit.

De verwachte service van de MAC-sublaag Voor infonnatie-uitwisseling met de MAC-sublaag zijn de volgende prirnitieven gedefinieerd: MA-UNITDATA- request en MA-UNITDATA-indication. De MA-UNITDATA-request en indication hebben een vergelijkbare functie als de DLUNITDATA primitieven (uitwisseling van userdata, samen met adresserings- en prioriteitinfonnatie). Hieronder enkele verschillen in de parameters van de primitieven. Adresserlng

Ben belangrijk verschil wordt gevonden in de adressering (in vergelijking met DL-adressering). Als source-adres dient een individueel MAC-adres ingevuld te worden. Het destination-adres kan zowel een individueel- als een groep MAC-adres zijn. De gegevens in deze adresvelden moet voldoende zijn voor de lokale MAC-service om naast de SA- en DA-adressen, welke in de MAC-PDU's worden ondergebracht, fysieke3

Uiteraard bevatten LLC-frames alleen LSAP-adressen (DSAP en SSAP), en MAC-frames alleen MAC-adressen (DA en SA) in bun headers (Het data-veld van een MAC-frame bevat een LLC-frame, en dus ook LSAP-adressen).

PDU-structuur 43


laag-adressen, zoals bijvoorbeeld transmissie-frequentie in broadband applicaties, te construeren. Service verlenlng aan Layer Management Oit wordt (nog) niet in de huidige LLC-standaard gedefmieerd, venneld staat: For further on-going study and resolution (ISOITC 971SC 6 N 4609,1987-10-02).

4.3.3 PDU-structuur Een LLC-I POD bestaat uit de volgende velden: OSAP en SSAP (elk 8 bit), control (l byte)4 en een infonnatie veld (M bytes, waarbij M afhankelijk is van de gebruikte MAC-service. (M mag eventueel ook 0 nul zijn).

DSAP-Adres

SSAP-Adres

r Control-veld

Information-veld

....-.----....-----...------...-------. 8 bi16

8 bits

M"8blts

8 bi16

Figuur 4.5: De opbouw van een LLC-1 frame

Adres-velden Evenals in het voorgaande dient een SSAP-adres een individuele laag 3-entiteit (L-SAP) aan te duiden, en kan een OSAP-adres ook een groep- of broadcast adres zijn. oSAP lIdr811-veld

SSAP .dres-veld

Figuur 4.6: De opbouw van DSAP- en SSAP-adresvelden

Slechts 7 van de 8 bits zijn beschikbaar voor OSAP- en SSAP adressen, deze zijn in figuur 4.6 aangegeven met resp. D en S.

4

Bij U.C-l is de lengte van bet control-veld beperkt tot I byte; een uit 2 bytes bestaand control-veld treft men bijvooJbeeld bij ll.C-2 aan.


Hoofdstuk4

De resterende bits, het minst significante bit van elk adresveld, worden op de volgende wijze gebruikt: Bij DSAP (destination) - adressen geeft de waarde van dit bit (fIG) aan of het een individueel- of groep adres betreft. Het eerste bit in het SSAP-veld (CIR) geeft aan of het een "Command" of "Response" frame betreft. (Bij LLC 1 is response niet altijd van toepassing: UI-response frames bestaan bijvoorbeeld niet). Bljzondere adressen

Ben bijzonder groep-adres is het zogenaamde Global DSAP-adres; dit duidt alle actieve DSAP's aan die van de dezelfde MAC-service gebruik maken. De codering ervan kenmerkt zich door 8 acht logische enen in het DSAP-adresveld (11111111).

Een ander bijzonder adres is het volledig uit logische nullen bestaande (00000000) "nul"-adres dat zowel in DSAP- als SSAP-veld voor kan komen. Het duidt een LLC-entiteit zelf aan, en is dus niet bedoeld voor het adresseren van een service access point van de netwerk-laag of het LLC-laag management. LLC-Iaag management adres

De management-entiteit die zich in de LLC-sublaag van een LAN-station bevindt kan geadresseerd worden door het adres: 1000000.

Control-veld In het control-veld wordt het type PDU aangegeven: Infonnation (I-PDU), Supervisory

(S·PDU) en Unnumbered (U-PDU). Bij LLC 1 zijn aIleen U-PDU's in gebruik; daardoorheeft het control-veld van een LLC-l frame altijd een lengte van 8 bits. Command- & Response-LLC-1 frames

In het LLC-l protocol komen een aantal verschillende frames voor, die hieronder worden

genoemd. UI-Command

Het belangrijkste frame-type is het Unnumbered Infonnation (UI) frame. Het is het enige juiste middel voor de overdracht van user-data. LLC-l biedt een unacknowledged CL-datalink service, en er bestaat daarom uitsluitend een UI-Command-frame, en geen UI-response, er vindt immers geen acknowledgement plaats van data-frames. De twee avenge frame typen, Exchange Identification- (XID) en Test- (TEST) frame, kennen weI een Command- en Response versie. Hiennee kunnen peer-LLC-entiteiten een soon primitieve dialoog aangaan.


LLC-2& 3 45

XID-Command/Response

Het XID-frame is bedoeld om met peer-LLC-entiteiten het te gebruiken LLC-type af te spreken. (In de meer geavanceerdere LLC-versies wordt dit frame-type verder benut voor het overeenkomen van zenden ontvang-windows). Een LLC-entiteit is verplicht om zo snel mogelijk te reageren op een ontvangen XID-command d.m.v. een XID-response.

Tenslotte: De in een XID-frame overte dragen informatie (zoals het te gebruiken LLC-type en eventueel window-afrnetingen) wordt ondergebracht in een 16-bits parameter-veld (te vergelijken met het Information-veld in een UI-Command-frame). De totale lengte van een LLC-type 1 XID-frame is dus 5 bytes. Test-Command/Response

Het Test-frame dient voor het testen van een bepaalde Logical Link. Elke LLC-entiteit is verplicht om na ontvangst van een Test-conunand onmiddellijk een Test-response terug te sturen. Optioneel kan een Test-Conunand een information-veld bevatten; dit dient, indien mogelijk, in het Test-Response-frame terug gezonden te worden.

Opmerking: Het Test-frame kan, indien het information-veld user-data bevat, gebruikt worden voor realisatie van een soon acknowledged CL-data-link service: een zender kan in de (terug) ontvangen Test-response frames "zien" of de user-data correct overgedragen is naar de peer LLC-entiteit. Dit "oneigenlijke" gebruik van het Test frame wordt in de standaard niet genoemd, en is dus niet verboden. Deze methode veroorzaakt echter een inefficient gebruik van het netwerk, en is alleen mogelijk als beide terminals het zo kunnen, en willen gebruiken. Het Poll/FInal-bit

Naast de code van het betreffende frame-type is er in het Control-veld nog een zogenaamd Poll/Final-bit aanwezig (Command-frames bevatten een poll-bit, bij Response-frames heeft dit bit een andere aanduiding: final-bit); "poll" geeft aan dat de zender een PDU terug verwacht, en "final" duidt de daaropvolgende respons aan.

4.3.4 LLC·2 & 3 In het vervolg van dit verslag zal alleen LLC type 1 aan de orde komen. In het voorgaande zijn echter ook LLC type 2 en 3 genoemd; voor de volledigheid volgen hieronder enkele kone opmerkingen daarover.


Hoofdstuk4

LLC2 LLC 2 biedt een Connection Oriented data-link service, welke voorziet in een volgorde vaste (en correcte) overdracht van LLC-data-units. Het LLC 2 protocol is een variant van het HOLC-protocol.

LLC3 LLC 3 (Connection Less inc1usief Acknowledgement) is bedoeld voor situaties waarin een grote betrouwbaarheid gewenst is, zonder de complexiteit van een connection oriented protocol. Oe werking van het protocol is vrij eenvoudig: elk verzonden frame moet gevolgd worden door een acknowledge-frame, alvorens er een volgend frame verzonden kan worden. Oe window grootte bij LLC 3 is dus per definitie gelijk aan een: LLC 3 voorziet niet in zogenaamde "multi frame" transmissie waarbij de acknowledgement van een bepaald frame pas "komt" nadat er reeds vervolg frames verzonden zijn.

0.931 47

ISDN Iaag-3 protoco/(/en): 0.931 & 0.93X

______ IS_D_N----I-protocollen

Voor de realisatie van Frame Mode bearer services, zoals frame-relaying, binnen het ISDN zijn er aanpassingen in de huidige ISDN laag 2 & 3 protocollen noodzakelijk (resp. Q.92l: datalink protocol voor het D-kanaal, en Q.93l: signalering).

5.1 ISDN

laa~rotocol(len):

Q.931 & Q.93X

Q.931 is het ISDN-laag 3 (abonnee-lijn) protocol dat bedoeld is voor de besturing (signalering) viahet D-kanaal van met name circuit-switcheden packet-switched-connections in een van de B-kanalen, of eventueel in een H-kanaal. Voor packet-switched connecties is de functionaliteit van Q.93l beperkt tot het opzetten van een circuit naar een X.25 Packet Handler (In het protocol zijn er verder voorzieningen getroffen voor useruser-signalering en, in beperkte mate, userdata transport via een D~kanaal.) Voor frame-mode bearer services, waaronder frame-relaying, zijn er enige uitbreidingen op Q.93l noodzakelijk: dit resulteert in Q.93X, een protocol dat nu in ontwikkeling is. In de volgende paragraaf (5.1.1) worden aspecten van Q.93l besproken. De uitbreidingen

daarop in de vorm van Q.93X, ten behoeven van frame-mode bearers, komen in paragraaf 5.1.3 aan de orde.

5.1.1 Q.931 Q.93l (en natuurlijk ook Q.93X) wordt gebruikt in het zogenaamde "control-plane" van hetISDN. Met behulp van berichten die binnen het protocol gedefmieerd zijn kan men B-kanaal verbindingen via een ISDN opzetten met zeer uiteenlopende eigenschappen (uiteenlopend van telex- tot bijvoorbeeld "slow-scan", 384 kbit/s, video-verbindingen en natuurlijk ook gewone telefonieverbindingen). De keuze voor een bepaald service-type, of kwaliteit van een resulterende verbinding, wordt door de initierende partij kenbaar gemaakt in een zogenaamd SETUP-pakket (met name in het bearer capability information element).

48 ISDN-protocol/en

Hoofdstuk 5

Q.931 is een user-network protocol dat gebruik maakt van een betrouwbare laag 2 service in de vonn van Q.921 (zie paragraaf 5.2, en verder), waardoor acknowledgement van Q.931-berichten niet nodig is. Uiteraard vindt er tussen zender en ontvanger weI een uitwisseling van Q.931 berichten plaats. Ben reactie op een ontvangen bericht geeft aan de zender een indicatie dat het bericht begrepen is (en vonnt een onderdeel van een "handshake/onderhandelings-procedure" die bij het opzetten ofverbreken van verbindingen door het protocol uitgevoerd wordt: op een SETUP-bericht wordt bijvoorbeeld gereageerd met een CALL PROCEEDING-bericht). In Q.931 onderscheid men uiteraard incoming- en outgoing-call's. Het zal duidelijk zijn

dat deze elkaar be'invloeden: een outgoing call request genereert ergens (in het netwerk) een incoming call request.

5.1.2 Enkele kenmerken In deze paragraaf worden enkele kerunerkende aspecten van het zeer uitgebreide Q.931 protocol besproken. Voor een volledige beschrijving wordt de lezer verwezen naar de officH~le CCITT specificatie.

Pakket-opbouw Zoals gebruikelijk kan men ook in Q.931-pakketten een header- en een data-part onderscheiden. In de header is infonnatie ondergebracht betreffende het gebruikte protocol (hier dus Q.93I), een indicatie van het type bericht (Message Type) en een zogenaamde Call-Reference-value (zie verder). In de protocoldefinitie zijn ongeveer 26 verschillende Message Types gedefinieerd, waaronder het SETUP-, CONNECT-, DISCONNECT-type. Het data-part omvat een variabel aantallnfonnation-elements (afhankelijk van het Message Type). In sommige gevallen kan eenzelfde lnfonnation Element type meennalen voorkomen in hetzelfde Q.931-pakket. Er zijn zo'n 40 verschillende lnfonnation elements gedefmieerd. Pskket-/engte

De maximale lengte van Q.931 pakketten is bepaald door de capaciteit van het onderliggeride datalink-protocol (Q.921). Het Q.921-protocol, dat uitsluitend op het D-kanaal toegepast wordt, kan laag 3 pakketten met een maximale lengte van 260 bytes verwerken. Dit is een default-waarde: in het kader van het D-kanaal zijn echter geen grotere pakketten toegestaan omdat alle tenninals die -bus bevinden binnen een zekere tijd gegarandeerd toegang moeten hebben zich op een

srr

tot het D-kanaal. Zodat het gebroik ervan voor signalering door elke tenninal gegarandeerd is.

Enkele kenmerken 49

ISDN Isag-3 protocol(Ien): 0.931 & 0.93X

Q.931 messages die zouden resulteren in te grote pakketten (langer dan 260 bytes) worden door het laag 3 protocol opgesplitst in meerdere kleinere pakketten: dit proces staat bekend onder de term "segmenteren". Voor deze functie heeft men het Segmented message information element gedefinieerd dat de "ontvanger" in staat stelt om het oorspronkelijke Q.931 bericht uit meerdere segmenten te reconstrueren. De segmentation/reassembly-fuoctie is een typiscbe laag 3 fuoctie. Ook bet CL-netwerkprotocol ISO 8473. dat in bet vorige boofdstuk is besproken, bevat deze fuoctie.

Adressering en terminal-selectie Onder de titel adressering kan men zowel de werkelijke ISDN-adressering binnen het ISDN-net, als de identificatie met "Call References" van systemen op user/netwerkkoppelvlakken verstaan. Call-Reference

Tussen abonnee-apparatuur (in de vonn van TE's) en een ISDN-centrale worden logische signaleringskanalen, die via het "fysieke" D-kanaallopen, van elkaar onderscheiden met behulp van Call References. Alle bij een bepaalde verbinding behorende (signalerings) berichten worden met dezelfde Call-Reference-waarde gekenrnerkt. Een initierend systeem kiest de op de betreffende interface te gebruiken Call-referencewaarde uit een range beschikbare waarden. Zowel het netwerk als de abonnee-apparatuur gebruiken vervolgens dezelfde waarde. Een Call-Reference heeft slechts een lokale betekenis: alleen op de betreffende user/netwerk-interface. Het gebruik van Call-References in Q.931 vertoond sterke overeenkomst met betgeen in X.25 gebruikelijk is. Dit is Diet zo verwonderlijk daar X.25 model beeft gestaan bij de ontwikkeling van Q.93 1.

Ultwlssellng van IfNetwerk-adressen

If

Binnen de structuur van Q.931 is uitwisseling en verwerking mogelijk van adresseringsinformatie volgens een groot aantal verschillende nummer-plannen (zoals ISDN/telefoon X.121, datanetten F.69, prive-plannen). Dit kan in de vorm van een "compleet" ISDN-adres/subadres of een zogenaamd keypadadres. De laatste vorm is speciaal bedoeld voor het direct transporteren van op een eenvoudig keyboard ingegeven nummer-informatie (Zo'n keyboard is te vergelijken met de druktoetsen op een conventionele telefoon). De eerder genoemde ISDN-adres-informatie bevat nummers uit een van de gedefinieerde standaard nummer-plannen. Naast ISDN-adressen bestaan er ook ISDN-subadressen. Deze zijn bedoeld voor de adressering van gebruikers-apparatuur die zich "achter" de ISDN-aansluiting bevindt. Een

50 ISDN-protocol/en

Hoofdstuk5

ISDN-subadres kan zowel door een gebruiker te bepalen infonnatie bevatten als een (gestandaardiseerd) X.213/ISO 8348 NSAP-adres. Zo'n sub-adres wordt, indien mogel lijk , door het ISDN-netwerk getransporteerd, maar nooit door dat netwerk geprocessed (voor routering oj.d.). Het zal blijken dat dit subadres van grote betekenis is voor de realisatie van een LAN-interconnectie d.m.v. frame-relay bearers.

Compatibility-check Tijdens het opbouwen van een verbinding vinden er zogenaamde compatibility-checks plaats van zowel de toe te passen bearer-capability's als high- en low layer functionaliteiten in de gebruikte terminals. Dit is van belang omdat er binnen het ISDN een groot aantal verschillende bearer-services geboden kunnen worden, waarvan verwacht mag worden dat niet alle aangesloten tenninals en netwerk-delen ze allemaal kunnen ondersteunen. Met name de high- en low-layer compatibility infonnation elements worden door terminals gebruikt om te beoordelen of zij een binnenkomende call-request kunnen, of moeten beantwoorden. De inhoud van deze information elements mogen, in tegenstelling tot de inhoud van het bearer-capability infonnation element, niet door het netwerk gewijzigd worden. (De wijziging van het BC-information element door het netwerk kan noodzakelijk zijn als end-to-end geen identieke bearer geboden kan worden). Naast het onderscheid tussen bearer-capability en high- en low-layer capability, is er een verdeling te maken in de situatie tussen user-user en user-network (uiteraard beide richtingen) compatibiliteit-controle. Hierbij dienen de high- en low-layer capability information elements voor de eerste situatie, en het BC-information element voor de tweede. Bearer-capability

In het SETUP-pakket geeft een initierende terminal aan welke type bearer service van het netwerk verwacht wordt voor een bepaalde call. De genoemde informatie wordt ondergebracht in het "bearer-capability information element". Zowel het netwerk als de ontvangende terminal controleren of de gevraagde bearer-service (zoals is aangegeven in het Bearer-capability information element) daadweIkelijk geboden kan worden. Indien dat niet het geval is zal het netweIk het verzoek tot verbindingsopbouw verwerpen, of een altematieve bearer-service aanbieden (die uiteraard vervolgens door de gebruikers geweigerd kan worden).

1

Doorgifte van subadressen in bet ISDN is optioneel.

ISDN laag-3 protocol(len): 0.931 & 0.93X

Enkele kenmerken 51

Het gebruik van het bearer capability-element door een terminal 2 om te besluiten of een bepaalde inkomende call al dan niet geaccepteerd zal worden is eigenlijk niet correct: voor dat doel zijn de "low- en high layer capability information elements" in het SETUP-pakket ondergebracht. Ben ontvangende tenninal hoeft in het geval dat de aangegeven bearer-service niet past bij zijn eigen mogelijkheden overigens niet te reageren op de betreffende call-setup (met b.v. verwerping), maar kan volstaan met het negeren ervan. In het Bearer-capability information element wordt o.a. aangegeven of er een packet- of circuit-mode call gewenst is, de bitsnelheid van het gevraagde circuit, de soort informatie (speech, (un)restricted digital, video etc.), een aantal laag 1 parameters (user-bitsnelheid, gebruikte coderingsregel bij b.v. spraak, half/full-duplex) en eventueel de te gebruiken laag 2 en 3 protocollen. (NB.: Slechts een gedeelte van de hierboven genoemde informatie is verplicht in dit information element aanwezig.) Een ISDN mag, indien gewenst, de inhoud van het bearer-capability information element aanpassen aan de feitelijke capaciteiten van het netwerk. Low layer compatIbility

Het low-layer capability information element verschaft een geadresseerde entiteit de mogelijkheid om te kunnen bepalen of een bepaalde call geaccepteerd kan/moet worden. Dit information element wordt door het ISDN-netwerk transparant (en dus ongewijzigd) doorgegeven. De inhoud ervan vertoond zeer sterke overeenkomsten met het eerder genoemde bearer capability information element, waarvan de inhoud weI door het netwerk veranderd mag worden. HIgh layer compatibility

Het High layer compatibility information element wordt door user-terminals (van een ISDN-netwerk) gebruikt voor het controleren/bepalen of een bepaalde call wel- of niet geaccepteerd kan worden, ten aanzien van de end-to-end gebruikte hogere laag protocollen (tot en met de applicatie-laag). Ook dit information wordt door het ISDN transparant doorgegeven.

Opmerking: Hoewel dit information element transparant door het ISDN getransporteerd wordt, kan het netwerk er volgens de Q.931 specificatie zelf gebruik van maken voor het realiseren van een specifieke teleservice.

2

Hier moet de term ''terminal'' ruim gezien worden; er kan ook een interworldngunit binnen bet ISDN-net ofbijvoorbeeld een hogere laag entiteit mee worden aangeduid

52 ISDN-protocollen

Hoofdstuk 5

Symmetrie Hoewel het Q.931 protocol primair bedoeld is voor user/network signalering heeft men getracht de procedures ervan zoveel symmetrisch te houden (tussen user en netwerk), waardoor koppeling van ISDN-PABX'en (Huiscentrales) via "leased lines" eenvoudig mogelijk is.

5.1.3 Q.93X: een variant t.b.v. frame-relaying Ten behoeve van de signalering voor frame-mode call's, waaronder frame-relay call's, worden er een aantal aanvullingen en wijzigingen op de bestaande Q.931 specificatie voorgesteld in Q.93X. Deze komen in hoofdstuk 6, waarin het o.a. opzetten van framerelay call's in het ISDN beschreven worden, nader aan de orde. Daarop vooruit lopend worden hieronder een aantal in het oog springende kerunerken besproken.

Enkele bijzonderheden In grote lijnen komt de procedure voor het opzetten van frame-mode call's in het algemeen, en van frame-relay call's in het bijzonder, overeen met hetgeen gebruikelijk is bij "normale" ISDN-Packet-Mode call's. In Q.931 wordt wat betreft de beschikbare "messages" onderscheid gemaakt tussen circuit-mode- en pakket-mode-connecties. Frame-relaying valt onder de nieuw te defmieren groep van Frame-mode bearer services. De daarbij van toepassing zijnde Q.931 messages worden in tabel5.1 opgesomd. Tabel 5.1: 0.931 messages voor Frame Mode connections

Cau.stab.lshment m...,a.s:

•......

\

.:

ALLERTING CALL PROCEEDING CONNECT

CONNECT ACKNOWLEDGE PROGRESS SETUP

C.-ttCltat'oa me"'8$:

"

DISCONNECT RELEASE RELEASE COMPLETE

M"~lIIn.ou.m. ...g88

...

.:

..

.........

STATUS STATUS ENQUIRY

In vergelijking met Q.931 zijn de meeste messages op een aantal punten gewijzigd (ten behoeve van frame-mode bearer services): ze zijn uitgebreid met additione1e information elements (In tabel 5.1 zijn de hier bedoelde messages cursiejafgebeeld).

ISDN Laag-2 protocol(Ien): 0.921 & 0.922

0.93X: een variant t.b. v. frame-relaying 53

De in het voorgaande bedoelde additionele infonnation elements komen hieronder kon aan de orde. Data Link ConnectIon identifier

Bij frame-relaying is het mogelijk om meerdere frame-relay call's op een B-kanaal te multiplexen. Dit gaat op basis van de op laag 2 gebruikte Data Link Connection Identifiers (DLCI 's). Er bestaan hierbij meerdere onafhankelijke data-links op een bepaald B-kanaal. Voor de identificatie van zo'n datalink moet er naast het betreffende B-kanaal ook de DLCI-waarde aangegeven worden. In het Q.931 protocol wordt er tijdens de call-setup fase echter uitsluitend "onderhandeld" over het te gebruiken B-kanaal (H- en D-kanalen worden hier buiten beschouwing gelaten); circuit-calls bezetten immers B-kanalen volledig. Het zal duidelijk zijn dat er in de messages voor frame-relay call-setup naast een Channel Identijication- ook een DLCI-infonnation element opgenomen moet worden (Het Channel Identification infonnation element geeft het gebruikte B-kanaal aan). Link layer core parameters

Voor een frame-relay connectie wordt van het ISDN een bearer-service gevraagd waarop binnen het transmissie-net alleen de zogenaamde core-functies van het link-layer protocol (Q.922) actiefzijn. De gewenste eigenschappen daarvan, zoals frame-afmetingen en inen uitgaande transmissie-snelheden, kunnen in Q.93X-berichten worden aangegeven in het zogenaamde Link Layer core parameter infonnation element. Connected number & Connected subaddress

Het Connected number- en Connected subaddress-infonnation element wordt in de CONNECf- en RELEASE-messages gebruikt om in het geval van bijvoorbeeld call-forwarding de uiteindelijke bestemming van de call aan de initiator daarvan door te geven. Met die infonnatie kan deze bijvoorbeeld besluiten dat de altematieve bestemming niet gewenst is, en de call-setup procedure afbreken.

5.2 ISDN

Laag~rotocol(len):

Q.921 & Q.922

In de reeks Q.92X CCITI aanbevelingen wordt een laag 2 protocol beschreven voor toepassing binnen het ISDN: Link Access Procedure voor het D-kanaal (LAPD). Aanbeveling Q.920 beschrijft de globale struetuur van laag 2. De beschrijving van het Link Access protocol zelf (procedures voor data-uitwisseling en besturing binnen eind-systemen (lSDN-tenninals) en tussen eind-systemen en het netwerk) vindt in Q.921 plaats. Een uitbreiding van Q.921 voor toepassing op alle ISDN-kanalen wordt voorgesteld als Q.922. Een subset daarvan, bestaande uit de zogenaamde core-functies, speelt een rol bij de realisatie van frame-relaying.

54 ISDN-protocol/en

Hoofdstuk 5

5.2.1 LAPD; globale beschrijving LAPD (Link Access Procedure voor D-kanaal) is bedoeld voor het realiseren van 1 of meerdere data-link connecties via het D-kanaal (deze data-link connecties dienen voor het transport van laag 3 infonnatie in het algemeen, en signaleringsinfonnatie van het Q.931 protocol in het bijzonder), waarbij er sprake kan zijn van een multi-terminal installatie bij de abonnee (Srr-bus). Bovendien kan zo'n terminal meerdere laag 3 entiteiten in zich herbergen. Het zal dus duidelijk zijn dat het Q.921 protocol multiplex-mogelijkheden heeft. Zoals elk data-link protocol zorgt LAPD voor het construeren van frames aan de zend-zijde, en het herkennen daarvan aan de ontvangst-zijde. Bij het transport van die frames blijft de sequentie ervan (in het geval van LAPD) behouden. Er zijn voorzieningen getroffen zodat laag 3 infonnatie-uitwisseling op transparante wijze plaats kan vinden (zie verder). Uiteraard bevat het LAPD-protocol faciliteiten voor afhandeling van foutsituaties, zoals foutdetectie (o.a. d.m.v. FCS-controle), foutcorrectie (door her-transmissie) en het melden van onherstelbare-fouten aan laag 3 ofhet layer-management. Tenslotte dient nog venneldt te worden dat LAPD mogelijkheden heeft voor "flow control".

Data-link configuraties Er zijn zowel "point-to-point-" als "broadcast"-datalink-connecties mogelijk. Het eerste connectie-type "loopt" altijd tussen een terminal en het netwerk; dus tussen TE's en NT's, hetgeen inhoud dat terminals op een- en dezelfde bus niet rechtstreeks met elkaar kunnen comrnuniceren, maar uitsluitend via een NT of eventueel het ISDN. Bij een "broadcast"-datalink worden verzonden pakketten door alle op een bus (Srr-bus) aangesloten terminals en de netwerk-aansluiting (NT) ontvangen. Deze vonn van communicatie is vooral van belang voor uitwisseling van signaleringsinfonnatie (in het geval van een inkomende oproep), en besturingsfuncties in het algemeen zoals toewijzing van Terminal Equipment Identifiers (TEl's). Deze TEl's worden gebruikt voor de adressering van tenninals op een Srr-bus, zie verder.

Twee werkings-modi Overdracht van infonnatie kan zowel op "unacknowledged-" als "acknowledged-" basis geschieden. De laatste service is alleen mogelijk na een specifieke initialisatie procedure, en bovendien alleen bij point-to-point data-links.

Interne structuur van Data-Link laag De data-link laag in de Q.920-serie is onderverdeeld in een Data-Link- en een management gedeelte (Layer Management: LM). Het LM onderhoudt het contact tussen het Data-Link gedeelte en het systeem-management (in de vonn van de management-"toren" in het ISDN-model) en verzorgt o.a. het toewijzen van TEl's (zie verder).

ISDN Laag-2 protocol(Ien): 0.921 & 0.922

LAPD; globale beschrijving 55

Adressering De adressering van een uitwisselingspunt tussen laag 2 en laag 3 (Service Access Point) vindt vanuit laag 2 plaats door middel van eem Data Link Connection Identifier (DLCI: SAPI + TEl). Vanuit laag 3 worden deze punten geadresseerd door middel van een Connection Endpoint Identifier (CES: SAPI + CES). Service Access Point (SAP)

De data-link laag biedt zijn diensten aan laag 3 en het LM aan via SAP's (Service Access Point). Voor de verschillende te bieden service's zijn aparte SAP's gedefinieerd, welke geldentificeerd worden door een Service Access Point Identifier (SAP!). Zo vindt informatieuitwisseling ten behoeve van Call-Control plaats via SAPI=O. SAPI 1, en 2 zijn gereserveerd voor packet-mode communicatie (resp. I voor o.a. frame-relay, evt samen met Q.931 call-control procedures, en SAPI 2 voor X.25 PLP). Laag 2 management procedures maken gebruik van SAPI 63. De overige SAPI-waarden zijn gereserveerd voor toekomstige ontwikkelingen. Terminal Endpoint Identifier (TEl)

De selectie van een specifieke terminal (of onderdeel daarvan) binnen de data-link laag geschied aan de hand van een Terminal Endpoint Identifier (TEl). TEI-waarden kunnen zowel vast ingesteld worden in terminals, als door het netwerk worden toegewezen door middel van een TEI-assignment-procedure. (Vast ingestelde TEI-waarden: 0 Vm 63, automatisch toe te wijzen: 64 Vm 126). De hierboven genoemde TEI-waarden zijn bedoeld voor zogenaamde point-to-point verbindingen, daarnaast is er ten behoeve van point-to-multipoint comrnunicatie een globale TEI-waarde (127) gedefmieerd ("broadcast TEl"). De overdracht van bijvoorbeeld signalerings-infonnatie (zoals Q.931 SETIJP berichten) gaat via SAPI=O en TEI=127.

Het zal duidelijk zijn dat er bij broadcast-data uitwisseling geen acknowledgement van berichten mogelijk is. Bij de andere mogelijkheid, point-to-point, is dit uiteraard weI mogelijk. Connection Endpoint Suffix

Vanuit laag 3 wordt een bepaalde Data Link Connection aangeduid door een Connection Endpoint Suffix. De waarde ervan wordt gekozen door een laag 3 entiteit (die van een bepaalde data-link gebruik wil maken) of een laag 2 management-entiteit. De relatie tussen CES en TEl wordt door het managementgedeelte in laag 2 gelegd.

56 ISDN-protocol/en

Hoofdstuk 5

5.2.2 De geboden service De data-link laag, en met name het data-link gedeelte, biedt zowe1 aan laag 3 entiteiten als het laag 2 management (LM) een data-link service aan. Voor het transpon van laag 3 data is zowel een unacknowledged- als een unacknowledged service mogelijk. LM-data wordt uitsluitend op unacknowledge-basis getransponeerd (dit vanwege het feit dat daarvoor de zogenaamde broadcast-methode toegepast wordt).

Service verlening aan laag 3 De acknowledged infonnation transfer service zorgt voor het in de juiste volgorde transponeren van message-units (inclusief controle of de messages correct arriveren). Eventueel optredende fouten worden zoveel mogelijk binnen het LAPD-protocol opgelost. Onoplosbare problemen worden echter aan het Layer Management gemeld. In feite is de hier beschreven service een soon Connection-Oriented service inclusief de bijbehorende opbouwen verbreek procedures/primitieven. De unacknowledged infonnation transfer service is op dezelfde wijze te zien als een Connectionless service: er worden uitsluitend data-pakketten uitgewisseld waarbij er geen controle is of de verzonden infonnatie daadwerkelijk aankomt (geen acknowledge). Uiteraard kan acknowledgement eventueel op het niveau van laag 3 plaatsvinden.

Service verlening aan het Layer Management Het Layer Management vraagt uitsluitend een zogenaamde broadcast data-link verbinding, waarop alleen een unacknowledged service geboden kan worden.

5.2.3 Frame-structuur LAPD-frames venonen sterke overeenkomsten met HDLC-frames, een belangrijk verschil is het aanwezig zijn van een adresveld in de LAPD-frames. Doordat er bij ISDN sprake is van een busconfiguratie is deze "extra" adressering (DLCI) noodzakelijk. In een LAPD-frame zijn de volgende velden aanwezig: adres-veld (SAPI + TEl), controlveld, infonnation-veld, een Frame Check Sequence (FCS) en twee identieke begin- en eind flag's.

Flag's, transparancy Een Q.921 frame wordt geopend met, en afgesloten door een 8-bits flag (0111110). Een reeks van 6 logische enen zal dus door een ontvanger als een frame-grens herkend worden. Een dergelijke bit-sequentie mag als gevolg daarvan binnen de frame grenzen niet voorkomen (de flag uitgezonderd). Door het tussenvoegen van een logische 0 na een reeks van 5 logische enen wordt aan bovenstaande eis voldaan, zodat er geen beperkingen bestaan voor de data-inhoud van een LAPD-frame. Het LAPD protocol is dus transparant voor de aangeboden data.

ISDN Laag-2 protocol(len): 0.921 & 0.922

0.922 57

Adres-veld In het adres-veld wordt o.a. de SAPI- en TEI-waarde (= DLCn aangegeven van de gewenste bestemming. Verder wordt er in het adres-veld aangegeven of het betreffende frame een command- of response-frame is.

Control-veld Binnen Q.921 zijn er 3 verschillende frame-type gedefinieerd: 1-, S, en U-fonnat (I: Numbered info transfer, S: supervisory en U: Unnumbered/Control). De keuze daartussen is in het control-veld aangegeven. In het geval van een I-type frame wordt bovendien de toestand van het "windowing-mechanisme" aangegeven (de te ontvangen- ofte verzenden frame(nurnrners ».

Information-veld Het zal duidelijk zijn dat dit veld van de LAPD-frames bedoeld is voor laag 3 inforrnatie, in de vorrn van laag 3-SDU's.

5.2.4 0.922 Speciaal ten behoeve van frame-relaying en frame-switching wordt er in de vorrn van Q.922 een uitbreiding op Q.921 voorgesteld. Dit Q.922 protocol kan, in tegenstelling tot Q.921,op aile ISDN kanalen toegepast worden (en dus niet aileen op het D-kanaal), en is in hoge mate compatibel met Q.921. Hierdoor kan het gelijktijdig met Q.921 op een D-kanaal toegepast worden.

Uitbreidingen & wijzigingen t.o.v. Q.921 Enkele in het oog springende uitbreidingen t.O.V. Q.921 zijn o.a. de grotere frame-sizes die mogelijk zijn op aile kanalen behalve het D-kanaal, de overdracht van congestie infonnatie en het feit dat het de "core aspects" van LAPD kan bieden zoals in 1.122 is gedefmieerd. Verder worden er zogenaamde ongestructureerde DLC!'s toegepast: dus geen onderverdeling in SAPI en TEl, en zijn langere adressen mogelijk (behalve op het D-kanaal).

De signaleringsweg

59

Frame relay connecties via een ISDN B·kanaal

In dit hoofdstuk worden de procedures beschreven die binnen het ISDN uitgevoerd moeten worden voor het opzetten, en weer verbreken van framerelay connecties op B-kanalen. Hiervoor past men het eerder genoemde Q.93X protocol binnen het conn-ol-plane toe. Zoals in hoofdstuk 5 reeds is vermeld komt het Q.93X protocol in sterke mate overeen met Q.931. In dit hoofdstuk worden de procedures voor het opzetten en verbreken van frame-relay connecties zoveel mogelijk compleet beschreven; dit betekent dat een gedeelte daarvan gelijk is aan een beschrijving van Q.931 procedures. Om het lezers die bekend zijn met Q.931 gemakkelijk te maken worden paragrafen die specifieke Q.93X en/of framerelaying eigenschappen bevatten gemerkt worden met een ....

6.1 De signaleringsweg

_

Er is bier sprake van een zogenaamde CASE B situatie (voorheen ook weI het "Maximum Integratie" scenario genoemd), hetgeen inhoudt dat een user-terminal rechtstreeks toegang heeft tot een ISDN-frame relay service l . Een belangrijke consequentie daarvan is dat men de in ISDN gebruikelijke scheiding tussen user- en signalering data ook bier tegenkomt. De uitwisseling van Q.93X (laag 3) signalering berichten vindt plaats via ~n van de logische kanalen binnen het D-kanaal die op het scheidingsvlak tussen laag 2 en laag 3 beeindigd worden in Service Access Points (SAP's). De logische links binnen het D-kanaal worden geldentificeerd door Service Access Point Identifiers (SAP!' s) en Terminal Equipment Identifiers (TEl's). Voor signalering is SAPI=O gedefmieerd, terwijl er vele TEIwaarden mogelijk. zijn zodat er dus ook vele signalering-links gelijktijdig kunnen bestaan. Het uiteindelijke transport van laag 2 frames met user-infonnatie vindt op het B-kanaal plaats. 2 1 2

Zie voor een verklaring van de begrippen "CASE A" en "CASE B" boofdstuk 4. Frame-relaying via bet D-kanaal is in principe oak mogelijk (uiteraard met een veellagere transmissie snelbeid dan via een B· of H-kanaal geboden kan worden).

Hoofdstuk6

60 Frame relay conneeties via een ISDN B-kanaal

Om de bespreking van de verbindingsopbouw-procedure te vereenvoudigen zal in het vervolg het eind-systeem dat een oproep plaatst met A aangegeven worden en de ontvanger metB.

6.1.1 Message-flow van Q.93X messages In de levenscyc1us van een ISDN-frame-relay connectie zijn drie fasen te herkennen: het opzetten-, onderhouden- en verbreken van de verbinding. Deze drie fasen komen achtereenvolgens in dit hoofdstuk aan de orde.

Alvorens daadwerkelijk de diverse procedures te beschrijven eerst enkele opmerkingen over de information elements die in alle Q.93X berichten aanwezig zijn, zoals de protocol discriminator, call reference en message-type.

Protocol discriminator Met het Protocol discriminator information element wordt het gebruikte protocol aangegeven; Q.931. 8

7

6

5

4

3

2

0.931 (1.451) user-network call control messages

o

o

0

0 1 protocol discriminator

0

0

o

Octet 1

Figuur 6.1 : Codering van het Protocol discriminator information element

In messages van het Q.93X protocol zou men een speciaal voor dat protocol gedefmieerde protocol discriminator waarde verwachten. Q.93X is echter slechts een uitbreiding van Q.931, zodat voor de zelfde waarde is gekozen als bij het gewone Q.931 protocol; dat impliceert dat het voor het netwerk niet eenvoudig is om Q.931 van Q.93X berichten te onderscheiden (door bijvoorbeeld alleen naar de protocol discrimator in een bericht te kijken). Het protocol discriminator information element vormt het eerste octet van elk Q.931 & Q.93X pakket.

Call reference De Call reference zorgt voor de identificatie van de signaleringsberichten-stroom van een call op de user-network interface. Het aantal verschillende Call-reference waarden wordt

De signaleringsweg

Message-flow van Q.93X TTJ8ssages 61

bepaald door de lengte ervan: op een basic user-network interface I octet, en in het geval van een primary rate access 2octetten. 3 Een Call-reference waarde wordt door het initierende systeem gekozen. Deze waarde is uniek op de gebruikte D-kanaallaag 2 logical link, en blijft tijdens de gehele duur van de 4 call ongewijzigd (Het is wellicht duidelijk dat na beeindiging van een call de desbetreffende call-reference waarde weer vrij is voor een hemieuwd gebruik). 7

8

6

5

3

4

2

Length of call reference value

° flag

°

°

°

°

°

1

°

I

Octet 1

2 (evt 3)

Call reference value

Figuur 6.2: Codering van het Call-reference information element

Met de flag in het eerste bit van het tweede octet wordt aangegeven ofhet bericht waarin het call-reference information element is opgenomen van de initierende zijde afkomstig is of van de ontvangende zijde (0 resp. 1). De exacte keuze van een call-reference waarde is in het kader van dit verslag met van belang; er zal dan ook niet verder op ingegaan worden.

Message type Een van de information elements die altijd in een Q.93X (en ook Q.931) bericht is ondergebracht is het Message type, het geeft het bericht-type aan. Het Message type information element omvat slechts I octet, en bevindt zich direct na de Protocol discriminator en de Call reference in een Q.93X-bericht (en Q.931-bericht). In het geval van een SETUP-bericht is het op onderstaande wijze ingevuld.

8

7

6

5

4

3

2

----:._1

_....:0'--_--'0'--_'--0=---_ _0=---_ _0=---_ _..:..1_ _----"-0_ _

OCtet 1

Flguur 6.3: Codering van SETUP-message-type information element

Ben overzicht van de codering van het Q.93X-message type information element voor alle Q.93X messages is in tabel 6.1 opgenomen (De codering is identiek aan die van Q.931 3

4

Bij de Primary rate access is oak een call-reference ter lengte van ~n octet toegestaan, welke in dat geval slecbts een waarde tot en met 127 mag bebben. Deze "korte" call-reference mag ecbter, indien gewenst, toeb als twee octetten gecodeerd worden (aangevuld met nullen). AIleen in bet geval van "Call suspension" kan de Call-reference waarde gewijzigd worden. De duur van een call vangt aan bij de call establishment en eindigt na de call release.

62 Frame relay connecties via sen ISDN 8-kanaal

Hoofdstuk6

messages; Q.93X bevat echter uitsluitend de in de tabel opgenomen berichten, hetgeen een subset is van de verzameling Q.93l messages). TabeI6.1: Codering van Q.93X message-types

·ICocIerlna Q.9~Xm....ae·tVDe Call establishment messaQ9S ALERTING 0000 0001 CAU PROCEEDING 0000 0010 CONNECT 0000 0111 CONNECT ACKNOWLEDGE 0000 1111 PROGRESS 0000 0011 SETUP 0000 0101 Call clearinrJ m9SSBQes DISCONNECT 0100 0101 RELEASE 0100 1101 RELEASE COMPLETE 0101 1010 MiscellaneolJs meSSB!;9S SEGMENT 0110 0000 STATUS 0111 1101 STATUS ENQUIRY 0111 0101 Escape: nationale codes 0000 0000

."

6.2 Opzetten van een Frame-relay connectie Bij de procedure voor het opzetten van een frame-relay connectie wordt er bij aanvang verondersteld dat de betrokken apparatuur zich in de rusttoestand bevindt, en dat de TEl-assignment procedure (op laag 2) reeds heeft plaats gevonden. De toe te passen procedures zijn dezelfde als voor het realiseren van "norrnale" (circuit~ switched) B-kanaal verbindingen, waarbij nagenoeg aile Q.93X berichten enkele afwijkingen venonen in vergelijking met Q.93l berichten. Deze wijzigingen zijn speciaal voor frame-mode bearer services in het algemeen, en frame-relay bearers in het bijzonder, aangebracht. In het onderstaande komen de genoemde afwijkingen uitgebreid aan de orde. De belangrijkste Q.931 berichten voor het opzetten van framerelay connecties zijn: SETUP: Wordt door een gebruiker (in dit geval een systeem dat om een frame-relay service vraagt) naar het ISDN-netwerk gezonden voor het aanvragen van een uitgaande frame-relay connectie. Als het netwerk de oproep accepteen zal deze een SEfUP-berichten zenden naar de

Opzetten van een Frame-relay connectie

Message-flow van Q.93X messages 63

opgeroepene, de B-zijde (voor het opzetten van een inkomende connectie). CALL PROCEEDING: Is de response op een SETUP bericht; het geeft aan dat de connection request in behandeling is. CONNECT: Dit bericht wordt gezonden om aan te geven dat de eerder geplaatste oproep middels een SETUP-bericht geaccepteerd is. (Voor het vervolgens verbreken zijn de volgende berichten beschikbaar: DISCONNECf, RELEASE en RELEASE COMPLETE). TE

TE B

Netwer!<

A SETUP CALL PROCEEDING (DLCI_n)

...

I I, ---------' CALL PROCEEDING ,

CONNECT

CONNECT

1

~

1

1

- - - - - -1-·- - - - - - Data Transfer

- - - - - - -1-1- - - - - - ...:D:.;;IS:;;:C;.::;O,;;;NN~E~C.;..T_......

__

I

1

, RELEASE RELEASE COMPLETE

DISCONNECT RELEASE RELEASE COMP

E

Figuur 6.4: 0.931 message-flow voor frame-relay connection setup

In figuur 6.4 is de berichten uitwisseling van een succesvolle setup- en release-procedure afgebeeld. Deze wordt in dit verslag als uitgangspunt genomen (Het verloop van de vele niet succesvolle procedures komt slechts kon aan de orde, omdat de afhandeling daarvan in Q.93X en Q.931 aan elkaar gelijk zijn). De setup-procedure is te verdelen in een gedeelte dat van toepassing is op initierend zijde, in het vervolg de A-zijde genoemd, en een gedeelte dat betrekking heeft op B-zijde (de opgeroepene).


Hoofdstuk6

6.3 Setu~rocedure aan de A-zii_d_e

_

In deze paragraaf komt de setup-procedure voor een frame-relay call aan de orde die aan

de A-zijde uitgevoerd wordt. Daarbij wordt er vanuit gegaan dat op het moment dat deze procedure start er reeds een data-link verbinding bestaat voor het transpon van de Q.93X-berichten. (Daarvoor wordt, zoals gebruikelijk, een Q.92l datalink gebruikt met SAPI=O. Bovendien opereen het laag 2 protocol in de "Acknowledged" mode: correete transmissie van Q.93X-messages is daannee gegarandeerd).

6.3.1 Het Q.931 SETUP bericht Binnen het ISDN kunnen er een groot aantal verschillende bearerservices aan de gebruikers geboden worden, met zeer uiteenlopende eigenschappen. Een verbindingsopbouw (vanuit rust-toestand) vindt vanuit de A-zijde plaats door het verzenden van een SETUP-bericht, waarin de door de gebruiker gewenste eigenschappen van de te creeren bearer zijn opgenomen in de vonn van zogenaamde "Information-elements". De inhoud van dit initierende SEfUP-bericht is bepalend voor de eigenschappen van de op te zetten bearer. De meeste Infonnation-elements in het SEfUP-bericht zijn "optioneel", en dienen voor het realiseren van specifieke gebruikers wensen: in tabel6.2 aangegeven met "0" (Optional). "M" staat voor Mandatory (vetplicht). Tabel 6.2: SETUP-message Information element

Type

Protoc:oI discriminator caU reference Message type Bearer capability Channel identification Data link connection identifier Progress indicator Network·soecifie facilities DisPlay End-to-end transit delav Link laver core D8.rameters Link layer DrOtocol Dararneters Calina Dartv number Callina Dartv s&badclress Cded Dartv number Cded Dartv S\badclress Transit network selection R8D8Ilt indicator Low layer compatibility High laye, compatibility

0

User-user

0

M: Mandatory

M M M M

0 0 0 0 0 0 0

0 0 0 0

0 0 0 0

0: Optional

Setup procedure aan de A-zijde

Het 0.931 SETUP bericht 65

Slechts een beperkte subset van alle opties die binnen een SETUP-bericht mogelijk zijn is van belang voor het opzetten van een frame-relay verbinding. Naast de verplicht aanwezige infonnation elements (Mandatory: Protocol discriminator, Call reference, Message type en Bearer capability) zijn dat: 1. Channel Identification, 2. Data link connection identifier, 3. Link Layer Core parameters, 4. End-to-end transit delay, 5. Called/Calling party number/subaddress en 6. Low-layer compatibility.

"En-block-" en "Overlap-sending" In het ISDN bestaan er twee mogelijkheden voor de overdracht van adresseringsinformatie

(nununer 5 in het bovenstaande overzicht): "en-block-" en "overlap-"sending. Bij de eerste mogelijkheid wordt alle voor een call-setup benodigde infonnatie in het SETUP-bericht ondergebracht. In het geval van overlap-sending is er geen, of slechts een beperkte hoeveelheid adresserings-data van de gewenste bestemming in het SETUP-bericht aanwezig; aanvullende gegevens worden dan in een later stadium in de call-setup procedure op verzoek van het netwerk uitgewisseld. In het algemeen geldt dat bij packet-conununicatie via ISDN alleen de zogenaamde en-block sending is toegestaan. Daaruit kan geconc1udeerd worden dat ook bij frame-relaying deze beperking in de overdracht van adresserings-infonnatie van toepassing is. Op de volgende pagina's wordt een invulling van het SETUP-bericht zoals voor het hier gestelde doel, opzetten van en frame-relay verbinding via een B-kanaal, beschreven. De verplicht in een SETUP-bericht aanwezige information elements: Protocol discriminator, Call reference, Message type en Bearer capability zijn reeds eerderbeschrevenzodat een behandeling daarvan hier achterwege gelaten wordt.

Bearer Capability* De gewenste eigenschappen van een aangevraagde bearerservice worden aangegeven in het Bearer Capability infonnation element: Be. Daarin komen de specifieke eigenschappen voor een frame-relay conneetie tot uiting. Samen met de gegevens in het Link Layer Core infonnation element is het BC-information element in hoge mate bepalend voor de eigenschappen van de op te zetten conneetie. In het geval van frame-relaying is een frame-mode bearer-service nodig die "unrestricted" digital information kan transponeren, en waarbij op laag 2 alleen de zogenaamde core functies van het Q.922 protocol aanwezig zijn zoals in CCITI aanbeveling 1.122 is gedefmieerd.


Hoofdstuk6

Het laag 1 en laag 3 protocol wordt voor de bearer niet gedefinieerd (zoals blijkt uit het feit dat octet 5 en 7 afwezig zijn): er is hier inuners sprake van een verbinding voor de overdracht van laag 2 frames, zodat er op de "bearer" zelf binnen het ISDN geen laag 3 protocol toegepast wordt (uiteraard weI end-to-end tussen de twee via de frame-relay service verbonden eind-gebruikers). 8

7

6

5

4

3

2

1

0

Bearer capability

0

0

0

0

0

0

Octet 1

Information .....nt llHntifior

1 ext 1 ext. 1 ext.

2

Lenate van het Be information element Coding standard Information transfer capability

0

0

Transfer mode

0 0

1

0

1

0 I

0 0

0 0

(reserved)

1

0

0 0

User information layer 2 protocol

0

1

1

1

1

3 4 6

Figuur 6.5: Codering van Bearer-Capability information element

De tenn "unrestricted" geeft aan dat het B-kanaal een fysiek 64 kbit/s kanaal moet zijn. En niet beperkt is tot een capaciteit van slechts 56 kbit/s, zoals in o.a. de Verenigde Staten vaak voorkomt: het ge bit van elk octet is dan niet beschikbaar voor data, maar heeft men voor signaleringsinfonnatie gereserveerd (een bij digitale trunk-verbindingen toegepaste methode). De parameter Transfer mode wordt, aangezien frame-relay een frame-mode transmissie techniek is waarvoor een frame-mode bearer nodig is, ingevuld met: "frame-mode". NB.: De frame transfer mode is een uitbreiding ten opzichte van Q.931 dat alleen de keuze tussen circuit- en packet-mode toelaat. Voor een frame-relay call, waarbij uitsluitend de core aspects van Q.922 gewenst zijn binnen het transmissie-kanaal, wordt dit in User information layer 2 protocol aangegeven met "core aspects of frame relay". Zoals gebruikelijk wordt de standaard CCnT codering gebruikt: aangegeven in het "Coding standard"-veld.

Link Layer Core parameters'* Het Link Layer Core parameters infonnation element is bedoeld voor het aangeven van de gewenste parameters van de in het Be infonnation element gekozen "core aspects" van Q.922 (en is ··nieuwe" in Q.93X t.o.v. Q.931). Men kan hierbij denken aan afmetingen van frames en transmissie snelheden (uitgedrukt in aanta! frames per tijdseenheid), waarvan zowel gemiddelde- als minimale- en maximale waarden van belang zijn. Tenslotte is het



van belang om te weten dat ten aanzien van de Link Layer Core parameters onderscbeid gemaakt wordt tussen de inen uitgaande bearer-ricbting. AIle parameters van bet Link Layer Core information element zijn optioneel: bet information element zelf dus in feite ook, boewel bet volledig afwezig zijn ervan in een SETUPbericbt in bet kader van frame-relay connecties zeer ongebruikelijk is. Voor parameters die niet in bet Link layer core parameters information element zijn opgenomen wordt verondersteld dat bet netwerk default waarden neemt. In de onderstaande figuur is de opbouwen de codering van bet Link layer core parameters information element afgebeeld. 8

7

6

4

5

3

2

0

0

Link core parameters 0

1

0

0

1

0

Octet 1

Information element Identifier

2

Lengte 0

0

0

o ext 1 ext 0

0

o ext

0 1 Incommina maximum frame size

1 ext

Incommina maximum frame size (cont.)

0

0/1 ext

Frame mode information rate 0 0 1 Outgoing frame mode information rate

1 ext

Incoming frame mode information rate (conI.)

0

0

1

0

0

3a

4

1

0 4a

4b 0

5 1 5a 5b

Minimum acceptable frame mode information rate

0 0 0/1 ext 1 ext

0

0 0 1 1 Minimum acceptable outgoing frame mode information rate

0

Outgoing burst size 0

0

0

1

1

0

6 6a 6b

Minimum acceptable incoming frame mode information rate

0

3

3b

Incomming maximum frame size

0

I

Outgoing maximum frame size 0 0 1 Outgoing maximum frame size Outgoing maximum frame size (cont.)

1

7

o ext

OUtgoing burst size value

7a

1 ext

Outgoing burst size value (conI.)

7b

0

Incoming burst size 0

0

o ext 1 ext 0

1 ext

1

0

0

1 1 0 Outgoing maximum frame rate value

8a

1

1

0

1

0

0

9 9a

Incoming maximum frame rate 0

8

Bb

Outgoing maximum frame rate 0

1 ext 0

0 1 1 Incoming burst size value Incoming burst size value (conI.)

0

Incomina maximum frame rate value

Figuur 6.6: Unk layer core paremeters information element

0

10 10a

68 Frame relay connecties via een ISDN B-kanaal

Hoofdstuk6

Opmerklngen t.a.v. de parameters'

De lengte van een frame wordt, volgens de definitie, bepaald door het aantal octetten die zich bevinden na het adres- en voor het FeS-veld in een laag 2 frame (dus inclusief het control-veld). Op D-kanalen is de maximum frame-size beperkt tot 262 octetten. Voor Ben H-kanalen zijn langere frames toegestaan; in Q.93X wordt als voorbeeld een lengte van 4096 octetten genoemd. De frame mode information rate voor een frame-mode connection staat voor het gemiddelde aantal per seconde getransporteerde user-data bits, gemeten gedurende een bepaald tijdsinterval "t". Het interval ''1'' is nog niet gedefmieerd in Q.93X; voorgesteld wordt om de zogenaarnde round trip delay daarvoor te nemen (round trip delay = 2'" end-to-end transit delay). Met Burst size wordt de maximale overschrijding van het aantal databits ten opzichte van de gemiddelde waarde bedoeld. Codering van de gegevens in het information element vindt "gewoon" binair plaats, behalve voor de information rates: deze worden gecodeerd aan de hand van een tabel met standaard Information rates met waarden tussen 0.075 en 1920 kbits/sec (Bedoeld wordt tabel3 in de Q.93X aanbeveling). Speclfieke Invulling'

De specifieke invulling van de parameters in het link layer core parameters information veld wordt bepaald door de eisen die de te koppelen LAN's aan de transrnissie stellen. Hierop wordt in hoofdstuk 7 nader ingegaan.

Link layer protocol parameters Het link layer protocol parameters information element dient om bepaalde, af te spreken, parameters van het end-to-end gebruikte laag 2 protocol (zoals afmetingen van windows) door te gegeven (Dit is geldig voor frame-relaying: bij frame-switching worden deze parameters met het netwerk zelf afgesproken). Dit information element komt in Q.931 niet voor. Het toepassen van dit information element is slechts nuttig als van het complete Q.922 protocol gebruik gemaakt (De core-functies binnen het net, en de rest van Q.922 end-toend).In het kader van de afstudeeropdracht is dit niet het geval, zodat de bespreking van het link layer protocol parameters information element hier overbodig is. .

Voor aile duidelijlc: voor het opzetten van een normale frame-relaying conneetie heeft dit infonnation element geen betekenis.



End-to-end transit delay* Het doel van het end-to-end transit delay information element is het aangeven van de gewenste-, of maxirnaal toelaatbare transit delay op de frame mode bearer service. De transit delay gegevens kunnen per "call" verschillend zijn. Het opnemen van het end-to-end transit delay information element in een setup bericht dat naar het netwerk toe wordt gestuurd, houdt in dat het netwerk verzocht wordt om de te verwachten end-to-end transit delay te bepalen en deze vervolgens aan de user mede te delen in een respons bericht (bijvoorbeeld CONNECT). Optioneel kan een user de gewenste- en maxirnaal-toelaatbare transit delay aan het netwerk melden. Invulllng van de parameters

De specifieke invulling van het transit-delay information element ten behoeve van framerelaying voor de interconnectie van IEEE 802 LAN's (zoals in dit verslag aan de orde is) is afbankelijk van de eisen die zo'n LAN stelt aan het interconnectie medium (dat hier bestaat uit een frame-relay bearer service op een ISDN B-kanaal). Niet alle velden hoeven aanwezig te zijn; zo mogen de octetten 4 en 5 weg gelaten worden. De transit-delay's worden opgegeven in "milli seconden". 8

7

6

5

4

2

3

End-to-end transit delay

0

1

0

0

0

0

1

1

Octet 1

Infor.....tion e'-me'" identifier

2

LenQth of end-to-end transit delav contents

0

o ext.

0 0 0 Cumulative transit delay value spare Cumulative transit delay value (cont.)

3a

1 ext.

Cumulative transit delay value (cont.)

3b

o ext.

0

0

0

o ext.

0

0

0

spare

Requested end-toend transit delay value

3

4

o ext.

Requested end-to-end transit delay value (cont.)

4a

1 ext.

Requested end-to-end transit delay value (cont.)

4b

0

o ext.

0

0 spare

0

0

Maximum end-toend transit delay value

5

o ext.

Maximum end-to-end transit delay value (cont.)

5a

1 ext.

Maximum end-to-end transit delay value (cont.)

5b

Figuur 6.7: Codering van het End·to-end transit delay information element

Channel identification * Na de bespreking van een aantal information elements die betrekking hebben tot de eigenschappen van de bearer-service komen nu een aantal information elements aan de

70 Frame relay conneeties via een ISDN B-kanaa'

Hoofdstuk 6

orde die bepalend zijn voor adressering en identificatie van de op te zetten frame mode bearer. Het eerste te bespreken information element is bedoeld voor de kanaal-identificatie van het fysieke kanaal. In het Channel Identification information element wordt aangegeven welk kanaal een user wil gebruiken. In principe kan er op de Basic Access gekozen worden uit het D-, BI- of B2-kanaal. (Op een zogenaamde primary access heeft men naast het D-kanaal toegang tot H-kanalen). Hierbij zijn twee opties mogelijk: "preferred" en "exclusive". De eerste optie geeft slechts een voorkeur aan, waarbij het netwerk (of user-tenninal) nog enige vrijheid heeft in de keuze van een eventueel ander (beschikbaar) kanaal. Indien de optie "exclusive" wordt toegepast zal het netwerk (of user-terminal) uitsluitend het aangegeven kanaal gebruiken, tenzij dit reeds bezet is. In het laatste geval wordt de setup-procedure afgebroken door het netwerk. Het Channel Identification information element is in principe slechts optioneel in een SETUP-message aanwezig. Bij afwezigheid heeft het netwerk alle vrijheid in de keuze van het te gebruiken kanaal (mits passend bij de gewenste bearer-capability). In het kader van de afstudeeropdracht is bepaald dat er alleen van een B-kanaal gebruikt mag worden voor frame-relaying. Het zal daarom duidelijk zijn dat de Channel Identifier bier weI in het setup-bericht aanwezig moet zijn: het netwerk moet irnmers gedwongen worden om een B-kanaal te gebruiken (en geen D-kanaal), waarbij de keuze van het specifieke B-kanaal nog weI aan het netwerk overgelaten kan worden. Voor het invullen van het Channel Identifier information element wordt in de Q.93X standaard verwezen naar Q.931. Er zijn een groot aantal mogelijkheden. In het kader van de afstudeeropdracht is er voor gekozen om het netwerk de keuze tussen een van beide B-kanalen te laten doen; deze functie is in het kader van dit verslag niet essentieel, maar het verplaatsen van de uitvoering ervan naar het netwerk vereenvoudigd de beschrijving van de procedure. De bier gekozen invulling is in figuur 6.8 afgebeeld (Er is in aangegeven dat het netwerk. zelf een beschikbaar B-kanaal mag kiezen, maar het D-kanaal moet ongemoeid blijven). 8 0

7 0

6

5

3

2

0

Channel Identification 1 1 0

0

4

0

Octet 1

InIormaIIon .......n1 idenIHIer

ext

Interface Identifier

present 1

0

Interface type

0

Le gte Preferred/Exspare clusive

0

0

2 O-ehannelindicator

0

Information channel

selection 1

1

Figuur 6.8: Codering van het Channel Identification Infonnation element

3



B-kanaal keuze mogelljkheden'

In verband met het feit dat er gelijktijdig meerdere frame-relay connecties mogelijk zijn op een B-kanaal dient er een kleine wijziging in de procedure aangebracht te worden zoals die in Q.931 gedefmieerd is voor de behandeling van het Channel Identification information element. Het is namelijk mogelijk dat op een B-kanaal dat al voor frame-relaying in gebruik is een extra frame-relay connectie gerealiseerd dient te worden (multiplexing op een B-kanaal). De keuze mogelijkheden voor B-kanalen in het bier beschreven geval, Case B en framerelaying via B-kanalen, zijn in de volgende tabel samengevat.

Tabel 6.3: B-kanaal keuze mogeJijkheden

Channel Indicated In the SETUP mesalge US8f to network direction Pr8ferted or &clus~e Preferred Exclusive Preferred Preferred Exclusive

Chatlnelldentificatlon

Bi Any channel

No channel Absent

Atlowable network r.sconse NelWori(-user

Bi Bi Bi

Bk

.

Bi

In deze tabel worden met Bi en Bj B-kanalen aangeduid die zich in de "Idle"-toestand bevinden of reeds voor frame-relaying in gebruik. zijn, waaJbij Bi staat vooreen specifiek en Bj voor elk (bestaand) B-kanaal. Tenslotte wordt met Bk een B-kanaal bedoeld dat reeds door een frame-relay verbinding in gebruik is. S

De uiteindelijke keuze voor het te gebruiken B-kanaal is in principe afhankelijk van de specifieke wensen van de gebruiker (in dit geval de A-abonnee), en wordt kenbaar gemaakt in een Channel Identification information element van het eerste, door het netwerk, te verzenden respons-bericht (zie figuur 6.4, op pagina 63). Afhankelijk van de in het SETUP-bericht aangegeven opties wordt het netwerk slechts beperkte reactie mogelijkheden geboden. De mogelijke reactie van het netwerk op het in deze paragraaf beschreven SETUP bericht is in tabel 6.3 cursief aangegeven. In dit geval (Bj) kan het netwerk elk vrij B-kanaal kiezen, of een B-kanaal dat al in gebruik is voor een frame-mode bearer service en waarop nog voldoende transmissie-capaciteit beschikbaar is. Data Link Connection Identifier*

De frame-relaying techniek maakt gebruik van de core-funeties van het ISDN Laag-2 protocol (Q.922) waarmee multiplexing van meerdere logische kanalen (data-links) mo5

De in de label opgesomde mogelijkbeden gelden ook voor H-kanalen; deze vallen ecbter builen bet bestek van dit verslag.

72 Frame relay conneeties via 96n ISDN B-kanaal

Hoofdstuk6

gelijk is op een enkel fysiek kanaal. De identificatie van de verschillende data-links vindt, binnen de datalink-laag, in het geval van een B-kanaal, plaats door middel van een zogenaamde Data Link Connection Identifier (DLCl). Bij een D-kanaal is deze "DLCI" opgesplitst in een Terminal Identifier (TEl) en SenJice Access Point Identifier (SAPIl De TEl is in dit kader te vergelijken met een tijdelijk geldend terminal-adres (waarvan er zich meerdere in een fysieke terminal kunnen bevinden). Tenslotte geeft een SAPI-waarde het service-type aan. N.B.: Zo wordt signalering-infonnatie via betD-kanaal uitgewisseld met SAPI waarde 0, en bebben Packet Mode connecties (confonn X.25 PLP procedures) via een D-kanaal SAPI waanle 1. Voor frame-relay connecties is geen speciale waarde gereserveerd.

Bij gebruik van dezelfde service, bijvoorbeeld signalering m.b.v. SAPI=O, door meerdere terminals treft men dezelfde SAPI-waarde in combinatie met verschillende TEl's aan. Speciaal ten behoeve van een (zeer) groot aantal verschillende frame-mode bearers, die bijvoorbeeld op een H-kanaal gemultiplexed kunnen worden (op B-kanalen zijn de multiplexing mogelijkheden beperkter door de geringere transmissie-capaciteit daarvan), heeft men het aantal beschikbare DLCI-waarden in Q.93X sterk uitgebreid ten opzichte van de mogelijkheden in het Q.931 protocol. Dit komt tot uiting in de mogelijk grotere lengte van het Q.93X DLCI-information element. Het zal duidelijk zijn dat het voor het opzetten van een frame-relay connectie via een B-kanaal niet voldoende is om tijdens de opbouwfase alleen een B-kanaal overeen te komen, maar dat er tevens voor de betreffende connectie een DLCI-waarde afgesproken moet worden. Daartoe heeft men in Q.93X (in vergelijking met Q.931) het DLCI-information element toegevoegd. De DLCI-waarde zal (later) op de betreffende user-netwerk-interface in elk Q.922 frame aanwezig zijn. Merk op dat er op de verschillende user-netwerk en netwerk-netwerk interfaces die in gebruik zijn voor een frame relay conneetie verschillende DLCI waarden kunnen voorkomen: Ben DLeI heeft slechts een lokale betekenis; het netwerk zal voor een correcte mapping zorgen.

6

Vanuit laag 3 wordt de DLCI, die volgens bet ISDN-model uitsluitend binnen laag 2 bestaat, gezien als Connection End-point Identifier (CEI) die voor bet D-kanaal bestaat uit een SAPI en Connection End-point Suffix (CBS). De DLCI- en CEI-waarden zijn ~~n-o~n met elkaar verbonden zodat in de praktijk een bepaalde "iDtetface" tossen laag 2 en laag 3 zowel met een DLCI- ais CEI·waarde aangeduid tan wolden. In bijoa alle publikaties treft men alleen de DLCI aan.



OLCI & het SETUP-berlcht"

In het algemeen bevat het Q.93X SETUP-bericht in het geval van frame-mode bearer

services het DLCI information element samen met het Channel Identification information element. (V oor de identificatie van een frame-mode bearer birmen een D-kanaal mag het Channel Identification element afwezig zijn). Bij afwezigheid van het DLCI-information element wordt het netwerk geacht zelf een waarde aan de betreffende data-link toe te kennen. Deze waarde wordt dan in het eerst volgende respons-bericht vanuit netwerk aangegeven: bijvoorbeeld in een DLCI-information element van een Q.93X-CALL PROCEEDING- of eventueel CONNECf-bericht). Analoog aan de situatie bij het Channel Identification information element is in het kader van de afstudeeropdracht besloten de keuze van een DLCI-waarde aan het netwerk over te laten. Dit wordt automatisch bereikt door het weglaten van het DLCI information element uit het door de A-zijde te verzenden SETUP-bericht. De opbouw van het OLCllnformatlon element"

8 0

7

6

0

0

5

4

3

2

Data Link Connection Identifier 1 0 1

0

1

Octet 1

Information .I.m.nt Id.ntifi.r

o ext 0/1 ext.

Prefl

ExC11

Lengte Data Link Connection Identifier (Mo8t .lgnIflcant

Data Link Connection Identifier

I

Reserved'

Data Link Connection Identifier /3l'd

1 ext.

3

e bita)

(2nd mo8t IignHlcant 5 blta)

0/1 ext.

2

3a 3b

-.tlllanlftcont 7 bi181

Data Link Connection Identifier (4111 mo8t -'anlficant 7 blta)

3c

Figuur 6.9: Codering van het OLel information element

In het hier besproken Q.93X-SETUP bericht is het DLCI information element niet opgenomen. In andere Q.93X-berichten, zoals CALL PROCEEDING of CONNECT, zal het DLCI information element weI opgenomen worden. In voorbereiding daarop zal de opbouw ervan hier toch besproken worden. De opbouw van het DLCI information element is in figuur 6.9 afgebeeld. Het bevat naast de gebruikelijke Information element identifier- en een lengte veld de eigenlijke Data Link Connection Identifier waarde, en een indicatie of de gegeven waarde "Preferred" of "Exclusive" is (2e bit van bet 3e octet). De default lengte voor de DLCI is 2 octetten zodat octet 3b en 3c niet altijd aanwezig hoeven te zijn.


Hoofdstuk 6

Tens/otte: Speciaal ten behoeve van de afhandeling van congestieproblemen binnen het netwerk heeft men twee bits in het DLCI-infonnation element gereserveerd voor het melden van opgetreden congestie (bit 1 en 2 van octet 3a). Hierop zal in een later stadium nader ingegaan worden, zie hoofdstuk 7. Called party number Ben van de meest essentiele gegevens die vereist is voor het opzetten van een verbinding is adresserings-infonnatie (in de vonn van netwerk-adressen). In Q.93X wordt naar het ISDN-laag 3 protocol Q.931 verwezen als het gaat om Called/Calling-party- numbers/subaddresses. In Q.931, en dus ook in Q.93X, zijn er een aantal verschillende adres-typen mogelijk: naast het gebruik van een ISDN-nummerplan is ook toepassing van niet ISDN-nurnmerplannen waaronder telex-, data- nationale standaard-, prive-nummerplannen, etc. mogelijk. En verder het eventueel in gedeelten transporteren van nummer-infonnatie (bijvoorbeeld in het geval van interworking met een "gewone" PSTN-telefoon). Verder kan binnen een bepaald nurnmerplan nog onderscheid gemaakt worden tussen een intemationaal-, nationaal-, abonnee- of netwerk specifiek-nurnmer. Ook zijn verkorte nummers mogelijk. Tenslotte is het nog interessant om op te merken dat het mogelijk is om nummerinfonnatie de kwalificatie "unknown" te geven als een user of netwerk geen kennis heeft over type. 8

7

6

5

4

3

2

0

0

Called party number

0

0

0

1

1

1

Octet 1

Information .I• .".nt ~ntiMr

Lel'lQte

1 ext. 0

Type of Number

I

Number plan Identifier

Number digits

2 3 4

(lAS charKt.ro)

Flguur 6.10: Codering van hat Called party number Information element

Bij frame-relaying zijn in principe alle mogelijkheden bruikbaar. Het gebruik van een "echt" ISDN-nummer (volgens E.163/E.164) ligt echter voor de hand voor de adressering bij een ISDN-frame-relay-service. Verder is het voor het principe van frame-relaying niet van belang of er sprake is van een numrner met nationale-, intemationale-betekenis etc. Evenals bij "standaard" ISDN signalering volgens het Q.931 protocol zal het netwerk zelf zorgen voor interpreteren van adresseringsgegevens, waarbij het nurnmer-type en nummerplan in principe niet van belang zijn. Het zal inmiddels duidelijk zijn dat in het kader van dit verslag het gebruik van het norrnale ISDN-nummerplan (volgens E.l64) als uitgangspunt genomen zal worden. Met bijvoorbeeld zogenaamde intemationale numrners. Zoals reeds eerder gezegd: de andere mogelijkheden zijn in principe ook bruikbaar!



De algemene codering van het Called party number infonnation element is in figuur 6.10 afgebeeld. De verschillende velden zullen aan de hand van de eerder omschreven keuze behandeld worden (voor meer infonnatie omtrent bijvoorbeeld altematieve invullingen van het Called party number infonnation element wordt verwezen naar de Q.931 standaard). Het veld Type of number wordt in dit verslag als "international number" (0 0 1) gedefmieerd. Dit houdt automatisch in dat er geen prefix- of escape-digits toegepast worden zoals bij andere types gebruikt worden om bijvoorbeeld een "uitvlucht" te hebben naar een ander nummertype zoals een internationaal nummer. Zoals reeds eerder venneld is, is voor het ISDN-numrnerplan gekozen, zodat Number plan identifier als voIgt ingevuld wordt: "ISDN/telephony numbering plan (Rec. E. 164/E. 163 )" (0001).

Tenslotte wordt het uiteindelijke (intemationale) ISDN-nummer in het veld Number Digits ondergebracht: gecodeerd in IA5 karakters, zoals in Q.931 is voorgeschreven.

Called party subaddress In het Called party subaddress infonnation element kunnen adressen ingevuld worden van "tenninals" die zich "achter" een ISDN-aansluiting bevinden, zoals bijvoorbeeld LANstations. 8 0

7 1

6

5

3

2

1

Called party subaddress 0 0 1

0

4

1

Octet 1

Information el..... nt identifier

1 ext

Lellate Type of subaddress oddI.y"~ I dcator 0 0 0 Subaddress information

2 0

spare 0

0

3

4, etc.

Flguur 6.11 : Codering van Called party subadress information element

In het Called party subaddress infonnation element kan zowel een zogenaamd NSAPadres volgens X.213/ISO 8348 AD2 ondergebracht worden als een door een gebruiker zelf te kiezen codering/infonnatie. Het doel van de op te zetten frame-relay verbinding is het koppelen van IEEE 802 (= ISO 8802) LAN's, welke passen binnen de structuur van het OSI-referentie model, en daarom gebruik (kunnen) maken van NSAP-adressen. Het ligt dan ook voor de hand om van dat adres-type gebruik te maken. Bovendien worden er daardoor een aantal potentiele adresserings-problemen binnen de interworking unit voorkomen, omdat hierdoor automatisch de benodigde adresserings gegevens beschikbaar zijn.

Hoofdstuk6


De structuur van het Called party subaddress infonnation element is in figuur 6.11 afgebeeld. Zoals bekend is gekozen voor het NSAP Type of subaddress. Het veldje Odd/even indicator in octet 3 is hier niet in gebruik omdat er NSAP-adressen toegepast worden. Tenslotte dient nog venneld te worden dat het Called party subaddress infonnation element maxirnaal 23 octetten kan bevatten. Daarvan zijn er 20 beschikbaar voor het subaddress, hetgeen voor NSAP-adressen voldoende is.

Calling party number De Calling party number- en Calling party subaddress infonnation elements zijn voor een ontvanger bedoeld om de herkomst van een SETUP-bericht te kunnen bepalen. Behoudens enkele uitzonderingen komt de opbouw (en daarmee ook de invulling) overeen met die van het Called party number. (Dit geldt eveneens voor het bijbehorende subadres) Het Calling part)' number infonnation element bevat echter twee extra velden, te weten: Presentation indicator, Screening indicator. Beide velden hebben een functie die voor het realiseren van een frame-relaying verbinding niet van belang is, en zullen dan ook met een (soon) default waarde gevuld worden, respectievelijk "Presentation allowed" (0 0) en "User-provided, not screened" (0 0). 8

7

S

6

4

3

2

1

0

Calling party number

0

1

1

1

0

0

Octet 1

Information -'emen! Identifier

2

Lengte Type of number

0/1 ext

0 1 ext

0

Presentation indicator

0

Number plan identifier

1

0

0

spare

0

0

0

3 1

Screening indicator

3a

0

Number digits (lAS charcters)

4, etc.

Flguur 6.12: Codering van Calling party number infonnation element

Het zal duidelijk zijn dat een zender zijn eigen adres in dit infonnation element invult.

Calling party subaddress In het Calling part subaddress wordt het NSAP-adres aangegeven van de "afzender" van

het SETUP-bericht; op dezelfde wijze gecodeerd als het Called party subaddress.


Setup procedure san de A-zijde

8

7

6

5

3

4

2

Called party subaddress

0

1

1

1

0

0

0

1

Octet 1

information -....m ldenltfi.r

Lengte Type of subaddress

1 ext

0

0

0

I~·vn~ dlcalor

]

2 spare

0

0

0

Subaddress information

3

Figuur 6.13: Codering van Calling party subaddress information element

Low layer compatibility Het Low layer compatibility ~LLC) information element, welke transparant door het netwerk getransporteerd wordt , geeft een geadresseerde entiteit de mogelijk.heid om te controleren of een bepaalde call-request geaccepteerd kan worden: met het oog op een eventuele incompatibiliteit tussen de "terminal" van de oproeper en de opgeroepene. Verder is er in principe gelegenheid voor onderhandeling over de opties die in het LLC aangegeven worden 8; dit is bij frame-relaying niet van toepassing. In het LLC-information element wordt informatie ondergebracht betreffende de binnen een user-terminal toe te passen lagere laag protocollen (1 Vm 3). In het algemeen zullen die gegevens overeen komen met die in het Bearer-Capability information element. Maar omdat het ISDN-netwerk het BC-information element weI, en het LLC-information element niet mag wijzigen is het duidelijk dat het LLC primair voor end-to-end compatibility checking/negotiation bedoeld is. Een mogelijke codering van een LLC-information element dat deel uitrnaakt van een SETUP-bericht voor het opzetten van een frame-relay connectie is in figuur 6.0 afgebeeld. Merk op dat in deze figuur het 5eoctet, waarin laag-l protocol-informatie in ondergebracht kan worden, ontbreekt. Laag 2 &3 protocol/en'"

Twee velden van het LLC-information element zijn in het kader van de hier op te zetten verbinding van belang, namelijk het User information layer 2 ell 3 protocol. Op laag 3 wordt ISO 8473 toegepast (gecodeerd met 01001), en op laag 2 het LAN-LLC protocol (ISO 8802/2) of het volledige Q.922 protocol (gecodeerd met resp. 01100 en 01110).

(Zie voor de codering van andere protocollen de beschrijving van Q.922)

7 8

De mogelijkbeid voor bet (transparant) overdragen van een LLC-information element door een ISDN is slecbts optioneel: bet netweIk k.an dit information element verwijderen. Met name worden bier de parameters bedoeld die betrekking bebben op bet in gebJUik njnde laag 1 protocol. En de eventueel toegepaste (bit) rate-adaptation (volgens bijvOO1'beeld V.120).


7

8 0

1

Hoofdstuk6

6

5

3

2

1

Low layer compatibility 1 1 1

0

4

0

Octet 1

InfI>,matiorl .......nllderltift.,

1

Coding standard

1

Transfer mode

2 3

Lenate Information transfer capabilitv

0

0

0

0

0

4

R...rved

1

1

0

Lav., 2 Id.m.

1

1

1


6


7

1_ 3ldenl

Figuur 6.14: Codering van het Low layer compatibility information element

6.3.2 Reactie op het SETUP-bericht Nadat het in de vorige paragraafbeschreven SETUP-bericht in de richting van het netwerk is gezonden, wacht de "tenninal" op een reactie daarop. Een mogelijke reactie kan bestaan uit het ontvangen van een CALL PROCEEDING bericht, zoals in figuur 6.4 is afgebeeld. Aangezien het CALL PROCEEDING bij een succesvolle verbindingsopbouw een nOIDlale reactie vonnt op een SETUP verzoek, zal dit in de volgende paragraaf besproken worden. Andere resctles

Het ISDN-netwerk kan afbankelijk van de momentane toestand van de betreffende User/Network-interface op een aantal verschillende manieren reageren op een binnenkomend SETUP-bericht. Indien het netwerk de oproep kan accepteren (er is dan capaciteit beschikbaar op een B-kanaal, en de in het SETUP-bericht aangegeven parameters zijn acceptabel) zal de gelnitieerde verbindingsopbouw voortgezet worden met het terugzenden van bijvoorbeeld CALL PROCEEDING naar de A-zijde; zie de volgende paragraaf. N aast een respons in de vonn van een CALL-PROCEEDING-bericht, is in principe ook beantwoording van de ontvangen call-request mogelijk door middel van het SETUP ACKNOWLEDGE- of ALERTING-bericht (In dit verslag zal alleen ingegaan worden op de eerst genoemde mogelijkheid. SETUP ACKNOWLEDGE geeft aan dat de call-setup geaccepteerd is, maar dat er nog aanvulleode informatie door de A-zijde verstrekt moet worden (bijvoorbeeld in bet geval van overlap-sending). In bet kader van frame-relaying call's is dit bericht Diet van toepassing.

Het ALERTING bericht geeft aan dat aan de B-zijde de "called-user alerting" in wedcing is getreden. Het is wellicht duidelijk dat dit bericht Diet door de ISDN-centrale gegenereerd wordt, maar door de terminal aan de B-zijde. In het eerder gegeven voorbeeld voor de uitwisseling van Q. 931-berichten ten behoeve van een frame-relay connectie-setup (tiguur 6.4) komt bet ALERTING-bericht Diet voor: in bet kader van een veIbindingsopbouw


Reaetie op het SETUP-bericht 79

voor een frame-relay connectie is dat bericht Diet essentieel (dus slechts optioneel in gebruik) zodat daar in dit verslag verder geen aandacht aan besteed za] worden.

Atbreken van de opbouwprocedure is ook mogelijk. Een ISDN-Netwerk zal de opbouwprocedure afbreken als er bijvoorbeeld geen B-kanaal (of een gedeelte daarvan in het geval dat er voor de op te zenen frame-relay verbinding genoegen genomen kan worden met een transmissie-capaciteit die lager ligt dan het maxirnaal haalbare op een B-kanaal) vrij is. In de geschetste situatie zal het netwerk reageren met een RELEASE COMPLETE bericht met als cause "no circuit/channel available", waardoor de initierende terminal in de zogenaamde "null" toestand zal terug keren. Een andere reden voor het weigeren (en als gevolg daarvan afbreken) van een SETUP-request door het netwerk is het niet bestaan, of beschikbaar zijn, van een route naar de gewenste bestemrning. Bijvoorbeeld omdat het gekozen nummer dat aangegeven is in de adres-velden in het SETUP-bericht niet (meer) bestaat. Verder is het mogelijk dat er, eventueel tijdelijk, geen verbindingsweg naar de gewenste abonnee beschikbaar is (bijvoorbeeld door een storing in het netwerk). Daarnaast kunnen problemen met de gevraagde bearer-capability de oorzaak voor weigering door het netwerk zijn. Ook in de bovengenoemde gevallen zal het verbreken/weigeren van de call-setup plaatsvinden door het zenden van een RELEASE COMPLETE bericht, met daarin een passende cause. Voor de gemteresseerde lezet zijn hieronder mogelijke "causes" opgesomd die in bet genoemde RELEASE COMPLETE bericht ondergebracht kunnen worden. "no circuit/channel available" "unassigned (unallocated) number" "no route to destination" "number changed" "invalled number fonnat (incomplete number)" "bearer capability not authorized" "bearer capability not presently available" "service or option not available, unspecified" "bearer service not implemented"

Uiteraard is er ook een succes-volle call setup mogelijk: het netwerk accepteen de call-setup en gaat over tot het opzenen van de gewenste verbinding (en zendt een CALL PROCEEDING bericht terug). Enige tijd later meldt het netwerk dan dat de verbinding tot stand is gekomen (de B-zijde heeft "opgenomen") in de vorm van het CONNECf bericht.

80 Frame relay conn8Cties via een ISDN B-kanaal

Hoofdstuk6

6.3.3 CALL-PROCEEDING aan A-zijde In deze paragraaf wordt aandacht besteed aan de netwerkreactie in de vorm van het CALL PROCEEDING-bericht. In vergelijking met Q.931 bevat het CALL PROCEEDING bericht in Q .93X een extra information element, namelijk de Data link connection identifier De eerste drie infonnation elements komen in aIle Q.93X (en Q.931) berichten voor, en zijn reeds in het voorgaande behandeld. Vande overige zullen in het kader van dit verslag de progress indicator- en het displayinformation element niet behandeld worden. Deze vervullen inuners geen speciale rol tijdens het opzetten van een frame-relay connectie. Een user heeft echter geen zeggenschap over de informatie die het netwerk in responsberichten opneemt, zodat niet uit te sluiten is dat deze twee infonnation elements in het CALL PROCEEDING bericht zijn opgenomen: De user apparatuur mag ze eventueel negeren. Tabel 6.4: CALL PROCEEDING-message

Information element Protocol discriminator Call reference Messace tvDe Channel identification Data link connection identifier Proaress indicator Disglav

M: Mandatory

Type M M M M M

0 0

0: Optional

WeI belangrijk zijn het DLCI- en Channel Identification information element: deze geven de identificatie van de te gebruiken verbindingsweg aan de user-apparatuur door.

Channel Identification

.

Rekening houdend met de door de user in het SETUP-bericht "uitgesproken" voorkeur voor een bepaald B-kanaal Idest het ISDN-netwerk het daadwerkelijk te gebruiken B-kanaal. De gemaakte keuze wordt, zoals reeds eerder besproken is, bekend gemaakt in het eerst volgende respons-bericht op het van de user ontvangen SETUP-bericht; in de hier beschreven situatie is dat het CALL PROCEEDING bericht. De door het netwerk gemaakte keuze is dwingend; aangegeven met "Exclusive", Berder is vermeld dat het netwerk in het kader van de afstudeeropdracht de kanaal-keuze op zich neemt. In het Channel Identification information element in het SETUP-bericht werd aangegeven dat elk B-kanaal, in tegenstelling tot het D-kanaal, beschikbaar was voor de op te zetten frame relay call, zie in figuur 6.8. Het netwerk zal dan ook Idezen voor een vrij B-kanaal, of eventueel een reeds voor een andere frame-relay call in gebruik zijnd B-kanaal. Zie tabel 6.3 voor meer informatie over de B-kanaal keuze mogelijkheden van het netwerk (Het D-kanaal blijft oak hier als drager voor een frame-relay call buiten beschouwing).


CONNECT,

aan A-zijde

81

OLel * Naast het te gebruiken B-kanaal wordt in het CALL PROCEEDING bericht de door het netwerk gekozen DLCI-waarde aangegeven (in het eerder beschreven SETUP bericht was het DLCI infonnation element niet aanwezig, hetgeen automatisch inhoudt dat het netwerk een waarde moet kiezen) 9. Met name in het geval dat er met behulp van een en hetzelfde B-kanaal meerdere frame-relay calls gerealiseerd worden is de toewijzing van de DLCI-waarde van groot belang.

6.3.4 CONNECT, aan A-zijde Nadat aan de B-zijde de daar uitgevoerde setup-procedure succesvol is beeindigd (de B-zijde "neemt op") wordt dat aan de A-zijde door het netwerk kenbaar gemaakt met het CONNECT bericht. De infonnation elements die in het Q.93X bericht kunnen voorkomen zijn in tabel 6.5 afgebeeld. TabeI6.5: CONNECT-message Information element Protocol discriminator Call reference Messaae type Channel identification Oata link connection identifier Progress indicator Oisplav End-to-end transit delav Link laver core parameters Link layer protocol parameters Connected number Connected subaddress Low layer compatibility User-user

M: Mandatory

9

TVDe M M M

0 0 0 0 0 0 0 0 0 0 0

0: Optional

Speciaal ten beboeve van frame-relaying is er in de CALL PROCEEDING message nrimte gereserveenl voor een DLCI-waarde. Oit is in vergelijking met andere ISDN-bearer services, waamij een B-kanaal zoals gebruikelijk volledig door ~n connectie bezet wordt Diet nodig. Maar in bet geval van frame-relaying is bet mogelijk om meerdere datalinks onder te brengen in 66n B-kanaal, zodat bet uitsluitend aangeven van bet gekozen B-kanaal Diet voldoende zou zijn.

82 Frame relay conneeties via een ISDN B-kanaa'

Hoofdstuk6

Het CONNECT-bericht speelt bovendien een rol in de onderhandeling over de QOS en link core parameters van de frame-relay bearer. Met QOS wordt hier de transit delay van de verbinding bedoeld.

•

"Parameter negotiation" & Transit delay/Link layer core parameters

Van belang bij de parameter negotiation zijn de transit delay, en link layer core parameters zoals: maximum frame size, frame mode information rate, burst size en maximum frame rate. Als er in het van de A-zijde atkomstige SETUP-bericht geen waarden voor de genoemde parameters is opgenomen zal het netwerk de default waarden nemen: deze moeten dan aan de A-zijde doorgegeven worden, in transit delay- en link layer core parameters information elements. Deze information elements komen niet voor in het CALL PROCEEDING bericht, maar kunnen weI opgenomen worden in het CONNECT bericht. In de huidige versie van Q.93X heeft men het opnemen van de genoemde information elements in die gevallen dat het netwerk default waarden gaat gebruiken, ten onrechte niet genoemd. In het andere geval, als er weI waarden voor de genoemde parameters in het SETUP-bericht zijn opgenomen (zoals in het in dit verslag beschreven geval), zal het netwerk nagaan of de gewenste bearer-kwaliteiten geleverd kunnen worden. Als dat zo is dan zullen die waarden voor de bearer-service gebruikt gaan worden (Dit hoeft dan niet aan A-zijde gemeld te worden). In gevallen waarin het netwerk de gevraagde service niet kan bieden zal getracht worden een bearer-service met lagere kwaliteiten te bieden (deze moet dan weI aan de, door de A-zijde, gestelde minimum eisen voldoen: anders zal de verbindingsopbouw afgebroken worden middels het RELEASE COMPLEET bericht). De "slechtere" parameters die bij die altematieve bearer service horen zullen zowel aan de B-zijde doorgegeven worden (in het SETUP-bericht dat naar de B-zijde gezonden wordt) als aan de A-zijde door middel van het CONNECT-bericht. (Ook dit gebruik van het CONNECT bericht is men in de huidige Q.93X-versie vergeten). Invloed van de B-zljde

In het voorgaande is wellicht gesuggereerd dat de hierboven beschreven onderhandeling over de genoemde parameters alleen afhankelijk is van de A-zijde en het netwerk. Uiteraard heeft ook de B-zijde hier indirect invloed op: als er aan die zijde beperkingen bestaan ten aanzien van de bearer-kwaliteit zullen deze kunnen doorwerken in door het netwerk gekozen parameters.

De "Mandatory" information elements De eerste drie information elements, die verplicht in elk Q.93X bericht, zijn reeds eerder aan de orde geweest: zie het begin van dit hoofdstuk.

Data Transfer fase

CONNECT, aan A-zijde 83

Channel Identification & OLCI information element * It De Channel identification en DLCI infonnation elements zullen Diet in het CONNECf bericht aanwezig zijn: deze gegevens waren reeds in het CALL PROCEEDING bericht opgenomen (in de bier beschreven situatie).

Connected number & Connected subaddress * De Connected number- en Connected subaddress- infonnation elements kunnen in het geval van call-suspension gebruikt worden om aan de A-zijde de identiteit van de B-abonnee te melden. Aangezien dit geen specifieke functie voor frame-relaying is zal er in het kader van dit verslag verder geen aandacht aan worden besteed. WeI moet opgemerkt worden dat deze infonnation elemenst niet in Q.931 voor komen.

Low layer compatibility Evenals het SETUP-bericht kan het CONNECf-bericht een Low layer compatibility infonnation element bevatten. Dit infonnation element is in het hier behandelde CONNECf-bericht aanwezig als het ook opgenomen was in het CONNECT-message aan de B-zijde. Verder zal het gebruikt worden als er over de Low Layer Compatibility onderhandeld wordt tussen A- en B-zijde. Hetgeen bier Diet het geval zal zijn: er wordt uitgegaan van drie vrij "starre" interworking-scenario's. Bovendien is de onderhandelings procedure gelijk aan die van Q.931, en dus Diet zo interessant in het kader van dit verslag. Reeds eerder werd venneld dat het transparant door het netwerk getransporteerd wordt.

Link layer protocol parameters* In het CONNECT-bericht kan het netwerk de op de connectie (end-to-end) toe te passen Link layer core parameters vanuit de B-zijde naar de A-zijde doorgeven. Het is alleen van toepassing indien end-to-end op de het bovenste gedeelte van laag 2 het Q.922 protocol toegepast wordt. Het Link Layer core parameters infonnation element in het bier behandelde CONNECfbericht wordt door het netwerk gekopieerd uit het van B afkomstige CONNECf-bericht: het netwerk brengt er in het geval van frame relaying, zoals bier, geen wijzigingen in aan.

6.4 Data Transfer fase De data transfer fase treed in op het moment dat de ISDN-frame relaying bearer tussen Aen B-zijde tot stand is gekomen. Dit is het geval als aan beide zijden de setup-procedures succesvol verlopen zijn (De procedure voor de A-zijde is in de vorige paragraafbehandeld. zie voor de beschrijving van de procedure aan de B-zijde de volgende paragraaf).


Hoofdstuk6

Data transfer Het uiteindelijke proces van data-overdracht tussen A en B is afuankelijk van het gekozen interworkings-scenario, en zal in hoofdstuk 7, aan de orde komen.

6.5 Setu~rocedure aan de B-zijL....-d_e

_

Nadat het ISDN-netwerk een SEI'UP-bericht heeft ontvangen met zodanige parameters dat het geaccepteerd kan worden, zal het netwerk aan de B-zijde aanvangen met een verbindingsopzet-procedure, welke nagenoeg gelijk is aan de procedure aan de A-zijde, en een SETUP-bericht verzenden naar de opgeroepene (B-abonnee). (Zie figuur 6.4 op pagina 63).

6.5.1 Het SETUP-bericht aan de B-zijde Behoudens enkele wijzigingen zal dit door het netwerk naar user B te verzenden SEI'UPbericht dezelfde inhoud hebben als het van user A ontvangen bericht. De genoemde, door het ISDN-netwerk aangebrachte, wijzigingen worden in deze paragraaf behandeld.

Call reference De identificatie van de Q.93X~berichten die behoren bij de door het ISDN op te zetten call op het koppelvlak tussen het net en de B-abonnee vindt plaats (zoals gebruikelijk) d.m.v. een Call reference. De waarde ervan wordt aan de B-zijde door het netwerk bepaald en medegedeeld aan de B-abonnee in het SETUP-bericht in de vorm van het Call reference information element. Zie figuur 6.2 voor de codering van het CALL REFERENCE bericht.

Bearer Capability" De inhoud, en opbouw, van het bearer capability information element zoals dat in het hier besproken SETUP-bericht zit, is identiek aan het overeenkomstige element in het SEI'UPbericht aan de A-zijde. Normaal is het zo dat het netwerk enige wijzigingen kan aanbrengen in het naar B gezonden bearer capability information element. Bij frame-relaying is dit echter onmogelijk omdat er geen discussie mogelijk is over de benodigde bearerservice: frame mode bearer met de core aspects van Q.922 op laag 2 en unrestricted digital information.

..

Link layer core parameters

Het Link layer core parameters information element is in een SETUP-bericht dat door het netwerk naar een abonnee gezonden wordt (hier de abonnee aan de B-zijde) altijd aanwezig. Hiermee worden de door bet netwerk en de A-zijde voorgestelde parameters aan de B-abonnee gepresenteerd.

Setup-procedure aan de B-zijde

Het SETUP-bericht aan de B-zijde 85

De inhoud ervan wordt dus bepaald door hetgeen de A-abonnee heeft opgegeven (als deze, zoals in de in dit hoofdstuk beschreven procedures, van de mogelijkheid gebruik maakt) in het door "hem" verzonden SETUP-bericht samen met de mogelijkheden die het netwerk kan bieden. In het CONNECT-bericht zal de B-zijde kenbaar maken of de voorgestelde parameters acceptabel zijn. Vervolgens worden ze door het netwerk in een CONNECT-message aan de A-zijde gepresenteerd, waarna aldaar besloten wordt of de (iruniddels end-to-end) parameters geschikt zijn.

Link layer protocol parameters* Als er in het SETUP bericht dat het netwerk vanuit de A-zijde ontvangt een Link layer protocol parameters information element is opgenomen zal dit ongewijzigd overgenomen worden in het SETUP-bericht dat naar de B-abonnee gaat. Voor frame-relaying op zich heeft dit information element, zoals reeds eerder opgemerkt, geen betekenis.

End-to-end transit delay Met behulp van dit information element kan het netwerk de curnulatieve end-to-end transit delay van de op te zetten frame-relay connectie aan de B-abonnee melden. Het is in ieder geval in het hier besproken SETUP-bericht aanwezig als het in het door de A-zijde verzonden SETUP-bericht was opgenomen.

Channel identification* Aan de B-zijde is het netwerk verplicht om het te gebruiken B-kanaal (in het kader van de afstudeeropdracht uitsluitend B I of B2) te kiezen. De keuze wordt aan de B-abonnee kenbaar gemaakt in het channel identification information element dat in de door het netwerk verzonden SETUP-berichten verplicht aanwezig is. De B-kanaal keuze op het koppelvlak tussen het ISDN en de A-abonnee, zoals in 66n van de voorgaande paragrafen besproken is, is volledig onafhankelijk van het gekozen B-kanaal aan de B-zijde. Ook hier worden er bij het invullen van een SETUP-bericht een aantal mogelijkheden geboden. Zo kan er specifiek B-kanaal, al- of niet dwingend, aangegeven worden. Ben bijzondere mogelijkheid in het geval van frame-relay verbindingen is de mogelijkheid om "No channel" aan te geven hetgeen inhoudt dat er geen vrij B-kanaal beschikbaar is, maar dat er op een reeds voor frame relaying in gebruik zijnde B-kanaal een extra frame-relay connectie toegevoegd dient te worden. (Wellicht ten overvloede, maar zoals reeds eerder vermeld is worden er in het kader van dit verslag geen D-kanalen aangewend voor frame-relaying.) In tabel6.6 zijn de B-kanaal keuze mogelijkheden in de netwerk-user richting samengevat, inclusief de te toegestane user-responses.


Hoofdstuk6

Tabel 6.6: B-kanaal keuze mogelijkheden (netwerk-user)

Chann,llnette.ttd In the $ETUPmeuag. network to .. . Allo'!able u~.r!.ttponS8 user direction Ohannelldentlfieation

\.

..Pteferred Of' Excl1... fv. Preferred Exclusive Preferred Exclusive

Bi No channel

Netwolt<·ua.'········ Bi, (Bil, Bk Bi Bk

.

...

-

In deze tabel worden met Bi B-kanalen aangeduid die zicb in de "Idle"·toestand bevinden of reeds voor frame-relaying in gebruik zijn. Met Bj geeft men elk ander B-kanaal aan. Tenslone wordt met Bk een B·kanaal bedoeld dat reeds door een frame-relay verbinding IO in gebruik is. N.B.: De tussen haakjes geplaatste optie is Diet toegestaan in combinatie met een broadcast datalink.

Ter vereenvoudiging van het vervolg van de setup-procedure wordt aangenomen dat het netwerk een specifiek B-kanaal kiest, en het gebruik ervan dwingend aan de B-abonnee oplegt (exclusive-optie). Zie voor de codering van het Channel Identification information element figuur 6.15, waarin het gekozen B-kanaal met de bit-combinatie a,b aangegeven wordt: Bl bij (a,b)=(O,l) en B2 als (a,b)=(O,l).

8

7

6

5

4

3

2

Channel Identification

0

0

0

1 Information

ext

Interface identifier present

Interface type

1

0

0

1

Le tgte Preferspare red/Exelusive

0

0

0

0

Octet 1

.~.nt I~ntifl.r

1

2 D-channel indicator

0

Information channel selection a

3

b

Figuur 6.15: Codering van het Channel Identification information element ( B-zijde)

Data Link Connection Identifier* In tegenstelling tot SETUP-berichten die door het netwerk ontvangen worden bevat dit type Q.93X (en Q.931) bericht altijd het Data Link Connection Identifier information element indien het door een ISDN-netwerk verzonden wordt. In dit information element is dan de door het netwerk gereserveerde DLCI-waarde aangegeven, waarvan in het kader van dit verslag aangenomen wordt dat deze de status

lODe in de label opgesomde mogelijkbeden gelden ook voor H·kanalen; deze vallen echter buiten bet bestek van dit verslag.

Setup-procedure san de B-zijde

Reactie aan B-zijde op het SETUP-bericht 87

van "exclusive" heeft zodat de B-abonnee hiennee akkoord moet gaan (bij een succesvolle setup procedure). De codering en opbouw van het DLCI-infonnation element is standaard, en dus gelijk aan hetgeen in eerder stadium besproken werd.

Adresserings gegevens Onder normale omstandigheden zullen de adresseringsgegevens in de SETUP-berichten die aan de A- en B-zijde verzonden worden aan elkaar gelijk zijn. In het kader van de afstudeeropdracht wordt bier dan ook vanuit gegaan. Zie voor de bespreking van de Called party number-, Called party subaddress-, Calling party number- en Calling party subadress- information elements het voorgaande.

Low layer compatibility Het Low layer compatibility information element uit het SETUP-bericht van de A-zijde wordt door het nerwerk gekopieerd naar het B-zijde SETUP-bericht.

6.5.2 Reactie aan B-zijde op het SETUP-bericht Na ontvangst van het SETUP-bericht zal er aan de B-zijde "gekeken" worden of de call-setup geaccepteerd kan worden. Daarbij spelen o.a. de inhoud van het bearer capability- en Low layer compatibility-information element een ro!. Bij acceptatie kan de user anrwoorden met o.a. het CALL PROCEEDING-, ALERTINGof CONNECT-bericht.1n het kader van de afstudeeropdracht zal de user aan de B-zijde reageren door het verzenden van CALL PROCEEDING (Weigering kan de B-zijde bijvoorbeeld kenbaar maken door het zenden van RELEASE COMPLETE, er wordt bier echter aangenomen dat de call request geaccepteerd wordt zodat RELEASE COMPLETE niet aan de orde is).

"Parameter negiotiation" Net als op het koppelvlak tussen A-abonnee en het nerwerk vindt er tussen het ISDN en de B-zijde een "onderhandeling" plaats over de parameters van de frame relay connectie die opgezet wordt. De in het SETUP bericht ondergebrachte gegevens ten aanzien van Quality of Service (transit-delay en link layer core parameter) worden door de ontvanger beoordeeld op haalbaarheid. AIs zowel de transit-delay en Link layer protocol parameters acceptabel zijn dan is er niets aan de hand, en zal de B-zijde een CONNECT message verzenden met daarin de orginele parameters. Indien of meer van de genoemde parameters niet acceptabel zijn voor de B-zijde dan zal deze de parameters aanpassen en de nieuwe waarden in het te verzenden CONNECTbericht invullen, waarna het de beurt is aan het netwerk en/of de A-zijde om de callsetup al of niet af te breken. De aangepaste waarden voor de parameters moeten nog weI aan de

em


Hoofdstuk6

minimale eisen voldoen die o.a. in het Link core parameters infonnation element zijn gesteld: als daaraan niet voldaan kan worden moet de B-zijde de setup-procedure afbreken door het verzenden van een RELEASE COMPLETE message (met als "cause": Quality of service not available), waarna het netwerk vervolgens een zelfde bericht naar de A-zijde zal verzenden. Resumerend: In het door de B-zijde te verzenden CONNECf-bericht, waannee deze de call-request accepteerd, dient bij frame-relaying altijd het Link layer core parameters infonnation element vertegenwoordigd te zijn: ook als de voorgestelde parameters ongewijzigd overgenomen kunnen worden.

6.5.3 CALL PROCEEDING aan B..zijde Het is gebruikelijk dat de B-zijde op SETUP-bericht reageert met het CALL PROCEEDING bericht. Dit is niet verplicht: er kan ook oruniddellijk geantwoord worden met het CONNECf-bericht, maar in het kader van deze beschrijving wordt aangenomen dat CALL PROCEEDING weI gebruikt wordt. In eerder stadium is de opbouw en inhoud van het CALL PROCEEDING bericht reeds behandeld. Naast de standaard verplichte infonnation elements (Protocol Discriminator, Call reference en message type), zijn hier eveneens de Channel Identifier en de Data Link Connection Identifier verplicht aanwezig, omdat het CALL PROCEEDING bericht de eerste respons vonnt op een SETUP bericht. (N.B.: de Channel Identifier zou in een CASE A situatie afwezig mogen zijn).

Channel Identifier* In het voorgaande is reeds verondersteld dat het netwerk hier zelf een te gebruiken B-kanaal kiest, en dit dwingend aan de B-zijde oplegt (exclusive-optie). Het gevolg is dat de B-zijde dit kanaal moet accepteren als de call-request geaccepteerd wordt (hetgeen hier aangenomen wordt). De inhoud van het Channel identifier infonnation element zal in deze situatie precies gelijk zijn aan het corresponderende element in het SETUP-bericht dat door de B-zijde ontvangen werd.

DLCI * Ook van de DLCI-waarde werd verondersteld dat deze dwingend aan de B-abonnee opgelegd zou worden (in deze situatie), zodat voor het DLCI-infonnation element hetzelfde geldt a1s voor de channel identifier.

Opmerking Het nut van het precies copieren van de hierboven genoemde infonnation elements van een SETUP- naar CALL PROCEEDING-bericht is twijfelachtig: Het netwerk heeft

Setup-procedure aan de B-zijde

CONNECT aan B-zijde 89

immers zelf de waarden bepaald, en uit het weglaten van deze infonnatie in het respons bericht (CALL PROCEEDING) zou immers begrepen kunnen worden dat het voorstel door de B-zijde geaccepteerd is.

6.5.4 CONNECT aan B-zijde Met CONNECT geeft de B-zijde aan dat de call-request geaccepteerd wordt. Het is tevens voor het netwerk een teken om aan de A-zijde een CONNECT-bericht te verzenden. Eventuele wijzigingen in quality of service parameters, of Link layer core parameters, zoals hierboven besproken is, zijn in het CONNECT bericht opgenomen. Uiteraard zijn de verplichte infonnation elements aanwezig, de overige (mogelijk) aanwezige infonnation elements worden hieronder kon besproken.

Channel Identification & DLC( Deze infonnation elements zijn verplicht in het CONNECT-bericht aanwezig als dit de eerste respons zou zijn op een SETUP-bericht, dat is hier niet het geval zodat ze in de hier beschreven situatie afwezig zijn.

End-to-end transit delay & Link layer protocol parameters· De end-to-end transit delay- en Link layer protocol parameters infonnation elements zijn in het CONNECT-bericht opgenomen als ze zich ook in het SETUP bericht bevonden. Zie voor meer details het voorgaande, met name de paragraaf"Parameter Negotiation". Voor aile duidelljkheid: beide zijn in de hier beschreven situatie in het CONNECT-bericht opgenomen.

Connected numberlsubaddress· Er wordt in het kader vande afstudeeropdracht geen aandacht geschonken aan bijvoorbeeld call-redirection, waarbij de Connected number/subaddress infonnation elements van nut kunnen zijn. In het hier beschreven CONNECT bericht zijn ze niet opgenomen.

Low layer compatibility Het Low layer compatibility infonnation element zal in het CONNECT bericht opgenomen worden door de B-abonnee indien deze gegevens betreffende zijn lagere laag eigenschappen naar de A-zijde wi! doorgeven. In het kader van de afstudeeropdracht wordt aangenomen dat dat ook zo is. Optioneel kan dit information element onderwerp zijn van onderhandeling: bij frame-relaying valt er echter weinig te onderhandelen zodat dit hier niet aan de orde is.


Hoofdstuk6

Opmerking: Het zal de lezer duidelijk zijn dat de precieze invulling c.q. codering van de bier genoemde information elements bier niet nogmaals behandeld wordt: dit is inuners in de eerste helft van dit hoofdstuk reeds gedaan.

Data transfer fase N a ontvangst van het CONNECT-bericht vanuit de B-zijde, en het succesvol afronden van de setup-procedure aan de A-zijde treedt de data-transfer fase in. Hierop wordt in het volgende hoofdstuk nader ingegaan: er zijn daarbij inuners een aantal mogelijkheden die het gevolg zijn van eigenschappen van een specifiek interworking-scenario.

6.6 Release procedure aan A- en e-zij'--d_e

_

De in het kader van frame-relaying gebruikte release procedure komt overeen met de normale Q.931 procedure. Er moet hier echter weI opgemerkt worden dat pas na het verbreken van de Iaatste frame-relay connectie op een bepaald B- of H-kanaal de verbinding op dit fysieke kanaal verbroken kan/mag worden (er is irnmers multiplexing van meerdere frame-relay connecties op zo 'n fysiek kanaal mogelijk, waarbij het waarschijnlijk is dat niet alle bestaande frame-relay connecties op het zelfde moment verbroken moeten worden).

Aigemeen

Interworking symboliek 91

Interworking scenario's

In dit hoofdstuk voIgt de uiteindelijke beschrijving van de interworkingsituaties zoals die eerder zijn gepresenteerd als scenario I tim 3 (zie hoofdstuk 3)

7.1 Aigemeen Eerst enkele algemene aspecten en afspraken die voor alle inteIWorking-scenario's van belang zijn, zoals adressering binnen het LAN en afrnetingen van de te transponeren frames.

7.1.1 Interworking symboliek In de figuren van de drie scenario's die in hoofdstuk 3 gepresenteerd zijn, en verderop in dit hoofdstuk nogmaals afgebeeld worden, wordt een symbool gebruikt waarmee inteIWorking wordt aangegeven. Zie onderstaande figuur.

1

2

A

B

Figuur 7.1: Symbool voor Interworking tussen twea protocollen

Met deze afbeelding wordt bedoeld dat er tussen de protocollen 1 en 2 interwoIking plaats vindt, terwijl A en 8 geen contact met elkaar hebben. Deze interwoIking houdt in dat er tussen 1 en 2 een mapping/conversie plaatsvindt tussen de twee protocollen (1 en 2). Men kan hierbij denken aan het "mappen" van POU-velden van protocol 1 op POU velden van protocol 2. Oit lukt alleen als beide protocollen dezelfde POU-typen hebben.

92 Hoofdstuk 7


Als dat niet zo is dan kan de interworking in de vorm van primitieven uitkomst bieden. In dat geval wordt data- en besturings-informatie uitgewisseld in de vorm van primitieven (~), en geen POU's. Op die manier wordt getracht om de functionaliteiten van de twee protocollen zo goed mogelijk op elkaar te "mappen". In feite is zo 'n interworkingsituatie te vergelijken met de interactie die in een normale protocol-stack plaats vindt tussen de aangrenzende lagen (met verschillend niveau in de stack: een hogere laag maakt gebruik van de service van een lagere laag), waarbij er hier sprake is van interactie tussen twee lagen op het zelfde niveau.

7.1.2 POU's

~

Frames/Packets

Binnen het OSI-referentie model is sprake van POU's en SOU's. In protocollen, met name de datalink protocollen, worden POU's vaak frames genoemd; SOU's zijn in feite de userdata. Op analoge wijze worden in netwerklaagprotocollen POU's packets genoemd.

7.1.3 Afmetingen van Oatavelden Oe afmetingen van de datavelden van POU's die door de protocollen in de LAN-protocol. stack worden gegenereerd is het onderwerp van deze paragraaf, waarbij in het kader van dit verslag ISO 8473-, LLC-I- en MAC-POU's van belang zijn (evenals de bijbehorende SOU's), waarbij in navolging van het voorgaande ook gesproken zal worden van LLC-Ien MAC-frames. Het zal blijken dat de maximale lengten van deze datavelden niet op alle niveaus binnen de LAN-stack gelijk zijn, hoewel er vaak toch een vaste relatie bestaat tussen de POU -atmetingen op de verschillende niveaus.

De MAC-service Voor toepassing in de MAC-laag zijn een aantal protocollen gestandaardiseerd, zoals CSMA/CD, Token-bus en Token-ring. Deze bieden alle dezelfde MAC-service aan de LLC-laag. Ben aantal essentiele verschillen tussen de verschillende MAC-protocollen (zoals bijvoorbeeld in frame-Iengte en frame-opbouw) zijn er de oorzaak van dat er in de LLC-laag, ondanks de "identieke" MAC-service, toch rekening gehouden moet worden met het specifieke gebroikte protocol. Zo is de maximale LLC-frame lengte bij elk MAC-protocol anders als gevolg van verschillen in afmetingen van de data-velden in de MAC-frames.

LLC-frame lengten De voor de diverse MAC-protocollen toegestane LLC-frarnelengten zijn in tabel 7.1 samengevat.

Afmetingen van Datavelden 93

Algemeen

TabeI7.1: In IEEE-LAN's toegestane frame-Iengten LAN·tvDe: IEEE 802.3 IEEE 802.4 IEEE 802.5

·Omschrllvlna: CSMAlCD (Ethernet) Token bus Token ring

Frame-Ianate (lnbvt.8) 0·1500

o. 8192 onbearensd

De maximale LLC-frame lengte die door de MAC-protocollen verwerkt kan worden is, zoals uit bovenstaande tabel blijkt, bij de meeste MAC-implementaties beperkt. AIleen een Token ring lijkt uit deze tabel oneindig lange LLC-Frames te kunnen verwerken, er bestaat echter weI een lengte-beperking die het gevolg is van de werking van IEEE 802.5 protocol. In de praktijk kunnen Token ring LAN's LLC-frames verwerken met een lengte van ongeveer 8000 bytes, hetgeen overeenkomt met de situatie bij Token bus LAN's. Door het connectionless LLC type 1 protocol worden alleen unnumbered PDU's gegenereerd (U-fonnaatPDU's), teweten: UI-command,XID- enTEST-command/response. De lengte van een U-formaat-POU wordt bepaald door een header-deel, bestaande uit adresserings- en besturingsinformatie, en een data-deel. Oe header is bij LLC-l altijd 3 bytes lang. Oe uiteindelijk te transporteren data wordt ondergebracht in het datadeel van UI-command PDU's. Ook in XIO- en TEST-PDU's kan data ondergebracht worden: in het eerste geval betreft het dan specifieke voor laag 2 van belang zijnde data. In het tweede geval kan het (eventueel) gewone van laag 3 afkomstige user-data betreffen die, zoals bij TEST-PDU's gebruikelijk is, in een TEST-response-PDU terug naar de afzender gezonden wordt. In feite is er bij de XID- en TEST-PDU's sprake van een acknowledged CL-service; op XID- en TEST-commands dient inuners gereageerd te worden in de vonn van resp. XIDen TEST-responses. LLC-l verzorgt een unacknowledged data-link service, getuige het feit dat er geen response voIgt op een UI-command. De maxlmale lengte van

een LLC-PDU

Ben LLC-l POU bestaat altijd uit een header (3 bytes) plus een optioneel data-deel. De LLC-standaard geeft aan dat de maximale lengte van het datagedeelte begrensd wordt door de eisen welke het gebruikte MAC-protocol aan de LLC-PDU's stelt. Uitgaande van de vaste header-Iengte van 3 bytes kan de maximale lengte Ldata van het data-gedeelte in een LLC-l POU worden bepaald door: Ldata= LMA~SDU- 3

(7.1)

waarin LMAC-SDU staat voor de maximale, door de MAC-service acceptabele, SOU-Iengteo Voor alle duidelijkheid: LMAC·SDU is gelijk aan de maximale LLC framelengte. De maximale lengte Ldata van de verschillende IEEE 802.x protocollen is in tabel 7.2 afgebeeld.


94 Hoofdstuk 7

Tabel: 7.2: Maximale dataveld-Iengte in llC-(UI)-PDU's LAN·tVDe: IEEE 802.3 IEEE 802.4 IEEE 802.5

.OmachrUvlna: CSMIVCD (Ethernet) Token bus Token ring

ILn_max.

..

. ..

1497 8189 onbegrensd

Ophet grensvlak tussen denetwerklaag (ISO 8473) en de LLC-Iaag gaat een Netwerk-PDU over in een L-SDU, zodat geconc1udeerd kan worden dat de maximale Iengte van N-PDU's gelijk is aan die van L-SDU's.

Netwerk service Een cOIUlection-iess netwerkservice diem volgens de standaard (ISO 8348/Add.l) userdata in de vonn van N-SDU's te kunnen verwerken met afmetingen tot 64512 bytes. Uit het voorgaande zal het duidelijk zijn dat dataveiden met dergeIijke afmetingen niet zonder meer d.m.v. de eerder genoemde IEEE-LAN's getransporteerdkunnen worden: het netwerkprotocol zal zo'n datablok (64512 bytes) moeten opsplitsen in kleinere stukken waarvan verwerking door de LAN's weI mogelijk is (segmenting). Het ISO 8473 protocol kent, zoals in hoofdstuk 4 vermeld is, naast de "standaard" implementatie een aantal varianten: de Inactive- en Non-segmenting-variant. Het Inactive Network Layer protocol is hier niet aan de orde: het bevat geen enkele ISO 8473 functie behoudens de functie van "doorgeef-Iuik", en kan dan ook uitsluitend toegepast worden binnen een enkel sub-netwerk. De Non-segmenting Network Layer variant is hier weI interessant. Deze verschilt met "standaard ISO 8473" in het ontbreken van de segmentation/reassembly-functie, en is daardoor slechts beperkt toepasbaar: de eisen ten aanzien van de maximale dataveld-Iengte in LLC- VI -PDU's werken hierbij door naar de transponlaag. Er kan dus bij een combinatie van de Non-segmenting-subset en LLC-l/MAC geen sprake zijn van een volwaardige netwerkservice; deze moet immers N-SDU's kunnen verwerken met een lengte van 64512 bytes. Segmentation

De aanpassing tussen de maximaal toelaatbare N-PDU lengte en de door de netwerldaag te ondersteunen N-SDU afmetingen kan binnen laag 3 door middel van segmentation plaatsvinden. Deze functie is in het "standaard" ISO 8473 protocol aanwezig, en zal in voorkomende gevallen ook toegepast moeten worden. Men zou in dit stadium reeds kunnen conc1uderen dat de "Non-segmenting"-subset van het ISO 8473 protocol niet geschikt is voor gebruik in combinatie met IEEE 802 LAN's (tenzij verzekerd is dat laag 4 pakketten voldoende klein zijn).

Algemeen

Afmetingen van Datavelden 95

Mlnlmale LLC-PDU-Iengte

Naast een maximaal toelaatbare LLC-PDU lengte, als gevolg van beperkingen in de MAC-laag, is ook sprake van een minimaal te verwachten lengte. Zoals later zal blijken is dit van belang in verband met beperkingen in het ISDN.

In de ISO 8473 standaard wordt geeist dat de onderliggende service in staat moet zijn om N-PDU's met een lengte van minimaal512 bytes te kunnen verwerken. Deze voorwaarde resulteen in een minimale lengte van LLC-PDU's (VI- en TEST-PDU's met data) van 515 bytes: een header-deel van 3 bytes plus het 512-bytes data-deel (dat een N-PDU bevat). Bovenstaande betekent natuurlijk niet dat alle N-PDU' s 512 bytes of meer zullen bevatten, maar het onderliggende netwerk moet weI in staat zijn zulke PDU's te verwerken. Beperking in het ISDN Het datalink protocol dat in het ISDN gebruikt wordt voor het realiseren van frame-relaying, Q.922, is afgeleid van Q.921. Bij toepassing van Q.922 op een D-kanaal gelden dezelfde beperkingen ten aanzien van frame-sizes als in Q.921. In het Q.921 protocol is het maximum aantal bytes in het Information field beperkt tot 260; dit is een default waarde die afgestemd is op de kanaalcapaciteit van het D-kanaal van een ISDN Basic Access (2B + D configuratie). Voor het geval van de frame relaying bearer service wordt de frame grootte iets anders vastgelegd: niet de lengte van het Information veld is de systeem parameter, maar het aantal bytes tussen Adres- en FCS-veld. De reden hiervoor is dat in het geval van Frame relaying niet per definitie in het netwerk bekend is wat de lengte van een eventueel door de eindgebruikers toegepaste control veld zal zijn. Dit heeft het volgende tot gevolg: in een frame relaying situatie op een D-kanaal zal het aantal bytes tussen Adres-veld en FCS-veld per default maximaal gelijk zijn aan 262 bytes (260 bytes van het "Information field" + 2 bytes van het "Control field") . Wordt een compleet. d.w.z. inc1usiefDSAP-. SSAP- en control-veld, LLC 1 VI-command frame verstuurd, dan zal de maximale lengte van het dataveld van het LLC-l UI-command frame gelijk zijn aan 259 bytes (= 262 - 3). Het zal duidelijk zijn dat deze ruimte voor user-data niet toereikend is voor N-PDU's of LLC-l frames. De conc1usie is dan ook dat frame-relaying op een D-kanaal van een ISDN Basic Rate Access in combinatie met het ISO 8473 CL-netwerk protocol niet mogelijk is zonder een tussenliggend protocol dat voorziet in een segmentation/reassembly funetie.

1

In de huidige versie van Q.93X, wordt ten onrechte een maximwn van 260 bytes genoemd; men heeft daar de ruimte in bet (oude) "control-field" van maximaal2 bytes over bet hoofd gezien (blz.23)

96 Hoofdstuk 7

/nterworking scenario's

B-kana/en

Op B-kanalen staat het Q.922 protocol grotere frames toe. De toename komt volledig ten goede aan het data-veld. In de beschrijving van Q.922 is men niet duidelijk wat betreft de maximaal toelaatbare afmetingen van de frames, er wordt slechts een voorbeeld gegeven: 4096 bytes. De eind gebruikers moeten met het netwerk de feitelijk te gebruiken lengte afspreken tijdens de cali-setup.

7.1.4 Adressering binnen het LAN Binnen het LAN zijn er in het kader van dit verslag drie adresserings-niveaus van belang, namelijk op het niveau van MAC-, LLC- en de netwerk-laag. Deze worden in deze paragraaf besproken.

Adressering binnen de LLC-, laag Deprimitieven die op het grensvlak tussen netwerklaag en LLC-laag uitgewisseld worden bevatten o.a. adresseringsinformatie die van belang is voor zowel de LLC- als de MAClaag. Zo zijn er ten behoeve van de LLC-Iaag zogenaamde DSAP- en SSAP- adressen aanwezig. Verder is er voorzien in SA- en DA-MAC-adressen die binnen de MAC-laag van belang zijn (In de genoemde afkortingen staat de "S" voor Source, en "D" voor Destination). LLC-adressen (DSAP en SSAP) hebben een lengte van 8 bits (1 byte), waarvan slechts 2 7-bits voor een adres beschikbaar zijn . De in het kader van dit verslag van belang zijnde MAC-adressen (SA en DA) zijn 6 bytes lang (48 bits); er bestaan ook 16 bits MAC-adressen. LLC-PDU

De eerder genoemde DSAP- en SSAP-adressen worden bij compositie van een LLC-PDU opgenomen in de header, en zijn dus aan de ontvangstzijde bij decompositie weer beschikbaar. MAC-adressen

De eerder genoemde MAC-adressen (SA en DA) worden binnen de LLC-laag een-op-een gekopieerd naar de corresponderende velden van een MA_UNITDATA-request primitieve die tussen de MAC-Iaag en de LLC-laag voor informatie uitwisseling gebruikt wordt (en omgekeerd bij ontvangst van een MA_UNITDATA-indication primitieve).

2

Het resterende (minst sigoificante) bit wordt voor andere doeleinden aaogewend: group/individual- en command/respome-identificatie.

Aigemeen

Adressering binnen het LAN 97

Samenvattend:

Binnen de LLC-Iaag van de LAN-protocolstack zijn naast de LLC DSAP- en SSAP-adressen ook de MAC-adressen (DA- en SA-adressen) beschikbaar; zij worden zonder conversie met de netwerklaag uitgewisseld als onderdeel van de DL_UNITDATA-primitieven. Het beschikbaar zijn van deze adresseringsgegevens binnen de LLC-laag en op het grensvlak tussen netwerken LLC-laag kan van belang zijn voor het oplossen van interworkingsproblemen van LAN's met andere (data)-conununicatienetten (zoals bijvoorbeeld ISDN).

Adressering binnen de LAN-netwerklaag (ISO 8473) In feite verdeelt het netwerklaag protocol ISO 8473 laag 3 in een aantal sub-Iagen; in hoofdzaak een van het onderliggende netwerk onafhankelijke "basis"-laag die het eigenlijke ISO 8473 protocol bevat. En een onderliggende laag die de mapping (66n-op-een; zonder bijvoorbeeld segmentation oj.d.) verzorgt tussen ISO 8473 en het gebruikte subnetwerk (hier LLC-I). Zowel op de scheidingsvlakken van de netwerklaag met de aangrenzende lagen, transporten LLC-laag, als tussen de twee interne sublagen (binnen de netwerklaag) vindt uitwisseling van adresseringsinformatie plaats. Het scheidingsvlak tussen de transport· en netwerklaag

Tussen de transporten netwerklaag worden zogenaarnde N_UNITDATA-request en indication prirnitieven uitgewisseld. Daarin zijn zogenaarnde NSAP-adressen ondergebracht. Het "Interne" scheidingsvlak

De primitieven die op het interne scheidingsvlak binnen de netwerklaag toegepast worden bevatten de eerder genoemde LLC SSAP- en DSAP- adressen en MAC-adressen (DA en SA). Het scheldlngsvlak tussen de netwerk· en LLe-laag

De inhoud van de adres-velden van de hier gebruikte primitieven zijn identiek aan die van de op het "interne"-scheidingsvlak voorkomende prirnitieven. NSAP-adressen

De Service Access Points (NSAP's) die het contact verzorgen tussen de netwerken transpon-laag worden d.m.v. NSAP-adressen geldentificeerd. In ISO 8473 pakketten worden deze NSAP-adressen ondergebracht. Ben NSAP-adres identificeen een bepaalde laag 3 SAP (waarlangs de netwerkservice aan een laag 4 entiteit geboden wordt) volledig.

98 Hoofdstuk 7


Het NSAP-adres, dat uit drie onderdelen bestaat (AFI, IDI en DSP), kan op verschillende manieren ingevuld worden. Zo kan voor het IDI-deel gekozen worden uit een viertal CCIIT-nununerplarmen: X.121 (data), F.69 (telex), E.163 (telefoon) en E.164 (ISDN). Verder kan gekozen worden voor een ISO geografisch- of intemationaal domein. In het DSP kan een soort subadres geplaatst worden dat zich "achter" het IDI-nummer bevindt. De keuze van het gebruikte nummerplan, en de coderingswijze van de DSP worden door de AFI-aangegeven. Zie voor meer informatie over NSAP-adressen het RNL-verslag: 27 RNL/89, of het TUE-afstudeerverslag van H.J.J.H. Schepers: "Design of a LAN/ISDN Gateway,,3. Hler te gebrulken NSAP-adressen

Vande hier te koppelen LAN's wordt aangenomen dat zij in het IDI een E.l64 ISDN-nummer invullen. Deze kunnen dan eenvoudig in de ISDN-setup procedure gebruikt worden. Vervolgens wordt aangenomen dat in het DSP een combinatie van LLC- en MAC-adressen wordt opgenomen.

7.1.5 CO/CL - barriere Alle in het kader van de afstudeeropdracht aan de orde zijnde LAN protocollen zijn Connection-less, terwijl de gebruikte ISDN protocollen Connection-Oriented zijn. Het zal duidelijk zijn dat er in de interworkingunit een "mapping/conversie" tussen deze twee verbindingstypen plaats moet vinden. In hoofdstuk 2 zijn voor het oplossen van dat probleem vier (principiele) mogelijkheden genoemd. Er is in het kader van de afstudeeropdracht geen laag 4 protocol voorgeschreven, zodat het toepassen van laag 4 informatie voor het oplossen van CO/CL-probleem hier niet mogelijk is. Ook het gebruik van convergence protocollen is hier niet mogelijk: de te gebruiken protocollen zijn in de opdracht inuners nauwkeurig bepaald. Twee oplossingen lijken in het kader van de LAN-interconnectie geschikt, namelijk de zogenaamde timer-oplossing en de oplossing waarbij voor elk datagram (b.v. ISO 8473 pakket of LLC-frame) een verbinding in het CO-netwerk wordt opgezet en vervolgens verbroken. Het zal duidelijk zijn dat bij de laatste oplossing het belangrijkste voordeel van de frame-relaying techniek, de geringe overhead, volledig te niet gedaan wordt. Resumerend: Aileen de tirner-oplossing is in het kader van de opdracht geschikt.

3

V oor aIle duidelijkheid: In dat verslag wordt g~D Frame-relaying toegepast.

Scenario 1

Signa/ering in het /SDN 99

Timer-oplossing Bij de timer-oplossing wordt na het opzetten van een verbinding (hier een frame-relay verbinding in het ISDN) binnen de interworkingunit het gebruik ervan continu "gemoniton". rJs blijkt dat de betreffende connectie gedurende een bepaalde, door een timer gemeten, periode niet gebruikt is zal deze door de interworking unit verbroken worden. Tabe/

Aangezien er meerdere frame-relay connecties op hetzelfde moment kunnen bestaan moet er van meerdere connecties de "levensduur" bijgehouden worden: het gebruik van een soon database binnen de interworking-unit ligt dus voor de hand. Deze kan dan tevens gebruikt worden om de diverse voor de interworking noodzakelijke adres-mappingen in op te slaan. De "inhoud" van de verschillende protocol-Iagen die zich in de interworkingunit bevinden liggen min of maar vast. Verder is de informatie uit de database zowel op laag 2 als laag 3 van belang, zodat het plaatsen ervan in het zogenaamde management plane het meest voor de hand ligt.

7.1.6 Signalering in het ISDN De voor de besturing van frame-relay benodigde ISDN-Q.93X-procedures zijn reeds in hoofdstuk 6, beschreven. In de beschrijving van de verschillende scenario's zullen weI een aantal invullingen van parameters die in Q.93X-messages voorkomen gegeven worden (voor zover dat mogelijk is).

7.2 Scenario 1 Het interconnectie scenario 1 werd reeds kon gepresenteerd in hoofdstuk 3. Om terug bladeren te voorkomen zal de bijbehorende protocolstack nogmaals worden afgebeeld, zie figuur 7.2.

-,,.,. 1508473

1508473 ...............

LLC 1

LLC 1

\/

MAC

MAC

~---

~---

(BB02.X)

(8B02.X)

I

I LAN

-,.,.

\/

Q.93X

Q.922 core

-,

I

Q.921

Figuur 7.2: Overzicht van scenario 1, Brouter A

I

--.

1.43017.431

I

I

0_

~

I I

100 Hoofdstuk 7


Het betreft hier een interworkingunit (het middelste gedeelte in figuur 7.2) die zowel actief is op laag 3 als laag 2. Zo 'n combinatie van router en bridge wordt vaak aangeduid als brouter.

7.2.1 Aigemene aspecten van scenario 1 Berst enkele algemene aspecten van scenario I, vervolgens wordt de verwerking van inen uitgaande LLC-frames (en de daarin verpakte ISO 8473 pakketten) in afzonderlijke paragrafen behandeld.

Adressering binnen het (Iokale) LAN MAC·adressen

In scenario 1 geldt dat de MAC-laag in zowel de LAN-stations als de brouter een gewone standaard invulling heeft: dat houdt in dat MAC-frames die dooreen LAN-station naar de brouter gezonden worden als bestemmingsadres (DA) het MAC-adres van de brouter bevatten. Als source-adres (SA) wordt uiteraard het eigen MAC-adres van de zender in het MAC-frame geplaatst. Het omgekeerde geldt ook: de interworkingunit adresseen op MAC-Iaag niveau het bestenuning LAN-station en vult zijn eigen SA in. LLC·adressen

Binnen de "LLC-laag" is de situatie iets anders. In de brouter worden laag 2 frames vanuit het lokale LAN via een ISDN frame-relay-bearer naar een remote LAN getransponeerd. Het ligt voor de hand dat een zendend LAN-station als bestemmings LLC-adres (DSAP) een SAP-adres gebruikt dat zich in het remote LAN-station bevindt. Als SSAP wordt vanzelfsprekend het eigen SAP-adres ingevuld. Ben door de brouter naar een lokaal LAN-station gezonden (eigenlijk gerelayeerd) LLCframe zal als gevolg hiervan als DSAP het SAP-adres van het lokale bestemmings LAN-station bevatten, en als SSAP het SAP-adres van de remote zender.

Samengevat: De brouter (in scenario 1) laat de LLC-adressen in de LLC-frames ongewijzigd. Adresserlng op laag 3

In aIle scenario's die in dit verslag behandeld worden vindt laag 3 adressering op identieke wijze plaats: Het zendende station plaatst in de ISO 8473 pakketten het NSAP adres van de eindbestemming (remote LAN-station) en zijn eigen NSAP-ad.res als source-adres. In deze NSAP-adressen zijn naast een ISDN (E.I64) adres ook LLC- en MAC-adressen van de eind-systemen (LAN-terminals van lokaal en remote LAN) aanwezig. Dit vloeit voon

Scenario 1

Aigemene sspeeten van scenario 1 101

uit de eerder gemaakte afspraak ten aanzien vande in het kader van dit verslag te gebruiken NSAP-adressen. (Zie voor meer infonnatie de inleiding van dit hoofdstuk). De gebruikte tabel In de interworkingunit bevindt zich een tabel waarin voor alle op een bepaald moment bestaande frame-relay connecties de relatie tussen DLCI-waarden (ISDN-laag 2 adressen), de NSAP-adressen van de lokaleen remote-LAN-stations zijn opgenomen. Mapping

De mapping in uitgaande richting is als voIgt: Het NSAP adres van de bestemming wordt, d.m.v. van de tabel, gekoppeld aan een bepaalde DLCI-waarde. In de inkomende richting is de DLCI-waarde van de ISDN-verbinding gekoppeld aan een DSAP LLC-adres en DA destination MAC-adres van een lokaal LAN-station. Voor het uitvoeren van deze "mapping" bestaat er nog een probleem, namelijk het feit dat het eerste bit van SSAP-velden niet bij het LLC-adres hoon, maar gebruikt wordt als CommandlResponse-bit. Bij het uitlezen van de voor het SSAP-veld bedoelde LLC-adres uit de tabel gaat dit bit uiteraard verloren. Het is dus nodig om in plaats van de DSAP- en SSAP-velden, die in dit scenario niet via de ISDN frame-relay verbinding verzonden worden, het CIR-bit dat daardoor verloren zou gaan toch te verzenden in een Q.922 core frame. In het DLCI-adres veld van zo'n Q.922 core frame is I bit gereserveerd als CIR-bit dat door een gebruiker van de bearer-service ingevuld kan worden. Ben oplossing voor het eerder gestelde probleem kan dus gevonden worden door het CIR-bit uit een LLC-frame in het DLCI-veld onder te brengen. Van die oplossing wordt in dit scenario gebruik gemaakt. Het invullen/wijzigen van deze tabel is aan de orde bij het opzenen van een nieuwe in- of uitgaande frame-relay verbinding. Timer Behalve een entry in de tabel wordt er voor elke DLCI-waarde een timer gestan. Hiennee kan het verbreken van een bestaande frame-relay verbinding gestuurd worden als blijkt dat die verbinding lange tijd niet gebruikt is. De timer-waarde waarop deze aetie gestan wordt is arbitrair. Uiteraard wordt zo'n timer gereset op het moment dat de corresponderende DLCI-waarde uit de tabel wordt uitgelezen of benaden (Er wordt in twee richtingen in de tabel gezocht: zowel bestemmings-NSAP-adressen als DLCI-waarden worden als "ingang" gebruikt). Op dat moment stan dan een nieuwe "levensduur" voor de betreffende verbinding. De bier gebruikte "timer-oplossing" is reeds in hoofdstuk 2 behandeld.

102 Hoofdstuk 7


Afmetingen van laag 3 pakkeUen In principe worden de afmetingen van de laag 3 pakketten, en daannee ook die van het

LLC-protocol, bepaald door de ruimte die er in MAC-frames aanwezig is voor userdata. Er bestaat in de interworkingsituatie echter nog een beperking: ook de maximale afmetingen van de te relayeren LLC-frames als gevolg van eigenschappen van de frame-relay-bearer zijn beperkt (tot bijvoorbeeld 4096-bytes). Over het algemeen zijn er over deze afmetingen door de router nog afspraken te maken met het ISDN; het is echter bijzonder moeilijk om vervolgens aan de LAN-stations de maximale LLC-I frame afmetingen te melden. Daarin is binnen LLC-l in het geheel niet voorzien, en binnen ISO 8473 slechts op een zeer beperkte wijze: de interworkingunit zou in principe bij te grote ISO 8473 pakketten d.m.v. een Error-repon aan het LAN-station kunnen melden dat een bepaald pakket geweigerd is omdat "verdere segmentatie" ervan niet mogelijk is. Waama het betreffende LAN-station de pakket-grootte zou kunnen bijstellen. De brouter is echter hoofdzakelijk op laag 2 actief, er worden pas pakketten naar laag 3 doorgegeven als er voor het transpon daarvan een nieuwe frame-relay verbinding opgezet moet worden, zodat het implementeren van de hierboven beschreven optie niet erg aantrekkelijk is. Eenvoudiger is het om op de LAN's een zodanige afspraak te maken voor de maximale LLC-frame lengte (en als gevolg daarvan van de ISO 8473-pakketten) dat ze door het ISDN verwerkt kunnen worden. Bijvoorbeeld 4096 bytes, zoals ook in Q.922 als voorbeeld worth ,enoemd. ISO 8473 pakketten bebben dan een maximale lengte van 4096 - 1 = 4095 bytes omdat van de totale ruimte van 4096 in bet Q.922 core frame slecbts 1 byte bezet is door bet control-veld van bet LLC-frame.

Tijdens de verbindingsopbouw in het ISDN moet de genoemde (afgesproken) waarde nog weI overeengekomen worden; als dat niet lukt is de LAN-interconnectie in dit geval omnogelijk, en zullen de in de router ontvangen frames "weggegooid" worden. Tenslotte moet nog vermeld worden dat er in de brouter geen verdere segmentation (en reassembly) van ISO 8473 pakketten kan plaats vinden, omdat deze pakketten in dit scenario geen volledige ISO 8473 bewerking krijgen. De vastgestelde frame-Iengte is dus bindend voor de LAN-stations (te grote laag-4 PDU's die verzonden moeten worden zullen dus door de ISO 8473laag in het LAN-station eerst gesegmenteerd moeten worden).

4

Bij IEEE 802.3 type LAN's is bet bandig om een kleinere waarde aite spreken: deze bebben immers van nature een geringere frame-grootte.

Scenario 1

Verwerking van uitgaande frames 103

7.2.2 Verwerking van uitgaande frames De verwerking van de uitgaande frames, (hier) LLC-I frames die vanuit een lokaal LAN-station via een frame-relay-bearer naar een remote LAN-station gezonden moeten worden, is het onderwe~' \In deze paragraaf. Door middel van een normale MAC "verbinding" in het lokale LAN arriveren LLC-frames (ofPDU's) in de LLC-llaag van de brouter. Bij binnenkomst zijn ertwee mogelijkheden: 1. Het betreffende frame is het eerste is in een reeks naar een nieuwe bestenuning te verzenden frames, zodat er nog geen frame-relay verbinding met deze nieuwe bestemming (gevormd door een remote brouter en achterliggend LAN) bestaat: die zal dus eerst opgezet moeten worden. 2. Er bestaat al weI een verbinding met het gewenste remote LAN, zodat het betreffende frame oruniddellijk door gezonden kan worden. Het is van belang dat de brouter bij ontvangst van een LLC-frame vanuit het lokale-LAN snel kan zien of situatie I of 2 aan de orde is. Helaas is in scenario I de laag 2 adresseringsinformatie hiervoor niet toereikend: ISO 8473 berichten uit een LAN-station die voor totaal verschillende bestenuningen bedoeld zijn worden alle naar hetzelfde MAC-adres van de router gestuurd; hiermee kan dus geen onderscheid gemaakt worden tussen de verschillende datastromen. Ook de gebruikte LLC-(DSAP)-adressen geven niet genoeg informatie (deze hebben namelijk slechts een "lokale" betekenis). AIleen met het laag 3 bestenunings NSAP adres kan het noodzakelijke onderscheid gemaakt worden. Met behulp van een tabel, waarin een relatie gelegd wordt tussen de in gebruik zijnde DLCI-waarden met de corresponderende NSAP-adressen, kan van elk binnenkomend ISO 8473 pakket bepaald worden of er al een ISDN-framerelay verbinding naar de gewenste eindbestenuning bestaat (situatie 2). Als het betreffende bestemmings NSAP-adres niet in de tabel voorkomt is er sprake van situatie 1: er moet dan een nieuwe verbinding opgezet worden. Komt het NSAP-adres weI in de tabel voor dan is automatisch de benodigde DLCI-waarde bekend van de framerelay connectie waarop relaying moet plaatsvinden, en zal de corresponderende timer gereset worden (zie bIz. 101). Deze tabel-zoekfunctie kan niet binnen laag 2 van de brouter plaatsvinden, maar moet op het niveau van de netwerklaag (in het management-gedeelte van de brouter) gesitueerd worden omdat aIleen daar de NSAP-adressen bekend zijn. Uit elk ontvangen LLC-l-informatie-frame za1 dus het dataveld, waarin een ISO 8473 pakket is ondergebracht, voor inspectie van de NSAP-adressen naar de netwerklaag overgebracht moeten worden. In figuur 7.2 aangegeven met een donkere balk (t::::::::::}:::::::::/::~ ) op het onderste gedeelte van de ISO 8473 laag.

104 Hoofdstuk 7


De daar gesitueerde tabel zal dan geraadpleegd worden, waarna de te gebruiken DLCIwaarde aan de interworkingsfunctie op laag 2 doorgegeven wordt (mits er een DLCI-waarde beschikbaar is). Komt de gewenste bestemrning niet voor in de tabel, dan zal er eerst een nieuwe verbinding opgezet moeten worden: de bij deze verbinding behorende DLCI-waarde zal dan later aan laag 2 doorgegeven worden, waarna de IWU het frame alsnog kan verzenden. Beide gevallen worden in de volgende paragrafen behandeld.

Een nleuwe verblndlng opzetten Bij het opzetten van een nieuwe ISDN-frame-relay verbinding spelen een aantal in het ISO 8473 pakket aanwezige parameters een rol: zoals het bestemmings- en bron- NSAP adressen en de "Lifetime" parameter. De ISDN setup-procedure voor frame-relay connecties (op een B-kanaal) is reeds in hoofdstuk 6 beschreven. Deze procedure wordt als een soon "subroutine" vanuit dit hoofdstuk aangeroepen, waarbij er een aanta! input-parameters meegegeven worden. Na het beeindiging van deze Q. 93X procedure komen zijn er aantal parameters beschikbaar die voor de interworkingunit van belang zijn, zoals de toegewezen DLCI-waarde (die in de eerder genoemde tabel opgenomen za! worden). Het gebruik van de "parameters" zal hieronder behandeld worden. Input parameters voor Q.93X procedures

De NSAP-adressen vormen beide rechtstreekse input-parameters voor de Q.93X opzetprocedure (aan de A-zijde); ze zullen opgenomen worden in de Q.93X Called/Calling subadressen. De NSAP adressen bevanen confOIm de eerder gemaakte afspraak E.l64 ISDN-nummers: deze zullen door de interworking-functie op laag 3 afzonderlijk van de NSAP-adressen aan het "control plane" doorgegeven moeten worden. Verder kwmen er in het ISDN een aantal parameters overeen gekomen worden die betrekking hebben op de link layer core functies. De belangrijkste daarvan zijn de inen outgoing frame lengten. Hiervoor moet de binnen de LAN's voorafvastgestelde waarden afgesproken worden. Als dit niet mogelijk blijkt te zijn tijdens het opzetten van de ISDN verbinding is de frame-relay-interconnectie van de LAN's niet mogelijk. Overige Link Layer core parameters kunnen bijvoorbeeld ingevuld worden aan de hand van de "Lifetime" parameter die in het ISO 8473 pakket aanwezig is. Deze kan verder toegepast worden voor de invulling van minimale Transit-delay's in het ISDN. Ten behoeve van de invulling van het bearer-capability information element, en de compatibility-checking in het ISDN zal tevens aan het "control-plane" doorgegeven worden dat op laag 2 alleen de "core aspects" van Q.922 gewenst zijn, en dat de rest van laag 2 gevuld is met LLC-l. Tenslotte wordt aangegeven dat op laag 3 het ISO 8473 protocol gebruikt wordt.

Scenario 1

Verwerking van uitgaande frames 105

Output parameters

Als output levert de ISDN-setup procedure na een succesvol verloop o.a. een DLCI-waarde op. Verder zullen link layer core parameters beschikbaar komen, waaronder de gebruikte frame-Iengten, die door de interworkingsfunctie op laag 3 gebruikt kunnen worden om, bij een te geringe lengte, de ISDN-verbinding weer te verbreken. Bij een niet succesvol verlopen setup procedure zal het control-plane dit aan het interworking-gedeelte melden (bijvoorbeeld "onjuiste ISDN-adressen", "ontvanger bezet", etc.), waama het ISO 8473 protocol dit aan het zendende lokale LAN-station kan melden d.m.v. van een Error Report PDU, met daarin een passende verklaring (bijvoorbeeld: "Destination Address Unreachable"). Vervolgens kan het LAN-station dan passende maatregelen nemen. Bljwerken van de tabel

Ais de verbinding in het ISDN tot stand komt zal er, zoals eerder veIrneld, een DLCI-waarde voor de betreffende frame-relay-connectie beschikbaar zijn. Deze waarde zal vervolgens in de tabel ingevuld moeten worden. Daarbij wordt een relatie gelegd tussen DLCI waarde en de NSAP adressen van het lokal- en remote-LAN-station. Aan de hand van deze combinatie van DLCI-waarde en NSAP-adressen kan de interworkingunit na raadpleging van de tabel op laag 3 een juiste mapping verzorgen van een LLC-l frame op een Q.922 core frame.

Een bestaande verbinding gebruiken Bij het begin van dit gedeelte van de procedure wordt aangenomen dat er een LLC-frame samen met een te gebruiken DLCI waarde beschikbaar is in laag 2 van de brouter. De control- en data-velden van een LLC-frame worden in een Q.922 core frame vervoerd. Daarin is tevens ruirnte gereserveerd voor de DLCI-waarde en een PCS veld. Het CIR-bit in het DLCI-adresveld wordt gebruikt om er het CIR-bit uit het LLC-frame mee te vervoeren. Het Q.922 core frame zal vervolgens door middel van het ISDN B-kanaal, waar de betreffende framerelaying connectie gebruik van maakt, naar het remote LAN worden verzonden. Er wordt dus geen compleet LLC-frame in een Q.922 core frame ingepakt (encapsulation), maar uitsluitend het control- plus data-veld daarvan (en het CIR-bit). Samen met het DLCIen PCS-veld vonnt dit een compleet Q.922 core frame. In de ootvanger zal deze DLCI-waarde weer gemapt worden op de juiste MAC- en

LLC-adressen.

106 Hoofdstuk 7


180 ..13

lABEL

Figuur 7.3: Verwerking

van uitgaande frames in scenario

7.2.3 Verwerking van inkomende berichten Ook bij inkomende berichten kan het systeem zich in twee toestanden bevinden. Deze worden gekenrnerkt door het feit of er al dan niet een frame-relay connectie bestaat. In de zogenaamde Rust-toestand is er nog geen frame-relay connectie beschikbaar, terwijl er in de Aetieve-toestand weI een verbinding bestaat. AIleen in die toestand kunnen er daadwerkelijk LLC-frames ontvangen worden door de brouter. Overgang van de Rust- naar Actieve-toestand (voor een bepaalde frame-relay connectie die gebruikt wordt voor de interconnectie van een lokaal- en remote-LAN-station) vindt plaats nadat er een succesvolle setup-procedure in het ISDN is uitgevoerd. De overgang van de Rust- naar Actieve-toestand en omgekeerd zal in de volgende paragrafen aan de orde komen. Verder wordt de data-uitwisseling die in de Actieve-toestand plaats vindt (kan vinden) besproken

Overgang van de Rust- naar de Actieve toestand Als een remote LAN-station een LLC-frame naar een lokaal LAN-station wil zenden, zal er een frame-relay verbinding in het ISDN-moeten bestaan tussen de twee te koppelen LAN's. Het opzetten ervan wordt gelnitialiseerd vanuit het ISDN door het zenden van een SETUP bericht. Ook hier worden de beschrijvingen in hoofdstuk 6 als een soort "subroutine" beschouwd, die echter in dit geval vanuit het netwerk "aangeroepen" wordt.

Scenario 1

Verwerking van inkomende berichten 107

Ondanks het feit dat de "opzet-subroutine" vanuit het netwerk aangeroepen werd zijn er toch enkele inputparameters vanuit de lokale brouter beschikbaar (die in hoofdstuk 6 de rol van B-zijde vervult: gedefmieerd als de inkomende zijde van een ISDN-call). Uiteraard zijn er aan de zijde van de lokale brouter ook enkele output-parameters vanuit de setup-procedure te verwachten. Input parameters

Als input parameters dienen onder ander gegevens over de protocol-structuur van de lokale brouter/LAN combinatie zoals de gebruikte laag 2 en 3 protocollen, resp. het LAN-LLC type 1 protocol en ISO 8473.

Verder kunnen Link. Core Parameters (zoals de maximale inen uitgaande frame-sizes) en transit-delay aangegeven worden. Deze kunnen dan in het onderhandelingsproces over de quality of service aspecten van de op te zetten frame-relay verbinding gebruikt worden. Deze gegevens kunnen bijvoorbeeld in het Q.93X CONNECT bericht opgenomen worden dat door de lokale brouter naar het netwerk wordt gezonden als deze de verbinding geaccepteerd. Over het algemeen zal het netwerk een voorstel voor de invulling van de parameters gegeven hebben in het SETUPbericht, waarop de brouter dan kan antwoorden rekening houdend met de input parameters. De opmerkingen die eerder gemaakt zijn ten aanzien van de maximale frame-afmetingen op het LAN in het kader van scenario 1 zijn ook hier van toepassing. De B-zijde (hier de lokale brouter) moet de call-setup weigeren/afbreken als blijkt dat het ISDN niet aan bepaalde minimale voorwaarden kan voldoen ten aanzien van de Link. Layer Core parameters of transitdelay (voor zowel de in- als uitgaande frame-relay verbinding). Zo moet de binnen het LAN-afgesproken frame-lengte verwerkt kunnen worden, en mag de transit delay niet te groot worden waardoor de "lifetime" van een ISO 8473 pakket verstrijkt voor het zijn bestemrning kan bereiken. Output parameters

Na het eindigen van de ISDN-setup procedure (al dan niet met een succesvol verloop) zullen er een aantal parameters beschikbaar zijn. Bij een niet succesvol verloop kan er bijvoorbeeld een oorzaak voor het mislukken aangegeven worden. Deze zijn bij een ink.omende call-setup voor de ontvanger, hier de lokale interworkingunit en het LAN, niet van belang. Indien er weI een frame-relay verbinding tot stand gebracht wordt zijn er een aantal output parameters die voor de brouter van belang zijn. Zoals de op de verbinding te gebruiken DLCI-waarde en de NSAP-adressen van het remote LAN-station en LLC- en MAC-adressen van het lokale LAN-station. Deze worden als onderdeel van resp. het Calling- en Called party subadres in het SETUP-bericht in de brouter aan de B-zijde ontvangen (De LLC- en MAC-adressen als onderdeel van een NSAP-adres).

108 Hoofdstuk 7


Bljwerken van de tabel

De nieuw verkregen DLCI-waarde wordt samen met het MAC- en LLC- adres van het lokale LAN-station en het NSAP-adres van het remote LAN-station in de tabel ingeschreven, zodat zowel een inkomend- als een uitgaand-frame correct bij de juiste bestenuning kan worden afgeleverd. Verder wordt er voor de nieuwe DLCI waarde een timer gestan, die er zoals gebruikelijk voor zorgt dat de verbinding niet oneindig lang ongebruikt blijft "staan". V an het lokale LAN-station hoeft voor de verwerking van inkomende frames niet de relatie tussen het hele NSAP en de DLCI-waarde bijgehouden te worden, maar slechts van de MAC- en LLC-adressen (onderdeel van een compleet NSAP-adres). Om echter ook verwerking van uitgaande frames mogelijk te maken is het verstandig om toch het hele NSAP van het lokale LAN-station in de tabel onder te brengen (in de figuren worden alleen de MAC- en LLC-adressen genoemd).

Actieve toestand In de actieve toestand bestaat er een frame-relay verbinding tussen een lokaal- en een remote-LAN-station. In deze paragraaf wordt de verwerking van inkomende Q.922 core frames behandeld. Vit een Q.922 core frame dat in de brouter arriveert5 zal de inhoud van het data- en control-veld verwijderd worden, en vervolgens doorgegeven aan de LLC-l entiteit om daar in een LLC-l frame ondergebracht te worden. Voorde in het Q.922 core frame ondergebrachte DLCI-waarde zullen de corresponderende MAC- en LLC-adressen opgezocht worden in de tabel. Het MAC- en LLC-adres van het lokale (bestemmings) LAN-station zijn direct beschikbaar als onderdeel van het NSAPadres. Het LLC-adres van het remote (source) LAN-station wordt uit het betreffende NSAP-adres gehaald. Het C/R-bit dat in het SSAP-veld van het te verzenden frame thuis hoon is afkomstig van het Q.922 core frame C/R-bit (onderdeel van het DLCI-adresveld). Verder zal de bij de betreffende DLCI-waarde behorende timer gereset worden. Adres-fnapplng op MAC-Iasg

Zoals bekend wordt er in scenario 1 van een normale MAC-service gebruik gemaakt voor de verbinding tussen de brouter en het LAN-station, zie voor de adres-mapping figuur 7.4.

5

Met arriveren woldt bier bet zonder fouten ODtvangen bedoeld; als er een fout in bet frame gedetecteeld wordt aan de hand van de FCS woldt bet frame als Diet ontvangen beschouwd.

Globale werking van scenario 2 109

Sctmario2

TABEL

_

DI.CI

I

;---D-----..,I

/

1.LC>1

/

r' IL..... MAC-•IA Figuur 7.4: Verwerking van een inkomend 0.922 core frame in scenario 1

ISDN-verbinding verbreken Als er een timer voor een bepaalde DLCI-waarde afloopt omdat er blijkbaar geen verkeer meer is tussen de twee LAN-stations waarvoor de verbinding is opgezet, zal de brouter in het control-plane een release-procedure in het ISDN activeren. Op het niveau van laag 3 zal als gevolg hiervan een Q.93X DISCONNECT bericht naar het ISDN gezonden worden, waarna het netwerk de verbinding zal verbreken (de hiervoor uitgevoerde procedure is identiek aan die voor andere ISDN bearer-services). In de brouter wordt de betreffende DLCI-waarde uit de tabel verwijderd. De corresponderende timer was (zoals boven verondersteld) reeds afgelopen. Hiermee komt de router voor de relatie van lokaal- en remote-LAN-station in de rust toestand. Uiteraard blijven eventuele andere frame-relay connecties gewoon bestaan.

7.3 Scenario 2 Het eerder in hoofdstuk 3 gepresenteerde interconnectie-scenario 2 wordt in deze paragraaf nader uitgewerkt. Zie in figuur 7.5 nogmaals de protocol-stack van scenario 2.

7.3.1 Globale werking van scenario 2 Ook in dit scenario wordt de interworking tussen een LAN en de ISDN-frame-relay service veIZorgt door een routerlbridge combinatie. Het verschil met scenario I is dat er hier een

110 Hoofdstuk 7


lSOB473

lSOB473

LLC 1

LLC 1

MAC

j ~~_-.._ I

I

O.922cor. ''----O./i_21

----

~---

(BB02.X)

(BB02.X)

I

O.93X

I

1.430.1.43: I

.........

Figuur 7.5: Overzicht van scenario 2, Brouter B

MAC-bridge in de brouter gei'ntegreerd is zodat de LAN-stations ook op het ruveau van de MAC-sublaag rechtstreeks de eindbestenuning (een station van een remote-LAN) kunnen adresseren in plaats van de interworking unit. Aangezien de adressering in dit scenario op alle ruveaus vanaf de MAC-sublaag en hoger end-to-end plaatsvindt hoeven er in ten aanzien van adressering geen wijzigingen in de LAN-stations aangebracht te worden: de LAN-stations van het lokale LAN adresseren op de genoemde ruveaus rechtstreeks de stations op het remote LAN (als source-adressen, SA, SSAP en Source-NSAP, worden in de diverse pakketten uiteraard de "eigen" adressen van de stations ingevuld).

"Filter-functie" van de MAC-Iaag De MAC-laag van de brouter in scenario 2 moruton continu alle MAC-frames die voorbij komen. AIle MAC-frames met een bestenunings (MAC)-adres, DA, dat zich ruet op het lokale LAN bevindt zullen er vanaf gehaald worden, om vervolgens via een frame-relay verbinding naar de uiteindelijke bestenuning gerelayeerd te worden. Aan de hand van een tabel met MAC-adressen van stations die zich op het lokale LAN bevinden kunnen deze "vreemde" DA-adressen herlcend worden. Het invullen van zo 'n tabel kan bijvoorbeeld door een systeem-operator gebeuren. Maar ook door de interworkingunit zelf: deze observeen dan continu de SA (source MAC-adres) velden in de MAC-frames, waarbij alle nog niet bekende MAC-adressen aan de tabel worden toegevoegd (SA adressen in gerelayeerde pakkenen mogen niet toegevoegd worden omdat dit SA-adres zich niet op het lokale LAN bevindt. Hiervoor kan de interworkingunit zelf zorgen omdat deze zelf de "bron" is van de gerelayeerde frames met zulke "ongeldige" SA-adressen).

Tabel De genoemde tabel kan men ondergebracht denken in het management gedeelte van de brouter. Behalve voor de hierboven beschreven f1lter-funetie zal de inhoud van de tabel gebroikt worden voor eenjuiste mapping van MAC-adressen die op de LAN's gebroikt

Scenario 2

G/oba/e werking van scenario 2 111

worden en de corresponderende DLCI-waarden van de ISDN-frame-relay verbindingen (indien die bestaan). Zo zal er voor een bestaande frame-relay-verbinding tussen een lokaal- en een remoteLAN-station in de tabel een relatie tussen de DLCI-waarde en de MAC-adressen van de betrokken LAN-stations bestaan. Mapping

In scenario 2 worden DLCI-waarden, met behulp van de tabel, op MAC-adressen "gemapt" (LLC- en laag 3 NSAP adressen blijven ongemoeid). Voor een uitgaand bericht wordt in de tabel met behulp van de SA- en DA-MAC adressen in het frame de bijbehorende DLCI-waarde opgezocht. Inkomende frames worden precies andersom behandeld: aan de hand van de DLCI in het Q.922 core frame worden in de tabel de corresponderende SA- en DA-MAC adressen bepaald.

Timer Ook in scenario 2 wordt de "timer-methode" toegepast om ervoor te zorgen dat een bestaande frame-relay verbinding in het ISDN verbroken wordt als deze gedurende een bepaalde, door de timer te bij te houden periode niet gebruikt is.

Afmetingen van laag 3 pakketten Evenals in scenario 1 gelden er in dit scenario beperkingen voor de maximale lengte van laag 3 pakketten zoals die door de LAN's geconstrueerd mogen worden. Zowel het LAN als de ISDN framerelay bearer kennen hun beperkingen. Voor het LAN worden deze bepaald door de specifiek gebruikte MAC-Iaag protocollen (zie eerder in dit hoofdstuk). In het ISDN kan over de frame-lengte onderhandeld worden. Het is net als in scenario 1 ook hier eigenlijk niet mogelijk om de in de brouter met het ISDN daarover gemaakte afspraken aan de LAN-stations mede te delen. De beste oplossing voor dit probleem is om met alle LAN-stations een bepaalde framegrootte af te spreken waarvan (bijna) zeker is dat ze via het ISDN getransporteerd kunnen worden. Als ook in dit scenario met het ISDN een frame-Iengte van 4096 bytes overeen gekomen kan worden (net als in scenario 1), dan is de beschikbare mimte voor userdata in een Q.922 core frame 2 bytes minder dan in scenario 1. Dit komt omdat er in dit scenario een compleet LLC-1 frame getransporteerd wordt, terwijl in scenario 1 aileen bet data- en control-veld daarvan in een Q.922 core frame ondergebracbt wordt. Bij een ISDN-frame lengte van 4096 bytes mogen ISO 8473 pakketten maximaal4096-3 4093 bytes bevanen. 2 bytes wonien bezet door bet SSAP- en DSAP-veld van bet LLC-frame. Venier is 1 byte in gebnrik voor bet LLC-control-veld.

II:

112 Hoofdstuk 7


7.3.2 Actieve toestand: inen uitgaande frames Het systeem bevindt zich in de actieve toestand als er een frame-relay verbinding bestaat voor de interconnectie van een lokaal- en remote-LAN-station. Van zo'n situatie wordt in deze paragraaf uitgegaan. Een belangrijk kenmerk is dat er voor de betreffende frame-relay verbinding aan beide zijden van het ISDN (in de brouters) DLCI-waarden aanwezig zijn in de eerder genoemde tabel, samen met de lokaleen remote-MAC-adressen van de betrokken stations.

Inkomend Q.922 core frame In het user dataveld van het Q.922 core frame dat in een brouter binnen komt (die we hier even als de "lokale" brouter" beschouwen) zit een compleet LLC-l frame in ondergebracht. Met behulp van de DLCI-waarde wordt in de lokale tabel gezocht naarde SA- en DA-MAC adressen die op het lokale LAN van toepassing zijn.Voor elke DLCI-waarde wordt een timer gestart op het moment dat deze DLCI in de tabel geschreven wordt. Op het moment dat de tabel voor een bepaalde DLCI-waarde geraadpleegd wordt zal de corresponderende timer gereset worden zodat er een nieuwe "levensduur" voor de betreffende ISDN verbinding in gaat. De MAC-adressen worden samen met het dataveld uit het Q.922 core frame (dit dataveld bevat een LLC-l frame) als onderdeel van een MA_UNITOATA request primitieve aan de MAC-service provider aangeboden, die voor het verdere transport (van het LLC-I frame) naar het lokale LAN-station zal zorgen.

Uitgaande frames Als er in de interworkingunit een MAC-frame arriveert met een bestemming die via een frame-relay verbinding te bereiken is, waarvan hier aangenomen wordt dat die reeds bestaat (OLCI-waarden met bijbehorende MAC-adressen zijn beschikbaar in de tabellen van de lokaleen remote-brouter), dan kan dit frame onmiddellijk op MAC-niveau "gerelayeerd" worden. Standaard wordt voorelk: binnenkomend MAC-frame dat een bestemming buiten het lokale LAN heeft (er wordt'hier verondersteld dat de "fIlter-functie" zijn werk reeds heeft gedaan) in de tabel naar een OLCI waarde gezocht met als input de SA- en OA-adressen in het MAC-frame. Als er geen OLCI waarde gevonden kan worden bestaat er nog geen verbinding met de gewenste eindbesternming: deze zal dan eerst opgezet moeten worden, zie de volgende paragraaf. In afwachting van het tot stand komen van die verbinding wordt het betreffende frame opgeslagen, en vervolgens verzonden op het moment dat de verbinding is opgezet, en de noodzakelijke DLCI-waarde beschikbaar is. Zoals eerder reeds vermeld is zal tevens de bij de DLCI-waarde horende timer gereset worden.

Scenario 2

Actieve toestand: inen uitgaande frames 113

TABEL

I I

1.L.C>1

I I I

ID8API ..~ I~ I-D..-~I --------~. / '\ i

/

/

I

/

/

I

/ / SA

--

/ /

DA

Figuur 7.6: Verwer1
Inkomende frames Een 10kale brouter zal pas inkomende frames ontvangen als er een frame-relay verbinding in het ISDN-bestaat: dit is het geval in de actieve-toestand. Als gevolg van het werkingsprincipe van de brouter (o.a. de adrninistratie van de "tabel") zal er voor een inkomende Q.922 core frame een relatie tussen de daarin ondergebrachte DLCI-waarde en de te gebruiken MAC-adressen aanwezig zijn in de tabel. De mapping van de velden in het Q.922 core frame op de parameter van een MA_UNITDATA request primitieve, die vervolgens aan de MAC-service provider aangeboden wordt, is in de onderstaande figuur afgebeeld. (Er wordt bier geen mapping geven van een Q.922 core frame naar een MAC-frame, omdat er in het kader van dit verslag een aantal verschillende MAC-protocollen gebruikt kunnen worden: de MAC-service is echter unifonn, de bijbehorende primitieven dus ook).

114 Hoofdstuk 7


lABEL.

DLCt

~

/

I

/r

I

I

I ~

MAC

---r--

II I I I I I I I / ~ /

L1.Co1

__................

MAC

/

I

j

l

D"

'"

...rdaa

----'

0 .... _

Figuur 7.7: Verwerking van een inkomend 0.922 core frame in scenario 2

7.3.3 Rust toestand In de rust toestand bestaat er geen frame-relay connectie voor de overdracht van infonnatie tussen een bepaald lokaal- en remote-LAN-station. Vanuit de rust toestand kan naar de actieve toestand overgegaan worden na het succesvol afwerken van een ISDN-setup-procedure. Deze kan gelnitieerd worden door de lokale interworking unit (uitgaand), of door het netwerk (inkomend). Beide situatie worden hieronder afzonderlijk behandeld.

Ultgaande ISDN-setup procedure Na ontvangst van een "onbekend" MAC-frame in de brouter vanuit het lokale LAN zal dit frame tijdelijk opgeslagen worden. Ben kopie ervan wordt verder geprocessed: decompositie. Het dataveld (d.i. een LLC-l frame) van het MAC-PDU wordt aan de LLC-sublaag doorgegeven. Dit LLC-l frame wordt binnen de LLC-sublaag verder processed. Alleen een UI-comrnand-LLC-frame (UlUlumbered Information) bevat in zijn dataveld een ISO 8473 pakket (of segment pakket). Dit wordt vervolgens doorgegeven aan de netwerklaag binnen de brouter. Daar wordt o.a. aan de hand van de informatie uit de NSAP-adressen van dat pakket een ISDN-frame-relay bearer aangevraagd. Dit gebeurd vervolgens op dezelfde wijze als in scenario 1 (waarbij o.a. een in hoofdstuk 6 beschreven procedure "aangeroepen" wordt). Nadat de frame-relay cOlUlectie in het ISDN tot stand is gekomen, is er aan die verbinding een DLCI-waarde toegewezen. Deze zal zoals eerder beschreven is in de tabel opgenomen

Scenario 3

Rust toestand 115

worden, samen met de MAC-adressen van het lokaleen remote-LAN-station uit het uitgaande MAC-frame. Bovendien zal de nieuwe DLCI-waarde aan de interworkings-functie op laag 2 medegedeeld worden, zodat daar het opgeslagen MAC-frame verzonden kan worden. Verder wordt uiteraard een timer gestart voor deze nieuwe frame-relay verbinding (zoals reeds eerder is venneld).

Inkomende ISDN-SETUP procedure Ook een remote LAN-station kan een ISDN-setup procedure initieren. Deze zal dan vervolgens via het ISDN bij de hier beschouwde lokale brouter "arriveren" in de vonn van een inkomend SETUP-bericht. De uitvoering van deze procedure is reeds bij scenario 1 behandeld. Na afloop ervan zal o.a. de DLCI-waarde toegewezen zijn die de nieuwe frame-relay connectie identificeert. Uiteraard zal deze waarde in de tabel worden opgenomen, samen met de MAC-adressen van de betrokken lokaleen remote-LAN-stations. Deze MAC-adressen zullen afkomstig zijn uit het SETUP bericht (ze zijn aanwezig als onderdeel van de NSAP-adressen in de calling/called party subaddress infonnation elements). Het is duidelijk dat er ook een timer gestart zal worden voor de nieuwe DLCI-waarde zoals in het voorgaande beschreven is.

ISDN-verbinding verbreken Als er een timer voor een bepaalde DLCI-waarde afloopt omdat er blijkbaar geen verkeer meer is tussen de twee LAN-stations waarvoor de verbinding is opgezet, zal de brouter in het control-plane een release-procedure in het ISDN activeren. Op laag 3 zal als gevolg hiervan een Q.93X DISCONNECf bericht naar het ISDN gezonden worden, waama het netwerk de verbinding zal verbreken (de hiervoor uitgevoerde procedure is identiek aan die voor andere ISDN bearer-services).

In de brouter wordt de betreffende DLCI-waarde uit de tabel verwijderd. De corresponderende timer was (zoals boven verondersteld) reeds afgelopen. Hiennee komt de router voor de relatie van lokaal- en remote-LAN-station in de rust toestand. Uiteraard blijven eventuele andere frame-relay connecties gewoon bestaan.

7.4 Scenario 3 De interworkingunit (het middelste gedeelte in de onderstaande figuur), die het contact verzorgt tussen het LAN en het ISDN bij een abonnee, is in dit scenario uitsluitend actief als "relay" op het niveau van de netwerklaag. Er zullen dus in tegenstelling tot de vorige

116 Hoofdstuk 7


scenario's daadwerkelijk ISO 8473 pakketten verwerkt worden. ISO 8473 pakketten zul1en door middel van een Q.922 frame-relay verbinding in het ISDN getransporteerd worden. Voor de mapping van de Q.922 primitieven op ISO 8473 Subnetwerk primitieven is een speciale convergence laag aanwezig tussen de IS08473- en Q .922-laag. De functie daarvan zal verder in dit deeI van het hoofdstuk verklaard worden.

1508473

LLC 1

LLC 1

----

~

1508473

--

I-'--~-

MAC

MAC

r-----

r-----

(8802.X)

(8802.X) I

..

0.93X

0.922 ~----~

0.921

----~

-,

--_._--

--

1.4301/.431 0_

I

_..-.. ~

I

1 __

I

~_

Figuur 7.8: Overzicht van scenario 3; een router

7.4.1 Globale werking van scenario 3 In scenario 3 kan de interworkingunit op het niveau van laag 1 en 2 als een "nonnaal" LAN-station beschouwd worden: op die niveaus bestaan er geen verschillen met de echte LAN-stations. Op laag 3 is er in de interworking unit echter weI een verschil: hierin bevindt zich een relay/routeer functie. Tenslotte is er aan de ISDN-zijde van de router een speciale Subnetwork Dependent Convergence Function (SNDCF) tussen laag 3 en de Q.922-laag. Deze dient voor het mappen van ISO 8473 Subnetwork primitieven op Q.922 primitieven.

Adressering binnen het LAN Bovengenoemde eigenschappen hebben invloed op de mamer waarop een LAN-station de interworkingunit moet "aanspreken" (adresseren) om ervoor te zorgen dat pakketten via het ISDN naar een ander LAN getransporteerd worden, en andersom: er kunnen uiteraard ook pakketten vanuit een remote LAN verstuurd worden naar het hier beschouwde lokale

LAN. Adresserlng op MAe-laag nlveau

LAN-stations die MAC-frames met daarin een ISO 8473 pakket6 naar een LAN-station van het via het ISDN verbonden remote-LAN willen verzenden moeten in scenario 3 het 6

Vanwege het feit dat bet MAC en LLC protocol geen segmentation/reassembly functie bevatten zijn er altijd complete (segment) ISO 8473 pakketten in een MAC-frame ondergebracht

Scenario 3

Globale werking van scenario 3 117

MAC-adres van de interworkingunit gebruiken als destination-adres (DA) en niet het adres van het remote-LAN-station. De (standaard) irnplementatie van het MAC-protocollen dat in de interworking unit opereen zal irnmers alleen MAC-frames van het LAN afnemen als daarin zijn MAC-adres als destination staat. Als source-MAC adres vult het LAN-station uiteraard zijn eigen adres in. Het omgekeerde geldt uiteraard ook: MAC-frames die door de interworkingunit naar een bepaald LAN-station gestuurd worden bevatten als destination adres (DA) het MAC-adres van dat station. Als SA wordt het MAC-adres van de interworkingunit gebruikt. In beide gevallen wordt het MAC-adres van het zendende eind-systeem als source adres

in de frames opgenomen (SA). Hierbij kan zowel een LAN-station als de interworkingunit het zendende eind-systeem zijn. Adressering op Logical Link niveau

Een soon gelijke situatie doet zich op de LLC laag voor. Met een DSAP-adres (destination) wordt een LLC-Service Access Point aangeduid dat zich in het bestemmings eind-system bevindt. En in het SSAP-adresveld wordt door de zender van een LLC-frame het eigen, voor de betreffende link gebruikte, SAP-adres ingevuld. In LLC-frames die door een lokaal LAN-station naar de interworkingunit (IWU) gezonden

worden bevatten als DSAP een LLC-SAP adres van de IWU, en als SSAP het eigen LLC-SAP adres van het LAN-station. De IWU adresseert met het DSAP de bestenunings-SAP in het lokale LAN-station, en gebruikt als SSAP zijn eigen LLC-SAP-adres. Adresserlng blnnen de netwerlclaag

De adressering op het niveau van de Netwerklaag, d.m.v. NSAP-adressen, vindt net als bij scenario 1 en 2 ook hier end-to-end plaats. Een zendend lokaal LAN-station adresseert een remote LAN-station rechtstreeks met zijn NSAP-adres. De tussenliggende interworking unit wordt op het niveau van de netwerklaag dus nooit geadresseerd.

Frame grootte & segmentation Op het LAN gelden de eerder genoemde beperkingen ten aanzien van de maximale frameen pakket-afmetingen. Deze zijn afhankelijk van het gebruikte LAN-type. Bij de vorige scenario's moest er door de LAN-stations bovendien rekening gehouden worden met de maximale frame-size op de ISDN-frame-relay bearer. In dit scenario is dat niet nodig. Er vindt hier irnmers interworking op de met ISO 8473 gevulde netwerklaag plaats. Dit protocol kan door middel van segmentation en/of reassembly van ISO 8473 pakketten zorgen voor een conversie van de frame-Iengten tussen het LAN en de ISDN-framerelay

118 Hoofdstuk 7


bearer. (De lengte van een te relayeren frame op het ISDN heeft een vaste verhouding met de lengte van een ISO 8473 pakket). De enige eis die door ISO 8473 protocol in het algemeen aan subnetwerken, en dus ook een frame-relay bearer gesteld wordt is dat ISO 8473 pakketten met een m.inirnale lengte van 512 bytes in zijn geheel getransponeerd moeten kunnen worden.

0.922 Voor het transpon van ISO 8473 frames wordt gebruik gemaakt van een subset van het Q.922 protocol. Dit protocol is bedoeld voor het realiseren van een Connection Oriented Data Link service op elk willekeurig ISDN-kanaal. Speciaal ten behoeve vande overdracht van management-achtige frames (van het protocol) is er ook een CL-Unacknowledged service aanwezig (bijvoorbeeld voor overdracht van SABME·, DISC en XID-frarnes). Deze service voorziet ook in de overdracht van Unnumbered Information command frames, VI-command, die gebruikt kunnen worden voor unacknowledged CL userdata overdracht: te vergelijken met hetgeen de LLC-1 service biedt. In de ISO 8473 standaard wordt bepaald dat een subnetwerk waarvan dit protocol gebruik maakt bij voorkeur een CL-datalink service moet bieden. Dit is met de Q.922 VI-command frames eenvoudig te realiseren. Voor ondersteuning van ISO 8473 zal dus slechts een subset van Q.922 gebruikt worden, narnelijk alleen de procedures voor een CL-service.

Tabel De relatie tussen een DLCI-waarde en de NSAP-adressen van de lokaleen remote LAN-stations die via de betreffende frame-relay connectie contact met el.kaar onderhouden wordt, net als bij de andere scenario's, in een tabel bijgehouden. Verder is het voor de werking van de segmentation functie in de IWU noodzakelijk om voor iedere ISDN-framerelay connectie de afgesproken maximale frame-Iengte op te slaan in de tabel. Deze parameter wordt dan automatisch gekoppeld aan de bij de connectie behorende DLCI-waarde en daannee corresponderende NSAP-adressen. In de vorige scenario's was dit niet noodzakelijk omdat voor zowel het LAN- als alle ISDN-framerelay connecties een unifonne (default) framelengte werd afgesproken. Timer

Uiteraard wordt er ook in scenario 3 van timers gebruik gemaakt voor het verbreken van frame-relay connecties die lange tijd ongebruikt zijn.

Scenario 3

Aetieve toestand 119

Actieve en Rust toestanden Evenals in de voorgaande scenario's zijn er in de relatie tussen een lokaal- en remote LAN-stations twee toestanden te onderscheiden: een actieve en rust. In de actieve toestand is er een frame-relay verbinding tussen twee IWU's zodat het lokaleen remote-LAN-station frames/pakketten met elkaar kunnen uitwisselen. In de rust toestand bestaat deze frame-relay verbinding niet.

7.4.2 Actieve toestand In de actieve toestand kunnen twee LAN-stations onmiddellijk frames en/ofpakketten met elkaar uitwisselen.

Uitgaande ISO 8473 pakketten Een ISO 8473 pakket dat op de netwerklaag arriveert voor verzending naar een remote LAN zal als voIgt behandeld worden. ISO 8473

TABEl

-=

s~mentation

~. - : - -.0=

I

I

III

I

---\---

I

I

i D'"

....

Figuur 7.9: Verwerking ultgaande ISO 8473 pakketten in scenario 3

Allereerst worden de Source en Destination NSAP-adressen van het pakket gebruikt om met behulp van de eerder genoemde tabel te bepalen of er reeds een frame-relay connectie bestaat waarop het betreffende pakket door gezonden kan worden (na eerst in een Q.922-UI-command frame ingepakt te zijn). In het andere geval moet er eerst een nieuwe verbinding opgezet worden (de betreffende relatie tussen het lokaleen remote LAN-station bevindt zich dan m de rust toestand), in afwachting van het tot stand komen daarvan zal het betreffende ISO 8473 pakket opgesla-

120 Hoofdstuk 7


gen worden (gedurende "lifetime" van het pakket). Zie voor het opbouwen van zo'n verbinding de volgende paragraaf. In het hier besproken "actieve" geval is de benodigde frame-relay connectie beschikbaar, evenals de DLCI-waarde. segmentatIon/reassembly

Vervolgens zal er indien noodzakelijk segmentation of reassembly van het ISO 8473 pakket plaatsvinden. Na segmentation ontstaan er uiteraard meerdere (afgeleide) pakketten die aIlemaal verzonden moeten worden, terwijl er bij reassembly van twee of meer pakketten een groter ISO 8473 pakket zal ontstaan (hiervoor moet echter in de router weI eerst gewacht worden op de binnenkomst van vervolg-pakketten: als dit te lang gaat duren met het oog op de maximale levensduur, en in verhouding met de transit-delay van de frame-relay connectie, moet het eigenlijk te kleine ISO 8473 pakket toch verzonden worden). Het ISO 8473 pakket, of de daar van af geleidde segmenten pakketten, zal (of zullen) veIVolgens in een Q.922 UI-Command-frame "ingepakt" worden, waarna ze via de frame-relay bearer naar de eindbestemming gezonden worden. MappIng van prlmitieven tussen netwerken 0.922 laag

In het Q.922 pakket is naast een ISO 8473 pakket, dat zich in het dataveld bevindt, een DLCI-waarde, een FCS en een control-veld aanwezig (Het control-veld is bij een UI-command-Q.922 pakket, zoals hier gebruikt wordt, slechts 1 byte lang).

Er zijn voor de overdracht van ISO 8473 informatie uitsluitend Q.922-UI-command-frames noodzakelijk. Het verzenden daarvan door de Q.922-laag geschiedt op commando van een DL-UNITDATA request primitieve. De ontvangst van een Q.922-UI-command frame leidt tot het "zenden" van een DL-UNITDATA indication prirnitieve naar de netwerklaag. Zowel het DL-UNITDATA-request- als indication primitieve bevatten een laag 3 datapakket, in dit geval een ISO 8473 pakket en een DLCI waarde.

Voor aile duidelijkheid: deze primitieven worden niet rechtstreeks met de ISO 8473 laag 3 uitgewisseld, maar met een subnetwerk dependent convergence layer die zich tussen de Q.9221aag en de ISO 84731aag bevindt. Op dezelfde manier wisselt de ISO 8473 laag met die convergence-laag SN_UNITDATArequest- en indication prirnitieven uit. Het zal duidelijk zijn dat de convergence layer voor "mapping" tussen SN-UNITDATAen DL-UNITDATA- primitieven zorgt. (Een SN-UNITDATA-request wordt op een DL-UNITDATA request gemapt, en een DL-UNITDATA indication op een SN-UNITDATA-indication: de "mapping" is dus zoveel mogelijk een-op-een).

Actieve toestand 121

Scenario 3

De verschillende parameters in de primitieven worden als voIgt op elkaar "gemapt": Voor de userdata parameters is het eenvoudig: SN-Userdata op DL-Userdata (en omgekeerd). Het mappen van de DLCI-parameter van de DL-UNITDATA primitieven op de SN-Source- en SN-Destination-adres parameter is ingewikkelder, zie onderstaande figuur. De SN-source- en destination adressen bestaan ieder uit de combinatie van een MAC- en LLC-adres van resp. het bron- en bestemmings LAN-station. Deze MAC- en LLC-adressen zijn onderdeel van de in de tabel opgeslagen NSAP-adres-paren (van het lokaleen remote LAN-station). Samen met de eveneens in de tabel opgeslagen (corresponderende) DLCI kan de relatie tussen de MAC- en LLC-adressen en de DLCI bepaald worden die voor de adres-mapping tussen Q.922- en convergence-laag noodzakelijk is. Tabel wordt twee maal geraadpleegd

In de uitgaande richting zal de tabel voor elk ISO 8473 pillet twee maal geraadpleegd worden. De eerste keer door de ISO 8473 laag 3 entiteit om te bepalen of de combinatie van NSAP-adressen in het pillet al in tabel voorkomt, zodat er dus ook een frame-relay verbinding beschikbaar is op dat moment. En de tweede keer door de convergence functie om de MAC- en LLC-adressen in de SN-source- en destination adres parameters te vertalen naar een DLCI-waarde.

Inkomende "ISO 8473" pakketten Er kunnen alleen Q.922 VI-command frames, met daarin een ISO 8473 pillet, in de interworkingunit arriveren als de "verbinding" tussen het lokaal- en remote-LAN-station actief is. De verwerking van zo'n frame komt hieronder aan de orde. 180 ..73

'1~' :.lL I I

lABEL

R......

I.. I •-

L- _ _ ~

I

__

I

I II

I I ~I

1

~

I r

I

....

Figuur 7.10: Verwerking Inkomende ISO 8473 pakketten in scenario 3

122 Hoofdstuk 7


De inhoud van het frame wordt in de vonn van een DL-UNITDATA indication primitieve aan de convergence Iaag doorgegeven. Deze primitieve bevat een ISO 8473 pakket en een DLCI-waarde. De verwerking van deze primitieve in de convergence Iaag is eenvoudig: de data wordt "gemapt" op de SN-userdata parameter. Verder wordt de SN-destination parameter ingevuld met het globale LLC- en MAC-adres en de SN-source parameter met nul-adressen. De globale bestemmingsadressen in de SN-UNITDATA indication primitieve zijn mogelijk omdat er aan laag 3 geen routeringsinfonnatie gegeven hoeft te worden: in ISO 8473 is inuners zowel een source- als destination NSAP-adres aanwezig. Het gebruik van de nul MAC- en LLC- adressen in de SN-source address parameter is mogelijk omdat er van een Q.922 datalink gebruik gemaakt wordt in plaats van de combinatie van LLC- en MAC-protocollen. Het zal duidelijk zijn dat deze manier van "adres-mapping" een sterke vereenvoudiging is ten opzichte van de verwerking van inkomende pakkenen in de andere scenario's. Deze methode is mogelijk omdat aIle pakkenen door Iaag 3 verwerkt worden, en daar is volledige adresseringsinfonnatie "automatisch" aanwezig (zit immers in de ISO 8473 pakkenen).

Flow-control In het DLCI-veld in de Q.922 (core) frames 7 zijn ten behoeve van flow control binnen de datalink laag twee bits gereserveerd; een forward- en backward explicit congestion notification bit. Met het "Forward" bit kan het netwerk aan de gebruiker melden dat congestie in de zendrichting dreigt op te treden (of reeds is opgetreden) waarbij frames verloren kunnen gaan. De zender kan hierop reageren door de windowsize te verkleinen, zodat het netwerk minder wordt belast. Er wordt in dit versiag alleen van een connectionless subset van Q.922 gebruik gemaakt, zodat er van windows bier geen sprake is. WeI kan de IWU zelf barnes weg gaan gooien in bet geval van congestie: biennee wordt in ieder geval de belasting van bet netwerk geringer.

Binnen de huidige beschrijving van Q.922 is gedefinieerd dat het backward bit birmen het netwerk "gezet" kan worden om aan de ontvanger van een frame te melden dat er op de transmissieweg waarvan het frame gebruik heeft gemaakt congestie is opgetreden. Er wordt echter verwacht dat dit in het DLCI-veld gereserveerde bit in de toekomst een andere bestemming zal krijgen. Om die reden zal verder niet op dit bit ingegaan worden.

7

Zowel een Q.922 core- aJs een "compleet" Q.922-frame bevatten uiteraard een DLO-veld, en dus ook de genoemde congestie-bits.

Scenario 3

Rust t08stand 123

Het Forward congestie bit dat in het DLCI-veld aanwezig is kan in scenario 3 gebruikt worden om de ISO 8473 laag 3 aan het lokale LAN-station te laten melden dat er (in de frame-relay verbinding) congestie optreedt. Deze mogelijkheid wordt in het options-part van een ISO 8473 pakket geboden.

In het LAN-station zouden dan door het gebruikte laag 4 protocol, dat hier niet nader omschreven is, passende maatregelen genomen kunnen worden. Opmerking: De primitieven die gebruikt worden voor infonnatieuitwisseling tussen de lagen 2, 3 en 4 bieden geen mogelijk voor het doorgeven van congestie informatie. Dus zowel in het LAN-station als in de interworkingunit zal eventuele uitwisseling van die informatie (tussen de verschillende lagen) een management taak zijn.

7.4.3 Rust toestand Als er geen frame-relay verbinding bestaat voor de interconnectie tussen een lokaal- en remote LAN-station verkeen deze (vinuele) verbinding in de rust toestand.

Uitgaande ISDN call setup De lUst toestand is door de interworking unit (bij uitgaande ISO 8473 pakketten) te herkennen aan het feit dat er voor de combinatie van source- en destination-NSAP-adres er geen DLCI waarde in de eerder genoemde tabel gevonden kan worden. Door het uitvoeren van een call-setup procedure in het ISDN kan van de rust naar de actieve toestand overgaan worden. Het initialiseren daarvan gebeurt vanuit de ISO 84731aag. Deze geeft (met behulp van management-faciliteiten) het ISDN-control plane van de IWU opdracht een frame-relay connectie op te zetten met als bestemming het ISDN-adres dat zich in het destination NSAP binnen een ISO 8473 pakket bevindt (hetzelfde geldt voor het source-adres). Naast deze ISDN-adressen worden ook beide NSAP-adressen in hun geheel aan het control doorgegeven zodat ze a1s subadressen naar de remote IWU getransporteerd kunnen worden (in een Q.931 SETUP-bericht). Verder zullen ereen aantal andere parameters aan het control-plane doorgegeven worden, die dan als "input" voor de setup-procedure kunnen dienen. Hiermee wordt o.a. de protocol structuur van de IWU bedoeld (Q.922 op laag 2 en ISO 8473 oplaag 3, op te nemen in het low layer compatibility information element). Verder informatie ten aanzien van de transit-delay van de ISDNverbindingsweg (af te leiden uit de "lifetime" parameter van ISO 8473 pakketten) en de minimaal vereiste, of gewenste, framesizes (inen outgoing). Na het succesvol verlopen van de setup procedure is er o.a. een DLCI-waarde toegewezen die in opdracht van het control-plane in de tabel geschreven wordt samen met de "bijbehorende" NSAP-adressen. (Voor alle duidelijkheid: de tabel bevindt zich altijd in het "management-plane", ook bij scenario 1 en 2). Verder zijn de inen uitgaande ISDN-frame-sizes voor de betreffende connectie bekend: De uitgaande frame size wordt eveneens in de tabel opgeslagen, zodat er voor ISO 8473

124 Hoofdsruk 7


protocol infonnatie beschikbaar is over de maximaal toelaatbare pakket groone die in de zendrichting gebruikt mag worden. Tenslone zal het ISO 8473 pakket dat de verbindingsopbouw heeft veroorzaakt, verzonden worden volgens de "actieve"-procedure. Nlet-succesvolle ultgaande setup

Ben door de A-zijde uitgevoerde setup kan uiteraard ook mislukken (bijvoorbeeld door het gebruik van onjuiste bestemrnings adressen, storing in het netwerk, incompatible apparatuur bij de B-abonnee, etc). De reden voor het mislukken van een poging wordt door het ISDN in het Q.93X RELEASE bericht aangegeven. Als het door het LAN-station toegelaten wordt om ER-ISO 8473 pakkenen te verzenden kan de IWU het misluk.ken melden, waarbij de reden uit het omvangen RELEASE-bericht gemapt kan worden op een ISO 8473 "Reason for Discard Parameter" die in het options-part van een ER-pakket opgenomen kan worden.

Inkomende call-setup Er is uiteraard ook een call-setup vanuit het netwerk mogelijk (voor inkomende frames). Na het succesvol verlopen daarvan zal de overeengekomen DLCI-waarde samen met de "bijbehorende" NSAP-adressen in de tabel opgeslagen. Deze gegevens zijn dan beschikbaar als er vanuit het lokale LAN pakkenen teruggestuurd moeten worden: voor het ontvangen van pakkenen is deze infonnatie in dit scenario niet van belang. Immers de laag 3 pakkenen worden volledig geprocessed en bevanen aIle benodigde info. Uiteraard wordt ook de toegestane uitgaande frame-size voor de nieuwe verbinding in de tabel geregistreerd. Nlet succesvoile setup poglng van her ISDN

Ben niet-succesvolle setup is mogelijk als het netwerk een foutieve service wil aanbieden, zoals bijvoorbeeld in een "verkeerd-verbonden" situatie kan optreden. Van zo'n niet succesvolle setup-poging vanuit het ISDN wordt binnen de IWU (uiteraard) geen melding gedaan aan de ISO 8473-laag, en dus ook niet aan de lokale LAN-stations. Verbreken van een ISDN-verbinding Tenslotte dient nog venneldt te worden dat eenISDN-frame-relay verbinding door de IWU verbroken wordt door de A-zijde, als de bij de verbinding horende timer afloopt (de betreffende verbinding is dan lange tijd ongebruikt geweest). De ISDN-verbreekprocedure is in Q.931 beschreven, na afloop ervan worden aIle bij de zojuist verbroken verbinding behorende infonnatie uit de tabel in zowel de A- als B-zijde verwijdert.

Resume van de algemene kenmerken

Tabel, en het filtermechanisme 125

7.5 Resume van de algemene kenmerken Ter voorbereiding van het volgende hoofdstuk (conclusies) voIgt in deze paragraaf een resume van de belangrijkste kenmerken van de drie interworkings-cenario's.

7.5.1 Tabel, en het filtermechanisme In aIle besproken scenario's ziet men een mechanisme, waarbij uitgaande LAN-berichten zo mogelijk op een bestaande frame-relay connectie "geplaatst" worden. Deze mapping van LAN-berichten op een ISDN-frame-relay connectie vindt plaats aan de hand van een tabel in de IWU, waarin aIle voor een specifieke frame-relay connectie relevante informatie is opgeslagen (DLCI-, NSAP- en/of MAC-adressen). Filtering De fIltering van berichten voor bestemmingen waamaar (nog) geen frame-relay connectie bestaat van de hierboven genoemde berichten vindt eveneens aan de hand van de tabel plaats: Het niet voorkomen in de tabel van de gewenste bestemming is daarvoor het criterium. (Het is wellicht overbodig om te vermelden dat de I\VU zelf zijn tabel aanpast). Het niveau waarop deze fIltering in de I\VU wordt uitgevoerd is afhankelijk van het specifieke scenario. AIleen in scenario 2 is het voldoende om op het niveau van de MAC-Iaag (onderste helft van laag 2) de fIlter-functie uit te voeren; er is hier sprake van een MAC-bridge die alleen voor "onbekende" MAC-adres-paren een laag 3 functie verricht: opzetten van een nieuwe frame-relay connectie in het ISDN. De filterfunctie in scenario 3 vindt "automatisch" plaats binnen laag 3 van de IWU; de interworking vindt namelijk uitsluitend in de netwerklaag plaats. Hoewel er in scenario I sprake lijkt te zijn van een bridge is het noodzakelijk om de filter-functie toch op laag 3 te plaatsen: alleen door rniddel van de NSAP-adressen kan het noodzakelijke onderscheid gemaakt worden. Dit wordt met name veroorzaakt doordat de LLC-laag weI, en de MAC-laag in dit scenario niet end-to-end is.

7.5.2 Adressering Voor het correct functioneren van de IWU-scenario's is in alle gevallen het gebruik van NSAP-adressen op de LAN's noodzakelijk, waarin naast MAC- en LLC-adressen ook ISDN-adressen (E.I64) ondergebracht moeten zijn. Verder moet binnen het ISDN toepassing van subadressen mogelijk zijn. Hierin kunnen dan complete NSAP-adressen in ondergebracht worden, waaruit de l\VU's de noodzakelijke adresseringsgegevens kunnen afleiden (MAC- en LLC-adressen).

126 Hoofdstuk 7


7.5.3 Flow-control Het Q.922 protocol voorziet in de mogelijkheid om in het netwerk optredende congestie te melden aan, in elit geval, de IWU. Als er congestie gemeldt wordt aan een IWU kan deze hierop reageren door frames weg te gooien, of ze tijdelijk in een buffer op slaan, zodat het ISDN ontlast wordt. Alleen in scenario 3, waarin de interworking op laag 3 plaatsvindt, kan in het ISDN optredende congestie aan de LAN-stations gemeld worden. Deze kunnen dan passende maattegelen nemen. Samenvattend: Als gevolg van de CL-datalink en netwerk-protocollen is flowcontrol in 2 van de 3 scenario's niet good mogelijk, en in het derde scenario enigzins beperkt.

7.5.4 Transport protocol End-to-end wordt er een CL-(Unacknowledged) netwerkservice geboden aan de transportlaag. Functies zoals foutherstel en flowcontrol moeten daarom binnen het transportlaag protocol aanwezig zijn. Bij gebruik van het OSI laag 4 protocol X.224 betekent dit het gebruik van transportklasse 4.

7.5.5 CO/CL-probleem In aile scenario's wordt het CO/CL probleem (LAN's: CL, ISDN: CO) opgelost door middel van een timer die het verbreken van een ISDN-framerelay connectie initieert als deze connectie voor langere tijd niet gebruikt is. Verder wordt een tabel gebruikt om de CL-berichten te "mappen" op de juiste CO verbinding (inelien mogelijk). Telkens na het met succes raadplegen van de tabel wordt de, met een bepaalde DLCI-waarde corresponderende, timer gereset zodat er een nieuwe levensduur van de betreffende frame-relay conneetie start.

Dit is geen ideale oplossing, maar hier de enig mogelijke (de nog primitievere oplossing van het opbouwen en verbreken van een verbinding voor elk datagram wordt hier buiten beschouwing gelaten). Het gebruik van laag 4 infonnatie (monitor-functie, zoals in hoofdstuk 2 is genoemd) is in de drie scenario's niet mogelijk, omdat het gebruikte transportlaag protocol niet nader gedermieerd is. Met laag 4 infonnatie zou een betere storing van het opzetten en verbreken van ISDN-verbindingen mogelijk zijn. De storing d.m.v. timers veroorzaakt altijd het te vroeg of te laat verbreken van een ISDN-verbinding (wat in het laatste geval voor een gebruiker kostbaar kan zijn).

Resume van de algemene kenmerken

Signalering: Binnen- of Buiten de Band 127

7.5.6 Signalering: Binnen- of Buiten de Band In het ISDN vindt signalering "Buiten de Band"g de plaats, en bij LAN's "Binnen de Band". Bij de interconnectie van LAN's m.b.v. een ISDN vorrnen deze verschillen een hindemis, die echter in een IWU op eenvoudige wijze genomen kan worden.

Het nemen van die hindemis gaat hand-in-hand met het oplossen van het CO/CL-interworkingsprobleem, en vereist daarom geen extra processing in de IWU.

7.5.7 Frame-size Zowel de verschillende IEEE 802 LAN-typen, als de ISDN-framerelay-bearer stellen hun eisen t.a.v. de afmetingen van "datablokken" die in een pakket/frame onder gebracht kunnen worden. Ais er geen (volledige) interworking op laag 3 plaatsvindt moeten de LAN-stations rekening houden met de maximale frame-size in het ISDN. De LAN-protocollen bieden geen mogelijkheden om tussen de IWU en de LAN station daarover "afspraken" te maken. In het geval dat de interworking op laag 3 in de IWU uitgevoerd wordt kan deze d.m. v. segmentation/reassembly van laag 3 pakketten een aanpassing van de frame-sizes van het LAN en het ISDN verzorgen. Hiervoor hoeven dus geen eisen aan de LAN-stations gesteld te worden.

Tenslotte: Frame-relay connecties op een D-kanaal zijn niet geschikt voor de LAN-WANLAN interconnectie van de hier besproken LAN's. Dit wordt veroorzaakt door het laag 3 protocol in de LAN's (ISO 8473), dat van een onderliggende service eist dat deze laag 3 pakketten kan verwerken ter lengte van 512 bytes. Het D-kanaal biedt echter slechts 262 bytes ruimte voor user-data in zijn frames.

8

In bet ISDN vindt overdracbt en verwerlring van signalering gescbeiden van userdata plaats. Bij LAN's zijn deze verscbillende data-stromen gecombineerd.

Hoofdstuk8

Conclusies 129

Conclusies

8.1 Mechanismen van interworking:....-

_

Netwerk-interworking blijkt met name betrekking te hebben op de volgende items: Adressering en routering Frame-Iengte; segmenting & reassembly Flow-control, congestie Eindsystemen - Intermediate systemen En wordt bemoeilijkt door de volgende twee (principiele) tegenstellingen: Connection Oriented ¢:> Connection Less interworking "Birmen de Band" ¢:> "Buiten de Band" signalering

8.1.1 (Netwerk)-adressen: Liefsf universeel, b.v. NSAP-sdressen Men ziet dat er ten behoeve van routering (bijna) altijd een venaling van adresseringsinformatie moet plaats vinden als twee of meer verschillende netwerken met elkaar gekoppeld worden. Het gebruik van universele, globale adressen die voor elk netwerk gelden kan deze bewerking vereenvoudigen, of voorkomen: bijvoorbeeld NSAP-adressen. In de drie besproken scenario's is bijvoorbeeld te zien dat door bet gebruik van NSAPadressen (op laag 3) aan beide zijden van een verbinding voldoende adresseringsinfonnatie bescbikbaar is om de koppeling oit te kunnen voeren.

Verder wordt bij eenvoudige routeringsvonnen adresseringsinfonnatie toegepast om een seleetie te kunnen maken tussen pakkenen of frames die weI, of niet naar een remote netwerk overgedragen moeten worden.

8.1.2 Frame-Iengte Afwijkingen in frame- ofpakket-Iengte van gekoppelde netwerken kunnen de oorzaak zijn van problemen: het bestaan van te lange frames/pakkenen voor een bepaald subnetwerk, of een inefficient gebruik van te ruime frames/pakkenen.

130 Conclusies

Hoofdstuk8

Oplossing is mogelijk door gebruik te maken van een segmentation/reassembly functie, dit is echter over het algemeen alleen binnen laag 3 mogelijk. Een andere "oplossing" is het voorafmet alle betrokken systemen een bepaalde frame/pakket lengte af te spreken die voor alle subnetwerken acceptabel is. Ideaal zijn de genoemde oplossingen niet. In het eerste geval is men verplicht om op laag 3 interworking te plegen, terwijl er in het tweede geval beperkingen opgelegd worden aan de betrokken systemen, waaronder gebruikers-tenninals (wijzigingen noodzakelijk).

Frame-relaying i.s.m. ISO 8473 op een O-kanaal is onmogelijk Er is gebleken dat frame-relay connecties op een D-kanaal niet geschikt zijn voor de LAN-WAN-LAN interconnectie van de hier besproken LAN's. Dit wordt veroorzaakt door het laag 3 protocol van de LAN's (ISO 8473), dat van een onderliggende service eist dat deze laag 3 pakkenen kan verwerken ter lengte van 512 bytes. Het D-kanaal biedt echter slechts 262 bytes ruimte voor user-data in zijn frames.

8.1.3 Flow-control: bij CL-netten moeilijk of zelfs onmogelijk Bij koppeling van verschillende netwerk-typen is aandacht voor flow-control van groot belang, zeker als een van de subnetwerken een beperking heeft ten aanzien van troughput. Binnen CL-netwerken blijkt flow-control praktisch onmogelijk te zijn (behalve dan het "weggooien" van pakkenen in het geval van congestie). Sommige CL-protocollen bieden echter weI de mogelijkheid om in het netwerk opgetreden congestie te melden aan de eind-systemen, zodat daar eventueel maatrege1en genomen kunnen worden (door met name hogere laag protocollen). CO-netwerken kennen weI mogelijkheden tot flowcontrol (naast congestie-control). Bij CO/CL-interworking bestaan er op de overgangen tussen CO- en CL-subnetwerken problemen t.a.v. de atbandeling van flow-control. Deze zullen door de eind-systemen opgelost moeten worden.

8.1.4 Eind- & Intermediatie systemen Bij netwerkinterworking hebben we te maken met eind-systemen (zoals gebruikersterminals) en intennediate-systemen die voor de interworking tussen verschillende netwerken zorgen.

Virtuele end-systemen Eind-systemen die communicatie willen plegen via een IWU adresseren vaak onrniddellijk het bestemmings eind-systeem (bijvoorbeeld op het niveau van laag 3), dat echter niet rechtstreeks vanuit het lokale net bereikbaar is. In die gevallen simuleert de IWU (in de rol

HoofdstukB

Conclusies 131

van intennediate-systeem) dit remote eind-systeem, en zorgt ervoor dat de "berichten" bij de gewenste bestemrning arriveren. Het lokale eind-systeem "ziet" in zo'n geval niet de IWU, maar slechts het peer eind-systeem.

8.1.5 CO/CL-interworkingsprobleem: Goed oplosbaar De interworking tussen CO- en CL-netwerken blijkt goed oplosbaar te zijn, waarbij de keuze van een oplossing afhankelijk is van het specifieke comrnunicatie probleem: Van invloed is het niveau waarop interworking plaats vindt (op welke laag binnen het OSI-model), en enkele secundaire factoren zoals de noodzaak voor flowcontrol en segmentatie/reassembly. Aangezien op dit moment alle laag 4 protocollen CO zijn kan het gebruik van informatie uit die laag een oplossing bieden voor een CO/CL-interworkingsprobleem op een onderliggende laag. Het gebruik van laag 4 informatie is echter strijdig met de regels van het OSI-model, maar door handig gebruik te maken van virtuele (intennediate) systemen kunnen de bezwaren ervan ornzeilt worden (Zoals het potentieel verbreken van het end-to-end karakter van laag 4).

8.2 Modelmatige samenwerking (LAN-ISDN) De twee belangrijkste verschillen tussen het LAN-en het ISDN-model worden gekenrnerkt door de wijze waarop signalerings-infonnatie verwerkt, en getransponeerd wordt. In het ISDN geschied dit Buiten de Band, telkens bij de "dec1aratie van een verbinding" (= CO), en bestaat er bovendien een scheiding in een user- en control-plane. Bij een LAN gebeun de signaleringBinnen de Band, en bovendien bij de verwerking/transpon van elk frame/pakket (= CL). Het tweede verschil tussen het LAN- en ISDN-model wordt gevonnd door het feit dat een LAN CL is, en het ISDN CO. Beide verschillen blijken met elkaar in verband te staan: zowel voor het oplossen van het CO/CL-probleem als de scheiding van user- en signalerings-infonnatie is een fIlter-functie vereist die gebruik maakt van een tabel.

8.3 Beoordeling van de scenario's Bij de keuze van de drie scenario's is voomamelijk rekening gehouden met het niveau in de protocol-stack waarop interworking (relaying van user-data) plaats vindt.

132 Conc/usies

Hoofdstuk8

8.3.1 Aigemeen; voor aile scenario's Eerst enkele conclusie die voor alle drie scenario's gelden.

Data Transfer: goed psssend Mogelijkheden voor datatransfer in een CL-LAN en een ISDN dat een frame-relaying dienst biedt blijken goed op elkaar te passen, en vereisen daarom een eenvoudige interworkingsfunctie. De inhoud van de user-data velden in LAN (LLC ofMAC) frames kunnen eenvoudig gekopieerd worden naar corresponderende velden in Q.922 (core) frames. Alleen verschillen in frame-Iengte kunnen vervelend uitwerken, maar zijn door bijvoorbeeld afspraken vooraf goed te ondervangen.

Call Control-interworking: Oms/schtig, maar mogelijk De verwerking van call control infonnatie in de rwD is vrij omslachtig, maarwel mogelijk: voor elk frame moet een tabel geraadpleegd worden, waarmee de in het ISDN gebruikte DLCI-waarde afgebeeld wordt op NSAP-, LLC- en/of MAC-adressen (en omgekeerd). Afhankelijk van het scenario vraagt deze bewerking meer- ofminder processing in de rwD. Tenslotte moet opgemerkt worden dat de oplossing van dit probleem, zoals eerder venneld is, hand-in-hand gaat met CO/CL-interworking. Per saldo zal daarom weinig extra processesing nodig zijn.

Efficientie: goed De interworking van het CL-LAN en het CO-ISDN veroorzaakt een min ofmeer inefficient gebruik van de transmissie-capaciteit van het ISDN. Alle pakketten van een CL-protocol bevatten volledige control-informatie, waaronder adresserings-informatie, om een pakket naar zijn eindbestemming te transporteren. Maar omdat van een CO-frame-relay verbinding gebruik gemaakt wordt (waarbij de DLCI-waarde reeds de rcifieke communicatie-relatie tussen een lokaal- en remote-LAN station identificeert) is die informatie overbodig, zodat gesteld kan worden dat er in de 3 scenario's in principe overbodige control-informatie gerelayeerd wordt. Bij het gebruik van zo groot mogelijk frame-Iengtes wordt het effect van deze overbodige overhead venninderd. Zonder het "verknoeien" van de gelaagde structuur van met name de LAN-protocollen (hetgeen uiteraard ongewenst is) kan het hier boven genoemde probleem niet opgelost worden.

1

EIke communicatie-relatie tussen een lokaal- en remote-LAN station maakt gebruik van een "eigen" frame-relay comectie. Deze connecties worden "gemultiplexed" op een ISDN-kanaal aan de band van DLCI.waarden. Daardoor bestaat er een vast relatie tussen een DLO·waarde en de adressen van een specifieke lokaa1/remote LAN-station-combinatie.

Conclusies 133

HoofdstukB

8.3.2 Voor- en nadelen maken de scenario's situatiespecifiek Helaas kan van geen enkel in dit verslag gepresenteerde scenario gezegd worden dat het een ideale oplossing biedt voor het gestelde probleem: LAN-interconnectie m.b.v. ISDNframerelaying. Ben keuze tussen de scenario's kan pas bepaald worden na afweging van de voor en nadelen ervan, en is afhankelijk van specifieke gebruikers eisen aan de interworking situatie. label 8.1: Belangrijke kenmerken van de 3 scenario's

SeenaflO 2

Scenario 1

ScenariO 3

Adresserlng MAC-laaQ LLC-Iaag LaaQ 3 (ISO 8473 CLNP\ Aanpassingen in LAN-stations t.b.v. adressering noodzakelijk:

Nlveau van data-transfer Complextltelt v.d. fIIterfunctie Volledlge laag 3 Implementatle In IWU Laag 2 protocol In het ISDN (voor data-transfer) Frame-Iengte beperklng Flow-control (I.s.m. LAN-stations) Benodlgde processing In IWU

lokaal end-to-eOO end-to-eOO

end-to-eOO eOO-to-eOO end-to-eOO

lokaal lokaal end-to-eOO

ja

nee

ja

LLC-Iaag

MAC-laaQ

CLNP (Iaag 3)

complex: laag 3

eenvoudig

complex

nee

nee

ja

0.922 core

0.922 core

0.922

.

ja

ja

nee

zeer beperkt

zeer beperkt

mogelijk

gering

omvangrijk

matig

,

Indien men een zo universeel mogelijke oplossing wenst, lijkt scenario 3 het meest geschikt (flow-control, en segmentation/reassembly mogelijk). Als nadeel kan de dan vereiste processing in de IWU genoemd worden. De minste processing vraagt scenario 2, dat bovendien als voordeel heeft dat zowellaag 2 als laag 3 volledig end-to-end zijn. Scenario 1 lijkt het minst aantrekkelijk omdat er voor het uitvoeren van de laag 2 relay-functie telkens hulp ingeroepen moet worden van de filterfunctie op laag 3: een wat "kromrne" situatie.

Voorstel t.a.v. scenario's: Klassen in 0.922 AIleen in scenario 3 is het "complete" Q.922 protocol binnen het ISDN toegepast (in scenario 1 en 2 alleen de core-funeties daarvan). Hoewel dit protocol een CO-datalink service kan bieden wordt in het kader van dit scenario uitsluitend van een CL-subset gebruik gemaakt. Het is immers overbodig om een CO-datalink te gebruiken voor de ondersteuning van een CL-netwerk-protocol. Dit "beperkte" gebruik van het Q.922-protocol kan wellicht als een soon subset in het in ontwikkeling zijnde protocol gedefmieerd worden (Te vergelijken met de 3 verschillende

134 Conclusies

HoofdstukB

LLC-protocol typen). Hiermee kan de irnplementatie van dit protocol in een IWU vereenvoudigd worden. Een voorstel tot het defmieren vanzo'n subset (ofindeling inklassen) in Q.922 is onlangs, als gevolg van deze constatering, in de vorm van een bijdrage bij ccrrr SG XI & XVIII ingediend.

8.4 ISDN

'frame-relaying~

_

De in ontwikkeling zijnde frame-relay techniek in het ISDN lijkt een efficiente en "interworking vriendelijke" mogelijkheid te bieden voor het realiseren van pakket datatranspon, waarbij beter van de mogelijkheden van het ISDN gebruik gemaakt wordt dan bij X.25. Voor frame-relaying geldt, in vergelijking met o.a. X.25:

Goedkoper door eenvoud en, sneller door geringere processing in het netwerk. Een snelle- en universele·data transpon service

Frame-relay bearer services bieden in het ISDN een goede, en universele mogelijkheid om laag 2 frames met user-data te transponeren met zo min mogelijk processing in het ISDN. Er kunnen door de gebruikers van deze service een groat aantal verschillende laag 2 & 3 protocollen toegepast worden (ook meerdere op hetzelfde tijdstip), die een end-to-end functionaliteit hebben. Vooral bij het gebruik van H-kanalen kunnen transrnissie-snelheden geboden worden die voor interconneetie van de huidige LAN's zeer acceptabel zijn. Frame-relaying op B-kanalen is enigszins beperkt in snelheid, maar daar staat tegenover dat er, evenals bij H-kanalen, in principe communicatie met vele abonnees mogelijk is. Ongewljzlgde user/network-Interfaces

Verder is het van belang te weten dat voor het bieden van de frame-relay services geen wijzigingen in de basic-access- (SIT-bus) of primary access-interfaces vereist zijn. Technlsch has/bsre technlek

Aan de hand van drie scenario's is de technische haalbaarheid van frame-relaying voor LAN-interconnectie aangetoond.

Literatuurlijst

135

Literatuurlij~st

_

[1]

Lai, W. S. "Frame Relaying Service: an overview" Proc.INFOCOM '89, Ottawa,pp. 668-673, apr. 1989.

[ 2]

Cherukuri, R.I., Derby, J.H. "Frame Relay: Protocols and Private Network Applications." Proc.INFOCOM '89, Ottawa, pp. 676-685, apr. 1989.

[3]

Cherukuri, R.I., Derby, J.H., Japel, D. "Harmonisation of the ISDN D-channel Link-Access Protocol, with the IEEE 802.2 Logical-Link Control" Proc. GWBECOM '88, Hollywood,pp. 711-715,nov. 1988.

[4]

Lamout, J., Doak, J., Hui, M. "LAN Interconnection via Frame Relaying" Proc. INFOCOM ' 89, Ottawa, pp. 686-690, apr. 1989.

[ 5]

Lamout, J., Hui, M.H. "Some Experience with LAN Interconnection via Frame Relaying" IEEE Network Magazine, pp. 21-24, vol. 3, no. 5, sep. 1989.

[6 ]

Japel, D., Port, E. "LAN/ISDN interconnect via frame relay" Proc. GWBECOM' 88, Hollywood, pp. 1791-1797, nov. 1988.

[7]

CCITT X.25: Interface between data terminal equipment (DTE) and data circuit terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated cicruit

[8 ]

CCITT Recommendation 1.122: Framework for providing additional Packet Mode Bearer Services, blue book version, Geneva 1989.

[9 ]

CCITT Recommendation Q.920 & Q.921: Digital subscriber Signalling System No.1 (DSS 1), data link layer, blue book version, Geneva 1989.

[ 10]

CCIIT Recommendation Q.930 & Q.931: Digital subscriber Signalling System No.1 (DSS 1), network layer, blue book version, Geneva 1989.

[ 11 ]

"DSS 1 - Signalling specification for Frame Mode Bearer Services" CCITT SG XI, studieperiode 1988 - 1992, Tempory Document 625-E, 1990

'36

Literatuurlijst

[ 12 ]

"Draft base text for reconunendation Q.92x (LAPD+)" ccrrr SG XI, studieperiode 1988 -1992, TempoI)' Document 21l-E, Mar. 1990.

[ 13]

ISO 7498: Open Systems Interconnection - Basic reference model

[ 14 ]

ISO/DIS 8072: Open Systems Interconnection - Transpon service definition, Nov. 1983.

[ 15]

ISO 8072/DAD 1: Open Systems Interconnection - Transpon service definition Ad 1: Connectionless-mode transmission, Aug. 1985.

[ 16 ]

ISO 8073: Open Systems Interconnection - Transpon protocol specification

[ 17 ]

ISO 8348: Data communications - Network service definition, Addendum 2: Network layer addressing, 1987.

[ 18]

ISO 8473: Data communications-Protocolforproviding the connectionless-mode network sen/ice, First edition, dec. 1988.

[ 19]

ISO 8802-2.2/DIS: Local Area Networks - Pan 2: Logical Link Control, 1987.

[20]

ISO 8802-2/DAD 1: Local Area Networks - Pan 2: Logical Link Control Addendum 1: Flow control techniquesfor bridged local area networks, 1988.

[ 21 ]

ISO 8802-2/DAD 2: Local Area Networks - Pan 2: Logical Link Control Addendum 2: Acknowledged connectionless-mode service and protocol, Type 3 Operation, 1989.

[ 22]

ISO/DIS 8878: Data communications - Use ofX.25 to provide the OSI connection-mode network service

[ 23 ]

ISO/DIS 8880-1: Protocol combinations to provide and suppon teh OSI network service - Pan 1: General principles, 1987.

[ 24 ]

ISO/DIS 8880-3: Protocol combinations to provide and suppon teh OSI network service - Part 3: Provision and suppon of the connectionless-mode network service, 1987.

[25]

ISO/DIS 8881.3: Data communications - Use of the X.25 packet level protocol in local area networks

[26]

ISO/SC6/WG1 N5620 (ISO DP 10028.2): Data communications - Definition of the relaying functions of a Network layer intermediate system, 1989.

[ 27 ]

ISO/SC6/WG 1 N5248 (ISO/I'R 1(029): Data communications - Operation ofan X.25 interworking unit, Dec. 1988.

[ 28 ]

ISO/SC6/WG1 N5234 (ISO/IEC DP 1(038): Local area networks - MAC Service Definition, 1989.

[ 29 ]

ISO/SC6/WG 1N5239 (ISO/IEC DP 1(039): Local area networks - MAC sublayer interconnection (MAC bridging), 1988.

Literatuurlijst

137

[30]

ISO/SC6/WGI N5471 (ISO PDTR 10172): Data communications - Network/Transport protocol interworking specification (PDTR type 2), Aug. 1989.

[31 ]

ISO/SC6/WG2 N302: Intermediate-system support of the OSI connection-mode network sen/ice using ISO 8208 in accordance with ISO DP 10028, Apri11989.

[ 32 ]

ISO/SC6 N5098: Contribution on the Proposed Network/Transport Layer Protocol Interworking Project, July 1988.

[ 33 ]

ISO/SC6/WG2 N5252: Network/Transport protocol interworldng specification

[34]

ISO/SC6 N3030 (ISO 8802.1): Local and metropolitan area network standard, Draft IEEE standard 802.1 (parr A), Overview and architecture, June 1983.

[35]

Kommer, J., Kerkhof, AJJ., de la Court, A.W. Adressering bij netwerkkoppelingen Verslag 27 RNL/89

[ 36]

Halderen, AJ.F. van LAN-WAN koppeling: Interworking tussen OSI Connection Oriented en OSI Connectionless netwerken met de ISO-IFU Intern Rapport 842 RNL/89

[ 37 ]

Tanenbaum, A. Compute r N efYliorks Prentice-Hall International Editions

Afkortingen 139

Afkorting~e_n

AFI ATLR BC CC CCITT CES CL

CLNP CO CONP

CR C/R

CSMA/CD CSPDN DA DISC DL

DLCI DSAP DSP DT DQDB ER ES FCS FH

FMBS FS

HDLC I

Authority and Fonnat Identifier Active Transpon-Layer Relay Bearer Capability Connection Confinn Comite Consultatif Intemationale de Telegraphique et Telephonique Connection Endpoint Identifier Connection-Less Connection-Less Network Protocol Connection Oriented Connection Oriented Network Protocol Connection Request Conunand/Response Carrier Sense Multiple Access with Collision Detection Circuit Switched Public Data Network Destination MAC-address DIsConnect Data Link Data Link Connection Identifier Destination LLC-SAP address Domain Specific Pan DaTA Distributed Queue Dual Bus ERror End System Frame Check Sequence Frame Handler Frame Mode Bearer Service Fast Select High-level Data Link Control Infonnation

_

140 Afkortingen

ICI ID IDI IDU IEC IEEE IFU I/G IS ISDN ISO

IWU Kbit/s

LAN LAPD LLC LM M

MA MAC Mbit/s

N

NLR NS NSAP

o OSI

PABX PCI

PDU P/F PLP PSPDN PSTN

PTLR

PIT QOS

RNL

Interface Controllnfonnation IDentifier Initial Domain Identifier Interface Data Unit Internation Electrotechnical Commision Institute of Electrical and Electronic Engineers Interworking Functional Unit IndlviduaUCJroup International Standard Integrated Services Digital Network International Standards Organisation Inter-Working Unit Kilo-bits per seconde Local Area Network Link Access Procedure on the D-channel Logical Link Control & Low Layer Compatibility Layer Management Mandatory Medium Access Medium Access Control Mega-bits per seconde Network Network Layer Relay Network Service Network Service Access Point Optional Open Systems Interconnection Private Automatic Branch eXchange Protocol Controllnfonnation Protocol Data Unit Poll/Final Packet Level Protocol Packet Switched Public Data Network Public Switched Telephone Network Passive Transport-Layer Relay Post Telefoon Telegraaf Quality Of Service Research Neher Laboratorium

Afkortingen 141

S

SA SABME SAP SAPI SC SDU SN SNACP SNDCF SNDCP SNICF SNICP SNA SSAP T TC

TCOP TCLP TEl TR

TSAP TUE U

UI VC

WAN XID

Supervisory Source MAC-address Set Asynchronous Balanced Mode Extended Service Access Point Service Access Point Identifier Study Comminee Service Data Unit Sub Network Sub-Network ACcess Protocol Sub-Network Dependent Convergende Function Sub-Network Dependent Convergence Protocol Sub-Network Independent Convergence Function Sub-Network Independent Convergence Protocol Systems Network Architecture Source LLC-SAP address Transpon Teclmical Comminee Transpon Connection-Oriented Pan Transpon Connection-Less Pan Terminal Equipment Identifier Teclmical Repon Transpon Service Access Point Technische Universiteit Eindhoven Unnumbered Unnumbered Information Virtual Call & Virtual Circuit Wide Area Network eXchange IDentification

De ISO COICL "IFU~

Appendix A

143

De ISO CO/CL "IFU,,1

In deze appendix voIgt een verhandeling over een binnen ISO voorgestelde oplossing voor het CO/CL-interworkingsprobleem. Deze is ontstaan door het samenvoegen van een aantal voorgaande voorstellen, waardoor een universele oplossing verkregen is voor verschillende CO/CL-interworkingsproblemen. Bij interconnectie van een netwerk dat werkt volgens het Connection-mode Network Protocol ISO 8208/8878 (X.25) en een net dat het Connectionless-mode Netwerk Protocol ISO 8473 ondersteund, wordt een zogenaamde Interworking Functional Unit (IFU) ingezet die zorgt voor relayering en/ofconversie van PDU' s (die door de Eind-systemen naar elkaar worden gezonden). Aangezien het CO/CL-interworkingsprobleem zich manifesteert binnen de netwerklaag dient een oplossing zich bij voorkeur te beperken tot die laag, het gebruik van de transportlaag binnen de IFU kan echter niet altijd worden vermeden.

CL-omgeving

CO-omgeving

1 •

• A ".

2

-j----\

. ...

IFU

NSAP'l

Figuur A. 1: Fysieke plaats van een IFU in CO- en CL-omgeving

1

Naar ISO publicatie N5471 (POTR 10172) van werkgroep: JTC 1.06.53, getiteld: "Infonnation Processings Systems - Data Communications - Network/I'ransport Protocol Interwotking Specification (POTR Type 2)"

144 De ISO COICL "IFU ..1

Appendix A

Bij het oplossen van het CO/CL Interworking probleem wordt door ISO met de onderstaande voorwaarden rekening gehouden. A. Het toepassen van zo 'n IFU mag niet leiden tot wijzigingen in de bestaande eind-systemen of gebruikte protocollen. De werking ervan moet dus transparant zijn voor eind-systemen; en B. de oplossing moet zo universeel mogelijk zijn, waardoor interconnectie van een groot aantal systemen mogelijk is.

A.1 IFU werkingsmodi De in dit hoofdstuk beschreven ISO IFU (Interworking Functional Unit)2 kent drie verschillende werkingsmodi: 1. Netwerklaag relay mode (NLR).

2. Passieve transportlaag relay mode (PTLR). 3. Aktieve transportlaag relay mode (ATLR).

A.1.1 Aktieve Transport Laag Relay (ATLR) Deze werkingsmode biedt een end-to-end transportservice aan twee eind-systemen, door met ieder een aparte transport connection te onderhouden, waarbij de lFU zorgt voor het relayeren van de data tussen die connecties. Deze twee connecties kunnen geheel onafhankelijk zijn van elkaar, en kunnen zelfs gebruik maken van verschillende transport protocol klassen en parameters. De noodzaak hiervan is reeds in vorige hoofdstukken aan de orde gekomen. De lFU zal, voor zover mogelijk, de TDPU's op een end-to-end basis overdragen, en daannee een enkele transportconnectie tussen de twee eind-systemen simuleren. Daarnaast zorgt de Aktieve Transport Laag Relay voor conversie tussen de verschillende transportklassen die op de fysieke transportconnecties in gebruik zijn.

A.1.2 Passieve Transport Laag Relay (PTLR) In deze werkingsmode worden door de lFU TPDU's die ontvangen zijn in NSDU's afkornstig van de eind-systemen, transparant aan het andere eind-systeem doorgegeven. De IFU zorgt aan de hand van bepaalde parameters (uit de header) in die TPDU's voor een 2

OPM.: Een gedeelte van deze oplossing ligt Diet binnen de OSI-arcbiteetuur, de relay.functie is eigenlijk voorbebouden aan de netweIk-laag.

Appendix A

De ISO COICL "IFU"' 145

juiste mapping van Transport-connecties op de Netwerk-connecties. Op aIle fysieke Transport-connecties moet bij gebruik van de PTLR-mode hetzelfde transportprotocol (inclusief de zelfde transponklasse) toegepast worden.

A.1.3 Network Layer Relay (NLR) De IFU functioneert in deze werkingsmode als een nonnaal intennediate system (volgens ISO DP 10028) door het ondersteunen van het ISO 8473 CLNP als een zogenaamd SNICP (= Subnetwork independant convergence protocol). Op dezelfde wijze kan het ISO 8208 CONS protocol ondersteund worden, volgens ISO TR 10029. In feite kan men dus het NLR nog verder onderverdelen in 2 verschillende werkingsmodi, namenlijk als netwerk relay voor CONS en voor CLNS.

A.2 De IFU in de 051 Netwerk omg'--ev_i_n.-..9

_

A.2.1 Adressering: NSAP· en TSAP adressen Hoewel de IFU in de meeste gevallen als een transport "relay" fungeert (behalve in de NLR-mode), "zien" de eind-systemen in alle gevallen echter direct hun opponent, en geen IFU. Dit heeft onder andere tot gevolg dat de IFU zelf geen (echte) NSAP- en TSAP adressen heeft. Binnen een IFU wordt het complete (incompatibele) netwerk, inclusief eind-systemen, (waarmee men wenst te communiceren) gesimuleerd.Hierdoor lijkt het voor een eind-systeem in netwerk A alsof de NSAP- en TSAP-adressen van de eind-systemen van netwerk B zich in de IFU bevinden. Zie de volgende twee figuren.

IFlJ

Virtueel EM.-system d4t CJ.,.omgrviflg simuJurt

Figuur A.2: CL-omgeving wordt gesimuleerd binnen de IFU

Andersom gebeurt natuurlijk hetzelfde, zie figuur A.3.

146 De ISO COICL "IFU"1

Appendix A

Cwmgevillg

IFU

VirtuuJ End-sys/~m dol CO-omgevillg simuJurl

Figuur A,3: IFU die de CO-omgeving simuleert

A.2.2 Selectie van de werkingsmode De lFU selecteert automatisch de juiste werkingsmode op basis van "eigen kennis" over, en/of de reacties/berichten van de eind-systemen die verbonden zijn met de subnetwerken. Afhankelijk van de reacties van de betrokken eind-systemen vindt een juiste selectie plaats, waarbij de IFU de grootste voorkeur heeft voor "normale" Netwerk relay-mode, zodat de ATLR-mode slechts in het uiterste geval gekozen wordt (indien transpon klasse conversie nodig is). Zie voor meer informatie bIz. 160 env.

A.2.3 Het gebruik van Netwerk adressen Het adresseren van een eind-systeem in bijvoorbeeld een CL-omgeving door een eindsysteem in een CO-omgeving via de IFU vindt op de zelfde wijze plaats als in situaties waarin er geen IFU zou zijn (zoals bij adressering binnen het eigen netwerk). Een lFU heeft immers geen "eigen" NSAP- en TSAP-adressen. Voor de IFU betekent dat bijvoorbeeld, dat deze in uitgaande NPDU's als source adres niet zijn eigen NSAP-adres invult (dat bestaat immers niet) zoals door de gebruikte protocollen is voorgeschreven, maar in plaats daarvan het source ad.res uit de te relayeren NPDU's ovemeemt. In de praktijk houdt dat in dat op een X,25 cormection als source adres in de door de IFU verzonden pakketten het destination adres dat in inkomende (CR-) X,25 pakketten zit, wordt ingevuld. Zie voor meer duidelijkheid figuur A.4 waarin onderscheid gemaakt wordt tussen het geval dat de CO-zijde het initiatief nam (A), of dat het initiatief van de CL-zijde afkomstig was (B).

Appendix A

De ISO CO/CL "IFu

CO (8208) djM

w1

147

CL(8473)rqdr

CR

(A)

(B) Figuur A.4: De verwerking van Netwerkadressen (Voorbeeld

A.3 Netwerk-configuratie en routering IFU's kunnen onder bepaalde randvoorwaarden ten aanzien van netwerk-configuratie en routering ook functioneren binnen grotere netwerk-agglomeraties (met meer dan 2 subnetwerken en meerdere IFU's). Dat is het onderwerp van deze paragraaf.

A.3.1 Adressering bij systemen met meerdere IFU's Het gebruik van twee of meer IFU's in serle is mogelijk indien er een globaal adresseringsschema in gebruik is. Hierdoor hoeven de NSAP-adressen in NPDU's niet gewijzigd te worden door de IFU's, deze blijven consistent tussen de eind-systemen. In situaties waarin er meerdere IFU's beschikbaar zijn voor het (parallel) verzorgen van een verbinding tussen twee eind-systemen is het noodzakelijk dat een transport-connectie (CO) gedurende zijn "life-time" slechts van een IFU gebruik maakt, en dus via een route loopt.

A.3.2 Data Unit Identifiers In alle gevallen waar meerdere lFU's (parallel) aanwezig zijn (die in principe dezelfde connecties zouden kunnen ondersteunen) is het noodzakelijk dat elke IFU een eigen, niet overlappend, nummer domein krijgt toegewezen waaruit ze Data Unit Identifiers kunnen kiezen. Deze Data Unit Identifiers worden in de NPDU-header (segmentation part) van bet CLNS protocol (ISO 8473) gebruikt voor het merken van de verschillende segmenten van een PDU. (Alle segmenten van een NPDU krijgen dezelfde Data Unit Identifier; de verschillende segmenten worden door middel van een Segment Offset van elkaar onderscheiden. Zie ISO 8473, paragraaf 7.4).

148 De ISO CO/CL "IFU~1

Appendix A

Door het toepassen van verschillende (niet-overlappende) nummerdomeinen voor de invulling van de Data Unit Identifier bereikt men dat NPDU's, behorende bij verschillende transportconnecties tussen het zelfde paar netwerk-adressen, van elkaar onderscheiden kunnen worden.

A.3.3 Transport references Een zelfde beperking geldt voor het toewijzen van transport references: DST-REF, SRC-REF (deze zijn in gebruik voor het identificeren van verschillende transportconnecties door de transportlaag-entiteiten in eind-systemen). Dit voorkomt de mogelijkheid dat er aan meerdere transportconnecties tussen een paar eind-systemen dezelfde transport references worden toegewezen. Het gebruik van verschillende routes voor verschillende transport-connecties tussen een paar eind-systemen is uiteraard weI toegestaan.

A.3.4 Voorkeur voor de te gebruiken IFU In het algemeen kan gesteld worden dat, omdat routering een taak is van de Netwerk-laag en deze geen direct zicht heeft op de duur van een transponconnectie, een gebruikte route (en daannee de gebruikte IFU) tijdens de duur van een verbinding niet gewijzigd moet worden (behalve natuurlijk indien er zich problemen voordoen binnen de gebruikte route en/ofIFU). Door het instellen van een absolute volgorde van voorkeur kan men het gebruik van een bepaalde IFU forceren. Omdat er anders een reele kans is dat TDPU's die behoren bij een transponconnectie binnen het CL-netwerk naar verschillende IFU's gerouteerd worden. Dat mag niet gebeuren omdat aan de CONS-zijde de netwerkconnectie, en daannee de bijbehorende transponconnectie, gedurende zijn "levensduur" verbonden is met een lFU. 3 Het zal duidelijk zijn dat deze routerings-eisen niet aIleen een zaak zijn van de IFU' s, maar van de gehele omgeving waarin zich de IFU's en de eind-systemen zich bevinden. In het algemene geval met een aantaI IFU' sen afwijkende "routing-domains" is het voldoen aan de hierboven beschreven eisen een vrij complexe zaak. Ben oplossing hiervoor lijkt het opzetten van een statisch routeringsschema, waardoor er slechts ~n pad is tussen twee eind-systemen. Dit maakt het routeren eenvoudig, maar heeft belangrijke nadelen: Het netwerk wordt op deze wijze immers vrij star, en de eerder genoemde problemen (het op de juiste wijze routeren van bij elkaar horende PDU 's via ~n route) wordt verschoven naar degene die het eerder genoemde schema gaat opstellen. In de praktijk kunnen de routingsproblemen beperkt worden aan de hand van de gewenste QOS (Quality of Service) die gewenst is voor een bepaalde connection. Het voldoen

3

Indien, wafs in de referentie-configuratie, er twee IFU's (in serle) toegepast worden voor bet koppelen van twee LAN's via een WAN is bovenstaande routeringseis Diet van toepassing omdat er dan automatiscb steeds van dezelfde IFU's gebruik gemaakt wordt.

De ISO COICL "IFU..1

Appendix A

149

daaraan sluit een aantal routeringsmogelijkheden uit (narnenlijk die routes die de gewenste QOS niet kunnen bieden); de keuze tussen routes wordt hierdoor dus kleiner, en daannee ook eenvoudiger.

A.4 Ak'lieve Transport

Laag~R-=-e:......:.l..=.::.ay~

_

De Aktieve Transpon Laag Relay (ATLR) is in hoge mate gebaseerd op bestaande intemationale standaards, waamaar dan ook veelvuldig zal worden verwezen. In hoofdzaak zal de beschrijving bestaan uit aanbevolen aanpassingen/wijzigingen van de gebruikte protocollen voor toepassing binnen een IFU.

A.4.1 De opbouw van de ATLR A 1508073 lraft/lf>Or1I
0·" 1508208 COOP

• •

TPOV.

_ _ .4

>,If

I

•

..

B

~ ~ ISO 8073

IuncfN

1508208 CONP

SO 80731 A02

1508473 CLNP

•

1501073IA02 lr.".orfllJu....

.

•

1508473 CLNP

,~.

D•• Link

D•• Link

AfIIanI<.I;;* van

AIhan*.I;;* van

tiubMtwer*.Iyp.

tiubM_,*.Iyp.

"""ical

"",.ir.1

Es

_.

• T""",

IFU

ES

Figuur A.S: Protocol-stack van ATLR en omgeving

De Aktieve Transpon Laag Relay is opgebouwd uit de volgende onderdelen: Transpon Connection-Oriented Part (TCOP): ISO 8073 Transpon Connectionless Part (TCLP): ISO 8073/AD2 Network X.25 Part: ISO 8208/8878 Netwerk conneetionless part: ISO 8473 Transpon Relay Part: koppeling van ISO 8073 Transpon conneeties naar ISO 8073/AD2 connecties.


Appendix A

A.4.2 Functies binnen de IFU-netwerklaag Functies van het Netwerk X.25 deel (ISO 8208) Dit deel voen het ISO 8208/X.25 PLP uit, confonn de bepalingen in ISO 8878 (CONS m.b.v X.25). Slechts het gebruik van Netwerk adressen is afwijkend, dit dient te gebeuren op de wijze zoals eerder is aangegeven (zie paragraaf A.2.3). Er worden hier geen beperkingen opgelegd ten aanzien van het gebruik van aanvullende procedures in specifieke situaties mits ze samen kunnen werken met ISO 8878. Bijvoorbeeld: ISO 8881: Het gebruik van het X.25 PLP in Local Area Networks (LAN's) ISO 9574: Het verzorgen van de OSI-CONS door ISDN-packetmode tenninals.

Functies van het Netwerk CL Part (ISO 8473) Verpllehte funetles

Het Netwerk Connectionless gedeelte dient als eind-systeem te fungeren volgens het ISO 8473 protocol. Ook hier geldt de opmerking over het gebruik van netwerkadressen; zie hierboven. Optionele Intermediate System (IS) funetie

De IFU fungeen in de Netwerk Relay mode als Intennediate System indien beide eind-systemen ISO 8473 (kunnen) ondersteunen als SNICP. Deze werkingsmode is vergelijkbaar met de in hoofdstuk 2 gepresenteerde methode 3.

A.4.3 Functies binnen de IFU-transporllaag Functles van het Transport Connection Oriented Part Hieronder volgen een aantal bepalingen ten aanzien van functies die binnen de transponlaag van een lFU aanwezig moeten zijn, als aanvulling op hetgeen normaal in de gebruikte transponprotocollen aanwezig is. Verpllehte lunettes

Het TCOP client te werken volgens ISO 8073 (Connection mode transport protocol) behoudens enkele modificaties zoals het gebruik van netwerk adressen (zie het voorgaande), QOS behandeling, additionele Release functies en de invulling van TSAP-ID waarden (deze 3 modificaties worden in paragraaf A.3.2 besproken; ze zijn ook van toepassing op hetTCLP).

Appendix A

De ISO COICL "IFU'"

151

Het transport relay gedeelte is de gebruiker van de service die door het TCOP wordt geleverd. Deze service is gespecificeerd in ISO 8072, uiteraard zijn hierop ook de hierboven genoemde modificaties van toepassing. Het TCOP kan zodanig opgezet worden dat het voor elk NSAP(-adres) (als "calling"-adres voor uitgaande connecties, en als "called"-adres voor inkomende) dat gesimuleerd wordt aan de CO-zijde, een aparte transport-entiteit creeert. Het voordeel daarvan is dat voor elke transportconnectie dan automatisch een andere set transport protocol reference nummers beschikbaar is. Aanbevellng voor het gebrulk van Class 4 Ackn. time

Als het ISO 8073 gedeelte het Transport Klasse 4 protocol uitvoert moet de acknowledge parameter gebruikt worden op de wijze zoals beschreven is in paragraaf A.3.5.

Modificaties Hieronder voIgt de beschrijving van de reeds eerder genoemde modificaties ten aanzien van de uitvoering van de transponprotocollen binnen een IFU. Aanpasslng van de QOS verwerklnglreallserlng

In de transport laag moet uit binnenkomende CR- en CC-TPDU's (CR= Connection Request), en CC= Connection Confmn) gegevens betreffende RER (Residual Error Rate) en transit-delay parameters gehaald worden (indien aanwezig; deze parameters zijn bij TPO niet aanwezig). Deze parameters (ofhet ontbreken ervan) worden dan vervolgens doorgegeven aan de Transport Relay in de IFU via resp. T-CONNECT-indication of T-CONNECT-Confirm primitieven (als aanvulling op de normale parameters van deze primitieyen).

De Relay zelf zal deze parameters (of het ontbreken ervan) doorgeven aan het andere transport-laag protocol gedeelte in de vorm van een T-CONNECTRequest ofT-CONNECT Response. Het betreffende protocol gedeelte zal deze parameters vervolgens onderbrengen in de te verzenden CR- of CC- TPDU's (behalve bij gebruik van transport classe 0, zoals eerder is opgemerkt). Nadere studie zal moeten uitwijzen hoe de QOS parameters in de CR- en CC-TPDU's verder moeten worden verwerkt binnen de transportlaag (van een IFU). Eigenlijk zou de IFU de eerder genoemde QOS-parameters zodanig moeten bewerken dat de effecten erop door de IFU automatisch in de onderhandelingen worden betrokken.


Appendix A

Aanvulllng op de standaard release·functle

Doel van de aanvulling is om ervoor te zorgen dat de "Reason" parameter in T-DISCONNECT indication zijn zogenaamde end-to-end betekenis behoudt, ondanks het feit dat er een IFU "tussen" zit. Gespecificeerd is (in ISO 8072) dat een T-DISCONNECT indication een reason-code bevat die aangeeft of het verbreken is veroorzaakt door de Transport Service gebruiker aan de 4 andere zijde van de verbinding of door de service verlener zelf. Een T-DISCONNECTrequestkan vergezeld worden door een reason parameter, afkomstig van het Transport Relay Part in de IFU 5• Het verzoek tot verbreken, en daannee de inhoud van de reason parameter, kan afkomstig zijn van een service- gebruiker, of van een onderdeel van het uitvoerende gedeelte. Verder kan de reason parameter een zogenaamd permanent of transient karakter hebben. Een T-DISCONNECf request dat afkomstig is van een service gebruiker dient op normale wijze (dus volgens ISO 8073 en ISO 8073/AD2) te worden afgehandeld. Indien het verzoek echter afkomstig is van de service verlener zelf (de IFU) dan dient er in de invulling van de reason parameter in de DR-TPDU een wijziging te worden aangebracht: de gebruikelijk waarde 128+0 (Normal disconnect initiated by the session entity) dient niet gebruikt te worden. In plaats daarvan kan de waarde 2 (met als betekenis: Session entity not attached to TSAP, "pennanent") of 0 (Reason not specified, "transient) gebruikt worden. Daamaast kan er een meer infonnatievere waarde gegeven worden, mits met behoud van de permanent/transient betekenis, gekozen uit de in ISO 8073 en ISO 8073/AD2 toegestane reeks. Het bepalen van de desbetreffende waarde kan geschieden op basis van interne samenwerking met, ofkennis van de andere onderdelen binnen de IFU. Het gebruik van TSAP·ID waarden

Een van de velden in een CR-TPDU is het zogenaamde "variable part". Hierin kunnen een aantal parameters worden ondergebracht, zoals de TSAP-ID (Transport Service Access Point Identifier). Deze is onderverdeeld in o.a. een Parameter code, die aangeeft ofer sprake is van een TSAP welke een oproep plaatst of ontvangt, en een Parameter value die het desbetreffende TSAP identificeert. V oor een bepaald eind-systeern (A) dat een transport-connectie wi! onderhouden met een ander eind-systeern (B), via een IFU, lijkt het alsof het transport-adres van dit andere eind-systeem in de IFU is gesitueerd (en ook andersom; dus het transport-adres van A lijkt vanuit B gezien in de IFU te liggen). In feite tracht de IFU de tegenpartij te sirnuleren door

4

5

Zelfs zonder tussenkomst van een IFU is er bij gebroik van TP 0 geen mogelijkbeid om te bepalen wie de verbinding verbreekt, mits deze gebeel tot stand gekomen was. Bij een fout tijdens bet opbouwen is dit we) altijd mogelijk. De T-DISCONNECI' primitieve bevat geen ruimte voor een reason parameter; deze zal dus op een andere wijze de TCOP ofTCLP moeten bereiken. De wijze waarop dit zou kunne plaatsvinden wordt Diet gespecificeerd.

Appendix A

De ISO COICL "IFU~

153

berichten aan dat gesimuleerde eind-systeem te ontvangen en, na eventuele transportklasse conversie, naar het "echte" eind-systeem door te sturen. Het zal dus duidelijk zijn dat de eerder genoemde Parameter Value (onderdeel van het TSAP-ID) in de pakketten die de IFU verzendt naar de gewenste bestemming een andere invulling dient te krijgen dan normaal gebruikelijk is. Volgens ISO 8073 zou een IFU de Parameter value met zijn eigen TSAP-adres moeten vullen. Aangezien de IFU een end-to-end cOlUlectie tussen de twee betrokken eind-systemen tracht te realiseren/simuleren dienen er dus geen adressen van de IFU in de uitgewisseIde PDU's voor te komen, maar uitsluitend TSAP-adressen van de eind-systemen. Een IFU dient in de te relayeren CR-TPDU 's de TSAP-ID parameters ongewijzigd te laten. Dus een CR-TPDU dat van eind-systeem A via de IFU naar B wordt gestuurd heeft zowel op het traject van A naar de IFU als van de IFU naar B dezelfde TSAP-ID's. Hiermee wordt bereikt dat de eind-systemen de transportlaag in de IFU niet "zien", en daarmee blijft dus het end-to-end karakter van de Transport cOlUlectie tussen A en B behouden.

Functies van het Transport Connection less Part (TCLP) Het TCLP moet functioneren volgens ISO 8073/AD2 (Connection mode transport protocol voor gebruik op een CLNS) behoudens enkele modificaties zoals het gebruik van netwerk adressen (zie paragraaf A.2.3), QOS behandeling, additionele Release functies en de invulling van TSAP-ID waarden (deze 3 modificaties werden in paragraaf A.3.2 reeds besproken). Het transport relay gedeelte is de gebruiker van de service die door het TCLP wordt geleverd. Deze service is gespecificeerd in ISO 8072, uiteraard zijn hierop ook de hierboven genoemde modificaties van toepassing. Het TCLP kan zodanig opgezet worden dat het voor elk NSAP(-adres) (als "source"-adres bij het gegeven van een N-UNITDATA request prirnitieve, of als "destination"-adres voor een ontvangen N-UNITDATA indication) dat gesimuleerd wordt aan de CL-zijde, een apane transport-entiteit creeert. Het voordeel daarvan is dat voor elke transportconnectie dan een andere set transport protocol reference numrners beschikbaar is.

Uitvoering van de Transport Connectie mapping Het Transport Relay Pan, dat zich tussen het TCOP en TCLP bevindt, heeft uitsluitend een koppelingsfunctie, zodanig dat indications en confirmations vanuit het TCOP gedeelte "gemapt" worden op resp. requests en responses aan de TCLP zijde, en andersom. Ben gevolg hiervan is dat de Relay niet als een afzonderlijke operatie beschouwd hoeft te worden (in de zin van "echte" bewerlcingen, met risico van het veroorzaken van errors of delays), waardoor aile eisen betreffende QOS volledig bij het TCOP en TCLP terecht komen. Connectle opbouw vsnult CL-omgevlng

Ben CR-TPDU dat de IFU binnenkomt via de TCLP wordt als een T-CONNECT indication primitieve afgeleverd bij bet Transport Relay (afhankelijk van het feit of de oproep geaccepteerd kan worden, mede met bet oog op mogelijkheid of de gewenste QOS geboden

154 De ISO COICL uIFu w1

Appendix A

kan worden). Deze zal dit vervolgens mappen op een corresponderend T-CONNECT request primitieve naar het TCOP, met behoud van alle parameters uit de indication. Nadat de connectie die het TCOP vervolgens met het eind-systeem aan de CO-zijde tracht te bewerkstelligen is gerealiseerd, geeft het TCOP de T-CONNECT confirm primitieve af aan het Transport Relay Part, die dit vervolgens mapt op een corresponderend T-CONNECT response naar het TCLP (met alle parameters gelijk aan die van het confmn). Zie figuur A.6. 4L-(CR-TP@

4'

@:rP~

-"

T.CONNECT

Teop

Transport·Relay

••

-------~'"

-

T-CoC)NrlI!CT • .........n .. ·

T.OOfM,CT _

TeLP

.4'--(

CR·TPDU

l

... ~ C£CFi5UY-+

Figuur A.S: Mapping van Transport-connectie binnen IFU

Connectle opbouw vanult CO-omgevlng

Het opzenen van een connectie vanuit een eind-systeem in een CO-omgeving vindt op dezelfde wijze plaats, zie de vorige paragraaf. Data-ultwlssellng

Vervolgens kan de uitwisseling van data aanvangen. Het Transport Relay Part ontvangt dan T-DATA- of T-EXPEDITED DATA- indications van het TCOP (bijvoorbeeld) en geeft de hierin ondergebrachte data in de vonn van T-DATA of T-EXPEDITED DATA requests door aan het TCLP (en andersom). Indien het Transport Relay een indication in meerdere afzonderlijke TPDU's ontvangt, dan mogen deze afzonderlijke delen reeds verwerlet en doorgegeven worden, voordat het volledige indication primitieve ontvangen is. Het verbreken van een connectle

Ben door de Transport Relay Pan ontvangen T-DISCONNECT indication (vanuit het TCOP ofTCLP) wordt gemapt op een T-DISCONNECTrequest welke is gericht aan het andere transport part. De eventuele in de TPDU te verzenden reason-code dient op de wijze behandeld te worden zoals in een van de vorige paragrafen is beschreven.

De ISO COICL "IFU~

Appendix A

155

TensIone: de in de T-DISCONNECTindication aanwezige User Data dient exact gecopieerd te worden in bet zelfde veld in de T-DISCONNECT request.

Aanbeveling voor Acknowledge Time in TP4 Er wordt aanbevoIen om de grootst mogelijke waarde in te vullen voor de Acknowledge time parameter in bet variable part van CR- en CC-TPDU's, zodat nabet tot standkomen van de connectie de grootste mogelijke "Acknowledgement time" wordt gebruikt. Dit is nodig om de IFU de mogelijkheid te bieden een interactie aan te gaan met een eind-systeem, terwijl bet ander eind-systeem wacbt op een bepaalde respons. Indien in bet vervolg van een connectie geen interactie meer nodig is met bet bestemmingsend-systeem voor bet geven van een acknowledge aan bet "bron"-end-systeem (de IFU kan bijvoorbeeld op basis van kennis over de twee connecties reeds bij voorbaat een acknowledge terugzenden) lrunnen de overeengekomen waarden voor de acknowlegdetime aangepast worden.

Afmetingen van de TPDU's etc. Aangezien een IFU werkt op de grens van twee netwerken, met wellicbt zeer verschillende architectuur, is niet ondenkbaar dat er grote verschillen zijn in data-snelheid en afmetingen van de data units tussen de twee netwerken. De IFU zal moeten zorgen voor de nodige conversie daartussen.

A.5 Passieve Transp_o_rt_L_a_a--3lllg~R_e_l_a.&-y

_

Het doel van de PTLR is bet relayeren van TPDU's ontvangen van een CO-end-systeem naar een CL-end-systeem (en omgekeerd) zonder een al te grote ingreep (van de IFU) in de werking van bet gebruikte transport protocol(len). Hiervoor is bet noodzakelijk dat beide eind-systemen gebruik maken van TP4 (omdat de CL-zijde aIleen deze Transport klasse wi! ondersteunen). In sommige gevaIlen zal bet ecbter tocb noodzakelijk blijken om enige modificaties aan te brengen in de te relayeren TPDU's: daarover verderop in dit boofdstuk meer.

A.5.1 De opbouw van de PTLR Het Passieve Transport Laag Relay is opgebouwd uit de volgende onderdelen: Network X.25 Part: ISO 8208/8878 Network connectionless part: ISO 8473 Transport Relay Part: relayering van TPDU's op ISO 8073 Transport connections naar ISO 8073/AD2 connections (en omgekeerd).

156 De ISO COICL "IFu w1

Appendix A

A 1501iJ7'3

..aNpCltII
B

.-........

4---...__ _ _ _ _ _

rW. ---- ...

m>v•

4 1S0420~

COOP

•

..,.,., •

ISO 1120~

150847'3

COOP

C~P

.

-.T•

OM" UN

..."."et1I
OM" UN

AIft"'' ,k .i..bwiw.rl<.I)'p.

v"" ......'-I<.iyp. A/h...."k

v.."

"w"ictll

Es

0

1501iJ7'3IAD2

"w"ictll

IFU

ES

Figuur A.7; Protocol-stack van PTLR en omgeving

A.5.2 De netwerklaag van een PTLR Functies van het Netwerk X.25 deel (ISO 8208) Dit deel voert het ISO 8208/X.25 PLP uit, confonn de bepalingen in ISO 8878 (CONS). Behalve het gebruik van Netwerk adressen (dit dient te gebeuren op de wijze zoals eerder is aangegeven), QOS-processing en "Extended Lifetime processing" (deze twee items worden verderop besproken). Er worden geen beperkingen opgelegd ten aanzien van het gebruik van aanvullende procedures in specifieke situaties, mits ze sarnen kunnen werken met ISO 8878. Bijvoorbeeld: ISO 8881: Het gebruik van het X.25 PLP in Local Area Networks (LAN's) ISO 9574: Het verzorgen van de OSI-CONS door ISDN-packetrnode tenninals.

Functles van het Network Connectionless Part (ISO 8473) Verpllchte functles

Het Network Conneetionless gedeelte dient als eind-systeem te fungeren confonn de ISO 8473 protocol specificatie. Ook bier geldt de opmerking over het gebruik van netwerkadressen; zie § A.2.3. Verder geldt de bieronder te bespreken opmerking ten aanzien van de "Extended Lifetime Processing" Het Transport Relay is de gebruiker van de service die het Network Conneetionless Part biedt. Deze service is gedefinieerd in ISO 8473/ADI (Protocol voor Connectionless netwerkservice).

De ISO COICL "IFU..1

Appendix A

157

Enkele opmerkingen Hieronder enkele aanvullende opmerkingen. Gewljzlgde OOS onderhandellng

De wijze waarop over de QOS wordt onderhandeld in het Netwerk X.25 deel wijkt af van hetgeen in ISO 8878 is gespecificeerd voor eind-systemen. In ISO 8878 wordt gespecificeerd hoe de "transit delay" die veroorzaakt wordt door de Netwerk seIVice verlener, in gebruik is bij de onderhandelingen over de totale transit delay. In het geval van een IFU zou de transit delay van het NetwerkX.25 deel (= seIVice verlener) hieIVoor van belang zijn, echter de transit delay bij gebruik van een IFU in PTLR-mode is afhankelijk van meer faktoren, zodat in dit geval de som genomen moet worden van: Transit delay veroorzaakt door het Netwerk X.25 dee!. Transit delay veroorzaakt door het Transport Relay dee!. Transit delay veroorzaakt door de CL-mode transmissie die nodig is voor cornrnunicatie met het CL eind-systeem.

Extended Lifetime Processing

NPDU's, volgens ISO 8473 (dus in een CL-omgeving), bevatten een zogenaamde "lifetime" parameter. Een eind-systeem dat een PDU verzendt, bepaalt de initii:He inhoud van deze parameter. Elke netwerk entiteit waar het PDU, op weg naar zijn eindbestemming, passeert zal de waarde van de lifetime parameter venninderen met een getal gelijk: aan de transit delay van de transrnissieweg tussen deze entiteit en de vorige. Aan de hand van deze parameter kan een ontvangend eind-systeem (of eventueel ook een intermediate systeem) bepalen of de desbetreffende PDU nog geldig is, of dat het dient te worden "weggegooid". Dat laatste is het geval indien de genoemde parameter de waarde 0 heeft. De IFU maakt op zijn beun gebruik van de inhoud van de lifetime parameter in de ontvangen NPDU's om een maximale tijd te bepalen waarbinnen de erin opgesloten TPDU's moeten worden verzonden via de X.25 connectie. Indien deze tijd verstrijkt voordat er een complete TPDU geconstrueerd kon worden uit de ontvangen NPDU's wordt de betreffende TPDU niet verzonden maar weggegooid.

A.5.3 Het Transport Relay Part Het transport relay part van een passieve transport layer relay heeft als funetie het "koppelen" van twee transportconnecties.

158 De ISO CO/CL UIFU"1

Appendix A

Behandeling van X.25 connecties Binnenkomende X.25 connection requests.

Een N-CONNECT indication primitieve die binnenkomt vanuit het netwerk X.25 deel zal op de volgende wijze worden behandeld: indien het verzoek geaccepteerd kan worden6 zal de PTI..R zelfstandig een N-CONNECT response primitieve genereren waarin de geselecteerde QOS-parameters voor Throughput, priority en protection niet groter zijn dan de hoogste beschikbare waarden binnen het Transport Relay Part en op de transmissieweg naar de bestemming in de CL-omgeving. Zelf opzetten van X.25 connectIons

De PTLR zal zelf een X.25 connectie opzetten door het geven van een N-CONNECT request aan het Netwerk X.25 gedeelte, indien dat nodig is voor het overdragen van TPDU's naar een CO eind-systeem (de behandeling van de verschillende typen TPDU's door het transport relay voIgt in de volgende paragrafen). Als voorwaarde geldt daarbij dat alleen een X.25 connectie wordt opgezet indien: er nog geen X.25 connectie bestaat die gebruikt kan worden voor de gewenste Transport connectie, er een andere X.25 connectie nodig is voor het bieden van de gewenste QOS (die dus afwijkend is van een eventueel reeds bestaande X,25 verbinding).

Behandeling van NSDU's en TPDU's Verwerklng van NSDU's

Ontvangen NSDU's dienen door de PTI..R behandeld te worden volgens de in ISO 8073 gespecificeerde functies "separation" en "association ofTPDU's to transport connections". Daamaast moet er een controle plaats vinden op transmissiefouten aan de hand van de checksum parameter in de TPDU's. De ontvangen TPDU's moeten op de hieronder beschreven wijze worden behandeld. Verwerklng van CR-TPDU's

Een vanuit de CO-omgeving ontvangen CR-TPDU dat niet geassocieerd kan worden met een bestaande transport connectie zal door de PTLR via het Netwerk connectionless gedeelte worden doorgegeven aan het connectionless eind-systeem, na er de volgende modificaties in te hebben aangebracht.

6

NB.: Ben PTI..R kao bet verzoek Diet accepteren als de geweoste QOS Diet geboden kao worden door de P'I1..R zelf en de te gebroiken ttaosmissieweg in de CL-omgeving.

Appendix A

De ISO CO/CL "IFU..1

159

Indien noodzakelijk wordt de source reference (= identificatienummer van de op te zenen transponconnectie, welke is gekozen door het initierende eind-systeem aan CO-zijde) gewijzigd. Het is immers mogelijk, omdat de IFU aan beide zijden "onafhankelijke" transpon-eonnecties onderhoudt, dat de IFU aan de CL-zijde (waar het bestemmings eind-systeem zich bevindt) de gewenste source reference al in gebruik heeft. Om aan die CL-zijde toch onderscheid te kunnen maken tussen meerdere transponconnecties mag geen connectie dezelfde references gebruiken. Ook indien het niet strikt noodzakelijk is mag de lFU de source reference wijzigen. Indien de gewenste QOS (in de CR-TPDU) de mogelijkheden van de PTLR te boven gaan zal het transpon relay deze parameters aanpassen. Uiteraard zal de eventuele waarde voor checksum-parameter7 worden aangepast als het CR-TPDU inderdaad gewijzigd wordt. CR-TPDU's afkomstig van de CL-zijde zullen op dezelfde manier worden behandeld. Als de ontvangen CR-TPDU weI aan een reeds bestaande transpon connectie kan worden toegewezen, zal de IFU op die connectie een copy van de vorige CR-TPDU verzenden.1n het geval dat de betreffende connectie in de andere richting werd opgebouwd is er geen "vorige" CR-TPDU; dan relayeen de IFU de ontvangen CR-TPDU ongewijzigd. Verwerk/ng van

Cc- TPDU's

Van ontvangen (geldige) CC-TPDU's zal de TPLR de source- en destination references zodanig wijzigen dat ze op de juiste transponconnectie terecht komen. De verandering van deze parameters is noodzakelijk indien de PTLR eerder modificaties had aangebracht in de source reference van het corresponderende CR-TPDU.lndien noodzakelijk zal ook de checksum parameter worden aangepast. De overeengekomen QOS, zoals die in het CC-TPDU aanwezig is, wordt door de lFU aangewend voor het creeren van geschikte netwerk connections. Verwerlc/ng van de over/ge TPDU's

AIle andere TOPU's worden, na eventuele wijziging van de references (zoals bij het CC-TPDU), gerelayeerd. Ook bier indien noodzakelijk modificatie van de checksum parameter.

7

Alleen indien TP4 gewenst is bevat een CR-TPDU een checkslDfl.

160 De ISO COICL "IFU"'

Appendix A

A.6 Werkingsmode selectie In dit hoofdstuk voIgt een beschrijving van de wijze waarop een IFU zijn werkingsmode selecteert. Hierbij wordt onderscheid gemaakt tussen twee gevallen, namelijk de werkingsmode selectie na ontvangst van een NPDU dat afkomstig is van de CL-zijde en na ontvangst van een "Network connection request" vanuit de CO-zijde. Volgens de beschrijving (ISO/IEC PDTR 10172) is een IFU verplicht om minimaal de ATI..R-mode (Aktieve Transport Laag Relay) te ondersteunen. Daamaast is werking als Passieve Transport Laag Relay en/of als gewoon Netwerk laag relay gewenst. Feitelijk bestaan hierdoor 4 typen IFU's: 1.ATLR 2. ATLR+PTLR 3. ATLR+ NLR 4. ATLR + PTLR + NLR De selectie (bij IFU-type 2 tim 3) is zo opgezet dat altijd die mode uitgekozen zal worden welke interworking met zo min mogelijk IFU-functionaliteit kan realiseren.

A.6.1 Selectie, ontvangst van pakkeUen uit CL-zijde Het "algoritme" valt in twee delen uiteen, waarvan deel1 alleen uitgevoerd kan worden als de betreffende IFU een CLNS relayfunctie bevat.

Aanvankelijk zal een IFU uitzoeken of de gewone NLR-mode toereikend is. De procedure: Indien er een route beschikbaar is naar de gewenste bestemming, zonder wijziging van de geboden service, dan kan de IFU een "normale" CLNS relay funetie uitvoeren (volgens ISO 8880-4). Als er geen route beschikbaar is voor het gebruik van CLNS, maar er is weI een SNPA (Subnetwork Point of Attachment) bekend waarmee een X.25 connectie kan worden opgezet, dan zal de IFU proberen of

8

AIleen van toepassing op IFU's die een CLNS relayfunctie bevatten.

Appendix A

De ISO COICL "IFU"1

161

zo 'n verbinding geschikt is voor het relayeren van Data Units behorende bij een CLNS.

Oeel2

A1s deel 1 niet succesvol kan worden uitgevoerd (met als resultaat connectionless-mode relaying) dan wordt door de IFU deel 2 uitgevoerd. Indien er in de IFU een PTLR aanwezig is dan wordt deze waar mogelijk gebruikt, anders zal de ATLR-mode toegepast worden. De procedure: De IFU zal zich vanuit de CL-zijde "gezien" als een normale transponlaag entiteit gedragen, die TPDU's samenstelt uit de ontvangen NPDU 's. Vervolgens zullen die TPDU 's zoveel mogelijk aan bestaande transpon connecties worden toegewezen, en zo uiteraard naar hun bestemming (aan CO-zijde) worden doorgezonden. In het geval dat de betreffende transponconnectie niet TP4 ondersteund, zal de IFU voor die connectie van de ATLR-mode gebruik maken. Voor TPDU's die niet bestemd zijn voor een eind-systeem waannee reeds een transponconnectie bestaat geldt het volgende: De IFU zal nu een transponconnectie opzetten met het eind-systeem dat wordt aangegeven in de te verzenden TPDU. Bij aanvang daarvan bevindt de lFU zich in de ATLR-mode, het is immers bij voorbaat niet bekend welke Transpon klasse het aan te roepen eind-systeem kan/wil ondersteunen. Indien de transponconnectie tot stand is gekomen kan de IFU de relayering van Data Units voottzetten als een PTLR, mits er op de nieuwe transponconnectie van TP4 gebruik wordt gemaakt. Anders blijft de IFU zijn aktiviteiten voonzetten als ATLR (voor de zojuist tot stand gekomen transponconnectie).

A.6.2 Selectie, bij pakketten vanuit de CO-zijde Het onderstaande wordt uitgevoerd door een IFU die een verzoek tot het opzetten van een netwerk connectie ontvangt vanuit de CO-zijde. Evenals bij de werkingsmode selectie voor inkomende NPDU's (vanuit CL-zijde) valt het algorinne in 2 delen uiteen, waarvan het eerste deel alleen uitgevoerd kan worden door IFU met een CONS-relaying functie.

162 De ISO CO/CL "IFu w1

Appendix A

Deel1 AIleen van toepassing op IFU's die een CONS relay functie bevatten, de IFU tracht hier van die functie gebruik te maken. De procedure: Als er een route beschikbaar is naar de gewenste bestemming kan de IFU als gewoon netwerk relay fungeren (voor CO-omgeving), volgens ISO 8880/4. Indien er geen route beschikbaar is voor het gebruik van een CONS, maar er weI een SNPA bekend is waarmee een X.25 connectie kan worden opgezet, dan zal de IFU proberen of zo 'n verbinding geschikt is voor relayering van de Data Units welke behoren bij een CONS.

Deel2 Als in deell niet de gewenste koppeling tot stand gebracht kan worden zal vervolgens dee! 2 uitgevoerd worden (hierbij wordt bij voorkeur van de PTLR-mode gebruik gemaakt, mits deze aanwezig is in de betreffende IFU). De procedure: De IFU zal de binnenkomende netwerk connection request accepteren, en vervolgens een X.25 netwerk connectie met de CO-zijde opzetten en onderhouden. Uit de NSDU's op die connectie binnenkomen worden vervolgens TPDU' s sarnengesteld welke worden toegewezen aan de juiste transport connectie (volgens ISO 8073), hierbij is aangenomen dat die connectie dan reeds bestaat. Als dat niet zo is, is het volgende item van toepassing. NB.: afbankelijk van de gebruikte transportklasse zal de IFU als ATLR of PTLR fungeren (PTLR als aan de CO-zijde TP4 ondersteund wordt. Indien er een CR-TPDU binnenkomt via een zojuist gerealiseerde netwerk-connectie, dan zal er een transportconnectie gecreeerd worden. Afhankelijk van de gewenste transportklasse kan de IFU reeds bij het opzetten van die conneetie voor de PTLR- of ATLR-mode kiezen (PTLR aIleen als TP4 gewenst is). Ook is het mogelijk dat het opzetten van de transportconnectie in de ATLR-mode plaatsvindt, waarna er overgeschakeld kan worden indien blijkt dat TP4 in gebruik is.

Appendix A

De ISO CO/CL "IFU"'

163

A.7 Security In het huidige voorstel voor een "Network/Transpon Protocol Interworking Specification,,9 komt de opmerking over Security zoals die in voorgaande voorstellen was opgenomen niet meer voor. Aangezien de voor de beveiliging van getransponeerde data toegepaste encryptie gevolgen heeft voor de werking van een IFU voIgt hieronder een verhandeling gebaseerd op oudere publicaties (binnen dezelfde werkgroep) betreffende dit onderwerp. Voor sommige toepassingen van een transport-connectie lO is de bescherming (tegen "afluisteren" bijvoorbeeld) van de getransporteerde data van groot belang. Dit kan worden bereikt door het toepassen van encryptie op de TPDU's. Aangezien een transponconnectie een "end-to-end" karakter heeft geeft deze versleuteling van TPDU's normaal gesproken geen problemen omdat het transponerend netwerk de TPDU' s transparant doorgeeft. Bij toepassing van de in dit verslag beschreven IFU geeft encryptie van TPDU's echter weI problemen. De IFU zal tijdens de uitvoering van de PTLR- en ATLR-modi (en dus niet in de NLR-mode) gebruik willen maken van de transponadressen die zich in de (versleutelde) TPDU's bevinden; die zijn echter als gevolg van de encryptie niet toegankelijk.

A.7.1 Tatale encryptie van TPDU's Indien de TPDU's in zijn geheel "versleuteld" worden dient de gebruikte IFU in het bezit te zijn van de "sleutel", zodat deze de TPDU's kan verwerken (decryption en encryptie is voor verwerking noodzakelijk, O.a. in verband met adressering en het bepalen van de gewenste Quality Of Service). Het gevolg daarvan is dat de betrokken eind-systemen deze IFU moeten kunnen vertrouwen.

A.7.2 Gedeeltelijke encryptie van TPDU's Ben andere mogelijkheid is om slechts het data-gedeelte van de TPDU's te versleutelen, en de Protocol Control Information (pC!) onaangetast te laten. In dat geval zijn IFU's toch in staat om deze TPDU's te verwerken. (zonder kermis te hebben van de encryptie-sleutel, en dus ook niet van de inhoud van het datagedeelte van de TPDU's).

9 10

ISO/IEC PDTR 10172, reference number ISO/IEC JTC N5471 , workitem JTC 1.06.53 Bijvoorbeeld toepassingen waarbij vertrouwelijke gegevens overgedragen worden zoals PIN-codes, persoonsgegevens, etc.

Appendix B

Transport "Classes" 165

_____T_r_a_n.sport ... "Classes"

De transponservices die door de transponlaag worden verleend kan men onderverdelen in een aantal zogenaamde transpon-classes zoals die worden gespecificeerd in X.224 en ISO 8073: Class 0 tim Class 4 (ook weI TPO tim TP4 genoemd).

B.1 Class 0: "Simple Class" Biedt een eenvoudige transpon-service die alleen voorziet in functies die nodig zijn voor het opzetten van een connection (connection establishment) inclusief het onderhandelen over de te bieden quality of service (negotiation), datatranspon (eventueel met segmenting) en het melden van optredende protocol-errors. Bij dit alles wordt er vanuit gegaan dat de gebruikte netwerk-service foutloos functioneen; eventuele problemen in de onderste 3 lagen dienen dus binnen die lagen opgelost te worden op een wijze die onzichtbaar is voor de transponlaag. Aowcontrol op een Class 0 transponconnection vindt plaats door middel van door de netwerklaag geboden flowcontrol-service. Ook het verbreken van de verbinding vindt plaats aan de hand van netwerkservices.

B.2 Class 1: "Basic Error Recovery Class" Class 1 zorgt voor transponconnecties met flowcontrol (die gebaseerd zijn op door de netwerkservice verzorgde flowcontrol), foutcorrectie en expedited-data-overdracht. Het veIbreken van de transpon-connection (disconnection) wordt bij class 1 door de transponlaag zelfverzorgd. Verder bestaat er de mogelijkheid voor het ondersteunen van verschillende opeenvolgende transponconneetions op 6en netwerk connection. Wat betreft de !outcorrectie: het class 1 transportprotocol is in staat om zelfstandig een (reeds bestaande) transponconneetion te herstellen nadat er een foutsituatie is gesignaleerd vanuit de netwerklaag, zonder dat de gebruiker van deze connection daar iets van merkt. Na zo 'n gebeunenis worden beide transpon-entities met elkaar gesynchroniseerd en zullen ze verder gaan met hetgeen ze bezig waren tot het moment van de storing in de netwerkservice. Om bovenstaande mogelijk te maken zal er door de transpon-service gebruik gemaakt moeten worden van volgorde-nwnmers. Uiteraard heeft Class 1 de mogelijkheid tot segmenting. Samenvanend kan men stellen dat TPI een uitbreiding is op TPO.

166 Transport "Classes·

Appendix B

B.3 Class 2: "Multiplexing Class" Deze transport-service biedt zijn gebruikers transportconnections met- of zonder individuele flowcontrol. Er is hierbij niet voorzien in foutdetectie of foutcorrectie. Het Class 2 transport protocol is in staat om meerdere transportconnections te multiplexen over dezelfde netwerkconnection, hetgeen in bepaalde gevallen gunstig is. lodien er gebruik wordt gemaakt van de (optionele) individuele flowcontrol mogelijkheid dan kan een ontvanger de zender informeren over de hoeveelheid data welke hij wenst te ontvangen. Bovendien is dan spoed data-overdracht mogelijk (expedited data transfer). Een bestaande transportconnection wordt verbroken (zonder voorafgaande verbreekprocedure op laag 4) indien de gebruikte netwerk connection gereset, of verbroken wordt. De transportservice gebruiker wordt hierover dan uiteraard geinformeerd.

B.4 Class 3: "Error Recovery and MUltiplexing" Class 3 combineert de functies van Class 1 en Class 2 (met expliciet flow control)

8.5 Class 4: "Error Detection and Recovery Class" Biedt dezelfde functies als Class 3 plus een aantal extra's zodat ten alle tijde een betrouwbare transport connection verwacht kan worden. Er is dus voorzien in uitvoerige foutdetectie en -correctie. Het verlies, uit volgorde raken en het dubbel ontvangen van TPDU's wordt binnen de transportlaag gedetecteerd en gecorrigeerd zonder dat de gebruiker vande transportservice daar iets van merkt. Class 4 is in staat om wel- ofniet gesignaleerde netwerkfouten (zoals: reset, disconnect or inactivity) te detecteren en daarvan te herstellen door middel van timeout mechanismen. De detectie van fouten vindt plaats aan de hand volgorde nummering (zoals bij Class 2 en Class 3), timeout mechanismen en additionele procedures. Bovendien worden fouten in TPDU's gedetecteerd aan de hand van een Checkswn mechanisme. Uiteraard zorgt het protocol voor het herstellen van die fouten. Het gebruik van dit checksum-mechanisme is optioneel; en is dus onderwerp voor onderhandeling. Dit betekend niet dat de implementatie ervan optioneel is: het mechanisme dient weI altijd beschikbaar te zijn. Tenslotte biedt Class 4 de mogelijkheid om de zogenaamde "throughput" van de transportconnection te verhogen door gebruik te maken van meerdere netwerk connections. Samenvattend kan men stellen dat het class 4 transport protocol uiterst robuust en geavanceerd is. Het is de enige transport klasse die gebruikt kan worden in connectionless omgevingen

Transport "Classes· 167

Appendix B

8.6 Overzicht van TPO tIm TP4 Tensiotte voIgt hieronder in tabelvonn nog een overzicht van de diverse functies in de verschillende transport klassen Procedure Assignment to network conn. TPDU transfer Segmenting and reassembling Concatenating and seperation Connection Establishment Connection Refusal Normal Release Error Release Association of TPDUs with TCs Data TPDU Numbering Expedited Data Transfer Reassignment after failure Retention until ack. of TPDU's

Variant

implicit explicit

0

.. ..

.. .. .. .. . .

normal extended 1 net.norm net.exp.2

.. .. .. .. .. ..

. . . m ao

2

4

.. .. .. . .. .. m

m

m

.. . . . . . .

0

.

..

1) 01) .. 1)

ao m

conf.Rcpt

.

.. 2)

.

..

3

.. .. .. .. .. .. . .

..

.

AK Resynchronization Multiplexing and Demultiplexing Explicit Flow Control (with) Explicit Flow Control (Without) Checksum Frozen References Retransmission on Timeout Resequencing Inactivity Control Treatment of Protocol Errors Splitting and Recombination

1

. .

m

..

.

0

.. .. .. .. .. .. ..

. .

. . 3) . .

3)

0

. .

"/0

. . . . .. ..

•• Deze procedure is van toepassing m: OoderllaDdelingsprocedure. status: verplicht 0: Ooderbandelingsprocedure. status: optioneeI 80: OoderllaDdelingsprocedure (gebruik afh. van netwerksevice). status: optioneel 1): Niet van toepassing op Qass 2 indien explicietflawcontrol Diet woldt gebruikt 2): Multiplexing tan lijden tot verslechtering van geboden QOS indien explicietflowcontrol Diet in gebruik is. 3): De uitvoering van deze seIVice is in Class 4 vindt op andere wijze pIaa1s dan in de andere transport classes. 1 2

= =

net.nonn network nonna! data variant net.exp. network expedited data variant

AnnexC

051 Netwerklaag 169

OSI Netwerklaag

De OSI Netwerklaag is onderverdeeld in drie sub-Iagen, te weten: Subnetwork Access Sub/ayer, Subnetwork Dependent Convergence Sub/ayer en Subnetwork Independent Convergence Sub/ayer. Subnetwork Independent Convergence Sub/ayer --------- - - - - - - - - - - - -

Subnetwork Dependent Convergence Sub/ayer Subnetwork Access Sub/oyer

Figuur C.1 : Verdeling van de OSI-netwerklaag in sublagen

C.1 "Sublayers" Het doel van deze sublagen is het maskeren van specifieke netwerkeigenschappen zodat bij koppeling van verschillende netwerken toch een unifonne netwerkservice geboden kan worden. De onderste sublaag, de "Subnetwork Access Sublayer", verzorgt het contact met het netwerk via de Data Link laag en is dus in sterke mate afbankelijk daarvan. De "Subnetwork Independent Convergence Sublayer" biedt am alle gebruikers (transponlaag-entiteiten) een zelfde netwerk-service am, en zorgt daannee in feite voor het maskeren van de eigenschappen van het specifieke netwerk. Tenslotte dient de "Subnetwork Dependent Convergence Sublayer" voor de koppeling tussen de twee andere sublagen.

C.2 Toepassing'---

_

Het is mogelijk om CL-netwerken op te waarderen tot een CO-netwerk door het toepassen van een convergence protocol. Op dezelfde manier kan een CO-netwerk zich als een CL-netwerk gaan gedragen. Door binnen alle te koppelen subnetwerken hetzelfde "Subnetwork Independent Convergence Protocol" te definieren onstaat de situatie dat het geheel zich als een CO- of CL-netwerk gedraagt.

170 OSI Netwerklaag

AnnexC

Zo kan men bijvoorbeeld binnen LAN's (CL) X.25 als convergence protocol definieren waardoor koppeling met een X.25 netwerk mogelijk wordt.

AppendixD

Protocol/en binnen OSI 171

Protocollen binnen OSI

In de figuur op de volgende pagina vindt U een overzicht van de protocollen die binnen het OSI-model toegepast (kunnen) worden. In het kader van dit verslag is daarin de invullingen van de netwerklaag (en in mindere mate die van de transportlaag) van belang. Middels een arcering is in de figuur het onderscheid aangegeven tussen CO- en CL-netwerkprotocollen (welke resp. een CO- en CL-netwerk"service" bieden). De CO-protocollen worden aangegeven met: en de CL-protocollen met:

D,

D.

172

AppendixD

. . . . . . . . .nclllnll III xed Mod.

Videotex

.........., .....,., ..-- '~:1 ~;~D Ta

7: Appllcallon Layer

T......

T."

'.111

'.1" "',110

'

'.11e

....

,

TA'

' T."

6: Presentation lIyer

''':

"'.

r--------

llA10 JlAH

~ ~

"=117'l1"1

~

eo'." IC'M-tOl

1OO'Df'_

1OO'Df'_

XA'"

Job T,.,,81.

VI..-I Terml_

-=-J'"-".; ,; .1:11

I6'Qt1

IIIO'DP'

IeO'DP

U'.

--,

c---- - _ - -c. . ~ .....·...._u ~.l 1OO'Df'_

I....'

ICIM-1Ol IOO'Df' ..,...

IClM-101

--~

_..

_.oa.....-

_.oa --_ -

0 [JI ' ~, r TA' T ",.,

CEP'TWCOll

/,. /!.,

....

~"

~l~/

.,-,,,*,,
~~.

~ .~. $o<&? :R~:::-::,;:::~.

...

5: Session Layer

~.,tn

1IO't)ft . . . .,

r'01

~

.~

r--------

110""....

rA 1.6 T.sG T.7I

T,.

TA'

---- .c_ ---

---

I

..

FIle TNn81.

public

... ,•• IICJIIIM.I:DI

• • • • fIOIDII,112'

....c......... •.-I[K8l

.... ~ ..-.tfU.)

.... ~ ...... ~ (. .l

I

..

~

connection-oriented

con necllon-Ies s

~~ ~

IICilOtIUO"h

4: Transport Layer

x,,,,

~~t'I.X.IU

'1eO'OIa eoJa'Do\D ,

T.rv .... O

3: Network Layer

- -- - -- - -- -- --- -

...

...

...

IUlIi.-J

ll·JlJ8Ir'II'lLlMlil

lA«l ,LAP D) tAll, (LAP!))

.,... --.,. _.-

IG<;

-"-

2: Data Unk lIyer

-....

1: Physical Leyer

..., ...,.

-• .It

1101110

CSPDN

IAN I...... Of

1IO~1

....

V...

,-

""'0

I"."""V.I' ) aeouell17

V.IAN... Y.l4l\l,10

LAID (WT"". PL)

......

............1'

PSTN

...

::::r:::.:'>'"''''

- ' " - '.<

·.......-,lr_ . . . . . . . .~

--...,...eo, .....-.(1' ,, _ _ IT_

l.c1_llIII'tflllUI)

......

.......,...... _... ,...

ISDN

l

~

1""1"Il"'l.l~l)

va.a

~~......".

Figuur 0.1: Protocollen binnen het OSI-model

...... _. --...

-.:

TJ!tt...... UNI

..-

--

LAN

....

.

Appendix bij ISO 84 73 173

Appendix E

_ _ _----IA~endix bij ISO 8473

In aanvulling tot hetgeen over het Connection Less Netwerk Protocol ISO 8473 is verrneld in hoofclstuk 4 wordt er in deze appendix op details ervan ingegaan.

E.1 Structuur en encoding van de PDU's Alle ISO 8473 POU's moeten opgebouwd zijn uit een geheel aantal bytes. Ze bestaan uit een header en een data-veld. Oe header is verder nog verdeeld in een zogenaamd fixed part, address part, segmentation part en een options part. Oe laatste twee, het segmentatioll- en options part zijn niet in alle POU-headers aanwezig. Oe structuur van een ISO 8473 POU is in onderstaande figuur schematisch afgebeeld.

~ F;)(ed~rt

I

AddrMS Part

I

S~m.nlalion Part

I

Options Patt

Figuur E.1 : PDU-structuur

Oe bytes in een POU zijn oplopend genummerd in de volgorde waarin ze in een SN-SOU geplaatst worden. Zie voor gedetailleerde inforrnatie over de nummering van de diverse onderdelen binnen een POU de volgende figuur. De daarin aangegeven volgorde van bits en bytes wordt ook in de andere figuren in deze appendix aangehouden.

l

~...._.B.:Yt.e.1_..,.,I__.B.:vte.2_ _.. / / / bitnummer:

/ /

1'-8

\ 7

6

5

4

3

_ . t . .tic.". bit

Figuur E.2: Bit- en byte volgorde in PDU's

2

1

174 Appendix bij ISO 8473

Appendix E

E.1.1 Fixed part In het fIxed part worden o.a. gegevens ondergebracht betreffende het gebruikte protocol (en de versie daarvan), het wel- of niet in gebruik zijn van bepaalde opties zoals segmentation en error-reporting, en enkele algemene gegevens als lengte van de header en geldigheidsduur (lifetime). De codering vindt op anderstaande wijze plaats; de inhoud van de diverse velden komt in de volgende paragrafen aan de orde. Byte:

Network Layer Protocol Identifier Length Indicator

2 3

VersionlProtocol 10 Extension 1---.

..

Lifetime

4

5

~~~Ri --T~~--

6,7

Segmenth Length

8.9

Checksum

-

_=

Figuur E.3: Fixed Part van de PDU·header

Network Layer Protocol Identifier Hierin wordt door middel van een code het gebruikte protocol aangegeven. In het geval van ISO 8473 (zoals bier) met de binaire waarde: 1000 0001

Version/Protocolldentifier Extension In dit veld wordt de gebruikte versie van het eerder in de Network Layer ProtocolIdentifier aangegeven protocol aangegeven. Aktueel bevat dit bij gebruik van ISO 8473 de binaire waarde: 0000 0001

Length Indicator Geeft de lengte van de header aan in aantal bytes (binair gecodeerd) met als maximum 254 (1111 1110). De waarde 255 (1111 1111) is gereserveerd voor toekomstige ontwikkelingen. Met de term header wordt bier het samenstel van het Fixed-, Address-, Segmentation- en Options-Part bedoeld. Opmerking: De lengte van een POD-header mag volgens de protocoldefmitie niet worden gewijzigd bij relayering of eventuele segmentering. Het gevolg biervan is dat alle segmentenvan een bepaalde (initiele) POD dezelfdeheader-Iengte hebben (met uiteraard eenzelfde waarde voor de Length Indicator): gelijk aan die van de initiele POD.

Appendix bij ISO 8473 175

Appendix E

PDU lifetime De nog resterende levensduur van een PDU wordt aangegeven in het Lifetime-veld (in eenheden van SOO ms). De initiele waarde ervan wordt door het bron eind-systeem (het eind-systeem die de betreffende PDU gecreeerd heeft) bepaald. Elke netwerk-entiteit waar zo 'n PDU "langs komt" verlaagt de inhoud van het PDU-liftime-veld met de waarde 1 als de som van dev transit-delay van het subnetwerk waarvan de PDU afkornstig is en processing-delay van de betreffende entiteit maximaal SOO ms bedraagt. Een grotere totale delay wordt in rekening gebracht door een grotere waarde (modulo SOO ms) in mindering te brengen. PDU's met een lifetime gelijk aan nul worden door de ontvangende netwerk-entiteit "weggegooid" (deze fasciliteit hoeft niet altijd aanwezigte zijn). Bovendien zal een Error Reponing Function die binnen de netwerk-entiteit aanwezig is een ER-PDU genereren (de ER-PDU wordt later nog behandeld).

Tens/otte: Bij eventuele segmentatie van PDU krijgt de lifetime-parameter van alle segmenten dezelfde waarde als in de oorspronkelijke PDU.

Flag's Binnen het Se byte van het Fixed Part zijn een drietal bits gereserveerd voor flag's, te weten: Segmentation Permitted, More Segments en Error Report Flag. De waarde 1 voor de Segmentation Permitted Flag geeft aan dat segmentation toegestaan is. Een 0 (segmentation niet toegestaan) houdt automatisch in dat de non-segmenting protocol subset in gebruik is. Indien er van segmentation gebruik gemaakt is, wordt door middel van de More Segments flag aangegeven of een bepaalde PDU wel- (flag 0) of niet (flag 1) het laatste segment bevat van de initiele PDU. Bij de non-segmenting protocolsubset kan deze flag uitsluitend de waarde 0 bevatten.

=

=

Tens/one: De Error Report flag, een waarde 1 geeft aan dat er, volgens de nog te beschrijven procedure, Error Report PDU's gegeneerd moeten worden.

Type code De rest van het Se byte wordt toegepast voor het onderbrengen van een type-code van het betreffende PDU. Het 18473 kent slechts 2 PDU-types: Data- en Error report PDU (resp. OT-POU en ER-POU).


Appendix E

PDU Segment Length Oit veld geeft de totale lengte (header + data) aan van een POU-segment} In gevallen waarin er geen segmentation plaats vindt bevat de PDU-segment length parameter een waarde voor de totale lengte van de POU. NB.: Bij gebruik van het complete ISO 8473 protocol zal de PDU-segment lenght en het Total length veld in het Segmentation part van de header dezelfde waarde hebben (in de non-segmenting subset is het Segmentation part, en dus het Total Length-veld, niet aanwezig, en fungeen de PDU-segment length als Total Length-veld).

PDU Checksum Er wordt een checksum bepaald voor de complete POU-header. Het resultaat daarvan wordt door een initierend eind-systeem in het PDU Checksum veld geplaatst. Oe waarde 0 is gereserveerd voor het aangegeven van het feit dat er geen checksum bepaald is.

E.1.2 Address part Het tweede veld binnen de ISO 8473 POU-header is het adress-part, waarin zowel het bestenunings- als bron-adres zijn aangegeven in de vonn van Network Service Access Point adressen (NSAP-adressen) zoals gedefinieerd is in ISO 8348{AD 2. Oeze adressen hebben geen voorafbekende lengte, zodat de afmetingen (in hele bytes) van de Destinationen Source-adresvelden variabel zijn. Oe aktuele lengten worden in de twee bijbehorende Length Indicator velden aangegeven. Zie onderstaande figuur. Byt.: 10

Destination Address Length Indicator

11

Destination Address

..... 1

m .....1

Sourctl Address Length Indicator Sourctl Address

Figuur E.4: Address Part van de PDU-header

Het zal duidelijk zijn dat een ontvangend eind-systeem aan de hand van de inhoud van het Address part zal bepalen of een PDU zijn eindbestemming heeft bereikt, of dat het moeten worden doorgezonden naar een volgend eind-systeem.

1

Met een PDU-segment woldt bier een segment van een iDi~el PDU bedoeld, dat opzichze1f ook een PDU vannt (Header + data).

Appendix bij ISO 84 73 1n

Appendix E

E.1.3 Segmentation part Het Segmentation part is slechts aanwezig in de POD-header indien de Segmentation Permitted Flag in het Fixed part gezet is (waarde 1). In alle andere gevallen (flag-waarde = 0) is het Segmentation part niet aanwezig, en is dus de non-segmenting protocol subset in gebruik. Zie in figuur 1.5 de verschillende velden binnen het Segmentation part. Byt.:

n.n.'

Data Unit Identifier Segment Offset Total Length

Figuur E.5: Segmentation Part van de PDU-header

Data Unit Identifier Bij de compositie van POD's worden alle POD's die segmenten bevatten van een initiele POD of van een NS_userdata primitieve gekenmerkt door een unieke Data Unit Identifier (alle segmenten hebben dus dezelfde Data Unit Identifier-waarde). In het eerste geval zijn de Data Unit Identifiers van zowel het initiele POD als de afgeleide segment-POD's aan elkaar gelijk.

Segment Offset Oe afzonderlijke segmenten (segment-POD's) kunnen onderscheiden worden door een Segment Offset. Oeze geeft de relatieve positie (offset) van het betreffende segment aan in het initiele dataveld (afkomstig uit een initieel-POD of NS-userdata primitieve). Oe codering ervan is binair in eenheden van hele bytes; de offset van het eerste segment is O.

PDU Total Length HetPDU Total Length veld geeft de totale lengte aan van het initiele POD (header + data). Deze waarde komt ook voor in eventuele afgeleide POD's (bij segmentation).

E.1.4 Options part Byte: n+6 p

Options

Figuur E.6: Options Part van de PDU-header


Appendix E

Padding Indien gewenst kunnen er aan de POU-header een aantal "lege" bytes toegevoegd worden door middel van padding. Code: length: Value:

1100 1100

variabel alles toegestaan

Security Code: Length: Value:

1100 0101

variabel Twee mogelijkheden, aangegeven in het Ie bit (5=0 of 5=1). Zie figuur E. 7 5.0

[Sl

US9r D9finEJd

I

Cod9

5 I

Organisation

Cod•• Thie kid " " _ -Ileographlc or ~aphiccod. III which the option appli... OrganiMtion • Thie Ie fulhw IUbdeYlolon to ... Code fteld and I. Hl...mlned by an _nletra"" of the eeoIl'aphIe '" non.....aphIc domain idwllIfMd by the valu. of Cod••

Figuur E.7: Security parameter in het Options Part

Source Routing

Geeft de route (geheel of gedeeltlijk) aan die een PDU moet volgen. Code: Length: Value:

1100 1000

variabel 2 bytes conttol-infonnatie gevolgd door een adres-list (in volgorde van bron naar bestemming).

De control-infonnatie (2 bytes) geeft geheIe- of pani Ie sourcerouting aan, en bevat een offset die de plaats aangeeft binnen de adres-list welke als volgende aan de beurt is om behandeld te worden (als dat het eerste adres is in de reeks bevat deze offset de waarde 3).

Appendix bij ISO 84 73 179

Appendix E

De invulling van het eerste byte is als voIgt:

o0 0 0 0 001 0000 0000

complete source routing parial source routing

Elk item in de adres-list bestaat uit een netwerk-adres samen met een individuele lengte indicator (l byte lang, gaat vooraf aan het netwerk-adres). Zo'n lengte-indicator is noodzakelijk omdat de lengte van netwerkadressen variabel is.

Recording of Route Binnen het ISO 8473 is er een voorziening aanwezig om de door individuele POU's afgelegde route te registreren binnen de POU-header. Uitsluitend netwerk-adressen van eind-systemen waarlangs de POU passeen worden geregistreerd: dus niet het adres van het bron- en bestemmings-end-systeem. Code: Length: Value:

1100 1011 variabel 2 bytes control-info gevolgd door een adres-list

Het eerste control-byte is in gebruik voor het aangeven of de Recording of Route-functie nog uitgevoerd wordt of dat deze beeindigd is als gevolg van gebrek aan ruirnte in de adres-list (die lengte wordt door het initierende eind-systeem bepaald/gereserveerd binnen de header. De invulling van het eerste byte: 0000 0000 1111 1111

Recording of Route functie nog actief Recording of Route functie gestaakt

De adres-list is op dezelfde wijze gedefmieerd als bij de in de vorige paragraaf behandelde Source Routing functie.

Quality of Service Maintenance Door middel van deze optie in het Options Part van de POU-header wordt informatie betreffende de door de netwerk-service gebruiker gevraagde Quality of Service overgedragen naar peer-network-entiteiten (inclusief intermediate systems zoals relays). De algemene codering van deze parameter is als voIgt: Code: Length: Value:

1100 0011 Variabel Zie de tekst

Bijzonder is dat er een aantal verschillende coderingen voor QOS-gegevens mogelijk zijn. Zo kan er een codering toegepast worden die een specifieke betekenis heeft voor het


Appendix E

bestenuning-end-systeem ofvoor het bron-end-systeem, het zogenaamde "Source Addrss Specific-" en "Destination Address Specific-" QOS formaat. Uiteraard is er ook een standaard ISO 8473 codering mogelijk. De gebruikte codering wordt aangegeven het 7e en 8e bit van het Parameter Value veld, zie onderstaande tabel. label E.1: Betekenis van bit 7 en 8 van het aDS veld QQS-formaat code: 00 01 10 11

.. Tvoe QOS.v.k:l: Reserverd Source Address Specific Destination Address Specific Globally UniQue

Source/DestInatIon Address Specific In het geval van de Source- of Destination Address Specific codering zijn overige bits in het eerste byte van het Parameter Value veld ingevuld met nullen. In de volgende bytes worden dan de specifieke QOS-gegevens onder gebracht.

Globally Unique

De Globally Unique codering is de normale ISO 8473 codering, waarbij de overige bits van het Parameter Value veld gebruikt worden om de gewenste QOS aan te geven. Deze posities (bits) worden als voIgt gecodeerd: Elke postie correspondeerd met twee QOS-gegevens; met een nul of een geeft het initierende eind-systeem aan welke van de twee de voorkeur verdient. Zie onderstaande tabel voor de precieze betekenis van de bits 1 tim 6. label E.2: Coderering bij Globally Unique aDS codering

Set.kents;

BUwnummer: 1 2 3 4 5 6

7&8

•...

foutenkans ... kosten foutenkans ... transit delav transit delav ... kosten conaestie oooetreden volgorde behoud ... transit delay

Reserved QOS-formaat, code 11

Opmerking: de codering van bit 4 is afwijkend: een 1 geeft aan dat er congestie optreed in het netwerk. De initiele waarde is O. De waardes van de bits 1 tim 3 en 5 geven aan welke van de twee grootheden geoptimaliseerd dienen te worden (bijvoorbeeld bij de keuze tussen te volgen route binnen het netwerk).

Appendix bij ISO 8473 181

Appendix E

Zo geeft de waarde 1 voor bet 3e bit aan dat een lage transit delay belangrijker is dan lage kosten.

Priority De priority parameter geeft de relatieve prioriteit aan die afzonderlijke PDU's dienen te krijgen bij verwerking zoals routering en het bepalen van volgorde van verzending. De codering is als voIgt: Code: Length: Value:

1100 1100

1 byte 0000 0000

Nonnale prioriteit

Vm

o000 111 0 Hoogste prioriteit (alle andere waardes zijn gereserveerd)

E.1.5 Data part Het Data-veld bevat een geheel aantal bytes (minimaall byte) user-data. Deze is afkomstig van, of bestemd voor, de NS_Userdata parameter in een N_UNITDATA Request, of Indication primitive. Byte: p+1

z

Data

Figuur E.8: Data-veld in een PDU

E.1.6 Data (DT) PDU Zie figuur E.9 voor een schematisch overzicht van een complete DT-PDU

E.1.7 Error Report PDU De opbouw van een complete ER-PDU is in figuur E.IO afgebeeld. (Zie ISO/IS 8473 protocol specificatie voor de codering van de foutcode)


Appendix E

Networll Layer Protocol Identifier -------

._-

Length Indiestor

I

VersionlProtocollD Extension Lifetime SP

IMS IEIR I

Type

Segmenth Length

.,7 I,'

Ched<sum

'0

Destination Address Length Indicator

.".', . _, "" n, ,..1

Destination Address Source Address Length Indicator

._---_._-

--

---

Source Address ~-'---

Data Unit Identifier Segment Offset

..... p

p.'

•

Total Length Options Data

Figuur E.g: Complete opbouw van een Data PDU (DT-PDU)

E.1.8 Inactive Network Layer Protocol Een zeer beperkte subset van het ISO 8473 protocol wordt gevonnd door het Inactive Network Layer Protocol. Dit bevat slechts een protcol-identifier en user-data. Het zal duidelijk zijn dat deze subset alleen bruikbaar is tussen twee direct met elkaar in verbinding staande eind-systemen, daar er geen netwerk-adresseringsinfonnatie in de PDU's aanwezig is.

183

AppendixE

1IJto: Network Layer Protocol Identifier ---

------------

Lengttllndicator VersJonlProtocoilD Ext_Ion Lifetime Sp

IMS lElA

'.7

'.' 10

T~

I

SlIgmenth Length Ch«lcsum DMination Address Length Indicator

11

",.,

Dfltltin81ion Address Source Address Length Indiccor Source Address

n, n+1

- - ._----

Dca Unit Identifier SlIgment Offset ------~-

- -

Total Length ....e 1'"1 P

~1

Options Reason for Discsrd

q

•

Dca

Figuur E.1 0: Opbouw van een compleet Error Reporting PDU (ER-PDU)

TECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER ELEKTROTECHNIEK

Recommend Documents