Subject: Last Call On NAS Package

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Oct 2000 09:42:52 -0500

There have been no comments on draft-ietf-megaco-naspkg-01.txt.  I am
therefore submitting it to WG Last Call, expiring Nov. 8/00.  I think our
intention is that this be a Standards Track item, so speak up if you
disagree.

Tom Taylor

---

From: [email-masked]
Date: Wed, 25 Oct 2000 19:02:34 +0200

All,

Just one point I could use some clarification on. This may or may not impact the draft...

The NAS termination, when being added to a context for inbound call, needs to know at least called and calling number (if available) and the port type/bearer capability (required for authentication request).
The NAS package provides the called/calling number.
Where does the NAS termination derive the port type from?

The draft states in section 6.5:
<<
It will typically add the bearer capability properties (described in a
separate document) to the circuit termination based on call signalling.
What document is being referred to?
This would imply that the NAS termination has to peek at the properties of the circuit termination that has been (or will be) added to it's context?

What about Modem Descriptor? Would this be specified for the circuit termination or the NAS termination or both?

Thanks for clarifying,
Marc.

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Oct 2000 21:44:03 -0400

OK, thanks.

> -----Original Message-----
> From: Ilya Akramovich [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 9:15 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: [email-masked]
> Subject: Re: Last Call On NAS Package
>
>
> Tom,
>
> I'm afraid that those two may not be enough.
>
> I would also strongly recommend that User Information Layer 1 Protocol
> and User Rate be included in order to account for V.110, WORM-ARQ and
> PHS/PIAFS calls.
>
> Of course, those can always be added as vendor extensions, but I would
> give my 2 cents for their inclusion into a standartized package
> because of the wide use of the protocols in the NAS world.
>
> Ilya
> --
> Ilya Akramovich                    Tel: +1 (510) 747-2926
> Sr. Software Engineer              mailto:[email-masked]
> Lucent/InterNetworking Systems     http://www.lucent.com/ins
>
>
> Tom-PT Taylor wrote:
> >
> > The bearer capability package is on my "to do" list.  I
> think there are only
> > two properties required: Information Transfer Capability (speech,
> > unrestricted digital, etc.) and transfer rate/bandwidth.
> (Correct me if I'm
> > wrong.)  The package would apply to the circuit
> termination.  The MG (don't
> > personalize the NAS termination too much) would take
> account of these
> > properties on the circuit side when formulating its
> authentication request.
> >
> > The modem descriptor would also be set on the circuit side,
> but only if
> > modem type was indicated in incoming signalling to the MGC.
>  Otherwise
> > normal autosensing procedures would apply.
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, October 25, 2000 1:03 PM
> > > To: [email-masked]
> > > Subject: Re: Last Call On NAS Package
> > >
> > >
> > > All,
> > >
> > > The NAS termination, when being added to a context for
> > > inbound call, needs to know at least called and calling
> > > number (if available) and the port type/bearer capability
> > > (required for authentication request).
> > > This would imply that the NAS termination has to peek at the
> > > properties of the circuit termination that has been (or will
> > > be) added to it's context?
> > >
> > > What about Modem Descriptor? Would this be specified for the
> > > circuit termination or the NAS termination or both?
> > >
> > > Thanks for clarifying,
> > > Marc.
> > >
> > >
> > >

---

From: Alan Whitton <[email-masked]>
Date: Fri, 27 Oct 2000 12:21:27 -0500

Matt,

Agreed, however for those who don't want to have Radius in their Controller,
these stats would be useful.

Cheers,
Alan

-----Original Message-----
From: Matt Holdrege [mailto:[email-masked]]
Sent: Friday, October 27, 2000 1:00 PM
To: [email-masked]
Subject: Re: Last Call On NAS Package

These stats and many, many others are already returned in Radius Accounting
by NAS's. All you need is a thin Radius Accounting server in your MGC to
receive these stats.

At 10:10 AM 10/27/00 -0400, Alan Whitton wrote:
>Greetings,
>
>I posted this as it's own message, but it might do better as a follow on to
>the Last call...
>
>I think the NAS package is in need of some statistics (to be returned
>typically after the subtract of the NAS Ephemeral link)
>
>1) # of packets for session
>2) # of bytes transferred in session
>3) average connection rate
>
>I realize this is a bit sparse, but it would be useful none the less.
>
>Cheers,
>Alan

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 27 Oct 2000 10:37:15 -0700

But where does the list end? There are dozens of stats that can be sent
when a session ends, and the list grows each time an ISP convinces a NAS
vendor that they need something new. Do you want to reproduce all that in
the MEGACO NAS package and have vendor specific stats?

I don't see the point in doing just a few in the NAS package when ISP's
need the whole list. Also ISP's already have significant RADIUS
infrastructures so I don't see a great need for this in MEGACO. Lastly, you
may want to bring up this point in the IETF AAA WG.

At 12:21 PM 10/27/00 -0500, Alan Whitton wrote:

>Matt,
>
>Agreed, however for those who don't want to have Radius in their
>Controller, these stats would be useful.
>
>Cheers,
>Alan
>
>From: Matt Holdrege [<mailto:[email-masked]>mailto:[email-masked]]

---

From: Alan Whitton <[email-masked]>
Date: Fri, 27 Oct 2000 13:55:28 -0400

Matt,

No, all I am asking for are those simple statistics. I agree that the Radius
infrastructure is far superior for collection of this data, but why are NAS
Ephemeral links not allowed to send statistics back then (when they are
closed)?

As for all the "bells and whistles" stats, sure leave them where they should
be in the Radius side of things (especially the vendor specific stuff).

All I suggest is a simple set of "throughput" values to be returned, I am
not suggesting replacing or undermining Radius, only giving the controller
some statistics (if it chooses not to implement Radius on the box). All of
the Radius information can be "gleened" later from the Gateway's Radius (and
possibly cross-referenced?).

Cheers,
Alan

---

From: Alan Whitton <[email-masked]>
Date: Fri, 27 Oct 2000 14:23:56 -0400

OK,

Whilst I am shaking the tree a bit, one more point that needs to be made:

   EventID: authres (0x0001)

   Description: this event reports the outcome of a request for
   authorization of the network access request

   EventDescriptor Parameters: none added by this package

   ObservedEventDescriptor Parameters:

     result
       ParameterID: res (0x0001)
       Description: outcome of the service request to the AAA server
       (see for example RFC 2865 (RADIUS) [2]).
       Type: integer, 0 to 99
       Possible values:
         1: service denied
         2: incoming service authorized
         3: callback service authorized
         4: outgoing service authorized

Given that over 90% of the calling parties to the ISP are going to be
successful, can't this become an Event authfail (authenticate fail)? This
would mean you only receive this event if the authentication failed (thus
elimating those messages on successful calls).

Think that's it for me.

Cheers,
Alan

     <mailto:[email-masked]>

-----Original Message-----
From: Whitton, Alan [CAR:5Z00:EXCH]
Sent: Friday, October 27, 2000 1:55 PM
To: [email-masked]
Subject: Re: Last Call On NAS Package

Matt,

Cheers,
Alan

-----Original Message-----
From: Matt Holdrege [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Friday, October 27, 2000 1:37 PM
To: Whitton, Alan [CAR:5Z00:EXCH]
Cc: [email-masked]
Subject: RE: Last Call On NAS Package

At 12:21 PM 10/27/00 -0500, Alan Whitton wrote:

>From: Matt Holdrege [< mailto:[email-masked] <mailto:[email-masked]> >
mailto:[email-masked] <mailto:[email-masked]> ]

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 27 Oct 2000 11:40:50 -0700

Fair enough, but who chooses what stats? The ones that are important to you
may not meet the needs of others. I'm only against doing something
half-xxxed. Either do it all or don't do it at all.

Either way this goes, people can and will develop their own packages. I
expect carriers to publish their own MEGACO packages to meet special
requirements such as these.

At 01:55 PM 10/27/00 -0400, Alan Whitton wrote:

>Matt,
>
>No, all I am asking for are those simple statistics. I agree that the
>Radius infrastructure is far superior for collection of this data, but why
>are NAS Ephemeral links not allowed to send statistics back then (when
>they are closed)?
>
>As for all the "bells and whistles" stats, sure leave them where they
>should be in the Radius side of things (especially the vendor specific stuff).
>
>the Radius information can be "gleened" later from the Gateway's Radius
>(and possibly cross-referenced?).
>
>Cheers,
>Alan
>
>From: Matt Holdrege [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Matt Holdrege
> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]]

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 27 Oct 2000 12:07:17 -0700

For starters you could have a look at RFC 2866. Since I see you work for
Nortel, you might ask some co-workers in your NAS division for more info.

At 01:43 PM 10/27/00 -0500, Alan Whitton wrote:

>Matt,
>
>Half-"baked" is my middle name :-)
>
>As for the carriers and their packages, that is true also.
>
>What other useful stats could be included? I suppose you could break the
>packets and bytes into transmitted and received, but after that things get
>a bit unclear to me.
>
>Cheers,
>Alan
>
>Sent: Friday, October 27, 2000 2:41 PM
> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]]
> [<<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]]
>

---

From: Alan Whitton <[email-masked]>
Date: Fri, 27 Oct 2000 13:43:05 -0500

Matt,

What other useful stats could be included? I suppose you could break the
packets and bytes into transmitted and received, but after that things get a
bit unclear to me.

Cheers,
Alan

---

From: Julian Mitchell <[email-masked]>
Date: Tue, 31 Oct 2000 15:45:48 -0000

Hi,

I agree that most of NAS calls will generate an authres with value = 2, but
the purpose of this event is not solely to notify of authentication failure
(which will also be achieved by the value=17 (User Error) in the NASREL
event), but, more importantly, the type of service authorized. 

It should be noted that in the case that the AUTHRES value = 2, then no
additional messaging is needed from the MGC.

So, we should keep this event as authorization result, but remove the
generating of the value = 2, and work on the no news is good news principle
- unless an event is generated, continue with this call as an incoming NAS
call. 
  
Julian

> From: Whitton, Alan  [SMTP:[email-masked]]
> Sent: Friday, October 27, 2000 7:24 PM
>     Ø <mailto:[email-masked]>
> 
>

---

From: Alan Whitton <[email-masked]>
Date: Tue, 31 Oct 2000 09:49:38 -0600

Julian,

I agree with this just to keep things simpler.

So if you don't hear anything, assume all is good? This works for me. Tom,
any problems with changing this?

Cheers,
Alan Whitton

> From:         Mitchell, Julian [MDN05:CV05:EXCH]  
> Sent: Tuesday, October 31, 2000 10:46 AM
> Cc:   Whitton, Alan [CAR:5Z00:EXCH]
> I agree that most of NAS calls will generate an authres with value = 2,
> but the purpose of this event is not solely to notify of authentication
> failure (which will also be achieved by the value=17 (User Error) in the
> NASREL event), but, more importantly, the type of service authorized. 
> 
> generating of the value = 2, and work on the no news is good news
> principle - unless an event is generated, continue with this call as an
> incoming NAS call. 
>   
> Julian
> 
>       Given that over 90% of the calling parties to the ISP are going to
> be successful, can't this become an Event authfail (authenticate fail)?
> This would mean you only receive this event if the authentication failed
> (thus elimating those messages on successful calls).
>        
>       Think that's it for me.
>        
>       Cheers,
>       Alan
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 31 Oct 2000 12:00:15 -0600

So ... do other people feel that "authorization of incoming service
succeeded" is an unnecessary event?  If opinions are mixed, we could add a
parameter to the event configuration to indicate which results are wanted.
If everyone agrees that notification is only needed in the exceptional
cases, then I propose we rename the event "authex", Authorization Exception,
and delete the "Incoming Service Authorized" value from the set of possible
values of the result parameter.

-----Original Message-----
From: Mitchell, Julian [MDN05:CV04:EXCH]
Sent: Tuesday, October 31, 2000 10:46 AM
To: [email-masked]
Subject: Re: Last Call On NAS Package

Hi,

Julian

        -----Original Message-----
From:   Whitton, Alan  [SMTP:[email-masked]]
Sent:   Friday, October 27, 2000 7:24 PM
To:     [email-masked]
Subject:        Re: Last Call On NAS Package

        OK,

     result

Think that's it for me.

Cheers,
Alan

            Ø   < mailto:[email-masked]
<mailto:[email-masked]> >