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

From: Venkatesh Potdar <[email-masked]>
Date: Tue, 23 Jul 2002 20:13:14 -0700

Hello every one,

      Trying to revive an old discussion. This one didn't seem to have
reached a conclusion.

	The discussion below should lead to one of the following two
conclusions:

1. Both the MG and the MGC keep track of the other's state (i.e. both know
the MG view and the MGC view).

2. The MG need not keep track of the MGC's state. It is up to the MGC to
align itself with the state in the MG.

	Which option should it be?

	Another related aspect on which I would like to get a clarification
is the handling of events/signals by the MG when a termination is put out of
service. The H.248 spec only says that in the 'out of service' state, the
termination cannot be used for traffic. This should imply that the MG
continues to report observed events to the MGC. Extending this further, it
should be possible for the MGC to apply new events descriptors to the 'out
of service' termination and the corresponding observed events would have to
be reported by the MG to the MGC.

	Is this interpretation correct?

Regards,
--Venkatesh

             -----Original Message-----

From: Christian Groves <[email-masked]>
To: Raphael Tryster <[email-masked]>
CC: Tom-PT Taylor <[email-masked]>,
        John Stock <[email-masked]>, [email-masked]
Subject: Re: [Megaco] Multiple factors affecting a termination's service
state

G'Day,

Please see my comments below [CHG].

Regards, Christian

Raphael Tryster wrote:
> 
> 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.

[CHG] I don't see the reason why the MG has to keep a track of what it
believes the state of the MGC is. The MG knows whether its own
termination is IS or OS. Its up to the MGC to align itself with the
states in the MG.

 . . .
> 
> 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
>      termination's service s tate
> 
>      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
> 
>      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,
> 
>      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.
> 
>      [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:
> 
>      [PTT] Same result as above.
> 
>      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
> 
>              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
> 
>              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]
>      <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

=====================================
This message (including any attachments) is intended only for the use of the
named addressee(s), and may contain information that is legally privileged,
confidential or exempt from disclosure under applicable law. If you are not
a named addressee, you are hereby notified that any use, dissemination,
distribution or copying of this message is strictly prohibited. If you have
received this message in error, please notify the original sender
immediately by telephone or by return E-mail and delete this message, along
with any attachments, from your computer. Thank you.

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

---

From: Venkatesh Potdar <[email-masked]>
Date: Tue, 23 Jul 2002 20:13:14 -0700

Hello every one,

Regards,
--Venkatesh

             -----Original Message-----

G'Day,

Regards, Christian

 . . .