<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-song-ippm-ioam-tunnel-mode-00" ipr="trust200902">
  <front>
    <title abbrev="IOAM Tunnel Mode">In-situ OAM Processing in Tunnels</title>

    <author fullname="Haoyu Song" initials="H." role="editor" surname="Song">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <country>USA</country>
        </postal>
        <email>haoyu.song@huawei.com</email>
      </address>
    </author>


    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Road</street>
          <city>Beijing, 100095</city>
          <country>P.R. China</country>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Road</street>
          <city>Beijing, 100095</city>
          <country>P.R. China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>

    <author fullname="Zhongzhen Wang" initials="Z." surname="Wang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Road</street>
          <city>Beijing, 100095</city>
          <country>P.R. China</country>
        </postal>
        <email>wangzhongzhen@huawei.com</email>
      </address>
    </author>

    <date day="25" month="June" year="2018"/>

    <area>OPS &amp; Management</area>

    <workgroup>ippm</workgroup>
    <!---->

    <keyword>In-situ OAM, Tunnel, Uniform, Pipe</keyword>

    <abstract>
	    <t>This document describes the In-situ OAM (iOAM) processing behavior in a network with tunnels.
	       Specifically, the iOAM processing in tunnels with the uniform model and the pipe model is discussed.
	       The procedure is applicable to different type of tunnel protocols.
	    </t>    
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>

    <section title="Motivation">
       <t> In-situ OAM (iOAM) records OAM data associated with user packets while these packets traverse a network 
	       <xref target="I-D.brockners-inband-oam-requirements"></xref>. The iOAM instruction and data 
	       are kept in an iOAM header which is defined in <xref target="I-D.ietf-ippm-ioam-data"></xref>. 
	       The iOAM header needs to be encapsulated in a packet's transport protocol header in order to be processed
	       by the network nodes who are capable of iOAM processing. So far, the iOAM header encapsulation methods
	       have been defined for several protocols, including IPv6, VXLAN-GPE, NSH, SRv6 
	       <xref target="I-D.brockners-inband-oam-transport"></xref>,<xref target="I-D.ietf-sfc-ioam-nsh"></xref>, GENEVE
	       <xref target="I-D.brockners-ippm-ioam-geneve"></xref>, GRE <xref target="I-D.weis-ippm-ioam-gre"></xref>, and some others. 
       </t>
       <t> While the original scope of iOAM is purposely confined to a single network domain for simplicity, 
	       the authentic E2E data collection capability of iOAM is invaluable to network operators. 
	       In reality, especially in carrier networks, a user packet may traverse several network domains and pass through various
	       tunnels for QoS, traffic engineering, or public network traversal.
	       To extend the scope of iOAM's applicability and fully realize iOAM's potential, we need to consider various network conditions. 
	       In this document, we describe how iOAM should be processed in a network with tunnels.
       </t>
       <t> A tunneling protocol usually needs to add another layer of protocol header (i.e., the tunnel header) over the original packet.
	       Within a tunnel, only the outermost tunnel header is supposed to be processed by a network node.
	       Therefore, depending on the locations where the iOAM header is encapsulated/decapsulated and the tunnel operation mode, the iOAM processing 
               is also different.       
       </t>
       <t> In general, there are two modes of tunnel operations: the Uniform Model and the Pipe Model. 
	       The Uniform Model treats the nodes in a tunnel uniformly as the nodes outside of the tunnel on an E2E path. 
	       On the contrary, the Pipe Model abstracts all the nodes between the tunnel ingress and egress as a circuit so no nodes in the tunnel 
	       is visible to the nodes outside of the tunnel. 
               The iOAM processing behavior is discussed for each mode as follows. 
       </t>
    </section>


    <section title="Uniform Model">
	    
      <section title="U1: IOAM Domain Starts and Ends outside of a Tunnel">
	      <t> In this case, a tunnel is fully in between the head node and the end node of an iOAM path. This includes the situation that the tunnel ingress
		      coincides with the iOAM head node and/or the tunnel egress coincides with the iOAM end node. The iOAM header handling for different situation
		      is described as follows:</t>

	      <t><list style="symbols">

			   <t> iOAM head node is outside of the tunnel: The iOAM header is encapsulated into the original packet and processed. </t>	      
		           <t> iOAM head node is the tunnel ingress: The iOAM header is encapsulated into the original packet and processed.
				   The iOAM header is copied from the original packet and encapsulated into the underlay protocol header.</t>


		           <t> iOAM end node is outside of the tunnel: The iOAM header is decapsulated from the original packet after iOAM processing. </t>
	       
			   <t> iOAM end node is the tunnel egress: The iOAM header in the underlay protocol header is processed as usual. 
				   After the tunnel header is removed and the original packet is exposed, the iOAM header is copied to overwrite the original packet's iOAM header.
	                           After the iOAM processing is finished, the iOAM header is removed from the original packet. </t>

	                   <t> Other nodes in the iOAM domain: If the node is outside or inside of the tunnel, 
				   the iOAM header encapsulated in the outermost protocol header is processed.
		                   If the node is the tunnel ingress, the iOAM header in the original packet needs to be copied and encapsulated into the underlay protocol header. 
				   If the node is the tunnel egress, the iOAM header in the underlay protocol header needs to be copied to overwrite the iOAM header in the original
				   packet. 
	                    </t>

              </list></t>
      </section>

      <section title="U2: IOAM Domain Starts and Ends within a Tunnel">
	      <t> There is nothing special about this case since the transport network will not be aware of the tunnel. In this case, the iOAM is processed as usual.</t>
      </section>      

      <section title="U3: IOAM Domain Starts and Ends at any Nodes">
	      <t> For extra flexibility, the iOAM domain can be configured to start and end at any node (e.g., in or out of a tunnel). The iOAM header handling 
	      for different situation is described as follows:</t>
              
              <t><list style="symbols">
			      <t> iOAM head node is outside of the tunnel: The iOAM header is encapsulated in the original packet.</t>
			      <t> iOAM head node is the tunnel ingress: The iOAM header is encapsulated in the original packet first and processed. 
				      Then the iOAM header is copied from the original packet and encapsulated into the underlay protocol header. 
				      Meanwhile, the iOAM header in the original packet must be removed.</t> 
			      <t> iOAM head node is in the tunnel: The iOAM header is encapsulated in the underlay protocol header and processed.</t>
			      <t> iOAM head node is the tunnel egress: The iOAM header is encapsulated in the underlay protocol header first and processed. 
				      When the tunnel header is removed, the iOAM header is copied from the underlay protocol header and 
				      encapsulated into the original packet. </t>

			      <t> iOAM end node is outside of the tunnel: The iOAM header is decapsulated from the original packet.</t>
			      <t> iOAM end node is the tunnel ingress: The iOAM header is decapsulated from the original packet.  </t> 
			      <t> iOAM end node is in the tunnel: The iOAM header is decapsulated from the underlay protocol header.</t>
			      <t> iOAM end node is the tunnel egress: The iOAM header is removed with the underlay protocol header. </t>

			      <t> Tunnel ingress is in the IOAM domain: The iOAM header is decapsulated from the original packet and encapsulated in the underlay protocol header.</t>
			      <t> Tunnel egress is in the iOAM domain: The iOAM header in the underlay protocol header is encapsulated into the original packet.</t>
	      </list></t>
      
      </section>

      <section title="Discussion">
	      <t> U1 achieves the best implementation efficiency since it eliminates one encapsulation or decapsulation operation while U3 achieves the best flexibility and 
		      reduces the packet overhead. </t> 

	      <t> Since a tunnel usually aggregates multiple flows, so U2 (or U3 when the iOAM head node is in a tunnel) can only conduct iOAM at the tunnel granularity and 
		      on aggregated flows. </t> 
      </section>
<!--
      <t><figure anchor="figure_1" title="xxx">
         <artwork><![CDATA[
       ++++++++
     
         ]]></artwork>
      </figure></t>
-->

    </section>

    <section title="Pipe Model">

      <section title="P1: IOAM Domain Starts and Ends outside of a Tunnel">
	      <t> This case includes the situation that the tunnel ingress coincides with the iOAM head node and/or the tunnel egress coincides with the iOAM end node.</t>
	      <t> In this mode, the iOAM header only exists in the original packet. It is not copied to the tunnel header.
		      Within the tunnel, the iOAM header is invisible to the underlay network so it is not processed.
		      At the tunnel ingress, the iOAM header is processed before the tunnel header is applied.
	              At the tunnel egress, the iOAM header is processed after the tunnel header is removed. 
	              To the iOAM header, the entire tunnel appears to be just one hop. </t>
      </section>	      

      <section title="P2: IOAM Domain Starts and Ends within a Tunnel">
	    <t>This mode is identical to U2.</t>
      </section>

      <section title="Discussion">
           <t> In P1, the hop-by-hop iOAM data is missing for the tunnel. However, this mode also provides a convenient way to pass through third party tunnels in which 
		   either the iOAM is not supported or the tunnel operators do not participate in the iOAM service.</t>
	   <t> On the other hand, the tunnel operators can support iOAM independently to monitor the tunnel performance using the mode of P2.
	       In this case, U1 can also be applied without any confliction, so both underlay and overlay can be monitored by different entities. </t> 
	   <t> When iOAM works in the E2E operation mode as described in <xref target="I-D.ietf-ippm-ioam-data"></xref>, 
		   any tunnel on the path should be configured to the Pipe model in order to avoid the unnecessary iOAM header 
		   encapsulation/decapsulation.</t>
      </section>

    </section>

    <section title="Examples">
      <t> Examples will be added in future revisions.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>N/A</t>
    </section>
    
    <section anchor="Contributors" title="Contributors">
      <t>TBD.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>TBD.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.I-D.ietf-ippm-ioam-data'?>
      <?rfc include='reference.I-D.brockners-inband-oam-transport'?>
      <?rfc include='reference.I-D.weis-ippm-ioam-gre'?>
      <?rfc include='reference.I-D.brockners-ippm-ioam-geneve'?>
      <?rfc include='reference.I-D.ietf-sfc-ioam-nsh'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.brockners-inband-oam-requirements'?>
    </references>
  </back>
</rfc>
