<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-jags-mpls-mna-hdr-01" category="std" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true" version="3" consensus="true">
  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->
    <front>
    <title abbrev="MPLS MNA Encodings">MPLS Network Action (MNA) Header Encodings </title>
    <seriesInfo name="Internet-Draft" value="draft-jags-mpls-mna-hdr-01"/>
    <author fullname="Jaganbabu Rajamanickam" initials="J." role="editor" surname="Rajamanickam">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Canada</street>
        </postal>
        <email>jrajaman@cisco.com</email>
      </address>
    </author>
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Canada</street>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author fullname="Jisu Bhattacharya" initials="J." surname="Bhattacharya">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>jisu@cisco.com</email>
      </address>
    </author>
    <author fullname="Bruno Decraene" initials="B." surname="Decraene">
      <organization>Orange</organization>
      <address>
        <email>bruno.decraene@orange.com</email>
      </address>
    </author>
    <author fullname="Royi Zigler" initials="R." surname="Zigler">
      <organization>Broadcom</organization>
      <address>
        <email>royi.zigler@broadcom.com</email>
      </address>
    </author>
    <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Luay Jalil" initials="L." surname="Jalil">
      <organization>Verizon</organization>
      <address>
        <email>luay.jalil@verizon.com</email>
      </address>
    </author>
    <author fullname="Haoyu Song" initials="H." surname="Song">
      <organization>Futurewei Technologies</organization>
      <address>
        <email>haoyu.song@futurewei.com</email>
      </address>
    </author>
    <author fullname="Xiao Min" initials="X." surname="Min">
    <organization>ZTE Corp.</organization>
    <address>
        <email>xiao.min2@zte.com.cn</email>
    </address>
    </author>

    <author fullname="Bin Wen" initials="B." surname="Wen">
      <organization>Comcast</organization>
      <address>
        <email>Bin_Wen@cable.comcast.com</email>
      </address>
    </author>
    <author fullname="Sami Boutros" initials="S." surname="Boutros">
      <organization>Ciena</organization>
      <address>
        <email>sboutros@ciena.com</email>
      </address>
    </author>

    <date day="25" month="July" year="2022"/>
    <workgroup>MPLS Working Group</workgroup>
    <abstract>
      <t>
This document defines the MPLS Network Action (MNA) Header encoding formats to carry Network Actions and optionally Ancillary Data in the MPLS Label Stack and after the Label Stack. The MPLS Network Action can influence the forwarding decisions or can carry additional OAM information in the MPLS packet. This document follows the MNA requirements specified in draft-ietf-mpls-mna-requirements.

     </t>

    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
    <xref target="RFC3032" format="default"/> defines MPLS Header for carrying a stack of MPLS labels which are used to forward packets in an MPLS network.
    Today's new applications require the MPLS packets to carry network action indicators and optional Ancillary Data (AD) that would be used in MPLS packet forwarding decision or for OAM purpose. 
    Ancillary Data can be used to carry additional information, for example, a network slice identifier, In-Situ OAM (IOAM) data, etc. Several use-cases are described in <xref target="I-D.ietf-mpls-mna-usecases" format="default"/>. </t>
      <t>
   This document defines MPLS data plane extension header format to encode MPLS Network Actions (MNA) those are efficient to process in hardware. 
   The MPLS Network Actions are encoded in the form of flags and opcodes. These MPLS Network Actions can be encoded without Ancillary Data (AD) or with In-Stack Ancillary Data (ISD) or with Post-Stack Ancillary Data (PSD) after the Bottom of the Stack (BOS). 
   A new Special Purpose Label (SPL) will be assigned to indicate the presence of MPLS Network Action Sub-stack (MNAS) in the MPLS packet.
   This document follows the MNA requirements specified in <xref target="I-D.ietf-mpls-mna-requirements" format="default"/>.
      </t>

    </section>
    <section anchor="sect-2" numbered="true" toc="default">
      <name>Conventions Used in This Document</name>
      <section anchor="sect-2.1" numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
   when, and only when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="sect-2.2" numbered="true" toc="default">
        <name>Abbreviations</name>

    <t>The MNA terminology defined in <xref target="I-D.andersson-mpls-mna-fwk" format="default"/> and <xref target="I-D.ietf-mpls-mna-requirements" format="default"/> are used in this document.</t>

 <ul>
        <li>
   AD: Ancillary Data. </li>
        <li>
   ADL: Additional Data Length. </li>
        <li>
   BOS: Bottom Of Stack. </li>
        <li>
   I2E: Ingress-To-Egress. </li>
        <li>
   HPI: Hop-By-Hop Post-Stack Network Action Processing Indicator. </li>
        <li>
   ISD: In-Stack Data. </li>
        <li>
   IS-NAI-Opcode: In-Stack Network Action Opcode. </li>
        <li>
   INE: In-Stack Network Action Extension Presence Indicator. </li>
        <li>
   INI: In-Stack Network Action Presence Indicator. </li>
        <li>
   MPLS: Multiprotocol Label Switching. </li>
        <li>
   MNA: MPLS Network Action. </li>
        <li>
   NAI: Network Action Indicator. </li>
        <li>
   NAI-OP: Network Action Indicator Opcode. </li>
        <li>
   NASI: Network Action Sub-stack Indicator. </li>
        <li>
   PNI: Post-Stack Network Action Presence Indicator. </li>
        <li>
   PSD: Post-Stack Data. </li>
        <li>
   SPL: Special Purpose Label in the range of 0-15. </li>
        <li>
   TC: Traffic Class. </li>
        <li>
   TTL: Time To Live. </li>

</ul>
      </section>
    </section>
    <section anchor="sect-3" numbered="true" toc="default">
        <name>Overview</name>
        <t> 
      Encoding MPLS Network Actions requires two main parts. </t>
      <ul empty="true" spacing="normal">
      <li>  1. Network Action Sub-stack Indicator (NASI Label) - This label indicates the presence of MPLS Network Action Sub-stack in the packet. A new SPL (value TBA1) will be allocated for this purpose.</li>

      <li>  2. Network Action Encoding Format - The format in which the MPLS Network Actions can be carried in the MPLS packet. This includes both In-Stack and Post-Stack Network Actions. </li>
      </ul>


      <figure anchor="mpls-label-format">
        <name>MPLS Label Stack Entry (LSE) Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Label                    | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
      </figure>
      <t>
    New In-Stack MPLS Network Action encoding format is defined in this document to carry the In-Stack Network Action and its Ancillary Data in the MPLS Label Stack. </t>
      <ul spacing="normal">
        <li>  It uses MPLS Label field to carry the Network Action Indicator Opcode, Flags and part of In-Stack Ancillary Data. </li>
        <li>  It uses Traffic Class (TC) field to carry the Length of the In-Stack Network Action's Ancillary Data and Network Action I2E Scope. </li>
        <li>  It uses MPLS Label and Time-To-Live (TTL) fields to carry the part of In-Stack Ancillary Data (can be Flags or Ancillary Data). </li>
      </ul>

      <t> 
      The MPLS Network Action encoding formats defined in this document are flexible and allow to add In-Stack and Post-Stack MPLS Network Actions in a desired order in the same MPLS packet. </t>


        <t> A new SPL value (TBA1) is assigned to indicate the presence of the MPLS Network Action Sub-stack (NAS).
        </t>
        <figure anchor="SPL-Ext-Hdr-Format-isd">
          <name>New SPL as MPLS Network Action Sub-stack Indicator with ISD</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               |ADL|E|S| INE,INI=1,IL  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
        </figure>

        <figure anchor="SPL-Ext-Hdr-Format-psd">
          <name>New SPL as MPLS Network Action Sub-stack Indicator with PSD</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               | 0 |E|S| HPI,PNI=1,IL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
        </figure>


   <t> First Word: </t>
    <ul spacing="normal">
     <li> This is the new SPL, indicates the presence of NASI. The TC and TTL fields of the NASI SPL are not re-purposed for encoding format flags, as the penultimate node on the MPLS packet path may propagate TTL from the transport (or forwarding) label to the next label on the label stack, overwriting the TTL on the next label.  When the penultimate node is 
    aware of the NASI SPL (value TBA1), it can also pop that label. But when the penultimate node
    is not aware of the NASI SPL (value TBA1), this can cause encoding format flags in the TTL of the NASI (label TBA1) label to be lost. This word helps to identify the presence of In-Stack and/or Post-Stack Network Actions.</li>
    </ul>

   <t> Second Word: </t>
   <t> This word contains the Base Header, which indicates the some of the base attributes of the In-Stack and Post-Stack NAIs encoded. In this case, the TTL fields is re-purposed to encode the Base Header Information. But the Label and TC fields are used to encode the Flag-based In-Stack NAIs.</t>

   <t> TTL Field </t>
   <t> The following are the information that are encoded as part of TTL field. </t>
   <ul spacing="normal">

       <li> IL (In-Stack Network Action Encoding Length) - The First 3-bits TTL field is used to indicate the length of the In-Stack MPLS Network Actions encoded in terms  of words (32 bits). For example, IL value "0" means there are no In-Stack Network Actions encoded. If IL value is "1" means there is one word worth of In-Stack Network Action is encoded. This field is very helpful for the hardware ASICs to skip or process the In-Stack Network Actions. Using one NASI only 7 words of In-Stack Network Actions can be encoded. </li>
      <li> INI (In-Stack Network Action Presence Indicator) - This is the 5th bit in the TTL field. This indicates the presence of the In-Stack Network Actions encoding. This bit is defined to help the hardware ASICs to process the In-Stack Network Actions or skip. </li>
        <li> TBA4 - Bit 4 is reserved for future usage. </li>
        <li> PNI (Post-Stack Network Action Presence Indicator) - This is the 6th bit in the TTL field. This indicates the presence of the Post-Stack Network Actions encoding. This bit is defined to help the hardware ASICs to process the encoded Post-Stack Network Actions. </li>
        <li>  HPI (Hop-By-Hop Post-Stack Network Action Processing Indicator) - This is the 7th bit in the TTL field. This indicates the presence of the Post-Stack Network Actions encoded in the packet that required Hop-By-Hop processing. This bit is defined to help the hardware ASICs to process the encoded Post-Stack Network Actions on all the mid-nodes. </li>
        <li> INE (In-Stack Network Action Extension Presence Indicator) - This is the 8th bit in the TTL field. One NASI can encode only 7 words of In-Stack Network Actions. If the user needs to encode more than 7 words of In-Stack Network, then this bit will indicate that it has another set of In-Stack Network Actions encoded. This gives a flexibility to extend multiple sets of Network Action Sub-stack. The Last Network Action Sub-stack will set the INE bit to "0". This has been defined for more extensibility/flexibility in the future. But at the same time, it is not advisable to encode more Ancillary Data for a specific In-Stack Network Actions. If at all a Network Actions required more supporting Ancillary Data, then those Network Actions MUST be encoded as part of Post-Stack Network Actions. </li>

    </ul>
    <t> Label Field </t>
    <t> This field encoding the Flag-based NAIs which does not require any Ancillary data to be carried to process the In-Stack NAIs. </t>
    <ul spacing="normal">
       <li> The First bit MUST be set "1" to prevent aliasing with the existing SPLs. </li>
       <li> Next 19 bits will be used to encode In-Stack NAIs. These Bit positions will be assigned by IANA. </li>
    </ul>
    <t> TC Field </t>
    <ul spacing="normal">
       <li> ADL (Additional Data Length) - The first 2 bits are used to encode the length of additional Flag-based NAIs that are carried. This field is to extend the assignment of the Flag-based NAI bit position more than 19 (i.e) if IANA allocates bit position value more than 19, then it would take additional word to assign the new Flag-based In-Stack NAIs. By default, this value will be "0". Depending on the number of words is encoded this value will get incremented. The maximum value that is encoded would be "3" (i.e.) it allows additional 3 words to be encoded to carry Flag-based NAIs. </li>
       <li> E-Bit (I2E Bit) - This Flag will NOT be set when the MNA carries Flag-based In-Stack NAIs that are to be processed at Hop-By-Hop. This will allow the ASICs in the mid nodes to process the Flag-based In-Stack NAIs easily. </li>
    </ul>  


    </section>
    <section anchor="sect-J5" numbered="true" toc="default">
      <name>In-Stack MPLS Network Action Encoding</name>
      <t> This section describes the encoding format of the MPLS Network Actions carried as part of the MPLS Label Stack. The encoding format defined is flexible (e.g., stackable opcodes in desired order), extensible (by defining new NAI-Opcodes) and ASIC friendly (by using Sub-stack Length, Opcode+Data in the same field). This encoding format allows to carry Flag-based NAIs and the NAIs that required Ancillary Data in the same packet.</t>
      <figure anchor="In-Stack-Ext-Hdr-Format">
        <name>In-Stack Network Action Encoding Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      NASI=SPL (TBA1)                  | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               |ADL|E|S|   IL, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-NAI-Opcode |    Ancillary Data     |ADL|E|S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>
      <t> First Word: </t>
      <ul spacing="normal">
      <li> NASI will identify the presence of MPLS Network Action Sub-stacks. </li>
      </ul>
      <t> Second Word: </t>
      <t> This word contains the base MNA indicators and the Flag Based NAIs that has been described in the above section. </t>
      <ul spacing="normal">
      <li> INI flag is set to "1" to indicate the presence of any In-Stack MPLS Network Actions. </li>
      <li> IL will be set depending on the encoded In-Stack Network Actions. </li>
      <li> Flag-Based-NAI - Network Action that does not require Ancillary data to process can be encoded. This has been described in detail in the above section. </li>
      </ul>
    <t> Third Word: </t>
      <t> This word contains the NAIs that requires some Ancillary Data to be processed. </t>
      <t> Label Field: </t>
      <t> The first 8 bits are used to define the In-Stack Network Action Opcode (IS-NAI-Opcode). The opcode method of identifying a specific Network Actions are common in today's hardware ASICs (Similar to any IPv4/IPv6/VxLAN header processing), so this method is easy to be adopted by the existing hardware.  This will allow the hardware ASICs to serially or in-parallel process the Network Actions. </t>
      
      <t> This opcode ranges from 1 to 255. NAI-Opcode value of 0 is marked as invalid to avoid the label value aliasing with the reserved SPLs. </t>

      <ul spacing="normal">
        <li>IS-NAI-Opcode Value:1 - Opcode reserved to indicate the start offset of the Post-Stack Network Actions encoding after the MPLS Label Bottom of the Stack.
     This can allow to carry Generic Control Word (0000b) <xref target="RFC4385" format="default"/> and G-ACh (0001b) <xref target="RFC5586" format="default"/> fields immediately after the BOS. Adding of this opcode is
     not required when the BOS data starts immediately after the Bottom of the Label Stack (i.e. when offset is 0).</li>
        <li>IS-NAI-Opcode Value:2-254 - MUST be assigned by IANA. When the opcode is allocated for a specific applications Network Action, the respective Ancillary Data format MUST be defined. Also other required attributes of the Network Action MUST be defined like functionality, Hop-By-Hop Processing etc.. </li>
        <li>IS-NAI-Opcode Value:255 - IANA Allocated for IS-NAI-Opcode range extension. This gives the extensibility for opcode range beyond 255. </li>
      </ul>
      <t>IS-NAI-Opcode/Flag-Based-NAI Bits MUST define the following procedure before it can be used: </t>
      <ul empty="true" spacing="normal">
        <li> 1. Define the Data format for the MPLS Network Actions to be encoded. </li>
        <li> 2. Define the Hop-By-Hop or Ingress-To-Egress (only on the decapsulation node) processing scope. </li>
        <li> 3. The Hop-By-Hop IS-NAI-Opcodes MUST be placed before the Ingress-To-Egress IS-NAI-Opcodes in the MPLS Network Action Stack to optimize the Hop-By-Hop processing in hardware. </li>
      </ul>
      <t> Next 12 bits in the Label field and the 8 bits from the TTL field are used to carry Ancillary Data corresponding to the IS-NAI-Opcode.</t>
      <t> TC Field: </t>
      <t> This field is used to indicate the following. </t>
      <ul empty="true" spacing="normal">
        <li> ADL (Additional Data Length): This indicates the additional number of word fields used to encode Additional Ancillary Data. By default, an IS-NAI-Opcode can carry 20 bits of Ancillary Data. If a specific opcode needs to carry more than 20 bits of Ancillary Data, then this field should be encoded with the right value. By default, the ADL value would be "0". For example, if a specific opcode needs to carry 32 bits of Ancillary Data then the ADL value would be "1". This will allow the hardware ASIC to easily move to the next opcode. In some cases, if the node does not understand the opcode value, then this field will be used to skip the current opcode and move to the next opcode offset for further processing.</li>
        <li> E (I2E-Bit): In-Stack MPLS Network Action that requires processing only at the egress node.  This bit indicates will be set to "0" in case of Hop-By-Hop processing is required. </li>
      </ul>
      <t> TTL Field: </t>
      <t> This 8-bit field is used to carry In-Stack Ancillary Data apart from the 12 bits in the Label field. </t>
      <t> NOTE: </t>
      <ul empty="true" spacing="normal">
        <li> An intermediate node may use the full MPLS Label Stack for ECMP hash computation hence the In-Stack MPLS extension header MUST NOT change the Label Field part of the IS-NA data within the same traffic flow. But the TTL part of In-Stack Ancillary Data can change for the same traffic flow without affecting the ECMP hash. The In-Stack Network Action encoding defined above ensures this. </li>
      </ul>
    <section anchor="sect-J5.b" numbered="true" toc="default">
      <name>In-Stack MPLS Network Action Encoding more than 20 bits of Ancillary Data </name>
      <t> In some cases, the In-Stack Network Action can require more than 20 bits of supporting Ancillary Data. In these cases, the following Ancillary Data encoding should be used. This is applicable for the Flag-based In-Stack NAI encoding described in the section 3.1 </t>

      <figure anchor="In-Stack-Ext-Hdr-Format-with-more-AD">
        <name>In-Stack Network Action With Additional Ancillary Data Encoding Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               |ADL|E|S|   IL, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-NAI-Opcode |    Ancillary Data     |ADL|E|S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|     Additional Ancillary Data             |S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>

    <t> First and Second Word: </t>
  
    <t> These values are already described in the above section. </t>

    <t> Third Word: </t>
    <t> These values are also described above, but the ADL length will be set to "1", to indicate the presence of additional word data that is carried. This ADL length is corresponding to the specific opcode.</t>
    
    <t> Fourth Word: </t>
    <t> This is the Additional Ancillary Data that is encoded to support the IS-NAI-Opcode. The below is the format to encode single additional word to carry Ancillary Data. This format would be replicated for each additional word of Ancillary Data encoded.</t>
    <ul>
    <li> The first bit in the Label field MUST be set to "1". This is to prevent aliasing the label field with other SPLs on the legacy routers.</li>
    <li> Next 19 bits of the Label field can be used to encode Ancillary Data. </li>
    <li> The TC field carries part of Additional Ancillary Data. </li>
    <li> The TTL field carries a part of the Additional Ancillary Data. </li>
    </ul>

    </section>

    </section>

    <section anchor="sect-J6" numbered="true" toc="default">
      <name>Post-Stack MPLS Network Action Encoding </name>
      <t> Based on the PNI and HPI flags, the Post-Stack Network Actions will be processed. The details of the Post-Stack Network Action encoding have been provided in <xref target="I-D.song-mpls-extension-header" format="default"/>. </t>
    </section>


    <section anchor="sect-J7" numbered="true" toc="default">
      <name>In-Stack Network Action Encoding Example-1 - Carrying Flag-based In-Stack Network Action without Ancillary Data</name>

      <figure anchor="In-Stack-Ext-Hdr-1-a">
        <name>Example In-Stack Network Action Encoding Carrying Flag-based NA</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               | 0 |E|S| IL=0, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>
      <t> Second Word: </t>
      
      <t> Label Field: </t>
      <ul>
        <li> First bit MUST be set to "1".</li>
        <li> Next 19 bits are used to encode the flag-based Network Actions that do not need any corresponding Ancillary Data to process. Each Flag encoded is a unique Flag-based Network Action. This Flag position will be assigned by IANA. For example, an application-A can be allocated Flag position as "2" and another application-B can be allocated Flag position as "5". If application-A and B needs to set their Network Actions then the Flag bit position "2" and "5" will be set. The Flag positions are counted from left to right.</li>
      </ul>
      <t> TC Field: </t>
      <ul empty="true" spacing="normal">
        <li> ADL - This value depends on the length of the Flag value the MPLS In-Stack header is carrying. In this case the packet is carrying only bit position "1" and "3", the ADL value will be set to "0".</li>
      </ul>
      <t> TTL Field: </t>
      <ul empty="true" spacing="normal">
        <li> INI flag is set to "1" to indicate the presence of In-Stack Network Actions.</li>
      </ul>

      <figure anchor="In-Stack-Ext-Hdr-1-a-ext">
        <name>Example In-Stack Network Action Encoding Carrying Flag-based NA with Flag position is more than 20</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   | TC  |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               | 1 |E|S| IL=1, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Additional Flag-Based-NAI                 |S| Flag-Based-NAI|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>
      <t>In this Example, let us assume that an application-C has been allocated a Flag position of "21" by IANA, If the application-C needs to execute its Network Action on the MPLS packet then the 2nd bit in the third Label field will be set to indicate the Flags position "21".</t>
      <t> ADL is set to "1" indicates the Flag-Based-NAI word is encoded.</t>
      <t> If the Flag-Based-NAI contains Hop-By-Hop NA then this bit will be set to "0". </t>
      <t> IL is set to "1" indicates the additional In-Stack NAI word encoded. </t>
      <t> INI flag is set to indicate the presence of the In-Stack NAI. </t>
      <t>While encoding the Additional Ancillary Data, the Most Significant bit of the third Label Field MUST be set to "1" to prevent from aliasing with the reserved SPLs in the case of legacy devices.</t>
    </section>


    <section anchor="sect-J8" numbered="true" toc="default">
      <name>In-Stack Network Action Encoding Example-2 - Carrying Only Network Actions that require Ancillary Data</name>

      <figure anchor="In-Stack-Ext-Hdr-1-b">
        <name>Example In-Stack Network Action that requires Ancillary Data</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI=0             | 0 |E|S| IL=1, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IS-NAI-Opcode  |  Ancillary Data       | 0 |E|S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>
      <t> In this Example, the MNA is carrying only the In-Stack Network Action that requires Ancillary Data. </t>
      <t> Second Word: </t>
      <t> IL length is set to "1" to indicate an additional 1 word of IS-NA is encoded. </t>
      <t> INI flag is set to "1" to indicate the presence of In-Stack MPLS Network Actions.</t>
      <t> Third Word: </t>
      <t> Label Field: </t>
      <ul>
        <li> First 8 bits encodes the In-Stack Network Action opcode. In this case the IS-NAI-Opcode value ranges from 1 to 254. This value is assigned by IANA. This opcode value defines Ancillary Data format carried in the Label field and the TTL field.</li>
        <li> Next 12 bits are encoded with the Ancillary Data.</li>
      </ul>
      <t> TC Field: </t>
      <ul empty="true" spacing="normal">
        <li> ADL - In this case, since the Ancillary Data that is encode is less than 21 bits, the value of ADL encoded is "0". </li>
      </ul>
      <t> TTL Field: </t>
      <ul empty="true" spacing="normal">
        <li> 8-bit field is used to encode the In-Stack Ancillary Data apart from 12-bit Label field. </li>
      </ul>
      <figure anchor="In-Stack-Ext-Hdr-1-b-ext">
        <name>Example In-Stack Network Action that requires Ancillary Data of more than 20-bit length</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   | TC  |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI=0             | 0 |E|S| IL=2, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IS-NAI-Opcode  |   Ancillary Data      | 1 |E|S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|  Additional Ancillary Data              |E|S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>
      <t>In this example, the IS-NA carries more than 20-bit of Ancillary Data. </t>
      <t> Second Word: </t>
      <ul>
      <li> IL length is set to "2" to indicate an additional 2 word of IS-NA is encoded. </li>
      <li> INI flag is set to "1" to indicate the presence of In-Stack MPLS Network Actions.</li>
      </ul>
      <t> Third Word: </t>
      <ul>
      <li> The IS-NAI opcode and the first part of the Ancillary Data is encoded. </li>
       <li> ADL is set to "1", indicating the presence of additional word of Ancillary data corresponding to this opcode. </li>
      </ul>
      <t> Fourth Word: </t>
      <ul>
       <li> First bit in the Label field MUST be set to "1". </li>
       <li> Rest of the 19bits Label field, TC and TTL field May contain the Ancillary data corresponding to the above opcode encoded. </li>
      </ul>

      <t> Since it carried additional "1" word worth of Ancillary Data, ADL value in the second MPLS TC field is set to "1". </t>
      <t>While encoding the Additional Ancillary Data, the Most Significant bit of the Label Field MUST be set to "1" to prevent from aliasing with the reserved SPLs in the case of legacy devices. </t>
    </section>




    <section anchor="sect-J8.a" numbered="true" toc="default">
      <name>In-Stack Network Action Encoding Example-3 - Carrying Multiple Network Actions that require Ancillary Data</name>

      <figure anchor="In-Stack-Ext-Hdr-3">
        <name>Example In-Stack Network Action Carrying Multiple NA with the Ancillary Data</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=SPL (TBA1)                   |  TC |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI=0             | 0 |E|S| IL=2, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IS-NAI-Opcode=3| Ancillary Data3       | 0 |E|S|Ancillary Data3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IS-NAI-Opcode=5| Ancillary Data5       | 0 |E|S|Ancillary Data5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
      </figure>
      <t>
    This is the example where the MPLS packet carries multiple In-Stack Network Actions that require Ancillary Data to process. </t>

    <t> Thrid Word </t>
       <ul empty="true" spacing="normal">
          <li> Label-Field - First 8-bit field is used to represent In-Stack Network Action Opcode value "3". The next 12 bits indicates the first 12 bits of Ancillary Data corresponding to the Opcode "3".</li>
          <li> TC-Field - ADL - Since no Additional Ancillary Data is encoded or the opcode "3", this field is set to "0".</li>
          <li> TTL-Field - This 8-bit indicates the rest of eight bits of Ancillary Data corresponding to the opcode "3".</li>
       </ul>

    <t> Fourth Word </t>
       <ul empty="true" spacing="normal">
          <li> Label-Field - First 8-bit field is used to represent In-Stack Network Action Opcode value "4". The next 12 bits indicates the first 12 bits of Ancillary Data corresponding to the Opcode "4".</li>
          <li> TC-Field - ADL - Since no Additional Ancillary Data is encoded or the opcode "4", this field is set to "0".</li>
          <li> TTL-Field - This 8-bit indicates the rest of the eight bits of Ancillary Data corresponding to the opcode "4".</li>
       </ul>

    </section>



    <section anchor="sect-J101" numbered="true" toc="default">
      <name>Node Capability Signaling</name>
      <t> The node capability for the MPLS Network Action must be signaled before the MPLS Encapsulating node can add the necessary MPLS Network Action in the MPLS Label Stack.  The capability signaling will be added in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP-LS, etc. This is outside the scope of this document.
      </t>
    </section>
    <section anchor="sect-J11" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations in <xref target="RFC3032" format="default"/> also apply to the extensions defined in this document.
    The NASI Label MUST NOT be exposed to the node which does not support it. </t>
    </section>

    <section anchor="sect-J12" numbered="true" toc="default">
      <name>Backward Compatibility</name>

      <ul spacing="normal">
       <li> For the legacy node that does not advertise the MPLS Network Action capability, the Encapsulating node MUST make sure that the MPLS Network Action Sub-stack indicator is not at the top of the MPLS Label Stack to avoid dropping the packets. Based on the signalling, if the MPLS egress node is not capable of the processing MPLS Network Actions then it should not add MNA in the packet. In the worst case, if the legacy routes that does not understand the new SPL allocated then those routers will drop the packets.</li> 
      <li> The MPLS Network Action Encoding format is designed to make sure that it does not alias with any reserved SPL. </li> 
      <li> The MPLS Network Actions can co-exist with the existing GAL / G-ACh based encoding of data. </li>
      <li>The TC and
      TTL fields of the NASI SPL are not re-purposed for encoding, as the
      penultimate node on the MPLS packet path may propagate TTL from
      the transport (or forwarding) label to the next label on the label
      stack, overwriting the TTL on the next label.  When the
      penultimate node is aware of the NASI SPL (value TBA1), it can
      also pop that label.  But when the penultimate node is not aware
      of the NASI SPL (value TBA1), this can cause encoding format flags
      in the TTL of the NASI (label TBA1) label to be lost.</li>

    </ul>

    </section>

    <section anchor="sect-J12.1a" numbered="true" toc="default">
      <name>Processing In-Stack MPLS Network Actions</name>
      <t> Encapsulating Node: </t>
      <ul spacing="normal">
        <li> MUST NOT add In-Stack MPLS Network Action Sub-stack if the decapsulation node is not capable of In-Stack MPLS Network Action.</li>
        <li> SHOULD NOT change the IS-NAI-Opcode and the first 12 bits of the In-Stack Ancillary Data for the same packet flow to avoid ECMP path change. </li>
        <li> MAY change In-Stack Ancillary Data part present only in the TTL field for the same packet flow. </li>
        <li> MUST ensure that the penultimate node does not remove the MPLS Network Action Sub-stack.</li>
      </ul>
      <t> Intermediate Node: </t>
      <ul spacing="normal">
        <li> MUST ignore the IS-NAI-Opcode that are not supported.  </li>
        <li> MUST NOT add In-Stack MPLS Network Action Sub-stack if the decapsulation node is not capable of In-Stack MPLS Network Actions.</li>
        <li> SHOULD NOT change the IS-NAI-Opcode and the first 12 bits of the In-Stack Ancillary Data for the same packet flow. </li>
        <li> MAY change In-Stack Ancillary Data part present only in the TTL field for the same packet flow. </li>
        <li> MAY remove the IS-NAI-Opcode and its corresponding data for all matching packet flow. </li>
      </ul>
      <t> Decapsulating Node: </t>
      <ul spacing="normal">
        <li> MUST remove the In-Stack MPLS Network Action Sub-stack. </li>
      </ul>
    </section>



    <section anchor="sect-J13" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Below are the IANA actions which this document is requesting.</t>

      <t>The registries created by this document will be collected in a new registry grouping called “MPLS Network Action,” 
      which will be located at https://www.iana.org/assignments/mpls-network-action.</t>
      
      <section anchor="sect-J13.10" numbered="true" toc="default">
        <name>IANA Considerations for MNA Encoding Flags</name>
        <t>IANA is requested to create a new registry with name "MNA Encoding Flags" to assign the bit position and the meaning to the Flags to repurpose TTL and TC fields in the Label Stack Entry (LSE).</t>

        <table anchor="iana-fif-tbl" align="center">
          <name>MNA Encoding Flags Registry</name>
          <thead>
            <tr>
              <th align="left"> Bit Position</th>
              <th align="left"> Description</th>
              <th align="left"> Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">11-0</td>
              <td align="left">IETF Review</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
       </table>

       <t>Following MNA Encoding Flag values are assigned from this registry. </t>
        <table anchor="iana-is-fiflag-tbl" align="center">
          <name>MNA Encoding Flag Values</name>
          <thead>
            <tr>
              <th align="left"> Value</th>
              <th align="left"> Description</th>
              <th align="left"> Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0-2</td>
              <td align="left">In-Stack Network Action Encoding Length (IL)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">Reserved</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">In-Stack Network Action Presence Indicator (INI)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">Post-Stack Network Action Presence Indicator (PNI)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">Hop-By-Hop Post-Stack Network Action Processing Indicator (HPI)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">7</td>
              <td align="left">In-Stack Network Action Extension Presence Indicator (INE)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">8</td>
              <td align="left">End of Stack (S)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">9-10</td>
              <td align="left">Additional Data Length (ADL)</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">11</td>
              <td align="left">Ingress-To-Egress (E)</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
        </table>

      </section>

      <section anchor="sect-J13.1" numbered="true" toc="default">

        <name>IANA Considerations Flag-based Network Actions</name>
        <t>IANA is requested to create a new registry with name "In-Stack MPLS Network Action Indicator Flags" to assign the bit position and the meaning to the Flag-based Network Actions upon the user request. Based on the need this registry will be extended more than 19 bit positions. </t>
        <table anchor="iana-nafif-tbl" align="center">
          <name>In-Stack MPLS Network Action Indicator Flags Registry</name>
          <thead>
            <tr>
              <th align="left"> Bit Position</th>
              <th align="left"> Description</th>
              <th align="left"> Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">18-0</td>
              <td align="left">Unassigned</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
        </table>

      </section>
      <section anchor="sect-J13.2" numbered="true" toc="default">
        <name>IANA Considerations for IS-NAI-Opcode</name>
        <t>IANA is requested to create a new registry with name "In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-Opcode values.
   All code-points in the range 1 through 175 in this registry shall be
   allocated according to the "IETF Review" procedure as specified in
   <xref target="RFC8126" format="default"/>.  Code points in the range 176 through 239 in this
   registry shall be allocated according to the "First Come First
   Served" procedure as specified in <xref target="RFC8126" format="default"/>. 
   Remaining code-points are allocated according to <xref target="iana-is-fioc-reg-tbl" format="default"/>:
        </t>
        <table anchor="iana-is-fioc-reg-tbl" align="center">
          <name>In-Stack MPLS Network Action Indicator Opcodes Registry</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="center">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0 - 175</td>
              <td align="center">IETF Review</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">176 - 239</td>
              <td align="center">First Come First Served</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">240 - 251</td>
              <td align="center">Experimental Use</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">252 - 254</td>
              <td align="center">Private Use</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
        </table>
        <t>Following IS-NAI-Opcode Indicator values are assigned from this registry. </t>
        <table anchor="iana-is-fioc-tbl" align="center">
          <name>In-Stack Network Action Indicator Opcode Values</name>
          <thead>
            <tr>
              <th align="left"> Value</th>
              <th align="left"> Description</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">Offset of start of Post-Stack Network Action Header</td>
              <td align="left">This document</td>
            </tr>
            <tr>
              <td align="left">255</td>
              <td align="left">Opcode Range Extension Beyond 255</td>
              <td align="left">This document</td>
            </tr>
          </tbody>
        </table>
      </section>


      <section anchor="sect-J13.6" numbered="true" toc="default">
        <name>IANA Considerations for New Special Purpose Label</name>
        <t>IANA is requested to allocate a value TBA1 for the SPL label from the "Base Special-Purpose MPLS Label Values" registry to indicate the presence of MNA Sub-stack.</t>
      </section>

    </section>
    <section anchor="sect-J14" numbered="true" toc="default">
      <name>Appendix</name>
      <section anchor="sect-J14.1" numbered="true" toc="default">
        <name>Alternate approach for In-Stack Network Action Encoding</name>
        <t>Instead of encoding In-Stack Network Action Indicator Opcode in the Label field, here is an alternate way of adding In-Stack Network Action Indicator Opcode in the TTL field. </t>
        <figure anchor="Alternate-In-Stack-Ext-Hdr-Format">
          <name>Alternate In-Stack Network Action Encoding Format</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[

 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      NASI=SPL (TBA1)                  |  TC |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|        Flag-Based-NAI               | 0 |E|S| IL=1, INI=1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|         Ancillary Data              |ADL|E|S| IS-NAI-Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
        </figure>
        <t> INI flag is set to "1" to indicate the presence of In-Stack MPLS Network Actions. </t>
        <t> Since In-Stack MPLS Network Action encoding is part of the MPLS Header, the MPLS Header is redefined to encode the MPLS Network Actions. </t>
        <t> Fourth Word: </t>
        <t> Label Field: </t>
        <ul empty="true" spacing="normal">
          <li> Most significant bit is always set to "1" to avoid aliasing with the reserved SPLs. </li>
          <li> Rest of the 19 bits in the Label can be used to carry the Ancillary Data corresponding to the IS-NAI-Opcode. </li>
        </ul>
        <t> TC Field: </t>
        <ul empty="true" spacing="normal">
          <li> ADL (Additional Data Length): Length of Additional Ancillary Data that is encoded. </li>
        </ul>
        <t> TTL Field: </t>
        <t> This carries In-Stack Network Action Indicator Opcode.</t>
      </section>



    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author initials="E." surname="Rosen" fullname="E. Rosen">
              <organization/>
            </author>
            <author initials="D." surname="Tappan" fullname="D. Tappan">
              <organization/>
            </author>
            <author initials="G." surname="Fedorkow" fullname="G. Fedorkow">
              <organization/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
              <organization/>
            </author>
            <author initials="D." surname="Farinacci" fullname="D. Farinacci">
              <organization/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization/>
            </author>
            <author initials="A." surname="Conta" fullname="A. Conta">
              <organization/>
            </author>
            <date year="2001" month="January"/>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
         <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <date year="2017" month="June"/>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        <name>Informative References</name>

        <reference anchor="I-D.song-mpls-extension-header" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.song-mpls-extension-header.xml" target="https://www.ietf.org/archive/id/draft-song-mpls-extension-header-07.txt">
          <front>
            <title>MPLS Extension Header</title>
            <author fullname="Haoyu Song">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Zhenbin Li">
              <organization>Huawei</organization>
            </author>
            <author fullname="Tianran Zhou">
              <organization>Huawei</organization>
            </author>
            <author fullname="Loa Andersson">
              <organization>Bronze Dragon Consulting</organization>
            </author>
            <author fullname="Zhaohui Zhang">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Rakesh Gandhi">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Jaganbabu Rajamanickam">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Jisu Bhattacharya">
              <organization>Cisco Systems</organization>
            </author>
            <date month="July" day="08" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-song-mpls-extension-header-07"/>
        </reference>

       <reference anchor="I-D.andersson-mpls-mna-fwk" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-andersson-mpls-mna-fwk-04.xml" target="https://www.ietf.org/archive/id/draft-andersson-mpls-mna-fwk-04.txt">
          <front>
            <title>MPLS Network Actions Framework</title>
            <author fullname="Loa Andersson">
            </author>
            <author fullname="Stewart Bryant">
            </author>
            <author fullname=" Matthew Bocci">
            </author>
            <date month="June" day="27" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-andersson-mpls-mna-fwk-04.txt"/>
        </reference>


        <reference anchor="I-D.ietf-mpls-mna-requirements" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-mna-requirements.xml" target="https://www.ietf.org/archive/id/draft-ietf-mpls-mna-requirements-01.txt">
          <front>
            <title>Requirements for MPLS Network Action Indicators and MPLS Ancillary Data</title>
            <author fullname="Matthew Bocci">
              <organization>Nokia</organization>
            </author>
            <author fullname="Stewart Bryant">
              <organization>University of Surrey 5GIC</organization>
            </author>
            <author fullname="John Drake">
              <organization>Juniper Networks</organization>
            </author>
         
            <date month="June" day="21" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-requirements-01.txt"/>
        </reference>

        <reference anchor="I-D.ietf-mpls-mna-usecases" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-mna-usecases.xml" target="https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-00.txt">
          <front>
            <title>Usecases for MPLS Indicators and Ancillary Data</title>
            <author fullname="Tarek Saad">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Kiran Makhijani">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Haoyu Song">
              <organization>Futurewei Technologies</organization>
            </author>
            <date month="May" day="19" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-usecases-00"/>
        </reference>


        <reference anchor="RFC5586" target="https://www.rfc-editor.org/info/rfc5586" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml">
          <front>
            <title>MPLS Generic Associated Channel</title>
            <author initials="M." surname="Bocci" fullname="M. Bocci" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Vigoureux" fullname="M. Vigoureux" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Bryant" fullname="S. Bryant" role="editor">
              <organization/>
            </author>
            <date year="2009" month="June"/>
          </front>
          <seriesInfo name="RFC" value="5586"/>
          <seriesInfo name="DOI" value="10.17487/RFC5586"/>
        </reference>

        <reference anchor="RFC4385" target="https://www.rfc-editor.org/info/rfc4385" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml">
          <front>
            <title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN</title>
            <author initials="S." surname="Bryant" fullname="S. Bryant">
              <organization/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization/>
            </author>
            <author initials="L." surname="Martini" fullname="L. Martini">
              <organization/>
            </author>
            <author initials="D." surname="McPherson" fullname="D. McPherson">
              <organization/>
            </author>
            <date year="2006" month="February"/>
          </front>
          <seriesInfo name="RFC" value="4385"/>
          <seriesInfo name="DOI" value="10.17487/RFC4385"/>
        </reference>

      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>
      The authors of this document would like to thank the MPLS Working Group Design Team for the discussions and comments
      on this document. The authors would also like to thank Amanda Baber for reviewing the IANA Considerations and providing many useful suggestions.
      </t>

    </section>
    <section numbered="false" anchor="contributors" toc="default">
      <name>Contributors</name>
      <t>
          TBA
      </t>
    </section>
  </back>
</rfc>
