Subject: RE: [Megaco] Failure of MGC

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 24 Jul 2001 08:47:19 -0400

I have a feeling it would be a really good idea to write an I-D to review
the entire topic of the birth and death of control associations.  We spend
huge amounts of list time on this topic.  Once that I-D had been firmed up
to the list's satisfaction, we could back-propagate any necessary amendments
to the core protocol spec.

The passages you quote are not necessarily in conflict, but may be difficult
to reconcile in practice.  Let's look at the ways the MG can decide that
there is a problem:

 1) The MGC sends a ServiceChange indicating that it is about to fail,
without a Handoff redirection.  (Is this likely to happen?  I suppose I can
imagine a network setup where the MGC relies on the MG to go to its list of
alternative MGCs.)  This would be consistent with the cited 11.5 case.

 2) The MGC sends a ServiceChange with a Handoff.  Not covered by the 11.5
case.

 3) A connection-oriented transport connection (e.g. TCP) between the MG and
MGC fails.  I'm inclined to think this would be covered by Failover (the
11.5 case).

 4) Transport is connection-oriented (e.g. TCP) and the MGC fails to respond
to an MG request.  Again an 11.5 Failover case, I think.

 5) Transport is connectionless (UDP/ALF) and the MGC fails to respond to an
MG request.  In this case, you can't tell if this is a network or MGC
problem.  Hence the advice in D.1.5 to use Disconnected.

 6) Transport is connectionless (UDP/ALF) and the MGC fails to acknowledge a
message.  Same conclusion as 5).

Refinements of this analysis are welcome.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 6:39 AM
To: [email-masked]
Subject: [Megaco] Failure of MGC

Hi

Section 11.5 indicates, if the MG detects failure of its controlling MGC, it
sends the service change command with Failover method.
And Section D.1.5 indicates, if more than T-MAX time has elapsed since the
sending of initial datagram, the MG concludes that the MGC has failed, it
sends
the service change command with Disconnected method.

Can you please differentiate between the two?

Regards
Vivek

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

---

From: [email-masked]
Date: Wed, 25 Jul 2001 20:04:45 +0530

Hi Tom

I feel the definition of these protocol terms like Failover and disconnected
should be transport independent.

If the MG detects the failure of MGC which could be due to any reason i.e.
either failure of actual MGC or the signalling link between them, MG should you
either Failover or Disconnected method.

Regards
Vivek

"Tom-PT Taylor" <[email-masked]> on 07/24/2001 06:17:19 PM

To:   Vivek Bansal/HSS@HSS, [email-masked]
cc:

Subject:  RE: [Megaco] Failure of MGC

Tom Taylor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 6:39 AM
To: [email-masked]
Subject: [Megaco] Failure of MGC

Hi

Regards
Vivek

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 25 Jul 2001 16:39:08 -0400

I think (1) ("Disconnected" if reestablishing at same MGC, "Failover" if
trying a new one)is a good solution if agreeable to the list.

Tom Taylor

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 11:04 AM
To: Christian Groves
Cc: [email-masked]; [email-masked]
Subject: Re: [Megaco] Failure of MGC

Christian Groves wrote:

> Hello,
>
> I believe 11.5 is correct. The paragraph starts, "If the MG detects a
> failure of its controlling MGC, it attempts to contact the next MGC on
> its pre-provisioned list." This is clearly failover.
>
> D.1.5, I believe intends "Disconnect" as it is used when communication
> has been restored (recovered) with the MGC.

The the wording is wrong as it says "The MS shall use a ServiceChange with
ServiceChangeMethod set to Disconnected to that the new MGC will  be aware
..."  so it is
referring to value sent to NEW MGC for restored communication with original
MGC.

> Disconnect is used when you don't fail over to a completely new MGC.

Well whichever way we settle, I think the current wording is confusing and
call cases
should be described in one place.

So our choice is:
1) use "failover" in attempts to contact next MGC on pre-provisioned list
(if any) but
"Disconnected" if (possibly after trying others) one re-tries the original,
OR
2) use "Disconnected" in both cases.

If we choose case 1, I would fix the wording in D.1.5 and spell out BOTH
cases in 11.5.
Def of Failover in 7.2.8 should include this case (currently it only
includes case of MG
failure).
If we choose case 2, I would fix 11.5 to say "disconnected"

Which do we want??

>
>
> Regards, Christian
>
> Terry L Anderson wrote:
> >
> > It DOES look like a contradiction.  I have always wondered about the
11.5
> > specification to use Failover since this case is not mentioned in the
definition of
> > failover in 7.2.8 and there the definition of Disconnected does seem to
fit
> > (agreeing with D.1.5).
> >
> > What do others want to do?  Change 11.5 to say "Disconnected"?
> >
> > [email-masked] wrote:
> >
> > > Hi
> > >
> > > sending of initial datagram, the MG concludes that the MGC has failed,
it sends
> > --
> > Waiting for the other shoe to drop but hoping its a one legged man.
> > ------------------------------------------------------------
> > Terry L Anderson              mailto:[email-masked]
> > Tel:908.582.7013   Fax:908.582.6729
> > Lucent Technologies/INS/Voice Over IP Access Networks
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

--
Waiting for the other shoe to drop while hoping it's a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Kaul, Bharat" <[email-masked]>
Date: Thu, 26 Jul 2001 18:20:08 -0700

Modified "handoff" comment from my previous email. I had someone make me jog
my memory :)

- Bharat

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 3:49 PM
To: Madhu Babu Brahmanapally
Cc: [email-masked]

Let's discuss this before I write specific language.  I propose
Graceful:  MG->MGC only

[Bharat]  Alright with me

Forced: MG->MGC & MGC->MG
Restart: MG->MGC & MGC->MG

[Bharat] What would be the difference between two methods when direction is
MGC->MG ?

Disconnected: MG->MGC only

Handoff: MG->MGC & MGC->MG (as currently specified)
[Bharat] This is ok.

Failover: MG->MGC only (only direction currently specified)
[Bharat] This is ok.

---

From: [email-masked]
Date: Fri, 27 Jul 2001 20:50:04 +0530

Hi Madhu, Tom, Brian,
As per the discussion going on over the list regarding the usage of "Service
Change Method", there is one thing still unclear as mentioned below.

In a service change command on ROOT termination, what does a METHOD field
actually convey i.e. either a change in the control association or the a change
in the call state for all the associated terminations or both? For instance, if
MG sends a Service Change command with "Restart" method on ROOT, does it imply
that only the control association (re-registration) between MG and MGC is
affected or the call state of the associated terminations also change?

Regards,
Prashant

"Madhu Babu Brahmanapally" <[email-masked]> on 07/27/2001 08:04:15 PM

To:   "'Terry L Anderson'" <[email-masked]>, "'Kaul, Bharat'"
      <[email-masked]>
cc:   [email-masked] (bcc: Prashant Jain/HSS)

Hi Terry,
This is perfectly fine. If possible, text can be added related to the
Restart Method on ROOT termination from MGC(from the "ServiceChange Method
Usage" thread), if MGC specifies a ServiceChange Address, further requests
from the MG (Ex for Registration) will be sent to the newly specified
ServiceChange Address(If present). (I'm not sure if people have different
opinions, as the control association is broken, whether the MG should still
act on the (earlier controlling)MGC specified parameters).

Regards
Madhubabu

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, July 27, 2001 9:36 AM
To: Kaul, Bharat
Cc: Madhu Babu Brahmanapally; [email-masked]'
Subject: Re: [Megaco] Failure of MGC

"Kaul, Bharat" wrote:

> My comments are given below
>

Well I assume that the most common is MG->MGC.  MG signals that it wants
(local
GUI cmd or fault detected on TDM line, ...) to take one or more terminations
down.  It sends Forced or Graceful and then Restart when it wants them back
up.  MGC responds by Subtracting the terminations from any non-NULL Context
and
not Adding them.

I assume that some may want MGC to be able to also take lines out-of-service
(due to central mainenance decision, SS7 signaling, ...).  For most purposes
it
need not even inform MG, it simply Subtracts the terminations from any
non-NULL
contexts and avoids any Adds, but it may be useful to send Forced to the MG
to
make it aware that the lines are out of service.  This would be especially
useful for analog lines so the MG would not accept inbound calls (of course
turning off all events should accomplish this).  In any case there is little
the MG might do other than setting the state and replying with it to any
Audits.  But I see no reason to restrict it.

> [Bharat] Handoff from MG->MGC ? What does this mean ? So far I think
> specifications define handoff from MGC->MG only wherein MGC wants an MG to
> contact another MGC for further communication.

The current version H.248 states in the definition (I am not suggesting a
change):
    "Sent from the MG to the MGC, this indicates that the MG is attempting
to
establish a new association in accordance with a Handoff received from the
MGC
with which it was previously associated."

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 27 Jul 2001 11:22:11 -0400

Terry, I think you made a good move for opening up the discussion by doing
your enumeration of cases.  What I would like to see is that we step
backward for a moment to the level of requirements.  What is it we have to
signal?  When we've enumerated all the cases, we can go back to matching
them to what the protocol currently offers.

Basically I think we should derive association state machines for the MG and
the MGC, starting with the events, then the states, and finally the actions.
When we have all that, we can relate the actions to the messages that can be
sent according to the current protocol specification.  Any misfits or gaps
can be fixed in the IG.

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 6:49 PM
To: Madhu Babu Brahmanapally
Cc: [email-masked]
Subject: Re: [Megaco] Failure of MGC

Ok, the issue is how explicit to be as well has what sort of changes should
be
introduced through the IG.  Since I have only been editor for 2 months, I'll
accept some guidance from the group about what sort of changes to allow.  I
know
that there was a recent comment (Christian?) about avoiding gratuitous
changes.

Personally I am bothered by ambiguity and fear it causes interoperability
problems so my bias would be to support changes whenever we uncover an
ambiguity
that has a reasonable probability of leading to confusion and inconsistent
implementations - the change would attempt to remove ambiguousness by being
more
specific.  I would not support change where someone merely misread the
statement
because its wording was a little confusing but it could only reasonably be
interpretted one way.

I'll argue that this issue falls in the "support change" class unless the
intent
was to basically allow all ServiceClassMethods (or all not mentioning
direction)
to be used in either direction whether or not it makes a lot of sense.  The
problem is that one could never be sure the other end would take any
suitable
action.  So I would suggest that we add a directional statement (MG->MGC,
MGC->MG or both) to each Method that does not currently have one.

Do we agree that MGC can send Forced and Restart but NOT Graceful?  Seems
useful
for MGC to be able to manage inservice/out-of-service state in certain
cases,
but I see no reason for it to use Graceful (MGC can "refrain from
establishing
new connections" and can "gracefully teardown existing connections" on its
own
and then send Forced when it is ready).

Madhu Babu Brahmanapally wrote:

> HI Terry, All,
> my comments below [Madhu]
>
> Sent: Thursday, July 26, 2001 5:08 PM
> Madhu Babu Brahmanapally wrote:
>
> > HI All,
> > Along with the following text, can we add text to say whether both MGC
and
> > MG can use the same method or not. For example usage of Disconnected is
> > listed in the document to be used only by MG.
>
> I don't think that there is any global rule.  Each must (and most do) list
> whether MG or MGC or both may use it and what the meaning is in each case.
> Currently Disconnect does not explicitly indicate direction.  I believe
that
> the
> current description assumes MG->MGC.  I have heard no proposal for what it
> would
> mean if sent from MGC->MG.  If a connection is lost (disconnected) a new
one
> currently must be initiated by MG.  Are you suggesting that MGC might
> initiate a
> reconnection?  This would seem related to a previous discussion about
> Polling
> and I believe it was agreed that MGC could not initiate.
>
> So are you proposing that we make the restriction of MC->MGC only
explicit?
> or
> are you suggesting that it should be used MGC->MG?  If the latter, someone
> would
> have to propose what it would mean.
>
> [Madhu]Yes, IMO making the direction explicit will give more clarity. As
you
> suggested, the disconnection from MGC is not valid and hence needs to be
> mentioned. Its true that the protocol at present discusses only the case
> where MG uses that method, it doesn't mention whether using the same
method
> if valid or not (and if assumed valid, what is its implication). Because
the
> grammar at present support all methods in both directions, explicitly
> mentioning the direction will help.
>
> The recent thread started by Andrew Russell-laing seems to be favoring the
> use
> of Restart from MGC->MG.  Restart is one that currently does not
explicitly
> state direction although the description seems to assume MG->MGC.  I will
> add a
> directional statement  for Restart if it appears we are all in agreement..
>
> Any objections?
>
> -Regards
> Madhubabu

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 31 Jul 2001 07:33:04 -0400

My thoughts below.

-----Original Message-----
From: Hariharasubramanian R [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 4:00 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]
Cc: [email-masked]; Madhu Babu Brahmanapally; 'Terry L Anderson';
'Kaul, Bharat'; [email-masked]
Subject: Re: [Megaco] Failure of MGC

Hello,

    I have a few questions/clarifications regarding Failure of MGC :

    All references are based on RFC 3015.

    (Q.1)    Section 11.4, second para: "Allowing the MGC to send
duplicate messages to *both* MGs accomodate pairs of MGs that are
capable of redundant failover ..."
            (*) In a scenario where providing MG fault tolerance is
intended, can one provision two virtual MGs in such a way that the one
acts as Active and another as Passive, (both provisioned with the same
semi-permenant terminations) ?

[PTT] Yes.

            (*) If so, will both the virtual MGs share the value of the
MID parameter ?

[PTT] I think this is feasible.  Effectively the two MGs support the same
control association.

            (*) If the virtual MGs above are provisioned to have
different IP addresses, can I use the procedures in 11.4 as a
replacement for IP address takevover ?

[PTT] Such as they are, yes.  The section is very short in its description.
Obviously a new ServiceChangeAddress would be supplied in the request from
the failing MG.  I would be inclined to include ServiceChangeReason 908 MG
Impending Failure, hinting at graceful handoff.

            (*) How does the MGC learn about the *pair* of MGs capable
of redundant failover ? If *provisioning/management method* is the only
way, should we specify this explicitly (as for others) in the RFC ?

[PTT] This isn't a protocol issue unless there is a consensus to add the
capability to indicate redundancy in v2.  Until then the method need not be
specified and is an implementation issue.

    (Q.2)    Section 11.5, last para: "Pairs of MGCs that are capable of
redundant failover ..." ::
            (*) Is this mechanism "intended" to be used in a situation
to run MGC in an Active/Passive mode so as to provide fault tolerance ?

[PTT] Yes.

TIA,

rhari !

--
!===========================================================================
=!
= Hariharasubramanian R., Research Engineer, C-DoT, Bangalore.
=
= Call me at : OFF: 2383951(Dir) / 2263399 (268)
=
=              RES: 3435971
=
= Alternate email : [email-masked]
=
= Url: http://i.am/rhari
=
!===========================================================================
=!

---

From: [email-masked]
Date: Tue, 31 Jul 2001 20:53:00 +0530

Hello Kevin, Brian,
Does it mean that there is going to be no significance of "service change
reason" parameter in case of service change command on "ROOT" with method as
"RESTART. So does it imply that the extent of the call state change (cold boot
or warm boot) carry no meaning with RESTART method??

For that matter, does the "service change reason field" carry any significance
in the service change command on "ROOT" for any of the other methods like FORCED
or DISCONNECTED?? Whatever discussions have been made till now on the list, I
could infer that the "reason" field carry no significance as of now for ROOT
termination.

Regards,
Prashant Jain

"Kevin Boyle" <[email-masked]> on 07/27/2001 09:30:13 PM

To:   Prashant Jain/HSS@HSS, Madhu Babu Brahmanapally <[email-masked]>
cc:   "'Terry L Anderson'" <[email-masked]>, "'Kaul, Bharat'"
      <[email-masked]>, [email-masked]

It was agreed in an earlier thread that a "Restart" implies full loss of
state -- the MG is coming up clean, with all physicals in NULL and no
ephemerals.

Kevin

 -----Original Message-----
From:     [email-masked] [mailto:[email-masked]]
Sent:     Friday, July 27, 2001 11:20 AM
To:  Madhu Babu Brahmanapally
Cc:  'Terry L Anderson'; 'Kaul, Bharat'; [email-masked]
Subject:  RE: [Megaco] Failure of MGC

Hi Madhu, Tom, Brian,

In a service change command on ROOT termination, what does a METHOD field
actually convey i.e. either a change in the control association or the a
change
in the call state for all the associated terminations or both? For instance,
if
MG sends a Service Change command with "Restart" method on ROOT, does it
imply
that only the control association (re-registration) between MG and MGC is
affected or the call state of the associated terminations also change?

Regards,
Prashant

Hi Terry,

Regards
Madhubabu

---

From: "Harry Suede" <[email-masked]>
Date: Tue, 31 Jul 2001 23:08:56 +0800

Hi Tom

Are we really planning to have the association state machines for MG/MGC. If yes, will that be part of the same I-D which you suggested some time back or will it come up as a separate document.

-Harry

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

From: "Tom-PT Taylor" <[email-masked]> 
To: "'Terry L Anderson'" <[email-masked]>, 
Madhu Babu Brahmanapally <[email-masked]> 
Cc: [email-masked] 
Subject: RE: [Megaco] Failure of MGC 
Date: Fri, 27 Jul 2001 11:22:11 -0400 

-- 

_______________________________________________
Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! 
http://www.net2phone.com/cgi-bin/link.cgi?143

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 31 Jul 2001 13:17:53 -0400

It would be part of the I-D I spoke of.  In view of today's dicussion of
timestamps, I'm starting to think we need a general discussion of the uses
of ServiceChange.  We can start with association management and go on from
there.

-----Original Message-----
From: Harry Suede [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 11:09 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: [email-masked]
Subject: RE: Failure of MGC

Hi Tom

Are we really planning to have the association state machines for MG/MGC. If
yes, will that be part of the same I-D which you suggested some time back or
will it come up as a separate document.

-Harry

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

--