Name

AVP Code

Data Type

Vendor

Absolute-End-Fractional-Seconds

569

Unsigned32

IETF

Specifies the fractional seconds component added to the Absolute-End-Time value to determine the precise end time of a time window. If this AVP is absent from the Time-Of-Day-Condition AVP, the fractional seconds are assumed to be zero. Must be 0 ≤ value ≤ 999999999 (nanosecond precision). Example: 500000000 represents 0.5 seconds.

Absolute-End-Time

568

Time

IETF

Defines the end time of a time window in seconds since January 1, 1900, 00:00 UTC. It is used to specify when the time-based condition associated with a policy, session, or metering rule expires. If this AVP is absent from the Time-Of-Day-Condition, the time window is treated as open-ended, implying no expiration.

Absolute-Start-Fractional-Seconds

567

Unsigned32

IETF

Defines the fractional seconds component that is added to the Absolute-Start-Time AVP (566) to determine the precise start time of a time window. If this AVP is absent, the fractional seconds default to zero. Encodes the fractional second part of the start time as an integer value in microseconds (1/1,000,000 seconds). Must be used in compliance with the Time-Of-Day-Condition AVP, ensuring synchronization between absolute time and fractional precision.

Absolute-Start-Time

566

Time

IETF

Defines the absolute time at which a time window starts. It represents the time in seconds since January 1, 1900, 00:00 UTC. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window defaults to January 1, 1900, 00:00 UTC as the start time. Can be extended with Absolute-Start-Fractional-Seconds (567) for sub-second precision when required.

Classifier

511

Grouped

IETF

Specifies packet-matching rules based on various protocol parameters. This AVP supports defining packet characteristics like protocol type, direction, source, destination, and options associated with different network layers (IP, TCP, ICMP, etc.).

The AVP structure is defined as follows:

Classifier-ID (Mandatory, OctetString): Unique identifier for the classifier instance.

Protocol (Optional, Enumerated): Specifies the protocol to match (e.g., TCP, UDP).

Direction (Optional, Enumerated): Indicates traffic direction (e.g., inbound, outbound).

From-Spec (Optional, Multiple, Grouped): Specifies source criteria (e.g., IP address, port).

To-Spec (Optional, Multiple, Grouped): Specifies destination criteria.

Diffserv-Code-Point (Optional, Enumerated): Matches traffic based on DiffServ Code Points (DSCP).

Fragmentation-Flag (Optional, Enumerated): Specifies rules based on fragmentation status.

IP-Option (Optional, Multiple, Grouped): Matches packets based on specific IP options.

TCP-Option (Optional, Multiple, Grouped): Matches packets based on TCP options.

TCP-Flags (Optional, Enumerated): Matches packets using TCP control flags (e.g., SYN, ACK).

ICMP-Type (Optional, Enumerated): Matches ICMP message types.

ETH-Option (Optional, Multiple, Grouped): Matches packets based on Ethernet layer attributes. 

Classifier-ID

512

OctetString

IETF

Serves as a unique identifier for a classifier within the Classifier AVP. Its primary purpose is to distinguish between different classifiers, enabling precise definition and identification of traffic-matching rules.

The scope of uniqueness for this identifier is application-specific—it can be unique per terminal, globally unique, or constrained within a local deployment based on the application requirements.

This AVP MUST always be included within a Classifier AVP and cannot appear outside of it.

C-VID-End

556

Unsigned32

IETF

Specifies the end value of a range of VLAN IDs (C-VID) to be matched within a classifier. This AVP is used in traffic filtering or policy enforcement rules based on VLAN tagging in Ethernet networks.

It represents the highest VLAN ID in a range that is subject to matching criteria, allowing definition of inclusive ranges between a start and end VLAN ID.

This AVP is particularly useful in scenarios where grouped VLAN filtering is required rather than individual VLAN matching.

The value MUST be in the range 0 to 4095, as defined by the 12-bit VLAN ID field in IEEE 802.1Q standards.

Typically used alongside the C-VID-Start AVP (555) to define a range of VLAN IDs.

The C-VID-Start must always be less than or equal to C-VID-End for a valid range definition.

Multiple instances of this AVP can be included in a Classifier AVP when defining multiple VLAN ranges for matching.

If this AVP is absent, implementations MUST default to matching a single VLAN ID defined by the C-VID-Start AVP.

C-VID-Start

555

Unsigned32

IETF

Specifies the start value of a range of VLAN IDs (C-VID) to be matched within a classifier. It is used in traffic filtering or policy enforcement rules based on VLAN tagging in Ethernet networks.

This AVP defines the lower bound of VLAN IDs in the specified range and is often paired with C-VID-End AVP (AVP Code 556) to create inclusive ranges for VLAN matching.

The value MUST be in the range 0 to 4095, complying with the 12-bit VLAN ID field in IEEE 802.1Q standards.

Typically used together with the C-VID-End AVP (556) to define a range of VLAN IDs.

C-VID-Start must always be less than or equal to C-VID-End for a valid range definition.

Multiple instances of this AVP can be included in a Classifier AVP when defining multiple VLAN ranges for matching.

If C-VID-End is absent, the range is limited to a single VLAN ID defined by the C-VID-Start value.

Day-Of-Month-Mask

564

Unsigned32 (Bitmask32)

IETF

Defines a bitmask representing specific days of the month for which a time window condition should match. Each bit position corresponds to a day of the month, starting with bit 0 for the 1st day and ending with bit 30 for the 31st day. Unused bits MUST be set to 0. Bits set outside the 31-day range are invalid and should raise an error. If this AVP is absent, the time window condition applies to all days of the month. Only one instance of this AVP can be used in a Time-Of-Day-Condition grouping.

Day-Of-Week-Mask

563

Unsigned32 (Bitmask)

IETF

Used to specify a bitmask that defines the days of the week for which a time window is valid or applicable. Each bit in the bitmask corresponds to a specific day, starting from Sunday (Bit 0) to Saturday (Bit 6). The set bits indicate the days when the rule or condition applies, while unset bits are ignored. If this AVP is absent, the time window defaults to all days of the week.

Bit Mapping:

0: Sunday

1: Monday

2: Tuesday

3: Wednesday

4: Thursday

5: Friday

6: Saturday

Only Bits 0–6 are valid; invalid values (e.g., setting bits outside the range 0–6) MUST generate an error.

Can select single or multiple days by setting multiple bits in the mask.

If the AVP is absent, the condition applies to all days by default.

Diffserv-Code-Point

535

Enumerated

IETF

Specifies the Differentiated Services Codepoints (DSCP) used to classify and prioritize IP packets in Differentiated Services (DiffServ) networks, as defined in [RFC 2474]. It maps to the DS field in the IP header, allowing routers and switches to handle packets with specific quality-of-service (QoS) policies.

This AVP is particularly useful for traffic classification, prioritization, and bandwidth management in IP-based networks, enabling per-hop behavior (PHB) decisions.

Values must comply with IANA’s Differentiated Services Field Codepoints registry.

Defined Codepoints:

Class Selectors (CS): Used for priority handling in legacy environments.

Assured Forwarding (AF): Provides four classes (AF1–AF4) with three drop precedences each.

Expedited Forwarding (EF): Offers low-loss, low-latency, and low-jitter services.

VOICE-ADMIT: Reserved for admitted voice traffic requiring high reliability.

If this AVP is absent, all traffic is treated as CS0 (Default Forwarding).

Enumerated Values (IANA Defined):

0: CS0: Default Forwarding (Best Effort)

8: CS1: Priority Handling, Low Precedence

16: CS2: Priority Handling, Medium Precedence

24: CS3: Priority Handling, High Precedence

32: CS4: Critical Applications

40: CS5: Signaling Traffic

48: CS6: Network Control

56: CS7: Reserved for Highest Priority

10: AF11: Assured Forwarding, Low Drop (Class 1)

12: AF12: Assured Forwarding, Medium Drop (C1)

14: AF13: Assured Forwarding, High Drop (C1)

18: AF21: Assured Forwarding, Low Drop (Class 2)

20: AF22: Assured Forwarding, Medium Drop (C2)

22: AF23: Assured Forwarding, High Drop (C2)

26: AF31: Assured Forwarding, Low Drop (Class 3)

28: AF32: Assured Forwarding, Medium Drop (C3)

30: AF33: Assured Forwarding, High Drop (C3)

34: AF41: Assured Forwarding, Low Drop (Class 4)

36: AF42: Assured Forwarding, Medium Drop (C4)

38: AF43: Assured Forwarding, High Drop (C4)

46: EF: Expedited Forwarding (Low Latency)

44: VOICE_ADMIT: Reserved for Admitted Voice Traffic

Direction

514

Enumerated

IETF

Specifies the flow direction for applying a classifier. It determines whether the traffic filtering rules are enforced on incoming, outgoing, or both directions of network flows related to a managed terminal. This AVP provides flexibility for defining classifiers based on the direction of data flow in traffic management and policy enforcement.

If the Direction AVP is absent, the classifier is applied to both directions by default.

Enumerated Values:

0 IN: The classifier applies to flows from the managed terminal (outbound traffic).

1 OUT: The classifier applies to flows to the managed terminal (inbound traffic).

2 BOTH: The classifier applies to flows in both directions—to and from the managed terminal.

IN and BOTH:

• The From-Spec refers to the managed terminal (e.g., a subscriber's device).

• The To-Spec refers to the unmanaged terminal (e.g., a server).

OUT:

• The From-Spec refers to the unmanaged terminal (e.g., a server).

• The To-Spec refers to the managed terminal (e.g., a subscriber's device).

ETH-Ether-Type

550

OctetString

IETF

Represents the EtherType field in Ethernet frames, which identifies the protocol encapsulated within the frame. This AVP is used for packet classification and traffic filtering in Diameter-based policy management systems.

The value is a 2-byte (16-bit) identifier stored as an OctetString, and it may indicate standard protocols such as IPv4 (0x0800), IPv6 (0x86DD), ARP (0x0806), and others.

Compliant with IEEE 802.3 Ethernet frame definitions.

Supports both DIX Ethernet II and SNAP encapsulation.

Mutual Exclusivity with ETH-SAP AVP:

ETH-SAP AVP must NOT be present if ETH-Ether-Type is specified, ensuring compatibility with different Ethernet encapsulation types.

If absent, the AVP matches all EtherTypes in traffic.

ETH-Option

548

Grouped

IETF

Used to specify Ethernet-specific attributes in the Diameter protocol, as defined in [RFC 5777]. It is designed to support network policies related to Ethernet flows, enabling detailed classification and handling of Ethernet traffic.

The AVP structure is defined as follows:

ETH-Proto-Type (Mandatory): Specifies the Ethernet Protocol Type to identify the protocol in use within the Ethernet frame (e.g., IPv4, IPv6, ARP). This field is mandatory and must be included to determine the protocol characteristics of the Ethernet traffic.

VLAN-ID-Range (Optional, Multiple): Represents a list of VLAN ID ranges used for traffic classification and filtering based on VLAN tagging. Each entry defines a range of VLAN IDs, enabling policies for specific VLAN segments. Useful in network slicing and virtualized network environments for differentiated services.

User-Priority-Range (Optional, Multiple): Defines priority ranges based on user-defined priority levels for Ethernet traffic. These priorities are aligned with IEEE 802.1Q standards, supporting traffic prioritization and QoS mechanisms. Allows classification of traffic for prioritization within Ethernet frames.

Allows inclusion of additional attributes defined as AVPs, enabling extensibility for future enhancements or vendor-specific attributes.

ETH-Proto-Type

549

Grouped

IETF

Used to specify the encapsulated protocol type for Ethernet traffic, as defined in [RFC 5777]. It is employed in Diameter-based network policies to identify protocol types within Ethernet frames, supporting traffic classification and enforcement. This AVP allows the definition of protocol type attributes through two mutually exclusive parameters — ETH-Ether-Type and ETH-SAP — enabling flexibility in handling protocol identification mechanisms.

The AVP structure is defined as follows:

ETH-Ether-Type (Optional, Multiple): Represents one or more 16-bit EtherType values as defined in the IEEE 802.3 standard. Used to indicate the protocol encapsulated in the Ethernet frame, such as IPv4 (0x0800), IPv6 (0x86DD), or ARP (0x0806). Enables classification based on specific protocol types for packet handling and QoS policies.

ETH-SAP (Optional, Multiple): Specifies one or more 8-bit Service Access Point (SAP) identifiers, compliant with IEEE 802.2 LLC standards. Provides an alternative method to identify the protocol type, particularly for environments that use SAP addressing instead of EtherType. Useful in scenarios where protocols operate within logical link control layers.

Allows for extensibility by including additional AVPs to support future enhancements or vendor-specific needs.

ETH-SAP

551

OctetString

IETF

Used to specify the Service Access Point (SAP) identifiers in accordance with the IEEE 802.2 LLC standard. This AVP facilitates protocol identification and traffic classification in Ethernet-based networks using Logical Link Control (LLC) addressing.

The value of this AVP is a double-octet representation of SAP addresses:

First Octet: Destination Service Access Point (DSAP): Encoded in the first octet, it identifies the protocol or service that the Ethernet frame is intended for. Used for routing and filtering traffic within Ethernet frames based on the logical endpoint.

Second Octet: Source Service Access Point (SSAP): Encoded in the second octet, it specifies the origin protocol or service within the Ethernet frame. Enables source identification for protocol-level communication.

EUI64-Address

527

OctetString

IETF

Used to specify a single Layer 2 address in the EUI-64 (Extended Unique Identifier-64) format. This AVP provides a standardized method for identifying devices at the data link layer in Ethernet or other IEEE 802 networks. The value of this AVP is an 8-octet binary encoding of the address, represented exactly as it appears in the frame header. It is primarily used for identifying network interfaces in scenarios requiring unique and globally addressable identifiers.

EUI64-Address-Mask

528

Grouped

IETF

Used to specify a range of EUI-64 addresses by applying a bit mask to match specific address patterns. This AVP is essential for classifying Ethernet traffic based on address ranges and supports policy enforcement and traffic filtering in networks utilizing EUI-64 addressing. The AVP enables flexible address matching by defining a base address and a corresponding mask pattern. The mask determines which bits in the base address must match, allowing for specification of address groups rather than individual addresses.

The AVP structure is defined as follows:

EUI64-Address (Mandatory): Encodes the base EUI-64 address in an 8-octet binary format. Serves as the starting point for address matching, defined as the address range's lower boundary. Typically derived from IEEE 802 identifiers to ensure uniqueness.

EUI64-Address-Mask-Pattern (Mandatory): Encodes the mask pattern in an 8-octet binary format. Determines which bits in the base EUI-64 address must match. Bits set to '1' in the mask require an exact match, while bits set to '0' allow variation. Enables matching of address ranges rather than single addresses.

Allows inclusion of additional attributes for extensibility or vendor-specific enhancements.

EUI64-Address-Mask-Pattern

529

OctetString

IETF

Specifies an 8-octet bitmask used to define which bit positions in an EUI-64 address must match for classification or filtering purposes. This AVP is typically used in conjunction with the EUI64-Address-Mask AVP (528) to enable flexible and scalable address matching, allowing network policies to target ranges of Ethernet addresses rather than specific individual addresses. 

Mask Pattern (8 octets): Encodes the bitmask used for address matching. Each bit set to '1' specifies that the corresponding bit in the EUI64-Address AVP must match exactly. Each bit set to '0' allows variability at that position, enabling address range matching.

Example:

EUI64-Address: 00-10-A4-FF-FE-23-00-00

EUI64-Address-Mask-Pattern: FF-FF-FF-FF-FF-FF-00-00

Matches all addresses from 00-10-A4-FF-FE-23-00-00 to 00-10-A4-FF-FE-23-FF-FF.

Excess-Treatment

577

Grouped

IETF

Specifies how out-of-profile traffic — traffic that exceeds the limits defined in the original QoS-Profile-Template and QoS-Parameters AVPs — should be treated.

This AVP provides network nodes with explicit instructions for handling excess traffic by including information about treatment actions, alternative quality of service (QoS) profiles, and associated parameters. If this AVP is absent, the treatment of excess traffic is left to the discretion of the node applying QoS enforcement.

The AVP structure is defined as follows:

Treatment-Action (Mandatory): Specifies the action to be applied to out-of-profile traffic.

Actions may include dropping packets, marking them for lower priority, or re-routing to specific queues. Ensures consistent handling of excess traffic in accordance with QoS policies.

QoS-Profile-Template (Optional): Defines an alternative QoS profile to be applied to excess traffic. Allows administrators to specify different treatment parameters, ensuring flexibility in managing bursts of traffic that exceed initial allocations.

QoS-Parameters (Optional): Provides additional details about QoS settings, such as bandwidth limits, latency thresholds, or jitter constraints, for excess traffic.

Enables fine-grained control over traffic characteristics and policy enforcement.

Allows for extensibility to include vendor-specific attributes or future enhancements to handle excess traffic.

Filter-Rule

509

Grouped

IETF

Specifies a combination of conditions and actions used to enforce traffic filtering and Quality of Service (QoS) policies within Diameter-based networks. This AVP provides a flexible framework to define filtering rules for classifying packets based on specific criteria and applying associated QoS treatments.

The AVP structure is defined as follows:

Filter-Rule-Precedence (Optional): Indicates the precedence of this filter rule relative to other rules. Lower values represent higher precedence, ensuring prioritization when multiple rules are evaluated.

Condition Parameters (Optional):

Classifier: Defines criteria for identifying packets based on attributes such as source/destination IP address, port number, or protocol type.

Used to classify traffic flows for QoS enforcement.

Time-Of-Day-Condition (Optional, Multiple): Specifies time-based conditions for activating the filter rule. Allows time-dependent enforcement of QoS policies, e.g., peak-hour prioritization.

Action Parameters (Optional):

Treatment-Action: Specifies the action to be taken, such as marking, shaping, or dropping packets that meet the defined conditions. Supports traffic management and policy enforcement based on predefined rules.

QoS Parameters (Optional): 

QoS-Semantics: Defines semantics associated with QoS policies, ensuring consistency across different QoS profiles.

QoS-Profile-Template: Provides a template for QoS settings, specifying default or custom profiles for traffic treatment. Ensures consistency in QoS enforcement across network nodes.

QoS-Parameters: Contains additional QoS details such as bandwidth allocation, latency thresholds, and jitter limits. Allows fine-tuning of QoS policies to meet service-level agreements (SLAs).

Excess-Treatment: Defines handling instructions for traffic exceeding the defined QoS limits. Supports actions such as rerouting, dropping, or reprioritizing excess traffic.

Extension Point (Optional, Multiple): 

Allows for extensibility to include vendor-specific attributes or custom parameters for advanced policy management.

Filter-Rule-Precedence

510

Unsigned32

IETF

Specifies the execution order of rules within the QoS-Resources AVP. This precedence value determines the priority of filter rules, where lower numerical values represent higher precedence. Rules with higher precedence are evaluated and executed before those with lower precedence, ensuring strict ordering of policies for traffic filtering and Quality of Service (QoS) enforcement.

If the Filter-Rule-Precedence AVP is absent from the Filter-Rule AVP, rules should be executed in the order of appearance within the QoS-Resources AVP.

Fragmentation-Flag

536

Enumerated

IETF

Specifies the fragmentation flags present in the IP header of packets, enabling Diameter-based systems to filter and classify traffic based on packet fragmentation attributes. This AVP is primarily used for traffic management, filtering, and Quality of Service (QoS) enforcement in IP-based networks, especially in scenarios where packet fragmentation affects routing, reassembly, or processing.

Enumerated Values:

0: Don't Fragment (DF): Matches packets with the DF (Don't Fragment) flag set in the IP header. Indicates that the packet cannot be fragmented during transmission. Used to enforce strict handling of packets requiring end-to-end integrity without fragmentation.

1: More Fragments (MF): Matches packets with the MF (More Fragments) flag set in the IP header. Indicates that the packet is fragmented and additional fragments follow. Useful for handling scenarios where fragmented packets require special processing or reassembly.

From-Spec

515

Grouped

IETF

Specifies the source specification for matching packets based on criteria such as IP address, MAC address, EUI-64 address, and port numbers. This AVP is used in classifiers to define filtering rules for packets originating from specific sources.

If the From-Spec AVP is absent, all packets match regardless of the source address. When multiple instances of this AVP are present, a packet source can match any of the specified rules.

When multiple criteria (e.g., IP address, MAC address, and port) are defined within a single From-Spec, the packet must match all specified parameters simultaneously to be considered a match.

The AVP structure is defined as follows:

IP-Address (Optional, Multiple): Specifies one or more source IP addresses. Packets must match one of the listed addresses.

IP-Address-Range (Optional, Multiple): Defines ranges of source IP addresses. Allows packets within the specified range to match.

IP-Address-Mask (Optional, Multiple): Specifies IP address ranges using masks. Matches packets based on network and subnet masks.

MAC-Address (Optional, Multiple): Matches one or more source MAC addresses at Layer 2. Enables filtering based on physical device identifiers.

MAC-Address-Mask (Optional, Multiple): Allows filtering of MAC address ranges using masks. 

EUI64-Address (Optional, Multiple): Matches source EUI-64 addresses. Typically used in Ethernet-based networks with globally unique identifiers.

EUI64-Address-Mask (Optional, Multiple): Allows filtering of EUI-64 address ranges with masks.

Port (Optional, Multiple): Matches specific source port numbers at Layer 4. Useful for application-specific filtering.

Port-Range (Optional, Multiple): Allows filtering of packets within port ranges. Supports matching a series of contiguous port numbers.

Negated (Optional): If set, specifies that the rule applies to packets not matching the listed parameters. Enables exclusion-based filtering.

Use-Assigned-Address (Optional): Specifies that dynamically assigned addresses should be matched instead of statically defined addresses.

Allows extensibility for future enhancements or vendor-specific attributes.

High-User-Priority

559

Unsigned32

IETF

Specifies the priority level assigned to a user in traffic classification and Quality of Service (QoS) enforcement scenarios. This AVP is used to determine the precedence of user traffic within a network, enabling prioritization based on defined policies.

The value must be in the range 0 to 7.

Lower values correspond to higher priorities, ensuring more favorable treatment for traffic associated with users having higher priority levels.

ICMP-Code

547

Enumerated

IETF

Specifies ICMP (Internet Control Message Protocol) error codes used to classify and handle ICMP messages for network diagnostics, error reporting, and policy enforcement. The values for this AVP are managed by IANA under the ICMP Type Numbers registry as defined in [RFC 2780]. These codes provide granular filtering and treatment options based on ICMP error types and codes.

Enumerated Values:

0: NET_UNREACHABLE: Network is unreachable.

1: HOST_UNREACHABLE: Host is unreachable.

2: PROTOCOL_UNREACHABLE: Protocol is unreachable.

3: PORT_UNREACHABLE: Port is unreachable.

4: FRAGMENTATION_NEEDED_AND_DONT_FRAGMENT_SET: Fragmentation is required, but the 'Don't Fragment' flag is set.

5: SOURCE_ROUTE_FAILED: Source route failed.

6: DESTINATION_NETWORK_UNKNOWN: Destination network is unknown.

7: DESTINATION_HOST_UNKNOWN: Destination host is unknown.

8: SOURCE_HOST_ISOLATED: Source host is isolated.

9: COMMUNICATION_WITH_DESTINATION_NETWORK_IS_ADMINISTRATIVELY_PROHIBITED: Communication with the destination network is administratively prohibited.

10: COMMUNICATION_WITH_DESTINATION_HOST_IS_ADMINISTRATIVELY_PROHIBITED: Communication with the destination host is administratively prohibited.

11: DESTINATION_NETWORK_UNREACHABLE_FOR_TYPE_OF_SERVICE: Destination network is unreachable for the specified type of service.

12: DESTINATION_HOST_UNREACHABLE_FOR_TYPE_OF_SERVICE: Destination host is unreachable for the specified type of service.

13: COMMUNICATION_ADMINISTRATIVELY_PROHIBITED: Communication is administratively prohibited.

14: HOST_PRECEDENCE_VIOLATION: Host precedence violation occurred.

15: PRECEDENCE_CUTOFF_IN_EFFECT: Precedence cutoff is in effect.

ICMP-Type

545

Grouped

IETF

Specifies an ICMP (Internet Control Message Protocol) message type that must be matched for filtering, classification, or Quality of Service (QoS) enforcement. This AVP provides granular control over traffic by allowing filtering based on ICMP types and codes as defined in the IANA registry for ICMP message types. It also supports negation, enabling exclusion-based rules for enhanced traffic management.

The AVP structure is defined as follows:

ICMP-Type-Number (Required): Specifies the ICMP message type number that must be matched in the packet header. Values correspond to IANA-defined ICMP message types.

ICMP-Code (Optional, Multiple): Specifies the ICMP code values associated with the ICMP-Type. Matches specific error conditions or variations for the defined ICMP type.

Negated (Optional): Indicates that the rule applies to packets not matching the specified ICMP-Type or ICMP-Code.

When ICMP-Code is present, negation applies to the specified code.

When ICMP-Code is absent, negation applies to the ICMP-Type.

Allows for extensibility by including additional attributes or vendor-specific enhancements.

ICMP-Type-Number

546

Enumerated

IETF

Specifies the ICMP message type number for filtering, classification, and Quality of Service (QoS) enforcement. The values for this AVP are managed by IANA under the ICMP Type Numbers registry as defined in [RFC 2780]. Each type corresponds to a specific ICMP function, such as error reporting or network diagnostics.

Enumerated Values:

0: ECHO_REPLY: ICMP Echo Reply (response to a ping).

3: DESTINATION_UNREACHABLE: Indicates that the destination is unreachable.

4: SOURCE_QUENCH: Congestion control; requests sender to slow down transmission.

5: REDIRECT: Redirects traffic to another route.

6: ALTERNATE_HOST_ADDRESS: Specifies an alternate host address.

8: ECHO: ICMP Echo Request (ping).

9: ROUTER_ADVERTISEMENT: Advertises the presence of a router.

10: ROUTER_SOLICITATIONS: Requests router advertisement messages.

11: TIME_EXCEEDED: Packet TTL (time-to-live) expired in transit.

12: PARAMETER_PROBLEM: Issues with invalid header fields in the packet.

13: TIMESTAMP: Requests a timestamp for time synchronization.

14: TIMESTAMP_REPLY: Response with a timestamp.

15: INFORMATION_REQUEST: Requests information from a router.

16: INFORMATION_REPLY: Replies with requested information.

17: ADDRESS_MASK_REQUEST: Requests subnet mask from a router.

18: ADDRESS_MASK_REPLY: Replies with the requested subnet mask.

30: TRACEROUTE: Used for path tracing between two nodes.

31: DATAGRAM_CONVERSION_ERROR: Error in converting datagrams.

32: MOBILE_HOST_REDIRECT: Redirects traffic for mobile hosts.

33: IPV6_WHERE_ARE_YOU: Query for IPv6 presence.

34: IPV6_I_AM_HERE: Response indicating IPv6 presence.

35: MOBILE_REGISTRATION_REQUEST: Mobile host registration request.

36: MOBILE_REGISTRATION_REPLY: Mobile host registration reply.

37: DOMAIN_NAME_REQUEST: Queries domain name information.

38: DOMAIN_NAME_REPLY: Replies with domain name information.

39: SKIP: Reserved for future use.

40: PHOTURIS: Security protocol error messages.

41: EXPERIMENTAL: Reserved for experimentation.

42: EXTENDED_ECHO_REQUEST: Extended echo request.

43: EXTENDED_ECHO_REPLY: Extended echo reply.

253: EXPERIMENT_1: Reserved for experimental use.

254: EXPERIMENT_2: Reserved for experimental use.

IP-Address

518

Address

IETF

Specifies a single IP address, either IPv4 or IPv6, used for traffic classification, filtering, and Quality of Service (QoS) enforcement. This AVP is commonly employed in filtering rules and policy definitions to match traffic originating from or destined to a specific IP address. It supports addressing mechanisms for both IPv4 (32 bits) and IPv6 (128 bits) formats.

This AVP is often used within From-Spec or To-Spec AVPs to define source or destination IP addresses.

It may appear multiple times in a Grouped AVP to specify multiple addresses for matching purposes.

When combined with IP-Address-Range or IP-Address-Mask, it enables flexible traffic filtering based on address ranges or subnets.

IP-Address-End

521

Address

IETF

Specifies the last IP address in an address range, supporting both IPv4 and IPv6 formats. This AVP is typically used in conjunction with the IP-Address-Start AVP to define a range of IP addresses for traffic filtering, classification, and Quality of Service (QoS) enforcement.

IPv4 Address: Encoded as 32 bits in network byte order. Example: 192.168.1.100

IPv6 Address: Encoded as 128 bits in network byte order. Example: 2001:0db8::ff

IP-Address-Mask

522

Grouped

IETF

Specifies an IP address range using a base IP address and a bit-width mask. The IP-Address-Mask AVP simplifies matching traffic against subnets by defining an IP address prefix (e.g., 192.0.2.0/24) and ensuring all addresses within the specified range match the rule.

The AVP structure is defined as follows:

IP-Address (Mandatory): Specifies the base IP address in either IPv4 or IPv6 format. Encoded in network byte order.

IP-Bit-Mask-Width (Mandatory): Specifies the bit-width of the mask to determine the size of the address range.

Allows additional AVPs to be included. 

When combined with other AVPs such as Negated, it supports exclusion-based filtering, allowing traffic outside the specified range to be processed differently.

IP-Address-Range

519

Grouped

IETF

Specifies an inclusive range of IP addresses for traffic filtering, classification, and Quality of Service (QoS) enforcement. It supports both IPv4 and IPv6 addresses.

The AVP structure is defined as follows:

IP-Address-Start (Optional): Specifies the starting IP address of the range. Encoded in network byte order.

If this parameter is absent, the range starts from the first valid IP address supported by the protocol (e.g., 0.0.0.0 for IPv4).

IP-Address-End (Optional): Specifies the ending IP address of the range. Encoded in network byte order. If this parameter is absent, the range includes all addresses starting from the specified IP-Address-Start up to the last valid address supported by the protocol (e.g., 255.255.255.255 for IPv4).

Allows additional AVPs to be included.

If both IP-Address-Start and IP-Address-End are included, the Start value must be less than the End value for the AVP to be valid.

IP-Address-Start

520

Address

IETF

Specifies the first IP address (IPv4 or IPv6) in an IP address range. This AVP is typically used in conjunction with the IP-Address-End AVP to define an inclusive range of IP addresses for traffic classification and policy enforcement.

IP-Bit-Mask-Width

523

Unsigned32

IETF

Specifies the width of an IP address bit mask, which determines the range of IP addresses included in a subnet. This AVP is typically used in conjunction with an IP address (e.g., IP-Address or IP-Address-Mask) to define subnet-based traffic classification and policy enforcement.

The value of the AVP represents the number of significant bits in the subnet mask.

For example:

A value of 24 corresponds to a subnet mask of 255.255.255.0 for IPv4.

A value of 64 corresponds to a typical IPv6 subnet mask.

IP-Option

537

Grouped

IETF

Specifies an IP header option that must be matched for traffic classification or policy enforcement. This AVP allows for fine-grained control of IP-based traffic by matching specific IP header options or excluding certain options using negation.

The AVP structure is defined as follows:

IP-Option-Type (Mandatory): Specifies the type of IP header option to match. If the IP-Option-Value AVP is absent, this parameter ensures the presence of the option type in the IP header, with the value treated as a wildcard.

IP-Option-Value (Optional, Multiple): Specifies one or more values for the IP header option. If present, at least one of the provided values must match the value in the IP header.

Negated (Optional): Indicates a negation condition:

If used with IP-Option-Value, specifies IP options that do not match the given values.

If used without IP-Option-Value, specifies IP headers that do not contain the specified option type.

Allows additional AVPs to be included.

IP-Option-Type

538

Enumerated

IETF

Specifies the type of IP header option, with the enumerated values managed by IANA under the IP Option Numbers registry.
Enumerated Values:

The AVP supports the following IP Option Types, as defined by IANA and [RFC 2780]:

0: EOOL (End of Option List): Indicates the end of the options list.

1: NOP (No Operation): Used for padding between options.

7: RR (Record Route): Records the route of the packet.

10: ZSU (Experimental Measurement): Reserved for experimental use.

11: MTUP (MTU Probe): Measures MTU along the path.

12: MTUR (MTU Reply): Replies to an MTU probe.

68: TS (Timestamp): Records timestamps.

130: SEC (Security): Indicates security levels.

131: LSR (Loose Source Route): Specifies a partial source route.

133: ESEC (Extended Security): Provides extended security features.

134: CIPSO (Common IP Security Option): Specifies security levels and categories.

136: SID (Stream Identifier): Identifies a data stream.

137: SSR (Strict Source Route): Specifies a strict source route.

142: VISA: Indicates Visa protocol-specific options.

145: EIP (Extended Internet Protocol): Indicates an extended IP.

25: QS (Quick-Start): Indicates quick-start features.

30, 94, 158, 222: Experimental options (EXP_1, EXP_2, EXP_3, EXP_4): Reserved for experimental use.

IP-Option-Value

539

OctetString

IETF

Specifies the value of an IP header option that must be matched for traffic classification, routing decisions, or policy enforcement. This AVP is typically used within the IP-Option AVP to refine traffic matching based on specific option values. 

If multiple IP-Option-Value AVPs are included, one of the values must match the IP header option.

When this AVP is absent within the IP-Option AVP, the type is matched, but the value is treated as a wildcard.

Low-User-Priority

558

Unsigned32

IETF

Represents the user priority level for a specific service or traffic flow, with the value ranging from 0 to 7. 

0: Highest priority.

7: Lowest priority.

MAC-Address

524

OctetString

IETF

Specifies a single Layer 2 (MAC-48 format) address. The value is encoded as a 6-octet binary representation of the MAC address as it appears in the frame header.

MAC-Address-Mask

525

Grouped

IETF

Specifies a range of MAC addresses using a bit mask to define the bits of the MAC addresses that must match the specified MAC-Address. 

The AVP structure is defined as follows:

MAC-Address (Mandatory): Specifies the base MAC address that serves as the starting point for matching. Encoded as a 6-octet binary value in MAC-48 format.

MAC-Address-Mask-Pattern (Mandatory): Specifies the bit mask to define the matching range of MAC addresses. A binary value where each bit corresponds to a bit in the MAC-Address:

A bit value of 1 indicates the corresponding bit in the address must match.

A bit value of 0 allows any value for the corresponding bit.

Allows additional AVPs to be included.

MAC-Address-Mask-Pattern

526

OctetString

IETF

Specifies a 6-octet bit mask used to match a range of MAC addresses. The mask indicates which bits in the corresponding MAC-Address are significant for matching, enabling flexible grouping and classification of devices based on MAC address patterns.

The MAC-Address-Mask-Pattern is a binary value where:

A bit value of 1 means the corresponding bit in the MAC address must match.

A bit value of 0 allows any value for the corresponding bit in the MAC address.

This AVP is typically used within the MAC-Address-Mask AVP to define ranges of MAC addresses for traffic classification or policy enforcement.

To match specific MAC addresses, use a mask with all bits set to 1 (FF-FF-FF-FF-FF-FF).

To match ranges of MAC addresses, set some bits in the mask to 0. For example:

MAC-Address: 00-10-A4-23-00-00

MAC-Address-Mask-Pattern: FF-FF-FF-FF-00-00

Matches all MAC addresses from 00-10-A4-23-00-00 to 00-10-A4-23-FF-FF.

Month-Of-Year-Mask

565

Unsigned32 (Bitmask)

IETF

Uses a bitmask to specify the months of the year during which a given time condition is valid. Each bit in the mask corresponds to a specific month, where a bit value of 1 indicates that the corresponding month is included in the matching condition.

Bit Mapping:

Bit 0 (Least Significant Bit): January

Bit 1: February

Bit 2: March

Bit 3: April

Bit 4: May

Bit 5: June

Bit 6: July

Bit 7: August

Bit 8: September

Bit 9: October

Bit 10: November

Bit 11: December

To match a specific month, the corresponding bit in the mask must be set to 1.

If the AVP is absent, the time condition applies to all months.

Any unused bits (12–31) must be set to 0 to ensure compliance with the specification.

Negated

517

Enumerated

IETF

Indicates whether the match condition specified by a classifier (e.g., in the From-Spec or To-Spec AVP) is inverted. This AVP allows for more flexible matching rules by specifying whether to match or exclude the defined addresses or specifications.

Enumerated Values:

0: False: The match is not inverted. The classifier will match the addresses or conditions explicitly specified by the associated AVP.

1: True: The match is inverted. The classifier will match addresses other than those specified by the associated AVP.

Port

530

Integer32

IETF

Specifies a port number to match in the context of traffic classification and policy enforcement. The range of values for this AVP is 0 to 65535, which covers the full range of valid port numbers. The type of port (e.g., TCP or UDP) is determined by the value of the Protocol AVP in the same classifier.

Port-End

533

Integer32

IETF

Specifies the last port number of an IP port range in a traffic classification rule. This AVP is typically used in combination with the Port-Start AVP to define a range of port numbers for matching criteria.

Port-Range

531

Grouped

IETF

Specifies an inclusive range of port numbers to match in a traffic classification rule. The type of ports (e.g., TCP or UDP) is determined by the Protocol AVP in the same classifier.

The AVP structure is defined as follows:

Port-Start (Optional): Specifies the starting port number of the range. If omitted, the default value is 0.

Port-End (Optional): Specifies the ending port number of the range. If omitted, the default value is 65535.

Allows additional AVPs to be included.

If Port-Range AVP is omitted:

Port-Start defaults to 0 (lowest possible port).

Port-End defaults to 65535 (highest possible port).

Port-Start

532

Integer32

IETF

It specifies the first port number of an IP port range in a traffic classification rule. This AVP is typically used in conjunction with the Port-End AVP to define the starting boundary of a port range for matching criteria.

Protocol

513

Enumerated

IETF

Used to specify the network protocol being matched for traffic filtering, QoS policies, and Diameter-based policy enforcement. It is an Enumerated AVP, meaning it only allows predefined integer values representing different protocols.

If the Protocol AVP is omitted, it means that protocol comparison is irrelevant in the classifier.

Enumerated Values:

0: OPOPT: 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: Internet 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

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

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 Transport 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: IP with Encryption

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: Any host internal protocol

62: CFTP: CFTP

63: NETWORK_INTERNAL: Any local network

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 Protocol

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

78: WB_MON: WIDEBAND Monitoring

79: WB_EXPAK: WIDEBAND EXPAK

80: ISO_IP: ISO Internet Protocol

81: VMTP: Versatile Message Transport Protocol

82: SECURE_VMTP: Secure VMTP

83: VINES: VINES Protocol

84: IPTM: Internet Packet Transmission Protocol

85: NSFNET_IGP: NSFNET-IGP

86: DGP: Dissimilar Gateway Protocol

87: TCF: TCF

88: EIGRP: EIGRP

89: OSPFIGP: OSPF

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-in-IP Encapsulation Protocol

95: MICP: Mobile Internetworking Control Protocol

96: SCC_SP: Semaphore Communications

97: ETHERIP: Ethernet-within-IP Encapsulation

98: ENCAP: Encapsulation Header

99: PRIV_ENC: Private Encryption Protocol

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: Zero Hop Protocol

115: L2TP: Layer Two Tunneling Protocol

116: DDX: D-II Data Exchange (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: SM

123: PTP: Precision Time Protocol (PTP)

124: ISIS_OVER_IPv4: Intermediate System to Intermediate System (IS-IS) over IPv4

125: FIRE: Flexible Intra-AS Routing Environment

126: CRTP: Combat Radio Transport Protocol

127: CRUDP: Combat Radio User Datagram

128: SSCOPMCE: Service-Specific Connection-Oriented Protocol in a Multilink Environment

129: IPLT: IPLT

130: SPS: Secure Packet Shield

131: PIPE: Private IP Encapsulation

132: SCTP: Stream Control Transmission Protocol

133: FC: Fibre Channel

134: RSVP_E2E_IGNORE: RSVP End-to-End Ignore

135: MOBILITY_HEADER: Mobility Header for IPv6

136: UDP_LITE: Lightweight User Datagram Protocol

137: MPLS_IN_IP: MPLS-in-IP

138: MANET: Mobile Ad Hoc Network Protocol

139: HIP: Host Identity Protocol

140: SHIM6: Site Multihoming by IPv6 Intermediation

141: WESP: Wrapped Encapsulating Security Payload

142: ROHC: Robust Header Compression

143: ETHERNET: Ethernet Encapsulation

144: AGGFRAG: Aggregate Fragmentation

145: NSH: Network Service Header

253: TESTING_253: Reserved for Testing

254: TESTING_254: Reserved for Testing

QoS-Capability

578

Grouped

IETF

Contains a list of supported Quality of Service (QoS) profile templates and associated parameters. It is used for announcing or negotiating QoS capabilities and profiles between Diameter peers. At least one QoS-Profile-Template AVP must be present in the QoS-Capability AVP.

The AVP structure is defined as follows:

QoS-Profile-Template (Mandatory, Multiple):

Specifies the QoS profile templates supported by the peer. Each profile template defines specific QoS parameters that the peer can handle.

Allows additional AVPs to be included.

QoS-Parameters

576

Grouped

IETF

Encapsulates a set of Quality of Service (QoS) parameters. These parameters are specific to the QoS profile template indicated in the associated QoS-Profile-Template AVP. The parameters provide detailed definitions of QoS requirements, such as bandwidth, latency, and priority levels.

The AVP structure is defined as follows:

AVP (Optional, Multiple): can include multiple additional attributes to define QoS parameters comprehensively. The specific parameters depend on the QoS profile being applied. For an initial specification of QoS parameters, refer to [RFC5624].

QoS-Profile-Id

573

Unsigned32

IETF

Specifies the identifier of a Quality of Service (QoS) profile template. The QoS profile template defines the set of QoS parameters and policies to be applied to a service or flow.

The initial QoS profile template is defined with an identifier value of 0, as specified in [RFC5624].

The identifiers for QoS profile templates are maintained in a registry created and managed as per [RFC5624].

QoS-Profile-Template

574

Grouped

IETF

Specifies a Quality of Service (QoS) profile namespace and an associated profile template identifier. This AVP is used to define and apply QoS policies by referencing a vendor-specific namespace (via the Vendor-Id AVP) and a corresponding QoS-Profile-Id AVP.

The AVP structure is defined as follows:

Vendor-Id (Mandatory): Contains a 32-bit IANA Private Enterprise Number (PEN), identifying the organization responsible for the QoS profile namespace.

• Vendor ID = 0: Refers to the IETF namespace.

• Other values: Refer to specific vendors.

QoS-Profile-Id (Mandatory): Identifies the specific QoS profile template within the namespace defined by the Vendor-Id.

Additional optional AVPs may be included to provide further information or configuration.

QoS-Resources

508

Grouped

IETF

Defines a list of filter policy rules for Quality of Service (QoS) management. It allows network elements to specify filtering rules that map traffic flows to specific QoS policies.

The AVP structure is defined as follows:

Filter-Rule (Mandatory, Repeating): Contains one or more instances of the Filter-Rule AVP, which defines specific conditions and actions associated with the traffic flow. A Filter-Rule may include attributes such as precedence, QoS semantics, and treatment actions for the matching traffic.

Additional optional AVPs may be included for extensibility or to provide supplementary information.

QoS-Semantics

575

Enumerated

IETF

Provides the semantics for the QoS-Profile-Template and QoS-Parameters AVPs in the Filter-Rule AVP. It defines the context and purpose of QoS parameters exchanged between Diameter clients and servers.

Enumerated Values:

0: QoS-Desired: Client->Server: Client requests authorization of the indicated QoS.

1: QoS-Available: Client->Server: Admission Control at client indicates that this QoS is available.

1: QoS-Available: Client<-Server: Admission Control at server indicates that this QoS is available.

2: QoS-Delivered: Client->Server: Client is reporting the actual QoS delivered to the terminal.

3: Minimum-QoS: Client->Server: Client is not interested in authorizing QoS lower than the indicated QoS.

3: Minimum-QoS: Client<-Server: Client must not provide QoS guarantees lower than the indicated QoS.

4: QoS-Authorized: Client<-Server: Server authorizes the indicated QoS.

Notes:
(1) QoS-Available in this direction indicates to the server that any QoS-Authorized or Minimum-QoS must be less than this indicated QoS.

(2) QoS-Available in this direction is only useful when the AAA server performs admission control and knows about the resources in the network.

S-VID-End

554

Unsigned32

IETF

Specifies the end value of a range of S-VID VLAN-IDs used for matching VLANs in a network. It defines the upper boundary of the range and works in conjunction with the S-VID-Start AVP.

The value of this AVP MUST be between 0 and 4095, inclusive.

S-VID-Start

553

Unsigned32

IETF

Specifies the starting value of a range of S-VID VLAN-IDs used for matching VLANs in a network. It defines the lower boundary of the range and works in conjunction with the S-VID-End AVP.

The value of this AVP MUST be between 0 and 4095, inclusive.

TCP-Flags

543

Grouped

IETF

Specifies a set of TCP control flags that must be matched in a network packet. These flags determine the required or forbidden TCP states for the packet to satisfy a specific condition.

The AVP structure is defined as follows:

TCP-Flag-Type (Mandatory, Unsigned32): Specifies the TCP control flags that must be matched. Each bit in the value corresponds to a specific TCP flag (e.g., SYN, ACK, FIN, etc.).

Negated (Optional, Enumerated): 

• False (0): The specified flags in the TCP-Flag-Type must be set in the packet.

• True (1): The specified flags in the TCP-Flag-Type must be cleared in the packet.

Additional AVPs can be included to provide further details or configurations.

Behavior:

If the Negated AVP is absent or set to False, the condition matches when the flags specified in TCP-Flag-Type are present in the TCP header.

If the Negated AVP is set to True, the condition matches when the flags specified in TCP-Flag-Type are not present in the TCP header.

TCP-Flag-Type

544

Unsigned32

IETF

Specifies the TCP control flag types that must be matched in the TCP header of a packet. It is a 32-bit value where specific bits are defined by the TCP Header Flag registry as per [RFC3168].

Used in conjunction with the Negated AVP to determine inclusion or exclusion logic.

The unused bits must remain clear (set to 0) to comply with the specification.

Parameters:

First 16 Bits (4 to 15): Correspond to the TCP header format. Managed by IANA under the TCP Header Flag registry.

Bits 0 to 3: Reserved (Unused).

Bits 16 to 31: Reserved (Unused).

TCP-Option

540

Grouped

IETF

Specifies TCP header options that must match during packet classification. This AVP is used to describe specific TCP options, values, and negation criteria in the TCP header.

If one or more TCP-Option-Value AVPs are present, at least one value must match the corresponding value in the packet's TCP header.

If TCP-Option-Value is absent, the type is matched without considering specific values.

The AVP structure is defined as follows:

TCP-Option-Type (Mandatory): Identifies the type of TCP header option. 

TCP-Option-Value (Optional, Repeating): Specifies one or more values for the TCP option.

Negated (Optional): 

• True: The specified TCP-Option-Type must not be present, or the TCP-Option-Value must not match the values.

• False: Matches the specified TCP-Option-Type and any included TCP-Option-Value (default behavior if absent).

Allows additional AVPs for extensions or custom functionality.

TCP-Option-Type

541

Enumerated

IETF

Specifies the type of TCP header option to be matched. This AVP is used for traffic classification based on TCP option types defined in the TCP header. The values for this AVP are managed by IANA under the TCP Option Numbers registry as defined in [RFC2780].

Enumerated Values:

0: END_OF_OPTION_LIST: Indicates the end of the TCP options list.

1: NO_OPERATION: Used for padding between options.

2: MAXIMUM_SEGMENT_SIZE: Specifies the maximum segment size.

3: WINDOW_SCALE: Used for scaling the TCP window size.

4: SACK_PERMITTED: Indicates that Selective ACK (SACK) is allowed.

5: SACK: Selective Acknowledgement (SACK).

6: ECHO: Echo request for RTT measurement.

7: ECHO_REPLY: Echo reply for RTT measurement.

8: TIMESTAMP: Contains timestamps for RTT and PAWS.

9: PARTIAL_ORDER_CONNECTION_PERMITTED: Partial order connection indication.

10: PARTIAL_ORDER_SERVICE_PROFILE: Profile for partial order service.

11: CC: Connection count information.

12: CCNEW: New connection count.

13: CCECHO: Echo connection count.

14: TCP_ALTERNATE_CHECKSUM_REQUEST: Request for alternate checksum.

15: TCP_ALTERNATE_CHECKSUM_DATA: Data for alternate checksum.

16: SKEETER: Experimental option.

17: BUBBA: Experimental option.

18: TRAILER_CHECKSUM_OPTION: Checksum for TCP trailers.

19: MD5_SIGNATURE_OPTION: MD5 signature for TCP segments.

20: SCPS_CAPABILITIES: Space Communications Protocol Standards.

21: SELECTIVE_NEGATIVE_ACKNOWLEDGMENTS: Negative acknowledgment for selective data.

22: RECORD_BOUNDARIES: Indicates boundaries for application records.

23: CORRUPTION_EXPERIENCED: Indicates data corruption was experienced.

24: SNAP: Secure Network Address Translation Protocol.

26: TCP_COMPRESSION_FILTER: TCP compression filter.

27: QUICK_START_RESPONSE: Response to Quick-Start option.

28: USER_TIMEOUT_OPTION: User-defined timeout for connections.

29: TCP_AUTHENTICATION_OPTION: Authentication for TCP connections.

30: MULTIPATH_TCP: Multipath TCP support.

34: TCP_FAST_OPEN_COOKIE: Used for TCP Fast Open.

69: ENCRYPTION_NEGOTIATION: Negotiates encryption parameters.

172: ACCURATE_ECN_ORDER_0: Accurate ECN signaling, order 0.

174: ACCURATE_ECN_ORDER_1: Accurate ECN signaling, order 1.

253: EXPERIMENT_1: Reserved for experimental use.

254: EXPERIMENT_2: Reserved for experimental use.

TCP-Option-Value

542

OctetString

IETF

Specifies the value for a TCP header option that must be matched. It is used in conjunction with the TCP-Option AVP to define and enforce specific TCP option parameters within a classifier.

Time-Of-Day-Condition

560

Grouped

IETF

Specifies one or more time windows used to enforce specific temporal conditions within a Diameter-based policy. This AVP enables fine-grained control over when certain rules or actions are applicable.

The AVP structure is defined as follows:

Time-Of-Day-Start (Unsigned32): Specifies the start of the time window in seconds since midnight, local or UTC based on the Timezone-Flag.

Time-Of-Day-End (Unsigned32): Specifies the end of the time window. Seconds since midnight, local or UTC based on the Timezone-Flag.

Day-Of-Week-Mask (Bitmask): Defines which days of the week (e.g., Monday through Sunday) the time window applies.

Day-Of-Month-Mask (Bitmask): Defines specific days of the month for the time window (e.g., 1st, 15th, 31st).

Month-Of-Year-Mask (Bitmask): Specifies the months during which the time window applies.

Absolute-Start-Time (Date): Absolute starting point in time for the condition.

Absolute-End-Time (Date): Absolute ending point in time for the condition.

Timezone-Flag (Enumerated): Specifies whether the time window is based on local time or UTC.

If Time-Of-Day-End is earlier than Time-Of-Day-Start, the window spans midnight (e.g., 10 p.m.–2 a.m.).

Multiple Time-Of-Day-Condition AVPs can be included to define non-contiguous time windows.

Example:

A time window from 9 a.m. to 5 p.m. on weekdays can be defined as follows:

Time-Of-Day-Condition = {  

    Time-Of-Day-Start = 32400;  // 9:00 AM  

    Time-Of-Day-End = 61200;    // 5:00 PM  

    Day-Of-Week-Mask = MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY;  

    Timezone-Flag = LOCAL;  

}  

Time-Of-Day-End

562

Unsigned32

IETF

Specifies the endpoint of a time window within a Time-Of-Day-Condition AVP. The value is an offset in seconds from midnight (local or UTC, depending on the time zone). If this AVP is omitted, the end of the time window is assumed to be 11:59:59 PM (86400 seconds from midnight).

The value must fall within the valid range (1 to 86400). If an invalid value is provided, the Diameter stack should reject the AVP.

Time-Of-Day-Start

561

Unsigned32

IETF

Specifies the start of a time window within a Time-Of-Day-Condition AVP. The value is an offset in seconds from midnight, indicating when the time window begins. This AVP is optional; if absent, the time window defaults to starting at midnight (00:00:00).

The value must fall within the valid range (0 to 86400). If an invalid value is provided, the Diameter stack should reject the AVP.

Timezone-Flag

570

Enumerated

IETF

Specifies how time windows within a Time-Of-Day-Condition AVP are interpreted in terms of timezone. It defines whether the times are in UTC, local time, or as an offset from UTC. If this AVP is not present, the time windows default to UTC.

Enumerated Values:

0: UTC: The time windows are expressed in Coordinated Universal Time (UTC).

1: LOCAL: The time windows are expressed in the local time of the managed terminal.

2: OFFSET: The time windows are expressed as an offset from UTC, using the Timezone-Offset AVP.

If the Timezone-Flag AVP is absent, time windows are interpreted as UTC.

Timezone-Offset

571

Integer32

IETF

Specifies the offset in seconds from Coordinated Universal Time (UTC) that was used to express Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month-Mask, and Month-Of-Year-Mask AVPs. This AVP must be present if the Timezone-Flag AVP is set to OFFSET.

The offset value must be within the range of -43200 to 43200 seconds (equivalent to ±12 hours).

To-Spec

516

Grouped

IETF

Defines the destination specification used to match a packet's destination attributes. It is part of the classifier used in policy-based traffic management and can contain multiple criteria such as IP address, MAC address, and port information.

If multiple To-Spec AVPs are present in the classifier, the destination packet can match any of the To-Spec instances.

If the To-Spec AVP is absent, all packets are matched regardless of their destination address.

If multiple IP address AVPs (e.g., IP-Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) are present, the packet's destination IP must match one of them.

If multiple port AVPs (e.g., Port, Port-Range) are present, the destination port must match one of them.

If more than one instance of the layer 2 address AVPs (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the To-Spec, then the destination layer 2 address of the packet must match one of the addresses represented in these AVPs.

If the IP address, MAC address, and port AVPs appear in the same To-Spec AVP, then the destination packet must match all the specifications, i.e., match the IP address and MAC address and port number.

The AVP structure is defined as follows:

IP-Address: Matches specific destination IP addresses.

IP-Address-Range: Matches a range of destination IP addresses.

IP-Address-Mask: Matches a destination IP address using a mask.

MAC-Address: Matches specific destination MAC addresses.

MAC-Address-Mask: Matches a range of destination MAC addresses using a mask.

EUI64-Address: Matches specific EUI-64 destination addresses.

EUI64-Address-Mask: Matches EUI-64 destination addresses using a mask.

Port: Matches specific destination port numbers.

Port-Range: Matches a range of destination port numbers.

Negated: If set, negates the match criteria (e.g., packets not matching the given specifications).

Use-Assigned-Address: Indicates that the destination should match dynamically assigned addresses.

Treatment-Action

572

Enumerated

IETF

Specifies actions that are associated with the condition part of a rule in Diameter-based QoS and policy enforcement systems. It is used to define how network traffic should be handled when it matches a given rule. This AVP supports four predefined actions, which dictate whether packets should be dropped, shaped, marked, or permitted. These actions directly influence Quality of Service (QoS) management and policy-based traffic enforcement.

Enumerated Values:

0: drop: The traffic must be dropped (discarded). Used for policy enforcement or excess traffic policing.

1: shape: The traffic is delayed to conform to a specified traffic profile. Requires the use of QoS Parameters AVPs (e.g., TMOD-1, Bandwidth AVPs) to define shaping behavior.

2: mark: The traffic is marked using DiffServ (Differentiated Services) or other QoS markers. Requires the use of the PHB-Class AVP to specify the appropriate DiffServ codepoint.

3: permit: The traffic is allowed to pass through, bypassing any filtering or restrictions. This is the opposite of the 'drop' action.

Additional Notes [RFC2475]:

Shaping: Controls the rate at which packets are transmitted by delaying them based on a traffic profile.

Marking: Assigns specific QoS labels to packets, allowing differentiated treatment in the network.

Policing: Enforces traffic limits by dropping packets when they exceed a defined rate (handled through the Excess-Treatment AVP with a drop action).

Extensibility: Future actions may be registered per Section 10.3 of [RFC5777].

Use-Assigned-Address

534

Enumerated

IETF

Indicates whether the classifier should use the IP address assigned to the managed terminal. This AVP is typically used in scenarios where the AAA server does not know the terminal's assigned IP address when the classifier is created. It contains a boolean-like value (True or False) to represent this condition.

Enumerated Values:
0: False: Indicates that the IP address assigned to the managed terminal should not be used.

1: True: Indicates that the IP address assigned to the managed terminal should be used for classification purposes. This represents the terminal's assigned address.

If this AVP is absent, the classifier operates independently of the terminal's assigned IP address.

When the AVP is present and set to True, the IP address of the managed terminal becomes a critical part of the classifier's criteria.

User-Priority-Range

557

Grouped

IETF

Specifies an inclusive range of user_priority parameter defined in [IEEE 802.1D]. It is used to match Ethernet packets based on their user_priority parameter. The packet matches the classifier if its user_priority value falls within the range defined by the Low-User-Priority and High-User-Priority sub-AVPs.

If the User-Priority-Range AVP is omitted, the classifier disregards the user_priority parameter.

The AVP structure is defined as follows:

Low-User-Priority (Optional, Unsigned32): Specifies the lower bound of the user priority range.

High-User-Priority (Optional, Unsigned32): Specifies the upper bound of the user priority range.

An Ethernet packet matches the User-Priority-Range if its user_priority value is:

Low-User-Priority ≤ user_priority ≤ High-User-Priority

If Low-User-Priority is missing, it defaults to the lowest valid priority.

If High-User-Priority is missing, it defaults to the highest valid priority.

VLAN-ID-Range

552

Grouped

IETF

The VLAN-ID-Range AVP defines a VLAN range to be used for matching traffic in a classifier. It allows filtering of packets based on VLAN identifiers as specified by IEEE [802.1Q] (single VLAN ID) or IEEE [802.1ad] (Customer VLAN-ID and Service VLAN-ID).

Packets without VLAN tagging will not match if a VLAN range is specified.

If both S-VID and C-VID are present in one VLAN-ID-Range AVP, a packet must match both.

The AVP structure is defined as follows:

S-VID-Start / S-VID-End: Defines the Service VLAN ID range.

C-VID-Start / C-VID-End: Defines the Customer VLAN ID range.

If VLAN-ID-Range is absent from the classifier, the VLAN comparison is irrelevant. If multiple VLAN-ID-Range AVPs exist in a classifier, a packet must match at least one.

Service VLAN (S-VID) Handling

Only S-VID-Start is present: The S-VID must match S-VID-Start.

Only S-VID-End is present: The S-VID must match S-VID-End.

S-VID-Start and S-VID-End are equal: The S-VID must match the given value.

S-VID-Start < S-VID-End: The S-VID must be within the range (inclusive).

S-VID omitted: IEEE 802.1ad encapsulation is ignored.

Customer VLAN (C-VID) Handling

Only C-VID-Start is present: The C-VID must match C-VID-Start.

Only C-VID-End is present: The C-VID must match C-VID-End.

C-VID-Start and C-VID-End are equal: The C-VID must match the given value.

C-VID-Start < C-VID-End: The C-VID must be within the range (inclusive).

C-VID omitted: VLAN ID comparison is irrelevant.