Hi Mark, As Carles mentioned, and as already ROLL chairs replied, ROLL is not considering L2 "route-under". I don't want to debate the preference and benefits between 'route-over' and 'mesh-under'. Just want to mention that the current document was written based on the necessity to check if 6LOWPAN has its own specific routing requitments or not. As I remember, 71th meeting discussed to make 6LoWPAN RR work with a tight alignment with ROLL, avoiding duplicate work, and I believe that -05 is handling well on this matter.
At this stage it may be too early to answer if mesh-under related issues of 6LoWPAN don't need to be studied when route-over is provided, since only 3 application specific requirements drafts are available from ROLL so far. I think that this work is related to the current mesh-under ND. Before route-over becomes very clear, we can study in pararell. We can, later, provide mesh-under as informational or just give some issues as an input to route-over. To see this, I think we need to study more, meaning we need this item alive. Thanks, -eunah On 5/27/08, Carles Gomez Montenegro <[EMAIL PROTECTED]> wrote: > Hi Mark, > > I would like to answer to one of the questions you raised regarding the > mesh-under Vs. route-over paradigms. > > > Is there anything that the L3 > > "route-over" model might not provide that is listed as a requirement for > > 6lowpan's "route-under" model? > > At least, there are the following items listed in the routing requirements > draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) > that route-over approach cannot provide or would provide only in a limited > way: > > - [R03] (use of 802.15.4 link layer feedback for power efficient operation) > - [R05] (use of mesh-under neighbor discovery for 6LoWPAN) > - [R06] (use of 802.15.4 beacons to deal with hibernating/unresponsive nodes) > - [R09] (about exploiting 802.15.4 join/leave messages) > - [R11] (on applying security mechanisms of 802.15.4 for securing the > routing protocol). > - [R12] (802.15.4 constraint on message sizes due to its small MTU) > - [R13] (on using 802.15.4 link layer feedback for link connectivity > maintenance) > - [R14] (on taking advantage of the LQI parameter, which is very critical > in routing decisions in 802.15.4 environments) > > In my opinion, the "routing link and node metric" ROLL item can only > partially capture some of the specificities that may affect routing in > 802.15.4 environments. Even if LQI parameter can be provided from 802.15.4 > to layer three, all the specific 802.15.4 features (see the list above) > can only be fully exploited following a mesh-under approach. Hence, in my > opinion, routing decisions and efficiency of routing protocol operation > within a LoWPAN would be seriously limited if a route-over approach was > followed. > > Thanks, > > Carles > > > > > > > > > > > > > > > Eunsook "Eunah" Kim wrote: > >> Dear AD, and chairmen, > >> > >> It's good to finally see official rechater text. > >> > > It's only proposed text. > >> I think it's pretty well delivering our discussion of rechartering so > >> far, EXCEPT one part; 6lowpan routing requirement. > >> Last meeting (71th IETF), we discussed RR matter and agreed to see > >> IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember > >> correctly, we would keep this work with alignment with ROLL, as long > >> as it's not duplicate work with ROLL. > >> > > You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what > > are your expectations from 6lowpan with respect to the > > routing-requirements document? > > > > http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt > > > > I have some more questions for you specifically: > > > > Should that be pulled into roll, or left in 6lowpan? Is roll considering > > the L2"route-under" model at all? Is there anything that the L3 > > "route-over" model might not provide that is listed as a requirement for > > 6lowpan's "route-under" model? If 6lowpan were to work on an L2 > > "route-under" model, would there be constructs (e.g., the routing > > protocol itself and any low-power modifications) from ROLL that we would > > invariably want to try and reuse? > >> I would like to know if it is implied that the RR work is included in > >> Architecture work, OR, if you have *intentionally* excluded the work. > >> > >> If the first case, I would suggest 6LoWPANers check the updated > >> version (-05) of draft. We updated our RR draft (-05) after the > >> meeting based on the meeting discussion, and circulated to the mailing > >> list. > >> > >> If the second case, I think we should get a chance to discuss the > >> updated version. If the meeting decide the fate of this work after > >> that, I would accept it. However, I have problem if AD or chairmen > >> simply exclude this item without such discussion and concensus > >> > > There has never been any intention to go against consensus or limit > > discussion on this topic. So, let's use this thread to get to the bottom > > of what we want to do as a group here. > > > > - Mark > >> Would you please clarify it to me? > >> > >> Thanks, > >> > >> -eunah > >> > >> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley <[EMAIL PROTECTED]> > >> wrote: > >> > >>> I'd like to ask the group one final time for comments on the proposed > >>> new > >>> charter. I've also asked the ROLL WG chairs to comment. > >>> > >>> As I said before, soon after the format document was published, there > >>> is > >>> nothing stopping the WG from discussing and working on new and existing > >>> items at this time. In fact, activity helps us to decide what should be > >>> in > >>> and out of the charter. Please do not construe not having a charter in > >>> place > >>> as a reason not to update drafts, or discuss topics that need to be > >>> discussed. Just as when we have BoF's and mailing lists before creating > >>> a > >>> new WG, it is good to have WG meetings and on-lists discussions when > >>> creating new WG charters. > >>> > >>> - Mark > >>> > >>> > >>> > >>> > >>> > >>> > >>> Background/Introduction: > >>> > >>> Note: Given that there is not much precedent for this type of activity > >>> at the IETF, the text that follows is of an introductory > >>> nature. Hence, its objective is to give a general idea of the > >>> application area and motivations for the work. In particular, this > >>> section is not to be construed as detailing work items for the working > >>> group. That is done in the following section entitled "Scope of the > >>> Working Group." > >>> > >>> Well-established fields such as control networks, and burgeoning ones > >>> such as "sensor" (or transducer) networks, are increasingly being > >>> based on wireless technologies. Most (but certainly not all) of these > >>> nodes are amongst the most constrained that have ever been networked > >>> wirelessly. Extreme low power (such that they will run potentially for > >>> years on batteries) and extreme low cost (total device cost in single > >>> digit dollars, and riding Moore's law to continuously reduce that > >>> price point) are seen as essential enablers towards their deployment > >>> in networks with the following characteristics: > >>> > >>> * Significantly more devices than current networks > >>> > >>> * Severely limited code and ram space (e.g., highly desirable to > >>> fit the required code--MAC, IP and anything else needed to > >>> execute the embedded application-- in, for example, 32K of flash > >>> memory, using 8-bit microprocessors) > >>> > >>> * Unobtrusive but very different user interface for configuration > >>> (e.g., using gestures or interactions involving the physical > >>> world) > >>> > >>> * Robustness and simplicity in routing or network fabric > >>> > >>> A chief component of these devices is wireless communication > >>> technology. In particular, the IEEE 802.15.4 standard is very > >>> promising for the lower (physical and link) layers. As for higher > >>> layer functions, there is considerable interest from non-IETF groups > >>> in using IP technology (the ZigBee alliance, for example, is currently > >>> studying what such a work item might entail). The working group is > >>> expected to coordinate and interact with such groups. > >>> > >>> The required work includes items in the following (incomplete) list: > >>> > >>> * IP adaptation/Packet Formats and interoperability > >>> * Addressing schemes and address management > >>> * Network management > >>> * Routing in dynamically adaptive topologies > >>> * Security, including set-up and maintenance > >>> * Application programming interface > >>> * Discovery (of devices, of services, etc) > >>> * Implementation considerations > >>> > >>> Whereas at least some of the above items are within the purview of the > >>> IETF, at this point it is not clear that all of them are. Accordingly, > >>> the 6LoWPAN working group will address a reduced, more focused set of > >>> objectives. > >>> > >>> Scope of 6lowpan: > >>> > >>> Produce "Problems Statement, Assumptions and Goals for IPv6 for > >>> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the > >>> problem statement and goals of 6lowpan networks. > >>> > >>> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN > >>> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the > >>> basic packet formats and sub-IP adaptation layer for transmission of > >>> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, > >>> header compression and address generation. Furthermore, IEEE 802.15.4 > >>> devices are expected to be deployed in mesh topologies. > >>> > >>> As such, the working group may also work on an informational document > >>> to show how to apply an existing MANET protocol to LoWPANs (e.g., > >>> AODV, OLSR, DYMO, etc). > >>> > >>> The working group will reuse existing specifications whenever > >>> reasonable and possible. > >>> > >>> The working group will also serve as a venue for ongoing discussions > >>> on other topics related to the more complete list outlined above. > >>> Additional related milestones may be added in the future via a > >>> rechartering operation. > >>> > >>> Note: As may be obvious from its official name above, this particular > >>> working group will not work on IPv4 over IEEE 802.15.4 specifications. > >>> Given the limitations of the target devices, dual-stack deployments > >>> are not practical. Because of its higher potential for header > >>> compression, its support for the huge number of devices expected and > >>> of cleanly built-in features such as address autoconfiguration, IPv6 > >>> is the exclusive focus of the working group. > >>> Goals and Milestones: > >>> Done Working group last call on > >>> draft-ietf-lowpan-goals-assumptions-xx.txt > >>> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to > >>> IESG > >>> for consideration of publication as Informational > >>> Done Working Group Last Call on > >>> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt > >>> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to > >>> IESG > >>> for consideration of publication as Proposed Standard > >>> > >>> > >>> > >>> Background/Introduction: > >>> > >>> Note: Given that there is not much precedent for this type of activity > >>> at the IETF, the text that follows is of an introductory > >>> nature. Hence, its objective is to give a general idea of the > >>> application area and motivations for the work. In particular, this > >>> section is not to be construed as detailing work items for the working > >>> group. That is done in the following section entitled "Scope of the > >>> Working Group." > >>> > >>> Well-established fields such as control networks, and burgeoning ones > >>> such as "sensor" (or transducer) networks, are increasingly being > >>> based on wireless technologies. Most (but certainly not all) of these > >>> nodes are amongst the most constrained that have ever been networked > >>> wirelessly. Extreme low power (such that they will run potentially for > >>> years on batteries) and extreme low cost (total device cost in single > >>> digit dollars, and riding Moore's law to continuously reduce that > >>> price point) are seen as essential enablers towards their deployment > >>> in networks with the following characteristics: > >>> > >>> * Significantly more devices than current local area networks > >>> > >>> * Severely limited code and ram space (e.g., highly desirable to fit > >>> the required code--MAC, IP and anything else needed to execute the > >>> embedded application-- in, for example, 32K of flash memory, using > >>> 8-bit microprocessors) > >>> > >>> * Unobtrusive but very different user interface for configuration > >>> (e.g., using gestures or interactions involving the physical world) > >>> > >>> A chief component of these devices is wireless communication > >>> technology. In particular, the IEEE 802.15.4 standard is very > >>> promising for the lower (physical and link) layers. As for higher > >>> layer functions, there is considerable interest from non-IETF groups > >>> in using IP technology. The IEEE 1451.5 standard for wireless > >>> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for > >>> wireless industrial networks has adopted 6LoWPAN for their network > >>> layer. This working group is expected to coordinate and interact with > >>> such groups. > >>> > >>> Description of Working Group: > >>> > >>> The working group has completed two RFCs: "IPv6 over Low-Power > >>> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, > >>> Problem Statement, and Goals" (RFC4919) that documents and discusses > >>> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 > >>> Networks" (RFC4944) which defines the format for the adaptation > >>> between IPv6 and 802.15.4. > >>> > >>> The Working Group will generate the necessary documents to enusre > >>> interoperable implementations of 6LoWPAN networks and will define the > >>> necessary security and management protocols and constructs for build > >>> 6LoWPAN networks, paying particular attention to protocols already > >>> available. > >>> > >>> Work Items: > >>> > >>> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" > >>> to define the required optimizations to make IPv6 ND applicable in > >>> 6lowpans, given the fact that IPv6 ND is too expensive for the devices > >>> of 6lowpan and requires multicast. > >>> > >>> This document (or these documents - as the working group delves into > >>> this topic it may determine that this should be two separate > >>> documents) will define how to bootstrap a 6lowpan network and explore > >>> ND optimizations such as reusing the 802.15.4 network structure (use > >>> the coordinators), and obviate multicast by having devices talk to > >>> coordinators without creating a single point-of-failure, and changing > >>> the IPv6 ND multicast semantics. This document will be a proposed > >>> standard. > >>> > >>> 2. Produce "Problem Statement for Stateful Header Compression in > >>> 6lowpans" to document the problem of using stateful header compression > >>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of > >>> stateless header compression given the assumption that stateful header > >>> compression may be too complex. This document will determine if the > >>> assumption is correct and will be an informational document. The WG > >>> will determine if the assumption is correct at this time and record > >>> the findings in this informational document. > >>> > >>> 3. Produce "6LoWPAN Architecture" to describe the design and > >>> implementation of 6LoWPAN networks. This document will cover the > >>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, > >>> network components, addressing, and IPv4/IPv6 network connections. > >>> > >>> 4. Produce "Recommendations for 6lowpan Applications" to define a set > >>> of recommendations of protocols to use for applications. The > >>> recommendations will cover protocols for transport, application layer, > >>> discovery, configuration and commissioning. This document will be an > >>> informational document. > >>> > >>> 5. Produce "6lowpan Security Analysis" to define the threat model of > >>> 6lowpans and to document suitability of existing key management > >>> schemes and to discuss bootstrapping/installation/commissioning/setup > >>> issues. This document will be an informational document. > >>> > >>> The working group will continue to reuse existing protocols and > >>> mechanisms whenever reasonable and possible. > >>> > >>> Goals and Milestones: > >>> > >>> Jan 2008 - First Draft of Bootstrapping and ND Optimization document > >>> Feb 2008 - First Draft of Stateful Header Compression document > >>> Dec 2007 - First Draft of 6LoWPAN Architecture docuement > >>> Feb 2008 - First Draft of Applications document > >>> Mar 2008 - First Draft of Security Analysis > >>> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to > >>> be considered as Proposed Standard > >>> Jul 2008 - Submit Stateful Header Compression document to IESG to be > >>> considered as Proposed Standard > >>> May 2008 - Submit Architecture docuement to IESG to be considered as > >>> Informational RFC > >>> Jul 2008 - Submit Applications docuement to IESG to be considered as > >>> Informational RFC > >>> Sep 2008 - Submit Security Analysis document to IESG to be considered > >>> as Informational RFC. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 6lowpan mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> > >>> > >>> > >> > >> > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
