[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

974.0. "Line Domains" by ZPOVC::ANDREWWAITES (Singapore - Asia's Wellington) Wed May 01 1991 08:52

    Hi,                                       
    
    	I have had a quick look at anything mentioning lines and seen no
    joy so I hope this hasn't been asked before. (The all new, polite
    Andrew crawls out of the coccoon)
    
    	WE are setting up a monitoring environment for both a data centre
    and a network (local and WAN). The network people came to us on Friday
    and declared that they want their own VCS system as well as DECmcc (the
    data centre have a VCS). What they would like is to have VCS monitor
    their comms consoles (Telnet, CASE, etc) and work out if the line has
    gone down from the console message (very UN-architectural but it still
    works). It would be REALLY nice if we could then get VCS to tell DECmcc
    that the line is down AND have MCC alarms this event. (Yes, VCS can
    alarm it but they want their pretty network picture to be updated.)
    
    	I think we could get an alarm to fire if we had something to alarm
    but to-date MCC believes that lines are not living beings on a network.
    Now this is probably true according to our architecture which would
    have each of the network comms devices have an AM, etc but in truth it
    would be nice to just say that the line is sort of a domain of its own
    (with modems, encryptors, CASE/Telnet boxes etc) and declaring the line
    domain as down if any point in it fails then we could explode the line
    to see which point has failed.
    
    	So, ideally the line domain would look like a line on the map but
    be able to change colour but failing that (and now that isn't a goer)
    we could make do with a psuedo-domain sitting on theline between
    Singapore and HK which was in fact the line. Problem is that I can't
    think of any psueudo-entities to use for our network elements. Nodes
    have to exist to register them, maybe I can use something else but it
    would be nice if tehre was just a pseudo class of entities which we
    could alarm with non-AM mechanisms.
    
    	I guess I just threw this in for general comment and to try to
    regain some credability.
    
    thanks,
    Andrew
T.RTitleUserPersonal
Name
DateLines
974.1TOOK::F_MESSINGERWed May 01 1991 10:5327
Andrew,

For 1.2 it will be much easier to do this than what I am about to describe.

Claudia Peters showed me a marvelous "workaround to current functiality limitations".
She created a very long and skinny icon that looked like a line.  I think she had
one that was vertically oriented and one horizontaly oriented.  And I think her line 
icons were aliased domain icons.  Is this true Claudia?   Anyway, she had a map
with  node4 icons abutting line icons so that it looked like the node4s were 
connected by regular lines.  If the domain represented by one of the long skinny
lines was alarmed, it reflect the alarmed state.

Couple minor limitations with this:  

  You can't drag the lines or the entites on either end of the line and have
  the connections maintained.

  Things would look kind of strange if the line icons were diagonal.


But overall it looked sharp and, as I said, it will be easier and "act nicer" for
V 1.2.

 ...Ah, the resourcefullness of the human mind!  Good show Claudia!

Fred    
974.2what about the new v1.2 circuit am and LDOsTOOK::MATTHEWSWed May 01 1991 17:09105
Before I get specific about plans I need to establish terminology.
There are lines on an iconic map which may or may not represent
communications lines, link, wires, circuits, connections, paths, and/or
sessions. The lines on an iconic map are distinctly different objects
than the various objects that they may represent in the same way that
an icon is a different object than the entity that it represents.

Lines on a map are for the purpose of this discussion a line display
object (ie. LDO). A circuit on the other hand is a generic data pipe.
You put data in one end and it comes out the other. It may be bi-directional
or uni-directional. The circuit model is that of OSI/NMF and is a
very general model. It can be used to model wires, links, channels,
connections, paths, sessions, or whatever is desired. Because of its
need to be general, it is limited to what is common for all of these.

Our plans are in 2 parts. The first is general support and use of
LDOs. The second is an AM for circuits so that we can model all of
the various things we use LDOs to represent.

I. LDO support/use

The V1.1 LDO is a visual reminder that some association exists but
it can not be used as an icon alias for an entity nor can it be
a target of display for alarm/event notification. For V1.2, we
need to support the current LDO useage as well as allow an LDO
to become a target of display for alarm/event notification and
to allow it to be an icon alias for an entity. 

An LDO will become a managed object in V1.2. It will have a class
of LDO and it may have a name. If it has no name, it can be 
displayed but can not be an icon alias or a target of notification.
If you name it, it can become a target of notification and the
alarm rules will be extended to define a target entity for an
alarm of which a named LDO instance is one of the possibilities.
Alarm notification via an LDO follows the same functions as
notification via an icon. The use of color, the number of
colors in the notification scheme, etc. is consistent with
that for icons. In other words there are no special cases for
LDOs which do not apply for icons and vice versa.

You may also associate an LDO at creation time with any other specific
entity instance (including domains, global entities, or child entities).
If the association exists, the iconic map will treat the LDO as
an alias icon for the entity. In some special cases (ie. a circuit
entity), the LDO is the only icon for that entity class. For others
such as domains, it is an alias and either or both may appear in
the same map.

If you select an LDO which is associated with an entity you get the
same result you would be selecting an icon for that entity. If you
double click an LDO, it is equivalent to double clicking the icon
for the associated entity. If the associated entity is a domain, you
are presented with the map of that domain. If it is a global entity
you are presented with the selection list of child entity classes. If
it is a child entity, you are presented with the selection list of
its child entities.

Now lets see how we can use this. I have a link between 2 end points
(ie. nodes). I draw 2 LDOs which intersect at the half way point
between the node's icons. I can associate the left (or upper) LDO
with the left node's (or upper node's) line child entity that connects
to the right node (or lower node). I can do the converse for the
right node. Now I can target alarms from the left node to the left
half LDO and I can target alarms from the right node to the right
half LDO. If I select the left half LDO, I can select an operation
for the line child entity. I can even navigate to the appropriate
child entity by selecting the appropriate LDO.

A second example is T1 Mux networks over which both Data circuits
and voice circuits are routed. I am managing the data network and
the T1Mux network. I construct a domain map for my data circuit
which has multiple DSO circuits each of which is represented as
an LDO between adjacent nodes (ie. routers) in my data network.
I construct a second domain map for the T1Mux network and include
the DS1 link. In the first domain, I can associate the LDO that
represents the DS0 circuits to the second domain. Thus if I
double click a DS0 circuit, I am presented with a detailed map
of the T1Mux domain. Also if an alarm in the T1Mux domain occurs
it will be displayed on all DS0 circuits which are associated
with that domain.

For a third example, I would like to model the physical connection
between 2 routers as a circuit entity. I associate the LDO with
a circuit instance. When I select the LDO I am presented with
operations that apply to circuits. When I double click the LDO
I am presented with the selection list of the children of the
circuit (ie. the list of component circuits if there are any).

II. Circuit Entities

DECmcc will focus on the OSI/NMF definition of circuit for V1.2. Additional
extensions are in reality definition of specializations of the 
circuit superclass to a variety of more specific subclasses. Only
attributes and child entities which are appropriate for the superclass
will be implemented during this release. Future releases of the Circuit
AM will provide an extension (aka inheritance) mechanism that allows
users to define specialized circuits for which the circuit am will
provide the base functionality. 

As pointed out earlier, many physical components (ie. wires, cables)
and logical relationships (links, connections, sessions, channels, etc.)
can use the circuit as a model and use the LDO as a representation.

wally matthews

974.3is this possibleJETSAM::WOODCOCKWed May 01 1991 20:1920
Hi Wally,

I'm a bit fuzzy on what kind of alarm reactions we'll get with v1.2.
Say I have a domain containing two domains. These two domains are connected
using either one or two LDOs as described in the previous note. If I click
into either one of these domains the topology is broken out into nodes. 
Therefore I have two nodes in the lower domain also connected by an LDO.
Both LDOs actually describe the same entity. You mentioned that an LDO can
have a relationship to another. If an alarm is fired on this entity I
would want the LDO in both domains to change. Possible? Also, what is the
relationship of the LDO in the lower domain with the domain it is in? When
the alarm fires will the domain which includes the lower LDO also change?
This would be an undesired effect. What I would find ideal is that the LDO
in both the upper and lower domains change color but the domains themselves
do NOT change color. The domain would change color for only global entity
problems. Will there be a way of defining these reactions?? 

thanks,
brad...

974.4TOOK::F_MESSINGERThu May 02 1991 09:4335
Brad,

I'm a bit fuzzy on what kind of alarm reactions we'll get with v1.2.
Say I have a domain containing two domains. These two domains are connected
using either one or two LDOs as described in the previous note.

>>I will reread Wally's note, but I did not see where he said we can have
>>multiple connections between icons. If he did, we'll iron it out but
>>to date (and I suspect for v1.2) we  will not have multiple
>>connections between icons.  It is needed, though.  

 If I click
into either one of these domains the topology is broken out into nodes. 
Therefore I have two nodes in the lower domain also connected by an LDO.
Both LDOs actually describe the same entity. You mentioned that an LDO can
have a relationship to another.

>> An LDO has a relationship only with one(currently) other non-LDO entity.

If an alarm is fired on this entity I
would want the LDO in both domains to change. Possible?

>>Yes

Also, what is the
relationship of the LDO in the lower domain with the domain it is in? When
the alarm fires will the domain which includes the lower LDO also change?
This would be an undesired effect. What I would find ideal is that the LDO
in both the upper and lower domains change color but the domains themselves
do NOT change color. The domain would change color for only global entity
problems. Will there be a way of defining these reactions?? 

>>It is possible to allow the user, by way of the customize file, to provide
>>input into the algorithms we user to alarm icons and LDOs.