<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-liu-mpls-nas-combination-00"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

 <!-- ***** FRONT MATTER ***** -->

 <front>


   <title abbrev="NAS Combination">Combination Method of NASs</title>
    <seriesInfo name="Internet-Draft" value="draft-liu-mpls-nas-combination-00"/>


   <author fullname="Yao Liu" surname="Liu">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>liu.yao71@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
	
	 <author fullname="Zheng Zhang" surname="Zhang">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>zhang.zheng@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
    <date year="2022"/>

   <!-- Meta-data Declarations -->

   <area>Transport</area>
    <workgroup></workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>MPLS</keyword>
   <keyword>MNA</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
    <t>
	This document provides an alternate mechanism to provide different ordering of in-stack data for MNA solutions which leverage the fixed bit catalogs.
    </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  <t>There is significant interest in developing the MPLS data plane to address the requirements of new applications <xref target="I-D.ietf-mpls-mna-usecases"></xref>. As introduced in <xref target="I-D.andersson-mpls-mna-fwk"></xref>, the MPLS Network Actions (MNA) technologies aim to solve this. An MNA solution is envisioned as a set of network action sub-stacks(NAS), each consists of label, indicators and in-Stack Data.</t>
	<t>One MNA solution may choose to encode the set of network actions as a list of bits in the network action indicator, and the ordering of the in-stack data LSEs corresponds to the ordering of the network action indicators. If the meaning and ordering of the bits in the network action indicator is fixed, then the ordering of the network action and the corresponding possible in-stack data in the NAS are fixed either.</t>
	<t>Solutions leveraging the fixed bit catalogs are efficient for LSRs to process, but there may be scenarios where the ordering of the network actions/in-stack datas expected is not the ordering specified in the network action indicator.</t>
	<t>This document provides an alternate mechanism to provide different ordering of in-stack data for MNA solutions which leverage the fixed bit catalogs and makes these solutions more flexible.</t> 
	
		<section 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>.</t>
		</section>
	
		<section numbered="true" toc="default">
        <name>Terminology</name>
        <t>The terminologies follows <xref target="I-D.andersson-mpls-mna-fwk"></xref>.</t>
	  <ul spacing="normal">
        <li>
		<t>Ancillary Data (AD): Data relating to the MPLS packet that may be used to affect the forwarding or other processing of that packet,  either at an Label Edge Router (LER) <xref target="RFC4221"></xref> or Label Switching Router (LSR).  This data may be encoded within a network action sub-stack (see below) (in-stack data), and/or after the bottom of the label stack (post-stack data).</t>
		</li>
		<li>
        <t>Network Action: An operation to be performed on a packet.  A network action may affect router state, packet forwarding, or it may affect the packet in some other way.  A network action is said to be present if there is an indicator in the packet that invokes the action.</t>
		</li>
		<li>
		<t>Network Action Indication (NAI): An indication in the packet that a certain network action is to be perfomed.  There may be associated ancillary data in the packet.</t>
		</li>
		<li>
		<t>Network Action Sub-Stack (NAS): A set of related, contiguous Label Stack Entries (LSEs).  The first LSE is the Network Action Sub-stack Indicator.  The TC and TTL values in the sub-stack may be redefined.</t>
		</li>
		<li>
		<t>Network Action Sub-Stack Indicator (NSI): An LSE that contains a special label that indicates the start of a Network Action Sub-stack.</t>
        </li>		
     </ul>			
		</section>	   
    </section>
	
	<section numbered="true" toc="default">
	<name>Combination of NASs</name>

		<section numbered="true" toc="default">
		<name>Different Ordering of Network Action/In-stack Data</name>
		<figure anchor="Indicator">
		<name>Bit-cataloged Indicator</name>
        <artwork align="center" name="Bit-cataloged Indicator"><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Label                  |x x x|S|x x|x|x x x|A|B|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	  
           ]]></artwork>
		</figure>		
		<t>Figure 1 show an example of a bit-cataloged indicator in the NAS (using the TC and TTL repurposed method).</t>
		<t>Bit A indicates that network action A and the corresponding in-stack ancillary data A is present when set to 1. </t>
		<t>Bit B indicates that network action B and the corresponding in-stack ancillary data A is present when set to 1. </t>
		<t>If bit A and bit B are both set to 1, it indicates that both network action A and network action B are present, and the LSE which carries data A is followed by that which contains data B.</t>
		<t>If it is required that data B is located before data A in the packet, an single NAS based on the fixed-bit approach can't fulfill this requirement.</t>
		</section>
		
		<section numbered="true" toc="default">
		<name>C-bit in the Indicator</name>
		<t>This document introduces a continue bit (C-bit) in the indicator as shown in the encoding example in Figure 2.</t>
		<figure anchor="C-bit">
		<name>C-bit in the Indicator</name>
        <artwork align="center" name="C-bit in the Indicator"><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Label                  |x x x|S|x x|C|x x x|x|x|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	  
           ]]></artwork>
		</figure>		
		<t>When C-bit is set to 1, it indicates that there's another NAS following and the LSR SHOULD continue to look for the beginning of the next NAS and process it.</t>
		<t>With C-bit, NASs can be combined together as a whole to express different ordering of network actions and in-stack data.</t>		
		</section>		
		
		<section numbered="true" toc="default">
		<name>Encoding Example</name>
		<t>Figure 3 shows an encoding example of the combination of NASs leveraging C-bit.</t>
		<figure anchor="NASs">
		<name>Combination of NASs</name>
        <artwork align="center" name="Combination of NASs"><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------
     |                Label                  |x x x|S|x x|1|x x x|0|1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   NAS-1
     |                         Data   B                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------
     |                Label                  |x x x|S|x x|0|x x x|1|0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   NAS-2
     |                         Data   A                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------- 
           ]]></artwork>
		</figure>		
		<t>For the indicator in NAS-1: </t>
		<t>C=1: there's another NAS following. </t>
		<t>B=1: Data B is included.</t>
		<t>For the indicator in NAS-2:</t>
		<t>C=0: there's no NAS following.</t>
		<t>A=1: Data A is included.</t>
		
		</section>		

	</section>	  
	
<section numbered="true" toc="default">
	<name>IANA Considerations</name>
	<t>IANA is requested to create a new registry to assign a bit position for C-bit of the network action indicator. .</t>
        <artwork align="center" ><![CDATA[
              +==============+=============+===============+
              | Bit Position | Description | Reference     |
              +==============+=============+===============+
              |  TBA         | Continue to | This document |
              |              |  next NAS   |               |
              +--------------+-------------+---------------+
           ]]></artwork>
	</section>	

<section numbered="true" toc="default">
	<name>Security Considerations</name>
    <t>This document introduces no new security considerations.</t>
</section>	
	
	
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
		<?rfc include="reference.RFC.2119.xml"?>
		<?rfc include="reference.I-D.andersson-mpls-mna-fwk.xml"?>			  
      </references>
      <references>
        <name>Informative References</name>
	<?rfc include="reference.RFC.4221.xml"?>
	<?rfc include="reference.I-D.ietf-mpls-mna-usecases.xml"?>		
      </references>
    </references>


 </back>
</rfc>
