Dia Base Protocol

Diameter Base Protocol
1 Diameter Base Protocol
TM32043EN05GLA0
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
1
DIAMETER protocol is intended to provide an Authentication, Authorization and

Accounting (AAA) framework for different applications. Therefore DIAMETER is split
into two components:
DIAMETER base protocol: The DIAMETER base provides the very basic
communication framework with messages and root parameter formats. It does not
contain any specific application message. The DIAMETER base protocol uses
TCP or SCTP for transmission of messages.
DIAMETER Application: The DIAMETER application is placed on top of the base
protocol to use the offered communication facilities. The DIAMETER application
itself provides new request/response messages specific for the services to be
provided by the application. Associated with this are parameters derived from the
basic parameter formats used for the application specific behavior.
Each Diameter application must have Application Identifier, assigned by IANA. The
base protocol does not require an Application Identifier since its support is
mandatory. During the capabilities exchange, Diameter nodes inform their peers of
supported Application. Furthermore, all Diameter messages contain an Application
Identifier. In this context, a Diameter Application means a protocol.
Example:
Cx and Dx Application:
Application ID: 16777216, Vendor: 3GPP, Vendor Id: 10415.
Sh and Dh Application:
Application ID:16777217, , Vendor: 3GPP, Vendor Id: 10415.
Gx Application:
Application ID: 16777238, , Vendor: 3GPP, Vendor Id: 10415.
Gy Application:
Application ID:4, , Vendor: 3GPP, Vendor Id: 10415.
Rx Application:
Application ID:16777236 , Vendor: 3GPP, Vendor Id: 10415.
TM32043EN05GLA0
2 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
Fig. 1 CSCF Interfaces
Fig. 2 HSS-FE Interfaces
TM32043EN05GLA0
3
1.1 Basic Terms

The Diameter Base protocol is defined in RFC 3588. It is intended to provide an
Authentication, Authorization and Accounting (AAA) framework for different
applications. The Diameter Base protocol provides the minimum requirements
needed for an AAA protocol.
Main components of the Diameter Base protocol:
A Diameter Client is a device that performs access control. It generates Diameter
messages to request authentication, authorization, and accounting services for the
user.
A Diameter server performs authentication and/or authorization of the user.
Generates answer message.
A Diameter node may act as a client for certain requests while acting as a server for
others.
Relay Agents are Diameter agents that accept requests and route messages to
other Diameter nodes based on information found in the messages (e.g., Destination-
Realm). Relays modify Diameter messages by inserting and removing routing
information, but do not modify any other portion of a message.
In the example provided in Figure 1, peer connection A is established between the
Client and its local Relay. Peer connection B is established between the Relay and
the Server. User session X is ranging from the Client via the Relay to the Server.
Proxy Agents are similarly to relays. They route Diameter messages using the
Diameter Routing Table. However, they differ since they modify messages by
implementation of policy enforcement. Proxies maintain the state of their downstream
peers (e.g. access devices).
Redirect Agents do not relay messages, and only return an answer with the
information necessary for Diameter agents to communicate directly. They do not
modify messages. Since redirect agents do not receive answer messages, they
cannot maintain session state.
The Diameter Base protocol is a peer-to-peer protocol. Any node can initiate a
request.
A connection is a transport level connection between two peers, used to send and
receive Diameter messages (e.g. TCP connection or SCTP association) .
A session is a logical concept at the application layer, and is shared between the
Diameter Client and the Diameter Server. It is identified via the Session-Id . The
Session-Id is globally unique and is meant to uniquely identify a user session without
reference to any other information.
TM32043EN05GLA0
Fig. 3 Diameter Base Protocol
TM32043EN05GLA0
5
1.2 DIAMETER routing principles

DIAMETER messages are routed based on the server realm, which is an
administrated domain name for the destination entities. This enables to built server
farms with many server platforms all describing the same logical destination.
In DIAMETER a node that receives a DIAMETER message has four different

possibilities:
LOCAL The DIAMETER request can be handled locally at the present

node. There is no need to forward the message to other
servers.
RELAY If a message falls into this category it must be forwarded to a
next hop DIAMETER server. The present node must not change
any parameters in the message except some routing
parameters.
PROXY In this case the present node must forward the message to a
next hop DIAMETER server, but it may change/modify/append
parameters.
REDIRECT The present node can also reject the request and include the
realm of another DIAMETER server. The client can then redirect
the request to this alternative destination server.
In each message the destination realm and an application identifier are present. Each
DIAMETER node has a table where these two parameters are used as key. The
result is then how to process the message (LOCAL, RELAY, PROXY, REDIRECT)
and if necessary the next hop server identity.
TM32043EN05GLA0
relay
connection A connection B
client server
session
Realm based message routing table
realm applic. id local action server ident.

LOCAL
RELAY
PROXY
REDIRECT
Fig.. 4 Realm
. . based
. . routing
. . table
. . and
. sessions
. . . vs.. connections
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
7
1.3 Diameter message layout

The communication between 2 Diameter Agents is done via message-exchange.
Messages are always in pairs, one is a Command Code Request (from Client to
Server), and the next is an Answer.
All DIAMETER messages follow a basic layout. It consists of the a Header (20 octets
long), called the Diameter Header, followed by a changeable number of AVPs. This
message structure is the same in all Diameter applications.
Version The version field describes the DIAMETER base protocol

version used. For the present document this version must be
set to 0x01 (version 1).
Message Length Length of DIAMETER message including header fields in
octets.
Command Flags This field contains three bits. First the R-bit is used to indicate
whether the message is a request (1) or a response (0). The P-
bit indicates whether the message may be proxied (1) or must
be handled locally (0). The last bit is the E-bit which is only for
responses important. If E=1 then the response contains an
error.
Command Code The command code contains the procedure indicator the
message belongs to.
Application ID The application identifier indicates which DIAMETER
application is sending/receiving the message.
Hop-by-Hop ID This identifier has significance per connection. It is used to
associate responses to requests.
End-to-End ID This is an identifier for the message which remains the same for
all connections the message is sent on. It might be used to
detect duplicated messages. This identifier must be unique for a
time period of at least 4 minutes.
The Header is followed by one or more Attribute-Value-Pairs (AVPs). An AVP is

used to encapsulate protocol-specific data. It is possible, for a new application, to
create a new AVP or define a new AVP value. Of course, new applications should
attempt to reuse AVPs defined in existing applications always when possible.
TM32043EN05GLA0
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Version Message Length
Command Flags Command Code
Application ID
Hop-by-Hop Identifier
End-to-End Identifier
AVPs
R P E T r r r r
R(equest) 1=Message is Request; 0=Message is Answer

P(roxiable) 1=Message may be proxied; 0=Message must be locally processed
E(rror) 1=Message contains a protocol error (only for answer messages)
T 1=Indicates, that this message is potentially a retransmission
Fig.. 5 DIAMETER
. . . . message
. . .layout
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
9
1.3.1 Diameter Base Protocol Messages

Every message must contain one Command Code and Command Flags. Each
Request/Answer pair gets the same Command Code value. According to the flag field
(R bit) the request or the answer is identified.
TM32043EN05GLA0
Fig. 6 Diameter Base Protocol Messages
TM32043EN05GLA0
11
1.4 AVP layout

DIAMETER is an extensible protocol, therefore all parameters share a common
format definition that easily allows to introduce new parameters.
All DIAMETER parameters are in form of so called Attribute-Value-Pairs AVP. Such
an AVP consists of the following elements:
AVP Code The AVP code together with the Vendor ID uniquely identifies
the parameter. Note that some AVP are predefined while other
are application specific.
AVP Flags This field contains three bits acting as flags. The V-bit indicates
whether the optional header field Vendor ID is present (1) or not
(0). The M-bit shows whether the AVP is mandatory (1) for the
message or not (0). In case a mandatory AVP cannot be
understood or is missing, the message must be rejected. The
last flag is the P-bit which indicates whether end-to-end
encryption is required (1) or not (0).
AVP Length It contains the length of the AVP including all header fields in
octets.
Vendor ID The Vendor-ID field is present if the 'V' bit is set in the AVP
Flags field. This is a unique identifier for the vendor which
implemented a vendor-specific Diameter AVP.
Data This is the value part of the AVP. Its structure does not have a
general format.
TM32043EN05GLA0
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
AVP Code
AVP Flags AVP Length
Vendor ID (opt.)
Data
V M P r r r r r
V(endor) 1=Vendor ID is present; 0=no Vendor ID present

M(andatory) 1=AVP is mandatory to be supported or message must be rejected
P(rotected) 1=end-to-end encryption required for security reasons
Fig.. 7 DIAMETER
. . . . AVP
. layout
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
13
1.4.1 Basic and derived AVP

Basic AVP types
The definition of AVP follows the general mechanism used to define variables in
programming languages. We have
basic AVP: A basic AVP is a built-in type. It is already existing with the definition of
the DIAMETER base protocol. Basic AVP are the most primitive data types known
for the protocol.
derived AVP: A derived AVP is formed out of one or more basic AVP. Derived AVP
exist in general already for the base protocol, but can also be defined application
specific.
DIAMETER defines the following basic AVP formats:
Octet String An Octet String is an ordered sequence of bytes. The meaning

of each octet in the sequence is not defined by the basic AVP
Octet String. AVP that are derived from Octet String must give
an explicit description of the meaning of each octet.
Integer32 This is a signed 32 bit long integer value. Negative values are
coded as 2'complement. The most significant bit is the sign.
Unsigned32 This is an unsigned 32 bit long integer. Of course no sign
occurs, instead all 32 bit are used to define the value range.
Integer64 Like Integer32 but with 64 bits length.
Unsigned64 Like Unsigned32 but with 64 bits length.
Float32 A floating point number with 32 bit precision. The most
significant bit is used for the sign, the next following 8 bits are
used for the exponent which is biased with 127. The remaining
23 bit are used for the fractional part.
Float64 Like Float32 but with 64 bits precision and the exponent is
biased with 1023.
Grouped This basic AVP allows to define an ordered sequence of AVP
(basic and derived). It is used to aggregate AVP to bigger
parameters.
All AVP must be coded with a length that is an integral multiple of 32 bit. Thus
padding may have to be applied to the data values.
TM32043EN05GLA0
The mechanism to built new parameters out of these basic types is very similar to
ASN.1 or any programming language.
OctetString (variable length) Float32 (fixed length)
AVP Code AVP Code
AVP Flags AVP Length AVP Flags AVP Length=12|16
Vendor ID (opt.) Vendor ID (opt.)
Octet 1 Octet 2 Octet 3 Octet 4 +/- Exponent (8) Fraction (23)
Bias 127
Octet X Octet X+1 Padding Padding
Float64 (fixed length)
AVP Code
Integer32, Unsigned32 (fixed length) AVP Flags AVP Length=16|20
AVP Code Vendor ID (opt.)
AVP Flags AVP Length=12|16 +/- Exponent (11) Fraction (52) (MSB)
Vendor ID (opt.) Fraction (52) (LSB)
MSB . . LSB Bias 1023
Grouped (variable length)

AVP Code
Integer64, Unsigned64 (fixed length)
AVP Code
Vendor ID (opt.)
AVP Flags AVP Length=16|20
AVP #1
Vendor ID (opt.)
MSB . . .
. . . LSB AVP #N
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig.. 8 Basic
. . AVP
. types
. . defined
. . by. DIAMETER
. . . . base
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
15
Some derived AVP types
Already the base protocol defines a lot of derived AVP to work with. Every
DIAMETER application surely will add new, specific AVP to the protocol.
Only a very few examples shall be provided here.
Address The Address AVP is derived from the Octet String type. The first
octet always indicates the type of address that is presented (1 =
IPv4; 2 = IPv6). The remaining octets represent the indicated
address in classical hexadecimal form.
Time Also this type is derived from Octet String. It encodes a time
value. The first 4 octets give the seconds and the second 4
octets the fraction of seconds. Note that these seconds are with
respect to January 1 ,1900 at 0 hours UTC.
UTF8String This is a text string where each character is UTF8 coded (thus a
character may require more than one byte).
DiameterIdentity Also this is a text string, but ASCII coded. It contains the fully
qualified domain name (FQDN) of a DIAMETER node.
DiameterURI Again we have text string. It describes the URI of a DIAMETER
node.
Enumerated An enumeration is a labeled list. Each entry has a unique
number (index). If one element from the list shall be indicated
simply the index is given. Thus Enumerated is derived from
Integer32.
TM32043EN05GLA0
Address = OctetString DiameterIdentity = OctetString

AVP Code AVP Code
AVP Flags AVP Length AVP Flags AVP Length
AddressType Address MSB

FQDN of Diameter Node
Address LSB Padding
AddressType: 1 IPv4; 2 IPv6
DiameterURI = OctetString
Time = OctetString
AVP Code
AVP Code
AVP Flags AVP Length Vendor ID (opt.)
Vendor ID (opt.)
URI in form of
Seconds
Seconds Fraction aaa://host.example.com:6666;transport=sctp;protocol=diameter
time since 0h 1 January 1900 UTC
UTF8String = OctetString Enumerated = Integer32

AVP Code AVP Code
AVP Flags AVP Length AVP Flags AVP Length
Enumeration Value
UTF8 coded text string
Note: UTF8 codec characters may require more than one byte.
Fig.. 9 Some
. . derived
. . .AVP. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
17
1.5 Request - answer model and response codes

The DIAMETER base protocol defines the basic message exchange mechanism
according to the general Request-Answer model.
Each transaction is started by a request message and concluded by an answer
message carrying a response code.
The result code is a four digit value and one can distinguish the following response
categories:
1xxx Informational Response. This always indicates a failure of the request.

The client has to make further actions before this request can be satisfied.
An example is when authentication is required before the request can be
processed.
2xxx Successful Response. Indicate a successful or partial successful outcome
of the request.
3xxx Protocol Error. A protocol error is treated on a per-hop basis. It is even
possible that proxies try to correct this type of error.
4xxx Transient Failure. A request can temporarily not be processed. But later
on it may be possible. Typical examples are authentication failures, no
memory left, etc.
5xxx Permanent Failures. The request failed and should not be attempted
again.
TM32043EN05GLA0
Fig. 10 Request - Answer model and response codes
TM32043EN05GLA0
19
Result codes defended by Diameter Base Protocol:
Success
DIAMETER_SUCCESS 2001
DIAMETER_LIMITED_SUCCESS 2002
Protocol Errors
DIAMETER_COMMAND_UNSUPPORTED 3001
DIAMETER_UNABLE_TO_DELIVER 3002
DIAMETER_REALM_NOT_SERVED 3003
DIAMETER_TOO_BUSY 3004
DIAMETER_LOOP_DETECTED 3005
DIAMETER_REDIRECT_INDICATION 3006
DIAMETER_APPLICATION_UNSUPPORTED 3007
DIAMETER_INVALID_HDR_BITS 3008
DIAMETER_INVALID_AVP_BITS 3009
DIAMETER_UNKNOWN_PEER 3010
DIAMETER_COMMAND_UNSUPPORTED 3001
DIAMETER_INVALID_HDR_BITS 3008
DIAMETER_INVALID_AVP_BITS 3009
DIAMETER_UNKNOWN_PEER 3010
Transient Failures
DIAMETER_AUTHENTICATION_REJECTED 4001
DIAMETER_OUT_OF_SPACE 4002
ELECTION_LOST 4003
Permanent Failures
DIAMETER_AVP_UNSUPPORTED 5001
DIAMETER_UNKNOWN_SESSION_ID 5002
DIAMETER_AUTHORIZATION_REJECTED 5003
DIAMETER_INVALID_AVP_VALUE 5004
DIAMETER_MISSING_AVP 5005
DIAMETER_RESOURCES_EXCEEDED 5006
DIAMETER_CONTRADICTING_AVPS 5007
DIAMETER_AVP_NOT_ALLOWED 5008
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
DIAMETER_NO_COMMON_APPLICATION 5010
DIAMETER_UNSUPPORTED_VERSION 5011
DIAMETER_UNABLE_TO_COMPLY 5012
DIAMETER_INVALID_BIT_IN_HEADER 5013
DIAMETER_INVALID_AVP_LENGTH 5014
DIAMETER_INVALID_MESSAGE_LENGTH 5015
DIAMETER_INVALID_AVP_BIT_COMBO 5016
DIAMETER_NO_COMMON_SECURITY 5017
TM32043EN05GLA0
1.5.1 Experimental-Result AVP

The Experimental-Result AVP (AVP Code 297) is of type Grouped. It indicates
whether a particular vendor-specific request was completed successfully or whether
an error occurred.
Experimental-Result ::= < AVP Header: 297 >
{ Vendor-Id }
{ Experimental-Result-Code }
The Vendor-Id AVP identifies the vendor responsible for the assignment of the result
code which follows. All Diameter answer messages defined in vendor-specific
applications MUST include either one Result-Code AVP or one Experimental-Result
AVP.
The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 and
contains a vendor-assigned value representing the result of processing the request.
It is recommended that vendor-specific result codes follow the same conventions
given for the Result-Code AVP regarding the different types of result codes and the
handling of errors (for non 2xxx values).
TM32043EN05GLA0
21
1.6 DIAMETER Base procedures

The following describes procedures already defined by the DIAMETER base
protocol. So they are not application specific. All of these procedures are dedicated to
connection control. So these procedures have a per-hop significance and are not
end-to-end.
1.6.1 Connection establishment

When a connection between two DIAMETER nodes has to be setup the following
happens:
1. First the transport layer connection must be established. This means either TCP
connection setup or SCTP association setup.
2. When the transport layer connection is established a reliable data transfer

between the two DIAMETER nodes is possible. Now both nodes must agree
about their capabilities. This especially means, they must the DIAMETER
applications they support.
a) One node starts to send the DIAMETER base message CAPABILITES
ENQUIRY REQUEST (CER). It contains the originator's host name, realm and
IP address. Furthermore the supported vendor identifier are sent. For Cx and
Dx interface the vendor identifier indicates 3gpp (d'0415).
b) If at least on vendor identifier is shared by the remote DIAMETER node, it will
answer with CAPABILITIES ENQUIRY ANSWER (CEA). It contains now host
name, realm and IP address of the second node. Furthermore all commonly
supported vendor identifiers are indicated. If no vendor identifiers are shared
by both nodes, then the CEA would contain a result code indicating the failure.
The transport layer connection would then be closed.
TM32043EN05GLA0
Diameter Diameter
Node Node
START
Transport Layer Connection Setup
Capabilities Exchange Request (CER)

(origin host, origin realm, host IP address, vendor id, supported applications)
10415 = 3GPP
Capabilities Exchange Answer (CEA)

(result code, origin host, origin realm, host IP address, vendor id, supported applications)
Fig.. 11.Connection
. . . establishment
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
23
1.6.2 Graceful connection release

A connection can be release graceful or abortive. The latter is a failure case (e.g. loss
of transport layer connectivity) and is not associated with a DIAMETER procedure.
For the graceful shutdown a DIAMETER procedure is defined. Reasons for a graceful
shutdown can be:
rebooting of a DIAMETER node,
congestion (busy condition),
operation and maintenance intervention.
The device that wants to close the connection sends the DIAMETER base protocol
message DISCONNECT PEER REQUEST (DPR). The message contains a cause
value indicating the three mentioned reasons for the shutdown.
The remote DIAMETER node acknowledges with DISCONNECT PEER ANSWER
(DPA). Then the transport layer connection will be released too.
TM32043EN05GLA0
Diameter Diameter
Node Node
Disconnect Peer Request (DPR)

(origin host, origin realm, disconnect cause)
Enumerated:
0 REBOOTING
1 BUSY
2 DO_NOT_WANT_TO_TALK_TO_YOU
Disconnect Peer Answer (DPA)

(result code, origin host, origin realm)
tear down transport layer connection
Fig.. 12. Graceful

. . shutdown
. . . of. a .DIAMETER
. . . connection
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TM32043EN05GLA0
25
1.6.3 Device watchdog procedure

DIAMETER relies on the reliable and available transport layer connection established
between two DIAMETER nodes. To detect failures in the transport layer and to keep
the transport layer alive the device watchdog procedure is defined.
Therefore both sides of a connection will periodically send a DEVICE WATCHDOG
REQUEST (DWR) message. It contains nothing than the host and realm of the
originator.
The receiver of the DWR will immediately answer with DEVICE WATCHDOG ANSWER
(DWA). If this DWA is received within reasonable time the connection must be
assumed to have failed.
TM32043EN05GLA0
Diameter Diameter
Node Node
Device Watchdog Request (DWR)

(origin host, origin realm)
Device Watchdog Answer (DWA)

(result code, origin host, origin realm)
Fig. 13 Device watchdog procedure
Fig. 14
TM32043EN05GLA0
27
TM32043EN05GLA0

Dia Base Protocol

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dia Base Protocol

Uploaded by

Copyright:

Available Formats

Diameter Base Protocol

1 Diameter Base Protocol

DIAMETER protocol is intended to provide an Authentication, Authorization and

Fig. 1 CSCF Interfaces

Fig. 2 HSS-FE Interfaces

1.1 Basic Terms

Fig. 3 Diameter Base Protocol

1.2 DIAMETER routing principles

In DIAMETER a node that receives a DIAMETER message has four different

LOCAL The DIAMETER request can be handled locally at the present

Realm based message routing table

realm applic. id local action server ident.

1.3 Diameter message layout

Version The version field describes the DIAMETER base protocol

The Header is followed by one or more Attribute-Value-Pairs (AVPs). An AVP is

Version Message Length

Command Flags Command Code

R(equest) 1=Message is Request; 0=Message is Answer

1.3.1 Diameter Base Protocol Messages

Fig. 6 Diameter Base Protocol Messages

1.4 AVP layout

AVP Flags AVP Length

V(endor) 1=Vendor ID is present; 0=no Vendor ID present

1.4.1 Basic and derived AVP

DIAMETER defines the following basic AVP formats:

Octet String An Octet String is an ordered sequence of bytes. The meaning

OctetString (variable length) Float32 (fixed length)

AVP Code AVP Code

AVP Flags AVP Length AVP Flags AVP Length=12|16

Vendor ID (opt.) Vendor ID (opt.)

Octet 1 Octet 2 Octet 3 Octet 4 +/- Exponent (8) Fraction (23)

Float64 (fixed length)

AVP Code Vendor ID (opt.)

Vendor ID (opt.) Fraction (52) (LSB)

MSB . . LSB Bias 1023

Grouped (variable length)

Some derived AVP types

Only a very few examples shall be provided here.

Address = OctetString DiameterIdentity = OctetString

AVP Flags AVP Length AVP Flags AVP Length

Vendor ID (opt.) Vendor ID (opt.)

AddressType Address MSB

Address LSB Padding

AddressType: 1 IPv4; 2 IPv6

Seconds Fraction aaa://host.example.com:6666;transport=sctp;protocol=diameter

time since 0h 1 January 1900 UTC

UTF8String = OctetString Enumerated = Integer32

AVP Flags AVP Length AVP Flags AVP Length

Vendor ID (opt.) Vendor ID (opt.)

1.5 Request - answer model and response codes

1xxx Informational Response. This always indicates a failure of the request.

Fig. 10 Request - Answer model and response codes

Result codes defended by Diameter Base Protocol:

1.5.1 Experimental-Result AVP

1.6 DIAMETER Base procedures

1.6.1 Connection establishment

2. When the transport layer connection is established a reliable data transfer

Capabilities Exchange Request (CER)

Capabilities Exchange Answer (CEA)

1.6.2 Graceful connection release

Disconnect Peer Request (DPR)

Disconnect Peer Answer (DPA)

tear down transport layer connection

Fig.. 12. Graceful