2 Diameter Message Encoding

Overview

Introduction

This chapter details the Diameter Charging Driver (DCD) message encoding.

Diameter Message Encoding

Introduction

The DCD client will send (and expect to receive) DIAMETER messages that have a basic encoding in complete compliance with RFC 6733.

Diameter Headers

The header of Diameter messages sent by DCD are fully compliant with RFC 6733.

The individual parameters are:

Field Type/Length Comment
Version 1 byte Always set to 1
Message Length 3 bytes Length includes header fields.
Command Flags 1 byte

Format: RPETrrrr

All set as per RFC 6733.

Command Code 3 bytes

Will be one of:

  • 257 (CER/A)
  • 280 (DWR/A)
  • 282 (DPR/A)
  • 272 (CCR/A)
Application ID 4 bytes Set to 4 for CCRs, 0 for all other message types.
Hop-by-hop identifier Unsigned32; 4 bytes as per RFC 6733
End-to-end identifier Unsigned32; 4 bytes as per RFC 6733

Attribute-Value Pairs (AVPs)

The header on an AVP consists of the following fields:

Field Type/Length Comment
AVP Code 4 bytes  
AVP Flags 1 byte

Format: VMPrrrrr:

V is vendor bit. Will be set only if a vendor-ID is used.

M is mandatory bit: If the AVPCode is from RFC 6733 or 4006, the bit is set. Otherwise (for example, a vendor specific AVP code), the bit is not set.

P is encryption indicator. Set to 0.

AVP Length 3 bytes AVP length in bytes, including these header fields.
Vendor-ID 4 bytes Will be 0 for RFC 6733 and 4006 AVPs or 16247 for eServ specific AVPs.
Data   As specified by the AVP code and length.

AVP Data Types

The DCD can send and receive the all basic and derived data types mentioned in RFC 6733, with the exception of Float32 and Float64 which are not used by CCS.

Where the data types are used, they are encoded in complete compliance with RFC 6733 and RFC 2279.

The OctetString type can have number values as an array of either ASCII characters or integers.