Protocoalele Snmp Si Xmpp

Diverse2

Protocoalele Snmp Si Xmpp

Byadmin ianuarie 1, 2024

CUPRINS

Lista figurilor

Lista tabelelor

INTRODUCERE

Cap.1. Protocolul SNMP – Simple Netwok Management Protocol

1.1. Arhitectura Simple Network Management Protocol

1.2. Fișiere utilizate de SNMP: SMI și MIB

1.3. Operațiile de bază în cadrul SNMP

1.3.1. Operația SNMP get

1.3.2. Operația SNMP set

1.3.3. Operația SNMP get-next

1.3.4. Operația SNMP trap

1.3.5. Operația get-response

1.4. SNMP peste UDP și TCP-IP

Cap.2. Protocolul XMPP

2.1. Principii funcționale și fundamente

2.2. XMPP versus Email

2.3. Servicii oferite de XMPP

2.4. Aplicații XMPP

2.5. Adresare, domenii, utilizatori și resurse XMPP

2.6. Primitive în comunicația XMPP

2.6.1. Tipul mesaj

2.6.2. Tipul prezență

2.6.3. Strofa XML IQ

Cap.3. Integrarea SNMP-XMPP

3.1. Alegerea mediului de dezvoltare

3.2. Configurarea serverului de XMPP și a contului de router

3.3. Configurarea router-ului în mediul Dynamips

3.4. Testarea funcționalității convertorului XMPP-SNMP

3.4.1. Conectarea router-ului la serverul XMPP

3.4.2. Conversia de protocol: XMPP -> SNMP – demostrație aplicativă

Concluzii

Anexe

Bibliografie

Lista figurilor

Figură 1: Arhitectura unei rețele ce utilizează SNMP 6

Figură 2: Structura arborelui MIB 10

Figură 3: Procesul de cerere-răspuns SNMP pentru operația get 12

Figură 4: Procesul de cerere-răspuns SNMP pentru operația set 13

Figură 5: Parcurgere a arborelui MIB prin get-next 14

Figură 6: Modelul TCP/IP al SNMP 17

Figură 7: Comparație între tehnologia bazată pe e-mail și cea bazată pe XMPP 20

Figură 8: Operația de tip get și operația de tip set 27

Figură 9: Elemente de configurație a calculatorului 30

Figură 10: Interfață de pornire a serverului de XMPP 31

Figură 11: Fereastră de logare a administratorului de server 31

Figură 12: Setarea parametrilor pentru serverul XMPP 32

Figură 13: Modul de stocare a utilizatorilor pe serverul XMPP 32

Figură 14: Fereastră pentru crearea unui utilizator 33

Figură 15: Interfată în linie de comandă Dynamips 33

Figură 16: Interfață în linie de comandă Dynagen 34

Figură 17: Înregistrarea R1 pe serverul Dynamips 34

Figură 18: Selectarea valorilor de activitate redusă 35

Figură 19: Interfețele configurate ale router-ului Cisco 36

Figură 20: Rezultatul comenzii show SNMP după configurarea SNMP a router-ului 38

Figură 21: Autentificarea router-ului pe server – indicator de prezență stins 39

Figură 22: Autentificarea router-ului pe server – indicator de prezență aprins 40

Figură 23: Convertorul XMPP- SNMP – setarea și preluarea parametrilor prin comenzi SNMP din fereastra de chat 43

Figură 24: Convertorul XMPP-SNMP – dialog “user friendly” cu router-ul 47

Lista tabelelor

Tabel 1: OID asociate companiilor 11

Tabel 2: Alarmele SNMP generice 16

INTRODUCERE

Rețelele de telecomunicații, precum și cele de calculatoare sunt în continuă expansiune datorită creșterii numărului de utilizatori de servicii de comunicații. Infrastructura IT trebuie proiectată astfel încât să corespundă obiectivelor și necesităților reale ale unei organizații, să creeze nivele ridicate de productivitate, eficiență, securitate și confort, să reprezinte o investiție optimă și să asigure un cost total de deținere minim.

Creșterea nivelului de complexitate a rețelelor a facut ca nevoia de management și de monitorizare sa devina tot mai accentuată. Un bun sistem de management va conduce la reducerea costurilor legate de întreținerea rețelei, la o monitorizare ușoară a echipamentelor la distanță, la găsirea și corectarea rapidă a erorilor apărute precum și la descoperirea și eliminarea punctelor critice din rețea. Majoritatea echipamentelor prezintă o consolă sau acces prin conexiune la distanță prin care pot fi testate și urmărite periodic. Dar ce se întâmplă când echipamentele sunt în număr foarte mare? Monitorizarea individuală prin accesarea fiecăruia și verificarea faptului că funcționează în parametrii normali ar fi operații ce presupun un consum mare de timp și energie. De aceea intervin din nou sistemele de management și, implicit, de monitorizare care facilitează administrarea unei întregi rețele. În prezent tot mai multe companii, inclusiv operatori de rețele de comunicații, adoptă soluții care folosesc resurse din așa-numitul nor (cloud), fie acestea servicii, memorii, putere de procesare sau echipamente virtuale sau reale. Se pune problema eliminării unei rezervări de resurse greoaie, așa cum este în prezent, dar și a gestionării acestor resurse, în special a echipamentelor existente în „norul de calcul” (cloud computing), în modelul de infrastructură-ca-serviciu (Infrastructure as a Service – IaaS). Într-o rețea, fie de dimensiuni mici, fie de dimensiuni mari, managementul rețelei este unul dintre factorii care decide succesul acesteia.

Acesta este contextul actual care a dus la alegerea temei pentru lucrarea prezentă. Lucrarea de față își propune să realizeze un pachet demonstrativ pentru managementul echipamentelor din arhitectura IaaS, oferind capabilități de abonare și de dezabonare de echipamente în IaaS, de monitorizare a echipamentelor, de setare și configurare precum și de preluare a parametrilor echipamentelor, de actualizare a bazei de date comune întregului proiect, precum și de preluare a evenimentelor trimise de echipamente și informare a administratorului. Toate aceste capabilități sunt disponibile la distanță și realizate cu un cost redus.

Această lucrare propune o soluție inovativă prin care managementul de rețea dar și verificarea prezenței și disponibilității resurselor sunt abordate într-un mod diferit de cele existente până acum și anume prin prisma capabilităților și caracteristicilor retelelor de socializare.

Conversia de la protocolul de mesagerie instantă XMPP la protocolul de monitorizare și management de rețea SNMP reprezintă motorul si obiectivul principal al lucrării de față. Aceasta conversie asigură verificarea prezenței și disponibilității unor resurse sau echipamente, agregarea de noi entități de rețea, având anumite capabilități tehnice, în colonia de resurse Iaas într-un mod original și prietenos utilizatorului.

Lucrarea va prezenta în final o aplicație ce poate permite potențialilor clienți să vizualizeze o listă de echipamente în vederea rezervării acestora, monitorizării și managementului în măsura în care acestea admit.

Se dorește realizarea unui mecanism de publicare automată a prezenței și disponibilității entitătilor de rețea în ideea creșterii performanțelor coloniei Iaas prin posibilitatea tratării acestora la distanță și în timp util. Notificările amintite vor fi vizibile atât administratorului cât și persoanelor cărora le este permis accesul în colonie.

Un aspect foarte important este dat de configurarea parametrilor de interes în funcție de permisiunile și capabilitățile dispozitivelor.

Un alt obiectiv este reprezentat de evidențierea importanței reducerii costurilor de mentenanță ce survine în urma monitorizării la distanță a echipamentelor, în principal a stării operaționale.

Totodată lucrarea are un deosebit potențial didactic întrucât oferă studenților posibilitatea de a se familiariza cu protocoalele utilizate: XMPP și SNMP și cu funcționalitățile acestora în vederea monitorizării și managementul unui echipament.

În vederea realizării acestor obiective s-au urmărit documentarea și studierea domeniului monitorizării și managementului de rețea prin prisma protocoalelor SNMP și XMPP. Aplicația finală are la bază atât analiza protocoalelor amintite cât și studiul programelor utilizate pentru obținerea produsului final și anume convertorul de protocol.

Protocolul SNMP – Simple Netwok Management Protocol

Protocolul SNMP a luat naștere în anul 1988 și a reprezentat o soluție standardizată și de efect în domeniul managementului dispozitivelor de rețea. Fiind bazat pe stiva de protocoale TCP/IP acesta aducea inovație spre deosebire de competitorul său direct din acea perioadă CMIP ce avea ca fundament nivelurile OSI.

Nevoia, în creștere, de protocol standard a condus la introducerea SNMP, implementâdu-se un set simplu de comenzi pentru gestionarea și monitorizarea la distanță a nodurilor: switch-uri, routere, servere, stații de lucru și multe alte dispozitive. Astfel SNMP a preluat locul vechiului protocol de management Simple Gateway Monitoring Protocol ( SGMP) nefiind compatibile [5].

Arhitectura Simple Network Management Protocol

Fiind construită după modelul client-server, arhitectura SNMP prezintă două entități fundamentale: agentul și managerul.

Agentul este o aplicație care rulează pe orice echipament având capabilități SNMP, ce transmite informații managerului ca urmare a interogărilor făcute de acesta. Răspunsul poate conține date despre starea nodului sau configurarea acestuia. În afară de răspunsurile la cererile managerului agentul trimite asincorn informații cu privire la evenimentele neprevăzute ce pot apărea în rețea. Agentul poate fi inclus în sistemul de operare ( Internetwork Operating System de la CISCO) sau poate fi un program independent.

Managerul este serverul pe care rulează diferite aplicații de management. Este cel care interoghează unul sau mai mulți agenți primind toate informațiile pe portul 161, excepție facând cele legate de evenimentele apărute pe nodul agent care sunt recepționate pe portul 162 [5]. Poartă adesea numele de stație de management a rețelei – Network Management Station (NMS).

În Figura 1 este ilustrată o arhitectură simplă a unei rețele ce utilizează Simple Network Management Protocol.

Noțiunile de bază utilizate de SNMP vor fi descrise în subcapitolul următor și cuprind:

– Structure Management Information (SMI) – o platformă conceptuală ce definește regulile de descriere a informației de management;

– Manangement Information Base (MIB) – o bază de date „virtuală” ce conține informații despre dispozitivele aflate sub management [4];

– Object Identifier (OID) – indetificator unic, numeric, pentru informația de management;

– Basic Encoding Rules (BER);

Fișiere utilizate de SNMP: SMI și MIB

Informațiile schimbate între un agent și un manager SNMP în timpul unei comunicații poartă denumirea de informații de management. Pentru ca entitățile să poată înțelege în același mod informațiile de management este necesar să existe un limbaj comun format în acest caz din obiecte gestionate (managed objects – Mos) sau obiecte MIB reprezentând părți componente ale Management Information Base (MIB) [2].

Fișierul MIB are forma unui depozit de date din care managerii pot prelua informații prin transmiterea de cereri către agenții SNMP. Întrucât, în fișierul MIB, nu există date propriu-zise, reale, acesta nu trebuie privit ca bază de date. În MIB datele sunt stocate intern, pe echipament. În acest sens putem considera un bun exemplu registrul care numară pachetele recepționate pe un port. De remarcat este faptul că un agent SNMP poate implementa mai multe fișiere MIB, acestea fiind standard sau specifice anumitori vendori.

Informațiile de management reținute în MIB se pot clasifica în patru categorii având trei scopuri diferite:

Informații de stare

Informații de configurare fizică

Informații de configurare logică

Informații istorice

Informațiile de stare sunt cele mai importante pentru monitorizarea unei rețele. Acestea

conțin date cu privire la starea nodului și anume dacă funcționează în mod corect, care este cea mai gravă alarmă sau care sunt alarmele curente, intervalul de timp de la ultima repornire a sistemului. La acestea se adaugă informații ce au rolul de a descrie performanța curentă, date despre numărătoare de pachete și conexiuni pentru diverse protocoale, utilizarea memoriei, utilizarea lățimii de bandă și încărcătura curentă a procesorului. Aplicațiile de management pot doar citi aceste informații neavând permisiunea să le modifice, deoarece sunt proprii echipamentelor.

Informațiile de configurare fizică conțin și descriu adrese Media Access Control, furnizează detalii despre tipul dispozitivului, porate implementa mai multe fișiere MIB, acestea fiind standard sau specifice anumitori vendori.

Informațiile de management reținute în MIB se pot clasifica în patru categorii având trei scopuri diferite:

Informații de stare

Informații de configurare fizică

Informații de configurare logică

Informații istorice

Informațiile de stare sunt cele mai importante pentru monitorizarea unei rețele. Acestea

conțin date cu privire la starea nodului și anume dacă funcționează în mod corect, care este cea mai gravă alarmă sau care sunt alarmele curente, intervalul de timp de la ultima repornire a sistemului. La acestea se adaugă informații ce au rolul de a descrie performanța curentă, date despre numărătoare de pachete și conexiuni pentru diverse protocoale, utilizarea memoriei, utilizarea lățimii de bandă și încărcătura curentă a procesorului. Aplicațiile de management pot doar citi aceste informații neavând permisiunea să le modifice, deoarece sunt proprii echipamentelor.

Informațiile de configurare fizică conțin și descriu adrese Media Access Control, furnizează detalii despre tipul dispozitivului, porturile ce sunt disponibile și numere seriale. Acestea sunt specifice nodului, aplicațiile de management neavând permisiuni suficiente pentru a le modifica. Informațiile de configurare fizică au particularitatea că se schimbă foarte rar sau deloc, ceea ce înseamnă că, pentru eliminarea interogărilor repetate către agent, este recomandat ca aceste date să fie memorate în baza de date proprie a aplicațiilor de management.

Setarea adreselor IP, a numerelor de telefon, a interfețelor sau în general a resurselor logice reprezintă nimic altceva decât configurarea logică. Aplicațiile de management și administratorii au posibilitatea de a modifica aceste informații. Echipamentele nu pot schimba aceste configurații, de aceea ele pot fi memorate într-o bază de date.

Performanțele nodurilor și fișierele jurnal (logs) definind evenimentele apărute se încadrează în rândul informațiilor istorice. Acestea sunt informații cu un caracter mai special întrucât nu conțin resurse gestionate.

Fișierele MIB nu sunt dependente de un anumit protocol. Fiind una dintre noțiunile de bază din Simple Network Management Protocol, acest tip de fișiere are particularitatea că pentru SNMP trebuie construit după un anumit limbaj numit structura informației de management – Structure of Management Information (SMI).

Limbajul SMI prezintă un set de reguli complexe în conformitate cu Abstract Syntax Notation One (ANS.1) [3] în vederea descrierii informațiilor de management. Modul de reprezentare al datelor și modul de transmitere între agenți și manageri, în cadul SNMP, sunt definite prin ANS.1, concept independent de mașină.

ANS.1 prevede existența a trei atribute ce caracterizează fiecare tip de obiect: o sintaxă, o codificare și un nume.

Tipul de dată sau structura tipului unui obiect este definită prin sintaxă. Spre exemplu, obiectele pot avea tipul string sau întreg.

Codificarea utilizează un cuvânt de octeți contruit în conformitate cu regulile de bază de codificare, Basic Encoding Rules (BER). Această metodă presupune descrierea modului în care sunt codificate și decodificate obiectele astfel încât să poată fi transmise peste un anumit

mediu, cum este Ethernet [1]. Relația dintre codul sursă și codul în limbaj masină poate fi o aproximare, pentru o mai bună înțelegere, a relației dintre ASN.1 și BER.

Numele este un identificator unic de obiect (Object Identifier – OID) asignat administrativ. Acesta are rolul de a numi tipurile de obiecte gestionate, însă poate fi utilizat și pentru identificarea în cadrul altor standarde. OID are scopul de a identifica obiecte, indiferent de semantica cu care este asociat cu obiectul definit [6].

Obiectele gestionate sunt organizate într-o ierarhie arborescentă. Această structură este

baza schemei de nume a SNMP. Arborele are ca punct de pornire nodul numit rădăcină,

neetichetat, legat cu alte noduri etichetate. Fiecare nod poate avea, la rândul său noduri copii

cu etichete, în acest caz nodul devenind un sub-arbore [6] sau o ramură a subarborelui format de nodul părinte. În Figura 2[3], un astfel de sub-arbore este conținut de nodul iso(1). Etichetele sunt formate dintr-o pereche formată dintr-un număr întreg și o descriere text. Un nod care nu are noduri copii poartă numele de nod-frunză și este nodul care poartă informație despre obiectul gestionat.

Figura 2 [3] prezintă structura ierarhică a primelor niveluri ale arborelui de

MIB. Nivelurile superioare ale arborelui sunt standard, iar cele de mai jos sunt specifice diverselor organizații. Nodul rădăcină este format din cel puțin 3 noduri copii:

– ccitt(0) – administrat de Comitetul Internațional Consultativ de Telegrafie și Telefonie, International Telegraph and Telephone Consultative Comitee (CCITT);

– iso(1) – administrat de Organizația Internațională de Standardizare, International Organization for Standardization (ISO);

– joint-iso-ccitt(2) – administrat împreună de ISO și CCITT [5]. Sub nodul iso(1), ISO a creat un sub-arbore care să poată fi utilizat de alte organizații, org(3). Sub-arborele dod(6) aparține de Departamentul de Apărare al SUA, Department of Defense, DoD.

Un OID este construit din o serie de numere întregi bazată pe numerele nodurile arborelui, separate prin puncte. Totodată, OID are asociat și un nume, prin care nodul să fie

ușor identificat de către o persoană.De exemplu, pentru internet(1) OID este 1.3.6.1. definit astfel:

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

Sub-arborele directory(1) este rezervat pentru a fi folosit în viitor. Ramura de management, mgmt(2) definește un set standard de obiecte care pot fi utilizate în managementul Internetului. Ramura experimentală este rezervată în scopuri de cercetare și testare, pentru obiecte care nu au fost standardizate încă. Sub ramura privată, private(4), se definesc obiecte care sunt definite de organizații, companii sau chiar persoane fizice [1].

Producătorii își pot crea obiectele în ramura enterprise(1). Autoritatea de Asignare a Numerelor în Internet, Internet Assigned Numbers Authority (IANA), se ocupă de definirea acestor numere de către companii, instituții, indivizi etc. OIDs din care pornesc sub-arborii cu MIB ai companiilor sunt actualizate periodic, chiar zilnic, pe site-ul celor de la IANA. În prezent sunt peste 40000 de companii care s-au înregistrat, câteva exemple pot fi văzute în Tabelul 1 [8]. Înregistrarea numerelor este gratuită.

Tabel : OID asociate companiilor

Operațiile de bază în cadrul SNMP

Managementul SNMP înglobează un set de 5 operații care reprezintă primitivele funcționale ale acestui protocol. Ele sunt:

– GET

– GET-NEXT

– SET

– GET-RESPONSE

– TRAP

Toate aceste operații includ, de obicei, un parametru care poartă informația de management, format dintr-o listă de legături de variabile (variable bindings, varbinds). O legătură de variabilă este un obiect MIB care permite destinatarului să vadă informațiile cerute de la sursă [1]. Legătură de variabilă poate fi privită ca o pereche (OID, valoare) care identifică obiectul MIB și valoarea acestuia [2].

Operația SNMP get

Pentru a prelua informații de management de la un agent SNMP, un manager SNMP utilizează o operație get pentru care legatura de variabilă va avea o valoare specificată nulă (null), managerul fiind interesat de aflarea acestui parametru.

Deși se pot prelua mai multe obiecte MIB în același timp, SNMP limitează dimensiunea maximă a mesajelor la o anumită valoarea ( posibil de 484 octeți) [2].

În Figura 3 se poate vedea procesul de trimitere a cererii de către manager și primirea

răspunsului de la agent.

Există posibilitatea ca un agent sa nu trimită nici o valoare managerului, dacă agentul care răspunde la cerere nu poate prelua toate valorile din lista de OID-uri.

Operația SNMP set

Pentru scrierea unor valori în obiectele MIB managerul SNMP apelează la o operație de tip set. Altfel spus pentru modificarea sau crearea unui nou obiect MIB se va utiliza o operație set. De remarcat este faptul că un manager poate modifica mai multe obiecte simultan [1].

Instrucțiunea cerere realizată printr-o operație set este structurată asemănător cu cea pentru get sau get-next . Există totuși o diferență datorată faptului că legătura de variabilă va fi setată cu valoarea ce trebuie setată pentru obiect, nu cu o valoare nulă [2]. Operațiile set au scopuri de utilizare multiple cel mai important fiind configurarea dispozitivelor prin modificarea unor parametrii. De asemenea, crearea și ștergerea entităților logice dintr-un fișier MIB sunt operații indispensabile realizate prin funcția set. Nu există operații SNMP dedicate pentru crearea și ștergerea de informații cu ajutorului protocolului, astfel că este nevoie să se folosească operația set. Pentru a permite aceste acțiuni, trebuie să existe și un câmp pentru statutul fiecărei intrări.[2].

Un al treilea rol al operației set este de a stimula agentul să efectueze o acțiune, de

exemplu o comandă ping sau traceroute.

Operația SNMP get-next

Un manager utilizează o cerere get-next pentru a prelua informații de la agent, la fel ca

în cazul operației get. Dar get-next nu specifică în mod direct ce obiecte trebuie să transmită

agentul, în schimb, pentru fiecare OID din cerere, agentul trebuie să returneze primul obiect

care urmează după numărul OID specificat. Nu e obligatoriu ca OIDs specificate să fie

identificatori de obiecte propriu-zise (noduri frunză în arbore). În general se folosește pentru a

lua următoarea valoare dintr-un tabel sau listă.De exemplu, presupunând că agentul are un MIB ca cel din Figura 5 (după un model de MIB din [2]) o cerere get-next cu OID cu valoarea 0 este echivalentă cu cererea valorii obiectului cu numărul 1.3.6.1.555.7.1.1.0. Același răspuns ar fi fost primit și dacă OID transmis ar fi fost 1.3.6 sau 1.3.6.1.500. Dacă managerul face o nouă cerere către agent pe baza răspunsului primit anterior, adică cu OID-ul1.3.6.1.555.7.1.1.0, al obiectului countA, noul răspuns va întoarce o instanță countB. În continuare, o nouă operație get-next va prelua obiectul cu indexul 1 din coloanaA. Această parcurgere poate continua, pas cu pas, până la ultimul obiect întâlnit în MIB, adică MIBAgent.2.2.4.3, conform săgeților punctate din Figura 18. Se observă că get-next este echivalentul operației get ce are ca parametru OID obiectului de dinaintea lui, în ordine lexicografică. Atunci se pune întrebarea care este rolul acestui tip de operații. Există situații când managerul nu știe ce MIBs poate prelua de la un agent și atunci este mult mai simplu să transmită cereri get-next pentru toate obiectele întâlnite, începând de la nodul 0. Acest tip de execuŃie se nume_te parcurgerea MIB (walking a MIB). Parcurgerea MIB este utilă, în special, în cazul tabelelor. Înregistrările din tabel sunt create dinamic și șterse de către agent, în timp. Get-next permite găsirea tuturor datelor din tabel, indiferent de indexul lor. Un lucru interesant este faptul că tabelul va fi parcurs pe coloane, nu pe rânduri. Dacă totu_i parcurgerea este necesară, se pot trimite cereri get-next cu parametrii mulți dați de numerele OID coloanelor [2]. Pentru exemplul din Figura 18 acest lucru s-ar scrie printr-o serie de operaŃii get-next cu următorii parametri:

Get-next(tabelA.1.1, tabelA.1.2, tabelA.1.3, tabelA.1.4)

Get-next(tabelA.1.1.1, tabelA.1.2.1, tabelA.1.3.1, tabelA.1.4.1)

Get-next(tabelA.1.1.2, tabelA.1.2.2, tabelA.1.3.2, tabelA.1.4.2)

Get-next(tabelA.1.1.3, tabelA.1.2.3, tabelA.1.3.3, tabelA.1.4.3)

Va rezulta preluare tuturor intrărilor din tabelul tabelA, pe rânduri.

Figură 5: Parcurgere a arborelui MIB prin get-next

Operația SNMP trap

Mesajul trap (capcană, alarmă) este transmis de agent managerului. Este o notificare

asincronă care folosește, față de celelalte operații, portul 162. Din cauză că agentul nu așteaptă nicio confirmare din partea managerului, trap-urile nu sunt sigure[1].

Acestea pot fi pierdute între agent și manager, iar agentul să nu fie informat. Alarmele conțin următoarele informații:

– Emitentul alarmei – parametru care specifică adresa agentului și tipul sistemului

care a emis trap-ul;

– Evenimentul produs – identifică tipul evenimentului;

– Momentul producerii – un identificator de timp care precizează când a avut loc evenimentul, timp care nu este absolut, ci relativ la timpul de pornire al dispozitivului;

– Informații adiționale, incluse într-un set de legături de variabile – aceste legături de

variabile conțin informații care pot fi relevante pentru manager în găsirea unei soluții pentru eventuala problemă apărută [2]

Capcanele se împart în două categorii: generice sau specifice companiilor. Există 7

alarme generice, numerotate de la 0 la 6. Acestea sunt descrise în Tabelul 2 [9].

Capcanele specifice sunt cele care conferă putere mecanismului de recepție a evenimentelor. Oricine are definit, prin organizația IANA, un număr, poate defini alarme specifice care consideră că trebuie monitorizate. Alarmele specifice se identifică prin două

elemente: ID-ul companiei care a definit alarma și numărul specific al alarmei asociat de către

companie [1]. Pentru o companie care s-a înregistrat cu numărul 8076, va avea

OID al companiei 1.3.6.1.4.1.8076. OID poate fi subdivizat în alte OIDs, de exemplu 1.3.6.1.4.1.8076.45.3 ar putea fi OID al unei alarme.

Informațiile transmise de alarmele generice în legăturile de variabile sunt ușor de urmărit, fie că sunt timpii de pornire ai dispozitivului, fie numele interfețelor care și-au schimbat starea. În contrast, alegerea informațiilor purtate de o alarmă specifică depinde de

persoana care face acest lucru, deci de ce consideră aceasta că este relevant să cunoască receptorul alarmei. Se pot transmite și obiecte special concepute pentru a fi incluse în alarme

[1].

Tabel : Alarmele SNMP generice

Operația get-response

Agentul transmite un răspuns către manager prin get-response, indiferent dacă a primit un mesaj de tip get, get-next sau set de la manager. Un răspuns get-response este format din:

– Un identificator al cererii către care este îndreptat răspunsul;

– Un status al erorii ce deține un cod al erorii care indică dacă cererea a fost executată cu succes sau nu;

– Un index de eroare prin care sunt transmise mai multe informații, în cazul în care a

avut loc o eroare;

O listă de legături de variabile. Aceste variabile conțin informația de management

care este returnată, ca răspuns propriu-zis. În cazul unui răspuns la o cerere get, fiecare legătură de variabilă conține un OID și valoarea preluată a obiectului MIB.

Răspunsul este asemănător și pentru get-next, dar, după cum a fost explicat anterior, OID și valoarea sunt ale primului obiect după cel din cerere, în ordine lexicografică. Pentru operația set, răspunsul va fi format din OID ale obiectelor și valorile care au fost setate [2].

SNMP peste UDP și TCP-IP

Conform [7], este sugerat să se configureze entitățile SNMP care conțin aplicația ce răspunde la comenzi să asculte pe UDP, portul 161. Mai mult, se sugerează ca entitățile care conțin aplicația de receptor de notificări să asculte pe portul UDP 162

Protocolul UDP a fost ales în favoarea protocolului Transmission Control Protocol (TCP) pentru că nu este bazat pe conexiune, astfel că nu se realizează nicio legătură între agent și manager când datagramele sunt transmise între acestea. Dar acest aspect face ca UDP să nu fie sigur, lăsând la latitudinea SNMP să determine sau nu dacă datagramele au fost pierdute. Acest lucru se realizează prin cronometrarea timpului până la primirea răspunsului.Dacă răspunsul nu ajunge într-un anumit interval de timp pre-configurat, se reia transmiterea. De asemenea numărul de retransmisii este configurabil [1].

Problema reală care apare în urma pierderii mesajelor este în cazul alarmelor trimise și

pierdute până să ajungă la manager. Managerul nu va ști niciodată de eroarea apărută pentru

că nu trebuie să confirme primirea alarmelor [1]. Acest lucru este soluționat de

operația de informare (inform), începând cu SNMPv2.

Figura 6 [4] prezintă stiva de protocoale TCP/IP utilizată de SNMP.

La nivelul aplicație al stivei se află managerul sau agentul care decide ce trebuie transmis sau ce răspuns să dea înapoi. Nivelul UDP permite comunicarea între gazde. Antetul UDP conține, printre altele și porturile sursă și destinație. Protocolul IP încearcă să transmită datele către destinația specificată, adică adresa IP. Nivelul legătură de date, Media Access Control (MAC) transmite rețelei fizice pachetele care vor fi rutate până la destinația finală [1].

Există și posibilitatea de a configura protocolul SNMP să funcționeze peste TCP, dar acesta nu este un standard. Scopul principal al folosirii TCP este de a putea transmite date de o dimensiune mare, deoarece TCP oferă controlul fluxului și o segmentare eficientă a pachetelor. TCP garantează că datele sunt în ordine și nu sunt alterate, pierdute sau duplicate,

în lipsa unui atac de securitate [5].

Există implementări și peste alte protocoale: OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP) sau Internet Packet Exchange (IPX) [7].

Protocolul XMPP

Principii funcționale și fundamente

Standardul XMPP ( eXtensible Messaging and Presence Protocol) definește un protocol de comunicație în timp real utilizat în cadrul infrastructurilor ce suportă trimiterea și recepționarea de mesaje între sisteme distribuite. Limbajul de comunicație utilizat în cadrul acestui protocol este XML (eXtensible Markup Language). XML definește un set de reguli pentru codarea datelor într-un format comun și ușor de interpretat atât pentru utilizatorul uman cât și pentru utilizatorul mașină. Protocolul XMPP a fost numit inițial Jabber și dezvoltat de comunitatea open-source cu același nume. Pe lângă asigurarea schimbului de mesaje în timp real, acest model face posibilă publicarea prezenței și disponibilității unui utilizator mașină în cadrul unei infrastructuri. Proiectat pentru a fi extensibil, XMPP este utilizat în servicii de tipul publică-subscrie (publish-subscribe), în semnalizarea VoIP, transferuri de fișiere, jocuri pe calculator, în conceptul de internet al obiectelor (Internet of Things) punctând spre sectorul rețelelor inteligente și nu în ultimul rând în serviciile oferite de rețele de socializare.

Spre deosebire de celelalte standarde, XMPP prezintă o serie de puncte forte cum ar f

Stabilitate – XMPP este un concept dezvoltat pe parcursul a 14 ani, începand cu anul 1999. Testarea la scară largă a facut posibilă apropierea de un produs final ce reprezintă baza unui volum imens de servicii implementate pentru milioane de utilizatori;

Securitate – XMPP asigură pe langă o metodă puternică de autentificare și posibilitatea criptării canalului în scopul unei comunicații sigure și rezistentă la atacuri informatice provenite din exterior;

Arhitectură descentralizată – XMPP propune implementarea unei arhitecturi descentralizate client-server cu n servere neavând un nod central. Astfel orice utilizator, persoana fizică sau organizație, poate rula propriul server de XMPP care poate fi legat ulterior la internet prin DNS (Domain Name System);

Extensibilitate – Aflat sub managementul organizației XMPP Standards Foundation, protocolul XMPP este un standard deschis. Acest lucru inseamană că oricine poate crea, după bunul plac, un serviciu XMPP care să interopereze fără probleme cu alte servicii având acest tip.

XMPP versus Email

Tehnologiile email și XMPP sunt asemănătoare prin funcționalitate, însă prezintă câteva diferențe arhitecturale și de rutare a mesajelor de la sursă la destinație.

În cazul arhitecturii email, clientul final inițiază o conexiune la un server propriu de email. Acesta reprezintă punctul de start în cadrul procesului de rutare a pachetelor peste rețea. Mesajul este dirijat prin mai multe servere de email pentru a ajunge la destinație. Pe scurt numărul de servere utilizate în livrarea mesajului prin email este n, unde n în general este mai mare decât 2.

În ceea ce privește arhitectura XMPP, pentru transmiterea unui mesaj la un anumit contact din listă, clientul de XMPP inițiază o conexiune la serverul local. Spre deosebire de cazul email, acesta se leagă în mod direct la serverul de care aprține destinatarul. Prin îndeplinirea acestei condiții de minim al numărului de servere, întârzierea pachetelor este considerabil redusă, iar securitatea informațională este sporită prin eliminarea “spoofing-ului ”

Servicii oferite de XMPP

În acest context, un serviciu este o funcție care poate fi utilizat de orice aplicație dată. Implementările XMPP furnizează prin definiție următoarele servicii de bază:

Codarea canalului – cu ajutorul acestui serviciu, definit în specificația [14], se realizează criptarea conexiunii între client și server sau între două servere; reprezintă un aspect foarte important în construcția de aplicații sigure;

Autentificarea – acest seviciu, definit tot în cadrul [14], asigură faptul că entitățile ce doresc să comunice peste rețea sunt întâi autentificate de un server ce permite sau nu accesul la rețea;

Prezență – serviciu definit în specificația [15], acest serviciu permite unui client să afle informații despre disponibilitatea și prezența altor entități. În mod normal acestea sunt informații private ce sunt publicate numai în cazul unei subscrieri explicite realizată între două parți participante;

Listă de contacte – Serviciu explicitat de [15] prin care se poate stoca un registru incluzând contacte pe un server de XMPP.

Mesageria unu–la–unu – permite schimbul de mesaje între două entități de tip XMPP : programe bot, servere, diverse dispozitive, servicii web XMPP;

Mesageria multi–party – serviciu definit de [16] permite accesul în grupuri de chat în vederea schimbului de mesaje între mai mulți utilizatori. Mesajele pot fi sub forma limbajului obișnuit sau poate conține extensii XML pentru întrebuințări avansate cum ar fi configurația chat–room–ului, diferite sesiuni de control etc.

Descoperirea de servicii – definită în cadrul [17] presupune posibilitatea de a afla ce servicii poate oferi o altă entitate sau entitățile ce au același tip;

Publicarea capabilităților – explicitată în specificația [18], reprezintă o extensie a serviciului de prezență și vine în plus cu informații referitoare la caracteristicile tehnice ale unei entități;

Managementul fluxului de lucru – [19], permite angajarea într–un flux de lucru structurat cu o altă entitate XMPP în scopul de a oferi suport la execuția anumitor acțiuni;

Sesiuni media peer-to-peer – acest serviciu este descris de [19] și oferă posibilitatea de a negocia și administra o sesiune media cu o altă entitate. Este util în sesiuni precum : voice chat, video chat, transferuri de fișiere sau alte interacțiuni în timp real.

Aplicații XMPP

Avem la dipoziție o multitudine de servicii însă întrebarea este: ce aplicații putem realiza cu aceste servicii? Iată cateva posibile răspunsuri la această întrebare:

Mesageria instantă – sistemele clasice de mesagerie pe care majoritatea oamenilor le folosește combină trei dintre serviciile enumerate anterior: prezență, listă de contacte și mesageria unu-la-unu; în general, aplicațiile de mesagerie instantă au scheletul structurat pe aceste trei fundamente;

Grupuri de chat – comunicația multi–party permite crearea de grupuri de chat după modelul utilizat de Internet Relay Chat (IRC). Adesea, acestea sunt folosite în sistemele de tranzacții în timp real din domeniul finanțelor, săli de clasă virtuale, servicii militare etc.

Sisteme de control – aplicațiile implementate în acest domeniu includ managementul de rețea, telemetrie științifică și controlul roboțilorș

Geolocație – serviciul de notificare XMPP reprezintă baza unor aplicații fascinante precum urmărirea vehiculelor;

Middleware și cloud computing – un număr foarte mare de companii și grupuri de cercetare lucrează intens la sisteme XMPP pentru servicii computaționale și managementul infrastructurilor ce utilizează cloud computing. Deși este surprinzătoare apariția XMPP în acest domeniu unde în mod obișnuit comunicarea se realizează la cele mai înalte standarde de securitate, adoptarea infrastructurii XMPP este justificată de capabilitatea acestui protocol de a realiza nu doar funcții de mesagerie instantă;

Distribuția de date – sectorul aplicațiilor întalnite în rețelele de socializare înregistrează o considerabilă creștere în ceea ce privește utilizarea serviciului de notificare XMPP. Acest fapt este datorat necesității de actualizare ca efect al polling–ului constant. Implementarile bazate pe protocolul HTTP nu reușesc să realizeze în parametrii normali acestă actualizare. În contrast, serviciul de notificare XMPP permite în plus și salvarea de resurse ale serverului dar și a lărgimii de bandă întrucât update-ul se face numai în momentul în care o modificare a fost detectată în rețea.

Voce peste IP (Voice over Internet Protocol) – extensiile XMPP pentru sesiuni media, numite Jigle, au fost standardizate prin XSF și implementate după bunul plac de către Nokia si One Laptop Per Child. Aceleași extensii pot fii utilizate pentru a negocia o largă plajă de sesiuni media precum transmisiile video, transferurile de fișiere etc.

Servicii de identitate – dată fiind existența unor identificatori stabili (JabberIDs) și serviciul de autentificare robustă , este posibilă utilizarea XMPP pentru crearea unor servicii complexe de identitate și autorizare.

Adresare, domenii, utilizatori și resurse XMPP

Comunicația XMPP rulează peste o rețea. Astfel, fiecare entitate trebuie să folosească o adresă, denumită în acest caz JabberID. În mod obișnuit protocolul XMPP depinde de conceptul Domain Name System (DNS) în vederea obținerii structurii ce stă la baza adresării. Pentru utilizatori, JabberID-urile au un format asemanător adreselor email, această convenție reprezentând un aspect pozitiv al standardului XMPP. Un alt avantaj este acela că formatul utilizează infrastructura DNS în întregime, dar și spațiul de adresare Domain Name System.

Fiecare JabberID are în componență un spațiu destinat domeniului, fully qualified domain name(FQDN). La instalarea server-ului de XMPP, trebuie ales un domeniu cum ar fi jabber.org sau gmail.com.

În momentul creării unui cont, în scopul accesării unui serviciu XMPP, trebuie ales un JabberID asociat identității unei entități în rețea sau identitatea poate fi generată automat. După cum am mai precizat formatul acestuia este asemanător unei adrese de email. Mai mult, în funcție de tehnicile de implementare, JabberID-ul poate să coincidă cu o altă adresă de email personală. De precizat este faptul că în cadrul structurii adresei Jabber, porțiunea dedicată utilizatorului este case-insensitive: [anonimizat] va fi identic cu [anonimizat].

La conectarea unui client la un server XMPP, se alege sau este asignat automat un identificator de resursă pentru un anumit tip de conexiune. Acest parametru este utilizat

pentru rutarea traficului către acea conexiune, făcându-se abstracție de alte conexiuni deja deschise în acel moment. Resursa este adaugată la finalul structurii de adresare astfel:

[anonimizat]/iustinian. Acest procedeu permite unei entități XMPP sa realizeze o cerere sau un schimb de mesaje privat cu un anume dispozitiv asociat unui anumit cont; mai multe dispozitive asociate unui cont pot avea diferite disponibilități, indicatori de prezență diferiți și capabilități proprii. În ceea ce privește structura numelui resursei, aceasta este un șir de caractere incluzând spații sau caractere speciale.

Primitive în comunicația XMPP

Schimbul de mesaje în cadrul protocolului XMPP are la bază strofa XML, unitate de comunicație asemănatoare unui pachet sau mesaj din alte protocoale de rețea. Aceasta are următoarele particularități funcționale și constructive:

Tipul strofei care poate fi definit sub trei forme: mesaj, prezență sau iq (info-query). Fiecare dintre aceste trei modele este rutat diferit de către servere și tratat în mod diferit de la client la client;

Valoarea tipului strofei reprezintă un parametru care variază de la un tip la altul. Această valoare diferă mai degrabă în funție de modul în care este procesată strofa la nivel de echipament;

Elementul sau elementele copil care generează încărcătura strofei. Încărcatura poate fi prezentată în mod direct unui utilizator sau poate fi procesată automat, aspect dependent în întregime de specificațiile ce caracterizează namespeace-ul payload-ului.

În urmatoarele secțiuni aceste particularități vor fi descries detaliat pentru o mai bună întelegere a conceptului de strofă XML.

Tipul mesaj

Strofa <message/> este practic metoda “push ” utilizată în scopul obținerii informațiilor. Deoarece mesajele nu sunt urmate în mod obișnuit de o confirmare a primirii (acknowledge), mecanismul rapid prin care sunt culese informațiile de la un echipament la altul este de tipul “fire-and-forget”. Strofa mesaj este folosită pentru mesagerie instantă, groupchat, alarme și notificări sau alte aplicații de acest fel.

În funcție de tipul atributului, mesajul se poate clasifica astfel:

normal – are un comportament similar cu cel al email–ului întrucât este singurul mesaj care poate primi un răspuns;

chat – acest tip de mesaj este cel schimbat în sesiunile de comunicație în timp real, între două entități, așa cum doi prieteni comunică prin chat;

groupchat – asemănător mesajelor din Internet Relay Chat (IRC), mesajul grupchat este schimbat la interacțiunea simultană a mai multor utilizatori;

headline – utilizat pentru a trimite alarme și notificări, fără a permite exitența unui răspuns;

error – dacă o eroare apare în legatură cu un mesaj anterior, entitatea va detecta această eroare și va returna un mesaj de tip eroare;

Adițional acestor mesaje, strofa XML poate conține adresele sursei, destinației și atributul ID în scopul unei bune urmăriri în cadrul rețelei. În mod natural, adresa sursei coincide cu JabberID–ul entității ce a inițiat dialogul și adresa destinației este aceeași cu JabberID–ul destinatarului. Adresa destinației nu este adăugată la sursă, ci de către serverul sursă pentru o imunitate ridicată împotriva spoofing–ului.

Mesajele conțin de asemenea elemente de încărcare. Specificațiile XMPP definesc astfel de elemente cum ar fi <body/> și <subject/>, utile în situația dialogului unu–la–unu. Un simplu mesaj este exemplificat după cum urmează:

<message from="[anonimizat]/foo"

to="[anonimizat]"

type="chat">

<subject>Query</subject>

</message>

Ordinea elementelor de încărcare nu este importantă, însă se preferă ordonarea alfabetică a acestora. Foarte important este faptul că payload–ul nu este compus doar din componente definite de specificațiile standardului XMPP.

Tipul prezență

Reprezintă una dintre proprietățile distinctive ale sistemelor de comunicație în timp real. Strofa de tipul prezență anunță care este diponibilitatea entităților într–o rețea și astfel se permite sau nu angajarea într–un dialog. Prin definiție este un catalizator în realizarea comunicației și colaborării peste Internet deoarece interacțiunea în adevaratul sens depinde de prezența entităților.

Status-ul online al unui utilizator poate fii observat doar de utilizatorii carora le este permis acest lucru, prin activarea unui serviciu de subscriere la prezență (presence subscription). Pentru aceasta entitatea va trimite o cerere de subscriere, care odată ce a fost aprobată, conduce la schimbul de notificări cu rețeaua. Pe scurt, modelul descrie faptul că strofa XML de tip prezență este în esență o metodă simplă și specializată publish-subscribe care are rolul de a publica starea unei entități: „online”, „offline”, „in a meeting” etc. În continuare este ilustrată o scurtă strofă XMPP de tip prezență:

<status>prezent: la curs!</status>

</presence>

În aplicațiile de mesagerie instantă XMPP, status-ul este afișat în lista de contacte a unei entități. Această listă conține JabberID-uri și starea asociată fiecăruia dintre ele.

Strofa XML IQ

Strofa Info/Query reprezintă o structură de bază pentru interacțiunile de tip cerere-răspuns și pentru fluxurile simple de lucru, asemănatoare cu structura metodelor GET, POST și PUT specifice standardului HTTP. Spre deosebire de strofa mesaj include doar un singur element de încărcare care determină ca cererea sa fie procesată sau o decizie să fie luată. În plus o entitate ce va trimite un astfel de format, obligatoriu trebuie să primească și un răspuns. Cererile și răspunsurile sunt urmărite cu ajutorul atributelor ID. Funcțiile realizate de strofa IQ pot fi urmatoarele:

get – o entitate realizează o cere de informații cum ar fi cele necesare pentru înregistrarea unui cont ( similar cu metoda HTTP GET);

set – entitatea interogator furnizează informații sau face o cerere ( similar metodelor HTTP POST sau PUT);

result – reprezintă rezultatul unei operații get sau un mesaj de confirmare în urma unei operații set( structurat precum codul de stare HTTP 200);

error – funcție cu ajutorul căreia o entitate intermediară, cum ar fi un server XMPP, notifică entitatea interogator că procesarea unei cereri get sau set nu s-a putut realiza;

Pentru crearea unei imagini clare și de ansamblu asupra funcționalității și structurii strofei XMMP IQ, în continuare este prezetată atât grafic cât și sub formă de cod, interacțiunea dintre două entități.

Figura 8 prezintă grafic modul în care se realizează atât o operație de tip get, cât și una de tip set.

Să presupunem un scenariu în care operația get ar trebui să aibă ca rezultat lista de contacte a unei entități. În acest caz strofa XMPP IQ ar putea arăta astfel:

<iq from="[anonimizat]"

id="rr82a1z7"

to=" [anonimizat]/pda"

type="result">

</query>

</iq>

Pentru adăugarea unui nou contact, în structura codului se va utiliza o operație de tip set. Secvența va avea următoarea formă:

<iq from="[anonimizat]/pda"

id="ru761vd7"

to="[anonimizat]"

type="set">

</query>

</iq>

Server-ul de XMPP va întoarce în acest caz un rezultat cuprinzând confirmarea actualizării listei de contacte.

<iq from="[anonimizat]"

id="ru761vd7"

to="[anonimizat]/pda"

type="result"/>

În ceea ce privește o operație IQ-get se urmărește obținerea unui anumit tip de informații precum formulare de înregistrare, date de configurare, servicii de descoperire sau liste de contact. Operatiile IQ-set crează, actualizează sau șterge informațiile menționate în cazul IQ-get.

Integrarea SNMP-XMPP

După cum am amintit și în capitolul anterior, standardul XMPP este o tehnologie open-source pentru comunicare în timp real, folosind Extensible Markup Language (XML) ca format de bază pentru schimbul de informații între entități. Utilizarea acestui limbaj reprezintă motorul sau condiția necesară și suficientă pentru a realiza conversia între protocoalele XMPP și SNMP. Trecerea de la un standard de mesagerie instantă la un standard de management de rețea a reprezentat o adevărată provocare tehnică, produsul final având totodată și o importanță aplicativă și didactică de efect.

Alegerea mediului de dezvoltare

În scopul realizării convertorului de protocol, au fost necesare numeroase medii de dezvoltare și aplicații. Acestea formează un ansamblu structural și funcțional în vederea atingerii obiectivului lucrării de față.

Pentru partea XMPP am utilizat:

Server Openfire

Openfire este un server de mesagerie instantă implementat pentru prima dată de Jabbber în anul 2008. Una dintre particularitățile Openfire este aceea că asigură servicii de transport în cadrul mesageriei instante având capabilitatea de a oferi conectivitate pentru multiple și diferite servicii de IM precum AOL Instant Messenger, Yahoo Instant Messenger, MSN/Windows Live Messaging, ICQ sau Google Talk. Limbajul de programare suportat de acesta este limbajul Java. Openfire se poate descărca de pe pagina http://www.igniterealtime.org/projects/openfire .

Clientul Spark

Este un client de mesagerie instantă optimizat pentru mediul de afaceri și organizații. Prezintă numeroase servicii precum group chat sau telefonie integrată și lucrând împreună cu Openfire oferă cea mai ușoară și sigură soluție de implementare pentru o rețea publică de mesagerie instantă.

Pentru partea SNMP am utilizat mediul software Dynamips. Acest program are capacitatea de a emula echipamente Cisco pe un calculator obișnuit. Creat în 2005, Dynamips oferă posibilitatea utilizatorilor săi de a lucra cu versiunile Cisco 7200, 3600, 3700, 2600 și 1700. În lucrarea de față a fost emulat un router Cisco 7200.

De asemenea pentru construirea aplicației și integrarea XMPP-SNMP, am folosit limbajul de programare Java și mediul de dezvoltare Eclipse 3.6.2. Au fost importate 4 librării deja existente de la Smack API.Cele 4 librării ( smack.jar, smackx.jar, smackx-debug.jar, smackx-jingle.jar ) conțin funcții implementate pentru conectarea la serverul de XMPP , pentru inițierea mesageriei, pentru transferul de fișiere între utilizatori precum și funcții care permit acțiuni de abonare și publicare la un nod (publish-subscribe). Smack este menit să fie ușor de integrat în orice JDK 1.5 existent sau în orice altă aplicație Java mai veche. Nu are dependențe externe (cu excepția funcționalității de chat Jingle), și este optimizat pentru a fi cât mai mic posibil. Bibliotecile ar fi construite din mai multe fișiere JAR pentru a oferi o mai mare flexibilitate:

smack.jar – oferă funcționalitatea de bază XMPP . Toate caracteristicile XMPP, care fac parte din XMPP RFC sunt incluse ;

smackx.jar – oferă suport pentru multe dintre extensiile (XEPs), definite de standardele XMPP, inclusiv chat multi-user, transfer de fișiere, căutarea utilizatorilor, etc ;

smackx-debug.jar – depanatorul GUI pentru protocolul de trafic. Acesta va fi utilizat automat atunci când este găsit in classpath și atunci când depanarea este activată.

Mașina de calcul utilizată pentru gazduirea programelor amintite și crearea convertorului XMPP-SNMP are urmatoarele specificații funcționale: Fujitsu Siemens Lifebook, Intel Core 2 Duo T8100 2,1 GHz, 2 GB DDR2, 80 GB, Windows XP Professional Service Pack 3.

Figură : Elemente de configurație a calculatorului

Configurarea serverului de XMPP și a contului de router

La instalarea serverului pe mașina locală, adresată prin localhost sau 127.0.0.1, trebuie setat un domeniu, un port de consolă securizat pentru administrator și un port de consolă pentru administrator.

Configurarea serverului se lansează imediat după instalare prin comanda “ Launch Admin” din fereastra de mai jos – Figura 10.

Pentru autentificarea administratorului de server se vor folosi:

Nume utilizator: admin

Parolă: admin

Setarea parametrilor pentru server se realizează începând cu numele de domeniu. Acesta este implicit același cu numele calculatorului pe care rulează serverul. Prin porturile 9090 sau 9091 se realizează conexiunea administratorului la sistem, din orice loc, în vederea modificării configurației serverului, creării sau ștergerii de conturi, adăugării de plug-in-uri serverului. Am ales modelul de bază pentru acest pas.

Pasul următor presupune configurarea unei baze de date. Există două opțiuni pentru tipul bazei de date. Aceasta poate să fie integrată, având proprietatea că se populează pe măsură ce entitățile sunt adăugate sau poate să fie importată de pe propriul calculator. Am optat pentru o bază de date integrată, utilizatorii urmând sa fie stocați în baza de date a serverului.

În continuare, Figura 14 ilustrează fereastra de configurare pentru contul de router utilizat în aplicația noastră. Acesta va avea numele de utilizator dat de adresa IP pe care o va avea configurată pe interfața dintre calculator și router. Parola pentru accesul pe serverul XMPP este “parola”.

Configurarea router-ului în mediul Dynamips

Pentru a activa topologia se pornește mai întâi serverul Dynamips, iar apoi se rulează

fișierul .net (Dynagen), acesta din urmă reprezentând o imagine menită să simuleze router-ul nostru.

Imediat după executarea fișierului .net pe serverul Dynamips se înregistrează router-ul R1.

În consola Dynagen, prin comanda telnet R1 sau console R1 se conectează la consola router-ului R1 prin telenet. Pentru a porni sau opri routerul R1 se dau comenzile start R1, respectiv, stop R1.

La prima pornire, routerele nu sunt optimizate și folosesc o putere mare de procesare a calculatorului pentru că serverul Dynamips nu are capacitatea de a determina dacă un router este utilizat sau nu la un moment dat. Comanda idlepc get R1 va întoarce valorile ale parametrului idlepc care permit identificarea instrucțiunilor inactive. În Figura de mai jos sunt prezentate rezultatele acestei comenzi. Valorile idlepc returnate sunt în număr mai mare. Valorile considerate a fi cu un grad mai ridicat de optimizare sunt notate cu asterisc (*), dar nu este obligatoriu să fie așa. Se impune alegerea unei valori pentru parametrul idlepc în scopul reducerii semnificative a nivelului de utilizare al procesorului. Se observă de cele mai multe ori o scădere considerabilă în acest sens cu pană la 50 de procente.

Figură : Selectarea valorilor de activitate redusă

Comenzile folosite pentru a configura interfețele routerului R1 sunt:

R1>enable

R1#configure terminal

R1<config>#interface fastEhernet 0/0

R1<config-if>#ip address 192.168.50.2 255.255.255.0

R1<config-if>#no shutdown

R1<config>#exit

R1<config>#interface fastEhernet 0/1

R1<config-if>#ip address 192.168.11.1 255.255.255.0

R1<config-if>#no shutdown

Prin aceste comenzi se asignează interfeței fastEthernet 0/0 adresa IP 192.168.50.2. Se observă că face parte din aceeași rețea cu adresa de loopback a gazdei. Interfața fastEthernet 0/1 face parte din altă rețea și are adresa IP 192.168.11.1 .

Prin comanda no shutdown se va activa interfața. După executarea comenzilor menționate anterior, se procedează la menținerea schimbărilor de configurație aduse router-ului și după repornirea acestuia. Astfel, este necesar ca noua configurație să fie salvată în memoria nevolatilă a echipamentului. Acest lucru se realizeazăi, fie prin comanda copy running-config startup-config sau cu versiunea mai scurtă a acesteia, write.

Pentru a permite viitoarea comunicare între gazdă, router și alte echipamente ce vor fi conectate la router, trebuie configurat un protocol de routare. Protocolul Opens Shortest Path First (OSPF) este un protocol de rutare bazat pe statusurile conexiunilor dintre interfețe (link-state routing protocol).

Configurările OSPF pentru cele două routere sunt descrise mai jos:

R1<config>#router ospf 1

R1<config>#network 192.168.50.0 0.0.0.255 area 0

R1<config>#network 192.168.11.0 0.0.0.255 area 0

Comanda router ospf 1 activează protocolul OSPF. Parametrul 1 este identificatorul procesului OSPF de pe router care poate avea valori diferite pentru routere diferite. Acesta este un identificator local, deoarece pot exista mai multe procese OSPF pe un echipament. Rețelele direct legate la router sunt precizate prin comanda network. Masca de tip wildcard 0.0.0.255, care se obține din negarea biților măștii de rețea. Pentru fiecare bit în parte din mască, valoarea 0 înseamnă potrivirea bitului, iar 1 indiferent. Astfel rețeaua 192.168.50.0 cu masca de tip wildcard 0.0.0.255 înseamnă că va lua în considerare toate adresele 192.168.50.0 – 192.168.50.255. După realizarea acestei configurații routerele pot comunica între ele pe toate interfețele, dar pentru sistemul gazdă rețeaua 192.168.11.0 nu este vizibilă. Pentru a soluționa această problemă se adaugă o rută statică în sistemul gazdă, sub Windows prin cmd.exe, care să folosească interfața de pe R1 pentru toate pachetele trimise către rețeaua 192.168.11.0:

route add 192.168.11.0 mask 255.255.255.0 192.168.50.2

În continuare sunt prezentate configurările protocolului SNMPv2c care s-au realizat pe echipamente. În general, setările includ activarea agentului SNMPv2, setarea numelui comunității și setarea managerului SNMP.

Pentru activarea SNMP-ului în cazul routerelor Cisco s-au folosit comenzile următoare:

R1#configure terminal

R1<config>#snmp-server contact Bana Iustinian

R1<config># snmp-server location Brasov

R1<config># snmp-server community cR1 RW

Prin snmp-server contact se setează numele persoanei de contact, eventual și adresa de e-mail a acesteia sau alte informații relevante. Locația echipamentului, necesară în cazul în care apar evenimente care necesită deplasarea în acest loc se setează prin snmpserver location, pentru routerul R1 având valoarea Brașov. Ultima linie, snmp-server community cR1 RW, face ca SNMP-ul să fie disponibil pentru comunitatea cR1, dând acces la citire, cât și

la scriere. Ștergerea oricăreia dintre aceste comenzi se realizează printr-o negare, mai precis prin adăugarea cuvântului no în față, de exemplu no snmp-server location Brasov.

Rezultatele acestor comenzi se pot afișa prin comanda show snmp, după cum se

poate vedea și în Figura 20.

Testarea funcționalității convertorului XMPP-SNMP

Conectarea router-ului la serverul XMPP

După cum se poate observa în Figura 21, router-ul având adresa IP 192.168.50.2 nu este conectat la serverul local Openfire, dar apare ca inactiv. Indicatorul de prezență și anume “led-ul” verde, este stins atât în interfața serverului cât și în fereastra de chat.

Pașii parcurși pentru conectarea la server de către o entitate sunt următorii:

Se trimite o strofă iq de tipul set prin care entitatea trimite o cerere de resursă către server

După ce resursa a fost setată , entitatea va primi o strofă iq de tip result prin care i se comunică alocare resursei cu succes. Dacă acest mesaj nu este recepționat înseamnă că procesul de alocare a resursei a eșuat

Entitatea trimite o strofă iq de tip set către server prin care cere activarea unei sesiuni . Această acțiune este confirmată de server print-o strofă iq de tip result

Entitatea trimite apoi disponibilitatea sa în rețea către contactele din lista sa printr-o strofă presence

Primește o strofă iq de tip result cu entitățile din lista sa precum și subscrierile acestora

În final , entitatea primește câte o strofă presence de la fiecare entitate aflată în lista acesteia prin care comunică disponibilitatea

La rularea codului creat în mediul Eclipse 3.6.2 ruter-ul se autentifică pe server și se conectează utilizând următoarele credențiale:

Utilizator: 192.168.50.2

Parola: parola

String user = “192.168.50.2”, password = “parola”;

Pentru conectare se apelează funcția :

login(user, password)

public XMPPConnection(ConnectionConfiguration config) {

super(config);

}

public XMPPConnection(ConnectionConfiguration config, CallbackHandler callbackHandler) {

super(config);

config.setCallbackHandler(callbackHandler);

}

public String getConnectionID() {

if (!isConnected()) {

return null;

}

return connectionID;

}

public String getUser() {

if (!isAuthenticated()) {

return null;

}

return user;

}

Funcția prin care se realizează autentificarea router-ului la serverul de XMPP ce rulează pe mașina locală este următoarea:

public void login(String userName, String password) {

ConnectionConfiguration config = new ConnectionConfiguration("127.0.0.1", 5222, "Work");

connection = new XMPPConnection(config);

if (connection != null)

disconnect();

try {

connection.connect();

} catch (XMPPException e) {

e.printStackTrace();

}

try {

connection.login(userName, password);

} catch (XMPPException e) {

e.printStackTrace();

}

Conversia de protocol: XMPP -> SNMP – demostrație aplicativă

Setarea și preluarea parametrilor router-ului prin comenzi SNMP:

public void convert2SNMP(String message, String to) {

if (!message.isEmpty()) {

StringTokenizer st = new StringTokenizer(message);

ArrayList<String> params = new ArrayList<String>();

while (st.hasMoreTokens()) {

params.add(st.nextToken());

}

String user = connection.getUser().substring(0, connection.getUser().indexOf('@'));

String firstParam = params.get(0).toLowerCase();

MessageMapping param = MessageMapping.failed;

try {

param = MessageMapping.valueOf(firstParam);

System.out.println("param: " + param);

} catch (Exception e) {

e.printStackTrace();

}

switch (param) {

case snmpset: {

ArrayList<OIDValueAndType> oids = new ArrayList<OIDValueAndType>();

oids.add(new OIDValueAndType(params.get(1), params.get(2), params.get(3)));

System.out.println("Sending set command");

System.out.println(connection.getUser());

boolean setResp = SnmpUtil.SNMPSet(user, SNMPConstants.SNMPKEY, oids);

try {

if (setResp) {

sendMessage("Set succeeded.", to);

} else {

sendMessage("Set failed.", to);

}

} catch (XMPPException e) {

e.printStackTrace();

}

case snmpget: {

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, params.get(1));

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

La execuția metodelor snmpset și snmpget, se procedează la setarea anumitor parametrii cum ar fi numele router-ului, locația în care acesta se află, persoana de contact indispensabilă în cazul unei lucrări de mentenanță etc. sau la preluarea acestor parametrii.

Un exemplu concret al funcționalității metodelor, în cadrul convertorului, este ilustrat de Figura 23.

Implementarea dialogului între utilizatorul uman și echipamentul de rețea are la bază metodele descrise în continuare. Prin intermediul acestor metode administratorul de rețea are posibilitatea de a culege informații utile, administrative despre locația, numele, ora la care a fost ultima dată pornit echipamentul dar și numele persoanei responsabile cu mentenanța rețelei.

public void convert2SNMP(String message, String to) {

if (!message.isEmpty()) {

StringTokenizer st = new StringTokenizer(message);

ArrayList<String> params = new ArrayList<String>();

while (st.hasMoreTokens()) {

params.add(st.nextToken());

}

String user = connection.getUser().substring(0, connection.getUser().indexOf('@'));

String firstParam = params.get(0).toLowerCase();

MessageMapping param = MessageMapping.failed;

try {

param = MessageMapping.valueOf(firstParam);

System.out.println("param: " + param);

} catch (Exception e) {

e.printStackTrace();

}

switch (param) {

case salut: {

try {

sendMessage("Salut, " + to.substring(0, to.indexOf('@')), to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case cand: {

// cand ai fost pornit?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("cand");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysUpTime);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case persoana: {

// cand ai fost pornit?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("persoana");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysContact);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case la: {

try {

sendMessage("La revedere, " + to.substring(0, to.indexOf('@')), to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case spune: {

// spune-mi numele tau?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("spune");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysName);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case detalii: {

// detalii sistem?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("detalii");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysDescr);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

case unde: {

// unde esti?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("unde");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysLocation);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case failed:

default: {

try {

sendMessage("Imi pare rau, nu inteleg!", to);

} catch (XMPPException e) {

e.printStackTrace();

}

Figura 24 pune în evidență modul inovator de a comunica cu un echipament de rețea, diferit de cele existente până în momentul de față. Limbajul utilizat este cel prezent în dialogul a două persoane, această implementare reprezentând un pas important în scopul comunicației echipamentelor fără intervenția omului, având totodată și un aport didactic considerabil.

Concluzii

Rețelele de telecomunicații, precum și cele de calculatoare sunt în continuă expansiune datorită creșterii numărului de utilizatori de servicii de comunicații. Creșterea nivelului de complexitate a rețelelor a facut ca nevoia de management să devină tot mai accentuată.

Soluția propusă în lucrarea de față reprezintă un ansamblu complex de monitorizare, descris pe parcursul celor trei capitole componente.

Primul capitol prezintă arhitectura și particularitățile funcționale ale protocolului SNMP, un protocol puternic și o soluție de efect în domeniul managementului dispozitivelor de rețea. Fiind bazat pe stiva TCP/IP, SNMP implementează un set simplu de comenzi pentru gestionarea și supravegherea la distanță a nodurilor unei rețele. Arhitectura sa simplă, construită după modelul client-server, presupune un sistem ierahic foarte bine organizat compus din două tipuri de funcții atribuite nodurilor: manager SNMP și agent SNMP. Aceste entități utilizează un limbaj comun, structurat în fișiere speciale, în scopul schimbului de informații de management.

În cel de-al doilea capitol este prezentat protocolul XMPP, protocol de comunicație în timp real utilizat în cadrul infrastructurilor ce suportă trimiterea și recepționarea de mesaje între sisteme distribuite. Limbajul utilizat este structurat în așa-numitele strofe XML ce permit entităților să schimbe informații de prezență și disponibilitate în rețea prin intermediul unui canal de transmisie bine securizat. În plus, siguranța oferită de mecanismul de autentificare, protecția impotriva spoofing-ului și nu în ultimul rând utilizarea unui sistem de semnalizare relativ simplu au determinat dezvoltatorii de sofware să includă XMPP în domenii precum: rețele de socializare, cloud computing și comunicația machine-to-machine(mașină-mașină) sau domeniul sesiunilor multimedia.

Cel de-al treilea capitol prezintă aplicația practică a proiectului și oglindește întocmai ideea de bază a acestui proiect: o soluție standardizată, diferită de cele existente până în momentul actual, pentru managementul și monitorizarea unei rețele de comunicație. Aplicația este fondată pe elementul comun al protocoalelor XMPP și SNMP : limbajul în format XML. Astfel a fost posibilă realizarea convertorului XMPP-SNMP, un element inovativ de administrare a unei arhitecturi client-server având un potențial didactic foarte mare datorită funcției îndeplinite și modului în care studenții pot interacționa cu echipamentele de rețea.

Anexe

Codul sursă

package com.licenta.xmpptosnmp;

import java.io.IOException;

import java.util.ArrayList;

import java.util.Collection;

import java.util.StringTokenizer;

import org.jivesoftware.smack.Chat;

import org.jivesoftware.smack.ChatManagerListener;

import org.jivesoftware.smack.ConnectionConfiguration;

import org.jivesoftware.smack.MessageListener;

import org.jivesoftware.smack.Roster;

import org.jivesoftware.smack.RosterEntry;

import org.jivesoftware.smack.XMPPConnection;

import org.jivesoftware.smack.XMPPException;

import org.jivesoftware.smack.packet.Message;

public class XMPPtoSNMPParser implements MessageListener {

private XMPPConnection connection;

public void login(String userName, String password) {

ConnectionConfiguration config = new ConnectionConfiguration("127.0.0.1", 5222,"null");

connection = new XMPPConnection(config);

if (connection != null)

disconnect();

try {

connection.connect();

} catch (XMPPException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

try {

connection.login(userName, password);

} catch (XMPPException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

public void sendMessage(String message, String to) throws XMPPException {

Chat chat = connection.getChatManager().createChat(to, this);

chat.sendMessage(message);

}

public void displayBuddyList() {

Roster roster = connection.getRoster();

Collection<RosterEntry> entries = roster.getEntries();

System.out.println("\n\n" + entries.size() + " buddy(ies):");

for (RosterEntry r : entries) {

System.out.println(r.getUser());

}

System.out.println();

}

public void disconnect() {

connection.disconnect();

}

public void processMessage(Chat chat, Message message) {

if (message.getType() == Message.Type.chat)

System.out.println(chat.getParticipant() + " says: " + message.getBody());

}

/**

* Receives all messages and converts them into SNMP messages

*/

public void receiveMessage() {

connection.getChatManager().addChatListener(new ChatManagerListener() {

public void chatCreated(final Chat chat, final boolean createdLocally) {

chat.addMessageListener(new MessageListener() {

public void processMessage(Chat chat, Message message) {

System.out.println("Received message from " + chat.getParticipant() + ": " + (message != null ? message.getBody() : "NULL"));

convert2SNMP(message.getBody(), chat.getParticipant());

}

});

}

});

}

* Transforms the parameter message into a SNMP command, sent to the parameter to.

public void convert2SNMP(String message, String to) {

if (!message.isEmpty()) {

StringTokenizer st = new StringTokenizer(message);

ArrayList<String> params = new ArrayList<String>();

while (st.hasMoreTokens()) {

params.add(st.nextToken());

}

String user = connection.getUser().substring(0, connection.getUser().indexOf('@'));

// snmpset 1.3.6.1.2.1.1.6.0 locatie string

String firstParam = params.get(0).toLowerCase();

MessageMapping param = MessageMapping.failed;

try {

param = MessageMapping.valueOf(firstParam);

System.out.println("param: " + param);

} catch (Exception e) {

e.printStackTrace();

}

switch (param) {

case salut: {

try {

sendMessage("Salut, " + to.substring(0, to.indexOf('@')), to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case snmpset: {

ArrayList<OIDValueAndType> oids = new ArrayList<OIDValueAndType>();

oids.add(new OIDValueAndType(params.get(1), params.get(2), params.get(3)));

System.out.println("Sending set command");

System.out.println(connection.getUser());

boolean setResp = SnmpUtil.SNMPSet(user, SNMPConstants.SNMPKEY, oids);

try {

if (setResp) {

sendMessage("Set succeeded.", to);

} else {

sendMessage("Set failed.", to);

}

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case snmpget: {

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, params.get(1));

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case cand: {

// cand ai fost pornit?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("cand");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysUpTime);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case persoana: {

// cand ai fost pornit?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("persoana");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysContact);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case la: {

try {

sendMessage("La revedere, " + to.substring(0, to.indexOf('@')), to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case spune: {

// spune-mi numele tau?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("spune");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysName);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case detalii: {

// detalii sistem?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("detalii");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysDescr);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case unde: {

// unde esti?

// if (params.size() >= 2) params.get(1).toLowerCase.equals("unde");

String response = SnmpUtil.SNMPGet(user, SNMPConstants.SNMPKEY, SNMPConstants.sysLocation);

try {

sendMessage(response, to);

} catch (XMPPException e) {

e.printStackTrace();

}

break;

case failed:

default: {

try {

sendMessage("Imi pare rau, nu inteleg!", to);

} catch (XMPPException e) {

e.printStackTrace();

}

public static void main(String args[]) throws XMPPException, IOException {

XMPPConnection.DEBUG_ENABLED = true;

XMPPtoSNMPParser x2s = new XMPPtoSNMPParser();

//BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

String user = "192.168.50.2", password = "parola";

x2s.login(user, password);

x2s.displayBuddyList();

x2s.receiveMessage();

}

În clasa SNMPConstants amintită în codul sursă am definit:

public class SNMPConstants {

public static String SNMPKEY = "cR1";

public static final String sysContact = "1.3.6.1.2.1.1.4.0";

public static final String sysName = "1.3.6.1.2.1.1.5.0";

public static final String sysLocation = "1.3.6.1.2.1.1.6.0";

public static final String sysDescr = "1.3.6.1.2.1.1.1.0";

public static final String sysUpTime = "1.3.6.1.2.1.1.3.0";

}

Bibliografie

[1] Douglas Mauro, Kevin Schmidt, Essential SNMP, 2nd Edition, O’Reilly, 2005

[2] Alexander Clemm, Network Management Fundamentals. A guide to understanding how network management technology really works, Cisco Press, 532 pag., 2007

[3] Merilee Ford, Internetworking Technology Overview, Cisco, 1999

[4] Jianguo Ding, Advances in Network Management, CRC Press, 2010

[5] J. Case ș.a., A Simple Network Management Protocol, RFC 1157, 1990

[6] M. Rose, K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based Internets, RFC 1155, 1990

[7] R. Presuhn ș.a., Transport Mappings for the Simple Network Management Protocol (SNMP), RFC 3417, 2002

[8] Peter Saint-Andre, Kevin Smith, Remko Tronçon, XMPP: The Definitive Guide, O’Reilly, 2009

[9] http://www.iana.org/assignments/enterprise-numbers

[10] http://publib.boulder.ibm.com/infocenter

[11] http://www.eclipse.org/downloads/moreinfo/java.php

[12] http://www.igniterealtime.org/builds/smack/docs/latest/documentation/

[13] http://www.igniterealtime.org/builds/smack/docs/3.2.2/javadoc/

[14] Peter Saint-Andre, Extensible Messaging and Presence Protocol: Core, 2009

[15] Peter Saint-Andre, Extensible Messaging and Presence Protocol: Instant Messaging and Presence, 2009

[16] Peter Saint-Andre, Multi-User Chat, 2012

[17] Joe Hildebrand, Peter Saint-Andre, Remko Tronçon, Jacek Konieczny, Entity Capabilities, 2008

[18] Matthew Miller, Ad-Hoc Commands, 2005

[19] Joe Hildebrand, Peter Millard, Ryan Eatmon, Peter Saint-Andre , Service Discovery, 2008

[20] Roxana Păun, coordonator prof. univ. dr. ing. Florin Sandu, Proiect de dizertație-Managementul echipamentelor de telecomunicații pentru agregarea în Infrastructura-ca-Serviciu, 2012

[21] Catina Marinescu, coordonator prof. univ. dr. ing. Florin Sandu, Proiect de licență-Gestiunea rețelelor IP distribuite prin tehnici ale rețelelor sociale, 2012