[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT charter, Take 8 --- The Prepaid Attributes
Bernard writes:
> perhaps we can examine
> the proposals to see how they compare to established usage.
Here are my attributes. There are two of them. All of type string
encoded using TLVs.
5.1 PPAC Attribute
The PrepaidAccountingCapability (PPAC) attribute is sent in the
Access-Request message by a Prepaid Capable NAS and is used to
describe the PrePaid capabilities of the NAS. The PPAC is available
to be sent in an Access-Accept message by the Prepaid server to
indicate the type of prepaid metering that is to be applied to this
session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | SelectedForSession (SFS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : value of PPAC
LENGTH: 14
VALUE : String
The value MUST be encoded as follows:
Sub-Type (=1) : Sub-Type for AvailableInClient attribute
Length : Length of AvailableInClient attribute
(= 6 octets)
AvailableInClient (AiC):
The optional AvailableInClient Sub-Type, generated by the PrePaid
client, indicates the PrePaid Accounting capabilities of the NAS and
shall be bitmap encoded. The possible values are:
0x00000001 PrePaid Accounting for Volume supported
0x00000010 PrePaid Accounting for Duration supported
0x00000011 PrePaid Accounting for Volume and Duration supported
(non concurrently)
Others Reserved, treat like Not Capable of PrePaid
Accounting (=0).
Sub-Type (=2) : Sub-Type for SelectedForSession attribute
Length : Length of SelectedForSession attribute
(= 6 octets)
SelectedForSession (SfS):
The optional SelectedForSession Sub-Type, generated by the PrePaid
server, indicates the PrePaid Accounting capability to be used for a
given session. The possible values are:
0x00000000 PrePaid Accounting not used
0x00000001 Usage of PrePaid Accounting for Volume.
(only possible if the AvailableInClient supports
PrePaid Accounting for Volume)
0x00000010 Usage of PrePaid Accounting for Duration.
(only possible if the AvailableInClient supports
PrePaid Accounting for Duration)
0x00000011 Usage of PrePaid Accounting for Volume and Duration
(non concurrent) (only possible if the
AvailableInClient supports PrePaid Accounting for
Volume and duration)
Others Reserved, treat like PrePaid Accounting not used(=0).
5.3 PPAQ Attribute
The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and
Access-Accept messages. In Authorize Only Access-Request messages
it is used to report usage and request further quota; in an Access-
Accept message it is used to allocate the quota (initial quota and
subsequent quotas).
The attribute consists of a number of subtypes. Subtypes not used
are omitted in the message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIdentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Volume Quota |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Volume Quota | SUB-TYPE 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VolumeThreshold (VT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 6 | LENGTH | DurationQuota (DQ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationQuota (DQ) | SUB-TYPE 7 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationThreshold (DT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 9 | LENGTH | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PPAQ
Length: variable, greater than 8
String: The String value MUST be encoded as follows:
Sub-Type (=1): Sub-Type for QuotaIDentifier attribute
Length : Length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID):
The QuotaIDentifier Sub-Type is generated by the PrePaid server
at allocation of a Volume and/or Duration Quota. The on-line
quota update RADIUS Access-Request message sent from the Access
Device to the PPS shall include a previously received
QuotaIDentifier.
Sub-Type (=2): Sub-Type for VolumeQuota attribute
Length : length of VolumeQuota attribute (= 6 octets)
VolumeQuota (VQ):
The optional VolumeQuota Sub-Type is only present if Volume Based
charging is used. In RADIUS Access-Accept message (PPS to Access
Device direction), it indicates the Volume (in octets) allocated
for the session by the PrePaid server. In RADIUS Authorize Only
Access-Request message (Access Device to PPS direction), it
indicates the total used volume (in octets) for both forward and
reverse traffic applicable to PrePaid accounting.
Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
Length : length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO):
The optional VolumeQuotaOverflow Sub-Type is used to indicate how
many times the VolumeQuota counter has wrapped around 2^32 over
the course of the service being provided.
Sub-Type (=4): Sub-Type for VolumeThreshold attribute
Length : length of VolumeThreshold attribute (= 6 octets)
VolumeThreshold (VT):
The VolumeThreshold Sub-Type shall always be present if
VolumeQuota is present in a RADIUS Access-Accept message (PPS to
Access Device direction). It is generated by the PrePaid server
and indicates the volume (in octets) that shall be used before
requesting quota update. This threshold should not be larger than
the VolumeQuota.
Sub-Type (=5): Sub-Type for VolumeThresholdOverflow
Length : Length of VolumeThresholdOverflow attribute
(= 4 octets)
VolumeThresholdOverflow (VTO):
The optional VolumeThresholdOverflow Sub-Type is used to indicate
how many times the VolumeThreshold counter has wrapped around
2^32 over the course of the service being provided.
Sub-Type (=6): Sub-Type for DurationQuota attribute
Length : length of DurationQuota attribute (= 6 octets)
DurationQuota (DQ):
The optional DurationQuota Sub-Type is only present if Duration
Based charging is used. In RADIUS Access-Accept message (PPS to
Access Device direction), it indicates the Duration (in seconds)
allocated for the session by the PrePaid server. In on-line
RADIUS Access-Accept message (PPC to PPS direction), it indicates
the total Duration (in seconds) since the start of the accounting
session related to the QuotaID.
Sub-Type (=7): Sub-Type for DurationThreshold attribute
Length : length of DurationThreshold attribute (= 6 octets)
DurationThreshold (DT):
The DurationThreshold Sub-Type shall always be present if
DurationQuota is present in a RADIUS Access-Accept message (PPS
to Access Device direction). It represents the duration (in
seconds) that shall be used by the session before requesting
quota update. This threshold should not be larger than the
DurationQuota and shall always be sent with the DurationQuota.
Sub-Type (=8): Sub-Type for Update-Reason attribute
Length : length of Update-Reason attribute (= 4 octets)
Update-Reason attribute (UR):
The Update-Reason Sub-Type shall be present in the on-line RADIUS
Access-Request message (Access Device to PPS direction). It
indicates the reason for initiating the on-line quota update
operation. Update reasons 4, 5, 6, 7 and 8 indicate that the
associated resources are released at the client side, and
therefore the PPS shall not allocate a new quota in the RADIUS
Access_Accept message.
1. Pre-initialization
2. Initial request
3. Threshold reached
4. Quota reached
5. Remote Forced disconnect
6. Client Service termination
7. Main SI released
8. Service Instance not established
Sub-Type (=9) : Sub-Type for PrePaidServer attribute
Length : Length of PrePaidServer
(IPv4 = 6 octets, IPv6= 18 octets
PrePaidServer:
The optional, multi-value PrePaidServer indicates the address of
the serving PrePaid System. If present, the Home RADIUS server
uses this address to route the message to the serving PrePaid
Server. The attribute may be sent by the Home RADIUS server. If
present in the incoming RADIUS Access-Accept message, the PDSN
shall send this attribute back without modifying it in the
subsequent RADIUS Access-Request message, except for the first
one. If multiple values are present, the PDSN shall not change
the order of the attributes.
NOTES:
Either Volume-Quota or Time-Quota MUST appear in the attribute.
Volume Threshold may only appear if Volume Quota appears
If the Access Device can measure time, and if Time-Threshold appears
with Volume Quota, then the Access device should trigger a quota
replenishment when the Current Time >= Time-Threshold.
> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: Thursday, March 25, 2004 3:04 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: RE: RADEXT charter, Take 8
>
>
> Maybe it will help a bit to look at the definitions of each
> of the attributes you've cited. From what I can tell, there
> are quite a few examples of complex "String" fields sent from
> RADIUS server to NAS. In some cases, these fields are
> calculated on the fly, requiring a RADIUS server code change
> (e.g. Tunnel Password) but in other cases, the field could be
> entered statically by an admin with the patience to do so.
>
> There are also examples of complex "String" fields sent from
> NAS to RADIUS server, which require the RADIUS server to
> parse them (e.g. CHAP-PASSWORD, ARAP-PASSWORD).
>
> And there is an example of "Grouped AVPs" (e.g. Vendor-Specific).
>
> Based on what has been done before, perhaps we can examine
> the proposals to see how they compare to established usage.
> In this discussion, I think it would be helpful to avoid use
> of the term "sub-attribute" or "sub-type" since this seems to
> be used to refer to a variety of quite different things --
> from "Grouped AVPs" to "complex strings". As a result, I
> think we may be suffering from some terminology confusion.
>
>
> > User-Name
>
> This is defined in Section 5.1 of RFC 2865 as follows:
>
> 0 1 2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> | Type | Length | String ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> So this is just an element of type "String". Proxies
> do parse (and even edit) this attribute.
>
> > Chap-Password IDENT + PASSWORD
>
> This is defined in Section 5.3 of RFC 2865 as follows:
>
> 0 1 2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> | Type | Length | CHAP Ident | String ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> So here we have a one octet identifier followed by a
> "String". RADIUS servers do need to parse this in order to
> validate the password.
>
> > Framed-Route A list of IP-Addresses.
>
> This is defined in Section 5.22 of RFC 2865 as follows:
>
> 0 1 2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> | Type | Length | Text ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> Where "Text" is defined this way:
>
> The Text field is one or more octets, and its contents are
> implementation dependent. It is intended to be human
> readable and
> MUST NOT affect operation of the protocol. It is
> recommended that
> the message contain UTF-8 encoded 10646 [7] characters.
>
> For IP routes, it SHOULD contain a destination prefix in dotted
> quad form optionally followed by a slash and a decimal length
> specifier stating how many high order bits of the prefix to use.
>
> Here the admin enters the string and it is sent to the NAS
> where it is parsed.
>
> > Vendor-Specific allows more then one attribute.
>
> Section 5.26 of RFC 2865 says the following:
>
> The String field is one or more octets. The actual format of the
> information is site or application specific, and a robust
> implementation SHOULD support the field as
> undistinguished octets.
>
> The codification of the range of allowed usage of this field is
> outside the scope of this specification.
>
> It SHOULD be encoded as a sequence of vendor type /
> vendor length
> / value fields, as follows. The Attribute-Specific field is
> dependent on the vendor's definition of that attribute. An
> example encoding of the Vendor-Specific attribute using this
> method follows:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Vendor-Id
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Vendor-Id (cont) | Vendor type |
> Vendor length |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Attribute-Specific...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> Multiple subattributes MAY be encoded within a single Vendor-
> Specific attribute, although they do not have to be.
>
> Here there is parsing on the RADIUS server side.
>
> > Tunnel-Password Salt plus password
>
> This is defined in Section 3.5 of RFC 2868:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Tag | Salt
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Salt (cont) | String ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Here the RADIUS server needs to choose the salt and then
> calculate the "String" portion appropriately, then send this
> to the NAS.
>
> > ARAP-Password Multiple values
>
> This is defined in Section 5.4 of RFC 2869:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Value1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value2
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value4
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Looks like parsing is required on the RADIUS server for this
> one, though I'm no ARAP expert.
>
> > ARAP-Features Again multiple-values
>
> This is defined in Section 5.5 of RFC 2869:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Value1 | Value2 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value3 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value4 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value5 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Ditto.
>
> > Connect-Info a bunch of attributes.
>
> This is defined in Section 5.11 of RFC 2869:
>
> 0 1 2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Text...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Where "Text" is defined as follows:
>
> The Text field consists of UTF-8 encoded 10646 [8] characters.
> The connection speed SHOULD be included at the beginning of the
> first Connect-Info attribute in the packet. If the transmit and
> receive connection speeds differ, they may both be
> included in the
> first attribute with the transmit speed first (the speed the NAS
> modem transmits at), a slash (/), the receive speed, then
> optionally other information.
>
> For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
>
> More than one Connect-Info attribute may be present in an
> Accounting-Request packet to accommodate expected efforts by ITU
> to have modems report more connection information in a standard
> format that might exceed 252 octets.
>
> So here, the NAS sends a String to the RADIUS server which
> typically just stores it.
>
> > Framed-IPv6-Prefix Prefix-Length and Pre-fix
>
> This is defined in Section 2.3 of RFC 3162:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Reserved | Prefix-Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Prefix
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Prefix
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Prefix
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Prefix |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> This can be stored as a string on the RADIUS server and sent
> to the NAS, which parses it.
>
> > Framed-IPv6-Route a list of ip addresses
>
> This is defined in Section 2.5 of RFC 3162:
>
> 0 1 2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> | Type | Length | Text ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> Where "Text" is defined as:
>
> The Text field is one or more octets, and its contents are
> implementation dependent. The field is not NUL (hex 00)
> terminated. It is intended to be human readable and MUST NOT
> affect operation of the protocol.
>
> For IPv6 routes, it SHOULD contain a destination prefix
> optionally
> followed by a slash and a decimal length specifier stating how
> many high order bits of the prefix to use. That is
> followed by a
> space, a gateway address, a space, and one or more metrics
> (encoded in decimal) separated by spaces. Prefixes and
> addresses
> are formatted as described in [16]. For example,
> "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
>
>
--
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/>