Subject: [6lowpan] Mesh Delivery Field

From: "David Culler" <[email-masked]>
Date: Wed, 20 Sep 2006 22:18:13 -0700

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.4 routing
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
[email-masked]
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Fri, 22 Sep 2006 19:23:56 +1000

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.

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 22 Sep 2006 07:41:21 -0600

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

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 22 Sep 2006 09:02:18 -0700 (PDT)

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 <[email-masked]>
To: Soohong Daniel Park <[email-masked]>
Cc: [email-masked]; David Culler <[email-masked]>
Sent: Friday, September 22, 2006 6:41:21 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,

    geoff

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Wed, 27 Sep 2006 08:58:20 +0900

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

-- 
Ki-Hyung Kim
Associate Professor
Division of Information and Computer Eng., Ajou University, Suwon, Korea
442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433
http://www.6lowpan.org
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "David Culler" <[email-masked]>
Date: Fri, 29 Sep 2006 08:38:56 -0700

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 <[email-masked]> wrote:
> 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
> After all, my opinion is option 1. Let's have one byte for the multicast
> bit and the reserved fields for future.
> 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
> 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 <[email-masked]> 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!
> >
> > 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.
> > 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
> > From: Geoff Mulligan < [email-masked]>
> > > > have proved very suitable for IP.  Few, if any, of the public 15.4routing
> > > > layers developed
> Ki-Hyung Kim (김기형, 金起亨)

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

---

From: Mario Mao <[email-masked]>
Date: Sat, 30 Sep 2006 15:07:34 +0800

Hi Gabriel,

Thanks for you feedback.

As I mentioned before, the way to combining the Traffic Class and Flow Label with Version field just is a workaround we used temporarily. Also, the same method is used to solve the UDP compression alignment problem, that is, only compress the port field when both source and destination ports could be compressed.

Clearly, my workaround is somewhat ugly and not reasonable, but it do make the implementation more easily. In fact, we do wait for new draft to clarify this alignment problem. For personal opinion, it is a good idea to pad bits till all compression fininshed. However, I think we should pay caution to the facility for implementation. I hope we can get conclusion in the next version, thanks.

Best Regards,

Mario Mao
  ----- Original Message ----- 
  From: gabriel montenegro 
  To: Ki-Hyung Kim 
  Cc: David Culler ; Geoff Mulligan ; Soohong Daniel Park ; [email-masked] ; Mario Mao 
  Sent: Saturday, September 30, 2006 10:16 AM
  Subject: Re: [6lowpan] Mesh Delivery Field

  Ki-Hyung,

  You asked: "So, what is final look of the mesh delivery field?"

  As per Mario's suggestion, we'd use one of the 5 reserved bits to signal if the
  bcast/mcast mesh delivery format is being used, and we'd call it the 'B' bit.
  So no change to the mesh delivery fields is required. Since the reserved bits
  are common to all three lowpan header formats, the 'B' bit would apply to all
  three. 

  Mario also had a comment on how the header compression forces alignment to not
  fall on octet boundaries:
    At last, I find some problem when impliment IPv6 header compression. Please note Traffic Class and Flow Label bit in HC1. If we don't compress the two field, 28 bits (that is three and half bytes) are sent. However, how to send the half byte? As I know, most hardware could only transmit data in unit of BYTE. Should we need 4 bits pending data? The workdaround we used is combining the Traffic Class and Flow Label with Version field. So, the Traffic Class and Flow Label bit becomes Version, Traffic Class and Flow Label bit. Please see following as detail.

    Version, Traffic Class and Flow Label (bit 4):
    0: not compressed, full 4 bits for Version, 8 bits for Traffic Class and 20 bits for Flow Label are sent
    1: Traffic Class and Flow Label are zero
  What do people think of that? I'd rather not do that because

     1. why send a version field if the version is already known (i.e., IPv6)?
     2. this only fixes the alignment as far as the IPv6 header is concerned, but
        there are more headers probably following, and those could also have 
        alignment issues.

  For example, we also have an issue with UDP header compression (the only
  header compression scheme currently defined in addition to IPv6 header):

        UDP source port (bit 0):
           0: Not compressed, carried "in-line" (Section 10.3.2)
           1: Compressed to 4 bits.  The actual 16-bit source port is
              obtained by calculating: P + short_port value.  P is a
              predetermined port number with value TBD.  The short_port is
              expressed as a 4-bit value which is carried "in-line"
              (Section 10.3.2)

        UDP destination port (bit 1):
           0: Not compressed, carried "in-line" (Section 10.3.2)
           1: Compressed to 4 bits.  The actual 16-bit destination port is
              obtained by calculating: P + short_port value.  P is a
              predetermined port number with value TBD.  The short_port is
              expressed as a 4-bit value which is carried "in-line"
              (Section 10.3.2)

  Because of the above, it seems quite possible that one would end up with 4 bits
  for either the UDP source or destination. In such a case, the misalignment in the
  IPv6 header could be offset by the misalignment in the UDP header compression, 
  and we'd end up aligned on an octet boundary. Of course, if one uses the funky
  4-bit port compression for both source and destination then one wouldn't offset
  the previous misalignment. No way to know, so perhaps one should wait until the
  entire header is laid out to figure out if any padding with zero bits is to
  be done.

  So perhaps what we can do is to add text to the effect that one packs the entire
  header and then pads as appropriate to align to an octet boundary. Does this 
  sound reasonable?

  thanks for any comments,

  -gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 29 Sep 2006 19:16:50 -0700 (PDT)

Ki-Hyung,

 
 
   1. why send a version field if the version is already known (i.e., IPv6)?
   2. this only fixes the alignment as far as the IFrom [email-masked] Sat Sep 30 12:39:10 2006
Date: Fri, 29 Sep 2006 19:16:50 -0700 (PDT)
From: gabriel montenegro <[email-masked]>
Subject: Re: [6lowpan] Mesh Delivery Field
To: Ki-Hyung Kim <[email-masked]>
Cc: Mario Mao <[email-masked]>, [email-masked],
	David Culler <[email-masked]>
Reply-To: gabriel montenegro <[email-masked]>
Ki-Hyung,

 

 
      UDP source port (bit 0):

 
 
thanks for any comments,
 
-gabriel
 
----- Original Message ----
From: Ki-Hyung Kim <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: David Culler <[email-masked]>; Geoff Mulligan <[email-masked]>; Soohong Daniel Park <[email-masked]>; [email-masked]
Sent: Friday, September 29, 2006 5:16:11 PM
Subject: Re: [6lowpan] Mesh Delivery Field

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

On 9/30/06, gabriel montenegro <[email-masked]> 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 HdPv6 header is concerned, but
      there are more headers probably following, and those could also have 
      alignment issues.

      UDP source port (bit 0):

 
 
thanks for any comments,
 
-gabriel
 
----- Original Message ----
From: Ki-Hyung Kim <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: David Culler <[email-masked]>; Geoff Mulligan <[email-masked]>; Soohong Daniel Park <[email-masked]>; [email-masked]
Sent: Friday, September 29, 2006 5:16:11 PM
Subject: Re: [6lowpan] Mesh Delivery Field

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

On 9/30/06, gabriel montenegro <[email-masked]> 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 < [email-masked]>
To: Ki-Hyung Kim <[email-masked]>
Cc: gabriel montenegro < [email-masked]>; Geoff Mulligan <[email-masked]>; Soohong Daniel Park < [email-masked]>; [email-masked]
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 <[email-masked] > 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 r)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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 < [email-masked]>
To: Ki-Hyung Kim <[email-masked]>
Cc: gabriel montenegro < [email-masked]>; Geoff Mulligan <[email-masked]>; Soohong Daniel Park < [email-masked]>; [email-masked]
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 <[email-masked] > 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.

On 9/23/06, gabriel montenegro < [email-masked]> 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!

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

On 9/23/06, gabriel montenegro < [email-masked]> 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!

 

 
-gabriel

----- Original Message ----
From: Geoff Mulligan < [email-masked]>
To: Soohong Daniel Park <[email-masked]>
Cc: [email-masked]; David Culler <[email-masked]>
Sent: Friday, September 22, 2006 6:41:21 AM 
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,

    geoff

On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
>st makes things even more complex

-gabriel

----- Original Message ----
From: Geoff Mulligan < [email-masked]>
To: Soohong Daniel Park <[email-masked]>
Cc: [email-masked]; David Culler <[email-masked]>
Sent: Friday, September 22, 2006 6:41:21 AM 
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,

    geoff

On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
> > eno > 

-- 
Ki-Hyung Kim (김기형, 金起亨)
Associate Professor
Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433 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: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6lowpan.org

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 29 Sep 2006 14:08:28 -0700 (PDT)

The issue is that there is no such flexibility in the two other header formats, but we can certainly add such a 
reselowpan.org</A></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif"><BR></DIV></div></body></html>
--0-1262425063-1159582610=:47488--

--=======92960026=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=======92960026=--

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 29 Sep 2006 14:08:28 -0700 (PDT)

1                   2                   3

                           1                   2                   3

 
 
tnx,
 
-gabriel

----- Original Message ----
From: David Culler <[email-masked]>
To: Ki-Hyung Kim <[email-masked]>
Cc: gabriel montenegro <[email-masked]>; Geoff Mulligan <[email-masked]>; Soohong Daniel Park <[email-masked]>; [email-masked]
Sent: Friday, September 29, 2006 8:38:56 AM
Subject: Re: [6lowpan] Mesh Delivery Field

 

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

                           1                   2                   3

 
 
tnx,
 
-gabriel

----- Original Message ----
From: David Culler <[email-masked]>
To: Ki-Hyung Kim <[email-masked]>
Cc: gabriel montenegro <[email-masked]>; Geoff Mulligan <[email-masked]>; Soohong Daniel Park <[email-masked]>; [email-masked]
Sent: Friday, September 29, 2006 8:38:56 AM
Subject: Re: [6lowpan] Mesh Delivery Field

 

 

 

 
As for the claim that sub-IP benefits from simet 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.

 

 

-gabriel

----- Original Message ----
From: Geoff Mulligan < [email-masked]>
To: Soohong Daniel Park <[email-masked]>
Cc: [email-masked]; David Culler <[email-masked]>
Sent: Friday, September 22, 2006 6:41:21 AM 
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,

    geoff

On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
> > 6lowpan Format document, thapler structures, my interpretation is that you're suggesting it 

-gabriel

----- Original Message ----
From: Geoff Mulligan < [email-masked]>
To: Soohong Daniel Park <[email-masked]>
Cc: [email-masked]; David Culler <[email-masked]>
Sent: Friday, September 22, 2006 6:41:21 AM 
Subject: Re: [6lowpan] Mesh Delivery Field

Daniel,

    geoff

On Fri, 2006-09-22 at 19:23 +1000, Soohong Daniel Park wrote:
> > st format needs provide the raw structure

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

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Sat, 30 Sep 2006 09:16:11 +0900

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

On 9/30/06, gabriel montenegro <[email-masked]> wrote:
>
>  Ok, it seems like folks would like to have more flexibility in the
> header. I'm just having a hard time translating that
> One bit out of that reserved field is what Mario Mao suggests we use to
> distinguish between the two current flavors
> 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
> Cc: gabriel montenegro <[email-masked]>; Geoff Mulligan
> <[email-masked]>; Soohong Daniel Park <[email-masked]>;
> [email-masked]
> > 2. Routing protocols could be optimzed by having some option fields,
> > while it might not be right time to specifically mention them.
> >
> > > If so, one can ignore the mesh delivery header (not use it) and use
> > > the other parts of the format document to
> > > to create meshes if so desired.  Personally, I see that *if* one
> > > wishes to do a mesh, not doing it in the sub-IP
> > > > that. In fact, as far as I am concern, mesh belongs to 15.4technology