Subject: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Nov 2007 14:10:34 +0100

Hi JP:

Thanks a bunch for this charter. I'll try not to rephrase what was already discussed with Christian, Anders, Philip and Misha. 

There's an additional item I'd wish to see either in ROLL or 6LoWPAN and I do not know exactly where it belongs, maybe both. The question is whether we need to and can document how RFC 4294 applies for sensors, and M2M devices in general, whether they act as hosts or as routers. 

I've seen IPv6 presented as a Pandora box that drags just too much stuff to be incorporated in a sensory device. For instance, at the moment, SP100.11a endorses 6LoWPAN formats but it's not so clear at all that IPv6 itself is mandated. A clear spec with well-documented implementation could be a formidable tool to despond to Fear, Uncertainty and Defiance.

So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do without multicast at all if ND is supported some other way (such as suggested in: http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.txt). Maybe NULL encryption and authentication is enough etc, etc...
 
Being able to define one minimum set and maybe a few other profiles for the use cases that we selected could help tremendously. 

Otherwise I find the charter real well written and easy to digest. From the MANEMO experience, I expect that some arguments about the relative applicability of existing MANET protocols will be difficult to prove without some good simulation work running agreed-upon scenarios.

Finally, I'm a bit confused that it seems that both IPv4 and IPv6 seem supported. Ipv4 comes with a lot of overhead like DHCP. I suggest that when trouble comes and things can not be done in a common fashion for both IP protocols, hen we prioritize IPv6.

Unfortunately, I can not make it to Vancouver, but I do feel that the work is really needed so please count my vote in for the adoption of the WG.

Cheers,

Pascal

>-----Original Message-----
>From: Jean Philippe Vasseur (jvasseur)
>Sent: Wednesday, November 21, 2007 9:19 PM
>To: [email-masked]
>Subject: [RSN] Here is the new RL2N Proposed Working Charter
>
>Dear all,
>
>As promised, here is the new proposed Working Group, which reflects the
>number of comments/suggestions that we received, the pre-WG consensus, ...
>
>Thanks to Dave Ward (RTD AD) for his input.
>
>Proposed RL2N WG Charter
>
>Description of Working Group
>
>L2Ns (Low power and Lossy networks) are typically composed of many embedded
>devices with limited power, memory, and processing resources interconnected
>by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power
>WiFi.
>
>L2Ns are transitioning to an end-to-end IP-based solution to avoid the
>problems of non-interoperable networks interconnected by protocol
>translation gateways and proxies. In addition, L2Ns have specific routing
>requirements that are not currently met by existing routing protocols, such
>as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed to take
>into consideration the specific power, capabilities, attributes and
>functional characteristics of the links and nodes in the network.
>
>
>There is a wide scope of application areas for L2Ns, including industrial
>monitoring, building automation (HVAC, lighting/access control), connected
>home, healthcare, environmental monitoring, agricultural, smart cities,
>logistics, assets tracking, and refrigeration. The L2N WG will focus on
>routing solutions for a subset of these deployment scenarios, namely
>industrial, connected home/building and urban applications. The Working
>Group will determine the routing requirements for these scenarios.
>
>
>The Working Group will provide a routing framework for these application
>scenarios that provides high reliability in the presence of time varying
>loss characteristics and connectivity while permitting low-power operation
>with very modest memory and CPU pressure.
>
>
>The Working Group will pay a particular attention to routing security and
>manageability (e.g self managing/configuration) issues, which are
>particularly critical for L2Ns.
>
>Work Items:
>
>- Produce use cases documents for Industrial, Connected Home, Building and
>urban application networks. Each document will describe the use case and the
>associated routing protocol requirements. The documents will progress in
>collaboration with the 6lowpan Working Group (INT area).
>
>
>- Survey the applicability of existing protocols to L2Ns. The aim of this
>document will be to analyze the scaling and characteristics of existing
>protocols and identify whether or not they meet the routing requirements of
>the L2Ns applications identified above. Existing IGPs, MANET, NEMO, DTN
>routing protocols will be part of evaluation.
>
>- Specification of routing metrics used in path calculation. This includes
>static and dynamic link/nodes attributes required for routing in L2Ns.
>
>- Provide an architectural framework for routing and path selection at Layer
>3 (Routing for L2N Architecture)
>* Decide whether the L2Ns routing protocol require a distributed,
>centralized path computation models or both.
>* Decide whether the L2N routing protocol requires a hierarchical routing
>approach.
>
>- Produce a security framework for routing in L2Ns.
>
>Goals And Milestones:
>
>
>April 2008 Submit Use case/Routing requirements for Industrial, Connected
>Home, Building and Urban networks applications to the IESG to be considered
>as an Informational RFC.
>
>August 2008: Submit Routing metrics for L2Ns document to the IESG to be
>considered as an Informational RFC.
>
>September 2008: Submit first draft of the Routing for L2Ns Architecture
>document  (summary of requirements, path computation model,
>flat/hierarchy,Š).
>
>November 2008: Submit Protocol Survey to the IESG to be considered as an
>Informational RFC.
>
>January 2009 Submit Security Framework for L2Ns to the IESG to be considered
>as an Informational RFC
>
>February 2009: Submit the Routing for L2Ns Architecture document  (summary
>of requirements, metrics and attributes, path selection model) to the IESG
>as an Informational RFC.
>
>March 2009: Recharter.
>
>
>Please comment/suggest/...
>
>See you in Vancouver.
>
>JP and David.
>
>
>_______________________________________________
>RSN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rsn

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: JP Vasseur <[email-masked]>
Date: Wed, 28 Nov 2007 08:29:48 -0500

Hi Pascal,

Thanks for the feed-back and support - in line,

> From: "Pascal Thubert (pthubert)" <[email-masked]>
> Date: Wed, 28 Nov 2007 08:10:34 -0500
> To: "Jean Philippe Vasseur (jvasseur)" <[email-masked]>
> Cc: <[email-masked]>, 6lowpan <[email-masked]>
> Conversation: [RSN] Here is the new RL2N Proposed Working Charter
> Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter
> 
> Hi JP:
> 
> Thanks a bunch for this charter. I'll try not to rephrase what was already
> discussed with Christian, Anders, Philip and Misha.
> 
> There's an additional item I'd wish to see either in ROLL or 6LoWPAN and I do
> not know exactly where it belongs, maybe both. The question is whether we need
> to and can document how RFC 4294 applies for sensors, and M2M devices in
> general, whether they act as hosts or as routers.
> 
> I've seen IPv6 presented as a Pandora box that drags just too much stuff to be
> incorporated in a sensory device. For instance, at the moment, SP100.11a
> endorses 6LoWPAN formats but it's not so clear at all that IPv6 itself is
> mandated. A clear spec with well-documented implementation could be a
> formidable tool to despond to Fear, Uncertainty and Defiance.
> 
> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do without
> multicast at all if ND is supported some other way (such as suggested in:
> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.tx
> t). Maybe NULL encryption and authentication is enough etc, etc...
>  
> Being able to define one minimum set and maybe a few other profiles for the
> use cases that we selected could help tremendously.

I cannot agree more but this certainly belongs more to 6lowpan if they want
to work on this item. If a RL2N WG gets formed, we should contribute to this
work for the routing aspects.

> 
> Otherwise I find the charter real well written and easy to digest. From the
> MANEMO experience, I expect that some arguments about the relative
> applicability of existing MANET protocols will be difficult to prove without
> some good simulation work running agreed-upon scenarios.

This is indeed a key work item. The work has started in the protocol
overview draft (still more work is undoubtedly required).

> 
> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 seem
> supported. Ipv4 comes with a lot of overhead like DHCP. I suggest that when
> trouble comes and things can not be done in a common fashion for both IP
> protocols, hen we prioritize IPv6.
> 

It is indeed important to have a RL2N solution for both v4 *and* v6, I do
not think that we should try to "prioritize" between the two.

> Unfortunately, I can not make it to Vancouver,

Too bad ... But should a WG be formed, I hope that we'll have you contribute
to this work.

but I do feel that the work is
> really needed so please count my vote in for the adoption of the WG.

Will do.

Thanks.

JP.

---

From: Kris Pister <[email-masked]>
Date: Wed, 28 Nov 2007 08:42:08 -0800

Is there an email thread somewhere that discusses the impact on 6LoWPAN 
of the security requirements of 4294 and 4303?
My first quick readthrough makes me very uncomfortable that some of the 
mandates are going to be ugly from a header standpoint.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Nov 2007 18:44:38 +0100

Hi Kris:

For your question on ESP, AFAIK, RFC 4294 only mandates NULL encryption and authentication for interoperability reasons. 

On the general question of RFC 4294 itself: I'm not sure the work was ever done. I hope someone from the list can help?

If the answer is unclear, and considering that we are re-chartering the group, maybe we could have a work item to specify the instantiation of RFC 4294 for LoWPAN nodes?

Pascal
________________________________________
From: Kris Pister [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2007 5:42 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan
Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter

Is there an email thread somewhere that discusses the impact on 6LoWPAN of the security requirements of 4294 and 4303?
My first quick readthrough makes me very uncomfortable that some of the mandates are going to be ugly from a header standpoint.

ksjp

 

Cheers,

Pascal

-----Original Message-----
From: Jean Philippe Vasseur (jvasseur)
Sent: Wednesday, November 21, 2007 9:19 PM
To: [email-masked]
Subject: [RSN] Here is the new RL2N Proposed Working Charter

Dear all,

Proposed RL2N WG Charter

Work Items:

Goals And Milestones:

March 2009: Recharter.

See you in Vancouver.

JP and David.

---

From: Kris Pister <[email-masked]>
Date: Wed, 28 Nov 2007 11:02:34 -0800

Hmm.  From 4294:

"However, while authentication and encryption can each be NULL, they 
MUST NOT both be NULL."

ksjp

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Nov 2007 21:05:44 +0100

> "However, while authentication and encryption can each be NULL, they  

This does not surprise me that much.
Why would you want to expend the overhead of an ESP encapsulation to  
provide no security whatsoever?

Gruesse, Carsten

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 29 Nov 2007 11:28:42 +0900

Dear Pascal and JP,

I'm very happy to see the same thought of me on RFC 4294.
I agree on JP that this work is more on 6LoWPAN in general
and RL2N (or ROLL - I like this idea ^^) can check it in routing
perspective, if any.

I once discussed with Carsten about the necessity of this issue.
I've discussed this matter with some other Korean developers from
sensor node companies. We quite agreed on the necessity, and I and my
colleagues already proposed this work as korean domestic standard
first. The proposal has been accepted, and korean experts will start
to discuss it more to develop domestic standard. It must be great if
we can discuss it with IETF experts as well.

Pascal, I think it would be good if we can check each other's
profiling and collaborate to make one profile based on them. :)

-eunsook "eunah" kim

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Nov 2007 16:09:49 +0100

Hum... 

I had missed that; Seems that we have to make an exception :) If you consider ISA100.11a, they already have security at L2 and L5, it makes little sense to MUST IPSec on top of that.

Pascal

>Sent: Wednesday, November 28, 2007 8:03 PM
>> If the answer is unclear, and considering that we are re-chartering the group, maybe we could have
>a work item to specify the instantiation of RFC 4294 for LoWPAN nodes?
>>
>> Pascal
>> There's an additional item I'd wish to see either in ROLL or 6LoWPAN and I do not know exactly
>where it belongs, maybe both. The question is whether we need to and can document how RFC 4294
>applies for sensors, and M2M devices in general, whether they act as hosts or as routers.
>>
>> I've seen IPv6 presented as a Pandora box that drags just too much stuff to be incorporated in a
>sensory device. For instance, at the moment, SP100.11a endorses 6LoWPAN formats but it's not so clear
>at all that IPv6 itself is mandated. A clear spec with well-documented implementation could be a
>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do without multicast at all if ND is
>supported some other way (such as suggested in: http://www.ietf.org/internet-drafts/draft-thubert-
>lowpan-backbone-router-00.txt). Maybe NULL encryption and authentication is enough etc, etc...
>>
>> Otherwise I find the charter real well written and easy to digest. >From the MANEMO experience, I
>expect that some arguments about the relative applicability of existing MANET protocols will be
>difficult to prove without some good simulation work running agreed-upon scenarios.
>>
>> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 seem supported. Ipv4 comes with a
>lot of overhead like DHCP. I suggest that when trouble comes and things can not be done in a common
>fashion for both IP protocols, hen we prioritize IPv6.
>>
>> Unfortunately, I can not make it to Vancouver, but I do feel that the work is really needed so
>please count my vote in for the adoption of the WG.
>>
>> Cheers,
>>
>> Pascal
>>
>>

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 29 Nov 2007 08:52:08 -0700

We have already received an exception from the IESG to IPsec on 6lowpan
devices.

	geoff

On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote:
> >> Otherwise I find the charter real well written and easy to digest. >>From the MANEMO experience, I

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Nov 2007 11:31:37 -0500

Pascal,
      There will be a presentation in 6MAN on a possible update to 4294 
to address other changes in the standards.  I would encourage people 
interested in including sensor-like devices in such an update to bring 
the topic up either in the 6MAN meeting in Vancouver, on the 6MAN 
mailing list, or to the author of 4294 (John Loughney).

Regards,
Brian

Pascal Thubert (pthubert) wrote:
> Hi Kris:
> 
> For your question on ESP, AFAIK, RFC 4294 only mandates NULL
> encryption and authentication for interoperability reasons.
> 
> On the general question of RFC 4294 itself: I'm not sure the work was
> ever done. I hope someone from the list can help?
> 
> If the answer is unclear, and considering that we are re-chartering
> the group, maybe we could have a work item to specify the
> instantiation of RFC 4294 for LoWPAN nodes?
> 
> Pascal ________________________________________ From: Kris Pister
> [mailto:[email-masked]] Sent: Wednesday, November 28, 2007
> 5:42 PM To: Pascal Thubert (pthubert) Cc: 6lowpan Subject: Re: [RSN]
> Here is the new RL2N Proposed Working Charter
> 
> Is there an email thread somewhere that discusses the impact on
> 6LoWPAN of the security requirements of 4294 and 4303? My first quick
> readthrough makes me very uncomfortable that some of the mandates are
> going to be ugly from a header standpoint.
> 
> ksjp
> 
> Pascal Thubert (pthubert) wrote: Hi JP:
> 
> Thanks a bunch for this charter. I'll try not to rephrase what was
> already discussed with Christian, Anders, Philip and Misha.
> 
> There's an additional item I'd wish to see either in ROLL or 6LoWPAN
> and I do not know exactly where it belongs, maybe both. The question
> is whether we need to and can document how RFC 4294 applies for
> sensors, and M2M devices in general, whether they act as hosts or as
> routers.
> 
> I've seen IPv6 presented as a Pandora box that drags just too much
> stuff to be incorporated in a sensory device. For instance, at the
> moment, SP100.11a endorses 6LoWPAN formats but it's not so clear at
> all that IPv6 itself is mandated. A clear spec with well-documented
> implementation could be a formidable tool to despond to Fear,
> Uncertainty and Defiance.
> 
> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do
> without multicast at all if ND is supported some other way (such as
> suggested in:
> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.txt).
> Maybe NULL encryption and authentication is enough etc, etc...
> 
> Being able to define one minimum set and maybe a few other profiles
> for the use cases that we selected could help tremendously.
> 
> Otherwise I find the charter real well written and easy to digest.
> From the MANEMO experience, I expect that some arguments about the
> relative applicability of existing MANET protocols will be difficult
> to prove without some good simulation work running agreed-upon
> scenarios.
> 
> Finally, I'm a bit confused that it seems that both IPv4 and IPv6
> seem supported. Ipv4 comes with a lot of overhead like DHCP. I
> suggest that when trouble comes and things can not be done in a
> common fashion for both IP protocols, hen we prioritize IPv6.
> 
> Unfortunately, I can not make it to Vancouver, but I do feel that the
> work is really needed so please count my vote in for the adoption of
> the WG.
> 
> Cheers,
> 
> Pascal
> 
> 
> -----Original Message----- From: Jean Philippe Vasseur (jvasseur) 
> Sent: Wednesday, November 21, 2007 9:19 PM To: [email-masked] Subject:
> [RSN] Here is the new RL2N Proposed Working Charter
> 
> Dear all,
> 
> As promised, here is the new proposed Working Group, which reflects
> the number of comments/suggestions that we received, the pre-WG
> consensus, ...
> 
> L2Ns (Low power and Lossy networks) are typically composed of many
> embedded devices with limited power, memory, and processing resources
> interconnected by a variety of wireless links, such as IEEE 802.15.4,
> Bluetooth, Low Power WiFi.
> 
> L2Ns are transitioning to an end-to-end IP-based solution to avoid
> the problems of non-interoperable networks interconnected by protocol
>  translation gateways and proxies. In addition, L2Ns have specific
> routing requirements that are not currently met by existing routing
> protocols, such as OSPF, IS-IS, AODV, and OLSR. L2N path selection
> must be designed to take into consideration the specific power,
> capabilities, attributes and functional characteristics of the links
> and nodes in the network.
> 
> 
> There is a wide scope of application areas for L2Ns, including
> industrial monitoring, building automation (HVAC, lighting/access
> control), connected home, healthcare, environmental monitoring,
> agricultural, smart cities, logistics, assets tracking, and
> refrigeration. The L2N WG will focus on routing solutions for a
> subset of these deployment scenarios, namely industrial, connected
> home/building and urban applications. The Working Group will
> determine the routing requirements for these scenarios.
> 
> 
> The Working Group will provide a routing framework for these
> application scenarios that provides high reliability in the presence
> of time varying loss characteristics and connectivity while
> permitting low-power operation with very modest memory and CPU
> pressure.
> 
> 
> The Working Group will pay a particular attention to routing security
> and manageability (e.g self managing/configuration) issues, which are
> - Produce use cases documents for Industrial, Connected Home,
> Building and urban application networks. Each document will describe
> the use case and the associated routing protocol requirements. The
> documents will progress in collaboration with the 6lowpan Working
> Group (INT area).
> 
> 
> - Survey the applicability of existing protocols to L2Ns. The aim of
> this document will be to analyze the scaling and characteristics of
> existing protocols and identify whether or not they meet the routing
> requirements of the L2Ns applications identified above. Existing
> IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation.
> 
> - Specification of routing metrics used in path calculation. This
> includes static and dynamic link/nodes attributes required for
> routing in L2Ns.
> 
> - Provide an architectural framework for routing and path selection
> at Layer 3 (Routing for L2N Architecture) * Decide whether the L2Ns
> routing protocol require a distributed, centralized path computation
> models or both. * Decide whether the L2N routing protocol requires a
> hierarchical routing approach.
> 
> April 2008 Submit Use case/Routing requirements for Industrial,
> Connected Home, Building and Urban networks applications to the IESG
> to be considered as an Informational RFC.
> 
> August 2008: Submit Routing metrics for L2Ns document to the IESG to
> be considered as an Informational RFC.
> 
> September 2008: Submit first draft of the Routing for L2Ns
> Architecture document  (summary of requirements, path computation
> model, flat/hierarchy,Š).
> 
> November 2008: Submit Protocol Survey to the IESG to be considered as
> an Informational RFC.
> 
> January 2009 Submit Security Framework for L2Ns to the IESG to be
> considered as an Informational RFC
> 
> February 2009: Submit the Routing for L2Ns Architecture document
> (summary of requirements, metrics and attributes, path selection
> model) to the IESG as an Informational RFC.
> 
> March 2009: Recharter.
> 
> 
> _______________________________________________ RSN mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/rsn
> 
> 
> 
> _______________________________________________ RSN mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/rsn
> 
> 
> _______________________________________________ 6lowpan mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 29 Nov 2007 10:09:43 -0700

So people don't need to look it up, 6man is meeting Wednesday morning
Session 1.

	geoff

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Nov 2007 18:35:02 +0100

Thanks a bunch Brian,

6MAN, then.

Pascal

>From: Brian Haberman [mailto:[email-masked]]
>Sent: Thursday, November 29, 2007 5:32 PM
>To: 6lowpan
>Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter
>
>Pascal,

---

From: Kris Pister <[email-masked]>
Date: Thu, 29 Nov 2007 10:59:47 -0800

Geoff - ooh, I like exceptions.
Did we try to get an exception on the UDP checksum?  It's painful to 
leave that in the compressed header if we have L2 message integrity.

ksjp

Geoff Mulligan wrote:
>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL encryption and authentication for
>>>>         
>>> interoperability reasons.
>>>       
>>>> On the general question of RFC 4294 itself: I'm not sure the work was ever done. I hope someone
>>>>         
>> >from the list can help?
>>     
>>>> Is there an email thread somewhere that discusses the impact on 6LoWPAN of the security
>>>>         
>>> requirements of 4294 and 4303?
>>>       
>>>> My first quick readthrough makes me very uncomfortable that some of the mandates are going to be
>>>>         
>>> ugly from a header standpoint.
>>>       
>>>> ksjp
>>>>
>>>> Thanks a bunch for this charter. I'll try not to rephrase what was already discussed with Christian,
>>>>         
>>> Anders, Philip and Misha.
>>>       
>>>> Being able to define one minimum set and maybe a few other profiles for the use cases that we
>>>>         
>>> selected could help tremendously.
>>>

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 29 Nov 2007 11:06:32 -0800

Note that L2 message integrity doesn't provide end-to-end message 
integrity, which L4 checksums (that cover the L3 header) provide.

--
Jonathan Hui

Kris Pister wrote:
>>> I had missed that; Seems that we have to make an exception :) If you 
>>> consider ISA100.11a, they already have security at L2 and L5, it 
>>> makes little sense to MUST IPSec on top of that.
>>>
>>> Pascal
>>>
>>>    
>>>>> encryption and authentication for
>>>>>         
>>>>> the group, maybe we could have
>>>>>         
>>>>> 6LoWPAN of the security
>>>>> already discussed with Christian,
>>>>>         
>>>>> stuff to be incorporated in a
>>>>>         
>>>> at all that IPv6 itself is mandated. A clear spec with 
>>>> well-documented implementation could be a
>>>>> without multicast at all if ND is
>>>>>         
>>>> supported some other way (such as suggested in: 
>>>> http://www.ietf.org/internet-drafts/draft-thubert-
>>>>> for the use cases that we
>>>>>         
>>>>> >>From the MANEMO experience, I
>>>>>         
>>>>> seem supported. Ipv4 comes with a
>>>>>         
>>>>> the
>>>>> embedded
>>>>> routing
>>>>> industrial
>>>>> application
>>>>> Building and
>>>>> includes
>>>>> at Layer
>>>>> Connected
>>>>> Architecture
>>>>> (summary

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 29 Nov 2007 12:09:02 -0700

We did not try to get an exception to UDP checksums.

	geoff