<?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-01" 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-01"/>
    <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="04"/>
    <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:
H4sIAAAAAAAAA8Vca5PbRnb9zl+Bqv0QTS3JSLKd9TKbLY9Gkq2KHhNptNpN
KpUCgSbZKzxoNDAjuvTjc+6jG90gRl7bqYrK5eEDaNy+z3MfzdVqtXB93pT/
k1dtYzZZ3w1mUeS92bfdaZO5vly4YVtb52zb3JyOuOTFs5vnC3vs+GLXP374
8I8PHy+qvNlvMtMsFr3tK1z21vw42M7Upuld1u6y57nrs9dtb3cW62O1bNd2
2U2X7/BB9qzZ28aYzjb7DORkL9u8zJ7kWLXAR4t8u+3M7dyiTW+qRdkWTV7j
oSWW61d70+xXO/7K/+miG1cPHy3arWsr0xu3WQzHMucXv8voxSZ7/PDxN6uH
f1g9/DpbLPLO5HhuO/RE2iXeLe7a7uO+a4fjJnt++frm2UtcNfSHttssFtlq
kWW2cZvsr+vse9CBt0LaXwfjWiyhH7bdPm/sT8yJTfbDkN8Zi49Nndtqk9EO
PskN3x34u3XR1tHq12vc04bFr3H9c2P1s3TtJ6fePAUfzbj8YWiPuGNn7Hdb
fFvSt5MH/G2d/edhCA/4Gyj5kTggH6ZPuDrYJs9uTGV4Df+Unw7D6cdvvyvo
216+XBdNFj3k6Tp7acMzQKS8TVe/cXgumJC9b+yt6ZztT+Mz+rayIP+7Xi9a
m3LAQ6JnfFiDvlgQH4z90UJbw8dzm3nVbm0Vcayga+/0TtlSzZdM2HZFOxrZ
dnWgB8knc4/BlhKWVXYoHn31SB4w8Je0m8XCNrCWGvfemg0uf/v86qtH//Kt
vvzm228f6ss/fP1HvFwsVqtVlm9d3+VFv1jcHKzLYCQD6X9Wmh1szWX9wWSx
XbBB/hYzzR48z8keLpZZntWmwOatq/E8Z/eNKSEsvK5IiFlva1Odssb0ZE3w
M3k/uExNMStBUtHj+13X1kynv7A0t7Yw2Z3tD3gGPWFvaF26Rr8zn464WR4H
cy16emH7dSbEZW44HtuOtktb3YHvQ2d4NwWU3DjedBNxwC3h1/JtRTvs8qMt
s2PX9ngGXehACklL+FGeIHfwqSK+bD1f1rBBuufWlnRh1d6tKuyzKU5ZXhmQ
sgR92cFUR+c36kC6O7ZYEvIpPoIV2AQo+OgJdlOKzS3JkEg9qDSc6ZghHXie
Q1dhOHzT0XSsTGT0qiq1LUuo+wI+8EXTd205yO7w0DOFwEW/g8wL9oFYjpZ8
he9v9dsXdFuZn/7JwSQKSIBMExvwvBG662NlPgWxmubWdm1T6xZI1yypaq96
B2LzPWsp3y5SyMv82OeeTr+U6ATYA6EWne1BdbUmBS4tXZpX4cpoUXdyvanl
pnYH0YDXtSUlsg3plu0yz8GgVZFg3FCWuMdT6w52R/vwolrC9iNRrbNLPIkE
PFT9kpZ3ZpR7nZ9YhTswAMKLhAUF32MbvOMl6VNFS5ZBzqV13XBUjcUTYamB
kXhYO3S4CHGsUie0JsdAq9bEUzJzsgjTLbO67YwqoIO5znHskJN4wSkHxSAi
YOKsIg3ZLdsn2aS5bauBRYRoffmCWGQbby2kGy2/U85BTuSpGnOXuQI219kW
+wR7yDvBHf44GJIvOTXwB8wsyHSaohrEsPJuD99yhG4a3PDArPfrZfb1vz+5
WHpVBKUt/E9eVUFaRGFtlkxRLrKDTO/yroSLMHdYcDv0fu0djNcJ45wJumbV
ZlgGAArQjkgdq8rQVevsFfbe6/4Pdn9IhMuPv4XGeEVrTGEAu3r2iHT5yh0N
ayQ2D23C99ikejNaEkhs9fXDh9n326P48u+v3+Opz4cOkuhIpmxa5Lgg09RF
Tb0JXmJL1ejFvUENhYUJQechefKb/SHvVYXr3JG2LIPZEZ7KhWV8t6hPOdp3
JQ6JtAUAS3amKkyqYGKjq43xDxKNBdsdZN0hEA9QSNpwi1tr+xMjtRcZ8Z92
Ka6S6aVvaGu2GdoBusNsjaUAXNSJ04eQf1MstC4JgswnjX4uhL94bRhIcIfs
y70CJ25/GUlpeeZxQB7L1dYiWeMufHREFDC3sM7wkKYtSSkRmibRDc65Juwh
ZG1xuYFzk+jKXg1cSSjf5QWJiRWVvSIMpTSFpZxhVecfPYfEvcBv/x15g0CO
yHF3irHpyhm/T1gGaYk1an4gEyp1BPsLi1gyn2JYJ/6abZO4QIynYNvnH40Y
SZ4whC7fElKF7t1JNBhxBmKBBc1RsBJiW91SlhcgquRwp66MtADwAALFdQds
cS9+cXC8tOgf3Bws5rRMkAE51JylEtkgaxHz/iTyo0VGLxT4dsx7cLpxpBDB
EwFNcAgESVXdglxb16a0hM1Pa47qCe+uu7YA4zrAgtUMa1/BOUE2wLwvsQno
CP0ftMqnQikeeWtOjO5GZ/nADQXAmwvERjR6NCYGcCH4D4lpkE1LrgwasDqj
9ZjvPWHKrk12qdinEvc6hsO7nH0KvLUzNacnKeIbg7vIjLxTBEPp+Ted3e/F
+sMTWaGUMdk705AqPKB7ISVXwLeIljJGJurO3EMvPn2MpWewJvYJUSwnQo07
tFUJC4Wbwf7c0X4ke5VwCN1yYCixAQGot2ystCUnZBJl55btxUkbvhRIiAQb
NvwWwcnecujGGrrlL2wV98ntQfqd8QYf6UF+PFYn+oyChg9CF9AANd9mYtwd
k2FKdQndWXmAEf8OmQ/eN5ol7JgB6nETqbM1M9qDHSsAJ2qOkXqN1ighqjYI
XqX4kn7UidmFlQmO3U+DdAfrdTEnnZlmHncHQyofnIf5xAgD6F6Bldr4HScl
bYGYbT4xLOPb2YXFUmEy43RQWTd1MtGNrCVepMUAxjQTNUn4XrRDBWQBd0kY
nz6D7xsoCZghHk//M5kycmXBosBHFa6PcQeprF9K+Rm0SBU0k+x4mUjKM4TU
fsoG3lacFAsOASwE4cBZhaBauFRnCGPAQfhLiWbkSfPgYFK3SlMlrgcoGqSl
pxe/TCEZI4iApXZDIxaEGwFufL6wHIGNBAcfTRXwC/JKEFdVtVThK1UrOaJk
nKSpnyUUQf5FAqFjxAw9rBAtBNmbTwxNgSIDcCcPbLopqoTckPaakNbGiJeE
pUBn2/Y92GIK2k8Aaz6KhCKB5Dlk9TVQdJygSDYhrh7i+aG9w8pIZLy2TsiC
mz1wNkFFALiW2OEWiYgoQEe5a5ynrrM3jfH2wWAE0YSWtOJYK8idvxasx3Ci
AdsE6VPuSpTrJkyMhJJ4meaukV1IntrR2qTscDttCRL3VYuN6hru1BRwHL7s
RJKlLwghtBVpBHsYC1uSbJT3zOFD1QOxsQATWf9TRMfej8E4rqa09SMDq9KS
PmAp2lCBTVI4tw0VmfGfAeoOoczbMOtajGpZCZPk2YeI7dA5NsBX4HfLIp6I
1lMJpZJsD6l8S/Zzaw3SEIgYnou4xYEDRn0H2pAZ1hxtIFdlkw9Ou2oo+sF7
42PLl0BDTlllcg4O2OeRypKujysWtvm78fZKnJDtgSBAs4M6tZCSQhMHD32j
cD2bgljN+ZxUuDT/m7JhGxecKK7HVZVp2vEFALmcQjM10LiagQxC3PsX0KwH
EssZv0kO6c6leQnX7EZ46gG2BOd7RT46BV8UHJP0yFFymgiVmCuKzFTI4MPf
/nyZdMafP1qHZPEdm+NTo2XDTfYKRtm3nSKvc7ZPAZ6wnS2Dt0/bE7QxgRpU
k4zcGaVtPqF9vL4XNW8SCM2wO6mGllpzZYetYTqA0Xsz0gvJvjTx1Axyvfhq
7cHk5ZgKbkAbCR5UKzbkQITcDZbV2S29D8YVacYEROUJOyC9N1xcuR/bxjBy
KY47Va8RpE9ML6aCDNmRc+dUeyaT1ajLJWPJZH2KSAU/29y2FZX2gbPfEec8
BmZDAHQwneiCdyB03RE5dwKg86KD18hqeF9Oif2VNwgBCLDxpSXJi2ryu7E0
aSiG7klVuIiblxJ1lmqRRKcU6IMZFiHQUPGw7ahodo7Th6N6WGxlJ8UoX6kx
SXGf66pS+9GYyZ6GU+pcyFPj1p3GN6cFSKmCg+qJMEP9iyKx2PZTbk9k3+dA
igtO7IRFL3zLRYybwvhG7D7ZnbhZQ82LVd+umD82ujXf+uTRgxHl2C4mPy5j
TguTbH1nroAdBO2OcrPrjnygEQ/01oT9brJnVNsh3+6VdeIutDqUM19MqbIm
reAUOBAT2SHb1Sp7oyKkB6offT8SucnehT4LFG21p8KvGe0hXo18Vk5Od6XB
D0+nd5wEIozbL0Lu69CM+Rm4/Vo1Jb7BfxZ1dDz29GX1pChLnK+RP9LGXVxx
z8qBY05oz1TIvkVIkD+XRNrOt6gQfDycB74LaLWPgF5EUIT5BK0armBLi0LE
KI6D2BVCDJOKNJ1Q0mmTgMho7QAirXEJjPSVmDJZr4D+4tEs9ZDALxU8MuBn
X8zPZIuJsknCXeyFTcOZLMmuhrZ1TWC1tO58uFrBBEfQ8hwE0bqb7IOWi89c
unRc6CJFWeSy6LFbybxv2YmMdWJt71gysgjNeWqScjS7RAY4cTvNdykinBQL
jiALng0YzDUomLxUWFOmTuFYUCFf9Y4L1Ps2r0bo7Ibt6puHtQtMn4WMRn2A
PPy+xy0FiHHxwuTdKgXtcXcz2qL3yLhbzYLuH8BCyv3A9F+Cn2LDfLRmiZMK
piod37RJ3kmqu4dr71jQSFmbkZkt5TGC7hTp4JK00byT2oOvNSZVc9+OpS8Z
SXmXez+iSmljZaAId4hK8exstda4DFINAZNRUCeISd1tEBv5ueGYXZOibwKv
UudOWMqjxFHnx8ob+dnOrBD7qQHgDoZCJS9L9uNtRtT//ZdwVqRHy3tcF8Oc
CDFJ45zr7eMj3TJgPw0UnP4R6uo4dfZhiq9xiqC8x2YNpLZTcMssbwlkwUKy
qzlEMbYXFJBRNDajKFgpUmejfmIljQLvepaaxfUk51UbSy1kpAKjyuAz+hbp
eLs/zQOSt2y2XsJvleIxtJMTcIbK+9kDMIsgenAMFwFUxcGJfauUZsrsnbq7
K+mLwa0hOwkhzsdryke1zBK5d1roWXDR8zjgmUpHxZwWpgbhCLWMyVobY0qC
4ZIeswVyp8JnbHe58ugFfPNeOnWpc+Es5ZmvM44eZSzSuzkXSZayFZe/V+9B
C92Sc4f3C4XLePKjOJjaZ6rMS8XFY10qlHt8GCtOm9BNeauK/uD527cXc8gy
YFhcQAm9dg8lo58zd9/WiR03+ZXg18cevwCZNi4Nxn5hN+nIy2xKrf1raV5/
ARedTySQovyASPyOhg1X29PcfmUoRMToB+6ufVH7ilpJ3V5mInxh97zMMc+Z
aZFUM1GWuu/0zPsj2Zjft99XEUyF9vWKsM+KHLEnewP9HCc6pDjy7OrVNWMP
zn84R1uJl9Cthl3NtVh9CCeLGKE8HMzYTI3rCJI6sknlgSVU7uZQShZ2VgzR
jqRK1WePXwLezwlvXkmP5megd3rpHEJRVY/7Pql0cy1jxVWlhEUyw6ONx7zR
vUq1laasJjNkbLhn81MeEK4ZZZ5vfJkMSajTKKkmyP0CnW3S9rmfQZtrvP9j
xiqIDTDfamXGN5CmPdQYjJNmcG7AbzmT0/LiWG2BXKXr8r7hRCVOPQ6gi1JZ
+ps9MLBXvMGfi1Q6cYtGElws0jipRuYnKLmWh26uri+Wk3YLt+Qk5XjJ136V
PfD84ZvTh62zd9KTKaj0upQOPrwBt5vOhlZICtsBUEFmM5RlfpABXMgLM5VH
NOOXxHxWE0ekUKmYuCkrR4XepOaYFpR9jXSxuMw+mtPYXKDbEm5q00CbBWmC
MLapfcH2TG1pBuG2tUn5WPs73Dc8Dn08PpY2Fe4Ta9ph8G2BHWL0lnsbnYKL
qI0R+glkG5RTSY16673MTB/o59osi1+QQaR+hjqKNgIK8yMiVJ6/jwNal3Mh
5yYhHmkwgqp9G05TrkZhRPXd1xNnM04dYZ+1FH8n7jpUdQauSxKuEM9yGvsO
seiPreU21Ady89HniZ+f4HR8NyZI9EDHTYtoMuWcQ+JYfb8nhRweJ4c2ZVT6
GhOapMIkNRFfC1nqEAIBG+CI0E4bK8q+d+7LZyMipdrXl4vab/zgwNRiUiZ9
ad8BIIS00Ykvi4t8cYlz9C/iPigeUUrB6qV17HZCVEhkJMqfeyAaGKDpCNDQ
cehXrzbyOHH7o5+iTt2C8kcKzpxE+WnnJ/57QivYKWyVChRGBjDoeITYfZIu
jtFAHqg2o+6dCaQMV1s64z6mvR0e9GCkFWhCtHca+tjVBuOQuvJ0V2HMk8vQ
YeBKkCo9YevabjvpHGr+LyoQu8rRbau/mSZh81Z+rjRhxM/Pskv993wIKx4q
n0cI2MTHBn5por9U9mnlL8IglzWmibAOX3Wdznr6EKiARaZPIKr6SLWPrdm1
3ZmZgBD4BnK/q+zSd6upRUPyp78xS16FOb05nni1Dk3v6DHxZHcyY6W9LoiK
geBYm/K80WDBvVhtD0aqsjWH/Na2XQQG1K9OAvZ9Q/9SEorCucxLEjt8dlxm
16JCL6FCm2SSkhF8LDSe8+ekUvPaUPg/55fo8Hk8BxuiCaMZ+XpfsJ3aOsc3
Nth4+NKb59KrQEQwV6oobnnHzpLw0ThOv9OMO47Avy7nDrl2EpSj+syvSLhv
AjIVtJlQ+YDghPmUU/a5YbQ6p8TWjcPdciwlQlC4KSHXoyAZJzYu9psehxK8
JsPFrQyjpgmJDIDG41gMxzwM035DND1Lj+jsUerurKgeWidmG+99kyWzXxzj
uL2JHNXEIH0eNFNzTgamIa5bm8+wTaYjKFKG6eLJDn2ndIxX4sxkatdFBSya
3dVpsHSqiOqXUoeg8ZV5ELmCjh5p5qWPHVdC64NnV69nZU+aOlYnkMq/TnNT
LqRAh5uhyrulbtQHgDYBZ3rS6dwRwGVsO6p3Bk/nR6mlz+rZQInMqVVMNMm4
vHVW1cD2wjHqB03n6G926+5XhsUiG//R1ZfZig4H0YWPxpePx5dfyUu69kl8
8+fsl/z7vJj78N/m/tGBgpmP//x5QWb0K5/OPNA3f/p9/A8Cz6k27NO/36f/
Pi+8C/lte/68mvtHe535+M+z7Fr8X/DQ5yzT3Xz+04pYQBxYreb2mfIwWXR2
a9G/lIfxk36Wob+Jh/dWta6oWSfO5LJp4FULNvpkJEI99a05xcVY6Vr7tJb6
hBzU/MG8nn0qD3WO6RwVvPUYQpWM0YfBcCBZJSMrgCGoDBnApCfVTvusoa/l
iaA6lKB4+Ii4liKdYzrv0J+Ocp7gbPlTkutoVUezYGaAyXvpIPoCaehuL0Px
iVq9VNs0fbG+kM6sEcKoO6tbRE5at9yAjKLMv/IIC+WegcRkwEL37Abbc+GS
2JmMF1BkCqjixfdchn2CP2OiD7Is12U1qvKQ8BJx3oB8gIiltMq0Fg3ROz7I
1oO2xYeDrcykvFW2FJ1af9bWTxQXySPpzCfVPUjikiOPehFNVIeqvdQ+qfly
oGTtbI7Dn7YYuPxyHEvzoxY7PzkTZrEWejwMl+XVyVnt9CZD8rw3qg8X5A3x
+ubJUykMv/PD1JOjIV57n4Z1FoubcViR0XE8szspUowqrgczmVmUc9d0P6VK
tF94546LZcxjYuCWUFDecR3hTmaHTelUyfiHDig9+EmmAPwsUhj3VuDh/OCm
r+s6Dv5tI5U2WnZHBwijGB4NlU/2Mlqy1DFaZ0ZTNYpIKNGOptNpGAgEllRl
bLP9YGkcduBJWmZK0pOAXRHq4F4EBf83Q79qdyuRzDPtp0gtbNd6aBHtJxfc
7/CQjvgy9PTyH97VqCm+QGR8D4dWzpGD1MHMVf7UZj6NFsnT2NT/5HHkqA3S
dpPBf3xJIKgwTlG9tLafcTofnfuhzap/IvK1mhr5FX/ALhlBHhvY4zhvXIji
kxN6ygY+pa1CDUxA+T+PR2xoJJWRIbdgeKaET5cms4mibeNcvyP/pgktdlJW
Z3wiVvTQ7mAVcRm1HidK+9bzL4dq1CtpPI/ER2dYFuPJngkDSSDFeDCpq/lH
Azi5+mSKwZ8fGmfy+GDQeb3RD1f6wDHTsjiv4TPxnFHpPLG2ky/48HSvR+tK
c6zaE6nHKnhYbsFAElS96q2onpY2GGbQ1NFYczhWOVyHLxZ4N3OPEaSnZjgN
Vju7pMdreek6OPEPULWp5eX+ytTs7vMl8gMnX3IpFEk1Wkw9mg7JEKmTs33P
OXoKbYhvbakNpzqXcJPGljDH1PJIz9KfMILj9q16iJ4zQfLl4+HgMQsPcYeL
Y2Z6oGcN2NWUlocnfRHRhOqyGPvLv6yesB6nE0CXGf0szeqlafb9YfWXvBp4
mIOm9sn/hG5aBTsi6uBzqTKioW3SgOYTAJS7VyY+We1HW5kBvZXAyqbz5vry
P94/myEse6c0bKa1MOV2oFEGTsouv6Nm4NF20Qx21IqQKMdjEf/19vlV9s3j
bx7+Nw/H2NrCypUUxVkyWMHIwW+cq/3+oeWYfK+zt4abv138iwoUi8g5ilLo
zxJIlzZlg3oEUQjPmDOFuxLWctfx/HihaJhO0vr5wBjjjejmrFYaV1Sl6BLN
77Dm+LRGZvCjsd4NXB5QYjEWzliRZciS83R/lrJGHjho9yk5UZmxtBTm0rTk
sT9Mfu4Bi5a04bbTE4NU+8YHJBNfMyA+shaYIwUKqqqFc3/pOLGNiFwtuUm/
Cs4yeEHRzaNWp+KUpoT99dZprfZ1mOz2jZzZ0WXbRaE7MRmOU4wo4lxEwLJP
DyK4zOkMmaSGDo4MjHL4/BDXUYQCU47nOuYUKj6uQBrIftj/oAWX4E/qSeOR
v9R9np3/ZDWkxIGaLTo1bkLBTn5+gc0IQVo5yhp2TZ04qqnwi+zB9WOqIT71
dNCmx5RMf7qBx78A/bc0E9Lpj+ToVNinfnVoj+tkaZ4yOfr1X/EDkr4wP8XR
7yz1/KMgveyPe9tRhTOjX/ra86WSq42j+9JV6Q/8YGZoSQWi1vdenraEOld3
ZKRP4KNL5AP9ZJ9VpaVBS6Mn3mnJuQLeJ6+xzt7F2VooMo+5MrsAVmd8TKdi
5GSWD0XH3JbqFSSq+6yI0dfABqadd0GloFvVQQMwlyR7js2UM4T8f8wSZOpE
8fVMnLsnKEehXKP3rstrw+fGqUfAVVXmaDM9rirn7XXoKDnZqjGp4jb0PjlL
G8NnyX2T4QFfN5QuZ94VB0tfU3BMfwkpycfG04pQoriqIVO9TMBtnFAmp+M5
NRzqGpnY/8ePT8UclvM4Mnx9NlZFU909ob2KaTrAL52PXmmbgr22xF9oTMeT
APTjcJKKpLSMs5k67z0d4EhPepLdOMo4aPHolOqXjvUstQrOAyuT42tpP0Tc
SJhbpPr2+HMdIvlY2L49PzmEGaEhX5e+91ewpHJfJrOjTEXaeviB21zi7qct
b8ra5iZpJkW29CeRQvdNp2jGs2iQgriwSQ+Mqbqn4hedYIlLc9JOU0x19gMu
enw6DArGUfH+wpkf0jKK3i5iKKMHGOIj3HPZ4dkYof95J295pj4ecsfzmYX8
vlNkfR4AzZ6QC6hxOYmtZ+ifuRhGgPwPAUTQdUyEpPkpbu2jMUfReEnoUw+m
7R/JR+M6CTma/wXWtSjQwlIAAA==

-->

</rfc>
