Subject: Test ServiceState in Termination State Descriptor

From: Hemant Agrawal <[email-masked]>
Date: Mon, 17 Apr 2000 16:28:46 +0530

Hi All,
        I have few questions related to serviceState in
terminationStatedDescriptor.
TerminationStateDescriptor has three values for serviceState : In Service,
Out Of Service and Test.
The draft mentions "The state "test" indicates that the termination is being
tested" (sec 7.1.5 para 2).

How is "test" state different from "in service"? Is their any special action
to be taken by MG, when it receives a termination state to be set as test.

Does it mean that if the said termination supports test packages, the events
, signals etc pertaining to these can be applied only in test state. Also in
that case what happens to the non "test" package events and signals. Are
they stopped by the MG on getting service state property as "test" and vice
versa.

I think this differentiation between what constitutes test and what not
should not be done at MG level. But in that case how from an MG point of
view, are the service states "test" and "in service" different ?

Another question in this regards. Should the MG "prefer" allocating  "in
service" terminations over terminations with service state "test" while
resolving CHOOSE in Add.

Thanks in advance,
Hemant Agrawal

________________________________________
Hemant Agrawal
Ficon Technology
E-mail: [email-masked]
Web: http://www.ficon-tech.com

---

From: Michael Brown <[email-masked]>
Date: Mon, 17 Apr 2000 19:01:34 -0400

The test state is different from "in service" in that a termination can be "in
service", "OOS", "in service - test" or "OOS - test". I would say that there are
no specific actions which would be applied simply by placing the line in the
test state.

In my opinion, it would be something of a flag to indicate that the signals and
events associated with test package could be applied to a termination. The
behavior associated with those signals and events would be defined as part of
the package and may be different depending on whether the termination is  IS or
OOS.  I would think that the intelligence to determine whether or not to apply a
particular signal or event would be under the control of the MGC or a
maintenance interface, but it might be desirable for an implementation in the MG
to do some minimal defensive coding to prevent MGC or maintenance request
"mistakes".

I do agree that the intelligence for handling the test state should be driven by
the MGC and actions taken in the MG implemented in packages. One of the reasons
I believe that the test state is needed is to have this knowledge available
associated with the termination in the event of the MG performing a failover to
a secondary MGC. The MGC could determine those terminations which were under
test using audit mechanisms and could then take action accordingly.

Regarding your last question, I would say that the MG would behave no
differently in allocating a termination on a CHOOSE when it is IS-test or IS.
The point is that the termination should be used as IS except that specified
test functions will be performed (under MGC control) during normal use.

I am currently in process of working with Nortel development groups on producing
a test package for line test functions. This will be coming out in the near
future and I think it will help to further clarify my comments.

Michael Brown