<?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-02" 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-02"/>
    <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 In-Stack MNA capabilities include the Readable Label Depth (RLD), the maximum sizes of differently scoped Network Action Sub-stacks (MLD_NAS), and supported In-Stack network action opcodes. The Post-Stack MNA capabilities include the maximum Post-Stack MPLS Header size (MLD_PSMH), the Readable Label Depth including the Post-Stack MPLS Header (RLD_PSMH), and supported Post-Stack 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-fwk"/> 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">Maximum PSMH Size</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 they are 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.
Signaling the maximum supported NAS size to the ingress LER prevents an LSR from receiving packets with a larger NAS than it supports.
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 by 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 In-Stack 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, analogous 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 are 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 octets.</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. Values of 1 and 18-255 are invalid and <bcp14>MUST NOT</bcp14> be sent; receivers <bcp14>MUST</bcp14> treat them as 0.</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. Values of 1 and 18-255 are invalid and <bcp14>MUST NOT</bcp14> be sent; receivers <bcp14>MUST</bcp14> treat them as 0.</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. Values of 1 and 18-255 are invalid and <bcp14>MUST NOT</bcp14> be sent; receivers <bcp14>MUST</bcp14> treat them as 0.</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 In-Stack 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 Opcodes Sub-TLV format in <xref target="isd-opcodes"/> but independent from it.
For the Supported Post-Stack Opcodes Sub-TLV, the sub-type 5 (Supported Post-Stack 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 In-Stack 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> include Return Code TBA3 in the MPLS echo reply message.</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_NAS_Select</th>
            <th align="left">MLD_NAS_HBH</th>
            <th align="left">MLD_NAS_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 Post-Stack 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-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="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="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+0923LbSHbv+IqOXJWVEoISKckX7XpnaUsaK6XbkPJMJqmU
CySbImIQQADQssaaVCp/kKp92qc85jvyKfslOZfuRjcAXuyhvc4knCmZBPpy
+vTpc+tzun3f94qwiOSR2BqEt3EQhfGtuLjsiZdBGgzDKCxCmYvXOT4+H1yL
a/iy5QXDYSbfYZ2zb7e8UVDI2yS7PxJ5Mfa8cTKKgxm0OM6CSeGH00jmSXzr
z9Io92dx4Oe6I3+v6+Xz4SzM8zCJi/sUKp2d3JwK8UgEUZ5AB2E8lqmEP3Gx
1RJbchwWSRYGEf44672Af5IMvvVvTre8eD4byuzIGwM8R94oiXMZ5/P8SBTZ
XHoA7r4XZDKAVvvJvKCB3CXZ29ssmafw8GIeFWGaJUUySiJxHgxlJAZ3YTGa
UtG38h5Kj4884QszAvyB46J/48B7J+M59C3Emo0KwaPe+gEAQRx/i/Xw+SwI
I3iOjf8hlMWknWRUPshGU3g+LYo0P9rdxWL4KHwn27rYLj7YHWbJXS53sYFd
rHgbFtP5EKrO49Av5tJ/G++unCGsGAE688Lqs2ygzY22w2R1U6tLtKfFLNry
vGBeTJMMEQ29CzGZRxET1ClQZBCLM2iC3sBYgzj8KSiAeo7E6xiQkOVhcS+S
ibiZyyG0KWMqOYKnR9VnyTwukGq/ldksiO/poWS8T6inNgL7BzVcrtkeyzpc
fz+X9wDXIEGCqMH1Dzcn4mWSpUlGD9y+XwIdBHbPiJv2e2qw+4efCtkeJbP2
KK53ehGOpgFQ0wUsjelnRseM+2rPsK86Qrw4gSoF9HfkeWE8KX8JmKwL2T08
otb8IxFOZ/CTfhVBdiuBrjRZhVLK92mUZEjJUhIlAy+ZY6e7nb1nB0/2D55x
TeZYF9fnA3EpC1zEojfCYee/FTdyNI2TKLkNR0EkrgAH70J5J4J4LK4P/BdB
LsfiDIhPYruEKwH/B+JVeDv1B6mE12aBit7g7CV1aWiSPr76V4gwBv5y2i5p
Ej/N1KqmaPnM1Nq+aFszXDZen/21ms9lBvwcp0gP5fjq7Eh09todwPDu1d+9
vLoYtLt73cP2/uHhk72nXSpGHFXgY3/vALk2kSJNs27n+vh0+VTmRTBL+W/7
n/P0myJ9/tdBxjz7uZle+Pi+L4JhXmTBqPC8m2mYC00GYiwnYQwCKRAzmGag
9nyGcIhxmI8SGDVJrwayENsg03bEyBZqQQRLDVqymTJM/nVQTMU2yLodMSex
V0ylEX0Cek1EJv9lDixxN5NpdG9BwtCNYeJE//SleLrXfdYWN1D9LPYHRTB6
S5LVASKMR9F8LKmTvgzGwTCSCqJjmSIk/fPjnRa9nwXvw9l8BtLnJ6gJczsO
JxOZAV4AChh/Cl274xaD+dDPsWfEwPnxm8veABrDtZDPU+BIBS4GDVys6gZc
N0lHyVjmPILrJC/WGYOG0S6P8/EKxiYzAp0huR5cvFLjahw3N6rxv6A5RI5u
yR2UVWHxsICyyskLoggEJvUGvWYyzxU8J+NbgBE0Buzw/KS/I4rEEFwdGzAv
MhhNQekIYliEBJfk9mLoGJkN9pECmbWEjGHgOMhRkmVyVAjUWkBdUaBOeLQR
waHmEUoUQRhrPc0dXd7m9TMLx2NgO94jmN0iS8bcoIczuWR5TDLgLfT8w4dv
zvxj0ihKQT25e/vzzwKUmXfhmNYgcBWZAZN116KMAcEIXgU0wgQMPcyQnwS4
SgoNjzXCtndZrZdJbpSX1hISR/KGRoOC6qRRMIIqsLCBl4vts8HxDmqLkwRn
WoAyghN6jU+b4SBsAYqnTGxmXMiQypXeiKrpOPv5Z2gh0RMLK9RM7fJJrWCt
5VLkSR8KyHGONPg2hmEUCshGGiSCYz6naa7tnQIO3OVc7yMYg6IN3cOiuC87
NER/N5VQI6P2c73qFixSnvc7nJSFi5KWHWAIxCWQ1wiggPWcE58NM0Dz8F4M
JE83CCYcXiPW09wgfipz2cilQEPptBczZBJnPrG8xez4iPDFoguBURKEGjyB
9YbdgQQ5yXdgkdAc0MiCDGBCagReIlKZkQCNR4D5WQp4aJddAx2LC8VJnd41
Dz9yBYJhe1iReCwtRCQBkgtiO5cRILAlXr141RJn3ZMdq7f1RYHXbS+TBAp5
PyjqICTh6FUHebWummuk+mD1mtKz2yohXyFttkk01ISONcXnx1VBAyVssdKE
pdWyZZHaEoMienP+fU7TY5hOo06R58Et1PjwIZuMUJEAzgsrEMpk97SgoByu
ueoUsLQuGbJB/TAB+tlK0aYTM5yUbWoLx53E0CNCY4mpHepkC5UwmaHsq9UC
1qDWv8tggLK8R49ADc9mIenh9x5xUrCfBRrQORjFrwc3aMDjv+Lyir73T757
fdY/Ocbvg1e983PzxVMlBq+uXp8fl9/KmqC0XpxcHnNleCqcR97WRe/HLVYQ
tq6ub86uLnvnWyx+7ElCkQEoHiInBNGQZhInO8g9GOMoC4dMmi9eXv/3f3YO
YGL+CnS8bqeDM8M/nnaeHMAPYI4x90aI5Z/I37wgTWWQYSuIPJi2sAgiZnX5
NLmLQdKAxux5f/OPiJl/OhK/G47SzsHv1QMcsPNQ48x5SDirP6lVZiQ2PGro
xmDTeV7BtAtv70fnt8a79fB334DmI4XfefrN7z2kmUeiR36lkKyyvLKGZsFb
oLU5sFDguEhsMEezNSUxzcaiEqTWANYfnO7Fg7gEbUg0fR6AHSNJpFRwo58H
EDuk048WdA1g+tZHuD/XfPVLP6uaJjBRFlnjWqS2waseq0E4sZlEd9NYoPR0
NEQusVhPoikGaRpGUQAsEjXMNjQNMw4M9NmTp7hMG7GJMsBBf4PU51c3rtBH
CKvivf2Jk76EdBWYSvIbbC7QEBSYWjBWwEXOQ1VZR7aA11qXXk4pGmuoOrRt
MN0V2YRNkp9lhQWCWYOpNGtWxXGqX1wNAJ6MJUyKlfNGdbFpsldgU6sPCkxn
0i0wj9E0sV7VjBHomcwXbZGUwNcsiE+ZdAfMMxdMo565QK4FprKCPhrOdWnT
TPyDoUt6NEDlyyIgS2nD16SbNREiwHrgJ6NCFmIeh0W+YmWtQ5t9F0xX+bMI
l8EsEhDOvKqJH4wrbgkLgexchAZWgr0azA9H4lGBHb7hTRZ2dj7fckRje+tn
lJiw5mG1hsZXUNm2UVporiwnrYSyooamfoHWGbOCGBhEH6UrGXrskhcAf922
hNcVa5EVPsekcsFA0b7comIVcfF7tLmLBvbLYK9jXS2V/T1uJ7RMTsSCxI2U
qghC1d2w0GnwTiuNinLZWmWfYZ88AFRQxmO2squcbDbPC6xurU8kTKXj4Lpg
ix0MN1/5+FZ6CKjHdJ5P1WxX+yRlEvfGUOPFsljI9rZkeiIQcrQiETuO4yps
y3bLVL5v8LdYIzG+CKIUIIaT9wF64D1EvOTvxiTCOoY8cUpuw3cyZu1tEt76
WTR+o+rg1P0AvSEdqK4OW5oooCbRbSRZrwjKVZuLXku8aImXLXHMmvqJGALV
xEkhTokaVGtPHZLQFoOGuEioWTad4gLKWHQCQ/1X+Hhir4FbdRqedRue7WP1
DrzaFwfiUDwWTwCkZx/zzPtb/xf+B4yTPjg0nxfmc9DYGlnwS/i7R+Vvbs5L
nvZ5YHjxFcDw8iuA4fgrgOHkK4Dh9CuA4duvAIZXi2HofA4YiM2h2lLhzlpz
UczelqHEWuk3myVRNMf9vkJ74cDMG4Hwx3LAiUnbQbGhFUsUvwPaBDMOUVfV
QZFBm4RJEb5jcx7Fi4k0MDqo9peazQkUNLxhomTnSleslmkXpi+vR7W0tt28
gwCCM5IByP6uVmXG+GwGlojoPOFnEe6QL91g6GnVrQXiWeLuxizJCOiWkO1b
ENGBYNevVh6oHzFNUn947+M/euMQq5AUT/I8BKmpRCtoDhpbPmJKl2zUmEAD
kRloRPsHxt6cBtn4rnStkTyGr0pbqm9f0TziVgkoyHlZG1pO5hlPCqIpuMfW
cGeCe2YzRyTkeMa+9fhh3qEBW/YjJQz6PpEfKjM5xRBhJyj/g3cYUYNQAvAR
gqi1iDGo3yNy7l4E8T15okZBLnN7olfsoEEdqgKm0zih7hT2kFarSEbq15RQ
jnDxplrFHkaNOpMwWNlSRj+qyYC0eYrN6ZZZ70E3Lr7GqCuzn5PPgigCdFqL
pe2VUWIrdiDqdgJMugRVrjB6+yRLZoCBkQzfkb0PrEHC2ztS6Zj6ja4NC7Mw
3mxFJnfBPSu/uHc7Ir9RSSdaT1ejBgqdo3YaTprGRdNvBtH2LhKH5vBtSRjY
MhNaOs9guciclUhDrHoAyR0pkgqCGfAAJBJfE9SHDxwcQ95H4iELmI1304jq
5c4dyzRSa40W60RmarEG+WrmVvOSszFi7SxBAdpBRD6DanthGZflNodyXsn3
YV4AtkY4AWP9+M1AbU7p37RJhRjVD866J21PW2nKS61sVIsK/RI1RIGAGEaI
uxlWGi+OHfxxwNxMYd7t6nYQxClFxpRGBtY+5kkikl/iUdGTCMPlUCVldfFo
0TFnuqzbfa5dJ9VONy4t3IQgi1AvXEsYI3TEbrBrXoNHnsebXrXW0eeP7dTk
iiG8MNcrl1atA7yLY/EuiObSNnW5hTtgY4ZoqX61p/Zq8GLbYl4G3CyMif6R
WqDfGqzQDAOa6yLMLi1zeC1wgGw+CVdQz0WUtUtXs6fZRI6D/A1pNaWhXOpY
Sq8xsUNmcbIehAQY2+RhwikMZLZ/48y1iev6BrY8DfJSwJm1eaDk9AJtBIs8
0UXI3VtFoWlD29qfR5/+wrauEH/+47/R//9hwAGhQdA8Hw6uz8X2zYveznrg
4J8///HfxSbAopYIpCva5jYdiJo/Gt/0HwYn5wDSa9qsOH/efbjsnT/f0yBt
ACJFuGuDpAAjkPg9gQRGkWJIG8RS56He8zKQKu83iCVDTn/6fy9KFSWbW2Eb
Ix0hPmaJgXCyltjhxpeY+LhFr+CqrrCvEiLNPTYAEuoIvz4cdT4DRF8PW9Qs
AP7/r//lchbUov8lclagNrtBVomfjyWqzpchqj+5ftGaSr7EO1pzh5a6utHT
1Q4w6P6DevRmJdSG5yzX9jNZJpb1vCLo0/W7nKFN3VgQjRn0aGkzoYUV0dGZ
oytvrPcK4UmlvIFf2RXGsKmGizqbyg1JCXkSzQmg5YEVKtB/XUeaclzWwz2G
SVEkM22VVYMq2JJfGpja9j4mqFm7CpUHlPwZaZAV4ShMmVQ41pbQn9PevdV7
0xY+DClI83lU1m6vFTHAXh3aYib3F1uh1dlQdOn1GK6L3o+NgeJOGDDH3Nfh
Kq3pYDxejFZ0aikPBvr5aOnIWlvjRDqUtyQqeXWUufawLgzSr8XMl4H5lgdh
UYh02934WDDugRvgzGsDvvnnJ5diEsporH3UCxoI43E4Mq4BjnyJZHwLgCny
XljRDXdpCfneDqc+ALu+UFHVmOmqd0JWIPaV9qSGTqJeTn5/irmIwhlSuEJh
PaSomk/QXuBDpRpqqHX/qAlsqrpB0SURRMltMjeriRwTfp7KUTgJR5bLSPtX
cNmcDY6BhxJflO/TjONF6kjE/Y8wL5Djky+5qE+o3ktqN7tFKXRHQ98UsrNB
7+Jyb6FasQiH8oubkQCtwDIxLkkNLrrZ4vvFDkHMJIFyam00Bg2dlXFdqzLH
Po4J2yxxa0XiWnPXW0hY5TLjsLJqHGnLaoYi9xtFjBJZChvEup3ImQo19xdR
M4dHLyPJtvcDepBVfI5qJbdk/XJiUSFGo2Q2pOhS7QJcOCqcfwVqgdn/Y1o9
QYWBM/1w+/jmN+UY21XlyJqMBepRRaNoVnJyEC+S0uX864F/dU2RaU/EkJat
Yis4aZ3uU6NArWB2PUvEWWrZyiyT6oaYU8UBl0S62pyhDQhH7bOL/lbjGBmt
lo9BqeLFHI/bsmJzafcUaRRRXibKoiS9SiXnvJs0bJNTZ/SReyMh7UzahGri
zluu+EzOiVs1PpMDeeT1PJoyg8YKGde7tM7ZFt9RSs3N+feYFSbKhBfKd2k5
jfJGYG7YMqzRjKQTNo7moGL6HBgGYr5R1lM/KUUhUA+BQF0DuIgDP80ZdKR1
NYt1d9vixDRMxM97qIotOc1YWbH5YsRD22mCeLxT0XQ2PlPOXVyKxD41kEvG
I85Rpp+ojTFMExz6lPxEKZHUIbXHA8S8ohDWqZPM5O23axMe3ML3W6OsqKGP
TYesdSELnGF6CWLcvwvHiuwoBxNGgpG5AyWrMckRqIuMQRZkZSUKEs6djSJ8
xNlXbLMYWeXsCDW2Zu8pVVq1XzW17rRY2Udj3mhUj1hZV9g87xzZDRpu2dgi
7jYtqVrZfWocZKlcaUY1ceNX9X47ywxUNqTJd9ZVHKvQbLq1OU7YJgel9qiA
38UkPiRF3eyBIgOn5GvowcnEBUJnKwIX6oLOMulzIp5jVd1pCUkKPXKyW2nC
UMZziog4+/YaKTaJAaZbSvIB1JxiGFBfcR3k8RxGxDbwYn5leGnzaw6AzWhR
2YH/J7iq+y6XRJ00Vwc6sM1ucd1fTxirQlZbIwkNEnTydXaE8Wfx55wtAsdx
tBkYuOvTKLjNK32qT59jqMYNrzYfrkdk7BeRSTNYIh7R44QkR/YHi0KdLeTQ
i0+IPQIpZxuVy+TujeE2QHs4H7ihzlNwRC9dW/R7KmrsWlJTgZ2fklsCWzj/
vqVnEH4e6BLQqIX9IwGG01MfNDfTFMHL4RIhyFf3tBAY7lDiSyWpjjBj8AXU
bkoU3GyGoEr6a8q622ySH/W0R/B/9/qk/+MbOznuQWGvWJSp8dFj6lg92flt
uqeF4UkkSPKd5T3YPXWtnsAGf3N1/fLq+GRgerKCqpp1bWW8r+5p3+rpevAG
yd4Z07KDVLYVGC1jC7eMQdMCe0hDs0M9HfhPKF+xyi4e2JQYoqZK+uNPIFpI
OcETSWYhNA9WRpKx+U/6U1rPRCrHhLyC+cSEuJbiFNZSItbgG1COVgHA4VSq
TB0WDPVqUm6DeJm4Y9UVNAWbw9oAGOFNqmdZvgzsqyXTN0tgW9ltFsJ2iRVy
2Mr2B8Pg/4AUNkK4RJKWw92dLyWFf9HnwdvdbXh8HuYUsT7Qds7Cz+7uBmDY
sCagzaelyoBj5m1YH6ibkLZK0P0UlYDhs98pxyr5Ze2AeWObuueQuEGUykzJ
bQN37G5R6CjQ5bbuxPAm1Yftg5hAc6rEncykXYy4cEuZvW7virnp/imSUcOA
sos1mrCgWDxzRJ8yMh6RTavoljMxy9/KAswXy301BxWQfnUJcBontI+x3Sm1
j3ItK4b1HIDY8Fp9UAAwMX8FlkMWjW1WYRGM0gY0qo5gXiiH117Btk5uhmVp
5PMYPaG0CAt5W+5QaQdUJfTdxA+vdc6S6JUBtXvO3pfyU7OXORyTk1mdd6Zz
TKlme7PaDm3xKf3XXoWVZ85KXJx5kVfi3WG8EbqUM6k2qbSbsnKumvFDKsbx
K1vANjJ5CXf1Ev4yC9h12j04Hj/S2i0XHMHkrOeNL+CZu4ArtFZbxF074615
IbsD/IjVvOy0kgVZBu6KV3u8yEZg1WboeQOI/c6T5Wu93rbOAitTgZg1kcLQ
oZXceep3Dw+pZBi/ow7NAsf9ziHvEPxW2y2ZyrcvMslwz1DJ2LMRBhSwGWw1
Jz1sBFcN/tsvjyhYGptCVFM6xkYQVWn4yyJqw0KpIbZM7ZYamfThUZiPfeWY
UBbBGtVsUbYqAK0WIVZVfvmc3gB3YWdBWoZGCG2cV3dDl2/Yqu01JDGleKuG
S2WeNpnIgOCWlVbwKxKY9oSxuNxfqvF2Hm9cYNqfkqQ0YGpOtnEmxZ6/36m4
A784DPtd//H+zl8WhscH/rPDvzAMzx77ne6TnU3D4CgvvOxs/WU1z6mpNPti
26o1ONYVHAUH6LrUcBqLq9GDYEImQpJJ4eMO4wOJj1yKbTpfHzkNRWDgwz0d
CURJ/yjLaDc6pvraqp6EGbqVEISdGgOymI+4JN8BdxYaz2enVUo1Eweg6jXX
2LNq1EIlTc3GkE/Hn2MbMmuUMxLh7uNPj3WPRzdBgC0TIFU/6utXxasF7g0Y
v2rJsQ/cfc3P650AENSupjZmyiPVHoRz+FrVttk8f0jzsWYMa9BejTMciO0l
1RYaQBoF1a1FDJTwaa9w7wgKvRm8vr6+6t+cHNMCXLZSN3Jgst0LrO5Km7Uw
fL1oMrz8g0J+lIdXhw0q/4D2OZYKpBlnLjr+kyMzye1frI36hqA+Qf9fEAKq
PMjbq2KYq8HLO8uMhU9yLRFWWYXUjm9tcVRZPrbBo6/EA69NDOxx+1hcfvId
DU1HIv5SJH1OQ8caRUV/qJg2iws6xs3qMM5V5s3K2E62ZsQ2mjDs2tsBrOOV
WXQFjqKahaaY3nBEwrFtuZ/pbBjrAi7WXEJ1BkixJjaYreVaKB3aSle9FsXT
znPkJbS3ZDZDnfHwMQelEsgnqIjrkj3255HMl2SzlCUzLEku0/Jo83hcnYRc
H3JZBoNtf0eBINlOLSbN3PSwocBUrykwtRpxzYGwbrgq7XFbgak0gR1NERSn
xlxQ3YaiUqPKqDl1qqgbCaOSj6ZJCpPkgmXJBJxEjolbfHSlPjYyjjGGPMhr
g1JpNNPKXQ54piTBx1EC9i0bdAglH/yTpBSWx8dRmlBcDhInnK4MwjX4U8wF
3TQqMFfF25M4nIDaHlJUMA6XTn23vECrxtx0/P5v8nr0ER921fZ6lIE2SiJ0
XhIF68jXOlGMklk6R95ahmdaIbCsRFiH2+tUiP12jaZXnC1T3lujb2BS8ZSE
QqAhFb7da3C60kml48YoVuMDawj1d93NFBbdqzlA6w00h9wGoyzJ80XHu+xT
0xXPXlPT7hQ6JwYd8D4MnwxXT2rQIsqcnurkNAD3oQSMuu6Gy2xB+oVziQtP
HczCYT2s9bNk1/HRuKQ/lQovbWzjamp7j9XFUlqNUVk/CzpvQvbaCUM6Q+YJ
d7mhNJRltOmkoajQBpIll/DeiW5ygvNZ8FjhTjXpsbbQYPDcYKdfGNfvbTrs
gQQu5RRTEISJOCQiYY9Ey9jvWl0xuhz3Oa7UN9l21Taqm6kr2rGjBGttreHg
bmw+TpzotECFd2wj20HFdWft4I4yaE3jXE+PAqwmPgo6scw+bItOZbqbJnjW
IwDn1HiH6c8p2QEgbSYgUy3z1ETSkU+oJp2DNI1AU1MnPZoof2wE2SqHohC3
dGQtXfjEyRyVuVBxlLVpWMettG00z4OdxXO+1OrWBvFyYNayDEpoDhU0dOKi
A5IOOvTDWJ8UeMn5+xbbqHnmECZie3yq5Ci5jVUe7FLNsjeCpaoXqb60kAc0
hXHTQY9sABiRiOOgIagEETRTmfjMG3Pu32L2VCqKQa5MT5OaxpavCv5USe/A
vGSWYbwW689aBKkIS2fUY6WcNV3ph8ejc37QSB98qRBaRSfMBJ920OgJpUMP
0UAyva6Kc6cDERx22ZfFPIvFS+zg5kVv34kPtbi0ydLwyqPeXmIkG12eETun
meqEYYz2OB/08yPR77REvyu21YWE6qrE/r7YZm1lp64Q9PdgOaKCiCe1Nh+n
x+fI1pU5nHroTd8JFeZKhfKgzQW5euxZqhgSi8J53ewyYm0UiY9LRF3qUA21
EG6sRTXSAu//gKJm+VrOS+vOCH3xjqiH4pc/atH4YuFtPc5XvJyCg+G7e/j3
meWeNT8wMn+b0l552uDBjzK3S5o9uAexb75i2xz+ftiptb2/dttPy6+HBiJs
mwPe9w+XwG095geL4T7Uvnf7Jgx1ZMobsteq56YsUlk4Kv1U8ZRc2mYS0KLJ
EOQQ1Ws74w8vPI63u3stAKcFQ9sRz3FiMHrAKerEb2AV4Jz7LfEMy+/r4g25
ev3uEeCk8p5iG/ip2CZW2N/fwe5qKr+VYBdbFsu2o2ijXgFsjRd/C9tq12An
wq4k57FfEAfTedwST1swOTicp3U/6Y7tluUEidJA4mZgYs1Q2lUsvym72oeu
Dp8hugl1jxs7Qw6Cvla89bK8SzNwlHayclibxVMrlb2lz+StuwH4npzEzSaX
qPjwQIzW6CSONt2gCcCxiWX5MQkx9Wz1akYoFWMlo5oo33TJTAVebfm4VgdI
CjDmARfFvdCiwlyrhlqnejdy3rneAL47S10+iErdPetzznHAOsRiRUI3nvxM
x9KUocciGCbq8GlHf2zp9KtkHo1FmuAxGCHZsHgMD14rHZrcWCBxxA1bpyO8
YF5dK46IKdgDEdzCtOVa2JNcodND8IxVPDWIV1PbuyyVAVupahyYPmxDlQMs
TsLbuUp2T1J1p2nC9/tSmDnUZY14oY6wa4ytyTweseEOvba9F/fouwzmESYG
rYCITiritFa+fZDJnlNnzMnTJILHCe7vtJfSw6rjipEmnSvWSJ0lWiFt5ayH
Q63Sn+WUNSqAuRqTM9a1TUNXSYKK1yMlEUku96hRdfI81NXnW2ABOq6+vGVT
K5Rb8HMLyt+GsIjvtZq1dQEoDdMsKZJREjn3gCML2UYs7TRdD063u16DlKST
Dq7NmSlWF7egyqSlVqz8r59Z6QVxzPHhD1Si+f7C6g2DD8Y46WvghUk5XJ5g
WH3XXJbawqxO2hduVo8JDvdqLFTpGqDntrqNbZkFVG9rIPG8dVYnwiAOunTD
Wqli4DOtWlwq+lH3Tgj8XcVRMxGOMCKP7jODKrnZDVJoRRGJDwh+c65P6Uil
q7yCCO8Syug2XU/NDZpU5TQ1TmttVr1GVXO9WVRJoKbhxWkFdUyrtE5d93xJ
ymRT3W750rnxcJ26++XL5kCdJXUPypfLvAqNdQ+b+m1wAtTruvTXLWOZKgvS
phxNlbbxWHLHpcyR6dKuWHJI6+l6nNLbJKe0MsYcNnYhA3JOrkHo62RHa/ax
r9mHG/mwbIIyws8b2nm1+AQ/FviYo0igkyFMuuf9D9UMPXhbiQAA

-->

</rfc>
