Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF

From: Patrice Calhoun <[email-masked]>
Date: Wed, 23 Feb 2000 13:43:54 -0800

>At 03:10 PM 2/23/00 -0500, David Mitton wrote:
>>ummm...
>>
>>At 10:13 PM 2/23/00 -0800, you wrote:
>>>Yes, please read through the megaco archives if you wish to know our 
>>>disagreement.
>>
>>that's only 35MB of text in my mail reader.  But please do not attempt to 
>>explain here.  Just direct us to the prime temporal location of the
>discussion.
>
>Don't you keep 35 Mbytes in your In box in Eudora?  ;-)
>
>The latest round of discussion can be found in a thread titled
>"Basic Package and NAS"  which occured between 10/6/99 and 10/18/99
>
>The megaco archive search page at 
>http://standards.nortelnetworks.com/scripts/wa.exe?S1=megaco
>
>can be used to search for this.
>
>
>
>>>I agree with Matt that NASes work fine with current operation.  The main 
>>>disagreement I believe is that i believe enhancements can be made to the 
>>>NAS package to allow other capabilities.
>>
>>You know, "package" is a real general term in english.  I usually use UPS 
>>or FedEx.  Can you explain in about 64 words or less what this means to
>megaco?
>
>Megaco defines a base protocol for allowing a Media Gateway Controller to 
>control what are called "terminations" on Media Gateways.  A "termination" 
>could be physical (e.g., DS0) or "ephemeral"  (e.g., RTP endpoint).  The 
>specific parameters, events and signals for a particular type of 
>termination are defined in "packages."  A package defines the events that 
>can be detected on a termination (e.g., Dial tone), signals to be 
>transmitted on a termination (e.g., dtmf, dial tone, etc.) and parameters 
>that can be used to configure the termination (e.g., what codec to use on a 
>RTP termination).
>
>A NAS package would define a NAS termination and would define the events, 
>signals and configuration parameters that a MGC could use to control a NAS 
>(acting as a media gateway).  Basically,  the MGC would handle the call 
>control and then configure the NAS to accept the call.  The NAS would then 
>do its normal PPP (or whatever) and RADIUS thing.
>
>The sticking point seems to be whether or not the protocol would allow the 
>MGC to send down various configuration parameters (e.g., modem type, AAA 
>server to use, L2TP LNS to connect to , etc.) based on the Calling/Called 
>number (or other call info).

hmm... does the MGC "talk" to AAA? It sounds like it if it knows L2TP LNS
information (or perhaps all of this is statically configured, ugh!). How
would the MGC know the modem type, if the call wasn't answered? Or are
we talking about something that gets sent in the ISDN control message (X.75,
etc)? Lastly, as for AAA, it seems simpler to have the NAS talk to a AAA,
and have that AAA proxy to the appropriate server.

I understand that there may be MANY other configuration items involved, and
I really should stop everything I am doing to learn MEGACO :). Seriously,
the question I have is whether this is information that the MGC (and only the
MGC has), or whether it is information that can (and does) get derived by
the NAS.

>
>If something is done in this area, it should probably be done in close 
>cooperation with the megaco group.

agreed.

PatC

---

From: Chip Sharp <[email-masked]>
Date: Wed, 23 Feb 2000 16:35:35 -0800

>and have that AAA proxy to the appropriate server.

The only thing the MGC can key on is call information.  Most of the time 
this would be Called and Calling Party Number.   This operation happens 
before the call is answered, so there is no PPP (LCP or NCP).

Sample applications would be a service provider that wants to support 
credit card verification and other applications on the same modem 
pool.  Credit card verification tends to use V.22bis modem and it is too 
time-consuming to start at V.90 and negotiate down to V.22bis.  Therefore, 
the provider would want to have a way to tell the NAS to start modulation 
at V.22bis instead of V.90.  The provider could allocate a phone number to 
use for credit card verification.  The NAS would key off the phone number 
to know what type of modulation to start with.

A provider may also provide different phone numbers for customers to use 
for a virtual private dial network using L2TP.  The provider may want to 
key on the phone number to determine which AAA server to use or which LNS 
to use for a call.

If the NAS does this directly, it could receive the incoming call and then 
send a request to the RADIUS server containing the called/calling phone 
number.  The RADIUS server would then key on the phone number and return 
parameters for the call.  I won't call this AAA since it does not have 
anything to do with Authentication, Authorization or Accounting.  It is 
basically a call-by-call configuration function.

In either case (the NAS collecting pre-connect configuration info from a 
RADIUS server or from the MGC), during LCP/NCP the NAS would still do 
Authentication and Authorization as currently defined.

>MGC has), or whether it is information that can (and does) get derived by

Any pre-connect configuration info that is used on a call-by-call basis 
could reside on the NAS, RADIUS server or delivered to the NAS by the MGC.

I anticipate that initially the MGC will deliver the call to the NAS and 
the NAS will operate as it does today in terms of pre-connect configuration 
information.  However, I would rather not make a general statement now that 
prohibits enhancements to be defined in the future that allows the MGC to 
deliver pre-connect configuration to the NAS.

> >cooperation with the megaco group.

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