Concise Binary Object Representation (CBOR) Sequences
draft-bormann-cbor-sequence-01

Request for posting confirmation emailed  to submitter and authors: Carsten Bormann Internet-Draft                LPWAN SCHC                      May 2018

    |---Fragmentation Header----|
              |-- T --|1|-- N --|
    +-- ... --+- ... -+-+- ... -+--------...-------+
    | Rule ID | DTag  |W|  FCN  | Fragment payload |
    +-- ... --+- ... -+-+- ... -+--------...-------+

    Figure 12: Fragment Detailed Format for Fragments except the Last
                    One, ACK-Always and ACK-on-Error

  In the No-ACK mode, SCHC Fragments except the last one SHALL conform
  to the detailed format defined in Figure 13.  The total size of the
  fragment header is not byte aligned.

    |---Fragmentation Header---|
              |-- T --|-- N --|
    +-- ... --+- ... -+- ... -+--------...-------+
    | Rule ID |  DTag |  FCN  | Fragment payload |
    +-- ... --+- ... -+- ... -+--------...-------+

    Figure 13: Fragment Detailed Format for Fragments except the Last
                            One, No-ACK mode

  In all these cases, the total size of the fragment header is not byte
  aligned.

7.4.2.  All-1 and All-0 formats

  The All-0 format is used for sending the last SCHC Fragment of a
  window that is not the last window of the packet.

            |-- T --|1|-- N --|
  +-- ... --+- ... -+-+- ... -+--- ... ---+
  | Rule ID | DTag  |W|  0..0 |  payload  |
  +-- ... --+- ... -+-+- ... -+--- ... ---+

                Figure 14: All-0 fragment detailed format

  The All-0 empty fragment format is used by a sender to request the
  retransmission of an SCHC ACK by the receiver.  It is only used in
  ACK-Always mode.

Minaburo, et al.        Expires November 23, 2018              [Page 26]
Internet-Draft                LPWAN SCHC                      May 2018

              |-- T --|1|-- N --|
    +-- ... --+- ... -+-+- ... -+
    | Rule ID | DTag  |W|  0..0 | (no payload)
    +-- ... --+- ... -+-+- ... -+

              Figure 15: All-0 empty fragment detailed format

  In the No-ACK mode, the last SCHC Fragment of an IPv6 datagram SHALL
  contain a SCHC Fragment header that conforms to the detaield format
  shown in Figure 16.

                |-- T --|-N=1-|
  +---- ... ---+- ... -+-----+---- ... ----+---...---+
  |  Rule ID  | DTag  |  1  |    MIC    | payload |
  +---- ... ---+- ... -+-----+---- ... ----+---...---+

  Figure 16: All-1 Fragment Detailed Format for the Last Fragment, No-
                                ACK mode

  In any of the Window modes, the last fragment of an IPv6 datagram
  SHALL contain a SCHC Fragment header that conforms to the detailed
  format shown in Figure 17.  The total size of the SCHC Fragment
  header in this format is not byte aligned.

            |-- T --|1|-- N --|
  +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+
  | Rule ID | DTag  |W| 11..1 |    MIC    | payload |
  +-- ... --+- ... -+-+- ... -+---- ... ----+---...---+
                        (FCN)

  Figure 17: All-1 Fragment Detailed Format for the Last Fragment, ACK-
                          Always or ACK-on-Error

  In either ACK-Always or ACK-on-Error, in order to request a
  retransmission of the SCHC ACK for the All-1 window, the fragment
  sender uses the format shown in Figure 18.  The total size of the
  SCHC Fragment header in not byte aligned.

            |-- T --|1|-- N --|
  +-- ... --+- ... -+-+- ... -+---- ... ----+
  | Rule ID | DTag  |W|  1..1 |    MIC    | (no payload)
  +-- ... --+- ... -+-+- ... -+---- ... ----+

      Figure 18: All-1 for Retries format, also called All-1 empty

Minaburo, et al.        Expires November 23, 2018              [Page 27]
Internet-Draft                LPWAN SCHC                      May 2018

  The values for Fragmentation Header, N, T and the length of MIC are
  not specified in this document, and SHOULD be determined in other
  documents (e.g. technology-specific profile documents).

7.4.3.  SCHC ACK format

  The format of an SCHC ACK that acknowledges a window that is not the
  last one (denoted as All-0 window) is shown in Figure 19.

              |-- T --|1|
  +---- ... --+- ... -+-+---- ... -----+
  |  Rule ID  |  DTag |W|encoded Bitmap| (no payload)
  +---- ... --+- ... -+-+---- ... -----+

                  Figure 19: ACK format for All-0 windows

  To acknowledge the last window of a packet (denoted as All-1 window),
  a C bit (i.e.  MIC checked) following the W bit is set to 1 to
  indicate that the MIC check computed by the receiver matches the MIC
  present in the All-1 fragment.  If the MIC check fails, the C bit is
  set to 0 and the Bitmap for the All-1 window follows.

              |-- T --|1|1|
  +---- ... --+- ... -+-+-+
  |  Rule ID  |  DTag |W|1| (MIC correct)
  +---- ... --+- ... -+-+-+

  +---- ... --+- ... -+-+-+----- ... -----+
  |  Rule ID  |  DTag |W|0|encoded Bitmap |(MIC Incorrect)
  +---- ... --+- ... -+-+-+----- ... -----+
                          C

            Figure 20: Format of an SCHC ACK for All-1 windows

7.4.3.1.  Bitmap Encoding

  The Bitmap is transmitted by a receiver as part of the SCHC ACK
  format.  An SCHC ACK message MAY include padding at the end to align
  its number of transmitted bits to a multiple of 8 bits.

  Note that the SCHC ACK sent a response to an All-1 fragment including
  the C bit.  Therefore, the window size and thus the encoded Bitmap
  size need to be determined to take into account the available space
  in the layer two frame payload, where there will be 1 bit less for an
  SCHC ACK sent in response to an All-1 fragment than in other SCHC

Minaburo, et al.        Expires November 23, 2018              [Page 28]
Internet-Draft                LPWAN SCHC                      May 2018

  ACKs.  Note that the maximum number of SCHC Fragments of the last
  window is one unit smaller than that of the previous windows.

  When the receiver transmits an encoded Bitmap with a SCHC Fragment
  that has not been sent during the transmission, the sender will Abort
  the transmission.

                      |----        Bitmap bits      ----|
  | Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|
  |--- byte boundary ----| 1 byte  next  |  1 byte next  |

                      Figure 21: A non-encoded Bitmap

  In order to reduce the resulting frame size, the encoded Bitmap is
  shortened by applying the following algorithm: all the right-most
  contiguous bytes in the encoded Bitmap that have all their bits set
  to 1 MUST NOT be transmitted.  Because the SCHC Fragment sender knows
  the actual Bitmap size, it can reconstruct the original Bitmap with
  the trailing 1 bit optimized away.  In the example shown in
  Figure 22, the last 2 bytes of the Bitmap shown in Figure 21
  comprises bits that are all set to 1, therefore they are not sent.

              |-- T --|1|
  +---- ... --+- ... -+-+-+-+
  |  Rule ID  |  DTag |W|1|0|
  +---- ... --+- ... -+-+-+-+
  |---- byte boundary -----|

                    Figure 22: Optimized Bitmap format

  Figure 23 shows an example of an SCHC ACK with FCN ranging from 6
  down to 0, where the Bitmap indicates that the second and the fifth
  SCHC Fragments have not been correctly received.

Minaburo, et al.        Expires November 23, 2018              [Page 29]
Internet-Draft                LPWAN SCHC                      May 2018

                        6 5 4 3 2 1  0 (*)
            |-- T --|1|
  +---------+-------+-+-+-+-+-+-+-+-----+
  | Rule ID |  DTag |W|1|0|1|1|0|1|all-0| Bitmap(before tx)
  +---------+-------+-+-+-+-+-+-+-+-----+
  |<-- byte boundary ->|<---- 1 byte---->|
      (*)=(FCN values)

  +---------+------+-+-+-+-+-+-+-+-----+~~
  | Rule ID | DTag |W|1|0|1|1|0|1|all-0|Padding(opt.) encoded Bitmap
  +---------+------+-+-+-+-+-+-+-+-----+~~
  |<-- byte boundary ->|<---- 1 byte---->|

        Figure 23: Example of a Bitmap before transmission, and the
            transmitted one, in any window except the last one

  Figure 24 shows an example of an SCHC ACK with FCN ranging from 6
  down to 0, where the Bitmap indicates that the MIC check has failed
  but there are no missing SCHC Fragments.

    |-Fragmentation Header-|6 5 4 3 2 1 7 (*)
              |-- T --|1|
    |  Rule ID |  DTag |W|0|1|1|1|1|1|1|1|padding|  Bitmap (before tx)
    |---- byte boundary -----|  1 byte next |
                          C
    +---- ... --+-... -+-+-+-+
    |  Rule ID  | DTag |W|0|1| encoded Bitmap
    +---- ... --+-... -+-+-+-+
    |---- byte boundary -----|
      (*) = (FCN values indicating the order)

    Figure 24: Example of the Bitmap in ACK-Always or ACK-on-Error for
                        the last window, for N=3)

7.4.4.  Abort formats

  Abort are coded as exceptions to the previous coding, a specific
  format is defined for each direction.  When a SCHC Fragment sender
  needs to abort the transmission, it sends the Sender-Abort format
  Figure 25, that is an All-1 fragment with no MIC or payload.  In
  regular cases All-1 fragment contains at least a MIC value.  This
  absence of the MIC value indicates an Abort.

  When a SCHC Fragment receiver needs to abort the on-going SCHC
  Fragmented packet transmission, it transmits the Receiver- Abort
  format Figure 26, creating an exception in the encoded Bitmap coding.

Minaburo, et al.        Expires November 23, 2018              [Page 30]
Internet-Draft                LPWAN SCHC                      May 2018

  Encoded Bitmap avoid sending the rigth most bits of the Bitmap set to
  1.  Abort is coded as an SCHC ACK message with a Bitmap set to 1
  until the byte boundary, followed by an extra 0xFF byte.  Such
  message never occurs in a regular acknowledgement and is view as an
  abort.

  None of these messages are not acknowledged nor retransmitted.

  The sender uses the Sender-Abort when the MAX_ACK_REQUEST is reached.
  The receiver uses the Receiver-Abort when the Inactivity timer
  expires, or in the ACK-on-Error mode, SCHC ACK is lost and the sender
  transmits SCHC Fragments of a new window.  Some other cases for Abort
  are explained in the Section 7.5 or Appendix C.

  |-- Fragmentation Header ---|--- 1 byte ----|
  +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+
  |  Rule ID  | DTag  |W| FCN |      FF      | (no MIC & no payload)
  +--- ... ---+- ... -+-+-...-+-+-+-+-+-+-+-+-+

    Figure 25: Sender-Abort format.  All FCN fields in this format are
                                set to 1

    |----- byte boundary ------|---- 1 byte ---|

    +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Rule ID  | DTag |W| 1..1|      FF      |
    +---- ... --+-... -+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 26: Receiver-Abort format

7.5.  Baseline mechanism

  If after applying SCHC header compression (or when SCHC header
  compression is not possible) the SCHC Packet does not fit within the
  payload of a single L2 data unit, the SCHC Packet SHALL be broken
  into SCHC Fragments and the fragments SHALL be sent to the fragment
  receiver.  The fragment receiver needs to identify all the SCHC
  Fragments that belong to a given SCHC Packet.  To this end, the
  receiver SHALL use:

  o  The sender's L2 source address (if present),

  o  The destination's L2 address (if present),

  o  Rule ID,

Minaburo, et al.        Expires November 23, 2018              [Page 31]
Internet-Draft                LPWAN SCHC                      May 2018

  o  DTag (if present).

  Then, the fragment receiver MAY determine the SCHC Fragment
  reliability mode that is used for this SCHC Fragment based on the
  Rule ID in that fragment.

  After a SCHC Fragment reception, the receiver starts constructing the
  SCHC Packet.  It uses the FCN and the arrival order of each SCHC
  Fragment to determine the location of the individual fragments within
  the SCHC Packet.  For example, the receiver MAY place the fragment
  payload within a payload datagram reassembly buffer at the location
  determined from the FCN, the arrival order of the SCHC Fragments, and
  the fragment payload sizes.  In Window mode, the fragment receiver
  also uses the W bit in the received SCHC Fragments.  Note that the
  size of the original, unfragmented packet cannot be determined from
  fragmentation headers.

  Fragmentation functionality uses the FCN value to transmit the SCHC
  Fragments.  It has a length of N bits where the All-1 and All-0 FCN
  values are used to control the fragmentation transmission.  The rest
  of the FCN numbers MUST be assigned sequentially in a decreasing
  order, the first FCN of a window is RECOMMENDED to be MAX_WIND_FCN,
  i.e. the highest possible FCN value depending on the FCN number of
  bits.

  In all modes, the last SCHC Fragment of a packet MUST contain a MIC
  which is used to check if there are errors or missing SCHC Fragments
  and MUST use the corresponding All-1 fragment format.  Note that a
  SCHC Fragment with an All-0 format is considered the last SCHC
  Fragment of the current window.

  If the receiver receives the last fragment of a datagram (All-1), it
  checks for the integrity of the reassembled datagram, based on the
  MIC received.  In No-ACK, if the integrity check indicates that the
  reassembled datagram does not match the original datagram (prior to
  fragmentation), the reassembled datagram MUST be discarded.  In
  Window mode, a MIC check is also performed by the fragment receiver
  after reception of each subsequent SCHC Fragment retransmitted after
  the first MIC check.

  There are three reliability modes: No-ACK, ACK-Always and ACK-on-
  Error.  In ACK-Always and ACK-on-Error, a jumping window protocol
  uses two windows alternatively, identified as 0 and 1.  A SCHC
  Fragment with all FCN bits set to 0 (i.e. an All-0 fragment)
  indicates that the window is over (i.e. the SCHC Fragment is the last
  one of the window) and allows to switch from one window to the next
  one.  The All-1 FCN in a SCHC Fragment indicates that it is the last

Minaburo, et al.        Expires November 23, 2018              [Page 32]
Internet-Draft                LPWAN SCHC                      May 2018