<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.34 (Ruby 3.4.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ihlesong-mpls-mna-signaling-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.32.0 -->
  <front>
    <title abbrev="SIG">Signaling MNA Capabilities Using LSP Ping</title>
    <seriesInfo name="Internet-Draft" value="draft-ihlesong-mpls-mna-signaling-01"/>
    <author fullname="Fabian Ihle">
      <organization>University of Tuebingen</organization>
      <address>
        <postal>
          <city>Tuebingen</city>
          <country>Germany</country>
        </postal>
        <email>fabian.ihle@uni-tuebingen.de</email>
      </address>
    </author>
    <author fullname="Xueyan Song">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>song.xueyan2@zte.com.cn</email>
      </address>
    </author>
    <author fullname="Michael Menth">
      <organization>University of Tuebingen</organization>
      <address>
        <postal>
          <city>Tuebingen</city>
          <country>Germany</country>
        </postal>
        <email>michael.menth@uni-tuebingen.de</email>
      </address>
    </author>
    <date year="2026" month="March" day="17"/>
    <area>Routing</area>
    <workgroup>Multiprotocol Label Switching</workgroup>
    <keyword>signaling</keyword>
    <keyword>mpls</keyword>
    <keyword>mna</keyword>
    <abstract>
      <?line 69?>

<t>This document defines a mechanism for discovering MPLS Network Actions (MNA) capabilities along a Label Switched Path (LSP) using the LSP Ping echo request/reply mechanism defined in RFC 8029. The capabilities include the Readable Label Depth (RLD), the maximum sizes of differently scoped Network Action Sub-stacks (MLD_NAS), and supported network action opcodes. This mechanism allows the ingress Label Edge Router (LER) to discover MNA capabilities of each transit and egress node on the path, enabling correct construction of MPLS label stacks containing MNA network actions.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://uni-tue-kn.github.io/draft-ihlesong-mpls-mna-signaling/draft-ihlesong-mpls-mna-signaling.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ihlesong-mpls-mna-signaling/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Multiprotocol Label Switching Working Group mailing list (<eref target="mailto:mpls@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mpls/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mpls/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/uni-tue-kn/draft-ihlesong-mpls-mna-signaling"/>.</t>
    </note>
  </front>
  <middle>
    <?line 73?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The MPLS Network Actions (MNA) framework <xref target="I-D.ietf-mpls-mna-hdr"/> provides a general mechanism for encoding network actions and their data in the MPLS label stack.
Network actions are encoded in Network Action Sub-stacks (NAS) that are placed within (ISD) or follow after (PSD) the MPLS label stack.
The MNA header encoding is defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.
To correctly construct MPLS label stacks containing network actions, the ingress LER needs to know the MNA capabilities of each node along the path.
For Post-Stack MNA, the ingress LER additionally needs to discover whether nodes support Post-Stack MPLS Headers and what Post-Stack network actions they can process, as required by Section 5.3 of <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.
These capabilities include:</t>
      <ol spacing="normal" type="1"><li>
          <t>In-Stack MNA capabilities:
          </t>
          <ul spacing="normal">
            <li>
              <t>The Readable Label Depth (RLD): the number of Label Stack Entries (LSEs) a node can parse without performance impact.</t>
            </li>
            <li>
              <t>The NAS Maximum Label Depth (MLD_NAS): the maximum supported NAS size for each scope (select, HBH, I2E).</t>
            </li>
            <li>
              <t>The supported In-Stack network action opcodes.</t>
            </li>
          </ul>
        </li>
        <li>
          <t>Post-Stack MNA capabilities:
          </t>
          <ul spacing="normal">
            <li>
              <t>Whether the node supports Post-Stack MNA processing as defined in <xref target="I-D.ietf-mpls-mna-ps-hdr"/>,</t>
            </li>
            <li>
              <t>The maximum Post-Stack MPLS Header (PSMH) size (MLD_PSMH),</t>
            </li>
            <li>
              <t>The RLD including the PSMH (RLD_PSMH)</t>
            </li>
            <li>
              <t>The supported Post-Stack network action opcodes.</t>
            </li>
          </ul>
        </li>
      </ol>
      <t>This document defines new TLVs for the MPLS echo request/reply messages <xref target="rfc8029"/> to query and report MNA capabilities. The mechanism supports both "ping" mode (querying only the egress node) and "traceroute" mode (querying all nodes along the path).</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

<section anchor="abbreviations">
          <name>Abbreviations</name>
          <t>This document makes use of the terms defined in <xref target="I-D.ietf-mpls-mna-hdr"/> and in <xref target="I-D.ietf-mpls-mna-fwk"/>.</t>
          <table anchor="table_abbrev">
            <name>Abbreviations.</name>
            <thead>
              <tr>
                <th align="left">Abbreviation</th>
                <th align="left">Name</th>
                <th align="left">Description</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">NAS</td>
                <td align="left">Network Action Sub-stack</td>
                <td align="left">A stack of related LSEs in the MPLS stack containing network actions and ancillary data.</td>
                <td align="left">
                  <xref target="rfc9789"/></td>
              </tr>
              <tr>
                <td align="left">RLD</td>
                <td align="left">Readable Label Depth</td>
                <td align="left">The number of LSEs a node can parse.</td>
                <td align="left">
                  <xref target="I-D.ietf-mpls-mna-hdr"/></td>
              </tr>
              <tr>
                <td align="left">MLD_NAS</td>
                <td align="left">NAS Maximum Label Depth</td>
                <td align="left">The maximum number of LSEs in a NAS that a node can process, defined per scope.</td>
                <td align="left">This document</td>
              </tr>
              <tr>
                <td align="left">PSMH</td>
                <td align="left">Post-Stack MPLS Header</td>
                <td align="left">The header after the BOS carrying post-stack network actions and ancillary data.</td>
                <td align="left">
                  <xref target="I-D.ietf-mpls-mna-ps-hdr"/></td>
              </tr>
              <tr>
                <td align="left">PSD</td>
                <td align="left">Post-Stack Data</td>
                <td align="left">Network actions and data encoded after the MPLS label stack.</td>
                <td align="left">
                  <xref target="I-D.ietf-mpls-mna-ps-hdr"/></td>
              </tr>
              <tr>
                <td align="left">ISD</td>
                <td align="left">In-Stack Data</td>
                <td align="left">Network actions and data encoded within the MPLS label stack.</td>
                <td align="left">
                  <xref target="I-D.ietf-mpls-mna-hdr"/></td>
              </tr>
              <tr>
                <td align="left">MLD_PSMH</td>
                <td align="left">NAS Maximum Label Depth</td>
                <td align="left">The maximum PSMH size a node can process, in 4-octet units.</td>
                <td align="left">This document</td>
              </tr>
              <tr>
                <td align="left">RLD_PSMH</td>
                <td align="left">RLD including PSMH</td>
                <td align="left">The total parseable depth including label stack and PSMH, in 4-octet units.</td>
                <td align="left">This document</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
    </section>
    <section anchor="definition-of-mna-capabilities">
      <name>Definition of MNA Capabilities</name>
      <t>This section defines the parameters that an LSR uses to signal its MNA capabilities to the ingress LER.</t>
      <section anchor="in-stack-mna-capabilities">
        <name>In-Stack MNA Capabilities</name>
        <section anchor="the-readable-label-depth-rld">
          <name>The Readable Label Depth (RLD)</name>
          <t>The Readable Label Depth (RLD) is the number of LSEs an LSR can parse without performance impact <xref target="I-D.ietf-mpls-mna-fwk"/>.
An LSR is required to search the MPLS stack for NAS that have to be processed by the LSR.
To that end, the network actions must be within the RLD of the node.
For HBH-scoped network actions, the ingress LER that pushes the network actions <bcp14>MUST</bcp14> ensure that the actions are readable at each LSR on the path, i.e., that it is placed within the RLD of each node.</t>
          <section anchor="example">
            <name>Example</name>
            <t>An example for the RLD parameter is given in <xref target="fig-rld_example"/>.
With an RLD of 5, an LSR is capable of reading labels A, B, C, D, and E but not F.
An RLD of 8 is required in this example to read the entire MPLS stack.</t>
            <figure anchor="fig-rld_example">
              <name>Example MPLS stack of 8 MPLS LSEs illustrating the concept of RLD.</name>
              <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = A                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = B                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = C                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = D                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = E                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = F                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = G                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = H                   | TC  |1|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="maximum-nas-sizes-mldnas">
          <name>Maximum NAS Sizes (MLD_NAS)</name>
          <t>This section gives a motivation for signaling maximum NAS sizes and then introduces the NAS Maximum Label Depth (MLD_NAS).</t>
          <section anchor="motivation">
            <name>Motivation</name>
            <t>A NAS in the MNA header encoding is at least 2 LSEs and at most 17 LSEs large <xref target="I-D.ietf-mpls-mna-hdr"/>.
At an LSR, one or more NAS, e.g., a select-scoped and a hop-by-hop-scoped NAS, are possible.
With two maximum-sized NAS, an LSR is required to reserve 34 LSEs in hardware to be able to process network actions.
This consumes hardware resources that may be needed to encode other LSEs, e.g., forwarding labels for SR-MPLS paths, or are not available in less capable devices.</t>
            <t>Many use cases in the MNA framework <xref target="I-D.ietf-mpls-mna-usecases"/> do not require a maximum-sized NAS of 17 LSEs to encode network actions and their ancillary data.
Therefore, a NAS can be up to 17 LSEs but nodes can also support smaller maximum NAS.
By signaling the maximum supported NAS size to the ingress LER, an LSR receiving packets with a larger NAS than supported is avoided.
This way, the allocated resources for NAS can be reduced if smaller maximum NAS are supported.
More resources are available for other purposes, and hardware with a low RLD can be made MNA-capable <xref target="IhMe25"/>.</t>
          </section>
          <section anchor="nas-maximum-label-depth">
            <name>NAS Maximum Label Depth</name>
            <t>The maximum supported number of LSEs in a NAS that an LSR can process is referred to as NAS Maximum Label Depth (MLD_NAS) in this document.
For each scope in MNA, a separate parameter for the MLD_NAS exists, called MLD_NAS_Select, MLD_NAS_HBH, and MLD_NAS_I2E.</t>
            <t>An LSR <bcp14>SHOULD</bcp14> signal the maximum-supported size of a NAS for each scope, i.e., the parameters MLD_NAS_Select, MLD_NAS_HBH, and MLD_NAS_I2E.
Those parameters include the Format A, B, C, and D LSEs from <xref target="I-D.ietf-mpls-mna-hdr"/> in a NAS.</t>
            <t>Based on the signaled parameters, the ingress LER <bcp14>MUST</bcp14> ensure the following when pushing the MPLS stack and NAS on a packet:</t>
            <ul spacing="normal">
              <li>
                <t>The ingress LER <bcp14>MUST NOT</bcp14> push a select-scoped NAS that is larger than the signaled MLD_NAS_Select value of the node that will process the select-scoped NAS.</t>
              </li>
              <li>
                <t>The ingress LER <bcp14>MUST NOT</bcp14> push an HBH-scoped NAS that is larger than the minimum of all signaled MLD_NAS_HBH values of all nodes on the path.</t>
              </li>
              <li>
                <t>The ingress LER <bcp14>MUST NOT</bcp14> push an I2E-scoped NAS that is larger than the signaled MLD_NAS_I2E value of the egress node.</t>
              </li>
            </ul>
          </section>
          <section anchor="example-1">
            <name>Example</name>
            <t><xref target="fig-nas_sizes_example"/> illustrates the different MLD_NAS sizes in an MPLS stack that are signaled to the LSR.
In this example, a select-scoped NAS has a maximum size of 4 LSEs, a hop-by-hop-scoped NAS of 7 LSEs, and an I2E-scoped NAS of 4 LSEs.</t>
            <figure anchor="fig-nas_sizes_example">
              <name>Example MPLS stack illustrating the different NAS sizes.</name>
              <artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = A                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ──┑
|      MNA-Label=bSPL (TBA)             | TC  |0|    TTL        |    │ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|   Opcode    |      Data               |R|SEL|0|U| NASL=2|NAL=0|    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MLD_NAS
|   Opcode    |      Data                     |0|U|  Data |NAL=1| _Select
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|1|                  Data                     |0|    Data       |    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ──┚
|      MPLS-Label = B                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MPLS-Label = C                   | TC  |0|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ──┑
|      MNA-Label=bSPL (TBA)             | TC  |0|    TTL        |    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │  
|   Opcode    |      Data               |R|HBH|0|U| NASL=5|NAL=0|    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|   Opcode    |      Data                     |0|U|  Data |NAL=0|    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|   Opcode    |      Data                     |0|U|  Data |NAL=0| MLD_NAS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  _HBH
|   Opcode    |      Data                     |0|U|  Data |NAL=0|    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|   Opcode    |      Data                     |0|U|  Data |NAL=1|    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|1|                  Data                     |0|    Data       |    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ───┨
|      MNA-Label=bSPL (TBA)             | TC  |0|    TTL        |    │ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │
|   Opcode    |      Data               |R|I2E|0|U| NASL=2|NAL=0|    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MLD_NAS
|   Opcode    |      Data                     |0|U|  Data |NAL=1|  _I2E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    │      
|1|                  Data                     |1|    Data       |    │
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ───┚
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="supported-in-stack-network-action-opcodes">
          <name>Supported In-Stack Network Action Opcodes</name>
          <t>An LSR <bcp14>MUST</bcp14> signal the network action opcodes it supports.
If a network action opcode is not signaled, it is assumed that this opcode is not supported by the node.</t>
        </section>
      </section>
      <section anchor="post-stack-mna-capabilities">
        <name>Post-Stack MNA Capabilities</name>
        <t>The Post-Stack MNA solution <xref target="I-D.ietf-mpls-mna-ps-hdr"/> allows network actions and their ancillary data to be encoded after the bottom of the MPLS label stack in a Post-Stack MPLS Header (PSMH).
Section 5.3 of <xref target="I-D.ietf-mpls-mna-ps-hdr"/> requires that each participating node signals its Post-Stack capabilities to the encapsulating node.
This section defines the parameters for that purpose.</t>
        <section anchor="post-stack-mna-support">
          <name>Post-Stack MNA Support</name>
          <t>A node <bcp14>MAY</bcp14> support Post-Stack MNA processing.
The encapsulating node <bcp14>MUST NOT</bcp14> add a Post-Stack MPLS Header to a packet if the decapsulating node does not support Post-Stack MNA processing <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.
Therefore, the ingress LER needs to discover whether each node on the path supports Post-Stack MNA.</t>
        </section>
        <section anchor="maximum-post-stack-mpls-header-size-mldpsmh">
          <name>Maximum Post-Stack MPLS Header Size (MLD_PSMH)</name>
          <t>The PSMH-LEN field in the Post-Stack MPLS Header indicates the total length of the Post-Stack MPLS Header in 4-octet units, excluding the 4-byte PSMH type header <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.
Hardware implementations may have limits on the maximum PSMH size they can process.
The maximum supported PSMH length is referred to as MLD_PSMH in this document, analogue to the scope-specific values of MLD_NAS for ISD.
It is expressed in 4-octet units, consistent with the PSMH-LEN field encoding.
An LSR <bcp14>SHOULD</bcp14> signal its MLD_PSMH to the ingress LER.
Based on the signaled parameters, the ingress LER <bcp14>MUST</bcp14> ensure the following:</t>
          <ul spacing="normal">
            <li>
              <t>The ingress LER <bcp14>MUST NOT</bcp14> add a PSMH with a PSMH-LEN exceeding the MLD_PSMH of any node that will process that PSMH.</t>
            </li>
          </ul>
        </section>
        <section anchor="readable-label-depth-including-post-stack-mpls-header-rldpsmh">
          <name>Readable Label Depth Including Post-Stack MPLS Header (RLD_PSMH)</name>
          <t>Section 5.3 of <xref target="I-D.ietf-mpls-mna-ps-hdr"/> defines the "Readable Label Depth including Post-Stack MPLS Header" as the total depth a node can parse, including both the MPLS label stack and the PSMH.
This parameter is referred to as RLD_PSMH in this document and is expressed in 4-octet units.
When the RLD_PSMH is signaled, the ingress LER <bcp14>MUST</bcp14> ensure that the combined size of the MPLS label stack and any PSMH intended for a node does not exceed that node's RLD_PSMH.</t>
        </section>
        <section anchor="supported-post-stack-network-action-opcodes">
          <name>Supported Post-Stack Network Action Opcodes</name>
          <t>The Post-Stack network action opcode space (MNA-PS-OP) is 7 bits, supporting 128 opcodes <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.
A node <bcp14>MUST</bcp14> signal the Post-Stack network action opcodes it supports.
The Post-Stack opcode space is separate from the In-Stack opcode space; a node may support an opcode in-stack, post-stack, or both.</t>
        </section>
      </section>
    </section>
    <section anchor="lsp-ping-mna-operation-overview">
      <name>LSP Ping MNA Operation Overview</name>
      <t>The MNA capability discovery mechanism operates as follows:</t>
      <ol spacing="normal" type="1"><li>
          <t>The ingress LER sends MPLS echo request messages containing the MNA Capabilities Query TLV. In traceroute mode, echo requests are sent with incrementing TTL values to reach each node on the path. In ping mode, a single echo request is sent to the egress LER.</t>
        </li>
        <li>
          <t>Each node that receives the echo request and supports MNA capability discovery responds with an MPLS echo reply containing the MNA Capabilities Response TLV. The response includes sub-TLVs corresponding to the queried capabilities.</t>
        </li>
        <li>
          <t>The ingress LER aggregates the received responses to determine path-wide MNA constraints. Specifically:  </t>
          <ul spacing="normal">
            <li>
              <t>The path-wide RLD is the minimum RLD reported by any node on the path.</t>
            </li>
            <li>
              <t>The path-wide MLD_NAS_HBH is the minimum MLD_NAS_HBH reported by any node.</t>
            </li>
            <li>
              <t>The MLD_NAS_Select for a specific node is the value reported by that node.</t>
            </li>
            <li>
              <t>The MLD_NAS_I2E is the value reported by the egress node.</t>
            </li>
            <li>
              <t>The path-wide supported opcodes for HBH-scoped NAS is the intersection of opcodes supported by all nodes.</t>
            </li>
          </ul>
        </li>
      </ol>
      <t>The ingress LER <bcp14>SHOULD</bcp14> perform MNA capability discovery before pushing MNA-enabled label stacks onto a path. The ingress LER <bcp14>SHOULD</bcp14> re-query capabilities when the path changes, e.g., due to IGP reconvergence or Fast Reroute activation.</t>
      <section anchor="mna-capabilities-query-tlv">
        <name>MNA Capabilities Query TLV</name>
        <t>The MNA Capabilities Query TLV is carried in the MPLS Echo Request message.
Its format is as follows:</t>
        <figure anchor="fig-query-tlv">
          <name>MNA Capabilities Query TLV.</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  MNA Cap. Query Type (TBA1)   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Query Flags  |                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The fields are defined as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Type: Indicates the MNA Capabilities Query TLV. The value is TBA1.</t>
          </li>
          <li>
            <t>Length: The length of the Value field in octets. For this TLV, Length is 4.</t>
          </li>
          <li>
            <t>Query Flags: An 8-bit field indicating which capabilities are being queried:</t>
          </li>
        </ul>
        <table anchor="query-flags">
          <name>Query Flags.</name>
          <thead>
            <tr>
              <th align="left">Bit</th>
              <th align="left">Name</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">QUERY_RLD</td>
              <td align="left">Query the Readable Label Depth</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">QUERY_MLD_NAS</td>
              <td align="left">Query NAS Maximum Label Depth (scopes)</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">QUERY_ISD_OPCODES</td>
              <td align="left">Query supported network action opcodes for ISD</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">QUERY_PS_MNA</td>
              <td align="left">Query Post-Stack MNA capabilities (support, MLD_PSMH, RLD_PSMH, PS opcodes)</td>
            </tr>
            <tr>
              <td align="left">4-7</td>
              <td align="left">Reserved</td>
              <td align="left">
                <bcp14>MUST</bcp14> be set to zero on transmit, ignored on receipt</td>
            </tr>
          </tbody>
        </table>
        <ul spacing="normal">
          <li>
            <t>Reserved: <bcp14>MUST</bcp14> be set to zero on transmit and <bcp14>MUST</bcp14> be ignored on receipt.</t>
          </li>
        </ul>
        <t>A node that receives an MNA Capabilities Query TLV with all Query Flags set to zero <bcp14>SHOULD</bcp14> respond with all available MNA capabilities.</t>
      </section>
      <section anchor="mna-capabilities-response-tlv">
        <name>MNA Capabilities Response TLV</name>
        <t>The MNA Capabilities Response TLV is carried in the MPLS Echo Reply message. Its format is as follows:</t>
        <figure anchor="fig-response-tlv">
          <name>MNA Capabilities Response TLV.</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA Cap. Response Type (TBA2) |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                   List of Sub-TLVs                          //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The fields are defined as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Type: Indicates the MNA Capabilities Response TLV. The value is TBA2.</t>
          </li>
          <li>
            <t>Length: The length of the Value field in octets.</t>
          </li>
        </ul>
        <t>The Value field consists of one or more sub-TLVs as defined in the following sections. The responding node <bcp14>MUST</bcp14> include sub-TLVs corresponding to the flags set in the Query TLV. If no flags were set in the query, the responding node <bcp14>SHOULD</bcp14> include all sub-TLVs for which it has information.</t>
        <section anchor="rld-sub-tlv">
          <name>RLD Sub-TLV</name>
          <t>The RLD Sub-TLV reports the Readable Label Depth of the responding node.</t>
          <figure anchor="fig-rld-tlv">
            <name>RLD Sub-TLV.</name>
            <artwork><![CDATA[
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      RLD Sub-type (1)         |         Length = 4            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RLD Value   |                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <ul spacing="normal">
            <li>
              <t>Sub-type: 1 (RLD).</t>
            </li>
            <li>
              <t>Length: 4 octets.</t>
            </li>
            <li>
              <t>RLD Value: An 8-bit unsigned integer indicating the number of LSEs the node can parse without performance impact. A value of 0 indicates that the node did not provide an RLD value.</t>
            </li>
            <li>
              <t>Reserved: <bcp14>MUST</bcp14> be set to zero on transmit and <bcp14>MUST</bcp14> be ignored on receipt.</t>
            </li>
          </ul>
        </section>
        <section anchor="mldnas-sub-tlv">
          <name>MLD_NAS Sub-TLV</name>
          <t>The MLD_NAS Sub-TLV reports the maximum supported NAS sizes for each scope. All three scope values are encoded in a single sub-TLV.</t>
          <figure anchor="fig-mld-tlv">
            <name>MLD_NAS Sub-TLV.</name>
            <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    MLD_NAS Sub-type (2)       |         Length = 4            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MLD_NAS_Select| MLD_NAS_HBH   | MLD_NAS_I2E   |  Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <ul spacing="normal">
            <li>
              <t>Sub-type: 2 (MLD_NAS).</t>
            </li>
            <li>
              <t>Length: 4 octets.</t>
            </li>
            <li>
              <t>MLD_NAS_Select: An 8-bit unsigned integer indicating the maximum number of LSEs in a select-scoped NAS that the node can process. Valid range: 2-17. A value of 0 indicates that select-scoped NAS are not supported.</t>
            </li>
            <li>
              <t>MLD_NAS_HBH: An 8-bit unsigned integer indicating the maximum number of LSEs in an HBH-scoped NAS that the node can process. Valid range: 2-17. A value of 0 indicates that HBH-scoped NAS are not supported.</t>
            </li>
            <li>
              <t>MLD_NAS_I2E: An 8-bit unsigned integer indicating the maximum number of LSEs in an I2E-scoped NAS that the node can process. Valid range: 2-17. A value of 0 indicates that I2E-scoped NAS are not supported.</t>
            </li>
            <li>
              <t>Reserved: <bcp14>MUST</bcp14> be set to zero on transmit and <bcp14>MUST</bcp14> be ignored on receipt.</t>
            </li>
          </ul>
        </section>
        <section anchor="isd-opcodes">
          <name>Supported In-Stack Opcodes Sub-TLV</name>
          <t>The Supported In-Stack Opcodes Sub-TLV reports the network action opcodes supported by the responding node using a bitmap encoding. The MNA opcode space is 7 bits, supporting 128 opcodes. Each bit in the bitmap corresponds to one opcode value.</t>
          <figure anchor="fig-opcode-tlv">
            <name>Supported In-Stack Opcodes Sub-TLV.</name>
            <artwork><![CDATA[
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcodes Sub-type (3)         |         Length = 16           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Supported Opcodes bitmap (bits 0-31)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Supported Opcodes bitmap (bits 32-63)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Supported Opcodes bitmap (bits 64-95)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Supported Opcodes bitmap (bits 96-127)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <ul spacing="normal">
            <li>
              <t>Sub-type: 3 (Supported ISD Opcodes).</t>
            </li>
            <li>
              <t>Length: 16 octets.</t>
            </li>
            <li>
              <t>Supported ISD Opcodes bitmap: A 128-bit bitmap where bit N (counting from bit 0 as the most significant bit of the first octet) corresponds to opcode value N. If bit N is set to 1, the node supports opcode N. If bit N is set to 0, the node does not support opcode N.</t>
            </li>
          </ul>
        </section>
        <section anchor="post-stack-mna-capabilities-sub-tlv">
          <name>Post-Stack MNA Capabilities Sub-TLV</name>
          <t>The Post-Stack MNA Capabilities Sub-TLV reports whether the node supports Post-Stack MNA processing, the maximum PSMH size, and the RLD including PSMH.</t>
          <figure anchor="fig-psd">
            <name>Post-Stack MNA Capabilities Sub-TLV.</name>
            <artwork><![CDATA[
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    PS MNA Cap. Sub-type (4)   |         Length = 4            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   PS Flags    | MLD_PSMH      |  RLD_PSMH    |  Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <ul spacing="normal">
            <li>
              <t>Sub-type: 4 (Post-Stack MNA Capabilities).</t>
            </li>
            <li>
              <t>Length: 4 octets.</t>
            </li>
            <li>
              <t>PS Flags: An 8-bit field.
              </t>
              <ul spacing="normal">
                <li>
                  <t>Bit 0: PS_SUPPORTED. If set to 1, the node supports Post-Stack MNA processing as defined in <xref target="I-D.ietf-mpls-mna-ps-hdr"/>. If set to 0, Post-Stack MNA is not supported and the remaining fields in this sub-TLV <bcp14>SHOULD</bcp14> be ignored.</t>
                </li>
                <li>
                  <t>Bits 1-7: Reserved. <bcp14>MUST</bcp14> be set to zero on transmit and <bcp14>MUST</bcp14> be ignored on receipt.</t>
                </li>
              </ul>
            </li>
            <li>
              <t>MLD_PSMH: An 8-bit unsigned integer indicating the maximum Post-Stack MPLS Header length (in 4-octet units, excluding the PSMH type header) that the node can process. A value of 0 indicates that the node did not provide this value. The valid range corresponds to the 8-bit PSMH-LEN field defined in <xref target="I-D.ietf-mpls-mna-ps-hdr"/>.</t>
            </li>
            <li>
              <t>RLD_PSMH: An 8-bit unsigned integer indicating the Readable Label Depth including the Post-Stack MPLS Header, in 4-octet units. A value of 0 indicates that the node did not provide this value.</t>
            </li>
            <li>
              <t>Reserved: <bcp14>MUST</bcp14> be set to zero on transmit and <bcp14>MUST</bcp14> be ignored on receipt.</t>
            </li>
          </ul>
        </section>
        <section anchor="supported-post-stack-opcodes-sub-tlv">
          <name>Supported Post-Stack Opcodes Sub-TLV</name>
          <t>The Supported Post-Stack Opcodes Sub-TLV reports the Post-Stack network action opcodes supported by the responding node.
The Post-Stack opcode space is 7 bits (128 values), identical to the In-Stack opcode in <xref target="isd-opcodes"/> but independent from it.
For the supported PSD Opcodes Sub-TLV, the sub-type 5 (Supported PSD Opcodes) is used.
The format is identical to <xref target="fig-opcode-tlv"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="processing-rules">
      <name>Processing Rules</name>
      <t>This section defines the processing rules for querying and responding nodes.</t>
      <section anchor="ingress-ler-querier">
        <name>Ingress LER (Querier)</name>
        <t>The ingress LER constructs MPLS echo request messages containing the MNA Capabilities Query TLV.
In traceroute mode, the ingress LER sends echo requests with TTL values from 1 to the path length. This allows discovery of MNA capabilities at each hop.
Traceroute mode <bcp14>SHOULD</bcp14> be used when HBH-scoped network actions are planned, as the ingress LER needs the capabilities of every node to correctly place NAS copies within each node's RLD.
In ping mode, a single echo request with TTL set to 255 is sent.
This is sufficient when only I2E-scoped network actions are planned, as only the egress node's capabilities are needed.
After collecting responses, the ingress LER computes path-wide constraints as described in Section 3.
The ingress LER <bcp14>MUST</bcp14> ensure the following when constructing MPLS stacks with MNA:</t>
        <ol spacing="normal" type="1"><li>
            <t>A select-scoped NAS pushed for a specific node <bcp14>MUST NOT</bcp14> exceed that node's MLD_NAS_Select.</t>
          </li>
          <li>
            <t>An HBH-scoped NAS <bcp14>MUST NOT</bcp14> exceed the minimum MLD_NAS_HBH across all nodes on the path.</t>
          </li>
          <li>
            <t>An I2E-scoped NAS <bcp14>MUST NOT</bcp14> exceed the egress node's MLD_NAS_I2E.</t>
          </li>
          <li>
            <t>All NAS intended for a node <bcp14>MUST</bcp14> be within that node's RLD.</t>
          </li>
        </ol>
        <t>When Post-Stack MNA is used, the ingress LER <bcp14>MUST</bcp14> additionally ensure:</t>
        <ol spacing="normal" type="1"><li>
            <t>The ingress LER <bcp14>MUST NOT</bcp14> add a Post-Stack MPLS Header to a packet if the decapsulating node does not have the PS_SUPPORTED flag set.</t>
          </li>
          <li>
            <t>The PSMH-LEN of any Post-Stack MPLS Header <bcp14>MUST NOT</bcp14> exceed the MLD_PSMH of any node that will process the PSMH.</t>
          </li>
          <li>
            <t>The combined size of the MPLS label stack and any PSMH intended for a node <bcp14>MUST NOT</bcp14> exceed that node's RLD_PSMH.</t>
          </li>
        </ol>
      </section>
      <section anchor="responding-node">
        <name>Responding Node</name>
        <t>A node that supports MNA and receives an MPLS echo request containing the MNA Capabilities Query TLV <bcp14>MUST</bcp14> respond with an MPLS echo reply containing the MNA Capabilities Response TLV.
The responding node <bcp14>MUST</bcp14> include sub-TLVs corresponding to the flags set in the query.
If the QUERY_RLD flag is set, the RLD Sub-TLV <bcp14>MUST</bcp14> be included.
If the QUERY_MLD_NAS flag is set, the MLD_NAS Sub-TLV <bcp14>MUST</bcp14> be included.
If the QUERY_ISD_OPCODES flag is set, the Supported Opcodes Sub-TLV <bcp14>MUST</bcp14> be included.
If no Query Flags are set (all zero), the responding node <bcp14>SHOULD</bcp14> include all available sub-TLVs.
The reported capabilities are those of the node as a whole.
If capabilities vary per interface, the node <bcp14>SHOULD</bcp14> report the capabilities applicable to the interface on which the echo request was received.
If the QUERY_PS_MNA flag is set, the Post-Stack MNA Capabilities Sub-TLV (sub-type 4) <bcp14>MUST</bcp14> be included.
If the node supports Post-Stack MNA and the QUERY_PS_MNA flag is set, the Supported Post-Stack Opcodes Sub-TLV (sub-type 5) <bcp14>MUST</bcp14> also be included.</t>
      </section>
      <section anchor="mna-incapable-nodes">
        <name>MNA-incapable Nodes</name>
        <t>A node that does not support MNA will not recognize the MNA Capabilities Query TLV.
According to RFC 8029, the handling depends on the TLV type value range.
The TLV type for the MNA Capabilities Query TLV <bcp14>SHOULD</bcp14> be assigned from the range that requires an error message if the TLV is not recognized.
This allows the ingress LER to detect nodes that do not support MNA.</t>
        <t>If a node does not support MNA, but recognizes the MNA Capabilities Query TLV, it <bcp14>MUST</bcp14> reply with the Return Code TBA3 for MPLS echo reply messages.</t>
      </section>
    </section>
    <section anchor="example-2">
      <name>Example</name>
      <t>Consider an SR-MPLS path with three LSRs: R1, R2 (transit), and R3 (egress). The ingress LER R0 wants to push an HBH-scoped NAS and a select-scoped NAS for R2 along this path.</t>
      <t>R0 sends MPLS echo requests in traceroute mode with all Query Flags set. The responses are:</t>
      <table anchor="table_example_ping">
        <name>Example MNA Capabilities Responses.</name>
        <thead>
          <tr>
            <th align="left">Node</th>
            <th align="left">RLD</th>
            <th align="left">MLD_Select</th>
            <th align="left">MLD_HBH</th>
            <th align="left">MLD_I2E</th>
            <th align="left">PS_Supported</th>
            <th align="left">MLD_PSMH</th>
            <th align="left">RLD_PSMH</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">R1</td>
            <td align="left">20</td>
            <td align="left">9</td>
            <td align="left">9</td>
            <td align="left">0 (not egress)</td>
            <td align="left">Yes</td>
            <td align="left">16</td>
            <td align="left">36</td>
          </tr>
          <tr>
            <td align="left">R2</td>
            <td align="left">51</td>
            <td align="left">9</td>
            <td align="left">3</td>
            <td align="left">0 (not egress)</td>
            <td align="left">Yes</td>
            <td align="left">8</td>
            <td align="left">59</td>
          </tr>
          <tr>
            <td align="left">R3</td>
            <td align="left">35</td>
            <td align="left">9</td>
            <td align="left">9</td>
            <td align="left">9</td>
            <td align="left">Yes</td>
            <td align="left">16</td>
            <td align="left">51</td>
          </tr>
        </tbody>
      </table>
      <t>From these responses, R0 determines:</t>
      <ul spacing="normal">
        <li>
          <t>Path-wide RLD: min(20, 51, 35) = 20 LSEs</t>
        </li>
        <li>
          <t>Path-wide MLD_NAS_HBH: min(9, 3, 9) = 3 LSEs</t>
        </li>
        <li>
          <t>MLD_NAS_Select for R2: 9 LSEs</t>
        </li>
        <li>
          <t>MLD_NAS_I2E: 9 LSEs (from R3)</t>
        </li>
        <li>
          <t>Post-Stack MNA is supported on all nodes (PS_SUPPORTED set at R1, R2, R3).</t>
        </li>
        <li>
          <t>Path-wide MLD_PSMH for HBH-scoped PSMH: min(16, 8, 16) = 8 (in 4-octet units).</t>
        </li>
        <li>
          <t>MLD_PSMH for I2E-scoped PSMH: 16 (from R3).</t>
        </li>
        <li>
          <t>Path-wide RLD_PSMH: min(36, 59, 51) = 36 (in 4-octet units).</t>
        </li>
      </ul>
      <t>R0 can now construct a label stack ensuring that all NAS are within each node's RLD and do not exceed the per-scope MLD_NAS constraints. For Post-Stack MNA, R0 ensures that the PSMH does not exceed the path-wide MLD_PSMH and that the combined label stack and PSMH do not exceed any node's RLD_PSMH.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations described in <xref target="rfc8029"/> apply to this document.
The MNA capability discovery mechanism reveals information about node capabilities, which could potentially be exploited by an attacker to craft targeted attacks against nodes with limited MNA support.
Nodes that support MNA capability discovery <bcp14>SHOULD</bcp14> support configuration options to enable or disable the MNA Capabilities Query/Response functionality.
By default, MNA capability discovery <bcp14>SHOULD</bcp14> be enabled only within an MNA-capable MPLS domain.
The security considerations from <xref target="I-D.ietf-mpls-mna-hdr"/> and <xref target="rfc9789"/> also apply.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This section requests new TLVs and sub-TLVs.</t>
      <section anchor="tlv-assignments">
        <name>TLV Assignments</name>
        <t>IANA is requested to assign two new TLVs from the "TLV" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group.
The TLV values <bcp14>SHOULD</bcp14> be assigned from the range that requires an error message if the TLV is not recognized.</t>
        <table anchor="table_iana">
          <name>New TLVs.</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">TLV Name</th>
              <th align="left">Reference</th>
              <th align="left">Sub-TLV Registry</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA1</td>
              <td align="left">MNA Capabilities Query</td>
              <td align="left">This document</td>
              <td align="left">No</td>
            </tr>
            <tr>
              <td align="left">TBA2</td>
              <td align="left">MNA Capabilities Response</td>
              <td align="left">This document</td>
              <td align="left">See <xref target="table_iana2"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="new-sub-tlv-registry">
        <name>New Sub-TLV Registry</name>
        <t>IANA is requested to create a new sub-TLV registry for TLV TBA2 with the following initial entries:</t>
        <table anchor="table_iana2">
          <name>Sub-TLV Registry for TLV TBA2.</name>
          <thead>
            <tr>
              <th align="left">Sub-Type</th>
              <th align="left">Sub-TLV Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">RLD</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">MLD_NAS</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">Supported ISD Opcodes</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">Post-Stack MNA Capabilities</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">Supported PSD Opcodes</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="return-code-assignment">
        <name>Return Code Assignment</name>
        <t>IANA is requested to assign a new Return Code from the "Return Code" registry in the "Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group as follows</t>
        <table anchor="table_return_code">
          <name>New return code.</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Meaning</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA3</td>
              <td align="left">MNA not supported</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="IhMe25" target="https://ieeexplore.ieee.org/document/10947349">
          <front>
            <title>MPLS Network Actions; Technological Overview and P4-Based Implementation on a High-Speed Switching ASIC</title>
            <author initials="F." surname="Ihle" fullname="Fabian Ihle">
              <organization>University of Tuebingen</organization>
            </author>
            <author initials="M." surname="Menth" fullname="Michael Menth">
              <organization>University of Tuebingen</organization>
            </author>
            <date year="2025" month="April" day="02"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/OJCOMS.2025.3557082"/>
          <format type="PDF" target="https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&amp;arnumber=10947349"/>
        </reference>
        <reference anchor="I-D.ietf-mpls-mna-hdr">
          <front>
            <title>MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data</title>
            <author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Royi Zigler" initials="R." surname="Zigler">
              <organization>Broadcom</organization>
            </author>
            <author fullname="Haoyu Song" initials="H." surname="Song">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
              <organization>Juniper Networks</organization>
            </author>
            <date day="24" month="February" year="2026"/>
            <abstract>
              <t>   This document specifies the MPLS Network Actions (MNA) sub-stack for
   carrying Network Actions and Ancillary Data in the MPLS label stack.
   MNA can be used to influence packet forwarding decisions, carry
   additional Operations, Administration, and Maintenance information in
   the MPLS packet or perform user-defined operations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-hdr-21"/>
        </reference>
        <reference anchor="I-D.ietf-mpls-mna-ps-hdr">
          <front>
            <title>Post-Stack MPLS Network Action (MNA) Solution</title>
            <author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Royi Zigler" initials="R." surname="Zigler">
              <organization>Broadcom</organization>
            </author>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Jisu Bhattacharya" initials="J." surname="Bhattacharya">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <date day="24" month="February" year="2026"/>
            <abstract>
              <t>   This document defines the Post-Stack MPLS Network Action (MNA)
   solution for carrying Network Actions encodings and Ancillary Data
   after the MPLS label stack, based on the In-Stack MNA solution
   defined in "MPLS Network Action (MNA) Sub-Stack Solution."  MPLS
   Network Actions can be used to influence packet forwarding decisions,
   carry additional Operations, Administration, and Maintenance
   information in the MPLS packet, or perform user-defined operations.
   This solution document addresses the Post-Stack network action and
   Post-Stack data-specific requirements found in RFC 9613.  This
   document follows the framework specified in RFC 9789.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-ps-hdr-07"/>
        </reference>
        <reference anchor="I-D.ietf-mpls-mna-fwk">
          <front>
            <title>MPLS Network Actions (MNA) Framework</title>
            <author fullname="Loa Andersson" initials="L." surname="Andersson">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Stewart Bryant" initials="S." surname="Bryant">
              <organization>University of Surrey 5GIC</organization>
            </author>
            <author fullname="Matthew Bocci" initials="M." surname="Bocci">
              <organization>Nokia</organization>
            </author>
            <author fullname="Tony Li" initials="T." surname="Li">
              <organization>Juniper Networks</organization>
            </author>
            <date day="27" month="December" year="2024"/>
            <abstract>
              <t>   This document describes an architectural framework for the MPLS
   Network Actions (MNA) technologies.  MNA technologies are used to
   indicate actions that impact the forwarding or other processing (such
   as monitoring) of the packet along the Label Switched Path (LSP) of
   the packet and to transfer any additional data needed for these
   actions.

   The document provides the foundation for the development of a common
   set of network actions and information elements supporting additional
   operational models and capabilities of MPLS networks.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-fwk-15"/>
        </reference>
        <reference anchor="rfc9789">
          <front>
            <title>MPLS Network Actions (MNAs) Framework</title>
            <author fullname="L. Andersson" initials="L." surname="Andersson"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="M. Bocci" initials="M." surname="Bocci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <date month="July" year="2025"/>
            <abstract>
              <t>This document describes an architectural framework for MPLS Network Action (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet and to transfer any additional data needed for these actions.</t>
              <t>This document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9789"/>
          <seriesInfo name="DOI" value="10.17487/RFC9789"/>
        </reference>
        <reference anchor="I-D.ietf-mpls-mna-usecases">
          <front>
            <title>Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data</title>
            <author fullname="Tarek Saad" initials="T." surname="Saad">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Kiran Makhijani" initials="K." surname="Makhijani">
              <organization>Independent</organization>
            </author>
            <author fullname="Haoyu Song" initials="H." surname="Song">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
              <organization>Ericsson</organization>
            </author>
            <date day="23" month="September" year="2024"/>
            <abstract>
              <t>   This document presents use cases that have a common feature that may
   be addressed by encoding network action indicators and associated
   ancillary data within MPLS packets.  There is community interest in
   extending the MPLS data plane to carry such indicators and ancillary
   data to address the use cases that are described in this document.

   The use cases described in this document are not an exhaustive set,
   but rather the ones that are actively discussed by members of the
   IETF MPLS, PALS, and DetNet working groups from the beginning of work
   on the MPLS Network Action until the publication of this document.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-usecases-15"/>
        </reference>
        <reference anchor="rfc8029">
          <front>
            <title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <author fullname="N. Kumar" initials="N." surname="Kumar"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <date month="March" year="2017"/>
            <abstract>
              <t>This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.</t>
              <t>This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8029"/>
          <seriesInfo name="DOI" value="10.17487/RFC8029"/>
        </reference>
      </references>
    </references>
    <?line 562?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+0923LjRnbv+IqOpiorJQQlUtJcuDvr5Ywkj1K6mdTYcVKp
KZBsiohJAAHAkeWRU6n8Qar2aZ/ymO/Ip+yX5Fy6G924kByb4504oV0aEujL
6dOnz63P6fZ938vDfC57YmcY3kXBPIzuxOVVX7wOkmAUzsM8lJl4m+Hji+GN
uIEvO14wGqXyPdY5/3LHGwe5vIvTh57I8onnTeJxFCygxUkaTHM/nM1lFkd3
/iKZZ/4iCvxMd+QfdLxsOVqEWRbGUf6QQKXz09szIZ6IYJ7F0EEYTWQi4U+U
77TEjpyEeZyGwRx/nPdfwT9xCt8Gt2c7XrRcjGTa8yYAT88bx1Emo2yZ9USe
LqUH4B56QSoDaHUQL3MayH2cfneXxssEHl4u53mYpHEej+O5uAhGci6G92E+
nlHR7+QDlJ70POELMwL8geOif6PAey+jJfQtxIaNCsGj3vkGAEEcf4n18Pki
COfwHBv/QyjzaTtOqXyQjmfwfJbnSdbb38di+Ch8L9u62D4+2B+l8X0m97GB
fax4F+az5QiqLqPQz5fS/y7aXztDWHEO6Mxyq8+igTY32g7j9U2tL9Ge5Yv5
jucFy3wWp4ho6F2I6XI+Z4I6A4oMInEOTdAbGGsQhT8EOVBPT7yNAAlpFuYP
Ip6K26UcQZsyopJjeNorP4uXUY5U+6VMF0H0QA8l431KPbUR2D+o4XLN9kRW
4fr7pXwAuIYxEkQFrn+4PRWv4zSJU3rg9v0a6CCwe0bctL+nBrt/+CGX7XG8
aI+jaqeX4XgWADVdwtKYfWJ0LLiv9gL7qiLEi2KokkN/Pc8Lo2nxS8BkXcru
cY9a83sinC3gJ/3Kg/ROAl1psgqllN8n8zhFSpaSKBl4yRI73e8cvDh6dnj0
gmsyx7q8uRiKK5njIhb9MQ47+624leNZFM/ju3AczMU14OB9KO9FEE3EzZH/
KsjkRJwD8Ulsl3Al4P9AvAnvZv4wkfDaLFDRH56/pi4NTdLHV/8KEUbAX87a
BU3ip55a1RStnplK25dta4aLxquzv1HzmUyBn+MU6aGcXJ/3ROeg3QEM71//
3evry2G7e9A9bh8eHz87eN6lYsRRBT72D478A37I06zbuTk5Wz2VWR4sEv7b
/ucs+SJPXv51kDLPfmmmFz6+74tglOVpMM4973YWZkKTgZjIaRiBQArEAqYZ
qD1bIBxiEmbjGEZN0quGLMQuyLQ9MbaFWjCHpQYt2UwZJv8myGdiF2TdnliS
2Mtn0og+Ab3GIpX/sgSWuJ/KZP5gQcLQTWDixODstXh+0H3RFrdQ3ek3jMbz
5URSuwMZTILRXCogTmSCnQ8uTvZa9H4RfB8ulgsQOD9ATZjOSTidyhRQAR3D
kBPozR2qGC5HPmB5/B0O+uLk3VV/CI0h+WfLBJhQDlUiVSXgKnEyjicyQ1gB
2cV4gvkcZAgBAmNPZZYpOE8ndwA7CFGZAqpOB3sij80ckPrgjBjglsF4BnI4
iIAuCRjJ7UXQMa4/7CMBzLeEjAAhiOpxnKZynAsU5CDBFahTnt85waHGCSXy
IIy06uKOLmszSS3CyQRWovdEnAOfiyfcoIfTs4JipiksN3r+4cMX5/4JCdlC
ds0m6Y8/CpDv78MJkSUsNJkC33HJU0aAYASvBBphAoYeprjEAiScXMNjjbDt
XZXrpZIbZWpbQQI4/dBokFOdZB6MoQrQOrA3sXs+PNlDBWoa40wLkM84oTf4
tB4OwhageAZ0K61x4RotiL8ZVdBCrCcWKNhM7epJLWGt5VLk6QAKyEmGNPhd
BMPIFZC1NEgEx0tf01zbOwMc3MRZ7g+xb6xc7SOYgO4J3cOieCg6NER/P5NQ
I6X2M73UnEZxhG8Ibzzv9zgpVoEybUBzgCGQIEBeY4ACFnFGrCdMAc2jBzGU
PN3Aq3F4tVhPMoP4mczqOREI7Q5IsKgYvVOMOLxPfKyZXfUIX8zNERjFVKnB
U1hv2B0w1dNsDxYJzQGNLEgBJqRG4CUikSnJlGgMmF8kgId20TXQsbhU3NDp
XfO4nsswDa/Disg+eSEiCRDfFLuZnAMCW+LNqzctcd493bN6K6obtDTwTK/b
LpFOHfK+UdRBSMLRqw6ycl0110j1wfo1pWe3VUCuEVBPebi4L9/sMUIIdfTb
qg+TqehCyz4sQZPMZeuQ1EjFBZoaBHkEqtntxdcZzY7hObVSNsuCO6jx4UM6
HaNoBcYLCxDKpA+0nqAcLrnyDLAELvixwfwoBvLZSdDKEQuck11qC4cdR9Aj
QmNJqT3qZAfVEpmi6KvUAs6glr/LX4CwvCdPQDFNFyFppg8eMVKwKAWalBmY
iW+Ht2jS4r/i6pq+D06/ens+OD3B78M3/YsL88VTJYZvrt9enBTfipqgxl2e
Xp1wZXgqnEfezmX/2x1WCnaub27Pr6/6FzssfexJQokBKB4hIwTJkKQSJzvI
PBjjOA1HTJmvXt/89392jmBi/gq0nm6ngzPDP553nh3BD+CNEfdGiOWfyN68
IElkkGIriDyYtjAHw584XTaL7yMQNKBDet7f/CNi5p964nejcdI5+r16gAN2
HmqcOQ8JZ9UnlcqMxJpHNd0YbDrPS5h24e1/6/zWeLce/u4LUHyk8DvPv/i9
hzTzRPTJ0xKSnZKV1tAi+A5obQkcFBguEhvM0WJDQUyz0VRiev8dSgzv0ele
PIorUIZE3ecRuDGSREIFt/p5BKlDKu+4oWsA07c+wv254auf+1nXNIGJosga
V5PWBq/6rAXhxKYSHTATgcLTURC5RLOaRFMMwjSczwNgkahgtqFpmHFgoC+e
PcdlWotNFAEO+muEPr+6dWU+QliW7u2fOOkrSFeBqQS/wWaDgqDA1HKxBC5y
HqrKKrIFvFa69HIC7YQ1h7YNprsi67BJ4rOo0CCXNZhKsWZNHKf61fUQ4ElZ
wiRYOavVFusmew02tfagwHQm3QLzBC0T61XFFoGeyXrRBkkBfMWA+CmT7oB5
7oJptDMXyI3AVEbQR8O5KW2aid+YNqkGqWZ1hAiwHvnxOJe5WEZhnq1ZWZvQ
5sAF09X9LMJlMPMYhDOvauIHExpDUcFCILvboIG1YK8H80NPPMmxw3e87cDu
v5c7jmhs7/yIEhPwCqs1NK6C0kaG0kIzZThpJZQVNbT0czTOmBVEwCAGKF3J
zmMntQD4q6YlvC4Zi6zwORaVCwaK9tUGFauIze/R5M5r2C+DvYlxtVL297md
0LI4EQsStxbKIghVd8NCZ8F7rTQqymVjlb1oA3IAUEEZTdjILnOyxTLLsbq1
PpEwlY6D64INdrDbfOUCW+sgoB6TZTZTs13uk5RJ3C1CjRfLYiHb2ZLqiUDI
0YhE7Dh+q7At2y2uHOaIONfXYg3D+CGITIASTr8P0CHtIdYlfzf2ENYxtInN
3oXvZcSq2zS889P55J2qg/P2DfSGRKC6Om5pioCaRLRzyUpFUCzZTPRb4lVL
vG6JE1bTT8UISCaKc3FGpKBae+7QgzYXNMR5TM2y3RTlUMYiEhjqv8LHEwc1
rKpT86xb8+wQq3fg1aE4EsfiqXgGIL34mGfe3/o/8z/gmvTBofm8Kl+CulbL
f1/D3wMqf3t7UTC0TwPDq88AhtefAQwnnwEMp58BDGefAQxffgYwvGmGofMp
YCA2hzpLiTtrtUUxe1uAEmul32yTzOdL3P7KtQcObLwxSH4sB5yYVB0UG1qj
RNk7pA0i4wx19RwUGbRnFufhe7blUbyYjXejgGpfqdmYQEHDmyVKcK51w2qZ
dmn68vpUS6va9bsHIDXnMgDB39V6zASfLcAMEZ1n/GyOG8YrNxf6Wm9rgWyW
uLOxiFMCuiVk+w7kcyDY7as1B+pHzOLEHz34+I/eVMMqtGMSZ1kIUlOJVlAb
NLZ8xJQuWasugfohU1CHDo+MsTkL0sl94VcjeQxflapU3bqiecRtEtCOs6I2
tBwvU54URFPwgK3hrgT3zDaOiMnpjH3r8cO8QwO27EdKGA58Ij/UZDIKqcFO
UP4H7zHABKEE4OcIotYiJqB7j8mzexlED+SGGgeZzOyJXrN7BnWoCthNk5i6
U9hDWi0jGalfU0IxwuYNtZIxjOp0KmGwsqUsftSRAWnLBJvTLbPegz5cfI1B
SGYvJ1sE8zmg01osbe/Vg7WM1mxAVO0EQzipHMvwPZn4wBAkWBn3pMgxzRv1
OrKaxUXzPg5hwhWV3AcPrPjitu2YfEYFmWgdXQ0aCHSJymk4rRsWzb7pqe1d
xg7J4duCLrBlprNkmcJqkRnrkIZW9Ujie9IjFQQLYAFII76mpw8fOFSEPI/E
Qhp4jXdbi+bVjh3LLFJLjdbqVKZqrQbZet5W8ZCzIWJtKkEB2jxENoNae24Z
lsUWh3Jcye/DLAdsjXECJvrxu6Hal9K/aX8KMaofnHdP25620JSHWtmnFgX6
BWqI+gAxjBB3H6wwXBwb+OOAuZ3BvNvV7RiHM4oTKWwMrH3CkzRN48Uqb4qe
RBguB+4oi4tHi04502XV5nNtOqk2uXGN4QYEWYN60VqyGKEjboNd82LseR5v
eFVaR38/tlMRK4bwwkwvYVq+DvAujsX7YL6UtpnLLdwDFzNES/XLPbXXgxfZ
1vIq4BZhRPSP1AL9VmCFZhjQTBdhbmmZwhuBA2Tzk3AF9VxEWTt0FXOaLeQo
yN6RUlPYyYWKpdQaE1ZjFierQUiAkU0eJpLCQKa4Ovk2zl2TuKpuYMuzICvk
m1mbR0pMNygjWOSZLkKu3jIKTRva1P406vQvbOoK8ec//hv9/x8GHBAaBM3L
0fDmQuzevurvbQYO/vnzH/9dbAMsaolAuqYtbtOBqPii8c3gcXh6ASC9JWfw
xcvu41X/4uWBBmkLECnC3RgkBRiBxO8JJLCJFEPaIpY6j9WeV4FUer9FLBly
+tP/O1HKKNneCtsa6QjxMUsMhJO1xI63vsTExy16BVd5hX2WEGnusQWQUEf4
9eGo8wkg+nzYomYB8P9//S+Xs6AW/S+RswK12S2ySvx8LFF1fhmi+pPrFq2o
5CucoxVvaKGrGz1d7f6C7j+sBm6Wwmx4zjJtP5NlYlnP9fGLuKWnAwdBzUdT
urYg2jDox9LWQUvtBQYZOvAmem8RnpTKG7DVVqmxZ8oBos4+MppZpfdZPF8S
QKtjKVRo/6buM+WurEZ4jOI8jxfaGCvHUbABvzIUte19TBizdhAqvye5MZIg
zcNxmDCFcHQtoT+j7Xqr97pdexhSkGTLeVG7vVGQADtzaFeZvF5sfJZnQ5Gj
12e4Lvvf1oaGO4G/HGVfhaswooPJpBmt6MtSjgt079GKkZW2JrF0KG9FHPL6
uHLtV20My69EyReh+JbjoCkouu1udzSMe+iGNPPagG/+xemVmIZyPtGe6YYG
wmgSjo1HgINd5jK6A8AUeTdWdCNcWmD/2wHUR2DO5yqOGtM99f7HGsS+0Q7U
0MlWy8jbT2EW83CBFK5QWI0iKmcQtBtcp1RDDbXqFjWxTGXvJ3oignl8tzSu
bXJH+Fkix+E0HFuOIu1VwVVzPjwBFkpsUX6fpBwhUsUhbnqEWY58njzIeXU+
9QZSu94ZSsE6Gvi6IJ0t+hRX+wjVgkU4lDfcjARIBVaJcURqcNG5Fj00uwEx
dQTKqaVRGyZ0XkRyNTDgIqb/o3iwzRF3arsO13S9g3RVrDIOJCtHjrasZihW
v1bCKImlsEGc2wmXKRHzoImYOSB6FUm2vW/Qb6yCclQrmSXqVxOLCioax4sR
xZNqx1/jqHD+Fag5ZsBPaPUEJf7N9MPt45vfFGNsl1UiazIalKKSQlGv42Qg
XSTlx/k3Q//6hmLRnokRLVvFVXDSOt3nRn9aw+v6loSzlLG1eSWuXlaC3gGX
JLrakqFtB2zf6Ih20d9qHCOf1eIxKDS8iCNwW1Y0Lm2ZIo0iyotkURSk14nk
vG+TimyS6Iw68mAEpJ1NGlNN3G/LFJ/JOFOrwmcyII+smjlT5MxYQeJ6a9Y5
3+ErSqK5vfga08BEkeJCGS4tp1He/ssMW4Y1mpJwwsbRCFRMn6PBQMrXinrq
J6HQA+ohEKhqABdx4Kc5g460qmax7m5bnJqGifh5C1WxJacZK/c1a0Y8tJ3E
iMd7FUJn4zPhZMWVSBxQA5lkPOIcpfqJ2g7DvMCRT+lOlANJHVJ7PEDMJAph
nTrpS95huzLhwR18vzO6ihr6xHTISheywAUmlCDG/ftwosiOki5hJBiLO1Sy
GrMagbrIBGRBVlSisODM2R7CR5xvxSaLkVXOPlBta/ZOUqlV+1Vd606Lpd0z
5o1G9YiUcYXN836R3aDhlrUt4h7TiqqlPafaQRa6lWZUUzdilSJidGo16hrS
5DfrGo5NaHba2hwYbFOD0npUhG8zhY9ITTcbn8i/KdkaenAyb4HO2YbAddrQ
WSp9zrxzbKp7LSBJnUdGdidN6MmE9cTzL2+QYOMIYLqjrB7AzBmG/gwU00EW
z6FDbAE3syvDSutfc9BrSmvKjvQ/xUU9cJkkqqSZOtOALXaL6f56QlcVstoa
SWiOoGevsyeME4s/F2wPON6i7cDAXZ/Ng7us1Kf6DDhualLzavshekTGfj43
eQUrpCO6mZDkyPxgSajTgxx68QmxPRBytkm5SuzeGmYDtIfzgbvoPAU9eula
ol9TUWPVkpYK3PyMnBLYwsXXLT2D8PMIW7PQ3hNgMD33QWMzbRCgHBwRglx1
T8qAcY4kvlQSqoe5ga+gdl1K4HZzAVV6X11+3XbT+ainA4L/q7eng2/f2Wlw
jwp7eVNOxkePqWP1ZGey6Z4ag5FIgGR7q3uwe+paPYHt/e765vX1yenQ9LTu
WBBttK/v6dDq6Wb4DundGdOKPHkYF4PRMjZwyxgyLbCDNDR71NOR/4wyE8t8
4pFNiBFqqKQ3/gAyhZQSPHpkEULzYF3EKZv9pDcl1ZyjYkzIJJhBTIldKRZh
LSXiCb4BpbcOAA6eUmWqsGBgV51SG0Sr5ByrrKAi2KzVBsBIbVI5i/JFGF8l
bb5e9NpKbr30tUusEcBWXj8YBP8HxK+RvgWStADu7v1S4vdnfR69/f2axxdh
RuHpQ23fNH7297cAw5ZVAG02rdQCHPNuy4pA1XS0dYHuT9EFGD77nXKokj/W
jo43Nql74IgbMqnsk8w2bCfuzoSO+Vxt404Nb1J92L6HKTSnStzLVNrFiAu3
lLnr9q6Ym+6f4hY1DCi7WKMJc4q8M8fTKeviCdmyim4557L4rSy/rFnuqzko
gaRD8H4FLIs+GiW0e7HbKZSPYikrfvUSgNjyUn1UADAtfwYWQzqf2JzCohel
DGhU9WBeKFnXXsBHZoX6xbAshXwZoQOU1mAu74p9Ke13KsW5m2Dhjc5TEv0i
evbA2fFS7ml2LocT8i2rc810PinVbG9X2aGNPaX+2ouw9MxZiM0pFlkpuB3G
O0dPcirV3pT2TpbOTzPuR8U3fmXZqjYyeQl39RL+ZRaw66t7dBx9pLRbnjeC
yVnPW1/AC3cBl2itsoi7dnZb/UJ2B/gRq3nVsSQNKQXuilc7u8hGYNWm6HED
iP3Os9Vrvdq2zviy8n58e6K2M6j6RIStDKnU8MrxAKFtazx1mQxbGU+p4drx
bJkT10RPqZ1Bw4g/PAmzia+McaUFb1DN5t8NboZKDFRZz+PjWAPcaFwESbH7
L7QdWt7wW70nqXaQkACUjqkaLvRW2kchXZlbVhLw16Pc2dPEkuFwpXLXebp1
2WB/CkLSgKkp2cWJFAf+Yafk+PrFYTjs+k8P9/6yMDw98l8c/4VhePHU73Sf
7W0bBkdO86qzRfV6TlOR3odi16o1PNEVHFkOdF0I89riavQgNZCHkNhQ+LjH
ADhiI1dil05RR0ZDMQb48EDHulAuOwoa2m+NqL62H6dhig4UBGGvwn8s3iOu
yErmzkLj4+u0CpFjdrpVvfoaB1aNSiygqVkb0+h4LmydfYNyRg7cf/yBqO6J
2CbKrWVCgKrHV/2aWLVAJ7hxIBYM+8jdufu0djiAoPbttNpenBL2KJzzxMpa
/PbZQ5JNNF/YgPQqjOFI7K6o1qjqaxSU99AwEsCnTbGDHhR6N3x7c3M9uD09
ofW3aqFu5QhguxdY3KU2K2Hmes2keMMDxbQoV6aOi1OWsHauFVqjGWcmOv6z
npnk9s9WQX1DUD9BN2+IcVSu0t11Mbrl4Ny9VYr8T3KiEFZZgdQeXm0NlDk+
tsGjLwW8bkwM7Fv6WFyuieVsDoGuO+Xv5yLpU1o31ihK6kPJnmku6Fg06+MU
1xk3a4MX2ZYRu2jAsBNrD7CO9yLRPSeKasoBjUQotsH2I51wYt2qxIpKqI6y
oEBoKy78pDzsliqipM+xrVxZxSkkdJnx2STS2tdzIOb8/ELL46M/xE3BAAfL
ucxW5GMUJVMsSe6/4jzuaFJGc6ZPZiwCmna/opiGdK8SV2VuJ9hSbKVXF1tZ
DhrmWE434pK2a63YSpqyjp5zirViPqdu8FDJPUXklzoK0w3qUOkzsziBSXLB
srg+TiLHdTWft6ivlogiDIMOssqgVCLIrHT/AJ6FSPDxhrd9MwQdnsgn1sQJ
hZbxMYommpTjnAmna+NIDf4U++geH+vYUhUyTgJvCnp5SIGtOFw6qtzywawb
c92Z8b/JqoE0fEhT2+tTDtU4nqMjjihYB29WiWIcL5Ilcs8iwtCK4mQ1wTqR
XUfzH7YrNL3mUJTirhV9kY6KCSQUAg2pCOR+jQORjtec1AZimkSImmh113VK
kb39ipew2kB91GgwTuMsazqX5JCaLvnV6pp2p9A56uaI9xT4RLNqXL4WQubU
TycsH7gP5RBUtTNcZg0ZBM7FIzx1MAvH1dDMT5Ifxue5koZUqLS0R4urqe09
ZTiMoqISVxo6r0P2xjkvOsnjmbpUaTuZFKto08mkULv0JEuu4L0TqOPEl7Pg
sSJ3KtJjY6HB4LlxOz8zNN3b9g4+CVzKiqX9fBM8R0TCLoeWMdC1+mS0Ne5z
UqpvEsbKbZQ3Bte0Ywe8VdqqurhWthrFTnxVoAIUdpHboEa6t3F4QhF2pVGt
Z0XBU5EaOZ2wZR8ORacI3c9iPJoQgHNqvMe83YQUfBAyUxCllt1pYsHI11MR
ykGSzEFBUwcTmgB1bAS5KQdTEJN0RCzdTcRpCKUpUJGAFexv4i7aNZrm0V7z
VK80p7WluxqYjVT+AppjBQ0dEOiApMPm/DDSJ9tdcb65xS0qHjeEibgdH4I4
ju8ilcC5UqHsj2GF6rWpr5zjAc1g3HQoIWv6RhLiOGgIKrUB7U8mPvPGnFPX
zJUK/TDIlE1pkqrYpFXhiypbG3iWTFOMOGK1WUseFSPojFqfZ1h3+xwe5c2Z
LWN9TqNCaBmdMBOcpl/r4aRD+tASMr2uC9GmTH7FjJHlmpzUgcyXaSReYz+3
r/qHhL4yg9bWAtk3+nyy1xiQRbc9RM4JnLptjFq4GA6ynhh0WmLQFbvqAj11
n9/gUOyyprJXVQYGB7AmUTnE00Xrz4Djs0+rihwOAHrTlxiFmVKfPGizIdWM
/UYlI6IpKtVNjiL+RgHluE7ULQTsW1SpPfwD1Tv+xlECyueIaolZu5ZL0rrc
QN8QI6qR5MWPSjC5aLxWxvmKtyhwLHf3AP++sJyu5gcGlu9StiZPFzz4VmZ2
SbOx9igOzVdsm6O3jzuVtg83bvt58fXYQIRtc7z24fEKuK3H/KAZ7mPtUbev
bFDne7wjG618yEeTmsJB1WeKoWTSNo2ABk1iG0dY3tiJanhXbbTbPWgBOC0Y
2p54iROD+/VOUSewAasA2zxsiRdY/lAXr0kxG3R7gJPSe4om4Kdil/jg4HAP
u6uo+VZeWGRZKbuOco1KBfA0XvQtbKtdgZ0Iu5RTxt4+HEznaUs8b8Hk4HCe
V72fe7azleP7C6OIm4GJNUNpl7H8rujqELo6foHoJtQ9re0MOQd6UPF2xuLO
x8BR1MmyYQ0Wj1hUNpY+QLZq+vOFLrGbBC1R6+GBGE3RyXesu+kRgGOzyvJO
EmKqSdblREYqxhpGOb+77jaUErza2nEtDZAQYMADLvIHoUWEuf8LVU71buy8
cz0AfMmTuiUPNboHVuacs2t12MSaPORUvpd0mEoROSuCUawOSnaUx5bOHoqX
84lIYjy9ISS7FQ+PwRuBQ5PSCSSOuGGLdIx3g6sboRExOXsdgjuYtkxLepIn
dOYFHgiKZ93wamp7V4UmYGtUtQPTZ0SocoDFaXi3VDnacaLu3oz5HlqKkoa6
rA43Kgj7xsCaLqMxG+vQKx0PPZHTYDnHvJY1ENH5OpyOydfkMdlz5oc5JplE
7yTGXZv2SnpYd7Yu0qRzFxjpskQrpKWc93GoZfqzHLFG9Js7HDnRWhs0dOch
6Hd90hCR5DKPGlWnpENdfSwDFqCj1YvrILU2uQM/d6D8XQiL+EGbnDuXgNIw
SeM8Hsdz5wpnZCG7iKW9upud6RbSG5CSlKB/Y476sLq4AxUmKVRi5XP9xBov
iGOOb36kEvUX7ZWvwns0lslAAy9Mxtzq/Ljyu/qy1BZmI9Jub71uTHC4dzih
KlcDPbfVrW3LLKBqW0OJh4OzOhEGUdClq8AKFQOfadXiStGPuiNB4O8yjuqJ
cJxKPBoiIBLMzB6PQiuKSHxA8BvVv3Ce0p1TwRzvvUnp1ldPzQ3aU8U01U1r
ZVK9Wk1zozlUGYym3RVB8WU0q5REXfWiOd2vrmq3eOlcy7dB1cPiZX3gTXPV
o6LqKmdCXdXjul5vNujVpbtuEZhUWog2xWhqtE3FgiuuZIpMj3bFgjNaTzfj
kN42OaSV6GRzr0sZkB9yAwLfJKdXc41DzTXcMIZV85MSet7RPqjFHvixwMcc
EgKdjIBuPO9/AJpuhC8NhwAA

-->

</rfc>
