Re: [6lowpan] Mesh Delivery Field

["Ki-Hyung Kim" <[e-mail]>]

I think the flexibility should be fine. So, what is final look of the mesh
delivery field?


On 9/30/06, gabriel montenegro <[e-mail]> wrote:
>
>  Ok, it seems like folks would like to have more flexibility in the
> header. I'm just having a hard time translating that
> to actual bits and bytes within the header formats, and how much
> flexibility is fine.
>
> The first packet format has 5 bits of reserved field:
>                            1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | LF|  prot_type    |M| rsv     |Payload (or Mesh Delivery Hdr)...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>          Figure 1: LoWPAN unfragmented encapsulation header format
>
> One bit out of that reserved field is what Mario Mao suggests we use to
> distinguish between the two current flavors
> of mesh delivery header (unicast vs bcast/mcast). Is this sufficient
> flexibility?
>
> The issue is that there is no such flexibility in the two other header
> formats, but we can certainly add such a reserved field and make all 3
> header formats the same up to the first 16 bits. Perhaps along these lines
> (notice the new "reserved" field and the corresponding 5 bit shift for
> datagram_size and datagram_tag) :
>
>                            1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | LF|  prot_type    |M|reserved |   datagram_size     |dgram_tag|
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |dgram_tag| Payload (or Mesh Delivery Hdr)...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>         Figure 2: LoWPAN first fragment encapsulation header format
>
>                            1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | LF|datagram_offset|M|reserved |   datagram_size     |dgram_tag|
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |dgram_tag| Payload (or Mesh Delivery Hdr)...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure 3: LoWPAN subsequent fragment(s) encapsulation header format
>
>
>
> Would this be enough? If not, how many bits should be allocated? Should
> there be a version field in addition
> (as suggested by Vipul a while back)? What changes in the format are
> suggested? Folks, please be specific
> as to the suggested changes by sending header formats with clearly
> proposed fields, etc.
>
> tnx,
>
> -gabriel
>
>
>  ----- Original Message ----
> From: David Culler <[e-mail]>
> To: Ki-Hyung Kim <[e-mail]>
> Cc: gabriel montenegro <[e-mail]>; Geoff Mulligan
> <[e-mail]>; Soohong Daniel Park <[e-mail]>;
> [e-mail]
> Sent: Friday, September 29, 2006 8:38:56 AM
> Subject: Re: [6lowpan] Mesh Delivery Field
>
> 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.4technology
> > > > 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
>
>
>



-- 
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

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