Subject: Re: [Megaco] How MGC to Put a Trunk Group out of Service Gracefully?

From: Christian Groves <[email-masked]>
Date: Fri, 01 Mar 2002 10:46:11 +1100

G'Day,

I don't see why we need new syntax for this??? A solution was proposed
to use 2 servicechanges which is relatively clean. Kevin added that you
could put it in the same command. I could buy the "not efficient"
argument if this was used in normal traffic cases but this isn't used
very often.

Regards, Christian

"Zhang, Yuyong" wrote:
> 
> G'day, Tom and list!
> 
> I agree with you in general that a syntax change should be done in the new
> version of the protocol to avoid the irregularity of the protocol. Maybe in
> the V3, we should consider the possibility to allow operation on
> terminations regradles of the context for applications such as the Trunk
> Group operations.
> 
> Is there any other way for a MGC to block a Trunk group other than the one
> mentioned in this thread? Trunk Group Blocking is a basic and normal
> procedure for PSTN trunks, shouldn't we have some clean procedures in MEGACO
> to do that?
> 
> Please advice!
> 
> Regards,
> 
> Yuyong
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 12:32 PM
> To: 'Zhang, Yuyong'; Kevin Boyle; [email-masked]'
> Subject: RE: [Megaco] How MGC to Put a Trunk Group out of Service
> Graceful ly?
> 
> At the moment this just looks like hacking: continuing in this direction
> would produce a very irregular protocol.  Is there a more general
> requirement here to operate on a given termination regardless of the context
> it is in?
> 
> Something new in the way of syntax would have to wait now until
> Megaco/H.248v3.
> 
> -----Original Message-----
> From: Zhang, Yuyong [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 3:21 PM
> To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Zhang, Yuyong; Taylor, Tom-PT
> [CAR:B800:EXCH]; [email-masked]'
> Subject: RE: [Megaco] How MGC to Put a Trunk Group out of Service Graceful
> ly?
> 
> Hi there,
> 
> Though it works to send both to block a Trunk Group, but from a MG
> implementation, it is not efficient to go through NULL contxt and all the
> active contexts to find out CICs in the Trunk Group.
> 
> Let's look at the possible Trunk Group operations a MGC can ask MG to do.
> 
> Forced or Graceful
>      MGC want to block a Trunk Group either forced or Graceful. In this
> case, MG does not care what the context MGC used in
>      the Message. The operation implies what a MG should do. If a CIC is in
> an active context, then MG block it if is forced. Or
>      wait for clearance then blocked it if it is Graceful.
> 
> Restart
>      To restart a Trunk Group, the trunk group has to be blocked previously.
> Therefore, all the CiCs has to be in NULL context.
> 
> As a conclusion, we can define a message scheme for Trunk Group Blocking as
> the following:
> 
> 1. Forced  or Graceful, the context (NULL or ALL) are insignificant to MG,
> MG should use the operation and the Trunk Group
>     Information to process.
> 2. Restart, the context has to be NULL.
> 
> Please give your thoughts.
> 
> Regards,
> 
> Yuyong
> 
> 
> -----Original Message-----
> From: Kevin Boyle [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 8:02 PM
> To: Zhang, Yuyong; Tom-PT Taylor; [email-masked]'
> Subject: RE: [Megaco] How MGC to Put a Trunk Group out of Service Graceful
> ly?
> 
> Why wouldn't you send both in the same transaction?  Then you would have
> covered both cases.
> Kevin
> -----Original Message-----
> From: Zhang, Yuyong [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 9:27 PM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]'
> Subject: [Megaco] How MGC to Put a Trunk Group out of Service
> Gracefully?
> 
> Hi Folks,
> I have a question about how a MGC to put a Trunk Group out Service
> Gracefully.
> There are two options I see as the following:
> Context = - {
>                   ServiceChange = TG1/* {
>                         ServiceMethod = Gracefully}
>                }
> Context = * {
>                   ServiceChange = TG1/* {
>                         ServiceMethod = Gracefully}
>                }
> Since it is the graceful, that means MGC want to put the trunk out of
> service as soon as all the contexts are cleared on this Trunk Group.
> My question is that some of the CICs in the Trunk gourp has an active
> context, some of them doesn't. Therefore the first option above doesn't take
> 
> care of those who have active contexts, the second option doesn't take care
> of those who doesn't have active context.
> What is the solution here? Oh this kind of graceful blocking a trunk group
> is not supported in MEGACO.
> Please give your comments.
> Regards,
> Yuyong
> _______________________________________________
> 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

---

From: Christian Groves <[email-masked]>
Date: Fri, 01 Mar 2002 10:46:11 +1100

G'Day,

Regards, Christian

---

From: Al Varney <[email-masked]>
Date: Fri, 01 Mar 2002 08:23:04 -0600

> > active contexts to find out CICs in the Trunk Group.

    I don't see how this particular inefficiency ranks very high; look at 
all the messaging needed to set up a line origination!  Christian's right 
-- trunk group blocking is rare and unencumbered by any real-time response 
requirement.  You have to deal with the race conditions where the far end 
initiates calls or blocks/unblocks trunks while you are blocking/unblocking 
trunks anyway.

    Two other observations:

1)  You mentioned "CICs", implying ISUP/BICC protocol trunks.  Such trunks 
use SS7 messaging to block/unblock trunks.  There is (with rare exception) 
no need to change any state on idle (or soon-to-be-idled) trunks that are 
blocked using ISUP.  And BICC CICs are ephemeral (but can be blocked).

2)  Traditional implementations (I know, a permanent Bell-head) of trunks 
dis-associate members of Trunk Groups from the physical termination 
numbering scheme.  Mapping this scheme to an MG means the MG has no 
knowledge of trunk groups, only physical terminations.  Blocking of such 
non-ISUP Trunk Groups requires sending messages for each termination 
(because the MG only knows about terminations, not group membership.

    Only if you let the MG operate using Trunk Group members as the 
termination names, and allow it (rather than the MGC) to select trunk 
members for new outgoing calls, would you need to inform the MG of blocked 
ISUP trunks.  But then you have to wait on the MG to respond in order to 
know which CIC will be used for the outgoing IAM.  This will add to the 
delay before the IAM can be sent, and increases the possibility of glare.

  ...

---

From: Al Varney <[email-masked]>
Date: Fri, 01 Mar 2002 08:23:04 -0600

Two other observations:

  ...

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Fri, 01 Mar 2002 21:13:18 +0530

> initiates calls or blocks/unblocks trunks while you are blocking/unblocking

All the same, it would be nice to have a mechanism to control a
device/termination irrespective of the call/context it is in - i.e., a 'dont
care' context option, while operating on a termination. I think this would still
be consitent with the megaco protocol model too.

>     Two other observations:

some comment in-line

> blocked using ISUP.  And BICC CICs are ephemeral (but can be blocked).

Blocking/unblocking isup msgs are used to let the far-end know of the state
change of the near end bearer ckts or other such equivalent maintenance actions.
So if the blocking/unblocking is initiated by the near-end MGC, we'd need to mark
the corresponding bearer ckts at the near-end appropriately, and subsequently
issue the blocking/unblocking isup message to the far end (for eg via the
backhauling - m3ua, path). To 'mark' the corresponding bearer-ckts at the
near-end appropriately, the MGC would need to communicate this bearer ckt state
change info to the MG via megaco - not sure how/why there could/should be two
ways about this.

> (because the MG only knows about terminations, not group membership.

Not necessarily - even if the MG instance is only aware of the physical
termination numbering scheme, the mapping of received trunk group info (via
wildcarding or otherwise) to the physical numbering scheme can be accomplished
via appropriately provisoned lookup and mapping functions/tables at the MG. This
is assuming the crafts-person provisions the interpretation of the trunk group
naming scheme at the MGC and MG consistently. I would assume that, this is *one*
of the reasons why the termination ID wildcarding option is provided in megaco.
An implementation that does not allow for such a mapping of provisioned info,
imo, severely lacks flexibility.

> ISUP trunks.

Strictly speaking MG shouldnt be aware of any trunk group or related information
- for the MG its a termination or a group of terminations. As I mentioned above,
its upto an implementation specific mapping function that should derive the
mapping of the received wildcarded trunk group information to a group of
terminations that the MG can operate on.

> But then you have to wait on the MG to respond in order to

> delay before the IAM can be sent, and increases the possibility of glare.

Most MGC implementations, would move the CIC to a transient state (for eg,
PENDING_MANUAL_BSY) while awaiting a response. This would help prevent increase
of  the glare window size

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Fri, 01 Mar 2002 21:13:18 +0530

some comment in-line

---

From: Al Varney <[email-masked]>
Date: Sat, 02 Mar 2002 17:51:59 -0600

At 09:13 PM 3/1/02 +0530, Ranjith Mukundan wrote:
>device/termination irrespective of the call/context it is in - i.e., a 
>'dont care' context option, while operating on a termination. I think this 
>would still be consitent with the megaco protocol model too.

    I could support the advantage of a non-Context termination address 
mechanism (useful as well for individual terminations and with Audit?).  My 
comments were solely on the ISUP Trunk Group Blocking application of this 
proposed mechanism.

>Blocking/unblocking isup msgs are used to let the far-end know of the 
>state change of the near end bearer ckts or other such equivalent 
>maintenance actions. So if the blocking/unblocking is initiated by the 
>near-end MGC, we'd need to mark the corresponding bearer ckts at the 
>near-end appropriately, and subsequently issue the blocking/unblocking 
>isup message to the far end (for eg via the backhauling - m3ua, path). To 
>'mark' the corresponding bearer-ckts at the near-end appropriately, the 
>MGC would need to communicate this bearer ckt state change info to the MG 
>via megaco - not sure how/why there could/should be two ways about this.

    If the "blocking" status is kept in the MGC (as I believe it should 
be), what does the MG do with a "ServiceChange=Gracefully" request?  For 
ISUP trunks, no physical change occurs for either idle or in-use 
terminations.  In essence, there is no need to notify the MG of ISUP trunk 
blocking (it all happens in the MGC).

    For per-channel-signalled trunks (MF, DP, DTMF), the MG does apply a 
state change to idle trunks in order to inform the distant device that the 
trunk is not available.  So your ServiceChange would be needed for these.

>termination numbering scheme, the mapping of received trunk group info 
>(via wildcarding or otherwise) to the physical numbering scheme can be 
>accomplished via appropriately provisoned lookup and mapping 
>functions/tables at the MG. This is assuming the crafts-person provisions 
>the interpretation of the trunk group naming scheme at the MGC and MG 
>consistently. I would assume that, this is *one* of the reasons why the 
>termination ID wildcarding option is provided in megaco. An implementation 
>that does not allow for such a mapping of provisioned info, imo, severely 
>lacks flexibility.

    I had not considered the MG could have multiple means of identifying a 
given termination.  Interesting concept -- might be useful for maintenance.

>PENDING_MANUAL_BSY) while awaiting a response. This would help prevent 
>increase of  the glare window size.

    I was unclear, it seems; wasn't talking about delay during 
blocking.  Rather, if the MG selected, for new calls, outgoing ISUP 
terminations from a pool of idle terminations, the MGC would not know the 
CIC until the MG responded with the specific termination information.  If 
the MGC selects such terminations, this is not an issue.

Al Varney

---

From: Al Varney <[email-masked]>
Date: Sat, 02 Mar 2002 17:51:59 -0600

Al Varney

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Sun, 03 Mar 2002 05:31:17 +0530

comments in-line...

> comments were solely on the ISUP Trunk Group Blocking application of this

I  agree - for isup trunk group blocking, the current context specific (- or *)
address mechanism would suffice entirely. Albeit, it wouldnt be the most efficient
of means (processing-wise, esp in case of 'forceful' methods) to search around for
contexts when there can be a flurry of events to handle during maintenance (even
if it happens once in a while) - esp, if the MG houses a composite MG/SG
functionality.

I was more coming from a general perspective, where its not intutitve to correlate
a context to a termination - for eg, you would want to perform a broadcast (of
some announcement/tone) on a set of terminations thats configured as permanent
(nailed-up) lines. Even more pertinent, if these permenent terminations are
configured as part of a separate virtual MG (on the same physical MG) - which you
may want to do, becasue the resource requirement of a permanent line is different
from those of other lines/terminations. Please note that, in case of permanent
lines, you wouldnt really need to know of the context (null or active) the
termination is in, as the treatment would be the same.

> be), what does the MG do with a "ServiceChange=Gracefully" request?

It could, for instance,
   - remove all resources (like the COT detectors) allocated to the bearer ckts in
oos. please note that the mips i save on de-allocating a dsp resource like the
cot-detector can be used to reduce the service blocking that could result due to
lack of dsp resources for specific dsp intensive services made available on other
terminations.
   - stop detecting any events and its subsequent reporting to the MGC - esp, in
the event that the far end exchange delays in honouring the blocking msg sent from
the near end ( its not so pronounced in case of 'graceful' method as much as it
would be in the case of 'forced' method). Especially, in case of some country
variants, these intentional delays are really pronounced.

> For

I agree - there would be no physical change. But as i mentioned, it helps if the
MG is made aware of the logical state change happening to the bearer ckts, as MG
is the entity that manages, allocates, deallocates resources for the bearer ckts -
which has a bearing on the logical state the ckt is in.

yes, it would, as you observe, indeed be needed for the CAS trunks too.

> given termination.  Interesting concept -- might be useful for maintenance.

...AND for some broadcast scenarios too...

> the MGC selects such terminations, this is not an issue.

OK. I understand the reasoning behind how the glare window would increase if the
tdm termination selection is done at the MG and reported back to MGC. But I still
fail to comprehend as to how this has a bearing on whether or not you decide to
send a service change (= gracefully or otherwise) from the MGC to the MG - aren't
they mutually independent? May be i am missing something fundamental....

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Sun, 03 Mar 2002 05:31:17 +0530

comments in-line...

It could, for instance,

---

From: Al Varney <[email-masked]>
Date: Mon, 04 Mar 2002 02:19:18 -0600

At 05:31 AM 3/3/02 +0530, Ranjith Mukundan wrote:
>OK. I understand the reasoning behind how the glare window would increase 
>if the tdm termination selection is done at the MG and reported back to 
>MGC. But I still fail to comprehend as to how this has a bearing on 
>whether or not you decide to send a service change (= gracefully or 
>otherwise) from the MGC to the MG - aren't they mutually independent? May 
>be i am missing something fundamental....

    I just haven't heard a reason for ISUP terminations on an MG to "be 
aware" of a blocking condition.  I don't think you can remove your DSP 
resources (blocked ISUP trunks can still carry test calls with COT 
requested -- a common means of verifying circuit operation prior to 
unblocking trunks).  Nor can the MG stop reporting events regarding these 
terminations (a carrier alarm must be signaled even for blocked trunks).

    Perhaps the condition you want from "service change" is an OUT OF 
SERVICE/DISABLED state, common during repair/removal of physical 
circuits?  (If ISUP, these circuits would first be Blocked.)

    But we're rambling off-Subject here.  I agree a means of addressing 
terminations without Context knowledge could be useful (version 3?).

Al Varney

---

From: Al Varney <[email-masked]>
Date: Mon, 04 Mar 2002 02:19:18 -0600

Al Varney