<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zhou-ippm-enhanced-alternate-marking-10"
     ipr="trust200902">
  <front>
    <title abbrev="enhanced-alternate-marking">Enhanced Alternate Marking
    Method</title>

    <author fullname="Tianran Zhou" initials="T." surname="Zhou, Ed.">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <email>zhoutianran@huawei.com</email>
      </address>
    </author>

    <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Riesstrasse, 25</street>

          <city>Munich</city>

          <code>80992</code>

          <region/>

          <country>Germany</country>
        </postal>

        <email>giuseppe.fioccola@huawei.com</email>
      </address>
    </author>

    <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
      <organization>Telecom Italia</organization>

      <address>
        <postal>
          <street>Via Reiss Romoli, 274</street>

          <city>Torino</city>

          <region/>

          <code>10148</code>

          <country>Italy</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>mauro.cociglio@telecomitalia.it</email>

        <uri/>
      </address>
    </author>

    <author fullname="Yisong Liu" initials="Y." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>liuyisong@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Shinyoung Lee" initials="S." surname="Lee">
      <organization>LG U+</organization>

      <address>
        <postal>
          <street>71, Magokjungang 8-ro, Gangseo-gu</street>

          <city>Seoul</city>

          <region/>

          <code/>

          <country>Republic of Korea</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>leesy@lguplus.co.kr</email>

        <uri/>
      </address>
    </author>

    <author fullname="Weidong Li" initials="W." surname="Li">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>poly.li@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="29" month="August" year="2022"/>

    <workgroup>IPPM</workgroup>

    <abstract>
      <t>This document extends the IPv6 Alternate Marking Option to provide
      enhanced capabilities and allow advanced functionalities. With this
      extension, it can be possible to perform thicker packet loss
      measurements and more dense delay measurements with no limitation for
      the number of concurrent flows under monitoring.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The <xref target="RFC8321">Alternate Marking</xref> and <xref
      target="RFC8889">Multipoint Alternate Marking</xref> define the
      Alternate Marking technique that is a hybrid performance measurement
      method, per <xref target="RFC7799"/> classification of measurement
      methods. This method is based on marking consecutive batches of packets
      and it can be used to measure packet loss, latency, and jitter on live
      traffic.</t>

      <t>The <xref target="I-D.ietf-6man-ipv6-alt-mark">IPv6 AltMark
      Option</xref> applies the Alternate Marking Method to IPv6, and defines
      an Extension Header Option to encode the Alternate Marking Method for
      both the Hop-by-Hop Options Header and the Destination Options Header.
      Similarly, <xref target="I-D.fz-spring-srv6-alt-mark">SRv6
      AltMark</xref> defines how Alternate Marking data is carried as a TLV in
      the Segment Routing Header.</t>

      <t>While the IPv6 AltMark Option implements the basic alternate marking
      methodology, this document defines extended data fields for the AltMark
      Option and provides enhanced capabilities to overcome some challenges
      and enable future proof applications.</t>

      <t>It is worth mentioning that the enhanced capabilities are intended
      for further use and are optional.</t>

      <t>Some possible enhanced applications MAY be:<list style="numbers">
          <t>thicker packet loss measurements: the single marking method of
          the base AltMark Option can be extended with additional marking bits
          in order to get shortest marking periods under the same timing
          conditions.</t>

          <t>more dense delay measurements: than double marking method of the
          base AltMark Option can be extended with additional marking bits in
          order to identify down to each packet as delay sample.</t>

          <t>increase the number of concurrent flows under monitoring: if the
          20-bit FlowMonID is set independently and pseudo randomly, there is
          a 50% chance of collision for 1206 flows. The size of FlowMonIDcan
          can be extended to raise the entropy and therefore to increase the
          number of concurrent flows that can be monitored.</t>
        </list></t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Data Fields Format">
      <t>The Data Fields format is represented in Figure 1. An 4-bit
      NH(NextHeader) field is allocated from the Reserved field of <xref
      target="I-D.ietf-6man-ipv6-alt-mark">IPv6 AltMark Option</xref>. It is
      worth highlighting that remaining bits of the former Reserved field
      continue to be reserved.</t>

      <figure title="Figure 1: Data fields indicator for enhanced capabilities">
        <artwork><![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
+---------------------------------------+-+-+-----------+-------+
|           FlowMonID                   |L|D|  Reserved |  NH   |
+---------------------------------------+-+-+-----------+-------+

]]></artwork>
      </figure>

      <t>The NH (NextHeader) field is used to indicate the extended data
      fields which are used for enhanced capabilities:<list>
          <t>NextHeader value of 0x00 is reserved for backward compatibility.
          It means that there is no extended data field attached.</t>

          <t>NextHeader values of 0x01-0x08 are reserved for private use or
          for experimentation.</t>

          <t>NextHeader value of 0x09 indicates the extended data fields. The
          format is showed in Figure 2.</t>
        </list></t>

      <figure title="Figure 2: Data fields extension for enhanced alternate marking">
        <artwork><![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 
+---------------------------------------+-------+-------+-------+
|           FlowMonID Ext               | Flag  |  Len  |   R   |
+-------------------------------+-------+-------+-------+-------+
|           MetaInfo            |      Padding (variable)       |
+-------------------------------+-------------------------------+
//                    Padding (variable)                       //
+-------------------------------+-------------------------------+
]]></artwork>
      </figure>

      <t>where:</t>

      <t><list style="symbols">
          <t>FlowMonID Ext - 20 bits unsigned integer. This is used to extend
          the FlowMonID to reduce the conflict when random allocation is
          applied. The disambiguation of the FlowMonID field is discussed in
          <xref target="I-D.ietf-6man-ipv6-alt-mark">IPv6 AltMark
          Option</xref>.</t>

          <t>Flag - A 4-bit flag to indicate the special purpose usage (see
          below).</t>

          <t>Len - Length. It indicates the length of the enhanced alternate
          marking extension in bytes.</t>

          <t>R - Reserved for further use. These bits MUST be set to zero on
          transmission and ignored on receipt.</t>

          <t>MetaInfo - A 16-bit Bitmap to indicate more meta data attached
          for the enhanced function (see below).</t>

          <t>Padding - These bits MUST be set to zero when not being used.</t>
        </list></t>

      <t>The Flag is defined in Figure 3 as:</t>

      <t><list style="symbols">
          <t>bit 0 - Measurement mode, M bit. M=0, indicates that it is for
          hop-by-hop monitoring. M=1, indicates that it is for end-to-end
          monitoring.</t>

          <t>bit 2 - Flow direction identification, F bit. This flag is used
          in the case backward direction flow monitoring is requested to be
          set up automatically. F=1, indicates that the flow direction is
          forward. F=0, indicates the flow direction is backward.</t>

          <t>others (shown as R) - Reserved. MUST be set to zero and ignored
          on receipt.</t>
        </list></t>

      <figure title="Figure 3: Flag data field">
        <artwork align="center"><![CDATA[ 0 1 2 3
+-------+
|M|R|F|R|
+-------+]]></artwork>
      </figure>

      <t>The MetaInfo is defined in Figure 4 as a bit map as follows:</t>

      <figure title="Figure 4: MetaInfo data field">
        <artwork align="center"><![CDATA[ 0 1 2 3 4 5 6 7
+---------------+
|    MetaInfo   |
+---------------+]]></artwork>
      </figure>

      <t><list style="symbols">
          <t>bit 0: indicates a 6 bytes Timestamp is attached after the
          MetaInfo. Timestamp(s) stands for the number of seconds in the
          timestamp. It will overwrite the Padding after MetaInfo.
          Timestamp(ns) stands for the number of subseconds in the timestamp
          with the unit of nano second. This Timestamp is filled by the
          encapsulation node, and is taken all the way to the decapsulation
          node. So that all the intermediate nodes could compare it with its
          local time, and measure the one way delay. <figure
              title="Figure 5: Timestamp data field">
              <artwork><![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 
                                +-------------------------------+
                                |    Timestamp(s)               |
+-------------------------------+-------------------------------+
|                 Timestamp(ns)                                 |
+---------------------------------------------------------------+
]]></artwork>
            </figure></t>

          <t>bit 1: indicates the control information with the following data
          format is attached: <figure
              title="Figure 6: Control words for backward direction flow monitoring">
              <artwork><![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 
+---------------+---------------+-----------+-------------------+
|  DIP Mask     |  SIP Mask     | Control   |    Period         |
+---------------+---------------+-----------+-------------------+]]></artwork>
            </figure> This is used to set up the backward direction flow
          monitoring. Where:<list style="symbols">
              <t>DIP Mask: is the length of the destination IP prefix.</t>

              <t>SIP Mask: is the length of the source IP prefix.</t>

              <t>Control: indicates more match fields to set up the backward
              direction flow monitoring.</t>

              <t>Period: indicates the alternate marking period with the unit
              of second.</t>
            </list></t>

          <t>bit 2: indicates a 4 bytes Sequence number with the following
          data format is attached after the MetaInfo. Sole Sequence cound be
          used to detect the out-of-order packets, in addition to the normal
          loss measurement. More over, the Sequence can be used together with
          the latency measurement, so as to get the per packet timestamp.
          <figure title="Figure 7: Sequence number data field">
              <artwork><![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 
+---------------------------------------------------------------+
|                          Sequence                             |
+---------------------------------------------------------------+]]></artwork>
            </figure></t>
        </list></t>

      <t>It is worth noting that the meta data information specified above in
      Figure 5, Figure 6 and Figure 7 must be ordered according to the order
      of the MetaInfo bits.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t><xref target="I-D.ietf-6man-ipv6-alt-mark">IPv6 AltMark Option</xref>
      analyzes different security concerns and related solutions. These
      aspects are valid and applicable also to this document. In particular
      the fundamental security requirement is that Alternate Marking MUST only
      be applied in a specific limited domain, as also mentioned in <xref
      target="RFC8799"/>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no request to IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.7799'?>

      <?rfc include='reference.I-D.ietf-6man-ipv6-alt-mark'?>

      <?rfc include='reference.I-D.fz-spring-srv6-alt-mark'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.8321'?>

      <?rfc include='reference.RFC.8889'?>

      <?rfc include='reference.RFC.8799'?>
    </references>
  </back>
</rfc>
