I think your text below makes sense, and see no problem adding it, unless there's heated objection.
In general, though, this 1280 byte number is just thrown in to say that we comply with IPv6
requirements. Having enough buffer space for such large packets does not make it a good idea to
throw them around a LoWPAN network. Nor does having insufficient buffer space mean that such
a device won't be able to participate in a LoWPAN network, given that judicious applications
better NOT use such large packets anyhow.
I guess the upcoming document on application best practices (if we ever finish our current
docs and recharter) can offer advice in this regard.
-gabriel
----- Original Message ----
From: Philip Levis <[EMAIL PROTECTED]>
To: Samita Chakrabarti <[EMAIL PROTECTED]>
Cc: 6lowpan <[email protected]>
Sent: Friday, July 21, 2006 11:59:34 AM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document
From: Philip Levis <[EMAIL PROTECTED]>
To: Samita Chakrabarti <[EMAIL PROTECTED]>
Cc: 6lowpan <[email protected]>
Sent: Friday, July 21, 2006 11:59:34 AM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document
On Jul 20, 2006, at 8:05 PM, Samita Chakrabarti wrote:
> On 7/20/06, Philip Levis <[EMAIL PROTECTED]> wrote:
>> You can totally write an IP stack -- even a TCP stack -- on sensor
>> nodes today, admittedly the ones that have the biggest
>> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP
>> stack might not have a lot of RAM for windowing and high performance,
>> but that's rarely the goal. You can do it.
>>
>> I don't think the requirements the document implies are unrealistic
>> or onerous. As I said, you have to cut the line somewhere. My comment
>> was just that they *do* preclude smaller nodes whose storage cannot
>> hold a complete IPv6 packet, and it might be useful to note as such,
>> since the document is defining the problem statement, and therefore
>> the problem scope.
>>
>
> Your point is valid. Though IMHO, drawing a strict line on non-
> applicability
> on low RAM devices may not be wise.
Of course; it would be counter-productive for the document to say
"this means IPv6 cannot be implemented on hardware XYZ," as the
future and some interesting techniques might show such a hard
statement to be wrong. Rather, something such as "IPv6's requirement
of sub-IP reassembly may pose challenges for low-end LowPAN devices
that do not have enough RAM or storage for a 1280-octet packet."
But anyways. Sounds like I've beaten this horse to death.
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
> On 7/20/06, Philip Levis <[EMAIL PROTECTED]> wrote:
>> You can totally write an IP stack -- even a TCP stack -- on sensor
>> nodes today, admittedly the ones that have the biggest
>> microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP
>> stack might not have a lot of RAM for windowing and high performance,
>> but that's rarely the goal. You can do it.
>>
>> I don't think the requirements the document implies are unrealistic
>> or onerous. As I said, you have to cut the line somewhere. My comment
>> was just that they *do* preclude smaller nodes whose storage cannot
>> hold a complete IPv6 packet, and it might be useful to note as such,
>> since the document is defining the problem statement, and therefore
>> the problem scope.
>>
>
> Your point is valid. Though IMHO, drawing a strict line on non-
> applicability
> on low RAM devices may not be wise.
Of course; it would be counter-productive for the document to say
"this means IPv6 cannot be implemented on hardware XYZ," as the
future and some interesting techniques might show such a hard
statement to be wrong. Rather, something such as "IPv6's requirement
of sub-IP reassembly may pose challenges for low-end LowPAN devices
that do not have enough RAM or storage for a 1280-octet packet."
But anyways. Sounds like I've beaten this horse to death.
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
