lpwan Working Group                                             A. Pelov
Internet-Draft                                                    Acklio
Intended status: Standards Track                              P. Thubert
Expires: July 23, 2021                                     Cisco Systems
                                                             A. Minaburo
                                                                  Acklio
                                                        January 19, 2021


        Static Context Header Compression (SCHC) Architecture
               draft-pelov-lpwan-architecture-00

Abstract

   This document defines the SCHC architecture.

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 July 23, 2021.

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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Pelov, et al.             Expires July 23, 2021                 [Page 1]


Internet-Draft           SCHC Architecture                  January 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Global architecture . . . . . . . . . . . . . . . . . . . . .   3
   4.  Data management . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The base operation and the definition of the SCHC compression &
   Fragmentation are now described in several documents published by the
   LPWAN working group.

   Among them:

   o  The [rfc8724] defines the generic compression and fragmentation
      mechanisms for SCHC and applies it to IPv6 and UDP.

   o  The [I-D.ietf-lpwan-coap-static-context-hc] extend the compression
      to CoAP and OSCORE.

   o  The [I-D.ietf-lpwan-schc-yang-data-model] defines a rule
      representation using the YANG formalism.

   As [I-D.ietf-lpwan-coap-static-context-hc] states, the SCHC
   compression and fragmentation mechanism can be implemented at
   different levels and/or managed by different organizations.  For
   instance, as represented figure Figure 1, IP compression and
   fragmentation may be managed by the network SCHC instance and end-to-
   end compression between the device and the application.  The former
   can itself be split in two instances since encryption hides the field
   structure.
















Pelov, et al.             Expires July 23, 2021                 [Page 2]


Internet-Draft           SCHC Architecture                  January 2021


         (device)            (NGW)                              (App)

         +--------+                                           +--------+
  A S    |  CoAP  |                                           |  CoAP  |
  p C    |  inner |                                           |  inner |
  p H    +--------+                                           +--------+
  . V    |  SCHC  |                                           |  SCHC  |
         |  inner |   cryptographical boundary                |  inner |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  A S    |  CoAP  |                                           |  CoAP  |
  p C    |  outer |                                           |  outer |
  p H    +--------+                                           +--------+
  . C    |  SCHC  |                                           |  SCHC  |
         |  outer |   functional boundary                     |  outer |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  N      .  udp   .                                           .  udp   .
  e      ..........     ..................                    ..........
  t      .  ipv6  .     .      ipv6      .                    .  ipv6  .
  w C    ..........     ..................                    ..........
  o S    .  schc  .     .  schc  .       .                    .        .
  r H    ..........     ..........       .                    .        .
  k C    .  lpwan .     . lpwan  .       .                    .        .
         ..........     ..................                    ..........
             ((((LPWAN))))             ------   Internet  ------

                Figure 3: OSCORE compression/decompression.


           Figure 1: Different SCHC instances in a global system

   This document defines a generic architecture for SCHC that can be
   used at any of these levels.  The goal of the architectural document
   is to orchestrate the different protocols and data model defined by
   the LPWAN woeking group to design an operational and interoperable
   framework for allowing IP application over contrained networks.

2.  Definitions

3.  Global architecture

   As described in [rfc8724] a SCHC service is composed of a Parser,
   analyzing packets and creating a list of fields what will be used to
   match against the compression rules.  If a packet matches rules,
   compression can be applied following rules instructions.

   If SCHC compressed packet is too large to be send in a single L2
   frame, fragmentation will apply.  The process is similar, device
   rules are checked to find the most appropriate fragmentation rule,



Pelov, et al.             Expires July 23, 2021                 [Page 3]


Internet-Draft           SCHC Architecture                  January 2021


   regarding the SCHC packet size, the link error rate, the reliability
   required by the application, ...

   On the other direction, when a packet SCHC arrives, the ruleID is
   used to find the rule.  Its nature allows to select if it is a
   compression or fragmentation rule.

   The rule database contains a set of rules specific to a single
   device.  The [rfc8724] indicates that the SCHC instance reads the
   rules to process C/D and F/R, rules are not modified during these
   actions.

   A SCHC instance, summarized in the Figure 2, implies C/D and F/R
   present in both end.  The device connected to a constrained network
   is in one end and the other end is either located in the core network
   or at the application.

   In any cases, the rules must be the same in both ends to perform C/D
   and F/R.

       (device)                                 (core|app)

        (---)                                     (---)
        ( r )                                     ( r )
        (---)                                     (---)
           . read                                   . read
           .                                        .
        +-----+                                  +-----+
    <===| R&D |<=..............................<=| C&F |<===
    ===>| C&F |=>..............................=>| R&D |===>
        +-----+                                  +-----+



                    Figure 2: Summarized SCHC elements

   To enable rule synchronization between both ends, a common rule
   representation must be defined.

4.  Data management

   [I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to
   represent the rules.  This enables the use of several protocols for
   rule management, such as NETCONF, RESTCONF and CORECONF.  NETCONF
   uses SSH, RESTCONF uses HTTPS, and CORECONF uses CoAP(s) as their
   respective transport layer protocols.  The data is represented in XML
   under NETCONF, in JSON under RESTCONF and in CBOR under CORECONF.




Pelov, et al.             Expires July 23, 2021                 [Page 4]


Internet-Draft           SCHC Architecture                  January 2021


                     create
          (-------)  read   +=======+ *
          ( rules )<------->|Rule   |<--|-------->
          (-------)  update |Manager|   NETCONF, RESTCONF or CORECONF
             . read  delete +=======+   request
             .
          +-------+
      <===| R & D |<===
      ===>| C & F |===>
          +-------+

                    Figure 3: Summerized SCHC elements

   Rule Manager (RM) is in charge of handling data derived from the YANG
   Data Model and apply changes to the rules database Figure 3.

   The RM is a application using the Internet to exchange information,
   therefore:

   o  for the network-level SCHC, the communication does not require
      routing.  Each of the end-points having an RM and both RMs can be
      viewed on the same link, therefore wellknown Link Local addresses
      can be used to identify the device and the core RM.  L2 security
      MAY be deemed as sufficient, if it provides the necessary level of
      protection.

   o  for application-level SCHC, routing is involved and global IP
      addresses SHOULD be used.  End-to-end encryption is recommended.

   Management messages can also be carried in the negotiation protocol
   as proposed in [I-D.thubert-lpwan-schc-over-ppp]

   The RM traffic may be itself compressed by SCHC, especially if
   CORECONF is used, [I-D.ietf-lpwan-coap-static-context-hc] can be
   used.

5.  Acknowledgements

   The authors would like to thank (in alphabetic order):

6.  Normative References

   [I-D.ietf-lpwan-coap-static-context-hc]
              Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
              Context Header Compression (SCHC) for CoAP", draft-ietf-
              lpwan-coap-static-context-hc-16 (work in progress),
              October 2020.




Pelov, et al.             Expires July 23, 2021                 [Page 5]


Internet-Draft           SCHC Architecture                  January 2021


   [I-D.ietf-lpwan-schc-yang-data-model]
              Minaburo, A. and L. Toutain, "Data Model for Static
              Context Header Compression (SCHC)", draft-ietf-lpwan-schc-
              yang-data-model-03 (work in progress), July 2020.

   [I-D.thubert-lpwan-schc-over-ppp]
              Thubert, P., "SCHC over PPP", draft-thubert-lpwan-schc-
              over-ppp-01 (work in progress), June 2020.

   [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>.

Authors' Addresses

   Alexander Pelov
   Acklio
   1137A avenue des Champs Blancs
   35510 Cesson-Sevigne Cedex
   France

   Email: a@ackl.io


   Pascal Thubert
   Cisco Systems
   45 Allee des Ormes - BP1200
   06254 Mougins - Sophia Antipolis
   France

   Email: pthubert@cisco.com


   Ana Minaburo
   Acklio
   1137A avenue des Champs Blancs
   35510 Cesson-Sevigne Cedex
   France

   Email: ana@ackl.io









Pelov, et al.             Expires July 23, 2021                 [Page 6]