<?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" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY IOAMReq SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-brockners-inband-oam-requirements-02.xml">
<!ENTITY IOAMData SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ippm-ioam-data-00.xml">
]>
<?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="std" docName="draft-song-ippm-segment-ioam-01"
     ipr="trust200902">
  <front>
    <title abbrev="Segment IOAM">
         Control In-situ OAM Overhead with Segment IOAM </title>

    <author fullname="Haoyu Song" initials="H." surname="Song" role="editor">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>2330 Central Expressway</street>

          <city>Santa Clara, 95050</city>

          <country>USA</country>
        </postal>

        <email>haoyu.song@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>

    <date month="April" year="2018"/>

    <area>OPS &amp; Management</area>

    <workgroup>ippm</workgroup>

    <keyword>in-situ OAM, segment ioam, scalability</keyword>

    <abstract>
      <t>
	      This document describes a proposal which partitions an in-situ OAM (iOAM) domain into multiple segments in order to control the iOAM data overhead, 
	      adapt to the path MTU limitations, and enable new applications. We discuss several use cases to motivate our proposal 
	      and base the necessary modifications on the current in-situ OAM header format specification.   
      </t>
    </abstract>
  </front>

  <middle>

    <section title="Introduction">
      <t>
        <xref target="I-D.brockners-inband-oam-requirements">In-situ OAM (iOAM)</xref> records OAM information 
	within user packets while the packets traverse a network. 
        The data types and data formats for in-situ OAM data records have been defined 
	in <xref target="I-D.ietf-ippm-ioam-data"></xref>. 
      </t><t>
        iOAM may incur significant overhead on user packets. The overhead includes the iOAM header and 
        the node data list for each network element. 
      </t><t>
        The total size of data is limited by the MTU. When the number of required data types is large 
        and the forwarding path length is long, it is possible that there is not enough
	space in the user packets to hold the iOAM header and data. The current proposal is to label the overflow status and 
	stop adding new node data to the packet, leading to the loss of information. 
      </t><t>
        Even if the header has enough space to hold the iOAM data, the overhead may be too large 
        and consumes too much bandwidth. 
	For example, if we assume moderate 20 bytes of data per node, a path with length of 10 will need 
	200 bytes to hold the data. 
	This will inflate small 64-byte packets by more than four times. Even for the largest packet size (e.g., 1500 bytes),
	the overhead (>10%) is not negligible.  
	Therefore, we need to limit the iOAM data overhead without sacrificing the data collection capability. 
      </t><t>
        Here we have another interesting related issue. Packets can be dropped anywhere in a network for various reasons. 
	If we can only collect iOAM data at the path end, we
	lose all data from the dropped packets and have no idea where the packets are dropped. 
	This defies the purpose of iOAM and makes those iOAM-enabled nodes work in vain. 
      </t>
    </section>
      
    <section title = "Segment In-situ OAM">
      <t>
        Based on the observation in Section 1, we propose a method to limit the size of the node data list.  
      </t>
      <section title="Segment and Hops">
        <t>
	  A hop is a node on a flow's forwarding path which is capable of processing iOAM data. 
	  A segment is a fixed number hops on a flow's forwarding path.      
	  While working in the "per hop" trace mode, the segment size (SSize) and the remaining hops (RHop), 
	  is added to the iOAM header at the edge. Initially, RHop is equal to SSize. 
	  At each hop, if RH is not zero, the node data is added to the node data list at the corresponding 
	  location and then RH is decremented by 1.  
	  If RH is equal to 0 when receiving the packet, the node needs to remove (in incremental trace option) 
	  or clear (in pre-allocated trace option) the iOAM node data list and 
	  reset RHop to SSize. Then the node will add its data to the node data list as if it is the edge node. 
        </t><t>
          The stripped iOAM data at the segement edge can be immediately exported to a collector. 
	</t><t>
          
          <xref target="figure_2"></xref> shows the proposed in-situ OAM header format. The bit 23 
	  in the Flags field is used to indicate the current header is a segment iOAM header.
	  In this context, the last octet in the iOAM header is partitioned into two 4-bit nibbles. 
	  The first nibble (SSize) is used to save the segment size and the second nibble (RHop) 
	  is used to save the remaining hops.
	  This limits the maximum segment size to 15. 
        </t><t>
	  <figure title="Segment iOAM Header Format" anchor="figure_2">  
          <artwork>
                  
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Base OAM Trace Type        |NodeLen|Flags|1| SSize | RHop  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Node Data List []                            |
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       	  </artwork>
          </figure>
	  </t><t>
	    In the special case when SSize is set to 0, no data will be recorded in the node data list. 
	    The requested data listed in the OAM Trace Type will be immediately exported to the collector. 
	    This way the iOAM overhead is minimized. 
          </t>

      </section>

      <section title = "Considerations for Data Handling">
        <t>
          At any hop when RHop is equal to 0, the node data list is copied from the iOAM header. 
          The data can be encapsulated and reported to the controller or the edge node as configured. 
          The encapsulation and report method is beyond the scope of this draft but should be comply 
	  with the method used by the iOAM edge node.    
        </t><t>
          The actual size of the last segment may not be equal to SSize but this is not a problem.
        </t>
      </section>

      <section title = "Use Cases" anchor="uc2">
	<t> Segment iOAM is necessary in the following example scenarios:</t><t>
	<list style="symbols">
          <t>
            Segment iOAM can be used to detect at which segment the flow packet is dropped. 
            If the SSize is set to 1, then the exact drop node can be identified. 
	    The iOAM data before the dropping point is also retained.
	  </t><t>
	    The path MTU allows to add at most k node data in the list to avoid fragmentation. 
	    Therefore SSize is set to k and at each hop where RHop is 0, the node data list is retrieved and sent
            in a standalone packet. 
	  </t><t>
            A flow contains mainly short packets and travels a long path. It would be inefficient to keep 
            a large node data list in the packet so the network bandwidth utilization rate is low. 
	    In this case, segment iOAM can be used to limit the ratio of the iOAM data to the flow packet payload. 
	  </t><t>
            The network allows at most n bytes budget for the iOAM data. There is a tradeoff between 
            the number of data types that can be collected and the number of hops for data collecting. 
            The segment size is therefore necessary to meet the application's data requirement 
	    (i.e., SSize * Node Data Size &lt; n).
    	  </t>
	</list>
        </t>
      </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t> 
        There is no extra security considerations beyond those have been identified by in-situ OAM protocol.  
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>We would like to thank Frank Brockners, Carlos Pignataro, and Shwetha Bhandari for helpful comments and suggestions.</t>
    </section>
    
    <section anchor="Contributors" title="Contributors">
      <t>The document is inspired by numerous discussions with James N. Guichard. He also provided significant comments 
         and suggestions to help improve this document.</t>
    </section>

  </middle>

  <back>
    <references title="Informative References">
      &IOAMReq;
      &IOAMData;
    </references>
  </back>
</rfc>
