Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Tianran Zhou , Giuseppe Fioccola , Yisong Liu , Shinyoung Lee , Mauro Cociglio , Weidong Li
Last updated 2022-01-04 (Latest revision 2021-07-11)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-zhou-ippm-enhanced-alternate-marking-08
IPPM                                                        T. Zhou, Ed.
Internet-Draft                                               G. Fioccola
Intended status: Standards Track                                  Huawei
Expires: July 8, 2022                                             Y. Liu
                                                            China Mobile
                                                                  S. Lee
                                                                   LG U+
                                                             M. Cociglio
                                                          Telecom Italia
                                                                   W. Li
                                                                  Huawei
                                                        January 04, 2022

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

Abstract

   This document extends the IPv6 Alternate Marking Option, defined in
   IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark], to provide the
   enhanced capabilities and allow advanced functionalities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 July 8, 2022.

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 1]
Internet-Draft         enhanced-alternate-marking           January 2022

Copyright Notice

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

   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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

1.  Introduction

   The Alternate Marking [RFC8321] and Multipoint Alternate Marking
   [RFC8889] define the Alternate Marking technique that is an 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.

   IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] applies the
   Alternate Marking Method to the IPv6 protocol, and defines Extension
   Header Option to encode Alternate Marking Method for both Hop-by-Hop
   Options Header and Destination Options Header.  Similarly, SRv6
   AltMark [I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking
   data is carried as SRH TLV.

   While the AltMark Option implements the basic alternate marking
   method, this document defines the extended data fields for the
   AltMark Option and provides the enhanced capabilities.

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

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 2]
Internet-Draft         enhanced-alternate-marking           January 2022

2.  Data Fields Format

   The Data Fields format is represented in the next figure.  An 8 bits
   NextHeader field is allocated from the Reserved field of IPv6 AltMark
   Option [I-D.ietf-6man-ipv6-alt-mark].

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

          Fig. 1: Data fields indicator for enhanced capabilities

   The NextHeader field is used to indicate the extended data fields
   which are used for enhanced capabilities.  When the NextHeader is
   0x00, there is no extended data field attached.  Value 1-8 are
   reserved for private use.

   The following figure shows the extended data fields format when the
   NextHeader value is 0x09.

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

       Fig. 2: Data fields extension for enhanced alternate marking

   where:

   o  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].

   o  Flag - A 4 bits flag to indicate the special purpose usage.

   o  Len - Length.  It indicates the length of extension headers.

   o  MetaInfo - A 16 bits Bitmap to indicate more meta data attached
      for the enhanced function.

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 3]
Internet-Draft         enhanced-alternate-marking           January 2022

   o  R - Reserved for further use.  These bits MUST be set to zero.

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

   The Flag is defined as follows:

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

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

   o  others - Reserved.

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

                          Fig. 3: Flag data field

   The MetaInfo is defined as a bit map as follows:

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

                        Fig. 4: MetaInfo data field

   o  bit 0: indicates a 6 bytes Timestamp is attached after the
      MetaInfo.  Timestamp(s) stands for the second part.  It will
      overwrite the Padding after MetaInfo.  Timestamp(ns) stands for
      the subsecond part 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.

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 4]
Internet-Draft         enhanced-alternate-marking           January 2022

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

                       Fig. 5: Timestamp data field

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

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

   o  bit 2: indicates a 4 bytes Sequence number with the following data
      format is attached after the MetaInfo

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

                    Fig. 7: Sequence number data field

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 5]
Internet-Draft         enhanced-alternate-marking           January 2022

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 be applied in a
   specific limited domain, as also mentioned in [RFC8799].

4.  IANA Considerations

   This document has no request to IANA.

5.  References

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", draft-
              fz-spring-srv6-alt-mark-01 (work in progress), July 2021.

   [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",
              draft-ietf-6man-ipv6-alt-mark-12 (work in progress),
              October 2021.

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

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

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 6]
Internet-Draft         enhanced-alternate-marking           January 2022

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

Authors' Addresses

   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhoutianran@huawei.com

   Giuseppe Fioccola
   Huawei
   Riesstrasse, 25
   Munich  80992
   Germany

   Email: giuseppe.fioccola@huawei.com

   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

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 7]
Internet-Draft         enhanced-alternate-marking           January 2022

   Mauro Cociglio
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148
   Italy

   Email: mauro.cociglio@telecomitalia.it

   Weidong Li
   Huawei
   156 Beiqing Rd.
   Beijing  100095
   China

   Email: poly.li@huawei.com

Zhou, Ed., et al.         Expires July 8, 2022                  [Page 8]