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

From: Brian Rosen <[email-masked]>
Date: Mon, 11 Oct 1999 14:26:49 -0400

> 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.).
Both the Multiservice Switching Forum and the International Softswitch
Consortium have expressed interest in supporting interoperability testing of
Megaco.  They may even co-operate on such an exercise!

Brian

---

From: Faad Ghoraishi <[email-masked]>
Date: Tue, 12 Oct 1999 09:59:09 -0400

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.

2. The second approach is similar to SGCP which gives ALL control to MGC. In
this
case, the MEGACO protocol (using Packages) shall define all the existing
 AAA/L2TP/etc parameters which it will use to send from the MGC to the MG to
perform all AAA/L2TP functions. This approach will make the Packages too
complicated.

3. The third appoach is a hybrid of the above two. In this approach
the MGC can only  program a termination within
the MG to perform AAA/L2TP/etc functions.
The MGC does not send any parameters required for
AAA/L2TP to the MG. The MG shall store the Called Number/Calling Number/etc
parameter per call (as is done today for AAA), but the will get its instruction
on what type of
AAA , frameing or Tunneling it should perform.
There should also be Events define in MEGACO to notify the MGC of
failure/success
of AAA/Tunneling functions.

Matt Holdrege <[email-masked]> on 10/11/99 03:50:53 PM

Please respond to Matt Holdrege <[email-masked]>

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

At 03:01 PM 10/11/99 -0400, Faad Ghoraishi wrote:

>Also, using the A,O&M interface to notify the MGC (as some suggest) is also a
>major mistake, since there will be too many call related messages put on this
>interface and could hinder management.

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.

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 12 Oct 1999 16:46:10 -0700

>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: Tom-PT Taylor <[email-masked]>
Date: Wed, 13 Oct 1999 11:38:39 -0400

Would you mind getting specific in what you propose to be added.  (i.e.)
What words should be added to what section of what document?  That will give
us a better idea of what you're asking for.

> -----Original Message-----
> From: Faad Ghoraishi [SMTP:[email-masked]]
> Sent: Wednesday, October 13, 1999 9:56 AM
> To:   [email-masked]
> Matt Holderge writes:
> 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)

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 13 Oct 1999 11:13:54 -0700

That's in APC 1744 coming to a server near you soon. :)