Excellent Gabriel. Thanks again for taking on the load of continuing to
edit the draft for the working group!
geoff
On Fri, 2006-11-03 at 14:52 -0800, gabriel montenegro wrote:
> 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
>
> Gabriel,
> 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.
>
> 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.
>
> 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?
>
> 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
