Reteaua Token Bus si standardul ieee 802

Reteaua Token Bus si standardul IEEE 802.4
Standardul IEEE 802.4, a fost publicat de IEEE la mijlocul anilor ’80, si a fost sustinut de companii precum gigantul General Motors, interesate in domeniul automatizarii fabricatiei (protocolul definit de standardul 802.4 intra in categoria MAP - Manufacturing Automation Protocol).

El a fost construit ca o reactie la standardul 802.3, aplicat cu succes in activitatile de proiectare si de birou (acesta intra in categoria TOP - Technical and Office Protocol), dar total impropriu folosirii pentru automatizarea proceselor industriale, prin faptul ca nu prevede cadre prioritare si nu ofera o determinare a timpilor de asteptare pentru accesul la mediu (protocolul este nedeterminist, cazul cel mai defavorabil nu poate fi estimat printr-o valoare de maxim). In replica, comitetul de lucru pentru dezvoltarea standardului 802.4 a propus o retea cu o topologie liniara, de tip magistrala (bus), cea mai adecvata controlului automat al unei linii de productie, permitand deasemenea implementarea unui sistem de prioritati pentru statiile conectate si prezentand o comportare determinista, accesul la mediu fiind facut printr-o metoda bazata pe jeton (token), lucru ce da posibilitatea estimarii cazului cel mai defavorabil pentru accesul la mediu.

Precum celelalte protocoale 802.x, ilustrate de figura ... , protocolul 802.4 este un protocol la nivelul accesului la mediu, avand deasupra, in stiva de protocoale, protocolul LLC definit de standardul IEEE 802.2, iar la nivelul fizic bazandu-se pe transmisia analogica (in banda larga), utilizand cablu coaxial CATV. Este si acesta unul dintre motivele pentru care retelele Token Bus nu mai corespund performantelor cerute actualmente.

Daca fizic, cablul folosit, la care sunt atasate statiile, este configurat liniar sau arborescent, din punct de vedere logic statiile sunt organizate intr-un inel, in care circula tokenul intr-o anumita directie (vezi figura ...). Fiecare statie cunoaste adresele statiilor din aval si amonte, sau de la stanga si dreapta sa. Dintre statii, la initializare, una este cea care genereaza tokenul, si anume cea cu adresa superioara. Accesul la mediu este fara coliziune, deoarece la un moment dat doar o statie din retea detine tokenul, si deci poate transmite. Mediul fiind de tip broadcast, utilizat (impartit) de toate statiile, fiecare statie receptioneaza fiecare cadru din mediu, procesand doar cele care ii sunt adresate. Reteaua opereaza la viteze de 1, 5 sau 10Mbps.

La nivelul fizic, o retea Token Bus se bazeaza pe cablul coaxial CATV, cu impedanta de 75, folosit pentru pentru transmisii analogice (cablul obisnuit pentru televiziunea prin cablu). Ca arhitectura este posibila implementarea arborelui, cu sau fara nod de capat (headend), fie in sistem cu cablu simplu, fie cu cablu dual. Pentru modularea semnalului se folosesc diferite tehnici, variante specializate ale modularii prin deplasare in frecventa (FSK), sau deplasare in faza (PSK), precum: modularea in frecventa cu faza continua, modularea in frecventa cu faza coerenta si modularea in faza cu amplitudine multinivel. Prin aceste tehnici se moduleaza nu numai simbolurile de date, sau simbolul ‘idle’, dar si altele necesare in gestionarea si controlul retelei. Prin toate acestea, nivelul fizic al retelei 802.4 este total incompatibil cu cel al unei retele 802.3, si chiar mai complicat.

La nivelul controlului accesului la mediu, este implementat protocolul Token Bus. Este un protocol de tip token passing, accesul la mediu facandu-se fara disputa (contention free), spre deosebire de algoritmul utilizat de 802.3. Accesul la mediu pentru transmisie, al unei statii, se face pe baza detinerii tokenului (un cadru special de control) care, la terminarea operatiei, este transmis in retea pentru a fi ‘achizitionat’ de alta statie. Singura actiune unde poate interveni disputa intre statii este inserarea in retea, rezolvarea bazandu-se pe un algoritm de regresie binara.

Token Bus este un protocol complex, prevazand multe sarcini (functii) pentru fiecare statie, implementarea sa cerand gestionarea unui numar important de timere si variabile interne.

Elementele principiale de baza ale protocolului de acces sunt urmatoarele:

- la initializare, statiile sunt introduse in inel in ordinea adreselor lor, de la adresele superioare catre cele inferioare

- in inel, tokenul unic circula de la statiile cu adrese superioare, catre cele cu adrese inferioare (aceasta da ordinea in care statiile pot accesa mediul)

- organizarea logica a inelului (ordinea statiilor in inel) este aceeasi pe tot parcursul operarii, de unde rezulta algoritmi specifici pentru inserarea de noi statii in inel sau pentru scoaterea unor statii din inel

- fiecare statie gestioneaza patru nivele de prioritate, creand intern patru fire de asteptare pentru transmisie, conform prioritatii cadrului ce trebuie transmis; schema de prioritati permite alocarea catre un nivel de prioritate a unei portiuni din banda de frecvente, lucru ce faciliteaza implementarea traficului de timp real

- fiecare statie pastreaza informatii despre statiile vecine, pe care le actualizeaza periodic; ele stau la baza unor operatii de intretinere ale inelului logic

- in retea controlul este distribuit, temporizarea necesara accesului si intretinerii retelei se realizeaza prin implementarea unui numar considerabil de timere (complexitatea algoritmilor folositi si dificultatea implementarii constituie un dezavantaj major al retelei 802.4).
Formatul cadrului 802.4 Token Bus este ilustrat de figura ...
Octeti  1 1 1 2/6 2/6 0 - 8182 4 1

Preambul

SD

FC

SA

DA

Info

FCS

ED

Campul Preambul este folosit pentru sincronizarea ceasului statiei (statiilor) receptoare a cadrului, avand insa o lungime mult mai mica dacat la 802.3 (poate fi doar un octet).

Campurile SD (Start Delimiter) si ED (End Delimiter), sunt folosite pentru a marca clar inceputul si sfarsitul cadrului. Pentru aceasta ele au in componenta, la fel ca la protocolul 802.5, simboluri non-data, cu o codificare diferita de codificarea pentru bitii de date 0 si 1. In acest fel nu mai este necesara prezenta in cadru a unui camp de lungime, pentru a evidentia clar lungimea campului Info (campul de date ).

Campul FC (Frame Control) este folosit pentru identificarea cadrelor de control.

Cadrele de control sunt prezentate de tabelul ... si rolul lor este ilustrat la prezentarea metodei de acces la mediu si a functiilor de intretinere si control a magistralei.

Daca cadrul este pentru date, acest camp transporta prioritatea asociata respectivului cadru.

Campurile SA (Source Address) si DA (Destination Address) au o lungime (2 sau 6 octeti) si structura (biti pentru adresare locala/globala, adresare individuala/grup) identice cu cele folosite de protocolul 802.3.

Campul de date propriu-zis, numit Info, poate avea o lungime de pana la 8182 octeti, daca se foloseste adresarea cu adrese pe 2 octeti, sau pana la 8174 octeti, la o adresare pe 6 octeti. Este o lungime considerabila a campului de date, de peste cinci ori lungimea maxim posibila pentru campul de date din cadrul 802.3 (aceasta este posibil pentru ca metoda de acces la mediu aferenta protocolului Token Bus foloseste timere pentru limitarea timpului de detinere a jetonului, si nu este necesar sa limiteze drastic lungimea cadrului, pentru a limita timpul de acces la mediu, precum este cazul la retelele 802.3).

Campul pentru controlul erorii FCS (Frame Control Sequence) de 4 octeti, foloseste acelasi polinom generator CRC ca si standardul 802.3.

Cod cadru	Nume cadru
00000000	Claim_token
00000001	Solicit_succesor_1
00000010	Solicit_succesor_2
00000011	Who_follows
00000100	Resolve_contention
00001000	Token
00001100	Set_succesor

Operatiunile de control in retea

Operatiunile de control si intretinere ale retelei se desfasoara pe baza cadrelor de control prezentate mai sus. Dintre aceste cadre de control, cel mai utilizat (si deja prezentat) este cadrul Token, ce implementeaza conceptul de token, elementul cheie al algoritmului de acces la mediu.
Initializarea retelei
La initializare, cazul cel mai simplu este cand o singura statie devine activa. Aceasta constata ca este singura in inel, prin detectarea lipsei de trafic in retea. Ea va genera un cadru de control, numit Claim_token, prin care solicita token. Neavand competitori pentru dobandirea tokenului, la revenirea inapoi a cadrului Claim_token, ea va crea un token (va genera un cadru Token) si-l va trimite in retea. Periodic, cu o perioada data de un timer specific, statia va solicita altor statii intrarea in retea, prin permisiunea unei sesiuni de inserare in retea, sesiune bazata pe competitie (bid session), intre ‘ofertele’ existente (o singura statie este inserata la un moment dat) . Pe masura ce alte statii devin active, ele vor putea fi inserate in retea, dupa un algoritm ce va fi decris mai jos.

Daca la initializare, doua sau mai multe statii devin simultan active (sunt startate simultan), procesul de alegere a primei statii din inelul logic (cea care va genera tokenul) decurge dupa acelasi algoritm de licitare bazat pe regresia binara.

De fapt initializarea este un caz particular al procesului de adaugare in inel a unei noi statii, proces ce este prezentat in continuare.


Inserarea in retea a unei noi statii
Odata ce inelul a fost creat, fiecare statie ce se afla in inel desfasoara continuu activitati de gestionare a inelului. Pentru aceasta, fiecare statie va avea memorate adresele statiilor vecine, din ‘dreapta’ si ‘stanga’ sa, dupa cum este sensul de parcurgere a retelei de catre token (figura ... de la inceput). Pentru a permite inserarea de noi statii in retea, cu pastrarea ordinii logice in inel, se va emite periodic, de catre fiecare statie activa din retea, in momentul cand detine tokenul, cate un cadru de control de tip Solicit_succesor_1. De remarcat ca ordinea statiilor in inelul logic nu corespunde in mod necesar cu ordinea fizica a amplasarii statiilor (conectarea lor la cablu). Aceasta se datoreaza faptului ca mediul de comunicatie este unul de tip broadcast, fiecare statie va receptiona fiecare cadru ce circula in retea si va procesa doar pe acelea care ii sunt destinate.

Cadrul de tip Solicit_succesor_1, emis de o statie activa detinatoare a tokenului, la anumite momente de timp, date de un timer specific, contine atat adresa proprie cat si adresa statiei succesoare. Daca intr-un timp anumit, dat de un timer, timp ce depinde de lungimea cablului, statia nu primeste inapoi cadrul modificat, semn al existentei unei statii ce doreste inserarea si s-a introdus in retea, ea va continua activitatile normale de transmisie sau de transmitere a tokenului.

Daca o statie care asteapta sa fie inserata in inel, determina ca adresa sa logica se incadreaza in intervalul stabilit de cele doua adrese din cadrul Solicit_succesor_1, acum poate sa o faca, dupa o modalitate simpla, si anume prin setarea sa ca statie succesoare a statiei detinatoare a tokenului.

Daca insa sunt mai multe statii care asteapta inserarea si au adresele in acest interval, se va declansa un proces de alegere bazat pe ‘oferta’ (bid) fiecarei statii, doar una fiind castigatoarea care va fi inserata la acel moment (va fi succesorul statiei detinatoare a tokenului).

Existenta mai multor statii care cer inserarea in inel este dedusa de statia care a initiat procesul de inserare printr-un proces electric, datorat coliziunii cadrelor modificate Solicit_succesor_1, emise de statii, de pe urma auto-setarii lor ca statii succesoare. Statia detinatoare a tokenului va genera acum un cadru de control de tip Resolve_contention, generandu-se un proces de alegere bazat pe un algoritm cu regresie liniara. In acest sens fiecare statie are implementata in interfata pentru acces la retea, un mecanism de generare a unei valori aleatoare, intre 0 si 3. Valoarea aleatoare este generata la fiecare folosire, sau in mod periodic, pentru a nu fi dezavantajata nici o statie. Aceasta valoare va determina un interval de intarziere pentru ofertare, deci sansa ca doua statii sa doreasca inserare simultan (ca raspuns la acelasi cadru de solicitare succesor) este redusa. In acest mod este foarte probabil ca o singura statie sa solicite inserare, actionand asupra cadrului si setandu-si adresa.

Pentru a se asigura o viteza de transmisie optima, sau un timp prevazut de parcurgere a inelului, initierea unui proces de inserare nu se face in mod necesar periodic, ci depinde de incarcarea actuala a retelei.

Excluderea unei statii din inel se face simplu, dupa modelul listelor inlantuite, pe baza adreselor statiilor predecesoare (fie ea ‘adr_P’) si succesoare (fie adresa sa ‘adr_S’) ale statiei care doreste excluderea (cu adresa ‘adr_A’). In acest sens, statia care doreste excluderea sa din inel va trimite catre statia predecesoare, cu adresa ‘adr_P’, un cadru Set_succesor, anuntand-o ca nu ea constituie succesorul, ci statia sa succesoare, deci va fi setata in campul respectiv adresa ‘adr_S’.
Operatii de intretinere a inelului
Problemele de intretinere ale integritatii inelului logic si ale tokenului sunt rezolvate tot in mod distribuit, prin intermediul altor cadre de control.

Astfel, la caderea unei statii, inactivitatea sa este depistata de statia sa predecesoare, in momentul pasarii tokenului. Statia care a detinut tokenul si il paseaza acum statiei sale succesoare (statia inactiva), va intra intr-un proces de ‘ascultare’, determinand daca succesorul sau transmite date sau transmite mai departe tokenul. Daca dupa un timp determinat, statia care asculta nu sesizeaza acest lucru, va transmite un nou token. Daca nici la acesta nu observa replica, va transmite in inel un cadru special, numit Who_follows, cadru ce contine adresa statiei succesoare (statia inactiva). Statia succesoare a statiei inactive, la receptia cadrului Who_follows, va modifica campul cu adresa statiei succesoare, setand acolo propria adresa, in acest fel statia inactiva fiind eliminata din inel.

Daca defectul este mai grav, afectand doua sau mai multe statii, statia care a detinut tokenul neputand localiza un alt eventual succesor, ea va lansa un cadru de tip Solicit_succesor_2, care determina daca exista statii active; in acelasi timp se lanseaza procesul de permitere a unei inserari. Deseori este insa necesara reinitializarea retelei.

Daca eroarea afecteaza tokenul, pot exista cazurile de pierdere a tokenului sau de tokene multiple in retea.

In primul caz, la disparitia tokenului din retea, fiecare statie activa are implementat un timer pentru durata maxima de asteptare a unui cadru, sau a unui token. La expirarea timpului de asteptare, ea va genera un cadru Claim_token, care va declansa procesul de alegere a statiei detinatoare a tokenului (initializare), dupa algoritmul de regresie binara cu doi biti aleatori.

Problema tokenelor multiple se rezolva in modul urmator: daca o statie care detine tokenul sesizeaza o transmisie a altei statii, va scoate tokenul propriu din inel. Daca exista in continuare tokene multiple, fiecare statie detinatoare de token care sesizeaza transmisie a altei statii, isi va elimina tokenul din retea.

Standardul IEEE 802.4 este actualmente in declin, pe de-o parte datorita minusurilor proprii (transmisie analogica si amplificatoare analogice pretentioase, complexitatea protocolului, comportare slaba pentru incarcare redusa a retelei), dar si pentru ca este impropriu utilizarii la nivel fizic a unor medii de transmisie rapide, precum fibra optica.