A Framework for Fast Network Notifications

Introduction 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 . 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 documents the need for a fast notification mechanism and the limitations of existing approaches. The companion requirements and 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 notes, the IETF has previously examined path-coupled signaling and in-network feedback. The Next Steps in Signaling (NSIS) framework 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. (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.

Scope 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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms.

Fast Network Notification (FANN):: An event-driven mechanism that conveys a locally detected adverse network condition, or the recovery from such a condition, to one or more remote nodes within a defined notification domain, with the objective of low-latency delivery suitable for actions in the forwarding plane.
Notification Originator:: A functional role that detects an adverse condition (or its recovery) and generates a fast network notification. Also referred to as the originating or reporting node.
Notification Consumer:: A functional role that receives a fast network notification and may take action based on it. Also referred to as the recipient node.
Notification Relay:: A functional role that forwards or redistributes a notification toward additional consumers, optionally applying filtering, damping, or aggregation. A node may be both a relay and a consumer.
Notification Domain:: A bounded region of the network, under a single administrative control, within which fast network notifications are generated, distributed, and consumed, and outside of which they are not propagated without explicit policy.
Notification Controller:: An optional control-plane or management-plane entity that assists with discovery, registration, subscription, policy, and global optimization. It is not required to be on the fast notification delivery path.
Event:: A change in network condition detected by a node, such as a link failure, signal degradation, or output-queue congestion. The recovery from a previously reported condition is also considered as an event.
Tenant:: An administratively distinguished user of a shared network and/or computing infrastructure, to which resources are allocated and for which isolation from other such users is expected. A tenant may be realized by a network slice, a VPN, an overlay, or another administrative construct; this document does not assume a particular realization.
Task:: A unit of work belonging to a tenant, such as a distributed training job, a fine-tuning run, or an inference service, whose traffic can be distinguished from that of other tasks of the same tenant. A task typically comprises many flows.

The terms BFD , ECN , FRR , and IOAM are used as defined in their respective references.

Fast Network Notification Framework 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.

Design Principles and Goals The framework is guided by the following principles, derived from the problem statement and requirements .

Event-driven, not periodic:: Notifications are generated in response to detected events. This distinguishes fast network notifications from preconfigured periodic mechanisms such as BFD , which detect rather than disseminate.
Forwarding-plane optimized:: The primary design point is fast generation and consumption in the forwarding plane, ideally in hardware, to meet responsiveness targets. Consumption by the control plane and management plane is a secondary objective and MUST NOT compromise routing stability.
Lightweight and bounded:: Notification messages are compact and the system is designed to bound the load it places on the network, especially during the very events it reports. The notification system MUST NOT exacerbate a failure or congestion event.
Action-agnostic:: A notification message conveys information, it does not mandate a specific reaction. A notification MAY explicitly indicate a recommended action, or the action MAY be determined implicitly by the consumer from the information carried.
Extensible:: The information model and event taxonomy are extensible to additional conditions, metrics, and scopes without redefining the architecture. Extensibility also constrains the protocol design: the notification message encoding SHOULD allow new information elements, event types, and optional fields to be added in a forward-compatible way, and a receiver MUST skip any element it does not understand instead of discarding the whole notification. New information can then be added over time without breaking existing implementations or forcing a new protocol version.
Complementary:: Fast network notifications complement, and do not replace, existing OAM, control-plane, and telemetry mechanisms. They bridge the time gap between event onset and slower control-plane or telemetry-driven responses.
Scoped and isolated:: Notifications are confined to a notification domain. Domain identification and isolation are first-class concerns.
Decoupled from routing convergence:: Fast-changing network state SHOULD be conveyed by mechanisms that are separate from the routing protocol database and their own flooding and best-path computation, so that high-frequency or transient events do not introduce churn, instability, or excessive recomputation in the routing control plane. Notifications can then be generated and refreshed quickly, independently of routing convergence. Any consumption by routing remains a secondary objective and is still bound by the stability constraint above.

Reference Architecture

Functional Roles The framework defines four functional roles. A single physical or virtual network element MAY implement more than one role.

Notification Originator:: Detects an event using local detection mechanisms (for example link fault detection, error counters, queue occupancy thresholds, or BFD as a detection input) and generates a notification. The originator determines, by policy or signaling, the set of consumers and the delivery mode, and applies originator-side controls such as damping and rate limiting.
Notification Relay:: Receives a notification and forwards it toward additional consumers. A relay MAY filter, aggregate, deduplicate, or damp notifications. Relays enable hop-by-hop and scoped-flooding delivery and allow load to be bounded inside the domain.
Notification Consumer:: Receives a notification and may act on it in the data plane (for example rate adjusting, ECMP rebalancing, flow steering, or traffic pause), and/or pass the information to the control plane or management plane. A consumer MAY also be a relay. Most consumers are forwarding elements: nodes next to the event, nodes several hops upstream, domain ingress nodes, or a controller. End hosts and edge nodes MAY also be consumers, as notes, for instance to adapt a sending rate or pick a different uplink; a host consumer lies inside the notification domain and registers, subscribes, and is authorized like any other (). Hosts are numerous, so admitting them affects both scale () and the size of the trust boundary (), and a deployment SHOULD weigh this before admitting them. A host-side reaction may also overlap with transport congestion control ().
Notification Controller:: An optional entity that supports discovery, registration, subscription, and policy distribution, and that may consume notifications for global traffic-engineering or load-balancing optimization. The controller is not required to be on the fast delivery path and SHOULD NOT be a single point of failure for forwarding-plane reactions.

Notification Lifecycle A fast network notification proceeds through the following stages.

Detection. A node observes an event at the forwarding plane using a local detection mechanism. Detection mechanisms are out of scope of this framework, but their output is the trigger for notification generation.
Generation. The originator constructs a notification populated from the information model (), subject to origination policy, damping, and rate limiting.
Delivery. The notification is delivered to the intended consumers using one of the delivery modes (), possibly via one or more relays.
Consumption. A consumer parses the notification and decides whether and how to act, based on the information carried and on any local state it holds.
Action. The consumer performs an action (out of scope of this framework) and may relay the notification further.
Recovery and withdrawal. When the condition clears, the originator may generate a recovery notification so consumers can revert or update their state. Recovery is itself an event (), so the stages above apply to it without change. How the originator notices that the condition has cleared is outside the scope of this framework, as is the action the consumer then takes; the notification itself is built from the same information model () and follows the same delivery policy as any other.

Detection Assumptions and Constraints 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 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 . 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.

Information Model 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:

Event Type:: The class of event, for example failure, signal degradation, congestion, or performance degradation, and whether the notification reports onset or recovery. The event taxonomy is extensible.
Location of Event:: An identifier of where the event occurred, for example a link, node, interface, or queue identifier. Location identifiers SHOULD be interpretable by consumers within the notification domain.
Network Status:: Quantifiable metrics such as link utilization, available bandwidth, link capacity, queue length, level of congestion, link or node delay, jitter, and packet loss. Conveying such quantitative metrics, rather than a binary up/down indication, enables graduated and proportional responses such as weighted load-sharing adjustments. Protocol specifications MUST define the exact quantization, resolution, sampling interval, and normalization semantics (e.g., absolute value vs. percentage of capacity) for these metrics to ensure consistent interpretation across heterogeneous nodes. This element corresponds to the "Fine-grained Network Status information" of . The "Fine-grained Event and State" element below carries the same kinds of metrics, but broken down by tenant, task, or flow instead of totalled over the resource.
Path Identification:: Identification of the path affected by the event, allowing consumers to scope their reaction to specific paths.
Flow/Service Identification:: Identification of an affected flow (for example a 5-tuple) or service, allowing differentiated, per-flow or per-service responses.
Tenant/Task Identification:: Identification of the tenant/task whose traffic is affected by, or is contributing to, the reported condition. A tenant or task identifier MAY be carried explicitly, or MAY be derived from an existing construct such as a network slice identifier, a VPN or overlay identifier, a VLAN or tunnel identifier, or a path or segment identifier bound to the tenant.
Fine-grained Event and State:: A notification MAY report a condition at fine granularity so that it can be attributed and acted on selectively. The Network Status element above gives a figure for the resource as a whole; this element breaks that figure down by tenant, task, flow, path, or queue: how much of a congested queue a given task occupies, say, or how far a tenant's current rate sits above its committed share. The granularity SHOULD be negotiable or configurable.
Timing and Validity:: Optional event timestamp and a validity or hold time after which the reported condition should be considered stale in the absence of refresh or recovery.
Action Hint:: An optional explicit indication of a recommended action. When absent, the consumer determines the action implicitly from the other elements.
Origin and Sequence:: Originator identity, which may be represented by the source IP address of the notification, and an optional sequence or epoch indicator. The sequence or epoch supports ordering, deduplication, and loop detection at relays and consumers; it is RECOMMENDED where notifications may be relayed, flooded, or reordered, and MAY be omitted in simple cases such as single-hop unicast delivery where such protection is unnecessary.

A consistent information model across implementations is necessary for interoperability; defining the normative model and encodings is a task for the protocol specification.

Delivery and Scoping

Delivery Modes Depending on the position and number of consumers, the framework supports the following delivery modes. A scenario MAY use more than one.

Unicast:: Direct delivery to a single consumer. Suitable when the originator knows the specific node that must react (for example a designated ingress or upstream node).
Multicast / Point-to-Multipoint:: Delivery to a selected group of consumers, for example along a service or forwarding path. Suitable when a defined set of nodes must react together.
Hop-by-hop:: Delivery along a series of nodes on a specified path, with each node acting as a relay and possibly a consumer. Suitable for propagating awareness upstream along an affected path.
Scoped Flooding:: Dissemination to all nodes within a bounded region of the domain. Suitable for critical events with many interested consumers, with special attention to control overhead and duplicate suppression.

Transport Considerations 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:

DiffServ marking (e.g., dedicated DSCP mapped to Expedited Forwarding );
Strict-priority or dedicated control queues separated from user data traffic;
Layer 2 priority markings (e.g., IEEE 802.1p/PCP) across bridged segments.

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 (). Notification volume MUST be rate-limited and damped () to prevent control queue starvation.

Notification Domain and Isolation 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 (). Internal nodes trust notifications originating within the domain, avoiding per-packet domain verification in the forwarding plane.

Discovery, Registration, and Subscription 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.

Discovery:: Nodes determine the identity, functional roles, and capabilities (e.g., supported event types, encodings, and delivery modes) of peers and relays in the domain. Discovery MAY use existing distributed or centralized signaling.
Registration:: A node registers its capabilities as an originator, relay, or consumer, establishing necessary addressing (e.g., IP addresses, segment IDs, or multicast groups) and trust parameters. Nodes implementing multiple roles (e.g., both relay and consumer) MAY register these roles concurrently while maintaining explicit, separate policy contexts for each.
Subscription:: A consumer specifies the events, locations, paths, flows, tenants, tasks, or metric thresholds it wishes to receive, as well as the required reporting granularity (). Subscriptions are dynamic, and MAY be created, updated, or canceled at runtime. Originators and relays apply subscription filters to discard non-matching notifications before transmission, bounding traffic volume. Subscriptions MAY be managed by a controller or negotiated directly between nodes.

These procedures MAY be realized by extending existing protocols or by introducing new protocol mechanisms defined in companion specifications.

Loop Prevention, Filtering, and Damping 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:

Loop prevention:: Uses origin identifiers, sequence or epoch numbers, hop/region bounds, and duplicate suppression to prevent indefinite packet circulation. Concepts from loop-free convergence frameworks (e.g., ) apply here.
Filtering and aggregation:: Relays suppress notifications irrelevant to downstream peers and aggregate related events to control message volume. This leverages subscription-based filtering mechanisms similar to those in .
Damping:: Suppresses rapid notification oscillation caused by unstable conditions (e.g., link flapping). Damping MAY occur at the originator, transit relays, or the consumer. A typical policy reports degradation immediately but delays recovery notifications for a hold-down interval. This is the same penalty-and-decay idea used in BGP Route Flap Damping .

Deployment Scenarios 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 (), information model (), and delivery modes () 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).

Intra-Data-Center Fabric 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.

Intra-Data-Center Fabric: In-Fabric Notification Dissemination | [C] | : : +---------+ +---------+ +---------+ : : notification delivery : :............................................................: ]]>

Single-Hop DCI / Point-to-Point WAN 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.

Single-Hop DCI: Delivery to Upstream Node

Multi-Hop Managed DCI Interconnect 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.

Multi-Hop Managed DCI: Delivery Along a Known TE Path

Edge-Cloud Collaborative Training and Inference 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.

Edge-Cloud Collaboration: Per-Tenant Attribution on a Shared Interconnect

Multi-Hop / Arbitrary WAN Paths 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.

Arbitrary WAN Paths: Subscription and Relay Filtering

Realization and Operational Considerations 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.

Integration with Existing Technologies Fast network notifications complement existing network mechanisms across detection, dissemination, and consumption functions:

Detection Mechanisms (Originator Inputs):: Physical alarms, FEC error counters, and interface error statistics provide immediate hardware-level fault and degradation inputs. BFD provides bidirectional liveness detection to trigger notifications. Measurement tools such as IOAM , Alternate Marking , and IPFIX provide continuous telemetry data. FANN MAY use these mechanisms as event triggers; it does not replace them.
Dissemination Mechanisms:: Notifications complement traditional control-plane flooding (e.g., IGP/BGP) and path-coupled signaling (e.g., ECN ). Unlike control-plane flooding that introduces routing recomputation churn, or single-bit ECN signals that operate over an end-to-end RTT, FANN provides low-latency, event-driven dissemination directly in the forwarding plane without triggering control-plane instability.
Consumer and Reaction Mechanisms:: Received notifications feed into existing reaction mechanisms, including Layer 2 link protection, Layer 3 Fast Reroute (FRR) , and remote path protection schemes. Because network-side reactions run concurrently with endpoint transport loops (e.g., TCP, QUIC, ROCE), network actions SHOULD preserve packet ordering and avoid abrupt capacity shifts. End-to-end congestion marks (e.g., ECN bits) MUST NOT be cleared or rewritten without policy authorization.

Topology and inventory models, such as , provide context for interpreting location and path identifiers across these functional components.

Candidate Realization Approaches Multiple candidate mechanisms can realize fast network notifications. These approaches differ in latency, processing overhead, and implementation layer, and can be categorized as follows:

Extensions to Control and Routing Protocols:

Existing control-plane protocols (e.g., IGP or BGP extensions) can be extended to carry notification state. While this reuses deployed control-plane infrastructure, it MUST be weighed against control-plane stability, CPU processing overhead, and routing convergence churn, making it better suited for slower-changing state or control-plane consumers.

Dedicated Notification Messages:

Notifications are conveyed via dedicated protocol messages operating at different protocol layers:

Layer 2 (L2): defines a fast notification protocol operating above Ethernet to flood lightweight link connectivity status for rapid fault recovery, motivated by AI/ML fabric protection requirements ;
Layer 3 (L3): Dedicated L3 signaling provides lightweight, network-layer notification delivery. In particular, ICMP can be extended for Layer 3 notifications, such as delivering Segment/Path-based Flow Control and fine-grained, path- or tenant-scoped congestion backpressure . Direct IP-level message encapsulations, as described in and , may also operate at this layer;
Layer 4 (L4): Notifications can be encapsulated over transport protocols such as UDP. advertises link and flow reachability status via UDP independently of the IGP. FALCON may combine telemetry with UDP-based dedicated notifications to return latency and congestion data to traffic sources. defines a common UDP message container for fast notifications, and outlines dedicated ICMP and UDP notification mechanisms across DCI and WAN tunnels.

In-Band Signaling:

Notifications can be embedded directly within user data packet headers in the forwarding plane. For example, Congestion Signaling (CSIG) provides an in-band signaling mechanism to convey fine-grained congestion and network state directly in data packets between network nodes and endpoints, enabling the endpoints to reflect this information back to senders using reflection headers.

A deployment MAY combine multiple realization approaches depending on topological scope, hardware capabilities, and operational requirements.

Illustrative Applications This section sketches, non-normatively, applications that fast network notifications enable. The actions themselves are out of scope (); they illustrate what the information in makes possible.

Upstream (remote) protection:: On a link or node failure notification, a node several hops upstream activates a pre-computed backup path instead of relying only on local repair, avoiding the hairpinning that purely local alternates (LFA or TI-LFA) can introduce. Efficient Remote Protection describes such a mechanism and applies both to failures and to degradations such as reduced capacity or congestion.
Fast protection in AI/ML fabrics:: AI/ML fabrics need convergence within tens of microseconds, requiring notification and reaction within the forwarding plane without CPU intervention. analyzes the limitations of existing IP-FRR in such fabrics and the requirements for fast, forwarding-plane protection.
Graduated load-sharing:: When a notification carries quantitative status (utilization, available bandwidth, or capacity degradation) rather than a binary up/down, an upstream node can rebalance load-sharing weights in proportion to the reported severity instead of treating a degraded member as either fully usable or entirely failed. A link reporting reduced capacity can retain a correspondingly reduced share of the ECMP or UCMP weight rather than being withdrawn outright. The response is graduated and capacity-aware, which avoids both abrupt load displacement and persistent overload of a degraded member.
Fine-grained flow control:: A notification reporting congestion or reduced available bandwidth can also be read as a flow control signal. Instead of moving traffic onto other paths, the consuming node slows what it admits toward the congestion point, applying backpressure well before the transport's own end-to-end loop would react. Granularity decides whether this helps. PFC and similar link-layer mechanisms act on a port and a priority, so they pause every flow sharing that port and priority, whatever caused the congestion. The result is head-of-line blocking and victim flows; in the multi-tenant deployment of it also throttles tenants and tasks that were within their contracted share. With the tenant, task, and flow identification and the fine-grained state of , a consumer can act on just the traffic responsible, and size the reduction against the reported severity and each entity's committed share. Tenants stay isolated. Such a mechanism complements end-to-end transport congestion control and does not replace it.

Scaling Considerations 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.

Operational Considerations 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 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 ().

Performance and Evaluation Principles This framework does not define specific numerical thresholds, as acceptable latency and overhead depend on the target deployment scenario (). However, solution specifications SHOULD evaluate their design against a consistent set of measurable performance metrics:

Detection and End-to-End Latency:: Measures the total interval from initial event detection, notification generation, transit across the domain, relay processing (such as filtering or authentication), to message parsing and decoding at the consumer. This timing excludes the execution delay of the consumer's reaction action.
Forwarding Plane Performance and Capacity Bounds:: Solutions MUST quantify the peak notification generation rate, the maximum scale of concurrent active subscriptions or filters supported, and demonstrate that generating, parsing, and filtering notifications at line rate introduces no more than a strictly bounded degradation to regular user data throughput.
Control Plane Processing and Stability:: Evaluates the impact on the control plane when notifications are processed by software for aggregation, policy decisions, or damping. Solutions MUST specify the maximum sustained control-plane processing rate and demonstrate that high-frequency notification bursts do not compromise the stability or convergence of existing routing and control protocols.
Network Bandwidth and Traffic Bounds:: Evaluates notification traffic volume relative to total available link capacity under worst-case event conditions (such as correlated failures or fabric-wide congestion). Rate-limiting and damping mechanisms () MUST bound notification traffic to prevent starvation of regular user data queues.

Future solution specifications SHOULD specify testing topologies, traffic profiles, and measurement methodologies appropriate for their intended operational environment.

Security Considerations 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 () 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 (), are especially sensitive in the multi-tenant deployment of . 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 (). 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.

IANA Considerations This document requires no IANA actions.