Subject: Re: [lp-wan] Ticket #13: SCHC: terminology and "sublayers"

From: Ana Minaburo <[email-masked]>
Date: Sun, 11 Feb 2018 19:51:41 +0100

Hello,

a Ticket (#13) has been created for this discussion, please include the
ticket number in the discussion to follow it.

https://trac.ietf.org/trac/lpwan/ticket/13

On Wed, Jan 31, 2018 at 6:30 AM, Shoichi Sakane <[email-masked]> wrote:

> Hi,
>
> This clarification is fine to me.  If I would say more, #3 should have the
> diagram for the incoming processing.
>
> I think that the fragmentation should be more clarified.  If both
> compression and fragmentation take place to a IPv6 packet, the SCHC packet
> is fragmented into some SCHC fragments which have another Rule ID.  Correct
> ?
>
> Best,
> Shoichi
>
> On 1/31/18 03:03, Carles Gomez Montenegro wrote:
> > Hi everyone,
> >
> > One topic that appears to be important (based on feedback from the
> > reviewers) is to better clarify the different stages and ordering of the
> > operations defined by SCHC (for a sender, it is first 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 a
> > 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 a
> > SCHC packet. Fragmentation is needed when the size of a 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.
> >
> > Thanks!
> >
> > Carles
> >
> > _______________________________________________
> > lp-wan mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/lp-wan
> >
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>