Subject: RE: Context Id in Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Apr 2001 09:13:19 -0400

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Sunday, April 08, 2001 6:33 PM
Cc: [email-masked]'
Subject: Re: Context Id in Service Change

Ok.  It is useful for MG to send Forced w/ROOT if it can before it goes
away. 

1) So does a Forced w/ROOT mean that the MGC-MG association is broken? 
     MGC does no have to perform any heartbeat to the MG. 
     MG and MGC would not accept any message from each other until 
     MG sends a Restart w/ROOT to MGC.  

I think so, yes 

     So Kevin, if Forced w/ROOT does not necessary mean cold boot, what
Reason 
      should MG give in the Restart. 
     I hope MG comes back w/Reason of cold boot.  If MG comes back 2 days
later w/warm boot, 
     I am not sure what MGC is supposed to think here.  

Yeah, pretty weird, although how would you know/why would you care? 
     Brian had indicated earlier that warm boot means that MG has kept
whatever 
     state it had before Restart and MGC should do an Audit to synch up
w/MG. 

     We have already decided all contexts are cleared and Forced w/ROOT is
an MG failure 
      condition.  So what other state info can there be?  

I agree.  I want to keep forced with Root a full failure of the MG, and
require cold boot on restart. 

2) Forced w/term=ALL means that MGC-MG association is not broken. 
     It could take days for MG to recover, in the meantime, MGC and MG
should 
     still perform heartbeat towards each other. 
     MGC is still responsible for cleaning up MG contexts. 
     Is MG still capable of handling subtract ALL from MGC?  

I think it should.  That is the difference between failing root and failing
ALL. 

3) ServiceChangeReason is optional if you are looking at ABNF but it is not 
     optional in the ASN.1  

Didn't we addresss this in the IG?  I though we decided it is NOT optional. 

4) Why did we exclude Graceful w/ROOT?  If after delay timer has expired and
MGC 
     did not sent subtract ALL, do we also assume that MG has cleaned up all
contexts too?  

I always believed that a graceful with root was followed by a forced on root
if the state of the MG was not clean.   The MG is indicating that it is
going down.  If the MGC leaves state in the MG, that is a problem. 

Kevin Boyle wrote: 

Hold on... ServiceChange Forced on Root does not necessarily mean "cold 
boot" -- the Restart to come back in service will take care of that. 
The Forced just indicates that the MG is going out of service... for an 
indefinite period of time, and for any one of a number of reasons.  It 
may be instantaneous, or it could be days.  However, the Forced allows 
the MGC to clean itself up in advance, without having to do it at the 
same time that the MG comes into service. 

Sending Restart on Root "cold boot" while already in service would seem 
to indicate an instantaneous reboot.  However, 11.4 "Failure of an MG" 
states: 

"If a MG fails, but is capable of sending a message to the MGC, it sends 
a ServiceChange with an appropriate method (graceful or forced) and 
specifies the Root TerminationID.  When it returns to service, it sends 
a ServiceChange with a "Restart" method." 

So, unless the MG has a very bad failure, wherein it loses its 
capability to message, it will send the Forced AND the Restart.  Keep in 
mind that ServiceChangeReason is optional, with the exception of Handoff 
and Failover, for which the text has several scenarios where it implies 
the Reason should be set. 

Kevin 

Chuong Nguyen wrote: 

> So do we not have 2 ways to indicate a "cold boot" - 
> SC Restart ROOT cold boot 
> SC Forced ROOT cold boot  - This requires a follow-up SC registration 
> - Restart. 
> 
> It seems like if the intend of MG is to do a cold boot, it should go 
> ahead and do 
> a SC Restart w/cold boot instead of doing SC Forced w/ROOT to be 
> followed by 
> SC Restart w/cold boot. 
> 
> Does this also imply that SC Graceful w/ROOT w/delay of 10 sec will 
> work like - 
> After 10 sec, MG is in a cold boot state and send SC Restart w/ROOT to 
> MGC 
> to re-register itself to the same MGC? 
> 
> Somehow I feel like we should leave the Standard as it is. 
> Forced w/a specified termination should work the same as Forced 
> w/ROOT. 
> 
> If someone feels the need to clear out all contexts and go back to 
> cold boot state, 
> they should use Restart w/ROOT cold boot. 
> Especially if Forced w/ROOT has to be followed by Restart w/ROOT. 
> 
> Maybe the clarification should be to use Restart w/ROOT for cold boot 
> and to avoid using Forced w/ROOT if the intend of MG is to indicate 
> cold boot state 
> to MGC. 
> Something is seriously wrong w/MG if it has to do a Forced/ROOT in the 
> first place. 
> Therefore it might as well do Restart w/ROOT and reboot itself instead 
> of Forced w/ROOT 
> and try to keep all states as is. 
> 
> 
> ----- 
> 
> Section 11.4 Failure of an MG 
> If a MG fails, but is capbable of sending a message to the MGC, it 
> sends a 
> ServiceChange with an appropriate method (graceful or forced) and 
> specifies 
> the Root terminationID.  When it returns to to service, it sends a 
> ServiceChange with a "Restart" method. 
> 
> But if SC Forced was like before where MG state is not cold boot, that 
> means 
> Restart w/ROOT has to have the correct Reason so that MGC does not 
> think 
> that MG has cold boot after "Restart"  for Section 11.4 scenario as 
> quoted 
> above. 
> 
> 
> Tom, some earlier draft version, you had a table that showed what 
> combination 
> of Method, termination, context, etc were valid for each ServiceChange 
> scenario. 
> Maybe  we do need one in the IG after all. 
> 
> Chuong 
> 
> 
> "Rosen, Brian" wrote: 
> 
>> As long as we interpret Forced SC on Root to be a reboot, 
>> where the state of the MG is known (same as cold start), then I'm 
>> okay. 
>> If the MG is trying to preserve any state, then I don't think it's 
>> a worthwhile change.  The cost of a subtract * is low. 
>> 
>> Note that I'm implying that the MG needs to reestablish a control 
>> association. 
>> 
>> Brian 
>> 
>> > -----Original Message----- 
>> > From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>> > Sent: Thursday, April 05, 2001 9:45 PM 
>> > To: Kevin Boyle 
>> > Cc: Rosen, Brian; 'Paul Rheaume'; [email-masked]' 
>> > Subject: Re: Context Id in Service Change 
>> > 
>> > 
>> > I support Kevin's view that Forced SC on root should carry the 
>> > assumption that all contexts are cleared. If the MG has 
>> > effectively been 
>> > rebooted then its alot of wasted messaging for the MGC to request 
>> a 
>> > subtract and then return termination not in context. 
>> > All other cases its up to the MGC to subtract the terminations. 
>> > 
>> > How about the following for the implementors' Guide? 
>> > 
>> > 1.44 Clearing Contexts in ServiceChange 
>> > 
>> > Description:  There is confusion as to the handling on subtraction 
>> of 
>> > terminations from a context when a ServiceChange with "forced" 
>> > indication is used. When a ServiceChange "forced" is issued on a 
>> > non-Root termination the MGC is responsible for subsequently 
>> > subtracting 
>> > the termination from the applicable context. When a ServiceChange 
>> > "forced" is issued on the Root termination it is assumed that all 
>> > connection are lost on the MG and thus the MGC can consider 
>> > that all the 
>> > terminations are subtracted. 
>> > 
>> > Reference:    Subject: Re: Context Id in Service Change 
>> > Date: Wed, 04 Apr 2001 19:31:17 -0400 
>> > From: "Kevin Boyle" <[email-masked]> 
>> > Organization: Nortel Networks 
>> > To: "Rosen, Brian" <[email-masked]> 
>> > CC: "'Paul Rheaume'" <[email-masked]>, 
>> "[email-masked]'" 
>> > <[email-masked]> 
>> >  [Begin Correction] 
>> > Section 7.2.8 ServiceChange 
>> > ... 
>> > 2) Forced - indicates that the specified Terminations were taken 
>> > abruptly out of service and any established connections 
>> > associated with 
>> > them may be lost. For non-Root terminations the MGC is responsible 
>> for 
>> > cleaning up the context (if any) with which the failed termination 
>> is 
>> > associated.  At a minimum the termination shall be subtracted from 
>> the 
>> > context.  The termination serviceState should be "out of service". 
>> For 
>> > the root termination the MGC can assume that all connections 
>> > are lost on 
>> > the MG and thus can consider that all the terminations have been 
>> > subtracted. 
>> > 
>> > ... 
>> > [End Correction] 
>> > 
>> > Regards, Christian 
>> > 
>> > Kevin Boyle wrote: 
>> > > 
>> > > I would say that a Forced SC on Root for any reason ought 
>> > to carry the 
>> > > assumption that all contexts are cleared.  This is in line 
>> > with the "boot 
>> > > the MG" comment below, and allows the MGC to recover the MG 
>> > with less 
>> > > messaging when the MG comes back up (that is to say, the 
>> > MGC won't have to 
>> > > send the Context=*,Subtract=* message when the MG comes 
>> > back in service). 
>> > > 
>> > > This should go in the Implementor's Guide, given that "It's an 
>> > > often-misunderstood thing." 
>> > > 
>> > > Kevin 
>> > > 
>> > > "Rosen, Brian" wrote: 
>> > > 
>> > > > Yes, that is right.  It's an often-misunderstood thing. 
>> > > > The MG NEVER takes a termination out of a context 
>> "involuntarily". 
>> > > > It can have all kinds of errors, but the context stays 
>> > > > around, and the termination stays in it until the MGC does 
>> > > > the Subtract. 
>> > > > 
>> > > > The MG can do a ServiceChange on a termination in a context, 
>> > > > even a Forced ServiceChange, but the termination (which would 
>> > > > then be out-of-service) STAYS IN THE CONTEXT. 
>> > > > 
>> > > > Of course if you boot the MG, all bets (contexts) are off :) 
>> > > > 
>> > > > Brian 
>> > > > 
>> > > > > -----Original Message----- 
>> > > > > From: Paul Rheaume [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>> > > > > Sent: Friday, March 30, 2001 2:25 PM 
>> > > > > To: Rosen, Brian 
>> > > > > Cc: [email-masked]' 
>> > > > > Subject: Re: Context Id in Service Change 
>> > > > > 
>> > > > > 
>> > > > > Brian, 
>> > > > > 
>> > > > > One last clarification: 
>> > > > > 
>> > > > > My interpretation of the spec is that it is the 
>> > responsibility of the 
>> > > > > MGC to clean up contexts and terminations and that the 
>> > MG shall never 
>> > > > > remove any context or termination without the explicite 
>> > > > > command to do so 
>> > > > > from the MGC. 
>> > > > > 
>> > > > > Is this correct? 
>> > > > > 
>> > > > > Cheers, 
>> > > > > Paul 
>> > > > > 
>> > > > > "Rosen, Brian" wrote: 
>> > > > > > 
>> > > > > > It's the MGC that should do that, yes. 
>> > > > > > If the MG needed to take the terminations out of service, 
>> > > > > > and they were in a context, and the MG had no way to 
>> > > > > > tell the MGC what was about to happen, I suppose you would 
>> 
>> > > > > > have to use the contextId(s) of the context the 
>> terminations 
>> > > > > > were in to execute the ServiceChange.  The MGC would then 
>> > > > > > have to send the Subtracts. 
>> > > > > > 
>> > > > > > Brian 
>> > > > > > 
>> > > > > > > -----Original Message----- 
>> > > > > > > From: Paul Rheaume [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>> > > > > > > Sent: Thursday, March 29, 2001 12:33 PM 
>> > > > > > > To: Rosen, Brian 
>> > > > > > > Subject: Re: Context Id in Service Change 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > Hi Brian, 
>> > > > > > > 
>> > > > > > > You seem to be saying that the MG should subtract 
>> > > > > terminations from 
>> > > > > > > their context when those terminations go 
>> > out-of-service, but the 
>> > > > > > > protocol clearly states that the MGC is responsible for 
>> > > > > > > cleaning up the 
>> > > > > > > contexts. So I think the subtract should come from the 
>> MGC. 
>> > > > > > > 
>> > > > > > > Am I understanding your statement correctly? 
>> > > > > > > 
>> > > > > > > Cheers, 
>> > > > > > > Paul 
>> > > > > > > 
>> > > > > > > "Rosen, Brian" wrote: 
>> > > > > > > > 
>> > > > > > > > Technically correct. 
>> > > > > > > > 
>> > > > > > > > However, if you were taking terminations out of 
>> > > > > service, it would 
>> > > > > > > > be very wise to subtract them out of whatever 
>> > terminations they 
>> > > > > > > > were in first, then execute the service change to 
>> > take them out 
>> > > > > > > > of service.  It should be possible to do it in 
>> > the other order, 
>> > > > > > > > and it should be possible to leave them in a context, 
>> but 
>> > > > > > > > I wouldn't recommend it! 
>> > > > > > > > 
>> > > > > > > > Brian 
>> > > > > > > > 
>> > > > > > > > > -----Original Message----- 
>> > > > > > > > > From: Christer Holmberg 
>> > > > > [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>> > > > > > > > > Sent: Thursday, March 29, 2001 11:08 AM 
>> > > > > > > > > To: [email-masked] 
>> > > > > > > > > Cc: [email-masked] 
>> > > > > > > > > Subject: Re: Context Id in Service Change 
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > Hi Revital, 
>> > > > > > > > > 
>> > > > > > > > > An MG can use any Context, depending on what is the 
>> > > > > purpose of the 
>> > > > > > > > > Service Change command. 
>> > > > > > > > > 
>> > > > > > > > > For example, if the MG sends ServiceChange to 
>> "register" 
>> > > > > > > itself to the 
>> > > > > > > > > MGC, the NULL Context will be used, but if the 
>> > ServiceChange 
>> > > > > > > > > is sent to 
>> > > > > > > > > indicate that terminations have been taken out 
>> > or service 
>> > > > > > > (or put back 
>> > > > > > > > > in service) you can use an ANY-wilcarded ContextId 
>> value 
>> > > > > > > or a specific 
>> > > > > > > > > ContextId value. 
>> > > > > > > > > 
>> > > > > > > > > Regards, 
>> > > > > > > > > 
>> > > > > > > > > Christer Holmberg 
>> > > > > > > > > Ericsson Finland 
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > [email-masked] wrote: 
>> > > > > > > > > > 
>> > > > > > > > > > Hi List, 
>> > > > > > > > > > 
>> > > > > > > > > > Which Context should the MG use when 
>> > generating Service 
>> > > > > > > > > Change Command? 
>> > > > > > > > > > 
>> > > > > > > > > > Revital Malka 
>> > > > > > > > > > Voice Over IP 
>> > > > > > > > > > E.C.I NGTS 
>> > > > > > > > > > Tel: 03-9287516 
>> > > > > > > > > > Fax: 03-9287010 
>> > > > > > > > > 
>> > > > > > > 
>> > > > > 
>> > 
> 
> -- 
>   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 **** 
> 
>

-- 

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 10 Apr 2001 12:47:31 -0400

Comments inline [KJBII]

Kevin

"Rosen, Brian" wrote:

>      Ok.  It is useful for MG to send Forced w/ROOT if it can
>      before it goes away.
>
>
[KJBII] I agree.

>
>
>           So Kevin, if Forced w/ROOT does not necessary mean cold
>      boot, what Reason
>           I hope MG comes back w/Reason of cold boot.  If MG
>      comes back 2 days later w/warm boot,
[KJBII] I think the reason is largely irrelevant.  The MGC received
Forced on Root.  At some time in the future, the MGC receives Restart on
Root.  I don't see where it matters why the Forced occurred.  Needing to
know the reason why a ServiceChange of a particular method occurred
leads to having to specify exact behavior for every method/reason
combination.  I do not think that we want to head down that road...

>
>           Brian had indicated earlier that warm boot means that
>      MG has kept whatever
>           state it had before Restart and MGC should do an Audit
>      to synch up w/MG.
>
>           We have already decided all contexts are cleared and
>      Forced w/ROOT is an MG failure
>      I agree.  I want to keep forced with Root a full failure of
>      the MG, and require cold boot on restart.
>
[KJBII] Why wouldn't you want to Audit after all Restarts?  I would say
that a full top-to-bottom Audit after a Restart is a wise thing to do,
regardless of the reason for the Restart.

>           It could take days for MG to recover, in the meantime,
>      MGC and MG should
>      I think it should.  That is the difference between failing
>      root and failing ALL.
>
[KJBII] Absolutely.  If Root is not out of service, that should, at a
minimum, indicate that the message processing capability is still intact
in the MG.

>      Didn't we addresss this in the IG?  I though we decided it
[KJBII] I looked at both the approved IG, and the additions version 5,
and did not see this correction.  I do not think it should be mandatory,
however, since Method is not mandatory (changing the
ServiceChangeAddress does not require a Method, if I remember the
discussions correctly.)  Since Method isn't required, how can Reason be
required?  And, as I stated earlier, this leads down the path of
defining behavior for every Method/Reason combination.

>      4) Why did we exclude Graceful w/ROOT?  If after delay timer
>      has expired and MGC
>           did not sent subtract ALL, do we also assume that MG
>      has cleaned up all contexts too?
>
>      I always believed that a graceful with root was followed by
>      a forced on root if the state of the MG was not clean.   The
>      MG is indicating that it is going down.  If the MGC
>      leaves state in the MG, that is a problem.
>
[KJBII] Why wouldn't the Graceful behave like the Forced when the delay
expires?  The MG is going out of service.  It is my understanding that
Graceful is a Forced that can wait for connections to be torn down.  Why
wouldn't the end behavior then be the same?  I think that the expiry of
the Delay parameter for Graceful is the same as executing a Forced at
that moment.