| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1936.1 | More Q's about Circuit AM | BAHTAT::BOND | | Fri Dec 13 1991 12:12 | 18 |
| At first sight, the Circuit Object seems to be a very useful way of
keeping track of multiple hops between nodes. As I read it, you could
define a circuit to be composed of a number of DECnet links and then
just watch the Circuit Object itself to see if anything goes wrong.
Perhaps I am reading too much into this? Can somebody illucidate?
For instance, the documentation indicates that the Circuit opState will
follow a combination of the component circuits' states. Does the
Circuit AM poll them or does it pick up events from the real entities
AMs? Does it just check that they are turned on ie state or does it
follow sub-state as suggested in .-1?
Finally, just a suggestion for the documentation. I think you need a
warning about changing the Admin State of a Circuit object. This seems
to involve actually setting the NODE4 LINE state to OFF for the DECnet
circuits involved (page 3-22). If this is the case, it should be
pointed out that if there is no other route to the Node(s) affected,
the re-setting of the adminState to Unlocked may be tricky :-)
|
| 1936.2 | We go with the standard | TOOK::MATTHEWS | | Fri Dec 13 1991 13:21 | 24 |
| To the original note. Brad, I understand your point, but Standards
are standards. Operational state values as are defined by NMF. They
did not ask our opinion (actually they did and we (ie. DEC) ignored
them). We are stuck with the state values as they defined them.
It is our intent to stick with the standard for V1.2. If, circuit
becomes very popular with DECies rather than just the TELCO types,
we may consider some DEC specific extensions in the future.
To .1. Yes, it is our intent in the future, to have a composite
circuit which is composed of any number of serial links. You can
then alarm on the composite circuit and let the circuit AM worry
about the details of the component circuits. There is a glitch
for V1.2. If you read the release notes, you will find that the
change of operational state event is not yet implemented.
So the answer, is yes and no. It will work if you set an alarm rule
which polls the composite circuit's operational state attribute
and fires the alarm when it goes to some state (ie. Disabled). It
will not work if your alarm rule is reception of an event that
signals NMF style "change of attribute" for the Operational state
attribute.
wally
|
| 1936.3 | ok, but down should = disabled | JETSAM::WOODCOCK | | Fri Dec 13 1991 14:15 | 23 |
| > To the original note. Brad, I understand your point, but Standards
> are standards. Operational state values as are defined by NMF. They
> did not ask our opinion (actually they did and we (ie. DEC) ignored
> them). We are stuck with the state values as they defined them.
Hi Wally,
I understand the rock/hard-place issue here. But maybe a 'slight' change
in your implementation will help with the data users understanding of
what is going on at a first glance. Disregarding the basic .0 suggestions,
how about if we go with what is in the DOCS. Enabled=Operational and that
is how it is today. But if the circuit is down it comes back 'busy'. From
a telephony standpoint this kind of makes sense because the circuit is
'unavailable' to the incoming caller, but it doesn't imply it's broken.
In the point to point world this circuit is NOT OPERATIONAL if any one of
the endpoints returns a value of the substate <> none. By the definitions
given in the DOCS 'not operational' would be DISABLED.
Therefore if all substates = NONE then nmfOperationState = Enabled, if any
endpoint returns substate <> NONE then nmfOperationState = Disabled. What
do you think??
brad...
|
| 1936.4 | here is the mapping table... | TOOK::JESURAJ | | Tue Dec 17 1991 10:50 | 74 |
| Sorry to take sometime to reposnd to this note. (I was away at DECUS.)
Following is the table containing the possible values (state,substate)
pairs for the DNA4 circuit entity and the corresponding mapping for
entity's operational state. We felt it is an appropraite mapping when
we did it (no mistake of key strokes !!).
State Substate nmfoperationalState
CLEARED NONE BUSY
OFF NONE DISABLED
ON RUNNING ENABLED
ON STARTING BUSY
ON SYNCH "
ON FAILED DISABLED
ON REFLECTING BUSY
ON LOADING BUSY
ON DUMPING BUSY
ON LOOPING BUSY
ON TRIGGERING BUSY
ON AUTOSERVICE BUSY
ON AUTOLOADING BUSY
ON AUTODUMPIN BUSY
ON AUTOTRIGGER BUSY
SERVICE IDLE BUSY
SERVICE REFELCTING BUSY
SERVICE LOADING BUSY
SERVICE DUMPING BUSY
SERVICE TRIGGERING BUSY
SERVICE LOOPING BUSY
As pointed out by the note .0, a lot of (state, substate) pairs have
been mapped into operational state of BUSY, indicating that the circuit
is not availble for the use of higher level applications.
If the mapping needs to be changed, please feel free to discuss the
necessary changes. Please tell us why it is more meaningful to the
users. We are very open to suggestions.
By the by, the Circuit AM does not see the (state, substate) pair at
all. All the mapping is done per end point basis at the DNA4 AM, and
the circuit Am receives the mapped status only. Therefore the mapping
suggested at the end of note .-1 is not possible.
Jesuraj
Circuit AM Project Leader
|
| 1936.5 | mapping for IP circuits | TOOK::JESURAJ | | Fri Dec 20 1991 11:45 | 27 |
|
Following the same logic in .-1, for the IP circuits we have
the following mappings:
IP status Opertaional state
UP ENABLED
DOWN DISABLED
TESTING BUSY
/ Jesuraj
|
| 1936.6 | RUNNING??? | LUVBOT::MCC | | Mon Dec 23 1991 11:16 | 39 |
| Hi,
Giving all the details of the mapping helps out. My feedback is completely
based from the definitions givin in the DOCS on pg. 3-16. They are:
ENABLED: Circuit is operational
DISABLED: Circuit is not operational
ACTIVE: Circuit is transmitting
BUSY: Circuit is transmitting but one end cannot communicate in one direction
These are the only values which I have opinions on and this is strictly from
the DNA4 perspective. The rest will do from my view.
ON RUNNING ENABLED
ON STARTING BUSY
ON SYNCH "
First is the "RUNNING" state. Does the DNA4_AM even return this value and
if it does what does it correspond to? T1.2.4 returns a substate of "NONE"
when the circuit is actually running. Therefore, ON and NONE would mean
nmfState=ENABLED. In addition, any circuit which is UP is also ACTIVE. So
ENABLED and ACTIVE are interchangeable in point to point data circuits with
ACTIVE being more properly descriptive but ENABLED pairs up with DISABLED
better as the opposite state. Take your pick.
Secondly, any circuit with a substate of STARTING or SYNCRONIZING is "DOWN"
(ie. NOT operational). Even if the other side of the circuit has a substate
of NONE this circuit is still DOWN and the packets are going to the bit bucket.
Therefore, both of these substates can be considered as nmfState of DISABLED.
As always opinions will vary but thanks for at least listening.
best regards,
brad...
|