IPPM                                                        T. Zhou, Ed.
Internet-Draft                                               G. Fioccola
Intended status: Standards Track                                  Huawei
Expires: 2 March 2023                                        M. Cociglio
                                                          Telecom Italia
                                                                  Y. Liu
                                                            China Mobile
                                                                  S. Lee
                                                                   LG U+
                                                                   W. Li
                                                                  Huawei
                                                          29 August 2022


                   Enhanced Alternate Marking Method
             draft-zhou-ippm-enhanced-alternate-marking-10

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 2 March 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Zhou, Ed., et al.         Expires 2 March 2023                  [Page 1]


Internet-Draft         enhanced-alternate-marking            August 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Data Fields Format  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Alternate Marking [RFC8321] and Multipoint Alternate Marking
   [RFC8889] define the Alternate Marking technique that is a hybrid
   performance measurement method, per [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.

   The IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] 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, SRv6
   AltMark [I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking
   data is carried as a TLV in the Segment Routing Header.

   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.

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

   Some possible enhanced applications MAY be:





Zhou, Ed., et al.         Expires 2 March 2023                  [Page 2]


Internet-Draft         enhanced-alternate-marking            August 2022


   1.  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.

   2.  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.

   3.  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.

1.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Data Fields Format

   The Data Fields format is represented in Figure 1.  An 4-bit
   NH(NextHeader) field is allocated from the Reserved field of IPv6
   AltMark Option [I-D.ietf-6man-ipv6-alt-mark].  It is worth
   highlighting that remaining bits of the former Reserved field
   continue to be reserved.

    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   |
   +---------------------------------------+-+-+-----------+-------+

    Figure 1: Figure 1: Data fields indicator for enhanced capabilities

   The NH (NextHeader) field is used to indicate the extended data
   fields which are used for enhanced capabilities:

      NextHeader value of 0x00 is reserved for backward compatibility.
      It means that there is no extended data field attached.

      NextHeader values of 0x01-0x08 are reserved for private use or for
      experimentation.




Zhou, Ed., et al.         Expires 2 March 2023                  [Page 3]


Internet-Draft         enhanced-alternate-marking            August 2022


      NextHeader value of 0x09 indicates the extended data fields.  The
      format is showed in Figure 2.

    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)                       //
   +-------------------------------+-------------------------------+

      Figure 2: Figure 2: Data fields extension for enhanced alternate
                                  marking

   where:

   *  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 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark].

   *  Flag - A 4-bit flag to indicate the special purpose usage (see
      below).

   *  Len - Length.  It indicates the length of the enhanced alternate
      marking extension in bytes.

   *  R - Reserved for further use.  These bits MUST be set to zero on
      transmission and ignored on receipt.

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

   *  Padding - These bits MUST be set to zero when not being used.

   The Flag is defined in Figure 3 as:

   *  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.

   *  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.




Zhou, Ed., et al.         Expires 2 March 2023                  [Page 4]


Internet-Draft         enhanced-alternate-marking            August 2022


   *  others (shown as R) - Reserved.  MUST be set to zero and ignored
      on receipt.

                                  0 1 2 3
                                 +-------+
                                 |M|R|F|R|
                                 +-------+

                    Figure 3: Figure 3: Flag data field

   The MetaInfo is defined in Figure 4 as a bit map as follows:

                              0 1 2 3 4 5 6 7
                             +---------------+
                             |    MetaInfo   |
                             +---------------+

                  Figure 4: Figure 4: MetaInfo data field

   *  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.

       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)                                 |
      +---------------------------------------------------------------+

                   Figure 5: Figure 5: Timestamp data field

   *  bit 1: indicates the control information with the following data
      format is attached:

       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         |
      +---------------+---------------+-----------+-------------------+





Zhou, Ed., et al.         Expires 2 March 2023                  [Page 5]


Internet-Draft         enhanced-alternate-marking            August 2022


        Figure 6: Figure 6: Control words for backward direction flow
                                  monitoring

      This is used to set up the backward direction flow monitoring.
      Where:

      -  DIP Mask: is the length of the destination IP prefix.

      -  SIP Mask: is the length of the source IP prefix.

      -  Control: indicates more match fields to set up the backward
         direction flow monitoring.

      -  Period: indicates the alternate marking period with the unit of
         second.

   *  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.

       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                             |
      +---------------------------------------------------------------+

                Figure 7: Figure 7: Sequence number data field

   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.

3.  Security Considerations

   IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] 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 [RFC8799].

4.  IANA Considerations

   This document has no request to IANA.

5.  References



Zhou, Ed., et al.         Expires 2 March 2023                  [Page 6]


Internet-Draft         enhanced-alternate-marking            August 2022


5.1.  Normative References

   [I-D.fz-spring-srv6-alt-mark]
              Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing
              Header encapsulation for Alternate Marking Method", Work
              in Progress, Internet-Draft, draft-fz-spring-srv6-alt-
              mark-03, 5 August 2022,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              fz-spring-srv6-alt-mark/>.

   [I-D.ietf-6man-ipv6-alt-mark]
              Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate Marking Method",
              Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
              alt-mark-16, 1 July 2022,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              ietf-6man-ipv6-alt-mark/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

5.2.  Informative References

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC8889]  Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
              "Multipoint Alternate-Marking Method for Passive and
              Hybrid Performance Monitoring", RFC 8889,
              DOI 10.17487/RFC8889, August 2020,
              <https://www.rfc-editor.org/info/rfc8889>.



Zhou, Ed., et al.         Expires 2 March 2023                  [Page 7]


Internet-Draft         enhanced-alternate-marking            August 2022


Authors' Addresses

   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhoutianran@huawei.com


   Giuseppe Fioccola
   Huawei
   Riesstrasse, 25
   80992 Munich
   Germany
   Email: giuseppe.fioccola@huawei.com


   Mauro Cociglio
   Telecom Italia
   Via Reiss Romoli, 274
   10148 Torino
   Italy
   Email: mauro.cociglio@telecomitalia.it


   Yisong Liu
   China Mobile
   Beijing
   China
   Email: liuyisong@chinamobile.com


   Shinyoung Lee
   LG U+
   71, Magokjungang 8-ro, Gangseo-gu
   Seoul
   Republic of Korea
   Email: leesy@lguplus.co.kr


   Weidong Li
   Huawei
   156 Beiqing Rd.
   Beijing
   100095
   China



Zhou, Ed., et al.         Expires 2 March 2023                  [Page 8]


Internet-Draft         enhanced-alternate-marking            August 2022


   Email: poly.li@huawei.com


















































Zhou, Ed., et al.         Expires 2 March 2023                  [Page 9]