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

Thursday, August 03, 2006

Chestionar adresat bloggerilor romani

Chestionar pentru bloggeri

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)