Subject: Re: [Roll] packet size issues

From: [email-masked]
Date: Thu, 10 Dec 2009 18:45:36 -0500

Hi all,

If the main concern about the packet size is what kind of payload that an 802.15.4 device can support; I would like to let everyone know that even though the current 802.15.4 device only can support a maximum packet length of 127 bytes, for the ongoing new standard 802.15.4g which is intended for smart utility network (SUN) applications, it does be able to support a maximum length of 1500 bytes. I would think that ROLL probably wants to be able to  support that as well.

Best Regards,

Kuor-Hsin Chang

----- Original Message -----
From: Matteo Paris [[email-masked]]
Sent: 12/10/2009 11:03 AM EST
To: [email-masked]
Subject: Re: [Roll] packet size issues

I agree that we should remove alignment requirements and reduce the 
suboption length field to 1 byte.

As Peter wrote, if RPL is to work over constrained link layers, we 
have to keep in mind the frame size and bandwidth constraints of 
those layers.  For example, in 802.15.4 after link-layer overhead, 
the usable payload is only 81 bytes (see RFC4944).

Because limited bandwidth and large dense networks are a common use 
case, it is desirable for a DIO message to fit in a single packet. 
The current size of a DIO message not including the DAG Metric 
Container is already 59 bytes (3 6lowpan ip header + 4 icmp header + 
20 base option + 25 dest prefix + 7 dag config).  Padding could 
increase this by tens of bytes.  If the DAG Metric Container is 
longer than 255 bytes I think it will pose serious challenges to RPL 
operation over constrained link layers.

Matteo

At 6:34 PM -0500 12/9/09, Tim Winter wrote:
>I agree with Peter that we should consider to remove alignment requirements-
>including the Pad1 and PadN options.  I would expect that it is often cheaper
>(energy/time/processing) to handle the alignment issues in the 
>implementation versus
>transporting extra padding over LLN links.
>
>The 16-bit sub-option length is driven by the DAG Metric Container. 
>Perhaps once we
>begin to see some proposed objective functions we can better 
>determine how large the
>Metric Container may need to be.  Perhaps the DAG Metric Container 
>could be chained
>such that each piece fits into 255 bytes or less...
>
>-Tim
>
>
>Joakim Eriksson wrote:
>>  Hi Peter,
>>
>>  I totally agree on the goal of minimizing packet sizes, but I would
>>  like to keep alignment requirements since it simplifies implementations.
>>  I also think (as you mention) that we need to question the 16-bit
>>  sub-option length. Is it really needed? Both IPv6 options and ICMPv6
>>  option lenghts are encoded as 8-bit values. Going down to 8-bits would
>>  also help the alignment of the options.
>>
>>
>>  Best Regards,
>>  -- Joakim Eriksson, SICS
>>
>>  Peter Siklosi skrev:
>>>  Hi all,
>>>
>>> 
>>>
>>>  If I understand correctly, RPL is designed to be usable with for
>>>  instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if
>>>  1280 byte IPv6 packets are of course supported using fragmentation,
>>>  large packets should be avoided at all cost given the low bandwidth
>>>  and low packet delivery success rate.
>>>
>>> 
>>>
>>>  Given this, I do not understand the alignment requirements specified
>>>  in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in
>>>  IPv6, these options are aligned in a packet such that multi-octet
>>>  values within the Option Data field of each option fall on natural
>>>  boundaries". It seems that it would be more important to keep the
>>>  messages short and avoid padding options. I am also curious on
>>>  allocating 16 bits for a length field of a sub option. If sub option
>>>  length exceeding 255 bytes (as could be specified by 8 bits) are
>>>  needed, it seems that the routing messages are expected to get very
>>>  large.
>>>
>>> 
>>>
>>>  Regards,
>>>  Peter Siklosi
>>>
>>> 
>>>
>>>
>>>  ------------------------------------------------------------------------
>>>
>>>  _______________________________________________
>>>  Roll mailing list
>>>  [email-masked]
>>>  https://www.ietf.org/mailman/listinfo/roll
>>
>>  _______________________________________________
>>  Roll mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/roll
>>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

______________________________________________________________________
This email has been spam and virus checked by Elster IT Services.