A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics
draft-praveen-fann-lq-telemetry-udp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | S. Praveen K. Pasalapudi , Vishnu Pavan Beeram | ||
| Last updated | 2026-07-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-praveen-fann-lq-telemetry-udp-00
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,
<https://datatracker.ietf.org/doc/html/draft-praveen-fann-
lq-telemetry-info-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-zzhang-rtgwg-
router-info-06>.
[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,
<https://www.rfc-editor.org/rfc/rfc768>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/rfc/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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,
<https://www.rfc-editor.org/rfc/rfc5082>.
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,
<https://www.rfc-editor.org/rfc/rfc5771>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
8.2. Informative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/rfc/rfc5880>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/rfc/rfc6935>.
[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,
<https://www.rfc-editor.org/rfc/rfc6936>.
[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,
<https://www.rfc-editor.org/rfc/rfc8900>.
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]