[lp-wan] Profile Questions

Ana Minaburo <ana@ackl.io> Tue, 28 January 2020 15:54 UTC

Return-Path: <ana@ackl.io>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E511209C2 for <lp-wan@ietfa.amsl.com>; Tue, 28 Jan 2020 07:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-N6PrzWrVpV for <lp-wan@ietfa.amsl.com>; Tue, 28 Jan 2020 07:54:08 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333B31209CE for <lp-wan@ietf.org>; Tue, 28 Jan 2020 07:54:08 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id t26so14784511ioi.13 for <lp-wan@ietf.org>; Tue, 28 Jan 2020 07:54:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=850+8aY9lk+BS2wOpbt7Yi5VXWiqX5/FLQa2ZE6LSXI=; b=izp+jAwAWc3lh31g0G+8Z9Wphx3omkaivVq5+pznWx1HDZgIYBkGlHAyPx7xDzMmvq OgZGJTqMEmdWxNn7Sa70U86Ue8MDBGyHfjCC57ZVt9Y3RX3vKCEe6G10tTMaVd2R8cVo cELbGIlQvPQ3Z7rGG2onDEqy2y+QCInXBrG22MizbGIxpIaeOEDKo7hju4xDQ9uSg7mj Y5nsWhkVaTQyxIZm5zAqUXkkqP620GrLLjEgAUXx05TeX3J773icKei/nkJDxk85vzbR pifA3uFcH/AUdWXcSLCyy8LIV6jHRJhJESp7Ggd2IfKtPMgFMmkbvTm+bohl39tHK0ul PJyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=850+8aY9lk+BS2wOpbt7Yi5VXWiqX5/FLQa2ZE6LSXI=; b=Pxh/3xIRQiljR+6gLSO+4oN3QmkD1YaE5yUdb4eoPvtbZF69LALSi3U8TvTKJrxF9o VQYOSHzPsMtLD8BE4MDbychlH7zuo5nmI8KnDl6dja0PiLjeMOcoAA/TeadWWyc2DKMA PsMHTaFhJ+wCkBtpj0NdVkEPP27t4SzEjKegZDfg4hgP09zQjCEV6T+O49PHUfHcv3JK IUzIVXpDIGU2YXnp1E4mlkSxtZFSFQsxS5lFVgkIahDdaM25AIbShm6nG1SfmJ2cW2qD XcH696THpP3zlOmdbPAwUCbSqW8UP+sZI+6Tl/QIdXOiCL34y4cznizaLgM+n4TwRycI 2pSQ==
X-Gm-Message-State: APjAAAUUDbfKuDQrJaqtd0oft2JGn9m0eB4/6FjXm0olJ48ye+q9tBzQ TlRdGNveZYuUn6PtCbJh6ol9SwLTOGQGisAJ76ZNOAMm9+3CIw==
X-Google-Smtp-Source: APXvYqxEngw2mHDQVrd4fsb7JSRfVgRVbJXjq5SJ2CjtDpS7QhQYNytKb0L1DWVvhKsZ3Ha77k9QRLrwDYCCo6VWh4M=
X-Received: by 2002:a05:6602:22d6:: with SMTP id e22mr17032745ioe.41.1580226847245; Tue, 28 Jan 2020 07:54:07 -0800 (PST)
MIME-Version: 1.0
From: Ana Minaburo <ana@ackl.io>
Date: Tue, 28 Jan 2020 16:53:41 +0100
Message-ID: <CAAbr+nR23JgOWXSuiWO2q_-dLROvxT81hP4NnHq=hu4m5jJekg@mail.gmail.com>
To: lp-wan <lp-wan@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e51b07059d353b4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/6qYRRmAlGB75Lnyjrp_unIkZ3mc>
Subject: [lp-wan] Profile Questions
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2020 15:54:11 -0000

Dear LPWANers,

The last version of SCHC document gives quite an extensive list of things
that need to be defined in something called 'Profiles.' This concept is
broadened, and I presume it is only a list of parameters to be set and
functionalities that need to be restricted in used or avoided to be used.
But while defining parameters for NB-IoT draft the following question
raised:

The draft is not clear about where these profiles get into the
communication or not, do they?

How are they distinguishable from other profiles? Is an identifier needed?

Who can define a new one?

Does a profile contain Rules or Rules are separate things?

Do we need to be formal in the number of "profiles" we need?

Is profile a configuration that is used locally and then only requires to
define all the SCHC parameters and so these configurations are merely
informative and not mandatory?

Here I put a non-exhaustive list of what the draft talks about profiles:
The draft SCHC specifies in page 7 the definition of Profiles as
"Profile: SCHC offers variations in the way it is operated, with a
 number of parameters listed in Appendix D.  A Profile indicates a
      particular setting of all these parameters.  Both ends of a SCHC
      communication must be provisioned with the same Profile
      information and with the same set of Rules before the
      communication starts, so that there is no ambiguity in how they
      expect to communicate."

But all are not in Appendix D because you can find through the document a
number of things that need to be addressed as:
-The use or not of Fragmentation (page 9, 21)
-The size of the Rule_ID (page 11)
-The way the Rule ID is sent (page 16)
-The IID value (page 20)
- The Fragmentation Modes used (page 21)
- The restriction or not of interleaving fragments for different fragmented
SCHC packets" (page 21)
- Window_Size (page 23)
- Specify how integrity check is performed (page 24)
- The size  and presence of DTag
- The size and presence of W- The FCN size for each Rule_ID
- The size and algorithm for RCS field for each Rule_ID
- The All-1 SCHC Fragment is distinguishable from Send-Abort msg
- Which Rule_ID values correspond to SCHC F/R msg
- The expiration time of the Inactivity Timer
- The meaning of values sent in the FCN field
- Which Rule ID corresponds to each SCHC F/R
- The penultimate tile is regular size or regular minus L2 Word
- Last tile must be sent either as regular fragment or multi-tiles or alone
in an All-1 SCHC fragment
- Other times the sender must listen for SCHC ACK msg
- the size of L2 Word
- The value of padding bits
- Whether and when the UDP CHECKSUM is elided
- MAX_PACKET_SIZE
- A delay to be added after each SCHC message transmission
- The MAX_ACK_REQUESTS
- Settings and choices specific to a technology or a product
and many others that I've not listed

Thanks,
 Ana