LPWAN Working Group                                             A. Pelov
Internet-Draft                                                    Acklio
Intended status: Informational                                P. Thubert
Expires: 30 May 2022                                       Cisco Systems
                                                             A. Minaburo
                                                                  Acklio
                                                        26 November 2021


      LPWAN Static Context Header Compression (SCHC) Architecture
                    draft-ietf-lpwan-architecture-01

Abstract

   This document defines the LPWAN 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 30 May 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 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.





Pelov, et al.              Expires 30 May 2022                  [Page 1]


Internet-Draft             LPWAN Architecture              November 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  LPWAN Technologies and Profiles . . . . . . . . . . . . . . .   3
   3.  The Static Context Header Compression . . . . . . . . . . . .   3
   4.  SCHC Applicability  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  LPWAN Overview  . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Compressing Serial Streams  . . . . . . . . . . . . . . .   4
     4.3.  Example: Goose and DLMS . . . . . . . . . . . . . . . . .   4
   5.  SCHC Architecture . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  SCHC Endpoints  . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  Layering with SCHC Instances  . . . . . . . . . . . . . .   5
   6.  SCHC Data Model . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  SCHC Device Lifecycle . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Device Development  . . . . . . . . . . . . . . . . . . .   8
     7.2.  Rules Publication . . . . . . . . . . . . . . . . . . . .   8
     7.3.  SCHC Device Deployment  . . . . . . . . . . . . . . . . .   9
     7.4.  SCHC Device Maintenance . . . . . . . . . . . . . . . . .   9
     7.5.  SCHC Device Decommissionning  . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The IETF LPWAN WG defined the necessary operations to enable IPv6
   over selected Low-Power Wide Area Networking (LPWAN) radio
   technologies. [rfc8376] presents an overview of those technologies.

   The Static Context Header Compression (SCHC) [rfc8724] technology is
   the core product of the IETF LPWAN working group. [rfc8724] defines a
   generic framework for header compression and fragmentation, based on
   a static context that is pre-installed on the SCHC endpoints.

   This document details the constitutive elements of a SCHC-based
   solution, and how the solution can be deployed.  It provides a
   general architecture for a SCHC deployment, positioning the required
   specifications, describing the possible deployment types, and
   indicating models whereby the rules can be distributed and installed
   to enable reliable and scalable operations.








Pelov, et al.              Expires 30 May 2022                  [Page 2]


Internet-Draft             LPWAN Architecture              November 2021


2.  LPWAN Technologies and Profiles

   Because LPWAN technologies [rfc8376] have strict yet distinct
   constraints, e.g., in terms of maximum frame size, throughput, and/or
   directionality, a SCHC instance must be profiled to adapt to the
   specific necessities of the technology to which it is applied.

   Appendix D.  "SCHC Parameters" of [rfc8724] lists the information
   that an LPWAN technology-specific document must provide to profile
   SCHC for that technology.

   As an example, [rfc9011] provides the SCHC profile for LoRaWAN
   networks.

3.  The Static Context Header Compression

   SCHC [rfc8724] specifies an extreme compression capability based on a
   state that must match on the compressor and decompressor side.  This
   state comprises a set of Compression/Decompression (C/D) rules.

   The SCHC Parser analyzes incoming packets and creates a list of
   fields that it matches against the compression rules.  The rule that
   matches best is used to compress the packet, and the rule identifier
   (RuleID) is transmitted together with the compression residue to the
   decompressor.  Based on the RuleID and the residue, the decompressor
   can rebuild the original packet and forward it in its uncompressed
   form over the Internet.

   [rfc8724] also provides a Fragmentation/Reassembly (F/R) capability
   to cope with the maximum and/or variable frame size of a Link, which
   is extremely constrained in the case of an LPWAN network.

   If a SCHC-compressed packet is too large to be sent in a single Link-
   Layer PDU, the SCHC fragmentation can be applied on the compressed
   packet.  The process of SCHC fragmentation is similar to that of
   compression; the fragmentation rules that are programmed for this
   Device are checked to find the most appropriate one, regarding the
   SCHC packet size, the link error rate, and the reliability level
   required by the application.

   The ruleID allows to determine if it is a compression or
   fragmentation rule.









Pelov, et al.              Expires 30 May 2022                  [Page 3]


Internet-Draft             LPWAN Architecture              November 2021


4.  SCHC Applicability

4.1.  LPWAN Overview

4.2.  Compressing Serial Streams

   [rfc8724] was defined to compress IPv6 [rfc8200] and UDP; but SCHC
   really is a generic compression and fragmentation technology.  As
   such, SCHC is agnostic to which protocol it compresses and at which
   layer it is operated.  The C/D peers may be hosted by different
   entities for different layers, and the F/R operation may also be
   performed between different parties, or different sub-layers in the
   same stack, and/or managed by different organizations.

   If a protocol or a layer requires additional capabilities, it is
   always possible to document more specifically how to use SCHC in that
   context, or to specify additional behaviours.  For instance,
   [I-D.ietf-lpwan-coap-static-context-hc] extends the compression to
   CoAP [RFC7252] and OSCORE [RFC8613].

4.3.  Example: Goose and DLMS

5.  SCHC Architecture

5.1.  SCHC Endpoints

   Section 3 of [rfc8724] depicts a typical network architecture for an
   LPWAN network, simplified from that shown in [rfc8376] and reproduced
   in Figure 1.

    ()   ()   ()       |
     ()  () () ()     / \       +---------+
   () () () () () () /   \======|    ^    |             +-----------+
    ()  ()   ()     |           | <--|--> |             |Application|
   ()  ()  ()  ()  / \==========|    v    |=============|   Server  |
     ()  ()  ()   /   \         +---------+             +-----------+
    Dev            RGWs             NGW                      App

                Figure 1: Typical LPWAN Network Architecture












Pelov, et al.              Expires 30 May 2022                  [Page 4]


Internet-Draft             LPWAN Architecture              November 2021


   Typically, an LPWAN network topology is star-oriented, which means
   that all packets between the same source-destination pair follow the
   same path from/to a central point.  In that model, highly constrained
   Devices (Dev) exchange information with LPWAN Application Servers
   (App) through a central Network Gateway (NGW), which can be powered
   and is typically a lot less constrained than the Devices.  Because
   Devices embed built-in applications, the traffic flows to be
   compressed are known in advance and the location of the C/D and F/R
   functions (e.g., at the Dev and NGW), and the associated rules, can
   be pre provisionned in the system before use.

   Nevertheless, SCHC is very generic and its applicability is not
   limited to star-oriented deployments and/or to use cases where
   applications are very static and the state provisionned in advance.
   [I-D.thubert-intarea-schc-over-ppp] describes an alternate deployment
   where the C/D and/or F/R operations are performed between peers of
   equal capabilities over a PPP [rfc2516] connection.  SCHC over PPP
   illustrates that with SCHC, the protocols that are compressed can be
   discovered dynamically and the rules can be fetched on-demand by both
   parties from the same Uniform Resource Name (URN) [rfc8141], ensuring
   that the peers use the exact same set of rules.

       +----------+  Wi-Fi /   +----------+                ....
       |    IP    |  Ethernet  |    IP    |            ..          )
       |   Host   +-----/------+  Router  +----------(   Internet   )
       | SCHC C/D |  Serial    | SCHC C/D |            (         )
       +----------+            +----------+               ...
                   <-- SCHC -->
                     over PPP

                    Figure 2: PPP-based SCHC Deployment

5.2.  Layering with SCHC Instances

   The rule database contains at least one set of rules that are
   specific per Device.  There is thus a SCHC instance per pair of
   endpoints. [rfc8724] states that a SCHC instance needs the rules to
   process C/D and F/R before the session starts, and that rules cannot
   be modified during the session.

   As represented figure Figure 3, the compression of the IP and UDP
   headers may be operated by a network SCHC instance whereas the end-
   to-end compression of the application payload happens between the
   Device and the application.  The compression of the application
   payload may be split in two instances to deal with the encrypted
   portion of the application PDU.  Fragmentation applies before LPWAN
   transportation layer.




Pelov, et al.              Expires 30 May 2022                  [Page 5]


Internet-Draft             LPWAN Architecture              November 2021


         (Device)            (NGW)                              (App)

         +--------+                                           +--------+
  A S    |  CoAP  |                                           |  CoAP  |
  p C    |  inner |                                           |  inner |
  p H    +--------+                                           +--------+
  . C    |  SCHC  |                                           |  SCHC  |
         |  inner |   cryptographical boundary                |  inner |
 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
  A S    |  CoAP  |                                           |  CoAP  |
  p C    |  outer |                                           |  outer |
  p H    +--------+                                           +--------+
  . C    |  SCHC  |                                           |  SCHC  |
         |  outer |   layer / functional boundary             |  outer |
 -._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
  N      .  UDP   .                                           .  UDP   .
  e      ..........     ..................                    ..........
  t      .  IPv6  .     .      IPv6      .                    .  IPv6  .
  w S    ..........     ..................                    ..........
  o C    .SCHC/L3 .     . SCHC/L3.       .                    .        .
  r H    ..........     ..........       .                    .        .
  k C    .  LPWAN .     . LPWAN  .       .                    .        .
         ..........     ..................                    ..........
             ((((LPWAN))))             ------   Internet  ------

        Figure 3: 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 working group to design an operational and interoperable
   framework for allowing IP application over contrained networks.

6.  SCHC Data Model

   A SCHC instance, summarized in the Figure 4, implies C/D and/or F/R
   present in both end and that both ends are provisionned with the same
   set of rules.

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



Pelov, et al.              Expires 30 May 2022                  [Page 6]


Internet-Draft             LPWAN Architecture              November 2021


                     Figure 4: Summarized SCHC elements

   A common rule representation that expresses the SCHC rules in an
   interoperable fashion is needed yo be able to provision end-points
   from different vendors To that effect,
   [I-D.ietf-lpwan-schc-yang-data-model] defines a rule representation
   using the YANG [rfc7950] formalism.

   [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[RFC6241], RESTCONF[RFC8040], and
   CORECONF[I-D.ietf-core-comi].  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[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF.

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

                     Figure 5: Summerized SCHC elements

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

   The RM is an Application using the Internet to exchange information,
   therefore:

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

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







Pelov, et al.              Expires 30 May 2022                  [Page 7]


Internet-Draft             LPWAN Architecture              November 2021


   Management messages can also be carried in the negotiation protocol
   as proposed in [I-D.thubert-intarea-schc-over-ppp].  The RM traffic
   may be itself compressed by SCHC: if CORECONF protocol is used,
   [I-D.ietf-lpwan-coap-static-context-hc] can be applied.

7.  SCHC Device Lifecycle

   In the context of LPWANs, the expectation is that SCHC rules are
   associated with a physical device that is deployed in a network.
   This section describes the actions taken to enable an autimatic
   commissioning of the device in the network.  SCHC

7.1.  Device Development

   The expectation for the development cycle is that message formats are
   documented as a data model that is used to generate rules.  Several
   models are possible:

   1.  In the application model, an interface definition language and
       binary communication protocol such as Apache Thrift is used, and
       the serialization code includes the SCHC operation.  This model
       imposes that both ends are compiled with the generated structures
       and linked with generated code that represents the rule
       operation.

   2.  In the device model, the rules are generated separately.  Only
       the device-side code is linked with generated code.  The Rules
       are published separately to be used by a generic SCHC engine that
       operates in a middle box such as a SCHC gateway.

   3.  In the protocol model, both endpoint generate a packet format
       that is imposed by a protocol.  In that case, the protocol itself
       is the source to generate the Rules.  Both ends of the SCHC
       compression are operated in middle boxes, and special attention
       must be taken to ensure that they operate on the compatible Rule
       sets, basically the same major version of the same Rule Set.

   Depending on the deployment, the tools thar generate the Rules should
   provide knobs to optimize the Rule set, e.g., more rules vs. larger
   residue.

7.2.  Rules Publication

   In the device model and in the protocol model, at least one of the
   endpoints must obtain the rule set dynamically.  The expectation is
   that the Rule Sets are published to a reachable repository and
   versionned (minor, major).  Each rule set should have its own Uniform
   Resource Names (URN) [RFC8141] and a version.



Pelov, et al.              Expires 30 May 2022                  [Page 8]


Internet-Draft             LPWAN Architecture              November 2021


   The Rule Set should be authenticated to ensure that it is genuine, or
   obtained from a trusted app store.  A corrupted Rule Set may be used
   for multiple forms of attacks, more in Section 8.

7.3.  SCHC Device Deployment

   The device and the network should mutually authenticate themselves.
   The autonomic approach [RFC8993] provides a model to achieve this at
   scale with zero touchn, in networks where enough bandwidth and
   compute are available.  In highly constrained networks, one touch is
   usually necessary to program keys in the devices.

   The initial handshake between the SCHC endpoints should comprise a
   capability exchange whereby URN and the version of the rule set are
   obtained or compared.  SCHC may not be used if both ends can not
   agree on an URN and a major version.  Manufacturer Usage Descriptions
   (MUD) [RFC8520] may be used for that purpose in the device model.

   Upon the handshake, both ends can agree on a rule set, their role
   when the rules are asymmetrical, and fetch the rule set if necessary.
   Optionally, a node that fetwhed a rule set may inform the other end
   that it is reacy from transmission.

7.4.  SCHC Device Maintenance

   URN update without device update (bug fix) FUOTA => new URN =>
   reprovisionning

7.5.  SCHC Device Decommissionning

   Signal from device/vendor/network admin

8.  Security Considerations

   SCHC is sensitive to the rules that could be abused to form arbitrary
   long messages or as a form of attack against the C/D and/or F/R
   functions, say to generate a buffer overflow and either modify the
   Device or crash it.  It is thus critical to ensure that the rules are
   distributed in a fashion that is protected against tempering, e.g.,
   encrypted and signed.

   # IANA Consideration

   This document has no request to IANA







Pelov, et al.              Expires 30 May 2022                  [Page 9]


Internet-Draft             LPWAN Architecture              November 2021


9.  Acknowledgements

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

10.  References

10.1.  Normative References

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

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,
              <https://www.rfc-editor.org/info/rfc8520>.

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

   [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
              L., and J. Nobre, "A Reference Model for Autonomic
              Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
              <https://www.rfc-editor.org/info/rfc8993>.

   [rfc9011]  Gimenez, O., Ed. and I. Petrov, Ed., "Static Context
              Header Compression and Fragmentation (SCHC) over LoRaWAN",
              RFC 9011, DOI 10.17487/RFC9011, April 2021,
              <https://www.rfc-editor.org/info/rfc9011>.

10.2.  Informative References








Pelov, et al.              Expires 30 May 2022                 [Page 10]


Internet-Draft             LPWAN Architecture              November 2021


   [I-D.ietf-core-comi]
              Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
              I. Petrov, "CoAP Management Interface (CORECONF)", Work in
              Progress, Internet-Draft, draft-ietf-core-comi-11, 17
              January 2021, <https://www.ietf.org/archive/id/draft-ietf-
              core-comi-11.txt>.

   [I-D.ietf-lpwan-coap-static-context-hc]
              Minaburo, A., Toutain, L., and R. Andreasen, "Static
              Context Header Compression (SCHC) for the Constrained
              Application Protocol (CoAP)", Work in Progress, Internet-
              Draft, draft-ietf-lpwan-coap-static-context-hc-19, 8 March
              2021, <https://www.ietf.org/archive/id/draft-ietf-lpwan-
              coap-static-context-hc-19.txt>.

   [I-D.ietf-lpwan-schc-yang-data-model]
              Minaburo, A. and L. Toutain, "Data Model for Static
              Context Header Compression (SCHC)", Work in Progress,
              Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-06,
              24 November 2021, <https://www.ietf.org/archive/id/draft-
              ietf-lpwan-schc-yang-data-model-06.txt>.

   [I-D.thubert-intarea-schc-over-ppp]
              Thubert, P., "SCHC over PPP", Work in Progress, Internet-
              Draft, draft-thubert-intarea-schc-over-ppp-03, 21 April
              2021, <https://www.ietf.org/archive/id/draft-thubert-
              intarea-schc-over-ppp-03.txt>.

   [rfc2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
              February 1999, <https://www.rfc-editor.org/info/rfc2516>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [rfc7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.





Pelov, et al.              Expires 30 May 2022                 [Page 11]


Internet-Draft             LPWAN Architecture              November 2021


   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [rfc8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

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

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [rfc8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

Authors' Addresses

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

   Email: a@ackl.io










Pelov, et al.              Expires 30 May 2022                 [Page 12]


Internet-Draft             LPWAN Architecture              November 2021


   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 30 May 2022                 [Page 13]