IPPM T. Zhou, Ed. Internet-Draft G. Fioccola Intended status: Standards Track Huawei Expires: September 1, 2022 Y. Liu China Mobile M. Cociglio Telecom Italia S. Lee LG U+ W. Li Huawei February 28, 2022 Enhanced Alternate Marking Method draft-zhou-ippm-enhanced-alternate-marking-09 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 September 1, 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Zhou, Ed., et al. Expires September 1, 2022 [Page 1] Internet-Draft enhanced-alternate-marking February 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 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Data Fields Format . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 September 1, 2022 [Page 2] Internet-Draft enhanced-alternate-marking February 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. A 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: 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 September 1, 2022 [Page 3] Internet-Draft enhanced-alternate-marking February 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: Data fields extension for enhanced alternate marking where: o 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 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark]. o Flag - A 4-bit flag to indicate the special purpose usage (see below). o Len - Length. It indicates the length of the enhanced alternate marking extension in bytes. o R - Reserved for further use. These bits MUST be set to zero on transmission and ignored on receipt. o MetaInfo - A 16-bit Bitmap to indicate more meta data attached for the enhanced function (see below). o Padding - These bits MUST be set to zero when not being used. The Flag is defined in Figure 3 as: o 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. o 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. Zhou, Ed., et al. Expires September 1, 2022 [Page 4] Internet-Draft enhanced-alternate-marking February 2022 o others (shown as R) - Reserved. These bits MUST be set to zero and ignored on receipt. 0 1 2 3 +-------+ |M|R|F|R| +-------+ Figure 3: Flag data field The MetaInfo is defined in the following Figure 4 as a bit map: 0 1 2 3 4 5 6 7 +---------------+ | MetaInfo | +---------------+ Figure 4: MetaInfo data field o bit 0: 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. 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: Timestamp data field o bit 1: it indicates the control information with the following data format that is attached as Padding 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 +---------------+---------------+-----------+-------------------+ | DIP Mask | SIP Mask | Control | Period | +---------------+---------------+-----------+-------------------+ Figure 6: Control words for backward direction flow monitoring Zhou, Ed., et al. Expires September 1, 2022 [Page 5] Internet-Draft enhanced-alternate-marking February 2022 This is used to set up the backward direction flow monitoring. Where: * DIP Mask: it is the length of the destination IP prefix. * SIP Mask: it is the length of the source IP prefix. * Control: it indicates more match fields to set up the backward direction flow monitoring. * Period: it indicates the alternate marking period with the unit of second. o bit 2: 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. 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: Sequence number data field 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. 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. Zhou, Ed., et al. Expires September 1, 2022 [Page 6] Internet-Draft enhanced-alternate-marking February 2022 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-02 (work in progress), February 2022. [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, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [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, . Zhou, Ed., et al. Expires September 1, 2022 [Page 7] Internet-Draft enhanced-alternate-marking February 2022 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 Mauro Cociglio Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: mauro.cociglio@telecomitalia.it Shinyoung Lee LG U+ 71, Magokjungang 8-ro, Gangseo-gu Seoul Republic of Korea Email: leesy@lguplus.co.kr Zhou, Ed., et al. Expires September 1, 2022 [Page 8] Internet-Draft enhanced-alternate-marking February 2022 Weidong Li Huawei 156 Beiqing Rd. Beijing 100095 China Email: poly.li@huawei.com Zhou, Ed., et al. Expires September 1, 2022 [Page 9]