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

From: Faad Ghoraishi <[email-masked]>
Date: Wed, 13 Oct 1999 16:58:01 -0400

Chip Sharp writes:
>... Moving all AAA information to the MGC to ride over megaco
>is not realistic for most ISPs anytime soon, if ever.
>
>Therefore, I agree with Matt that we need to provide a way for Dial
>providers to maintain their current investment in NAS and AAA as much as
>possible (preferably in toto).

I agree too. I think there is a misunderstanding about my basic
point on NAS capabilities.
I agree that the NAS will maintain AAA function and interface. It
is too late to change that now.
What I am suggesting is to give the MGC the ability to initiate
the REQUEST for AAA at the MG and receive acknowledgment.
That is ,if MGC determines that ISP 1 prefers RADIUS, then it will
send a request in the ADD message's Local Descriptor SDP, indicating
RADIUS and possibly the IP address of the RADIUS server.
The MG then takes this and completes all the RADIUS procedure
including collecting login and password, etc for that call. Then it will ack
the MGC with success/failure and cause code.

Now what if the MGC wants the AAA procedure to be TACACS or
just L2TP, then it will send this request down to MG and the MG
perform the functions. The MG still will need to be programmed
and provisioned with how  to do these functions.
The RADIUS server will also still maintain the data it has now.
But the point is that the MGC is now in charge.

See, this capability if added in this version of MEGACO
will be a place-holder for the more advanced
capability where the MGC can do all the AAA functions or
send all AAA parameters down to the MG needs. But this is
for the future.

I think that since the NAS market is going to be moving
to Carrier grade NASs, i.e., NAS located in the CO with
large number of ports and many divergent ISPs subscribing
to modem service on the same NAS, and the very likely scenario
of a single MGC controlling all  NASs,  the NAS should be as much
a plug-and-play box as possible and it should be able to support
various AAA functions not just RADIUS.

Faad Ghoraishi
Telcordia Tech. Inc.
*****************************************

Chip Sharp <[email-masked]> on 10/13/99 02:11:04 PM

Please respond to Chip Sharp <[email-masked]>

To:   [email-masked]
cc:    (bcc: Faad Ghoraishi/Bellcore)
Subject:  Re: AW: AW: Basic Package and NAS

I think that we all have to realize that current NASes will continue to
exist and be deployed.  The current dial-in architecture will not change
just because megaco defines a new protocol.  ISPs will have to have a
compelling reason to move to a new architecture.  Those of us who have
deployed dial POPs and services over the last few years know this very well.

I haven't heard too many ISPs beating down our (megaco's) door for a new
architecture to replace their current AAA and dial infrastructure.

In fact, at least one ISP and several vendors have invented a new protocol
(PPP over Ethernet) that will allow them to preserve their current dialin
RADIUS architecture when providing service to DSL customers.  This seems to
imply that at least one major ISP would rather invent a new protocol than
change their RADIUS infrastructure (which contains most of their high-touch
customer info).  Fundamentally, a NAS is different from a Voice Gateway at
this stage of development.  The market is much more mature, there is a much
larger embedded base and operations are pretty well codified.

Thus, we shouldn't assume that the megaco architecture is going to replace
the current AAA or Dial architecture any time soon.  Moving all AAA
information to the MGC to ride over megaco is not realistic for most ISPs
anytime soon, if ever.

Therefore, I agree with Matt that we need to provide a way for Dial
providers to maintain their current investment in NAS and AAA as much as
possible (preferably in toto).  In a way, this can be seen as preserving
the "Q.931 experience", :-).  This means supporting native intelligence in
the NAS and the possibility that the NAS is querying other systems for
operation (e.g., RADIUS).

The main disagreement I believe Matt and I have in this case is whether or
not the NAS notifies the MGC via a "disconnect" notice (in megaco's case a
Subtract) or via a Notify (that causes the MGC to send a Subtract).  Using
a Notify uses an extra message exchange (Notify/Reply, Subtract/Reply)
though the first Reply and Subtract can be bundled into one
message.  Sending a Subtract from the NAS to the MGC changes the current
operation of the protocol and the meaning of some of the statistics.  In
either case, the net effect is that the NAS sends an unsolicited message to
the MGC that causes the MGC to disconnect the call.

A good example of this is when an ISP uses its current operations system to
knock somebody offline.  This would come as an unsolicited RADIUS message
to the NAS.  The NAS would have to notify the MGC to disconnect the call.

If the Notify method is used, then there needs to be some procedure written
explaining how to program the NAS appropriately.  Expecting the MGC to send
a Notify Request to the NAS for every disconnect case is probably
unrealistic.  Having a way for the NAS to send a Notify with (MGC)
unsolicited disconnect events is needed to support this functionality.

In either case, we can provide error or cause codes that are more
informative than Q.931 cause codes.  I don't think allowing the NAS to send
a Notify or Subtract to the MGC with a cause code of "Authentication
Failed" will break anyone's systems.

On the other hand, not allowing the MGC to exert more control over the NAS
is unnecessarily restrictive.  If vendors don't want to implement it and
ISPs don't want to deploy it then current operation must be supported.  I
don't think supporting current operations and allowing future enhancements
for more MGC control are mutually exclusive.

Chip

At 07:27 AM 10/13/99 -0700, Matt Holdrege wrote:
>At 09:56 AM 10/13/99 -0400, Faad Ghoraishi wrote:
>
>>Matt I wish you would stop accusing people of not knowing and answer the
>>question.
>
>I'm sorry, but you keep making statements that make it seem like
>you don't understand how NAS's or ISP's work. Your message below
>is full of misunderstandings (or so I interpret them). I'll try
>to address a few below.
>
>
>>When I say that the MGC needs to be in control of all aspects of NAS call
>>setup.
>>This does not mean that it is going to do AAA/L2TP etc., but it needs to
>>be in
>>control
>>of who ever initates this and must know of the status of these procedures.
>>That is it needs to instruct the MG to intitate AAA/L2TP/etc. and
>>be notified of any failure or success of these procedures. The MGC also
>>needs to
>>be notified during start-up as well on kind of AAA interface the MG
>>supports (RADIUS, etc).
>
>As I've said many times, where is this need? Can you quantify it or
>describe in real terms what would break if you didn't have this
>capability? ISP's using MEGACO precursors don't have this requirement
>today.
>
>>I also do not understand your concern about impact on the 50,000,000 users
>>and the 1000s of ISPs who are presently doing this procedure if we change
>>MEGACO AAA function the way we are describing it.
>>Nobody is changing AAA , PPP, or L2TP procedures that will impact users or
>>ISPs.
>>So what are you talking about.?
>
>Redirecting AAA information through an intelligent entity will
>certainly impact current procedures. Removing the state and control
>from the NAS will impact even more.
>
>>If the ISP wants to buy a new NAS which supports MEGACO, they are already
>>changing their NAS, so what is so hard about a different AAA provisioning
>>site,
>>instead of at the NAS, now they will do all the AAA/L2TP provisioning in the
>>MGC.
>
>This is where I recommend that you learn more about the NAS architecture.
>Changing the call setup signalling is entirely different than changing
>AAA. And I keep hearing about L2TP which is a very small piece of the pie.
>There is so much more that hasn't been addressed.
>
>>Also, think of what happens when one MGC controls several MGs (may be upto 10
>>large MGs (50K - 500K ports). Think of the addess provisioning that one
>>has to
>>do in all MGs. If I (the network administrator) want to add one ISP I have to
>>provision many MGs instead of one MGC.
>>Also, what if the MG losses its RADIUS interface, should the MGC just accept
>>calls anyway. If it knew of the problem it could have rerouted the incoming
>>SS7 calls to other MGs (SS7 now has a new feature where a call can be sent
>>on an alternate route defined  in the SS7 RELEASE Message).
>
>ISP's today have solved all of the concerns that you list above. Radius
>gives you central control. Radius has backup and failover scenarios covered.
>
>I apologize if my emails sound harsh. Perhaps I can explain my views
>in person in Washington.

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: Thu, 14 Oct 1999 18:22:29 -0700

>various AAA functions not just RADIUS.

NAS's today support all this and much much more. The above
paragraph describes how NAS's have worked for over a year
now. They do not require anything special from the MGC that
they don't already get today.