Vasta 1980-luvun puolivälin jälkeen, Internet-yhteisön kasvaessa lähes eksponentiaalisesti [RFC1296], kuten kuvassa 6 esitetään, ruvettiin kiinnittämään huomiota tehokkaamman verkonhallinnan kehittämiseen. Syntyi useita projekteja, jotka keskittyivät verkonhallintaprotokollan kehittämiseen. Näiden projektien joukosta nousi esiin kolme muita lupaavampaa protokollaa:
Kun SNMP:n kehittäjät näin vapautettiin OSI-yhteensopivuuden vaatimuksista, kehitys oli nopeata. Huhtikuussa 1989 voidaan sanoa SNMP:stä tulleen de facto -standardi TCP/IP-pohjaisten verkkojen hallintaan. Useat laitevalmistajat tukivat SNMP:tä, ja, mikä tärkeintä, olivat toteuttaneet sen omissa järjestelmissään. Toukokuussa 1990 SNMP hyväksyttiin Internet-standardiksi. Toisin sanoen itse verkonhallintaprotokolla (SNMP, RFC1157), hallittavan tiedon rakenne ja identifionti (SMI, Structure and Indetification of Management Information of TCP/IP-based Internets, RFC1155) sekä hallittavat tiedot (MIB, Management Information Base for Network Management of TCP/IP-Based Internets, RFC1156) hyväksyttiin täysiksi Internet-standardeiksi. Maaliskuussa 1991 MIB korvattiin uudella standardilla. MIB-II (Management Information Base for Network Management of TCP/IP-Based Internets, RFC1213) oli laajennettu versio edellisestä versiosta, jota ruvettiin kutsumaan nimellä MIB-I.
SNMP:llä on muutama huomattava puute, jotka johtuvat hyvin pitkälti SNMP:n yksnkertaisuudesta. Tärkein näistä on puutteellinen turvallisuus. SNMP:ssä ei ole mitään kunnollista autentikointimekanismia, jolla voitaisiin taata, että pyyntöjä lähettävät laitteet ovat niitä, joille voidaan haluttua informaatiota lähettää. Heinäkuussa 1992 julkaistiin standardiehdotukset SNMP:n turvallisuusominaisuuksien parantamiseksi. Näiden parannusten totetuttaminen olisi vaatinut muutoksia SNMP-protokollan viestien hallintaan, mutta itse viestien lukumäärä ja sisällön rakenne olisi pysynyt muuttumattomana. Tämän tarkoituksena oli taata mahdollisimman kivuton siirtyminen SNMP:stä turvalliseen SNMP:hen (Secure SNMP).
Samaan aikaan kuitenkin ilmestyi toinen ehdotus SNMP:n uudeksi toteutukseksi. SMP (Simple Management Protocol) tarjosi turvallisuusnäkökohtien lisäksi parannuksia protokollan tehokkuuteen, joten se hyväksyttiin seuraavan sukupolven SNMP:n kehittämisen pohjaksi. Kaksi ryhmää muodostettiin kehittämään SNMP:n uutta versiota, jota ruvettiin kutsumaan nimellä SNMPv2. Toinen ryhmä keskittyi kaikkeen muuhun paitsi turvallisuuden määrittelyyn, ja toinen ainoastaan turvallisuusominaisuuksien kehittämiseen. Vuoden 1993 alussa julkaistiin SNMPv2:n standardiehdotus, ja saman vuoden syksyllä se hyväksyttiin standardiluonnokseksi. Vuoden 1994 aikana SNMPv2 hyväksyttäneen täydeksi standardiksi.
Hallinta-agentti on verkon laite (tietokone, silta, reititin tms.), johon on toteutettu SNMP siten, että laitetta voidaan hallita hallinta-asemasta käsin. Hallinta-agentti vastaa hallinta-asemasta tulleisiin kyselyihin ja pyyntöihin mutta voi myös oma-aloitteisesti kertoa hallinta-asemalle verkon merkittävistä tapahtumista.
Hallittavia resursseja kuvataan olioina (object). Tarkkaan ottaen kyse ei ole olioista, vaan jokainen olio on muuttuja, joka kuvaa hallinta-agentin jotain ominaisuutta. Joukkoa tällaisia olioita kutsutaan hallintatietokannaksi (Management Information Base). Nämä oliot on standardoitu siten, että kaikki samantyyppiset laitteet tukevat samaa joukkoa olioita. Hallinta-asema voi kysellä hallinta-agentin tietokannan jonkin olion arvoa tai asettaa sen ja siten toteuttaa verkon valvontaa ja hallintaa.
Hallinta-asemat ja hallinta-agentit liitetään toisiinsa verkonhallinnan yhteyskäytännön avulla. TCP/IP-verkkojen hallintaan tarkoitetulla yksinkertaisella verkonhallintaprotokollalla (SNMP:llä) on seuraavat perusoperaatiot:
Jokaisen hallittavan laitteen, agentin (agent), on toteutettava SNMP, UDP ja IP. Lisäksi jokaisessa agentissa on oltava mekanismi, joka tulkitsee SNMP-viestit ja hallitsee agentin paikallista tietokantaa (MIB).
Hallintatyöasemalta voidaan lähettää kolmenlaisia viestejä. GetRequest ja GetNextRequest ovat viestejä, joilla pyydetään (luetaan) agentilta tietoja. SetRequestilla muutetaan (kirjoitetaan) agentin paikallisen tietokannan sisältöä. Näihin kolmeen viestiin agentti vastaa GetResponse-viestillä, joka välitetään hallintaohjelmistolle. GetResponse-viestin lisäksi agentti voi lähettää Trap-viestejä, joilla se voi ilmoittaa hallintatyöasemille tapahtumista, jotka vaikuttavat hallittaviin resursseihin. Kuvassa 7 on esitetty SNMP-protokollan yleinen rakenne. Itse yhteyskäytäntöön palataan myöhemmin SNMP-protokollan tarkemmassa kuvauksessa.
Koska SNMP perustuu UDP:hen, joka on yhteydetön protokolla, myös SNMP on yhteydetön. Toisin sanoen hallintatyöaseman ja agenttien välillä ei ylläpidetä yhteyksiä, vaan jokainen viesti on erillinen tapahtuma. Tämä merkitsee myös sitä, että SNMP:n on itse huolehdittava viestien uudelleenlähetyksistä vastausten perusteella. Toisaalta agenttien lähettämiin Trap-viesteihin ei hallintatyöasema vastaa, joten ne voivat hävitä matkalla, eikä agentti voi tietää, onko sen viesti mennyt perille.
Mikäli hallintatyöaseman vastuulla on suuri joukko hallinta-agentteja ja jokaisella agentilla on suuri paikallinen tietokanta, ei ole käytännöllistä säännöllisesti kysellä agenteilta koko tietokantaa. Suositeltava toimintaperiaate on sovelluksen käynnistyessä ja mahdollisesti kerran vuorokaudessa kysyä agenteilta joitakin oleellisia tietoja. Tällaisia tietoja voivat esimerkiksi olla verkkoliityntöjen tila, ja jotkut tehokkuuteen liittyvät tilastotiedot, kuten lähetettyjen ja vastaanotettujen pakettien lukumäärä. Tämän jälkeen agenttien vastuulla on ilmoittaa epätavallisista tapahtumista, kuten agentin uudelleenkäynnistämisestä, tai liikenteen määrän ennalta määrätyn raja-arvon ylittymisestä. Näin voidaan huomattavasti vähentää verkonhallinnan aiheuttamaa ylimääräistä verkkokuomaa.
Näiden laitteiden hallintatarpeisiin on kehitetty valtuutuskonsepti (proxy). Tässä järjestelyssä SNMP-agentti toimii edustajana joukolle muita laitteita [Rose]. SNMP-manageri lähettää hallittavia laitteita koskevat kyselyt valtuutusagentille, joka muuttaa kyselyt hallittavien laitteiden ymmärtämälle protokollalle ja saadut vastaukset vastaavasti SNMP-viesteiksi takaisin managerille. Myös laitteiden valtuutusagentille välittämät Trap-viestiä vastaavat ilmoitukset lähetetään edelleen SNMP-viesteinä hallintatyöasemalle.
Viimeisenä käsitellään SNMP:n tärkeää laajennusta RMON MIB:iä (Remote monitoring MIB). RMON määrittelee hallintatietokannan verkkojen etähallintaan. Sen yhteydessä tulee esille myös monia käytännön asioita, jotka koskevat erityisesti suorituskyvyn ja käytön hallintaa.
SMI:n ja MIB:ien kuvaukseen käytetään ASN.1 (Abstract Syntax Notation One) formaattia, joka on CCITT:n (X.208) ja ISO:n (ISO 8824) kehittämä ja standardoima formaali kieli. Yksinkertaisuuden vuoksi ainoastaan rajoitettu osajoukko ASN.1:n elementeistä ja piirteistä on otettu mukaan MIB:ien kuvaukseen.
Kuvassa 8 voidaan nähdä MIB-hierarkian perusrakenne. Juuresta aloitettaessa on ensimmäisellä tasolla kolme oksaa: iso, ccitt ja jointisoccitt. Iso-solmun alapuolella on yksi alipuu varattu muiden organisaatioiden käyttöön ja yksi USA:n puolustusministeriön käyttöön (dod, Departement of Defense). Standardissa käytetään säännönmukaisesti lähinnä pieniä kirjaimia olioiden nimeämiseen. Dokumentissa [RFC1155] oletetaan, että yksi dod:n alipuu allokoidaan IAB:n (Internet Activities Board) hallintaan, eli kaikki SNMP:n MIB:it rekisteröidään olion internet alle.
Olio internet voidaan ASN.1:llä määritellä esimerkiksi seuraavasti:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
Usein kyseinen olio kirjoitetaan lyhyesti 1.3.6.1.
Kuten kuvasta 8 voidaan nähdä, on internet-solmun alle määritelty neljä alipuuta:
Olioiden kuvaamiseen voidaan käyttää seuraavia tietotyyppejä:
RFC1155:ssä määritellään lisäksi joukko tietotyyppejä sovellusten käyttöön:
---------------------------------------------------------------------------
NetworkAddress Verkko-osoite: sallii osoiteformaatin valinnan eri pro
tokollaperheiden välillä. Tällä hetkellä ainoa määritelty
osoitetyyppi on IpAddress.
IpAddress IP-osoite: 32-bittinen osoite IP-protokollan määrit
telemässä muodossa.
Counter Laskuri: ei-negatiivinen kokonaisluku, jonka maksimi
on 232-1. Laskuria voidaan kasvattaa, mutta ei
pienentää. Kun laskuri saavuttaa maksimiarvonsa, se
aloittaa laskemisen uudelleen nollasta.
Gauge Mittari: ei-negatiivinen kokonaisluku, joka voi kasvaa tai
pienentyä, maksimi 232-1. Mikäli mittari saavuttaa mak
simiarvonsa, se jää siihen arvoon, kunnes se alustetaan
uudelleen (reset).
TimeTicks Ajanmittaus: ei-negatiivinen kokonaisluku, joka laskee
aikaa sadasosasekunteina jostain tapahtumasta.
Opaque Tukee mahdollisuutta siirtää satunnaista tietoa.
---------------------------------------------------------------------------
Näistä laskuri on yksi yleisimmin MIB:eissä käytetyistä tyypeistä. Tyypillisesti sovellukset laskevat esimerkiksi lähetettyjä paketteja tai tavuja. Tätä tietotyyppiä käytettäessä on hallinta-aseman pidettävä huolta riittävästä kyselystä, jotta se pysyy selvillä laskurin nollaamisesta ja siten tietää laskurin tarkan arvon. Tosin 32-bittisen laskurin nollautuminen ei tapahdu kovinkaan usein.Mittaria (gauge) käytetään tyypillisesti jonkin olion hetkellisen arvon mittaamiseen. Arvo voi olla esimerkiksi lähetystä odottavien pakettien lukumäärää jonossa. Mittaria voidaan käyttää myös kuvaamaan jonkin olion muutosta tietyllä aikavälillä. Tällä tavoin sitä voidaan käyttää jonkin olion muutosnopeuden valvontaan.
Makron avulla kustakin oliosta määritellään olion nimi (ObjectName), sen tyyppi (Syntax), saatavuus (Access) ja tila (Status). Lisäksi olion määrittelyssä voi olla mukana (mutta ei ole pakollinen) kuvaus (Description) ja viittaus (Reference) johonkin muuhun olioon jossain muussa MIB-kuvauksessa.
Esimerkiksi seuraavanlainen kuvaus on dokumentissa [RFC1213]:
sysContact OBJECT-TYPESyntax kertoo siis, minkä tyyppisestä oliosta on kysymys. Tässä tapauksessa tyyppi on merkkijono, jonka maksimipituus on 255 merkkiä.SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person
for this managed node, together with information
on how to contact this person."
::= { system 4 }
Access kuvaa saatavuutta eli sitä, voidaanko olion arvoa muuttaa SNMP SetRequest-viestin avulla. Mahdolliset arvot ovat read-only, read-write, write-only ja non-accessible.
Status kertoo, onko kyseinen olio pakollinen, kun jotain kyseistä MIB:iä käyttävää sovellusta toteutetaan. Mahdolliset arvot ovat mandatory, optional, obsolete ja deprecated. Mandatory kertoo, että olio on toteutettava ja optional kertoo, että olion toteuttaminen ei ole pakollista. Obsolete ilmaisee, että kyseistä oliota ei enää tarvitse toteuttaa. Deprecated puolestaan kertoo, että kyseinen olio on toteutettava, mutta se tullaan todennäköisesti poistamaan kyseisen MIB:in seuraavassa versiossa.
Description kertoo suorasanaisen selvityksen olion käyttötarkoituksesta.
Viimeisellä rivillä identifioidaan olio. Viittaamalla olion vanhempaan ja antamalla oliolle oma numero voidaan kaikki oliot määritellä yksikäsitteisesti.
Seuraavassa käydään pääpiirteissään läpi eri ryhmät ja joitakin tärkeimpiä niiden sisältämistä olioista ja kuinka niitä voidaan käyttää hyväksi verkonhallinnassa.
---------------------------------------------------------------------------
sysDescr Sanallinen kuvaus järjestelmästä. Sen tulisi yleensä sisältää
laitteiston, käyttöjärjestelmän ja verkko-ohjelmiston nimi ja
versionumero.
sysObjectID Valmistajan identifikaatio järjestelmästä ja sen tyypistä.
sysUpTime Kuinka kauan järjestelmä on ollut yhtäjaksoisesti toimin
nassa.
sysContact Tänne kirjataan yleensä laitteesta vastaavan henkilön
yhteystiedot. Tämä helpottaa yhteydenottoa vastuulliseen
henkilöön ongelmatapauksissa.
sysLocation Tänne kirjataan, missä laite sijaitsee.
sysServices Lukuarvo, joka kertoo, millä OSI-viitemallin tasoilla järjes
telmä pääasiassa toimii. Lukuarvo on summa, joka saadaan,
kun lasketaan yhteen 2L-1 kaikille viitemallin tasoille (L),
joilla laite toimii. Esimerkiksi reititin toimii pääasiassa
tasolla 3, jolloin saadaan 23-1 = 4.
---------------------------------------------------------------------------
Esimerkiksi eräs TKK:n atk-keskuksen moniporttitoistimista kertoo seuraavanlaista informaatiota:
sysDescr[0]="Allied Telesis AT-3606F Extendable Hub"Yhtäläisyysmerkin vasemmalla puolella on olion nimi ja oikealla puolella on laitteen lähettämä vastaus. Jotkut ohjelmat osaavat kertoa hieman enemmän saadusta vastauksesta. Esimerkiksi edellinen sysUpTime on helpompi käsittää, kun se näytetään päivinä ja tunteina:sysObjectID[0]=1.3.6.1.4.1.207.1.2.1
sysUpTime[0]=308228767
sysContact[0]="Jallu p. 4321"
sysName[0]="kone-hub.hut.fi"
sysLocation[0]="K2 (konepaja)"
sysServices[0]=4
system.sysUpTime.0 : Timeticks: (309158002) 35 days, 18:46:20.02
--------------------------------------------------------------------------
ifNumber Kuinka monta verkkoliityntää laitteessa on.
ifDescr Verkkoliitynnän sanallinen kuvaus.
ifType Verkkoliitynnän tyyppi, joka ilmaistaan kokonaislukuna.
Tyyppejä ovat mm. ethernet-csmacd(6), fddi(15) ja frame-
relay(32).
ifMtu Suurin paketti, jonka verkkoliityntä voi lähettää tai vas
taanottaa, ilmaistuna tavuina.
ifSpeed Verkkoliitynnän kaistanleveys bitteinä sekunnissa.
ifAdminStatus, Verkkoliitynnän toiminnallinen tila.
ifOperStatus
--------------------------------------------------------------------------
Näiden lisäksi on joukko olioita, joita voidaan käyttää verkonhallintaan. Esimerkiksi voidaan laskea laitteen lähettämien ja vastaanottamien virheellisten pakettien suhteelliset osuudet prosentteina.Suorituskyvyn seuraamiseksi voidaan ottaa kaksi näytettä hetkillä t0 ja t1 ja laskea näiden perusteella verkkoliitynnän keskimääräinen liikenne tavuina sekunnissa kyseisellä aikavälillä:
Edellisestä saadaan edelleen helposti verkkoliitynnän käyttöaste (utilization):
Olioita ifInOctets ja ifOutOctets voi käyttää myös käytön hallinnassa. Mikäli jotain organisaatiota laskutetaan runkoverkon käytöstä ja sillä on oma aliverkkonsa esimerkiksi reitittimen takana, voidaan laskutus suorittaa reitittimen runkoverkon verkkoliitynnän lähettämien ja vastaanottamien tavujen perusteella.
Vastaavat oliot on toteutettu ip-ryhmän aliryhmässä ipNetToMediaTable.
--------------------------------------------------------------------------
ipForwarding Kertoo, toimiiko laite reitittimenä (gateway).
ipInReceives Kaikkien vastaanotettujen, myös virheellisten IP-
pakettien lukumäärä.
ipInHdrErrors Niiden hylättyjen pakettien lukumäärä, joissa on ollut
virheitä IP-paketin otsikkokentissä.
ipInAddrErrors Niiden hylättyjen pakettien lukumäärä, joissa on ollut
virheellinen osoitekenttä.
ipForwDatagrams Niiden pakettien lukumäärä, jotka on lähetetty edel
leen.
ipInUnknownProtos Paketit, jotka on hylätty, koska niiden protokollaa ei
tunneta tai tueta.
ipAddrTable Taulukko, jossa ovat tiedot paikallisten verkkoliityn
töjen osoitteista jne.
ipRouteTable Taulukko, jossa on laitteen omat reititystiedot.
ipNetToMediaTable Taulukko, jossa ovat laitteen ARP-tiedot.
--------------------------------------------------------------------------
Mikäli laite hylkää paljon paketteja joko laitteen resurssien puutteen vuoksi tai viallisten IP-otsikoiden takia, voivat sovellukset, jotka käyttävät IP:tä tiedon siirtoon, toimia hitaasti. Tällaisten virheiden suhteellisen osuuden voi laskea seuraavasti sekä lähetetyille että vastaanotetuille paketeille erikseen: ipRouteTablen olioiden ilmentymiä muokkaamalla voidaan hallita kokoonpanoa. Taulukon reititystietoja voidaan muokata esimerkiksi lisäämällä reititystauluun rivejä tai muuttamalla tiettyjen reititystietojen kustannuksia (ipRouteMetric).
---------------------------------------------------------------------------
tcpMaxConn Yhtäaikaisten TCP-yhteyksien maksimilukumäärä. Mikäli
maksimi on dynaaminen, eli yhteyksiä voidaan luoda tar
vittaessa, arvo on -1.
tcpCurrEstab Kyselyhetkellä olevien TCP-yhteyksien lukumäärä.
tcpConnTable Taulukko, jossa on tiedot senhetkisistä TCP-yhteyksistä.
Mm. yhteyden tila, vastapään IP-osoite sekä paikallisen ja
vastapään TCP-porttien numerot.
tcpRetransSegs Kuinka monta TCP-pakettia laite on joutunut lähettämään
uudelleen. Uudelleenlähetykset eivät suoranaisesti
vaikuta tehokkuuden hallintaan, mutta mikäli niitä on
paljon, voi se olla merkki siirtotien heikosta toiminnasta.
---------------------------------------------------------------------------
--------------------------------------------------------------------
snmpInPkts Kaikkien vastaantotettujen SNMP-pakettien
lukumäärä.
snmpOutPkts Kaikkien lähetettyjen SNMP-pakettien luku
määrä.
snmpInBadVersions Vastaanotetut väärän SNMP-version paketit.
snmpEnableAuthenTraps Osoittaa, lähettääkö laite Trap-viestin auten
tikointivirheen tapahduttua.
--------------------------------------------------------------------
Mikäli edellä mainitussa listassa oleva snmpEnableAuthenTraps ei ole aktivoitu, voidaan tuntemattomalla yhteisönimellä varustettujen pakettien lukumäärä saada oliosta snmpInBadCommunityNames. Sitä ja snmpInBadCommunityUses -oliota voidaan seurata mahdollisten väärinkäytösyritysten varalta. Tosin on huomattava, että SNMP:n nykyisen version viestejä ei mitenkään salata. Siten yhteisönimet kulkevat sellaisenaan verkossa, josta ne voidaan sopivilla ohjelmilla lukea.Ryhmässä on myös laskurit SNMP-protokollan eri viesteille, sekä lähetetyille että vastaanotetuille. Näitä laskureita seuraamalla voidaan selvitellä mahdollisia SNMP-kyselyihin liittyviä ongelmia.
Nämä rajoitukset yksinkertaistavat SNMP:n toteuttamista huomattavasti, mutta toisaalta ne myös rajoittavat SNMP:llä toteutetun verkonhallintajärjestelmän toimintamahdollisuuksia.
SNMP-yhteisö (SNMP community) määritellään hallinta-agentissa paikallisesti. Jokaista haluttua autentikoinnin, saatavuuden ja valtuutuksen sisältävää yhdistelmää kohti voidaan määritellä oma yhteisötunnus. Nämä tunnukset ovat hallinta-agentin sisällä yksikäsitteisiä ja jokaisen hallinta-aseman on jokaisessa luku- tai kirjoitusoperaatiossa ilmaistava sen oikeuksien mukainen yhteisötunnus.
Koska yhteisöt on määritelty paikallisesti hallinta-agentissa, samaa nimeä voidaan käyttää useammassa hallinta-agentissa. Yhteisöjen nimet sinällään eivät merkitse mitään eivätkä kuvasta mitään yhtäläisyyttä määriteltyjen yhteisöjen välilllä. Hallinta-aseman on siis pidettävä kirjaa yhteisönimistä, jotka assosioidaan kuhunkin agenttiin, jonka kanssa se haluaa kommunikoida.
Yhteisönimi toimii siis eräänlaisena salasanana hallinta-agenttiin ja sen olioihin. Näin heikon autentikointimekanismin vuoksi useat verkon ylläpitäjät ja laitevalmistajat ovat hyvin vastahakoisia sallimaan mitään muuta kuin laitteiden valvonnan, eli luku- ja ilmoitusviestioperaatiot. Verkon hallinta kirjoitusoperaation kautta on selvästi näitä haavoittuvampi osa-alue.
Yhteisönimen määrittelyllä rajoitetaan hallinta-asemien pääsyä hallinta-agenttien paikallisiin hallintatietokantoihin. Määrittelemällä useampia yhteisöjä, voidaan eri hallinta-asemille määritellä erilaiset oikeudet. Tämä saantimekanismi koostuu kahdesta osasta:
Skalaariolioiden ilmentymiä on helppo helppo identifioida ja operoida. Standardin mukaan skalaariolion ilmentymään viitataan olion identifikaation avulla siten, että loppuun lisätään nolla.
Jos siis halutaan viitata MIB-II:een sisältyvään sysDescr-olion ilmentymään, jonka identifikaatio on 1.3.6.1.2.1.1.1 (iso.org.dod.internet.mgmt.mib-2.system.sysDescr), käytetään tunnusta 1.3.6.1.2.1.1.1.0.
Talukoiden käsittely on jossain määrin hankalampaa. SNMP:ssä määritellään ilmentymien saantiin kaksi tapaa: peräkkäissaanti ja suorasaanti. Peräkkäissaannissa käytetään hyväksi olioiden leksikografista järjestystä. Tähän palataan seuraavassa luvussa. Suorasaannissa viitataan suoraan olion ilmentymään.
Taulukoiden käsittelyssä joudutaan ottamaan mukaan taulukon olioiden indeksointi. SMI:n mukaisessa taulukon määrittelyssä voidaan tietyt taulukon muodostavat oliot määritellä indeksiolioiksi. Näiden olioiden avustuksella voidaan erottaa taulukon rivit, eli saman olion ilmentymät toisistaan.
Yleisesti taulukon tietyn olion ilmentymä voidaan saada viittaamalla siihen seuraavasti:
x.i.(nimi1).(nimi2).(...).(nimiN)
Tässä x on taulukon identifikaattori, i on halutun olion nimi taulukossa ja nimi1 - nimiN ovat indeksiolioiden arvot.
Esimerkiksi voidaan ottaa MIB-II:n verkkoliityntäryhmän taulukko, josta saadaan eräästä atk-keskuksen työaseman kaikista verkkoliitynnöistä seuraavanlaista tietoa:
interfaces.ifTable.ifEntry.ifOutUcastPkts.1 : Counter: 0Tässä siis x on interfaces.ifTable.ifEntry. I on ifOutUcastPkts eli haluttu olio MIB:istä. Nimi1 on ifIndex:in arvo eri verkkoliitynnöille (järjestysnumero) eli olio, jonka mukaan taulukko on indeksoitu.interfaces.ifTable.ifEntry.ifOutUcastPkts.2 : Counter: 0
interfaces.ifTable.ifEntry.ifOutUcastPkts.3 : Counter: 742165
interfaces.ifTable.ifEntry.ifOutUcastPkts.4 : Counter: 2271714
Vastaava rakenne käy selville paremmin, kun katsotaan ainoastaan yhden verkkoliitynnän tietoja hallintatietokannan taulukosta:
interfaces.ifTable.ifEntry.ifIndex.4 : INTEGER: 4
...interfaces.ifTable.ifEntry.ifInOctets.4 : Counter: 432727658
interfaces.ifTable.ifEntry.ifInUcastPkts.4 : Counter: 1201639
interfaces.ifTable.ifEntry.ifInNUcastPkts.4 : Counter: 224754
interfaces.ifTable.ifEntry.ifInDiscards.4 : Counter: 0
interfaces.ifTable.ifEntry.ifInErrors.4 : Counter: 181
interfaces.ifTable.ifEntry.ifInUnknownProtos.4 : Counter: 33311
interfaces.ifTable.ifEntry.ifOutOctets.4 : Counter: 1010256327
interfaces.ifTable.ifEntry.ifOutUcastPkts.4 : Counter: 2271800
interfaces.ifTable.ifEntry.ifOutNUcastPkts.4 : Counter: 187826
...
Olioiden ja niiden ilmentymien järjestäminen on tärkeätä siksi, että hallinta-asema ei välttämättä tunne hallinta-agentin esittämän MIB:in tarkkaa rakennetta. Hallinta-asema tarvitsee siis keinot, joilla se voi etsiä ja operoida olioita ilman, että sen tarvitsee tuntea niitä nimeltä. Joka paikassa puuta hallinta-asema voi määritellä olion tai sen ilmentymän ja kysyä järjestyksessä seuraavaa olion ilmentymää.
Tarkastellaan esimerkiksi kuvan 10 esittämää puurakennetta, jossa on esitetty puun läpikäymisjärjestys katkoviivalla. Voidaan havaita, että oliota 1 seuraava olion ilmentymä on 1.1 ja oliota 1.2 seuraava ilmentymä on 1.2.1. Samoin ilmentymää 1.1 seuraava ilmentymä on 1.2.1. Olioiden 2, 2.1 ja 2.1.1 sanakirjajärjestyksen mukainen seuraava olion ilmentymä on 2.1.1.1.
Kuvassa 11 on esitetty SNMP-viestin perusrakenne, eri operaatioviestien rakenne sekä näihin viesteihin sisältyvän olioinformaation yleisrakenne. Voidaan huomata, että kaikki luku- ja kirjoituspyynnöt ovat rakenteeltaan samanlaisia ja eroavat pyyntöihin lähetettävästä vastauksesta ainoastaan siinä, että niissä on virheilmoituksia varten varatut kentät nollia.
Lisäksi on huomautettava, että vaikka kuvan rakenteissa esiintyy kenttä viestin tyypille (PDU type), ei sitä ole standardissa määritelty. Standardissa määritellään viisi eri viestityyppiä, joihin sitten viestiä muodostettaessa kyseinen tyyppikenttä käytännössä muodostuu.
Toinen huomion arvoinen asia on SNMP-työryhmän epäonnistunut termien käyttö. Yleensä PDU-nimikettä käytetään jonkin protokollan koko viestistä, mutta SNMP:ssä sitä käytetään vain viestin informaatio-osalle.
Kaikki SNMP:n operaatiot koskevat yhden olion ilmentymän käsittelyä. SNMP-viesteissä on kuitenkin mahdollista sisällyttää yhteen viestiin useampia olioita käsitteleviä toimenpiteitä, mikäli niille suoritettavat operaatiot ovat samoja. Jos siis hallinta-asema haluaa lukea joltain hallinta-agentilta tietyn joukon olioita, se voi lähettää viestin, jossa on listattu kaikki halutut olioiden ilmentymät, ja saada vastauksen, jossa on kaikki kyseiset ilmentymät ja niiden arvot. Tämä tekniikka voi huomattavasti vähentää SNMP-viestien aiheuttamaa kuormaa verkossa.
Tämän tekniikan toteuttamiseksi kaikissa SNMP:n viesteissä on varattu tilaa olioita ja niiden arvoja varten. Kuvassa 11 tätä esittää variable bindings -kenttä. Tässä kentässä on sarja viittauksia olioiden ilmentymiin sekä niiden arvot. Tapauksissa, joissa tarvitaan ainoastaan olion ilmentymää (esimerkiksi lukupyynnöt), vastaanottava osapuoli ei huomioi arvokenttien sisältöä.
Kun SNMP-viesti saadaan kuljetuskerrokselta, suoritetaan seuraavat toimenpiteet:
Pyynnön vastaanottava hallinta-agentti vastaa pyyntöön GetResponse-viestillä, johon se sisällyttää pyynnön sisältämän viestitunnuksen. GetRequest-operaatio on luonteeltaan atominen, eli joko kaikki pyydetyt ilmentymien arvot palautetaan tai yhtäkään arvoa ei palauteta. Mikäli kaikille pyydetyille olioille voidaan antaa arvo, ne palautetaan variable-bindings-listassa. Mikäli on yksikin olio, jolle ei voida antaa arvoa, ei millekään oliolle palauteta arvoa ja viestiin sisällytetään virhekoodi.
Seuraavat virheet ovat mahdollisia:
Oletetaan, että hallinta-asema haluaa tietää jostain laitteesta sen yhteyshenkilön, nimen ja sijainnin. Tällöin se voi lähettää seuraavankaltaisen GetRequest-viestin:
GetRequest (sysContact.0, sysName.0, sysLocation.0)
Mikäli yhteisön näkymä laitteen MIB:issä sallii, se saa seuraavanlaisen viestin:
GetResponse ((sysContact.0 = Mika Hautaniemi), (sysName.0 = pizza.hut.fi), (sysLocation.0 = Y196))
Mikäli hallinta-agentilla ei olisi arvoa yhdelle pyydetyistä arvoista, se palauttaisi ainoastaan virhekoodin eikä yhtään haluttua arvoa. Varmistaakseen kaikkien haluttujen arvojen saamisen olisi hallinta-aseman lähetettävä kolme erillistä viestiä.
Mikäli käytettäisiin seuraavanlaista GetNextRequest-viestiä:
GetNextRequest(sysContact, sysName, sysLocation)
hallinta-agentti palauttaa jokaista oliota leksikograafisessa järjestyksessä seuraavan ilmentymän arvon. Mikäli kaikki arvot voidaan palauttaa, on vastaus sama kuin edellisessä tapauksessa, koska sysContact:a seuraava olion ilmentymä on sysContact.0 jne. Mutta mikäli esimerkiksi sysName-olio ei kuuluisi näkymään, hallinta-agentti palauttaisi seuraavanlaisen viestin:
GetResponse((sysContact.0 = Mika Hautaniemi), (sysLocation.0 = Y196), (sysLocation = Y196))
Koska sysName ei kuulunut kyseiseen näkymään, palautetaan järjestyksessä sitä seuraava ilmentymä ja sen arvo, jotka tässä tapauksessa ovat sysLocation.0 ja Y196.
GetNextRequest-viestiin liittyvät säännöt vaativat, että hallinta-agentti palauttaa sen olion ilmentymän, joka seuraa annettua olion tunnistetta. Missään ei esitetä vaatimusta, että annetun olion tunnisteen täytyisi esittää olemassa olevaa oliota tai sen ilmentymää. Hallinta-asema voi siten käyttää GetNextRequest-viestiä tutkiakseen hallintatietokannan näkymää tuntematta lainkaan sen rakennetta. Ensimmäisellä viestillä hallinta-asema saa tietää näkymän ensimmäisen tunnetun olion ja sen ilmentymän arvon samalla kertaa, ja se voi käyttää saamaansa oliota kysyäkseen seuraavan.
Viestin atomisuus on myös samanlainen GetRequest-viestin kanssa, eli mikäli yksikin olioista on virheellinen, yhdenkään ilmentymän arvoa ei muuteta, vaan palautetaan virhettä vastaava koodi. Koodit ovat samat kuin GetRequest-viesteille (noSuchName, tooBig, genErr). Lisäksi on koodi badValue, jolla kerrotaan, että saatu asetettava arvo on virheellinen. Virheellisyys voi johtua väärän tyyppisestä tai väärän mittaisesta arvosta tai itse arvon suuruudesta.
SNMP ei tarjoa mitään mekanismia, jolla voitaisiin antaa komentoja, jotka hallinta-agentti suorittaisi. Ainoat mahdollisuudet ovat lukea tai kirjoittaa olioiden ilmentymien arvoja. Periaatteessa on kuitenkin mahdollista käyttää hyväksi kirjoitusoperaatiota jonkin komennon suorittamiseen. Laitevalmistaja voi määritellä omaan MIB:iinsä olion, joka esittää komentoa, joka suoritetaan, kun oliolle annetaan tietty arvo. Esimerkiksi hallinta-agentissa voi olla olio reBoot, jonka alkuarvo on nolla. Kun kyseisen olion arvo asetetaan ykköseksi, laite käynnistää itsensä uudelleen ja asettaa olion arvoksi jällen nollan.
Trap-viestin kentät ovat:
---------------------------------------------------------------------------
PDU type Osoittaa, että kyseessä on ilmoitusviesti (Trap PDU).
Enterprise Identifioi viestin generoineen järjestelmän. Sen arvo
otetaan system-ryhmän sysObejctID-oliosta.
Agent-addr Kertoo viestin lähettäneen laitteen IP-osoitteen.
Generic-trap Yksi ennakkoon määritellyistä ilmoitusviestien tyy
peistä.
Specific-trap Koodi, joka voi osoittaa tarkemmin ilmoitusviestin
syyn.
Time-stamp Ilmoittaa, kauanko laite on ollut yhtäjaksoisesti toimin
nassa viestin lähettämishetkellä.
Variable-bindings Sisältää lisää viestiin liittyvää informaatiota. Näiden
tietojen merkitys riippuu toteutuksesta.
---------------------------------------------------------------------------
Generic-trap-kenttä voi saada yhden seitsemästä arvosta:
------------------------------------------------------------------------------
coldStart(0) Lähettävä laite alustaa (re-initialize) itsensä uudel
leen siten, että sen asetukset voivat muuttua.
Yleensä tämä on odottamaton uudelleenkäyn
nistys, joka voi johtua esimerkiksi vakavasta
viasta.
warmStart(1) Lähettävä laite alustaa itsensä uudelleen ilman
asetusten muutoksia.
linkDown(2) Lähettävä laite ilmoittaa jonkin sen tietoliikenne
yhteyden vikaantumisesta. Variable-bindings-lis
tassa on vikaantuneen linkin verkkoliitäntäolion
nimi ja arvo.
linkUp(3) Sama kuin edellinen, mutta nyt jokin tietoliikenne
yhteyksistä on jälleen toiminnassa.
autheticationFailure(4) Laite on saanut SNMP-viestin, jonka autentikointi
on epäonnistunut.
egpNeighborLoss(5) Laitteen EGP-protokollan mukaiseen naapuriin ei
enää saada yhteyttä.
enterpriseSpecific(6) Tämä on varattu laite- ja ohjelmistovalmistajien
omille ilmoitusviestityypeille. Tarkempi tieto on
specific-trap-kentässä.
------------------------------------------------------------------------------
MIB-II:n kuvaamien tietojen avulla voidaan saada tietoa, joka on puhtaasti paikallista kyseiselle hallinta-agentille. Esimerkiksi jossain lähiverkossa olevista MIB-II:ta tukevista laitteista voidaan saada kustakin laitteesta erikseen tietoa sen lähettämistä ja vastaanottamista paketeista. Tämän tiedon perusteella ei kuitenkaan ole kovinkaan helppoa saada kokonaiskuvaa kyseisen lähiverkon tilasta.
Standardissa kuvattu etähallinnan määrittely on pääasiassa MIB:in määrittely, mutta sen perusteella voidaan hyvin helposti määritellä ne tiedot ja toiminnot, joita etähallinnassa tarvitaan. Voidaan hyvin sanoa, että RMON-konsepti tarjoaa tehokkaan tavan valvoa lähiverkon tilaa ja samalla vähentää hallinta-asemaan, verkon liikenteeseen ja yksittäisiin laitteisiin kohdistuvaa kuormaa.
Kuvassa 13 on esitetty esimerkkikokoonpano etähallinta-agenttien käytöstä. Ylimpänä on hallinta-asema. Tämän lisäksi on kaksi lähiverkkoa, joissa on normaalien työasemien lisäksi laitteet, joissa toimii RMON-agentti. Toinen agenteista on toteutettu kuvan järjestelyssä reitittimessä ja toinen verkon työasemassa. Tällaisella järjestelyllä voidaan yhdeltä hallinta-asemalta seurata kolmen erillisen lähiverkon toimintaa.
Ryhmässä on laskurit mm. verkossa liikkuneille tavuille ja paketeille, havaituille pakettien virheille, törmäyksille sekä eri pituisille paketeille.
Näissä olioissa on lähes samat oliot kuin tilastoryhmässä, lukuunottamatta laskureita eri pituisille paketeille. Lisäksi ryhmässä on olio, jossa on arvio verkon käyttöasteesta kyseisellä aikavälillä.
Hälytyksille voidaan määritellä, mitä laskuria seurataan, minkä mittaiselta ajanjaksolta tietoa kerätään ja onko hälytyksen perusteena absoluuttinen vai arvon muutokseen perustuva hälytys. Lisäksi voidaan määritellä raja, jonka perusteella hälytys suoritetaan, sekä raja, jonka yli tai alle tarkkailtavan arvon on mentävä, ennenkuin suoritetaan uusi hälytys.
Tämän talukon lisäksi ryhmässä on toinen taulukko, jossa on vastaavat tiedot, mutta se on järjestetty laitteiden havaitsemisjärjestyksen mukaisesti. Edellinen taulukko on järjestetty laitteiden Ethernet-osoitteiden mukaisesti.
RMON-agenteilta saatavien tietojen perusteella voidaan tehdä jopa verkon rakenteen uudelleen suunnittelua [Leinwand93b]. RMON MIB:in olioiden avulla voidaan seurata esimerkiksi siirtotien käyttöastetta ja sen perusteella tehdä päätöksiä, olisiko siirtotie kenties syytä jakaa osiin. Myös törmäysten suhteellista osuutta on helppo seurata RMON:in avulla. Vaikka siirtotie ei olisikaan ylikuormitettu, voi sen pilkkominen olla tarpeen, mikäli törmäyksiä on runsaasti.
Törmäysten suhteellinen osuus voidaan laskea esimerkiksi näin.
Edellisessä kaavassa olevat etherStatsCollisions- ja etherStatsPkts-oliot ovat RMON MIB:in tilastoryhmän laskureita. Historiaryhmän vastaavia olioita tutkimalla voidaan edelleen selvittää, onko laskettu törmäysprosentti normaali vai ainoastaan yksittäinen törmäyspiikki.
Joissain tapauksissa RMON-agenteilla voidaan korvata perinteisiä protokolla-analysaattoreita [Waldbusser92b]. Yksinkertainen verkon analysointijärjestelmä voi koostua useista RMON-agenteista ja yhdestä hallinta-asemasta. RMON-agentit keräävät tietoa verkon tilasta lukemalla kaikki verkossa kulkevat paketit eli toimivat periaatteessa samalla tavalla kuin protokolla-analysaattorit. Kerätty data lähetetään hallinta-asemalle, jossa sitä voidaan käsitellä edelleen ja esittää halutussa muodossa.
Koska RMON-agenttien kaikki toiminnot suoritetaan verkon välityksellä, niihin ei ole tarpeen sisällyttää kalliita näyttöjä tai levyjä. Vain hallinta-asemassa tarvitaan laitteet käyttöliittymää varten. Tällä tavalla RMON-agentteihin perustuva järjestelmä voi olla huomattavasti halvempi kuin perinteinen analysaattoriin perustuva systeemi. Protokolla-analysaattorit ovat yleensä myös toteutukseltaan sellaisia, että niiden käyttö on mahdollista vain paikan päällä. Huomattavaa on myös se, että RMON-agentit suorittavat yleensä useita tehtäviä yhtä aikaa. Näin on mahdollista tehdä yksittäisiä lyhyitä valvontatehtäviä ilman, että tarvitsee keskeyttää jatkuvaa tilastointia.
SNMPv2 eroaa edeltävästä versiosta pääasiassa seuraavien osalta:
Yhteyskäytäntöön on otettu mukaan kaksi uutta SNMP-viestiä. GetBulkRequest-viestin avulla hallinta-asemat voivat tehokkaammin pyytää hallinta-agenteilta suuria tietomääriä. Erityisesti se soveltuu suurten taulukoiden tietojen lukemiseen. InformRequest-viesti antaa hallinta-asemalle mahdollisuuden lähettää Trap-viestin tyyppistä informaatiota toiselle hallinta-asemalle.
SNMPv2:n määrittelyssä kuvataan kaksi MIB:iä. SNMPv2 MIB kuvaa vastaavat verkon liikenteeseen liittyvät tiedot kuin SNMP:n MIB-II. Erityisesti hajautetun verkonhallinnan tukemiseksi mukaan on otettu MIB, joka kuvaa hallinta-asemien välisen kommunikoinnin tarvitsemat oliot (M2M MIB, Manager-to-Manager MIB). Sen tarjoamat toiminnot ovat hyvin pitkälle samanlaiset kuin RMON MIB:issä.
SNMPv2:n turvallisuutta lisäävät ominaisuudet ovat hyvin pitkälle samat kuin sen pohjana olleen turvallisen SNMP:n ominaisuudet. Turvallisuuden varmistamiseksi on luotu mekanismit, joiden avulla voidaan autentikoida viestien lähettäjä sekä saadun tiedon integriteetti eli eheys. Näillä mekanismeilla voidaan suojautua aktiivisilta turvallisuusriskeiltä. Passiivisten riskien minimoimiseksi voidaan turvallisuutta edelleen parantaa salaamalla viestit. Autentikoinnin ja tiedon integriteetin varmistaminen tapahtuu MD5-algoritmin avulla. MD5 on MIT:ssä kehitetty, lähinnä digitaaliseen allekirjoitukseen tarkoitettu kryptografinen hajautusfunktio [RFC1321]. Viestien salaukseen käytetään DES-algoritmia (Data Encryption Standard). DES:in huono puoli on se, että se kuuluu siihen joukkoon tuotteita ja algoritmeja, joita ei saa viedä USA:n ulkopuolelle. Tämän takia sen osalta USA:sta tuotavat ohjelmistot ovat joko puutteellisia tai DES-osuus koodista on tehtävä USA:n ulkopuolella. Yksi DES-toteutus on tehty Teknillisessä korkeakoulussa Antti Loukon toimesta.
Siirtymäkauden järjestelmän toteuttamiseksi on kaksi tapaa [RFC1452]. Yksinkertaisin tapa toteuttaa yhteiskäyttö protokollatasolla on pitää hallinta-agentit ennallaan ja kommunikoida niiden kanssa valtuutusagentin välityksellä. Kaikki laitteille tehtävät SNMPv2-kyselyt lähetetään valtuutusagentille, joka suorittaa kyselyiden muunnoksen SNMP-kyselyiksi ja välittää ne edelleen SNMP-hallinta-agenteille. Saadut vastaukset valtuutusagentti muuntaa SNMPv2-viesteiksi ja välittää ne hallinta-asemalle.
Toinen tapa yhteiskäytön mahdollistamiseksi on toteuttaa hallinta-asemien ohjelmisto siten, että ne ovat `kaksikielisiä'. Hallinta-asemalla on paikallisessa tietokannassaan informaatio eri laitteiden ymmärtämästä SNMP-versiosta, ja se kommunikoi hallinta-agenttien kanssa niiden ymmärtämän protokollan välityksellä.
Eräs tärkeä SNMP-pohjaisen järjestelmän toteutuksessa tarvittava tieto on se, kuinka montaa hallinta-agenttia yksi hallinta-asema voi hallita. Tällöin on määriteltävä, kuinka usein laitteille halutaan esittää kyselyitä ja mikä on verkon aiheuttama keskimääräinen viive. Yksinkertaistamalla ongelmaa siten, että ainoastaan yhdelle laitteelle kerrallaan tehdään kyselyitä, voidaan muodostaa seuraavanlainen yhteys valvottavien laitteiden määrän (N), halutun kyselyvälin (T) ja yhteen kyselyyn kuluvan ajan välille (delta) [Stallings].
Kyselyyn kuluva aika (delta) riippuu useista tekijöistä:
Toisin sanoen esimerkin mukaisessa tilanteessa yksi hallinta-asema voisi hoitaa noin 4400 hallinta-agentin tietojen kyselyt.
Laajassa verkossa, joka muodostuu useista aliverkoista, voi verkon aiheuttama viive olla huomattavasti suurempi. Tämä voi johtua esimerkiksi pienemmistä tiedonsiirtonopeuksista ja suuremmista etäisyyksistä. Oletetaan verkon aiheuttamaksi viiveeksi 0,5 sekuntia, jolloin yhden hallinta-aseman hoidettavana olevien hallinta-agenttien ylärajaksi saadaan.
Voidaan havaita, että näissä esimerkeissä verkon aiheuttama viive on erittäin merkittävä tekijä määritettäessä yhden hallinta-aseman hallittavissa olevien hallinta-agenttien lukumäärää.
Edellinen esimerkki kuvaa SNMP:n toista suurta ongelmaa, tehokkuutta. SNMP ei tarjoa mekanismia suurten tietomäärien siirtämiseen, ja usein tilanne on sellainen, että kaikkien haluttujen tietojen saamiseksi on tehtävä useita kyselyitä. Laajoissa verkoissa, joissa vasteajat voivat olla hyvinkin pitkiä, voi SNMP:n kyselyihin perustuva valvonta olla liian hidasta ja, kuten esimerkistä havaitaan, hallittavien laitteiden lukumäärä voi olla hyvin pieni. SNMP-kyselyt aiheuttavat myös lisäkuormaa verkkoon, mutta useimmissa tapauksissa tämä lisäkuorma ei ole kovinkaan merkittävä, jos se suhteutetaan kaikkeen verkon liikenteeseen [Waldbusser92a].
Edellisten esimerkkien perusteella voisi olettaa, että laajojen verkkojen valvontaan tarvittaisiin useita hallinta-asemia. SNMP:n tällä hetkellä käytössä oleva versio ei kuitenkaan tue hallinta-asemien välistä kommunikaatiota, vaan se on mahdollista vasta SNMPv2:ssa.
Toinen ongelma standardi-MIB:ien toteutuksiin laitteissa liittyy niiden tarkkuuteen. Joissakin testeissä on havaittu, että osa toteutuksista ei kykene kovinkaan tarkasti pitämään kirjaa eri olioihin liittyvistä laskureista [Stallings]. Tällöin hallinta-agenteilta saatavien tietojen perusteella tapahtuva verkonhallinta ei ole kovinkaan vankalla todellisuuspohjalla.
Eräs suuri ongelma SNMP-toteutuksissa liittyy laitevalmistajien omiin MIB:eihin. Kuten aikaisemmin on mainittu, on laitevalmistajille varattu oma ryhmä (enterprises), jonka alle laitevalmistajat voivat rekisteröidä omat MIB:insä. Tämä järjestely hankaloittaa huomattavasti keskitetyn verkohallinnan toteutusta, koska eri laitteilla voi olla saman informaation sisältävä laskuri, mutta kukin näistä on rekisteröity eri ryhmään.
Omat lisäongelmansa tuovat erilaiset valtuutusagenttiratkaisut [Chen]. Useat valmistajat ovat käyttäneet oikoteitä SNMP:n toteuttamiseksi omien laitteidensa hallintaan valtuutusagenttien avustuksella. Nämä ratkaisut vaativat yleensä erillisen mikrotietokoneen (PC), joka toimii valtuutusagenttina esimerkiksi valmistajan päätepalvelimille. Mikäli käytössä on usean eri valmistajan laitteita, tarvitaan näiden hallintaan useita lisälaitteita, joista aiheutuu lisäkustannuksia ja jotka lisäävät kunnossapidettävien laitteiden lukumäärää.
