Cisco Cisco Packet Data Interworking Function (PDIF)
Diameter Dictionaries and Attribute Definitions
Diameter Attributes ▀
AAA Interface Administration and Reference, StarOS Release 18 ▄
51
Field
Description
AVP
Flags
Flags
The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and
SHOULD be set to 0. Note that subsequent Diameter applications may define additional bits within the AVP Header,
and an unrecognized bit SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end
security.
The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit
set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized,
the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized
AVPs.
The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability,
a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither
defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in
which it appears. It may do this in one of the following ways:
SHOULD be set to 0. Note that subsequent Diameter applications may define additional bits within the AVP Header,
and an unrecognized bit SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end
security.
The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit
set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized,
the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized
AVPs.
The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability,
a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither
defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in
which it appears. It may do this in one of the following ways:
If a message is rejected because it contains a Mandatory AVP which is neither defined in the base Diameter
standard nor in any of the Diameter Application specifications governing the message in which it appears, the
implementation may resend the message without the AVP, possibly inserting additional standard AVPs
instead.
standard nor in any of the Diameter Application specifications governing the message in which it appears, the
implementation may resend the message without the AVP, possibly inserting additional standard AVPs
instead.
A configuration option may be provided on a system wide, per peer, or per realm basis that would
allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to
avoid interoperability problems.
allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to
avoid interoperability problems.
Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal
syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing
the message.
AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is
not supported, or whose value is not supported, MAY simply ignore the AVP.
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP
header. When set the AVP Code belongs to the specific vendor code address space.
Unless otherwise noted, AVPs will have the following default AVP Flags field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.
syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing
the message.
AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is
not supported, or whose value is not supported, MAY simply ignore the AVP.
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP
header. When set the AVP Code belongs to the specific vendor code address space.
Unless otherwise noted, AVPs will have the following default AVP Flags field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.
AVP
Length
Length
The AVP Length field is three octets, and 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. If a message is received with an invalid attribute
length, the message SHOULD be rejected.
Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute
length, the message SHOULD be rejected.
Vendor-
ID
ID
This field is optional.
The Vendor-ID field is 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. Any vendor wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with
their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-
specific AVP(s), nor with future IETF applications.
A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the
absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations MUST NOT
use the zero (0) vendor ID.
The Vendor-ID field is 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. Any vendor wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with
their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-
specific AVP(s), nor with future IETF applications.
A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the
absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations MUST NOT
use the zero (0) vendor ID.
Basic AVP Data Formats
The Data field is zero or more octets and contains information specific to the attribute. The format and length of the
Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the
following base data types or a data type derived from the base data types.
Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the
following base data types or a data type derived from the base data types.