Thanks a bunch Brian, 6MAN, then.
Pascal >-----Original Message----- >From: Brian Haberman [mailto:[EMAIL PROTECTED] >Sent: Thursday, November 29, 2007 5:32 PM >To: 6lowpan >Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter > >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 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 > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
