Subject: [AAA-WG]: Two accounting spec nits

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 17:21:46 +0300

Hi. I went over some issues that Ericsson's 3GPP [UMTS]
experts had on the DIAMETER accounting spec. A couple of
minor fixes should perhaps be added to the spec. They are
described below:

- A number of AVPs in the accounting spec
  are mandatory, even they might not make
  sense for all applications. (e.g. a
  SIP proxy would not know the number of
  transferred packets in a call since it
  is not a party in the RTP session).

  The following AVPs should therefore be
  marked as optional and should appear 0 to 1
  times in the accounting request packets.

  Accounting-Input-Octets
  Accounting-Input-Packets
  Accounting-Output-Octets
  Accounting-Output-Packets
  Accounting-Session-Time

- Use of Accounting-Interim-Interval which appears
  in the accounting-request should be clarified. I
  believe the intent is to supply the value given
  from the authorization server, if any.
  Also, the use of the same AVP in the -answer
  message should be clarified in the same manner:
  I believe the intent is for the server to echo
  the value in the -request, possibly modify, or supply
  one if it was missing. This seems to be an
  important requirement for 3GPP who are going to
  decouple authorization server and prepaid server
  from each other and propably supply the AVP as
  an ack to the start request.

Jari

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 28 Mar 2001 06:41:06 -0800 (PST)

> Jari Arkko [mailto:[email-masked]] writes:
> 
> >   sense for all applications.
> 
> True, but I think a better approach might be to remove them from the base
> spec altogether and place them (or equivalents) into the extension(s) for
> which they are intended; in this case, NASREQ (perhaps better named
> dial-access, since virtually everything seems to be a NAS these days ;-).

Well, Mobile IP also needs these, so putting them in NASREQ may not be that
wise...

> > (e.g. a

So they should be optional.

> >   an ack to the start request.

ok, that's an easy enough fix.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 28 Mar 2001 06:59:20 -0800

> Well, Mobile IP also needs these, so putting them in NASREQ may

I'm all for reusing code, but reusing AVPs only makes sense to me in an
(extremely) constrained namespace.  Is the test for whether AVPs should be
included in the base protocol whether more than one extension needs them?
If so, then, we can look forward to virtually endless modification of the
base, since an extension can invent it's own AVPs, which another extension
can see and say, "Gosh that looks good, I want that too" and there we go.  A
more reasonable criterion, IMHO, is whether the AVP is _necessary_ for the
operation of the _base_ protocol.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 18:04:39 +0300

Glen Zorn wrote:

> which they are intended; in this case,
> NASREQ (perhaps better named dial-
> access, since virtually everything
> seems to be a NAS these days 

I would agree with this.

FYI, the 3GPP would also later define their
own extension which adds some of their
service-specific attributes in how
the accounting is used.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Mar 2001 18:08:14 +0300

>putting them in NASREQ may not be that

Yeah. Now I remember that some of these
attributes were supposed to be in the
base part to ease the applications to
not always define their own, when they
are likely needed by several apps. Maybe
the optionality then is the best course
of action here.

Jari

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 28 Mar 2001 07:08:07 -0800 (PST)

> operation of the _base_ protocol.

ok, i'd like to open this one up for discussion. The AVPs in question are: 		
	Accounting-Input-Octets
	Accounting-Input-Packets
	Accounting-Output-Octets
	Accounting-Output-Packets
	Accounting-Session-Time

To me, these seem generic enough for accounting purposes that they could be
used by *any* extension. However, I'll buy Glen's opposition about AVP reuse.
What do others think?

(of course, my personal preference is to keep them in the base, which is where
all of the accounting stuff now resides)

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 28 Mar 2001 07:31:13 -0800 (PST)

> Sorry, but I've probably missed this earlier, why should accounting be a
> part of the base protocol. I don't see why it should be mandatory when used
> with MIP within a corporate environment.
> 

Glen has brought this up ad nauseum on the list, and it was discussed at the
IETF. The -01 I-D included a section that stated that Accounting is mandatory
to support, but it was still an extension (hence advertised). It was finally
decided to merge it into the base protocol. I initially did not like this
because of the increased size of the base protocol document, but having an
extension (which is advertised) is also the wrong thing to do since Accounting
is part of the base protocol.

So this is really nothing new, and if corporate networks don't want to use
accounting, well they can easily turn that feature off.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 28 Mar 2001 18:01:23 +0200

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Patrice Calhoun
>Sent: den 28 mars 2001 17:31
>To: Fredrik Johansson
>Cc: Patrice Calhoun; [email-masked]; Jari Arkko; [email-masked]
>Subject: RE: [AAA-WG]: Two accounting spec nits
>
>
>> >> >

It can easily be turned off, but why implement it in the first place.
Following that argument one can make MIP and NASREQ mandatory but easy to
turn off :-). Having a AAA protocol without one of the A's does not make a
lot of sence and probably makes better explanation to why it should be there
:-)

I agree that having it as an extension is wrong if it should be mandatory.

/Fredrik

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 28 Mar 2001 06:33:16 -0800

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 28 Mar 2001 07:48:42 -0800

Fredrik Johansson [mailto:[email-masked]] writes:

> part of the base protocol. 

Um, 'cause it's a AAA protocol, not an AA protocol.

> I don't see why it should be mandatory 
> when used

Nothing is mandatory to deploy, AFAIK...

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 28 Mar 2001 08:21:21 -0800 (PST)

> lot of sence and probably makes better explanation to why it should be there

You'd be surprised that you may be wrong. My experience (product, not research
experience) shows that many corporate customers want to know who is using
what, and how much. In many cases, there is a charge back from the IT dept to
the user's department. 

So, a AAA client or server that doesn't support Accounting may not be very
useful in the real world.

> I agree that having it as an extension is wrong if it should be mandatory.

Good, the you agree with the strategy.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 28 Mar 2001 08:07:16 -0800

...

> Having a AAA protocol without one of the A's does not make a

My thought exactly :-)

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 28 Mar 2001 17:25:53 +0200

/Fredrik

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 28 Mar 2001 09:51:48 -0800

> operation of the _base_ protocol.

My understanding is that only the AVPs in the base protocol spec,
and those defined within the extensions could set the 'M' bit. So
there would be no need to modify the base spec in order to
accomodate additional (optional) AVPs. If a NAS didn't
understand those AVPs, it could ignore them.

This provides a means of supporting additional AVPs that does not
require modification to the base spec. If someone were to propose
a new AVP for an extension or even the base, and a DIAMETER server
were to send this AVP to a NAS, no harm would be done -- as long
as there was no expectation that the NAS would be *required* to
understand it. Thus, as long as the 'M' bit is clear, we have a
way to add to the protocol without having to revise the specs.

The problem comes from addition of new *mandatory* AVPs, either
standardized or vendor-specific. We need to carefully think through
the circumstances in which these will be allowed. This is part of
the IANA considerations section -- a similar discussion has occurred
within DHC WG with respect to handling of new options.

If possible, I would try to address the issue of new AVPs without
requiring the base protocol to be revved each time a new
optional AVP is created. After all, we didn't have
to rev RFC 2865 to accomodate RFC 2867-2869 extensions. Those
specs stood on their own.

Duplicating messages (and AVPs) also doesn't seem like a sensible
strategy either. Other posters have noted that there are several
DIAMETER messages that have roughly the same usage. It isn't
entirely clear to me why those duplicate messages or AVPs need
to exist.

---

From: "John Alayari" <[email-masked]>
Date: Wed, 28 Mar 2001 11:37:11 -0800

In 3GPP and similar usage of AAA, there may be multiple clients running for
a given session. A AAA client in the SIP server may send an Accounting
Request message and record-type AVP=START-RECORD with specific AVPs such as
service type or QoS parameters to a AAA server and another AAA client in the
SGSN may send the Accounting Request and record-type AVP = INTERIM_RECORD
with usage information AVPs for the same accounting session.

So my point is that, we need to revisit mandatory AVPs other than those Jeri
mentioned (e.g. authentication-type)in the base accounting for these kind of
applications.

John.

>Sent: Wednesday, March 28, 2001 7:31 AM
><To: Fredrik Johansson

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 28 Mar 2001 23:25:32 +0300

> a given session. A AAA client in the SIP server may send an Accounting

I think I understand the general setup you describe, but I would
note the following:

* In your particular example, I think it is more likely that the existing
  bearer service AAA schemes will be retained by 3GPP i.e. the SGSN will
  use a telco protocol in the accounting but the IP multimedia will run
  with DIAMETER.

* One way of handling the accounting from several sources is to
  do the correlation of records in post-processing stage. In general,
  this may be the only way of doing this, given that various nodes may
  not have synchronization protocols in place to exchange e.g. session
  identities.

* Also, various users of DIAMETER are all faced with the question of
  whether DIAMETER accounting is (a) sufficient as is from the RFC,
  (b) sufficient but additional attributes need to be defined, or (c) can
  be reused in part, but a new extension is required. I think most cases
  would fall on a or b.

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 28 Mar 2001 19:19:51 -0800

Bernad Aboba [mailto:[email-masked]] writes:

> > can see and say, "Gosh that looks good, I want that too" and
> there we go.
> A

This discussion, though cogent, seems irrelevant.  Pat's assertion was that
the AVPs should be included (as optional) in the base because they were
needed by >1 extensions.  My argument is that they should not, for one
reason that they are _not_ optional for either of the extensions in
question.  It seems to me that the extensions would need to either modify
the base to state that the AVPs are mandatory or establish that while they
are technically optional, they are (non-explicitly) mandatory in their
contexts (wink, wink, nod, nod ;-).

> within DHC WG with respect to handling of new options.

Yes, but more to the point of this discussion, what about AVPs that are
mandatory for some extensions (say, MIP & NASREQ) but optional (or even
superfluous) for others?

> specs stood on their own.

Well, umm, sort of.  RFC 2867, in particular, is rife with references to
attributes defined in other documents, as well as modifications to the
semantics thereof.

> entirely clear to me why those duplicate messages or AVPs need

From a protocol POV, I'll admit that there is probably not a great reason.
However, fromm a specification POV, independently defined messages increase
the cohesion of the documents, while decreasing the coupling between them.
To use RFC 2867 as an example, in order to implement it a person needs to
understand RFCs 2865-2869, inclusive.  I would have _vastly_ preferred to
have defined the compulsory tunneling attributes independent of the base
RADIUS stuff, but the paucity of the RADIUS namespace prevented that; the
same limitations do not exist in Diameter, and I think we should take
advantage of it.  To put it another way, I would like to be able to take 2
documents and implement both the base protocol and _any_ given Diameter
extension, w/o needing to chase through a pile of essentially unrelated
stuff searching for the definition of the _one_ AVP I need from it.

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 29 Mar 2001 16:55:53 -0800 (PST)

I buy some of Glen's comments about having parse through multiple documents to
get an extension completed. However, I am looking for concrete examples of
what needs to be done.

Ideas?

(btw, one idea I had was to move the filter definition text into the base, but
just leave the AVP definition in the relevant documents. Not sure Glen would
like that any better than the original proposal).

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 29 Mar 2001 23:55:04 -0800

>contexts (wink, wink, nod, nod ;-).

I think it makes sense to include AVPs in the base protocol that are
used in more than one extension. However, as you point out, if they
are mandatory in more than one extension, then they cannot be made
optional in the base spec. If an AVP does not have the same status
for all extensions, it seems to me that the base spec would
need to specify the extensions for which the 'M' bit can be set.

>mandatory for some extensions (say, MIP & NASREQ) but optional (or even

I would propose that the base spec include a table specifying for each
AVP and extension whether the 'M' bit may be set or not. Each new
extension could also include such a table.

>RADIUS stuff, but the paucity of the RADIUS namespace prevented that.

How did the paucity of attributes influence the design? In order to
handle compulsory tunneling accounting, new accounting messages *were*
defined, so this had some of the character of an "extension". Can you
talk about the advantages and disadvantages of this approach?

One thing that has occurred to me about RADIUS is that with new access
types like VPN, the combination of NAS-Port-Type and the message in
effect define an "extension": the semantics of the AVPs may change
as a result. For example, if NAS-Port-Type = 802.11, there is no
point sending a number of attributes that might make sense if
NAS-Port-Type = Virtual.

The nice thing about this is that these "extensions" can in effect
be created without the need for any code changes, assuming that the
RADIUS implementation has an extensible dictionary and supports
conditional behavior. (For an example of conditional behavior in
the ISC DHCP server, see Droms & Lemon's "DHCP Handbook").

So if possible, I'd rather not move to a model in which DIAMETER
server code updates are needed to support "extensions" that could
have been implemented as dictionary additions under RADIUS. This
seems like a step backward.

>To put it another way, I would like to be able to take 2

Well, I would say that it is ok to describe an AVP or messages in two
places, if that would help, as long as the definition is the same. But
creating new messages or AVPs that do the same thing as the old ones
seems like a bad idea, because it requires unnecessary code changes.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 06:59:00 -0800 (PST)

> extension could also include such a table.

The table *is* already in the spec, but only includes AVPs defined in the base
spec. Are you now proposing that the base include ALL AVPs defined in ALL
extensions?

(btw, the extension documents also have such a table).

PatC