<?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-13"
     ipr="trust200902">
  <front>
    <title abbrev="enhanced-alternate-marking">Enhanced Alternate Marking
    Method</title>

    <author fullname="Tianran Zhou" initials="T." role="editor" surname="Zhou">
      <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="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="Mauro Cociglio" initials="M." surname="Cociglio">
      <organization>Telecom Italia</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>mauro.cociglio@outlook.com</email>

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

    <author fullname="Ran Pang" initials="R." surname="Pang">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street>9 Shouti South Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100089</code>

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

        <phone/>

        <facsimile/>

        <email>pangran@chinaunicom.cn</email>

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

    <author fullname="Lixia Xiong" initials="L." surname="Xiong">
      <organization>CITC</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

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

        <phone/>

        <facsimile/>

        <email>xionglx1@dimpt.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="19" month="October" year="2023"/>

    <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="RFC9341">Alternate Marking</xref> and <xref
      target="RFC9342">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="RFC9343">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. </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. A 4-bit
      NH(NextHeader) field is allocated from the Reserved field of <xref
      target="RFC9343">IPv6 AltMark Option</xref>. It is worth highlighting
      that remaining bits of the former Reserved field continue to be
      reserved.</t>

      <figure anchor="Figure 1"
              title="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 style="symbols">
          <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 anchor="Figure 2"
              title="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 in order to reduce the conflict when random allocation
          is applied. The disambiguation of the FlowMonID field is discussed
          in <xref target="RFC9343">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="hanging">
          <t>bit 0: Measurement mode, M bit. If M=0, it indicates that it is
          for hop-by-hop monitoring. If M=1, it 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. If F=1, it indicates that the flow direction is
          forward. If F=0, it indicates that the flow direction is
          backward.</t>

          <t>bit 1 and bit 3: Reserved (shown as R). These bits MUST be set to
          zero and ignored on receipt.</t>
        </list></t>

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

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

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

      <t><list style="hanging">
          <t>bit 0: if set to 1, it indicates a 6 bytes Timestamp that is
          attached as Padding 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 sub-seconds
          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
              anchor="Figure 5" title="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: if set to 1, it indicates the control information with the
          following data format that is attached as Padding after the
          MetaInfo: <figure anchor="Figure 6"
              title="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>
              <t>DIP Mask: it is the length of the destination IP prefix.</t>

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

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

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

          <t>bit 2: if set to 1, it indicates a 4 bytes Sequence number with
          the following data format that is attached as Padding after the
          MetaInfo. The unique Sequence could 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
              anchor="Figure 7" title="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 forming the Padding
      and 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="RFC9343">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>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Adrian Farrel for the comments and
      review of this document.</t>
    </section>
  </middle>

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

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

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

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

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

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

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