Subject: AW: AW: Basic Package and NAS

From: Bilalis Zacharias <[email-masked]>
Date: Mon, 11 Oct 1999 17:39:52 +0200

I think it is a cleaner solution that MGC initiates the disconnect.

Best Regards / Mit freundlichen Grüssen

Zacharias Bilalis

SIEMENS ICN WN CS EC D12
> Schertlinstr. 8
> D-81359 Muenchen
> Germany
Tel: + 49 89 722 28391
Fax: + 49 89 722 61243
Mail to: [email-masked] 

> -----Ursprüngliche Nachricht-----
> Von:  Matt Holdrege [SMTP:[email-masked]]
> Gesendet am:  Montag, 11. Oktober 1999 17:28
> An:   [email-masked]
> Betreff:      Re: AW: Basic Package and NAS
> 
> That is exactly what happens. The MG may disconnect internally and send a 
> MEGACO disconnect message to the MGC. But any auth information in that 
> message would be optional.
> 
> 
> At 01:59 PM 10/11/99 +0200, Bilalis Zacharias wrote:
> >If e.g. AAA fails, the cleanest solution is that MGC is informed and ends
> >the connection
> >
> >Best Regards
> >
> >Zacharias Bilalis
> >
> >SIEMENS ICN WN CS EC D12
> > > Schertlinstr. 8
> > > D-81359 Muenchen
> > > Germany
> > >
> >Tel: + 49 89 722 28391
> >Fax: + 49 89 722 61243
> >Mail to: [email-masked]
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von:  Matt Holdrege [SMTP:[email-masked]]
> > > Gesendet am:  Freitag, 8. Oktober 1999 20:31
> > > An:   Bilalis Zacharias
> > > Cc:   [email-masked]
> > > Betreff:      Re: AW: AW: Basic Package and NAS (was Re: AW: Packages
> > > Conference Ca ll M inutes)
> > >
> > > MUST? No. Just as a Class 5 switch is not informed of nor has any
> > > knowledge
> > > of an AAA server. COULD? Perhaps if you wish to build that type of
> feature
> > >
> > > into your system. It would be a trivial task to have your MGC notified
> of
> > > AAA activities (heck, they could even be in the same box!), but MEGACO
> > > should not be encumbered with such overhead and complexity.
> > >
> > >
> > > At 08:51 AM 10/8/99 +0200, Bilalis Zacharias wrote:
> > > >What happens if NAS access fails due to AAA deny? Must MGC not be
> > > informed ?
> > > >
> > > >Best Regards
> > > >
> > > >Zacharias Bilalis
> > > >
> > > >SIEMENS ICN WN CS EC D12
> > > > > Schertlinstr. 8
> > > > > D-81359 Muenchen
> > > > > Germany
> > > > >
> > > >Tel: + 49 89 722 28391
> > > >Fax: + 49 89 722 61243
> > > >Mail to: [email-masked]
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von:  Matt Holdrege [SMTP:[email-masked]]
> > > > > Gesendet am:  Donnerstag, 7. Oktober 1999 22:54
> > > > > An:   [email-masked]
> > > > > Betreff:      Re: AW: Basic Package and NAS (was Re: AW: Packages
> > > > > Conference Call M inutes)
> > > > >
> > > > > Where is this "need" that you mention? As I said, the model
> actually
> > > works
> > > > >
> > > > > today. It is not deficient. Millions are using it with ISDN and in
> > > fact a
> > > > > great deal of NAS ports are using the current AAA model with the
> new
> > > > > signalling architecture, and with a MEGACO pre-cursor protocol
> (e.g.
> > > > > Q.931+
> > > > > and IPDC).
> > > > >
> > > > > As for the MGC being in charge of end-to-end, that isn't even true
> for
> > > an
> > > > > ordinary voice call, much less a data call. With voice, in a
> trunking
> > > > > scenario, there is a source and destination MGC and each control's
> > > their
> > > > > own MG. With data for Internet access, the MGC *only* passes the
> call
> > > off
> > > > > to the NAS. The rest of the end-to-end data session has other IETF
> > > > > standard
> > > > > entitites controlling it. AAA servers, LNS's, route servers, etc.,
> > > control
> > > > >
> > > > > this. Not the MGC.
> > > > >
> > > > >
> > > > > At 03:03 PM 10/7/99 -0400, Faad Ghoraishi wrote:
> > > > >
> > > > >
> > > > >
> > > > > >Matt writes:
> > > > > > >The NAS supports all the actions you list below today through
> the
> > > IETF
> > > > > > >standard methods. Perhaps you should discover how NAS's work
> today
> > > to
> > > > > see
> > > > > > >how they can work best with MEGACO.
> > > > > >
> > > > > >I know that the NAS today support all the actions I listed. What
> is
> > > your
> > > > > >point?
> > > > > >
> > > > > >These are old methods, we need to have new methods in MEGACO.
> > > > > >As Chip said, it is good and most likely required to be backward
> > > > > >compatible with
> > > > > >old NAS functions, but we need to MOVE ON.
> > > > > >If the MGC is truly in charge of the end to end call, then it
> MUST
> > > know
> > > > > of all
> > > > > >AAA and Tunneling
> > > > > >procedures. Futher it should be able to activate these functions
> > > within
> > > > > >the NAS
> > > > > >termiantions.
> > > > > >
> > > > > >Why do you want to dublicate data provisioning in both the NAS
> (as is
> > > > > >today) and
> > > > > >the MGC (in the future)?
> > > > > >
> > > > > >
> > > > > >Faad
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >Matt Holdrege <[email-masked]> on 10/07/99 02:27:34 PM
> > > > > >
> > > > > >Please respond to Matt Holdrege <[email-masked]>
> > > > > >
> > > > > >To:   [email-masked]
> > > > > >cc:    (bcc: Faad Ghoraishi/Bellcore)
> > > > > >Subject:  Re: AW: Basic Package and NAS (was Re: AW: Packages
> > > Conference
> > > > > >       Call M inutes)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >The NAS supports all the actions you list below today through the
> > > IETF
> > > > > >standard methods. Perhaps you should discover how NAS's work
> today to
> > > see
> > > > > >how they can work best with MEGACO.
> > > > > >
> > > > > >
> > > > > >At 09:32 AM 10/7/99 -0400, Faad Ghoraishi wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > >I have the same concern as Bilalis about not supproting AAA
> > > function in
> > > > > > >MEGACO.
> > > > > > >How does the NAS notify the MGC of the success of AAA?
> > > > > > >If it is through the O,A&M interface (as Matt suggested), it is
> > > unwise
> > > > > > to mix
> > > > > > >call related
> > > > > > >messages with operation system messages. During congestion,
> this is
> > > > > > >potentially going to be a nightmare.
> > > > > > >
> > > > > > >Also, if MEGACO does not support AAA and/or Tunneling requests,
> is
> > > the
> > > > > NAS
> > > > > > >suppose to
> > > > > > >now maintain Call State for each incoming modem call. How is
> the
> > > NAS to
> > > > > know
> > > > > > >what AAA protocol
> > > > > > >to use per call (i.e., RADIUS, TACACS, Login, etc.)? Is it
> going to
> > > > > > maintain a
> > > > > > >list of Called Number (ISP number) and
> > > > > > >the associated AAA protocol to use
> > > > > > >Also, how does NAS  know  which framing to use (PPP asynch, PPP
> > > hdlc,
> > > > > SLIP,
> > > > > > >etc)?
> > > > > > >
> > > > > > >May be the MEGACO protocol should not support PPP and L2TP
> protocol
> > > > > > >itself, but
> > > > > > >it should
> > > > > > >certainly support the capability to request such protocol  from
> MGC
> > > to
> > > > > MG.
> > > > > > >
> > > > > > >
> > > > > > >Faad Ghoraishi
> > > > > > >Telcordia Technologies, Inc
> > > > > > >********************************************
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >Bilalis Zacharias <[email-masked]> on
> 10/07/99
> > > > > 02:58:22 AM
> > > > > > >
> > > > > > >Please respond to Bilalis Zacharias
> > > <[email-masked]>
> > > > > > >
> > > > > > >To:   [email-masked]
> > > > > > >cc:    (bcc: Faad Ghoraishi/Bellcore)
> > > > > > >Subject:  AW: Basic Package and NAS (was Re: AW: Packages
> > > Conference
> > > > > Call M
> > > > > > >       inutes)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >         In the introduction of the NAS package, It is
> mentioned
> > > that
> > > > > > dial-in
> > > > > > >access to the NAS is supported, not the
> > > > > > >  contact to a AAA server. The latter is part of other
> protocols.
> > > That
> > > > > > is why
> > > > > > >issues e.g. how password is sent to AAA server and
> > > accepted/rejected
> > > > > are not
> > > > > > >part of the package. But if we want to support dial-in access,
> we
> > > have
> > > > > to
> > > > > > >know if the AAA server has permitted the access or no.
> > > > > > >
> > > > > > >Best Regards
> > > > > > >
> > > > > > >Zacharias Bilalis
> > > > > > >
> > > > > > >SIEMENS ICN WN CS EC D12
> > > > > > > > Schertlinstr. 8
> > > > > > > > D-81359 Muenchen
> > > > > > > > Germany
> > > > > > > >
> > > > > > >Tel: + 49 89 722 28391
> > > > > > >Fax: + 49 89 722 61243
> > > > > > >Mail to: [email-masked]
> > > > > > >
> > > > > > > > -----Urspr
> > > > > > >
> > > > > >üngliche Nachricht-----
> > > > > > > > Von:  Matt Holdrege [SMTP:[email-masked]]
> > > > > > > > Gesendet am:  Donnerstag, 7. Oktober 1999 00:56
> > > > > > > > An:   [email-masked]
> > > > > > > > Betreff:      Re: Basic Package and NAS (was Re: AW:
> Packages
> > > > > Conference
> > > > > > > > Call Minutes)
> > > > > > > >
> > > > > > > > At 01:32 PM 10/6/99 -0400, Chip Sharp wrote:
> > > > > > > > >It is hard to reconcile the NAS part of this package with
> the
> > > > > > > > requirements
> > > > > > > > >in draft-ietf-megaco-reqs-06.txt.
> > > > > > > >
> > > > > > > > As I've said on many an occasion, the requirements as
> written go
> > > > > outside
> > > > > > > > the scope of MEGACO. We even had a conference call on this
> issue
> > > > > which I
> > > > > > > > though solved the problems. Bottom line, we do not do AAA
> with
> > > > > MEGACO!!
> > > > > > > >
> > > > > > > > >I'm especially referring to the following text:
> > > > > > > > >"This encompasses the support of dial-in access to the NAS,
> but
> > > not
> > > > > the
> > > > > > > > >contact to a AAA server for authentication, authorisation
> etc
> > > and
> > > > > the
> > > > > > > > >possible subsequent set-up of a layer 2 tunnel to a remote
> NAS.
> > > > > > Those are
> > > > > > > > >autonomous functions of a NAS and therefore out of scope
> for
> > > the
> > > > > Megaco
> > > > > > > > >protocol (see e.g. IETF RFC 2661 (L2TP) and RFC 1661
> (PPP)). "
> > > > > > > > >
> > > > > > > > >It is certainly desirable to allow legacy NAS equipment to
> > > continue
> > > > > > > > >operating as currently deployed and implemented.  However,
> to
> > > > > restrict
> > > > > > > > >future development to legacy capabilities is
> over-restrictive.
> > > It
> > > > > is a
> > > > > > > > >definite probability that megaco may be used for a host of
> > > things
> > > > > > related
> > > > > > > > >to AAA and tunneling (among other things) at least based on
> > > > > information
> > > > > > > > >received from the SCN (e.g., Called Party Number, Calling
> Party
> > > > > Number,
> > > > > > > > >Bearer Capability, etc.).
> > > > > > > >
> > > > > > > > If you think the current scheme is "legacy" and should be
> > > improved,
> > > > > you
> > > > > > > > should be contributing to the discussions going on in the
> AAA
> > > WG. I
> > > > > don't
> > > > > > > > think characterizing the method currently used by
> 50,000,000-odd
> > > > > Internet
> > > > > > > > users is overly restrictive. The Internet would not have
> scaled
> > > as
> > > > > > > > massively and quickly had that been true.
> > > > > > > >
> > > > > > > > >It is clear that the NAS package is pretty rudimentary and
> will
> > > > > have to
> > > > > > > > be
> > > > > > > > >extended substantially for proper operation of a Dial POP.
> > > This
> > > > > may not
> > > > > > > > >happen until after the white paper is released or after
> H.248
> > > is
> > > > > > > > approved.
> > > > > > > > >
> > > > > > > > >If you don't want the currently defined NAS package to
> provide
> > > > > these
> > > > > > > > >features, then don't include them.  But don't say they are
> > > outside
> > > > > the
> > > > > > > > >scope of megaco.
> > > > > > > >
> > > > > > > > I think that protocols that are handled by other WG's are
> > > outside
> > > > > the
> > > > > > > > scope
> > > > > > > > of MEGACO. The L2TP WG handles L2TP. The AAA WG handles AAA.
> > > > > > > >
> > > > > > > > >Actually, the more I think of the current megaco
> architecture
> > > since
> > > > > the
> > > > > > > > >March Compromis (reminds me of the Missouri Compromise) the
> > > more I
> > > > > think
> > > > > > > > >the best way to support NAS behavior is via a NAS
> termination.
> > > In
> > > > > this
> > > > > > > > >case, the DS0 termination would control behaviour of the
> DS0
> > > and
> > > > > the NAS
> > > > > > > > >termination would control the behaviour of the NAS (modem
> type,
> > > > > HDLC
> > > > > > > > >controller, which AAA server to use, which L2TP destination
> to
> > > use,
> > > > > > > > >etc.).  This would have to be rolled up into a package
> defining
> > > the
> > > > >
> > > > > > media
> > > > > > > > >descriptor, eventdescriptor and signaldescriptor
> parameters.
> > > > > > > > >
> > > > > > > > >Other items:
> > > > > > > > >
> > > > > > > > >In Section 3.14.2.1.4 (CallBack Request), you take into
> account
> > > > > only AAA
> > > > > > > > >initiated callback.  There are various other types of
> callback
> > > > > allowed
> > > > > > > > >(e.g., PPP callback) that may not involve AAA.
> > > > > > > >
> > > > > > > > PPP callback is a part of PPP and has nothing to do with
> MEGACO
> > > > > except
> > > > > > > > that
> > > > > > > > the PPP engine on the NAS will request a call setup to the
> > > MEGACO
> > > > > engine.
> > > > > > > > The same works for any method of setting up a call on a NAS.
> > > > > > > >
> > > > > > > >
> > > > > > > > >Authorisation Succeed/Fail:
> > > > > > > > >RADIUS doesn't separate Authentication and Authorisation.
> > > However,
> > > > > they
> > > > > > > > >are separate events.  Therefore, a user could conceivably
> pass
> > > > > > > > >Authentication and fail Authorization for a service.  If
> these
> > > > > types of
> > > > > > > > >indications are to be sent to the MGC, then they should be
> > > > > separated
> > > > > > into
> > > > > > > > >separate events.  I see that the package has the
> Authorisation
> > > > > event
> > > > > > > > >defined but there is no Authentication event defined.
> > > > > > > >
> > > > > > > > If the MGC needs to know about Auth failure, it can learn
> that
> > > from
> > > > > the
> > > > > > > > AAA
> > > > > > > > server out of band of MEGACO.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 11 Oct 1999 09:01:46 -0700

It must be optional. Many will not want to leave a call up while waiting 
for a MGC to handle things. It's up to the operator and the service.

---

From: Chip Sharp <[email-masked]>
Date: Mon, 11 Oct 1999 14:00:35 -0400

Sounds like there is an architectural disconnect (pun intended).

In the architecture I've been working with in the megaco WG and SG16, the
MGC tells the MG (in this case a NAS) to notify it of events.  The MG
doesn't send Subtract or Modify messages to the MGC.  There is no
"disconnect" message in Megaco.

The MGC receives the event and takes action based on its internal
operation.  This action may be to send a "Disconnect" (e.g., Q.931
Disconnect, SS7 RLN, etc.) message to the SCN and send a megaco Subtract
message to the MG(NAS).

In this case, the MGC would have to program the MG(NAS) to notify the MGC
of AAA failure along with other failures and events (LCP, IPCP, loss of
modem carrier, etc.).

There is the case that seems to be discussed by a couple of folks in which
the MG terminates the SCN signaling and communicates with the MGC via some
common signaling protocol (Q.931 over TCP or Sigtran has been
discussed).  I imagine in this case, the MG would sends a Disconnect to the
MGC and the MGC would send the Subtract to the MG.  This particular
architecture would seem to be out of the scope of the megaco protocol.

Being allowed to do the latter is not the same thing as not having the
capability in the megaco/H.248 protocol.  The capability must be in
H.248/megaco.  Different vendors may choose to implement the protocol in
different ways.

Chip

P.S.  I'd suggest someone think about starting a Megaco interoperability
forum soon because it doesn't look like there is much of a chance on
implementations interoperating given all the options we are throwing into
it (type-value vs. SDP, binary vs. text, etc.).

> > > > > > > > > server out of band of MEGACO.

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: Mon, 11 Oct 1999 11:31:54 -0700

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

>of AAA failure along with other failures and events (LCP, IPCP, loss of

So you're saying we should reprogram the entire connect/disconnect
operation of millions of NAS ports in use around the world to solve some
perception of architectural purity? And consequently tell ISP's to change
their procedures to suit? And hope we get it right on the first try even
though we are significantly changing something that has taken years to
evolve? Sorry to be dramatic, but that's what it looks like to me. That
will never fly.