AVPs (Attribute-Value Pairs)
AVPs (Attribute-Value Pairs) in Mobius Diameter
General Overview
Attribute-Value Pairs (AVPs) form the core building blocks for carrying data in the Diameter protocol. These AVPs are flexible, allowing Diameter messages to handle a variety of functions such as authentication, authorization, accounting, configuration, and routing. AVPs are structured in a way that allows them to encapsulate information specific to a given application or protocol layer, while maintaining a clear and standardized format for transport across network nodes.
AVPs contain a Header followed by a Data field, where the actual information is stored. The data structure supports multiple types, including simple types (e.g., integers, strings) and complex types (e.g., grouped AVPs). This structure allows AVPs to extend beyond basic functions and be adaptable for new applications while remaining compliant with the core Diameter protocol standard.
The Diameter base protocol and AVP structure are defined in [RFC6733].
AVP Header
The AVP Header is a fixed part of the AVP structure, used to identify and manage the data being transported. The structure is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code: The AVP Code uniquely identifies the AVP. AVP codes 1-255 are reserved for reuse of RADIUS attributes, while values 256 and above are allocated for Diameter-specific AVPs. Each AVP Code is assigned by IANA and, in some cases, may be vendor-specific if the V-bit is set.
AVP Flags: The AVP Flags field consists of eight bits, which control how the AVP should be processed:
- V-bit (Vendor-Specific): When set, this bit indicates that the AVP belongs to a vendor-specific namespace, and the Vendor-ID field is present. Vendor-specific AVPs are commonly used by hardware and software manufacturers to add proprietary extensions.
- M-bit (Mandatory): If this bit is set, it signals that the AVP is mandatory for the receiving node. If the AVP is unrecognized or cannot be processed, the receiver must reject the message and return an error. This is critical for ensuring interoperability and ensuring mandatory parameters are handled across nodes.
- P-bit (Protected): Reserved for future use to indicate the need for end-to-end security. At the time of writing, no specific security mechanisms use this flag, and the bit must be set to zero.
- Reserved bits (r): These bits are currently unused and must be set to zero. They may be redefined in future versions of the protocol.
AVP Length: This field defines the total length of the AVP, including the header and data. The length is always expressed in octets. The calculation of the length is crucial for correct padding and alignment. For certain AVP types, such as OctetString, padding is added to align the AVP on a 32-bit boundary, but this padding is not counted in the AVP length. The AVP length includes the following components:
- AVP Code (4 bytes)
- AVP Flags and Length (3 bytes)
- Vendor-ID (optional, 4 bytes)
- AVP Data (variable length)
Vendor-ID (Optional): If the V-bit is set, the AVP header contains a Vendor-ID field. This field identifies the vendor’s namespace for the AVP Code. Vendor-IDs are allocated by IANA and are used to ensure that AVPs created by different vendors can coexist without conflict. If the V-bit is not set, this field is omitted, and the AVP is considered to belong to the IETF-controlled namespace.
AVP Data Types
The AVP Data field contains the actual information being transmitted by the AVP. The data can be one of several base data types or a derived data type. Proper understanding of these data types is essential for decoding and interpreting AVP values correctly.
Base Data Types
Base data types are fundamental and are used directly or as building blocks for more complex derived types:
- OctetString: This is a sequence of arbitrary bytes, commonly used for binary data. The length of the OctetString can vary, but it must be padded to a 32-bit boundary to ensure proper alignment. Padding is added at the end of the string and does not count towards the AVP length.
- Integer32: A 32-bit signed integer, transmitted in network byte order. This type is frequently used for simple numerical values, such as counters or status codes. The length of the AVP must be set to 12 octets (16 if the V-bit is set).
- Integer64: A 64-bit signed integer, also in network byte order. Used for larger numerical values, the AVP length is 16 octets (20 if the V-bit is set).
- Unsigned32: A 32-bit unsigned integer, similar to Integer32 but without negative values. Commonly used for counters or identifiers where negative values are not allowed.
- Unsigned64: A 64-bit unsigned integer, used for larger unsigned values.
- Float32: A 32-bit floating-point number, following the IEEE 754 standard for single-precision. The value is transmitted in network byte order. Float32 is rarely used but is available for specific applications requiring precise numeric representation.
- Float64: A 64-bit floating-point number, also following IEEE 754 for double-precision.
Derived Data Types
Derived data types are built from base data types, providing more complex structures:
- UTF8String: This format is derived from the OctetString and contains human-readable text encoded using the UTF-8 character set. UTF-8 is widely used for internationalized text and allows for flexible encoding of characters. The length of the AVP is measured in octets, not characters.
- DiameterIdentity: This is a specialized OctetString used to represent a Diameter node or realm, typically as a Fully Qualified Domain Name (FQDN). It is used for tasks like routing and node identification within the Diameter network.
- DiameterURI: Represents a URI for a Diameter node or resource. It follows the syntax outlined in RFC 3986 and supports fields like the FQDN, port, transport, and protocol (e.g., "diameter").
- IPFilterRule: This is used to define a set of rules for IP packet filtering. The format is derived from OctetString and allows filtering based on criteria like source/destination IP, protocol, ports, and TCP flags.
- Bitmask: A specialized format typically derived from an integer base type (commonly Unsigned32) in which each bit of the integer represents a distinct flag or condition. This allows multiple states or conditions to be represented within a single AVP value.
- Enumerated: This format is derived from Integer32 and represents a finite set of values, where each value has a specific meaning defined by the AVP’s application. For example, an enumerated AVP might represent different states or types, with values like "1" for active and "2" for inactive.
Mobius Diameter Enumerated AVP Architecture
IMPORTANT: In Mobius Diameter, each Enumerated AVP is split into two Java classes:
AVP Interface (e.g., AoCRequestType.java): Extends a generic interface like DiameterEnumerated<T> (where T is the actual enum). Annotated with @DiameterAvpDefinition to link the AVP's code, vendor, and name to this interface. Serves as a marker or wrapper that ties the high-level Diameter concept (e.g., the AoC-Request-Type AVP) to its integer-based, enumerated logic.
Enum Definition (e.g., AoCRequestTypeEnum.java): Implements an IntegerEnum (or similar) interface. Contains a finite set of possible values, each mapped to the integer value specified by the Diameter standard. Provides easy conversion from the integer value (as received in a Diameter message) to the strongly typed enum constant, and vice versa.
If new enumerated values are added by the standard or by a vendor-specific extension, only the enum class (AoCRequestTypeEnum) needs updating.
Grouped AVPs
A Grouped AVP is a special type of AVP where the data field is itself a sequence of AVPs, which can also include other grouped AVPs. This structure allows for flexible and hierarchical data representation within Diameter messages.
Grouped AVP rules:
- Encapsulated AVPs inherit the same code numbering space.
- Unrecognized Grouped AVPs may be ignored unless the M-bit is set on encapsulated AVPs.
For example:
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
In this case, the Example-AVP includes a mandatory Origin-Host AVP, one or more Session-Id AVPs, and any number of additional optional AVPs. The AVP header for each member is included, along with any necessary padding to ensure 32-bit alignment.
Origin-Host = "example.com".
One or more Session-Ids must follow. Here there are two:
Session-Id = "grump.example.com:33041;23432;893;0AF3B81"
Session-Id = "grump.example.com:33054;23561;2358;0AF3B82"
optional AVPs included are
Recovery-Policy = <binary> 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary> fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 d3427475e49968f841
The data for the optional AVPs is represented in hexadecimal form since the format of these AVPs is not known at the time of definition of the Example-AVP group nor (likely) at the time when the example instance of this AVP is interpreted — except by Diameter implementations that support the same set of AVPs.
The encoding example illustrates how padding is used and how length fields are calculated. Also, note that AVPs may be present in the Grouped AVP value that the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs). The length of the Example-AVP is the sum of all the length of the member AVPs, including their padding, plus the Example-AVP header size.
This AVP would be encoded as follows:
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 496 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
+-------+-------+-------+-------+-------+-------+-------+-------+
88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
+-------+-------+-------+-------+-------+-------+-------+-------+
128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
+-------+-------+-------+-------+-------+-------+-------+-------+
136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
+-------+-------+-------+-------+-------+-------+-------+-------+
144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
+-------+-------+-------+-------+-------+-------+-------+-------+
336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
List of AVPs
This documentation provides a comprehensive list of all AVPs in Mobius Diameter.
Each java package (usually corresponding to a particular application interface) presented in a separate sub-close. Each sub-close consists of a basic description of application/interface functionality and a table with AVPs descriptions.
Table formatted as following:
- Name:
- AVP Code:
- Data Type:
- Vendor:
- Description:
For example:
| Name | AVP Code | Data Type | Description |
| Additional-Type-Information | 1205 | UTF8String | 3GPP |
| Used to provide any additional information about media types beyond the well-known or non-well-known media types. | |||
Core AVP toolkit
package com.mobius.software.telco.protocols.diameter.primitives;
A core AVP framework — interfaces and enums that represent all the fundamental Diameter data types, along with helper classes for parsing and storing raw AVP information. Whenever higher-level packages define a new AVP, they base it on these primitives—ensuring consistent encoding/decoding, minimal duplication of parsing logic, and a uniform way to handle unknown or future AVPs.
|
Name |
AVP Code |
Data Type |
Vendor |
|
DiameterAddress |
N/A |
Address |
Mobius |
|
The DiameterAddress AVP is used to represent an IP address or an E.164 number in Diameter messages. It supports various address types, including IPv4, IPv6, and E.164, ensuring flexibility for different network and signaling scenarios. |
|||
|
DiameterAddressTypeEnum |
N/A |
Enumerated |
Mobius |
|
Represents various types of network address formats used in Diameter protocol messages. These address types are crucial for routing, policy enforcement, and address representation in Diameter AVPs. Enumerated Values: 0: RESERVED: Reserved value, not in use. 1: IPV4: IPv4 address format. 2: IPV6: IPv6 address format. 3: NSAP: Network Service Access Point (NSAP) address. 4: HDLC: High-Level Data Link Control (HDLC) address. 5: BBN_1822: BBN Report 1822 address format. 6: E802: IEEE 802 MAC address. 7: E163: E.163 telephone number format. 8: E164: E.164 telephone number format. 9: F69: F.69 format (used in older ITU-T protocols). 10: X121: X.121 address format (used in X.25 networks). 11: IPX: Internetwork Packet Exchange (IPX) address. 12: APPLETALK: AppleTalk address. 13: DECNET_IV: Digital Equipment Corporation DECnet Phase IV address. 14: BANYAN_VINES: Banyan VINES address format. 15: E164_WITH_NSAP: E.164 number including NSAP-style extensions. 16: DNS: Domain Name System (DNS) address. 17: DISTINGUISHED_NAME: X.500 Distinguished Name (DN) format. 18: AS_NUMBER: Autonomous System (AS) number as an address type. 19: XTP_OVER_IP_VERSION_4: Xpress Transfer Protocol over IPv4. 20: XTP_OVER_IP_VERSION_6: Xpress Transfer Protocol over IPv6. 21: XTP_NATIVE_MODE_XTP: Xpress Transfer Protocol in its native mode. 22: FIBRE_CHANNEL_WW_PORT_NAME: Fibre Channel World-Wide Port Name (WWPN). 23: FIBRE_CHANNEL_WW_NODE_NAME: Fibre Channel World-Wide Node Name (WWNN). 24: GWID: Gateway Identifier. 25: AFI_FOR_L2VPN: Address Family Identifier (AFI) for Layer 2 VPNs. 26: MPLS_TP_SECTION_ENDPOINT_IDENTIFIER: MPLS-TP Section Endpoint Identifier. 27: MPLS_TP_LSP_ENDPOINT_IDENTIFIER: MPLS-TP Label Switched Path (LSP) Endpoint Identifier. 28: MPLS_TP_PSEUDOWIRE_ENDPOINT_IDENTIFIER: MPLS-TP Pseudowire Endpoint Identifier. 29: MT_IP: Multi-Topology IP address. 30: MT_IPV6: Multi-Topology IPv6 address. 31: BGP_SFC: Border Gateway Protocol Service Function Chaining (BGP-SFC). 16384: EIGRP_COMMON_SERVICE_FAMILY: EIGRP Common Service Family. 16385: EIGRP_IPV4_SERVICE_FAMILY: EIGRP IPv4 Service Family. 16386: EIGRP_IPV6_SERVICE_FAMILY: EIGRP IPv6 Service Family. 16387: LCAF: Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF). 16388: BGPLS: BGP Link-State address family. 16389: MAC_48: 48-bit MAC address. 16390: MAC_64: 64-bit MAC address. 16391: OUI: Organizationally Unique Identifier (OUI). 16392: MAC_24: 24-bit MAC address format. 16393: MAC_40: 40-bit MAC address format. 16394: IPV6_64: IPv6 64-bit address format. 16395: RBEIDGE_PORT_ID: RBridge (TRILL) Port Identifier. 16396: TRILL_NICKNAME: TRILL (Transparent Interconnection of Lots of Links) Nickname. 16397: UUID: Universally Unique Identifier (UUID) format. 16398: ROUTING_POLICY_AFI: Routing Policy Address Family Identifier (AFI). 16399: MPLS_NAMESPACES: MPLS Namespaces. |
|||
|
DiameterAsciiString |
N/A |
ASCII String |
Mobius |
|
Represents a Diameter AVP containing an ASCII-encoded string. Provides a method to retrieve the string value in its decoded form. Used as a base type for AVPs requiring ASCII string representation. |
|||
|
DiameterAvp |
N/A |
N/A |
Mobius |
|
The root interface for all Diameter AVPs, defining essential AVP metadata such as the M-bit and P-bit flags. Provides methods for setting and retrieving these flags, allowing higher-level logic to determine AVP handling behavior. |
|||
|
DiameterAvpKey |
N/A |
N/A |
Mobius |
|
A utility class that uniquely identifies a Diameter AVP based on its AVP Code and Vendor ID. Supports equality checks and hash-based lookups, ensuring efficient AVP retrieval during encoding/decoding. |
|||
|
DiameterBitmask32 |
N/A |
Bitmask 32-bit |
Mobius |
|
Represents a Diameter AVP that contains a 32-bit bitmask. Provides methods to set or retrieve individual bits, allowing flag-based encoding and processing. |
|||
|
DiameterBitmask64 |
N/A |
Bitmask 64-bit |
Mobius |
|
Represents a Diameter AVP that contains a 64-bit bitmask. Provides methods to set or retrieve individual bits, allowing flag-based encoding and processing. |
|||
|
DiameterE164Address |
N/A |
E.164 Address |
Mobius |
|
Represents a Diameter AVP that stores an E.164-formatted phone number, typically used for MSISDN or other numbering plans. |
|||
|
DiameterEnumerated |
N/A |
Enumerated |
Mobius |
|
Represents a Diameter AVP that maps integer values to an enumerated type. Provides methods for retrieving type-safe, symbolic representations of on-wire integer values. |
|||
|
DiameterFloat32 |
N/A |
32-bit Floating Point Number |
Mobius |
|
Represents a Diameter AVP that contains a 32-bit floating point value, ensuring precise numeric representation for protocol-specific calculations. |
|||
|
DiameterFloat64 |
N/A |
64-bit Floating Point Number |
Mobius |
|
Represents a Diameter AVP that contains a 64-bit floating point value, enabling high-precision numeric data storage. |
|||
|
DiameterGroupedAvp |
N/A |
Grouped |
Mobius |
|
Represents a Diameter AVP that contains a collection of nested AVPs. Supports optional AVP storage, dynamic parsing, and hierarchical AVP structures, enabling flexible data encoding. |
|||
|
DiameterIdentity |
N/A |
Diameter Identity |
Mobius |
|
Represents a Diameter AVP that holds a network node's identity in a Diameter system, typically formatted as a Fully Qualified Domain Name (FQDN). Used for routing and authentication. |
|||
|
DiameterInteger32 |
N/A |
32-bit Integer |
Mobius |
|
Represents a Diameter AVP that contains a signed 32-bit integer value. Used for protocol parameters requiring integer-based storage. |
|||
|
DiameterInteger64 |
N/A |
64-bit Integer |
Mobius |
|
Represents a Diameter AVP that contains a signed 64-bit integer value. Used for high-precision counters or identifiers within Diameter messages. |
|||
|
DiameterIpAction |
N/A |
Enumerated |
Mobius |
|
Defines the action to be applied in an IP filter rule. Enumerated values are "permit" (allow traffic) and "deny" (block traffic). Used in Diameter IP filtering mechanisms. |
|||
|
DiameterIpFilterRule |
N/A |
IP Filter Rule |
Mobius |
|
Represents a Diameter AVP that contains an IP filter rule. Used to define traffic flow policies based on attributes such as source and destination addresses, ports, protocols, TCP flags, and ICMP types. Supports defining actions (permit/deny), direction, and specific rule conditions. |
|||
|
DiameterIpv4Address |
N/A |
Address (IPv4) |
Mobius |
|
Represents a Diameter AVP containing an IPv4 address. It provides methods to retrieve the address as an Inet4Address object. |
|||
|
DiameterIpv6Address |
N/A |
Address (IPv6) |
Mobius |
|
Represents a Diameter AVP containing an IPv6 address. It provides methods to retrieve the address as an Inet6Address object. |
|||
|
DiameterOctetString |
N/A |
OctetString |
Mobius |
|
Represents a Diameter AVP that holds binary data as a ByteBuf. Used for AVPs that contain raw byte sequences without specific type constraints. |
|||
|
DiameterProtocol |
N/A |
Enumerated |
Mobius |
|
Defines protocol types used in Diameter-related communication. Enumerated values include "diameter" (Diameter protocol), "radius" (RADIUS protocol), "tacacs+" (TACACS+ protocol), and an empty “default” value. |
|||
|
DiameterQosAction |
N/A |
Enumerated |
Mobius |
|
Defines possible Quality of Service (QoS) actions in Diameter-based networks. Enumerated values are "tag" (marking traffic for special handling) and "meter" (rate-limiting or bandwidth control). |
|||
|
DiameterRuleAddress |
N/A |
Address |
Mobius |
|
Represents an address object used in Diameter rule definitions. It provides access to the address as a string or InetAddress, supports subnet bitmasking, and includes flags for inverse matching, assignment status, and wildcard usage. |
|||
|
DiameterRuleDirection |
N/A |
Enumerated |
Mobius |
|
Specifies the direction of a Diameter rule. Enumerated values are "in" (traffic entering the network) and "out" (traffic leaving the network). Used primarily in IP filter rules to define the flow direction of packets. |
|||
|
DiameterRuleIcmpType |
N/A |
Enumerated |
Mobius |
|
Represents ICMP (Internet Control Message Protocol) types used in Diameter IP filtering rules. These types define specific control messages exchanged between network devices for diagnostic and error-handling purposes. Enumerated Values: 0: ECHO_REPLY: Response to an ICMP Echo Request (ping reply). 3: DESTINATION_UNREACHABLE: Indicates the destination is unreachable for some reason. 4: SOURCE_QUENCH: A deprecated message used to indicate congestion control. 5: REDIRECT: Sent to inform a host about a better route to a destination. 8: ECHO_REQUEST: ICMP request to check reachability (ping request). 9: ROUTER_ADVERTISEMENT: Sent by routers to advertise their presence. 10: ROUTER_SOLICITATION: Sent by hosts to request router advertisement messages. 11: TIME_TO_LIVE_EXCEEDED: Packet dropped due to exceeding its Time-to-Live (TTL). 12: IP_HEADER_BAD: Sent when an issue with the IP header is detected. 13: TIMESTAMP_REQUEST: Request for timestamp information. 14: TIMESTAMP_REPLY: Response to a Timestamp Request. 15: INFORMATION_REQUEST: Used for obtaining network configuration information (obsolete). 16: INFORMATION_REPLY: Response to an Information Request (obsolete). 17: ADDRESS_MASK_REQUEST: Request for a subnet mask. 18: ADDRESS_MASK_REPLY: Response with the subnet mask information. |
|||
|
DiameterRuleIpOption |
N/A |
Enumerated |
Mobius |
|
Represents specific IP options used in Diameter IP filter rules. These options modify the handling of IP packets within a rule set. Enumerated values include "ssrr" (Strict Source Route), "lsrr" (Loose Source Route), "rr" (Record Route), and "ts" (Timestamp). Used for fine-grained control over packet routing and tracking. |
|||
|
DiameterRuleOption |
N/A |
Enumerated |
Mobius |
|
Defines additional filtering criteria within Diameter IP filter rules. Enumerated values include "frag" (fragmented packets), "established" (established TCP connections), "setup" (new connection setup), "ipoptions" (IP options present), "tcpoptions" (TCP options present), "icmptypes" (ICMP type filtering), and "tcpflags" (TCP flag filtering). These options enable more precise rule definition and enforcement. |
|||
|
DiameterRulePorts |
N/A |
Grouped |
Mobius |
|
Defines a port range for Diameter IP filtering rules. Supports methods for retrieving the range as a string, as well as accessing the minimum and maximum port numbers. Used in traffic filtering policies to specify allowed or restricted port ranges. |
|||
|
DiameterRuleTcpFlag |
N/A |
Enumerated |
Mobius |
|
Represents TCP flags used in Diameter IP filtering rules to specify packet matching criteria. Enumerated values: FIN: Indicates that the sender has finished sending data and wants to terminate the connection. SYN: Synchronization flag used to initiate a new TCP connection. RST: Reset flag that forcefully terminates an active connection. PSH: Push flag signals that the receiver should process the data immediately instead of buffering it. ACK: Acknowledgment flag confirms receipt of a packet. URG: Urgent flag indicates that the data in the packet should be prioritized for immediate processing. |
|||
|
DiameterRuleTcpOption |
N/A |
Enumerated |
Mobius |
|
Specifies TCP options that can be used in Diameter IP filtering rules. Enumerated values include "MSS" (Maximum Segment Size), "WINDOW" (TCP Window Size), "SACK" (Selective Acknowledgment), "TS" (Timestamp), and "CC" (Congestion Control). These options refine how TCP packet handling is configured. |
|||
|
DiameterTime |
N/A |
Time |
Mobius |
|
Represents a time-based AVP in Diameter, providing a method to retrieve the stored value as a Date object. Used in AVPs that involve timestamps, expiration times, or duration tracking. |
|||
|
DiameterTransport |
N/A |
Enumerated |
Mobius |
|
Defines supported transport protocols for Diameter communication. The available values are "TCP", "SCTP", and "UDP", along with a "DEFAULT" option. |
|||
|
DiameterUnknownAvp |
N/A |
OctetString |
Mobius |
|
Represents an unrecognized or vendor-specific AVP that is not explicitly defined in the local implementation. This AVP allows storage and forwarding of unknown AVPs, preserving their raw binary data for potential future decoding. |
|||
|
DiameterUnsigned32 |
N/A |
Unsigned32 |
Mobius |
|
Represents a Diameter AVP with an unsigned 32-bit integer value. This type is commonly used for AVPs that require numerical representation with a positive value range. |
|||
|
DiameterUnsigned64 |
N/A |
Unsigned64 |
Mobius |
|
Represents a Diameter AVP with an unsigned 64-bit integer value. This type is commonly used for AVPs that require numerical representation with a positive value range. |
|||
|
DiameterUri |
N/A |
UTF8String |
Mobius |
|
Represents a URI-based AVP that encodes network addresses or service endpoints in Diameter. It includes fields for host, port, transport protocol, and security attributes, allowing for precise network resource identification. |
|||
|
DiameterUTF8String |
N/A |
UTF8String |
Mobius |
|
Represents a Diameter AVP that stores text as a UTF-8 encoded string. This type is commonly used for human-readable identifiers, descriptions, and labels in Diameter messages. |
|||
|
IntegerEnum |
N/A |
Enumerated |
Mobius |
|
Defines an interface for enumerations representing enumerated values in Diameter AVPs. Implementing this interface allows enum constants to be mapped to their integer representations, ensuring compatibility with the Diameter protocol's encoding of enumerated values. |
|||
|
InternetProtocol |
N/A |
Enumerated |
Mobius |
|
Represents protocol numbers used in the Internet Protocol suite. Each value corresponds to a specific transport or network layer protocol as defined by the IANA Protocol Numbers registry. Enumerated Values: Ip: ANY: Represents any IP protocol. 0: HOPOPT: IPv6 Hop-by-Hop Option. 1: ICMP: Internet Control Message Protocol. 2: IGMP: Internet Group Management Protocol. 3: GGP: Gateway-to-Gateway Protocol. 4: IPv4: IPv4 encapsulation. 5: ST: Stream Protocol. 6: TCP: Transmission Control Protocol. 7: CBT: Core-based Trees. 8: EGP: Exterior Gateway Protocol. 9: IGP: Interior Gateway Protocol. 10: BBN_RCC_MON: BBN RCC Monitoring. 11: NVP_II: Network Voice Protocol. 12: PUP: Xerox PUP. 13: ARGUS: ARGUS. 14: EMCON: EMCON. 15: XNET: Cross Net Debugger. 16: CHAOS: Chaos Protocol. 17: UDP: User Datagram Protocol. 18: MUX: Multiplexing. 19: DCN_MEAS: DCN Measurement Subsystems. 20: HMP: Host Monitoring Protocol. 21: PRM: Packet Radio Measurement. 22: XNS_IDP: Xerox NS IDP. 23: TRUNK_1: Trunk-1. 24: TRUNK_2: Trunk-2. 25: LEAF_1: Leaf-1. 26: LEAF_2: Leaf-2. 27: RDP: Reliable Data Protocol. 28: IRTP: Internet Reliable Transaction Protocol. 29: ISO_TP4: ISO Transport Protocol Class 4. 30: NETBLT: Bulk Data Transfer Protocol. 31: MFE_NSP: MFE Network Services Protocol. 32: MERIT_INP: MERIT Internodal Protocol. 33: DCCP: Datagram Congestion Control Protocol. 34: THREE_PC: Third Party Connect Protocol. 35: IDPR: Inter-Domain Policy Routing Protocol. 36: XTP: Xpress Transfer Protocol. 37: DDP: Datagram Delivery Protocol. 38: IDPR_CMTP: IDPR Control Message Transport Protocol. 39: TP_PLUS_PLUS: TP++ Transport Protocol. 40: IL: IL Transport Protocol. 41: IPv6: IPv6 encapsulation. 42: SDRP: Source Demand Routing Protocol. 43: IPv6_ROUTE: Routing Header for IPv6. 44: IPv6_FRAG: Fragment Header for IPv6. 45: IDRP: Inter-Domain Routing Protocol. 46: RSVP: Resource Reservation Protocol. 47: GRE: Generic Routing Encapsulation. 48: DSR: Dynamic Source Routing Protocol. 49: BNA: BNA. 50: ESP: Encapsulating Security Payload. 51: AH: Authentication Header. 52: I_NLSP: Integrated NLSP. 53: SWIPE: Simple Key-Management for Internet Protocols. 54: NARP: NBMA Address Resolution Protocol. 55: MOBILE: IP Mobility. 56: TLSP: Transport Layer Security Protocol. 57: SKIP: SKIP. 58: IPv6_ICMP: ICMP for IPv6. 59: IPv6_NONXT: No Next Header for IPv6. 60: IPv6_OPTS: Destination Options for IPv6. 61: HOST_INTERNAL: Reserved for host internal use. 62: CFTP: CFTP. 63: NETWORK_INTERNAL: Reserved for network internal use. 64: SAT_EXPAK: SATNET and Backroom EXPAK. 65: KRYPTOLAN: Kryptolan. 66: RVD: MIT Remote Virtual Disk Protocol. 67: IPPC: Internet Pluribus Packet Core. 68: DIST_FS: Distributed File System. 69: SAT_MON: SATNET Monitoring. 70: VISA: VISA Protocol. 71: IPCV: Internet Packet Core Utility. 72: CPNX: Computer Protocol Network Executive. 73: CPHB: Computer Protocol Heart Beat. 74: WSN: Wang Span Network. 75: PVP: Packet Video Protocol. 76: BR_SAT_MON: Backroom SATNET Monitoring. 77: SUN_ND: SUN ND PROTOCOL-Temporary. 78: WB_MON: WIDEBAND Monitoring. 79: WB_EXPAK: WIDEBAND EXPAK. 80: ISO_IP: ISO Internet Protocol. 81: VMTP: Versatile Message Transaction Protocol. 82: SECURE_VMTP: Secure Versatile Message Transaction Protocol. 83: VINES: VINES. 84: IPTM: Internet Protocol Traffic Manager. 85: NSFNET_IGP: NSFNET-IGP. 86: DGP: Dissimilar Gateway Protocol. 87: TCF: TCF. 88: EIGRP: EIGRP. 89: OSPFIGP: Open Shortest Path First. 90: Sprite_RPC: Sprite RPC Protocol. 91: LARP: Locus Address Resolution Protocol. 92: MTP: Multicast Transport Protocol. 93: AX_25: AX.25 Frames. 94: IPIP: IP-within-IP Encapsulation Protocol. 95: MICP: Mobile Internetworking Control Protocol. 96: SCC_SP: Semaphore Communications Sec. Protocol. 97: ETHERIP: Ethernet-within-IP Encapsulation. 98: ENCAP: Encapsulation Header. 99: PRIV_ENC: Private Encryption Scheme. 100: GMTP: GMTP. 101: IFMP: Ipsilon Flow Management Protocol. 102: PNNI: PNNI over IP. 103: PIM: Protocol Independent Multicast. 104: ARIS: ARIS. 105: SCPS: SCPS. 106: QNX: QNX. 107: A_N: Active Networks. 108: IP_COMP: IP Payload Compression Protocol. 109: SNP: Sitara Networks Protocol. 110: COMPAQ_PEER: Compaq Peer Protocol. 111: IPX_IN_IP: IPX in IP. 112: VRRP: Virtual Router Redundancy Protocol. 113: PGM: PGM Reliable Transport Protocol. 114: ZERO_HOP: Any 0-hop protocol. 115: L2TP: Layer Two Tunneling Protocol. 116: DDX: DDX. 117: IATP: Interactive Agent Transfer Protocol. 118: STP: Schedule Transfer Protocol. 119: SRP: SpectraLink Radio Protocol. 120: UTI: UTI. 121: SMP: Simple Message Protocol. 122: SM: Simple Multicast Protocol. 253: TESTING_253: Reserved for testing. 254: TESTING_254: Reserved for testing. |
|||
Start innovating with Mobius
What's next? Let's talk!