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

From: Faad Ghoraishi <[email-masked]>
Date: Wed, 13 Oct 1999 09:56:09 -0400

Matt Holderge writes:

>Lack of central control? Do you understand how this works today? It is
>central control! (unless it is required to not have central control as is
>sometimes the case). AAA is flexible in that respect. You may also want to
>read the RADIUS RFC and each of the I-D's in the RADIUS WG to see exactly
>how much work you would have to do to support any other model.

Matt I wish you would stop accusing people of not knowing and answer the
question.
When I say lack of central control, I am referring to MGC in a distributed
architecture
of MGC and MGs not having control over AAA/L2TP/etc procedure. How can you
disagree with that when you are saying that presently in MEGACO
MGC should not have control over AAA/L2TP?

As to the lack of my knowledge, we at Telcordia wrote a set of Generic
Requirement for
Internet Traffic Offload nodes (MG and MGC which we called Access
Server (AS) and Internet Call Router (ICR), respectively). FYI, both Lucent and
Ascend,
among others were major funders of these GRs.

In our GR we did not finalize the MG/MGC interface protocol because we wanted
to use standardized protocol (MEGACO). At this point the MEGACO protocol is
not what we expected it to be with respect to NAS functions.

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

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

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.

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

Faad Ghoraishi
Telcordia Tech. Inc.
USA

Matt Holdrege <[email-masked]> on 10/12/99 07:46:10 PM

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

At 09:59 AM 10/12/99 -0400, Faad Ghoraishi wrote:

>Matt Holdrege writes:
>
> >Just as there are too many AAA related messages which would hinder call
> >management? It's a heck of a lot more than an accept/deny message and an
> >L2TP setup.
>
>Im my opinion there are three ulternatives approaches in dealing with  AAA or
>L2TP
>control within the new distributed architecture using MEGACO.
>
>1. The first approach is to do nothing and let the NAS handle all
>AAA/L2TP/etc.
>This approach will exclude the MGC from the overall picture of NAS call setup.
>As discussed before it has several shortcomings, including extra provisioning,
>overload of A,O&M interface, lack of central control, etc.

Lack of central control? Do you understand how this works today? It is
central control! (unless it is required to not have central control as is
sometimes the case). AAA is flexible in that respect. You may also want to
read the RADIUS RFC and each of the I-D's in the RADIUS WG to see exactly
how much work you would have to do to support any other model.

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 13 Oct 1999 07:27:20 -0700

>Matt I wish you would stop accusing people of not knowing and answer the

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.

>be notified during start-up as well on kind of AAA interface the MG

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.

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

>instead of at the NAS, now they will do all the AAA/L2TP provisioning in the

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.

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

---

From: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" <[email-masked]>
Date: Wed, 13 Oct 1999 17:20:50 +0200

>>>>> "Matt" == Matt Holdrege <[email-masked]> writes:

 ...

    >> be notified during start-up as well on kind of AAA interface the MG

    Matt> As I've said many times, where is this need? Can you quantify it or
    Matt> describe in real terms what would break if you didn't have this
    Matt> capability? ISP's using MEGACO precursors don't have this requirement
    Matt> today.

 ...

  So is NAS termination type is required at all in your understanding?

  I think it is required, including the L2TP parameters in case the MG
routes PPP via L2TP to an ISP. The originating PSTN termination reports
digits to the MGC and the MGC according to the dialed number decides that
the call is destined to some ISP with some known L2TP server. Then the MGC
should instruct the MG to connect originating termination to NAS termination
providing ISP L2TP server domain name/IP address and shared secret.

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 13 Oct 1999 09:36:23 -0700

At 05:20 PM 10/13/99 +0200, Rasin, Mark (M.) [SMTPPART:LOD:Telrad] wrote:
>     >> When I say that the MGC needs to be in control of all aspects of
> NAS call
>     >> setup.
>     >> be notified of any failure or success of these procedures. The MGC
> also
>     >> needs to

That works just fine today without the MGC or switch knowing anything about
L2TP.

---

From: Chip Sharp <[email-masked]>
Date: Wed, 13 Oct 1999 14:11:04 -0400

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

>I apologize if my emails sound harsh. Perhaps I can explain my views

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

---

From: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" <[email-masked]>
Date: Wed, 13 Oct 1999 18:52:10 +0200

Matt> As I've said many times, where is this need? Can you quantify it or
    Matt> describe in real terms what would break if you didn't have this
    Matt> capability? ISP's using MEGACO precursors don't have this
    >> requirement
    Matt> today.
    >> providing ISP L2TP server domain name/IP address and shared secret.

    Matt> That works just fine today without the MGC or switch knowing anything about
    Matt> L2TP.

    Yes, it does when there is dial-up connection to ISP's modem pool. But in
case there is an intention to off-load the PSTN network and send PPP from
a telco's MG with a modem pool to an ISP directly via data network it does not.

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 15 Oct 1999 09:20:52 -0700

>a telco's MG with a modem pool to an ISP directly via data network it does

It works fine. For today's NAS's the only thing that is changed
in the new signalling architecture is the interface to the NAS
call control. Everything else works the same.

A good number of ISP's are doing this today.

---

From: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" <[email-masked]>
Date: Sun, 17 Oct 1999 09:31:33 +0200

>> >> providing ISP L2TP server domain name/IP address and shared secret.
    Matt> That works just fine today without the MGC or switch knowing
    >> anything about
    Matt> L2TP.
    >> a telco's MG with a modem pool to an ISP directly via data network it does

    Matt> It works fine. For today's NAS's the only thing that is changed
    Matt> in the new signalling architecture is the interface to the NAS
    Matt> call control. Everything else works the same.

    Matt> A good number of ISP's are doing this today.

   Again, you are taking into account only NAS's belong ISP's and
ignoring the case when ISP's out-source the PSTN access to telco's and
therefore NAS's belong a telco. In latter case the same MG serves
access to several different ISP's, end even the same PSTN subscriber
can request access to different ISP's. In this case the MG first should
know which ISP data traffic should be routed. Since the MGC is the one
which has the knowledge (according to directory number dialed or
pre-provisioned), there should be a way to tell it to the MG.

---

From: Robert Pluim <[email-masked]>
Date: Mon, 18 Oct 1999 15:52:41 +0200

> pre-provisioned), there should be a way to tell it to the MG.

Well, in all the networks I've been involved in, this knowledge is
held on a server distinct from the MGC, accessed using RADIUS or
similar. I don't see that it makes any difference whether the NAS is
providing a "real" POP or a "virtual" one, in both cases there is
information that the MGC is not (necessarily) privy to, but which the
NAS requires to determine how and where to authenticate/authorize a
call, and how and where to route the resulting data.

Thus, as Matt argues, it should be possible for the NAS to make a
decision to terminate a call, and informing the MGC that it has done
so is considerably simpler than asking the MGC to ask the MG to do it.

Robert
--

---

From: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" <[email-masked]>
Date: Mon, 18 Oct 1999 16:57:34 +0200

>>>>> "Robert" == Robert Pluim <[email-masked]> writes:

    >> pre-provisioned), there should be a way to tell it to the MG.

    Robert> Well, in all the networks I've been involved in, this knowledge is
    Robert> held on a server distinct from the MGC, accessed using RADIUS or
    Robert> similar. I don't see that it makes any difference whether the NAS is
    Robert> providing a "real" POP or a "virtual" one, in both cases there is
    Robert> information that the MGC is not (necessarily) privy to, but which the
    Robert> NAS requires to determine how and where to authenticate/authorize a
    Robert> call, and how and where to route the resulting data.

    Robert> Thus, as Matt argues, it should be possible for the NAS to make a
    Robert> decision to terminate a call, and informing the MGC that it has done
    Robert> so is considerably simpler than asking the MGC to ask the MG to do it.

    Robert> Robert

   I think both NAS services are possible in MG's:

1. The NAS service you are describing, when a PPP link in the MG is both
   established and authenticated. In this case I agree that all the
   routing information should be retrieved by the MG via RADIUS or
   similar and it is out of the scope of the MGC and therefore out of
   the scope of MEGACO.

2. The more limited NAS service, when a PPP link in the MG is only
   established but is not authenticated. Authentication PPP phase
   messaging is passed to a ISP or to an intermediate subscriber
   management system via L2TP. In this case it is simpler for the MGC
   to associate dialed number with a L2TP server and tell it to the MG,
   and therefore required in NAS package.

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 18 Oct 1999 10:45:11 -0700

At 09:31 AM 10/17/99 +0200, Mark Rasin wrote:
>     >> a telco's MG with a modem pool to an ISP directly via data network
> it does
>     >> not.
>

Again, this is all done today. The MGC does tell the MG by sending
the DNIS. The MG knows what to do with that.

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 18 Oct 1999 11:52:54 -0700

At 04:57 PM 10/18/99 +0200, Rasin, Mark (M.) [SMTPPART:LOD:Telrad]

>    and therefore required in NAS package.

Which is simpler is debatable. But there is an established method for
using it with Radius. So I don't think we should overly complicate MEGACO
at this stage, especially since I am quite sure the problem space has not
come even close to being adequately stated.