|
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
|
| 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
|
|
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.
|