Re: [6lowpan] questions about lowpan_nhc fields

[[e-mail]]

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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: March 16, 2011 6:18 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.