Subject: Re: AW: AW: Basic Package and NAS

From: Brian Rosen <[email-masked]>
Date: Mon, 11 Oct 1999 15:54:27 -0400

Now who is holding up the architectural purity flag?

It has never been possible for the MG to have control over terminations.
It was discussed, but never decided that this was a good idea.

There is nothing wrong with the MG informing the MGC that it had an
AAA failure, and the MGC responding with subtract.  That does not
change anything about the way NAS's work.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Monday, October 11, 1999 3:47 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: RE: AW: AW: Basic Package and NAS
>
>
> At 02:45 PM 10/11/99 -0400, Brian Rosen wrote:
> > > The MG
> > > >doesn't send Subtract or Modify messages to the MGC.  There is no
> > > >"disconnect" message in Megaco.
> > >
> > > Isn't disconnect the same things as subtract?
> > >
> > > The MG must be allowed to choose to disconnect (or subtract)
> > > on it's own.
> > >
> >There is no provision for the MG to disconnect (or
> >subtract) a termination except on actual failure of the
> >termination.  ServiceChange(forced) is used to
> >notify the MGC of such a failure.  This is expected to
> >be used in true failure of the hardware (or software),
> >not a routine event like AAA authentication denial.
> >
> >The correct way to handle this case is an event, which
> >would cause the MGC to Subtract the Termination.
> >
> >The model we have is that the MGC has all the call state,
> >and the MGC has very little state at all.  Anything that
> >affects call state should be communicated to the MGC for it
> >to take action.  The MG should never take action on it's
> >own except for irretrievable failure.
>
> I understand that to be the optimal case for telephony gateways. But
> in the early days of MEGACO I recall pushing for allowing more
> intelligent gateways to be built which MAY choose to have more control
> over their destiny. I don't recall anyone saying this shouldn't be
> allowed. I do recall people saying they wanted the model that you
> mentioned which is fine as long as you don't exclude others.
>
> You guys seem to be unaware of the fact that all the NAS's in the
> world today are already intelligent and have state. That simply is
> not going to change anytime soon. Neither are the ISP procedures that
> utilize all those NAS's (in most cases).
>
> In all the 1000-odd emails on this list I must have missed where
> the balance of control was taken away. I guess I'm saying it needs to
> be put back in or you will ultimately remove NAS's from the scope of
> MEGACO. NAS's will then have to continue to use Q.931+ or
> IPDC which allow
> the NAS to have some control and MGC's will have to very
> multilingual.
>

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 11 Oct 1999 13:37:47 -0700

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.

What about the case where a corporate LNS indicates that a tunneled
employee has exceeded his maximum time online? That LNS will kill the
session. The NAS/LAC will acknowledge the killed session and disconnect the
call. The MGC has no knowledge of this and must be told.

There are dozens of such scenarios that must be supported. That's why IPDC
has this feature and I don't know how MEGACO lost it.

---

From: Chip Sharp <[email-masked]>
Date: Mon, 11 Oct 1999 18:01:04 -0400

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

>call. The MGC has no knowledge of this and must be told.

Same as above.

>has this feature and I don't know how MEGACO lost it.

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.

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.

If not, there is possibility of programming the NAS terminations with
events that would cause the NAS to send Notify messages to the MGC that
would accomplish the same thing.

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.

Chip

>> > the NAS to have some control and MGC's will have to very

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

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 12 Oct 1999 17:53:35 -0700

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

>the MGC to notify the MGC that a connection could not be maintained.

So why object to having this in MEGACO?

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

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