| You might wonder what the big delay with LTM is all about... It may be
related to LTM sales (the figures were disappointingly low when the
product first came out, because the field was giving it away (minimum
LTM price was around $15K for DEBET + s/w) or using it to sell
services, or it could be that the first release didn't have a real
sexy user interface, except for those VT240 histograms (remember the
VT240, anyone? I thought not...). I'm not sure because I haven't
worked on LTM in 3 years.
Some of the LTM functionality could be done quite well with MCC today,
such as management of LTM itself. Perhaps MCC has advanced far
enough that some of the previous problems have gone away, I'll be
interested to see where we stand with it, but 2 1/2 years ago there
appeared to be some technical obstacles to its integration with MCC.
LTM (formerly 911 monitor) is very different from some of the other
LAN management products such as RBMS and TSM, in the following
respects:
- LTM measures traffic for the entire (physical) Ethernet, not just one
entity.
- It's possible to have a bridge switch between LTM_mode and bridging
mode (polymorphism), it could be confusing to both MCC and the end
user if MCC doesn't have support for polymorphic global entities.
- LTM outputs a tremendous volume of data (up to 3000 bytes / second),
thereby straining the throughput and buffering capacity of the
database, CPU (if data reduction performed) and end-user, if
he/she is forced to look at all of this data.
- It's hard to understand what the entity model for LTM might be.
an LTM monitor can be thought of as an intelligent ethernet cable.
Thus you might want to think of this device as part of a "wire"
entity. The traffic matrix would be counter data associated with
relationships between nodes on that wire entity. But wire entities
were not that well accepted, because there were some very real
problems with them:
- they have no address
- they don't respond to directives (although LTM does)
- the "wire" looks different at each layer of the network,
- You can have multiple monitors logging to the same host
(i.e. one for each ethernet in the extended LAN). This could
potentially create quite a load on the host, without judicious
load limiting.
- The data arrives at such a high rate that the existing RMS-based
MIR routines might not be able to log it all. However, this may be
a non-issue, LTM-Reports was able to log data at a reduced sampling
rate (about 1/10th the rate that the monitor supports, if I'm not
mistaken).
- the LTM protocol uses both synchronous and asynchronous/multicast
methods of transmitting data from the monitor to the host.
While the asynchrony could be hidden from the MCC PM by an
access module, the best use of the data would require some form
of event mechanism to notify the data reduction FM(?).
- the data does not easily conform to a strictly hierarchical model.
For example, much of the data is accessible via 2-dimensional tables
(such as traffic matrices), of very large size. These tables
might not easily fit into the existing callable interface.
They could be divided up in some arbitrary way, but the fact remains
that the ILV interface was not optimized for passing thousands of
array elements across an interface (unless the entire array is passed
as a single ILV value, creating the need for an "array" data type.
Hence there was a strong temptation to avoid passing this data around
MCC at all, by pushing data reduction functions into the access module,
but this violates the layering of MCC, which implies that such
functions should occur at the FM layer. At least the FM ought
to be on the same node as the AM, so that the minimum amount of
LTM data gets passed across system boundaries.
For all these problems, LTM is exactly the kind of application that
would really break MCC out of the pack, now that graphics interfaces
and generic APIs are less of a differentiating factor for the
product.
LTM would be very powerful if coupled with MCC alarms and MCC
DECwindows PM, which would provide a very useful tool for navigating
the vast amount of LAN monitoring data.
|
| Ben, your analysis is pretty accurate for someone who has been away
from MCC for so long. Some of the problems that you mention have been
solved, others can be worked around fairly easily, and still others are
probably part of the reason that there is no LTM AM in MCC. I've put in
a bit of thought to the subject of LTM and MCC; you may want to contact me
offline if you're interested in pursuing this subject.
FWIW: You will be able to get some of the statistics that LTM provided
via the Bridge AM (using a LB200) and the Performance Analyzer FM in DECmcc
V1.1. Utilization, via the LB200's byte counters will help fill the gap,
but it's still not even close to the total of what LTM provides.
Wayne
|