Re: [6lowpan] New charter for 6lowpan

["Eunsook \"Eunah\" Kim" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> >> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/6lowpan
> >>>
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > 6lowpan mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6lowpan
> >
>
>
>
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan