5 Compliance Tables

Overview

Introduction

This chapter identifies the level of compliance to RFC 6733 and RFC 4006.

Compliance to RFC 6733

Introduction - Section 1

This table lists the compliances for section 1.

Section Section Heading Compliance Level Comment
1 Introduction N/A  

Protocol Overview - Section 2

This table lists the compliances for section 2.

Section Section Heading Compliance Level Comment
2 Protocol Overview N/A  
2.1 Transport Fully compliant TCP + SCTP supported TCP is selected by default.
2.2 Security

Partially compliant

IPSec through g/w function

 
2.3 Application Compliance Fully compliant  
2.4 Application Identification Fully compliant  
2.5 Connection Management Fully compliant Connection is established and added to pool for use by Diameter sessions. Number of connections per Charging realm is configurable.
2.6 Peers N/A A list of static peers are configured using the SMS platform.
2.7 Realm Based Routing Not Supported No.
2.8 Role of agents N/A Convergent Charging Controller offer a Diameter client only.
2.9 Path Authentication N/A The list of valid paths are configured using the SMS management node.

Headers - Section 3

This table lists the compliances for section 3.

Section Section Heading Compliance Level Comment
3 Headers Fully compliant  
3.1 Command Codes Partially compliant

CER, CEA, DWR, DWA, DPR, DPA, RAR, RAA supported.

Each message may be enabled independently to allow support for various applications/peers.

3.2 ABNF Specification Fully compliant  
3.3 Naming Conventions Fully compliant  

Diameter AVPs - Section 4

This table lists the compliances for section 4.

Section Section Heading Compliance Level Comment
4 Diameter AVPs N/A  
4.1 AVP Header Fully compliant  
4.2 Basic AVP Data Formats Fully compliant  
4.3 Derived AVP Data Formats Fully compliant No Convergent Charging Controller specific AVPs are defined by default.
4.4 Grouped AVP Values Fully compliant  
4.5 Diameter Base Protocol AVPs Fully compliant Support for all AVPs needed for compliance to section 3.1

Diameter Peers - Section 5

This table lists the compliances for section 6.

Section Section Heading Compliance Level Comment
5 Diameter Peers N/A  
5.1 Peer Connections Fully compliant Multiple peers per realm are supported – where 2 peers are defined primary/secondary is assumed. For multiple peers load sharing is based on round-robin approach.
5.2 Peer discovery Non compliant The list of valid paths are configured using the SMS management node
5.3 Capability Exchange Fully compliant  
5.4 Disconnecting Peer Connections Fully compliant Supported non-persistently per client interface.
5.5 Transport Failure Fully compliant  
5.6 Peer State Machine Partially compliant  

Diameter Message Processing - Section 6

This table lists the compliances for section 5.

Section Section Heading Compliance Level Comment
6 Diameter Message Processing    
6.1 Request Routing Fully compliant Please note that proxy and forward are not supported
6.2 Diameter Answer Processing Fully compliant  
6.3 Origin-Host AVP Fully compliant  
6.4 Origin- Realm AVP Fully compliant  
6.5 Destination-Host AVP Fully compliant  
6.6 Destination- Realm AVP Fully compliant  
6.7 Routing AVPs Fully compliant  
6.8 Auth-Application-Id AVP Fully compliant  
6.9 Acct-Application-Id AVP Fully compliant  
6.10 Inband-Security ID AVP Fully compliant  
6.11 Vendor Specific Application-Id AVP Fully compliant No Convergent Charging Controller specific AVPs are defined today.
6.12 Redirect-Host AVP Non compliant No explicit routing supported.
6.13 Redirect-Host-Usage AVP Non compliant  
6.14 Redirect-Max-Cache-Time AVP Non compliant  

Error Handling - Section 7

This table lists the compliances for section 7.

Section Section Heading Compliance Level Comment
7 Error Handling    
7.1 Result-Code AVP Fully compliant  
7.2 Error Bit Fully compliant  
7.3 Error-Message ACP Fully compliant  
7.4 Error-Reporting-Host AVP Fully compliant  
7.5 Failed-AVP AVP Fully compliant This information may be included in the ACSapplication EDR for further debugging.
7.6 Experimental Result ACP Fully compliant  
7.7 Experimental Result Code AVP Fully compliant  

Diameter User Sessions - Section 8

This table lists the compliances for section 8.

Section Section Heading Compliance Level Comment
8 Diameter User Sessions    
8.1 Authorization Session State Machine Non compliant  
8.2 Accounting Session State Machine Partially compliant Implements only the client side of the state machine.
8.3 Server-Initiated Re-Auth Fully compliant  
8.4 Session Termination Fully compliant When Convergent Charging Controller receive this message from an application all session in progress will released and this information will be included in EDRs produced.
8.5 Abort Session Fully compliant When Convergent Charging Controller receive this message from an application all session in progress will released and this information will be included in EDRs produced.
8.6 Inferring Session Termination from Origin-State-Id Non compliant  
8.7 Auth-Request-Type AVP Non compliant  
8.8 Session-Id AVP Fully compliant  
8.9 Authorization-Lifetime AVP Non compliant  
8.10 Auth-Grace-Period AVP Non compliant  
8.11 Auth-Session-State AVP Non compliant  
8.12 Re-Auth-Request-Type AVP Non compliant  
8.13 Session Timeout AVP Fully compliant  
8.14 User Name AVP Fully compliant  
8.15 Termination Cause Fully compliant  
8.16 Origin State ID AVP Fully compliant  
8.17 Session Binding AVP Non compliant  
8.18 Session-Server-Failover AVP Non compliant  
8.19 Multi-Round-Time-Out AVP Non compliant  
8.20 Class AVP Non compliant  
8.21 Event Timestamp AVP Fully compliant  

Accounting - Section 9

This table lists the compliances for section 9.

Section Section Heading Compliance Level Comment
9 Accounting    
9.1 Server Directed Model Fully compliant  
9.2 Protocol Messages Partially compliant No IP compression is supported at this time. Support for negotiation is however provided.
9.3 Application document requirements Fully compliant See Credit Control Application defined in RFC 4006
9.4 Fault Resilience Fully compliant Please note that only the client side is implemented.
9.5 Accounting Records Fully compliant  
9.6 Correlation of Accounting Records Fully compliant  
9.7 Accounting Command-Codes Fully compliant  
9.8 Accounting AVPs Fully compliant  

AVP Occurrence Table - Section 10

This table lists the compliances for section 10.

Section Section Heading Compliance Level Comment
10 AVP Occurrence Table Partial compliant As detailed elsewhere in this document and as needed for CER, CEA, DWR, DWA, DPR, DPA, RAR, RAA

IANA Considerations - Section 11

This table lists the compliances for section 11.

Section Section Heading Compliance Level Comment
11 IANA Considerations    
11.1 AVP Header Fully compliant  
11.2 Diameter Header Fully compliant  
11.3 AVP Values Fully compliant

As detailed elsewhere in this document and as needed for CER, CEA, DWR, DWA, DPR, DPA, RAR, RAA.

Please note that unused AVPs are ignored by the Convergent Charging Controller client implementation.

11.4 Diameter TCP/SCTP Port Numbers Fully compliant  
11.5 SCTP Payload Protocol Identifiers Fully compliant  
11.6 NAPR Service Fields Fully compliant This information is updated when the client package is installed.

Diameter Protocol Related Configurable Parameters - Section 12

This table lists the compliances for section 12.

Section Section Heading Compliance Level Comment
12 Diameter Protocol Related Configurable Parameters Partial compliant Only statically configured peers are supported by Convergent Charging Controller.

Security Considerations - Section 13

This table lists the compliances for section 13.

Section Section Heading Compliance Level Comment
13 Security Considerations Fully compliant  

Compliance to Diameter Base Protocol Draft 8

Introduction

This section highlights compliance for the Diameter Base Protocol Draft 8 (refered to below as Draft 8), where there is variance for RFC 6733. Compliance is as per that for RFC 6733, unless stated otherwise.

Note: The use of Draft 8 is facilitated for compatibility with Ericsson SCAP. Stated levels of compliance only apply to the use of Draft 8, with SCAP.

Protocol Overview - Section 2

This table lists the compliances for section 2.

Section RFC 6733 Section Heading Compliance Level Comment
2.4 2.4 Application Identification Not compliant Not used for SCAP
N/A 2.9 End-to-end security N/A Not supported for Draft 8.

Headers - Section 3

This table lists the compliances for section 3.

Section RFC 6733 Section Heading Compliance Level Comment
3.0 3.0 Headers Fully compliant Note T (retransmit) flag is not supported in Draft 8.
3.2 3.2 ABNF Specification Partial compliance. Errors assumed in Draft 8.

In Section 3.2 of Draft 8, the Command Code ABNF specification appears to conflict with section 3.0, with respect to the position of Vendor-Id. This is assumed to be an error in Draft 8.

Similarly the definition for "qual" in section 3.2 appears to be ambiguous in Draft 8, but is clearer in RFC 6733.

Diameter AVPs - Section 4

This table lists the compliances for section 4.

Section RFC 6733 Section Heading Compliance Level Comment
4.4 4.3 Derived AVP Data Formats Fully compliant

IPAddress in Draft 8 is replaced by Address in RFC 6733. Address represents the address type, which contains an Address Family. This is as opposed to Draft 8 which determines the type of address based on the AVP length.

The Draft 8 definition for Diameter-Identity conflicts with RFC 6733, which has both Diameter-Identity (sometimes referred to as DiameterIdentity) and DiameterURI. Effectively the Draft 8 Diameter-Identity appears to match DiameterURI in RFC 6733. This is specified as a UTF8 String.

4.6 4.5 Diameter Base Protocol AVPs Partially compliant

Acct-Application-Id and Auth-Application-Id Draft 8, are specified Integer32 rather than Unsigned32. This is assumed to be a mistake as this conflicts with other sections within Draft 8 (that is, Section 6).

Destination-Realm and Origin-Realm, are specified as type UTF8String in Draft 8. However in RFC 6733 they are specified as type DiameterIdentity.

Host-IP-Address is missing from the list of Diameter Base Protocol AVPs for Draft 8. This is assumed to be an error as they are present in RFC 6733.

The AVP header flags for the Product-Name AVP differ.

For Error-Message (281) OctetString is used for Draft 8, instead of UTF8String.

For Error-Reporting-Host (294), UTF8String is used instead vs. DiameterIdentity

Diameter Peers - Section 5

This table lists the compliances for section 6.

Section RFC 6733 Section Heading Compliance Level Comment
5.1 5.1 Peer Connections Partially compliant. It is assumed that the "not invoke" versus "invoked" difference in section 5.1 is a correction to an existing mistake.
5.3.1 5.3.1 Capabilities Exchange -Request Fully compliant

Inband-Security-Id (AVP code 299), is not supported by Draft 8.

Similarly DIAMETER_NO_COMMON_SECURITY, is not supported in Draft 8 as a Result-Code.

5.3.2 5.3.2 Capabilities Exchange -Answer Partially compliant In Draft 8 Vendor-Specific-Application-Id, is shown as NOT grouped in CEA (but it is in CER). This lack of grouping in CEA is assumed to be a mistake.
5.3.5 5.3.5 Host-IP-Address AVP Fully compliant Host-IP-Address (257), is specified as an IPAddress type in Draft 8, but an Address in RFC 6733.
5.4.3 5.4.3 Disconnect-Cause AVP Partially compliant

Disconnect-Cause AVP, only features the value ELECTION_LOST in Draft 8. In RFC 6733, this is handled via the Result-Code AVP instead.

As per SCAP Programmer’s Guide, "CCN acts as a Diameter SCAP Server and does not initiate connections". Hence this is not implemented.

5.6 5.6 Peer State Machine Partially compliant There is no I-snd-DWR in section 5.6 of Draft 3588. This is not deemed to be an issue as R-snd-DWR from the peer will ensure connection is kept alive.

Diameter Message Processing - Section 6

This table lists the compliances for section 5.

Section RFC 6733 Section Heading Compliance Level Comment
6.6 6.6 Destination-Realm AVP Fully compliant Destination-Realm and Origin-Realm, are specified as type UTF8String in Draft 8. However in RFC 6733 they are specified as type DiameterIdentity.

Error Handling - Section 7

This table lists the compliances for section 7.

Section RFC 6733 Section Heading Compliance Level Comment
7.1.3 7.1.3 Protocol Errors Partially compliant

For Draft 8 Result-Codes 5011 through to 5017, subtract 1 to get the equivalent in RFC 6733, that is, DIAMETER_NO_COMMON_APPLICATION is 5011 for Draft 8 and 5010 for RFC 6733.

In RFC 6733, a Result-Code of 5017 is DIAMETER_NO_COMMON_SECURITY.

DIAMETER_UNSUPPORTED_TRANSFORM is not present in RFC 6733, and is unused by DCD However given that a CMS-Data AVP is not expected, this is not implemented.

Diameter User Sessions - Section 8

This table lists the compliances for section 8.

Section RFC 6733 Section Heading Compliance Level Comment
8.8 8.8 Session-Id AVP Fully compliant

Note: According to section 8.8 Draft 8, Session-Id must start with DiameterIdentity.

This is not enforced, but may be specified appropriately via configuration.

Accounting - Section 9

This table lists the compliances for section 9.

Section RFC 6733 Section Heading Compliance Level Comment
9.7 and 9.8 9.7 and 9.8 Accounting-Request Partially compliant

The SCAP version of the ACR message is assumed to take precedence to Draft 8.

Note: The Draft 8 Accounting-Interim-Interval (AVP Code 482), is replaced by Acct-Interim-Interval (85) in RFC 6733. If required this can be configured, according to a profile or a static value. However this optional is generally not used.

A number of (optional) AVPs are changed between Draft 8, RFC 6733 and SCAP Programmer’s Guide. Due to the configurable nature of DCD this should not cause too many issues. That is:

Accounting-Radius-Session-Id Draft 8 is not in RFC 6733 but is in SCAP Programmer’s Guide. This is replaced by Acct-Session-Id in RFC 6733.

AVP Occurrence Table - Section 10

This table lists the compliances for section 10.

Section RFC 6733 Section Heading Compliance Level Comment
10.2 10.2 Accounting AVP Table Partially compliant

In addition to above comments regarding Accounting messages, the following should be noted:

Termination-Cause is shown in Section 10.2 RFC 6733, but is not specified in Draft 8 or SCAP Programmer’s Guide, so it is assumed that this should not be sent.

IANA Considerations - Section 11

This table lists the compliances for section 11.

Section RFC 6733 Section Heading Compliance Level Comment
11.2.2 11.2.2 Command Flags Partially compliant Byte ordering is incorrect compared to other parts of the document and RFC 6733. It is assumed that the bits specified and byte order should be as per RFC 6733.

Compliance to RFC 4006

Introduction - Section 1

This table lists the compliances for sections 4.2 and 4.3 of the "Programmer’s Guide - Service Charging Based on Diameter Charging Control Node 5.

Section Section Heading Compliance Level Comment
4.2.1 Messages Fully compliant  
4.2.2 Diameter Base Protocol AVPs Partially compliant Refer to Draft 8 compliance above.
4.2.3 Defined Application Specific AVPs Fully compliant Values may be set according to configuration.
4.2.4 Description of Application Specific AVPs Fully compliant Values may be set according to configuration.
4.3.1 Service Charging Types Fully compliant  
4.3.2 Service Charging Methods Fully compliant  
4.3.3 List of Service Operations with Scenarios Fully compliant  

Architecture Model - Section 2

This table lists the compliances for section 2.

Section Section Heading Compliance Level Comment
2 Architecture Model Partial compliant Authentication and Authorization messages are not used

Credit-Control Messages - Section 3

This table lists the compliances for section 3.

Section Section Heading Compliance Level Comment
3 Credit-Control Messages Fully compliant  

Credit-Control Application Overview - Section 4

This table lists the compliances for section 4.

Section Section Heading Compliance Level Comment
4 Credit-Control Application Overview    
4.1 Service-Specific Rating Input and Interoperability Fully compliant Details of specific AVP implementation is given later in this document

Session Based Credit-Control - Section 5

This table lists the compliances for section 5.

Section Section Heading Compliance Level Comment
5 Session Based Credit-Control    
5.1.1 Basic Tariff-Time Change Support Non compliant  
5.1.2 Credit Control for Multiple Services within a Sub Session Non compliant  
5.2 First Interrogation Fully compliant  
5.3 Intermediate Interrogation Fully compliant  
5.4 Final Interrogation Fully compliant  
5.5 Server-Initiated Credit Re-Authorization Partially compliant DCA support RAR at all (sub)sessions granularity.
5.6 Graceful Service Termination Fully compliant Please note that if this information is not present from the Billing Server no post credit expiration behavior may be defined.
5.7 Failure Procedures Fully compliant Please note that if this information is not present from the Billing Server normal Billing Failure Treatment may be applied inside the Convergent Charging Controller system.

One Time Event - Section 6

This table lists the compliances for section 6.

Section Section Heading Compliance Level Comment
6 One Time Event    
6.1 Service Price Enquiry Fully compliant  
6.2 Balance Check Fully compliant  
6.3 Direct Debit Fully compliant  
6.4 Refund Fully compliant  
6.5 Failure Procedure Fully compliant The number of retries may be configured.

Credit-Control State Machine - Section 7

This table lists the compliances for section 7.

Section Section Heading Compliance Level Comment
7 Credit-Control State Machine Fully compliant Client side only is implemented

Credit-Control AVPs - Section 8

This table lists the compliances for section 8.

Section Section Heading Compliance Level Comment
8 Credit-Control AVPs    
8.1 CC-Correlation-ID AVP Fully compliant This field contains the unique identifier extracted from the session control protocol (that is, Call Reference from CAP). It is expected that this field be included in the BE EDR created.
8.2 CC-Request-Number AVP Fully compliant Implemented as per suggestion in RFC 4006.
8.3 CC-Request-Type AVP Fully compliant  
8.4 CC-Session-Failover AVP Fully compliant This parameter may be configured to allow/reject support for session failover.
8.5 CC-Sub-Session-Id AVP Non compliant  
8.6 Check-Balance-Result AVP Fully compliant  
8.7 Cost-Information AVP Fully compliant Please note that current balance information may be requested via this AVP group where Balance Check is requested with the Service-Identifier value set to ‘Information’.
8.8 Unit Value Fully compliant  
8.9 Exponent AVP Fully compliant  
8.10 Value Digits AVP Fully compliant  
8.11 Currency-Code AVP Fully compliant  
8.12 Cost-Unit AVP Fully compliant This value may be stored for SMS notification.
8.13 Credit-Control AVP Fully compliant  
8.14 Credit-Control-Failure-Handling AVP Fully compliant  
8.15 Direct-Debit-Failure-Handling Fully compliant  
8.16 Multiple-Services-Credit-Control AVP Non compliant Each session relates to only one network session.
8.17 Granted-Service-Unit AVP Fully compliant  
8.18 Requested-Service-Unit AVP Fully compliant Convergent Charging Controller implement Time, Money, Total Octets and CC-Service-Specific-Units only today.
8.19 Used-Service-Unit ACP Fully compliant  
8.20 Tariff-Time-Change AVP Non compliant  
8.21 CC-Time AVP Fully compliant  
8.22 CC-Money AVP Fully compliant  
8.23 CC-Total-Octets AVP Fully compliant  
8.24 CC-Input-Octets ACP Non compliant  
8.25 CC-Output-Octets ACP Non compliant  
8.26 CC-Service-Specific-Units AVP Fully compliant  
8.27 Tariff-Change-Usage AVP Non compliant  
8.28 Service-Identifier AVP Fully compliant This AVP may contain the special value ‘Information’ if a balance query is performed. Otherwise, this value is configured to be the CCS Capability as configured on the SLC for this particular interaction. Examples include ‘MO Voice’, ‘MT Voice’, ‘MO SMS’, and the rest.
8.29 Rating-Group AVP Fully compliant  
8.30 G-S-U Pool Reference AVP Non compliant  
8.31 G-S-U Pool Identifier AVP Non compliant  
8.32 CC-Unit-Type AVP Fully compliant  
8.33 Validity-Time AVP Fully compliant  
8.34 Final-Unit-Indication AVP Partially compliant Only Final-Unit-Indication of TERMINATE is supported.
8.35 Final-Unit-Action AVP Partially compliant Only Final-Unit-Action of TERMINATE is supported.
8.36 Restriction-Filter-Rule AVP Non compliant These rules are defined using the ACS Control Plan Editor.
8.37 Redirect-Server AVP Non compliant  
8.38 Redirect-Address-Type AVP Fully compliant  
8.39 Redirect-Server-Address AVP Fully compliant  
8.40 Multiple-Services-Indicator AVP Fully compliant Please note that multiple services are not requested by the client.
8.41 Requested-Action AVP Fully compliant This AVP may contain the special value '5' (VIEW_BALANCE) if the DIAMETER.DomainTypes.balanceEnquiry parameter is set to 'reqActionViewBalance'. The default value for balance queries is '2' (CHECK_BALANCE) when the parameter value is 'balanceCheck'.
8.42 Service-Context-Id AVP Fully compliant  
8.43 Service-Parameter-Info AVP Fully compliant This parameter is used to indicate supplementary rating information toward the BE. Only a single value is sent in this group. It is expected that the BE will use this value when determining the rate for the interaction.
8.44 Service-Parameter-Type AVP Fully compliant  
8.45 Service-Parameter-Value AVP Fully compliant  
8.46 Subscription-Id AVP Fully compliant  
8.47 Subscription-Id-Type AVP Fully compliant E164 and SIP URI.
8.48 Subscription-Id-Data AVP Fully compliant  
8.49 User-Equipment-Info AVP Non compliant  
8.50 User-Equipment-Info-Type AVP Non compliant  
8.51 User-Equipment-Info-Data AVP Non compliant  

Result Code AVP Values - Section 9

This table lists the compliances for section 9.

Section Section Heading Compliance Level Comment
9 Result Code AVP Values    
9.1 Transient Failures Fully compliant  
9.2 Permanent Failures Fully compliant  

AVP Occurrence Table - Section 10

This table lists the compliances for section 10.

Section Section Heading Compliance Level Comment
10 AVP Occurrence Table    
10.1 Credit-Control AVP Table Fully compliant  
10.2 Re-Auth-Request/Answer Table AVP Fully compliant  

RADIUS/Diameter Credit-Control Interworking Model - Section 11

This table lists the compliances for section 11.

Section Section Heading Compliance Level Comment
11 RADIUS/Diameter Credit-Control Interworking Model Non compliant  

IANA Considerations - Section 12

This table lists the compliances for section 12.

Section Section Heading Compliance Level Comment
12 IANA Considerations Fully compliant  

Credit-Control Application Related Parameters - Section 13

This table lists the compliances for section 13.

Section Section Heading Compliance Level Comment
13 Credit-Control Application Related Parameters Fully compliant Tx and Tcc timers are supported

Security Considerations - Section 14

This table lists the compliances for section 14.

Section Section Heading Compliance Level Comment
14 Security Considerations Fully compliant  
14.1 Direct Connection with Redirect Non compliant Statically configured peers are supported by Convergent Charging Controller.

Compliance to Ericsson SCAP

Overview

This section highlights compliance for to sections 4.2 and 4.3 of the "Programmer’s Guide - Service Charging Based on Diameter Charging Control Node 5".

Note: For SCAP the use of Diameter Base Protocol Draft 8 is required.

Compliance - Section 4

This table lists the compliances for section 1.

Section Section Heading Compliance Level Comment
1 Introduction N/A