Protokoli i arhitekture u sustavima upravljanja mrežom - osnove ...

Fakultet elektrotehnike i računarstva
xxxx
Zavod za telekomunikacije
SEMINAR:
Protokoli i arhitekture u sustavima upravljanja mrežom
Zagreb, 25.01.2005.

1. Strukture za upravljanje mrežama
1.1. Arhitekturalna koncepcija
1.1.1. Razina elementa
Na najnižoj razini telekomunikacijskih mreža nalaze se neke mrežne komponente kao što
su preusmjeritelji, routeri, hubovi, i sučeljska oprema; svaka pogodna za određeni posao.
Komponente mogu biti proizvedene od više dobavljača, svaki nudi svoje prikladne softwere
dizajnirane više da omoguće stručnjacima da poprave komponentu nego da daju informacije
korisne za više razine upravljanja. Upravljanje ovim elementima zahtijeva da svaka komponenta
bude konstantno nadgledana da se osigura njihov optimalan rad. Softwer za upravljanje
elementima mora biti u mogućnosti da nadgleda i regulira mnoge mrežne komponente i daje
informacije koje mogu biti korisne na višim razinama upravljačkih aplikacija.
Slika 1. Arhitektura telekomunikacijske mreže
1.1.2. Razina mreže
Slika 1 pokazuje tipičan skup telekomunikacijskih mreža od kojih svaka može koristiti
elemente od različitih proizvođača. Neke mreže mogu biti ovisne o nekim drugima (u našem
primjeru, Frame-Relay je ovisna o mreži ATM, koja je ovisna o mreži SDH). Najvažniji zadaci
za svaku mrežu uključuju povezanost i izvođenje. Informacija iz pojedinog mrežnog elementa
mora biti dostupna da bi se stvorila slika općeg stanja mreže. Koristeći ove informacije, sustav za
upravljanje mrežom može donositi odluke o tome kako preusmjeriti promet i tako smanjiti
mrežna gomilanja ili smanjiti mogućnost većih problema.
1.1.3. Razina usluge
Usluga koja se nudi korisniku može sadržavati nekoliko mreža. Zadatak ove razine
upravljanja uključuje cijenu, korisničku uslugu, i kreiranje novih usluga. Ovakav sustav također
mora nuditi osobnu uslugu sa mogućnosti kreiranja, nadgledanja i podržavanja za individualnog
korisnika. Dodatno, ovo dozvoljava razmjenu ovisnih mrežnih tehnologija, na primjer, ako
korisnik koji je našao uslugu koja je prespora preko mreže Frame-Relay može biti brzo
promijenjena u uslugu ATM mreže.
Tipična telekomunikacijska usluga je prikazana na slici 2. U ovom primjeru korisnik želi usluge
mreže Frame-Relay ali provedba ove usluge ovisi o mreži koja uslugu nudi. Prema tome,
nekoliko mreža mora biti nadgledano da se utvrdi da je kriterij izvođenja usluge nađen.

Nadgledanje usluge je potreban da se nađe točno onakva usluga kakvu je korisnik zatražio.
Usluga održavanja osigurava da, ako se kvaliteta može povećati ili ako se pojavi problem,
potrebna poboljšanja se rade bez odgode.
Slika 2. Tipična telekomunikacijska usluga
1.1.4. Razina poslovanja
Na kraju, sustav upravljanja mora osigurati podršku za poslovno upravljanje. Odluke o
tome koja usluga je uspješna, zaradi i cijeni, i općenito izvođenje poslova mora biti podržano u
sustavu upravljanja.
Slika 3. Hijerarhija upravljanja uslugama
1.1.5. Telecommunications management network (TMN)
Sa različitim zahtjevima svakog nivoa upravljanja, kako jedan sustav može osigurati
zahtjeve koje postavlja neka organizacija?
Koristeći primjere sa slika 1 i 2 i kombinirajući ih dobivamo sliku 3. Prvi sloj sadrži mrežne
elemente, drugi sloj predstavlja mrežu i elemente usluge, a najviši sloj sadrži usluge. Ova podjela
po slojevima omogućava takav dizajn arhitekture u kojem postoje softweri koji rade na
pojedinim slojevima i komuniciraju između susjednih slojeva preko vrlo dobro definiranih
sučelja. Takva arhitektura je definirana kao TMN. TMN je hijerarhija koja ostvaruje
funkcionalnost preko pet razina (slika 4).
Najniži sloj sadrži mrežne elemente (kao usmjeritelji ili routeri). Informacije o upravljanju koje
pripadaju mrežnim elementima prosljeđuju se do sloja za upravljanje mrežom, koji ima pet
funkcija.
Različite mreže, podmreže i elementi mogu biti integrirani na ovoj razini. Sloj upravljanja
uslugama omogućava da vidimo skup mrežnih elemenata kao uslugu. Najviši sloj je sloj
poslovnog upravljanja, koji se brine za upravljanje skupom usluga.

Slika 4. TMN hijerarhija
Komunikacija između svakog sloja TMN hijerarhije je prikazano na slici 5. Svaki sloj sadrži
OSF (Operating System Function), koji prosljeđuje informacije za nadzor i/ili kontrolu.
Komunikacija između OSF-ova unutar četiri najviša TMN sloja je definirana Q3 sučeljem.
Komunikacija između najnižeg sloja i ostalih slojeva može biti ostvarena sa Q3 ili Qx sučeljem.
Elementi koji nisu Q3 kompatibilni moraju komunicirati preko Qx sučelja. Na sloju upravljanja
elementima Qx mora biti pretvoren u Q3 pomoću QA (Q-Adaptor). Specifikacija protokola Q3 i
Qx je objašnjena u poglavlju 2.4.
Ima mnogo TMN produkata. Neki od poznatijih su: NetExpert OSI, TeMip Digital, Openview
HP, Tivoli IBM i ISM BULL.
Slika 5. Q3 sučelje

1.2. TINA
TINA (Telecommunications Information Networking Architecture) priključuje filozofiji
TMN-a detaljnu arhitekturu prilagođenu distribuiranoj prirodi modernih telekomunikacijskih
mreža. Kao i TMN, TINA ja fokusirana na:
-objektno orijentirani dizajn, koji sustave pretvara u lako upotrebljive komponente
-distribuirane mreže softwerskih elemenata, koje mogu prilagoditi prometni tok i zahtjeve
za pouzdanosti
TINA specificira slojnu arhitekturu, koja odvaja aplikaciju, usluge, resurse i elemente koristeći
dobro definirana sučelja. TINA dodaje TMN-u DPE (distributed processing environment).
Slika 6 prikazuje TINA DPE kao sloj između aplikacije i mrežnih hardwera. DPE čini aplikacija
sa jednim sučeljem za različite usluge. Funkcionalnost iza ovog sučelja je transparentno
implementirana na jednoj ili više platformi. Svaka implementacija tada komunicira sa mrežnim
hardwerima preko transportne mreže (na primjer TCP/IP). TINA aplikacije će biti podupirane
bilo kojom spremnom DPE platformom, i aplikacije koje se pokreću na različitim DPE
platformama mogu komunicirati preko standardnih mehanizama. Prema tome, DPE je važan
međusloj koji rješava probleme heterogenosti i distribuiranosti.
Još jedna bitna razlika između TMA-a i TINA-e je koncept TINA sesije. Sesije su spremnici
stanja; one čuvaju informacije koje koriste svi entiteti koji su uključeni u dobavljanje neke
usluge. Koncept sesije je osmišljen tako da podržava ove tri funkcije: pristup (uspostavljanje i
postavljanje sesije), usluga (stvarno dobavljanje usluge) i komunikacija (postavljanje konekcije i
nadgledanje mreže). Bit implementiranja na ovoj razini znači da se neki jednostavni korišteni
protokoli (kao SNMP) mogu lako integrirati u TINA aplikaciju.
1.3. Korporacijske mreže
Slika 6. TINA DPE
Za velike korporacije pristup upravljanju mrežama je vrlo koristan. Upravitelji
korporacijskim mrežama moraju osigurati pouzdanu mrežu bez prevelikih zahtjeva za ljudskom
pomoći. Kao rezultat toga, sofisticirani sustavi za upravljanje mrežom nisu previše privlačne za
upotrebu. Umjesto njih, jednostavni pristup je korišten sa spoznajom da jednostavan dizajn ima
jednostavne nedostatke koje je lagano ispraviti.
Alati kao Netview (IBM-ova verzija OpenView-a) i CiscoWorks (alat za upravljanje CISCO
routerima) čine bazu na temelju koje se grade mreže, ali zahtjeva napor da se to izvede. Ovi alati
često ne rade ispravno ili jednostavno ne odgovaraju organizaciji.
Mnoge korporacije biraju za korištenje jednostavnije alate za upravljanje kao PING i MRTG
kombiniranih sa nekim softwerima napravljenima za određene svrhe. Na primjer, proučavanja
jedne velike korporacijske mreže su pokazala da je upravljanje jednom njihovom velikom
nacionalnom IP mrežom je djelotvorno ostvareno koristeći neke osnovne alate kao PING,
usmjeritelji i MRTG zajedno sa NetView-om.

U proteklim godinama postoji pomak od privatnih mreža (kao SNA ili DECNet) prema mrežama
baziranim na IP mrežama. Ove mreže su potpuno razvijene i dobro definirane i kao rezultat
jeftinije za izgradnju i mnogo alata za upravljanje postaje dostupno. Sa ovim trendom naginjanja
IP mrežama, mnoge korporacije se koncentriraju na upravljanje IP mrežom, prosljeđujući detalje
o najnižoj razini telekomunikacijskoj mreži. Slika 7 pokazuje ovaj odnos, gdje usluga ostvarena
u telekomunikacijskoj mreži upravlja razinom elemenata korporacije. Takva strategija prepušta
telekomunikacijskoj mreži¸upravljanje najnižom razinom dok se korporacija koncentrira na
upravljanje višim razinama mrežnih usluga i na poslovne solucije. Iz inata prema ovom
naginjanju IP mrežama, mnogi sustavi za upravljanje još koriste privatne mreže (kao Netscape's
Directory Server, koji radi samo sa Netscape pretraživačima). To limitira upotrebljivost mnogih
takvih alata za upravljanje. Drugi alati za upravljanje koji rade na različite načine su limitirani u
funkcionalnosti (kao SMS koji radi na Windowsima NT).
Bez upotrebljivog izvornog koda, ograničenom podrškom i bez realnih mogućnosti prilagodbe
proizvoda određenim potrebama, takvi alati služe za pristup upravljanju mrežama, radije nego
kao temelj samog upravljanja.
Kao zaključak, korporacijske mreže su kompleksne i često zahtijevaju posebno, za njih
namijenjeno upravljanje. Sustavi za upravljanje nabavljeni «na crno» ne mogu biti efikasno
prilagođeni zahtjevima korporacije. Rješenje je u kompromisu između postojećih jednostavnih
pouzdanih alata i nekih privatno proizvedenih softwera, i nastajanje jednostavnih, ne skupih i
pouzdanih sustava za upravljanje mrežama.
Slika 7. Arhitektura korporacijske mreže
2. Tehnologije korištene u sustavima upravljanja mrežama
2.1. SNMP
Različite verzije SNMP-a su proizvedene ali najviše se koristi sada SNMPv2c koji se
većinom temelji na SNMPv2, i specificiran je u RFC-ima. SNMPv3 je predložena 1998. i
kombinacija je sigurnosti sa radom protokola i tipovima podataka iz SNMPv2 protokola. Dobri
principi izgradnje softwera su korišteni da se izgradi protokol koji se temelji na osnovnom
modelu, dopuštajući dodatne nadogradnje i manju kompatibilnost za lakšu implementaciju. Ovaj
pristup također osigurava i podršku za različite sigurnosne protokole.

Slika 8 pokazuje tipičnu konfiguraciju SNMP protokola. Svaki upravljani objekt u mreži mora
implementirati SNMP, UDP i IP zajedno sa procesom agenta koji je odgovoran za suradnju sa
MIB-om (Management Information Base) objekta i odgovara na SNMP poruke. Otkad SNMP
operira preko UDP protokola to je tzv. «connectionless» protokol, što je dovelo do odluke
promovirane kao « Mit kolapsirajućih mreža ». Mreže sa bazom su u prednosti pred onima bez
baze, kojih je većina danas, u trenucima neispravnog rada mreže. U slučajevima kada se prekine
TCP tok podataka, zbog teškog kvara na vezama ili greške na routeru, niti UDP tok ne prolazi.
Premda je jednostavnost koju su postigli kreatori SNMP-a rezultirala jednostavnom
implementacijom i rasprostranjenu upotrebu, to je donijelo i neke ozbiljne nedostatke. Najvažniji
je u području funkcionalnosti i sigurnosti. SNMP podržava samo centralizirani model
upravljanja. Rad sa velikim brojem podataka (npr. tablice) zahtijeva nekoliko SNMP poruka što
rezultira povećanim prometom u upravljivim mrežama, što je očito nedostatak. Samo
jednostavna identifikacija je potrebna (npr. lozinka), prema tome, kontrola aplikacije je
nesigurna. Dalje nadogradnje SNMP-a se bave rješavanjem ovih problema.
Slika 8. Arhitektura SNMP protokola
2.2. RMON
Važan dio upravljanja mrežama leži u nadgledanju dijelova mreže s ciljem da se dobiju
neke informacije o greškama ili statistika o radu mreže. Tradicionalno, posebno dizajnirani
mrežni monitori se koriste za ovu svrhu. Kako je memorija računala postajala jeftinija logika
mrežnih monitora se ugrađuje u druge mrežne uređaje kao file-serveri. Neki programi na
aplikacijskoj razini žele pokupiti statistiku sa svake stanice za nadgledanje mreže s ciljem da
napravi centralni pogled na mrežu. SNMP nema ovu funkcionalnost. Da se riješi ovaj problem
razvijen je RMON (Remote Monitoring) MIB. Ovim dobivamo spremnik za statistiku u obliku
MIB-a dostupnog SNMP-u. Prije je centralna stanica za upravljanje bi pokupila podatke sa nižih
razina od uređaja okolo mreže i obavila analize koje se zahtijevaju da se generira tražena
statistika. Kako su mreže postajale veće, stanice za upravljanje je trebala postati sve snažnija što
je rezultiralo problemima.
Primjer mreže sa slike 9 je inicijalno konfigurirana bez RMON-a. Stanica za upravljanje mora
pokrenuti svaki uređaj u mreži u jednakim intervalima da uzme podatke i analizira ih. U točkama

Slika 9. Primjena RMON-a na mrežu
D, E i C promet iz svake podmreže će biti prihvatljiv. Kada ovaj promet bude prolazio točkama
B i A velika je mogućnost nastanka problema. Zbog toga, centralni LAN mora biti u mogućnosti
raditi sa velikom količinom prometa, što zahtijeva dodatne nadogradnje koje koštaju.
Nadalje, što se događa kada se WAN link u točki G nagomila prometom? Uvođenjem RMON-a
u mreže u svaku od označenih točaka, problemi oko zakrčenja se mogu izbjeći. RMON entitet
unutar svake podmreže skuplja podatke i generira traženu statistiku. Stanica za upravljanje tada
može zatražiti svaki RMON entitet kada mu je to potrebno. Ako je podmreža izolirana od
centralnog LAN-a duže vrijeme, RMON entitet može nastaviti nadgledanje (off-line operacija).
RMON entiteti mogu biti konfigurirani da obavještavaju konkurentno svakog upravutelja.
Nedostatak RMON-a je nesposobnost rada preko MAC sloja jer je izvorno dizajniran za usluge
udaljenog nadgledanja za fizičke mreže i kao rezultat toga RMON MIB sadrži definicije objekata
za te slojeve.
RMON2 je modifikacija RMON-a koja uključuje nadgledanje prometa unutar slojeva od 3 do 7.
Odavde, promet na određenim mrežnim adresama (npr. IP adresa) ili između određenih hostova
(npr. WWW serveri) može biti nadgledan. Ovo omogućava sustavu za upravljanje da odredi
pravi izvor i odredište prometa.

2.3. CMIP
Slika 10. Veza između CMIS-a i CMIP podataka
CMIP definira proceduru za prijenos upravljačkih informacija. Svaka CMIP PDU je blok
napravljen za konstruiranje kompleksnijih upravljačkih usluga zvanih CMIS (Common
Management Information Service). To je pokazano na slici 10.
Svaki upravljački sustav mora pokušati riješiti tri zahtjeva:
- ne smije ozbiljno narušavati rad mreže
- odluke se moraju donositi i radnje poduzimati brzo
- široki raspon usluga mora biti omogućen da se omogući detaljno nadgledanje i kontrola
U slučaju OSI/CMIP upravljačkih sustava, zahtjevi 2 i 3 se podudaraju sa cijenom. U skladu sa
nizom upotrebljivih usluga i veličinom OSI MIB-a, krajnje implementacije su usmjerene prema
generiranju velike količine mrežnog prometa.
Ova veličina prometa i kompleksnost sprečava prilagodbu korisnicima i prodavačima također.
Ali, sa napretkom u mrežnim tehnologijama (kao npr. Gigabit-ni Ethernet) i sve većim brojem
zahtjeva prema mrežnim upravljačkim sustavima, CMIP se ponovno preporodio zahvaljujući
sučelju Q3.
2.4. TMN standardna sučelja Q3 i Qx
Sučelja Q3 i Qx su spominjana u odlomku 1.1.5 kao komunikacija između slojeva TMN
hijerarhije. Q3 sučelje se nalazi između OSF-a (Operating System Functions), Q-adaptera (QA) i
mrežnih elemenata (NE- network elements). Na primjer, slika 11 pokazuje ponašanje funkcije za
upravljanje (OSF) koja komunicira direktno sa Q3-kompatibilnim usmjeriteljem (na mrežnim
elementima). Isti OSF također komunicira sa Q3-nekompatibilnim usmjeriteljima preko Q-
adaptera.
Qx sučelje nosi informacije protokola koji nisu prilagođene TMN-u od mrežnih elemenata koji
se nalaze na sloju elemenata. Na primjer, QA sa slike 11 komunicira sa Q3- nekompatibilnim
mrežnim elementom i onda šalje informacije preko Q3 dalje do OSF-a.
F sučelje se nalazi između radne stanice (engl. Workstation, WS) i OSF-a. Slika 11 također
ilustrira traženje informacija radne stanice od OSF-a na sloju poslovnog upravljanja.
X sučelje služi za komunikaciju između dva različita sustava upravljanja. Na slici 11 vidimo da
kompanija A traži poslovne informacije od OSF-a sa sloja poslovnog upravljanja. Također se
vidi ovisnost kompanije B (korisnik usluga) o kompaniji X. Razmjena upravljačkih informacija
između IBM-ove Tivoli i HP-og Openviewa je primjer implementacije X sučelja. X sučelje može
biti implementirano preko nekog zamjenskog agenta dok njegova implementacija ne bude
prihvaćena.
Q3 je opisan kao sučelje treće razine između OS-a i mrežnih elemenata. Početno su bila
definirana tri sučelja u TMN fizičkom modelu: Q1, Q2 i Q3. broj odgovara povećanoj razini

lika 11. Sučelja između TMN komponenata
inteligencije ili kompleksnosti pojedinog sučelja. Zahtjevi za Q1 i Q2 nisu nikad točno
definirani, pa je odlučeno da se ta dva sučelja ujedine u jedno nazvano Q3. Q3 je u biti CMIP,
dok je Qx sadrži nekoliko protokola (kao SNMP, SS7, ili čak protokoli bazirani na ASCII
porukama).
Nekoliko velikih korporacija i davatelji telekomunikacijskih usluga koriste TMN da bi
modernizirali svoje upravljanje mrežom. Ovaj povećani interes se odrazio na implementaciji
CMIP-a, nakon više od desetljeća otkad je dizajniran.

2.5. Suvremena dostignuća
2.5.1. Upravljanje bazirano na Web tehnologiji
Slika 12. Interakcija WBEM tehnologija
Upravljanje bazirano na Web tehnologiji (Web-based enterprise management - WBEM)
specificira grupu tehnologija, koje osiguravaju pristup i podacima i elementima za upravljanje.
Tehnologije koje se koriste za WBEM su: CIM (Common Information Model), XML
(extensibile mark-up language) i HTTP. Slika 12 pokazuje kako ove tehnologije mogu biti
integrirane.
CIM je uzet iz HMMS-a (Hyper Media Management Schema). CIM se koristi da se opišu
ukupne upravljačke informacije. Implementacija čini zajedničko razumijevanje upravljačkih
podataka iz različitih upravljačkih sustava i prema tome, pojednostavljeno integriranje tih
podataka iz različitih izvora u zajednički spremnik. CIJM meta sheme su korištene da se
predstave objekti iz stvarnog svijeta koji se nadgledaju. CIM koristi objektno orijentiranu
paradigmu, gdje nadgledani objekti su modelirani koristeći koncept klasa i njihovih instanci.
HMMP (Hyper-media management protocol) je dizajniran da omogući suradnju razina
procesiranja koristeći HTTP. Ideja korištenja stateless protokola za prijenos upravljačkih
informacija je dovelo do njegovog odbijanja od strane IETF, ali kao zamjena je razmatran OMGov
(Object Management Group) Internet Inter-ORB protokol.
XML se koristi za prilagođavanje CIM meta shema za distribuciju između CIM omogućenih
aplikacija, dok HTTP osigurava pronalaženje upravljačkih informacija od servera za upravljanje.
XML čini standard za opis strukturiranih podataka preko weba sa ugrađenomupotrebom
definicija za tipove dokumenata (DTD – document type definition). Korištenje HTTP-a
osigurava prednosti neutralnosti i jednostavnosti aplikacija. Ovi faktori bi trebali pomoći razvoju
WBEM aplikacija.
2.5.2. Arhitekture za upravljanje distribuiranim objektima
Veliki razvitak weba kombiniran sa razvojem vrlo brzih i multimedijskih mrežama je
dovelo do distribuiranog procesiranja. Da bi se pojednostavilo upravljanje komponentama
baziranim na softwerima, dva slična distribuirana objektna modela su razvijena – CORBA
(Common Object Request Broker Architecture) i DCOM (Distributed Component Object
Model).
DCOM je distribuirana nadogradnja na COM koja sadrži objektno baziranu udaljenu proceduru
zvanu sloj na vrhu DCE RPC-a s ciljem podržavanja nadgledanja udaljenih objekata. COM
server može stvoriti instancu klase. COM objekt može podržati više sučelja , svako
predstavljajući različito ponašanje nadgledanog objekta. Na primjer, mrežni router može imati
dva sučelja, svako predstavlja različitu verziju softwera. COM klijent surađuje sa COM
objektom postavljajući pointer sučelja objekta čiju metodu želi pozvati. U ovom primjeru sustav
za upravljanje mrežom može raditi neovisno o pojedinim verzijama softwera.

CORBA je distribuirani objektni sustav predložen od skupine od preko 700 kompanija nazvanih
Object Management Group (OMG). Jezgra CORBA arhitekture je Object Request Broker (ORB)
koji predstavlja objekt preko kojeg objekti transparentno komuniciraju sa drugim lokalnim ili
udaljenim objektima. CORBA objekt prema vanjskom svijetu predstavlja sučelje sa skupom
metoda, a instanca nekog objekta je predstavljena kao referenca na objekt.
I DCOM i CORBA su bazirane na modelu klijent – server. Za traženje usluge, klijent poziva
metodu implementiranu na udaljenom objektu, koji predstavlja server u modelu klijent – server.
Usluga koju daje server j implementirana u nekom objektu, a sučelje objekta je opisano pomoću
IDL-a (Interface Definition Language).
I u DCOM-u i u CORBA-i, interakcija između procesa klijenta i objekta servera je
implementirana objektno orijentiranim RPC stilom komunikacije. Slika 13 pokazuje tipičnu RPC
strukturu za DCOM i CORBA-u. Aplikacija treba samo znati o DCOM ili CORBA klijentskom
sučelju i ne treba znati ništa o arhitekturi. Za pozivanje udaljene funkcije, klijent zove klijentski
« stub », koji pakira parametre zahtjeva i prosljeđuje zahtjev transportnoj mreži prema serveru.
Na strani servera, transportna mreža dostavlja poruku stubu servera, koji raspakirava zahtjev i
poziva traženu funkciju objekta. Na ovaj način upravljana transportna mreža može pružati
transparentno usluge svojim klijentima bez obzira na promjene u upravljačkoj arhitekturi.
Slika 13. Razdvajanje upravljačkih funkcija koristeći DCOM ili CORBA sučelja
2.5.3. Policy-based networking (PBN)
PBN je jedno vrijeme bio samo ideja. Osnovna ideja PBN-a je stvoriti set politika za
upravljanje i staviti ih u neki repozitorij odakle se dostavljaju ostalim relevantnim mrežnim
entitetima kada je to potrebno. Svaki od tih entiteta tada implementira dio politike koja ga
zanima.
Nekoliko inicijativa trenutno rade na razvoju PBN-a: DEN (Directory Enabled Networking),
LDAP (Lightweight Directory Access Protokol) i RSVP (Resource Reservation Protocol). Slika
14 ilustrira odnose između ovih tehnologija.
DEN je repozitorij informacija za PBN. DEN osigurava mogućnost povezivanja profila korisnika
i drugih korisničkih informacija kao što je IP adresa. Ključ uspjeha DEN-a će biti u
standardizaciji definicija objekata. DEN se može usporediti sa SNMP SMI.
LDAP određuje koji standardizirani DEN će biti propušten kroz mrežu. Za razliku od DEN-a,
LDAP je prošao RFC proces i postoji implementacija, zadnja je LDAP3.0. LDAP je DEN-u isti
kao i SNMP i MIB-u – komunikacijski protokol za pristup spremniku upravljačkih informacija.
RSVP je jedan od nekoliko mogućih shema koje se mogu koristiti za implementaciju mrežnih
politika.
DEN još uvijek čeka ratifikaciju od DMTF-a prije nego bude uključen u CIM (Common
Information Model). Niti jedna shema za zauzimanje resursa (pa čak niti RSVP) nije na široko

Slika 14. Odnos između PBN tehnologija
implementirana. Zamisao PBN-a ne može biti realizirana sva dok sve komponente ne budu
standardizirane.