<?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-14"
     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="24" month="November" 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 5-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 0 is reserved for backward compatibility. It
          means that there is no extended data field attached.</t>

          <t>NextHeader values of 1-15 are reserved for private use or for
          experimentation.</t>

          <t>NextHeader value of 16-31 indicates the extended data fields that
          should be defined in IETF. This document specifies the extended data
          fields when the NextHeader is 16. The format is shown 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               |F|  P  | M |  Reserved |
+-------------------------------+-------+-+-----+---+-----------+
|           MetaInfo            |            Padding            |
+-------------------------------+-------------------------------+
]]></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>F - The flag to enable the automatic backward flow monitoring. If
          F=1, it indicates the egress node to setup the backward flow
          monitoring automatically based on 5 tuple of the forward flow.</t>

          <t>P - It indicates period of the alternate marking.<list
              style="symbols">
              <t>000: 1s</t>

              <t>001: 10s</t>

              <t>010: 30s</t>

              <t>011: 60s</t>

              <t>100: 300s</t>
            </list>M - It indicates the measurement mode. <list
              style="symbols">
              <t>00: Reserved;</t>

              <t>01: Edge to edge mode;</t>

              <t>10: Hop by hop mode;</t>

              <t>11: Reserved.</t>
            </list></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 MetaInfo is defined in the following Figure 4 as a bit map:</t>

      <t><list style="hanging">
          <t>bit 0: If set to 1, it indicates a 6 bytes Timestamp that 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 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 3" 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 more detailed control
          information with the following data format that is attached after
          the MetaInfo: <figure anchor="Figure 4"
              title="Control information 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 
+---------------+---------------+-----------+-------------------+
|  DIP Mask     |  SIP Mask     |P|I|O|V|S|T|    Period         |
+---------------+---------------+-----------+-------------------+]]></artwork>
            </figure> This is used to set up the backward direction flow
          monitoring. Where:<list style="symbols">
              <t>DIP Mask: The length of the destination IP prefix used to
              match the flow.</t>

              <t>SIP Mask: The length of the source IP prefix used to match
              the flow.</t>

              <t>P bit: If set to 1, it indicates to match the flow using the
              protocol identifier in the trigger packet. </t>

              <t>I bit: If set to 1, it indicates to match the source port.
              </t>

              <t>O bit: If set to 1, it indicates to match the destination
              port. </t>

              <t>V bit: If set to 1, the egress node will automatically set up
              reverse direction monitoring, and allocate a FlowMonID. </t>

              <t>S bit: If set to 1, it indicates to match the DSCP.</t>

              <t>T bit: Used to control the scope of tunnel measurement. T=1
              means meausre between Network-to-Network Interfaces (i.e., NNI
              to NNI). T=0 means measure between User-to-Network Interfaces
              (i.e., UNI to UNI).</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 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 5"
              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 3, Figure 4 and Figure 5 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>
