Subject: [Megaco] Re: Draft H.248 Implementor's Guide approved at the Q.3

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 11:42:49 -0400

I am not sure if I understand the significance of your points below, but 
let me try to respond.  I'm forwarding it on to the megaco list as well 
since there are some issues that others may want to comment on.

Chuong N. Nguyen wrote:

> Say MG established controlling association w/MGC and MGC specifies MG 
> to use UDP port 10,000.
> Therefore all future msgs from MG to MGC has to go to MGC port 10,000.
>
> Thus implying SC Disconnected too.
>
> Now for whatever reason MGC cold booted which meant that it had also 
> all info about MG and any
> port opened for that MG.
>
> Since MGC is not listening on port 10,000, all SC Disconnected from MG 
> will not be answered.
>
Certainly true.  MG will think that MGC has failed and try any 
alternates it has provisioned.  I guess the issue is that after it has 
exhausted these and (as suggested in 11.5) re-tries the original MGC 
should it use port 10000 or the default 2944.  Port 10000 is used for 
the duration of the "association" but precise rules for association 
termination are not given.  I would assume that after some number of 
attempts to re-establish the association MG would conclude that the MGC 
has truly failed and that any subsequent registration is a wholely new 
association and revert to the 2944 port.  Perhaps your point is that at 
this same time, MG might begin using "handoff" rather than 
"disconnected" since it is really now a new association rather than a 
reestablishment of the old.  I am not sure that this truly requires 
using a different method since the MG cannot really know whether state 
has been lost or not, but I agree that MG should not keep trying the old 
port forever.

> Now one can ask the question as to why doesn't the MGC keep a 
> persistent data for the port used.
> Well it could but that leads us into another situation.
>
> Say while MGC is cold booting, MG went off and register w/another MGC2 
> using SC Failover.
> Thus MGC is holding info or has resources tied to an MG that might 
> never come back and re-register
> w/it.
>
11.5 specifies that MGC state mainenance is outside the scope of H.248. 
 I would assume that most MGCs would use a timer to decide how long to 
keep state on possibly terminated associations.

As you may know there are ongoing discussions about specifying more 
precisely the states of an association and I would assume that some of 
the above would be specified more carefully in this.

>  
>  
>
> Terry L Anderson wrote:
>
>>  
>>
>> Chuong N. Nguyen wrote:
>>
>>>  
>>> Thanks
>>>
>>> I really don't quite agreed w/this change but it is bridge under 
>>> water now.
>>>
>>> Simply because - how does MG knows that it has lost communication 
>>> w/MGC to start sending
>>> SC Disconnected.
>>>
>> Obviously if it doesn't know, it won't send SC.  But there are a 
>> number of ways it may know (ICMP error, timeout on response to a 
>> Notify, Notify from Inactivity timer package,..).  If it IS aware 
>> then it sends SC/Disconnected.
>>
>>> What is wrong w/just using SC Failover for all MGCs on the list to 
>>> start with?
>>
>> There are two cases from MGC1's point of view.
>> 1. MG lost communications with it and was controlled by MGC2 for 
>> awhile and is now back (failover)
>> 2. MG lost communications with it and is back but was never 
>> controlled by another MGC (disconnect).
>>
>> The need to audit and what to audit may be very different in these 
>> two cases.
>>
>>> Does MG keep sending SC Disconnected to the controlling MGC if the 
>>> MGC does not answer back
>>> or answer back w/error code 504 - Unauthorized MG which could 
>>> happend if MGC was cold boot and
>>> does not have any info about which MG was already registered?
>>
>> If MGC does not answer, MG will try any alternates it has 
>> provisioned.  If it has no alternates or it has failed in attempts to 
>> all of them, then it re-tries MGC.  It continues to try alternates 
>> and original MGC until one accepts it.
>>
>> If MGC responds but sends 504, then I would assume that MG does a 
>> registration.
>>
>>> Terry L Anderson wrote:
>>>
>>>> I am attaching TD-28.  The item you are looking for is IG 6.92.   
>>>> And the added text DOES appear in TD-47 which incorporated all the 
>>>> IG changes through the Dublin meeting.
>>>>
>>>> Chuong N. Nguyen wrote:
>>>>
>>>>> Hi Terry
>>>>>
>>>>> I am looking for the following doc.
>>>>>  
>>>>>
>>>>>    IGDUB: Draft H.248 Implementor's Guide approved at the Q.3
>>>>>    Rapporteur's meeting held near Dublin, October 2001 (as TD-28, 
>>>>> Terry
>>>>>    Anderson, editor).
>>>>>  
>>>>>
>>>>> Specially I am interesting in knowing the reason why the following 
>>>>> change was made
>>>>>
>>>>>    11.5        IGDUB    Added text indicating that when trying to
>>>>>                         reestablish contact with the previously
>>>>>                         controlling MGC the MG uses the Disconnected
>>>>>                         method.
>>>>>  
>>>>>
>>>>> Is this part of TD-47?
>>>>>
>>>>> 11.5 Failure of an MGC
>>>>> If the MG detects a failure of its controlling MGC, it attempts to 
>>>>> contact the next MGC on its pre-provisioned list.  It starts its 
>>>>> attempts at the beginning (Primary MGC), unless that was the MGC 
>>>>> that failed, in which case it starts at its first Secondary MGC.  
>>>>> It sends a ServiceChange message with a "Failover" method and a " 
>>>>> MGC Impending Failure" reason. If the MG is unable to establish a 
>>>>> control relationship with any MGC, it shall wait a random amount 
>>>>> of time as described in section 9.2 and then start contacting its 
>>>>> primary, and if necessary, its secondary MGCs again. When 
>>>>> contacting its previously controlling MGC the MG sends the 
>>>>> ServiceChange message with "Disconnected" method.
>>>>>  
>>>>>
>>>>> Thanks
>>>>> Chuong
>>>>>
>>>>>-- 
>>>>>  Alcatel USA, Inc             Internet: [email-masked]
>>>>>  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>>>>>  **** The opinions expressed are not those of Alcatel USA, Inc ****
>>>>>
>>>>>  
>>>>
>>>>-- 
>>>>
>>>>------------------------------------------------------------
>>>>Terry L Anderson              mailto:[email-masked]
>>>>Tel:732.949.5628   Fax:732.949.7016
>>>>Lucent Technologies/INS/Voice Over IP Access Networks
>>>>Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
>>>>http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>>>>
>>>>        
>>>>
>>>>  
>>>
>>>-- 
>>>  Alcatel USA, Inc             Internet: [email-masked]
>>>  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>>>  **** The opinions expressed are not those of Alcatel USA, Inc ****
>>>
>>>  
>>
>>-- 
>>
>>------------------------------------------------------------
>>Terry L Anderson              mailto:[email-masked]
>>Tel:732.949.5628   Fax:732.949.7016
>>Lucent Technologies/INS/Voice Over IP Access Networks
>>Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
>>http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>>
>>    
>>
>>  
>
>-- 
>  Alcatel USA, Inc             Internet: [email-masked]
>  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>  **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>  

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 11:42:49 -0400

--

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 23 Jul 2002 12:14:26 -0500

I guess my point is the definition of control association and what is the
lifetime of control association.

The MGC has cold booted for whatever reason.
After this, is the MGC expected to maintain the knowledge of control
association before it cold booted?
I don't think so.
If MGC does not have any control association w/any MG, then can it really
treat MG SC Disconnected
as a registration?

I think there is nothing wrong w/the change in the Standard but a
clarification should be given that
SC Disconnected should only be used or answered if there is control
association between MGC and MG.

I think the original intend was for MGC to answer to SC Disconnected if it
could.
But if MGC does not answer to SC Disconnected or answer with error, it is
still up to MG to take the corrective
action to re-register w/any MGC including what MG thinks is its controlling
MGC.

Also MGC is already telling MG that MG is NOT authorized thus it is already
informing MG that
there is no control association so stop sending SC Disconnected - either go
away or try to re-register
and see if MGC is willing to accept the MG service request.

I don't think HandOff is the right Method to use here.
Since it was not directed by its controlling MGC to try another MGC.

The following paragraph is making the MG implementation more complicated.

     11.5  Failure of an MGC
        If the MG detects a failure of its controlling MGC, it attempts
     to
        contact the next MGC on its pre.provisioned list. It starts its
        attempts at the beginning (primary MGC), unless that was the MGC
     that
        failed, in which case it starts at its first secondary MGC. It
     sends
        a ServiceChange message with a "Failover" method and a " MGC
        Impending Failure" reason. If the MG is unable to establish a
     control
        relationship with any MGC, it shall wait a random amount of time
     as
        described in section 9.2 and then start again contacting its
     primary,
        and (if necessary) its secondary MGCs. When contacting its
     previously
        controlling MGC, the MG sends the ServiceChange message with
        ôDisconnectedö method.

Now MG has to keep track of what Method to use for each MGC in the list.
For the non-controlling MGC, it is simple - Failover.
For the controlling MGC, it is Disconnected but after so many retries, it
becomes - Restart/Failover/HandOff?

HandOff is out as I have explained above.
Restart - MG did not restart.  MG did not boot - cold/warm/etc.
                   MG did not fail.
                   Using Reason code 900?? - MG never lost it service
capability.  It is MGC that failed.
                   If we use this Method, we have to use a clear Reason code
to indicate this to MGC so MGC does not
                   assume that MG is starting from scratch w/no contexts being
used.

Failover - By Section 11.5, if we ignore the "controlling MGC changes",
I don't see any reason why MG can't
                     use this.  What difference does it make to MGC whether
the Method is Failover.
                     MG is trying to tell MGC that my controlling MGC has
failed can you service me.
                     At this point it doesn't matter to MGC that it was or was
not the MG controlling MGC.
                     MGC will either reply back w/yes or no.
                     If yes, then MGC can decide what to do next.  MGC will
take the appropriate action to rebuild its MG state info.

Also from Section 7.2.8 ServiceChange

   6) Failover û sent from MG to MGC to indicate the primary MG is out
      of service and a secondary MG is taking over. This serviceChange
      method is also sent from the MG to the MGC when the MG detects
      that MGC has failed.

Further down in 7.2.8

     The Media Gateway may also announce a registration
        command by specifying the "Root" for the TerminationID and
        ServiceChangeMethod equal to Failover when the MG detects MGC
        failures.

And that is why I ask the question - how does MG determines that its
controlling MGC has failed?

By 7.2.8, if MG detects that MGC has failed, it is supposed to use Failover.
IT does not say anything about controlling MGC or not.

     I am not sure if I understand the significance of your points below,
     but
     let me try to respond.  I'm forwarding it on to the megaco list as
     well
     since there are some issues that others may want to comment on.

     Certainly true.  MG will think that MGC has failed and try any
     alternates it has provisioned.  I guess the issue is that after it
     has
     exhausted these and (as suggested in 11.5) re-tries the original MGC

     should it use port 10000 or the default 2944.  Port 10000 is used
     for
     the duration of the "association" but precise rules for association
     termination are not given.  I would assume that after some number of

     attempts to re-establish the association MG would conclude that the
     MGC
     has truly failed and that any subsequent registration is a wholely
     new
     association and revert to the 2944 port.  Perhaps your point is that
     at
     this same time, MG might begin using "handoff" rather than
     "disconnected" since it is really now a new association rather than
     a
     reestablishment of the old.  I am not sure that this truly requires
     using a different method since the MG cannot really know whether
     state
     has been lost or not, but I agree that MG should not keep trying the
     old
     port forever.

     > never come back and re-register
     11.5 specifies that MGC state mainenance is outside the scope of
     H.248.
      I would assume that most MGCs would use a timer to decide how long
     to
     keep state on possibly terminated associations.

     As you may know there are ongoing discussions about specifying more
     precisely the states of an association and I would assume that some
     of
     the above would be specified more carefully in this.

     --

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 23 Jul 2002 12:14:26 -0500

11.5  Failure of an MGC

Further down in 7.2.8

     --