6MAN Working Group G. Fioccola Internet-Draft T. Zhou Intended status: Standards Track Huawei Expires: January 23, 2020 M. Cociglio Telecom Italia July 22, 2019 IPv6 Application of the Alternate Marking Method draft-fz-6man-ipv6-alt-mark-00 Abstract This document describes how the alternate marking method in [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] can be used as the passive performance measurement method in an IPv6 domain and reports implementation considerations. It proposes how to define a new encapsulation header to encode alternate marking technique. 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 23, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Fioccola, et al. Expires January 23, 2020 [Page 1] Internet-Draft IPv6 with AMM July 2019 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. IPv6 application of Alternate Marking . . . . . . . . . . . . 3 3. IPv6 Extension Headers as Marking Field . . . . . . . . . . . 3 3.1. Definition of the AltMark Extension Header . . . . . . . 3 3.1.1. Data Fields Format . . . . . . . . . . . . . . . . . 4 3.1.2. AltMark: Destination Option and Hop-by-Hop Option . . 5 4. Alternate Marking Method Operation . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe passive performance measurement method, which can be used to measure packet loss, latency and jitter on live traffic. Since this method is based on marking consecutive batches of packets, the method often referred as Alternate Marking Method. This document defines how the alternate marking method can be used to measure packet loss and delay metrics of IPv6 and SRv6. The IPv6 Header Format defined in [RFC8200] introduces the format of the IPv6 addresses, the Extension Headers in the base IPv6 Header and the availability of a 20-bit flow label, that can be considered for the application of the Alternate Marking methodology. In this respect, [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible implementation options for the application of the alternate marking method in an IPv6 domain. [I-D.zhou-ippm-enhanced-alternate-marking] defines the data field for the alternate marking in order to generalize its application. More Fioccola, et al. Expires January 23, 2020 [Page 2] Internet-Draft IPv6 with AMM July 2019 information can be considered within the alternate marking field to facilitate the efficiency and ease the deployment. For the overall application of the methodology [I-D.song-ippm-postcard-based-telemetry] introduces a new approach named Postcard-Based Telemetry (PBT). It includes alternative ways which can collect the same data of In-band OAM ([I-D.ietf-ippm-ioam-data]) but avoid or mitigate the In-band OAM issues. There are two variations of PBT: PBT-M and PBT-I. PBT-M marks the user packets (set one bit) or configure the flow filter to invoke the data collection. At each PBT-aware node, if the mark is detected, a postcard is generated and sent to a collector. Instead, PBT-I can be seen as a trade-off between IOAM and PBT-M. It needs to add a fixed length instruction header to user packets for OAM data collection, called Per-Hop Postcard (PHP), but, unlike IOAM, data are exported through dedicated postcards. Both PBT-M and PBT-I variations can allow the implementation of [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] and this is also discussed in [I-D.zhou-ippm-enhanced-alternate-marking]. 2. IPv6 application of Alternate Marking The application of the alternate marking requires a marking field. Several alternatives have been analysed in [I-D.fioccola-v6ops-ipv6-alt-mark] (Extension Header, IPv6 Address, Flow Label). Anyway the best choice would be the use of an Extension Header (EH). 3. IPv6 Extension Headers as Marking Field A new type of EH can be defined for this scope. In this way there is enough space to implement and optimize the deployment of the Alternate Marking method. A possibility can be to use a Destination or a Hop-By-Hop(HBH) Extension Header(EH). The assumption is that an EH with an alternate marking measurement option can be defined. The router processing can be easily optimized to handle this use case. 3.1. Definition of the AltMark Extension Header The desired choice is to define a new Extension Header. [I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data fields for the alternate marking method and inspired the layout. Fioccola, et al. Expires January 23, 2020 [Page 3] Internet-Draft IPv6 with AMM July 2019 3.1.1. Data Fields Format The following figure shows the data fields format for enhanced alternate marking. This data is expected to be encapsulated to specific transports, in this case the IPv6 Option Header named AltMark. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowID |L|D|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Option Type - 8 bit identifier of the type of option. It needs to be allocated. o Opt Data Len - 8 bit unsigned integer. Length of the Option Data field of this option, in octets. o FlowID - 20 bits unsigned integer. Flow identifier field is to uniquely identify a monitored flow within the measurement domain. The field is set at the ingress node. The FlowID can be uniformly assigned by the central controller or algorithmically generated by the ingress node. The latter approach cannot guarantee the uniqueness of FlowID, yet the conflict probability is small due to the large FlowID space. o L - Loss flag as defined in [RFC8321]; o D - Delay flag as defined in [RFC8321]; o M - Marking bit as defined in PBT-M [I-D.song-ippm-postcard-based-telemetry]; o Reserved - is reserved for further use. These bits MUST be set to zero. Note that PBT-I [I-D.song-ippm-postcard-based-telemetry] can also be used and the marking fields, in this case, are included in the PHP Header Format as described in [I-D.song-ippm-postcard-based-telemetry]. Fioccola, et al. Expires January 23, 2020 [Page 4] Internet-Draft IPv6 with AMM July 2019 3.1.2. AltMark: Destination Option and Hop-by-Hop Option Using a new EH assumes that all routers in the domain support this type of headers, but, beyond backward compatibility, the new AltMark Option Layout seems the best way to implement the Alternate Marking method. It is important to highlight that the Option Layout can be used both as Destination Option and as Hop-By-Hop Option depending on the Use Cases. In general, it is needed to perform end-to-end or hop-by-hop measurements, and the alternate marking methodology in [RFC8321] allows, by definition, both end-to-end and hop-by-hop performance measurements. 4. Alternate Marking Method Operation [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe in detail the methodology. 5. Security Considerations tbc 6. IANA Considerations The option type should be assigned in IANA's "Destination Options and Hop-by-Hop Options" registry. 7. Acknowledgements tbc 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.fioccola-v6ops-ipv6-alt-mark] Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 Performance Measurement with Alternate Marking Method", draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), June 2018. Fioccola, et al. Expires January 23, 2020 [Page 5] Internet-Draft IPv6 with AMM July 2019 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- data-06 (work in progress), July 2019. [I-D.ietf-ippm-multipoint-alt-mark] Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, "Multipoint Alternate Marking method for passive and hybrid performance monitoring", draft-ietf-ippm- multipoint-alt-mark-02 (work in progress), July 2019. [I-D.song-ippm-postcard-based-telemetry] Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path Flow Data Telemetry", draft-song- ippm-postcard-based-telemetry-04 (work in progress), June 2019. [I-D.zhou-ippm-enhanced-alternate-marking] Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and Z. Li, "Enhanced Alternate Marking Method", draft-zhou- ippm-enhanced-alternate-marking-03 (work in progress), July 2019. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [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, . Authors' Addresses Giuseppe Fioccola Huawei Riesstrasse, 25 Munich 80992 Germany Email: giuseppe.fioccola@huawei.com Fioccola, et al. Expires January 23, 2020 [Page 6] Internet-Draft IPv6 with AMM July 2019 Tianran Zhou Huawei 156 Beiqing Rd. Beijing 100095 China Email: zhoutianran@huawei.com Mauro Cociglio Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: mauro.cociglio@telecomitalia.it Fioccola, et al. Expires January 23, 2020 [Page 7]