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, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . 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, . 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, . 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]