| Internet-Draft | FANN Framework | October 2026 |
| Song, et al. | Expires 25 April 2027 | [Page] |
High-performance network applications, such as AI/ML distributed training/inference and large-scale cloud services, require rapid adaptation to link faults, signal degradation, and transient congestion. Existing dissemination mechanisms are often too slow or coarse to match the detection capabilities of modern forwarding hardware.¶
This document specifies a framework for Fast Network Notifications (FANN). It defines the reference architecture, functional roles, information model, delivery and scoping mechanisms, operational procedures, and integration principles with existing protocols to guide future protocol specifications.¶
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 25 April 2027.¶
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.¶
Modern high-performance networks, in particular data center (DC) and data center interconnect (DCI) fabrics serving AI/ML and cloud workloads, demand rapid adaptation to changing network conditions. A single fiber link failure, signal degradation, or transient congestion event can stall a distributed training job, waste compute and energy, and degrade service experience [I-D.ietf-fann-problem-statement].¶
Contemporary forwarding hardware can detect link failures, signal degradation reported as link errors, queue buildup, microbursts, and output-queue congestion at microsecond to sub-millisecond timescales. However, the time required to disseminate this information to the remote nodes that can act on it typically far exceeds the detection time. This gap between detection and reaction is the central problem that fast network notifications aim to address.¶
The Fast Network Notifications Problem Statement [I-D.ietf-fann-problem-statement] documents the need for a fast notification mechanism and the limitations of existing approaches. The companion requirements [I-D.geng-fantel-fantel-requirements] and gap analysis [I-D.geng-fantel-fantel-gap-analysis] documents elaborate on the requirements and the deficiencies of current technologies. Built on these documents, this document defines a framework to describe the overall architecture, the functional roles, the information carried, how notifications are delivered and scoped, and how the mechanism integrates with existing protocols and technologies across layers.¶
As [I-D.ietf-fann-problem-statement] notes, the IETF has previously examined path-coupled signaling and in-network feedback. The Next Steps in Signaling (NSIS) framework [RFC4080] defined a general architecture for signaling along the data path, and the difficulties it identified, namely signaling state management, scalability, and security, apply equally here. [RFC6077] (Section 3.1) identifies a related tension between signaling speed, scalability, and correctness that constrains any in-network notification mechanism. This framework treats those constraints as design inputs. It bounds scale through scoping, subscription, relay-side filtering and aggregation, and damping, and it confines notifications to a single administrative domain, concentrating enforcement at the boundary.¶
This informational document does not define any protocol, encoding, or YANG model. Those are expected to be specified in separate protocol and management documents that build on this framework.¶
This framework applies to limited-domain networks under a single administrative control. It prioritizes DC and DCI fabrics where rapid responsiveness is critical, while remaining applicable to provider backbones.¶
The framework initially targets notifications for link and node failures, signal degradation (e.g., link bit errors), and port queue congestion, remaining extensible to other conditions. Reaction logic (such as fast reroute, adaptive load balancing, or rate adjustment) is out of scope and managed by consuming subsystems.¶
In this document, "fast" implies delivery latency on the order of microseconds to milliseconds, determined by domain diameter and operational targets, which is substantially shorter than the RTT of the affected traffic.¶
This framework is solution-agnostic. It defines functional roles, information models, and scoping semantics without specifying encodings or protocol formats. Fast generation and consumption in the forwarding plane (ideally hardware) is the primary design point; control-plane or management-plane consumption is secondary and MUST NOT compromise routing stability.¶
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.¶
This document uses the following terms.¶
The terms BFD [RFC5880], ECN [RFC3168], FRR [RFC4090] [RFC5714], and IOAM [RFC9197] are used as defined in their respective references.¶
This chapter defines the core of the framework: its design principles, the functional reference architecture, the information carried in notifications, the models for delivering, scoping, discovering, and controlling notifications, and finally the deployment scenarios in which they are applied.¶
The framework is guided by the following principles, derived from the problem statement [I-D.ietf-fann-problem-statement] and requirements [I-D.geng-fantel-fantel-requirements].¶
The framework defines four functional roles. A single physical or virtual network element MAY implement more than one role.¶
+-------------------------------------------------+
| Notification Domain |
| |
| [Detect] [Distribute] [Act] |
| |
| +----------+ +-----------+ +-----------+ |
| |Originator|->| Relay |--->| Consumer | |
| | (detect/ | | (forward/ | | (receive/ | |
| | generate)| | filter/ | | action) | |
| +----+-----+ | damp) | +-----+-----+ |
| | +-----+-----+ | |
| | | | |
| v v v |
| ........................................ |
| : Notification Controller : |
| : (discovery / registration / policy / : |
| : global optimization) : |
| ........................................ |
+-------------------------------------------------+
A fast network notification proceeds through the following stages.¶
The mechanisms by which a node detects an event are out of scope of this framework, but the framework assumes their existence and depends on their characteristics. Two assumptions are important.¶
First, the E2E responsiveness of a fast notification system is bounded by detection time as well as delivery time: a notification cannot be faster than the moment the originating node becomes aware of the condition. Detection latency, accuracy, and false-positive behavior therefore directly shape what the notification system can achieve, and an event that is detected slowly or unreliably limits the value of fast delivery.¶
Second, detection itself has a cost that interacts with scaling. For example, achieving fast liveness detection by running BFD [RFC5880] at very short transmit intervals consumes forwarding and control resources. Driving detection intervals down to obtain faster detection can impose significant load, and this trade-off between detection speed and detection cost SHOULD be considered together with the notification load discussed in Section 4.4. Where hardware can detect a condition directly (for example loss of signal, FEC errors, or queue-occupancy thresholds), it is generally preferable to detection mechanisms that rely on periodic message exchange such as BFD. The distinction that matters is hardware versus protocol session, not polling versus event-driven. Hardware often polls internally too, but it does so far faster and at a fraction of the per-event cost of a protocol session pushed to an aggressive interval.¶
A fast network notification carries one or more information elements. For a given scenario some elements are mandatory and others optional; the framework does not require all elements in every notification. The detailed encoding is left to protocol specifications. The information elements are:¶
A consistent information model across implementations is necessary for interoperability; defining the normative model and encodings is a task for the protocol specification.¶
Depending on the position and number of consumers, the framework supports the following delivery modes. A scenario MAY use more than one.¶
Notifications MAY use existing messaging and transport mechanisms. Dedicated lightweight encodings MAY be defined where existing ones cannot meet the requirements. The transport mechanism MUST bound delivery latency and control traffic overhead.¶
To prevent delivery delay during network degradation, notification traffic SHOULD be able to be prioritized over regular data traffic. Prioritization SHOULD be enforced in hardware using existing mechanisms, such as:¶
Priority markings MUST be applied consistently within the domain. Operators MUST be able to configure markings, and notification priorities SHOULD be restricted to authorized traffic (Section 5). Notification volume MUST be rate-limited and damped (Section 3.6) to prevent control queue starvation.¶
Fast network notifications are confined to a notification domain under a single administrative control. Domain scoping bounds the propagation of notifications and defines the trust perimeter.¶
Domain isolation is primarily enforced at domain boundary nodes (such as edge relays or border routers), which MUST perform inbound and outbound filtering to prevent notification leaking unless explicitly authorized by policy.¶
An explicit domain identifier inside the notification message is OPTIONAL. Within a single administrative domain, domain boundaries MAY be defined implicitly based on interface binding, network topology, or hop/region limits (Section 3.6). Internal nodes trust notifications originating within the domain, avoiding per-packet domain verification in the forwarding plane.¶
To deliver notifications only to interested and authorized consumers, the framework supports procedures for discovery, registration, and subscription. These procedures MAY be deployed through static configuration or dynamic signaling.¶
These procedures MAY be realized by extending existing protocols or by introducing new protocol mechanisms defined in companion specifications.¶
Because relays forward notifications and consumers MAY act as relays, solutions MUST incorporate loop prevention, filtering, and damping mechanisms, drawing on established network design practices:¶
Fast network notifications apply across a range of network scenarios, but the time budget, processing constraints, and practical mechanisms differ substantially between them. Deployments select the delivery modes, scoping, and realization mechanisms appropriate to their specific topology and operational goals rather than applying a single fixed mechanism.¶
The functional roles (Section 3.2), information model (Section 3.3), and delivery modes (Section 3.4) are common across scenarios, but their realization and achievable latency vary. Where specific latency targets are referenced, they apply to the scenarios where they are physically and topologically feasible.¶
Each scenario below includes an illustrative figure showing a simplified topology, notification domain extent, and originator/consumer roles. In the figures, [O] denotes a notification originator, [C] a consumer, [R] a relay, and (X) marks the detected event. A scenario MAY use one or a combination of delivery modes (e.g., unicast, multicast, hop-by-hop, or scoped flooding).¶
Within a single DC fabric (for example, a Clos topology), originators and consumers are typically a small number of hops apart with minimal propagation delay. Forwarding hardware can both detect and consume notifications. This scenario demands sub-millisecond responsiveness to support local repair or adaptive load balancing. The primary scaling challenge is notification volume and rate of change rather than propagation distance.¶
.............................................................. : Notification Domain = the DC fabric : : : : +---------+ +---------+ +---------+ : : | Spine 1 | | Spine 2 | | Spine 3 | : : +----+----+ +----+----+ +----+----+ : : | | | : : | |(X)queue | : : | | congestion | : : +----+----+ +----+----+ +----+----+ : : | Leaf A | | Leaf B | | Leaf C | : : | [C] | <-- | [O] | --> | [C] | : : +---------+ +---------+ +---------+ : : notification delivery : :............................................................:
Between two sites or routers connected by a single logical hop, the recipient set is small and defined, targeting the upstream or ingress node. The time budget is dominated by fixed link propagation delay; the design goal is to minimize processing overhead so that the notification reaches the receiving node faster than the end-to-end traffic reaction loop.¶
.............................................................. : Notification Domain (single administrative control) : : : : Site A Site B : : +---------+ +---------+ : : | R1 |==== one (logical) hop =====| R2 | : : | [C] | | [O] (X) | : : +---------+ +---------+ : : ^ | : : +----------- notification -------------+ : : : :............................................................:
Data centers may be interconnected across multiple IP hops by a managed network. Unlike arbitrary WAN paths, this environment is highly engineered: traffic follows deterministic traffic-engineered (TE) paths, and network slicing isolates tenant workloads. Because paths and relevant ingress/upstream nodes are known, notifications can be delivered along the path and scoped per slice or tenant, enabling fine-grained control actions at path or tenant granularity.¶
.............................................................. : Notification Domain = managed DCI network : : : : +----+ +----+ +----+ +----+ +----+ : : | DC |----| R1 |------| R2 |------| R3 |----| DC | : : | A | |[C] | |[R] | |[O] | | B | : : +----+ +----+ +----+ +--+-+ +----+ : : ^ ^ |(X) : : | | | : : +---notif---+<--notif---+ : : : : TE path, one slice per tenant; action applied at tenant : : or path granularity, not only at the physical link : :............................................................:
Enterprise on-premises compute resources interact with remote data center capacity over a managed interconnect to run joint AI/ML workloads. Because the interconnect and compute sites are shared by multiple tenants and concurrent tasks, notifications must carry attribution information (tenants, tasks, flows) to allow differentiated reactions without breaking tenant isolation or violating service SLAs.¶
.............................................................. : Notification Domain = managed interconnect (one operator) : : : : Enterprise site shared Remote : : (on-prem compute) interconnect computing DC : : +-----------+ +----+ +----+ +-----------+ : : | tenant T1 | | | | | | tenant T1 | : : | tenant T2 |--| R1 |====~~~~====| R2 |--| tenant T2 | : : | task ... | |[C] | |[O] | | task ... | : : +-----------+ +----+ +--+-+ +-----------+ : : ^ |(x) queue buildup : : | | caused by T2 : : +--notification---+ : : : : The notification identifies T2, so [C] throttles only T2 : : and T1 keeps its committed share : :............................................................:
When notifications span arbitrary WAN paths across multiple hops, propagation delay, consumer counts, and the risk of notification storms increase. Time budgets are typically on the order of milliseconds. Subscriptions, relay filtering, aggregation, and bounded scoping become essential to control overhead.¶
.............................................................. : Notification Domain (bounded region of a wider WAN) : : : : +-----+ +-----+ : : | [C] | ... | [C] | : : +--^--+ +--^--+ : : | | : : +--+---------------------------+--+ : : | [R] filter / aggregate / damp | : : +--------------^------------------+ : : | : : notification : : | : : +---+----+ : : | [O](X) | : : +--------+ : :............................................................:
This chapter describes how the framework relates to existing technologies, the candidate mechanisms that could realize it, the applications it enables, and the scaling and operational considerations that apply when deploying it. It is informational and does not mandate any particular realization.¶
Fast network notifications complement existing network mechanisms across detection, dissemination, and consumption functions:¶
Topology and inventory models, such as [RFC8345], provide context for interpreting location and path identifiers across these functional components.¶
Multiple candidate mechanisms can realize fast network notifications. These approaches differ in latency, processing overhead, and implementation layer, and can be categorized as follows:¶
Notifications are conveyed via dedicated protocol messages operating at different protocol layers:¶
A deployment MAY combine multiple realization approaches depending on topological scope, hardware capabilities, and operational requirements.¶
This section sketches, non-normatively, applications that fast network notifications enable. The actions themselves are out of scope (Section 1.1); they illustrate what the information in Section 3.3 makes possible.¶
The solution must remain effective as the network grows. Scaling pressure arises from network size (the number of nodes and links that may report events), the volume and rate of change of reported information, the granularity at which state is reported (per tenant, task, or flow rather than per resource), and the number of consumers. The design assumption is that if anything can go wrong it will, so the system must cope with a high proportion of nodes and links reporting simultaneously.¶
The framework addresses scale through subscription (delivering only relevant information), scoping and domain isolation (bounding propagation), relay-based filtering and aggregation, damping of rapidly changing conditions, and transport prioritization and rate limiting. Protocol specifications SHOULD quantify the load their mechanisms place on the forwarding and control planes under worst-case event conditions.¶
Fast network notifications introduce additional traffic. During the failures and congestion events they report, the notification system MUST NOT exacerbate the situation and SHOULD actively assist in mitigating it. Operators SHOULD be able to configure which event types trigger notifications, the delivery modes and scopes used, damping and rate-limiting parameters, and prioritization, so that notification behavior aligns with network operation policies.¶
Management and configuration of the solution are expected to be supported by YANG modules, to be defined as a separate deliverable consistent with the charter. Manageability includes observability of the notification system itself (counts, drops, damping events) so operators can verify it is helping rather than harming.¶
Not every node in a domain will support fast network notifications at the same time, and the framework MUST NOT assume otherwise. An originator has to know which nodes can receive and process a notification before it sends one; that is what the discovery and registration procedures of Section 3.5 provide, which makes them an incremental-deployment tool as much as a steady-state one. Reachability is not the only issue. If some nodes on a path can react and others cannot, the actions taken along that path may not be consistent, and a notification relayed through a node that does not understand it may be dropped or, if carried transparently, may arrive without the filtering or aggregation a capable relay would have applied. A solution SHOULD therefore state how it behaves when capability is missing along a path, and operators SHOULD check whether a partially deployed domain delivers the intended benefit. Multi-vendor interoperation rests on a common information model and encoding (Section 3.3).¶
This framework does not define specific numerical thresholds, as acceptable latency and overhead depend on the target deployment scenario (Section 3.7). However, solution specifications SHOULD evaluate their design against a consistent set of measurable performance metrics:¶
Future solution specifications SHOULD specify testing topologies, traffic profiles, and measurement methodologies appropriate for their intended operational environment.¶
If not properly authenticated and rate-limited, fast network notifications could be a denial-of-service vector: an attacker that injects or floods spurious notifications could trigger unnecessary re-convergence, path changes, or repeated state updates, and could induce state flapping to keep an originator busy. Notifications may also reveal sensitive operational information, whether by inspection or by an adversary registering as a consumer.¶
Accordingly, solutions built on this framework MUST provide integrity protection and origin authentication of notifications, MUST apply rate controls on both sending and receiving, and MUST address trust boundaries around domains and subscriptions, authorization of notification sources, and protection of sensitive operational data. Because stronger security can add latency, the trade-off between notification latency and security strength is considered per scenario. Domain identification and isolation (Section 3.4) are central to confining notifications to the trusted administrative boundary.¶
Notifications that carry tenant or task identifiers, or that report per-tenant or per-task state (Section 3.3), are especially sensitive in the multi-tenant deployment of Section 3.7.4. They can expose one tenant's workload structure, traffic volume, and activity pattern to another. Authorization for subscription and delivery MUST therefore be evaluated per tenant, and a consumer MUST NOT receive notifications describing tenants it is not authorized for. A tenant may also be able to influence how many notifications are generated, deliberately or simply through the events its traffic causes. That can degrade the service other tenants receive, or provoke control actions against them, so rate limiting and damping SHOULD be applied per tenant as well as per originator.¶
The charter's restriction to a single administrative control reduces the threat surface but does not eliminate it. The operator controls every originator, relay, and consumer, and the trust boundary coincides with the notification domain (Section 3.4). The boundary can therefore drop notifications arriving from outside it, which constrains external injection and spoofing. Exposure of operational data to third parties is likewise bounded, and discovery, registration, and subscription can reuse the trust infrastructure already present inside the domain. The design can then stay lightweight and low-latency internally while concentrating enforcement at the boundary.¶
None of this removes the need for protection inside the domain. Insider threats, compromised or malfunctioning nodes, and the self-inflicted denial of service of a flapping link all start inside the boundary. The requirements above still apply there. Single administrative control is defense in depth, not a substitute for them.¶
This document requires no IANA actions.¶