Page History

AVP Value parameters are one of three format types:

HexString

String

Integer

“The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA.”

Example:

Origin-Host AVP (AVP Code 264), Vendor ID AVP (0)

The AVP Flags field informs the receiver how each attribute must be handled.

Type: ubit8

Format: V M P r r r r r

Bits:

The r (reserved) bits are unused and SHOULD be set to 0 by the sender, and ignored by the receiver.

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.

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.

Default Value: P bit (0x20)

“Vendor-Id is a four-octet field that contains the vendor's assigned SMI Network Management Private Enterprise Codes from IANA.” Vendor-Id is used in conjunction with Vendor's specific AVPs to make sure these AVPs can be identified in their private AVP codes namespace and do not collide with any other external ones. “Absence of a Vendor-Id in an XML message or a Vendor-Id value of zero defaults to the IETF IANA controlled AVP codes namespace.”

Type: ubit32

Default value: 0

The AVP name is optional, and is used to look up AVP details in the company dictionary. For more information, refer to the  section in the .

If the API fails to lookup the provided AVP Name in the dictionary, the default AVP fields are used (AVP Code = 0, AVP Type = Unknown, Vendor Id = 0). This usually results in insufficient information for the message to be routed properly.

Type: string

All AVP data fields must be either base data type or derived data type.

Base data type AVP:

• Octet-string: HexString
• Enumerated: s32 - 4 byte integer
• Unsigned32: 4 byte integer
• Unsigned64: 8 byte integer
• Integer32: 4 byte integer
• Integer64: 8 byte integer
• Float32: 4 byte floating point
• Float64: 8 byte floating point
• Grouped AVPs: sequence of nested AVPs

Example:

 <avp avp-name="Parent1">           

<avp avp-name="Parent2">

<avp avp-name="Vendor-Id" value="10415" />

<avp avp-name="Auth-Application-Id" value="16777217" />

</avp>

</avp>

In the example above, one can observe that the AVP value in grouped AVPs is only provided if the AVP is a child (leaf) AVP and not a parent AVP. In other words, an AVP within a set of grouped AVPs should either provide a child AVP or an AVP value, but not both.

Derived data type:

• Address:
  “The Address format is derived from the octet-string AVP Base Format. It is a discriminated union, representing, for example a 32-bit (IPv4) or 128-bit (IPv6) address.”
  
  
• Time:
  “The Time format is derived from the octet-string AVP Base Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC).”
  
  
• UTF8String:
  “Human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an octet-string using the UTF-8 transformation format.”
  
  
• DiameterIdentity:
  “The DiameterIdentity format is derived from the octet-string AVP Base Format. DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection. The contents of the string MUST be the FQDN of the Diameter node.”
  
  
• IPFilterRule:

  “The IPFilterRule format is derived from the octet-string AVP Base Format. It uses the ASCII character set. Packets may be filtered based on the following information that is associated with it:

Direction (in or out)

Source and destination IP address (possibly masked)

Protocol

Source and destination port (lists or ranges)

TCP flags

IP fragment flag

IP options

ICMP types”

• DiameterURI:
  “The DiameterURI MUST follow the Uniform Resource Identifiers (URI) syntax rules specified below:

"aaa://" FQDN [ port ] [ transport ] [ protocol ]

"aaas://" FQDN [ port ] [ transport ] [ protocol ]

FQDN = Fully Qualified Host Name

port = One of the ports used to listen for incoming connections.

If absent, the default Diameter port (3868) is assumed.

transport = ";transport=" transport-protocol

One of the transports used to listen for incoming connections. If absent, the default SCTP

[SCTP] protocol is assumed.

transport-protocol = ( "tcp" / "sctp" / "udp" )

protocol = ";protocol=" aaa-protocol

If absent, the default AAA protocol is diameter.

aaa-protocol = ( "diameter" / "radius" )

The following are examples of valid Diameter host identities:

aaa://host.example.com;transport=tcp

aaa://host.example.com:6666;transport=tcp

aaa://host.example.com;protocol=diameter

aaa://host.example.com:6666;protocol=diameter

Not currently used by the XML APIs for the incoming XML messages to series4. However, this is properly included in all outgoing messages from series4.

Encoding is currently decided based on combinations of the format of the AVP value and the AVP type provided in the message. The encoding for cases of absence or unknown AVP types are defaulted to octet-string encoding.