<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.4 20241031//EN" "JATS-journalpublishing1-4.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" article-type="research-article" dtd-version="1.4" xml:lang="en">
  <front>
    <journal-meta>
      <journal-id journal-id-type="publisher-id">ijcns</journal-id>
      <journal-title-group>
        <journal-title>International Journal of Communications, Network and System Sciences</journal-title>
      </journal-title-group>
      <issn pub-type="epub">1913-3723</issn>
      <issn pub-type="ppub">1913-3715</issn>
      <publisher>
        <publisher-name>Scientific Research Publishing</publisher-name>
      </publisher>
    </journal-meta>
    <article-meta>
      <article-id pub-id-type="doi">10.4236/ijcns.2026.197007</article-id>
      <article-id pub-id-type="publisher-id">ijcns-154295</article-id>
      <article-categories>
        <subj-group>
          <subject>Article</subject>
        </subj-group>
        <subj-group>
          <subject>Computer Science</subject>
          <subject>Communications</subject>
        </subj-group>
      </article-categories>
      <title-group>
        <article-title>Telemetry-Aware Risk-Adaptive Routing for Link-Flooding Resilience in Software-Defined Networks</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author" corresp="yes">
          <contrib-id contrib-id-type="orcid">0009-0004-0661-043X</contrib-id>
          <name name-style="western">
            <surname>Sethupathy</surname>
            <given-names>Utham Kumar Anugula</given-names>
          </name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <name name-style="western">
            <surname>Ananthanarayanan</surname>
            <given-names>Vijayanand</given-names>
          </name>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
      </contrib-group>
      <aff id="aff1"><label>1</label> Independent Researcher, Senior Member IEEE, Alumni, Nanyang Technological University, Atlanta, USA </aff>
      <aff id="aff2"><label>2</label> Independent Researcher Alumni, Farleigh Dickinson University, Atlanta, USA </aff>
      <author-notes>
        <fn fn-type="conflict" id="fn-conflict">
          <p>The authors declare no conflicts of interest regarding the publication of this paper.</p>
        </fn>
      </author-notes>
      <pub-date pub-type="epub">
        <day>29</day>
        <month>07</month>
        <year>2026</year>
      </pub-date>
      <pub-date pub-type="collection">
        <month>07</month>
        <year>2026</year>
      </pub-date>
      <volume>19</volume>
      <issue>07</issue>
      <fpage>97</fpage>
      <lpage>112</lpage>
      <history>
        <date date-type="received">
          <day>10</day>
          <month>06</month>
          <year>2026</year>
        </date>
        <date date-type="accepted">
          <day>28</day>
          <month>07</month>
          <year>2026</year>
        </date>
        <date date-type="published">
          <day>31</day>
          <month>07</month>
          <year>2026</year>
        </date>
      </history>
      <permissions>
        <copyright-statement>© 2026 by the authors and Scientific Research Publishing Inc.</copyright-statement>
        <copyright-year>2026</copyright-year>
        <license license-type="open-access">
          <license-p> This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license ( <ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">https://creativecommons.org/licenses/by/4.0/</ext-link> ). </license-p>
        </license>
      </permissions>
      <self-uri content-type="doi" xlink:href="https://doi.org/10.4236/ijcns.2026.197007">https://doi.org/10.4236/ijcns.2026.197007</self-uri>
      <abstract>
        <p>Adaptive-routing evaluations can overestimate resilience when controllers are assumed to know attack locations. This study presents telemetry-aware risk-adaptive routing (TARA), in which the controller receives only delayed, noisy utilization and delay measurements processed by an exponentially weighted detector with explicit false positives, false negatives, and calibration error. Twenty-four paired synthetic 36-node backbones were evaluated across three attack loads, three detector-quality settings, three baselines, full TARA, and four structural ablations, producing 1728 trials. Under 100% target-capacity attack load and moderate detection, full TARA delivered 97.25% of demand (SD 1.20) versus 93.18% (SD 2.52) for reactive rerouting. The paired improvement was 4.07 percentage points (95% CI 3.39 to 4.74). Its 95th-percentile path latency was 27.15 ms, a paired difference of −6.47 ms (95% CI −7.94 to −5.00) relative to reactive routing. Delivery changed from 97.89% with strong detection to 96.71% with weak detection. Ablations identify path diversity as the dominant source of benefit; risk, overlap control, and utilization prediction produce comparatively modest, condition-dependent differences. These are controlled simulation results, not measurements from a production network.</p>
      </abstract>
      <kwd-group kwd-group-type="author-generated" xml:lang="en">
        <kwd>Software-Defined Networking</kwd>
        <kwd>Link-Flooding Attack</kwd>
        <kwd>Telemetry</kwd>
        <kwd>Resilient Routing</kwd>
        <kwd>Sensitivity Analysis</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec1">
      <title>1. Introduction</title>
      <p>Software-defined networking separates forwarding behavior from logically centralized control and enables systematic path changes [<xref ref-type="bibr" rid="B1">1</xref>]. Its programmability also enlarges the consequences of inaccurate or delayed network state, so resilience claims must identify exactly what the controller can observe [<xref ref-type="bibr" rid="B2">2</xref>].</p>
      <p>Low-rate link-flooding attacks can congest selected transit links without sending traffic directly to the victim [<xref ref-type="bibr" rid="B3">3</xref>]. Defenses that perturb routes can increase attacker cost, but their benefit depends on whether congestion can be inferred quickly enough [<xref ref-type="bibr" rid="B4">4</xref>]. Evaluations that disclose the attack set or instantaneous attack load to a routing controller risk overstating deployable resilience.</p>
      <p>This study asks how much service protection risk-adaptive path diversity provides when attack state is hidden and the controller receives only imperfect telemetry. Attack ground truth exists only in the traffic generator and evaluator; routing decisions use noisy delayed measurements, detector output, and controller state.</p>
      <p>The contributions are an observable telemetry and detection layer; fair information timing for all policies; detector-quality sensitivity; four structural ablations; and paired confidence intervals over fixed seeds. <xref ref-type="fig" rid="fig1">Figure 1</xref> summarizes the information boundary and the controller workflow.</p>
      <fig id="fig1">
        <label>Figure 1</label>
        <graphic xlink:href="https://html.scirp.org/file/9702666-rId15.jpeg?20260929023036" />
      </fig>
      <p><bold>Figure 1.</bold> Information flow from generated traffic through noisy delayed telemetry to detector-derived risk and routing decisions.</p>
    </sec>
    <sec id="sec2">
      <title>2. Related Work</title>
      <p>Software-driven wide-area traffic engineering demonstrated centralized allocation over multiple paths [<xref ref-type="bibr" rid="B5">5</xref>], while OSPF weight optimization established a classical link-cost baseline [<xref ref-type="bibr" rid="B6">6</xref>]. These systems motivate load-aware routing but do not by themselves model adversarial uncertainty.</p>
      <p>Disjoint-path construction [<xref ref-type="bibr" rid="B7">7</xref>] and loopless <italic>k</italic>-shortest path enumeration [<xref ref-type="bibr" rid="B8">8</xref>] provide the topology-only diversity used in this study. TARA uses the same candidate set as its ablations, preventing candidate-generation differences from confounding the comparison.</p>
      <p>Exponentially weighted state estimation is a standard way to smooth noisy time series [<xref ref-type="bibr" rid="B9">9</xref>]. Intrusion-detection guidance distinguishes sensor evidence, detection decisions, and ground truth and emphasizes false alarms and missed detections [<xref ref-type="bibr" rid="B10">10</xref>]. Those distinctions determine the detector model.</p>
      <p>Congestion-control principles [<xref ref-type="bibr" rid="B11">11</xref>], differentiated-services architecture [<xref ref-type="bibr" rid="B12">12</xref>], and the end-to-end argument [<xref ref-type="bibr" rid="B13">13</xref>] caution against treating a controller as omniscient. Simulation studies also require explicit scope because Internet behavior is difficult to reproduce in full [<xref ref-type="bibr" rid="B14">14</xref>]. The present model therefore isolates route selection and telemetry quality rather than claiming Internet-scale realism.</p>
      <p>Recent work has combined link-flooding prevention with alternate-path and topology-obfuscation mechanisms [<xref ref-type="bibr" rid="B15">15</xref>], measured SD-WAN delay through in-band telemetry [<xref ref-type="bibr" rid="B16">16</xref>], and used monitored data-plane state for reliable path prediction [<xref ref-type="bibr" rid="B17">17</xref>]. Scalable software-defined sensor networks likewise expose controller-update and state-prediction overheads [<xref ref-type="bibr" rid="B18">18</xref>]. Link verification based on observed latency [<xref ref-type="bibr" rid="B19">19</xref>] and credibility-oriented link-flooding mitigation [<xref ref-type="bibr" rid="B20">20</xref>] reinforce the importance of detection uncertainty. Control-plane resilience in SD-WANs [<xref ref-type="bibr" rid="B21">21</xref>] and flooding defenses in information-centric networks [<xref ref-type="bibr" rid="B22">22</xref>] provide complementary perspectives on failure containment and adversarial traffic.</p>
    </sec>
    <sec id="sec3">
      <title>3. System Model and Information Boundary</title>
      <p><xref ref-type="fig" rid="fig2">Figure 2</xref> shows one generated 36-node backbone. Red links are attack targets in the evaluator. The controller never receives those labels; the coloring exists only to explain the simulated ground truth.</p>
      <p><bold>Table 1</bold> separates variables available to the traffic generator, telemetry process, controller, and evaluator. This separation is enforced in the executable code: routing functions accept measured risk and utilization state but not the attack dictionary.</p>
      <p><bold>Table 1.</bold> Information boundary.</p>
      <table-wrap id="tbl1">
        <label>Table 1</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Component</bold>
              </td>
              <td>
                <bold>Available state</bold>
              </td>
              <td>
                <bold>Unavailable state</bold>
              </td>
            </tr>
            <tr>
              <td>Traffic generator</td>
              <td>Demand matrix; attack schedule</td>
              <td>Controller estimate</td>
            </tr>
            <tr>
              <td>Telemetry process</td>
              <td>Actual utilization and delay for measurement generation</td>
              <td>Routing objective</td>
            </tr>
            <tr>
              <td>Controller</td>
              <td>Delayed noisy measurements; detector risk; topology</td>
              <td>Attack labels; attack load; future measurements</td>
            </tr>
            <tr>
              <td>Evaluator</td>
              <td>Ground truth and delivered traffic</td>
              <td>No decision authority</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
      <p>For link <italic>e</italic> and epoch <italic>t</italic>, Equation (1) defines measured utilization and delay as physical values plus zero-mean detector-scenario noise.</p>
      <disp-formula id="FD1">
        <label>(1)</label>
        <mml:math>
          <mml:mrow>
            <mml:msub>
              <mml:mover accent="true">
                <mml:mi>u</mml:mi>
                <mml:mo>˜</mml:mo>
              </mml:mover>
              <mml:mrow>
                <mml:mi>e</mml:mi>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mi>t</mml:mi>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
            </mml:msub>
            <mml:mo>=</mml:mo>
            <mml:msub>
              <mml:mi>u</mml:mi>
              <mml:mrow>
                <mml:mi>e</mml:mi>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mi>t</mml:mi>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:msubsup>
              <mml:mi>ε</mml:mi>
              <mml:mrow>
                <mml:mi>e</mml:mi>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mi>t</mml:mi>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
              <mml:mi>u</mml:mi>
            </mml:msubsup>
            <mml:mo>;</mml:mo>
            <mml:msub>
              <mml:mover accent="true">
                <mml:mi>d</mml:mi>
                <mml:mo>˜</mml:mo>
              </mml:mover>
              <mml:mrow>
                <mml:mi>e</mml:mi>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mi>t</mml:mi>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
            </mml:msub>
            <mml:mo>=</mml:mo>
            <mml:msub>
              <mml:mi>d</mml:mi>
              <mml:mrow>
                <mml:mi>e</mml:mi>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mi>t</mml:mi>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
            </mml:msub>
            <mml:mo>+</mml:mo>
            <mml:msubsup>
              <mml:mi>ε</mml:mi>
              <mml:mrow>
                <mml:mi>e</mml:mi>
                <mml:mrow>
                  <mml:mo>(</mml:mo>
                  <mml:mi>t</mml:mi>
                  <mml:mo>)</mml:mo>
                </mml:mrow>
              </mml:mrow>
              <mml:mi>d</mml:mi>
            </mml:msubsup>
          </mml:mrow>
        </mml:math>
      </disp-formula>
      <p>Noise standard deviations are 0.025, 0.060, and 0.110 utilization units and 0.35, 0.75, and 1.25 ms for strong, moderate, and weak detection.</p>
      <fig id="fig2">
        <label>Figure 2</label>
        <graphic xlink:href="https://html.scirp.org/file/9702666-rId18.jpeg?20260929023037" />
      </fig>
      <p><bold>Figure 2.</bold> Representative synthetic backbone. Red links are evaluator-only attack ground truth and are not exposed to any routing policy.</p>
    </sec>
    <sec id="sec4">
      <title>4. Telemetry Derived TARA</title>
      <sec id="sec4dot1">
        <title>4.1. Delayed EWMA Detector</title>
        <p>The detector converts delayed utilization and delay measurements into bounded normalized anomaly scores. These quantities are denoted as anomaly scores rather than statistical z-scores because they are referenced to fixed operating thresholds rather than estimated sample means and standard deviations. For delayed measured utilization (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mover accent="true"><mml:mi> u </mml:mi><mml:mo> ˜ </mml:mo></mml:mover><mml:mi> e </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ) and delayed measured latency (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mover accent="true"><mml:mi> d </mml:mi><mml:mo> ˜ </mml:mo></mml:mover><mml:mi> e </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ), the two anomaly components are</p>
        <disp-formula id="FD2">
          <label>(2)</label>
          <mml:math>
            <mml:mtable columnalign="left">
              <mml:mtr>
                <mml:mtd>
                  <mml:msup>
                    <mml:mi>a</mml:mi>
                    <mml:mi>u</mml:mi>
                  </mml:msup>
                  <mml:msub>
                    <mml:mrow>
                    </mml:mrow>
                    <mml:mi>e</mml:mi>
                  </mml:msub>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mi>t</mml:mi>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                  <mml:mo>=</mml:mo>
                  <mml:mi>c</mml:mi>
                  <mml:mi>l</mml:mi>
                  <mml:mi>i</mml:mi>
                  <mml:mi>p</mml:mi>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mrow>
                      <mml:mrow>
                        <mml:mrow>
                          <mml:mrow>
                            <mml:mo>(</mml:mo>
                            <mml:mrow>
                              <mml:msub>
                                <mml:mover accent="true">
                                  <mml:mi>u</mml:mi>
                                  <mml:mo>˜</mml:mo>
                                </mml:mover>
                                <mml:mi>e</mml:mi>
                              </mml:msub>
                              <mml:mrow>
                                <mml:mo>(</mml:mo>
                                <mml:mi>t</mml:mi>
                                <mml:mo>)</mml:mo>
                              </mml:mrow>
                              <mml:mo>−</mml:mo>
                              <mml:mn>0.62</mml:mn>
                            </mml:mrow>
                            <mml:mo>)</mml:mo>
                          </mml:mrow>
                        </mml:mrow>
                        <mml:mo>/</mml:mo>
                        <mml:mrow>
                          <mml:mn>0.75</mml:mn>
                          <mml:mo>,</mml:mo>
                          <mml:mn>0</mml:mn>
                          <mml:mo>,</mml:mo>
                          <mml:mn>1</mml:mn>
                        </mml:mrow>
                      </mml:mrow>
                    </mml:mrow>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                </mml:mtd>
              </mml:mtr>
              <mml:mtr>
                <mml:mtd>
                  <mml:msup>
                    <mml:mi>a</mml:mi>
                    <mml:mi>d</mml:mi>
                  </mml:msup>
                  <mml:msub>
                    <mml:mrow>
                    </mml:mrow>
                    <mml:mi>e</mml:mi>
                  </mml:msub>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mi>t</mml:mi>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                  <mml:mo>=</mml:mo>
                  <mml:mi>c</mml:mi>
                  <mml:mi>l</mml:mi>
                  <mml:mi>i</mml:mi>
                  <mml:mi>p</mml:mi>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mrow>
                      <mml:mrow>
                        <mml:mrow>
                          <mml:mrow>
                            <mml:mo>(</mml:mo>
                            <mml:mrow>
                              <mml:msub>
                                <mml:mover accent="true">
                                  <mml:mi>d</mml:mi>
                                  <mml:mo>˜</mml:mo>
                                </mml:mover>
                                <mml:mi>e</mml:mi>
                              </mml:msub>
                              <mml:mrow>
                                <mml:mo>(</mml:mo>
                                <mml:mi>t</mml:mi>
                                <mml:mo>)</mml:mo>
                              </mml:mrow>
                              <mml:msub>
                                <mml:mi>ℓ</mml:mi>
                                <mml:mi>e</mml:mi>
                              </mml:msub>
                              <mml:mo>−</mml:mo>
                              <mml:mn>1.15</mml:mn>
                            </mml:mrow>
                            <mml:mo>)</mml:mo>
                          </mml:mrow>
                        </mml:mrow>
                        <mml:mo>/</mml:mo>
                        <mml:mrow>
                          <mml:mn>2.2</mml:mn>
                          <mml:mo>,</mml:mo>
                          <mml:mn>0</mml:mn>
                          <mml:mo>,</mml:mo>
                          <mml:mn>1</mml:mn>
                        </mml:mrow>
                      </mml:mrow>
                    </mml:mrow>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                </mml:mtd>
              </mml:mtr>
            </mml:mtable>
          </mml:math>
        </disp-formula>
        <p>where (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> ℓ </mml:mi><mml:mi> e </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ) is the nominal propagation latency of link (<italic>e</italic>). Detector evidence is</p>
        <disp-formula id="FD3">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>x</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mi>max</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:msubsup>
                    <mml:mi>a</mml:mi>
                    <mml:mi>e</mml:mi>
                    <mml:mi>u</mml:mi>
                  </mml:msubsup>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mi>t</mml:mi>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                  <mml:mo>,</mml:mo>
                  <mml:msubsup>
                    <mml:mi>a</mml:mi>
                    <mml:mi>e</mml:mi>
                    <mml:mi>d</mml:mi>
                  </mml:msubsup>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mi>t</mml:mi>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>The utilization baseline of 0.62 represents the nominal utilization level above which congestion evidence begins to accumulate. For delay, evidence begins when measured latency exceeds 1.15 times nominal propagation latency. Both signals are clipped to [0, 1].</p>
        <p>A detector-quality-specific calibration function is applied to the anomaly evidence:</p>
        <disp-formula id="FD4">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>C</mml:mi>
                <mml:mi>q</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>x</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:msub>
                <mml:mi>c</mml:mi>
                <mml:mi>q</mml:mi>
              </mml:msub>
              <mml:mi>x</mml:mi>
              <mml:mo>+</mml:mo>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mn>1</mml:mn>
                  <mml:mo>−</mml:mo>
                  <mml:msub>
                    <mml:mi>c</mml:mi>
                    <mml:mi>q</mml:mi>
                  </mml:msub>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mn>0.10</mml:mn>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>where (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> c </mml:mi><mml:mi> q </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ) is 0.95, 0.80, or 0.62 for the strong, moderate, and weak detector settings, respectively. Link risk is then updated using</p>
        <disp-formula id="FD5">
          <label>(3)</label>
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>r</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mn>0.60</mml:mn>
              <mml:msub>
                <mml:mi>r</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mi>t</mml:mi>
                  <mml:mo>−</mml:mo>
                  <mml:mn>1</mml:mn>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>+</mml:mo>
              <mml:mn>0.40</mml:mn>
              <mml:msub>
                <mml:mi>C</mml:mi>
                <mml:mi>q</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>x</mml:mi>
                    <mml:mi>e</mml:mi>
                  </mml:msub>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mrow>
                      <mml:mi>t</mml:mi>
                      <mml:mo>−</mml:mo>
                      <mml:msub>
                        <mml:mi>δ</mml:mi>
                        <mml:mi>q</mml:mi>
                      </mml:msub>
                    </mml:mrow>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>where (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> δ </mml:mi><mml:mi> q </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ) is the detector delay.</p>
        <p>To simulate imperfect detection, an attack-associated evidence value is attenuated to 12% of its original magnitude when a configured false-negative event occurs. For an unattacked link experiencing a configured false-positive event, alert-like evidence between approximately 0.58 and 0.93 is injected before calibration. These stochastic error events use the probabilities reported in <bold>Table 2</bold>.</p>
        <p>For reporting detector precision and recall, a link is classified as detector-positive when (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> r </mml:mi><mml:mi> e </mml:mi></mml:msub><mml:mrow><mml:mo> ( </mml:mo><mml:mi> t </mml:mi><mml:mo> ) </mml:mo></mml:mrow><mml:mo></mml:mo><mml:mo> ≥ </mml:mo><mml:mo></mml:mo><mml:mn> 0.50 </mml:mn></mml:mrow></mml:math></inline-formula> ). Precision and recall are computed over link-epoch decisions during attack-active evaluation epochs by comparing this detector output with evaluator-only attack ground truth. Ground-truth attack labels are used only by the simulation generator to impose controlled false-negative/false-positive events and by the evaluator to score detector performance; they are never supplied to the routing controller.</p>
        <p><bold>Table 2.</bold>Detector quality scenarios.</p>
        <table-wrap id="tbl2">
          <label>Table 2</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Quality</bold>
                </td>
                <td>
                  <bold>Utilization noise SD</bold>
                </td>
                <td>
                  <bold>Delay noise SD</bold>
                </td>
                <td>
                  <bold>False positive</bold>
                </td>
                <td>
                  <bold>False negative</bold>
                </td>
                <td>
                  <bold>Delay</bold>
                </td>
              </tr>
              <tr>
                <td>Strong</td>
                <td>0.025</td>
                <td>0.35 ms</td>
                <td>1%</td>
                <td>5%</td>
                <td>1 epoch</td>
              </tr>
              <tr>
                <td>Moderate</td>
                <td>0.060</td>
                <td>0.75 ms</td>
                <td>4%</td>
                <td>15%</td>
                <td>2 epochs</td>
              </tr>
              <tr>
                <td>Weak</td>
                <td>0.110</td>
                <td>1.25 ms</td>
                <td>10%</td>
                <td>30%</td>
                <td>3 epochs</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
      </sec>
      <sec id="sec4dot2">
        <title>4.2. Utilization Prediction and Path Cost</title>
        <p>For a candidate path (<italic>p</italic>), let</p>
        <disp-formula id="FD6">
          <mml:math>
            <mml:mrow>
              <mml:mi>L</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>p</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:munder>
                <mml:mstyle mathsize="140%" displaystyle="true">
                  <mml:mo>∑</mml:mo>
                </mml:mstyle>
                <mml:mrow>
                  <mml:mi>e</mml:mi>
                  <mml:mo>∈</mml:mo>
                  <mml:mi>p</mml:mi>
                </mml:mrow>
              </mml:munder>
              <mml:msub>
                <mml:mi>ℓ</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>denote nominal propagation latency,</p>
        <disp-formula id="FD7">
          <mml:math>
            <mml:mrow>
              <mml:mi>U</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>p</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:munder>
                <mml:mrow>
                  <mml:mi>max</mml:mi>
                </mml:mrow>
                <mml:mrow>
                  <mml:mi>e</mml:mi>
                  <mml:mo>∈</mml:mo>
                  <mml:mi>p</mml:mi>
                </mml:mrow>
              </mml:munder>
              <mml:mrow>
                <mml:mo>[</mml:mo>
                <mml:mrow>
                  <mml:msub>
                    <mml:mover accent="true">
                      <mml:mi>u</mml:mi>
                      <mml:mo>^</mml:mo>
                    </mml:mover>
                    <mml:mi>e</mml:mi>
                  </mml:msub>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mrow>
                      <mml:mi>t</mml:mi>
                      <mml:mo>+</mml:mo>
                      <mml:mn>1</mml:mn>
                    </mml:mrow>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                  <mml:mo>+</mml:mo>
                  <mml:mfrac>
                    <mml:mrow>
                      <mml:msub>
                        <mml:mi>v</mml:mi>
                        <mml:mi>e</mml:mi>
                      </mml:msub>
                    </mml:mrow>
                    <mml:mrow>
                      <mml:msub>
                        <mml:mi>C</mml:mi>
                        <mml:mi>e</mml:mi>
                      </mml:msub>
                    </mml:mrow>
                  </mml:mfrac>
                </mml:mrow>
                <mml:mo>]</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>denote the maximum predicted utilization after accounting for provisional traffic (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> v </mml:mi><mml:mi> e </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ) already assigned during the current routing pass, and</p>
        <disp-formula id="FD8">
          <mml:math>
            <mml:mrow>
              <mml:mi>R</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>p</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mfrac>
                <mml:mn>1</mml:mn>
                <mml:mrow>
                  <mml:mrow>
                    <mml:mo>|</mml:mo>
                    <mml:mi>p</mml:mi>
                    <mml:mo>|</mml:mo>
                  </mml:mrow>
                </mml:mrow>
              </mml:mfrac>
              <mml:munder>
                <mml:mstyle mathsize="140%" displaystyle="true">
                  <mml:mo>∑</mml:mo>
                </mml:mstyle>
                <mml:mrow>
                  <mml:mi>e</mml:mi>
                  <mml:mo>∈</mml:mo>
                  <mml:mi>p</mml:mi>
                </mml:mrow>
              </mml:munder>
              <mml:msub>
                <mml:mi>r</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>denote mean detector-derived path risk.</p>
        <p>The TARA path score is</p>
        <disp-formula id="FD9">
          <label>(4)</label>
          <mml:math>
            <mml:mrow>
              <mml:mi>J</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>p</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mi>L</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>p</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mrow>
                <mml:mo>[</mml:mo>
                <mml:mrow>
                  <mml:mn>1</mml:mn>
                  <mml:mo>+</mml:mo>
                  <mml:mn>1.45</mml:mn>
                  <mml:mi>U</mml:mi>
                  <mml:msup>
                    <mml:mrow>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mi>p</mml:mi>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                    <mml:mn>3</mml:mn>
                  </mml:msup>
                </mml:mrow>
                <mml:mo>]</mml:mo>
              </mml:mrow>
              <mml:mo>+</mml:mo>
              <mml:mn>18</mml:mn>
              <mml:mi>R</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>p</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>Candidate paths are initially ordered by (<inline-formula><mml:math><mml:mrow><mml:mi> J </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mi> p </mml:mi><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> ). The lowest-cost path becomes the primary path. When path splitting is enabled, the secondary path is selected from the remaining candidates by first minimizing the number of links shared with the primary path and then minimizing (<inline-formula><mml:math><mml:mrow><mml:mi> J </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mi> p </mml:mi><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> ) among equal-overlap candidates. The no-overlap ablation omits this shared-link preference. Traffic shares across the selected paths are proportional to (<inline-formula><mml:math><mml:mrow><mml:mrow><mml:mn> 1 </mml:mn><mml:mo> / </mml:mo><mml:mrow><mml:mi> J </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mi> p </mml:mi><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:mrow></mml:mrow></mml:math></inline-formula> ) and normalized to sum to one.</p>
      </sec>
      <sec id="sec4dot3">
        <title>4.3. Policy Definitions and Fair Access</title>
        <p><bold>Table 3</bold> identifies what each policy does with the common information stream. Static and topology-disjoint routing intentionally ignore telemetry after initialization; this is a policy restriction, not unequal information delivery. Reactive routing uses the same risk signal as TARA and changes a route only when its current path contains a link whose risk is at least 0.55.</p>
        <p><bold>Table 3.</bold> Policies and ablations.</p>
        <table-wrap id="tbl3">
          <label>Table 3</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Policy</bold>
                </td>
                <td>
                  <bold>Risk</bold>
                </td>
                <td>
                  <bold>Utilization forecast</bold>
                </td>
                <td>
                  <bold>Diversity</bold>
                </td>
                <td>
                  <bold>Overlap control</bold>
                </td>
              </tr>
              <tr>
                <td>Static shortest path</td>
                <td>No</td>
                <td>No</td>
                <td>No</td>
                <td>No</td>
              </tr>
              <tr>
                <td>Reactive rerouting</td>
                <td>Threshold only</td>
                <td>No</td>
                <td>No</td>
                <td>No</td>
              </tr>
              <tr>
                <td>Topology disjoint</td>
                <td>No</td>
                <td>No</td>
                <td>Two paths</td>
                <td>Topology only</td>
              </tr>
              <tr>
                <td>Full TARA</td>
                <td>Continuous</td>
                <td>Yes</td>
                <td>Two paths</td>
                <td>Yes</td>
              </tr>
              <tr>
                <td>No risk term</td>
                <td>No</td>
                <td>Yes</td>
                <td>Two paths</td>
                <td>Yes</td>
              </tr>
              <tr>
                <td>No overlap term</td>
                <td>Continuous</td>
                <td>Yes</td>
                <td>Two paths</td>
                <td>No</td>
              </tr>
              <tr>
                <td>Single path</td>
                <td>Continuous</td>
                <td>Yes</td>
                <td>No</td>
                <td>No</td>
              </tr>
              <tr>
                <td>No utilization prediction</td>
                <td>Continuous</td>
                <td>Current EWMA</td>
                <td>Two paths</td>
                <td>Yes</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
      </sec>
    </sec>
    <sec id="sec5">
      <title>5. Experimental Design</title>
      <sec id="sec5dot1">
        <title>5.1. Scenario Generation and Reproducibility</title>
        <p>For each seed, 36 nodes are placed independently and uniformly in a <inline-formula><mml:math><mml:mrow><mml:mn> 1000 </mml:mn><mml:mo> × </mml:mo><mml:mn> 1000 </mml:mn></mml:mrow></mml:math></inline-formula> two-dimensional coordinate region. Each node is connected to its four nearest neighbors, after which 18 additional undirected node pairs are selected uniformly without replacement to increase path diversity. Duplicate undirected links are merged. Propagation latency for a link between nodes <inline-formula><mml:math><mml:mi> u </mml:mi></mml:math></inline-formula> and <inline-formula><mml:math><mml:mi> v </mml:mi></mml:math></inline-formula> is generated as </p>
        <p><inline-formula><mml:math><mml:mrow><mml:mn> 1 </mml:mn><mml:mo> + </mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mi> d </mml:mi><mml:mrow><mml:mrow><mml:mo> { </mml:mo><mml:mrow><mml:mi> u </mml:mi><mml:mi> v </mml:mi></mml:mrow><mml:mo> } </mml:mo></mml:mrow></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mn> 190 </mml:mn></mml:mrow></mml:mfrac><mml:mo> + </mml:mo><mml:mi> ξ </mml:mi></mml:mrow></mml:math></inline-formula> ms, where <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> d </mml:mi><mml:mrow><mml:mi> u </mml:mi><mml:mi> v </mml:mi></mml:mrow></mml:msub></mml:mrow></mml:math></inline-formula> is Euclidean distance and <inline-formula><mml:math><mml:mrow><mml:mi> ξ </mml:mi><mml:mo> ∼ </mml:mo><mml:mo></mml:mo><mml:mi> U </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mrow><mml:mn> 0 </mml:mn><mml:mo> , </mml:mo><mml:mn> 1 </mml:mn></mml:mrow><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> . Capacities of </p>
        <p>nearest-neighbor links are sampled from <inline-formula><mml:math><mml:mrow><mml:mi> U </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mrow><mml:mn> 125 </mml:mn><mml:mo> , </mml:mo><mml:mn> 235 </mml:mn></mml:mrow><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> , while the additional random links use <inline-formula><mml:math><mml:mrow><mml:mi> U </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mrow><mml:mn> 115 </mml:mn><mml:mo> , </mml:mo><mml:mn> 220 </mml:mn></mml:mrow><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> .</p>
        <p>Each topology contains 90 legitimate demands. Source and destination nodes are sampled uniformly from distinct node pairs. The offered rate for each demand is sampled from a lognormal distribution with log-location 1.05 and log-scale 0.42 and is clipped to the interval 1 - 8 simulation rate units.</p>
        <p>Initial shortest paths are computed using propagation latency as link cost. For every demand, up to four candidate paths are generated through repeated shortest-path searches in which links used by an already discovered path have their temporary cost multiplied by 2.0. This produces alternative paths while retaining a bounded candidate set.</p>
        <p>Attack targets are selected from links that occur most frequently in the initial shortest paths. Specifically, links are ranked by the number of baseline paths that </p>
        <p>traverse them, and the highest-ranked <inline-formula><mml:math><mml:mrow><mml:mi> max </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mrow><mml:mn> 5 </mml:mn><mml:mo> , </mml:mo><mml:mfrac><mml:mrow><mml:mrow><mml:mo> | </mml:mo><mml:mi> E </mml:mi><mml:mo> | </mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn> 15 </mml:mn></mml:mrow></mml:mfrac></mml:mrow><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> links are selected as attack </p>
        <p>targets. The target set remains fixed within a seed-scenario trial.</p>
        <p>The simulation contains 10 routing epochs, with attacks active during epochs 4 - 10. For every attacked link (<italic>e</italic>) and attack-active epoch (<italic>t</italic>), attack load is generated as</p>
        <disp-formula id="FD10">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>A</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mi>α</mml:mi>
              <mml:mo>
              </mml:mo>
              <mml:msub>
                <mml:mi>C</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:msub>
                <mml:mi>F</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>where (<inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> C </mml:mi><mml:mi> e </mml:mi></mml:msub></mml:mrow></mml:math></inline-formula> ) is link capacity, <inline-formula><mml:math><mml:mrow><mml:mi> α </mml:mi><mml:mo> ∈ </mml:mo><mml:mo></mml:mo><mml:mrow><mml:mo> { </mml:mo><mml:mrow><mml:mn> 0.60 </mml:mn><mml:mo> , </mml:mo><mml:mn> 1.00 </mml:mn><mml:mo> , </mml:mo><mml:mn> 1.40 </mml:mn></mml:mrow><mml:mo> } </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> is the configured attack-intensity factor, and <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> F </mml:mi><mml:mi> e </mml:mi></mml:msub><mml:mrow><mml:mo> ( </mml:mo><mml:mi> t </mml:mi><mml:mo> ) </mml:mo></mml:mrow><mml:mo> ∼ </mml:mo><mml:mo></mml:mo><mml:mi> U </mml:mi><mml:mrow><mml:mo> ( </mml:mo><mml:mrow><mml:mn> 0.82 </mml:mn><mml:mo> , </mml:mo><mml:mn> 1.18 </mml:mn></mml:mrow><mml:mo> ) </mml:mo></mml:mrow></mml:mrow></mml:math></inline-formula> introduces epoch-level fluctuation. Random streams are deterministically derived from the simulation seed, attack intensity, and detector setting so that policies evaluated within a scenario experience paired underlying conditions.</p>
        <p><bold>Table 4</bold> gives the complete design. Each seed fixes node coordinates, capacities, demands, attack targets, measurement noise, false-alarm draws, and attack fluctuations. Policies within that scenario are therefore paired.</p>
        <p><bold>Table 4.</bold>Executed simulation design.</p>
        <table-wrap id="tbl4">
          <label>Table 4</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Factor</bold>
                </td>
                <td>
                  <bold>Values</bold>
                </td>
              </tr>
              <tr>
                <td>Seeds</td>
                <td>24, numbered 1001 - 1024</td>
              </tr>
              <tr>
                <td>Topology</td>
                <td>36 nodes; geometric links; 90 demands</td>
              </tr>
              <tr>
                <td>Epochs</td>
                <td>10 total; attack active in epochs 4 - 10</td>
              </tr>
              <tr>
                <td>Attack load</td>
                <td>60%, 100%, or 140% of target-link capacity</td>
              </tr>
              <tr>
                <td>Detector quality</td>
                <td>Strong, moderate, weak</td>
              </tr>
              <tr>
                <td>Policies</td>
                <td>3 baselines, full TARA, 4 structural ablations</td>
              </tr>
              <tr>
                <td>Trials</td>
                <td>1728 seed-scenario-policy records</td>
              </tr>
              <tr>
                <td>Primary outcomes</td>
                <td>Delivered demand and 95th-percentile path latency</td>
              </tr>
              <tr>
                <td>Attack-active epochs</td>
                <td>4 - 10 of 10</td>
              </tr>
              <tr>
                <td>Attack targets</td>
                <td>
                  Highest baseline-path-centrality links;
                  <inline-formula>
                    <mml:math>
                      <mml:mrow>
                        <mml:mi>max</mml:mi>
                        <mml:mrow>
                          <mml:mo>(</mml:mo>
                          <mml:mrow>
                            <mml:mn>5</mml:mn>
                            <mml:mo>,</mml:mo>
                            <mml:mrow>
                              <mml:mrow>
                                <mml:mrow>
                                  <mml:mo>|</mml:mo>
                                  <mml:mi>E</mml:mi>
                                  <mml:mo>|</mml:mo>
                                </mml:mrow>
                              </mml:mrow>
                              <mml:mo>/</mml:mo>
                              <mml:mrow>
                                <mml:mn>15</mml:mn>
                              </mml:mrow>
                            </mml:mrow>
                          </mml:mrow>
                          <mml:mo>)</mml:mo>
                        </mml:mrow>
                      </mml:mrow>
                    </mml:math>
                  </inline-formula>
                  targets per topology
                </td>
              </tr>
              <tr>
                <td>Attack fluctuation</td>
                <td>
                  Independent multiplier
                  <inline-formula>
                    <mml:math>
                      <mml:mrow>
                        <mml:msub>
                          <mml:mi>F</mml:mi>
                          <mml:mi>e</mml:mi>
                        </mml:msub>
                        <mml:mrow>
                          <mml:mo>(</mml:mo>
                          <mml:mi>t</mml:mi>
                          <mml:mo>)</mml:mo>
                        </mml:mrow>
                        <mml:mo>∼</mml:mo>
                        <mml:mi>U</mml:mi>
                        <mml:mrow>
                          <mml:mo>(</mml:mo>
                          <mml:mrow>
                            <mml:mn>0.82</mml:mn>
                            <mml:mo>,</mml:mo>
                            <mml:mn>1.18</mml:mn>
                          </mml:mrow>
                          <mml:mo>)</mml:mo>
                        </mml:mrow>
                      </mml:mrow>
                    </mml:math>
                  </inline-formula>
                  per target link and epoch
                </td>
              </tr>
              <tr>
                <td>Candidate paths</td>
                <td>Up to 4 per demand</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
        <p>The 95% paired interval for a comparison uses Equation (5), where each difference is computed between policies sharing a seed and scenario.</p>
        <p>The two-sided 95% paired confidence interval is computed using the Student-(<italic>t</italic>) distribution:</p>
        <disp-formula id="FD11">
          <label>(5)</label>
          <mml:math>
            <mml:mrow>
              <mml:mtext>
              </mml:mtext>
              <mml:mover accent="true">
                <mml:mtext>Δ</mml:mtext>
                <mml:mo>¯</mml:mo>
              </mml:mover>
              <mml:mo>±</mml:mo>
              <mml:msub>
                <mml:mi>t</mml:mi>
                <mml:mrow>
                  <mml:mn>0.975</mml:mn>
                  <mml:mo>,</mml:mo>
                  <mml:mi>n</mml:mi>
                  <mml:mo>−</mml:mo>
                  <mml:mn>1</mml:mn>
                </mml:mrow>
              </mml:msub>
              <mml:mfrac>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>s</mml:mi>
                    <mml:mtext>Δ</mml:mtext>
                  </mml:msub>
                </mml:mrow>
                <mml:mrow>
                  <mml:msqrt>
                    <mml:mi>n</mml:mi>
                  </mml:msqrt>
                </mml:mrow>
              </mml:mfrac>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>where <inline-formula><mml:math><mml:mrow><mml:mtext></mml:mtext><mml:mover accent="true"><mml:mtext> Δ </mml:mtext><mml:mo> ¯ </mml:mo></mml:mover><mml:mo></mml:mo></mml:mrow></mml:math></inline-formula> is the mean paired difference, <inline-formula><mml:math><mml:mrow><mml:msub><mml:mi> s </mml:mi><mml:mtext> Δ </mml:mtext></mml:msub></mml:mrow></mml:math></inline-formula> is the sample standard deviation of the paired differences, and <inline-formula><mml:math><mml:mrow><mml:mi> n </mml:mi><mml:mo> = </mml:mo><mml:mn> 24 </mml:mn></mml:mrow></mml:math></inline-formula> . For the reported comparisons, <inline-formula><mml:math><mml:mrow><mml:mi> d </mml:mi><mml:mi> f </mml:mi><mml:mo> = </mml:mo><mml:mn> 23 </mml:mn></mml:mrow></mml:math></inline-formula> and <inline-formula><mml:math display="inline"><mml:mrow><mml:msub><mml:mi> t </mml:mi><mml:mrow><mml:mrow><mml:mo> { </mml:mo><mml:mrow><mml:mn> 0.975 </mml:mn><mml:mo> , </mml:mo><mml:mn> 23 </mml:mn></mml:mrow><mml:mo> } </mml:mo></mml:mrow></mml:mrow></mml:msub><mml:mo> = </mml:mo><mml:mn> 2.069 </mml:mn></mml:mrow></mml:math></inline-formula> .</p>
        <p>The interval is descriptive for the executed seed population; no claim is made that synthetic topology seeds are a random sample of deployed networks.</p>
      </sec>
      <sec id="sec5dot2">
        <title>5.2. Attack Effects and Evaluation Metrics</title>
        <p>Attack traffic and legitimate routed traffic contribute jointly to link load. For each link <inline-formula><mml:math><mml:mi> e </mml:mi></mml:math></inline-formula> , utilization is</p>
        <disp-formula id="FD12">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>u</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mfrac>
                <mml:mrow>
                  <mml:msubsup>
                    <mml:mi>L</mml:mi>
                    <mml:mi>e</mml:mi>
                    <mml:mrow>
                      <mml:mtext>legit</mml:mtext>
                    </mml:mrow>
                  </mml:msubsup>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mi>t</mml:mi>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                  <mml:mo>+</mml:mo>
                  <mml:msub>
                    <mml:mi>A</mml:mi>
                    <mml:mi>e</mml:mi>
                  </mml:msub>
                  <mml:mrow>
                    <mml:mo>(</mml:mo>
                    <mml:mi>t</mml:mi>
                    <mml:mo>)</mml:mo>
                  </mml:mrow>
                </mml:mrow>
                <mml:mrow>
                  <mml:msub>
                    <mml:mi>C</mml:mi>
                    <mml:mi>e</mml:mi>
                  </mml:msub>
                </mml:mrow>
              </mml:mfrac>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>For a legitimate path (<italic>p</italic>), the deliverable fraction is limited by its most capacity-constrained link. The delivered fraction associated with each path share is therefore computed from</p>
        <disp-formula id="FD13">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>D</mml:mi>
                <mml:mi>p</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:munder>
                <mml:mrow>
                  <mml:mi>min</mml:mi>
                </mml:mrow>
                <mml:mrow>
                  <mml:mi>e</mml:mi>
                  <mml:mo>∈</mml:mo>
                  <mml:mi>p</mml:mi>
                </mml:mrow>
              </mml:munder>
              <mml:mi>min</mml:mi>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mrow>
                  <mml:mn>1</mml:mn>
                  <mml:mo>,</mml:mo>
                  <mml:mfrac>
                    <mml:mn>1</mml:mn>
                    <mml:mrow>
                      <mml:msub>
                        <mml:mi>u</mml:mi>
                        <mml:mi>e</mml:mi>
                      </mml:msub>
                      <mml:mrow>
                        <mml:mo>(</mml:mo>
                        <mml:mi>t</mml:mi>
                        <mml:mo>)</mml:mo>
                      </mml:mrow>
                    </mml:mrow>
                  </mml:mfrac>
                </mml:mrow>
                <mml:mo>)</mml:mo>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>Demand delivery is the weighted sum of the fractions delivered through its selected paths.</p>
        <p>The performance-latency model uses total utilization to approximate congestion-induced delay. For link <inline-formula><mml:math><mml:mi> e </mml:mi></mml:math></inline-formula> , the queueing factor is</p>
        <disp-formula id="FD14">
          <mml:math>
            <mml:mrow>
              <mml:msub>
                <mml:mi>q</mml:mi>
                <mml:mi>e</mml:mi>
              </mml:msub>
              <mml:mrow>
                <mml:mo>(</mml:mo>
                <mml:mi>t</mml:mi>
                <mml:mo>)</mml:mo>
              </mml:mrow>
              <mml:mo>=</mml:mo>
              <mml:mrow>
                <mml:mo>{</mml:mo>
                <mml:mrow>
                  <mml:mtable>
                    <mml:mtr>
                      <mml:mtd>
                        <mml:mrow>
                          <mml:mfrac>
                            <mml:mrow>
                              <mml:msub>
                                <mml:mi>u</mml:mi>
                                <mml:mi>e</mml:mi>
                              </mml:msub>
                              <mml:msup>
                                <mml:mrow>
                                  <mml:mrow>
                                    <mml:mo>(</mml:mo>
                                    <mml:mi>t</mml:mi>
                                    <mml:mo>)</mml:mo>
                                  </mml:mrow>
                                </mml:mrow>
                                <mml:mn>2</mml:mn>
                              </mml:msup>
                            </mml:mrow>
                            <mml:mrow>
                              <mml:mi>max</mml:mi>
                              <mml:mrow>
                                <mml:mo>(</mml:mo>
                                <mml:mrow>
                                  <mml:mn>0.08</mml:mn>
                                  <mml:mo>,</mml:mo>
                                  <mml:mn>1</mml:mn>
                                  <mml:mo>−</mml:mo>
                                  <mml:msub>
                                    <mml:mi>u</mml:mi>
                                    <mml:mi>e</mml:mi>
                                  </mml:msub>
                                  <mml:mrow>
                                    <mml:mo>(</mml:mo>
                                    <mml:mi>t</mml:mi>
                                    <mml:mo>)</mml:mo>
                                  </mml:mrow>
                                  <mml:mo stretchy="false">)</mml:mo>
                                </mml:mrow>
                                <mml:mo>)</mml:mo>
                              </mml:mrow>
                            </mml:mrow>
                          </mml:mfrac>
                          <mml:mo>,</mml:mo>
                        </mml:mrow>
                      </mml:mtd>
                      <mml:mtd>
                        <mml:mrow>
                          <mml:msub>
                            <mml:mi>u</mml:mi>
                            <mml:mi>e</mml:mi>
                          </mml:msub>
                          <mml:mrow>
                            <mml:mo>(</mml:mo>
                            <mml:mi>t</mml:mi>
                            <mml:mo>)</mml:mo>
                          </mml:mrow>
                          <mml:mo>&lt;</mml:mo>
                          <mml:mn>1</mml:mn>
                          <mml:mo>,</mml:mo>
                        </mml:mrow>
                      </mml:mtd>
                    </mml:mtr>
                    <mml:mtr>
                      <mml:mtd>
                        <mml:mrow>
                          <mml:mfrac>
                            <mml:mrow>
                              <mml:msub>
                                <mml:mi>u</mml:mi>
                                <mml:mi>e</mml:mi>
                              </mml:msub>
                              <mml:msup>
                                <mml:mrow>
                                  <mml:mrow>
                                    <mml:mo>(</mml:mo>
                                    <mml:mi>t</mml:mi>
                                    <mml:mo>)</mml:mo>
                                  </mml:mrow>
                                </mml:mrow>
                                <mml:mn>2</mml:mn>
                              </mml:msup>
                            </mml:mrow>
                            <mml:mrow>
                              <mml:mn>0.08</mml:mn>
                            </mml:mrow>
                          </mml:mfrac>
                          <mml:mo>,</mml:mo>
                        </mml:mrow>
                      </mml:mtd>
                      <mml:mtd>
                        <mml:mrow>
                          <mml:msub>
                            <mml:mi>u</mml:mi>
                            <mml:mi>e</mml:mi>
                          </mml:msub>
                          <mml:mrow>
                            <mml:mo>(</mml:mo>
                            <mml:mi>t</mml:mi>
                            <mml:mo>)</mml:mo>
                          </mml:mrow>
                          <mml:mo>≥</mml:mo>
                          <mml:mn>1.</mml:mn>
                        </mml:mrow>
                      </mml:mtd>
                    </mml:mtr>
                  </mml:mtable>
                </mml:mrow>
              </mml:mrow>
            </mml:mrow>
          </mml:math>
        </disp-formula>
        <p>The primary results aggregate only the seven attack-active epochs (epochs 4 -10). Trial-level delivered demand is the mean delivery percentage across those epochs. At each epoch, the 95th percentile of modeled path latency is computed across the 90 legitimate demands; the reported trial-level P95 latency is the 95th percentile of those seven epoch-level P95 values.</p>
        <p>Dropped or partially undelivered demand is represented through the delivery-ratio metric and is not assigned an artificial infinite or penalty latency. The latency statistic therefore represents modeled path delay under the offered load rather than packet-completion latency for successfully delivered traffic only.</p>
      </sec>
    </sec>
    <sec id="sec6">
      <title>6. Results</title>
      <sec id="sec6dot1">
        <title>6.1. Principal Scenario</title>
        <p><xref ref-type="fig" rid="fig3">Figure 3</xref> and <bold>Table 5</bold> report the moderate-detector, 100%-attack scenario. Full TARA delivered 97.25% (SD 1.20) and reactive rerouting delivered 93.18% (SD 2.52). The paired difference was 4.07 percentage points, with a two-sided 95% paired <italic>t</italic>-interval from 3.39 to 4.74 percentage points.</p>
        <fig id="fig3">
          <label>Figure 3</label>
          <graphic xlink:href="https://html.scirp.org/file/9702666-rId107.jpeg?20260929023041" />
        </fig>
        <p><bold>Figure 3.</bold> Mean delivered demand for the principal scenario across 24 paired seeds.</p>
        <p><bold>Table 5.</bold> Principal scenario results.</p>
        <table-wrap id="tbl5">
          <label>Table 5</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Policy</bold>
                </td>
                <td>
                  <bold>Delivery mean ± SD (%)</bold>
                </td>
                <td>
                  <bold>P95 latency mean ± SD (ms)</bold>
                </td>
                <td>
                  <bold>Route changes</bold>
                </td>
              </tr>
              <tr>
                <td>Static shortest path</td>
                <td>92.93 ± 2.77</td>
                <td>33.47 ± 5.65</td>
                <td>0.0</td>
              </tr>
              <tr>
                <td>Reactive rerouting</td>
                <td>93.18 ± 2.52</td>
                <td>33.61 ± 5.74</td>
                <td>15.2</td>
              </tr>
              <tr>
                <td>Topology disjoint</td>
                <td>94.44 ± 2.41</td>
                <td>27.70 ± 5.36</td>
                <td>0.0</td>
              </tr>
              <tr>
                <td>Full TARA</td>
                <td>97.25 ± 1.20</td>
                <td>27.15 ± 4.93</td>
                <td>91.8</td>
              </tr>
              <tr>
                <td>No risk term</td>
                <td>97.19 ± 1.18</td>
                <td>27.37 ± 4.97</td>
                <td>44.2</td>
              </tr>
              <tr>
                <td>No overlap term</td>
                <td>97.16 ± 1.22</td>
                <td>27.45 ± 4.44</td>
                <td>91.4</td>
              </tr>
              <tr>
                <td>Single path</td>
                <td>97.07 ± 1.04</td>
                <td>32.67 ± 5.25</td>
                <td>94.0</td>
              </tr>
              <tr>
                <td>No utilization prediction</td>
                <td>97.08 ± 1.26</td>
                <td>27.23 ± 4.95</td>
                <td>89.3</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
        <p>Full TARA’s mean 95th-percentile latency was 27.15 ms. Its paired difference from reactive routing was −6.47 ms (two-sided 95% paired <italic>t</italic>-interval: −7.94 to −5.00 ms); negative values favor TARA.</p>
      </sec>
      <sec id="sec6dot2">
        <title>6.2. Detector Quality Sensitivity</title>
        <p><xref ref-type="fig" rid="fig4">Figure 4</xref> shows degradation as detector quality weakens. Full TARA delivery was 97.89% with strong detection and 96.71% with weak detection. <bold>Table 6</bold> pairs those service results with the detector precision and recall produced by the simulated measurement pipeline.</p>
        <fig id="fig4">
          <label>Figure 4</label>
          <graphic xlink:href="https://html.scirp.org/file/9702666-rId108.jpeg?20260929023042" />
        </fig>
        <p><bold>Figure 4.</bold>Delivery under strong, moderate, and weak detector settings. Axis values 1, 2, and 3 denote strong, moderate, and weak.</p>
        <p><bold>Table 6.</bold>Full TARA detector sensitivity at 100% attack.</p>
        <table-wrap id="tbl6">
          <label>Table 6</label>
          <table>
            <tbody>
              <tr>
                <td>
                  <bold>Detector</bold>
                </td>
                <td>
                  <bold>Delivery mean ± SD (%)</bold>
                </td>
                <td>
                  <bold>Precision (%)</bold>
                </td>
                <td>
                  <bold>Recall (%)</bold>
                </td>
              </tr>
              <tr>
                <td>Strong</td>
                <td>97.89 ± 0.95</td>
                <td>99.65</td>
                <td>25.06</td>
              </tr>
              <tr>
                <td>Moderate</td>
                <td>97.25 ± 1.20</td>
                <td>93.85</td>
                <td>7.74</td>
              </tr>
              <tr>
                <td>Weak</td>
                <td>96.71 ± 1.31</td>
                <td>20.83</td>
                <td>0.78</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
      </sec>
      <sec id="sec6dot3">
        <title>6.3. Attack Load Sensitivity</title>
        <p><xref ref-type="fig" rid="fig5">Figure 5</xref> reports all attack levels under moderate detection. The separation among policies grows as capacity pressure increases, but detector delay means that no telemetry-driven policy avoids the initial attacked epochs.</p>
      </sec>
      <sec id="sec6dot4">
        <title>6.4. Ablation and Overhead</title>
        <p><xref ref-type="fig" rid="fig6">Figure 6</xref> compares Full TARA with its four structural ablations in the principal scenario. The single-path ablation has the largest latency, showing that diversity rather than the risk term alone explains much of the resilience.</p>
        <fig id="fig5">
          <label>Figure 5</label>
          <graphic xlink:href="https://html.scirp.org/file/9702666-rId109.jpeg?20260929023043" />
        </fig>
        <p><bold>Figure 5.</bold> Delivered demand under 60%, 100%, and 140% target-capacity attack load with moderate detector quality.</p>
        <fig id="fig6">
          <label>Figure 6</label>
          <graphic xlink:href="https://html.scirp.org/file/9702666-rId110.jpeg?20260929023043" />
        </fig>
        <p><bold>Figure 6.</bold> Mean 95th-percentile latency for full TARA and four ablations in the principal scenario.</p>
        <p><xref ref-type="fig" rid="fig7">Figure 7</xref> confirms that strong detection improves both precision and recall; weak detection reduces recall and increases false-alert exposure. <xref ref-type="fig" rid="fig8">Figure 8</xref> shows that this additional adaptivity requires substantially more route changes than reactive rerouting.</p>
        <fig id="fig7">
          <label>Figure 7</label>
          <graphic xlink:href="https://html.scirp.org/file/9702666-rId111.jpeg?20260929023043" />
        </fig>
        <p><bold>Figure 7.</bold>Mean detector precision and recall obtained from the simulated telemetry pipeline.</p>
        <fig id="fig8">
          <label>Figure 8</label>
          <graphic xlink:href="https://html.scirp.org/file/9702666-rId112.jpeg?20260929023043" />
        </fig>
        <p><bold>Figure 8.</bold>Mean controller route changes in the principal scenario.</p>
      </sec>
    </sec>
    <sec id="sec7">
      <title>7. Discussion</title>
      <p>TARA preserves more demand than reactive and static routing in the modeled scenarios when risk must be inferred from imperfect telemetry. This result does not imply that the controller identifies attacked links correctly in every epoch. Detection delay guarantees a period in which route decisions use stale pre-attack state.</p>
      <p>Ablation differences are modest among full TARA, no-risk, no-overlap, and no-prediction variants in the principal scenario. Path splitting produces the largest structural change. The continuous risk term becomes more relevant as detector quality improves; under weak detection its benefit can shrink or reverse because false positives redirect flows unnecessarily.</p>
      <p>Operationally, the delivery gain must be balanced against route churn. Full TARA changes more routes than reactive rerouting because it adjusts split paths as observed utilization evolves. Rate limiting, minimum dwell times, and rule-capacity constraints should be added before controller deployment.</p>
    </sec>
    <sec id="sec8">
      <title>8. Threats to Validity and Limitations</title>
      <p>The topology generator is geometric and smaller than a carrier backbone. Traffic is stationary within an epoch, links are undirected, queueing is an analytic approximation, and the attacker does not adapt to observed route changes. These assumptions limit external validity.</p>
      <p>Detector errors are parameterized rather than learned from packet traces. The strong, moderate, and weak settings are controlled sensitivity cases, not measured operating points. Ground truth is used only to generate false-negative and false-positive events and to score detector performance; it is never passed to routing code.</p>
      <p>The paired confidence intervals describe variation across the fixed synthetic seeds. They do not account for uncertainty in the assumed traffic, detector, or queueing models. Hardware-in-the-loop evaluation with controller and switch timing remains necessary.</p>
    </sec>
    <sec id="sec9">
      <title>9. Conclusion</title>
      <p>Full TARA delivered 97.25% of demand in the principal scenario, 4.07 percentage points more than reactive rerouting on paired seeds, while its paired 95th-percentile latency difference was −6.47 ms. Path diversity provides the dominant benefit, whereas the risk, overlap, and utilization-prediction terms show comparatively modest differences. Detector degradation changed full-TARA delivery from 97.89% to 96.71%, confirming that resilience depends on telemetry quality. These findings are simulation-based and do not constitute evidence of production deployment performance.</p>
    </sec>
    <sec id="sec10">
      <title>Data and Code Availability</title>
      <p>The study uses no proprietary or personal data. The complete simulation source, fixed random-seed ranges, seed-level result files, aggregated tables, and publication figures are included in the accompanying reproducibility package. The code regenerates all numerical results and figures reported in this manuscript.</p>
    </sec>
    <sec id="sec11">
      <title>Funding</title>
      <p>This research received no external funding.</p>
    </sec>
    <sec id="sec12">
      <title>Author Contributions</title>
      <p><bold>Utham Kumar Anugula Sethupathy:</bold> Conceptualization, methodology, software, validation, formal analysis, investigation, data curation, writing—original draft, writing—review and editing, and visualization. <bold>Vijayanand Ananthanarayanan:</bold> Validation, formal analysis, writing—review and editing.</p>
    </sec>
    <sec id="sec13">
      <title>Appendix A. Reproduction Procedure</title>
      <p>Python run_experiments.py --study ijcns. It writes every seed-policy record, grouped summaries, figures, and an experiment manifest. The seed, detector, attack load, and policy columns uniquely identify each trial; <bold>Table A1</bold> lists the expected checks.</p>
      <p>A complete trial is uniquely determined by the topology seed, attack-intensity setting, detector-quality setting, and routing policy. The seed determines topology geometry and base link characteristics, while deterministic derived random streams determine demands, attack fluctuations, telemetry noise, false-positive events, and false-negative events. Policies within a common seed/intensity/detector scenario therefore operate under paired stochastic conditions. The main experiment contains <inline-formula><mml:math><mml:mrow><mml:mn> 24 </mml:mn><mml:mo> × </mml:mo><mml:mn> 3 </mml:mn><mml:mo> × </mml:mo><mml:mn> 3 </mml:mn><mml:mo> × </mml:mo><mml:mn> 8 </mml:mn><mml:mo> = </mml:mo><mml:mn> 1728 </mml:mn></mml:mrow></mml:math></inline-formula> seed-scenario-policy records.</p>
      <p><bold>Table A1</bold><bold>.</bold> Reproduction checks.</p>
      <table-wrap id="tbl7">
        <label>Table 7</label>
        <table>
          <tbody>
            <tr>
              <td>
                <bold>Check</bold>
              </td>
              <td>
                <bold>Expected value</bold>
              </td>
            </tr>
            <tr>
              <td>Seed range</td>
              <td>1001 - 1024</td>
            </tr>
            <tr>
              <td>Main records</td>
              <td>1728</td>
            </tr>
            <tr>
              <td>Attack information in routing function</td>
              <td>Absent</td>
            </tr>
            <tr>
              <td>Figure resolution</td>
              <td>500 dpi PNG</td>
            </tr>
            <tr>
              <td>Primary uncertainty</td>
              <td>Paired 95% confidence interval</td>
            </tr>
          </tbody>
        </table>
      </table-wrap>
    </sec>
  </body>
  <back>
    <ref-list>
      <title>References</title>
      <ref id="B1">
        <label>1.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., <italic>et al</italic>. (2008) OpenFlow: Enabling Innovation in Campus Networks. <italic>ACM SIGCOMM Computer Communication Review</italic>, 38, 69-74. https://doi.org/10.1145/1355734.1355746 <pub-id pub-id-type="doi">10.1145/1355734.1355746</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/1355734.1355746">https://doi.org/10.1145/1355734.1355746</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>McKeown, N.</string-name>
              <string-name>Anderson, T.</string-name>
              <string-name>Balakrishnan, H.</string-name>
              <string-name>Parulkar, G.</string-name>
              <string-name>Peterson, L.</string-name>
              <string-name>Rexford, J.</string-name>
            </person-group>
            <year>2008</year>
            <article-title>OpenFlow: Enabling Innovation in Campus Networks</article-title>
            <source>ACM SIGCOMM Computer Communication Review</source>
            <volume>38</volume>
            <pub-id pub-id-type="doi">10.1145/1355734.1355746</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B2">
        <label>2.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Kreutz, D., Ramos, F.M.V., Esteves Verissimo, P., Esteve Rothenberg, C., Azodolmolky, S. and Uhlig, S. (2015) Software-Defined Networking: A Comprehensive Survey. <italic>Proceedings of the IEEE</italic>, 103, 14-76. https://doi.org/10.1109/jproc.2014.2371999 <pub-id pub-id-type="doi">10.1109/jproc.2014.2371999</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/jproc.2014.2371999">https://doi.org/10.1109/jproc.2014.2371999</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Kreutz, D.</string-name>
              <string-name>Ramos, F.M.V.</string-name>
              <string-name>Verissimo, P.</string-name>
              <string-name>Rothenberg, C.</string-name>
              <string-name>Azodolmolky, S.</string-name>
              <string-name>Uhlig, S.</string-name>
            </person-group>
            <year>2015</year>
            <article-title>Software-Defined Networking: A Comprehensive Survey</article-title>
            <source>Proceedings of the IEEE</source>
            <volume>103</volume>
            <pub-id pub-id-type="doi">10.1109/jproc.2014.2371999</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B3">
        <label>3.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Kang, M.S., Lee, S.B. and Gligor, V.D. (2013) The Crossfire Attack. 2013 <italic>IEEE Symposium on Security and Privacy</italic>, Berkeley, 19-22 May 2013, 127-141. https://doi.org/10.1109/sp.2013.19 <pub-id pub-id-type="doi">10.1109/sp.2013.19</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/sp.2013.19">https://doi.org/10.1109/sp.2013.19</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Kang, M.S.</string-name>
              <string-name>Lee, S.B.</string-name>
              <string-name>Gligor, V.D.</string-name>
              <string-name>Privacy, B</string-name>
            </person-group>
            <year>2013</year>
            <article-title>The Crossfire Attack</article-title>
            <source>2013 IEEE Symposium on Security and Privacy</source>
            <volume>19</volume>
            <pub-id pub-id-type="doi">10.1109/sp.2013.19</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B4">
        <label>4.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Kang, M.S., Gligor, V.D. and Sekar, V. (2016) SPIFFY: Inducing Cost-Detectability Tradeoffs for Persistent Link-Flooding Attacks. <italic>Proceedings</italic>2016 <italic>Network and Distributed System Security Symposium</italic>, San Diego, 21-24 February 2016, 1-15. https://doi.org/10.14722/ndss.2016.23147 <pub-id pub-id-type="doi">10.14722/ndss.2016.23147</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.14722/ndss.2016.23147">https://doi.org/10.14722/ndss.2016.23147</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Kang, M.S.</string-name>
              <string-name>Gligor, V.D.</string-name>
              <string-name>Sekar, V.</string-name>
              <string-name>Symposium, S</string-name>
            </person-group>
            <year>2016</year>
            <article-title>SPIFFY: Inducing Cost-Detectability Tradeoffs for Persistent Link-Flooding Attacks</article-title>
            <source>Proceedings 2016 Network and Distributed System Security Symposium</source>
            <volume>21</volume>
            <pub-id pub-id-type="doi">10.14722/ndss.2016.23147</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B5">
        <label>5.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Hong, C., Kandula, S., Mahajan, R., Zhang, M., Gill, V., Nanduri, M., <italic>et al</italic>. (2013) Achieving High Utilization with Software-Driven WAN. <italic>ACM SIGCOMM Computer Communication Review</italic>, 43, 15-26. https://doi.org/10.1145/2534169.2486012 <pub-id pub-id-type="doi">10.1145/2534169.2486012</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/2534169.2486012">https://doi.org/10.1145/2534169.2486012</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Hong, C.</string-name>
              <string-name>Kandula, S.</string-name>
              <string-name>Mahajan, R.</string-name>
              <string-name>Zhang, M.</string-name>
              <string-name>Gill, V.</string-name>
              <string-name>Nanduri, M.</string-name>
            </person-group>
            <year>2013</year>
            <article-title>Achieving High Utilization with Software-Driven WAN</article-title>
            <source>ACM SIGCOMM Computer Communication Review</source>
            <volume>43</volume>
            <pub-id pub-id-type="doi">10.1145/2534169.2486012</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B6">
        <label>6.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Fortz, B. and Thorup, M. (2000) Internet Traffic Engineering by Optimizing OSPF Weights. Proceedings IEEE INFOCOM 2000. <italic>Conference on Computer Communications. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies</italic>, Tel Aviv, 26-30 March 2000, 519-528. https://doi.org/10.1109/infcom.2000.832225 <pub-id pub-id-type="doi">10.1109/infcom.2000.832225</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/infcom.2000.832225">https://doi.org/10.1109/infcom.2000.832225</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Fortz, B.</string-name>
              <string-name>Thorup, M.</string-name>
              <string-name>Societies, T</string-name>
            </person-group>
            <year>2000</year>
            <article-title>Internet Traffic Engineering by Optimizing OSPF Weights</article-title>
            <source>Proceedings IEEE INFOCOM 2000. Conference on Computer Communications. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies</source>
            <volume>26</volume>
            <pub-id pub-id-type="doi">10.1109/infcom.2000.832225</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B7">
        <label>7.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Suurballe, J.W. (1974) Disjoint Paths in a Network. <italic>Networks</italic>, 4, 125-145. https://doi.org/10.1002/net.3230040204 <pub-id pub-id-type="doi">10.1002/net.3230040204</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1002/net.3230040204">https://doi.org/10.1002/net.3230040204</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Suurballe, J.W.</string-name>
            </person-group>
            <year>1974</year>
            <article-title>Disjoint Paths in a Network</article-title>
            <source>Networks</source>
            <volume>4</volume>
            <pub-id pub-id-type="doi">10.1002/net.3230040204</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B8">
        <label>8.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Yen, J.Y. (1971) Finding the <italic>k</italic> Shortest Loopless Paths in a Network. <italic>Management Science</italic>, 17, 712-716. https://doi.org/10.1287/mnsc.17.11.712 <pub-id pub-id-type="doi">10.1287/mnsc.17.11.712</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1287/mnsc.17.11.712">https://doi.org/10.1287/mnsc.17.11.712</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Yen, J.Y.</string-name>
            </person-group>
            <year>1971</year>
            <article-title>Finding the k Shortest Loopless Paths in a Network</article-title>
            <source>Management Science</source>
            <volume>17</volume>
            <pub-id pub-id-type="doi">10.1287/mnsc.17.11.712</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B9">
        <label>9.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Brown, R.G. (1959) Statistical Forecast for Inventory Control. McGraw-Hill.</mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Brown, R.G.</string-name>
            </person-group>
            <year>1959</year>
            <article-title>Statistical Forecast for Inventory Control</article-title>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B10">
        <label>10.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Scarfone, K. and Mell, P. (2007) Guide to Intrusion Detection and Prevention Systems. NIST SP 800-94. https://doi.org/10.6028/NIST.SP.800-94 <pub-id pub-id-type="doi">10.6028/NIST.SP.800-94</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.6028/NIST.SP.800-94">https://doi.org/10.6028/NIST.SP.800-94</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Scarfone, K.</string-name>
              <string-name>Mell, P.</string-name>
            </person-group>
            <year>2007</year>
            <article-title>Guide to Intrusion Detection and Prevention Systems</article-title>
            <pub-id pub-id-type="doi">10.6028/NIST.SP.800-94</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B11">
        <label>11.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Floyd, S. (2000) Congestion Control Principles. RFC 2914. https://doi.org/10.17487/RFC2914 <pub-id pub-id-type="doi">10.17487/RFC2914</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.17487/RFC2914">https://doi.org/10.17487/RFC2914</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Floyd, S.</string-name>
            </person-group>
            <year>2000</year>
            <article-title>Congestion Control Principles</article-title>
            <pub-id pub-id-type="doi">10.17487/RFC2914</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B12">
        <label>12.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Baker, F., Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and Weiss, W. (1998) An Architecture for Differentiated Services. RFC 2475. https://doi.org/10.17487/RFC2475 <pub-id pub-id-type="doi">10.17487/RFC2475</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.17487/RFC2475">https://doi.org/10.17487/RFC2475</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Baker, F.</string-name>
              <string-name>Black, D.</string-name>
              <string-name>Blake, S.</string-name>
              <string-name>Carlson, M.</string-name>
              <string-name>Davies, E.</string-name>
              <string-name>Wang, Z.</string-name>
              <string-name>Weiss, W.</string-name>
            </person-group>
            <year>1998</year>
            <article-title>An Architecture for Differentiated Services</article-title>
            <pub-id pub-id-type="doi">10.17487/RFC2475</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B13">
        <label>13.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Saltzer, J.H., Reed, D.P. and Clark, D.D. (1984) End-to-End Arguments in System Design. <italic>ACM Transactions on Computer Systems</italic>, 2, 277-288. https://doi.org/10.1145/357401.357402 <pub-id pub-id-type="doi">10.1145/357401.357402</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1145/357401.357402">https://doi.org/10.1145/357401.357402</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Saltzer, J.H.</string-name>
              <string-name>Reed, D.P.</string-name>
              <string-name>Clark, D.D.</string-name>
            </person-group>
            <year>1984</year>
            <article-title>End-to-End Arguments in System Design</article-title>
            <source>ACM Transactions on Computer Systems</source>
            <volume>2</volume>
            <pub-id pub-id-type="doi">10.1145/357401.357402</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B14">
        <label>14.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Paxson, V. and Floyd, S. (1997) Why We Don’t Know How to Simulate the Internet. <italic>Proceedings of the</italic>29 <italic>th conference on Winter Simulation</italic>, Atlanta, 7-10 December 1997, 1037-1044.</mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Paxson, V.</string-name>
              <string-name>Floyd, S.</string-name>
              <string-name>Simulation, A</string-name>
            </person-group>
            <year>1997</year>
            <article-title>Why We Don’t Know How to Simulate the Internet</article-title>
            <source>Proceedings of the 29th conference on Winter Simulation</source>
            <volume>7</volume>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B15">
        <label>15.</label>
        <citation-alternatives>
          <mixed-citation publication-type="journal">Murtuza, S. and Asawa, K. (2024) Early Prevention and Mitigation of Link Flooding Attacks in Software Defined Networks. <italic>Journal of Network and Computer Applications</italic>, 224, Article 103832. https://doi.org/10.1016/j.jnca.2024.103832 <pub-id pub-id-type="doi">10.1016/j.jnca.2024.103832</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1016/j.jnca.2024.103832">https://doi.org/10.1016/j.jnca.2024.103832</ext-link></mixed-citation>
          <element-citation publication-type="journal">
            <person-group person-group-type="author">
              <string-name>Murtuza, S.</string-name>
              <string-name>Asawa, K.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Early Prevention and Mitigation of Link Flooding Attacks in Software Defined Networks</article-title>
            <source>Journal of Network and Computer Applications</source>
            <volume>224</volume>
            <elocation-id>103832</elocation-id>
            <pub-id pub-id-type="doi">10.1016/j.jnca.2024.103832</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B16">
        <label>16.</label>
        <citation-alternatives>
          <mixed-citation publication-type="confproc">Troia, S., Gregorini, E., Asdikian, J.P., Li, M. and Maier, G. (2024) Real-Time Delay Measurement in SD-WAN Based on In-Band Network Telemetry. 2024 <italic>IEEE</italic>25 <italic>th International Conference on High Performance Switching and Routing</italic>( <italic>HPSR</italic>), Pisa, 22-24 July 2024, 149-154. https://doi.org/10.1109/hpsr62440.2024.10635944 <pub-id pub-id-type="doi">10.1109/hpsr62440.2024.10635944</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/hpsr62440.2024.10635944">https://doi.org/10.1109/hpsr62440.2024.10635944</ext-link></mixed-citation>
          <element-citation publication-type="confproc">
            <person-group person-group-type="author">
              <string-name>Troia, S.</string-name>
              <string-name>Gregorini, E.</string-name>
              <string-name>Asdikian, J.P.</string-name>
              <string-name>Li, M.</string-name>
              <string-name>Maier, G.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Real-Time Delay Measurement in SD-WAN Based on In-Band Network Telemetry</article-title>
            <source>2024 IEEE 25th International Conference on High Performance Switching and Routing (HPSR)</source>
            <volume>22</volume>
            <pub-id pub-id-type="doi">10.1109/hpsr62440.2024.10635944</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B17">
        <label>17.</label>
        <citation-alternatives>
          <mixed-citation publication-type="journal">Jisi, C., Roh, B. and Ali, J. (2024) Reliable Paths Prediction with Intelligent Data Plane Monitoring Enabled Reinforcement Learning in SD-IoT. <italic>Journal of King Saud University</italic>- <italic>Computer and Information Sciences</italic>, 36, Article 102006. https://doi.org/10.1016/j.jksuci.2024.102006 <pub-id pub-id-type="doi">10.1016/j.jksuci.2024.102006</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1016/j.jksuci.2024.102006">https://doi.org/10.1016/j.jksuci.2024.102006</ext-link></mixed-citation>
          <element-citation publication-type="journal">
            <person-group person-group-type="author">
              <string-name>Jisi, C.</string-name>
              <string-name>Roh, B.</string-name>
              <string-name>Ali, J.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Reliable Paths Prediction with Intelligent Data Plane Monitoring Enabled Reinforcement Learning in SD-IoT</article-title>
            <source>Journal of King Saud University-Computer and Information Sciences</source>
            <volume>36</volume>
            <elocation-id>102006</elocation-id>
            <pub-id pub-id-type="doi">10.1016/j.jksuci.2024.102006</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B18">
        <label>18.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Alsaeedi, M., Mohamad, M.M. and Al-Roubaiey, A. (2024) SSDWSN: A Scalable Software-Defined Wireless Sensor Networks. <italic>IEEE Access</italic>, 12, 21787-21806. https://doi.org/10.1109/access.2024.3362353 <pub-id pub-id-type="doi">10.1109/access.2024.3362353</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/access.2024.3362353">https://doi.org/10.1109/access.2024.3362353</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Alsaeedi, M.</string-name>
              <string-name>Mohamad, M.M.</string-name>
              <string-name>Al-Roubaiey, A.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>SSDWSN: A Scalable Software-Defined Wireless Sensor Networks</article-title>
            <source>IEEE Access</source>
            <volume>12</volume>
            <pub-id pub-id-type="doi">10.1109/access.2024.3362353</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B19">
        <label>19.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Soltani, S., Shojafar, M., Mostafaei, H. and Tafazolli, R. (2023) Real-Time Link Verification in Software-Defined Networks. <italic>IEEE Transactions on Network and Service Management</italic>, 20, 3596-3611. https://doi.org/10.1109/tnsm.2023.3238691 <pub-id pub-id-type="doi">10.1109/tnsm.2023.3238691</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/tnsm.2023.3238691">https://doi.org/10.1109/tnsm.2023.3238691</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Soltani, S.</string-name>
              <string-name>Shojafar, M.</string-name>
              <string-name>Mostafaei, H.</string-name>
              <string-name>Tafazolli, R.</string-name>
            </person-group>
            <year>2023</year>
            <article-title>Real-Time Link Verification in Software-Defined Networks</article-title>
            <source>IEEE Transactions on Network and Service Management</source>
            <volume>20</volume>
            <pub-id pub-id-type="doi">10.1109/tnsm.2023.3238691</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B20">
        <label>20.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Jiang, X., Shi, Q., Miao, H., Cao, W., He, H., Chen, S., <italic>et al</italic>. (2024) Credible Link Flooding Attack Detection and Mitigation: A Blockchain-Based Approach. <italic>IEEE Transactions on Network and Service Management</italic>, 21, 3537-3554. https://doi.org/10.1109/tnsm.2024.3357660 <pub-id pub-id-type="doi">10.1109/tnsm.2024.3357660</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/tnsm.2024.3357660">https://doi.org/10.1109/tnsm.2024.3357660</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Jiang, X.</string-name>
              <string-name>Shi, Q.</string-name>
              <string-name>Miao, H.</string-name>
              <string-name>Cao, W.</string-name>
              <string-name>He, H.</string-name>
              <string-name>Chen, S.</string-name>
            </person-group>
            <year>2024</year>
            <article-title>Credible Link Flooding Attack Detection and Mitigation: A Blockchain-Based Approach</article-title>
            <source>IEEE Transactions on Network and Service Management</source>
            <volume>21</volume>
            <pub-id pub-id-type="doi">10.1109/tnsm.2024.3357660</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B21">
        <label>21.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Guo, Z., Dou, S., Liu, S., Feng, W., Jiang, W., Xu, Y., <italic>et al</italic>. (2022) Maintaining Control Resiliency and Flow Programmability in Software-Defined Wans during Controller Failures. <italic>IEEE</italic>/ <italic>ACM Transactions on Networking</italic>, 30, 969-984. https://doi.org/10.1109/tnet.2021.3128771 <pub-id pub-id-type="doi">10.1109/tnet.2021.3128771</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/tnet.2021.3128771">https://doi.org/10.1109/tnet.2021.3128771</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Guo, Z.</string-name>
              <string-name>Dou, S.</string-name>
              <string-name>Liu, S.</string-name>
              <string-name>Feng, W.</string-name>
              <string-name>Jiang, W.</string-name>
              <string-name>Xu, Y.</string-name>
            </person-group>
            <year>2022</year>
            <article-title>Maintaining Control Resiliency and Flow Programmability in Software-Defined Wans during Controller Failures</article-title>
            <source>IEEE/ACM Transactions on Networking</source>
            <volume>30</volume>
            <pub-id pub-id-type="doi">10.1109/tnet.2021.3128771</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
      <ref id="B22">
        <label>22.</label>
        <citation-alternatives>
          <mixed-citation publication-type="other">Al-Share, R.A., Shatnawi, A.S. and Al-Duwairi, B. (2022) Detecting and Mitigating Collusive Interest Flooding Attacks in Named Data Networking. <italic>IEEE Access</italic>, 10, 65996-66017. https://doi.org/10.1109/access.2022.3184304 <pub-id pub-id-type="doi">10.1109/access.2022.3184304</pub-id><ext-link ext-link-type="uri" xlink:href="https://doi.org/10.1109/access.2022.3184304">https://doi.org/10.1109/access.2022.3184304</ext-link></mixed-citation>
          <element-citation publication-type="other">
            <person-group person-group-type="author">
              <string-name>Al-Share, R.A.</string-name>
              <string-name>Shatnawi, A.S.</string-name>
              <string-name>Al-Duwairi, B.</string-name>
            </person-group>
            <year>2022</year>
            <article-title>Detecting and Mitigating Collusive Interest Flooding Attacks in Named Data Networking</article-title>
            <source>IEEE Access</source>
            <volume>10</volume>
            <pub-id pub-id-type="doi">10.1109/access.2022.3184304</pub-id>
          </element-citation>
        </citation-alternatives>
      </ref>
    </ref-list>
  </back>
</article>