| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Two questions on the V1.1 DECmcc Director product...
1) In a multi-domain, multi-director management environment, what protocol
do the directors use to communicate among themselves? Is it CMIP?
Is there an option to use SNMP?
CMIP?
MCC DIR #1 <-------------------------> MCC DIR #2
2)
a) How automated is the iconic map PM in V1.1? Does it require manual
edits for either:
o initial population of the map
or
o dynamic changes (e.g. a router crashing)
b) If manual edits/additions/deletions are required, are there any
plans for automating this whole process? (Auto-topology &
Auto-updates)
c) If automated, will the method of gathering data from entities be
mainly done via polling by the director or unsolicited updates from
the entities? I know this depends on the capabilities of the
entity to send unsolicited msgs so I guess I'm asking...
Which entities covered by today's AMs would support
the sending of unsolicited update msgs to the director?
Thanks, Stan
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 932.1 | Director to Director Protocol? Not yet. | TOOK::GUERTIN | I do this for a living -- really | Thu Apr 18 1991 13:07 | 36 |
RE:.0
I'm currently working on DECmcc V2.0 Distributed Directors. I'll try
to answer the first question. For DECmcc V1.2, directors do not know
about each other, and do not know how to talk to each other. This
isn't as bad as it sounds, because we use DNS as a network-wide
repository to share information between directors, so it "looks" as
though there is a lot of coordination going on, when there really isn't
much.
We are currently planning to use DECrpc (an implementation of OSF DCE-rpc)
to communicate between directors. (I believe that DECrpc will support the
OSI protocol for their V2.0 product.) For director specific information
exchange (kind of like introducing each other at a cocktail party), we
may end up using CMIP. However, I found that DNS (or some other global
nameserver) solves over 90% of information exchange problems because
you can just look up the information you need in DNS. The only time it
doesn't work is when the information you need is very dynamic (such as
needing to know whether a certain server (daemon) process is currently
running, or requesting some sort of statistic). In short, don't expect
CMIP to be used. And if it is used, it will probably be used very
little.
With DECrpc, we can select a preferred protocol for the rpc to run over.
I am currently planning to expose this to the end-user. This way the
end-user can state a preferred protocol for directors to talk to each
other. The software will be smart enough to figure out what protocol
to actually use by reading information out of the namespace (naturally,
it will try to use the preferred protocol first). TCP/IP is one of the
protocols which the user may select (other choices currently are OSI,
DECnet, and NCA).
Since this is mostly advanced development, expect it to change
significantly about a month from now.
-Matt.
| |||||
| 932.2 | Another bit of Current work | TOOK::KOHLS | Ruth Kohls | Thu Apr 18 1991 14:47 | 7 |
You might contact Kathrin Winkler (SMAUG::WINKLER) or Sally Martin (SMAUG::SMARTIN). They are developing an MM set that will do director-director communication (among other things) with SCI's Net/Master, and it is using CMIP or aiming that direction. Ruth | |||||
| 932.3 | RIPPLE::KOPEC_ST | Seattle DNT/Sales - DTN 545-4207 | Mon Apr 22 1991 21:38 | 3 | |
any thoughts on question 2 in .0?
Thx, Stan
| |||||
| 932.4 | Part 2, Stan. | TOOK::MCPHERSON | i'm only 5 foot one... | Mon Apr 22 1991 23:08 | 34 |
> 2)
> a) How automated is the iconic map PM in V1.1? Does it require manual
> edits for either:
> o initial population of the map
>
Yes.
> or
> o dynamic changes (e.g. a router crashing)
>
No. The icon will remain (although it may change color as a result of
an alarm rule & notification services). It will not spew forth a an
animated bitmap of smoking network bits. :-)
> b) If manual edits/additions/deletions are required, are there any
> plans for automating this whole process? (Auto-topology &
> Auto-updates)
Yes.
> c) If automated, will the method of gathering data from entities be
> mainly done via polling by the director or unsolicited updates from
> the entities? I know this depends on the capabilities of the
> entity to send unsolicited msgs so I guess I'm asking...
> Which entities covered by today's AMs would support
> the sending of unsolicited update msgs to the director?
The only AMs that *I* know of with getevent support _right now_ are
the DECnet AMs.
I'll leave it to more knowledgable folk to add further information (or
correct mine, of course. )
/doug
| |||||
| 932.5 | Dir-Dir, and Ker-ker | BSYBEE::EGOLF | John C. Egolf LKG2-2/T02 x226-7874 | Tue Apr 23 1991 11:54 | 23 |
Lets me try to add some info here... First of all, there is what we call "Director to Director" and also "Kernel to kernel" communication being planned for V2.0. Kernel to kernel will most likely use the RPC mechanism that Matt described. This will tie DECmcc systems together "logically" so that data can be passed and access modules on others systems can be used by other DECmcc directors. Director to Director will use CMIP and NMF. We are currently working on an OSI (CMIP) AM as well as plans for an OSI (CMIP) Agent PM. The AM allows us to manage any OSI entity. The PM allows us to be managed by any other OSI management system. The power of this is that non-OSI entities can be managed for an OSI management system. Stay tuned as the plans become firmer and papers are produced. In V1.2 we will have an auto-dection and auto-map capability. JCE | |||||