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, . 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]