Subject: RE: [Megaco] Multiple factors affecting a termination's service s tate

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 22 Nov 2001 16:58:53 -0500

I'm assuming that in your example the MGC, in setting the termination
administratively OOS, has sent a ServiceChange request to the MG to do so.
It would seem reasonable that the MG should respect this request, even after
it has found and cleared a physical condition.  Thus there is no conflict.

On the other hand, suppose the sequence is different, so that the MG sends
the ServiceChange request rather than the MGC.  Here the MGC would be bound
to wait until the MG returned the termination to service.  Still no
conflict.

In the background, you have to assume that management systems are running to
ensure that out of service states are eventually cleared.  Megaco is there
just to ensure that call processing and termination availability are kept in
synch.

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Thursday, November 22, 2001 1:34 PM
To: [email-masked]
Subject: [Megaco] Multiple factors affecting a termination's service state

In some protocols, there is a concept of a primary service state
(in-service/out-of-service) and a secondary service state (basically the
reason why the entity is OOS).  The primary service state is IS only when
none of the secondary OOS states apply.  In Megaco, there seems to be only a
primary service state for terminations.  Suppose the MGC sets a termination
OOS for administrative reasons, and subsequently the MG discovers a physical
problem requiring that termination to be OOS.  If we had a secondary service
state, we could ensure that the termination stays OOS until the LAST of
these conditions clears.  Without it, it seems behaviour is
non-deterministic as the FIRST condition to clear will attempt to return to
service.  For example, if the MG discovers that the physical problem has
cleared, will it:
Tell the MGC the termination is going IS?  Will the MGC then have to issue a
new command overruling the MG? or 
Do nothing and wait for the MGC?  The MG can only make this decision if it
remembers there is an MGC OOS to wait for, i.e. it keeps a secondary state. 

In general, without a secondary state, either side wishing to change the
service state can override any previous history.
What is the correct way to handle such situations in Megaco? 
Raphael Tryster 

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 22 Nov 2001 16:58:53 -0500

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 25 Nov 2001 12:44:49 +0200

Tom,

I think what you are saying is:
1.	Both the MG and the MGC are required to maintain secret secondary
service states.
2.	An entity (MG or MGC) shall not send a ServiceChange changing the
state of a termination if that termination is currently OOS at the
initiative of the peer.

	Consider the following variations of sequences, based on these
rules:

	Case 1

	MGC sends ServiceChange placing termination administratively OOS.
	MG detects fault.  MG should not send ServiceChange
	MG clears fault.  MG should not send ServiceChange

	In order for the MG to suppress state changing, it must have
remembered that there were two reasons for OOS, and this implies a secret
secondary state.  Now, let's suppose an administrative action is performed
by management on the MGC to return the termination to service while the
physical condition still exists.
	 
	Case 2

	MGC sends ServiceChange placing termination administratively OOS.
	MG detects fault.  MG should not send ServiceChange.
	Management action at MGC wishes to return termination to service.
	MGC sends ServiceChange placing termination administratively IS.

	Here we have a conflict between MGC and MG.  The MGC sent IS because
it did not know about the fault at the MG, which was not reported because
the MG is following rule #2.  So let me try a variation of rule #2:

3.	An entity (MG or MGC) shall not send a ServiceChange changing the
state of a termination to IS if that termination is currently OOS at the
initiative of the peer.

Thus Case 2 becomes:

Case 3

MGC sends ServiceChange placing termination administratively OOS.
MG detects fault.  MG send ServiceChange announcing OOS from its end.
Management action at MGC wishes to return termination to service.
MGC does not send ServiceChange because it has to wait for the MG condition
to clear.
MG clears fault but does not send ServiceChange to MGC because of
administrative OOS.

Now we have a deadlock.  Each side is aware of the other's problem and does
not want to restore to service before the other.  So it looks to me as if a
secret secondary state is not good enough, and we need an explicit one.

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Thursday, 22 November, 2001 11:59 PM
	To:	'Raphael Tryster'; [email-masked]
	Subject:	RE: [Megaco] Multiple factors affecting a
termination's service s tate

	I'm assuming that in your example the MGC, in setting the
termination
	administratively OOS, has sent a ServiceChange request to the MG to
do so.
	It would seem reasonable that the MG should respect this request,
even after
	it has found and cleared a physical condition.  Thus there is no
conflict.

	On the other hand, suppose the sequence is different, so that the MG
sends
	the ServiceChange request rather than the MGC.  Here the MGC would
be bound
	to wait until the MG returned the termination to service.  Still no
	conflict.

	In the background, you have to assume that management systems are
running to
	ensure that out of service states are eventually cleared.  Megaco is
there
	just to ensure that call processing and termination availability are
kept in
	synch.

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
	Sent: Thursday, November 22, 2001 1:34 PM
	To: [email-masked]
	Subject: [Megaco] Multiple factors affecting a termination's service
state

	In some protocols, there is a concept of a primary service state
	(in-service/out-of-service) and a secondary service state (basically
the
	reason why the entity is OOS).  The primary service state is IS only
when
	none of the secondary OOS states apply.  In Megaco, there seems to
be only a
	primary service state for terminations.  Suppose the MGC sets a
termination
	OOS for administrative reasons, and subsequently the MG discovers a
physical
	problem requiring that termination to be OOS.  If we had a secondary
service
	state, we could ensure that the termination stays OOS until the LAST
of
	these conditions clears.  Without it, it seems behaviour is
	non-deterministic as the FIRST condition to clear will attempt to
return to
	service.  For example, if the MG discovers that the physical problem
has
	cleared, will it:
	Tell the MGC the termination is going IS?  Will the MGC then have to
issue a
	new command overruling the MG? or 
	Do nothing and wait for the MGC?  The MG can only make this decision
if it
	remembers there is an MGC OOS to wait for, i.e. it keeps a secondary
state. 

	In general, without a secondary state, either side wishing to change
the
	service state can override any previous history.
	What is the correct way to handle such situations in Megaco? 
	Raphael Tryster

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 25 Nov 2001 12:44:49 +0200

Tom,

	Case 1

	 
	Case 2

Thus Case 2 becomes:

Case 3

Raphael Tryster

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
	Sent: Thursday, November 22, 2001 1:34 PM
	To: [email-masked]
	Subject: [Megaco] Multiple factors affecting a termination's service
state

---

From: John Stock <[email-masked]>
Date: Mon, 26 Nov 2001 18:12:41 -0800

Additionally it seems that it would be necessary to maintain multiple IS/OOS
secondary service states, such as 
 
Administrative state - OOS
Fault state - OOS
 
Thus when one is cleared (e.g. the administrative state), the termination
will not be put into service prematurely since the other (e.g. the fault
state) is still OOS.
 
Taking it a step further, this would actually make local storage of the
primary and secondary states redundant, as the primary could be calculated
by simply OR'ing the secondary states.  It may still be useful to exchange
the primary state though, for auditing purpose.
 
Thoughts?
 
John Stock

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, November 25, 2001 2:45 AM
To: Tom-PT Taylor; [email-masked]
Subject: RE: [Megaco] Multiple factors affecting a termination's service s
tate

Tom, 

	Case 1 

Case 2 

Thus Case 2 becomes: 

Case 3 

Raphael Tryster 

	BM__MailData-----Original Message----- 
From:   Tom-PT Taylor [SMTP:[email-masked]] 
Sent:   Thursday, 22 November, 2001 11:59 PM 
To:     'Raphael Tryster'; [email-masked] 
Subject:        RE: [Megaco] Multiple factors affecting a termination's
service s tate 

synch. 

	-----Original Message----- 
From: Raphael Tryster [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, November 22, 2001 1:34 PM 
To: [email-masked] 
Subject: [Megaco] Multiple factors affecting a termination's service state

---

From: John Stock <[email-masked]>
Date: Mon, 26 Nov 2001 18:12:41 -0800

Thoughts?
 
John Stock

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, November 25, 2001 2:45 AM
To: Tom-PT Taylor; [email-masked]
Subject: RE: [Megaco] Multiple factors affecting a termination's service s
tate

Tom, 

	Case 1 

Case 2 

Thus Case 2 becomes: 

Case 3 

Raphael Tryster 

synch.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Nov 2001 23:36:34 -0500

The answer to all your quandaries is indeed to require both sides to track
two state variables.  However, this only requires one explicit state value
in the messages exchanged between them, as I'll explain below.  Thinking
this out, I've changed my mind a bit on how it all should work.  I came to
this point in considering what would happen in the case of SewrviceChange
'glare', where both sides simultaneously announce that the termination is
out of service.  We don't need a visible change in the protocol to take care
of this, but we do need to specify some behaviour.  We could specify backoff
rules, but I think the proposal I give below is simpler.

I would remark that the two states are not "fault" versus "administrative",
but rather "MG view" vs. "MGC view".  Administration could act directly on
the MG rather than through the MGC, or the MGC could detect a fault in the
provisioned data for the termination.  Each entity has to track its peer's
view as well as its own.

The necessary coordination can still be achieved through a single state
property in the messages exchanged.  The key point is in the interpretation
of that property.  Instead of a single shared view of state, it represents
the sender's view of state.  The required description of behaviour is
therefore as follows (text to go in the ServiceChange section 7.2.8:
 - either entity in the control association may send a ServiceChange
indicating a change in the state of a termination at any time
 - a termination is available for general use only if neither the MG nor the
MGC have most recently indicated that it is out of service
 - in other cases use of the termination is restricted.

The above defines language we can now use to replace current restrictions on
applying other commands when a termination is out of service.  We say
instead, that the commands cannot be applied when use of the termination is
restricted in accordance with the definition given in section 7.2.8.

-----Original Message-----
From: John Stock [mailto:[email-masked]]
Sent: Monday, November 26, 2001 9:13 PM
To: 'Raphael Tryster'; Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Subject: RE: [Megaco] Multiple factors affecting a termination's service
s tate

 

Thoughts?
 
John Stock

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, November 25, 2001 2:45 AM
To: Tom-PT Taylor; [email-masked]
Subject: RE: [Megaco] Multiple factors affecting a termination's service s
tate

Tom, 

[PTT] Right.  To be absolutely clear, the "state" referred to in that second
sentence is the Megaco state, which represents availability for general use,
not whatever internal representation of state the MG and MGC happen to
maintain.  As John remarks, this is the 'or' of the other states.

	Case 1 

[PTT] That is proper and good.  Presumably the MGC sends a ServiceChange
announcing a return to service as a result of the management action.  The
next step is for the MG to send a ServiceChange representing its view of the
termination's availability.

Case 2 

[PTT] Same result as above.

Thus Case 2 becomes: 

Case 3 

[PTT] No, what we need is a prohibition on sending either a ServiceChange to
IS or a ServiceChange to OS if the termination is already OS as a result of
the peer's action.

Raphael Tryster 

synch.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Nov 2001 23:36:34 -0500

-----Original Message-----
From: John Stock [mailto:[email-masked]]
Sent: Monday, November 26, 2001 9:13 PM
To: 'Raphael Tryster'; Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Subject: RE: [Megaco] Multiple factors affecting a termination's service
s tate

 

Thoughts?
 
John Stock

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Sunday, November 25, 2001 2:45 AM
To: Tom-PT Taylor; [email-masked]
Subject: RE: [Megaco] Multiple factors affecting a termination's service s
tate

Tom, 

	Case 1 

Case 2 

Thus Case 2 becomes: 

Case 3 

Raphael Tryster 

synch.

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 28 Nov 2001 09:48:07 +0200

Looks good to me.  What about initial states?  Perhaps a clarification could
be added to section 7.1.5 that IS is the default state both for the local
view of a termination, and for the local copy of the peer's view, if that is
the intention.  In other words, I initially see my termination as IS and
believe my peer also sees it as IS.

I am wondering about recovery after a period of disconnection.  Consider the
following sequence:

Initially, both MGC and MG view termination as IS.
MGC sends ServiceChange setting termination to OOS.  MG receives the
message.
Communication between MGC and MG is lost.
MGC sends ServiceChange setting termination to IS.  MG does not receive the
message.
Communication between MGC and MG is restored.
MG sends ServiceChange informing MGC of recovery.
MGC audits termination states.
MG replies that it views the termination as IS.

At this point, the MGC has a correct overall view but the MG has an
incorrect one.  The MGC has the termination IS and believes that the MG sees
it as IS.  The MG has the termination IS but believes that the MGC sees it
as OOS.  The asymmetry arises from the fact that the MGC can audit but the
MG cannot.  This is OK provided only the MGC makes call processing
decisions.  It is bad if, as a result of its mistaken view, the MG would
refuse to accept calls on the termination, or would refrain from sending
Notify.  How is the MG's behaviour defined in such a case?

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Wednesday, 28 November, 2001 6:37 AM
	To:	John Stock; 'Raphael Tryster'; [email-masked]
	Subject:	RE: [Megaco] Multiple factors affecting a

	The answer to all your quandaries is indeed to require both sides to
track
	two state variables.  However, this only requires one explicit state
value
	in the messages exchanged between them, as I'll explain below.
Thinking
	this out, I've changed my mind a bit on how it all should work.  I
came to
	this point in considering what would happen in the case of
SewrviceChange
	'glare', where both sides simultaneously announce that the
termination is
	out of service.  We don't need a visible change in the protocol to
take care
	of this, but we do need to specify some behaviour.  We could specify
backoff
	rules, but I think the proposal I give below is simpler.

	I would remark that the two states are not "fault" versus
"administrative",
	but rather "MG view" vs. "MGC view".  Administration could act
directly on
	the MG rather than through the MGC, or the MGC could detect a fault
in the
	provisioned data for the termination.  Each entity has to track its
peer's
	view as well as its own.

	The necessary coordination can still be achieved through a single
state
	property in the messages exchanged.  The key point is in the
interpretation
	of that property.  Instead of a single shared view of state, it
represents
	the sender's view of state.  The required description of behaviour
is
	therefore as follows (text to go in the ServiceChange section 7.2.8:
	 - either entity in the control association may send a ServiceChange
	indicating a change in the state of a termination at any time
	 - a termination is available for general use only if neither the MG
nor the
	MGC have most recently indicated that it is out of service
	 - in other cases use of the termination is restricted.

	The above defines language we can now use to replace current
restrictions on
	applying other commands when a termination is out of service.  We
say
	instead, that the commands cannot be applied when use of the
termination is
	restricted in accordance with the definition given in section 7.2.8.

	-----Original Message-----
	From: John Stock [mailto:[email-masked]]
	Sent: Monday, November 26, 2001 9:13 PM
	To: 'Raphael Tryster'; Taylor, Tom-PT [CAR:B800:EXCH];
[email-masked]

	Additionally it seems that it would be necessary to maintain
multiple IS/OOS
	secondary service states, such as 

	Thus when one is cleared (e.g. the administrative state), the
termination
	will not be put into service prematurely since the other (e.g. the
fault
	state) is still OOS.
	 
	Taking it a step further, this would actually make local storage of
the
	primary and secondary states redundant, as the primary could be
calculated
	by simply OR'ing the secondary states.  It may still be useful to
exchange
	the primary state though, for auditing purpose.
	 
	Thoughts?
	 
	John Stock

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
	Sent: Sunday, November 25, 2001 2:45 AM
	To: Tom-PT Taylor; [email-masked]
	Subject: RE: [Megaco] Multiple factors affecting a termination's
service s
	tate

	Tom, 

	1.	Both the MG and the MGC are required to maintain secret
secondary
	service states. 

	2.	An entity (MG or MGC) shall not send a ServiceChange
changing the
	state of a termination if that termination is currently OOS at the
	initiative of the peer. 

	[PTT] Right.  To be absolutely clear, the "state" referred to in
that second
	sentence is the Megaco state, which represents availability for
general use,
	not whatever internal representation of state the MG and MGC happen
to
	maintain.  As John remarks, this is the 'or' of the other states.

		Consider the following variations of sequences, based on
these
	rules: 

		Case 1 

		MGC sends ServiceChange placing termination administratively
OOS. 
	MG detects fault.  MG should not send ServiceChange 
	MG clears fault.  MG should not send ServiceChange 

		In order for the MG to suppress state changing, it must have
	remembered that there were two reasons for OOS, and this implies a
secret
	secondary state.  Now, let's suppose an administrative action is
performed
	by management on the MGC to return the termination to service while
the
	physical condition still exists.

	[PTT] That is proper and good.  Presumably the MGC sends a
ServiceChange
	announcing a return to service as a result of the management action.
The
	next step is for the MG to send a ServiceChange representing its
view of the
	termination's availability.

	Case 2 

		MGC sends ServiceChange placing termination administratively
OOS. 
	MG detects fault.  MG should not send ServiceChange. 
	Management action at MGC wishes to return termination to service. 
	MGC sends ServiceChange placing termination administratively IS. 

		Here we have a conflict between MGC and MG.  The MGC sent IS
because
	it did not know about the fault at the MG, which was not reported
because
	the MG is following rule #2.  So let me try a variation of rule #2:

	3.	An entity (MG or MGC) shall not send a ServiceChange
changing the
	state of a termination to IS if that termination is currently OOS at
the
	initiative of the peer. 

	Thus Case 2 becomes: 

	Case 3 

	MGC sends ServiceChange placing termination administratively OOS. 
	MG detects fault.  MG send ServiceChange announcing OOS from its
end. 
	Management action at MGC wishes to return termination to service. 
	MGC does not send ServiceChange because it has to wait for the MG
condition
	to clear. 
	MG clears fault but does not send ServiceChange to MGC because of
	administrative OOS. 

	Now we have a deadlock.  Each side is aware of the other's problem
and does
	not want to restore to service before the other.  So it looks to me
as if a
	secret secondary state is not good enough, and we need an explicit
one.

	[PTT] No, what we need is a prohibition on sending either a
ServiceChange to
	IS or a ServiceChange to OS if the termination is already OS as a
result of
	the peer's action.

	Raphael Tryster 

termination's
	service s tate 

		On the other hand, suppose the sequence is different, so
that the MG
	sends 
	the ServiceChange request rather than the MGC.  Here the MGC would
be bound 
	to wait until the MG returned the termination to service.  Still no 
	conflict. 

		In the background, you have to assume that management
systems are
	running to 
	ensure that out of service states are eventually cleared.  Megaco is
there 
	just to ensure that call processing and termination availability are
kept in

	synch. 

		-----Original Message----- 
	From: Raphael Tryster [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: Thursday, November 22, 2001 1:34 PM 
	To: [email-masked] 
	Subject: [Megaco] Multiple factors affecting a termination's service
state 

		In some protocols, there is a concept of a primary service
state 
	(in-service/out-of-service) and a secondary service state (basically
the 
	reason why the entity is OOS).  The primary service state is IS only
when 
	none of the secondary OOS states apply.  In Megaco, there seems to
be only a

		In general, without a secondary state, either side wishing
to change
	the 
	service state can override any previous history. 
	What is the correct way to handle such situations in Megaco? 
	Raphael Tryster

---

From: Raphael Tryster <[email-masked]>
Date: Wed, 28 Nov 2001 09:48:07 +0200

Raphael Tryster

	-----Original Message-----
	From: John Stock [mailto:[email-masked]]
	Sent: Monday, November 26, 2001 9:13 PM
	To: 'Raphael Tryster'; Taylor, Tom-PT [CAR:B800:EXCH];
[email-masked]

	 

	Thoughts?
	 
	John Stock

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
	Sent: Sunday, November 25, 2001 2:45 AM
	To: Tom-PT Taylor; [email-masked]
	Subject: RE: [Megaco] Multiple factors affecting a termination's
service s
	tate

	Tom, 

		Case 1 

	Case 2 

	Thus Case 2 becomes: 

	Case 3 

	Raphael Tryster 

	synch. 

		-----Original Message----- 
	From: Raphael Tryster [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: Thursday, November 22, 2001 1:34 PM 
	To: [email-masked] 
	Subject: [Megaco] Multiple factors affecting a termination's service
state