ANMMA un blog despre Retele radio ad-hoc; management retea; agenti mobili

Wednesday, March 29, 2006

Modele teoretice pentru mobilitate in retele ad-hoc

  • miscari independente ale nodurilor
    • Random Walk Mobility Model (miscarea browniana)
      un nod aflat intr-o locatie se va deplasa catre urmatoarea locatie cu o viteza aleasa aleator in intervalul [vmin , vmax] cu sensul ales aleator in intervalul [0 , 2 π]. Fiecare miscare are loc fie intr-un timp constant t fie se parcurge un spatiu d. La atingerea limitelor domeniului spatial are loc o reflexie.
      intr-un spatiu bidimensional reintoarcerea la locatia initiala are intotdeauna loc
      are dezavantajul ca pot aparea miscari ipotetice cum ar fi opriri bruste sau intoarceri scurte
    • Random Waypoint Mobility Model
      se alege aleator un punct in spatiul de simulare, noua destinatie, iar viteza este uniform distribuita pe [vmin , vmax], dupa sosirea la destinatie se face o pauza dupa care se reia miscarea cu alt punct destinatie si alta viteza
      prezinta o problema: la initializare numarul de noduri vecine unui nod ales este mult diferita fata de media obtinuta pe durata simularii. Nodurile vecine sunt acele noduri care se afla in aria de acoperire a nodului selectat
    • Random Direction Mobility Model
      se alege aleator un sens de miscare si o viteza, ca la Random Walk Mobility Model, si se continua miscarea pana la sosirea pe frontiera spatiului de simulare, moment in care nodul se operste pentru un timp si apoi se reia miscarea cu alt sens si alta viteza
    • Boundless Simulation Area Mobility Model
      se realizeaza o discretizare cu pasul Δt astfel ca:
        viteza la momentul t+Δt
      • v( t + Δt) = min ( max( v(t) + Δv , 0 ) , vmax )
      • θ( t + Δt ) = θ(t) + Δθ
        pozitia la momentul t+Δt
      • x( t + Δt) = x(t) + v(t) * cos θ(t)
      • y( t + Δt) = y(t) + v(t) * cos θ(t)
        unde
      • vmax este o constanta fixata, viteaza maxima
      • a este o constanta fixata, acceleratia
      • α este o constanta fixata, modificarea maxima de directie
      • Δv uniform distribuita pe [ - a * Δt , a * Δt }
      • Δθ uniform distribuita pe [ - α * Δt , α * Δt }
      La sosirea pe frontiera, nodul nu este nici reflectat si nici nu se opreste, nodul isi continua miscarea reintrand in spatiul de simulare intr-un alt punct al frontierei, simetricul fata de centrul spatiului de simulare
    • Gauss-Markov Mobility Model
    • A Probabilistic Version of the Random Walk Mobility Model
    • City Section Mobility Model
  • miscari corelate ale nodurilor
    • Exponential Correlated Random Mobility Model
    • Reference Point Group Mobility Model
      se compune o miscare, aleatoare sau dupa o lege, a centrului grupului cu miscarile relative ale nodurilor fata de acesta
      miscarea relativa a nodurilor se defineste astfel incat nodurile sunt uniform distribuite intr-o vecinatate a centrului
      • In-place mobility model: fiecare grup se misca intr-un singur subspatiu al spatiului de simulare
      • Overlap mobility model: grupurile se misca in intreg spaitul de simulare dar miscarile centrelor sunt diferite
      • Convention mobility model: grupurile au miscarile cenrelor similare dar se misca in subspatii diferite
      • cazuri particulare RPGM
      • Column Mobility Model
        fiecare nod are propriul punct de referinta
        punctele de referinta ale nodurilor se afla pe o dreapta
        punctele de referinta nu au miscare relativa fata de punctul de referinta al grupului
        miscarea relativa, fata de propriul punct de referinta, a unui nod se realizeaza conform unui model de mobilitate independenta
      • Nomadic Community Mobility Model
        miscarile relative, fata de centrul de referinta al nodului, ale nodurilor au loc dupa un model de mobilitate independenta
      • Pursue Mobility Model
A Survey of Mobility Models for Ad Hoc Network Research

Tuesday, March 28, 2006

Intro. agenti

  • agent
      Definitia lui Ferber
      o entitate fizica sau virtuala caracterizata astfel:
    • are capacitatea sa actioneze intr-un ambient
    • poate comunica cu alti agenti
    • este guvernat conform unor scopuri, obiective individuale sau unei functii de existenta/satisfactie pe care incearca sa o optimizeze
    • poseda propriile resurse
    • este capabil sa perceapa ambientul cu anumite limitari
    • are o reprezentare partiala a propriului ambient
    • are anumite caracteristici si poate oferi servicii
    • este capabil de autoreproducere
    • are un comportament orientat catre satisfacerea obiectivelor proprii si tine cont de resursele disponibile, de capacitatile sale, de perceptia si comunicarile pe care le realizeaza
  • sisteme multi-agent, SMA
      un sistem caracterizat prin:
    • un ambient S, un spatiu care are volum
    • o multime de obiecte, O, pozitionate in spatiul S
    • un grup de agenti, A, si care reprezinta entitatile active in sistem care sunt asociati multimii O,
    • o multime, R, de relatii intre elementele lui A
    • o multime de operatii, Op, pe care agentii, elementele lui A, le pot realiza asupra obiectelor, elementele lui O
    • o multime de operatori, legile universului, care reprezinta aplicarea operatiilor, Op, si reactiunea universului la acestea
  • agent de comunicare
      o entitate de calcul cu proprietatile:
    • este un sistem deschis
    • poate comunica cu alti agenti
    • este guvernat de obiective proprii
    • poseda resurse proprii
    • are o reprezentare partiala a celorlati agenti
    • are niste capacitati, servicii, pe care le poate oferi altor agenti
    • are un comportament orientat catre indeplinirea obiectivelor proprii in baza resurselor si capacitatilor proprii si in baza reprezentarilor si a comunicarilor pe care le face
  • Lange si Oshima
      o entitate software care
    • se gaseste intr-un mediu de executie
    • are, in mod obligatoriu, urmatoarele proprietati
      • reactioneaza la modificarile mediului
      • are autocontrol asupra propriilor actiuni
      • are initiativa in indeplinirea obiectivelor
      • ruleaza in mod continuu intr-un continuu temporal
    • are, in mod facultativ, urmatoarele proprietati
      • este capabil de comunicare cu alti agenti (comunicare)
      • este mobil, putand calatori de la un host la altul (mobilitate)
      • se adapteaza in baza experientei (invatare)
      • are convingeri, propria reprezentare a mediului
    • Lange si Oshima, Motive agenti mobili
      • reduc incarcarea retelei; aplicatiile de retea conentionale necesita comunicatia intre host-uri; un agent mobil se executa local, pe sistemul vizitat
      • influenta scazuta la latenta retelei: influenta intarzierii asociata transmisiei este deasemena minimizata
      • incapsuleaza protocoale; intr-o aplicatie conventionala, corespondentii cad de acord a priori asupra protocolului utilizat; un agent mobil poate fi configurat sa interactioneze cu sistemul vizitat
      • ruleaza asincron si autonom
      • se adapteaza dinamic la mediul de executie
      • sunt potential independenti de platforma
      • sunt robusti si toleranti la defectele de sistem/retea, fiind capabili sa reactioneze la modificarile de ambient
  • Modele agenti
    modelul Convingere-Dorinta-Intentie
    agentul are propria reprezentare, convingere, interna a mediului. Eforturile pe care le face un agent, pentru a-si atinge obiectivele, rezulta din dorintele pe care le are. Dorintele sunt generate ca raspunsuri la modificarile mediului sau din interactiunea cu alti agenti. Dintre dorinte se selecteaza acelea care vor deveni obiective, intentiile
  • criterii analiza SAM-uri
    • modelul comportamental
      descrie comportamentele posibile ale unui agent care actioneaza pentru realizarea unei intentii
      acest model poate influenta modelele de mobilitate si de coordonare
    • modelul de mobilitate
      descrie strategiile de relocare ale agentilor; un anumit tip de comportament al agentului necesita o schema de relocare specifica; relocare se realizeaza intre locatii statice, aflate sub controlul SAM-ului; in general SAM-ul de pe un host poate reprezenta, in logica aplicatiei, mai multe locatii; daca relocarea are loc in ambientul SAm-ului dintr-un host, mobilitatea este locala, altfel este o mobilitate fizica;
        clasificare dupa initiatorul migratiei
      • activ: agentul insusi initiaza migratia
      • pasiv: SAM-ul decide migrarea
        clasificare dupa starea de executie agentului in urma relocarii
      • slaba: starea codului si datelor se pastreaza la migratie dar pentru reluarea rularii agentului, SAM-ul invoca o metoda a agentului
      • puternica: dupa migratie agentul se gaseste in aceeasi stare de executie
        clasificare dupa distanta de relocare
      • monosalt: SAM-urile sunt direct conectate
      • multisalt: SAM-urile utilizeaza tabele de rutare
    • modelul de coordonare
      descrie modurile posbile prin care agentii pot colabora
        o clasificare a modelelor de coordonare pentru sisteme de agenti mobili
      • coordonare directa
        agentii partajeaza un spatiu de nume si sunt sincronizati; in general utilizeaza un model de comunicare client-server cum ar fi Java RMI sau CORBA;
      • coordonare prin intalnire
        nu mai exista spatiul de nume, existand doar restricitia de cunoastere a punctului de intalnire,agentii aflati in acelasi nod comunicand in punctele de intalnire; sincronizarea se realizeaza prin intalnire
      • coordonarea prin spatiu de mesaje
        exista spatiul de nume dar nu exista nici o restrictie asupra sincronizarii; mesajele sunt lasate in spatiul de mesaje si nu conteaza cand si daca vor fi preluate de catre destinatari
      • coordonare tip Linda
        nu exista spatiul de nume si nci restrictia de sincronizare; exista un spatiu de date partajat, spatiul tuplelor, in care agentii stocheaza sau din care culeg informatia prin mecanisme asociative, ale caror primitve sunt predefinite. Informatia este reprezentata prin structuri de date, tuple, adaptate pentru algoritmi de regasire.

Monday, March 27, 2006

FIPA, sumar specificatii

  • aplicatii
    descrieri ontologii si servicii pentru domenii specifice
    • FIPA Nomadic Application Support Specification - standard
        specificarea urmatoarelor functionalitati agent:
      • MA, Monitor Agent
      • CA, Control Agent
        ambientul aplicatiilor nomade este diferit de cel al sistemelor distribuite traditionale in ceea ce priveste
      • latimea de banda
      • latenta
      • intarzierea
      • rata de eroare
      • posibilitatile grafice
      • alti parametri non-functionali
      • rolul acestui standard fiind acela de a specifica o infrastructura care se refera la informatia asupra performantei, monitorizarea agentului, a controlului operatiilor si a modului de adaptare, mai precis:
        sarcini ale agentului pentru adaptarea aplicatiei:
      • selectarea MTP, Message Transport Protocol, si a MTC, Message Transport Connection utilizate pentru comunicatiile agentului
      • selectarea ACL, Agent Communication Language, si a reprezentarii limbajului de continut
      • rezervari pentru asigurarea adaptarilor la cerintele de date ale aplicatiei
      • comunicatii intre agenti pe timpul realizarii adaptarii
    • FIPA Agent Software Integration Specification
      integrarea serviciilor asigurate de software-ul non-agent intr-o comunitate multi-agent, definind relatiile intre aceste sisteme la nivelul comunicatiei agent ceea ce implica realizare de :
      • containere, pentru servicii, care sa fie utilizate si/sau controlate de comunitati de agenti
      • agenti care sa asigure serviciul ARB, Agent Resource Broket, care sa permita inregistrarea si managementul serviciilor software
      • agenti care acceseze aceste servicii
    • FIPA Network Management and Provisioning Specification
      furnizorii de servicii de telecomunicatii colaboreaza pentru a asigura abonatului un serviciu unic, optimizat din punct de vedere al caliatii serviciului si costului
      modelele clasice de management, TMN sau SNMP, sunt bazate pe interfete cu interactiune fixa, modelul cu agenti fiind o incercare de rezolvare a problemei, in sensul realizarii unei negocieri automate a serviciilor si a configurarii acestora. Agentii, utilizand ACL, ar trebui sa permita:
      • realizarea negocierii
      • asigurarea de servicii dinamice si configurarea
      • reducerea dependentei de fiabilitatea retelei si disponibilitatea acesteia prin incapsularea functiunilor de negociere in mesaje ACL
      • personalizarea configurarii resursei unui serviciu si utilizarea acetuia
    • FIPA Message Buffering Service Specification
      serviciu de stocare pentru MTS pentru dispozitive wireless si roaming MBS, Message Buffering Service, realizeaza stocarea mesajelor atunci cand un agent sau o platforma nu este disponibila. Aceasta permite unui dispozitiv ce are o conexiune slaba, temporara, cu reteaua sa prmieasca totusi mesajele. Acest serviciu se adreseaza in primul rand mediilor wireless.
    • FIPA Quality of Service Specification
      pentru utlizatorii nomazi posibilitatea de adaptare automata, in mod transparent si integrat, la modificari este esentiala ceea ce implica ca un agent sa aiba capacitatea de a cunoaste modificarile mediului. Acest standard descrie ontologia, un vocabular, utilizata in comunicarile despre QoS.
  • arhitectura abstracta
    entitatile, abstracte, care sunt necesare pentru construirea mediului si serviciilor agent
    • FIPA Abstract Architecture Specification
      Specificatiile referitoare la arhitectura abstracta includ:
      • elementele de arhitecturaq si relatiile intre acestea; scopul acestui standard
      • linii directoare pentru specificarea sistemelor de agenti, software specific si comunicatiile acestora
      • interoperabilitatea si conformitatea agentilor si sistemelor de agenti
    • FIPA Domains and Policies Specification
      serviciile de baza oferite de o platforma agent nu au restrictii, un agent fiind liber sa inregistreze intr-un director de servicii tot ceea ce doreste; in practica, dezvoltatorii sistemelor multi-agent doresc activarea unor restrictii si politici ce pot include:
      • cerinta ca un agent sa utilizeze o anumita codificare a mesajelor
      • prevenirea comunicatiei intre un agent si un agent non-local, aflat intr-un domeniu extern, prin schema de transport
      • restrictia ca un agent sa utilizeze o anumita clasa de calitate a serviciului a comunicatiei cu un agent non-local
      • prevenirea inregistrarii anumitor atribute ale agentului in ADS, Agent Directory Service, daca agentul agentul nu lucreaza sub coordonarea unui anumit director
      • limitarea numarului de agenti, de pe o platforma, care se inregistreaza
      • restrictionarea accesului la anumite host-uri sau stabilirea unui prag al resurselor unitilizate
  • comunicare agent
    mesajele ACL, Agent Communication Language, protocoalele pentru schimbarea acestor mesaje, actele de comunicare si reprezentari ale limbajelor de continut
    • FIPA ACL Message Structure Specification
      descrierea structurii mesajului ACL
    • FIPA Ontology Service Specification, experimental
      modelul comunicatiei agent se bazeaza pe presupunerea ca doi agenti partajeaza un vocabular asupra domeniului astfel incat agentii dau acelasi inteles simbolurilor utilizate in mesaj
      intr-o comunitate exista un agent dedicat OA, Ontology Agent, care poate asigura urmatoarele servicii:
      • descoperirea ontologiilor publice
      • mentinerea unei multimi de asemena ontologii
      • traducerea expresiilor intre diverse ontologii si/sau limbaje de continut diferite
      • rezolvarea cererilor asupra relatiilor intre termeni sau ontologii
      • identificarea unei ontologii implicate in comunicatia intre doi agenti
  • management agent
    managementul agentilor in contextul platformelor de agent
  • transport mesaj agent
    transportul si maparile mesajelor in protocoalele de transport

Friday, March 24, 2006

OMG Telecomm, CORBA TMN SNMP

  • intentii Telecommunications PSIG si stadiul actual
  • Interworking Between CORBA and TMN Systems Specification
    • JIDM, Joint Inter-Domain Management, CORBA
      colaborarea intre doua sisteme de management cu modele de referinta diferite presupune:
      • o schema de translatie intre cele doua modele de obiecte, Specification Translation
      • o conversie dinamica intre cele doua protocoale, Interaction Translation
      Interaction Translation presupune existenta unor interfete pe trei nivele
      • interfete generice independente de modelul de management
        JIDM facilities
      • interfete generice dependente de modelul de management
        Servicii suport OSI si SNMP CORBA
      • interfete specifice dependenete de modelul informational si de modelul de management
      JIDM defineste o serie de interfete care realizeaza legatura intre manager si agent
        interfete pentru manager
      • ProxyAgent
        un obiect care se creaza dupa ce un manager obtine accesul la un domeniu de obiecte gestionate; se poate obtine accesul concurent la un domeniu prin mai multe instante
      • ProxyAgentController
        permite validarea dreptului de a distruge un ProxyAgent
      • ProxyAgentFinder
        gasirea unui ProxyAgent
      • EventPort
        permite accesul dinspre agent catre manager
      • EventPortFactory
        crearea dinamica aunui EventPort
        interfete pentru agent
      • DomainPort
        controlul accesului la un domeniu
      • DomainPortFactory
        permite crearea dinamica a unui DomainPort
      • EventPortFinder
        gasirea unui EventPort
      contextul este cel al sistemelor distribuite fara arbitru astfel ca solutia indicata este utilizarea unui serviciu de federalizare
      pentru transferul intre protocoale se indica utilizarea CORBA/CMIP si CORBA/SNMP gateways atat pentru manager cat si pentru agent
    • OSI CORBA
        interfete; OSIMgmt
      • ProxyAgent
        realizeaza o extindere a JIDM::ProxyAgent pentru OSI
      • ManagedObject
        extinde OSIMgmt::NamingConetx si CosLifeCycle::LifeCycleObject
      • ManagedObjectFactory
        creaza instante ManagedObject
      • LocalRoot
        intr-un domeniu CORBA de obiecte gestionate OSI exista un obiect care are rolul de radacina locala
        radacina locala este superiorul oricarui obiect orfan
        un obiect orfan este un obuect gestionat al carui superior sa afla in alt domeniu OSI
        radacina locala pastreaza referinte catre toate obiectele orfane si exporta o interfata de tip LocalRoot
      • LinkedReplyHandler, EndOfRepliesHandler
        permit unui obiect sa trimita mai multe raspunsuri, la aceeasi interogare, folosind un model asincron
      • MultipleRepliesHandler
      • RepliesIterator
      • BufferedRepliesHandler
        receptionarea mai multor raspunsuri la aceeasi interogar, utilizand un model sincron
      • LName
        realizeaza translatia de nume, intre conventia OSI si CoSNaming::Names
        in OSI-SM-RM orice obiect gestionat este continut intr-un alt obiect, acesta din urma fiind unic, astfel ca numele obiectelor se bazeaza pe relatia de compozitie. Numele unui obiect se poate exprima prin doua forme:
        • globala
          o secventa RDN, Relative Distinguished Name, care identifica in mod univoc obiectul in contextul global; in contextul unui container, un obiect se identifica prin valoarea unui atrobit, AVA, Attribute Value Assertion
        • locala
          o secventa RDN care identifica in mod univoc obiectul intr-un context predefinit
      • NamingContext
        extensie pentru CosNaming::NamingContext pentru OSI; permite operatii de nume extinse OSI
        porti CORBA/CMIP
      • manager
        permite accesarea de catre manager a unui obiect gestionat ce este disponibil prin CMIP
        contine mai multe obiecte de tipurile:
        • JIDM::ProxyAgentFinder
        • JIDM::EventPort
      • agent
        un agent CORBA care pune la dispoziytie o interfata de management CMIP
        contine mai multe obiecte de tipurile:
        • JIDM::EventPortFinder
        • JIDM::DomainPort
    • Servicii suport OSI
      • OSI Caching and Tracking Services
        un OSIMgmt::ManagedObject poate fi configurat sa stocheze local valori ale atributelor
        stocarea se poate configura pentru fiecare obiect in parte, pentru toate obiectele unei clase sau pentru toate obiectele gestionabile printr-un proxy
        yrmariea (tracking) permite actualizarea dinamica a informatiei critice
      • Collection Service
        permite realizarea de operatii asupra unor m ultimi de OSIMgmt::ManagedObject
      • Dynamic Management of ASN.1 Any Values
        permite operatii asupra valorilor CORBA::Any la runtime fara a avea informatii statice (generate de compilatorul IDL) asupra tipului
      • The OSI Management Information Repository
        contine descrierile si structurile modelelor informationale utilizate in modelul TMN management si ofera doua servicii:
        • descrierea modelului
          informatii suplimentare care au fost pierdute la transcrierea in IDL (datorita restrictiilor tipurilor ASN.1 sau relatii de mostenire care apareau in ierarhia de clase GDMO)
        • descrierea translatiei
          informatii privind corespondenta intre modelel GDMO/ASN.1 si IDL
    • SNMP CORBA
      extinderea JIDM Facilities pentru a permite maparea bidirectionala a numelor, mesajelor si evenimentelor, din domeniul SNMP, cu nume, operatii, invocare si evenimente, din domeniul CORBA
      • SNMPMgmt
          interfete
        • ProxyAgent
          extinde JIDM::ProxyAgent
        • SmiEntry
          este interfata IDL de baza pentru toate interfetele IDL ale grupurilor SMI si intrarilor in tablouri
        • GenericFactory
          extensie a CosLifeCycle::GenericFactory ce permite operatii specifice SNMP SMI referitoare la ciclul de viata pentru o intrarile unei interfete IDL; corespunde tipului de data RowStatus din SNMPv2
        • NamingContext
          extinde CosNaming::NamingContext si permite maparea catre spatiul de nume SNMP, ordine lexicografica
        • SmiTableIterator
          perite accesul la tabluri; obiect
        • GetNextEntryIterator
        • parcurgeraea in ordine lexicografica a unui tablou, urmata de un GetNext
      • SNMP Management Information Repository
        translatia unei specificatii SMI catre IDL se face cu anumite pierderi si deasemenea disponibilitatea meta-informatiei SMI prin IFR, Corba Interface Repository, poate sa nu fie convenabila
        are doua componenete:
        • OID Repository
          ierarhia OID si numele textuale atasate fiecrui nod OID din arborele OID
        • SMI Macro Repository
          meta-informatie despre modulele SMI si macrourile referitoare la grupuri, intrari in tablouri si variabile

Thursday, March 23, 2006

Sumar arhitectura TMN

  • standarde TMN (M3000 - M3599)
    • subiecte
      • arhitectura (M.3010)
      • metodologia de specificare a interfetelor (M.3020)
      • servicii de management (M.32xx)
      • functii de management (M.3400)
      • modele pentru informatia de management: modele pentru retele generice (M.3100) si modele specifice unei tehnologii
      • inregistraea informatiei de management, similar cu OSI SMI
      • protocoale de comunicatii
        • protocoale transport: OSI, ISDN, SS7, TCP/IP
        • protocoale de management: CMIP, X.500, CORBA GIOP
        sintaxa de transfer este BER
      • servicii pentru management de sisteme si mesaje de management
      • securitate (M.3016)
    • zone referite
      • servicii de telecomunicatii
      • arhitectura retelei de telecomunicatii
      • managementul traficului
      • mentenanta retelei
      • securitatea retelei
      • componentele retelei
      • rezervarea retelei
      • protocoale de comunicatii
      • servicii de management sisteme OSI
      • functii de management OSI
  • arhitectura (M.3010)
    • functional architecture
      descompunerea functiunilor in blocuri, "function blocks", si modul de conectare al acestora, "reference points", functii de management, "Management Application Functions - MAF", functii de management ale TMN si multimi ale acestora
    • information architecture
      adopta modul de specificare, orientat obiect, cat si principiile de acces ale OSI-SM
    • physical architecture
      mapeaza blocurile functionale in blocuri fizice prin prisma cerintelor care nu tin de functionalitate
  • arhitectura functionala
    utilizeaza urmatoarele tipuri de blocuri functionale
    • OSF, Operations Systems Functions
      realizeaza procesarea informatiei de management. Se interfateaza NEF-urile in mod direct sau indirect prin MF-uri, cu QAF-urile si cu alte OSF-uri. OSF-urile comunica fie punct-la-punct fie intr-o maniera ierarhica. Un OSF corespunde atat rolurilor de manager cat si de agent din modelul agent-manager
    • NEF, Network Element Functions
      modeleaza echipamentul care este subiectul managementului, monitorizare si/sau control, corespunde unui agent din modelul agent-manager
    • WSF, Workstaion Functions
      reprezinta o interfata om-masina care comunica cu OSF si MF si permite complementarea deciziilor de consistenta si validitate, automate, cu decizii umane si corespunde unei aplicatii in rol de manager in modelul agent-manager
    • TF, Transformation Functions
      converteste, protocoale sau modele ale informatie, intre doua entitati
    si urmatoarele puncte de conectare
      puncte de referinta TMN
    • f (M.3300)
      conecteaza OSF si WSF
    • q
      conecteaza OSF, TF, NEF
      • q3
        ce conecteaza un OSF cu NEF-uri, QAF-uri, MF-uri si alte OSF-uri
      • qx
        ce contecteaza un MF cu QAF-uri si NEF-uri, sau MF-uri intr-o maniera ierarhica
    • x (M.3320)
      OSF cu OSF ce apartin la TMN-uri diferite, similar unui q3 cu mecanisme de securitate

    • si puncte de referinta non-TMN
    • g
      reprezinta interfata grafica om-masina, utilizator cu WSF
    • m
      conecteaza un QAF la elemente gestionate care suporta alte interfete de management, non-conforme TMN
    ce au relatiile:
    XNEFOSFTFWSFnon-TMN
    NEF-qq--
    OSFqq, xqf-
    TFqqqfm
    WSF-ff-g
    non-TMN--mg-
    implementarea MAF, functiunilor aplicatie de management, realizandu-se prin combinatii ale blocurilor functionale
    intreaga arhitectura ffind stratificata astfel:
    • organizatie
      se refera la functiunile specifice organizatie si OSF-urile din acest nivel nu au puncte de referinta de tipul x
    • serviciu
      • interfata cu abonatii pentru tranzactionarea serviciilor, rezervare, calitatea serviciului (QoS)
      • intercatiune cu furnizori de servicii
      • date statistice
      • interactiunea intre servicii
    • retea
      • controlul si coordonarea prin prisma retelei a elementelor de retea
      • rezervarea si modificarea capacitatilor de asigurare a serviciilor pentru abonati
      • mentenanat capacitatilor retelei
      • colectarea informatiilor statistice, jurnale despre retea si interactiunea cu nivelul de management al serviciuuli
      • OSF-uriloe de retea pot gestiona relatiile intre NEF-uri
    • element
      • controlul si coordonarea elementelor de retea arondate unui NEF; OSF de element asigura interactiunea intre nivelul element de retea si nivelul managementului de retea
      • poate controla o multime de alte elemente de retea
      • colectarea informatiilor statistice, jurnale pentru elementele respective
  • arhitectura fizica
    arhitectura functionala este o arhitectura conceptuala, trecerea catre arhitectura fizica facandu-se fie prin transformarea blocurilor functionale in blocuri fizice in relatie unu-la-unu fie prin agregarea mai multor blocuri functionale intr-un bloc fizic si transformarea punctelor de referinta in interfete
    utilizeaza urmatoarele blocuri fizice:
    • OS, Operations System
      este sistemul care realizeaza OSF-urile si poate include QAF-uri si WSF-uri
    • Transformation
      conversii intre protocoale si formate de date
      • adaptation device
        transformarea de la un entitate fizica non-TMN la un NE sau OS.
        QA, Q-Adapter, este un bloc fizic ce conecteaza un NE sau un OS cu o interfata non-TMN, la un punct de referinta de tip m, cu o interfata Q.
        XA, X-adapter, este un bloc fizic ce conecteaza o entitate non-TMN aflata intr-un mediu non-TMN si care utilizeaza o comunicatie non_TMN cu un OS aflat la frontiera unui TMN.
      • mediation device
        MD, mediation device, este un bloc fizic ce realizeaza o transformare intre doua blocuri fizice cu mecanisme de comunicare incompatibile
    • NE, Network Element
      reprezinta echipamente care realizeaza NEF-uri si poate contine si alte blocuri functionale
    • WS, Workstation
      un sistem care realoizeaza WSF-uri
    comunicatia intre acestea fiind asigurata de DCN, Data Communication Network
  • information architecture
    este compusa din:
    • puncte de referinta
      reprezinta o extindere a conceptului de punct de referinta functional cu informatia de management care este schimbata in punctul de referinta
    • modele ale datelor
      reprezinta o abstractizare a aspectelor de management ce privesc resusrele retelei
    • elemente de date
      sunt elemetele ce alcatuiesc modelul datelor
    • modelul de date al punctului de referinta
      datele prezente intr-un punct de referinta, definite pe baza interactiunilor functionale
    • prevede regulile si tiparele fluxului de informatii intre blocurile functionale la punctele de referinta

Tuesday, March 21, 2006

Sumar SNMP

SNMPv1 (RFCs: 1155, 1157, 1212)
  • mesaj SNMP
    version | community | SNMP PDU
  • PDU
    PDU type | request ID | error status | error index | variable bindings
  • variable bindings
    name 1 | value 1 | name 2 | value 2 | ... | name n | value n
  • PDU type
    • GetRequest-PDU
        se initiaza la manager
      • daca agentul nu gaseste obiectul cerut sau daca obiectul este compus, raspunde cu un GetResponse-PDU identic in care error-status="noSuchName" si "error-index" este este cel al obuiectului cerut initial
      • daca GetResponse-PDU ar fi prea mare, agentul raspunde cu GetResponse-PDU cu error-status="tooBig"
      • daca nu poate gasi obiectul, alte cazuri, agentul raspunde cu GetResponse-PDU cu serror-status="genErr"
      • altfel agentul trimite GetResponse-PDU
    • GetNextRequest-PDU
      similar cu >GetRequest-PDU dar se face verificarea de ordonare lexicografica a variabilelor
    • GetResponse-PDU
      generat in caz corect de catre agent in urma unui get
    • SetRequest-PDU
      generat de manager si interpretat de agent
      • daca agentul nu gaseste obiectul cerut sau daca obiectul este compus, raspunde cu un GetResponse-PDU identic in care error-status="noSuchName" si "error-index" este este cel al obuiectului cerut initial
      • daca obiectul exista dar nu corespunde ca tip, valoare sau lungime se raspunde cu GetResponse-PDU ce are error-status="badValue" si indexul corespunzator din mesajul de set
      • daca GetResponse-PDU ar depasi limitele se trimite un GetResponse-PDU cu error-status="tooBig"
      • pentru alte motive, de eroare se raspunde cu GetResponse-PDU ce are error-status="genErr"
      • altfel, dupa setarea variabilelor se raspunde cu GetResponse-PDU ce are serror-status="noError"
    • Trap-PDU
      se transmite de la agent catre manager pentru a semnala un eveniment, fiind un serviciu fara livrare garantata; agentulpoate fi configurat astfel incat sa nu transmita trap-urile sau sa le transmita catre anumiti manageri
        evenimente definite
      • coldstart; reinitializarea entitatii cu posibila modificarea a configuratiei agentului sau a protocolului
      • warmstart; reinitializarea entitatii fara modificarea configuratiei agentului si nici a protocolului
      • linkdown
      • linkup
      • authentication failure
      • egpneighbourloss
      • enterprisespecifictrap
  • codificarea mesajelor SNMP
    mesajele sunt formatate in sintaxa abstracta, ASN.1. la nivel aplicatie
    transferul se face printr-o sintaxa de transfer, BER, Basic ENcoding Rules, la nivel prezentare
      fiecare valoare ASN.1 este codificata ca un sir de bytes:
    • tag
    • length
    • value
SNMPv2 (RFCs: 2578, 2579, 2580, 3416, 3417, 3418)
    limitarile SNMPv1 au condus la modificari in SNMPv2 in ceea ce priveste:
  • confinarea codurilor de eroare (SetRequest-PDU) si generarea de exceptii
    SNMPv1SNMPv2
    badValuewrongValue
    badValuewrongEncoding
    badValuewrongType
    badValuewrongLength
    badValueinconsistentValue
    noSuchNamenoAccess
    noSuchNamenotWritable
    noSuchNamenoCreation
    noSuchNameinconsistentName
    genErrresourceUnavailable
    genErrgenErr
    genErrCommitFailed
    genErrundoFailed
  • PDU type
    • manager
        transmite
      • GetRequest-PDU
      • GetNextRequest-PDU
      • GetBulkRequest-PDU
      • SetRequest-PDU
      • InformRequest-PDU
        utilizat intre doi manageri
      • Response-PDU
        receptioneaza
      • Response-PDU
      • SNMPv2-Trap-PDU
    • agent
        transmite
      • Response-PDU
      • SNMPv2-Trap-PDU
        receptioneaza
      • GetRequest-PDU
        la fel ca la SNMPv1 dar apar exceptiile si nu se mai genereaza un raspuns cu eroare:
        • daca numele variabilei nu are un prefix OBJECT IDENTIFIER adecvat se genereaza "noSuchObject"
        • altfel "noSuchInstance"
      • GetNextRequest-PDU
        la fel ca la SNMPv1 dar daca numele variabilei nu precede lexicografic o variabila locala atunci se genereaza un raspuns cu exceptia "endOfMibView"
        se foloseste pentru accesul tablourilor conceptuale
      • GetBulkRequest-PDU
        folosit pentru obtinerea rapida a tablourilor mari
        nu se mai aplica maparea unu-la-unu, cum este cazul pentru GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU types si Response-PDU rezultant
        pentru primele "non-repetors" variabile se procedeaza ca si in cazul GetNextRequest-PDU iar pentru urmatoarele variabile se aplica "max-repetitions" repetitii pentru a obtine succesorii lexicografici
      • SetRequest-PDU
        procesarea se realizeaza in doua faze
        • validarea variabilelor; pot rezulta doua situatii de eroare; in caz de reusita raspunde cu Response-PDU cu error-status="noErr" si error-index=0
        • alterarea valorilor are loc in caz de reusita a fazei anterioare; daca varibilele nu exista se vor crea cu valorile specificate
  • notificarile
  • performanta
    GetBulkRequest-PDU
  • ierarhia
      exista trei abordari, ale managementului distribuit
    • bazat pe MIB
    • bazat pe script
    • operatii la distanta
  • securitatea
    • SNMPv2, community based
    • SNMPv2, user based
SNMPv3
  • arhitectura (RFC 3411)
    • manager
      o entitate SNMP care contine unul sau mai multe generatoare de comenzi si/sau receptor de notificare
      generator comanda ↔ dispecer
      receptor notificare ↔ dispecer
      originator notificare ↔ dispecer
      dispecer ↔ subsistem procesare mesaje
      subsistem procesare mesaje ↔ subsistem de securitate
      dispecer ↔ protocol transport
    • agent
      o entitate SNMP care contine unul sau mai multei receptori de comenzi si/sau generatori de nottificare
      receptor comanda ↔ MIB
      generator notificare ↔ MIB
      receptor comanda ↔ controlul accesului
      generator notificare ↔ controlul accesului
      receptor comanda ↔ dispecer
      generator notificare ↔ dispecer
      releu proxy ↔ dispecer
      dispecer ↔ subsistem procesare mesaje
      subsistem procesare mesaje ↔ subsistem de securitate
      dispecer ↔ protocol transport
  • aplicatii (RFC 3413)
    • generator comanda
    • receptor comanda
    • generator notificare
    • receptor notificare
    • releu proxy
      • pasarea cererii
      • procesarea unei cereri
      • procesarea unui raspuns
      • procesarea unui PDU clasa interna
      • altele
    • altele
  • motor
      un motor SNMP furnizeaza servicii pentru transmiterea/receptionarea de mesaje, autentificarea si criptarea acestora si controlul accesului la obiectele gestionate
      o entitate SNMP contine un singur motor
    • identificarea motorului (snmpEngineID)
      este un identificator unic si neambiguu intr-un domeniu administrativ
    • componente
      • subsistem procesare mesaje (RFC 3412)
        • model de procesare mesajeSNMPv3
        • model de procesare mesajeSNMPv1
        • model de procesare mesajeSNMPv2c
        • alte modele de procesare mesaje
      • dispecer (RFC 3412)
        un motor SNMP contine un singur dispecer
        dispecerul permite circulatia mesajelor SNMP apartinand mai multor versiuni
        • dispecer PDU
        • dispecer mesaje
        • mapari transport
          transportul SNMP peste alte protocoale (RFC 3417)
          schema URI pentru SNMP (RFC 4088)
      • subsistem de securitate
        • CSM, Community based Security Model
        • USM, User based Security Model (RFC 3414)
          utilizarea AES in USM (RFC 3826)
      • subsistem control acces
        • control acces - VACM, view-based access control model (RFC 3415)
  • accesul la informatia de management (RFC 3416)

Friday, March 17, 2006

IETF, SMI, Structure of Management Information, SMIv1, SMIv2

    SMI, Structure of Management Information
  • SMIv1, SMIv2
  • SMIng
Structure of Management Information
SMIv1, SMIv2

Informatia de management este disponibila ca o colectie de obiecte gestionate, ce sunt stocate in magazii virtuale, MIB-urile
Colectiile de obiecte inrudite sunt definite in MIB-uri care sunt specificate ASN.1
  • standarde
    • RFC 1155, SMI v1
    • RFC 1211, Concise MIB Definitions
    • RFC 2578, SMI v2
  • structura
      expandarile acestor macrouri au loc in mod conceptual, la implementare si nu la run-time
    • definitii module (macro ASN.1 MODULE-IDENTITY)
      descrire generala a modulului, inf. contact
    • definitii obiecte (macro ASN.1 OBJECT-TYPE)
      definirea tipurilor de obiecte gestionate
    • definitii notificari (macro ASN.1 NOTIFICATION-TYPE)
      definirea informatiei continute intr-o transmisie nesolicitata (SNMPv2-Trap-PDU sau InformRequest-PDU)
  • tipuri scalare
    SMI v1SMI v2
    tipuri simple
    INTEGERINTEGER
    OCTET STRINGOCTET STRING
    OBJECT IDENTIFIEROBJECT IDENTIFIER
    Integer32
    tipuri cu vizibilitate la nivel aplicatie
    Unsigned32
    GaugeGauge32
    CounterCounter32
    Counter64
    TimeTicksTimeTicks
    IpAddressIpAddress
    OpaqueOpaque
    NetworkAddress
    Pseudo tipuri
    BITS
  • reguli pentru definirea tipurilor
    • obiectele apartin unui tip si au valori care sunt restrictionate la o multime care se poate reduce la tipurile de baza ASN.1 prezentate mai sus ca tipuri simple
    • obiectele cu vizibilitate la nivel aplicatie trebuie sa rezulte in tipurile intregi sau string de scalari
    • tipul care se poate construi este un vector bidimensional, elementele acestuia fiind tipurile de mai sus
    • se pot defini tipuri noi utilizand un macro ASN.1, OBJECT-TYPE
    • se permite instantierea simpla sau multipla pentru tabluri;
    • nu exista notiunea de obiect compus care sa contina o multime de tipuri scalare, singura relatie de compozitie permisa existand intre obiectele componente ale aceluiasi tablou
    • un tablou se modeleaza prin tipul ASN.1, SEQUENCE OF randuri; este permisa instantierea dinamica a unui numar arbitrar de randuri
    • un tablou contine randuri (intrari in tablou sau inregistrari) fiecare fiind reprezentat prin tipul ASN.1, SEQUENCE ce contine un numar, definit static, de obiecte
    • un rand trebuie sa fie scalar, adica nu se poate defini un tablou in alt tablou
    • tablourile si randurile sunt obiecte compuse dpdv conceptual astfel incat numai obiectele individuale ce constituie un rand pot fi accesate prin protocolul de management
    O1: codificarile si decodificarile pot fi scumpe computational daca se foloseste o sintaxa complexa dar datorita faptului ca multimea tipurilor este redusa aceasta problema se poate rezolva printr-o optimzare manuala
      OBJECT-TYPE:
    • SYNTAX
      tipuri simple | tipuri cu vizibilitate la nivel aplicatie | New type
    • MAX-ACCESS
      • read-only
      • read-wrirte
      • read-create
      • accessibke-for-notify
      • not-accesible
    • STATUS
      • current
      • deprecated
      • obsolete
    • DESCRIPTION
      ""
    exemplu definire "frunza"
    adresaOBJECT-TYPE
    SYNTAXIpAddress
    MAX-ACCESSread-write
    STATUScurrent
    DESCRIPTION"adresa IP a calculatorului"
    ::={unAltMib 1}
    exemplu definire nod
    informatiiOBJECT-IDENTITY
    STATUScurrent
    DESCRIPTION"nod ce va contine frunze, scalari"
    ::={unAltMib 2}
    exemplu definire tablou
    • tabloul
      tabelaRutareOBJECT-TYPE
      SYNTAXSEQUENCE OF randRuta
      MAX-ACCESSnot-accessible
      STATUScurrent
      DESCRIPTION"tabela de rutare"
      ::={mibRutare 3}
    • randul
      randRutaOBJECT-TYPE
      SYNTAXRuta
      MAX-ACCESSnot-accessible
      STATUScurrent
      DESCRIPTION"intare in tabela de rutare"
      INDEX{destinatie, metrica}
      ::={tabelaRutare 1}
    • tipuri noi utilizate, definire
      • Ruta::=
        SEQUENCE{
        destinatie ipAddress
        metrica INTEGER
        hopulUrmator ipAddress
        }
      • destinatieOBJECT-TYPE
        SYNTAXipAddress
        ACCESSnot-accessible
        STATUScurrent
        DESCRIPTION"adresa IP destinatie"
        ::={Ruta 1}
      • metricaOBJECT-TYPE
        SYNTAXINTEGER{
        distanta(1)
        latimeBanda(2)
        ACCESSnot-accessible
        STATUScurrent
        DESCRIPTION"metrica catre destinatie"
        ::={Ruta 2}
      • hopulUrmatorOBJECT-TYPE
        SYNTAXipAddress
        ACCESSread-write
        STATUScurrent
        DESCRIPTION"adresa IP unde se trimite pachetul"
        ::={Ruta 3}
schema de indexare multipla := OID tablou.numarColoana.valoateIndex1.valoareIndex2
  • reguli de instantiere si de compozitie
    • instantele trebuie denumite astfel incat adresarea sa nu fie ambigua astfel ca se folosesc identificatori de obiecte
    • un tip de obiect are un "registration OID" astfel ca o instanta se identifica prin IOD urmat de de un sufix care identifca in mod unic instanta; in cazul ca exista mai multe instante, sufixul va identifica randul prin compunerea uneia sau mai multor valori ale obiectelor cce constituie cheia, asa cum este ea specificata in template-ul OBJECT-TYPE pentru acel rand
    • astfel apare o cuplare stransa intre tipul obiectului si si identificatorul instantei ceea ce are ca efect directa ca un tip de obiect poate apare numai intr-un loc in in arborele de inregistrare ceea ce inseamna ca ca nu se pot defini tipuri generice de obiecte care sa fie utilizate in contexte diferite
    (exemplu arbore de nume in interiorul uni MIB; nodurile apar pentru a se putea face referirea, frunzele reprezentand obiectele gestionate)
    unAltMib:1
    adresa(1)informatii(2)
    192.168.1.1numeNod(1)utilizator(2)
    laptopIonescuIonescu
    astfel ca se obtine
    OIDinstantavaloarea
    adresa1.11.1.0192.168.1.1
    informatii1.2
    numeNod1.2.11.2.1.0laptopIonescu
    utilizator1.2.21.2.2.0Ionescu
  • reguli de access
    • operatia "Set" se realizeaza numai asupra obiectelor care nivelul "read-write" sau "read-create", asa cum apare in specificatia obiectului
    • accesul la obiecte prin "Get" si "Set" face subiectul unei politici de contril a accesului prin interfata de management
    • obiectele nu suporta operatiile explicite "Create" si nici "Delete", acestea fiind suportate numai pentru obiectele cu instante multiple
    • in SNMP v1, crearea unui rand, care nu exista deja intr-un tablou, se poate realiza printr-o definierea valorilor tuturor obiectelor randului dar protocolul SNMP limiteaza valoarea maxima a PDU (protocol data unit) asa ca nu este intotdeauan posibil sa se paseze valorile pentru toate obiectele randului
    • in SNMPv2, exista o schema de care asigura atomicitatea crearii unui rand
    • se poate simula o actiune arbitrara lde tipul "la frontiera obiectului" printr-un "Set" urmat de un "Get"
    • agentii pot emite notificari, "traps", asociate mai degraba protocolului SNMP decat unei specificatii MIB
  • Thursday, March 16, 2006

    OSI Systems Management - domenii functionale

    Domeniile functionale ale OSI Systems Management (X.700)
    cerintele specifice prin SMF (Systems Management Functions)
    mnemonica = FCAPS
    • Fault management
      se refera la generarea notificarilor de eroare, jurnalizarea acestora la sursa si testarea resurselor retelei cu scopul identifcarii defectelor si trasabilitatii acestora
      • raportarea alarmelor(X.733)
        are ca scop obtinerea si procesarea informatiei pentru identificarea evenimentelor de interes
      • raportarea evenimentelor(X.734)
      • jurnalizarea (X.735)
      • testarea (X.737 si X.745)
    • Configuration management
      initializarea, instalarea si rezervarea; permite colectarea informatiei de stare la cerere si asigura facilitati de logistica; permite anuntarea modificarilor de configuratie prin notificari relevante
      • obiectul (X,730)
      • starea (X.731)
      • relatiile (X.732)
      • rapoartarea evenimentului (X.734)
      • jurnalizarea (X.735)
      • gestionarea timpului (X.743)
      • distributia software-ului (X.744)
      • planificarea gestionarii (X746)
      • informatie de management partajata (X.750)
    • Accounting management
      se refera la colectarea informatiei de contabilitate si la procesarea acesteia cu scopul incadrarii in conturi si facturarii in contextul unui serviciu atunci cand sunt utilizate resurse multiple
      • raportarea evenimentului (X.734)
      • jurnalizarea (X.735)
      • metrica de conturi (X.742)
    • Performance management
      priveste disponibilitatea informatiei necesare determinarii incarcarii sistemului si retelei in conditii naturale si artificiale. Permite colecatrea periodica a informatiei, de performanta, necesara activitatilor de statistica si planificare a capacitatii
      • raportarea evenimentelor (X.734)
      • jurnalizarea (X.735)
      • monitorizarea metricii (X.739)
      • sumarizarea (X.738)
      • planificarea (X.746)
      • monitorizarea timpului de raspuns (X.748)
    • Security management
      se ocupa de aspectele care privesc securitatea sistemului
      • managementul securitatii
        posibilitatea de a monitoriza si controla disponibilitatea facilitatilor de securitate si de a raporta amenintarile sau bresele de securitate
      • securitatea managementului
        posibilitatea de a autentifica aplicatiile si utilizatorii de management ceea ce ar permite garantarea confidentialitatii si a integritatii modificarilor de management si de a interzice accesul neautorizat la informatia de management
      si face uz de:
      • raportarea evenimentelor (X734)
      • jurnalizare (X735)
      • raportarea alarmelor de securitate (X736)
      • trasabilitatea auditului de securitate (X737)
      • controlul accesului (X741)

    Caracteristici generale retele ad hoc

    • latime de banda scazuta si legaturi de capacitate variabila
      ca urmare a fading-ului, bruierii, etc. legaturile radio prezinta rate de eroare diferite
    • topologie dinamica
      modificarile topologiei au loc atunci cand nodurile isi modifica distantele relative ceea ce are efect asupra legaturii
      sistemul de management trebuie sa cunosca topologia retelei
      modificarile frecvente ale topologiei retelei implica un trafic de semnalizare sporit
      rezulta ca mecanismul utilizat pentru gestionarea informatiei despre topologie este foarte important
        clasificare conform mobilitatii relative
      • retele wireless fixe
      • retele wireless fixe cu punct de acces
      • retele mobile ad hoc
    • resurse limitate
      sursa de putere este bateria ceea ce impune o limitare asupra capacitatilor de stocare si procesare
    • nodurile retelei au roluri multiple
      majoritatea nodurilor ruteaza pachete si in acelasi timp pot fi sursa/destinatie
    • eterogenitate
      nodurile pot fi: de la senzori pana la LAN-uri mobile
    • supravietuire limitata
      utilizarea unui mediu radio ofera, unei terte parti, posibilitatea de a initia atacuri la primele doua nivele OSI care se intind de la interceptare pana la raspuns fals
    • desfasurare temporara si axata pe misiune
      retelele ad hoc ofera o alternativa eficienta si economica pentru comunicatii si informatica in situatiile in care utilizarea unei infrastructuri de retea nu ar fi practica sau prea costisitoare

    Wednesday, March 08, 2006

    Sun SPOT

    Nu este vorba despre pete solare ci despre "small programmable object technology". Se pare ca vor sa scoata in luna mai un kit de dezvoltare la 500$ ce ar permite scrierea de aplicatii Java, CLDC + Squawk VM, pentru retele de senzori, acceleratie + temperatura + lumina, wireless, MAC 802.15.4. sunspot