Per-Entry Soft-State Refresh Horizon and Paced Fragmentation Scheduling for Fast Network Notification (FANN) Telemetry

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 3 May 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

Link-quality advertisements can contain several records and can be split across packets. A receiver that refreshes every record when any packet from a helper arrives can retain an omitted record indefinitely. This document specifies a per-record receipt-aging profile for the Link Quality Telemetry model [LQ-INFO] and its UDP binding [LQ-UDP]. It also specifies that partial triggered advertisements must not postpone the sender's periodic coverage of other records.¶

The profile is a focused proposed amendment to those individual drafts. It does not define a new notification packet, metric, transport, congestion-control algorithm, or forwarding policy. [ROUTER-INFO] already discusses per-neighbor and per-link refresh and aging. The contribution here is to make the aging unit, sender scheduling, and composition with nested LQ records explicit. The preferred progression is joint integration into the base documents, not parallel standardization of the same mechanism.¶

The failure scenario follows from partial refresh and loss semantics; it is not presented as a measured production incident. The FANN problem statement [FANN-PROBLEM] establishes the wider notification problem, but does not constitute working-group adoption of this particular profile. The current framework [FANN-FRAMEWORK] remains work in progress.¶

2. Record Identity and Local State

For the native LQ model the receiver keys a record by the tuple (administrative receive scope, sender AS qualifier, sender node ID, remote AS qualifier, remote node ID, link ID). Zero AS qualifiers retain the unqualified semantics of [LQ-INFO]; the administrative receive scope MUST keep otherwise ambiguous identifiers separate. Interface indices or node IDs from unrelated scopes MUST NOT alias the same state entry.¶

Each admitted record stores its value, monotonic accepted-receipt time, expiry deadline, and validity state. Validity is absent, fresh, or stale. Stale means that this profile no longer permits use of the retained quality observation. It does not by itself mean that the physical link is down, healthy, or has zero capacity.¶

Sender heartbeat state and per-record validity are separate. An accepted packet for record B can establish that the sender is responsive while record A expires. A heartbeat failure can invalidate all records from that sender according to the base mechanism, but heartbeat success MUST NOT refresh an omitted record. Topology validity remains an independent condition.¶

3. Configuration and Deployment Agreement

The operator configures an upper bound R on the interval between completed emissions that explicitly refresh each advertised record. R is expressed in integer milliseconds and MUST be positive. The receiver uses a positive integer miss multiplier M and computes L = M * R using checked arithmetic. L is the local receipt lifetime. An implementation MUST reject a configuration whose product is not representable in its timer system or whose scheduling precision cannot enforce it.¶

R is a per-record coverage budget, not necessarily the nominal packet timer. If the periodic scheduler has a maximum gap of ceil(1.1 * T) and a full emission cycle takes at most E milliseconds, a conservative choice is R = ceil(1.1 * T) + E. E includes serialization, batching, and scheduler delays for the entire advertised record set. An implementation MUST NOT set E to zero merely because each individual packet is small.¶

The sender and receiver MUST be provisioned consistently for this profile. There is no in-band negotiation in this version. Enabling only the receiver provides conservative expiry but does not ensure that the sender refreshes records frequently enough; enabling only the sender does not correct receiver aging. A mixed deployment requires explicit operational compatibility assessment. The packet format is unchanged, but the profile intentionally changes behavior relative to the timer-reset rule in [LQ-INFO] and [LQ-UDP].¶

When L is reduced, existing deadlines MUST be shortened to no later than accepted-receipt-time + new-L. Increasing L MUST NOT extend an existing record's deadline; the longer value applies after a new accepted explicit update. Changes of administrative scope, sender identity mapping, or topology mapping MUST invalidate affected entries until valid updates are admitted under the new mapping.¶

4. Sender Procedure

While a record is advertised as current, the sender MUST schedule explicit refreshes so that the interval between completed emissions for that record does not exceed R under the declared operating envelope. Periodic coverage includes unchanged records. Triggered advertisements can contain a subset, but MUST NOT reset or postpone the periodic coverage deadlines of omitted records.¶

Splitting a full refresh across packets does not make the packet group atomic. The sender follows the base binding's sequence-number rules and advances the packet sequence as required. Every packet contains self-contained records. The sender MUST budget for the entire group when claiming R and MUST account for the maximum record count and link serialization rate.¶

The sender MUST NOT present a stale local measurement as newly sampled merely by periodically transmitting it. Existing measurement-validity procedures remain applicable. This profile does not add an observation-age field, so a receiver cannot derive such age solely from successful refreshes. If local sampling is unavailable, the sender MUST stop refreshing the affected observation, or use an unavailable indication only if the selected base binding explicitly defines one. It MUST NOT manufacture a healthy score. Stopping refresh permits the receiver's deadline to expire; it does not signal an immediate physical link failure.¶

If overload prevents compliance with R, the sender SHOULD expose a local alarm and reduce the advertised set or renegotiate configuration through management. It MUST NOT silently advertise that the guarantee still holds. The receiver still expires entries according to L; thus overload can reduce usable telemetry without extending stale use.¶

When a link-quality record first becomes eligible for periodic advertisement, its first completed explicit emission MUST occur no later than R after that eligibility event under the declared operating envelope. Initial coverage and subsequent periodic sweeps share the same per-record refresh bound. An event-triggered emission satisfies the refreshed record's own deadline but MUST NOT postpone the emission deadline of any omitted link record.¶

5. Receiver Procedure

The receiver MUST validate packet framing, source and scope checks, configured security protections, and the base sequence rule before any timer renewal. A rejected, duplicate, or stale packet renews neither a record timer nor a sender heartbeat in this profile. Serial comparisons use the bit width and procedures of the base binding and [RFC1982]; the exactly-half-range case is not a newer value.¶

This profile retains the base per-sender packet ordering. For example, if packet 102 containing B arrives before packet 101 containing A, the base rule can reject packet 101. The receiver MUST NOT treat receipt of B as recovery of A. A subsequently accepted explicit refresh can restore A. This profile does not change to per-record serial numbers or claim to repair all reordering losses.¶

For an otherwise admissible packet, the receiver validates every record and rejects the packet if it contains duplicate composite keys or structurally invalid records. No timer is partially updated before this validation completes. Optional fields continue to follow the base binding's rules. An unsupported record type MUST NOT be interpreted as a refresh of a previously known type.¶

For every valid, admitted record K explicitly present, the receiver applies the following operation. The time is the local monotonic time at successful admission, not an untrusted sender timestamp.¶

on_admit(K, value, now):
    state[K].value = value
    state[K].last = now
    state[K].deadline = checked_add(now, L)
    state[K].validity = fresh

usable(K, now):
    return (state[K].validity == fresh
            and now < state[K].deadline
            and topology_allows(K)
            and parent_carriage_allows(K))

At now equal to the deadline, the record is not usable. Periodic cleanup may run later, but the forwarding consumer MUST test the deadline or an equivalent hardware validity mechanism before using the observation. A timer implementation with bounded error must conservatively account for that error; delayed housekeeping MUST NOT create extra usable lifetime.¶

Entries absent from the packet are unchanged. Their deadlines MUST NOT be extended. Expiry marks an entry stale and prevents its quality value from affecting forwarding. The consumer then uses its configured base-protocol fallback, such as topology-only forwarding, withdrawing the affected optimization, or another independently validated source. This document does not mandate a new fallback that contradicts the base protocol's eligibility rule.¶

Receiver restart or loss of validity state makes all affected observations unusable until renewed. Reset of a sender's sequence state follows the base binding's recovery rule and its security limitations. A heartbeat timeout is not proof of a fresh authenticated incarnation. Deployments that cannot exclude delayed or replayed traffic across that reset MUST NOT claim measurement freshness from this profile. Adding a boot epoch would require a separate wire-format agreement.¶

Any installed path weight or derived forwarding state that depends on a link-quality record MUST NOT remain eligible for traffic steering beyond the earliest applicable input record expiry, topology invalidation, or enclosing node-record expiry. An implementation MUST either propagate that conservative expiration timestamp into the derived forwarding table entry or atomically invalidate the derived entry at the exact expiry boundary, even if background telemetry table garbage collection has not yet executed.¶

6. Router-Info Carriage

When LQ records are carried inside Router-Info, the validity checks compose. A record is usable only while its own LQ deadline, the applicable enclosing Router-Info record lifetime, and topology conditions all permit it. Expiry of the enclosing information invalidates its dependent observations. Receipt of an unrelated Router-Info TLV, a different neighbor, or another nested link record MUST NOT extend an LQ record's lifetime.¶

The base Router-Info refresh-rate rules remain applicable to their own record types, including the treatment of one-time notifications. This profile MUST NOT create an indefinite lifetime for periodic LQ records by selecting a zero refresh value. A deployment with no finite agreed LQ coverage bound cannot enable this profile for those records.¶

Because [ROUTER-INFO] already has per-record aging, the normative work needed there may be only a clarification of composition with the nested LQ TLV. A new parallel timer or packet type is not required when existing implementation state can express the same deadlines.¶

7. Worked Trace and Interoperability Cases

Assume T = 20 ms, maximum jittered gap 22 ms, E = 1 ms, R = 23 ms, and M = 3. Then L = 69 ms. At t = 0, A and B are admitted. Updates containing only B are admitted at t = 20 and t = 40. At t = 69, A is unusable even though the sender heartbeat remains healthy. B's deadline is t = 109. A is usable again only after an explicit accepted update, for example at t = 75, establishing a new deadline at t = 144.¶

This trace is an arithmetic example, not a measured hardware result. Loss of every packet carrying A can keep A stale indefinitely. A full sender refresh schedule creates transmission opportunities; it cannot promise successful delivery in R milliseconds.¶

An interoperability suite MUST cover omitted records, duplicate packets, duplicate keys, packet reordering, exact deadline boundaries, sequence wrap and half-range ambiguity, sender restart, changed scope, reduced and increased lifetime configuration, nested outer expiry, receiver resource exhaustion, and sustained loss. Expected outcomes should be compared at the usability interface, not only by inspecting whether entries remain allocated.¶

Interoperability verification MUST additionally test the initial-emission deadline bound R and verify that derived forwarding weights cease influencing packet selection at the exact nanosecond a constituent link record expires, prior to asynchronous background record purge.¶

8. YANG Data Model Augmentation for FANN Per-Record Aging

To ensure interoperable configuration and operational monitoring of the per-record receipt-aging profile across Fast Network Notification (FANN) senders and receivers, this section defines the YANG 1.1 [RFC7950] module ietf-fann-soft-state-refresh, which augments the Link Quality Telemetry model [LQ-INFO], uses the common data types of [RFC9911], and conforms to NMDA [RFC8342] and the YANG module guidance in [RFC9907].¶

<CODE BEGINS> file "ietf-fann-soft-state-refresh@2026-10-30.yang"
module ietf-fann-soft-state-refresh {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-fann-soft-state-refresh";
  prefix fann-ssr;

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 9911: Common YANG Data Types";
  }

  organization
    "IETF Fast Network Notifications (FANN) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/fann/>
     WG List:  <mailto:fann@ietf.org>
     Author:   Zhiqiang Li
               <mailto:lizhiqiangyjy@chinamobile.com>";
  description
    "This module defines configuration and operational state
     parameters for per-record receipt aging and bounded refresh
     scheduling in Fast Network Notification (FANN) Link-Quality
     Telemetry.

     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see the
     RFC itself for full legal notices.";

  revision 2026-10-30 {
    description
      "Initial version specifying per-record receipt aging
       parameters including multi-packet fragmentation emission
       margin (E).";
    reference
      "RFC XXXX: Per-Record Receipt Aging and Bounded Refresh
       Scheduling for Fast Network Notification (FANN)
       Link-Quality Telemetry";
  }

  container fann-soft-state-refresh {
    description
      "Per-record receipt aging configuration and operational
       telemetry.";
    leaf record-expire-ms {
      type uint32 {
        range "1..3600000";
      }
      units "milliseconds";
      default "1000";
      description
        "Receiver per-record expiration interval (T_expire).";
    }
    leaf safety-margin-ms {
      type uint32;
      units "milliseconds";
      default "200";
      description
        "Configured transit, jitter, and loss safety margin (M).";
    }
    leaf fragment-spacing-ms {
      type uint32;
      units "milliseconds";
      default "10";
      description
        "Maximum inter-fragment emission spacing (T_spacing).";
    }
    leaf max-fragments-per-sweep {
      type uint16 {
        range "1..1024";
      }
      default "1";
      description
        "Maximum fragments (F) required to emit a full link-record
         sweep.";
    }
    leaf refresh-interval-ms {
      type uint32 {
        range "1..3600000";
      }
      units "milliseconds";
      must ". + ../safety-margin-ms + "
         + "((../max-fragments-per-sweep - 1) * "
         + "../fragment-spacing-ms) <= ../record-expire-ms" {
        error-message
          "T_refresh + M + (F - 1) * T_spacing MUST NOT exceed "
        + "T_expire.";
      }
      default "500";
      description
        "Bounded full-sweep refresh interval (T_refresh).";
    }
    leaf expired-record-purges {
      type yang:counter64;
      config false;
      description
        "Total number of link-quality records transitioned to
         Expired because T_now - T_rx_last >= T_expire.";
    }
  }
}
<CODE ENDS>

9. Security and Operational Considerations

Per-record deadlines prevent unrelated accepted traffic from extending a record's local receipt lifetime. They do not authenticate telemetry. Source-address checks and a hop-limit check restrict scope but are not cryptographic authentication. The deployment MUST apply the base binding's security requirements and assess whether its link protection and operational trust suffice for the proposed use.¶

An on-link attacker able to inject accepted packets can create misleading records or advance serial state. Per-record aging does not solve that attack. Integrity protection, authorization of sender identities and scope, and protection against replay are required where that threat is in scope. This document adds no authentication field and MUST NOT claim to provide such protection by itself.¶

Receivers MUST bound admitted senders and records. A record that cannot be stored MUST NOT be represented as fresh. Resource eviction invalidates the affected observation; it MUST NOT transfer its deadline to another key. Operators SHOULD monitor per-record expiry, heartbeat failure, sequence rejection, capacity rejection, and coverage-budget violations separately.¶

Frequent expiry can cause forwarding changes, so implementations need a stable fallback and appropriate policy damping. Any adaptation must respect the data transport's ordering assumptions; this profile does not authorize arbitrary packet spraying for RoCE traffic. Hardware timer capacity and update rate must be measured under the maximum advertised record set.¶

10. IANA Considerations

This document requests no IANA allocation. It changes no codepoint, YANG namespace, packet header, or registry. Its intended progression is integration of the specified behavior into the relevant base documents, subject to their editors and the FANN working group. It does not claim to update an existing RFC.¶

11. Implementation Status and Integration Plan

No conforming hardware implementation or independent interoperability result is claimed. The FANN charter [FANN-CHARTER] includes hardware-forwarding and interoperability requirements before protocol publication. Model-level trace checks cannot satisfy those requirements.¶

The proposed integration points are the per-entry last-seen and heartbeat procedures in Sections 6.2 and 6.5 of [LQ-INFO], its transmission procedure in Section 7.2, and the triggered/periodic interaction in Section 4.5 of [LQ-UDP]. Router-Info composition should be reviewed with its per-neighbor/link aging text and the LQ carriage rules. The exact section numbers are tied to the cited -00 revisions.¶

Before adoption, the base editors should confirm whether current senders can omit unchanged records, whether complete periodic coverage is already intended, how reset and replay are handled, and whether the receiver's existing per-entry timestamp is already used for expiry. If an updated base draft specifies equivalent behavior, this proposal should be merged or retired instead of remaining a duplicate document.¶

Authors' Addresses