<?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-03.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-ioam-data-extension-01"
     ipr="trust200902">
  <front>
    <title abbrev="IOAM Data Type Extension">
         In-situ OAM Data Type Extension</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, data type extension, scalability</keyword>

    <abstract>
      <t>
	 This document describes a proposal which extends in-situ OAM to support 
	 potential future standard tracing data in addition to those currently defined. 
	 We provide use cases to motivate our proposal and base the modifications on 
	 the latest in-situ OAM header format specification.   
      </t>
    </abstract>
  </front>

  <middle>

    <section title="Motivation for Data Type Extension">
      <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>
	 Currently 12 data types and associated formats (including wide format and short format 
	 of the same data) are defined in <xref target="I-D.ietf-ippm-ioam-data"></xref> . 
	 The presence of data is indicated by a 16-bit bitmap in the "OAM-Trace-Type" field.    
      </t><t>
	 In the current specification only four bits are left to identify new standard data types. 
	 Moreover, some data is forced to be bundled together as a single unit to save bitmap 
         space and pack data to the ideal size (e.g., the hop limit and the node id are bundled, 
	 and the ingress interface id and the egress interface id are bundled), 
	 regardless of the fact that an application may only ask for a part of the data. 
	 Last but not the least, each data is forced to be 4-byte aligned for easier access, 
	 resulting in waste of header space in many cases.   
      </t><t>
         Since the data plane bandwidth, the data plane packet processing, and the management 
         plane data handling are all precious yet scarce resource, the scheme should strive to be simple and precise. 
         The application should be able to control the exact type and format of data it needs to collect and analyze. 
	 It is conceivable that more types of data may be introduced in the future. 
	 However, the current scheme cannot support it after all the bits in the bitmap are used up.    
      </t><t>
         For example, when a flow traverses a series of middleboxes (e.g., Firewall, NAT, and load balancer), 
	 its identity (e.g., the 5-tuple) is often altered, which makes the OAM system lose track of the flow trace. 
	 In this case, we may want to copy some of the original 
	 packet header fields into the iOAM header so the original flow can be identified at any point of the network.  
      </t><t>
	 For another example, in wireless, mobile, and optical network environments, some physical data associated with a flow 
	 (e.g., power, temperature, signal strength, GPS location) need to be collected to monitor the service performance. 
      </t><t>
         For another example, some data may have different semantics and formats in different networks and application scenarios. 
         An example is the timestamp data type in which NTP, PTP, or any other local defined approaches can be used. 
      </t><t>
         All the above cases require new iOAM data types. More examples are listed in <xref target="uc1"></xref>.
      </t><t>
         There are some other issues about the current specification. 
         For example, bit 7 is used to indicate the presence of variable length opaque state snapshot data;
         Bit 5 and bit 10 are used to indicate the presence of the application specific data. 
         While these data fields can be used to store arbitrary data, 
	 the data is difficult to be standardized and another schema is needed to decode the data, 
	 which may lead to low data plane performance as well as interoperability issues.
	 More important, the existence of the variable length data complicates the data processing such as data packing and encapsulation. 
         It is preferred to know the data type and size in advance for efficient hardware implementation.	 
      </t>
    </section>

    <section title="Scalable Data Type Extension">
      <t>
         Based on the observation in Section 1, we propose a method for data type encoding 
         which can solve the current limitation and address future data requirements.  
      </t>
      <section title ="Data Type Bitmap">    
        <t>
          Bitmap is simple and efficient data structure for high performance data plane implementation. 
	  The base bitmap size is kept to be 16 bits. 
	  We use one bit to indicate a single type of data in a single format. 
	  The last bit in the bitmap (i.e., bit 15), if set, is used to indicate 
	  the presence of the next data type bitmap, which is 32 bits long. 
	  In the second bitmap, bit 31 is again reserved to indicate a third bitmap, and so on. 
	  With each extra bitmap, 31 more data types can be defined. 	    
	</t><t>
	  <xref target="figure_1"></xref> shows an example of the in-situ OAM header format 
	  with two extended OAM trace type fields. Except the OAM Trace Type fields, all other fields remain 
	  the same as defined in <xref target="I-D.ietf-ippm-ioam-data"></xref>.  
	</t><t>
	  <figure title="Extended OAM Trace Type Header Format" anchor="figure_1">  
	    <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      |1|NodeLen|  Flags  | Octets-left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Extended OAM Trace Type 1                    |1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Extended OAM Trace Type 2                    |0|   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Node Data List []                            |
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            </artwork>
         </figure>
       </t><t>
         The specification of the Base OAM Trace Type is the same as the OAM Trace Type 
	 in <xref target="I-D.ietf-ippm-ioam-data"></xref> except the last bit, which is defined as follows:
       </t><t>
         <list style="symbols">
	   <t> Bit 15: When set indicates presence of next bit map.</t>
         </list>
       </t><t>
         The OAM trace type fields are labeled as Base OAM Trace Type, Extended OAM Trace Type 1, 
	 Extended OAM Trace Type 2, and so on. The Base OAM Trace Type is always present.
         If no data type is asked by the application in Extended OAM Trace Type n and beyond, 
	 then the last bit in the previous bitmap is set to 1 and these extended fields are not included in the header. 
         On the other hand, to eliminate ambiguity, if any data is asked for by the application 
	 in Extended OAM Trace Type n, then Extended OAM Trace Type 1 to (n-1) must be included in the header, 
         even though no data type in these bitmaps are needed (i.e., all zero bitmap except the last bit).
       </t><t>
         The actual data in a node is packed together in the same order as listed in the OAM Trace Type bitmap. 
	 Each node is padded to be the multiple of 4 bytes. 
       </t>
    </section>

    <section title="Use Cases" anchor="uc1">

       <t> 
         New types of data can be potentially added and standardized, which demand new bits allocated 
	 in the OAM Trace Type bitmaps. Some examples are listed here.
       </t><t>
         <list style="symbols">
			    <t> Metered flow bandwidth.</t>
			    <t> Time gap between two consecutive flow packets. </t>
			    <t> Remaining time budget to the packet delivery deadline. </t> 
			    <t> Buffer occupancy on the Node. </t>
			    <t> Queue depth on each level of hierarchical QoS queues. </t>
			    <t> Packet jitter at the Node.</t>
			    <t> Current packet IP addresses. </t>
			    <t> Current packet port numbers. </t>
			    <t> Time using different network timing protocol. </t>
			    <t> Other node statistics. </t>
	 </list>
       </t>

    </section>
   
    <section title ="Consideration for Efficient Data Packing">
       <t>
         The length of each data must be the multiple of 2 bytes. However, allowing different 
	 data type to have different length, while efficient in storage, makes data 
	 alignment and packing difficult.  
       </t><t>
         If we can define the maximum number of data types that can be carried per packet, 
         the offset of each data in the node can be pre-calculated and carried in the iOAM header. 
	 The overhead can be justified by the overall space saving of the node data list. Otherwise, 
	 each data's offset in the node must be calculated in each device, with the help of a 
	 table which stores the size of each data type. We can also arrange the bitmap to reflect the 
	 data availability order in the system (e.g.,  the bit for egress_if_id must be after the bit 
	 for ingress_if_id), so in a pipeline-based system, the required data can be packed one
	 after one.
       </t>
    </section>

    <section title ="Alternative Data Extension Possibilities">
       <t>
         Bitmap is simple and support parallel processing in hardware. However, 
	 it is not the only option to support data type extension. For example, 
	 cascaded TLV can be used to support arbitrary number of new data types. 
	 This can be implemented by using a flag bit to indicate the presence of extra data types and packing 
	 the number of types and the list of the type IDs after the trace option header. The corresponding data
         is therefore added in each node data list in the order as its type ID is listed in the extended trace option header.	 
       </t>
    </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t> 
        There is no extra security considerations beyond those have been identified by the original in-situ OAM proposals.  
      </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>

