Here's another preliminary version of the doc:
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.htm
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.txt
Please look it over, specially as related to the changes:
Appendix B. Changes
Changes from version draft-ietf-6lowpan-format-00.txt to version
draft-ietf-6lowpan-format-01.txt are as follows:
TODO: Add support for 16-bit "short" addresses.
TODO: Added 'Ver' field, and one more bit to datagram tag (from 15
to 16 bits). protocol_type and datagram offset both went from 11
to 8 bits (which is still enough for the format, and which implies
counting offset in units of 8 octets for the latter).
Changed both fragmentation formats, moved the datagram tag towards
the end, and increased its length from 7 to 15 bits.
Addition of the originator's link-layer source address to the
"Mesh Delivery" header.
Changed name of "Final Destination" header to "Mesh Delivery"
header.
Further clarification on mesh delivery.
Sundry editorial changes.
As for your message, please find some answers below...
-gabriel
--- Samita Chakrabarti <[EMAIL PROTECTED]> wrote:
> > > Q1: What is meant by 'used for adhoc or mesh routing' ? I assume that
> > > it
> > > means M bit is used for both control and data path for multihop routing
> > > -
> > > is it correct?
> >
> > It's meant for data delivery. You would run your favorite mesh protocol
> > (aodv, dymo, olsr, etc) without using the 'M' bit, cuz these go hop-by-hop.
> > One could think of ways in which one could run them even with an 'M' bit
> > on, but this is perhaps more for discussion f2f.
>
> For RREQ forward path M bit is not necessary, because all nodes use bcast.
> For RREP from destination to the original sender, it might be useful
> it seems.[ when AODV runs on link-layer]
ah, yes, ok.
> > > It seems if we can come up with a IEEE address format for lowpan, then
> > > it can be compressed easily over a LowPAN network to include both
> > > originator address and final address.
> >
> > I don't think we have the charter to define layer 2 addressing. Besides,
> > I don't see the point, cuz if a PAN is using 16-bit (short) addresses
> > as per 802.15.4, they would take much less space. Might as well use that.
> >
> > >
>
> Are we re-thinking of IPv6-address format ( the low 64bit part) as well ?
> fe80:0:0:<pan-id>::<16bit-addr>?
ah, i see. you're talking about the interface identifier (IID) format based on
the link-layer address. yes, that's one of the things that an ip-over-foo
is expected to specify. we already did for the 64-bit format. for the
16-bit 15.4 link-layer format, your suggestion is the simplest, yes.
we're already suggesting adding a <pan-id> to a /48 to obtain a prefix
identifier
so this would play into that as well. but for IIDs we can actually mandate
the above format. going through the draft and adding support for short bit
addresses is still on the TODO list, hopefully we can do it before the cut-off.
> ...
> Currently it says 'Final destination field' - I suppose, it's going to change
> to 'Final Destination header' or alike?
> If we add source link-layer address as well, then I'd really like to see
> a suggestion for header compression in case of 64bit addresses, even though
> IETF charter may not allow to specify IEEE address format. Do you think, it
> might be something that should be brought up at the IEEE meetings?
not sure what you mean here.
> If we use 16bit short addresses only, do we see any disadvantages in
> routing directly to the Internet other than limitation of address space?
not sure why. any link-layer addresses are supposed to be used on your local
link.
so routing to the internet only plays in that you must find a router to send
stuff
off-link. this router would be on your local link, of course, so it would an
address on that link just like anybody else (e.g., short 16-bit address if on a
15.4 link). perhaps i misunderstood the question.
> As for naming, I'd prefer 'Mesh Delivery header'.
ok.
> > Please read the updated section 9 on mesh delivery and comment. That section
> > is available here:
> >
> >
> http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.h
> tm#mesh
> >
> http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.t
> xt
> >
> > I include it below for your convenience.
>
> Thanks so much. Please the comments in-line.
>
> > 9. Frame Delivery in a Link-Layer Mesh
> >
> > Even though 802.15.4 networks are expected to commonly use mesh
> > routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not
> > define such capability. In such cases, an ad hoc or mesh routing
> > protocol populates the devices' routing tables. A device that wishes
> > to send a frame may, in such cases, use other intermediate devices as
> > forwarders towards the final destination. In order to achieve such
> > frame delivery using unicast, it is necessary to include the final
> > destination in addition to the hop-by-hop destination.
> >
> > 9.1. Alternatives for Delivery of Frames in a Mesh
> >
> > Before discussing the defined mechanism for delivery in a mesh, let's
> > review some options on how to accomplish this. The final destination
> > could be expressed either as a layer 2 or as an IP (layer 3) address.
> > In the latter case, there would be no need to provide any additional
> > header support in this document (i.e., at the sub-IP layer). The
> > link-layer destination address would point to the next hop
> > destination address while the IP destination address would point to
> > the final destination (IP) address (that may be multiple hops away
> > from the source). Thus, while forwarding data, the single-hop
> > destination address would change at each hop (always pointing to the
> > "best" next link-layer hop), while the destination IP address would
> > remain unchanged. Notice that if an IP packet is fragmented, the
> > individual fragments may arrive at any node out of order. If so, if
> > the initial frament (which contains the IP header) is delayed for
> > some reason, a node that receives a middle fragment would lack the
> > final destination address. It would be forced to wait until this
> > information arrives (in the IP header within the first fragment)
> > before being able to forward the fragment any further. This imposes
> > some additional buffering requirements on intermediate nodes.
> > Additionally, the above scheme would need to be adapted depending on
> > the layer 3 protocol, and would require this protocol to include its
> > own addressing information.
> >
>
>
> Perhaps a subheader for 'Using L3 Final Destination field' and 'Using L2 Final
> Destination Field' would look a litle clear.
I just moved the above section into an appendix.
> As for L3 final destination address, I understand :
>
> - The routing still happens in L3 layer; each node derives the next hop
> L2 address corresponding to the next-hop IP-address in the routing table
> given the final destination IPv6 address.
>
> - The Final destination field is useful when IPv6 pkt is fragmented over the
> link. If not fragmented, Final destination IP-address is not needed.
>
> - If the IPv6 packet is not fragmented, and we use L3 routing, we don't
> need to set M bit.
>
> Are the above assumptions correct? If yes, perhaps then a clarification
> on them in the above text is helpful.
This was one option we did not choose, so I've left the text pretty much
unchanged
(with some minor edits, perhaps it's clearer).
We might want to remove this altogether before publicatino.
-gabriel
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
