Fast Network Notifications S. P. K. Pasalapudi Internet-Draft V. P. Beeram Intended status: Standards Track Hewlett Packard Enterprise Expires: 21 January 2027 20 July 2026 A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics draft-praveen-fann-lq-telemetry-udp-00 Abstract This document specifies a UDP transport binding for the Link Quality Telemetry data model. The binding disseminates YANG-modeled link quality data between directly connected switches in multi-stage CLOS (leaf-spine) data center fabrics using a compact, fixed-offset binary encoding designed for forwarding-plane (ASIC) generation and consumption, achieving sub-100 microsecond notification latency on forwarding engines capable of data-plane UDP processing. The encoded payload can be carried natively on a dedicated UDP port or as a TLV within the Router-Info advertisement mechanism; both carriages share a byte-identical payload. The data model, receiver processing rules, and requirements applicable to all transport bindings are defined in a companion document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Pasalapudi & Beeram Expires 21 January 2027 [Page 1] Internet-Draft LQ Telemetry UDP July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. UDP Transport Binding . . . . . . . . . . . . . . . . . . . . 4 4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Hardware-Accelerated Processing . . . . . . . . . . . . . 4 4.3. Compact Binary Encoding . . . . . . . . . . . . . . . . . 6 4.4. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1. UDP LQ Version Header (4 octets) . . . . . . . . . . 9 4.4.2. UDP LQ Header (12 octets; 16 octets when Q=1) . . . . 9 4.4.3. UDP Link Quality Record (16 octets, or 20 octets when Q=1, repeated N times) . . . . . . . . . . . . . . . 10 4.4.4. UDP Diagnostic Record (8 octets, repeated N times, optional) . . . . . . . . . . . . . . . . . . . . . . 11 4.4.5. Complete UDP Payload Layout . . . . . . . . . . . . . 12 4.5. Transmission Procedures . . . . . . . . . . . . . . . . . 14 4.6. Addressing and Scoping . . . . . . . . . . . . . . . . . 14 4.7. Congestion and Loss Considerations . . . . . . . . . . . 14 4.8. ECMP Entropy . . . . . . . . . . . . . . . . . . . . . . 15 5. Carriage within Router-Info . . . . . . . . . . . . . . . . . 15 5.1. LQ Telemetry TLV . . . . . . . . . . . . . . . . . . . . 16 5.2. Carriage Rules . . . . . . . . . . . . . . . . . . . . . 17 5.3. Refresh Rate and Heartbeat Reconciliation . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.1. IPv6 Multicast Address . . . . . . . . . . . . . . . . . 18 6.2. IPv4 Multicast Address . . . . . . . . . . . . . . . . . 18 6.3. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Router-Info TLV Type . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Pasalapudi & Beeram Expires 21 January 2027 [Page 2] Internet-Draft LQ Telemetry UDP July 2026 1. Introduction The Link Quality Telemetry data model [I-D.praveen-fann-lq-telemetry-info] defines a vendor-agnostic YANG representation of per-link congestion state -- a 256-level Link Quality Score (LQS), an 8-level Congestion Level (CL), and available bandwidth -- giving load-balancing nodes next-next-hop (NNH) path quality visibility in CLOS fabrics. The model is deliberately transport-neutral. This document defines one concrete transport binding for that model: a lightweight UDP encapsulation for link-local, high-frequency advertisement between directly connected switches. The binding is optimized for hardware generation and consumption in the forwarding plane, in line with the FANN charter's emphasis on notifications that are generated and consumed in the forwarding plane, ideally in hardware. This document specifies one payload encoding and two carriages for it. The native carriage (Section 4) places the payload directly in a UDP datagram on a dedicated port. The Router-Info carriage (Section 5) places the byte-identical payload in a TLV within the Router-Info advertisement mechanism [I-D.zzhang-rtgwg-router-info], gaining that mechanism's authentication and refresh-rate negotiation. An implementation supports either or both carriages with a single payload encoder and parser. The binding satisfies the transport requirements (serialization, periodic and triggered signaling, and link-local scoping) stated in [I-D.praveen-fann-lq-telemetry-info]. Field semantics, receiver processing (path quality table maintenance, weighted ECMP computation, heartbeat-based failure detection), the congestion detection pipeline, and configuration parameters (such as T_notify and CHANGE_THRESHOLD) are defined in that document and are not repeated here. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Pasalapudi & Beeram Expires 21 January 2027 [Page 3] Internet-Draft LQ Telemetry UDP July 2026 3. Terminology This document uses the terminology defined in [I-D.praveen-fann-lq-telemetry-info], including Helper Node, Load- Balancer Node, Node Identifier (a 4-octet Router-ID), AS Qualifier, LQS, and CL. In addition: AS-Qualified (Q) Flag: A flag in this binding's LQ Header. When set, AS Numbers (a sender AS in the header and a remote AS per record) are carried on the wire; when clear, only Router-IDs are carried and AS Qualifiers are treated as 0. 4. UDP Transport Binding 4.1. Rationale UDP provides source-port entropy for LAG hashing, dedicated IANA port for firewall rules, and straightforward ASIC parser integration. This binding is most suitable for greenfield fabrics where all devices support the same protocol and maximum forwarding-plane performance is required. On forwarding engines capable of processing UDP payloads directly in the data plane without CPU intervention, this binding achieves sub-100 microsecond notification latency. 4.2. Hardware-Accelerated Processing Modern data center forwarding engines are capable of parsing and acting on UDP packets entirely within the forwarding pipeline, without punting to the routing engine or line-card CPU. When a forwarding engine supports this capability, the following illustrative processing model applies. The normative receiver behavior -- path quality table maintenance, weighted ECMP computation, and receiver damping -- is defined in [I-D.praveen-fann-lq-telemetry-info] and governs where this illustration and that document differ: 1. The LQ UDP packet arrives at the leaf's ingress port and enters the normal forwarding pipeline. 2. The forwarding engine classifies the packet by destination port (TBD5) and identifies it as an LQ Telemetry message. Pasalapudi & Beeram Expires 21 January 2027 [Page 4] Internet-Draft LQ Telemetry UDP July 2026 3. The compact binary payload is parsed in the forwarding pipeline. The fixed-position field layout (Section 4.3) is designed for this purpose: after a single read of the Flags octet (which fixes the header size HLEN and record size RLEN for the whole packet via the Q flag), all fields are at deterministic offsets, requiring no variable-length parsing or conditional branching. 4. For each LQ record in the payload, the forwarding engine extracts the remote-node-id, link-id, LQS, CL, and available-bandwidth fields, plus the remote-as field when Q=1 (treated as 0 when Q=0). 5. The extracted LQS values are written to a hardware path quality table indexed by (spine_as, spine_node_id, remote_leaf_as, remote_leaf_id, link_id), co-located with or cross-referenced to the ECMP group membership table in forwarding memory. 6. The ECMP next-hop weights or membership are updated atomically based on the new LQS values: * LQS = 0 for a path: the corresponding next-hop is assigned weight 0 (equivalent to a hardware veto), unless all paths in the group are 0, in which case the receiver falls back to equal weights per the weighted ECMP computation of [I-D.praveen-fann-lq-telemetry-info]. Applying this transition immediately is permitted by the path failure/ recovery exception in the receiver damping rules of that document. * LQS > 0: the next-hop weight is moved toward the target weight computed per the weighted ECMP computation of [I-D.praveen-fann-lq-telemetry-info], subject to the receiver damping rules (reweighting interval T_reweight and damping gain g) defined there. 7. The LQ packet is consumed (not forwarded). This processing model achieves end-to-end notification latency (from spine link-state change to leaf ECMP update) bounded by: T_total = T_detect + T_generate + T_propagate + T_process where: Pasalapudi & Beeram Expires 21 January 2027 [Page 5] Internet-Draft LQ Telemetry UDP July 2026 * T_detect: Time for the spine to detect the link quality change. Bounded by T_sample (RECOMMENDED 2 ms; see the congestion detection pipeline of [I-D.praveen-fann-lq-telemetry-info]) for gradual congestion, or sub-microsecond for hard link failures detected by the PHY. * T_generate: Time for the spine to construct and transmit the LQ packet. On hardware-accelerated implementations, this is bounded by the packet serialization time (sub-microsecond for a ~100 byte frame at 400G). * T_propagate: Wire propagation delay. Negligible within a data center (~5 ns/m). * T_process: Time for the leaf's forwarding engine to parse the LQ packet and update the ECMP table. On hardware-accelerated implementations, this is bounded by the forwarding pipeline depth (sub-microsecond to low microseconds). For hard link failures where T_detect is sub-microsecond, the total notification latency T_total is dominated by T_generate + T_process, which is in the low microsecond range on hardware-accelerated forwarding engines, without requiring a dedicated Layer 2 notification protocol. For congestion events where T_detect is bounded by T_sample, the total latency is dominated by the sampling interval. The RECOMMENDED T_sample of 2 ms (the congestion detection pipeline of [I-D.praveen-fann-lq-telemetry-info]) yields a worst-case notification latency of approximately 2-4 ms for congestion, which is appropriate for the graduated quality-aware traffic steering use case. Implementations that do not support forwarding-plane UDP processing MAY process LQ packets on the line-card CPU or routing engine. In this case, the processing latency is in the millisecond range. The protocol semantics and packet format are identical regardless of the processing model. 4.3. Compact Binary Encoding This binding serializes instances of the lq-advertisement YANG data structure defined in [I-D.praveen-fann-lq-telemetry-info] into fixed- position binary fields designed for efficient ASIC parsing. All multi-octet fields are in network byte order. Each node of the structure maps to a wire field as follows: Pasalapudi & Beeram Expires 21 January 2027 [Page 6] Internet-Draft LQ Telemetry UDP July 2026 +========================+==========================================+ | Structure Node | Wire Encoding | +========================+==========================================+ | node-id | 4 octets (uint32) | +------------------------+------------------------------------------+ | node-as | 4 octets (uint32); present only when Q=1 | +------------------------+------------------------------------------+ | sequence-number | 2 octets (uint16) | +------------------------+------------------------------------------+ | timestamp-ms | 4 octets (uint32) | +------------------------+------------------------------------------+ | pfc-fabric | P flag (1 bit) | +------------------------+------------------------------------------+ | signaling-mode | S flag (1 bit); see below | +------------------------+------------------------------------------+ | remote-node-id | 4 octets (uint32) | +------------------------+------------------------------------------+ | remote-as | 4 octets (uint32); present only when Q=1 | +------------------------+------------------------------------------+ | link-id | 4 octets (uint32) | +------------------------+------------------------------------------+ | available-bandwidth | 4 octets (IEEE 754 [IEEE754] binary32) | +------------------------+------------------------------------------+ | lqs | 1 octet (uint8) | +------------------------+------------------------------------------+ | cl | 3 bits; record octet 13, bits 0-2 | +------------------------+------------------------------------------+ | diagnostics | D flag (1 bit); see below | | (presence) | | +------------------------+------------------------------------------+ | link-capacity | 4 octets (IEEE 754 binary32) | +------------------------+------------------------------------------+ | queue-depth | 1 octet (uint8) | +------------------------+------------------------------------------+ | ecn-marking-rate | 5 bits; see the Diagnostic Record | +------------------------+------------------------------------------+ | pfc-pause-fraction | 5 bits; see the Diagnostic Record | +------------------------+------------------------------------------+ | drops-active | 1 bit (X); see the Diagnostic Record | +------------------------+------------------------------------------+ Table 1 The Version, Flags, Num Records, and Reserved fields are framing defined by this binding only; they do not correspond to nodes of the lq-advertisement structure (the number of entries is conveyed by the structure's link-quality list itself, and diagnostics presence by the per-entry presence container). Pasalapudi & Beeram Expires 21 January 2027 [Page 7] Internet-Draft LQ Telemetry UDP July 2026 Value-space conversions: available-bandwidth and link-capacity: The structure models these as decimal64 with three fraction digits; the wire carries IEEE 754 binary32. A sender rounds the decimal64 value to the nearest representable binary32 value on encoding; a receiver rounds the decoded value to three fraction digits, per the "bandwidth-gbps" typedef of [I-D.praveen-fann-lq-telemetry-info]. signaling-mode: S=0 maps to "periodic" and S=1 to "triggered". The "solicited" value is not representable in this binding, which operates in unsolicited (push) mode only. diagnostics: The structure permits per-entry diagnostics presence; the D flag is per-packet. When diagnostics are enabled, a sender MUST include a Diagnostic Record for every Link Quality Record in the packet (D=1) or for none (D=0). A receiver populates the diagnostics presence container for every entry of a packet received with D=1. The AS Number fields (node-as, remote-as) are 4-octet values carried on the wire only when the AS-Qualified (Q) flag is set in the LQ Header. When Q=0 they are absent and the receiver populates the corresponding structure nodes with 0 (unqualified), per the as- qualifier semantics of [I-D.praveen-fann-lq-telemetry-info]. The Q setting is uniform for all records in a packet, so record size is fixed within a packet and determined by a single flag read. 4.4. Packet Format The UDP payload uses self-contained framing: a 4-octet version header, an LQ header, N Link Quality Records, and optionally N Diagnostic Records (8 octets each). Header and Link Quality Record sizes depend on the AS-Qualified (Q) flag: * Q=0 (Router-ID only): LQ Header is 12 octets, each LQ Record is 16 octets. * Q=1 (AS-qualified): the LQ Header is 16 octets (a 4-octet Sender AS Number is appended) and each LQ Record is 20 octets (a 4-octet Remote AS Number is appended). Q is uniform across all records in a packet. All fields named Reserved, and all reserved flag bits, MUST be set to zero on transmission and MUST be ignored on receipt. A receiver MUST discard packets whose Version field is not 1 and SHOULD count such discards. Pasalapudi & Beeram Expires 21 January 2027 [Page 8] Internet-Draft LQ Telemetry UDP July 2026 IPv6/IPv4 Header: Source: Spine interface address (link-local). Destination: ff02::TBD2 (IPv6) or 224.0.0.TBD4 (IPv4). Hop Limit/ TTL: 255. DSCP: CS6. UDP Header: Source Port: Randomized per-packet (entropy for LAG/ ECMP). Destination Port: TBD5 (to be assigned by IANA). 4.4.1. UDP LQ Version Header (4 octets) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (1) | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: 1 (this specification). Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |H| +-+-+-+-+-+-+-+-+ H: 0 = software-processed, 1 = hardware-accelerated (informational; indicates sender supports forwarding-plane processing per Section 4.2). 4.4.2. UDP LQ Header (12 octets; 16 octets when Q=1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Num Records | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (ms since boot) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender AS Number (present only when Q=1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sender AS Number (octets 12-15) is present only when the Q flag is set; otherwise the LQ Header is 12 octets and the receiver treats the sender AS as 0. Flags: Pasalapudi & Beeram Expires 21 January 2027 [Page 9] Internet-Draft LQ Telemetry UDP July 2026 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R|R|R|R|Q|S|D|P| +-+-+-+-+-+-+-+-+ Bit 0 is the most significant bit. Bits 0-3 are Reserved. Q (bit 4): 0 = node identity is the 4-octet Router-ID only (AS qualifiers are 0); 1 = AS-qualified: a 4-octet Sender AS Number is present in the LQ Header and a 4-octet Remote AS Number is present in each Link Quality Record. A sender sets Q per the "as- qualified" configuration leaf, which MUST be configured consistently on all nodes of a fabric ([I-D.praveen-fann-lq-telemetry-info]). A receiver that is not configured or not capable of AS-qualified operation MUST discard packets with Q=1 (it cannot parse the larger records reliably), MUST count such discards, and SHOULD log them; because sustained discards cause the heartbeat mechanism of [I-D.praveen-fann-lq-telemetry-info] to declare the sending neighbor failed, an inconsistent "as-qualified" setting is an operationally visible misconfiguration rather than a silent one. A receiver configured for AS-qualified operation processes a received Q=0 packet normally, keying its entries with AS Qualifier 0; the fabric-wide consistency requirement makes this a transient condition during reconfiguration. S (bit 5): 0 = periodic, 1 = change-triggered. Maps to the signaling-mode node of the lq-advertisement structure (Section 4.3). D (bit 6): 0 = no diagnostics, 1 = Diagnostic Records follow the Link Quality Records. P (bit 7): 0 = lossy fabric, 1 = PFC-enabled. Maps to the pfc- fabric node of the lq-advertisement structure. 4.4.3. UDP Link Quality Record (16 octets, or 20 octets when Q=1, repeated N times) Pasalapudi & Beeram Expires 21 January 2027 [Page 10] Internet-Draft LQ Telemetry UDP July 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Node Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth (IEEE 754) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LQS | CL | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote AS Number (present only when Q=1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LQS is octet 12 of the record. CL occupies bits 0-2 (the three most significant bits) of octet 13; bits 3-7 of octet 13 and octets 14-15 are Reserved. The Remote AS Number (octets 16-19) is appended to the base 16-octet record only when Q=1, making the record 20 octets and keeping 4-octet alignment. When Q=0 the record is 16 octets and the receiver treats the remote AS as 0. The (Remote AS Number, Remote Node Identifier) pair is the globally unique identity of the far-end node, per the node identity semantics of [I-D.praveen-fann-lq-telemetry-info]. 4.4.4. UDP Diagnostic Record (8 octets, repeated N times, optional) Present only when D flag = 1 in the LQ Header. N Diagnostic Records follow immediately after the N Link Quality Records. The i-th Diagnostic Record corresponds positionally to the i-th Link Quality Record. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Capacity (IEEE 754) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Depth |Rsvd | ECN Rate|Rsvd | PFC Frac|X| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field positions within the second word (octets 4-7): * Queue Depth: octet 4. * ECN Marking Rate (0-31): octet 5, low-order 5 bits (bits 3-7); bits 0-2 Reserved. Pasalapudi & Beeram Expires 21 January 2027 [Page 11] Internet-Draft LQ Telemetry UDP July 2026 * PFC Pause Fraction (0-31): octet 6, low-order 5 bits (bits 3-7); bits 0-2 Reserved. * X (drops-active): octet 7, bit 0 (most significant); bits 1-7 Reserved. Right-aligning each 5-bit value within its own octet allows extraction with a single byte read and a 0x1F mask, with no fields straddling octet boundaries. 4.4.5. Complete UDP Payload Layout When D = 0 (no diagnostics), shown for Q=0 (for Q=1 the LQ Header is 16 octets and each LQ Record is 20 octets, shifting the offsets accordingly): +---------------------------+ offset 0 | Version Header (4 octets) | +---------------------------+ offset 4 | LQ Header (12 octets) | +---------------------------+ offset 16 | LQ Record 1 (16 octets) | +---------------------------+ offset 32 | LQ Record 2 (16 octets) | +---------------------------+ | ... | +---------------------------+ offset 16 + 16(N-1) | LQ Record N (16 octets) | +---------------------------+ offset 16 + 16N Total (Q=0): 16 + 16N octets (UDP payload); with UDP header: 24 + 16N. Total (Q=1): 20 + 20N octets (UDP payload); with UDP header: 28 + 20N. (The version header is 4 octets and the LQ header is 12 octets for Q=0 or 16 for Q=1; records start at offset 4 + LQ-header- size.) When D = 1 (diagnostics present), shown for Q=0: Pasalapudi & Beeram Expires 21 January 2027 [Page 12] Internet-Draft LQ Telemetry UDP July 2026 +---------------------------+ offset 0 | Version Header (4 octets) | +---------------------------+ offset 4 | LQ Header (12 octets) | +---------------------------+ offset 16 | LQ Record 1 (16 octets) | +---------------------------+ | ... | +---------------------------+ offset 16 + 16(N-1) | LQ Record N (16 octets) | +---------------------------+ offset 16 + 16N | Diag Record 1 (8 octets) | <- matches LQ Record 1 +---------------------------+ | ... | +---------------------------+ offset 16 + 16N + 8(N-1) | Diag Record N (8 octets) | +---------------------------+ offset 16 + 24N Total (Q=0): 16 + 24N octets (UDP payload); with UDP header: 24 + 24N. Total (Q=1): 20 + 28N octets (UDP payload); with UDP header: 28 + 28N. Example sizes (N=4 links, typical spine; including UDP header): * Router-ID only (Q=0), without diagnostics: 24 + 64 = 88 octets * Router-ID only (Q=0), with diagnostics: 24 + 96 = 120 octets * AS-qualified (Q=1), without diagnostics: 28 + 80 = 108 octets * AS-qualified (Q=1), with diagnostics: 28 + 112 = 140 octets All fields are at deterministic offsets. The receiver reads the Flags (including Q) and Num Records (N) from the LQ Header to determine record size and count. LQ Records start at fixed offset 4 + HLEN, where HLEN is the LQ header size (12 when Q=0, 16 when Q=1); each record is RLEN octets (16 when Q=0, 20 when Q=1). When D = 1, Diagnostic Records start at offset 4 + HLEN + RLEN*N. Both HLEN and RLEN are fixed for the whole packet once the single Flags octet is read, so no variable-length parsing or TLV walking is required, preserving forwarding-plane ASIC processing per Section 4.2. Pasalapudi & Beeram Expires 21 January 2027 [Page 13] Internet-Draft LQ Telemetry UDP July 2026 4.5. Transmission Procedures A helper transmits periodic and triggered advertisements per the signaling requirements of [I-D.praveen-fann-lq-telemetry-info]. To desynchronize helper nodes, each periodic transmission MUST be jittered uniformly within [0.9 * T_notify, 1.1 * T_notify], as recommended by that document; a triggered advertisement resets the periodic timer. An LQ packet MUST fit within the link MTU without IP fragmentation; fragmentation of a forwarding-plane-parsed control packet defeats hardware processing and is fragile in operational networks [RFC8900]. A helper with more link quality entries than fit within the MTU MUST split them across multiple packets. Each packet is self-contained: it carries its own Version Header, LQ Header, and sequence number (sequence numbers are consumed one per packet, not per advertisement burst), and receivers process each packet independently. Entries for a given (remote-as, remote-node-id, link-id) key MUST NOT be split across packets. 4.6. Addressing and Scoping This section applies to the native carriage; addressing and scoping for the Router-Info carriage are governed by the Router-Info envelope (Section 5). Link-Local Mode: Multicast: ff02::TBD2 (IPv6) or 224.0.0.TBD4 (IPv4). Hop Limit = 255 with GTSM [RFC5082] validation. Unicast: MAY be used for point-to-point advertisement to a specific neighbor's interface address. 4.7. Congestion and Loss Considerations This section addresses the applicability of the UDP usage guidelines [RFC8085] to this binding. Pasalapudi & Beeram Expires 21 January 2027 [Page 14] Internet-Draft LQ Telemetry UDP July 2026 The binding's traffic is strictly bounded and confined: advertisements are link-local (one hop, Section 4.6), each sender transmits at most one advertisement burst per triggered event and otherwise at the jittered periodic rate, with T_notify no smaller than 10 ms ([I-D.praveen-fann-lq-telemetry-info]), and packets are small (Section 4.3). Traffic does not traverse congested Internet paths, does not react to loss by retransmitting, and cannot form feedback loops with itself: loss of an LQ packet reduces, rather than increases, subsequent traffic influence. The circuit-breaker guidance of [RFC8085] is satisfied structurally by the one-hop scope and the fixed upper bound on transmission rate. The binding provides no reliable delivery, by design: the periodic advertisement is the repair mechanism for lost triggered advertisements, bounding the staleness of receiver state to approximately one T_notify interval per loss, and the heartbeat mechanism of [I-D.praveen-fann-lq-telemetry-info] bounds the effect of sustained loss. UDP checksums [RFC0768] MUST be computed by senders and validated by receivers. Over IPv6, the UDP checksum MUST NOT be zero [RFC8200]; the zero-checksum exemptions of [RFC6935] [RFC6936] do NOT apply to this binding, because a corrupted LQ payload directly programs forwarding hardware and no upper-layer integrity check exists. 4.8. ECMP Entropy The UDP binding randomizes the source port for each transmitted packet, providing entropy for ECMP and LAG hashing. This ensures that LQ packets probe different physical paths in a Link Aggregation Group. 5. Carriage within Router-Info The LQ payload MAY be carried as a TLV within the Router-Info advertisement mechanism [I-D.zzhang-rtgwg-router-info], instead of or in addition to the native carriage of Section 4. This carriage gains the Router-Info envelope's optional authentication and refresh-rate negotiation while preserving the fixed-offset payload properties of this binding. In the data model of [I-D.praveen-fann-lq-telemetry-info], the native carriage is identified by the "lq-transport-udp" identity and this carriage by the "lq-transport-udp-router-info" identity derived from it, allowing the two carriages to be enabled (through the "active- transports" leaf-list) and observed (through the per-neighbor "transport" leaf) independently. Pasalapudi & Beeram Expires 21 January 2027 [Page 15] Internet-Draft LQ Telemetry UDP July 2026 5.1. LQ Telemetry TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD6 | Length |S| Refresh Rate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value: complete UDP LQ payload, byte-identical to the ~ | native carriage (Version Header, LQ Header, Link | | Quality Records, and Diagnostic Records if D=1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD6, allocated from the Router-Info TLV type registry (Section 6.4). Length: Length of the Value in octets. Following the Router-Info TLV convention, the Value begins with the one-octet S/Refresh Rate field, so Length equals 1 plus the LQ payload size: 17 + 16N for Q=0, D=0; 17 + 24N for Q=0, D=1; 21 + 20N for Q=1, D=0; and 21 + 28N for Q=1, D=1 (per the payload layout of Section 4). A receiver MUST verify that Length is consistent with the payload's own framing (Q, D, and Num Records) and MUST discard the TLV on mismatch. S / Refresh Rate: Per the Router-Info TLV convention. A sender MUST set the Refresh Rate to T_notify with the S bit clear (rate in milliseconds); the 7-bit rate field (0-127) covers the full T_notify range of 10-100 ms defined by [I-D.praveen-fann-lq-telemetry-info]. Value: The complete UDP LQ payload of Section 4, without modification. Carrying the payload verbatim -- including the Version Header -- means an implementation uses a single payload encoder and parser for both carriages, the payload format can be versioned independently of the Router-Info envelope, and the two carriages cannot drift. The Type, Length, and S/Refresh Rate fields together occupy 4 octets, so all payload fields remain at deterministic offsets and a hardware parser processes this carriage with the same extraction logic at a fixed base-offset shift. Note that the Router-Info fixed header of [I-D.zzhang-rtgwg-router-info] (2 octets of version and flags followed by the 4-octet Source Router ID and 4-octet Link ID, when no authentication block is present) is 10 octets, so payload fields are not 32-bit aligned relative to the start of the Router-Info message; parsers that require word alignment need to account for the 2-octet skew. Pasalapudi & Beeram Expires 21 January 2027 [Page 16] Internet-Draft LQ Telemetry UDP July 2026 5.2. Carriage Rules A Router-Info packet MUST NOT contain more than one LQ Telemetry TLV (the payload already aggregates all of a helper's entries). When hardware parsing of this TLV is desired, senders SHOULD place it as the first TLV in the packet so its offset is deterministic; note that the presence of the variable-length Router-Info authentication block, which precedes the TLVs, shifts TLV offsets, so deployments combining hardware parsing with authentication SHOULD restrict themselves to a single, fixed-length authentication type. A receiver MUST verify that the Source Router ID of the Router-Info header equals the Node Identifier in the LQ Header, and MUST discard the TLV on mismatch; this check turns the field duplication into an integrity cross-check. Addressing, scoping, TTL/Hop Limit handling, and the UDP port are those of the Router-Info envelope, restricted as follows: the LQ Telemetry TLV MUST be sent only in Router-Info's local-link mode (link/node-local destination) and MUST NOT be included in Router-Info messages flooded to remote receivers; a receiver MUST ignore an LQ Telemetry TLV received in a remote-flooded Router-Info message. So restricted, the envelope satisfies the one-hop confinement requirement of [I-D.praveen-fann-lq-telemetry-info]. The transmission procedures of Section 4.5 (jitter, MTU fit without fragmentation, splitting, self-contained packets) apply to the resulting Router-Info packet. The congestion and loss properties of Section 4.7 apply equally to this carriage. 5.3. Refresh Rate and Heartbeat Reconciliation The Router-Info envelope allows a receiver to request a slower Refresh Rate through a Notification TLV, and obliges the sender to honor the largest rate requested by any receiver ([I-D.zzhang-rtgwg-router-info]). Left unconstrained, this would let the effective advertisement interval for the LQ Telemetry TLV exceed T_notify, causing the heartbeat-based failure detection of [I-D.praveen-fann-lq-telemetry-info] (miss_count times T_notify) to declare a healthy neighbor failed. This binding reconciles the two mechanisms as follows. A sender MUST set the Refresh Rate field of the LQ Telemetry TLV to the interval at which it actually advertises that TLV. A sender that adjusts the rate, whether on its own or in response to a Notification TLV, MUST update the Refresh Rate field to the new value in the same advertisement in which the new rate takes effect. Pasalapudi & Beeram Expires 21 January 2027 [Page 17] Internet-Draft LQ Telemetry UDP July 2026 A receiver MUST derive its heartbeat interval for a neighbor from the Refresh Rate most recently advertised by that neighbor rather than from its own configured T_notify, declaring the neighbor failed after miss_count times the advertised Refresh Rate. Because Router-Info ages the TLV at three times the Refresh Rate, this makes the two timers agree by construction at the default miss_count of 3, rather than by coincidence of default values, and keeps failure detection correct across rate renegotiation. A receiver that requires failure detection no slower than its own configured miss_count times T_notify MUST NOT request a Refresh Rate slower than T_notify for this TLV. A receiver that cannot keep up at the sender's rate faces a trade-off between processing load and detection time; this is an operational decision, and the resulting detection time is always observable from the advertised Refresh Rate. The heartbeat mechanism of [I-D.praveen-fann-lq-telemetry-info] governs forwarding state in both carriages. In the native carriage no rate negotiation exists, so the advertised interval is T_notify and the derivation above reduces to miss_count times T_notify. 6. IANA Considerations 6.1. IPv6 Multicast Address IANA is requested to assign one link-local scope IPv6 multicast address, ff02::TBD2 ("LQ Advertisement Nodes"), from the "IPv6 Multicast Address Space Registry", Link-Local Scope Multicast Addresses registry, with this document as the reference. 6.2. IPv4 Multicast Address IANA is requested to assign one IPv4 multicast address, 224.0.0.TBD4 ("LQ Advertisement Nodes"), from the "IPv4 Multicast Address Space Registry", Local Network Control Block (224.0.0.0/24) [RFC5771], with this document as the reference. 6.3. UDP Port From "Service Name and Transport Protocol Port Number Registry": Pasalapudi & Beeram Expires 21 January 2027 [Page 18] Internet-Draft LQ Telemetry UDP July 2026 +=============+========================+ | Field | Value | +=============+========================+ | Port | TBD5 | +-------------+------------------------+ | Name | lq-telemetry | +-------------+------------------------+ | Protocol | UDP | +-------------+------------------------+ | Description | Link Quality Telemetry | +-------------+------------------------+ | Reference | [this document] | +-------------+------------------------+ Table 2 6.4. Router-Info TLV Type IANA is requested to allocate one TLV type (TBD6, "LQ Telemetry") from the Router-Info TLV type registry defined by [I-D.zzhang-rtgwg-router-info], following that registry's registration policy, with this document as the reference. The YANG module is registered by [I-D.praveen-fann-lq-telemetry-info]. 7. Security Considerations LQ Telemetry advertisements influence forwarding decisions at receiving nodes. A malicious or malfunctioning sender could cause traffic mis-steering by advertising falsified quality data. This binding limits the attack surface to directly connected neighbors: advertisements are sent with TTL/Hop Limit = 255 and validated on receipt with GTSM [RFC5082] as specified in Section 4.6. A receiver MUST additionally verify that the destination address is the assigned LQ multicast group or one of its own interface addresses, and, for IPv6, that the source address is link-local; packets failing these checks MUST be discarded. Implementations SHOULD rate-limit the processing of LQ messages to mitigate the risk of localized UDP flooding attacks. The Router-Info carriage (Section 5) inherits the optional authentication of the Router-Info envelope [I-D.zzhang-rtgwg-router-info], which SHOULD be used where message authentication is required and the offset considerations of Section 5 are acceptable; the Source Router ID cross-check of that section additionally binds the payload to the envelope's authenticated sender identity. Pasalapudi & Beeram Expires 21 January 2027 [Page 19] Internet-Draft LQ Telemetry UDP July 2026 The native carriage defines no message authentication mechanism. IPsec is, in practice, incompatible with the forwarding-plane processing objective of this binding (Section 4.2): an ASIC that parses fixed-offset payloads cannot terminate IPsec. Deployments that require cryptographic protection on fabric links SHOULD use MACsec [IEEE8021AE], which provides line-rate, hop-by-hop integrity and confidentiality below IP and is compatible with forwarding-plane processing of the LQ payload. A future version of this binding may define an optional authentication extension carrying a keyed MAC at a fixed offset, analogous to BFD authentication (Section 6.7 of [RFC5880]); such an extension is deliberately not specified here. Within a single administrative domain on point-to-point switch-to- switch links -- the intended deployment -- GTSM plus the address validation above confines forgery to an attacker with physical or administrative access to a fabric link. Receivers MUST validate the Sequence Number in the LQ Header to detect replay, comparing sequence numbers using serial number arithmetic [RFC1982] with SERIAL_BITS = 16 as specified in [I-D.praveen-fann-lq-telemetry-info]: a packet is accepted if its sequence number is greater than the last accepted sequence number from that sender. An on-link attacker who can inject packets can advance the expected sequence number and cause legitimate packets to be rejected as replays; this is bounded by the heartbeat mechanism of [I-D.praveen-fann-lq-telemetry-info] -- a receiver MUST reset its expected sequence state for a neighbor when that neighbor's heartbeat state transitions to failed, restoring processing of legitimate packets within miss_count * T_notify -- and eliminated by link-layer authentication such as MACsec. Receivers MUST also enforce the heartbeat-based failure detection defined in [I-D.praveen-fann-lq-telemetry-info] to prevent stale data from influencing forwarding. A forged Sender AS Number or Remote AS Number could cause a receiver to key a quality entry under the wrong node identity, either masking a real condition or creating a spurious entry. This is a sub-case of the falsified-data threat above and is bounded by the same link-local scoping and authentication measures; it adds no new trust boundary, since the Q flag and AS fields are covered by whatever integrity mechanism protects the rest of the payload. Receivers SHOULD treat an AS Number that is not consistent with the local fabric's AS plan as an error and discard the record. Model-level security considerations are discussed in [I-D.praveen-fann-lq-telemetry-info]. 8. References Pasalapudi & Beeram Expires 21 January 2027 [Page 20] Internet-Draft LQ Telemetry UDP July 2026 8.1. Normative References [I-D.praveen-fann-lq-telemetry-info] Pasalapudi, S. P. K. and V. P. Beeram, "A YANG Data Model for Link Quality Telemetry in CLOS Data Center Fabrics", Work in Progress, Internet-Draft, draft-praveen-fann-lq- telemetry-info-00, July 2026, . [I-D.zzhang-rtgwg-router-info] Zhang, Z. J., Wang, K., Lin, C., Vaidya, N., Tantsura, J., and Y. Liu, "Advertising Router Information", Work in Progress, Internet-Draft, draft-zzhang-rtgwg-router-info- 06, 23 February 2026, . [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, 2019. [IEEE8021AE] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE 802.1AE-2018, 2018. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, . Pasalapudi & Beeram Expires 21 January 2027 [Page 21] Internet-Draft LQ Telemetry UDP July 2026 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 8.2. Informative References [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, . Acknowledgments The authors thank the IETF RTGWG community for discussion of the adaptive routing problem space that motivated this work. Contributors Kaliraj Vairavakkalai Hewlett Packard Enterprise Pasalapudi & Beeram Expires 21 January 2027 [Page 22] Internet-Draft LQ Telemetry UDP July 2026 Email: kaliraj.vairavakkalai@hpe.com Swamy SRK Hewlett Packard Enterprise Email: swamy.sadashivaiah-renu-kananda@hpe.com Authors' Addresses S. Praveen K. Pasalapudi Hewlett Packard Enterprise Email: praveenp@hpe.com Vishnu Pavan Beeram Hewlett Packard Enterprise Email: vishnu-pavan-kumar.beeram@hpe.com Pasalapudi & Beeram Expires 21 January 2027 [Page 23]