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 ::= < 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 ::= < 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 ::= * {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. ::= {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-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. ::= {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. ::=< 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]