Re: [6lowpan] 01 version of IP over IEEE 802.15.4

Sakane-san,

Thanks for your generous words.

Shoichi Sakane wrote:
> Hi,
> 
> 
>>   draft-montenegro-lowpan-ipv6-over-802.15.4-01.txt
> 
> 
> as i read the draft, let me say thank you for the great work,
> and i have two comments.
> 
> 1. A link fragment defined at the section 2 is always placed to the MAC
>    payload in the MAC protocol data unit of IEEE 802.15.4, right ?
>    If my understanding is correct, it would be better for me to describe
>    that though it might be explicit thing.

Not sure I understand the question. Section two does not talk much about
fragmenation. In that respect, there is no mention of "link fragments" as
per your question. There is, however, mention of IPv6 links (which map to
IPv6 prefixes).

There is mention of link fragments in section 4, however. Even so, not all
packets will need to be fragmented (the expectation is that most will be
small enough). Only those that are fragmented use the encapsulation in
figures 2 and 3. Unfragmented packets use the simpler encapsulation format
in figure 1.

Perhaps you're asking where exactly this encapsulationn format (figs 1-3)
occurs. Yes, it is the MAC frame payload in the 15.4 MAC PDU. I agree that
it makes sense to say so explicitly. Added this as a new first paragraph in
section 4.1:

    All IP datagrams transported over IEEE 802.15.4 are prefixed by an
    encapsulation header with one of the formats illustrated below.  The
    encapsulation formats defined in this section are the payload in the
    IEEE 802.15.4 MAC protocol data unit (PDU).

>    
> 2. in the section 8.1, "PI" is defined like below:
> 	PI: Prefix included in-line
>    "in-line" means that the prefix included in the following IPv6 header ?
>    or it included anywhere ?
> 

It means that it is included as a non-compressed field. Notice that what follows
the encoding bit maps is not an IPv6 header, as the point is to compress it.
Rather, what follows is a smaller version of an IPv6 header comprising the
non-compressed fields as specified in section 8.2. I've added references to
section 8.2 whenever 'carried in-line' is used, as in:

E.g., this is how it reads now:

       PI: Prefix carried in-line (Section 8.2)
       PC: Prefix compressed (link-local prefix assumed)
       II: Interface identifier carried in-line (Section 8.2)
       IC: Interface identifier compressed (derived from link-layer
          address)

And added this as the new first paragraph in section 8.2:

    This scheme allows the IPv6 header to be compressed to different
    degrees.  Hence, instead of the entire (standard) IPv6 header, only
    non-compressed fields need to be sent.  The subsequent header (as
    specified by the Next Header field in the original IPv6 header)
    immediately follows the IPv6 non-compressed fields.

Hope that helps,

-gabriel

_______________________________________________
6lowpan mailing list
6lowpan@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan