Subject: Re: AW: Basic Package and NAS (was Re: AW: Packages Conference Call M inutes)

From: Faad Ghoraishi <[email-masked]>
Date: Thu, 7 Oct 1999 15:03:08 -0400

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: Thu, 7 Oct 1999 13:53:37 -0700

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.