Hi, > Jacni>: While we opened the door in this way for additional IANA > activities. I have a fear that everytime we will need to request a > value for -id, > then give the recommended definition of -name accordingly, and vise > versa? ;-) I understand your concerns. Another option to do this properly would be to use RFC5777 - it allows traffic filter, QoS, or even time-of-day definitions. That should cover a lot of use cases. The obvious drawback (is it a serious one?) is that it pulls in Diameter attribute format, which might mean it's not very easy to implement in a RADIUS server. I wonder what people think of this... > I don't see an issue with that unless one would want to have different > session Id's for different traffic groups in the same accounting > ticket > - but I have a hard time thinking of a reason for that; after all all > the counted Octets and Packets belong to the same user session, > and can > thus share the same session id. > > > Jacni>: For example, two clasess v4 and v6, over single access service, > there may be cases that the dynamic QoS or bandwidth policy changes > (class-specific) > are requested by users,say, through portal, then initiate/executed by > the server side, the > -id is needed. I'm not sure I understand what you mean. Let me construct an example. Did you mean - User logs in over single PPPoE session, gets dual stack connectivity - NAS has Accounting ID 0xf00ba, and two accounting classes, one for v4 and one for v6 - mid-session, IPv6 gets new QoS parameters (DSCP -> higher) and needs to be billed separately from that moment on If that's the use case, I still don't see why the accounting ID would need to be different from the initially allocated one. It's still the same session, and thus the same session ID. An accounting packet could start with two accounting blocks: IPv4 - DSCP 0 IPv6 - DSCP 0 and when the change happened, adds the third block for traffic class IPv6 - DSCP x The block "IPv6 - DSCP 0" will stop incrementing at that point, because all subsequent traffic will be DSCP x. But it can still be there, and accurate billing can be produced from it - so no reason why a Acct-packet-global accounting ID would be insufficient. Or maybe I got your use case wrong :-) Stefan > > > Cheers, > Jacni > > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education > Nationale et de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Attachment:
signature.asc
Description: OpenPGP digital signature