Aggregation Trace Option for In-situ Operations, Administration, and Maintenance (IOAM)
draft-cxx-ippm-ioamaggr-01

IPPM                                                            A. Clemm
Internet-Draft                                                          
Intended status: Standards Track                              L. Metzger
Expires: 27 October 2024               Ostschweizer Fachhochschule - OST
                                                           25 April 2024

  Aggregation Trace Option for In-situ Operations, Administration, and
                           Maintenance (IOAM)
                       draft-cxx-ippm-ioamaggr-01

Abstract

   The purpose of this memo is to describe a new option type for In-Situ
   Operations, Administration, and Maintenance (IOAM).  This option type
   allows to aggregate IOAM data along a network path.  Aggregates
   include functions such as the sum, average, minimum, or maximum of a
   given data parameter.

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 27 October 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Clemm & Metzger          Expires 27 October 2024                [Page 1]
Internet-Draft                  ioam-aggr                     April 2024

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IOAM Aggregation Option-Type  . . . . . . . . . . . . . . . .   4
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This memo proposes a new option type for In-Situ Operations,
   Administration, and Maintenance (IOAM) [RFC9197].  The IOAM Aggregate
   option type allows to aggregate IOAM data along a network path.
   Aggregates include functions such as the sum, average, minimum, or
   maximum of a given data parameter.

   Many applications interested in telemetry data across a path are not
   so much interested in each individual node's telemetry, but an
   aggregate to paint a more holistic picture.  An example of an
   aggregate could be a sum (for example, the sum of packet dwell times
   experienced across a path), an average (for example, the average
   dwell time experienced across a path), or a minimum or maximum (for
   example, of the dwell time experienced on any hop across the path,
   along with the node ID where the extreme was experienced).  Other
   applications include sustainable networking, where (for example) the
   carbon-intensity of a path as a whole needs to be determined as an
   input to applications that attempt to minimize pollution attributable
   to specific networking traffic.

   The aggregation option type proposed in this memo addresses the needs
   of those applications.  Rather than collecting individual IOAM data
   parameters at each node and exporting them for further processing,

Clemm & Metzger          Expires 27 October 2024                [Page 2]
Internet-Draft                  ioam-aggr                     April 2024

   IOAM Aggregate allows to preprocess telemetry data into an aggregate
   as a packet traverses a path.  Aggregating parameters along the path,
   instead of merely collecting them, offers the following advantages:

   *  It keeps the packet size constant.  This avoids problems such as
      the possibility of packets exceeding their MTU and need for
      fragmentation and reassembly in case of longer data paths, or
      deteriorating packet delays as packets grow in size along a path.

   *  It reduces the volume of data to be exported.

   *  It obviates the need to correlate data exported from individual
      nodes as belonging to the same flow, when compared with processing
      of postcard telemetry data [RFC9326].

   *  It significantly reduces the amount of processing that needs to be
      done by applications, simplifying their development and
      deployment.

   *  It enables greater network intelligence, such as taking actions on
      aggregates when certain thresholds are exceeded.

   Aggregating parameters does require a small amount of processing
   (such as, an arithmetic operations to add to a sum, or a comparison
   operation to determine a minimum) at each hop, requiring some
   additional processing cycles.  This is a small tradeoff to be aware
   of when choosing this option.  We believe that this tradeoff will be
   acceptable in many implementations and deployment scenarios.

2.  Background

   [RFC9197] defines the scope of IOAM as well as the different IOAM
   nodes.  The following section reiterates those roles and explains how
   they are applied in the context of IOAM Aggregation.

   IOAM is focused on "limited domains", as defined in [RFC8799].  IOAM
   is not targeted for a deployment on the global Internet, which would
   incur additional considerations such as the crossing of Trust
   Boundaries, authentication of IOAM data, or the desire to obfuscate
   domain internals to outside parties.  The part of the network that
   employs IOAM is referred to as the "IOAM-Domain".

   An IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM
   decapsulating nodes", and "IOAM transit nodes", as depicted in
   Figure 1.

Clemm & Metzger          Expires 27 October 2024                [Page 3]
Internet-Draft                  ioam-aggr                     April 2024

                                                         Export of
                                                     IOAM data (opt.)
                                                             ^
                                                             |
   User     +--------+     +--------+     +--------+     +---+----+
   packets  |Encapsu-|     | Transit|     | Transit|     |Decapsu-|
   -------->|lating  |====>| Node   |====>| Node   |====>|lating  |-->
            |Node    |     | A      |     | B      |     |Node    |
            +--------+     +--------+     +--------+     +--------+

                       Figure 1: Roles of IOAM nodes

   The role of these nodes is as follows:

   *  The Encapsulating Node originates the IOAM aggregation.  It adds
      the IOAM Aggregation Option to the packet for which telemetry data
      is to be aggregated across the path and populates the fields with
      their initial values.

   *  The Transit Node is an IOAM-enabled node that aggregates the value
      of its own telemetry with the aggregate in the packet, updating
      the aggregation data as needed.

   *  The Decapsulating Node terminates the IOAM aggregation.  It
      aggregates the value of its own telemetry with the aggregate in
      the packet and updates the aggregation data as needed.  It
      subsequently exports the aggregated data, specifically, including
      the value of the aggregate itself as well as auxiliary data as
      applicable (e.g. node ID for min, max, and in case of errors).

3.  IOAM Aggregation Option-Type

3.1.  Overview

   This section defines the data fields for the IOAM Aggregation Option
   Type format.  Like other IOAM Aggregation Option Types, these data
   fields can be mapped into a number of transport protocols [RFC9378].
   For example, a transport over IPv6 [RFC8200] has been defined in
   [RFC9486].

   The format of the IOAM Aggregation Option Type data fields is
   depicted in Figure 2.

Clemm & Metzger          Expires 27 October 2024                [Page 4]
Internet-Draft                  ioam-aggr                     April 2024

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Namespace-ID           | Flags |       Reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               IOAM Data Param                 |  Aggregator   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Aggregate                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Auxil-data Node-ID                |   Hop Count    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: IOAM Aggregation Option Type Format

   The total length of the IOAM Aggregation Option Type data fields is
   fixed at 16 octets (word-aligned).  These 16 octets hold header
   information as well as aggregation data in the following fields:

   *  Namespace-ID: 16-bit identifier of an IOAM-Namespace, as defined
      in [RFC9197].  The Namespace-ID is populated by the encapsulating
      node and MUST NOT be changed by any of the intermediate nodes.
      The Namespace-ID value of 0x0000 is defined as the "Default-
      Namespace-ID" and MUST be known to all the nodes implementing
      IOAM.  For any other Namespace-ID value that does not match any
      Namespace-ID the node is configured to operate on, the node MUST
      NOT change the contents of the IOAM-Data-Fields except for the
      Namespace Flag (see below).

   *  Flags: 4-bit field to indicate errors that were encountered when
      attempting to process the IOAM Aggregation Option along the path.
      Once a flag is set, no further aggregation occurs along the path.
      An intermediate node that encounters an error during processing of
      the IOAM Aggregation that prevents it from updating the aggregate
      as requested MUST set the corresponding flag to 1.  In order to
      facilitate troubleshooting, it also MUST set the value of the
      Auxil-data Node-ID field to its own Node-ID.  The encapsulating
      node MUST set the value of Flags to zero upon transmission.  When
      an intermediate node encounters receives a packet in which any of
      the Flags are non-zero, the node MUST NOT perform further IOAM
      operations on that packet; instead, the IOAM data MUST be
      forwarded as-is unchanged.  The following flags are defined:

      -  Flag 1: Aggregator not supported

      -  Flag 2: Unsupported IOAM data parameter

      -  Flag 3: Unsupported Namespace

Clemm & Metzger          Expires 27 October 2024                [Page 5]
Internet-Draft                  ioam-aggr                     April 2024

      -  Flag 4: Any other error

   *  Reserved: An IOAM encapsulating node MUST set the value to zero
      upon transmission.  IOAM transit nodes MUST ignore the received
      value.

   *  IOAM Data Param: This field identifies the data parameter that is
      to be aggregated across the nodes.  It MUST be set by the IOAM
      encapsulating node.  IOAM transit nodes MUST NOT change it.
      Contrary to IOAM Trace-Type in the pre-allocated and incremental
      trace option types, only a single parameter is aggregated at a
      time.  Accordingly, the data parameter to be aggregated is not
      identified by a a particular bit, but by a value.

   *  Aggregator: This 8-bit field identifies the aggregation function
      that is to be applied.  Its value MUST be set by the IOAM
      encapsulating node.  IOAM transit nodes MUST not change it.  The
      following aggregators are defined:

      -  Sum (value: 0b1)

      -  Min (value: 0b10)

      -  Max (value: 0b100)

      -  Average (value: 0b1000)

   *  Aggregate: This 32-bit field contains the aggregated value.  Its
      value is initialized by the encapsulating node,in general by
      simply recording the value of its data parameter that is to be
      aggregated.  The field is updated by each subsequent node pre the
      requested aggregation, including IOAM transit nodes as well as the
      IOAM decapsulating node (prior to performing decapsulation).

   *  Auxil-data Node-ID: This 24-bit field contains a Node-ID.  It MUST
      be set by the encapsulating node to its own Node ID.  Subsequent
      nodes (IOAM transit nodes, as well as the IOAM decapsulating node
      prior to performing decapsulation) MUST update the value to their
      own Node-ID IF AND ONLY IF one of the following conditions hold,
      otherwise they MUST NOT change its value:

      -  When a flag is set by the node (i.e., the first time any type
         of error is encounted along the path)

Clemm & Metzger          Expires 27 October 2024                [Page 6]
Internet-Draft                  ioam-aggr                     April 2024

      -  When the aggregator is one of Min or Max, and a new minimum
         respectively maximum is encountered.  The value of the Auxil-
         data Node-ID field is hence used to record where the minimum
         respectively maximum value was first encountered.  (When a node
         matches an existing minimum or maximum but does not beat it,
         the Node-ID is not updated.)

   *  Hop Count.  This 8-bit fields contains a hop count to record the
      number of nodes along the path that successfully processed the
      IOAM Aggregation.  The encapsulating node MUST set the value to 1,
      and each subsequent node (transit nodes, as well as the
      decapsulating node prior to performing decapsulation) MUST
      increment its value by 1.  If the Hop Count at a node exceeds 255,
      that node MUST set the Hop Count to 0 and set Flag 4 ("any other
      error") to prevent further processing of the IOAM Aggregation.

3.2.  Discussion

   This section explains some of the design choices and points out items
   that may be subjected to further discussion.

   *  Single versus multiple parameters.  The Aggregation Option Type
      allows to only aggregate one data parameter at a time.  This
      allows to keep the format of the data structure simple and of
      fixed size.  This facilitates processing.  It also limits the
      number of processing cycles that need to be spent for aggregation
      at each node.  An application seeking to perform multiple types of
      aggregation at a time will need to apply different types of
      aggregation for different packets.

   *  IOAM data parameter identification.  Unlike other IOAM Option
      Types, data parameters are not represented by a bit position in a
      field but by a 24-bit identifier.  This allows to support a
      greater number of parameters.  In order to facilitate
      compatibility, initially only identifiers SHOULD be used that
      utilize bits 12 through 22, with other bits set to 0.  The
      assignment of IOAM data parameter identifiers is at this point up
      to the network operator, with IOAM data parameters being specific
      to an IOAM name space.  It is conceivable that a global namespace
      and a corresponding IANA registry for IOAM data parameters would
      be introduced at a later point in time.

   *  Average aggregator.  An average can be easily derived from
      dividing a sum obtained across all nodes by the hopcount.
      Avoiding division operations along the path can save considerable
      processing cycles.  It is FFS if the average aggregator is really
      required.

Clemm & Metzger          Expires 27 October 2024                [Page 7]
Internet-Draft                  ioam-aggr                     April 2024

   *  Simultaneous use with other IOAM Option Types.  There are use
      cases conceivable that would benefit from also adding a trace of
      which nodes were actually traversed on the path.  The possibility
      to do so is already provided with other IOAM Option Types and does
      not need to be added here.  In order to use multiple IOAM Option
      Types simultaneously, applications can use one of several
      alternatives.  In one alternative, multiple IOAM Option Types with
      their corresponding data structures are simultaneously used in the
      same packet.  In another alternative, different packets of the
      same flow are each send with a different IOAM Option Type, a form
      of sampling which however provides no absolute guarantees of path
      congruency (i.e., different packets traversing the exact same
      path).

4.  Security Considerations

   A malicious node along the path could attempt to forge the aggregate,
   resulting in a wrong aggregate to be reported.  This might mislead
   applications.  Likewise, a malicious node along the path could set a
   flag to trick other nodes not to process the aggregate any further,
   or clear a flag to make an errored result appear legitimate.  To
   avoid this, network operators need to ensure that their network nodes
   can be trusted and are not compromised.

5.  IANA Considerations

   IANA requests are TBD.  Future versions of this document may request
   the establishment of a registry for Aggregators as well as for IOAM
   Data Parameters.

6.  Contributors

   *  Ramon Bister, OST

   *  Severin Dellsperger, OST

   *  Reto Furrer, OST

7.  References

7.1.  Normative References

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/rfc/rfc9197>.

7.2.  Informative References

Clemm & Metzger          Expires 27 October 2024                [Page 8]
Internet-Draft                  ioam-aggr                     April 2024

   [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/rfc/rfc8200>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/rfc/rfc8799>.

   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In Situ Operations, Administration, and
              Maintenance (IOAM) Direct Exporting", RFC 9326,
              DOI 10.17487/RFC9326, November 2022,
              <https://www.rfc-editor.org/rfc/rfc9326>.

   [RFC9378]  Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T.
              Mizrahi, Ed., "In Situ Operations, Administration, and
              Maintenance (IOAM) Deployment", RFC 9378,
              DOI 10.17487/RFC9378, April 2023,
              <https://www.rfc-editor.org/rfc/rfc9378>.

   [RFC9486]  Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
              In Situ Operations, Administration, and Maintenance
              (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9486>.

Authors' Addresses

   Alexander Clemm
   Email: ludwig@clemm.org

   Laurent Metzger
   Ostschweizer Fachhochschule - OST
   Email: laurent.metzger@ost.ch

Clemm & Metzger          Expires 27 October 2024                [Page 9]