Hi Pascal, Thanks for the feed-back and support - in line,
> From: "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> > Date: Wed, 28 Nov 2007 08:10:34 -0500 > To: "Jean Philippe Vasseur (jvasseur)" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>, 6lowpan <[EMAIL PROTECTED]> > 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. > > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
