Subject: Service State [Fwd: Re: [Megaco] ServiceChange for a single termination (Cold Start)]

From: Christian Groves <[email-masked]>
Date: Tue, 28 Mar 2006 15:32:01 +1000

Hello all,

As a follow up of the recent discussion on the default value of Service 
State, I believe this was discussed back in 2002. Please see attached 
email.

Regards, Christian

-------- Original Message --------
Subject: 	Re: [Megaco] ServiceChange for a single termination (Cold Start)
Date: 	Fri, 19 Apr 2002 11:47:18 -0400
From: 	Terry L Anderson <[email-masked]>
Organization: 	Lucent Technologies
To: 	Christian Groves <[email-masked]>
CC: 	[email-masked], Al Varney <[email-masked]>, [email-masked]
References: 	<[email-masked]> 
<[email-masked]>

Christian
Good point.  I missed the relevance of the ServiceState property in 7.1.5.  There is
states that "in service" is default.  While Service State is not defined to be
precisely the same as ServiceChange forced and restart (maybe it should be for a
termination), I agree that this default indicates the intention defaulting to
inservice.  Thus I think that my assumption #1 is the more consistent.  I still think
that the link between ServiceState and ServiceChange for a termination is ambiguous
enough that it would be helpful to restate the assumption in 7.2.8.

I propose we add the following to 7.2.8 at the end of the current Restart entry:

"When applied to ROOT, this specifies that the Media Gateway as a whole will be in
service and includes all its physical terminations which will be in their default
state ("in service").  Exceptions can be indicated by additional ServiceChange
commands."

As Vikas points out, most uses of wildcard ALL assumes that MGC knows the range of
valid terminationIDs for the GW.  Packages have been proposed (but not yet approved)
for MGC to discover this range if it is not known from provisioning.  Sending
individual (non-wildcard) ServiceChange for every distinct physical termination would
be legal but impractical for most large MGs.

Al Varney asked:

>  Is there an assumption that MG SVC(ROOT,restart) implies the ephemeral
> interface(s) are all operational?  If it makes sense to positively assert
> SVC(restart) on physical terminations, why wouldn't it also make sense to
> indicate availability of ephemeral interfaces?  I'm thinking particularly
> of MGs with multiple ephemeral interfaces (IP, ATM, etc.).
>

There has been previous discussions about the applicability of ServiceChange for
ephemerals.  While there is nothing stating that one could not use ServiceChange to
take an ephemeral out of service, but since it would then be subtracted from any
context it was in, it would cease to exist and so could never be "restarted".  Clearly
serviceChange cannot be used to indicate whether an ephemeral Add will succeed or not
(availability of any underlying network or gateway resources).  I think that the
assumption is that if a GW is in service then any ephemeral Add can be attempted.
Failure of an underlying network can be indicated using nt/netfail, but since events
are only set on terminations, one must Add an ephemeral before such an event can be
used.

I think we currently have no good way to announce that the MG is in service but one or
more classes of ephemerals are unavailable.  I think that a specific error to indicate
this after an Add attempt might be sufficient (I don't believe that there is a good
one now).

Christian Groves wrote:

> G'Day Vikas,
>
> I believe you are getting what you asked for. The default state of all
> terminaton is "inservice".
> If the MG cold starts and sends ServiceChange on "ROOT" then the MGC can assume
> that:
> o as the MG is running and
> o a MG contains terminations and
> o the termination's natural state is "inservice"
> therefore the individual terminations are running also.
>
> Regards, Christian
>
> [email-masked] wrote:
> >
> > Al,
> >        The advantage you have cited below will hold true only under the
> > assumption
> >   that MG sends ServiceChange for individual terminations instead of using a
> > wildcard.
> >   Sending ServiceChange for individual terminations would be too expensive in
> > terms
> >   of network bandwidth as well as MG processing for extremely large sized
> > Gateways.
> >   I would expect that if MGC is interested in finding out configuration
> > inconsistencies
> >   with its MGs, it would do an Audit at lesiure in parallel to handling normal
> > calls.
> >
> >  IMHO, "ServiceChange on ROOT" should indicate all terminations are up at the
> > MG.
> >  ServiceChange for Out Of Service Terminations can be sent subsequently. Total
> > number of messages required in this scenario would be
> > (1 ServiceChange on ROOT + x ServiceChange for configured but unequipped
> > terminations)
> >
> > Even if we go by approach #2 suggested below, the latter step (i.e. sending
> > ServiceChange
> > for Out Of Service Terminations) will anyway have to be executed.
> >  Subsequent to a ServiceChange on ROOT, if MG uses Wildcarded Termination Id
> > to indicate that all terminations in the MG are In Service, it will need to send
> >  Out of Service ServiceChange for those terminations that have been configured
> >  but not hardware equipped. The number of messages required in this scenario
> > would be
> >
> > (1 ServiceChange on ROOT + 1 ServiceChange with Termination Id "*"+ n
> > ServiceChange
> >   for configured but unequipped terminations (Term Id = "/TG!/Fac1/*))
> >
> > The MG may of course choose not to use a wildcarded
> > termination signifiying all terminations on the MG and instead use multiple
> > ServiceChange commands each with a Termination Id (tg1/fac1/*) that siginfies a
> > DS0 aggregation. In this case, the number of ServiceChange commands would equal
> > the number of such DS0 aggregations in the MG i.e. several ServiceChange
> > messages
> >  would be needed to complete the initial MG-MGC startup sequence. The number of
> >  messages required in this scenario would be
> >
> > (1 ServiceChange on ROOT + n ServiceChange for configured and equipped
> > terminations
> >     (Term Id = "/TG!/Fac1/*))
> >
> > {Assuming most of the terminations in MG would be In Service, n could be a large
> > value unless
> >   the MG is intelligent and can optimize on the number of messages}
> >
> > To summarize, IMO that number of (ServiceChange) messages required at startup
> >  would turn out to be larger in approach #2 than in approach #1. So, why not
> > choose
> >  a strategy that is optimal ?
> >
> > Rgds,
> >
> > Vikas Bajaj
> > NGN Group
> > Hughes Software Systems
> > (www.hssworld.com)
> >
> > Al Varney <[email-masked]> on 04/19/2002 04:59:53 AM
> >
> > To:   [email-masked]
> > cc:    (bcc: Vikas Bajaj/HSS)
> >
> > Subject:  Re: [Megaco] ServiceChange for a single termination (Cold  Start)
> >
> > At 02:46 PM 4/18/02 -0400, Terry L Anderson wrote:
> > >Possible clarifications:
> > >ServiceChange on ROOT with method=restart (a registration):
> > >1) implies that all physical terminations on MG are also up.  Exceptions
> > >should be indicated by additional ServiceChanges on the down terminations
> > >using Forced, preferrably in the same message and using wildcards where
> > >possible.
> > >2) implies that all physical terminations on MG are down.  Those that are up
> > >will be indicated by additional ServiceChanges on the up terminations using
> > >method=restart, preferrably in the same message and using wildcards were
> > >possible.
> >
> > ...
> >
> > >Even though I think that most GWs probably would not register until all or
> > >most of their physical terminations are available, I would probably prefer
> > >#2 since I can easily indicated them all up with only one additional
> > >ServiceChange and it seems more natural to indicate those up those that are
> > >down.  But I can be happy with either #1 or #2.
> >
> >     #2 has the added (slight?) advantage that physical termination ID
> > mis-matches (between MGC and MG) are identified when the MG sends
> > SVC(restart) on a termination ID unknown to the MGC.  #1 relies on MGC
> > discovering these (non-existent) terminations 1 at a time, when connections
> > are attempted.  With #1, a mis-match of this type might go undetected for
> > days, until the MGC attempted to use/audit that particular termination ID.
> >
> >     Terminations known only to the MGC will still go "undetected", but
> > since no SVC(restart) is ever received for them, at least the MGC would not
> > be trying to use them.  An audit might eventually reveal the reason for the
> > OOS terminations.  (It is not unusual in "old" voice switches to have
> > termination data populated without having the hardware yet in place, so a
> > mis-match cannot be considered an error in all cases.)
> >
> >     Is there an assumption that MG SVC(ROOT,restart) implies the ephemeral
> > interface(s) are all operational?  If it makes sense to positively assert
> > SVC(restart) on physical terminations, why wouldn't it also make sense to
> > indicate availability of ephemeral interfaces?  I'm thinking particularly
> > of MGs with multiple ephemeral interfaces (IP, ATM, etc.).
> >
> >     Assuming a reasonable SVC mechanism with "ranges" exists, #2 is not a
> > big burden after MG restart.  If SVC is needed for every individual
> > physical termination, then #1 becomes attractive.
> >
> > Al Varney
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

--

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

Subject: Re: [Megaco] ServiceChange for a single termination (Cold Start)
From: Christer Holmberg <[email-masked]>
To: Christian Groves <[email-masked]>
Cc: [email-masked], Al Varney <[email-masked]>, [email-masked]
Date: Fri, 19 Apr 2002 10:19:30 +0300

Hi,

Ok, so assuming that ROOT is enough to indicate that all Terminations are
"in-service", what error code shall the MG use if the MGC tries to use a termination
which still isn't ready to be used (but WILL be in eg 10 seconds)? 503? 521?

Regards,

Christer Holmberg
Ericsson Finland

Christian Groves wrote:

> G'Day Vikas,
>
> I believe you are getting what you asked for. The default state of all
> terminaton is "inservice".
> If the MG cold starts and sends ServiceChange on "ROOT" then the MGC can assume
> that:
> o as the MG is running and
> o a MG contains terminations and
> o the termination's natural state is "inservice"
> therefore the individual terminations are running also.
>
> Regards, Christian
>
> [email-masked] wrote:
> >
> > Al,
> >        The advantage you have cited below will hold true only under the
> > assumption
> >   that MG sends ServiceChange for individual terminations instead of using a
> > wildcard.
> >   Sending ServiceChange for individual terminations would be too expensive in
> > terms
> >   of network bandwidth as well as MG processing for extremely large sized
> > Gateways.
> >   I would expect that if MGC is interested in finding out configuration
> > inconsistencies
> >   with its MGs, it would do an Audit at lesiure in parallel to handling normal
> > calls.
> >
> >  IMHO, "ServiceChange on ROOT" should indicate all terminations are up at the
> > MG.
> >  ServiceChange for Out Of Service Terminations can be sent subsequently. Total
> > number of messages required in this scenario would be
> > (1 ServiceChange on ROOT + x ServiceChange for configured but unequipped
> > terminations)
> >
> > Even if we go by approach #2 suggested below, the latter step (i.e. sending
> > ServiceChange
> > for Out Of Service Terminations) will anyway have to be executed.
> >  Subsequent to a ServiceChange on ROOT, if MG uses Wildcarded Termination Id
> > to indicate that all terminations in the MG are In Service, it will need to send
> >  Out of Service ServiceChange for those terminations that have been configured
> >  but not hardware equipped. The number of messages required in this scenario
> > would be
> >
> > (1 ServiceChange on ROOT + 1 ServiceChange with Termination Id "*"+ n
> > ServiceChange
> >   for configured but unequipped terminations (Term Id = "/TG!/Fac1/*))
> >
> > The MG may of course choose not to use a wildcarded
> > termination signifiying all terminations on the MG and instead use multiple
> > ServiceChange commands each with a Termination Id (tg1/fac1/*) that siginfies a
> > DS0 aggregation. In this case, the number of ServiceChange commands would equal
> > the number of such DS0 aggregations in the MG i.e. several ServiceChange
> > messages
> >  would be needed to complete the initial MG-MGC startup sequence. The number of
> >  messages required in this scenario would be
> >
> > (1 ServiceChange on ROOT + n ServiceChange for configured and equipped
> > terminations
> >     (Term Id = "/TG!/Fac1/*))
> >
> > {Assuming most of the terminations in MG would be In Service, n could be a large
> > value unless
> >   the MG is intelligent and can optimize on the number of messages}
> >
> > To summarize, IMO that number of (ServiceChange) messages required at startup
> >  would turn out to be larger in approach #2 than in approach #1. So, why not
> > choose
> >  a strategy that is optimal ?
> >
> > Rgds,
> >
> > Vikas Bajaj
> > NGN Group
> > Hughes Software Systems
> > (www.hssworld.com)
> >
> > Al Varney <[email-masked]> on 04/19/2002 04:59:53 AM
> >
> > To:   [email-masked]
> > cc:    (bcc: Vikas Bajaj/HSS)
> >
> > Subject:  Re: [Megaco] ServiceChange for a single termination (Cold  Start)
> >
> > At 02:46 PM 4/18/02 -0400, Terry L Anderson wrote:
> > >Possible clarifications:
> > >ServiceChange on ROOT with method=restart (a registration):
> > >1) implies that all physical terminations on MG are also up.  Exceptions
> > >should be indicated by additional ServiceChanges on the down terminations
> > >using Forced, preferrably in the same message and using wildcards where
> > >possible.
> > >2) implies that all physical terminations on MG are down.  Those that are up
> > >will be indicated by additional ServiceChanges on the up terminations using
> > >method=restart, preferrably in the same message and using wildcards were
> > >possible.
> >
> > ...
> >
> > >Even though I think that most GWs probably would not register until all or
> > >most of their physical terminations are available, I would probably prefer
> > >#2 since I can easily indicated them all up with only one additional
> > >ServiceChange and it seems more natural to indicate those up those that are
> > >down.  But I can be happy with either #1 or #2.
> >
> >     #2 has the added (slight?) advantage that physical termination ID
> > mis-matches (between MGC and MG) are identified when the MG sends
> > SVC(restart) on a termination ID unknown to the MGC.  #1 relies on MGC
> > discovering these (non-existent) terminations 1 at a time, when connections
> > are attempted.  With #1, a mis-match of this type might go undetected for
> > days, until the MGC attempted to use/audit that particular termination ID.
> >
> >     Terminations known only to the MGC will still go "undetected", but
> > since no SVC(restart) is ever received for them, at least the MGC would not
> > be trying to use them.  An audit might eventually reveal the reason for the
> > OOS terminations.  (It is not unusual in "old" voice switches to have
> > termination data populated without having the hardware yet in place, so a
> > mis-match cannot be considered an error in all cases.)
> >
> >     Is there an assumption that MG SVC(ROOT,restart) implies the ephemeral
> > interface(s) are all operational?  If it makes sense to positively assert
> > SVC(restart) on physical terminations, why wouldn't it also make sense to
> > indicate availability of ephemeral interfaces?  I'm thinking particularly
> > of MGs with multiple ephemeral interfaces (IP, ATM, etc.).
> >
> >     Assuming a reasonable SVC mechanism with "ranges" exists, #2 is not a
> > big burden after MG restart.  If SVC is needed for every individual
> > physical termination, then #1 becomes attractive.
> >
> > Al Varney
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

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