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 PROTECTED] 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 PROTECTED] 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 PROTECTED] https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________ RSN mailing list
[EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________ 6lowpan mailing list
[email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
