Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (31)
SNMP was included as a transport option to reuse existing installed devices that already implement SNMP agents, avoiding transport-protocol-level redesign. However, its UDP basis increases congestion risk and produces larger encoded messages than TCP, so TCP is RECOMMENDED wherever available.
TCP port 7744 was chosen specifically to lie above 5000 because Unix systems auto-assign ephemeral ports between 1024 and 5000 and restrict ports below 1024 to privileged processes, making those ranges unsuitable for a fixed well-known service port.
The APP (application-specific) part of the PDU is designed to accommodate new application extensions without requiring a new PDU type value registration, enabling modular extensibility. RRCs are required to recognize but not necessarily interpret vendor extensions.
Under the SNMP transport, the RCN (Record Count Number) supports a maximum of 16 sub-sessions (0–15); this limitation is explicitly imposed for compatibility with other transport protocols, constraining the SNMP mapping relative to the TCP PDU's 256-record maximum.
After initiating a TLS closure, the initiator MUST discard any TLS messages until it receives a closure alert. The other party, upon receiving a closure alert, MUST immediately transmit a TLS closure alert.
After sending a StartTLS request, the client MUST NOT send any PDUs on that connection until it receives a StartTLS response (TLS_RESP).
Any RAQMON-compliant RRC MUST recognize vendors' SMI Enterprise Codes and MUST recognize the presence of application-specific extensions identified by Report Type fields, even without understanding their semantics.
Data Source Name text MUST NOT be longer than 255 octets and MUST be encoded in UTF-8 per RFC 3629.
RDSs MUST send a RAQMON NULL PDU (B=0, T=0) to the RRC to signal the end of a reporting session. A NULL PDU ends with the DSRC field.
RRCs MUST implement the TCP transport for RAQMON PDUs and MAY implement the SNMP transport. This asymmetry ensures all collectors support the congestion-safe transport regardless of which the RDS uses.
The client MUST check the server's hostname against the server's identity in its TLS certificate using the dnsNAME in the subjectAltName field in order to prevent man-in-the-middle attacks. Matching is case-insensitive and wildcards apply only to the left-most name component.
The client MUST refresh any cached server capabilities information upon TLS session establishment to protect against active-intermediary attacks that may have altered pre-TLS capability information.
The server MUST authenticate the RDS client (require a client certificate and private-key proof) when deployment is susceptible to man-in-the-middle or spoofing attacks. Deployments requiring sensitive data protection MUST negotiate a ciphersuite with a bulk encryption algorithm of appropriate strength.
The server MUST return OP_ERR if the client violates StartTLS sequencing requirements (e.g., sending StartTLS while TLS is already established or while RAQMON traffic is in progress).
Vendors MUST use the BASIC part of the PDU to report pre-listed parameters for interoperability, rather than encoding them in application-specific extensions.
When SNMP is chosen as transport, RDSs MUST process SNMP INFORM responses from RRCs and MUST serialize the PDU transmission rate to meet congestion safety requirements from RFC 4710 Section 3.
The RAQMON Parameter Presence Flags (RPPF) is a 32-bit field in the BASIC part where each bit signals the presence of a specific parameter (bits 0–31 map to DA, RA, NTP Timestamp, Application Name, DN, RN, Session Setup Status, Session Duration, RTT, OWD, packet loss/discard counts, octets, ports, layer 2/3 priorities, payload types, CPU/memory utilization, delays, jitter, and fraction metrics).
The RAQMON PDU is functionally divided into a BASIC part (mandatory QoS metrics) and one or more APP parts (vendor/application-specific extensions). Both parts are preceded by an SMI Enterprise Code identifying the defining organization.
The RAQMON-RDS-MIB defines two notification types for the SNMP transport: raqmonDsStaticNotification (sent once per session with session-invariant parameters; MUST include raqmonDsAppName) and raqmonDsDynamicNotification (sent periodically with QoS metrics; MUST include raqmonDsTotalPacketsReceived). A third notification, raqmonDsByeNotification, is equivalent to the NULL PDU.
The StartTLS exchange uses two special PDU Report Types: TLS_REQ (sent by the RDS client to request TLS) and TLS_RESP (returned by the RRC), with seven defined result codes: OK (0), OP_ERR (1), PROTO_ERR (2), UNAVAIL (3), CONF_REQD (4), STRONG_AUTH_REQD (5), and REFERRAL (6).
TCP port 7744 is registered with IANA as the default port for RAQMON PDUs over TCP. The port was chosen above 5000 to avoid the range auto-assigned by Unix operating systems and the privileged range below 1024.
The RAQMON-RDS-MIB MODULE-IDENTITY (raqmonDsMIB) is assigned OID { rmon 32 } per RFC 3737. The MIB defines notification objects, a notification table, and compliance groups for SNMP-transport RAQMON.
Anonymous TLS establishes server authentication and confidentiality/replay protection but offers no protection against man-in-the-middle attacks during session establishment or spoofing by unauthorized clients; mutual certificate-based authentication is required when such threats are present.
Automated RAQMON clients SHOULD close the connection if the server's hostname does not match the dNSName in the certificate's subjectAltName, logging an error indicating the server identity is suspect.
RAQMON implementations MUST provide authentication (verifying report origin), data confidentiality, message integrity, and replay protection. TLS over TCP is the specified mechanism, providing these via its handshake and negotiated ciphersuite.
Data Source Address (DA) and Receiver Address (RA) are each 32 bits for IPv4 or 160 bits for IPv6; the S and R flag bits in the PDU header indicate which address family is used. All string fields (Application Name, Data Source Name, Receiver Name, Session Setup Status) start with an 8-bit length octet followed by UTF-8 text, padded to a 32-bit boundary.
Packet Loss in Fraction and Packet Discard in Fraction are each 8 bits expressed as a fixed-point number with the binary point at the left edge (i.e., the integer part of the fraction multiplied by 256, capped at 255). All integer fields use network byte order (big-endian); all header data is aligned to its natural length.
The APP part header consists of a 32-bit SMI Enterprise Code (non-zero for vendor extensions), a 16-bit Report Type, and a 16-bit Length field (in 32-bit words minus one). Application-dependent data follows and must be padded to a multiple of 32 bits.
The DSRC field is 32 bits and serves as a unique session descriptor. Values should be randomly generated; implementers are directed to the algorithm in RFC 3550 Appendix A.6. Zero is valid. The RRC should use DA, DN, and MAC Address in conjunction with DSRC to reduce collision probability.
The NTP Timestamp field is 64 bits: a full-resolution unsigned fixed-point number with the integer part (seconds) in the most significant 32 bits and the fractional part in the least significant 32 bits. A Data Source lacking NTP SHOULD set the corresponding RPPF bit to 0.
The RAQMON PDU header occupies the first 32 bits: PDT (5 bits, value=1 for current version), B (1 bit, BASIC part present), T (3 bits, count of APP extensions), P (1 bit, padding present), S (1 bit, source IPv6), R (1 bit, receiver IPv6), RC (4 bits, record count), Length (16 bits, BASIC part length in 32-bit words minus one).