I understand it,
but there are some other questions that I struggle with.
Let's talk about fragmentation header:
in this discussion
http://www.ietf.org/mail-archive/web/6lowpan/current/msg02327.html
authors explain their doubts about datagram_size field in RFC 4944.
Since in draft I found only this sentece about it:
Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6
datagrams that do not fit within a single link frame. Section 5.3 of
[RFC4944] defines the fragment header's datagram_size and
datagram_offset values as the size and offset of the IPv6 datagram
before compression. As a result, all fragment payload outside the
first fragment must carry their respective portions of the IPv6
datagram before compression. This document does not change that
requirement. When using the fragmentation mechanism described in
Section 5.3 of [RFC4944], any header that cannot fit within the first
fragment MUST NOT be compressed.
I would like to have a confirm about how I think the compression and
fragmentation works.
Let me say I am the 6lowpan (2.5) layer, and I take a datagram from
the upper layers. IPv6 and UDP add their headers without knowing
anything about me and my presence between data-link layer and them. So
I have a datagram with 8 byte of UDP header and 40 byte (even more if
there is an extension header) of IPv6 header.
I start compressing IPv6 header and, if it is possible, extension
and/or UDP headers, now I have a compressed header and application
layer payload.
If the total length is less than the data-link MTU, I fill a single
data-link message and I send it.
If the total length is bigger than data-link MTU I have to come back,
calculate the size of compression header (IPv6, extension and UDP
headers) ask me if they suit in a single data-link message
Colin O'Flynn <[email protected]> ha scritto:
Hello Giulio,
There are two levels of fragmentation, I think that might be causing
confusion?
IPv6 level fragmentation DOES keep the IPv6 headers between fragments, for
example see
http://www.tcpipguide.com/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUF
ragment-4.htm .
6LoWPAN level fragmentation DOES NOT keep the IPv6 headers between
fragments. 6LoWPAN only repeats the 6LoWPAN header between fragments.
The 6LoWPAN MTU is (at least) 1280 bytes. Any packet larger than fits in a
single 15.4 packet but smaller or equal to the 6LoWPAN MTU will be
fragmented at the 6LoWPAN layer. Anything larger than the 6LoWPAN MTU would
have to be fragmented at the IPv6 layer by the sender, and each of those
IPv6 fragments may have 6LoWPAN fragmentation applied.
Hope this is a lucid explanation, let me know if it doesn't make sense.
Regards,
-Colin O'Flynn
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of [email protected]
Sent: March 16, 2011 6:18 PM
To: [email protected]
Subject: [6lowpan] questions about lowpan_nhc fields
Dear authors,
I would speak about 6lowPAN hc-15 draft document.
Section 4 describes the ipv6 next header compression and in 4.2 ipv6
extension header encoding is shown.
So incidentally in a 802.15.4 127 byte long packet I could have a mesh
header and a fragmentation header like RFC4944 describes; after those
a lowpan_IPCH dispatch with in-line ipv6 fields, like it is shown in
figure 1 on page 5. All those headers (RFC4944 and figure 1 ones) in a
single 802.15.4 packet.
But figure 11 on page 14 shows that we could have other headers like
in IPv6 (so-called extension-header), and they could be heavy like
router header or they grows on-the-fly like hop-by-hop header.
So my questions are: do those extension headers have to be present in
every fragment of an IPv6 packet? And if it is so, doesn't it seem
like wasting a lot of space? Let's say that I want to send a message
and I have to write entirely the IPv6 source and destination addresses
and I want a routing header too, even with 4 addresses, I fill 80 out
of 127 bytes only for addresses. Is this example right or I understand
wrongly the document? And after these considerations, is it necessary
to change the rule to calculate the datagram size field in RFC4944
fragmentation header?
Best regards
Giulio Ministeri
from University of Padova, Italy
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
