Internet DRAFT - draft-grayson-aaa-serviceflows
draft-grayson-aaa-serviceflows
Authentication, Authorization and Accounting Mark Grayson
Internet Draft Cisco Systems
Draft: draft-grayson-aaa-serviceflows-00.txt> June 2003
Expires: December 2003
Diameter NASREQ Extensions for the Delivery of
Service-Flow Charging Rules
Status of this memo
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments should
be directed to the authors.
Abstract
This document specifies a Diameter authorization extension that is used
for the delivery of Service-Flow Charging Rules. These Service-Flow
Charging Rules identify service flows that can be used within a
credit control environment for distinguishing individual packet flows
for which credit control applies. Multiple Service-Flows can be
provided which then enable independent rating of the individual packet
flows. Service-Flows can be provided at authentication and may be
dynamically updated throughout the lifetime of an AAA session.
TABLE OF CONTENTS
Status of this Memo..................................................1
Abstract.............................................................1
Table of Contents....................................................1
Grayson Expires - December 2003 [Page 1]
Diameter Service-Flow Charging Rules June 2003
1 Introduction.......................................................2
1.1 Requirements Language............................................3
1.2 Terminology......................................................3
2 Architectural Model................................................4
3 Service Definition.................................................5
3.1 Flow Activation..................................................6
3.2 Service Termination..............................................6
3.3 Service Flow Re-activation.......................................7
4 NASREQ Diameter Extensions.........................................7
4.1 AA-Request Message...............................................7
4.2 AA-Answer Message................................................8
4.3 Server Initiated Operations......................................10
5 AVPs ..............................................................11
5.1 Service-Flow-Rules-Supported.....................................11
5.2 Service Flow Definitions.........................................11
6 AVP Occurrence Table...............................................11
7 IANA Considerations................................................15
8 Diameter to RADIUS Interworking....................................15
8.1 Interworking with AA-Request.....................................15
8.2 Interworking with AA-Answer......................................15
8.3 Interworking with Server Initiated Operations....................17
8.4 RADIUS VSA occurrence Table......................................17
9 References.........................................................17
10 Author's Address..................................................18
1 Introduction
Diameter Credit Control Application as defined in [HAKALA] defines an
accounting protocol that can be used for real time cost and credit
control in a service-environment. This Diameter Credit Control
application is used for the real-time delivery of service event
information from a service element to a credit control server. Key to
the operation of Diameter Credit Control is the ability of the service
element to identify a particular service flow for which such credit
control applies.
This NASREQ [NASREQ] extension for delivery of Service-Flow Charging
Rules is used within such an environment in order to provide the
definition and transport of the "service" to the service element.
Techniques are defined which allow the correlation between service
rules provided by this Diameter Extension and the subsequent credit
requests made, e.g., using the Diameter Credit Control application.
This Diameter Service-Flow Charging Rule Extension supports a multi-
service environment where individual services are defined by service
flows. In a multi-service environment, it might happen that an end user
with already on-going service (e.g., a voice call) issues a new service
request (e.g. data service) towards the same account or during an
active multimedia session an additional media type is added to the
Grayson Expires - December 2003 [Page 2]
Diameter Service-Flow Charging Rules June 2003
session causing a new simultaneous request towards same account. Using
Diameter Service-Flow Charging Rules these independent services MUST be
identified by unique charging rules.
Service rule definition MAY include whether a rule is to be
automatically activated or whether the service element SHOULD wait for
an asynchronous trigger to activate the service rule. The definition of
such an asynchronous trigger is out of scope of this document but, for
example, can include the user interacting with a web portal which
advertises a new service. Furthermore, whilst the definition of a
Service-Flow Charging Rule is compatible with the support of triggered
de-activation of an already active service rule, it does not specify
how such de-activation is achieved.
Finally, the Diameter Service-Flow Charging Rule Extension allows for
the asynchronous delivery and installation of new service rules and
deletion of existing charging rules. This allows for dynamic creation
and delivery of the charging rule to the service element. For example,
it might happen that a user is engaged in establishing a SIP call and
that the detailed service flow definition is only known following SDP
negotiation. In such an example, the service flow will be
asynchronously installed after SDP has been negotiated and subsequently
deleted after the media stream corresponding to the SDP has been
terminated.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [KEYWORDS].
1.2 Terminology
Content-Flow: [TBD]
IP-flow: identified by {source address, destination address, source
port, destination port, protocol}
Service Element: an element which includes a credit control client
Service rule: a collection of 1 or more content-flows and/or IP-flows.
Service key: an identifier which enables correlation of service rules
provided by the Diameter Service-Flow Charging Rule Extension with
credit control procedures.
2 Architectural Model
The architectural model builds on that introduced in [HAKALA] which
Grayson Expires - December 2003 [Page 3]
Diameter Service-Flow Charging Rules June 2003
defines service elements which are responsible for collecting service
event information and reporting this information to a credit control
server. In order to reduce credit risk, service authorization is
required prior to service delivery.
Such an architecture assumes that the definition of the ?service? is
shared a priori by the service element and the credit control server.
The Diameter Service-Flow Charging Rule extension is used to share such
service definition between the Service Element and the Credit Control
Server. Figure 1 shows the architecture for Diameter Service-Flow
Charging Rules within an on-line charging model.
accounting
+------------+ +-----------+ protocol +--------------+
| End |<----->| Service |<------------>| Accounting |
| User | +-->| Element |<-----+ | Server |
+------------+ | | |<--+ | +--------------+
| +-----------+ | |
+------------+ | | |
| End |<--+ | | +--------------+
| User | | +------>|Credit Control|
+------------+ | credit | Server |
| control +--------------+
| protocol
| +--------------+
+--------->|Authentication|
service |Authorization |
flow |and Charging |
charging |Rules Server |
rules +--------------+
extensions
Figure 1: Diameter Service-Flow Charging Rules within a Diameter
Credit Control Environment.
The credit control server, accounting server and charging rules server
in this architecture model are logical entities. The real configuration
MAY combine then into a single host.
There MAY exist protocol transparent Diameter relays and redirect
agents between the charging rules client and the charging rules server.
These agents transparently support the Diameter Service-Flow Charging
Rules extension.
The rules delivered from the Authentication, Authorization and Charging
Rules server to the Service Element allow this element to unambiguously
identify service flows which SHOULD be independently accounted for.
Accounting MAY use on-line accounting techniques, e.g., Diameter Credit
Control application, or MAY be charged in an off-line manner. In order
to accommodate flexible environments supporting a mix of off-line and
on-line accounting methods, the Diameter Service-Flow Charging Rule
Grayson Expires - December 2003 [Page 4]
Diameter Service-Flow Charging Rules June 2003
Extension SHOULD indicate to the service element the accounting mode to
be used for a corresponding service flow.
Within the service element all service flows follow a common state
model. Service flows are first installed in the service element and
normally, if they are to be used for accounting, activated. A service
flow can be defined to automatically self-activate or be activated
asynchronously. Triggering of an asynchronous activation might require
the definition and support of service element specific procedures and
is out of scope of this draft.
Following activation, a service flow MAY be de-activated, modified or
de-installed. A de-activated service flow may be re-activated without
re-installation. Techniques for triggering service de-activation
include termination by the credit control application or by some
service element specific interface. Triggered de-activation is out of
the scope of this draft.
Installed service flows (both active and in-active) MAY be modified by
using the Diameter Service-Flow Charging Rule Extension using the
server initiated procedures described in section 4.3 below. During a
charging rule update procedure, the Charging Rules server MUST use the
same Service-Flow-ID AVP to identify the modified service rule. The
detailed operation of the accounting protocol under such operation is
out of scope of this draft but, for example in a Diameter Credit
Control environment the modification of an active service flow can
include the termination of the existing DCC accounting session and the
re-establishment of a new DCC accounting session using the modified
rule.
Installed service flows (both active and in-active) MAY be de-installed
by using the Diameter Service-Flow Charging Rule Extension. De-
installation of an active service flow SHOULD trigger the service
element to gracefully close the corresponding accounting session.
3 Service Definition
Diameter Credit Control Application defines a service as some task
performed by the service element. The Diameter Service-Flow Charging
Rule Extension enables the service definition to be provided to the
service element from a charging rules server. The definition of a
service allows cross-referencing with those requests issued using the
credit control procedures, e.g., using the Diameter Credit Control
Application.
A service is defined using flow identifiers. A flow identifier can
identify a particular 5-tuple IP flow {source address, destination
address, source port, destination port, protocol}, a combination of 5-
Tuples, or identified by a more complex content rule, designated a
Content Flow, or identified by a combination of IP-flow(s) and Content-
Flow(s).
Grayson Expires - December 2003 [Page 5]
Diameter Service-Flow Charging Rules June 2003
3.1 Service Flow Activation
Service flows MAY be provided to the service element at AAA session
authorization or MAY be provided asynchronously throughout the duration
of a session. Service flow descriptions include whether the service
flow MUST be immediately installed on the service element or whether
the service flow installation MUST be delayed until some asynchronous
event has occurred.
3.2 Service Termination
Service Termination may be performed by an end-user or end-user agent
or by some credit control application, e.g., using the techniques
described in the Diameter Credit Control Application. A terminated
service MUST trigger the de-activation of the service flow. This does
not prevent such a de-activated service from being re-activated at a
later stage.
3.2.1 Service Termination by Credit Control Application
According to the Credit Control Application, it may be defined that
when all the granted units are used and no other units are available to
be granted, e.g., in a DCC environment after a Final-Unit-Indication
AVP has been received from the credit control server, the credit
control client in a service element is responsible for correct handling
of the service.
Whilst the Credit Control Application may indicate that a client should
terminate the corresponding service, the Diameter Service-Flow Charging
Rule Extension allows for over-riding of such default behavior.
The Termination Action AVP is used to indicate to the Credit Control
Client in the service element whether on termination due to consumption
of the finally granted units, the service element MUST
1) drop the packets corresponding to the de-activated service flow
This is the default behavior and allows a pre-paid service to be
implemented with no loss of credit
2) pass those packets corresponding to the de-activated service flow
terminated by the Credit Control Application
In a pre-paid environment, this will require some additional technique
in order to reduce credit risk, for example triggering the de-
activation of a user?s layer 2 session.
3) redirect those packets corresponding to the de-activated service
flow terminated by Credit Control Application
Re-direction of the user?s service flow recognizes that whilst access
to a non-zero rated service is curtailed due to the user?s expired
Grayson Expires - December 2003 [Page 6]
Diameter Service-Flow Charging Rules June 2003
balance, a service provider may still support zero-rated services, e.g.,
for on-line balance top-up.
Re-direction of HTTP can be particularly useful. Dropping of the
packets corresponding to a de-activated service flow by the service
element will cause the non-graceful closure of the transport connection.
HTTP 1.1 [RFC2616] defines mandatory functionality to allow clients,
servers and proxies to recover from such asynchronous close events.
Under such circumstances, the client software will reopen the transport
connection and retransmit the aborted sequence of requests without user
interaction.
This new connection can be re-directed by the Service Element to a
specific re-direct server. Service flows to this re-direct server will
normally be zero-rated by the Credit Control Application. Once re-
directed, the user can be displayed appropriate information, e.g., why
access has been limited and offered an opportunity for on-line balance
top-up.
3.2.2 Service Flow Termination by user or user-agent
Service flows MAY be de-activated by other means than the Credit
Control application, e.g., by an end-user.
3.3 Service Flow Re-activation
A de-activated Service-Flow MAY be re-activated by a user or user-agent.
For example, it can happen that a session has been terminated and re-
directed to a server advertising a balance top-up service. Following
suitable balance top-up, the previously terminated service can be re-
activated.
4 NASREQ Diameter Extensions
4.1 AA-Request Message
[to be completed]
Message Format
::= < Diameter Header: 265, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ NAS-Port ]
[ Origin-State-Id ]
[ Destination-Host ]
[ NAS-IP-Address ]
Grayson Expires - December 2003 [Page 7]
Diameter Service-Flow Charging Rules June 2003
[ NAS-Identifier ]
[ NAS-Port-Type ]
[ Port-Limit ]
[ User-Name ]
[ User-Password ]
[ Service-Type ]
[ Idle-Timeout ]
[ State ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Session-Timeout ]
[ NAS-Key-Binding ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Connect-Info ]
[ CHAP-Auth ]
[ CHAP-Challenge ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
* [ Framed-IPv6-Prefix ]
[ Framed-IP-Address ]
[ Framed-IP-Netmask ]
[ Framed-MTU ]
[ Framed-Protocol ]
[ ARAP-Password ]
[ ARAP-Security ]
* [ ARAP-Security-Data ]
* [ Login-IP-Host ]
[ Login-LAT-Group ]
[ Login-LAT-Node ]
[ Login-LAT-Port ]
[ Login-LAT-Service ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
[ Service-Flow-Rules-Supported]
* [ AVP ]
4.2 AA-Answer Message
[to be completed]
Message Format
::= < Diameter Header: 265, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
Grayson Expires - December 2003 [Page 8]
Diameter Service-Flow Charging Rules June 2003
{ Origin-Realm }
[ User-Name ]
[ Service-Type ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Re-Auth-Request-Type ]
[ Session-Timeout ]
[ State ]
* [ Reply-Message ]
[ Origin-State-Id ]
* [ Filter-Id ]
* [ NAS-Session-Key ]
[ Password-Retry ]
[ Port-Limit ]
[ Prompt ]
[ ARAP-Challenge-Response ]
[ ARAP-Features ]
[ ARAP-Security ]
* [ ARAP-Security-Data ]
[ ARAP-Zone-Access ]
[ Callback-Id ]
[ Callback-Number ]
[ Framed-Appletalk-Link ]
* [ Framed-Appletalk-Network ]
[ Framed-Appletalk-Zone ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
* [ Framed-IPv6-Prefix ]
[ Framed-IPv6-Pool ]
* [ Framed-IPv6-Route ]
[ Framed-IP-Address ]
[ Framed-IP-Netmask ]
* [ Framed-IP-Route ]
[ Framed-IPX-Network ]
[ Framed-MTU ]
[ Framed-Protocol ]
[ Framed-Routing ]
* [ Login-IP-Host ]
[ Login-LAT-Group ]
[ Login-LAT-Node ]
[ Login-LAT-Port ]
[ Login-LAT-Service ]
[ Login-Service ]
[ Login-TCP-Port ]
* [ NAS-Filter-Rule ]
* [ Tunneling ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
Grayson Expires - December 2003 [Page 9]
Diameter Service-Flow Charging Rules June 2003
* [ Proxy-Info ]
* [ Install-Charging-Rule ]
* [ AVP ]
[to be completed]
4.3 Server Initiated Operations
A Diameter Server may initiate procedures to de-install, modify or
install a new charging rule. The procedure is initiated for a
particular session by issuing a Re-Auth-Request (RAR) [DIAMBASE].
A service entity that receives a RAR message including at least one
Charging Rules AVP with Session-Id equal to a currently installed
Service-Flow MUST initiate Charging Rules Modification/De-installation.
4.3.1 Sever Initiated De-Installation of Charging Rules
The server initiated de-installation of a charging rule is triggered by
the inclusion of the Delete-Charging-Rule AVP.
Message Format
<RAA> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
[ Delete-Charging-Rules ]
* [ AVP ]
4.3.2 Server Initiated Installation of Charging Rule
The server initiated installation of a new charging rule is triggered
by the inclusion of one or more Install-Charging-Rule AVP(s).
Message Format
<RAA> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
Grayson Expires - December 2003 [Page 10]
Diameter Service-Flow Charging Rules June 2003
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Install-Charging-Rule ]
* [ AVP ]
5 AVPs
This section defines the Vendor Specific Diameter AVPs that are used to
transport the charging flow definitions. All Vendor Specific Diameter
AVPs used for the delivery of service flow based charging rules use the
Vendor-ID set to [TBD].
5.1 Service-Flow-Rules-Supported
The Service-Flow-Rules-Supported AVP is of type Unsigned32 (AVP Code
TBD) and can be one of the following:
SERVICE_FLOW_RULES_IGNORED 0
The service element indicates to the Authentication, Authorization and
Charging Rules server that if service flows are returned in the AA-
Response message they will be ignored
SERVICE_FLOW_RULES_REQUESTED 1
The service element indicates to the Authentication, Authorization and
Charging Rules server that service flows SHOULD be returned in the AA-
Response message
5.2 Service Flow Definitions
<Delete-Charging-Rules>::=<AVP header: TBD>
* {Service-Flow-Id}
The Delete-Charging-Rules AVP is of type Grouped and contains a list of
service flow identities corresponding to flows/rules which MUST be de-
installed.
<Install-Charging-Rule>::=<AVP header: TBD>
{Service-Flow-Id}
{Online-Offline}
{Flow-Activation}
* [Content-Service-Flow]
* [IP-Service-Flow]
[DCC-Termination-Info]
[Service-Parameter-Info]
[Non-Matching-Packet-Rule]
The Install-Charging-Rule AVP is of type Grouped and contains a single
Grayson Expires - December 2003 [Page 11]
Diameter Service-Flow Charging Rules June 2003
service flow rule together with a unique reference identity.
5.2.1 Service-Flow-Id AVP
The Charging-Rule-Id AVP (AVP code TBD) is of type UTF8String and is
used to identify a specific charging rule.
5.2.2. On-line or off-line charging
The Diameter Service flow based Charging Rules application MAY be used
to transport the rules which define on-line charging, or MAY be used to
define rules which apply to off-line charging.
The Online-Offline AVP is of type Unsigned32 (AVP Code TBD) and can be
one of the following:
ON-LINE 0
On-line credit control application apply to this flow
OFF-LINE 1
On-line credit control application does not apply to this flow
5.2.3. Flow Activation
The Diameter Service-Flow Charging Rule extension MAY be used to
transport the rules which MUST be activated immediately or those which
MUST require some out of band activation procedure on the service
element.
The Flow-Activation AVP is of type Unsigned32 (AVP Code TBD) and can be
one of the following:
IMMEDIATE_ACTIVATION 0
The service flow MUST be immediately activated on the service element.
DELAYED_ACTIVATION 1
The activation of the service flow is delayed until some asynchronous
event occurs on the service element. This asynchronous event is out of
scope of this document.
5.2.4 Content-Service-Flow AVP
<Content-Service-Flow>::=<AVP header: TBD>
* [Content-IP-Filter]
* [Content-URL]
5.2.4.1 Content-IP-Filter AVP
The Content-IP-Filer AVP (AVP code TBD) is of type IPFilterRule. Any
packet which matches a DENY statement in the Content-IP-Filer AVP MAY
skip further checking against possible Host and URL matches.
Grayson Expires - December 2003 [Page 12]
Diameter Service-Flow Charging Rules June 2003
5.2.4.2 Content-URL AVP
The Content-URL AVP (AVP code TBD) is of type UTF8String. The format is
defined as:
[?*?][URL-Host][?*?][URL-object]
where URL-Host corresponds to the matching filter used to identify the
host part of the Universal Resource Locator (URL) and URL-object
corresponds to the matching filter used to identify the requested
object.
Examples of Content-URL AVP include:
?*.amazon.com?
?*.amazon.*?
?www.bbc.*?
?*.movies.com/*.mpg?
5.2.4.3 IP-Service-Flow AVP
IP-Service-Flow AVP (AVP code TBD) is of type IPFilterRule and provides
filter rules that define task implemented on the service element. Any
filter-rule listed with action set to ?deny? MAY be ignored by the
service element.
5.2.5 DCC-Termination-Info
The DCC-Termination-Info describes the action the session entity MUST
perform when the service flow is terminated by the Credit Control
application. It SHOULD only be present when the service flow identifies
a flow to be charged using on-line credit control. When not present,
the default behavior MUST be set to DROP_PACKETS.
<DCC-Termination-Info>::=<AVP Header: TBD>
{Termination-Identifier}
[Redirect-Server-Type]
[Redirect-Server-Address]
5.2.5.1 Termination Identifier AVP
The Termination-Identifier AVP is of type Unsigned32 (AVP Code TBD) and
can be one of the following:
PASS_PACKETS 0
The packet termination action is to pass any packets after the Credit
Control client has terminated the session
DROP_PACKETS 1
The packet termination action is to drop any packets after the Credit
Control client has terminated the session
REDIRECT_PACKETS 2
The packet termination action is to redirect any packets even after the
Grayson Expires - December 2003 [Page 13]
Diameter Service-Flow Charging Rules June 2003
Credit Control client has terminated the session
5.2.5.2 Redirect-Server-Type AVP
The Redirect-Server-Type AVP is of type Unsigned32 (AVP code TBD). It
SHOULD only be present when the Termination-Identifier AVP is set to
REDIRECT_PACKETS. The value and can be one of the following:
FQDN 0
IP Address 1
5.2.5.3 Redirect-Server-Address
The Redirect-Server-Address AVP is of type UTF8String. It SHOULD only
be present when the Termination-Identifier AVP is set to
REDIRECT_PACKETS. This string is either the fully qualified domain
name (FQDN) of the redirect server client machine, or it is a "dotted-
decimal" IP address.
5.2.6 Service-Parameter-Info AVP
The Service-Parameter-Info AVP is of type Grouped and is used provide
the service entity with a correlation key which it can be subsequently
use in the Credit Control application.
<Service-Parameter-Info>::=< AVP Header: TBD >
[ Service-Parameter-Type ]
[ Service-Parameter-Value ]
5.2.6.1 Service-Parameter-Type AVP
The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code TBD) and
defines the type of the service event specific parameter (e.g. it can
be end-user location, service name). The different parameters and their
types are service specific and the meanings of these parameters are not
defined in this document. The Service-Parameter-Value AVP contains the
service parameter type.
5.2.6.2 Service-Parameter-Value AVP
The Service-Parameter-Value AVP is of type UTF8String (AVP Code TBD)
and contains the value of the service parameter type.
5.2.7 Non-Matching-Packet-Rule
Non-Matching-Packet-Rule AVP is of type Unsigned32 (AVP Code TBD) and
can be one of the following:
PASS_PACKETS 0
Packet not matching any defined charging rules are passed by the
service entity
Grayson Expires - December 2003 [Page 14]
Diameter Service-Flow Charging Rules June 2003
DROP_PACKETS 1
Packet not matching any defined charging rule are dropped by the
service entity
When not present the default behavior is set to DROP_PACKETS.
6 AVP Occurrence Table
[to be completed]
7 IANA Considerations
[to be completed]
8 Diameter to RADIUS Interworking
Whilst the delivery of Service-Flow charging rules has immediate
applicability to a Diameter Credit Control environment, the delivery of
rules can also be applicable to legacy RADIUS implementations or other
credit control environments. In such circumstances, the interworking
between Diameter and RADIUS is defined. Interworking makes use of
RADIUS Vendor Specific Attributes (VSAs) [RFC2865] for transporting
service flow based charging rules.
8.1 Interworking with AA-Request
RADIUS Interworking with Diameter AA-Request message uses the following
VSA included with the RADIUS Access Request message.
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | SFlowSuppt | Integer |
+--------+----------+------------+-------------+-----------------+
SFlowSuppt can be one of the following:
SERVICE_FLOW_RULES_IGNORED 0
The service element indicates to the Authentication, Authorization and
Charging Rules server that if service flows are returned in the AA-
Response message they will be ignored
SERVICE_FLOW_RULES_REQUESTED 1
The service element indicates to the Authentication, Authorization and
Charging Rules server that service flows SHOULD be returned in the AA-
Response message
8.2 Interworking with AA-Answer
RADIUS Interworking with Diameter AA-Answer message uses the following
mandatory VSA included with the RADIUS Access Accept message.
Grayson Expires - December 2003 [Page 15]
Diameter Service-Flow Charging Rules June 2003
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | SFlowID | String |
| 26 | TBD | TBD | OnOffLine | Integer |
| 26 | TBD | TBD | AutoActive | Integer |
+--------+----------+------------+-------------+-----------------+
Optional individual Content-IP-Filters are identified using the
following VSAs.
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | FiltDirect | String |
| 26 | TBD | TBD | SrcAddress | String |
| 26 | TBD | TBD | SrcMask | String |
| 26 | TBD | TBD | SrcPorts | String |
| 26 | TBD | TBD | DstAddress | String |
| 26 | TBD | TBD | DstMask | String |
| 26 | TBD | TBD | DstPorts | String |
+--------+----------+------------+-------------+-----------------+
FiltDirect can be one of the following
?in? - corresponds to packets sent from the terminal
?out? - corresponds to packets sent to the terminal
[to be completed]
Optional individual Content-URLs are identified using the following
VSAs.
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | ContentUrl | String |
+--------+----------+------------+-------------+-----------------+
The termination action of the service flow based charging rules is
defined using the following VSAs
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | TermAction | Integer |
| 26 | TBD | TBD | RdirectID | Integer |
| 26 | TBD | TBD | RdirectVal | String |
+--------+----------+------------+-------------+-----------------+
The charging correlation value is provided using the following VSAs
Grayson Expires - December 2003 [Page 16]
Diameter Service-Flow Charging Rules June 2003
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | ServKeyType | Integer |
| 26 | TBD | TBD | ServKeyVal | String |
+--------+----------+------------+-------------+-----------------+
Finally, the information concerning how to handle non-matching packets
is provided using the following VSA
+--------+----------+------------+-------------+-----------------+
| AttrID | VendorID | SubAttr ID | SubAttrName | SubAttrDataType |
+--------+----------+------------+-------------+-----------------+
| 26 | TBD | TBD | NoMatchRule | Integer |
+--------+----------+------------+-------------+-----------------+
8.3 Interworking with Server Initiated Operations
Interworking with server initiated operations re-uses the Dynamic Re-
Authorization Extensions defined in [DYNAUTH]. Interworking makes use
of the above defined VSAs and uses a Change of Authorization command.
[to be completed]
8.4 RADIUS VSA occurrence Table
[to be completed]
9 References
[HAKALA] Hahala, H. et al, ?Diameter Credit Control Application?,
draft-ietf-aaa-diameter-cc-00.txt, work in progress, June 2003
[KEYWORDS] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[NASREQ] Calhoun, P. R. et al, ?Diameter NASREQ Application?, draft-
ietf-aaa-diameter-nasreq-09.txt, work in progress, March 2002
[RFC2616] Fielding, R. et al, ?Hypertext Transfer Protocol -- HTTP/1.1?,
RFC 2616, June 1999
[DIAMBASE] Calhoun, P. R. et al, ?Diameter Base Protocol?, draft-ietf-
aaa-diameter-17.txt, work in progress, December 2002
[RFC2865] Rigney, C. et al, ?Remote Authentication Dial In User Service
(RADIUS)?, RFC2865, June 2000
[DYNAUTH] Chiba, M. et al, ?Dynamic Authorization Extensions to Remote
Authentication Dial-In User Service (RADIUS)?, draft-chiba-radius-
dynamic-authorization-12.txt, Work in progress, April 2003
Grayson Expires - December 2003 [Page 17]
Diameter Service-Flow Charging Rules June 2003
10 Author's Address
Mark Grayson
11 Rue Camille Desmoulins
Issy Les Moulineaux
92782
France
E-mail: mgrayson@cisco.com
Phone: +33 6 19 98 40 99
Grayson Expires - December 2003 [Page 18]
