83501 Tietoliikenneprotokollat Luentomoniste osa 1 syksy Jarmo Harju

Transkriptio

1 83501 Tietoliikenneprotokollat Luentomoniste osa 1 syksy 2000 Jarmo Harju

2 TIETOLIIKENNEPROTOKOLLAT OSA 1 1. Johdanto OSI -viitemalli ja standardointi Tausta ja standardien ryhmittely Viitemallin yleiset periaatteet Johdanto OSI -mallin kerroksiin Protokollien määrittely ja mallintaminen Historiaa Määritelmiä ja ominaisuuksia Mallinnusmenetelmät Yksinkertainen äärellinen automaatti (FSA, Finite State Automaton) Mealyn tilakone Yleistetty äärellinen automaatti (EFSA, Extended FSA) Automaattien välinen kommunikointi Kanavat Järjestelmäarkkitehtuuri Siirtokerroksen protokollille tyypillisiä mekanismeja Virhekontrolli Virhetodennäköisyydet Virhetyypit ja virheiden korjaus Virheenkorjaavat koodit Sykliseen varmenteeseen (CRC) perustuvat koodit Vuonvalvonta ja virhetoipuminen: johdanto Yksinkertainen stop-and-wait -mekanismi vuonvalvontaan Sanomia kadottavan kanavan ongelma Sanomia vääristävä ja kadottava kanava: lisää ongelmia Pitkän siirtoviiveen ja kanavan käyttöasteen ongelmat Vuonvalvonta ja virhetoipuminen: liukuvan ikkunan mekanismit Yleistä Toipuminen PDU:iden katoamisesta - Go-Back-N ARQ Toipuminen PDU:iden katoamisesta - Selective Repeat Toipuminen PDU:iden katoamisesta - Negative Acknowledgement Verkkokerros Verkkokerroksen tehtävät Verkkopalvelu Yhteyspohjainen palvelu Yhteydetön palvelu Verkkoprotokollat Verkkokerroksen sisäinen rakenne Yhteydetön verkkoprotokolla ISO IP Kuljetuskerros Kuljetuskerroksen tehtävät ja protokollaluokat Kuljetuspalvelu ja kerroksen tärkeimmät protokollamekanismit Kuljetuspalvelu Yhteydenmuodostus kuljetusprotokollan luokka 4:ssa Yhteyden purku kuljetuskerroksella Luottomenetelmä vuonvalvonnassa Viitteet...57 Liite

3 Luvut 1-3 puuttuvat tarkoituksellisesti

4 4. Protokollien määrittely ja mallintaminen 4.1 Historiaa Protokollilla on tietoliikenteessä pitkä historia. Ennen puhelinta ja sähköisiä lennätinjärjestelmiä televiestintä perustui pääasiassa näköhavaintoihin: savumerkit, tulet, soihturyhmät, suuret puiset konstruktiot (semaforit), joiden asentoa voitiin muuttaa, ym. Näiden järjestelmien tiedonsiirtokapasiteetti oli luonnollisesti varsin vaatimaton. On arvioitu, että luvulla käytettyjen näköhavaintoon perustuvien järjestelmien kapasiteetti on ollut luokkaa 1 bit/s. Vastaavissa protokollissa kuvattiin, mitkä semaforien asennot tai millaiset soihturyhmät vastasivat mitäkin merkkejä tai sanomia. Poikkeuksellisten tilanteiden kuvaamiseen järjestelmät eivät olleet riittävän hyvin varustautuneita tai ohjeet saattoivat olla puutteelliset, jolloin eri henkilöt tulkitsivat tilanteet eri tavoin. Tästä on lukuisia esimerkkejä mm. junaonnettomuuksien historiassa junaliikenteen alkuvaiheista nykypäivään asti. Sähköisen tiedonsiirron kehittyessä 1800-luvun puolivälin jälkeen tiedonsiirron nopeus kohosi n. 30:een bit/s reikänauhaa käyttävän automaattisen lennättimen ansiosta. Siitä kehitetty järjestelmä sai lopullisen muotonsa luvulla, jolloin käyttöön otettiin Baudot'n 5-bittinen koodi ja automaattiseen vastaanottoon kykenevät kirjoittimet, siis telex -järjestelmä. Puhelinliikenteessä protokollien merkitys oli pitkään vähäinen, koska välitysjärjestelmät perustuivat yksinkertaiseen ja varmatoimiseen tekniikkaan tai hankalammissa tilanteissa keskusoperaattoreiden kanssa käytävään ihmisten väliseen keskusteluun. Protokollien kannalta seuraavat merkittävät tapahtumat ajoittuvat luvulle, jolloin automaattisen tietojenkäsittelyn aika alkoi. Silloin alkanut ATK:n kehityskulku on merkinnyt myös jatkuvaa protokollien kehitystä. Keskitettyjen järjestelmien aikana tietoliikenteen ongelmana oli yhdistää oheislaitteet (päätteet, kirjoittimet, nauhanlukijat) keskuskoneeseen. Luonteva tapa ratkaista hallinnan ja synkronoinnin ongelmat oli antaa yhdelle kommunikointiosapuolelle määräysvalta muihin nähden. Näin syntyivät ns. master - slave -protokollat, joissa master vastasi toimintojen käynnistämisestä, virhevalvonnasta, vuonvalvonnasta (poll -kyselyt), ym luvulla alkoi syntyä keskuskoneita yhdistäviä verkkoja, joissa master - slave -suhteet eivät välttämättä olleet käyttökelpoisia. Myös verkkojen tiedonsiirtonopeus oli kasvanut. Pakettikytkentäisten dataverkkojen myötä kehittyivät uudentyyppiset protokollat, nk. peer-to-peer -protokollat. Viime vuosikymmenten aikana nämä protokollat ovat kehittyneet ja standardisoituneet, ja niitä on sovellettu merkitykseltään yhä monipuolisempien ja monimutkaisempien kommunikointitilanteiden hallintaan. Viimeisimpänä kehitysvaiheena on nähtävissä suurinopeuksisten (luokkaa Gbit/s) verkkojen protokollille asettamat vaatimukset.

5 4.2 Määritelmiä ja ominaisuuksia OSI:n kerrosrakenteisessa mallissa protokollan tehtävät rajoitetaan sopiviin, helposti ymmärrettäviin osiin sallimalla keskustelu vain samalla kerroksella olevien vertaisolioiden välillä. Nämä kerrosprotokollat liittyvät ympäristöönsä palvelurajapintojen kautta. Kerroksen (N) protokollan siirtämä, sen itsensä kannalta merkityksetön tavujono jäsentyy ja saa merkityksellisen sisällön siirtyessään palvelurajapinnan kautta ylemmälle kerrokselle, jossa (N+1) -protokolla tulkitsee sen (tai osan siitä) omaan sanomajoukkoonsa kuuluvaksi. Kun halutaan katsoa kerrosmallia palvelujen näkökulmasta (ja ajatella palvelu hyvin määritellyksi käsitteeksi), voidaan kerrosprotokolla määritellä yksinkertaisesti: (N) -protokolla sovittaa (N) -palvelun (N-1) -palveluun. (4.1) Tämä määritelmä korostaa protokollalle asetettavia tavoitteita; siitä voidaan johtaa ne asiat, joista protokollan tulee huolehtia. Tarkastellaan esimerkkinä tilannetta, jossa palvelurajapintojen laadussa on suuri ero: Korkeatasoinen palvelu pitkät PDU:t yhteyspohjainen palvelu useita rinnakkaisia yhteyksiä luotettava kuljetus tietoturva (N)-olio (N)-palvelu (N)-protokolla Vaatimaton palvelutaso lyhyet paketit yhteydetön palvelu epäluotettava kuljetus tietovarkaita... (N-1)-palvelu Kuva 4.1 Protokolla palvelurajapintojen ominaisuuksien sovittajana Kuvan tapauksessa (N) -protokollalla on paljon tekemistä! Kerrosprotokollien tehtävät näyttäisivät näin olevan sangen riippuvaisia kerroksesta. Näin tietysti onkin, mutta on myös useita sellaisia tehtäviä, jotka esiintyvät useamman kuin yhden kerroksen protokollissa: - yhteydenmuodostus, - PDU:iden pilkkominen ja kokoaminen, - vuonvalvonta, - virhevalvonta ja virheistä toipuminen,

6 - yhteyksien limitys, - erityispalvelut: kiirehditty data, yhteyspyyntöjen törmäysten hallinta, parametreista neuvottelu, tietoturva, ym. Määritelmä (4.1) ei anna minkäänlaista viitettä siitä, miten protokolla voisi hoitaa esim. edellä mainitut tehtävät. Protokollassa on aina kysymys sanomien avulla toteutettavasta keskustelusta, jolloin konstruktiivisemmassa määrittelyssä voidaan ajatella karkeaa analogiaa kielen määrittelyn kanssa. Protokollaan kuuluu: - yhteys toimintaympäristöön (semantiikka), - sanomajoukon määrittely (sanasto), - sanomien rakentuminen biteistä ja kentistä (syntaksi), - toimintalogiikka (kielioppi). Edellä on jo nähty, että OSI-mallissa palvelun käsite liittää protokollan toimintaympäristöönsä. Protokollan sanomajoukko koostuu PDU:ista, joilla on oltava tarkkaan määritelty esitys binaarimuodossa. On kuitenkin selvää, että oleellisilta osiltaan vastaus kysymykseen, miten protokolla suorittaa sille asetetut tehtävät, sisältyy kohtaan toimintalogiikka. Toimintalogiikan tulee taata keskustelun järkevä kulku ja asianmukaiset toimenpiteet paitsi normaaleissa, myös kaikissa muissa ajateltavissa olevissa tilanteissa. Tämä tekee toimintalogiikasta väistämättä mutkikkaan jo varsin yksinkertaisiakin tehtäviä suoritettaessa, ja erityisten mallinnusmenetelmien käyttö on tarpeellista sekä protokollien toiminnan analysoinnissa että niiden toteuttamisessa. 4.3 Mallinnusmenetelmät Toimintalogiikka ohjaa keskustelun kulkua määrittelemällä sopivat vasteet toiselta osapuolelta saapuneisiin sanomiin. Tarkempaa tietoa välitetään sanomien parametreissa, joista osa on tarkoitettu protokollan ohjaukseen, osa taas välitettäväksi palvelurajapinnan kautta ympäristöön (OSI -mallissa ylemmälle kerrokselle). Sanomat ja parametrit ovat siis syötteitä toimintalogiikalle sen suorittaessa tehtäviään. Tällaiseen tilanteeseen ovat sopiviksi mallinnusmenetelmiksi osoittautuneet tila-automaatteihin pohjautuvat menetelmät, joita seuraavassa tarkastellaan lähemmin Yksinkertainen äärellinen automaatti (FSA, Finite State Automaton) Yksinkertainen äärellinen automaatti eli tilakone M on viisikko: missä M = (S, I, t, s o, F), 1) S on äärellinen tilojen joukko, 2) I on äärellinen syötteiden joukko, 3) t on tilasiirtymäfunktio t:sxi -> S,

7 4) s o S on alkutila, 5) F on lopputilojen joukko, F S. Aluksi M on tilassa s o odottaen syötejonoa j Ι *, missä Ι * on syötejonojen joukko: Ι * = {a 1 a 2...a n a i I, i = 1,...n, n N }. Kun jono j on käyty läpi, M pysähtyy. Olkoon lopputila r S. Jos r F, niin M hyväksyy j:n, muuten M hylkää j:n. M:n hyväksymien syötejonojen joukko L(M) (joka on Ι * :n osajoukko) on M:n määrittelemä kieli. Tarkastellaan esimerkkinä pariteetin laskentaa. Olkoon M = (S, I, t, s o, F), missä S = {even, odd}, I = {0, 1}, s o = even, F = {even}. Määritellään tilasiirtymäfunktio t seuraavasti t: even odd S I 0 1 even odd odd even Sama graafisena kuvauksena: 1 0 even odd 0 Kuva 4.2 Pariteetin laskennan automaatti 1 M:n hyväksymien syötejonojen joukko L(M) koostuu sellaisista 0:n ja 1:n jonoista, joissa on parillinen määrä ykkösiä Mealyn tilakone Mealyn tilakone on automaatti, jossa on määritelty myös tulostus (output): M = (S, I, O, t, σ, s o ),

8 missä S, I, t ja s o ovat kuten edellä, lisäksi O on äärellinen tulosteiden joukko, σ on tulostusfunktio σ: S x I -> O (tulostus riippuu tilasta ja syötteestä). Mealyn tilakoneessa ei ole loputilojen joukkoa. Tilannetta, jolloin M tilassa s 1 saa syötteen a I ja siirtyy tilaan s 2 lähettäen tulosteen o O, kuvataan yleensä graafisesti seuraavasti: a o s 1 s 2 Kuva 4.3 Graafinen merkintä tilasiirtymälle Mealyn tilakoneessa Mealyn tilakone M tuottaa syötejonoista tulostejonoja. Kutakin alkutilaa s o kohti se määrittelee kuvauksen Ms o : Ι * -> Ο *, missä Ο * on tulostejonojen joukko samalla tavalla kuin Ι * on syötejonojen joukko. Mealyn tilakoneen toimintaa voidaan tutkia syöttämällä sille ns. testisekvenssejä ja analysoimalla tulossekvenssejä Yleistetty äärellinen automaatti (EFSA, Extended FSA) Mealyn tilakonetta voidaan yleistää lukuisilla eri tavoilla. Pääasiallisena syynä yleistyksille on, että FSA:ta käytettäessä syntyy yleensä suuri määrä tiloja jo yksinkertaisia tapauksia mallitettaessa. Tyypilliset muutokset: 1) otetaan käyttöön tulostejonot: σ: S x I -> Ο *, 2) muuttujien käyttö: olkoon M:llä k kpl kokonaislukumuuttujia eli muuttujavektori V Z k. Funktiot t ja σ voivat myös käyttää muuttujavektoria: t : S x I x Z k -> S, σ: S x I x Z k -> Ο * x Z k (σ voi myös muuttaa muuttujien arvoja). EFSA:lla kuvaus saadaan kompaktiksi, toisaalta analysoituvuus heikkenee. CVOPS-kehitysympäristössä on käytössä EFSA:an pohjautuva protokollien mallinnusmenetelmä, jossa kokonaislukujen lisäksi voidaan käyttää hyväksi rakenteisia muuttujia.

9 4.3.4 Automaattien välinen kommunikointi Mealyn tilakoneet ja yleistetyt äärelliset automaatit voivat kommunikoida toistensa kanssa: toisen output voi olla toisen input, jne. Malliin voidaan tällöin luontevasti ottaa mukaan aika, jolloin lähestytään rinnakkaisten järjestelmien toiminnan perusteita. Ajan liittäminen malliin mahdollistaa myös monissa protokollissa tärkeiden ajastimien mallintamisen. Aikaa kuluttaa luonnollisesti input-elementtien odottaminen. Myös automaatin siirtymä- ja tulostusfunktiot kuluttavat suorituksessaan vaihtelevan määrän aikaa, ja tänä aikana automaatti ei voi ottaa vastaan syötteitä. Useista automaateista yhdistetyn automaatin käyttäytyminen tulee näin riippuvaiseksi siitä, milloin tilasiirtymät katsotaan loppuunsuoritetuksi, eli milloin automaatti on valmis ottamaan vastaan uusia syötteitä. Tarkastellaan seuraavassa tähän liittyvää ilmeistä tulkintaongelmaa: Automaatti S (sender) suorittaa saamaansa syötteeseen a liittyvää tulostusfunktiota σ, johon sisältyy tulosteen b lähettäminen automaatin R (receiver) syötteeksi. Milloin tulkitaan funktio σ loppuunsuoritetuksi, silloinko kun b on saatu tulostettua vaiko silloin kun R ottaa syötteen b vastaan? Edellisessä tapauksessa S:n valmius ottaa vastaan seuraava syöte ei riipu R:n käyttäytymisestä, jälkimmäisessä S ei voi ottaa seuraavaa syötettä ennen kuin R on edennyt tilanteeseen, jossa se voi ottaa b:n vastaan. Edellistä tulkintaa kutsutaan asynkroniseksi lähetyskäytännöksi. Sen havainnollistamisessa voidaan ottaa käyttöön apukäsite puskuri B, jossa tuloste/syöte voi kuluttaa aikaa. S B R Send Aika } Wait Receive Tilasiirtymät laukeavat toisistaan riippumatta Kuva 4.4 Asynkroninen lähetyskäytäntö Esim. CVOPS ja formaali kuvauskieli SDL käyttävät asynkronista lähetyskäytäntöä. Jälkimmäistä tulkintaa kutsutaan synkroniseksi lähetyskäytännöksi.

10 S R Aika Send } Wait Receive Tilasiirtymät laukeavat yhtä aikaa Kanavat Kuva 4.5 Synkroninen lähetyskäytäntö Esim. ADA, Occam ja LOTOS -kielet käyttävät synkronista lähetyskäytäntöä. Mallintamisen kannalta asynkronisen lähetyskäytännön yhteydessä käytetty puskuri -käsite ei toistaiseksi ole tyydyttävällä tavalla määritelty. Kommunikoivien automaattien kannalta se on parempi korvata kanavan käsitteellä, jolloin asynkronisuus ja synkronisuus voidaan siirtää kanavan ominaisuuksiksi. Lähettävän automaatin S ja vastaanottavan automaatin R kohtaamisen voidaan sanoa tapahtuvan kanavassa, joka voi olla asynkroninen tai synkroninen. Synkroninen kanava sitoo S:n ja R:n tilasiirtymät samanaikaisiksi. S voi ottaa vastaan uusia syötteitä vasta kun R on ottanut S:n lähettämän tulostuselementin (sanoman) syötteekseen. Asynkroninen kanava sallii S:n tilasiirtymän loppuunsuorituksen heti kun tilasiirtymään liittyvä sanoma on tullut kanavaan. Tämä sanoma on käytettävissä R:n syötteeksi heti kun R on valmis vastaanottamaan syötteitä kanavasta. Asynkronisessa kanavassa elementit etenevät lähettäjältä vastaanottajalle FIFO (first in first out) -periaatteella. Tällainen FIFO -puskuri voidaan tulkita ääretöntilaiseksi automaatiksi α, jolloin puskurissa olevien sanomien lukumäärä määrää α:n tilan. Asynkroninen kanava FIFO-puskuri S α R Synkroniset kanavat Kuva 4.6 Asynkroninen kanava esitettynä FIFO-puskurin ja synkronisten kanavien avulla.

11 Kuvan 4.6 mukaisesti voidaan sanoa, että asynkroninen kanava on itse asiassa FIFO -automaatti α, joka liittyy S:ään ja R:ään synkronisilla kanavilla. Jos α on äärellistilainen, niin S:n ja R:n välinen kanava ei määritelmän mukaan ole synkroninen eikä asynkroninen, vaan välimuoto. Tällöinhän lähettäjä voi joutua odottamaan, että kanavasta vapautuu tilaa, mikä on vastoin asynkronisen lähetyskäytännön periaatetta. Käytännössä tietenkin kanavat ovat äärellistilaisia, ja mikäli halutaan pitää kiinni lähetyksen täydellisestä asynkronisuudesta tapauksessa, jolloin kanavan FIFO on täynnä, on kanavan ominaisuudeksi lisättävä epäluotettavuus: kanava voi hukata sanomat, jotka eivät mahdu puskuriin Järjestelmäarkkitehtuuri Kanavat ovat olioita, joiden avulla toteutetaan automaattien välisiä liitäntöjä. Syntyvää kokonaisuutta kutsutaan järjestelmän arkkitehtuuriksi tai konfiguraatioksi. Automaatti M ja siihen liittyvä kanava α määrittelevät portin p. Ottamalla portti peruselementiksi, voidaan toisaalta kanavat määritellä porttipareina: α = (p 1, p 2 ). M 1 M p 2 1 p 2 α = (p, p ) α = (p, p ) M 3 p p Kuva 4.7 Yksinkertainen järjestelmäarkkitehtuuri CVOPSissa arkkitehtuuri määritellään automaattien (virtuaalitaskien) ja porttien (interface) avulla.

12 5. Siirtokerroksen protokollille tyypillisiä mekanismeja 5.1 Virhekontrolli Virhetodennäköisyydet Tiedonsiirtokanavan laatua voidaan kuvan kanavan bittivirhesuhteella (BER), joka ilmaisee todennäköisyyden sille, että kanavassa kulkeva bitti kääntyy, eli lähetetty nollabitti vastaanotetaan ykkösenä tai päinvastoin. Laatu on suurissa verkoissa yleensä varsin suuresti vaihteleva, riippuen lähinnä siitä, miten vanhaa tekniikkaa verkon vanhimmissa osissa on käytetty. Parhaissa optisissa kuiduissa BER on luokkaa , kun taas puhelinverkon huonokuntoisimmissa osissa BER voi olla niinkin suuri kuin 10-4, ja langattomalla yhteydellä jopa Optisissa kuiduissakin virhesuhde on silti vielä paljon suurempi kuin laitteistojen sisäisissä väylissä ja muisteissa, joissa BER on tyypillisesti pienempi kuin Kanavien virheet eivät yleensä ole tasajakautuneita, vaan impulssikohina, kosketushäiriöt tai esim. inhimilliset virheet tuottavat ns. ryöppyvirheitä. Ollakseen luotettava, BER onkin syytä mitata pitkän ajan keskiarvona. Joskus keskiarvon lisäksi myös hajontaominaisuudet voivat olla tärkeitä. Kanavan laatua voidaan tällöin mitata esim. virheettömien sekuntien (tai muun sopivan aikayksikön) prosenttiosuutena. Yksinkertaisimmassa kanavamallissa virheet ajatellaan tasajakautuneiksi: kunkin bitin virhetodennäköisyys on BER = b (discrete memoryless channel). Tällöin todennäköisyys n:lle perättäiselle virheettömälle bitille on P(EFI n) = (1 - b) n (EFI = Error Free Interval). Niin ollen todennäköisyys sille, että n:n bitin sarjassa on vähintään yksi virhe on 1 - P(EFI n) = 1 - (1 - b) n. Puhelinverkon virhetodennäköisyyksiä mittaamalla on kokeellisesti havaittu, että P(EFI n) e -b(n-1) Näin virheen syntyminen n:n bitin sarjaan on lähinnä Poisson-prosessi, johon päädytään diskreetistä binomijakautumasta pienillä b:n ja suurilla n:n arvoilla Virhetyypit ja virheiden korjaus Kanavan tiedonsiirtoon aiheuttamat virheet voidaan luokitella seuraaviin tyyppeihin: - kehykset, joissa on bittivirheitä, - kehykset, joissa on ylimääräisiä bittejä,

13 - kadonneet kehykset, - ylimääräiset kehykset (yleensä duplikaatit), - väärään järjestykseen joutuneet kehykset. Tässä luvussa tarkastellaan menetelmiä, joilla voidaan vaikuttaa kahteen ensimmäiseen virhetyyppiin, ns. bittivirheisiin. Kolmeen jälkimmäiseen virhetyyppiin soveltuvia menetelmiä käsitellään luvussa 5.2. Virhekontrolli voidaan jakaa kahteen vaiheeseen: virheiden havaitsemiseen ja virheiden korjaukseen. Bittivirheiden havaitseminen perustuu redundanssin lisäämiseen, jolloin kehyksessä kulkee oleellisen informaation lisäksi informaatiota, jota voidaan käyttää sen asian tarkistamiseen, onko informaatio tullut halutussa muodossa perille. Jos redundanssi on tarpeeksi suuri, pystytään vääristynyt informaatio ehkä palauttamaan alkuperäiseen muotoonsa. Mikäli tämä ei ole mahdollista tai kannattavaa, on käytettävä uudelleenlähetystä. Virheenkorjausmenetelmät jakaantuvat näin kahteen luokkaan: - virheenkorjaavien koodien käyttö (forward error control), - uudelleenlähetysten käyttö (feedback error control). Mikään redundanssi ei pysty havaitsemaan kaikkia virheitä. Olkoon f menetelmän havaitsemien virheiden suhteellinen osuus kaikista mahdollisista virheistä, jolloin f < 1. Tällöin havaitsematta jääneiden virheiden todennäköisyys, jäännösvirhesuhde RER (Residual Error Rate) on bittivirhesuhteen BER = b avulla lausuttuna: RER = (1 - f)b. Redundanssin käyttöä varten virheiden havaitsemiseen tarkoitetut koodit ryhmittelevät bitit koodisanoiksi, joissa on databittejä ja koodibittejä. Joissain koodeissa tämä suhde on kiinteä, databittejä d kpl ja koodibittejä e kpl, jolloin koodin hyötysuhde = d/(d + e). Mikäli suhde voi vaihdella, voidaan koodille laskea keskimääräinen hyötysuhde. Jäännösvirhesuhteen pienentäminen pienentää yleensä myös koodin hyötysuhdetta. Virheenkorjaavilla koodeilla hyötysuhde voi olla luokkaa 0.5 tai paljon sitäkin huonompi. Tarkastellaan esimerkkinä virheitä havaitsevasta koodausmenetelmästä pariteettitarkistukseen perustuvaa menetelmää. Siinä koodisana muodostetaan databiteistä d 1,...,d n ja yhdestä koodibitistä, ns. pariteettibitistä p, joka lasketaan kaavalla (parillinen pariteetti): p = (Σ i n= 1 d i ) % 2. Näin taataan, että koodisanassa on aina parillinen määrä ykkösbittejä. Mikäli kanavan bittivirhesuhde on BER = b, niin virheettömänä saapuvan koodisanan todennäköisyys on P(EFI n+1) = (1 - b) n+1. Pariteettitarkistuksella selvästikin havaitaan virheet, joissa pariton määrä bittejä on kääntynyt. Binomijakautuman mukaan täsmälleen k:n virheen todennäköisyys on

14 P(täsm. k kpl virheitä) = [(n+1)!/k!(n - k + 1)!]b k (1 - b) n-k+1. Jäännösvirheiden todennäköisyys on tällöin eli RER = P(väh. 1 virhe) - P(havaitut virheet) RER = 1 - (1 - b) n Σ k n= 1, 3, 5,... P(täsm. k virhettä), Allaoleva kuva havainnollistaa RER:n riippuvuutta bittivirhesuhteesta b tapauksessa, jossa n = 15. On syytä huomata, että kuvassa korostuvat suuret BER:n arvot. Kuva 5.1 Pariteettitarkistukseen perustuva RER BER:n funktiona Virheenkorjaavat koodit Virheiden havaitsemisen lisäksi virheenkorjaavat koodit osaavat paikallistaa koodisanassa olevia virheellisiä bittejä. Koska redundanssin tarve on tällöin suurempi ja koodin hyötysuhde niin ollen pienempi kuin virheitä havaitsevilla koodeilla, virheenkorjaavia koodeja käytetään lähinnä erikoistapauksissa. Tällaisia voivat olla esim. seuraavat tilanteet: - siirtotiellä pitkä viive, - kanava on yksisuuntainen (ei feed-back -mahdollisuutta), - kanavassa suuri BER (uudelleenlähetyksenkin epäonnistuminen todennäköistä). Tarkastellaan esimerkkinä pariteeteista koottua virheenkorjaavaa koodia: 7 bitin ASCII + pariteetti (LRC) + neljän oktetin pystysuora pariteetti (VRC) D = A = T = A = LRC VRC

15 Tämä koodi havaitsee ja korjaa koodisanaan tulleen yhden virheen: ero vastaanotetussa ja lasketussa LRC:ssä identifioi virheellisen rivin ja vastaavasti VRC:n avulla tunnistetaan virheellinen sarake. Koodisanassa on 40 bittiä, joista 28 on databittejä ja 12 koodibittejä, eli hyötysuhde on 28/40 = 0.7. Virheenkorjauksen teoriaa voidaan tutkia ns. Hammingin etäisyyden avulla. Koodisanojen välinen etäisyys voidaan määritellä yksinkertaisesti niiden bittien lukumääräksi, jotka ovat erilaisia ko. sanoissa. Hammingin etäisyys määritellään nyt seuraavasti: Koodin Hammingin etäisyys on pienin etäisyys koodin kuuluvien kahden eri koodisanan välillä. Helposti voidaan todeta, että jos koodin Hammingin etäisyys on n, niin kaikki enintään n - 1 bittivirheen kombinaatiot voidaan havaita koodisanassa, kaikki enintään (n - 1)/2 bittivirheen kombinaatiot voidaan korjata tulkitsemalla virheellinen koodisana lähimmäksi kelvolliseksi koodisanaksi. Yksinkertaisen pariteettitarkistuksen Hammingin etäisyys on 2, kun taas kahdesta pariteetista koostuvassa yllä esitetyssä koodissa Hammingin etäisyys on 4 (tarkista) Sykliseen varmenteeseen (CRC) perustuvat koodit Edellisessä luvussa esitettyjä erityistilanteita lukuunottamatta pääasiallinen menetelmä tietoliikenteessä on virheenhavaitsevien koodien käyttö. Tärkein näistä menetelmistä on sykliseen varmenteeseen (cyclic redundancy check) perustuva menetelmä. Menetelmässä binaarikehyksillä suoritetaan laskutoimituksia, jotka määritellään kuvaamalla kehykset polynomeille. Näiden polynomien kertoimina voivat olla vain luvut nolla ja yksi, joten polynomien laskutoimituksissa noudatetaan modulo 2 -aritmetiikkaa. Perussäännöt ovat siis seuraavat: = 0-0 = = 0-1 = = 1-0 = = 1-1 = 0 Kehysten kuvaaminen polynomeiksi tapahtuu luonnollisella tavalla, esimerkiksi: P = = x 7 + x 6 + x 4 + x 3 + x 2 G = = x 5 + x (x 0 = 1) Polynomeilla ja modulo 2 -aritmetiikalla voidaan suorittaa jakolaskuja, esim.

16 Tässä jakojäännös R = x. Jakolasku P G = x2 + x + x G P - R G = x2 + x menee tasan. Olkoon tehtävänä siirtää bittijono P epäluotettavan kanavan läpi siten, että generoituneet virheet voitaisiin suurella todennäköisyydellä havaita. Syklisen varmenteen idea on seuraava: Valitaan generoiva polynomi G, ja yhdistetään P ja jakolaskun P/G jakojäännös R sanomaksi T siten, että T/G menee tasan. Vastaanottaja voi todeta sanoman virheettömäksi, jos myös hänen laskujensa mukaan T/G menee tasan. Valitsemalla T = P - R saadaan jako T/G menemään tasan, mutta valitettavasti vastaanottaja ei pysty purkamaan sanomasta T varsinaista dataa eli P:tä. Ratkaisu tähän ongelmaan on seuraava: Tehdään tilaa R:lle siirtämällä P r bittiä vasemmalle (r on G:n asteluku), ja määrätään R siten, että R on jakojäännös jakolaskusta Pxr G Asetetaan sitten T = Px r - R. Esimerkissämme on tällöin Px 5 G = x7 + x 6 + x + x3 + x G joten R = x 3 + x = (R:n asteluku on G:n asteluku miinus yksi) ja T =

17 Vastaanottaja pystyy nyt tarkistamaan vastaanotetun T:n jakamalla sen G:llä. Kun virheettömyys on todettu irrotetaan tarkistusosan viisi bittiä, jolloin jäljelle jää varsinainen data: P = Virhe sanomassa T voidaan tulkita polynomiksi E, joka on lisätty sanomaan: vastaanotettu sanoma T' = T + E. Vastaanottaja testaa: T + E G = G T + G E ja huomaa virheen, jos ja vain jos E/G ei mene tasan. Generaattoripolynomin valinnalla voidaan jonkin verran vaikuttaa siihen, millaisia virheitä havaitaan. Tarkastellaan paria esimerkkiä. Esimerkki 1. Jos E koostuu purskeesta, jossa bittivirheet rajoittuvat r:n peräkkäisen bitin alueelle, niin virhe havaitaan aina, mikäli G ei ole tiettyä muotoa. Tällöin nimittäin löytyy luku s ja polynomi E' siten, että E = x s E', missä E':n asteluku on pienempi kuin r. Nyt jakolasku E G = xs E' G voi mennä tasan vain jos G = x r, ja s on r:n monikerta. Valitsemalla G x r voidaan siis taata, että em. jakolasku ei mene tasan. Esimerkki 2. Jos generoiva polynomi G sisältää tekijänä polynomin (x + 1), niin kaikki sellaiset virhepolynomit E, joissa on pariton määrä nollasta poikkeavia kertoimia (ts. T':ssa pariton määrä bitin kääntymisiä) havaitaan. Tämä johtuu siitä, että mielivaltaiselle polynomille P pätee: polynomissa (x + 1)P on parillinen määrä nollasta poikkeavia kertoimia. Tämä väite on helppo todeta paikkansapitäväksi, kun P:n asteluku on 0 tai 1. Induktiolla voidaan suorittaa yleinen todistus, mutta todistus sivuutetaan tässä. Jos nyt siis G = (x + 1)G', ja E/G menee tasan eli virhettä ei havaita, niin myös jako E/(x + 1) menee tasan. Merkitään H = E/(x + 1), jolloin E = (x + 1)H. Mutta tällöin E:ssä täytyy olla parillinen määrä nollasta poikkeavia kertoimia. Yleisesti käytettyjä generoivia polynomeja ovat mm. seuraavat: CRC - 12: x 12 + x 11 + x 3 + x 2 + 1, CRC - CCITT: x 16 + x 12 + x = (x + 1)(x 15 + x 14 + x 13 + x 12 + x 4 + x 3 + x 2 + x + 1), CRC - 16 (IBM): x 16 + x 15 + x 2 + 1, CRC - 32: x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x x 5 + x 4 + x 2 + x + 1. Voidaan yleisesti osoittaa, että jos tarkistussumma on r bittiä, niin todennäköisyys havaitsematta jääneille virheille on luokkaa 2 -r. Kun r = 16, tämä vastaa todennäköisyyttä 10-5 eli näin voidaan parantaa esim. kanava, jossa BER = 10-4 kanavaksi, jossa jäännösvirhesuhde RER on 10-9.

18 5.2 Vuonvalvonta ja virhetoipuminen: johdanto Yksinkertainen stop-and-wait -mekanismi vuonvalvontaan Lähdetään tarkastelemaan siirtoon liittyviä ongelmatilanteita yksi kerrallaan, asteittain. Vuonvalvonnan perustilanne voidaan karakterisoida seuraavasti: 1) siirtotie on täysin virheetön, 2) kanava on kaksisuuntainen, mutta tiedonsiirto tapahtuu vain yhteen suuntaan, 3) vastaanottajan puskuritila on äärellinen, ja siltä menee aikaa saapuvan datan prosessointiin. Oletuksesta 3 seuraa ongelma: miten estetään lähettäjä lähettämästä liian nopeasti? Ratkaisu on kuittaussanomien käyttö: vastaanottaessaan datasanoman eli DATA -PDU:n vastaanottaja lähettää kuittaussanoman eli ACK -PDU:n. DATA -PDU:n lähettäjä joutuu odottamaan ACK -PDU:ta ennenkuin voi lähettää uuden DATA -PDU:n. Protokollamekanismia kutsutaan stop-and-wait -mekanismiksi ja sitä tai sen kehittyneempiä muunnelmia tarvitaan siirtotien laadusta riippumatta yleensä aina kun halutaan varmistautua datan perillemenosta. Vain järjestelmissä, joissa lähettäjä ja vastaanottaja on nopeudeltaan tarkasti sovitettu toisiinsa, tai joissa datan vähäinen katoaminen ei aiheuta ongelmia, kuittauksiin perustuvaa vuonvalvontaa ei tarvita Sanomia kadottavan kanavan ongelma Oletetaan nyt, että edellisen oletuksen 1) sijasta onkin voimassa 1 ) siirtotiellä voi kadota sanomia. Yleensä katoaminen tosin ei ole kovin todennäköistä itse linjalla, vaan katoamiset tapahtuvat prosessoivissa solmuissa esim. juuri vuonvalvonnan laiminlyönnin johdosta. On selvää, että yksinkertainen stop-and-wait ei voi selviytyä tilanteista, joissa esim. DATA -PDU katoaa, koska tällöin protokolla joutuu deadlock -tilanteeseen: lähettäjä ei voi jatkaa, koska ei saa kuittausta, ja vastaanottaja ei voi kuitata, koska ei saa DATA -PDU:ta. Ainoa mahdollinen ratkaisu tähän ongelmaan on ajastimen käyttö. Yksinkertaisinta on, että DATA -PDU:n lähettäjä käynnistää lähetyksen yhteydessä ajastimen, ja ellei kuittausta ole tullut ajastimen säätelemän ajan kuluessa, lähettäjä lähettää edellisen DATA -PDU:n uudelleen.

19 LÄHETTÄJÄ VASTAANOTTAJA DATA ACK DATA ylemmälle kerrokselle TIMEOUT DATA ACK DATA ylemmälle kerrokselle VIRHE! Vastaanottaja luulee saaneensa uuden DATAn, vaikka kyseessä onkin edellisen kopio. Kuva 5.2 Kuittaussanoman katoamisen aiheuttama ongelma Tapaus, jossa kuittaussanoma katoaa, johtaa hiukan monimutkaisempaan tilanteeseen, jota voidaan analysoida kuvan 5.2 sanomakaavion avulla. Ongelman ratkaisu edellyttää selvästi, että vastaanottajan on pystyttävä erottamaan uudelleenlähetykset alkuperäisistä lähetyksistä, jotta se osaisi hylätä jo kertaalleen saamansa sanomat. Yksinkertainen ratkaisu tässä tilanteessa on käyttää erillistä RDATA -PDU:ta uudelleenlähetyksissä. Jatkossa tulemme tarkastelemaan myös toisentyyppistä, PDU:iden järjestysnumerointiin perustuvaa keinoa Sanomia vääristävä ja kadottava kanava: lisää ongelmia Tapaus 1: Esimerkki huonosta spesifikaatiosta Korvataan nyt oletus mahdollisesta sanomien katoamisesta kanavassa mahdollisuudella sanomien vääristymiseen, ts. kanavan BER ei enää ole nolla. Yksinkertaisuuden vuoksi oletetaan kuitenkin aluksi, että sanomat eivät voi kadota. Edelleen oletetaan, että käytössä on virheiden havaitsemiseen kykenevä koodaus, joka leimaa virheellisiksi havaitsemansa sanomat ERR -sanomiksi. Tilanne on nyt aiempaa selvästi mutkikkaampi, ja protokollan suunnitteluun tulee kiinnittää huomiota. Protokollan on kyettävä reagoimaan virheellisiin sanomiin jollakin tavalla; eräs luonnollinen tapa on kuitata ne eri tavalla kuin virheettömät sanomat: käytetään niille NAK -kuittaussanomaa (negative acknowledgement). Järkevä tapa reagoida NAK -PDU:hun on puolestaan lähettää edellinen PDU uudelleen. Edellisen luvun esimerkistä on kuitenkin syytä ottaa oppia sen verran, että uudelleenlähetystä ei suoriteta samalla PDU:lla kuin alkuperäisen lähetystä.

20 Tässä nimittäin kuittauksen katoamista vastaava tilanne on kuittauksen vääristyminen ERR -PDU:ksi. Valitaan käyttöön RDATA -PDU uudelleenlähetyksille. Koska protokolla ei enää ole triviaali, se on syytä spesifioida mallin avulla; käytetään laajennettua äärellistä automaattia toiminnan kuvaamiseen. Tilanteen havainnollistamiseksi asetetaan tehtäväksi seuraavan konkreettisen esimerkin mallintaminen. start dti... b a Buffer CLIENT C C -> S READY ACK NAK ERR PDU:t S -> C DATA RDATA CLOSE ERR next SERVER S Kuva 5.3 Client - Server -järjestelmä Client C hakee joukon tietoyksiköitä Server S:ltä. Tietoyksiköt a,b,c,... ovat valmiina S:n puskurissa, josta ne voidaan siirtää linjalle järjestyksessä. Aiemmat oletukset ovat voimassa, siis 1) sanomia ei katoa, mutta ne voivat vääristyä, 2) DATA -PDU:ita siirretään vain yhteen suuntaan, serveriltä clientille, 3) oikein saapuneet DATA -PDU:t kuitataan ACK -PDU:lla, 4) virheellisinä saapuneet DATA -PDU:t kuitataan NAK -PDU:lla, 5) server vastaa NAK -PDU:hun RDATA -PDU:lla ja 6) server vastaa ERR -PDU:hun RDATA -PDU:lla. Kuvassa 5.3 on esitetty järjestelmän primitiivit ja PDU:t, sekä puskuri ja hakuoperaatio next. Kuvissa 5.4 ja 5.5 on esitetty tila-automaatit graafisina kuvauksina. DATA ACK dti idle start READY open ERR NAK err ERR NAK CLOSE RDATA ACK dti RDATA ACK Kuva 5.4 Clientin tila-automaatti

21 READY ACK & BuffNotEmpty next DATA next DATA idle open NAK RDATA ACK & BuffEmpty CLOSE ERR RDATA Kuva 5.5 Serverin tila-automaatti Myös aloitus- ja lopetustilanteet on otettu mukaan, mutta yksinkertaisuuden vuoksi protokollassa ei ole varauduttu READY ja CLOSE -PDU:iden vääristymisiin. Kohdat 1-6 spesifioivat protokollan varsin hyvin: tila-automaatit on helppo rakentaa. Tämä protokolla vaikuttaa päällisin puolin yksinkertaiselta ja toimivalta ratkaisulta kuvattuun tiedonsiirtotehtävään. Toimintalogiikka on (mukailtuna) peräisin klassisesta esimerkistä [Hol89, s.25-26], joka on ollut aidossa tuotantokäytössä. Järkevyydestään huolimatta protokolla sisältää suunnitteluvirheen, joka eräissä tilanteissa johtaa siihen, että client saa huomaamattaan saman datan kahteen kertaa. Automaattiset välineet protokollien toiminnan validoimiseksi (sen takaamiseksi, että protokolla toimii kaikissa tilanteissa halutulla tavalla ja loogisesti oikein esim. ilman deadlockeja), ovat viime aikoina kehittyneet formaalien spesifikaatioiden yleistymisen myötä. Esimerkki osoittaa, miten helpoiltakin näyttävissä tilanteissa suunnittelijan huomiokyky joutuu kovalle koetuksella, ja näin esimerkin tarkoitus onkin motivoida lukijaa ymmärtämään kehittyneiden suunnittelumenetelmien käytön tarpeellisuus. Tapahtumasarja, joka johtaa virheelliseen toimintaan on kuvattu oheisessa sanomakaaviossa:

22 ACK ERR start C S READY dti(a) DATA (a) ERR RDATA (a) NAK dti(a) RDATA (a) VIRHE! Client ei tiedä saavansa saman datan, jonka on jo kerran saanut. Kuva 5.6 Sanomasekvenssi, joka paljastaa edellä kuvatussa protokollassa olevan virheen Edellä kuvattua virhetilannetta ei ole helppo paikata. Järkevin parannuskeino on luopua erillisen RDATA-PDU:n käytöstä ja pyrkiä datan identifiointiin täsmällisemmin keinoin, esimerkiksi järjestysnumeroinnin avulla. Tähän palataan ikkunoivia mekanismeja käsittelevässä luvussa 5.3. Tapaus 2: Kuittausten sekoittuminen Tarkastellaan jälleen tapausta, jossa sanomat voivat kadota kanavassa. Yllä esitettyyn ja luvussa tarkasteltuun tapaukseen viitaten oletetaan nyt, että DATA- PDU:issa on mukana järjestysnumero, jonka avulla vastaanottaja voi erottaa duplikaatit toisistaan ja havaita kadonneet DATA-PDU:t. Vaikka tilanne vastaanottajan kannalta alkaakin olla tyydyttävässä kunnossa, voidaan vielä helposti kuvitella tapahtumasarja, jossa lähettäjä ja vastaanottaja ajautuvat peruuttamattomalla tavalla erilaiseen näkemykseen tilanteesta. Alla oleva esimerkki kuvaa samaa yksinkertaista perustilannetta kuin kuva 5.2, eikä se liity suoranaisesti yllä kuvattuun client -server -protokollaan. Ongelmiin johtava tapahtumaketju alkaa nyt liian lyhyestä uudelleenlähetysajastimesta, joka ehtii laueta ennen kuin kuittaus ehtii perille. Lähettäjä liittää kuittauksen uudelleenlähettämäänsä DATA(a) -PDU:hun, eikä osaa suhtautua oikealla tavalla seuraavaan kuittaukseen, joka sekin koskee DATA(a):ta, vaan luulee sen

23 tarkoittavan kuittausta DATA(b):hen. Näin lähettäjä lähettää matkaan DATA(c):n, eikä voi ymmärtää DATA(b):n jääneen tulematta perille. Vastaanottaja odottaa kuitenkin DATA(b):tä, jota ei koskaan tule. DATA (a) dti(a) timeout ACK DATA (a) Luulee kuittauksen olevan DATA(b):hen DATA (b) ACK DATA (c) Hylkää datan duplikaattina, lähettää kuittauksen. Hylkää datan, koska huomaa yhden datan puuttuvan välistä. Osapuolilla on täysin erilainen käsitys tilanteesta, toipuminen ei ole mahdollista. Kuva 5.7 Kuittausten sekoittuminen Tämän esimerkin virhetilanne on korjattavissa käyttämällä järjestysnumeroita myös kuittauksissa. Samalla on tärkeä huomata uudelleenlähetysajastimen oikea kesto: liian lyhyt ajastin johtaa tarpeettomiin uudelleenlähetyksiin kuten edellä, liian pitkä ajastin taas hidastaa tarpeettomasti datasiirtoa virhetilanteen sattuessa. Minimiaika koostuu seuraavien vaiheiden yhteenlasketusta kestosta: - DATA -PDU:n siirtoaika vastaanottajalle, - DATA -PDU:n prosessointiaika vastaanottajalla, - kuittauksen siirtoaika lähettäjälle. Koska etenkin pakettikytkentäisissä verkoissa siirtoajat voivat vaihdella huomattavasti verkon kuormituksesta riippuen, uudelleenlähetysajastimien keston määrittäminen on usein vaikeaa. Etenkin nopeissa verkoissa suuriin virhearvioihin ei ole varaa (puskuritilojen täyttyminen lähettäjällä, ym.), jolloin ajastimien arvoista tulee suorituskyvyn kannalta kriittisiä tekijöitä.

24 5.2.3 Pitkän siirtoviiveen ja kanavan käyttöasteen ongelmat Jos siirtoviive on pitkä, tavallinen stop-and-wait -mekanismi hukkaa kanavan kapasiteettia. Tarkastellaan esimerkkinä satelliittikanavaa Suomesta USA:aan: - tiedonsiirtonopeus 64 kbit/s, - käytetään 1000 bitin kehyksiä, - etäisyys n km (satelliitti geostationaarisella radalla), - signaalin nopeus sama kuin valon nopeus, - kuittaus tulee äärijärjestelmältä (satelliitti toimii vain signaalin toistimena). Näistä voidaan laskea, että yhden kehyksen lähetysaika on 1000 bit / bit/s = 15.6 ms, signaalin etenemisviive äärijärjestelmästä toiseen 72000/ s = 240 ms, joten jos kehyksen lähetys aloitetaan hetkellä t = 0, niin kehys on kokonaisuudessaan vastaanotettu hetkellä ms ja lähettäjä saa kuittauksen aikaisintaan hetkellä ms. Tällöin lähettäjä on toimettomana 480/495.6 = 96.8 % ajasta, ja kanavan kapasiteetista vain n. 3 % on hyötykäytössä. Ratkaisuna tähän on sallia lähettäjän lähettää matkaan useampia kehyksiä ennen ensimmäisen kuittauksen tulemista. Myös myöhemmin matkalla olisi aina tietty joukko kehyksiä, joiden kuittaus ei ole vielä saapunut lähettäjälle. Näistä lähetetyistä, mutta kuittaamattomista kehyksistä käytetään nimitystä lähetysikkuna. Optimaalinen lähetysikkunan koko saadaan laskemalla, montako kehystä lähettäjä ehtii lähettää, ennen kuin ensimmäinen kuittaus ehtii perille: W = ms / 15.6 ms/kehys = 31 kehystä. On myös selvää, että kuittausten siirtoon liittyy tehokkuusongelmia, kuittauksethan eivät sisällä hyötydataa. Niiden generointi, lähetys ja vastaanotto ovat protokollan toimintalogiikan kannalta välttämättömiä, mutta käytännössä niiden vaatima kanavakapasiteetti ja käsittelyn overhead olisi minimoitava. Usein etenkin siirtokerroksella datan lähetystarve molempiin suuntiin on ilmeinen, ts. osapuolet ovat toisiinsa nähden enemmän tai vähemmän symmetrisessä suhteessa. Esimerkiksi pitkissä yhteen suuntaan tapahtuvissa tiedostonsiirroissa joutuu kuljetuskerros kuittaamaan saapuneita tiedoston osasia tietyin välein, ja siirtokerroksella tämä näkyy säännöllisin välein vastavirtaan lähetettävänä datana. Kuittausmekanismin yksinkertaistamiseksi voidaan käyttää hyväksi näitä vastavirtaan kulkevia DATA-PDU:ita ja upottaa kuittaukset niihin parametreiksi. Tätä mekanismia kutsutaan nimellä piggybacking eli ratsastus. On kuitenkin selvää, että datan siirtotarve molempiin suuntiin harvoin on täsmälleen saman suuruista, joten tämä mekanismi sopii huonosti stop-and-wait -mekanismiin, koska silloin DATA- PDU:iden pitäisi kulkea puolelta toiselle täsmälleen vuorotahtia. Suurempi joustavuus on siis tarpeen, ja tässäkin ikkunamekanismi osoittautuu joustavaksi ratkaisuksi. Lisäksi kuittausmekanismia voi helposti modifioida siten, että kuitataan useampi sanoma kerralla, jolloin kuittauksia voi lähettää harvemmin. Tällöin tietyn järjestysnumeron sisältävä kuittaus kuittaa myös kaikki sitä aikaisemmin lähetetyt

25 kehykset. On kuitenkin selvää, että kuittausta ei pidä viivästyttää liikaa, koska lähettäjän uudelleenlähetysmekanismi käynnistyy ja idean hyöty menetetään. Jos vastavirtaan kulkevia DATA-PDU:ita, joissa kuittaus voi ratsastaa, ei ilmaannu, on tällöin käytettävä erillistä kuittaus-pdu:ta. 5.3 Vuonvalvonta ja virhetoipuminen: liukuvan ikkunan mekanismit Yleistä Liukuvan ikkunan mekanismi on kehitetty siirtokerroksen vuonvalvonnan ja virhetilanteista toipumisen tarpeisiin. Siinä on pyritty ottamaan huomioon kaikki edellä esitetyt ongelmatilanteet. Lisäksi siinä on varaa tapauskohtaiseen räätälöintiin. Mekanismi perustuu DATA-PDU:iden järjestysnumerointiin. Numeroinnin ei yleensä tarvitse olla yksikäsitteinen, vaan riittää, että käytössä on tietty määrä eri numeroita, esim. 0,1,2,..., MAXSEQ, jolloin numeron MAXSEQ jälkeen aloitetaan jälleen 0:sta. Sanotaan, että kyseessä on tällöin numerointi modulo MAXSEQ+1. Riippuen MAXSEQ:n arvosta järjestysnumero vaatii tietyn määrän bittejä DATA-PDU:n otsikkokentässä. Tyypillisesti MAXSEQ:n arvoksi asetetaankin 2 n - 1 jollekin luvulle n, joista käytetyimpiä ovat arvot n = 3, 5, 8, 16 ja 32. Viimeisin arvo tarkoittaa käytännössä yksikäsitteistä numerointia, sillä MAXSEQ on tällöin yli 4 miljardia. Mekanismin oleelliset käsitteet ovat lähetysikkuna ja vastaanottoikkuna. Lähetysikkuna : lähettäjällä oleva lista lähetetyistä, mutta kuittaamattomista DATA-PDU:ista Vastaanottoikkuna : vastaanottajalla oleva lista järjestysnumeroista, jotka se on valmis hyväksymään. Liukuvan ikkunan mekanismi määrittelee lähetysikkunalle maksimikoon MAX S. Normaalissa toiminnassa lähetysikkuna kasvaa aluksi maksimiarvoonsa, sitten saapuvat kuittauksen pudottavat DATA-PDU:ita pois ikkunan alarajalta mahdollistaen uusien DATA-PDU:iden lähetyksen ikkunan maksimikoon puitteissa, jolloin ikkunan yläraja siirtyy vastaavasti. Tästä nimi liukuva ikkuna. Koska järjestysnumerot kiertävät ympäri, ikkunaa havainnollistetaan usein seuraavanlaisella kuviolla Kuva 5.8 Liukuvassa ikkunassa olevat kehysnumerot

26 Tässä esimerkissä lähetysikkunassa ovat järjestysnumerot 2, 3 ja 4. Lähettäjän on pidettävä kuittaamattomat DATA-PDU:t puskurissaan mahdollista uudelleenlähetystä varten. Puskuritilaa tarvitaan enimmillään MAX S DATA-PDU:ta varten. Vastaanottoikkuna edustaa järjestysnumeroita, jotka vastaanottaja on valmis hyväksymään, muilla numeroilla varustetut PDU:t se hylkää. Vastaanottoikkunan koko voidaan tietyissä rajoissa asettaa lähetysikkunan koosta riippumattomasti. Puskuritilaa vastaanottaja tarvitsee enimmillään vastaanottoikkunan koon MAX R verran, sillä saapuvat PDU:t on annettava ylöspäin käyttäjälle numerojärjestyksessä. Väärässä järjestyksessä tulleet PDU:t on niin ollen puskuroitava, kunnes puuttuvat numerot ovat tulleet. Mikäli lähetysikkunan maksimikoko ja vastaanottoikkuna yhteensä ovat niin suuret, että ne voivat kattaa suuremman alueen kuin mitä erilaisia kehysnumeroita on olemassa, voi seurauksena olla vaikeasti havaittavia virhetilanteita. Yleissääntönä voidaan pitää : Lähetysikkunan maksimikoko + vastaanottoikkunan koko MAXSEQ + 1 Sanomakaaviot, jotka valaisevat yllä olevan säännön tärkeyttä, on esitetty liitteessä 1. Tarkastellaan seuraavassa PDU:n katoamisen tai vääristymisen aiheuttamia toipumismekanismeja. Oletetaan, että lähetysikkunan maksimikoko MAX S = W. Toipumismekanismit voidaan jaotella sen mukaan, onko vastaanottoikkunan koko yksi vai suurempi kuin yksi Toipuminen PDU:iden katoamisesta - Go-Back-N ARQ Jos vastaanottoikkunan koko on yksi, vastaanottaja ei hyväksy saapuvia PDU:ita elleivät ne tule järjestyksessä. Jos siis yksi DATA-PDU katoaa matkalla, vastaanottaja hylkää kaikki myöhemmin lähetetyt PDU:t, jotka on lähetetty ennen kuin lähetysikkuna on täyttynyt. Vastaanottajalle tämä menetelmä on yksinkertainen, koska puskuritilaa ei tarvita. Lähettäjä tietää myös, että mikäli kuittausta ikkunan alarajalla olevalle PDU:lle ei tule, kaikki sen jälkeen lähetetyt PDU:t on lähetettävä uudelleen. Näin lähettäjälle riittää vain yksi ajastin, joka käynnistetään aina kun ikkunan alaraja siirtyy. Kun ajastin laukeaa, koko ikkunallinen PDU:ita lähetetään uudestaan. Tästä nimi Go-Back-N. Lyhenne ARQ tulee sanoista automatic repeat request. Oheinen kuva havainnollistaa tilannetta

27 DATA (0) DATA (1) DATA (2) ACK (0) ACK (1) DATA (4) DATA (3) DATA (5) DATA (6) DATA (7) timeout DATA (2) DATA (3) DATA (4) DATA (5) DATA (6) ACK (2) ACK (3) ACK (4) ACK (5) Kuva 5.9 Go-back-N Automatic Repeat Reequest (ARQ) Toipuminen PDU:iden katoamisesta - Selective Repeat Jos vastaanottoikkunan koko on suurempi kuin yksi, yhden kehyksen katoaminen ei välttämättä edellytä seuraavien kehysten uudelleenlähetystä. Mikäli ne ovat saapuneet virheettöminä vastaanottajalle, niin vastaanottaja on puskuroinut niistä ne, jotka ovat mahtuneet vastaanottoikkunaan. Kadonnut tai virheellisenä saapunut kehys jää vastaanottoikkunan alarajalle, eikä vastaanottoikkuna enää siirry ennenkuin puuttuva kehys on vastaanotettu. Lähettäjän päässä kadonnut kehys on jäänyt lähetysikkunan alarajalle. Uudelleenlähetysmekanismin käynnistyessä ajastimen lauettua lähettäjän ei tässä tilanteessa kannata lähettää seuraavia uudelleen. Järkevää yleensä onkin odottaa, tulisiko seuraavassa kuittauksessa ilmoitus, että koko ikkunallinen tai ainakin osa siitä on otettu virheettöminä vastaan.

28 Kuva 5.10 Selective repeat Ajastimen oikea ajoitus voi olla pulmallista etenkin, jos siirtoviive on pitkä. Kanavalle tulee nimittäin tyhjäkäyntiä, jos kuitenkin osoittautuu, että seuraavakin kehys pitää lähettää uudelleen. Siksi kompromissina voi olla esim. edellä olevan kuvan 5.10 tilanne, jossa kadonnutta kehystä seuraavakin kehyksen uudelleenlähetysajastin ehtii laueta, ennenkuin kuittaus koko ikkunallisen vastaanotosta saapuu lähettäjälle. Sitten voidaan siirtyä kokonaan uusien kehysten lähetykseen. Aikaa edelliseen Go-Back-N -mekanismiin verrattuna säästyy selvästi Toipuminen PDU:iden katoamisesta - Negative Acknowledgement Liukuvan ikkunan protokollassa voi uudelleenlähetysajastimeen perustuva toipumismekanismi aiheuttaa tarpeetonta viivettä. Näin erityisesti silloin, kun vastaanottaja kuittaa harvakseen, useita kehyksiä kerralla. Tehokkuutta voidaan lisätä ottamalla käyttöön ns. negatiivinen kuittaus NAK, jonka vastaanottaja lähettää havaitessaan virheellisen kehyksen tai yhden järjestysnumeron jääneen välistä pois. NAK varustetaan tällöin sen kehyksen järjestysnumerolla joka oli virheellinen tai ei tullut ajallaan. DATA (1) DATA (2) DATA (4) DATA (5) DATA (0) ACK (0) ACK (1) DATA (3) NAK (2) Vastaanottaja lähettää NAK:n, koska DATA (2) jäi saapumatta. Se voi lähettää uuden NAK:n vasta kun DATA (2) on saapunut. Lähettäjä havaitsee, että DATA (2) on lähetettävä uudelleen. Se jatkaa sitten (optimistisesti) siitä mihin jäikin. DATA (2) DATA (6) DATA (7) NAK (4) NAK (4) kuittaa DATA (3):n ja DATA (2):n saapuneiksi. Nyt lähettäjä tietää, että DATA (4) on myös lähetettävä uudelleen. DATA (4) DATA (0) DATA (1) DATA (2) ACK (7) Vastaanottaja voi nyt kuitata numeroon 7 asti ja tilanne jatkuu normaalin ikkunamekanismin puitteissa. Kuva 5.11 Negative Acknowledgement Jos vastaanottoikkunan koko on yksi, lähettäjän tulee NAK:n saatuaan lähettää uudelleen kaikki kehykset NAK:ssa mainitusta järjestysnumerosta alkaen. Mikäli vastaanottoikkuna on suurempi kuin yksi, lähettäjä voi tyytyä lähettämään vain

29 mainitun kehyksen, ja uudelleenlähetysajastin tai uusi NAK ilmoittaa, mikäli seuraavien kehysten vastaanotossa on ollut häiriöitä. Mikäli pidetään kiinni periaatteesta, että NAK:ssa tullut järjestysnumero N kuittaa kaikki sitä edeltävät kehykset, on vastaanottajan kannalta riskialtista lähettää uutta NAK:ia esim. järjestysnumerolla N+2 ennenkuin kehys N on tullut virheettömänä perille. Mikäli näin tehdään, niin lähettäjä kuvittelee saadessaan NAK:n, jossa on numero N+2, että hänen uudelleenlähettämänsä kehys numero N on mennyt virheettömänä perille, vaikka vastaanottaja ei ole vielä ko. kehystä saanutkaan lähettäessään jälkimmäisen NAK:n. Se, että NAK:eja voi olla kerrallaan liikenteessä vain yksi, tekee uudelleenlähetysajastimeen perustuvista toipumismekanismeista lähes samanarvoisia NAK:iin perustuvien mekanismien kanssa. Ajallinen etu, joka NAK:lla saavutetaan joudutaan maksamaan monimutkaisemman toimintalogiikan muodossa.

30 Luku 6 puuttuu tarkoituksellisesti

31 7. Kuljetuskerros 7.1 Kuljetuskerroksen tehtävät ja protokollaluokat Kuljetusyhteyttä voidaan luonnehtia termeillä päästä - päähän -yhteys sekä bittiputki (bitpipe). Edellinen termi korostaa kuljetuskerroksen roolia kahden äärijärjestelmän yhdistämisessä. Bittiputkeen liitetään lisäksi ominaisuudet luotettava ja läpinäkyvä. Luotettavuudella tarkoitetaan sitä, että viimeistään kuljetuskerros suorittaa tietynasteiset tarkistukset ja toipumistoimet bittivirheiden ja kadonneiden tai epäjärjestykseen joutuneiden sanomien osalta. Luotettavuus ei välttämättä tarkoita sitä, että ylemmillä kerroksilla ei enää tarvita minkäänlaisia virheentarkistus- tai toipumismekanismeja, vaan siellä voidaan joutua huolehtimaan toisentyyppisistä ilmiöistä, esim. siitä, onko sovellusolio onnistunut tallettamaan saamansa tiedot levylle. Tällaiset asiat eivät koske kuljetuskerrosta. Läpinäkyvyydellä puolestaan tarkoitetaan sitä, että kuljetuspalvelun kautta kuljetuskerroksen siirrettäväksi annettu data saa sisältää millaisia bittikuvioita hyvänsä. Tätä ominaisuutta halutaan sen itsestäänselvyydestä huolimatta korostaa, koska eräät vanhemmat järjestelmät, esim. aikaisempi digitaalinen T1 -palvelu USA:ssa, eivät sallineet tiettyjen verkon sisäiseen merkinantoon käytettyjen oktettien esiintymistä datan joukossa. Kuljetuskerroksen tulisi myös toipua verkkokerroksen signaloimista virheistä (Reseteistä) sekä mahdollisuuksien mukaan yrittää avata uudelleen poikki menneet verkkoyhteydet ilman, että kuljetuspalvelun käyttäjä tulee tietoiseksi yhteyskatkoista. Lisäksi kuljetuskerros voi tarjota useiden kuljetusyhteyksien limitystä yhdelle verkkoyhteydelle tai yhteydettömän verkkopalvelun päälle. Jotta kuljetuskerros voisi joustavasti mukautua erilaatuisten verkkoyhteyksien hyväksikäyttöön, standardoijat ovat määritelleet kuljetuskerrokselle useita vaihtoehtoisia toimintokokonaisuuksia, ns. protokollaluokkia. Näin voidaan keventää kuljetuskerroksen protokollaa, mikäli alemmat kerrokset huolehtivat esim. luotettavuudesta tai multipleksauksesta eli limityksestä. Toisaalta tilanteessa, jossa alemmat kerrokset eivät takaa virheetöntä siirtoa, kuljetuskerroksen protokollasta tulee monipuolinen ja myös raskas (ja kallis). Toimintojen tarkastelua varten verkkoyhteydet jaetaan yleensä kolmeen tyyppiin, A, B ja C: tyyppi A tyyppi B tyyppi C luotettavat verkkoyhteydet, joissa bittivirheiden todennäköisyys on erittäin pieni ja joissa verkon toimintahäiriöitä (N-RESET) ei esiinny, virheistä ilmoittavat verkkoyhteydet, joissa paketit ovat perille tullessaan virheettömiä, mutta verkko voi silloin tällöin kaatua, eli N-RESET:tejä esiintyy, epäluotettava verkkoyhteys, jossa paketit voivat kadota, kahdentua ja korruptoitua, ja N-RESET:tejä esiintyy.