|Email This Page
The Diameter protocol is designed to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations.Diameter protocol was designed as an improved version of the RADIUS protocol. The DIAMETER protocol does not address flaws within the RADIUS model. The basic concept behind DIAMETER is to provide a base protocol that can be extended in order to provide AAA services to new access technologies. DIAMETER does not use the same RADIUS protocol data unit, but is backward compatible with RADIUS to ease migration.
The traditional AAA protocols such as TACACS and RADIUS were initially deployed to provide dial-up PPP [PPP] and terminal server access. Over time, with the growth of the Internet and the introduction of new access technologies, including wireless, DSL, Mobile IP and Ethernet, routers and network access servers (NAS) have increased in complexity and density, putting new demands on AAA protocols. The DIAMETER protocol then was introduced.
Diameter is defined in terms of a base protocol and a set of applications. This design allows the protocol to be extended to new access technologies. The base protocol provides basic mechanisms for reliable transport message delivery, and error handling.
The base protocol must be used in conjunction with a Diameter application. Each application relies on the
services of the base protocol to support a specific type of network access. The two major applications are
Mobile IPv4 and NASREQ (network access server requirements). The NASREQ application supports dial-in PPP/IP and is the intended replacement for RADIUS. The following figure depicts the Diameter architecture:
Protocol Structure - DIAMETER Protocol
The base protocol defines the basic Diameter message format. Data is carried within a Diameter message as a collection of attribute value pairs (AVPs). The packet format of the diameter base protocol is shown as follows:
Version- MUST be set to 1 to indicate Diameter Version 1.
Message Length - three octets and indicates the length of the Diameter message including the header fields.
Command Flags - eight bits flags.
Command-Code - three octets field used in order to communicate the command associated with the message.
Application-ID - four octets used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application.
Hop-by-Hop Identifier- an unsigned 32-bit integer field aids in matching requests and replies.
End-to-End Identifier - an unsigned 32-bit integer field used to detect duplicate messages.
AVPs - Attribute Value Pair (AVP) is a method of encapsulating information relevant to the Diameter message. An AVP is like a RADIUS attribute. Some AVPs are used by the Diameter base protocol; other AVPs are intended for the Diameter application (e.g. NASREQ); while yet others may be used by the higher-level end-system application that employs Diameter. The format of a Diameter AVP header is:
AVPs - Attribute Value Pair (AVP)
AVP Code - combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS.
AVP Flags - informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0.
AVP Length - three octets, indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data.
Vendor-ID – opetional field, present if the 'V' bit is set in the AVP Flags field. The optional four-octet Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" value, encoded in network byte order.
DIAMETER protocol is defined by IETF in RFC 3588.
http://www.javvin.com/protocol/rfc3588.pdf : Diameter Base Protocol