In Situ OAM Profile for the Linux Kernel Implementation
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Authors||Tal Mizrahi , Justin Iurman , Frank Brockners|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group T. Mizrahi Internet-Draft Huawei Intended status: Informational J. Iurman Expires: April 3, 2022 ULiege F. Brockners Cisco September 30, 2021 In Situ OAM Profile for the Linux Kernel Implementation draft-mizrahi-ippm-ioam-linux-profile-00 Abstract In Situ Operations, Administration and Maintenance (IOAM) is used for monitoring network performance and for detecting traffic bottlenecks and anomalies. This document defines an IOAM profile that is used in the Linux kernel implementation, starting from the Linux 5.15 kernel. 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 April 3, 2022. 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 Mizrahi, et al. Expires April 3, 2022 [Page 1] Internet-Draft IOAM Linux Profile September 2021 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Linux IOAM Profile . . . . . . . . . . . . . . . . . . . 2 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2. IOAM Version . . . . . . . . . . . . . . . . . . . . . . 3 2.3. IOAM Options . . . . . . . . . . . . . . . . . . . . . . 3 2.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 3 2.5. IOAM Supported Data Fields . . . . . . . . . . . . . . . 4 2.6. Trace Option-Type Flags . . . . . . . . . . . . . . . . . 4 2.7. Timestamp Format . . . . . . . . . . . . . . . . . . . . 4 2.8. Profile Coexistence . . . . . . . . . . . . . . . . . . . 4 2.9. Validity . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Notes about the IOAM Support in Linux . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the network by incorporating IOAM data fields into in-flight data packets. An IOAM profile [I-D.mizrahi-ippm-ioam-profile] defines a use case or a set of use cases for IOAM, and an associated set of rules that restrict the scope and features of the IOAM specification, thereby limiting it to a subset of the full functionality. This document introduces a profile of IOAM that is used in the Linux kernel implementation. The profile is intended to formally specify the subset of features that are in scope, and to enable other implementations to interoperate with the Linux implementation. 2. The Linux IOAM Profile 2.1. Use Cases The Linux kernel implementation enables the functionality of any of the following nodes: o IOAM encapsulating node o IOAM transit node Mizrahi, et al. Expires April 3, 2022 [Page 2] Internet-Draft IOAM Linux Profile September 2021 o IOAM decapsulating node One possible use case is a set of Linux-based hosts that function as IOAM encapsulating and decapsulating nodes, interconnected by IOAM transit nodes that are not necessarily Linux-based. Thus, Linux- based implementations are expected to interoperate with other implementations that comply to this profile. Another possible use case is a homogenous setting in which all IOAM nodes are Linux-based. 2.2. IOAM Version The current profile is based on [I-D.ietf-ippm-ioam-data-14], which is a work-in-progress version of IOAM. 2.3. IOAM Options The current profile uses the Pre-allocated Trace Option-Type. It is assumed that one IOAM option is used in an IOAM encapsulated packet. 2.4. Encapsulation The IOAM encapsulation uses an IPv6 Extension Header. This extension header is used for the IOAM Pre-allocated Trace Option-Type, as defined in [I-D.ietf-ippm-ioam-ipv6-options-06], which is a work-in- progress version of the IPv6 IOAM option. The IPv6 Extension Header is a Hop-by-Hop Options header, that contains the IOAM Trace Option-Type. The Hop-by-Hop Options header can include one or more options, such that one of these options is the IOAM Pre-allocated Trace Option-Type. Figure 1 illustrates the format of this Hop-by-Hop Options header when the IOAM Pre-allocated Trace Option-Type is the only Hop-by-Hop option. If more options are present the format will change accordingly. As illustrated in Figure 1, the first 2 octets are the Hop-by-Hop Options header [RFC8200], followed by a 2 octet Padding field. The following 4 octets are the IOAM IPv6 option header [I-D.ietf-ippm-ioam-ipv6-options-06]. The IOAM Option includes the 8 octet Pre-allocated Trace Option-Type header [I-D.ietf-ippm-ioam-data-14], followed by the Option Data. Mizrahi, et al. Expires April 3, 2022 [Page 3] Internet-Draft IOAM Linux Profile September 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | Option Type | Opt Data Len | Reserved | IOAM Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | Namespace-ID |NodeLen | Flags | RemainingLen| O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A | IOAM-Trace-Type | Reserved | M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | | . . . . . Option Data . O . . P . . T . . I . . O . . N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ Figure 1: IPv6 IOAM Extension Header Format 2.5. IOAM Supported Data Fields The current profile supports all the data field types that are defined in [I-D.ietf-ippm-ioam-data-14] for the Pre-allocated Trace Option-Type, except for the Checksum Complement field, which is not required in this profile, since the IOAM Trace Option is encapsulated directly in an IPv6 Extension Header, without any additional layers that use a checksum. 2.6. Trace Option-Type Flags This profile only uses the Overflow flag. 2.7. Timestamp Format This profile uses the POSIX timestamp format. 2.8. Profile Coexistence It is assumed that the current profile is used in a confined administrative domain in which no other IOAM profiles are used. Therefore, it is assumed that the current profile does not coexist with other profiles. Mizrahi, et al. Expires April 3, 2022 [Page 4] Internet-Draft IOAM Linux Profile September 2021 2.9. Validity An IOAM transit/decapsulating node that receives a packet with IOAM options that do not comply to the current profile is expected to forward/decapsulate the packet without IOAM processing, if it is able to do so. If a decapsulating node is not able to decapsulate an IOAM option that is not compliant to the current profile, the packet is discarded. 3. Notes about the IOAM Support in Linux The current Linux implementation supports all the data field types defined in [I-D.ietf-ippm-ioam-data-14] for the Pre-allocated Trace Option-Type. Specifically, the Linux implementation does not update the transit delay, the queue depth, the checksum complement and the buffer occupancy. These four data field types are passively supported, meaning the Linux implementation can add the Pre-allocated Trace Option-Type including these fields, but cannot populate them with system information. They are populated with empty values and, therefore, interoperability is possible with other IOAM nodes that support these fields. The following table summarizes the data field type support in the Linux implementation. Data field type Status Hop_Lim and node_id (short format) Supported Ingress_if_id and egress_if_id (short format) Supported Timestamp seconds Supported Timestamp fraction Supported Transit delay Passive support Namespace specific data (short format) Supported Queue depth Passive support Checksum complement Passive support Hop_Lim and node_id (wide format) Supported Ingress_if_id and egress_if_id (wide format) Supported Namespace specific data (wide format) Supported Buffer occupancy Passive support Opaque State Snapshot Supported Both the Opaque State Snapshot and the Namespace specific data are supported in the Linux implementation by incorporating configurable values into these fields. Notably, Linux-based IOAM nodes can interoperate with other nodes that use the Opaque State Snapshot and/ or the Namespace specific data in a more flexible way. Mizrahi, et al. Expires April 3, 2022 [Page 5] Internet-Draft IOAM Linux Profile September 2021 4. IANA Considerations This document does not include any requests from IANA. 5. Security Considerations The security considerations of IOAM profiles are discussed in [I-D.mizrahi-ippm-ioam-profile]. The current document does not present any new security considerations. 6. Normative References [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in progress), June 2021. [I-D.ietf-ippm-ioam-data-14] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in progress), June 2021. [I-D.ietf-ippm-ioam-ipv6-options-06] Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam-ipv6-options-06 (work in progress), July 2021. [I-D.mizrahi-ippm-ioam-profile] Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., Zhou, T., and J. Lemon, "In Situ OAM Profiles", draft-mizrahi-ippm- ioam-profile-05 (work in progress), August 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>. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. Mizrahi, et al. Expires April 3, 2022 [Page 6] Internet-Draft IOAM Linux Profile September 2021 Authors' Addresses Tal Mizrahi Huawei 8-2 Matam Haifa Israel Email: firstname.lastname@example.org Justin Iurman Universite de Liege 10, Allee de la decouverte (B28) Sart-Tilman, LIEGE 4000 Belgium Email: email@example.com Frank Brockners Cisco Systems, Inc. Hansaallee 249, 3rd Floor DUESSELDORF, NORDRHEIN-WESTFALEN 40549 Germany Email: firstname.lastname@example.org Mizrahi, et al. Expires April 3, 2022 [Page 7]