Subject: Re: [6tisch] Comment to draft-wang-6tisch-6top-coapie-01.txt

From: Thomas Watteyne <[email-masked]>
Date: Fri, 25 Sep 2015 12:31:59 +0200

We need to discuss this point urgently, and do the work to ask the IEEE for
carve out some IE space for IETF/6TISCH if applicable.

On Thu, Jul 23, 2015 at 4:28 PM, Qin Wang <[email-masked]> wrote:

> Hi Pat,
>
> Since there are two approaches mentioned in the discussion, i.e. (1)
> containing 6top-to-6top message in a specific payload IE (coapie), (2)
> using the mechanism provided by IEEE802.15.9 to convey the 6top-to-6top
> message, I would like to do more evaluation. I couldn't find the
> IEEE802.15.9 spec on IEEE802 website. Can you tell me how to get it?
>
> Thanks
> Qin
>
>
>
> On Tuesday, July 21, 2015 8:59 PM, Tero Kivinen <[email-masked]> wrote:
>
>
> This draft plans to put the coap messages directly on the payload IEs
> in the 802.15.4. The problem is that we only have 16 payload IE types
> in total for 802.15.4, so reserving one number for coap might be hard.
>
> On the other hand IEEE 802.15.9 needed to have solution to this same
> problem, i.e how to multiplex upper layer data packet over 802.15.4
> frames and how to fragment them so they can fit on the 802.15.4
> frames.
>
> The 802.15.9 is split in two layers, first one is the multiplexed data
> service, which takes 16-bit MultiplexId and the data packet to be sent
> to the other end, and it will fragment and deliver it to the other
> end. The MultiplexId is used to separate different protocols using
> this mechanism. One of those protocols is the key management protocols
> providing KMP for 802.15.4, which is the second part of the 802.15.9.
>
> Instead putting the coap messages in the payload IEs, it would
> possible to allocate one MultiplexId for coap messages, and then coap
> messages could be transmitted using multiplexing layer of 802.15.9.
> This would also take care of fragmentting the messages (with PHY using
> 127 octet PSDU, the maximum size of the data packet is around 24kB).
>
> The 802.15.9 recommended practice is already past the working group
> letter ballots, and is starting its sponsor ballot soon. It is
> expected to come out around the end of year. The draft will be
> available on the ieee document store after the sponsor ballot starts,
> i.e. very soon.
> --
> [email-masked]
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 25 Sep 2015 15:00:48 +0300

Thomas Watteyne writes:
> We need to discuss this point urgently, and do the work to ask the
> IEEE for carve out some IE space for IETF/6TISCH if applicable.

There is Vendor specific IE space for both header and payload IEs.
Those can be used provided IETF has OUI allocated from RAC. The
802.15.9 uses ethertypes, so you can allocate one of ethertypes for
generic, or you can ask for an number from 802.15.9 specific range.

I think for this the 802.15.9 would be better, as it would also
provide the fragmentation and multiplexing layer, meaning you are not
restricted to 127 byte limit.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 25 Sep 2015 14:18:44 +0200

Tero,

I'm cautious in embracing a standard without understanding benefits and
overhead:

Where can I download the 802.15.9 spec? All I can find is
https://www.ietf.org/proceedings/84/slides/slides-84-roll-3.pdf

What is the scope of 802.15.9? It is presented as a Key Management
solution, yet you suggest to use 802.15.9's mechanisms for (i) IE space and
(ii) fragmentation. It looks to me like we would be exploiting a tiny
fraction of a much more involved standard, but have to include the full
memory footprint.

How much flash/RAM memory is a 802.15.9 implementation?

Thomas

---

From: Alexander Pelov <[email-masked]>
Date: Sat, 26 Sep 2015 23:43:43 +0200

Dear all,

For me the ideal solution would be if one of the 16 payload types could 
be allocated to CoAP. This way, we could use it for 6TiSCH and 
long-range, low-rate WANs. However, this would provide for a generic, 
extensible mechanism of operating these networks. Adding too much 
overhead (not sure how many bytes 802.15.9 takes) would make it 
impractical for LR-WANs.

On the packet fragmentation, I like the approach taken by the 802.15.4k 
LECIM group, which introduces a new type of frame - 110 Fragment Frame - 
and sends the full 802.15.4 MAC header only in the first frame (context 
establishment - some other info is added also). Afterwards, the set of 
fragments is identified only through a 7 bit identifier assigned by the 
sender. In each consecutive fragment, only a 2 byte MAC header is 
included (3 bits frame type (= 110), 7 bits frame ID, 6 bits frame 
counter). Extremely efficient in terms of overhead (e.g. MAC addresses 
are sent only during the context establishment), and particularly well 
adapted to infrastructure networks. Not sure if it would fit all 6TiSCH 
scenarios though.

Best,
Alexander

Le 25/09/2015 12:31, Thomas Watteyne a écrit :
> On Thu, Jul 23, 2015 at 4:28 PM, Qin Wang <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Pat,
>
>     Since there are two approaches mentioned in the discussion, i.e.
>     (1) containing 6top-to-6top message in a specific payload IE
>     (coapie), (2) using the mechanism provided by IEEE802.15.9 to
>     convey the 6top-to-6top message, I would like to do more
>     evaluation. I couldn't find the IEEE802.15.9 spec on IEEE802
>     website. Can you tell me how to get it?
>
>     Thanks
>     Qin
>
>
>
>     On Tuesday, July 21, 2015 8:59 PM, Tero Kivinen <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Sep 2015 11:55:50 +0300

> https://www.ietf.org/proceedings/84/slides/slides-84-roll-3.pdf

The 802.15.9 is now in the Sponsor Ballot, and we are not allowed to
distribute it to others now, but you can go and buy it from the IEEE
Standards Store:

http://www.techstreet.com/ieee/products/1902465

The price is $86, which is not that bad, compared that the
802.15.4-REVc draft is $433
(http://www.techstreet.com/ieee/products/1894072).

> What is the scope of 802.15.9?

The 802.15.9 related documents can be found from mentor:

https://mentor.ieee.org/802.15/documents?is_group=0009

and the scope of 802.15.9 can be found from the latest PAR change
document:

https://mentor.ieee.org/802.15/dcn/15/15-15-0464-00-0009-p802-15-9-par-detail-draft-change-2015-05.pdf

I.e the scope is:

	This Recommended Practice defines a message exchange framework
	based on Information Elements as a transport method for key
	management protocol (KMP) datagrams and guidelines for the use
	of some existing KMPs with the IEEE Std 802.15.4. This
	Recommended Practice does not create a new KMP.

> It is presented as a Key Management solution, yet you suggest to use
> 802.15.9's mechanisms for (i) IE space and (ii) fragmentation.

The 802.15.9 document is split in two pieces, the multiplexing and
fragmentation layer, and the key management layer. The key management
layer requires a method of transmitting messages which are larger than
802.15.4 phy frames, thus it needed layer to fragment KMP messages and
transmit them over 802.15.4 phy frames. While we created that, people
said that this mechanism would be useful also for others, so make sure
other protocols can also use this. Because of this we added simple
multiplexing method, which will allow others to use the fragmentation
and transport method too. 

> It looks to me like we would be exploiting a tiny fraction of a
> much more involved standard, but have to include the full memory footprint.

Actually most of the 802.15.9 implementation parts are in the
multiplexing and fragmentation layer. The KMP layer is very minimal,
only consisting of one byte identifying the KMP protocol to use. I.e.
MP IE Format description in the specification is 4 pages, and the KMP
service description is one page...

All the actual key management protocols are described in the appendix,
and none of those are mandatory to implement (i.e. all are informative
annexes). I.e. you can implement 802.15.9 without implementing any key
management protocols, and if you do not have any KMPs configured, then
all your MLME calls related to them are not really relevant. 

> How much flash/RAM memory is a 802.15.9 implementation?

As this is recommended practice that is still in the draft phase, I do
not think there is any implementations of it out there yet. There are
other groups interested in using it, so perhaps they will get some
numbers out after we get through sponsor ballot.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Sep 2015 12:16:27 +0300

Alexander Pelov writes:
> For me the ideal solution would be if one of the 16 payload types could be
> allocated to CoAP. This way, we could use it for 6TiSCH and long-range,
> low-rate WANs. However, this would provide for a generic, extensible mechanism
> of operating these networks. Adding too much overhead (not sure how many bytes
> 802.15.9 takes) would make it impractical for LR-WANs.

If the message fits in the single frame (i.e. is less than 100 octet
long, when using PHYs with 127 octet max frame length), 802.15.9 adds
following overhead:

 * Normal MAC header
 * 2 octets for the Header Termination 1 IE
 * 2 octets for the MP IE Payload IE header
 * 1 octet for transaction control
 * 2 octets for multiplex ID (may be omitted in future for some IDs)

And thats it, i.e. 1-3 octets, I would expect it to go to 1 for CoAP.

If specify your own Payload IE, you might save 1-3 octets, depending
how you specify the IE. To support fragmentation you most likely need
at least one octet to specify whether it is in use (== transaction
control), and then you are at the same as 802.15.9.

When the frame is larger than what PHY support the overhead is:

For the first frame:

 * Normal MAC header
 * 2 octets for the Header Termination 1 IE
 * 2 octets for the MP IE Payload IE header
 * 1 octet for transaction control
 * 1 octet for fragment number
 * 2 octets for total frame size
 * 2 octets for multiplex ID

For the following and last frame

 * Normal MAC header
 * 2 octets for the Header Termination 1 IE
 * 2 octets for the MP IE Payload IE header
 * 1 octet for transaction control
 * 1 octet for fragment number

I.e. 6 octets for first frame, and 2 octets for following frames. 

> On the packet fragmentation, I like the approach taken by the 802.15.4k LECIM
> group, which introduces a new type of frame - 110  Fragment Frame - and sends
> the full 802.15.4 MAC header only in the first frame (context establishment -
> some other info is added also).

That fragmentation was completely broken, and cannot be used in
general cases. It has been removed from the generic MAC parts, and
moved to the LECIM PHY description, and it is now specified as PHY
layer fragmentation, i.e. it is below MAC and only works with LECIM
PHY. 

> Afterwards, the set of fragments is identified only through a 7 bit
> identifier assigned by the sender. In each consecutive fragment,
> only a 2 byte MAC header is included (3 bits frame type (= 110), 7
> bits frame ID, 6 bits frame counter). Extremely efficient in terms
> of overhead (e.g. MAC addresses are sent only during the context
> establishment), and particularly well adapted to infrastructure
> networks. Not sure if it would fit all 6TiSCH scenarios though.

It does not really work in general cases. The transaction id (TID) is
only 6 bits, and as there is no addresses, if two devices talking to
each other at the same time pick the same TID, this will mess up the
whole transaction for both. There was also lots of other things broken
in it... 
-- 
[email-masked]