| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 766.1 | Yes, it's about time we got around to doing that | TOOK::GUERTIN | E = mcc | Fri Mar 01 1991 16:41 | 12 |
| Wally,
Sounds like a great idea, but you might get a lot more bang for the
buck if you make it an FM. That way you can call any AM, or any other
FM (and it does sound like added value functionality). I believe that
Alarms and Historian can function on any other FM as well as any AM, so
you are covered there as well. If it is an AM, you cannot call the
DECnet AM, so you will end up cutting and pasting a lot of code (I
think). Anyway, it sounds great (as for names, I like Wire AM better).
Would it be possible to provide statistics for the "wire" as well?
-Matt.
|
| 766.2 | It's like deja vu all over again... | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Mon Mar 04 1991 09:53 | 22 |
| RE: Yes, it's about time we got around to doing that
The last time I checked, AMs could call other AMs (I believe TSAM uses this
feature now). Has this changed?
AMs cannot call FMs, which means you could probably get alot more mileage
out of making it an FM anyway because...
RE: STATISTICS.
In the early days of prototyping an LTM AM, it was suggested that relating
an Ethernet Segment to statistics derivable by a LTM-Listener would be
"really nice".
Since Ethernet (and FDDI) Bridges can also provide counters from which Line
Utilization can be calculated (by PA, of course), and since it would also be
nice to relate this information to a segment ("turn segment RED when Utilization
goes above 50%"), it sounds like making an FM to do this stuff would be a big
win...
Chris
|
| 766.3 | Easy set ups | MAYDAY::ANDRADE | The sentinel (.)(.) | Mon Mar 04 1991 10:07 | 20 |
| Another yes,
I mean DECmcc was created to replace older point products. And this is
a major delivery of these networking point products such as ENOP, NMCC/DM,
NMCC/Ethernim, etc.
The network connectivity summary status at a glance in a map, with
further details only a a couple of key srokes away. Together with
historical connectivity and traffic network reports.
*** A requirement I would like to add is ease of set up, both of the
MAP part and the underlying database. As automatic as resources allow.
Possibly this could be done with a question/answer menu like routine.
With the users entering data like: I want to monitor the A,B, and C
(router) nodes and all the WAN lines that connect them (using alarms),
etc... Then MCC would do the rest, applying all related defaults.
With any user desired modifications (later on) being just as easy.
Gil
|
| 766.4 | | SCRPIO::LIZBICKI | | Mon Mar 04 1991 11:15 | 8 |
|
re: .2
Chris is correct, an AM can call another AM. The Terminal Server
AM calls the DNA4_AM to configure the DECnet database for down-line
loading and up-line dumping of terminal servers.
Lynne
|
| 766.5 | Circuits & Services | TENERE::DENIS | a DEC CME SuperCopter | Mon Mar 04 1991 11:24 | 18 |
|
Wally,
For Public Network Management, we see this as an important requirement:
users are sometimes more interested by LINES/CIRCUITS than by NODES.
I'd put a VERY HIGH PRIORITY for this capability.
A requirement I'd like to add is the possibility to define and manage
"SERVICES" (ala Telecom Services) based on such Circuits/Wires/...
i.e. for us to be able to write a management module that could call your
Circuit AM, for mapping purposes between "physical/logical" entities and
"abstract/service" entities.
michel
|
| 766.6 | Hold the Phone. Isn't this Topology? | TOOK::GUERTIN | E = mcc | Mon Mar 04 1991 13:17 | 13 |
| RE:.2,.4
Oops. Okay, an AM can call another AM. I'm glad. I think we
still agree that it would be better to make it an FM.
RE:.3,.5
Isn't it starting to sound like Topology? Am I mistaken, or isn't
Topology supposed to manage the "Connectivity Entities"? (That is to
say, those Relationship Entities associated with the Connectivity of
Entities in the network.)
-Matt.
|
| 766.7 | What is OSI/NMF "circuit" definition? | ANDRIS::putnins | Hands across the Baltics | Mon Mar 04 1991 14:23 | 4 |
| What is the OSI/NMF definition of "circuit", and will your envisioned
module stictly comform? If your module implements a subset, that's
fine, but I suggest that DECmcc should avoid imposing any sort of
DECnet semantics upon the class structure or terminology.
|
| 766.8 | Circuit AM vs Topology FM vs Map associations | TOOK::MATTHEWS | | Mon Mar 04 1991 14:48 | 73 |
| Looks like I got a winna here. There is a lot of overlap in the
"circuit" AM and the "Topology" FM. I am pursuing both in parallel
at this point. There is a place for both. The following is my intuition
so don't throw bricks toooo hard.
There are relationships which are well defined and can be enrolled
in a "generic FM" that we have been calling the topology FM. There
are other relationships that are less well defined which require
circuit specific (ie. hard coded ) implementations. The former
kinds of relationships lend themselves to implementation via a
topology fm. The later lend themselves to implementation via
specific AMs/FMs. We need to establish precedents for each of these
and show customers and third parties how to implement them and
enroll them similar to what we are teaching them about AMs today.
Further, there are lines on our iconic maps. Sometimes, a line
corresponds to a circuit. Sometimes, it corresponds to a more
abstract relationship. When the line terminates in two DNA4 icons,
one can presume that it is a DECnet circuit. When the line spans
multiple DNA4, DNA5, TCP, Bridge, and Ethernet Station icons, one
can presume that it is an Ethernet that it represents. However,
when a line terminates in 2 domains what does it represent. One
can say a circuit. In such a case is it a single circuit or is
is all the circuits which terminate in nodes in the termination
domains. For BBNs case it may very well be the latter. They would
like to use domains as geographic domains to segment a mesh network
into a European, North American, and Pacific theater of operations.
There may be many circuits between each theater of operations which
may terminate in different packet switches for redundancy reasons.
Thus at the world global level, there may be 3 domains with 3 lines
between the domains. However, each of these lines represents the
set of circuits which terminate in the same domains.
The point I am trying to make is that the lines on the map are not
as simple as we think. They represent abstract relationships known
by the person who first composes the map. In some cases the map
designer may work intuitively and not have well defined meanings
for the lines. We need a way to allow free form expression for some
lines and well defined expression for others.
Our current implementation fulfills the free form expression but
the requirements from customers and third parties lead us to a more
regimented view. We want to make the transition without loosing what
we have gained.
My intuition tells me that there are simple associations that we
can make between the iconic map and alarms which do not require
a formal topology model of circuit. We want to provide that so
that alarms can change the display of certain lines. I think
that mechanism is needed even if we had a well defined topology
FM because there are will be alarms that are not easily associated
with an existing relationship/entity.
There is also another simple association between a line on the map
and the values of a particular attribute's value whether that attribute
is a statistics attribute or a primitive attribute. In a similar way
I think that we want to allow this well after the existence of a well
defined topology FM.
The topology FM on the other hand, should be generic and support
enrollable topology relationships. When a topology relationship
is too specific to be generic, I believe a specific AM or FM needs
to be implemented.
The "Circuit AM" in my mind establishes the "Sample" precedent for
this last case. Various third parties can use it to build specific
relationships with well defined display properties integrated
into the Map and FCL.
The "Topology FM" is a longer lead time item that hopefully will
provide the generic relationship support.
wally
|
| 766.9 | general comments | JETSAM::WOODCOCK | | Mon Mar 04 1991 18:01 | 92 |
| Hi Wally,
I'll have to agree with you in your thoughts that lines on the map don't
always conform to specific rules. Unfortunately I have a pretty narrow
view of things (DECnet) but I can give you some examples of what I'd
think would be useful for our specific environment.
First, I would hope this module is of the generic form, able to handle
interfacing with multiple protocols (ie AMs). This is very important
given the integration activities of all companies.
> 1.) Associate an alarm rule with a line drawn on the iconic map
- What I would find VERY useful is if there is an association
between a global entity alarm and the wires attached. If the
global entity fails (firing alarm) logically so do all the wires.
This would highlight the entity and all wires. Maybe multiple
target entities is what I'm looking for here if these wires
can be declared as such. This would give the full impact of the
situation graphically without touching the mouse.
- If the above method isn't available, some users may want to
associate multiple alarms to a single wire. For example, if
events are being used for notification both ends of the circuit
may be set up to sink. In the event that one node goes down
(which obviously won't send an event) the other side will send
the event and result in notification. Or vice versa thus
providing redundancy. If this method is used it would be handy
to associate the alarm "data" to a wire. This keeps wildcards
and the number of rules down to a managable level. For example:
expression=(occurs(node4 <node> cir syn-* circuit down))
A particular wire can't be associated to this expression until
the alarm is fired and the "data" within it is examined to
determine exactly which circuit is having the problem. Just a
thought.
> 2.) When the associated alarm rule fires, turn the line the appropriate
> color.
- This wire may reside in multiple domains. Notification should be
in all domains it resides. Or if this isn't feasible, notify up
to the composite circuit in a higher domain (preferred).
> 3.) When the associated alarm conditions have gone away, return the line
> to the appropriate color.
- Or to a different color. This lets the user know that this wire
had a problem but now it's ok.
> 4.) Associate lines drawn on the iconic map with "circuit" entities
> and treat the line as an icon for a circuit instance. The definition
> of a circuit in this context is that of an OSI/NMF Circuit object
> as defined in the NMF library of objects. I am using this as
> a conceptual definition and not implying full NMF circuit
> implementation.
> 5.) Associate lines drawn between domains on the iconic map as composite
> "circuits".
> 6.) Double click on "simple circuits" and show their reference attributes.
> 7.) Double click on "composite circuits" and show their component "simple
> circuits".
- A wire which has been picked should also be able to produce graphic
statistics (error, utilization, etc). It would also be nice if
management fuctions were available (shows & sets at least) from this
point. All this from the composite circuit (ie. double click composite
circuit, pick simple circuit, show statistics or attributes).
- Composite circuits (using your definition) should be used as the
hierarchy of notification for its simple circuits. For example,
if a user has a circuit within a domain which gets notification, MCC
should check the next domain level up for a composite circuit
which contains the simple circuit. If it exists notify the composite
line, if it doesn't notify the domain which simple circuit resides,
not BOTH. This gives a better sense of the actual failures for those
using composite circuits between domains.
> 8.) Possibly associate a line drawn on the iconic map with an attribute
> of an entity and select the salient color for the line based upon
> the current value of the attribute.
- This sounds as if it would work well when using a polling mechanism
for alarm detection. You'll need to take into account that the
attribute in question may have "several" states.
looking forward to this one,
brad...
|
| 766.10 | Beyond DECnet/OSI... | SMAUG::WINKLER | | Thu Mar 07 1991 09:44 | 5 |
| Wally,
What are the implications of basing it on the OSI/NMF Circuit object
definition? I know that this is a strong requirement for SNA
management as well, and hope it will be general enough to apply!
|
| 766.11 | Need it, ASAP | ISIDRO::BURGOS | Luis Burgos. TIMG Spain. | Fri Mar 08 1991 09:32 | 25 |
| Wally,
I mostly agree with your view of the Line/Wire Module. A drawing line
can represent many types of links, and you should be able to zoom in it
several levels as with the domains. And many people are more interested
with the lines that with the nodes. But I also think it should be a FM
instead of an AM, since you should be able to change colors automaticly
acording to expecific rules (percentage of use, errors, etc...) and
been able to use it with different AM. So independently of how it's
done it really performs Function type of things rather than an Access
type of things.
I am looking for that specific funtionality to sell EMA to manage our
national X.25 network (several hundreds of switches), and if we wait for
the Topology FM it's going to be too late. And I don't see why the
Topology FM couldn't use the Line/Wire FM to do his job if he need it.
Well, actually I need something else, been able to show the result on
diferent distributed systems, according to the domains defined on each
system. But if I have it soon I can guaranteed a BIG sale. (To give you
an idea they just spent several million dollars buying a 9210 and over
one hundred 3100 just to monitor the state of some of the switches with
an aplication made to them).
Regards
|
| 766.12 | I don't want to see duplicate effort and redundant work :-) | TOOK::GUERTIN | I want my MCC | Fri Mar 08 1991 10:10 | 51 |
| RE: .8 & .11
Please, please, check with the Topology folks first. Without a
Topology Concepts paper or design document, it is virtually impossible
to determine if there is any overlap. I can only go on the ideas which
were tossed around a couple of years ago. The Topology-FM should be
able to support simple topologies by being data-driven off of the MCC
Dictionary (MM writers would put in topology specific information in
there .MS files for the Topology-FM). However, if the topological
relations were complex, the Topology-FM could call the MM through the
call interface and have the MM provide the information with a special
verb (I forgot what the verb was). (In fact, why not *always* call the
MM, even for simple topologies, and let the MM call common routines?
Well,...) Okay, so some complex topologies may involve multiple global
entity classes. My intuition tells me that hardcoding these into
special MMs is NOT the answer. It would be better for the Topology-FM
to support user defined relationship rules which can incorporate
multiple entity classes, much the way the Alarms-FM supports
user-defined rules which they are data-driven off of.
Having a graphical line connecting two domains simply means that the
two domains are connected in some way. If I as a user suddenly saw
that "line" turn red, frankly, I wouldn't know what to make of it. I
could only guess that there must be some communication problem between
the two domains. The user should be able to "click" on that graphical
line and find out what the problem is.
**********************************************************************
That model, the one of two or more objects on the map being connected,
and the connection meaning something other than just a graphical line
drawn by decwindows (in other words, the line itself is an object /
icon), should be the fundamental model of topology.
**********************************************************************
How that connection is represented depends on what the relationship is
that binds the entites. That is to say, different relationships should
have different graphical representations (icons). For example,
ethernet connections look different than multipoint connections.
Furthermore, you should be able to connect connections (connections can
be made up of other connections). For example, one might model a
DECnet Line as an object which connects DECnet Nodes to Wires. Wires
connect Lines to other Lines. Each Connection Object can be clicked
on, and can have Alarm rules on them. (Is this a pipe dream?) This
functionality would cost LESS to implement in the long run, since it
is a more extensible solution.
Am I making any sense? I'm more concerned with redundant effort
than with the concept itself (which is much needed).
-Matt.
|
| 766.13 | Thanks for tossing around those "old ideas"
Thanks for tossing around those old ideas...
| DFLAT::PLOUFFE | Jerry | Mon Mar 11 1991 16:22 | 33 |
| RE: -.1
Wally, I know you've seen this stuff before, but just in case you forgot,
please reference notes 10.* in the MCC_FUTURES notes file.
There are four notes there that capture all the initial research done on
"Relationships". This work might be valuable for what you are doing. In
fact, this work might be very valuable to the Topology FM also.
I completely agree with Matt's comments:
"My intuition tells me that hardcoding these into
special MMs is NOT the answer. It would be better for the Topology-FM
to support user defined relationship rules which can incorporate
multiple entity classes, much the way the Alarms-FM supports
user-defined rules which they are data-driven off of."
Also:
> Each Connection Object can be clicked on, and can have Alarm rules on them.
> (Is this a pipe dream?)
Absolutely true. This is not a pipe dream. Alarms v1.1 has proved that we
can have notification color changes applied to objects on the map. It makes
no difference that the object is a "Connection" object or a "Connected"
object.
With Relationships we will also be able to relate alarms rules (not just
the alarms that result from the alarm rules) w/ any object. With this
capability, the user can ask for a list of alarm rules that are associated
with a node, with a line, with a wire, with a domain, with ... anything.
- Jerry
|
| 766.14 | more fuel for the fire | TOOK::MATTHEWS | | Tue Mar 12 1991 11:07 | 51 |
| The alarm which monitors the rate of entry for replies to this note
just kicked off again. It seems that the reply rate is dropping so
I am going to kick start it again.
First, the NMF circuit definition. It is my intent to try to implement
the NMF Circuit attributes as is. However, to implement them in DECmcc
I have to make adjustments to the datatypes as defined in NMF 006
(Object definition library to those who have trouble remembering
what set of numbers go with what). I have to MCCize the datatypes.
If MCC shows some of its DECnet heritage, that is a price that must
be paid to support OSI. I have no control over the fact that MCC uses
fullnames rather than namingstrings. Personally, Namingstrings as
defined by NMF are loosely defined so that they can be exchanged
between multiple vendors. I also will use the MCC datatypes for
full entity class and full entity name in a record for A endpoint
name and Z endpoint name. It may alienate some NMF purists but it
is the price of doing business in MCC and it is more concise than
the namingstrings.
I am trying to OSIize DECmcc where-ever possible. The model of
NMF circuits is the DECmcc internal model and does not compromise
the model we present to the outside world. I will not slavishly
follow the NMF object models because in many cases they are imprecise
and/or ambiguously defined. I will use them as a guide and use
cautious judgement on where I choose to extend them or make changes.
The intent is to use DECmcc for future NMF showcases as it has already
been used at Comnet.
I would like to put the Topology vs Circuit AM discussion behind us.
I am the development manager of both as of a week ago. I am acutely
aware of the overlap of the 2 projects. It is my intent that the
circuit am work leads right into the topology FM work. I am also
working with Butch McKinney who is developing an auto-configuration
tool which supports auto-topology. I am managing the project that
has been called the Topology FM. I am NOT managing Butch's project.
The marketplace has an expectation around Topology. That is an
expectation shared by many projects in DECmcc. I am specifically
responsible for the relationship piece that Matt and Jerry so
eloquently described. My views are similar to theirs but are tempered
with the reality that it will be delivered over many release cycles.
The objective of the Circuit AM is to do the first increment of work
in MCC V1.2 and use it as examples of how third party developers
and internal developers can implement Specific relationships in
parallel with the more generic Topology FM.
Yes, there will be concepts papers, etc. That will be done in parallel
with the circuit AM project so as not to compromise the ability
to deliver the first increment of functionality for V1.2.
wally
|
| 766.15 | keep it alive | NAC::ENGLAND | | Tue Mar 19 1991 14:10 | 27 |
| Don't let it die! There is an abstract model of topology that covers
these cases, it was discussed 2-3 years ago, it has practical
applications. It does need support from the user interface and
framework. Now that you have relational DBMSes available for this
stuff, it should be MUCH easier to do than it was then. One real
application of topology is NAVIGATION within the user interface, as was
suggested back then. Another application of topology was to be fault
diagnosis, because topology-driven fault diagnosis would greatly
improve the ability of the diagnostic FM or whatever it is to isolate
the problem to a node or wire. All the AI attempts to do fault
diagnosis fail with networks unless they take into account the network
topology.
I always wanted to do a map interface to a fault diagnostician that
would show the FM picking new tests to isolate the problem, coloring
the test path, drawing a boundary around the suspected problem area,
homing in on the problem until it picked a specific entity or entity
interface. This would be a product that would excite the customer, I'd
guarantee you. You couldn't sign them up fast enough for MCC if you got
this far. I did a very primitive prototype of the fault isolation
algorithms in LISP 5-6 years ago, let me know if there's anything I can
do to help, but that's not the hard part anyway.
Good luck,
ben
|