> >In my view this may be a good idea for higher management layers but
> >for element management layers, replacing SNMP with CORBA may put
> >too much of a overhead on the network traffic.
> Why? Is BER that much better than GIOP/IIOP at packing data? Or is
> it the TCP overhead verses UDP overhead? It seems to me that in some
> cases CORBA would win -- particularly over something like walking a
> big SNMP table element by element.
Network performance is definitely an issue. In SNMP model systems
work on a understanding that operations traffic is higher priority
than the management traffic. Also with SNMPv2C getBulk primitive
even walking over tables results in lesser traffic.
Quote:> Plus with CORBA you get function call semantics, not just
> set-get-this-parameter[-set] or add-a-row-to-a-table semantics. This
> might allow the device vendor to expose the entire management
> interface via CORBA instead of just filling out the mib-2 interface
> table and letting the rest of the configuration be done by a serial or
> telnet connection, or an ad-hoc set of web pages.
I agree that SNMP does not provide function call semantics and it is
a serious limitation.
Quote:> Ok, I know this doesn't mean much, but as for code size, libsnmp.a
> from ucd-snmp is about the same size (1300K) as libomniORB3.a from
Code size is really not an issue. It is the amount of network traffic
that is generated by either of the responses.
Quote:> But, I suppose, one place where SNMP wins would be in sending a TRAP.
> CORBA would require setting up a TCP connection first.
My other reason for making that statement if purely from network element
support point of view. The same reason why CMIP is not very
popular compared to SNMP.
Every network element would have a SNMP agent running by default.