Re: [6lowpan] Mesh Delivery Field

["David Culler" <[e-mail]>]

It certainly would be a shame to get into a position where the encoding is
so so constrained that there was not a means of accomodating additional
capabilities that are revealed through deeper implementation and usage
experience.  The IP community has historically been very good at planning
for change.  Options fields and leaving a little room in the initial
encodings are essential to that.  As much as we try, we seldom get every
aspect of the protocol exactly right the first time.  It is understandable
that with so much focus being place on header compression that it is hard to
leave any space unclaimed.  However, that contingency planning and
flexibility may be more critical to eventual adoption than squeezing out
every unneccessary bit.   As we look at the desired "rush to finish" it is
important to verify that the proposed framework permits enough expressive
power to address the issues that have not yet been fully vetted.  You cannot
expand the format, only work within it.

On 9/26/06, Ki-Hyung Kim <[e-mail]> wrote:
>
> Gabriel,
>
> I am sorry for this late reply.
> Basically, I agree that current format document is rather
> tightly scheduled and not well prepared for future enhancements or
> revisions, in terms of routing, diagnoses, management, etc. Based on the
> assumption that we are not yet in the stage of pursuing future rechartering
> items, it might not be the right time to consider all the cases at one time.
> Also, we should be in rush to finish the current format document ASAP for
> moving forward into next stage before next IETF meeting.
>
> Regarding the mesh delivery field, Mario Mao's approach should be fine,
> and other approaches (like option 2,3, and 4) might be OK. However, it seems
> like we are trying too much to make the format compact while not considering
> the future expansions.
>
> After all, my opinion is option 1. Let's have one byte for the multicast
> bit and the reserved fields for future.
> having additional one byte for this is not a big deal in terms of packet
> size and won't add much complexity for handling it.
> Examples of utilizing some reserved fields might be follows:
> 1. Based on the assumption that 6lowpan supports multiple routing
> protocols such as  LOAD, DYMO-low, HiLow, DSR, or whatever, etc., the field
> might be used for indicating which specific routing protocol should be used
> for routing this particular packet. It might be argued whether the format
> document should support multiple protocols at a time. However, those kind of
> argue should be debated later while considering routing protocols without
> eliminating future possible necessity.
> 2. Routing protocols could be optimzed by having some option fields, while
> it might not be right time to specifically mention them.
>
> I remember that the issue of the mesh underneath or above IP has been
> raised several times in the WG. I think it might not be right time
> considering it again right now.
>
> If you have any other opinions, please let me know.
>
>
> On 9/23/06, gabriel montenegro <[e-mail]> wrote:
> >
> >  First of all, Thanks David for your thoughtful message. It's great to
> > see you participate in this forum and I hope
> > you'll stick around!
> >
> > From the point of view of laying the technology foundation, everything
> > in your message is quite relevant.
> > From the point of view of WG management, I'm trying to figure out if we
> > need to act on all of it right now
> > or if there are things we can address independently of the format draft
> > under discussion. For example,
> > you bring up the topic of traceroute type functionality. In IP, this is
> > carried over ICMP, a separate
> > management control plane. Since what we have in the format draft is a
> > multiplexing layer, we can
> > define a new protocol value to carry out the management protocol
> > packets. The question is if the
> > current format provides the required mechanism to go do work on such a
> > separate protocol
> > in another draft. Intuitively, it seems like this would work. Someone
> > (your group, David?) could
> > define such a protocol with functionality similar to ICMP for pings,
> > traceroute, etc and provide
> > the route gathering functionality, the echo response, etc in that
> > separate draft. Conceivably, it
> > would not necessarily use the mesh delivery header, as it would provide
> > its own facility to
> > record hop-by-hop route information within its own protocol fields. It
> > could use loose source
> > routing in which case some use of the mesh delivery header might be
> > appropriate as well.
> > Would such an approach work, David? This would actually play into one of
> > the items slated for
> > the next round of 6lowpan (if we ever recharter) to strengthen
> > diagnosability or management of
> > these networks.
> >
> > As for your point about us not knowing exactly what the header format
> > must look like at this point in
> > time, this is perhaps something we need to take into consideration right
> > now. For example, this
> > input would push us into reserving at least a couple of bits in the
> > header for future expansion. A while
> > back Vipul was arguing for a "version" field. Not sure if such a field
> > is required or if the current reserved
> > fields are enough. Mario Mao's proposal uses one of those reserved bits
> > to solve the issue under
> > discussion regarding the mesh delivery header variants for unicast vs
> > mcast/bcast. There has been
> > one group expressing support for this, so perhaps we already have the
> > necessary mechanism in place
> > in the header.
> >
> > David, you also mention the need to support different routing protocols
> > side-by-side for comparison.
> > This is one of the design goals of the format document. As I mentioned,
> > the protocol field allows one
> > to carry different protocols. We currently have proposals for a 6lowpan
> > adaptations of AODV, a DyMO
> > and HiLow. I know Nandu was thinking of doing one for OLSR. Perhaps BVR
> > is next. The point is that
> > the format document does provide the mechanism to define any such
> > protocol, or is there a limitation you
> > can see in the current document? If so, what needs to change?
> >
> > As for the claim that sub-IP benefits from simpler structures, my
> > interpretation is that you're suggesting it
> > is better not to use the mesh delivery header and let IP deal with the
> > underlying individual collection of links.
> > If so, one can ignore the mesh delivery header (not use it) and use the
> > other parts of the format document to
> > simply layer IP on top. This approach would then make use of other
> > activities like AUTOCONF or MANET
> > to create meshes if so desired.  Personally, I see that *if* one wishes
> > to do a mesh, not doing it in the sub-IP
> > layer just pushes to problem upwards into the IP routing realm, and this
> > just makes things even more complex
> > than doing it under sub-IP. Complexity will be there no matter what,
> > it's just a question of where one wants to
> > address it. I do note that sub-IP complex structures are very popular
> > and deployed in some cases (802.1d bridged
> > networks). Perhaps likely to become even more so with 802.11s within a
> > few years.
> >
> > I would not be interested in pursuing an AUTOCONF path, but think it
> > should
> > be possible to do so for those so inclined. Does this sound doable?
> > Again, my immediate concern is that the
> > format document not prevent this approach.
> >
> > -gabriel
> >
> >
> >  ----- Original Message ----
> > From: Geoff Mulligan < [e-mail]>
> > To: Soohong Daniel Park <[e-mail]>
> > Cc: [e-mail]; David Culler <[e-mail]>
> > Sent: Friday, September 22, 2006 6:41:21 AM
> > Subject: Re: [6lowpan] Mesh Delivery Field
> >
> > Daniel,
> >   While the WG last call did expire, I'm not sure if David is too late.
> > I think that he raises some important concerns and I'm not sure that we
> > really have consensus on the mesh delivery field.
> >
> > I would like to hear from the list on this.  I think that Gabriel has
> > put forth 4 alternatives.  Carsten indicated that he thought he might
> > have a different alternative and would post to the list either the
> > alternative or his consideration of the 4 alternatives - Carsten, please
> >
> > send your thoughts.
> >
> > I feel that the issue David raises should be dealt with by the WG
> > because I do not want to send the draft on to the IESG only to have
> > these issues brought up in the IETF last call.  These seem rather
> > fundamental to me and we might look rather foolish not having resolved
> > this in the working group!
> >
> > We need some significant discussion from the members of the WG.  This WG
> > has been, my self included, rather quiet and as a result we have moved
> > at a snails pace getting anything done.  I implore everyone to take time
> > and read the thread on the mesh field and send your thoughts, pro, con
> > or otherwise to this list.  If everyone continues to be apathetic about
> > this work, I hold little hope for this WG being rechartered to do any
> > other work!
> >
> >     geoff
> >
> > On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
> > > David,
> > >
> > > First off, your issue raising in this thread seems too late since our
> > > official WGLC was expired: "This Last Call will end on Wednesday 02
> > > August 2006 at 2359 UTC."
> > >
> > > Anyway, my sense is not to take Mesh issue at this stage. As long as
> > > we are looking at the 6lowpan solution format, mesh is out of scope of
> >
> > > that. In fact, as far as I am concern, mesh belongs to 15.4 technology
> > > based on MAC layer. Instead, as described in the rechartering, we will
> > > go through adhoc issue based on IP layer. That's why we are here in
> > > 6lowpan wg of ietf.
> > >
> > > But, some staffs described in your mail seem helpful from the 6lowpan
> > > perspective, especially IPv6 related stuffs. If allowed, please bring
> > > your concern to the next 6lowpan face-to-face meeting in San Diego.
> > > Then, we will have further details in there I believe...
> > >
> > > --
> > >
> > >
> > > Daniel (Soohong Daniel Park)
> > > Mobile Convergence Laboratory, SAMSUNG Electronics.
> > >
> > >
> > >
> > > On 9/21/06, David Culler <[e-mail]> wrote:
> > > > Dear All,
> > > >
> > > > I would like to raise a concern about the Mesh Delivery Field
> > > > definition in Section 11 of the format document.  While the actual
> > > > mesh routing protocol is appropriately outside the scope of the
> > > > 6lowpan Format document, that format needs provide the raw structure
> > > > upon which rough consensus and running code can be flourish.  We
> > > > know that low power wireless mesh routing is technically tricky and
> > > > strongly influenced by target traffic load, power management
> > profile,
> > > > network design, and so on.  Thus, it is reasonable to expect that
> > the
> > > > consensus building and technical refinement process will require
> > > > on-going experience with protocol and implementation alternatives.
> > > > The 6lowpan format document should support this process, although it
> > > > should not dictate its conclusion.
> > > >
> > > > Based on past experience with IP layer 3 routing and with past
> > > > internally routed links, we can establish a few primary goals for
> > the
> > > > expressiveness of the 6lowpan Mesh Delivery Field.
> > > >    (1) It should support the visibility into the routed 15.4 cloud
> > > > necessary to develop, debug, diagnose, and manage the 15.4 cloud.
> > > >    (2) It should support the ability to define, develop and compare
> > > > routing protocols and possibly support the presence of multiple
> > > > protocols for widely differing usage cases.
> > > >    (3) It needs to be possible for nodes to communicate with other
> > nodes
> > > > in the cloud in order to discover and negotiate joining the cloud
> > > > without joining the cloud a priori through some mechanism that is
> > > > opaque to IP and above.
> > > >
> > > > (1) has historically been addressed through various forms of source
> > > > routing.  It should be possible to do the equivalent of traceroute
> > > > through the 15.4 mesh and this should be accessible in some form
> > through IP
> > > > so
> > > > higher layers can be built to perform the management.  The current
> > > > Mesh Delivery Field definition seems to prohibit any form of source
> > routing.
> > > > It assumes that the routing tables are all set up and correct so
> > that
> > > > the forwarder can "swizzle" the destination address field of the
> > 15.4
> > > > header with a table entry.  (The experience of IP over ATM and the
> > > > thousands of pages of the Q83b signalling protocol required to set
> > up
> > > > all the tables in advance ought to give us a little pause
> > here.)  The
> > > > idea of supporting table-driven routing and thereby separating the
> > > > route formation from the forwarding engine is a good one, but there
> > > > needs to be enough expressive power to support the protocols that
> > will
> > > > establish and manage those tables (rather than relying on an opaque
> > > > out-of-band signaling mechanism) and there needs to be the ability
> > to
> > > > query and validate those tables without relying on out-of-band
> > > > mechanisms.
> > > >
> > > > (2) has historically be addressed with protocol identifiers and
> > > > options.  As we went through the various RIP, OSPF, etc. we didn't
> > > > need to go back and redefine the format documents.  There was enough
> >
> > > > expressiveness for topology formation and routing to evolve.  Not
> > all
> > > > networks need to support all protocols.  That has been the network
> > > > designers' determination.  The underlying structure provided the
> > > > primitives, allowing solutions (and consensus) to evolve.  We want
> > to
> > > > avoid creating a "winner take all" structure where there is no room
> > > > for evolution and development.  It is possible that AODV, or
> > TinyAODV,
> > > > or DSR, or GPSR or possibly one of several other alternatives is the
> > right
> > > > solution.  However, there is little evidence of one having clear
> > superiority
> > > > at
> > > > this time, despite numerous high profile efforts.  We should be
> > defining the
> > > > canvas upon which competing alternatives can be defined and vetted.
> > > >
> > > > (3) has historically been addressed by a limited ability to
> > > > communicate on the link to a crudely defined set of nodes in order
> > to
> > > > bootstrap the discovery, join, address assignment, negotiation, etc.
> > > > Most successful links under IP look either like a broadcast medium
> > or
> > > > a point-to-point link (a degenerative broadcast).  This allows ARP,
> > > > RARP, BOOTP, DHCP, etc. to gain higher level accessibility and
> > > > addressibility through the link.  Links that require complex
> > > > signaling, discovery, joining and coordnation below the link layer,
> > > > including ATM, Bluetooth (piconets and scatter nets), and IRDA have
> > > > proved onerous for IP and have been relegated to far less general
> > > > usage scenarios - such as the desktop USB replacement.  Even though
> > > > the radio is a broadcast medium, the challenge in a routed link is
> > > > that the link is not by default a link-wide broadcast phy.  There
> > > > are two natural notions of "broadcast" in a lowpan.  (i) The
> > physical
> > > > neighbors that happen to receive a transmission because they are
> > close
> > > > enough to pick up the signal and have their radios turned on to
> > > > receive.  (ii) The entire collection of nodes that can be reached by
> > a
> > > > multihop dissemination (flood).  Both of these are extremely useful
> > in
> > > > bootstrapping higher levels, including routing, and should be
> > > > addressed in the format document.  Additionally, it is not
> > > > neccessary to use the 802.15.4 beaconing mechanism to bring up IP
> > over
> > > > a 15.4 link.  Providing some forms of broadcast using data frames
> > > > makes the 802.15.4 format much more like 802.11 and other links that
> > > > have proved very suitable for IP.  Few, if any, of the public 15.4routing
> > > > layers developed
> > > > by the TinyOS community utilize beacon packets.
> > > >
> > > > The recognition that the current Mesh Delivery field may be to
> > restrictive
> > > > is intimated by the need to define a second form of the header for
> > > > multicast (and link local broadcast) that includes a sequence
> > number.
> > > > The mesh header field type is defined by whether the destination
> > > > address is unicast or multicast. The document states that the use of
> > > > such a sequence number is out of scope. However, the observation
> > that
> > > > that extra information may need to be included depending on how
> > > > packets are routed further suggests that more careful format
> > > > definition is needed to support future development of mesh routing.
> > > >
> > > > Have folks who have been developing mesh layers for lowpan6 felt
> > that
> > > > the existing Mesh Delivery Field is too restrictive?
> > > >
> > > >
> > > > David E. Culler
> > > > UC Berkeley
> > > > [e-mail]
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 6lowpan mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/6lowpan
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > 6lowpan mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/6lowpan
> >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/6lowpan
> >
> >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/6lowpan
> >
> >
> >
>
>
> --
> Ki-Hyung Kim (김기형, 金起亨)
> Associate Professor
> Division of Information and Computer Eng., Ajou University, Suwon, Korea
> 442-749
> Tel: [phone], Cel: [phone],  Fax: [phone]
> http://www.6lowpan.org




-- 
David E. Culler
Arched Rock Corporation
2168 Shattuck Ave
Berkeley, CA 94704
www.archedrock.com

_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan