Re: [lp-wan] Ticket #13: Terminology Sublayers
<dominique.barthel@orange.com> Tue, 27 March 2018 15:23 UTC
Return-Path: <dominique.barthel@orange.com>
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 31CB5127601; Tue, 27 Mar 2018 08:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 v71W36W1SuOO; Tue, 27 Mar 2018 08:23:56 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE12712D964; Tue, 27 Mar 2018 08:23:55 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id A59CAA022D; Tue, 27 Mar 2018 17:23:54 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 70CB620069; Tue, 27 Mar 2018 17:23:54 +0200 (CEST)
Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 17:23:54 +0200
From: dominique.barthel@orange.com
To: "ana@ackl.io" <ana@ackl.io>, lp-wan <lp-wan@ietf.org>
CC: "lpwan-chairs@ietf.org" <lpwan-chairs@ietf.org>
Thread-Topic: [lp-wan] Ticket #13: Terminology Sublayers
Thread-Index: AQHTxdzqITJDWNZWQkSRhXSLu6CCXaPkM30A
Date: Tue, 27 Mar 2018 15:23:53 +0000
Message-ID: <1406_1522164234_5ABA620A_1406_447_1_D6E02A70.5122E%dominique.barthel@orange.com>
References: <CAOPRf-c0xk3=jkcVkhFnGPkbpmuA3JpH1EjS3vjN1uMwY7muag@mail.gmail.com>
In-Reply-To: <CAOPRf-c0xk3=jkcVkhFnGPkbpmuA3JpH1EjS3vjN1uMwY7muag@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-originating-ip: [10.168.234.2]
Content-Type: multipart/alternative; boundary="_000_D6E02A705122Edominiquebarthelorangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/BiuNbIS-S50wIIIKPwdXwzfJ6lU>
Subject: Re: [lp-wan] Ticket #13: Terminology Sublayers
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Mar 2018 15:23:59 -0000
Hello Ana
Thanks for this proposal.
Since we show the SCHC ACK flowing backward, I suggest we show the SCHC fragment flowing forward, instead of the vague term "transmission".
Same for the transmission of the SCHC Packet.
How about this ? (I changed the font to Courier so that it be fixed-width. Easier to draw asci art!)
Thanks
Dominique
A packet (e.g. an IPv6 packet)
| ^
v |
+—-----------------+ +--------------------+
| SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+
| |
| |
| |
| If no fragmentation (*) |
+------------------------------ SCHC Packet -------------------------------------->|
| |
| |
+--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| +--------------------------- SCHC Fragments ---------------------------------+ |
+------------------------------------ SCHC ACK ------------------------------------------+
SENDER RECEIVER
*: see Section xxx for the decision.
De : lp-wan <lp-wan-bounces@ietf.org<mailto:lp-wan-bounces@ietf.org>> on behalf of Ana Minaburo <ana@ackl.io<mailto:ana@ackl.io>>
Répondre à : "ana@ackl.io<mailto:ana@ackl.io>" <ana@ackl.io<mailto:ana@ackl.io>>
Date : Tuesday 27 March 2018 17:03
À : lp-wan <lp-wan@ietf.org<mailto:lp-wan@ietf.org>>
Cc : "lpwan-chairs@ietf.org<mailto:lpwan-chairs@ietf.org>" <lpwan-chairs@ietf.org<mailto:lpwan-chairs@ietf.org>>
Objet : Re: [lp-wan] Ticket #13: Terminology Sublayers
On Mon, Feb 26, 2018 at 9:59 PM, Ana Minaburo <ana@ackl.io<mailto:ana@ackl.io>> wrote:
One topic that appears to be important (based on feedback from the
reviewers) is to better clarify the different stages and the order of the
operations defined by SCHC (for a sender, first, it is compression, then
fragmentation, if needed). This would be basically introductory material.
Also, there are terminology issues (e.g. how do we call the data unit after
compression?).
So here are some proposals.
1.- We may define that SCHC comprises two sublayers (i.e. compression
sublayer and fragmentation sublayer, as shown in the figure. Would there
be any (hidden) issues involved by adding this to the document?
+----------------+ \
| Compression | \
+----------------+ > SCHC
| Fragmentation | /
+----------------+ /
2.- Two terms are proposed below:
* “SCHC packet”: a packet (e.g. an IPv6 packet) whose header has been compressed per the header compression mechanism defined in this document. If the header compression process is unable to actually compress the packet header, the packet with the uncompressed header is still called an SCHC packet (in this case, a Rule ID is used to indicate that the packet header has not been compressed).
* “SCHC fragment”: a data unit that carries a subset of the bytes of an SCHC packet. Fragmentation is needed when the size of an SCHC packet exceeds the available payload size of the data unit of the layer underlying SCHC.
3.- Would the following diagram (for a sender) provide further clarity
regarding what SCHC defines?
IPv6 packet
|
/ V
| +--------------+
| | compression |
| +--------------+
| |
SCHC < SCHC packet
| |
| V
| +----------------+
| | fragmentation | (if needed)
| +----------------+
| |
\ V
SCHC fragment (if needed)
We may include content such as the one above in the next revision of SCHC,
so please do not hesitate to provide your feedback.
----------
IETF 101
In order to clarify the terminology of all the draft, a new section called Overview is added with all the vocabulary and some figures showing the different components of the SCHC Compression and the SCHC Fragmentation. There are also some definitions of the lines in the Rules in order to better understand the definitions all over the document (Field Description), the ACK now are SCHC ACK, SCHC Packet, SCHC Fragment.
* #5 #13 : Overview, comments ask precision on how Compression and fragmentation are arranged
* Ana: The SCHC overview (tickets) were addressed by adding text on how the fragmentation and compression are working together.
* first step is compression, if there is no rule a specific rule Id is added.
* Dominique: One of the issue was that there was no name for the remaining part of the compression - "the SCHC packet"
* Ana: SCHC packet is a compressed packet or a packet for which compression has not been possible (but it will also have a Rule ID)
* Dominique: There will be capitalization to indicate a SCHC "P"acket and SCHC "F"ragment
* A next figure is proposed for -11 to explain the link between compression and fragmentation
* Ana explains a figure.
* After SCHC Compression, if SCHC packet fits L2 there will be no Fragmentation and, thus, it will b e transmitted. Otherwise, there will be a SCHC Fragmentation.
* Thus, the SCHC packet will be splitted to SCHC Fragment(s) and then transmitted.
*
* JC Zúñiga; Does this assume any rule ID space.
* Dominique: We will come back to this later.
*
* Alex requests the room to raise their hand or come to the mic if they do not agree with the following open tickets.
* Rahul Jadhav (from Jabber - Shoichi): how can you know if a packet has not been compressed or is a fragment?
* Ana: based on the Rule ID. We have a slide later
*
* Dominique: clarification in terminology:
* - compressed header : Something that was not understood was that we are only compressing the headers, not the payload itself.
* - compresison residue: what is not in the rule and has to be sent
* - fragmentation header
*
* JCZ: simplify the figure: just one fragment in the figure
*
* Ack was defined as a special case of a fragment, but it is confusing;
* new term: SCHC Ack
*
* No name for line in rule table => Field Description.
*
* Georgios: Asks about the figure on slide 8 in connection to Acks.
* Ana: ACK are only for SCHC Fragments.
* Dominique: Should we add SCHC ACK in SCHC Overview figure? "Yes" in the room.
A packet (e.g. an IPv6 packet)
| ^
v |
+---------------------------+ +------------------------------+
| SCHC Compression | |SCHC Decompression|
+----------------------------+ +------------------------------+
| |
SCHC packet |
| |
| IF No Fragmentation (Ref. section for the decision) |
+------------------------------- transmission -------------------------------- -->|
| |
| |
+---------------------------+ +---------------------------+
|SCHC Fragmentation| | SCHC Reassembly |
+----------------------------+ +---------------------------+
| ^
SCHC Fragment(s) |
| |
| |
| |
v ^
------------------------------------transmission-------------------------------->
<----------------------------------SCHC ACK------------------------------------
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
- [lp-wan] Ticket #13: Terminology Sublayers Ana Minaburo
- Re: [lp-wan] Ticket #13: Terminology Sublayers Ana Minaburo
- Re: [lp-wan] Ticket #13: Terminology Sublayers dominique.barthel
- Re: [lp-wan] Ticket #13: Terminology Sublayers Ana Minaburo