inline marked "gm>"
----- Original Message ----
From: Geoff Mulligan <[EMAIL PROTECTED]>
To: 6lowpan <[email protected]>
Sent: Thursday, October 26, 2006 11:30:55 PM
Subject: [6lowpan] comments on draft 5
Section 5.1 Paragraph on datagram_size (page 8): I think that the NOTE:
should read:
While it may appear that this field does not need to be in every packet,
as one could send it with the first fragment and elide it subsequently,
it is included it in every link fragment to ease the task of reassembly
in the event that a second (or subsequent) link fragment arrives before
the first. ...
Section 5.2: Possible rewrite:
The recipient of link fragments SHALL use (1) ...
I think that the next paragraph in the text, the paragraph starting with
"Upon receipt" should be removed since this is an implementation choice.
For the same reason and and per the discussion with Phil, I think that
the next paragraph (starting with "If a link fragment") should also be
removed.
And for the same reason, this is an implementation detail, the paragraph
starting with "Upon detection of a IEEE" should be removed unless there
is a specific reason for the 15 second time out - where did 15 seconds
come from?
Section 6: Paragraph 2 Line 6: I'm not sure that the phrase
"concatenated with" is clear as to the ordering. I'm not sure that
"concatenated to" is precise (as used in the previous sentence).
Section 10.1: I think that it should be written as:
It is possible to use header compression even in advance of setting up
the customary state. The following common IPv6 header...
Questions:
Section 5.1 Paragraph on datagram_size (page 8): The datagram_size is
set to 40 octets more than the Payload Length value in the IPv6 header,
but if the IPv6 header is compressed doesn't this lead to the wrong
datagram size calculation?
Section 5.1 Encapsulation header format (meta question): if we were to
allow multiple mesh protocols under this adaptation layer do we think
that this should be carried in the prot_type field or should we add or
define the "rsv" field for the mesh network type, though 3 bits would
probably suffice or should we add one more byte. I think that this is
partially what David was asking about. Having this flexibility might be
especially important to allow for diagnosing the mesh layer.
Section 11 - It doesn't look like we fixed the problem with the sequence
number before the destination address? Did I miss a different solution?
From: Geoff Mulligan <[EMAIL PROTECTED]>
To: 6lowpan <[email protected]>
Sent: Thursday, October 26, 2006 11:30:55 PM
Subject: [6lowpan] comments on draft 5
Gabriel,
First some editorial comments:
Section 3 Paragraph 1 Line 12 - occurred should be occurring
First some editorial comments:
Section 3 Paragraph 1 Line 12 - occurred should be occurring
gm> Fixed, thanks.
Section 5.1 Paragraph on datagram_size (page 8): I think that the NOTE:
should read:
While it may appear that this field does not need to be in every packet,
as one could send it with the first fragment and elide it subsequently,
it is included it in every link fragment to ease the task of reassembly
in the event that a second (or subsequent) link fragment arrives before
the first. ...
gm> I don't agree with the"it may appear". It's not just appearance, one can
actually elide it. I have not put in any change here.
Section 5.2: Possible rewrite:
The recipient of link fragments SHALL use (1) ...
gm> Ok, done.
I think that the next paragraph in the text, the paragraph starting with
"Upon receipt" should be removed since this is an implementation choice.
For the same reason and and per the discussion with Phil, I think that
the next paragraph (starting with "If a link fragment") should also be
removed.
gm> Phil and I feel like this is good info to have, but I have made some changes
to try to soften the prescriptiveness of the text, while still leaving in some
info for implementors.
And for the same reason, this is an implementation detail, the paragraph
starting with "Upon detection of a IEEE" should be removed unless there
is a specific reason for the 15 second time out - where did 15 seconds
come from?
gm> I think we found it in someone's hat. You have a point. If we look at
rfc 2460, IPv6 implements a hard reassembly timeout of 60 seconds.
Since what we at the lowpan level may be transporting could potentially
be an IPv6 fragmented packet, it makes no sense for us to hold on to
our lower-layer reassembly process longer than that. So I've changed
our text to reflect the fact that we recommend some reassembly timeout
which should not exceed 60 sec.
gm> Since there are several changes to this reassembly section here it is as it looks now after the tentative changes:
5.2 Reassembly The recipient of link fragments SHALL use (1) the sender's 802.15.4 source address (or the Originator Address if a Mesh Delivery field is present), (2) the destination's 802.15.4 address (or the Final Destination address if a Mesh Delivery field is present), (3) datagram_size and (4) datagram_tag to identify all the link fragments that belong to a given datagram. Upon receipt of a link fragment, the recipient starts constructing the original unfragmented packet whose size is datagram_size. It uses the datagram_offset field to determine the location of the individual fragments within the original unfragmented packet. For example, it may place the data payload (except the encapsulation header) within a payload datagram reassembly buffer at the location specified by datagram_offset. The size of the reassembly buffer SHALL be determined from datagram_size. If a link fragment is received that overlaps another fragment as identified above and differs in either the size or datagram_offset of the overlapped fragment, the fragment(s) already accumulated in the reassembly buffer SHALL be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of datagram_offset from the encapsulation header and "Frame Length" from the 802.15.4 PPDU packet header. Upon detection of a IEEE 802.15.4 Disassociation event, fragment recipients SHOULD discard all link fragments of all partially reassembled payload datagrams, and fragment senders SHOULD discard all not yet transmitted link fragments of all partially transmitted payload (e.g., IPv6) datagrams. Similarly, when a node first receives a fragment with a given datagram_tag, it starts a reassembly timer. When this time expires, if the entire packet has not been reassembled, the existing fragments SHOULD be discarded and the reassembly state SHOULD be flushed. The reassembly timeout MUST be set to a maximum of 60 seconds (this is also the timeout in the IPv6 reassembly procedure [RFC2460] ).
Section 6: Paragraph 2 Line 6: I'm not sure that the phrase
"concatenated with" is clear as to the ordering. I'm not sure that
"concatenated to" is precise (as used in the previous sentence).
gm> I had added some illustration of what the result looks like, but perhaps
that is lost in the text. I've now modified to more clearly show this and the
relevant text now looks like this:
All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
addresses (Section 3 and Section 12) are also possible. In these
cases, a "pseudo 48-bit address" is formed as follows. First, the
left-most 32 bits are formed by concatenating 16 zero bits to the 16-
bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
used). This produces a 32-bit field as follows:
16_bit_PAN:16_zero_bits
Then, these 32 bits are concatenated with the 16-bit short address.
This produces a 48-bit address as follows:
32_bits_as_specified_previously:16_bit_short_address
The interface identifier is formed from this 48-bit address as per
Section 10.1: I think that it should be written as:
It is possible to use header compression even in advance of setting up
the customary state. The following common IPv6 header...
gm> Not sure about this. "in advance" implies we will eventually enter a context-building
phase for header compression. But this is not what we do. We don't have the customary
(for header compression) context-building phase. So "in absence" describes what we do,
I think.
Appendix A Paragraph 1 line 18: frament should be fragment.
gm> Ok, thanks.
Appendix A Paragraph 1 line 18: frament should be fragment.
gm> Ok, thanks.
Questions:
Section 5.1 Paragraph on datagram_size (page 8): The datagram_size is
set to 40 octets more than the Payload Length value in the IPv6 header,
but if the IPv6 header is compressed doesn't this lead to the wrong
datagram size calculation?
gm> Ok, added "uncompressed" before "IPv6 header".
Section 5.1 Encapsulation header format (meta question): if we were to
allow multiple mesh protocols under this adaptation layer do we think
that this should be carried in the prot_type field or should we add or
define the "rsv" field for the mesh network type, though 3 bits would
probably suffice or should we add one more byte. I think that this is
partially what David was asking about. Having this flexibility might be
especially important to allow for diagnosing the mesh layer.
gm> I think we've already answered this question a while back with the
drafts on DyMO, LOAD, etc. These are protocols that run on top of the lowpan
layer, just like IPv6 itself runs on the lowpan layer. In our current design,
one runs one protocol at a time on top of the lowpan adaptation layer.
So one would run a mesh routing protocol of choice to set up routes
and populate nodes with the appropriate topological information.
Subsequent to that, any other protocol on top of that adaptation layer
(e.g., IPv6, appletalk, IPv4, whatever) could use the mesh delivery.
The "B" bit and the mesh delivery field are only used for the delivery
of data on a mesh. The control plane for the mesh is determined by prot_type
and is done with any of several mesh routing protocols.
Section 9 about Multicast Address mapping: Does this preclude a network
from using 64-bit addressing for multicasting? It seems to indicate
that you must use 16-bit addresses for multicast addresses.
Section 9 about Multicast Address mapping: Does this preclude a network
from using 64-bit addressing for multicasting? It seems to indicate
that you must use 16-bit addresses for multicast addresses.
gm> The mesh delivery header for multicast does not preclude that, as it also
includes the "O" and "F" bits to signal 16 or 64 bit address length. So one could
in the future define the mapping from IPv6 multicast to 64-bit addresses, but
we're not doing that now. This could be a separate document for which I don't
see much urgency in current networks.
Section 10.2 in the Length (bit 2) paragraph: can we really compute the
udp length field from the possibly compressed frame length field or the
datagram_size field in a fragment header? Is this a simple calculation?
Section 10.2 in the Length (bit 2) paragraph: can we really compute the
udp length field from the possibly compressed frame length field or the
datagram_size field in a fragment header? Is this a simple calculation?
gm> The frame length is never compressed. It is part of the layer 2 802.15.4
header which we do not control. The value of the UDP length field is equal
to the Payload Length from the IPv6 header, minus the length of any extension
headers present between the IPv6 header and the UDP header. I've added this
sentence to clarify.
Section 11 - It doesn't look like we fixed the problem with the sequence
number before the destination address? Did I miss a different solution?
gm> We added the 'B' bit. The paragraph before figure 10 now has this text,
for example:
There are two types of Mesh delivery fields: the "Unicast Mesh Delivery Field" (Figure 10), and the "Broadcast or Multicast Mesh Delivery Field" (Figure 11). The former is used if the 'B' bit is set to zero, and the latter is used if the 'B' bit is set to 1. The 'B' bit appears in all variations of the LoWPAN encapsulation header (Section 5).
-gabriel
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
