dictionary.diameter

Diameter dictionaries

Use dictionary { diameter { ... } } to load Diameter attribute definitions. Each named application block accepts one or more filename statements. Custom definitions extend the built-in Diameter AVP catalog. The application names organize the files; their definitions are merged into one catalog used by the configured Diameter servers. Loading a dictionary does not enable an application or add a command schema.

dictionary {
    diameter {
        application "NASREQ" {
            filename "dictionary.dia";
        }
    }
}

File format

Define one AVP or enum value per line. Blank lines and comments starting with # are ignored. Names and values cannot contain whitespace.

ATTRIBUTE Ruckus-SSID 3 OctetString vendor=25053
ATTRIBUTE Example-Mode 500 Enumerated vendor=25053 flags=M
VALUE Example-Mode Enabled 1

ATTRIBUTE takes the name, numeric AVP code and Diameter type, followed by optional vendor=<id> and flags=<letters> fields. Omit vendor for standard AVPs. M requires the Mandatory bit; P describes the advisory Protected bit. VALUE adds a signed 32-bit enum value to a previously defined Enumerated AVP.

Types include OctetString, UTF8String, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64, Address, Time, Enumerated, Grouped, DiameterIdentity, DiameterURI, IPFilterRule, QoSFilterRule, and Enumerated8. Type names are case insensitive. Dictionary files do not define command or grouped-AVP schemas.

Conflicting AVP names, duplicate identities, unsupported types and invalid definitions reject the configuration. Built-in definitions cannot be replaced.

Reload

Edit the configured dictionary file and reload the configuration through Radiator UI or the HTTP Management API. No software update is required. Reload reads the file contents even when its filename is unchanged.

Validation completes before publication. An invalid dictionary leaves the previous configuration active. A successful change replaces dependent Diameter server generations; their peer connections are reestablished using the new catalog. In-flight transactions retain their original immutable protocol model. Unchanged dictionary material retains its catalog. Removing a custom definition removes it from new server generations.

RADIUS reply mapping

The Diameter backend maps known vendor AVPs to configured RADIUS Type 26 attributes with the same vendor ID and attribute code. Both dictionaries must define the attribute; their names can differ. Values use the Diameter datatype and the RADIUS attribute encoder. Repeated AVPs remain repeated RADIUS attributes.

For example, load the Ruckus-SSID definition above alongside a RADIUS dictionary that defines vendor 25053, attribute 3. Ruckus-SSID replies can then pass through the NASREQ backend into the RADIUS reply.

Unknown vendor AVPs, unmapped RADIUS attributes, encrypted RADIUS attributes and nested RADIUS TLV definitions are omitted from generic vendor mapping. Protected key material uses the dedicated bridge handling.