Subject: Connection Changes At MG (was Basic Package and NAS)

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 12 Oct 1999 21:07:49 -0400

I see APC-1744 has been submitted to address the matter of MG-notified loss
of connection.  I have also heard requests for the MG to be able to notify
an MGC that a connection has changed, possibly as the result of an action by
another MGC operating on that MG.  How do people feel about that one?

Either of these notifications would have to be defined in a package.

> -----Original Message-----
> From: Matt Holdrege [SMTP:[email-masked]]
> Sent: Tuesday, October 12, 1999 8:54 PM
> To:   [email-masked]
> Subject:      Re: AW: AW: Basic Package and NAS
>
> At 06:01 PM 10/11/99 -0400, Chip Sharp wrote:
> >At 01:37 PM 10/11/99 -0700, Matt Holdrege wrote:
> >>OK, now how about the case where one management entity owns the NAS and
> >>another owns the MGC. The NAS manager may decide to kill a certain user,
> >>but he has no way to send a command to an MGC to do this.
> >
> >The MGC would have to program the NAS to notify the MGC of this event.
>
> Do you have any technical reason for doubling up on the signalling
> messages? What objection is there to sending a disconnect rather than a
> notifcation to request a disconnect?
>
> >MGCP also had the capability of sending a Delete Connection from the MG
> to
> >the MGC to notify the MGC that a connection could not be maintained.
>
> So why object to having this in MEGACO?
>
> >In all the compromising and opposition to most things MGCP making it into
> >the text, this capability did not seem to make it into megaco.
> >
> >It is too late for mere mortals to submit contributions to the Red Bank
> >meeting (and this is the last meeting before the white paper is
> >published).  However, the all-powerful, :-), rapporteurs can submit
> >contributions whenever they wish.  Since the rapporteurs for Q13 and Q14
> >work for Lucent perhaps you could convince them of the need.
>
> Surely you know that SG16 is pretty open about such things. You can count
> on a contribution on this, Lucent or not.
>
> >You are correct that there are dozens (probably more) of such scenarios
> >that need to be looked at for megaco and H.248.  It didn't seem like
> there
> >was much interest in megaco in NAS issues and the nasreq WG didn't seem
> >interested either.  That is why I've said that there was a lot of work on
> >NAS issues still to be done before it can really be supported.
>
> On the contrary. As the archives should show, I've stated clearly and
> often
> that NAS requirements for MEGACO are a subset of voice requirements. I
> even
> recall the chair agreeing with me on this. Nothing special needs to be
> supported. This lack of a disconnect message seems to be an aberration
> that
> we need to fix.

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 13 Oct 1999 10:01:36 -0400

I think we're in agreement here, but the event has to be defined in a
package before it can be Notified.  Also, this introduces an error state
which the MG must maintain until the MGC gets back to it.  Does that imply a
new state value on the termination, or can we use OutOfService?

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Wednesday, October 13, 1999 9:29 AM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH];
> [email-masked]
> Subject:      RE: Connection Changes At MG (was Basic Package and NAS)
>
> I think it is unwise to change the architecture of the
> protocol.  This is an error condition.  The problem is
> completely solved by sending a Notify to the MGC, which
> responds with a Subtract.  It is, admittedly, one extra
> message and its ack, but it's an error condition!
>
> The MGC wishes to know WHY the MG wants the connection
> taken down.  The MGC must go through all the work it
> would do for a Subtract to get its state consistent.
> The Notify is the most appropriate way to tell the MGC,
> and Subtract is the most efficient way to get the connection
> taken down on both sides.
>
> The current mechanism suffices, adding a new one doesn't
> improve anything.
>
> Brian
>
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Tuesday, October 12, 1999 9:08 PM
> > To: [email-masked]
> > Subject: Connection Changes At MG (was Basic Package and NAS)
> >
> >

---

From: Brian Rosen <[email-masked]>
Date: Wed, 13 Oct 1999 11:54:06 -0400

It's all in when you want this protocol on the street.

If you want it soon, we have to stop tinkering with the protocol.
You can keep tinkering with some packages, but
changes to the protocol have to stop, yesterday.

If it changes the ABNF, then I think it has a pretty
tall wall to climb now.

This is a classic case; the existing mechanism is okay.
You can argue about a backwards subtract being "better".
Right now, okay is enough.  At least IMHO.

Going into Red Bank, there are quite a few proposals on
the table to change the ABNF.  Generally speaking,
I personally want to turn ALL of them down, even ones
I think have some merit.  If someone comes up with a problem
that shows that the protocol as we have it now is BROKEN,
then we have to fix it, but incremental improvements with
small gain, and reasonable mechanisms in the present
incarnation should be, I think, flatly rejected as too late.

There will clearly be a version 2 of the protocol some day.
Some of these issues can be brought up then.

It would be helpfull for those of us going to Red Bank
to have a sense of whether the rest of you agree with this
position.  You could very well say that we want MEGACO to
be as close to perfect as we can get it, and suggestions
for any kind of improvement are still welcome, when it's
done, it's done.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, October 13, 1999 11:27 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Connection Changes At MG (was Basic Package and NAS)
>
>
>
> Brian,
>
> The main problem is that it's an error condition,
> but there is no generic "error" event that can be
> posted on the MG to catch all unexpected errors.
> In order to make this work properly, the MGC would
> need to post event requests for all error sources
> -- which ought to be on a package basis -- and
> listen for them.
>
> I believe that Ericsson has a proposal for having
> a generic error event. I haven't read it, but I
> think it's intended for cause codes to be relayed.
> If we expanded that to expect any out of band
> error code (and probably allow packages to expand
> the error code space), then MEGACO as it currently
> stands might be made to work.
>
> The only other option is to allow for the MG to do
> subtracts with reason. This has the benefit of
> cutting down on a half a round trip, but also has
> the potential for abuse on the MG side (eg, the MG
> subtracts because it's having a bad hair day).
>
> I suspect that both are probably appropriate in
> certain circumstances. If for no other reason, it
> would probably be good for the MG to have a
> catch-all way to alert an MGC that something is
> dreadfully wrong/inconsistent with the
> termination's state. This could be done with a
> ServiceChange wink, but that seems rather heavy
> handed.
>
> Is there a real problem with allowing for both?
>
>        Mike
>
>
> Brian Rosen writes:

---

From: Faad Ghoraishi <[email-masked]>
Date: Wed, 13 Oct 1999 11:57:38 -0400

Brian Rosen writes:
>...The problem is completely solved by sending a Notify to the MGC, which

What about also defining a ServiceChange parameter so that
the MG can notify the MGC of complete AAA/LAC  failure.

The MGC might be overloaded by the many notify
messages it will receive from the MG due to AAA failure.
Also, there is no need to setup an SS7 trunk call if the AAA is
going to fail.

As you know the rate of re-dialing in the dialup access world is very high.
5 to 10 times per connection. So there will be many calls incoming
to MGC which are all destined to fail. Also, if it know of the failure,
it is possible that MGC can initiate Automatic Call Control procedure.

Faad Ghoraishi
Telcordia Tech. Inc.

********************

Brian Rosen <[email-masked]> on 10/13/99 09:29:16 AM

Please respond to Brian Rosen <[email-masked]>

To:   [email-masked]
cc:    (bcc: Faad Ghoraishi/Bellcore)
Subject:  Re: Connection Changes At MG (was Basic Package and NAS)

Brian

> > supported. This lack of a disconnect message seems to be an

Brian Rosen <[email-masked]> on 10/13/99 09:29:16 AM

Please respond to Brian Rosen <[email-masked]>

To:   [email-masked]
cc:    (bcc: Faad Ghoraishi/Bellcore)
Subject:  Re: Connection Changes At MG (was Basic Package and NAS)

Brian

---

From: Peter Blatherwick <[email-masked]>
Date: Wed, 13 Oct 1999 08:26:41 -0500

Tom, list:

Connection loss events seems like a good thing to get Notification of.
There could be any number of reasons for this, including failure, and the
MGC needs to know what's going on so it can handle it and stay in synch with
network state.  Not clear to me this should be defined in a package, since
the case is quite generic and would therefore apply to almost all
terminations.  (What did you have in mind Tom?  A termination monitoring
package of some sort?)

Second case, notification of change/loss due to actions of another MGC, is
less generic, but I would think it could be handled by the same notification
mechanism.

Alas, I think its pretty late in the game to be considering such
fundamentals.  Completion of the packages document is already a full agenda
without adding more to it.

-- Peter Blatherwick

> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent: 12 Oct, 1999 21:08

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 13 Oct 1999 13:08:23 -0500

It isn't really necessary to do this in ServiceChange.  You can provide an
event against the MG rather than individual terminations which indicates
failure of (what? the transport connection to the AAA/LAC server? the
far-end application?).

> From: Faad Ghoraishi [SMTP:[email-masked]]
> Sent: Wednesday, October 13, 1999 11:58 AM

---

From: Chip Sharp <[email-masked]>
Date: Wed, 13 Oct 1999 14:23:06 -0400

I don't believe that we will be able to identify all the events required
for NAS operation in the near future.  Perhaps a general error event would
be sufficient with a cause code.

As for maintaining an error state, I'm not sure that is necessarily.
What will the NAS do in this case if the MGC NAKs the request?

Chip

> > > > supported. This lack of a disconnect message seems to be an

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Faad Ghoraishi <[email-masked]>
Date: Wed, 13 Oct 1999 17:17:10 -0400

I agree 100%. Your suggestion to use the root event and notify message
is simpler and will result in the same capability of detecting complete
AAA failure at the NAS.

I suggest the NAS should have a root event to detect AAA and L2TP failures.
Both application and interface failure (lost socket) could be combined
into one error since the final effect is the same, failed calls.

A more granular detection for L2TP failure is to have a seperate NAS events
for the LAC and  the far end L2TP network server (LNS) failures
since one can have one LNS failed while others are working fine.

Faad
*******************************

Tom-PT Taylor <[email-masked]> on 10/13/99 02:08:23 PM

Please respond to Tom-PT Taylor <[email-masked]>

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 13 Oct 1999 19:12:02 -0500

Notify is not a request.  Actually, there is a potential problem here: the
call has to be cleared before the connection is taken down, lest the
incoming trunk be reused for an outgoing call while the original caller is
still connected.  In present mode of operation the call clearing is
initiated by the caller when the attempt to set up a data session fails.
Resources can be released a little more quickly if the MGC initiates call
clearing, and that would be the justification for sending the notification
to the MGC in the first place.  (I base my discussion on the architectural
premise in our charter, which says that call signalling terminates on the
MGC.)

You're probably right that an error state is unnecessary -- it is sufficient
that the incoming trunk termination is held in a context which has no other
terminations until the MGC does get around to clearing the connection.

We do have a potential problem, that there will be a pile of notifications
that the MGC will want, and it will be a pain to enable them on a
per-termination basis.  One possibility is to provide in package definitions
that certain notifications are armed by default on all the terminations to
which they apply.

> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Wednesday, October 13, 1999 2:23 PM