[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: redirection+prepaid
Hi Stefaan and all
As you point out, rhe problem with extending the text field for this
attribute is that we would break Diameter. I borrowed heavily from
Diameter.
Having said that in the next version of Redirection Draft, for different
reasons, I had to change the syntax of that string.
Here is the reason:
If you want to remove a filter-rule or redirection-rule using COA push model
then you have to send an attribute that you want to change. If you don't
then the NAS will keep the attribute. By sending an attribute the NAS will
replace all other attributes of the same type.
BTW: The COA push model allows the RADIUS server to push attributes that it
wants to change to the NAS. The other model is what I call the COA pull
model which is a COA message that forces the NAS to reauthorize (send an
Access-Request Service-Type Authorize-Only) and receives all the attributes
in the Access-Accept message (hence "pull model"). The push model is not
supported by Diameter.
So two options:
a) Keep the syntax the same. Therefore I would have to send a benign rule
that will replace the other attributes; or
b) Change the syntax slightly eg. If the attribute is set to "flush" then
this flushes all the rules;
I like option b).
Note a couple of things:
1) Option b) could be extended so that we can selectively remove
filter/redirection rules.
2) It does break the Diameter syntax but note that Diameter doesn't even
support the COA push model for changing attributes so we would have to have
some translation.
> -----Original Message-----
> From: stefaan.de_cnodder@alcatel.be
> [mailto:stefaan.de_cnodder@alcatel.be]
> Sent: May 4, 2004 3:50 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: redirection+prepaid
>
>
>
> Hi Avi,
>
> Ok, I see. In fact I was thinking about extending the text
> field in for instance the NAS-Filter-Rule from "action dir
> proto from src to dst [options]" to "action dir proto from
> src to dst activation [options] " where activation can have
> values "immediately", "quota_expired", ... this has the
> problem that all possible cases has to be enumerated and that
> it might not line up with diameter. Anyhow, the two options
> below are also fine.
>
> regards,
> Stefaan
>
>
> Avi Lior wrote:
> >
> > Hi Stefaan and all,
> >
> > Your question is very timely and right on. We are
> currently working
> > on this in 3GPP2.
> >
> > Putting an attribute to indicate when something applies may
> not work.
> > It is possible that even under normal circumstances the session may
> > have a filter applied. In the case where it's a prepaid session it
> > could be that I have a filter/redirect attributes to be
> applied when
> > quota runs out and a filter id to be applied immediately. Since we
> > cannot guarantee the order of different attributes this
> will be hard
> > to do with an additional attribute. If we could however group the
> > redirection/filter attributes with the prepaid stuff then
> this would
> > do the trick. That is the essence of Option 2 below.
> >
> > I have identified two options (there could be others):
> >
> > Option 1:
> > =========
> >
> > When the quota reaches zero, in 3GPP2 the session is
> terminated and an
> > Access-Request Authorize-Only is sent back to report that
> the session
> > has terminated etc...
> >
> > My suggestion is to not terminate the session but rather,
> wait for the
> > reply to the Access-Request (above). That reply would be either:
> >
> > an Access-Reject (no quota drop the user) or;
> > an Access-Accept with new quota (after all the user may have topped
> > his
> > account) or;
> > an Access-Accept with redirection attributes.
> >
> > Problem with Option 1 is that during the time when we wait for the
> > response to the Access-Request there could be revenue leakage. Any
> > use could be applied to the new quota. So we would only
> have revenue
> > leakage if the user doesn't top up. Also it could be the case that
> > the NAS will drop the session anyway after some (locally
> configured)
> > timeout period.
> >
> > Option 2:
> > =========
> >
> > For prepaid put the Redirection/Filter attributes in the PPAQ.
> > Doesn't change the behavior of prepaid as specified by
> 3GPP2. The NAS
> > would apply any filter/redirection attributes it finds outside the
> > PPAQ immediately. Those in the PPAQ would be acted on when
> the quota
> > runs out.
> >
> > This is what I have on the table in 3GPP2.
> >
> > Note the following:
> > ===================
> >
> > a) 3GPP2 folks have not given me a clear indication of what is the
> > best option. We are addressing this now so I will know
> their opinions
> > shortly.
> >
> > b) I preffer option 1 but not sure about how operators will
> feel about
> > revenue leakage of several seconds. Option 1 fixes the
> problem of the
> > subscriber toping off his account. Yes you have some potential for
> > leakage but you may prevent a user from calling the call center to
> > complain. Not for me to decide which is better.
> >
> > c) I have to check what Diameter-CC does about this. I would very
> > much like to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid.
> >
> > Finally, I would very much like to hear what other folks
> have to say
> > about this.
> >
> > I really appreciate your comments.
> >
> > Avi
> >
> > > -----Original Message-----
> > > From: stefaan.de_cnodder@alcatel.be
> > > [mailto:stefaan.de_cnodder@alcatel.be]
> > > Sent: May 4, 2004 12:43 PM
> > > To: radiusext@ops.ietf.org
> > > Subject: redirection+prepaid
> > >
> > >
> > >
> > > Hi,
> > >
> > > I was wondering how the redirection in
> > > draft-lior-radius-redirection-00 can be used for prepaid: the
> > > filters/redirect is applied by the NAS as soon the attributes are
> > > received by the NAS (either in access accept or CoA). How
> can this
> > > then be used for prepaid when the filters have to be applied when
> > > there is no quota anymore? Would it not be better to add
> something
> > > to indicate when it has to be applied (e.g., immediately, when no
> > > quota anymore, ...)?
> > >
> > > regards,
> > >
> > > Stefaan
> > >
> > > --
> > > to unsubscribe send a message to
> radiusext-request@ops.ietf.org with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > >
> >
> > --
> > to unsubscribe send a message to radiusext-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>