Subject: Re: Test ServiceState in Termination State Descriptor]

From: Hemant Agrawal <[email-masked]>
Date: Tue, 18 Apr 2000 18:58:50 +0530

Hi Brown, list,

 My comments are inserted inline with HA>

> The test state is different from "in service" in that a termination can be
"in
> service", "OOS", "in service - test" or "OOS - test".
>

HA>  In TerminationStateDescriptor, ServiceState has only three valid
states, IS, OOS and Test. There is no state as "IS-TEST" or "OOS-TEST". The
state "test" is independent of the IS or OOS state.

> I would say that there are no specific actions which would be applied
simply by placing the line in the
> test state.
 HA> Agreed. (In fact that's what we have said)
>
> 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".
>
 HA> is it that when the termination is not in test state, then the MG
should  not allow test events and signals to be applied ? What happens to
the test  signals & events when a termination which is in test state moves
to a IS state -
 does the MG stop those signals and events ?

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

HA> Agreed

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

Regards,
Hemant Agrawal

>
> Hemant Agrawal wrote:
>
> > 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: Wed, 19 Apr 2000 10:58:47 -0400

Overall, was glad that mostly we are agreeing. Reading your reply I realized
that I didn't state a couple of my underlying assumptions which led to some
confusion.

In particular, the statement about IS, OOS, IS-TEST and OOS-TEST is misleading
without the assumptions. That is, of course, you are correct that there are 3
defined states. My assumption was that in defining a test package there would be
a property which would be used to indicate whether the line is IS or OOS as a
substate of TEST. So, that when the termination is placed in the TEST state, the
property would be set to reflect the underlying IS or OOS state of the
termination. The MGC and/or maintenance system would also have the knowledge of
this termination as either IS or OOS and would allow or disallow use of the
termination as appropriate.

I put one other comment inline with <MB>.

Mike

>  does the MG stop those signals and events ?

<MB> I would say that the answers to your questions would be yes and no
respectively, assuming that the transactions requesting these functions only
contained the command to do the requests specified. I would suggest, however,
that the scenario described suggests a somewhat confused or less than aware MGC
or maintenance craft person. In my opinion, this type of error checking should
be performed by the MGC or maintenance interface which is why I said that "it
might be desirable" to provide some defensive coding in the MG. I think that it
is not unreasonable to expect that the MG recognize the suggested operations as
errors and report them to the MGC as such but don't think it should be
required..