Cisco Cisco ASR 5500 Administrator's Guide

 

AVP 
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: 



 

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. 



 

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. 

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. 

AVP 
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. 

Vendor-
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 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.