IPPM T. Zhou, Ed. Internet-Draft G. Fioccola Intended status: Standards Track Huawei Expires: January 12, 2022 Y. Liu China Mobile S. Lee LG U+ M. Cociglio Telecom Italia W. Li Huawei July 11, 2021 Enhanced Alternate Marking Method draft-zhou-ippm-enhanced-alternate-marking-07 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 January 12, 2022. Zhou, Ed., et al. Expires January 12, 2022 [Page 1] Internet-Draft enhanced-alternate-marking July 2021 Copyright Notice Copyright (c) 2021 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. Enhanced Alternate Marking capabilities . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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. Zhou, Ed., et al. Expires January 12, 2022 [Page 2] Internet-Draft enhanced-alternate-marking July 2021 It is worth mentioning that the enhanced capabilities are intended for further use and are optional. 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 | +---------------------------------------+-+-+---+---------------+ The NextHeader field is used to indicate the extended data fields which are used for enhanced capabilities. When the NextHeader is 0, 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 9. 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 | R | +---------------------------------------------------------------+ 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. o R - Reserved for further use. These bits MUST be set to zero. Zhou, Ed., et al. Expires January 12, 2022 [Page 3] Internet-Draft enhanced-alternate-marking July 2021 The Flag is defined as follows: o bit 1 - Flow direction identification, F bit. F=1, indicates that the flow direction is forward. F=0, indicates the flow direction is backward. o bit 3 - Measurement mode, M bit. M=1, indicates that it is for hop-by-hop monitoring. M=0, indicates that it is for end-to-end monitoring. o others - Reserved. 3. Enhanced Alternate Marking capabilities The extended data fields presented in the previous section can be used for several uses. Some possible applications can be: 1. shortest marking periods of single marking method for thicker packet loss measurements. 2. more dense delay measurements than double marking method (down to each packet). 3. increase the entropy of flow monitoring identifier by extending the size of FlowMonID. 4. automatically set up the backward direction flow monitoring. 5. and so on. 4. 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]. 5. IANA Considerations This document has no request to IANA. 6. References Zhou, Ed., et al. Expires January 12, 2022 [Page 4] Internet-Draft enhanced-alternate-marking July 2021 6.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-00 (work in progress), January 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-04 (work in progress), March 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, . 6.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, . Authors' Addresses Zhou, Ed., et al. Expires January 12, 2022 [Page 5] Internet-Draft enhanced-alternate-marking July 2021 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 Mauro Cociglio Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: mauro.cociglio@telecomitalia.it Zhou, Ed., et al. Expires January 12, 2022 [Page 6] Internet-Draft enhanced-alternate-marking July 2021 Weidong Li Huawei 156 Beiqing Rd. Beijing 100095 China Email: poly.li@huawei.com Zhou, Ed., et al. Expires January 12, 2022 [Page 7]