SCHClet - A Modular Approach to SCHC Architecture
draft-pelov-schclet-architecture-00

Network Working Group                                           A. Pelov
Internet-Draft                                            IMT Atlantique
Intended status: Informational                             31 March 2025
Expires: 2 October 2025

           SCHClet - A Modular Approach to SCHC Architecture
                  draft-pelov-schclet-architecture-00

Abstract

   This draft introduces the concept of a SCHClet, a modular, atomic
   sub-function within the SCHC (Static Context Header Compression)
   framework.  Drawing an analogy from chiplet technology in integrated
   circuits, a SCHClet is envisioned as a self-contained unit that
   encapsulates a specific SCHC function or set of functions.  This
   modular approach allows for tailored implementations that can meet
   diverse use cases without the overhead of a full SCHC apparatus.  By
   decomposing SCHC functionality into SCHClets, the framework becomes
   more adaptable, extensible, and easier to deploy generic network
   environments, applicable, but not limited to constrained networks.

   A technology which uses a SCHClet can be considered as built using
   the SCHC Framework.  A generic SCHC Framework implementation which
   has all SCHClets implemented MUST be able to interoperate with any
   SCHClet, provided it has the corresponding configuration.  For
   example, if one IPsec end-point uses a minimal SCHClet
   implementation, the other end-point may use a full SCHC
   implementation with the corresponding configuration.

   It may be said that a SCHClet is the minimal sub-function
   corresponding to a given SCHC Context.  In this sense, we can see
   Ack-On-Err Fragmentation as a SCHClet.  We may consider the Ack-
   Always Fragmentation as a SCHClet.  Or we may consider the baseline
   fragmentations from RFC8724 (NoAck, AckAlways, AckOnErr) as a
   SCHClet, with the parameters defining which fragmentation mode is
   used.  In any case, a developer may chose to use only the NoAck
   fragmentation (for example), and in this case they are using the
   NoAck Fragmentation SCHClet, which can even be further restricted to
   a fixed set of parameters, with different parameters unsupported by
   the implementation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Pelov                    Expires 2 October 2025                 [Page 1]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

   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 2 October 2025.

Copyright Notice

   Copyright (c) 2025 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 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Background and Motivation . . . . . . . . . . . . . . . . . .   4
     3.1.  Simplifications Enabled by SCHClets . . . . . . . . . . .   4
   4.  SCHClet: Definition and Analogies . . . . . . . . . . . . . .   5
     4.1.  Defining a Chiplet  . . . . . . . . . . . . . . . . . . .   5
     4.2.  SCHClet by Analogy  . . . . . . . . . . . . . . . . . . .   6
   5.  Design Considerations . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Integration with Existing SCHC Implementations  . . . . .   6
     5.2.  Interoperability and Configuration  . . . . . . . . . . .   6
     5.3.  Extensibility for Future Enhancements . . . . . . . . . .   7
   6.  Use Cases and Examples  . . . . . . . . . . . . . . . . . . .   7
     6.1.  IPsec Compression SCHClet . . . . . . . . . . . . . . . .   7
     6.2.  Fragmentation SCHClets  . . . . . . . . . . . . . . . . .   8
     6.3.  Future Extensions . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

Pelov                    Expires 2 October 2025                 [Page 2]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

1.  Introduction

   The SCHC framework, as defined in RFC8724 and related documents, was
   originally designed to address the needs of constrained networks by
   providing efficient header compression.  Over time, the addition of
   new functionalities—such as Compound Acknowledgement and various
   fragmentation modes—has revealed both the strengths and limitations
   of a monolithic SCHC implementation.

   A SCHClet is a self-contained function of SCHC, which may or may not
   include all aspects discussed in RFC8724, or other related SCHC RFCs.

   One of the goals for definition of a SCHClet is the fact that parts
   of SCHC may be applicable to many use-cases, without the need to
   include the entire SCHC apparatus.  This is somehow done in SCHC RFC
   technology profiles, where there is no rule management for example.
   There is no rule discovery, no description of SCHC Stratum, etc.  In
   that sense, these RFCs use SCHC, built on a specific set of SCHClets
   and their configuration.

   A full SCHC implementation is supposed to implement at least RFC8724.
   However, there are more and more RFCs that add supplementary
   funcionalities, such as CompoundAck.  In this sense, what is
   considered a full SCHC implementation today, may not be exhaustive
   tomorrow.

   The notion of SCHClet allows to express the atomic sub-functions of
   SCHC, which allow for a technology to use the SCHC framework in their
   own setting, without having to integrate the entirety of all
   SCHClets.

   For example, the IPsec draft, includes only compression, and with
   specific compression rules.  It may be seen as a SCHClet, using only
   SCHC Compression from RFC8724, with only a subset of the CDAs.  This
   SCHClet will not be supposed to interoperate with a generic SCHC
   compression context.

   This provides for a way to define future extensions of the SCHC
   Framework.  For example, new SCHC Fragmentations can be considered as
   SCHClets.  Adding aggregation functions can be considered as a
   SCHClet.  FEC can be considered as a SCHClet.

   This draft proposes a modular architecture for SCHC through the
   introduction of SCHClets.  Each SCHClet represents an atomic sub-
   function of the overall SCHC process.  This design enables developers
   to incorporate only the relevant SCHC functionality for a given
   application, thereby reducing complexity and resource requirements
   while retaining the benefits of the SCHC approach.

Pelov                    Expires 2 October 2025                 [Page 3]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

2.  Terminology

   *  SCHClet: A self-contained unit within the SCHC framework that
      implements a specific SCHC function or a subset of SCHC
      operations.  A SCHClet may implement aspects defined in RFC8724 or
      other related SCHC RFCs, and is designed to be combined with other
      SCHClets or integrated into a full SCHC implementation.

   *  Full SCHC Implementation: An implementation that covers all
      mandatory aspects of SCHC as defined in RFC8724, potentially
      extended by additional functionalities introduced in subsequent
      RFCs.

   *  Context: In SCHC, context refers to the set of parameters, rules,
      and configurations that govern the operation of a SCHC
      implementation or SCHClet.

3.  Background and Motivation

   SCHC was developed to provide a robust mechanism for header
   compression in networks with strict resource constraints.  The
   original design focused on a comprehensive implementation that would
   cover all aspects of SCHC functionality.  However, several trends
   have emerged:

   *  Diverse Use Cases: Different applications may require only a
      subset of SCHC functionalities.  For example, some may only need
      compression while others might focus solely on fragmentation.

   *  Evolving Standards: As new RFCs extend SCHC functionality (e.g.,
      Compound Acknowledgement, advanced fragmentation techniques), a
      monolithic implementation risks becoming overly complex.

   *  Resource Optimization: In constrained environments, it is
      beneficial to deploy only the necessary SCHC functions to optimize
      memory, processing power, and energy usage.

   The SCHClet concept addresses these challenges by providing a modular
   approach that decouples individual SCHC functions from a monolithic
   architecture.

3.1.  Simplifications Enabled by SCHClets

   By breaking down a SCHC implementation into SCHClets, several
   simplifications can be realized:

Pelov                    Expires 2 October 2025                 [Page 4]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

   *  Exclusion of Rule Management:
      SCHClets can omit complex rule discovery, installation, and update
      mechanisms.  This results in a leaner protocol that focuses on the
      core function (e.g., compression) without the overhead of managing
      multiple rule sets.

   *  Omission of SCHC Stratum considerations: A SCHClet does not have
      to handle the higher-level coordination and context
      synchronization typically associated with the full SCHC Stratum,
      reducing implementation complexity.

   *  Fixed or Limited Negotiation:
      Instead of supporting extensive negotiation for every parameter, a
      SCHClet may operate with a fixed set of configuration parameters,
      further reducing signaling overhead.

   *  Targeted Functionality: Specific optional functions (such as
      compound acknowledgments or advanced fragmentation modes) can be
      encapsulated in separate SCHClets.  This approach allows
      developers to include only the necessary functions for a given use
      case, simplifying the overall design.

   Please note, that as a full SCHC implementation with the right
   configuration MUST interoperate with a specific SCHClet, even though
   these notions are not necesserily handled by the SCHClet itself, they
   can be reinterpreted as a full SCHC implementation would.  For
   example, an implementer of a compression SCHClet may never formally
   use Rule Management, Discriminators, SCHC Header or other notions
   defined in the SCHC Architecture, these can be infered by the
   knowledgeable SCHC practitionner.  It is of course RECOMMENDED that a
   SCHClet provides a complete picture of its use in the context of a
   full SCHC implementation.

4.  SCHClet: Definition and Analogies

4.1.  Defining a Chiplet

   In modern integrated circuit design, a chiplet is a small, modular
   building block that performs a specific function.  By interconnecting
   multiple chiplets, designers can create highly optimized and flexible
   systems.  The modular nature of chiplets allows for innovation and
   reuse, as each chiplet can be developed, tested, and upgraded
   independently.

Pelov                    Expires 2 October 2025                 [Page 5]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

4.2.  SCHClet by Analogy

   Analogous to a chiplet, a SCHClet is a self-contained SCHC function
   that can be independently implemented, deployed, and configured.  A
   SCHClet may:

   *  Implement only the compression functionality of SCHC.

   *  Focus on a specific fragmentation mode, such as NoAck or Ack-On-
      Err.

   *  Incorporate advanced features like aggregation or Forward Error
      Correction (FEC) without enforcing a full SCHC stack.

   This modularity permits a technology to adopt SCHC functionalities in
   a piecemeal fashion, reducing integration complexity while still
   benefiting from SCHC’s design principles.

5.  Design Considerations

5.1.  Integration with Existing SCHC Implementations

   A SCHClet is designed to be interoperable with both minimal and full
   SCHC implementations.  For instance, an endpoint may implement a
   single SCHClet for a specific function (e.g., IPsec compression)
   while the corresponding peer uses a comprehensive SCHC implementation
   that supports multiple SCHClets.  Proper configuration and
   negotiation mechanisms are essential to ensure that both ends
   correctly interpret the SCHC context.

5.2.  Interoperability and Configuration

   Interoperability between SCHClets and full SCHC implementations
   hinges on:

   *  Configuration Parameters: Each SCHClet must expose configuration
      parameters that clearly define its operational context.  These
      parameters should be standardized to facilitate cross-
      implementation compatibility.

   *  Negotiation Mechanisms: When establishing communication, endpoints
      must negotiate which SCHClets are in use and align their
      configurations accordingly.  This may involve exchanging minimal
      metadata to indicate capabilities.

   *  Layered Implementation: A generic SCHC framework may integrate
      multiple SCHClets, with each responsible for a distinct part of
      the compression or fragmentation process.

Pelov                    Expires 2 October 2025                 [Page 6]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

5.3.  Extensibility for Future Enhancements

   The SCHClet architecture provides a structured pathway for
   introducing future SCHC functionalities.  Potential extensions
   include:

   *  New Fragmentation Methods: Future fragmentation techniques can be
      encapsulated as individual SCHClets, providing flexibility in
      deployment.

   *  Aggregation Functions: Aggregation of multiple packets or flows
      could be implemented as a SCHClet, allowing devices to optimize
      communication based on traffic patterns.

   *  FEC Schemes: Forward Error Correction can be modularized, enabling
      error-resilient communications without affecting other SCHC
      functions.

6.  Use Cases and Examples

6.1.  IPsec Compression SCHClet

   An illustrative example is an IPsec draft that leverages SCHC
   compression:

   *  Functionality: This SCHClet implements only the compression rules
      defined in RFC8724 and a limited set of Context-Dependent
      Attributes (CDAs).

   *  Deployment: The implementation is tailored for IPsec environments,
      focusing solely on compression without engaging in rule management
      or SCHC Stratum functions.

   *  Interoperability: Although minimal, this SCHClet must be
      configured to operate alongside endpoints that might use full SCHC
      implementations.

   As an example, Diet-ESP, as defined in draft-ietf-IPsecme-diet-esp-05
   (https://datatracker.ietf.org/doc/html/draft-ietf-IPsecme-diet-esp-
   05), represents a minimal, streamlined version of the ESP protocol
   designed for constrained environments.  By integrating SCHClets,
   Diet-ESP can leverage SCHC’s compression or fragmentation
   capabilities in a modular manner, without needing to implement a full
   SCHC implementation.

Pelov                    Expires 2 October 2025                 [Page 7]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

6.2.  Fragmentation SCHClets

   Fragmentation is a core aspect of SCHC, with multiple modes
   available:

   *  NoAck Fragmentation SCHClet: Implements a fragmentation scheme
      without acknowledgement, suitable for low-overhead scenarios.

   *  Ack-On-Err Fragmentation SCHClet: Incorporates error recovery
      mechanisms by acknowledging only when errors occur.

   *  Ack-Always Fragmentation SCHClet: Provides continuous
      acknowledgement for reliable communication, albeit with increased
      overhead.

   Developers may choose to implement one or more of these SCHClets
   based on application requirements and network conditions.

6.3.  Future Extensions

   Beyond current functionalities, SCHClets offer a pathway for future
   enhancements: - Aggregation SCHClet: Could combine multiple small
   packets into a larger one to improve transmission efficiency. - FEC
   SCHClet: Provides error correction capabilities that are critical in
   lossy network environments. - Custom SCHClets: Developers may design
   proprietary SCHClets to address niche requirements, thereby extending
   the SCHC framework’s versatility.

7.  Security Considerations

   TBD.

8.  IANA Considerations

   This document does not require any immediate IANA actions.

9.  Normative References

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

Author's Address

Pelov                    Expires 2 October 2025                 [Page 8]
Internet-Draft  SCHClet - A Modular Approach to SCHC Arc      March 2025

   Alexander Pelov
   IMT Atlantique
   2bis rue de la Chataigneraie
   35536 Cesson-Sévigné
   France
   Email: alexander.pelov@imt-atlantique.fr

Pelov                    Expires 2 October 2025                 [Page 9]