<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-geng-fantel-fantel-requirements-02" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="Requirements of Fantel">Requirements of Fast Notification for Traffic Engineering and Load Balancing</title>
    <seriesInfo name="Internet-Draft" value="draft-geng-fantel-fantel-requirements-02"/>
    <author initials="X." surname="Geng" fullname="Xuesong Geng">
      <organization>Huawei</organization>
      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>
    <author initials="P." surname="Huo" fullname="PengFei Huo">
      <organization>ByteDance</organization>
      <address>
        <email>huopengfei@bytedance.com</email>
      </address>
    </author>
    <author initials="Y." surname="Zhu" fullname="Yongqing Zhu">
      <organization>China Telecom</organization>
      <address>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>
    <author initials="D." surname="Li" fullname="Dan Li">
      <organization>Tsinghua University</organization>
      <address>
        <email>tolidan@tsinghua.edu.cn</email>
      </address>
    </author>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="C." surname="Liu" fullname="Chang Liu">
      <organization>China Unicom</organization>
      <address>
        <email>liuc131@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2025" month="July" day="07"/>
    <area>Routing Area</area>
    <workgroup>FANTEL</workgroup>
    <abstract>
      <?line 58?>

<t>This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver timely network status updates directly from the network device with a change to the device expected to react to it. FaNTEL supports fast failure and congestion notifications, enabling rapid protection switching and dynamic load balancing. By providing low-latency alerts, it helps networks respond quickly to link failures and congestion events, enhancing service reliability and performance.</t>
    </abstract>
  </front>
  <middle>
    <?line 63?>

<section anchor="introduction-to-fast-notification">
      <name>Introduction to Fast Notification</name>
      <section anchor="background-and-motivation">
        <name>Background and Motivation</name>
        <t>In today's increasingly dynamic and complex network environments, efficient traffic management and rapid adaptation to network changes are critical. Traditional network management systems are often limited in their ability to react quickly to sudden traffic shifts, failures, or congestion. As a result, these networks may experience performance degradation, prolonged service disruptions, or inefficient resource utilization.</t>
        <t>The demand for faster, more responsive network management has intensified significantly with the evolution of AI training and reasoning traffic. This new scenario presents unique characteristics, including larger packets (e.g., 4KB), increased overall traffic volume, and a shift towards fewer but larger flows.</t>
        <t>These changes introduce distinct network challenges. Maintaining high performance and availability necessitates high-speed interconnects supporting 200-400 Gbps for GPUs. Furthermore, effective load balancing and congestion control mechanisms are crucial to ensure that these massive, critical data flows are managed efficiently and without interruption. The ability to meet these demands is paramount for optimizing AI workloads and ensuring continuous, high-performance operations.</t>
        <t>Fast Notification for Traffic Engineering and Load Balancing is a mechanism that delivers timely notification of network events (e.g., link failures, congestion, traffic shifts, or load imbalances) to the relevant network nodes. By enabling rapid communication between devices, fast notification facilitates quicker decision-making and faster adjustments to network routing and traffic management strategies.</t>
        <t>The core principle of Fast Notification is to reduce the time it takes for a network node to become aware of a change in its environment and to adjust accordingly. This is achieved through the use of high-priority, low-latency signaling mechanisms that notify nodes of changes in traffic patterns or network conditions almost immediately.</t>
      </section>
      <section anchor="notification-procedure">
        <name>Notification Procedure</name>
        <ul spacing="normal">
          <li>
            <t>Fast Notification Messages: Lightweight messages that convey state changes (such as traffic or network failure events) from one node to others.</t>
          </li>
          <li>
            <t>Notification Propagation Mechanism: A reliable and efficient way to disseminate notifications quickly throughout the network.</t>
          </li>
          <li>
            <t>Triggering Mechanism for Message Sending(out of scope of FaNTEL): A mechanism that detects significant network changes (e.g., link utilization thresholds, delay spikes, packet loss) and initiates the sending of fast notification messages.</t>
          </li>
          <li>
            <t>Action after Receiving the Message(out of scope of FaNTEL): An action (such as rerouting traffic or applying flow control) once the notification is received.</t>
          </li>
        </ul>
        <t>The requirements of FaNTEL focus on the definition of notifications and their corresponding propagation mechanisms. The methods for triggering notifications and the actions taken upon receiving these notifications, whether through existing solutions or new protocol extensions, are out of scope for this document.</t>
        <t>The mechanisms that are out of the scope of current notification requirements could be implemented using existing solutions.</t>
        <ul empty="true">
          <li>
            <t>Note: The detailed mechanisms and implementations (such as message format, propagation protocols) are out of scope of this document and will be specified in separate documents.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="fast-notification-for-load-balancing">
      <name>Fast Notification for Load Balancing</name>
      <section anchor="background-challenges-in-load-balancing">
        <name>Background: Challenges in Load Balancing</name>
        <t>Load balancing is a critical function in AI networks, ensuring that network resources are efficiently allocated and that no single node or link becomes overwhelmed with excessive traffic. Proper load balancing improves network performance, prevents bottlenecks, and ensures that network services remain responsive and reliable.</t>
        <t>However, current load balancing techniques face significant challenges in highly dynamic environments. One of the core issues is the lack of timely awareness and adaptive response to network state changes. Traditional mechanisms often rely on periodic global state synchronization or static policies, which results in delayed and inaccurate decision-making. These delays make it difficult to capture instantaneous changes such as link congestion, node failures, or traffic bursts.</t>
        <t>Moreover, load balancing decisions based on local views cannot perceive downstream contention or routing fluctuations, potentially leading to persistent traffic injection into congested paths and increased queuing and packet loss.</t>
        <t>Fast Notification is supposed to support load balancing by providing fast, efficient notification of changes in traffic patterns, network failures, and congestion. By using high-priority, low-latency messages, Fast Notification allows network nodes to immediately adjust their load balancing decisions in response to these changes, ensuring optimal resource utilization and performance.</t>
      </section>
      <section anchor="requirements-for-fast-notification-in-load-balancing">
        <name>Requirements for Fast Notification in Load Balancing</name>
        <ol spacing="normal" type="1"><li>
            <t>Traffic State Detection: Monitoring of traffic patterns, link utilization, and node load to trigger notifications on significant deviations.</t>
          </li>
          <li>
            <t>Notification Propagation: Propagation from congestion node with event details (e.g., congestion, traffic shift) to relevant devices.</t>
          </li>
          <li>
            <t>Action Adjustments: Nodes can reroute or redistribute traffic immediately upon receiving a notification.</t>
          </li>
        </ol>
        <t>Once a fast notification message is received, the load balancing mechanism is supposed to immediately reassess the routing and traffic allocation strategy. This may involve:</t>
        <ul spacing="normal">
          <li>
            <t>Shifting flows to underutilized paths</t>
          </li>
          <li>
            <t>Splitting traffic across multiple paths</t>
          </li>
          <li>
            <t>Throttling traffic destined for congested regions</t>
          </li>
        </ul>
        <t>In addition, nodes may update their local state or forward the notification upstream to further optimize the network reaction. Timely and coordinated response across the network significantly enhances load balancing effectiveness.</t>
      </section>
      <section anchor="design-gaols">
        <name>Design Gaols</name>
        <ul spacing="normal">
          <li>
            <t>Traffic Information in time: Fast notification provides up-to-date information about the current state of the network, including traffic volume, node utilization, and link load.</t>
          </li>
          <li>
            <t>Precise Load Rebalancing: Enables immediate notifications to the affected nodes for quick traffic redistribution.</t>
          </li>
          <li>
            <t>Optimized Resource Utilization: Supports fine-grained traffic distribution on a per-packet or per-flow basis.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="fast-notification-for-protection">
      <name>Fast Notification for Protection</name>
      <section anchor="background-challenges-in-network-protection">
        <name>Background: Challenges in Network Protection</name>
        <t>Network protection ensures service availability and minimizes disruptions due to failures like link outages or device malfunctions. However, traditional protection mechanisms face several limitations:</t>
        <ul spacing="normal">
          <li>
            <t>Slow Detection and Recovery: Traditional protection often relies on periodic failure detection and centralized rerouting, resulting in recovery times that are not fast enough for modern service expectations.</t>
          </li>
          <li>
            <t>Inefficient Failover: Without fast notification, failover paths may not be activated or optimized in time, leading to service interruption.</t>
          </li>
        </ul>
        <t>In high-reliability scenarios, network protection must be capable of rapid detection and notification of failures to meet performance goals such as sub-50ms recovery.</t>
        <t>Fast Notification enables rapid notification of failures, allowing near-instantaneous and dynamic protection responses, minimizing user impact.</t>
      </section>
      <section anchor="requirements-for-fast-notification-in-protection">
        <name>Requirements for Fast Notification in Protection</name>
        <ol spacing="normal" type="1"><li>
            <t>Failure Detection and Notification: Notifications are generated when failures occur and propagated directly from failed node to the relevant respond node.</t>
          </li>
          <li>
            <t>Precise Notification Propagation: Notifications must reach relevant nodes quickly, such as upstream routers.</t>
          </li>
          <li>
            <t>Optimization of Backup Paths: Failure notifications can trigger optimized rerouting or pre-established backup path activation.</t>
          </li>
        </ol>
        <t>Upon receiving a notification of failure, protection mechanisms may immediately switch to backup paths, reroute traffic, or suppress affected routes. This ensures minimal disruption and quick recovery. Coordinated response strategies may include upstream node notification, service-aware failover, and path re-optimization based on updated network topology.</t>
      </section>
      <section anchor="design-gaols-1">
        <name>Design Gaols</name>
        <ul spacing="normal">
          <li>
            <t>Rapid Failure Response: Enables sub-second (or even sub-50ms) reaction to failures.</t>
          </li>
          <li>
            <t>Improved Service Continuity: Minimizes traffic loss and recovery time.</t>
          </li>
          <li>
            <t>Efficient Resource Utilization: Ensures backup resources are used only when needed, and in the most optimal way.</t>
          </li>
        </ul>
      </section>
      <section anchor="integration-requirements-with-existing-protection-mechanisms">
        <name>Integration Requirements with Existing Protection Mechanisms</name>
        <t>Fast Notification can be integrated with various existing protection schemes to improve their responsiveness and efficiency:</t>
        <ul spacing="normal">
          <li>
            <t>Fast Reroute (FRR): Fast notification enhances FRR by delivering failure notifications almost instantaneously, allowing for faster and more efficient rerouting of traffic. This helps maintain high availability and minimizes service disruption.</t>
          </li>
          <li>
            <t>Hot Stand-by: Fast notification complements Routing Protocol Convergence protocols by providing fast failure notifications, ensuring that devices can quickly switch to backup paths and maintain service continuity.</t>
          </li>
          <li>
            <t>Multi-Path Routing: In networks using ECMP or other multi-path routing protocols, fast notification enables the immediate re-adjustment of traffic flows when a failure is detected, ensuring optimal use of available paths.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="fast-notification-for-flow-control">
      <name>Fast Notification for Flow Control</name>
      <section anchor="background-challenges-in-flow-control">
        <name>Background: Challenges in Flow Control</name>
        <t>Fast Notification enhances flow control by providing a fast, low-latency notification system that can detect and alert network devices to congestion events in time. With Fast Notification, congestion can be identified and communicated to relevant network nodes almost instantaneously, allowing for rapid mitigation actions such as traffic rerouting, rate limiting, or queuing adjustments.</t>
        <t>Note: Unlike traditional host-to-host (end-to-end) flow control mechanisms at the transport layer (e.g., TCP), this document focuses on Layer 3 (network layer) flow control. Specifically, it targets congestion control and buffering actions between adjacent network nodes, enabling upstream nodes to slow down or buffer traffic in response to downstream congestion.</t>
        <t>A key challenge in flow control is the timely detection and dissemination of congestion events to avoid packet loss and throughput degradation. Traditional flow control mechanisms often rely on delayed feedback or reactive responses, which can lead to suboptimal network performance in highly dynamic environments.</t>
      </section>
      <section anchor="requirements-for-fast-notification-in-flow-control">
        <name>Requirements for Fast Notification in Flow Control</name>
        <t>The integration of Fast Notification into flow control mechanisms involves several key processes:</t>
        <ol spacing="normal" type="1"><li>
            <t>Congestion Detection: Network devices continuously monitor traffic flows and link usage to identify potential congestion points. When congestion is detected, a notification is generated and sent through the Fast Notification system. These notifications include critical information, such as the affected link or device, the severity of the congestion, and the current traffic load.</t>
          </li>
          <li>
            <t>Notification Propagation: Once the congestion event is detected, the Fast Notification system quickly propagates this information upstream to adjacent nodes that may contribute to the congestion. This enables upstream nodes to take appropriate actions, such as rate limiting or buffering.</t>
          </li>
          <li>
            <t>Backpressure and Buffering: Instead of relying solely on rerouting or end-to-end rate control, this approach allows upstream network nodes to apply backpressure by slowing down traffic forwarding or buffering packets locally. This helps to absorb traffic bursts and prevent packet loss downstream.</t>
          </li>
        </ol>
      </section>
      <section anchor="design-gaols-2">
        <name>Design Gaols</name>
        <ul spacing="normal">
          <li>
            <t>Congestion Detection: Fast Notification delivers updates about network conditions, enabling relevant network nodes to know the congestion as soon as it occurs. This ensures that corrective actions can be taken promptly before the congestion worsens.</t>
          </li>
          <li>
            <t>Adaptive Node-to-Node Congestion Management: Fast Notification enables adaptive congestion management at the network node level by allowing nodes to dynamically adjust forwarding behavior and buffer usage in response to congestion notifications from downstream nodes.</t>
          </li>
          <li>
            <t>Minimized Packet Loss: By enabling fast congestion alerts within the network, Fast Notification helps avoid packet loss by triggering corrective actions such as backpressure and flow rate adjustments upstream, before congestion reaches critical levels.</t>
          </li>
        </ul>
      </section>
      <section anchor="integration-with-existing-flow-control-mechanisms">
        <name>Integration with Existing Flow Control Mechanisms</name>
        <t>Fast Notification can be integrated with existing flow control strategies to improve their responsiveness and efficiency:</t>
        <ul spacing="normal">
          <li>
            <t>Transport Layer Flow Control (for example: TCP): Fast Notification is distinct from traditional TCP flow control, which operates end-to-end between hosts. TCP reacts to congestion signals that are often delayed due to network round-trip times.</t>
          </li>
          <li>
            <t>Layer 3 Node-to-Node Flow Control: The mechanism proposed here focuses on adjacent network nodes cooperating via Fast Notification to perform rapid congestion signaling and buffering. This reduces reaction time and improves network stability in dynamic environments.</t>
          </li>
          <li>
            <t>Explicit Congestion Notification (ECN): Fast Notification can complement ECN by providing more granular, rapid updates on congestion status within the network fabric, allowing quicker local reactions beyond the transport layer.</t>
          </li>
        </ul>
      </section>
      <section anchor="illustration-host-to-host-vs-node-to-node-flow-control">
        <name>Illustration: Host-to-Host vs Node-to-Node Flow Control</name>
        <artwork><![CDATA[
           HostA ---- Node1 ---- Node2 ---- Node3 ---- HostB
           |                                             |
                   |=====================data===================>|
TCP        |                                             |
Flow       |<+++++++++++++please slow down+++++++++++++++|
Control    |                                             |
           |---------------------data------------------->|
                   

                   |=====================data===================>|
Network    |            |<-slowdown--|                   |
Flow       |===========>|--------------------------------|
Control    ||<-slowdown-|                                |
           |---------------------data------------------->|

]]></artwork>
      </section>
    </section>
    <section anchor="fast-notification-for-capability-announcement">
      <name>Fast Notification for Capability Announcement</name>
      <t>In addition to conveying failure or performance-related events, there is a potential need for a lightweight mechanism to announce certain network capabilities that are not directly related to routing.</t>
      <t>Specifically:</t>
      <ul spacing="normal">
        <li>
          <t>Some types of network capability information (e.g., processing features, service functions, queuing models, etc.) may need to be announced among network nodes;</t>
        </li>
        <li>
          <t>These types of information are not suitable for distribution via existing IGP or BGP mechanisms, either due to scope, frequency, or protocol constraints;</t>
        </li>
      </ul>
      <t>While this document does not define specific mechanisms, it highlights the potential requirement for fast, low-overhead notifications to convey such capability announcements across devices.</t>
      <t>Further analysis and definition of this use case is TBD.</t>
    </section>
    <section anchor="scope-of-notification-mechanism-definition">
      <name>Scope of Notification Mechanism Definition</name>
      <t>To support fast and reliable notification in network systems, it is important to clearly define the boundary of what needs to be standardized or further specified. This section identifies components that fall within the scope of the notification mechanism and those that are explicitly out of scope, in order to guide future work and maintain modularity.</t>
      <section anchor="out-of-scope-elements">
        <name>Out-of-Scope Elements</name>
        <t>The following components are considered outside the scope of the notification mechanism definition. These elements are assumed to be supported by existing technologies, protocols, or implementation practices:</t>
        <ul spacing="normal">
          <li>
            <t>Trigger Event Mechanism: The process of detecting network events (such as link failure, persistent congestion, or threshold violations in delay/loss) and deciding when to send a notification. This function is typically handled by existing telemetry systems, performance monitoring tools, or alarm-based threshold mechanisms.</t>
          </li>
          <li>
            <t>Action Mechanism: The logic that determines and executes the response after a notification is received (e.g., traffic rerouting, congestion control, or flow prioritization). As this is deployment-specific and closely tied to the control or management plane behavior, it is outside the scope of this document.</t>
          </li>
        </ul>
      </section>
      <section anchor="in-scope-aspects-and-potential-work">
        <name>In-Scope Aspects and Potential Work</name>
        <t>The following aspects are considered within the scope of the Fantel notification mechanism and may require further specification:</t>
        <section anchor="notification-format">
          <name>Notification Format</name>
          <t>The encoding format for notifications must be compact, extensible, and interoperable to ensure efficiency across diverse implementations. Candidate approaches include:</t>
          <ul spacing="normal">
            <li>
              <t>TLV-Based Notification: A Type-Length-Value structure allowing flexible expression of notification content while supporting forward compatibility.</t>
            </li>
            <li>
              <t>OPAQUE-Based Notification Structur: Notification encoding structures may draw inspiration from mechanisms defined in [RFC 5250] or similar OPAQUE models used for flexible and structured signaling. Reuse or adaptation of such formats may enhance compatibility and extensibility.</t>
            </li>
          </ul>
        </section>
        <section anchor="notification-content">
          <name>Notification Content</name>
          <t>Notification messages must provide enough information to convey relevant network conditions, which may include:</t>
          <ul spacing="normal">
            <li>
              <t>Network State Information: Metrics such as interface status, delay measurements, packet loss ratios, queue depth, or congestion indicators. The applicable granularity may depend on whether the information is interface-, path-, or flow-specific.</t>
            </li>
            <li>
              <t>Optional Capability Advertisement: Nodes may include information about their supported notification handling capabilities or processing constraints to allow the receiver to make more informed decisions.</t>
            </li>
          </ul>
        </section>
        <section anchor="notification-propagation-and-scope">
          <name>Notification Propagation and Scope</name>
          <t>The delivery scope and propagation mechanism of notifications must strike a balance between speed and scalability:</t>
          <ul spacing="normal">
            <li>
              <t>Point-to-Point (P2P): Delivery to a directly connected neighbor or designated next-hop.</t>
            </li>
            <li>
              <t>Point-to-Multipoint (P2MP): Dissemination to a selected set of nodes, for example along a service or forwarding path.</t>
            </li>
            <li>
              <t>Scoped Flooding or Domain-wide Broadcast: Delivery to all nodes in a defined region or domain. Suitable for critical events, though special attention must be paid to control overhead and duplication.</t>
            </li>
          </ul>
          <t>These in-scope aspects form the foundation for standardizing a modular and interoperable notification mechanism within the Fantel framework. By focusing on propagation procedures and message format while leveraging existing technologies for detection and reaction, the architecture supports fast and reliable awareness of performance-impacting events across the network.</t>
        </section>
      </section>
    </section>
    <section anchor="summary">
      <name>Summary</name>
      <t>This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), focusing on the role of fast notification.</t>
      <t>It outlines how fast notification can be applied in four key areas:</t>
      <ul spacing="normal">
        <li>
          <t>Load Balancing: Enables rapid dissemination of network state to assist in balancing traffic across multiple paths, improving utilization and responsiveness.</t>
        </li>
        <li>
          <t>Protection: Facilitates fast awareness of link or node failures, supporting quicker protection switching and reduced traffic loss.</t>
        </li>
        <li>
          <t>Flow Control: Helps inform upstream nodes of downstream congestion or performance degradation, enabling timely traffic shaping or rate adjustment.</t>
        </li>
        <li>
          <t>Capability Announcement: Supports lightweight and flexible notification of node or service capabilities (e.g., processing features or queue models), which may not be efficiently handled by existing routing protocols.</t>
        </li>
      </ul>
      <t>The document emphasizes core requirements such as notification message structure, delivery scope, and interoperability, which could be defined in following work, while keeping trigger detection and action logic out of scope.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC3168">
        <front>
          <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
          <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
          <author fullname="S. Floyd" initials="S." surname="Floyd"/>
          <author fullname="D. Black" initials="D." surname="Black"/>
          <date month="September" year="2001"/>
          <abstract>
            <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3168"/>
        <seriesInfo name="DOI" value="10.17487/RFC3168"/>
      </reference>
      <reference anchor="RFC5880">
        <front>
          <title>Bidirectional Forwarding Detection (BFD)</title>
          <author fullname="D. Katz" initials="D." surname="Katz"/>
          <author fullname="D. Ward" initials="D." surname="Ward"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5880"/>
        <seriesInfo name="DOI" value="10.17487/RFC5880"/>
      </reference>
      <reference anchor="RFC7490">
        <front>
          <title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
          <author fullname="S. Previdi" initials="S." surname="Previdi"/>
          <author fullname="M. Shand" initials="M." surname="Shand"/>
          <author fullname="N. So" initials="N." surname="So"/>
          <date month="April" year="2015"/>
          <abstract>
            <t>This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7490"/>
        <seriesInfo name="DOI" value="10.17487/RFC7490"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8Vca5PcxnX9Pr8CVf4QsjwzoSgrlieOS8slKbFCUhtyZdlJ
pVIYoGemTbyEBnY5KpV/e859dKMbg6VsK1VhqbTzABq37/PcR89ms1m5IW/K
/8mrtjG7bOhHsyrywRzb/rzL3FCu3LivrXO2bW7PHS559eL25cp2PV/shqdP
nvzuydNVlTfHXWaa1WqwQ4XL3pkfRtub2jSDy9pD9jJ3Q/a2HezBYn2slh3a
Prvt8wM+yF40R9sY09vmmIGc7HWbl9mzHKsW+GiV7/e9uVtatBlMtSrboslr
PLTEcsPmaJrj5sBf+T99dOMG5LZ711ZmMG63Grsy5xe/yujFLnv65OkXmye/
xX/ZapX3Jsdz23Eg0q7wbnXf9h+OfTt2u+zl1dvbF69x1Tic2n63WmWbVZbZ
xu2yP22zr0EH3gppfxqNa7GEftj2x7yxPzIndtk3Y35vLD42dW6rXUY7+Cg3
fHXi77ZFW0er32xxTxsWv8H1L43Vz9K1n50H8xx8NNPyp7HtcMfB2K/2+Lak
b2cP+PM2+8/TGB7wZ1DyA3FAPkyfcH2yTZ7dmsrwGv4pP57G8w9fflXQt4N8
uS2aLHrI82322oZngEh5m65+6/BcMCH7rrF3pnd2OE/PGNrKgvyvBr1oa8oR
D4me8f0W9MWC+N7YHyy0NXy8tJk37d5WEccKuvZe75Qt1XzJjG3XtKOJbdcn
epB8svQYbClhWWXH4rPPP5MHjPwl7Wa1sg2spca9d2aHy9+9vP78s3/5Ul9+
8eWXT/Tlb3/zO7xcrTabTZbv3dDnxbBa3Z6sy2AkI+l/VpoDbM1lw8lksV2w
Qf4SM80evczJHh6vszyrTYHNW1fjec4eG1NCWHhdkRCzwdamOmeNGcia4Gfy
YXSZmmJWgqRiwPeHvq2ZTn9hae5sYbJ7O5zwDHrC0dC6dI1+Zz52uFkeB3Mt
Bnphh20mxGVu7Lq2p+3SVg/g+9gb3k0BJTeON91EHHBr+LV8X9EO+7yzZdb1
7YBn0IUOpJC0hB/lGXIHnyriy97zZQsbpHvubEkXVu39psI+m+Kc5ZUBKWvQ
l51M1Tm/UQfSXddiScin+ABWYBOg4IMn2M0pNnckQyL1pNJwpmeG9OB5Dl2F
4fBNnelZmcjoVVVqW5ZQ9xV84Ktm6NtylN3hoRcKgYt+BZkX7AOxHC35Bt/f
6bev6LYyP/+Tg0kUkACZJjbgeSN0111lPgaxmubO9m1T6xZI1yyp6qB6B2Lz
I2sp3y5SyMu8G3JPp19KdALsgVCL3g6gutqSApeWLs2rcGW0qDu7wdRyU3uA
aMDr2pIS2YZ0y/aZ52DQqkgwbixL3OOpdSd7oH14Ua1h+5GottkVnkQCHqth
Tcs7M8m9zs+swj0YAOFFwoKCH7EN3vGa9KmiJcsg59K6fuxUY/FEWGpgJB7W
jj0uQhyr1AltyTHQqjXxlMycLML066xue6MK6GCuSxw75SRecMpBMYgImDir
SEN2y/ZJNmnu2mpkESFaX70iFtnGWwvpRsvvlHOQE3mqxtxnroDN9bbFPsEe
8k5whz+MhuRLTg38ATMLMp2mqEYxrLw/wrd00E2DGx6Z7XG7zn7z788er70q
gtIW/ievqiAtorA2a6YoF9lBpvd5X8JFmHssuB8Hv/YBxuuEcc4EXbNqMywD
AAVoR6SOVWXoqm32BnsfdP8nezwlwuXH30FjvKI1pjCAXQN7RLp84zrDGonN
Q5vwPTap3oyWBBLb/ObJk+zrfSe+/Oub7/DUl2MPSfQkUzYtclyQaeqi5t4E
L7GlavLi3qDGwsKEoPOQPPnN4ZQPqsJ17khb1sHsCE/lwjK+W9SnnOy7EodE
2gKAJTtTFSZVMLHR1cb4B4nGgu0Osu4RiEcoJG24xa21/ZGR2quM+E+7FFfJ
9NI3tDXbjO0I3WG2xlIALurF6UPIvygWWpcEQeaTRj8Xwl+8NgwkuEP25V6B
E7e/jqS0vvA4II/lamuRrHGPfXREFDB3sM7wkKYtSSkRmmbRDc65JuwhZO1x
uYFzk+jKXg1cSSg/5AWJiRWVvSIMpTSFpZxhU+cfPIfEvcBv/wV5g0COyHH3
irHpygW/T1gGaYk1an4gEyrVgf2FRSxZTjGsE3/NtklcIMZTsB3yD0aMJE8Y
QpfvCalC9+4lGkw4A7HAguYoWAmxrW4pywsQVXK4U1dGWgB4AIHiuhO2eBS/
ODpeWvQPbg4Wc14nyIAcas5SiWyQtYh5fxb50SKTFwp86/IBnG4cKUTwREAT
HAJBUlW3INfWtSktYfPzlqN6wrubvi3AuB6wYLPA2jdwTpANMO9rbAI6Qv8H
rfKpUIpH3pkzo7vJWT5yYwHw5gKxEY0ejYkBPBb8h8Q0yKYlVwYN2FzQ2uVH
T5iya5ddKfapxL1O4fA+Z58Cb+1MzelJivim4C4yI+8UwVB6/m1vj0ex/vBE
VihlTPbeNKQKj+heSMkV8C2ipYyRiboL9zCIT59i6QWsiX1CFMuJUONObVXC
QuFmsD/X2Q9krxIOoVsODCU2IAANlo2VtuSETKLs0rK9OGnDVwIJkWDDht8h
ONk7Dt1YQ7f8ia3iPrk9SL833uAjPci7rjrTZxQ0fBB6DA1Q821mxt0zGaZU
l9BflAcY8R+Q+eB9o1nCgRmgHjeROlszoz3YsQJwoqaL1GuyRglRtUHwKsWX
DJNOLC6sTHDsfhqkO1ivjznpzDzzuD8ZUvngPMxHRhhA9wqs1MbvOSlpC8Rs
85FhGd/OLiyWCpMZp4PKurmTiW5kLfEiLUYwppmpScL3oh0rIAu4S8L49Bl8
30hJwALxePofyJSRKwsWBT6qcH2MO0hl/VLKz6BFqqCZZMfrRFKeIaT2czbw
tuKkWHAIYCEIB84qBNXCpTpDGAMOwl9KNCNPWgYHs7pVmipxPUDRIC09v/h1
CskYQQQsdRgbsSDcCHDj84X1BGwkOPhoqoBfkFeCuKqqpQpfqVrJESXjJE39
LKEI8i8SCB0jZuhhhWghyN58ZGgKFBmAO3lg089RJeSGtNeEtDZGvCQsBTr7
dhjAFlPQfgJY81EkFAkkzyGrr4Gi4wRFsglx9RDPN+09VkYi47V1Rhbc7Imz
CSoCwLXEDrdIREQBOspd4zx1m33bGG8fDEYQTWhJK461gtz5a8F6DCcasE2Q
PuWuRLluwsRIKImXae4a2YXkqT2tTcoOt9OWIPFYtdioruHOTQHH4ctOJFn6
ghBCW5FGsIexsCXJRnnPHD5UPRAbCzCR9T9FdOz9GIzjakpbPzCwKi3pA5ai
DRXYJIVz21CRGf8ZoO4QyrwNs67FqJaVMEmefYjYj71jA3wDfrcs4ploPZVQ
Ksn2kMq3ZD931iANgYjhuYhbHDhg1PegDZlhzdEGclU2+eB0qMZiGL037lq+
BBpyziqTc3DAPjsqS7ohrljY5i/G2ytxQrYHggDNTurUQkoKTRw99I3C9WIK
YjXnc1Lh0vxvzoZ9XHCiuB5XVeZpxycA5HoOzdRA42oGMghx759Asx5IrBf8
Jjmke5fmJVyzm+CpB9gSnB8U+eQUfFFwStIjR8lpIlRiqSiyUCGDD3/382XS
BX/+2TYki+/ZHJ8bLRvusjcwyqHtFXldsn0O8ITtbBm8fdqeoI0Z1KCaZOTO
KG3zCe3T7YOoeZdAaIbdSTW01JorO2wN0wGMPpiRPpbsSxNPzSC3q8+3Hkxe
TangDrSR4EG1YkMORMjdYFm93dP7YFyRZsxAVJ6wA9L7losrD2PbGEauxXGn
6jWB9JnpxVSQITty7pxqL2SyGnW5ZCyZrE8RqeBnm7u2otI+cPZ74pzHwGwI
gA6mF13wDoSu65BzJwA6L3p4jayG9+WU2F95ixCAABtfWpK8qCZ/mEqThmLo
kVSFi7h5KVFnrRZJdEqBPphhEQINFQ/bnopmlzh97NTDYisHKUb5So1Jivtc
V5Xaj8ZM9jScUudCnhq37jS+OS1AShUcVM+EGepfFInFtp9zeyL7OgdSXHFi
Jyx65VsuYtwUxndi98nuxM0aal5shnbD/LHRrfneJ48ejCjHDjH5cRlzXphk
67twBewgaHeUm9305AONeKB3Jux3l72g2g75dq+sM3eh1aGc+WJKlTVpBafA
gZjIDtmuNtm3KkJ6oPrR7yYid9n70GeBom2OVPg1kz3Eq5HPysnpbjT44en0
jpNAhHH7Sch9E5oxPwO336qmxDf4z6KOjseevqyeFGWJ8zXyR9q4iyvuWTly
zAntmQrZtwgJ8ueSSNv7FhWCj4fzwHcBrQ4R0IsIijCfoFXDFWxpUYgYxXEQ
u0KIYVKRphNKOu8SEBmtHUCkNS6Bkb4SUybrFdBfPJqlHhL4tYJHBvzsi/mZ
bDFRNkm4i72waTiTJdnV0La+CayW1p0PVxuY4ARaXoIgWneXfa/l4guXLh0X
ukhRFrkseuxeMu87diJTnVjbO5aMLEJznpqkHM0ukQFO3E7zXYoIJ8WCI8iC
ZwMGcw0KJi8V1pSpczgWVMhXveMC9bHNqwk6u3G/+eJJ7QLTFyGjUR8gD3/o
cWsBYly8MHm/SUF73N2Mtug9Mu5Ws6D7R7CQcj8w/e/BT7FhfrZliZMKpiod
37RL3kmqe4Rr71nQSFmbiZkt5TGC7hTp4JK00XyQ2oOvNSZVc9+OpS8ZSXmX
+zCiSmljZaAId4pK8exstda4DlINAZNRUC+ISd1tEBv5ubHLbkjRd4FXqXMn
LOVR4qTzU+WN/GxvNoj91ABwJ0Ohkpcl+/E2I+r/3adwVqRH6wdcF8OcCDFJ
45zr7dMj3TpgPw0UnP4R6uo5dfZhiq9xiqC8x2YNpLZTcMssbwlkwUKy6yVE
MbUXFJBRNDaTKFgpUmejfmIjjQLvetaaxQ0k500bSy1kpAKjyuAzhhbpeHs8
LwOSd2y2XsLvlOIptJMTcIbK+9kjMIsgenAMjwOoioMT+1YpzZTZe3V319IX
g1tDdhJCnI/XlI9qmSVy77TQi+Cil3HAC5WOijktTI3CEWoZk7U2xpQEwyU9
ZgvkToXP2O5z5dEr+OajdOpS58JZygtfZ5w8ylSkd0sukixlLy7/qN6DFroj
5w7vFwqX8eRHcTK1z1SZl4qLp7pUKPf4MFacd6Gb8k4V/dHLd+8eLyHLgGFx
ASX02j2UjH7J3H1bJ3bc5FeCX596/AJk2rg0GPuFw6wjL7MptfavpXn9CVx0
OZFAivINIvF7Gjbc7M9L+5WhEBGjH7i78UXta2ol9UeZifCF3csyxzJn5kVS
zURZ6r7Ts+yPZGN+335fRTAV2tcbwj4bcsSe7B30c5rokOLIi+s3N4w9OP/h
HG0jXkK3Gna11GL1IZwsYoLycDBTMzWuI0jqyCaVB5ZQuZtDKVnYRTFEO5Iq
VZ89fgp4vyS8eS09mp+B3umlSwhFVT3u+6TSzbWMFVeVEhbJDI82HvNG9yrV
Vpqyms2QseFezE95QLhllHm58XUyJKFOo6SaIPcLdLZJ2+d+Bm2p8f63Gasg
NsB8q5UZ30Ca91BjME6awbkBv+VMTsuLU7UFcpWuy3cNJypx6nECXZTK0t/s
kYG94g3+PE6lE7doJMHFIo2TamR+hpJreej2+ubxetZu4ZacpByv+drPs0ee
P3xz+rBt9l56MgWVXtfSwYc34HbTxdAKSWE/AirIbIayzA8ygAt5YebyiGb8
kpjPauKIFCoVEzdl5ajQm9Qc04Kyr5GuVlfZB3Oemgt0W8JNbRposyBNEKY2
tS/YXqgtzSDctTYpH2t/h/uG3TjE42NpU+EhsaYdBt8WOCBG77m30Su4iNoY
oZ9AtkE5ldSo997LLPSBfq7Nsvo7MojUz1BH0UZAYXlEhMrzD3FA63Iu5Nwk
xI4GI6jat+M05XoSRlTffTtzNtPUEfZZS/F35q5DVWfkuiThCvEs56nvEIu+
ay23ob4nNx99nvj5GU7Hd1OCRA903LSIJlMuOSSO1fd7UsjhcXJoU0alrymh
SSpMUhPxtZC1DiEQsAGOCO20qaLse+e+fDYhUqp9fbqo/a0fHJhbTMqkT+07
AISQNjrxZXGRLy5xTv5F3AfFI0opWL20jt3OiAqJjET5Sw9EAwM0HQEaeg79
6tUmHiduf/JT1KlbUf5IwZmTKD/t/Mx/T2gFO4WtUoHCyAAGHY8Qu0/SxSka
yAPVZtS9M4GU4WpLZ9rHvLfDgx6MtAJNiPZOQx+72mAcUlee7yqMeXIZOgxc
CVKlJ+xd2+9nnUPN/0UFYlc5uW31N/MkbNnKL5UmjPj5WXap/14OYcVD5csI
AZv40MAvzfSXyj6t/EUY5LLGPBHW4au+11lPHwIVsMj0CURVd1T72JtD21+Y
CQiBbyD3u8mufLeaWjQkf/obs+RNmNNb4olX69D0jh4TT3YnM1ba64KoGAhO
tSnPGw0W3IvV9mCkKntzyu9s20dgQP3qLGA/NPQvJaEonMu8JLHDZ8dldiMq
9BoqtEsmKRnBx0LjOX9OKjWvDYX/S36JDl/Gc7AhmjBakK/3Bfu5rXN8Y4ON
hy+9ea69CkQEc6WK4pZ37CwJH43j9DvNuOMI/I/l3CHXToJyVJ/5BxLu24BM
BW0mVD4iOGE+5pR97hitLimxddNwtxxLiRAUbkrI9ShIxomNi/2mx6EEr8lw
cSvDqHlCIgOg8TgWwzEPw7TfEE3P0iN620ndnRXVQ+vEbOO977Jk9otjHLc3
kaOaGKQvg2ZqzsnANMR1Z/MFtsl0BEXKMF0826HvlE7xSpyZTO26qIBFs7s6
DZZOFVH9UuoQNL6yDCI30NGOZl6G2HEltD56cf12UfakqVN1Aqn82zQ35UIK
dLgZq7xf60Z9AGgTcKYnnS4dAVzGvqd6Z/B0fpRa+qyeDZTInFvFRLOMy1tn
VY1sLxyjvtF0jv5md+5hZVit/vrXv65W2fSPbrnKNnRCiK7+bHr5dHr5ubyk
a5/FN/+U/T3/flotffhvS//oVMHCx3/4aUW29A8+nRmhb37/6/gfpJ5Tgdjn
gL9O//208n7kl+35p83SP9rrwsd/WGTX6v+Chz5xme/mp99viAXEgc1maZ8p
D5NFF7cW/Ut5GD/pZxn6i3goCv9Qfeua2nbiVq6aBv61YPNPhiPUZ9+Zc1yW
lf61T3CpY8jhzR/RG9i78njnlNhR6VsPJFTJQH0YEQemVTKyAmiCCpIBVnpS
7bzjGjpcngiqSAmeh7eIqyrSQ6aTD8O5k5MFF8ufk6xH6zuaDzMDTD5IL9GX
SkOfex3KUNT0pSqnGYrtY+nRGiGM+rS6RWSndcutyCje/CsPs1AWGkhMRi10
z260A5cwiZ3JoAHFqIAvXn3NBdln+DOl/CDLcoVW4yuPC68R8Q3IB5xYS9NM
q9IQveMjbQNoW31/spWZFbrKluJU60/d+tniInkknf6kCghJXLLlSS+i2epQ
v5cqKLVhTpS2XUx0+HMXIxdiuqlIP2mx8zM0YSprpQfFcFlenZ3Vnm8yLs97
o0pxQS4Rr2+fPZcS8Xs/Vj07JOK193lYZ7W6ncYWGSfH07uzcsWk4npEk5lF
2XdN91PSRPuFi+65bMY8JgbuCQ/lPVcU7mWK2JROlYx/8oAShR9lHsBPJYXB
b4Ugzo9w+gqvYxjQNlJzo2UPdJQwiubRePlsL5MlS0WjdWYyVaPYhFLuaE6d
xoJAYEn1xjY7jpYGY0eeqWWmJN0J2BXhD+5KEAz4dhw27WEjknmhnRWpih1a
DzKi/eSSATg8pCe+jAO9/Jt3NWmKLxUZ382hlXNkI3Uwc5U/NZzPk0XyXDZ1
QnkwOWqItP3sCAC+JDhUGKf4XprcLzixj04A0WbVPxH5WleN/Io/apcMI0+t
7GmwNy5J8RkKPW8Dn9JWoRom8Pyfp8M2NJzKGJGbMTxdwudMkylF0bZpwt+R
f9PUFjspqws+ESsGaHewirigWk+zpUPr+ZdDNeqNtKAn4qPTLKvpjM+MgSSQ
Yjqi1Nf88wGcZn00xehPEk3TeXxE6LLy6McsfeBYaF5cVvOZeM6tdLJYG8uP
+Rj1oIfsStNV7ZnUYxM8LDdjIAmqYw1WVE+LHIw1aP5oqj50VQ7X4csG3s08
YATp+RlOiNXOrujxWmi6CU78e6ja3PJyf2Vqdg/5Evmpk0+5FIqkGi3mHk3H
ZYjU2Sm/lxw9hTbEt7bU1lOdS7hJY0uYaGp5uGftzxrBcfumPUTPOSH58umY
8JSPh7jDZTIzP9qzBexqSstjlL6caEKdWYz99R83z1iP01mgq4x+oGbz2jTH
4bT5Y16NPNZB8/vkf0JfrYIdEXXwuVQj0dA2a0XzWQDK4isTn7H2Q67MgMFK
YGXT+fbm6j++e7FAWPZeadjNq2LK7UCjjJ6UfX5PbcHO9tE0dtSUkCjHAxL/
9e7ldfbF0y+e/DePydjawsqVFMVZMmLByMFvnOv+/qHllIZvs3eG28B9/NsK
FIvIOYpS6A8USL82ZYN6BFEIz5gLhbsW1nL/8fKgoWiYztT6ScEY403o5qJq
GtdWpfwSTfKw5vjcRqbxowHfHVweUGIxldBYkWXckjN2f6qyRjI4ah8qOVuZ
sbQU5tLcZDecZj/8gEVL2nDb69lBqoLjA5KJrx4QH1kLTEeBgupr4QRgOlhs
IyI3a27Xb4KzDF5QdLPTOlWc0pSwv8E6rdq+DTPevqWzOMRs+yh0JybDcYoR
RZyLCFj26UEElzmdIZPU0MGRgVEOnyTiiopQYMrphMeSQsUHF0gD2Q/7n7bg
YvxZPWk8/Je6z4uToKyGlDhQ20Xnx00o3ckPMbAZIUgrR1nDbqgnR9UVfpE9
unlK1cTnng7a9JSS6Y848CAYoP+epkN6/bkcnQ/7OGxObbdNluZ5k86v/4Yf
kHSI+SmOfnFp4J8HGWR/3OWOap0Z/ebXkS+VXG0a4pf+ynDiBzNDSyoVtb4L
87wl1Lm5JyN9Bh9dIh8YZvusKi0SWhpC8U5LThjwPnmNbfY+ztZCuXnKldkF
sDrjYzofI2e0fCjqcluqV5Co7rMiRl8jG5j24AWVgm5VBw3AXJwcODZTzhDy
/ylLkPkTxdcLce6BoByFco3ehz6vDZ8gp24B11eZo8384KqcvNfxo+SMq8ak
ihvSx+RUbQyfJfdNxgh8BVH6nXlfnCx9TcEx/U2kJB+bzi1CieKqhsz3MgF3
cUKZnJPn1HCsa2Ri/x8/QxVzWE7myBj2xYAVzXcPhPYqpukEv3Q5hKUNC/ba
En+hMT3PBNDPxEkqktIyTWnq5Pd8lCM980l24yjjoMWj86qfOuCz1no4j67M
DrKlnRFxI2GCkSrd0w93iORjYftG/ew4ZoSGfIX6wd/Dkhp+mUyRMhVpE+Ib
bniJu583vylrW5qpmRXZ0h9HCn04naeZTqVBCuLCZt0wpuqBil90liUuzUlj
TTHVxU+56EHqMDIYR8WHC2d+XMsoenscQxk9yhAf5l7KDi8GCv0PPXnLM3V3
yh1PahbyS0+R9XkAtHhWLqDG9Sy2XqB/5mIYBvI/CRBB1ykRkjaouLUPxnSi
8ZLQpx5MG0GSj8Z1EnI0/wvwv1dRzFIAAA==

-->

</rfc>
