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

From: [email-masked]
Date: Fri, 19 Apr 2002 09:49:34 +0530

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Apr 2002 14:54:54 +1000

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Apr 2002 14:54:54 +1000

G'Day Vikas,

Regards, Christian

---

From: Christer Holmberg <[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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Apr 2002 10:19:30 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 19 Apr 2002 08:19:28 -0500

Per Annex L, 503 and 521 are not used anymore.

Error Code # : 502 Name: Not ready.
Definition: The command directed to a termination was not executed because of the
service state of the termination.

--
  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: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 19 Apr 2002 08:19:28 -0500

---

From: Al Varney <[email-masked]>
Date: Fri, 19 Apr 2002 10:22:04 -0500

>   that MG sends ServiceChange for individual terminations instead of using a

    I have no preference for #1 vs. #2.  I was just pointing out a 
potential advantage of #2.  I was assuming ServiceChange with "ranges" 
identifying only in-service terminations would be used, never a "*" 
wildcard.  If the protocol adopted #2, "*" would obviously loose the 
explicit termination verification at the MGC.

>   with its MGs, it would do an Audit at lesiure in parallel to handling 

    It may happen that a "normal call" could encounter an unusable 
termination prior to the leisurely audit.  Since an MGC has to be prepared 
to handle this case anyway, using approach #1 is certainly simpler for both 
MGC and MG.  But will it meet requirements of applications?

>choose a strategy that is optimal ?

    I agree, the goal is an optimal strategy.  If service provider 
performance requirements heavily penalize connection attempts to OOS 
terminations, then approach #2 is optimal because it allows the MGC to 
start using known-in-service terminations as soon as possible, while 
avoiding failing attempts.  With approach #1, such performance requirements 
would force an MGC to audit terminations before attempting to use them -- 
less optimal than #2, right?

    If the performance requirements are heavily weighted toward reducing 
"down-time" after an MG restart (ignoring how many initial connections 
might fail), then approach #1 is obviously optimal.

    An unfortunate side-effect of doing only protocol development, rather 
than services development, is that we don't know the requirements of the 
service providers.  An optimal strategy for the protocol may be non-optimal 
for the application.

Al Varney

---

From: Al Varney <[email-masked]>
Date: Fri, 19 Apr 2002 10:22:04 -0500

Al Varney

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 19 Apr 2002 11:47:18 -0400

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.

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

--

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

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 19 Apr 2002 11:47:18 -0400

Christian

--

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Fri, 19 Apr 2002 12:21:42 -0400

This proposal sounds good. But to make it absolutely unambiguous you
could specify:

"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 Service State ("in service").  Exceptions can be
indicated by additional ServiceChange commands."
^^^^^^^

-- Bala

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Terry L Anderson
Sent: Friday, April 19, 2002 11:47 AM
To: Christian Groves
Cc: [email-masked]; Al Varney; [email-masked]
Subject: Re: [Megaco] ServiceChange for a single termination (Cold
Start)

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.

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

> terminaton is "inservice". If the MG cold starts and sends 
> ServiceChange on "ROOT" then the MGC can assume
> that:
> >        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
> > 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
> > {Assuming most of the terminations in MG would be In Service, n 
> > could be a large value unless
> > 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)
> >
> > Subject:  Re: [Megaco] ServiceChange for a single termination (Cold

> > Start)
> > >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.)
> >
> >     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
> >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
>

--

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Fri, 19 Apr 2002 12:21:42 -0400

-- Bala

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

Christian

--

---

From: Sankar Raman <[email-masked]>
Date: Fri, 19 Apr 2002 13:14:24 -0400

Terry:

In my expereince working with different swicthes and gateways,
typical internal implementation of these boxes are such that when
the box comes up, all T1 lines are asumed down untill they come up
in which case the T1 framer chip notifies this event to the upper layers.
Typical implementation is such that when the T1 hardware is reset, no
events will be generated until a line comes up. Line down evets are
generated by T1 hardware only if the line was up before.
This means, if a MGC asssumes on registation, that all lines are up, and
if certain do not come up at the MG, the MG will not be able to indicate
this to
the MGC, unless the MG implelements periodic polling of some sort. 

I feel, it is better, that default state for physical terminations,
when MGC registers with ROOT in service, should be out of service.
Upon registration, the MGC assumes all lines are down until explicitly
indicated
by service change by the MG for the physical lines. As lines come up
at the MG, the MG will send svcchg in svc for each as it happens.
This will be simpler for MGs and go with their typical internal
implementation.
(although it may generate more traffic which can be cut down by using wildcard
for the lines).

Also, this way MGs do not have to worry about how long should it wait for
all lines
to come up before registering with MGC. Some lines may never come up due to
some
fault at the far end switch or may come up much later than some other lines.

>"When applied to ROOT, this specifies that the Media Gateway as a whole
will be in
>There has been previous discussions about the applicability of
ServiceChange for
>(availability of any underlying network or gateway resources).  I think
that the
>I think we currently have no good way to announce that the MG is in
service but one or

>> >   that MG sends ServiceChange for individual terminations instead of
using a
>> >   Sending ServiceChange for individual terminations would be too
expensive in
>> >   with its MGs, it would do an Audit at lesiure in parallel to
handling normal
>> > Even if we go by approach #2 suggested below, the latter step (i.e.
sending
>> > ServiceChange commands each with a Termination Id (tg1/fac1/*) that
siginfies a
Start)

>> > >Even though I think that most GWs probably would not register until
all or

---

From: Sankar Raman <[email-masked]>
Date: Fri, 19 Apr 2002 13:14:24 -0400

Terry:

 

will be in
ServiceChange for
that the
service but one or

using a
expensive in
handling normal
sending
siginfies a
Start)

all or

---

From: Root Mean Square <[email-masked]>
Date: Fri, 19 Apr 2002 19:00:00 -0400

Sankar,

I think I agree with everything you said.  In our case we have
administrative and operational states for individual interfaces as well as
the gateway as a whole.  If the administrative state of the MG is enabled,
it will attempt to register with the MGC as soon as the MG cold starts.
Individual interfaces may be adminsitratively disabled, or may be in an
alarm or offline condition (e.g., physically removed from the chasis).
Also, most of our interfaces are intelligent peripherals that need to
download their code image after a cold start, and this may take several
seconds, so they do not come online immediately.  We could wait several
seconds after a cold start before attempting to register with the MGC, but
we still need to deal with interfaces that are administratively disabled,
are temporarily out-of-service or have fault conditions pending.

I understand that it would be optimal if the MG only had to send a single
service change on root if all of its terminations are in-service and
operational when it registers with the MGC.  However, making the default
service state in-service has always seemed a little goofy to me.  If the
default state were out-of-service, it may not reflect reality when the MG
sends its initial service change on root, but it doesn't have any adverse
side effects.  On the other hand, making the default state in-service does.

Making the default termination state out-of-service would seem to be more
consistent with how large media gateways in fact operate -- that is, the
service state of the signaling path between the MG and MGC is independent of
the service state of individual terminations.  Using a technique similar to
what Terry Anderson proposes may overcome most of the inefficiences
associated with having to register interfaces or terminations as they come
into service.  In our particular case, I would prefer to establish an
association with the MGC, negotiate the protocol version and profile, and
then deal with which terminations are in-service or not.  I don't think this
can be cleanly done with a single service change command on root -- perhaps
on a residential GW with a couple of terminations, but not on a large
trunking GW with 1000's of terminations.

Cheers,
Ron Stoughton

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sankar Raman
> Sent: Friday, April 19, 2002 1:14 PM
> To: Terry L Anderson; Christian Groves
> >Good point.  I missed the relevance of the ServiceState property
> in 7.1.5.
>  There is
> >precisely the same as ServiceChange forced and restart (maybe it
> should be
> for a
> >valid terminationIDs for the GW.  Packages have been proposed
> (but not yet
> approved)
> >more classes of ephemerals are unavailable.  I think that a
> specific error
> to indicate
> >> If the MG cold starts and sends ServiceChange on "ROOT" then
> the MGC can
> assume
> >> that:
> >> >  IMHO, "ServiceChange on ROOT" should indicate all
> terminations are up
> at the
> >> > MG.
> >> > >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
> >> > days, until the MGC attempted to use/audit that particular
> termination
> ID.
> >> >

---

From: Root Mean Square <[email-masked]>
Date: Fri, 19 Apr 2002 19:00:00 -0400

Sankar,

Cheers,
Ron Stoughton

---

From: Christian Groves <[email-masked]>
Date: Mon, 22 Apr 2002 10:51:02 +1000

G'Day,

In both H.248/Megaco v1 and v2 we have sect 7.1.5 stating that the default is
"in-service". I think now it is too late to change this to "inactive". It would
be a backwards incompatible change. Whilst not everyone will like it because
they have either big or small MG/MGCs, we had chosen to go done the "in-service"
path. 

The MGC can discover what terminations are on the MG by other means ie.
Provisioning, MIB or via the termination package.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 22 Apr 2002 10:51:02 +1000

G'Day,

Regards, Christian